Define compatibility for your product
Specify supported versions and information: concepts, text, breakdowns, quantities or valuations. Distinguish what your application can read, edit and export again. A price-list importer and a complete estimating editor have different needs, and users should understand those limits.
Separate parsing, validation and business logic
Keep file interpretation separate from creating objects in your application. This lets you report an unknown reference before changing a project. Retain source codes and define their relationship to internal identifiers.
- Record parsing and character encoding
- Reference and required-data validation
- Mapping concepts, units and relationships
- An explicit policy for unsupported records
Make imports reviewable
Before confirming an import, show what will be created and what could change. Distinguish a new estimate version from a catalogue update. Importing the same file twice should not silently duplicate data. Errors should identify the affected record or concept with an explanation that helps the user correct it.
Test exports against clear criteria
Generate a file within the agreed scope and check it against the specification and official checker where applicable. Then open it in the receiving applications. Compare structure, units, quantities and calculations. Byte-for-byte comparison alone does not establish equivalence because order and representation can differ.
A first release with a clear scope
An initial development can cover a specific workflow and report information outside its scope. Agree on representative samples, expected results and a strategy for future versions. Depending on your architecture, we can assess an application module or an exchange service between systems.