Gå til hovedinnhold

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.

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_001Den matchede leverandøren har ingen betalingsbetingelser konfigurert i ERP-systemet.
DUE_002Leverandørens betalingsbetingelser ble ikke funnet i ERP-systemet.
DUE_003Kredittvilkå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).

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.

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

{
    "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",
    "defaultAccountable": "101",
    "payRecipientCheck" : true,
    "payRecipientBankCheck" : 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"],
    "compressGL": false,
    "locale": "en",
    "erpHeaders": {
        "X-ACME-RequestOrigin": "ERP Apps OCR",
        "X-ACME-UUID": "0c12f153-36f7-4b76-962c-e97c82a491e8"
    }
}