How to Property Configure Costing Functionality

Objective

Costing functionality can be very complex and, if not configured properly, it can even be harder to understand and to maintain.

This is the reason why it is so important to analyze the Client's requests first, and then to configure it properly in Openbravo. In order to do so, there are several topics that must be taken into consideration while doing this initial configuration.

This are the concepts that have caused bigger problems when not configured properly. It is very important to uderstand first the Client's needs and to decide if this configurations apply to their needs or not.

Costing Precision of Currency

While working with the Costing functionality and Average Algorithm, there can be some minor rounding issues due to mathematical calculations.

However, this issues can be more noticeable if the Costing Precision of the Currency is low. By using a higher precision, the system can perform the calculations with a larger number of decimals, reducing the problem.

That is the reason why it is advice to configure the Costing Precision of the Currency with at least 6 decimals. A lower number will lead to more noticeable rounding issues.

More information can be found in the Currency Documentation

Warehouse Dimension

While creating a new Costing Rule, it is possible to decide whether the calculation must taken into account the Warehouse Dimension or not. The difference between both approaches is:

• Warehouse Dimension disabled: The costs will be calculated at the Legal Entity level. This means that the cost of a particular Product is going to be shared for all the Warehouses defined for Organizations that belongs to the Legal Entity.
• With the Warehouse Dimension enabled: The costs will be calculated per each Warehouse. This means that for a particular Product, it can have a cost in one Warehouse and a different cost in another one, even if both are defined for Organizations that belongs to the Legal Entity.

More information can be found in the link

Also, it is important to take this factor into account when creating a manual entry in the Costing Tab of the Product Window If it is necessary to do so, the Warehouse field must be consistent with the Costing Rule definition. If the Warehouse Dimension is disabled, the field must remain empty, if the Warehouse Dimension is enabled, the field must have the proper value set. Otherwise problems in the calculation can be raised due to this discrepancy between data an configuration.

Manufacturing

It is very important to know if the Client is going to use Manufacturing functionality. The reason for it that is due to the fact that, in the Costing functionality, there is a little caveat when calculating the costs for Manufacturing. While in the other flows, the costs are created at Legal Entity or Warehouse level, depending on the Warehouse Dimension flag, in Manufacturing, the costs are created only at Client level.

This means that, for Manufacturing, the cost of a particular Product is going to be shared for all the Organizations of the Client, it can not be defined at Legal Entity level.

Negative Stock

It is very important to know if the Client is going to work with Negative Stock or not. This feature can be enabled through the Client Window

If it is enabled it is important to activate the Negative Stock Correction preference for Costing functionality. More information can be found in the Costs Adjustments Documentation

By activating this preference, the costing algorithm will fix calculation problems raised when the Stock is negative, if not, this problems won't be dealed with.

This functionality is only implemented for the Average Algorithm.

Forbidden changes in Product definition

This problem is already controlled in the Application, but it is important to be noticed. When a Product is defined, some of the parameters can be changed. However, if the Product has already Documents associated to it, there are several parameters that can not be changed.

Particulary, if a Product is defined to be used in Production, if it is defined as Stocked or not, or the Product type. More information can be found in the Product definition Window

This parameters can affect the calculation of the costs for that Product. This means that, when a Product is defined and used, the definition should not be changed, that is why it is so important to define it properly from the start.

Related to Sales/Purchase Flow

Relationship between Goods Shipment/Receipt and Orders

It is important to understand the workflow of the Client and, in this case, if the Goods Shipment/Receipts are going to be linked to the Orders and/or Invoices.

In the Documentation about the Costing Sever it is explained how the cost is calculated.

For incoming transactions, like a Goods Receipt, it tries to retrieve first the cost from the related Purchase Order, if not, it retrieves the cost from other places (like purchase price list or default standard cost of the Product)

From a functional point of view, what most Clients expect is for this algorithm to retrieve the cost from the related Purchase Order, as it tries to do. However, if this Purchase Order is not related to the Goods Receipt, the algorithm is not able to do so. This relation is introduced while creating a Goods Receipt based on the previous Order instead of creating it from scratch.

More information can be found in the Procure to Pay Business Flow

Difference between Invoice price and Order price

Normally, the costing engine retrieves the cost of a Product from an Order instead of an Invoice. For some Clients, this can be a problem since the price can vary significantly for them from the Order to de Invoice. In this case it is possible to enable a functionality named Price Difference Correction.

Is a type of Cost Adjustment that adjusts the cost of the Transaction in order to reflect the cost of the Invoice rather than the cost of the Order.

More information can be found in the Costs Adjustments Documentation

This functionality is only implemented for the Average Algorithm.

Backdated Transactions

In Openbravo, right now, the Costing functionality have been developed based on Perpetual Cost. Therefore, the cost of the Transactions are calculated based on when a Transaction has been processed.

This means that, if a Transaction that has happened in the past is registered in the future, it will be calculated when it is processed, in this case, in the future.

For some Clients this can be a problem, because due to their workflow, they might not be able to register all the Transaction in the proper order. For this scneario, there is a functionality named Backdated Transactions. It allows to calculate the cost of a Transaction like it would have been calculated if it happened in the past.

However, it is recommended to enable this functionality only if this problem is really critical for the Client because the scneario happens often in their workflow. If not, it is better to avoid using it, since it can make calculations of the cost more complex to understand.

More information can be found in the Costs Adjustments Documentation

This functionality is only implemented for the Average Algorithm.