I have been developing an Inventory system (PHP Codeigniter & MySQL), I have setup almost everything except one feature which one of my clients wants to implement to the system - A multi - unit support feature for the system.
Currently my system only supports single unit per item per transaction:
item_desc: Item1
default_unit: pc
reorder: 1
in_stock: 25
remain: 25
In multi - unit feature, this would become:
item_desc: Item1
default_unit: pc
big_unit: pack
pack_size: 50
reorder: 1
in_stock: 25 pack
remain: 24 pack 5 pc
Can someone give me hint on probably the easy way to implement this? I just want to know where to start on this thing. I would appreciate much if someone could share an idea regarding on this one :)
We just launched v2 of our website and I've gone through 8 months of all kinds of questions like this myself. The best way to do it is to separate your tables into products, inventory and listings.
Products holds product specific information only, things that will never change.
Inventory holds information about current inventory only, ie quantity on hand, backorder, location in warehouse etc.
Listings are how you handle the multi item support. This table would hold listing information and draw from the other two tables for the product and quantity data. So you'd have a basic table structure something like this
Products
productId
productName
productModel
productDescription
Inventory
inventoryId
productId
quantityOnHand
location
Listings
listingId
inventoryId
quantityInListing
numberOfListings
price
Our company sells a lot of preowned things so the listings change regularly, but you could always set the listings up to auto-populate based on inventory if you're selling new things that you just restock. Doing it this way means you don't end up with a ton of data duplication as you would if you just created products for the multiples. It also allows you to sell any item in any quantity and set prices for those quantities manually.
Related
I'm designing a database for product rental. I'm using Laravel 8 framework.
prices change all the time.
The rental order requires a quote generated by the client.
The prices are stored but not listed in the user view, they are only for reference in the admin order quote generator view.
The client wants to be able to change the price for each quote before sending it as their specific client may need special treatment.
So, summing up, I need:
To store a record for the price of a specific order quote.
To store a base price and a history record of this price.
To be able to list the available products in between two dates filtered by the status of the order, which will change until the final approval of the quote. Also filtered by the stock available.
Have additional costs associated to the specific order.
Different total price for deferred payment.
This is what I came up to, I have a table for:
Orders
Products
Order_Product (this name format is required by laravel's eloquent)
Products_Prices
Additionals
Orders_statuses
In the order_product table I'm planning to store the price defined for the client, and the count of rented products. Also foreign keys for a many-to-many between products and orders.
In the order I'm planning to store the "pickup" and "return dates to query first WHERE "orders with approved status" BETWEEN the two dates selected by the user. Finally get order_products with a NOT IN to display the available products.
The products_prices table I use it to store the changes record.
In the products table I have availability because the product may not be available for rent for many reasons for a period. Stock and colors that I will use for ordering the list because of a requirement from the client so I go first for primary color, secondary and tertiary afterwards.
I'm not sure if this is the most efficient way to achieve what I'm looking for. Since I will need to check products availability all the time I need to be sure that this is the fastest and more reliable one.
I'm not english speaker so I feel the need to clarify this:
The client = My client.
User = My client's client.
Thanks in advance!
I have one more complex questions, so I will split it. Since it is basically one topic I don't wanna to split it into two separate threads. I would be grateful either for any information about an existing module, or any idea how to do this by yourself.
Question #1
If I understand the product price calculation process in Prestashop I basically have two options:
Price defined on a product
Price defined on a product combination
What I need, though, is to provide customer with more advanced calculation. Let's say products can be assembled and equipped with multiple different tags. Therefore, I can't use product_attribute (Combination) as no matter if I assemble the product or not, it is always the same product with only one physical amount of products on stock. As if it was a Combination, and customer order the product assembled, the stock would only be decreased on for this Combination, but not for the other Combinations. Hope that makes sense.
Example:
Painting #348 + frame + additional service = $500
Painting #348 + frame = $375
Painting #348 = $345
It is even more complicated as these sort of "additional services" are only available to relevant products. Another products may offer customers different "additional services".
Question #2
For scenarios from Question #1, I need also to differentiate the price. So if a customer wants to buy 300 pieces of a painting with frame it is $10 cheaper per product. If the amount is over 500, it's $25 cheaper etc. I know I can do this for a regular product or a combination, but how would you do it if the price would be custom just like in Question #1.
Thanks a lot for any help!
I am not sure if i have understood your question completely or not but, as far as i understood here is your solution:
You may have a product:
XYZ Pizza
(with different toppings like chicken, red meat)
(also have sizes Small, Medium and Large)
Off course you will have different prices for different combination.
So what you can do is:
Create a product XYZ Pizza with price zero and quantity zero.
Add combinations to the product, so you just need to add actual price of that
combinations, no headache of increase decrease calculations for price.
It is super easy if you are using csv import.
And don't worry as long as you have a single combination with some price for that product the zero prices won't be shown on your website.
Hope it helps.
I'm working on an order system for my online shop. I have 2 tables:
products, storing info about products
orders, storing general id's & infos of customer orders.
Now I want to have a way to store complex customer orders in the database. I need something that will let me know how much of each size (S, M or L) of each product is in an order.
The tricky part is that I want to be able to add/edit/delete products (of course without affecting orders from the past), so the method should be flexible
How should I go about this?
a separate table for every order, with products as rows?
one table for all orders, with products as columns?
some other option?
Thanks!
Depends on your goals for your cart. For instance, do you want to allow guest purchases? i.e. where a user does not need to login in order to make a purchase?
The attached image is a design I have been working on and it goes like this:
A visitor selects products from the site and adds these to a session cart (just a place to temporarily store the products, their quantities and their prices etc.)
Once the customer is ready to check out, we create the order, the order person and the person_address (where the product must be delivered to) and add the items to the order_item table. All this information is added by the customer in the checkout page.
The final step is then to offer the payment methods: paypal, credit card, etc.
What I like about this design is that users have no obligation to register with us. Order_person acts as a kind of interface between users and orders. If do register, we simply link order_person to the user table...
I have included a sample front end of the checkout page too.
At the very least you need:
Products (one row per product)
ProductID
Size
Orders (one row per order)
OrderID
OrderDetails (one row per product per order)
ProductID
OrderID
Size
Note that each 'size' is its own ProductID. You'll probably want to have yet another ID that groups products that are the same 'base' product, but in different sizes.
So if Order #1 has three products, and Order #2 has four, then OrderDetails will have seven rows:
OrderID ProductID Quantity
1 234 2
1 345 9
1 456 30
2 432 1
2 234 65
2 654 8
2 987 4
My questions is basically I have 2 products that can be sold separately and together.
What I want to do is take these 2 individual items, create a new product in Magento for it with a new image that will show both of them together for a combined price. When this particular item is sold then it will reduce the qty from each of the individual sku's that were created. Is this possible?
As an example,
SKU 1 - Wii Remote - $30
SKU 2 - Wii Nunchuk - $15
SKU 3 - Wii Remote + Nunhcuk - $45
So when sku 3 is sold it will reduce the qty of sku 1 and 2.
Thank you
Maybe a "bundle" could help you?
http://www.magentocommerce.com/knowledge-base/entry/creating-a-bundled-product
I don't know for sure, because I have never used Magento. I just Googled your problem.
A bundle product will do if your rules are within these:
Points to Remember
A Bundle is a “build your own” product type
Bundle Items can be Simple or Virtual products, but without Custom Variants and Options
The Price View of a Bundle can be set to display a price range or “As Low as”
The SKU and Weight of a Bundle product can be set to either “Fixed” or “Dynamic”
Items can have either a preset or user-defined quantity
Items can be shipped together or separately
Bundle product data cannot be imported into your catalog.
Means : bundle product cannot have a configurable product within.
so if your SKU1 and SKU2 are not configurable or rather just simple or virtual then you can create a bundle product and sell the way you have stated.
I don't necessarily agree with the way magento wants us to sell our "Bundles"
It lets users decide which products they want to combine, it's really similar to a "Grouped product".
To me a bundle is predetermined by the store owner, If A is Bought together with B & C, then the customer saves X amount of money... It's not up to the customer to decide what's part of the bundle.
SO I ended up creating the Bundle, adding all the products I want in the bundle as a "Multiple Select", ticked them all as "Default",
and I'm hiding the options with CSS, only showing the price and the add to cart button (Every product has it's own class in ): body.product-name #product-options-wrapper { display: none }
So of course if you have thousands of bundles then this won't work for you.
I'm really happy with this solution because 1. It updates the inventory & 2. All of the SKUs are displayed on the invoice! (For me they are also lot numbers)
I'm working on a Magento site that has a number of simple products. There's also a "holiday package" which combines several simple products into one, at a discounted price:
6 of Item A
2 of Item B
2 of Item C
2 of Item D
The "grouped" product type is pretty close to what I need - it allows each item to keep track of it's own stock, and when it comes time to ship and estimate packages, it tries to pack the containers using the weight/volume of each individual item. (This shipping aspect is very important, as we need to pack the boxes as efficiently as possible - using a simple product with an estimated size for all items may not work).
However, we do not want the customer to be able to choose the quantity of each item. The customer should instead be asked to choose how many holiday packages they would like.
Is a grouped product the best approach? Is there a better way to handle this?
In Magento 1.5.1, the best solution should be the bundle product. There, you can define a price, a quantity for each item in the backend. You can block the user to change the quantity for these items, not for the bundle product (you could too if you want but it's not your need here).
We do like that for some of our product. Check the screenshot to see an example of configuration