This section explains how employee transactions and work orders from Solumina can be brought into Shop Floor Time.
Solumina sends Shop Floor Time an XML document called a BOD (Business Object Document) with real-time transactions or work orders. The transactions will be marked as online or offline transactions.
For online transactions, a synchronous Web Service moves this data to the Interface In Queue tables in Shop Floor Time. Shop Floor Time converts the data based on a specific Import Definition, placing the converted data into the In XML Queue tables. Shop Floor Time processes the data and sends a response document (ConfirmBOD) back to Solumina with the results. After the transactions are posted successfully from Solumina, you will need to run the LABOR_ALL_MT service in Shop Floor Time for the transactions to appear in the timecard.
For offline transactions, the Web Service will move the data to the Offline Data Queue in Shop Floor Time. The TERMINAL_MONITOR and OFFLINE_DATA_PROCESSOR services monitor and update the status of the Solumina Web Service terminal and process the records. Shop Floor Time sends a response document (ConfirmBOD) back to Solumina with the results.
Best Practice for Solumina Data Collection
If you are using Solumina to collect punch transactions, you should only use Solumina to collect these transactions. Do not use both Solumina and Shop Floor Time to record clock-ins, clock-outs, and labor. Errors may occur if the Solumina system goes offline but the Shop Floor Time terminals continue to record online punches, causing transactions to be out of sync. You can configure Shop Floor Time to use multiple data collection systems. However, this configuration can only help reduce the problem of out-of-sync punches when collecting data from two systems; it will not eliminate the problem completely.
See Also:
Configure the Import Definitions
Configure the Interfaces on the Distribution Model Form
Configure the Future Post Tolerance Settings
Configure the Solumina Request Document
Send the Solumina Data to Shop Floor Time
Updating the Quantity of Posted Transactions
Solumina sends Shop Floor Time an XML document called a BOD (Business Object Document) with real-time transactions or work orders. Shop Floor Time processes the data and sends a response document (ConfirmBOD) back to Solumina with the results.
The following BODs are supported:
Request BOD
ProcessEmployeeWorkTime - Used by Solumina to send real-time transactions and quantity changes to Shop Floor Time.
SyncWorkOrder – Used by Solumina to send work orders to Shop Floor Time.
Response BOD
ConfirmBOD – Used by Shop Floor Time to send a response to Solumina for one of the above requests.
You will need to make a copy of the SOLUMINA_MFI Interface Host and configure it for your Solumina system.
On the Interface Host form, select the SOLUMINA_MFI record and click Copy.
Change the Host Name to SOLUMINA_<Shop Floor Time Name in Solumina>, where <Shop Floor Time Name in Solumina> is the name of the Shop Floor Time system configured in the Solumina system. For example, if the Shop Floor Time system in Solumina is named KASG, then the Host Name should be SOLUMINA_KASG.
For the Host Type, select Sender.
In the Login Name and Password fields, enter the Login Name and Password that the Web Service can use to log into the Solumina system.
You will need the Host Name, Login Name, and Password when you create the request BOD that will be used to send transactions or work orders from Solumina to Shop Floor Time.
Click Save when you are done.
Import Definitions will be used to process the Solumina BODs.
The WSOAGIS_PROCESSEMPLOYEEWORKTIME Import Definition processes the ProcessEmployeeWorkTime BOD, which Solumina uses to send real-time transactions and quantity changes to Shop Floor Time.
The WSOAGIS_SYNCWORKORDER Import Definition processes the SyncWorkOrder BOD, which Solumina uses to send work orders to Shop Floor Time.
You will need to duplicate and configure these Import Definitions as explained below.
The WSOAGIS_PROCESSEMPLOYEEWORKTIME Import Definition processes the ProcessEmployeeWorkTime BOD. This Import Definition uses the Processemployeeworktime import context which has the same fields available as the Action import context.
You will need to map the Solumina Sign On Types to the appropriate events in the Import Definition for ProcessEmployeeWorkTime.
Make a copy of the WSOAGIS_PROCESSEMPLOYEEWORKTIME Import Definition and then modify the copy as explained below.
On the Import
Definition form, click the 
quick link icon next to the Import Name field and select Maintain.
On the Import Source pop-up form, select the WSOAGIS_PROCESSEMPLOYEEWORKTIME Import Name and click Copy.
Change the Import Name and click Save.
On the Import Definition form, select the copy of the WSOAGIS_PROCESSEMPLOYEEWORKTIME Import Definition that you just created.
On the Destination Records tab, modify the PING record to specify the GID and DID of the Solumina Web Service terminal. The GID and DID are defined on the Terminal form. The PING record indicates which Solumina terminal will be sending transactions via this Import Definition. If you have more than one Solumina terminal, you need to add a PING record to the Import Definition for each one.
Click the Source Fields tab.
Go to the Source Alias column and select the record for the event you want to map. For example, if you want to map a different Clock Event, select the record with FI_CLOCK_EVENT_NAME as the Source Alias.
With the record still selected, click the Field Translation tab.
Modify the record so that the Destination Value is the Shop Floor Time Event Name you want the system to use when someone posts the corresponding Sign On Type in Solumina. Make sure the correct Source Value is used also.
The table below shows the Shop Floor Time Source Alias and Source Value to use for each Solumina Sign On Type.
Save your changes.
Note: If you have a Work Order event with the COLLECTION_TYPE setting of Multi, you will need to make some additional configuration changes.
Shop Floor Time Source Alias |
Field Translation Source Value |
|
ATTENDANCE |
FI_CLOCK_EVENT_NAME |
[%CLOCK%] |
PROJECT |
FI_PROJECT_EVENT_NAME |
[%PROJECT%] |
WORK_ORDER |
FI_WORKORDER_EVENT_NAME |
[%WORKORDER%] |
LUNCH |
FI_LUNCH_EVENT_NAME |
[%LUNCH%] |
ACCOUNT |
FI_ACCOUNT_EVENT_NAME |
[%ACCOUNT%] |
If you have a Work Order event with the COLLECTION_TYPE setting of MULTI, you will need to make some additional configuration changes so that the Work Order event will post as a Multi Labor.
On the Import Definition form, select the copy of the WSOAGIS_PROCESSEMPLOYEEWORKTIME Import Definition that you created earlier.
Click the Destination Records tab.
Select the Record Name of WORKORDER.
Go to the Record Value Map tab and add the following records:
Field Name = Collection Type - F_COLLECTION_TYPE
Field Value Type = Static
Field Value = MULTI
Field Name = Command use in the prompt - F_PROMPT_COMMAND
Field Value Type = Static
Field Value = SAVE
Field Name = Stop Labor - F_STOP_LABOR
Field Value Type = Condition
Field Value = <#if (FI_STAGE)?has_content && FI_STAGE == 'E'>Yes</#if>
The WSOAGIS_SYNCWORKORDER Import Definition processes the SyncWorkOrder BOD, which Solumina uses to send work orders to Shop Floor Time.
Make a copy of the WSOAGIS_SYNCWORKORDER Import Definition and then modify the copy as needed.
If you want to make sure that numeric values such as Labor Standard Hours and Setup Standard Hours are imported with the right decimal precision, use the duration_to_decimal_hours_precision (ISO_8601 Duration to decimal hours with precision) Field Format to specify the precision amount.
On the Distribution Model form, find the records with Interface Name Process and Sync and the Sender Name SOLUMINA_MFI.
The records with an Interface Name of Process handle the ProcessEmployeeWorkTime BODs while the records with an Interface Name of Sync handle the SyncWorkOrder BODs.
Duplicate the Process and Sync records that have a Sender Name of SOLUMINA_MFI and change the following information:
Change the Sender Name of both the Process and Sync records to the one you created on the Interface Host form.
Change the Import Name for the Process record to the Import Definition that was duplicated from WSOAGIS_PROCESSEMPLOYEEWORKTIME.
Change the Import Name for the Sync record to the Import Definition that was duplicated from WSOAGIS_SYNCWORKORDER.
Sometimes the Solumina server and the Shop Floor Time server may not be in sync (for example, the time on the Solumina server is 09:00:01 and the time on the Shop Floor Time server is 09:00:00). If this occurs, a punch transaction from Solumina may be interpreted as a future posting in Shop Floor Time and generate an error. To help prevent these errors, you can configure a Future Post Tolerance that allows transactions with a future timestamp to be posted as current transactions.
These settings are located on the Interface form, on the Transaction Param tab. Select the Process interface. On the Transaction Param tab, modify the FUTURE_POST_TOLERANCE_SECONDS and FUTURE_POST_TOLERANCE_RESOLUTION settings.
These parameters will only be used if the event is a punch transaction and it has the FUTURE_POST Event Setting set to Disallowed.
FUTURE_POST_TOLERANCE_SECONDS is the threshold in seconds for a future timestamp on a Solumina transaction. If the timestamp is no more than this number of seconds past the Shop Floor Time server time, the transaction will be accepted. Its timestamp will either stay the same or change to the Shop Floor Time server time, depending on the FUTURE_POST_TOLERANCE_RESOLUTION parameter.
For example, if FUTURE_POST_TOLERANCE_SECONDS is 60 and the Shop Floor Time server time is 08:00:00, a Solumina punch with a timestamp of 08:00:55 will be imported without an error (its timestamp does not exceed the FUTURE_POST_TOLERANCE_SECONDS of 60). If FUTURE_POST_TOLERANCE_SECONDS is 30, then the 08:00:55 Solumina punch will generate an error because it is too far in the future (it exceeds the FUTURE_POST_TOLERANCE_SECONDS of 30). Likewise, if FUTURE_POST_TOLERANCE_SECONDS is 60 and the Shop Floor Time server time is 08:00:00, a Solumina punch with a timestamp of 08:02:00 will generate an error because it is too far in the future (exceeds the FUTURE_POST_TOLERANCE_SECONDS of 60).
FUTURE_POST_TOLERANCE_RESOLUTION determines whether the Solumina transaction with the future timestamp – that is within the FUTURE_POST_TOLERANCE_SECONDS parameter – will keep its existing timestamp or change its timestamp to match the Shop Floor Time server time.
Set this parameter to CLIENT if you want the imported transaction to keep its existing timestamp. Set this parameter to SERVER if you want the imported transaction's timestamp to change to match the Shop Floor Time server time.
For example, FUTURE_POST_TOLERANCE_SECONDS is 60 and the Shop Floor Time server time is 08:00:00. The Solumina punch has a timestamp of 08:00:55. The transaction will be imported without an error because its timestamp does not exceed the FUTURE_POST_TOLERANCE_SECONDS of 60. The FUTURE_POST_TOLERANCE_RESOLUTION parameter determines what the Solumina punch's timestamp will be. If FUTURE_POST_TOLERANCE_RESOLUTION is set to CLIENT, the Solumina punch's timestamp will remain at 08:00:55. If FUTURE_POST_TOLERANCE_RESOLUTION is set to SERVER, the Solumina punch's timestamp will change to 08:00:00 to match the Shop Floor Time server time.
By default, the WEB_SERVICES "secure" Application Setting is set to True, meaning the Login Name and Password defined in the Interface Host form must be used when communicating with Solumina. You defined these values earlier in the Configure the Interface Host section.
When you create the request BOD that will be used to send transactions or work orders from Solumina to Shop Floor Time, you need to include this Login Name and Password in the Header section of the document. The Login Name needs to be in the following format: <HOST_NAME>/<LOGIN_NAME>.
In the example below, the Host Name is SOLUMINA_KASG and the Login Name is WAT_USER. The Password is WAT_PWD.
<soapenv:Envelope xmlns:ns="http://www.openapplications.org/oagis/9"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken
wsu:Id="UsernameToken-1">
<wsse:Username>SOLUMINA_KASG/WAT_USER</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">WAT_PWD</wsse:Password>
<wsse:Nonce
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">rLO1GNdQR26hWRRxNU9H7g==</wsse:Nonce>
<wsu:Created>2018-05-30T13:18:20.912Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
When you post a transaction in Solumina, Solumina will generate a ProcessEmployeeWorkTime BOD and send it to Shop Floor Time using a synchronous Web Service. Similarly, when you create a Work Order in Solumina, Solumina will generate a SyncWorkOrder BOD and send it to Shop Floor Time using a synchronous Web Service. When Shop Floor Time receives the data, Shop Floor Time will immediately process the data and return a ConfirmBOD BOD to Solumina using the same Web Service, with either a success or error message.
In order for transactions posted in Solumina to display in the Shop Floor Time timecard, you must run the LABOR_ALL_MT service in Shop Floor Time.
When a work order is created in Solumina and sent to Shop Floor Time, the work order will automatically display in Shop Floor Time, without having to run any services.
An employee can modify the quantity of a transaction that has already been sent from Solumina and posted in Shop Floor Time.
Only the quantity of the transaction can be modified; no other values can be modified.
When Solumina sends an updated quantity value to Shop Floor Time, Solumina will send a value for OperSignOnVarChar5 in the following XPath of the ProcessEmployeeWorkTime BOD:
ProcessEmployeeWorkTime/DataArea/EmployeeWorkTime/UserArea/ibts:UserConfigurableFields/ ibts:UserConfigurableIdentifier[@name=”OperSignOnVarChar5”]
When this value is provided, it will be mapped to the FI_ACTION_ID Source Alias of the WSOAGIS_PROCESSEMPLOYEEWORKTIME Import Definition. This value corresponds to the Action ID of the transaction and will indicate whether the record is a new transaction being posted or a quantity adjustment for an existing transaction.
If the FI_ACTION_ID value is a positive numeric value, the system will locate the transaction record and update the quantity value as necessary. If the quantity has not changed, then an error will post and no changes will be made to the existing transaction.
If the FI_ACTION_ID value is zero or blank, the system will post the record as a new transaction.