We are planning to use adempiere as base for a quite huge erp project.
As the most important part we are in Manufacturing UOM Conversion and Inventory UOMs are very important for us.
This is very limiting at the moment in ADempiere.
Thus we decided to start the specification and a sponsored development in this area
I created the following wiki site and started to list our requirements identified in a first brainstorming
This is by no means a complete specification, just a first starting point.
As this will touch the core of the system and nearly every mask and a lot of tables in the system it will not be an easy task.
And it will not be easy to say how much effort this would be ?
My questions now are:
Is this initiative interesting for the community - will it be supported ?
Who is interested in helping to write the detailed specification ?
Who would be interested and capable in developing this (trunkable) ?
What method could we use to find out how much effort this is resp. the amout of money which needs to be sponsored ?
Who is willing to sponsor this enhancement as well ?
There are some open questions on the sponsored development policies.
But i'll add the open points on this later...
Any feedback welcome
Kind regards
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are also in need of some of the enhancement outline in your spec for our current project ( at design phase now ), will see how we can collaborate on this in the coming month ( very busy working with customer requirements now ).
Regards,
Low
P.S FYI, I submitted the Add C_Uom_ID to the M_ProductPrice FR when prototyping my current project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your commitment to this.
It has been silent around this in the last weeks due to my holidays.
We are still fully committed to this topic and are going to bring the spec forward in the next week.
kind regards
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Generality when you convert a product to other UOM, it need some process to transformation. In manufacturing you can create a Multilevel BOM, it can be contain some sub-assembly and this generality are to transform the Original UOM, For this process is necessary create a planning of material and resource.
Thanks a lot for your feedback.
I think we are talking about slightly different things.
We understand that in a production process the product is changed in each process step.
IN:
1,5 liters of product a
1,5 liters of product b
OUT:
6 "0,5 liter cans" of product c (with different costs for sure)
We know that this can be done with a multilevel BOM and Libero
-> What we suggest is more than one Inventory UOM per Material:
e.g.:
Our raw material is paper.
Our leading UOM (and Costing UOM) is "Kilograms".
But in the further process for planning and production it's very important to know the Value of "Sheets" on Hand.
Thus "Sheets" would be our Second Inventory UOM.
There has to be conversion rate between between Kilograms and Sheets.
But in the worst case this could be on Lot level (suggested in 4.1)
If we only store the conversion rates it would be very time consuming to caculate the inventory in "Sheets".
That's the reason why we suggest more than one inventory uom.
This means that all material transactions have to be done in two UOMs for this product.
Fully understanding that this (and the other things proposed) are not easy to be implemented.
btw.: many erp systems support multiple inventory UOMs product
any further feedback welcome
kind regards
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just want to add one more example:
Customers of meat producers usually make order in case:
2 Cases of beef meat.
But at the end pay per kilogram.
In this case there is not conversion rate and must store both UOM.
I had such requirement before 2-3 months.
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I would even say you have an conversion rate,
>but in your case on material receipt level.
They do not know how many kilograms will be in case.
They produce beef meat till they fill the case but exact value of kilograms is unknown prior production.
Example which i gave is complicated as in Sales Order meat producer must put 2 Cases beef meat(kilograms is just a guess, they could know average kilograms per case), but exact value of kilograms in known when Shipment is made.
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I would even say you have an conversion rate,
>but in your case on material receipt level.
yes you are right.
Conversion rate is known at Receipt or Shipment level.
But it is not fixed conversion rate, it changes each time Receipt or Shipment is made.
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let there be the conversions based on the transactions.
1. We should have a base UOM (like the way it is presently in the system), which is mandatory to be defined.
2. UOM window (and UOM conversion tab) may work the way they are working right now with small exception that the check that multiply rate should be always greater 1 shouldn't be their.
3. Define following UOMs for product in new a tab (may be called UOM)
a. Stocking UOM (selection), Conversion rate with base UOM (enter able, non mandatory)
b. Purchasing UOM (Selection), Conversion rate with base UOM (enter able, non mandatory)
c. Sales UOM (selection) Conversion rate with base UOM (enter able, non mandatory)
4. With every entry in this tab, their will be corresponding entry in UOM window (UOM Conversion tab) too.
Say for a product wine A, I define Stocking UOM (crates) and say that its conversion rate is 24 with base UOM (each), it will result in one entry in UOM window under UOM "each" for product "wine A" with multiply rate as 24 and conversion to UOM as "crate".
Similarly, if I am defining other UOMs for each product.
5. So user need not to go to UOM window again and again to define conversion rates but still will have flexibility to choosing UOMs. Each UOM should reflect by default in respective transactions and reports but evaluation to be done in base UOM.
6. This seems to be quite an easy thing but real twist is, user can also leave these conversion rate blank. In that case he will be prompted to give conversion rate at transactions (because conversion rate would be dynamic in those cases).
Ex:-
Say I am a trader of stone. I import slabs in different UOMs (inches) keep them in inventory in different UOM (SFT) and sell them as single slab. And at time of selling I define whats the conversion rate of each slab in terms of SFT.
Well friends most of you have already discussed similar solutions, I am just trying to be specific how we can do it in these lines. I am not sure how much this suggestion will solve the whole issue but I kept things within the boundaries of present functionality.
Will like to join this team for modifications in UOM.
Kind Regards'
Sandeep.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
re: multiple UOM; inventory, Sales & Purchase (point3)
Yeah I said this a long time ago in another discussion...
BUT, I think the suggestion to be able add UoM to the pricelist is a better one.
Then, any number of UoM could be used. Inventory UoM is what we have now .. if the pricelists is a sales pricelist then the UoM used would be the Sales UoM otherwise purchase UoM!? There can be as many Sales & Purchases pricelists as needed and hence as many Sales & purchase UoM!
I do think it would still be a good idea to add a UoM tab to the product window.
At the moment the UoM conversion must be explicitly defined for each product. Which can be a bit of a pain ... defining there are 1000g to a Kilogram for each product is a bit annoying to say the least. And it's not immediately obvious that this must be done. We could I think leave the current UoM window as it is ... but allow the view, create & update of those records from the product window via this new tab... that would I think make it more obvious that each product must define its own conversion rate (which I think is your point 4?) ... we might be able to make it easier too by defaulting the basic conversion rate when entering this information.
re: check on conversion rate (point2)
There is a basic rule in adempiere that the inventory UoM *must* be the smallest UoM for this product. All Storage records are in this UoM. Enforcing this is the reason behind the check you mention and ensure there can be no remainders left in Storage records due to conversion. This was discussed in a tracker some while ago.
Your stone & Trifon's meat examples do show there are some unusual scenarios that must be accounted for. Having never worked on projects in these areas the answer is not immediately obvious to me.
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well can you give me the link to the tracker where it was discussed why base UOM should be smallest one. I would like to go through that (as I have been removing this check since some time and want to be sure that I haven't done any blunder). And yes my reason for removing this check (during implementations) has been to remove this restriction on user to store product in smallest UOM in inventory.
Regarding stone and meat example discussed above, I think there are number of such scenarios available in industry where user is required to define UOM conversion at the time of transactions (which may be production, receipt or shipment).
Let me quote few more examples how UOM conversions varies in different industry scenarios:
1. Textile Industry :
Cotton is procured in various states in various UOM's like Mond, Candy, Bales etc. There is a conversion factor between any of these and Kgs is different. Also for different vendors, this could differ. The rate of Cotton is specified in per kg qty but ordering happens only for mond, candy etc . Over and above this, Cotton is succeptible to moisture collection. Hence the weight of the Cotton changes during transit or Storage. The price per kg is fixed at the time of placing a PO, but payment to the vendor is made on the basis of weight received less moisture weight.
2. For jewelery a portion analysis concept (like used in catering / hotel industry) is used. The conversion factor is important factor although. All items are classified, there weight, karat etc. are defined and then every day rates are fed at the start of the day or when ever. Thats how the cost is evolved.
3. Like in Dairy Ind. Milk price depends on FAT & SNF % in the order. So the prices depends on the value of FAT & SNF% a the time of transactions and UOM conversion rate too cannot be defined as static for such a scenario.
Yes these are industry specific scenarios and it might not be appropriate to consider all of them while finalizing specifications for generic functionalities. But yes one thing which is common in them is UOM conversion during the time of transactions, which is currently not supported in Adempiere.
Lastly, I would also say that UOM in price list is a good option in order to have multiple UOM flexibility but it may be confusing for end user. Well I am not sure about it. You guys are much more expert in commenting about that.
Regards'
Sandeep.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
re: other industry examples
indeed there are many. I guess I shouldn't have said *unusual*. Just in case there is any misunerstanding - I really only meant my experience has mostly been in hi-tech electronic firms were the quanties are all nice and standard :) So having no experience of these other industries I was not in a position to suggest a solution... at least not based on previous experience.
I can say the current UoM functionality is very *basic*. Adding a UoM to pricelist would, I imagine, be a relatively small change that would make a nice extension to the functionality... resulting in a nice userability return on a small risk change. Making the UoM functionality truly universal to enable it to handle the scenarios you provided would be a much bigger, riskier, undertaken. Not that it's not required or should not be done! But it requires a lot more thinking and planning I guess is my point. I will help in anyway I can.
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes these are industry specific scenarios and it might not be appropriate to consider all of them while finalizing specifications for generic functionalities. But yes one thing which is common in them is ***UOM conversion rate*** during the time of transactions, which is currently not supported in Adempiere.
Regards'
Sandeep.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
We are planning to use adempiere as base for a quite huge erp project.
As the most important part we are in Manufacturing UOM Conversion and Inventory UOMs are very important for us.
This is very limiting at the moment in ADempiere.
Thus we decided to start the specification and a sponsored development in this area
I created the following wiki site and started to list our requirements identified in a first brainstorming
http://www.adempiere.com/wiki/index.php/Sponsored_Development:_Inventory_UOMs_and_UOM_Conversion_Enhancements
This is by no means a complete specification, just a first starting point.
As this will touch the core of the system and nearly every mask and a lot of tables in the system it will not be an easy task.
And it will not be easy to say how much effort this would be ?
My questions now are:
Is this initiative interesting for the community - will it be supported ?
Who is interested in helping to write the detailed specification ?
Who would be interested and capable in developing this (trunkable) ?
What method could we use to find out how much effort this is resp. the amout of money which needs to be sponsored ?
Who is willing to sponsor this enhancement as well ?
There are some open questions on the sponsored development policies.
But i'll add the open points on this later...
Any feedback welcome
Kind regards
Chris
Hi Chris,
We are also in need of some of the enhancement outline in your spec for our current project ( at design phase now ), will see how we can collaborate on this in the coming month ( very busy working with customer requirements now ).
Regards,
Low
P.S FYI, I submitted the Add C_Uom_ID to the M_ProductPrice FR when prototyping my current project.
Hi Low,
Thanks for your feedback.
Can you shortly outline what the overlapping parts are ?
One is a different UOM for the priclists - right ?
kind regards
Christian
hi Chris,
I'm interested in this part of enhancement. Actually my co. is facing this single UOM limitation in Compiere. I have added some comment in wiki page.
Please count me in this thread to draft out the spec.
beta
Hi beta,
Thanks for your commitment to this.
It has been silent around this in the last weeks due to my holidays.
We are still fully committed to this topic and are going to bring the spec forward in the next week.
kind regards
Chris
>>first/Master UOM:
>>Storage or Stock Keeping Unit (SKU) of a Product.
>>Leading UOM for this product (Costing)
>>e.g. liters of beer
>>2nd/3rd UOM:
>>e.g. additional Inventory UOM
>>e.g. beer cans
>>e.g. Replenishment UOM - MRP relevant
>>e.g. cartons of beer cans)
This is crazy idea for the product at different process....
in production line the product before packing
storage at big pool liter...
after packing with cans ,,we need another product number and add-cost ...
after pakcing with cartons ,,we need another product number too...
but three product must in same parent product number.
Hi Chris!
I review your propose, I have some question.
Generality when you convert a product to other UOM, it need some process to transformation. In manufacturing you can create a Multilevel BOM, it can be contain some sub-assembly and this generality are to transform the Original UOM, For this process is necessary create a planning of material and resource.
http://en.wikipedia.org/wiki/Modular_BOM
no I can convert a UOM to other UOM using Libero and Manufacturing Order, My question is What is the different with you are propose?
Victor Perez
CEO
www.e-evolution.com
Hi Albert,
Hi Victor,
Thanks a lot for your feedback.
I think we are talking about slightly different things.
We understand that in a production process the product is changed in each process step.
IN:
1,5 liters of product a
1,5 liters of product b
OUT:
6 "0,5 liter cans" of product c (with different costs for sure)
We know that this can be done with a multilevel BOM and Libero
-> What we suggest is more than one Inventory UOM per Material:
e.g.:
Our raw material is paper.
Our leading UOM (and Costing UOM) is "Kilograms".
But in the further process for planning and production it's very important to know the Value of "Sheets" on Hand.
Thus "Sheets" would be our Second Inventory UOM.
There has to be conversion rate between between Kilograms and Sheets.
But in the worst case this could be on Lot level (suggested in 4.1)
If we only store the conversion rates it would be very time consuming to caculate the inventory in "Sheets".
That's the reason why we suggest more than one inventory uom.
This means that all material transactions have to be done in two UOMs for this product.
Fully understanding that this (and the other things proposed) are not easy to be implemented.
btw.: many erp systems support multiple inventory UOMs product
any further feedback welcome
kind regards
Chris
Hi Chris,
I just want to add one more example:
Customers of meat producers usually make order in case:
2 Cases of beef meat.
But at the end pay per kilogram.
In this case there is not conversion rate and must store both UOM.
I had such requirement before 2-3 months.
Kind regards,
Trifon
Hi Trifon,
Thanks for the example.
I would even say you have an conversion rate,
but in your case on material receipt level.
What do you think ?
kind regards
Chris
Hi Chris,
>I would even say you have an conversion rate,
>but in your case on material receipt level.
They do not know how many kilograms will be in case.
They produce beef meat till they fill the case but exact value of kilograms is unknown prior production.
Example which i gave is complicated as in Sales Order meat producer must put 2 Cases beef meat(kilograms is just a guess, they could know average kilograms per case), but exact value of kilograms in known when Shipment is made.
Kind regards,
Trifon
Hi Chris,
>I would even say you have an conversion rate,
>but in your case on material receipt level.
yes you are right.
Conversion rate is known at Receipt or Shipment level.
But it is not fixed conversion rate, it changes each time Receipt or Shipment is made.
Kind regards,
Trifon
Suggestion for Mulit UOM:
Let there be the conversions based on the transactions.
1. We should have a base UOM (like the way it is presently in the system), which is mandatory to be defined.
2. UOM window (and UOM conversion tab) may work the way they are working right now with small exception that the check that multiply rate should be always greater 1 shouldn't be their.
3. Define following UOMs for product in new a tab (may be called UOM)
a. Stocking UOM (selection), Conversion rate with base UOM (enter able, non mandatory)
b. Purchasing UOM (Selection), Conversion rate with base UOM (enter able, non mandatory)
c. Sales UOM (selection) Conversion rate with base UOM (enter able, non mandatory)
4. With every entry in this tab, their will be corresponding entry in UOM window (UOM Conversion tab) too.
Say for a product wine A, I define Stocking UOM (crates) and say that its conversion rate is 24 with base UOM (each), it will result in one entry in UOM window under UOM "each" for product "wine A" with multiply rate as 24 and conversion to UOM as "crate".
Similarly, if I am defining other UOMs for each product.
5. So user need not to go to UOM window again and again to define conversion rates but still will have flexibility to choosing UOMs. Each UOM should reflect by default in respective transactions and reports but evaluation to be done in base UOM.
6. This seems to be quite an easy thing but real twist is, user can also leave these conversion rate blank. In that case he will be prompted to give conversion rate at transactions (because conversion rate would be dynamic in those cases).
Ex:-
Say I am a trader of stone. I import slabs in different UOMs (inches) keep them in inventory in different UOM (SFT) and sell them as single slab. And at time of selling I define whats the conversion rate of each slab in terms of SFT.
Well friends most of you have already discussed similar solutions, I am just trying to be specific how we can do it in these lines. I am not sure how much this suggestion will solve the whole issue but I kept things within the boundaries of present functionality.
Will like to join this team for modifications in UOM.
Kind Regards'
Sandeep.
Hi all
re: multiple UOM; inventory, Sales & Purchase (point3)
Yeah I said this a long time ago in another discussion...
BUT, I think the suggestion to be able add UoM to the pricelist is a better one.
Then, any number of UoM could be used. Inventory UoM is what we have now .. if the pricelists is a sales pricelist then the UoM used would be the Sales UoM otherwise purchase UoM!? There can be as many Sales & Purchases pricelists as needed and hence as many Sales & purchase UoM!
I do think it would still be a good idea to add a UoM tab to the product window.
At the moment the UoM conversion must be explicitly defined for each product. Which can be a bit of a pain ... defining there are 1000g to a Kilogram for each product is a bit annoying to say the least. And it's not immediately obvious that this must be done. We could I think leave the current UoM window as it is ... but allow the view, create & update of those records from the product window via this new tab... that would I think make it more obvious that each product must define its own conversion rate (which I think is your point 4?) ... we might be able to make it easier too by defaulting the basic conversion rate when entering this information.
re: check on conversion rate (point2)
There is a basic rule in adempiere that the inventory UoM *must* be the smallest UoM for this product. All Storage records are in this UoM. Enforcing this is the reason behind the check you mention and ensure there can be no remainders left in Storage records due to conversion. This was discussed in a tracker some while ago.
Your stone & Trifon's meat examples do show there are some unusual scenarios that must be accounted for. Having never worked on projects in these areas the answer is not immediately obvious to me.
colin
Sorry .... forget to write about Pricing UOM.
Either to have UOM selected for each price list or define additional Pricing UOM just like others.
I think second option is better because even if price changes with UOM that can be modified during transaction.
But yes it will have some accounting consequences which may not be required. So still need some heads to define specifications in detail.
Kind Regards'
Sandeep.
Hi Colin,
Thanks for the expert advice.
Well can you give me the link to the tracker where it was discussed why base UOM should be smallest one. I would like to go through that (as I have been removing this check since some time and want to be sure that I haven't done any blunder). And yes my reason for removing this check (during implementations) has been to remove this restriction on user to store product in smallest UOM in inventory.
Regarding stone and meat example discussed above, I think there are number of such scenarios available in industry where user is required to define UOM conversion at the time of transactions (which may be production, receipt or shipment).
Let me quote few more examples how UOM conversions varies in different industry scenarios:
1. Textile Industry :
Cotton is procured in various states in various UOM's like Mond, Candy, Bales etc. There is a conversion factor between any of these and Kgs is different. Also for different vendors, this could differ. The rate of Cotton is specified in per kg qty but ordering happens only for mond, candy etc . Over and above this, Cotton is succeptible to moisture collection. Hence the weight of the Cotton changes during transit or Storage. The price per kg is fixed at the time of placing a PO, but payment to the vendor is made on the basis of weight received less moisture weight.
2. For jewelery a portion analysis concept (like used in catering / hotel industry) is used. The conversion factor is important factor although. All items are classified, there weight, karat etc. are defined and then every day rates are fed at the start of the day or when ever. Thats how the cost is evolved.
3. Like in Dairy Ind. Milk price depends on FAT & SNF % in the order. So the prices depends on the value of FAT & SNF% a the time of transactions and UOM conversion rate too cannot be defined as static for such a scenario.
Yes these are industry specific scenarios and it might not be appropriate to consider all of them while finalizing specifications for generic functionalities. But yes one thing which is common in them is UOM conversion during the time of transactions, which is currently not supported in Adempiere.
Lastly, I would also say that UOM in price list is a good option in order to have multiple UOM flexibility but it may be confusing for end user. Well I am not sure about it. You guys are much more expert in commenting about that.
Regards'
Sandeep.
Hi Sandeep
>> can you give me the link to the tracker where it was discussed why base UOM should be smallest one
I think this was the discussion I was thinking of.. but there might be others!
http://sourceforge.net/tracker/index.php?func=detail&aid=1689521&group_id=176962&atid=879332
re: other industry examples
indeed there are many. I guess I shouldn't have said *unusual*. Just in case there is any misunerstanding - I really only meant my experience has mostly been in hi-tech electronic firms were the quanties are all nice and standard :) So having no experience of these other industries I was not in a position to suggest a solution... at least not based on previous experience.
I can say the current UoM functionality is very *basic*. Adding a UoM to pricelist would, I imagine, be a relatively small change that would make a nice extension to the functionality... resulting in a nice userability return on a small risk change. Making the UoM functionality truly universal to enable it to handle the scenarios you provided would be a much bigger, riskier, undertaken. Not that it's not required or should not be done! But it requires a lot more thinking and planning I guess is my point. I will help in anyway I can.
colin
I meant conversion rate in this para.
Yes these are industry specific scenarios and it might not be appropriate to consider all of them while finalizing specifications for generic functionalities. But yes one thing which is common in them is ***UOM conversion rate*** during the time of transactions, which is currently not supported in Adempiere.
Regards'
Sandeep.