Hoe je NUMBER_OUTSIDE_VALID_RANGE in Salesforce-deployments oplost

Een numerieke veldwaarde op een op te slaan record overschrijdt het aantal cijfers of decimalen dat voor dat veld is gedefinieerd.

Treedt op bij: runtime DML, bij data loads, Apex-tests, en formule- of rollup-evaluatie

Wat het betekent

NUMBER_OUTSIDE_VALID_RANGE treedt op wanneer een waarde die naar een Number- of Currency-veld wordt geschreven meer cijfers of meer decimalen heeft dan de precisie en schaal van het veld toestaan. Salesforce definieert die limieten op het veld zelf, dus elke waarde daarbuiten wordt bij het opslaan geweigerd, ongeacht waar deze vandaan kwam.

Precisie en schaal worden ingesteld bij het aanmaken van een veld en zijn berucht moeilijk later te verbreden zonder een supportcase in sommige edities, dus deze fout wijst vaak op een velddefinitie die te klein was voor de data die het nu moet bevatten, niet slechts een eenmalige foute waarde.

Diagnose

Veelvoorkomende oorzaken

Gemigreerde data heeft meer precisie dan het veld toestaat
Brondata heeft meer decimalen dan de schaal van het doelveld, vaak afkomstig van een systeem met minder strikte numerieke opmaak.
De uitvoer van een formule of rollup overschrijdt het cijferlimiet van het veld
Een berekende waarde groeit voorbij het maximale aantal cijfers waarvoor het doelveld is gedefinieerd.
Valutaconversie introduceerde extra decimale precisie
Multi-currency-conversie produceert een waarde met meer decimalen dan de gedefinieerde schaal van het veld na afronding.

De oplossing

  1. Rond waarden af of kort ze in voordat je laadt
    Pas de migratie- of transformatiestap aan zodat deze exact overeenkomt met de precisie en schaal van het doelveld vóór de insert.
    Decimal rounded = rawValue.setScale(2, System.RoundingMode.HALF_UP);
  2. Verbreed het veld als de extra precisie legitiem is
    Verhoog het aantal decimalen of cijfers van het veld in Setup als het bedrijf dat detailniveau echt nodig heeft.
  3. Controleer formule-uitvoer tegen de velddefinitie
    Bevestig dat elke formule of rollup summary die het veld voedt geen waarde kan produceren die de numerieke limieten ervan overschrijdt.
In de praktijk

Hoe Serpent dit voorkomt

De gepoolde scratch orgs van Serpent delen dezelfde velddefinities als de branch die wordt getest, dus een migratiescript dat waarden buiten bereik produceert, faalt snel in een geïsoleerde omgeving in plaats van tijdens een gedeelde sandbox-load. Zie de bibliotheek met Salesforce-deploymentfouten.

Metadata en data in één deploymentflow in Serpent

Preventie

Dimensioneer number- en currency-velden vooraf voor de grootst realistische waarde
Schat de werkelijke maximale grootte en precisie die een veld nodig heeft al bij het ontwerp in, aangezien het later verbreden van precisie en schaal bij sommige veldconfiguraties verstorend is.
Rond expliciet af bij elk schrijfpad naar een geschaald veld
Pas setScale() toe op het punt van toewijzing in Apex en in ETL-transformaties, in plaats van erop te vertrouwen dat het platform stilzwijgend voor je afrondt.
Profileer bereiken van brondata vóór een migratie
Controleer het minimum, maximum en de decimale precisie van de daadwerkelijke brondata tegen de definitie van het doelveld voordat je een bulk load uitvoert.
Veelgestelde vragen

NUMBER_OUTSIDE_VALID_RANGE, beantwoord

Treft dit alleen Currency-velden?
Nee. Het geldt voor elk Number- of Currency-veld; de trigger is de precisie- en schaaldefinitie van het veld, niet het veldtype specifiek.
Kan ik de precisie van een Number-veld verbreden zonder bestaande data te verliezen?
Meestal wel; het verhogen van precisie of schaal is over het algemeen veilig voor bestaande records, maar bevestig dit altijd eerst in een sandbox, aangezien sommige veldconfiguraties en zeer grote bestaande datasets anders kunnen reageren.
Rondt Salesforce in sommige gevallen stilzwijgend af in plaats van te weigeren?
Nee. In tegenstelling tot sommige databases die stilzwijgend inkorten, weigert Salesforce altijd een waarde die de gedefinieerde precisie en schaal van het veld overschrijdt, in plaats van deze voor je af te ronden.

Start gratis. Geen creditcard, geen installatie, geen verplichting.

Binnen 15 minuten ingericht. Geen DevOps-medewerker nodig.

Benieuwd naar sneller releasen voordat je instapt? Laten we praten

Vrijblijvend.