A field map states how each source value becomes a target value, including identifiers, required fields, units, dates and status rules. A data dictionary explains what those values mean. Define transformations and exception handling before import, then test a linked sample. Matching column names alone cannot establish that records will retain their business meaning.
- Document meaning and transformations beside column names.
- Preserve stable source identifiers for reconciliation.
- Test dates, units and statuses with known boundary cases.
Describe both sides of the map
List the source file, source field, target record and target field. Add a plain-language definition and requiredness. Two columns named status may describe different things: payment state in one system and fulfilment state in another. Their identical labels do not make a direct mapping correct.
Include who approves each business interpretation. Technical implementers can apply transformations, but process owners must confirm meaning. Record target constraints using current candidate documentation, such as accepted values and relationship requirements, without assuming every micro-ERP importer uses the same conventions or supports the same field types.
Protect identifiers and relationships
Preserve original keys in a suitable reference field where the design allows it. Define new identifiers and a crosswalk when the target generates its own. This lets reviewers trace an imported record back to its source and reconnect transactions without relying on names that may be ambiguous.
Check formatting risks such as leading zeros, long numeric codes and case-sensitive references. Avoid spreadsheet transformations that silently alter an item code. Treat identifier validation separately from visual appearance; a number displayed neatly in a cell may already have lost information needed for reliable matching.
Write transformation rules explicitly
Specify date format, timezone interpretation, decimal conventions and units of measure. Define what happens to blank values and unsupported statuses. Do not replace missing information with a plausible default unless the business owner agrees and the transformation is recorded. Otherwise cleanup can invent facts rather than preserve data.
Keep rejected rows available for authorized correction with clear reason categories. Decide whether a batch stops on error or valid rows proceed, based on the actual tool. That behavior influences rerun and reconciliation, so it belongs in the field map and migration procedure.
Use an illustrative units example
Illustrative scenario: a supplier file records stock in boxes, each containing twelve units, while the target item ledger uses individual units. The map includes pack size and a conversion rule. A row with unknown pack size is rejected for review rather than multiplied by an assumed number.
The test includes one partial box, one item with a different pack size and a leading-zero item code. Reviewers compare expected quantities and references after import. This reveals semantic errors that a file passing basic format validation could still carry into the new stock ledger.
Validate a connected sample
Import a sample containing related master records and transactions, then inspect their links and calculated outputs. Test boundary dates and status transitions as well as normal rows. A field map succeeds when users can explain the resulting records, not only when the importer reports that the file was accepted.
Record which transformations were applied and which records required manual decisions. Reconcile counts and important totals with the source sample. Update the map when errors reveal a missing rule, and rerun the relevant sample before applying the revised transformation to the full dataset.
Version and hand over the dictionary
Give the map a version, approval date and owner. Retain changes with reasons, especially after a rehearsal or new source export. Use the approved version for each migration run and record it in the execution log; otherwise two batches can silently use different interpretations.
Keep the dictionary available to report owners and support staff after launch. Its explanations of statuses and references remain useful beyond migration. EasyManageX categories can help frame data domains, but field behavior and import constraints must come from the actual candidate and configured environment.
Your working checklist
- List source and target definitions.
- Approve business interpretations.
- Preserve source references or a crosswalk.
- Specify date, unit and status rules.
- Define rejection handling.
- Import and reconcile a linked sample.
- Version the approved dictionary.
Common questions
Can column-name matching automate the whole map?+
It can assist with straightforward fields, but cannot reliably determine meaning, units or relationship rules. Review every critical mapping with a process owner. Identical names may represent different concepts, and different names may represent the same value, so semantic validation is still necessary.
Should missing values use defaults?+
Only when the default is valid for the business meaning and an accountable owner approves it. Record the transformation and its scope. For unknown identifiers, quantities or required statuses, rejection and correction may be more appropriate than inserting a plausible value that hides a source-data problem.
Who owns the data dictionary after migration?+
Assign an operational owner for business definitions and a technical owner for implementation details where appropriate. Reports, integrations and new staff will continue to rely on those meanings. Update the dictionary when workflows or fields change rather than abandoning it once the first import finishes.
Sources and further reading
These primary references explain relevant concepts. Our scenarios and working checklists are original, illustrative guidance.
- ERPNext documentation: Data Import
Templates, validation errors, record keys and CSV imports. This is further reading, not a claim about EasyManageX products.
- ERPNext documentation: Stock Reconciliation
Physical counts, opening balances and reconciliation workflows. This is further reading, not a claim about EasyManageX products.
- RFC Editor: RFC 4180 CSV format
CSV record format and interoperability; validate each target system import contract.
Published by EasyManageX as practical, AI-assisted guidance. Examples are illustrative. Confirm software capabilities, licence terms and project-specific requirements before committing. Read our editorial policy.
