I would recommend thinking about your data and your reporting needs
first. Then develop the form last as the representation of your data
input requirements.
It sounds to me like the widgets generate income while they are stored
(from your remaining quantity on hand comment) and then go away
(consumed).
Do the widgets need to retain the data about what container they were
in? That is what I am hearing from your description.
Container XYZ
Widget 123
Widget 456
etc.
etc.
Widget 999
If this is the case, think about a table that keeps track of what you
know about containers. Then another table for what you know about
widgets, of which one piece of data is what container the widget was
in. Then the container number is a column in the widget key and a
foreign key to the container table.
For me, it is always data first, forms later. Getting the data
relationships is the key item and then the form is easy based on the
data.
Post back if you have other questions as you go.
On 30 Oct 2006 21:43:37 -0800,
pq*******@gmail.com wrote:
>I have an interesting Challenge - It is effectively an inventory system
but with a twist.
For each client, I need to track, let's call them containers. each of
these containers logically contain, let's call them widgets. (widgets
actually have a separate physical location, so the relationship is
logical at first...)
When a widget is consumed, I need to retain tracking of it. (as a) the
billing is actually done on the "remaining quantity on hand" and b)
there are post consumption details that need to be updated, and kept
forever...
I am trying to work out how to best represent this in a form Something
like a Microsoft Excel outline comes to mind, but I am open to
input/suggestion. Any ideas...
Peter
