Projekt

Obecné

Profil

Požadavek #981

Aktualizováno uživatelem Ondřej Fibich před asi 9 roky(ů)

Přiřazení neidentifikovatelné platby na libovolný účet se správným pořadím podvodných převodů. 

 h2. Analýza 

 Neidentifikované převody lze rozdělit do následujících kategorií: 

 # Jedná se o platbu za členský příspěvek s chybně uvedeným nebo neuvedeným VS (nejčastější případ). 
 # Jedná se o úrok (plusový). 
 # Jedná se o úrok z termínovaného vkladu. 
 # Jedná se o stažení peněz z termínovaného vkladu (KS = 968). 
 # Jedná se o vklad peněz na účet sdružení. 
 # Jedná se o dobropis. 
 # ... 

 h2. Současný stav 

 Pokud se při import bankovních výpisů narazí na neidentifikovanou platbu vytvoří se vždy převod (neuvažuji zde transakční poplatky, pokuty a jiné nepodstatné náležitosti tohoto typu přiřazení platby): 

 @[684000 (Member fees)] ---> [221000 (Bank)]@ 

 a kvůli předpokladu, že neidentifikovaný převod je platba za členský příspěvek. Následně totiž pro přiřazení stačí vytvořit převod: 

 @[221000 (Bank)] ---> [221100 (Credit - member)]@ 

 Zároveň je také jednoduché v DB vyhledávat nespárované převody, což by se jinak muselo dělat na úrovni bankovních převodů (to by možná bylo i rozumnější). 
 *Problém* ale spočívá v tom, že pokud se nejedná o neidentifikovaný převod v kategorii 1., je nutné předvytvořený převod smazat, jelikož peníze nepochází z @684000 (Member fees)@. 
 Z tohoto důvodu je chybé řešení z #897, které vytvoří převod z původního převodu např. na provozní účet. 

 h2. Návrh 

 I když by bylo nejlepší zaznamenávat neidentifikované převody na úrovni bankovních převodů, je to vzhledem k nutnému zásahu v DB pro verzi 1.1.10 nepřijatelné. 
 Bude se tedy vycházet ze současného stavu DB a pokud se nebude jednat o převod z kategorie 1., provede se odstranění chybného převodu + přepočítání zůstatků dotčených účtů (pozn. smazání převodu lze nahradit jeho editací kdy se mění jeho zdrojový účet a text). účtů. 

 h3. Způsob řešení jednotlivých kategorií 

 # _Stejně jako dříve_ 
 # Převod z @[644000 (Bank interests)] ---> [221000 (Bank)]@ 
 # Převod z @[655000 (Time deposit interests)] ---> [221000 (Bank)]@ 
 # Převod z @[259000 (Time deposit)] ---> [221000 (Bank)]@ 
 # Převod z @[211000 (Cash)] ---> [221000 (Bank)]@ 
 # Převod z @[321000 (Suppliers)] ---> [221000 (Bank)]@ (tedy dobropis nuluje fakturu, která byla dříve zaplacena) 
 # ... 

 Pokud je potřeba přidat nějaký následný převoz z @[221000 (Bank)]@, lze tak učinit následně z "transfers/add_from_account". 

 h2. Implementace 

 Z pohledu UI je efektivní formulář rozdělit na dvě sekce. První sekce by obsahovala původní formulář (z verze 1.1, ne Davidovu variantu z 1.2) pro spárování členského platby a druhá část by umožnila řešit všechny ostatní případy. 

 Řešení ostatních případů je dle návrhu vlastně jen výběr zdrojového účtu, který není typu 221000 (Bank), 221100 (Credit), 684000 (Member fees) a 549001 (Bank fees).

Zpět