Correct me if I’m wrong, but it seems that handling returns is a separate task from allocating an order –the user is not going to do both at the same time on the same order line item. Most business want to track each transaction with the customer -each order and each return, including when each return occurred, how was it handled (credit or refund) and why. The business probably doesn't want users going in and fudging allocations like that was the original order. What if some units in a lot are later found to be damaged? The business is going to want to know if that's from the manufacturer or a return from a customer. Processing a return has to be a distinct user operation.
If so, the returns reverse-allocate dialog should appear as a separate dialog from the order allocate dialog. It may be the same programmatic dialog with labels and fields dynamically modified, but you should have two functionally different dialogs, one supporting only order allocating (and correcting allocations after a pickup) and one supporting only return reverse-allocating. They’ll probably each be accessed via a separate menu items, for example.
To minimize workload, the reverse-allocate dialog should only have editable fields for the Quantities to Allocate Back for each lot. Do not make the user do double the work (with double the chance of error) by having them also manually subtract from the original Quantities fields. This is achieved without confusion by two possible means:
Don’t have the original Quantities field. Unless it’s important for knowing how to reverse-allocate (e.g., by policy, the user should not reverse allocate more than the original allocation), don’t include this cluttering and potentially confusing information. If the users’ job is to read the quantity and lot number from the label on a bag of returned units, then maybe all your dialog needs is a read-only lot number (sorted) and editable quantity fields. Keep it simple for the user. If the user counts 15 units from Lot A, then have them enter "15" for "A." Don't make users have to perform additional arithmetic (e.g., subtract 15 from the original allocation, or add 15 to the quantity from an earlier return). That's asking for human error. Computers are better at that kind of thing.
Make the original Quantities field read only. Label it to make it clear whether it represents the Original Order Allocation or the amount Remaining w/ Customer (the latter updating automatically). Perhaps you want both. Indeed perhaps you also want the quantity from Prior Returns and Total Returned for each lot. Depending on your users, it may be helpful to spell out the mathematical relation of whatever fields you have by inserting +, –, and = signs between the fields or labels: Original Order – (Prior Returns + Current Return = Total Returned) = Remaining w/ Customer. But again, include any of these only if they are helpful for properly completing a return.
Of course, the fact that each lot has certain attributes like Origin, Certs, and Age implies that each individual unit needs to be correctly allocated back to its original lot if returned. If that’s the case, then your system needs to track the lot identity of each unit sent out and returned. That may make it possible to automate whole Quantity Reverse-Allocated process (e.g., by scanning bar codes of returned units) and you don’t need the UI.
BTW, the standard is to label your execution button “OK” (or “Allocate” is even better), not “Okay”.