Skriv et endringsforslag med feilbilde og konsekvens
Et godt endringsforslag gjør det mulig å forstå problemet og vurdere løsningen uten tilgang til virksomhetens produksjonsdata.
«Formatet burde være enklere» gir en forvalter lite å arbeide med. Et nyttig endringsforslag viser hvilken oppgave som ikke kan utføres, hva dagens regel sier og hvordan et konkret eksempel blir behandlet. Beskriv problemet før dere binder dere til en løsning.
Kontroller først at problemet ikke allerede er løst i en nyere utgave eller omtalt i gjeldende veiledning. Et forslag basert på en gammel versjon kan ellers bruke tid på en feil som mottakeren allerede har rettet.
Et fiktivt eksempel på en lokal datakontrakt
En kontrakt har bare ett kontaktfelt per leverandør. Innkjøp trenger en ordrekontakt, mens fakturabehandling trenger en økonomikontakt. Virksomheten foreslår en struktur med kontaktrolle i stedet for å legge begge e-postadressene i samme tekstfelt.
| Del av forslaget | Konkret innhold |
|---|---|
| Dagens regel | Ett kontaktfelt uten rolle |
| Feilbilde | Ordrehenvendelser går til økonomiavdelingen |
| Konsekvens | Manuell videresending og forsinket avklaring |
| Forslag | Flere kontakter med avtalt rollekode |
| Kompatibilitet | Bevar gammel kontakt som standardkontakt i overgang |
| Test | Én leverandør med to roller og to mottakere |
Eksemplet gjelder en lokal kontrakt. Det er ikke en påstand om at SAF-T eller Peppol mangler en bestemt kontaktstruktur.
Gjør eksemplet lite og trygt å dele
Lag et syntetisk eksempel med de feltene som er nødvendige for å vise problemet. Oppgi formatversjon, regel-ID der den finnes, og forventet resultat. Unngå å sende hele regnskapsarkivet eller fakturaer med personopplysninger som feilrapport.
Det bør være mulig å gjenskape feilbildet uten virksomhetens spesielle driftsmiljø. Dersom problemet bare oppstår med en bestemt leverandør, beskriv leverandørens tolkning som en separat observasjon. Det kan være en implementeringsfeil fremfor en feil i formatet.
Vurder alternativer og overgang
Forklar om problemet kan løses gjennom bedre dokumentasjon, en kodeliste, et nytt felt eller en ny prosess. Et nytt obligatorisk felt kan løse ett behov og samtidig bryte gamle avsendere. Beskriv derfor hvordan eksisterende leveranser skal behandles.
Et forslag bør ha en avgrenset konklusjon: hva dere ber forvalteren vurdere, og hvilket resultat som ville løst feilbildet. Ikke presenter virksomhetens forslag som vedtatt standard før det faktisk er vedtatt og publisert.
Bevar innsendt utgave, mottaksbekreftelse og senere svar. Når dokumentasjonen endres, skal det fremgå om løsningen er et forslag, et besluttet tiltak eller en publisert regel.
Les faglige problemnotater og bruddvurderingen.