e-copedia hjælpecenter

Using a custom reference to identify sales documents via the API

Since there isn

Sidst opdateret:
Skrevet af Charles J

Sales documents in e-conomic can move through different stages depending on whether the customer uses quotes, orders or invoices alone:

  • Quote → Order → Invoice

  • Quote → Invoice

  • Order → Invoice

When building an integration, it is possible maintain a reference to the same transaction throughout its lifecycle, regardless of which document type it currently exists as.

This is where we recommend using the references.other property to store your own external identifier.

Example:

"references": "other":{customOrderID}

The primary reason to use references.other is that it can be used as a filter when retrieving sales documents through the API.

Obs

Property externalID isn't present in our documentation but can also be used as a customer reference field, though filtering isn't applicable.

Locating Documents Throughout the Lifecycle

Since references.other is filterable, it can be used to locate documents regardless of where they currently exist in the sales process.

Examples:

GET /quotes/drafts?filter=references.other$eq:{customOrderID}
GET /orders/drafts?filter=references.other$eq:{customOrderID}
GET /invoices/drafts?filter=references.other$eq:{customOrderID}
GET /invoices/booked?filter=references.other$eq:{customOrderID}

This allows an integration to determine whether the document currently exists as a quote, order, draft invoice or booked invoice.

Users Can Change the Value

The references.other field is editable within e-conomic.

While we generally recommend using references.other for lifecycle tracking, it should not be considered an immutable system identifier.

If your integration relies on references.other as a primary identifier, it is therefore possible that the value may no longer match the value originally supplied by your integration. You may also change the identifier yourself via your app.

Visibility on Invoice Layouts

The references.other field can be displayed on the PDF layout presented to the customer.

e-conomic allows customization of invoice layouts through the Design & Layout section of the web interface. This means that the label shown to the recipient can be adjusted to better reflect the purpose of the value stored in references.other or removed completely.

Keep in mind that PDF layout customization is configured through the e-conomic web interface and is not exposed through the API.

Additionally, when using electronic invoicing formats such as EAN or Peppol, the standardized mapping used by e-conomic applies. Any customized PDF labels may therefore not be reflected in the electronic invoice received by the recipient.

Var denne artikel nyttig?