Here’s a compact, practical guide you can drop straight into an FDD.

Types of data in an FDD—and how to document them

1. Master Data (e.g., Customers, Vendors, Items)
   • Document: Data dictionary per entity (field name, description, type/length, required?, allowed values, owner/SoR, CRUD). Include data-quality rules (uniqueness, format) and stewardship.
2. Reference/Code Data (e.g., UoM, currencies, tax groups, reason codes)
   • Document: Code lists with valid values, semantics, crosswalks (old→new codes), versioning, and who maintains them.
3. Transactional Data (e.g., Sales Orders, Purchase Orders, Inventory transactions, Invoices)
   • Document: Header/line schemas, lifecycle/status model, key fields/keys, validations, and throughput/volume assumptions.
4. Configuration/Parameter Data (e.g., posting profiles, number sequences, WMS templates, planning parameters)
   • Document: Parameter tables with default values, environment-specific overrides, change control, and effective dates.
5. Integration & Audit Data (e.g., EDI payloads, API schemas, message logs, error queues)
   • Document: Interface contracts (schemas, endpoints, auth), message-level mapping, retry rules, idempotency keys, and retention/audit policy.

Tip: Add a CRUD matrix (by role/process vs. entity), data ownership (System of Record), security classification (PII/financial), and retention/archiving per entity.

Five examples of data (D365 Finance & Supply Chain)

1. Customer master (account, terms, tax group, credit limit)
2. Released product (item ID, variant, UoM, barcode/GTIN)
3. Sales order (header/lines: customer, ship-to, item, qty, price)
4. Posting profiles (AR/AP/Inventory→GL mappings)
5. Warehouse work templates & location directives (receiving/put-away rules)

How to do data mapping (field-level, source→target)

1. Inventory sources/targets: List each source system (e.g., EDI broker, CRM) and D365 target entities (e.g., SalesOrderHeaderV2/LinesV2). Mark SoR per attribute.
2. Define keys & identifiers: Customer/item cross-references, natural vs. surrogate keys, deduplication rules, and how you resolve lookups.
3. Map fields with rules: For every target field, specify source field(s), transformation (trim, parse, UoM or currency conversion, rounding), defaults, and validation.
4. Handle code lists: Create crosswalk tables for UoM, payment terms, tax groups, reason codes; document owner and change process.
5. Set constraints & data quality: Required/optional, uniqueness, domain checks, error handling (reject, correct, or default), and idempotency.
6. Consider volumes & NFRs: Batch sizes, throughput, ordering guarantees, and retry/backoff for interfaces.
7. Prove with samples: Build “golden records” and edge cases; run dry-runs to compare row/field counts and business totals.
8. Trace & govern: Tie mappings to requirements and test cases; version the mapping spec; add monitoring (counts, failures, drift).

Mini example mapping (Inbound EDI 850 → D365 Sales Order)

Source (850)	Target (D365)	Transform/Rule	Notes/Ownership
BEG03 Purchase Order Number	Sales order External document (Customer PO)	Must be unique per Customer; trim/uppercase	EDI Analyst owns cross-partner rule
N1*BT Bill-to ID	Customer account	Crosswalk Trading Partner ID → CustAccount	Master data owns crosswalk
N1*ST Ship-to address segments	Delivery address	Create/resolve address in DirParty; validate country/UoM	Address policy applies
DTM*002 Requested delivery date	Requested delivery/ship date	Time zone normalize; reject weekends if policy	Planner defines rule
PO1 (Buyer Item, Qty, UoM, Price)	Sales line (Item, Qty, UoM, Unit price)	Item cross-reference; UoM conversion; price/discount validation	Product master validates
CTT Total line count	Control total (audit log)	Compare to created lines; hard-fail on mismatch	Exceptions workbench

Suggested FDD tables/snippets to include

• Data Dictionary (per entity): Field | Description | Type/Len | Req? | Domain/Code | Default | Source | Owner | PII | Retention
• Mapping Spec (per interface): Target Entity.Field | Source System.Field | Transform | Validation | Error Action | Test Case ID
• Crosswalks: Old Code | New Code | Effective From/To | Owner | Approval Ref

With these pieces in your FDD, reviewers can see what data exists, how it’s governed, and exactly how it moves and transforms into D365.