PROD GLA Integration Guideline - CR Integration

Source document: IP016_PROD-GLA-Integration-Guideline.pdf
Original PDF section: 8.4 GLA and CR communication
Version: 1
Effective date: 01-Jan-2022

Contents

• 1 GLA and CR communication
  • 1.1 Overview
  • 1.2 Production order interface
  • 1.3 Authentication
  • 1.4 Endpoint
  • 1.5 Request data
  • 1.6 Response data
  • 1.7 Barcode formats
• 2 Preservation notes

---

1 GLA and CR communication

1.1 Overview

This section describes the interface between GLA and CR.

The purpose of the interface is to send production-related information from GLA to CR.

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

CR is used as the target system for Track and Trace related production information.

1.2 Production order interface

The GLA-to-CR production order interface transfers production order information and related tracking data.

The interface may include information such as:

• Plant or factory identifier
• Production order number
• Work order number
• Material number
• Batch number
• Production line or work center
• Tracking relevance
• Pack, carton, or master case tracking indicators
• Production date and time information
• Barcode or EPC-related data

Formatting note: The original PDF contains technical interface details and field lists. The available extraction in this conversation does not provide every field with full confidence, so the reliably identified structure is preserved below without inventing unsupported field names.

1.3 Authentication

Authentication is required before calling CR APIs.

The authentication process uses token-based access.

The client system must request an access token before sending data to CR.

Generic token request structure:

POST https://tat.jti.com/cr/<instance>/auth
Content-Type: application/x-www-form-urlencoded

Request body structure:

grant_type=client_credentials
client_id=<client_id>
client_secret=<client_secret>

MDX safety note: Placeholders such as <instance>, <client_id>, and <client_secret> are kept inside fenced code blocks so MDX does not treat them as JSX tags.

The response contains an access token that must be used when calling CR APIs.

Example token response structure:

{
  "access_token": "token value",
  "token_type": "Bearer",
  "expires_in": 3600
}

1.4 Endpoint

Generic CR endpoint structure:

POST https://tat.jti.com/cr/<instance>/client-cm/v1/cm/corporate/epcis
Content-Type: application/xml
Authorization: Bearer <access_token>

Environment examples:

Environment	Endpoint
QA	https://tat.jti.com/cr/qa/client-cm/v1/cm/corporate/epcis
PPR	https://tat.jti.com/cr/ppr/client-cm/v1/cm/corporate/epcis
PRD	https://tat.jti.com/cr/prd/client-cm/v1/cm/corporate/epcis

Note: Endpoint values are kept in backticks or fenced blocks to avoid MDX parsing issues with <instance> and URL characters.

1.5 Request data

The request sent from GLA to CR is XML-based.

Generic XML-style request structure:

<EPCISDocument>
  <EPCISBody>
    <EventList>
      <ObjectEvent>
        <eventTime>Production event time</eventTime>
        <eventTimeZoneOffset>Time zone offset</eventTimeZoneOffset>
        <epcList>
          <epc>EPC or barcode value</epc>
        </epcList>
        <action>ADD</action>
        <bizStep>Business step</bizStep>
        <disposition>Disposition</disposition>
        <readPoint>
          <id>Read point identifier</id>
        </readPoint>
        <bizLocation>
          <id>Business location identifier</id>
        </bizLocation>
      </ObjectEvent>
    </EventList>
  </EPCISBody>
</EPCISDocument>

Typical request fields:

Field	Description	Notes
eventTime	Date and time of the event	Should reflect the production or tracking event time
eventTimeZoneOffset	Time zone offset	Example format: +03:00
epcList	List of EPC or barcode values	Contains one or more epc entries
epc	EPC or barcode value	Represents tracked item, case, or pallet depending on event type
action	Event action	Example: ADD
bizStep	Business step	Business process step represented by the event
disposition	Disposition	Status or disposition of the tracked object
readPoint	Read point identifier	Physical or logical point where the event was captured
bizLocation	Business location identifier	Location associated with the event

Additional production order data may include:

Field	Description
PlantCode	Plant or factory code
WorkOrder	Work order or production order number
BatchNumber	Batch number
MaterialNumber	SKU or material number
LineCode	Production line or work center
ProductionDateTime	Production date and time
TrackingRelevant	Indicator showing whether tracking is required

1.6 Response data

CR returns a response confirming whether the message was accepted or rejected.

Generic response structure:

{
  "StatusCode": 200,
  "ResponseDateTime": "YYYY-MM-DDTHH:mm:ss.fff",
  "Message": "Success or error message"
}

Typical response fields:

Field	Description	Notes
StatusCode	Processing status returned by CR	200 normally represents success
ResponseDateTime	CR response timestamp	Used for logging and troubleshooting
Message	Success or error message	Used to understand processing result

Status codes:

Status code	Meaning
200	Success
500	Failed

If the CR response indicates an error, GLA should log the error and follow the configured error handling or retry process.

Typical logged data includes:

• Request timestamp
• Response timestamp
• Status code
• Error message
• Production order number
• Batch number
• Plant code
• Payload reference or message identifier

1.7 Barcode formats

The source document includes barcode-related information for production and Track and Trace handling.

Barcode or EPC values may represent different packaging levels, such as:

• Pack
• Carton
• Master case
• Pallet

Typical barcode handling considerations:

Item	Description
EPC	Electronic Product Code or serialized code used in tracking events
SSCC	Serial Shipping Container Code, commonly used for pallet identification
GTIN	Global Trade Item Number, commonly used for trade item identification
FNC1	Function 1 symbol character used in GS1 barcode structures

MDX safety note: Barcode examples containing <, >, {}, or | must be fenced or escaped. For example, a pattern such as <FNC1<31>> must not appear as raw MDX prose.

Safe barcode-pattern example:

<FNC1<31>>

If barcode examples are added later from screenshots or source tables, keep them inside fenced text blocks unless they are simple inline values.