Hi Chris,

I don't have access to your database but can you check with SQL whether the order_line.order_id or c_order_line.order_id for SV2310230098@@1 is in the database?  I have seen cases where the node_id is missing for example and it will not appear in the search results.  It should not be a case where the order_stat_uniq_id is defined such that the order locator can't find it but service order will not find orders having that set to 700 or higher (order locator and audit queue should normally find it).

This is a support issue and probably a ticket should be logged for it but if you can send a select *  query result for the order_line or c_order_line tables where this order might be found, this can be reviewed for some of the more obvious things that would disqualify it from being found.

Hi Phil,

Thanks, I tried that and SV2310230098@@1 is not showing up at all in either order_line or C_order_line.

So I guess we’ll have to log a support request but without being able to replicate it will make it difficult to track down.

Sorry to hear that, Chris.

I do find it strange that an order can just 'disappear' like that after it was assigned.  It should be in the database unless someone executed a script to delete the record.  The application does not remove records from the order_line table until it is moved to the c_order_line table.

I wonder if there was an SQL or Network issue during that process if for example the order was canceled or invoiced and never committed to the database.  Otherwise it has to be in either of the two tables.  You could also check the service_call and c_service_call tables but if I recall, when a record is deleted by SQL, it cascades to the other tables via dependencies.

Another thing to check is via the Request ID… I remember in older versions we encountered issues where the Request ID was not aligned with the Order ID,  for example… Request ID = Phil1 and order_id = Phil2@@1.  The two should be the same prior to the @@ string.

Also, look at the log files for the PM Batch Scheduling.  Perhaps there was an indication of an issue recorded there.  These logs usually are stored in the profile filestoragepath folders.

Maybe there was an issue and it could not save but then rolled back, tried again which picks up the incremented number and thus creating a gap?

Thanks Phil,

I checked again using Request_ID but got the same result. Also when looking service_call and c_service_call.

 I’ll ask a colleague to assist with the PM Batch log files later.

Your idea of a network issue when transferring from active to history is interesting and worrying.

Hi Phil,

Thanks for the excellent support.  We managed to find the PM Batch log and turns out that the SV in question failed due to a bad pricing rule, so was never completed, hence not in history or active.

So not a system issue.

Thank you

Hi Chris,

 Very happy you found the issue in the PM logs.

As indicated, there is nothing in the application to delete service orders once created so more likely something happened during the creation process itself.

Hello Chris,

Just to ease your concern about missing orders during the transfer from active tables to history tables due to network issue. Order information will never be deleted from active table until the end of the successful transfer. We had cases when transfer was interrupted and order was partially moved to history, fully moved to history but was not removed from active table, etc. So, in such cases sometimes the order is not visible on Server Order or Service Order History search screens but should be visible on Order locator search which looks at both active and history tables. And it’s definitely can be found directly in the database in one of the tables (active or history) or both.