[Solved] Poll (yes/no) Backend Product Final Price w/(vat/tax)

[lipes]

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

[maxispin]

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.))

[AH]

I think both should be displayed. 

[maxispin]

I think both should be displayed. 

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

[jjk]

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 )

[maxispin]

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. 

[Milbo]

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.

[jenkinhill]

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.

[maxispin]

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]

[Milbo]

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 .

[jjk]

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). 

[simbus82]

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.

[jjk]

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:

... 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.

[Milbo]

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

[maxispin]

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.