ExternalCodes for records in Basware API need to meet the following criteria:
- They must retain their value when updating records (else data updates will not work)
- They most not exceed the field max length (else the record will be rejected by Basware API).
Two common ways are 1) using UUIDs and 2) Concatenating the externalCode from other key values, such as SourceSystem_CompanyCode_PONumber_PORowNumber_GRNumber.
The UUIDmethod requires saving this guid to the sending system. The second "composite key" method may make integration debugging more straightforward and requires making sure the combined key does not exceed the max length for externalCode -field.
It's up to the customer implementation what is the best way to create them.
Please refer to the error handling section of Purchase-to-Pay API manual.
Please check the errorFeedbacks API. Note that specific kinds of errors can take some minutes to become available in errorFeedbacks API due to internal retry logic. Try to use GET errorFeedbacks with just daterange search, setting the date to one day before your expected error (in case of timezone differences). If this does not resolve your issue, please contact Basware support.
If you send the exact same record again to API, it will not get updated into P2P as the data in API has not changed, even if the record is still missing from P2P. Try to modify the record slightly and send it again. Then API will send the record again to P2P and other target systems.
There is a setting in P2P admin, settings section called "Delete existing user groups when importing users". This setting needs to be enabled in order to clear existing user groups during import.
No, each bank account on the vendor needs to be unique.
This typically happens for invoices which have already been acknowledged. API allows acknowledging an invoice only once (unless it is retransferred from P2P). Already acknowledged invoices have 'processingStatus' = 'TransferInProgress'.
Please check that you are sending the x-amz-meta-continuationtoken parameter as a request header parameter. It does not work if it is not sent in header (for example in body).
The x-amz-meta-continuationtoken parameter is preconfigured in our Postman templates. Please try it out through postman using the preconfigured template, that should help spot the difference between how it is set up in the request sent by Postman and sending it in your HTTPS request.
The swagger definition should serve you the same way as WSDL. You can download the swagger here https://api.basware.com/p2pOpenApiSwagger/p2popenapi.json and then validate the messages against that. However, there is no json schema or WSDL file currently available.
There is no way at the moment to keep changes made manually to records which are updated through the API. An exception to this is the vendors -interface, where some of the interface fields can be configured so API data does not overwrite existing data in P2p. This functionality to vendors -interface is planned to be released in Q3/2020.
Please find a way to update the data fully in your source system, alternatively you could consider creating a separate maintenance table for particular items - please discuss options for you specific scenario with your Basware consultant.
Yes you can. There are some things which need to be taken into account. The most important thing is to update user externalCodes in P2P to have same externalCode values that will be sent for each user through users API. This will enable users API to correcly identify existing users for update instead of creating new users instead. It is important to update existing users instead of creating new ones so the users preserve access to invoices they have processed and invoices they currently have in circulation.
User externalCodes can be updated either manually through the user administration -module in P2P or automatically with more direct access to the system. Basware consultants and delivery partners can update the externalCodes directly in P2P. Note that when importing users through API, the user will be available for a GET operation in users API only after the user has been POSTed to users API.
Please test this procedure in test environment to verify all the details are correctly in place before applying the same in a production environment.
You should create one or more applicationGroup(s). Application groups provide log-in access to applications when assigned to users.
Creating applicationGroup(s) can be done by a one-time POST applicationGroups -operation. The easiest way to do that is to use the preconfigured API call for POSTing applicationGroups. After the application group(s) are created, POST user(s) while specifying their assigned applicationGroup(s). See related P2P API manual article for more information.
Example message returned from users API in this situation:
{
"requestId": "e3361d63-bc8a-44a4-91f7-1ec4be706074",
"hasErrors": true,
"errors": [
{
"type": "VALIDATION",
"code": "SCHEMA_VALIDATION_ERROR",
"message": "The default application group does not exists for customer 123456"
}
]
}
Handling supplier additional data fields (imported in vendors API 'customFields' block) in P2P is controlled by parameter 'DeleteAdditionalDataDuringSupplierImport' (in CMN_TENANT_SETTINGS in P2P).
When true, all existing values for supplier additional data fields are cleared before supplier is imported. When false, existing values are kept which can result in duplicate additional data -entries.
Most likely case is the parameter has incorrect value for your use case. Please check the parameter value and set it to 'true'.
This is an unsupported use case. The invoice needs to be present in accountingDocuments API for the responses to be updated to P2P. You will need to send the response information back through the same channel as was used for originally transferring the invoice.
This typically occurs when GETting data from APIs that use redirects to allow large data payloads (accountingDocuments, exportedPurchaseOrders, etc) and the redirected request includes extra HTTP headers. For the redirected call, the 'Authorization' HTTP header must not be sent. The redirected call is using secure signed URLs with short expiration time.
In Postman this is controlled by a setting called "Follow Authorization Header", having default value false. Sometimes this header is copied from the original request by integration software used. Please adjust the settings of your integration software to not send this header on the redirected request.
There are the following options:
You can, but this is not recommended as these are used as parts of an URL in the API's GET operations. If you would need to use these special characters they will need to be URL encoded whenever they are used as parts of a URL or used in query parameters.
Q: I got the above error message when posting users. How should I resolve this?
This error is due to the company on which you're importing the user not being marked as an administrative site in P2P. Make sure the the company to which you are posting the user is marked as an administrative site in P2P. When it is not, users cannot be imported to the company. We have logged an enhancement to return a clear error message also in this situation.
- Basic authentication over HTTPS
- OAUTH2 (client credentials flow).
See Basware P2P API manual ('Authentication' -section) for more details.
Basware network APIs support basic authentication over HTTPS.
Status 'NotProcessed' commonly occurs due to delta check. If the record contents has not changed since last time it was posted, API skips the record (as is nothing to update) instead of sending it to target systems. Below is an example requestStatus response JSON where this has occurred.
