How to Property Configure Costing Functionality - Revision history

Wikiadmin: /* Backdated Transactions */

2021-12-19T23:24:35Z

‎Backdated Transactions

Wikiadmin: /* Warehouse Dimension */

2018-10-26T08:27:42Z

‎Warehouse Dimension

Wikiadmin: /* Costing Precision of Currency */

2018-10-26T08:27:31Z

‎Costing Precision of Currency

Wikiadmin: /* Objective */

2018-10-26T08:27:19Z

‎Objective

Wikiadmin: /* Related to Sales/Purchase Flow */

2018-10-26T08:26:58Z

‎Related to Sales/Purchase Flow

Wikiadmin: /* Difference between Invoice price and Order price */

2018-10-26T08:26:36Z

‎Difference between Invoice price and Order price

Wikiadmin: /* Backdated Transactions */

2018-10-26T08:26:23Z

‎Backdated Transactions

Wikiadmin: Created page with "==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..."

2018-10-14T14:56:34Z

Created page with "==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..."

New page

==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 [http://wiki.openbravo.com/wiki/Currency#Currency 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 [http://wiki.openbravo.com/wiki/Costing_Rules#Costing_Rule link]

Also, it is important to take this factor into account when creating a manual entry in the [http://wiki.openbravo.com/wiki/Product#Costing 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 [http://wiki.openbravo.com/wiki/Client#Information 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 [http://wiki.openbravo.com/wiki/Cost_Adjustment 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 [http://wiki.openbravo.com/wiki/Product#Product 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 [http://wiki.openbravo.com/wiki/Costing_Server#Cost_Calculation_Methods 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 [http://wiki.openbravo.com/wiki/Procurement_Management#Procure_to_Pay_Business_Flow 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 [http://wiki.openbravo.com/wiki/Cost_Adjustment 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 [http://wiki.openbravo.com/wiki/Cost_Adjustment Costs Adjustments Documentation]

This functionality is only implemented for the Average Algorithm.

← Older revision		Revision as of 23:24, 19 December 2021
Line 99:		Line 99:
	This functionality is only implemented for the Average Algorithm.		This functionality is only implemented for the Average Algorithm.

−	[[Category:~~HowTo~~]]	+	[[Category:HowTo_Process]]

← Older revision		Revision as of 08:27, 26 October 2018
Line 1:		Line 1:
−	==Objective==	+	== '''Objective''' ==

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

@@ Line 18: / Line 18: @@
 More information can be found in the [http://wiki.openbravo.com/wiki/Currency#Currency Currency Documentation]
-==Warehouse Dimension==
+== '''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.

@@ Line 8: / Line 8: @@
 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==
+== '''Costing Precision of Currency''' ==
 While working with the Costing functionality and Average Algorithm, there can be some minor rounding issues due to mathematical calculations.
@@ Line 16: / Line 16: @@
 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 [http://wiki.openbravo.com/wiki/Currency#Currency Currency Documentation]
 ==Warehouse Dimension==

@@ Line 57: / Line 57: @@
 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==
+== '''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.

@@ Line 70: / Line 70: @@
 More information can be found in the [http://wiki.openbravo.com/wiki/Procurement_Management#Procure_to_Pay_Business_Flow Procure to Pay Business Flow]
-===Difference between Invoice price and Order price===
+=== '''Difference between Invoice price and Order price''' ===
 Normally, the costing engine retrieves the cost of a Product from an Order instead of an Invoice.

@@ Line 82: / Line 82: @@
 This functionality is only implemented for the Average Algorithm.
-==Backdated Transactions==
+== '''Backdated Transactions''' ==
 In Openbravo, right now, the Costing functionality have been developed based on Perpetual Cost.
@@ Line 97: / Line 97: @@
 This functionality is only implemented for the Average Algorithm.