Jak nejlépe zautomatizovat napojení e-shopu na účetní software?

Zdravím, rád bych vás požádal o informace, jakým způsobem máte nastaveny procesy co se týče vedení skladu pro účetnictví, resp. napojení e-shopu na účetní software. Abychom nedělali vše ručně, tak máme vytvořen násl. způsob. 1, v objednávce se vygeneruje faktura (jedním klikem) která se vytiskne a současně také uloží do "modulu", ze kterého se exportuje ven a importuje jednou měsíčně do Pohody (všechny faktury najednou) za celý měsíc. 2. jelikož prodáváme hadry, tak se spousta toho vrací. Tím pádem v e-shopu se přímo také generuje opravný daňový doklad k dané objednávce a opět se nahrává za celý měsíc do Pohody. Potřebujeme ale ještě hlavně vyladit a zautomatizovat příjemky, výdejky a skladové karty produktu. Jelikož se sortiment strašně obměňuje, tak zatím neuvažuji o zřízení kódů. Protože by se pořád ty produkty lepily, ale reálně by mi to asi moc neulehčilo. Co se týče skladu, tak je nutné ručně naklikat do Pohody všechny přijaté faktury (ty dostáváme v papírové podobě) a z nich se pak dělají příjemky. Výdejka se pak udělá jedním klikem z faktury. K tomu je ještě nutné samozřejmě nové zboží dávat do zásob (skladové karty) A řeším teď, jak toto vše zjednodušit, protože ta práce je enormní. Došel jsem ke dvěma řešením. Buď napojit celý e-shop na Pohodu a objednávky vyřizovat tam. Že by se z objednávky vytvořila rovnou vydaná faktura a výdejka v reálném čase a přenášely by se i nové skladové karty (automaticky). Ručně by se tedy datlovaly jen příjemky. Dělal by to tedy rovnou skladník při balení. Ale trošku se toho obávám, protože nevím, jak moc ulehčující bude objednávky vyřizovat v Pohodě. Mě ten systém přijde celkem pomalý a nepřehledný. Za to administrace shopu nám vyhovuje (jedeme na Opencartu) a celkem to máme vyladěné. Druhou možností mě napadlo to, že bych e-shop na Pohodu nenapojoval, ale v e-shopu bychom dělali rovnou příjemky (ručně, v nějakém modulu) a také by se rovnou automaticky k vydaným fakturám do modulu ukládaly výdejky. V xml by se také stahovaly také nové skladové karty. Jednou měsíčně by se tedy veškeré vydané faktury, opravné daňové doklady, příjemky, výdejky, skladové karty nahrály do Pohody. Z jejich strany mě ujistili, že pokud budou příjemky a výdejky ve správném formátu, bude to navazovat i na sklad a jeho pohyby. Co vám přijde ideálnější a jak to máte řešeno vy?

Pohoda je super, ale má své limity a ted jsi na hraně jelikož do krabicového řešení se jim moc dělat takové úpravy nechce. Asi by bylo lépe přejít na Pohoda + a nebo na jiný otevřený systém, kde si to uděláš jak potřebuješ. Jestli by to bylo rychlejší dělat v vše v Pohodě se musí jedině vyzkoušet. Jinak pokud nenakupuješ u Vietnamců nebo někoho, kdo píše faktury ještě ručně nech si faktury posílat v elektronické formě a následně je importuj do příjemky at to nemusí skladník datlovat a nebo pro naskladnění používej čtečku, ale to se ti nechce.

Napsal Mar_o55;1405581

Zdravím,

rád bych vás požádal o informace, jakým způsobem máte nastaveny procesy co se týče vedení skladu pro účetnictví, resp. napojení e-shopu na účetní software.

Abychom nedělali vše ručně, tak máme vytvořen násl. způsob.

1, v objednávce se vygeneruje faktura (jedním klikem) která se vytiskne a současně také uloží do "modulu", ze kterého se exportuje ven a importuje jednou měsíčně do Pohody (všechny faktury najednou) za celý měsíc.

2. jelikož prodáváme hadry, tak se spousta toho vrací. Tím pádem v e-shopu se přímo také generuje opravný daňový doklad k dané objednávce a opět se nahrává za celý měsíc do Pohody.

Potřebujeme ale ještě hlavně vyladit a zautomatizovat příjemky, výdejky a skladové karty produktu. Jelikož se sortiment strašně obměňuje, tak zatím neuvažuji o zřízení kódů. Protože by se pořád ty produkty lepily, ale reálně by mi to asi moc neulehčilo.

Co se týče skladu, tak je nutné ručně naklikat do Pohody všechny přijaté faktury (ty dostáváme v papírové podobě) a z nich se pak dělají příjemky. Výdejka se pak udělá jedním klikem z faktury. K tomu je ještě nutné samozřejmě nové zboží dávat do zásob (skladové karty)

A řeším teď, jak toto vše zjednodušit, protože ta práce je enormní. Došel jsem ke dvěma řešením. Buď napojit celý e-shop na Pohodu a objednávky vyřizovat tam. Že by se z objednávky vytvořila rovnou vydaná faktura a výdejka v reálném čase a přenášely by se i nové skladové karty (automaticky). Ručně by se tedy datlovaly jen příjemky. Dělal by to tedy rovnou skladník při balení. Ale trošku se toho obávám, protože nevím, jak moc ulehčující bude objednávky vyřizovat v Pohodě. Mě ten systém přijde celkem pomalý a nepřehledný. Za to administrace shopu nám vyhovuje (jedeme na Opencartu) a celkem to máme vyladěné.

Druhou možností mě napadlo to, že bych e-shop na Pohodu nenapojoval, ale v e-shopu bychom dělali rovnou příjemky (ručně, v nějakém modulu) a také by se rovnou automaticky k vydaným fakturám do modulu ukládaly výdejky. V xml by se také stahovaly také nové skladové karty.

Jednou měsíčně by se tedy veškeré vydané faktury, opravné daňové doklady, příjemky, výdejky, skladové karty nahrály do Pohody. Z jejich strany mě ujistili, že pokud budou příjemky a výdejky ve správném formátu, bude to navazovat i na sklad a jeho pohyby.

Co vám přijde ideálnější a jak to máte řešeno vy?

Dobry den,pohoda ma svoje limity, ale iba do okamihu, pokial ju nepoznate a neviete z nej vytazit maximum, co sa v nej nachadza. Fakt je samozrejme aj ten, ze v sucasnej dobe robim prepojenia iba s pohodou E1(CZ/SK). S pohodou MDB nedokazem ABSOLUTNE NIC, s pohodou SQL o nieco viac ale aj tak je to chudoba. V pripade, ze je clovek databazovo znaly, dokaze ist priamo do databazy a napojit sa konnektorom cez databazu a napojit si co len potrebuje. Uzivatel v pohode to uz vidi nasledne vo front-endovej aplikacii zvanej Pohoda. To co sa deje na pozadi, je uz vec externej aplikacie alebo skriptu, ktory riadu pracu na pozadi.1. Do pohody sa daju importovat prijate objednavky a tie preklapat do vydanych faktur a taktiez aj vydane faktury, to je vztah Vy-zakaznik, a potom vydane objednavky - prijate faktury, to je vztah dodavatel.2. Pokial sa robi dobropis, dobropisuje sa vzdy konkretna faktura. Netvrdim, ze sa nemoze spravit jedna suhrnna faktura a na nu prijemka, co sa vrati na sklad ale zo zvyku sa spravi dobropis vydanej faktury a ta vrati tovar na sklad.Spravidla byva vzdy ako vztycny system - ekonomicky system cize ERP. Ten drzi doklady, zasoby, ciselniky, adresar, strediska, predajne ceny...atd. Ten potom komunikuje s eshopom ale eshop je len prilepeny na ERP a berie si doklady. Zo zvyku - co generuje eshop, byva:adresa, objednavka a reklamaciaokrem tychto 3 agiend som sa nestretol s tym, ze by este nieco potreboval eshop importovat do ES.Preto mi pride ovela viac praktickejsie spravit riesenie:"A řeším teď, jak toto vše zjednodušit, protože ta práce je enormní. Došel jsem ke dvěma řešením. Buď napojit celý e-shop na Pohodu a objednávky vyřizovat tam."a ako som napisal, zbytok je len o tom, akeho mate konzultanta, kto s tym ES vie ako robit a kto z toho vie co vytiahnut.Stevo

Sice nepoužívám pohodu, ale rozhodně je lepší řešení napojit eshop na účetní sw, a vše řešit v tom účetním sw (ve vašem případě pohoda).

inet-creative: a co používáte vy? Jinak ano, asi se k tomuto řešení již také klaním.

Vsechny ucetni softy jsou pro realtime propojeni s eshopem prilis pomale. Co se tyce propojeni, tak jediny ucetni soft co jde rozumne propojit je Flexibee. Tam vse co jde naklikat rucne muze udelat system pomoci rest api. V Money a Pohode musis sahat do DB. Neuvedomis si nejakou vazbu nebo v pristi verzi zmeni strukturu DB a mas data v...

Napsal Mar_o55;1406863

inet-creative: a co používáte vy? Jinak ano, asi se k tomuto řešení již také klaním.

Já používám LP Soft Profit... je výrazně jednodušší než pohoda a pro mé účely postačuje. Pro propojení podporuje klasické xml které se dá dobře nastavit přímo v softu (nicméně používám opencart takže si propojení píšu přímo na míru)

Napojovat Pohodu přes databázi je nesmysl. Kdo zaručí, že se schéma nebude měnit? A že vyplníte všechna potřebná pole?Pro propojení s e-shopem (naprosto jakýmkoliv) doporučuji využít FlexiBee REST-API. Zde je totiž výhoda, že musíte uvádět jen minimum polí a FlexiBee si zbytek "domyslí".Můžete se rozhodnout co budete řešit v e-shopu a co budete řešit v účetnictví. Možností je mnoho. Můžete přenášet až faktury, které e-shop vytvořil, nebo si do FlexiBee nahrávat objednávky a fakturaci řešit tam. Z objednávky je možné vytvořit fakturu buď ručně nebo opět přes API. PDFko faktury je pak možné vracet do e-shopu.Je jen na Vás jakým způsobem bude celé propojení fungovat a jak rozsáhlé bude.

Pokial poznate dany ES od hlavy po paty, ako sa hovori, nie je to nezmysel. Je velmi odvazne toto tvrdit. Mam za sebou niekolko prepojeni priamo na databazu a vsetky riesenia su funkcne. Pracoval som 8 rokov na pozicii IT konzultant vo firme Stormware a mozem Vas ubezpecit ze tieto riesenia funguju.Da sa to aj all-in-one. Samozrejme, ze si to vyzaduje aj nejaky cas, peniaze, ale urcite to riesenie je potom dobre a neporuchove.Rozhodnutie je samozrejme na zakaznikovi.

Napsal stefantothml;1409291

Pokial poznate dany ES od hlavy po paty, ako sa hovori, nie je to nezmysel. Je velmi odvazne toto tvrdit. Mam za sebou niekolko prepojeni priamo na databazu a vsetky riesenia su funkcne. Pracoval som 8 rokov na pozicii IT konzultant vo firme Stormware a mozem Vas ubezpecit ze tieto riesenia funguju.

Myslim ze tu nikdo nepochybuje o funkcnosti reseni a tvoji znalosti systemu. Jde tu o riziko. Jak zajistis, ze nekdy v budoucnu, kdyz vyda Stormware novou verzi DB nedojde k poskozeni dat?

K poskodeniu nedojde. Na to je v stormware okrem programatorov aj analyticky tim, ktory velmi citlivo prebera kazdu jednu zmenu. Samozrejme, ze sa treba prisposobit od zaciatku databaze pohody, s tym suhlasim, ale ked sa to prvy krat spravi spravne, uz to bude stale spravne. Pohoda historicky neodmazava ani premenne, iba ich umrtvi, to znamena, ze maximalne bude ich zapis zbytocny ale priebezne sa doplnaju iba nove stlpce, ako napriklad KV DPH.

Napsal stefantothml;1409316

...priebezne sa doplnaju iba nove stlpce, ako napriklad KV DPH.

No a to je oč tu běží. To je problém zápisu do databáze. Musí se stále kontrolovat jestli nepřibylo nové pole. Pokud je dostupné API je to jinak. Vyplní se něco a API se pokusí vyplnit zbytek. Pokud to vyplňuje špatně, většinou je to jen špatně nastavené, ale do můstku nemusím šáhnout. Proto bude API lepší než jakýkoliv zápis do databáze.Je někde zdokumentováno databázové schéma Pohody?Kolik sloupců, které je nutné zohledňovat, doplnila Pohoda jen za poslední dva roky? KH DPH? EET?

Napsal CharlieB;1409412

No a to je oč tu běží. To je problém zápisu do databáze. Musí se stále kontrolovat jestli nepřibylo nové pole. Pokud je dostupné API je to jinak. Vyplní se něco a API se pokusí vyplnit zbytek. Pokud to vyplňuje špatně, většinou je to jen špatně nastavené, ale do můstku nemusím šáhnout. Proto bude API lepší než jakýkoliv zápis do databáze.

Je někde zdokumentováno databázové schéma Pohody?

Kolik sloupců, které je nutné zohledňovat, doplnila Pohoda jen za poslední dva roky? KH DPH? EET?

Lenze to je z pohladu vyvoja to iste, akokeby ste doplnali prave spominane KV DPH do API. Je jedno potom, ci sa Vam osobny konzultant stara o databazu, ktoru pozna ako vlastne dieta, alebo sa Vam iny programator stara o API, do ktoreho taktiez musi doplnat funkcnost. NIEKDE na nieco musi davat predsa pozor a nieco sa musi NIEKDE strazit. V mojom pripade to tje na strane ekonomickeho systemu, z Vasho pohladu na strane API.

Napsal stefantothml;1409463

Lenze to je z pohladu vyvoja to iste, akokeby ste doplnali prave spominane KV DPH do API. Je jedno potom, ci sa Vam osobny konzultant stara o databazu, ktoru pozna ako vlastne dieta, alebo sa Vam iny programator stara o API, do ktoreho taktiez musi doplnat funkcnost. NIEKDE na nieco musi davat predsa pozor a nieco sa musi NIEKDE strazit. V mojom pripade to tje na strane ekonomickeho systemu, z Vasho pohladu na strane API.

To same to neni. Kdyz se zmeni API a nevyplnim novy parameter nebo pribude nejake omezeni. Napr 3. parametetr muze byt max dvojnasobek 1. Tak api vyhodi chybu a nasledne resim upravu systemu. Do te chvile nic nemusim resit.Co se stane v pripade kdy to na tvrdo zapisuji do DB? Pribude podminka ze 3. sloupec muze byt max dvojnasobek 1. Bud to neresim jako u API a dozvim se o tom az se neco pokazi. Nebo potrebuji cloveka co pred kazdym upgradem pohody projde zmeny a zhodnoti jestli je potreba upravit system.

Napsal Pavel Cibulka;1409466

To same to neni. Kdyz se zmeni API a nevyplnim novy parameter nebo pribude nejake omezeni. Napr 3. parametetr muze byt max dvojnasobek 1. Tak api vyhodi chybu a nasledne resim upravu systemu. Do te chvile nic nemusim resit.

Co se stane v pripade kdy to na tvrdo zapisuji do DB? Pribude podminka ze 3. sloupec muze byt max dvojnasobek 1. Bud to neresim jako u API a dozvim se o tom az se neco pokazi. Nebo potrebuji cloveka co pred kazdym upgradem pohody projde zmeny a zhodnoti jestli je potreba upravit system.

Ved v poriadku ale v com je teda rozdiel ? :) ved ani pri importe a aktualizacii nemusim vyplnat ziadne povinne polia v databaze ako KV DPH, mozem ho vynechat. Neviem ake ES mate na mysli ale pohoda taketo problemy vobec nema, ze dvojnasobok parametra...taketo problemy proste nepoznam.