On Fri, Feb 10, 2017 at 9:04 AM, Paul Foxworthy <p...@cohsoft.com.au> wrote:
> Hi all, > > As you might guess if you've been looking at Jira and the dev list lately, > I've been working on purchases and sales generating GL transactions. > > Please have a look at the createAcctgTransForPurchaseInvoice method in > applications/accounting/minilang/ledger/GeneralLedgerServices.xml > > line 2024 in trunk does this: > > <set field="debitEntry.glAccountTypeId" > from-field="invoiceItem.invoiceItemTypeId"/> > > Wat? > > There are two different sets of values defined in two different places for > invoice item types and GL account types. Surely you can't just copy a value > from one to the other? Shouldn't there be a service right here to find a > decent GL account type based on the invoice item type? > > Later on, the getGlAccountFromAccountType service looks at all sorts of > things to decide the final GL account to use. But the GL Account *type* is > an input to that. > > Am I missing something, or is this a very nasty bug? > It is not a bug, because the system use that value to decode the account id. However it is a mess that we should improve: the whole GL posting configuration mechanism need to be refactored, improved and simplified. We should start by deciding what should be the real purpose of a few fields, like the GL Account Type (that we could consider as the event that is triggering the transaction). In short, we need to identify the following: * how to represent the events (invoice, payment, payment application, inventory receive, inventory issuance, inventory adjustment etc...) * how to map events and its subelements (Cr and Dr components) to actual GL Accounts Best regards, Jacopo
