Document Integration
Why trace a TPS submission before sending it again?
An uncertain response calls for status checks, transaction identity and a clear correction trail.
- Topic
- Document Integration
- Updated
- 5 November 2026
- Reading time
- 2 min
- Sections
- 5
One submission has several stages
Preparing data, sending a request, receiving a response and observing portal status are different events. An application needs to explain which stage is known and which still requires checking.
INTEGRA TPS Integration material treats status checking and uncertain-response handling as part of the workflow. A submission status should not be translated into a guarantee that every administrative process is complete.
Prepare the data
Data is made ready for submission.
Send the request
A timeout can occur after the request has left the application.
Receive the response
The response may be uncertain.
Observe the portal status
A different event from the response.
Uncertainty is not an instruction to immediately resend
A timeout can occur after a request has left the application. Resending without knowing the earlier status risks obscuring the relationship between references. Start with the document identity, submission time and available response history.
The checking procedure must follow the interface and requirements applicable to the implementation environment. This article explains product status-management principles rather than replacing official regulator instructions.
Corrections need to preserve document relationships
Reference numbers, BL records, receiving/delivery relationships and change history help explain what was corrected. The TPS presentation discusses corrections with a new reference and duplicate-report prevention.
Before creating a correction, operators need the original data, reason for change and known status. Correction permissions and action records must match application roles.
A submission status should not be translated into a guarantee that every administrative process is complete.
Document balance is not tank level
Delivery can change a BL balance through document transactions. Physical tank conditions come from measurements and inventory procedures. Reconciliation requires correct timing and transaction relationships.
A dashboard with a tank illustration also needs to explain its data source. A visual display does not by itself mean the data comes from live ATG measurements.
What to cover in a technical demo
Use scenarios covering normal responses, uncertain status, corrections and delivery. This shows application behavior when operators need help, rather than only a successful path.
- Data sources and pre-submission checks
- Transaction identity and status history
- Correction permissions and reference relationships
- Delivery effects on balances and reporting
Next step
Prepare the technical discussion for your facility.
Bring the equipment list, diagrams and symptoms you have. The Citia team helps map the next step.