Test Case Scenario for Purchasing Receiving and Invoicing & Sales invo

I posted this in Mantis but I just thought i'd also include it here to see if anyone else has this issue or has a work around.

_____

Here is a test scenario I have which as a result shows an inaccurate inventory amount. I start this case with a Trial Balance of everything 0, from scratch and here is the result.

I'm not sure if there is a work around, but it causes problems to the balance of my inventory/purchases account:

1) I create a PO for an item at 500 units at 10 dollars

2) I then receive the PO items stating that 500 was delivered (Price is not changed since I haven't received the invoice yet till later).

3) I haven't yet created the PO invoice since I didn't get it yet, but I create a sales order for that item at 300 qty for 15 dollars price and create dispatch the sales order for 300 units, since the PO has been received already and inventory is available. Result of GL is that it debits Purchases account for 3000 (300 x 10.0) and Credits Inventory for 3000

4) I then invoice the delivery note which credits Sales account and debits AR

5) After all this, I finally get an invoice from the supplier, which I now create an invoice for it. So I enter Supplier Invoice and choose the Items Received Yet to be Invoiced, in this case 500 was received and Qty for invoice is 500. Original order price was 10.0... but in this particular case supplier gave me a better price so I put in 8.0 instead. After entering the invoice. AP is credited 4000 and Inventory is Debit 4000.

The problem is that now Inventory shows 1000 with 200 pieces left over instead of being 8 dollars a piece average cost value its 5. Purchases account is out of synch as well since it recorded at the point of Delivery based on the original PO price of 10.

The ideal scenario would be if the invoiced price differs the order price, that an automatic adjustments would be made to correct the difference to the Purchases and Inventory Account.

I'm not really sure on what the work around would be, since information is entered at different times using the same data, which really messes things up.