Hey,
I'm working on a feature but I wanted to get your input.
I'm not quite sure how the "minimum price" figures into the current status of things. As of now, this is a "seller" configurable option that changes an advertised minimum price.
Our needs
For our site, we need to have a minimum amount that the seller needs to set their price point at in order for everyone to not lose money. This is based on a series of factors for us, including bandwidth, time involved with any manual product adjustments (specific to our site), etc.
The solution
A Site Admin-configurable text field within the Sellers settings tab, that allows a "sitewide base price" that the sellers must meet or exceed. This way, the store admin can be assured that the results will be a positive net and not a loss.
Our case
Specifically for our site, we need to make sure that a user is not selling a 90-minute movie for $1.00, and selling a 10-minute short clip for the same price. (Our custom code will handle different product sizes based on filesize of the file feature - however this might be something worth integrating with product classes, and/or taxonomy). Since we have a standard amount of money that goes into hosting, bandwidth, and employee time, we know that we need to sell these for (as an example) a minimum of $1.00 in order to break even, since we are going with a 50/50 split for most seller products.
Hope this makes sense. I'm in the process of editing the mp_products module to include this basic functionality, but I wanted to see if you had any thoughts in this regard.
Thanks!
Erik
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | mp_products.diff | 3.11 KB | torgospizza |
Comments
Comment #1
torgospizzaI forgot to mention that there will be a condition in hook_validate that will check the configured Sell price for the product being edited, and if it's not equal or greater than the base price, will set a form error notifying the user that they must adjust the price due to the sitewide "base" price.
Comment #2
torgospizzaHere is a .diff for mp_products.module. Check it out for my changes - I have tested and it works great. Let me know if you like it and if you do end up rolling it into the module. (I myself think it's a handy thing to have - and if you have changes to the verbiage on the settings form, feel free to modify it.)
I added a couple spaces to the validate $op in hook_nodeapi, just for readability's sake. Also, it looks like you could use uc_currency_format in some of your currency functions instead of, for example,
variable_get('uc_currency_sign', '$');. I didn't patch these but I could if you like.Comment #3
Turgrid commentedWow. This sounds good. I think my "min price field" is sort of deprecated at this point (but probably won't be removed) because of its very niche use. Your feature sounds good and your patch looks great. Thanks...I will put this in BETA3 (eta: tba) - appropriate credit will be given.
I am not quite sure what you mean about replacing uc_currency_format calls. Is your example method a better approach? Thanks again.
Comment #4
torgospizzaI may have misread what your module was doing, so I'll have to look again. Your module appeared (to me, at least) to be adding the $ sign after looking up variables, which were then added to the form fields. I wasn't sure if this was how Ubercart's form already works, however.
I sort of assumed that the normal (non-Marketplace) node edit forms use uc_currency_format to format the number, say, .32 into $0.32 (complete with currency sign). Again maybe I'm confused, so no worries. I'll look through your code to understand it more thoroughly. One thing I am considering is an edit of your commission screen, or at least something similar to it, that allows you to set minimum prices for each separate product class - which is essentially how we'll be handling our site. I'll add to it sometime tomorrow.
Always glad to help out. Watch for another .diff coming soon - you can still apply this one for now and I'll build a .diff against that new version, as well as against the original file, just for consistency.
Comment #5
torgospizzaOkay, I see that your form does in fact, duplicate the $sign_flag function (in #field_prefix and #field_suffix) of the product edit form, so I won't patch that. From my quick glance it looked like an inconsistency, but after looking again, I see that it's not :)
Regarding product classes, I've decided to hold off on that for now. I think setting a sitewide base price is a good enough solution for the time being. Eventually there could be either another table, or an extra column in the commission rates table, that would allow for a per-product Class base price for each role, just as you have done with commission rates.
Feel free to roll my patch as you see fit.
Comment #6
torgospizzaUpdating status, update again once patch has been rolled into the module. (You can modify as desired.)
Comment #7
Turgrid commentedPatch committed in BETA3. Thanks.
Comment #8
Turgrid commentedI actually will now be releasing another BETA to address an issue with the patch. A second argument is required for variable_get().
Comment #9
torgospizzaAh, whoops - I can see how that slipped through. Thanks for taking care of it :)
Comment #10
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.