Webes ERP

Web, mail, IRC, IM, hálózatok

Segítséget kérnék webes ERP appokkal kapcsolatban.
Van néhány kiszemelt áldozat (ha tudsz jobbat, linknek örülnék).

Ami az alapelvárás (súlyozottan):
- GPL
- Webes app (java nem játszik, PHP, Python, Perl. Ruby csak akkor, ha bármilyen linuxra könnyen feltehető)
- Tud magyarul (nem 21%-ban, legalább 90-ben)
- Tud MySQL-be dolgozni
- Tud LDAP auth-ot

Ilyeneket találtam hirtelen:

http://www.erp5.org/
http://www.dolibarr.org/
http://sourceforge.net/projects/blueerp/
http://www.gnucash.org/
http://www.phreesoft.com/
http://www.weberp.org/

A Dolibarr-t ahogy elnéztem, mindenben megfelel. A kérdés főleg az, hogy van-e más, ami nekem jobban kell, mert esetleg többet vagy jobban tud. Ha esetleg nincs a listán, akkor mi az, jobb ennél/ezeknél?

THX előre is.

( royal v | 2013. 09. 12., cs – 00:41 )

Szerintem a "többet vagy jobban tud" az nagyon relatív. Amiket felsoroltál, még azok sem teljesen egy ligában játszanak, nagy tudásbeli eltérések vannak közöttük. Vannak konkrét elvárások, célok meghatározva, amire használni szeretnéd?

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

( vl v | 2013. 09. 12., cs – 01:52 )

java nem játszik, PHP, Python, Perl.

Istenem, borogass... Jó, hogy nem bash vagy Visual Basic.

Örök dilemma:
szar programnyelv vs. szar programozó

Az ember találékony és gyárt magának eszközöket.

Eddigi rekord "ERP" amit láttam excelben készült és googleGroups-ban használják a googleDocs segítségével (formokat is ott készítette el a tulajdonos, aki egy excelmágus közgazdász). Van Ő neki kiskereskedelemme három üzlettel + egy nagykereskedelme. Azt mondta: egy fillért nem költ IT-re. Programozói szemmel szánalmas, közgazdász kisvállalkozói szemmel zseniális.

A legtöbb brutális gányolással Javában találkoztam - egyrészt. Másrészt 5 Java alatt futó platformhoz 5 küklönböző Java verziót kell felrakni sok esetben, mert a fejlesztő kiköti, hogy neki az a verzió kell (ami egyébként irdatlan backdoorokkal van tele) - no, ez nem hiányzik.
Lehet isteníteni a Javát, csak ne előttem, még ha el is hiszem, hogy jó dolog, és aki szépen dolgozik benne, az jót produkál. Sajnos csak saját tapasztalatnak vagyok hajlandó hinni, mivel nekem kell szívnom vele, ha valami nem OK.

Szóval igen: Java off.
--
PtY - www.onlinedemo.hu

Oke, rakerdezek: jelenleg hany darab Java alapu alkalmazas fut azon a webszerveren, amire ezt itt es most telepitened? Es hany darab Java verzio van fenn?

Mert oke, hogy mindezt altalanossagban elmondod, ez altalanossagban igaz is, de te nem altalanossagban akarod megoldani a problemat, hanem itt es most. Marpedig el kellene tudni vonatkoztatni a nagy altalanossagoktol, es figyelembe venni peldaul a projekt igenyeit.

Egyebkent pedig uzemeltettem mar en is Java alkalmazasokat, es igazabol sosem volt gond abbol, hogy mindig az elerheto legfrissebb Sun/Oracle JDK volt fenn a gepen. Egyetlen esetben volt egy dedikalt Java 1.4, de az egybe volt gyogyitva tobbek kozt egy osregi Tomcat-tal es az egesz egy darab bundlekent mukodott, kellett gyartani egy init scriptet neki, es elindult-leallt anelkul, hogy barmit foglalkozni kellett volna vele.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Egy kicsit én is idegenkedem a Javatól, de közel sem ennyire és teljesen más okból.
Mindeközben a TomCat és a JBoss, meg az ezeket használó alkalmazások köszönik szépen jól elvannak! :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Lehet, hogy programozói szemmel szánalmas, de végül is a megfelelő eszközt használta a megfelelő feladatra. Ha néha el kell tolni pár méterre 1 talicska földet, nem vesz emiatt egy kamiont. Nyilván elég volt neki egy excelben összebarkácsolt valami, ami az ő kis cégének az igényeit tökéletesen kiszolgálta/kiszolgálja.
Akkor van baj, amikor azt nem képesek ésszel felérni a vezetők, hogy a cég kinőtte/kinövi a barkácsolt rendszert. továbbra is azt nyomják, és ezzel feleslegesen erőforrást pazarolnak. Főleg emberit, ami a legnagyobb költséggel jár. Mert csak azt látja a hülye mánáger, hogy a X rendszer bevezetése Y millió Ft, de azt már nem, hogy ha nem vezeti be, akkor munkabérben akár 2Y-t is kifizethet a cég, mert megfelelő támogató rendszerrel ugyanazt a folyamatot a dolgozó töredék idő alatt el tudja végezni.

Nem igaz, hogy egy fillért nem költ IT-re. Egyrészt "költi" a saját idejét, másrészt meg költ gépre, internetre, stb.

Na meg, külön aranyos lehet összepárosítani a saját cikktörzset a beszállítói cikktörzsekkel, főleg, ha naponta kellene frissíteni az árlistákat. Na meg kb. a pokolba kívánom azokat, akik még mindig nem jutottak el odáig, hogy valamivel generálják az árlistájukat és ne kézzel farigcsálják. Kurva nagy élmény, mikor egy ilyen Excel mágus úgy dönt, hogy egy picit változtat az árlistája formátumán. (Oké, a legtöbb esetre fel van készítve a betöltő, de ugye az userek túl kreatívak tudnak lenni.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( saxus | 2013. 09. 12., cs – 02:54 )

Erdekes, hogy jobb helyen a funcionalitas alapjan szokas ERP-t valasztani nem ilyen ("vicces") technikai ervek menten, mint legyen MySQL meg PHP.

GNU Cash meg csak nem is ERP rendszer...

A webes rendszer meg izles kerdese, de reszemrol le nem cserelnem ezekre a szarokra azt, amink nekunk van, pedig azert azzal is megkuzdottunk :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Jobb helyen használnak FLOSS ERP-t?
Oszt csetten várják a szupportot? Vagy maillisten?
Ááááá nem gond, ha áll a számlázás vagy megHaxxolták a FLOSS-t.

Nekem kicsit olyan ez (vállalati szemmel), mint olajcsere nélkül autózni vagy használt ejtőernyőt vásárolni, mert adnak hozzá ajándék leselejtezett bungee-jumping kötelet. :)

Teljesen igaz, de az előbbi posztban írtam az okot. Olyan gépre kerül, ahol már van apache és mysql. Más gép nincs, így nem elsz oracle/mssql/postgres/stb sem. Azon kell mennie, ami _van_.
Nem értek az ERP-hez, mik azok a funkcionalitások, amik általában számításba jöhetnek, mint igény?
--
PtY - www.onlinedemo.hu

"Nem értek az ERP-hez, mik azok a funkcionalitások, amik általában számításba jöhetnek, mint igény?"

Ezt az usernek kell tudnia megmondani. Olyan nincs, hogy kell egy random erp. Masreszt ugyanazt az ERP-t is lehet egeszen eltérő módon hasznalni, pl. mit építész kore, mihez hogyan csatolod, stb.

----------------
[=8]Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™[/siz

Ez eddig rizsa. Az alapdolgokat, (partnertorzs, cikktorzs, keszletezes, kijovo-bejövő szamla/szallito, folyoszamlak (tartozások) kezelése) meg nagyjabol talan használhatóak mindben (bar itt is vannak érdekes dolgok, pl. az előző rendszerünkben allitolag hosszu percekig tartott egy sima raktári karton lekerdezes) az érdekesebb resze utana kezdodik: mit, hogyan akarsz automatizálni, milyen adatokat honnan fogadsz, hova kell feladni, azokat mennyire kepes hatékonyan kezelni), import/export excelbe mennyire támogatott, hogyan arazol, stb.

Arrol nem is beszelve, hogy a webes ui erre a célra, nos hat nem a használhatóság csúcsa.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nincs. Ez pont ugyanolyan, mint amikor odajonnek hozzad, hogy menj, es vegyel egy szamitogepet. Mindegy milyet, csak szamitogep legyen, es gyorsan vedd meg.

Le kell ulni a userrel es osszeszedni, hogy mi az, amit feltetlen tudnia kell az ERP rendszernek. Mire akarjak hasznalni, mit akarnak benne tartani, stb.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Tehát abban az esetben, ha pl. Te számítógépet akarsz eladni, akkor nem raksz össze egyet sem, ami eladható?
Miért adnak el a műszaki áruházak mégis több előre legyártott konfigot, mint a kisebb üzletek, ahol összerakják?
Mert a többségnek általánosságban kell egy PC, amin internetezhet, egyszerűbb játékokkal játszhat, filmet nézhet.
--
PtY - www.onlinedemo.hu

azert valljuk be egy ERP meg egy szamitogep kozott van egy kis kulonbseg:

Ha a szamitogep nem jon, be meg mindig vehetsz masikat, erosebbet es penzen kivul nem vesztesz semmit

Egy ERP nem egy Word, hogy siman lecsereld Open/Libre office-ra de meg csak nem is szamlazo-keszletnyilvantarto program.
1, nem kell minden cegnek ERP, van mikor ez nem indokolt.
2, egy ERP annyira meghatarozza a ceg eletét, hogy annak lecserelese ugy hogy a ceg uzletmenete ne szenvedje meg, nem piskota...

Biztos hogy te ERP-t akarsz ajanlani az ugyfeleidnek?

Szinte csak olyan van, hogy "random erp" kell. Hányszor futottam már bele abba, hogy az ügyfél az igényt sem tudta megfogalmazni, hogy mit is akar pontosan. Specifikációról már nem is álmodtunk. Volt aki kért tesztre munkacsoport szervert, aztán közölte, hogy ez egy sz@r. Mint kiderült, azért volt sz@r, mert neki valójában egy projekt menedzsment rendszerre volt szüksége. :) És olyan funkciókat egy munkacsoport szerver többnyire nem tud.

"Olyan gépre kerül, ahol már van apache és mysql."

Vakuljak meg, de ezt en nem erzem korlatnak sem a Java-ra sem masik adatbazismotorra. Egy postgres vigan elfut egy mysql mellett ha nagyon kell, es a Java appokat is at lehet proxyzni apache-n keresztul. Szoval az indokaid invalidak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

El fut mellette, csak plusz erőforrás itt is, ott is. Ezen az áron nem kell. A Javát meg már kitárgyaltuk, és ez olyan dolog, amiben lehet érvelni, csak épp nem fogom a _véleményem_ megváltoztatni - még ha én is gondolom rosszul :)
De azért meg ne vakulj, az nem egészséges :)
--
PtY - www.onlinedemo.hu

Az a problema, hogy en pontosan tudom mi van az ilyen hozzaallas mogott. Lattal ket-harom gany, osregi Tomcatre epulo, talan meg a JavaEE-t sem ismero rendszert, ami allandoan esett-kelt, igy levontad a konzekvenciat: a Java szar. Csakhogy az a problema, hogy ugyanakkor nagysagrendekkel tobb olyan PHP rendszert latni, amelyik esik-kel, es esetleg meg nem is tamogatja a legujabb PHP-t, megse mondta meg soha egy rendszergazda sem, hogy a PHP szar, es PHP-s appot fel nem tennek a szerveremre. Amit itt ereztetni akarok, az a kettos merce, ami a Java es a PHP kozott huzodik.

Nem mondom, hogy valtoztasd meg a velemenyedet, de talan probald meg felulvizsgalni esszerusegi szempontok alapjan. Ugyanis egy olyan velemeny, ami nem esszeru, az nem velemeny, hanem hit. Es hinni nem a munkahelyen kell, hanem egy bizonyos tornyos kis epuletben.

A plusz eroforras pedig megfontolas kerdese. Bizonyos userszam alatt annyira nem nagy overhead. Ezt is inkabb merlegelni, esetleg merni kell, mielott kategorikusan elutasitod.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Te is tudod, hogy tök igazad van, bár nem mindenben.
Kókány munka van PHP-ben is, nem is kevés, hajjaj! Ám sokkal könnyebb megvédeni egy olyan kódot, ami egy Apache, vagy más, jobban védhető kiszolgáló mögött fut, mint azt a tisztességes Java kódot, ami egy bug- és exploit halom motor mögött fut - ebben is egyet tudunk érteni, azt hiszem.
Főleg, hogy egy PHP kódba könnyebb belenyúlni, ha pl. egy szöveges beviteli mező úgy íródik vissza egy input mező value tulajdonságába, hogy nincs escape-elve, és emiatt poisoninggal támadható az oldal, mint egy Java app esetén.
Ezért van az, hogy a PHP-t - annak ellenére, hogy minden 8. osztályból kikerülő srác már PHP fejlesztő (LOL) - sokkal inkább megtűrjük a rendszeren, mert könnyebb idomítani a kódot, és könnyebb legyerélni a frontendet - Apache-ot Lighttpdre, azt Nginxre, amazt megint másra.
A nagyobb probléma meg az, ha van egy SSL-es oldalad már, és a Javát is be akarod fűzni alá, de egy külső IP-d van, és nem tudsz neki adni mégegy NAT-ot, bohóckodni kell reverse proxyval, és ha a Java fejlesztő ügyes volt, akkor az összes belső hivatkozás abszolút lesz, és http://-rel kezdődik, ami mégjobban megbonyolítja a korrekt proxyzást.
Szóval nagyon sok esetben fölösleges terhet is jelent a Java, nem csak a motor hibái és a programozók trehánysága jön számításba.
--
PtY - www.onlinedemo.hu

Lehet, csak aha fejlesztő rosszul választja meg az adott objektumosztályt, akkor anélkül, hogy észre venné, ilyen lesz.

Nyilván statikus HTML-ben is lehet ilyet tenni. Itt pl. a

<a href='/'>link</a>

<a href='http://hup.hu/'>link</a&gt;

ekvivalens, csak ha betesznek elé egy reverse proxyt https-en keresztül, az egyikkel sokkal több lesz a szívás.
--
PtY - www.onlinedemo.hu

( dejo v | 2013. 09. 12., cs – 07:07 )

Az ERP rendszereknél elsősorban magának a rendszernek az átlátása jelenti a legnagyobb problémát.
Nem értem, hogy miért kikötés, hogy MySQL legyen alatta? A PostgreSQL miért nem jó?
Amúgy meg OpenERP. Igen Python nyelven íródott, de WEB-es felületen használható. És nagyon sok modulja van.
Én találtam leírást a telepítéshez ami alapján könnyen feltettem egy CentOS-re.
Még csak kóstolgatom, tanulmányozom. Ott még nem tartok, hogy élesben merném üzemeltetni. De időm függvényében most ezt tanulmányozom.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( szipka | 2013. 09. 12., cs – 11:44 )

Ez kb olyan mint autót választani üléshuzat, és szín alapján. Ez kicsit fordítva kellene történnie, a pénzügyes, managment, stb döntéshozók csinálnak egy listát, hogy milyen funkciókra van szüksége a cégnek. Ez után lehet megvizsgálni a rendszereket, hogy melyik az ami ezeket tudja. Ezután jön az üzemeltetési szempont, ami alapján lehet még dönteni. De hogy egy terméket kizárj, mert nem mysqlt használ, vagy mert javas, az egy kicsit nonszensz. Az hogy a cég nem akar beruházni egy erp rendszerhez, még minimális hardware-t sem , akkor nem is annyira fontos az erp rendszer, jobb ha be sem vezetik. Nincs rosszabb mint egy rosszul bevezetett rendszer.

Teljesen igazad van, és nem is gondolod, hogy rátapintottál a lényegre, és pont fordítva gondolod a valóságot.

Az ERP rendszer nem kell konkrétan _senkinek_ még. Így nincs mihez igazítani, nincsenek konkrét igények.
Van egy applikációs csomag, aminek vannak komponensei és vannak szolgáltatásai, és ezekhez kell illeszkednie az ERP-nek, mert evvel akarjuk bővíteni a szolgáltatás csomagot.
Nyilván benne van a képben, hogy valakinek - mint ügyfélnek - ez nem lesz jó, akkor ezt a komponenst nyilván nem is fogja kérni. De: az appnak a meglévő struktúrába illeszkednie kell, ezért van kizárva az, ami ki van zárva.
Tehát ige, üléshuzat szerint kell választani egy megfelelő autót, mert a többi szín már adott, és lila üléshuzat zöld pöttyel nem fog játszani, mert nem illik a rendszerbe.

Tehát továbbra is csupán annyi a kérdésem - amire még konstruktív válasz nem jött -, hogy a fentiek közül melyik az, ami nem csak megfelel a kívánalmaknak, hanem egymáshoz képest a lehető legáltalánosabb, legjobban testre szabható, legkönnyebben kezelhető - nyilván, ehhez ismerni kell némelyiket, meg konkrétan az ERP-k képességeit, de ez ügyben nekem semmi tapasztalatom.
Ha esetleg van olyan rendszer, ami nincs a listán, de bárki szerint az a jó választás, és a kritériumoknak megfelel, az sem baj.

Egyébiránt nem is baj, hogy belekötöttetek a fentibe, elég fontos infó volt amit nem írtam le az eredeti kérdésben - fáradt voltam, elsiettem, sorry :)
--
PtY - www.onlinedemo.hu

és ezekhez kell illeszkednie az ERP-nek, mert evvel akarjuk bővíteni a szolgáltatás csomagot.

Ez igy eleg erdekes uzleti terv.

Gondolom egy komplett csomagot kinaltok az ugyfeleiteknek amiben ERP-t is bele akartok tenni.

En a helyedben azt valasztanam amihez a legjobban ertek, mert aki azt monjda hogy egy akarmilyen vallakozasnak megfelel majd az off-the shelf ERP az nem ert hozza, illetve annak a cegnek akinek megfele annak szerinem csak szamlazoprogramra+raktarkeszlet nyilvantarto-ra van szuksege, es nem komplett integralt vallalatiranyitasi rendszerre.

A masik szempont pedig az hogy mielott ERP-t vasarol/bevezet egy ceg, felul kell hogy vizsgalja a meglevo uzleti folyamatokat, munkamenetet, vallalati strukturat, stb. csak ezutan lehet nekiallni keresni olyan ERP-t ami a meglevo vallati kornyezetbe jol illeszkedik, illetve minel kevesebb valtoztatassal (legyen az a szoftver oldalon, vagy az uzleti folyamatok oldalan) be lehet vezetni.

En ugy latom, hogy tok mindegy melyik rendszert valasztod, felteve hogy:
- az ugyfelednek eleg flexibilisek az uzleti folyamatai, hajlando oket a ERP-kovetelmenyei/korlatai szerint megvaltoztatni,kialakitani es vallalja az ezzel jaro atkepzeseket.
- esetleg egy uj vallalkozas kialalkitasok ugy alakitasz mindent hogy minel kevesebbet kelljen buheralni az ERP-n
- fel vagy ra keszulve, hogy a rendszert rászabd a cegre

helyedbe kriteriumkent az AD-n vagy openldap-n keresztuli authentikaciot tekintenem a legfontosabbnak ha mar sok kulon szoftver-bol alakitasz ki egy csomagot.

Benne van a kritériumok között az LDAP. ;)
Ne úgy értsd, hogy rá akarunk bármit is erőltetni bárkire, mert az neki jó... Szó nincs erről. Van egy alapszolgáltatás, és ahhoz _lehetnek_ komponensek, amit vagy kér, vagy nem kér (mert nem jó neki, vagy nincs rá szüksége, stb.).
Egy ilyen komponens csupán az ERP - egyébként az sem kizárt, hogy ha több olyan használható app van, ami beleillik a képbe, hogy több -féle legyen a kínálatban, aztán majd az ügyfél eldönti, hogy kell-e, és ha igen, akkor melyik.

Tehát nem cél, hogy mindenkinek megfeleljen, az a cél, hogy aki igényli, és a kínálat neki megfelel, azt ki lehessen szolgálni - semmi több.

És nem, nem kötelező elem - természetesen.
--
PtY - www.onlinedemo.hu

Tehát nem lehet megállapítani egyik felsorolt elemről sem, hogy:

- Tud LDAP auth-ot
- Rendelkezik testre szabási lehetőségekkel (pl. pluginek)
- A legtöbb vállalkozás számára alkalmassá tehető (mindenféle hackelés nélkül)
- Be lehet plusz komponens nélkül integrálni olyan kiszolgáló alá, amin apache-php-mysql alapú alkalmazások vannak

Ha ez így hangzik el, akkor miért is nem lehet rá értelmes választ adni?

Az más kérdés, ha valaki ugyanúgy nem ért a működéséhez, mint én, és csak kötekedik - ezt elfogadom. Azt is, hogy pl. nem akar válaszolni, mert csak, és amúgy is lóf@sz a hátsómba, ez is OK.

De azt, hogy nem lehet ezek alapján válaszolni, nem tudom elképzelni. :)

--
PtY - www.onlinedemo.hu

Nem akar senki semmit senkire _rásózni_. Kellene a palettára egy (vagy több) ERP alkalmazás, ami a jelenleg kialakított környezetbe beleilleszthető, amit választhat az ügyfél ha kell neki.
Nyilván, ha az lesz a tapasztalat, hogy másak az igények, akkor lesz helyette más - ezért sem lenne rossz, ha van 2 vagy akár 3 választható alternatíva.

Ha ez Nálad rásózás, akkor menj be egy Opel szalonba, és vond kérdőre őket, hogy miért akarnak Opelt rád sózni.

Kezdem azt érezni, hogy nem is akarod érteni, hogy miről van szó.
--
PtY - www.onlinedemo.hu

Használja egy hónapig, és majd el tudja dönteni, hogy kell-e neki vagy sem. Sőt, használhat egyszerre 2-3 félét, és mejd megmondja, hogy melyik a szimpatikusabb számára - vagy egyik sem.
És főképpen olyan ügyfelekre kell gondolni, akik nem engedhetik meg maguknak, hogy egy SAP-t vagy Oracle alapú ERP-t vagy hasonlót bevezessenek.
--
PtY - www.onlinedemo.hu

Az Opel szalonba akkor mennek be, ha egy Opel melle meg egy lakasbiztonsagi rendszert is megprobalnanak eladni nekem. Nagyjabol nalatok is ez zajlik.

Illetve, mindent meg lehetne oldani, de ti valojaban nem szeretnetek annyira ezt az egeszet uzemeltetesi oldalrol tamogatni. Sem az apache, sem a mysql nem korlatja annak, hogy ne lehetne egy Javas, PostgreSQL vagy Apache Derby alapokon mukodo ERP rendszert beuzemelni. De itt jon kepbe az, hogy ehhez vagy nem vagytok eleg kepzettek, hogy ezt belassatok, vagy egyszeruen nincs meg az uzemeltetoi szandek a dolog rendes integralasa mogott. Ezzel itt, ezen a forumon senki nem fog tudni erdemben valtoztatni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ha viszont, így közelítjük meg akkor sem relevánsak a feltételeid. Mert akkor azon a vonalon kellene elindulni, milyen fejlesztőim vannak, milyen tudással rendelkeznek, hogy mindenkinek az igényeire tudjam szabni a programot. Tehát ebben az esetben is irreleváns az üzemeltetői szempontok, itt fejlesztői szempontok a legfontosabbak, ettől függetlenül kijöhet hogy mondjuk php a nyelv, de max ennyi. Meg gondolom akkor OSS-nek kell lennie, hogy hozzáférhessetek a kódhoz. Ha minőségi szolgáltatást akarsz árulni, akkor az ERP-ben pont az a lényeg, hogy testreszabhasd, amihez mindenképp kell fejlesztő, architect stb... Egyébként sem 24 óra megtanulni egy EPR rendszer működését, úgy hogy fejleszthess hozzá, nem váletlen hogy olyan drága egy SAP fejlesztő.

azert ~2000 olvasas es ~50 hozzaszolas utan erdemes elgondolkozni, hogy esetleg nem a 'mindenki hulye csak en vagyok trolibusz' tipusu-e a helyzet...
egyreszt szerintem is ERP rendszer - ceg viszonylatban a kivalasztasnal a fentebb velemenyt nyilvanitokkal etek egyet. lattam mar sap bevezetest 30- es 2000 fos cegnel/intezmenynel is, a kisebb 14 honapig a nagyobbik 24 honapig tartott (hivataloasn, bar meg akkor sem volt minden ok). persze, biztosan tudatlan volt a bevezeto ceg stb. a lenyeg az hogy a meglehetos rutinnal rendelkezo bevezto ceg es egy meglehetos flexibilitassal rendelkezo termek eseten is figyelembe kell venni hasonlo idot. a fentebb altalad elmondottak alapjan veletlenul sem gondolom, hogy a terveitekben hasonlo szereplne (ki tudja persze, a tevedes jogat fenntartom).

technikai oldalrol: a feltetelek alapjan amik a topikinditoban szerepelnek, kb. 4-6 ora google-porgetes utan van 3-4-5 tipped. az elozo bekezdesem alapjan ugyis mindegy melyiket valasztod, es ahogy masok is irtak a fejlesztoi kapacitas/szakertelem hatarozza majd meg, hogy mi lesz a kornyezetbe illesztes vege. tehat elsosorban a dokumentacio / kod minosege alapjan lehet erdemes valasztani az alapokat ugyis tudja mindegyik amelyik szoba johet.

roviden ami neked kellene: ingyen legyen, jo legyen, tudjon mindent, amit nem azt ket perc alatt lehessen beletenni. ugye milyen erdekes igy egyutt latni a kovetelmenyeket? ha lenne ilyen akkor a google elso talalatban hozna, gondolhatod.

( PtY | 2013. 09. 13., p – 10:20 )

Azt hiszem, tisztáznom kéne néhány dolgot, mert totálisan elbeszélünk egymás mellett - ami lehet, hogy főképp az én hibám, de ez abból fakad, hogy az ún. ERP-hez nem értek.

Azt hiszem, KeeF volt az, akinek sikerült egy részét meglátni annak, hogy mit is szeretnék.
Az alapvető probléma az, hogy ma mindenki mindent ERP-nek hív, és ha elhangzik a szó, akkor mindenki egy titkos csodafegyverre gondol, és aszerint kezeli, holott lehet, hogy messze nem arról van szó. Itt sem. Az, hogy ezeket ott fenn, amit összeszedtem, ebbe a gyűjtőbe szórják, és onnan vettem ki - talán - nem az én hibám. Nagyjából azt tudják, amire nekem kell:
- számlák kezelése,
- pénzügyi tranzakciók kezelése,
- eszközök nyilvántartása,
- stb.

Tehát azok a minimális dolgok, amik minden vállalkozás esetén (vagy legalábbis a többség esetén) számításba jöhetnek, semmi több. Természetes, hogy nem egy SAP-ról vagy egy Oracle ERP-ről vagy Saldoról beszélek, ilyen szintű funkcionalitás nem igény. Nem kívánok semmi olyasmit adni senkinek, ami többnek látszik, mint ami valójában, vagy amire ténylegesen használható.

Ami a fenti rendszereket megkülönböztetheti egymástól az az, hogy mennyire igazítható a hazai viszonyokhoz - főleg anélkül, hogy bele kelljen nyúlni, hiányzó funkciókat kézzel belevakarni. A pluginek, ha vannak, azok mehetnek, de a kód maga annak kell maradjon, ahogyan azt a gyártó kiadta - ennek többek között upgrade okai is vannak. Tehát a testre szabás csak annyi, amennyit maga a rendszer is enged.
A másik szempont a kezelhetőség. Ha idétlenül van összerakva az app logikája, nem könnyű átlátni, a használata túl van bonyolítva, nyilván nem fogja elnyerni sokak tetszését, ezért nem is szeretném preferálni.

Tehát lefordítva az egészet, eltekintve attól a három betűtől (ERP) - az lenne a kérdés, hogy a fentiek közül melyik az az egy vagy pár app, ami egy hazai kisebb cég/vállalkozás hasznára tudna válni? - talán így kellett volna eleve megközelítenem, de már késő volt, és erre nem (sem) figyeltem.

Azt hiszem, ez az az apró(?) momentum ami miatt az egész thread félre ment, és mindenkitől elnézést kérek, ha nem úgy reagáltam le - az amúgy a hozzászólók szemszögéből nézve teljesen jogos, és építő jellegű - hozzászólásokat, de mint említettem, hosszú napom volt, és ez rányomta a hangulatomra is a bélyegét. Szóval bocs :)

--
PtY - www.onlinedemo.hu

Hát barátom ez a tudás kurvára nem ERP:

- számlák kezelése,
- pénzügyi tranzakciók kezelése,
- eszközök nyilvántartása,
- stb.

Bemész a közértbe és veszel 10e hufért erre a feladatra dobozos terméket supporttal.

ps.: http://hup.hu/node/118541?comments_per_page=9999#comment-1590956
(és még ez egy fiatal rendszer, aminek van hova fejlődnie)
ERP != ügyviteli szoftver

A számlázás lesz az első olyan pont, ahol az összes fent felsorolt, nem hazai fejlesztésű rendszer megbukik, hiszen a hatályos szabályozás szerint egy számla készítő szoftver használatához rendelkezned kell a szoftver készítőjétől egy nyilatkozattal, mely szerint az megfelel a törvényben és jogszabályban előírt feltételeknek.

Persze ezt a problémát is ki lehet kerülni, pl. a szamlazz.hu számla agent használatával, de akkor már megint nem egy integrált rendszerről van szó, valamint nem teljesíti a korábbi feltételeidet (GPL, stb.)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Igen, a probléma nem itt kezdődik.

De egyébként nem ismerek egyetlen olyan F/LOSS alkalmazást sem, ahol alá mernék írni egy nyilatkozatot arról, hogy a program a Magyar szabályozás szerint működik. :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Számlák kezelése - ez is félreérthető.
Nem gondoltam számlakészítésre, főleg annak tudatában, hogy gyakran változnak a számlázás szabályai, és az ilyen jellegű dolgokat nem kéne belemókolni, és nem hiszem, hogy alapból meg tudná bármelyik is. Iktatás, nyilvántartás - ilyesmik.
--
PtY - www.onlinedemo.hu

Ami változik az a bérszámfejtés.
A számlák 2000 óta pont ugyan úgy néznek ki.
Max az ÁFA _mértéke_ változik, puff. Ettől még nem kell újra írni az appot.

Saját rendszeremet 2003 óta fejlesztem és a 2003-as számla is megtekinthető benne. (emiatt is írtam sajátot)

Ami neked kell azt ügyvitelnek hívják. Ha tényleg ez kell neked. Ezek nem drága dolgok. Egy kis vállalkozás is pár tíz vagy száz ezer forintból felszerelhető. pl.: kulcs szoftverek

Nekem úgy rémlik, hogy a 2001. január 1-i sok változás egyike volt, hogy a számla kötelező adattartalmi elemei közé bekerült az "áthárított adó összege tételenként és összesen" sor. De ettől függetlenül a mi rendszereink is már az előző évezredben is feltüntették a számlánkon ezt. :)
A 2001-es előírásokhoz képest sok változás volt már, de ezek szinte mind egyszerűsítések, így ami akkor megfelelt bizonylat, az ma is megfelel, mert szinte biztos, hogy túlteljesíti a jelenlegi előírásokat.
--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Viszont ezzel meg pont az integrált rendszer előnyeit dobod el.
Egy ERP rendszerben a számlázás a rendszerben szereplő egyéb adatok alapján (pl. készletinformációk, szállítólevelek, munkalapok, stb.) maximum néhány gombnyomással készül el, valamint az elkészített vevői számla importálásra kerül a pénzügyi nyilvántartásba. Egyik folyamatnál sincs szükség biorobot általi redundáns és manuális adatbevitelre :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Ahol kézzel írják a számlát és ezen nem is akarnak változtatni, az nem igazán célközönsége bármilyen ERP rendszernek.
Ahol pedig kézzel írják és változtatni akarnak, ott már teljesen normális igény, hogy az elkészült számla adatait ne kelljen kézzel felvinni újra valahova :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Azert az ERP eleg behatarolhato dolgot jelent, meg a wikipedia is ossze tudta fogni egy cikkbe.

Talan masik elnevezest kellene hasznalni azokra a cuccokra, amik nem felelnek meg a kriteriumoknak, es akkor nem lenne felreertes.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Te valaki olyan szállítót keresel, aki garantálja, hogy hozzáigazítja neked a gpl-es cuccot a magyar szabályokhoz változás esetén. Aki hosszabb távon is tudna ilyet, az kicsit komolyabb termékeket forgalmaz (és fejleszt), úgyhogy be kell vállalni némi kockázatot, hogy dzsunkabt vagy havervállalkozó egyszer csak visszadobja a rendszerkövetés melót, ha sikerül szerződést kötni rá.

"Ami a fenti rendszereket megkülönböztetheti egymástól az az, hogy mennyire igazítható a hazai viszonyokhoz - főleg anélkül, hogy bele kelljen nyúlni, hiányzó funkciókat kézzel belevakarni."

Na ez az, ami egyetlen nem-magyar fejlesztesu appnal se lesz meg. Nem veletlen pedzegette valaki, hogy az alapjan is kellene valogatni, hogy milyen fejlesztok vannak a cegednel. Mert egy random kulso cucc _sosem_ fog viszonyulni a hazai viszonyokhoz, egyszeruen kulfoldon (gondolok itt elsosorban az USA/UK vonalra) teljesen maskepp mennek a dolgok. Gyokeresen.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.