Hi Anthony,

Unfortunately you will have to unassign the service agent to the demands and order before invoicing.  There is no mechanism to invoice when the agent is deactivated.

Other option is to leave him active a little longer to allow you to invoice the order and then deactivate him 

Hi Anthony,

To clarify, my advice above was only due to the fact you cannot set the employee’s end date or Inactive while they are assigned to an order that has not yet been moved to history regardless if that activity was prior to the planned end date or not.

However, in discussion with R&D, there is an RFE developed allowing deactivation of employees who have already completed all their activities.  At this point, it would be possible to make the employee inactive and then invoicing is also possible according to R&D.

This RFE is already developed and could be provided to retrofit to earlier versions than the planned next release via a fix document.  For resolving your question for tomorrow, my advice still stands.

Hope this helps.

Hi Phil, we run into a simular issue when an employee needs to be set inactive.

• first we remove all portals from the “Alliance Portal” page in the Employee Security module to be shure this person cannot use Astea anymore but also to be able to re-use the licences.
• then we have to wait until all orders where employee has a fullfilled activity (or has created) are in history before we can de-activate that employee. This can take serveral months, surely for repair orders where longer delays are more common (sent to vendor,...)

with this method we can continue to work but our data for analysis is not correct. Employees are still active according Astea even after they have left the division already for a couple of months

Will this be solved in HF6 for v15.3 ?

Hi Piet,

The RFE is for SU4 so I will have to inquire with R&D if this is possible or not.  SU4 is due early next year while HF6 is scheduled for 22-Dec.

I know there is a fix document and it can be retrofitted into the dll code.  (it is not a .js type client side fix).

R&D confirms this will be added to HF6 now.