VirtueMart Forum

In my opinion the default displayed Price (in Product Backend) should be with/without Vat/TAX aka (Final Price) because it's what all costumers or company's will pay to us....
All we pay the taxes/vat when we buy something else...  only in international sellings we dont have pay that country tax/vat ..  but how many of us use the VM in our local country ?...
I think it's even more easy to control the price from the Manufacturer Provider if we have that Final Price, so i think it should be the Final Price the default and not the Base Price like we got until now...

---

One of the most important things in every shop is the FINAL sales price.
In the VM2 we can not edit the most important Price that is the Final Price.
In the old VM1 this was possible and in the VM 2 this is not possible, and we all have more work to get the final price to users views because we have to do some math, to get the price + VAT/Tax ... Now we must be always with a calculator turnned ON.

Case study: If some other Shop have they FINAL price price to 450€/$ .... and Your webShop has the same product but with different price 500€/$, You have to change it!!! Right ???
You can do a better price so you have to change it to 449€/$, what do you do in VM2?
Takes many time to change many products because we have to take out the rate tax/vat to get the value that we want.

Please some developer give us the right to change (edit/update) directly the Final Price.. its very very important! Dont you think?

PS: And this is also an old question in Virtuemart 1, at least for me...
Like you could see in the post link ( since April 15, 2011 with many Readers) ...
http://forum.virtuemart.net/index.php?topic=85119.0

I voted for the final price system in the backend = Web store owner sets the final price   (OR admin selects which system of these two is used). ((And the discounts are calculated from the final price either with or before taxes.))

I think both should be displayed. 

Quote from: Hutson on March 02, 2012, 19:17:43 PM
I think both should be displayed. 

I agree. Both displayed. Counting just has to be based on the one.

Sorry, but I disagree!
First, you would replace a valuable price information with a redunant price information if it would just display the final price. You already have that on the BE product page and in the frontend. But there are more good reasons to keep the base price in the backend.

Most of you who want to see the final price in BE apparently don't use VM2's calculation rules extensively, which in the long run means a lot of extra work when you need to adjust prices for some reason. Currently, VM2 displays the base price in BE, which is the cost price x rate of exchange. So you instantly see the trade price (purchase price) in your local currency.

VM2 supports a cost-oriented calculation. In VM2 you can enter the product trade price in the suppliers currency, convert it to your own currency, add your profit margin and shipping cost from the supplier to your address and finally add sales tax to the net price to calculate the final price. If you don't use it, you can just type in your net retail price, apply no rules, add your local tax and that's it. Or even worse, type the final price including tax into the 'Pricing rules overrides' - 'Discounted price' field and never think about it again. But that's a pretty poor commercial practice! (At present, I know plenty of colleagues, who are actually loosing money with every sale in their internet shop, simply because the supplier of a range of products has increased the trade price by 50 percent (which is equal to: reduced trade discount from 50 to 25 percent) plus isn't allowed to subtract local sales tax anymore when delivering to merchants abroad. The supplier did this more than a year ago, but the vast majority of my colleagues still didn't recognize that because they are used to thinking in "final price" don't do their math and believe they are still making some (reduced) profit by keeping the original final sales price.

In VM2 you can enter the product trade price in the suppliers currency, convert it to your own currency, add your profit margin and shipping cost from the supplier to your address and finally add sales tax to the net price (which is your revenue) to calculate the final price.

If the developers decide to provide an option to display an additional price of your choice in the BE product list, thats fine. But replacing the current base/cost price with the final price is imho a pretty stupid idea.
(However,  your other suggestions look more appealing to me :) )

JJK,
Of course any shop keeper must know what is the real cost price and how much profit selling a product generates. That is very good point because there is always a danger that the costs are higher than you expect. (Especially when the final product consists of several "pieces" which each have different purchase price for the shopper.)

Our point is the usability. I think that in an ideal situation any of the BE prices (cost price or final price) is editable and all other fields will be (automatically) updated based on the changed information AND affecting rules.

However, after the update 2.0.3. there are now more digits and that makes situation much better.  :)

I cannot even understand your questions. I need to interprete a lot, you are using much too sloopy your language and words.

The final price is displayed in the product edti, so what you are talking? you can override the final price, so what you are talking about?

So the option BOTH IS ALREADY THERE.

Or use your words correct. BEcause you want something completly different. What you want is (and that is from the merchant point of view really bad, dont admit that you do your calculation that way.)

What you want is that you can enter the final price (the thing you think is the right final price) and vm is the calculating for you the rest. What you do is very dangerous, because you set the result of your calculation, before you did the calculation. This works for smaller stores, you did your calculation manually and then you enter your stuff manually. Guys, last millenium. The future is that your trading system aka vm2 is doing that for you.

Quote from: jjk on March 08, 2012, 09:28:00 AM
In VM2 you can enter the product trade price in the suppliers currency, convert it to your own currency, add your profit margin and shipping cost from the supplier to your address and finally add sales tax to the net price (which is your revenue) to calculate the final price.

That is the way it should work for any serious retailer.

Milbo, you are absolutely right about the loose use of terminology. Automatic system is perfect. After a long thought, I think that we just don't know how to use it properly.

About the rules,
If I use Rules it is a bit complicated.

Let's use an example.

Cost price: 1 e
VAT: 23% (1,23)
Final Price with Tax ( that I want the customer see ): 12,50 e
X = Margin (euros)

(1+X)*1,23=12,5
1+X=12,5/1,23
X=(12,5/1,23)-1
9,162601626

Thus, in order to get the final price exactly 12,50 e I will use Tax Rule 23% and 'Price modifier for Profit Margin' 9,16...e.
[Tax Rule 23% => Tax  +%  23.0000]
[Price modifier  => Marge  +   9.1626]

Each product would need own rule because I want each product have a pretty final price.

Utilizing "Discount Price" is almost what it is talked about above and probably Milbo's way of editing the final price (?). Please see pictures.

Maybe I am doing this incorrectly but this is how I see the system works. [[We need to build up a MANual for VM2]]





[attachment cleanup by admin]

yes, and to have nicer prices, we have todo extra work. Maybe something, which shows then your profit margin and the use of the override price .

Quote from: maxispin on March 08, 2012, 11:33:54 AM
Each product would need own rule because I want each product have a pretty final price.

Normal retailers calculate with a common (depending on the type of product) profit margin and afterwards maybe increase or decrease it a little bit to stay slightly below a price they believe to be a threshold price.

However, nowadays supermarket chains with a big market share sometimes go the other way round. They tell the manufacturer "We want to sell your product for this final price and we need a profit margin of X percent. If you can't deliver for that trade price, we'll order from your competitor." Then the manufacturer starts to search for cheaper ingredients until he can match the dictated price. The result is a lower quality product in a brand name product packaging (Supermarket-Version).  :P

I can not understand some of your statements that you are a developer.

I have to put on my site over 1000 products: I give the task to one of my employees the LONG process of insertion of the products.

The 1000 products are in a printed catalog with the price including taxes as in any catalog of the world to end customers.

Well as it is today VM2.0, he must take any price, remove the taxation by a calculation with a calculator (eg base price = final price / 1.21 with tax at 21%) and enter the new value obtained.

This for 1000 products.

It 's just RIDICULOUS .... an inconceivable loss of time.

What I ask gently, and I think that those who opened the discussion asking, is that one who places the product can simply enter the final price as in EVERY free and commercial ecommerce in the world.

Quote from: simbus82 on March 08, 2012, 18:23:05 PM
Well as it is today VM2.0, he must take any price, remove the taxation by a calculation with a calculator (eg base price = final price / 1.21 with tax at 21%) and enter the new value obtained.
This for 1000 products.
It 's just RIDICULOUS .... an inconceivable loss of time.

..reminds me of this statement a little bit above this post:

Quote from: Milbo on March 08, 2012, 10:29:15 AM
... Guys, last millenium.

Just a reminder - Spreadsheets and databases were invented more than 30! years ago.  ;) How did you calculate your catalog prices - without knowing the cost price?
I understand that many shop users think it's quicker to just enter the final price and there might be a VM2 solution in the future that also covers this frequently requested, old-fashioned feature (which still is the only option in many other shopping carts - including my own old online shop  :-[ , but in the long run these users are wasting a lot of time and money.

Just one of many (real world) examples:
Assume, we are both selling 1000 products which are primarily manufactured abroad. At some point the rate of exchange between our manufacturer's currency increases against our local currency by 10 percent, which eats up our profit margin. So we have to increase our prices, too. Now you would have to have your employee to enter 1000 x the final sales prices again within the next two weeks or so. I have entered cost prices in the manufacturer's currency and let VM2 calculate the final sales price. Instead of spending two weeks entering new prices, I need something like 5 mouse clicks and I'm done in less than five minutes.

:) :) :)

Quote from: simbus82 on March 08, 2012, 18:23:05 PM
I can not understand some of your statements that you are a developer.

I have to put on my site over 1000 products: I give the task to one of my employees the LONG process of insertion of the products.

The 1000 products are in a printed catalog with the price including taxes as in any catalog of the world to end customers.

Well as it is today VM2.0, he must take any price, remove the taxation by a calculation with a calculator (eg base price = final price / 1.21 with tax at 21%) and enter the new value obtained.

This for 1000 products.

It 's just RIDICULOUS .... an inconceivable loss of time.

From my point of view it is ridiculous that a serious business man is caculating his products with the brutto prices. This remembers me to a friend who often flipped busines volume with the profit. So you should just provide your employee with the right data. How you do your calculations?

When you have to pay the vat tax, then you buy usually without vat. You buy maybe in large amounts. Then you have some strange numbers, for example 1.53 per item. After that you add your expenses on it and then you must stay below the price you think you can make. And you wanna have some profit for your effort and risk, and so on. After all that odd numbers you add your VAT. What you finally get is something like 4.32. Then you set it to 4.49 so that it looks nicer and what you do then? you must recalculate the whole thing back. When you not do that, then you do less then in some 17 year old pupils learn at school. So when you want to have "nice" prices you need todo that anyway.

But the whole effort is for nothing anyway and it completly outdated. The whole 99 concept works only in comparison, when you are on physical market. In the internet you can buy anyway in different countries. And it is impossible to make nice prices for more than one currency. So when you want to be on the global market, really forget the stupid .99 prices.

The feature that you can define the endprice and it is recalculating for you the profit then,.. is desired, no question. But that is not easy, there is some guy who meant he already did it, but the performance and side effects are not clear yet

I think this discussion is worth of having because it helps all of us understanding better the user needs and the ideology behind VM2.

Please remind that there are quite many different types of sellers and shop types which are defined by:

• Market area  [Domestic / International]
  
• Product type  [Physical / Electronic / Service]
  
• Parts one product consists of  [One / Tens / Hundreds]
  
• The number of Customers  [Tens / Hundreds / Thousands]
  
• Product amounts [Tens / Hundreds / Thousands]
  
• Store type [Physical / Internet]
  
• etc.
  

And combos of all of these.


Simbus,
I saw somewhere in Youtube a video of a VM1 office plugin etc. that helped in entering/controlling huge amounts of products. I think investments in that kind of tool for 1000 product sellers is acceptable.

Quote from: maxispin on March 09, 2012, 08:04:58 AM

I think this discussion is worth of having because it helps all of us understanding better the user needs and the ideology behind VM2.

Please remind that there are quite many different types of sellers and shop types which are defined by:

• Market area  [Domestic / International]
  
• Product type  [Physical / Electronic / Service]
  
• Parts one product consists of  [One / Tens / Hundreds]
  
• The number of Customers  [Tens / Hundreds / Thousands]
  
• Product amounts [Tens / Hundreds / Thousands]
  
• Store type [Physical / Internet]
  
• etc.
  

And combos of all of these.

Simbus,
I saw somewhere in Youtube a video of a VM1 office plugin etc. that helped in entering/controlling huge amounts of products. I think investments in that kind of tool for 1000 product sellers is acceptable.

Maxispin mine is only an example: i could be difficult with only 100 product to recalculate from price gross the price net.

The problem is that the VM developers think like a developer and not think like an end user, not like a vendor, but lika the man that have to use the PC to insert image files and write price inside forms.


Tipical situation HERE:
My client has a supermarket and wants to open an ecommerce: Call an poorly paid intern with a tablet and he go through the shelves to take pictures and put the product with its price GROSS (readed from shelves!!!) inside VM.

Do you realize that the VM developers do not understand that anyone who puts the product is probably not the one who has to hand the net prices without taxes?

You really believe that a vendor makes the calculations of the gain to sell on the internet when he has already a shop?


99% of those who open an ecommerce, he does this because it already has a physical store, already has its products with the gross price, has supplier that sell him products and he pays bills include taxes.


That is, truly, but are you living on the moon?!?!

I live in EUROPE, in ITALY, and here there are 3 different rates ... 4%, 10% and 21% depending on the type of goods sold: supplied basic (bread, pasta), various food products (beverages, condiments), and everything else from food to electronic goods.

A vendor has prices GROSS ,no one would ever bother to calculate prices without taxes: then in Italy, it is not a tax, but an Aliquot on the added value. Aliquot which is paid by the private final buyer.

So NO ONE IN ITALY insert net prices in a ecommerce which aims to sell to private individuals.

If you can not figure out this little thing ok, I'll try to find those who can make this change for the Italian people that want to use this wonderful tool for ecommerce.

lol sorry simbus, but you really seem not to understand.

For your case you create 3 unpublished categories, corresponding rules to it. Then you add the corresponding category to your products, you add the costprice done. You did not read correctly. Virtuemart is using your cost price. The price you use to buy your goods.

What you call Aliquot is imho what we call Vat = "value add tax", which has to be paid by all private customers yes. When you buy in italy using gross, but without  Aliquot, then afaik the rest in europe calls it netto. Taxes and costs of the merchant which cannot be used by you are Either you buy without vat or you get the vat back, a normal merchant does not buy with VAT. Of course, when you do illegal stuff,...

When you do not bother to calculate the price without tax, then it is just not your tax. For example, the big area merchant is paying import taxes, special duties (used by the state to influence the market). Do you have to show this taxes on the invoice? Afaik not, you just show your final price, which is the costprice (what you buy in gross) + profit and the vat (which is maybe your aliquot). You need only to show the aliquot to your customers. Maybe you do not, then you dont need tax rules. In germany we must always show both values, except the invoice has a low amount.

Quote from: Milbo on March 11, 2012, 16:02:18 PM
lol sorry simbus, but you really seem not to understand.

For your case you create 3 unpublished categories, corresponding rules to it. Then you add the corresponding category to your products, you add the costprice done. You did not read correctly. Virtuemart is using your cost price. The price you use to buy your goods.

What you call Aliquot is imho what we call Vat = "value add tax", which has to be paid by all private customers yes. When you buy in italy using gross, but without  Aliquot, then afaik the rest in europe calls it netto. Taxes and costs of the merchant which cannot be used by you are Either you buy without vat or you get the vat back, a normal merchant does not buy with VAT. Of course, when you do illegal stuff,...

Boh.. I think I have understood.
I only know that whoever puts the products in ecommerce is a person who has in hand ONLY gross prices inclusive of VAT and that VAT type of the product.

Quote
When you do not bother to calculate the price without tax, then it is just not your tax. For example, the big area merchant is paying import taxes, special duties (used by the state to influence the market). Do you have to show this taxes on the invoice? Afaik not, you just show your final price, which is the costprice (what you buy in gross) + profit and the vat (which is maybe your aliquot). You need only to show the aliquot to your customers. Maybe you do not, then you dont need tax rules. In germany we must always show both values, except the invoice has a low amount.

I think i need to show the type of VAT for every products (if i have a product at 4% and not at 21% i have to show it), not only in invoice but in ticket/receipt/check (in italian "scontrino fiscale"), but it is not required to show the price netto.


So you're saying that in theory I could not use the tax rules and enter only the FINAL price in VM?

And if someone buys something and then he asks the invoice as a company?

The real example of which I speak is this grocery store that wants an ecommerce to sell online (with shipping) or with the preparation of the shopping bag for those who have little time to spend in the store to choose the food.

But some purchases can come from those who ask for the invoice (perhaps the buyer is a restaurant instead of an ordinary citizen).

:-)

You guys dont need to persuade me todo this. It is planned already longer, when I started with the calculator. What I just want to say is that it should not be a blocker and not a real problem.

At least your writings a are setting the priority higher. The reason we use the forum and not a ticket system. I got a new idea, how to solve the problem a lot faster then I thought before.

Maybe I manage it even today to write an extra. My idea before was to calculate with the costprice and the final price the effecting profit. Problem is just that people would like to see their profit, when they enter their costprice and final price. Or they enter the final price, the desired profit and can see then their maximum costprice.

Sounds awesome!

So... Any news on this yet?...  ::)

Lipes
In your picture you are adding profit over VAT price? 243.90 Price + 23% VAT + 5 % Profit
How come?
In my country any receipt of purchase is: Price + VAT = Cost of the product to buyer
(Here PRICE already include manufacture cost, shipping, profit)

So if you sell something for 315€  the VAT paid can be calculated (eg. to fiscal refund if you are an international truck company) from the 315 not from the 300!

Thoughts on the discussion

- No seller should post directly the end price. Even if you are a reseller and are just copying a print catalog to virtuemart, you know you should use a spreadsheet to split the end price in his components. Like it or not. Selling its a business!

- If you want to have a "cute" price as in 9.99 then you need to adjust your profit margin.
The manufacturer cost, the VAT and additional taxes (except any promotional shipping) are not the part to edit!


So maybe you should focus on making/asking virtuemart easier to adjust the profit margin!
Maybe a system to round up your prices as in:

if end price 9.97 round up to 9.99 // if 10.0 round down to 9.99
(on both 9.99 products you get same VAT euros to delivery to the fiscal authority but your profit margin its different!)

Again, you can have a spreadsheet for that! Thats what the real seller do in real life.
So sometimes you loose, sometimes you get more! (remember you can't sell below product cost unless in SALES period!!)

Quote from: horus_68 on March 15, 2012, 05:26:52 AM
Again, you can have a spreadsheet for that! Thats what the real seller do in real life.
So sometimes you loose, sometimes you get more! (remember you can't sell below product cost unless in SALES period!!)

No, you don't have idea what SELLER really do in real life. No one follow rules.

Many vendors already have their real shop with their gross prices.

No one cares to use virtuemart as a marketing platform: VM is used to SELL. And if a seller has a real shop to the public, inside VM wants to put the final prices. NO ONE of these sellers with a real shop is interested in VM to indicate the margins on the price or other things, apart from the VAT.

Sorry but you are totally confused... even if you do this is real life you are totally wrong!!!

So if you add the % of the Profit after VAT as in = (243.90 € + 23% VAT) + 5 % Profit  = 315€
Can you please tell me how many VAT for that product you register in
A) the invoice to the client (that needs to display Price + VAT = Total
B) How many euros do you register to give back to your local fiscal authority?

Or you don't give any?
You can't add profit after VAT. You can't make profit from VAT, only form the product cost!
Cost + VAT + Profit = Price? No, No, No!!
And please go and talk with an accountant!

Quote from: horus_68 on March 16, 2012, 00:30:07 AM
Sorry but you are totally confused... even if you do this is real life you are totally wrong!!!

My clients are owners of companies that have active business for many years.

You CAN NOT say what is right and wrong in real life if these people are doing that job for decades.

It is they who made ​​me notice this problem (the inability to put the price and VAT FINAL without having to enter the price BASE).

People in a real store that SELLS from years, people who already have their own list of final prices determined a long time ago....

These are the customers of the VM that we have in our web agency: we DO NOT WORK with ordinary people who jumps on the Internet with dreams of making money by selling items bought from some kind of suppliers (where is needed to calculate the earning too! i agree!), we work only with COMPANIES.

Do you really want you to teach THEM how to SELL??

And Lipes is right about the calculation. And you think in my case, that here in Italy there are 3 different vat to be used and whether buyers want an invoice, the vat must be exposed for everyone Product TOGETHER THE FINAL PRICE!!



The change is conceptually simple: make the final price of the box editable.

Instead of doing

Final Price = [base price x (1,vat)]

just do

base price = [final price / (1,vat)]

and to get the result in the base price.  (if vat = 20% .... 1,vat ... is .... 1,20)

Of course you should add a "check" on the box is filled in, to see if you compile the final price or the basic one. Even a tick is good!


And this is solved EVERY problem.

PS: Then one radiobutton in configuration and each one shows what he wants in the product price column.

Lets get real:
My father is an accountant. I know how this is done!
My country has 3 VAT rates. I know this too!
And I also know that those are not eternal rates as governments do change it when they want, and move products form one to other category. Mine did it last year too!
So if something its lost in translation lets get this in plain talk!

So if someone can resume whats in stake here would be better than adding issues that are plain wrong and messing one simple request ant first.
Maybe people should understand that when they are asking to turn copper in gold they just need to stay on that request, they don't need to add new issues over that.
So I will post a new reply that will be plain and simple and get the discussion back again on the request done!

The initial request was:
New way to display price to users:
- WITH our VAT/TAX! Final Price (price gross)
- WITHOUT our VAT or TAX  Base Price  (price net)
- BOTH (with and without option)

No extra arguments scenarios needed!
Plain and simple: I'm for with, without or both as available options.
I'm for both 3 options available but with a "choose one by default only" option.
As I don't want my store to have different/mixed price systems on shelves!

Those how for any reason want the price visible with VAT, without or both should be able to choose. End stores should use with, middleman resellers would use with and without (without in big), Producers would prefer without", whatever! Fine!
I don't care what you find "most important" on "a" store. I'm not here to win any argumentation on you!
So focus on that and see if it can be done by actual developers or just share a way to do that on the code so it can be used! Maybe other users can help building that solution!


On other requests done along this post:
- You can't ask a store software to include one feature that its against every regular business practice, even if you don't realize this is done that way! (as in profit over VAT)
- You shouldn't ask for features that would turn impossible to multi-edit prices directly in tables or with external tools. This would be the case if you don't have a  common rule for prices on the same group.

Special note:
- You asked one thing then requested another. That's usually the direct way to not see any of them implemented, only endless discussions!
- If you want a "direct cute price" its another request different from this post!
Ask for it in another post, find a "cute" name as in "Low end store", "Direct price mode", "One field price", "No calculations mode" or any other you like.
And that could then be considered an interesting feature for virtuemart, something easy to market and a reason to someone invest some hours coding.

So before you request a feature, ask yourself why someone would implement it! Show how useful it would be for others, market your idea!
Don't just shout in panic mode: "I need this now, give it to me!".
Maybe its not accepted at first but you could succeed later. You simple need to accept that others have different priority than yours and try to find alternative ways or make your proposal an interesting one.
That's business 101 !!

So now lets get back on topic and to initial request.
Split requests (even if they look related or are for the same store) and try to find votes for your cause or submit a patch to implement it !
Please understand this and you will find more success on life!

It was discussed in various systems too many time so I'm not sure if the discussion makes a sense even.
But...

There're always two POVS:
- system
- sales man

System needs one fixed price, at least it's common practice. It doesn't matter if it's final or base. But must be one. Or each product have to have it's own info "my fixed price is base or final" (what currently VM2 AFAIK does not have) and 10 yrs of practice says this leads to comon problems in all calculations.

Sales man should have a unique price methodology, so fixed price is without VAT or with VAT.
Bu there're some situations sales man needs to say "this product has final price 100 EUR, no matter what other costs are". Well that is common, I need to agree, especially on web. Marketing action, special promos...

So, what is the matter of the problem? All constraints atre on the table and there is simple implication leading to solution, so where is the bouried dog?

I think the easiest way to solve the problems is to handle BE so it easies calculation of base price from final price enetered.
Another common problem then is rounding and big quantities in printed documents (some countired needs calculated price of 1pc on printed documents and then document must match. Then if you have 1pc eg for 0.14159 EUR and you buy 1000pcs, then printed document rounded to 2 decimal places will not match - 1pc=0.14, final price=141.59  Strict auditor will kick you in the ... I saw it three times ;D ).
Then you're again in troubles. But this is let's say marginal problem and can be solved in print by adding rounding row....

So I vote for final price, but in matter that we will add only calculation helper in BE, so everybody can enter final price and base price will be calculated depending on TAX rules and stored.

lol Guys, the problem is solved and in svn

But to you lipes:
That you have the same result does NOT make your calculation correct!

the profit margin is added BEFORE VAT, that is part of the definition of VAT. Also that the VAT is only paid by the endconsumer ist also part of the definition (ala aliquote, lol).

and thank you horus and ondra for your replies. I agree

Quote from: lipes on March 16, 2012, 03:36:35 AM
I proved you that everybody could do that! Profit after VAT or VAT after the Profit, who cares? It gives the same result:
243.90 + 23% (tax/vat)  +  5% (profit)   = 315€     magic?
243.90 +   5% (profit) + 23% (tax/vat)   = 315€     magic?
315 / 1.23 = 256.0975609756098 €
Tax/Vat = 58.90243902439024€

!

True.. the end result its the same. You win.
Or are you so focused on the final price that you don't see whats happening in the middle?
My point was: you can't calculate the VAT and than add your profit as your picture show!

On March 14, 2012, 21:07:15 PM your image shows:
243.90 + 23% = 300 + 5% = 315
So VAT would be 56,097 not 58,90...

Now lets do the math again only with big and clean numbers to be easier:

(Price + 23%) +  5% profit = amount to be paid by costumer
as in: 10 000.00 + 2 300 = 12 300 +  615 = 12 915 final price.

So its 2 300 euros to give to the fiscal authorities and you gain 615 euros! Not bad for a sale!


Now lets see... I wonder if the fiscal authorities feel the same. I think they will prefer this formula:
(Price + 5% profit) +  23% VAT = amount to be paid by costumer
As in: 10 000.00 + 500 = 10 500 +  2 415 = 12 915 final price.

So, same end price but now its 2 415 euros to give to the fiscal authorities and you only gain 500 euros! Not the same, right?

So I see two options: something its lost in translation here... or in the formula!
If I'm wrong accept my apologies!
Else if an auditor comes to visit you it will be interesting to know the results!

Well, as Milbo said above, what you ask for is in the next VM2 release.
...but couldn't resist to reply with a hint on this statement:

Quotewe could make that Product Sell and RECOVER the Tax again that we already payed

...you get the sales tax you paid to your supplier of the product back from your tax authority - even if you don't sell your product. It's called "pre-tax deduction" in all EU countries.  :)

Now it works with ver 2.03E. See attachment.

Checking generated result.

Final price 10
VAT 23 %

=>  X * 1,23 =10e
=> X = 8,130081300813008

BINGO ;)

##########################
:) T H A N K    Y O U    M I L B O!  :)
##########################

[attachment cleanup by admin]

Quote from: lipes on March 16, 2012, 03:36:35 AM
I proved you that everybody could do that! Profit after VAT or VAT after the Profit, who cares? It gives the same result:
243.90 + 23% (tax/vat)  +  5% (profit)   = 315€     magic?
243.90 +   5% (profit) + 23% (tax/vat)   = 315€     magic?
315 / 1.23 = 256.0975609756098 €
Tax/Vat = 58.90243902439024€

I think you should show your thoughts in a correct way, not using +23%. Much better way is to use  1.23X

Thus,
X = 243.90
Y = 1X * 1.23X * 1.05X
Y = 1.2915X
Y = 1.2915 * 243.90
Y = 314.99685

Quote from: lipes on March 16, 2012, 23:51:38 PM
I'll try to search the "pre-tax deduction" in legislation to see if i can find something about that. Tks!

I suppose you are located in Portugal. So just type "pre-tax deduction" here:
http://translate.google.pt/?hl=pt&tab=TT (http://translate.google.pt/?hl=pt&tab=TT)
You could also look it up in Wikipedia, which usually has links to the complete laws.
The tax regulations are almost identical in all EU-countries. Only the tax rates are different.

I was talking in english to a portuguese?!!  8)

And now for something completely different... in portuguese:

Lipes: andas a perder dinheiro com o IVA.
Só os consumidores finais pagam realmente IVA, os comerciantes recolhem e entregam!
O IVA é um imposto rotativo em que fazes os acertos com as finanças (regularmente!) entre aquilo que entregas e o que recolhes.
Existem ainda coisas como imobilizado, perdas, deduções, etc.
- Atenção às faturas pois a percentagem de IVA é sempre adicionada no final ao preço do produto dando assim origem ao TOTAL. A margem de lucro está já colocada dentro do preço do produto (que naturalmente tem de ser superior ao preço de custo!). Até os descontos e promoções, custos de transporte e outras taxas aparecem antes do IVA. Certamente não ignoras que os carros pagam IVA em cima do Imposto de circulação! Assim o IVA é sempre depois de tudo!
Já nos cálculos cuidado com a diferença entre somar coisas e multiplicar coisas. Parece igual mas não é!!

Recomendo que façam uma visita a um contabilista para vos explicar o que andam a fazer de errado no vosso negócio, mas andam mesmo a perder dinheiro!

Bom trabalho!

The best thing about software is that it allows to implement multiple solutions configurable to match the needs of different users.

It´s comparable to the shopergroup...

While there are some legal constraints (tax is always due on the value including profit) there are definitely more than one aproach in the implementation of pricing into day to day business practice:

The bottom-up aproach is when you start with the product cost and add a formula to get to your final (theoretical) price. This is the aproach practiced in most large shops which usually BUY and RESELL
The top down aproach is a more common business case in smaller businesses, especially (but not only) when there is a product PRODUCED, lets say e.g a pizza, a painting etc..

Both aproaches are valid and there is no reason to limit the ability of a software to serve only one of the two cases.

Just my 5 cents worth..
Bernhard

I just came across with this thread and I am mesmerized.

The kind of things written here, specially the reasoning for building prices is wrong (I'm being kind and trying not to use stronger terms) for anything but indiferentiated products.
If your store sell indiferentiated products, say OEM computer parts or bulk ore, then yes, cost maybe relevant for the final price calculation, because your business model is based solely in a profit margin of comparable goods. And even then, calculating from a cost standpoint is not productive, because you can have different margins per product and product cost can have a number of variables (bulk promotions, offerings, variable shipping or insurance rates, ...) that require it to be calculated separately, so it's pointless to use it in the backend.

But in every case where you sell diferentiated products, then the price is always what the market wants to pay (the maximum unit price for your projected volume) and cost has nothing to do with it. This is economics 101!

So yes, final price to buyer should be the primary concern and net prices should be calculated (and maybe margins or costs) but not the other way around like it's built right now  and some people here defend "it's the future of pricing". Being able to input the final price and then let VM calculate the net price without tax should be the primary function.


Virtuemart is an online store, not a management tableau. The whole purpose is to make it easy to put products online for promoting an selling, not to use it as your business management tableau de bord - specialized solutions exist for that.

The mixed concepts and misconceptions in this thread are common when you don't have marketing or business oriented people dealing with the business rules, rather relying on the technical team to devise them.

And although are common misconceptions, technical people don't even need to go "outside their world" to understand that. Think about software pricing (not freelancing jobs, which are "indiferentiated"): is the pricing of any software or script based in the amount of working hours paid?
No, never, it's based on how the market values it, which in turn depends on what are the market needs it solves. As simple as that.
Many scripts are sold or leased with a pricing based on the prospected revenue of the customer (that's called "revenue sharing" and yes, thats the model of the XXI century) and cost has nothing to do with it.

I know this is volunteer work and that VM is a big piece of software, but these are the details that are critical for the webmasters and store administrators and in the end make people choose other solutions over VM.

Just my five cents