We are pleased to announce the availability of the new Credit Management – Dunning module.This module supports the creation of Dunning letters; reminder letters that are sent to customers that have sales invoices overdue for settlement.The Credit Manag…
Openbravo is pleased to announce that the Advanced Payables & Receivables Management module is now recommended for every new installation of the Professional Edition.This module was originally launched in Controlled Release status in May 2010. Aft…
Openbravo is pleased to announce the availability of the Advanced Payables and Receivables Management module.Advanced Payables and Receivables Management offers a completely new user experience that simplifies and automates the business processes aroun…
You may have noticed that the Localization Team in Spain have started a new series of blogs on “Building a Localization Pack”. I want to take a moment to stress the benefits of actually doing this (creating a pack) , both to users of Openbravo ERP and …
The way that transactions are reversed in an ERP application is a big deal!
It is important that the application allows reversal that is in line with local best practice and law. Additionally, the way transactions are reversed can influence the level of tax that a company pays or charges, especially when the tax is triggered by a threshold measured by the total movement on a particular account.
In many countries the traditional mechanism for transaction reversal is a straightforward “contra” transaction. This means that debit values in the original transaction are reversed with credit values, and vice versa for the reversal of credit values. Using simple “T” accounts to illustrate this you would expect a contra reversal to look like this:
Original Transaction:Contra Reversal:
However, in some countries there is also a practice of reversing transactions using a “storno” transaction. This means that debit values in the original transaction are reversed with negative debit values, and the credit values are reversed with negative credit values. Using a storno transaction ensures that the total movement on an account is reduced by the reversal. If the original transaction is reversed with a storno transaction we would expect to see the following:
Storno Reversal:In this example you can see that the total movement on the accounts is reduced to zero.
Many ERP applications support only one method or the other. If they do support both methods then it tends to be a global parameter that sets the behaviour for the system as a whole. Openbravo supports both types of reversal and gives users granular control over how and when they use each reversal type.
In Openbravo, users can control transaction reversal behaviour at a schema level using the “Allow negative” parameter. This parameter controls the default reversal behaviour of all reversing transactions. If the parameter is left blank then the default behaviour is “contra” reversal, and if it is “ticked” then “storno” is used as a default.
Additionally, this behaviour can be controlled at a document level.
For a specific Accounting Schema go to Account Schema Tables.
In this example we want to control the way that Invoices are reversed, so we select the “Invoice” document type.
Within the Invoice document type we select the “Documents” tab….
We can test this by entering a normal AP Invoice and viewing the posting….
When we use an AP Credit Memo to reverse the transaction above, if the “Allow negative” is not selected then we get a contra reversal.
However, if the “Allow negative” is selected then we get a storno reversal using an AP Credit Memo, and when viewing the reversing transaction we see the following:
Finally, if a user want to have the choice of which reversal method they use, then it is a simple matter of configuring the default behaviour at a schema level so that the “Allow Negative” is not enabled. This means that the exiting “AP Credit Memo” and “AR Credit Memo” documents will generate a contra reversal.
Two new document types, the “AP Storno Credit Memo” and the “AR Storno Credit Memo”, can then be added. When creating them we ensure that the “Allow negative” parameter is selected during configuration. This will means that the user will then be able to do a contra reversal by using a “credit memo” and a storno using the “storno credit memo”.
As a brief introduction of myself I am responsible for the financial and localization capability of Openbravo ERP. I have worked in the ERP industry for 11 years as Director of Product Management for one of the main players in the proprietary ERP market.
Moving to Openbravo is an extremely exciting opportunity for me as I am a strong believer in the “distributed” localization model. Quite simply I lost faith in the ability of the large proproprietary solutions to support local market needs with centralized development in a timely and efficient manner.
Openbravo, as an open source solution, really is the ultimate distributed model and I am looking forward to working with the Openbravo community to make it a success for all of us.
A couple of weeks ago I was interviewed by the Open Source ERP Guru on “Openbravo ERP Localization” the results of which you can find published here:
The key message that I wanted to convey was our belief here at Openbravo that we have the ability to create a “localization ecosystem” that allows all members of that ecosystem to thrive.
A fundamental technical component that we have recently delivered on Openbravo ERP 2.50 (currently in Beta) is the concept of modularity.
The localization development team have been playing with modularity themselves over the last month or so, partly in order to test it, but really to prove to ourselves that it really does make a difference, both in the ease of development and the speed of deployment. We set ourselves the challenge of creating the first localization “pack” for Spain. Last week the guys demonstrated the results of their efforts to me and it is genuinely very impressive! Not just “cool”, but really something that gets your mind racing through all the possible applications and uses. They opened up a “bare” demo version of Openbravo (English language, no chart of accounts) and picked the “Spanish Localization Pack” from a list of modules that were listed as available for download by the Openbravo application. After a couple of minutes it was “hey presto” and we had a localized version of Openbravo, including language, chart of accounts, alerts, tax rates, etc.
It was very clear to me that this is going to make our lives a lot easier in delivering and supporting add-ons, but (getting back to the Open Source ERP Guru) the real impact this will have is on that ecosystem I was refering to.
With the combination of modularity on Openbravo 2.50 and the new Openbravo Forge there is significant potential for localizers to add value to the core Openbravo features in a way that has a straightforward ROI associated with it.
Selecting Openbravo modularity as the development framework and the forge as the licensing, distribution and support network combines into an extremely efficient delivery mechanism; removing a significant amount of cost from the developer and at the same time providing enhanced revenue opportunities throughout the ecosystem.
As I told the Open Source ERP Guru “Modularity..makes a huge difference both to the ease with which localization can be added in by a customer, the ease by which a partner can develop a module add-on and the ease by which a new module can enhance functionality.. a fourth dimension (to modularity) is … from the partners’ prospective, the potential for modularity to provide an enhanced revenue stream from the provision of those localization packs. With 2.50 we have delivered the technical platform for modularity and we are using that platform ourselves to deliver modules and localizations ourselves already.”
For those of you attending the Openbravo Word Conference we will be showing a demonstration of the use of modularity in delivering localization capability during my Localization session on Sunday afternoon.