The financialPeriods query and the FinancialPeriod type are now available, exposing the company's financial calendar:

• Core fields: finPeriodId, startDate, endDate, description, active, year.
• Per-module close flags: closedInGeneralLedger, closedInSupplierLedger, closedInCustomerLedger, closedInInventoryManagement, closedInCashManagement, closedInFixedAssets.

New query: warehouseLocations​

The warehouseLocations query is now available, exposing bin/location records within a warehouse via the WarehouseLocation type:

• Core fields: warehouseId, locationId, locationCd, locationDescription, active.
• Operational flags: inclQtyAvail, isCosted, salesValid, receiptsValid, transfersValid, assemblyValid, primaryItemValid.
• References: primaryItemId, primaryItemClassId, projectId, taskId.

Location.paymentByType is now nullable​

The paymentByType field on the Location type has changed from String! to String:

• paymentByType: String - returns "Due Date" or "Discount Date" for the known ERP values, and null when the ERP holds a value outside that set.

The raw ERP value remains available in the deprecated paymentBy: Int! field. Clients that treated paymentByType as always present should handle a null value.

Schema documentation regenerated​

The published GraphQL schema documentation has been regenerated from the current API schema, so all available queries and types are now documented - including generalLedgerBalancesByPeriod, generalLedgerBalancesV2, salesOrderLinesV2 and the GeneralLedgerBalanceForwardPage type. No behavioural change accompanies the documentation refresh; these endpoints were already served by the API.

The FinancialPeriods collection is now synced from the ERP. Each document describes a period in the company's financial calendar:

• finPeriodId, startDate, endDate, description, active and year.
• Per-module close flags: closedInGeneralLedger, closedInSupplierLedger, closedInCustomerLedger, closedInInventoryManagement, closedInCashManagement and closedInFixedAssets.

The collection supports deletion tracking and reconciliation (deletedDatabaseRecord).

New ETL: Warehouse Locations​

The WarehouseLocations collection is now synced from the ERP. Each document represents a bin/location within a warehouse:

• warehouseId, locationId, locationCd, locationDescription and active.
• Operational flags: inclQtyAvail, isCosted, salesValid, receiptsValid, transfersValid, assemblyValid and primaryItemValid.
• References: primaryItemId, primaryItemClassId, projectId and taskId.

The collection supports deletion tracking and reconciliation (deletedDatabaseRecord).

The Budget type has been updated so that its GraphQL key matches the full GLBudgetLine primary key:

• branchId, ledgerId and financialYear are now marked as part of the key (@partOfKey).
• A new non-nullable field parentGroupId: String! has been added and is also part of the key.

This aligns the schema with the underlying ETL collection, which has been reimported with the same composite key. Clients querying the Budget type should add parentGroupId to their selection sets where the parent budget line is relevant.

deletedDatabaseRecord and includeDeleted re-added for Budgets​

Following the enablement of deletion tracking and reconciliation for the Budgets collection:

• The deletedDatabaseRecord: Boolean! field is back on the Budget type.
• The budgets query exposes the includeDeleted: Boolean! = false argument again. Soft-deleted budgets are excluded by default; pass includeDeleted: true to include them.

Both were removed earlier, when Budgets did not yet support soft-deletion. They now behave the same way as other soft-deletion-aware entities (Accounts, CustomerDocuments, etc.).

New includeUnreleased argument on budgets query​

The ETL upsert pipeline now stores both released and unreleased GLBudgetLine rows. To preserve the historical default (released only), the budgets query exposes a new includeUnreleased: Boolean! = false argument:

• budgets (no argument) - only budgets with released = true are returned, matching the previous behaviour.
• budgets(includeUnreleased: true) - both released and unreleased budgets are returned.

Combine with includeDeleted as needed.

Documentation clarifications​

Schema descriptions have been reviewed and tightened:

• includeDeleted argument descriptions across queries (accounts, apInvoices/supplierDocuments, apPayments/supplierPayments, apInvoiceLines/supplierDocumentLines, apPaymentLines/supplierPaymentLines, customerPayments, customerPaymentLines, customerDocuments, customerDocumentLines, customers, subaccounts, addresses, contacts, countries, salesOrders, salesOrderLines/salesOrderLinesV2, suppliers) are now consistent with the canonical wording used by the API server.
• The budgets query argument descriptions follow the same canonical wording.
• The type-level descriptions on APInvoice, APInvoiceLine, APPayment, SupplierPaymentLine, Address, Country and Location have been reverted to indicate that deletion detection is still in development for these entities. The deletedDatabaseRecord field on these types should not be relied on as a deletion signal yet.

No behavioural changes; only schema descriptions are affected.

The Budgets collection has been updated to use the full GLBudgetLine composite key (companyId, branchId, ledgerId, financialYear, groupId, parentGroupId). Sibling budget lines that share a groupId but differ in parentGroupId were previously collapsed under a single document, causing related rows to be lost.

As part of this change, the Budgets collection will be reimported in full. Existing documents will be replaced; no manual action is required from integrators.

The upsert pipeline also no longer filters on Released = 1, so unreleased budget lines are now tracked. This is a prerequisite for the deletion tracking change below.

Deletion tracking and reconciliation enabled for Budgets​

Deletion tracking is now available for the Budgets collection. GLBudgetLine deletions in the ERP are picked up via ChangeNotifications and the matching Budget document is soft-deleted (deletedDatabaseRecord = true).

Reconciliation has also been enabled for Budgets: the periodic sweep now matches MongoDB Budget documents against GLBudgetLine rows using the full composite key (BranchID, LedgerID, FinYear, GroupID, ParentGroupID) and soft-deletes any orphaned documents missed by the notification pipeline.

• Deletion tracking is now available for all collections except Budgets, GeneralLedgerBalances, and JournalTransactions. The API exposes an includeDeleted filter so integrations can choose whether soft-deleted records are included in query results.

• Reconciliation has been run for all collections that support deletion tracking, marking existing DataMart documents as deleted where the corresponding ERP records were deleted. These collections are now up to date.

includeDeleted argument removed from selected queries​

The includeDeleted argument has been removed from the queries listed below. For these entities the underlying deletedDatabaseRecord field is not populated, so the argument had no effect - it was previously documented as Not active yet for budgets and journalTransactions, and as deprecated for the GL balance queries. It has now been dropped from the schema entirely.

• budgets
• journalTransactions
• generalLedgerBalances
• generalLedgerBalancesV2
• generalLedgerBalancesByPeriod
• generalLedgerBalancesForwardByGroup
• generalLedgerBalancesForwardExpanded

Existing clients that passed includeDeleted to any of these queries should remove the argument. Behavior is unchanged: results have always been returned regardless of the value passed.

Removed Fields​

deletedDatabaseRecord removed from selected types​

The deletedDatabaseRecord: Boolean! field has been removed from the following types because it is not populated for these entities:

• Budget
• GeneralLedgerBalance (was previously marked deprecated for the same reason)
• JournalTransaction

Clients that selected this field in queries against these types must remove it from their selection set.

Documentation Clarifications​

deletedDatabaseRecord marked as Not active yet on remaining types​

The deletedDatabaseRecord field has been annotated as Not active yet on every object type that still exposes it, with the exception of SOLine and SalesOrderLine where the field is populated. The field remains in the schema for forward compatibility, but does not yet reflect the actual soft-deletion state for the affected types.

deferralScheduleNbr on invoice line types​

A new optional deferralScheduleNbr: String field is exposed on the following types. It carries the deferral schedule's business number, separate from the existing deferralSchedule (description) and deferredCode (code) values.

• APInvoiceLine
• SupplierDocumentLine

Removed Deprecations​

deferredCode is no longer deprecated​

The deferredCode field on APInvoiceLine and SupplierDocumentLine is no longer marked as deprecated. The previous deprecation hint pointing to deferralSchedule has been removed because deferredCode, deferralSchedule, and the new deferralScheduleNbr now represent three distinct values (code, description, and business number) and are all populated independently.

SupplierDocumentLine / APInvoiceLine​

Data Quality Improvements​

• Deferral schedule values on supplier document lines are now split across three independent fields - DeferredCode (code), DeferralSchedule (description), and the new DeferralScheduleNbr (business number). Previously the description and code were conflated and the business number was not surfaced. DeferredCode is no longer deprecated.
• Legacy deferralSchedule values stored as non-string types in MongoDB are now read through a lenient BSON serializer, so historical documents continue to deserialize after the field's semantics changed.

Operational Updates​

• The patch initiation HTTP trigger now returns a confirmation body - Patch '{patchName}' started successfully. Instance ID: {instanceId}. - alongside the existing 202 Accepted response, making it easier for callers to correlate the kicked-off run.

includeDeleted parameter added to additional queries​

Not active yet.

The includeDeleted argument (Boolean! = false) is now available on the following queries. When false (the default), soft-deleted records (deletedDatabaseRecord = true) are excluded from results. Pass includeDeleted: true to include them.

• accounts
• addresses
• apInvoiceLines
• apPaymentLines
• branches
• budgets
• countries
• customers
• customerDocuments
• customerDocumentLines
• customerPaymentLines
• journalTransactions
• locations
• paymentMethods
• projectTasks
• salesOrders
• salesPersons
• salesPrices
• states
• supplierDocumentLines
• supplierPaymentLines
• suppliers
• terms
• vatCategories
• vatZones
• warehouses

New Fields​

The deletedDatabaseRecord: Boolean! field is now exposed on the following types, letting callers identify records that have been soft-deleted by the ETL's deletion-tracking or reconciliation flows:

• Address
• Budget
• Country
• CustomerDocumentLine
• JournalTransaction
• Location
• ProjectTask
• SalesOrder
• SalesPerson
• SalesPrice
• State
• Terms
• VatCategory
• VatZone
• Warehouse

Deprecations​

includeDeleted argument on GL balance queries​

Not active yet.

The includeDeleted argument is deprecated on the following queries because deletedDatabaseRecord is not currently populated for general ledger balances; passing the argument has no effect.

• generalLedgerBalances
• generalLedgerBalancesV2
• generalLedgerBalancesForwardByGroup
• generalLedgerBalancesForwardExpanded
• generalLedgerBalancesByPeriod

GeneralLedgerBalance.deletedDatabaseRecord field​

The deletedDatabaseRecord field on the GeneralLedgerBalance type is marked deprecated for the same reason. The field is included in the schema for type-consistency with other soft-delete-aware entities, but it is not populated for GL balances.

All ETLs now enabled in production​

All available ETL processes are now enabled in production. Previously disabled ETLs can now be activated through the provisioning API.

Clearer error when activating a non-existent company​

Calling activateEtl or deactivateEtl for a company that does not exist in ERP now returns a structured NOT_FOUND error with the message "Company {id} does not exist in ERP." instead of a generic INTERNAL_SERVER_ERROR.

• Customer payments with document type DRM (Debit Note) are now correctly processed. Previously, these records caused a mapping error during the ETL transform step and were not synced to MongoDB.

Operational Updates​

• All available ETL entities are now enabled in production, including Insert, Upsert, and Corrector flows for every implemented entity.

CustomerDocumentLine​

GeneralLedgerBalance​

CustomerDocumentLine​

GeneralLedgerBalance​

Data Quality Improvements​

• Normal corrector runs now start from the older checkpoint inside the safety window, reducing the risk of missed updates while keeping full rescans limited to explicit override runs.

Experimental GL balance queries​

The generalLedgerBalanceExperimentalForwardPeriodsByGroup and generalLedgerBalanceExperimentalForwardPeriodsExpanded queries now accept an optional periodsUpTo parameter.

Breaking Changes​

Page size limit reduced for experimental GL balance queries​

The maximum and default pageSize for both generalLedgerBalanceExperimentalForwardPeriodsByGroup and generalLedgerBalanceExperimentalForwardPeriodsExpanded has been lowered from 5 000 to 100. Requests that previously used a pageSize above 100 will now receive a validation error. The error message now dynamically reports the applicable limit.

updatedInDataMart filter field corrected​

The underlying database filter for the updatedInDataMart parameter on experimental GL balance queries was pointing to an incorrect field. It now correctly filters on updatedInDataMartDateTime. If you were relying on this filter and observed unexpected results, the behaviour is now corrected.

• generalLedgerBalancesForwardByGroup - Forward-period expansion paginated by group. Each affected (branchId, accountId, subaccountId) group is expanded with virtual monthly periods up to the current month. Use lastGroupKey for cursor-based pagination. Marked as EXPERIMENTAL.
• generalLedgerBalancesForwardExpanded - Forward-period expansion with overflow. pageSize controls approximate source documents processed; response may exceed pageSize due to virtual period expansion. Use lastGroupKey for cursor-based pagination. Marked as EXPERIMENTAL.

Improvements​

• Response compression - API responses now support Brotli (Optimal) and Gzip (Fastest) compression. Clients sending Accept-Encoding: br or Accept-Encoding: gzip will receive compressed responses, including GraphQL payloads.
• Request-Id header - Every response now includes a Request-Id header containing the OpenTelemetry trace ID, making it easier to correlate API calls with backend traces for debugging.
• @partOfKey directive introspection - The @partOfKey directive is now visible via GraphQL introspection, allowing clients to programmatically discover which fields form part of an entity's key.

SalesOrderLines​

SupplierDocumentLines​

SupplierPaymentLines​

Renamed Fields​

SalesOrderLines​

Old names remain available but are marked [Obsolete] and will be removed in a future release.

Data Quality Improvements​

• Added corrector flow for all 32 ETL entities, ensuring near-real-time updates that were previously missed due to SQL Server rowversion race conditions are now automatically caught and corrected using LastModifiedDateTime-based lookback.
• The @partOfKey GraphQL directive and (PK) markers are now present on all primary key fields across all entities, making it clear which fields uniquely identify a document.
• Added companyId + rowVersion compound index to all MongoDB collections for improved query performance.

Bug Fixes​

• CustomerDocument no longer produces duplicate documents. branchId and customerId were incorrectly included in the primary key, causing the same document to appear multiple times. The PK is now CompanyId + DocumentType + ReferenceNumber.
• CustomerDocumentLine and Warehouse SQL join mismatch between COUNT and UPSERT queries has been fixed, ensuring accurate row counts.

Deprecations​

• SupplierDocumentLines.DeferredCode - Deprecated in favor of DeferralSchedule. The DeferredCode field still exists and is populated, but will be removed in a future release.
• SalesOrderLines - 16 fields have been renamed (see Renamed Fields above). The old field names still exist and are populated, but are marked [Obsolete] and will be removed in a future release.