On 14 February 2017 at 01:00, Jacopo Cappellato <jacopo.cappellato@ hotwaxsystems.com> wrote:
> > One way to go to preserve the existing functionalities would be that of > creating one GlAccountType for each InvoiceItemType and VarianceReason > records. Then we would need to define a mechanism to map > InvoiceItemType/VarianceReason to GlAccountType. > This would make the design a bit more "correct" but still it would be very > complex, without adding much value. > Thanks again Jacopo. Variance I think is fine as-is. You can use VarianceReasonGlAccount to get directly to a GL account, no need to think about GL account types. Note that in getGlAccountFromAccountType, variance is handled early and simply. So I think the only problem is that we are overloading the glAccountTypeId with the varianceReasonId, and a separate parameter is all that's needed. I'd like to suggest a fairly simple way to get the GL account type for GL entries for an invoice . In many cases, when getGlAccountFromAccountType is called, the caller already knows the right GL account type, and we have the type in the glAccountTypeId parameter. For invoices, it's more complex. In InvoiceItemType, there is a default GL account in the defaultGlAccountId attribute. In getGlAccountFromAccountType, if we've received an invoice item but no GL account type, how about we infer the GlAccountType from the default GL account? In other words, go InvoiceItem->InvoiceItemType->default GL account->GL account type. Get the GlAccountType associated with the default GL account and use that as we look up PartyGlAccount, ProductGlAccount or InvoiceItemTypeGlAccount. If there is nothing relevant in the ...GlAccount entities, you'd end up with that default GL account and therefore that GL account type anyway. A possible alternative would be to explicitly add an attribute to InvoiceItem for a default GL account type, in addition to the current specific GL account. But surely the specific account would be of that type? In other words, we can infer it anyway, without any need for a new attribute. What do people think? We could do this but, as I mentioned earlier, my preference would be to > spend some time thinking/redefining the meaning of GlAccountTypes and (that > could be that of identifying events that are relevant for the GL) and then > clean up the system accordingly. > I have been writing up some notes on categorising GL accounts, which I will post here soon. 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. Cheers Paul -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Australia Phone: +61 3 9585 6788 <+61%203%209585%206788> Web: http://www.coherentsoftware.com.au/ Email: [email protected]
