Release Notes. 24 oktober 2013

Transcriptie

1 Release Notes 24 oktober 2013 Dit document beschrijft vanuit technisch oogpunt de aanpassingen in HiAnt 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 HiAnt werken. Al deze informatie is confidentieel en mag niet zonder de schriftelijke toestemming van Prato in eender welke vorm verder gedistribueerd of gereproduceerd worden. Deze teksten kunnen ook informatie bevatten van functionaliteiten 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 functionaliteiten in dit document. 1

2 1 Module Uitzendkrachten & kandidaten 1.1 Ticket Attesten aanduiden als read-only (JV) In HiAnt versie 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). 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 specifieren op attestdetailtype. De parameterwaarde dient als volgt ingevuld te worden: <attesttype>:<attestdetailtype>, <attesttype>:<attestdetailtype>,, <attesttype>, Bv je wil attesttype 24 met detailtype 2 read-only maken, alsook attesttype 32. De parameterwaarde is dan 24:2, 32. 2

3 1.2 Ticket ReadOnly attesten (JV) Sedert de laatste release kunnen de attesten op detailniveau op Read-Only gezet worden. Maar tijdens de recentste Release Party is toen ook naar boven gekomen dat dit attest ook niet door iedereen mocht aangemaakt worden. Dit moet namelijk samenhangen. Het heeft geen zin om bepaalde attesten read-only te maken (= met doelstelling dat de uzc deze zeker niet kunnen wijzigen) en daarnaast toe te laten dat zij wel nog deze attesten kunnen aanmaken. Dit is nu ook geïmplementeerd. De (detail)types die in de parameter zijn opgenomen, worden niet meer ingeladen bij het aanmaken van een attest. 1.3 Ticket Automatische afdruk C63 bij verlaten van WN fiche (JV) Het is nu mogelijk om bij het sluiten van een werknemerfiche (dus geen kandidatenfiche) automatisch het document C63 naar de printer te sturen. Dit gebeurt bij mensen tussen 18 en 26 jaar voor wie de afdruk nog niet gebeurd is. Om dit te bepalen wordt er gekeken of er opvolging van het type C63 bestaan. 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 in de vertaaluzbtabel met code OmschrijvingOpvolgingC63AutoAfdruk. Standaard wordt de tekst "Document automatisch afgedrukt bij afsluiten fiche" gebruikt. 1.4 Bugfixen module Uitzendkrachten & kandidaten Update herkende gsm prefixen (JV) Bij het ingeven van een telefoonnummer in de werknemerfiche ging HiAnt automatisch kijken of er een gsm nummer bij zat. Indien dit zo was werd dit nummer als type GSM toegevoegd in de wncom tabellen. De herkenbare prefixen waren echter verouderd. Deze zijn nu bijgewerkt en HiAnt herkent alle actuele Belgische gsm-prefixen: (Telenet) (Proximus) (BASE) 3

4 (Mobistar) BugFix: Ticket : Foutmelding bij huisnummer met alfanumeriek karakter in WN-fiche (KT) Bij het aanmaken van een nieuwe werknemerfiche met als huisnummer een alfanumeriek karakter, krijg je een Incorrect sytax foutmelding. Deze bug is nu gefixed. 4

5 2 Module klanten en prospecten 2.1 Ticket : Sortering datum in poollijst (KT) 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 formattering van de datum via parameter kan worden ingesteld. Deze parameter wordt ook al gebruikt in de werknemerlijst en in de bezoekrapportlijst. Param1 Param2 Param3 initialisatie gridbrowse dateformatcode Waardes parameter: Dus als de datum moet worden weergegeven als yyyy/mm/dd moet er bij waarde 111 worden ingegeven. 2.2 Ticket : Zoekveld kantoornummer in bezoekplanningslijst aanpasbaar maken voor niet CO-medewerkers (KT) Standaard is het kantoornummer in het bezoekplanningsoverzicht enkel voor CO-medewerkers aanpasbaar. Dit is niet via een parameter bepaald. De programmatie is nu aangepast zodat er na het laden van de velden nog een changecontrolsload gebeurt zodat het mogelijk is om het gedrag van het veld kantoornummer te beïnvloeden via changecontrolsload-parameters. Om het veld werkgevernummer aanpasbaar te maken, dien je de parameter Changecontrolsload, frmbezplanlst, dtbzoek(8).locked met waarde 0 in te geven. 5

6 2.3 Bugfixen module Klanten en prospecten Bugfix: Ticket : Foutmelding bij het openen van het bezoekrapporten overzicht (KT) HiAnt geeft een foutmelding bij het selecteren van een bezoekrapport indien het infoveld niet is ingevuld. HiAnt probeert de waarde van dit veld te tonen in de textbox onder de lijst Controle tarificatie payroll (KT) De controle van payroll tarificatie stond bij bewaren/kopiëren van een contract op de verkeerde plaats. De controle gebeurde op het moment dat het contract nog niet bewaard was. De controle is nu verhuisd en gebeurt nu nadat het contract is bewaard. 6

7 3 Module Opvolging 3.1 Ticket Lookupbox Werknemers in opvolgingsdetail onduidelijk bij identieke namen (JV) Indien je een opvolging ingeeft en je wil een uitzendkracht kiezen, maar voor deze uitzendkracht zijn er meerdere fiches (verschillende statuten), dan zal deze uitzendkracht meerdere keren in de lijst verschijnen. Vroeger werd enkel het koppelid naast de naam vermeld, maar dan was het voor de consulent(e) vaak niet duidelijk welk de correcte fiche was. Nu is er een kolom met het werknemernummer (wnnr) toegevoegd: 3.2 Bugfixen module Opvolging Opvolgingsomschrijving met TAB waardes (JV) Wanneer men in het omschrijvingsveld van een opvolging tab-waardes zet (door de inhoud te plakken vanuit bv Word) dan werden deze tabs mee opgeslagen in de database. Hierdoor werden o.a. de grid met opvolging verkeerd ingevuld (door de tabwaarde werd de kolominhoud verspreid over meerdere kolommen). Dit is nu omzeild door TAB waardes uit het omschrijvingsveld te vervangen door een spatie. 7

8 3.2.2 Weergeven opvolgingslijst vanuit klantenfiche (JV) Gebruiker opent via Opvolgingslijst Gegevens Klant een klantenfiche en wil dan in die openstaande fiche via Opvolgingen "Lijst opvolging" openen. Dit gaf een foutmelding omdat de opvolgingslijst eigenlijk al open stond. HiAnt gaat dit nu correct afschermen en indien mogelijk de geopende lijst terug tonen. Dit is echter niet altijd mogelijk omdat het klantenscherm als dialoog geopend kan zijn, waardoor het niet naar de achtergrond kan worden verwezen. In dat geval zal HiAnt een infoboodschap tonen Bugfix: Ticket : Foutmelding in het opvolgingen overzicht bij klikken op het menu Acties > Zet op afgehandeld (KT) Foutmelding omdat HiAnt probeert de opvolgingsdatum aan te passen terwijl deze niet werd opgehaald. Opvolgingsdatum wordt nu wel opgehaald. 8

9 4 Module Zoek 4.1 Bugfixen module Zoek Bugfix: Ticket : Zoekmodule: foutmelding indien men zoekt op graad opleiding en naam opleiding in 1 zoekopdracht (KT) Blijkbaar worden indien je kiest voor graad en naam opleiding dezelfde alias gebruikt voor de wnopleidingen-tabel. De aliassen zijn aangepast. 9

10 5 Module Contracten 5.1 Ticket Controle medisch onderzoek in WPF bij opslaan contract (JV) Indien je parameter contract, controleerwpf, medisch aanmaakt met waarde 1 gaat HiAnt bij het opslaan van een eerste contract tussen werknemer en klant controleren of er in de werkpostfiche die gekoppeld is aan de tarificatie ofwel een verplicht gezondheidstoezicht gekoppeld is, ofwel Gezondheidsbeoordeling uit te voeren voorafgaand aan tewerkstelling is aangevinkt. Indien een van deze, of beide, het geval is, 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. 10

11 5.2 Ticket Opvolging 1 e contract aanpasbare omschrijving (JV) Met de reeds bestaande parameter Initialisatie, NieuwContract, AutoOpvolging, "" kan je instellen dat er een automatische opvolging verschijnt bij aanmaak van het eerste contract. Als waarde geef je dan het id van het opvolgingstype en eventueel opvolgingsdetailtype in dat er dient ingevuld te worden. Dit doe je als volgt: <id opvolgingstype>, <id opvolgingsdetailtype>. Indien het hoofdtype 2 is en het detailtype 4, wordt de waarde dus 2,4. Met de parameter Initialisatie, NieuwContract, Tekst, "" kan je de te gebruiken omschrijving (of vertaal-code) definiëren die in de aangemaakte opvolging komt te staan. In het verleden was het enkel mogelijk om als waarde bij deze parameter steeds een vaste tekst in te geven. Nu is het ook mogelijk om hier een veldnaam te gebruiken ipv 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 5.3 Ticket Mastercontracten voor jobstudenten (JV) Het is nu mogelijk om een mastercontract te maken voor een jobstudent. Hieraan zijn echter een aantal belangrijke punten gekoppeld: Het aantal geplande dagen moet manueel ingevuld worden De dimona aangifte dient manueel te gebeuren Om mastercontracten toe te staan dien je parameter Controle, Jobstudenten, MasterToegelaten aan te maken met waarde 1. Om het aantal geplande dagen manueel te kunnen invullen moet je ook parameter initialisatie, jobstudent2012, LaatManueelAantalDagenToe aanmaken met waarde 1. Bij het bewaren van een mastercontract zal steeds een waarschuwende boodschap getoond worden: 5.4 Ticket Zichtbare bestelling bij contracten met reden instroom (JV) Huidige werking: Indien een arbeidscontract reden instroom heeft, is het verplicht een bestelling te selecteren op het arbeidscontract. De keuzelijst van de bestellingen zijn : de bestellingen van deze klant met reden instroom ongeacht de status Ook status closed wordt getoond, daar je chronologisch eerst een bestelling kan afsluiten (omdat ingevuld), en vervolgens een arbeidscontract aanmaakt. 11

12 Wijziging: Je kan nu filteren welke status ID s getoond moeten worden. De weer te geven bestelstatus ID's (codesoort 85) moeten opgesomd worden als komma gescheiden numerieke waardes in parameter controle, instroom, filteropbestelstatusids. Indien de parameter niet bestaat wordt er niet gefilterd op de weergegeven statussen en worden alle bestellingen die geldig zijn op de startdatum van het contract, bij die klant getoond. 5.5 Controle payroll coëfficiënt bij kopieren contract in visueel scherm (JV) In het verleden werd een controle op payroll coëfficiënt ingebouwd bij het bewaren en overhevelen van contracten. Deze controle gebeurde echter niet wanneer je via het vliegertje een contract kopieerde in het contracten visueel scherm (Shift F4). Dat is nu gecorrigeerd. De controle wordt getriggerd door dezelfde parameter als deze bij bewaren van contracten: Contract, PayRollCoeff, Controle met waarde Ticket klantencontracten printen (PZ) Parameter Afdruk, optie, KlantContactSplitsWeek (standaardwaarde = 0 = uit) Indien je bovenstaade parameter de waarde 1 geeft zullen de klantcontracten bij het afdrukken gesplitst worden per week. 5.7 Bugfixen module Contracten Overzicht mastercontracten houdt geen rekening met actieve jaar (JV) In het overzicht van de mastercontracten werd niet gekeken naar het actieve jaar binnen HiAnt. Hierdoor kreeg je contracten van jaren geleden te zien. Dit is nu aangepast zodat het actieve HiAnt jaar steeds tussen begin- en einddatum van het mastercontract moeten liggen Opeenvolgende DagContracten (FD) Sinds is de nieuwe regeling van opeenvolgende dagcontracten actief. Dit betekent dat er geen opeenvolgende dagcontracten meer aangemaakt mogen worden. De bijhorende controle werd steeds opgestart als het om een dagcontract gaat (begindatum = einddatum) Dit gaf echter een probleem als men een dagcontract van voor wou aanpassen in de nieuwe versie. Er werd een extra controle ingebouwd zodat er ook getest wordt of het gaat over dagcontracten voor of vanaf

13 5.7.3 Ticket : Foutmelding bij het aanpassen van een label in het contractenscherm (KT) Foutmelding doordat de focus gezet wordt op een veld dat niet aanpasbaar is. De code is aangepast om dit probleem op te lossen. 13

14 6 Module Prestaties 6.1 Aanpassing binnen beide prestatie-ingaveschermen: na selectie van periode worden de contracten van deze periode gecontroleerd op verschillen in de uurloon-velden (EO) De contracten hebben 2 uurloonvelden, ebruto en ebrutoloon, die altijd gelijk zouden moeten zijn (deze velden zijn beide nodig: op sommige plaatsen wordt veld ebrutoloon gebruikt; de loonberekening heeft veld ebruto nodig). Zeer sporadisch treedt het op dat meestal veld ebruto 0 is (waardoor de loonberekening geen waarde terug geeft). Beide prestatie-ingaveschermen zijn nu aangepast zodat steeds, na selectie van een periode, al de contracten van deze periode worden gecontroleerd op verschillen tussen velden ebruto en ebrutoloon. Indien periode (en systeem ingeval van maand-ingavescherm) gekend is/zijn, worden alle contracten van de betreffende periode en betaalsysteem binnen het actieve jaar met verschillen in de uurloon-velden opgehaald en overlopen. Concreet worden de contracten opgehaald waarbij 1) OF het verschil tussen velden ebruto en ebrutoloon groter is dan ) OF het veld ebruto 0 is 3) OF het veld ebrutoloon 0 is Vervolgens worden deze contracten overlopen: als veld ebruto 0 is en veld ebrutoloon > 0 is, wordt veld ebruto ingevuld zoals veld ebrutoloon als veld ebrutoloon 0 is en veld ebruto > 0 is, wordt veld ebrutoloon ingevuld zoals veld ebruto als het verschil in waarde tussen veld ebruto en ebrutoloon <= , dan wordt veld ebruto ingevuld zoals veld ebrutoloon in het andere geval (verschil in waarde tussen veld ebruto en ebrutoloon > ) wordt dit gemeld aan de gebruiker via een Excel-bestand met vermelding van Jaar, Week, Wnnr, UzkNaam, UzkVoornaam, Begind, Einde, Ebruto en Ebrutoloon. 14

15 7 Module Lijsten & documenten 7.1 Ticket Aanpassing aan Attest RSZ Vermindering betalende module (JV) De opzet is om het gecombineerd gebruik van Activakaarten, Startbaankaarten en RSZ Verminderingsattesten te versimpelen door alle nodige gegevens in 1 attest RSZ Verminderingen (800) te kunnen ingeven. Hiervoor werden 3 nieuwe velden toegevoegd aan de attestentabel, die zichtbaar worden wanneer je attest van type 800 aanmaakt / opent. De maximum geldigheid is niet invulbaar door de gebruiker, maar wordt berekend op basis van de RSZ tabellen bij het bewaren van het attest. In het veld contract vanaf en t/m dient de gebruiker initieel de begin- en einddatum van het eerste contract in te geven. Het veld t/m wordt automatisch verhoogd met de einddatum van toekomstige contracten wanneer deze worden aangemaakt. 15

16 7.2 Ticket activa aanvragen : lijst met adressen ter merging C63 (PZ) Documenten op newsource: LeegC63Werkkaart_ASAP.doc LeegC63WerkkaartFR_ASAP.doc De documenten die hierboven vernoemd zijn bevatten naast de C63 een voorblad waarop de adres gegevens 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. 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 het 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 (kantoornummer). 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 zal HiAnt de standaard werking voortzetten. Beneden het voorbeeld van dat voorblad. 16

17 7.3 Ticket vragensets intentieverklaring + C63 HiAnt (PZ) Indien je de parameter scherm, FrmWnGeg1, ControleInlichtingsblad met waarde 4 instelt, zal er bij de afdruk van Inlichtingsblad + intentieverklaring een extra keuze "Document infosessie OK" verschijnen. Parameter Control, printc63, InfoSessie met waarde 1 17

18 NOTA: parameter controle, printc63, isverplicht moet als waarde 0 hebben voor deze optie! HiAnt beschouwt het document als zijnde afgedrukt en zal de opvolgingen aanmaken. 7.4 Ticket Uitbreiding keuzemogelijkheid (PZ) Parameter scherm, FrmWnGeg1, ControleInlichtingsblad met waarde 4 Het keuzescherm wordt met deze parameter verder aangevuld met een extra keuzeitem "Intentieverklaring ontvangen via ". HiAnt beschouwt het document als zijnde verzonden via en zal hierbij ook een nieuwe opvolging aanmaken die dat aantoont. Deze nieuwe opvolging "Intentieverklaring via " dient men aan te maken en in te geven in de parameter Codeboekcode, OpvolgingsType, inlichtingsbladviamail. 18

19 7.5 Ticket C63 lijsten (PZ) Parameter changecontrols, frmexternalfiles, mnuoverzicht.visible standaard waarde = 0 = UIT Door de waarde van bovenstaande parameter op 1 te zetten zal HiAnt een bijkomend menu Overzicht tonen in het scherm Gekoppelde documenten (via menu Gegevens Gekoppelde documenten ). Binnen het menu Overzicht staat de standaard weergave aangevinkt. Drukt men op het item Lijst starters zal HiAnt een grid tonen met als standaard filter alle personen uit het huidig kantoor die in het huidig jaar een contract hebben. 19

20 Daarnaast wordt ook een nieuw menu Print zichtbaar: Op basis van de selectie zal HiAnt een controle doen of de geselecteerde personen in aanmerking komen voor een C63 (leeftijd tussen 18 en 27) en op basis van opvolgingen, de C63 ervan werd afgedrukt. Zo ja zullen deze op het scherm getoond worden in Word. 20

21 7.6 Ticket Afdrukmodule knop export Word (PZ) Parameter Afdrukmodule, Scherm, ToonWord Door de parameter de waarde 1 te geven zal op het scherm van de afdrukmodule een bijkomende knop Export Word verschijnen om de documenten naar Word te exporteren. 7.7 Aanpassing werking bij ADM-documenten (EO)* Om deze aanpassing te illustreren, vertrekken we vanuit een voorbeeld. Stel een uitzendkracht werkt binnen een bepaalde loonperiode bij meerdere klanten bv. klant A en klant B. Voor deze uitzendkracht heb je binnen deze loonperiode de prestatiecode OGA gebruikt. Deze code OGA staat in dit uitzendbedrijf ingesteld als een code waarvoor een ADM document dient worden opgemaakt. Indien de code OGA voorkomt bij een contract bij klant B, dan kon het zijn dat binnen de printaanvragen niet het juiste prest-id werd weggeschreven, bijvoorbeeld een prest-id bij klant A. Voor invulling van de prest-id werd immers de min(prest.id) opgehaald voor de betreffende uzk in de betreffende periode. Standaard geven ADM-stored-procedures de klantnaam terug, om dit te kunnen invullen (bij ADM-doc werking zonder printaanvragen) binnen een document. Om het juiste prest-id te kunnen bepalen, nl. een prest-id bij de juiste klant, dient de stored procedure ook het klnr terug te geven. De programmatie van de ADM-documenten is aangepast zodanig dat de min(prest.id) wordt opgehaald voor de betreffende uzk in de betreffende periode en bij de betreffende klant. De programmatie van de ADM-documenten is zodanig gemaakt zodat, indien de stored procedure het klnr teruggeeft de min(prest.id) bij de betreffende klant wordt opgehaald en, indien de stored procedure NIET het klnr teruggeeft de oude werkwijze geldt (niet rekening houdend met klnr). 7.8 Aanpassing CAO58 CAO108 (JV)* Extra info zie: HiAnt werd aangepast om de nieuwe layout en gegevens van CAO documenten te ondersteunen. Het document CAO58 werd omgevormd tot CAO108, met enkele inhoudelijke wijzigingen: Enkel de naam van het uitzendkantoor wordt meegestuurd, het adres is niet meer nodig Het ondernemingsnummer van de klant wordt toegevoegd Klantgemeente valt weg Extra velden zoals naam (vrij invulveld), aanmaakdatum, kantoornummer vallen weg Er wordt ook enkel nog een Excelfile aangemaakt, dewelke verstuurd moet worden naar Federgon. 21

22 Er bestond reeds een parameter waarin je de codes van contract-redenen kon opnemen die bekeken moesten worden bij het maken van het CAO58 document. Hier werd nu standaard de code van instroom bijgezet. Opgelet: indien je deze parameter gebruikte met extra codes zal je zelf code 10 moeten toevoegen. ("CAO58", "prest-reden", "inaanmerking", "1,2,10") Na het verwerken wordt gevraagd of je het bestand wil openen, ook de locatie wordt getoond. In het Excel bestand wordt per klant, per motief, per PC een regel getoond: Er werd ook een optie toegevoegd om gelijkaardig bestand aan te maken ivm Opeenvolgende Dagcontracten. Hiermee wordt een Excel file gemaakt die de klanten oplijst waarbij op de ingegeven maand opeenvolgende dagcontracten zijn gebruikt. Ook deze Excelfile voldoet aan de layout die gevraagd wordt door Federgon. 22

23 7.9 Ticket Waarschuwing bij C4 en (on)betaalde compensatie bij klant (JV)** Op het moment van afdruk C4 doet het systeem een test of de klant waarbij de UZK heeft gewerkt in de ingegeven periode werkt met betaalde en/of onbetaalde compensatie. Op dat moment krijgt de consulente een boodschap, weg te klikken met OK, waarin HiAnt aangeeft dat de uren betaalde/onbetaalde compensatie moeten vermeld worden op de C4. Dit dient geactiveerd te worden via parameter Controle, C4, KlantCompensatie, aan te maken met waarde 1. Standaard staat deze uit Bugfixen module Lijsten & Documenten Ticket : Foutmelding bij aanmaken rapport Gewerkte dagen per jaar, klant, uzk, week in het klantenoverzicht (KT)* Indien de klantnaam het teken bevat, kreeg je een foutmelding als je het rapport Gewerkte dagen per jaar, klant, uzk, week wilde openen. Nu is dit probleem opgelost. 23

24 8 Module Lonen 8.1 Ticket : Aanpassing PratoDashBoard Loonberekening (FD) In het batchdashboard heb je de mogelijkheid om loonruns te blokkeren en/of te deblokkeren. Er is nu zichtbaar gemaakt of de loonruns geblokkeerd of gedeblokkeerd zijn Je kan door rechts te klikken op het kantoornummer, de loonrun van dat kantoor blokkeren of deblokkeren. Als het kantoor geblokkeerd is, dan zal het kantoornr in witte letters op een zwarte achtergrond staan. 8.2 Aanpassingen batch loonberekening (TS) 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 komen dan te zien in deze lijst. De geblokkeerde loonruns worden niet meegenomen in de doorloop van de batch. 24

25 8.3 Aanpassing om dubbele lonen te voorkomen (EO)* Het kon gebeuren dat er bij een uitzendbureau toch nog dubbele lonen voorkwamen. Dit gebeurde wanneer men tegelijkertijd meerdere loonberekeningen opstartte, en met dezelfde user ingelogd was op verschillende terminal servers. Dan kwamen er gegevens van uitzendkrachten terecht binnen de loonrun van een ander kantoor. Ze werden echter ook berekend en geboekt onder de loonrun van hun eigen kantoor. Deze bug was te wijten aan het feit dat binnen een bepaalde funktie die bij het berekenen/boeken van de lonen wordt opgeroepen, blijkbaar de variabele met het loonrunnr wijzigt. Er is nu voor gezorgd dat deze variabele die het loonrunnr bevat, van het type is "niet wijzigbaar" (en dat binnen alle funkties die aangeroepen worden bij het berekenen en boeken van de lonen, en die een loonrunnr doorkrijgen). Volgende funkties zijn aangepast, zodat de parameter met het loonrunnr ByVal is: - startloonberekening - berekenloonrun - tegenboeken - berekenbruto - schrijf_transaktie - controleervakbediende - controleermc 25

26 - (controle_klfakt1210_en_klfakt...) - maakcontrolelijst - boekloonrun - splitsloonperloonrun - vuldmfaveldenloonrun 8.4 Ticket Lege loonruns verwijderen (JV)* Bij het boeken van loonruns kan het voorkomen dat door splitsing lege loonruns achterblijven. Deze kan je vanaf nu simpel verwijderen via het menu acties: 26

27 8.5 Bugfixen module Lonen Loonberekening: Multiple Step Error (SF) 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 gestoken dat mogelijk was, waardoor HiAnt deze melding gaf. Naast het wijzigen van code 629 naar 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. 27

28 9 Module Facturatie 9.1 Ticket geen namen op factuur (PZ) Via de klantoptie TGW zal HiAnt aan de factuur meegeven dat de namen van de werknemer niet zullen getoond worden. Achterliggend wordt wel de sortering op werknemer behouden indien deze sortering uiteraard aanwezig is. Let wel op dat deze functionaliteit in het Crystal Reports document dient ingebouwd te worden indien men van deze optie wenst gebruik te maken. 9.2 Ticket : FactuurGroepen (PZ) Parameter : Menu, frmmain, mnubeheerfactuurgroepen Binnen HiAnt kan je door bovenstaande parameter de waarde 1 te geven een nieuw menu item zichtbaar maken om de factuurgroepen te beheren. Dit menu item kan je terugvinden vanuit het hoofdscherm onder het menu Gegevens Instellingen Beheer Beheer factuurgroepen 28

29 Het scherm is als volgt opgedeeld. De grid bovenaan toont alle reeds bestaande factuurgroepen binnen HiAnt. Op het onderste gedeelte van het hoofdscherm staan 2 lijsten met links alle kantoren die gekoppeld zijn aan de vennootschap van de geselecteerde factuurgroep en rechts alle kantoren die gekoppeld zijn aan de betreffende factuurgroep. Via de 4 knoppen kan je 1, meerdere of alle kantoren van de ene lijst naar de andere verplaatsen. Rechts onder de grid kan je een factuurgroep aanmaken of verwijderen. Met een dubbelklik op een geselecteerd record kan je de groep wijzigen. In het detailscherm kan je de vennootschap, naam en omschrijving van een factuurgroep aanpassen/ingeven. Het selectievak vennootschap bevat alle vennootschapen die aanwezig zijn in de database. Boeken facturen Via parameterisatie worden factuurgroepen gekoppeld aan een factuurnummering Er zijn 2 nieuwe boekingstypes toegevoegd die dienen ingegeven te worden met de parameter Initialisatie, FactuurnrType, *, 0 waarde 5 Per vennootschap en per facturatiegroep Parameter : Factuurnr, <jaar>_<vennootschapsid>_<facturatiegroep>, volgendenr, 999> waarde 6 Per vennootschap en per facturatiegroep en per type document Parameter : Factuurnr, <F/C>_<jaar>_<vennootschapsid>_<FacturatieGroep>, volgendenr, <999> Bij het boeken van de facturen waarbij er in 1 run facturen van verschillenden vennootschappen en/of verschillende factuurgroepen zitten, zal HiAnt de boeking afbreken en de gebruiker melden dat dit het geval is waarom de boeking wordt gestopt. 29

30 9.3 Ticket HiAnt Facturatie (PZ) Parameter AfdrukFactuur, optie, ControleGeenBtwDanOndernemingsNr. Door de parameter de waarde 1 te geven zal HiAnt bij het afdrukken van de facturen volgende procedure uitvoeren indien de klant geen BTW nummer heeft. Het ondernemingsnummer zal dan wordt gebruikt i.p.v. het BTW nummer en de labels op de factuur met BTW nummer worden vervangen door ondernemingsnummer. 9.4 Ticket HiantDocMailing - extra parameter voor benaming PDF facturen (PZ)* Parameter AfdrukFactuur, optie, FactuurGebruikInternNrNaamPdf Voor de HiantDocMailing is een extra parameter voorzien bij het exporteren van PDF bestanden voor facturen. Standaard neemt HiAnt het factuurnummer binnen de benaming van de PDF. Door de parameter de waarde 1 te geven zal HiAnt in plaats daarvan het intern factuurnummer gebruiken. 9.5 Ticket meldingen bij facturatie (JV)* Bij het berekeningen van de facturen kan HiAnt soms de melding geven dat er een aantal op 0 staat. Hierbij werd echter enkel het klantnummer vermeld, waardoor de gebruiker soms 100 en werknemers bij die klant moest afgaan om te kijken waar het probleem zat. Vanaf nu wordt samen met het klantnummer ook nog de werknemernummer, datum, en gefactureerde code vermeld. 30

31 10 Module export naar sociaal secretariaten 10.1 Export naar Securex Wijziging uren bij beheer mastercontract (EO) Er is een aanpassing gebeurd in het menu beheer mastercontract wanneer je 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. Voorheen kreeg men, na aanmaak van de nieuwe cyclus en roosters, enkel onderstaande melding. 31

32 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 master-historiek toevoegt aan het einde van de bestaande master en 2) waarbij men een nieuwe master-historiek toevoegt aan het begin van de bestaande master en 3) waarbij men een nieuwe master-historiek 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 Export naar Securex - Ticket Controle op geldig roosterid bij overhevelen (JV) Bij het overhevelen van een contract wordt gecontroleerd of er een geldig roosterid gekoppeld is. Dit is op vraag van dienstenchequeklanten. 32

33 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. Export naar Securex - Afhandeling problemen na export (EO)* Het was al steeds zo bij de Securex-export dat, als de aanmaak van exportbestanden succesvol was, de export niet meer ongedaan wordt gemaakt bij een fout. Na een succesvolle aanmaak van exportbestanden, zijn er nog 2 stappen die dienen te gebeuren, in volgorde van opsomming hieronder: - invullen van export-datum en export-bestandsnaam binnen de betreffende loonruns - versturen via mail van de exportbestanden Indien het versturen via mail van de exportbestanden niet lukte, was het tevoren reeds zo dat er een boodschap kwam aan de gebruiker die meldde dat de export succesvol was, dat het automatisch versturen via mail van de exportbestanden niet lukte en dat de gebruiker dan zelf via mail deze exportbestanden diende op te sturen. Echter indien er een fout optrad tijdens opvulling van de export-datum of de export-bestandsnaam binnen de loonrun, werd de gebruiker hiervan niet op de hoogte gesteld (met als gevolg dat de betreffende loonrun[s] nog stonden als zijnde te exporteren). De export naar Securex is nu aangepast - bij de stappen na een succesvolle export: Vóór elke stap wordt een error-variabele op 0 gezet. Indien bij een stap de errorhandling wordt doorlopen, wordt de error-variabele ingevuld met het foutnummer. Indien dan bij een stap een fout is opgetreden, wordt dit aan de gebruiker gemeld. Melding die gegeven wordt indien invulling van export-datum en export-bestandsnaam binnen de loonrun mislukt: Melding die gegeven wordt indien versturen via mail van de exportbestanden mislukt: 33

34 10.3 Export naar GroepS - Mogelijkheid kantoornaam uit veld wg.kantoornaam i.p.v. veld wg.naam (EO) 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 kantoorinfo bevat. Binnen de 001-records verschijnt dan ook voor niveau 1 voor elk kantoor de vermelding van het kantoornummer en de kantoornaam. Voor de kantoornaam werd steeds het veld wg.naam gebruikt. Bij sommige uitzendbedrijven is het echter 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 je de parameter ExportLoonGroepS, Niv1_WgInfo, NaamAhvVeldKantoornaam aanmaakt met waarde 1, zal echter de naam van het kantoor gehaald worden uit veld wg.kantoornaam Export naar GroepS Doorsturen signaletiek uzk zonder lonen (EO) Volgend probleem heeft zich voorgedaan bij een uitzendbedrijf dat exporteert naar GroepS. Een uitzendkracht was eerst aangemaakt in een bepaalde sektie (bv. arbeider). Deze uzk was meegegaan bij een export naar GroepS (signaletiek van uzk zonder lonen). Deze uzk had nog geen contract, waardoor men deze uzk van sektie heeft kunnen veranderen (bv. sektie bediende). Bij een volgende export naar GroepS is dus het zelfde wnnr doorgegaan onder een andere sektie, hetgeen een probleem opleverde. De export naar GroepS is nu aangepast: bij de signaletiekwijzigingen van uzk zonder lonen worden enkel de uzk doorgestuurd die al een contract hebben Export naar GroepS Aanpassing bij eerste maal doorsturen van een uzk (EO) Er zijn bij de GroepS-exporters uitzendbedrijven waarbij de kantoren vallen onder verschillende GroepS-dossiers (concreet 2 GroepS-dossiers Hasselt en Brussel, vnl. te maken met de taal). Er was hierbij nog een probleem ivm. bepaling of een uzk reeds is doorgestuurd naar GroepS of niet dit dient immers best PER GROEPS-DOSSIER te gebeuren zie hieronder. De programmatie van de export naar GroepS is aangepast. Het blijft zo zijn dat signaletiekwijzigingen van een bepaalde uzk naar beide dossiers doorgaan. Het kan immers zo zijn dat iemand die rond de taalgrens woont nu misschien onder kantoor Hasselt hoort, maar binnen afzienbare tijd misschien onder kantoor Luik. Wel is het volgende aangepast: De tabel die bijhoudt welke uzk al is doorgestuurd (omdat bij eerste maal doorsturen er ook historiek van contractgegevens dient te zijn vanaf de indienstdatum --> hier worden fictieve gegevens in gestoken), houdt nu bijkomend bij naar welk dossier deze gegevens zijn verstuurd. 34

35 Dit om het volgende probleem te verhelpen: Een kandidaat die net uzk is gemaakt, wordt de volgende keer naar GroepS doorgestuurd met zijn signaletiekgegevens. Vermits dit een nieuwe fiche is die nog nooit is doorgestuurd naar GroepS worden de eerste maal ook de "ficitieve contractgegevens vanaf indienstdatum" naar GroepS doorgestuurd. Als dit een uzk was die onder dossier Hasselt gaat werken, maar de eerstvolgende export naar GroepS (na de actie "maak uzk" voor deze kandidaat) was een export naar dossier Luik, dan werden de "ficitieve contractgegevens vanaf indienstdatum" enkel doorgestuurd naar kantoor Luik. Dit terwijl de uzk eigenlijk voor Hasselt gaat werken. Dit gaf een probleem als er lonen voor deze uzk voor dossier Hasselt werden berekend: er bestond voor deze uzk onder dossier Hasselt geen historiek met contractgegevens vanaf de indienstdatum (enkel waren er reële contractgegevens doorgestuurd voor zijn effectieve contracten). De export naar GroepS is dus nu aangepast: er wordt per dossier bijgehouden en dus ook per dossier bepaald of de betreffende uzk al is doorgestuurd naar GroepS. Dus een bepaalde uzk zal naar beide dossiers (Hasselt en Luik) worden doorgestuurd en voor beide dossiers zal er een historiek met contractgegevens vanaf indienstdatum worden doorgestuurd Exports naar sociale secretariaten algemeen - Exportbestanden worden nu gebackuped naar een netwerk-folder (EO) De programmatie van HiAnt is aangepast zodat de exportbestanden, aangemaakt bij export van lonen naar een sociaal secretariaat, kunnen gebackuped worden naar een netwerkmap. Er dient een parameter Export, <SociaalSecretariaat>, ExportBestanden_BackupDirectory te bestaan, en deze netwerkap dient te bestaan, opdat de bestanden opzij gekopieerd worden. Elke aanroep van een export is veranderd van een Sub naar een Function, die de bestandsnamen van alle aangemaakte exportbestanden (gescheiden door ';') teruggeeft. Volgende exports zijn aangepast: - Acerta - export naar CLB voor zowel lonen, signaletiek als voorschotten - export "GroepS" - export aangemaakt voor maandverloonden binnen sector Horeca, events en reception services - export "GroepSInterim" - export aangemaakt voor exports bij interimbedrijven - SD - Cepa - Sofim - SofimDC - Securex voor zowel lonen, signaletiek als voorschotten - HDP Ook wordt het excel-bestand dat aangemaakt wordt voor annulatie-lonen (actief ingeval men de parameter export, sociaalsecretariaat, toongeannuleerdelonen met waarde 1 heeft) gebackuped naar de netwerkmap. Bij al de uitzendbedrijven die Prato-klant zijn en een export naar een sociaal secretariaat hebben, zijn de netwerkmappen en de parameters die deze netwerkmap-naam bevatten, reeds voorzien. 35

36 Indien toch bij een bepaald uitzendbedrijf geen netwerkmap zou zijn ingesteld, krijgt men bij export volgende melding (maar de export gaat wel gewoon door): "Er is geen directory ingesteld naar waar de exportbestanden moeten overgekopieerd worden [parameter Export, " & strexporttoexternalsocsec & ", ExportBestanden_BackupDirectory]." Indien een export van bij Prato wordt uitgevoerd vanuit de sources, zal normaal gezien deze netwerkmap niet bestaan. Men krijgt dan een melding "De map naar waar de exportbestanden moeten overgekopieerd worden [parameter Export', " & strexporttoexternalsocsec & ", ExportBestanden_BackupDirectory] bestaat niet - waarde " & strexportbestanden_backupdirectory & "." - dus zeker geen probleem bij een test-export - indien een export wordt uitgevoerd op een productiedatabase, die dan ook doorgestuurd wordt naar het sociaal secretariaat, is het wel aan te raden dit exportbestand zelf binnen de netwerkmap bij het uzb te plaatsen (opdat men dit bestand later nog kan raadplegen) Export naar HDP Aanpassing loonberekening (EO)* Het volgende probleem stelde zich: bij overuur-looncodes berekend volgens de tabel "overuren" binnen posten/overuren (cdeenheid 171), waarbij een bedrag bovenop het verhoogde uurloon stond ingesteld (geen % bovenop het verhoogde uurloon), klopte de door de loonberekening ingevulde ld_basiscode niet. In dit geval werd binnen de loond de ld_lfwaarde ingevuld met het eenheidsbedrag zijnde het verhoogde uurloon waarbovenop een bedrag was opgeteld, de ld_cdeenheid ingevuld met "01" en de ld_basiscode met de code verwijzend naar het verhoogde uurloon (bv ingeval van uren in de week in nachtpost). Dit klopt niet, vermits de ld_lfwaarde niet het verhoogde uurloon bevat, maar het verhoogde uurloon waar nog bijkomend een bedrag is toegepast. De loonberekening is nu aangepast zodat de ld_basiscode wordt leeggemaakt (ld_basiscode op 0). De export naar HDP zorgde er in dit geval al voor dat er dynamisch een uurloon-basiscode wordt toegekend (bv. 8114) voor dit afwijkende uurloon Bugfixen module Export naar sociaal secretariaten Export naar GroepS - Doorgeven aantal kinderen ten laste (EO) Er was een probleem ivm de manier waarop GroepS de gegevens ivm kinderen ten laste wenste binnen te krijgen. Binnen HiAnt geldt het volgende: - Veld "Ten laste kind" = aantal kinderen ten laste (totaal aantal kinderen, incl. invalide kinderen) - Veld "Inv. Kind" = aantal invalide kinderen (steeds ten laste) 36

37 Bijvoorbeeld: Heeft de uitzendkracht 3 kinderen ten laste waarvan eentje invalide, dan vul je in het veld 'Ten laste kind' 3 in en in het veld 'Inv. Kind' 1 in. GroepS verwacht binnen gegeven AKL het volgende: Aantal kinderen ten laste. De gehandicapte kinderen tellen voor 2 kinderen. Voor het AKL-gegeven werd dit dus als volgt aangepast: ("Ten laste kind" - "Inv. Kind") + (2 * "Inv. Kind") De export naar GroepS is aangepast. 37

38 11 Module Maaltijdcheques 11.1 Aanpassingen scherm bestellen maaltijdcheques (TS) De layout van het bestelscherm voor maaltijdcheques is gewijzigd. Bovenaan zie je de aangemaakte bestellingen, waarbij je kan filteren op de id of naam van de bestelling, en op het al dan niet afgsloten zijn van deze bestelling (0/1) Ook in het overzicht van de bestellingen zie je 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 zijn er 2 tabbladen: Op de eerste tab ziet je de maaltijdcheques die in de aktieve bestelling zit (door dubbelklik op bestaande bestelling in bovenste grid te doen). Op tweede tab zie je een overzicht van de maaltijdcheques die nog niet zijn opgenomen in een bestelbestand. Op deze grid kan je enkel zoeken, er zijn geen verdere acties op deze grid geprogrammeerd. 38

39 Indien je verwijder datum afsluiting zou doen, wordt dit gelogd in de logtabel met type 118. De bestandsnaam in de grid wordt na aanmaak van het elektronisch maaltijdchequebestand opgevuld indien de installatie is gebeurd van de laatste dll s mbt elektronische maaltijdcheques, in combinatie met deze versie van HiAnt Overzicht maaltijdcheque bestelling aantal en bedrag (TS) In het overzichtscherm van maaltijdcheques kan je nu ook zoeken op het brutobedrag van een maaltijdcheque zowel binnen een bestelling als op de nog te bestellen maaltijdcheques. Verder is aangepast dat indien er gewerkt wordt met elektronische maaltijdcheques, dat het aantal uit het veld cod_aantal en het brutobedrag van de mc uit het veld cod_bedrag gehaald wordt Bugfixen module Maaltijdcheques Aanpassing elektronische maaltijdcheques aanmaak bug (TS) Bij aanmaak van elektronische maaltijdcheques ging er iets fout indien het om een grote bestelling ging waarbij de query naar de database niet kon verwerkt worden (meer dan 2100 parameters in query naar de sql). Er is een aanpassing gebeurd in de services.interop.dll zodat deze gegevens op een andere manier worden opgehaald. 39

40 12 Module Operations 12.1 Aanpassing parametriseerbare controles bij druk op bewaar-toets (checkfields) (EO) Er zat nog een probleem bij de parametriseerbare controles die uitgevoerd worden bij druk op de bewaar-toets (checkfields). Indien men bv. bij errortype askuser ingaf, werd er toch geen vraag aan de gebruiker gesteld. Dit kwam omdat in de code de controle gebeurt op waarde ASKUSER. Er was m.a.w. een probleem van hoofdletter-gevoeligheid. De programmatie is nu aangepast zodat dit niet meer hoofdletter-gevoelig is Aanpassing nieuwe grid-control (Prato_Ado_Gridbrowse) (EO) 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 funktie 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 = <gridnaam>). 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 hierbij rekening gehouden met de gebruikersgroep [CO, PROG ] en gebruiker (dus de velden cdkey en keywaarde 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 de grid meegegeven te worden over welke gebruiker en kantoorgroep het gaat. Dit gebeurt door het opvullen van de respectievelijke grid-properties personeelid en ParamOfficeGroup. De recordset met parameters wordt clientside gezet, waarna de parameters betrekking op de betreffende grid worden overlopen. De funktie voor het (trachten te) laden en toepassen van de parameters voor de 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 de grid is ingesteld. Dit treedt dus pas op voor het geval dat de ParamOfficeGroup property van de grid wordt ingesteld. Enkel in dit 40

41 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 de 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. binnen de RefreshGrid, bij het geval dat de ConnectionString -property van de grid niet is ingesteld. bij de bovengenoemde gevallen wordt de volledige parameter-set van toepassing op de grid geladen. Bovendien worden er op verschillende plaatsen subsets van de grid-parameters 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 de grid al is ingesteld. Voor elke eigenschap wordt hierop gechecked. Na het laden van een subset of de volledige set van parameters voor de grid (en toepassen van deze parameters op de property-array), worden de kolomeigenschappen pas effectief toegepast op de 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 de grid (en toepassen van deze parameters op de property-array), worden de zoekveld-eigenschappen pas effectief toegepast op de 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 de grid zou crashen na toepassing grid-parameters 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 zoekveld-label. Bv. men zou volgende kunnen doen om voor de FR-gebruikers de kolom-hoofding van de beginkolom en einde-kolom 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. 41

42 Bv. onzichtbaar zetten van kolommen voor DC-bedrijven: 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. Men dient de kolomhoofdingen en zoekveldlabels van de originele Nederlandstalige 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 FRgebruikers veranderen, dan dient men dit ook te doen via een parameter columnwidths(kontnr). [!! Voorwaarde is wel dat N contrat gevonden wordt in de vertaaluzb/vertaal-tabel in het Frans-veld 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 ingeval 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: 42

43 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 het geval waarbij parameters binnen de wiso-db terug te vinden zijn als voor het geval waarbij 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 de grid" (connectie van de recordset wordt gebruikt, tenminste als de recordset niet disconnected is) In de volgende gevallen zal men geen instellingen van grid-properties kunnen doen: Prato_PrintDestination control (die een Prato_Ado_Gridbrowse gebruikt) ingeval 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 ingeval een recordset, die disconnected is, wordt toegekend aan de grid (er is geen verbinding meer beschikbaar) 12.3 Ticket : companycar (03/06/2013) (FD) Als een nieuwe fiche aangemaakt wordt dan stond het vinkje t.l.v. klant in het grijs, dit is nu aangepast zodat het standaard uitgevinkt staat: 12.4 Ticket Taalinstellingen (PZ) 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). 43

44 12.5 Toon één van de Common Lists na het starten van HiAnt (SF) 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. Frmcommonlist, show, onstartup, <lijstcode> <lijstcode>: De code van de lijst die we na het starten van HiAnt willen tonen. Voorbeeld: Frmcommonlist, show,, onstartup, VervallenAttesten De lijst opvragen Na het starten van HiAnt wordt nu automatisch de lijst getoond: 12.6 Bugfixen module Operations BugFix: Ticket : Foutmelding bij toevoegen ecocheques aan bestelling indien je klantnummer meegeeft (KT) 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 klantummers ingaf, kreeg je een foutmelding. Deze bug is nu opgelost. 44

45 13 Module Dimona 13.1 Ticket 93868: Extra Controle Dimona Studenten zonder PlannedDays (FD) Het kon voorkomen dat er een dimona-aangifte verstuurd wordt, waarbij een student geen planneddays zou ingevuld hebben. Nu is er een extra controle toegevoegd, vlak voor het versturen van het bestand. Wanneer er een student (type STU of STX) inzit en het aantal Planneddays is leeg of 0, dan zal er een foutmelding komen en een bestandje geopend worden met daarin Prestid, wnnr, klnr en week van het studentencontract zonder dagen. Belangrijk : het dimonabestand wordt dan niet aangegeven, dit is dus ook zo voor al de andere contracten die mee in deze aangifte zitten. Om deze controle te activeren dien je onderstaande parameter aan te maken met waarde 1: Dimona, ExtraControle, StudentDagen, 0 Vertaling : STUZONDERDAG en ERR_STUZONDERDAG 13.2 Blokkeren van veld werkstudent nadat een contract aangegeven is aan dimona (JV)** Door parameter dimona, contract, blokkeerwerkstudentnadimona aan te maken met waarde 1 kan je het vinkje Werkstudent op het contract blokkeren indien dit contract reeds verstuurd is naar dimona 45

46 14 Module HiAnt SelfService 14.1 Aanpassing automatische berekening van bedrag voor premie a.d.h.v. loonformule (EO) Tevoren werkte de automatische berekening van een bedrag voor een premie a.d.h.v. de loonformules enkel voor de bestaande loonformule-niveaus ALG, PC, FI, TR en KU. Ondertussen zijn er binnen HiAnt voor de berekening loonformule-niveaus bijgekomen. De programmatie van HiAntSelfService is nu aangepast zodat de berekening van een bedrag voor een premie ahv. de loonformules werkt voor niveaus ALG, GSTATUUT, PC, PCGEW, PCSTAT, PCSUB, PCSUBGEW, PCSUBSTAT, FI, KSTATUUT, TR en KU. 46

47 15 Module Webservices 15.1 Ticket : BV Percentage (SF) Sinds deze versie vullen de webservices het veld BV percentage ook in nadat iemand zich heeft ingeschreven die nog niet in de HiAnt of de inschrijvingsdatabase voorkomt. De waarde wordt opgehaald uit de parameter initialisatie, frmwngeg, standaardbvpercentage en/of uit de parameter initialisatie, minbvpercentage, *. Indien de waarde van de parameter initialisatie, frmwngeg, standaardbvpercentage groter is dan de parameter initialisatie, minbvpercentage, * dan wordt die waarde genomen en anders de waarde van de parameter initialisatie, minbvpercentage, *. 47

48 16 Module arbeidsongevallen 16.1 Aanpssing statistieken + rapportjes (TS) Vanuit het arbeidsongevallenprogramma 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 16.2 Verwijderen van ongevallen enkel door co (TS) Je kan nu met onderstaande parameter activeren dat co-medewerkers ongevallen in het ongevallenprograma kunnen verwijderen. Je dient dan de waarde van onderstaande parameter in te vullen met 1: initialisatie, ongevallen, enkelcokanverwijderen, "0" Na een bevestigende vraag zal het ongeval verwijderd worden en gelogd worden in de logtable met type

49 17 Module Debiteuren 17.1 Debiteurenbeheer springen naar facturen overzicht minder kolommen tonen in facturenoverzicht (TS) Als parameter initialisatie, debiteuren, beknoptoverzichtfacturen, 0 op 1 wordt gezet en men gaat vanuit het scherm Debiteurenbeheer naar de facturen dan zullen de onderstaande kolommen niet zichtbaar zijn: FP Uren Netto BTW PrintDatum Wgnr 49

50 18 Module Bouw 18.1 Registratienummer is niet meer verplicht in de bouw (JV)* In de code staat de onderstaande parameter standaard op 1 PrestatieIngave, KlantParkom124, RegistratieNrVerplicht omdat het in het verleden een verplichting was om een registratienummer in te geven voor een klant die resulteert onder het paritair comité van de bouw (PC 214). Het registratienummer is nu niet meer verplicht in de bouw, de standaardwaarde van de parameter werd dan ook op 0 gezet in HiAnt. Klanten die deze parameter zelf hebben aangemaakt met waarde 0 mogen deze in principe wissen nu Controle op registratienummer bouw is verwijderd (JV)** In het verleden kon je, via een parameter, activeren dat HiAnt erover waakt dat een prospect in de bouw een registratienummer moet ingevuld hebben in de fiche alvorens dat je deze klant kon maken. Aangezien dit niet meer verplicht is werd ook de controle uit HiAnt verwijderd. Parameter PrestatieIngave, KlantParkom124, RegistratieNrVerplicht wordt dus niet meer gebruikt en mag verwijderd worden indien nog aanwezig in de database. 50

51 19 Module Dienstencheques en planning 19.1 Ticket Aanpassingen prestatiestaat planningsmodule (PZ) Volgende parameters werden ingebouwd om enkele extra opties te voorzien bij het afdrukken van de prestatiestaat (specifiek document van een bepaalde klant) vanuit het planningscherm: Parameter : PrestatieStaat, Afdruk, ToonContactMedewerker Indien waarde = 1 (standaard = 0) zal HiAnt op de prestatiestaat de naam van de medewerker (ingelogde user) tonen ipv de contactpersoon van de dienstverlener Parameter : PrestatieStaat, Afdruk, ToonUrenPerKlant Indien waarde = 1 (standaard = 0) zal HiAnt de gepresteerde uren tonen per klant ipv 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 Facturatie gezinnen wijziging comfortpackage (TS) Achtergrondinfo: Een bepaalde klant biedt aan zijn gezinnen een comfortpackage aan. Dit pakket garandeert een extra service aan de gezinnen, mits een bepaalde facturatiekost per maand. Het bedrag wordt steeds via domiciliëring afgehouden, de facturen zelf worden niet afgedrukt. Door de parameter initialisatie, gezinnen, comfortpackage, 0 door deze op 1 in te stellen is men in de mogelijkheid om bij een gezin aan te duiden of deze een comfortpackage heeft. Het gegeven is zichtbaar in het tabblad commercieel Wanneer je comfortpackage aanvinkt is zowel het veld begindatum als dom. nr. (domiciliëringsnummer) verplicht in te geven. Bij het bewaren van de gezinsfiche waarin het veld comfortpackage is aangevinkt, zal HiAnt controleren of het gezin reeds klant is, zo nee wordt de fiche eerst klant gemaakt (het klnr wordt ingevuld). Standaard zal facturatiesysteem op 1210 (maandelijks) worden ingesteld in de gezinsfiche. Dit kan je echter sturen via de parameter initialisatie, maakgezinklant, facturatiesysteem, Standaard zal betalingstermijn op type 12 ( in spec. Db was dit domiciliëring) geplaatst worden. Ook dit kan je sturen via de parameter initialisatie, maakgezinklant, betalingssyteem, 12 51

52 Het veld BTW wordt op Nee geplaatst, en in de optiebalk wordt de code BN toegevoegd indien deze nog niet in de optiebalk voorkomt. Bij het toevoegen aan de fakturatierun krijg je een tabblad Fakturatie gezinnen te zien (hiervoor moet de reeds bestaande parameter initialisatie, fakturatie, gezinnen, 0 met waarde 1 worden ingesteld). Het fakturatiesysteem voor gezinnen op dit tabblad is te bepalen via de parameter initialisatie, gezinnen, factsysteem, Standaard is dit 1210 maandelijks. Bij het toevoegen van gegevens aan de fakturatierun via het tabblad Fakturatie gezinnen zal indien jouw onderneming gebruik maakt van dit systeem comfortpackage de parameter initialisatie, facturatiegezin, berekeningstype, 1 op 2 moeten ingesteld worden. Hiermee worden alle gezinnen toegevoegd aan de fakturatierun die in die betreffende periode comfortpackage hebben aangeduid in de gezinsfiche. Bij start fakturatie wordt er gekeken of dit gezin in die periode reeds een faktuur heeft. Gezinsfiches met dezelfde straat, huisnr, busnr en postnr worden als zelfde gezin beschouwd, en krijgen maar één faktuur per fakturatieperiode. Indien nog geen faktuur gevonden in die periode voor deze gezinsfiche(s) zal er een nieuwe faktuur worden aangemaakt. Hierbij zal - Faktuurd.wnnr = Val(geefparamwaarde("initialisatie", "facturatiegezin", "tegebruikenwnnr", " ")) - Faktuurd.sektie= Val(geefparamwaarde("initialisatie", "facturatiegezin", "tegebruikensektie", "115")) - Faktuurd.kode= Val(geefparamwaarde("initialisatie", "facturatiegezin", "tegebruikencode", "9999")) - Faktuurd.bedrag = zal bepaald worden adhv de parameter initialisatie, facturatiegezin, bedrag waarbij de tscrea bepaalt vanaf welke datum dit bedrag geldt. De datum is altijd de eerste van de maand van de facturatieperiode. Indien de parameter niet gevonden wordt, zal het bedrag 5 euro bedragen. Nieuw: [Parameter initialisatie, FacturatieGezin, BerekeningsType, 1 moet op 2 staan] Deze module werd aangepast, nog steeds te activeren via parameter initialisatie, gezinnen, ComfortPackage, 0 op 1 in te stellen Vanaf nu noemt dit fakturatie gezinsbijdrage Bedoeling is om de gezinnen maandelijks een factuur van 5 euro (indexeerbaar) aan te maken, op basis van domiciliëring. Op het tabblad commercieel kan men instellen of het gezin een facturatie dient te hebben Hier geeft men de begindatum vanaf in (verplicht) en eventueel datum t/m. Verder is er een nieuw tabblad bijgekomen nl. betaling Hier kan men instellen dat de facturatie gebeurt via domiciliëring, of dat het gezin niet gefaktureerd moet worden (dit is enkel in te stellen door co-gebruiker) 52

53 Indien het vinkje domiciliëring aangevinkt is, dan zijn velden Geldig vanaf, IBAN nummer en BIC Code verplicht in te vullen. Mandaat referte is steeds het klantnummer (gezin dient dus klant gemaakt te worden dit wordt automatisch gedaan als vinkje op tabblad Commercieel is aangeduid) Ook is er mogelijkheid om voor bepaalde periodes dit gezin niet te faktureren. Dit is zichtbaar in de rechtse grid. Door op + te klikken kan men een lijn toevoegen. Begin- en einddatum alsook de reden zijn verplicht in te vullen. De facturatie zelf is ongewijzigd, alleen de manier van toevoegen van gezinnen is gewijzigd. Enkel gezinnen die het vinkje fakturatie hebben aangevinkt op het tabblad Commercieel, en domiciliëring hebben aangeduid zullen in de run worden opgenomen, rekening houdend met begin- en einddatum van de facturatieperiode en eventueel uitsluiting op basis van grid niet te factureren. Bij de facturatie worden na het berekenen de volgende controlelijsten aangemaakt (initialisatie, FacturatieGezin, BerekeningsType, 1 moet op 2 staan) Then - Controle ontbrekende prestaties o Er wordt gekeken of de gezinnen die zijn berekend ook als afdeling op een contract zit in die periode (tabblad afdelingen bij contracten, waar men voor- en nammiddag een gezin als afdeling kan instellen) o Indien gezinnen niet gevonden zijn bij de afdelingen van de contracten zullen deze als excel getoond worden aan de gebruiker. - Controle ontbrekende adresgegevens o Er wordt gekeken of de gezinnen die zijn berekend correcte adresgegevens bevatten. Straat Huisnr Postnr Gemeente 53