OSCOMMERCE SUPPORT CALL 702-453-3332

Hi, all!

I'm new here but I've been reading and working with osCommerce for a while now. So here comes a question a need help with—simply because I think it's better to ask than to start messing around with the core code...

If I understand osC logic correctly,

a) zones are mainly used for tax purposes but can also be created to be used as "shipping zones"

b) shipping and payment zones do not necessarily have to relate (we DO have an account, a billing and a shipping address, don't we?)

c) nevertheless, SOME payment modules check the shipping instead of the billing address (like CoD, for a sensible reason)

d) using a tax zone in a shipping module (like zones.php) should somehow be "overruled" by the actuall billing (payment module)

Correct me if I misunderstood anything, please.

My actual problem is that for some reason ALL payment modules show up even if they're not "enabled" ($this->enable == false). The CAN be selected on checkout but when pressing "continue" a red bar comes up stating something like "Select a payment option". The payment module that WOULD be correct CAN be selected and WILL lead to continuation of the checkout.

Here's what I have set up:

—The PayPal Cart IPN and two "bank transfer" modules, one for EU IBAN/BIC transfers and one for German bank transfers (my own), set up like this:






—The "zones.php" as shipping module.

—Two "tax zones", one "European Union", containing all 25 countries (incl. Germany, taking it out didn't better it), and one "Germany" containing only Germany.

—Two tax rates, containing "European Union" as zone with 16% and 7% tax, respectively. (Only the 16% is used currently.)

—The shipping module is set up like this:
and actually everything calculates perfectly and like charm.

But I've tried with 3 test customers, and the outcome is wrong (I think) since only the shipping modules that ARE ALLOWED for that particular customer should show up—or is that not so? I even put debugging code in and it shows them being "DISABLED" but still they show on checkout!

(And changing any Sort Orders won't help, I've tried.)

Case 1: Customer living in Germany

Desired: 16% VAT should apply on both goods & shipping; Payment options shown: German Bank Transfer, EU Bank Transfer (since Germany in zone), and PayPal (since in no zone).

Actual: The same. All calculated correctly, all working. Fine.

Case 2: Customer living in Austria.

Desired: 16% VAT on goods & shipping; Payment options shown: EU bank transfer and Paypal.

Actual: German bank transfer shows up! Calculations are okay. If user selects German bank transfer, a message shows "Please select a payment method for your order." and he's returned to the payment checkout screen.

Debugging shows that German bank transfer is actually NOT enabled since the module has detected that it's not applicable for a billing address in Austria.

So why does it show up in the first place? Is that intended behaviour?

Case 3: Customer living in the U.S.

Desired: NO VAT on goods and shipping; Payment options shown: Only PayPal.

Actual: PayPal AND EU bank transfer AND German bank transfer show up. Last two are not enabled (i.e., have detected they're not applicable here). Selecting them shows above error message. Paypal works.

Shipping and goods are calculated correctly (no VAT applied). So even if I stated in the Zone Rates Shipping Module to USE tax 16%, IT DIDN'T! Great! But... why? IS it actually overruled and somehow "reset" not net values by billing to a non-VAT-applicable address?

Since I'm working with this for over 20 hours apiece now... I'm busted. Please help me see the fault I seem to overlook all the time... ;-)

Thank you.

Matthias

N.B.: Sorry for the long text, but my English isn't THAT good and I wanted to make everything clear. And, yes, my payment modules work, and have been thouroughly debugged.

> Matthias C Hormann
> N.B.: Sorry for the long text, but my English isn't THAT good and I wanted to make everything clear.
> And, yes, my payment modules work, and have been thouroughly debugged.

If all posters were so thorough (gründlich) there would a lot less postings

O.K following my conclusions if I read it all correctly.

Shipping modules:
- zones
- - zone 1 Germany is OK
- - zone 2 EUR countries without Germany is OK
- - zone 3 if you think you need to do it that way why not
- - zone 4 if you think you need to do it that way why not
- - zone 5 is OK
Tax Class
16% MwSt
Sort Order = 0
I would change that 0 into 1, if a next one: will have to be 2, etc.


Payment modules:
PayPal Zone = none is OK
Sort order of display = 0 => change to 1

EU Bank transfer:
Payment Zone = European Union is OK
Module Sort order of display = 0 => change to 2

Bank Transfer Germany
Payment Zone = Germany is OK
Module Sort order of display = 0 => change to 3


Now comes the tricky part but be assured it works.

LOCATIONS / TAXES (LAND / STEUER)

Countries (Land): I suppose they are all there +/- 240, you're going to export to all of them?

Zones (Bundesländer ist eine flashe Übersetzung): please enter all 25 EU-countries.

> Matthias C Hormann
> Two "tax zones", one "European Union", containing all 25 countries (incl. Germany,
> taking it out didn't better it), and one "Germany" containing only Germany.

Change your Tax Zones as follows:

Tax Zones (Steuerzonen):
- please enter all 25 EU countries => Austria to UK => yellow folders (25 #'s)
- now click on each yellow folder, click on DETAILS, click on INSERT, from the dropdown choose the same country as the folder is called, and in the lower field choose "Alle Bundesländer" or "All Zones" depending on the language-version in your admin.
- we're not ready yet, we need a yellow folder called: World (that's #26) , forget about details and insert here.
- still not ready, make a yellow folder called: European Union (#27) <= that's the name you gave it higher up.
- next thing is that you're going to fill that European Union with the 25 countries, the same 25 you entered already in Zones (Bundesländer).

> Matthias C Hormann
> Two tax rates, containing "European Union" as zone with 16% and 7% tax, respectively.
> (Only the 16% is used currently.)

Tax rates is easy, you need
- MWST 16%, Priority 1 <= that's for DE + EURO
- MWST 0%, Priority 2 <= that's for outside EU
- MWST 7%, Priority 3 <= you may use it in the future

Tax Classes, there is no priority there.
- MWST Hoch (High) => sind die 16%
- MWST Ohne => sind die 0%
- MWST Niedrig => sind die 7%

Keep the descriptions clear for yourself and the same within Classes and Rates.

Amount of work: 15 - 30 minutes depending on your typing, mine is 2 fingers

You can choose Germany for money transfers inside Germany
You can choose EUR for EU bank transfers

Zones will choose from the countries you entered for shipping charges

All your 3 cases will work now flawlessly

Thanks for the tip. I wonder why that should be necessary, guess I have to contemplate a little...

It would be a great help if we had better documentation, or somebody could explain the underlying logic to me! (Otherwise I'll probably spend another three 14-hour nights reading core code and trying to outguess the original programmer's intentions... :-)

berkedam, do you KNOW or think that will take care of the payment modules not showing up during checkout? I don't (yet) see much of a flaw in how I did it now. But that may well be due to mis-interpretation.

Oh well... here's a German one ;-)

'EDV ... heisst ja nicht umsonst auch 'E'nde 'D'er 'V'ernunft! ... *schmunzel*

Well, it's been another 13 hours with osC again.... guess I go and catch some sleep and follow up on this tomorrow.

Thanks again!

M.

N.B.: Re shipping zones: Yes. I'd prefer to do differently, but that's the best approximation I could make to mirror the German DHL Parcel Shipping Zones. And the prices are actually 'DHL Postpaket' net prices plus a minimal surcharge for packing material.

(And I simply HATE IPB. Giving me an 'Edit' button an when all is finished telling me 'You're NOT allowed to edit.' BAD BAD coding style. Tell the user upfront.)

G'nite now!

I KNOW it will take care of all your problems
EG you did not mention the part that INSIDE the yellow Tax Zone folders you created the Tax Zone.
And the total set-up was not complete either.

Du wirst die Logik kapieren nachdem du die Dateien in den Versand- und Zahlmodules bearbeitet hast.

BTW I forgot to mention that upon completion of the "Zone/Tax corrections" you will have to check in MyStore the Country + Zone where you store is located.

Furthermore, afterwords you will have to open (edit) and check all your "activ" modules (shipping + payment+ OT + Ship2Pay) in order to see if everything is still correct, otherwise adjust the data.

In OT don't forget to adjust the right sort order of the modules!

Choose "none" for Paypal, choose "Germany" for Vorauszahlung (Bankeinzug or whatever) choose "European Union" for EU Bank Transfer.

As said before, Zones will choose it's own shipping charges.
BTW you chose the right zones.php I see: the one from the friends

Sad to say you were wrong. I followed your instructions and introduced all these zones and stuff, and, believe it or not: IT DIDN'T CHANGE A THING.

Everything is still calculated correctly, but on the Austrian and U.S. test customer the extra (and not-to-be-allowed) payment options STILL show up during checkout. The U.S. customer even gets "German bank transfer" as suggested first (selected) option.

I'm at my wit's end. Anybody, any other ideas?

I guess there must be so many european stores using osC, how did all of you manage to handle this correctly?

Regards,
M.

I guess I can see the IDEA behind all these zone stuff... you can use them as "shipping" or "payment" zones and they actually show up in a list whenever I set a shipping and/or payment zone in the modules.

From a payment module in admin:


Makes sense. But nevertheless, why do they still show up in checkout? I really wonder what's going wrong here.

I think they should not even show up during checkout, instead of showing up and giving an error if somebody selects them.

Anybody else having these symptoms?

Too bad you can't get it right, after checking again myself and my instructions on how to do it, it still works perfectly in my shop.

Logging in with USA details, customer sees only payment conditions that are World ie "none".

Customers not being World are automagically from 1 of the 25 EUR countries and get a choice between EUR payments assigned to EUR or their respective country and of course all World = "none" payment possibilities.

Customers from a particular EUR country eg Germany only get the German Bank Transfer because that's the only one assigned to Germany, and if the European comes from eg Belgium he will than NOT see the German Bank Transfer.

I don't know what went wrong but in my samplestore with 11x payment possibilities and 7 transport methods and 7 OT possibilities and Ship2Pay, 4 Tax Rates and 3 Tax Classes it all works flawless and like a charm.

I suggest you double check your corrections and reread carefully what I wrote.

You can also send me a PM with a temp /admin/ login/pass and I will make it work for you for free.

Or I will just look in your admin where you went wrong, tell you, and you can do it yourself.

Can you send detailed screenshots with a PM? I don't know. If that's possible you can do that also.

Or you can PM me a URL from your site where I can see the detailed screenshots.

Choose any method you like but don't tell me it's not working

Editting does not work very well, is there a max time or what happend

Pls read the above as follows:

Customers from a particular EUR country eg Germany get the German Bank Transfer because that's only assigned to Germany, he will also see EUR because Germany is also EUR, and he will of course see World because all EUR countries are also in the World.

If the European comes from eg Belgium he will than NOT see the German Bank Transfer he will see EUR and if you have a bank in Belgium you could also make a posssibility that only Belgium customers see that account.

Well, all that sounds sensible to me. And actually I introduced another few shipping & payment modules just to check.

Result: Works beautifully on all SHIPPING modules, but NOT on the payment modules. I start wondering if I messed something up somewhere integrating contribs.

Guess I will revert back to an unmodified checkout_payment.php for a test, or have a close look there, at least.

Do you know if there are any known side effects from using Linda McGrath's (WebMaker) Free Shipping / Free Charge contribs? I checked the code but I see no obvious bugs.

Thanks for your help.

Oh, btw, do you put things like PayPal (worldwide) into "---none---" or "World"? If I assume correctly, "World" is supposed to mean the same (i.e., "all world" including EU)?

Hmmm. "checkout_payment.php" as well as "checkout_payment_address.php" actually ARE the unmodified files from 2.2MS2.

No untill now I did not have a need for Linda's nice contribs.



Previous posting:
Logging in with USA details, customer sees only payment conditions that are World ie "none".

Customers not being World are automagically from 1 of the 25 EUR countries and get a choice between EUR payments assigned to EUR or their respective country and of course all World = "none" payment possibilities.

BTW, did you mess with other things apart from this? You do keep a log of changes, do you, so that you know exactly which files are changed and where?

Maybe it's some mistake in my payment module, after all?

Would you care to maybe try mine and see if it does something wrong? I have it zipped up here. It's only a module, together with language files for English and German.

It would be nice to have it checked in still another setup, just to start excluding errors now.

Thank you (and if you like it, you can keep it, of course :-)

M.

Sorry I don't have a German contrib to compare with and I also don't need one.

A good working German Bank Transfer Contribution can be found here:
http://www.oscommerce.at/contributions.php?cbPath=6

Well, I'm down to code again.

The one you mention has too many frills for me, that's why I made my own.

Seem that you were right insofar as it seems to work with one of the simplest payment modules, moneyorder.

Must be my mistake, though I don't see much difference. Seems $this->update_status() doesn't get called or there is a flaw somewhere.

Again, thanks for all your help.

M.

Aaaaarrrgggh!

Can you believe it? Me saying "it has been debugged thoroughly" ... and forgetting to put in "global $order" in the class constructor???!!!

My sincere apologies...

Of course it works now, as you promised! Phew!

I'm happy and my belief in myself is back

Everything works as it's supposed to be, and I'm back to only

TWO Tax Zones:
1: EU, containing all 25 countries MINUS Germany (the store country)
2: Germany, containg only itself

FOUR Tax Rates, all sort order 0:
1: Germany 16%
2: Germany 7%
3: EU 16%
4: EU 7%

Shipping Modules, all sort order 0:
1: Linda's Free Shipping (Tax Class: none, Shipping Zone: none)
2: Zone Rates (Tax Class: 16% VAT, all net prices w/ 4 decimals)

Payment Modules:
1: Linda's Free Charge (Sort order: 0, Payment zone: none)
2: PayPal IPN/Cart (Sort order: 1, Payment zone: none)
3: Prepayment via bank transfer/EU (my own, Sort: 2, Zone: European Union)
4: Prepayment via bank transfer/DE (my own, Sort: 3, Zone: Germany)
5: CoD (for verification only) (Sort order: 4, Payment zone: Germany)

All my test cases resolve:

CASE 1 - German customer

Shipping options: Free or Zone Rates (depending on 'virtual' or not)
Payment options: Free (if virtual+no cost), PayPal, Bank transfer/DE, CoD
16% VAT for both goods and shipping cost, shown correctly.

CASE 2 - Austrian customer

Shipping options: Free or Zone Rates (depending on 'virtual' or not)
Payment options: Free (if virtual+no cost), PayPal, Bank Transfer/EU
16% VAT for both goods and shipping cost, shown correctly.

CASE 3 - U.S. customer

Shipping options: Free or Zone Rates (depending on 'virtual' or not)
Payment options: Free (if virtual+no cost), PayPal
NO VAT for both goods and shipping cost, shown correctly.

This finally makes me believe that I actually DID understand how all this zone'ing works. Nevertheless, I could bang my head for looking at the code over and over and not seeing that forgotten "global $order;" ...

It seems to me the above is actually the 'minimum' solution that works as intended. I like things being not overly complicated.

I do hope all this can be of use to somebody else. John, thanks again for taking the time and your willingness to help me. Even if the original question can now be answered: "It WAS a dumb error." Well, we're only human, after all...

Good night, everybody. Let's call it a day.

Matthias

Last change, and it REALLY works:

TWO Tax Zones:
1: EU, containing all 25 countries INCLUDING Germany (the store country)
2: Germany, containg only itself (solely for payment/shipping purposes)
3: EU, containing all 25 countries MINUS Germany (solely for payment purposes, because I want one option NOT to show within Germany)

TWO Tax Rates, all sort order 0:
1: EU 16% (set to the 'all countries' EU zone)
2: EU 7% (as above)

The construct in the post before made new article price entry impossible: osC subtracted 2x16% for all prices I entered as Gross.

I guess that actually IS a bug. I think if 'display prices incl. tax' in admin is ON, it should calculate net as

(entered gross) - (tax applying to local store),

NOT as

(entered gross) - (add all tax % within tax class regardless of WHERE tax applies)!

It is stated in the docs somewhere that prices displayed for somebody not logged-in is shown as gross price (incl. tax) AS VALID AT THE STORE LOCATION. So one should assume the same rule applies when ENTERING gross prices for articles.

THE END. (I hope.)

M.

[1] I'm not so sure.
[2] You named them EU_1 and EU_2 or something like it? Because otherwise ...

Where is the 0% Rate for exports to outside the EU?
And you do not believe me but sort order is NECESSARY.

But of course as in your other posts you are entitled to your own opinion.

EUR rules ask for display of prices including the Tax Rate applicable in the store-country as well as indication of all extra's like transport cost, packing, insurance, payment surcharge, etc etc.

If I recall correctly I gave the link in another forum already.

Those prices will be valid inside Germany and of course inside the EU.

In the correct set-up, people who log in from outside EU with an outside EU shipping address will get an OT prices-display on check-out without Tax but only if you have a 0% Tax Rate.

Charging World customers EU Tax is not beneficial anyway because you will have to transfer received Tax to the German Tax authorities anyway, better show lower prices ie without Tax to all customers from outside EU.

Entering gross or net prices in the article descrition on page
/categories.php?cPath=23&action=new_product
does not make any difference.

osCommerce will either add Tax or deduct Tax depending whether you insert the amount in the upper- or lower box.

Easiest is to choose the Tax Class first and only than insert the price.

Sure, "European Union" and "SP European Union" (for Shipping/Payment EU) actually.


Not needed, tax "---none---" defaults to zero, of course. And since we have only the EU zone set up for 16% tax, all others will be 0%.


In principle, agreed. But since both are = 0, and there can only be articles with EITHER 7% OR 16% it should be okay (and actually add tax instead of compounding it in OT).


Sure do. That's why we set 'Display prices with tax' and have all these extra pages... And it makes much sense that osC defaults to the store places's tax rate for non-logged-in users.


They DO get exactly that. Without the 0% tax rate and the 'world' zone. That would really only be needed if one explicitly wanted to show "0% tax" on the orders/invoices.


That's exactly what's intended and what it does now. (Actually, I'd LIKE to show the higher prices to have the 'same' price for everyone, but it makes no sense of course since it would be against the law, and I'd have to give it to the state anyway.)


Well, it does. Because one is calculated from the other (as you say). And if I want 'even' gross prices, it's best to set tax class and enter the gross so net gets stored with max. precision (i.e., 4 decimals).

Exactly here lies the BUG. Because osC will calculate ALL taxes in the specified tax class and simply add (or compound) them, not only the one applicable to the store's location! Thusly, you'll get a wrong price if you have a 'German' tax zone w/ tax rate 16% plus an 'EU' tax zone (which doesn't include Germany) w/ tax rate 16% and use the same tax class for the 16%. It then simply deducts 2x16% from the entered gross price instead of checking against the store location, finding it in the 'German' zone and only subtractiong tax that is applicable at the store's location, i.e. 1x16%. It can be circumvented by the scheme I use now but I consider it a bug nevertheless.

This is actually why I eventually made the whole EU one (tax) zone again, including Germany. Of course, now I had to introduce the 'SP EU' zone (excluding Germany) just for the purpose of having different shipping/payment options within and without Germany.

But since all this works now, I'm already working on another general thing and try to find out what the better approach would be:

If one has a product like an eBook that can be either downloaded or shipped on CD, and wanting to store only ONE article—would it be better to set a product weight in the article (messing up shipping on mixed carts) and modify, say shopping_cart.php to set weight on a 'virtual' product to zero, or introduce a new product attribute like 'additional weight' (which would mean more coding or finding the bugs in existing contribs). The latter one seems more appropriate, I feel.

Well, I'll check and probably open another thread on that.

Board is not working well so I had to copy/paste/fiddle this continuing story.
I have World and 0%: no Tax is showing in ../checkout_confirmation.php if I order from Antartica.
What am i doing wrong?
Since when is it against the law to charge some people/groups higher prices?
So sorry to inform you that 4 decimals is not enough in the case of for example € 12,00 and 7% Tax and there are other cases in other countries with other amounts and other %%.
There is nothing wrong with the calculations as far as I know because apart from Germany there are countries in the world that have for instance
1/ a set Tax and have
2/ a second compounded Tax.
and osCommerce should be usable for those countries also.

Anyway bugs should be reported here: <http://www.oscommerce.com/community/bugs>