Bob defining what to charge is done by the method you describe, OOTB. In accounting though you need a GL number assigned to put in the right reporting category.
jonatan: i could not find a english description so I am of no help. ========================= BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro> Bob Morley sent the following on 5/7/2010 12:51 PM: > > jonatan soto wrote: >> In Spain (and I think other countries of EU) uses a predefined >> hierarchical >> GL. If I create subaccounts will vulnerate the integrity of the PGC (Plan >> general contable) so I don't think that is the solution but I understand >> your comment. It will work for US with no doubt. >> In fact, it was impossible to understand what I wanted to say because I >> didn't put it in context. I continued an old topic last week talking about >> the integration of the spanish PGC to Ofbiz and this time I created a new >> one w/o a reference to the other. >> >> Anyway I appreciate your input. >> > > Right now Ofbiz supports binding a particular tax authority in a specific > geographical region for an internal organization to a specific GL Account > (as you have indicated). The short-coming as I see it is that you could not > have multiple rates supported by that tax authority go to different GL > accounts. The use case here would be having a tax authority that charges > AST ("A" sales tax) and BST ("B" sales tax) but wants the taxes collected > and remitted to different accounts / on different schedules. > > If this in any way resembles your problem then I think the solution may be > to provide an override gl account on the tax_authority_rate_product table > (similar to other override gl account fields in the system). The idea would > be when an order adjustment that is related to the "AST" sales tax is posted > it would first check this override gl account and (if not set) fall back on > the standard gl account for that tax authority / geo. In the end you could > have separate GL accounts for each tax rate associated with the tax > authority in the system. > > Then again it is likely I missed the point too. :)
