No data without a contract: how we map your ECC fields (and report every column we drop)
The one rule that governs every byte entering SangamIQ from your ERP — and why "we'll just ingest everything" is exactly the wrong answer.
When a planning tool connects to your ERP, the lazy design is "sync everything and sort it out later." It feels generous. It is how you end up with a shadow copy of your master data, drifting quietly out of sync, storing personal and commercial fields nobody meant to share.
We took the opposite rule: no data without a contract.
The contract
Every object you bring in — material master, plant data, stock, open POs — passes through an explicit field-mapping contract. MATNR maps to sku, WERKS maps to location, and so on. Only the fields named in the contract are stored. Everything else is dropped at the door.
And we tell you what we dropped
This is the part that matters for trust: when a column is dropped, it is reported by name. If your extract carries a ZZ_LEGACY_CODE we weren't asked to map, you'll see "ZZ_LEGACY_CODE — dropped, not stored" in the load report. No silent hoarding, no surprise on an audit.
File or RFC, same path
Per object, you choose the transport — a file drop for the slow-changing masters, an RFC for the things that move — and both travel the identical map-and-load path. On the way back out, approved plans return to ECC with their document numbers stamped, so the loop is closed and traceable end to end.
The discipline costs a little more up front. It buys you an integration your security team can actually reason about — which, at pilot, is the difference between go and no-go.
Every number in SangamIQ shows its work — see our live accuracy page, or start free and put your own CSV through it in ten minutes.