Release Notes CheQpoint 2.0. Versie 32. Efficiency through innovation

Transcriptie

1 Release Notes CheQpoint 2.0 Versie 32 Efficiency through innovation

2 1 (IGSE) #PTC #WER: geavanceerd zoeken op tel/fax/gsm-nummers Probleemstelling: Zoekfunctie op tel/fax/gsm-nummers: 1. Niet-numerieke tekens worden wel toegelaten op de GUI maar in het geavanceerd zoekscherm kunnen enkel cijfers ingegeven worden. In dergelijke situaties kan dus nooit een resultaat gevonden worden. 2. Daarenboven maken andere tekens de zoekopdracht moeilijk. Door een grote diversiteit aan scheidingstekens (ook spaties) en omdat een perfecte match noodzakelijk is deze functie bijna nutteloos. Vanaf heden is het mogelijk klanten en werknemers op te zoeken via het telefoonnummers door een volledige of gedeeltelijke match. Hierbij zijn enkel cijfers en hun volgorde nog van belang, andere tekens worden genegeerd in de zoekopdracht. Bij een volledige match is ook het aantal cijfers van belang, bij een gedeeltelijke match dus niet. Niet-numerieke tekens ingegeven door de eindgebruiker worden wel nog getoond op de gebruikersinterface en worden dus ook nog bewaard op de database. Versie

3 Een andere en in principe betere oplossing zou zijn om een formattering toe te passen op de interface en op de database enkel cijfers te bewaren. De gebruiker zou zich dan ook mogen beperken tot het ingeven van cijfers. Deze methode werd echter niet gebruikt omdat: bepaalde klanten telefoon/fax/gsm gegevens rechtstreeks importeren in de database (met scheidingstekens). Waarbij ook soms deze data moet doorgegeven worden naar andere applicaties. bij de klanten al speciale tekens in die velden staan en deze allemaal zouden moeten aangepast worden. Dat is dan wel een eenvoudig oplosbaar probleem. mogelijks de klant een al eigen formattering heeft gekozen en de gegevens dus niet mogen aangepast worden 2 (IGSE) #PTC: Bugfix - velden voorrang en voorrangsreden niet leeg bij nieuwe klant Probleemstelling: Bij ingave van een nieuwe particulier bleven de gegevens van een vorige particulier hangen in de velden voorrang en voorrangsreden. Er zat een fout in CheQpoint waardoor deze velden niet netjes werden opgeruimd. 3 (IGSE) #MAW: F-PIT - aanpassing bepaling werknemeradres Probleemstelling: 1. In CheQpoint wordt het adres van de werknemer bepaalt op de begindatum van de afdrukperiode. Dit komt omdat de afdruk ook voor de toekomst (of zelfs het verleden) kan zijn. Meestal wordt de afdruk gemaakt voor de komende maand, vandaar dat het adres wordt genomen die op de startdatum geldig is. Echter alles hangt af van de verzenddatum van het f-pit document vandaar dat deze logica ook niet sluitend is en zal worden aangepast (zie oplossing). 2. Een tweede punt is dat het adres van de werknemer over de afdrukperiode kan wijzigen en er slechts 1 adres kan getoond worden. Maar ook hier is het meest logische zich te baseren op de startdatum. Versie

4 Voor de eindgebruiker is meestal het huidige adres van belang (als we er vanuit gaan de documenten worden verzonden op de dag van afdruk). Dit lijkt dus een betere keuze te zijn dan het adres op startdatum. In CheQpoint werd dit dus aangepast. 4 (IGSE) #PTC #WER: meerdere contactpersonen met gelijke contactgegevens Probleemstelling: In de huidige versie van CheQpoint kan men geen 2 maal dezelfde tel-, fax- of GSM-nummer ingeven. Dit kan inderdaad een ongemak zijn, vandaar volgende wijzigingen in de logica van CheQpoint zowel bij particulieren als werknemers: Verschillende contactpersonen met hetzelfde nummer wordt toegelaten zowel bij werknemers als klanten Waarschuwing bij dubbele tel/fax/gsm nummers, enkel rekening houdend met cijfers (zie screenshot ) 5 (IGSE) #PTC #WER: Verbetering voor het aanpassen van adressen bij klanten en werknemers Probleemstelling: Wijzigen van adressen van zowel klanten als werknemers geeft soms problemen. Versie

5 De datum van het adres heeft in CheQpoint geen uurnotatie. Aangezien de adressen soms worden geïmporteerd is deze uurnotatie soms per ongeluk toegevoegd. Dit zorgt voor problemen bij het wijzigen en wissen van adressen in het systeem. Hiervoor is nu een beveiliging geïntegreerd in CheQpoint zodat bovenstaande geen probleem meer vormt, ook al is de timestamp toegevoegd. Echter om adrestoekenning juist te laten verlopen (bijvoorbeeld in de planning) is het aangewezen deze timestamp terug te verwijderen, omdat met die timestamp rekening wordt gehouden in de code: Voor Microsoft SQL Server gebruikt u hiervoor volgende queries: UPDATE tblklantadres SET Vanaf = DATEADD(dd, 0, DATEDIFF(dd, 0, Vanaf)); UPDATE tblwerknemeradres SET Vanaf = DATEADD(dd, 0, DATEDIFF(dd, 0, Vanaf)); Voor Oracle MySQL gebruikt u deze queries: UPDATE tblklantadres SET Vanaf = DATE(Vanaf); UPDATE tblwerknemeradres SET Vanaf = DATE(Vanaf); Stel dat de timestamp op 14:00:00 staat, dan zal dit adres voor de begindag maar vanaf 14u worden toegekend. Op die dag wordt dan in de voormiddag het vorige of geen adres toegekend. 6 (IGSE) #PTC #PLA: Foutieve chequewaarden Probleemstelling: Er zat een fout in het codeboek voor chequewaarden (korte omschrijving voor waarden 9/9.5/10 verkeerd) De fout doet zich voor bij de setup van versie , deze setup werd gecorrigeerd zodat de fout niet meer optreedt. De oplossing voor latere versies (indien u versie al geïnstalleerd heeft) zit in versie die binnenkort zal uitgebracht worden. Als u de fout onmiddellijk wil oplossen, kunt u volgende queries uitvoeren op uw database (zonder een update van CheQpoint): Versie

6 UPDATE tblcode SET OMSCHR_KORT = '9' WHERE CD_SRT = '1919' AND CD = '3'; UPDATE tblcode SET OMSCHR_KORT = '9.5' WHERE CD_SRT = '1919' AND CD = '4'; UPDATE tblcode SET OMSCHR_KORT = '10' WHERE CD_SRT = '1919' AND CD = '5'; 7 (IGSE) #PLA: Altijd goedkeuring vragen bij kopieslag Om het gebruiksgemak te verbeteren werd er geopteerd de interactie met de gebruiker bij de kopieslag naar de planning standaard aan of af te kunnen zetten. Uitwerking: Voortaan kan u met de parameter 'GoedkeuringVragenBijKopieslag' standaard de optie 'Altijd eerst de door te voeren wijzigingen tonen ter goedkeuring' aanzetten (zie screenshot) bij de kopieslag van een theoretische planning van een werknemer naar een werkelijke planning. Deze parameter moet de CheQpoint-klant ingeven in de tabel tblglobalsettings op de database van CheQpoint. De waarde van de parameter moet 1 zijn om de optie aan te zetten. De optie is inactief als de parameter ontbreekt of de waarde 0 heeft. Versie

7 8 (KEAN) #EXS #KAN: wijziging kantoorselectie bij gebruik vennootschappen In het venster exporteer gegevens naar sociaal bureau kiest men het kantoor waarvoor men de gegevens wenst te exporteren. Indien men werkte met vennootschappen, dan kreeg men ook de optie ALLE KANTOREN welke eigenlijk duidde op de kantoren van de huidige vennootschap en niet op alle kantoren van CheQpoint. Vanaf nu wordt in de keuzelijst van kantoren de naam van de vennootschap weergegeven in plaats van de aanduiding ALLE KANTOREN. Dit geldt enkel wanneer vennootschappen gebruikt worden; als dat niet het geval is, dan wordt nog altijd de optie ALLE KANTOREN weergegeven. 9 (KEAN) #PTC: nieuwe optie alle bij werknemeroverlay in theoplanning particulier In de particuliertheoplanning wordt standaard een overlay getoond van de werknemertheoplanningen. Daarbij had men twee opties: vanaf vandaag en laatste. Daar is nu een derde optie alle bijgekomen. De optie alle toont alles wat binnen het bereik van de particuliertheoplanning valt, dus wat binnen de start- en stopdatum van de particuliertheoplanning ligt, ongeacht of het nog van belang is of niet. Er wordt wel rekening gehouden met de juiste week, dus optie alle zal geen items tonen die in een andere week vallen. De optie laatste blijft nog altijd de standaardoptie. 10 (KEAN) #PTC: betekenis van optie laatste van werknemer-overlay is gewijzigd In de particuliertheoplanning wordt standaard een overlay getoond van de werknemertheoplanningen. De betekenis van de optie laatste, welke standaard geselecteerd is, is nu aangepast. Vroeger toonde de optie laatste de werknemertheoplanningen die geldig zouden zijn aan het einde van de particuliertheoplanning. Dit betekende dat als een werknemertheoplanning een stopdatum had en deze voor de stopdatum van de particuliertheoplanning lag, de werknemertheoplanning in kwestie niet getoond werd in de overlay. Ook wanneer de particuliertheoplanning geen stopdatum had maar de werknemertheoplanning wel, dan werd deze laatste dus niet getoond in de overlay. Versie

8 Vanaf nu worden de meest recente werknemertheoplanningen getoond die geldig zijn binnen de geldigheidsperiode van de particuliertheoplanning. Dit gebeurt via een eliminatieproces. Er wordt vertrokken van de werknemertheoplanningen die met optie alle zouden zichtbaar zijn. De werknemertheoplanningen worden één voor één met elkaar vergeleken aan de hand van volgende eliminatiecriteria: Bij twee theoplanningen van eenzelfde werknemer wordt van die twee enkel de theoplanning met de recentste startdatum overgehouden. Bij twee theoplanningen van twee verschillende werknemers wordt de theoplanning geëlimineerd die strikt vóór de andere ligt. Als ze elkaar deels/volledig overlappen dan worden ze in deze stap niet geëlimineerd. 11 (IGSE) #PRE: Controle op dubbele uurcode in Controls Management Probleem: Er worden dubbele uurcode (verkorte omschrijving) toegelaten in Controls Management Er kunnen in principe geen dubbele uurcodes bestaan in CheQpoint, maar er kunnen uurcodes worden toegevoegd met dezelfde betekenis van een reeds aanwezige uurcode. Hiervoor werd een extra beveiliging ingebouwd in CheQpoint. Voortaan moet de verkorte omschrijving uniek zijn. Wanneer deze niet uniek is krijgt de eindgebruiker een popupscherm met een waarschuwing (zie screenshot): Versie

9 12 (IGSE) #PRE: Verplichte uurcode voor prestaties in Controls Management De uurcode (verkorte omschrijving) van een prestatie is nu verplicht in te geven in Controls Management. Het veld staat ook in het rood afgedrukt als aanduiding dat het veld verplicht is. U krijgt een popupvenster als dit niet OK is: 13 (IGSE) #PRE: Bugfix - Fout bij het toevoegen van een prestatiecode in Controls Management Probleem: Er verschijnt een foutmelding bij het openen van het bewerkingsscherm bij een nieuwe prestatie (definitie). Versie

10 Het veld Heeft Limiet had geen standaardwaarde waardoor de waarde van het veld op null kwam. Dat genereert een fout want de waarde mag niet null zijn. De standaardwaarde werd programmotorisch op 0 gezet, wat betekent dat de prestatie geen verbruikslimiet (beginsaldo) heeft. 14 (KEAN) #KAN: hoofdkantoor in lijst van kantoorselectie altijd volledig bovenaan Vanaf nu staat het hoofdkantoor altijd volledig bovenaan de andere kantoren in de lijsten waar men een kantoor moet selecteren (dropdowns). Vroeger stond dit alfabetisch tussen de rest van kantoren. 15 (KEAN) #ALG: OPGELET: in de database tabel tblcode wordt de taal nu anders voorgesteld Tot nu toe werd in de codetabel voor een aantal zaken NL in de kolom van de taal gebruikt om Nederlands voor te stellen. Om toekomstige compatibiliteitsproblemen met WorkB te vermijden wordt nu in de plaats daarvan 1 gebruikt om Nederlands aan te duiden. Bestaande records in de tabellen code en tblcode zullen automatisch gemigreerd worden van NL naar 1 in deze CheQpoint versie. 16 (KEAN) #KAN: ondersteuning voor kantoorgroepen (clusters) toegevoegd Vanaf nu kunnen kantoren gegroepeerd worden in groepen (clusters). Een kantoor kan tot maximum 1 kantoorgroep behoren. Men kan dan in CheQpoint bepaalde operaties uitvoeren op clusterniveau in plaats van kantoorniveau. Het beheer van clusters en het toewijzen van kantoren aan clusters dient te gebeuren vanuit WorkB. Inschakelen van ondersteuning voor kantoorgroepen gebeurt aan de hand van de parameter MODULE_KantoorgroepenActief in tabel tblglobalsettings. Deze parameter moet de waarde 1 krijgen om de functionaliteit van kantoorgroepen te activeren. Wanneer de functionaliteit actief is, kan men in het hoofdvenster van CheQpoint een groep selecteren in plaats van een kantoor. Men kan ook nog gewoon een kantoor kiezen. In de lijst met kantoren rechts bovenaan staat achter de naam van elk kantoor de naam van de groep waartoe het kantoor behoort. Men kan dan via een keuzerondje aangeven of men het kantoor Versie

11 dan wel de hele groep wenst te selecteren. Wanneer een groep is geselecteerd dan worden in de lijst links in het hoofdvenster de werknemers of particulieren getoond van de hele groep in plaats van enkel het actieve kantoor. Wanneer de groep geselecteerd is zal ook in de vervangingsmodule de groep worden gebruikt om de lijsten bovenaan de tabbladen te vullen. Op alle plaatsen waar een kantoor geselecteerd kan worden en waar de mogelijkheid ALLE KANTOREN in aanwezig is zullen ook de kantoorgroepen beschikbaar zijn, en zal standaard de actieve groep in voorgeselecteerd zijn indien men in het hoofdvenster de [groep] optie heeft gekozen. In de lijst met kantoren staan de losse kantoren samen onder de groep waartoe ze behoren: Bovenaan in de lijst staat eerst de mogelijkheid ALLE KANTOREN indien de context toelaat dat die mogelijkheid beschikbaar is. Daar direct onder staat dan het hoofdkantoor. En daarachter komen de losse kantoren die niet tot een kantoorgroep behoren. En ten slotte komen alfabetisch alle groepen aan bod, met bij elke groep de kantoren die eraan gekoppeld zijn, alfabetisch gerangschikt: Versie

12 Versie