You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For example, I have a project that requires 500pcs of part X; and currently only have 400pcs in stock. In the distributor tab of that part there exist two prices from the same supplier, 500pcs price, and 100pcs price.
Autofill is smart enough to know that I am 100pcs short and tells me I need to order 100pcs, however the price is based on the 500pcs order price, rather than the 100pcs order price.
Partkeepr should probably use the price per part of the next lower order quantity, failing that, bump up the "Amount to Order" to the next higher order quantity as set up in the distributor tab of a part. That way the actual to-order cost is correctly reflected.
This was reproduced in a local install of 0.1.9, I have not tested it on the demo server but I assume the results would be similar.
Implements the feature described in issue partkeepr#341 / partkeepr#404 (related / duplicates)
This simply adds a check to the report calculation which takes the packagingUnit into account.
If the part count (so the missing parts which have to be ordered) is not larger than the packagingUnit of the part distributor, that distributor is omitted (by the continue keyword).
For example, I have a project that requires 500pcs of part X; and currently only have 400pcs in stock. In the distributor tab of that part there exist two prices from the same supplier, 500pcs price, and 100pcs price.
Autofill is smart enough to know that I am 100pcs short and tells me I need to order 100pcs, however the price is based on the 500pcs order price, rather than the 100pcs order price.
Partkeepr should probably use the price per part of the next lower order quantity, failing that, bump up the "Amount to Order" to the next higher order quantity as set up in the distributor tab of a part. That way the actual to-order cost is correctly reflected.
This was reproduced in a local install of 0.1.9, I have not tested it on the demo server but I assume the results would be similar.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: