PROD GLA Integration Guideline - TPM Integration

Source document: IP016_PROD-GLA-Integration-Guideline.pdf
Original PDF sections: 8.1-8.1.5 TPM integration
Version: 1
Effective date: 01-Jan-2022

Contents

• 1 Integration with TPM system
  • 1.1 TPM pallet-master case aggregation protocol
  • 1.2 SOAP interface
• 2 UploadData
  • 2.1 Request data
  • 2.2 Response data
• 3 AggregationADD
  • 3.1 Request data
  • 3.2 Response data
• 4 AggregationDELETE
  • 4.1 Request data
  • 4.2 Response data
• 5 Master Case Verification
  • 5.1 Overview
  • 5.2 GetData
  • 5.3 Request data
  • 5.4 Response data
  • 5.5 Master case validation result
  • 5.6 Error reporting
  • 5.7 Logging and retry handling
• 6 Workorder Tracking System for TPM
  • 6.1 Overview
  • 6.2 Running workorder data
  • 6.3 Tracking rules
  • 6.4 Production run history
  • 6.5 JSON response
• 7 Preservation notes

---

1 Integration with TPM system

1.1 TPM pallet-master case aggregation protocol

This section describes the integration protocol between GLA and TPM for pallet-master case aggregation.

The interface is used to transfer pallet aggregation information from GLA to TPM.

Note: The source PDF content is under original section 8.1. In this split Markdown file, the chapter numbering starts from 1.

1.2 SOAP interface

The communication between GLA and TPM is based on SOAP web service calls.

MDX safety note: SOAP/XML examples must always remain inside fenced code blocks. Do not paste raw <soapenv:Envelope>, <soapenv:Header>, or similar XML tags directly into Markdown prose.

Generic SOAP message structure:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header />
  <soapenv:Body>
    <!-- Request payload -->
  </soapenv:Body>
</soapenv:Envelope>

2 UploadData

UploadData is used to send data from GLA to TPM.

The exact payload depends on the aggregation operation and the data available in GLA.

2.1 Request data

<UploadData>
  <LocationID>Plant or factory location identifier</LocationID>
  <MessageDateTime>Message date and time</MessageDateTime>
  <PalletSSCC>Pallet SSCC code</PalletSSCC>
  <WorkOrder>Work order number</WorkOrder>
  <BatchNumber>Batch number</BatchNumber>
  <EPCList>
    <EPC>Master case EPC code</EPC>
  </EPCList>
</UploadData>

Request fields:

Field	Description	Mandatory / Optional	Notes
LocationID	Plant or factory location identifier	M	Example values in the document include plant-style identifiers
MessageDateTime	Date and time of the request message	M	Date-time format depends on implementation
PalletSSCC	Pallet SSCC code	M	Used as the parent aggregation identifier
WorkOrder	Work order number	O	Used to link aggregation to production order where available
BatchNumber	Batch number	O	Used to link aggregation to production batch where available
EPCList	List of master case EPC codes	M	Contains the master case codes aggregated to the pallet
EPC	Master case EPC code	M	Repeated for each master case

2.2 Response data

The response from TPM confirms whether the message was processed successfully or whether an error occurred.

<UploadDataResponse>
  <StatusCode>200</StatusCode>
  <ResponseDateTime>Response date and time</ResponseDateTime>
  <ErrorCode>0</ErrorCode>
  <ErrorMessage>Success or error message</ErrorMessage>
</UploadDataResponse>

Response fields:

Field	Description	Notes
StatusCode	Processing status returned by TPM	200 normally represents success
ResponseDateTime	Date and time of the TPM response
ErrorCode	Error code returned by TPM	0 or empty may represent no error depending on implementation
ErrorMessage	Error or success message text	Used for troubleshooting

3 AggregationADD

AggregationADD is used when master cases are added to a pallet aggregation.

The operation links master case codes to the pallet SSCC.

3.1 Request data

<AggregationADD>
  <LocationID>Plant or factory location identifier</LocationID>
  <MessageDateTime>Message date and time</MessageDateTime>
  <PalletSSCC>Pallet SSCC code</PalletSSCC>
  <WorkOrder>Work order number</WorkOrder>
  <BatchNumber>Batch number</BatchNumber>
  <MasterCases>
    <MasterCase>
      <EPC>Master case EPC code</EPC>
    </MasterCase>
  </MasterCases>
</AggregationADD>

Request fields:

Field	Description	Mandatory / Optional	Notes
LocationID	Plant or factory location identifier	M	Identifies the source location
MessageDateTime	Date and time of the request	M	Should reflect the message creation time
PalletSSCC	Pallet SSCC code	M	Parent code for aggregation
WorkOrder	Work order number	O	May be required depending on local implementation
BatchNumber	Batch number	O	May be used for validation
MasterCases	Collection of master case records	M	Contains one or more MasterCase entries
MasterCase	One master case record	M	Repeated per master case
EPC	EPC code of the master case	M	Child code to be added to the pallet

3.2 Response data

<AggregationADDResponse>
  <StatusCode>200</StatusCode>
  <ResponseDateTime>Response date and time</ResponseDateTime>
  <ErrorCode>0</ErrorCode>
  <ErrorMessage>Success or error message</ErrorMessage>
</AggregationADDResponse>

Response fields:

Field	Description	Notes
StatusCode	TPM processing status	200 normally represents success
ResponseDateTime	TPM response timestamp
ErrorCode	TPM error code	Used if processing fails
ErrorMessage	Error or success message text	Used for troubleshooting and logging

4 AggregationDELETE

AggregationDELETE is used when master cases are removed from a pallet aggregation.

The operation removes the link between the pallet SSCC and one or more master case EPC codes.

4.1 Request data

<AggregationDELETE>
  <LocationID>Plant or factory location identifier</LocationID>
  <MessageDateTime>Message date and time</MessageDateTime>
  <PalletSSCC>Pallet SSCC code</PalletSSCC>
  <MasterCases>
    <MasterCase>
      <EPC>Master case EPC code</EPC>
    </MasterCase>
  </MasterCases>
</AggregationDELETE>

Request fields:

Field	Description	Mandatory / Optional	Notes
LocationID	Plant or factory location identifier	M	Identifies the source location
MessageDateTime	Date and time of the request	M	Should reflect the message creation time
PalletSSCC	Pallet SSCC code	M	Parent aggregation identifier
MasterCases	Collection of master case records to remove	M	Contains one or more MasterCase entries
MasterCase	One master case record	M	Repeated per master case
EPC	EPC code of the master case	M	Child code to be removed from the pallet

4.2 Response data

<AggregationDELETEResponse>
  <StatusCode>200</StatusCode>
  <ResponseDateTime>Response date and time</ResponseDateTime>
  <ErrorCode>0</ErrorCode>
  <ErrorMessage>Success or error message</ErrorMessage>
</AggregationDELETEResponse>

Response fields:

Field	Description	Notes
StatusCode	TPM processing status	200 normally represents success
ResponseDateTime	TPM response timestamp
ErrorCode	TPM error code	Used if processing fails
ErrorMessage	Error or success message text	Used for troubleshooting and logging

5 Master Case Verification

5.1 Overview

The Master Case Verification interface is used by GLA to verify master case codes through TPM.

This process supports validation of master case information during production and aggregation-related operations.

The interface is based on SOAP web service communication.

Generic SOAP message structure:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header />
  <soapenv:Body>
    <!-- Request payload -->
  </soapenv:Body>
</soapenv:Envelope>

5.2 GetData

GetData is used to request master case validation information from TPM.

5.3 Request data

<GetData>
  <LocationID>Plant or factory location identifier</LocationID>
  <MessageDateTime>Message date and time</MessageDateTime>
  <MasterCaseCode>Master case EPC or barcode value</MasterCaseCode>
</GetData>

Request fields:

Field	Description	Mandatory / Optional	Notes
LocationID	Plant or factory location identifier	M	Identifies the source location
MessageDateTime	Date and time of the request	M	Should reflect the request creation timestamp
MasterCaseCode	Master case code to be verified	M	May contain EPC or barcode value depending on implementation

5.4 Response data

<GetDataResponse>
  <StatusCode>200</StatusCode>
  <ResponseDateTime>Response date and time</ResponseDateTime>
  <MasterCaseCode>Master case EPC or barcode value</MasterCaseCode>
  <ValidationResult>Validation result</ValidationResult>
  <ErrorCode>0</ErrorCode>
  <ErrorMessage>Success or error message</ErrorMessage>
</GetDataResponse>

Response fields:

Field	Description	Notes
StatusCode	Processing status returned by TPM	200 normally represents success
ResponseDateTime	Date and time of the TPM response
MasterCaseCode	Master case code returned by TPM	Should correspond to the requested code
ValidationResult	Result of master case verification	Used by GLA to determine whether the case is valid
ErrorCode	Error code returned by TPM	Used if validation or communication fails
ErrorMessage	Error or success message text	Used for troubleshooting and logging

5.5 Master case validation result

The validation result confirms whether the master case code is accepted or rejected by TPM.

Typical processing logic:

1. GLA sends the master case code to TPM
2. TPM checks the code and related production or aggregation data
3. TPM returns validation status to GLA
4. GLA continues or blocks the related process based on the returned result

Possible validation outcomes:

Result	Meaning	GLA action
Valid	Master case code is accepted	Continue the process
Invalid	Master case code is rejected	Stop or reject the related operation
Error	TPM could not complete validation	Log the error and follow retry or escalation handling

Extraction note: The exact result values in the source PDF were not fully reliable in the available extraction. The table above preserves the functional meaning without inventing unsupported numeric codes.

5.6 Error reporting

If TPM returns an error or does not respond, GLA should record the issue for troubleshooting.

Typical error information includes:

Field	Description
ErrorCode	Error code returned by TPM
ErrorMessage	Error message returned by TPM
MessageDateTime	Request timestamp
ResponseDateTime	Response timestamp, if available
MasterCaseCode	Master case code involved in the failed validation
LocationID	Location where the validation request originated

Example error response:

<GetDataResponse>
  <StatusCode>500</StatusCode>
  <ResponseDateTime>Response date and time</ResponseDateTime>
  <MasterCaseCode>Master case EPC or barcode value</MasterCaseCode>
  <ValidationResult>Error</ValidationResult>
  <ErrorCode>TPM error code</ErrorCode>
  <ErrorMessage>TPM error message</ErrorMessage>
</GetDataResponse>

5.7 Logging and retry handling

GLA should log TPM master case verification requests and responses.

Recommended logging points:

• Request sent from GLA to TPM
• Response received from TPM
• Validation result returned by TPM
• Communication timeout or connection failure
• Error code and error message, if returned

If TPM is unavailable, GLA should follow the configured retry or escalation process.

Note: The detailed retry interval and exact scheduler configuration were not reliably extracted from this section of the PDF. They should be aligned with the local GLA and TPM implementation configuration.

6 Workorder Tracking System for TPM

6.1 Overview

This section describes the workorder tracking system information used for TPM integration.

The purpose is to provide TPM with information related to the running workorder and its tracking requirements.

Extraction note: The original PDF section for the workorder tracking API contains API/JSON content, but the extraction available in this conversation is incomplete. The structure below preserves the identified purpose and MDX-safe JSON handling without inventing unsupported endpoint details.

6.2 Running workorder data

Running workorder data may include information such as:

Field	Description
WorkOrder	Production workorder number
PlantCode	Plant or factory code
LineCode	Production line or work center code
MaterialNumber	SKU or material number
BatchNumber	Batch number
TrackingRelevant	Indicator showing whether tracking is required
CartonTrackingRequired	Indicator showing whether carton tracking is required
PackTrackingRequired	Indicator showing whether pack tracking is required
ProductionStartDateTime	Production start date and time

6.3 Tracking rules

Tracking rules define which tracking level applies to a given production run or workorder.

Typical indicators include:

Indicator	Meaning
SAP_IsTrackingRelevant	Indicates whether the workorder is tracking relevant
SAP_IsCartonTrackingRequired	Indicates whether carton tracking is required
SAP_IsPackTrackingRequired	Indicates whether pack tracking is required
SAP_TTProdIdent	T&T production identifier used to derive tracking relevance

6.4 Production run history

Production run history may be used to identify previous or current workorder execution context.

Typical data points include:

• Workorder number
• Batch number
• Material number
• Plant code
• Production line
• Start date and time
• End date and time, if available
• Tracking flags
• Status information

6.5 JSON response

Example JSON-style response structure:

{
  "WorkOrder": "Production order number",
  "PlantCode": "Plant code",
  "LineCode": "Production line or work center",
  "MaterialNumber": "SKU or material number",
  "BatchNumber": "Batch number",
  "TrackingRelevant": true,
  "CartonTrackingRequired": false,
  "PackTrackingRequired": false,
  "ProductionStartDateTime": "YYYY-MM-DDTHH:mm:ss"
}