Construire une application de comptabilité rudimentaire

Question

Je construis une application de comptabilité simple à utiliser pour les finances personnelles.

Un utilisateur peut suivre les achats, les factures à venir, les dépôts récurrents, etc. Ce sera vraiment simple.

Deux questions:

1) Quel conseil dois-je garder à l'esprit? Évidemment, j'utiliserai des transactions le cas échéant, mais il serait bon de connaître les types de données appropriés et d'autres considérations.

2) Connaissez-vous des API que je pourrais utiliser pour obtenir périodiquement le solde d'un utilisateur de sa banque? c’est-à-dire une API qui faciliterait l’interrogation de leur compte, qu’ils soient chez Chase, BofA ou autre?

Merci beaucoup,

Michael

Answer 1

Je viens de terminer la version 1.0 de certains logiciels de comptabilité en ligne personnalisés pour les organisations à but non lucratif liées aux écoles.

• Utilisez la comptabilité / comptabilité en partie double standard (débits et crédits) comme base de votre moteur financier. Vous constaterez que cela vous sera utile lorsqu'il s'agira non seulement de stocker des données sur des transactions, mais également de générer des rapports. Actif = Passif + Équité est une approche éprouvée pour déterminer qui possède quoi.
• Utilisez des types décimaux pour de l'argent.
• Utiliser les transactions.
• Maintenez l'interface aussi simple que possible possible.
• Vous aurez besoin d'une méthode pour permettre à l'utilisateur de rapprocher la banque enregistrements avec leurs propres enregistrements. Tirer des données bancaires aiderait cela processus, mais vous devrez fournir l'utilisateur avec une méthode pour comparer. Vous pouvez utiliser les relevés bancaires pour cela processus.
• La banque est toujours considérée comme ayant raison. S'il y a un écart entre la banque et l'utilisateur enregistre ... le la faute est presque toujours avec l'utilisateur enregistrements.
• Assurez-vous de fournir une sorte de fonction de sauvegarde pour l'utilisateur
• Sécuriser les données des utilisateurs
• Assurez-vous de bien comprendre le processus que vous automatisez. Ne faites pas de suppositions. Exécutez vos idées par un comptable spécialisé dans les finances personnelles. Avoir cette vérification aidera un peu.
• Soyez prêt à écrire BEAUCOUP de code. Le logiciel de comptabilité existe depuis des années, la liste des "fonctionnalités standard" " pour un logiciel de comptabilité typique a augmenté, et il y a assez peu d'acteurs sur le marché Si vous envisagez de vendre ce produit, vous devez fournir ces fonctionnalités standard, puis trouver un moyen de le différencier de ce qui est déjà disponible avec des fonctionnalités supplémentaires.
• TEST TEST TEST et TEST à nouveau. Vous tiennent des registres des peuples transactions financières personnelles (leur argent). Les erreurs ne sont pas prises légèrement.

Answer 2

I will add a few tips as I am finishing a POS system that focuses on ACCOUNTING - meaning the purchases, expenses, invoicing, accounts, credit cards, cash, vehicles, etc all need to be tracked. The concepts will eventually be applied to a personal system.

The best advice is to look at your paperwork and try to form your database around what you need to do to translate your physical documents to the computer. Combine this with the first couple of chapters of an accounting textbook which talks about accounts, chart of accounts, and journals.

The books I used : Accounting at your fingertips by George Murray Finance and Accounting for Entrepenuers by Suzanne Caplan Introduction To Accounting by Ainsworth Accounting, Information technology, and Business Solutions By Hollander

Once you have your source documents entered into the system you can then run queries to get to your answers. Doing this eliminated the concept of the "General Ledger" and "trial balance" because you simply correct or add to your source documents. So the "General Ledger" becomes a calculation. That was super confusing to me. Again, all the source documents will be put into 'Journals', which can be your database tables. I use a general journal, a purchases journal, a payments or cash disbursements journal, a sales journal, and a cash receipts journal. Keep in mind the term "CASH" refers to cash, credit, check, debit.

For example I have a "general journal" which is basically what you need. In this journal I keep track of 'source receipts'. A receipt might be an invoice, like time warner cable, which has an account number. In that case I create an 'account' for time warner. The time warner account will link to a 'chart of accounts' which will specify the type of expense as "internet". The invoice then gets entered with the date, the amount, etc. The invoice links to the account for time warner. Once the invoice is entered it is unpaid. You then need to add payment. Of course you could pay the bill in full as you should, but you might need to do two payments, or split payments, or not pay in full. This will lead you to a 'Payments Journal" in combination with a 'invoice to payments lookup table' which will need to have an applied amount to apply to an invoice. This applied amount is important because you might have 4 unpaid time warner bills and you just send over $200 in a panic to get your account back on. This payment then needs to split across the invoices with amounts to apply to each. And of course the payment account will link back to your accounts.

For the case of entering a receipt, the account is not used. Say you pick up some lingerie at embrasse-moi, and pay cash. Your system will take the supplier, embrasse-moi, the date, the cost, I added a 'use tax' in case you purchase over the internet and did not pay tax but you still owe it, the amount, and the 'Chart of accounts' which is essentially what category is your expense. That all goes to the general journal. On the same form you will have the payment method. I made a simplified form for an expense + exact payment as that is very common. If the payment is split then you will need to enter the receipt using one form, then create multiple payments linking to that receipt with other forms.

So in the end your database for this simple accounting app will have the following tables: Accounts (the account information including an account type like cc/debit card, checking, cash, inventory account for business purchases, expense account like utilities, the default chart of account) Chart of accounts (basically a list describing how to classify expenses and accounts which will flow to your operating statement, i put mine here for you to check out: http://embrasse-moi.com/exampleData/pos_chart_of_accounts.csv) I have a table for opening balances for accounts, because you have to start somewhere Account type - meaning credit card, debit card, etc. Keep in mind the accounting equation basicaly switches based on the account. Checking accounts debits are "bad" because you gave away your money and credits are "good" because you took in money while credit cards debits are "good" because you reduced your debt and credits are "bad" becasue you added to your debt Chart of account types, which is an 'asset, liability, long term asset, etc. This could be included in the cart of accounts as an Enum type Then there is the general journal, which as described contains enough information to describe your document. Is it on account? Date, amount, the type (receipt or invoice) due date, i keep a 'paid' flag to ease the querying. Then you have a lookup between the 'general journal' table and the payment table Then you have the payment table.

Once you have all this information in, you will almost never use your bank as sources, as they are not always correct, at least my bank makes mistakes. So this type of structure will keep you on top of your information, and at the end of the month this system will produce a statement that looks identical to your account statements. And that is the goal.

Answer 3

About APIs for getting info from your bank: not simple, if at all possible. You can imagine the lengths your bank will go through to make sure everything is secured. I don't think it'll be possible to automatically connect. Usually there's a way to download data through manual downloading of a file, after you logged into your online banking (if you have that available). Hopefully it'll be in CSV format or something similar ;-)

[edit]

Apparently I was wrong here, major banks DO allow direct connection. I guess you'll have to consult your bank techsupport on that then.

[/edit]

As for datatypes to use, I'd at least recommend decimals for money values, instead of doubles/floats. see this SO question thread about that too.

Answer 4

Have you looked at Microsoft® Office Accounting Express?