Interface Exact via API
The exact export module API is only intended for the Exact Online accounting system. Other Exact packages are not supported.
Parameters
A number of parameters apply to Exact Online
| Parameter | Allowed values | Example | Description | Comment |
|---|---|---|---|---|
| cust_id_length | Numeric | 8 | The length of the customer ID. This means that the ID is padded with leading zeros. | Optional |
| cust_id_prefix | Text | IR | An optional prefix | Optional |
| journal_code | Numeric | 70 | Journal code, default value in Exact is 70 | Optional |
| Invoice field | Select field | external_id | Use a field other than external id if multiple integrations are running. | Mandatory |
| Customer field | Select field | external_id | Use a field other than external id if multiple integrations are running. | Mandatory |
| Contact person field | Select field | custom01 | Use this field for the contact ID | Optional |
| Use VAT excluding | Yes/No | If yes, use the exclusive field | Optional | |
| Use date fields | Yes/No | Convert the date fields from and to from the IRES to EOL invoice | Optional | |
| Make invoice final | Yes/No | If no, the invoice remains in draft | Optional | |
| Send email after finalizing | Yes/No | If yes, the invoice will be sent via email from EOL. Set to no if the invoice should be sent from IRES |
Optional |
Data model
At IRES the customer is leading. There may be a company-customer structure, but the customer is the basis for synchronization with EOL. In EOL the structure is Account-Contact. Although this may be misleading at first, the Customer IRES will be transferred to an Account EOL. And then a Contact can be added. Yet the data model is more similar than appears at first glance. Because almost every field can be overwritten by linking it to another field from IRES. For example, the EOL-Account-Name can be filled with IRES-Company-name.
Multiple IRES customers can be linked to the same EOL Account.
The EOL Code field also requires attention. Each account in EOL receives an internal UID (not visible in EOL, but visible in the external id field in IRES). When data is synchronized, the UID is checked first. If it exists in EOL, then this Account will be used. If this does not exist, an Account with Code equal to the Code in IRES is searched for. However: IRES Code is a "optional" field. This can be the cust_id but also a custom field.
Mapping
A number of mappings apply to Exact Online
| Parameter | Allowed values | Example | Description |
|---|---|---|---|
| vatmapping | Numeric | 8 -> 12 | The VAT code mapping |
| article mapping | Text | IR | Item mapping |
Determine items
This paragraph is only if the invoice mode will be used. I-Reserve lines must then be converted to exact items. Because journal entries have not been selected in such an export, i-Reserve uses the general ledger account field to determine the item. A period can, for example, have id=12 in i-Reserve, with an associated price. A general ledger account of, for example, 12 can be specified. A corresponding exact item, for example “STANDARD”, must then be set. In the following paragraphs we will make the connection between the two. But first we set up exactly.
Determine general ledger determination method
IRES passes on a customer + invoice with invoice lines. The invoice line contains an item but no ledger. Exact Online uses two methods in which a general ledger is assigned to an invoice line. The settings in EOL can be used to indicate whether the general ledger should be allocated on the basis of an item or on the basis of the customer. We explain these two methods.
1. Item-based ledger. In this case, the item must exist in EOL at the time of reading the invoice. This item should also include the general ledger. At first glance, this construction can be confusing: the general ledger in IRES is translated into an item in EOL and a general ledger is determined again when the invoice is created. Tip: create an item that has the general ledger as code. For example, item 8000 with ledger 8000. This ensures less confusion, while still showing the description on the line, so there is no customer confusion.
2. Customer-based ledger. In this case, two working methods can be applied.
2a. It is ensured that all customers (debtors) in EOL are manually provided with a correct ledger prior to reading
2b. A field is set up in IRES where the general ledger can be specified. In the connection, this field must be linked to the GLA account in EOL via the parameters. The link then ensures that EOL is updated.
Wat wordt er gekoppeld?
| i-Reserve | Richting | Exact | Overschrijven * |
|---|---|---|---|
| Klant | Account | ||
| cust_id | > | code | Ja |
| Bedrijfsnaam | > | Name | Ja |
| Telefoon | > | Phone | Ja |
| IBAN | > | BankAccount | |
| Betaalconditie | > | SalesPaymentCondition | |
| Klant | Contact | ||
| Achternaam | > | LastName | Ja |
| Prefix | > | MiddleName | Ja |
| Initialen | > | FirstName | Ja |
| Mobiel | > | Mobile | Ja |
| Telefoon | > | Phone | Ja |
| > | Ja | ||
| Klant | Address | ||
| Adres + Huisnummer + Toevoeging | > | AddressLine1 | Ja |
| Postcode | > | PostalCode | Ja |
| Woonplaats | > | City | Ja |
| Land | > | Country | Ja |
| Factuur | SalesInvoice | ||
| Factuurnummer | > | ordernumber | |
| Factuurdatum | > | OrderDate | |
| Omschrijving | > | Description | |
| Aangepast veld XX | > | YourRef | |
| cust_id | > | InvoiceTo | |
| Factuurregel | InvoiceLine | ||
| Mapping Grootboek | > | Item | |
| Regelomschrijving | > | Description | |
| 1 | > | Quantity | |
| Regel-Sub | > | NetAmount | |
| Datum vanaf | > | StartDate | |
| Datum tor | > | EndDate |
* Override => kan aangepast worden naar ander bron veld
