--- title: "TAS and TMS Integration with SAP: Data and Failures | Citia" description: "TAS and TMS integration with SAP moves orders, filling results and tank stock. See the data per transaction and how queues, retries and reconciliation work." url: https://citia-engineering.com/en/knowledge/tas-tms-sap-integration language: en updated: 2026-11-13 type: article site: Citia Engineering Indonesia --- # Integrating TAS and TMS with SAP: what data flows and how to handle failures A TAS and TMS link to SAP carries orders, filling results and tank stock. See the data per transaction and how queues, retries and reconciliation keep it correct when the connection fails. | Field | Value | | --- | --- | | Topic | Regulation and Integration | | Author | Tim Engineering Citia | | Updated | 2026-11-13 | Key takeaways 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. - A TAS and TMS link to SAP usually moves three kinds of data: orders and delivery status, filling results per compartment, and tank stock at standard temperature. - What decides success is not the interface type but the rules for queues, retries and reconciliation when the connection fails. - Every transaction needs a unique business key and a timestamp, so a retry can never create a second posting. - Terminal systems must keep working when SAP is unreachable. Write the loading policy for that case down before go-live. ## Where OT stops and IT begins 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. OT priorities IT priorities - Loading must continue when the office network fails - Changes are tested and scheduled around operations - A wrong value can affect a physical operation - Records must agree with accounting and audit - Systems are patched and upgraded on a regular cycle - Access is controlled per user and role - Level 0 to 2: Process, sensing and control: field instruments, meters, batch controllers, PLCs - Level 3: Operations management: TAS and TMS - Level 4: Business planning and logistics: SAP ## Three kinds of data that move 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. - Meter and ATG: Measure the loaded volume and the tank level. - Controller, PLC: Run the bay and collect device data. - TAS: Runs orders, gates, loading and delivery documents. - TMS: Keeps tank readings, tank tickets and physical stock. - SAP: Holds orders, materials and accounting. - SIOD: Distribution order data exchanged with the terminal. ## What each transaction carries 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. - Direction: SAP or SIOD to TAS; status back to SAP | TAS to SAP | TMS to SAP - Typical fields: Order number, vehicle, driver, product, planned quantity, compartment plan | Order number, compartment, product, actual quantity, start and end time, meter | Tank, product, level, volume, temperature, reading time - Trigger: New or changed order; each status change | End of a filling transaction | Scheduled posting, receipt or sale - Key against duplicates: Order number plus version | Transaction number plus compartment | Tank plus posting time or ticket number - If SAP is unreachable: Loading continues on the last accepted order; status is queued | Result is queued and sent later, in order | Posting is queued; stock stays in the TMS ## Queues, retries and no double posting When SAP or the network is down, the terminal should keep working and the data should wait in line. The pattern has four parts. The sender stores each message in a durable queue before it tries to send it. It retries with growing pauses, not in a tight loop. The receiver treats a repeated message with the same business key as one it already has, so a retry never creates a second posting. Anything that fails repeatedly goes to a review list with an alarm, and a person decides. SAP's IDoc documentation describes the receiving half of this idea. Status records trace an IDoc through its stages, and an error status starts exception handling and allows a resend. The terminal side must do its own part by keeping a status for every message it sends. Decide the loading policy in writing. Some sites let a truck load against the last accepted order while SAP is unreachable. Others stop new loading authorisations until the order is confirmed. Both can be right. The unsafe choice is not to decide. - Durable queue: Each message is stored before it is sent, so a restart loses nothing. - Retries with pauses: Growing delays between attempts protect SAP when it comes back. - Business key: A repeated message is recognised and ignored, not posted twice. - Review list and alarm: Repeated failures reach a person with the evidence attached. ## Daily reconciliation between terminal and SAP 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. Do not hide a double posting: When a repeated message creates a second posting, fix it with a reversal in SAP and a note in the terminal record. Deleting the terminal transaction removes the evidence of how the duplicate happened, and it will happen again. - Set the cut-off: Use the same time and time zone on both sides. - Count transactions: Orders, filling results and stock postings in the terminal against those received in SAP. - Compare quantities per product: Total loaded volume per product on both sides. - Compare tank stock: TMS reading at the cut-off against the stock SAP holds. - Give each difference a reason: Timing, queued message, correction or unknown. Unknown goes first. - Resend only what is missing: Never resend what SAP has already posted. ## Who holds the master data 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. ## Testing the integration before go-live 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: 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. - 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. ## Keeping the link safe 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. - Network position: An interface server between the OT and IT networks - Connections: Only those the data flow needs, outbound from the terminal where possible - Account: Dedicated to the integration, with minimum rights - Logging: Every message with key, time and result ## Terms explained - OT and IT: OT runs the physical operation (TAS, TMS, PLC). IT runs the business records (SAP, email, office network). - SAP: The enterprise system that holds orders, materials, stock and accounting for the company. - IDoc: SAP's document format for exchanging business data between systems, with status records that trace each document. - Business key: A value that identifies a transaction uniquely, such as an order number with a compartment, used to recognise repeats. - Physical inventory: The stock measured in the tanks, as opposed to the stock a ledger says should be there. - Good Issue: The SAP posting that records goods leaving stock, here triggered by a completed delivery. - SIOD: The distribution order system whose data is exchanged with the terminal in Citia TAS projects. ## Frequently asked questions Q: What happens to a transaction when SAP is unavailable? A: The transaction is stored in a queue on the terminal side and sent when SAP is back. Whether trucks can keep loading meanwhile is a site policy, usually against the last accepted order. The queue sends results in order, and the business key stops duplicates. Q: Who holds the master data, the TAS or SAP? A: Usually SAP holds business master data such as materials, customers and plants, and the terminal holds tanks, bays and equipment. The TAS keeps copies of what it needs. Give each item one owner and one direction of change. Q: How do you prevent duplicate postings? A: Give every transaction a unique business key and make the receiver ignore a key it already holds. Keep a status for each message on the sender side, so a retry is a decision based on a known state. Q: What data does a TMS send to SAP? A: The INTEGRA TMS reads level, temperature and volume from the tank gauges, keeps tank tickets for receipts and sales, and posts physical inventory to SAP over the intranet. Raw readings stay in the TMS database. Q: What does OT/IT convergence mean? A: It means connecting operational technology, the systems that run the physical site, with information technology, the business systems. The benefit is one record per transaction. The cost is that two teams with different priorities must agree on interfaces, access and change control. Q: Should SAP receive every tank reading? A: No. SAP needs stock at the points the business process defines, such as end of day or after a receipt. Continuous readings stay in the TMS, where they serve alarms and trends, and a summary goes to SAP. ## Sources and further reading 1. ISA-95 Standard: Enterprise-Control System Integration, International Society of Automation (ISA) (https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard) 2. Status Processing (IDoc status records and exception handling), SAP Help Portal (https://help.sap.com/saphelp_nw73/helpdata/en/4b/6a8db3aa022b5fe10000000a42189c/content.htm) 3. OData Version 4.0 Part 1: Protocol, OASIS, 2014 (https://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html) 4. INTEGRA TMS, PT Citia Engineering Indonesia (https://citia-engineering.com/en/products/tank-management-system) 5. Fuel Terminal Jambi distribution workflow, PT Citia Engineering Indonesia, 2026 (https://citia-engineering.com/en/projects/jambi-terminal-automation) 6. Tank farm operations: TMS integration with SAP, PT Citia Engineering Indonesia, 2025 (https://citia-engineering.com/en/news/streamlining-tank-farm-operations-how-tms-integration-with-sap-revolutionizes-inventory-management-and-terminal-automation) 7. B50 product update, Padalarang fuel terminal, PT Citia Engineering Indonesia, 2026 (https://citia-engineering.com/en/projects/b50-product-update-padalarang-fuel-terminal) 8. Cover photo by Christopher Bowns, CC BY-SA 2.0 (cropped and colour graded), Wikimedia Commons (https://commons.wikimedia.org/wiki/File:Virginia_Tech_-_data_center.jpg) Planning a TAS or TMS link to SAP?: Send siTia, Citia's assistant on WhatsApp, a short description of your terminal and your SAP setup, and the engineering team will follow up. ## Contact - Company: PT Citia Engineering Indonesia - siTia - Virtual Assistance: [WhatsApp +62 813-2206-507](https://wa.me/628132206507). siTia answers questions about our products, projects and enquiries on WhatsApp. Replies are automated, and a person from the Citia team follows up. - Email: services@citiaengineering.com - Phone / WhatsApp (siTia): +62 813-2206-507 - Location: Bandung, Indonesia [Contact Citia](https://citia-engineering.com/en/contact.md) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://citia-engineering.com/#organization", "name": "Citia Engineering Indonesia", "legalName": "PT Citia Engineering Indonesia", "alternateName": "Citia", "url": "https://citia-engineering.com", "logo": { "@type": "ImageObject", "url": "https://citia-engineering.com/media/citia-logo.png", "width": 950, "height": 328 }, "description": "Citia is an engineering and system integration company in Bandung, Indonesia. We connect field devices, PLC and SCADA, terminal software and enterprise systems, then install, test and maintain them.", "email": "services@citiaengineering.com", "telephone": "+62 813-2206-507", "address": { "@type": "PostalAddress", "addressLocality": "Bandung", "addressRegion": "Jawa Barat", "addressCountry": "ID" }, "contactPoint": [ { "@type": "ContactPoint", "contactType": "customer service", "email": "services@citiaengineering.com", "telephone": "+62 813-2206-507", "url": "https://citia-engineering.com/en/contact" }, { "@type": "ContactPoint", "contactType": "customer support", "name": "siTia - Virtual Assistance", "telephone": "+62 813-2206-507", "url": "https://wa.me/628132206507", "areaServed": "ID", "availableLanguage": [ "id", "en" ] } ], "areaServed": { "@type": "Country", "name": "Indonesia" }, "knowsAbout": [ "Terminal automation system", "Automatic tank gauging", "Tank management system", "SCADA", "Programmable logic controller", "Modbus", "Field instrumentation", "Weighbridge", "Pipeline pressure monitoring", "Industrial IoT" ], "brand": [ { "@type": "Brand", "name": "INTEGRA" }, { "@type": "Brand", "name": "CATALYST" } ], "sameAs": [ "https://www.facebook.com/citiaengineering/", "https://www.instagram.com/citiaengineering/" ] }, { "@type": "WebSite", "@id": "https://citia-engineering.com/#website", "url": "https://citia-engineering.com", "name": "Citia Engineering Indonesia", "inLanguage": [ "en", "id" ], "publisher": { "@id": "https://citia-engineering.com/#organization" }, "potentialAction": [ { "@type": "SearchAction", "name": "Search Citia News", "target": { "@type": "EntryPoint", "urlTemplate": "https://citia-engineering.com/en/news?q={search_term_string}" }, "query-input": "required name=search_term_string" }, { "@type": "SearchAction", "name": "Cari di News Citia", "target": { "@type": "EntryPoint", "urlTemplate": "https://citia-engineering.com/id/news?q={search_term_string}" }, "query-input": "required name=search_term_string" } ] }, { "@type": "WebPage", "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#webpage", "url": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration", "name": "Integrating TAS and TMS with SAP: what data flows and how to handle failures", "description": "TAS and TMS integration with SAP moves orders, filling results and tank stock. See the data per transaction and how queues, retries and reconciliation work.", "inLanguage": "en", "isPartOf": { "@id": "https://citia-engineering.com/#website" }, "publisher": { "@id": "https://citia-engineering.com/#organization" }, "about": { "@id": "https://citia-engineering.com/#organization" }, "breadcrumb": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#breadcrumb" }, "dateModified": "2026-11-13", "mainEntity": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#entity" } }, { "@type": "BreadcrumbList", "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Citia", "item": "https://citia-engineering.com/en" }, { "@type": "ListItem", "position": 2, "name": "Knowledge", "item": "https://citia-engineering.com/en/knowledge" }, { "@type": "ListItem", "position": 3, "name": "Integrating TAS and TMS with SAP: what data flows and how to handle failures", "item": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration" } ] }, { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#entity", "url": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration", "mainEntityOfPage": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#webpage" }, "@type": "TechArticle", "headline": "Integrating TAS and TMS with SAP: what data flows and how to handle failures", "description": "A TAS and TMS link to SAP carries orders, filling results and tank stock. See the data per transaction and how queues, retries and reconciliation keep it correct when the connection fails.", "dateModified": "2026-11-13", "author": { "@id": "https://citia-engineering.com/#organization" }, "publisher": { "@id": "https://citia-engineering.com/#organization" }, "inLanguage": "en", "articleSection": "Regulation and Integration", "datePublished": "2026-11-13", "image": "https://citia-engineering.com/media/covers/tas-tms-sap-integration.webp" }, { "@type": "FAQPage", "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#faq", "url": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration", "inLanguage": "en", "isPartOf": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#webpage" }, "mainEntity": [ { "@type": "Question", "name": "What happens to a transaction when SAP is unavailable?", "acceptedAnswer": { "@type": "Answer", "text": "The transaction is stored in a queue on the terminal side and sent when SAP is back. Whether trucks can keep loading meanwhile is a site policy, usually against the last accepted order. The queue sends results in order, and the business key stops duplicates." } }, { "@type": "Question", "name": "Who holds the master data, the TAS or SAP?", "acceptedAnswer": { "@type": "Answer", "text": "Usually SAP holds business master data such as materials, customers and plants, and the terminal holds tanks, bays and equipment. The TAS keeps copies of what it needs. Give each item one owner and one direction of change." } }, { "@type": "Question", "name": "How do you prevent duplicate postings?", "acceptedAnswer": { "@type": "Answer", "text": "Give every transaction a unique business key and make the receiver ignore a key it already holds. Keep a status for each message on the sender side, so a retry is a decision based on a known state." } }, { "@type": "Question", "name": "What data does a TMS send to SAP?", "acceptedAnswer": { "@type": "Answer", "text": "The INTEGRA TMS reads level, temperature and volume from the tank gauges, keeps tank tickets for receipts and sales, and posts physical inventory to SAP over the intranet. Raw readings stay in the TMS database." } }, { "@type": "Question", "name": "What does OT/IT convergence mean?", "acceptedAnswer": { "@type": "Answer", "text": "It means connecting operational technology, the systems that run the physical site, with information technology, the business systems. The benefit is one record per transaction. The cost is that two teams with different priorities must agree on interfaces, access and change control." } }, { "@type": "Question", "name": "Should SAP receive every tank reading?", "acceptedAnswer": { "@type": "Answer", "text": "No. SAP needs stock at the points the business process defines, such as end of day or after a receipt. Continuous readings stay in the TMS, where they serve alarms and trends, and a summary goes to SAP." } } ] }, { "@type": "DefinedTermSet", "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#glossary", "url": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration", "inLanguage": "en", "isPartOf": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#webpage" }, "name": "Terms explained", "hasDefinedTerm": [ { "@type": "DefinedTerm", "name": "OT and IT", "description": "OT runs the physical operation (TAS, TMS, PLC). IT runs the business records (SAP, email, office network).", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#glossary" } }, { "@type": "DefinedTerm", "name": "SAP", "description": "The enterprise system that holds orders, materials, stock and accounting for the company.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#glossary" } }, { "@type": "DefinedTerm", "name": "IDoc", "description": "SAP's document format for exchanging business data between systems, with status records that trace each document.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#glossary" } }, { "@type": "DefinedTerm", "name": "Business key", "description": "A value that identifies a transaction uniquely, such as an order number with a compartment, used to recognise repeats.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#glossary" } }, { "@type": "DefinedTerm", "name": "Physical inventory", "description": "The stock measured in the tanks, as opposed to the stock a ledger says should be there.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#glossary" } }, { "@type": "DefinedTerm", "name": "Good Issue", "description": "The SAP posting that records goods leaving stock, here triggered by a completed delivery.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#glossary" } }, { "@type": "DefinedTerm", "name": "SIOD", "description": "The distribution order system whose data is exchanged with the terminal in Citia TAS projects.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/tas-tms-sap-integration#glossary" } } ] } ] } ```