The scripting is pretty straightforward, but I question the approach.
May I propose a "transactions" table which would be shown through a portal on the job record layout? A child table, linked by Job# (uniqueID key...don't alter it with hyphens) would have one record per transaction.
Job 5000 has 10,000. pieces on it. It is entered in the job record.
We want to ship 5000, you would fill in the first portal row that you shipped 5000.
Then in the job record, you would have a "Qty owed" field which would be calculated from:
QtyOrdered - Sum(ChildTable::Qty shipped)
The order status would be "Active" if Sum(ChildTable::Qty shipped) < QtyOrdered
or "Complete" if Sum(ChildTable::Qty shipped) = QtyOrdered
or "Overshipped" if Sum(ChildTable::Qty shipped) > QtyOrdered
Doing it this way will let you see how many partial shipments...the number of portal rows. It will also let you track how many were shipped on what date very easily.
This transaction table will also open up the possibility of packing lists, invoicing and inventory control down the road.
My two cents...hope it is of value.
Thank you for help Ninja.
The reason that I am looking to have the job numbers actally represented instead of a child portal is for reports and calculations.
Most partials ship to different customers, so i would like them to be shown in my job summary just as the rest of the jobs.
I would like to see something like to following in my job summary:
Job Qty Finished Qty
50 100 100
51 50 50
52 100 50
52-1 50 25
52-2 25 25 (So now the job is closed out)
53 100 100
If the partial were hidden in portals then I would not be able to see them on summaries and when billing for the seperate partials i need them to be on seperate jobs.