Release Notes

Version releases

We are constantly adding new features to Procountor API. This page has the planned changes in future releases as well as release notes for the current ones. For anyone interested, we recommend subscribing to our mailing list to get notifications about API changes as soon as they become available.

Subscribe to our mailing list

Currently available API versions

You can find the version update schedule from Procountor news and announcements site.

Release notes

Changes highlighted in red are not backwards compatible

Changes in version 21.04

The legacy authentication method has been removed from production.

Endpoints

• We are introducing new GET /company/invoicecirculation/settings endpoint, which returns the company specific invoice circulation settings including default verifiers and acceptors.
• We are introducing new GET /company/invoicecirculation/verifierlists endpoint, which returns basic data from all the invoice verifier lists configured in the company environment.
• We are introducing new GET /company/invoicecirculation/verifierlists/{id} endpoint, which returns verifiers and acceptors connected to a specific verifier list.

• POST /invoices and PUT /invoices/{id} now return correct error when trying to create or update an invoice with cash discounts in an environment which does not allow using cash discounts.

• We are changing the pagination in GET /products endpoint to be in line with other endpoints supporting pagination. With this change the results are now returned in results object instead of products object, the maximum number of returned products is now controlled with size query parameter instead of limit query parameter, and meta object containing pagination related information is now returned with the results. We have also added orderById query parameter to control the order of the returned items.

Changes in version 21.03

The legacy authentication method has been removed from the API public test server.

Endpoints

• Missing currency codes, e.g. CNH, have been added to GET /bankaccounts and other API endpoints returning currency code information.
• GET /bankstatements results can now be filtered by bank account number using accountNumber query parameter. This filter uses exact matching.
• POST /invoices and PUT ​/invoices​/{invoiceId} endpoints will now replace all line breaks (\n or \r) with spaces in address fields like counterPartyAddress, billingAddress and deliveryAddress. This prevents invoices being caught in an error because of forbidden characters.
• GET /products results can now be filtered by product code using code query parameter. This filter uses substring matching.

Other

• Issues some customers have faced on the public API test server with endpoints requiring two-factor authentication have been fixed.

Changes in version 21.02

All refresh tokens more than 6 months old expire with this release. This means that if your integration is relying on login performed more than six months ago relogin is required to continue accessing the API. All refresh tokens issued since August 2020 have inbuilt 6 month expiration period. Any integrations relying on refresh tokens for persistent access should switch over to M2M authentication with Client Credentials.

We have adjusted our API release cycle. These changes do not require actions from API users. From here on out the supported versions will be released a month after the same changes have been introduced in latest and numbered versions. This means that the version 21.02 released now will be available on the numbered /v2102 path, but will be updated to /supported path in the next version release in March.

Endpoints

• PATCH /businesspartners/{id} no longer requires einvoiceAddress or einvoiceOperator if there are no changes to these fields.

• You are now able to mark SALES_ORDERS as offers using the isOffer field with POST /invoices and PUT /invoices/{id} endpoints.
• You can now send purchase invoices to circulation using PUT /invoices/{id}/sendToCirculation endpoint.

• You are now able to request automatic reconciliation for journal receipts using createReconciliation=true query parameter with POST /ledgerreceipts and PUT /ledgerreceipts/{id}. This functionality matches the functionality in the UI by creating/modifying the reconciliation entry row in the ledger receipt in order to make the ledger sum to zero. This row can overwrite any already existing reconciliation entry row.

• It is now possible to choose charging fees for all foreign payments with all currencies when using POST /payments and POST ​/payments​/directbanktransfers endpoints. Information about the charging fee is stored in the serviceCharge field, and is also returned by GET /payments/{paymentId} from the value of serviceCharge.
• Trying to set a payment due date with POST /payments or POST /payments/directbanktransfers to a Danish bank holiday when using Arbejdernes Landsbank (BIC: ALBADKKK), will result in a 400 Bad Request response with message DATE_MUST_BE_WORKING_DAY. This is because AL bank doesn't accept payments on bank holidays.

Changes in version 21.01

Endpoints

• A withdrawal/deposit sum calculation issue with GET /bankstatements has been fixed.

• POST /invoices and PUT /invoices/{id} now allow you to specify the approvers and verifiers for a purchase and travel invoices. Approvers and verifiers must have the correct user rights to be able to approve or verify the invoices.
  If approvers and verifiers are not given, the defaults for the environment or business partner are used. If you want the invoice not to have any approvers or verifiers then you need to supply an empty object {} as invoiceApprovalInfo when making the POST or PUT request.

Changes in version 20.12

Endpoints

• PUT /bankstatements/{id}/events/{eventId}/metadata - A new endpoint for adding bank statement metadata. The metadata contains accounting data including ledger account, sum, and VAT percentage and status.
  The same metadata model is also used with reference payments in PUT /referencepayments/{id}/metadata endpoint. This means that the two new optional fields, ledgerAccount and vatStatus, are usable with reference payment metadata as well. Reference payments only allow sales type vatStatus.
  The metadata is returned by GET /bankstatements and GET /referencepayments endpoints.
  Note that reflecting the metadata to ledger receipts requires using the "Update accounting" functionality available in the bank statement and reference payment UIs.
• DELETE /bankstatements/{id}/events/{eventId}/metadata - A new endpoint for removing bank statement metadata.

• GET /businesspartners/{ids}, GET /invoices/{ids}, and GET /ledgerreceipts/{ids} now allow fetching up to 200 resources at a time by specifying a comma separated list of IDs in the request URL.
  When multiple resources are requested the result will contain a list of resources, regardless of how many resources are actually being returned. This list does not contain duplicates. The items in the result list are not guaranteed to be in the same order than in the request. When only a single ID is specified the return model is the same than in previous versions.
  Only resources with valid IDs are returned. If all given IDs are invalid 404 response is returned. As long as the list of IDs contains at least one valid ID the request won't return an error.

• POST /invoices and PUT /invoices/{id} endpoints now allow creating and modifying sales and purchase orders.
• PUT /invoices/{id} now properly updates the accompanying accounting ledger when the invoice contents are modified. Note that modifying the invoice might cause the accounting ledger to be recreated. In this cases a new ledgerReceiptId is returned with the invoice.

• GET /ledgerreceipts - It is now possible to filter the results using the status field.
• PUT /ledgerreceipts/{id}/approve - A new endpoint for approving journal receipts. A journal receipt can be approved if its status is UNFINSHED and the fiscal year it's in has not been closed.

• The following deprecated id fields have been removed.

### Changes in version 20.11 (supported) - **`PATCH /attachments/{id}`** - A new endpoint, which allows renaming the attachment file. The attachment file extension can not be changed. - **`GET /invoices`** can now be used to search sales and purchase orders as well as invoices. - **`GET /invoices/{id}/transactions`** - A new endpoint for fetching the invoice transaction information for a specified invoice. - **`POST /invoices`** and **`PUT /invoices/{id}`** now allow invoices to have empty billing or delivery address. To create an invoice without billing or delivery address an empty object `{}` needs to be supplied for the intended address. If billing or delivery address is left out of the request body, or given as `null`, then the existing behavior of copying the counterparty address for billing or delivery address still holds. ### Changes in version 20.10 #### Endpoints - - - Fields `name`, `type` and `version` are no longer mandatory in **`PATCH /businesspartners/{id}`** request body. The `version` field is still required, but can be given either as a query parameter or in the request body. - Validations in **`PATCH /businesspartners/{id}`** have been updated to match validations in other businesspartners endpoints. - EDI identifier field `ediId` has been added to the `einvoiceAddress` structure used in **`GET /invoices/{id}`**, **`POST /invoices`** and **`PUT /invoices/{id}`** endpoints. This optional field is used with Finnish environments. - ### Changes in version 20.09 We have added OAuth 2.0 Client Credentials flow to our API authentication. This authentication method is especially suitable for machine-to-machine integrations where the user is not actively involved during the API transactions. You can read more about this authentication method from the [M2M authentication page]({filename}22-m2m-authentication.md). The Client Credentials flow is usable with all API versions. ### Changes in version 20.08 (supported) The format of Procountor API access tokens and refresh tokens has been changed to JWT. _**This change affects all API versions.**_ All new access and refresh tokens will be issued in JWT format. The old format refresh tokens will continue to function normally until their specific expiration dates. _**The size of the tokens is up to 512 bytes for access tokens and up to 1024 bytes for refresh tokens.**_ The JWT tokens encode additional information, including user, audience, and expiration date. Detailed information of the tokens' contents is available on the [API authentication page]({filename}21-api-authentication.md#authentication%20tokens_1). ### Changes in version 20.06 #### Endpoints - - - ### Changes in version 20.05 #### Endpoints - - - - - **`GET /users/rights`** - A new endpoint for getting access rights for the currently logged in user #### Other - - The following id fields can now be found with new names. The old fields have been marked as deprecated and will be removed in the future.

Model / Schema	New field	Removed field
BasicPaymentTransactionData	`id`	`paymentId`
BusinessPartnerBasicInfo	`id`	`registerId`
FactoringContract	`id`	`contractId`
LedgerReceipt	`id`	`receiptId`
LedgerReceiptBasicInfo	`id`	`receiptId`
PaymentEvent	`id`	`paymentEventId`
PaymentRowInfo	`id`	`paymentId`
PersonalDetails	`partnerId`	`personId`
Transaction	`id`	`transactionId`
User	`id` `partnerId`	`userId` `personRegisterId`

Model / Schema	New field	Old field
BasicPaymentTransactionData	`id`	`paymentId`
BusinessPartnerBasicInfo	`id`	`registerId`
FactoringContract	`id`	`contractId`
LedgerReceipt	`id`	`receiptId`
LedgerReceiptBasicInfo	`id`	`receiptId`
PaymentEvent	`id`	`paymentEventId`
PaymentRowInfo	`id`	`paymentId`
PersonalDetails	`partnerId`	`personId`
Transaction	`id`	`transactionId`
User	`id` `partnerId`	`userId` `personRegisterId`

- Number of previously generalized error conditions now return more specific error codes and messages. - Errors caused by failing validation rules have been clarified. ### Changes in version 20.04 (supported) #### Endpoints - **`GET /businesspartners/{id}/defaults/products`** - A new endpoint for getting the default products for a given business partner. - **`GET /businesspartners/{id}/defaults/accounts`** - A new endpoint for getting the default accounts for a given business partner. - **`POST /businesspartners`** endpoint has been extended to support all fields except `id`, `attachments` and `version`. - E-Invoice addresses given to business partners using **`POST /businesspartners`** or **`PUT /businesspartners/{id}`** endpoint are now validated against used environment and country. ### Changes in version 20.03 #### Endpoints - **`PUT /invoices`** - A new endpoint for modifying existing invoices. The invoice type, status or attachments cannot be modified using this endpoint. - **`PUT /invoices/{invoiceId}/notes`** - A new endpoint for modifying the internal notes of an invoice. - - - - **`POST /payments`** - A new field has been added `bankReferenceCodeType`. If present, the information in this optional field is used to validate the value given in the `bankReferenceCode` field. - **`POST /payments/directbanktransfers`** - A new field has been added to the endpoint: `bankReferenceCodeType`. If present, the information in this optional field is used to validate the value given in the `bankReferenceCode` field. - **`POST /payments/directsalarypayments`** - A new field has been added: `bankReferenceCodeType`. If present, the information in this optional field is used to validate the value given in the `bankReferenceCode` field. - - - Invoice row ordering given to **`POST /invoices`** endpoint is now preserved. - Invoice rows returned by **`GET /invoices/{invoiceId}`** now follow the ordering given using the `POST /invoices` endpoint or in the UI. - **`GET ​/invoices​/{invoiceId}/paymentevents`** now returns description for the payment event. - **`PUT /invoices/{invoiceId}/payments/markpaid`** - It is now possible to mark credit invoices as paid (payments with negative amounts) using this enpoint. #### Other - Marking sales invoices paid using `PUT /invoices//paymentevents/markpaid` no longer requires full rights for "Mark paid elsewhere". Viewing rights suffice just like in the UI. - API error messages have been clarified. ### Changes in version 20.02 #### Endpoints - **`GET /invoices/{invoiceId}/paymentevents/{id}`** - A new endpoint for getting single payment events. - You can now use originalInvoiceNumber to filter results returned by `GET /invoices`. - Invoice rows returned by `GET /invoices/{invoiceId}` now have an unique `id`. -

Field names in `GET /businesspartners` have been changed to match field names in `GET /businesspartners/{id}` as follows: - `code` → `invoicingInfo/identifier` - `codeType` → `invoicingInfo/identifierType` - `customerNo` → `invoicingInfo/customerNumber` - `active` → `registryInfo/active`

#### Other - Performance issues in GET /bankstatemets have been addressed. - Pagination related bug in GET endpoints' metadata has been fixed. - Electronic invoice address validation bug affecting Swedish environments has been fixed. ## Older release notes Older release notes can be found from [their own page]({filename}51-old-release-notes.md). [Old release notes]({filename}51-old-release-notes.md){ .bold-link .padding-bottom }