About Yıldırım

Yıldırım · ‎11-09-2020

Hello, There is a general performance degradation in both API and some operations in ERP. Our Infrastructure teams is currently investigating elevated reports of the connection issues. We are sorry for the standstill this may have caused in your integrations. Updates will be forthcoming.

Yıldırım · ‎10-09-2020

Hi Andre, The team is currently investigating the issues. Please subscribe to the The column name '[FeaturesSet].[SeveraIntegration]' is invalid.

Yıldırım · ‎09-09-2020

Hello, as far as i know, Auto-Invoice is receiving data from embedded methods working in Visma.Net ERP. The data (XML) is populated by Financials and sent to Auto-Invoice SOAP. Visma.Net Financials Branch / Company is linked to Auto-Invoice via ScreenId=CS10250 (AutoInvoice settings). So it does not read the data via the Visma.Net ERP API but receiving the file what ERP constructs based on peppol bis 3.0 Consequently, to be able to receive IBAN / Bank Account etc from Organization Module via API the following idea should be implemented in Visma.net ERP API Expose Organisations "Payment Settings" Tab via Branch Endpoint

Yıldırım · ‎09-09-2020

We connect our system to Visma and perform recognition on the invoices added to our system.We use the IBAN of the vendor to recognize which vendor it is. However, often the IBAN number of the receiving company is mentioned on the invoice. We would like to synchronize the IBAN number of the company itself to Blue10, so we can exclude that IBAN number from recognition. So we're not looking for the IBAN on customers and suppliers, but the company IBAN. I'm looking for the possibility to get out the Bankaccount-Number of the Branch (CS101500) - Bank Settings / BBAN since we produce outgoing electroinc invoices by our portal. In the new Peppol-BIS 3.0 description is documentated to use the Payment Methods instead and place the bankaccount there (Screen CA204000) - Field PaymentMethod / BBAN. It seems that autoinvoice is able to read this field in any way, but I can't find it in the API either. -----------------------------------------

Yıldırım · ‎09-09-2020

Fix has been deployed, the team will continue monitoring. Please let us know if the problem persists. https://status.visma.com/incidents/nz6f72958shq

Yıldırım · ‎09-09-2020

Information regarding Visma.Net Financials ERP "Some of our users are having issues to login to their demo companies" Updates will be provided at Status.Visma: https://status.visma.com/incidents/nz6f72958shq

Yıldırım · ‎09-09-2020

Hello Florian, Currently, Payment Settings tab is not available in the Branch Endpoint ,therefore, this information can not be fetched via the API at this moment. (Exposing Payment Settings Tab is registered in the backlog) ------------------------ When it comes to "Payment Methods" - ScreenID:CA204000 UI Settings 1)Assuming that Financials ERP configured with the desired payment methods. (Bank Account) 2) Customer/Supplier is configured with the specified Payment Method 3) Customer > Customer Payment Method ScreenID:AR303010 where you can enter the values based on your payment method settings (IBAN,Bank Account etc) API 1) This information can be fetched through, first, looking up to the PaymentDto, {GET:CustomerPayment} in order to get relevant Customer reference/s, "customer": { "number": "string", "name": "string" }, to get relevant Payment Method reference, "paymentMethod": { "id": "string", "description": "string" }, and making another GET request to the /controller/api/v1/customerpaymentmethod/{customerNumber}/{customerPaymentMethodId} (If you already have the Customer and CustomerPaymentMethod references, first calls can be skipped) In this way, you can get the details of the registered Customer Payment Method based on the references these have been used in the Customer Payment Document. Endpoint documentation: https://integration.visma.net/API-index/

Yıldırım · ‎09-09-2020

@SlootweR wrote: I did get a ID number to run tests against and still I get this error. For now I was the only one doing tests... Please advise as I did only a couple of test runs with API, cannot even reach 500 a hour. Please send your API Client ID to <developersupport@visma.com>

Yıldırım · ‎09-09-2020

@SlootweR wrote: Still getting error a8910fa7-22d2-47e1-a734-ffd2546a0c33 Browser closed and restarted… but still error Please send your API Client ID Financials ERP CompanyID & Name to <developersupport@visma.com>

Yıldırım · ‎09-09-2020

Hello, can you please provide related Screen ID of the Module and print screen from the panel ?

Yıldırım · ‎09-09-2020

@SlootweR wrote: Very often we get this error, how many issues is causing this and can it be removed as it probit us in testing: Hello, Swagger is a platform that only addresses need of helping with endpoint readability and small testing ,therefore, currently we don't encourage people to use swagger to execute whole transaction sets for any reason. There is also ongoing operation for implementing new throttling rules for the swagger. (Requests Per Company instead of using a common pool) We recommend conducting your tests with your own API Client ID that has been provided to you during the onboarding. (Test Type clients are allowed to have 500 requests per hour. Once you complete the testing you should inform partner service from your market to obtain Production Type API Client)

Yıldırım · ‎09-09-2020

Hello, This was caused due to technical issues faced during the planned release. More information can be found at (https://status.visma.com/incidents/22f0crhg5wg0) Visma.Net Financials ERP is up and running again and Version 8.25 release has been postponed.

Yıldırım · ‎09-09-2020

Last night (08/09/2020) planned release has been postponed due to technical reasons. Further information can be found at https://status.visma.com/incidents/22f0crhg5wg0 A new date will be communicated in due course. ----------------------------- Update: New release date for 8.25 version has been planned as 15th of September. (https://status.visma.com/incidents/hnyxw0fmm166) Version news Visma.net Financials API updates for version 8.25 (September 2020)

Yıldırım · ‎08-09-2020

Thank you too Florian ! We definitely understand that using swagger can be easier for the consultants. If this is mostly required for testing of single calls and investigation / documentation etc, We'd also recommend that considering the option of generating a token with your Test Client ID via Postman and storing it in the postman instances between your consultants. This would be also a concrete solution, if you'd like to see the guideline, it can be found here : Generating token with oAuth2 for Visma.Net API in Postman

Yıldırım · ‎08-09-2020

Hello, As of today, swagger-ui is shared with all developers, so you might get throttled even though you did not make any request due to the total of the transactions might have been reached out the threshold. We're currently working on a new approach to bend this rule with Request / Per Company. We will keep the community posted with future developments.

Yıldırım · ‎07-09-2020

Visma.net Financials API updates for version 8.25 (September 2020) Increase of data transferred through GeneralLedgerBalance endpoint Previously, the table containing balances did not have the LastModifiedDateTime column. To implement filtering by LastModifiedDateTime on GeneralLedgerBalance endpoint, the column from the Transactions table was used. However, this implementation might cause some issues. Now there is the LastModifiedDateTime column in the Balances table and it is used in the API endpoint implementation. This is not a breaking change. However, the integrators should expect an increase of transferred data first time they call the endpoint after release. This behavior is determined by the new column. For the existing entries, the newly introduced column will be filled in with the current date and time. There is no way to find out exactly when a balance was changed last time, so this approach is the only solution to ensure data integrity. For example, the newly introduced column will be added during the upgrade on 15th of September 2020. For all lines the last modified date time will be set to '2020.09.08 hh:mm:ss'. Supposing an integrator had it's last synchronization on '2020.09.07 22:00:00', on next synchronization, after '2020.09.08 hh:mm:ss', the '2020.09.07 22:00:00' will be set as last modified date and time. Then there will be fetched all lines from database. This will happen only on first synchronization after upgrade. On the next ones there will be set a last modified date and time greater than '2020.09.08 hh:mm:ss' and only really changed balances will be fetched.

Yıldırım · ‎07-09-2020

Thanks. This module is available with the API, the correspondent endpoint name is "Stocktake" and can be found in the documentation : https://integration.visma.net/API-index If you need information about module usage, you can get help from Financials ERP Online Documentation : https://help.visma.net/no_en/financials/online-help/o2c/in_30_50_00.html

Yıldırım · ‎07-09-2020

Hello, Please look at the URL in the browser address bar > "ScreenID" and share with us.

Yıldırım · ‎07-09-2020

Hello, are you referring to "Stocktaking Review / ScreenId=IN305000" in the Financials ERP ?

Yıldırım · ‎04-09-2020

Hello, Fix has been deployed, the team will continue monitoring. Please let us know if the problem persists. https://status.visma.com/incidents/8dpkcy0qtyf5

Yıldırım · ‎04-09-2020

Thank you for your feedback. Incident has been resolved, we are monitoring the results. Please let us know whether you are still facing the problem. https://status.visma.com/incidents/4prq8jph2fx4

Yıldırım · ‎04-09-2020

Hello, The team is currently working on a fix, it has been planned to be deployed today. This may vary depending on the process. More conclusive details about the deployment will be published at https://status.visma.com/incidents/8dpkcy0qtyf5

Yıldırım · ‎04-09-2020

Underscore is being used as a segment delimiter in the Financials UI therefore end-user can not create a resource by using "_" . Financials ERP UI replaces "space" chars with "_" when resourceID is shorter than the defined segment length therefore you should avoid to use underscore while creating resources via API. Especially this misuse will be taken into consideration as a bug in API with POST operation. API should not allow using "_" for resource identifiers. This may lead wrongfully referenced inventories in the UI/ DB transactions. When you POST an Inventory via API: { "inventoryNumber": { "value": "01-210034_BK_30/32" }, "type": { "value": "FinishedGoodItem" }, "description": { "value": "Underscore usage via API" }, "itemClass": { "value": "6" }, "postingClass": { "value": "1" } Financials UI (Underscore cannot be entered as ID char in the UI ) Then when you try to overwrite the same underscore used value manually on the UI by Update ID Action, system will replace these underscores with space char. @plh wrote: Does not seem to have any impact on the performance figures, but this allows customer to delete all the dublicated data in their financials. PS. After the update on incident, we dont see any improvement in timings. I can send export for all calls if you need. Please send these reports to <developersupport@visma.com>

Yıldırım · ‎04-09-2020

Hello, The performance issue from yesterday has been diagnosed and the remedial task is still in progress. Calls should be performing better today. Can you please check this over and inform us ? https://status.visma.com/incidents/4prq8jph2fx4

Yıldırım · ‎03-09-2020

We confirm that this is currently following the intended behaviour, results are ordered by LastModifiedDateTime when LMDT is used as filtering parameter. In base GET calls, records are orderedBy "internalId". We definitely understand the bottleneck you're experiencing so if you could make a change/adjustment request at the Ideas section, we'll check that if this behaviour in the specification can be modified as you described.

Yıldırım · ‎03-09-2020

Hello Véronique, We'll check this over to make sure whether it's working as designed. (LastModifiedDate & Default Sort-Ordering)

Yıldırım · ‎03-09-2020

Hello, Currently, OrderBy query parameter is obsolete and it's omitted by the endpoints. Every transaction is automatically ordered by ASC based on its PK while being fetched from the DB (base GET invoke),therefore, it shouldn't be used in the URI. This parameter will be removed from the API documentation soon. If you could register this request at Ideas section, this will be evaluated by the development team. Thanks.

Yıldırım · ‎03-09-2020

More information will be provided as it becomes available.Updates at: https://status.visma.com/incidents/8dpkcy0qtyf5

Yıldırım · ‎03-09-2020

The situation is currently being investigated by the Infrastructure Team. Updates can be followed at : https://status.visma.com/incidents/4prq8jph2fx4

Yıldırım · ‎03-09-2020

Hello, we've informed the team and this is being checked out now.

Sv: 502 Bad Gateway

Re: Error messages "The transaction has been silen...

Re: BankAccountNumber

Expose Organisations "Payment Settings" Tab via Br...

Re: Enviroment does not work.

Re: Enviroment does not work.

Re: BankAccountNumber

Re: Hourly number of requests reached

Re: Enviroment does not work.

Re: API, Vendor Sales Price endpoint - Status chan...

Re: Hourly number of requests reached

Re: Enviroment does not work.

Version 8.25 release has been postponed (New plann...

Re: Swagger - number of requests exceeded

Re: Swagger - number of requests exceeded

Increase of data transferred through GeneralLedger...

Re: Is Physical Inventory Count available in the A...

Re: Is Physical Inventory Count available in the A...

Re: Is Physical Inventory Count available in the A...

Re: webhooks unstable

Re: Alot of errors from the API today

Re: webhooks unstable

Re: Inventory API: Slow performance

Re: Alot of errors from the API today

Re: Orderby query parameter

Re: Orderby query parameter

Re: Orderby query parameter

Re: webhooks unstable

Re: Alot of errors from the API today

Re: webhooks unstable

Useful pages

About Visma

Contact us

Follow us