- Change: The
comments
field length has been reduced from 65536 characters to 250. - Reason: This change was implemented to mitigate performance impact risks if large volumes are added.
- Solution: Ensure during the creation and modification of products that the length of comment values does not exceed 250 characters. Replace overly lengthy content with a hyperlink that leads to a page displaying detailed comments.
Breaking Changes
Why breaking changes ?
At Sage Active, we strive to maintain backward compatibility to ensure a seamless experience for our users.
Most changes to our API are designed to be non-disruptive and are implemented in a way that preserves existing functionality.
However, there are exceptions where, in the best interest of the product and its users, breaking compatibility is necessary.
In such cases, maintaining an element that could negatively impact performance, security, or usability would be detrimental to the overall user experience and the product’s evolution.
Therefore, when a breaking change is unavoidable, it is made with careful consideration of its necessity and potential benefits, aiming to minimize disruption and provide clear migration paths for all affected users.
Here is a list of recent breaking changes that you may need to adapt to:
-
Resource: Purchase Invoices
January version
- Change: Fields
xxxx
changed type fromInt
toDecimal
. - Reason: The January version of Sage Active introduces the ability to handle quantities with decimals in sales documents.
This results in technical breaking changes as quantities now shift fromInt
toDecimal
. However, this does not impact existing developments becauseDecimal
supportsInt
. - Solution: No modifications are required, as compatibility is maintained.
- Change: Fields
-
Resource: Purchase Invoices
December version
- Change: The input field
taxGroupId
was removed from the input object typePurchaseInvoiceLineCreateGLDtoInput
. - Reason: The API schema has been updated to simplify the handling of tax groups, ensuring a more streamlined and consistent data structure for purchase invoice lines.
- Solution: Remove any references to the
taxGroupId
field in your Purchase Invoices mutations.
- Change: The input field
-
Resource: Purchase Invoices
November version
- Change: The input field
lines
was removed from the input object typePurchaseInvoiceCreateGLDtoInput
. The input fieldvatLines
of type[PurchaseInvoiceLineCreateGLDtoInput!]!
was added instead. - Reason: The structure of the purchase invoice creation process has been improved to better handle VAT lines separately, providing more clarity and precision in the data model.
- Solution: Update your queries and mutations by replacing references to the
lines
input field with the newvatLines
input field.
- Change: The input field
-
Resource: Organizations
October version
- Change: The
status
field of organizations is no longer relevant and should not be used to check the status of organizations. - Reason: Access permission management for an organization now depends on business management, which allows, for example, the termination of a business’s use. Additionally, the
status
field always returns the valueREADY
, making it meaningless for determining an organization’s status. - Solution: Either remove the
status
field if it was referenced in queries onorganization
, or, if kept, ensure that its returned value is no longer taken into account.
- Change: The
-
Resource: SalesInvoice Post Sales Invoice, Sales Open Items settlement
October version
- Change: The
Id
field in response use by PostSalesInvoice service and SalesOpentItemSettlment service is removed and change byaccountingEntryId
. - Reason:
accountingEntryId
indicates that it is the ID of the accountingEntry and not Id of SalesInvoice. - Solution: Simply replace the
Id
field by theaccountingEntryId
field when it was referenced in actions onPostSalesInvoice
orSalesOpenItemSettlement
.
- Change: The
-
Resource: Userprofile
September version
- Change: The
expirationDate
field is removed fromuserprofile
. - Reason: Access permission management for users now depends on business management, which allows, for example, managing the role of a user.
- Solution: Simply remove the
expirationDate
field if it is referenced in queries onuserprofile
.
- Change: The
-
Resource: Product
May version
-
Resource: sales Documents
May version
- Change: The
mainAddress
anddeliveryAddress
for salesDocuments were previously exposed as arrays. Now, they are presented in a simple format. - Reason: These objects contained only one element, and simplifying their structure facilitates filtering, such as retrieving sales quotes from clients in Brussels.
- Solution: When retrieving data, remove the index [0].
For example, usesalesQuoteNode.mainAddress
instead ofsalesQuoteNode.mainAddress[0]
.
- Change: The
-
Resource: sales Documents
May version
- Change: The
id
field has been removed frommainAddress
anddeliveryAddress
in salesDocuments because it contained a non-significant value. - Reason: This change was made to streamline the data structure, as the
id
was not providing useful information. - Solution: Remove the
id
field from queries involvingmainAddress
anddeliveryAddress
.
- Change: The
-
Resources: Customer, Supplier
May Version
- Change: The
defaultAccountingAccountId
field inCustomers
andSuppliers
is no longer filterable or sortable. - Reason: The introduction of dataloaders has currently prevented filtering on this field, which was possible in previous versions. A solution is being studied for a future version.
- Solution: Remove the filter or sort from the query and perform local filtering on the response data.
- Change: The
-
Resource: All Resources
May version
- Change: In the syntax of queries using fragments, the DTO used to qualify fragment fields is no longer compatible due to the transition to data loaders.
- Reason: This update is part of a move to simplify query writing and to enhance performance with the use of data loaders.
- Solution: Replace the DTO name in the fragment syntax with the name of the resource in singular form, starting with a capital letter.
Example for a queryusers
,fragment UserProps on UserGLDto
becomesfragment UserProps on User
.
-
Resource: Other removed fields
May version
- Changes: All of these fields are
salesQuotes
->action
salesOrders
->action
salesDeliveryNotes
->action
salesInvoices
->action
salesTariffs
->calculationBase
suppliers
/thirdCollectorName
paymentMeans
->inactive
paymentMeans
->paymentMethodId
paymentMeans
->paymentMethodReferenceName
organizations
->isDefaultDeliveryAddress
organizations
->isDeliveryAddress
organizations
->isMainAddress
zipcode
->code
- Reason: These fields were historically present but became inconsistent with the developments in Sage Active. They have been removed to avoid the implication that they may contain incoherent data.
- Solution: Remove these fields from queries and modify the code responsible for retrieving data from the affected queries.
- Changes: All of these fields are
-
Resource: userProfile
April version
- Change: The
activeOrganizationId
field no longer returns the current user’s active organization in Sage Active, but instead returns the first organization assigned to the user. - Reason: The information returned was no longer relevant, leading to its removal from the documentation, though the field still exists to prevent query errors.
- Solution: Manage the current user’s organization in a local cache to retrieve it upon the user’s next login.
- Change: The