In this article
DELFOR EDIFACT mapping transforms a buyer’s forecasted delivery schedule into actionable demand records for a supplier’s ERP environment. This process, when correctly structured and tested, reduces manual planning effort, decreases data entry risk and ensures that incoming schedules flow smoothly into core demand and production systems. In many industries, especially manufacturing and automotive, DELFOR is the backbone of supplier planning, driving both forecast and firm schedule data—making accurate mapping essential for efficient operations.
What DELFOR communicates
A typical DELFOR message sent using the EDIFACT standard includes product forecasts, schedule quantities, requested delivery dates, and sometimes special planning or release instructions. These forecasts can stretch over multiple periods—weeks, months or custom timeframes—and often cover various item numbers and destination locations in a single electronic document. The information content and business meaning depend on the buyer’s ERP setup and documented trading partner guide, not just the generic EDIFACT envelope.
For the supplier, the critical output of DELFOR mapping is an accurate, traceable demand record in the ERP that references the source message and supports both future planning and execution. The mapping must handle both forecast and schedule layers, so planners understand whether quantities are estimates, firm demand or require a formal release to production or shipping.
The single most important caution: Always verify if DELFOR quantities represent forecast, firm or released demand based on the specific partner guide. Blindly treating all quantities as orders can trigger supply chain confusion or financial exposure.
How DELFOR EDIFACT mapping works
The DELFOR mapping process can be broken into discrete, practical steps:
- Document receipt and association: Receive the DELFOR message from the agreed channel (VAN, AS2, SFTP or API) and assign it to the correct trading partner and business account. Correct mailbox and identifier setup at this stage prevents misrouting and data loss.
- Validation: Check for structural integrity (envelope, syntax, segment rules), completeness, code set alignment (item, location, unit codes), and reference numbers. Use the trading partner’s published implementation guide as the authority, not just a generic DELFOR template.
- Mapping and transformation: Convert EDIFACT segment data—product codes, delivery dates, forecast ranges—into the internal structure your ERP expects. This often includes cross-referencing partner identifiers with your own item or location tables, converting units and mapping release or status codes. Handle differences in date formats and repeated records with care.
- Application of business rules: Decide whether data from this DELFOR should update an existing demand schedule, create a new schedule, or trigger exception review. For example, some suppliers update rolling forecasts automatically, while others require validation of firm schedules before acting.
- Integration with ERP or planning system: Transmit the translated and validated data to the ERP, either via batch interface, middleware, API or direct EDI integration. Detailed status and exception reporting here allows for traceability and audit.
- Acknowledgment and monitoring: If required, generate a 997 functional acknowledgment that reports on document syntax acceptance or rejection. This step confirms technical receipt, not business agreement to quantities or dates.
Each of these steps benefits from internal audit trails and clear exception routing, so operations and IT teams can trace the status of schedules and address discrepancies before they reach production.
The data structure to map
DELFOR mapping is highly hierarchical. The following table summarizes core business layers to consider during DELFOR-to-ERP mapping, including the types of business and technical questions you should resolve before automating:
| Business layer | Typical purpose | ERP handling question |
|---|---|---|
| Message identity | Identifies document, sender, receiver, message reference numbers | How does your ERP prevent duplicates? |
| Schedule context | Purpose (forecast, firm, release), date range, planning horizon | Does this add to or overwrite existing demand? |
| Product requirement | Item code, requested quantity | How does this map to your inventory/part database? |
| Delivery detail | Requested date, delivery location, special instructions | Which plant or distribution center receives the demand? |
| Control and status | Exception, warning and acknowledgment handling | Where will users see source ID, error and workflow status? |
We recommend preserving the original partner values alongside your own internal identifiers and storing the mapping version. That way, if you need to audit a change or resolve a dispute with a trading partner, you have a reliable chain of custody connecting each demand record to the original DELFOR.
Common mapping pitfalls
Confusing forecast and firm demand
Mixing these can create excess stock or missed shipments. Make sure to reference the implementation guide for each trading partner. If possible, keep forecast and firm segments or qualifiers clearly separated in your ERP.
Misinterpreting date qualifiers
DELFOR may include several types of dates (reference, delivery, planning, release), not all of which trigger the same business action. Confirm with both the partner’s specification and your own planning logic before automating this mapping step.
Unit and code mismatches
A common source of costly errors is assuming all partners use the same units or product codes. Always validate units of measure, packaging and any required code conversions. If a code or unit is missing in your ERP, route the document for exception handling rather than guessing.
Uncontrolled duplicate or overwrite logic
Delivery forecasts often replace or update previous schedules. Implement robust checks on message and schedule references to ensure you do not overwrite or duplicate demand records in error.
Assuming one standard fits all
EDIFACT provides a generic format, but real-world usage varies. Trading partner-specific implementation guides and test files are essential. Build flexibility into your mapping so you can adapt to routine changes without extensive rework.
A practical implementation and testing process
Successful DELFOR mapping is iterative. From the start, assemble these artifacts:
- Trading partner’s current implementation guide and at least one real DELFOR message
- A catalog of all expected item and location codes, units and business rules
- ERP interface specification or canonical demand structure
- Map the normal case: Test incoming DELFOR files using normal, expected data.
- Test edge cases: Submit files with missing, duplicate, mis-coded, or unexpected data types. Confirm exceptions are captured, explained and resolved.
- Review ERP output: Make sure created or updated records in your ERP reflect both the raw data and the intended business meaning.
- Simulate partner changes: When your buyer updates their requirements, document the change and test the mapping revision. At BOLD VAN, minor map changes are typically handled at no cost, but each needs review and sign-off on the resulting business logic.
- Audit before go-live: Do a reconciliation run with recent DELFOR data, ensuring that all fields, codes and responses match between the source and your destination system, and that status can be traced end-to-end.
How BOLD VAN supports DELFOR integration
BOLD VAN provides full EDIFACT and DELFOR support, with mapping and integration into ERP, WMS, TMS and e-commerce platforms. We connect directly with platforms such as SAP, Oracle ERP, Infor CloudSuite and more, and can bridge to APIs when a partner uses a non-EDI interface. For teams wanting to manage their maps, BOLD Transmission and Connectivity offers a robust VAN layer, and for those needing end-to-end integration—including mapping, cross-reference maintenance and exception handling—BOLD Integration is the practical choice.
With BOLD VAN, new maps are typically ready to test in about two days and new connections are typically live within a business day, streamlining onboarding and partner changes. Our managed approach helps reduce key-person risk and ensures that all documents, including DELFOR schedules, are tracked and searchable in the portal—making status, requeue and reporting seamless for operators and planners. VAN migrations typically take about two weeks with stated uptime of 99.996%.
For your DELFOR project, start by collecting a current sample, your trading partner’s guide and ERP requirements. The BOLD VAN team can clarify the mapping scope and process required for successful end-to-end integration without disrupting your existing systems.
Frequently asked questions
What is a DELFOR EDIFACT message?
A DELFOR EDIFACT message is a delivery schedule used by a buyer to communicate forecast demand, requested delivery timing and related planning information to a supplier. The exact content depends on the trading partner's implementation guide.
How does DELFOR mapping connect to an ERP?
The mapping validates the incoming EDIFACT document, identifies the partner and items, converts dates and quantities into the ERP's accepted structure, then sends the transformed data through the agreed integration method. The ERP uses that information for planning, scheduling or demand updates.
Does a DELFOR message create a firm customer order?
Not necessarily. DELFOR commonly communicates forecast or schedule information, but whether quantities are firm, forecast or subject to release rules depends on the trading partner's implementation guide and commercial agreement.
What does a 997 acknowledgment confirm?
A 997 functional acknowledgment tells the sender whether a document passed the receiver's syntax check. It can report acceptance or rejection, but it does not mean the order or its content was accepted.
