Jaarwerk: opstellen van jaaropgaven voor mensen met een PW-uitkering en zorgdragen afdracht Loonbelasting (o.a. Premie Volksverzekeringen) en Zorgverzekeringswet (werkgeversheffing).
Cummulatieven: de opgebouwde historische gegevens over uitkeringen, belastingen, en vorderingen binnen SSD (Loonheffingen (PVV, Zvw, LB) en Bruto/netto vorderingen (terugvorderingen van teveel betaalde uitkeringen).
Wanneer een dienstbetrekking van belast naar onbelast wijzigt, dient deze wijziging zowel in SQL als in de loonaangifte te worden doorgevoerd. Vergeet niet om een reeds ingediende aangifte in te trekken. Let op: zowel in de SZDOS als de SZDOSHIS tabel.
Aanbevolen methode: Wat altijd werkt (zonder SQL) is het dossier afsluiten en dan begin- en einddatum gelijkzetten, dan kan een terugvordering aangemaakt worden: in dit geval van een belaste terugvordering met geïntegreerd herberekenen, maak een nieuw dossier, en die los je af op die schuld. Door dat terugboeken gaat die jaaropgaaf vanzelf naar beneden. En ook de loonaangifte in december (of de maand waarin je jaarwerk draait) vanzelf gecorrigeerd.
Belangrijk: Als er met SQL een dossier van belast naar onbelast wordt gezet, dan corrigeert het systeem niet automatisch de loonaangifte. De oplossing om alles terug te boeken, dossier te sluiten is altijd een oplossing. Want dan heb je iets op lopend dienstjaar, boek je terug.
Qua belast- onbelaste uitkeringsdossiers zijn er drie combinaties mogelijk
Ga naar SSD-beheer > componenten. Daarin staat o.a. een veldje 'belast' of 'onbelast'. Je kunt erop checken.
Tabblad regelingsspecifiek. O.a.: Belast, zvw etc. Kan je tussendoor niet meer veranderen.
De code: belasting code (1 anders 2,3,4,9) etc. wat doet dat door het jaar heen en wat doet hij bij de loonaangifte? De belasting code hangt een tabel aan vast 'Bijstandspercentagetarief' en aan die code hangen percentages, loonheffing die die door het jaar heen berekenend zonder rekening te houden met de definitieve rekenregel.
Belangrijk: SSD doet door het jaar heen niet de definitieve rekenregel toepassen, dat doet hij alleen met herberekening loonheffing aan het einde van het jaar. De bijstandspercentage berekening die zit ook op internet te vinden bij belastingdienst, voor de eindheffing is dat 58% - 60% van netto.
klik hier voor de belastingregels P-wet. De definitieve rekenregel die zit: rekenregels loonheffing bijstandsuitkering. De gemeente berekent de hoogte van de loonbelasting/premie volksverzekeringen als volgt:
Het percentage E is afhankelijk van de leeftijd van de bijstandsgerechtigde. Dus als iemand AOW gerechtigd wordt krijg je twee berekeningen en dus ook twee cummulatieven.
Berekening gaat in dat laatste geval in vanaf eerste dag van de maand waarin je AOW-gerechtigd wordt (vanaf de eerste dag van de maand dus gaat hij het voordelige percentage in). Som van die cummulatieven is jaaropgaaf.
Het recht op LHK moet goed staan anders gaat de berekening van Q al verkeerd. Want als jij namelijk 1 maand uitkering krijgt, maar nu blijkt: jij hebt 15 dagen teveel gehad. Dan maakt UA in SSD een vordering aan, waarin UA die begin en einddatum registreert (bijvoorbeeld van 16 aug tot 31 aug), dat is 15 dagen.
Systeemwerking: Bij niet-betaling Past SSD de Loongerelateerde Heffingskorting (LHK) voor de volledige maand toe. Dit levert een financieel voordeel op voor de gemeente, niet voor de cliënt. De logica is eenduidig: een hogere LHK resulteert direct in een lagere loonheffing. De verwerking is daarom op basis van 31 dagen. De gemeente is degene die de loonheffing afdraagt. Door maximale LHK toe te kennen, minimaliseert de gemeente haar eigen afdracht aan de Belastingdienst. Dit is het "voordeel". Het is een financieel-technische handigheid in het systeem, niet een sociaal beleid dat de cliënt helpt. het systeem is zo ingericht dat het pas corrigeert op het moment dat er daadwerkelijk een betaling binnenkomt. Zolang de vordering "open" staat, wordt de uitkeringsberekening niet aangepast.
De volgende componenten gebruikt SSD voor berekening LH:
Op het moment dat client Terugbetaald dan wordt dat bedrag terug naar de uitkering geboekt met het programma 'terugboeken ontvangsten'. Hij heeft niet alles terugbetaald, zeg in dit voorbeeld: de helft, 15 / 2 is 7 dagen: dan boekt het systeem 7 dagen terug. Dan gaat SSD 31 – 7 dagen lhk toepassen.
Teurg te zien in het systeem bij: dagen min. in HISCUM0 (veld: dagenmin of ‘dagen negatief’). Als dat gevuld is dan weet je dat er een debiteur is met het vinkje 'terugboeken dagen' aan en dat de dagen dus gedeeltelijk of in zijn geheel terug geboekt zijn. Dan doet hij het niet op basis van de maand maar obv: wat staat er in de debiteuren.
Debiteurendossiers: complex onderdeel Jaarwerk. In een vordering vanaf de 16e, als het vinkje 'terugboeken dagen' aanstaat gaat SSD naar verhouding deze dagen terugboeken.
Die boekingen zitten in de uitkeringshistorie. Dan staat er echter geen bedrag bij: alleen 'dagen negatief'.
Dienstjaar in debiteur: relevant voor terugboeken / doorboeken. SSD kijkt naar het dienstjaar bij het 'kabouter programma': 'terugboeken ontvangsten'. Hij pakt dan netto belaste vorderingen die teruggeboekt moeten worden naar de uitkering, vinkje in deb. dossier 'doorboeken' moet aan, hij pakt dan alleen vorderingen waarin dienstjaar = 2025 (huidig jaar).
Stel gemeente betaald 28 december 2024, dan valt hij obv boekingsdatum en fiscaal in het jaar 2024, als Gemeente die periode gaat terugvorderen is het 2024. Maar stel nu: de uitkering is geblokkeerd en er wordt betaald in januari 2025 dan is het fiscaal en boekingsdatum over 2025 en gaat hij mee met jaarwerk 2025. Alleen mag je over voorgaande jaren geen LHK benutten, dan mag je alleen over 2025 lhk benutten niet over 2024. Dan staan er geen dagen bij 'dagen negatief'.
Hoe kan je nu een uitkering terugvorderen in een periode waar je wel recht hebt op bijstand? Als jij achteraf inkomsten doorgeeft over een oude periode , in die terugvorderingen is er nog recht op bijstand want de inkomsten zijn lager dan uitkeringsloon alleen: het uitkeringsbedrag is lager. In zulke gevallen moet vinkje uit staan.
'ontvangsten voor dit jaar verwerken', kan je in december bij jaarwerk draaien. Komt aparte cummulatieven van, negatieve fiscaal loon en negatieve werkgeversheffing.
Zijn er bruto vorderingen die je niet mee wilt laten gaan naar loonaangifte? Ja: Vinkje 'uitsluiten loonheffing' relevant voor SVB / UWV: client en gemeente weten dat er een aow of ww uitkering aankomt. Dit wordt gecommuniceert met svb en uwv: je moet ALS je die uitkering toekent het geld verrekenen met de bijstand die wij overmaken!!! daarom dat vinkje, loonaangifte gaat dan via AOW en UWV. Wet van Oortsen.
Tip: Ze mogen niet mee met de blauwe kabouterlijn, vandaar dat vinkje 'uitsluiten loonaangifte'. Wel handig als gemeente een aparte debiteur groep hiervoor hanteert. Anders wordt het zoeken, en bij elke dossier dat vinkje aanzetten, het is een verrekening tussen instanties.
Als gemeente terugvordert wil drie dingen terug:
Nee zegt de belastingdienst: 1 en 2 krijgen jullie terug en 3 krijgen jullie niet meer, alleen als de client weer in de uitkering komt. Dit kan een negatieve cummulatieve/ jaaorpgaaf veroorzaken, mag niet van belastingdienst.
Op dit moment stuurt SSD nog negatieve werkgeversheffingen in. Waarom? De kosten van bijstand is netto (bij de PW) + loonheffing + werkgeversheffing: dat draagt gemeente af. Vervolgens gaat gemeente –als er sprake is van een stukje terugvordering - netto terugvorderen: als er aan het einde van het jaar niet terug betaald is gaat gemeente bruteren, bruteren is in feite: 'stel dat alles op tijd was terug betaald en we hadden alles terug geboekt en die dagen terug geboekt, wat zou er dan de definitieve rekenregel zijn geweest? En dan gaat hij dat berekenen en dan zegt hij bijvoorbeeld: 'je hebt 500 euro te veel loonheffing afgedragen'. DIE 500 EURO ZET SSD DAN OP DE VORDERING.'
Belangrijk: SSD/ gemeente kan nooit meer loonheffing terughalen als dat er verstrekt is.
De werkgeversheffing krijgt gemeente eigenlijk terug, op het moment dat die client gaat terugbetalen op die bruto vordering, en dat boekt SSD niet op de uitkeringscummulatieven maar op een aparte cummulatieven: de ontvangsten vorige dienstjaren. Advies is om dat programma 1 x per jaar te draaien om te zorgen of alles goed staat.
Wat wil nou de belastingdienst? Die wil dat die werkgeversheffing op jaarbasis NIET negatief zijn.
Wetgeving: Met de belastingwetgeving van 2006: expliciet toestemming gekregen om dat WEL terug te vorderen. Want als we die werkgeversheffing niet terug kunnen krijgen dan zouden de bruteringsregels anders moeten.
Zvw = werkgeversheffing.
Heeft kinderalimentatie invloed op fiscaal loon bij de bijstand? Instinker: partneralimentatie belast, kinderalimentatie onbelast. Maar heeft het invloed op fiscaal loon? Het antwoord is ja: onbelast voor degene die het ontvangt, maar wordt gekort op bijstand (net als onbelaste kindercombinatie opvang oid): uitkering wordt lager, dus minder fiscaal loon dus wel invloed.
MAAR partneralimentatie (via 05 900 gaat het omlaag) maar via 05 980 om het weer omhoog te brengen omdat de afspraak is dat gemeente de loonheffing betaald. Op partneralimentatie. Dus gemeente gaat kunstmatig het fiscaal loon weer omhoog brengen.
In SSD: Maximale premieloon. Bruto fiscaalloon, de basis waarover werkgeversheffing berekend wordt. Waarom staat dat opgenomen in SSD want iemand in de bijstand heeft toch nooit 6000 euro bruto? Dat haalt toch nooit iemand?
Voorbeeld waar een client dit wel haalt: max. Premieloon geldt per jaar. En dan gedeeld door twaalf is dat per maand. Stel: client heeft recht op uitkering van 4 maanden en 2 dagen van vorig jaar. De boekingsdatum is bepalend: alles wat jij dit jaar betaald krijgt valt in jouw belastingaangifte van dat jaar. Dus: als iemand met terugwerkende kracht betaald krijgt, en er is bv ook nog geen lhk (dat kan namelijk ook) dan is de werkgeversheffing nul over alles wat je vorig jaar gekregen hebt (uitkering beeindigd, geen vt, geen lhk). Dus: geen werkgeversheffing.
Systeemcorrecties: Dus het kan ook nog zijn dat het systeem via bijstandspercentage 21% heeft berekend en op het einde van het jaar blijkt maar twee dagen recht en dan houd je maar een paar honderd euro over en als je dan maar een paar duizend euro heb gehad ga je over die paar 100 euro werkgeversheffing berekenen.
Er is een programma waar alles om draait: herberekening loonheffing regeling 00. We willen uiteindelijk dit programma zo goed mogelijk laten draaien en eigenlijk maar 1 keer. Dus niet 3 keer! Als het achteraf niet goed blijkt te zijn draaien we dit programma.
Stap 0 van het jaarwerk, zet in SSD-beheer vinkjes antidateren. liefst geen journaalposten van december doorzetten naar volgend jaar, heeft met antidateren te maken: staan er boekingen verkeerd of niet de jp van december is niet compleet.
Controleer ook meteen of 'terugboeken dagen' bij de IOAW uit staat. En doorboeken zet ik aan. Terugboeken dagen heeft met loonheffing te maken, hoeft bij IOAW nooit gevuld worden. Check ook even of alles met de herberekening is aangemaakt. Dan kan je groep 2 en 3 terugboeken, journaalposten bekijken. Alleen de fiscale delen mogen gejournaliseerd worden: 16 en 17.
Journaalpost Correcties: Als er bij IOAW verschil is in JP dan corrigeer je dat in het vakantiegeld. Soms treedt er een afrondingsverschil in als je in stukjes betalen. Pas in op kolom 09 in boeking van SZUKHIS en dan JP opnieuw opbouwen.
Na het terugboeken zouden de scripts opnieuw gedraaid kunnen worden en dan is het interessant als dezelfde scripts opent en nagekken wordt wat er klaar staat om terug te boeken: alles wat 'ja' is zou verdwenen moeten zijn. Belangrijk voor jaarwerk is focus op alles wat terug geboekt moest worden.
Nu kunnen alle cummulatieven opgebouwd worden voor alle regelingen. Belangrijkste is: waarom doet SSD opnieuw opbouwen cumulatieven bij regeling 00? Opbouwen cummulatieven doet niet alleen dingen opbouwen (optellen) maar hij berekent ook de leeftijdsindicaties. Terugboeken wil dat nog wel eens beïnvloeden. Daarom is het opbouwen van belang na het doorboeken.
Belangrijk: Kijk in dat script goed na of je de juiste jaartallen weg gooit. Select distcinct kode_regelingfrom szdoscum1 Szdoscum0 en szdoscum6 Kan je controleren of alle cumulatieven erin zitten.
Na het opbouwen van de cummulatieven zouden de achteraf scripts gedraaid kunnen worden. Kan gemeente door het jaar heen ook draaien. De loonaangifte controles en de journaalposten bijvoorbeeld.
Het script genereert een totaaloverzicht om te controleren of de opbouw van cumulatieven (stap 8 in het jaarwerk) correct is verlopen, voordat je verder gaat met de volgende stappen.
Het vergelijkt gegevens uit verschillende tabellen voor elk loonheffingsnummer:
Genereert 4 soorten overzichten:
jw_totaal_overzicht_12. Het script genereert een totaaloverzicht om te controleren of de opbouw van cumulatieven (stap 8 in het jaarwerk) correct is verlopen, voordat je verder gaat met de volgende stappen. Na het draaien van dit script vergelijk je kolommen D, E en F (of andere relevante kolommen). Als de bedragen tussen de verschillende systeembronnen overeenkomen, is de cumulatief-opbouw geslaagd en kun je verder met het jaarwerk.
Alle lichten op groen? Door naar stap 10.
We hebben terug geboekt, we hebben opnieuw opgebouwd, nu negatieve cummulatieven draaien. Doel: controle op aanwezigheid van negatieven. Een client heeft een deel negatief en deel positief maar totaal is positief? Jaarwerk kan doorgaan. Als iemand ergens negatief staat, en in andere dossiers positief: waarschijnlijk naar verkeerde dossier terug geboekt. Stel er staat er eentje negatief en die heeft geen levensonderhoud , hoe kan die gecorrigeert worden? Vordering raadplegen, en dna als volgt op 0 zetten: In versie 19 nieuw: Bij de uitvoering van het jaarwerk is het soms noodzakelijk om het bedrag dat teruggeboekt wordt naar de uitkering (bedrag doorboeken BEDRAG_UA) over het lopend dienstjaar te muteren. Bijvoorbeeld als bij het uitvoeren van de ‘jaarwerkscripts vooraf’ blijkt dat er meer uitkering teruggeboekt gaat worden vanuit debiteurenontvangsten dan dat er als uitkering is verstrekt, of als bij het programma afdrukken ‘Negatieve cumulatieven’ blijkt dat bedrag netto (levensonderhoud belast en/of bijzondere bijstand belast en/of premie belast en/of alimentatie belast) lager is dan 0,00 (dus negatief is). Eigenlijk zou je die debiteuren op moeten schrijven en terugkoppelen naar de uitkeringsadministratie: er is teveel terug geboekt, kan allemaal redenen hebben maar misschien heeft deze teveel betaald. Krijgt wellicht dus nog wat geld die client... Hoe kan je zien waar dat bedrag vandaan komt? Optie 1 debiteur gekoppeld aan het dossier. Je kunt ook nog in uitkeringshistorie terugboeken opzoeken en daar staat het veldje debiteurnr bij. Hoe kan je terugboeken? via de debiteur, via bedrag_ua dat is het antwoord. Eigenlijk kan je ivm tijd als een kip zonder kip naar 0 zetten! Schrijf debiteurnrs op, UA moet het maar uitzoeken.
Vraag na bij gemeente: is er al aansluiting, hoe zit dat bij bij deze gemeente? Niet teveel mee bezig zijn is het advies. Als het JP's zijn die door boekingen die niet goed staan, kan het invloed hebben op jaarwerk. Jaarwerk consultant heeft al journaalposten over hele jaar gedraaid. Advies doe dat ook tijdens db controle. In ssd beheer > afdrukken jp's , alleen totalen. En dan onder aan de streep: is het in evenwicht of niet in evenwicht? Je kan zoeken naar 'NIET BEKEND'. Tip: tijdens DB controle je ziet een verschil: geef gemeente de opdracht om het te zoeken en op te lossen.
Stel 1 vraag: heb je berekeningsconstanten met script of hand erin gezet? Of : zullen we voor de zekerheid dat script draaien?
Werking van het systeem Het systeem haalt de gegevens uit het SSD-dossier van de cliënt. Alleen dossiers met een belastingcode, die als belast zijn gemarkeerd, komen in aanmerking voor een jaaropgaaf en worden meegenomen in de herberekening van de loonheffing. Dit proces is specifiek voor regeling 00. Gegevensbronnen en logica Voor de bepaling van de extern benutte loonheffingskorting (LHK) raadpleegt het systeem de inkomstenhistorie, waar het belastbaar loon staat. Op basis hiervan vult het het scherm Basis Fiscalisering. In dit scherm kunt u het saldo in dagen (plus/min) en het recht op LHK zien. De getoonde gegevens komen uit de zogenaamde FIS-tabellen: FISPLHK, FISPCUM en FISJCUM. Het gaat hier specifiek om de bevroren eindstand van de loonheffingsherberekening, die in de *_r-raadpleegtabellen staat. Verwerking van nieuwe berekeningen Wanneer er voor hetzelfde jaar een nieuwe bruteringsberekening wordt gestart door aanvullende inkomsten in te voeren, voert het SSD-systeem een volledig nieuwe berekening uit. De bestaande raadpleegtabellen blijven hierbij behouden. Deze tabellen worden pas verwijderd tijdens het opbouwen van de cumulatieven.
Voor de vastlegging van de loonheffingskorting (LHK) verzamelt en verwerkt het systeem gegevens uit de tabellen HISCUM en DOSCUM. De uiteindelijke eindstand van de herberekening loonheffing wordt per persoon vastgelegd in de tabel SZBPDOSCUM0. Vervolgens verdeelt het systeem dit totaal over alle bij de persoon gekoppelde (belaste) dossiers (DOSCUM). Voor het jaar waarop de jaarwerkzaamheden worden uitgevoerd, is de tabel SZBPDOSCUM0 aanvankelijk leeg en wordt deze in deze stap gevuld.
Het systeem doorloopt verschillende stappen, te beginnen met het terugboeken van dagen waarop geen recht bestaat. Dit gebeurt aan de hand van de optie 'terugboeken dagen', waarbij op basis van de verhouding binnen de totale schuld de betreffende dagen worden teruggeboekt. Deze actie is zichtbaar in de dagen min en dagen fiscalisering. Vervolgens worden alle loontabellen geleegd (de FIS-tabellen zonder *_R). Daarna verzamelt het systeem gegevens door alle debiteuren te doorlopen om te bepalen waar de persoon als klant of partner geregistreerd staat. Alle netto belaste bedragen worden bijeengerekend, wat ook onderaan het scherm wordt weergegeven. Hierna verwijdert het systeem de loonheffingskorting (LHK) voor perioden zonder recht, uitgaande van de regel dat zonder code 10 990 ook geen recht op LHK bestaat. Ten slotte past het systeem de definitieve rekenregel toe. Een belangrijk punt is dat het systeem in deze fase de tabel SZBPDOSCUM0 vult. Om tijdens de uitvoering van dit programma te controleren of het nog actief is, kunt u de processtatus monitoren.
Kijk of SZBPDOSCUM0 nog draait: select sum(FISCLN_JW) from szbpocum0 where jaar =202501. Belangrijk om te controleren na 2 uur of het nog draait.
Van stap 8 weet je een beetje wat het fiscaal loon was. Het systeem gaat langzaam naar dat bedrag. Let op: alleen fiscaal loon van regeling 00.
Na afronding van deze taak genereert het systeem een verslag met resultaten. Het kopieert de eindstand naar de fiscaliseringstabellen (de tabellen met '_R'). Vervolgens worden de rekenregels van de Belastingdienst toegepast, waarbij onder andere de cumulatieven worden bijgewerkt. Dit proces resulteert in twee soorten runs, vergelijkbaar met een 'run 8 en een run 9'. Het terugboeken van dagen (de negatieve dagen) vindt plaats in de laatste run. Uit de herberekening loonheffing komen twee verslagnummers: één voor het terugboeken van dagen en één voor de bedragen. Het verslag toont per dossier de uitgevoerde berekening. Een hoog bedrag aan loonheffingskorting is op zich niet fout; dit kan bijvoorbeeld wijzen op een dossier met een partner. De focus ligt niet op de gedetailleerde lijst, maar op de totaalbedragen onderaan. Deze totalen kunnen worden gekopieerd naar bijvoorbeeld Excel. Vervolgens wordt via 'Afdrukken cumulatieven' een lijst gegenereerd voor het specifieke verslagnummer van de herberekening loonheffing voor regeling 00. Deze lijst toont de gecorrigeerde totalen per cumulatief, exclusief loonheffing en werkgeversheffing, en geeft alleen de financiële consequenties per groep weer. Daarna wordt via 'Afdrukken journaalpost', eveneens op totaalniveau en met hetzelfde verslagnummer, een journaalpost gegenereerd. Het totaalbedrag (debet/credit) van deze journaalpost moet overeenkomen met de som van de loonheffing en werkgeversheffing uit de overzichten. Ter controle: het totaal uit de cumulatievenlijst, vermeerderd met de loonheffing en werkgeversheffing, moet gelijk zijn aan het totaal van de journaalpost. Een kleine afwijking van enkele centen is mogelijk. De cruciale controle is dat de totalen van de cumulatieven overeenkomen met de journaalpost. Het gaat om zeven kolommen. Het totaalbedrag van deze kolommen wordt opgeteld en vergeleken met de totalen uit de cumulatieven en de journaalpost. Pas als deze overeenkomen, kan worden doorgegaan naar de volgende stap.
Er is een specifiek script wat niet uitgeleverd wordt. Dat script voegt 2025 met juiste percentages, en dan obv de bpdoscum0 verzamelt het script dingen (heel veel genestelde scripts) en uiteindelijk berkent het relevante gegevens , het genereert een een excel lijst waarin staat: dit is de loonheffing voor dit dossier , dit is de berekende loonheffing voor dat dossier. Inhoudelijke controle: Zijn er belaste uitkeringsdossiers 2025 in szdoscum0 met belaste bijstand (levensonderhoud, bijzonder en alimentatie) ongelijk aan 0, waarin in de bijbehorende SZBPDOSCUM0 2024 de velden FISCLN_JW, LOONH_JW en ZVW_WGHEF_JW allemaal nog 0 zijn. Deze dossiers zijn mogelijk niet meegegaan met de herberekening loonheffing. U kunt dit controleren door het volgende script: Select a.jaar ,a.clientnr ,a.kode_regeling ,b.dossiernr ,a.FISCLN_JW ,a.LOONH_JW ,a.ZVW_WGHEF_JW from szbpdoscum0 a, szdoscum0 b where a.doscum0 = b.doscum0 and a.jaar = 2025 and a.jaar = b.jaar and nvl(b.netto_bel,0)+nvl(b.bb_belast,0)+nvl(b.mee_bel_ali,0)<>0 and (b.ind_belasting = 1 or b.ind_svw_zfw = 'P') and nvl(a.FISCLN_JW,0)= 0 and nvl(a.LOONH_JW,0)=0 and nvl(a.ZVW_WGHEF_JW,0)=0Voordat u verder gaat dient u deze afwijkingen eerst te herstellen, zodat szbpdoscum0 wel juist gevuld is.
Zie rode alinea voor specifiek script om overzicht te creeren in deze stap. Het is mogelijk dat iemand een fiscaal loon heeft, maar geen werkgeversheffing. Dit kan voorkomen wanneer er geen loontijdvak is; zonder loontijdvak is er echter ook geen benutting van de loonheffingskorting (LHK), wat leidt tot een maximale loonheffing. Een situatie met een beetje loonheffing en geen werkgeversheffing is dus denkbaar. Een situatie waarbij zowel de loonheffing als de werkgeversheffing volledig nul zijn, is echter verdacht. Dit kan duiden op een onvoltooide herberekening loonheffing voor het dossier, waarbij gegevens wel in DOSCUM staan maar niet correct zijn verwerkt in BPDOS.
Wanneer iemand de AOW-gerechtigde leeftijd bereikt, worden twee berekeningen gemaakt. Alle verwerkingen vanaf de eerste dag van de betreffende maand vallen onder het lage tarief. Het systeem plaatst de dagen daarna in een aparte cumulatief (BPDOSCUM). Een probleem kan ontstaan als in één periode_betrekking (bijvoorbeeld juli) zowel de indicatie leeftijd 0 (onder AOW) als 1 (boven AOW) aanwezig is. Dit is theoretisch correct als er boekingen zijn vóór en ná de ingangsdatum binnen dezelfde maand. Het programma 'herberekening loonheffing' kan in één boeking echter slechts één waarde (0 óf 1) voor deze indicatie verwerken, wat tot fouten leidt. De oplossing is om vanaf de ingangsdatum van de AOW (bijvoorbeeld 1 juli) alle volgende perioden eenduidig op indicatie 1 te zetten. Dit kan door middel van SQL-manipulatie van de tabellen BPDOSHIS, UKDOSHIS en BPDOSCUM. Na deze correctie moeten de cumulatieven opnieuw worden opgebouwd en moet de herberekening loonheffing opnieuw worden gestart. Dit probleem komt sporadisch voor.
Na uitvoering dient u de totaalbedragen te controleren en te verifiëren of alle dossiers daadwerkelijk zijn berekend.
Stap 13 (herberekening loonheffing) gedraaid.
Het printbestand open je, je scrollt naar beneden naar de totalen. Je TYPT de waarden over in excel (heeft te maken met printbestand en het meenemen van extra nullen/ datatype, je kan ook gegevens > celeigenschappen > getal met twee cijfers achter komma). Als volgt:
LHK uitk. LH.Bijst. LH.Aliment LH.Aliment LH BB ZVW ZVW WGH ZVW WGH BB
1875582.05 -169588.48 -571.04 -2248.59 0.00 -12433.95 0.00 -146.15
• Draai cummulatieven lijst, kopieer / plak verslagnr uit herberkening loonheffing (stap 13). Geen data invullen, alleen verslagnr.
• Draai journalpost, vul ALLEEN verslagnr in kopieer / plak verslagnr uit herberkening loonheffing (stap 13).
Scroll helemaal onderaan in de JP. Kopieer en plak het totaal en totaal generaal ook in het Excel werkblad:
Totaal -19815.56 -19815.56 Totaal generaal -184988.18 -184988.18
Is de optelsom van totaal generaal (JP) hetzelfde als de optelsom LH.Bijst. + LH.Aliment + LH BB + ZVW + ZVW WGH + ZVW WGH BB (printbestand herberekening loonheffing)?
Ja is goed. Nee, je moet op zoek naar de fout.
Scroll helemaal naar onderen in het printbestand wat SSD genereert als je de cummulatieve opbouwt. Selecteer en kopieer de volgende velden:
Dagen : 0 Uitstroompremie : 0.00 Inhoudingen voorschotten : 0.00 Basisbedrag : 0.00 Fiscaal loon : -172408.11 Inhoudingen dienst : 0.00 Toeslag : 0.00 Premieloon : -172408.11 Inhouding debiteur : 0.00 Verlaging basis : 0.00 Max. premieloon : 0.00 Inhouding opboeking deb. : 0.00 Verlaging toeslag : 0.00 Belaste alimentatie : 0.00 Inhouding crediteur : 0.00 Maatregel : 0.00 Loonheffing : -169588.48 Kosten onderzoek derden : 0.00 Inkomsten : 0.00 Loonh. bel. alimentatie : -571.04 Kstn.beg.derden,voorber. : 0.00 Inkomsten registr. : 0.00 Loonheffing premie : 0.00 Kstn.beg.derden,1e jaar : 0.00 Bijzonder : 0.00 Loonheffing bijzonder : -2248.59 Vakantietoeslag : 0.00 BB belast : 0.00 Eindheffing : 0.00 Correctie reservering VT : 0.00 Incidenteel : 0.00 Inkomsten bijz.bijstand : 0.00 Uitbetaald VT : 0.00 Ontvangsten : 0.00 Inhouding ZVW AB : 0.00 Uitkering belast : 0.00 WG-heffing ZVW AB : -12433.92 Inhouding ZVW BB : 0.00 Netto uitbetalingen : 0.00 WG-heffing ZVW BB : -146.15 Vergoeding ZVW AB : 0.00 Netto terugboekingen : 0.00 Ontv. bijzonder : 0.00 Vergoeding ZVW BB : 0.00 Inkomensbeheer : 0.00
Komen de bedragen overeen met de totalen van het printbestand herberekening loonheffing?
Cumulatieve printbestand herberekening loonheffing Loonheffing LH.Bijst. Loonh. bel. alimentatie LH.Aliment WG-heffing ZVW AB ZVW WG-heffing ZVW BB ZVW WGH BB
Enz. Als de bedragen overeen komen klopt het en kan je doorgaan.
Totaalbedragen zijn gecontroleerd, er is gecontroleerd of er dossiers helemaal niet berekent zijn.
Dan draai je de negatieve cummulatieve opnieuw. Key2Uitkeringen > Jaarwerk > Negatieve cumulatieven. Na de herberekening loonheffing van regeling 00 dient dit lijstje leeg te zijn.
Verwerken bruto ontvangsten vorige dienstjaren. Key2Uitkeringen > Loonaangifte > Ontvangsten vorige dienstjaren. Je kunt altijd tussendoor de achteraf scripts draaien, dat totaaloverzicht. Na de herberekening loonheffing bijvoorbeeld. De loonaangifte en jaaropgaven heb je nog niet gevuld, ontvangstenvorige dienstjaren ook niet maar wel de herberekening loonheffing. Hoeft niet.
Je hebt samen met de klant alle debiteuren beoordeelt: welke staan klaar met ontvangsten op bruto terugvorderingen, wat is UWV? Wat mag niet wat mag wel wat zijn uitbetalingen. Nu vraag je: "hoe wil je dat ik dat draai?" Je kan het programma op 2 manieren draaien als je het hele jaar nog niet gedraaid hebt en je wilt maar 1 boeking kan je over hele jaar invoeren. Als je dat doet, draait hi alle ontvangsten in 1 keer. Er is echter een apart raadpleeg scherm voor debiteuren: historie vorige dienstjaar cumulatieve. Zeg je : ik ga twaalf keer draaien dan toont het scherm het per maand. Krijg je wel 12 verslagnummers. Grootste fout die je hier kan maken: niet controleren van te voren, 'op lijst draaien' (niet handig). Juiste data gebruiken!
Ontvangsten vorige dienstjaren genereert een cumulatieve lijst. De werkgeversheffing wordt eigenlijk gejournaliseerd. Je moet weten: er komt WEL een jp voor werkgeversheffing maar die werkgeversheffing staat niet opuitkeringssscummulatieve. Dus als gemeente aansluit op financieel pakket moet Ontvangsten vorige dienstjaren apart. De gemeente lelystad heeft dit program a 10 jaar lang gedraaid maar 10 jaar lang niet gejournaliseerd. Want: 'als we dat gaan journaliseren dan heb ik geen aansluiting met mijn uitkeringsscummulatieven.' Aldus lelystad. Met als resultaat anderhalve ton op een tussenrekening , journaliseren dus. Werkgeversheffing stat in ssd dus op 2 plekken: uitkeringscummulatieven en de debiteuren. Het fiscaal loon van de ontvangsten vorig dienstjaar gaat er van af, (want: vorige dienstjaar). Waarom staat er geen loonheffing bij ontvangsten vorig dienstjaar? Je berekent alleen de werkgeversheffing want de loonheffing zit op de brutoterugvordering. Het enige wat je hier boekt is de werkgeversheffing en het fiscaal loon.
Key2Uitkeringen > Loonaangifte > Vullen loonaangifte tabellen. Nu zitten we op een punt dat iedereen het jaarwerk zou kunnen doen... het echte denkwerk is al klaar.
Key2Uitkeringen > Jaarwerk > Opbouwen jaartotalen. Wat die gemeenten gaan doen: aansluiting zoeken. Dat doen ze namelijk elke maand (oktober, november, december dus ook). Maar: zijn er correcties die wij gedaan hebben hier en daar zijn dingen niet goed meegegaan in de oude en nu wel. Het kan zijn dat fiscaal loon in januari te laag was en dat gaat hij nu doorgeven. Advies: niet aansluiten in december per maand, maar over hele jaar. In december doet hij namelijk iets speciaals! Je zet dingen om van belast naar onbelast en hij gaat fiscaal loon corrigeren. Als je met SQL-dingen repareert: (van onbelast naar belast), je hele netto bedrag daar zit geen loonheffing op maar dat had eigenlijk fiscaal loon moeten zijn. Dus die nemen we mee. Dat moet ook. ZOEK AANSLUTING OVER HELE JAAR. In januari draait gemeente een lijst: JANUARI IS VERANDERD! Loonheffing zal niet veranderd zijn maar fiscaal loon kan veranderd zijn.
Op het moment dat jij de loonaangifte vult , staan er de standaard dingen in de database. Wat er in SSD kan staan: landcode niet bekend. Dan krijg je een F. Die moet je oplossen, eigenlijk ook door het jaar heen. Kan je (soms) ook na jaarwerk doen.
Kan je meteen doen, dan heb je alvast een bestand. Dan weet je wat je moet betalen. Maar ik wacht daar altijd mee. Daarom zeg ik: zijn er problemen met foutmeldingen: je kunt in de 12e maand een foutmelding krijgen: 'het is meer dan 4 maanden geleden dat er loonaangifte geweest is'.... NEGEREN! Bij samenstellen krijg je daarvan meldingen , bijn IOAW gaan we dat verwijderen. Ruud zegt: niet aanpakken. Na vullen zou je meteen naar opbouwen jaartotalen kunnen gaan. Weet iemand waarom je dit ook over 2023 kan draaien? Als ik namelijk opbouwen cummulatieven probeer te draaien dan zegt ie: mag niet. Kan je niet aanpassen. Omdat: als je met correctie eerder tijdsvak een oude loonaangifte zou corrigeren van 2023, dan kun je na die correctie, die klant –waar het over gaat- kun je opnieuw selectief die klant opbouwen. Dan maakt hij een nieuwe jaaropgaaf inclusief correctie. Dus ga je met eerder tijdsvak correcties doen: kun je ook van die oude jaren opbouwen en dan krijg je een nieuwe jaaropgaaf zichtbaar. Sterker nog: daarmee kun jij controleren of jij je correcties goed gedaan hebt. Want: je hebt je correcties gedaan en je wilt iets bereiken, als je dan opbouwen jaartotalen doet en je ziet dat het OMLAAG gaat terwijl het OMHOOG zou moeten gaan, dan weet je dat je niet goed gecorrigeerd hebt.
Zorg dat gebruikers geen inkomsten herberekeningen uitvoert. Oplossing? Printbestanden, herberekening opnieuw doen ALLEEN VOOR DIE DOSSIERS.
Samenstellen kan altijd, vullen niet!
Vroeger moest dat per regeling, nu kan je gewoon 2025 ingeven en dan sluit hij af. Als je dit programma draait vult hij in SZREGEL 202601 in dus als je 2025 afsluit dan zet hij daar 202601 in. Dat is dan ook meteen het probleem als ik iets opnieuw zou moeten doen , dan moet je dit met de hand openzetten en weer terugzetten. Belangrijk voor veegruns!
Stuurgegevens terugzetten. Als je afsluiten dienstjaar draait bewerkt SSD alle tabellen waar je iets mee hebt gedaan. Szdosvt Wat ik vergeten te vertellen ben: een van de eerste stappen is terugboeken dagen. Er is een tabel en daar staan de terug geboekte dagen in. Dus als ik dan kies , alles met de periode groter gelijk aan periode_betrekking >= 202501 Dit lijstje kun je naast het lijstje vooraf scripts: terugboeken dagen leggen. In grote lijnen zou dat overeen moeten komen. Soms doet hij helemaal niet terug omdat de 10 990 (geen belaste bijstand) boekt hij om die reden niks terug. In grote lijn zou dit kloppen moeten.
Duh.
HIJ KAN GAAN WIEBREN! Bij elke boeking die je doet moet je jaartal checken. Er kunnen meerdere uniface op de achtergrond lopen namelijk. Zouden er meer regelingen dan 00 en 06 in aanmerking komen voor jaaropgave? Voor welke regelingen gaan we jaaropgave draaien? Iig 00 en 06. Een oude regeling: ja: als er OUDE bruto terugvorderingen zin, bijvoorbeeld: regeling 2 van de WIJ. Als je daar terugvorderingen op krijgt dan krijg je voor die mensen een jaaropgave. CHECK DAT DUS! Sommige gemeenten zitten bij mijninkomen, die zien de jaaropagve meteen!
GT
Koppel de bruteringslijst terug naar de medewerkers. Er zijn gemeenten die niet bruteren op dat moment maar pas als alles nagekeken is. Bruteren zit op 2 plekken: dat zit bij debiteuren en bij het jaarwerk. Het bruteringsprogramma is het enige programma , als het dienstjaar is afgesloten en het staat al op 2026, is dit het enige programma waar je nog kan boeken op oude jaar. Sterker nog: als jaar nog niet is omgezt in geheugen dan kun je niet boeken in december vorige jaar. Men kan ook opnieuw jaar boeken. Informeer bij de klant: moet ik dit draaien? Doen jullie het? Is namelijk direct zichtbaar voor clienten. In welk jaar willen jullie het geboekt hebben?
Alleen netto belaste terugvorderingen over lopend dienstjaar ofwel het af te sluiten dienstjaar komen in aanmerking voor brutering. De Suite checkt of het dienstjaar in deze netto belaste terugvorderingen gelijk is aan het afgesloten dienstjaar (stap jaarafsluiting). Als men niet wenst dat netto belaste vorderingen gebruteerd worden, is het mogelijk om deze vorderingen uit te sluiten van brutering door het vinkje “Uitsluiten brutering” in het debiteurendossier aan te zetten.
Brutering openstaande vorderingen (Regeling 00/PW) De brutering van openstaande vorderingen kan worden uitgevoerd na de herberekening loonheffing. In tabel SZDEBADM geeft de rubriek dnstjr_vord het af te sluiten dienstjaar aan. Voorwaarde Het gebruikte periodenummer moet lager zijn dan de waarde in de rubriek afgesloten_tot (tabel SZREGEL). Bij een brutering in periode 202412 dient afgesloten_tot bijvoorbeeld minimaal 202501 te zijn. Gevolgen van uitgestelde brutering Zonder brutering blijft het vorderingensaldo netto. Correcties op aflossingen vinden dan ook plaats op basis van het nettobedrag. Dit is acceptabel aangezien de brutering uiteindelijk het saldo per 31 december verwerkt, zoals vastgesteld via de boekingsdatum in SZDEBMUT. Opmerking Een ogenschijnlijke tegenstrijdigheid kan ontstaan als een inhouding het saldo tijdelijk op nul zet. De brutering boekt dan alsnog het bruto saldo van 31 december, waardoor een saldo kan verschijnen na een eerdere nulstelling.
De achteraf scripts geven als output bestanden jw_lijst_te_bruteren_12.csv. Als er na de definitieve brutering nog vorderingen over blijven op deze lijst dient u deze vorderingen na te kijken en eventueel handmatig te bruteren of aan te passen. Mogelijke situaties: • Vorderingen zijn niet gebruteerd doordat er geen of geen belast uitkeringsdossier aan gekoppeld zit. Indien noodzakelijk met de hand bruteren. • Vorderingen zijn niet gebruteerd doordat de berekening van loonheffing negatief uitkomt. De loonheffing gaat omhoog in plaats van omlaag. Controleer of deze vorderingen ook op ‘Bruto’ zijn gezet. Het nettobedrag vullen bij de bijstandspersonen en de loonheffing met 0. • Vorderingen zijn niet gebruteerd doordat het vinkje ‘Uitsluiten bruteren’ aan staat. Deze zijn terecht niet gebruteerd. Deze vorderingen dienen op ‘Netto’ te blijven staan.
Het vervaardigen en afdrukken van jaaropgaven Programma: Key2Uitkeringen > Jaarwerk > Jaaropgave cliënt (via MDU) De gegenereerde gegevens dienen aangeleverd te worden naar de (ex)cliënten. Het vervaardigen van de jaaropgaven wordt via het sjabloon en bodydocument
Vervaardigen saldobiljetten Programma: Key2Debiteuren > Afdrukken > Saldobiljetten Nadat de vorderingen zijn gebruteerd kunnen de saldobiljetten vervaardigd worden. Het vervaardigen van de saldobiljetten wordt via het sjabloon en bodydocument met behulp van MDU uitgevoerd.
Opbouwen cumulatieven alle regelingen 2025 Programma: Key2Uitkeringen > Jaarwerk > Opbouwen cumulatieven Na het afsluiten van het dienstjaar, het afronden van het jaarwerk en het omzetten van het dienstjaar naar het nieuwe dienstjaar is het advies om voor het nieuwe dienstjaar te beginnen met de cumulatieven opnieuw op te bouwen. Dit om zeker te weten dat de cumulatieven goed staat en het overgeboekte openstaande vakantiegeld goed in de nieuwe cumulatieven aanwezig is. Het advies is om voor alle regelingen de cumulatieven op te bouwen.
GT
| Veld | Toelichting | Relevantie voor het jaarwerk | Herstelacties tijdens DB-controle of JW |
|---|---|---|---|
| Terugboeken dagen | Door dit vijktje aan te zetten, worden dagen als "geen recht" geboekt in Uitkeringshistorie HISCUM0 (veld: dagenmin). Gebruik dit alleen bij een volledig stopgezette uitkering, niet voor incidentele inkomsten (tenzij deze zo hoog zijn dat de norm wordt overschreden). Stap 13 (Herberekening loonheffing 00) start met dit terugboeken. Vervolgens: SSD boekt de dagen terug op basis van de schuldverhouding (zichtbaar in dagenmin/dagen fiscalisering). De FIS-loantabellen (zonder _R) worden geleegd. Gegevens worden verzameld en debiteuren worden gecontroleerd. Loonheffingskortingen (LHK) voor perioden zonder recht worden verwijderd. De definitieve rekenregel wordt toegepast en SZBPDOSCUM0 wordt gevuld. | Algemeen: Dit vinkje is alleen relevant voor bruto-uitkeringen (zoals Bijstand) en activeert het terugboeken van rechtendagen. Dit beïnvloedt de loonheffingskorting (LHK) en het fiscaal loon op de jaaropgaaf. IOAW/IOAZ (Regeling 6): Zet dit vinkje altijd UIT. IOAW is een netto-uitkering waar loonheffing niet van toepassing is. Controle: Controleer of de status van het vinkje (aan/uit) terecht is. Staat het onterecht uit, dan kan een handmatig aangemaakt vordering (zonder herberekening) leiden tot een onjuist hoge jaaropgaaf. Werking en consequenties Het aanzetten van het vinkje zorgt ervoor dat SSD bij de jaarwerkherberekening rechtendagen als "geen recht" boekt. Hierdoor wordt de LHK voor die periode verwijderd, wat resulteert in een hoger fiscaal loon (en een hogere naheffing voor de cliënt). Zonder terugboeking van dagen (vinkje uit) houdt SSD rekening met de volledige LHK, ook bij een terugvordering. Dit is voordelig voor de cliënt, maar niet voor de gemeente. Belangrijk voor tijdige jaarwerkrun Jaaropgaven zijn een momentopname. Wie zeer vroeg draait (bijv. 31 december), mist mogelijk gegevens over inkomsten en LHK-benutting van de laatste periode, wat leidt tot onnauwkeurigheden. | 1. IOAW Oplossing handmatig debiteur aangemaakt: bij IOAW is de voorwaarde voor het terugboeken een integrale herberekening maken, dat ga je dan alsnog doen. Een herberekening dus maken, en dan ga je de bruto-inkomsten inbrengen wat de bedoeling is dus (onderzoeken, in rapport/ beschikking). Inclusief VT het liefste. Eerst herberekenen, alle ontvangsten boeken van de ene naar de andere debiteur dan corrigeren met correctie schuld. 2. Oplossing handmatig debiteur aangemaakt: 3. Herberekening loonheffing (stap 13 stappenplan JW) doet als eerste iets met terugboeken dagen. Dus als je kiest: alles met de periode groter gelijk aan periode_betrekking >= 202501 Dit lijstje kun je naast het lijstje vooraf scripts: terugboeken dagen leggen. In grote lijnen zou dat overeen moeten komen. Soms doet hij helemaal niet terug omdat de 10 990 (geen belaste bijstand) boekt hij om die reden niks terug. In grote lijn zou dit kloppen moeten. Vinkje moet uitstaan bij regeling 6 en bij belaste bijzondere bijstand! |
| Dienstjaar vordering | Aanduiding van het jaar, waar de vordering betrekking op heeft. Niet periode betrekking maar de boekingsdatum is bepalend | Is dit dienstjaar niet gelijk aan het huidige dienstjaar, dan wordt de ontvangst niet teruggeboekt op de uitkering (via Doorboeken uitkeringsadministratie), maar wordt deze alleen op een lijst Ontvangsten vorige dienstjaren afgedrukt. Loonheffing en premies kunnen in deze situatie namelijk niet meer verrekend worden. Het dienstjaar is niet voor alle categorieën vorderingen relevant. | Kan het nu zijn Dat dit jaar anders is dan dat jaar? Stel ik betaal 28 december 2024 , dan valt hij obv boekingsdatum en fiscaal in het jaar 2024 , als ik die periode ga terugvorderen is het 2024. Maar stel nu: ik heb een uitkering geblokkeerd en betaal in januari 2025 dan is het fiscaal en boekingsdatum over 2025 en gaat hij mee met jaarwerk 2025. Alleen mag je over voorgaande jaren geen LHK benutten , dan mag je alleen over 2025 lhk benutten niet over 2024. Dan staan er geen dagen bij ‘dagen negatief’. |
| Bedrag doorboeken | Hier wordt het bedrag getoond dat nog open staat om door te boeken naar de uitkeringsadministratie. De gemeente bepaalt zelf met welke periodiciteit zij deze bedragen wenst door te boeken. Deze rubriek kan niet gemuteerd worden. Via het veld Vervangend kan is dit veld indirect wel muteerbaar. | dummy | dummy |
| Vervangend | Dit te autoriseren veld is alleen muteerbaar als het vinkje ‘Doorboeken’ in het debiteurendossier aanstaat. Bij het vullen van dit veld zal dit bedrag automatisch ook verschijnen bij het veld ‘Bedrag doorboeken’. Mochten er daarna toch nog nieuwe ontvangsten in dit lopend jaar worden ingeboekt, dan zal vanaf dat bedrag cumulatief doorgeteld worden. Het dringende advies is om door het lopend dienstjaar heen ‘BEDRAG_UA’ niet handmatig te veranderen. Dit bedrag dus alleen veranderen als dit noodzakelijk is bij het uitvoeren van het jaarwerk. Omdat dit eigenlijk alleen nodig is bij het uitvoeren van het jaarwerk, is het advies om dit nieuwe veld alleen te autoriseren voor de medewerkers die het jaarwerk uitvoeren. Dus niet autoriseren voor overige medewerkers van de administratie. Bij het draaien van het programma ‘Doorboeken Uitkeringsadministratie’ zullen beide velden op 0,00 gezet worden. Mocht er desondanks na doorboeken nog een bedrag in het veld ‘Bedrag doorboeken/Vervangend’ staan, dan kan dit veld leeggemaakt worden (bijvoorbeeld m.b.v. de backspace-toets). Dat geldt ook voor het programma ‘Afsluiten Dienstjaar’. | dummy | dummy |
| BEDRAG_UA | Hier wordt het bedrag getoond dat nog open staat om door te boeken naar de uitkeringsadministratie. De gemeente bepaalt zelf met welke periodiciteit zij deze bedragen wenst door te boeken. Deze rubriek kan niet gemuteerd worden. | Als je inkomstenverrekening gebruikt (inkomsten mogen tot zes maanden na het verkrijgen hiervan verrekend worden) dus het kan OVER een dienstjaar heen gaan. Dus als je een inkomstenverrekening van november inbrengt en dan zes maanden (en dan dec, jan, feb etc.) dan gaat hij een stukje over het dienstjaar heen. Het recht van jan en feb gaat hij verrekenen met inkomstenverrekening die over een hele andere periode gaat maar dat mag. En vervolgens verstrekken wij die uitkering MAAR VERVOLGENS komt er informatie naar boven dat die persoon helemaal geen recht heeft op een uitkering. Dan gaan we terug vorderen. Maar met dat recht is ook de inkomsten verrekend. Die staat er nog.... die kan ik niet intrekken.. Dat stuk staat dus negatief! 'eigenlijk' zou je die ook moeten terug halen bij de klant WANT je hebt het verrekend met iets, maar dat zit natuurlijk al in dat totaal recht. Je kunt discussie voeren: je hebt niks gegeven maar moet je het dan toch terug willen vorderen? Je moet hiermee iets doen. Je kan het terugboeken en achteraf iets doen. Maar je kunt ook van te voren zeggen: met SQL bedrag_ua = het minbedrag wat er in deze gevallen staat haal je van kolom O. | 1. Bij de uitvoering van het jaarwerk is het soms noodzakelijk om het bedrag dat teruggeboekt wordt naar de uitkering (bedrag doorboeken BEDRAG_UA) over het lopend dienstjaar te muteren. Bijvoorbeeld als bij het uitvoeren van de ‘jaarwerkscripts vooraf’ blijkt dat er meer uitkering teruggeboekt gaat worden vanuit debiteurenontvangsten dan dat er als uitkering is verstrekt, of als bij het programma afdrukken ‘Negatieve cumulatieven’ blijkt dat bedrag netto (levensonderhoud belast en/of bijzondere bijstand belast en/of premie belast en/of alimentatie belast) lager is dan 0,00 (dus negatief is), releasenotes versie 19." 4. 2. ´controle_debvul_foutief´ is een script , komen meerdere output lijsten uit. Die ga je beoordelen: je gaat op zoek naar fouten in de database. O.a.: wordt er niet meer terug geboekt dan dat er aan uitkering verstrekt is? Maak bijvoorbeeld een filter op de lijst: alles waar vinkje 'doorboeken aanstaat' alles wat onbelast staat: is niet goed. Onbelast kan namelijk niet in dit geval. Mogelijke oorzaak van deze fouten: gemeente gebruikt geen herberekening maar boekt dit handmatig op. We hebben nog een script dat heet: jw_ctr_bedrag_ua.sql mag nooit gevuld zijn. Als je bij bedrag UA dat bedrag hebt veranderd, die debiteuren komen op deze lijst. Als dit csv bestand leeg is betekend het bedrag_ua precies aansluit op de netto ontvangsten van dit jaar met dd_referentie in SZDEBMUT (ontvangsten op de debiteuren) - datgene wat al doorgeboekt is (als ze elke maand doorboeken) . Als er wel een record naar boven komt is BEDRAG_UA niet goed. Ooit gebeurde het dat BEDRAG_UA niet goed bijgewerkt werd, zolang dit script leeg staat het goed. Helemaal vol? FF Rob bellen. |
| 6 | dummy | dummy | dummy |
| 7 | dummy | dummy | dummy |
| 8 | dummy | dummy | dummy |
| 9 | dummy | dummy | dummy |
| 10 | dummy | dummy | dummy |
Bel Rob.