Product documentation
Service Management - DYS - Setup > Calls
A service activity normally starts with creating a service call. Using the repair or helpdesk search screens to find the correct customer, service object and all other necessary information to create a call.
From the service call one or more service tasks are created to forecast, plan and register actual work done on the service object.
The service call is used to track and follow up on service activities using service level and service level agreements (SLA) milestone registration.
Based on the call and service level definition, which are linked to the service object, the service transactions are defaulted with appropriate information for invoicing.
Service Management - DYS > Setup > Calls > Call types
A call type is the entity that is used to define what type of service is needed. Each service call needs a call type at the call creation step. Typical examples could be maintenance, inspection, complaint. Call types have settings that define under which circumstances this call type is allowed. Also, a call type is designed so that the user can define the steps, or call statuses, that are needed to solve this service call from beginning to the end. Each call gets this call type assigned will adopt these statuses and settings.
| Field | Description |
| Call type | Unique identifier for the call type. This ID will be visible in multiple forms, so a logical name is advised. |
| Description | Description of the call type. |
| Details | |
| Options | |
| Auto post WIP | When ticked, automatically work in progress transactions will be posted (when used) once the call is closed. This only is applicable for non-invoice abel lines since the work in progress transactions of invoice able lines will be posted will posting the invoice. |
| Mandatroy call tracking | Besides registering hours on a service task, it is possible to keep track of the time spent directly on the service call. This can be done via the call timer buttons on the service call list page and the service call details screen. When this tickbox is ticked on, the call time will start automatically when the call timer functionality is also activated for the employee working on the call. |
| Supress visit transaction | Only applicable when using the Mobile Field Service (MFS) solution. Once ticked the visit transaction created in the mobile device won't update the transaction in Service Management. |
| Allow idle object | When ticked on, it is alllowed to us this call type for all service objects without a contract. |
| Automatic invoice project | Create invoice project automatically if no contract is specified. First a check will be done whether there is an invoice project based on the customer ID available. If this is not the case, an invoice project will be created based on the customer ID. |
| Auto visitline | On the service task linked to this call type visit lines (travel) can be added. When this tick box is ticked on the visit line, it will be added automatically when a service task is created. |
| Active contract required | When ticked, on this call type can only be made against a contract with the status active. |
| Scheduling | |
| Plan term (time) | The time defined will calculate, based on the SLA reference time of the service call, required start time of the service task. |
| Plan term (days) |
The days defined will calculate, based on the SLA reference days of the service call, required start date of the service task. |
| Setup | |
| Calendar | Calendar used for the deadlines defined in this call type. The working time in the calendar in combination with the deadline time of a call status determines the actual SLA date/ time for a service call of this type. When the calendar field is blank, the working time will be set to 24 hours a day. |
| Project group | When a service task created from a service call this project group will be used to create a sub project in the project module. This project group is mostly of the type time and material. When this field is blank, project group of the parameters is used. |
| Default event code | When adding a service task to a service call of this type, the selected eventcode can be used as default. When blank, the event code should always be selected from the pull down menu on the service task. |
| Exclude from moible field service | Only applicable when using the Mobile Field Service (MFS) solution. This default task priority will be shown in the agenda in the mobile device and is for information only. |
| Call type | Automatically filled in ased on the selected call type in the top part of the screen. |
| Call status | Description of the call status |
| Deadline days | Detemines, togehter with the deadline time, the Service Level Agreement (SLA). The effective deadline date/ time is calculated from the service call SLA date/ time. I.e. if the deadline days is set to 1, it means that the deadline of this call staus will be 1 day after teh call was created (SLA reference time). |
| Deadline time | Detemines, togehter with the deadline days,, the Service Level Agreement (SLA). The effective deadline date/ time is calculated from the service call SLA date/ time. I.e. if the deadline time is set to 8, and de days to 1, it means that the deadline of this call status will be 1 day and 8 hours after the call was created (SLA reference time). |
| Sub status | Group or person responsible for the next progress, i.e. employee or customer. |
| Ref. time | Mean time consumed for this status. Normally indirect tiem, not registered anywhere. Could be in the second range. As each status is assigned, reference time is accumulated in the call history. This produce information on call handling overhead. |
| Action delta type |
The action as used on the service call can be eneterd manually or can be calculated based on the deadline date/ time. Forward from status change: The defined time in the action days/ time delta is added to the moment of the call statuschange to determine the action date/ time. |
| Action delta days | Determine the amount of days for the calculation of the action date/ time |
| Action time delta | Determine the amount of time for the calculation of the action date/ time. |
| Allow status | All settings as discriped, needs to be defined per call status. |
| Complaint code required | The complaint code value is needed before the status may be assigned. This makes the complaint code a mandatroy field for this status. |
| Cause code required | The cause code value is neeed before the status may be assigned. This makes the cause code a mandatory field for this status. |
| Solution code required | The solution code value is needed before the status may be assigned. This makes the solution code a mandatory field for this status. |
| Use quantity counter setting required | Use quantity counter value needed before the status may be assigned. This ensures counter values are only become mandatory fields. |
| Notify | |
| Notify | Should an email be sent as notification? This option is only available for those sub-statuses where Microsoft Dynamics 365 for Finance and Operations had an email address for. Only applicable if email is set for customer, vendor and employee. This email address is taken from the contact person if one is chosen. |
| Close call | |
| Close call |
For closing call there are three options: No close allowed: The call remains open and can't be closed while assigned this status Closed allowed: The call may be closed using a button, if all conditions for the close fit. This is: all mandatory fields are filled and all service tasks have the status ready. The same button may later be used to re-open the call. Automatic close: As soon as this status is assigned, checks are performed if all conditions for the close fit. This is: all mandatory fields are filled and all service tasks have the status ready. The same button may later be used to re-open the call. |
| Show close dialog | When this tickbox is ticked, a close dialog will appear while closing the call. In the close dialog the complaint, cause and solution code can be entered as well as the solution text. |
| Solution code required on close | The solution code value is needed before closing the call. This makes the solution code a mandatory field for this status. |
| Reopen call status | Define the call status that will be entered when a service call is reopened. |
| Close call status | Define the call status that will be entered when a service call is closed. This only works with the close call field set to closed allowed. When hitting the button in status X during the closing of the call, the status will automatically be changed to the defined close call status. |
| Colors |
| Color code | The defined color will be used for the service tasks linked to a service call of this type. The color will be shown in the scheduling overview. The idea is that the color can help you quickly in identifying the type of scheduled job. |
Service Management - DYS > Setup > Calls > Service level agreements
The SLA ID's are ID's that can be used in the call type SLA setup. Each deviation of the standard SLA as defined on the service call type setup needs to be linked to an priority.
| Field | Description |
| SLA | Unique ID to indentify the SLA. This SLA will be visible on the call type SLA setup. |
| Description | Description of the Service Level Agreement. |
Service Management - DYS > Setup > Calls > Call type SLA
For each call type it is possible to set up different call type SLA's. This set up is not mandatory. This setup allows for changing calendar, deadline- and action times for the same call type, depending on the selected object, contract and severity. This allows the company to assign higher priority and enforce quicker reaction times to calls for certain specific object or object ypes, specific contracts or contract types, or calls with a higher degree of severity. Combinations of those settings are possible to allow for very detailed SLA's.
| Field | Description |
| Call type SLA | Most of the fields in this form are for information only. Only Description, Calendar, Severity, Plan terms are editable. |
| Details | Only for information only |
| Lines | See lines |
Service Management - DYS > Setup > Calls > Complaint code
Service Management - DYS > Setup > Calls > Cause code
Service Management - DYS > Setup > Calls > Solution code
In order to make use of statistics codes functionality, complaint, cause and solution code setup need to be completed. These codes are used to establish a complaint, cause and solution for a service call. Each service call allows for the one complaint code, one cause code and one solution code. These codes are typically used for problem analysis, reporting ande inquiry purposes.
Using complaint, cause and solution codes is optional per default, and is not required to start using Service Management call functionality. With setup described, these codes can be set as mandatory to allow status changes. If so, setting up these statistics codes becomes mandatory.
| Field | Description |
| Code | Unique ID or code for the complaint, cause or solution code |
| Description | Description of the complaint, cause or solution code |
Service Management - DYS > Setup > Calls > Diagnostic tree
The set up of complaint, cause and solution codes, can be made dependent on object types. First it is necessary do define the highest level of the diagnostic tree. Accordingly, a selection of complaint codes can be attached to the tree. For each complaint code, the relevant cause codes and for each cause code the relevenat solution codes can be linked.
| Field | Description |
| Diagnostic tree |
| Tree ID | Unique ID for diagnostic tree |
| Description | Description of the diagnostic tree |
| Object types | |
| Object types | Overview of object types which can be selected for this tree |
| Used by object types | Overview of object types where the tree can be used |
| Diagnostic tree |
| Delete node | Button to delete the tree |
| Cause, solution codes | Depending on selection left, cause or solution code which you can add to the tree |
Service Management - DYS > Setup > Calls > Standard solution texts
In a lot of cased the solution to a certain problem might be the same. To prevent retyping the solutions repeatedly it is possible to define standard solution texts. These texts can be selected while closing the serivce task with the close dialog screen. When selecting the code in the close dialog screen the related text will be copied in the solution field of the service call.
| Field | Description |
| Standard solution texts |
| Sort code | Unique ID for solution text |
| Standard text | Solution text for the sort code |
Service Management - DYS > Setup > Calls > Automatic call status update
Though not a mandatroy setup, the automatic call status update is a considered to be on of the key features in Service Management to automate the service call business process. It is designed to update the status of a service call, based on the status of its related task and their item transaction movements.
| Field | Description |
| Update trigger | The call status updat can be triggerd by the following 3 options Packing slip posting, when this option is chosen, the call status can be automatically be updated once the packingslip is posted for all item transactions. Taskstatus change, when this option is set, the call status will be updated by the task status change Reserved physical, when this option is set, the call status will be updated once all item lines are physically reserved In service normally only Taskstatus change will be used |
| Priority | When a service call has multiple service tasks, the priority of the different call status changes will determine the new call status |
| Call type | Select from the service call type main table for which call type this call staus update is applicable |
| Status | On which service call status is the trigger applicable. The servcie status can be selected from the service call type main table and is filtered based on the selected call type. |
| Event code | When required, the call status cahnge can also be limited by an event code. The event code can be selected from the event code main table. |
| New call status | What should the new service call status be, based on the defined trigger. The service status can be selected from teh service call main table and is filtered based on the selected call type. |
| MFS Status | Only possible when MFS (Mobile Field Service) is used |