B
BruceM
Without going into an involved explanation, the main form is for Job
information, and the subform is for details. The forms are based on related
tables.
The Job table includes the quantity. The ReworkDetails table includes the
step of the process during which parts were removed from production due to
flaws, etc. The steps are sequentially numbered in the processing plan (the
Steps are stored in a related PlanDetails table) that is used as the basis
for the job, but there is no inherent sort order for the records that are
placed in the ReworkDetails table.
It is necessary that the steps with associated rework be sorted in the
Rework table in the same order they appear in the PlanDetails table (the
reasons are fairly complex, so I will just say that calculations need to be
performed based on the various quantities, including the reduced quantity
when parts are removed from processing. If 10 of 100 original parts were
removed from processing after Step 1, I need to show that only 90 parts
continued through processing. Various calculations depend on this
information. Since there is no guarantee the Steps listed in ReworkDetails
will be entered in sequential order (which is quite likely in the natural
course of things), I cannot rely on sequential numbering of the
ReworkDetails records, and instead I believe I must use the Step number in
the PlanDetails table for the sort order. This means storing the number,
which seems redundant, but I don't see a way around it.
Another consideration is that a step (let's say Coating) may be Step 5 in
one ProcessPlan and Step 8 in another. Also, the sequence of steps may be
reversed in a different ProcesPlan. The Coating record from the Steps table
has a PK and a description, neither of which can be used to sort the records
in the ReworkDetails table. This is why I think it may be necessary to
store the SequenceNumber from the PlanDetails table.
Finally, the calculations that must be performed are aggragate calculations
for all jobs performed according to a particular ProcessPlan. It is not
enough to perform calculations on the ReworkDetails form based on a single
Job record. If Job 1 was for 100 parts and Job 2 for 200 parts, the
calculation is performed as if there was a single job for 300 parts. For
that reason it may be necessary to store the reduced quantity (when parts
are removed from processing) in the ReworkDetails table. This seems to be
somewhat redundant, but as I need to keep a running total I don't see
another way. I understand about performing calculations on the fly for a
single record (or a main record and its related records), but I can't see a
way of performing on the fly the type of aggregate calculations I need.
Have I overlooked anything obvious here? Is any of this comprehensible at
all?
information, and the subform is for details. The forms are based on related
tables.
The Job table includes the quantity. The ReworkDetails table includes the
step of the process during which parts were removed from production due to
flaws, etc. The steps are sequentially numbered in the processing plan (the
Steps are stored in a related PlanDetails table) that is used as the basis
for the job, but there is no inherent sort order for the records that are
placed in the ReworkDetails table.
It is necessary that the steps with associated rework be sorted in the
Rework table in the same order they appear in the PlanDetails table (the
reasons are fairly complex, so I will just say that calculations need to be
performed based on the various quantities, including the reduced quantity
when parts are removed from processing. If 10 of 100 original parts were
removed from processing after Step 1, I need to show that only 90 parts
continued through processing. Various calculations depend on this
information. Since there is no guarantee the Steps listed in ReworkDetails
will be entered in sequential order (which is quite likely in the natural
course of things), I cannot rely on sequential numbering of the
ReworkDetails records, and instead I believe I must use the Step number in
the PlanDetails table for the sort order. This means storing the number,
which seems redundant, but I don't see a way around it.
Another consideration is that a step (let's say Coating) may be Step 5 in
one ProcessPlan and Step 8 in another. Also, the sequence of steps may be
reversed in a different ProcesPlan. The Coating record from the Steps table
has a PK and a description, neither of which can be used to sort the records
in the ReworkDetails table. This is why I think it may be necessary to
store the SequenceNumber from the PlanDetails table.
Finally, the calculations that must be performed are aggragate calculations
for all jobs performed according to a particular ProcessPlan. It is not
enough to perform calculations on the ReworkDetails form based on a single
Job record. If Job 1 was for 100 parts and Job 2 for 200 parts, the
calculation is performed as if there was a single job for 300 parts. For
that reason it may be necessary to store the reduced quantity (when parts
are removed from processing) in the ReworkDetails table. This seems to be
somewhat redundant, but as I need to keep a running total I don't see
another way. I understand about performing calculations on the fly for a
single record (or a main record and its related records), but I can't see a
way of performing on the fly the type of aggregate calculations I need.
Have I overlooked anything obvious here? Is any of this comprehensible at
all?