Konfigurasjon av fakturautvidelsen

Når du konfigurerer Rossum-utvidelsen, finnes det noen alternativer du kan justere for å tilpasse fakturaprosessen slik at den passer bedre til din organisasjon. Disse konfigurasjonsalternativene angis i utvidelsesinnstillingene via Rossum-brukergrensesnittet.

Disse bør skrives i JSON-format.

info

De fleste parametrene her er valgfrie, med unntak av invoiceDocumentTypes og erpVersion. Hvis andre parametere ikke er angitt, bruker vi standardverdiene våre.

Det eneste andre unntaket er ei02Variant, som er obligatorisk HVIS du bruker ERP7-/ERPCR-versjonen av koblingen.

Parameterdefinisjoner og bruk

Systemoppsett

clientId

string

{ "clientId": "ABC" }

Hvis dette angis, vil ALLE ERP-forespørsler være begrenset til denne klient-ID-en.

Hvis den ikke er angitt, vil vi forsøke å lese denne per dokument fra dataene i Rossum-brukergrensesnittet. Hvis den ikke er angitt der, vil det blir gjort et forsøk på å fastslå klient-ID-en ut fra de tilgjengelige innkjøpsordredetaljene.

De fleste påfølgende oppslag vil mislykkes hvis vi ikke kan fastslå en klient-ID, og vi anbefaler derfor å spesifisere dette i konfigurasjonen der det er mulig, da det har stor betydning for systemets pålitelighet.

legalEntityIndex

tall

{"legalEntityIndex": 7 }

Bør settes til nummeret på den juridiske enhetens dimensjon for kunden.

Hvis dette er angitt, vil systemet forsøke å [identifisere koder for juridiske enheter og anvende disse på regnskapsinformasjon](../../user-guide/guides/legal-entities.md

) for fakturaer som ikke er knyttet til innkjøpsordrer.

erpVersion

'erpx' | 'erp7' | 'erpcr'

{ "erpVersion": "erp7" }

ERP-versjonen. Dette er viktig for at vi skal vite hvilke endepunkter vi skal bruke for å hente data fra og sende data til.

• ERPx Unit4s ERPx-system
• ERPCR Unit4s ERP CR-system; du bruker sannsynligvis dette systemet hvis du bruker Unit4 Cloud.
• ERP7 Dette er mest sannsynlig den versjonen du bruker hvis serverne dine ikke driftes av Unit4.

transactionType

string

{ "transactionType": "T1" }

Dette er ERP-transaksjonstypekoden som vi vil sende videre til ERP-systemet ditt når vi sender fakturaen, enten direkte i JSON-formatet for ERPx eller som parameteren for innkommende fakturatransaksjonstype på EI02 for ERP7 / CR

ei02Variant

tall

{ "ei02Variant": 0 }

Dette er påkrevd for milepæl syv; dette er EI02-rapportvarianten som vil kjøres når fakturaen bokføres.

invoiceDocumentTypes:

string[]

{ "invoiceDocumentTypes": ["IINV", "XYZ"] }

Dette er listen over dokumenttyper som vi aksepterer som fakturaer. Hvis det bare er én type, vil vi pålegge den; ellers vil vi bruke den første som standard, men la brukeren endre den i brukergrensesnittet.

For helautomatiserte prosesser betyr dette at docType ALLTID vil være den første i listen. Hvis du trenger manuell kontroll, må du sørge for at automatisk behandling er deaktivert.

locale

'en' | 'no' | 'sv' | 'es' | 'fr' | 'cy'

{ "locale": "en" }

Bare akkurat disse strengene godtas som gyldige språkinnstillinger. Hvis ikke angitt, vil vi bruke en

Noen meldinger blir kanskje ikke oversatt, da vi må dekode og validere hendelsen før vi kan bruke språket. Så hvis vi mislykkes før det, vil feilmeldingene være på engelsk.

erpHeaders

Record<string, string="">

{
    "erpHeaders": {
        "X-ACME-RequestOrigin": "ERP Apps OCR",
        "X-ACME-UUID": "0c12f153-36f7-4b76-962c-e97c82a491e8"
    }
}

Hvis dette er angitt, vil vi videresende disse overskriftene til ERP-systemet.

Dette kan for eksempel være nyttig hvis du har et selvhostet ERP-system som du ønsker å kontrollere tilgangen til.

Du kan bruke dette til å angi en forhåndsdefinert overskrift som kan brukes på en lastbalanser eller omvendt proxy for å kontrollere tilgangen til ERP-systemet.

Hvis det sendes en forespørsel til ERP-systemet uten denne overskriften, kan den avvises av lastbalanseren eller den omvendte proxyen uten at den når selve serveren.

Du kan også ønske å bruke dette til analyse- eller loggføringsformål.

attachMessagesDocument

none | warning | all

{ "attachMessagesDocument": "all" }

Hvilke meldinger som skal legges ved transaksjonen i ERP som et sekundært dokument. (Disse vil bli lagt ved som zzzz_messages....) Dette er kopier av meldingene vi sender til Rossum-brukergrensesnittet, slik at ERP-brukere har langvarig tilgang til de samme meldingene.

• none vil aldri legge ved meldinger.
• warning vil legge ved meldinger på advarselsnivå eller høyere.
• all vil legge ved alle meldinger, inkludert info

Hvis ikke angitt, er standardinnstillingen all.

Konfigurasjon av ERP-tilkobling

warning

Merk at disse tilkoblingsinnstillingene nå kan angis i utvidelseshemmeligheter (der de tidligere lå) ELLER her i innstillingene (for bedre oversikt).

Hvis noen av disse verdiene er angitt begge steder, vil den som er angitt her i innstillingene ha forrang.

erpConnectionSettings

{ unit4ApiUrl?: string, unit4SoapUrl?: string, erpxHost?: string, erpIdsHost?: string

{
    "erpConnectionSettings" :{
    "unit4ApiUrl": "https://example.unit4cloud.com",
    "unit4SoapUrl": "https://example.unit4cloud.com" ,
    "erpxHost": "https://example.unit4cloud.com",
    "erpIdsHost": "https://example.unit4cloud.com"
    }
}

unit4ApiUrl og unit4SoapUrl er påkrevd for ERP7-/ERPCR-systemer.

erpxHost er påkrevd på et ERPx-system

erpIdsHost er påkrevd på alle systemer som bruker IDS for autentisering.

Dokumentbehandling

manualTaxCodeIds

string[]

{ "manualTaxCodeIds": ["0", "1", "11"] }

Hvis dette angis, vil vi begrense skattekodene for linjer som ikke er knyttet til innkjøpsordre (AP / ekstra innkjøpsordrelinjer / fakturalinjer uten innkjøpsordre) til kun de som er oppført her.

Fakturalinjer som samsvarer med en innkjøpsordrelinje, vil fortsatt bruke skattekodene fra innkjøpsordren som angitt.

allowedTaxRates

number[]

{ "allowedTaxRates": [0.2, 0.05] }

Hvis dette angis, vil vi begrense skattesatsene til kun de som er oppført her. Hvis vi avrunder til nær en av disse, vil vi «justeres» til den. Hvis vi avrunder til en sats som ikke er på denne listen, vil vi ignorere den og anta at det er en OCR- eller fakturafeil.

allowAnyTaxCoding

boolean

{ "allowAnyTaxCoding": false }

Hvis dette er satt til true, vil systemet alltid tillate at hvilken som helst skattekode (som overholder fakturavalutaen) og hvilket som helst skattesystem velges manuelt i kontokodingen, uavhengig av skatteprosent, kontoregler, om dokumentet er en innkjøpsordre eller innstillingene i manualTaxCodeIds.

Merk at valg av en skattekode som ikke samsvarer med skatteprosenten eller valutaen på fakturalinjen, vil generere en ACL_004-advarsel eller -feil, fordi det å la dette gå videre til ERP sannsynligvis vil føre til at importtjenesten rapporterer dokumentet som ubalansert. Denne innstillingen er imidlertid spesifikt etterspurt av kunder for å gi dem muligheten til å registrere skattekoden før import, og oppdatere innkjøpsordren med denne skattekoden (ved hjelp av verktøy i Unit4)

Hvis denne innstillingen ikke er angitt, eller er satt til «false», vil de tilgjengelige skattekodene være begrenset av manualTaxCodeIds samt skattesatsen og valutaen på fakturaen.

noPurchaseOrder

{ base: 'allow' | 'reject'; perSupplier: 'allow' | 'reject' | null; }

{
    "noPurchaseOrder": {
        "base": "allow",
        "perSupplier": "supppoctrl/no_po_no_pay_fx"
    }
}

Dette brukes til å avgjøre om vi kan utstede fakturaer uten innkjøpsordre. Hvis base er 'reject', vil vi avvise alle fakturaer uten innkjøpsordre. Hvis base er 'allow', vil vi tillate fakturaer uten innkjøpsordre.

Hvis perSupplier er angitt, vil vi se etter et customField (flexifield) hos leverandøren, og hvis det finnes, vil vi behandle verdien som basisverdien for den leverandøren. Denne verdien bør være enten allow eller reject (eller ikke være til stede), så flexifield bør konfigureres med disse alternativene. Et eksempel på en verdi for perSupplier-feltet kan være noe i stil med supppoctrl/no_po_no_pay_fx Hvis det ikke finnes, vil vi bruke basisverdien.

singleLineMatch

'force' | 'auto'

{ "singleLineMatch": "force" }

Hvis denne innstillingen ikke er angitt i konfigurasjonen, vil auto bli brukt

Dette brukes til å tvinge samsvar av innkjøpsordrer med én linje på kønivå. Hvis satt til "force", vil systemet for ordrer der det bare er én linje på ordren (uansett status), vil systemet automatisk matche ALLE fakturalinjer mot den ene ordrelinjen.

Hvis den er satt til "auto", vil linjen kun bli matchet hvis den standard automatiske matchingsprosessen finner en linje å matche mot basert på tilgjengelige data.

lineRoundingTolerance

'nearest' | 'floor'

{ "lineRoundingTolerance": "floor" }

Hvis denne innstillingen ikke er angitt i konfigurasjonen, vil nearest bli brukt

Dette styrer hvor stor avrundingstoleranse som er tillatt når verdiene i en linje (f.eks. enhetspris * antall) sammenlignes med verdien som er trykt på fakturaen.

De fleste leverandører avrunder linjesummer til nærmeste penny, og i slike tilfeller kan den utskrevne verdien lovlig avvike fra verdien med full presisjon med opptil en halv penny per vare i begge retninger. Dette er standardinnstillingen ("nearest").

Noen leverandører avrunder i stedet alltid linjesummer ned (avkorter) i stedet for å avrunde til nærmeste. Siden avrunding nedover aldri avrunder opp, kan den utskrevne verdien ligge under verdien med full-presisjonsverdien med opptil en hel penny per vare – det dobbelte av standardtoleransen. Sett dette til "floor" for køer der det er kjent at leverandøren avrunder linjeverdiene ned, slik at undervurdering tolereres opptil en hel penny per vare. En overskridelse (utskrevet verdi større enn verdien med full presisjon) tolereres fortsatt bare med en halv penny per vare, siden avkorting aldri forklarer en overskridelse.

roundingMode

'item' | 'line' | 'total'

{ "roundingMode": "line" }

Hvis denne innstillingen ikke er angitt i konfigurasjonen, vil line bli brukt

Dette styrer hvor, under linjenormalisering, en linjes netto-/brutto-/skatteverdier avrundes til to desimaler. Interne beregninger holdes ellers med full flytende desimalpresisjon gjennom hele prosessen – dette er den eneste bevisste avrundingen. Den er uavhengig av lineRoundingTolerance ovenfor, som styrer sammenligningstoleransen snarere enn beregningen, og de to innstillingene kan brukes sammen.

• "item": avrund enhetsverdiene først, og utvid deretter med antall. Dette gjenskaper avrunding per enhet før utvidelse. Kun valgfri, for leverandører som er kjent for å avrunde per enhet før utvidelse – det kan medføre en feil på opptil en halv penny per vare sammenlignet med linjeverdien med full presisjon.
• "line" (standard): avrunde én gang på det oppløste linjetotalnivået. Samsvarer med eksisterende oppførsel når ingen enhetsverdier er oppgitt, og unngår avrundingsfeilen som "item" kan medføre når enhetsverdier er oppgitt.
• "total": ikke avrund linjen i det hele tatt under normalisering – behold full presisjon, slik at summering av mange linjer for kontroll av overskriftssummen ikke medfører noen sammensatt avrundingsfeil. Skiller seg kun merkbart fra "line" på fakturaer med flere linjer.

validPOStatus

string[]

{ "validPOStatus": ["O","F"] }

Hvis denne innstillingen ikke er angitt i konfigurasjonen, vil vårt standardfilter status NOT IN (N, P, T) bli brukt

Dette brukes til å angi status for overskriften på innkjøpsordrer som anses som gyldige for samsvar. Hvis dette er angitt og en innkjøpsordre returneres, men ikke har en av de angitte statusene, vil den ikke brukes til samsvar og vil ikke sendes videre til ERP-systemet sammen med fakturadataene. Brukeren vil vises en advarsel hvis en innkjøpsordre ble funnet av OCR, men ikke matchet.

validSupplierStatus

string[]

{ "validSupplierStatus": ["N","P","C","T"] }

Hvis denne innstillingen ikke er angitt i konfigurasjonen, vil vårt standardfilter status = N bli brukt

Noen kunder har bedt om at ikke-aktive leverandører skal matches i OCR-prosessen, men at det skal vises en feilmelding hvis dette er tilfelle. De ønsker for eksempel å vite at leverandøren eksisterer og var det beste treffet, men at den er nedlagt.

For å unngå å endre vår opprinnelige funksjonalitet, lar denne nye statusen deg angi gyldig status for leverandører, som vil bli brukt når leverandører hentes fra ERP-API-et.

Du kan motta feilmelding SU_017 hvis leverandøren ikke har status N eller P, og advarsel SU_018 hvis leverandøren har status P. SU_018 kan også oppgraderes til en feil.

matchFirstFoundSupplier

boolean

{ "matchFirstFoundSupplier": false }

Hvis denne innstillingen ikke er angitt i konfigurasjonen, settes den som standard til true, noe som var den opprinnelige funksjonaliteten, ment for økt automatisering.

Når vi søker etter en leverandør søker vi i ERP-systemet etter flere kriterier: leverandørnavn, MVA-nummer, organisasjonsnummer og bankopplysninger. Noen ganger har flere leverandørposter samme verdi for ett av disse kriteriene, slik at ett enkelt kriterium gir to eller flere kandidater.

Med denne innstillingen satt til true, bruker vi den første leverandøren som blir funnet.

Sett den til false, så velger vi ikke mellom dem. Sammenligningen går gjennom leverandørstatusene i rekkefølge: først aktive (N), deretter parkerte (P) og til slutt alle andre resultater søket ga; og tvetydighet vurderes kun innenfor den aktuelle sjekken. Et samsvarende kriterium som deles av én N- og én P-leverandør er derfor ikke tvetydig: på det tidspunktet er den aktive leverandøren det eneste alternativet, og den blir valgt. Der to eller flere leverandører i samme kontroll deler verdien, hoppes dette kriteriet over til fordel for det neste, som fortsatt kan identifisere én enkelt leverandør. Hvis ingen identifiserer en unik leverandør, forblir dokumentet uten samsvar med feilmelding SU_016, og alle kandidater som søket returnerte, vises i leverandørmenyen slik at brukeren kan velge blant dem.

Dette påvirker ikke en leverandør hentet fra en innkjøpsordre, eller en som brukeren har valgt manuelt, da begge identifiserer en leverandør ved hjelp av ID-en.

Merk at defaultSupplierId, der det er konfigurert, fortsatt gjelder. Et dokument vi avstår fra å gjette på, blir sendt til den leverandøren i stedet for å forbli uten match, da de to innstillingene svarer på forskjellige spørsmål: denne spør om man skal velge mellom kandidater, mens defaultSupplierId spør hva man skal gjøre når ingen kandidat ble identifisert i det hele tatt.

apDefaultDims

{ dim1?: string|number, dim3?: string|number, dim3?: string|number, dim4?: string|number, dim5?: string|number, dim6?: string|number, dim7?: string|number }

{
   "apDefaultDims": {
        "dim1": 3000,
        "dim2": "ABC",
        "dim4": "Egendefinert verdi"
   }
}

Vi bruker disse standardverdiene for å muliggjøre automatisk innsending.

På AP-linjen henter vi konto fra leverandørgruppen og fyller deretter ut alle gyldige dimensjoner med dimensjonene herfra.

Hvis disse ikke er oppgitt, må de fylles ut manuelt i brukergrensesnittet.

glDefaultDims

{ account?: string, dim1?: string|number, dim3?: string|number, dim3?: string|number, dim4?: string|number, dim5?: string|number, dim6?: string|number, dim7?: string|number }

{
    "glDefaultDims": {
        "dim1": 3001,
        "dim2": "ABC",
        "dim6": "Egendefinert verdi",
        "account": "3000"
    }
}

For fakturaer uten innkjøpsordre vil vi bruke disse standardverdiene for å muliggjøre automatisk innsending.

Hvis disse ikke er oppgitt, må de fylles ut manuelt i brukergrensesnittet.

defaultQuantity

tall

{ "defaultQuantity": 1 }

Hvis vi ikke kan lese av antall for en varelinje, vil vi bruke denne verdien som standard.

defaultSupplierId

streng

{ "defaultSupplierId": "1000" }

Hvis vi ikke kan identifisere en leverandør, vil vi bruke denne verdien som standard.

Før vi bruker dette, sjekker vi innkjøpsordren for en leverandør, og deretter søker vi i feltene for organisasjonsnummer, MVA-nummer og bankopplysninger etter en leverandør. Hvis vi finner en match på noen av disse, vil vi bruke den. Hvis ikke, vil vi bruke denne verdien når den er angitt.

defaultAccountable

string

{ "defaultAccountable": "101" }

Vi prøver å finne en match mellom den aktive Rossum-brukeren og en ERP-bruker. Hvis dette lykkes, vil vi angi denne ERP-brukeren som ansvarlig person for denne fakturaen.

Hvis vi ikke klarer å matche brukeren, vil vi falle tilbake på denne verdien når den er angitt.

Denne verdien vil til slutt vises i feltet «ext_ref» på fakturatransaksjonen

ignoreTax

boolean

{ "ignoreTax": false }

Dette medfører ingen store endringer i brukergrensesnittet, men når fakturaen sendes til ERP, vil vi kun sende bruttoverdier og sette all skatt til null.

Dette er en innstilling som sjelden brukes, og er beregnet på spesielle typer organisasjoner som aldri håndterer merverdiavgift eller andre avgiftssatser, og som kun forvalter bruttoverdier internt. Vi beholder avgiften i brukergrensesnittet selv når denne innstillingen er aktivert, for å sikre at fakturalinjene stemmer overens med overskriften, men vi vil ikke sende avgiften til ERP-systemet.

taxCodeAttrId

string

{ "taxCodeAttrId": "A1" }

Dette brukes til å slå opp attributtrelasjoner og i verdimatriser, dersom du har en konfigurasjon der skattekoden er knyttet til regnskapsdimensjoner.

Hvis dette ikke angis, vil vi bruke verdien A1, så vi anbefaler på det sterkeste å overstyre dette hvis du bruker en annen attributt-ID for skattekoder.

taxSystemAttrId

string

{ "taxSystemAttrId": "GK" }

Når vi ber om konfigurasjon av skattesystemet fra ERP7/ERPCr, vil vi bruke denne attributt-ID-en som identifikator. Hvis dette ikke angis, vil standardverdien GK brukes, så vi anbefaler på det sterkeste at du overskriver dette hvis du bruker en annen attributt-ID for skattesystemer.

Dette brukes også til å slå opp attributtrelasjoner og i verdimatriser.

ignoreZeroRows

boolean

{ "ignoreZeroRows": true }

Hvis true, vil en rad med nullverdier vise en informasjonsmelding, men deretter bli filtrert ut før den sendes til ERP.

Hvis false, vil en rad med nullverdier vise en feilmelding og blokkere innsendingen inntil den er manuelt korrigert i brukergrensesnittet.

headerOnly

{ base: true | false ; perSupplier: string | null; }

{ "headerOnly": {
        "base": true,
        "perSupplier": "supocrctrl/header_only_fx"
    }
}

Dette kan slås på eller av på kønivå ved å sette base til true eller false, men du kan deretter overstyre dette for hver enkelt leverandør. Vi vil se etter et customField (flexifield) på leverandøren, og hvis vi finner det, vil vi behandle verdien som basisverdien for den aktuelle leverandøren.

Denne verdien bør være et avkryssingsfelt på flexifieldet, da dette da er «true» eller «false».

Et eksempel på en verdi for feltet «perSupplier» kan være noe i stil med supocrctrl/header_only_fx (dette kan være et annet felt på samme flexifield som det som brukes for innstillingen «no po no pay»)

Hvis verdien er «sann» enten per kø eller per leverandør, ignoreres de uttrukne linjepostene fullstendig. Det genereres én enkelt fakturalinje som inneholder de fullstendige totalene fra overskriften (netto / moms / brutto), sammen med den tilhørende hovedboklinjen og leverandørregningslinjen. Alle de vanlige balansevalideringene kjøres fortsatt, men mot denne genererte linjen, slik at de går i balanse.

Dette er for kunder som kun ønsker å bokføre verdier fra overskriften og la ERP-systemet (eller en nedstrømsprosess) håndtere detaljene.

glDefaultDims.account må være en gyldig ERP-konto, ellers vil den genererte linjen bli blokkert av valideringen «velg kontokode».

Hvis ingen verdi angis, vil den bli behandlet som false

autoGenerateGlLine

boolean

{ "autoGenerateGlLine": true }

En reserve løsning for når ingen linjeposter ble hentet ut fra dokumentet.

Hvis verdien er true og OCR-prosessen ikke produserte noen linjeposter, genereres en enkelt fakturalinje som inneholder de fullstendige totalbeløpene fra overskriften (det samme som headerOnly), sammen med tilhørende GL- og AP-regnskapslinjene, og det vises en advarsel som kan heves, slik at en person blir gjort oppmerksom på at linjen ble generert automatisk.

Hvis linjeposter ble hentet ut, har denne innstillingen ingen effekt. Hvis headerOnly også er angitt, har headerOnly forrang, og det vises ingen advarsel.

Hvis ingen verdi angis, vil den bli behandlet som false

ignoreDueDate

boolean

{ "ignoreDueDate": true }

Ignorer forfallsdatoen på fakturaen og la Unit4 beregne den ved hjelp av standardoppsettet.

Ikke aktiver dette samtidig med calculatedDueDate, da dette vil forkaste datoen vi har beregnet. Å aktivere begge deler utløser en QSET_012-advarsel.

calculatedDueDate

boolean

{ "calculatedDueDate": true }

Beregn forfallsdatoen på fakturaen ut fra leverandørens kredittvilkår i ERP-systemet, i stedet for å basere seg utelukkende på forfallsdatoen som fremgår av dokumentet.

Når denne funksjonen er aktivert, slås leverandørens betalingsbetingelses-ID opp mot ERP-objektet credit-terms, og forfallsdatoen beregnes ut fra fakturadatoen ved hjelp av betingelsens metode for beregning av forfallsdato. Resultatet skrives inn i feltet Beregnet forfallsdato (date_due_calculated).

Selve fakturadatoen beregnes enten som skattepunktdato, utstedelsesdato eller dagens dato (hvis du har angitt eksportdato som fakturadato); den beregnede verdien vil bli brukt til beregningen av forfallsdatoen.

Ikke aktiver dette samtidig med ignoreDueDate: den innstillingen sletter forfallsdatoen ved eksport slik at Unit4 kan beregne den, noe som vil forkaste datoen vi nettopp har beregnet. Å aktivere begge deler utløser en QSET_012-advarsel.

:::advarsel[Endring av Rossum-skjemaet] Hvis du aktiverer denne innstillingen, MÅ du endre det eksisterende Rossum-skjemaet – se nedenfor :::

Nødvendig konfigurasjon av køen

Denne innstillingen krever to manuelle endringer i Rossum-feltbehandleren for køen. Den har ingen effekt før disse endringene er utført.

1. Legg til et Beregnet forfallsdato-felt med ID-en date_due_calculated i seksjonen «Fakturainfo», som et datofelt med formatet D/M/ÅÅÅÅ. Hvis du ønsker å redigere JSON-filen, kan du kopiere den fra skjemadokumentet men sørg for å sette «hidden» til false.

2. Sørg for at tilkoblingsbrukeren har tilgang til «credit-terms»-objektet i ERP-systemet

3. Endre det eksisterende Forfallsdato (date_due) fra et innleset felt til et formelfelt som peker mot det beregnede feltet:

   default_to(field.date_due_calculated, None) if is_empty(field.date_due) else field.date_due

date_due er det som eksporteres til ERP-systemet, så det er ved å peke det mot det beregnede feltet at beregningen trer i kraft.

Hvis du foretrekker å redigere JSON-filen, ser den slik ut:

{
        "rir_field_names": [],
        "constraints": {
          "required": false
        },
        "score_threshold": 0,
        "default_value": null,
        "category": "datapoint",
        "id": "date_due",
        "label": "Forfallsdato",
        "description": "Fakturaens forfallsdato.",
        "hidden": false,
        "disable_prediction": true,
        "type": "date",
        "can_export": true,
        "ui_configuration": {
          "type": "formula",
          "edit": "enabled"
        },
        "formula": "default_to(field.date_due_calculated, None) if is_empty(field.date_due) else field.date_due",
        "format": "D/M/YYYY"
      },

Overstyring av den beregnede datoen

Du trenger bare å overskrive det opprinnelige date_due-feltet.

Når ingen dato kan beregnes

Feltet blir stående tomt, og det vises en advarsel ved siden av det, når:

DUE_001	Den matchede leverandøren har ingen betalingsbetingelser konfigurert i ERP-systemet.
DUE_002	Leverandørens betalingsbetingelser ble ikke funnet i ERP-systemet.
DUE_003	Kredittvilkårene bruker en beregningsmetode for forfallsdato som vi ikke støtter.

En tom beregnet forfallsdato betyr at formelen faller tilbake til en tom forfallsdato, så disse advarslene bør løses i leverandør- eller kredittvilkårsoppsettet i ERP-systemet.

exportDateAsInvoiceDate

boolean

{ "exportDateAsInvoiceDate": true }

Vil overskrive fakturadatoen på alle fakturaer med dagens dato ved eksport til ERP. Hvis ikke angitt, vil standardoppførselen brukes, som er å hente data fra feltene for skattepunktdato eller utstedelsesdato.

forceOrderProductAndDescription

boolean

{ "forceOrderProductAndDescription": true }

Når en linje samsvarer med en innkjøpsordrelinje, skal produktkoden og beskrivelsen for linjen alltid overskrives med verdiene fra innkjøpsordrelinjen, selv om OCR har hentet ut egne verdier.

Hvis ikke angitt (eller false), brukes produktkoden/beskrivelsen fra innkjøpsordrelinjen kun som reserve når OCR ikke har hentet ut en verdi for det feltet.

arrivalDateOutput

rossumArrived | export

{ "arrivalDateOutput": "rossumArrived" }

Hvis dette er angitt, vil <ArrivalDate> XML-element et (ERP7/CR) / registeredDate-feltet (ERPx) settes til enten:

• rossumArrived: «arrived_at»-datoen som er angitt på dokumentet i Rossum.

• export: den gjeldende eksporttidsstemplingen.

Hvis ikke angitt, vil disse eksportfeltene ikke bli inkludert.

firstLineAsDescription

boolean

{ "firstLineAsDescription": true }

Hvis satt til true, vil beskrivelsen på den første fakturalinjen brukes som den overordnede fakturabeskrivelsen (dette er beskrivelsen på AP-linjen). Hvis den ikke er angitt eller er satt til false, vil et tidsstempel legges inn som beskrivelse.

payRecipientCheck

boolean

{ "payRecipientCheck": true }

Hvis dette er satt til true, vil systemet markere en INFO-melding for den matchede leverandøren, dersom en betalingsmottaker (faktorbedrift) er identifisert som angitt i leverandørregistreringen. Dette vil bli oppgradert til en ADVARSEL-melding hvis betalingsmottakeren ikke har status N.

payRecipientBankCheck

boolean

{ "payRecipientBankCheck": true }

Hvis dette er satt til true, vil systemet sammenligne bankopplysningene OG valutaen fra fakturaen med opplysningene fra betalingsmottakeren (i stedet for opplysningene i leverandørstamfilen).

supplierVatCheck

boolean

{ "supplierVatCheck": true }

Hvis dette er satt til true, sammenlignes MVA-nummeret som er lest fra fakturaen, med MVA-nummeret i stamfilen til den matchede leverandøren, og det gis en advarsel (SU_020) ved feltet Leverandørens MVA-nummer hvis de ikke stemmer overens.

Dette er særlig viktig når leverandøren er hentet fra en innkjøpsordre. Leverandøren godtas da uten videre kontroll, slik at ingenting annet på dokumentet ellers kontrolleres mot leverandøren vi er i ferd med å betale.

En tom verdi på en av sidene godtas — kun et reelt avvik gir en advarsel. Tegnsetting og store/små bokstaver ignoreres.

Hvis ikke annet er angitt, er standardinnstillingen false.

supplierCompanyRegCheck

boolean

{ "supplierCompanyRegCheck": true }

Som supplierVatCheck, men for organisasjonsnummeret. Gir SU_021 ved feltet Leverandørens organisasjonsnummer.

Hvis ikke annet er angitt, er standardinnstillingen false.

supplierNameMinSimilarity

tall (0-100)

{ "supplierNameMinSimilarity": 70 }

Sammenligner leverandørnavnet som er lest fra fakturaen, med navnet i stamfilen til den matchede leverandøren, og gir en advarsel (SU_022) ved feltet Leverandørnavn når de ikke ligner nok på hverandre. Advarselsteksten inneholder poengsummen, slik at du kan se hvordan et gitt navnepar ble vurdert. 0 slår av kontrollen.

Firmanavn skrives sjelden helt likt på fakturaen og i ERP, så dette er en likhetsprosent og ikke en direkte sammenligning. Før sammenligningen gjøres aksenter om til vanlige bokstaver, & leses som «and», og selskapsformen skrives på kortform på det språket den står på — Limited blir Ltd, Aksjeselskap blir AS, Aktiebolag blir AB, Sociedad Limitada blir SL, og så videre. Dette dekker selskapsformene som brukes i hele Europa, USA og Canada, og navn skrevet med kyrilliske eller greske bokstaver blir også sammenlignet. Uten dette kan selskapsformen alene dominere et kort navn og få samme selskap til å se ut som et annet.

70 er det anbefalte utgangspunktet. Reelle varianter av et navn får 77 eller mer, mens ulike selskaper med bevisst like navn får 59 eller mindre.

Målte eksempler:

Navn på faktura	Leverandørstamfil	Poengsum
Acme Trading Ltd	Acme Trading Ltd.	100
Northern Builders Limited	Northern Builders Ltd	100
J Smith & Sons Ltd	J Smith and Sons Limited	100
Laser-Tone AS	Laser Tone Aksjeselskap	100
Nordiska Bygg AB	Nordiska Bygg Aktiebolag	100
Constructora Ibérica SL	Constructora Iberica Sociedad Limitada	100
Société Générale SA	Societe Generale Societe Anonyme	100
Acme Trading Ltd	Acme Trading Co Ltd	86
Acme Trading Ltd	Acme Trading Group Ltd	77
Acme Trading Ltd	Acme Holdings Ltd	59
Northern Builders Ltd	Northern Roofing Ltd	51
Acme Trading Ltd	Acme Logistics Limited	36
Acme Trading Ltd	Barclays Bank PLC	0

Det er verdt å være klar over to begrensninger:

• Dette sammenligner kun navn. To selskaper i samme konsern som har samme firmanavn, men ulik selskapsform (Acme Trading Ltd mot Acme Trading AS), får en score på rundt 80 og vil bli godkjent. Selskaps-ID og kontroll av bankopplysninger er de riktige kontrollmekanismene i et slikt tilfelle.
• En leverandør som fakturerer under et firmanavn som er ganske forskjellig fra det registrerte navnet (Wm Morrison Supermarkets PLC mot Morrisons), vil utløse en advarsel hver gang. Det er derfor dette er en advarsel og ikke en feil, og hvorfor funksjonen er deaktivert som standard.

En tom verdi på en av sidene godtas.

Hvis ikke annet er angitt, er standardinnstillingen 0 (deaktivert).

supplierConfidenceCheck

boolean

{ "supplierConfidenceCheck": true }

Kontrollene ovenfor sammenligner hvert sitt felt. Denne kontrollen vurderer om den matchede leverandøren som helhet ser riktig ut. Det er særlig viktig når leverandøren er hentet fra en innkjøpsordre.

En av to advarsler kan gis ved leverandørfeltet:

• SU_023: MVA-nummeret, organisasjonsnummeret, IBAN eller bankkontoen på fakturaen tilhører en annen leverandør i ERP, og ikke den valgte. Advarselen navngir den leverandøren.
• SU_024: verken MVA-nummer, organisasjonsnummer, IBAN eller bankkonto for den valgte leverandøren stemmer med fakturaen, og minst én av dem, eller leverandørnavnet, avviker. Advarselen lister opp det som avviker.

Hvis minst én av disse identifikatorene stemmer, regnes leverandøren som bekreftet og SU_024 gis ikke, selv om andre felt avviker. Disse rapporteres fortsatt av sine egne kontroller, der de er aktivert. SU_023 gis likevel hvis en annen av fakturaens identifikatorer tilhører en annen leverandør.

Noen detaljer som er verdt å kjenne til:

• Når fakturaen oppgir en sorteringskode, stemmer bankkontoen bare hvis sorteringskoden også stemmer, siden kontonumre går igjen fra bank til bank.
• Med payRecipientBankCheck aktivert er leverandørens bankopplysninger betalingsmottakerens. En betalingsmottaker, for eksempel et factoringselskap, deles vanligvis av mange leverandører, så bankopplysningene sier hvor pengene går, ikke hvem som sendte fakturaen. De kan fortsatt avvike, men de bekrefter aldri leverandøren alene, og navngir aldri en annen leverandør i SU_023.
• Navnet sammenlignes som for supplierNameMinSimilarity, med verdien fra den innstillingen, eller 70 når den er 0 eller ikke er angitt.
• Standardleverandøren kontrolleres aldri, og navngis aldri som den andre leverandøren.
• Kontrollene ovenfor trenger ikke være aktivert.

Begge er advarsler, så legg SU_023 og/eller SU_024 til i elevateWarnings for å stoppe behandlingen.

Hvis ikke annet er angitt, er standardinnstillingen false.

elevateWarnings

string[]

{ "elevateWarnings": ["ACL_003","SU_007"] }

En matrise med koder som vanligvis genererer advarsler, men som organisasjonen ønsker å oppgradere til feil.

Hvis du legger til elementer her, vil skjemafeltet override_warnings gi en feilmelding dersom det finnes advarsler som står på listen over oppgraderte advarsler. For mer informasjon, se dokumentasjonen om advarsler

Se listen over advarsler som kan oppgraderes

compressGL

boolean

{ "compressGL": true }

Hvis ingen verdi angis, settes denne til false.

KUN ERPx Hvis satt til true, settes dette flagget på API-endepunktet. Unit4 beskriver dette slik: hvis satt til true, aggregeres hovedbok- og skatteradene i henhold til hovedbokanalysen. Beskrivelsen som er angitt for hovedbokraden, overføres ikke til hovedboken. (Oppførselen kan replikeres i ERP7 med parameteren «compress» på EI02).

showSupplierMessage

none | warning | info

{ "showSupplierMessage": "none" }

Hvis feltet «message» på fakturafanen i leverandørstamfilen har en verdi, kan den vises som en informasjons- eller advarselsmelding ved det valgte leverandørfeltet i Rossum.

• none vil aldri vise en melding.
• info vil vise meldingsteksten som en informasjonsmelding
• warning viser meldingsteksten som en advarsel

Hvis ikke annet er angitt, er standardinnstillingen none.

Caching

cacheTime

tall

{ "cacheTime": 3600 }

Hvis ingen verdi er angitt, vil standardverdien på 3600 sekunder (én time) .

Tiden (i sekunder) som data (for eksempel leverandører, innkjøpsordrer, regnskapsinformasjon) fra Unit4 vil bli lagret i cachen. Jo lenger denne tiden er, desto færre API-forespørsler må sendes, og desto raskere vil tjenesten kjøre. Ulempen med en lengre cachetid er at det vil ta lengre tid før dataene «dukke opp» i OCR-systemet.

cacheSuffix

streng

{ "cacheSuffix": "custom-suffix" }

En tilfeldig streng som kan legges til slutten av cache-nøklene i systemet. Hvis ingen verdi angis, brukes default. Du kan eventuelt definere en verdi her for å tvinge frem en oppdatering av cachen i systemet før cacheTime-verdien utløper. Hver gang denne verdien endres, vil gamle verdier i cachen ikke lenger brukes, og dataene hentes på nytt. Det bør ikke være nødvendig å gjøre dette regelmessig; hvis du gjør det, kan det tyde på at cacheTime er for lang.

testExtensionSettings

Se dokumentasjonen for testutvidelsen

Eksempel på konfigurasjon

Siden JSON-syntaksen og typedefinisjonene som er brukt ovenfor kanskje ikke er kjent for alle, følger her et eksempel på en konfigurasjon.

warning

Dette MÅ redigeres / reduseres til kun de nøklene og alternativene du trenger.

Sørg også for at et ERP7-system har «ei02Variant» angitt

{
    "clientId": "ABC",
    "legalEntityIndex": 7,
    "erpVersion": "erp7",
    "erpConnectionSettings" :{
        "unit4ApiUrl": "https://example.unit4cloud.com",
        "unit4SoapUrl": "https://example.unit4cloud.com" ,
        "erpxHost": "https://example.unit4cloud.com",
        "erpIdsHost": "https://example.unit4cloud.com"
    },
    "transactionType": "T1",
    "ei02Variant": 0,
    "invoiceDocumentTypes": ["IINV", "XYZ"],
     "headerOnly": { "base": false, "perSupplier": "supocrctrl/header_only_fx" },
    "autoGenerateGlLine": true,
    "forceOrderProductAndDescription": false,
    "manualTaxCodeIds": ["0", "1", "11"],
    "showSupplierMessage": "none",
    "allowedTaxRates": [0.2, 0.05],
     "allowAnyTaxCoding": false,
    "noPurchaseOrder": {
        "base": "allow",
        "perSupplier": "xocrconfig/nopurchaseorder"
    },
    "validPOStatus":["O"],
    "singleLineMatch": "auto",
    "lineRoundingTolerance": "nearest",
    "roundingMode": "line",
    "apDefaultDims": {
        "dim1": 3000,
        "dim2": "ABC",
        "dim4": "Egendefinert verdi"
    },
    "glDefaultDims": {
        "dim1": 3001,
        "dim2": "ABC",
        "dim6": "Egendefinert verdi",
        "account": "3000"
    },
    "defaultQuantity": 1,
    "defaultSupplierId": "1000",
    "validSupplierStatus": ["N","P"],
    "matchFirstFoundSupplier": false,
    "defaultAccountable": "101",
    "payRecipientCheck" : true,
    "payRecipientBankCheck" : true,
    "supplierVatCheck": true,
    "supplierCompanyRegCheck": true,
    "supplierNameMinSimilarity": 70,
    "supplierConfidenceCheck": true,
    "ignoreTax": false,
    "taxCodeAttrId": "A1",
    "taxSystemAttrId": "GK",
    "ignoreZeroRows": true,
    "ignoreDueDate": true,
    "calculatedDueDate": false,
    "exportDateAsInvoiceDate": false,
    "arrivalDateOutput": "rossumArrived",
    "firstLineAsDescription": true,
    "cacheTime": 3600,
    "cacheSuffix": "",
    "elevateWarnings": ["ACL_003","SU_007"],
    "attachMessagesDocument": "all",
    "compressGL": false,
    "locale": "en",
    "erpHeaders": {
        "X-ACME-RequestOrigin": "ERP Apps OCR",
        "X-ACME-UUID": "0c12f153-36f7-4b76-962c-e97c82a491e8"
    }
}