Delivery Notes Integrations
Electronic delivery notes and Remittances are primarily for suppliers to provide their customers with electronic delivery notes and remittances, and easy stock in.
Purpose of this guide is to ease the integration of a supplier's system with the Dotykacka platform. The customers can then benefit from a smooth cooperation between the two systems which will save their time otherwise consumed by updating products and stock quantities in a delivery note manually item-by-item.
Should you have any questions or issues with the integration do not hesitate to ask us via e-mail [email protected]
- 1.The supplier prepares the delivery note XML and uploads it via the API2 (steps to setup and invoke the API2 are described in this guide).
- 2.When the XML document is uploaded, it will show up in the customer's Warehouse application.
- 3.From there, optionally, the customer can alter selling prices and quantities before confirming to stock in the items.
- 4.When confirmed, the application will automatically update product prices and quantities of stock items in the customer's warehouse and it will also set the delivery note status to Stacked.
- We will provide you a Client ID and Client Secret, and a testing license key.
The steps in this section are very simplified to help you to experiment with the API as quickly as possible but should not be used in production.
- For testing, create a new Dotypos Account with the provided testing license key.
- Prepare the connector URL (replace variables
{}
with client ID and secret):https://admin.dotykacka.cz/client/connect?client_id={client_id}&client_secret={client_secret}&scope=*&redirect_uri=https://dotykacka.cz
- Open the URL in a browser and grant access to your testing cloud.
- Note down the Refresh Token returned in the URL after you get redirected to dotykacka.cz(redirect URL:
https://dotykacka.cz?token={RefreshToken}&cloudid={cloudId}
)
Here are some hints to make your application better prepared for the production.
- Your application should generate the connector URL query parameters and use the full URL to redirect users automatically.
- The
redirect_uri
in the connector URL should be an URL of your webhook that will process the response. - The Refresh Token should be stored safely in your application (never expires).
- send API request
POST https://test.api.dotykacka.cz/v2/signin/token
- with header:
Authorization: User {RefreshToken}
- and header:
Content-Type: application/json
- and JSON body:
{ "_cloudId": {cloudId} }
- parse the response body (JSON) so as to get the value for the key "
accessToken
"
- is valid for a limited time only and when it expires, it must be renewed via this endpoint again.
- allows access only to the Cloud ID specified in the body of the request that returned it.
- must be specified when calling any other API v2 endpoint in the headers:
Authorization: Bearer {AccessToken}
During the development stage of your integration code you can call the following endpoint to check you have the right access token with access to the given cloud:
GET https://api.dotykacka.cz/v2/clouds/{cloudId}
Do not forget to add the request header
Authorization: Bearer {AccessToken}
If it responds with http status 200 and a cloud info in the body, then you are prepared and ready to call other endpoints.
It is not needed to check the access in production code so we recommend skipping this step for a better performance of your integration code.
We recommend reading the General section in this documentation for more details that apply to most of the entity endpoints.
You can upload a delivery note in a XML format by using the API call.
The XML document (structure described here) must be a valid XSD file and according to the mentioned validations. Put it as a value for the key named
file
in a form-data request body.Call:
POST /v2/clouds/{cloudId}/branches/{branchId}/delivery-note-uploads
In case the XML file is not accepted, please make sure it is valid according to the XSD.
You can manage, filter and sort products by using the API calls.
When updating multiple entities, keep the same order in the PUT request as it was in the GET response that returned the ETag.
For endpoints working with a list of entities (POST/PUT), the order of entities in the response is the same as it was sent in the request .
The POST method does not expect an ID so it always creates new products.
The PUT method requires an ID so you need to generate one when you want to create a product using the PUT method.
The JSON samples labeled "Body request minimum" under the POST and PUT requests show the minimum set of fields that are required to create a new product.
When changing an entity via the PATCH endpoint, you can send only the fields that you want to update, f.e. to change the product name send body
{"name": "New name"}
.
Last modified 3mo ago