Konfiguration av fakturatillägg

När du konfigurerar ditt Rossum-tillägg finns det några alternativ du kan justera för att anpassa fakturaflödet så att det passar din organisation bättre. Dessa konfigurationsalternativ ställs in i tilläggets inställningar via ditt Rossum-gränssnitt.

Dessa ska skrivas i JSON-format.

info

De flesta parametrarna här är valfria, med undantag för invoiceDocumentTypes och erpVersion. Om inga andra parametrar anges kommer vi att använda våra standardvärden.

Det enda andra undantaget är ei02Variant, som är obligatoriskt OM du använder ERP7-/ERPCR-versionen av kopplingen.

Parameterdefinitioner och användning

Systeminställningar

clientId

string

{ "clientId": "ABC" }

Om detta anges kommer ALLA ERP-frågor att begränsas till detta klient-ID.

Om det inte anges kommer vi att försöka läsa in detta per dokument från uppgifterna i Rossum-gränssnittet. Om det inte anges där kommer vi att försöka fastställa klient-ID:t utifrån de tillgängliga inköpsorderuppgifterna.

De flesta efterföljande sökningar kommer att misslyckas om vi inte kan fastställa ett klient-ID, och därför rekommenderar vi att detta anges i konfigurationen när det är möjligt, eftersom det har stor betydelse för systemets tillförlitlighet.

legalEntityIndex

number

{"legalEntityIndex": 7 }

Bör ställas in på numret för den juridiska enhetens dimension för kunden.

Om detta är inställt kommer systemet att försöka [identifiera juridiska enhetskoder och tillämpa dessa på bokföringsinformationen](../../user-guide/guides/legal-entities.md

) för fakturor som inte avser inköpsorder.

erpVersion

'erpx' | 'erp7' | 'erpcr'

{ "erpVersion": "erp7" }

ERP-versionen. Detta är viktigt för att vi ska veta vilka slutpunkter vi ska använda för att hämta och skicka data.

• ERPx Unit4:s ERPx-system
• ERPCR Unit4:s ERP CR-system. Du använder troligen detta system om du använder Unit4 Cloud.
• ERP7 Detta är troligtvis den version du använder om dina servrar inte hostas av Unit4.

transactionType

string

{ "transactionType": "T1" }

Detta är koden för ERP-transaktionstypen som vi vidarebefordrar till ditt ERP-system när fakturan skickas in, antingen direkt i JSON-formatet för ERPx eller som parametern för inkommande fakturatransaktionstyp i EI02 för ERP7/CR

ei02Variant

number

{ "ei02Variant": 0 }

Detta är obligatoriskt för milstolpe sju. Det är EI02-rapportvarianten som kommer att köras när fakturan bokförs.

invoiceDocumentTypes:

string[]

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

Detta är listan över dokumenttyper som vi accepterar som fakturor. Om det bara finns en typ kommer vi att kräva den, annars använder vi den första som standard men låter användaren ändra den i användargränssnittet.

För helt automatiserade processer innebär detta att docType ALLTID kommer att vara den första i listan. Om du behöver manuell kontroll, se till att automatisk bearbetning är inaktiverad.

språkinställning

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

{ "locale": "en" }

Endast exakt dessa strängar accepteras som giltiga språkinställningar. Om inget anges använder vi en

Vissa meddelanden kanske inte översätts, eftersom vi måste avkoda och validera händelsen innan vi kan använda språkinställningen. Om vi misslyckas innan dess kommer felmeddelanden därför att vara på engelska.

erpHeaders

Record<string, string="">

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

Om dessa är inställda vidarebefordrar vi dessa rubriker till ERP-systemet.

Detta kan till exempel vara användbart om du har ett egenhostat ERP-system där du vill kontrollera åtkomsten.

Du kan använda detta för att ställa in en fördefinierad rubrik som kan användas på en lastbalanserare eller omvänd proxy för att kontrollera åtkomsten till ERP-systemet.

Om en begäran skickas till ERP-systemet utan denna rubrik kan den avvisas av lastbalanseraren eller omvända proxyn utan att nå själva servern.

Du kanske också vill använda detta för analys- eller loggningsändamål.

attachMessagesDocument

none | warning | all

{ "attachMessagesDocument": "all" }

Vilka meddelanden som ska bifogas transaktionen i ERP som ett sekundärt dokument. (Dessa bifogas som zzzz_messages....) Dessa är kopior av de meddelanden vi skickar till Rossum-gränssnittet, så att ERP-användare har långsiktig tillgång till samma meddelanden.

• none bifogar aldrig några meddelanden.
• warning bifogar meddelanden på varningsnivå eller högre.
• all bifogar alla meddelanden, inklusive informationsmeddelanden

Om inget anges är standardinställningen all.

Konfiguration av ERP-anslutning

warning

Observera att dessa anslutningsinställningar nu kan anges i tilläggets hemliga inställningar (där de tidigare fanns) ELLER här i inställningarna (för bättre översikt).

Om något av dessa värden är angivna på båda ställena har det som anges här i inställningarna företräde.

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 och unit4SoapUrl krävs för ERP7-/ERPCR-system.

erpxHost krävs på ett ERPx-system

erpIdsHost krävs på alla system som använder IDS för autentisering.

Dokumenthantering

manualTaxCodeIds

string[]

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

Om detta anges kommer vi att begränsa skattekoderna för rader som inte hör till inköpsorder (leverantörsreskontra / extra inköpsorderrader / fakturarader som inte hör till inköpsorder) till endast de som anges här.

Fakturarader som matchar en inköpsorderrad kommer fortfarande att använda skattekoderna från inköpsordern enligt vad som angivits.

allowedTaxRates

number[]

{ "allowedTaxRates": [0.2, 0.05] }

Om detta anges kommer vi att begränsa skattesatserna till endast de som anges här. Om vi avrundar till ett värde nära en av dessa kommer vi att ”snäppa” till den. Om vi avrundar till en skattesats som inte finns i listan kommer vi att ignorera den och anta att det är ett OCR- eller fakturafel.

allowAnyTaxCoding

boolean

{ "allowAnyTaxCoding": false }

Om detta är inställt på true tillåter systemet alltid att valfri skattekod (som överensstämmer med fakturavalutan) och valfritt skattesystem väljs manuellt vid kontokodning, oavsett skatteprocent, kontoregler, om dokumentet är en inköpsorderfaktura eller inställningarna i manualTaxCodeIds.

Observera att val av en skattekod som inte stämmer överens med skattesatsen eller valutan på fakturaraden kommer att generera en ACL_004-varning eller ett fel, eftersom det sannolikt leder till att importtjänsten markerar dokumentet som obalanserat om detta tillåts gå vidare till ERP. Denna inställning har dock specifikt efterfrågats av kunder för att de ska kunna registrera skattekoden före importen och uppdatera inköpsordern med denna skattekod (med hjälp av verktyg i Unit4)

Om denna inställning inte är aktiverad, eller är inställd på ”false”, kommer de tillgängliga skattekoderna att begränsas av manualTaxCodeIds samt skattesatsen och valutan på fakturan.

noPurchaseOrder

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

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

Detta används för att avgöra om vi kan utfärda fakturor utan inköpsorder. Om base är 'reject' kommer vi att avvisa alla fakturor utan inköpsorder. Om base är 'allow' kommer vi att tillåta fakturor utan inköpsorder.

Om perSupplier anges kommer vi att söka efter ett customField (flexifield) hos leverantören och, om det hittas, behandla värdet som basvärdet för den leverantören. Detta värde bör vara antingen allow eller reject (eller saknas helt), så flexifieldet bör konfigureras med dessa alternativ. Ett exempel på ett värde för fältet perSupplier skulle kunna vara något i stil med supppoctrl/no_po_no_pay_fx Om det inte hittas använder vi basvärdet.

singleLineMatch

'force' | 'auto'

{ "singleLineMatch": "force" }

Om denna inställning inte anges i konfigurationen kommer auto att tillämpas

Detta används för att tvinga fram matchning av inköpsorder med en enda rad på könivå. Om inställningen är "force" kommer systemet, för order där det endast finns en rad i ordern (oavsett status), automatiskt att matcha ALLA fakturarader mot den enda orderraden.

Om inställningen är "auto" kommer raden endast att matchas om den automatiska matchningsprocessen hittar en rad att matcha mot utifrån tillgängliga data.

lineRoundingTolerance

'nearest' | 'floor'

{ "lineRoundingTolerance": "floor" }

Om denna inställning inte anges i konfigurationen kommer nearest att tillämpas

Detta styr hur stor avrundningstolerans som tillåts vid kontroll av en rads värden (t.ex. enhetspris * antal) mot det värde som står på fakturan.

De flesta leverantörer avrundar radsummorna till närmaste penny, vilket innebär att det tryckta värdet legitimt kan avvika från värdet med full precision med upp till en halv penny per artikel i båda riktningarna. Detta är standardinställningen ("nearest").

Vissa leverantörer avrundar istället alltid radsumman nedåt (avkortar) istället för att avrunda till närmaste. Eftersom avrundning nedåt aldrig innebär avrundning uppåt kan deras utskrivna värde understiga värdet med full precision med upp till en hel penny per artikel – dubbelt så mycket som standardtoleransen. Ställ in detta på "floor" för köer där leverantören är känd för att avrunda sina radvärden nedåt, så att underskridande tolereras upp till en hel penny per artikel. En överskridning (utskrivet värde större än värdet med full precision) tolereras fortfarande endast med en halv penny per artikel, eftersom avrundning nedåt aldrig förklarar en överskridning.

roundingMode

'item' | 'line' | 'total'

{ "roundingMode": "line" }

Om denna inställning inte anges i konfigurationen kommer line att tillämpas

Detta styr var, under radnormaliseringen, en rads netto-/brutto- och skattevärden avrundas till två decimaler. Interna beräkningar hålls annars med full flyttalsprecision genomgående - detta är det enda avsiktliga avrundningssteget. Det är oberoende av lineRoundingTolerance ovan, som styr jämförelsetoleransen snarare än beräkningen, och de två inställningarna kan användas tillsammans.

• "item": avrunda enhetsvärdena först, utvidga sedan med kvantiteten. Detta återskapar avrundning per enhet före utvidgning. Endast valfritt- endast för leverantörer som man vet avrundar per enhet innan utvidgning – det kan medföra ett fel på upp till en halv penny per artikel jämfört med radvärdet med full precision.
• "line" (standard): avrunda en gång på den upplösta rad-totalnivå. Stämmer överens med befintligt beteende när inga enhetsvärden anges, och undviker det avrundningsfel som "item" kan orsaka när enhetsvärden anges.
• "total": avrunda inte raden alls under normaliseringen – låt den ha full precision, så att summeringen av många rader för kontrollen av rubrikens totalbelopp inte ger något sammanlagt avrundningsfel. Skillnaden mot "line" märks endast på fakturor med flera rader.

validPOStatus

string[]

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

Om denna inställning inte anges i konfigurationen kommer vårt standardfilter status NOT IN (N, P, T) att tillämpas

Detta används för att ange vilka rubrik-statusar för inköpsorder som anses giltiga för matchning. Om detta är inställt och en inköpsorder returneras men inte har någon av de identifierade statusarna, kommer den inte att användas för matchning och kommer inte att skickas vidare till ERP-systemet tillsammans med fakturauppgifterna. Användaren kommer att få ett varningsmeddelande om en inköpsorder hittades av OCR men inte matchades.

validSupplierStatus

string[]

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

Om denna inställning inte anges i konfigurationen kommer vårt standardfilter status = N att tillämpas

Vissa kunder har efterfrågat att icke-aktiva leverantörer ska matchas i OCR-processen, men att ett felmeddelande ska visas om så är fallet. De vill till exempel veta att leverantören finns och var den bästa matchningen, men att den är nedlagd.

För att undvika att ändra vårt ursprungliga beteende gör denna nya status det möjligt för dig att ange en giltig status för leverantörer, som kommer att användas vid hämtning av leverantörer från ERP-API:et.

Du kan få felmeddelandet SU_017 om leverantören inte har status N eller P och varningen SU_018 om leverantören har status P. SU_018 kan också uppgraderas till ett fel.

matchFirstFoundSupplier

boolean

{ "matchFirstFoundSupplier": false }

Om denna inställning inte anges i konfigurationen är standardvärdet true, vilket var det ursprungliga beteendet och avsåg att möjliggöra högre automatiseringsgrad.

När vi söker efter en leverantör söker vi i ERP-systemet utifrån flera kriterier: leverantörens namn, momsregistreringsnummer, organisationsnummer och bankuppgifter. Ibland har flera leverantörsposter samma värde för ett av dessa kriterier, vilket innebär att ett enda sökkriterium ger två eller flera träffar.

Med inställningen true väljer vi den första leverantören som hittas.

Ställ in den på false så väljer vi inte mellan dem. Matchningen sker genom att leverantörsstatusarna går igenom i tur och ordning: först aktiva (N), sedan parkerade (P) och därefter alla övriga som sökningen gav; och tvetydighet bedöms endast inom den kontroll som granskas. Ett matchningskriterium som delas av en N-leverantör och en P-leverantör är därför inte tvetydigt: vid den punkten är den aktiva leverantören det enda alternativet, och den matchas. Om två eller fler leverantörer i samma kontroll delar samma värde, hoppas det kriteriet över till förmån för nästa, vilket fortfarande kan identifiera en enda leverantör. Om inget kriterium identifierar en unik leverantör lämnas dokumentet omatchet med felet SU_016, och alla kandidater som sökningen gav tillbaka erbjuds i leverantörsmenyn för användaren att välja mellan.

Detta påverkar inte en leverantör som hämtas från en inköpsorder eller en som användaren har valt manuellt, eftersom båda identifierar en leverantör via dess ID.

Observera att defaultSupplierId, där det är konfigurerat, fortfarande gäller. Ett dokument som vi avstår från att gissa på dirigeras till den leverantören istället för att lämnas omatchat, eftersom de två inställningarna besvarar olika frågor: den här frågar om man ska välja mellan kandidater, medan defaultSupplierId frågar vad man ska göra när ingen kandidat alls har identifierats.

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": "Anpassat värde"
   }
}

Vi använder dessa standardvärden för att möjliggöra automatiserad inlämning.

På AP-raden hämtar vi kontot från leverantörsgruppen och fyller sedan i alla giltiga dimensioner med dimensionerna härifrån.

Om dessa inte anges måste de fyllas i manuellt i användargränssnittet.

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": "Anpassat värde",
        "account": "3000"
    }
}

För fakturor utan inköpsorder använder vi dessa standardvärden för att möjliggöra automatisk inlämning.

Om dessa inte anges måste de fyllas i manuellt i användargränssnittet.

defaultQuantity

tal

{ "defaultQuantity": 1 }

Om vi inte kan avläsa en kvantitet för en radpost använder vi detta värde som fallback.

defaultSupplierId

sträng

{ "defaultSupplierId": "1000" }

Om vi inte kan fastställa en leverantör använder vi detta värde som standard.

Innan vi använder detta kommer vi att kontrollera inköpsordern för att se om det finns en leverantör, och sedan söka efter leverantören i fälten företagsnummer, momsregistreringsnummer och bankuppgifter. Om vi kan matcha någon av dessa uppgifter kommer vi att göra det. Om inte kommer vi att använda detta värde när det är angivet.

defaultAccountable

string

{ "defaultAccountable": "101" }

Vi försöker matcha den aktiva Rossum-användaren med en ERP-användare. Om det lyckas kommer vi att ange den ERP-användaren som ansvarig person för denna faktura.

Om vi inte lyckas matcha användaren faller vi tillbaka på detta värde när det är angivet.

Detta värde kommer så småningom att visas i fältet ext_ref i fakturatransaktionen

ignoreTax

boolean

{ "ignoreTax": false }

Denna inställning medför inga större förändringar i användargränssnittet, men när fakturan skickas till ERP-systemet skickar vi endast bruttovärden och sätter alla skatter till noll.

Detta är en inställning som sällan används för särskilda typer av organisationer som aldrig hanterar moms eller andra skattesatser och endast hanterar bruttovärden internt. Vi behåller skatten i användargränssnittet även när den är inställd för att säkerställa att fakturans radposter stämmer överens med rubriken, men vi skickar inte skatten till ERP-systemet.

taxCodeAttrId

string

{ "taxCodeAttrId": "A1" }

Detta används för att söka upp attributrelationer och i värdematriser, om du har en konfiguration där skattekoden är kopplad till redovisningsdimensioner.

Om inget värde anges använder vi värdet A1, så vi rekommenderar starkt att du överskriver detta om du använder ett annat attribut-ID för skattekoder.

taxSystemAttrId

string

{ "taxSystemAttrId": "GK" }

När vi begär skattesystemkonfiguration från ERP7/ERPCr använder vi detta attribut-ID som identifierare. Om inget anges kommer standardvärdet GK att användas, så vi rekommenderar starkt att du överskriver detta om du använder ett annat attribut-ID för skattesystem.

Detta används också för att söka efter attributrelationer och i värdematriser.

ignoreZeroRows

boolean

{ "ignoreZeroRows": true }

Om värdet är true visas ett informationsmeddelande för en rad med nollvärden, men raden filtreras sedan bort innan den skickas till ERP.

Om värdet är false visas ett felmeddelande för en rad med nollvärden och inlämningen blockeras tills den korrigeras manuellt i användargränssnittet.

headerOnly

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

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

Detta kan aktiveras eller inaktiveras på könivå genom att ställa in base till true eller false, men du kan sedan åsidosätta detta för varje leverantör. Vi letar efter ett customField (flexifield) för leverantören och om vi hittar det behandlar vi värdet som standardvärdet för den leverantören.

Detta värde bör vara ett kryssrutsfält i flexifieldet, eftersom det då kan vara antingen true eller false.

Ett exempel på ett värde för fältet perSupplier skulle kunna vara något i stil med supocrctrl/header_only_fx (detta kan vara ett annat fält i samma flexifield som används för inställningen ”no po no pay”)

Om värdet är ”sant” (antingen per kö eller per leverantör) ignoreras de extraherade radposterna helt. En enda fakturarad med de fullständiga huvudpostssummorna (netto / moms / brutto) genereras, tillsammans med dess huvudbokföringsrad och leverantörsreskontraraden. Alla vanliga balanskontroller körs fortfarande, men mot denna genererade rad så att de balanserar.

Detta är avsett för kunder som endast vill bokföra huvudpostsvärden och låta ERP-systemet (eller en efterföljande process) hantera detaljerna.

glDefaultDims.account måste vara ett giltigt ERP-konto, annars blockeras den genererade raden av valideringen ”välj kontokod”.

Om inget värde anges behandlas det som false

autoGenerateGlLine

boolean

{ "autoGenerateGlLine": true }

En reservlösning för när inga radposter extraherades från dokumentet.

Om värdet är true och OCR inte genererade några radposter, skapas en enda fakturarad som innehåller de fullständiga huvudpostssummorna (samma som headerOnly), tillsammans med dess GL- och AP-bokföringsraderna, och en varningsmeddelande som kan höjas visas så att en användare blir medveten om att raden genererades automatiskt.

Om radposter extraherades har denna inställning ingen effekt. Om headerOnly också är inställt har headerOnly företräde och ingen varning visas.

Om inget värde anges behandlas det som false

ignoreDueDate

boolean

{ "ignoreDueDate": true }

Ignorera förfallodatumet på fakturan och låt Unit4 beräkna det med hjälp av standardinställningarna.

Aktivera inte detta samtidigt som calculatedDueDate, eftersom detta skulle åsidosätta det datum vi beräknat. Om båda aktiveras genereras en QSET_012-varning.

calculatedDueDate

boolean

{ "calculatedDueDate": true }

Beräkna fakturans förfallodatum utifrån leverantörens kreditvillkor i ERP-systemet, istället för att enbart förlita sig på det förfallodatum som läses av från dokumentet.

När detta är aktiverat söks leverantörens betalningsvillkors-ID upp mot ERP-objektet credit-terms och förfallodatumet beräknas utifrån fakturadatumet med hjälp av villkorets metod för förfallodatum. Resultatet skrivs till fältet Beräknat förfallodatum (date_due_calculated).

Själva fakturadatumet beräknas antingen som skattepunktens datum, utfärdandedatum eller dagens datum (om du har ställt in exportdatumet som fakturadatum), och det beräknade värdet används för beräkningen av förfallodatumet.

Aktivera inte detta samtidigt som ignoreDueDate: den inställningen raderar förfallodatumet vid export så att Unit4 kan beräkna det, vilket skulle göra att det datum vi just beräknat kastas bort. Om båda aktiveras visas en QSET_012-varning.

:::warning[Ändra ditt Rossum-schema] Om du aktiverar denna inställning MÅSTE du ändra ditt befintliga Rossum-schema, se nedan :::

Nödvändig kökonfiguration

Denna inställning kräver två manuella ändringar i Rossum-fältmanagern för kön. Den har ingen effekt förrän dessa ändringar har gjorts.

1. Lägg till ett fält Beräknat förfallodatum med ID:t date_due_calculated i avsnittet Fakturainformation, som ett datumfält med formatet D/M/ÅÅÅÅ. Om du vill redigera JSON-filen kan du kopiera den från schemadokumentet men se till att du ställer in ”hidden” till false.

2. Se till att din anslutningsanvändare har åtkomst till objektet ”credit-terms” i ERP-systemet

3. Ändra det befintliga fältet Förfallodatum (date_due) från ett inmatat fält till ett formelfält som pekar på det beräknade fältet:

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

date_due är det som exporteras till ERP-systemet, så det är genom att peka det mot det beräknade fältet som beräkningen träder i kraft.

Om du föredrar att redigera JSON-filen ser det ut så här

{
        "rir_field_names": [],
        "constraints": {
          "required": false
        },
        "score_threshold": 0,
        "default_value": null,
        "category": "datapoint",
        "id": "date_due",
        "label": "Förfallodatum",
        "description": "Fakturans förfallodatum.",
        "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"
      },

Åsidosätta det beräknade datumet

Skriv helt enkelt över det ursprungliga date_due-fältet.

När inget datum kan beräknas

Fältet lämnas tomt och en varning visas vid det när:

DUE_001	Den matchade leverantören har inga betalningsvillkor konfigurerade i ERP-systemet.
DUE_002	Leverantörens betalningsvillkor hittades inte i ERP-systemet.
DUE_003	Kreditvillkoren använder en beräkningsmetod för förfallodatum som vi inte stöder.

Ett tomt beräknat förfallodatum innebär att formeln faller tillbaka till ett tomt förfallodatum, så dessa varningar bör åtgärdas i leverantörs- eller kreditvillkorsinställningarna i ERP-systemet.

exportDateAsInvoiceDate

boolean

{ "exportDateAsInvoiceDate": true }

Skriver över fakturadatumet på alla fakturor med det aktuella datumet vid export till ERP-systemet. Om detta inte anges används standardbeteendet att extrahera från fälten för skattepunktens datum eller utfärdandedatum.

forceOrderProductAndDescription

boolean

{ "forceOrderProductAndDescription": true }

När en rad matchas mot en inköpsorderrad ska radens produktkod och beskrivning alltid skrivas över med värdena från inköpsorderraden, även om OCR har extraherat egna värden.

Om detta inte är inställt (eller false) används inköpsorderradens produktkod/beskrivning endast som reserv när OCR inte har extraherat något värde för det fältet.

arrivalDateOutput

rossumArrived | export

{ "arrivalDateOutput": "rossumArrived" }

Om detta är inställt kommer <ArrivalDate> XML-element et (ERP7/CR) / fältet registeredDate (ERPx) att sättas till antingen:

• rossumArrived: datumet för ankomst (arrived_at) som angetts för dokumentet i Rossum.

• export: den aktuella tidsstämpeln för exporten.

Om detta inte anges kommer dessa exportfält inte att inkluderas.

firstLineAsDescription

boolean

{ "firstLineAsDescription": true }

Om inställt på true kommer beskrivningen för den första fakturaraden att användas som den övergripande fakturabeskrivningen (detta är beskrivningen på AP-raden). Om det inte finns eller är false kommer en tidsstämpel att anges som beskrivning.

payRecipientCheck

boolean

{ "payRecipientCheck": true }

Om detta är inställt på true kommer systemet att markera ett INFO-meddelande för den matchade leverantören, om en betalningsmottagare (fakturaköpsföretag) identifieras som angiven i leverantörsregistret. Detta uppgraderas till ett VARNING-meddelande om betalningsmottagaren inte har status N.

payRecipientBankCheck

boolean

{ "payRecipientBankCheck": true }

Om detta är inställt på true kommer systemet att matcha bankuppgifterna OCH valutan från fakturan mot dem från betalningsmottagaren (istället för dem i leverantörsregistret).

supplierVatCheck

boolean

{ "supplierVatCheck": true }

Om detta är inställt på true jämförs momsregistreringsnumret som lästs från fakturan med momsregistreringsnumret i den matchade leverantörens register, och en varning (SU_020) visas vid fältet Leverantörens momsregistreringsnummer om de inte stämmer överens.

Detta har störst betydelse när leverantören hämtats från en inköpsorder. Leverantören godtas då utan vidare kontroll, så inget annat på dokumentet kontrolleras i övrigt mot den leverantör vi är på väg att betala.

Ett tomt värde på någon av sidorna godtas — endast en verklig avvikelse ger en varning. Skiljetecken och versaler/gemener ignoreras.

Om inget annat anges är standardbeteendet false.

supplierCompanyRegCheck

boolean

{ "supplierCompanyRegCheck": true }

Som supplierVatCheck, men för organisationsnumret. Ger SU_021 vid fältet Leverantörens organisationsnummer.

Om inget annat anges är standardbeteendet false.

supplierNameMinSimilarity

tal (0-100)

{ "supplierNameMinSimilarity": 70 }

Jämför leverantörsnamnet som läses in från fakturan med namnet i den matchade leverantörens stamdata och genererar en varning (SU_022) för fältet ”Leverantörsnamn” när namnen inte stämmer överens tillräckligt väl. Varningstexten innehåller poängvärdet, så att du kan se hur ett visst namnpar har bedömts. 0 inaktiverar kontrollen.

Företagsnamn skrivs ofta inte identiskt på fakturan och i ERP-systemet, så detta är en procentuell likhet snarare än en direkt jämförelse. Innan jämförelsen görs ändrar systemet accenter till vanliga bokstäver, tolkar & som ”och” och, om det finns en sådan, skriver det den juridiska företagsformen i kortform på det språk den förekommer. Så till exempel blir Limited till Ltd, Aksjeselskap blir AS, Aktiebolag blir AB, Sociedad Limitada blir SL och så vidare. Detta omfattar de företagsformer som används i hela Europa, USA och Kanada, och namn skrivna med kyrilliska eller grekiska bokstäver jämförs också.

70 är den rekommenderade utgångspunkten, men du kan behöva justera detta utifrån dina data.

Uppmätta exempel:

Namn på fakturan	Leverantörsregistret	Poäng
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 finns två begränsningar som är värda att känna till:

• Här jämförs endast namn. Två företag inom samma koncern som har samma handelsnamn men olika juridisk form (Acme Trading Ltd jämfört med Acme Trading AS) får ett resultat på cirka 80 och godkänns. Kontrollerna av företags-ID och bankuppgifter är de rätta kontrollerna i det fallet.
• En leverantör som fakturerar under ett firmanamn som skiljer sig avsevärt från det registrerade namnet (Wm Morrison Supermarkets PLC jämfört med Morrisons) kommer att utlösa en varning varje gång. Det är därför detta är en varning snarare än ett fel, och varför funktionen är avstängd som standard.

Ett tomt värde på någon av sidorna accepteras.

Om inget anges är standardinställningen 0 (avstängd).

supplierConfidenceCheck

boolean

{ "supplierConfidenceCheck": true }

Kontrollerna ovan jämför var sitt fält. Den här kontrollen bedömer om den matchade leverantören som helhet ser rätt ut. Det har störst betydelse när leverantören hämtats från en inköpsorder.

En av två varningar kan visas vid leverantörsfältet:

• SU_023: fakturans momsregistreringsnummer, organisationsnummer, IBAN eller bankkonto tillhör en annan leverantör i ERP, och inte den valda. Varningen namnger den leverantören.
• SU_024: varken den valda leverantörens momsregistreringsnummer, organisationsnummer, IBAN eller bankkonto stämmer med fakturan, och minst ett av dem, eller leverantörsnamnet, avviker. Varningen listar det som avviker.

Om minst en av dessa identifierare stämmer anses leverantören bekräftad och SU_024 visas inte, även om andra fält avviker. Dessa rapporteras fortfarande av sina egna kontroller, där de är aktiverade. SU_023 visas ändå om en annan av fakturans identifierare tillhör en annan leverantör.

Några detaljer som är värda att känna till:

• När fakturan anger en sorteringskod stämmer bankkontot bara om sorteringskoden också stämmer, eftersom kontonummer återkommer från bank till bank.
• Med payRecipientBankCheck aktiverad är leverantörens bankuppgifter betalningsmottagarens. En betalningsmottagare, till exempel ett factoringbolag, delas oftast av många leverantörer, så bankuppgifterna säger vart pengarna går, inte vem som skickade fakturan. De kan fortfarande avvika, men de bekräftar aldrig leverantören på egen hand och namnger aldrig en annan leverantör i SU_023.
• Namnet jämförs som för supplierNameMinSimilarity, med den inställningens värde, eller 70 när det är 0 eller inte anges.
• Standardleverantören kontrolleras aldrig och namnges aldrig som den andra leverantören.
• Kontrollerna ovan behöver inte vara aktiverade.

Båda är varningar, så lägg till SU_023 och/eller SU_024 i elevateWarnings för att stoppa behandlingen.

Om inget annat anges är standardbeteendet false.

elevateWarnings

string[]

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

En array med koder som vanligtvis genererar varningar, men som organisationen vill uppgradera till fel.

Om du lägger till poster här kommer schemafältet override_warnings att generera ett fel om det finns varningsmeddelanden som finns med i listan över uppgraderade varningar. För mer information, se dokumentationen om varningar

Se listan över varningar som kan uppgraderas

compressGL

boolean

{ "compressGL": true }

Om inget värde anges kommer detta att ställas in på false.

ENDAST ERPx Om detta är inställt på true sätts flaggan på API-ändpunkten. Unit4 beskriver detta så här: om det är inställt på true aggregeras huvudbok- och skatteraderna enligt huvudboksanalysen. Den beskrivning som angetts för GL-raden överförs inte till huvudboken. (Beteendet kan replikeras i ERP7 med komprimeringsparametern på EI02).

showSupplierMessage

none | warning | info

{ "showSupplierMessage": "none" }

Om fältet ”message” på fakturafliken i leverantörsstamfilen har ett värde kan det visas som ett informations- eller varningsmeddelande vid det valda leverantörsfältet i Rossum.

• none visar aldrig något meddelande.
• info visar meddelandetexten som ett informationsmeddelande
• warning visar meddelandetexten som ett varningsmeddelande

Om inget anges är standardbeteendet none.

Cachelagring

cacheTime

tal

{ "cacheTime": 3600 }

Om inget värde anges tillämpas standardvärdet 3600 sekunder (en timme).

Den tid (i sekunder) som data (t.ex. leverantörer, inköpsorder, bokföringsinformation) från Unit4 kommer att lagras i cachen. Ju längre denna tid är, desto färre API-förfrågningar behöver göras och desto snabbare kommer tjänsten att köras. Nackdelen med en längre cachtid är att det tar längre tid innan data ”dyker upp” i OCR-systemet.

cacheSuffix

sträng

{ "cacheSuffix": "custom-suffix" }

En slumpmässig sträng som kan läggas till i slutet av cachenycklarna i systemet. Om inget värde anges används default. Du kanske vill ange ett värde här för att tvinga fram en cacheuppdatering i systemet tidigare än din cacheTime. Varje gång detta värde ändras kommer gamla cachade värden inte längre att användas och data kommer hämtas på nytt. Det bör inte vara nödvändigt att göra detta regelbundet; om så sker kan det tyda på att din cacheTime är för lång.

testExtensionSettings

Se dokumentationen för testtillägget

Konfigurations exempel

Eftersom JSON-syntaxen och de typdefinitioner som används ovan kanske inte är bekanta för alla, följer här ett konfigurations exempel.

warning

Detta MÅSTE redigeras / reduceras till endast de nycklar och alternativ som du behöver.

Se också till att inställningen ei02Variant är aktiverad i ERP7-systemet

{
    "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"
    },
    "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": "Anpassat värde"
    },
    "glDefaultDims": {
        "dim1": 3001,
        "dim2": "ABC",
        "dim6": "Anpassat värde",
        "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"
    }
}