Service Requests

• Site (field SALFCY)

This field contains the code for the site from which the service request will be tracked.

• field SRENUM

This field corresponds to the main identifier of each service request.

Its generation is ensured by an automatic sequence number counter.
As this counter is automatic, you should not need to check the content of this field.

By default, this code is made up of a sequence number limited to 15 characters. In addition to this technical identifier, each service request can contain:

• an alphanumeric customer sequence number,
• and a chronological numeric customer sequence number counter (chrono).
  This numeric counter is always calculated automatically by the system. It is used to classify the requests by order of creation for a single customer or to detect potential deletions identified by the presence of gaps in the number sequence.

From the Actions icon, click Search by customer chrono to open the selection window of service requests, based on the customer and their sequence number counter (chrono).
When this window opens, it displays by default all the open customer requests that include a customer sequence number.

Click Service responses by request to inquire all the service responses planned for the service request.

• Customer (field SRENUMBPC)

In addition to the technical identifier, each service request can contain an alphanumeric customer seq. number and a numeric and chronological customer seq. number.

• The alphanumeric customer seq. number is used to record a short and intuitive reference number which can be easily communicated to a customer and used in later correspondence. Conversely, in some cases it is used to record the number under which the incident is managed within the customer's own organization.
   
  It can either be entered manually or determined automatically by the system, depending on the value of the parameter SRENUMAUT - Automatic customer seq. number (HDK chapter, SRE group): 
• If this parameter is set to Yes, this field cannot be accessed and is completely managed by the system.
  In this case, a customer seq. number is calculated automatically once a customer code is indicated in the request.
  Its content is defined with respect to the formatting rules defined by the parameter CHRSREBPC - Customer seq no. prefix length (HDK chapter, FMT group): for instance, if this parameter has for value "3", the first three characters of the customer code will be incremented. If this parameter is null, the generated sequence number will be completely numeric.
   
• If this parameter is set to 'No', this field can be freely entered by the user.

The contextual menu "Suggest a customer seq. number" is only available when the CHRSREBPC - Customer seq no. prefix length is strictly superior to zero. It is used to request the automatic generation of a sequence number with respect to the formatting rules of this parameter.

• A hidden technical field "Numeric and chronological customer sequence number" is present in the service request. Its contents can be viewed only from within the search window by customer seq. number. It is always determine automatically by the system and is used to class the requests by order of creation for a single customer or to detect any deletions by the presence of gaps in the number sequence. This numerical sequence number is automatically generated during the creation of a service request. Its structure depends on the setup of the service request sequence number counter. 

A contextual menu "Search by customer sequence number" triggers the opening of a window for the selection of the service requests on the basis of the customer and customer sequence number search criteria.
On opening, this window displays all the open customer requests containing a customer sequence number. It is also possible to exclude from the search the closed requests.
If only the customer code is entered, then all the requests containing a customer sequence number will be displayed. The Customer sequence numberis used to limit the list to only the requests where the sequence number starts with the entered value. For example, if the value M1 is entered, only the requests having a customer sequence number starting with M1 will be displayed.

A contextual menu "Service responses by request" is used to inquire all the planned service responses for the service request.

• Service caller (field SREDOO)

The notion of an order giver is relevant to the majority of companies that carry out a customer support activity. The true customers for these companies are the suppliers for the people who call.
In order to regularly invoice the service requests processed for the account from different order givers, it is indispensable to mention this information on each service request.
The requests that contain no information on this field are considered as being relative to the true financial customers for the company.

Definition of a default order giver :

To facilitate the management of calls, the customer support call centers frequently deliver a different telephone number for each order giver. In this way, for each incoming call, the order giver for which a service request must be process is often known in advance.

This field offers a functionality that is used to automate the contents of this field. In fact, in an After-sales technician knows that he/she will work for the nest three hours on the account for a specific order giver, a contextual menu is used to define the contents of this field for next request creations.

This contextual menu named "Define by default" saves the name of the order giver or the absence of the order giver as the next value by default for any request created by THIS USER until a new order is entered.

Selection of an order giver :

The contextual menu "Selection" associated with the "Order giver" field is used to:

- Select an order giver from amongst those defined in the business partner file if the customer field is empty.
- Select an order giver from amongst the suppliers for the customer entered in the service request.

• Customer (field SREBPC)

This field either indicates the code of the final customer or the customer code of the order-giver.
In both cases, the customer must be defined in the Customer function.

To select a customer code, click the Selection icon and:

• select a customer from all the customers defined for business partners if the order-giver field is empty,
• select a customer from all the customers of the order-giver related to a service request.

You can also use the Actions icon and click:

• Customer search to open the quick customer search window. This search method is recommended as it is highly efficient and offers the possibility to combine multiple search criteria. (Company name, Postcode, Town/city).
• Specify a customer site to complete the customer code with the address code for which an incident occurred. This is in particular useful if service responses at the site are required for processing the request. This information is also useful for narrowing the selection in the customer installed base to the specific base of the given address.
• Service response by customer to display all the planned and completed service responses for the customer, all service requests included.

• field ICOBPC

• Contact (relationship) (field SRECCN)

This field is used to save the identity of the physical individual who has issued the request.

• field SRECCNCLA

• field ICOSAT

• field ICOGRALEV

• Title (field SRETTR)

This field must contain a text that is used to understand in several words the nature of the request.

• field SREFULDES

This field is used to enter a full description either of the customer problem, or of the request for explanations or advice.
The following icons can be displayed to the right of the description of the service request:

• The first icon is displayed when the entered text exceeds 235 characters. It makes it possible to write a summary or overview of the description when the text to be entered is long (the maximum length of the entered text is conditioned by the HD1 data type).
  The general parameter ICOSYN -Overview to be written icon (CRM chapter, ICO group) is used to define the icon displayed. If no code is entered, the icon no. 71 is displayed.
   
• The second icon specifies that an overview has been written.
  The general parameter ICOSYNDON - Overview written icon (CRM chapter, ICO group) is used to defined the icon displayed. If no code is entered, the icon no. 117 is displayed

• field SREDESICO

• Date created (field CREDAT)

• Time (field CREHOU)

• Created by (field FULNAMUSR)

• Source (field SREORI)

• Document no. (field SREORIVCR)

• Line (field SREORIVCRL)

• field TSDCOD

Use these fields to enter the statistics group codes for the service contracts. Codes can be selected and initialized from the service contract template.

You can define up to 5 statistical groups. The number of groups and their names can be set up when installing the application. These groups are used in statistical processes and as selection criteria in many programs.

• field TYPMAC

Use this field to specify the method used to enter the installed base related to the service request.

• Use the Listed installed base option to specify, one by one, the relevant installed bases in the dedicated table (grid). This option is the preferred method for qualifying resolved service requests.
• Use the Filtered Installed base option to define a targeting in which all the characteristics of the base to be processed can be specified. Once the targeting has been created, the base table is automatically loaded with the resulting sample data. This option is the preferred method used for qualifying preventive or maintenance service requests.

Any modification to the entry method of the installed base leads to the complete deletion of the Baseand Componentgrids.

• Base filter (field MACFLT)

This field is the starting point for defining the targeting of the filtered installed base. From the Actions icon, click Targeting to access the inquiry window of Machine targeting types.

You then have two possibilities:

1 - Select an existing target to be included in the service request.

2 - Proceed with the definition of a new targeting that will then be included in the service request.

• Customer filter (field MACFLTINT)

In the very common case where the service request only concerns the base installed at the customer's, this option is used to over-ride one of the installation criteria of the base in the targeting definition.

In fact, if you select this option, only the customer installed base will be included in the service request.
When this is not the case, the installed base will rigorously correspond to the sample generated by the target.

• field NBMACSEL

• Base (field MAC)

Use this field to proceed with the successive entry of the different installed base records involved in the service request.
From the Actions icon, click:

• Selection and Installed base to perform a selection in a single customer installed base,
• Base selection to select an installed base record from the whole installed base described in the application.

Any entry of an installed base on a service request automatically leads to:

• the complete deletion of the contents of the grid containing the components associated with the current installed base,
• a coverage calculation applied to the selected installed base,
• a recalculation of the global coverage for the service request,
• the deletion or modification of all the consumptions related to the previous installed base.

The first installed base entered on the service request is automatically considered as the default base.

• Product reference (field ITM)

• Description (field ITMDES)

• Serial number (field SER)

• Quantity (field QTY)

• Base on loan (field LND)

• Skill (field PBL)

An installed base record can be associated to a skill group. The entry of a skill group automatically leads to:

• a recalculation of the coverage of the installed base concerned,
• a recalculation of the global coverage for the service request,
• a recalculation of consumptions.

• Description (field PBLCLA)

• Coverage (field COVFLG)

This field is used to modify the coverage applied automatically by the system.

• Coverage support (field COVSPT)

• Document no. (field COVVCR)

• Points debited (contract) (field PITMAC)

• Base by default (field MACDEF)

This column is used to indicate the installed base record that must be used by default in this service request.
This information is essential for the entry of consumptions. In fact, any consumption for which no installed base is specified is automatically assigned to the default installed base of the service request.

• Action regrouping (field ITNGRU)

This column is used to carry out groupings of the installed base records.
A grouping is carried out via the entry of an alphanumeric code on different installed base records.
These groupings are notable used to plan service responses. In fact, a contextual menu "Service Responses" available on each line in the installed base is used to plan the responses.
When a service response is created from this menu, it inherits all non-performed consumptions related to the installed base records sharing the same grouping code.

• Component (field CPNITM)

This field is used to indicate the component or component that is malfunctioning in the installed base.
Each component can be selected directly from the product base or from the after-sales BOM for the installed base concerned.
The contextual menu "After-sales BOM" is used to open the BOM for the installed base.

• Description (field CPNITMDES)

• Quantity (field CPNQTY)

This field is used to enter the quantity of components that can be found in the selected defective installed base.

• Coverage (field CPNCOVFLG)

This field is used to modify the coverage applied automatically by the system.

• Coverage support (field CPNCOVSPT)

• Document no. (field CPNCOVVCR)

• field SREPBLGRP

This field is used to indicate the skills group required for the processing of the service request.
In the case where several installed base records are mentioned in the installed base grid, two cases may arise :

1 - The skills group is entered : All the installed base records must share the same skill.
2 - The skills group is empty : each installed base record can contain its own specific skill.

Any modification of this information WILL lead to :

• A recalculation of the coverage for all the installed base and components records.
• A recalculation of the global coverage for the service request.
• A recalculation of the consumptions.

• field SREPBLCLA

• Assignment (field SREASS)

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.

• Assignment detail (field SREDET)

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.

• field SREDETCLA

• Assignment date (field SREDATASS)

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.

• Request status (field SRESAT)

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.

• field OVRCOV

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.

• field OVRCOVCLA

• Severity level (field SREGRALEV)

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.

• Requested resolution date (field SRERESDAT)

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 problemssection.
If the problem is non blocking, the date is calculated from the Maximum resolution lead-time fields in the Non blocking problemssection.

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.

• Time (field SRERESHOU)

• Support contract (field CONSPT)

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

• field CONSPTCLA

• Reason (field SRERESREN)

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

• field TITBLK

• field TITDAY

• field TITHOU

• field TITMNT

• field TITSPG

• field TIMSPGDAY

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.

• field TIMSPGHOU

• field TIMSPGMNT

• field TITCSPG

• field CTIMSPGDAY

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.

• field CTIMSPGHOU

• field CTIMSPGMNT

• Code (field SREESCNUM)

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.

• field SREESCCAT

• Date (field SREESCDAT)

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

• Time (field SREESCHOU)

• Type (field ESCTYPCLA)

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.

• Bill-to customer (field SREBPCINV)

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.

• Pay-by (field SREBPCPYR)

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.

• Group customer (field SREBPCGRU)

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.

• Storage site (field STOFCY)

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.

• Project (field SREPJT)

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.

• field SREREP

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.

• Tax rule (field SREVACBPR)

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.

• Entity/Use (field SSTENTCOD)

• Rate type (field SRECHGTYP)

• Price type (field SREPRITYP)

• Currency (field SRECUR)

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

• Payment term (field SREPTE)

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.

• Settlement discount (field SREDEP)

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.

• Dimension type (field DIE)

• Description (field NAMDIE)

• Dimension (field CCE)

• No. (field NOLIG2)

• Description (field SHO)

• % or amount (field INVDTAAMT)

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.

• field INVDTATYP

• Curr. (field WWCUR)

• SST tax code (field SFISSTCOD)

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.

• Base (field HDTMACSRE)

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.

• Component (field HDTCPN)

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.

• Consumption type (field HDTTYP)

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).

• Consumption (field HDTITM)

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

• Major version (field ECCVALMAJ)

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.

• Minor version (field ECCVALMIN)

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.

• Storage site (field HDTSTOFCY)

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.

• Quantity/Duration (field HDTQTY)

This field is used to enter the quantity consumed.

• Unit (field HDTUOM)

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).

• Provider type (field HDTAUSTYP)

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

• Provider (field HDTAUS)

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.

• Description (field HDTAUSCOD)

• Planned date (field HDTPLNDAT)

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".

• Date executed (field HDTDONDAT)

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.

• Time executed (field BHDTDONHOU)

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

• Stock issue (field HDTSTOISS)

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.

• Quantity to issue (field HDTISSQTY)

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

• Quantity issued (field HDTISSISS)

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

• Billable (field HDTINV)

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.

• Amount consumed (field HDTAMT)

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.

• Amount to invoice (field HDTAMTINV)

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

• Currency (field HDTCUR)

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.

• Points debited (field PITHDT)

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.

• Text (field HDTTEX)

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.

• Consumption chrono (field HDTNUM)

• Action Chrono (field ITNNUM)

• field CCE1

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.

• Labor (field TOTSVC)

• Parts (field TOTPDT)

• Project expenses (field TOTEXS)

• Consumed (field TOTCSM)

• Billable (field TOTINV)

• field PRCINV

• Not invoiced (field TOTNOTINV)

• field PRCNOTINV

• Consumed (field TOTPIT)

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.

• Part (field PRCPIT)

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.

• Date (field INVDAT)

• Amount - tax (field INVAMT)

• Document no. (field INVVCR)

• Date (field DUDDAT)

• Amount + tax (field DUDAMT)

• Dispute (field DUDDPTCOD)

• Open item no. (field DUDNUM)

• Date (field PAYDAT)

• Amount + tax (field PAYAMT)

• Payment no. (field PAYNUM)

• Open item no. (field PAYDUDLIG)