Resolving inconsistency between serialized and non-serialized inventory
Locked
Resolving inconsistency between serialized and non-serialized inventory
 
|
One of the issues that has cropped up from time to time for us is the inconsistency with how serialized and non-serialized inventory are handled. Serialized inventory availability to based primarily on the statusId on the InventoryItem entity while non-serialized inventory is based the materialized quantityOnHandTotal and availableToPromiseTotal on the InventoryItem entity (with actual details on the InventoryItemDetail entity).
From my understanding it is common knowledge that there are a number of problems around support for serialized inventory. The two things that have brought this into focus for us are (1) inventory item variance support and (2) inventory level reporting requirements. In the first case, it appears serialized inventory is not supported at all (likely partially due to not making business sense for a positive variance). In the second case, we wanted to report on historic inventory levels which would be best done by calculating levels from the InventoryItemDetail entity. The trouble with this is that serialized inventory are not properly reflected in this entity (sales appear to be reflected by not receiving via a PO). What we would like to do is talk about removing statusId completely from the inventoryItem entity and using a consistent approach regardless of the type of inventory. This implies that the QOH/ATP would be materialized on the inventoryItem (in practice it would only be 0 or 1 for serialized pieces) and the accumulation would be proper based on the InventoryItemDetail. Business logic that makes decisions based on serialized vs. non-serialized would be brought together. Current state exposes 13 inventory status items. Six of these are not in use at all including both status items that are of type "non-serialized). Of the six statuses that are currently reference in business logic and/or presentment they are in a small number of areas of the application: reservation, issuance, transfer, returns, and Oagis integration. In all of these situations current business logic exists for handling non-serialized inventory so it should be reasonable to handle serialized in the same manner. For example, availability for serialized inventory items would be achieved using the QOH / ATP numbers that are used in the logic for the non-serialized equivalents. From the data model resource book, there was a Inventory Item Status Type modeled with the intent of storing the current condition of the items (examples, good, being repaired, defective, scrap, etc) - page 85. The recommendation I would like to make is : - the set of statusItems to reflect the status that seemed to be intended in the book; that is the current state of that bucket of inventory. Understanding that if non-serialized inventory is going to take on a state that only reflects some of the items, the inventory item would be broken into two buckets. - inventory item variance would be applicable to all kinds of inventory (as per page 86). Business logic would exist to ensure that the result of a variance would not change the QOH/ATP totals for a serialized inventory item to be anything other than 0 or 1. - business logic where the current statusId is used would be collapsed to work as non-serialized inventory works now (obviously with an eye to ensuring that the business result is the same for serialized items). What I mean here is that in Oagis suggests that a serialized piece is "ON_HOLD" it would be created such that the QOH = 1 while the ATP = 0. - reasonable migration put into place to ensure backwards compatibility; not sure what this means but it likely means ensuring the materialized QOH/ATP are accurate for serialized goods based on the current statusId. It also likely means that the InventoryItemDetail records result in the same total as what is materialized on the InventoryItem table. - consider an enhancement to existing presentment based services that prevents the QOH/ATP values from being set directly. The line of thinking is that they should be materialized via ECA based on operations to the InventoryItemDetail entity. We would like to get working on this as soon as possible; if the community thinks that this makes sense for the product and we can get a contributor that would be willing to code review then we can get started. My hope is that we would end up with more consistent operation and properly working serialized inventory management. |
Re: Resolving inconsistency between serialized and non-serialized inventory
|
|
On Mar 26, 2010, at 8:46 PM, Bob Morley wrote:
> What we would like to do is talk about removing statusId completely from the > inventoryItem entity and using a consistent approach regardless of the type > of inventory. This implies that the QOH/ATP would be materialized on the > inventoryItem (in practice it would only be 0 or 1 for serialized pieces) > and the accumulation would be proper based on the InventoryItemDetail. > Business logic that makes decisions based on serialized vs. non-serialized > would be brought together. I am against removing InventoryItem.statusId: it is a good way to for example "hold" inventory (because of inspections etc...). I agree with the idea of reimplementing serialized inventory to be based (and consistent with non-serialized items) on inventoryItemDetails instead of statusId. After this change the only difference between serialized and non-serialized items will be that serialized items cannot have QOH greater than 1. Jacopo |
Re: Resolving inconsistency between serialized and non-serialized inventory
|
|
In reply to this post by Bob Morley
On Mar 26, 2010, at 8:46 PM, Bob Morley wrote: > - consider an enhancement to existing presentment based services that > prevents the QOH/ATP values from being set directly. The line of thinking > is that they should be materialized via ECA based on operations to the > InventoryItemDetail entity. Isn't this already done in this way? Jacopo |
Re: Resolving inconsistency between serialized and non-serialized inventory
|
|
There is a balance inventory items service that executes and keeps the details and materialized QOH/ATP in-line. And this service does it for both types of inventory items -- the trouble is that there is another service that executes specifically for serialized inventory items and it hardcodes the values based on the status. Something like if "AVAILABLE" set 1/1, if "DELIVERED" set 0/0, else set it to 1/0. When you stop doing this I think you notice that the InventoryItemDetail is not created for serialized inventory when products are received.
Your comment about holds is interesting -- I wonder, however, where the use case is to hold individual item pieces. For example, I would have thought if you are doing an order and want to put it on hold it effectively has the items on hold. Same with a transfer, etc. I would have thought that doing these things would do a reservation against the inventory items and reduce the ATP. To do otherwise would require breaking non-serialized inventory items into buckets each time you want to "hold" a few. But I could certainly be wrong here ... ----- Original Message ----- From: "Jacopo Cappellato" <[hidden email]> To: [hidden email] Sent: Saturday, March 27, 2010 5:15:24 AM Subject: Re: Resolving inconsistency between serialized and non-serialized inventory On Mar 26, 2010, at 8:46 PM, Bob Morley wrote: > - consider an enhancement to existing presentment based services that > prevents the QOH/ATP values from being set directly. The line of thinking > is that they should be materialized via ECA based on operations to the > InventoryItemDetail entity. Isn't this already done in this way? Jacopo |
Re: Resolving inconsistency between serialized and non-serialized inventory
|
|
On Mar 27, 2010, at 3:03 PM, Robert Morley wrote:
> There is a balance inventory items service that executes and keeps the details and materialized QOH/ATP in-line. And this service does it for both types of inventory items -- the trouble is that there is another service that executes specifically for serialized inventory items and it hardcodes the values based on the status. Something like if "AVAILABLE" set 1/1, if "DELIVERED" set 0/0, else set it to 1/0. When you stop doing this I think you notice that the InventoryItemDetail is not created for serialized inventory when products are received. > I was referring to the following eca: <!-- The InventoryItemDetail entity should never be updated/stored or deleted/removed, but we'll catch those too anyway... --> <eca entity="InventoryItemDetail" operation="create-store-remove" event="return"> <action service="updateInventoryItemFromDetail" mode="sync"/> </eca> > Your comment about holds is interesting -- I wonder, however, where the use case is to hold individual item pieces. For example you receive some items into the warehouse, and you want to "hold" them before quality control etc.. Jacopo > For example, I would have thought if you are doing an order and want to put it on hold it effectively has the items on hold. Same with a transfer, etc. I would have thought that doing these things would do a reservation against the inventory items and reduce the ATP. To do otherwise would require breaking non-serialized inventory items into buckets each time you want to "hold" a few. But I could certainly be wrong here ... > > ----- Original Message ----- > From: "Jacopo Cappellato" <[hidden email]> > To: [hidden email] > Sent: Saturday, March 27, 2010 5:15:24 AM > Subject: Re: Resolving inconsistency between serialized and non-serialized inventory > > > On Mar 26, 2010, at 8:46 PM, Bob Morley wrote: > >> - consider an enhancement to existing presentment based services that >> prevents the QOH/ATP values from being set directly. The line of thinking >> is that they should be materialized via ECA based on operations to the >> InventoryItemDetail entity. > > Isn't this already done in this way? > > Jacopo > |
Re: Resolving inconsistency between serialized and non-serialized inventory
|
|
In reply to this post by Bob Morley
Yep; when I attempted to do variance on inventory items for serialized inventory I traveled down that path to the ECA you are referring to. The trouble is that there is another ECA defined a couple of lines up ...
<eca entity="InventoryItem" operation="create-store" event="return"> <action service="updateSerializedInventoryTotals" mode="sync"/> </eca> And this one does the set the QOH/ATP based on the status (for serialized only). So after the ECA is fired and updates the InventoryItem to put them in line based on the detail, this one turns around and updates them again and potentially puts them back out of wack. As for the use case for "held" inventory items. If that is a reasonable use case then I agree 100%. What we do is use location for these situations -- for example, when a PO is received we allow the user to receive the inventory into a specific location. So if there is a "review" location that is not pickable then it may move there. Otherwise, it may move into a stockroom location that would be pickable. Putting inventory items on "hold" is perfectly reasonable. I would have to look at the code again, but I wonder how this is done for non-serialized items. Does it break the "bundle" of items (InventoryItem) into two so that one can be on "hold" while the other one can have no status? Currently, the "INV_ON_HOLD" is defined under a "SERIALIZED_INV_ITEM" parent so it is actually somewhat invalid to even set this on non-serialized items. Jacopo, if I start to make some changes based on our discussions would you be willing to to review the changes? ----- Original Message ----- From: "Jacopo Cappellato" <[hidden email]> To: [hidden email] Sent: Saturday, March 27, 2010 12:22:47 PM Subject: Re: Resolving inconsistency between serialized and non-serialized inventory On Mar 27, 2010, at 3:03 PM, Robert Morley wrote: > There is a balance inventory items service that executes and keeps the details and materialized QOH/ATP in-line. And this service does it for both types of inventory items -- the trouble is that there is another service that executes specifically for serialized inventory items and it hardcodes the values based on the status. Something like if "AVAILABLE" set 1/1, if "DELIVERED" set 0/0, else set it to 1/0. When you stop doing this I think you notice that the InventoryItemDetail is not created for serialized inventory when products are received. > I was referring to the following eca: <!-- The InventoryItemDetail entity should never be updated/stored or deleted/removed, but we'll catch those too anyway... --> <eca entity="InventoryItemDetail" operation="create-store-remove" event="return"> <action service="updateInventoryItemFromDetail" mode="sync"/> </eca> > Your comment about holds is interesting -- I wonder, however, where the use case is to hold individual item pieces. For example you receive some items into the warehouse, and you want to "hold" them before quality control etc.. Jacopo > For example, I would have thought if you are doing an order and want to put it on hold it effectively has the items on hold. Same with a transfer, etc. I would have thought that doing these things would do a reservation against the inventory items and reduce the ATP. To do otherwise would require breaking non-serialized inventory items into buckets each time you want to "hold" a few. But I could certainly be wrong here ... > > ----- Original Message ----- > From: "Jacopo Cappellato" <[hidden email]> > To: [hidden email] > Sent: Saturday, March 27, 2010 5:15:24 AM > Subject: Re: Resolving inconsistency between serialized and non-serialized inventory > > > On Mar 26, 2010, at 8:46 PM, Bob Morley wrote: > >> - consider an enhancement to existing presentment based services that >> prevents the QOH/ATP values from being set directly. The line of thinking >> is that they should be materialized via ECA based on operations to the >> InventoryItemDetail entity. > > Isn't this already done in this way? > > Jacopo > |
Re: Resolving inconsistency between serialized and non-serialized inventory
|
|
On Mar 27, 2010, at 6:51 PM, Robert Morley wrote: > Yep; when I attempted to do variance on inventory items for serialized inventory I traveled down that path to the ECA you are referring to. The trouble is that there is another ECA defined a couple of lines up ... > > <eca entity="InventoryItem" operation="create-store" event="return"> > <action service="updateSerializedInventoryTotals" mode="sync"/> > </eca> > > And this one does the set the QOH/ATP based on the status (for serialized only). So after the ECA is fired and updates the InventoryItem to put them in line based on the detail, this one turns around and updates them again and potentially puts them back out of wack. Yes, I know that serialized items are based on statusId rather than inventoryitemdetails and I agree that it would be good to reconcile them to the non-serialized logic. > > As for the use case for "held" inventory items. If that is a reasonable use case then I agree 100%. What we do is use location for these situations -- for example, when a PO is received we allow the user to receive the inventory into a specific location. So if there is a "review" location that is not pickable then it may move there. Otherwise, it may move into a stockroom location that would be pickable. > > Putting inventory items on "hold" is perfectly reasonable. I would have to look at the code again, but I wonder how this is done for non-serialized items. I don't know about serialized inventory, I know there are some OFBiz instances in production that are using on-hold status for non-serialized inventory. > Does it break the "bundle" of items (InventoryItem) into two so that one can be on "hold" while the other one can have no status? Currently, the "INV_ON_HOLD" is defined under a "SERIALIZED_INV_ITEM" parent so it is actually somewhat invalid to even set this on non-serialized items. The one I am talking about is INV_NS_ON_HOLD > > Jacopo, if I start to make some changes based on our discussions would you be willing to to review the changes? Sure. To all committers: do you agree with the plan to reimplement serialized inventory QOH/ATP to be based on InventoryItemDetail rather than InventoryItem.statusId? Kind regards, Jacopo > > ----- Original Message ----- > From: "Jacopo Cappellato" <[hidden email]> > To: [hidden email] > Sent: Saturday, March 27, 2010 12:22:47 PM > Subject: Re: Resolving inconsistency between serialized and non-serialized inventory > > On Mar 27, 2010, at 3:03 PM, Robert Morley wrote: > >> There is a balance inventory items service that executes and keeps the details and materialized QOH/ATP in-line. And this service does it for both types of inventory items -- the trouble is that there is another service that executes specifically for serialized inventory items and it hardcodes the values based on the status. Something like if "AVAILABLE" set 1/1, if "DELIVERED" set 0/0, else set it to 1/0. When you stop doing this I think you notice that the InventoryItemDetail is not created for serialized inventory when products are received. >> > > I was referring to the following eca: > > <!-- The InventoryItemDetail entity should never be updated/stored or deleted/removed, but we'll catch those too anyway... --> > <eca entity="InventoryItemDetail" operation="create-store-remove" event="return"> > <action service="updateInventoryItemFromDetail" mode="sync"/> > </eca> > >> Your comment about holds is interesting -- I wonder, however, where the use case is to hold individual item pieces. > > For example you receive some items into the warehouse, and you want to "hold" them before quality control etc.. > > Jacopo > >> For example, I would have thought if you are doing an order and want to put it on hold it effectively has the items on hold. Same with a transfer, etc. I would have thought that doing these things would do a reservation against the inventory items and reduce the ATP. To do otherwise would require breaking non-serialized inventory items into buckets each time you want to "hold" a few. But I could certainly be wrong here ... >> >> ----- Original Message ----- >> From: "Jacopo Cappellato" <[hidden email]> >> To: [hidden email] >> Sent: Saturday, March 27, 2010 5:15:24 AM >> Subject: Re: Resolving inconsistency between serialized and non-serialized inventory >> >> >> On Mar 26, 2010, at 8:46 PM, Bob Morley wrote: >> >>> - consider an enhancement to existing presentment based services that >>> prevents the QOH/ATP values from being set directly. The line of thinking >>> is that they should be materialized via ECA based on operations to the >>> InventoryItemDetail entity. >> >> Isn't this already done in this way? >> >> Jacopo >> > |
Re: Resolving inconsistency between serialized and non-serialized inventory
Administrator
|
From: "Jacopo Cappellato" <[hidden email]>
> On Mar 27, 2010, at 6:51 PM, Robert Morley wrote: > >> Yep; when I attempted to do variance on inventory items for serialized inventory I traveled down that path to the ECA you are >> referring to. The trouble is that there is another ECA defined a couple of lines up ... >> >> <eca entity="InventoryItem" operation="create-store" event="return"> >> <action service="updateSerializedInventoryTotals" mode="sync"/> >> </eca> >> >> And this one does the set the QOH/ATP based on the status (for serialized only). So after the ECA is fired and updates the >> InventoryItem to put them in line based on the detail, this one turns around and updates them again and potentially puts them >> back out of wack. > > Yes, I know that serialized items are based on statusId rather than inventoryitemdetails and I agree that it would be good to > reconcile them to the non-serialized logic. > >> >> As for the use case for "held" inventory items. If that is a reasonable use case then I agree 100%. What we do is use location >> for these situations -- for example, when a PO is received we allow the user to receive the inventory into a specific location. >> So if there is a "review" location that is not pickable then it may move there. Otherwise, it may move into a stockroom location >> that would be pickable. >> >> Putting inventory items on "hold" is perfectly reasonable. I would have to look at the code again, but I wonder how this is done >> for non-serialized items. > > I don't know about serialized inventory, I know there are some OFBiz instances in production that are using on-hold status for > non-serialized inventory. > >> Does it break the "bundle" of items (InventoryItem) into two so that one can be on "hold" while the other one can have no >> status? Currently, the "INV_ON_HOLD" is defined under a "SERIALIZED_INV_ITEM" parent so it is actually somewhat invalid to even >> set this on non-serialized items. > > The one I am talking about is INV_NS_ON_HOLD > >> >> Jacopo, if I start to make some changes based on our discussions would you be willing to to review the changes? > > Sure. > To all committers: do you agree with the plan to reimplement serialized inventory QOH/ATP to be based on InventoryItemDetail > rather than InventoryItem.statusId? Just to be sure to completly understand: does anybody knows why it's done with InventoryItem.statusId for the moment? Thanks Jacques > Kind regards, > > Jacopo > > >> >> ----- Original Message ----- >> From: "Jacopo Cappellato" <[hidden email]> >> To: [hidden email] >> Sent: Saturday, March 27, 2010 12:22:47 PM >> Subject: Re: Resolving inconsistency between serialized and non-serialized inventory >> >> On Mar 27, 2010, at 3:03 PM, Robert Morley wrote: >> >>> There is a balance inventory items service that executes and keeps the details and materialized QOH/ATP in-line. And this >>> service does it for both types of inventory items -- the trouble is that there is another service that executes specifically for >>> serialized inventory items and it hardcodes the values based on the status. Something like if "AVAILABLE" set 1/1, if >>> "DELIVERED" set 0/0, else set it to 1/0. When you stop doing this I think you notice that the InventoryItemDetail is not >>> created for serialized inventory when products are received. >>> >> >> I was referring to the following eca: >> >> <!-- The InventoryItemDetail entity should never be updated/stored or deleted/removed, but we'll catch those too anyway... --> >> <eca entity="InventoryItemDetail" operation="create-store-remove" event="return"> >> <action service="updateInventoryItemFromDetail" mode="sync"/> >> </eca> >> >>> Your comment about holds is interesting -- I wonder, however, where the use case is to hold individual item pieces. >> >> For example you receive some items into the warehouse, and you want to "hold" them before quality control etc.. >> >> Jacopo >> >>> For example, I would have thought if you are doing an order and want to put it on hold it effectively has the items on hold. >>> Same with a transfer, etc. I would have thought that doing these things would do a reservation against the inventory items and >>> reduce the ATP. To do otherwise would require breaking non-serialized inventory items into buckets each time you want to "hold" >>> a few. But I could certainly be wrong here ... >>> >>> ----- Original Message ----- >>> From: "Jacopo Cappellato" <[hidden email]> >>> To: [hidden email] >>> Sent: Saturday, March 27, 2010 5:15:24 AM >>> Subject: Re: Resolving inconsistency between serialized and non-serialized inventory >>> >>> >>> On Mar 26, 2010, at 8:46 PM, Bob Morley wrote: >>> >>>> - consider an enhancement to existing presentment based services that >>>> prevents the QOH/ATP values from being set directly. The line of thinking >>>> is that they should be materialized via ECA based on operations to the >>>> InventoryItemDetail entity. >>> >>> Isn't this already done in this way? >>> >>> Jacopo >>> >> > > |
Re: Resolving inconsistency between serialized and non-serialized inventory
|
|
Thanks all for your valuable comments,
Here is the ticket for the above discussion OFBIZ-9475 <https://issues.apache.org/jira/browse/OFBIZ-9475> Thanks & Regards Deepak Dixit On Sun, Mar 28, 2010 at 7:20 PM, Jacques Le Roux < [hidden email]> wrote: > From: "Jacopo Cappellato" <[hidden email]> > >> On Mar 27, 2010, at 6:51 PM, Robert Morley wrote: >> >> Yep; when I attempted to do variance on inventory items for serialized >>> inventory I traveled down that path to the ECA you are referring to. The >>> trouble is that there is another ECA defined a couple of lines up ... >>> >>> <eca entity="InventoryItem" operation="create-store" event="return"> >>> <action service="updateSerializedInventoryTotals" mode="sync"/> >>> </eca> >>> >>> And this one does the set the QOH/ATP based on the status (for >>> serialized only). So after the ECA is fired and updates the InventoryItem >>> to put them in line based on the detail, this one turns around and updates >>> them again and potentially puts them back out of wack. >>> >> >> Yes, I know that serialized items are based on statusId rather than >> inventoryitemdetails and I agree that it would be good to reconcile them to >> the non-serialized logic. >> >> >>> As for the use case for "held" inventory items. If that is a reasonable >>> use case then I agree 100%. What we do is use location for these >>> situations -- for example, when a PO is received we allow the user to >>> receive the inventory into a specific location. So if there is a "review" >>> location that is not pickable then it may move there. Otherwise, it may >>> move into a stockroom location that would be pickable. >>> >>> Putting inventory items on "hold" is perfectly reasonable. I would have >>> to look at the code again, but I wonder how this is done for non-serialized >>> items. >>> >> >> I don't know about serialized inventory, I know there are some OFBiz >> instances in production that are using on-hold status for non-serialized >> inventory. >> >> Does it break the "bundle" of items (InventoryItem) into two so that one >>> can be on "hold" while the other one can have no status? Currently, the >>> "INV_ON_HOLD" is defined under a "SERIALIZED_INV_ITEM" parent so it is >>> actually somewhat invalid to even set this on non-serialized items. >>> >> >> The one I am talking about is INV_NS_ON_HOLD >> >> >>> Jacopo, if I start to make some changes based on our discussions would >>> you be willing to to review the changes? >>> >> >> Sure. >> To all committers: do you agree with the plan to reimplement serialized >> inventory QOH/ATP to be based on InventoryItemDetail rather than >> InventoryItem.statusId? >> > > Just to be sure to completly understand: does anybody knows why it's done > with InventoryItem.statusId for the moment? > > Thanks > > Jacques > > > Kind regards, >> >> Jacopo >> >> >> >>> ----- Original Message ----- >>> From: "Jacopo Cappellato" <[hidden email]> >>> To: [hidden email] >>> Sent: Saturday, March 27, 2010 12:22:47 PM >>> Subject: Re: Resolving inconsistency between serialized and >>> non-serialized inventory >>> >>> On Mar 27, 2010, at 3:03 PM, Robert Morley wrote: >>> >>> There is a balance inventory items service that executes and keeps the >>>> details and materialized QOH/ATP in-line. And this service does it for >>>> both types of inventory items -- the trouble is that there is another >>>> service that executes specifically for serialized inventory items and it >>>> hardcodes the values based on the status. Something like if "AVAILABLE" >>>> set 1/1, if "DELIVERED" set 0/0, else set it to 1/0. When you stop doing >>>> this I think you notice that the InventoryItemDetail is not created for >>>> serialized inventory when products are received. >>>> >>>> >>> I was referring to the following eca: >>> >>> <!-- The InventoryItemDetail entity should never be updated/stored or >>> deleted/removed, but we'll catch those too anyway... --> >>> <eca entity="InventoryItemDetail" operation="create-store-remove" >>> event="return"> >>> <action service="updateInventoryItemFromDetail" mode="sync"/> >>> </eca> >>> >>> Your comment about holds is interesting -- I wonder, however, where the >>>> use case is to hold individual item pieces. >>>> >>> >>> For example you receive some items into the warehouse, and you want to >>> "hold" them before quality control etc.. >>> >>> Jacopo >>> >>> For example, I would have thought if you are doing an order and want to >>>> put it on hold it effectively has the items on hold. Same with a transfer, >>>> etc. I would have thought that doing these things would do a reservation >>>> against the inventory items and reduce the ATP. To do otherwise would >>>> require breaking non-serialized inventory items into buckets each time you >>>> want to "hold" a few. But I could certainly be wrong here ... >>>> >>>> ----- Original Message ----- >>>> From: "Jacopo Cappellato" <[hidden email]> >>>> To: [hidden email] >>>> Sent: Saturday, March 27, 2010 5:15:24 AM >>>> Subject: Re: Resolving inconsistency between serialized and >>>> non-serialized inventory >>>> >>>> >>>> On Mar 26, 2010, at 8:46 PM, Bob Morley wrote: >>>> >>>> - consider an enhancement to existing presentment based services that >>>>> prevents the QOH/ATP values from being set directly. The line of >>>>> thinking >>>>> is that they should be materialized via ECA based on operations to the >>>>> InventoryItemDetail entity. >>>>> >>>> >>>> Isn't this already done in this way? >>>> >>>> Jacopo >>>> >>>> >>> >> >> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |