Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0037275
TypeCategorySeverityReproducibilityDate SubmittedLast Update
design defect[Openbravo ERP] 03. Procurement managementmajoralways2017-11-10 12:292018-01-30 17:49
ReporterngarciaView Statuspublic 
Assigned Tononofrancisco 
PriorityurgentResolutionopenFixed in Version
StatusnewFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0037275: Matched Invoice records for already invoiced order lines are only created the first time except in GR-Create Lines From Invoice

DescriptionMatched Invoice records for already invoiced order lines are only created the first time except in GR-Create Lines From Invoice.

Currently, when an already invoiced order line is received in more than one goods receipt line, the purchase invoice line is associated only with the first generated goods receipt line. Matched Invoice records are always created for this first line.

For next lines, the Matched Invoice records are only created when the second goods receipt line is created in Goods Receipt window by Create Lines From process and selecting the invoice line. The Matched Invoice records are not created when the second goods receipt line is created by:

- Pending Goods Receipt process
- In Goods Receipt window by Create Lines From process and selecting the order line
Steps To ReproduceAs group admin role:
   Create three Purchase Orders, add more than one unit of two products to them and book them

   Create three Purchase Invoices and invoice the orders completely

   1. Go to Pending Goods Receipt window, select the two lines of one of the orders and decrease the quantity in one of them. Process it
      Repeat the process for the pending line.
      Check in Matched Invoice the records have been created only for the first goods receipt
   2. Go to Goods Receipt window and open Create Lines From pop-up and select the second purchase order. Select the two lines and decrease the quantity in one of them. Complete it
      Repeat the process for the pending line.
      Check in Matched Invoice the records have been created only for the first goods receipt
   3. Go to Goods Receipt window and open Create Lines From pop-up and select the third purchase invoice. Select the two lines and decrease the quantity in one of them. Complete it
      Repeat the process for the pending line.
      Check in Matched Invoice the records have been created only for the two goods receipt

   Go to Purchase Invoice window and check all the lines are related with the first created goods receipt for each case
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to design defect 0031313 closedTriage Omni OMS Matched Invoice records are created in the Create Lines process (selecting order lines) but not in Pending Goods Receipt process 
related to defect 0030430 newTriage Omni OMS No price correction adjustment is created whenever a receipt is not created from an invoice but from the order related. 

-  Notes
(0100509)
dmiguelez (developer)
2017-11-14 11:46
edited on: 2017-11-27 17:30

Moved to design defect:

We have M_InOutLine_ID reference in C_InvoiceLine which can hold information for a single Goods Receipt Line only. In the scenario reported we have multiple M_InoutLine_ID for a single C_InvoiceLine_ID. At the time of first partial Goods Receipt we mark Invoice Line ID with first M_InoutLine Reference and only for this record Match Invoice record is created and other are skipped.

Fixing this issue would require a deep refactor in the code and in the way to store the relationships between invoice lines and shipment lines.

Moved to design defect and removed resolution time.


While trying to fix this Issue, several solutions were proposed, but none of them was correct, also, some things were noted:

* Proposal: Create the MatchInvoice in the CreateFrom process. This is not correct. The MatchInvoice shold be created when completing the Document.
  If it is created with the process, it might happen that the user changes the data of the Goods Receipt Line before completing the Document.
  In this case the MatchInvoice record does not reflect the changes
* Note: CreateFrom_Shipment_data.xsql. Query updateInvoiceOrder. This is not correct
  Example: Create a Purchase Order of 5 Units. Create two Purchase Invoices of 3 and 2 units against the Purchase Order. Both Invoice Lines are related to the Order Line.
           Create a Goods Receipt of 1 unit. Following the logic of the query, this reception line is linked to both Invoice Lines. That is not correct.
           Also, it does not fully complete either line, so it is not possible to create a new relationshipt again

(0102002)
dmiguelez (developer)
2018-01-26 14:42
edited on: 2018-01-26 14:47

Additional problems related with this Issue:

As group admin role:
   Create a Purchase Order for any Product with 10 units

   Create two Purchase Invoices from this Order with 5 units each.

   Go to Goods Receipt window and open Create Lines From pop-up and select the purchase order. Select only 5 units from the line. Complete it.

   Check in Matched Invoice the records have been created for the two invoices, both with 10 units instead of 5.
   There should have been only one record, for one of the Invoices, with 5 units

(0102073)
dmiguelez (developer)
2018-01-30 17:49

The problem with this Design Defect is that the creation of the Match Invoice in this scenario is not fully resolved.
That is why there are so many problems related to performing the flow this way.
And all of them must be fixed at the same time.

The problem is raised when:
- There is a Purchase Order
- There is a Purchase Invoice related to the previous Purchase Order
- A Goods Receipt is created and it is partially linked to the Purchase Order using the Create Lines From button

The workaround to this problem is to link the Goods Receipt with the Purchase Invoice instead.

More specifically:

The Matched Invoice is created always in the M_InOut_Post process by creating a record for every C_InvoiceLine with it's M_InOutLine_ID related to the line being processed.
That creates a restriction, an Invoice Line can only be associated with one InOut Line.

There is one exception though, when usign the Create Lines button and selecting the Purchase Invoice.
In this case, the Matched Invoice is created manually in the CreateFrom.java process, and the M_InOutLine_ID of the Invoice Line is set as null, so it is not duplicated by the M_Inout_Post.
However, this is done because the Invoice Line has been manually selected and it is known by the process.
In the case that the selected record is a Purchase Order, that can be linked to many Purchase Invoices, all of them with different quantities than the current InOut Line, the process would not be able to know how to associate the Purchase Invoices to the InOut Line.

Example:

Purchase Order of 10 Units
Two Purchase Invoices of 5 Units each
One Goods Receipt of 8 Units.

How should the Goods Receipt Line be related to the Purchase Invoices?
It is not possible to "partially" relate 3 units to one of the Invoices as of now.
Therefore, it won't be possible to manage the creation of the Matched Invoices as it is being done as of now.

Understanding and properly fixing this problem for all the scenarios is quite complex, and should be done carefully.

In the code, most of the problem can be found in CreateFrom.java, Lines 2033-2067:

try {
                CreateFromShipmentData.insert(conn, this, strSequence, strKey, vars.getClient(),
                    data[i].adOrgId, vars.getUser(), data[i].description, data[i].mProductId,
                    data[i].cUomId, strMovementqty, strAumQty, data[i].cAum, data[i].cOrderlineId,
                    strLocator,
                    CreateFromShipmentData.isInvoiced(conn, this, data[i].cInvoicelineId),
                    strQuantityorder, strProductUomId, strmAttributesetinstanceId,
                    data[i].aAssetId, data[i].cProjectId, data[i].cCostcenterId, data[i].user1Id,
                    data[i].user2Id, data[i].cBpartnerId, data[i].explode, data[i].isorder);

                if (strType.equals("INVOICE") && !data[i].cInvoicelineId.isEmpty()) {
                  CreateFromShipmentData.insertInvoiceAcctDimension(conn, this, strSequence,
                      vars.getClient(), data[i].adOrgId, vars.getUser(), data[i].cInvoicelineId);
                } else if (!data[i].cOrderlineId.isEmpty()) {
                  CreateFromShipmentData.insertAcctDimension(conn, this, strSequence,
                      vars.getClient(), data[i].adOrgId, vars.getUser(), data[i].cOrderlineId);
                }
                if (!strInvoice.equals("")) {
                  String strInOutLineId = CreateFromShipmentData.selectInvoiceInOut(conn, this,
                      data[i].cInvoicelineId);
                  if (strInOutLineId.isEmpty()) {
                    CreateFromShipmentData.updateInvoice(conn, this, strSequence,
                        data[i].cInvoicelineId);
                    CreateFromShipmentData.updateBOMStructure(conn, this, strKey, strSequence);
                  } else {
                    CreateFromShipmentData.insertMatchInv(conn, this, vars.getUser(),
                        data[i].cInvoicelineId, strSequence, data[i].cInvoiceId);
                  }
                } else
                  CreateFromShipmentData.updateInvoiceOrder(conn, this, strSequence,
                      data[i].cOrderlineId);
              } catch (final ServletException ex) {
                myMessage = Utility.translateError(this, vars, vars.getLanguage(), ex.getMessage());
                releaseRollbackConnection(conn);
                return myMessage;
              }

- Issue History
Date Modified Username Field Change
2017-11-10 12:29 ngarcia New Issue
2017-11-10 12:29 ngarcia Assigned To => Triage Finance
2017-11-10 12:29 ngarcia Modules => Core
2017-11-10 12:29 ngarcia Resolution time => 1512082800
2017-11-10 12:29 ngarcia Triggers an Emergency Pack => No
2017-11-10 12:29 ngarcia Relationship added related to 0031313
2017-11-10 12:30 ngarcia Issue Monitored: networkb
2017-11-10 13:15 dmiguelez Assigned To Triage Finance => nonofrancisco
2017-11-14 11:46 dmiguelez Note Added: 0100509
2017-11-14 11:47 dmiguelez Resolution time 1512082800 =>
2017-11-14 11:47 dmiguelez Type defect => design defect
2017-11-14 13:54 ngarcia Relationship added related to 0030430
2017-11-27 17:30 dmiguelez Note Edited: 0100509 View Revisions
2018-01-26 14:42 dmiguelez Note Added: 0102002
2018-01-26 14:46 dmiguelez Note Edited: 0102002 View Revisions
2018-01-26 14:47 dmiguelez Note Edited: 0102002 View Revisions
2018-01-30 17:49 dmiguelez Note Added: 0102073


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker