16

Release Notes Afdrukdatum: 2010/12/16

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 5.35

1/32

1.

V5.35 1.1. -

-

Bugfix

Dimonafoutenlijst scherm : indien er slechts één rij te zien is, en je wenst dit op afgehandeld te plaatsen, diende je extra op het zwarte floppy icoontje geklikt te worden om deze wijziging op te slaan. Aanpassing is gebeurd zodat de eventuele openstaande wijzigingen worden bewaard bij het sluiten van het scherm. Indien parameter "frmcontgeg", "Bewaar", "controleHerverdeling", "0" op 1 staat en je bewaart contract, controleert HiAnt of het geselecteerde omzetkantoor van de klant gelijk is aan dat van het contract, en indien dit zo is, kan men contract niet bewaren. Bij de controle zat iets fout waardoor dit niet werkte. Veld was een zgn “boolean” veld, en in code werd gecontroleerd of dit de waarde “1” bevatte.

1.2.

Database aanpassingen: Aanpassingen in Database structuur: Ticket 59626: Contactpersoon boekhouding van klant kunnen exporteren naar multivers

Nieuw veld ‘boekhouderjn’ (bit) toegevoegd (via ‘McheckDatabase.CheckDatabase_Hiant’) aan tabel ‘ContactPersonen‘.

1.3.

Database aanpassingen: Aanpassingen in Database structuur: Ticket 49351: Aantal personen ten laste +65 andersvalide

Nieuw veld ‘fisplus65Inv’ (int) toegevoegd (via mCheckDatabase.CheckDatabase_Hiant3) aan tabel ‘wn’.

1.4.

Ticket 58131: Defaultvalue instellen voor lookupbox gepensioneerd in contractendetail scherm

Via volgende parameter kan de standaardwaarde worden ingesteld voor bv. de lookupbox gepensioneerd op het contractendetail scherm. Param1 Param2 Param3 Waarde changecontrols frmcontgeg Lubgeg(14).defaultvalue Vb. N Deze waarde werd dan ook ingesteld maar zodra er een werknemer gekozen of veranderd werd, werd deze waarde op leeg gezet. De code is nu aangepast zodat als het veld werknemer verandert, de waarde van deze lookupbox terug naar de standaardwaarde gereset wordt. Ook de andere lookupboxen die veranderen na keuze van de werknemer, worden nu op de standaard waarde ingesteld. Technisch: In ‘frmcontgeg’ in het event ‘Lubgeg_FieldChanged’ is de code aangepast zodat overal:

1.5.

Ticket 56136: Blokkeren ECW-code in prestatie-ingave (maand en week)

Als de ECW-aanvraag via het programma EuroEcw gaat (AHS en ASAP wgnr 122), wordt er automatisch een attest aangemaakt met een via parameters instelbaar type en detailtype. Ook indien er vanuit hiant een C32A controlekaart wordt afgeprint, wordt dit attest aangemaakt. Param1 Param2 Param3 Waarde Attest C32AAfdruk DetIdUitkering 2 Dit is de cd van het attest type


2/32

Attest

C32AAfdruk

Typeid

20

Dit is de cd van het attest detailtype

Dit wil zeggen dat voor iedereen voor wie een controlekaart is afgeprint, er ook een attest bestaat in Hiant. Het is dan ook aan de hand van dit attest dat we kunnen controleren of er ECW aan de prestaties mag worden toegevoegd. Deze controle kan worden ingeschakeld met volgende parameter: Param1 Param2 Param3 Waarde Scherm frmcontgeg ControleECW 0: controle staat uit, standaard waarde 1: controle staat aan Indien er ECW wordt toegevoegd, wordt er gecontroleerd of er een attest bestaat van het geparameteriseerde type en detailtype op de dag waarop de ECW wordt ingegeven. Indien dit niet het geval is, verschijnt er een foutmelding en kan de code niet worden toegevoegd. Technisch: Volgende code toegevoegd aan ‘frmprestgeg1.VoegToe’. Volgende code toegevoegd aan ‘frmprestgeg2.ControleerInput’.

1.6.

Ticket 55973: Automatische opvolging bij afdruk inlichtingenblad uitkeringen

Als het inlichtingsblad uitkeringen wordt aangemaakt, wordt er nu een automatische opvolging aangemaakt. Om dit te activeren moet volgende parameter worden aangemaakt: Param1 Param2 Param3 Waarde Codeboekcode OpvolgingsType AfdrukInlichtingenBlad , Waarde: , als er geen detailtype moet worden opgeslaan wordt er enkel ingevuld zonder komma De volgende gegevens worden bij de opvolging ingevuld te worden : • contacttypeid (inhoud van de globale variabele gOpvolgContactTypeAuto) • koppelid (koppelid van de werknemer) • opvolgingtypeid (code uit de ‘parameter’ tabel waarde voor de komma) • opvlogingdetailtypeid (code uit de ‘parameter’ tabel waarde na de komma) • internecontactid (id van de actieve uitzendconsulent) • datumingave (actieve datum) • datumopvolging (actieve datum) • omschrijving (de caption van het menu-item) • afgehandeld (1) • wgnr (actief kantoor) Technisch: Code toegevoegd aan ‘FrmInlichtingsBlad.CmdOK_Click’ na het openen van het document.

1.7.

Ticket 54377: Inlichtingsblad mutualiteit: Ziekte – AD –Ziekte

Als iemand in zijn prestaties tijdens een periode van ziekte een dag AD had, werd deze dag in de ziekteperiode meegenomen in het rooster op het inlichtingenblad. De code is nu aangepast zodat de ziekte periode in bovenstaand geval op 2 rijen wordt ste de weergegeven in het rooster. De 1 rij is de ziekte-periode voor de dag AD en de 2 rij is de ziekteperiode na de dag AD. De dag AD zelf wordt niet vermeld.


3/32

Technisch: Code aangepast in ‘FrmInlichtingsBlad.CmdOk_Click’:

1.8.

Ticket 54090: Wervingskanaal in wn-fiche moet numeriek zijn: controle inbouwen

Wervingskanaal wordt weergegeven in een opzoeklijst. De keuze-mogelijkheden zitten in cd_srt = 42. Hier is het mogelijk om een alfanumerieke code te gebruiken. Het veld wervingskanaal in de database is numeriek. Als er een alfanumerieke code gekozen wordt in de opzoeklijst, krijg je geen fout bij het bewaren maar de waarde wordt niet bewaard in de db. De programmatie is nu aangepast. Bij het verlaten van het veld wervingskanaal wordt er gecontroleerd of de gekozen waarde numeriek is. Indien dit niet het geval is, wordt er een boodschap getoond. Ook bij het bewaren van de fiche wordt deze controle gedaan. Er kan niet bewaard worden zolang de code alfanumeriek is. Technisch: Code aangepast in ‘MwnGeg.BewaarWN1’: Code aangepast in ‘MwnGeg.JumpoutLubgeg2’:

1.9.

Ticket 58779: Fout bij bezoekrapporten

Als er in het menu gekozen wordt voor print > Overzicht per dag, krijg je een foutmelding. Het probleem is opgelost. Technisch: Er werd een veld in de recordset aangesproken dat niet meer met de query werd opgehaald. Code aangepast in ‘frmBezRapLst.ExportDB' rs!initialen = Rs1!initialen

vervangen door: rs!initialen = Rs1!internecontacten

1.10. Ticket 58836: Dimona-aangifte lukt niet De dimona aangifte voor een bepaalde persoon was niet gebeurd. Ook een laattijdige aangifte lukte niet. Dit gaf een foutmelding. Het probleem lag aan het siskaartnummer. In de code werd er een spatie voor gezet en deze waarde werd dan naar een numeriek veld geschreven. De code is nu aangepast. Er is een trim toegevoegd. Technisch: Trim toegevoegd in 'ModDimona.MaakDimonaTussenBestand':

1.11. Ticket 59432: Foutmelding bij verloning feestdag Het is niet mogelijk om op een bepaalde dag meerdere keren een F-code in te boeken. Huishoudhulpen werken vb. in de voormiddag voor 1 bepaald gezin en in de namiddag voor een ander. Dit is bij dezelfde klant op verschillende afdelingen. Hiant laat niet toe om 2 keer dezelfde F-code te gebruiken. De programmatie is nu aangepast zodat een bepaalde F-code op een bepaalde dag meer dan 1 maal kan gebruikt worden. Technisch: Code aangepast in ‘Mwisonet.AllowHolidayInput’.


4/32

1.12. Ticket 59387: Foutmelding in klantenfiche DC Waneer parameter "Scherm", "Frmklgeg1", "ControleerVakbond" geactiveerd is, krijg je een melding als er in de opties geen van de codes ‘SYND’ en ‘GVA’ voorkomt en kan je niet bewaren. Bij gezinnen is de opties-balk niet zichtbaar, het is dus niet mogelijk om ‘SYND’ of ‘GVA’ in te vullen. Dit is nu aangepast. Er is een nieuwe parameter aangemaakt waarin kan worden aangegeven voor welke firma-codes de controle NIET moet gebeuren. Standaard heeft deze parameter de waarde ‘G’ Param1 Scherm

Param2 Param3 Frmklgeg1 FirmaTypesGeenVakbond

Waarde Een opsomming van firma-codes Vb ‘G’, ‘L’, ‘S’ Standaardwaarde: ‘G’

Technisch: De code is aangepast in ‘frmklgeg1.ControleerVelden’:

1.13. Ticket 50287: Veld ondernemingsnummer toevoegen klantenlijst en filtervelden Veld ondernemingsnummer is toegevoegd aan de lijstschermen ‘klanten + prospecten’ en ‘klanten’. Ook aan de filtervelden is dit veld toegevoegd. Technisch: in ‘frmkllst’ en ‘frmkllst1’ zijn er op verschillende plaatsen volgende properties van brwgeg aangepast: • NumberOfSearchFields: 5 ipv 4 • SearchLabels: “OndernemingsNr” achteraan toegevoegd • SearchFieldNames: “OndernemingsNr” achteraan toegevoegd • SearchFieldTypes: 1 achteraan toegevoegd • SearchInitValues: “” achteraan toegevoegd • LookUpSQLStrings: “” achteraan toegevoegd • selectstring: “kl.ondernemingsnr” als laatste veld van de select toegevoegd • ColumnHeadings: “Ondernemingsnr” achteraan toegevoegd • ColumnWidths: 15 achteraan toegevoegd

1.14. Ticket 59509: Het veld personeelid in de tabel bezoekrapport moet worden opgevuld met de id van de ingever Het veld personeelid in de tabel bezoekrapport wordt niet ingevuld. Software aangepast zodat de id van de ingever terug wordt ingevuld. Technisch: In ‘frmBezRapGeg’ is er een nieuw veld ‘dtbpersoneelid’ aangemaakt om de id van de ingever bij te houden. Dit veld is enkel voor programmeurs zichtbaar. Bij het bewaren van een bezoekrapport wordt er gecontroleerd of dit veld al is ingevuld. Indien niet, wordt de id van de aangemelde persoon weggeschreven naar dit nieuwe veld en hierdoor ook bewaard in de database.

1.15. Ticket 59626: Contactpersoon boekhouding van klant kunnen exporteren naar multivers In de export van de klanten is de mogelijkheid toegevoegd om gegevens van de contactpersoon te exporteren naar multivers. Dit kan geactiveerd worden door de volgende parameter op 1 te plaatsen:


5/32

Param1 Export

Param2 mtv

Param3 gebruikboekhouder

Waarde 0: oude werking, persoon uit klantenfiche, standaard waarde 1: persoon in contacten aangeduid als boekhouder

Het systeem zoekt dan op of er in de klantenfiche een contactpersoon is aangeduid als boekhouder. Indien dit het geval is zal het geslacht, (M of V), naam, voornaam en het email adres van deze boekhouder doorgestuurd worden.

Indien er bij die klant geen boekhouder wordt gevonden, zal het standaard geslacht M worden doorgegevens, alsook een tekst uit de vertaaltabel met code MTVboekhouder. Als er geen boekhouder wordt gevonden, wordt er een - teken als email adres doorgegeven. Technisch: Wijzigingen in ‘frmExport.ExportClientsToMTV’: Wijzigingen in ‘frmcontPersGeg’: Nieuwe checkbox toegevoegd om aan te geven of een contact boekhouder is of niet. Wijzigingen in ‘McheckDatabase.CheckDatabase_Hiant’: Nieuw veld ‘boekhouderjn’ (bit) toegevoegd aan tabel ‘ContactPersonen‘.

1.16. Ticket 57208: de zoekvelden van het planningoverzicht mogen niet worden overgenomen bij het openen van een nieuw overzicht Als er een nieuw planningoverzicht wordt geopend via menu Bestand > Nieuw Overzicht, worden de zoekvelden al ingevuld met de waardes die in het reeds openstaande scherm stonden. Dit is nu geparameteriseerd door onderstaande parameter Param1 scherm


Param2 frmplankalender

Param3 ZoekveldenOver nemenBijNieuw

Waarde 0: de zoekvelden worden niet overgenomen 1: oude werking: de zoekvelden worden

6/32

overgenomen, standaard waarde Technisch: In ‘frmPlanKalender.mnuNieuw_Click’ is de parameter toegevoegd.

1.17. Ticket 59511: In frmSearch 3 nieuwe menu’s toevoegen die op dezelfde manier werken als het menu ‘overige’. Er zijn 3 nieuwe menu’s toegevoegd: Control naam Weergave Param1 mnuOverige1 Overige 1 List1 mnuOverige2 Overige 2 List2 mnuOverige3 Overige 3 List3 Deze menu’s zijn enkel zichtbaar indien er in de parameter-tabel een parameter voorkomt met param1 = <waarde uit tabel hierboven> en param3 = ‘MENUCAPTION’ en param2 > 2. Deze 3 menu-items werken op de zelfde manier als het menu-item ‘Overige’. Meer info over het aanmaken van lijsten onder het menu ‘Overige’, is terug te vinden in de globale releasenotes onder de punten: 24.4 (Eenvoudigere zoekmodule), 49.13 (Toevoegen opvolgingen), 49.14 (Toegang tot snelle info) en 111.26 (Module SMS Mogelijkheid tot verzenden sms binnen nieuwe zoeklijst). Technisch: Code gewijzigd in ‘frmSearch’. Nieuwe property aangemaakt waarin het type van de lijst wordt bijgehouden. Deze property wordt opgevuld bij het klikken op het submenu van Overige, Overige1, Overige2 en Overige 3 met de respectievelijke waardes ‘LIST’, ‘LIST1’, ‘LIST2’ of ‘LIST3’. De Functie ‘BuildMenu’ is aangepast zodat ook de nieuwe menu’s worden getoond. De functionaliteit die zich in ‘SubMenu_Click’ bevond is verhuisd naar de procedure ‘LoadList’ die nu ook wordt opgeroepen in de click-events van de nieuwe menu’s. Overal in ‘frmSearch’ waar de vaste waarde ‘List’ gebruikt werd, is deze vervangen door de property LijstType.

1.18. Ticket 59902: De vertaling van de boodschappen bij klantoptie ‘BGGZ’ vertaalbaar maken via VertaalUZB-tabel De meldingen die gegeven worden als bij de klant optie ‘BGGZ’ is ingesteld waren niet wijzigbaar door de Hiant-gebruikers. De meldingen zijn nu opgenomen in de Vertaal tabel en kunnen dus een andere omschrijving gegeven worden via de vertaalUZB tabel. De begrippen ‘{AantalMaandenBewijs}’ en ‘{AantalMaandenKlant}’ in de vertalingen van ‘CONTVervallenBGGZ’ worden vervangen door het juiste aantal maanden bij het uitvoeren van Hiant. Code CONTGeenBGGZ

Nederlands Deze klant wenst een Bewijs van Goed gedrag en zeden! Wilt U verder gaan?

CONTVervallenBGGZ

Het Bewijs van Goed gedrag en zeden voor deze uzk is


Frans Ce client souhaitera avoir un certificat de bonne vie et moers! Voulez-vous continuer? Le certificat de bonne vie et moers de l'intérimaire a

7/32

{AantalMaandenBewijs} maanden oud. De klant aanvaardt maximum {AantalMaandenKlant} maanden oude BGGZ! Wilt U verder gaan?

{AantalMaandenBewijs} mois. Le client accepte certificat de bonne vie et moers de {AantalMandenKlant} mois! Voulez-vous continuer?

Technisch: Code gewijzigd in ‘frmContGeg.ControleerVelden’

1.19. Ticket 59984: Bug in concurrentielijst Als er een alfanumerieke postcode is bewaard in een klantenfiche, geeft dit problemen in de concurrentielijst. Deze bug is nu gefixt. Technisch: Code aangepast in ‘frmMailLst.ConcurrentieOverzicht’. In de query’s is ‘str(kl.postnr)’ vervangen door ‘cast(kl.postnr as varchar)’. Str gaat blijkbaar eerst converteren naar een float om er daarna een varchar van te maken. Dit loopt uiteraard fout indien postnr alfanumeriek is.

1.20. Ticket 59984: foutmelding in klantenfiche Bij een buitenlandse klant, kan je niets selecteren in de gemeente opzoeklijst. Je moet dan in dit veld de postcode ingeven. Deze moet numeriek zijn, anders krijg je een foutmelding indien je later te klantenfiche wil openen. Het alfanumerieke stuk van de postcode, moet je in het veld naast de opzoeklijst voor de gemeentenaam typen. Er is nu een controle ingebouwd zodat het niet meer mogelijk is om alfanumerieke waardes in het postcode veld te bewaren. Technisch: In ‘frmklgeg1.cmdbewaar_Click’ is een controle toegevoegd.

1.21. Ticket 59831: BestelId verdwijnt uit opvolging bij het aanpassen van de aanbiedingsdatum Als men na het aanpassen van de aanbiedingsdatum (via de knop ‘Pas aanbiedingsdatum aan’) op de bewaarknop drukte in het opvolgings-scherm, verdween de bestelid uit de opvolging. Dit probleem is nu opgelost. Technisch: Bij het aanpassen van de aanbiedingsdatum gebeurt er een InitiFormWN1. Hierin wordt LoadLookupFieldsWN1 opgeroepen waarin gFirmaId op 0 gezet wordt. Hierdoor wordt in de SaveData de Bestelid op 0 gezet. Code toegevoegd in ‘FrmWnOpvolging.cmdAanbiedingsdatum_Click’, na het uitvoeren van InitFormWN1 wordt volgende code uitgevoerd om de gFirmaId terug te vullen.

1.22. Ticket 49351: Aantal personen ten laste +65 andersvalide Nieuw veld aanmaken in het werknemerdetail-scherm. Dit veld in onzichtbaar maar kan zichtbaar gemaakt worden door de ‘changecontrols’.


8/32

Veldnaam Omschrijving lbl(67) De omschrijving van het veld ‘Inv +65 :’ dtbgeg(43) Het invulveld. Technisch: In ‘mCheckDatabase.CheckDatabase_Hiant3’ is code toegevoegd om het veld aan te maken in de database.

1.23. ECOCHEQUES via XLS (ticket 59541) Nieuwe parameter om menu Ecocheques via EXCEL zichtbaar te maken Param1 = changecontrols Param2 = frmloonber Param3 = mnuActie(18).visible Waarde = 1 Nieuwe parameter om menu Ecocheques Genereer BijlageFactuur zichtbaar te maken Param1 = changecontrols Param2 = frmloonber Param3 = mnuActie(19).visible Waarde = 1

1.23.1. Aanleveren van gegevens De gegevens voor het inboeken van de eco cheques worden aangeboden in een Excel met de volgende structuur (één sheet) : De eerste rij bevat de volgende kolomhoofdingen : • Klnr • Klnaam • Wnnr • Wnnaam • Bedrag De volgende rijen bevatten de gegevens. Elke Excel mag enkel de gegevens van één enkele klant bevatten. Het stopt automatisch aan de rij waarbij geen klantnummer is ingevuld of waarbij de klantnummer gelijk is aan nul. De naam van de Excel is eco.xls waarbij het nummer van de in te lezen klant bevat.

1.23.2. Procedure De procedure wordt opgestart vanuit het loonberekeningsschem. Na het opstarten van de procedure vraagt Hiant naar de volgende gegevens : • Klantnummer : aan de hand van dit nummer zal hiant dus ook automatisch het bestand opzoeken in de wisolok directory • Jaar : de gegevens zullen in de lonen en contracten van het opgegeven jaar geboekt worden • Factuurcode : deze numerische code wordt als negative waarde bewaard bij de in te boeken premies en dient uniek te zijn in het systeem. Aan de hand van deze code kan er een overzichtslijst aangemaakt worden, met de gegevens die hiant in de premies heeft ingeboekt en die als bijlage bij de factuur kan gevoegd worden. Hiant controleert of de negatieve waarde van de code reeds bij de premies wordt gevonden. Indien dit het geval is, stopt de procedure. Nadat deze gegevens ingegeven zijn start de procedure. Hiant voert per lijn de volgende gegevens uit : • Opzoeken van het eerste contract van deze werknemer bij deze klant


9/32

•

•

•

Controleer of er op dit eerste contract reeds een eco cheque werd toegevoegd. Indien dit het geval is stopt de procedure. Dit om te vermijden dat een bepaald bedrag tweemaal door hiant aan dit contract zou toegevoegd worden. Controleer of dit contract gekoppeld is aan een loon met status 0. Indien dit niet het geval is, zoeken we een volgend contract. Indien er geen contract gevonden wordt stopt de procedure voor deze lijn en dit wordt gerapporteerd op het einde van de routine.. (Er worden geen ecocheques toegevoegd aan contracten die nog niet verloond zijn of aan contracten die gekoppeld zijn aan geannuleerde lonen. Indien deze controles slagen start het eigenlijk inboeken van de gegevens : § Er wordt een premie ingeboekt met de volgende gegevens : • Jaar is gelijk aan het ingegeven jaar • Contract is het eerste contract van de uitzendkracht bij de klant in het opgegeven jaar • Datum is gelijk aan de begindatum van dit eerste contract • De kode is de code van de eco cheque, namelijk 2801 • Aantal is 1 • Bedrag is het bedrag dat we terug vinden in de Excel • De premie wordt ook gekoppeld aan het gevonden loon met status 0 • Facturatieid wordt gelijk gesteld aan de negatieve waarde van de ingegeven code • Er wordt geen afdeling, kostenplaats of ploegcode ingegeven • De premies wordt ook gekoppeld aan de loonrunnr van het gevonden loon • De premie wordt ingegeven als een manuele premie • (de overige gegevens in de premie tabel worden niet ingevuld) § Er wordt een loondetail record gekoppeld aan het gevonden loon met status 0. De volgende gegevens worden in deze record ingegeven : • Loonid : id van het gevonden loon • Rekkode (wordt opgehaald via parameter : "EcoCheque", "Looncode", "*", 2801) • Aantal =1 • De waarde is de waarde van de totale cheque • Klnr : nummer van de klant • Ddatum :begindatum van het contract • Wgnr = kantoor van het contract • Prestid = contract identificatie • Oldloonid : bevat de negatieve waarde van de factuurcode • (de overige gegevens worden niet ingevuld § Ecocheques inboek voor de bestelling • Het inboeken van de ecocheques voor de bestelling zal op dezelfde manier gebeuren alsof deze zouden ingeboekt zijn bij het boeken van het oorspronkelijke loon waaraan ze nu gekoppeld zijn. Dit betekent oa : o Er wordt rekening gehouden met het afhaalkantoor o Er wordt rekening gehouden met de loonrunnr waaraan het loon gekoppeld is o De omschrijving van de loonrun wordt ook overgehaald naar het bestellingsbestand. o De adres gegevens van de persoon zoals ze nu in de fiche ingegeven zijn worden overgehaald naar het bestelbestand.


10/32

•

Er wordt een overzicht getoond van de cheques die niet ingeboekt kunnen worden, omwille van het feit dat er reeds een ecocheque was ingegeven voor deze werknemer bij deze klant.

1.23.3.Aanmaken bijlage bij factuur Aan de hand van de negatieve code kan er een Excel aangemaakt worden die u al de gegevens toont die hiant bij de premies heeft ingeboekt en die u als bijlage bij de factuur kan toevoegen. Deze gegevens bevat de waarden van de ingeboekte gegevens zonder toepassing van een eventuele coëfficiënt.

1.23.4.Opmerkingen Er wordt geen procedure voorzien om een import terug ongedaan te maken. Het zal echter wel mogelijk zijn om : • De premies en loond records te verwijderen mbv de negatieve factuurcode • De ingeboekte gegevens in de bestelbestand kunnen niet aan de hand van deze code verwijderd worden. Aanpassingen in FRMLOONBER, 2 nieuwe menu-Items

1.24. Margelijsten Hiant -> DMFA kortingen Nieuwe tabel aanmaken Trszdetailklant, met de kortingen in opgesplitst per klant Nieuiwe parameter met de dmfa-codes die uitgesloten moeten worden (codes 0001 en 601) Karl heeft nieuwe index aangemaakt op de wiso100 op de loon of loond tabel? Nieuwe tabel is CREATE TABLE [dbo].[TRSZDetailKlant](

De code staat in de autotask. Als opvullen van de tabel voltooid is -> mail naar gebruiker Aanpassing in hiant, nieuw menu (huidige Margelijst opsplitsen) Nieuwe parameters Param1 : menu Param2 : frmmain Param3 : mnumargelijst(1) Waarde : 5 Param1 : menu Param2 : frmmain Param3 : mnumargelijst(2) Waarde : 5 RSZ kolom opsplitsen in RSZ_SV en RSZ_Andere RSZ_SV zijn de RSZ Structurele verminderingen RSZ_Andere zijn al de andere rsz-verminderingen


11/32

1.25. Aanpassing DIMONA (ticket 59874) " UPDATE DIMONALOGNOTI_ERROR set DNE_ERROR_HANDLED = 1 " & _ " WHERE DNE_ID in (" & _ " SELECT DNE_ID from dimonalognoti_error" & _ " INNER JOIN DIMONALOGBOOKD on DNE_LOGBOOKDID = dld_id " & _ " WHERE DNE_ERROR_HANDLED = 0" & _ " AND DLD_PrestId NOT IN (SELECT id from V_Prest_Dimona))" Qry toegevoegd in sub die opgeroepen wordt overal in hiant VOOR we gaan kijken of er dimonafouten zijn. Dit omdat er soms dimonafouten binnenkomen van prestaties die verwijderd werden uit hiant. Dan automatisch op afgehandeld zetten ! Anders opgelost ! bovenstaande verwijderd.

1.26. Aanpassing dimona (ticket 59977) controles indien insz of ondernemingsnr niet ingevuld is Als insz-nr van wn niet ingevuld is, controle doen af volgende velden ingevuld zijn : anders niet aangeven : naam,voornaam, adresgegevens Idem indien ondernemingsnummer van klant niet ingevuld zijn

1.27. Aanpassing Dimona (ticket 59976) Indien er voor een bepaalde uzk en klant in een bepaalde week wijzigingen of annulaties van dimona aangiftes zijn geweest, mogen er geen nieuwe contracten worden aangegeven totdat deze contracten terug de status OK/DELETED of CANCELED hebben. Standaard op, maar moet kunnen afgezet worden met een parameter. Probleem is dat zal deze contracten nog op MSEND of CSEND staan, dit aanleiding kan geven tot een dubbele aangifte. BV -

Contract van ma tot vr, wordt aangegeven en staat op OK Contract wordt ingekort tot wo, een aangegeven staat op MSEND Men maak een contract aan op VRIJDAG, Als dit w aangegeven geeft dit aanleiding tot een dubbel contract

Nieuwe parameter If geefparamwaarde("Dimona", "controlestatus", "actief", "0") = "1" Then

1.28. Ticket 58383 - releasenotes ticket 52926 - werknemersadres geldig van BUGFIX Met de parameter "frmWnGeg", "Controle", "AdresTypeId" (standaard = 0) kan je het standaardtype kunt meegeven van het adres van de WN dat wordt opgeslagen in de tabel wnadres.


12/32

Als de waarde van deze parameter gelijk is aan 0 zal deze de NULL waarde toekennen aan het adrestypeid.

1.29. Ticket 56175 - eID (aanvullende gegevens inlezen in Hiant) Bij het inlezen van gegevens op een E-id kaart worden nu ook het kaartnummer en de geldigheidsperiode ingelezen. Deze staan in de titelbalk vermeld.

Hiant zal het kaartnummer importeren en plaatsen in het veld Paspoortnr. Let op de geldigheidsperiode wordt nog niet bewaard in hiant!

1.30. Ticket 58230 - FW: Probleem nationaliteit Hiant Bij het inlezen van E-id gegevens binnen hiant onstonden problemen indien de kandidaat een buitenlandse nationaliteit heeft. De waarde op de kaart is blijkbaar leeg wat het onmogelijk maakt om binnen hiant de wn fiche te bewaren daar en eer koppeling gelegd wordt naar een blaco waarde (ook al past men deze waarde na het inlezen handmatig in). Als bij het inlezen blijkt dat er geen nationaliteit aanwezig is zal hiant dit melden en vragen aan de gebruiker om een nationaliteit te selecteren uit een onderstaande lijst.


13/32

1.31. Ticket 57026 – Automatische CV uit hiant Bij het aanmaken/tonen van de CV zijn 2 extra parameter ingebouwd. Standaard zijn deze uitgeschakeld. De parameter "frmCV", "AfdrukCV", "ReferentiesOpvolging" zorgt ervoor dat de referenties niet meer worden opgehaald vanuit de tabel werkervaring maar via de opvolging tabel "frmCV", "AfdrukCV", "MotivatieTekst" Toon de motivatietekst van de UZK op de CV

1.32. Ticket 59931 - Aanpassingen VDAB module - doorsturen Parameter 'changecontrols', 'frmbestellst', 'mnuPubliceer(2).visible' (standaard UIT) Er bestaat nu de mogelijkheid om alle aanwezige records in het bestelling overzicht door te sturen naar de VDAB zonder deze te markeren. Indien men records in de grid heeft staan die niet gekoppeld zijn aan de VDAB zullen deze uiteraard ook NIET doorgestuurd worden.


14/32

1.33. Ticket 59929 - Aanpassingen VDAB module - Controle jobkanaal Als je een bestelling wilt doorsturen naar de VDAB is het van belang dat er een post en een regime aanwezig is bij de betreffende bestelling. Met de parameter "frmBestelGeg", "VDAB_Controle", "PostEnRegime" (standaard UIT) zal bij het toevoegen van de jobkanaal VDAB en bij het bewaren van een bestelling een controle worden uitgevoerd die dit bevestigd. Als de bestelling hier niet aan voldoet zal hiant de gebruiker dit ook melden en zal de handeling niet uitgevoerd worden.


15/32

1.34. Ticket 57194 - Aanpassing afdruk 131A Met het activeren van de parameter "frmC131a", "ToonVeldenWeek2", "*" (standaard UIT) kan de je bij het afdrukken van de C131A werkgever de uren van een 2 week meegeven. Opgelet je kan ze hier enkel maar ingeven om ze vervolgens ook af te drukken Hiant is NIET voorzien om deze uren op te halen van de contracten of om deze op te slaan.

1.35. Ticket 54677 - wijziging tbv vakbondsafvaardiging. Parameter "Scherm", "Frmklgeg1", "ControleerVakbondOptie" (standaard UIT) Klanten optie AVO "aanwezigheid vakbondsafgevaardigde onbekend" optie zorgt ervoor dat de bestaande controle voor de verplichte ingave van vakbondsafvaardiging bij het bewaren van de fiche, niet geactiveerd wordt. Indien er geen optie omtrent de vakbond aanwezig is bij het bewaren van de klantfiche, stelt Hiant de vraag ‘naar de status van de vakbond’ : Vakbond aanwezig (-SYND) Geen vakbond aanwezig (GVA) Status vakbond onbekend (AVO)


16/32

Indien men deze laatste status kiest, zal Hiant automatisch de optie aanmaken met status op niet afgehandeld. Ook zal er een controle rapport aangemaakt worden. De aanmaak van het rapport zal in de autotask opgenomen worden zodat het rapport ook automatisch kan aangemaakt worden. Het rapport wordt standaard gemaild naar alle co medewerkers. Men kan echter via een parameter aangeven dat het naar bepaalde users dient verstuurd te worden. Ook zal de mogelijkheid bestaan om een rapport per kantoor aan te maken. In dit geval wordt het rapport naar het emailadres van het kantoor verstuurd. Indien men de lijst ‘CAO58-bis’ opvraagt uit HiAnt krijgt men een oplijsting van ALLE bedrijven die als klantoptie ‘GVA’ hebben ingesteld. Indien er op het moment van aanmaken van deze specifieke lijst nog klanten zijn met de optie ‘AOV’, dan krijgt de maker van deze CAO58-bis-lijst een melding dat er nog klanten in het systeem aanwezig zijn met de optie ‘AOV’. Er wordt op dat moment een bijkomende lijst gemaakt van de betreffende ‘AOV’-klanten met de volgende info: wgnr, klnr en klantnaam. Deze lijst wordt opgeslagen in de WISOLOK. Daarnaast wordt tevens de lijst aangemaakt met daarin ALLE klanten die als klantoptie ‘GVA’ hebben.

1.36. Ticket 59930 - Aanpassingen VDAB module - Preview tonen Parameter "VDAB_XML_Bestellingen", "Settings", "ToonAfdrukVoorbeeldHtml" (standaard UIT) De VDAB module is uitgebreid zodat men een preview te zien krijgt in de Layout van de VDAB website. Men kan de teksten die worden doorgestuurd bekijken hoe ze uiteindelijk zullen staan op de VDAB website. Een handige methode is dat dit scherm langs Hiant kan staan zodat men met 2 schermen kan werken om zo in hiant eventueel aanpassingen te doen en dadelijk ook het resultaat ziet. Bij het selecteren van een bestelling uit de lijst zal de preview getoond worden aan het rechtkant van het scherm zoals hieronder afgebeeld. Ook zullen op het scherm rechtsboven 2 knoppen tevoorschijnkomen. Data vernieuwen : Bij het controleren/aanpassen/goedkeuren van een bestelling in hiant kan je met deze knop dadelijk je aanpassingen zien in de preview. Afdrukken : Je kan ook indien gewenst de preview afdrukken.


17/32

de

Men kan de preview ook opvragen via een 2 mogelijkheid vanuit het bestellinglijst scherm van Hiant onder het menu acties Ł VDAB preview. Parameter “changecontrols”, “frmbestelgeg”, “mnuVdabVoorbeeld” (standaard UIT)

De preview kan enkel getoond worden in de geselecteerde bestelling ook gekoppeld is aan de VDAB jobkanaal. Indien dit niet zo is zal de gebruiker een melding krijgen.

Ook hier heeft men de mogelijkheid om de preview af te drukken. Rechts beneden van het scherm ziet de gebruiker ook of deze is goedgekeurd.


18/32

Je kan na het oproepen van de preview nog altijd de gegevens aanpassen in hiant zoals in onderstaand voorbeeld getoond.

Je kunt de tekst aanpassen waar nodig. Het is wel belangrijk dat je dan ook op de knop BEWAAR klikt.


19/32

Bij de preview drukt je op de knop vernieuw data

1.37. Ticket 60364 - VDAB status overzicht bestellingen tonen Parameter “changecontrols”, “frmbestelgeg”, “mnuVdabVoorbeeld” (standaard UIT) Nadat men bestellingen verstuurd heeft naar de VDAB zullen enkel de bestellingen zonder errors worden gepubliceerd. Hiant is nu voorzien om deze errors te raadplegen. Deze staan ook in de tabel VDAB_statusoverzicht. Tabel opbouw Id : BestandNaam : Bes_id : Begindatum : Einddatum : Status : VdabDatumVerwerkt : VdabStatusCode : Errors : IsLaatsteRapport :

uniek id Naam van het ingelezen bestand bij de VDAB id van de bestelling Begindatum publicatie van de bestelling Einddatum publicatie van de bestelling De VDAB status waarmee de bestelling verstuurd werd (Active, InActive, Pending) Datum en tijd controle bestelling bij de VDAB OK of Error – bij error is de bestelling NIET gepubliceerd Beschrijving van de errors die zijn opgedoken bij de VDAB controle Toont aan dat het record de laatste bewerking/status van De gekoppelde bestelling bevat.

Vanuit het bestellinglijst scherm kan men de status van de gepubliceerde bestellingen opvragen bij de VDAB.


20/32

Bij het opstarten zal hiant een verbinding maken met de VDAB server om vervolgens de feedback bestanden te overlopen. De bestanden (elk met een unieke naam!) worden 1 voor 1 overlopen met volgende procedure -

Controle of het bestand reeds ingelezen is (Veld BestandNaam) Indien Ja : volgend bestand overlopen Indien Nee : onderstaande controles uitvoeren

-

Controle of het bestand de laatste bewerking bevat (Veld VdabDatumVerwerkt) Indien Ja : gebeurt een UPDATE dat het veld IsLaatsteRapport op false voor de bestelling die overeenkomen met het huidig bestand

-

De gegevens wegschrijven naar de tabel VDAB_ statusoverzicht

De gebruiker krijgt uiteindelijk een scherm getoond met daarin per bestelling hun laatst gekende status bij de VDAB. Bestellingen die errors bevatten worden in het rood getoond.

Bij het selecteren van een rij zal de status beneden op het scherm getoond worden.


21/32

1.38. Ticket 58132 – document achterstalllige cheques Parameter “changecontrols”, “frmplankalender”, “mnuPrint(7).visible” Standaard UIT Document : OpvolgingAchterstalligeCheques.dot Binnen het planningsscherm krijg je een extra menuitem te zien dat op basis van jouw selectie een document zal afdrukken per WN met daarop hun naam, voornaam en rijksregisternummer om hun achterstallinge cheques in te vullen.


22/32

1.39. Fout bij procedure “zet uitdienst” binnen “beheer mastercontract scherm” [voor Securex exporters]: het dimonagegeven werd op “MODIFIED” gezet ipv “ENDCONT” Er was een probleem binnen procedure “zet uitdienst” binnen “beheer mastercontract scherm” [voor Securex exporters]: het dimona-gegeven werd op “MODIFIED” gezet ipv op “ENDCONT”. Binnen de oude dimona-verwerking gaf dit blijkbaar geen problemen. Bij de nieuwe dimona-versie is er echter een probleem hiermee. De dimona-aangiftes raken niet aanvaard en er komt een melding "Verboden om een wijzigende aangifte te doen om een Dimonaperiode af te sluiten" binnen. De programmatie is aangepast: bij “zet uitdienst” wordt de dimona nu op “ENDCONT” geplaatst.

1.40. Procedure gemaakt om volledige boeken van een (dubbel) loon naar saldo toe ongedaan te maken Er is al opgetreden bij een uitzendbedrijf dat een dubbel loon voorkwam. Waarschijnlijk zit er ergens in Hiant nog een achterpoortje waardoor een klaargezette fiche ergens dubbel in loonruns terecht kan komen. Met als gevolg een dubbel loon. Alleszins om de gevolgen van de problemen van een dubbel loon teniet te doen is er alvast een procedure uitgewerkt. Deze is op te starten, enkel voor programmeurs, via een menu “Programmeur / Lonen / Tegenboeken (dubbel) loon volledige actie (MC, Ttax…)” vanuit het contractenlijstscherm.


23/32

Via dit menu worden ALLE acties, die worden uitgevoerd bij het boeken van zo’n dubbel loon, teniet gedaan. De programmeur dient hierbij eerst zelf een loonrun aan te maken (bv. kopie nemen van bestaande loonrun met dubbele lonen in, wel direct status op 3 zetten, en waarbij velden zoals loonrungroep juist worden ingevuld). En hij dient de loon.id te kennen van de dubbele lonen.

Bij het uitvoeren van het menu wordt telkens een loonrunnr en een loon.id gevraagd. Volgende acties worden uitgevoerd tgv het menu: - Ecocheques geboekt bij boeken van het dubbele loon worden tegengeboekt - Maaltijdcheques geboekt bij boeken van het dubbele loon worden tegengeboekt - Het dubbele loon wordt tegengeboekt. Er wordt dus “een loon bij-gecreëerd”, met status -1. En bijbehorende loon-detail-lijnen met alle codes van het dubbel loon in negatief. - Het netto tgv het boeken van het dubbele loon wordt in negatief ingeboekt bij de voorschotten (zodat dit afgetrokken wordt bij een volgende loonberekening) - Het dubbele loon krijgt de status 1 (zodat dit als een “oud loon” wordt gezien). - De Ttax tabel wordt ingevuld (er komt hier slecht 1 record in per loonrun). Deze tabel wordt gebruikt bij de BV-berekening. - De trafak tabel wordt ingevuld. Hier komt records in gegroepeerd per kantoor, sektie, periode, jaar, trimester en loonrunnr voor de betreffende loonrun. Deze tabel wordt gebruikt oa voor het fiscaal attest.

1.41. Aanpassing export naar Securex: bij de export wordt de kantoorafdeling (“kostenplaats” in de terminologie van Securex) van de mastercontracten en losstaande weekcontracten STEEDS aangepast Tevoren werd enkel de kantoorafdeling (“kostenplaats” in de terminologie van Securex) van mastercontracten en losstaande weekcontracten, betrokken in de export, waarbij de kantoorafdeling nog niet was ingevuld, aangepast (dit gebeurt binnen de export naar Securex, alvorens het eigenlijke bestand wordt aangemaakt). De kantoorafdeling (kostenplaats) dient om door te geven aan Securex aan welk kantoor (kostenplaats) een contract is gekoppeld. Dit ging dan over nieuw aangemaakte mastercontracten en nieuw aangemaakte losstaande weekcontracten. Volgend probleem stelde zich echter: Indien men een “mastercontract aanpassing” uitvoert (nieuwe historiek binnen mastercontracten bij een bepaald Securexnr) met reden “ander kantoor” of wanneer men een losstaand weekcontract overkopieert naar een ander kantoor, wordt de kantoorafdeling van het broncontract gewoonweg overgenomen. Echter in deze gevallen zou de kantoorafdeling (kostenplaats) van deze contracten moeten aangepast worden ahv het nieuwe kantoor. De export naar Securex is nu aangepast: de kantoorafdeling (kostenplaats) van mastercontracten en losstaande weekcontracten, betrokken in de export, wordt nu STEEDS aangepast ahv het kantoor van het contract in kwestie.


24/32

1.42. Functionaliteit aangemaakt om uurlonen te indexeren – op basis van een conversietabel van oude uurlonen naar nieuwe uurlonen – ingave datum indexatie – automatische bepaling “oude uurlonen” door ophalen alle uurlonen op ingegeven “datum ophalen uurlonen” In eerste instantie is deze functionaliteit speciaal gemaakt voor de speciale situatie waarin de exporters van lonen van dienstenchequers van onbepaalde duur (met mastercontracten) naar Securex zitten. In deze gevallen moeten de bestaande mastercontracten beëindigd worden op de dag vóór de ingang van de nieuwe indexaties en dienen er bijkomende mastercontracten (met hetzelfde Securexnr) aangemaakt te worden, met het nieuwe uurloon, vanaf begindatum indexatie. Bij deze Securex-exporters moeten de mastercontracten immers steeds de volledige historiek van de uurlonen bevatten. Uurlonen moeten ook steeds gelijk zijn tussen het mastercontract en zijn subcontracten. De functionaliteit van het indexeren gaat bij Securex-exporters ook de subcontracten vanaf de indexatie datum onder een mastercontract omhangen naar het nieuw gecreëerde mastercontract (gecreëerd vanaf de indexatiedatum). [ook worden eventueel subcontracten waar de indexatiedatum middenin valt opgesplitst en enkel het tweede gehangen onder het nieuw gecreëerde mastercontract]

1.42.1.Opzet Het doel is dat men binnen Hiant, met een bepaalde datum van ingang, lonen kan indexeren. Dwz de aanmaak van de juiste periodes binnen de mastercontracten (aanmaak bijkomende periodes binnen mastercontracten bij een bepaald SecurexNr) en het juist instellen van de uurlonen binnen deze mastercontracten, subcontracten en de losstaande weekcontracten. De indexatie zal steeds gebeuren ahv een conversietabel (opsomming oude uurloon en corresponderende nieuwe uurloon). De indexatie zal steeds toegepast worden op de volledige set van contracten/mastercontracten bestaand op de datum van indexatie. De indexatie van losstaande contracten en mastercontracten kan wel apart opgestart worden (of samen). Indien men niet wil dat een bepaald uurloon geïndexeerd wordt kan men volgende doen: Uurloon niet opnemen in de indexatietabel (lijn verwijderen uit conversietabel) Of veld “nieuw uurloon” niet invullen of op -1 zetten Of bij “nieuw uurloon” dezelfde waarde invullen als het oude uurloon (niet aan te raden). De functionaliteit van het indexeren ahv een conversietabel is wel ook verder uitgebreid voor andere uitzendbedrijven, niet exporterend naar Securex. Dwz deze uitzendbedrijven kunnen ook gaan indexeren met deze functionaliteit, ahv een Conversietabel, waarbij men kan kiezen om losstaande contracten te indexeren en/of contracten gebonden aan een mastercontract. Bij deze niet-Securex-exporters worden er geen bijkomende mastercontracten aangemaakt. De link tussen mastercontracten en subcontracten wordt behouden.


25/32

Wel heeft men hier de mogelijkheid om eventueel bij de indexatie het uurloon van het mastercontract ook mee aan te passen.

1.42.2.Werking binnen Hiant Er is binnen het contractenlijstscherm een menu “Indexatie uurlonen”: - Programmeur / Contracten / Indexatie uurlonen Hierna wordt het indexatie-scherm geopend. Binnen dit scherm kan men de conversietabel voor omzetting van uurlonen op een bepaalde datum raadplegen/ingeven. Vanuit dit scherm kan men ook de eigenlijke indexatie doorvoeren.

Binnen dit scherm worden 2 menu’s voorzien: “Ingave uurlonen” “Indexatie doorvoeren” Het indexatie-scherm ziet er als volgt uit: Zoekveld waarmee men kan zoeken op de indexatiedatum Grid met de indexatielijnen vermeldend: indexatiedatum, “datum waarop de oude uurlonen zijn opgehaald”, oude uurloon, nieuwe uurloon.


26/32

Menu “Ingave uurlonen” Na opstart van het menu wordt de gebruiker gevraagd naar de datum waarop de indexatie dient plaats te vinden. Ook wordt er gevraagd naar de datum waarop de huidige set van uurlonen gaat opgehaald worden. Men kan dus een indexatie doorvoeren op 1/10/2010. Maar de set van “huidige uurlonen” kan men ophalen op datum 20/9/2010. Bovendien wordt er gevraagd of men 1) alleen de losstaande contracten wil indexeren 2) enkel de contracten gebonden aan een mastercontract wil indexeren of 3) zowel de losstaande contracten en de contracten gebonden aan een mastercontract wil indexeren. [er wordt ook nog gevraagd of men bij de indexatie van de contracten gebonden aan een mastercontract (subcontracten) ook het uurloon van het mastercontract zelf wil indexeren (enkel van toepassing bij niet-Securex-exporters; bij Securex-exporters komt er een nieuwe historiek op mastercontract-niveau en wordt sowieso het uurloon van het mastercontract en de subcontracten gelijk getrokken)]. Vervolgens worden uit de database al de verschillende uurlonen (uit losstaande contracten en/of contracten gebonden aan een mastercontract [evt. mastercontracten zelf] afhankelijk van de keuze hierboven, nl. welke contracten men wil indexeren) opgehaald op “datum waarop de huidige set van uurlonen gaat opgehaald worden”.

Binnen het indexatiescherm worden dan “datum indexatie”, “datum ophalen oude uurloon” en “oud uurloon” getoond voor de bekomen lijnen.


27/32

Het “nieuw uurloon” veld staat dan overal op -1. Men dient vervolgens zelf in te geven met welk nieuw uurloon het oude uurloon wenst te vervangen. Als men het menu “ingave uurlonen” uitvoert en er bestaan reeds conversielijnen op deze indexatiedatum, dan gebeurt er niets meer. Men kan eventueel wel zelf bijkomende lijnen toevoegen aan de conversietabel. Bij toevoegen van een lijn aan de conversietabel wordt er ook steeds gevraagd of men deze indexatie wil toepassen 1) alleen op de losstaande contracten 2) enkel op de contracten gebonden aan een mastercontract of 3) zowel op de losstaande contracten als de contracten gebonden aan een mastercontract. [er wordt ook nog gevraagd of men bij de indexatie van de contracten gebonden aan een mastercontract (subcontracten) ook het uurloon van het mastercontract zelf wil indexeren (enkel van toepassing bij niet-Securex-exporters; bij Securex-exporters komt er een nieuwe historiek op mastercontract-niveau en wordt sowieso het uurloon van het mastercontract en de subcontracten gelijk getrokken)]. Indien men niet wil dat een bepaald uurloon geïndexeerd wordt kan men volgende doen: Lijn verwijderen uit conversietabel Of veld “nieuw uurloon” niet invullen of op -1 zetten Of bij “nieuw uurloon” dezelfde waarde invullen als het oude uurloon (niet aan te raden).

Menu “Indexatie doorvoeren” Via dit menu kan men de eigenlijke indexering toepassen Ł Datum indexering wordt gevraagd; aan de hand hiervan worden de juiste records opgehaald uit de indexatie-tabel. Losstaande contracten - Bij de losstaande contracten zal het uurloon bij al de contracten WAARBIJ BEGINDATUM LIGT VANAF DATUM INDEXATIE en waarbij het uurloon gevonden wordt in de indexatietabel aangepast worden. Contracten gebonden aan een mastercontract bij niet-Securex-exporters - Bij de contracten gebonden aan een mastercontrat zal het uurloon bij al de contracten WAARBIJ BEGINDATUM LIGT VANAF DATUM INDEXATIE en waarbij het uurloon gevonden wordt in de indexatietabel aangepast worden. Eventueel wordt het uurloon van de mastercontract mee geïndexeerd (indien men hiervoor geopteerd heeft). Volgende mastercontracten worden dan aangepast: - de mastercontracten waaronder de subcontracten hangen die geïndexeerd zijn; het uurloon van het mastercontract wordt gelijkgesteld aan het uurloon van het subcontract. - mastercontracten gelegen vanaf datum indexatie met een uurloon gevonden in de conversietabel en waarvan er geen subcontract is dat geïndexeerd is, worden geïndexeerd ahv de conversietabel. Mastercontracten (en subcontracten gebonden aan deze masters) bij SecurexExporters waarbij de indexatiedatum valt tussen begindatum en einddatum (of oneindigheidsdatum indien de einddatum leeg is) - Bij de mastercontracten komen alle mastercontracten in aanmerking – waarbij het laatste mastercontract bij dit SecurexNr dimonastatus “OK” heeft - en waarbij “datum


28/32

indexatie” is gelegen tussen begindatum master en einddatum mastercontract (of oneindig ingeval van master van onbepaalde duur) en waarbij het uurloon zich bevindt binnen de indexatie-tabel. - Voor al deze mastercontracten zal een historieklijn binnen de masters bij dit SecurexNr toegevoegd worden (nieuwe historieklijn = ingang nieuwe uurloon). Volgende acties gebeuren er allemaal: o het bestaande mastercontract wordt afgesloten op “begindatum indexatie – 1 dag”. o Het dimona-gegeven, dimonastatus OK met het dimonanr, worden gehangen aan het nieuw bijgecreëerde mastercontract. Het afgesloten mastercontract krijgt een BLOCKED dimonastatus. o Een subcontract waar de indexatiedatum evt. middenin valt wordt opgesplitst. Het eerste deel blijft hangen onder het afgesloten mastercontract. Het tweede deel wordt gehangen aan het nieuw bijgecreëerde mastercontract. o De sucontracten die vallen vanaf datum indexatie worden alle gehangen onder het nieuw bijgecreëerde mastercontract. o Het uurloon van de nieuw bijgecreëerde master wordt geïndexeerd. o Het uurloon van de subcontracten van de nieuw bijgecreëerde master worden geïndexeerd. Mastercontracten (en subcontracten gebonden aan deze masters) bij SecurexExporters gelegen vanaf de indexatiedatum In dit geval dienen er geen mastercontracten bijgecreëerd te worden. Hier is dus niet zo’n complexe procedure. In dit geval zal enkel het uurloon binnen het mastercontract en zijn subcontracten aangepast worden. Alle mastercontracten komen in aanmerking – waarbij het laatste mastercontract bij dit SecurexNr dimonastatus “OK” heeft - en waarbij de begindatum is gelegen na “datum indexatie” en waarbij het uurloon zich bevindt binnen de indexatie-tabel. Voor al deze mastercontracten zal het uurloon van de master en zijn subcontracten aangepast moeten worden.

Bijkomende acties bij het indexeren fakturatieprijzen Het is zo dat bij de aanpassing van het uurloon binnen de contracten (het indexeren), afhankelijk van de instelling of het uitzendbedrijf werkt met fakturatieprijzen of niet, ook eventueel de fakturatieprijs binnen de contracten wordt aangepast (= uurloon * coëfficiënt). Logging binnen excels, getoond aan de gebruiker Er worden 2 loggings aangemaakt – 2 excels worden aangemaakt • één met overzicht van al de aangepaste master- en subcontracten: vermelding wnnr, wnnaam, contract-id, master(0 of 1), begindatum, einde, origineel uurloon, nieuwe uurloon, datum indexatie • één met overzicht van al de master- en subcontracten die niet aangepast werden, met vermelding van de reden (bv. uurloon niet gevonden in conversietabel): vermelding wnnr, wnnaam, contract-id, master(0 of 1), begindatum, einde, origineel uurloon, datum indexatie, reden niet indexatie (uurloon niet gevonden in conversietabel; of mastercontract zonder dimonastatus OK) Logging binnen logtabel op database Ook wordt al deze info ivm “wel geïndexeerde” en “niet geïndexeerde” contracten opgenomen in de logtable binnen de database, bij type 95.


29/32

1.43. Binnen scherm “eenvoudige ingave cyclus en roosters” – het is nu verplicht dat men het stelsel invult voor een ingevuld rooster Binnen het scherm voor “eenvoudige ingave van cyclus en roosters” is het nu verplicht dat men het stelsel invult voor een ingevuld rooster.

1.44. Aanpassing export naar Securex: voor premies waarvoor het totaal-bedrag wordt doorgestuurd (geen aantallen en eenheidsbedragen) worden er nu geen verschillende lijnen meer doorgestuurd Tevoren kon het zijn, bij de export naar Securex, bij premies waarvoor een totaal-bedrag moet doorgestuurd worden (geen aantallen en eenheidsbedragen) dat er verschillende lijnen in het exportbestand werden aangemaakt (waarbij de som van de bedragen bij deze lijnen wel gelijk was aan het totaalbedrag dat doorgestuurd dient te worden). Dit lag aan het feit dat er verschillende eenheidsbedragen voorkwamen binnen de premielijntjes na loonberekening. De programmatie van de export naar Securex is aangepast zodat bij de premies waarbij enkel een totaal-bedrag moet doorgestuurd worden, er slechts 1 lijn in het exportbestand meer wordt aangemaakt met het totaal-bedrag (er wordt niet meer gegroepeerd op eenheidsbedrag).

1.45. Aanpassing export naar Securex: apart kunnen exporteren van signaletiek (dus niet gebonden aan een loonrun; zonder dat er lonen zijn); reeds tussentijds doorsturen signaletiek opdat gegevens voor aanvraag C131-documenten snel beschikbaar zijn In het verleden was het zo dat er enkel gegevens konden geëxporteerd worden naar Securex voor dossiers waarvoor er lonen waren, dus samenhangend met de lonen voorkomend in één/meerdere geselecteerde/gemarkeerde loonruns. Met als gevolg dat bij dossiers met maandverloning de aanvraag van de C131-documenten steeds pas konden gebeuren meer dan een maand nadat de contracten waren aangemaakt, dus na doorsturen van de lonen en de bijhorende signaletiek van deze contracten. De export naar Securex is nu aangepast zodat men ook signaletiek kan doorsturen los van lonen. Dit doorsturen kan bvb. dan wekelijks gebeuren. Men heeft bij de opstart van een export nu de keuze tussen: - Signaletiek en loongegevens van geselecteerde loonruns of - Enkel signaletiek (nieuwe en gewijzigde contracten). Bij export “enkel signaletiek” worden dossiergegevens doorgestuurd gekoppeld aan contracten die voldoen aan volgende voorwaarden: - Bij losstaande contracten worden enkel contracten doorgestuurd die nog niet doorgestuurd zijn geweest naar Securex. - Bij mastercontracten worden zowel mastercontracten van nog niet doorgestuurde dossiers doorgezonden zowel als wijzigingen (nieuwe historieklijn) aan bestaande mastercontracten. Dus alle mastercontracten liggend tussen “begindatumsignaletiek” en Release Notes Hi-Ant Versie 5.35

30/32

“einddatumsignaletiek” (zie verder) worden overlopen, waarbij nieuwe mastercontracten steeds volledig worden doorgestuurd en bij gewijzigde mastercontracten worden enkel de wijzigingen doorgestuurd. - De begindatum van de (master)contracten moet liggen tussen een bepaalde “begindatumsignaletiek” en “einddatumsignaletiek”. * “begindatumsignaletiek” is standaard 3 maanden gelegen voor de huidige datum. Er is gekozen voor 3 maand opdat zeker de wijzigingen aan mastercontracten van het huidige kwartaal zouden doorgestuurd worden. * “einddatumsignaletiek” is standaard de einddag van de week waarbinnen de huidige datum valt. In het geval een programmeur of CO-medewerker is ingelogd, heeft deze de mogelijkheid om ander datums dan de standaard “begindatumsignaletiek” en “einddatumsignaletiek” in te geven. Dit bijv. om bij opstart van een uitzendbedrijf alle contracten met een hele range van begindatums ineens door te sturen. - Er moet een dimonastatus zijn verschillend van volgende statussen: 'CANCELED', ‘DELETED’, 'MARKED' of 'CSEND'. - Vermits er bij dossiers zonder lonen geen loonperiode is, wordt er een fictieve loonperiode bepaald. Oa. voor het doorgeven van de contractrooster-info, die bij doorsturen van mastercontracten uit de subcontracten wordt gehaald, worden de subcontracten uit deze loonperiode overlopen. * standaard wordt deze loonperiode bij mastercontracten bepaald als de maand waarbinnen de begindatum van het mastercontract ligt. * Indien men ingelogd is als programmeur kan men echter een andere, opgelegde, loonperiode ingeven. Bij export wordt er gevraagd of men wenst te werken met een opgelegde loonperiode en wordt vervolgens evt. gevraagd naar de (begindatum van) deze loonperiode. Bijv. bij een opstartend uitzendbedrijf kan zo’n opgelegde loonperiode nodig zijn. Indien men mastercontracten voorziet met hun werkelijke begindatum, maar men enkel subcontracten voorziet beginnend vanaf de datum van opstart van dit uitzendbedrijf, zouden zonder opgelegde loonperiode een hele hoop mastercontracten niet doorgestuurd worden omdat ze in de loonperiode waarbinnen begindatum mastercontract valt geen subcontracten hebben. In dat geval dient men een opgelegde loonperiode in te geven met als begindatum = begindatum opstart uitzendbedrijf. Indien men werkt met een opgelegde loonperiode, worden wel enkel mastercontracten doorgestuurd die nog niet doorgestuurd zijn geweest naar Securex. De werkwijze met “opgelegde loonperiode” is eigenlijk ook maar enkel voorzien voor de “initiële export bij een opstartend uitzendbedrijf”. - Er moeten binnen de “fictieve loonperiode” dus ook steeds subcontracten aanwezig zijn, zoniet gebeurt er geen export voor dit mastercontract. Bij het doorsturen van “enkel signaletiek” dient achteraf ook een export goedgekeurd of afgekeurd te worden. Men ziet het goedgekeurd/afgekeurd zijn wel niet “fysiek” in een lijst zoals binnen het overzicht van de loonruns. Men kan echter geen volgende export (van “enkel signaletiek” of lonen en signaletiek) opstarten zonder dat een vorige export is goedgekeurd of afgekeurd.

1.46. Aanpassing programmatie berekening voorschotten: via parametrisatie kan nu de afronding van het berekende voorschot gestuurd worden


31/32

De programmatie ivm berekening van de voorschotten is aangepast. Via een parameter kan de afronding van het berekende voorschot gestuurd worden. Standaard wordt het berekende voorschot afgerond tot op 2 cijfers na de komma. Indien men een parameter ("Scherm", "FrmVoorschottenlst", "AfrondingsType") aanmaakt met waarde 1, wordt het berekende voorschot naar beneden afgerond naar het dichtstbijzijnde tiental.


32/32

16

Recommend Documents