Integrating TAS and TMS with SAP: what data flows and how to handle failures

Integrating a terminal automation system (TAS) and a tank management system (TMS) with SAP usually moves three kinds of data: orders and delivery status, filling results per compartment, and tank stock corrected to a standard temperature. What decides success is the set of rules for queues, retries and reconciliation when the connection fails.

A TAS runs loading at the terminal (see what a terminal automation system is) and a TMS keeps tank levels and stock. SAP is the business system that holds orders, materials and accounting. Customs reporting is a separate line, described in TPS Online. This guide covers the data, the boundaries and the failure handling, using the patterns visible in Citia's own terminal projects.

OT is the equipment and software that runs the physical terminal. IT is the business systems that account for what happened.

The TAS, the TMS, batch controllers and PLCs are OT: they must keep working when the office network is down. SAP is IT, with a different change cycle, different availability targets and different owners. The integration is where these two worlds meet, and most failures come from assuming they behave alike.

The ISA-95 standard (IEC 62264) describes the same split. Level 3 covers operations management, where a TAS and a TMS sit, and Level 4 covers business planning and logistics, where SAP sits. Part 3 of the standard defines the activities at Level 3, and the exchange between the two levels is what this guide is about.

Almost every TAS and TMS link to SAP carries the same three kinds of data.

Orders and delivery status go from SAP, or from a distribution order system such as SIOD, to the TAS, and the status of each delivery goes back. Filling results go from the TAS to SAP once a truck has loaded, per compartment, with the measured quantity. Tank stock goes from the TMS to SAP as physical inventory.

Citia's own project notes show the pattern. At the Jambi fuel terminal the TAS links shipment, gate-in, the filling shed and gate-out with SAP and SIOD, including the delivery note and Good Issue. The LPG terminal at Pulau Layang reports tank stock to SAP through automatic physical inventory, and the Padalarang TAS updates distribution status in SAP automatically.

A sound design starts from a field list for each transaction, written with the SAP team and not guessed.

The table shows typical content. The real field list depends on the SAP configuration and on what the site agrees. Two fields matter more than the rest: a unique business key for each transaction, and a timestamp with its time zone. Without them, retries create duplicates and reconciliation cannot line up the two sides.

Put the agreement in one interface document: the field list, the version, the error codes, the contact on each side and the rule for changing any of them. A field added on one side without the document is the most common way an integration breaks months after go-live.

Keep units explicit. Volume at observed temperature, volume at standard temperature, density and temperature are different values. SAP should receive the one the business process defines, and the others stay in the terminal record for audit. The last row shows common choices for an unreachable SAP, and each site sets its own policy.

Reconciliation is the check that both systems agree, done every day and not only at month end.

Pick a cut-off time and compare what each side holds for that moment. The goal is not zero differences on the first day. The goal is to find each difference while the people who understand the shift are still around to explain it.

Master data is the shared vocabulary of the integration: products, customers, plants, tanks and vehicles.

In most terminals SAP owns material codes, customers and plant data, while the terminal owns tanks, bays and equipment. The TAS keeps copies of the SAP data it needs, so the real question is how a change travels. If a product code changes in SAP and the TAS is not updated, a truck loads one product against another's code.

The Citia work at Padalarang is a clear case. Moving from B40 to B50 meant new material codes in the loading application. The project page records short lessons: validate active codes before an update, do not set up pending codes as operational products, and test and document every product change. The article on B50 at fuel terminals lists the full set of changes.

Give every master data item one owner and one direction of change. Two systems that can both edit the same product list will drift apart.

An integration is tested by breaking it on purpose, not only by running it when everything works.

Agree the test cases with the SAP team and run them in a test system with realistic master data. A short list is enough when each case has a written expected result:

• A normal order, from loading to posting, start to end.
• A repeated message with the same business key, which must not create a second posting.
• SAP unreachable during loading, then restored, with results arriving in order.
• A product code that exists in the terminal but not in SAP, which must be rejected with a clear reason.
• A restart of the terminal server in the middle of a queue.
• A clock or time zone difference between the two systems.

Record every result in the site acceptance record. The Citia B50 project followed the same habit: test transactions with the new product codes, plus documented screens and test results.

The link between SAP and the terminal is also a path into the control network, so it deserves its own design.

Use a dedicated interface server or service between the two networks, and let it open only the connections the data flow needs. Give the integration its own account with minimum rights, so that a leaked password cannot change terminal settings. Log every message with its key and time, because the log is also your evidence in a reconciliation dispute.

The Citia bulletin on secure system integration describes API-based links with layered protection, and the guide on OT cybersecurity at fuel terminals covers the first steps for the control network.