04

Release Notes Afdrukdatum: 2012/09/04

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

1/14

1.

V6.028 1.1.

Bugfixes 1.1.1. Bugfix – Verplichte attesten bij contracten in de bouw De controle op vereiste attesten gaf niet altijd een boodschap indien een contract niet werd aangemaakt bij het overhevelen. De contracten werden correct NIET aangemaakt, maar de gebruiker kreeg hiervan geen feedback zodat hij geen idee heeft van de niet aangemaakte contracten. Dit is nu opgelost.

1.1.2. Beheer koppeltabellen – CDKey Beperkingen op niveau van USER werden verkeerd toegevoegd in de tabel, er werd namelijk de naam & voornaam weggeschreven i.p.v. de username uit de personeelstabel, hierdoor werden deze niet correct uitgelezen en had de beperking geen effect.

1.1.3. Controles jobstudenten vóór 2012 Wanneer je een contract vanuit 2011 zou kopiëren naar 2012 werden de oude controles nog steeds uitgevoerd, met als gevolgd dat je bepaalde contracten niet zou kunnen aanmaken. Deze controles zijn nu standaard uitgeschakeld. Indien je in heel uitzonderlijke gevallen toch nog een contract jobstudent 2011 zou moeten aanmaken kan je best eerst parameter "Controle", "Contracten", "JobstudentenVoor2012" aanmaken met waarde 1 om deze controle (tijdelijk?) terug te activeren.

1.1.4. Facturatie herzieningen – filteren op datum Door een bug kon je niet meer filteren op datum. Dit is nu opgelost.

1.1.5. Bugfix: Ticket 88035: Dagoverzicht geeft foutmelding bij jobstudenten in de bouw Indien er jobstudenten in de bouw tewerkgesteld worden, geeft Hiant hier de foutmelding ‘Foutieve sektie’ omdat dit document nog niet voorzien is op jobstudenten in de bouw. Deze studenten worden dus ook niet meegeteld. Dit is nu aangepast. Indien de sectie eindig op 10, wordt de werknemer ook meegeteld met de studenten.

1.1.6. Bugfix: Ticket 87860: Foutmelding bij opstarten zoekmodule Foutmelding “Error converting datatype varchar to numeric Query in de code die convert(param2,decimal) deed en dit lukte niet altijd. Code aangepast zodat de test op param2 > 2 later in de code gebeurd.

1.1.7. Bugfix: controle op bankrekeningnummer werd niet uitgevoerd indien de “kode betaling” niet ingevuld was Er kwamen bij uitzendbedrijven uzk-fiches voor waarbij het bankrekeningnummer niet klopte.


2/14

Volgende was het probleem: De controle op het bankrekeningnr werd uitgevoerd als: - uzk woont in België - de kode betaling niet voorkomt bij "betalingskodes waarbij banknr leeg mag zijn" Als de parameter "betalingskodes waarbij banknr leeg mag zijn" leeg was en de kode betaling was niet ingevuld, dan klopte deze test niet helemaal er werd geen controle uitgevoerd op het bankrekeningnr. De test om te bepalen of het bankrekeningnr moet gecontroleerd worden is nu aangepast naar: - uzk woont in België - de kode betaling komt niet voor bij "betalingskodes waarbij banknr leeg mag zijn" OF de betalingskode is leeg

1.1.8. Bugfix – indien menu “contracten bepaalde duur – wijzig cyclusroosters” (vooral voor Securex-exporters) werd gebruikt, werden er bij de nieuw aangemaakte contracten geen nieuwe SecurexNrs toegekend Er was nog een probleem bij uitvoeren menu “contracten bepaalde duur”: bij de nieuw aangemaakte contracten werd er geen nieuw SecurexNr toegekend. Het SecurexNr werd overgenomen van het broncontract. Met als gevolg dubbele SecurexNrs – hetgeen een probleem vormde. De programmatie is aangepast zodat bij uitvoeren menu “contracten bepaalde duur – wijzig cyclus-roosters” bij de nieuw aangemaakte contracten nu een nieuw SecurexNr wordt toegekend.

1.2.

Bestellingenlijst: gebruik steunkantoren UZK ipv steunkantoren algemeen

Door parameter "scherm", "frmbestellst", "gebruikSteunkantorenUZK" aan te maken met waarde 1 kan je er voor zorgen dat HiAnt niet de algemene steunkantoren gebruikt maar de steunkantoren UZK bij het opbouwen van de lijst van bestellingen.

1.3.

Ticket 86455 – Logging Blokkeren dimona’s

Er is een nieuwe logtype 105 gemaakt waarbij wordt gelogd wie wanneer welk contract op dimonastatus Blocked zet of deblokkeert. De logging staat standaard uit maar kan geactiveerd worden door parameter "Dimona", "ManualBlock", "LogChanges" aan te maken met waarde 1.

1.4.

Ticket 87530 – Minimumleeftijd kandidaten

Deze controle blokkeert bij het inschrijven, maar iemand die NU 14 jaar is en in augustus wil werken (wanneer hij dus effectief 15 jaar is) kan nog niet in HiAnt ingegeven worden. De controle werd aangepast als volgt: - inschrijving is toegestaan indien de persoon 15 wordt in het jaar van inschrijving. - bij maakUZK wordt er een waarschuwing getoond indien de persoon nog geen 15 is. - het maken van een contract wordt geblokkeerd indien de werknemer geen 15 is op de begindatum van het contract.


3/14

1.5.

Bewaren van aantal km in distance tabel

Wanneer bij berekenen van de aantal kilometers tussen 2 punten, deze nog niet gevonden werd in de distance tabel, wordt een nieuwe record aangemaakt. Standaard is de database ingesteld op 2 cijfers na de komma nauwkeurigheid wat wil zeggen tot op 10 m nauwkeurig. Wanneer er echter een afstand was minder dan 10 m werd bij de eerste keer de berekening gedaan op de niet afgeronde waarde. Bij het opslaan in de db werd dit dan wel afgerond waardoor aantal km op 0 kwam te staan. Aanpassing is gebeurd zodat bij berekenen van aantal km de gevonden km wordt afgerond op de instelling van het veld in de db, zodat dit niet meer kan voorkomen.

1.6.

Aanmaak nieuwe fakturatierun – klikken op annuleren

Wanneer men een nieuwe fakturatierun wenst aan te maken door op ‘+’ knop te klikken, en men zou deze actie onderbreken door op annuleren te klikken, werd achterliggend een variable die bijhoudt welke run actief is, op 0 gezet. Wanneer men dan een actie ging doen op een run, zonder eerst een run terug te selecteren werd deze in de tabellen toegevoegd als fakturatierun 0. Aanpassing is gebeurd dat na het openen van het scherm voor toevoegen van een fakturatierun de grids opnieuw worden geïnitialiseerd. Ook op databaseniveau via checkdatabase wordt een controle gelegd op het veld fakturatierunnr in tabel fakturatierunteberekenen en op veld FR in faktuurtransaktie dat deze groter dan 0 moet zijn.

1.7.

Boeken van lonen – controle fakturatie

Stel volgend scenario. Er worden lonen berekend en geboekt voor bepaalde klant. Deze lonen worden opgenomen in een fakturatierun en berekend (nog niet geboekt). Vervolgens worden nieuwe bijkomende lonen berekend en geboekt voor dezelfde klant en periode. In fakturatiescherm wordt de faktuur in transaktie geboekt -> gevolg was dat de nieuwe bijkomende lonen ook werden aangeduid als zijnde gefaktureerd, terwijl deze niet op de faktuur te vinden zijn. Daarom is een controle toegevoegd die ook al gebeurde bij klikken op herziening van prestaties/premies. De controle is standaard geactiveerd volgens de reeds bestaande parameter "Initialisatie", "Facturatie", "ControleRecalculate", "1" (standaard = 1 betekent controle gactiveerd). Indien er tijdens boeken van lonen de klanten die in deze lonen zitten in een openstaande fakturatierun staan, wordt het veld recalculate in fakturatierunteberekenen bij deze klant op 1 gezet. Hierdoor kan men deze faktuartierun niet boeken en dient men dus deze opnieuw te berekenen om alzo zeker te zijn dat alle geboekte lonen van de werknemers bij die klant ook op de faktuur komen te staan. Deze actie wordt ook gelogd in de logtable met type '109','Recalculate facturatierun na boeken loon'

1.8.

Toevoegen manuele faktuur aan fakturatierun – errorhandler

Foutafhandeling juist toegevoegd bij procedure toevoegen van manuele faktuur. Indien fout gebeurt zal gebruiker melding krijgen en zal niets bewaard worden.

1.9.

Berekenen sociaal abonnement type 2 (klantspecifieke aanpassing)

Er wordt bij berekenen van sociaal abonnement gezocht naar de klant EN de kostenplaats bij deze persoon. Aanpassing is gebeurd, indien deze combinatie geen record teruggeeft, wordt er enkel gezocht op de klant zonder rekening te houden met de kostenplaats

1.10. Prestatieingavescherm shift+F5 (klantspecifieke aanpassing) Indien men de parameter initialisatie", "frmprestgeg2", "GebruikKlantIpvAfdeling", "0" op 1 instelt zal de lookupbox van de afdeling veranderen naar een lookupbox van de klanten. Release Notes Hi-Ant Versie 6.028

4/14

Ook zal in het overzicht van de presaties en premies op de plaats waar normaal de afdeling staat, de naam van de klant getoond worden. Bij toevoegen van prestaties zal de kl.id ingevuld worden in de prestaties.prestatiesklid Bij toevoegen van premies zal de kl.id ingevuld worden in de premies.premiesklid De ingave van de klant is verplicht. Bij veranderen van de klant, zullen ook de actieve kostenplaatsen van die klant worden ingesteld in de lookupbox van de kostenplaatsen.

1.11. Debiteurenbeheer – mailen van rekeningoverzicht -

“initialisatie”,”debiteuren”,”mailmetpdfbijlage”,”0” -> ingesteld op 1, hierdoor wordt de module geactiveerd.

-

“initialisatie”,”debiteuren”,”pathmetpdfbijlage”,”” -> ingesteld op “\\goliath\@@@\hoofdkantoor\Rekeningoverzicht - Extrait de compte”.

-

“initialisatie”,”debiteuren”,”mailBCC”,”” -> ingesteld op “finance@@@@.be” , hierdoor wordt deze mail ook verzonden in BCC naar dit adres.

-

“initialisatie”,”debiteuren”,”mailAfzender”,”” -> ingesteld op “finance@@@@.be” , hierdoor wordt deze mail verzonden met afzender van dit adres.

-

“initialisatie”,”debiteuren”,”mailAfzender”,”0” -> ingesteld op “10”, dit bepaald welk sjabloon er moet gebruikt worden. Dit kan men instellen in HiAnt onder menu gegevens – instellingen – beheer – beheer HTML mailings

Werking : -

Vanuit het debiteuren scherm kan men een klant selecteren, vervolgens via menu acties – “stuur geselecteerde klant rekeningoverzicht per mail” of via ctrl+S.

-

HiAnt zoekt de klant op en kijkt of er een geldig email adres is ingevuld in de hoofdfiche EN zoekt in de contactpersonen van de klant of er contactpersonen zijn waarbij het vinkje “ontvanger aanmaningen” is aangevinkt en een geldig email adres is ingevuld.

-

Indien geen email adressen gevonden, stopt de procedure

-

Indien één of meerdere email adressen gevonden, dient de gebruiker het email adres te selecteren uit een lijst.

-

HiAnt gaat zoeken naar de pdf in de vorm van ANM00000000 (ANM + klantnummer in 8 cijfers). Indien bijlage niet gevonden kan er geen mail verstuurd worden.

-

Afhankelijk van de taal van de klant wordt de mail opgesteld in NL of FR.

-

Er wordt gebruik gemaakt van HTML-mailing, waarbij in de HTML de volgende parameters kunnen opgenomen worden • %TEXT% -> wordt vervangen door de nl/fr tekst die is ingesteld in de HTMLmailing • %TITLE% -> wordt vervangen door de nl/fr titel die is ingesteld in de HTMLmailing • %DATE% -> wordt vervangen door de systeemdatum


5/14

-

Indien de mail verstuurd is, is er een mogelijkheid om een opvolging toe te voegen voor deze klant. Hiervoor dienen de volgende parameters ingesteld te worden : • "Scherm", "FrmklGeg1", "OpvolgingContactTypeId", "0" -> bepaalt contacttypeid dat gebruikt dient te worden voor aanmaak van opvolging • "codeboekcode", "debiteuren", "opvolgingtypeid", "" -> bepaalt typeid van de aan te maken opvolging • "codeboekcode", "debiteuren", "opvolgingDetailtypeidRekMail", "" -> bepaalt detailtypeid van de aan te maken opvolging

-

Enkel indien bovenstaande parameters allemaal zijn ingevuld zal er een automatische opvolging worden geregistreerd.

1.12. Debiteurenbeheer instellen van onderverdelingen Vanaf nu is het mogelijk om de onderverdelingen van de dagen vervallen in het debiteurenoverzicht uit te breiden mbv parameters. Het systeem zoek in de parameters naar de records met Param1='initialisatie' and param2='debiteuren' and param3 like 'dagen%' Deze worden gesorteerd volgens de waarde. Standaard zijn de volgende parameters ter beschikking: “Initialisatie”,”debiteuren”,”dagenX”,”30” “Initialisatie”,”debiteuren”,”dagenY”,”60” Wat resulteert in de volgende onderverdelingen : -

Meer dan 30 en maximum tot 60 dagen vervallen Meer dan 60 dagen vervallen

En volgende filter mogelijkheden :

Indien men bv. volgende parameters zou aanmaken “Initialisatie”,”debiteuren”,”dagen0”,”10” “Initialisatie”,”debiteuren”,”dagen1”,”20” “Initialisatie”,”debiteuren”,”dagen2”,”30” Zal men in het overzichtsscherm debiteuren een onderverdeling hebben - Meer dan 10 en maximum tot 20 dagen vervallen - Meer dan 20 en maximum tot 30 dagen vervallen - Meer dan 30 dagen vervallen Ook zal onderaan deze filtermogelijkheden te zien zijn :

OPGELET : dit is enkel van toepassing in het tabblad Debiteurenoverzicht. In het tabblad aanmaningen is enkel de standaard onderverdeling tussen 2 in te stellen dagen beschikbaar via de parameters “Initialisatie”,”debiteuren”,”dagenX”,”30” “Initialisatie”,”debiteuren”,”dagenY”,”60”


6/14

1.13. Debiteuren beheer – kleuren van rijen op basis van waarde in kolom Er is een uitbreiding gebeurd om de kleuren te bepalen indien in bepaalde kolom een waarde groter dan 0 is ingegeven Dit is in te stellen met de parameters “initialisatie”,”debiteuren”,”Kleurkolom%” Zie een voorbeeld hieronder

De parameters worden ingelezen volgens dalende kolomnummer (numerieke gedeelte achter KleurKolom). De waarde bevat de RGB code die gebruikt dient te worden indien er in deze kolom een bedrag groter dan 0 is gevonden. Er wordt vertrokken van de hoogste kolomnummer. Indien in die kolomnummer een bedrag groter dan 0 is gevonden, zal de rij kleuren volgens de insgestelde RGB waarde in de parameter. Indien niet groter dan 0 zal naar de lagere kolomnummer gekeken worden. Indien geen enkele kolom met waarde >0 is gevonden kleurt de rij groen. Indien parameters niet aanwezig zijn is de standaard kleuring van toepassing -

Indien saldo +YD >0 -> rood Indien saldo +XD-YD>0 -> geel Indien saldo +XD >0 -> oranje Anders groen

1.14. Nieuwe AfdrukModule – Splitsen taal documenten Parameter : "Afdrukmodule", #DOCUMENT#, "SplitsTalen" (Standaard waarde = 0 UIT) #DOCUMENT# staat voor het document Vb WPF, UZKCONTRACT, KLCONTRACT, PRESTATIEFORMULIER Zodra men via de afdrukmodule een document op het scherm krijgt en deze wil sturen naar de printer zal hij standaard alle documenten naar 1 printer sturen. Indien men 2-talig voorgedrukt papier gebruikt kan deze parameter ervoor zorgen (Waarde = 1) dat hij de Nederlandse en franse documenten zal scheiden en de gebruiker vraagt de betreffende printer te selecteren waar het bijhorende papier zich bevind.

1.15. Ticket 86775 - publicatie bestellingen Parameter "Bestellingen", "MenuOverzichten", "Publicaties" standaard waarde 0 = UIT Bij activate (waarde = 1) zullen er bij het menu Overzicht 3 extra menu items getoond worden - Bestellingen 1 kanaal - Bestellingen aantal dagen gepubl - Bestellingen aantal dagen gedepubl


7/14

1. Bestellingen 1 kanaal Het systeem toont alle bestellingen die slechts gepubliceerd zijn aan 1 kanaal: - of eigen website - of VDAB Er wordt een scherm geopend met idem dezelfde filters en kolommen als heden bij “export bestellingen”. 2. Bestellingen aantal dagen gepubl Het systeem gaat ervan uit dat “heden (vandaag)” telt als basis om te tellen. Er wordt een scherm geopend met idem dezelfde filters als heden bij “export bestellingen”. Hierin is reed bepaald dat enkel actieve bestellingen worden getoond. In het zoekresultaat komt naast de kolom “publstart” een extra kolom “aantal dagen begin”. In deze extra kolom wordt geteld: het aantal dagen tussen “heden” en “datum publstart” 3. Bestellingen aantal dagen gedepubl Het systeem gaat ervan uit dat “heden(vandaag)” telt als basis om te tellen. Er wordt een scherm geopend met idem dezelfde filters als heden bij “export bestellingen”. Hierin is reed bepaald dat enkel actieve bestellingen worden getoond. In het zoekresultaat komt naast de kolom “publeinde” een extra kolom “aantal dagen einde”. In deze extra kolom wordt geteld: het aantal dagen tussen “heden” en “datum publeinde”

1.16. Ticket 86252 – klantspecifieke functionaliteit Parameter "scherm", "frmPlanKalender", "PrintVeiligheidsfiche" Vanuit het planningscherm – menu Print heeft men de mogelijkheid om een veiligheidsfiche af te drukken voor de werknemers die zijn opgenomen in de selectie linksaan het scherm.


8/14

Het document “Veiligheidsfiche” wordt vervolgens via de nieuwe AfdrukModule gegenereerd. Deze zal dan ook via de nieuwe Crystal Reports manier afgedrukt worden. Prato heeft een standaard sjabloon ter beschikking maar het is natuurlijk mogelijk om van deze af te wijken in overleg met Prato. Vertalingen Voor de prestatieformulieren zijn dit ALLE vertallingen uit de vertaal en vertaaluzb tabel die beginnen met VF_. De taal van het document kan worden bijgestuurd via de getDocutaal functie van de module.

1.17. Ticket 85247 - Cv : contactpersoon Via de parameter "afdruk", "WordCV", "ToonContactPersoonHiant" (standaard 0 = UIT) zal bij de waarde 1 = AAN de naam van de gebruiker staan in het header gedeelte van het FAX onderdeel bij een CV. Hiervoor is da laatste versie van WordRap.exe nodig.


9/14

1.18. Export facturen type MTV2 : aparte dagboekcode voor export facturen In de export naar de boekhouding, type MTV2, kan men nu de gegevens naar een apart dagboekcode exporteren met de parameter : Export, Factuur, MTV2dagboekcode, VF De standaard waarde van het dagboek is dus : VF Het maximaal aantal tekens voor deze dagboekcode is 3. Indien er meer tekens worden ingegevens worden enkel de 3 rechtste tekens gebruikt voor de export.

1.19. Export lonen type MTV1 : aparte dagboekcode voor export lonen In de export naar de boekhouding, type MTV1, kan men nu de gegevens naar een apart dagboekcode exporteren met de parameter : Export", "Loon", "MTV1dagboekcode", "LON" De standaard waarde van het dagboek is dus : LON Het maximaal aantal tekens voor deze dagboekcode is 3. Indien er meer tekens worden ingegevens worden enkel de 3 rechtste tekens gebruikt voor de export.

1.20. Export BOB CS Het is nu ook mogelijk om met de volgende parameter het decimaal scheidingsteken in te stellen : Export, bobcd, decimalsign,”.” Het decimaal scheidingsteken staat standaard op een punt en is van toepassing voor alle gegevens van het numerisch type. (“N”)


10/14

1.21. Programmatie “zet op te berekenen” en “zet klant op te berekenen” aangepast binnen beide prestatie-ingaveschermen: vermijden dat er dubbel wnbetaalperiodestatus-lijnen met volgnr 0 voorkomen indien dit tegelijk wordt uitgevoerd door meerdere gebruikers Er zijn testen gebeurd: indien meerdere gebruikers tegelijkertijd “zet klant op te berekenen” en/of “zet op te berekenen” (voor 1 uzk) uitvoeren, konden er dubbele wnbetaalperiodestatuslijnen voorkomen met volgnr 0. De programmatie binnen beide prestatie-ingaveschermen is aangepast, zowel bij "zet op te berekenen" als bij "zet klant op te berekenen": bij het “insert”-commando voor de wnbetaalperiodestatus zelf wordt nu getest dat er niet al een wnbetaalperiodestatus met volgnr 0 bestaat voor de betreffende combinatie.

1.22. Loggen naar logtable bij toevoegen eerste loon/herziening aan loonrun, bij “automatisch wnbetaalperiodestatus op -1 zetten” en bij verwijderen lijnen uit loonrun Sporadisch traden er problemen op met uzk die dubbel in de lonen terecht kwamen. Om zo’n probleem beter te kunnen onderzoeken, zijn er nu bijkomende loggings naar logtable toegevoegd: 1) Loggen bij toevoegen van eerste loon en herziening aan een loonrun Zowel bij toevoegen van een eerste loon aan een loonrun als bij toevoegen van een herziening aan een loonrun, wordt dit nu gelogd. Beide worden gelogd in de logtable bij type 106 (“Toevoegen aan loonrun”) met volgende velden: Param1 = loonrungroep. Loonrungroep wordt genomen ipv loonrunnr, omdat bij splitsen van lonen de loonrunnr kan verschillend zijn van de loonrun waarin de lonen oorspronkelijk zijn toegevoegd. De loonrungroep blijft echter gelijk (beide loonruns van een gesplitste week hebben dezelfde loonrungroep. Param2 = jaar Param3 = systeem Param4 = periode Param5 = wnnr Param6 = Type loon (H = herziening; L = eerste loon) Param7 = begindatum week Param8 = einddatum week Param9 = “Wherestring selectie”. Hier verschijnt dan een stuk query, bij eerste lonen, gebruikt bij toevoegen van uzk aan de loonrun. Dit zijn de voorwaarden ingegeven door de gebruiker – voorwaarden op wgnr, klnr, wnnr, sektie.

2) Loggen bij “automatisch wnbetaalperiodestatus op -1 zetten” Soms treedt het probleem op dat er een wnbetaalperiodestatus 0 voorkomt bij eerste lonen, terwijl er de betreffende combinatie niet voorkomt binnen een loonrun. In dit geval wordt automatisch de wnbetaalperiodestatus terug op -1 gezet. Nu wordt dit “automatisch wnbetaalperiodestatus op -1 zetten” ook gelogd naar de logtable Dit wordt gelogd in de logtable bij type 107 (“Wnbetaalperiodestatus automatisch terug op -1 gezet”) met volgende velden: Release Notes Hi-Ant Versie 6.028

11/14

Param1 = jaar Param2 = systeem Param3 = periode Param4 = wnnr 3) Loggen bij Verwijderen uit loonrun Er wordt nu ook gelogd als er lijnen verwijderd worden uit een loonrun. Dit wordt gelogd in de logtable bij type 108 (“Verwijderen uit loonrun”) met volgende velden: Param1 = loonrungroep. Loonrungroep wordt genomen ipv loonrunnr, omdat bij splitsen van lonen de loonrunnr kan verschillend zijn van de loonrun waarin de lonen oorspronkelijk zijn toegevoegd. De loonrungroep blijft echter gelijk (beide loonruns van een gesplitste week hebben dezelfde loonrungroep. Param2 = jaar Param3 = systeem Param4 = periode Param5 = wnnr Param6 = Type loon (H = herziening; L = eerste loon)

1.23. Op einde loonberekening controle op MC-codes - als 1) een MCcode mist (bv. 653 en 2001 aanwezig en geen 2002) of 2) de aantallen van de MC-codes komen niet overeen of 3) bruto WNbijdrage <> netto, dan loon van uzk op niet berekend zetten Tevoren was het zo dat, als er iets scheelde met de door de gebruiker manueel ingegeven maaltijdcheques, men een berekende loonrun kon boeken. Men kreeg dan na het boeken wel de melding dat er een aantal maaltijdcheques niet geboekt waren. Een uitzendbedrijf dat zelf de maaltijdcheque-bestellingen doet (op basis van de maaltijdcheques-tabel) kan dan evt. nog aanpassingen doen aan de maaltijdcheques. De MC-codes zijn dus wel geboekt naar de lonen. Bij HDP-exporters worden de MC-codes uit de lonen doorgestuurd naar HDP en HDP doet dan de bestelling van de maaltijdcheques op basis hiervan. Ook is het zo dat, als bv. een manueel ingegeven werknemersinhouding niet klopt (2001 – 653 <> 2002), dat de werknemersinhouding in de lonen dus mis is en bijgevolg ook het netto van de uzk.

De programmatie is nu aangepast zodat na de loonberekening een controle wordt gedaan op de MC-codes. Deze controle wordt uitgevoerd PER CONTRACT. Als 1) een MC-code mist (bv. 653 en 2001 aanwezig en geen 2002) of 2) de aantallen van de MC-codes komen niet overeen of 3) bruto - WNbijdrage <> netto dan wordt het loon van de betreffende uzk op niet berekend gezet. Men krijgt zo'n loonrun dan ook niet geboekt, omdat niet alle lonen berekend zijn. Men dient dus eerst de premies voor deze uzk aan te passen en terug het loon te berekenen. Deze controle op de MC's is af te zetten door parameter ("Scherm", "frmloonber", "controleerMC") aan te maken met waarde 0.


12/14

1.24. Aanpassing programmatie achter menu “Studenten > Overzicht gewerkte dagen” Binnen de programmatie achter menu “Controlelijsten/Studenten/Overzicht gewerkte dagen” zaten er nog een aantal zaken niet hemaal in orde zodat deze controlelijst niet altijd de correcte gegevens toonde. Deze controlelijst is nu aangepast. Volgende is veranderd: 1) Voor "NogTeVerlonen" en "ReedsVerloond" worden enkel contractgegevens resp. lonen genomen gelegen vanaf datum jobstudent-attest. Dit was tevoren niet zo (ook contractgegevens en loongegevens van voor datum jobstudentattest). 2) Tevoren werden enkel contractgegevens en loongegevens genomen gekoppeld aan contracten met einddatum gelegen VOOR DE HUIDIGE DATUM. Dit is nu niet meer zo. Als er al contracten bestaan >= huidige datum waarvoor de dimona is uitgevoerd, dan verschijnen deze mee in het overzicht.

1.25. Aanpassing programmatie menu “contracten bepaalde duur – wijzig cyclus-roosters” (vooral voor Securex-exporters): zorgen dat het nieuw aangemaakte contract altijd begint op maandag en eindigt op zondag (indien broncontract, bij splitsweek, geen 7 dagen bevat) Bij uitvoeren van de procedure "contracten bepaalde duur - wijzig cyclus/roosters" (vooral voor dienstenchequers bij Securex-exporters) werd het nieuw aangemaakte contract niet altijd aangemaakt met een duur van een volledige week. Dit gebeurde als het broncontract in een splitsweek lag. Tevoren werd begindatum en einddatum nieuwe contract bepaald door bijtellen 7 dagen bij de datums van het uitgangscontract. Dit was een probleem indien het "te kopiëren contract" in een gesplitste week viel. Het nieuw aangemaakte contract, dat dan niet in een splitsweek viel, bevatte dan geen 7 dagen. Deze werkwijze is nu aangepast. Bij uitvoeren van de procedure "contracten bepaalde duur - wijzig cyclus/roosters" wordt de gebruiker altijd gevraagd naar een begindatum voor het nieuwe contract. De opgegeven begindatum wordt nu gezocht binnen de betaalperiodes voor weekverloning. De begindatum voor het nieuwe contract is dan de begindatum van de gevonden week. De einddatum voor het nieuwe contract valt 6 dagen na de begindatum voor het nieuwe contract.

1.26. Bijkomende controle bij export naar Securex: er kan niet geëxporteerd worden indien er bij de “losstaande contracten” dubbele SecurexNrs voorkomen Programmatie aangepast en getest. Als lonen worden geëxporteerd, wordt er gechecked op "SecurexNrs die dubbel voorkomen, gebaseerd op de SecurexNrs die voorkomen binnen de contracten waarvan de lonen moeten geëxporteerd worden".


13/14

Als enkel signaletiek moet worden geëxporteerd, wordt er gechecked op "SecurexNrs die dubbel voorkomen, gebaseerd op de SecurexNrs van de contracten die vallen in de periode die we meenemen voor export signaletiek".

1.27. (Securex-exporters) Bij “Acties/Beheer mastercontract/maak nieuwe periode aan/kiezen welke aanpassingen men wil doen” gezorgd dat het kiezen van meerdere selecties correct werkt Deze aanpassing heeft enkel voor Securex-exporters invloed. De Securex exporters hebben voor de mastercontracten een menu “Acties/Beheer mastercontract”. Hierbinnen kan men kiezen voor “Maak nieuwe periode aan” (maakt een nieuwe historieklijn aan voor hetzelfde mastercontract). Men kan dan kiezen welke aanpassingen men wil doen (aanpassen wgnr, uren FT, uren PT…). Er was reeds de mogelijkheid om meerdere selecties te maken, maar er werd erna toch maar één afgehandeld. Bv. men kon kiezen om tegelijkertijd het kantoornr en de uren PT aan te passen, maar vervolgens werd toch maar één van deze selecties afgehandeld. De programmatie is nu aangepast ivm "kiezen welke aanpassingen men wil doen": - Indien men meerdere selecties maakt, worden deze ook alle afgehandeld Men kan dus kiezen bij "maak nieuwe periode" om tegelijkertijd zowel het kantoornr te veranderen als bv. uren PT (In dit geval wordt dus zowel het kantoornr veranderd en krijgt men een scherm voor ingave van nieuwe cyclus/roosters). - Er wordt nu ook duidelijk vermeld bij "welke aanpassingen wil u doorvoeren" dat er meerdere selecties mogelijk zijn - Ook is de programmatie aangepast zodat zowel wanneer men 1) "0 - annuleren" optie kiest als 2) Annuleren-knop drukt of zelfs wanneer men 3) kruisje rechts bovenaan clickt de procedure wordt gestopt.

1.28. Opvangen dat er geen runtime error optreedt wanneer men een omschrijving voor een loonrun ingeeft die langer is dan het database-veld De programmatie voor het ingeven van de naam voor een loonrun is aangepast. Er wordt getest of de ingegeven naam voor de loonrun langer is dat het database-veld. Zolang als de ingegeven naam voor de loonrun langer is dan het database-veld, blijft telkens aan de gebruiker gevraagd worden om een naam voor de loonrun in te geven. Er wordt dan steeds al een omschrijving voor-ingevuld voor de loonrun, die gelijk is aan de reeds ingegeven naam, die dan afgekapt is op het aantal toegelaten tekens.


14/14

04

Recommend Documents