Documentation/ ERP integrations/ ICG
Delivery notes and supplier invoices straight into ICG
Dijit.app posts delivery notes and purchase invoices straight into ICG: numbering by series, taxes, supplier discounts and the due date in the cash ledger, exactly as they would look if somebody keyed them by hand in the application itself. Where an invoice carries the supplier's delivery note numbers, it links them too, just as ICG does when a delivery note is invoiced from inside.
Several entities at once
One integration serves each entity's database, each with its own user and its own defaults.
It leaves no half-written documents
Before anything is written it checks that the items exist and that the supplier has a nominal account. If something is missing, the whole document is rejected.
Invoices linked to their delivery notes
If the invoice carries the supplier's delivery note numbers, each is found and marked as invoiced.
It does not guess
Taxes, descriptions and discounts are read from the ERP. The connector creates no suppliers, items or VAT rates.
On this page
What it does
What the connector does
Searching suppliers and items
Before sending anything, you can search by name, tax number, description or supplier reference to match the data against ICG's codes.
Items validated before anything is written
It checks in one pass that every item on the lines exists in the master. If any is missing, the whole document is rejected without touching the database.
Numbering consistent with ICG
The number is taken from the series' official counter or from the highest already in the table, whichever is greater: it does not collide with documents created by hand.
The supplier's discount wins
If the supplier has an agreed discount on their record, it takes precedence over whatever the document's line carries.
Taxes and cash ledger automatically
The breakdown by VAT rate and the payment due date are generated from the supplier's nominal account and payment method.
Invoices linked to their delivery notes
The supplier's delivery note numbers the invoice covers are found and marked as invoiced, exactly as when invoicing from inside ICG.
Several entities, each with its own credentials
Each entity connects with its own database user and with whatever permissions belong to it.
Sendings kept apart
A document that fails does not affect the others in the same sending: each gets its own result.
Several entities
Several entities at once
A group of companies usually has one ICG database per entity. The integration serves them all from a single point: each sending says which entity it should work on, and the right connection is resolved at that moment, with its own user and its own defaults for series, warehouse and expense account.
There is no shared state between sendings that could mix one entity's data with another's: the entity is declared on every request, and a sending with no entity is refused at once.
Adding a new entity is a configuration job, not another deployment to maintain.
How it connects
How it connects
The integration writes straight into ICG's database. The documents it creates are ordinary delivery notes and purchase invoices: they are seen, posted and reported exactly like the ones your team keys by hand.
Access and security
- One database user per entity. The integration connects with the credentials you supply and works within that user's permissions: read on the masters, write on purchasing and the cash ledger.
- Prepared statements throughout. Every value travels as a parameter; nothing is ever concatenated straight into a statement.
- The entity is validated before connecting. The entity reference is checked against a closed format before it is used to resolve the connection.
- Passwords hidden in the settings. They are stored encrypted; leaving the field empty when editing the parameters keeps the previous one.
- Deployed inside the customer's network. The service runs alongside the ERP, within the customer's perimeter, and does not expose the database outside.
The document's journey
How each document is processed
A document is written in several steps and the order matters, because each depends on what the one before produced.
Purchase delivery note
- 01Destination checked. It verifies the document carries a series and a warehouse. Without them there is nowhere to write and it is refused without touching the database.
- 02Items checked. It verifies in one pass that every item on the lines exists in the master. If any is missing, the whole document is refused.
- 03Number reserved. The series' next number is worked out, taking the greater of the official counter and the highest already in the table.
- 04Header. Recorded with supplier, date, discounts, net, taxes and total, and the series' counter moves on.
- 05Lines. Each is inserted with the item's official description, its tax rate and the supplier's discount where there is one.
- 06Taxes and cash ledger. The breakdown by VAT rate and the due date are recorded using the supplier's nominal account and payment method.
Integrity rule. Items are validated before the header is recorded: it stops an unknown item on one line leaving a half-written delivery note in ICG for somebody to delete by hand.
Purchase invoice
It follows the same path as the delivery note, numbering, header, lines, taxes, with one particularity: it can include the supplier's delivery note numbers that it covers. Each is found among that supplier's delivery notes, marked as invoiced and given the reference to the invoice, just as when a delivery note is invoiced from within the application itself.
The search is always narrowed to the invoice's supplier, because a delivery note number is only unique within one supplier. If no match turns up, or more than one does, that delivery note is left alone and the reason recorded: linking the wrong delivery note is worse than not linking it. An invoice with no delivery notes is processed the same way, with no links.
If the invoice is recorded but some delivery note cannot be linked, the sending is treated as successful and says which delivery notes were left outstanding. Sending the invoice again would duplicate an accounting document; the link, by contrast, can be redone by hand.
Business rules
Business rules
These are the decisions the connector takes in translating a document into ICG's model. They explain differences between what was sent and what appears in the ERP.
| Rule | Behaviour |
|---|---|
| Numbering | The series' official counter or the highest existing in the table, whichever is greater, so as not to collide with documents created by hand. |
| The line's tax | Taken from the ERP's item master, not from the incoming document. |
| The breakdown's tax | It finds the rate whose percentage matches the breakdown sent. Faced with several candidates, it takes the lowest, deterministically. |
| The line's description | Overwritten with the item's official description in ICG. |
| Line discount | The discount agreed with the supplier, where there is one, takes precedence over the document line's. |
| Rounding | Net amounts and tax are rounded to two decimals, and each rate's total is recalculated already rounded. |
| Supplier or item with no reference | The defaults set at go-live are used. |
| Cash ledger | The due date is generated from the nominal account and payment method on the supplier's record. With no nominal account, the document is not treated as successful. |
General principle. Where the incoming document and the ERP's master disagree on something ICG considers its own, taxes, descriptions, supplier discounts, the ERP wins. The connector does not alter masters.
Results
Results and errors
Every document sent produces its own result: how many went in, which did not and why. The ones that fail stay in the list with their reason, and the list refreshes either way.
| What you see | Why | What to do |
|---|---|---|
| Supplier ID missing in ICG | The supplier's record has no reference. | Fill it in on the supplier master. |
| Every document from one supplier fails | It is the same value missing from their record. | Correct the record once and send them all again. |
| The ERP badge shows a dash on several lines | Items are still to be assigned. | Assign them from the assignment dialogue. |
| A whole line fails with "item has no purchase tax" | The item has no VAT rate set in ICG. | Fill it in on the ERP's item master. |
| An invoice does not link one of its delivery notes | The number does not appear, or appears more than once, among that supplier's. | The invoice is recorded anyway; check and link that delivery note by hand if needed. |
| The whole sending fails with a connection error | A problem reaching the ICG database. | Try once more; if it persists, go over the parameters with whoever administers the ERP. |
| A reference code already set has to be corrected | The wrong item was assigned. | Use that line's additional information dialogue. |
Going live
Going live
Going live is a short list. Almost all of it is confirming what already exists in ICG, rather than building anything new.
- 01The ICG server reachable from wherever Dijit.app connects.
- 02A database user per entity, with read on the masters and write on purchasing and the cash ledger.
- 03Series and warehouses agreed per entity, with the series' counter already existing in ICG.
- 04Suppliers with their reference code filled in on their record, so documents attach without failing.
- 05Nominal account and payment method complete on every regular supplier's record.
- 06A default supplier and item, for documents or lines that arrive with no reference.
- 07A trial on a test database before switching real entities on.
- 08Who receives each sending's summary, with the count of documents that worked and failed.
Scope
What it does today and what it does not
What it covers
- Creates complete delivery notes and purchase invoices, with taxes and the due date in the cash ledger.
- Links invoices to the delivery notes they cover, just as ICG does when invoicing from inside.
- Looks up suppliers and items so data can be matched before anything is sent.
- Serves several entities from one integration, without mixing their data.
- Refuses a document outright where it cannot write the whole thing, rather than leaving it half done.
What it does not do
- It creates and changes no suppliers, items or VAT rates: they are always ICG's.
- It generates no accounting entries and closes no periods.
- It does not cover the sales cycle or stock, only purchasing.
- It does not correct incomplete documents or guess which item was meant.