Not Taken
Allow composite values of less than 1 for an inventory item
Mark Aldous
said
over 11 years ago
This won't be possible, if delivering a composite the composite needs to be 1 ie the whole composite is being delivered.
If you need to partially deliver a composite (part of the composite) then the granular items need to be delivered.
If you need to partially deliver a composite (part of the composite) then the granular items need to be delivered.
Is it possible to do it this way? Say 1 multi-pack has 100 individual items. We say in packs of 10 and packs of 50. If we could create a composite item using 0.1 and 0.5 of the original multi-pack item, respectively, it would work. However, we're not able to enter decimals in composites. This would also allow for scrapping, say, 2 or 3 of every 100-count multi-pack due to defects. If we have to enter POs and manually change the initial quantity (to, in the example, 100 for every 1 ordered) for each item (and there are items that come in packs of 1, 2, 3, 5, 10, 20, 25, 50, etc. all the way up to 1000s), then it's going to mean that using LinnWorks actually takes more time than doing it all manually. We're looking at purchasing a subscription but can't go with it until we know that we can enter multi-packs and sell off composites. That one disallowed decimal issue seems to be the primary problem standing in the way of going with LinnWorks. Any help would be appreciated!
We'd like to see this feature as it's critical to our business
I've been working with support on this very issue for the past few days. Your support person is working with a supervisor to come up with a work-around for me being able to put in PO's with my supplier by doing some kind of translating of sku's and quantities.
If you think strictly in terms of "composite" (item composed of components), then you can get stuck thinking that you always have to have positive integers.
What we need is the ability to ship smaller quantity of an item. For example using food products as an example. The item might be available from a wholesaler in a 55 lb bag only. You need to buy from a wholesaler by the bag. But you want to sell to your customers in smaller quantities. Say 2 lbs, 5 lbs, 10 lbs, 20 lbs.
Your true stock keeping unit is the 55 lb bag. You want to maintain your stock levels and reorder by the 55 lb SKU.
So to sell smaller quantities, you need to want to have a SKU that is made up as a smaller quantity of another SKU. Let's say I have 10 bags of X in stock. I sell two 10 lb units and a 5 pound unit. I know should have approx 9.55 bags in stock.
I saw in the forum where somebody is selling products that they buy from their supplier by the barrel, and sell by the liter or 1/2 liter. Another good example.
My workaround for this is that I have to create a SKU that represents 1 lb of the item. Then I have to create the larger sizes, all the way up to the 55lb bag as composites. So if a customer wants to buy 1 full bag of the product, I'm really selling 55 x 1 lb SKUs. Instead of having 10 bags of the product from the supplier in stock, I have to keep 550 of the 1lb SKUs in stock. Then when I want to reorder from my supplier, they're going to get confused if I'm ordering Qty=550. So this is what LinnWorks support is working on for me. Some custom translation of 55 SKU1's into 1 SKU55 for the purpose of the POs, but on the PDF output only. Because in LinnWorks, I still have to have my PO show up as 550 SKU1's and when I book it in, I'm booking in the 1 lb units.
So if a Composite has to be made up of whole items, and you want your SKUs to match reality, then we need a new type of product called a Fractional Unit, or whatever,
If you think strictly in terms of "composite" (item composed of components), then you can get stuck thinking that you always have to have positive integers.
What we need is the ability to ship smaller quantity of an item. For example using food products as an example. The item might be available from a wholesaler in a 55 lb bag only. You need to buy from a wholesaler by the bag. But you want to sell to your customers in smaller quantities. Say 2 lbs, 5 lbs, 10 lbs, 20 lbs.
Your true stock keeping unit is the 55 lb bag. You want to maintain your stock levels and reorder by the 55 lb SKU.
So to sell smaller quantities, you need to want to have a SKU that is made up as a smaller quantity of another SKU. Let's say I have 10 bags of X in stock. I sell two 10 lb units and a 5 pound unit. I know should have approx 9.55 bags in stock.
I saw in the forum where somebody is selling products that they buy from their supplier by the barrel, and sell by the liter or 1/2 liter. Another good example.
My workaround for this is that I have to create a SKU that represents 1 lb of the item. Then I have to create the larger sizes, all the way up to the 55lb bag as composites. So if a customer wants to buy 1 full bag of the product, I'm really selling 55 x 1 lb SKUs. Instead of having 10 bags of the product from the supplier in stock, I have to keep 550 of the 1lb SKUs in stock. Then when I want to reorder from my supplier, they're going to get confused if I'm ordering Qty=550. So this is what LinnWorks support is working on for me. Some custom translation of 55 SKU1's into 1 SKU55 for the purpose of the POs, but on the PDF output only. Because in LinnWorks, I still have to have my PO show up as 550 SKU1's and when I book it in, I'm booking in the 1 lb units.
So if a Composite has to be made up of whole items, and you want your SKUs to match reality, then we need a new type of product called a Fractional Unit, or whatever,
Hi
I also need this type of feature.
At the moment I am using the free Linnworks Express to try out the software to see if there is a way to handle my scenario that is similar to this. Once I know I can do it, I will subscribe!
I buy bags in cartons up to 50,000. They come in boxes of 1,000 within the carton, and inside the boxes they come in packs of 100.
For many of these I also sell bags of 50, so have to divide the packs of 100 into 2 packs of 50.
When we order from our supplier we say how many thousand bags we want of each size, so that is fine.
The problem occurs here. We have to record each SKU as 1 individual bag and make composites for 100, 200, 500, 1000 and any other quantities that we sell (with price breaks at each quantity level). So far so good. But the bags are charged by our supplier by the thousand, and I have to record them in Linnworks individually, however the individual price is below 1p for some of the bags, and so it treats them as 0p / free! It does not record any more than 2 decimal places, i.e. prices less than 1p are free. So that means 1000 or 50000 are also treated as free because 1 bag is considered free.
I cannot see a way around this without allowing SKUs to be priced with more than 2 decimal places, or as you say perhaps having fractions in the composite quantities, or enabling the purchase prices to be specified for a higher quantity, i.e. 1 bag is bought via a pack of 1000 at a particular price for 1000.
Any suggestions?
Thanks
Nick
I also need this type of feature.
At the moment I am using the free Linnworks Express to try out the software to see if there is a way to handle my scenario that is similar to this. Once I know I can do it, I will subscribe!
I buy bags in cartons up to 50,000. They come in boxes of 1,000 within the carton, and inside the boxes they come in packs of 100.
For many of these I also sell bags of 50, so have to divide the packs of 100 into 2 packs of 50.
When we order from our supplier we say how many thousand bags we want of each size, so that is fine.
The problem occurs here. We have to record each SKU as 1 individual bag and make composites for 100, 200, 500, 1000 and any other quantities that we sell (with price breaks at each quantity level). So far so good. But the bags are charged by our supplier by the thousand, and I have to record them in Linnworks individually, however the individual price is below 1p for some of the bags, and so it treats them as 0p / free! It does not record any more than 2 decimal places, i.e. prices less than 1p are free. So that means 1000 or 50000 are also treated as free because 1 bag is considered free.
I cannot see a way around this without allowing SKUs to be priced with more than 2 decimal places, or as you say perhaps having fractions in the composite quantities, or enabling the purchase prices to be specified for a higher quantity, i.e. 1 bag is bought via a pack of 1000 at a particular price for 1000.
Any suggestions?
Thanks
Nick
Matthew Price
1 person likes this idea