How can I prevent Magento from reserving product stock on "pending" orders. Generally allow stock quantity reservation for paid orders only.
Thanks a lot!
This can't be done without code changes.
In Order to generally prevent Magento from subtracting stock quantity from products you may use system configuration field "Decrease Stock When Order is Placed" set to "no" under System Config->Catalog->Inventory
To achieve desired behaviour you may try following Solution:
Disable default magento behaviour by setting "Decrease Stock..." to
"no"
Create new local Module
Add Observer for event sales_order_save_after
Compare status values and decrease stock when needed
Related
So I have a table categories with the following columns:
Id, Category, Vat, Tax
And a products tables with the following columns:
Id, idCategory, Code, Product, Stock, buyingPrice, sellingPrice, Sales
When creating a new product the value of a product is entered and the buyingPrice is calculated by adding the Vat and Tax from the categories table to the value.
The sellingPrice is then calculated by a percentage markup of the buying price.
I now want to be able to automatically update the buyingPrice of all products if the Vat or Tax is changed.
I have tried creating a trigger but I am currently unable to work it out. I'm not sure if it's because the original value is not saved or if I am doing it all wrong. I have never created a trigger before so any push in the right direction would be appreciated.
I think Strawberry has a great comment here; you should store the VAT and tax separately and apply them to the base price that you store, rather than storing it as a final selling price that includes VAT or tax.
In your scenario, what happens if the VAT is reduced by 0.5%? Your trigger can be modified to properly account for newly inserted items, but how will you go back and correct existing ones? In the US, an item can be exempt from sales tax (if the purchaser is a certain type of non-profit organization or other exempt business, or in certain states during a sales-tax holiday). Again, in the US, sales tax calculations regarding putting an item on sale can be complicated. I'm not making the assumption that your situation will require dealing with those situations, but it seems like it would benefit you to not need to recalculate every item in your database if any of these were to apply.
If you really insist on this, I'd personally rather use a view to calculate the price on the fly rather than using a trigger to calculate it on insertion, but that's just me. Again, I'd ultimately prefer to handle this in the application logic.
[EDITED] I am working on a simple setup of inventory with following tables and columns:
Item Table [Edited]
id|title|supplier_id|sku
Stock Table [Edited - Main Inventory]
id|date|item_id|quantity
Stock Received [Received against Purchase Order]
id|item_id|qty_received|date| purchaseorder_id
Stock Issuance [Issued against Demand Note]
id|qty_given|date|demand_id
Quantity in Stock table will be increased/decreased dependent on stock issuance or stock received , so the quantity will always be physically accurate.
[NOTE] I want to keep my item list totally separate from in/out transactions, so i kept it separate.
"Stock Table" is where i keep the exact quantity of every item.
"Stock Rec" + "Stock Issue" are used to keep track of item in/out transactions, instead of keeping extraneous column of in/out transactions in "stock table" and continuously updating them without a record of when the transactions were made.
My question is, Will i be able to calculate the Opening & Closing balance accurately. on any given dates? using all four of these tables.
Please note, then "Stock Table" holds, around 18000 rows and can grow with a rate of 10-15 per month.
Yes!
The structure that you are using is enough and quite efficient as per your requirement. It will definitely be able to provide all necessary details ( as described in OP) for opening and closing balance of given dates.
Use of joins will be quite helpful.
I need some help updating all configurable products from
Manage Stock = no
and
Stock Availability = no
to
Manage Stock = yes
and
Stock Availability = yes
via the database...
the stock for the products I believe is in the table
cataloginventory_stock_item
however I can't see where the product type = configurable is defined in this table, which causes a bit of an issue as I can't see which to update...
Any thoughts would be very appreciated
Regards
Henry
if you only update the configurable product quantity,best solution is Go to admin>system>Import/Export>Dataflow - Profiles>Export Product Stocks
Then select only Mapped Fields in Data Format and add these required fields (screen shot below) in Field Mapping section and save and continue,
Then go to Run Profile section in your left hand side and click on Run Profile button.
Connect FTP or download your csv root/var/export/export_product_stocks.csv update product inventory or import Import/Export>Dataflow - Profiles>import Product Stocks
upload your file and same run profile.
your all product's inventory will be updated.
Thanks......
I'm building a website and I'll be charging my customers to use it. I'm thinking of having 6 monthly or yearly licence options and there'll be a few different variations of licences available each granting different types of access to the site.
Also I'll have a few optional extras that you can add on to the purchase of their licence. These would be once-off purchases more like products rather than licences. They're more add-ons for the website that enable more features. Once purchased you get to keep it. So everything's based on the site there's no shipping to worry about.
This will be displayed in some sort of shopping cart fashion where they can choose what they want then sent through to Paypal for processing.
Just wondering how I would model this correctly in my database? So far I've come up with:
Database schema
Basically I've tried to put licences and products in the same table and used a flag column (licence_or_product) to distinguish between the two. This would help in the display on the website about whether it's a product or licence.
Is it worth having the licence *offering_start_date* and *offering_end_date* fields? I'm trying to get it so that I can expire that offering if I want to make a new licence offering with a different price. That way customers who have already purchased the licence at that price it always stays at that price. If I want to change the price, I'll set the offering end date to today, then make a new licence_products row with a lower price but end_date in the future. Is that the right way to do it? Or do you just edit the price of the item directly? I'm just thinking if the price changes then the customer wants a refund for that licence, how do you track how much they paid for that licence? The amount_paid field would tell me how much the whole order cost but not the original price of the licence which has now changed. Do I need a history of all the product price changes?
Other thing I don't know how to do, lets say they've purchased a licence to use the site for a year. How do I pull out which is the most current licence? Lets say I've started them off with a 30day trial licence, then they purchase a yearly licence. Do I invalidate the trial licence immediately? I think I only want one valid licence at a time. So if they buy another licence before the old one expires I'm not sure how my program should handle that.
Any help much appreciated. Thank-you!
P.S. Here's the SQLyog database schema and SQL if you want to have a go at reworking it a little.
sql db extract
SQLyog schema
I think you should create the following 3 tables:
1. customer (client or whatever make sense to you),
2. license and
3. customer_license.
And I suggest the following fields for the customer_license table:
id (some int auto_increment)
customer_id (some int) FK
license_id (some int) FK
price_offered decimal(7,2) (with the precision you need)
expiration_date date
active tinyint(1)
created_at datetime
updated_at datetime
This way you can track all details of the customer with the license you offered them: what you offered? when you offered? when does it expire? price offered? the license is active?
Good luck
What is the general pattern or approach to managing transactions in a web-based e-commerce system? How do you handle the situation where more than one user tries to buy the last item, for example?
To prevent two users from purchasing the same stock item of which there is only 1 unit in stock, you need to check that each item in a user's cart has stock available right before you create an order and decrement stock for that item.
This operation will have to be atomic and only one order can be processed at any given time (read: database transaction), which should not be a problem if you are using a central database for stock management.
If stock has run out by the time a client checks out, you should remove the item from the client's cart and redirect them to their shopping cart, informing them of the situation.
Of course, this situation only occurs when two users both add the same stock item to their cart of which only one unit is in stock and one of them checks out. First come, first served. You should generally not allow clients to add products to their cart if no stock is available at that moment, unless you can order new stock within a reasonable amount of time, but in that case, the whole point is moot.
You can take a preemptive approach by checking that stock is available the moment a client initiates checkout and take the same route as above. However, that would depend on the nature of your product and the volume of transactions vs cancelled orders. If it is likely that another order for the same item was cancelled in the meantime and stock becomes available by the time a client checks out, then you don't want to lose a sale by telling the client that no stock is available. Better to let the order fail at the moment stock is not available and inform the client of the situation, which is rare after all.
Why not take the order and then get that item for the customer, perhaps a bit later? You can win a repeat customer :)