Gewijzigd en verbeterd
Verwerkingsverslag: melding "Goed" verbergen (VIDIS-7221)
Waarom
Tot nu toe werden voor de Polisjob, Bulkjob en Relatiejob de succesvolle regels altijd getoond in het verwerkingverslag als aparte regel.
Hierdoor kan het verwerkingverslag bestand groot worden en zijn de fouten en waarschuwingen soms moeilijk ontdekken.
Een wens is om de succesvolle entries alleen in de totalen (<AantalRegels> and <AantalGoed>) mee te tellen.
Hoe
Verwerking > Handmatige/Automatische verwerking > Start Polisjob verwerking
Verwerking > Handmatige/Automatische verwerking > Start Bulkjob verwerking
Verwerking > Handmatige/Automatische verwerking > Start Relatiejob verwerking
De Polisjob, Bulkjob en Relatiejob hebben een optionele XML tag <GoedMeldingen>, onder de optionele tag <HashTotaal>, anders ServicecenterCode:
- waarde Nee : succesvolle regels worden niet individueel getoond in het verwerkingsverslag, alleen in de totalen.
- geen tag of de waarde Ja: succesvolle regels worden (als voorheen) individueel met "Goed" getoond in het verwerkingsverslag.
Actie
Indien u de Polisjob/Bulkjob/Relatiejob XML niet aanpast blijft de werking ongewijzigd.
Grootboekrekening rapportage "Baten" (VIDIS-7949)
Waarom
Als voorbereiding op het ondersteunen van de functionaliteiten met betrekking tot betaalbestemming 'Incasso' en Baten' is grootboekrekening rapportage "Baten" aangepast.
Hoe
In grootboekrekening rapportage "Baten" verdwijnt de kolom "betaling"(die altijd een lege waarde had) en zijn aan het einde 3 velden toegevoegd:
- Toelichting - de bij de schuldopvoering opgegeven toelichting
- Toelichting2 - Op dit moment altijd leeg
- Verzamel - "VerzamelUP" indien het uitkeringsplan een verzamelontvanger heeft (dus een vordering ten behoeve van borderel), anders "Regulier".
Actie
Geen actie nodig
Flexibiliteit bronsysteem van een uitkeringsplan versus bron van een relatie (VIDIS-8077)
Waarom
Tot nu toe was er geen scheiding mogelijk tussen het bronsysteem van een uitkeringsplan en de bron van een relatie, deze waren onlosmakelijk verbonden.
Waarbij de combinatie van bron en relatienummer wordt beschouwd als logische sleutel voor de relatie. Die bron moet tevoren ingericht zijn in de applicatie.
Dit sluit niet altijd goed aan op de praktijk, waarbij er bijvoorbeeld maar 1 CRM is (en enkel het relatienummer afdoende is als logische sleutel) in combinatie met diverse bronsystemen voor de uitkeringsplannen.
Hoe
Verwerking > Handmatige/Automatische verwerking > Start Polisjob verwerking
Verwerking > Handmatige/Automatische verwerking > Start bulk verwerking
Verwerking > Handmatige/Automatische verwerking > Start Relatiejob verwerking
Verwerking > Handmatige/Automatische verwerking > Start samenvoegen relatie verwerking
Verwerking > Handmatige/Automatische verwerking > Start rapportage ...
Voor de invoer van data via XML:
- Bij de Polisjob XML bestanden accepteren we het als het opgegeven bronsysteem van het uitkeringsplan (via verplichte XML tag <Bronsysteem>) niet bekend is in de applicatie (d.w.z. niet is ingericht binnen referentiegegevens Bron).
- Bij de Bulkjob, Relatiejob en Samenvoegenjob accepteren we het als er geen bron (via nu optionele XML tag <Bron>) is opgegeven voor de relatie (ten behoeve van fiscaal begunstigde of ontvanger).
In beide situaties interpreteren we dat dan alsof de Bedrijfscode van het fonds als waarde is opgegeven.
Om hier profijt van te hebben is het dus nodig om een bron met die waarde in te richten.
Als het gaat om uitvoer in rapporten, overzichten:
- waar het relatienummer getoond wordt blijven we het relatienummer dat behoort bij het bronsysteem van het betrokken uitkeringsplan tonen.
Als deze niet bestaat (indien het een niet ingerichte bron betreft) wordt het hoofd relatienummer getoond.
- in het daarbij getoonde bron veld blijven we het bronsysteem van het uitkeringsplan tonen.
Actie
Indien u de Polisjob/Bulkjob/Relatiejob XML en de inrichting van de bronnen niet aanpast blijft ook de werking van de applicatie ongewijzigd.
Wilt u wel gebruik maken van de boven beschreven scheiding tussen het bronsysteem van een uitkeringsplan en de bron van een relatie is verstandig te overleggen met een consultant van Visma Idella.
Termijnen uitkeringsplan fiatteren (VIDIS-7460)
Waarom
Tot nu toe werd er onvoldoende rekening gehouden met termijnen uitkeringsplannen bij het controleren van gewijzigde financiële velden.
Hoe
Fiscaal begunstigden > tabblad Uitkeringsplannen
Uitkeringsplannen > Nieuw uitkeringsplan
- Bij het bepalen of een tweede gebruiker een mutatie van het uitkeringsplan moet fiatteren kijken we of er sprake is van een financiële wijziging:
- bij reguliere uitkeringsplannen controleren we als voorheen (onder andere) of het (jaar)bedrag gewijzigd is.
- bij termijnen uitkeringsplannen gaan we nu controleren of het (termijn)bedrag ongelijk aan 0 is.
Ook als het bedrag gelijk is aan de voorgaande mutatie zien we dit als een financiële wijziging omdat het immers een delta, een extra uitkering/termijn is.
- Bij het filteren van niet-relevante tussenstanden uit de historie van een uitkeringsplan zullen we ook elk bedrag ongelijk 0 bij een termijnen uitkeringsplan als een relevante wijziging zien.
Actie
Geen actie benodigd.
Voorkomen dubbele of vroegtijdige jaaropgave voor overleden begunstigde (VIDIS-8079)
Waarom
In sommige gevallen wordt in de praktijk voor een fiscaal begunstigde een jaaropgave aangemaakt terwijl de administratieve afhandeling nog niet gereed is.
Of er worden 2 jaaropgaven aangemaakt.
Hoe
Fiscaal begunstigden > tabblad Uitkeringsplannen
Uitkeringsplannen > Nieuw uitkeringsplan
- Bij opvraag van alle jaaropgaven (d.w.z. met begunstigden selectie "Alle (A)") voor een "open" jaar:
Behalve de begunstigden met JaarlijkseJaaropgaveGeblokkeerd worden nu ook begunstigden waarvoor de Overlijdensdatum gevuld is overgeslagen.
Dit vanuit het idee dat deze met de stroom overlijdens-jaaropgaven mee gaan (waarna JaarlijkseJaaropgaveGeblokkeerd aangaat).
Het zijn dus overleden begunstigden die nog "in behandeling" zijn.
- Bij opvraag van tussentijdse jaaropgaven (d.w.z. met begunstigden selectie "Met vink Tussentijdse jaaropgave opgegeven jaar (T)") voor een "open" jaar:
Ook hier worden de begunstigden overgeslagen waarvoor de overlijdensdatum gevuld is terwijl JaarlijkseJaaropgaveGeblokkeerd (nog) niet aan staat.
Het vinkje "TussentijdseJaaropgave Ja/Nee" blijft aanstaan, de laatste jaaropgave voor de begunstigde wacht tot deze in de de stroom overlijdens-jaaropgaven mee gaat. Daar zitten alle controles in dat de administratieve afhandeling compleet is.
NB: Dit geldt alleen voor een "open" jaar, d.w.z een jaar waarvoor payroll Gemal nog berekeningen kan doen.
Zonder gebruik van een duale periode is dat alleen het huidige jaar.
Tijdens een duale periode is dat het voorgaande en het huidige jaar.
Actie
Geen actie benodigd.
Overige verbeteringen en opgeloste meldingen
- Technische upgrade javascript libraries (VIDIS-5901)
- Extra BNS formaat (VIDIS-8079)
- Negatief bedrag geeft fout bij ontvanger verdeling op begunstigde niveau (VIDIS-8087)
- Fout bij verrekenen vanuit betaling in combinatie met ontvanger verdeling op begunstigde niveau (VIDIS-8120)
- Technische Aanpassing in DFO20 (VIDIS-7552)
Visma Denemarken
Visma Finland
Visma Letland
Visma Nederland
Visma Noorwegen
Visma Zweden
Visma Developers & Partners
Visma Latijns-Amerika