Seamless transition

Everyone wants the transition to a new ERP system to be as seamless as possible.  For most companies how seamless the transition is will usually be determined by time and cost.  Seamless migration of Accounts Receivable requires, at a minimum, migrating outstanding AR documents to the new system.  In Odoo, there is more than one way to accomplish this task; the approach should be tailored to the needs of the Company.  For most companies, it’s important to capture Invoice Date and Terms for each document so they will age properly.  Some companies may want to implement faster and forgo detailed entry of AR documents, while others may ask to bring-in outstanding invoices in a way that facilitates simple product returns for legacy invoices in the new system.  The method and steps used will be determined by the company’s needs, balanced with the time and costs required.

So, where do we start?

The step-by-step guides that accompany this article will demonstrate steps to bring legacy system invoices into Odoo manually.  However, know that outstanding legacy system invoices can be imported into Odoo as well.  Importing is usually the best option for companies with a large number of open documents, but even for companies with smaller agings, importing may reduce the time required to perform this task.  Whether inputting outstanding invoices manually or importing them, the first step is to identify the company’s needs and make a plan.  Let’s start with some important considerations: 

• INVOICE NUMBERS:  Odoo will assign invoice numbers to each invoice entered.  This means that, by default, Odoo will assign a new invoice number.  Does the company need the legacy invoice number to be entered into Odoo?  OCA has a wonderful, free customization called “Force Invoice Number” that allows you to override the Odoo Invoice number.  This is a helpful customization when entering legacy system AR invoices.  You could also add a custom field to capture the legacy system invoice number.

• GENERAL LEDGER EFFECT:  Creation of these invoices will affect your general ledger.  At a minimum, each invoice entered will create a Debit to Accounts Receivable, and a Credit to whatever account you provide.  In other ERP systems, we often debit and credit the AR account when entering legacy system invoices so that there is no GL effect.  However, Odoo is different and will not allow us to select the AR Account on the detail lines.  It’s important to decide which accounts you will use ahead of time and be consistent so that you may easily reverse the effect of these entries once they are all entered. 

• LEVEL OF DETAIL TO MIGRATE: When bringing legacy invoices into a new system the most important thing is usually bringing the total balance of outstanding invoice amount into Odoo.  It’s not necessary to enter every single detail line (product sold, quantity, unit price, discount amounts, tax amounts, etc.) on the original invoice into Odoo to meet this goal.  Of course, it can be done and should be done if it’s necessary for future management of invoices, but know it will add complexity (including time and cost) to the process.

• WHERE THE DATA ENTRY IS DONE MATTERS:  When legacy invoices are brought into Odoo via the Accounting | Customer | Invoices screen, returns from those invoices will require more care, even if we enter every detail line.  A return for one of these invoices will not generate product moves.  For most companies, the Customer Invoice Entry method (covered in the related article) is the best balance between post-implementation functionality, speed, and cost, but it does have some limitations so it’s something you need to discuss.  For example, if the Company needs, to bring-in detail lines (product sold, quantity, unit price, discount amounts, tax amounts, etc.) for a specific reason (e.g. so product returns are seamless) you’ll need to bring invoices in via the Sales module and plan to manage the additional complexities that come with that.  This is an important discussion to have in the beginning stages of a project. 

• DATES MATTER:  Consider dates and how your legacy system balances will be brought into Odoo. In the related step-by-step guides, go-live is July 1.  The legacy trial balance will be entered into Odoo as of June 30th.  All legacy invoices are dated prior to July 1 and will be entered with their actual invoice date.  The reversing journal entry (to reverse the effect of the legacy system invoice entry) will be entered as of June 30th.  The dates in this plan hold strong even if you are entering the trial balance from, for example, December and rolling it forward with each months’ activity.  There is no need to reverse these entries in the month in which the invoice is posted.  In fact, it’s best to reverse them all as a group on the same date assigned to the final trial balance entry (usually the day before go-live.)

• COME INTO ODOO CLEAN:  Finally, as a best practice, clients should clean up their legacy system general ledger prior to migration to their new Odoo system.  Review the legacy system Aged AR report and compare it to the legacy system GL trial balance report.  The sum of all outstanding invoices should support the Accounts Receivable balance in the legacy system GL.  If it does not, the accounting team should know why.  How those variances are managed will be up to the accounting team.  In some cases, a journal entry adjustment will be required.

With the above list considered you are ready to make your migration plan for legacy system Accounts Receivable.  The step-by-step guides below will demonstrate two methods for bringing-in outstanding documents:

1. Journal Entry Method:  this method comes with some limitations that won't be acceptable to most companies.  It's quick and easy, so for those looking to implement quickly it may be a great option. 
   

2. Customer Invoice Entry Method: while this method has some minor limitations, most companies find it to be the best balance between speed, cost and post-implementation functionality.

These are just two of many possible approaches for migrating AR.  While they won't accommodate every client requirement for AR migration, they can be modified to meet a number of specific needs.