28

Release Notes Afdrukdatum: 2009/09/28

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 4.196

1/6

1.

V4.196 1.1. -

1.2.

Nieuwe bestanden Pratocontrols.ocx

Aanpassing pratocontrols.ocx – nieuwe gridbrowse

Indien er in de selectstring van de nieuwe gridbrowse gegevens stonden voor het eigenlijke SELECT-commando, werd dit verwijderd, wanneer in de gridbrowse gebruikt werd gemaakt van een maxium aantal te tonen records. Voorbeeld : gebruik van het commando SET DATEFIRST voor het SELECT-commando. Aanpassing is gebeurd in de pratocontrols.ocx.

1.3.

Bugfix Maandprestatieingavescherm

Wanneer men in het maandprestatieingavescherm zat bij een bepaalde werknemer, en men liet het scherm openstaan, om vervolgens via de werknemerlijst een andere werknemersfiche te openen, werd achterliggend een variabele veranderd naar dit nieuwe werknemernummer. Wanneer men dan daarna terug in het maandprestatieingavescherm kwam, en men een actie uitvoerde (bv. klaarzetten van prestaties), werd niet gewerkt met het werknemernummer dat men zag, maar met het werknemernummer van de laatst geopende fiche. Aanpassing is gebeurd in de programmatie zodat de variabele binnen het maandprestatieingavescherm afgeschermd blijft.

1.4.

Bugfix: “eenvoudige beheerscherm roosters en cycli”, ingeval van Securex-exporters: bij Securex-exporters wordt er voor alle roosters van de cyclus als uren PT het gemiddelde uren PT over alle roosters heen ingevuld. Echter de Q-waarde binnen de roosters volgde deze automatisch berekende uren PT niet

Bij Securex-exporters wordt er voor alle roosters van de cyclus als uren PT het gemiddelde uren PT over alle roosters heen ingevuld. Het probleem was echter dat de Q-waarde binnen de roosters deze automatisch berekende uren PT niet volgde. Met als gevolg problemen zoals: na invullen van de contract-gegevens op basis van het langetermijn-rooster stonden de contracten niet goed. De programmatie is aangepast om dit probleem te verhelpen.

1.5.

Veranderen van kantoor in het hoofdscherm

Wanneer men van kantoor wenst te veranderen via het menu kantoor in het hoofdscherm, zal HiAnt controleren of er nog een prestatie-ingave scherm (week- en maandingave) openstaat. Indien dit het geval is, krijgt de gebruiker de melding dat deze eerst gesloten dienen te worden, alvorens men van kantoor kan veranderen.

1.6.

Aanpassing query-analyser

Wanneer men een query wilde uitvoeren, waarbij er bv. gebruik wordt gemaakt van instellen van variabelen met DECLARE, of een commando SET DATEFIRST werd gegeven voor de eigelijk


2/6

SELECT begon, dan werd het resultaat niet in een grid getoond, en kreeg men enkel de melding -1 rows affected. Er is nu een aanpassing gebeurd, zodat steeds het resultaat in een grid wordt getoond, behalve wanner de query start met volgende commando’s "DELETE", "INSERT", "UPDATE", "TRUNCATE", "DROP", "CREATE".

1.7.

Menu bereken sociaal abonnement vanuit week- en maandingavescherm prestaties

Het menu voor het automatisch berekenen van sociaal abonnement is enkel bedoeld voor werknemers met een dienstencheque statuut. Indien men deze actie opstart voor een werknemer waarvan het paritaire comité verschillend is van 322.01, dan zal de gebruiker een melding krijgen dat dit niet van toepassing is voor deze werknemer. Indien men toch wenst gebruik te maken van deze module voor niet-dienstenchequers kan men de volgende parameter op 1 instellen. "INITIALISATIE", "BEREKENSOCABB", "NIETDC", "0" Opgelet, indien men dit bij een niet-dienstenchequer zou uitvoeren, zal tijdens de berekening van het loon van deze werknemer, het sociaal abonnement nogmaals worden uitgerekend, wat dus tot dubbels kan leiden!

1.8.

Aanpassing planningsmodule

Bij het eenmalig toevoegen van een werknemer/gezin aan een gezin/werknemer via de grid beschikbare gezinnen/werknemers, zal HiAnt geparameteriseerd kunnen worden, om te bepalen welke code dient gebruikt te worden. Parameter "Planning", "ToevoegenEenmalig", "CodeTeGebruiken", "AD". Standaard is dit dus AD. Indien de parameter leeg wordt gemaakt, zal HiAnt de code gebruiken die bij de klant voor die dag is ingesteld (type 100 of 105). Bij toevoegen aan langetermijn planning, wordt steeds de code gebruikt die in het rooster van het gezin (op bestellingniveau –planning) is ingesteld op die dag.

1.9.

Automatisch berekenen sociaal abonnement in week-ingave scherm prestaties

Nu is het ook mogelijke om in het gewone prestatie-ingavescherm (week ingave scherm), het sociaal abonnement automatisch te laten uitrekenen. Procedure kan opgestart worden via het menu Acties – Bereken sociaal abonnement. Dit menu staat standaard niet op, en dient geactiveerd worden door volgende parameter op 1 in te stellen “changecontrols”,”frmprestgeg1”,”mnuActie(10).visible”,”0”

1.10. Onzichtbaar maken van aantal kilometers en type transport in contract bij dienstenchequers


3/6

Indien het om een werknemer met statuut dienstencheque gaat, zullen standaard de gegevens ivm het aantal kilometers en het type transport in het contractdetail scherm niet zichtbaar zijn. Men kan met volgende parameter afwijken, zodat deze gegevens steeds worden getoond. Hiervoor dient men de parameter op 0 in te stellen. "Scherm", "frmcontgeg", "VerbergKmEnTransportMiddelBijDC", "1"

1.11. Ticket 46381: Het veld ‘dienstverlener’ in de bestelling enkel verplichten indien de gekozen sektie een DC-sektie is. ALLE k antoren moeten de mogelijkheid hebben om bestellingen voor DC-ers in te geven ongeacht of het hierbij gaat over een DC-kantoor of niet. Indien ze een dergelijke bestelling aanmaken dan moet men verplicht de dienstverlener invullen. Indien het echter over een bestelling gaat waarbij GÉÉN DC-sektie wordt geselecteerd, dan mag het veld Dienstverlener niet worden ingevuld! Dus het veld dienstverlener enkel verplicht in te vullen indien het gaat over een DC-sektie icm de onderstaande parameter: Als men de parameter (Scherm, frmbestelgeg, dienstverlenerverplicht) de waarde 2 geeft, dan wordt bij het bewaren de volgende controles gedaan. è dienstverlener ingevuld o geen sektie: foutmelding dat er geen DC sektie gekozen is o geen DC sektie: foutmelding dat er geen DC sektie gekozen is. è dienstverlener niet ingevuld o DC sektie ingevuld: foutmelding dienstverlener verplicht.

1.12. Parametriseerbare controle voor opstart loonberekening: controleren of alle prestaties een ploegcode hebben Voor alle duidelijkheid: indien “0 – geen ploegcode” is ingevuld binnen een prestatie wordt dit ook beschouwd als een ingevulde ploegcode. Bij bepaalde uitzendbedrijven is het belangrijk, omwille van de loonberekening, dat de ploegcode is ingevuld (zij het met “0 – geen ploegcode”). Er kan nu gecontroleerd worden vóór opstart loonberekening of bij alle prestaties horende bij deze loonrun de ploegcode is ingevuld. Deze controle gebeurt niet standaard. Men kan deze activeren door een parameter ("scherm", "frmloonber", "PloegCdVerplicht") aan te maken met waarde 1. Indien er prestaties zijn zonder ploegcode, wordt er aan de gebruiker gevraagd of hij bij deze prestaties de “standaard ploegcode” automatisch wil laten invullen. Zo ja, wordt de ploegcode binnen de prestaties opgevuld en gaat de loonberekening verder. Zo neen, dan stopt de loonberekening. Men kan via een parameter deze “standaard ploegcode instellen”. Namelijk via parameter ("initialisatie", "ploegcode", "standaardwaarde"), die standaard de waarde 0 aanneemt.


4/6

1.13. Programmatie onderhoud: probleem bij mastercontracten als begindatum niet lag binnen jaar en week van de master; echter bij aanmaak bijkomende master via "beheer mastercontract" werden het jaar en de week niet opnieuw bepaald --> steeds probleem Er was sinds kort ook een controle bijgekomen bij mastercontracten: controle dat de begindatum van de master moest liggen binnen het jaar en de week van de master. Echter bij aanmaak van nieuwe masters via het scherm “beheer mastercontract” werden het jaar en de week niet opnieuw bepaald (wel overgenomen van de bestaande master). Dus bij bewaren van deze nieuwe master was er steeds het probleem dat de begindatum van het mastercontract niet lag binnen het jaar en de week van de master. Volgende items zijn aangepast: 1) Bij het bewaren van een master wordt niet meer gechecked of de begindatum binnen het jaar en de week van het mastercontract ligt (is bij mastercontracten immers ook niet zo van belang). Wel wordt nog steeds gechecked of het jaar van het mastercontract en het jaar van de begindatum van het mastercontract overeenkomen. 2) Bij alle methodes om masters bij te maken vanuit het scherm "beheer mastercontract" (aanmaak nieuwe master aan begin bestaande master, aanmaak nieuwe master aan einde bestaande master, aanmaak nieuwe master middenin bestaande master) wordt nu WEL getracht het jaar en de week voor de nieuwe master te bepalen (gebeurde ervoor niet - jaar en week werden van bestaande master overgenomen --> met als gevolg foutmeldingen bij bewaren van deze master omdat jaar en week van de master niet overeenkwamen met de begindatum). Jaar en week van de nieuwe master worden als volgt bepaald en ingevuld: a. indien er betaalperiode-gegevens bestaan voor de periode van de nieuwe begindatum --> jaar en week worden uit de betaalperiode-tabel genomen. b.

indien er GEEN betaalperiode-gegevens bestaan voor de periode van de nieuwe begindatum (toekomstig jaar) --> het jaar = jaar van de begindatum; de week wordt op 0 gezet

1.14. Nu ook mogelijkheid om voor een klant de ingave van een kostenplaats in de contracten en prestaties verplicht te maken (klant-optie IKV, analoog aan reeds bestaande klant-optie IAV) De afdelingen kunnen reeds verplicht worden om in te geven via de optie IAV in te geven in de klantenfiche. Een gelijkaardig systeem is nu ontwikkeld om de ingave van kostenplaatsen verplicht te maken optie: klant-optie IKV (Ingave Kostenplaats Verplicht). De volgende aanpassingen aan de programmatie zijn doorgevoerd: 1) Bij manueel toevoegen van een prestatie of premie zal dit tegengehouden worden indien men de kostenplaats niet invult bij een klant met optie IKV. 2) Bij de aanmaak van prestaties op basis van het contract ("lees prestaties in") wordt dit tegengehouden indien er een contract is waarbij de kostenplaats niet is ingevuld.


5/6

3) Bij klaarzetten prestaties wordt er ook gecontroleerd op het ingevuld zijn van de kostenplaats bij de prestaties en de manueel ingegeven premies. De controle op ingevuld zijn kostenplaats, bij het klaarzetten van de prestaties, kan aan- of afgezet worden (standaard staat deze op). De controle kan afgezet worden door een parameter ("ZetOpBerekenen", "Controle", " ControleKostenplaatsVoorIKV ") aan te maken met waarde 0. Er kan ook ingesteld worden of de controle op ingevuld zijn kostenplaats, bij het klaarzetten van de prestaties, blokkerend is of niet. Standaard is de controle blokkerend. De controle kan niet-blokkerend gemaakt worden door een parameter ("ZetOpBerekenen", "ControleKostenplaatsVoorIKV ", "blokkerend") aan te maken met waarde 0. 4) !!!!! Ook ivm de verplichte invulling van AFDELINGEN (klanten met optie IAV) is het nu zo dat er een controle is bijgemaakt bij het klaarzetten van de prestaties. Helemaal analoog aan de controle, bij klaarzetten prestaties, op het ingevuld zijn van de kostenplaatsen. De controle op het ingevuld zijn van een afdeling wordt dus uitgevoerd bij klanten met opties IAV. Ook kan deze controle aan- of afgezet worden (standaard staat deze op). De controle kan afgezet worden door een parameter ("ZetOpBerekenen", "Controle", "ControleAfdelingVoorIAV") aan te maken met waarde 0. Er kan ook ingesteld worden of de controle op het ingevuld zijn van een afdeling, bij het klaarzetten van de prestaties, blokkerend is of niet. Standaard is de controle blokkerend. De controle kan niet-blokkerend gemaakt worden door een parameter ("ZetOpBerekenen", "ControleAfdelingVoorIAV", "blokkerend") aan te maken met waarde 0. Deze aanpassingen zijn doorgevoerd in beide prestatie-ingaveschermen.

1.15. Ticket 46084 : Aanpassen posities velden op C32 Controlekaart FR Voor de C32Controlekaart de exacte positie bepalen van de invulvelden op de Franstalige uitvoering waarna dit via een correct invullen van de parametergegevens kan worden in orde gebracht. De posities werden aangepast in de tabel.


6/6

28

Recommend Documents