just a logic question.
I'm building a shop based on Laravel and other stuff but that's not the point.
The point is, how to handle stock addition / deduction.
Right now, I have a package (my item) with the qty of (let's say) 20 in the shop. Every time a user try to add this item (and the qty) to the cart or updates the qty of the item in the cart, I check if:
- Count of QTY of the PAID orders is < QTY OF ITEM - I do not count the qty of other orders which are not paid.
Is this correct? Or do I have to include orders with "pending payment" or other ?
Quite difficult to find the right way. What is the best way to manage stock ?
I'd say it all depends on how the logic and implementation you want to add is.
Think of it this way on a case-by-case scenario (me being the customer):
If i am allowed to create an order and never pay for it (changed my mind, out of money, forgot about it)
Will you reserve the stock for me forever?
If i create an order, i come back to pay a week later but you are out-of-stock
Will you make sure i get the item somehow?
Will you prompt me that the stocks have changed for some of my items and i need to review my order?
Will you just cancel my order as stock in not available?
If i make an order and while i am trying to find my credit card to pay someone else buys the last items before me, what will you do then?
Conclusion:
In case 1 the store is at a disadvantage and probably will face problems for keeping stock for items that are never going to be actually purchased.
In case 2 it was my fault for not making sure i paid for the orders promised in a reasonable amount of time so i would accept the scenario of "losing" the item
In case 3 it was probably the system's fault for not keeping the items for me as promised when making my order as it could be a matter of minutes or even seconds.
From this i would suggest you used a time based reservation of items, prompting the users to settle their payments in a reasonable amount of time (1 day, 1 week, 1 month... it depends on you) for which their orders are considered active.
By counting the active pending orders and just cancelling them after some time, you would keep customers happy since you are delivering as promised and them feeling obligated to pay their order or risk losing up on the items in their order.
Related
For the products in a cake shop, the cakes can get ordered for different order dates (order attribute) within the same order.
The stock should only be considered, if the cakes are ordered for the next day. For orders further in the future, the stock is irrelevant.
So I want to modify the cart that in get_cart_item_quantities() the item quantities get only grouped for cakes ordered for the next day.
So far, I managed to write a plugin extending the original cart and overriding get_cart_item_quantities()and add_to_cart().
But with the recent update, the plugin is no longer working due to new class hierarchies.
So I'm looking for a solution with standard filters and actions which is more update proof.
Can anyone help?
Here's more information on what I want to achieve:
The cakes can be ordered as a whole cake (12 or 16 pieces) – which is the main product – or as a variation of a quarter cake (3 or 4 pieces).
The shop keeper wants to manage the stock in number of pieces for the whole cake, not with the variations as well.
Moreover, the cakes can be ordered for next day delivery or sometime in the further future.
ONLY if the cake gets ordered for the next day, the stock should get checked.
Let's say there is 12 pieces of a cake in stock.
One customer buys a whole cake (12 pieces in this case) for tomorrow and a quarter for sometime next week.
When adding this to the cart, the cart should contain:
amount 1 of the whole cake for tomorrow
amount 1 of the quarter cake for sometime later
I add the delivery date in woocommerce_add_cart_item_data.
Internally, WC_Product::has_enough_stock() should check the stock only for the items ordered for tomorrow and in the actual number of pieces, in this case 12 for the whole cake for tomorrow (even though the amount in the cart is 1)
So far, I implemented the number of pieces by overriding WC_Cart::get_cart_item_quantities() and adding a custom filter.
And by overriding WC_Cart::add_to_cart() to modify has_enough_stock().
During checkout, I reduce the stock amount by the correct number of pieces by filtering woocommerce_order_item_quantity.
But of course, with the plugin solution I need to update the plugin with almost every update of WooCommerce.
The possibilities I see at the moment:
As WC_Product::has_enough_stock() is not applying any filters itself, I could filter woocommerce_product_variation_get_stock_quantity and return the actual quantity if the delivery date is relevant and return a fake number like 9999 in all other cases.
Like this, stock management should workg during add to cart, in the cart and during checkout when relevant.
What do you think?
Hi i’m developing a eCommerce site in Magento for jewellery business and its based on a “weight”, not the price because gold rate is changing in day by day or more then 3 times in a day.So it is not possible to change the product price every time according to gold rate. Then, how to manage the prices on this scenario?
Example case: Today I have added a 18K gold ring of 10gm to my site and right now gold rate is Rs30,000 per 10gm, so today price of this ring is Rs30,000 but, Next day the rate will be changed (Rs32,000 per 10gm) then, my product price must be changed from Rs30,000 to Rs32,000.
This is not possible to update the price of all products every time.
I am using Magento platform. Please, Share your idea regarding this situation.
To make this simple, you should work on a 2 ways solutions.
In the frontend, do not show price ($_product->getPrice()) but just show the real price according to weight.
Example if you have price/grm stored in the backend use $product->getWeight * Mage::getStoreConfig('mycompany/gold/dayprice').
That way price will be shown dynamically in the product page or list page.
Now you should use an Observer on the add to cart event to change the price to the good one.
This way, don't matter what price is set on the product because showing and adding will use the formulae.
I am currently developing a subscription system for a web application.
I need help regarding the approach for new subscription costs when a user decides to downgrade or upgrade their account.
I created a image to make an example of a user that keeps changing levels.
A user can choose to pay each month, quarter or year.
I want to add a discount when the user decides to downgrade. The discount is currently factored into the new cost using this formula:
[final plan cost] = [new plan cost] * 12 - [discount] / [12 - month / 3 - quarter / 1 - year]
If we have a user that keeps changing plans like this, how can I calculate the discount dynamically? It's easy for one change - I can take the difference between the two plans and multiply it for each payment that was made before. But I need some help regarding the approach for several changes, and how I can keep track of the discount.
I think you should put all that information in a database table and just call the cells. If the user it at the plan where they are getting the discount based on the sub; then
eg
if(price is this)
discount is {discount value from the database} x price of subscription..
You will not have to worry if someone changes their subscription in the middle of the month, all you have to do is put that information in a different table and at the end of the month all the application would do is apply the new subscription and do the calculations. It is not hard just the approach..
I have a question on what the best way to calculate and store sales tax in the US should be. I am creating an invoice program that can have multiple line items. Here is an example of the issue I'm am running into.
One of my invoice line items looks like this.
quantity 2
amount 1133.67
tax rate 7.5% (.075)
If I add 1133.67 to 1133.67 and multiply by .075, the tax is 170.05.
However, if I take each quantity 1133.67 and apply tax to it individually first, the amount of tax totals up to 170.06.
Obviously, when I'm dealing with taxing each individual quantity, each quantity is being rounded up. But when I total each quantity and then tax the total, there is no rounding up.
I can probably solve this problem by simply editting my table field to allow for 3 decimal places instead of 2.
This may be a question only I can answer, but does it make sense to store tax amounts for each line item or no? I was thinking the data could be useful in reports later down the road.
Wondering what others are doing.
Thanks in advance.
Having worked at a successful sales tax startup, I can tell you "it depends". Local laws vary on whether you calculate sales tax at the line item or invoice level. For some discussion on the topic see:
https://money.stackexchange.com/questions/15051/sales-tax-rounded-then-totaled-or-totaled-then-rounded
I can also tell you that US sales tax is extremely complicated. There are over 10,000 jurisdictions that can levy a tax (state, county, city, and special districts such as stadium districts, metropolitan transport districts, water districts, etc.). The boundaries of those districts are not well defined an a readily available public source, and certainly do not conform to ZIP code boundaries.
If you want to get it right, your best bet is to use a sales tax calculation service. There are several SAAS solutions that are well-suited for web apps.
EDIT: Im sorry guys my explantion of the problem wasn't clear! This should be better:
User sends ID numbers of articles and the max. number of bundles(packages)
API searches for all prices available for the articles and calculates best result for min. number of bundles (limit to max. number provided by customer)
ONE Bundle is one package of items delivered to ONE platform(buyer)
Thanks!
This is a fun little problem. I spent a few hours on it this morning, and while I don't have a complete solution, I think I have enough for you to get started (which I believe was what you asked for).
First of all, I'm assuming these things, based on your description of the problem:
All buyers quote a price for all the items
There's no assumption about the items, they may all be different
The user can only interact with a limited number of buyers
The user wants to sell every item, each to one buyer
The user may sell multiple items to a single buyer
Exact solution -- brute force approach
For this, the first thing to realize is that, for a given set of buyers, it is straight forward to calculate the maximum total revenue, because you can just choose the highest price offered in that set of buyers for each item. Add up all those highest prices, and you have the max total revenue for that set of buyers.
Now all you have to do is make that calculation for every possible combination of buyers. That's a basic combinations problem: "n choose k" where n is the total number of buyers and k is the number of buyers you're limited to. There are functions out there that will generate lists of these combinations (I wrote my own... there's also this PEAR package for php).
Once you have a max total revenue for every combination of chosen buyers, just pick the biggest one, and you've solved the problem.
More elegant algorithm?
However, as I intimated by calling this "brute force", the above is not fast, and scales horribly. My machine runs out of memory with 20 buyers and 20 items. I'm sure a better algorithm exists, and I've got a good one, but it isn't perfect.
It's based on opportunity costs. I calculate the difference between the highest price and the second highest price for each item. That difference is an opportunity cost for not picking the buyer with that highest price.
Then I pick buyers offering high prices for items where the opportunity cost is the highest (thus avoiding the worst opportunity costs), until I have k - 1 buyers (where k is the max I can pick). The final choice is tricky, and instead of writing a much more complicated algorithm, I just run all the possibilities for the final buyer and pick the best revenue.
This strategy picks the best combination most of the time, and if it misses, it doesn't miss much. Its also scales relatively well. It's 10x faster than brute force on small scales, and if I quadruple all the parameters (buyers, buyer limit, and items), calculation time goes up by a factor of 20. Considering how many combinations are involved, that's pretty good.
I've got some code drafted, but it's too long for this post. Let me know if you're interested, and I'll figure out a way to send it to you.
This is a graph problem. It can be solved with the Edmond's Blossom V algorithm. It's a matching algorithm to find the best pairwise matching for example in dating programs. Maybe you want to look for the 1d bin-packing algorithm. In 1d bin-packing you have a limit items to assign to unlimited boxes or shelves the better the boxes get filled.
If I understand the problem correctly, it is NP-complete via reduction from Minimum Set Cover. We can translate an instance of Set Cover into an instance of the OP's problem as follows:
Let an instance of Set Cover be given by a set X of size n and a collection of subsets S_1, S_2, ..., S_m of X. Construct an instance of the OP's problem where the seller has n items to sell to m buyers, where buyer i offers a price of 1 for item j if *S_i* contains item j and 0 otherwise. A solution to the OP's problem where the number of buyers is limited by k and the total price paid is n corresponds to a solution to the original Set Cover problem with k sets. So, if you had a polynomial-time solution to the OP's problem, you could solve Minimum Set Cover by successively solving it for the case of 1, 2, 3, etc... buyers until you found a solution with total price equal to n.