Re: Inventory class proposal

[Reinhard Müller]

Am Don, 02 Nov 2000 09:02:46 schrieb(en) Georg Lehner:
> item:
> key:  varchar(20)     short description, "human" understandable
> key
> internal_code: varchar(35)    "our" article code
> name1:        text
> name2:        text
> name3:        text
> group1:       varchar(35)     Article category. I have seen, that
> Accounting
> group2:       varchar(35)     Department has peculiar interpretation
> so I
> group3: varchar(35)   provide different grouping categories for
>                       ledger, controlling, and ... reserved.

Like you, I don't like too short fields; but I don't see a use for
35 character long grouping code.

> Quantities:
> 
> From problems I had with a 15.3 approach I would suggest to register
> in inventory by the smallest unit of the product,measured in
> long-integer with fixed-coma notation, say:
> 
> qty: longint
> decimals: int
> 
> decimals is an item attribute (property, field, column...)
> 
>       example1: 12.65 kg of gold dust, stored in mg (milligrams)
>               would be stored as:
> 
>       qty = 12650000
>       decimals = 0
> 
>       example2 (real):
>               bunker-oil for our sterilizer vapor plant burner is
>               delivered as 3 decimal fractions of galons:
>       qty = 42695437
>       decimal = 3
>               ==> 42695.437 gal 

This is actually the same as I proposed for storing currency. On the
one hand, it creates a lot of headache when you have to display such
values (on screen and on reports), on the other hand it would surely
be a good idea to use the same system for currency _and_ quantities.

> If we could use BCD we would be better off, at least when using SI
> units and derived: g, l, m, etc. and with decimal fractions. The ones
> who like to store in units of 1/16 gal would benefit from a binary
> notation for minimizing rounding errors.
> 
> Next issue: units. We propose to field in item which refer to a
> selection list.
> 
> multiplier: -->               
> unit: -->
> 
> multiplier_codes:
> 
> key:  varchar(10)     `k',`m',`M',`u',`K' - letter(s) which
> appears
>                                             before unit. 
> conversion: float (?) kilo = 1000,
>                       milli = 1/1000,
>                       mega = 10^6,
>                       omicron = 10^-6,
>                       Kilo = 1024,        - conversion factor to next
>                                             SI unit or unity (1)
> comment: text         Well, comment!
> 
> unit_codes:
> 
> key:  varchar(15)     `m', `g', `gal', `onz', - unit text
> comment: text         meter, gram, gallones, ounces (in spanish
> onzas).

> So to describe 3.5 kilometers of aluminium wire gage 00 for a new
> high-voltage line we used: multiplier=k, unit=m -> km
> 
> This allows us to dispatch our gold dust in kilograms while storing it
> in milligrams.

Still you have the problem when you once sell 600 m of a wire, and next
time you sell 20 kg. This example is not so far from practice.

> But that's not all on conversion stuff:
> 
> Next issue: packages. We propose a package-> code for each item,
> packages are defined in a list.
> 
> package:
> key:  varchar(35)             short name for the package form
> comment: text                 epic name for the package
> conversion:   longint         How much units of the base unit
> are
>                               kept in the package. The `decimals'
>                               field apply. 
> 
> What if we sell vine in bottles, but we buy vine in barrels.
> 
> We would store it in liters, with three decimals.
> 
> instances of package:
> 
> key     |comment                     |conversion
> barrel    |Full Size Barrel with 45 l  |45000
> halfbarrel|Hall Size Barrel with 20 l  |20000
> bottle          |standard bottle             |00750
> champagne |Champagne bottle            |02000
> 24 box    |Box with 24 standard bottles|18000
> dozen   |Box with 12 standard bottles|09000
> 
> etc.
> 
> If we buy three "barrel"s gnue stocks 135 l of wine, If we sell 5
> "bottle"s we reduce our stock by 3.75 l.

This is ok, but then we have to have this table per item, because
some kinds of wine are bottled 0.75 l and some are 0.7 l.

And, I would like to have a pseudo-item-number for each of these
packages. And actually an own price.
And actually it's own stock, because I want to know whether I have
enough bottled wine, or I have to fill some bottles from a barrel.

> Next Issue(s):
> 
> I think that also volume, and weight should be standard with the item.

Yes. Volume, brut weight and net weight. Of course brut weight is
dependent on the package.

> At each provider the item has a different order number and description
> then we use, so we should register them there.

Order number yes, description no. At least not necessarily.

> Article numbers are propably missleading, as in some firm on article
> number is used for (sligthly) different products, while in others it
> is a real unique key.

Item numbers should IMHO always be an unique key in inventory.

> Question:
> 
> Please explain what is "abcType" and "Cycle Count Frequency", and also
> the terms "value" and "rotation".
> 
> Finally: where will the future discussion be pointed to?

The discussion should take place at address@hidden

Please all who are interested in this subscribe there.

Thanks
--
Reinhard Müller
BYTEWISE Software GmbH
address@hidden
www.bytewise.at