PROD MOM Integration Procedure
Version: 1
Effective date: 01-Feb-2022
Contents
- 1 Standard description
- 2 Document objectives and benefits
- 3 Definitions
- 4 Roles & Responsibilities
- 5 Events to be tracked
- 6 MOM communication
- 7 MOM Integration Process
- 8 Testing
- 9 Standard owner
- 10 Document control
- 11 References
1 Standard description
This document defines the process for MOM integration into the Track and Trace landscape for a factory.
This document does not cover the capabilities of the Corporate Repository.
2 Document objectives and benefits
2.1 Objectives
The objectives of the document are:
- Describe steps to perform to integrate MOM with Track and Trace systems
2.2 Benefits
This document helps to guide through the process of MOM integration.
3 Definitions
| Abbreviation / Term | Explanation |
|---|---|
| WMS | Warehouse Management System is a software application designed to support and optimize warehouse functionality and distribution center management |
| MOM | Manufacturing Operations Management is a collection of systems for managing end-to-end manufacturing processes to optimize efficiency |
| ERP | Enterprise Resource Planning is the system for integrated business process management; typically, under this name, the local distribution center system is mentioned |
| SAP | Main ERP system of JTI |
| CR | Corporate Repository |
| 3PL | Third-party logistics |
| QA or QLF | Test environment |
| PPR or QLF2 | Pre-production environment |
| PRD or PROD | Production environment |
| EOID Economic Operator ID | Economic operator is any natural or legal person involved in the trade of tobacco products, including for export, from the manufacturer to the last economic operator before the first retail outlet. This includes, but is not limited to, manufacturers, importers, wholesalers, and distributors, as well as transport companies or providers of courier services |
| FID Facility ID | Facility is any location, building, or vending machine where tobacco products are manufactured, stored, or placed on the market. One or more FID could be assigned to EOID |
Please refer to IT Glossary in the IT P&P portal for further definitions.
4 Roles & Responsibilities
The following roles and responsibilities are defined for mentioned activities:
| Activity | GSC CP | IT BTS TT | GDC TT | Market / Factory |
|---|---|---|---|---|
| Define and maintain standard | A | R | C | I |
| Apply the standard | R/A | R | R | R/I |
A - Accountable
R - Responsible
C - Consulting
I - Informed
5 Events to be tracked
Different events could be a subject of tracking depending on regulations for specific markets. Possible tracking events and messages corresponding to these events are described in the Integration Guideline document, including masterdata, data format, and so on.
The events to be tracked are:
- Shipping
- Aggregation
- Disaggregation
- Arrival
- Return from customer
- Deactivation
- Transloading
- Vending Van Sales
5.1 Tracking points scanning points
Scanning points are defined in the business process.
6 MOM communication
6.1 MOM to CR communication
MOM must be configured to send distribution events to CR, defined in paragraph 3.2.
However, pallet aggregation and MC validation, production level events, are to be continued with GLA-TPM integration.
Any other communication from CR to Government Repository is out of the scope of this document.
Communication to CR is described in the Integration Guideline document, including authentication, certificates, token request, message format, masterdata management.
6.2 MOM to other systems communication
Depending on MOM components planned for implementation MOM should be configured to exchange data with different JTI systems.
6.2.1 SAP
Production area interfaces:
- SAP-MOM Production orders interface, aimed to supply the MOM system with relevant information concerning Production orders, scheduled for Production in SAP
- MOM-SAP Production order confirmation interface, aimed to post SSCC based production order confirmation in SAP
6.2.2 TPM and MOM communication
MOM is currently communicating with TPM for pallet-MC aggregation and MC validation at the Poland OTP factory.
At other locations, this TPM communication will continue to be handled by GLA.
6.2.3 GLA and MOM communication
GLA-to-MOM interface is described in this chapter.
MOM-to-GLA interface does not exist, and there is no plan to develop it.
GLA talks to Palletizer, and Palletizer talks to MOM, only for factories where we still have Palletizers.
Also, please provide information concerning SAP-GLA interfacing, which will be active after MOM implementation.
6.2.3.1 Process "as is" before MOM implementation
GLA is creating pallet confirmation files for SAP.
6.2.3.2 Process "to be" after MOM implementation
GLA is creating pallet confirmation files but these files will not be transferred into SAP folder. Hence, no pallet confirmation was triggered by GLA. Instead, MOM will be creating pallet confirmation files for SAP.
Following GLA-MOM interfaces have been deployed at Dagmersellen and Trier factories. GLA provides pallet data to MOM as soon as the pallet is built and validated by TPM.
6.2.3.3 Validated Pallet data interface
Following information provided by GLA to MOM:
| Field description | Data Type | Length | O/M | Description |
|---|---|---|---|---|
| PlantCode | Varchar | 10 | O | The factory id as used in SAP, e.g. DEP1, TRP1, etc |
| BatchNumber | Varchar | 10 | M | The batch number of the pallet to create |
| SSCCcode | Varchar | 20 | M | The SSCC of the pallet to create. Can be empty, in which case there should be 20 spaces and the SSCC can be updated through the T&T pallet information association process. This is dependent on the fully automated or semi-automated solution. Note: The second last digit in the SSCC represents the tracking indicator. This enables the system reading this file to know if the pallet is tracked or not |
| WorkOrder | Varchar | 8 | O | The production order number of the pallet to create. Can be empty, in which case there should be 8 spaces. This value is padded on the left with spaces, '" |
| PalletCounter | Numeric | 6 | O | The sequential number of the pallet to create |
| PalletType | Nvchar | 3 | M | 3 Characters representing the pallet type using SAP coding, e.g.: EUR for Euro, IND for Industrial Pallets |
| NumberOfCase | Int | M | Number of master cases on the pallet | |
| MaterialNumber | Varchar | 8 | M | SKU number of the work order |
| EPCcodes | Varchar | Max | M | Provide mastercase codes in an array format, see example below |
| ErrorCode | Int | M | Error/success code of TPM and Palletizer communication | |
| PalletBuildStatus | Int | M | If the pallet was built automatically or manually to use the correct vehicle for pick up. Value 0: Pallet built automatically. Value 1: Pallet built manually |
Example array format for EPCcodes:
{
"EPCcodes": [
"011460043993295310127346602100006124014046760",
"011460043993295310127346602100006224014046760",
"011460043993295310127346602100006324014046760",
"011460043993295310127346602100006424014046760",
"011460043993295310127346602100006524014046760"
]
}
6.2.3.4 New Pallet Created in GLA
Note: The original PDF contains a flowchart. The visual layout cannot be fully preserved in Markdown. The OCR-extracted text was low quality, so the available text is preserved below as an OCR note.
Start
New Polst
GLA
Plew SSCC
Crestad
Pallet Contain
Any Errors
Irrar Code
Upikte
HO
Is TFDE
Yes
Palla irto
Send to TEM
Al codes are
validited?
Ho
Yes
Is Palet Printed
Vadite
MOM
Stop
6.2.3.5 Existing Pallet Reworked
Note: The original PDF contains a flowchart. The visual layout cannot be fully preserved in Markdown. The OCR-extracted text was low quality, so the available text is preserved below as an OCR note.
Start
Existing Pellet
Reworked
Is TFD?
Delete Lyisting
SSOC & Creste
FlewSSUL
Pallet into
Send to TPM
No
Al cases are
velickted?
s Pallet Printed
Error Code
Tpdie
Pellet indo Send to
MOM
Stop
6.2.3.6 TPM Status Change Interface GLA to MOM
GLA provides TPM status change information to MOM. GLA will run a new interface with the TPM system every 300 seconds to check the TPM status. If TPM becomes unreachable, GLA will trigger this GLA-to-MOM TPM status interface to notify MOM.
Whenever GLA detects that TPM is running again, the interface will be triggered to notify MOM.
The interface execution data will be logged in the GLA database, InterfaceRunLog table.
The JSON format is explained below.
- TPM is Enabled
- TPM is Disabled
Request JSON Format:
{
"LocationID": "RUP1",
"MessageDateTime": "2019-10-04T08:15:01.000",
"ErrorCode": 51003,
"TPMAlive": 1
}
MOM Response JSON Format:
{
"StatusCode": 200,
"ResponseDateTime": "2019-10-04T08:15:01.000"
}
Status codes:
| Status code | Meaning |
|---|---|
| 200 | Success |
| 500 | Failed |
6.2.3.7 TPM Alive Check GLA to TPM Interface
A new interface has been developed between GLA and TPM systems to check if TPM system is running.
GLA will log the TPM state changes in its database. A new field can be added into SAPInterfaceConfiguration table to store the TPM state.
Request JSON Format:
{
"LocationID": "RUP1",
"MessageDateTime": "2019-10-04T08 :15:01.000"
}
TPM Response JSON Format:
{
"StatusCode": 200,
"ResponseDateTime": "2019-10-04T08:15:01.000"
}
If TPM does not respond, GLA will treat it as TPM unavailable and trigger the TPM status change interface to MOM.
6.2.4 Palletizer
No change on the GLA side. However, MOM may be controlling the palletizer, which is out of T&T scope.
7 MOM Integration Process
7.1 Configurations
To implement MOM, several configurations must be checked in CR, or created if necessary.
Make sure you use the correct environment, as Prod, QA, and PreProd environments are independent, and making changes in one of them does not influence the others.
Initially, all the configurations for CR must be done in a QA environment. Only after successful testing in QA, configurations should be replicated in the PROD environment. The process of creating configurations is the same in all environments. After all the tests pass successfully in test environments, configurations in production can be done the same way.
7.1.1 CR configurations
EOID, Economic Operator ID, and FID, Facility ID, for customers of JTI are not required to be in CR.
Only EOID and FID of the JTI warehouse, source warehouse, are to be created in CR.
CR configurations are performed by JTI Track and Trace team.
Partner_id is provided by JTI Track and Trace team.
Depending on regulations, EOID and FID can be provided by JTI Track and Trace or ID issue.
7.1.1.1 Economic Operator IDs
New EOID to be created, if necessary.
EOID naming conventions:
Prefix is always:
urn : atos : loc :
Example, for JT INTERNATIONAL SA, which already exists in CR:
urn: atos : loc : JTI_SAP_ECC_PRD: 1799
7.1.1.2 Facility IDs
FID, Facility ID, is always associated with EOID.
Prefix is always:
urn : atos : loc :
Example, for CHP1 plant:
urn : atos : loc : JTI_SAP_ECC_PRD : CHP1
7.1.1.3 Partner IDs
New partner id should be created for MOM.
MOM owner should provide to Track and Trace email distribution list associated for this partner_id.
Partner_id will be provided by JTI Track and Trace team.
Prefix is always:
urn : atos : partner :
Example of partner_id:
urn : atos : partner : JTI_MOM_ CHP1_PRD
urn : atos : partner : JTI_MOM_KZP2_PRD
urn : atos : partner : JTI_MOM_PLP2RMC_PRD
urn : atos : partner : JTI_MOM_PLP2RRP_PRD
urn:atos:partner:JTI_MOM_PLP2OTP_PRD
XML example:
Note: The PDF extraction around this XML example contained line breaks and a stray
4. The content is preserved below as a corrected MDX-safe XML-style code block.
<Sender>
<Identifier Authority="Internal">urn: atos : partner : JTI_MOM_CHP1_PRD</Identifier>
</Sender>
Original extracted XML-like text, preserved as text:
<Sender>
4
→
<Identifier
\> Authority="Internal">urn: atos : partner : JTI_MOM_CHP1_PRD</Identifier>
→
</Sender>
7.1.1.4 Scope
Depending on implementation Scope can be set to either Private or Legal.
This is explained in Integration Guideline.
Summary:
- Private - CR will not forward any data further
- Legal - CR will forward data further
This is described in Integration Guideline.
7.1.1.5 Configuration in CR
Check if required EOID and FID exist in CR, use CM Admin under the Economic Operators tab.
If these values are not defined, please create in CR the EOID and FID values defined in previous paragraphs.
To create a new EOID use + next to the Economic operators heading and fill in all the details in the form. Note that it is possible to edit the entry after it was saved, but it cannot be deleted, so pay attention.
For FID the process is similar.
New partner_id has to be created via a ticket in World Line Jira, providing internal id, scope, Legal for partners reporting to regulatory authorities and Private for voluntarily tracking, shipment info mailing distribution list and environment, QA, PRD, etc.
7.1.2 MOM authentication when connecting to CR
This process is fully described in the Integration Guideline, chapter 5 - Technical description of data transmission.
Here is only a summary provided.
OAuth2 is used.
Before calling any API, the client application must call the authentication system in order to generate and receive an OAuth2 token.
7.1.2.1 Token generation
Endpoint URL for token request in the generic format:
| URL | Method | Comments |
|---|---|---|
https://tat.jti.com/cr/<instance>/auth | POST | <instance> is one of: prd, qa or ppr |
Endpoint URL for token request exact values:
| # | Environment | Endpoint URL |
|---|---|---|
| 1 | QA | https://tat.jti.com/cr/qa/auth |
| 2 | PPR | https://tat.jti.com/cr/ppr/auth |
| 3 | PRD | https://tat.jti.com/cr/prd/auth |
Header:
Content-Type: application/x-www-form-urlencoded
Body contains:
Grant_type: client_credentials
Client_id: JTI Track and Trace team will provide
Client_secret: JTI Track and Trace team will provide
The response contains an access_token that must be used to process all other requests, call API on CR side.
7.1.3 MOM sending message to CR
This process is fully described in Integration Guideline, chapter 5 - Technical description of data transmission.
This is only a summary:
With the access_token generated in the previous section, you are now able to use any APIs provided in Integration Guideline. The token access_token must be set into the Authorization HTTP headers.
Endpoint URL for sending a message to CR in the generic format:
Note: The PDF extraction split this URL across lines. It was reconstructed below based on the extracted text and the exact endpoint values listed in the document.
| URL | Method | Comments |
|---|---|---|
https://tat.jti.com/cr/<instance>/client-cm/v1/cm/corporate/epcis | POST | <instance> is one of: prd, qa or ppr |
Original extracted split text:
https://tat.jti.com/cr/<instance>/client POST
<instance> is one of: prd, qa or ppr
cm/v1/cm/corporate/epcis
Endpoint URL for sending message to CR exact values:
| # | Environment | Endpoint URL |
|---|---|---|
| 1 | QA | https://tat.jti.com/cr/qa/client-cm/v1/cm/corporate/epcis |
| 2 | PPR | https://tat.jti.com/cr/ppr/client-cm/v1/cm/corporate/epcis |
| 3 | PRD | https://tat.jti.com/cr/prd/client-cm/v1/cm/corporate/epcis |
Content type:
Content-Type: application/xml
Authorization:
Authorization: Bearer {access_token}
7.1.4 MOM configuration for "Shipping" message
There are two types of Shipment, or Dispatch, messages:
- Shipment option 1
- Shipment option 2
This is explained in Integration Guidelines.
Message example provided in Integration Guideline as well.
7.1.4.1 "Shipping" opt.1
Shipment option 1 is used when JTI SAP is involved and consists of the Delivery note data, sent to CR from SAP, and the Scanning data message, sent from MOM. Those two messages are matched in CR by the reference number to form a full Shipping message.
Scanning data messageis being sent from MOMDelivery note datamessage is being sent from JTI SAP S4 HANA
This is the option for MOM, send Shipment as option 1.
7.1.4.2 "Shipping" opt.2
Shipment opt.2 is used when JTI SAP is not involved, e.g., for 3PL or WWDF customers. In this case system will send the full Shipping message to CR.
Shippingmessage as a whole, in one message, is sent from one system, WMS, Movilizer
8 Testing
After all configurations in a certain environment are complete, initially in QA, and in PRD after all tests are successful in QA, testing should be done before moving to the PRD, Go-live.
The standard list of required tests:
- Test that MOM can perform scan correctly and send data, message, to CR; check that data appear in CR
- Test each type of message which is in scope:
- Check that message appears in CR and has expected data, correct EOID, FID, partner_id
- Check that message appears in iTrack, if applicable
- SAP and MOM communication test, if relevant, SAP team to be involved
- TPM and MOM communication test, if relevant, TPM team to be involved
- GLA and MOM communication test, if relevant, GLA team to be involved
9 Standard owner
The owner of this standard is BTS T&T team.
10 Document control
10.1 Contact person
Questions and feedback regarding this standard should be submitted to the BTS T&T Team.
Note: The original PDF included a named contact person. The name is not reproduced here.
10.2 Revision History
| Version | Effective date | Purpose of change | Author |
|---|---|---|---|
| 1 | 01-Feb-2022 | First version of the document | Troshev, Mikhail |
| Version | Effective Date | Reason for Changes |
|---|---|---|
| V0.9 | 23.08.2021 | First draft |
| v1.0 | 01.02.2022 | First version |
11 References
References to relevant documents:
- EU TPD Integration Guidelines