Select for Billing & Backorder issue

[AKPolarBear]

I am investigating a possible problem with backorders. I found this by using the OE audit report for a specific order.
Here is the set up: During the select for billing process, the user picks the item, changes the actual ship amount to zero and allows the backorder to be created.
Then, in the same session, the user selects the same item and ships an amount less than is ordered but greater than zero.
An example is 10 ordered, 0 shipped and 10 are backordered the first time. Same item is changed to ship 7.
The problem is the backorder is still at 10, not the correct 3. The inventory gets corrected that evening when the order is invoiced but the OE backorder is still at 10.
We run a Crystal report every morning to verify the backorders from the previous day. The report compares the calculated backorder amount verses the amount Macola OE shows. Problems are identified when they don't match up.
Any thoughts why backorders appear to be only changed one time and are not updated after the initial creation?

 

[MacolaHelp]

Silly question: why not change the qty to ship to 7 during select for billing so the 7 is backordered from the get-go rather than changing to 0 and again to 7? On Macola's program side, it must have to do with the qty ordered, qty to ship, qty backordered fields & the fact that oeordlin_sql is updated after the 3 you shipped is going to oelinhst_sql & the qty backordered field is still at 10. Why change the qty_shipped field twice during billing?

 

[AKPolarBear]

User error in this case. Normally it is done in one step but this type of error has to come up even among the best keyboarders.

I guess my thought is that it appears that any updates or changes to the qty to ship are not updating the backorder (or possibly other) fields after you move on to the next item or order.

I think I have seen this in other areas also. Changes do not update all records as when they were initially created.