Jednoduche double-entry sledovanie transakcii v marketplace

[hknmtt]

Robim na projekte typu marketplace kde mi uzivatelia poslu peniaze, dobiju si tak ucet/penazenku, zaplatia inym uzivatelom za sluzby a tyto si potom peniaze zase vytiahnu, minus poplatok za sluzbu.

Rozmyslal som nad viacerymi sposobmi ako sledovat financie a zatial som dospel k niecomu podobnemu double-entry uctovaniu.

Prakticky v systeme bude mat kazdy uzivatel penazenku. Mimo toho budu v systeme dalsie dve penazenky - revenues a liabilities(nechavam anglicke vyrazy pre lahsie pochopenie).

Proces by bol nasledovny:

Uzivatel #1 si dobije penazenku tym ze zaplati kartou alebo mi posle peniaze na ucet v banke a ja do systemu tuto platbu zanesiem nasledovne:

Kód: [Vybrat]

CREDIT 100 Liabilities Wallet
DEBIT  100 Wallet #1

Uzivatel #1 potom zaplati Uzivatel #2 za nejaku sluzbu

Kód: [Vybrat]

CREDIT 100 Wallet #1
DEBIT  100 Wallet #2

Uzivatel #2 si vyberie zarobene peniaze(ktore mu poslem na ucet v banke)

Kód: [Vybrat]

CREDIT 80 Wallet #2
DEBIT  80 Liabilities Wallet

Ja si vezmem proviziu

Kód: [Vybrat]

CREDIT 20 Wallet #2
DEBIT  20 Revenues Wallet

V systeme mam ale stale navyse $20, takze system nie je vyrovnany(balanced), takze ja si vytiahnem peniaze z penazenky a poslem ich sebe na ucet

Kód: [Vybrat]

CREDIT 20 Revenues Wallet
DEBIT  20 Liabilities Wallet

A system je teraz vyrovnany. Ked chcem vidiet kolko penazi je v systeme, tak si vezmem liabilities-revenues.

Kazda transakcia ma dve platby - z uctu z ktoreho peniaze idu ako CREDIT a na ucet kam peniaze idu ako DEBIT.

Penazenka liabilities teda funguje akoby most medzi aplikaciou a vonkajsim svetom cez ktory prudia peniaze dnu a von.

Penazenka liabilities dostava CREDIT pri vklade penazi pretoze uzivatel dostava DEBIT na svoju penazenku, plus pre mna tieto peniaze su naozaj liability(riziko), pretoze som za ne zodpovedny.

Nejake poznamky, pripadne ine riesenie?

[Reklama]

[_Tomáš_]

chtěl bych vidět ER diagram tvého db modelu.

Vymýšlíte kolo. Zkoušeli jste sehnat někoho, kdo má zkušenosti s návrhem třeba z bankovního prostředí? Těch lidí jsou mraky.

Udělej si 100000 uživatelů a každého s 10000 transakcemi, pak ten systém laď a vymýšlej model, uvidíš, kde máš slabá místa. Stejně tak mysli na to, že občas budeš nucen udělat ruční zásah zpět do historii a nutnost celý strom závislých transakcí přepočítat.

Další sranda je při obnově, při testech nezapomeň si pravidelně sestřelovat databázi a zkoušet se dostat zpět do konzistentního stavu.

[Filip Jirsák]

To, co zkoušíte vymyslet, se jmenuje podvojné účetnictví. Používá se to už asi 800 let. Nevymýšlejte to znova, nevymyslíte to lépe – prostě si jen nastudujte, jak podvojné účetnictví funguje, a to pak implementujte.

[RDa]

Tvuj pristup je prilis akademicky - v praxi narazis pak na to, ze ti bude chybet nektery radek z paru ktery tvori prevod, takze vznikne nekonzistentni system a budes tezko hledat co se ztratilo.

Muj pristup (kdyz jsem delal vlastni sw na ucto) je tento:

TABLE users - id, .... ;
TABLE accounts - userid, typ, nazev-cislo;
TABLE transfers - src, dst, amount;

Kazdy uzivatel (u me subjekt) ma evidovany jeden nebo vicero uctu - uctem se mysli reference na externi ucet (lokalni, mezinarodni, paypal), pripadne docasne ucty - u tebe to jsou interni stavy.

V tabulce prevodu pak mas prevody mezi dvouma* uctama. At uz se jedna o externi platby (dobiti, vyplata), nebo interni platby (za zbozi a provize). *Ve tvem pripade bych se nebal to rozsirit na tristranny prevod 1-na-2 (platba na prijem a provize), udelat to sumarizaci slozitejsi, ale zas se nemusis starat o transakce a rollback pri castecnem selhani. V pripade potreby multi-menove obsluhy je potreba mit alespon 4 sloupce u transferu - zdrojova/cilova castka/mena (a dalsi metadata jako kurz, datum, puvod kurzu). Ja tam mam i reference na radek bankovniho vypisu (paypal, fio) pro snazsi trasovani.

Z takoveho modelu muzes vzdy nechat spocitat balance na kazdem uctu (a v kazde mene), pro kazdeho cloveka. Vse, co mas vedeno jako interni ucet, si pak muze nekdo z uzivatelu narokovat.

Pro pripad rucnich kompenzaci si samozrejme musis zalozit vlastniho uzivatele, s uctem, nabit ho z externiho, a pak delat az kompenzaci. Pripadne nabit muzes i dodatecne, pokud akceptujes zaporny zustatek u sebe.

[hknmtt]

Neviem ci len RDA alebo vseci ste asi zle pochopili - ja tu neriesim realne peniaze a pohyby na uctoch. Len virtualne sledovanie kto ma kolko "kreditov" v mojom systeme.

[Reklama]

[Filip Jirsák]

Neviem ci len RDA alebo vseci ste asi zle pochopili - ja tu neriesim realne peniaze a pohyby na uctoch. Len virtualne sledovanie kto ma kolko "kreditov" v mojom systeme.

Je úplně jedno, jestli tomu říkáte peníze, koruny nebo kredity, princip je pořád stejný.

[Wangarad]

hknmtt : no bud si to zle vysvetlil ked to vsetci chapu inak alebo je to jednoduche podvojne uctovnictvo ktore sa snazis znova vymysliet. A je jedno ci je to sukromny system na korunky/kredity/eura

[Karmelos]

Neviem ci len RDA alebo vseci ste asi zle pochopili - ja tu neriesim realne peniaze a pohyby na uctoch. Len virtualne sledovanie kto ma kolko "kreditov" v mojom systeme.

jakože ty vaše revenues a liabilities jsou jen jine formy účtu tedy wallet -  akorátže ta vstupní peněženka bude asi pořád v mínusu a ta výstupní peněženka pořád v plusu a podle mě je blbost se okrádat o možnost převodu ze svého "výstupního" účtu na jiný účet v systému.
 
Ten příklad od Jirsáka s podvojným účetnictvím je dobrý, možná ale že pro vás bude zajímavější nastudovat účetnictví potrojné :-)

[Vietnamka]

Taková maličkost, co jsou ty dvojitý entry?

[Filip Jirsák]

Taková maličkost, co jsou ty dvojitý entry?

Účet, který má dvě strany, v češtině označované Má dáti a Dal.

[RDa]

Neviem ci len RDA alebo vseci ste asi zle pochopili - ja tu neriesim realne peniaze a pohyby na uctoch. Len virtualne sledovanie kto ma kolko "kreditov" v mojom systeme.

V tom pripade pro tebe navic plati ta ma rozsirena konstrukce s ruznymi menami - at je vetsina internich transakci v "kreditech", ale i/o s bankama pak v realnych menach. Jestli jsi nekdy pouzival PayPal, tak tam to meli hezky udelany ty konverze - v podstate to je transakce v ramci stejneho uctu, jen mezi jinymi menami. Tohle umim presne i ja, ale casteji ke konverzi pouzivam individualni virtualni ucet ("hromadku") pro dany pripad - protoze pak tam muzu nacpat volitelne i zisk/ztratu nebo provizi.

Uzivatel #1 si dobije penazenku tym ze zaplati kartou alebo mi posle peniaze na ucet v banke a ja do systemu tuto platbu zanesiem nasledovne:

A proc to nesledovat vcetne techto vstupu? (a predpokladam ze analogicky i vystupu)

[yossy]

na tento use case je uplne vyhovujuci https://www.ledger-cli.org, pripadne niektory z jeho klonov uvedenych na stranke https://plaintextaccounting.org

[Filip Jirsák]

Mohlo by vás zajímat: https://beancount.github.io/docs/the_double_entry_counting_method.html