In this article, we want to look at two topics that may be solved technically with very similar functions, even though, at first glance, they seem to have little in common.
These are
- Purchase quantities and pack sizes
- Minimum order quantities
Let us first take a step-by-step look at units and products.
Purchase quantities and pack sizes
If you have already worked with Odoo, you may have stumbled across the fact that you may put in any quantity you like when you enter inquiry items, as you can see from the following screenshot:
But what
if a particular product cannot be purchased in any given quantity? In many
systems, you can install a counter at the master data level specifying the
increments in which quantities can be counted up or recorded.
The solution
In Odoo, this is possible as well. You can simply create units in Purchasing. Still, you need to remember that these units will also exist in Sales. Odoo leaves the creation and use of units quite open and flexible. There is one condition, however: the products need to be in the same category for Purchasing and Sales.
To do this, go to the menu item for creating
unit categories:
Example
We have stocked cutter blades sold as pieces, but they can only be purchased in packs of 10. We will create a separate category for these blades to avoid confusion with other products and simplify handling other requests. This ensures that only the purchase units for the blades will be displayed.
In the systems, our example would look something like the following:
It becomes immediately apparent that rounding can prevent a nonsensical entry such as 4,333, as in our first example.
Now, it is time to create the corresponding product. Here, we switch directly to single blades in Sales:
Since the sales unit is also the leading inventory unit, we will have individual pieces in stock, and customers can order individual blades.
We
determine the purchasing unit in the “Purchasing“ tab. Here, we set “Pack of 10
blades“ as the standard unit:
To check
whether our settings are already working, we can display the purchasing units
in the price list for each supplier by clicking on the column overview on the
right and activating the units:
We can
then see that the unit “Pack of 10 blades” has been adopted:
Now, we only have to remember that the purchase price for the pack also needs to be entered.
The whole thing can be tested by triggering a purchase directly from the product. To do this, we click on the “Replenish“ button:
By confirming the requirement, we receive an order request for 10 blades in one pack:
If we change the quantity to 2, 3, or 4, it will, of course, gradually increase to 20, 30, and 40. After confirming the order, you will see that 40 blades are expected in the incoming goods department:
And in incoming goods:
Minimum order quantity
In the next step, we set ourselves the task of purchasing at least 20 blades from the supplier (i.e., at least two packs of 10 on the order).
The problem
Here, too, you will find that there is neither a configuration available in Odoo nor a note on handling this problem in the official documentation.
Since Odoo directly generates an order request, at least one supplier for this product should be stored for the minimum order quantity to work. If three of our cutter blades are reported as a requirement, and the three directly become 20, what would happen if a further requirement for three blades is reported a short time later? At this point, it is no longer known that the 20 actually only refers to a requirement of three. The additional quantity would, therefore, have to be added to the 20. However, the actual order quantity would only be six, and the amount would still be within the minimum order quantity. The difference would be an even larger excess quantity.
The solution
This issue has two possible solutions that do not necessarily exclude each other.
Procurement rule
The most common way to trigger a requirement in the system is probably by creating a procurement rule. The minimum value (“Min“ column) indicates that the rule is triggered when the available quantity in stock falls below this value.
An order request is then calculated as the quantity to be reordered based on the difference between the minimum and maximum values.
The
following shows an example of such an order rule:
If the stock quantity of our cutter blade is nine, this will trigger the rule. Since the stock is to be refilled to 30, the amount to be reordered is 21.
Replaying this situation, we get the following order proposal:
Since we also get the Pack of 10 as a result, the procedure seems to work quite well.
This leads us to conclude that a minimum order quantity should, even must, be included in the difference between minimum and maximum.
In our case, it is clear that the buyer would have to adjust the quantity manually, as a quantity of 2.1 indeed cannot be purchased. Whether it makes sense at this point to round up or down is open for discussion, but the situation will probably not be that simple. The respective quantities are brought together from different procurement sources, and rounding up or down at this point could have adverse effects. Therefore, we recommend that the final correction be a human user's job.
Purchase price list
Let us move on to the second solution, which, by the way, does not replace the procurement rule. This option may be used as an add-on or when dealing with a product without automated re-purchasing.
There are two additional hidden fields in the master data:
When
creating a supplier, it is possible to store a different product number (Vendor
Product Code) as well as a name or description (Vendor Product Name) for each
supplier.
The purchaser is automatically alerted if we simply enter the minimum order quantity as a text for the product name. The supplier, of course, will also see this text, but there is no reason why he should not.
Here is our extended example:
If we now
generate a new order request, it will look like this:
In other words, we can also add other process-relevant data here. Anyone working on the request can now follow any adjustments via the texts, making it even more transparent in external communication.
Conclusion
Again, we have solved a basic functionality quite easily, although this function does not exist in Odoo in this form. At the end of the day, it is not relevant how something has been named, but only whether it works and whether you can make use of this function.
In our next article, we will take this even one step further!
Are you interested in learning more? Contact us at [email protected]
Was this article helpfull information to you?
Would you mind to leave us a review of your experiences with openfellas?