Learn about setup steps of the prefilled checklist customizing transaction.
Step 1. - Maintain mapping between checklist instance fields and SAP tables fields
Step 1.1. - Select a company ID and enter the ID of the template relevant for mapping.
Enter a specific template version or activate the ‘Latest template’ option.
Latest Template | Use the latest available template version. If you leave the template version empty, then this flag will be automatically checked. |
|---|
Step 1.2. - For all relevant checklist template fields, specify a corresponding structure (which reflects SAP tables) and the structure’s field.
(S4)PACG 200 SP09 In order to generate empty checklist instances, keep the ‘Fields mapping’ node empty.
Mapping between checklist instance fields and SAP ECC/S4 tables data can be maintained using the following provided structures:
Activity-related
S_E4C_ACTI | Table /PACG/ECM_ACTI, data of the activity to which the checklist instance refers to |
|---|
Equipment-related
S_EQ_OPER_EQUI | Table EQUI, the related operation’s equipment |
|---|---|
S_EQ_OPER_EQUZ | Table EQUZ, the related operation’s equipment |
S_EQ_SCALL_EQUI | Table EQUI, service order’s header equipment |
S_EQ_SCALL_EQUZ | Table EQUZ, service order’s header equipment |
T_MEASURE_PTS | Measuring points and documents of the operation’s equipment. If no equipment is found in the operation, equipment from the service order header is used. Equipment determination procedure can be overwritten by implementing BAdI /PACG/ECM_FILL_COMM_STR_ACT_EQ. |
Functional location-related
S_FL_OPER_IFLOTi | Table IFLOT, the operation’s functional location |
|---|---|
S_FL_SCALL_IFLOT | Table IFLOT, the service order header’s functional location |
Notification-related
Applicable for notification-based activities (notification no. filled in field QMNUM in table /PACG/ECM_ACTI).
S_NOTIF_QMEL | Table QMEL. the assigned quality notification |
|---|---|
T_NOTIF_ITEMS | The assigned QM notification’s items |
T_NOTIF_TASK | The assigned QM notification’s tasks |
(S4)PACG SP13 T_NOTIF_PARTNERS | All partners of a notification (tables IHPA, KNA1, PA0001). The notification number is taken from /PACG/ECM_ACTI-QNUM (the case when activities are created based on notification tasks) or if not found, from activity’s order’s header. This is a table structure, requiring mapping to table or series fields. |
(S4)PACG SP13 S_NOTIF_PARTNER_SH | Data of a SHIP-TO partner of a notification (table KNA1). The notification number is taken from /PACG/ECM_ACTI-QNUM (the case when activities are created based on notification tasks) or if not found, from activity’s order’s header. |
(S4)PACG SP13 S_NOTIF_PARTNER_SP | Data of a SOLD-TO partner of a notification (table KNA1). The notification number is taken from /PACG/ECM_ACTI-QNUM (the case when activities are created based on notification tasks) or if not found, from activity’s order’s header. |
(S4)PACG SP13 S_NOTIF_PARTNER_VW | Data of a PERSON RESPONSIBLE partner of a notification (table PA001). The notification number is taken from /PACG/ECM_ACTI-QNUM (the case when activities are created based on notification tasks) or if not found, from activity’s order’s header. |
Service/Maintenance order-related
T_SCALL_COMPONENTS | Service order components assigned to the specific operation |
|---|---|
T_SCALL_OBJLIST | Service order object list |
S_SCALL_OPERATION | Service order operation related to the activity |
S_SCALL_AFIH | Table AFIH, data of the related maintenance order’s header |
S_SCALL_AUFK | Table AUFK, data of the related order’s header |
(S4)PACG SP13 T_SCALL_PARTNERS | All partners of the service order related to a given activity (tables IHPA, KNA1, PA0001). This is a table structure, requiring mapping to table or series fields. |
(S4)PACG SP13 S_SCALL_PARTNER_SH | Data of a SHIP-TO partner of the service order related to a given activity (table KNA1) |
(S4)PACG SP13 S_SCALL_PARTNER_SP | Data of a SOLD-TO partner of the service order related to a given activity (table KNA1) |
(S4)PACG SP13 S_SCALL_PARTNER_VW | Data of a PERSON RESPONSIBLE partner of the service order related to a given activity (table PA0001) |
Object Picker
Object Picker fields can also be pre-filled in SAP ECC/S4. Information about relevant Object Type (e.g. Equipment, Business Partner) is retrieved automatically based on inbound checklist template data.
Keep in mind that information about Object Picker’s reference object is stored in SAP ECC/S4 starting from Service Pack 2 for Add-on 200. Checklist templates created before installation of this Service Pack should be resent from SAP FSM to SAP ECC/S4.
Moreover, please note that the field mapping should point to a table value which was sent to SAP FSM as the key of a given object, e.g. pointing to value ‘CHY' or ‘Jake Austin’ for a Person Object Picker will not work properly on the mobile app, ‘U/CHY’ should be used instead.
Location picker
(S4)PACG 200 SP09
Location picker can also be prefilled in checklist instances.
To construct such a picker, it is recommended to use method BUILD_LOC_PICKER_VALUE from class /PACG/ECM_CL_A_CHECKLIST_DATA. Inside the method you will find the following parameters:
Latitude (obligatory)
Longitude (obligatory)
Altitude
Altrefsys
Accuracy
More information about Location Picker can be found in FSM documentation https://help.sap.com/docs/SAP_FIELD_SERVICE_MANAGEMENT/fsm_smartforms/location-picker.html.
Additional mapping remarks
All structures and their fields (including technical details) can be viewed in structure /PACG/ECM_STR_CHKL_COMM.
Checklist template fields of type ‘long text’ (text input with multiple lines) should be mapped only with structure fields of type TLINE_TAB.
Table types in SAP should be mapped as checklist series or tables.
When filling in the drop-down, the user should use the value from the description or index field. To find out what descriptions/indexes are used, please check created values in the FSM Smartform and Feedback generator or look at the /PACG/ECM_CLTTD table where “Index” and "Description" field are located.
(S4)PACG 200 SP12 Multiple values are allowed for single drop-down element. To create such drop-down successfully it is necessary to separate every value by “;”. This approach is used in the FSM database.
Population of table within a series requires additional mandatory fields in the corresponding table type in the communication structure: 'INDEX_SERCT' and 'INDEX_TAB_ROW'. These fields indicate how many table rows goes into a particular series in the checklist instance.
Step 2. - Maintain at least one condition
Step 2.1. - Enter the condition’s name and description.
The conditions contain circumstances in which a checklist instance should be generated.
Step 2.2. - Maintain condition criteria
An example condition - checklist instances will be generated only if the activity’s service order’s plant number is between 1000 and 1200.
If no specific conditions are required, maintain only a generic condition name and description, without maintaining the sub-nodes. In such a case checklist instances will always be generated if technical conditions in node ‘Technical condition assignment’ are met.
Step 3. - Assign the conditions to the mapped checklist templates. Configure additional assignment options.
Step 3.1. - Enter the mapped template’s ID in the ‘Conditions assignment’ node.
Create a new entry with the mapped template’s ID. Mapped templates will be displayed on the search help list.
Step 3.2. - Specify additional technical assignment conditions
Click on the template ID entry and navigate to node ‘Technical condition assignment’. Enter the condition’s name (already created in the ‘Conditions list’). Make sure to check it as ‘active’. Only active entries will be used during checklist instance generation processing.
Other available options include:
Mandatory | If checked, a checklist instance will be sent with the ‘Mandatory’ property set. The checklist will be mandatory to filled on the mobile app during service execution.   |
|---|---|
Allow Duplication | Allow generation of multiple checklist instances for one activity. If the flag is set, it will not be checked if the checklist was already generated for a given activity and a new one will be generated after each activity update. Otherwise, only one checklist instance will be created for one activity. |
Exclude status | Generate a checklist instance only for the activity related to the first operation whose status is other than the one specified in this field. Only one checklist instance per service order can be generated. Leave this field empty, if checklist instances should be generated for all order operations' activities. Example Generate a checklist instance for the activity related to the first service order operation whose status is not 'Locked' (I0043).  |
1st operation only | Generate a checklist instance only for the activity related to the first operation. Only one checklist instance per service order can be generated. |
Measuring Point on | If checked, the checklist instance will be generated only if there is at least one active measuring point defined for the equipment assigned to the header of the service order.  |
Language source | Specify where the checklist's language should be determined from. 
E.g. if in field ‘Sold-to’ value ‘SP’ is entered, the language of the customer added to the service order as partner function ‘Sold-to-party’ will be used   The customer’s language should also be maintained in transaction /PACG/ECM_LANG. If no customer language is found, the first company language will be used. |
(S4)PACG 200 SP09 ReasAct | Reassign an existing checklist instance to a new technician after activity reassignment. If not enabled, new, duplicated checklist instances will be created after activity reassignment. This setting must be used in combination with the Business Rule SAMPLE - Update responsible person of all checklists linked to an activity when releasing the activity to technician activated. During activity saving, the /PACG/ECM_CLTDH table gets updated. Updated checklists won’t be resent, as the reassignment is done on the FSM side via the BR. That update will prevent generating new instances during outbound activity processing. When technicians are reassigned in SAP ECC/S4 (in service order), Business Rule Update responsible person of all checklists linked to an activity when changing technician on the SAP side (Extension of sample) must also be enabled, it can be downloaded below: For older FSM Cloud Conenctor versions the following work-around is possible: deactivate Business Rule SAMPLE - Update responsible person of all checklists linked to an activity when releasing the activity to technician. The new instance will still be generated for a new technician, however the old instance will remain 'assigned to the old technician', therefore either will be visible as read-only, or not visible - depending on the permissions of a given user group for the 'ChecklistIntance' object. |
Step 4. - Optionally maintain additional mapping configurations
Optionally, additional mapping configuration can be specified for each mapped field. Start by entering a mapping configuration name in node ‘Additional mapping config’. After saving, it will be available in node ‘Additional fields mapping’, field ‘AddMap’. FSM Cloud Connector doesn’t provide specific implementations (nor BAdI definitions), the additional mapping logic should be implemented locally by the Customer. Depending on an implementation, the mapping key and mapping value fields should be filled.
Example usage: mapping between checklist template drop-down fields and SAP notification fields (for the first drop-down value ['1' in additional mapping key], use the value from [additional mapping value]).