01

Defineix la compatibilitat del producte

Concreta les versions i la informació admesa: conceptes, textos, descomposicions, amidaments o certificacions. Diferencia què pots llegir, editar i tornar a exportar. Un importador de tarifes i un editor complet de pressupostos tenen necessitats diferents, i l’usuari ha de conèixer aquests límits.

02

Separa lectura, validació i negoci

Separa la interpretació del fitxer de la creació d’objectes a l’aplicació. Així pots informar d’una referència desconeguda abans d’alterar un projecte. Conserva els codis d’origen i defineix-ne la relació amb els identificadors interns.

  • Lectura de registres i codificació de caràcters
  • Validació de referències i dades necessàries
  • Mapatge de conceptes, unitats i relacions
  • Tractament explícit dels registres no admesos
03

Permet revisar la importació

Abans de confirmar una càrrega, mostra què es crearà i què podria canviar. Distingeix una nova versió de pressupost d’una actualització de catàleg. Importar dues vegades el mateix fitxer no hauria de duplicar dades sense avisar. Els errors han d’identificar el registre o concepte afectat amb una explicació útil.

04

Comprova l’exportació

Genera un fitxer conforme a l’abast acordat i contrasta’l amb l’especificació i el checker oficial quan correspongui. Després obre’l als programes destinataris. Compara estructura, unitats, quantitats i càlculs: comparar només bytes no demostra equivalència, perquè l’ordre i la representació poden variar.

05

Un primer lliurament amb límits clars

El primer desenvolupament pot cobrir un circuit acotat i avisar de les dades que queden fora. Acordem mostres, resultats esperats i una estratègia per a versions futures. Segons l’arquitectura, podem estudiar un mòdul dins de l’aplicació o un servei d’intercanvi entre sistemes.