24
Dec 14

Migrating Opening Balances into Odoo

In order to move the GL Balances into Odoo from a legacy system the following procedure must be applied.

A new GL Account: “Opening Balance Equity” is required.

Opening Balance Equity is the account that is used for the other side of the entry when beginning balances are entered when setting up new accounts.

The following Account Journals must exist:

  • Opening Sales Journal
  • Opening Sales Refund Journal
  • Opening Purchase Journal
  • Opening Purchase Refund Journal

As suggested in the following link, in order to migrate the Accounts Receivable and Accounts Payable Open Items it is best if they are created as invoices.

When the load file is created, indicate the original invoice #, the customer and the open balance to-date, so that it will be easy for to later reconcile with payments received during 2015.

Normal customer invoice:
(AR Open Item Balance in legacy system >0):

  • Journal: Opening Sales Journal
  • Invoice date: the original invoice date
  • Invoice due date
  • Period: force to the period in which the invoice will be posted (e.g. 01/2015)
  • Account: AR account defined in the customer master data
  • Line items: One line item indicating as Account “Opening Balance Equity” and the total amount due.

At the time of approving the invoice a journal entry will be created with the following items:

  • Debit: AR account
  • Credit: Opening Balance Equity

Customer invoice refund:
(AR Open Item Balance in legacy system < 0)

  • Journal: Opening Sales Refund Journal
  • Invoice date: the original invoice date
  • Invoice due date
  • Period: force to the period in which the invoice will be posted (e.g. 01/2015)
  • Account: AR Account defined in the customer master data
  • Line items: One line item indicating as Account “Opening Balance Equity” and the total amount due.

At the time of approving the invoice a journal entry will be created with the following items:

  • Debit: Opening Balance Equity
  • Credit: AR Account

The Accounts Payable open items will be migrated as supplier invoices, indicating the original invoice #, the supplier and the open balance to-date, so that it will be easy  to later reconcile with payments made during 2015.

Normal supplier invoice:
(AP Open Item Balance in legacy system >0):

  • Journal: Opening Purchase Journal
  • Invoice date: the original invoice date
  • Invoice due date
  • Period: force to the period in which the invoice will be posted (e.g. 01/2015)
  • Account: AP account defined in the supplier master data
  • Line items: One line item indicating as Account “Opening Balance Equity” and the total amount due.

At the time of approving the invoice a journal entry will be created with the following items:

  • Debit: Opening Balance Equity (recorded in the invoice line item)
  • Credit: AP Account

Spplier invoice refund
(AP Open Item Balance in legacy system < 0):

  • Journal: Opening Purchase Refund Journal
  • Invoice date: the original invoice date
  • Invoice due date
  • Period: force to the period in which the invoice will be posted (e.g. 01/2015)
  • Account: AP account defined in the supplier master data
  • Line items: One line item indicating as Account “Opening Balance Equity” and the total amount due.

At the time of approving the invoice a journal entry will be created with the following items:

  • Debit: AP Account (recorded in the invoice header)
  • Credit: Opening Balance Equity (recorded in the invoice line item)

The Inventory is migrated by means of a physical inventory count. As the products in stock use real time inventory valuation,  the following Journal entry being created (one journal item for each product) when the physical inventory is posted:

  • Journal: Stock Journal
  • Debit: Stock Quantity * Average cost
  • Credit: Opening Balance Equity

When the other GL Account Balances are loaded, some weeks later, a single Journal entry will be created using the Opening Journal and .

The AR, AP and inventory balances need to be omitted, because they have already been loaded, and all the Balance Sheet GL account balances are entered using the ‘Opening Balance Equity’ as the contra GL account.

After this process, the Opening Balance Equity account should have the same balance as the Retained Earnings account in the legacy system.

Then a final journal entry needs to be created to distribute the remaining balance in the Opening Balance Equity account to the retained earnings.


15
Dec 14

Cost Management Accounting in Odoo

Odoo uses an app called Analytic Accounting. It can be described as:

  • A single-entry bookkeeping system. Is a method of bookkeeping relying on a one sided accounting entry to maintain financial information. Only the costs or revenues associated to the transactions are recorded, but they are not balanced within the accounting system.
  • A Non-integral accounting system. Means that the transactions are recorded separately from the financial accounting. In the Analytic Accounting app, separate journals are created, called Analytic Journals. A non-integral accounting system must implement a mechanism to ensure that both accounting systems can be reconciled.

The single-entry bookkeeping system

A single-entry bookkeeping system has the advantage of being simple to implement and operate, but the main disadvantage is that it cannot be easily trusted, as there are no check and balances to ensure accuracy.

For example, consider the scenario where a user wants to distribute costs from one analytic account (say, a department that services others) into two other analytic accounts, manually. The user should manually enter a -100 amount in the origin analytic account and then distribute +50 to each other. She may make a mistake, and enter +500, and the system would never prevent it.

Tracing the errors in a single-entry bookkeeping system, most specially when there’s a significant amount of cost distribution transactions, can be extremely difficult.

Reconciliation between Analytic and Financial accounts

Being a non-integral accounting system, the method that Analytic Accounts implement in order to bring reconciliation with the Financial Accounts system is through the use of the “Inverted Analytic Balance”.

cost_accounting_1

 

In order to ensure proper reconciliation the the user has to guess all accounts that may have been subject to analytic entries on a period, then print the Inverted Analytic Balance, and finally compare the balance with the debit or credit of the corresponding General Ledger Account.

In case that differences exist, adjusting entries may need to be recorded in either Accounting system.

Other Cost Management Accounting Methods

 

All researched Cost Management Accounting methods that implement a non-integral accounting system are based on:

  • The double-entry bookkeeping system.
  • Interlocking systems, by which the two sets of accounts are being kept continuously in agreement or readily recognizable.

The following article explains the interlocking system using double-entry bookkeeping. This system provides the following benefits:

  • Brings the accuracy of the double bookkeeping entry system
  • Provides the tools to easily reconcile the the Cost Accounting with the Financial Accounting.
  • Provides a trusting system to analyze the costs of your company.

05
Dec 14

Product receptions and returns with real-time inventory valuation in Odoo

In this blog post I will describe the account journal entries related to Purchase Orders for stockable product receptions and Purchase Order Returns, using real-time inventory valuation in Odoo.

I will also  explain why I consider that a new module “Account Creditor Price Difference” implemented by Eficent is required to bring-in the proper account journal entries, and why the module “Account Anglo Saxon” should not be used.

Receive product from supplier

These are the Account Journal Entries that should be produced:

goods_receipt_1

At the time when the product is accepted into stock the Stock Input Account is Credited. This account usually called in the business context as “Goods Received Not Invoiced (GRNI). I think that calling it “Stock Input Account” adds a lot of confusion.

But so far, so good. This is what the module “Account Anglo Saxon” would do…

Return product to supplier

You can see that a return to a supplier is simply a reversal of the postings explained in “Receive Products from supplier”. This is what should be, and what “Account Creditor Price Difference” delivers.

goods_receipt_2

Without this module, this is what happens:

goods_receipt_3

The Stock Input Account is debited in step “2. Return 1 product”, but never balanced.
The Stock Output Account is credited in step “3. Supplier refund”, but never balanced.

Only if Stock Input Account = Stock Output account would the flow from “Anglo Saxon Accounting” make sense.

But as I explained, both accounts have different meaning!

Supplier invoices and refunds without reference to a stock move

In case that the user may create a supplier invoice or refund not directly from a stock move, it does not make sense that the application should propose the Stock Input or Stock Output accounts (as it is doing now), because the user well may be creating this invoice/refund associated to a drop shipment.

In my opinion, in the scenario where a user creates a supplier invoice or refund without reference to an preceding document, the system should not accept it to be validated, until the invoice is properly referenced, the quantities match and the price variance is under the tolerance limit.

  • Invoice lines referencing to stockable or consumable products should refer to a stock move.
  • Invoice lines referencing to services should refer to a purchase order line.

..But this is still work in progress.. :)

More information

The module that implements the features described in this post is available for free under the AGPL license. If you are interested to use this module and seek further assistance, please contact us and we will be happy to provide you with instructions on how to install it.


04
Dec 14

Use of remit-to addresses in Odoo to use during check printing

In countries where payments are made by checks the account vouchers are used, and it often happens that the addresses that the checks should be sent to is different to the address of the supplier.

Eficent introduces new modules that add the possibility to set up a partner with a new address type ‘Remit-to’.

account_voucher_remit_to_1

During the creation of a Voucher, once the Supplier is entered, the application will determine the associated remit-to address.

account_voucher_remit_to_3

At the time of printing the check this address is considered instead of the supplier’s:

account_voucher_remit_to_4

More information

The module that implements the features described in this post is available for free under the AGPL license. If you are interested to use this module and seek further assistance, please contact us and we will be happy to provide you with instructions on how to install it.


01
Dec 14

Drop shipments improvements in Odoo

Eficent has introduced a new module for Odoo/OpenERP v7 that makes it possible to maintain more accurate financial postings associated to drop shipments.

What is the problem?

The current module “sale_dropshipping” facilitates the drop shipping transactions and it is the foundation for the changes described in this article.

However, at the time when stock is issued from the vendor to the customer, no proper account postings are maintained.

Looking at the end to end procurement account journal entries for a drop shipment:sale_dropshipping_location_1

One realizes that the step “2. Accept 1 product”, that is represented in OpenERP with a stock move from the supplier to the customer location, will not generate an account journal entry.

The stock input account (that represents a liability account) is never credited, but debited in step ‘Supplier invoice’.

Looking at the end to end sales account journal entries for a drop shipment:sale_dropshipping_location_2

One realizes that the step “2. Deliver 1 product”, that is represented in OpenERP with a stock move from the supplier to the customer location, will not generate an account journal entry.

The stock output account (that represents an expense account) is never debited, but credited in step ‘Customer invoice’.

The flow would only be correct if  stock input account = stock output account. But as described in the post ‘Recognition of project expenses in Odoo‘,  that would be an incorrect configuration in normal flows.

What is the solution?

Eficent introduces a new module “Sale Dropshipping Location” that automatically proposes two chained stock moves associated to a drop shipment that are triggered automatically when the purchased products are received.

sale_dropshipping_location_10

  1. Stock move 1: Supplier -> virtual ‘Drop Shipment’ internal location
  2. Stock move 2: Virtual ‘Drop Shipment’ internal location > Customer

sale_dropshipping_location_3

See the corresponding Account Journal Entries created:

For move Supplier -> virtual ‘Drop Shipment’ internal location:sale_dropshipping_location_4

For move Virtual ‘Drop Shipment’ internal location > Customer:

sale_dropshipping_location_5

 

Drop shipment returns

When the user creates a return for a drop shipment the user automatically creates a new incoming shipment associated to the supplier, where the destination location is the customer’s, and the source is a default Virtual Drop Shipment Returns location.

The Virtual Drop Shipment Returns location is automatically chained to a generic supplier location.

As a consequence of a customer return for a drop shipment, the following incoming shipments are generated:

sale_dropshipping_location_6

 

Notice that the incoming shipment shows the actual supplier as the destination address.

 

The corresponding stock moves:sale_dropshipping_location_7

 

And the corresponding account journal entries:

For move Customer -> virtual ‘Drop Shipment Returns’ internal location:sale_dropshipping_location_8

For move Virtual ‘Drop Shipment Returns’ internal location -> Supplier location:sale_dropshipping_location_9

As a consequence the account journal entries created are the same as described in  ‘Recognition of project expenses in Odoo‘.

More information

The module that implements the features described in this post is available for free under the AGPL license. If you are interested to use this module and seek further assistance, please contact us and we will be happy to provide you with instructions on how to install it.


13
Nov 14

Project Progress measurements in Odoo

Introduction

Eficent brings you a module to better enter and track the progress measurements of your projects in Odoo/OpenERP version 7.

The progress of a project indicates the degree of completion, with respect to the estimated scope of work.

Generally the progress cannot be automatically measured and it is based on the expert judgement or the completion of checklists that determine the degree of completion of a project.

The progress measurements are a critical element for the progress evaluation (and most specially in the Earned Value Management techniques).

Progress Measurement Types

A company can measure the progress on a projects using different types of measurements, such as percent, tons delivered to the customer,..

The measurement types are defined in “Project > Configuration > Progress Measurement > Progress Measurement Types”:

progress_measurement_1

Non-Aggregated Measurements

These are measurements directly associated to the progress of a WBS element in a project. They will indicate to which percent has this WBS element been completed, with regards to the work that has been directly allocated to be performed in this WBS element. A non-aggregated measurement does not consider the work planned in the childs WBS elements.

The user can either enter measurements from scratch, from the menu:

openerp_project_progress_measurment_2

 

Alternatively, the user can enter to a WBS element and in the Tab “Progress”, initiate an action to enter non-aggregated progress measurements for a specific date, for all the WBS elements in the hierarchy.

openerp_project_progress_measurment_3

 

openerp_project_progress_measurment_4

Use of Non-Aggregated Measurements in the project progress analysis

An aggregated measurement is a calculated measurement of the progress of the WBS element. In the Earned Value Management module, the non-aggregated measurements are used to produce the Percentage of Completion (POC), which is an aggregated measurement.

Example of how is the Percentage of Completion (POC) calculated in the Earned Value Management module;:

A project has the following WBS structure:

WBS element A
> WBS element A / 1
> WBS element A / 2

The user needs to enter, for each WBS element, the Total Planned Cost and the Non-Aggregated progress measurement.

The Earned Value (EV)  is then calculated, for each WBS element, as the Total Planned Cost * Non-aggregated progress measurement.

The Aggregated Percent of Completion (POC) is then obtained as:

Aggregated POC = Aggregated Earned Value (EV) / Aggregated Total Cost

WBS code Total Planned Cost Non-aggregated progress measurement Earned Value Aggregated Earned Value Aggregated Total Planned Cost Aggregated POC
A $50.00 50.00% $25.00 $56.00 $90.00 62.22%
A / 1 $10.00 100.00% $10.00 $10.00 $10.00 100.00%
A / 2 $30.00 70.00% $21.00 $21.00 $30.00 70.00%

More information

The module that implements the features described in this post is available for free under the AGPL license. If you are interested to use this module and seek further assistance, please contact us and we will be happy to provide you with instructions on how to install it.


03
Nov 14

Recognition of project expenses in Odoo

Introduction

This blog post aims to explain the following changes introduced by Eficent to Odoo (formerly known as OpenERP) version 7, to make it possible to recognize material expenses to projects in a more accurate and timely manner.

Currently Odoo has the following limitations:

  • Acknowledges the expense in the project’s Analytic Account only when the vendor invoice is accepted. Not when existing stock is used/delivered to the customer as part of the project (bad timing for the recognition of expenses associated to a project)
  • Does to recognize in the project’s Analytic Account expenses associated to materials consumed from stock for the project (inaccuracy of the recognition of expenses associated to a project)
  • Does not allow limiting the posting to the Analytic Accounts Accounting only to P&L entries.

Business case

During the execution of a project, materials may be either consumed or delivered, as part of the activities required to produce the project deliverables.

The company may obtain the required materials from its own existing stock, or may procure the materials specifically for the project.

Every time a material is used for the project (consumed or delivered to the customer), the project’s Analytic Account needs to reflect the associated expense.

Pre-requisite modules

The following modules need to be installed:

Odoo modules:

  • account
  • account_anglo_saxon
  • project
  • analytic
  • purchase
  • sale

Eficent’s modules:

Analytic moves only for expenses or incomes
Technical name: account_analytic_moves_extend
Source: https://github.com/Eficent/eficent-odoo-addons/tree/v7
Comments: Limits the creation of analytic lines associated to invoices accepted only when the move is associated to an expense or revenue account.

Anglo-Saxon Accounting extension
Technical name: account_anglo_saxon_ext
Source: https://github.com/Eficent/eficent-odoo-addons/tree/v7
Comments: A change to the account_anglo_saxon modue is introduced in order to make it possible to post the cost of goods sold move to the analytic journal.

Stock Move Line
Technical name: stock_move_line
Source: https://github.com/Eficent/eficent-odoo-addons/tree/v7
Comments: Limits the creation of analytic lines associated to stock moves to only occur when the move is associated to an expense or revenue account. Introduces the analytic account associated to the account move. Creates an analytic line associated to the expense or income account for that analytic account when the account move is created.

Purchase Stock Analytic
Technical name: purchase_stock_analytic
Source: https://github.com/Eficent/eficent-odoo-addons/tree/v7
Comments: Copies the analytic account of the purchase order to the stock move.

Sale stock analytic
Technical name: sale_stock_analytic
Source: https://github.com/Eficent/eficent-odoo-addons/tree/v7
Comments: Copies the analytic account of the sales order to the stock move.

 

Master data set-up

Accounts

Code Description Parent Internal type Account type P&L/BS category
STIN Stock Input Current Liabilities Regular Current Liability BS
STOUT Stock Output Expenses Regular Expense BS
STVAL Stock Valuation Current Assets Regular Current Asset BS
PREX Product Expense Expenses Regular Expense P&L
120010 Account Receivable Receivable Account Receivable BS
200010 Account payable Payable Account Payable BS
PRIN Prouct Income Income Regular Income P&L
PRDIF Price Difference Expenses Regular Expense P&L

Product category

Accounting information:

Product category attribute Account
Stock Input Account Stock Input
Stock Output Account Stock Output
Stock Valuation Account Stock Valuation
Income Account Product Income
Expense Account Product Expense
Price Difference Account Price Difference

stock_1

Current situation

Procurement of products

The following table describes the usual purchase tansactions for products in Odoo using the anglo-saxon accouting module.

Product cost

9

Supplier price

10

stock_16

stock_17

 

stock_18

Remarks:

The cost associated to the products purchased is recognised at the analytic account when the supplier invoice is accepted. This is not an appropiate timing for the reconginition of expenses incurred by the project because:

a) The recognition of the cost in the Analytic Journal is not in line with the recognition of expense in the Account Journal, where no expense-related move has been yet created.

b) The products may have been purchased for the project, but they have not yet been used by the project.

Sale of products

The following table describes the usual purchase tansactions for products in Odoo using the anglo-saxon accouting module.

Product cost

9

Sale price

20

stock_19

stock_20

stock_31

Remarks
The expense associated to delivering products is not recongized in the Analytic Journal.

Scenarios with Eficent’s modules

Procurement of products

See the previous table on procurement of products, now with the changes incorporated by Eficent’s modules (see changes highlighted)

Product cost

9

Supplier price

10

stock_21

stock_22

 

stock_23

See below the Account Journal Entries created in step “2.Accept 1 product”

stock_2

See below the Account Journal Entries created in step “3. Supplier invoice”:

stock_3

See below the Analytic Journal Entries created in step “3. Supplier invoice”:

stock_4

Remarks:
The expense corresponding to the price difference is recognized at the same time in the Account Journal and in the Analytic Journal.

Sale of products

See the previous table on sale of products, now with the changes incorporated by Eficent’s modules (see changes highlighted).

stock_24

 

stock_25

stock_27

 

See below the Account Journal Entries created in step “2. Deliver 1 product”:

stock_12

See below the Analytic Journal Entries created in step “2. Deliver 1 product”:

stock_13

See below the Account Journal Entries created in step “3. Customer invoice”:

stock_14

See below the Analytic Journal Entries created in step “3. Customer invoice”:

stock_15

Remarks:
When the invoice has been confirmed the revenue associated to the sale is recognized in the Account Journal and the Analytic Journal.

Conclusions

Expenses associated to stock moves are recognized, independently of the origin of the expense (material product consumed from stock or purchased for the project), into the project’s analytic account.

The analytic account is restricted to display only expenses and revenues (P&L accounts).

The Anglo-Saxon accounting module was used in the example. This module will defer the recognition of costs associated to a sale to the event when the customer invoice is accepted. A cost work in process (WIP) asset account is normally assigned to the Stock Output Account.

This module can also be used by Rhine (continental accounting) countries, provided that in these countries change their Stock Output Account to be an expense account. These countries would benefit from the possibility of recording the price-differences entry recorded at the time of accepting the vendor invoice.

For companies managing long-term projects, IFRS and GAAP dictate that expenses shoud be recognized at the time when the event that originates the expense occurs. According to the matching principle required by IFRS and GAAP, it is revenue that must be accrued in the same accounting period as the cost that originated this revenue.

As a consequence companies whose main activities are related to long-term project should use the Odoo Anglo-Saxon Accounting module, but should set-up the Stock Output Account tp be an Expense account, not a cost work in process (WIP) asset account.

More information

The module that implements the features described in this post is available for free under the AGPL license. If you are interested to use this module and seek further assistance, please contact us and we will be happy to provide you with instructions on how to install it.

 

 

 


30
Oct 14

Search invoices by project/analytic account in Odoo/OpenERP 7

Organizations often require to quicky find the invoices associated to a project/analytic account.

The new module ‘Invoice Analytic Search’ initiated by Eficent introduces the possibility search for invoices by analytic account or by project manager.

account_invoice_analytic_search

More information

The module that implements the features described in this post is available for free under the AGPL license. If you are interested to use this module and seek further assistance, please contact us and we will be happy to provide you with instructions on how to install it.


05
Oct 14

Project/analytic planned costs and revenues in Odoo/OpenERP

An effective planning of costs and revenues associated to projects or to other analytic accounts  becomes essential in organizations that are run by projects, or profit centers.

The process of cost planning generally follows an rolling wave planning approach, in which the level of detail of the planned costs is increases over time, as the details of the work required
are known to the planning group.

Organizations typically maintain different versions of their planned costs (rough cut, detailed, approved budget, committed,…).

The module ‘Analytic Plan’ provides the foundation for the planning of analytic costs and revenues, and it is
used by other modules that can originate planned costs or revenues during the business process execution.

Users will generally not access to the analytic planning lines to record planned costs and revenues, but will enter the planning data through other entities, such as the Project/Analytic Resource Planning module.

However, an example is provided below on how can users enter planning analytic lines.

Example

A company is initiating a project to build a new car “NextGen”. The company will be in charge of developing the engine and electrical systems.

After an an analyis the engineering team has produced a detailed breakdown of the costs to design the engine, and a rough cut version of the costs required to design the electrical system.

The following project Work Breakdown Structure (WBS) is created in Odoo/OpenERP:

openerp_analytic_plan_1

The user indicates, for each WBS element, what is the currently active planning version.

openerp_analytic_plan_4

Once the projects have been created, the user enters the planned costs associated to each WBS element going to “Project > Analytic Accounting > Analytic Journal Plan Items”.

openerp_analytic_plan_3

openerp_analytic_plan_2

A user can review the totalized planned costs and revenues from the analytic account list view.

openerp_analytic_plan_5

 

The user can also access, from the analytic account, to the associated planned costs and revenues.

openerp_analytic_plan_10

How to download the module

The module can be downloaded from: https://github.com/Eficent/eficent-odoo-addons

The name of the module is “analytic_plan”.

After downloading the module the OpenERP administrator should move it to the “addons” folder in the OpenERP server.

The server will then need to be restarted.

How to install the module

An OpenERP user with administrator rights should go to “Settings > Modules > Update modules list” to add the new module to the repository.

Then go to “Settings > Modules > Installed Modules” and search for the module “Analytic Plan”. Install the module.

Configuration requirements

Define Planning Versions

Go to “Accounting > Configuration > Analytic Accounting > Analytic Planning Versions”.

openerp_analytic_plan_6

openerp_analytic_plan_7

Define Analytic Planning Journals

The Analytic Planning Journal serves as an attribute to classify the costs or revenue by the it’s origin. It is equivalent to the Analytic Journal in Odoo/OpenERP.

Go to “Accounting > Configuration > Analytic Accounting > Planning Analytic Journals”.

openerp_analytic_plan_8

openerp_analytic_plan_9


03
Oct 14

Analytic accounts in purchase requisitions for Odoo/OpenERP7

Organizations often require to integrate purchase requisitions with projects or contracts, and find requisitions by searching by it the project/contract code, name or project/contract manager.

When a user creates a new purchase requisition she/he can indicate the analytic account.

Eficent Odoo OpenERP purchase_requisition_analytic 1

When the purchase order is created from the purchase requisition the analytic account is copied to the purchase order line.

Eficent Odoo OpenERP purchase_requisition_analytic 2

Introduces the possibility to search purchase requisitions by analytic account or by project manager.

Eficent Odoo OpenERP purchase_requisition_analytic 3

And introduces a new entry in the Purchasing menu to list purchase requisition lines.

Eficent Odoo OpenERP purchase_requisition_analytic 4

How to download the module

The module can be downloaded from: https://github.com/Eficent/eficent-odoo-addons

The name of the module is “purchase_requisition_analytic”.

After downloading the module the OpenERP administrator should move it to the “addons” folder in the OpenERP server.

The server will then need to be restarted.

How to install the module

An OpenERP user with administrator rights should go to “Settings > Modules > Update modules list” to add the new module to the repository.

Then go to “Settings > Modules > Installed Modules” and search for the module “Purchase Requisition Analytic”. Install the module.

Configuration requirements

Users willing to be able to use this functionality must have the technical setting “Analytic Accounting for Purchases” activated in their user’s access right settings. Go to “Settings > Users > Users” then locate the user and go to the form view.

Eficent Odoo OpenERP purchase_order_analytic 3