request for comments on inventory experiment

[Richard Mancusi]

Basic comments about inventory follow - there is much more to learn.
You won't want to implement the entire function at once.  But it
doesn't hurt to know where you are going to avoid re-programming.
If I misunderstood your comments or perhaps missed other posts,
pleas accept my apology.

I think you are confusing inventory with BOM or Multilevel (structured) BOM.
A part stands on its own in inventory - not associated with the next step in
the process because it can be used to make many other parts.  e.g. a 12'
piece of bar stock can be cut and manufactured into many different parts
with different part numbers and costs.  The cost now includes manufacturing
costs, spoilage, etc.  Even a simple screw or resistor can be used in many
other parts which make the sub-assemblies and and eventually the assembly.
Many of the parts may also have individual sales potential as spare or
replacements.  There are even "goesinto" reports that will tell you every
place a part is used.

It is very important that each part stands on its own in an inventory so
you can set reorder levels.  e.g. You may wish to keep 100 pieces in
inventory for customer replacements.  So if you want to put a build to
the factory that requires 200 pieces and you have 250 in inventory, you
can't release the build because you are out of "build stock".

The comments made about how to handle inventory are incorrect for
basic inventory - but PERFECT for a structured BOM.

If you need samples let me know - and give me some time.  I will need
to alter them to protect the companies in question.

-rich


On Jan 5, 2008 5:37 PM, Andrew Sackville-West
<andrew at swclan.homelinux.org> wrote:
> On Sat, Jan 05, 2008 at 05:13:33PM -0500, Josh Sled wrote:
> > "Lianto Ruyang" <lianto.ruyang at gmail.com> writes:
> > > I hope my description is quite clear and understandable. I need inputs from
> > > all of you whether this idea is good enough for an inventory system in
> > > gnucash and can be developed for future needs, any ideas, any directions
> > > will be greatly appreciated.
> >
> > I know hardly anything about the practical concept and requirements of
> > "Inventory" tracking.
>
> One of the more difficult issues is tracking parts of greater wholes
> in a manufactured product. And there is need to track at both levels:
> the raw goods and the finished product (and maybe the in between
> levels as well: subassembly A, B, C etc). And one needs to be able to
> convert between these.
>
> >
> > However, the system you proposed sounded very similar to Commodity accounts.
> > They, too, are children of Asset accounts, with Lots of "shares" (not
> > necessarily in integer values/units only), where the price of the commodity
> > varies over time.
> >
> > I'm wondering if you can leverage that mechanism to implement inventory
> > here without such extensive changes.  Maybe just modifying the app/UI-layer
> > to accommodate Inventory.
>
> I think you're on to something here.
>
> >
> >
> > > Account-T\ree
> > > |---Asset
> > >       |---Inventory Account 1
> > >       |       |---lots (goodsA's lots + goodsC's lots)
> > >       |---Inventory Account 2
> > >       |       |---lots (goodsB's lots)
> > >
> > > The only difference of an "Inventory Account" with other type of accounts
> > > is: the lots in "Inventory Account" will have a path "goods-guid" in its
> > > slot, pointing to a goods' GUID.
> > > So in the above example some  of "Inventory Account 1" lots will have a path
> > > "goods-guid" pointing to goodsA's GUID, an the rest will be pointing to
> > > goodsB's GUID.
>
>
> Why not something like:
>
> Inventory
>         |---Item 1
>         |---Item 2
>         |---Item 3
>         |---Item 4
>
> And call items 1, 2, 3 raw materials and "buy" Item 4's with
> proportional amounts of Items 1,2,3? You could even set up exchange
> rates (more handwaving) so that it takes 3 item 1's and 2 item 2' and
> 5 item 3's to make one item 4?
>
> A
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHgBTNaIeIEqwil4YRAtI/AJ0eoffi7u3EB56+rMPnQ52hI17+owCffPap
> oT9l++CTtTwvg9UZ3QjqKDU=
> =Qm12
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>