Navigating and Creating Master Data in SAP Field Service Management

Business partners are any parties in which the company has a business interest. In Field Service Management, business partners most often refer to customers, but can also be of other types, for example, suppliers.

Business partner records include:

• Contact Person information
• Address information
• Skill requirements
• Price List

Multiple addresses can be registered, for example for billing, shipping, or service execution location purposes. Likewise, multiple contact persons can be registered.

Contacts generally represent the employees of a given business partner. Contacts can be linked to various objects, for example:

• Business partners
• Equipment
• Service contracts
• Service calls
• Activity

Customers may have unique skill requirements that are relevant to any service execution for that customer. Skill requirements from a business partner can be inherited down to linked service calls and activities. This way, the skill requirements can be used to find the best matching technician.

The address object is used to store information about a street address, postal address, or similar. If an address does not include a geolocation, FSM will automatically try to resolve the related geographic coordinates. This way each address gets its standard parent object, but can be referenced by certain working objects like activities.

Addresses can, for example, be linked to the following:

• Business partner
• Equipment
• Person
• Service call
• Activity

On the FSM database, addresses are linked to their parent object by the object reference. Other objects (for example an activity) can still refer to an address, even if the address itself has a different object reference (for example, an equipment).

Furthermore, addresses can be of different types, like "Home" or "Work" for persons, or "ShipTo" or "BillTo" for customers.

Items in FSM correspond to data like material masters, products, articles, or service items in the backend system. As such, they generally serve 2 purposes:

• Items can be the things being sold or used during service, for example consumable material, spare parts, or specific services
• Items can refer to what an Equipment is made of and may represent (generic) tools.

Items have prices based on price lists and stock levels by warehouse. Prices and stock levels are usually determined and updated through the underlying ERP. FSM does not have material management features. Therefore, stock levels are not automatically updated based on consumption or other material movements.

The item record contains the generic properties of the related service or tangible good. Items can be classified by using item types and item groups, and may also have name translations. Other properties include:

• inventoryItem flag
• managedByBatches flag
• managedBySerialNumbers flag
• purchaseItem flag
• salesItem flag

An equipment can be understood as an instance of an item. As such, the equipment inherits information from the related item, for example, the necessary skill requirements. In addition to the item-related information, an equipment has its own specific information, like an address and a serial number.

Field Service Management combines functional locations and equipment into the same database table, so each record in that table is referred to as an equipment. To distinguish between the different kinds, an FSM equipment can be assigned to a category, for example:

• Functional location
• Equipment
• IBASE

FSM equipment can be organized as part of a hierarchy. An equipment hierarchy can be created by drag-and-drop in the equipment list or by maintaining the 'parent' field in the equipment details. Equipment can have name translations and can represent specific (instances of) tools.

The person generally represents the employees, users, or sales employees of your company. Users need to have a person record in order to work with any of the Field Service Management applications (web UI, mobile). When set as a plannable resource, the person shows up as a technician on the planning board.

From this screen, several different kinds of information can be linked or maintained for the person:

• Skills
• Addresses
• Regions

The Person record plays an important role in FSM as Owner or Responsible other data records. For example, permissions to read or change data can be limited to the Owner of a data record. In many cases, the Owner or Responsible of a data record is set automatically by the system, but in some cases it can be explicitly defined using the UI. Here are some objects which can have an Owner or Responsible:

• Service calls
• Activity
• Time effort
• EMME records (effort, material, mileage, expense)
• Reservation
• Work time absence

A skill is an ability, qualification or property that a person can have, or vice versa, a requirement is the skill that a technician must have when working with specific objects. The UIs in FSM (for example, master data and dispatching board) commonly use the term 'skill', even when referring to a requirement. Skills are used in the Planning and Dispatching application to ensure activities are assigned to technicians with the best matching qualifications. In the skills module of the master data application, users can create, manage, and assign skills to persons. Person skills can have a specific validity period.

Requirements can be optional or mandatory. Requirements are inherited or propagated from one object to other related (child) objects. For example:

• Item requirement → equipment requirement
• Business partner requirement and equipment requirement → service call requirement
• Service call requirement → activity requirement

In this way, requirements for parent objects are automatically applied to the dependent child objects upon creation. Instead of needing to set requirements manually and separately for each activity, the requirements of the activity are the result of the propagation of requirements from the parent objects. Requirements can be added on any level, wherever needed.

In the Tools module of the Master Data Management application, users can create generic and serialized tools in the All Tools pane. A generic tool refers to the type of tool needed to perform an activity. A serialized tool is a specific instance of the generic tool, identified by its serial number. Generic tools are based on an Item record, whereas a serialized tool is based on / linked to an equipment record.

With work time patterns, you can create and apply scheduled working times to employees. In other words, this pattern defines when technicians are generally available for work to be assigned to them. On the Planning Board, the technicians' availability is depicted by the white spaces, as opposed to the greyed-out periods when the technicians are not available.

Work time patterns can be maintained in the Settings and Configuration section of the FSM UI. They can be general patterns that apply to multiple employees - for example, a shift, or they can be custom-made that apply to individual employees. A work time pattern consists of at least one week with a minimum of one defined working day. Persons can be assigned to multiple work time pattern records, as long as there is no overlap between the work time pattern assignments.

Instead of creating (master) data records one by one, the data loader application allows users to upload entire lists of new or updated records all at once. For each supported object type, a template can be downloaded that can be filled in offline, after which the file can be used for upload in the application. The data upload can be done by using CSV or Excel files. The application then creates, updates, or overwrites existing records based on the file data.

This functionality is intended for objects which are not covered by the integration to the back-end ERP system. While uploading, the data loader validates for errors, such as missing required fields and format inconsistencies.

To access the data loader, navigate to the Settings and Configuration section, and open the Master Data tab. There, start by selecting the desired object type.

As a second step, select any linked data or linked business object types that you want to include in the upload.

Now you can download a template that includes the fields necessary for the selections you have made before. The template can be in CSV or Excel formats, which you can edit offline using the applicable third-party software.

To import the updated file, use the UI button to select it from your local computer or drag-and-drop the file onto the corresponding area of the web page.

When you import a data file and records with the same (external) ID already exist in the system, you need to decide whether you want to merge or overwrite the existing data. When merging data, existing data fields will not be overwritten. When overwriting data, all fields of the pre-existing data record are erased and completely replaced with the data in the upload file.

Import Logic: When uploading data, the ID column of your data will be stored as the external ID in the database. At the same time, the application assigns its own internal ID to the records. Differences in logic between creating new records and updating existing ones are as follows:

• Create New Record: When creating a new record, the ID from the uploaded file template will become the externalId value in the cloud.
• Update Existing Record: When updating an existing record, the code and externalId are checked by the application to determine if a match exists.

Best practices when re-importing edited data using the data loader include:

• The re-importation of exported data that has been modified should be completed after hours (outside of business hours) in order to avoid data inconsistencies and performance issues in the desktop and mobile applications.
• It is recommended to maintain a copy of the original exported data file in order to be able to manually revert changes should issues occur with the modified set of records.
• Following the re-importation of data that has been modified, all mobile application users will need to resynchronize data.

This functionality allows you to export SAP Field Service Management master data for supported objects, for example:

• To backup data
• To use it in another tool
• For auditing/reporting purposes

The data exporter feature is used to export master data for the following data objects:

• Business partners
• Contacts
• Equipment
• Items
• People
• People - skills assignment

Additionally, the master data can be exported in order to perform master updates that are then imported back into SAP Field Service Management using the data loader tool.

Export Logic: When exporting the data, the external ID is displayed as the ID, and the internal ID of the record is not exported.

Data can also be exported using query API, data API, or possibly by using a customized Field Service Management report.