Service Requests

In the absence of assignment rules for the service request, the assignment of the request is always linked by default to "dispatching".
This field is used to modify this assignment by changing the various elements managing the assignment of service requests.

• The skill group: when the system has to process a service request that requires a skill group, it will try to assign it to the least busy "skilled employee".
• In the absence of a competent employee, the system attempts to assign the request to an appropriate queue.
• In the absence of the queue, the request is assigned to the dispatching site.
• In the absence of the site, the request is assigned to global dispatching.

The SREASSDEF - Request default assignment and SREASSDET - Request default assignment parameters (HDK chapter - SRE group) are used to control this default behavior. They have priority in the assignment algorithms associated with the skill group.
They make it possible for example, to always assign the request to the connected user irrespective of the skill.
It is also possible to assign a request to a commercial service. This assignment is used when a customer calls the after-sales service for purely commercial questions. In this case, the system attempts to plan a task for the sales representative responsible for the customer.

Even though the automatic assignment of request mechanisms often provide a satisfactory result, it is sometime necessary to manually intervene in order to carry out the most appropriate assignment. Several tools are available for this.

• Assignment to dispatching
  If the user selects the "Dispatching" radio button, the "Assignment detail" field must either be empty or contain the Site code.
  By default, this field is loaded with the site code mentioned in the request header.
  To select a different site, it is possible to use the contextual menu "Site selection" associated with this field.
   
• Allocate to an employee
  If the user selects the "Employee" radio button, the "Assignment detail" field must contain the code of a customer support user.
  By default, this field is qualified on the basis of the skill group entered in the request.
  To select a different employee, the technician has available three distinct tools accessible in the form of a contextual menu associated with this field:
   
  -Selection of an employee.
  This menu is used to select an employee from the list of all the customer support users declared in the application.
   
  - Skilled employees:
  This is used to select an employee from amongst all the competent customer support users for the skill group identified in the request.
   
  -Employee statistics:
  This menu is used to display for each technician working at the site identified in the service request header, the number of requests currently being processed.
   
  It is possible to enlarge the employee statistic to include another site and also to all the customer support users at all sites.
  The "Select" button is used to allocate the request to a specific technician.
   
• Assignment to a queue
  If the user selects the "Queue" radio button, the "Assignment detail" field must contain the code of a queue.
  By default, this field is qualified on the basis of the skill group entered in the request.
  To select a different queue, the technician has two distinct tools available in the form of contextual menus associated with this field :
   
  -Select a queue:
  This menu is used to select a queue from the list of all the queues declared in the application.
   
  -Corresponding queues:
  This menu is used to select a queue from the list of all queues associated with the skill group identified in the request
   
• Assignment to the commercial service
  It can happen that a customer contact the customer support service for reasons that which fall outside of the intervention of this structure. It is often the case that certain customer can call to order new products or to obtain a new quote etc.
   
  In the care where the processing of a call is clearly a commercial issue, the radio button Commercial button is used to re-orientate the request.
   
  If this option is selected, a task is automatically generated for the attention of the sales representative in a charge of the customer account. The due date of the task picks up the date identified in the Desired resolution date field in the request. This generation takes place at the time of the confirmation of the creation or modification of the request. The technician is warned with the following message:
  "A task has been generated for the attention of ....."
  If no sales representative could be identified, the technician is warned by an error message.
  In this way, the sales representative will be warned instantly of the customer request directly via their normal workbench.

This option is also used to perform the closing of service requests.
When a service request is closed, the user is invited to close all non-performed consumptions and write a solution which will be used to update the company's knowledge database.
The closure of a service request is the required stage before invoicing.
Numerous ways exist to trigger the closure of a service request.

• Click on the Closed radio button of a service request.
• Use the contextual menu "Close the request" on the service request line in the workbench.
• Check the Request satisfied field in the report record for a service response.

The closure of an intervention is the time to enter the status of the request. At the time of the closure, the status of the request is automatically initialized with the status of the request which corresponds with the closure status. It should be noted that a single request status must correspond to a closure status in miscellaneous table 422: Service request status. The icon corresponding to the closure status will then be displayed in the service request header.
The closure of a request is the preferred procedure to carry out the creation of a solution record. In fact, in this case, the skill group for the solution is picked up from the request. The problem title and description are also recovered from the service request.
In addition, in the case where a request is closed from the intervention record report, the solution description is recovered from the intervention report.
The user must simply complete the solution with a category, several key-words and any associated solutions.

Even though the automatic assignment of request mechanisms often provide a satisfactory result, it is sometime necessary to manually intervene in order to carry out the most appropriate assignment. Several tools are available for this:

Assignment to dispatching

If you click Dispatching, the Assignment detail field must either be empty or contain a Site code.

This field defaults to the site code specified on the request header.
In order to select another site, the technician can click on Select site from the Actions icon available in this field.

Allocate to an employee

If you click on Employee, the Assignment detail field must contain the code of a customer support user.

This field is loaded by default based on the skill group entered in the request.
To select a different employee, three tools are available to the technician from the Actions icon in this field:

• Selection of an employee:
  Use this action to select an employee from the list of all customer support users declared in the application.
• Competent employees:
  Use this action to select an employee from all the competent customer support users for the skill group identified in the request.
• Employee statistics:
  Use this menu to display for each technician working at the site identified in the service request header, the number of requests currently being processed.
  You can extend the employee statistics to include another site and also to all the customer support users at all sites.
  Click Select to allocate the request to the technician of your choosing.

Assignment to a queue

If you click Queue, the Assignment detail field must contain the code of a queue.
This field is loaded by default based on the skill group entered in the request.
To select a different queue, three tools are available to the technician from the Actions icon in this field:

• Selection of a queue:
  Use this action to select a queue from the list of all the queues declared in the application.
• Corresponding queues:
  Use this action to select a queue from the list of all queues associated with the skill group identified in the request

Assignment to the commercial service

It can happen that a customer contact the customer support service for reasons that which fall outside of the intervention of this structure. It is often the case that certain customer can call to order new products or to obtain a new quote etc.

In the case where the processing of a call is clearly a commercial issue, click Sales department to redirect the request. A task is then automatically generated for the sales representative in a charge of the customer account. The due date of the task displays the date identified in the Desired resolution date field of the request. This generation takes place at the time of the confirmation of the creation or modification of the request. The technician is warned with the following message:

A task has been generated for the attention of ????.

In this way, the sales representative will be warned instantly of the customer request directly via their normal workbench.
If no sales representative could be identified, the technician is warned by an error message.

This field indicates the date of the last manual or automatic assignment of the request.
When the request is closed, the closure date is automatically loaded as a function of the current date. The closed request is then found in the left list dedicated to the closed service requests. Different message confirm the closure of a service request.

Use this field to know the current progress of the request. Any modification to this field is recorded in the history of the request status. To view this history, go to Functions / Status history from the Actions panel.

This field indicates the coverage applied globally at the level of the service request.

When the global coverage is automatically defined, it represents an aggregation of the different coverages for the installed base concerned.

When the global coverage is manually defined, it applies to all the elements that make up the service request.

You can apply up to seven different types of coverage to a service request:

• Total coverage
  This coverage can only be assigned by the system. It is applied when all the installed base coverages are total.
• Partial coverage
  This coverage can only be assigned by the system. It is applied when at least one coverage for the installed base is either null, nor partial and at the same time the other coverages are partial or total.
• Request not covered
  This coverage can be automatically or manually assigned.
  In this last case, the phrase Coverage refused manually is used to identify clearly the wish of the user.
• Request covered by service contract
  This coverage can only be applied manually. As a rule, it is used to cover a request linked to a service contract that is different to that automatically selected by the system.
  Click the Contract to select the support contract for the new coverage of the request. A request using this type of coverage without contract number is considered as totally covered commercially.
• Request covered by sales order
  This coverage can only be applied manually. It is in general used to cover the request for a customer that has not subscribed to any contract or who doesn't have any contract adapted to the nature of their problem.
  Click Order to select the order used to cover the request. A request using this type of coverage without order number is considered as totally covered commercially.
• Request covered commercially
  This coverage can only be applied manually. Such a service request benefits from a free total coverage.
• Request covered by direct invoicing
  This coverage can only be applied manually. This request concerns the requests that cannot be covered by any contract linked to the customer. However, the customer has given their agreement for the invoicing of miscellaneous consumptions register for the processing of their request.

When a service request is commercially covered by an employee that does not exercise the function of commercial manager, an electronic alert message is automatically sent to the hierarchical manager.

Any modification of the global coverage will lead to :

• A recalculation of all coverages for the installed base concerned.
• A recalculation of the consumptions.

When the manually-applied coverage is not satisfactory, click Default coverage from the Actions panel is used to re-establish a default coverage calculated automatically for each of the elements that make up the service request.

Use this field to indicate the level of severity of the service request.
This information is used, for instance, to determine the date and time of the desired resolution in accordance with the quality constraints of the selected service contract.

This field indicates the date after which the customer issue must be resolved.
This field is always the object of an automatic qualification throughout the entry of the different fields that make up the service request.

When the request is not covered by a service contract, this date corresponds to the current date increased by the number of days contained in the global parameter QREAC - CS reactivity level (days) (HDK chapter, SRE group) set to 7 standard days.

If the request is covered by a service request, this date is loaded as a function of the quality constraints in the contract concerned.
If the problem is non blocking, the date is calculated from the Maximum resolution lead-time fields in the Non blocking problems section.
If the problem is non blocking, the date is calculated from the Maximum resolution lead-time fields in the Non blocking problems section.

This date can also be affected by a manual modification to the contract. In fact, the customer can be confronted by a specific situation that imposes more extended resolution lead-times than planned. The reasons for this extended lead-time can be described in the Reason field.

This field is used to indicate the contract used to respect the quality constraints.

This field indicates the reasons that have led to a manual modification to the "Desired resolution date" field.

The timestamp entry is used to enter the time devoted to the processing of a service request.
Each entry of a new timestamp triggers the calculation of the total time for the different timestamp entries, as well as the new consumption carried out.

The product, which is automatically consumed for this timestamp, is defined in the setup. (Products for timestamp)

Each timestamp can be entered manually. They can also be calculated automatically if you click Start timestamp from the Actions icon.

Each time a timestamp is triggered, it is automatically recorded if one of the following events occurs after one minute:

• Click End timestamp.
• Selection of another request in the selection panel.
• Click End.
• Creation of another service request.

The timestamp triggered from one of these three fields is related to the default installed base.

You can also click Start timestamp from the Actions icons available on each installed base concerned when the timestamp relates to a specific base.

The triggering of a timestamp is also the means to access specific operational features of the service request processing.

The Preferences action is indeed used to activate the access to a specific feature in the context of the service request.

The totals fields are automatically recalculated after each recording of a new timestamp.
They are used to measure the total time consumed by the service request process.

This field displays the code of the last escalation carried out for the service request.
If at least one escalation has been carried out for the service request, the "Escalation history" menu is active.
The category is displayed with regard to the escalation code in order to evaluate its severity.

This field indicates the date on which the escalation has been executed.

This field displays the type of the last escalation carried out for the service request.
The escalation can be of three types:

• Hidden: comparable to entry points, these escalations are used in the conditional execution of the specific/custom application code.
• Archived: identical to the first, these escalations load a history associated with the request.
• Incremental: these are allocated under the responsibility of an employee.

Code of the bill-to customer initialized by default with the bill-to customer code associated with the customer entered in the service request header.

This field is used to enter the paying customer code. It is initialized by default with the paying customer code associated with the customer entered in the service request header.

This field is used to enter the group customer code. It is initialized by default with the group customer code associated with the customer entered in the service request header.

The warehouse site specified in the request will be used as the default warehouse site for each new consumption related to a product generated in the stock.

This field is used to indicate any project code at the origin of the financial coverage of the service request. Its management depends on the value of the CTLOPPCOD - Mandatory project control parameter.

• When the value is 'No', it may be a code selected freely.
• When its value is 'Yes', a control of the project code entered is systematically performed. In the latter case, the code must have been previously defined at the level of the project management. It must be active — if it becomes inactive after creating the document, the control applies and the document line can no longer be selected on other documents, i.e. a quote line cannot be selected from an order.
  
  To enter the code, the user has two alternatives:
• The contextual menus ('CRM Project selection', 'BP selection', and 'Contact selection') are used to select a project amongst a list of filtered selection.
• The 'CRM projects' contextual menu is used to directly access the management function and perform a selection or create a project.

When the project code is modified, a dialogue box opens and suggests a recalculation of prices and discounts. The answer 'Yes' causes a price list search, based on the new project code, for all consumption lines.
The consumed amount is systematically updated; it corresponds to the net price returned by the price list search and multiplied by the quantity. The invoiceable amount is also updated but only when the line can be invoiced and if the invoiceable amount has not been modified manually.
During the price list search, the quantity used corresponds to the total quantities of all the invoiceable lines of one product.

This field is used to indicate the sales representative(s) to which any commission that will be posted related to the amounts consumed in the service request.
It is possible to enter up to two sales representative codes. From these fields, several options of the right-click contextual menu are available: "Selection" gives access to the list of sales representatives and "Representatives" is used to directly access the management function to perform a selection or create a 'representative' code in the table.

This information is used to indicate the tax rule for the document. This code is controlled in the tax rule table and is initialized by the corresponding code in the BP record. It can be modified.
This information is mandatory and remains accessible provided the delivery has not been confirmed.
Only a tax rule with a legislation and group that are consistent with those of the document can be entered.
The general principles linked to the multi-legislation setup are detailed here.

This currency is used to value all the financial elements in the service request.

This code defines the payment method the invoiced consumptions. It is initialized by the bill-to BP and is controlled in the payment condition table.

This information is entered in the quote and it is initialized by the discount code in the bill-to customer. It makes it possible to determine a series of early discount rates or late charges to be applied depending on whether the payment is early or late with respect to the due date.
Only a discount code consistent with the legislation and company group of the document site can be entered.
The general principles linked to the multi-legislation setup are detailed here.

If the quote involves a prospect, this information is not initialized.

The values relate to the invoicing footer. This information can directly come from the parameters of the invoice footer or from the customer record.
 Refer to the Invoicing elements documentation for more information.
The values of the footer elements can be modified. The ex-tax and tax-incl. amounts of the document are directly impacted by these values.
Intercompany specificities
If the order has been generated from an inter-company or inter-site purchase order, and the inter-company setup stipulates that the invoicing elements come from the Purchase module, these will be initialized with the values entered in the original purchase order.

Enter the code to use in order to override the default SST tax code from the product or invoice element. This tax code is recognized by Sage Sales Tax and is used to identify line types for tax purposes. This field is available only if the LTA - Local taxing activity code is activated, and the USATAX - Tax system user parameter is set to Yes.

For invoicing elements designated as the SST document discount for a company, you cannot remove the SST tax code value on the document.

This column is used to identify the installed customer base for which the consumption is carried out. This base MUST be chosen from amongst the customer installed base for the service request.
If no installed base has been entered and at least one installed base record has been entered in the request, then the consumption will be automatically assigned by default to the installed base record.
This information is used to evaluation at the level of coverage applicable to the consumption.

This column is used to specify the particular component for which a consumption is carried out.
This component must imperatively be chosen from the list of components declared defective for the customer installed base.
It is important to enter this information in order to benefit from an automatic evaluation of the coverage level to be applied to the most exact consumption.

this column is used to select the type of the consumption that has been entered. The type conditions the nature of the product reference authorized for the consumption.
It can be:

• spare parts or a complete product.
• labor or service provider,
• assignment expenses.

This information is automatically initialized with respect to the parameter DEFHDTTYP - Type of consumption / default (HDK chapter - SRE group).

This field is used to enter the product consumed. A contextual menu "Product Stocks" is used to access the stocks by product inquiry screen.

The major version number can be accessed if the tracking of major versions is active at the level of the product setup (in the Management tab of the Product function, the Stock version field is set to 'Major').

If the preloading of versions is active at the product/customer level (in the Customers tab of the Product function, the Version preloading box is checked), or by default, at the product/sales level (in the Sales tab of the Product function, the Version preloading box is checked), then the last active major version is preloaded automatically.

The major version number can be entered if, in the setup function of the Service requests (GESCMS) entry transactions, in the Consumptions tab,the Major version field is set to 'Entered'. If you enter a major version number, the system checks that the major version does exist and its status. If an error occurs, a warning non-blocking message displays.

The minor version number can only be accessed if the tracking of major and minor versions is active at the level of the product setup (in the Management tab of the Product function, the Stock version field is set to 'Major and minor').

If the preloading of versions is active at the product/customer level (in the Customers tab of the Product function, the Version preloading box is checked), or by default, at the product/sales level (in the Sales tab of the Product function, the Version preloading box is checked), then the last active minor version is preloaded automatically.

The minor version number can be entered in the following cases:

• if, in the setup function of the Service requests (GESCMS) entry transactions, in the Consumptions tab, the Major version field is set to 'Entered',
• and if the product is indeed managed in major version.

If you enter a minor version number, the system checks that the major version does exist. If an error occurs, a warning non-blocking message displays.

This field is only used for those items generated in stock.
The product-site MUST be created in the application in order to be consumed.

This field is used to enter the quantity consumed.

This field is used to enter the unit in which the consumption will be expressed. By default, the unit is qualified with the sales unit of the product consumed.
For journals, the various packing units can also be used.
For labor, it is possible to use one of the three time units specified in the product file (Days, Hours, Minutes).

This field is used for the labor consumptions.
The services can be carried out by either internal resources or by using external service providers.

If the consumption is carried out by an internal employee, this field must contain a user code.
If the consumption is carried out by an external service provider, this filed must contain the code of a service provider.

A consumption is either :

• To be carried out
• Planned
• Executed

This field is used to indicate the date on which the consumption has been planned.
If not execution or planning date have been entered, it is possible to plan the consumption using the contextual menu "Plan the consumption".

This field is used to indicate the date on which the consumption has been carried out. The entry of a date triggers the opening of an entry window for the stock issued, if the consumption concerns an item managed in stock for which a stock issue is requested.

This field is used to indicate the time at which the consumption has been carried out.

This field is qualified by default as a function of the "Stock issue by default" note in the product record.
It is the essential element of the stock issue for consumption lines of service requests: any consumption of entries managed in stock can be subject to a recording of stock issues from a service request.
The entry is triggered by the combination of a stock issue request and the status carrying out the consumption.
This field is therefore used to identify a stock issue for the consumption and to activate the opening of the entry window of stock issues.
For example, for the consumption of an item managed with serial numbers, the opening of the stock issue entry window makes it possible to select the serial numbers consumed.

 The stock issue for the consumptions does not correspond to a stock line allocation.

This field, which cannot be entered, is used to view the number of quantities to be issued to the line.

This field, which cannot be entered, is used to view the issued quantity for the consumption line.

This field determines the invoiceable amount for the consumption.

Reminder : a service request is only invoiceable if it is closed and it contains at least one invoiceable consumption. When the service request is closed, the phrase "Request pending invoicing" appears below the request status (management tab).

The invoiceable amount is qualified by default thanks to the different applicable coverage evaluation mechanisms. It can still be modified. Two general parameters influence the invoicing rules for the consumption lines:

• INVSREMOD - invoicing mode of requests (HDK chapter, INV group): activates the aggregation mechanisms.
• INVSREUOM - Invoicing Unit of requests (HDK chapter, INV group): describes the aggregation type desired (aggregation per sales unit or aggregation per consumption unit).

NB : An invoiceable consumption line containing a text is never aggregated during its invoicing. Also, the consumption lines share the different analytical dimensions are never aggregated.

This field is calculated again if the following elements of the consumption are modified:

• the installed base,
• the component,
• the product consumed,
• the consumed quantity,
• the unit used,
• the project (only if the user validates the price and discount re-calculation suggestion with a price list search based on the new project code, if the line can be invoiced, and if the amount has not been modified manually).

The general parameter CLOINV - Service request invoicing (HDK chapter, INV group) is used to neutralize all features related to the invoicing.

This field contains the amount consumed. It is always qualified by default thanks to the different applicable coverage evaluation mechanisms. It thus corresponds to the net price recovered by the price list search multiplied by the quantity; and can still be modified.

This field is calculated again when the following elements of the consumptions are modified:

• the installed base,
• the component,
• the product consumed,
• the consumed quantity,
• the unit used,
• the project (only if the user validates the price and discount re-calculation suggestion with a price list search based on the new project code).

 During the price list search, the quantity used to determine the consumed amount corresponds to the total quantities of all the invoiceable lines of one product.

This field is used to enter the amounts that will be picked up in the invoicing of the consumption lines. This field is modifiable.

This field is used to enter the currency that is used to value the consumption lines and that will be picked up in the invoicing phase.

In the case of multi-base requests, the consumptions covered financially can be mixed with consumptions covered by points.
This field is used to display the number of points debited by the consumption.

This field is used to complete the product reference with an explanatory text for the consumption carried out. It is generally used to detail the nature of the work carried associated with a product reference of the type Labor.
Example: in the vehicle domain, the phrase "Two hours of labor" could be followed by "Replacement of four tires".

It is possible to directly enter a text of up to two hundred characters in the grid. If the text to be entered is too long, the "Text" contextual menu is used to open an additional window in which the maximum text is controlled by the data type ACB.
 An invoiceable consumption line on which a text has been entered is never aggregated during the invoicing.

The setup determines if the analytical dimensions can be modified. They are initialized based on the setup of the default dimension.

In creation mode, if no order line has been entered and the project code is modified, the analytical dimensions are reset based on the setup of default dimensions.

In creation mode, as in modification mode, if an order line is entered and the project code is modified, the analytical dimensions are not reset.

This field displays the total number of points mobilized or consumed automatically by the service requests.
This total includes both the fixed debits and any additional debits associated with the different recorded consumptions.
The point debit is always an automatic operation. Nevertheless, in terms of the service request process, it is possible to modify the total debit calculated by the system.
A contextual menu "Manual points debit" is used to modify the total number of points that the request is to consume upon closing.

This field is only of interest in the case of service requests covered by different types of service contracts. In fact, in this case, some consumptions can be covered in a financial fashion whilst other are covered using point debits.
This field thus calculates the share of consumptions covered by points as compared to the global amount of consumptions.