The need for an accounting suite

[Guido1982]

I'm working on the last touches of my module that connects coreBOS to Exact Online. In this process, I realized something. Any Exact sales person that comes into contact with someone using coreBOS will try to talk that person into moving their entire CRM system to Exact, since they also offer that. This brings us into a situation (or at least it has brought me into that situation) where offering the connection could in the end loose a customer. CoreBOS of course has many advantages over Exact, but there is one in which it lacks: official Accounting possibilities.

I've taken it upon myself therefor to investigate the possibilities of creating a set of modules (a suite) that fixes this, so that coreBOS can also offer real Accounting features. My investigation will split into two parts, for which I'm looking for input here:

1. The technical part. Of course I am an expert developer now , but I could still use a lot of help. I read somewhere in some documentation (I don't remember where) that it was possible to install a 'chain' of modules. Kind of like making the modules dependant of each other. Is this real, or just a distorted recollection? Also, any advice on implementation of what I'm describing below on the accounting side would be welcome.
2. The Accounting part. I've been going through my Exact Online test account to see what they offer, and how they approach the accounting part. I will post my findings hereunder, as a 'part 1' list, meant to be expanded by you: reader! Anyone with experience in the field of accounting, please respond, because I am not experienced or educated in this field so I'd like to setup a basic system to work from.
   

For the accounting part, I've established we need the following:

• A 'General Ledgers' module. This is a 'homo economicus' term for 'category', simple as that. Let's say you run a supermarket. Your General Ledgers could be:
  • Meat
  • Vegetables
  • Bread
  • Etc...
    
• The General Ledgers can be on three sides of your balance sheet, costs, revenue or stock. They can only be on one at the same time so this can be a simple dropdown.
• Within products, you'd have to create a new block for the general ledgers. For each product, you'd have three fields. There you can choose, for that product which Ledger you book the costs on, on which Ledger you book the Profits and on Which ledger you book the stock. Let's say my supermarket will now buy ten tomatoes. The purchase value of these tomatoes will now be booked on the Ledger I indicated as the cost one, AND on the stock one (since I also add ten to my stock). Now, if I sell three tomatoes, these three will be deducted from the stock Ledger I chose for tomatoes, and the revenue for these tomatoes will be added to the revenue Ledger I selected for tomatoes.
• The purchase part takes me to the second part. We already have purchase orders, but this module doesn't cover the needs for accounting. We need to be able to also import other costs, like rent, or electrical bills. So there should also be a module for 'Purchase Invoices'. You should be able to select a general Ledger here also, so we know which ledger to book these costs on to. From a purchase order (the existing module) we should also be able to create a purchase invoice (the same way a sales order can create one or more sales invoices). After saving the purchase invoice (using the aftersave events?) we can automatically book the purchase value of the products to the correct Ledgers (that are of the 'cost' type).
• The above leads to adding a new field in products (in the 'price' block), called 'cost price'. When a purchase order is created or converted to a purchase invoice, the system should take the value of this cost price field in creating the inventory lines. You should also be able to change these (as you are able to change sales prices per salesorder also), when for instance you received a one-time discount.
• Journals. Journals are nothing else then a record of any financial transaction you made. I'm not wuite sure how to describe this, and don't have a firm grasp on what they should show. I'm thinking every invoice you make should show that some amount of money transferred from one Ledger to another. So booking your electrical bill could be a journal, adding the amount to the Ledger you created for 'housing costs'. I'm not sure, but I think you should be able to tell the system which 'booking period' this journal belongs to.
• I don't know squat about a profit/loss balance, but if someone could explain in in a 'accounting for dummies' way, that would be nice.
  

Of course the integration with existing modules, like 'payment' are also important, I don't want to re-invent the wheel here. I'm more than happy to take on the programming side, would be good excersize for me, but I really do need some pointers before I embark on a mission into nowhere. One thing that I feel is also a real advantage of a lot of CRM's is the possibility of a direct import of bank records, so you can cross-reference these with your invoices (and purchase invoices). I know a lot of banks offer digitized records. I've no experience with the format, but anyone that has any experience, please shout out. I'm thinking of a module that could import a digital bank record, create a record for each transaction made in your account and see if it can find the correct invoice for that booking.

I'm hoping this post will result in a more clear and detailed spec of what an accounting suite should be able to do, so I can start building modules that lead up to such a suite.