On 10 February 2017 at 21:50, Jacopo Cappellato < [email protected]> wrote:
> It is not a bug, because the system use that value to decode the account > id. > Thanks Jacopo. I still think we have a serious problem. I see in getGlAccountFromAccountType at line 533 http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l533 <field-map field-name="invoiceItemTypeId" from-field="parameters.glAccountTypeId"/> So yes, at that point the method is expecting an InvoiceItemType, and you could say the parameter is misnamed. There is some method to the madness :-). However, before that, at line 438 http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l438 it has called getPartyGlAccountInline, which wants a GL account type. And if the getGlAccountFromAccountType has not found specific GL accounts for a party or product, towards the end at line 556 it calls getGlAccountTypeDefaultInline. getGlAccountTypeDefaultInline again expects a GL account type, not an invoice item type. http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l566 I think we need separate parameters invoiceItemTypeId and varianceReasonId, instead of attempting to overload the meaning of the glAccountTypeId parameter. What do you think? Thanks Paul Foxworthy -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Australia Phone: +61 3 9585 6788 Web: http://www.coherentsoftware.com.au/ Email: [email protected]
