Skip to content
GTSR Solutions — connected by designGTSR Solutions
Get in touch

Integration

Integration, specifically

What gets built, what the first three flows actually do, and what happens to a message that fails at two in the morning. The flows below are the retail supply-chain case; the same pattern applies to any two systems that have to agree.

One record, entered once, reaching three systems that then hold the same value

What gets built

Three ways systems talk. All three get built here.

Which one is right is a design decision, not a preference — it depends on what the other system can do, how fresh the data needs to be, and what happens when it fails. That decision gets made once, deliberately, and written down.

API integration

Request and reply, or fire and forget

When a system can answer questions in real time, and you need the answer now — a stock check at the point of sale, an order pushed the moment it is placed. Built with authentication, rate limiting and retry handled properly, so a slow partner never takes your own systems down with it.

  • REST
  • Webhook callbacks
  • OAuth 2.0
  • Rate limiting
  • Idempotent writes

File-based integration

Scheduled, batched, still everywhere

Most large trading partners still exchange files — CSV, fixed-width, XML, and the EDI formats their compliance pack names — and will for years yet. Files arrive on a schedule, get validated before anything downstream sees them, and are archived exactly as received — so when a partner disputes what they sent, you have it.

  • SFTP
  • CSV
  • Fixed-width
  • XML
  • Scheduled batch

Event-driven integration

Something happened; several systems care

An order ships, and the warehouse, the accounting system and the customer notification all need to know. Publish the event once and let each system take it at its own pace. Adding a fourth consumer later does not mean reopening the first three.

  • Webhooks
  • Pub/sub
  • Change events
  • Queues
  • Dead-letter handling

What we build first

Three flows, specified end to end

These are the three flows an integration is built around, and they are written out here because the detail is the proof. Anyone can say they integrate systems; the question that separates people is what happens to the second copy of an order.

Purchase order to sales order

The money flow. A customer sends an order; it appears in your ERP without anyone typing it.

Trigger
A file lands on your SFTP endpoint, or the customer’s API is polled on a schedule.
Transform
Parsed — EDIFACT ORDERS, X12, CSV or whatever the customer sends — to a canonical purchase order: line items keyed on GTIN, delivery window, destination site.
Target
A sales order in your ERP, matched to the right customer, price list and warehouse.
Idempotency
Keyed on customer, order number and revision. The same order arriving twice is acknowledged and discarded, not duplicated.
Amendments
Revisions and cancellations arrive as new versions and are handled explicitly. This is where most integrations quietly break.

Despatch advice (DESADV/ASN), validated before it is sent

The one that saves you money. Retailer compliance charges are raised against this document, and validating it before it leaves you is how they are avoided.

Trigger
A shipment is confirmed in your ERP or warehouse system.
Validation
Checked against the order before it leaves you — delivery window, barcode match, quantity tolerance, carton label uniqueness, lead time.
Target
A despatch advice in the customer’s required format — EDIFACT DESADV, or an ASN where that is the term they use — with SSCC-18 carton labels generated to their specification.
Idempotency
An SSCC serial register that never reissues a number.
Replay
Correcting, not repeating. Re-sending a despatch advice raises a cancel-and-replace, because a duplicate is worse than the original error.

Stock and price synchronisation

The quiet one. It stops the question “which system is right?” from having an answer.

Trigger
A schedule, plus change events from the source system.
Transform
Canonical availability, with per-channel buffers so your online store never sells the last one twice.
Target
Your sales channels and, where required, the customer’s price catalogue.
Idempotency
Values are hashed and unchanged ones are suppressed — which keeps both the message count and your API quota down.
Failure
Per-item outcomes, never all-or-nothing. One bad product does not stop the other four thousand.

When it breaks

Every failure is one of four things

An integration that never fails does not exist. What separates a good one is that each kind of failure has a defined owner, a defined behaviour, and a defined way back — decided at design time, not invented at six in the morning.

Resolvable by you

Your data, your fix

An unrecognised product code, a price that does not exist, an address the courier rejects. These are parked, not failed — your own staff resolve them in the console and the message continues. No ticket, no waiting on us.

We are paged

Our problem

A mapping defect, a deployment fault, anything we built behaving other than as designed. That pages us, and it is fixed under the monthly fee.

Queued and retried

Their outage

The customer’s endpoint is down or the ERP vendor is having a bad day. Messages queue and retry with increasing backoff. Nothing is lost, and you are told before you notice.

Quarantined

Genuinely malformed

A file that is not what it claims to be. Quarantined without retry, because retrying broken input just produces the same failure more expensively. You get told what arrived and what was wrong with it.

The first category is the important one. If your staff cannot resolve their own data problems without us, every new product code becomes our phone call and your delay — so the console is built around that from day one.

What gets connected

The systems an integration like this touches

This is the landscape, not a list of prebuilt adapters — each connection is designed against that system’s own interface and your actual process. If yours is not here, it almost certainly still has a way in.

ERP & accounting

  • NetSuite
  • Dynamics 365 Business Central
  • Xero
  • MYOB
  • Cin7
  • Unleashed

Sales channels

  • Shopify
  • BigCommerce
  • WooCommerce
  • Amazon
  • Square
  • Lightspeed

Warehouse & logistics

  • 3PL warehouse systems
  • Carrier despatch and tracking
  • Barcode and label generation
  • Stock and bin movements

Trading partners

  • Grocery and hardware retailers
  • Department stores
  • Marketplaces
  • E-invoicing via a third-party Peppol Access Point (we are not one)

Tell us how the data moves today

Including the spreadsheet. Especially the spreadsheet. One conversation is enough to say whether there is anything worth doing here.

Send an enquiryhello@GTSRSolutions.com.au