| Item |
Dates/Info |
| Version |
1.3.0.1 Swagger on Prod
1.4.0.2/1.5.0.1/1.6.0.2/1.8.0/1.8.1/1.10.0
|
| Release month (PO) |
2025-10 |
| Validations |
Date |
By |
| Processing Doc.Team |
|
|
| Publication(s) |
Released Community |
|
| Publication 1 |
|
|
| Table of Contents |
|
|
Items
| Item |
Item beschrijving |
PBI |
opmerking |
Breaking |
Acc |
Stag |
Prod |
|
|
| 1.3.0.1 |
Uitbreiding naar alle velden bij GET companies |
VIDIS-8941 |
Get companies response bevatte alleen de id en de naamgeving. Nu worden alle velden meegegeven. |
Nee |
|
|
|
|
|
| 1.4.0.2 |
Bug fix Wijziging op endpoint Specificaties waarbij relatienummer niet meer verplicht is, en limit is toegevoegd met default = 10, |
VIDIS-9154 |
Nu kunnen alle specificaties van een maand worden opgevraagd. Technisch vergt dit wel een aanpassing in de APP die een GET request doet op een Specificatie
|
Nee |
|
|
|
|
|
|
1.5.0.1
|
Bug fix Benefitplan met type Advanced noticed kan gewijzigd worden naar Regular ook bij een eenmalig plan. |
VIDIS-8409 |
|
Nee |
|
|
|
|
|
| 1.6.0.2 |
Bug fix Toevoegen van een Recipient op een Benefitplan kan ook als deze eerder verwijderd was |
VIDIS-9063 |
|
Nee |
|
|
|
|
|
| 1.8.1.1 |
Technische aanpassing in API om voor het service center apart processen te kunnen starten ongeacht of die lopen op een ander Service Center |
VIDIS-9262 |
Aanpassing mbt eerste deel wijziging in VIDIS. |
Nee |
|
|
|
|
|
| 1.9.0.2 |
Bug fix, onnodige opbouw van history op endpoint Beneficiary |
VIDIS-9218 |
History en wijzigen van mutatiedatum actueel exemplaar gebeurde ook als er geen inhoudelijke wijziging wordt verstuurd. Dat verstoord onnodig de werking van doorgegeven mutaties naar de payroll. |
Nee |
|
|
|
|
|
| 1.10.0.1 |
Bug fix on total in response for Get specifications |
VIDIS-9154 |
Totaal werd niet in alle gevallen juist bepaalt. |
Nee |
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
Bijzonderheden
De publicatie op Community wijzigt in de oude structuur van Release Notes naar een doorlopend tabel overzicht per maand waarin de items zijn opgenomen en waar wordt aangegeven wanneer deze naar acceptatie gaat, naar staging en als laatst naar productie. Een extra kolom geeft aan of een item breaking is. Indien ja, dan wordt die naar staging doorgezet, maar vervolgens minimaal 1 maand later naar productie zodat klanten de gelegenheid hebben om de eigen app aan te passen en te testen.
Visma Finland
Visma Letland
Visma Nederland
Visma Noorwegen
Visma Zweden
Visma Developers & Partners
Visma Latijns-Amerika