25

Release Notes Afdrukdatum: 2013/07/25

Dit document beschrijft vanuit technisch oogpunt de aanpassingen in Hi-Ant aan de betreffende versie. Deze tekst is geenszins bedoeld als document naar de eindgebruiker, maar wel voor de IT verantwoordelijken van de uitzendbedrijven die met Hi-Ant werken. Al deze informatie is confidentieel en mag niet zonder de schriftelijke toestemming van Prato in eender welke vorm verder gedistribueerd of reproduceerd worden. Deze teksten kunnen ook informatie bevatten van funktionaliteiten die niet van toepassing zijn op uw uitzendbedrijf en/of die enkel na bestelling geactiveerd worden. Het feit dat het uitzendbedrijf een onderhoudscontract en/of huurlicentie heeft lopen, impliceert geenszins het recht op de beschreven funktionaliteiten in dit document.

Release Notes Hi-Ant Versie 6.051

1/33

1.

V6.051 1.1.

Bugfixes

1.1.1. Onterecht melding i.v.m. klantengroep Klanten kunnen onterecht onderstaande melding te zien krijgen bij het openen van een klantenfiche:

Deze controle werd onterecht getriggerd.

1.1.2. Opslaan van contracten - Overflow Door een fout in de code kon men contracten die gekoppeld waren aan een bestelling met een hoge ID niet meer bewaren. Dit is nu opgelost.

1.1.3. Ingeven nieuw e-mailadres in WN-Fiche knipt eerste letter af Wanneer je een e-mailadres invult in de WN-Fiche opent zicht automatisch een venster waarin je het adres moet ingeven (gekoppeld aan WNCom). Indien je echter in 1 keer het e-mailadres ingaf, ging de eerste letter verloren bij het overgaan naar het nieuwe scherm. Door de 1ste toetsaanslag weet HiAnt dat het nieuwe scherm geopend moet worden, maar die toetsaanslag zelf ging verloren. Hierdoor kon je bij onoplettendheid adressen ingeven waarvan de eerste letter ontbreekt. Dit wordt nu correct opgevangen, HiAnt zal de 1ste toetsaanslag meegeven naar het nieuwe scherm. Op deze manier kan je zonder problemen in 1 keer het adres intypen.

1.1.4. Bug bij afdrukken mastercontracten Bij het afdrukken van mastercontracten wordt code aangesproken die aangepast was om automatisch de beste waarde voor het sociaal abonnement uit de km-tabel te halen. Dit mocht niet gebeuren en dit probleem is nu opgelost.

1.1.5. Maximum aantal items in een filterveld In de Prato-gridbrowse was het mogelijk om maximum 30 items kommagescheiden in te geven als filterwaarde. In sommige gevallen bleek dit echter niet voldoende te zijn. Het max. aantal items is verhoogd naar 500.

1.1.6. Conflict tussen verplicht maar disabled veld In het contractscherm wordt bij sommige klanten het veld “statuut bij aanwerving” ingesteld als verplicht, maar HiAnt blokkeert dit veld indien er reeds prestaties aan het contract hangen. Hierdoor kan je niet bewaren én het veld niet invullen.

1.1.7. Ticket 103711 - Minstens 1 functie verplicht in de WN-fiche In het verleden is er een controle ingebouwd in HiAnt waarmee je het toevoegen van minstens 1 “komt in aanmerking voor … functie” verplicht kon maken. Dit kan door parameter "frmwngeg1", "Controle", "FunctieAanmerkingVerplicht" aan te maken met


2/33

waarde 1. Het is echter onmogelijk om dit af te dwingen bij een nieuwe fiche aangezien deze bewaard moet worden voordat er een functie toegevoegd kan worden. Gebruikers die deze parameter activeren, zitten dus vast bij het aanmaken van een nieuwe fiche. De controle is nu aangepast zodat een eerste bewaaractie wel kan gebeuren zonder functie toe te voegen.

1.1.8. Verplichte velden bij aanmaak coëfficienten Bij het ingeven van een coëfficient was geen enkel veld verplicht. Bij het aanmaken van contracten waarbij deze coëfficienten gebruikt worden, wordt er echter van uit gegaan dat o.a. het veld type en jobstudent ingevuld zijn. Indien deze leeg zijn kan je met een coëfficient niets doen. Vanaf nu zijn de velden dus verplicht gemaakt bij het ingeven/bewerken van een coëfficient.

1.1.9. Filteren op rooster-lookupbox in contractscherm De lookupbox voor het rooster in het contractscherm bevatte een fout in de filtervoorwaarde. Hierdoor was het niet mogelijk iets manueel in te typen alvorens de selectie uit te voeren. Dit is gecorrigeerd.

1.1.10. Controlebestand niet geboekte MC Indien er MC’s niet geboekt kunnen worden, worden deze in een tekstbestand bijgehouden. De naam van dat bestand was echter vastgezet op “nietgeboekteMC.txt”, en die geeft problemen bij o.a. batchboeken van lonen, omdat telkens hetzelfde bestand overschreven werd. Vanaf nu wordt de bestandsnaam analoog aan de andere controlebestanden opgebouwd, en vooraf gegaan door “LR_”.

1.1.11. Ticket 95640 - Opvolgingen enkel laten afhandelen door de persoon aan wie ze toegewezen zijn Deze controle werd nog niet uitgevoerd wanneer je vanuit het WN-scherm op de knop “zet op afgehandeld” klikt in het tabblad Opvolgingen. Dit is nu wel het geval.

1.1.12. Ticket 105789 - Fout bij maximaliseren van ingavescherm loonformule Het ingavescherm van een loonformule kon je onterecht maximaliseren en gaf een fout wanneer dit gebeurde.

1.1.13. Ticket 105672 - Afprinten van vakantieattesten vanuit overzicht alle personen Het was onterecht mogelijk om vakantieattesten op te vragen vanuit het overzichtsscherm “alle personen”. Indien de geselecteerde lijn toevallig een wnnr had, en de rest van de lijst niet, dan ging HiAnt attesten van verkeerde personen aanmaken. Dit wordt nu afgeschermd met een foutboodschap. Vakantieattesten dienen steeds vanuit de werknemerslijst te gebeuren.

1.1.14. Velden “laatst gewijzigd” worden onterecht en/of niet correct ingevuld bij het overhevelen van contracten Tot nu werd bij het overhevelen het veld “laatst gewijzigd” ingesteld op de actuele datum, en het veld “laatst gewijzigd door” overgenomen van het broncontract. Beiden zijn eigenlijk niet correct. De velden “laatst gewijzigd” worden nu leeggemaakt bij het overhevelen en worden pas ingevuld bij het bewaren van een contract, omdat op dat moment de wijziging gebeurt. De creatiedatum wordt uiteraard wel ingevuld bij overheveling.


3/33

1.1.15. Persoonsfiche kan niet geopend worden vanuit zoekresultaat Wanneer je via werknemerslijst – gegevens > zoek – geavanceerd zoeken een zoekopdracht ingaf, kon je vanuit de resultaten geen fiches openen. Dit is nu aangepast.

1.1.16. Gegevens bewerken in opvolgingsgrid in de klantenfiche Tot op heden was het mogelijk om opvolgingen rechtstreeks in het grid in de klantenfiche te bewerken. Door de achterliggende structuur kon dit tot onvoorziene fouten en veranderingen leiden. Het bewerken werd daarom uitgezet. Wijzigingen zullen steeds in het detailscherm (dubbelklik) dienen te gebeuren.

1.1.17. Controlelijst Payroll toont verkeerde kantoornummer Op de controlelijsten Payroll werd verkeerdelijk het kantoornummer van de werknemer i.p.v. die van het contract getoond. Dit is gecorrigeerd.

1.1.18. Foute opvolgingsdatum bij aanmaak vanuit prestatieingavescherm Wanneer je van in het prestatieingavescherm een opvolging ingeeft, wordt de datum verkeerdelijk op “vandaag” gezet. Normaal wordt de begindatum van de actieve betaalperiode genomen, maar door een bug werd deze terug overschreven. Dit is nu opgelost.

1.1.19.Ticket 103554: Foutmelding in het opvolgingenoverzicht bij klikken op het menu Acties > Zet op afgehandeld Je krijgt een foutmelding omdat Hiant de opvolgingsdatum probeert aan te passen terwijl deze niet werd opgehaald. De opvolgingsdatum wordt nu wel opgehaald.

1.1.20.Ticket 104496: Foutmelding bij het openen van het bezoekrapportenoverzicht HiAnt geeft een foutmelding bij het selecteren van een bezoekrrapport indien het infoveld niet is ingevuld. HiAnt probeert de waarde van dit veld te tonen in de textbox onder de lijst. Technisch: HiAnt probeert de waarde uit het info-veld tonen in de multi-line textbox mldgeg onder de lijst. Indien de waarde van het Info-veld NULL is, krijg je een foutmelding. Code aangepast in ‘frmBezRapLst.BrwGeg_RowColChange’: mldgeg.text = ls(Rs1!info)

1.1.21.Ticket 105014: Foutmelding bij het openen van de veiligheidsfiche Als je de veiligheidsfiche van een gezin wil openen, gaat HiAnt eerst controleren of deze al bestaat. Indien dit niet het geval is, wordt er gevraagd of je een nieuwe veiligheidsfiche wil aanmaken. Als je hier ‘Nee’ kiest, krijg je de foutmelding ‘Object was unloaded’. Dit probleem is nu opgelost. Technisch: In de form_load, kan je geen unload doen. De controle is nu verhuisd naar een nieuwe publieke procedure ‘Initform’. Deze wordt vanuit ‘frmklgeg1’ opgeroepen voor de ‘frmVeiligheidsfiche.Show’. Deze laatste wordt niet meer uitgevoerd indien er voor gekozen werd om geen nieuwe fiche aan te maken. Nieuwe property aangemaakt in ‘frmVeiligheidsfiche’: Private booCancel As Boolean


4/33

1.1.22.Ticket 104300: Sortering datum in pool-lijst De datum wordt momenteel getoond als ‘dd/mm/yyyy’. Als je dan gaat sorteren op datum, wordt er gesorteerd op dag. De code is nu aangepast zodat de formatering van de datum via een parameter kan worden ingesteld. Deze parameter wordt ook al in de werknemerlijst en in de bezoekrapportlijst gebruikt. Param1 initialisatie

Param2 gridbrowse

Param3 dateformatcode

Waardes parameter:

Dus als de datum moet worden weergegeven als ‘yyyy/mm/dd’ moet er bij waarde 111 worden ingegeven. Technisch: Code toegevoegd aan ‘frmPoolMgt.Form_Load’

1.1.23.Ticket 105671: Foutmelding bij huisnummer met alfanumeriek karakter in WN-fiche Bij het aanmaken van een nieuwe WN-fiche met als huisnummer een alfanumeriek karakter, krijg je een ‘Incorrect sytax…’-foutmelding. Deze bug is nu gefixt. Release Notes Hi-Ant Versie 6.051

5/33

Technisch: Bij het wegschrijven naar de wnadres-tabel, werd het huisnummer niet tussen single quates gezet. Code aangepast in ‘MWnGeg.BewaarWn’.

1.1.24.Ticket 106055: Foutmelding bij toevoegen ecocheques aan bestelling indien je klantnummer meegeeft Als je ecocheques aan een bestand wil toevoegen, krijg je de keuze of je alle ecocheques wil toevoegen (-1) of voor een opsomming van klanten. Indien je hier 1 of meerdere klantnummers ingeeft, kreeg je een foutmelding. Dit is nu opgelost. Technisch: Er gebeurde een update-query van de ecocheques-tabel met in de where een verwijzing naar de klnr. Het veld klnr bestaat echter niet in de ecocheques-tabel. Het veld heet ecc_klnr in deze tabel. Code aangepast in ‘frmEcoCheques.CmdVoegToe_Click’.

1.1.25.Probleem binnen functie “VolgendItem” indien er “,1433” of “,1434” in de string met waardes zit Volgend probleem deed zich voor binnen functie VolgendItem. Binnen deze functie werd het volgende gedaan om het probleem op te lossen met een commandline met komma als separator en bij uzb waarbij de "SQL server name" een "poort-achtervoegsel" ",1433" of ",1434" bevat. Als het volgende item in de kommaseparated lijst gevolgd wordt door ",1433" of ",1434" dan wordt dit als achtervoegsel toegevoegd aan het item. Dit gaf natuurlijk een probleem indien men een lijst van loonrun- of contract-... items had die loonrun-id/contract-id 1433 of 1434 bevatte. Aan de numerische variabele waaraan de volgende loonrun-id of contract-id werd toegekend, werd dan bv. waarde "1432,1433" toegekend, hetgeen een fout gaf. De programmatie van de functie "VolgendItem" en de afhandeling van de commandline binnen projecten worddoc en nieuwloonbrief zijn aangepast: -de functie "VolgendItem" heeft nu een bijkomende optionele parameter "strParamToSearchValueFor". Enkel in geval "strParamToSearchValueFor" gelijk is aan "SERVER" of "DATA SOURCE", dan wordt er, indien er een ",1433" of ",1434" voorkomt, dit als achtervoegsel toegevoegd aan het item. -projecten worddoc en nieuwloonbrief, waarbij de items van de SQL-connectiestring apart worden doorgegeven (i.p.v. de connectiestring als geheel) geven nu bij ophalen van de waarde voor commandline-variabele "SERVER" of "DATA SOURCE" deze naam van de commandline-variabele mee aan functie VolgendItem.

1.1.26.Loonberekening: Multiple Step Error Men had een nieuwe looncode 629 aangemaakt en deze gebruikt. 629 is echter één gereserveerde code die men zelf niet mag aanmaken. Omwille van de char velden werd voor de ploegcode van de premie meer tekens in het doelveld gestopt dan mogelijk was, waardoor HiAnt deze melding gaf.


6/33

Naast het wijzigen van code 629 naar een andere code, werd er ook een aanpassing gedaan in de loonberekening waardoor de achterliggende spaties uit de waarde van het veld ploegcode van de premies werd gehaald.

1.2.

Aanmaak maaltijdcheques controle op negatieve aantallen of aantal gelijk aan 0.

Door de parameter "initialisatie", "maaltijdcheques", "AutoControleNegEnNul", "0" op 1 in te stellen kan men bij aanmaak van het maaltijdchequesbestand automatisch de negatieve aantallen van mcs terug klaarzetten voor een volgende bestelling, en de aantallen die op 0 uitkomen automatisch verwijderen uit de bestelling. Op databaseniveau wordt er een maaltijdcheques# tabel aangemaakt die de verwijderde maaltijdcheques gaat bijhouden.

1.3.

Aanpassing langetermijnplanning werknemer - indien parameter "initialisatie", "planning", "GezinnenAanpassenAfwezigheidLT", "0" op 1 staat

Als parameter "initialisatie", "planning", "GezinnenAanpassenAfwezigheidLT", "0" op 1 is ingesteld, wordt bij langetermijn “toevoeging van afwezigheid” gevraagd of de klanten die in de periode van afwezigheid vallen, vervanging wensen of niet. Aanpassing is gebeurd zodat bij verwijderen van een dergelijke langetermijn afwezigheid, de betreffende gezinnen terug op AD (gewerkte dag) gezet worden. Ook bij aanmaak van kalender zal het type 100 blijven (en niet aangepast worden naar 105), zodat bij hergenereren van kalender deze terug aangemaakt kan worden.

1.4.

Planningsmodule - OTV (op te vullen uren)

Aanpassing is gebeurd zodat men bij het invullen van een einddatum van een bestelling van een gezin, de langetermijnplanningen van de huishoudhulpen van deze gestopte bestelling kan doen verderlopen als een langetermijnplanning op een fictief gezin (Op te vullen uren – gezin). Te activeren door volgende parameter met waarde 1 aan te maken: "Scherm", "frmbestelgeg", "OpvullenOTVKlant", "0" Er dient bepaald te worden welke dagcode gebruikt moet gebruikt worden voor deze op te vullen uren. Dit wordt ingesteld met onderstaande parameter: "planning", "OTVKlant", "Code", "OTV" Standaard is dit ‘OTV’. Opgelet: je dient deze code ook aan te maken in de codedefinities op tabblad “Codes” in het onderste grid, en het tabblad “loonbrief” in het bovenste grid. Hier stelt men ook extra in of deze ‘OTV’ moet beschouwd worden als aanwezigheids- (1) of afwezigheidscode (2). Er dient een gezinsfiche aangemaakt te worden die zal gebruikt worden om een bestelling/deelopdracht aan te koppelen die fungeert als “op te vullen uren”. Éénmaal deze fiche is aangemaakt, dient men de kl.id van deze fiche in volgende parameter in te vullen. In geval men wil werken met één enkele gezinsfiche “op te vullen uren” dient dit als volgt ingesteld te worden: "planning", "OTVKlantId", "*", "0" -> in waarde komt de id van de aangemaakte gezinsfiche.


7/33

In geval men per kantoor een aparte gezinsfiche “op te vullen uren” wenst, dient men per kantoor een fiche aan te maken en per kantoor een parameter als volgt aan te maken: "planning", "OTVKlantId", <wgnr>, "0" -> <wgnr> moet dan het kantoornr zijn, en in waarde komt de id van de aangemaakte gezinsfiche van dat kantoornr. -Werking vanuit bestellingsdetailscherm Als men een bestelling van een lege einddatum naar een ingevulde einddatum brengt, zal het systeem de volgende vraag stellen aan de gebruiker (enkel indien geconfigureerd via bovenstaande instellingen): Wenst U de huishoudhulpen die aan deze bestelling hangen in langetermijn op "Op te vullen klant" zetten. Bij bevestiging zullen op de langetermijnplanningen van de betrokken huishoudhulpen, waarvan de einddatum leeg is, de langetermijn voor het gezin worden stopgezet (einddatum wordt ingevuld), en zal er een nieuwe langetermijn beginnen met begindatum gelijk aan de einddatum van bestelling + 1, en zal deze langetermijnplanning gekoppeld worden aan de “op te vullen uren” gezinsfiche/deelopdracht. Éénmaal alle betrokken huishoudhulpen zijn aangepast, wordt de kalender automatisch gegenereerd voor deze huishoudhulpen. -Werking vanuit langetermijnplanningsscherm werknemer Wanneer men in een langetermijnplanning bij de werknemer een lijn verwijdert van een koppeling met een gezin, en de einddatum is leeg, en vervolgens wordt deze einddatum ingevuld en wordt deze lijn terug toegevoegd, dan zal de gebruiker volgende vraag krijgen: Wenst U ook een langetermijnplanning aan te maken op de "Op te vullen klant". Bij bevestiging zal op de langetermijnplanningen van de betrokken huishoudhulp een nieuwe langetermijn beginnen met begindatum gelijk aan de einddatum + 1, en zal deze langetermijnplanning gekoppeld worden aan de “op te vullen uren” gezinsfiche/deelopdracht.

1.5.

Planningsmodule – Extra gewenste uren

Aanpassing is gebeurd zodat men in het rooster van de werknemer Extra gewenste uren kan instellen.


8/33

Hiervoor dient volgende parameter op 1 ingesteld te worden: "INITIALISATIE", "PLANNING", "SHOWEXTRAHOURS", "0" In het grid ziet men dan een extra kolom met omschrijving “Gu”. Door hier op te dubbelklikken kan men de gewenste uren invullen. In bovenstaand voorbeeld werkt de hhh 4u/week, maar is aangegeven dat de hhh 6u/week wenst te werken. In het planningsscherm ziet men dit dan in de blauwe kolom, waar dan gewenste uren/effectieve uren/contract uren komt te staan.

In dit overzicht worden de gewenste uren enkel getoond indien ingevuld en verschillend is van de effectieve uren. In het overzicht kan men ook gaan filteren tussen deze gewenste uren en de contracturen of gewenste uren en de effectieve uren. In de bovenbalk van het menu zijn dan extra filterknoppen te zien.

Deze filters zullen enkel werken op ingevulde gewenste uren. Dus de gewenste uren moeten groter zijn dan 0.

1.6.

Planningsmodule - langetermijnplanning op gezinsniveau (afwezigheid)

In het deelrooster van gezin/bestelling kan men nu ook langetermijn afwezigheid instellen op gezinsniveau:

Men kan hier enkel afwezigheidscodes invullen (typeaanwezigheid=2). Bij aanmaak van de kalender zullen eerst de gewone items van het gezin worden aangemaakt, daarna worden de codes met type 100 tussen de ingestelde begin- en (al dan niet ingevulde) einddatum van de langetermijn op de ingestelde afwezigheidscode gezet worden. Het type blijft onveranderd op 100 staan. Release Notes Hi-Ant Versie 6.051

9/33

1.7.

Loonbrief nieuwe lay-out - tonen van de code 392 Totaal bruto rsz

Er is een aanpassing gebeurd aan rapport voor nieuwe lay-out van loonbrieven, waarbij het mogelijk is om de looncode ‘392’ (totaal bruto rsz) te tonen in de samenvatting. Hiervoor dient het startdocument “LoonbriefV3.rpt” (of LoonbriefV3.rpt) aangepast te worden. Dit kan aangevraagd worden via [email protected] Na installatie van het nieuwe startdocument kan men met volgende queries dit verder instellen: insert into availablecodesGroup (GroupCD,cd_srt,AllCodesRequired,Param1Text,Param1DefaultValue,Param2 Text,Param2DefaultValue) select '101LBBRUTORSZ',cd_srt,AllCodesRequired,Param1Text,Param1DefaultValue ,Param2Text,Param2DefaultValue from availablecodesGroup where GroupCD='100LBBRUTO' update AvailableCodes set GroupCD='101LBBRUTORSZ' where code='392' insert into parameter (param1,param2,param3,waarde,user_crea,ts_crea,user_wijzig,ts_wijzig, cdKey,Keywaarde,RSZCategorie,cd_taal) values ('Afdruk', 'loonbrief', 'GroupsSamenvatting', '''100LBBRUTO'',''101LBBRUTORSZ'',''200LBBELASTBAAR'',''400LBNETTO'', ''500LBINFO''','tose',GETDATE(),'tose',GETDATE(),'UZC','0','ALG',0)

Voorbeeld:


10/33

1.8.

Planningsmodule - aanpassingen in detail grid

Er is een aanpassing gebeurd op de manier waarop men een detailregel kan wijzigen. Vroeger kon men rechtstreeks in het grid aanpassingen doen, maar hierbij traden soms foutmeldingen op die niet traceerbaar waren. Vanaf nu dient men dus, om een aanpassing te doen aan een detailregel, te dubbelklikken op deze regel.

Na het dubbelklikken krijgt men een detailscherm te zien, waarin men aanpassingen kan doen:

Voor het toevoegen van een detailregel dient men op het “+” knopje boven het detailgrid te klikken. Voor het verwijderen van een detailregel dient men op het “-“ knopje boven de detailgrid te klikken (of via de del-toets op een planningsitem in bovenste grid).

1.9.

Jaarverslag ongevallen - berekenen frequentiegraad

Het bepalen van het aantal ongevallen voor het berekenen van de frequentiegraad van de ongevallen kan rekening houden met “enkel de aanvaardde” ongevallen.


11/33

Hiervoor dient de volgende parameter op 1 ingesteld te worden (standaard = 0): "ongevallen", "frequentiegraad", "enkelaanvaardeongevallen", "0"

1.10. Arbeidsongevallen - aanpassing statistieken + rapportjes Vanuit arbeidsongevallen kan men statistieken trekken. Hier zijn aanpassingen gebeurd zodat er gebruik wordt gemaakt van unieke bestandsnamen. Ook opbouw/aanmaak van deze statistieken en de rapportjes ervan zijn aangepast Volgende nieuwe rapportjes zijn hiervoor nodig: - ongStat.rpt - ongStat3.rpt - ongStat4.rpt

1.11. Aanpassingen scherm “bestellen maaltijdcheques” De lay-out van het bestelscherm voor maaltijdcheques is gewijzigd. Bovenaan ziet men de aangemaakte bestellingen, waarbij men kan filteren op de id of naam van de bestelling, en op het al dan niet afgesloten zijn van deze bestelling (0/1).

Ook in het overzicht van de bestellingen ziet men welke gebruiker de bestelling heeft aangemaakt, en eventueel heeft afgesloten. De aanmaak/ en afsluitingsdatum zal voortaan ook met tijd worden bewaard. Ook wordt bij elektronische maaltijdcheques de bestandsnaam getoond die werd aangemaakt. Onderaan ziet men 2 tabs.Op de eerste tab ziet men de maaltijdcheques die in de actieve bestelling zit (door een dubbelklik op bestaande bestelling in bovenste grid te doen).


12/33

Op de tweede tab ziet men een overzicht van de maaltijdcheques die nog niet zijn opgenomen in een bestelbestand. Op dit grid kan men enkel zoeken. Er zijn geen verdere acties op dit grid geprogrammeerd.

Indien men “verwijder datum afsluiting” zou doen, wordt dit gelogd in de logtabel met type 118. De bestandsnaam in het grid wordt na aanmaak van het elektronisch maaltijdchequebestand opgevuld indien de installatie is gebeurd van de laatste dll’s m.b.t. elektronische maaltijdcheques, in combinatie met deze versie van HiAnt.

1.12. Aanpassingen batch loonberekening Men kan nu bij batchloonberekening de batch opstarten en laten lopen. Vroeger werd de gehele batch maar één keer doorlopen. Nu kan men dit proces laten lopen en doen stoppen door op de Stop-knop te klikken. Ook is er nog altijd de mogelijkheid om de batch éénmaal te doorlopen door het vinkje “Doorloop batch één keer” aan te vinken. Nadat de batch is doorlopen, zal er 10 seconden worden gewacht alvorens de volgende doorloop start. In die tijd kan men op de Stop-knop klikken. Rechts is ook een overzichtlijst te zien van de geblokkeerde loonruns. Men kan via het apart .NET project voor dashboard bepaalde loonruns op blokkeren zetten. Deze zijn dan te zien in deze lijst. De geblokkeerde loonruns worden niet meegenomen in de doorloop van de batch.


13/33

1.13. Aanpassing PratoDashBoard Loonberekening Batchdashboard: mogelijkheid om loonruns te blokkeren / deblokkeren. Zichtbaar maken of de loonruns geblokkeerd of gedeblokkeerd zijn. De gebruiker kan door rechts te klikken op een kantoornummer om de loonrun van dat kantoor te blokkeren of te deblokkeren. Als het kantoor geblokkeerd is, dan zal het kantoornummer in witte letters op een zwarte achtergrond staan:


14/33

1.14. Ticket 103669 - docs in verkeerde taal Binnen HiAnt is de functie voor het ophalen van de taal van een tewerkstellingsattest en een inlichtingsblad aangepast waardoor er bij afdruk van dit document niet meer wordt gecontroleerd op wnnr (voor kandidaten = 0) maar op het koppelid.

1.15. Ticket 104855 - Taalinstellingen Parameter "Afdruk", "individuelerekening", "ControleTaal" standaard = UIT waarde 0 = UIT waarde 1 = AAN Het document Individuele rekeningen is in HiAnt aangepast zodat de taal van het document bepaald wordt via de getdocutaal (taalwetgeving).

1.16. Ticket 105485 - Activa aanvragen: lijst met adressen ter merging C63 (klantspecifieke aanpassing) Documenten op newsource: LeegC63Werkkaart_klant.doc LeegC63WerkkaartFR_klant.doc De documenten die hierboven vernoemd zijn, bevatten naast de C63 een voorblad waarop de adresgegevens van de RVA komen te staan met de tekst van de aanvraag. Bij het afdrukken van de intentieverklaring (knop inlichtingsblad op WN-fiche) zal HiAnt de controle uitvoeren of er voor de betreffende WN een C63 moet afgedrukt worden als de parameter "Afdruk", "Inlichtingsblad", "ControlePrintC63" de waarde 1 bevat.


15/33

De parameter "Afdruk", "C63", "MetRVAadres" met waarde 1 geeft vervolgens aan dat HiAnt het RVA adres dient op te halen. De adressen van de RVA zijn terug te vinden in de nieuwe tabel RVA_adres. Op basis van de postcode bij de adres van de WN zal HiAnt de tabel postcodes raadplegen waarin zich een nieuw veld RVA_code bevindt. Dit veld komt overeen met het adres van het toegekende RVA kantoor in de tabel RVA_adres dat aan die postcode werd gekoppeld. Op dat voorblad komen ook de kantoorgegevens te staan van het WG-kantoor. Standaard wordt telkens het gekoppelde kantoor afgedrukt. Voor een centrale afdruk kan men dit adres koppelen aan 1 kantoor met de parameter "Afdruk", "C63", "KantoorCentraleAfdruk". De waarde is dan gelijk aan het WGNR. Om deze uit te schakelen dient men de parameter de waarde 0 te geven. Mocht om één of andere reden het kantoor van deze parameter niet gevonden worden, dan zal HiAnt de standaard werking voortzetten. Beneden het voorbeeld van dat voorblad:

1.17. Ticket 104487 - geen namen op factuur Via de klantoptie TGW zal HiAnt aan de Factuur meegeven dat de namen van de WN NIET getoond zal worden. Achterliggend wordt wel de sortering behouden op WN indien deze sortering uiteraard aanwezig is. Let wel op dat deze functionaliteit in het Crystal Reports-document dient ingebouwd te worden indien men wenst van deze optie gebruik te maken.


16/33

1.18. Ticket 101612 - vragensets intentieverklaring + C63 HiAnt Parameter "scherm", "FrmWnGeg1", "ControleInlichtingsblad" met waarde 4 Extra keuze "Document infosessie OK" komt tevoorschijn. HiAnt beschouwt het document als zijnde afgedrukt en zal de opvolgingen aanmaken.

Parameter "Control", "printc63", "InfoSessie" met waarde 1 NOTA: parameter "controle", "printc63", "isVerplicht" MOET 0 zijn voor deze optie! Extra keuze "Document infosessie OK" komt tevoorschijn. HiAnt beschouwt het document als zijnde afgedrukt en zal de opvolgingen aanmaken.

1.19. Ticket 105894 - Uitbreiding keuzemogelijkheid Parameter "scherm", "FrmWnGeg1", "ControleInlichtingsblad" met waarde 4 Het keuzescherm wordt met deze parameter verder aangevuld met een extra keuze-item "Intensieverklaring ontvangen via -email". HiAnt beschouwt het document als zijnde verzonden via e-mail en zal hierbij ook een nieuwe opvolging aanmaken die dat aantoont. Dze nieuwe opvolging "Intensieverklaring via e-mail" dient men aan te maken en in te geven in de parameter "Codeboekcode", "OpvolgingsType", "inlichtingsBladViaMail".


17/33

1.20. Ticket 102112 - Aanpassingen prestatiestaat planningmodule Volgende parameters werden ingebouwd om enkele extra opties te voorzien bij het afdrukken van de prestatiestaat vanuit het planningscherm: Parameter: "PrestatieStaat", "Afdruk", "ToonContactMedewerker" Indien waarde = 1 (standaard = 0) zal HiAnt op de prestatiestaat de naam van de medewerker tonen i.p.v. de contactpersoon van de dienstverlener. Parameter: "PrestatieStaat", "Afdruk", "ToonUrenPerKlant” Indien waarde = 1 (standaard = 0) zal HiAnt de gepresteerde uren tonen per klant i.p.v. per dag. Parameter: "PrestatieStaat", "Afdruk", "ToonRijWeek Indien waarde = 1 (standaard = 0) zal HiAnt een extra rij tonen op de prestatiestaat per week met daarin uiteraard de vermelding van de week.

1.21. Ticket 106167 - klantencontracten printen Parameter "Afdruk", "optie", "KlantContactSplitsWeek" (standaard 0 = UIT) Indien je bovenstaande parameter de waarde 1 geeft, dan zullen de klantcontracten bij het afdrukken gesplitst worden per week.

1.22. Zichtbare klanten in Beheer Slogan-scherm In het scherm Beheer Slogan is de mogelijkheid toegevoegd om “incl. steunkantoren” aan te vinken. Hiermee kan je ervoor zorgen dat de klantenlijst die gevuld wordt al dan niet rekening houdt met steunkantoren i.p.v. enkel het actieve kantoor.

1.23. Ticket 102563 - Paritaire comités onzichtbaar zetten Door op de codetabel bij cd_srt 203 een einddatum in te vullen bij een Paritair Comité, wordt ervoor gezorgd dat deze niet meer zichtbaar is in de selectiebox op de klantenfiche. Deze vraag kwam naar aanleiding van het niet meer gebruiken van PC 111, aangezien er nu steeds het subcomité gebruikt moet worden.


18/33

1.24. Ticket 102002 - Chequelevernota in grid bij ingave cheques “Zou het mogelijk zijn om naast de kolom "Controle" het afleveringsnummer te voorzien waarop de DC werden geboekt ? Het is nu niet mogelijk om na te gaan op welke afleveringsnota, welke dienstencheques geboekt werden.” Vanaf nu wordt de kolom LevernotaNr getoond in het scherm voor chequesingave.

1.25. BTW-plichtigheid instellen bij nieuwe klanten Standaard werd het BTW-veld altijd op Ja ingesteld vanuit de code. Dit kan nu gestuurd worden via parameter “scherm", "frmklgeg1", "standaardBTWplichtJN". Deze kan de waardes J of N hebben. Standaard blijft er uiteraard J ingesteld staan.

1.26. Ticket 103438 - Aanpassen coëfficiënt firmawagens Tot nu stond de VAA op jaarbasis = [5,5% + (CO2 - 115) x 0,1%] x (cataloguswaarde x ouderdomscorrectie*) x 6/7. Het getal 115 stond echter vast in de code. Vanaf 1 april moet dit 116 worden. Om dit in de toekomst te vergemakkelijken kan je deze waarde nu in parameters opnemen. De parameter wordt als volgt opgesteld: Param1 = co2coef Param2 = dit is ofwel “benzineLPG”, ofwel “diesel” Param3 = de datum vanaf wanneer deze waarde gebruikt moet worden, in te geven in het formaat YYYYMMDD. Bijvoorbeeld: 20130401. Waarde = te gebruiken bijdrage.


19/33

Standaardwaardes: benzineLPG = 115 diesel = 95 Electrisch blijft vast op 0 staan in de code. In Mcommonfunctions zit een nieuwe functie die voor HiAnt en Sonet de berekening kan doen: '--------------------------------------------------------------------------------------' Procedure : BepaalCO2Bijdrage ' Author : … ' Date : 19/04/2013 ' Purpose : Gaat CO2 bijdrage voor pratocompanycar opzoeken in de parameters '--------------------------------------------------------------------------------------' Public Function BepaalCO2Bijdrage(fueltype As String, fromDate As Date) As Double

1.27. Ticket 103024 – Aanpassing lijst: Facturatieoverzicht Sociaal Abonnement “Jullie hebben voor ons een lijst ontwikkeld voor de berekening van de facturen voor het sociaal abonnement in ons dienstenchequeskantoor.Kunnen jullie aan de output van de lijst in Excel het klantnummer toevoegen? Tot nu toe krijgen we enkel de klantnaam.”

Aan deze lijst (mnuDC(2)) werd dus het klantnummer toegevoegd als 1ste kolom.


20/33

1.28. Ticket 102629 – Federgonlijsten “Voor het aanmaken van sommige Federgonlijsten, wordt er gewerkt met een referentiedatum. Voor de Driemaandelijkse statistiek dienstencheques, wordt hier de einddatum van het kwartaal genomen. Het probleem is nu dat als deze datum op een zaterdag of zondag valt, de lijst niet representatief is.” HiAnt gaat nu kijken of deze einddatum in een weekend valt. Indien dit het geval is, krijgt de klant de mogelijkheid om deze datum aan te passen naar bv. de vrijdag voordien.

1.29. Kolom resterend aantal dagen jobstudent in controlelijst Aan de lijst onder het menu Lijsten - Controlelijsten - Studenten - Overzicht gewerkte dagen is een extra kolom toegevoegd achteraan. Deze toont het aantal resterende dagen voor deze persoon.

1.30. Bestellingsnaam en -type vergrendelen voor bestaande bestellingen Door parameter "scherm", "frmBestelGeg", "LockNameAndType" aan te maken met waarde 1 kan je er voor zorgen dat de naam en het type van een bestaande bestelling niet meer kunnen worden gewijzigd.


21/33

1.31. Sloganbeheer - Type 4 ook zichtbaar De hele opzet van 5 & 6 is dat ze vasthangen aan een klant (of ook een werknemer). Slogantype 4 kan echter ook algemeen los van de klant gebruikt worden. Type 4 gebruiken om aan een klant te koppelen, is in principe geen probleem. De programmatie is aangepast zodat Type 4 inderdaad zichtbaar is, maar dit zal ALTIJD gekoppeld worden aan een klant.

1.32. Ticket 104829 - Controle op geldig roosterid bij overhevelen Bij het overhevelen van een contract wordt gecontroleerd of er een geldig roosterid gekoppeld is. Dit is op vraag van DC klanten. Indien de betreffende roosterid ontbreekt (leeg is), dan meldt de module dat het contract van wn X met wnnr 1234 van week 19 niet kan worden overgeheveld naar week Y vermits er geen rooster geselecteerd is in het contract. De controle kan geactiveerd worden door parameter "controle", "overhevelen", "geldigRoosterId" aan te maken met waarde 1. Standaard staat de controle uit.

1.33. Ticket 99421 - Controle medisch onderzoek in WPF bij opslaan contract “Indien er in de WPF aangevinkt wordt dat er een medisch onderzoek verplicht is OF een gezondheidsbeoordeling uit te voeren voorafgaand aan de tewerkstelling, dan willen wij graag dat er een waarschuwing wordt gegeven hiervan indien er op de bewaarknop wordt geklikt van een eerste contract tussen de betreffende klant en een uitzendkracht.” Indien je parameter "contract", "controleerWPF", "medisch" aanmaakt met waarde 1, dan gaat HiAnt bij het opslaan van een eerste contract tussen WN en KL controleren of er in de werkpostfiche - die gekoppeld is aan de tarificatie - ofwel een verplicht gezondheidstoezicht gekoppeld is, ofwel het vinkje “medisch onderzoek” is aangevinkt. Indien een van deze, of beide, het geval is, dan zal de gebruiker een waarschuwende melding krijgen. Het contract wordt steeds verder opgeslaan, deze controle is NIET blokkerend.

De meldingen zijn standaard: “gezondheidstoezicht verplicht” en “medische controle verplicht”. Deze kunnen vertaald worden via vertaalcode prest_WPF_gezondheidstoezicht en prest_WPF_medischonderzoek aan te maken in de vertaalUZB tabel indien gewenst.

1.34. Ticket 104178 - Attesten aanduiden als read-only In HiAnt 6.48 werd onderstaande voorzien: In een nieuwe parameter 'controle', 'attesttypes', 'readOnly' kan je attesttype-ID’s opsommen (kommagescheiden) die niet gewijzigd mogen worden. Deze parameter is nooit geldig voor programmeurs. Om voor andere gebruikersgroepen (bv. CO’s) uitzondering te maken dien je dus aparte parameters aan te maken (keywaarde).


22/33

Wanneer een gebruiker een alleen-lezen attest opent, worden alle velden geblokkeerd en wordt er een boodschap getoond. Deze functionaliteit werd uitgebreid om te kunnen specifiëren op attestdetailtype. De parameterwaarde dient als volgt ingevuld te worden: :, :, …, , … Bv. je wil attesttype 24 met detailtype 2 read-only maken, alsook attesttype 32. De parameterwaarde is dan 24:2, 32.

1.35. Ticket 103067 - Automatische afdruk C63 bij verlaten van WNfiche Het is nu mogelijk om bij het sluiten van een WN-fiche automatisch het document C63 naar de printer te sturen. Dit gebeurt bij mensen tussen 18 en 26 voor wie de afdruk nog niet gebeurd is. Om dit te bepalen wordt er gekeken of er opvolging van het type C63 bestaat. Het bestaande opvolgingstypeid dat gebruikt wordt bij o.a. documenten UZB dient gespecifieerd te worden in parameter "Codeboekcode", "opvolgingstypeid", "C63". Verder moet je een nieuwe parameter "Codeboekcode", "opvolgingstypeid", "C63AutoAfdruk" aanmaken met daarin het opvolgingstypeid van een opvolging die je zelf kan aanmaken, bv. C63 Auto Print. Op deze 2 opvolgingen wordt gecontroleerd om te bepalen of het document gedrukt moet worden of niet. Indien je geen nieuwe opvolging wilt maken hiervoor, moet je toch deze parameter aanmaken, maar kan je bv. dezelfde waarde als "Codeboekcode", "opvolgingstypeid", "C63" gebruiken. Je kan deze functionaliteit activeren door parameter "Controle", "Afdruk", "AutoC63BijVerlatenWN" aan te maken met waarde: 1. Het document wordt op de achtergrond aangemaakt en rechtstreeks naar de standaardprinter gestuurd, zonder melding of input van de gebruiker. 2. Het document wordt geopend in Word, maar niet geprint. Er wordt automatisch een opvolging aangemaakt. De omschrijving hiervan kan je eventueel bepalen door een vertaling aan te maken met code “OmschrijvingOpvolgingC63AutoAfdruk”. Standaard wordt de tekst "Document automatisch afgedrukt bij afsluiten fiche" gebruikt.

1.36. Ticket 104774 - Opvolging 1e contract - aanpasbare omschrijving Tot nu toe kon je in de parameter "INITIALISATIE", "NIEUWCONTRACT", "Tekst", "" de te gebruiken omschrijving (of vertaal-code) definiëren die in de aangemaakte opvolging kwam te staan. Dit was dus echter steeds een vaste tekst. Het is nu ook mogelijk om hier een veldnaam te gebruiken i.p.v. een tekst, om zo bv. de waarde uit het veld “opmerking” uit het contract als omschrijving te gebruiken in de opvolging. De waarde van de parameter is dan dtbgeg(58). Dit is analoog aan het onderwerp van de opvolging, wat je kon definiëren in parameter "INITIALISATIE", "NIEUWCONTRACT", "OpvolgingMetOnderwerpUitVeldNaam".

1.37. Ticket 105519 - Lookupbox Werknemers in opvolgingsdetail onduidelijke bij identieke namen “Als men een opvolging ingeeft en men wil een uzk kiezen, maar hij bestaat meerdere keren, dan kunnen de uzc niet weten welke ze moeten kiezen want het koppelid zegt hun niets aangezien het niet zichtbaar is voor hun. Kan deze keuzelijst aangepast worden zodat in de toekomst het wnnr getoond wordt want dit hebben de uzc ook voorhanden.” Release Notes Hi-Ant Versie 6.051

23/33

De wnnr werd toegevoegd in het lijstscherm van WN’s:

1.38. Uitbreiding controle sekties bij opstart HiAnt Bij opstart van HiAnt wordt er gecontroleerd of het veld tabrsz van de sektie tabel één van volgende waarde bevat: 10,17,60,97,224,226,244,254,597,497. Vanaf nu kunnen deze waarden uitgebreid worden in de parameter "initialisatie", "MogelijkeSekties", "*". Standaardwaarde van de parameter is 10,17,60,97,224,226,244,254,597,497.

1.39. Ticket 99020 : companycar Als een nieuwe fiche aangemaakt wordt, dan staat het vinkje t.l.v klant in het grijs. Dit moet standaard uitgevinkt staan. De code is aangepast zodat dit default niet aangevinkt is.


24/33

1.40. Aanpassing programmatie aanmaak prestaties op basis van contract: mogelijkheid om STEEDS verschillende prestatielijnen aan te maken per dagdeel, ook als er niet bij elk dagdeel een verschillende afdeling voorkomt Indien men een parameter ("PrestatieIngave", "afdeling", "*") heeft met waarde 1, dan worden er verschillende prestatielijnen aangemaakt per dagdeel in het contract, maar enkel als er een VERSCHILLENDE AFDELING in het contract is ingevuld per dagdeel. Indien men dus binnen het contract GEEN verschillende afdelingen had ingevuld per dagdeel, werd er maar 1 prestatielijn aangemaakt met het totaal aantal uren. Dit kan problemen opleveren, bv. In het geval men een contract heeft dat op zaterdag begint en eindigt op zondag en men een correcte berekening van bv. zaterdagpremie wil (enkel berekening van zaterdagpremie voor de uren die op zaterdag vallen). Bijvoorbeeld: er is een contract dat op zaterdag begint en op zondag eindigt met als uren voor dagdeel 1 van 14u. tot 18u. en als uren voor dagdeel 2 van 22u. tot 2u. Als er geen verschillende prestatielijnen zijn voor de verschillende dagdelen, is er ook geen info aanwezig van wanneer dagdeel 1 stopt en wanneer dagdeel 2 begint. In dit geval is dus eenvoudigweg ook niet de info aanwezig i.v.m. hoeveel uren er moeten gerekend worden voor zaterdagpremie. De programmatie i.v.m. prestatie-aanmaak op basis van de contracten is nu verder aangepast: Als men parameter ("PrestatieIngave", "afdeling", "*") heeft met waarde 1, dan worden er toch STEEDS meerdere prestatielijnen aangemaakt (ook als er geen VERSCHILLENDE afdelingen zijn of dus ook als de afdelingen beide leeg) indien men een parameter ("PrestatieIngave", "ZelfdeAfdeling", "UrenSamenNemen") aanmaakt met waarde 0.

1.41. Aanpassing export naar GroepS voor de bouw: 1) bepalen per kantoor het gaat om bouw of niet 2) enkel toelaten dat er OF loongegevens voor bouw-kantoor of loongegevens van nietbouw-kantoor worden geëxporteerd 3) belangrijkheidscode firma (aantal wn) doorsturen bij bouw 4) uurloon van eerste contract week doorsturen bij de persoonsinfo De export naar GroepS is aangepast voor de uitzendbedrijven die ook uzk tewerkstellen in de bouw. -Er wordt bepaald per kantoor of het gaat om de bouw of niet, en dit ahv van het voorkomen van arbeidersekties met parkom 124. Een bouwkantoor mag dan ook enkel contracten hebben voor arbeiders met een bouwsektie (parkom 124). Wel alle bediendesekties mogen gebruikt worden bij dit kantoor. -Bij de export van loongegevens naar GroepS wordt er bepaald of er lonen met sekties uit de bouw in zitten. Het is enkel toegelaten dat er OF loongegevens voor een bouwkantoor OF loongegevens van een niet-bouwkantoor samen worden geëxporteerd. -Bij export van loongegevens van de bouw wordt de belangrijkheidscode van de klant (aantal wn) doorgestuurd via een code 094 binnen de 011-lijnen. Dit gebeurt ook bij de bedienden uit de bouw (mag volgens GroepS). -Bij doorsturen van persoonsinfo binnen de signaletiek wordt nu ook het uurloon van het eerste binnen de loonperiode doorgestuurd. Dit gebeurt zowel bij de niet-bouw als bij de bouw.


25/33

Gegeven BBB wordt opgevuld met het uurloon. Gegeven CBB wordt opgevuld met waarde 4 (= code uurloon). Indien een uzk nog geen contract heeft binnen de periode (bv. bij doorsturen enkel signaletiek zonder loongegevens voor een pas aangemaakte uzk die nog geen contract heeft) wordt BBB en CBB opgevuld met 0.

1.42. Loonberekening voorzien van juiste berekening voor jobstudent gelegenheidsarbeider Voor een jobstudent seizoensarbeider dient het RSZ-percentage bepaald te worden zoals bij jobstudenten en de basis waarop de RSZ berekend wordt (392), dient bepaald te worden a.d.h.v. het dagforfait voor de gelegenheidsarbeider. Deze berekening was tot nu toe nog niet voorzien. De basis voor de RSZ-berekening werd tevoren altijd bepaald a.d.h.v. het dagforfait voor gelegenheidsarbeiders bij sekties waarbij de wswncode op 10 staat. Echter bij jobstudent gelegenheidsarbeiders staat de wswncode op deze van de jobstudenten. Om de correcte berekening mogelijk te maken is nu de sektie-tabel uitgebreid met een veld “forfaitair”, 0 bij niet-gelegenheidsarbeiders en 1 bij gelegenheidsarbeiders. De loonberekening werkt nu als volgt: -Bij sekties waarbij “forfaitair” op 1 staat, wordt de basis waarop de RSZ berekend wordt (392) bepaald a.d.h.v. het dagforfait. Overzicht van de geldende dagforfaits: Voorkode = 90 (gehele getal van PC arbeiders = 302) momenteel dagforfait = 23.23 Voorkode = 91 (gehele getal van PC arbeiders = 144) momenteel dagforfait = 19.02 Voorkode = 99 (gehele getal van PC arbeiders = 145 en het PC verschilt van 145.04) momenteel dagforfait = 18.58 - Op deze basis voor de RSZ-berekening wordt het RSZ-percentage van de jobstudenten toegepast, momenteel 2.71%.

1.43. Aanpassing programmatie i.v.m. “Loggen naar logtable bij toevoegen eerste loon/herziening aan loonrun” Sinds enige tijd wordt het toevoegen van een uzk aan een loonrun gelogd binnen de logtable bij type 106. Hierbij was het zo dat er een lijn gelogd werd per contract dat voorkwam voor de betreffende uzk binnen de betreffende betaalperiode. De programmatie is nu aangepast zodat er maar 1 lijn meer wordt gelogd voor de betreffende uzk.

1.44. Aanpassing export naar GroepS: mogelijkheid (parametriseerbaar) dat voor de 001-records de kantoornaam niet gehaald wordt uit veld wg.naam maar uit veld wg.kantoornaam Binnen de 001-records (definitie van de niveaus van de bijkomende info die men samen met de loongegevens doorstuurt) is het zo dat niveau 1 steeds de kantoor-info bevat. Binnen de 001-records verschijnt dan ook voor niveau 1 voor elk kantoor de vermelding van het kantoornr en de kantoornaam. Voor de kantoornaam werd steeds veld wg.naam gebruikt.


26/33

Echter bij sommige uitzendbedrijven is het zo dat bij elk kantoor hier de algemene naam van het uitzendbedrijf verschijnt bv. “interimbedrijf… NV”. Men wil echter dat in de interface met GroepS de werkelijke kantoornaam wordt vermeld. De programmatie van de export is nu aangepast zodanig dat parametriseerbaar is uit welk wgveld de kantoornaam wordt gehaald. Standaard wordt de kantoornaam gehaald uit veld wg.naam. Indien men een parameter ("ExportLoonGroepS", "Niv1_WgInfo", "NaamAhvVeldKantoornaam") aanmaakt met waarde 1, zal echter de naam van het kantoor gehaald worden uit veld wg.kantoornaam.

1.45. Veranderde werking voor Securex-exporters bij “beheer mastercontract” waarbij men de uren wijzigt - vanaf nu komt er een vraag naar de gebruiker om te selecteren met welk rooster men het eerste subcontract wil laten beginnen Volgende programmatie-aanpassing geldt voor de Securex-exporters, binnen “beheer mastercontract” wanneer men “Maak nieuwe periode aan binnen geselecteerde master” uitvoert:

Het is zo voor de Securex-exporters bij “beheer mastercontract” waarbij men de uren wijzigt dat, tenminste voor het geval waarbij de nieuwe master-periode enkel nog niet verloonde subcontracten bevat, enkel het eerste subcontract wordt overgehouden. Tevoren kreeg men, na aanmaak van de nieuwe cyclus en roosters enkel onderstaande melding.


27/33

De gebruiker diende dus het eerste subcontract te openen en het juiste rooster, waarmee men het eerste subcontract wil laten beginnen, te selecteren. Sommige gebruikers negeerden deze melding, met als gevolg dat er voor de DC-er één of, tengevolge van overhevelen, meerdere subcontracten voorkwamen waarbij er geen rooster-info voorkwam. Terwijl de rooster-info verplicht is voor export naar Securex. De programmatie van HiAnt is nu aangepast zodanig dat, na invulling van de nieuwe cyclus en roosters, de gebruiker de vraag krijgt om het gewenste rooster voor het eerste subcontract te selecteren. Deze veranderde programmatie geldt zowel voor de gevallen 1) waarbij men een nieuwe masterhistoriek toevoegt aan het einde van de bestaande master en 2) waarbij men een nieuwe masterhistoriek toevoegt aan het begin van de bestaande master en 3) waarbij men een nieuwe masterhistoriek toevoegt middenin een bestaande master. De gebruiker krijgt een duidelijk overzicht van de te selecteren roosters, met vermelding van rooster-id, volgnr van het rooster binnen de cyclus, omschrijving van het rooster en een opsomming van de dagdelen binnen het rooster, met vermelding van uren. Na selectie van het gewenste rooster, wordt dit rooster ingevuld binnen het eerste subcontract en worden binnen het contractrooster van dit eerste subcontract de uren ook ingevuld overeenkomend met het geselecteerde rooster.

1.46. Aanpassing werking “parametriseerbare controles uitgevoerd bij druk op bewaartoets” (checkfields) - ingevulde errortype hoofdletterongevoelig gemaakt Er zat nog een probleem bij de “parametriseerbare controles uitgevoerd bij druk op de bewaartoets” (checkfields) - indien men bv. bij errortype “askuser” ingaf, werd er toch geen vraag aan de gebruiker gesteld. Dit was te wijten aan het feit dat in code de controle gebeurt


28/33

op waarde “ASKUSER”; m.a.w. er was een probleem van hoofdlettergevoeligheid. De programmatie is aangepast zodat dit niet meer hoofdlettergevoelig is.

1.47. Aanpassing “nieuwe gridcontrol” (Prato_Ado_Gridbrowse): deze gridcontrol gaat nu zelf ophalen welke parameters van toepassing zijn op het scherm en grid in kwestie. Er kunnen per kolom/zoekveld de volgende gridproperties via parameters ingesteld worden: "COLUMNHEADINGS", "COLUMNWIDTHS", "STYLES", "EDITCOLS", "SEARCHLABELS", "SEARCHFIELDNAMES", "SEARCHFIELDTYPES", "SEARCHFIELDWIDTHS", “SEARCHFIELDS” De Prato_Ado_Gridbrowse (nieuwe grid) is aangepast, naar aanleiding van het feit dat een column resize (onzichtbaar zetten) voor bepaalde grids niet (meer) werkte. Er diende in het verleden per grid in een scherm de functie: “Grid_AdjustPropsWithParamValues” (of afzonderlijk funkties “Grid_AdjustColumnWidths” en “Grid_AdjustSearchFieldWidths”) aangeroepen te worden. Bovendien moest de ontwikkelaar eraan denken dat er na de “Grid_AdjustPropsWithParamValues” een “RefreshGrid” gebeurde. Vanaf nu is het zo de Prato_Ado_Gridbrowse zelf de parameters ophaalt die van toepassing zijn op de betreffende grid (alle parameters met param1 = <scherm-naam> en param2 = ). Vanaf nu is het ook zo dat er veel meer eigenschappen via parameters ingesteld kunnen worden: "COLUMNHEADINGS", "COLUMNWIDTHS", "STYLES", "EDITCOLS", "SEARCHLABELS", "SEARCHFIELDNAMES", "SEARCHFIELDTYPES", "SEARCHFIELDWIDTHS". Bij het ophalen van de betreffende parameters wordt er rekening gehouden met: -de meest specifieke parameter van toepassing op de gebruiker (er wordt rekening gehouden met de gebruikersgroep [CO, PROG…] en gebruiker). Er wordt dus rekening gehouden met het cdkey-veld en keywaarde-veld uit de parameter-tabel. -de kantoorgroep in kwestie. Veld ParamOfficeGroup uit de parameter-tabel. -de taal van de gebruiker. Cd-taal veld uit de parameter-tabel. Opdat er bij ophalen van de parameters rekening wordt gehouden met de gebruiker, kantoorgroep en taal van de gebruiker, dient wel aan het grid meegegeven te worden over welke gebruiker en kantoorgroep het gaat. Dit door opvullen van de resp. grid-properties “personeelID” en “ParamOfficeGroup”. De recordset met parameters wordt clientside gezet, waarna de parameters met betrekking op de betreffende grid worden overlopen. De functie voor het (trachten te) laden en toepassen van de parameters voor het grid gebeurt op meerdere plaatsen binnen de grid-control: -na instelling van de “ConnectionString”-property (omdat er sowieso een connectie dient te bestaan voor ophalen van de parameters) -nadat de “ParamOfficeGroup” property van het grid is ingesteld. Dit treedt dus pas op voor het geval dat de “ParamOfficeGroup” property van het grid wordt ingesteld. Enkel in dit geval kan er dan ook maar rekening gehouden worden met het ParamOfficeGroup-veld van de parameter. -nadat de “personeelid” property van de grid is ingesteld. Dit treedt dus pas op voor het geval dat de “personeelid”-group property van het grid wordt ingesteld. Enkel in dit geval kan er dan ook maar rekening gehouden worden met de cdkey/keywaarde en cd_taal van de parameter.


29/33

-Binnen de RefreshGrid, bij het geval dat de “ConnectionString”-property van het grid niet is ingesteld. Bij de bovengenoemde gevallen wordt de volledige parameter-set van toepassing op het grid geladen. Bovendien worden er op verschillende plaatsen subsets van de gridparameters geladen: -bij het instellen van een eigenschap voor de kolommen (ColumnHeadings, ColumnWidths, Styles, EditCols) wordt enkel de parameter-subset van toepassing op kolomeigenschappen geladen. -bij het instellen van een eigenschap voor de zoekvelden (SearchLabels, SearchFieldNames, SearchFieldTypes, SearchFieldWidths, SearchFields = dit zijn initiële waardes voor de zoekvelden) wordt enkel de parameter-subset van toepassing op zoekveldeigenschappen geladen. Het toepassen van bv. ColumnWidhts-parameters kan enkel maar worden toegepast voor het geval de ColumnWidths-eigenschap voor het grid al is ingesteld. Voor elke eigenschap wordt hierop gecheckt. Na het laden van een subset of de volledige set van parameters voor het grid (en toepassen van deze parameters op de property-array), worden de kolomeigenschappen pas effectief toegepast op het grid (Draw_ColumnsHeadings) nadat zowel de ColumnHeadings-eigenschap als de ColumnWidths-eigenschap is ingevuld (hoofdingen en breedtes zijn noodzakelijke eigenschappen voor een kolom). Na het laden van een subset of de volledige set van parameters voor het grid (en toepassen van deze parameters op de property-array), worden de zoekveldeigenschappen pas effectief toegepast op het grid (Draw_SearchFields) nadat zowel de ColumnHeadings-eigenschap als de ColumnWidths-eigenschap is ingevuld (zoeken op een grid heeft geen zin als er geen kolommen zijn) en nadat zowel de SearchLabels, SearchFieldNames, SearchFieldTypes eigenschappen zijn ingevuld. Dit om te vermijden dat het grid zou crashen na toepassing gridparameters als men enkel nog maar bv. de SearchLabels, SearchFieldNames heeft ingevuld, maar nog niet de SearchFieldTypes. De FillSearchFields voor de zoekvelden wordt enkel maar toegepast als aan de voorwaarde hierboven voor de zoekveldeigenschappen is voldaan en als effectief ook de SearchFieldsproperty is ingevuld. De instelling van een eigenschap voor een bepaalde kolom of een bepaald zoekveld gebeurt op basis van resp. de kolomhoofding en het zoekveldlabel. Bv. men zou het volgende kunnen doen om voor de FR-gebruikers de kolomhoofding van de beginkolom en eindekolom binnen het contractenoverzicht in te stellen: -standaard voor iedereen (cd_taal 0) zijn de hoofdingen “begin” en “einde”. -meer specifiek voor de FR-talige gebruikers (cd_taal 2) zijn de hoofdingen “début” en “fin”.

Bv. onzichtbaar zetten van kolommen voor DC-bedrijven:


30/33

Bv. ook hernoemen van de zoekvelden:

We zouden ook evt. een bepaald zoekveld een ander invulling kunnen geven. Door zowel zoeklabel, zoekveld, de initiële zoekwaarde (searchfields) als het zoektype (searchfieldtypes) te veranderen. Natuurlijk moet het zoekveld wel voorkomen binnen de query waarmee de grid wordt opgevuld. Het is waarschijnlijk ook niet echt aan te raden om dit te doen. Het is beter om dit binnen de programmatie parametriseerbaar te voorzien. De gebruiker moet dan ook zeer goed weten waarmee hij bezig is.

Men dient de kolomhoofdingen en zoekveldlabels van de originele NL-talige kolomhoofding/zoekveldlabel-variant te gebruiken. Dus indien men een parameter heeft gemaakt om voor de FR-gebruikers de columnheading van kolom “kontnr” te wijzigen naar “N° contrat” en men wil erna ook de kolombreedte voor deze FR-gebruikers veranderen, dan dient men dit ook te doen via een parameter “columnwidths(kontnr)”. Voorwaarde is wel dat “N° contrat” gevonden wordt i n de vertaaluzb/vertaal-tabel in het “Fransveld” binnen een record, waarbij binnen het “Nederlands-veld” “kontnr” staat. Er wordt sowieso altijd eerst gezien of de kolomhoofding/zoekveldlabel ingegeven in de parameter wordt gevonden bij de “initiële kolomhoofdingen/zoekveldlabels” – zie hieronder. Indien deze niet wordt gevonden, wordt, voor een Franstalige gebruiker gezocht ahv de Vertaaluzb/ vertaal tabel of er een vertaling wordt gevonden waarbij de NL-talige variant wel voorkomt binnen de kolommen/zoekvelden. De initiële kolomhoofdingen en zoekveldlabels worden immers opgeslagen en gebruikt. Dit ook om te vermijden dat het uitzendbedrijf, bv. voor het instellen van kolombreedtes, steeds 2 parameters dient te voorzien, één voor de NL-talige kolom en één voor de FR-talige kolom. Dit is natuurlijk een ander verhaal in het geval men met de HiAntFR werkt, waarbij bv. standaard de kolommen al in de Franse taal voorkomen. Dit is enkel toegepast bij de nieuwe grid-control (Prato_Ado_Gridbrowse) en niet bij de oude grid-control (PratoGridBrowse). De wijzigingen aan de Prato_Ado_Gridbrowse zijn aangebracht rekening houdend met zoveel mogelijk situaties van opvulling van grid-properties: - bij grids, waarbij de verbinding naar de globalvar-database wordt gebruikt voor opvulling van de gegevens, zou er geen probleem meer mogen zijn (bv. frmParamLst) - indien er een connectie naar een database, waarbij parameters helemaal niet van toepassing zijn, wordt gebruikt voor opvulling van de grid, zou er geen probleem meer mogen zijn (bv. connectie naar PratoSupport op srvpprato01 --> ophalen van tickets) - zou moeten werken voor zowel in het geval dat parameters binnen de wiso-db terug te vinden zijn als in het geval dat parameters binnen de globalvar-db terug te vinden zijn - zou moeten werken voor zowel het geval waarbij een "connectionstring en een selectstring worden meegegeven aan de grid" als het geval waarbij een "recordset wordt toegekend aan het grid" (connectie van de recordset wordt gebruikt, tenminste als de recordset niet disconnected is)


31/33

In de volgende gevallen zal men geen instellingen van gridproperties kunnen doen: - Prato_PrintDestination control (die een Prato_Ado_Gridbrowse gebruikt) - in het geval binnen de connectiestring "PERSIST SECURITY INFO" op False staat. In dit geval is het paswoord niet meer beschikbaar binnen de connectiestring en kan men hier dus verder ook geen connectie meer mee maken - in het geval een recordset, die disconnected is, wordt toegekend aan het grid (er is geen verbinding meer beschikbaar)

1.48. Overhalen inschrijvingen webservice Met deze versie van HiAnt wordt het mogelijk om de import van de inschrijvingen die binnenkomen via de webservices altijd als nieuwe inschrijving te bezorgen. Er wordt dan niet gecontroleerd of de persoon reeds voorkomt in HiAnt of niet. Er wordt dan een nieuwe fiche aangemaakt. Param1

Param2

Param3

importwebsubscribe

type

*

importwebsubscribe

pwshiant

alwaysnew

Default

Omschrijving Deze parameter dient dan de waarde pwshiant te krijgen.

0

Deze parameter dient dan de waarde 1 te krijgen.

1.49. Afdrukken Loonbrief Bij het afdrukken van het loonbriefje zijn enkele vertaalde omschrijvingen langer dan de 70 tekens die hiervoor voorzien zijn. Het NieuwLoonBrief is aangepast zodat de omschrijvingen 100 tekens lang mogen zijn.

1.50. Toon één van de Common List na het starten van HiAnt Voor meer info: zie de handleiding van de Common Lists. We kunnen één van de ingestelde lijsten tonen na het starten van HiAnt, bijvoorbeeld om een takenlijst of reminderlijst te maken voor de gebruikers. Hiervoor volstaat het om volgende parameter aan te maken: Param1

Param2

Param3

Waarde

frmcommonlist

show

onstartup

Keywaarde

Omschrijving De code van de lijst die we na het starten van HiAnt willen tonen.

Voorbeeld: •

param1:

frmcommonlist

•

param2:

show

•

param3:

onstartup

•

waarde:

VervallenAttesten

De lijst opvragen. Na het starten van HiAnt wordt nu vanzelf de lijst getoond:


32/33


33/33

25

Recommend Documents