Hello !
It looks like Open Boxes can not keep half kg as a number. I try to explain better: if the unit of measure is Kg and we are stocking for example beans (the most common are 400 gr cans), and the final weight of a box of beans is 22.5 Kg, Open Boxes save that box of beans as 22 Kg or 23 Kg (no half Kg). This is a problem for reports, crucial every few months, as well as for the knowledge of the real capacity of the warehouse.
Thank you!
This is a great question, @Genna95.
Is box (22.5 kg) the smallest unit of measure that you use to distribute beans? If so, you can just make the product = “Beans, Iron, Box (22.5 kg)”, unit of measure = “Box” or “Box (22.5 kg)”. This would require someone to do some multiplication in the reporting, but it would be more accurate.
If you need to distribute in non-standardized quantities (i.e. 0.25 kg, 0.6, 1.4) then yes, that is definitely a known limitation. Because we were primarily dealing with healthcare commodities with a default unit of measure of each / piece, we made the decision to support integer instead of decimal quantities. This was a decision made to prevent unnecessary complexity and errors around floating point accuracy.
In hindsight it might not have been the correct choice. However, until today no one had complained about this limitation, so at least I can say we got away with it for 10 years. We can certainly change the data type for quantity to decimal but it’s not an easy change as it impacts every part of the system.
In the meantime, if you distribute in standardized units of measure (i.e. 22.5 kg box, 0.5 kg bag, 2.5 kg sack, etc) then there’s a potential workaround. You could set the unit of measure to the smallest unit at which the product is dispensed / sold. So if beans were distributed in 0.5 kg “scoops” or “bag” then you would create the product (SKU) as “Beans, Iron, bag (approx. 0.5 kg)” and unit of measure = “scoop (0.5 kg)” or “bag (0.5 kg)”.
If you had multiple standardized UoMs used for distribution (i.e. 22.5 kg box, 0.5 kg bag, 2.5 kg sack, etc) then each should be modeled as a separate products (SKUs). Then you could “recondition” larger items received (100 kg sack) into their standardized atomic unit of measures (22.5 kg box, 0.5 kg bags) in order to prepare for distribution.
This is a pretty disruptive change as it adds some overhead in dealing with your stock but you’ll need to live with one of these solutions until we convert the data type from integer to decimal.
Schedule a call if you’d like to discuss this in more detail and I can show you some examples.
Also if you have a developer who could work on the conversion, I could help walk that person through the code change process.
I’ve created a ticket to track this requirement and any work that might be completed against it.
Good evening,
I’m very sorry for the late reply but I’ve been on holiday from work and then, when I came back, all the work fell on me like a giant rock.
By the way, the work arounds you suggested are already used for all those types of products where decimal unit is needed (to have box instead of Kg, or tube, can, bottle). But, after almost a year, doing the report of the past year has been complicated. This because we have a very big warehouse, and open boxes is not directly linked to the distribution part of the project. Right now is used to stock and to have reports about the warehouse and the movements in/out from it. Then, at the center where tha distribution take place, is used another app easier and created just for distributions. This because the distribution project, called Free Shop is based on a point system, so the beneficiaries can choose what they want.
Moreover, the projects are based on the willingness of young volunteers, that maybe have to face for the first time a 33 pallet tir, or two, to stock. It would be too difficult for them to count the exact amount of 400gr beans can that create a 20 Kg box or so.
A workaround I was thinking at was to change the unit from Kg to gr, but this would mean to not have a clear idea of what there is in the warehouse instantly and can also make confusion (even if at the end you just have to divide by one hundred. I’d like to know what you think about this workaround.
Your help is precious and I really appreciate you’re using your time to reply me back, even if I disappeared for about ten days.
I would love to have a call with you, and I confirm that there’s a collaborator that’s a developer that can understand better than me about coding and so on.
I want also to apologize for my bad english. I’m not the best in it.
For the access, I just don’t remember my password because it’s saved on my account. So now I’m just waiting the login credentials form the field coordinator. Than I would be glad if you take a look on the work already done.
Really thank you,
Gennaro Erminio
ᐧ
Moreover, the projects are based on the willingness of young volunteers, that maybe have to face for the first time a 33 pallet tir, or two, to stock. It would be too difficult for them to count the exact amount of 400gr beans can that create a 20 Kg box or so.
So it sounds like we have two problems. One is around tracking quantities as a decimal. And the other is tracking quantities in different units of measure (can, box, pallet).
Does that sound right?
A workaround I was thinking at was to change the unit from Kg to gr, but this would mean to not have a clear idea of what there is in the warehouse instantly and can also make confusion (even if at the end you just have to divide by one hundred. I’d like to know what you think about this workaround.
There’s a feature called Product Packages which can be used to set up different UoM conversions for each product. So the default unit of measure could be grams and you could create separate product packages for each UoM you want to support (1 can = 400 grams, 1 kg = 1000 grams, 1 box = 20000 grams).
This feature is only used to display the quantities in different UoM. You can only create transactions in the system using the default UoM.
I would love to have a call with you, and I confirm that there’s a collaborator that’s a developer that can understand better than me about coding and so on.
You can schedule a call with me using the link below.
This feature (i.e. Product Packages) is only used to display the quantities in different UoM. You can only create transactions in the system using the default UoM.
As an aside, I would love to improve on this to allow transactions in different UoM. However, it’s complicated and comes with some downsides as it’s easy to ruin your data and it also potentially adds a lot of overhead when you need to convert quantities from one UoM to another just to move or allocate stock.
Therefore I’m planning to do this in two phases:
- Allow users to enter quantities in any UoM but always store the quantity value in the default UoM Essentially, we do the conversion calculation for you, but the inventory item will continue to be tracked at the default UoM.
For example, let’s say a user requests 4 cans of beans. The system would allocate 4 cans of beans to the order. Another user picks 4 cans of beans from stock. But when we create the transaction against the inventory, the system would debit 1600 grams of beans. Same would be true of receipts. User receives 1 pallet of beans. System records this inbound as 900.000 grams
- Allow user to store quantities with UoM in the database so that you can create a stock movement for 1 pallet or 10 boxes or 2 cans.
The problem here is that the inventory items need to be tracked with the specific unit of measure. So let’s say you receive 3 pallets of beans (1 pallet = 45 boxes, 1 box = 50 cans, 1 can = 400g) and put them away into 3 separate locations (1 pick location, 2 racking locations ). The pick face location should immediately be converted from pallet to boxes or cans (depending on the distribution UoM).
Let’s say you distribute in boxes. So now you have three inventory items
- 1 pallet of beans in location AA-00-02
- 1 pallet of beans in location AA-00-01
- 45 boxes of beans in location AA-00-00
An order comes in for 1 box. Easy. User pick one box from picking location, system debits 1 box from picking location
- 1 pallet of beans in location AA-00-02
- 1 pallet of beans in location AA-00-01
- 44 boxes of beans in location AA-00-00
A special order comes in for 3 cans. Ugh. Now we need to convert one of those boxes to be 50 cans in order to distribute 3 cans. System now shows the correct inventory but it requires a conversion process to be completed by the user which takes time and could lead to errors, wastage, etc.
- 1 pallet of beans in location AA-00-02
- 1 pallet of beans in location AA-00-01
- 43 boxes of beans in location AA-00-00
- 47 cans of beans in location AA-00-00
Anyway, we can (and plan to) implement this at some point. But it’s complicated and potentially error-prone for the user.