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.

[Guido1982]

Okay. I've been googling a bit and the general idea has become a bit more clear:

Some definitions. Accounting is also known as 'book keeping'. You may ask: "which book is this?". Well, it's the General Ledger. That's the book. In the General Ledger every transaction will be noted, as a journal. The General Ledger contains multiple General Ledger Accounts. Each GLAccount has a specific number prefix. For instance, Revenue will always start with the number 8. You can subcatergorize in this. Let's say you sell furniture, you could have GLAccount 801 for chairs, and 802 for tables. Now let's say you sell a table with 4 chairs. The selling value of the table will be added to GLAccount 802, the selling value of the 4 chairs will be added to 801. Each of these additions (or subtractions) is a Journal Post. There are also GLAccounts for stock. In the previous example, The tables and chairs will be booked from stock to Revenue. Of course there will be a difference between these, the profit margin, since the stock value was the value you purchased these for. I'm not sure yet if the difference should be booked on a Profit GLAccount in this example. I do know that every journal post should be balanced. So if you take 100 from one GLAccount, you should add the same amount to another.

I will keep searching to better understand the Accounting rules, if anyone can clarify further, help is welcome.

[opto]

why not try to connect to some open source accounting software?
weberp comes to my mind. They also have a module for BOM's and manufacturing, which might be nice to add.
Although cb and vtiger, I thibk, still miss hierarchical product trees.

Klaus

[Guido1982]

Thanks, I'll certainly investigate this. I do however am still tending to a coreBOS suite, since that offers people the ability to capture their entire company in one application, which is what a lot of competing CRM's offer. From my experience with connecting coreBOS to Exact Online, I can say you'll end up repeating yourself a lot and creating a lot of double fields. Also, it can slow down coreBOS if the remote server decides to respond slow, which is bad for user experience.

I do however agree with you on the product hierarchy. This is something on my list to improve and submit to the core team.

[joebordes]

The technical part: yes this is possible. It is called a Perspective and described here:

http://corebos.org/documentation/doku.php?id=en:devel:corebosupdater#corebos_updatercorebos_perspectives

A perspective is a set of code and database changes that literally convert a stock coreBOS system into a verticalization prepared for a clearly defined market segment.

This is functional and is only missing documentation on how it works, so you can use it: start asking :-)

[joebordes]

Guys, for the product hierarchy feature please open another thread and explain what you have in mind.

[joebordes]

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.

[opto]

what I am interested in is not accounting - in germany, one should use software that is officially accepted by the tax administration, but manufacturing support. Thus hierarchical products, BOMs and time planning for procurement.

That part in weberp is pretty ok and could be adapted - at least I am somewhat oriented about the code and did some changes.

Their webinterface is .... no comment.

There is, interestingly, no alternative for small scale manufacturing support - all other systems i found are huge java apps with little chance of customisation unless one wants to understand them. Like odoo, adempiere with libero manufacturing, openbravo, apache ofbiz, postbooks/xtuple (I think manufacturing is free module in all but openbravo).

The weberp solution has the advantage that it is php and has what is needed for small scale make to order. but we never really started that but for the fact that I know the code, because we didn't want two systems with vt or cb and weberp.

And vt/cb is definitely missing the product hierarchy.

Should we do one or two separate threads as new feature on hierarchical product categories and manufacturing/BOMS? To see whether there is general interest in that?

PS:
In weberp, I actually failed in getting some jquery into the code for ease of user interface (meaning they didn't let me to keep it faster loading for use in developing coutries, which makes sense if aimed for that market, and I did not want to have a seriously customised version here) - so I am still searching for a way to replace our excel sheets by something else (meaning putting it into some other code basis).



Klaus

[joebordes]

(01-16-2016, 10:56 AM)opto Wrote: Should we do one or two separate threads as new feature on hierarchical product categories and manufacturing/BOMS? To see whether there is general interest in that?

Please make two, one for each issue so we can discuss, see what we have, what we need and decide how to go forward.

[Guido1982]

(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.