Product master
Product ID, title, brand, GTIN and text are mapped in a clear way.
EDI · SCM · MAPPING
EDI and SCM mapping for clean data flows.
Product data, stock and orders must mean the same thing in both systems. OpenDeal maps fields, values and status codes in a clear way. This creates steady data flows and a clear path for supplier links.
Clear fields · defined rules · clear status
What mapping solves
One field needs the same meaning on both sides.
A supplier may use other labels, codes and values. Mapping resolves the gaps and shows which source field belongs to each target field.
Price
Purchase price, currency and valid values need fixed rules.
Stock
Stock and lead time must be easy to read.
Order
Order number, line, amount and delivery address remain linked.
Shipping status
Dispatch, tracking and delivery states are mapped into clear values.
Returns
Returns, errors and credits need clear status codes and links.
In short
How mapping works in daily use.
A data set comes from the partner and OpenDeal interprets it. Each attribute is checked against a clear rule. Codes are mapped when required, while pricing and stock retain their meaning. If a mandatory value is missing, the record stops and the issue is reported. Checked data can then enter the target model, while orders can move in the opposite direction. The partner receives the order and returns status and tracking, so both systems maintain the same daily state. Mapping is not a one-time import but a logged rule set for continuous exchange. Each rule has an ID, each change has a version, and tests confirm whether new data remains compatible.
Partner→Check→Map→OpenDeal→Status back
Mapping process
From source field to checked target value.
The mapping is logged and checked. A value should enter production only when its meaning is clear.
Read the source
We collect fields, data types, codes and real examples from the source system.
Define the meaning
We validate what each attribute means in the business process. A label alone is not sufficient.
Build the rule
We define the target attribute, format and any required change.
Validate values
Required attributes, units and permitted values are checked.
Send test data
Real examples run through the mapping. This makes mapping errors easy to see.
Release a version
The checked mapping receives a defined version for production use.
Core data model
A clear operational model.
Many partners provide similar data in different forms. A shared core model keeps those attributes together and makes check rules and later changes easier to manage.
- unique product and partner IDs
- clear units for amount, weight and dimensions
- one currency and price logic
- defined order and fulfilment states
- clear rules for date and time
- traceable mapping versions
Tech reference
Mapping rules need explicit semantics, validation and traceability.
A live mapping needs one logged rule set. It should name the source field, its meaning, the change rule, the target field, checks, error handling and version owner. This makes tests, daily checks and later changes easier to plan.
Transformation logic
A cleanup rule may trim values, split combined fields, change formats, calculate values or join fields. It should do this only when the business meaning stays clear and can be tested.
Code translation
A supplier may use its own status codes. Mapping can turn them into a shared set of terms. Order, shipping and error states then keep the same meaning across linked systems.
Units and precision
Amount, weight, size, currency and decimal places need clear conversion rules. A number can look valid but still mean something different in another system. Logged rules stop that mix-up.
Fallback policy
Optional data may use an approved fallback. Required fields should fail the check when data is missing. The system must not invent values that could damage later steps.
Idempotency
Message IDs and business keys stop repeated messages from creating two orders, two shipping events or mixed stock moves. Each event should have one clear key.
Reconciliation
Regular checks can compare stock, order state, shipping links and payment IDs. This makes async errors visible before they cause wider supply-chain problems.
Daily work also needs clear owners and rules for change. Define who owns the schema, which versions still work, what depends on a change, how retries work, when checks run and who handles errors. A small source change can otherwise spread wrong sales, stock or shipping data through several systems before anyone sees it.
SCM and order status
The data flow does not stop at the product.
Supply chain management also requires clear order data. Each status needs one clear meaning so both systems can interpret the next daily step.
01OrderThe order is released.
→02ResponseThe partner accepts the order.
→03DispatchTracking and ship time come back.
→04DeliveryThe state stays traceable.
→05ReturnIssues keep a clear reference.
Data quality
Good mapping needs clear checks.
A value can be valid in tech terms but wrong for the sale. Check format and business meaning separately.
01Check earlyErrors are found before the data moves on.
02Visible rulesEach check has a clear purpose.
03Explain errorsField, value and reason stay traceable.
04Move safelyOnly checked data goes to the next step.
Required fields
Missing required values are found before the next step.
Data types
Numbers, text, dates and flags must match the target attribute.
Value ranges
Invalid amounts or prices are treated as errors.
References
Order, product and partner remain linked through stable IDs.
Duplicates
A repeated message must not create a copy order.
Error path
Rejected data needs a reason, time stamp and clear owner.
Status codes
Status values need approved terms and a clear order.
Time context
Timestamp, validity and sequence should remain traceable.
Operations and checks
A mapping must also stay stable after launch.
Source systems change. New fields appear. Codes can change. Every live connection therefore needs a clear operating model.
Important errors are logged; changes get a version; when something fails, the affected message should be easy to find.
01
Versions. Mapping changes remain traceable.
02
Check. Bad values are not accepted silently.
03
Checks. Missing data and tech faults become visible.
04
Retry. A tech failure can be processed again in a controlled way.
05
Escalation. Business issues have a named contact.
Frequently asked questions
EDI and SCM mapping in plain language.
What is EDI mapping?
EDI mapping links data fields between two systems; it can also convert codes and formats.
Does every partner need EDIFACT?
No. CSV, XML, JSON or an API can also work. The best path depends on the source system.
What is part of SCM mapping?
It can include product, stock, order, shipping status and returns; more data can be added when needed.
How is a mapping tested?
Test data runs through the key rules; required fields, values and states are checked.
What happens when data fails?
The error needs a clear reason; the affected message and next step should be visible.
Can the mapping grow later?
Yes. New fields or rules can be added in a new version and tested again.
Connect a supplier
From data format to a stable process.
Do you have a product range and existing data? A small test set can be mapped first; the process can then grow step by step.