01-18-2016, 12:14 AM
(01-14-2016, 12:43 PM)joebordes Wrote: Accounting:
the way I understand this we are VERY close to a solution. The core of the accounting system is the payment module, which, in fact, is called "Accounting and Payment Module".
http://corebos.org/documentation/doku.php?id=en:coreboscyp
A record in this module reflects a money movement, which can be understood as one of the three sides of your balance sheet: costs, revenue or stock. For example, an invoice could be represented by two payment control records:
1.- related to account (debit) and invoice (credit) for the amount with no taxes
2.- related to vendor (credit) and (invoice) debit for the taxes
I can donate to this initiative (besides my guidance) three additional modules: GLAccounts, GLAGroups and GLATypes (maybe even some others), so what would need to be done would be:
- visual editor to manage payment records in a more "accounting" fashion
- set of default workflows to create payment records
- reporting: create a set of base reports
- packaging: convert it all into a perspective to be installed in one shot
- documentation and support
Let me know how I can help.
I'm going to check this out. Thank you for your offer, I think we can really make some steps here. I think we have a good base. The only thing that I'm missing is a 'Purchase Invoice' module, where you can create purchase invoices (preferably created from purchase orders, but not limited to these). This would need to tie into payments (so an outgoing payment should be able to be connected to a purchase invoice). Apart from that we'd need some kind of 'freelines' I think, because not every purchase invoice will be directly related to an item from the products or services module.
The main thing is I think to create a strong roadmap and specs document before we do any coding. That requires a good knowledge of accounting, which I am now researching (partly by looking at how other more 'Accounty' applications handle this). I have to study your answers, and take some time for this to come up with this roadmap so that we don't create any double work and stay efficient.
Quote:what I am interested in is not accounting - in germany, one should use software that is officially accepted by the tax administration
I think this is not really the case. In Holland (which is a lot like Germany in these things) there is no list of Accounting software packages that you are required to choose from. The end-reports need to be accurate and right, they don't care how you get there. Some Accounting software packages are certified yes, but that does not mean you are prohibited from using other ones.