Dotaz na Viktora: kdyz mali zakaznici plati pravidelne, tak jak poznate, ze nezaplatil? V podstate jde o to stejne - je potreba prichozi platbu sparovat s nejakym predpisem pro platbu, at uz to nazyvam fakturou nebo jen fiktivni vyzvou/pravidelnym terminem pro platbu.
Pro Zdenka: ono i obycejna Pohoda je docela dobre scriptovatelna, protoze vyuziva jako svou databazi Access soubory a do tech jde pristupovat pres ODBC. Mozna bych se pokusil polemizovat i s Tvym nazorem na to, ze Pohoda je uzavreny system. Na svych strankach tvrdi, ze je Pohoda vhodna i pro dodelavana reseni.
Zkusim lehce rozvest co tady nastinil o nasem systemu Dalibor:
Pro ucetnictvi pouzivame Pohodu, aktualne v SQL verzi, ale zacinali jsme s normalni verzi s access databazi, pro prechod na SQL nas donutila pomalost Pohody pri praci v ni.
Pro billing, vystavovani faktur podle zvoleneho tarifu, pripadne blokovani neplaticu pouzivame system, ktery nema s Pohodu nic spolecneho. Teda krome dat o fakturach a to, zda jsou zaplacene. A opacne, vystavene faktury v billing systemu se automaticky nacpou do Pohody. Podle me delat jednu obludu, ve ktere by se sledovali zakaznici a zaroven se v tom uctovalo, je cesta do pekla.
Faktury se vystavi billingovym system, ktery si je udrzuje ve svych SQL tabulkach, scriptem se tyto data nactou a v Pohode primym zapisem do tabulek vytvori faktury vcetne ciselnych rad, zakladniho zauctovani v podvojnem ucetnictvi. Takto vytvorene faktury je mozne samozrejme primo v Pohode pohodlne editovat atd. Dalsim krokem je pravidelna aktualizace faktur z Pohody zpatky do billing systemu uz vcetne informace o zaplaceni popr. provedenych zmenach. Tohle vsechno delaji scripty pravidelne a spolehlive.
Parovani plateb s jiz vystavenou fakturou muze byt provedeno nekolika zpusoby:
1. vystavena faktura a nasledna platba se spravnym variabilnim symbolem - toto sparuje Pohoda primo primo sama (jsou samozrejme male nuance, kdyz zakaznik zaplati vic, tak u platby zustava preplatek, ktery je potreba doresit dal apod.)
2. FA a platba bez spravneho VS - automaticky se dohleda podle cisla uctu odkud platba prisla komu to patri a platba se sparuje s jiz vystavenou fakturou
3. zakaznik zaplati i kdyz nema vystavenou FA, na toto mame pro kazdeho zakaznika jeho jedinecny VS, na takovoutou platbu se vystavi danovy doklad neboli FA, ktera je oznacena jako zaloha na sluzby. Pripadne zaplati s VS jiz davno zaplacene FA nebo i s uplne jinym nebo zadnym VS. Povetsinou zafunguje dohledani zakaznika podle cisla uctu u jeho ostatnich plateb.
4. Pak jsou samozrejme kombinace bodu 1-3 s variacemi, ze zakaznik zaplati jednou platbou nekolik faktur najednou, pripadne nekolika platbami jednu fakturu, ruzne castecne uhrady dnes, kdy zbyva k uhrade faktury nejaka castka, kterou doplati priste soucasne s platbou jine faktury a pod.
5. Pak dalsi veci jako zpracovani hromadne zaslanych slozenek jednou platbou, prijem plateb pres SuperCash, SIPO apod.
Ucetni tak zustava k dohledani pouze, kdyz zakaznik zaplati slozenim na pokladne banky bez uvedeni spravneho VS FA, pripadne kdyz zaplati se spatnym VS platbu a neda se dohledat ani podel uctu, protoze z nej jeste neplatil (prvni platba nebo plati z jineho uctu). Tohle ma jeste jednu krasnou vlastnost, ze kdyz zaplati dalsi platbu spravne, tak se hned na to spravne urci i ta drivejsi platba a sparuje.
Jinak vse co je potreba v Pohode vytvaret, pripadne z ni brat, tak se odkazuje na par tabulek v databazi Pohody, Pohodu a scripty nad ni pouzivame uz cca 12let a doposud nebyl zasadni problem ze by doslo k zmene struktury tak, ze by bylo nutne vse predelat.
Predpokladam, ze Zdenek bude mit lehkou vyhodu v napojeni na jeho novy ucetni system, protoze to ma nejaky dokumentovany interface, ale programovat bude muset zrejme sam nebo si to zaplatit. Navic dalsi naklady na to, aby se lidi naucili novy ucetni system.
