Your basic process is sound. Auto-enter calculations do not trigger based on value changes in related tables (as you've discovered). So you're restricted to using either a Script Trigger (as you've done), or a batch process that runs on some frequency (which is probably not appropriate here, based on the need for more real-time feedback).
I think the problem isn't your process, but the specifics of your calculation. I don't know enough about the particular database to give you a good answer, but it sounds like you need to account for the case that's coming up wrong by running a check to see if the quantities are appropriate. If not, either throw a warning and force the user to fix it, or put up a status of "Error" or something like that.
Not sure that helps much, but maybe that will point you in a good direction.
Sounds like this will work for now. The client said that if they ship more than the order, they would change the order qty before they generate the packing list. So, it should not be an issue.
For another area with similar requirements, I had implemented this technique:
But that was for a updating the status of a single record, not one with multiple line items.
The other complication is that this is a converted (from who knows how old) solution, so while they are using FM13, they still have everything in separate files. Not as easy to hop around.
"The other complication is that this is a converted (from who knows how old) solution, so while they are using FM13, they still have everything in separate files. Not as easy to hop around."
I feel your pain ...