Hi Robin,

According to the query executed by the Audit queue, it is doing a left join to the table order_comp.

Left Outer Join
      order_comp WITH(NOLOCK) On order_line.order_id = order_comp.order_id

The where criteria indicates it is evaluating the value of order_comp.total_price.  (I used CS2206010112 as an example to make the analysis a little simpler.)

And
      ( order_line.request_id like 'CS2206010112%' AND order_comp.total_price >= 1) 

In this case, the value currently populated is 2.4 in our copy of this database.  What I don't know is what is populating the order_comp at this time but the question was where did it come from and it explicitly retrieves it from this table column.

I will have to review how this table is populated to see but the Audit Queue is correctly retrieving the data as it stands. I am already inquring about this column with R&D.

Hi Phil,

Thanks, then indeed the follow up question is then where is this table receive the data from, because Total price in the order (CS2206010112) is 0.

Thanks..

Hi Robin,

I did notice that when I invoiced it (invoiced later), the value was updated to zero.  So apparently the value in the order_comp table is not finalized until the order is actually invoiced.

But this is strange as the previous order status was Pending Invoice (850) and this did not change.  I suspect something happened in earlier HF releases that was populating this column that now does not do this in HF5.  The invoicing from within the service order module does the update, just invoicing it again from the Audit Queue does not update the column.

Hi Phil,

The strange thing is that why order_comp has value with a total price in the first place, when the total price in order is 0.

Should i create a support ticket for this?

HI Robin,

First point, I am working with R&D to clarify whether a recalculation should have occurred when the order was moved from Resolved to Pending Invoice status.  Hopefully we can find out what is happening to not set it to zero value in these cases.

For why it was populated in the first place, it looks like this may be done prior to changing the billable type flag to otherwise as the information I currently have is:

When a user decides to send an order to the invoice (later or to auditing), the order goes through the order completion process and the prices are calculated. The order is completed and is waiting for invoicing (batch). At this stage, the order can be modified and its new price can be different, but the Audit queue will still show the old price, until the order price is recalculated.

It is this last part that I am investigating with R&D to find out why the recalculation did not set the values to zero when going to the invoicing module.