Slik fikser du «Record Does Not Exist or Has Been Deleted»-feil i Odoo

Innledning

Feilmeldingen «Record does not exist or has been deleted» dukker ofte opp uventet i Odoo – når du åpner en skjema, bekrefter en post eller lar en automatisering kjøre. For mange brukere er dette ett av de mest forvirrende øyeblikkene i daglig arbeid med systemet.

Til tross for alarmlyden betyr det som regel ikke at databasen er ødelagt. Meldingen peker heller på at noe i referansene mellom poster har blitt brutt, eller at tilgang til en bestemt post er begrenset.

Her forklarer vi hva som ligger bak meldingen, hvordan du trygt finner årsaken og hvilke tiltak som løser problemet uten å skape nye feil.

Hva feilmeldingen egentlig sier

Teknisk sett skjer feilen når Odoo prøver å finne en databasepost ved hjelp av et ID-nummer som:

• ikke lenger finnes i databasen
• har blitt slettet
• er utilgjengelig på grunn av tilgangsregler
• tilhører en annen firma-kontekst i multi-company-oppsett

Eksempel som illustrerer situasjonen:

record = self.env['res.partner'].browse(45)

Hvis posten med ID 45 mangler, kaster Odoo denne feilen i stedet for å returnere et tomt resultat.

Vanlige årsaker

1. Slette poster som fortsatt er referert

Felt av typen Many2one kan peke mot poster som er fjernet, og dermed skape «orphan»-referanser i databasen.

Det skjer ofte i sammenhenger som:

• når noen manuelt sletter poster direkte i grensesnittet eller i databasen
• ved rydding av testdata etter utvikling eller demoer
• etter mislykkede importjobber som delvis oppdaterte relasjoner

2. Feil i ekstern ID-mapping

Ved integrasjoner kan eksterne systemer sende ID-er som ikke samsvarer med Odoos interne poster.

Dersom Odoo mottar en slik ID i et API-kall,

{ "partner_id": 99999 }

og det ikke finnes noen partner med dette ID-et, vil feilen utløses.

3. Multi-company og tilgangsbegrensninger

I multi-company-oppsett kan posten eksistere, men ikke være synlig under nåværende selskapskontekst eller brukerrettigheter.

Å teste med administrator- eller superuser-konto avdekker ofte om posten finnes, men er skjult for andre brukere.

4. Migrasjon og oppgraderingsproblematikk

Etter moduloppgraderinger eller datamigrasjoner kan relasjoner peke til omstrukturerte eller flyttede poster, noe som fører til manglende referanser.

Hvordan rette opp feilen

Steg 1 – Bekreft at posten finnes

Bruk ORM-sjekk før bruk:
record = self.env['model.name'].browse(record_id)
if record.exists():
    # trygt å benytte posten

Steg 2 – Sjekk tilgangsregler

Logg inn som administrator for å se om posten er tilgjengelig.

Dersom admin ser posten men ikke vanlige brukere gjør det, peker det mot en tilgangsregel eller sikkerhetsgruppe som blokkerer.

Steg 3 – Rydd opp i relasjoner

Søk etter foreldreløse Many2one-felt og oppdater dem — enten koble riktig post eller sett feltet til null for å fjerne bruddet.

Steg 4 – Verifiser eksterne integrasjoner

Gå gjennom integrasjonsflyten og se spesielt på:

• API-kall og innkommende payloads
• kartleggingslogikk mellom systemene
• synkroniseringslag og eventuelle mellomlag

Feilmatching av ID-er mellom systemer er en vanlig årsak i integrerte landskap.

Hvordan unngå at feilen oppstår

• Unngå å hardkode interne ID-er i integrasjoner eller koder
• Bruk eksterne ID-er og referansemekanismer korrekt
• Valider innkommende API-data før du prøver å knytte dem til interne poster
• Test migrasjoner og integrasjoner grundig i staging før produksjon
• Unngå å slette poster som andre objekter fortsatt refererer til

Slik unngår Dasolo «Record Does Not Exist»-problemer

Feilen oppstår ofte fordi koblingen mellom modeller er utdatert eller ødelagt. Selv om problemet ofte vises i brukergrensesnittet, ligger årsaken sjelden i UI-et – det handler som regel om slettede poster, ødelagte relasjoner eller operasjoner som har hoppet over ORM-sikkerheten.

Hos Dasolo ser vi denne feilen som et symptom på svake dataregler i systemets struktur, ikke bare en enkeltstående hendelse.

• Eksempler på hva feilen typisk avslører inkluderer foreldreløse relasjoner
• feilaktige slettestrategier som fjerner nødvendige rader
• mismatcher i integrasjoner mellom systemer
• mangel på validering før systemet prøver å åpne eller oppdatere en post
• og håndtering av multi-company-kontekst som ikke tar hensyn til synlighet og tilgang

For å forebygge bygger vi Odoo-løsninger med kontrollert datalivssyklus: i stedet for å slette kritiske poster foretrekker vi arkivering, og vi håndhever referanseintegritet gjennom ORMsafe praksis. Det reduserer overraskende «post ikke funnet»-feil i produksjon.

Oppsummering

Kort sagt: Odoo-meldingen betyr at systemet forsøker å åpne en post som enten er slettet eller aldri ble opprettet korrekt. Bak ligger ofte brutt relasjonslogikk eller usikre datamanipulasjoner – ikke nødvendigvis en ødelagt database.

Ved å holde relasjonsarkitekturen konsistent, alltid sjekke at en post finnes før den brukes, og unngå direkte databaseendringer uten ORM, reduserer utviklere og administratorer slike feil kraftig. Gode arbeidsflyter og strukturerte dataregler gir forutsigbarhet og færre produksjonsproblemer.

Å ta tak i disse problemene gir mer enn en raskere feilretting: det styrker databasen, gjør systemet mer robust og gir færre uforutsette avbrudd over tid.