Knowledge base in Developers Visma.net

In certain instances, users may encounter a specific error message when sending request via the API: {   "ExceptionType": "IPPException",   "ExceptionMessage": "No license for this company.",   "ExceptionFaultCode": "12027",   "ExceptionMessageID": "12027_6e2a06a8-76d8-4e9a-bce8-a5818d60a388",   "ExceptionDetails": "" } Follow these steps to troubleshoot this error:   Using the Interactive authentication without the API user role Make sure that the user has the correct role assigned. [Needs to be checked by Customer in Admin]     Ensure to verify that the customer sends the TenantID to their company and not the customer The tenantID provided to the ISV/Application is the end customers “Customer TenantID” (The customer contract which holds the license for all companies) and not the specific companies tenantID. [Needs to be checked by Customer(with “integration administrator” role) in Visma App Store] TenantID for Company in Visma App Store. For further information regarding Tenant ID provisioning and integration processes, please read the documentation available on the Visma Developer Portal and the start-up guide: Developer Portal Startup-Guide  3. The license for Visma.Net Financials has expired [Needs to be checked by Visma]

Visma.Net Integrations - API Client Configuration In this document we will go through what needs to be done after you completed your Visma.Net Integration certification.  Redirect_URI The first thing you need to do to configure your API client is to set up a redirect_URI.  Redirect URIs are a critical part of the OAuth flow. After a user successfully authorizes an application, the authorization server will redirect the user back to the application with an authorization code in the URL. Because the URL will contain sensitive information, it is critical that the service doesn’t redirect the user to arbitrary locations.    Due to this, it is required to specify one or more redirect URIs when you register your integration with Visma.Net. For production, it is required that the provided URI is set up with HTTPS.    When you have a redirect URI, this should be sent to your partner service in order to be able to get your Client_ID and Client_Secret. When this has been processed, you will receive an Activation email for your registration, the link to activate your Client_Id will be active for 5 days, so make sure to do this when the email is received:     API client types For Visma.Net there are two client types available, API “test client” and “production client” (also known as live) Test Clients All new API clients are generated as the type “Test”. In the test client there is a limit to the allowed calls per hour, which is set 500 calls/hour/per company.   ℹ️ When you are ready to go live with your integration you need to contact your partner service to obtain the "production" type API Client. Production Clients In the Production Client, the limit for calls  is ​15,000 calls / per hour & per company (since version: 8.25) Please also see, Why am I receiving "HTTP 429 - Too many request / throttling" response from API ? Visma.Net Integrations Startup Guide Visma.Net API International Support Policy Contacting the Visma.Net ERP Support / Partner Service API incidents - Troubleshooting and reporting

Currently, the "Attributes" parameter is exposed on the following endpoints.  Endpoint Customer CustomerContract Inventory Project Supplier   Setting the attributes for other assets works in the same way as for e.g. customer.    To set Attributes on Customers and Inventory Items you first need to Create the attributes in the UI. Assign the attributes to the Customer/Inventory etc. Classes respectively. Assign the class to the Customer/Inventory Item you want to use them on. Set the values of the attributes. 1. Creating the attributes: You can do this in the Attributes screen(ScreenId=CS205000): 2. Assigning the attributes to the class: Customer You can either reach the customer classes by Going to screen ScreenId=AR2010PL Clicking on the pen next to the class in the customer card: Here you then add attributes based on the attributes you have created in the attributes screen. Inventory You can either find the Item classes by: Going to the Item class screen(ScreenId=IN201000) Or clicking in the pen next to the Item class in the Inventory screen: Same as for customer, you can add attributes here based on the attributes you have created in the Attributes screen.   3/4. Setting the attributes and their values When this has been done, you can under the Attributes tab add the attributes from the classes the Customer/Inventory belongs to and set their values:   Using the attribute parameter via the API   To use these attributes, below is the syntax to use in your query: Filtering on several attributes. {{base}}/inventory?attributes={"AttributeID1":"ValueID1","AttributeID2":"ValueID2"} Filtering on date time {{base}}/inventory?attributes={"DATETIME":"2019-04-19"} Filtering on text. It will not match partial strings. only exact string. {{base}}/inventory?attributes={"TEXT":"long text to filter upon"} Filtering on True/False {{base}}/inventory?attributes={"ACTIVE":"1"} With special case for Multiple selection combo: {{base}}/inventory?attributes={"AttributeID":"ValueID1,ValueID2"}​ When encoding your query, the "equal sign" should not be encoded, below is an example for the customer endpoint and accepted forms of encoding it: Customer Endpoint: GET {baseUrl}customer?attributes={"DATETEST":"2019-01-01","TEST":"testvalue"} Encoded: (both encoding examples below are accepted) customer?attributes=%7B"DATETEST":"2019-01-01","TEST":"testvalue"%7D customer?attributes=%7B%22DATETEST%22%3A%222019-01-01%22%2C%22TEST%22%3A%22testvalue%22%7D Inventory Endpoint Inventory?attributes={"TEST":"testvalue"} Encoded: (both encoding examples below are accepted) inventory?attributes=%7B"TEST":"testvalue"%7D inventory?attributes=%7B%22TEST%22%3A%22testvalue%22%7D

When posting documents with subaccounts, some times you might encounter errors that look like this: “Error: (.*) of Subaccount do not exist."   To troubleshoot this please have a look at your Segment Key/Value setup of the dimension “SubAccount” (ScreenId=CS202000&DimensionID=SUBACCOUNT)     Clicking on the “Segment ID” will lead to the screen showing your values for that Segment Key:     If you have validation activated for your Segment Key’s, you need to set up the combinations you want to be using in the SubAccounts screen(ScreenId=GL203000)      

Manage environments Creating a new environment You can create a new environment from the: Manage Environments icon New button Launch screen Manage environments icon Click "Manage Environments" icon in the upper right corner of the Postman app. Select “Manage Environments”. Click the Add button. New button In the header toolbar, click the New button or click the “Gear” Manage Environments icon   Click "Environment" and enter a name for the new environment.   Add the variables you want to save as key-value pairs.   Click the Add/Update button. Manage Environments to change the values with your own   base_uri:currently pointing to API environment <https://integration.visma.net/API> client_id: The client identifier given to the client during the Application registration process. client_secret: The client secret given to the client during the Application registration process. redirect_uri: (CallbackURL)The Application’s callback URL that’s registered with the server. If not provided, Postman uses a default empty URL and extracts the code or access token from it. company_id: Financials companyId that will be used on API calls   scope:The scope of the access request {financialstasks} state: An opaque value that prevents cross-site request forgery auth_URL: The endpoint for authorization server, which retrieves the authorization code.<https://integration.visma.net/API/resources/oauth/authorize> Access_Token_URL: The endpoint for the resource server, which exchanges the authorization code for an access token. <https://integration.visma.net/API/security/api/v2/token>     oAuth2 OAuth 2.0 is an authorization type that enables you to approve an application that contacts another application for you without exposing your password. To use the OAuth 2.0 authorization in Postman In the Authorization tab, select "OAuth 2.0" from the TYPE drop down menu. From the "Add authorization data to" drop down menu, select either "Request URL" or "Request Headers". To set the authorization parameters for a request, you have three options: Click the Get New Access Token button. The screen appears.  Enter the appropriate values, click the Request Token button to populate the "Access Token" field, and then click the Send button. In the "Access Token" field, enter a token, or an environment defined variable, and click the Send button. In the "Available Tokens" drop down menu, select an existing token and click the Send button.     Get New Access Token After clicking the Get New Access Token button , Postman brings the following screen where user should fill out the parameters.     The values used here are the variables defined in the environment. After filling the parameters user needs to click Request Token button.   You will be directed to a Visma.net login, enter your credentials and sign in.     Allow Visma.net Integrations to connect to your account.     After you click the Allow button and if entered data is correct, you will see the Postman window that has the token. By default Postman expects to find a field named: access_token in the response. Since the Visma.Net response contains a field named  token , instead of access_token, Postman cannot auto-detect it as an access_token     Copy the value of token , close the MANAGE ACCESS TOKENS screen and paste it in the Access Token field.       We also recommend taking a look at : Connecting your Visma.Net Financials company to the API OAuth 2.0 Authorization Flow

Setup up your user rights To be able to use Visma.Net API you need to make sure your visma user have the correct roles on the Financials company you want to use it for. Login with your Visma.Net Account : https://signin.visma.net and go to Admin Panel. 1- Visma.Net Admin 1.A- To be able to edit the access rights you need to be logged in with a user with “Customer administrator” role.   1.B- To set your rights, click on Visma.Net Financials in the top left corner and choose Admin.   2-User and roles 2.A- When you have accessed Visma.net Admin click on “User and roles”.  2.B- Head to the “User” tab. 2.C- Search for your username and click your name. 3-Company access and rights 3.A- If the company you want to edit roles for does not exist in the list under your username, click the “Add access to” menu and look for the company you wish to add.      3.B- Find the company you want to edit roles for.     3.C- On the line for the desired company, press the field for “Financials” and add the roles “Financial Administrator” & “Financials User”.   Swagger Our Swagger is a good point for you to start using the API.   Connect to your Visma.Net account Authorize and get a VNF token to use in Swagger. Click “Authorize” on the right side of the interface.     Tick the box for “financialstasks” and press “Authorize”     You will be directed to a Visma.net login, enter your credentials and sign in.(If you are not asked to enter your credentials but get directed to the next step straight away, please clear your cookies in your browser and retry)     Allow Visma.net Integrations to connect to your account.     When you have allowed the connection you see that you are now authorized in Swagger. Close the window and proceed to use Swagger.   Start using Swagger The first thing you need to do is check what companies your visma.net financials user have access to. You can find the names and Ids via the “Context” endpoint. Scroll down to the “Context” endpoint and expand it.     Expand the first GET method - Get the companies available for this token, and press “Try it out”.     You will now see a button, “Execute”, press it and you’ll notice the result below will have updated to show your available companies. You’ll also see the request URL.     In the list, decide which company you want to use and copy the “id:”, this is the Id you will add to your “ipp-company-id” header when you are making requests. For now scroll back up to the top and paste the ID in the field “ipp-company-id”. When you have filled this field, the requests you execute via Swagger will target that company.     We also recommend taking a look at : OAuth 2.0 Authorization Flow  

Overview In modern web applications, ensuring data consistency and preventing conflicts is essential, especially when multiple clients attempt to update the same resource concurrently. The ETag and If-Match HTTP headers offer a solution for these challenges. Here's how they work together to maintain data integrity. ETag Response Header An ETag (Entity Tag) is a unique identifier that the server assigns to a specific version of a resource. It is included in the response header when a client requests the resource. This identifier helps clients in managing cache and detecting resource changes. Usage in API: When a client requests a resource, the server responds with the ETag value in the response header and as part of the response DTO (with the field name: "Timestamp").  Pagination Note: During paginated responses, the ETag value isn't included in the response header but is available within the response DTO (Field name: "Timestamp"). If-Match Request Header (Optional) The If-Match HTTP header is used by clients to signal that they wish to update a resource only if its current version matches a specific ETag. This mechanism prevents resource conflicts when multiple clients try to update the same resource simultaneously. See also, lost update problem, If-Match, HTTP conditional requests   Conflict Prevention: If the ETag stored on the server doesn't match the client's If-Match header, the server responds with a 412 Precondition Failed status code Usage in API: Currently  "If-Match" header is optional and can only be used with certain PUT & POST Action endpoints shared in detail in the following section below.  Example: 1) GET : .../api/v1/supplier/xxxxx Response headers : ETag Response body : timeStamp 2) PUT: .../api/v1/supplier/xxxxx Request headers : If-Match   This request will succeed in updating the resource only if the resource's current "ETag" is "AAAAAE0YIiI=". A) In case of success, the server returns "204 - No content" together with the new ETag value in the response headers.   B) In case of failure, the server returns "412 - Precondition Failed". Advantages of using ETag and If-Match Optimistic concurrency control: By using If-Match headers, clients can ensure that updates to resources are made safely without unwanted overwrites. Data Integrity: Helps maintain data consistency by validating that resource updates are based on the most current data. API Endpoints with ETag and If-Match Header Support A) Endpoints & Operations Supporting "ETag" Response Header ℹ️ PUT: The ETag of the recently updated entity is included in the response header. ℹ️ POST: The ETag of the recently created entity is included in the response header. GET Supplier PUT Supplier  POST Supplier  GET SupplierInvoice  PUT SupplierInvoice  POST SupplierInvoice  GET SupplierLocation PUT SupplierLocation  POST SupplierLocation  GET SupplierPayment PUT SupplierPayment  POST SupplierPayment  GET Shipment PUT Shipment  POST Shipment  GET PurchaseOrder PUT PurchaseOrder  POST PurchaseOrder  GET PurchaseOrderBasic PUT PurchaseOrderBasic  POST PurchaseOrderBasic  GET PurchaseReceipt PUT PurchaseReceipt  POST PurchaseReceipt  GET PurchaseReceiptBasic PUT PurchaseReceiptBasic  POST PurchaseReceiptBasic Note: : "TimeStamp" field can also be checked via the DTOs where it's exposed. B) Endpoints & Operations Supporting "If-Match" Request Header PUT Supplier PUT SupplierInvoice PUT SupplierLocation PUT SupplierPayment PUT Shipment PUT PurchaseOrder PUT PurchaseOrderBasic PUT PurchaseReceipt PurchaseReceiptBasic   If the endpoint is asynchronous,  meaning that if it is immediately returning a “202-Accepted” HTTP response and starts the actual job in the background, such as “Action” based operations. (Endpoint URL: …/action/…) If-Match is supported in the following actions only with “erp-api-background usage, POST SupplierPayment action/Release POST SupplierInvoice action/Release POST SupplierInvoice action/Prebook POST SupplierInvoice action/voidinvoice POST SupplierInvoice action/sendtoapproval ---------------------------------------------------------------------------------------------------------------------------------------- We're currently working on updating the swagger documentation, once the work is done, function will be listed on all the related operations / actions accordingly.   This knowledge article serves as a guide for developers to incorporate ETag and If-Match functionality into their applications, ensuring smooth updates and mitigating conflicts in a multi-client environment.

Introduction In SalesOrder v1 and v2, when you set the {"markForPO": "true"}, the Purchase order source is by default set to Purchase to order. In SalesOrder v3, only the field purchaseOrderSource is included. If you set purchaseOrderSource in v3, markForPO will automatically be true in the database.   ScreenId=SO30100S   This change simplifies the process compared to v1 and v2, where you needed to include both markForPO and poSource if you wanted to set the Purchase order source to Drop-Ship. The change in v3 allows you to set Purchase order source with just one field.   Available Options for v3 There are two main methods to set the purchase order source in v3.   Option 1: Default Replenishment Setting in UI If an item has a default replenishment source, such as Drop Shipment or Purchase to Order, set in Item warehouse details screen (IN204500, Replenishment Info-tab), the system will automatically mark the line for PO when you add the item to an order line. The Purchase order source will be set according to the item's default setting.   ScreenId=IN204500   Option 2. Manual Setting If an item does not have a default replenishment source, set the Purchase order source manually for the line when needed. In v3, use {“purchaseOrderSource”: “purchaseToOrder” } instead of setting {markForPO: true} as in v1 and v2. See the documentation for more information.   POST /api/v3/SalesOrders   With these changes in v3, managing purchase order source in sales orders becomes more straightforward and efficient.

In this article, you can find guidelines on utilizing Visma.Net API Endpoints using DateTime parameters, as well as their associated condition and operators. For more information regarding the endpoints, query parameters and other endpoints for all areas, Please read the documentation found here: Swagger - Visma.Net Integrations Documentation lastModifiedDateTimeCondition=Operator Supported comparative operators for LastModifiedDateTime Conditions on filtering  > - Greater than < - Less than <= - Less than or equal to >= - Greater than or equal to   Explanation:   ?lastModifiedDateTime=2024-05-25 &lastModifiedDateTimeCondition=>- Retrieve records after and on the given DateTime ?lastModifiedDateTime=2024-05-25 &lastModifiedDateTimeCondition=<- Retrieve records before and on the given DateTime ?lastModifiedDateTime=2024-05-25 &lastModifiedDateTimeCondition=>= Retrieve records after and on the given DateTime ?lastModifiedDateTime=2024-05-25 &lastModifiedDateTimeCondition=<= Retrieve records before and on the given DateTime Usage example: This query will return customers updated on 2024-05-25 or later. GET https://integration.visma.net/API/controller/api/v1/Customer ?lastModifiedDateTime=2024-05-25 &lastModifiedDateTimeCondition=>= ( Lines are separated for readability)   The operators are used the same for: createdDateTimeCondition=Operator dunningLetterDateTimeCondition=Operator

Question We received a 400 Bad Request when using POST/api/v3/SalesOrders. How can I see what is the reason for this error? Answer When receiving a 400 Bad Request it include an error response body. This response body will indicate the reason for getting the error, looking like this:    

We’ve implemented a new feature that API Endpoints available at Visma.net ERP API Documentation, can be invoked in an asynchronous mode by using the new “Background API” functionality. (Version: 8.88.0)  This can be achieved by adding an extra request header “erp-api-background: “WebhookURL”  to your request.   If this additional “request header” is provided in your request, our servers  will "intercept" the API request before it reaches the Endpoint. The request will be persisted in our backend. All our application web servers will regularly pull queued requests and process them in the background. This processing is not taking place in a web context, and therefore it is not prone to web exceptions like timeouts etc.    In this way, with this new feature, potentially long-running operations can be performed more effectively.    Once the request has been processed, the API Client will be notified with the webhook notification if “erp-api-background” request header had been provided with “webhookURL” value in your request.   This webhook notification will contain information about, “stateLocation” of the operation(status of the background operation) and “ContentLocation”  that where the response can be picked up, in other word, where the API Client can GET the result of the request that has recently been made.(if it has any content aka ResponseBody)   If the “erp-api-background” request header value set as “none” Webhook notification will not be invoked.  In any case, every queued API request will be assigned an ID that will be present in the immediate “202-Accepted” response to the client.  This response also contains a "stateLocation" address that the client can call at any time to check what is the status of the background operation.  "contentLocation" address that points to the readily formatted and stored response body of the operation if it has any content to be returned.   If the endpoint today is asynchronous,  meaning that if it is immediately returning a “202-Accepted” HTTP response and starts the actual job in the background, such as “Action” based operations. (Endpoint URL: …/action/…),     Currently,  the new "Background API" system is also unable to receive the state of the document when the action based request invoked. Therefore, we’re unable to determine whether the “action” based process succeeded or the state of the document changed without making an additional GET request to see the actual status of the document. However, this topic is already in our development plan. (Endpoint logic should be "synchronous" so that, waiting for the actual job to be done, to inform the client accordingly.)   Example request: "Request Headers erp-api-background : yourWebhookURL" Key  Value ipp-application-type Visma.net Financials ipp-company-id "ERP CompanyID" Content-Type application/json Authorization "yourToken" erp-api-background "yourWebhookURL"   GET: "Customer  Invoice" Request URL: /api/v1/customerinvoice?pageNumber=1&pageSize=100 HTTP Response: “202-Accepted” Response Body: Received Webhook Notification: GET: "stateLocation" Request URL: /api/v1/background/{id} HTTP Response: ”200-OK” Response Body: GET: "contentLocation" Request URL: api/v1/background/{id}/content HTTP Response: ” 200-OK” Response Body: Contains the “GET - CustomerInvoice” data. --------------------------------------------------------------------------------------------------------------------------------------- POST: “Customer Invoice” Request URL: “/api/v2/customerinvoice” HTTP Response: “202-Accepted” Response Body: Contains request “ID” and “stateLocation” Received Webhook Notification: GET: "stateLocation" Request URL: /api/v1/background/{id} HTTP Response: ”200-OK” Response Body:  --------------------------------------------------------------------------------------------------------------------------------------- PUT: "Customer Invoice" Request URL: /api/v1/customerinvoice/{invoiceNumber} HTTP Response: “202-Accepted” Response Body: Contains request “ID” and “stateLocation” Received Webhook Notification: GET: “stateLocation” Request URL: /api/v1/background/{id} HTTP Response: ”200-OK” Response Body: --------------------------------------------------------------------------------------------------------------------------------------- "Request Headers erp-api-background : None" Key Value ipp-application-type Visma.net Financials ipp-company-id "ERP CompanyID" Content-Type application/json Authorization "yourToken" erp-api-background "None"     ℹ️ Webhook notification will not be invoked, State & Content Location logic will be the same as request examples shared above.  ---------------------------------------------------------------------------------------------------------------------------------------   Please feel free to contact us (Financials ERP API Support) if you need any further information.

Did you know that Visma.net ERP API supports different compression algorithm? We support brotli, gzip and deflate. They can be used by adding Accept-Encoding: <compression type> in your request header. More info and sample code can be found at: Response compression in ASP.NET Core

In order to be able to add a new "Contact" to a Supplier or Customer via Visma.net ERP API, we can use the POST - Contact Endpoint.  Visma.net ERP API - Endpoint Documentation     Visma.net Financials ERP - Contact Module - ScreenID=CR302000     The connection between Supplier / Customer and Contact will be established by "businessAccount" field which is available in the POST - Contact DTO. "businessAccount": { "value": "string"   We need to set POST - Contact:"businessAccount" field's value with the "Customer ID" or "Supplier ID" depending on where you'd like to assign the "Contact". 1) POST Contact Endpoint (Sample payload) https://integration.visma.net/API/controller/api/v1/contact { "active": { "value": true }, "title": { "value": "Doctor" }, "firstName": { "value": "Crowley" }, "lastName": { "value": "Ozy" }, "position": { "value": "Position" }, "businessAccount": { "value": "Supplier or Customer ID" }, "sameAsAccount": { "value": false }, "address": { "value": { "addressLine1": { "value": "A1" }, "addressLine2": { "value": "A2" }, "addressLine3": { "value": "A3" }, "postalCode": { "value": "1313" }, "city": { "value": "test" }, "countryId": { "value": "01" }, "county": { "value": "02" } } }, "email": { "value": "test@gmail.com" }, "web": { "value": "web" }, "phone1": { "value": "0002" }, "phone2": { "value": "56565655" }, "phone3": { "value": "656565" }, "fax": { "value": "65656565" }, "contactMethod": { "value": "Any" }, "doNotCall": { "value": true }, "doNotFax": { "value": true }, "doNotEmail": { "value": true }, "doNotMail": { "value": true }, "noMassMail": { "value": true }, "noMarketing": { "value": true } }   2) Financials ERP UI Output Customer: Supplier: