Get this Wholesale thing correct.

[Skipper]

Maybe it's time to get the wording right for this wholesale-thing. TB would really stand apart.

"Cost price" is the acquisition cost of goods. That can be the price the merchant pays for merchandise, or the cost of making things for a manufacturer.

"Retail price" is the price end-customers pay.

"Wholesale price" is the price a wholesaler pays. A wholesaler, also called reseller, usually buys a larger quantity and gets a price discount to do so. That could be a percentage of the retail price, or a defined price. "Wholesale price" is also called "trade price".

Depending on the industry, you could have other, different prices. In my industry (home decoration), you can find "prescriptor prices" : An interior designer who needs 1 piece of something for a project doesn't pay retail, but with a quantity of 1 doesn't qualify for wholesale. As an incentive, he gets a price somewhere between retail and wholesale.

So changing "wholesale price" to "cost price" would correct this left-over from Prestashop.

[Traumflug]

@Occam

and how would you make it happen then for example that the checkout - let’s say in in Germany - displays the net sum plus required tax totals after you defined this (B2B) customer group with prices tax excl.?

The same way one always does. Prices for ordinary customers have a price with and one without tax, just as prices for business customers do. Distinction is just a matter of a different display.

Removing the idea of a B2B mode in favor of more universal means opens entire new opportunities. For example, one can sell wares meant for ordinary customers to business customers and vice versa. As long as nobody is logged in, prices with taxes are displayed (as law requires), as soon as a visitor is recognized as a business customer (by logging in), display changes to prices without tax.

If a merchant's idea is to have a B2B-only shop (which is a bit tricky to get it right under German legislation), simply apply these B2B price display rules to customer groups "Visitor", "Guest" and "Customer". That's it, pretty straightforward.

[Occam]

@Traumflug I'm sorry but I'm afraid you didn't get what I was talking about - or you are not familiar with the legal requirements in Germany and other European countries. I't is not that simple! It took me a lot of time to explain this to the PrestaShop team, how the checkout (and the invoice) for B2B has to look like. And finally it works for 1.6 and I guess in thirty bees too. Your proposal would be a step back.

[Traumflug]

Perhaps it'd be a good idea to make a list of what distinguishes a B2B shop from a shop displaying prices without tax, then. I'm aware of these:

• Prices are displayed without tax, still tax is added to the price to pay and mentioned at the bottom of the cart/checkout and on the invoice.
• A mechanism making sure a customer is indeed a business customer. Typical solution is to ask the customer for a tax ID (available field on the signup page), then to give these customers some property qualifying them as B2B customers (doable by assigning them to a group).
• Allow customers to order without paying (payment happens by invoice later).

As you talk about "how the checkout and invoice should look like": well, that's exactly what I mean, too: it's a pure display thing. All the core calculations remain the same. Instead of checking a shop-global flag/property, one better looks for a customer group property when rendering the screen and PDF display.

[Occam]

@Traumflug Just to quote a working draft I wrote for the PrestaShop team referring to requirements of AEUC in February 2016:

Mistakenly the programmers seem to assume that it is enough in B2B mode to indicate all prices net and refrain entirely from a statement of VAT on goods and shipping. Product prices B2B are displayed correctly excl. tax in order summary, but without tax total amount and total amount incl. tax and products and shipping, which is mandatory for B2B within the same European country. Pure net prices are only correct for orders from other European countries or outside the EU.

The latter makes it difficult to identify a business customer alone by his tax ID, because you need a proof if he is EU resident or not (Orders from Switzerland are btw a good example that this wouldn't even work within Europe). And given the EU business partner is a company, but doesn't offer his VAT no. you need to apply the taxes of the delivery country.

Moreover, you need to add a note on every invoice depending on the destination country, e.g. - tax free export delivery for orders from non-EU countries (B2C/B2B) - tax exempt intra-Community supply for orders from EU countries (B2B) etc.

And if this weren't enough you have to take into account the delivery quota for B2C. If you cross a certain threshold (depending on the destination EU country's law) you need to apply the taxation according to the country of destination, wheras below this threshold it's the tax of the delivery country.

And then there is the special case of the small scale entrepreneur, who is not even allowed to specify any tax, but needs to indicate in his shop and on the invoice that he is not allowed to display taxes at all (which is not equal to a display tax incl.!) Here some informations for German community members.

Eventually every infomation the shop gives his customers is a display thing. Ok so far! So basically I totally agree with you, but the devil's in the nuts and bolts, especially for those poor chaps (in Germany, Austria and other countries) who are in urgent need to apply this botched module AdvancedEUCompliance, which in my view deserves to be completely rewritten.

And this is just the situation in Europe. So don't forget that thirty bees is a US company - and the tax laws and particular rules in the States are legion afaik.

[Traumflug]

Excellent, thanks for the outline, @Occam.

Actually I thought about rewriting AEUC, too, but so far I had no golden idea on how to do it substantially better. Applying rule by rule, as written into law, can be done, of course, but also inevitably ends up in a large pile of hardly maintainable code.

[Occam]

Sounds great, @Traumflug. You should have a look into EU legal. The German forerunner to AEUC had more features than the slimmed-down French successor.

[dynambee]

@lesley said in Get this Wholesale thing correct.:

What about Cost Wholesale Price Retail Price for the 3 pricing areas?

I've been away for a bit and otherwise busy and unable to post here so my reply is a bit late.

In our business we often have different cost prices from different suppliers for the same product. We base our retail prices on a combination of supplier priority, supplier price, and supplier stock availability. It's built into our pricing calculation system.

I think 30bz should focus on being a top class system for selling online and make sure it can be easily integrated into popular ERP systems that are likely to be used by medium to larger businesses. Having a strong API is certainly a critical part of that but perhaps providing connectors for one or more popular ERP systems would be a good idea? It seems like this would be a better use of limited resources than attempting to reinvent the wheel by adding ERP features to 30bz itself.

Just my 2yen's worth.