21

Release Notes Afdrukdatum: 2012/12/21

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.041

1/24

1.

V6.041 1.1.

Bugfixes: 1.1.1. Opvolgingen van uit prestatie-ingaveschermen Bij het ingeven van opvolgingen vanuit het prestatieingavescherm kreeg de gebruiker de melding “type mismatch”. Dit is verholpen.

1.1.2. Contacttype is leeg bij ingave vanuit werknemerslijst Vanaf nu is het contacttype standaard weer op UZK gezet wanneer je vanuit de werknemerslijst een opvolging ingeeft via F11.

1.1.3. Controle 3 maanden in dienst bij DC De controle of een DC’er een vast contract moet krijgen 3 dagen na zijn eerste interim contract ging slechts 1 jaar terug kijken naar een eerste tewerkstelling. Dit was niet correct. De controle is aangepast zodat er gekeken wordt naar het eerste gedimoniseerd contract, ongeacht de leeftijd ervan.

1.1.4. Export facturen – dubbele of driedubbele lijnen (tgv ticket 88639) Door een uitbreiding van de facturatierun exportmodule kregen klanten ongewenst meerdere lijnen per facturatierun te zien. Dit was te wijten aan extra kolommen die achterliggend werden ingeladen om nieuwe functionaliteit te zien. (activeerbaar via parameter "scherm", "frmexport", "ToonFactuurZoekveld" met waarde 1). De code is nu aangepast zodat mensen die deze parameter niet gebruiken ook geen hinder ondervinden van de aanpassingen en terug enkel 1 lijn per facturatierun zien.

1.1.5. Ticket 96214, 95577: Type mismatch bij het verlaten van OpvolgingsType zonder selectie Wanneer je in het opvolgingsscherm het veld opvolgingstype verlaat zonder dat er een selectie is gemaakt (bv door verkeerde selectie in te typen en dan te annuleren in het lijstschermpje) crashte HiAnt door een type mismatch. Deze werd veroorzaakt door het proberen in te laten van detailtypes op basis van het geselecteerde type.

1.1.6. ticket 95514 : bufix : werkrooster (13/12/2012) Als persoon elke week bij de zelfde klant werkt met zelfde begin uur maar de ene week een ander eindweek dan de volgende week, dan werden er steeds 2 periodes aangemaakt.

1.1.7. Bugfix: Ticket 95408: klantoptie met tekst in opties scherm, zet waarde niet in optiesbalk indien deze maar 1 karakter is Indien er in het opties-scherm een klantoptie met tekst wordt gekozen en in de tekstbox wordt een waarde van 1 karakter ingevuld, wordt in de opties-balk van de klfiche deze waarde niet getoond. Enkel de klantoptie zonder ‘=’ wordt getoond. Dit is nu aangepast. Technisch: Code aangepast in ‘frmOptie.cmdbewaar_Click:


2/24

If Len(Trim(ls(txtingave(i).text))) >= 1 Then

1.1.8. Import Harmony bug Indien men kostenplaats had aangemaakt met een accentje ‘ in de omschrijving, crashte de import. Hiervoor zijn de nodige aanpassingen doorgevoerd.

1.1.9. Werkpostfiches nieuwe module – bug Wanneer men in de nieuwe module van werkpostfiches via menu gegevens ouder dan -... de lijst opvraagt en men wil dan naar de klant springen via F3 kreeg men foutmelding. Ook update handtekening werkte niet indien men dan in detail van werkpostfiche ging. Bug opgelost in nieuwe versie van jobsheet.

1.1.10.Werkpostfiches nieuwe module – bug Indien men gebruik maakt van de mogelijkheid tot koppelen van een ingescande pdf, werd het vinkje “Gezondheidsbeoordeling uit te voeren voorafgaand aan tewerkstelling” niet onzichtbaar gemaakt.

1.2.

Probleem, ingeval bij uzk meerdere premies dubbel voorkomen op dezelfde datum, bij doorsturen “uurlonen op afwijkende kostenplaats” naar HDP; probleem in de export naar HDP

Probleem was volgende: Als er bv. 2 dubbele premies (premcode1 en premcode2) zijn bij een bepaalde tew: - premcode1 wordt doorgestuurd onder - en premcode1 wordt doorgestuurd onder --> ook uurlonen doorsturen onder - premcode2 wordt doorgestuurd onder - en premcode2 wordt doorgestuurd onder --> uurlonen werden ook nog eens doorgestuurd onder . Dit gaf een probleem bij validatie van de export: dubbele uurlonen bij dezelfde "sleutel-combinatie". De programmatie is aangepast om dit probleem te verhelpen: niet nog een tweede maal de uurlonen doorsturen bij eenzelfde “sleutel-combinatie”.

1.3.

Probleem bij export loongegevens naar DAVE – er kan een DCverschil optreden omwille van het feit dat “de gegevenslijnen niet in de juiste volgorde worden opgehaald uit het tijdelijk Access-bestand”

De export van loongegevens naar boekhoudpakket DAVE kan in sommige gevallen DCverschillen geven/melden. Terwijl er in feite geen DC-verschillen zijn. Bij ophalen van gegevens uit het Access-bestand moet steeds een Credit-lijn gevolgd worden door een Debet-lijn met hetzelfde bedrag. Bij ophalen gegroepeerde gegevens uit het Access-bestand wordt volgende ordening toegepast: "order by loonruns,klcode,wgnr,profitcenter,kostenplaats,pjaarperiode,KJaarWeek,dc" Bij export naar DAVE werd de profit-center info niet ingevuld in het Access-bestand, omdat de “profitcenter” info niet nodig is voor aanmaak van het output-tekst-bestand.


3/24

In sommige gevallen konden er 2 Credit-lijnen voorkomen met dezelfde “loonruns,klcode,wgnr,profitcenter,kostenplaats,pjaarperiode,KjaarWeek”-info. Er was dan wel een verschil in wginternecode-info. Dit zorgde ervoor dat er bij ophalen van de gegevens 2 Credit-lijnen elkaar volgden. De programmatie van de export naar DAVE is aangepast: Nu wordt de profitcenter wel ingevuld in het Access-bestand. Dit zorgt ervoor dat bij ophalen van de gegroepeerde gegevens uit het Access-bestand, door de ordening op profitcenter, dat nu wel een Credit-lijn gevolgd wordt door een Debet-lijn met hetzelfde bedrag.

1.4.

Aanpassing export naar Securex: voor uitzendbedrijven waarbij de kantoornummering niet gelijkloopt met de codes voor de kostenplaatsen, kan men via parametrisatie zorgen dat de exploitatie-adressen (gelijk aan kostenplaatsen) doorgestuurd via de PI2 de “afwijkende kostenplaatsen” bevat

Bij bepaalde uitzendbedrijven die exporteren naar Securex loopt de kantoornummering niet gelijk met de codes voor de kostenplaatsen. Indien voor dit uitzendbedrijf de exploitatie-adressen (gelijk aan kostenplaatsen) via de PI2records dienen doorgestuurd te worden, was er een probleem Via de PI2 werd het exploitatie-adres immers altijd bepaald ahv de laatste 2 cijfers van het kantoornummer. De programmatie van de export naar Securex is nu aangepast: Bij doorsturen van de exploitatie-adressen binnen de PI2 heeft men nu de mogelijkheid om de wgafd!boekhoudcode door te sturen ipv de 2 laatste cijfers van het kantoornr. Er wordt gewerkt ahv de boekhoudcode uit de wgafd indien men parameter ("ExportSecurex", "PI2", "Pi2ExplAdr_UitWgafdBoekh") aanmaakt met waarde 1.

1.5.

Aanpassing export naar Securex: veld code.externalcodesuppl gebruiken ipv code.externalcode2

Er bestaat de mogelijkheid binnen bepaalde databases dat men naar verschillende sociaal secretariaten kan exporteren. Hierbij had het “ander sociaal secretariaat” uit de code-tabel veld externalcode2 nodig. De export naar Securex is hiervoor aangepast: niet meer gebruiken van veld code.externalcode2, maar gebruik van code.externalcodesuppl (want anders overlapping met instellingen voor “ander sociaal secretariaat”).

1.6.

Mogelijkheid van export naar verschillende sociaal secretariaten (overgang) waarbij automatisch wordt bepaald ahv. de periode van de gegevens naar welk sociaal secretariaat wordt geëxporteerd

Er is programmatie aangemaakt zodat op éénzelfde database kan geëxporteerd worden naar verschillende sociaal secretariaten.


4/24

De export bepaalt, zowel voor lonen, voorschotten (en ook export “enkel signaletiek”) ahv de periode van de gegevens naar welk sociaal secretariaat gaat geëxporteerd worden.

Het verhaal waarbij de parameter ('Export', 'Loon', 'SociaalSecretariaat') meerdere sociale secretariaten bevat, bvb. ACERTA,CLB en waarbij de gebruiker zelf dient te kiezen naar welk sociaal secretariaat hij wenst te exporteren, blijft werken.

Werking van het systeem van automatisch bepalen naar welk socsec er wordt geëxporteerd: - Men dient 2 parameters aan te maken: * ('Export', 'Loon', 'OldSociaalSecretariaat') waarbij men RSZcategorie invult met datumvan en datumtot in de vorm bv. 1900-01-01/2012-12-31 * ('Export', 'Loon', 'SociaalSecretariaat') waarbij men RSZcategorie invult met datumvan en datumtot in de vorm bv. 2013-01-01/2099-12-31 - Indien er een parameter ("Export", "Loon", "OldSociaalSecretariaat") bestaat wordt er bij beide parameters gecontroleerd dat RSZcategorie een datumvan en datumtot bevat en moeten beide periodes "oldsocsec" en "newsocsec" elkaar opvolgen. - Indien er een parameter ("Export", "Loon", "OldSociaalSecretariaat") bestaat, heeft men ook de mogelijkheid om voorschotten te exporteren naar één/beide sociaal secretariaten. Hiervoor dienen dan parameters ('Export', 'Voorschot', 'OldSociaalSecretariaat') resp. ('Export', 'Voorschot', 'SociaalSecretariaat') voor te komen, die eveneens binnen veld RSZcategorie de periode bevatten. De periodes "oldsocsec" en "newsocsec" dienen voor de voorschotten overeen te komen met deze voor de lonen. - In het geval de gewone socsec-parameter zonder periode-opgave (steeds export naar 1 sociaal secretariaat) of de oldsocsec-parameter of de socsec-parameter MET periodeopgave waarde "SECUREX" of "CLB" heeft, heeft men steeds de keuze tussen volgende mogelijkheden van export: * 1 - Signaletiek en loongegevens van geselecteerde loonruns. * 2 - Enkel signaletiek (nieuwe en gewijzigde contracten). * 3 - Voorschotten van geselecteerde bankruns en signaletiek (nieuwe en gewijzigde contracten). Indien men voor "SECUREX" of "CLB" kiest om signaletiek te exporteren, dan wordt 1) de voorgestelde einddatum signaletiek standaard beperkt tot de "datum einde bij socsec" als dit het "oude sociaal secretariaat is 2) de voorgestelde begindatum signaletiek standaard beperkt tot de "datum begin bij socsec" als dit het "nieuwe sociaal secretariaat is.. Bij de andere sociaal secretariaten is er enkel een export van lonen. - Indien parameter ('Export', 'Voorschot', 'OldSociaalSecretariaat') bestaat (men kan exporteren naar 2 sociaal secretariaten) dan wordt, bij zowel export van lonen als bij export van voorschotten, geblokkeerd indien de geselecteerde bankruns/loonruns, gegevens bevatten van zowel "periode voor overgang" als "periode vanaf overgang" - Aan de hand van de periode van de gegevens wordt automatisch bepaald (zowel bij lonen, voorschotten als signaletiek) naar welk sociaal secretariaat de gegevens zullen geëxporteerd worden. [ De bedoeling is ook dat, wanneer er export naar 2 verschillende sociaal secretariaten mogelijk is (If strOldExportToExternalSocSec <> "" Then) dat dan, ingeval "strExportToExternalSocSec = strOldExportToExternalSocSec" de velden met suffix 2 worden gebruikt (externalcode2, socsecexportype2 en evt. verdere overlappende velden [sektieexternalcode2, wg.bedrijfscd2] ) en ingeval strExportToExternalSocSec = strNewExportToExternalSocSec de velden zonder suffix worden gebruikt.


5/24

Er dient dan aan de exportfunktie een strSuffix meegegeven te worden die leeg is of "2" is. Dit wordt dan achter de velden externalcode, socsecexportype... geplakt. De beide exports dienen dan wel hiervoor klaar te zijn (afhandelen van de suffix). Momenteel stelt zich het probleem van "meegeven van de suffix aan de exportfunktie" nog niet. Momenteel is het zo dat bij de gevallen van 2 sociale secretariaten steeds als oude socsec of nieuwe socsec CLB betrokken is. Binnen de export naar CLB is het zo dat er momenteel via parameters [ ("export", "CLB", "externalcode2"), ("export", "CLB", "Socsecexporttype2"), ("export", "CLB", "Bedrijfscd2") ] voor is gezorgd dat er steeds de "2" velden worden gebruikt. ]

1.7.

Via parameter kunnen instellen welke opties (geselecteerde rij, gemarkeerde rijen, alle rijen) men krijgt bij gebruik menu “Prestatie voorschot” (uzk klaarzetten om voorschot voor te berekenen)

De vraag is gekomen om te kunnen instellen welke opties (geselecteerde rij, gemarkeerde rijen, alle rijen) men krijgt bij gebruik van menu “Prestatie voorschot” (in maandingavescherm). De programmatie is aangemaakt zodat men via parameter ("frmprestgeg2", "voorschotstatus", "SelectOpties") kan instellen welke opties er zullen verschijnen. Binnen deze parameter dient men binnen het waarde-veld de numerische waarde van de opties, gescheiden door komma, in te geven. Volgende opties zijn er: -1 Geselecteerde rij -2 Gemarkeerde rij(en) -3 Alle rijen uit de lijst Dus indien de parameter waarde “1, 2” heeft kan men enkel de geselecteerde rij of de gemarkeerde rijen klaar zetten voor de voorschot-berekening.

1.8.

Bij gebruik menu “Prestatie voorschot” (uzk klaarzetten om voorschot voor te berekenen): controleren dat de uzk prestaties heeft voor al de in aanmerking te nemen dagen voor voorschotberekening waarvoor er in de planning uren zijn ingegeven

Sinds enige tijd bestaat er het menu “Prestatie voorschot” binnen het maandingavescherm voor prestatie-ingave. Via dit menu kan men iemand klaarzetten om voorschot voor te berekenen (bij deze uzb is deze voorschot-status verplicht; indien een uzk geen voorschot-status heeft, wordt er geen voorschot voor berekend). In het begin kon men enkel de geselecteerde uzk klaarzetten voor de voorschotten. Dus men volgde normaliter altijd de werkwijze: prestaties ingeven en erna klaarzetten voor de voorschotten. Recent zijn de opties erbij gekomen om ook de gemarkeerde lijnen of alle lijnen uit de lijst klaar te zetten voor de voorschotten. Echter gebruikten de consulenten dit menu ook al had men niet eerst al de nodige prestaties voor de gemarkeerde lijnen/alle lijnen ingegeven.


6/24

Nu bestaat er de mogelijkheid dat de prestaties gecontroleerd worden alvorens de uzk klaar kan gezet worden voor de voorschotten. Deze controle gebeurt enkel indien parameter ("frmprestgeg2", "voorschotstatus", "CheckAanwezigheidPrestaties") de waarde 1 heeft, hetgeen standaard het geval is. Er is voor gezorgd dat deze controle rekening houdt met alle types van voorschotberekening: - bij voorschottype “1 = aan de hand van het bedrag in het attest” er gebeurt geen controle, vermits het bedrag van de voorschotberekening niet afhangt van de prestaties - bij voorschottype “2 = vast bedrag per gewerkt uur” en “3 = percentage van het uurloon per gewerkt uur” er gebeurt WEL controle, vermits het bedrag van de voorschotberekening afhangt van de prestaties

De controle houdt ook rekening met de “in aanmerking te nemen dagen voor voorschotberekening”: Via de bestaande parameter ("Scherm", "frmvoorschottenlst", "VraagNaarDatum") wordt er ingesteld welke dagen in aanmerking worden genomen voor voorschotberekening: Bij parameterwaarde: - 0: (er wordt bij voorschotberekening geen einddatum aan de gebruiker gevraagd) het systeem berekent het voorschot op alle codes die ingegeven zijn voor de volledige Maand er wordt ook gechecked op de prestaties van de ganse maand - 1: (het systeem vraagt de gewenste einddatum aan de gebruiker), standaard stelt het systeem als einddatum de laatste dag van de maand voor er wordt in dit geval steeds gechecked op de prestaties van de ganse maand - 2: (het systeem vraagt de gewenste einddatum aan de gebruiker), de standaard einddatum die hiant voorstelt wordt bepaald aan de hand van de einddagen per maand. De einddagen per maand worden ingegeven in een parameter ("scherm", "frmvoorschottenlstEinddagen", ), bv. 15, 14, 15, 14, 15, 14, 15, 15, 14, 15, 14, 15 De einddatum wordt dus in dit geval bepaald ahv de einddag voor de betreffende maand binnen de parameter. Indien de parameter niet aanwezig is voor het betreffende jaar of er is geen waarde ingegeven binnen deze parameter voor de betreffende maand, dan wordt standaard 15 genomen als einddag. Werking van de controle op aanwezigheid prestaties bij klaarzetten voor voorschotberekening: - indien de uzk geen planningsgegevens heeft tussen en <einddatum voorschotberekening> de uzk kan niet klaargezet worden voor voorschotberekening. De uzk komt op de controlelijst met melding “deze uzk heeft geen planningsgegevens” - indien de uzk WEL planningsgegevens heeft tussen en <einddatum voorschotberekening> Voor al de verschillende datums uit de planning voor de uzk tussen en <einddatum voorschotberekening> waarop er uren zijn ingegeven (pk_type 110 of 210) dienen er prestaties aanwezig te zijn. Indien dit niet het geval is wordt de uzk niet klaargezet voor voorschotberekening. De uzk komt op de controlelijst met melding “niet alle prestaties zijn aanwezig.” Op het eind van het klaarzetten voor de voorschotten wordt er dus een controlelijst aan de gebruiker getoond waarop alle uzk worden vermeld die niet klaargezet zijn (samen met de reden: “deze uzk heeft geen planningsgegevens” of “niet alle prestaties zijn aanwezig.”).


7/24

1.9.

Aanpassing controle op MC-codes aan het einde van de berekening een loonrun

Er is sinds enige tijd een blokkerende controle aan het eind van de berekening van een loonrun: Als 1) een MC-code mist (bv. 653 en 2001 aanwezig en geen 2002) of 2) de aantallen van de MC-codes komen niet overeen of 3) bruto - WNbijdrage <> netto dan wordt het loon van de betreffende uzk op niet berekend gezet. Men krijgt zo'n loonrun dan ook niet geboekt, omdat niet alle lonen berekend zijn.

Met deze blokkerende controle was er een probleem bij berekenen lonen van een herziening, waarbij originele loon MC had en nieuwe berekening niet: De controle was als volgt: als er MC-codes worden gevonden bij de berekende lonen, dan worden de MC-premies opgehaald en wordt er vervolgens gechecked dat de aantallen van de 3 MC-codes gelijk zijn en dat de MC-rekening klopt. Echter als er bij het originele loon MC waren en bij nieuwe berekening niet, dan zijn er geen MC-premies. De controle is als volgt aangepast: als er bij de berekende lonen MC-codes voorkomen en er worden geen MC-premies gevonden, dan gaan we niet blokkeren ingeval de MC-codes voorkomen bij de tegenboeking, wel ingeval de MC-codes voorkomen bij de nieuwe berekening. Voorlopig is enkel de blokkerende controle bij berekenen lonen aangepast. De melding à la "geen MC-premies gevonden" bij boeken lonen zal voorlopig wel blijven. De lonen worden dan geboekt, maar er zijn geen acties naar de maaltijdcheque-tabel.

1.10. Aanpassing lijstscherm parameters: na toevoegen parameter en verwijderen parameter de lijst van de Hiant-parameters herladen Het lijstscherm met parameters (Gegevens/Instellingen/Beheer/Beheer parameters) is aangepast: na toevoegen parameter en verwijderen parameter wordt de lijst van de Hiantparameters herladen. Waardoor men niet verplicht is zelf nog de lijst van parameters te herladen. Dus, na toevoegen of verwijderen van een parameter in het lijstscherm met parameters, is deze wijziging onmiddellijk merkbaar binnen Hiant.

1.11. Probleem binnen “Gegevens/Zoek/Overige” vanuit werknemerslijstscherm – probleem met aanmaak opvolging indien het volgnr in de lijst decimaal is Binnen “Gegevens/Zoek/Overige” was er een probleem wanneer men een opvolging wilde aanmaken en het volgnr van de lijst was decimaal. Tevoren was er een variabele Lijstnr die van het type integer (geheel getal) was. Echter in de praktijk wordt nu vaak het nummer in de lijst decimaal gemaakt (om ook in de boom op verschillende plaatsen items toe te voegen).


8/24

Het tonen van de lijst van alle zoekcriteria loopt goed, geordend op het decimale lijstnr. Echter de variabele LijstNr bevatte altijd het gehele getal van het lijstnummer. Met als gevolg dat er problemen waren, oa. om de juiste parameter op te halen voor de opvolging bij de betreffende lijst – de parameter die het opvolgingstype ophaalde ging altijd zoeken bij het “gehele getal” voor het volgnr in de lijst: lngOpvolgingID = geefparamwaarde(LijstType, Lijstnr, "FollowUpType", "0") De programmatie is aangepast: variabele heet nu dblLijstNr en is van type Double.

1.12. Probleem bij overhevelen contracten – een recordset.Movenext gaat niet naar de volgende lijn – overhevelen komt hierdoor in een oneindige lus – blijkbaar te maken met manier van openen recordset en met de gebruikte index bij ophalen gegevens; index voor ophalen blijkbaar gewijzigd tgv. jaarovergang Bij een uitzendbedrijf was er het probleem dat bij overhevelen van contracten van week 52 van 2012 naar week 1 van 2013 er een oneindige lus voorkwam. De reden was dat er bij een recordset.Movenext niet naar de volgende lijn werd gegaan. Dit had blijkbaar te maken met een samenloop van zaken: manier van openen recordset en feit dat blijkbaar een andere index voor ophalen gegevens is gebruikt bij overgang van week 52 2012 naar week 1 van 2013. De manier van openen van de recordset is nu aangepast: deze wordt nu adOpenKeyset geopend ipv adOpenDynamic. Zat binnen funktie “SplitsMaandOvergang”.

1.13. Ook probleem bij bewaren contract – een recordset.Movenext gaat niet naar de volgende lijn – bewaren komt hierdoor in een oneindige lus – blijkbaar te maken met manier van openen recordset en met de gebruikte index bij ophalen gegevens; index voor ophalen blijkbaar gewijzigd tgv. jaarovergang Bij een uitzendbedrijf was er het probleem bij het bewaren van een contract van week 1 van 2013 dat er een oneindige lus voorkwam. De reden was dat er bij een recordset.Movenext niet naar de volgende lijn werd gegaan. Dit had blijkbaar te maken met een samenloop van zaken: manier van openen recordset en feit dat blijkbaar een andere index voor ophalen gegevens is gebruikt bij week 1 van 2013. De manier van openen van de recordset is nu aangepast: deze wordt nu adOpenKeyset geopend ipv adOpenDynamic. Zat binnen funktie “SplitsMaandOvergang”, maar binnen een ander blok broncode dan dit gebruikt bij overhevelen. Ook is het openen van de recordset nu aangepast binnen funktie “SplitsHALFMaandOvergang”, zowel binnen het blok gebruikt bij overhevelen als het blok gebruikt bij bewaren contract.


9/24

1.14. Probleem met berekening restbedrag ecocheques (HDPexporters) indien met de totaalwaarde ecocheques ingeeft met gedeelte na de komma; het restbedrag kon in negatief komen Bij de HDP-exporters is het zo dat, als men een premie ecocheques ingeeft, dit resulteert in de aanmaak van 2 premies: één premie met het bedrag van de volledige ecocheques en één premie met het restbedrag. Hierbij was er nog een probleem indien met de totaalwaarde van de ecocheques ingaf met cijfers na de komma (eigenlijk enkel indien de afronding naar een geheel getal naar boven gebeurt). Volgende was het probleem (stel waarde van 1 ecocheque is 10 EUR): - Men had bv. de totaalwaarde ecocheque ingegeven met een decimale waarde 79.5 - berekening van het aantal volledige ecocheques gaf in dit geval 8. Binnen de VB-code is het namelijk zo dat bij berekening van de deling automatisch het deeltal omgezet werd naar een geheel getal (en afronding van 79.5 geeft 80) --> bedrag volledige ecocheques = 8 * 10 = 80 - En de bepaling van de restwaarde is dan als volgt: 79.5 - 80 = -0.5 De programmatie is aangepast binnen beide prestatie-ingaveschermen: - Het ingegeven bedrag wordt eerst omgevormd tot een geheel getal - enkel het gedeelte voor de komma wordt genomen. Dus als 79.5 wordt ingegeven, wordt enkel 79 in rekening gebracht, en dit geeft bijgevolg: - 7 volledige ecocheques van 10 EUR = 70 - restwaarde van 9 EUR

1.15. Ticket 93309 op specifiek klantverzoek loggingmogelijkheid ingebouwd. Vraag : op scherm frmprestgeg2, kan men een voorschot klaar zetten Als je klikt op prestatie voorschot wordt het op OK gezet. Indien je daarna op dezelfde lijn weer gaat staan en nog eens op prestatie voorschot klikt, dan komt het op niet ok. Hier logging rond zetten : Weten wanneer iemand dit verzet Nieuwe parameter : Param1 = frmprestgeg2 Param2 = voorschotstatus Param3 = logging Waarde 0 = geen logging, 1=wel logging Logging type = 113 Wat wordt gelogd param1=vss_id (id van de tabel voorschotstatus, indien aanmaak is, dan staat hier “aanmaak” ,param2=vss_wnnr, param3=vss_jaar, param4=vss_periode, param5=vss_systeem,


10/24

param6=vss_status

1.16. ticket 92822 : extra functionaliteit bij invullen van einddatum bij bestelling gezin. Indien men in een bestelling van een gezin de status bestelling aanpast naar ‘stopgezet gezin’ of ‘stopgezet dienstenchequebedrijf’ en men klikt op bewaar en de einddatum van de bestelling is niet ingevuld dan geeft HiANt de melding : ‘LET OP, einddatum van bestelling moet worden ingevuld’. LET OP : deze einddatum zal zich automatisch dan ook invullen in detail gewenst rooster ‘einddatum’.

nieuwe parameter om dit te activeren param1 = frmbestelgeg param2 =testeneinddatum param3 = * waarde = 1 (1 activeren, anders 0) nieuwe parameter om de statussen te definieren die gelijk staan aan stopzetten om deze waardes te kennen : op code-tabel zoeken naar cd_srt 85 in te vullen (komma-gescheiden- in volgende parameter param1 = CODEBOEKCODE param2 =Bestelling param3=stopzetstatussen

1.17. ticket 93714 specifieke wijziging ivm wijziging einddatum van een gedimoniseerd contract via een parameter voorkomen dat er in een reeds gedimoniseerd contract waarbij men de start- en of stopdatum wijzigt, dit contract niet kan opslaan indien de dag waarop men de wijziging uitvoert meer dan één dag ligt NA de oorspronkelijke einddatum van het contract. Deze beveiliging is parametriseerbaar in te stellen !

nieuwe parameter param1 = contract param2= gedimoniseerd param3 = DatumNietAanpassenNa2Dagen waarde = 1 om te activeren

1.18. ticket 96264 : klantspecifieke aanpassing Export boekhouding (13/12/2012) Nieuwe parameter aangemaakt : Param1 = "Export" Param2 = "KostenPlaats" Param3 = "2009altijdop0" Als deze parameter op 1 staat, dan, zal voor de 2009 steeds de kostenplaats 090 doorgegeven worden


11/24

1.19. Opvolging detail scherm Indien men vanuit de bestelling een opvolging aanmaakt, wordt het veld van de bestellingen (opzoeklijst) gedisabled. De gebruiker kan dus niet van bestelling wijzigen. In dat geval zal men, indien men door velde tabt, de opzoeklijst van de bestelling ook niet meer leeggemaakt worden. Ook indien men een opvolging met een reeds bestaande bestelling open, wordt de bestaande bestelling niet gewist tijdens het tabben tussen de verschillende velden binnen deze opvolging. Ook bij het schakelen tussen al dan niet de bestellingen tonen van de steunkantoren wordt het veld niet gewist.

1.20. Electronische maaltijdcheques : aantal zichtbaar maken in bestelscherm In het bestelscherm wordt er een onderscheid gemaakt in het aantal en totaal bruto bedrag van de nog te bestellen maaltijdcheques. Het gegeven vindt men achter het label : “Nogniet bestelde MC : “


12/24

1.21. Laattijdige aangifte zonder controlecijfer Het is nu ook mogelijk dat gewone consulenten een laattijdige dimonaaangifte kunnen uitvoeren zonder controlecijfer. Hierdoor dient men de parameter ("dimona", "UZC", "LaattijdigZonderControleNr", "0") meet waarde 1 in te geven. Let op : er is geen controle op de ouderdom van het contract. Elke contract kan men dus laattijdig aangeven.

1.22. Ticket 93786 - Barcode contracten en roadsheets De nieuwe afdrukmodule is voorzien om op contracten en roadsheets een barcode te plaatsten. (Nota: Voor gebruik dient dit barcode veld eerst ingebouwd te worden op het sjabloon. Daarnaast moet ook de barcode font aanwezig zijn op de server)

Vanuit het scherm (SHIFT + F4) Menu Acties Inscannen getekende uzk contracten heeft kan met met behulp van een barcode scanner de code inlezen. Hiant controleert eerst de geldigheid van de bacode. Voor barcodes die beginnen met de letter C zal hiant het contract markeren als zijnde getekend. Voor barcodes die beginnen met de letter R zal hiant de Roadsheet markeren als zijnde ontvangen/getekend.


13/24

1.23. Ticket 94293 - specifieke functionaliteit bij het invullen van het emailadres van een UZK KLANTSPECIFIEKE AANPASSING

Parameter "WNcheck", "mail", "loonfiche" Standaard waarde = 0 = UIT Bij waarde 1 = AAN zal Hiant volgende controle uitvoeren. Hiant zal bij het verlaten van het veld Email in de WN fiche controleren of er een email wordt ingegeven of leeggemaakt.

Bij het toevoegen van een email zal hiant ervoor zorgen dat de loonfiches via mail verstuurd worden naar de WN (enkel als dit nog niet gebeurd is en of deze actie nog niet verjaard is) Bij het verwijderen zal hiant controleren of bovenstaande actie ooit werd uitgevoerd en nog actief is. In dat geval krijgt de actie de huidige datum als annulatie en zal de actie niet meer worden uitgevoerd.


14/24

1.24. Ticket 92828 - bij komende controle bij bewaren van HHH-fiche Parameter "frmwngeg1", "Controle", "CatA" (standaard waarde 0 = UIT) Bij het inschakelen van de parameter (waarde op 1 zetten = AAN) zal hiant bij het bewaren van een WN fiche nagaan of het om een WN met CAT A gaat. In dat geval zal hiant nagaan of uitkering RVA is aangevinkt en of er ook een werkloosheids datum is ingevuld.

Als er iets niet voldoet zal hiant bij het bewaren van de fiche de volgende melding aan de gebruiker tonen.


15/24

1.25. Ticket 91564 - specifieke controle bij opslaan van een attest PARAMETER : "frmAttest", "Controle", "AanwezigheidAttest" standaard = 0 Met het activeren van deze parameter (waarde op 1 zetten) zal hiant bij het bewaren van een attest nagaan of voor het nieuwe ingegeven attest een verplicht attest noodzakelijk is VOORDAT men kan bewaren. Deze verplichte attesten kan men als volgt meegeven. PARAM1 = 'VerplichtBijAttest' PARAM2 = Type van het in te geven attest PARAM3 = Detailtype van het in te geven attest (indien niet van toepassing kan men deze blanco laten)

De WAARDE is dan het type van het verplicht attest en het eventuele detailtype (indien er een detailtype is zal deze gescheiden moeten worden met een komma. Gaat men vervolgens een attest bewaren waarmee hiant een parameter terug vindt op basis van het type en eventueel detailtype zal bij een attest dat een verplicht attest nodig heeft de controle uitgevoerd worden. Hierbij wordt ook gekeken naar het attestdatum. Dus de attestdatum van het nieuwe attest moet tussen begin en einddatum van verplicht attest vallen. Indien dat verplicht attest niet aanwezig is bij de kandidaat zal hiant de bewaar procedure afbreken en de gebruiker een melding tonen.

1.26. Klantspecifieke aanpassing mbt Contractbeheer PARAMETER : "Hiant", "Sluiten", "ControleAfdrukContracten" standaard waarde = 0


16/24

Als men de parameter de waarde 1 geeft zal hiant de volgende controle doen als men hiant wilt afsluiten. Als de huidige dag een vrijdag is en het is na 16u30 zal hiant controleren of alle contracten die volgende week beginnen zijn afgedrukt geweest. Indien niet zal hiant de gebruiker informeren.

1.27. AfdrukModule – adres kantoor op contracten PARAMETER : "Afdruk", "Documenten", "kantoorGegevensKlant" PARAMETER : "Afdruk", "Documenten", "kantoorGegevensContract"

Bovenstaande parameters (standaard waard = 0) zorgt bij activatie (waarde = 1) dat op de contracten de kantoor gegevens als volgt getoond worden. 1) Parameter kantoorGegevensKlant = 1 Op de contracten (uzk en klant) worden de kantoor gegevens getoond van het kantoor dat gekoppeld is aan de klant 2) Parameter kantoorGegevensContract = 1 Op de contracten (uzk en klant) worden de kantoor gegevens getoond van het kantoor dat gekoppeld is aan het contract (ALLEEN als de vorige parameter waarde 0 heeft) 3) Als beide parameter de waarde 0 hebben Op de contracten (uzk en klant) worden de kantoor gegevens getoond van het kantoor van het actieve kantoor waarin de hiant gebruiker werkt.

1.28. Ticket 94503 - optie PAW icm prestatiestaat Als men in hiant timesheets gaat afdrukken voor klanten die de optie PAW (Print Adres Werknemer) hebben zal de afdrukmodule eerst controlere of de optie PPU (Prestatieformulier Per Uitzendkracht) aanwezig is bij de betreffende klant. Enkel dan zal op de timesheet het adres van de klant vervangen worden door het adres van de betreffende werknemer.

1.29. Elektronische maaltijdcheques Er is begonnen met voorbereiding voor aanmaak elektronische maaltijdcheques via HiAnt. Tijdens het boeken van de lonen worden ook de eventuele maaltijdcheques geboekt in de tabel maaltijdcheques. Deze tabel is uitgebreid met een aantal velden, zodat er gebruik kan gemaakt worden van een nieuwe module om de maaltijdcheques elektronisch te kunnen bestellen. Noodzakelijke bestanden onder de dll directory (bv. C:\program files\prato\dll) - Iesi.Collections.dll


17/24

-

Newtonsoft.Json.dll NHibernate.dll PFW.HiAnt.DataAccessLayer.dll PFW.HiAnt.DomainLayer.dll PFW.Utilities.dll PFW.WorkB.BusinessLayer.dll PFW.WorkB.DomainLayer.dll PFW.WorkB.FacadeLayer.dll PFW.WorkB.ServiceLayer.dll Services.Interop.dll

Noodzakelijke bestanden onder de applicatie directory Hiant - VouchersOrder_v1-4.xsd Onder applicatie directory HiAnt dient een map bin aangemaakt te worden met daaronder - hiant.cfg.xml Verder dient de dll Serices.Interop.dll geregistreerd te worden via Regasm met framework 4 c:\windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe Services.Interop.dll /codebase /tlb VOORWAARDEN : - Er moet gebruik worden gemaakt van vennootschappen binnen HiAnt. De aanmaak van de elektronische bestanden gebeuren per vennootschap. - Elke actief kantoor (uit wg-tabel) dient gekoppeld te zijn aan een vennootschapid (link naar tabel vennootschap) - Alle personen die een elektronische maaltijdcheque willen ontvangen dienen een geldig sisnummer te hebben in hun fiche - Klanten waarbij de database is opgesplitst in een zogenaamde WISO-db en GLOBALVAR-db dienen over te schakelen naar één Database (uit te voeren door Prato) - Indien toch opsplitsing van databases dient aan de parameter tabel op WISO-niveau een autonummering veld paramid toegevoegd te worden (met primary key). Ook dienen de parameters die aangesproken worden via de nieuwe dll op de parameter tabel op WISO-niveau gedefinieerd te worden en niet op GLOBALVAR-niveau - Framework 4 (client-version) dient geïnstalleerd te zijn Bij aanmaak van het bestelbestand via xml zullen volgende controles uitgevoerd worden : - Controle negatieve aantallen : Indien het totaal aantal te bestellen cheques gegroepeerd per werknemer negatief uitkomt, zal de gebruiker een oplijsting zien van deze personen, en een melding krijgen dat het bestelbestand niet aangemaakt kan worden. - Controle op ingevulde sisnummer: Indien er personen zijn waarvan de sisnummers niet zijn ingevuld, zal de gebruiker een oplijsting zien van deze personen, en een melding krijgen dat het bestelbestand niet aangemaakt kan worden. - Controle vennootschappen : Indien er in de te bestellen maaltijdcheques van de bestelling records gevonden zijn waarvan de vennootschapsid niet is ingevuld, zal de gebruiker een oplijsting zien van deze personen, en een melding krijgen dat het bestelbestand niet aangemaakt kan worden. Parameters

De waarde van deze parameter moet de datum (in formaat YYYY-MM-DD) bevatten vanaf wanneer men elektronische maaltijdcheques wenst te bestellen. De ingestelde datum wordt vergeleken met de boekingsdatum van de lonen. Als er bv. 2013-01-01 is ingevuld, wil dit zeggen dat alle lonen geboekt vanaf 01/01/2013 de eventuele maaltijdcheques elektronisch kunnen besteld worden.


18/24

Indien bovenstaande parameter is ingesteld kan men met volgende parameter bepalen of men elektronische maaltijdcheques wenst te bestellen ENKEL voor dienstencheque-sekties. (standaard is alle sekties).

Stel dat men in één database zowel interim als dienstenchequers heeft zitten, en de vaste werknemers hebben elektronische maaltijdcheques, dan dienen de dienstenchequers de regelgeving van de vaste medewerkers te volgen. Men dient in deze database dus de bovenstaande parameter op 1 in te stellen. Indien de parameter blabla is ingevuld en men dus elektronische mc’s wenst te bestellen, zullen alle werknemers (eventueel enkel de dienstenchequers) elektronische mc’s krijgen. Individueel kan er afgeweken worden naar papieren mc’s d.m.v. een attest. Hiervoor dient men een nieuwe attesttype aan te maken en te parameteriseren via volgende parameter "INITIALISATIE", "MAALTIJDCHEQUES", "ATTESTPAPIER", "-1" De waarde bevat dan de id van het nieuw aangemaakte attest Indien tijdens boeken van lonen (en dus ook eventuele mc’s) het bedrijf staat ingesteld op elektronische mc’s , maar een werknemer heeft een actief attest van dit nieuwe type, dan zal voor deze persoon toch een papieren mc worden besteld.

Bepalen van leverancier elektronische maaltijdcheques : "INITIALISATIE", "MAALTIJDCHEQUES", "ELEKTRONISCHELEVERANCIER", "" Mogelijke waarden : - “ED” : Edenred - “SO” : Sodexo - “MO” : Monizze - “EK” : Ekena (E-ve) Bepalen van leverancier papieren maaltijdcheques (indien voor elektronisch op werkgeverniveau is gekozen, maar individueel wordt afgeweken door middel van een attest) : "INITIALISATIE", "MAALTIJDCHEQUES", "PAPIERENLEVERANCIER", "" Mogelijke waarden : - “ED” : Edenred - “SO” : Sodexo

"VOUCHERSORDER", "CREATEFILE", "XSDFILE", "VouchersOrder_v1-4.xsd" : bepaalt welke xsd moet gebruikt worden om een validatie van het aangemaakte XML bestand uit te voeren. Standaard VouchersOrder_v1-4.xsd. Dit bestand dient aanwezig te zijn op de applicatiedirectory van HiAnt. Indien niet aanwezig, krijgt de gebruiker een melding en kan het bestand niet aangemaakt worden. "initialisatie", "ElectronicOrderFile", "ExportPath" -> bepaalt het exportpad waar het XML bestand wordt aangemaakt. Standaard is dit het ingestelde lokale pad van HiAnt. Indien het ingestelde pad niet gevonden wordt, krijgt de gebruiker een melding en kan het bestand niet aangemaakt worden.


19/24

Parameters mbt afzender van de elektronische maaltijdcheques “VouchersOrder”,”SenderData”,”CompanyID” : bevat ondernemingsnummer van afzender “VouchersOrder”,”SenderData”,”ContactID” : bevat contactid van afzender? “VouchersOrder”,”SenderData”,”Name” : naam van contactpersoon van afzender “VouchersOrder”,”SenderData”,”FirstName” : voornaam van contactpersoon van afzender “VouchersOrder”,”SenderData”,”Language” : taal van contactpersoon van afzender (NL of FR) “VouchersOrder”,”SenderData”,”Email” : email van contactpersoon van afzender “VouchersOrder”,”SenderData”,”Phone” : telefoon van contactpersoon van afzender De bovenstaande parameters in vet gedrukt dienen ingevuld te zijn. Hierop wordt gecontroleerd. Indien niet gevonden kan bestand niet aangemaakt worden "initialisatie", "ElectronicOrderFile", "MailToCurrentUser", "1" -> bepaalt of het aangemaakte bestelbestand moet verstuurd worden naar het email adres dat is ingesteld in de personeelstabel van de gebruiker die de actie uitvoert. Indien email-adres ongeldig of niet ingevuld is, wordt een waarschuwingsmelding getoond aan de gebruiker dat het bestand niet gemaild kan worden. (werkt enkel indien de SMTP parameters correct zijn ingesteld) “CHEQUEEMAIL”,<Supllier>”,”TO” -> bepaalt of er in de tekst van de mail een vermelding moet komen waarnaar het bestand dient verstuurd te worden. Parameter 2 bevat de leverancierscode (bv ED,SO). De waarde is het emailadres. Indien de parameter is gevonden zal dus in de toegestuurde mail naar de gebruiker de volgende tekst extra geprint worden : “Dit moet verstuurd worden naar : ” “CHEQUEEMAIL”,<Supllier>”,”CC” -> bepaalt of er in de tekst van de mail een vermelding moet komen waarnaar het bestand in CC dient verstuurd te worden. Parameter 2 bevat de leverancierscode (bv ED,SO). De waarde is het emailadres. Indien de parameter is gevonden zal dus in de toegestuurde mail naar de gebruiker de volgende tekst extra geprint worden : “met in cc : ” “PRATOMAIL”,”FORMADDRESS”,”*” -> bepaalt de afzender die gebruikt moet worden bij versturen van de mail naar de gebruiker. “PRATOMAIL”,”SMTPSERVER”,”*” -> bepaalt de smtp server die gebruikt moet worden bij versturen van de mail naar de gebruiker. “PRATOMAIL”,”SMTPPORT”,”*” -> bepaalt de smtp poort die gebruikt moet worden bij versturen van de mail naar de gebruiker. (standaard = 25) “cheques”,”nocontractnummer”,<supplier> -> bepaalt of ingeval van papieren mcs of het contractnummer moet geschreven worden in de CostCenter in xml bestand. Standaard wordt contractnummer wel geschreven in element CostCenter van xml bestand, indien het gaat om een papieren mc. “maaltijdcheques”,”contractnr”,”*” -> bepaalt het contractnummer dat gebruikt wordt bij opvullen van element CostCenter in xml bestand indien het gaat om papieren mcs. “maaltijdcheques”,”extraadres”,”sodexho” -> bepaalt adrestypeid voor gebruik van afwijkend afleveradres in geval van papieren mcs. (reeds bestaande parameter)

1.30. Mogelijkheid tot veranderen van wgnr van bestelling bij bepaalde statussen (Klantspecifiek) Mogelijkheid is ingebouwd dat men de werkgever (kantoornr) van een bestelling kan aanpassen.


20/24

In de bestellingentabel wordt een nieuw veld bes_WgnrOrig toegevoegd. Dit veld wordt bij aanmaak van een nieuwe bestelling gelijk gezet aan het kantoornr (wgnr). Zo kan men zien wat de originele werkgevernummer was bij aanmaak van bestelling. Dit is mogelijk via menu Acties – verander werkgever. Menu is op te zetten met changecontrols parameter “changecontrols”,”frmbestelgeg”,”mnuVeranderWerkgever.visbile”,”1” Men kan de wgnr van de bestelling enkel veranderen indien deze een bepaalde status heeft. De mogelijke statussen dient men te parameteriseren (meerdere statusids gescheiden door een komma) "Scherm", "frmBestelGeg", "StatussenVeranderWgnr", "" Indien bovenstaande parameter niet is ingevuld, zal men wgnr niet kunnen wijzigen. Indien status van bestelling voorkomt in opsomming (in bovenstaande parameter), vraagt HiAnt het nieuwe kantoornummer. Na ingave wordt gecontroleerd of dit een bestaand kantoor is. Indien succesvol gewijzigd wordt dit gelogged in de logtable met type 114. Ook is het mogelijk om bij het uitvoeren van deze actie, een opvolging aan te maken. Hiervoor dient men de volgende parameter aan te maken. "codeboekcode", "OpvolgingsTypeId", "BestellingVeranderWG", "-1". De waarde bevat dan het nieuw aangemaakte opvolgingstype id. De opvolging heeft als opvolgingsdatum de systeemdatum + 1. Indien de systeemdatum + 1 in het weekend (za of zo) valt, wordt als opvolgingsdatum de maandag na het weekend genomen. De opvolging hangt aan de bestelling en aan de klant van deze bestelling. Het contacttype staat op 1 – Algemeen

1.31. Bestellingen detailscherm – nieuw veld Datum klaar (Klantspecifiek) Mogelijkheid om een nieuw invulveld zichtbaar te maken in detailscherm van een bestelling. Zichtbaar te maken met changecontrols parameter “Scherm”,”frmbestelgeg”,”datgeg(1).visible”,”1” “Scherm”,”frmbestelgeg”,”label6(0).visible”,”1” Mogelijkheid tot automatisch opvullen van deze datum, indien er in een bestaande bestelling naar een bepaalde status wordt verwisseld. De mogelijke statussen dienen met volgende parameter ingesteld worden (meerdere statusIds gescheiden door een komma) "scherm", "frmbestelgeg", "statussenPasDatumKlaarAan", "-1" Indien de status wordt veranderd naar een status opgesomd in bovenstaande parameter en de datum klaar is nog niet ingevuld, dan wordt de datum klaar ingesteld op de systeemdatum.

1.32. Contracten detailscherm – mogelijkheid tot koppelen aan bestelling (Klantspecifiek) Mogelijkheid is voorzien om een contract te kunnen koppelen aan een bestelling. Hiervoor dient onderstaande parameter op 1 worden ingesteld "INITIALISATIE", "Contractenscherm", "ToonBestelling", "0" Indien bovenstaande parameter op 1 is ingesteld krijgt men op tabblad algemeen de mogelijkheid om een bestelling op te zoeken via een lookupbox. Release Notes Hi-Ant Versie 6.041

21/24

Men kan hier een bestelling opzoeken die gekoppeld is aan de klant van het contract en die actief is op de begindatum van het contract. (bes_startdatum en bes_eindedatum). Wanneer de klant in het contract verandert, wordt de koppeling naar bestelling leeggemaakt. Men kan de koppeling naar de bestelling ook leegmaken door op het rode kruisje vooraan deze lookupbox te klikken, en vervolgens het contract te bewaren. Ook indien bovenstaande parameter op 1 is ingesteld, kan men naar de eventueel gekoppelde bestelling gaan, door het menu “Bestelling” bovenaan het scherm te klikken. Men gaat dan in het detail scherm van de gekoppelde bestelling.

1.33. Tarificatie maaltijdcheques nieuwe berekeningsmode (Klantspecifiek) Er is een nieuwe berekeningsmethode ontwikkeld voor toekennen van maaltijdcheques. Dit zal enkel mogelijk zijn bij weekverloners (5301). Door de parameter "INITIALISATIE", "TARIFICATIE", "CHEQUESPERBLOKHERREKENINGMAAND", "0" op 1 in te stellen zal men in het scherm van tarificatie bij maaltijdcheques een nieuw type kunnen selecteren met omschrijving "INITIALISATIE", "CHEQUESPERBLOKHERREKENINGMAAND", "AFRONDINGNAARBOVEN", "0" – bepaalt of er afgerond wordt naar boven (waarde met 1 in stellen), standaard naar onder. Cheques toewijzen per week met herrekening op maandbasis per blok van : Per wekelijkse prestatie-ingave (in het week- of maandingavescherm) zal er een toekenning van maaltijdcheques gebeuren op basis van het totaal reeds gepresteerde uren van deze kalendermaand. Detailberekening 1) Voor de maand van de prestatiedagen… (In 1 prestatieweek kunnen 2 maanden zitten. In dit geval zal Hiant de berekening doen per maand!!) 2) …Controleert Hiant of er reeds prestaties zijn met een status hoger of gelijk aan “-1”, ongeacht of het weeknummer groter of kleiner is dan deze van de huidige week (dus vroeger of later) 3) Indien er geen andere prestaties zijn, houdt Hiant enkel rekening met de huidige prestatieweek om het aantal maaltijdcheques te berekenen: men neemt het totaal aantal uren (van de codes die recht geven op een maaltijdcheque) / 7.6 indien het resultaat cijfers na de komma heeft, rondt men steeds naar beneden af om een geheel getal te bekomen (voorbeeld : 5.86 wordt 5) Indien het resultaat geen cijfers na de komma heeft, is dit het geheel getal dit is vervolgens het aantal maaltijdcheques dat toegekend mag worden voor deze prestatieweek 4) Indien er toch andere prestaties zouden zijn (zie voorwaarde in punt 2), houdt Hiant wel rekening met deze prestaties: men neemt het totaal aantal uren van ALLE prestatieweken (van de codes die recht geven op een maaltijdcheque) / 7.6 indien het resultaat cijfers na de komma heeft, rondt men steeds naar beneden af om een geheel getal te bekomen


22/24

Indien het resultaat geen cijfers na de komma heeft, is dit het geheel getal dit is vervolgens het aantal maaltijdcheques waarop de dienstenchequer recht heeft voor de gehele periode (tot nu toe) Dit is NIET het aantal maaltijdcheques wat er in deze prestatieweek toegekend wordt! neem de som van het aantal maaltijdcheques dat toegekend zijn in de andere prestatieweken (dus exclusief de huidige prestatieweek) aantal maaltijdcheques toe te kennen in de huidige prestatieweek is het verschil tussen : “het aantal maaltijdcheques waarop de dienstenchequer recht heeft voor de gehele periode” MINUS “de som van het aantal maaltijdcheques dat toegekend zijn in de andere prestatieweken (dus excusief de huidige prestatieweek)”

1.34. Automatisch inboeken van Margelijst via Scheduled Task De broncode voor het opvullen van de margelijst tabellen is verplaatst van HiAnt naar AutoTask. Hierdoor wordt het mogelijk om de margelijsten automatisch te laten berekenen via een Scheduled Task. Om te zorgen dat de periode waarvoor de tabellen worden opgevuld dynamisch wordt werden er twee parameters voorzien waarmee men een interval gedefinieerd kan worden om de einddatum te berekenen. Param1

Param2

Param3

Default

Omschrijving

margelijst

autoinboeken

interval.type

d

Geeft het type van het interval aan: • •

margelijst

autoinboeken

interval.aantal

0

d: dagen m: maanden

Om het aantal dagen/maanden in te stellen dat in mindering gebracht moet worden van de huidige datum om de einddatum te berekenen.

Indien het type interval in dagen (d) is wordt het ingestelde aantal dagen in mindering gebracht van de huidige datum. Aan de hand van de datum die je dan krijgt wordt de datum van de zondag in die week bepaalt. Als begindatum wordt steeds 1 januari genomen van het jaar van de berekende einddatum. vb. interval.type = d, aantal = 14, berekeningsdag = 13/12/2012 Datum – 14 dagen = 29/11/2012 Zondag in die week = 02/12/2012 Indien het type interval in maanden (m) is wordt het ingestelde aantal maanden in mindering gebracht van de huidige datum. Dan wordt voor de bekomen maand de laatste dag genomen als einddatum. vb. interval type = m, aantal = 2, berekeningsdag = 13/12/2012 Datum – 2 maanden = 13/10/2012 Einddatum maand = 31/10/2012 Om de margelijst automatisch via AutoTask te draaien, rekening houdend met voorgaande parameters, dient men de volgende parameters mee te geven: UIC: MARGELIJST (VASTE WAARDE) INI: De volledige bestandsnaam inclusief path van de ini file die gebruikt moet worden. vb. d:\autotask\wisotest.ini FACTURENTRANSACTIE: Waarde geeft aan of de facturen in transactie meegenomen moeten worden of niet. • 0: niet meenemen • 1: meenemen vb. commando autotask.exe §UIC§MARGELIJST§INI§d:\autotask\wisotest.ini§FACTURENTRANSACTIE§0


23/24


24/24

21

Recommend Documents