11

Release Notes Afdrukdatum: 2012/07/11

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

1/20

1.

V6.027 1.1. -

Nieuwe bestanden

Jaarverslag.rpt JaarVerslag.rpt

1.2.

Bugfixes 1.2.1. Opvolgingen verwijderen Het verwijderen van opvolging kon problemen geven op servers met comptabiliteitssettings op SQL2005 en hoger. De manier waarop het record verwijderd wordt is nu aangepast om grotere compatibiliteit te geven.

1.2.2. Afdruk VormingV1 e

Op het vormingsdocument V1 werd steeds de naam van het 1 kantoornummer vermeld. Dit is aangepast naar het kantoor waaruit het document wordt gedrukt.

1.2.3. Bug aanmaak kalender – verlengen kalender – 2 wekelijks systeem Bij aanmaak kalender/verlengen kalender ging iets fout bij het opzoeken van de startweek wanneer de Minimum datum aanmaak kalender (leeg = begindatum van deelrooster) : geen maandag was. Aanpassing gebeurd in aanmaak kalender procedure zodat deze bug opgevangen wordt.

1.2.4. Bugfix: bij “zet prestaties op te berekenen” en een controlelijst-item gaf een “probleem-geval” terug dat echter niet-blokkerend was, en waarbij de gebruiker dit “probleemgeval” negeerde er wordt weggeschreven naar de logtable; als de omschrijving van het controlelijst-item een enkel aanhalingsteken bevatte, kwam er een runtime-error Het probleem was het volgende: Bij “zet prestaties op te berekenen” en een controlelijst-item gaf een “probleem-geval” terug dat echter niet-blokkerend was, en waarbij de gebruiker dit “probleem-geval” negeerde in dit geval wordt de melding weggeschreven naar de logtable. Als de omschrijving van het controlelijst-item een enkel aanhalingsteken bevatte, kwam er een runtime-error. Het enkele aanhalingsteken is een speciaal teken voor SQL server en geeft problemen bij opvulling naar de database van teksten met een enkel aanhalingsteken in (in dit geval opvullen van de logtable), tenzij dit door de programmatie is opgevangen. De programmatie is aangepast (opvullen logtable bij probleem bij een controlelijstitem), zodat er geen probleem meer is met meldingen waar een enkel aanhalingsteken in voorkomt.


2/20

1.3.

Overhalen inschrijvingen vanuit website

Wanneer er gebruik gemaakt wordt van een website voor inschrijvingen te doen van uitzendkrachten wordt gecontroleerd of er belgische gsmnummers zijn ingegeven in de velden van telefoonnummer. Soms werd hier echter ook een landcode ingegeven bv. +32. Hierdoor werden de belgische gsmnummers niet automatisch toegevoegd aan de communicatienummers met type GSM. Aanpassing is gebeurd zodat dit nu ook mogelijk is.

1.4.

Aanmaak contracten vanuit planningsmodule – controle attest dienstencheque Cat. A of Cat.B bij eerste 3 maanden

Te activeren met onderstaande parameters "codeboekcode","Attest","DC","-1" -> deze bepaalt de code van het type attest Dienstencheques. "codeboekcode","Attest","DCCatA","0" -> deze bepaalt detailtype van attest categorie A. "codeboekcode","Attest","DCCatB","0" -> deze bepaalt detailtype van attest categorie B. "initialisatie","planning","controleattestCatAofB","0" -> deze bepaalt of controle moet gebeuren Indien alle bovenstaande parameters zijn ingevuld en parameter "initialisatie","planning","controleattestCatAofB" staat op 1, dan zal tijdens aanmaak van contracten vanuit de planning gecontroleerd worden of de personen die dagcontracten krijgen (dus eerste 3 maanden) een geldig attest hebben van catergorie A of B. OPGELET dit werkt enkel indien men werkt met controle 3maanden via parameter "initialisatie", "planning", "controlecontractbepaaldeduur", "1".

1.5.

Fakturatiemodule scherm

Wanneer men op een knop klikt in dit scherm worden alle knoppen disabled. Echter werd na het terug enabelen van deze knoppen, de focus niet op de knop gezet van waar men initieel had op geklikt. Dit is in deze versie aangepast.

1.6.

Jaarverslag ongevallen via HiAnt mogelijkheid om extra commentaar op rapport te zetten

De commentaar wordt ingesteld via de vertaalUZB tabel met code JAARVELabel47. Standaard is dit leeg. Men kan in de vertaalUZB tabel dus voor nl en fr een tekst invullen die standaard op het jaarverslag dient geprint te worden. De tekst komt in het vet onder de Naam en funktie van aanmaker van document.

1.7.

Afdruk loonbrief nieuwe layout – taalwetgeving – loonbrief V4.47

Ingebouwd bij afdruk loonbrief nieuwe layout zodat de taalwetgeving wordt gerespecteerd. Bij tussenscherm voor het printen is er een vinkje en uitleg bijgekomen


3/20

Dit vinkje is standaard niet te wijzigen (kan eventueel wel via changecontrols aangepast worden zodat het bv. enkel voor co-medewerkers kan afgevinkt worden). Aangevinkt = taalwetgeving toepassen Niet aangevinkt = taal gebruiken van werknemersfiche ongeacht gewest. Het gewest wordt bepaald door het ingestelde gewest in het kantoor waar het loon is op geboekt (loon.wgnr) waarbij : 1 = Vlaams gewest 2 = Waals gewest 3 = Brussels gewest Indien het gaat om een sektie voor dienstencheques (sektie.dienstencheque = 1) dan zal het gewest bepaald worden door het gewest op te zoeken in de postcodes tabel via de postnummer van de dienstverlener (loon.klnr). Het kan namelijk zijn dat men in een database alle dienstverleners in 1 kantoor hebben zitten, maar dat deze dienstverleners in verschillende gewesten zijn gevestigd.

1.8.

Planningsmodule – mogelijkheid tot verwijderen van een contract

Vanuit zicht werknemer als men op rij staat van de persoon kan men rechts klikken met muis en verwijder contract selecteren. Men kan contract enkel verwijderen als er op de dagen onder dat contract geen planning meer bestaat (types 110 en 210). Verder wordt gecontroleerd of er een dimona is gebeurd, zo ja kan men dit niet verwijderen. Ook wordt gecontroleerd of voor die periode een wnbetaalperiodestatus bestaat. Indien er dan prestaties/premies of loon is gevonden voor dit contract kan men dit ook niet verwijderen (zelfde controles als bij verwijder gemarkeerde contracten uit contractenlijst scherm)


4/20

1.9.

Verwijderen contract vanuit F4 lijstscherm via acties – verwijder gemarkeerde contracten.

Er werd geen controle gedaan of , indien het een mastercontract betrof, er nog subcontracten aan het mastercontract hingen. Aanpassing is gebeurd, zodat bij verwijderen via deze weg van mastercontract dit niet lukt indien er nog subcontracten aanwezig zijn.

1.10. Verwijderen contract vanuit shif+F4 lijstscherm – bug Indien er nog geen wnbetaalperiodestatus record bestond voor deze persoon en periode, kon het contract verwijderd worden zonder dat er een controle op dimona gebeurde. Aangepast , zodat indien er een dimonarecord voor dit contract bestaat, men niet kan verwijderen.

1.11. Toevoegen aan fakturatierun – automatisch bepalen van fakturatiesysteem bij optie via klant toevoegen Wanneer men gegevens toevoegt aan een fakturatierun om te berekenen, heeft men de mogelijkheid om een selectie te doen op basis van de klant, of meerdere klanten gescheiden door een komma.

Wanneer men de optie klant aanduidt, en men geeft de klantnummer in, dan zal het fakturatiesysteem van die klant opgezocht worden. Indien gevonden, en verschilt van het ingegeven fakturatiesysteem, zal het facturatiesysteem op het fakturatiesysteem van de klant gezet worden, en de eventueel reeds geselecteerde periode terug leeggemaakt worden. Wanneer er meerdere klanten zijn opgesomd (komma gescheiden), zal het fakturatiesysteem van de eerste klant worden gebruikt.

1.12. Ongevallenmodule – datum kennisgeving ongeval V4.83 Door onderstaande parameter op 1 in te stellen zal de datum van kennisgeving aan werkgever bij het aanmaken van een nieuw ongeval ingevuld worden met de systeemdatum. "initialisatie", "ongevallen", "systeemdatumbekendmaking", "0"

1.13. AfdrukModule - PrestatieFormulieren De afdrukmodule is verder uitgebreid zodat het nu mogelijk is om ook vanuit hiant de PrestatieFormulieren af te drukken met de nieuwe module. Deze zal dan ook via de nieuwe Crystal Reports manier afgedrukt worden en niet meer via word zodra men de parameter heeft


5/20

ingeschakeld. Prato heeft een standaard sjabloon ter beschikking maar het is natuurlijk mogelijk om van deze af te wijken in overleg met Prato. Parameters Opvragen bij PRATO Standaard waarde = 0.

Dit activeert de nieuwe afdrukmodule voor het prestatieformulier. Waarde 1 activeert de module voor het type document dat vermeld staat in param2. "Afdruk", "AantalExemplaren", "PRESTATIEFORMULIER" standaard waarde = 1

Dit bepaalt per document hoeveel exemplaren er worden afgedrukt . De waarde bepaalt het aantal exemplaren. Vertalingen Voor de prestatieformulieren zijn dit ALLE vertallingen uit de vertaal en vertaaluzb tabel die beginnen met PRESTFORMULIER. De taal van het document kan worden bijgestuurd via de getDocutaal functie van de module.

1.14. Ticket 86843 - PrintFacturatie : ParamOfficeGroup PrintFacturatie.exe is uitgebreid zodat er bij het ophalen van de parameters rekening gehouden wordt met de UserName en de ParamOfficeGroup waarmee de gebruiker ingelogd is in Hiant.

1.15. Ticket 86844 - PrintFacturatie : PDF naam Bij het exporteren van de facturen naar PDF bestanden zal voortaan rekening gehouden worden met de waarde van de parameter "AfdrukFactuur", "optie", "ExportPdfBenaming" De waarde van deze parameter bepaald het bestandsnaam van de PDF. Waarde 1 = FactuurNummer + '_f' + InternFactuurNummer + '.pdf' Alle andere waarde = FactuurNummer + '.pdf' Andere waardes kunnen in de toekomst ook mogelijk zijn.

1.16. Ticket 86846 - PrintFacturatie : Export facturen naar PDF Parameter "AfdrukFactuur", "optie", "ExportDuplicaten" Standaard UIT (waarde 0) Deze parameter gaat na of bij het exporteren van PDF's de duplicaten al dan niet mee geexporteerd worden.

1.17. Bugfix: Ticket 87026: Maandelijkse statistiek Federgoon: het aantal gewerkte dagen is niet correct De telling loopt verkeerd waardoor het aantal gewerkte dagen niet klopt indien er meer dan 1 verlofdag op een weekdag per maand voorkomt. Voor 2012 geeft dit dus enkel problemen voor Mei. De Telling is aangepast zodat deze nu ook correct loopt voor Mei. Technisch: Code aangepast in ‘frmMain.MaandStatistiekPerJobstudentJaNee’. For i = 1 To DatePart("d", DatEinde) If DatePart("w", DateSerial(intJaar, CInt(bytMonth), i), vbMonday, vbFirstFourDays) < 6 Then


6/20

If Not (rs.BOF And rs.EOF) Then rs.MoveFirst booIsWerkdag = True While Not rs.EOF If Trim(ls(rs!Waarde)) = intJaar & "-" & Right(0 & CInt(bytMonth), 2) & "-" & Right(0 & i, 2) Then booIsWerkdag = False End If rs.MoveNext Wend If booIsWerkdag Then intDagen = intDagen + 1 End If Else intDagen = intDagen + 1 End If End If Next i

1.18. Ticket 86673: Filterveld factuur maand toevoegen ‘frmexport’ grid facturen Er kon enkel gefiltert worden op jaar. De filter voor maand is nu ook toegevoegd. Technisch: Code aangepast in ‘frmexport. InitExportBIK’: With BrwBikFacturen .MaxItems = CstMaxItems ' .selectstring = "select id,id,omschrijving,fakturatierun.datum,min(" & StrFactnr & ") as minfactnr,faktuur.jaar from fakturatierun inner join faktuur on fakturatierun.id = faktuur.fr " .selectstring = "select id,* from " & _ "(select id,omschrijving,fakturatierun.datum,min(" & StrFactnr & ") as minfactnr,faktuur.jaar, min(Month(faktuur.Datum)) As minmaand " & _ " From fakturatierun inner join faktuur on fakturatierun.id = faktuur.fr " & _ " Where IsNull(exportdate, 0) = 0 And status = 1 " & _ " group by id,omschrijving,fakturatierun.datum,faktuur.jaar) as temp" .ColumnHeadings = Array("id", "id", "Omschrijving", "Datum", "MinFactnr", "FactJaar", "FactMaand") ' .wherestring = " where isnull(exportdate,0)=0 and status = 1 " ' .OrderByString = "group by id,omschrijving,fakturatierun.datum,faktuur.jaar order by minfactnr " .OrderByString = " order by minfactnr " .NumberOfInvisibleColumns = 1 .NumberOfSearchFields = 2 .SearchLabels = Array("Fact.Jaar", "Min.Maand") .searchFieldNames = Array("jaar", "minmaand") .SearchFieldTypes = Array(3, 3) .SearchInitValues = Array("", "") .LookUpSQLStrings = Array("", "") .ColWidthSetup = 1 If geefparamwaarde("scherm", "frmexport", "ToonFactuurZoekveld", "0") = "1" Then .ControlsVisible = True .ColumnWidths = Array(0, 5, 20, 5, 5, 5, 4) Else .ControlsVisible = False .ColumnWidths = Array(0, 5, 20, 5, 5, 0, 0) End If '.ColumnWidths = Array(0, 5, 20, 5, 5, 5) .MoveLastAfterRefresh = False .InitControl End With


7/20

1.19. Ticket 71883: Code komt voor met verschillende omschrijvingen in de omzetlijsten (Hoofdscherm menu: Lijsten > Overzichtlijsten > Omzet/facturatie gegevens) Het probleem is, dat Hiant de omschrijving van de code uit de factuurdetails gaat halen. Aangezien hier hetgeen staat wat effectief op de factuur vermeld wordt, kan het zijn dat er voor een bepaalde code, meerdere omschrijvingen voorkomen (Frans en Nederlands, andere omschrijving door manuele factuur). Hiant is nu aangepast zodat met een parameter kan aangegeven worden of de omschrijving van de code uit de factuurdetails of uit de code-tabel komt. Standaard komen ze uit de factuurdetails, door de parameter op waarde 1 in te stellen, worden ze uit de code-tabel gehaald. Er wordt dan ook rekening gehouden met de taal van de consulent(e). 1. aram1 5. verzichtlijsten

P2. aram2 O6. mzetlijst

3. Pa ram3 4. Mogelijke Waardes 7. To 8. 0 (Default waarde) onCodeOmschr Omschrijving uit factuurdetail 9. 1 Omschrijving uit codetabel

Technisch: Code aangepast in ‘frmmain.mnuoverzicht_click’ bij index 6. • Nieuwe variabele toegevoegd ‘booToonCodeOmschr’ waarin de waarde van da parameter wordt bijgehouden • In de instellingen van de grid voor de verschillende lijsten rekening houden met dit veld voor het ophalen van de code omschrijving. Dit is in de selectstring en de orderbystring van de grid.

1.20. Ticket 86760 – Controle herberekening Sociaal Abonnement parameteriseerbaar In de vorige versie werd een controle ingebouwd die een melding gaf dat je het Sociaal Abo moest herberekenen nadat je manueel een prestatie toevoegde. Vanaf nu staat deze controle standaard uit en kan je ze actieveren door parameter "scherm", "prestatieIngave", "ControleHerberekeningSocAbo" op waarde 1 te zetten.

1.21. Ticket 86495 – Kantoorgegevens - €EPA Vanaf nu kan je bij de kantoorgegevens de bankgegevens ook ingeven in IBAN en SWIFT vorm. Dit met het oog op de latere omschakeling naar SEPA bankbestanden. Vroeger:


8/20

Nu:


9/20

1.22. Ticket 85939 - Attest “Geen Voorschot” Je kan mensen met een attest "Geen Voorschot" uitsluiten van de voorschotten. Je dient hiervoor eerst een attest Geen Voorschot aan te maken, en de gekozen code te specifiëren in parameter "codeboekcode", "attest", "GeenVoorschot". HiAnt gaat bij het voorstellen van voorschotten dan mensen die zulk geldig (begin- en einddatum invullen!) attest hebben overslaan.

1.23. Ticket 86616 – Logging Dimona Foutafhandeling Je kan een logging activeren door parameter "dimona", "logFoutAfhandeling", "actief" op waarde 1 in te stellen. Indien gewenst kan je de UZC’s ook om de reden van afhandeling vragen door parameter "dimona", "logFoutAfhandeling", "VraagReden" aan te maken met waarde 1. De logging gebeurt onder type 104 en vermeldt wie, wanneer, waarom en ook het prest.ID, de foutomschrijving en de werknemer naam.

1.24. Ticket 86836 – Aanpassing klantenlijstscherm Is het mogelijk in de frmkllst (klanten en prospecten & klanten) te voorzien dat bedrijven die op geen samenwerking staan (dus waar het ! komt voor te staan) standaard niet getoond worden in die lijst, maar dan via een checkbox de mogelijkheid gegeven wordt deze zichtbaar te maken?


10/20

Onderaan de klantenlijst en klanten- & prospectenlijst kan je een checkbox zichtbaar maken die de klanten met status ‘geen samenwerking’ wegfiltert. Standaard staan deze verborgen, je kan ze activeren met onderstaande parameters: Zichtbaarheid Klantenlijst: changecontrols, frmkllst, chkHideNoColab.visible, 1 Zichtbaarheid Klanten- & Prospectenlijst: changecontrols, frmkllst1, chkHideNoColab.visible, 1 Standaardwaarde: "initialisatie", "klantenlijst", "checkboxGeenSamenWerking", 0 of 1

1.25. aanpassing IMPORT JDE in AutoTask vraag : Beste, Bij het aanmaken van een nieuwe klant is er een interface tussen HIANT en JDE Dit via FTP Nu hebben we in PROEF de JDEdwards omgeving intern draaien op onze eigen servers (binnen het domain) Kunnen we enkele interface testen organiseren aub Nieuwe bestandslocatie = \\wi1wk229\jde\pd Hieronder vinden jullie de folders die U reeds bekend zijn. Maw het enige die aangepast werd is de manier van import/export Voorheen FTP Nu via UNC path Hebben jullie een bepaalde userid nodig ? of is het de ActiveDirectory user die rechten nodig heeft op die share ?

Aanpassing gedaan : nieuwe parameters : Param1 :AutoTask Param2 : ImportJDE Param3: UseUNCPath Waarde = 1 dan UNC gebruiken, andere waarde : gebruik secure ftp Param1:AutoTask Param2 :ImportJDE Param3 :UNCFolder Waarde = UNc bijvoorbeeld \\ariane\users\droogmans frank\EXPORT\HIANT Param1:AutoTask Param2:ImportJDE Param3:UNCBackUpFolder Waarde = UNC bijvoorbeeld \\ariane\users\droogmans frank\ARCHIVE\HIANT In autotask overal opsplitsing gemaakt.

1.26. Aanpassing Dimona Doorgeven plaats tewerkstelling Studenten (18/6/2012) (ticket 86468) Nieuwe parameter Param1 = ‘dimona’ Param2 = ‘PlaatsTewerkstelling’ Param3 = ‘Sekties’ Waarde = opsomming van de sekties ( komma gescheiden) Waarschijnlijk sekties van studenten (zie parameter ("initialisatie", "jobstudent2012", "sekties", "")) Parameter om dimona-aangifte aan te passen


11/20

Param1 : dimona Param2 : Student Param3: afwijkendadres Waarde : 1 Om te activeren.

Zeer belangrijk : Voor iedereen nieuwe pratodimonav2.dll (compile datum 19-06-2012) Aanpassing dima_xml_stuctuur tabel !!

1.27. Bugfix “Procedure om volledige boeken van een (dubbel) loon naar saldo toe ongedaan te maken” – het inboeken van een negatief netto voor de tegenboeking ging mis Er zat nog een foutje in de “procedure om volledige boeken van een (dubbel) loon naar saldo toe ongedaan te maken”: het inboeken van een negatief netto voor de tegenboeking ging mis. Er was een probleem met een type variabele.

1.28. Aanpassing werking ecocheques bij HDP-exporters: als een bedrag wordt ingegeven kleiner dan het bedrag van een volledige ecocheque geen probleemmelding meer met “aantal 0” voor de volledige ecocheques + ook niet meer inboeken volledige ecocheques met waarde 0 Het probleem was het volgende: Bij HDP-exporters moeten ecocheques ingegeven worden met code 2801. Er was een probleem indien een bedrag ecocheques wordt ingegeven waarbij het bedrag minder is dan de waarde van een volledige ecocheque. Achterliggend gebeurt het volgende bij ingeven van ecocheques: - aantal volledige ecocheques bepalen ahv ingegeven bedrag en inboeken onder de 2801 In het geval dat ecocheques worden ingegeven met een bedrag van 5 EURO geeft dit aantal 0 en waarde 0 voor premie 2801 Bij niet-programmeurs kwam er sowieso een foutmelding als aantal 0 is. Bij programmeurs kwam er geen melding op aantal 0 en werd er wel een premie 2801 ingeboekt met aantal en waarde 0 (hetgeen niet zo’n groot probleem is; premies met waarde 0 worden toch niet geëxporteerd naar het sociaal secretariaat). - het restbedrag ecocheques bepalen en inboeken onder de 2805. De programmatie van beide prestatie-ingaveschermen is aangepast zodat er geen probleem meer is met ingave van ecocheques waarbij het bedrag minder is dan het bedrag van een volledige ecocheque: - niet meer reclameren op aantal 0 als het gaat om ecocheques bij HDP-exporters - geen 2801 meer inboeken als waarde 0.


12/20

1.29. Aanpassing “maak subcontract aan” bij mastercontract: cyclus (en bijhorende roosters) gelijk zetten aan cyclus van mastercontract Bij "maak subcontract aan" vanuit een mastercontract werden tevoren als cyclus en roosters van het subcontract altijd de laatst actieve cyclus en roosters genomen. Dit is niet wenselijk bij Securex-exporters. De cyclus en roosters moeten bij Securex-exporters bij een subcontract altijd als volgt bepaald worden: cyclus gelijk aan cyclus van mastercontract waartoe het subcontract hoort (en roosters zijn de roosters horende bij deze cyclus).

Het feit of de cyclus (en roosters) van een subcontract worden gelijk getrokken aan deze van het mastercontract, wordt als volgt bepaald: - bij Securex-exporters geldt dit standaard, tenzij een parameter ("cyclischrooster", "CyclusSub", "GelijkAanCyclusMaster") wordt aangemaakt met waarde 0. - bij NIET-Securex-exporters geldt dit standaard NIET, tenzij parameter ("cyclischrooster", "CyclusSub", "GelijkAanCyclusMaster") wordt aangemaakt met waarde 1

1.30. Vooral voor Securex-exporters aangemaakt: 1) bij aanmaak nieuw contract wordt eerst tussenscherm getoond voor selectie klnr en wnnr; dan scherm voor ingave cyclus en roosters 2) Bij openen contract worden de contractrooster-velden en DMFAvelden geblokkeerd Volgende is aangepast aan de programmatie: 1) Programmatie aangemaakt zodat, bij druk op de "+"-knop bij de contractenlijst volgende gebeurt: - eerst tussenscherm voor selectie klnr en wnnr; de sektie wordt automatisch ingevuld ahv wnnr - dan controle of er al een cyclus en roosters bestaan bij de geselecteerde klnr en wnnr met autocreate = 1 * Als ja --> deze cyclus nemen * Als neen --> tussenscherm voor ingave cyclus en roosters Men moet dan eerst een cyclus en roosters aanmaken. Na verlaten van dit scherm voor ingave van cyclus en roosters: er wordt nogmaals gecontroleerd of er een cyclus en roosters bestaan bij klnr en wnnr met autocreate = 1. Indien neen, kan er niet verder gegaan worden met contractaanmaak Indien ja, dan wordt er verdergegaan met contract aanmaak. Deze autocreate-cyclus zal dus ook ingevuld zijn. 2) Bij openen van een nieuw of bestaand contract worden de velden stelsel, S, urenFT, urenPT, uren bet.comp., uren onbet.comp., Q en al de roostervelden geblokkeerd. Dit geldt in de volgende gevallen: - bij de Securex-exporters, tenzij parameter ("frmContLst", "RoosterEnDmfaVelden", "Blokkeren") aanwezig is met waarde 0. - bij de NIET-Securex-exporters geldt dit NIET, tenzij parameter ("frmContLst", "RoosterEnDmfaVelden", "Blokkeren") aanwezig is met waarde 1.


13/20

1.31. Vooral voor Securex-exporters aangemaakt: niet meer kunnen wijzigen van cycli-roosters indien de cyclus al gebruikt wordt binnen een contract met een wnbetaalperiodestatus De volgende wijzigingen aan de programmatie zijn doorgevoerd: Scherm "Cyclische roosters - eenvoudige ingave" aangepast: Indien de cyclus voorkomt binnen contracten met een wnbetaalperiodestatus, dan kan men geen wijzigingen meer aanbrengen aan cyclus en rooster info. Alle schermen ivm "Cyclische roosters", voor de gedetailleerde roosteringave, aangepast - Indien de cyclus voorkomt binnen contracten met een wnbetaalperiodestatus, dan kan men volgende niet meer uitvoeren: - men kan een cyclus niet meer bewerken of verwijderen - men kan geen wijzigingen, toevoegingen of deletes meer doorvoeren aan de cyclus-rooster links - men kan geen wijzigingen, toevoegingen of deletes meer doorvoeren aan de roosterdetail-lijnen (dagdelen) gekoppeld aan een rooster die op zijn beurt is gekoppeld aan zo'n cyclus die gebruikt wordt binnen een contract met een wnbetaalperiodestatus. - men kan een rooster niet meer wijzigen of verwijderen wanneer het gekoppeld is aan zo'n cyclus die gebruikt wordt binnen een contract met een wnbetaalperiodestatus. Deze werkwijze van beveiligen van cycli en roosters wordt toegepast in volgende gevallen: - standaard bij de Securex-exporters tenzij parameter ("cyclischrooster", "MetWnbetaalperiodeStatus", "Blokkeren") wordt aangemaakt met waarde 0. - Bij NIET-SECUREX-exporters geldt dit standaard NIET, tenzij parameter ("cyclischrooster", "MetWnbetaalperiodeStatus", "Blokkeren") wordt aangemaakt met waarde 1.

1.32. Vooral voor Securex-exporters aangemaakt: indien uren-info of DMFA-veld-info van cyclus of rooster gewijzigd wordt, dan ook de uren-info of DMFA-veld-info in de contracten aanpassen Bepaalde uitzendbedrijven willen niet dat er rechtstreeks uur-info of DMFA-veld-info (uren FT…) rechtstreeks in de contracten wordt ingegeven. Deze info is dan ook geblokkeerd binnen de contracten. Daarentegen wil men dat alles loopt via het ingeven van cyclus en roosters die dan geselecteerd worden binnen een contract. Een cyclus/roosters, gekoppeld aan een contract, waarbij evenwel de cyclus/roosters niet gekoppeld zijn aan contracten die reeds een wnbetaalperiodestatus hebben, kunnen echter nog gewijzigd worden. Men wil echter dat, indien men binnen een cyclus/roosters uur-info of DMFA-veld-info wijzigt, binnen de contracten die gebruik maken van deze cyclus/roosters de uur-info en/of DMFA-veld-info ook mee wijzigt. De programmatie om dit te verwezenlijken is aangemaakt. Volgende aanpassingen zijn doorgevoerd: A) Scherm voor "eenvoudige roosteringave" aangepast: er wordt bij wijziging van uur-info of DMFAveld-info bijgehouden dat er een wijziging is aan uur-info of DMFA-veld info. Er is ook instelbaar via een parameter of bij een wijziging van uur-info of DMFA-veld-info de (master)contracten dienen aangepast te worden: - bij Securex-exporters worden standaard de contracten aangepast, tenzij een parameter ("CyclischRooster", "UrenOfDMFAWijziging", "AanpassenContracten") aanwezig is met waarde 0. - bij NIET-SECUREX-exporters is het zo dat standaard de contracten NIET aangepast worden, tenzij Release Notes Hi-Ant Versie 6.027

14/20

een parameter ("CyclischRooster", "UrenOfDMFAWijziging", "AanpassenContracten") aanwezig is met waarde 1. Bij het bewaren van de cyclus/roosterinfo gebeurt dan volgende: - als het een bestaande cyclus is - als er velden met uur-info of DMFA-veld-info gewijzigd zijn - als staat ingesteld dat men de contracten wil aanpassen - als er (master)contracten zijn die van de cyclus gebruik maken Er komt een vraag aan de gebruiker of ie de contracten wil aanpassen. Zo ja, dan worden de contracten aangepast. Zo nee, dan kan de cyclus/rooster info niet bewaard worden. B) Schermen voor "gedetailleerde roosteringave" aangepast (rooster-scherm, "dagdeel-scherm", cyclusscherm). Er wordt eveneens bij wijziging van uur-info of DMFA-veld-info bijgehouden dat er een wijziging is aan uur-info of DMFA-veld info. De werking is voor de rest analoog zoals bij het scherm voor "eenvoudige roosteringave": - zelfde parametrisatie om contracten al of niet aan te passen - zelfde controles bij bewaren (bestaande cyclus/rooster, velden met uur-info of DMFA-veld-info gewijzigd...)

1.33. Aanpassing programmatie export naar HDP voor de agro: jobstudenten in de agro werden verkeerd doorgestuurd; niet meer testen op sektie.wswncode = 10 maar checken op parameter die agro-sekties bevat Er zat een probleem in de export naar HDP: jobstudenten in de agro werden niet doorgestuurd met de speciale eigenschappen nodig bij export naar HDP voor de agro-werknemers. Er werd voor de agro bij de export naar HDP getest op sektie.wswncode = 10. De jobstudenten in de agro hebben echter de wswncode van jobstudenten. De export naar HDP is nu aangepast. Voor de agro-werknemers moet bij de export naar HDP het totaal bruto via een bepaalde looncode doorgestuurd worden. Dit totaal bruto wordt binnen Hiant bij de loonberekening via een speciale looncode ingeboekt bij de loonberekening. Om te zien voor welke sektie van uitzendkrachten dit ingeboekt moet worden, wordt parameter ("Loonberekening", "InsertTotaalKodeVoorAgro", "Sekties") gebruikt. Deze parameter wordt nu bij export naar HDP ook gebruikt om te zien welke sekties agro-sekties zijn.


15/20

1.34. Aanpassing binnenhalen webinschrijvingsgegevens: probleem was dat bij binnenhalen webinschrijvingen voor een fiche die reeds binnen Hiant bestaat, het inschrijvingsnr tevoren verloren ging Bij bepaalde uitzendbedrijven is het mogelijk dat een kandidaat nog via een webapplicatie zijn gegevens, die reeds in Hiant bestaan, kan vervolledigen. Bij het binnenhalen van deze webinschrijvingsgegevens voor een fiche die al binnen Hiant bestaat, ging tevoren het inschrijvingsnr bij de inschrijvingsgegevens verloren. De koppelid van de persoon was nochtans niet veranderd. Het inschrijvingsnr, hetgeen men te zien krijgt binnen Hiant, daarentegen veranderde wel. Het probleem was dat, alvorens de info definitief naar Hiant wordt overgehaald, eerst een TUSSENTIJDSE fiche wordt getoond die men al of niet kan bewaren. Deze TUSSENTIJDSE fiche heeft een tijdelijk en ander nummer dan de reeds bestaande fiche. Het inschrijvingsnr wordt bij openen van een fiche binnen Hiant steeds gelijk gezet aan de koppelid (in dit geval de koppelid van de TUSSENTIJDSE fiche). De programmatie van Hiant is nu aangepast zodat, na tonen van de tussentijdse fiche en na bevestigen voor het binnenhalen van de fiche naar Hiant toe, het inschrijvingsnr toch gelijk wordt gezet aan het nummer van de reeds bestaande fiche. Men kan deze werking, die standaard geldt, echter toch niet volgen, door een parameter ("ImportWebSubscribe", "InschrijvingnsrBehoud", "GelijkAanKoppelid") aan te maken met waarde 0.

1.35. In eerste instantie enkel voor HDP-exporters: kunnen aanmaken geboekte niet te exporteren loonrun. Hier kunnen dan geboekte lonen in overgeplaatst worden. Bij de HDP-exporters wilde men een “geboekte, niet te exporteren loonrun” kunnen aanmaken waarin bepaalde lonen kunnen overgeplaatst worden van een andere reeds geboekte loonrun. Dit ingeval men na het boeken (en/of reeds evt. doorsturen gegevens naar HDP) erachter komt dat bv. bepaalde mensen binnen de lonen een verkeerde sektie hebben.

Hiervoor zijn er 2 submenu’s bijgemaakt binnen het “Acties-menu” binnen het loonberekening-scherm: - “maak geboekte, niet te exporteren loonrun” - “plaats loon over naar niet te exporteren loonrun”

“maak geboekte, niet te exporteren loonrun” Er wordt hierbij de gebruiker naar een omschrijving voor deze loonrun gevraagd. De loonrun-tabel krijgt er een eigenschap “NietExporteren” bij, die bij zo’n niet te exporteren loonrun waarde 1 heeft. Bij zo’n “niet te exporteren” loonrun wordt ook onmiddellijk de “datum export naar sociaal secretariaat” ingevuld met de huidige datum en het veld voor het exportbestand wordt ingevuld met “NtExp”. Een loonrun met eigenschap “NietExporteren” kan met niet terug op te exporteren zetten (men kan dus zo’n loonrun niet meer terug “activeren” door “zet op niet geëxporteerd” [manipulatie exportdatum]).


16/20

“plaats loon over naar niet te exporteren loonrun”

Dit menu dient men telkens uit te voeren per uzk die men wenst over te plaatsen naar een niet te exporteren loonrun.

Hierbij wordt er aan de gebruiker de volgende zaken gevraagd: - loonrunnr van de loonrun waarin zich de over te plaatsen uzk bevindt (bron-loonrun) - wnnr van de over te plaatsen uzk Indien de ingegeven uzk zich meermaals in de bron-loonrun bevindt (ingeval Actief is dit normaal gezien niet het geval) wordt aan de gebruiker gevraagd welke periode (week) van de uzk dient overgeplaatst te worden - loonrunnr van de loonrun waarin het loon dient overgeplaatst te worden (doel-loonrun)

Vóór het definitief overplaatsen wordt eerst aan de gebruiker nog wnnr, sektie, naam, voornaam, periode (week/maand) van de over te plaatsen uzk getoond, waarbij de gebruiker evt. kan annuleren. Indien het over te plaatsen loon deel is van een gesplitste week, wordt automatisch ook het loon van het andere weekdeel mee overgeplaatst naar de doel-loonrun. Men kan in zo’n “geboekte, niet te exporteren loonrun” lonen verzamelen van meerdere bron-loonruns. Het maakt niet uit welke combinaties van betaalsystemen, periodes… er allemaal binnen de doel-loonrun terecht komen, vermits deze lonen toch niet meer geëxporteerd moeten worden.

!!!!! Alhoewel men er via deze procedure voor kan zorgen dat men een “fout loon” niet (meer) naar HDP gaat sturen, is het zo dat dit loon wel in Hiant zit en ervoor zorgt dat de cijfers voor de betreffende fysieke persoon niet kloppen (te veel loon in Hiant). Men zou hierbij eigenlijk ook de procedure moeten volgen voor het volledige tegenboeken van het verkeerde loon (“verkeerde loon” wordt op “oud loon” gezet en wordt ook tegengeboekt).

1.36. In eerste instantie enkel voor HDP-exporters: kunnen aanmaken en opvullen geboekte, opnieuw te exporteren loonrun Bij de HDP-exporters wilde men een “geboekte, opnieuw te exporteren loonrun” kunnen aanmaken en opvullen, waarin bepaalde lonen kunnen overgeplaatst worden van een andere reeds geboekte loonrun. Dit ingeval men na het boeken (en/of reeds evt. doorsturen gegevens naar HDP) erachter komt dat bv. bepaalde mensen bij de originele export een verkeerd HDPnr hadden. In dit geval zijn bv. van een loonrun met 50 uzk 49 mensen reeds correct verwerkt bij HDP. Men mag dus niet de volledige loonrun met 50 uzk opnieuw exporteren. Er dient dan een “geboekte, opnieuw te exporteren loonrun” aangemaakt te worden waarin enkel de ene uzk wordt overgeplaatst. Na aanpassen van het HDPnr kan deze uzk dan via de nieuwe loonrun apart opnieuw geëxporteerd worden.

Hiervoor is er een submenu bijgemaakt binnen het “Acties-menu” binnen het loonberekening-scherm: - “aanmaken + opvullen ‘geboekte, opnieuw te exporteren loonrun’ ” Via deze procedure gaat men op basis van een bron-loonrun een nieuwe geboekte, opnieuw te exporteren loonrun aanmaken waarin een deel van de lonen van de bron-loonrun terecht komen.


17/20

Een nieuwe doel-loonrun wordt zo altijd aangemaakt op basis van slechts één bron-doelrun. Op deze manier vermijden we dat er in een doel-loonrun allerlei combinaties van betaalsystemen, periodes… terechtkomen.

Hierbij wordt er aan de gebruiker de volgende zaken gevraagd: - loonrunnr van de loonrun waarin zich de over te plaatsen uzk bevindt (bron-loonrun) - opsommen van de wnnr’s die overgeplaatst dienen te worden (ingeven van de wnnrs gescheiden door komma). De wnnrs worden erna één voor één overlopen. Indien een bepaalde wnnr niet wordt gevonden bij de lonen met status 0 (laatste lonen) wordt de boodschap “uzk… is niet gevonden binnen de loonrun met status 0. Deze uzk wordt overgeslagen. Doorgaan?”. Bij de ja-keuze wordt deze uzk overgeslagen. Bij de nee-keuze wordt er gestopt. Erna wordt eerst nog eens de volledige lijst van wnnr, sektie, naam, voornaam van de opgegeven uzk getoond. De gebruiker kan hier nog annuleren. Erna worden de opgegeven uzk nogmaals één voor één overlopen. Indien een ingegeven uzk zich meermaals in de bron-loonrun bevindt (ingeval Actief is dit normaal gezien niet het geval) wordt er voor deze uzk aan de gebruiker gevraagd welke periode (week) van de uzk dient overgeplaatst te worden. Er wordt hierbij ook gechecked voor elke wnnr (en evt. apart opgegeven periode) of het betreffende loon een herziening-loon is. Ingeval van een herziening-loon wordt de procedure gestopt. Overzetten van herziening-lonen wordt niet toegelaten. Indien er in de bron-loonrun voor de opgegeven uzk (en evt. apart opgegeven periode) gegevens van een gesplitste week zitten, wordt ook automatisch een loonrun aangemaakt voor het 2e weekdeel en worden de lonen van het 2e weekdeel voor de betreffende uzk hierin ook overgeplaatst. Standaard krijgt de doel-loonrun als naam de naam van de bron-loonrun + “ herexport”. Deze omschrijving wordt voorgesteld aan de gebruiker, die deze omschrijving kan wijzigen.

1.37. Mogelijkheid dat bepaalde gebruikers niet enkel de actieve cyclus en roosters kunnen selecteren in (master)contract, maar alle van toepassing zijnde cycli en roosters Indien er in de bron-loonrun voor de opgegeven uzk (en evt. apart opgegeven periode) gegevens van een gesplitste week zitten, wordt ook automatisch een loonrun aangemaakt voor het 2e weekdeel en worden de lonen van het 2e weekdeel voor de betreffende uzk hierin ook overgeplaatst. Er bestaat nu de mogelijkheid dat bepaalde gebruikers alle van toepassing zijnde (niveau ALG of horend bij kl/wn combinatie) cycli/roosters in (master)contract kunnen kiezen ipv enkel de actieve. Dit is vooral voor Securex-exporters interessant (waarbij cyclus en rooster info wordt doorgestuurd) – een programmeur kan dan bv. nog bepaalde fouten gemaakt door de gebruiker rechttrekken (andere cyclus/roosters selecteren). (Het is wel zo dat binnen subcontracten men enkel de cyclus en roosters krijgt te zien die in het mastercontract zijn gekozen. Dus men zou in dit geval eerst cyclus en rooster in mastercontract dienen te wijzigen, waarna men andere roosters in subcontracten kan kiezen).


18/20

Om alle cycli en roosters te kunnen kiezen, dient men voor deze gebruikers een parameter ("cyclischrooster", "NietEnkelAutoCreate", "*") aan te maken met waarde 1.

1.38. Voornamelijk voor Securex-exporters: menu “contracten bepaalde duur – wijzig cyclus-roosters” Sinds kort is het zo (standaard voor Securex-exporters) dat men cycli-roosters niet meer kan aanpassen indien de cyclus gebruikt is binnen contracten die al een wnbetaalperiodestatus hebben. Dit zou een probleem gaan opleveren voor de contracten bepaalde duur (losstaande weekcontracten) indien voor een uzk de uren zouden gaan veranderen: men kon een bestaande cyclus-roosters niet afsluiten en een nieuwe set cyclus-roosters aanmaken. Daarom is er een menu “acties/contracten bepaalde duur – wijzig cyclus-roosters”. Men kan, met ingang van een bepaalde datum een nieuwe cyclus en bijhorende roosters aanmaken. De werkwijze is als volgt: Er moet een contract staan geselecteerd - de actie wordt uitgevoerd voor de kl-wn combinatie van het geselecteerde contract. Hierbij wordt er gevraagd naar een begindatum vanaf wanneer deze wijziging ingaat. Er wordt dan gecontroleerd of er al contracten bestaan vanaf deze begindatum Als er al contracten bestaan vanaf de nieuwe begindatum: ---------------------------------------------------------------------------------- Als er al contracten bij zijn die verloond zijn, is dit niet mogelijk. Procedure wordt gestopt. - Er wordt aan de gebruiker gevraagd of de cyclus en roosters in de bestaande contracten aangepast mogen worden. Indien de gebruiker “ja” antwoordt, wordt er verder gegaan. Indien de gebruiker “neen” antwoordt wordt de procedure ook gestopt. - de bestaande cyclus en roosters worden inactief gezet - er wordt een nieuwe cyclus en roosters aangemaakt, in eerste instantie als kopie van de bestaande cyclus en roosters. Vervolgens wordt een tussenscherm getoond waarbij de nieuwe cyclus en roosters kunnen aangepast worden - bij de contracten die al bestaan vanaf de nieuwe begindatum wordt de cyclusid, roosterid aangepast – rooster wordt aangepast naar het rooster met hetzelfde volgnr binnen de nieuwe cyclus (en ook contract-roosterinfo en DMFA-info overeenkomend met de cyclus en rooster). Als de nieuwe cyclus minder roosters met uren bevat, dan wordt bij een bepaald roostervolgnr (dat geen uren heeft binnen de nieuwe cyclus) het rooster genomen met de hoogste volgnr dat wel uren heeft. Als er nog geen contracten bestaan vanaf de nieuwe begindatum: -------------------------------------------------------------------------------------------- de bestaande cyclus en roosters worden inactief gezet - er wordt een nieuwe cyclus en roosters aangemaakt, in eerste instantie als kopie van de bestaande cyclus en roosters. Vervolgens wordt een tussenscherm getoond waarbij de nieuwe cyclus en roosters kunnen aangepast worden - dan wordt een contract aangemaakt voor de betreffende kl-wn met als week de week waarin de begindatum voor de nieuwe cyclus-roosters ligt. Dit contract is een kopie van het laatste contract dat bestond voor de nieuwe begindatum. Wel wordt natuurlijk de nieuwe cyclus ingevuld.


19/20

Het rooster dient wel nog gekozen te worden. De gebruiker dient nog de keuze te maken met welk rooster hij het nieuwe contract wil laten beginnen.

1.39. Controle ingebouwd op “dubbele lonen” bij berekenen van lonen: het berekenen van lonen blokkeert indien 1) de uzkperiode combinatie meermaals voorkomt bij de te berekenen lonen en 2) indien de uzk-periode combinatie voorkomt bij te berekenen lonen en reeds geboekt loon Het kwam af en toe voor dat er bij een uitzendbedrijf lonen dubbel voorkwamen. Er is nu een controle ingebouwd, bij het berekenen van de lonen, die dubbele lonen moet voorkomen. Het bereken van lonen blokkeert indien: 1) de uzk-periode combinatie meermaals voorkomt bij te berekenen lonen (aantal in loonruntebereken tabel > 1) 2) de uzk-periode combinatie voorkomt bij te berekenen loon en reeds geboekt loon (aantal uit loonrunteberekenen tabel en loon-tabel bij status 0 > 1) Deze controle neemt dus: - alle loonrunteberekenen bij dezelfde jaar, systeem, periode, wnnr - de loon-lijnen bij dezelfde jaar, systeem, periode, wnnr * bij gesplitste lonen worden deze lonen niet als 2 lijnen geteld (neemt per combinatie van de lonen slechts de min(loonrunnr) ) * bij een herziening, zolang een herziening niet geboekt, wordt het vorige loon niet als een loon geteld (binnen wnbetaalperiodestatus met status 0 staat nog de vorige loonid van weekdeel 1 binnen loonbriefnr; van deze ene loonid bepalen we de loonrungroep [lonen die bij elkaar horen bij gesplitste week]; de lonen die deze loonrungroep hebben nemen we niet mee [vorige lonen die nog status 0 hebben zolang herziening niet is geboekt] ) De controle is af te zetten door parameter ("scherm", "frmloonber", "ControleDubbelLoon") aan te maken met waarde 0.


20/20

11

Recommend Documents