IT-systemen van Belastingdienst pas in 2029 klaar voor stelselwijziging

De Belastingdienst heeft bekendgemaakt dat de geplande modernisering van zijn IT-infrastructuur vertraging oploopt. Waar eerder werd gestreefd naar een voltooiing in 2028, zullen de computersystemen nu pas in 2029 gereed zijn voor een grootschalige stelselwijziging.

De vertraging is het gevolg van een herprioritering binnen de Belastingdienst. IT-personeel moet worden vrijgemaakt om urgente problemen rondom de box 3-belasting aan te pakken. Deze kwestie, die voortvloeit uit een recente uitspraak van de Hoge Raad, vereist dat bepaalde spaarders en beleggers te veel betaalde rendementsbelasting terugkrijgen.

Folkert Idsinga, staatssecretaris van Financiën, zegt dat de herstelwerkzaamheden na de Hoge Raad-uitspraken prioriteit krijgen. "We moeten nu een nieuwe planning aanhouden", zegt Idsinga in een brief aan de Tweede Kamer. De Belastingdienst kampt al jaren met verouderde softwaresystemen en een tekort aan ict'ers met de benodigde expertise. Dit maakt het doorvoeren van wetswijzigingen in de systemen 'buitengewoon complex', volgens Idsinga.

Reacties (137)

[Lock859]

Als programmeur die ook werkt in een systeem die elk jaar hevig te maken krijgt met wet- en regelgeving, vooral in de zorg, Laatst hadden we een overleg tussen VWS en alle betrokken partijen en daar kwam uit de koker dat er _36_ projecten tegelijkertijd liepen bij het VWS voor het 'verbeteren' van de automatisering rondom de ICT. Daar sta je dan met je mond open. Daar is gewoon NIET tegenop te programmeren. Software is per definite al oudbollig. De snelheid waarmee de wereld veranderd is enorm. Los van het bijhouden van alle wet- en regelgeving en alle processen rondom het domein waarin je werkt, heb je nog met een legio aan andere veranderingen en moderniseringen te maken. Denk aan alles in nomad/docker krijgen voor high availability, maar ook security fixes en de hele devops rondom applicaties met het predicaat; 'het wordt makkelijke voor de ontwikkelaar'. Realistisch gezien betekend het veelal een enorme investering aan kennis, voor een hele grote groep mensen. En ja sommige dingen worden makkelijker, maar veelal krijg je er gewoon weer nieuwe uitdagingen voor terug. Nieuwe dingen die je moet leren in je al beperkte tijd.

Ik heb het te doen met de ontwikkelaars bij de belastingdienst die dit waarschijnlijk nog op grotere schaal meemaken. Veelal ook nog externe partijen ingevlogen om alles te 'modernizeren'. Wat ook echt wel moet gebeuren, maar om het allemaal bij te houden. Het is echt veel tegenwoordig. Los van het domein. Want ook daar wil je mensen in hebben die dat echt in de vingers hebben. En ontwikkelaars die beide kunnen, inhoudelijk sterk een mening hebben en dit ook kunnen uitprogrammeren en kunnen inzien wat de impact op het geheel is. Die zijn zeldzaam en hebben vaak een traject nodig voor vele jaren om hier goed in te komen.

Ik hoop dat ze eruit komen en ook kritisch naar hun eigen bestand aan personeel kijken. Ik weet gewoon vanuit de vele verhalen uit de wandelgang. En ik weet zeker dat menig ontwikkelaar die wel eens gehoord heeft, dat daar echt mensen rondlopen die niet het beste voor hebben met de belastingdienst. Maar de randjes er niet eens van aflopen, maar ze opblazen met dynamiet. Er zit volgens mij genoeg talent, want anders was dit al geimplodeerd. Maar als je dit wil oplossen, kan dat niet alleen vanuit de techniek, maar moet je ook intern kijken. Hoe maken we het zo aantrekkelijk mogelijk voor top-talent.

[Gamebuster]

Naar mijn ervaring is het probleem heel snel groter naarmate de software groeit.

Stel je hebt een software pakket van "1 unit" in formaat, die kan je prima onderhouden met 1-2 ontwikkelaars.

Is die software opeens "2 units" en dan is 1 ontwikkelaar niet voldoende meer, en het houdt 2 personen fulltime bezig. Echter, 1 iemand is ziek of gaat met verlof, dus er komt een 3e bij. Die 3 developers beginnen te overleggen hoe bepaalde zaken gedaan moet worden. Meetings, overleg, standaardisering, etc. zorgt voor een vloeiende samenwerking, maar de snelheid neemt niet linear toe.

Neem daarna 4 units aan software. Nu heb je opeens de snelheid van 4 developers nodig, maar door overhead heb je er eigenlijk opeens 8 nodig. De samenwerking wordt minder efficient, developers komen en gaan, niemand kent het hele systeem uit zijn hoofd, standaarden en afspraken moeten afgedwongen worden met trage CI tools die soms niet helemaal meewerken, etc.

Nu moet die software weer groeien door nieuwe wetgeving, en ondertussen was er een ontslag ronde, problemen met funding, outdated code, legacy meuk, nieuwe technologieen etc en voor je het weet heb je een verdieping vol developers en krijg je niets meer gedaan.

[Skit3000]

Ik werk als ontwikkelaar bij een bedrijf waar we de basis van onze software enorm goed hebben geregeld, waardoor we min of meer 'functioneel' kunnen programmeren. Bij veranderende regelgeving passen we dus de logica-laag aan maar hoeven verder geen UI of DB aanpassingen te maken. Deze logica-laag is een abstractie van de (wetgevende) werkelijkheid. Natuurlijk zijn we nog steeds beperkt in hoeveel er in een bepaalde tijd voor elkaar kunnen krijgen, maar de benodigde tijd voor het onderhouden van bestaande modules is redelijk constant, dus we weten dat we elk kwartaal een aantal nieuwe modules op kunnen leveren en dan elke x-maanden iemand aan het team toe moeten voegen voor het onderhoud.

Ik snap dat de Belastingdienst dat nu niet kan want die zitten nog met enorme hoeveelheden legacy, maar wie nu een nieuw softwarepakket bouwt die regelgeving moet implementeren is niet handig bezig als je niet op een of andere manier voor een goede abstractielaag zorgt.

[Reactie gewijzigd door Skit3000 op 15 oktober 2024 22:53]

[Jonathan-458]

Als je ziet hoe de overheid met IT projecten omgaat en hoeveel deze partners verdienen, dan loont het ook niet om goed werk op te leveren voor deze partners.

Ze zijn een blok aan het been van de overheid en kosten enorm veel geld. Nu helpt het ook niet mee dat er ook mensen besluiten maken of constant zaken bij toewillen voegen die niet eens de kern snappen.

[barbarbar]

Daar zit wel een limiet aan natuurlijk. Als voor box3 eerst alleen de waarde op 31 december per rekening nodig was, en nu opeens een gedetailleerd logboek van elke aan- en verkoop per beleggingsinstrument (met opeens eigen belastingtarieven) , dan red je het niet met wat regeltjes aanpassen. Dan moet je alle koppelvlakken opnieuw gaan bedenken. Alle rekenregels bijlangs. Rekening houden met veel meer data, veel meer opslag, veel meer rekencapaciteit. Voor één individu die een enkele transactie doet per jaar wil dat wel, maar het moet ook kloppen voor de multimiljonair die meermaals z'n vermogen heen en weer schuift, daghandelaren die vanuit prive werken. Dan is het aanpassen van een paar regels gewoon niet voldoende, want je hebt überhaupt de data om de berekening te maken nog niet eens ergens gekregen.

[Gamebuster]

Ik droom van zulke mooie oplossingen, maar ik heb nog nooit een functionele applicatie op grote schaal in het wild gezien. Ik zeg niet dat ze er zijn, maar ik heb ze nog niet gezien. Ik zou ze wel graag willen zien, want tot op heden heb ik vooral gezien hoe het niet moet

[CivLord]

De Belastingdienst is met iets dergelijks bezig. Een framework om wettekst te vertalen in logische regels voor IT-systemen.
Geen idee of dit nog in de kinderschoenen staat of dat het onderdeel gaat worden van de nieuwe programmatuur die vanaf 2029 stelselwijzigingen mogelijk moet maken. Ik heb hier zijdelings iets over gehoord en het klonk veelbelovend.

[Florimon]

Het helpt natuurlijk ook niet echt dat de belastingdienst heeft aangekondigd weer strenger te willen gaan controleren op schijnzelfstandigheid, en het zich daarom nu niet meer kan veroorloven om niet zelf het braafste jongetje van de klas te zijn. Probleem is alleen dat de meeste zzp'ers in de IT (en waarschijnlijk in andere sectoren ook) het absoluut niet zien zitten om weer in loondienst te gaan (en misschien vooral niet bij de belastingdienst). Dus veel succes met het behouden danwel zoeken van mensen met de juiste expertise, die er brood in zien om voor vele jaren de boel weer op de rit te helpen.

[Tassadar32]

Mijn ervaring als detacheerder bij de belastingdienst: voornamelijk oude rotten die niet *willen* moderniseren en afstudeerders die niks anders konden vinden (vaak gebrek aan talent). De hele groep daartussen mist structureel. Ook word er veel te veel politiek bedreven door iedereen die geen developer is waardoor er aan teams getrokken word tot ze totaal onproductief zijn.

[Jonathan-458]

Het is echt de overheidsmentaliteit inderdaad. Politiek bedrijven is veel belangrijker dan daadwerkelijk dienstbaar en effectief het werk uitvoeren.

De toeslag affaire is natuurlijk een heel makkelijk voorbeeld maar het zal je toch niet verbazen dat wederom die zelfde belastingdienst een “nieuw” algoritme heeft ontworpen dat wederom door het AP is afgeschoten ivm veel al de zelfde gebreken als de oude.

De enige mensen die hier rijk van worden zijn de grote partners van de overheid en ingehuurde zzp’ers.

[Highlands]

Spot on, alle zzp’ers moeten eruit binnenkort dus nog grotere chaos. Nou ja, blik kenniswerkers uit India halen … die willen heel graag op de loonlijst …

[Vaevictis_]

Bij een uitvoeringsorganisatie die veel regels had spraken ze over multirealiteit dus iemand valt binnen een aantal meerdere regimes met wetten en regels. Dan krijg je dus uitzondering op uitzondering en kun je niet meer automatiseren laat staan software veranderen. Die hadden dus meer dan 50% uitval en moesten uitzendkrachten inhuren om het werk van ambtenaren te doen.

[groene henk]

Is het niet mogelijk om al die oude meuk te vergeten en met een team ernaast gewoon opnieuw te beginnen?
De onderhoudbaarheid wordt zo alleen maar slechter elk jaar totdat er geen nieuwe mensen te vinden zijn.

[Reactie gewijzigd door groene henk op 16 oktober 2024 00:30]

[Gamebuster]

Is het niet mogelijk om al die oude meuk te vergeten en met een team ernaast gewoon opnieuw te beginnen?

Groot risico, want die oude meuk heeft vaak (ongedocumenteerde) features die je nieuwe pakket dan niet heeft, en die oude meuk wordt dan parallel ook doorontwikkeld. Zo moet de nieuwe software ontwikkeld worden terwijl de oude meuk ook wordt doorontwikkeld.

Tenzij de nieuwe meuk gemaakt wordt door een nieuw team, is het ook aannemelijk dat je gewoon opnieuw ellende krijgt.

[CivLord]

Dat is zo'n beetje waar ze nu mee bezig zijn. Maar opnieuw beginnen is niet binnen een paar weken klaar. Dus moet je daarnaast het oude systeem blijven onderhouden, om het werk uit te kunnen blijven voeren. En wanneer de politiek zo beslist, moeten die oude systemen ook weer aangepast worden aan nieuwe wetgeving.
En omdat er niet een onbeperkt aantal programmeurs beschikbaar is (en er ook geen onbeperkte zak geld beschikbaar is om een blik nieuwe programmeurs open te trekken), zal er bij grote wijzigingen in de oude systemen programmeurs die aan het nieuwe systeem werken ingezet moeten worden op het oude systeem. Dat zorgt weer vertraging in de oplevering van het nieuwe systeem.

[scoobs]

Ligt het aan mij, of wordt de wijziging elk jaar met twee jaar uitgesteld?

[BoerBart]

Het gaat hier om vertraging van een jaar, niet omdat de IT afdeling problemen ondervind met de migratie, maar er zijn andere dingen met prioriteit tussengekomen. Iets dat, zeker met het gebrek aan (capabel) IT personeel, er al snel flink in hakt qua planning.

[wiseger]

Een belasting verhoging wordt ingevoerd door aan de bestaande knoppen te draaien, dus BTW een procentje omhoog. De kapper naar het hoge BTW tarief et cetera.

Hoef je geen code voor aan te passen, je past simpelweg parameters aan.

Wat de fiscus nu moet doen is iets heel anders. Men stelde altijd vanaf een bepaald vermogen gaan we uit van een vaste spaar-beleggingsmix en daarop slaan we u aan in box 3.

Fictief ter voorbeeld: Bezit u meer dan 80.000 euro maar minder dan 120.000 euro aan box 3 vermogen dan geldt 50 procent is sparen (in 2023 belast met 0,92 procent) en 50 procent is beleggen (in 2023 belast met 6,17 procent). En zo werden de mensen belast.

Door een uitspraak van de hoge raad mag dit niet. De fiscus moet dus met terugwerkende kracht per burger de daadwerkelijke beleggingsmix gaan vaststellen en de daarbijbehorende belasting. Dus meneer de Vries 72 procent sparen, 28 procent beleggen, meneer Janssen 100 procent sparen, meneer Pieterse 20 procent sparen, 80 procent beleggen et cetera.

Dat vereist allemaal code aanpassingen. Aanpassingen om de date van de mix te vergaren, vast te leggen in de database(s) en de berekeningen uit te voeren waarna er een verrekening met de reeds betaalde belasting zal moeten volgen.

[wild_dog]

Sorry maar, hoe lastig is dit daadwerkelijk?

Als je het totaal moet splitsen gebaseerd op een percentage, is dat wat lastige ja.
Maar de gegevens die de belastingdienst van mij (automatisch) krijgt, zijn rekeningen waar individueel van bekend is of het een spaarrekening of een beleggingsrekening is, en bij de 2e hoeveel dividend er uitgekeerd is en hoeveel dividend belasting ingehouden.

Het is dan toch zo simpel as rekeningen in categorie 1 belasten met x% en in categorie 2 met y%? Belasting berekenen voor de box3 optelling, niet na.

[Mellow Jack]

1 aanpassing is niet zo lastig. Als je tientallen jaren een jaarlijkse golf van dit soort kleine aanpassingen moet verwerken begint al een uitdaging te worden. Als je dan ook nog eens nooit tijd en geld krijgt om het e.e.a. fundamenteel te veranderen is het gewoon moeilijk.

[Vaevictis_]

Het is dus dat je meerdere regimes naast elkaar moet uitvoeren en controleren om mogelijke fraude. Dat is heel complex.

[Mellow Jack]

Niet alleen dat. Ook gewoon Frankenstein code. Zoals die Fallout game waar een character een train "aantrekt" om zo een trein scène te faken. Mijn beeld, als buitenstaander vd Belastingdienst is een beetje in deze context. Hun character kan 20 hoedjes op doen. Hoedje 17 is toevallig een trein. Schoen 20 v/d 40 is een vliegtuig. En jasje 31 vd 60 is een boot. Als je dus iets aan de boot wilt veranderen heeft dat direct impact op alle character, alle treinen en alle vliegtuigen

[J_van_Ekris]

En al die uitzonderingen met heffingen etc. sla je maar even over? Het basale werk is volgens mij redelijk simpel, maar het woud aan kortingen en heffingen omdat er weer een uitzondering voor een bepaalde situatie gemaakt moet worden maakt het dramatisch.

[FiberSam]

Dit is EXTREEM lastig. De belastingdienst beschikt helemaal niet over adequate info over de aard van het vermogen van burgers, laat staan het rendement. Die informatie wordt ook niet aangeleverd door banken, vermogensbeheerders etc. Belastingplichtigen kunnen dus (nu) gewoon maar wat opgeven, zonder dat de belastingdienst dit goed kan controleren. Ja, als je elke aangifte handmatig doorloopt door iemand met verstand van beleggen kan je misschien 80% controleren. Maar die mensen heeft de belastingdienst helemaal niet, laat staan voor die overige 20% complexe beleggingen. Er moet dus een systeem komen om het rendement onafhankelijk van de aangifte te kunnen controleren. Succes. Ik denk dat de belastingdienst dat over 20 jaar nog niet heeft.

[Matthijs Hoekstra]

Lastig stuk is dat veel software ook terug in de tijd moet kunnen en dus alle voorgaande regels ook moet ondersteunen, dus het is meestal niet alleen een getalletje aanpassen.

[fvdp89]

Klopt helemaal wat je zegt. Wat mij verbaast is dat de belastingdienst het zichzelf zo moeilijk lijkt te maken door het zo automatisch te willen als jij ook zegt.

Voor het overgrote deel van de mensen bestaat vermogen uit spaargeld en 'gewone' beleggingen waarvan de bank waar je die dingen aanhoudt in een jaaroverzicht keurig kan aanleveren wat je werkelijke rendement was. Voor het deel van de mensen dat in vastgoed en andere minder liquide zaken belegt werkt dit niet maar kan vanuit de wetgever worden opgelegd hoe het berekend wordt.
Vervolgens leg je de informatieverplichting bij de belastingplichtige en zou de last voor de belastingdienst met name bestaan uit het heffen van X% over het inkomen dat uit vermogen verdiend is. Alle automatisering die dit zo lastig maakt ben je dan kwijt tot men daar wél tijd voor heeft.

Met inkomen uit werk gaat het tegenwoordig vrijwel geheel automatisch, maar dat was tot een paar jaar geleden natuurlijk ook niet zo. En ook nu ben je als belastingplichtige verantwoordelijk voor de juistheid van de gegevens.

Ik maak het vast simpeler dan dat het is, maar als de complexiteit zit in al deze automatisering dan is de oplossing volgens mij om het de komende jaren gewoon niet te automatiseren en mensen het zelf aan te laten leveren.

[juulian]

Als je de automatisering stopzet, moet je direct ook het personeelsbestand uitbreiden om dit gat op te vangen. Je kan je voorstellen dat dat onhoudbaar is?

[fvdp89]

Ik zeg niet dat je moet stoppen met automatisering in het algemeen, maar dat je dit onderdeel (dat blijkbaar erg lastig te automatiseren is) de eerste paar jaar aan de belastingplichtige kan overlaten. Volgens mij interpreteer je mijn voorstel als dat de belastingdienst al die dingen handmatig moet gaan invullen en dat kan uiteraard niet.

Het lijkt er op dat hier gebeurt wat je vaker ziet: 'perfectie is de vijand van het goede':
- Wat we nu hebben is blijkbaar onvoldoende (de belastingdienst is niet in staat werkelijk rendement te belasten en dat is een probleem);
- De droomoplossing is dat ieders werkelijke rendement automatisch wordt ingeladen zodat je daar weinig tot niets voor hoeft te doen;
- Het bereiken van die droomoplossing gaat blijkbaar jaren duren.
- De vraag is dan: ga je in de tussentijd gewoon geen box 3 belasting meer heffen, of vraag je de belastingplichtigen om even mee te werken en het invulwerk voor je te doen?

Ik zou zeggen dat wat we nu hebben een '1' is, 'iedereen vult het even zelf in' zou ik een '6' noemen (doel wordt bereikt, maar het kost iedereen beetje moeite) en in de tussentijd kunnen we aan de '10' werken. Maar het lijkt er nu op dat bij alles wat niet perfect is gezegd wordt 'ja maar dat is ook niet perfect'.

[Gamebuster]

Hoef je geen code voor aan te passen, je past simpelweg parameters aan.

dan heb je sommige apps niet gezien die ik ben tegengekomen.

Ik heb nog applicaties gezien met hardcoded referenties naar 19% btw, en dingen als "if datum dan 19% anders 21%" enzo. En dan niet in een nette "BTWBepalerModuleClassFactory", maar gewoon verstopt in "MVC web app" controllers.

Natuurlijk zou ik zulke dingen nooit schrijven. Wat? Nee git blame doet het niet, geloof me maar, ik was het niet.

[Reactie gewijzigd door Gamebuster op 16 oktober 2024 08:21]

[CivLord]

Natuurlijk zou elke zichzelf respecterende programmeur dat nooit doen. Totdat kort voor het einde van het jaar de politiek nog even snel met een paar wijzigingen komt die vóór 1 januari in de systemen moet zijn verwerkt. Dan prak je die wijzigingen op elke manier in het systeem die vóór 1 januari de juiste uitkomst geven.
Natuurlijk maak je dan aantekeningen dat dat op een rustiger tijdstip op een normale manier opgelost moet worden. Maar dat moment komt nooit (of niet genoeg om al die aantekeningen af te werken) doordat andere zaken meer prioriteit hebben.

[uiltje]

Enige reden waarom de belastingdienst dat zou doen? Worden ze anders niet betaald ofzo? Zonder onderbouwing is dit slechts een complot theorie.

[denios]

Tuurlijk, vriend.
De 0% BTW op fruit die de politiek had goedgekeurd bijvoorbeeld, die kan niet volgens de belastingdienst.
Terwijl er gewoon een groep nultarief is.
Maar de verhoging van de BTW op hotelkamers van 9% naar 21% per 2026 is al ingeregeld hoor, geen enkel probleem.

Leg het maar uit.

[locke960]

Ik denk dat je schromelijk onderschat hoe ingewikkeld het kan zijn.

Zomaar een mogelijkheid:
Het basistarief is 21% al het andere is een uitzondering daarop.

Hotelkamers zijn nu 9%. Dat betekent dat er voor hotelkamers een uitzondering bestaat in de systemen. Alle processen, data-modellen, codes, interfaces met andere systemen, etc zijn al gedefinieerd om die uitzondering te behappen. Het is dan relatief eenvoudig om dat tarief naar 21% te zetten.

Fruit is niet gedefinieerd. Er bestaat alleen een voedsel categorie, waar fruit een onderdeel van is.
Om het btw tarief van fruit dan te veranderen naar 0% zul je dus eerst moeten definiëren wat fruit is. (Is een tomaat groente of fruit?) en vervolgens moet je het uit de voedsel uitzondering halen, en er een eigen uitzondering voor creëren.

Ik zeg niet dat dit de reden is, dit is alleen maar een gesimplificeerd voorbeeld om aan te geven hoe zoiets zou kunnen gebeuren. De realiteit is waarschijnlijk nog veel ingewikkelder.

[fenrirs]

Ook dit is puur willekeur. Je hoeft niet eens te definiëren wat groente en fruit is. Simpelweg stellen: onbewerkt-->0%, bewerkt-->9%. En ja, helaas gaat je voorbewerkte zakje gesneden sla dan niet naar beneden, maar dat heeft als positief effect minder plastic verpakking.

Zelfde geneuzel als met sinaasappelsap en toevoegen van een 'melk' component om het niet onder frisdrank te laten vallen.

De regels zijn gewoon te ingewikkeld en men maakt die ook te complex om maar aan alle randgevallen recht te doen.

[Renoir]

Eens dat te veel regels het complexer maken. Maar het is niet altijd zo simpel. Want taalkundig is de genoemde tomaat vaak een groente, plantkundig is het een vrucht. En maakt dat het dan fruit? Misschien wel ja. Groente hoeft niet per se een vrucht te zijn.

In 1983 besloot het Hooggerechtshof dat de tomaat voor de Amerikaanse wet als groente moest worden beschouwd. De rechtszaak werd aangespannen door een importeur die weigerde om importbelasting te betalen over zijn tomaten. Destijds werd er over groente wel belasting betaald en over fruit niet. Helaas voor de importeur besloot de rechter dat tomaten als groenten moesten worden gezien.

Zie hier wat er dan gebeurt. Het is niet zo'n makkelijke kwestie. En dan leven we ook nog eens in lobbyland waar de vereniging van producenten van zakjes voorgesneden ananas en meloen ervoor gaat pleiten dat ze toch als fruit worden gezien want gezond. Etc etc.

Net als Taksi. Het heeeeerlijke frisdrankje. Maar er zit ook zuivel in. Dus is het niet ook een zuiveldrank. Dus als er verschil zit in de btw op frisdrank tov zuivel, wat is dan het btw tarief voor taksi?

[fenrirs]

Simpel, een tomaat is onbewerkt. Een appel ook. Een tomaten salade niet, stukjes fruit in een plastic doosje is ook bewerkt.

Het wordt moeilijk gemaakt

Taksi is ook bewerkt/gemixt. Een pak melk is dat niet. Er zijn geen melk vreemde stoffen aan toegevoegd.

‘T is niet zo moeilijk

[barbarbar]

Dat schiet z'n doel ook voorbij. Het idee erachter is dat gezonde voeding aangemoedigd wordt. De vraag is dus niet zozeer "wat is groente, wat is fruit" of "wat is bewerkt en wat niet". De vraag is veel waziger: wat is gezond? En dan word het natuurlijk heel lastig om te gaan zeggen dat melk gezond is, maar chocomelk niet. Ga dat maar eens sluitend onderbouwen.

[Jeanpaul145]

Ik denk dat je schromelijk onderschat hoe ingewikkeld het kan zijn.

Ik begrijp je punt. Maar tegelijkertijd kan ik niet ontkomen aan het gevoel dat de fiscus dit zichzelf heeft aangedaan, en daarbij een handje geholpen is met een overstroming aan regelgeving uit Den Haag.
Denk dan bijvoorbeeld aan hun "het is moeilijk om geschikt personeel te vinden". Dat is hetzelfde gelul als Amerikaanse bedrijven die klagen dat ze geen geschikt personeel kunnen vinden. In beide gevallen telt: dat geschikte personeel heeft veel betere keuzes, niet in de minste plaats financieel. Dus als ze geschikt personeel willen moeten ze gewoon een marktconform salaris betalen, en dat is flink hoger (denk makkelijk 2 ton) dan ze denken. Zo ver de balkenende norm.

Gegeven het bovenstaande is het bijzonder moeilijk om empathie voor de fiscus als organisatie te voelen.
Sterker nog, hoe meer ze roeptoereren "boehoe kijk arme ons eens", hoe minder empathie ik voor ze heb als groep.

Want wat anderen zeggen is waar: wanneer het ten voordele van de overheid is kan het allemaal wel, en snel ook.

Maar kijk maar eens naar het gesteggel rond de toeslagenaffaire om te zien hoe het gaat wanneer er iets gecorrigeerd moet worden dat in de eerste plaats nooit had mogen gebeuren.

Dus het is dan leuk en aardig om te zeggen "het is allemaal complexer dan je denkt", maar de gemiddelde burger (hell, de gemiddelde tweaker) heeft daar eigenlijk totaal geen boodschap aan.

[Reactie gewijzigd door Jeanpaul145 op 15 oktober 2024 16:59]

[Nozmordre]

Dat is niet iets wat de fiscus zichzelf heeft aangedaan, de fiscus is gebonden aan wat Den Haag beslist.

[TheMak]

Ik denk dat het ministerie vsn financiën de prioriteit van de projecten bepaalt. Dus de belastingmaatregelen voor de gratis kunderopvang kan dus wel. Wat ten koste gaat van de belastingherziening.

[CivLord]

Gewoon even wat extra salaris om goed personeel aan te trekken klinkt leuk, maar geeft wel problemen.
Je kan niet enkel bij de Belastingdienst de salarissen verhogen, want dan zuig je de rest van de overheidssector leeg, dus je moet de salarissen voor de hele sector Rijk verhogen. Dat gaat miljarden extra per jaar kosten. Dat betekent dat iedere Nederlander daar een paar honderd euro extra voor bij moet dragen.
Maar daar blijft het niet bij. Wanneer personeel wegloopt bij het bedrijfsleven, zullen die de lonen verhogen om aantrekkelijker te blijven. Dan zit je weer in dezelfde situatie, maar zijn over de hele linie de personeelskosten hoger. Dus uiteindelijk is er een tekort aan geschikt personeel.

[Jeanpaul145]

Daarmee geef je dus zelf ook wel aan dat het nu nergens over gaat, want beter gaat 't duidelijk niet worden, tenminste niet op een redelijke termijn.

[wild_dog]

De belasting hoeft vrij weinig te definiëren. Die moet een categorie aanmaken "Groetne-fruit-tarief" en die op 0% zetten. Vervolgens moeten de boekhoud systemen die de supermarkten e.d. gebruiken, aangeven welk deel van de verkopen onder die categorie vallen voor de aangifte, en moet de verkoper bepalen welke producten die hij verkoopt volgens hem onder die categorie vallen.

De belastingdienst hoeft (programmatisch gezien) niets te doen om te definiëren welke producten onder die categorie vallen. Het moet in de regelgeving wel duidelijk maken welke dit zijn, maar vervolgens is het de verantwoordelijkheid van de burger de juiste verkopen onder die categorie te melden.

[ikweethetbeter]

Tuurlijk, vriend.

Doet het altijd goed, zo'n prikkelend begin van een reactie!

De 0% BTW op fruit die de politiek had goedgekeurd bijvoorbeeld, die kan niet volgens de belastingdienst.
Terwijl er gewoon een groep nultarief is.

Er is een groep 0% BTW, net zoals er groepen BTW laag (9%) en BTW hoog (21%) zijn. Er is alleen geen "groep fruit". Dus daar zit het probleem. Wat is fruit, is verpakt gesneden fruit ook fruit, en wat als er toevoegingen gedaan zijn, zoals conserveringsmiddelen? En wat als het conserveringsmiddel zout of suiker is? En wat als ...

Dus als dat niet duidelijk is, is een maatregel niet in te voeren. Daarbij: hoe controleer je dat? Door alle kassabonnen en inkoopnota's van supermarkten uit te pluizen?

Maar de verhoging van de BTW op hotelkamers van 9% naar 21% per 2026 is al ingeregeld hoor, geen enkel probleem.

Leg het maar uit.

Dat is symboolpolitiek van ons PVV kabinet. Hotels en theaters gaan in één grote wijziging allemaal over van BTW laag naar BTW hoog. En bioscopen niet, want dat is vermaak voor Henk & Ingrid, en "ons Geert" houdt van films.

[Renoir]

En van de Efteling. En pretparken gaan ook niet omhoog.

[denios]

Ik dacht ik laat even zien dat ik je kritiek niet persoonlijk opvat, maar als een goed gesprek, vandaar 'vriend'.

Wat wel en niet onder fruit valt, is helemaal geen belasting probleem, laat staan een stelsel-probleem, zoals het wel door de belastingdienst is benoemd. Het is een simpele kwalificatie die elke middle-manager kan uitvoeren, en die ook niet in beton gegoten hoeft te zijn. Dat heeft ook niemand als voorwaarde gesteld.

Symboolpolitiek, waar of niet, heeft er niets mee te maken, ik snap niet waarom je dat aanhaalt.
Het gaat er hier om dat dit wel direct uitvoerbaar is, terwijl aanpassing in het voordeel van de belastingbetaler altijd 'problematisch' en 'IT-probleem' zijn.

Als iets echt een IT probleem is, dan heb ik daar alle begrip voor. Ik kan me nog goed het probleem van de slechte programmering van Exact en de overgang naar de Euro herinneren bijvoorbeeld. Een echt IT probleem. Maar dat is bij de belastingdienst geenszins het geval in het genoemde voorbeeld.

[TheMak]

En suiker komt gewoon uit groente, nl de suikerbiet

[ikweethetbeter]

En chocolade is heel gezond, want het is gemaakt van cacao (fruit, groeit aan een boom) en suikerbiet (groente)!

[nllight]

Je hoeft het niet meer te controleren als er 0% belasting op zit

[johan_L]

Het probleem met de invoering van de 0% BTW op groente en fruit was de afbakening van wat daaronder moest vallen, en dat is uiteindelijk een politieke keuze en geen statement van de belastingdienst.

[CivLord]

De Belastingdienst heeft hier helemaal niets over gezegd. De Staatssecretaris heeft gezegd dat de systemen van de Belastingdienst het niet aan konden. Omdat de Belastingdienst toch al de kop van jut was op andere terreinen was dat voor hem een makkelijke manier om van een lastige klus af te komen.

Heeft de staatssecretaris dan regelrecht gelogen? Echt liegen proberen politici meestal te vermijden, maar ze zijn er niet vies van om de feiten iets in hun voordeel 'aan te passen'. Wat ook nog mogelijk is, is dat hem is gezegd dat een dergelijke wijziging lastig in het systeem van wet en regelgeving past (wat dus niets met IT te maken heeft) en dat de staatssecretaris dat verkeerd begrepen heeft.

Maar hoe je het ook wendt of keert. Het afbakenen van welke producten nog wel onder het 0% tarief zouden moeten vallen en welke niet was en is een probleem dat de systemen van de Belastingdienst totaal niet raakt.

[ikweethetbeter]

Er is geen "systeem" waarmee de belastingdienst dit kan faciliteren en controleren. Een feit dus. En eentje die, ls het ingevoerd zou worden, voor veel discussie zou zorgen. Wat is fruit en wat niet. Is een sinaasappel fruit? En sinaasappelsap?

[Rolfie]

Een voorverpakt bakje met fruit kan ook een banaan bevatten.

Muslie kan ook stukjes banaan bevatten .

Bananenbrood?

[Reactie gewijzigd door Rolfie op 16 oktober 2024 07:37]

[SuperPolum]

Het gaat niet om verhogingen of verlagingen, maar om een stelselwijziging.

[PWM]

Het hele Box 3 gebeuren op dit moment is juist het teruggeven van miljarden. Dat hebben ze nu dus prioriteit gegeven en zijn ze aan het uitrollen.

Er zijn ook genoeg voorbeelden van belastingen die geïnd zouden moeten worden maar wat niet gebeurt. En de belastingdienst "pakt" geen geld af.

Populistisch geneuzel.

[Dooxed]

Nou inderdaad!

[jaenster]

Nee, maar elk jaar worden wel de requirements veranderd, zodat ze opnieuw kunnen beginnen

[kodak]

Het nieuws is dat er keuzes is gemaakt andere nodige wijzigingen belangrijker te vinden. Dat is wat anders dan eisen van dit systeem aanpassen. Dus waar baseer je je dan op?

[Guru Evi]

Waarom opnieuw te beginnen? De wet verandert dagelijks en is enkele bibliotheken groot, een degelijk systeem moet veranderingen kunnen continu doordrijven.

Als de wet te groot is, misschien tijd om eens wat af te schaffen, gewoon een platte verkoopsbelasting op alle eindgoederen die verkocht worden (als je rijk bent, betaal je meer omdat je meer uitgeeft ipv minder omdat je een politieker in je broekzak hebt). Het BBP is 1T, als de overheid niet kan rondkomen met 10% kunnen ze snijden en dat geeft de overheid een belang om het BBP te stimuleren ipv meer 'schaduw' belastingen te heffen.

[Reactie gewijzigd door Guru Evi op 15 oktober 2024 18:35]

[GertMenkel]

De afgelopen vijf jaar roept de belastingdienst "we kunnen geen veranderingen aan de wet meer aan, het systeem houdt het niet bij, over x jaar kunnen we weer verder". Vervolgens verandert de wetgeving, en wordt het "over x+1 jaar kunnen we weer verder".

De politiek heeft niet zo'n grote boodschap aan de technische mogelijkheden van de belastingdienst, en daardoor wordt de backlog ieder jaar dieper. Gaat nog wel eens een keer heel goed mis, maar tot die tijd wordt het probleem eerst erger voor het beter wordt.

[Reactie gewijzigd door GertMenkel op 15 oktober 2024 14:17]

[Guru Evi]

Nee, het ligt niet aan jouw:
2017 tegen 2020:
nieuws: Belastingdienst concludeert dat innen belasting gevaar loopt door ict...
En je kunt de tags op Tweakers volgen tot vandaag.

[wildhagen]

De Belastingdienst kampt al jaren met verouderde softwaresystemen en een tekort aan ict'ers met de benodigde expertise. Dit maakt het doorvoeren van wetswijzigingen in de systemen 'buitengewoon complex',

Wat het ook complex maakt is dat de regering praktisch elk jaar weer aanpassingen bedenkt aan het belastingstelsel, die de Belastingdienst dus in hun systemen moet verwerken.

En dan nog dit soort uitspraken van diverse rechtbanken, of in dit geval zelfs de Hoge Raad.

Dat helpt niet echt mee, als er toch al te weinig personeel is om alles te verwerken... zeker niet als veel mensen met kennis van die oude systemen niet meer aanwezig zijn (ivm pensionering bijvoorbeeld).

Als de regering nou eens een paar jaar een 'freeze' op het belastingstelsel hanteert, en dus geen (niet-noodzakelijke) aanpassingen doet, krijgt de Belastingdienst wellicht weer wat extra lucht om eens aan structurele vernieuwing te doen ipv fulltime bezig te zijn met het verwerken van jaarlijkse wijzigingen en "brandjes te blussen".

[Reactie gewijzigd door wildhagen op 15 oktober 2024 13:22]

[Tintel]

Dat lukt dus niet meer als je eenmaal in dat wespennest van lapmiddel op lapmiddel zit...

Totale versimpeling van het stelsel zou echt helpen. Refactor dus.

[uiltje]

Ja, daar zijn ze dus mee bezig, maar dat kost dus tijd en de politiek heeft geen tijd.

[sdziscool]

gemiddeld bedrijf heeft al nauwelijks tijd voor een refactor, want refactor = geen nieuwe features = niets om te verkopen = geen directe waarde.
Erg jammer dat het zo moet zijn.

[trab_78]

Tja, je moet ook niet wachten totdat het zo erg wordt dat je moet wachten met features. Het is de verantwoordelijkheid van de engineers om het systeem in een goede staat te houden. Goede staat betekent dat wijzigingen makkelijk door te voeren zijn. Refactoring moet je eigenlijk voortdurend doen. Als je dat doet, zijn het veelal kleinere dingen die je mee kan pakken als je toch een feature aan het implementeren bent.

[uiltje]

Bij de belastingdienst hebben ze onder andere ook een visuele taal gebruikt toen dat in leek te komen. Dat is echter nooit gebeurd en nou moeten ze daar die hele code base nog van onderhouden. Dan is het bijvoorbeeld niet meer een kwestie van even refactoren. Soms ben je bijna wel gedwongen om opnieuw te beginnen.

Het probleem daarbij is dat je het stapsgewijs software wilt implementeren natuurlijk. Maar dan heb je dus een half werkend systeem dat niet on-par is met geboden functionaliteit met het oude systeem. En de gebruiker blijft dan dat oude systeem gebruiken (waarvan het de nukken ondertussen kent) en het nieuwe systeem is dan natuurlijk maar niets. Ik heb gezien hoe een oud systeem op die manier een nieuw systeem overleefde, ondanks dat het qua onderhoudbaarheid echt in de vuilverbrander zou moeten.

Al met al best lastig om dit allemaal goed te krijgen, vooral als door patchen en nieuwe features het oude systeem erg complex is.

[Reactie gewijzigd door uiltje op 15 oktober 2024 14:05]

[J_van_Ekris]

Het probleem daarbij is dat je het stapsgewijs software wilt implementeren natuurlijk. Maar dan heb je dus een half werkend systeem dat niet on-par is met geboden functionaliteit met het oude systeem. En de gebruiker blijft dan dat oude systeem gebruiken (waarvan het de nukken ondertussen kent) en het nieuwe systeem is dan natuurlijk maar niets. Ik heb gezien hoe een oud systeem op die manier een nieuw systeem overleefde, ondanks dat het qua onderhoudbaarheid echt in de vuilverbrander zou moeten.

Het is nog erger. Op een gegeven moment bestaan oud en nieuw systeem en zijn ze functioneel on-par, maar niemand durft het oude systeem uit te zetten omdat eigenlijk niemand het gehele landschap nog overziet. Voor hetzelfde geld haalt de jaarrekening eens per jaar iets uit dat oude systeem, etc.. De kennis is vaak al decennia weg, en dus weet niemand hoe het echt zit. Besef dat niemand de verantwoordelijke wil zijn die een informatiestroom de nek heeft omgedraait.

Gevolg is dat het probleem nu is verdubbeld (of zelfs verdrievoudigd omdat je de data in de twee systemen gelijk moet trekken). Er zijn maar heel weinig grote spelers (banken, verzekeraars, UWV, belastingdienst) die 30 jaar geleden hun processen al grotendeels automatiseerden die deze ellende succesvol vermijden. Technical debt is bij dat soort organisaties een probleem dat vele malen groter is dan simpelweg refactoren....

[Reactie gewijzigd door J_van_Ekris op 15 oktober 2024 15:28]

[trab_78]

Ja, het is allemaal verklaarbaar en begrijpelijk natuurlijk. Toch zouden engineers moeten doordrukken om die oude systemen wél uit te zetten. Nogmaals: weerstand vanuit de organisatie is begrijpelijk, maar het is de verantwoordelijkheid van engineers om te doorzien dat het in de lucht houden van twee systemen hoogst onwenselijk is.

Als je een nieuw systeem gaat bouwen dat een oud systeem moet vervangen, moet de transitie onderdeel van het plan zijn. Daarbij hoort ook een onderzoek naar gebruikers van het oude systeem. En het in kaart brengen van de risico's wanneer het oude systeem uitgeschakeld wordt.

Hoe begrijpelijk het allemaal ook is, als organisatie heb je flink gefaald als je een nieuw systeem gebouwd hebt en het oude is niet uitgeschakeld. En hoewel het de verantwoordelijkheid van de engineers is om dit aan te kaarten, is niet gezegd dat het de engineers zijn die gefaald hebben. Kan natuurlijk ook zijn dat ze niet gehoord zijn. Of dat er een dusdanige afrekencultuur heerst dat ze het niet durfden aan te kaarten.

Ik zeg dit niet om mensen of organisaties ergens de schuld van te geven. Het is gebeurd en we moeten verder. Maar ik hoop wel dat we kunnen leren van dit soort processen.

[ArnoutV]

Het gaat niet alleen om de belastingregels van vandaag, het systeem moet ook alle situaties uit het verleden ook aankunnen. (waarschijnlijk tot minimaal 10 jaar terug)

[Tintel]

Ja, dat is onhandig/vervelend - om die reden zullen ze dus het oude systeem nog een tijdje in de lucht moeten houden.
Maar dat is alleen maar een voordeel m.b.t. de ontwikkeling van een nieuw systeem denk ik.
Natuurlijk wel extra kosten maar ja. Soms moet je vernieuwen terwijl de oude nog even door moet draaien.

[Kastermaster]

Voor zover ik begrijp zijn voor sommige wijzigingen die men wil/moet doorvoeren aanpassingen in de grondwet nodig. En daarvoor heb je in twee opeenvolgende kabinetten 2/3 meerderheid nodig. En daar zit hem nu net de crux, aangezien er iedere 3 jaar - na weer een gevallen kabinet - een frisse wind in Den Haag waait. Die wetswijziging komt er niet, men hief het glas, men deed een plas en alles bleef zoals het was.

[Luminair]

Als de regering nou eens een paar jaar een 'freeze' op het belastingstelsel hanteert

Dat lijkt mij compleet onrealistisch. Wetgeving, en dus ook het belastingstelsel, is gemaakt op aangepast te worden. Dat is de hele bestaansreden van wetgevers.

[Anonyymm]

Eens, maar het zou wel helpen als wetgeving bedacht wordt welke verder kijkt dan drie/vier jaar, niet een bepaald persoon per se zijn/haar stempel op wilt drukken of waarvan ze op voorhand weten dat het eigenlijk niet kan, maar besluiten het toch door te voeren en wel zien of er iemand/instantie ooit naar de rechter stapt.

[latka]

Een belangrijk verschil tussen wetgeving en IT systemen is echter dat wetten geïnterpreteerd worden door mensen (de rechter) dus een ambiguïteit of fout is niet zo'n probleem.....

[uiltje]

Vast wel, maar momenteel is veel software niet gemaakt om aangepast te worden. Momenteel lijkt het erop dat er eerst wetten worden gemaakt om er daarna achter te komen dat de veranderingen niet doorgevoerd kunnen worden. Dat kan je oplossen door de software beter te maken, maar daar komen ze nu dus niet aan toe.

Het beheren van software is altijd een beetje een ondergeschoven kindje geweest.

[Simon Weel]

Ongetwijfeld zijn de usual suspects zoals Cap Gemini en Ordina aangetrokken voor deze klus en dan weet je hoe het afloopt. Duurt twee keer langer dan gepland en kost vier keer zoveel dan begroot. En het eindresultaat is onwerkbaar.

[Senaxx]

Vanuit eigen ervaring weet ik dat Belastingdienst ook gebruikt maakt van andere leveranciers voor SAS diensten. Neemt niet weg dat het veel beter was. Ik heb destijds meegewerkt aan het befaamde Toeslagen project. Dit project is na 2 jaar destijds ook compleet de prullenbak in gegaan en daarna weer helemaal opnieuw begonnen.

Dit is wel een aardige tijd geleden maar dit was toen met SAS op DB2 mainframe. Ik weet niet of dat nog steeds gebruikt wordt.

[joostiphone]

Dit wordt nog steeds gebruikt.

[YopY]

Maar ze zijn immuun voor kritiek omdat ze de requirements vanuit de dienst krijgen.

[tja]

denk dat het niet meer willen inhuren van freelance ICTers maar alleen nog op payroll of detacherings basis ook niet zal bijdragen.

[BulMi]

Of gewoon marktconforme salarissen betalen zodat je minder afhankelijk wordt van inhuur.

[DjoeC]

Er wordt echt wel marktconform betaald, zeker als je alle secundaire arbeidsvoorwaarden meeneemt. Alleen zijn het geen idiote Silicon Valley bedragen...

[DjoeC]

Misschien gaat dat juist helpen. De belangen van inhuurpartijen lopen niet altijd gelijk met de belangen van de klant kan ik je uit eigen ervaring vertellen.

[Ascension]

Dat alle ZZP-ers eruit moeten zal de slagvaardigheid van de Belastingdienst ook niet ten goede gaan komen.

[Muncher]

Moeten die eruit dan? Hoor ik voor het eerst.

[robertpNL]

Het schijnzelfstandigheids van de Belastingdienst zelf (nota bene) is per 1/1/2025 van toepassing. Je bent dan als zelfstandige ingehuurd door de Belastingdienst en dan hoeft er geen loonbelasting worden betaald en heb jij als ZZP-er belastingvoordelen. Maar de wet DBA vindt dat je eigenlijk in loondienst bent, dus kan dit veel geld kosten. het kabinet heeft besloten hierin te gaan handhaven zodat bedrijven meer personeel in loondienst gaan nemen.

Dat houdt in dat bedrijven terughoudend zijn met het inhuren van ZZP-ers, zo ook de Belastingdienst. En als goed voorbeeldorganisatie zie je dus een kaalslag bij de Belastingdienst. teveel ZZp-ers die nu als schijnzelfstandigheid aan de slag zijn.

[Reactie gewijzigd door robertpNL op 15 oktober 2024 14:39]

[Muncher]

Ooh ja, tuurlijk. Ik had de link even niet gelegd. Bedankt voor de uitleg!

[DjoeC]

De belastingdienst verzint geen wetten, dat doen WIJ via onze democratisch gekozen vertegenwoordigers.

Ik zie nogal vaak reacties waar de uitvoerders als veroorzakers worden benoemd terwijl die slechts wetten uitvoeren. Overigens doen politici dat ook graag om zichzelf in de luwte te houden terwijl zij zelf aan de knoppen zitten. Er komt geen enkele wet zonder dat er een politieke meerderheid voor is - noodwetgeving uitgesloten.

[Highlands]

Geen loonbelasting maar wel inkomstenbelasting. Plus geen verplichte verzekeringspremies (waardoor schijnzelfstandigen vaak onverzekerd zijn) plus wat aftrekposten (die jaarlijks minder worden).

Je suggereert nu alsof IT zzp’ers (veel) minder afdragen maar dit is netto netto niet of zelfs meer (meer productief).

Een gemiddelde zzp’er, dus niet dure interimmers, kost zelf netto amper meer dan een loondienster maar kan door keuzes te maken/ risico’s te nemen meer overhouden.

[Frituurman]

Ik zie veel cynisme in de reacties, maar ik denk dat we de complexiteit niet moeten onderschatten. Ik wérk niet bij de Belastingdienst, maar ik kan me voorstellen dat de systemen, veelal gebouwd in archaïsche programmeertalen, ontzettend complex zijn om te 'vertalen' naar meer toekomstbestendige systemen. Tel daarbij op dat de kennishouders er niet meer zijn (pensioen, overleden, andere werkgever) of in elk geval nauwelijks, dan maakt dat het allemaal niet makkelijker. Het adagium 'If it ain't broke, don't fix it' (of liever 'don't replace it') is tot een kunst verheven bij de Belastingdienst. En met een enorme spaghettibol aan houtjetouwtje-oplossingen die de afgelopen jaren zijn bijgebouwd om aan de wensen van de overheid te voldoen, is vervangen zeker niet makkelijker geworden.

Als de Belastingdienst dit góed had willen doen, dan hadden ze al pakweg 20 jaar geleden moeten (starten met) bouwen aan een gelijk(w)aardig systeem op een modernere architectuur, naast het bestaande platform. Dan had je het mooi incrementeel kunnen uitbreiden over tijd en had je de problemen nu het hoofd kunnen bieden. Regeren (en belastingheffen) is vooruitzien.

Dat gezegd hebbende is het dus wel erg bijzonder dat de huidige legacy systemen als zoveel jaar hun werk nog zo passend hebben kunnen doen.

[YopY]

Is Java al een archaïsche programmeertaal?

Ik zit zelf in de consultancy, zelf nooit voor de belastingdienst gewerkt maar wel via-via dingen gehoord van collega's. Ze zijn echt wel bezig met proberen de systemen en politiek daar te verbeteren, maar tegelijkertijd moet het met beleid gebeuren omdat ze fouten moeten minimaliseren en natuurlijk werkende software / procedures niet stuk moeten maken.

Een project ging over het detecteren van fraude / witwassen; door het toepassen van moderne data analyse konden ze de bedragen waar naar gekeken wordt flink verlagen, dwz, ze konden verdachte transacties beter en automatischer identificeren.

Maar ook qua code kwaliteit en architectuur zijn ze hard aan het werk. Ik vind persoonlijk ook dat de front-end voor het doen van de belastingaangifte echt goed gedaan is (ik herinner me ook nog de diskette-versie). Ze hebben over van alles nagedacht, van het linken naar meer info tot accessibility tot het gezamelijk invullen van de aangifte waardoor de hele flow anders wordt.

[Frituurman]

Ik noem Java niet toch? Ik doel op bijvoorbeeld COBOL, wat in pakweg 175 systemen/applicaties de programmeertaal is binnen de Belastingdienst en die systemen zijn verantwoordelijk voor 70% van alle financiële transacties die de Belastingdienst uitvoert.

Ik zeg ook niet dat ze niet bezig zijn, maar dat er hier wel erg cynisch wordt gereageerd en de complexiteit wordt onderschat. Overigens is iets als COBOL prima in te passen in een modern landschap en het werkt gewoon goed, probleem is alleen dat de kennis er niet is (wat ik al benoemde).

Je voorbeeld over fraude-opsporing, inderdaad, ze zijn op zich goed bezig, behalve dan dat ze op de FSV terug zijn gefloten natuurlijk door de Autoriteit Persoonsgegevens. Dan doel ik niet op de toeslagenaffaire.

[jopiek]

Zo is het, men gebruikt voor alle basiszaken voor zo ver ik weet nog steeds COBOL.

Alleen wat ook jij onderschat is dat die COBOL dan weliswaar op zich inderdaad te combineren is met een modern landschap, maar er is enorm veel COBOL code waarvan ook ervaren medewerkers niet precies weten wat het doet.

Men durft er ook niet aan te komen want men is als de dood dat het bijv. de printstraat activeert en volgende week alle Nederlandsers een of andere onterechte blauwe enveloppe met inhoud ontvangen. Dus die legacy is zeker wel een probleem.

[Frituurman]

Alleen wat ook jij onderschat is dat die COBOL dan weliswaar op zich inderdaad te combineren is met een modern landschap, maar er is enorm veel COBOL code waarvan ook ervaren medewerkers niet precies weten wat het doet.

Sorry, hier moet ik je corrigeren. Ik onderschat het juist niet. Je zegt gewoon in andere woorden wat ik al schreef:

Ik zeg ook niet dat ze niet bezig zijn, maar dat er hier wel erg cynisch wordt gereageerd en de complexiteit wordt onderschat. Overigens is iets als COBOL prima in te passen in een modern landschap en het werkt gewoon goed, probleem is alleen dat de kennis er niet is (wat ik al benoemde).

[jopiek]

Je hebt gelijk, ik heb het nog eens even herlezen en daar komt het zeker op neer! Ik denk overigens wel dat het probleem niet het ontbreken van kennis is, het is gewoon zo complex dat een mens het gewoon niet meer kan behappen. Misschien moeten ze maar een lokaal LLM gaan trainen en eerst maar eens proberen de software overzichtelijker te maken.

[downtime]

Als de Belastingdienst dit góed had willen doen, dan hadden ze al pakweg 20 jaar geleden moeten (starten met) bouwen aan een gelijk(w)aardig systeem op een modernere architectuur, naast het bestaande platform. Dan had je het mooi incrementeel kunnen uitbreiden over tijd en had je de problemen nu het hoofd kunnen bieden. Regeren (en belastingheffen) is vooruitzien.

20 jaar geleden? Dan hadden ze 20 jaar geinvesteerd in een systeem wat nu waarschijnlijk ook alweer legacy en aan vervanging toe is. Je moet veel geluk hebben als je 20 jaar geleden koos voor een systeem wat nu niet aan vervanging toe is.

[Lodd]

Wel wat makkelijk om iedere keer naar oorzaken van buiten te wijzen. Mijn beeld van de belastingdienst als organisatie is niet al te rooskleurig, en als ik weer eens een vacaturetekst van ze voorbij zie komen wordt dat beeld er niet beter van. Kunnen ze het bij de belastingdienst echt niet effectiever aanpakken?

[J_van_Ekris]

Wel wat makkelijk om iedere keer naar oorzaken van buiten te wijzen.

Omdat dat ook realistisch is. Je kunt niet een nieuwe architectuur neerzetten als de fundamenten van je bestaande systemen continue wijzigen en je bovendien direct die bestaande systemen ook nog moet aanpassen.

Dit is het gevolg van decennia roofbouw waar de politiek gewoon doet wat ze wil (belastingwetten wijzigen) zonder om te kijken naar de gevolgen bij de uitvoeringsorganisaties. Er ligt een soort blanco cheque bij de tweede kamer zonder controle op de effecten.

Dat een organisatie vast zit in een moeras van technical debt is niet vreemd. Alle voorlopers in grootschalige administratieve automatisering hebben hier nu last van (banken, verzekeraars, UWV, etc.). Maar opruimen is enorm lastig, zeker als de winkel gewoon open moet blijven en wijzigingen moet blijven accepteren. Sommigen zijn letterlijk overnieuw begonnen in een nieuw bedrijf (met name verzekeraars), maar ik weet van sommige partijen dat die 2500 man in dienst hebben voor het onderhoud op de primaire legacy systemen, waar hun jongere zusje het met minder dan 100 man afkan.

[DjoeC]

Tja, het box 3 herstel zal best wel inspanning vergen maar daar gaan geen 300 van de 1.500-2.000 automatiseerders aan werken. Zo'n persbericht lijkt dus meer als een schot voor de boeg: kom niet weer met nieuwe dingen.

En vwb de eerdere opmerkingen over archaische IT: De oudste systemen werken al heel lang zonder noemenswaardige problemen terwijl de nieuwere ontwikkelstraten zoals Java elke keer opnieuw onder het mes moeten vanwege niet (altijd) compatibele upgrades, vernieuwde of onveilig bevonden frameworks en ga zo maar door. Daarnaast zijn nieuwe agile ontwikkelde producten in de eerste N iteraties vaak nog onvolwassen, functioneel niet compleet, foutpaden incompleet en noem maar op. Daarnaast hebben "moderne" automatiseerders vaak een schromelijk gebrek aan bussiness kennis wat niet bijdraagt aan een goed product waar de klant echt iets mee kan. Enneh, het cintinue job hoppen draagt natuurlijk ook niet bij aan het (willen) opdoen van inhoudelijke kennis.

[panterarosso]

ik kan me niet voorstellen dat je een serieus belastingsysteem in java doet, ik kan me nog voorstellen dat ze niet in c of 1 van de vele afslagen/opvolgers werkte maar het probleem is blijkbaar dat er nog heel veel in cobol gewerkt wordt.

je zou bijna zeggen dat je gezien de bedragen het geld in een nieuwe moderne cobol versie kan steken

[DjoeC]

Het probleem met Cobol is het imago van legacy. Dat imago klopt niet maar zorgt er wel voor dat vrijwel niemand dit wil leren. En als je geen mensen kunt krijgen of naar het juiste niveau kunt brengen in willekeurig welk platform je hebt moet je dus veranderen, verstandig of niet...

Dat geldt dus ook voor de belastingdienst. Niet het verstand bepaalt maar de onderbuik van "de markt".

[aikebah]

Heel veel bijzonder serieuze en mission critical software draait in java (en in C en in dotNet en en COBOL en in whatnot...). Geen enkele reden om dat niet te gaan inzetten naar mijn idee.

[Megasyb]

Kan hier een achtergrondartikel over komen?

De enige stelselwijziging die mij zo te binnen schiet is de berekening van Box 3. Voor de rest zijn het toch alleen percentages (praktisch na elke verkiezing) en de jaarlijkse aanpassing van min/max bedragen?

Hoe kan het dan dat dit al jaren speelt en telkens vooruitgeschoven wordt "omdat het niet lukt?"

Ik ben een totale leek op gebied van programmeren en was ook niet de beste in belastingrecht tijdens mijn studie, dus ik begrijp dat het stelsel an sich al ingewikkeld genoeg is en dat het dus ook best wat tijd/klauwen met geld extra kan kosten. Maar het is toch niet zo dat de basis elk jaar volledig overhoop gaat en er daarom al weet ik niet hoeveel jaar inmiddels over vertraging wordt geschreven?

[Reactie gewijzigd door Megasyb op 15 oktober 2024 16:38]

[ArcticWolf]

Mijn stiefvader werkte jarenlang bij de belastingdienst als inhuur om de ICT op orde te krijgen en houden, naar mijn weten werken ze nu nog steeds met oude mainframes (nog net niet met COBOL zeg maar ).
Maar ik werk zelf ook bij een overheidsinstantie en voornamelijk de verplichte aanbestedings "drang" veroorzaakt veel problemen. Jaren geleden alweer moest de complete ICT afdeling van de belastingdienst (en onze ook) eruit en uit- en aanbesteed worden... Van de ene op de andere dag moest m'n stiefvader weg, niet dat hij dat erg vond maar vreemd was het wel. De duur van een gunning is beperkt en er zit /altijd/ een kostenaspect aan (waar de service onder lijdt).

Wij zijn gemigreerd van Ivanti naar Intune en dan merk je pas hoeveel gezeik het oplevert als de helpdesk wel intern is, maar de systeembeheerders van een ander bedrijf zijn, die weer een systeem van Microsoft hebben geïmplementeerd

[aikebah]

Je vergeet alle uitzonderingen op de regels, ook wel bekend als de koopkrachtreparaties omdat groep x bij de generieke tariefsaanpassing een te groot koopkrachteffect heeft ten opzichte van de rest en wordt er een bijzondere regeling opgetuigd om specifiek groep x weer wat te compenseren.

[barbarbar]

Het is in sommige gevallen ook wel fijn voor een minister om zaken te kunnen doorschuiven omdat "de IT-systemen" het niet kunnen. Lekker algemene dooddoener waarmee je niemand kwetst en geen verantwoordelijkheid voor hebt, en toch tijd wint/rekt tot de volgende verkiezing.

[CivLord]

Die wijziging van box 3 is een wijziging binnen het stelsel.
Het huidige stelsel is inkomen uit loon, winst en overige werkzaamheden in box 1, inkomen uit deelnemingen in rechtspersonen in box 2 en inkomen uit sparen en beleggen in box 3. Dat systeem begint te kraken.
Steeds meer personen werken als zelfstandige (ook wanneer je schijnzelfstandigen kwijt zou raken) waardoor alle belastingkortingen voor zelfstandigen te veel geld kosten, terwijl veel van die zelfstandigen niet tegen dezelfde kosten oplopen als een compleet bedrijf met een vestiging en personeel die als eenmanszaak gerund worden. Steeds meer mensen werken ook via een eigen BV, waarvoor de belastingtarieven lager zijn, wat ook weer veel belastinginkomsten scheelt. En sparen en beleggen heeft weer zijn eigen problemen.
Binnen het huidige systeem zijn de verschuivingen van inkomsten uit loon naar inkomsten uit winst en dividend alleen op te vangen door tarieven en bedragen aan te passen. Maar die werken voor een zelfstandige met laptop hetzelfde door als een metaalbewerker met een bedrijfspand en personeel en voor een holding met een directeur die zichzelf verhuurd hetzelfde als een groot bedrijf met meerdere vestigingen een paar honderd man personeel en tien aandeelhouders. Wat er dus eigenlijk nodig is, is een reorganisatie van het systeem, waardoor er ook onderscheid gemaakt kan worden tussen kleine ZZP-ers en grotere eenmanszaken en waarbij het inkomen uit aanmerkelijk belang op de schop gaat.
Een dergelijke grote wijziging in het hele stelsen kan op dit moment niet uitgevoerd worden door het simpel aanpassen van de bestaande systemen. Bij de vorige stelselwijziging, in 2001, waren er nog lang niet zoveel verschillende systemen bij de Belastingdienst en waren ze ook nog niet zo met elkaar vervlochten.