My Areas

Sign in to follow product and topic areas and get a shortcut in this menu
Visma eAccounting API
cancel
Showing results for 
Search instead for 
Did you mean: 
Recent topics

Status changed to: Declined

Endpoint: PUT v2/fiscalyears/openingbalances 1. Usability The purpose of this endpoint is to allow the user to update its opening balances on the first fiscal year through the API using a simple collection of account numbers and their new opening balances. Below you can see the Opening Balance section as you would like to update in eAccounting. Opening Balance in eAccounting In order to achieve the same behavior through the API, the following payload should be used: Opening Balance in API As you can see the account numbers which we wanted to update in the web application can be found in the JSON, next to its balance. The new balances represent the new total amounts that we want to have on the specific accounts, which do not amount or diminish the previous ones but instead replacing them. You can also specify some or all the other accounts in the fiscal year, as long as the total amount balances or you set the balance as it currently is.The endpoint by default supports using inactive accounts in the JSON by automatically activating them. If you do not wish to allow this, set the parameterenableInactiveAccountsto false in which case validation will be thrown. Scenario 1 We have the following accounts with their current balances: account 1010 ; opening balance: 10 account 1229 ; opening balance: -10 all the other account have 0 opening balances We would like to update the balance on account 1010 to 20. In order to successfully accomplish that, we need to set up a new amount on another account based on the new difference. In this case we will use account 1229 to counter the new added amount.The required JSON will be : Scenario 1 Note: You can also use other accounts as long as the amounts balance or either their current amount is used. Scenario 2 We have the following accounts with their current balances: account 1010 ; opening balance: 10 account 1229 ; opening balance: 20 account 1210 ; opening balance: 30 account 1470; opening balance: -60 all the other accounts have 0 opening balances We would like to update the opening balance of another account, for example, 1220 to -20. Below is an example of a way of doing it: At a first glance, the amounts in the JSON do not balance. -20 + 50 = 30. But below you can observe all the accounts with their updated amounts: account 1010 ; opening balance: 10 account 1229 ; opening balance: 20 account 1210 ; opening balance: 50 (the account we have used to counterbalance the new amount) account 1470; opening balance: -60 account 1220; opening balance: -20 (the updated amount which we've entered) all the other accounts have 0 opening balancesAs a result 10 + 20 + 50 - 60 - 20 = 0. Success! 2. Quick tips and sum up about functionality since the opening balance always needs to sum up to 0, a minimum of 2 pairs of account - opening balance needs to be used. opening balance can only be updated on the first fiscal year, which depending on your case, might not be the current fiscal year. the endpoint supports the use of a minimum of 2 accounts up to the total number of accounts in the first fiscal year. Also, the use of inactive accounts is possible through the specific parameter, which will automatically activate it. the endpoint works by replacing the previous amounts, not by adding or subtracting to them. using the same amount on an account as it currently holds is possible, though it will not be updated. the whole chart of accounts on the fiscal year can be used in the JSON. This might be useful when complex amounts and calculations are required if validation is thrown stating that your new amounts do not balance, although the amounts in your JSON body do (example 1010: 20 ; 1020 : -20), please check the amounts currently hold on other accounts in the fiscal year. A good example is Scenario 2.
Important Information We have implemented a new Identity Server that provides endpoints for authorization and authentication. This Identity Server will replace our existing ID/Auth Servers. We will shut down the ID/Auth servers in the production environment (https://id.vismaonline.comandhttps://auth.vismaonline.com) by the30th of September 2018. Until then, please make sure to update your solutions that go towards these endpoints as soon as possible. We have updated our documentation when it comes to authorization and authentication towards the new Identity Server. When it comes to the sandbox environment we will do the same changes, but the shutdown date is the1st of February 2018. If you have not implemented this change in your solutions, your existing test applications will stop working. The new Identity Server is used for: Authorize and Authenticate new customers. Receive Access Tokens, Identity Tokens and Refresh Tokens. The new Identity Server is located at another URL, in both Sandbox Environment and Production Environment. Endpoints Sandbox Environment: Authorization Endpoint:https://identity-sandbox.test.vismaonline.com/connect/authorize. Token Endpoint:https://identity-sandbox.test.vismaonline.com/connect/token. Production Environment: Authorization Endpoint:https://identity.vismaonline.com/connect/authorize. Token Endpoint:https://identity.vismaonline.com/connect/token. New Required Features Authorization and Token Requests Token requests towards the new Identity Server must always be in Content-Type: x-www-form-urlencoded. Scopes We have changed the namings of the scopes, and two additional mandatory scopes are added. Below is a list of mandatory and selectable scopes: Mandatory scopes offline_access ea%3Aapi Selectable scopes ea%3Asales ea%3Asales_readonly ea%3Apurchase ea%3Apurchase_readonly ea%3Aaccounting ea%3Aaccounting_readonly Tokens When requesting tokens, the Refresh Tokens will be always be updated.It is really important to save both Access Token and Refresh Token, the same Refresh Token cannot be used more than once. Force New Login If you want the user to log in again (even if you're already logged in) to authenticate multiple times in different companies, for example. Then use prompt=login in the querystring when you ask for authentication code against the auhorize endpoint. FAQ Why does Visma change Identity Server? More secure and stronger algorithms of token signing with certificates instead of symmetric keys. The new Identity Server follows the OAuth 2.0 standard and the OpenID Connect protocol. Simplifies future integrations and single-sign-on against other Visma products. Ability to access more user and company information in new claims. What do you need to do? Change URL to authorize-endpoint:https://identity.vismaonline.com/connect/authorizein production andhttps://identity-sandbox.test.vismaonline.com/connect/authorizein the sandbox environment. Change URL to token-endpoint:https://identity.vismaonline.com/connect/tokenin production andhttps://identity-sandbox.test.vismaonline.com/connect/tokenin the sandbox environment. Provide the two new mandatory scopes “offline_access” and “ea:api” Prefix existing scopes with "ea:" If you extract the access token yourself and use something in it, there are some minor changes in some claims: The value in "sub" is now UserId, not the e-mail address as before and the e-mail address is found in a new claim called " email ". Previous claim "VismaCustomerId" has renamed "customer_id" and all scopes are prefixed with "ea:" except "offline_access" which is a global scope. When can I make the change?The API already supports tokens from the new Identity Server, so it's free to switch to the new one, the sooner the better. Do I need to contact Visma before I change?No, your clients are already registered in the new Identity Server with the same client id and client secret as you have in the current. What happens when I switched over to the new Identity Server?All applications need to authenticate again and then everything is as before.Due to Visma's security policy, it may be necessary to authenticate again against the Identity Server if the authenticated user changes the password or lock their Visma Online account. What happens if I do nothing?From the 30th of September 2018 in the production environment, the applications will not be able to request new access tokens (HTTP status 400) and therefore not able to use the eAccounting API. If you have any questions about this, don’t hesitate to contact us
There are quite a few ways to pay invoices, so this endpoint deserves a cheat sheet. This FAQ does not cover all possible scenarios, but it should cover the most common ones. Domestic Customer Invoice Payments Scenario 1 Domestic debit invoice, full payment, no additions. Paid towards a cheque bank account. JSON data Voucher in eAccounting Scenario 2 Domestic credit invoice, full payment, no additions. Payed towards cheque bank account. JSON data Voucher in eAccounting Scenario 3 Domestic debit invoice, full payment with a factoring fee of 30 SEK. Paid towards a cheque bank account. We use 6064 as factoring account in this case, it is a commonly used account for this scenario in Sweden. Factoring fee is stated in the FactoringFeeAmount property and excluded from the PaymentAmount, as shown below. In the voucher, that amount is withdrawn from the cheque account row. JSON data Voucher in eAccounting Scenario 4 Domestic debit invoice, partial payment, no additions. Paid towards a cheque bank account. JSON data Voucher in eAccounting Scenario 5 Domestic debit invoice, full payment with 1 SEK in roundings, no additions. Paid towards a cheque bank account. JSON data Voucher in eAccounting Non Domestic Customer Invoice Payments Scenario 1 Non-domestic debit invoice in EUR currency with SEK as company base currency, full payment with no additions. Paid towards a cheque bank account. In this case, we receive exactly 1000 SEK in the bank when the currency is converted, which means that no currency profit/loss is registered by eAccounting. Quite rare scenario, unless the payment date is same as invoice date. JSON data Voucher in eAccounting Scenario 2 Non-domestic debit invoice in EUR currency with SEK as company base currency, full payment, with 10 SEK bank fee. Paid towards a cheque bank account. In this case, we receive a bit less money in SEK, due to currency loss. Note that DomesticPaymentAmount is payment amount in SEK with withdrawal for bank fee (10 SEK) and currency loss (8 SEK). JSON data Voucher in eAccounting Supplier Invoice Payments In general - Supplier invoice payments are the same as customer invoice payments. Some differences exist though:FactoringFeeAmount&FactoringFeeAccountNumberis not allowed in Supplier Invoice payments. Debit invoice amounts are specified in positive, credit invoice amounts are specified in negative.

Status changed to: Delivered

The bank transaction endpoints can now be found on Swagger.
Top Kudoed Authors
Top Solution Authors
Useful links

List of current integrations in: