Hi Paul, thanks, this is really a valuable conversation; please see inline:
On Tue, Feb 14, 2017 at 1:36 AM, Paul Foxworthy <p...@cohsoft.com.au> wrote: > [...] > I have been writing up some notes on categorising GL accounts, which I will > post here soon. Great! > It seems very messy. At the moment I agree redefining or > clarifying the meaning of GL account types is a good idea. > > When you talk about "identifying events relevant for GL", I'm not quite > with you. Are you suggesting a more data driven approach rather than the > specific services > createAcctgTransFor... ? If so, yes that would be a good idea and more > extensible. > Each of the "macro events" would map to one of the existing specific services createAcctgTransFor<EVENT> However, for each we could define more granular events. For example, for the "macro event" represented by the "creation of a Purchase Invoice" (which is associated to the service "createAcctgTransForPurchaseInvoice" we could define the following granular events and each of them would be mapped to a specific account id: PURCHASE_INVOICE_CREDIT this will be mapped to an account id for "Accounts Payable" PURCHASE_INVOICE_DEBIT_PINVOICE_ADJ this will be mapped the account id for purchase invoice adjustment PURCHASE_INVOICE_DEBIT_SHIP_CHARGES this will be mapped the account id for purchase invoice shipping charges etc... (one for each invoice item type). With a mapping like the one above, the service createAcctgTransForPurchaseInvoice would simply do the lookup to resolve the gl accounts for the posting. I am aware I am (on purpose) ignoring several details, but this is just the general idea. Jacopo
