Phoca Cart - číslování faktur - MĚSÍČNĚ/ROČNĚ - FAKTURA na záladě statusu

Mám spíš obecný dotaz k číslování faktur. Posloupnost jsem si nastavil s OrderId. Mám ale problém se stornovanou fakturou a výpadku jednoho čísla v číslování faktur.

Buď to budu faktury vytvářet manualně a číslo faktury napíšu ručně podle předchozí.
nebo budu ručně vytvářet opravné daňové doklady k vydaným fakturám.
nebo k objednávce, faktuře a dodacímu listu automaticky generovat opravný daňový doklad? Nebo číslovat až dokončený faktury?

Což ani jedna z variant mě nepřijde úplně dobrá. Hledal jsem nějaký řešení jak to dělají ostatní a nenašel jsem nic.

Vše probíhá na základě "auto increment" - tedy databáze automaticky přidává nové číslo, pokud se nějaké smaže, není nahrazeno.

Představ si, že by jsi měl fakturu číslo 99, poté by jsi vytvořil dalších 100 faktur a poté by jsi stornoval fakturu číslo 85. Pokud by jsi chtěl zachovat posloupnost, znamenalo by to, že faktura č. 86 by byla 85, 87 by byla 86, atd. A takto by jsi přečíslovávál až do poslední faktury 199. Což asi nedává smysl.

Spíš bych volil nějaký storno doklad, vrubopis, dopropis, a podobné.

Jinak ano, faktury se v Phoca Cart dají číslovat manuálně, tedy pokud jich není hodně, lze to řešit i takto

Jasně tomu rozumím, používat čísla zpětné nelze kvůli zachování číselne řady a datumu.

Šlo mě jen o návrh zlepšení do dalších verzí. Kdyby se třeba faktury cislovaly podle poslední vydané faktury a faktury se vydali až po statusu dokončené. Ale jelikož jsem nikdy e-shop neměl a vydávám max 50 faktur měsíčně, tak to do teď dělám manuálně. Možná moc stresuju a těch storno objednávek před zaplacením bude minimum.

Není na to nějakej indentifokator jako {lastinvoicenumber} s tím, že by se faktura vystavila až po stavu dokončené. Pak by to sice nesedelo s číslem objednávky, ale těch opravných daňových dokladů by bylo jistě míň

Nic z toho není nutný, jen k zamyšlení.

Obecně je číslování faktur úplně jedno, jak jede. Nikde v zákoně není číslování nijak předepsáno, takže když si budete číslovat třeba 10, 20, 15, 18 je to úplně jedno, a dokud je faktura jednoznačně identifikována, nikdo nemůže nic říct (i když někteří auditoři jsou z toho běsní).

Osobně si myslím, že následující případ se v praxi stává často:

- vydám fakturu 00011
- poté fakturu 00012
- poté fakturu 00013

Se zákazníkem s fakturou 00012 se nějak nedohodnu a prostě nezbude nic jiného než fakturu zrušit/smazat.

Tím pádem vznikne "neposloupnost" ... faktury: 00010 00011 00013 00014

Pokud si člověk dá tuto informaci do účetnictví, a při nějaké kontrole prostě vysvětlí, proč daná faktura byla zrušena/smazána, nevidím v tom žádný problém.

Já sám jsem v zákonech nikde nenašel zmínku o posloupnosti, stejně tak jsem nikde u tvrzení o tom, že posloupnost je nutná, nenašel žádný odkaz na nějaký zákon. To samozřejmě ale neznamená, že takové ustanovení neexistuje. Pokud by někdo takové ustanovení znal, byl bych rád za odkaz.

číslovat lze opravdu libovolně a žádný zákon posloupnost neukládá. Ale musí v tom být vždy nějaká logika, aby bylo jasné, že nic nechybí nebo není duplicitní.

No já myslím, že zákon neukládá ani tu logiku Posloupnosti faktur z mé zkušenosti zkoumají jen auditoři, a chybějící čísla chtějí vysvětlit, ale jak píše H13, stačí jim to rozumně zdůvodnit a je to (krom nějakého storna to může být třeba i chybou databáze, programu apod...).

Některá účetnictví (tuším Pohoda) nabízejí při vytváření faktury možnost zaplnění takto vzniklých mezer v číslování. Osobně mi to přijde jako nesmysl (zas budu muset vysvětlovat, proč faktura 13 má datum o měsíc mladší než faktura 14) a hlavně nepoužitelný pro serverový víceuživatelský prostředí.

Problém se stornem faktur je ten, že nemůžete stornovat (smazat) fakturu, kterou jste pustili z ruky. Pak už jen dobropis (po novu opravný daňový doklad). Což se ale nikomu moc nechce dělat (nutnost potvrzování od zákazníka), tak se obvykle spolehne na to, že mu zákazník slíbí že fakturu roztrhá. Kdyby ale ne, tak se objeví v kontrolním hlášení u zákazníka a u vás ne, a hned máte na problém zaděláno...

Ale jestli nějaká auditovaná firma vede účetnictví ve Phoca Cart, tak klobouk dolu

Tak naštěstí mi ty objednávky nepřibývají moc rychle. Zatím teda ještě ani jedna. No neplánuju víc jak jednu denně, takže ty stornovaný objednávky zvládnu mazat ručně. Čím dřív tím líp. Tím se vyhnu většině problémů. A pak na klasicky storna po zaplacení musím stejně vydat opravný daňový doklad. Zase tak horký to nebude.

Kdyby tak ty stornovaný padali rovnou někam do koše, kde bych je mohl třeba do 14 dnů znovu obnovit, pokud by mi volal zákazník, že mu to nešlo a chce se přesto domluvit.

Jak již bylo napsáno. Nemazat faktury vydané!. Pak to bude asi o tom, jak před FÚ obhájíte, že faktura 00012 je smazaná, může pak FÚ doměřit nesmysly. Problém je ten, že vy řeknete příběh a druhá strana (stát) může a nemusí veřit.

Správná cesta by bylo vydávat zálohovou fakturu a tu pak konvertovat na klasický doklad. Jak už to tak bývá, je to komplikovaná cesta.

Idealni stav by tedy byl, po obdržení objednávky zaslat objednávku a zalohovou fakturu, po zaplacení poslat opravdovou fakturu a ještě v záloze mít někde vygenerovany opravný daňový doklad.

To je snad pro mě lepší to hned dostat do Excelu a jen měnit názvy dokumentů a pak to posílat ručně.

PhocaCart byl původně zamýšlen jako jednoduchá náhrada za VM a podobné molochy. Postupně se nám ale rozrůstá do velkých rozměrů . Nenuťte Honzu do něj ještě dodělávat kompletní účetnictví, EET, kontrolní hlášení a výkaz zisků a ztrát A to pro celý svět

Ok. Nikoho nenutím. Beru zpět.

Spíš je to na nějakej plugin, kde by to šlo i třeba editovat.

Za mou osobu, určitě nenabalovat funkce účetnictví.

Nabalovat to funkcemi pro účetnictví rozhodně nemá smysl, spíš bych byl rád, pokud někdo, kdo má zkušenosti s exportem do účetních programů jako je Pohoda (např. pokud to někdo vytvářel pro jiný eshop) by mohl spolupracovat na takovém pluginu pro Phoca Cart nebo ho případně vytvořil sám a pak ho zveřejnil (zdarma, placený, ...)