Worker Security with Transaction Type Download

This integration downloads worker and associated assignment data based on an effective key of Security ID (SID) and includes the “Transaction Type” logic (i.e. Hire, Update, Terminate, Rehire). This version of the download pulls multiple records per worker where the worker is associated to more than one cost center, task code, and/or rate, with each individual record showing a unique combination of those fields.

Connector Overview

Component	Detail
Company Type	Buyer
Version Type	1.0 – Original version. 2.0 – Pulls data starting at Work Order “Activation” step.
Format	CSV
Prerequisites	Workers Work Orders
Predecessors	N/A
Related Connectors	Worker Security with Transaction Type Single Line Download

Process Workflows

High Level Buyer Connectivity

The following connectivity workflow diagram shows at a high-level process driven integration points for this project. Numeric steps are correlated to the integration point workflow.

Diagram showing the integration point workflow

Integration Points

The following integration points diagram shows the interaction to exchange, transform, and load information between SAP Fieldglass and External Systems.

Diagram showing the flow of information from SAP Fieldglass and External Systems

Transaction Type Process

This download pulls worker information and identifies them as a Hire (HIR), Update (UPD), Rehire (RHI), or Termination (TER), for consumption by the customer’s external system. Once the worker has been successfully loaded to the external system, a return file with the SAP Fieldglass Worker ID and External Person ID (which loads into the native “Buyer Reference” field) will be loaded into SAP Fieldglass to build a link between the two system and enact the “Transaction Type” logic. This logic works to identify the state of the worker and acts as the primary indicator for the External System of a given individual’s work status.

HIR = Hire – Worker is hired initially.

UPD = Update – Active worker is updated.

TER = Terminated – Worker is terminated. If terminated with a future end date, transaction is sent at the time of action.

RHI = Rehire – Worker is rehired. Previously termed work order assigned to a new work order, or an existing work order is re-opened.

The uniqueness of the worker is carried through using Security ID, and the External Person ID is carried through using Buyer Reference field.
The Buyer Reference field should always be populated when the worker exists in the external system.
Any time after the initial load, a new worker without a buyer reference will be deemed as HIR; however, in subsequent downloads where the worker is updated and still has no buyer ref., it will be set to blank.

(Optional) Buyer Reference Script

To fast-track the “Rehire” process and have the buyer reference field pre-populated with the last-known External Person ID before the next download, an optional backend script can be enabled within SAP Fieldglass (contact support to do so). Below are some notes on the script:

The script executes when the initial work order is created within the application.
When the Worker or Profile worker is ‘Selected for Hire’ in the application the buyer reference field is copied forward to the new assignment if a match is found, based on Security ID.
A Warning message is presented to the user in the event that no match can be found.

Diagram showing the transaction type workflow

Download Selection Criteria

The following information outlines how the download selection logic works with regards to pulling information related to each unique worker based on Security ID. The terms 'worker' and 'assignment are used generically here, with the former referring to a given worker person, by Security ID, and the latter referring to the associated data that outlines the work period, cost allocation, etc. The actual data that is downloaded pulls from the worker/work order records (contingent/services) and profile worker records in the application. Profile workers do not have a separate assignment-related object. All information is contained within the profile worker record itself; however, the logic outlined below still applies, as if they are separate.

General Logic

A worker can be on many assignments, across the Contingent, Services, and Profile Worker modules in SAP Fieldglass. This download pulls data for only one of those assignments at a time, no matter how many or what types a worker is associated with.
The data pulled throughout the tenure of a given worker is designed to be a rolling indication of when that worker starts, on the first assignment, and when the worker ends, on the final assignment. If there are no more open assignments and the final (or only) assignment is closed, the worker record is downloaded as ‘Closed’ based on this final assignment.
In order for the download to transition from one assignment to the next, the currently-referenced worker must be explicitly closed, not just have the end date pass (i.e. “expire”). If there’s an update to an assignment that is “expired”, the update triggers data to be sent in relation to that “expired” assignment. Refer to Assignment Section Continues section below for more information.

Assignment Selection Conditions

Assignment data is pulled in the download as soon as a Security ID is available, meaning a record containing only the assignment data, with a status of ‘Pending’ and no associated worker record, is possible.
The download always seeks to pull an active assignment with the earliest start date.
If a second assignment is created with a start date prior to that of the first assignment, an update comes through on the subsequent run of the download with the data from that second assignment. However, if the start date is later than the start date from the first assignment, this does not pull through immediately. It may come through later, depending on the conditions at that time.
If the first assignment “expires” (i.e. the end date passes), but it is not closed, while the second assignment with a later start date exists, any updates to the worker continues passing the data for that expired assignment.
If the first assignment is closed and its end date passed but the second assignment is not closed, data comes from the second assignment, i.e. the next available non-closed assignment with the earliest start date. A status change to ‘Closed’ is not passed while there are active assignments.
If the second assignment closes while the first assignment with the earliest start date is expired but still not closed, the worker record does not pass any data and hence the status change to the second assignment is not passed.
When there are no more open assignments and/or the final (or only) assignment for the worker is closed, then the worker record is downloaded as ‘Closed’ based on the assignment with the latest start date.

If both the first assignment with the earliest start date is closed and the second assignment with the later start date are closed between download executions, the most recently closed worker record with the latest closed time passes on the download and as ‘Closed’.
If a worker record is already downloaded as closed for an assignment and later a second assignment is created, then the download passes the worker record based off the second assignment. The client’s security system may decide, based on the elapsed time between the close of first assignment and start of second, whether to assign the worker a new identity/access ID or reuse the existing identity/access ID.

Assignment Revision Selection Conditions

When an assignment is under revision or revised, the worker record is downloaded with the assignment revision data included. If an assignment revision is then rejected or declined, the worker record comes through again and reflects data from the prior confirmed assignment.
For a worker on multiple assignments, the available revision data is used for assignment selection based on the same rules described above for the assignment selection conditions.

File Formatting

The following table outlines the fields in the Worker Security with Transaction Type Download along with the properties of each and the additional required customization.

Column #	Column Header	Data Type	Length	Description/Use/Field Rules	Sample Value
1	Security ID	Text	100	Unique identifier for a candidate when the supplier submits the candidate against a work order.	Example: 123456789
2	Job Seeker ID	Text	16	Internal SAP Fieldglass ID for Job Seeker. Tied to the work order. A worker can have many Job Seeker IDs.	Example: ABCDJS00000123
3	Worker ID	Text	16	Tied to the work order. A worker can have many Worker IDs. Will be blank if the record is downloaded from the work order Populated when the worker registers.	Example: ABCDWK00000456
4	Person ID	Text	24	Unique identifier for the worker as a person Will be blank if the record is downloaded from the work order Populated when the worker registers.	Example: Z99970916332361611234cc4
5	Status	Text	100	The status is set based on the following: pending: wo created pending: wo accepted closed: wo rejected closed: wo declined activated: wo activated active: worker confirmed active: worker revised active: wo revised closed: wo closed closed: worker closed Rule: Filter out Pending and Activated statuses	Example: Active
6	First Name	Text	200	First name	Example: John
7	Last Name	Text	200	Last name	Example: Smith
8	Worker Email	Text	100	Workers e-mail address	Example: JSmith@abcd.com
9	Job Posting Title	Text	100	Job posting Title	Example: Accountant
10	Work Order ID	Text	16	Work Order ID	Example: ABCDWO00000789
11	Work Order/Work Order Revision Owner	Text	100	Work Order owner name	Example: John Jones
12	Work Order/Work Order Revision Owner Employee ID	Text	50	Work Order Employee ID	Example: D099999
13	Business Unit Code	Text	100	Business unit code	Example: 2002
16	Business Unit Name	Text	100	Business unit name	Example: Best Business Unit
15	Vendor Number	Text	6	Supplier code	Example: 1234
16	Vendor Name	Text	200	Supplier name	Example: ACME Vending
17	Buyer Code	Text	6	Buyer Company Code	Example: 4500
18	Remit To Address Code	Text	100	Code as assigned to the RTA by supplier	Example: 6R99
19	Cost Center Name	Text	200	Cost Center Name	Example: Accounting
20	Cost Center Code	Text	200	Cost Center Code	Example: 2002
21	Task_Name	Text	100	Task Name	Example: Hours Worked
22	Task_Code	Text	100	Task Code	Example: 5678
23	Billable Per Diem	Decimal		Billable Per Diem	Example: 75.00
24	Start Date	Date		Work order start date. Valid format is: yyyy-mm-dd	Example: 2016-08-10
25	End Date	Date		Work order end date. Valid format is: yyyy-mm-dd	Example: 2016-08-10
26	Currency	Text	100	Currency designation (ex. USD)	Examples: USD EUR
27	Site Code	Text	100	Site code	Example: 1234
28	Site Name	Text	100	Site name	Example: Naperville
29	Rate Category/ UOM	Text	12	Rate category and rate unit of measure	Example: ST/Hr OT/Day
30	Bill Rate	Decimal		Bill rate for the Rate Category	Example: 45.16
31	Pay Rate	Decimal		Pay Rate for the Rate Category (Populated for buyer downloads when buyer has access to supplier pay rate data, otherwise this field will be defaulted to 0)	Example: 40.00
32	Worker Supervisor	Text	100	Username of worker’s supervisor	Example: Tom Greene
33	Closed Reason	Text	100	Reason for closing worker	Example: Breach of Contract
34	Buyer Reference	Text	100	Native Buyer Reference on the Worker. Contains External Person ID.	Example: C5999999
35	Transaction Type	Text	3	Send based on when the user took the action in SAP Fieldglass vs when it is effective. So, if a future close action is taken today we would send a TER trans type with the future end date. The following are possible values: HIR — Indicating brand new contingent worker. Rule: Status is Active and Buyer Reference is Blank UPD—Indicating a change to the existing contract of a contingent worker Rule: Status is Active and Buyer Reference is not Blank and is not a rehire. RHI – Indicating this is an existing worker on a new assignment Rule: Status is Active and Buyer Reference is not Blank and there is a previous Work Order in TRM status, and no other work orders are active during the same window. TER — Indicating a termination Rule: Send when the Action to Close is taken: User Closed in a future date Auto-Close after end date Please reference Transaction Type Process for further details.
36	Worker Country of Origin	Text	3	Indicates worker's country of origin. Company configurations Security ID format by worker country of origin and Security Information must be enabled.	Examples: GER USA
37	Time Zone	Text	100	Time zone of worker. If not entered, it is defaulted to the default setting of the buyer's time zone.	Examples: GMT-06:00 Central Time (US & Canada) GMT-05:00 Eastern Time (US & Canada) GMT Greenwich Mean Time.
38	Work Location Name	Text	100	The location name. Enable at least one sub-configuration for the company configuration Use multiple locations. If the download’s parameters pull a document with multiple locations, the row is repeated with the exact same information in all columns except the location columns. There will be as many duplicated rows as there are number of locations on the time sheet.
39	Primary Location Code	Text	100	Indicates primary location code when at least one sub-configuration for the company configuration Use multiple locations is enabled. Client must configure the download to include this field via the Enabled Fields +Add Native Fields hyperlink.
40	Location Code	Text	100	The location code. Enable at least one sub-configuration for the company configuration Use multiple locations. If the download’s parameters pull a document with multiple locations, the row is repeated with the exact same information in all columns except the location columns. There will be as many duplicated rows as there are number of locations on the time sheet.
41	Primary Location	Text	100	Indicates the primary location name when at least one sub-configuration for the company configuration Use multiple locations is enabled. Client must configure the download to include this field via the Enabled Fields +Add Native Fields hyperlink.
42	Original Revision Start Date	Date			This optional field returns the Start Date from the original work order, regardless of what revision the work order is currently on.
43	[c] Custom Fields	Dependent on custom field configuration.		Custom fields include: Worker Statement of Work SOW Revision SOW Worker	Example: [c] VISA number

Work Order and Transaction Type Scenarios

The following graphic shows the various work order and transaction type scenarios.

Diagram of work order and transaction type scenarios

Assumptions/Tips

The system includes any inactive cost centers associated with the document.