-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Behavior when the minimum order quantity (MOQ) isn't met #498
Comments
Thank you for taking up this feature - it crossed my mind lately for a component where I had to buy multiples of 5. Not as catastrophic as 4000! And multiples may be another issue from MOQ's with not so easily available data. Possibly you have to consider MOQ's not only as a minimum, but also as a multiplier. I see two major approches to handle MOQ's, considering that you might be making a one-time buy or a repeated buy. With regards to the MOQ:
This also makes me think about the habit some (prototype) PCBA manufacturers have: add 10% (and minimum 1) extra component to the order to cope with mistakes or mounting issues. Something I also do depending on how critical and pricy the components are. So that could be another rule that could be added as a spreadsheet order: minimum extra % and minimum extra component count. The latter is of course another feature, and I only think and suggest it here because it seems to have a close relation with the MOQ feature and might be appropriate to add whilst you are or have been working on it. There is the extra complexity of having to order from different suppliers in case one of them alone does not have enough components to satisfy your need. But that is an exception that I think the user has to handle himself. |
- Now we always add the order, but using the MOQ. - Related to the discussion in #498
This is true, if the MOQ says 5 it most probably means you must buy in multiples of 5.
Too far from the current state ;-)
I'm not sure about adding 4000 to the order because the user entered 2 ... but in general what you say is the most simple solution. I think we should always highlight the cell if the order doesn't match what the user entered. The 57478e3 adds the MOQ multiples feature.
I think that the most common mechanism for this is to add N extra boards. If a component is too expensive to buy spares you can always buy less than what the spreadsheet suggest for this particular component. You'll always need to adjust things manually. The number of spare parts is very specific of the part.
Yes and remmember we are creating an spreadsheet without macros, this restricts what we can do a lot. To make things worst the spreadsheet must work with the most popular software. I found some features that are handled in different ways by each of the three programs I tried! |
More limitations that I doubt we'll solve in the near future: if you take a look at the same component, but from Digi-Key you'll see that KiCost mixed the unitary and tape reel prices. So you could enter 5000 and KiCost will use the price for 4000, this is $0,053 with a total of $264,50. But the reality is that you have to buy 1 reel ($211,60) plus 1000 from a portion of a reel, which is $0,06084 * 1000 = $60,84. And in this case you'll want to add the extra $7 to make these 1000 parts usable in a pick & place machine, so the real value is: $279,44. This is about $15 more. Not a huge difference, but is around 6% of error. |
Sure, there is also the more common effect of ordering components and having to add the shipping costs and coping with differences in the currency conversoin or pricing differences across countries vs. the pricing for the country the pricing is valid for. For me KiCost is a tool to help create valid BOMs for different variants, estimate (public) pricing and availability at a given moment in time and help identify where you can source them. It gives a good idea how much the BOM is at different quantity breaks and helps identify where you can potentially save money. |
I liked the more obvious "MOQ=?" message, it more emphatic, also with the default hidden for MOQ column. I see the you (@set-soft ) also made some updates to thee purchase string presentation at the bottom. KiCad was lacking of some visual improvements at the spreadsheet. |
But I didn't remove it! Is there, when the global Qty < MOQ.
Yes, but is more like an accident ;-) |
My last patch (1c0a850) changes a lot of details about this behavior.
I'm opening this discussion to know the opinions about it.
As an example I'm using the
test_2
you can generate it by running:The previous behavior was like this:
You can see the best
Unit$
is $0,053, this is from Farnell, but when you check it this is because the MOQ is huge, at least 4000 parts!This is unfair because this cost is compared with costs for 100 pieces.
Purch
field you'll get:Here you get a yellow warning, but you also get a line to order the parts, but this order is invalid, Farnell won't sell you 3000 parts because the MOQ is 4000.
Here is the new behavior:
Now you get a minimum
Unit$
of $0,098, with a fair comparisson.Note that now the Farnell
Unit$
is yellow, indicating a problem and the cell saysMOQ=4000
indicating that this MOQ is bigger than the globalQty
value. Also note that Farnell'sExt$
is empty and yellow.Purchase
with 3000, like before, we get:Note that now you don't get a line to order 3000 parts, and of course the 3000 is in yellow.
Now the minimum is $0,053 and now we get a purchase order.
This patch introduces a new column with the MOQ, this column is hidden, but you can make it visible using the button to expand the collapsed column. Lamentably Libreoffice 7 fails to just collapse the column, you have to also hide it. And if you think this is a buggy spreadsheet just try Excel from Office 365 ... it hanged for minutes when I tried to expand this column, not to mention that you can't edit array formulas. All the functionality of this patch seems to be working for Libreoffice 7, Google Calc and Excel Office 365.
A minor detail: if you look at the line under the one we analyzed you'll note that the global
Unit$
andExt$
were $0 before the patch and now are just empty. This is because no distributor has this part. I think empty cells are better than pretending you'll the part for free ;-)Any comments? @hildogjr @devbisme @mdeweerd @xesscorp
The text was updated successfully, but these errors were encountered: