Hey Darryl, Thanks for bringing this up and making the proposal. Have you seen what Dennis has done? I am curious how that worked.
Also, just for reference, have you seen http://code.google.com/p/getpaid/wiki/TaxHandling ? One thing I didn't see expressly mentioned in what you were proposing is the ability to distinguish between taxing the items in the cart and taxing the items+shipping. I know this is a general need that exists. I was reminded of it when testing the Google Checkout processor and seeing how they handle taxes. Worth a look if you haven't seen it (see the README for link to dev checkout account area). Cheers, Chris On Thu, Aug 28, 2008 at 12:51 AM, Darryl Dixon <[EMAIL PROTECTED]>wrote: > Hi All, > > There have been various discussions on this list about Tax vis-a-vis > GetPaid. Currently, tax is implemented with an ITaxUtility, but the > implementation defeats the stated purpose of a utility (no context) and is > really just an adapter in disguise. I am thinking about wiring up a tax > framework based on an adapter for a context. Either a Buyable content item > or the corresponding LineItem. This would enable stuff like easily > displaying tax in the 'Add this to my cart' style portlets. > > Currently, the Price for an object is acquired via an adapter for the > context (IBuyableContentAdapter(context).price), and I believe that Tax > should be able to be generated/accounted for in much the same way, eg > ITaxPayableAdapter(context).tax, which could return, similarly to the > ITaxUtility currently, a dict of the various taxes owing on the item > currently. Probably, in fact, it would need/want to be a multi-adapter based > on the context and the request, so that the adapter could take into account, > eg, the area that the customer is registered for (are they out-of-state, in > another country, etc...), so: getMultiAdapter((context, request), > ITaxPayableAdapter).tax... (maybe I'm wrong and we don't need the request > for that? Not sure, anyhow...) > > At the checkout/shopping cart level, a different adapter could then > calculate tax on the entire shopping cart, as a multi-adapter for the cart > and the request. It would be able to aggregate the tax from the individual > items, as well as from shipping costs, etc, and return a tax dict as per > previous. > > It is my impression that doing this will currently only require a very > small change at the checkout level (getMultiAdapter instead of getUtility, > effectively), but that baking this in pervasively everywhere else is a lot > bigger (eg, in the buyable portlet showing 'Price is: $4.00 + $0.50 sales > tax' or similar... > > Does anyone have any thoughts on this? Is it worth my while to sketch out > some code on a branch somewhere or is there a strong push/momentum to head > in a different direction already? > > regards, > Darryl Dixon > Winterhouse Consulting Ltd > http://www.winterhouseconsulting.com > > > > -- Cofounder and CEO ifPeople - Innovation for People www.ifpeople.net t: 678-608-3408 130 Boulevard NE, #6 Atlanta, GA 30312 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "getpaid-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en -~----------~----~----~----~------~----~------~--~---
