I have custom page and products will be displayed based on my custom criteria.
each block i have
Combo 1
item 1
$7.99 Qty 1
item 2
$5.99 Qty 2
item 3
$3.99 Qty 4
item 4
$2.99 Qty 6
item 5
$8.99 Qty 2
|--------------- |
| add to cart |
|--------------- |
when i click "add to cart" all the products with quantity needs to added to bigcommerce cart.
Can you please let me know how to add multiple products with quantity to cart.
Thanks in advance.
Dhamu
Related
I'm trying to develop a database for my inventory. But I have no idea how to keep track of multilevel packaging.
For example:
I currently have a products and positions table
products
Id | Name
================
1013 | Metal
1014 | Wood
positions
id | Name
================
1 | 1-1-1-1
2 | 1-1-1-2
And my inventory table I was thinking of doing something like this:
Let's say I stored 1 box with 1000 Metal and 1 box with 500 Wood at position 1-1-1-1
ItemId | ProductId | Quantity | PositionId
==========================================
1 | 1013 | 1000 | 1
2 | 1014 | 500 | 1
So I'll label those two boxes with a barcode 1 and 2 respectively, so if I scan them, I can check this table to see the product and quantity inside them.
But I can also put these 2 boxes (1 and 2) inside another box (let's call it box 3), which would generate a new barcode for it that, if scanned, will show both previous boxes and its items. And store this box 3 in another position
And I can also put this box 3 inside a pallet, generating a new code and so on. So basically I can multilevel package N times.
What is the best table structure to keep track of all of this? Thanks in advance for any help!
I would add another column to the products table, make it a BIT and maybe call it BOM, BillOfMaterials, or whatever makes sense to you
So your products Table would look like this
Then you could create another table called BillOfMaterials
Quantity is how many of your products are needed to make up your new product. So for this example 2 metal and 1 wood make a pencil.
I was able to make a good structure:
My products and positions are the same but I created a stock table like:
id | product_id | amount | parent_id | position_id
=====================================================
1 | 1013 | 1000 | 4 | 1
2 | 1013 | 1000 | 4 | 1
3 | 1014 | 500 | 4 | 1
4 | 1234 | NULL | NULL | 1
The 1234 (random id) is a box that contains 2000 metal and 500 wood. I dont save this box in the product table.
When I scan the box with id 3, I perform a recursive cte query:
with recursive bom as (
select *, 1 as level
from testing.stock
where id = '4' #scanned id
union all
select c.*, p.level + 1
from testing.stock c
join bom p on c.parent_id = p.id
)
select product_id as product, sum(amount), position_id
from bom b
left join testing.product pd on b.product_id = pd.id
where pd.id is not null
group by product_id, position_id
which returns:
sum | product | position
2000 | 1013 | 3
500 | 1014 | 3
to get by position I just run a variation of the above query. To perform an update I get the Ids inside that box and run a
update testing.stock set position = '2' where id in (#variation of above query)
I hope this helps someone. This works for N packaging level
We are combining products, and want to get an idea of what demand may look like for the combined products vs what we had before. Here is some sample data:
A mapping of where products will be going called SKU_Mapping:
Old Product | New Product
1 | 2
3 | 4
Then I have some historical sales information called Sales:
Product | Quantity
1 | 5
2 | 10
3 | 3
4 | 7
I also have a table with all the SKUs to link my two other tables together called Master_SKU
Product
1
2
3
4
I have relationships between 'Master_SKU'[Product] to 'Sales'[Product] and from 'Master_SKU'[Product] to 'SKU_Mapping[Old Product]
I am trying to get an output like this
New Product | Old Product | Original Quantity | New Quantity
2 | 1 | 10 | 15
4 | 3 | 7 | 10
I cannot figure out how to write a formula that says, take the quantity of the new product and add it to the quantity of the old product. I have tried a bunch of different operators but for the life of me I cannot figure it out. Any insights or suggestions will be appreciated. Thank you.
I did this:
Here's how:
I set up three tables exactly as you described, with the relationships as you described. Then I opened the SKU_Mapping table and I added a column:
Old Product Qty = CALCULATE(sumx(Sales,Sales[Quantity]),filter(Sales,Sales[Product]=SKU_Mapping[Old Product]))
...and another column:
New Product Qty = CALCULATE(sumx(Sales,Sales[Quantity]),filter(Sales,Sales[Product]=SKU_Mapping[New Product]))
...and one last column:
Total Qty = SKU_Mapping[Old Product Qty]+SKU_Mapping[New Product Qty]
I am designing a database for retail business using Sql server as backend. There are some products that can be sold in multiple units, for example, pencils can be sold in ea and dozen, paper can be sold in sheet, ream, and canton. Basically, each product can be sold in more than one unit.
The App needs to supports
Can receive products from suppliers in many unit. Sometime we might
order 1 pencil and the next time we order 2 boxes of pencil.
Can sell products in multiple unit, for example, we must be able to
sell 1 box and 2 pencils in the same bill.
App also need supports for FIFO or LIFO
Below is my initial design
Table: Products
ProductId | Barcode | Name | BaseUnitId
1 | XXXX | Pencil | 1
Table: Units
UnitId | Name
1 | Each / Pieces
2 | Box
Table: UnitConversion
ProductId | BaseUnitId | Multiplier | ToUnitId |
1 | 1 | 24 | 2 | // 24 pencils in a box
Table: Inventories
Id | ProductId | UnitId | Quantity
1 | 1 | 1 | 48 //In pieces
Table Invoices
Id | ProductId | UnitId | Quantity
1 | 1 | 2 | 1.5 //Sold/Purchased 1.5 boxes that means 18 pieces
Is there any flaws in my design? Is there anything that I miss? This can't be a new problem. Does anyone have any ideas (or examples)?
I have a few suggestions:
It seems like you could remove the UnitConversion table and just store the Multiplier value against the Unit record (so you'd store 1 against Each / Pieces and 24 against Box). Then the conversion would just be the 'From' unit's quantity divided by the 'To' unit's quantity.
Is is possible that different units would have different barcodes? If so, the barcode could be stored against the Unit record instead.
In your Inventories and Invoices tables, the ProductId column might be unnecessary as you could get this by joining Units table.
To support FIFO or LIFO, you're going to need to store more specific information about your stock, so there's some way of knowing the date it was booked in, the quantity remaining, and maybe some way of identifying that specific item (or group of items).
Hope this helps!
EDIT: Your Inventories table could look something like this:
Id | UnitId | [identifier] | CurrentQuantity | DateAdded
1 | 1 | ABC123 | 20 | 2017-01-10
2 | 1 | ABC124 | 96 | 2017-01-12
The [identifier] column (name's up to you!) would store some way of identifying the physical stock, this could be something that the users assign on receipt of the item, or maybe their suppliers would already have added some that could be used.
To implement FIFO in a scenario where someone wants to buy 24 pencils, you know you need to take 20 from the group of items labelled 'ABC123' and 4 labelled 'ABC124'.
I have a data set (currently in Access 2007 format) which has 2 tables, simplified to
category
categoryid | category name | first item
1 | category 1 | i1
2 | category 2 | i2
3 | category 3 | i3
items
itemid | item name | next item
i1 | item 1 | i4
i2 | item 2 | i5
i3 | item 3 | i6
The category defines the first item and each subsequent item references the next item until an item's next item is NULL, so it should be possible to find all the items for a particular category by continually following the next item field. Is this possible in SQL or do I need to drop out to a script to process it? I was hoping that there was at least a half-way house in that a SQL query could get me some of the way before using VBScript or similar.
I could import this to SQL server if that provides additional functionality not available in Access.
On SQL Server you can write such query using Common Table Expressions. See here: http://msdn.microsoft.com/en-us/library/ms186243.aspx
Not sure if it's possible in Access, though.
Our current database layout for store inventory includes a table that houses a record for each item and includes the item attributes such as price, cost, description, SKU, etc. Each store then has a table that has the SKU and the Quantity, and a few other attributes that are different for each store depending on the SKU.
Although this is better than having a column for each store's quantity in the Items table, it seems that this too is a somewhat ugly solution as when a new store is added, you need to select into a new table and when a new item is added, you have to insert into not only the items table but each individual store table.
Is there a better way to go about this than how I'm seeing it? It feels like there is.
Why not have a stock table with SKU, StoreId and Stock levels?
e.g.
Sku | StoreId | StockLevel
1234 | 001 | 15
1235 | 001 | 16
1234 | 002 | 8
1235 | 002 | 0
so, store 002 is out of stock of sku 1235, but store 001 has plenty. This table layout also allows you to get a group-wide view of your stock levels in a single table using something like
select sku, sum(StockLevel) from stock group by sku
By following the rules of data normalization, you would want to create a table like this:
store_id | sku | quantity | other_attributes ...
---------+--------+----------+---------------------
1000 | 129832 | 234 | ...
1000 | 129833 | 334 | ...
1000 | 129834 | 23 | ...
1001 | 129832 | 0 | ...
1001 | 129833 | 12 | ...
1001 | 129834 | 10 | ...
...
Essentially, it is a store_inventory table. That way, you can filter down to a given store by saying
WHERE store_id = 1000
etc...
You really want three tables as far as I can see:
Product
ProductID
Price
Description
...
StoreProduct
ProductID
StoreID
Quantity
...
Store
StoreID
Address
...
That's a perfectly valid and normalised database design, and sounds basically what you have right now.
It sounds like it started on the right path with having one table for all of the common attributes of the item.
Instead of having an individual table for each store, the inventory counts for all stores should be in a single additional table, using the Item's Key and the Store's Key as a combined Primary Key on that table.
For Example
Items
ItemKey
Name
Price
SKU
Stores
StoreKey
Name
Address
Inventory
StoreKey
ItemKey
Quantity
Using the StoreKey and ItemKey together on the Inventory table will keep your records unique.
This will allow you to not only easily lookup the single item but also lookup such things as:
Quantity of all items at one store by the StoreKey
Quantity of one item at all stores by the ItemKey
What items are low at all stores by Quantity
etc