Ekonomika
Obsah
Úvod
Evidence členských příspěvků je typická úloha pro podvojné účetnictví. Proč?Protože od 12.-13. století, kdy se podvojné účto poprvé objevuje v písemných zmínkách, ještě nikdo nevymyslel žádný lepší a jednodušší systém vnitřní evidence financí pro jakýkoli subjekt (živnostník, neziskovka, s.r.o nebo univerzita...).
Princip podvojného účetnictví je opravdu triviální: o každé finanční operaci si pořizujete záznam ve tvaru
______________________ částka ____________________ |zdrojový podvojný účet| ---------->|cílový podvojný účet| |______________________| |____________________|
Např. když Franta Šiška pošle sdružení částku 1000 Kč, lze to podvojně zaúčtovat takto:
______________________ 1000 Kč ____________________ | Franta Šiška | ---------->| náš bankovní účet | |______________________| |____________________|
anebo třeba takto:
______________________ 1000 Kč ____________________ | Členské příspěvky | ---------->|Kredit Franta Šiška | |______________________| |____________________|
Poznámka: k čemu je ve druhém způsobu účet "Členské příspěvky"?
Peníze v podvojném účtu nemůžou přitéct "odnikud", na obou stranách šipky musí být nějaké účty.
Výhoda tohoto je v tom, že když budeme všechny členské příspěvky převádět z jednoho účtu "Členské příspěvky", bude nám okamžitý stav tohoto účtu říkat, kolik členských příspěvků už jsmevybrali. Což se určitě hodí!
DB Schema
Podvojné účty si můžeme v podvojném účetnictví tvořit dle vlastní libovůle.
Příklad: chceme zjistit, kolik utrácíme za UTP kabely. Vytvoříme si proto účet "UTP kabely" a na něj budeme převádět částku z každého nákupu UTP kabelu.
Ve Freenetisu jsou podvojné účty, které naše organizace používá, uloženy v tabulce accounts.
Po instalaci Freenetisu tabulka accounts obsahuje jenom cca 5 účtů, ale s postupem času jejich počet roste, protože každý platící člen má automaticky vytvořen "svůj" podvojný účet, na kterém ukládáme jeho kredit.
Ve Freenetisu může člen mít přiřazeny i další podvojné účty - to jsou účty projektů, ale o tom někdy příště.
Převody mezi podvojnými účty jsou v tabulce transfers.Její sloupce jsou:
- origin_id, destination_id : id podvojných účtů z tabulky accounts
- previous_transfer_id : používá se u složitějších podvojných transakcí, které se skládají z více podvojných převodů. Např. zaúčtování faktury se standardně dělá 2ma transakcemi. Aby bylo jasné, že tyto 2 transakce "patří k sobě", nastavíme u té druhé previous_transfer_id tak, aby ukazovalo na tu první transakci.
- member_id : u platby příspěvku je zde ID člena, od něhož transakce pochází. Může se zdát, že tento sloupec je zbytečný, protože peníze přece putují na kreditní účet člena a ten má také údaj member_id. Ale držet si member_id i v tabulce transfers je výhodné při více-krokových převodech. Např. zaúčtování platby členského příspěvku v našem sdružení děláme v 5ti podvojných převodech, z nichž jen jeden cílí na kreditní účet člena. My ale chceme jednoduše vidět, že i ty ostatní převody "způsobil" tento daný člen - mohli bychom to sice složitě odvodit přes previous_transfer_id, ale ten dotaz, to by byla šílenost.
- user_id : id uživatele, který podvojný převod vytvořil. Ve freenetisu můžete právo přístupu k ekonomické části přidělit více lidem, takže je potřeba vědět, kdo z nich daný převod spáchal.
- type: 1=stržení pravidelného měsíčního příspěvku, 2=vstupní příspěvek, 4=dobití VOIP kreditu, ...
- datetime: datum a čas účetního případu. Např. u řádku bankovního výpisu se zde bere datum a čas tohoto řádku. U faktury zde bude datum zdanitelného plnění.
- creation_datetime: datum a čas, kdy byl převod zadán do Freenetisu
- text, amount - popis platby a částka
Pozn. pro znalce podvojného účetnictví: tabulka transfers je vlastně obyčejný účetní deník - stejný, jaký si můj děda před 50ti lety vedl v papírové podobě...
Tabulka account_attributes
Když už tedy podvojně účtujeme, je dobrý nápad mít naše podvojné účty "kompatibilní" s legislativou našeho státu.
Pak může stavy podvojných účtů ve Freenetisu okamžitě začít využívat pan(í) účetní naší organizace, protože mu (jí) to ušetří spoustu práce.
Abychom dosáhli kombatibilitu s legislativou, musíme ke každému našemu podvojnímu účtu najít nějaký standardní účet dle legislativy.
Standardní účty legislativa definuje ve formě tzv. účetní osnovy (angličani mají lepší termín: chart of accounts).
Účetní osnova je seznam možných podvojných účtů pro daný typ organizace. U každého účtu je v účetní osnově definován jeho standardní název, standardní číslo a další atributy.
Účetní osnova vypadá nějak pro neziskovky, trochu jinak pro podnikatelské subjekty, trochu jinak pro státní správu.
Ve Freenetis-u je účetní osnova uložena v tabulce account_attributes, a to jako účetní osnova pro neziskovky. Jiné typy účetních osnov (např. podnikatelské) by řešil instalátor Freenetis-u, ale zatím to nikdo nechtěl.
Nás asi nejvíc zajímá, na který standardní podvojný účet budeme mapovat kreditní účty členů?
Podvojný účet kreditu člena můžeme dle účetní osnovy pro neziskovky implementovat buď jako
- podúčet standardního účtu "Členské příspěvky" (standardní číslo v účetní osnově = 684000)
- podúčet standardního účtu "Účty v bankách" (číslo 221000)
Ve Freenetisu používáme 2. variantu, protože je stejná pro neziskovky i pro jiné subjekty, jejichž účetní osnova žádné členské příspěvky (684000) nezná.
Podrobnější výklad najdete v této prezentaci:
Na slajdu 13 je ukázán způsob, jakým členské příspěvky účtujeme v UnArtu my (při importu z Ebanky).
Evidence bankovních účtů
Narozdíl od běžných účetních systémů (Pohoda, Money S3), má Freenetis dokonalejší evidenci bankovních účtů členů - Freenetis umožňuje evidovat u každého člena až N jeho bankovních účtů. To nám velmi často pomáhá při identifikaci platby se špatným variabilem - přestože spousta členů(=rodin) platí z bankovního účtu manželky, který nese její dívčí příjmení (odlišné od příjmení rodiny), jsme schopni díky evidenci bankovních účtů okamžitě poznat, který člen je původcem takové platby.
Bankovní účty evidujeme v tabulce bank_accounts.
Po instalaci Freenetisu zde bude pouze bankovní účet sdružení.
Další bankovní účty členů automaticky vytváří importer z ebanky. U plateb, které mají správný variabil, také importer nově vytvářenému bank. účtu automaticky přiřadí majitele.
Pokud chcete importovat bankovní výpisy ze zdroje, který bankovní účty neobsahuje, pak budete muset v tabulce "bank_accounts" vytvořit účet "NEIDENTIFIKOVANY"
Proč? Viz další kapitola:
Evidence bankovních výpisů
Bankovní výpisy evidujeme v tabulce bank_statement.
Každý bankovní výpis sestává z mnoha bankovních transakcí. Bankovní transakce jsou převody mezi bankovními účty. Proto je evidujeme podobně, jako převody mezi podvojnými účty - pomocí tabulky bank_transfers, která obsahuje následující sloupce:
- origin_id, destination_id : id bankovních účtů z tabulky bank_accounts
- transfer_id : id podvojného převodu z tabulky transfers. Každý bankovní převod by měl být podvojně zaúčtovaný, tj. odkazovat na některý podvojný převod. Pokud byste některé bankovní převody nezaúčtovali, vznikne účetní chyba - stav podvojného účtu "bankovní účet" nebude sedět se skutečným stavem bankovního účtu
- bank_statement_id : odkaz do tabulky bank
- number: Line number or number of the bank listing item
- variable_symbol, constant_symbol, specific_symbol - to je asi jasné
- comment - případný komentář účetního k dané platbě
Datum, čas a text platby jsme se rozhodli evidovat ne v této tabulce, ale v tabulce transfers - protože každý bank_transfer má vždy přiřazen jeden transfer, byly by stejnomenné sloupce v tabulce bank_transfers redundantní.
Terminologie
- V kódu se používá směska anglické "polopatické" a oficiální účetní terminologie.
- Oficiální anglická a jí odpovídající česká účetní terminologie je popsána
- V tomto slovníčku
- v PhD práci Radka Vogela z MUNI Brno.
Import výpisů z banky
Freenetis momentálně umí importovat HTML výpisy z ebanky/Raiffeisen banky a výpisy v libovolném CSV formátu. Největší díl práce v této oblasti představují parsery - především HTML parser ebanky. Proto jsou parsery napsány tak, aby neměly žádnou závislost na frameworku Kohana ani na Freenetisu - jsou to naprosto samostatné knihovny.
Popis implementace je v následujících článcích:
