I am creating Indent of multiple products and each time Purchase order for every product is created.
I want single PO for multiple products given in Indent.
Example: Indent contains 3 products, then 3 different PO for that indent is created for every product respectively.
Need solution for this
Related
So I have a current sqlite db table that contains the following:
Set Name
Set ID
Set Price
List of Items included in JSON
I am getting in a shopping list of items wanted from front end. Each Set could contain one or more of the items in the list, as well as items not on the list. How would I be able to find the cheapest way of obtaining the list of items by buying the right amount of sets, allowing for purchasing multiple sets to get all of the items on the provided list?
Example:
Set A contains 2 apples, 5 bananas, and 5 croissants. Costs $3
Set B contains 6 apples, 10 bananas, and 2 croissants. Costs $7
List: Need 10 bananas and 2 croissants. -- Result: Buy 2 Set As
List Need 15 bananas -- Result: Buy 3 Set As
List: Need 12 apples -- Buy 2 Set Bs
Currently just sorting the results by lowest price and adding the quantities of the list of items within the JSON together. Thinking there should be a more efficient way, may have to redesign the tables to allow for direct querying of the list of items, but the size of the list for each set can be different, and the request list can be of different items. Thinking this problem has probably already been solved, but also don't know what it's called or what the solutions are.
With Bigcommerce Price Lists, we obviously have the ability to give discounts based on bulk buys/qty.
We want to be able to combine the quantities of items in the cart if the products have a common custom field (or similar) and give the bulk price list discounts based on the combined qty.
For example:
Product A has a bulk purchase discount - buy 5+ and get 10% discount
Product B has a bulk purchase discount - buy 10+ and get 15% discount
Both these products would have a custom field/meta field at the variant level that = "Allow Combined Discount A"
So that means if Product A has a cart qty of 4, and product B has a cart qty of 6, the combined qty = 10
Product A should receive 10% discount (as combined qty >=5)
Product B should receive 15% discount (as combined qty >=10)
How can we achieve this? Ideally, the price updates/discounts would apply immediately when the cart quantities reach the correct levels. There could also be other products in the cart with different combining custom field/meta field values, which would need to calculate their own total - e.g. "Allow Combined Discount B"
Promotions on categories will not work as there are can be varients on products a and b where the bulk discounts do not apply, or the qty of some variants should not count towards a combined total to apply price list bulk buy discounts.
I work for an eCommerce company and we use Microsoft Excel for our inventory database. We currently just keep adding items to this database as we purchase them, without ever removing them. What I would like to do is start removing items as they sell. I am not sure how to attach the file, so if you e-mail me at drenollet#supplykick.com I can send it to you. Below are the following steps:
The Sales tab includes the sales data for the items. I would like to take this data and be able to copy and paste it in a sheet in our Inventory Managment file in excel (a separate file, but I included a sample in the "Database" sheet).
I then need to just use a VLOOKUP formula and the Catalog data to get the Product ID instead of the SKU. (I can do this.)
Then use the copied data in the Sales Tab that is in the Inventory Management file and move the corresponding rows out of the Database file/sheet to the Sold Items sheet.
A few thoughts on specifics:
I want to make sure all the quantities are right. (e.g.1 if we purchased two of an item and only one sold - reducing the quantity in the Database sheet from two down to one.) (e.g.2 If we purchased an item two different times at two different prices and both were purchased in one sale, I would want to make sure both of the rows are moved out of the database).
If you have any thoughts on making sure the quantities are right, let me know. Maybe we need to set all the purchase quantities to one and copy the purchase of a multiple quantity of items X number of times for each one that was purchased.
Would love your input on how to cross this bridge! Let me know if you would like to see the sample file and I can directly e-mail it to you!
Best Regards,
Don Renollet
The best way to do this is to have a sheet called Movements
then you have just rows of entries like
A B C D
----------------------------------------
prodID Movement type Qty Date
123 Purchase 5 08/01/15
789 Sale 2 07/01/15
123 Return 1 06/01/15
456 Sale 1 05/01/15
789 Purchase 10 04/01/15
456 Purchase 5 03/01/15
123 Sale 2 03/01/15
123 Return 1 02/01/15
123 Sale 1 02/01/15
123 Purchase 10 01/01/15
Then at anytime excel can calculate whats in stock using sumifs or similar
=SUMIFS(C:C,A:A,"123",B:B,"Purchase") - Sumif(C:C,A:A,"123",B:B,"Sale")) + Sumif(C:C,A:A,"123",B:B,"Return"))
You should never remove rows from a database like this, you can always do a stock take every so often and restart the database with 1 entry for each item, but aways store the old data elsewhere.
Try not to mix price with quantity if possible, if you need to manage price , consider using a moving average price (MAP)
I have 2 almost identical tables like this example:
item_list
store item price
-------------------------
store1 SKU2388 200
store1 SKU2377 150
season_list
store item price season_start season_end
-------------------------------------------------------
store1 SKU2377 100 12/10/10 31/12/10
store1 SKU2310 300 12/10/10 31/01/11
There will be multiple stores, and sometimes with multiple seasonal items specific to some stores that only available once in a time then disappears, and won't make it to normal items list. There will also be some normal items with promotional price on specific period.
Now, how can I make a compilation of these 2 tables, with all prices from normal items, combined with all seasonal items, and if there are some conflicting items, the query will return the one on season_list and discard those on item_list?
Thank you for your help :)
select COALESCE(seasonal.price,normal.price)
from normal left outer join seasonal
on normal.id= seasonal.id
column and table name is not what you mentioned but hope to get the idea.
It joins two tables and when the seasonal price in not exists or is null it returns the normal price.
I have an ecommerce store that I am building. I am using Rails/ActiveRecord, but that really isn't necessary to answer this question (however, if you are familiar with those things, please feel free to answer in terms of Rails/AR).
One of the store's requirements is that it needs to represent two types of products:
Simple products - these are products that just have one option, such as a band's CD. It has a basic price, and quantity.
Products with variation - these are products that have multiple options, such as a t-shirt that has 3 sizes and 3 colors. Each combination of size and color would have its own price and quantity.
I have done this kind of thing in the past, and done the following:
Have a products table, which has the main information for the product (title, etc).
Have a variants table, which holds the price and quantity information for each type of variant. Products have_many Variants.
For simple products, they would just have one associated Variant.
Are there better ways I could be doing this?
I worked on an e-commerce product a few years ago, and we did it the way you described. But we added one more layer to handle multiple attributes on the same product (size and color, like you said). We tracked each attribute separately, and we had a "SKUs" table that listed each attribute combination that was allowed for each product. Something like this:
attr_id attr_name
1 Size
2 Color
sku_id prod_id attr_id attr_val
1 1 1 Small
1 1 2 Blue
2 1 1 Small
2 1 2 Red
3 1 1 Large
3 1 2 Red
Later, we added inventory tracking and other features, and we tied them to the sku IDs so that we could track each one separately.
Your way seems pretty flexible. It would be similar to my first cut.