Bij invoer is het mogelijk om een foute datum handmatig in te geven, bv 06-06-0219 ipv 06-06-2019. Het systeeem controleert deze invoer niet. de foute datum kan gewoon worden opgeslagen met alle lastige gevolgen naderhand bij opvragen van datum gerelateerde informatie. bv boekjaar.
Fout is aangemeld bij Support en kreeg daarop onderstaand reactie:
Alleen zijn er momenteel veel meer change requests met een hogere prio waarbij er echt sprake is van fouten met grotere gevolgen binnen de applicatie dat we dat nu niet gaan oppakken. We raden u aan om er een wens voor in te dienen op het Unit4 Ideas portaal. Afhankelijk van het aantal stemmen van andere klanten, kunnen we het in een volgende release wellicht wel meenemen. Vooralsnog blijft het invoeren van correcte data nu nog een zaak van de gebruiker en wordt dit niet gecheckt in de software. Er zit nu alleen een controle op het datumformaat dd-mm-jjjj. Maar u heeft gelijk dat je daarbij alle mogelijke waarden in kan geven, ook bijv. 31-12-9999 die vaak gebruikt wordt als waarde 'tot en met' in een een bepaald bereik. Het zal dus nog best lastig worden om een goede geldigheidscontrole in te bouwen voor ALLE data in ALLE tabellen. Een jaartal kan nl. ook nog best 1998 zijn, maar 1898 lijkt minder correct. En 2098 ook niet. Het vergt dus nogal wat ontwerp-werk om dat 100% goed te krijgen.
Ik denk dat dit een normale controle routine behoort te zijn bij alle invoerschermen bij datum velden
Kees Meeus
0
Geaccepteerd
0
Geaccepteerd
ik lees 'orderdatum'...voor Verkooporders bestaat (gelukkig) een herstelprogramma, voor Inkooporders (nog) niet. Klant heeft specifiek probleem bij Inkooporders en zou graag veld afgeschermd zien. In mijn optiek is dan een Gebruikersparameter (status vanaf Blokkeren) de beste optie
Attachments Open full size
Goeiemorgen,
Is er al wat bekend over de ontwikkelingen m.b.t. dit idea?
Attachments Open full size
Goeiemorgen,
Is er al wat bekend over de ontwikkelingen m.b.t. dit idea?
Nogmaals, voor ons zou het voldoende zijn als we via gebruikersparameters konden instellen dat de orderdatum geblokkeerd is en altijd op <vandaag> staat en alleen door een andere gebruiker of met een wachtwoord gewijzigd kan worden.
Attachments Open full size
Goeiemorgen André,
Ik denk niet dat ik het eens ben met het mergen van mijn idea met dit andere Idea.
Mijn verzoek is om 1 veld te blokkeren voor gebruikers, dus vaste waarde in te vullen.
Dat andere Idea is om ALLE datumvelden in Agresso te controleren en een waarschuwing te geven bij vreemde datums.
Dat is dus een stuk omvangrijker en ook niet nuttig voor ons, want dan zouden we nog steeds per ongeluk de datum van gisteren kunnen ingeven denk ik.
Misschien dat jullie het dan nog steeds geen PRIO geven maar dan kan men er apart op stemmen en blijft het een apart onderwerp.
____________________________________________________
Met vriendelijke groet,
Nasja van Meerten
Applicatiebeheerder
Attachments Open full size
Bij ons komt het (met 12 vestigingen en 150 gebruikers) helaas wel vaker voor, en soms is het echt heel vervelend..
Volgens mij hoeft het niet heel moeilijk te zijn, en is die controle vrij makkelijk toe te voegen aan een trigger o.i.d.
Je zou in de parameters Basisgegevens een maximale "terug" en "vooruit" periode in kunnen geven, en wellicht een mogelijkheid om een aantal data uit te zonderen (zoals idd 31-12-9999 die AW zelf ook gebruikt als er geen einddatum is bij bijvoorbeeld prijzen en kortingen). Vergelijkbaar met programma 'Voorzet boekjaar/periode'.
Attachments Open full size
Arjan Vos - Dresz
11-6-2019 8:38
Ik volg Unit4 wel, dat hier enorm veel uren van de ontwikkelaars in gaan zitten om dit in te bouwen op alle plaatsen in het pakket waar je een datum in kunt vullen. Ik zou liever zien dat die uren in andere onderdelen worden gestoken. Mede omdat we hier in een paar jaar tijd maar één keer een fout hebben gehad die hiermee voorkomen had kunnen worden. Dat is wel te overzien...
Attachments Open full size