Hi Chaitanya,

Can you confirm the following your user is allowed access to the node NLD (Employees Security - Nodes) when you are trying to open it from Order Locator.

As for searching in Service Order (don't bother looking in Service Order History as the order is on Resolved status and not moved to history), please clear your search criteria with the clear button and search again.

If this still fails, in case there were recent changes to the application, clear your Astea Browser cache.

Kind regards,

Phil

Hi Phil,

• Your user is allowed access to the node NLD (Employees Security - Nodes) - Yes
• There is not a view applied to your Service Order module QBE? (it may say last view) - No view applied
• You cleared the search criteria and tried searching again for just the Request ID? - Yes tried that

Then I suggest enabling debug mode in the global.xml for the profile and capturing the event logs to provide to your Alliance support desk.  This is how we can see what queries were executed when you searched for it in the Service Order module.

Please work with Alliance EMEA Support to review this further as it cannot be diagnosed/troubleshot via this forum.  I see you have logged a ticket for this already.

It is possible the order did not properly move to history. We’ve encountered a similar issue in the past

US0011086@@1 - Execute this script to move order to history if they are stuck in 900 or 2000 order stat_uniq_id

Run this script first to verify order has been identified

SELECT order_id, request_id, order_type_id FROM order_line WHERE (order_stat_uniq_id = 900 or order_stat_uniq_id = 2000)
AND order_type_id <> 'sale_order' AND order_type_id <> 'sale_quotation'

Phil - There is a script associated to the issue# that may help

Thanks, Kyle.

I don't believe this is the current scenario as the order is on Resolved (500) status thus should not have been moved to history yet.  You are correct if the status was Invoiced (900) or Cancelled (2000).

Yes, I have seen your scenario in the past and have used scripts to move orders to history after confirming they were not already there having duplicated rows (to prevent primary key conflicts).

Along with order status as Kyle mentioned, there have also been times where the itil type of an order is not correct - I believe for service orders, it should be ServiceRequest.  I would suggest opening a support ticket and providing a backup of the database so that we can research and debug this issue.

Phil - the script that Kyle mentioned takes care of possible duplicates in history table. In short it finds “stuck” orders records, removes their corresponding rows from all history tables if any, and moves orders to history. So, in that case you don’t need to do the check through history tables

The itil_type in the database is incorrect and causing the order not to display.

Running the following query will show the incorrect value:

select itil_type from order_line o with (nolock)
inner join service_call sc with (nolock) on sc.order_id = o.order_id
inner join service_call_env sce with (nolock) on sce.order_id = o.order_id
where o.order_id like 'SV2012040045%';

We can then find all orders that have this problem using the following query:

select order_id from service_call with (nolock) where itil_type = 'ServiceRequest?action';

Finally, we can correct the orders using this update statement:

update service_call set itil_type = 'ServiceRequest' where itil_type like 'ServiceRequest?action';

The root cause of this issue has been addressed in later versions of V14 and V15.