Hi,
I will try to give my shot at this.
I would create one 'Item' model which have common fields like
description, product category etc.
For quantities I would create a system of units and unit conversion
tables for each item using one model called 'Unit' and one called
'ItemUnit' or similar.
Unit defines all possible units in the system with their description.
Item would get a ForeignKey field to one unit for defining that items
'base unit'.
This allows you to calculate quantities for each item and you will
always have a base unit for everything to fall back on.
To manage the respective quantities I would go for a traditional
transaction table where all transaction of items gets posted, here by
the model ItemEntry. Here you want to have unit and quantities twice.
Once for the unit handled and once for the base unit. This is to
easily do a summary of how much in base unit you have in stock.
Optionals...
If you need more properties for different item types then I think a
one to many table would be enough. If you even define item types with
it's own model you could give a predefined set of properties for each
item type.
If you need to keep track of where stuff is located (multiple
warehouses or storage locations) just add a location to the
transaction model.
class Unit(models.Model):
name = models.CharField(max_length=10) # for kg, lbs, pcs, l, oz
etc
description = models.CharField(max_length=50) #kilogram, pounds,
pieces, litre, oz....
class Item(models.Model):
no = models.CharField(max_lengt=10)
description = models.CharField(max_length=100)
base_unit = models.ForeignKey(Unit)
....
....
class ItemUnit(models.Model):
item = models.ForeignKey(Item, related_name='units')
unit = models.ForeignKey(Unit)
conversion_factor = models.FloatField()
class ItemEntry(models.Model)
posting_date = models.DateTimeField(auto_now_add=True)
item = models.ForeignKey(Item)
quantity = models.FloatField()
unit = models.ForeignKey(Unit)
quantity_base = models.FloatField()
...
...
def save(self, force_insert=False, force_update=False):
item_unit = self.item.units.get(unit=self.unit) #get the
conversion
self.quantity_base=quantity * item_unit.conversion_factor
#calculate the quantity but in base unit
return super(ItemEntry, self).save(force_insert, force_update)
# Call the "real" save() method.
You would only need to define those units applicable to each Item.
Liquid items would need the units in which you manage them.
Items which is stored by lenght would need units like that.
But you could of course mix. If you know the density of an item you
could get volume / weight conversion.
If you now the weight per piece as well then you could go that way.
All this is based on my experience from several ERP systems, django
and databases over several years.
It might not be the fanciest and smartest use of bleeding edge
features but it would work, is easy to understand and debug, could
easily be ported to something else then django and/or easily
understood using direct database access for information extraction.
//Peter
On Dec 15, 2:56 pm, yummy_droid <yus...@gmail.com> wrote:
> Hi,
>
> I wanted to design a system that would keep inventory data for items.
> The items themselves are different enough, that they don't conform to
> a simple model.
>
> E.g., the products are for a bakery company. The company keeps
> inventory of solid items, liquid items, and items that are used in
> partial quantities. Each has its own properties, some have volume,
> some have wieght, some have length, etc.
>
> So, should I try to create a base "Item" model, which common
> attributes like name and vendor_id, and then have a one-to-many
> relationship to a table which you can add custom fields/value pairs.
> (i would like to be able to choose a "category" when creating a new
> item, and have the form automatically show the fields for that item).
>
> Or, should I go about creating a base "Item" class, and then subclass
> it for each category of item?
>
> My main concern is that the system is built in such a way that we can
> easily create future reports across all the inventory database (e.g.
> what is the time any item has been in the store room, price of
> inventory of same type for all items, etc.), without having to worry
> about the way we implemented the models.\
>
> Thanks.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
