Skip to main content

Data Mart ETL - 2026-09-28

Data Mart Team
Visma Net ERP Data Mart

In this release:

Customers​

Breaking change: creditVerification and statementType values aligned with the Visma.net REST API​

Customer synchronization now converts creditVerification and statementType from ERP single-character codes to the REST-aligned values. See the API value mappings when updating integrations. Existing records receive the converted values through the historical backfill; deployment alone does not establish that the backfill is complete.

Customer attributes​

Customer synchronization now imports attributesId. See the API field definitions for its meaning and attribute-value availability.

Customer notes​

Customer synchronization now imports note and picks up subsequent changes. Clearing a note replaces the previously synchronized text. Customers without a note remain in the collection. The historical backfill supplies notes for existing documents.

The updated API and Customers ETL must be deployed before integrations select note. See the API release notes for a GraphQL example and comparison with the dedicated ERP customer-note endpoint. Follow the historical-data guidance below to retrieve notes for customers that have not otherwise changed.

Customer sync includes invoicing and debt collection settings​

Customer synchronization now imports the invoicing, debt collection and default payment-method settings listed in the API field definitions.

The dunning-letter flags and excludeDebtCollection use false for missing source values; invoiceToDefaultLocation remains nullable. Customer defaultPaymentMethodId comes from ERP Customer.DefPaymentMethodID, while Location paymentMethodId comes from Location.VPaymentMethodID. The API lookup guidance explains how to use these separate settings.

Customer lookups​

Related master-data values remain in their owning ETLs rather than being copied into Customers. See the API Customer lookups for billing and delivery data, Attention, price class and payment-method keys, and the relationships that are not yet available.

Historical data and reimport​

The Customer backfill updates nine fields on existing documents: attributesId, printDunningLetters, sendDunningLettersViaEmail, invoiceToDefaultLocation, excludeDebtCollection, defaultPaymentMethodId, creditVerification, statementType and note.

The Customer backfill does not advance updatedInDataMartDateTime. An incremental fetch based on this timestamp will therefore not return every backfilled record. After the Production release and Customer backfill are complete, we will send a follow-up email confirming when integrations can start a full Customer reimport to refresh their stored values.

Locations​

Global Location Number (GLN)​

The Locations ETL now synchronizes gln from the location's Global Location Number. See the API Locations section for the field contract and Customer lookup.

Historical data and reimport​

The separate historical backfill updates existing Locations documents. The Locations backfill does not advance updatedInDataMartDateTime. An incremental fetch based on this timestamp will therefore not return every backfilled record. Production completion of the Locations backfill must be confirmed separately. Refresh previously imported Locations to retrieve GLN values once the separate Locations backfill is confirmed complete.

Contacts​

Date-of-birth synchronization​

The Contacts ETL imports dateOfBirth from the ERP Contact record. The value stays in Contacts; Employees use their existing contact reference to obtain it. See the API Contacts section for date format, nullability and lookup guidance.

Historical data and incremental fetching​

A separate backfill adds dateOfBirth to existing Contacts documents where the field is missing and a matching ERP Contact can be read. It writes an explicit null when the source has no date. An existing field is preserved, including an existing null value.

Each changed document receives a new updatedInDataMartDateTime. Existing deletion flags and all other fields remain unchanged, and the backfill does not create missing Contacts documents. Replaying the backfill skips documents where dateOfBirth already exists.

After the backfill is confirmed complete in your environment, continue normal incremental fetching from the checkpoint saved before the backfill and retrieve all pages. The updated timestamp makes the changed Contacts eligible for that fetch; a full reimport is not required solely for this backfill. Ensure your query and stored mapping include dateOfBirth.

If your integration retains soft-deleted Contacts or needs every record changed by the backfill, set includeDeleted: true on the contacts query. It defaults to false, so soft-deleted records are otherwise excluded even when their update timestamp changes.

Deploying the API and ETL does not run the backfill. Completion must be confirmed separately for each environment; these release notes do not establish Production completion. A returned null is a valid field value and does not by itself prove that a backfill is missing or complete.

Branches​

Branch-name synchronization​

The Branches ETL imports branchName from the branch's associated business-account name, trimming leading and trailing spaces. It preserves branchCode. If the matching business account is missing or deleted, branchName can be null. See the API Branches section for the field contract and Employee lookup.

Historical data and incremental fetching​

A separate backfill adds branchName to existing Branches documents where the field is missing, matching company and branch ID. Existing values, including explicit null, are preserved. It does not create missing documents or change deletion flags or other fields, apart from setting a new updatedInDataMartDateTime on each changed document.

Confirm completion separately for each environment after deployment. Continue incremental fetching from the checkpoint saved before the backfill and retrieve all pages, selecting and storing branchName. A full reimport is not required solely for this backfill because it advances the update timestamp. These notes do not establish Production backfill completion.

If your integration retains soft-deleted Branches or needs every record changed by the backfill, set includeDeleted: true on the branches query. It defaults to false, so soft-deleted records are otherwise excluded even when their update timestamp changes.

SalesOrders​

Field removal​

This release removes the 11 SalesOrder fields listed in the API removal list and replacement lookups. Update integrations using that guidance.

Related master-data values are resolved through their owning collections. The order's shipping-contact snapshot remains part of SalesOrders; see the API guidance for the retained fields and complete lookup keys.

Reimport​

Prepare a full SalesOrder reimport, and wait for the release-completion notification before starting it. Update the integration first so that reimported records no longer depend on the removed fields.

Previously imported copies may still contain retired fields. Their presence does not mean the fields remain available through the updated API; remove that dependency from stored mappings and reports.

Employees​

Synchronization and deletion​

The Employees ETL supports subscription, full refresh, correction and soft deletion. Its scheduled synchronization re-reads the company's employee projection at low frequency so changes to associated user and workgroup information are included. Documents are matched by companyId and employeeId. Each imported document receives a refreshed updatedInDataMartDateTime.

Soft deletion follows the employee and its underlying business-account and vendor records. A later refresh also clears workgroup descriptions when memberships are removed. See the API Employees section for the field contract, SalesOrder owner lookup and related master-data keys.

Availability and existing records​

Use Employees only where the updated API and ETL are deployed, the company's Employees subscription is active, and the initial import has completed. Merged code alone does not confirm availability in an environment.

The regular Employee import supplies the nullable noteId for future attribute lookup; an existing company receives it through a successful full-refresh run after deployment. It does not require a separate field backfill. Contacts date of birth and Branches names use their separate backfills described above; those values are not copied into Employees.

Customer and supplier IDs on lines​

Synchronization​

The line ETLs now import the customer or supplier ID of each line and keep it up to date on subsequent changes. No additional ETL activation is required. See the API field definitions for types and lookups.

LinesERP sourceData Mart field
SalesOrderLinesSOLine.CustomerIDcustomerId
CustomerDocumentLinesARTran.CustomerIDcustomerId
SupplierDocumentLinesAPTran.VendorIDsupplierId
CustomerPaymentLinesARAdjust.CustomerIDcustomerId
SupplierPaymentLinesAPAdjust.VendorIDsupplierId

ERP sets each value from the line's parent document. SOLine.CustomerID is nullable in ERP, and a missing customer is stored as null.

Historical data and reimport​

A separate historical backfill updates existing documents in all five line collections. The backfill does not advance updatedInDataMartDateTime. An incremental fetch based on this timestamp will therefore not return every backfilled line. Production completion of the backfill must be confirmed separately. Refresh previously imported lines once it is confirmed complete.

The backfill reads the lines from ERP, so lines deleted in ERP before it ran are not updated. See the API values for lines not yet updated.

GeneralLedgerBalances​

Deletion tracking​

The GeneralLedgerBalances ETL now tracks balances that ERP removes, for example when Validate account history rebuilds a ledger or when an account in the general ledger preferences is changed. The matching balances are marked with deletedDatabaseRecord: true. Balances that ERP recreates afterwards are restored by the regular synchronization, so only balances that no longer exist in ERP stay deleted.

Existing balances​

A one-time cleanup marks existing balances that no longer exist in ERP as deleted. Each changed document receives a new updatedInDataMartDateTime, so it appears in an incremental fetch. See the API GeneralLedgerBalances section for includeDeleted and the effect on period results.

CustomerPayments and CustomerPaymentLines​

  • Cash-document inclusion is disabled while testing is in progress. For customerPayments and customerPaymentLines, omit includeCashDocumentTypes or set it to false. Using true is not available until testing is complete and the feature is enabled.

ARHistoricalData​

  • AR history is disabled in Production while testing is in progress. The arHistoricalData query and ARHistoricalData type remain documented for reference, but the ETL is not available for Production use.