párování plateb v Pohodě

[okoun]

Ahoj, chtěl bych se zeptat těch co mají účetní program Pohoda, jak toto řeší. Vzhledem k tomu, že Pohodu používáme pár měsíců tak nevíme jak řešit nejlépe to, když nám někdo zaplatí paušál na internt měsíc dopředu či více měsíců, prostě k platbě ještě není vystavena faktura s kterou by se platba zlikvidovala. Ptám se na to proto, že je u nás celkm dost lidí co posílají peníze dříve než je faktura a bohužel nevím jak evidovat tyto přeplatky, aby se potom automaticky spárovaly s fakturama, vždy jsem je právě musel likvidovat ručně a to je nepříjemné a určitě při 1000 a více userů to bude časově dost náročné.

Děkuji

[Cheprer]

tak ja fa... vustavuji mezi 1-10 v mesici... a opravdu cca asi jeden klient kvuli tomu ze jsem ho uz asi 5x zariznul tak plati 2-5den v mesici.... takze vetsina plateb mi chodi v rozmezi 15-25dne v mesici a nemam s tim problem...

[svestka]

k přijaté platbě jsi povinen vystavit daňový doklad do 14 dnů od data přijetí platby
pohoda ale neumí (imho) vystavit doklad sama na základě údajů, co jí nacpe při importu banka, tedy z čísla účtu odesílatele, VS atd. si vydedukovat zákazníka, doplnit položky faktury atd ...

proto má většina z nás systém na míru, který kromě správy sítě a dohledu nad sítí si importuje platby z banky a páruje to s doklady (které umí sám vystavit). A pokud to pak ještě zpracovává účetní (třeba v Pohodě), posílají se jí XML, ať to tam nemusí bušit ručně.

[okoun]

systém na míru máme jenže systém přeci neúčtuje, to dělá Pohoda a jde o to, že Pohoda neumí párovat automaticky dodatečně a to nevím jak udělat, já tedy nevím jak by systém na míru mohl párovat, páruje se na základě výpisu z banky pomocí gpc, které se nahraje do Pohody

[Dalibor Toman]

systém na míru máme jenže systém přeci neúčtuje, to dělá Pohoda a jde o to, že Pohoda neumí párovat automaticky dodatečně a to nevím jak udělat, já tedy nevím jak by systém na míru mohl párovat, páruje se na základě výpisu z banky pomocí gpc, které se nahraje do Pohody

Pohodu pouzivame. Ale krome toho jeste mame okolo chytre skripty, ktere samy sparuji drtivou vetsinou plateb, pripadne vytvori zalohove faktury na platby prijate mimo poradi (kdyz je rozpoznan podle cisla uctu ci VS a dalsich kriterii konkretni zakaznik). Zakaznik muze plati navic jak se mu zachce, system mu sam z takto vznikleho kreditu ukrajuje pravidelnou mesicni fakturaci apod. Ale nejedna se o nic jednoduse prenositelneho k jinemu ISP. Vyladeni techle veci trvalo roky - zakaznici jsou pri platbach schopni neuveritelnych veci.

[zdenek.svarc]

Nevyžádané platby a na to navazující systém kreditu, o kterém píše Dalibor, je cesta. A že je to dlouhá cesta a mraky skriptů taktéž věřím, protože když jsme se k tomu rozhodovali u nás, Pohoda musela z kola ven. Po deseti letech. Protože dobu implementace jsme si stanovili na 6 až 8 týdnů a bez hromady skriptů, pouze API účetního systému + webhooks + radius SQL. V únoru na to vlítneme, o průběhu a výsledku budu informovat na Jezerce.

[okoun]

Aha, takže Pohoda je postě hloupej systém, který si s tím neporadí (zatím to tak vypadá), nevím tedy proč tu Pohodu všichny tak preferují. skoro každý snámější billing chce Pohodu či Helios, mám dojem že to tam nějak jde, ale zatím se nikdo nedoprátal jak.

[Viktor Novotný]

u nas tohle dela ucetni .. myslim, ze od toho proste je .. aby uctovala .. nikdy jsem se nezabyval tim, abych misto ni udelal nejaky stroj

[zdenek.svarc]

Proč mají billingové systémy jakous takous komunikaci s účetnictvím typu Stormware Pohoda je přece zřejmé. Je to jeden z nejrozšířenějších, ne-li nejrozšířenější účetní systém v ČR. Navzdory své uzavřenosti. Zkuste tedy vaší účetní říct, že od 1. ledna měníte Pohodu za Flexibee a hádejte, jak dopadnete. Předpokládám, že podobně jako my, takže máme od ledna nejen nový účetní systém, ale taky účetní personál. Málokdo má na takovou změnu koule, takže raději přizpůsobí billing a místo komunikace v reálném čase (tím nemyslím průmyslový reálný čas) používá obezličky a dávkové synchronizace s menší či větší mírou ruční práce. A tím se dostáváme k tomu "nějak to funguje" vs funguje.

Ano účetní je od toho, aby účtovala. Párování plateb a řešení neplatičů není účetničina. To je práce za trest. Takže pokud tohle nepořešíme na systémové úrovni, mmte problém úměrně velký počtu zákazníků.

[hapi]

Ano účetní je od toho, aby účtovala. Párování plateb a řešení neplatičů není účetničina. To je práce za trest. Takže pokud tohle nepořešíte na systémové úrovni, máte problém úměrně velký počtu zákazníků.

na to je fakturantka.

je zajímavý že noISPíci maji hafo fakturantek ale takovej ISPík nemá ani jednu. Nějak si nevzpomínám že by někdo jiný kromě ISPíků měl nějakej vymakanej billingovej systém. Všude to řeší fakturantky včetně těch kravinek co řeší okoun.

[Dalibor Toman]

Nevyžádané platby a na to navazující systém kreditu, o kterém píše Dalibor, je cesta. A že je to dlouhá cesta a mraky skriptů taktéž věřím, protože když jsme se k tomu rozhodovali u nás, Pohoda musela z kola ven. Po deseti letech. Protože dobu implementace jsme si stanovili na 6 až 8 týdnů a bez hromady skriptů, pouze API účetního systému + webhooks + radius SQL. V únoru na to vlítneme, o průběhu a výsledku budu informovat na Jezerce.

ja to neimplementoval ale IMHO neni problem s Pohodou - skripty se hrabou v SQL databazi Pohohody (vyhybali jsme se cemukoliv, co je moc zavisle na verzi Pohody a co by mohlo komplikovat upgrade Pohody apod) a tu ani moc nepotrebuji. Hlavni problem je v analyze pozadavku. Vlastni skript je hotovy za 'chvilku', problem je ale odladeni vsech moznych necekanych jevu, ktere Te tezko napadnou pri analyze. A bez prusvihu se to neobejde...
Ve vysledku ale ucetni rucne paruji jen minimum plateb (kdyz nekdo zaplati z cisla uctu pro ktery nemame zadnou historii a zvrzne VS, kdyz nekdo plati vice pripojeni jednim uctem a VS nesedi , mozna nejake platby slozenkou atd)

[Dalibor Toman]

je zajímavý že noISPíci maji hafo fakturantek ale takovej ISPík nemá ani jednu. Nějak si nevzpomínám že by někdo jiný kromě ISPíků měl nějakej vymakanej billingovej systém. Všude to řeší fakturantky včetně těch kravinek co řeší okoun.

IMHO to bude tim, ze spousta firem nema takove mnozstvi zakazniku, kteri navic jeste pravidelne plati. U neopakujicih se plateb neni tolik prostoru pro automatizaci.
Rozhodne mi prijde vyhodnejsi investovat nejake penize do vyvoje software, ktery usetri pracovni silu (vcetne zazemi pro ni) a navic vim, ze je to sparovane par minut po tom, co se stahne vypis a jeste ke vsemu bez chyb.

Navic na platby mame navazany automaticky system restrikci pripojeni (snizeni rychlosti az uplne odstrihnuti vcetne rozesilani upozorneni), takze je nanejvys potreba, aby parovani plateb probihalo rychle a nezavisle na tom jestli nejaka fakturantka ma zrovna naladu ci je nemocna/na dovolene.

[hapi]

mají nemaji, co taková firma co vlastní obchodní domy a vystavuje pravidelně faktury. Nijak to neřeší, řeší to fakturantky.

já si s pohodou hrál a nechápu to hrabání se v databázi pohody. Pohoda má "docela" slušnou XML komunikaci téměř na všechno. No ale jako chápu proč to tak máte. Něco prostě nějak udělat nejde ale to je spíš o tom co si necháte od zákazníků líbit.

[Viktor Novotný]

tak tak, firmy treba co pronajimaji byty a to po tisicich bytu ( rpg treba )... taky maji lidi na papiry

[Dalibor Toman]

tak tak, firmy treba co pronajimaji byty a to po tisicich bytu ( rpg treba )... taky maji lidi na papiry

jednak mozna ty lidi ve skutecnosti delaji neco jineho nez paruji platby (ja u nich nikdy v uctarne nebyl, ty jo ?), mozna taky stoji najem bytu vic nez 300Kc mesicne ...