Skip to main content

Invoice Extension Configuration

When configuring your Rossum Extension there are a few options you can tweak to adjust the invoice flow to better suit your organisation. These configuration options are set in the extension settings via your Rossum UI.

These should be written in JSON format.

info

Most parameters here are optional, with the exception of invoiceDocumentTypes and erpVersion. If any other parameters are not specified then we will use our defaults.

The only other exception to this is the ei02Variant which is required IF you are using the ERP7 / ERPCR version of the connector.

Parameter Definitions and Usage​

System Setup​

clientId​

string

{ "clientId": "ABC" }

If specified ALL ERP-queries will be restricted to this client ID.

if not specified, we will attempt to read this per-document from the data in the Rossum UI. If that is not specified then some attempt will be made to determine the client ID from the uncovered PO details.

Most subsequent lookups will fail if we cannot determine a client ID and so we recommend specifying this in the config wherever possible as it makes a big difference to the system reliability.

legalEntityIndex​

number

{"legalEntityIndex": 7 }

Should be set to the legal entity dimension number for the client.

If this is set, the system will try and identify legal entity codes and apply these to accounting information for non purchase order invoices.

erpVersion​

'erpx' | 'erp7' | 'erpcr'

{ "erpVersion": "erp7" }

The ERP version, this is important so we know what endpoints to use to retrieve data from and send data to.

  • ERPx Unit4's ERPx system
  • ERPCR Unit4's ERP CR system, you are likely on this system if you are using Unit4 cloud.
  • ERP7 This is most likely the version you are on if your servers are not hosted by Unit4.

transactionType​

string

{ "transactionType": "T1" }

This is the ERP Transaction Type code which we will pass through to your ERP when submitting the invoice, either directly in the JSON for ERPx or as the incoming invoice transaction type parameter on the EI02 for ERP7 / CR

ei02Variant​

number

{ "ei02Variant": 0 }

This is required for milestone seven, this is the EI02 report variant which will be run when the invoice is posted.

invoiceDocumentTypes:​

string[]

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

This is the list of document types that we will accept as invoices. If there is only one type we will enforce it, if not we will use the first as a default but allow the user to change it in the UI.

For fully-automated processes, this means that the docType will ALWAYS be the first in the list. If you require manual control, ensure that automatic processing is disabled.

locale​

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

{ "locale": "en" }

Only these exact strings will be accepted as valid locales. If not specified, we will use en

Some messages may not be translated, as we need to decode and validate the event before we can use the locale. So if we fail prior to that, error messages will be in English.

erpHeaders​

Record<string, string>

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

If set we will forward these headers along to the ERP system.

This may be useful, for example, if you have a self hosted ERP system to which you wish to control access.

You can use this to set a pre-defined header which can be used on a load balancer or reverse proxy to control access to the ERP system.

If a request is made to the ERP system without this header, it can be rejected by the load balancer or reverse proxy without hitting the server itself.

You may also wish to use this for analytics or logging purposes.

attachMessagesDocument​

none | warning | all

{ "attachMessagesDocument": "all" }

Which messages should be attached to the transaction in ERP as a secondary document. (This will be attached as zzzz_messages....) These are copies of the messages we send to the Rossum UI, so that ERP users have long-term access to the same messages.

  • none will never attach messages.
  • warning will attach messages of warning-level or above.
  • all will attach all messages including info

If not specified, the default behaviour is all.

ERP Connection Configuration​

warning

Note that these connection settings can now be set in extension secrets (where they were historically) OR here in settings (for better visibility).

If any of these values are set in both places, the one here in settings will take precedence.

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 and unit4SoapUrl are required for ERP7 / ERPCR systems.

erpxHost is required on an ERPx system

erpIdsHost is required on any system using IDS for authentication.

Document Processing​

manualTaxCodeIds​

string[]

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

If specified we will restrict tax-codes for non-PO lines (AP / extra PO lines / non PO invoice lines) to only those listed here.

Invoice lines matched to a purchase order line will still use the tax-codes from the purchase order as specified.

allowedTaxRates​

number[]

{ "allowedTaxRates": [0.2, 0.05] }

If specified we will restrict tax-rates to only those listed here. If we round near to one of these, we will "snap" to it. If we round to a rate not in this list we will ignore it and assume it's an OCR or invoice error.

allowAnyTaxCoding​

boolean

{ "allowAnyTaxCoding": false }

If this is set to true, the system will always allow any tax code (that respects the invoice currency) and tax system to be manually selected in account coding, regardless of tax percentages, account rules, the document being a purchase order invoice or the settings in manualTaxCodeIds.

Note that selecting a tax code that does not match the tax percent or currency on the invoice line will generate an ACL_004 warning or error because allowing this to go to ERP is likely to cause the import service to error the document as unbalanced. However this setting has been specifically requested by customers to allow them to capture the tax code prior to import, and update the purchase order with this tax code (using tools within Unit4)

If this setting is not set, or is set to false the tax codes available will be limited by the manualTaxCodeIds and the tax rate and currency on the invoice.

noPurchaseOrder​

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

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

This is used to determine if we can raise invoices without PO. If base is 'reject' then we will reject any invoice without a PO. If base is 'allow' then we will allow invoices without a PO.

If perSupplier is specified, we will look for a customField (flexifield) on the supplier and if found we will treat the value as the base value for that supplier. This value should be either allow or reject (or not present) so the flexifield should be configured with these options. An example value for the perSupplier field would be something like supppoctrl/no_po_no_pay_fx If not found, we will use the base value.

singleLineMatch​

'force' | 'auto'

{ "singleLineMatch": "force" }

If this setting is not set in the configuration, auto will be applied

This is used to force single line purchase order matching at the queue level. If set to "force", for orders where there is only one line on the order (at any status) the system will automatically match ALL invoice lines to that one order line.

If set to "auto" the line will only be matched if the standard automatic matching process finds a line to match to based on the available data.

lineRoundingTolerance​

'nearest' | 'floor'

{ "lineRoundingTolerance": "floor" }

If this setting is not set in the configuration, nearest will be applied

This controls how much rounding tolerance is allowed when checking a line's values (e.g. unit price * quantity) against the value printed on the invoice.

Most suppliers round line totals to the nearest penny, in which case the printed value can legitimately differ from the full-precision value by up to half a penny per item in either direction. This is the default ("nearest").

Some suppliers instead always floor (truncate) line totals rather than rounding to nearest. Since flooring never rounds up, their printed value can be short of the full-precision value by up to a full penny per item - double the standard allowance. Set this to "floor" for queues where the supplier is known to floor their line values, so undershoot is tolerated up to a full penny per item. An overshoot (printed value greater than the full-precision value) still only tolerates half a penny per item, since flooring never explains an overshoot.

roundingMode​

'item' | 'line' | 'total'

{ "roundingMode": "line" }

If this setting is not set in the configuration, line will be applied

This controls where, during line normalisation, a line's net/gross/tax values are rounded to 2 decimal places. Internal calculations are otherwise kept at full floating-point precision throughout - this is the one deliberate rounding pass. It is independent of lineRoundingTolerance above, which controls comparison tolerance rather than calculation, and the two settings can be used together.

  • "item": round the unit values first, then extend by quantity. This reproduces rounding-per-unit-before-extending. Opt-in only, for suppliers known to round per-unit before extending - it can introduce up to half a penny of error per item versus the full-precision line value.
  • "line" (default): round once at the resolved line-total level. Matches existing behaviour when no unit values are given, and avoids the rounding error "item" can introduce when unit values are given.
  • "total": don't round the line at all during normalisation - leave it at full precision, so summing many lines for the header-total check has zero compounding rounding error. Only observably different from "line" on multi-line invoices.

validPOStatus​

string[]

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

If this setting is not set in the configuration, our default filter of status NOT IN (N, P, T) will be applied

This is used to set purchase order header status which are considered valid for matching. If this is set and a purchase order is returned but not at one of the identified status, then it will not be used for matching and will not be passed to the ERP with the invoice data. The user will be presented with a warning message if a purchase order was found by the OCR, but not matched.

validSupplierStatus​

string[]

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

If this setting is not set in the configuration, our default filter of status = N will be applied

Some customers have requested that non-active suppliers be matched in the OCR, but an error raised if this is the case. E.g. they wish to know the supplier exists and was the best match, but that it is closed.

To avoid changing our original behaviour, this new status allows you to set valid status for suppliers which will be used when retrieving suppliers from the ERP API.

You may receive error SU_017 if the supplier is not at N or P status and warning SU_018 if the supplier is at P status. SU_018 can also be elevated to an error.

matchFirstFoundSupplier​

boolean

{ "matchFirstFoundSupplier": false }

If this setting is not set in the configuration, it defaults to true, which was the original behaviour, supplied for higher automation.

When we look for a supplier we search the ERP on several criteria; the supplier name, VAT registration number, company registration number and bank details. Occasionally more than one supplier record shares one of those values, so a single criteria returns two or more candidates.

With this setting true we use the first supplier found.

 Set it to false and we will not choose between them. Matching works through supplier statuses in turn, active (N) first, then parked (P), then everything else the search returned; and ambiguity is judged only within the check being examined. A matching criteria shared by one N and one P supplier is therefore not ambiguous: at that point the active supplier is the only option, and it is matched. Where two or more suppliers in the same check share the value, that criteria is skipped in favour of the next one, which may still identify a single supplier. If none identifies a unique vendor, the document is left unmatched with error SU_016, and every candidate the search returned is offered in the supplier dropdown for the user to pick from.

This does not affect a supplier taken from a purchase order, or one the user has selected manually, as both identify a supplier by its ID.

Note that defaultSupplierId, where it is configured, still applies. A document we decline to guess at is routed to that supplier rather than left unmatched, as the two settings answer different questions: this one asks whether to choose between candidates, defaultSupplierId asks what to do when no candidate was identified at all.

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": "Custom value"
   }
}

We use these defaults to enable automated submission.

On the AP line, we pull account from the supplier group and then fill in any valid dimensions with the dimensions from here.

If not provided these will need to be filled manually in the UI.

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": "Custom value",
        "account": "3000"
    }
}

For invoices without a PO, we will use these defaults to enable automated submission.

If not provided these will need to be filled manually in the UI.

defaultQuantity​

number

{ "defaultQuantity": 1 }

If we can't read a quantity for a line item we will fall back to this value.

defaultSupplierId​

string

{ "defaultSupplierId": "1000" }

If we can't determine a supplier we will fall back to this value.

Before using this we will check the purchase order for a supplier, then search the company-number, vat-number fields and bank details for a supplier. If we can match on any of those, we will. If not we will use this value when set.

defaultAccountable​

string

{ "defaultAccountable": "101" }

We try to match the active Rossum user to an ERP user. If successful we will set that ERP-user to be the accountable person for this invoice.

If we do not succeed in matching the user, we will fall back to this value when set.

This value will eventually appear in the ext_ref field on the invoice transaction

ignoreTax​

boolean

{ "ignoreTax": false }

This one makes no major changes to the UI, but when submitting the invoice to ERP we will only submit gross values and set all the tax to zero.

This is a rarely used setting for special types of organisation who never handle VAT or other tax rates and only manage gross values internally. We maintain the tax in the UI even when set to ensure that the invoice lines balance to the header, but we will not submit the tax to ERP.

taxCodeAttrId​

string

{ "taxCodeAttrId": "A1" }

This is used to look up attribute relations and in value matrices, should you have a configuration where tax-code is linked to accounting dimensions.

If not provided we will use the value of A1 so we strongly recommend overriding this if you are using a different attribute ID for tax codes.

taxSystemAttrId​

string

{ "taxSystemAttrId": "GK" }

When requesting tax-system configuration from ERP7/ERPCr we will use this attribute Id as an identifier. If not provided the default value used will be GK so we strongly recommend overriding this if you are using a different attribute ID for tax systems.

This is also used to look up attribute relations and in value matrices.

ignoreZeroRows​

boolean

{ "ignoreZeroRows": true }

If true a zero-row should will show an info notice, but then be filtered out before sending to ERP.

If false a zero-row will show an error and block submission until manually corrected in the UI.

headerOnly​

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

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

This can be set on / off at the queue level by setting base to true / false , however you can then over-ride this per supplier. We will look for a customField (flexifield) on the supplier and if found we will treat the value as the base value for that supplier.

This value should be a checkbox field on the flexifield as this is then true or false.

An example value for the perSupplier field would be something like supocrctrl/header_only_fx (This could be another field on the same flexifield as used for the no po no pay setting)

If true either per queue or per supplier, the extracted line items are ignored entirely. A single invoice line carrying the full header totals (net / tax / gross) is generated, along with its GL accounting line and the AP line. All the usual balancing validations still run, but against this generated line so they balance.

This is for customers who only want to post header values and let ERP (or a downstream process) handle the detail.

glDefaultDims.account must be a valid ERP account, otherwise the generated line will be blocked by the "please choose account code" validation.

If no value is provided then it will be treated as false

autoGenerateGlLine​

boolean

{ "autoGenerateGlLine": true }

A fallback for when no line items were extracted from the document.

If true and the OCR produced zero line items, a single invoice line carrying the full header totals is generated (the same as headerOnly), along with its GL and AP accounting lines, and an elevatable warning is raised so a human is made aware the line was auto-generated.

If line items were extracted, this setting has no effect. If headerOnly is also set, headerOnly takes precedence and no warning is raised.

If no value is provided then it will be treated as false

ignoreDueDate​

boolean

{ "ignoreDueDate": true }

Ignore the due date on the invoice and allow Unit4 to calculate it using standard setup.

Do not enable this at the same time as calculatedDueDate as this would discard the date we calculated. Turning both on raises a QSET_012 warning.

calculatedDueDate​

boolean

{ "calculatedDueDate": true }

Calculate the invoice due date from the supplier's credit terms in the ERP, rather than relying only on the due date read off the document.

When this is on, the supplier's payment terms ID is looked up against the ERP credit-terms object and the due date is calculated from the invoice date using the term's due date method. The result is written to the Calculated due date (date_due_calculated) field.

The invoice date itself is calculated either tax point date, issue date or today's date (if you have export date as invoice date set), the calculated value will be used for the due date calculation.

Do not enable this at the same time as ignoreDueDate: that setting blanks the due date on export so Unit4 can calculate it, which would discard the date we just calculated. Turning both on raises a QSET_012 warning.

Altering your rossum schema

If you enable this setting you MUST alter your existing rossum schema see below

Required queue setup​

This setting needs two manual changes in the Rossum field manager for the queue. It does nothing until they are made.

  1. Add a Calculated due date field with the ID date_due_calculated to the Invoice info section, as a date field with the format D/M/YYYY. If you are happy to edit the JSON you can copy it from the schema document but make sure you set hidden to false.

  2. Make sure your connection user has access to the credit-terms object in ERP

  3. Change the existing Due date (date_due) field from a captured field to a formula field pointing at the calculated one:

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

date_due is what gets exported to the ERP, so pointing it at the calculated field is what makes the calculation take effect.

If you prefer to edit the JSON it looks like this

{
        "rir_field_names": [],
        "constraints": {
          "required": false
        },
        "score_threshold": 0,
        "default_value": null,
        "category": "datapoint",
        "id": "date_due",
        "label": "Due date",
        "description": "The due date of the invoice.",
        "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"
      },
Overriding the calculated date​

Simply overwrite the original date_due field.

When no date can be calculated​

The field is left blank, and a warning is shown against it, when:

DUE_001The matched supplier has no payment terms configured in the ERP.
DUE_002The supplier's payment terms were not found in the ERP.
DUE_003The credit term uses a due date calculation method we do not support.

A blank calculated due date means the formula falls back to an empty due date, so these warnings should be resolved in the ERP supplier or credit term setup.

exportDateAsInvoiceDate​

boolean

{ "exportDateAsInvoiceDate": true }

Will overwrite the invoice date on all invoices, with the current date on export to ERP. If not set this will use the standard behaviour of extracting from tax point date or issue date fields.

forceOrderProductAndDescription​

boolean

{ "forceOrderProductAndDescription": true }

When a line is matched to a purchase order line, always overwrite the line's product code and description with the values from the purchase order line, even if OCR extracted its own values.

If not set (or false), the purchase order line's product code/description are only used as a fallback when OCR did not extract a value for that field.

arrivalDateOutput​

rossumArrived | export

{ "arrivalDateOutput": "rossumArrived" }

If set, the <ArrivalDate> XML element (ERP7/CR) / registeredDate field (ERPx) will be set to either:

  • rossumArrived the arrived_at date set on the document in Rossum.

  • export the current export timestamp.

If not set, these export fields will not be included.

firstLineAsDescription​

boolean

{ "firstLineAsDescription": true }

If set to true, the first invoice line description will be used as the overall invoice description (this is the description on the AP line). If not present or false, a timestamp will be entered as the description.

payRecipientCheck​

boolean

{ "payRecipientCheck": true }

If this is set to true the system will flag an INFO message against the matched supplier, if a pay recipient (Factor company) is identified as set on the supplier record. This will be upgraded to a WARNING message if the pay recipient is not status N.

payRecipientBankCheck​

boolean

{ "payRecipientBankCheck": true }

If this is set to true, the system will match the bank details AND currency from the invoice to those from the pay-recipient (instead of those on the supplier masterfile).

supplierVatCheck​

boolean

{ "supplierVatCheck": true }

If this is set to true, the VAT number read from the invoice is compared against the VAT number on the matched supplier's master record, and a warning (SU_020) is raised against the Vendor VAT number field if they disagree.

This matters most where the supplier was taken from a purchase order. In that case the supplier is accepted without question, so nothing else on the document is otherwise checked against the supplier we are about to pay.

A blank value on either side is accepted — only a genuine disagreement raises a warning. Punctuation and letter case are ignored.

If not specified, the default behaviour is false.

supplierCompanyRegCheck​

boolean

{ "supplierCompanyRegCheck": true }

As supplierVatCheck, but for the company registration number, raising SU_021 against the Vendor company ID field.

If not specified, the default behaviour is false.

supplierNameMinSimilarity​

number (0-100)

{ "supplierNameMinSimilarity": 70 }

Compares the supplier name read from the invoice with the name in the master data of the matched supplier, and raises a warning (SU_022) on the Vendor Name field when the names are not alike enough. The warning text includes the score, so you can see how a given pair of names was rated. 0 disables the check.

Company names are often not written identically on the invoice and in the ERP, so this is a similarity percentage rather than a straight comparison. Before comparing, the system folds accents to plain letters, reads & as "and", and, where there is one, writes the legal form the short way in whichever language it appears. So for example Limited becomes Ltd, Aksjeselskap becomes AS, Aktiebolag becomes AB, Sociedad Limitada becomes SL, and so on. This covers the legal forms used across Europe, the USA and Canada, and names written in Cyrillic or Greek are compared as well.

70 is the recommended starting point, but you may need to adjust it for your data.

Measured examples:

Invoice nameSupplier masterScore
Acme Trading LtdAcme Trading Ltd.100passes
Northern Builders LimitedNorthern Builders Ltd100passes
J Smith & Sons LtdJ Smith and Sons Limited100passes
Laser-Tone ASLaser Tone Aksjeselskap100passes
Nordiska Bygg ABNordiska Bygg Aktiebolag100passes
Constructora Ibérica SLConstructora Iberica Sociedad Limitada100passes
Société Générale SASociete Generale Societe Anonyme100passes
Acme Trading LtdAcme Trading Co Ltd86passes
Acme Trading LtdAcme Trading Group Ltd77passes
Acme Trading LtdAcme Holdings Ltd59warns
Northern Builders LtdNorthern Roofing Ltd51warns
Acme Trading LtdAcme Logistics Limited36warns
Acme Trading LtdBarclays Bank PLC0warns

Two limitations are worth knowing:

  • This compares names only. Two companies in the same group that share a trading name but differ in legal form (Acme Trading Ltd against Acme Trading AS) score around 80 and will pass. The company ID and the bank detail checks are the right control for that case.
  • A supplier that invoices under a trading name quite unlike its registered name (Wm Morrison Supermarkets PLC against Morrisons) will warn every time. That is why this is a warning rather than an error, and why it is off by default.

A blank value on either side is accepted.

If not specified, the default behaviour is 0 (disabled).

supplierConfidenceCheck​

boolean

{ "supplierConfidenceCheck": true }

The checks above each compare one field. This one asks whether the matched supplier as a whole looks right. That matters most where the supplier was taken from a purchase order.

One of two warnings may be raised against the supplier field:

  • SU_023: the invoice's VAT number, company registration number, IBAN or bank account belongs to a different supplier in the ERP, and not to the selected one. The warning names that supplier.
  • SU_024: none of the selected supplier's VAT number, company registration number, IBAN or bank account agree with the invoice, and at least one of them, or the supplier name, disagrees. The warning lists what disagrees.

If at least one of those identifiers agrees, the supplier is taken as confirmed and SU_024 is not raised, even if other fields disagree. Those are still reported by their own checks, where switched on. SU_023 is still raised if another of the invoice's identifiers belongs to a different supplier.

Some details worth knowing:

  • Account numbers repeat from one bank to the next, so where either the invoice or the ERP record has a sort code, the bank account only agrees if both have one and it agrees too. Where neither has one, as in the USA, the account alone decides.
  • VAT numbers are compared with or without their two letter country prefix, and IBANs regardless of spacing, both when searching the ERP and when comparing. A value stored in the ERP with spaces or punctuation inside a VAT number (e.g. GB 123 456 789) cannot be searched for, so that supplier is only found if another detail finds it.
  • With payRecipientBankCheck on, a supplier's bank details are those of its pay recipient. A pay recipient such as a factoring company is usually shared by many suppliers, so its bank details say where the money goes, not who sent the invoice. They can still disagree, but they never confirm the supplier on their own, and never name another supplier in SU_023.
  • The name is compared as for supplierNameMinSimilarity, using that setting's value, or 70 where it is 0 or not set.
  • The default supplier is never checked, and never named as the other supplier.
  • It does not need the checks above switched on.

Both are warnings, so add SU_023 and/or SU_024 to elevateWarnings to block processing.

If not specified, the default behaviour is false.

elevateWarnings​

string[]

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

An array of codes which usually generate warnings, but the organisation wishes to elevate to errors.

Adding items in here will cause the schema field override_warnings to error if there are warning messages present which are in the elevated list. For more information please see the warnings documentation

Please see the list of warnings that can be elevated

compressGL​

boolean

{ "compressGL": true }

If no value is given, this will be set to false.

ERPx ONLY If set to true this sets the flag on the API endpoint. Unit4 describe this as: if set to true, the GL and tax rows are aggregated according to the GL analysis. The description entered for the GL row is not transferred to the General Ledger. (Behaviour can be replicated in ERP7 with the compress parameter on EI02).

showSupplierMessage​

none | warning | info

{ "showSupplierMessage": "none" }

If the field "message" on the invoice tab of the supplier masterfile has a value, it can be displayed as an info or warning message against the selected Vendor field in Rossum.

  • none will never show a message.
  • info will show the message text displayed as an info type
  • warning will show the message text displayed as a warning type

If not specified, the default behaviour is none.

Caching​

cacheTime​

number

{ "cacheTime": 3600 }

If no value is given, the default of 3600 seconds (one hour) will be applied.

The amount of time (in seconds) that data (such as suppliers, purchase orders, accounting information) from Unit4 will be held by the cache. The longer this is, the fewer API requests need to be made and the faster the service will run. The offset against a longer cache time is that data will take longer to "appear" in the OCR system.

cacheSuffix​

string

{ "cacheSuffix": "custom-suffix" }

A random string which can be applied to the end of the cache keys in the system. If no value is supplied then default is used. You may wish to define a value in here to force a cache refresh in the system sooner than your cacheTime. Any time this value is changed, old cached values will no longer be used and data will be retrieved fresh. It should not be necessary to do this regularly, doing so may indicate your cacheTime is too long.

testExtensionSettings​

Please see the test extension documentation

Example Configuration​

As JSON syntax and the type definitions used above may not be familiar to everyone, here is an example configuration.

warning

This MUST be edited / reduced to only the keys and options which you require.

Please also ensure an ERP7 system has the ei02Variant set

{
    "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": "Custom value"
    },
    "glDefaultDims": {
        "dim1": 3001,
        "dim2": "ABC",
        "dim6": "Custom value",
        "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"
    }
}