Not-6102 | [IDEMPIERE] hieplq created IDEMPIERE-3374 Set default value on Callout_AD_Column don't respect null value | 04:46 |
---|---|---|
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3374 | 04:46 |
*** Sajeev has joined #idempiere | 05:25 | |
*** Sajeev has left #idempiere | 05:26 | |
*** Saj has joined #idempiere | 05:42 | |
Not-6102 | [IDEMPIERE] hieplq updated IDEMPIERE-3374 Attachment set to "IDEMPIERE-3374.patch" | 05:52 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3374 | 05:52 |
Not-6102 | [IDEMPIERE] hieplq updated IDEMPIERE-3374 | 05:54 |
Not-6102 | [IDEMPIERE] it's more general when add this logic to GridTab.setValue | GridField.setValue but need more time to test than place on [^IDEMPIERE-3374.patch] | 05:54 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3374 | 05:54 |
Not-6102 | [IDEMPIERE] hieplq updated IDEMPIERE-3374 labels set to "+Patch" | 05:54 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3374 | 05:54 |
Not-6102 | [IDEMPIERE] hieplq updated IDEMPIERE-3374 status set to "Peer Review Queue" | 05:54 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3374 | 05:54 |
Not-6102 | [IDEMPIERE] hieplq created IDEMPIERE-3375 import/export csv should use AD_Element.ColumnName to lookup columnName.ColumnName | 08:07 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3375 | 08:07 |
Not-6102 | [IDEMPIERE] hieplq updated IDEMPIERE-3375 labels set to "+Patch" -Attachment set to "IDEMPIERE-3375.patch" -description set to "current csv export/import use AD_Element.name to lookup for AD_Element_ID but value of AD_Element.name can duplicate so can get error like {code:java} <AD_Column>: AD_Element_ID[Name] resolved multiple times = (Description) / <AD_Column>: AD_Element_ID[Name] resolved multiple times = | 09:00 |
Not-6102 | (Description) / {code} better use AD_Element.ColumnName" -summary set to "import/export csv should use AD_Element.ColumnName to lookup" | 09:00 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3375 | 09:00 |
Not-6102 | [IDEMPIERE] hieplq updated IDEMPIERE-3375 status set to "Peer Review Queue" | 09:00 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3375 | 09:00 |
Not-6102 | [IDEMPIERE] norbert.bede updated IDEMPIERE-3359 description set to "Costing. Average PO Use case - create - document with 3 products. post it (eg. shipment) - document includes 2 products with proper m_costdetail 1 product with issues. P1. OK - cost calc has no error P2. OK - cost calc has no error P3. ERROR in costing calculation << this line prevent to create costing records for P1, P2 well. *SUMMARY*: When | 13:08 |
Not-6102 | document has multiple lines-products and one of them has costing error in posting transaction, then transaction is rolled back and no costing records are created. This error cause products costing calculation sequence has gaps and prevent to calculate properly. This cause eg. error logs in case of shipments in SEVERE LEVEL: org.adempiere.exceptions.AverageCostingNegativeQtyException *SOLUTION/IDEA:* new posting | 13:08 |
Not-6102 | status - costing error. when above scenario happening, then costing records MUST BE created for P1, P2 and not for P3. in this case this new status can be set, and accounting consequence can be created." | 13:08 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3359 | 13:08 |
Not-6102 | [IDEMPIERE] norbert.bede created IDEMPIERE-3376 Costing Records are calculated in some cases from facts instead costdetail/Average PO | 13:16 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3376 | 13:16 |
Not-6102 | [IDEMPIERE] norbert.bede updated IDEMPIERE-3359 description set to "Costing. Average PO Use case - create - document with 3 products. post it (eg. shipment) - document includes 2 products with proper m_costdetail 1 product with issues. P1. OK - cost calc has no error P2. OK - cost calc has no error P3. ERROR in costing calculation << this line prevent to create costing records for P1, P2 well. *SUMMARY*: When | 13:59 |
Not-6102 | document has multiple lines-products and one of them has costing error in posting transaction, then transaction is rolled back and no costing records are created. This error cause products costing calculation sequence has gaps and prevent to calculate properly. This cause eg. error logs in case of shipments in SEVERE LEVEL: org.adempiere.exceptions.AverageCostingNegativeQtyException *SOLUTION/IDEA:* new posting | 13:59 |
Not-6102 | status - costing error. when above scenario happening, then costing records MUST BE created for P1, P2 and not for P3. in this case this new status can be set, and accounting consequence can be created. _*REMARK:* additionally we recognise the following happens. WHEN posting submitted then new transaction created and start costing methods. when costing cant be calculated then POSTING rolled Back for ALL Products | 13:59 |
Not-6102 | included in transaction. ONLY one solution is we can imagine here - after lot experimenting - SPLIT posting and Costing resp. call 2 methods when costing fall then return back to continue to next costing record product._" | 13:59 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3359 | 13:59 |
*** Danny has joined #idempiere | 19:05 | |
Danny | Hello everyone | 19:06 |
Danny | Someone in here? | 19:06 |
*** Danny is now known as Guest7865 | 19:06 | |
*** Guest7865 has quit IRC | 19:30 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!