Beantwoord

Definitief geen omschrijving mogelijk bij betaling aan de Belastingdienst.


Toon eerste bericht

61 Reacties

Reputatie 3
Sterker nog, als ik mij goed herinner deed de BD dat in het verleden ook al, het kenmerk uit het omschrijvingveld halen. Het nadeel is dan echter dat een eventuele fout pas achteraf kan worden vastgesteld. Nu gebeurt dat tevoren. SNS zou dus de betreffende routine van de BD kunnen gebruiken als tegenprestatie? Dan valt het met dat prijskaartje ook heel erg mee.
Reputatie 2
Goed, ik dan ook maar even ...
Ik denk dat de BD veel geld bespaard door deze ingreep. De SNS in een financiële instelling, heeft de laatste jaren moeite de eindjes aan elkaar te knopen, dus ... Ze zijn tenslotte op de centen.
Nu heb ik daar niets op tegen, maar ..
* wees daar open over (maar ja das was een collega ook over data verkopen en ...)
* en hou de belangen van je klanten in het oog!
In dat laatste heeft men zich dus een beetje vergist.
En nu een verdere discussie willen sluiten omdat "het vastligt" is wel heel erg kort door de bocht (Max zou in de grindbak belanden vermoed ik)
Groet,
Ben :cool:
PS Dat de SNS meer greep op de discussies hier (wat ik al een poos constateer) wil, kan ik begrijpen, ik laat me (en met mij denk ik vele klanten) echt niet mond dood maken. Uiteindelijk hebben we voeten om mee te stampen. Wie niet horen wil ....
Reputatie 1
Koos schreef:

Sterker nog, als ik mij goed herinner deed de BD dat in het verleden ook al, het kenmerk uit het omschrijvingveld halen. Het nadeel is dan echter dat een eventuele fout pas achteraf kan worden vastgesteld. Nu gebeurt dat tevoren. SNS zou dus de betreffende routine van de BD kunnen gebruiken als tegenprestatie? Dan valt het met dat prijskaartje ook heel erg mee.

Hoi Koos, de reactie die ik vanmiddag in mijn hoofd was in de trant van: "De analyse van het informatieveld is nog wel een keer gedaan, maar wat doe je dan met het resultaat?". Waar ik hierbij aan dacht was het opknippen van het resultaat in twee stukken, zodat alleen het betalingskenmerk doorgaat naar de belastingdienst, maar de omschrijving in de database van SNS beschikbaar blijft. Maar linksom of rechtsom betekend dat opknippen twee tijdelijke en minstens een extra permanent informatieveld. Nu weet ik even niet wat voor kunstje de regular expression van eRik19 nog zou kunnen....

Maar nu ik hier zit te typen wordt het eigenlijk veel eenvoudiger. Als de belastingdienst echt alleen heeft gesteld dat het kenmerk deel moet uitmaken van de overschrijving, dan is een eenvoudig vaststellen van het kenmerk voldoende en hoeft het mogelijk niet eens uit de gemeenschappelijke string te worden gehaald. Misschien bedoelde je dat ook Koos?

Misschien is die check zelfs al in de Mijn SNS interface te verwerken, zodat de klant al ziet dat de overschrijving nog wat aandacht nodig heeft. Iets lastiger wordt het als een valide betalingskenmerk een reeks moet bevatten die zich voortdurend in de tijd veranderd, en eigenlijk alleen bij de belastingdienst zelf goed bekend is. Maar dit vermoed ik niet, omdat dan de huidige kenmerk-only interface ook te kort schiet als poortwachter .
Reputatie 3
Ferd schreef:

is die check zelfs al in de Mijn SNS interface te verwerken, zodat de klant al ziet dat de overschrijving nog wat aandacht nodig heeft. Iets lastiger wordt het als een valide betalingskenmerk een reeks moet bevatten die zich voortdurend in de tijd veranderd, en eigenlijk alleen bij de belastingdienst zelf goed bekend is. Maar dit vermoed ik niet, omdat dan de huidige kenmerk-only interface ook te kort schiet als poortwachter .


Het kenmerk staat ook op de acceptgiro, dus dat kun je wel uitsluiten.

Ferd schreef:

Waar ik hierbij aan dacht was het opknippen van het resultaat in twee stukken, zodat alleen het betalingskenmerk doorgaat naar de belastingdienst, maar de omschrijving in de database van SNS beschikbaar blijft. Maar linksom of rechtsom betekend dat opknippen twee tijdelijke en minstens een extra permanent informatieveld.

Maar nu ik hier zit te typen wordt het eigenlijk veel eenvoudiger. Als de belastingdienst echt alleen heeft gesteld dat het kenmerk deel moet uitmaken van de overschrijving, dan is een eenvoudig vaststellen van het kenmerk voldoende en hoeft het mogelijk niet eens uit de gemeenschappelijke string te worden gehaald. Misschien bedoelde je dat ook Koos?.


Ik kan mij voorstellen dat de BD een specifiek numeriek veld van 16 posities verwacht, dus een gecontroleerd kenmerk.
De rest van jouw voorstel is prima te doen lijkt me zonder veel extra kosten.
De enige mogelijke hobbel die ik zie is een bureaucratische. Het zou best kunnen dat het een vereiste is dat de informatie naar de betaler en naar de ontvanger identiek moeten zijn. Dat lijkt in dit geval totaal zinloos, maar je weet hoe het met regeltjes gaat.
Ook dit zou simpel op te lossen zijn. Tot 2019 accepteerde de BD wel degelijk omschrijvingen, dus dan moet dit worden hersteld. Lijkt me ook geen technisch zware opgave.

Ben benieuwd wat SNS / Volksbank van deze voorstellen vindt. Als we er ooit iets over horen....
Reputatie 2
Koos schreef:


Ben benieuwd wat SNS / Volksbank van deze voorstellen vindt. Als we er ooit iets over horen....


Ik denk dat je dan konkreet je vragen aan de SNS moet stellen, anders ......
Groet,
Ben :cool:
Reputatie 3
Als dat nodig is zou dat heel erg droevig zijn.
Goedemiddag @Koos, @Ferd, @BigBen, @eRik19 en @elperro,

Vanzelfsprekend begrijp ik jullie kritiek op het verplichte betalingskenmerk en dat jullie graag de mogelijkheid willen hebben om zelf een omschrijving toe te voegen bij een betaling aan de Belastingdienst. Ondanks dat ik verwacht dat het niet wordt aangepast, geef ik jullie reacties met suggesties door aan de ontwikkelaars bij SNS. Ik besef dat ik daarmee geen oplossing aandraag, maar op die manier tracht ik jullie wensen en vragen intern zichtbaar te houden.
Reputatie 3
Dat is fijn.
Reputatie 1
Hoi Evelien, ik vind het heel goed van je dat je desondanks die discussie doorzet. We kunnen onmogelijk het complete beeld hebben, maar de vragen die aan de orde zijn gekomen zijn volgens mij wel legitiem. Ondanks dat er waarschijnlijk nu weinig mee kan gebeuren zal zo in een toekomstige afweging beter kunnen worden voorkomen dat overschrijvingen voor haar gebruikers abstract worden.
Goedemorgen @Ferd en @Koos,

Dank voor jullie fijne reacties. SNS hecht veel waarde aan jullie input en ik vind het belangrijk om het goed over te brengen. Daarom luister ik met aandacht naar jullie vragen, wensen en opmerkingen. Ondanks dat ik zaken niet kan veranderen, vind ik het prettig en nuttig om me voor jullie (en alle andere mensen) in te zetten. In mijn functie tracht ik goede communicatie en de belangen van de klant op het netvlies van de bank te houden. Tot zover, ik wens jullie een mooie en zonnige dag in mei.
Het 16 cijferige betalingskenmerk veld en het omschrijvingsveld zijn beide aanwezig als twee aparte velden bij een overmaking.
Wanneer je bij een overmaking het rekening nummer van de belastingdienst invult krijg je alleen het 16 cijferige betalingskenmerk veld te zien. Het omschrijvingsveld wordt (op de achtergrond automatisch) gevuld met een (in mijn geval) code dat is opgebouwd uit de letters "CUR", dan een spatie en dan het 16 cijferige betalingskenmerk waarbij het laatste cijfer aangepast wordt met het volgnummer van de betaling. Nog een tweede kenmerk dus voor geautomatiseerde systemen.
Je kan dit zien als je een CSV download van je betalingen maakt.

Je zou voor een overmaking dus wel een 16 cijferig betalingskenmerk veld + een omschrijvingsveld met eigen herkenbare gegevens kunnen hebben, maar het omschrijvingsveld wordt bij een overmaking aan de belastingdienst misbruikt met voor mensen "nietszeggende" informatie voor geautomatiseerde systemen, wat het betalingskenmerk ook al is. Dus twee velden voor geautomatiseerde systemen zonder voor mensen begrijpelijke informatie.
Als ik mijn lijst met betalingen aan de belastingdienst doorkijk zie ik alleen een rij bedragen en codes. En of het nou een (deel) betaling van motorrijtuigenbelasting betreft voor b.v. één van mijn X aantal voertuigen, inkomstenbelasting of ander soort belasting, is niet te zien.

Ik zou zeggen laat het omschrijvingsveld beschikbaar voor informatie die door mensen te begrijpen is, en laat de IT-ers een oplossing zoeken om extra info daar automatisch aan toe te voegen voor geautomatiseerde systemen als er geen extra veld gemaakt kan worden. Dan zijn de mensen EN geautomatiseerde systemen tevreden.

Reageer

    • :D
    • :?
    • :cool:
    • :S
    • :(
    • :@
    • :$
    • :8
    • :)
    • :P
    • ;)