Ekonomika

Ú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 žádný lepší a jednodušší systém vnitřní evidence financí pro firmy nevymyslel.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č    __________________|  Členské příspěvky   | ---------->|Kredit Franta Šiška ||______________________|            |____________________|K čemu je úč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

1. podúčet standardního účtu "Členské příspěvky" (standardní číslo v účetní osnově = 684000)
2. 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) neobsahuje.Podrobnější výklad  najdete v této prezentaci:

• formát ODP
• formát PDF

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:

• Příprava pro import dat
• HTML Parser pro ebanku
• CSV Parser
• Ukládání dat do databáze