Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0028289Openbravo ERP04. Warehouse managementpublic2014-11-26 13:222014-12-30 23:28
psanjuan 
umartirena 
urgentmajoralways
closedfixed 
20Ubuntu 8.04.1
 
 
Sandrahuguet
Core
No
0028289: [Costing] No cost calculated in case costing rule does not have a starting date nor a fix backdated from date
[Costing] No cost calculated in case costing rule does not have a starting date nor a fix backdated from date
Create a new client and a new organization (legal entity with accounting) in that client.

Setup the vary basics such as fiscal calendar, open/close periods, BP group, Product group, Price Schema, Price list, a BP and a product. This setup should allow you to create and book a purchase order, a goods receipt of that order and the corresponding purchase invoice.

Go to Costing rule and create a new one by entering below data:
-Warehouse dimension = Yes
-Fix backdated transactions = Yes
Do not enter any starting date. Validate the costing rule. Realize that there is no date in Starting date field nor in Fix Backdated Transactions From field.

Go to process request window and create a new one for your client by choosing "Costing Background Process".

After completing a goods receipt, navigate to process request window and launch costing background process. Realize that this run is not set as "successfully" and no cost for the product has been calculated.

The issue is related to the fact that date is null.
In case the end-user does not enter an starting date nor a fix backdated from date for the first costing rule created, Openbravo should behave as described below while "validating" this first costing rule:

(1) if the costing rule is being created for a "Legal without Accounting" organization:

(1.1) A new window is going to be shown letting the end user know that as no starting date is provided, Openbravo is going to calculate the cost of all the transactions booked. This new window will have an "OK" and "Cancel" button. Text message: "The cost of all existing transactions is going to be calculate as no costing rule starting date is provided".

(1.1.1) If the user press "Ok", the "Starting Date" should not be set to null but to 1-1-1900. Same applies to "Fix Backdated From Date", it should also be set to 1-1-1900. Those two dates should NOT be populated in the corresponding fields but kept "internally".

(1.1.2) If the user press "Cancel", costing rule validation process stops.



(2) if the costing rule is being created for a "Legal with Accounting" organization. This kind of organizations are always linked to a "unique" fiscal calendar whose periods/documents can either be open or closed.

Openbravo should always check first whether there are transactions dated on a period closed whose costs need to be calculated.

(2.1) If that is not the case (There are no transactions whose costs needs to be calculated dated on a closed period but open period) - a new window is going to be shown letting the end user know that as no starting date is provided, Openbravo is going to calculate the cost of all existing transactions booked. This new window will have an "OK" and "Cancel" button. Text message: "The cost of all existing transactions booked is going to be calculate as no costing rule starting date is provided".

(2.1.1) If the user press "Ok", the "Starting Date" should not be set to null but to 1-1-1900. Same applies to "Fix Backdated From Date", it should also be set to 1-1-1900. Those two dates should NOT be populated in the corresponding fields but kept "internally".

(2.1.2) If the user press "Cancel", costing rule validation process stops.

(2.2) If that is the case (There are transactions whose costs needs to be calculated dated on a closed period):
A new window is going to be shown letting the end user know that there are transactions dated on a period closed whose costs need to be calculated, in fact the cost of those transactions will be calculated but not post unless the corresponding periods are opened. This new window will have an "OK" and "Cancel" button.
Text message: "There are transactions dated on a period closed whose costs need to be calculated. If you press "OK" the cost of those transactions will be calculated but it will not be possible to post them unless you open the corresponding periods. Otherwise please enter an starting date for the costing rule within an open period".

(2.2.1) If the end user press "OK" the "Starting Date" should not be set to null but to 1-1-1900. Same applies to "Fix Backdated From Date", it should also be set to 1-1-1900. Those two dates should NOT be populated in the corresponding fields but kept "internally".
Same way all cost will be calculated regardless the ones related to transactions dated on a closed period could not be posted.
Same applies to Fix Backdated Transactions.

(2.2.2) If the end user press "Cancel", costing rule validation process stops. End-user could then:
* Enter an later costing rule starting date within an open period.
* Open the periods and validate then the costing rule by do not entering an starting date


Additional validation:

* "Fix backdated from date" must always be after Costing Rule "Starting Date".

It is important to remark that:

* A period closed for an organization means that any/all documents are in status:
**Closed
**Never opened
**Permanently closed
**Mixed

* A period open for an organization means that all documents are in status:
** Open

No tags attached.
related to defect 0028423 closed umartirena Openbravo ERP API Break on Cost Adjustments Project (try-api 985) 
related to defect 0028445 closed umartirena Retail Modules [Cost Adjustments] Remove entries related to Validate Costing Rule Process that has been deleted 
Issue History
2014-11-26 13:22psanjuanNew Issue
2014-11-26 13:22psanjuanAssigned To => dmiguelez
2014-11-26 13:22psanjuanModules => Core
2014-11-26 13:22psanjuanTriggers an Emergency Pack => No
2014-11-26 13:24psanjuanAssigned Todmiguelez => Sandrahuguet
2014-12-05 14:27psanjuanProposed Solution updated
2014-12-09 10:09hgbotCheckin
2014-12-09 10:09hgbotNote Added: 0072340
2014-12-09 10:09hgbotStatusnew => resolved
2014-12-09 10:09hgbotResolutionopen => fixed
2014-12-09 10:09hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/1a024cd666f789bf12d5fa7f2004e77e2fe33b76 [^]
2014-12-09 14:55psanjuanNote Added: 0072363
2014-12-09 14:57psanjuanNote Edited: 0072363bug_revision_view_page.php?bugnote_id=0072363#r7229
2014-12-09 15:09psanjuanNote Edited: 0072363bug_revision_view_page.php?bugnote_id=0072363#r7230
2014-12-10 11:10psanjuanProposed Solution updated
2014-12-10 12:07psanjuanProposed Solution updated
2014-12-10 12:07psanjuanStatusresolved => new
2014-12-12 11:18psanjuanAssigned ToSandrahuguet => umartirena
2014-12-12 11:18psanjuanProposed Solution updated
2014-12-12 11:20psanjuanProposed Solution updated
2014-12-12 11:29psanjuanProposed Solution updated
2014-12-12 11:30psanjuanProposed Solution updated
2014-12-12 12:29psanjuanProposed Solution updated
2014-12-12 14:57psanjuanProposed Solution updated
2014-12-12 15:01psanjuanProposed Solution updated
2014-12-12 15:06psanjuanProposed Solution updated
2014-12-12 15:06psanjuanProposed Solution updated
2014-12-17 10:48dmitry_mezentsevRelationship addedrelated to 0028423
2014-12-17 20:26hgbotCheckin
2014-12-17 20:26hgbotNote Added: 0072678
2014-12-17 20:26hgbotStatusnew => resolved
2014-12-17 20:26hgbotFixed in SCM revisionhttp://code.openbravo.com/erp/devel/pi/rev/1a024cd666f789bf12d5fa7f2004e77e2fe33b76 [^] => http://code.openbravo.com/erp/devel/pi/rev/cf44dffa9a4d8d01e3bc7af598c0b1f8ac739136 [^]
2014-12-17 21:54hgbotCheckin
2014-12-17 21:54hgbotNote Added: 0072682
2014-12-17 21:55umartirenaRelationship addedrelated to 0028445
2014-12-18 17:57SandrahuguetReview Assigned To => Sandrahuguet
2014-12-18 19:07SandrahuguetNote Added: 0072713
2014-12-19 13:15hgbotCheckin
2014-12-19 13:15hgbotNote Added: 0072738
2014-12-19 14:31psanjuanNote Added: 0072741
2014-12-19 14:31psanjuanStatusresolved => closed
2014-12-19 15:07hgbotCheckin
2014-12-19 15:07hgbotNote Added: 0072742
2014-12-30 23:27hudsonbotCheckin
2014-12-30 23:27hudsonbotNote Added: 0073185
2014-12-30 23:28hudsonbotCheckin
2014-12-30 23:28hudsonbotNote Added: 0073240
2014-12-30 23:28hudsonbotCheckin
2014-12-30 23:28hudsonbotNote Added: 0073241
2014-12-30 23:28hudsonbotCheckin
2014-12-30 23:28hudsonbotNote Added: 0073250
2014-12-30 23:28hudsonbotCheckin
2014-12-30 23:28hudsonbotNote Added: 0073251

Notes
(0072340)
hgbot   
2014-12-09 10:09   
Repository: erp/devel/pi
Changeset: 1a024cd666f789bf12d5fa7f2004e77e2fe33b76
Author: Unai Martirena <unai.martirena <at> openbravo.com>
Date: Tue Dec 09 10:03:20 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/1a024cd666f789bf12d5fa7f2004e77e2fe33b76 [^]

Fixes Bug 28289:Add Starting Date and Fix Backdated From allways to Costing Rule

Modify CostingRuleEventHandler.java to allways set an Starting Date and Fix Backdated From to a Costing Rule if it has not been added manually. Take as Starting Date the Starting Date of the first period that is opened. Set the same date as Fix Backdated From.

---
M src/org/openbravo/event/CostingRuleEventHandler.java
---
(0072363)
psanjuan   
2014-12-09 14:55   
(edited on: 2014-12-09 15:09)
Verified for:

* Legal with accounting organization - Allow period control = Yes.
The organization can only have one calendar assigned. Calendar has several years starting from 2010.

Set April 2011 period as open for that organization. Starting date set for the costing rule is 01-04-2014.

Verified for:
* Legal without accounting organization.

(0072678)
hgbot   
2014-12-17 20:26   
Repository: erp/devel/pi
Changeset: cf44dffa9a4d8d01e3bc7af598c0b1f8ac739136
Author: Unai Martirena <unai.martirena <at> openbravo.com>
Date: Wed Dec 17 13:56:07 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/cf44dffa9a4d8d01e3bc7af598c0b1f8ac739136 [^]

Fixes Bug 28289: Manage null start and fix backdated from dates in Costing Rule.

Several things have been implemented in this changeset:
* A new Process Definition called 'Validate Costing Rule' has been created that replaces the old Process with the same name. This has been done to be able to use the new capabilities that these new kind of processes offer, like validations before executing the process and the posibility to show a confirmation popup. The new process action handler calls the old process java class, so all existing modules that may call or extend the old class they will continue working.
* The CostingRuleEventHandler has been removed, because it was doing a wrong validation and the fix backdated from date is managed in the CostingRuleProcess.
* 2 new functions have been created in CostingUtils ('getCostingRuleStartingDate' and 'getCostingRuleFixBackdatedFrom') that they return '01/01/1900' as costing rule Starting Date or Fix Backdated From when these are null. This has been done because in some places when these dates are null the application was giving an error. So, every time these dates are retrieved, these functions will be called.
* A validation has been added before executing the new Action Handler 'Validate Costing Rule' that shows a popup when transactions without cost calculated are found in closed periods. It asks for confirmation to proceed or the option to cancel.

---
M modules/org.openbravo.client.application/src/org/openbravo/client/application/ApplicationComponentProvider.java
M referencedata/sampledata/F_B_International_Group/AD_PROCESS_ACCESS.xml
M referencedata/sampledata/F_B_International_Group/OBUIAPP_PROCESS_ACCESS.xml
M referencedata/sampledata/QA_Testing/AD_PROCESS_ACCESS.xml
M referencedata/sampledata/QA_Testing/OBUIAPP_PROCESS_ACCESS.xml
M src-db/database/sourcedata/AD_COLUMN.xml
M src-db/database/sourcedata/AD_ELEMENT.xml
M src-db/database/sourcedata/AD_MESSAGE.xml
M src-db/database/sourcedata/AD_MODEL_OBJECT.xml
M src-db/database/sourcedata/AD_PROCESS.xml
M src-db/database/sourcedata/OBUIAPP_PROCESS.xml
M src/org/openbravo/costing/AverageCostAdjustment.java
M src/org/openbravo/costing/CostAdjustmentUtils.java
M src/org/openbravo/costing/CostingAlgorithmAdjustmentImp.java
M src/org/openbravo/costing/CostingRuleProcess.java
M src/org/openbravo/costing/CostingServer.java
M src/org/openbravo/costing/CostingUtils.java
M src/org/openbravo/costing/FixBackdatedTransactionsProcess.java
M src/org/openbravo/costing/StandardAlgorithm.java
M src/org/openbravo/costing/StandardCostAdjustment.java
A src/org/openbravo/costing/CostingRuleProcessActionHandler.java
A src/org/openbravo/costing/CostingRuleProcessOnProcessHandler.java
A web/js/validateCostingRuleProcess.js
R src/org/openbravo/event/CostingRuleEventHandler.java
---
(0072682)
hgbot   
2014-12-17 21:54   
Repository: erp/devel/pi
Changeset: 53746ee8da23d7bb74bd390f2f806509bddfb04a
Author: Unai Martirena <unai.martirena <at> openbravo.com>
Date: Wed Dec 17 21:45:17 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/53746ee8da23d7bb74bd390f2f806509bddfb04a [^]

Related to issue 28289: Little code review

---
M src/org/openbravo/costing/CostingRuleProcessActionHandler.java
M src/org/openbravo/costing/CostingRuleProcessOnProcessHandler.java
M src/org/openbravo/costing/CostingUtils.java
---
(0072713)
Sandrahuguet   
2014-12-18 19:07   
Code review done
(0072738)
hgbot   
2014-12-19 13:15   
Repository: erp/devel/pi
Changeset: 9342e75e040f8a5f7182a1b21bab3b63f6d484f1
Author: Unai Martirena <unai.martirena <at> openbravo.com>
Date: Fri Dec 19 13:15:14 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/9342e75e040f8a5f7182a1b21bab3b63f6d484f1 [^]

Related to bug 28289:Do @FixBackdateFromBeforeStartingDate@ later in the process.

Check the validation at the end of the Costing Rule Validation process when fixbackdated from and starting date are being initialized.
Also update the error message displayed.

---
M src-db/database/sourcedata/AD_MESSAGE.xml
M src/org/openbravo/costing/CostingRuleProcess.java
---
(0072741)
psanjuan   
2014-12-19 14:31   
Verified.
(0072742)
hgbot   
2014-12-19 15:07   
Repository: erp/devel/pi
Changeset: 51e45a1377bd29b973a64ed9c73c8341399f4931
Author: Unai Martirena <unai.martirena <at> openbravo.com>
Date: Fri Dec 19 15:07:05 2014 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/51e45a1377bd29b973a64ed9c73c8341399f4931 [^]

Related to issue 28289: Improve @FixBackdateFromBeforeStartingDate@ message

---
M src-db/database/sourcedata/AD_MESSAGE.xml
---
(0073185)
hudsonbot   
2014-12-30 23:27   
A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/6525fe229e06 [^]
Maturity status: Test
(0073240)
hudsonbot   
2014-12-30 23:28   
A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/6525fe229e06 [^]
Maturity status: Test
(0073241)
hudsonbot   
2014-12-30 23:28   
A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/6525fe229e06 [^]
Maturity status: Test
(0073250)
hudsonbot   
2014-12-30 23:28   
A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/6525fe229e06 [^]
Maturity status: Test
(0073251)
hudsonbot   
2014-12-30 23:28   
A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/6525fe229e06 [^]
Maturity status: Test