TBO ERP INFRASTRUCTURE

Governance, Ownership & Support

Operational rules and contacts for Dynamics 365 F&O go-lives and data processing (kept here so the top of the page stays focused on architecture).

1. Story in Plain Language

Product/Sales agree with a vendor or customer and register them to get a Master Code. Without that code, the product cannot go live on the Portal. Portal activity is stored on the Report Server by legal entity and product. The Product Owner (Product Tech) moves data through a bidirectional API: it writes JSON into Transit and reads unprocessed/failed records to correct and repush. After data is in Transit, the ERP team owns detailed validation & fixes, then CSV generation, then staging → journal create → journal post → completed.

2. Product Onboarding

Follow the 5-step onboarding lifecycle to ensure new product integrations successfully clear commercial, technical, and ERP milestones:

3. Ownership & Control

Clear division of responsibility between Product Tech, ERP, and Finance teams ensures zero gaps during integration and daily ledger posting.

4. Prerequisites Before Transit / ERP

Strict structural prerequisites must be verified prior to passing transactions into Transit and Dynamics 365 F&O:

5. End-to-End Pipeline

Step 1 — Portal → Report Server → Transit (API)

SQL jobs on Report/application DBs transform data to compressed JSON in batches of 500. Master data is sent 1–2 hours ahead of transactions. API writes via PushERPData. On failure, API reads unprocessed/errors, data is corrected, then repushed.

Step 2 — Transit Receipt → Validation & Fixes (ERP-Owned)

After ownership switches to the ERP team, detailed validation runs (ROE rules, closed-month halt, special characters/spaces, calculated fields/grouping, sales vs purchase price alignment, masters). Failures notify Technical Product Owners; data is corrected. Only when all set does the flow continue.

Step 3 — CSV Generation → Shared Folders → Scheduler

Validated product data is written to CSV, landed in shared folders, and picked up by the recurring integrations scheduler.

Step 4 — Staging → Journal Create → Journal Post → Completed

Staging checks (mapping, masters, duplicates, currency) → journal create (GL/tax/currency/sub-ledger) → journal post (fiscal period/dimensions) → back-stamp to completed. Azure Synapse analytics is a separate track and is not part of this posting animation.

6. Common Stored Procedures (All Report DBs)

These core stored procedures power batch aggregation, transmission, validation counters, and error notifications across all source report databases:

7. Tables & Logs

Report Server (Mandatory)

Transit Database

Transit also has a dedicated table per product across legal entities, based on Gross / Net accounting behaviour.

8. IsProcess & Tracking Dates

The IsProcess status flag governs whether a record proceeds into CSV staging, triggers an automated repush, or is placed on hold:

TransitDate = first push date · UpdatedDate = last update date

9. ERP Product / Functionality Matrix

TBOI = India · TBOH = Holidays · JUMBO = Jumbonline

10. UAT Sandbox Push (Product Team)

For UAT, Product Team can write to ERP Sandbox using PushERPData:

curl --location 'https://SandboxERP.tboholidays.com/api/Transit/PushERPData?Content-type=application%2Fjson' \
--header 'Content-Type: application/json' \
--data '{
    "CompanyCode": 9999,
    "FileName": "UAT",
    "LotId": 1,
    "ERPDataJSON": "[Data in JsonString]"
}'

{
  "Status": 1,
  "LotId": 1,
  "CompanyCode": 9999,
  "FileName": "UAT",
  "Message": "Lot data accepted into Transit DB successfully. Ready for validation.",
  "TransitAuditId": 984210,
  "Timestamp": "2026-10-30T17:25:00Z"
}

ERPDataJSON must be a JSON string inside the request body. Sandbox only — not production.

11. System Glossary

Definitions of mission-critical architecture entities, systems, and protocols: