Ideas on the best way to do this (if any)

[ronabop]

Here's the nut to crack:
Variable pricing and currencies based on *regions*.

Here's an example case:
A company sells widgets internationally, and in addition, salesfolk who are responsible for their area get a cut.

Thus, a widget that sells to a user in the southern US may go for $1.25, with BillyBob getting a $0.25 cut. However, in the northeast US, it sells for $1.35, with Buffy Smithers III getting a $0.07 cut. Meanwhile, over in Europe, Tony Charles gets 4% (in UK pounds) tacked onto each sale in commission for UK sales, and Benoit Chirac gets .25 in Euros tacked on to each sale in pounds.

I'm currently thinking of it in terms of a few pieces:
1. On the fly currency conversion.
2. On the fly price markups based on fixed amount or percents depending on region.
3. On the fly geolocation based on IP, so user pricing is deterministic (yes, I know about this minefield...)

Am I pushing the limits of what zencart even *can* do, to where I should custom write a system to do this?
Does somebody already know of a way to get zencart to at least emulate this kind of behavior?
If ZenCart *can't* do this, is there anybody who *can*?

(No actual stereotypes about names and locations were harmed in the composition of this forum posting)

[DrByte]

Sure, you can do that with Zen Cart. Zen Cart already tracks the currency in which an order is placed.

If you need to alter the way in which product-pricing is done, you'll need to study the pricing functions and extend their usability to do extra things such as you've described, with consideration of how the shopping-cart and order classes work together through the checkout process etc.

Not a small custom-coding process, but nonetheless do-able.