Feltnavn endret i Simplicate fakturatabeller

I dag sluttet rapportene mine plutselig å oppdatere seg. Hovedproblemet var at feltene hadde blitt omdøpt, noe som forårsaket en feil. En rekke felt er berørt:

  • id_2 > id_3
  • project_id_2 > project_id_3
  • organization_id_2 > oragnization_id_3

Hvorfor har disse feltene blitt omdøpt?

Er det mulig å sende et varsel før denne typen endringer? Det er veldig ubehagelig når jeg må forklare for lederne hvorfor rapportene ikke fungerer skikkelig i dag. Vi er avhengige av disse feltnavnene, og det er ikke god praksis å gi dem nye navn tilfeldig.

Dette er ikke første gang — et lignende problem skjedde for omtrent 1-2 år siden.

Trolig har feltnavnene endret seg på grunn av oppgraderingen fra utgivelse 25.0 til utgivelse 26.0 på Invantive Cloud / Invantive UniversalSQL kvelden 23. mars 2026.

Navnene på Simplicate-feltene blir automatisk utledet fra Simplicate sine metadata, og kan endre seg mellom hoved- og underutgivelser.

Selv om vi prøver å unngå unødvendige endringer, kan felt- og tabellnavn endre seg uventet, spesielt med dynamiske datamodeller.

Det finnes for øyeblikket ingen planer om å oppdage slike endringer mellom utgivelser og varsle på forhånd, ettersom en utgivelse settes i produksjon for alle brukere samtidig.

Dersom man trenger stabilitet i en individuell datamodell, anbefales det å sette opp et av on-premises-produktene, som for eksempel Invantive Data Hub, for å hente dataene ved hjelp av en selvvalgt versjon. Bruk av en versjonsspesifikk konfigurasjon kan redusere noen av disse problemene, men avhengig av plattformen kan den underliggende datamodellen likevel endre seg dynamisk på plattformsiden (som Simplicate, AFAS eller Odoo).

For mer bakgrunnsinformasjon, se:

Takk for svaret. Jeg forstår årsaken, men dette er egentlig «farlig» – å implementere en ny hovedversjon uten mulighet til å teste på forhånd, eller i det minste vite at det kommer til å skje.

Jeg skulle ønske det fantes et «test»-miljø der vi kunne finne ut hvilken innvirkning den nye utgivelsen har. Hva om det ikke er strukturen, men tallene eller feltinnholdet som endres? (for eksempel format, avkortede strenger) noe som kan føre til at tallene endres uten at man merker det.

Jeg godtar likevel dette faktumet – det er ikke en egnet tilnærming for å levere et rapporteringssystem.

Jeg er virkelig bekymret for dette temaet, fordi det er vanskelig å forklare ledelsen at «sånn er det bare» eller at «det kan skje med oss helt tilfeldig». Som rapporteringsansvarlig er jeg ansvarlig for dette, og det vil ødelegge omdømmet mitt. Derfor ønsker jeg en løsning som kan forhindre, eller i det minste forutsi, denne typen hendelser. Hvis jeg visste om datoen på forhånd, kunne jeg kommunisere at det er planlagt vedlikehold, og at det kan oppstå problemer. Det ville vært akseptabelt for meg, og også for ledelsen.

Dine bekymringer er forståelige.

For skyvarianten er det for øyeblikket ingen planer om å tilby en slik sandkasse eller lignende. Det anbefales å gå ut fra at dette kan skje. Selv om et slikt miljø skulle være tilgjengelig, gjenstår problemet med at mange skyleverandører ikke tilbyr det, og at de fortløpende utgir og endrer navngivninger.

For å redusere risikoen noe kan en lokal versjon benyttes, men dette fjerner ikke problemet helt, ettersom skyleverandørene man er koblet til kan endre datamodellene sine dynamisk uten forvarsel.

Hos Invantive er dette løst ved å sørge for at det er personale tilgjengelig hver dag for å håndtere skiftende og uventede forhold.

Takk for svaret. Jeg skulle ønske vi visste datoen for de store versjonsoppgraderingene. IT-tjenesteleverandører bruker nettopp denne tilnærmingen for å varsle kundene sine på forhånd. Disse oppgraderingene er planlagt og kommunisert.

Vi kan avslutte temaet.

Riktig og forståelig. For den typen kontroll tilbyr de lokale produktene (on-premises) en løsning.