Hello out there,
As a shop-owner you normally want to have a clear overview over how much you earn for the products you sell.
If you are a reseller-shopowner (someone who does not produce his own products), then in addition to all the cutomer-related product prices, you also need to have the purchase price (the shop-owner´s cost for the product - not the customer´s cost price).
As it is now there are only input fields for customer-related prices in the Virtuemart product admin page.
As I see it it is strongly missing a price field for the ahop-owner´s own product cost prices.
Actually I have been forced to add my own database field to the Virtuemart price table, which is of course a hack and not very good when upgrading to newer versions of Virtuemart..
Please speak up if you agree or disagree with this feature request.
The Cost Price field is already there. When VM2 was introduced it was referred to as the base price, displayable in the front end to store admins only, but there were a lot VM users who had difficulty with the concept! See http://forum.virtuemart.net/index.php?topic=111093.msg406231#msg406231 - and then browse that thread to see how it is misunderstood.
Is using the calc rules the only way to modify base price from cost price?
I have different margin for every product and can't modify the base price manually.
Can't create ad hoc calc rule and associate it to my product only too:
from the calc rule I can't select only one product and from product edit I cant select the rule from cost price level (as from base price level with tax)... :(
How can I manage this?
I ended up creating a separate field for supplier cost price
Trying to manage cost prices / retail prices with all the variants of supplier discounts was too much of a headache - we do this now in external systems.
However, the base price that Jenkin mentioned will work for many shops who have simple supplier discount structures
Storing the cost price in VM enables us to do margin displays in the backend admin
Deploying your own database addition is very simple and easy to maintain as long as you have good code management
Quote from: Hutson on August 01, 2014, 13:42:56 PM
I ended up creating a separate field for supplier cost price
Trying to manage cost prices / retail prices with all the variants of supplier discounts was too much of a headache - we do this now in external systems.
However, the base price that Jenkin mentioned will work for many shops who have simple supplier discount structures
Storing the cost price in VM enables us to do margin displays in the backend admin
Deploying your own database addition is very simple and easy to maintain as long as you have good code management
Thanks for the reply.
I'm evaluating if I can store the cost price in a custom field.
I've seen these properties in custom field definition:
- Published (yes/no)
- Admin only (yes/no)
- Hidden (yes/no)
How this properties works?
Can be suitable for my needs (have a custom field for only admin purposes without publishing it online)?
Thanks in advance for the support.
Custom fields could be used but they are a real pain and not great for use in admin
I would just add a new database field.
Very simple to do and then easy to customise the admin pages using a view override by putting the view in your admin template html directory
Just add the new field to the database:
`q_supplier_cost_price` VARCHAR(10) NULL DEFAULT NULL
I use varchar but it is up to you
Then reference that field in :-
administrator\components\com_virtuemart\tables\products.php
var $layout = '';
/** @var int published or unpublished */
var $published = 1;
/** MY NEW variables */
var $q_supplier_cost_price = null;
Then fix the annoying "bug" that stops you using an override in product admin:-
\administrator\components\com_virtuemart\views\product\view.html.php
Line : 55
//quorvia removed to allow template overides in product admin
// $this->addTemplatePath(JPATH_COMPONENT_ADMINISTRATOR.DS.'views'.DS.'product'.DS.'tmpl');
The do your template override to the view: product_edit_information.php and put it in
Create a copy in
administrator/templates/YOUR ADMIN TEMPLATE/html/com_virtuemart/product/product_edit_information.php
And add your new field:-
<tr>
<td class="label">Supplier Cost</td>
<td>
<input type="text" class="inputbox" name="q_supplier_cost_price" id="q_supplier_cost_price" value="<?php echo $this->product->q_supplier_cost_price; ?>" size="12" maxlength="14" />
</td>
</tr>
I actually do it slightly differently for all my new variables (as I have more than 1)
I still update the product database and the tables\products.php
But, I create a brand new TAB for my new variables so I ensure that I get all the changes to the standard product edit views
I call this something like
\administrator\templates\YOUR ADMIN TEMPLATE\html\com_virtuemart\product\product_edit_myview.php
Then I just need a tab to display that new view:-
So I created an override \administrator\templates\YOUR ADMIN TEMPLATE\html\com_virtuemart\product\product_edit.php
<?php // Loading Templates in Tabs
$tabarray = array();
$tabarray['information'] = 'COM_VIRTUEMART_PRODUCT_FORM_PRODUCT_INFO_LBL';
$tabarray['description'] = 'COM_VIRTUEMART_PRODUCT_FORM_DESCRIPTION';
$tabarray['status'] = 'COM_VIRTUEMART_PRODUCT_FORM_PRODUCT_STATUS_LBL';
$tabarray['dimensions'] = 'COM_VIRTUEMART_PRODUCT_FORM_PRODUCT_DIM_WEIGHT_LBL';
$tabarray['images'] = 'COM_VIRTUEMART_PRODUCT_FORM_PRODUCT_IMAGES_LBL';
$tabarray['custom'] = 'COM_VIRTUEMART_PRODUCT_FORM_PRODUCT_CUSTOM_TAB';
$tabarray['myview'] = 'My new view'; //added by quorvia
I now have a tab with my new fields in, that does not get overwritten by updates and still lets me see the new stuff in VM upgrades
I do however have to retrofit the small changes I make to these 2 files
\administrator\components\com_virtuemart\views\product\view.html.php
administrator\components\com_virtuemart\tables\products.php
But it is worth it, as I now have a field that I can update using spreadsheets and csvi and mysql etc that is always attached to a product and can be referenced wherever I wish.
I hope this helps
Some might say that I should create a separate database for my own stuff - but I cannot see the benefits of doing that over extending the current product database.
Thank you very much for the explanation of your solution.
It's clear and well formatted, it may be useful to many, even if I don't know if I'll use it...
Thanks again :)
Okey, so what we need is a possibility to enter the baseprice? so that people can use the costprice as intended, because doing all by profit margin rules is to complex? Hmmm..... I doubt we should do it already for vm3, or? could be to confusing, or?
Hmmm. interesting, I will think about that in my hollidays, cyah
Milbo
I like the way you keep using "base price" just to confuse us all ;D
No doubt if you introduced a separate value, it would result in people moaning that it did not do what they wanted and what then is base price etc etc
For many the current "base price" is functional. For thos awkward people (me included) we can introduce whatever fields we need.
Holidays ? Tsk tsk. 8)
Hello
Nice to see that more people are interested in storing a purchase price. I like to adjust the price that the customer pays in order to adapt to the actual market situation. But I still want to know the price I purchased the product for. It would actually also be interesting to see the purchase price history. Many companies keep track of purchase prices with relation to from whom and at which price it was purchased. But this probably requires a new table with purchase prises :)
Introducing a purchase price is a nice step on the way.
best regards
Jörgen @ Kreativ Fotografi
Milbo is only considering it as an option
For a retailer it is good to identify the cost price against stock held
Sales and stock movement is then allocated on a FIFO (first in first out) basis
The last retail system I worked with held 3 cost prices with 3 stock values with date of stock entry.
Useful if you have a volatile Retailer Cost price and want to see Retail "Margin on return" against old stock.
It is easy to adjust a retail price and make a loss on old stock (if you are not really watching!).
You would need to be able to book stock in at a cost price and where the new stock cost differs from current cost, prior stock gets bumped down one level
The oldest level never gets bumped if it has stock in it, it acts as a catch all bucket with the cost price being that of the stock being moved into it.
This is clearly above and beyond where VM is now, but worth a thought. Many people will have resorted to spreadsheets etc to try and mange this, but you have to be sure where the "system of record" is for your stock.
Ohh I need a Holiday! 8)
I am interested as well.
I have the following real-life condition:
- cost prices
- RRP prices that are a randomly percentage over the cost price between +10% and +13% (I mean, +10.19% +11.93% +10.45% +12.02% etc.)
- different wholesale groups prices that are grouped per fixed percentage over the COST PRICE (as +5% +7% +10%)
Maybe I will try to implement the Hutson suggestion. Thanks for that.
Quote from: Hutson on August 01, 2014, 18:12:24 PM
Custom fields could be used but they are a real pain and not great for use in admin
Maybe for you. If you setup a pattern and furthermore use only that pattern, it is just a 5 minutes action and the rest is behaviour, very simple.
I know that the rules/patterns will work very well for many VM users and I think it is a real positive part of the development.
It would be great for someone to put a tutorial together with real life examples, so that new users could get to grips with it and put it to some good use.
I have just chosen to use an alternative approach :)
I manage the pricing and margins using external systems/processes, so VM just gets an ex-vat price.
VM devs are really doing a great job hence why I support the forums with my time and try to help others and test new versions where possible.
Quote from: Jörgen on August 02, 2014, 12:58:31 PM
Hello
Nice to see that more people are interested in storing a purchase price. I like to adjust the price that the customer pays in order to adapt to the actual market situation. But I still want to know the price I purchased the product for. It would actually also be interesting to see the purchase price history. Many companies keep track of purchase prices with relation to from whom and at which price it was purchased. But this probably requires a new table with purchase prises :)
Introducing a purchase price is a nice step on the way.
best regards
Jörgen @ Kreativ Fotografi
You have understood everything, please please make in VM3 a field where we can insert purchase price! We need history of purchase price very usefull to control purchase price change
I think it is a must have for all shop owner
I have resolved this business requirement by storing the cost of items over time in a separate database
Many store owners use a model where the Accounting software controls a greater part of this process as the e-commerce channel is often one of many sales channels.
It would more than great, i think even crucial, to get this feature (that at my point should have been since the start)
Entering the price that we are buying the goods in order to know the margin VS final selling price in order to do a good report is crucial.
Prestashop, Magento, Hikashop... all are having this possibility which what i have seen but not VM which is a lack
I had one clients that point out this fact and prefer to use an another component that VM because of this point
I love VM and supporting it for many years now and will not stop here
Therefore as this feature is ask since 2012 (from the forum history) could you please now consider this important fact?.
Thank you very much
My clients have always used the base price as their purchase price. Simple.
Jenkin
I refer you back to the beginning of this thread and why a separate cost price might necessary for some businesses.
VM gets a net price in the base price for us.
huhh, quite old thread but the topic is still actual :/
Quote from: sandomatyas on November 29, 2017, 22:47:35 PM
huhh, quite old thread but the topic is still actual :/
If this is not used to calculate the final price, you can add and use a simple customfield.
I know but it's a bit hard to explain to the customer why he need to set two prices at two different places and why he can't see them next to each other :/
You can not avoid the need to set two prices, this is what You are asking for, right? You should add a field to the Product table and make an override for the backend edit Product / productstatus view. Adding a new field isn´t that hard. The back end is overridable in same way as the front end.
I myself use the text field on the first tab to make notes about when I order Products, how many, their price and when they are delivered into stock. It is enough for my needs and gives me flexibility and also a purchase history.
regards
Jörgen @ Kreativ Fotografi
Quote from: Jörgen on December 01, 2017, 07:58:04 AM
You can not avoid the need to set two prices, this is what You are asking for, right? You should add a field to the Product table and make an override for the backend edit Product / productstatus view. Adding a new field isn´t that hard. The back end is overridable in same way as the front end.
I myself use the text field on the first tab to make notes about when I order Products, how many, their price and when they are delivered into stock. It is enough for my needs and gives me flexibility and also a purchase history.
regards
Jörgen @ Kreativ Fotografi
Hi Jörgen
Thanks for your reply, you're right, it isn't hard but when I do this VM updates will override it or when I move modifications to template override I can't use the benefits of layout updates :)
My soltion was modify the layout via javascript and ajax which is loaded by a system plugin, it works well in other scenarios (eg adding custom background images per category or bind VM categories to Acymailing lists) but this time I should modify the storing mechanism too and I'm not sure if VM update won't remove the new table field too
sandomatyas
Your requirement is one I have had for many years and solved by simply adding a table field and then creating an override to existing admin product views.
Please read this thread.
http://forum.virtuemart.net/index.php?topic=137418.msg481235#msg481235 (http://forum.virtuemart.net/index.php?topic=137418.msg481235#msg481235)
QuoteI'm not sure if VM update won't remove the new table field too
Yes you will need to apply your table update to every release you deploy BUT - that should take you all of a minute and VM does not remove your database table entry.
Ensure you give the table field a name that someone else in VM will not use in the future :-)
Here is what it might look like - in \administrator\components\com_virtuemart\tables\products.php
var $layout = '';
/** @var int published or unpublished */
var $published = 1;
/** sando new variables */
var $sando_cost_price = null;
Quote from: jenkinhill on September 30, 2014, 21:14:11 PM
My clients have always used the base price as their purchase price. Simple.
The reason I call it "costprice" and that is also the reason that the "baseprice" is uneditable. It is also the reason that you can set a currency, it is the currency of the costprice!
So I wonder now, what is actually missing? editable baseprice?
By baseprice I was referring to cost price - I guess I did not catch up with the label change, but it is always the topmost price in the price table.
Quote from: Milbo on December 03, 2017, 10:27:03 AM
Quote from: jenkinhill on September 30, 2014, 21:14:11 PM
My clients have always used the base price as their purchase price. Simple.
The reason I call it "costprice" and that is also the reason that the "baseprice" is uneditable. It is also the reason that you can set a currency, it is the currency of the costprice!
So I wonder now, what is actually missing? editable baseprice?
I know the reason, my customers have same problem.
They have to check the real product costprice they paid if they need to change baseprice.
Eg in France you cannot sell a product < costprice.
If you know costprice and baseprice, you know how much you win
But you can have many other reason.
QuoteBut you can have many other reason.
I chose to add a new field - not because of any flaw in VMVM has been developed to support simple and flexible rules that allow for the cost price to be input into the cost price field and for a retail price to be calculated as a result of that.
These rules are extremely flexible and will suit many store owners. If that fits your situation then that is definitely the way you should go to make your life simpler.
So why am I not using VM's pricing flexibility?For some business the net price of items is calculated externally to VM so the flexibility VM offers is not required.
Prices can be loaded to VM and no rules (other than sales taxation) are required.
For us Cost and Base prices are then the same, they are the net retail price.
But, as a result, the business could not see the price paid for items when using VM admin.
To facilitate this I added a new field - (you can name it what you like - for us it is the "Last Cost price we paid for the item")