Dev - comments please - proposed Inventory Valuation implementation

[Si Chen-2]

Hi everybody.

We're in the process of a major overhaul of some key parts of the
Financials application before making an official release.  Part of it is
re-factoring the way inventory valuation is done so that it will support
manufacturing, returns, purchases equally under LIFO, FIFO, and Average
Cost.

I've written out the proposed scheme for doing this.  Please download
and read it:
http://www.opensourcestrategies.com/ofbiz/Inventory_Valuation.pdf and
give me your feedback.  If your organization has an accountant, CPA, or
CFO, it would be nice to get his/her feedback as well.  Feel free to
write your comments on the list.

Thanks!

Si
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Si,

I read over this and everything looks pretty good. There are couple  
of things that stuck out to me that should be watched for carefully.

1. Currency conversions are tricky. Local tables can be used but only  
as an approximation unless you are somehow using the same information  
as your bank. For inventory valuation this may not be such a big deal  
though, but would be good to find out about from an accountant.

2. I'm not sure if the allocation order configured on the  
ProductStore can be reliably used for financial purposes. It is  
really meant for inventory management purposes and is LIFO/FIFO for  
received date or expire date, which may not be what the enterprise  
needs/wants to use for financial valuation. Again something that  
should be checked with an accountant. I think some other scheme will  
be needed here.

All in all a great document, and for anyone who is wondering about  
all of these data structures and concepts it's very informative.

-David


On Feb 24, 2006, at 10:45 AM, Si Chen wrote:

> Hi everybody.
>
> We're in the process of a major overhaul of some key parts of the
> Financials application before making an official release.  Part of  
> it is
> re-factoring the way inventory valuation is done so that it will  
> support
> manufacturing, returns, purchases equally under LIFO, FIFO, and  
> Average
> Cost.
>
> I've written out the proposed scheme for doing this.  Please download
> and read it:
> http://www.opensourcestrategies.com/ofbiz/Inventory_Valuation.pdf and
> give me your feedback.  If your organization has an accountant,  
> CPA, or
> CFO, it would be nice to get his/her feedback as well.  Feel free to
> write your comments on the list.
>
> Thanks!
>
> Si
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Hi Si,

your document looks excellent.

Here are some comments:

1) you state that inventory items produced by a manufacturing order
(WorkEffort) should be grouped together in a (special type of)
ShipmentReceipt; I don't think this is necessary: inventoty items
produced by a manufacturing order are already associated to the
manufacturing order thru the WorkEffortInventoryProduced entity.

2) in the InventoryItem entity there is a field called partyId: can this
be used to store the owner party id?

3) are we sure that we want to set currency uom ids at InventoryItem
level? Maybe we can simply add the currencyUomId field in the facility
entity. For inventory transfers between facilities with different
currency uoms we can perform a conversion for inventory items costs.

Jacopo


Si Chen wrote:

> Hi everybody.
>
> We're in the process of a major overhaul of some key parts of the
> Financials application before making an official release.  Part of it is
> re-factoring the way inventory valuation is done so that it will support
> manufacturing, returns, purchases equally under LIFO, FIFO, and Average
> Cost.
>
> I've written out the proposed scheme for doing this.  Please download
> and read it:
> http://www.opensourcestrategies.com/ofbiz/Inventory_Valuation.pdf and
> give me your feedback.  If your organization has an accountant, CPA, or
> CFO, it would be nice to get his/her feedback as well.  Feel free to
> write your comments on the list.
>
> Thanks!
>
> Si
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

David,

Thanks very much for reading this.  I agree with you on both points: the
currency conversion is just an approximation, and we'll really need
someone who uses LIFO/FIFO to verify that this is a good way to do it.

Si


David E. Jones wrote:

>Si,
>
>I read over this and everything looks pretty good. There are couple  
>of things that stuck out to me that should be watched for carefully.
>
>1. Currency conversions are tricky. Local tables can be used but only  
>as an approximation unless you are somehow using the same information  
>as your bank. For inventory valuation this may not be such a big deal  
>though, but would be good to find out about from an accountant.
>
>2. I'm not sure if the allocation order configured on the  
>ProductStore can be reliably used for financial purposes. It is  
>really meant for inventory management purposes and is LIFO/FIFO for  
>received date or expire date, which may not be what the enterprise  
>needs/wants to use for financial valuation. Again something that  
>should be checked with an accountant. I think some other scheme will  
>be needed here.
>
>All in all a great document, and for anyone who is wondering about  
>all of these data structures and concepts it's very informative.
>
>-David
>
>
>On Feb 24, 2006, at 10:45 AM, Si Chen wrote:
>
>  
>
>>Hi everybody.
>>
>>We're in the process of a major overhaul of some key parts of the
>>Financials application before making an official release.  Part of  
>>it is
>>re-factoring the way inventory valuation is done so that it will  
>>support
>>manufacturing, returns, purchases equally under LIFO, FIFO, and  
>>Average
>>Cost.
>>
>>I've written out the proposed scheme for doing this.  Please download
>>and read it:
>>http://www.opensourcestrategies.com/ofbiz/Inventory_Valuation.pdf and
>>give me your feedback.  If your organization has an accountant,  
>>CPA, or
>>CFO, it would be nice to get his/her feedback as well.  Feel free to
>>write your comments on the list.
>>
>>Thanks!
>>
>>Si
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>    
>>
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Jacopo,

Thank you for looking through this.  Here are my thoughts:

1.  Inventory items from manufacturing don't have to be grouped into a
ShipmentReceipt, but it would make the code in Financials a lot easier.  
:)  My thought was that any receipt of inventory, whether from a
customer return, a vendor purchase order, or a manufacturing process,
could be grouped into a ShipmentReceipt.  Then, once a ShipmentReceipt
is marked "Received," ledger posting takes place.

Another possible advantage could be an added layer of abstraction: could
a ShipmentReceipt be used to record when the warehouse actually checked
and confirmed the manufactured goods?

Of course, if you really don't want to do it that way--that's ok too.  
We could make a post inventory items to ledger routine which gets a list
of items and posts them.  Then the manufacturing posting could get the
items in a separate way than the shipment receipt one.

2.  I didn't know about InventoryItem.partyId and don't know what it's
used for.  Technically, though, there may need to be two partyId fields
on an inventory item to denote (a) who owns the inventory and (b) who
it's held for.  For example, it could say item A is owned by Company and
held (or reserved) for DemoCustomer.  In distribution industries setting
inventory aside for a specific customer is common practice.

3.  currencyUomId of InventoryItem: real question is when currency
conversion should take place.  If it takes place when inventory is
received, then we don't need it at all.  We can just reference
currencyUomId of the ownerPartyId.  Do you think that's the right way to
do it?  I'm inclined to agree with you.


Si

Jacopo Cappellato wrote:

>Hi Si,
>
>your document looks excellent.
>
>Here are some comments:
>
>1) you state that inventory items produced by a manufacturing order
>(WorkEffort) should be grouped together in a (special type of)
>ShipmentReceipt; I don't think this is necessary: inventoty items
>produced by a manufacturing order are already associated to the
>manufacturing order thru the WorkEffortInventoryProduced entity.
>
>2) in the InventoryItem entity there is a field called partyId: can this
>be used to store the owner party id?
>
>3) are we sure that we want to set currency uom ids at InventoryItem
>level? Maybe we can simply add the currencyUomId field in the facility
>entity. For inventory transfers between facilities with different
>currency uoms we can perform a conversion for inventory items costs.
>
>Jacopo
>
>
>Si Chen wrote:
>  
>
>>Hi everybody.
>>
>>We're in the process of a major overhaul of some key parts of the
>>Financials application before making an official release.  Part of it is
>>re-factoring the way inventory valuation is done so that it will support
>>manufacturing, returns, purchases equally under LIFO, FIFO, and Average
>>Cost.
>>
>>I've written out the proposed scheme for doing this.  Please download
>>and read it:
>>http://www.opensourcestrategies.com/ofbiz/Inventory_Valuation.pdf and
>>give me your feedback.  If your organization has an accountant, CPA, or
>>CFO, it would be nice to get his/her feedback as well.  Feel free to
>>write your comments on the list.
>>
>>Thanks!
>>
>>Si
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>    
>>
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Yager]

Hi,

I should caveat that I haven't read what has been posted in the last  
couple of days, but I sent the link to my CPA and this is their  
thoughts on this.

---

On the surface, all looks OK.

It is taking into account all types of costing - FIFO, LIFO,  
standard, average and actual (ie for serialised inventory).

Most companies actually directly expense freight-in.  This is because  
inventory is suppose to be valued at the lower of actual and net  
realisable value.  It is considered more conservative not to  
capitalise the freight content.  It would perhaps make the system  
more flexible if this is a switched on feature only when required.

I am assuming that other costs to be capitalised would be labour  
content etc.

In the case of serialised inventory, I would think you would want a  
code to identify missing stock rather than "rejected/damaged".  This  
would enable "missing" stock when relocated to be re-entered properly  
into the system. Zeroing cost of rejected/damaged stock also sounds  
strange.  The cost of such stock should be written off according to  
its assessed saleability.

--

Thanks,
Andrew

_________________________
Andrew Yager
Real World Technology Solutions
Real People, Real SolUtions (tm)
ph: [phone] (office) [phone] (direct)
fax: [phone] mob: [phone]
http://www.rwts.com.au/
_________________________

On 25/02/2006, at 4:45 AM, Si Chen wrote:

> Hi everybody.
>
> We're in the process of a major overhaul of some key parts of the
> Financials application before making an official release.  Part of  
> it is
> re-factoring the way inventory valuation is done so that it will  
> support
> manufacturing, returns, purchases equally under LIFO, FIFO, and  
> Average
> Cost.
>
> I've written out the proposed scheme for doing this.  Please download
> and read it:
> http://www.opensourcestrategies.com/ofbiz/Inventory_Valuation.pdf and
> give me your feedback.  If your organization has an accountant,  
> CPA, or
> CFO, it would be nice to get his/her feedback as well.  Feel free to
> write your comments on the list.
>
> Thanks!
>
> Si
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Andrew,

Thanks so much.  This is very helpful.

We were not planning to support the allocation of freight-in etc. costs
at this stage.  I'm glad to hear that your accountant considered it
better just to expense it.  

Labour, etc. would be capitalized but as part of the manufacturing
process.  As for the purposes of this document, we would basically
assume that inventory is received when the manufacturing process is
done, and the cost of the inventory would be the finished goods cost of
the manufacturer items, however they are calculated.

I agree that zeroing out cost would be kind of strange.  I think we
should move it to a system where the quantity is changed.  Serialized
InventoryItems should be associated with quantity as well.  Just as a
general caveat--the structure for supporting serialized inventory
appears to be in place in OFBiz, but it needs to be "tightened up" a bit
to make sure it actually works.

Thanks again.  This is much appreciated.

Si


Andrew Yager wrote:

>Hi,
>
>I should caveat that I haven't read what has been posted in the last  
>couple of days, but I sent the link to my CPA and this is their  
>thoughts on this.
>
>---
>
>On the surface, all looks OK.
>
>It is taking into account all types of costing - FIFO, LIFO,  
>standard, average and actual (ie for serialised inventory).
>
>Most companies actually directly expense freight-in.  This is because  
>inventory is suppose to be valued at the lower of actual and net  
>realisable value.  It is considered more conservative not to  
>capitalise the freight content.  It would perhaps make the system  
>more flexible if this is a switched on feature only when required.
>
>I am assuming that other costs to be capitalised would be labour  
>content etc.
>
>In the case of serialised inventory, I would think you would want a  
>code to identify missing stock rather than "rejected/damaged".  This  
>would enable "missing" stock when relocated to be re-entered properly  
>into the system. Zeroing cost of rejected/damaged stock also sounds  
>strange.  The cost of such stock should be written off according to  
>its assessed saleability.
>
>--
>
>Thanks,
>Andrew
>
>_________________________
>Andrew Yager
>Real World Technology Solutions
>Real People, Real SolUtions (tm)
>ph: [phone] (office) [phone] (direct)
>fax: [phone] mob: [phone]
>http://www.rwts.com.au/
>_________________________
>
>On 25/02/2006, at 4:45 AM, Si Chen wrote:
>
>  
>
>>Hi everybody.
>>
>>We're in the process of a major overhaul of some key parts of the
>>Financials application before making an official release.  Part of  
>>it is
>>re-factoring the way inventory valuation is done so that it will  
>>support
>>manufacturing, returns, purchases equally under LIFO, FIFO, and  
>>Average
>>Cost.
>>
>>I've written out the proposed scheme for doing this.  Please download
>>and read it:
>>http://www.opensourcestrategies.com/ofbiz/Inventory_Valuation.pdf and
>>give me your feedback.  If your organization has an accountant,  
>>CPA, or
>>CFO, it would be nice to get his/her feedback as well.  Feel free to
>>write your comments on the list.
>>
>>Thanks!
>>
>>Si
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>    
>>
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev