Afdrukmodule
#AFD
Algemeen
#ALG
Authenticatie
#AUT
Bestellingen
#BES
Bedrijfsvoorheffing
#TAX
Bouw
#BOU
Contracten
#CON
Debiteuren
#DEB
Dimona
#DIM
DMFA
#DMF
Documenten
#DOC
Export boekhoudpakket
#EXB
Export sociaal secretariaat
#EXS
Facturatie
#FAC
HiAnt SelfService
#HSS
Klanten
#KLA
Loonberekening
#LOO
Maaltijdcheques
#MAA
Mailing
#MAI
Ongevallen
#ONG
Operations
#OPE
Opvolgingen
#OPV
Planning
#PLA
Prestaties
#PRE
Rechten
#REC
Signing
#SIG 1
SMS
#SMS
Tarificaties
#TAR
Webservices
#WEB
Werkgever
#WG
Werknemers
#WER
Werkpostfiches
#WPF
Zoekmodule
#ZOE
Ziektemodule
#ZIE
2
Compilatie Volgende projecten worden voor de vrijgave van v6.55.0 geparkeerd en gecompileerd.
VB6 Projecten ● ● ● ● ● ●
HiAnt (exe) v6.56.0 worddoc epratod loonbrief.exe (nieuwloonbrief.vbp) directprint srvHtmlBatchMail
.NET Projecten ●
3
(FRDR) #EXB - Ticket 127084 - Export BOB bij het vragen naar de periode werd soms foutief gemeld dat het over een foutieve periode ging. Dit is nu aangepast in de controle van de periode
(FRDR) #EXB - Ticket 126338 - Export MTV2 Na de nieuwe toevoeging van Btw Scenario, blijkt dat voor een bepaalde klant een extra veld in de export steekt. Als dit veld voorkomt, kwam de waarde van het BTW Scenario niet op de correcte positie in de exportfile te staan. Aangepast, rekening houdend met aanwezigheid extra veld.
(JAVA) #CON - Ticket 124471 - ASAP Activakaarten Bij het bewaren van een contract gaat HiAnt automatisch nakijken of er RSZ Verminderingsattesten zijn waarvan de geldigheidsdatum verlengd moet worden. Tot nu toe ging men er van uit dat er slechts 1 zo'n attest is, maar in praktijk blijkt dat dezelfde persoon verschillende RSZ attesten met anderen detailtype's kan hebben. HiAnt is nu aangepast om per detailtype te gaan kijken of de datum bijgewerkt moet worden ipv enkel het meest recente hoofdtype.
(EROP) #CON - Mogelijkheid dat men binnen een reeds gedimoniseerd contract de wnnr kan wijzigen van een jobstudent-wnnr naar een werkstudent-wnnr en omgekeerd Men kon tevoren de wnnr binnen het contract enkel wijzigen indien het contract nog niet gedimoniseerd was (ofwel diende er een BLOCKED dimona-status aanwezig te zijn). Er is nu binnen HiAnt de mogelijkheid dat men binnen een reeds gedimoniseerd contract de wnnr kan wijzigen van een jobstudent-wnnr naar een werkstudent-wnnr en omgekeerd. 4
De sektie van het contract wijzigt conform de wijziging van het wnnr. Hiervoor dient er wel een wn-fiche in de te kiezen sektie aanwezig zijn in de database. Het is immers zo voor jobstudent-contracten dat, indien het contract van de jobstudent reeds gedimoniseerd is maar het contingent blijkt over de 50 dagen te zitten, de RSZ het contract heeft geboekt als een werkstudent-contract. Volgende zijn de voorwaarden opdat men binnen een reeds gedimoniseerd contract het wnnr kan veranderen: - parameter ("frmcontgeg", "JobStudContractMetDimona", "WijzigNaarWerkStudToegelaten") dient aanwezig te zijn met waarde 1 - men doet een wijziging van een jobstudent-wnnr (wnnr bij een sektie met wswncode 840, 841, 842 of 843) naar een werkstudent-wnnr (wnnr bij een sektie 15 of 95) of omgekeerd - de uzk-fiche bij het gekozen wnnr dient hetzelfde sisnr of koppelid (voor het geval het sisnr binnen één of beide uzk-fiches niet is ingevuld) te hebben als de wn-fiche van het oorspronkelijke wnnr - er mag nog geen wnbetaalperiodestatus aanwezig zijn in de periode van het contract voor de uzk van het oorspronkelijke wnnr Op volgende plaatsen is er programmatie aangepast hieromtrent: - bij het openen van een bestaand contract: het wnnr-veld is niet wijzigbaar indien de parameter niet aanwezig of indien het niet gaat over een contract van een jobstudent-fiche of werkstudent-fiche - bij veranderen van de wnnr binnen een contract dient er aan de voorwaarden voldaan te zijn - bij het bewaren van een contract wordt er ook nogmaals gechecked op de voorwaarden voor wijziging van een wnnr Deze overzetting van een contract naar een ander wnnr is ingebouwd binnen het contractscherm zelf, dit opdat al de overige bestaande controles blijven gelden. Zo is het bijvoorbeelde niet mogelijk dat men deze wijziging van wnnr doovoert indien de dimonastatus op MSEND, CSEND, MARKED, CANCELED of DELETED staat.
(JAVA) #MAA - Ticket 124611 - Electronische maaltijdcheque bestanden zonder adres 5
Onlangs werd er een bestand naar Edenred gestuurd waarbij voor 3 UZK's geen adres ingevuld was. HiAnt gaat nu controleren of er een adres ingevuld is voordat het bestand aangemaakt wordt. Als het veld adres of gemeente korter dan 4 tekens is wordt er een fout getoond en zal het bestand niet aangemaakt worden.
(JAVA) #ATT - RSZ Verminderingsattesten / Herstructureringen De berekening van het veld datum maximum geldigheid bevatte een aantal bugs: ● ●
●
er werd in sommige gevallen een kwartaal te veel geteld, dit is nu rechtgezet. in geval van herstructurering (detailtype 3601) diende de telling te gebeuren op basis van de leeftijd van de werknemer op moment van indiensttreding: ○ minder dan 4j: geldig t.e.m. 4e kwartaal na indiensttreding ○ minstens 45j: geldig t.e.m. 20e kwartaal na indiensttreding in sommige gevallen moet de gebruiker de datum maximum geldigheid kunnen overschrijven; aangezien HiAnt bij het bewaren de berekening doet zal men het vinkje "manueel" moeten aanvinken wanneer de datum manueel aangepast is. Op dat moment zal er geen controle gebeuren bij het bewaren van het attest. Ook al is het veld zichtbaar, standaard zal het vergrendeld zijn. We raden aan om dit via parameters (changecontrols) enkel voor Loonverwerkers (of hoger) bewerkbaar te maken.
6
(KART) #ZOE - Zoeken op functie in franstalige Hiant werkt niet Het zoeken op de de functie-inhoud van een werkervaring werkte enkel in de nederlands Hiant omdat in de query een taalid vast op 1 stond. Ik heb deze nu vervangen door de variabele gTaal. Technisch: Code aangepast in mZoek.BuildSqlString: Case "wnwerkervaring" ... FromString = "(" & FromString & " left join (funktie f inner join funktieN2 f2 on f.idfunktieN2=f2.id and f2.Taalid = f.taalid and f.taalid = " & gTaal & ") on wnwerkervaring.wefunctieid =f.id and f.taalid=" & gTaal & " and f2.id=f.idfunktien2 )"
7
(PALE) #WER - Mogelijkheid tot het koppelen van een fucntiegroepcode aan het hoofdniveau van de functie (funktieN1) Aan de tabel funktien1 is een extra veld Fucntiegroepcd toegevoegd waarin men per functiegroep kan aangeven tot welke groep deze functiegroep behoort. De code hiervoor dient opgenomen te worden in het code boek tabel bij code soort 150.
Ook het veld binnen het kantoor (functiegroepcode) is gekoppeld aan deze code soort. Op die manier is er een mogelijkheid om te gegeven welke functies (op groeps niveau) van toepassing zijn in een bepaald kantoor.
let op : noch op kantoorniveau noch op funktien1 niveau is dit een verplicht veld of wordt het ingevuld zijn van dit veld wordt gecontroleerd.
(EROP) #LOO - bugfix: probleem bij export voorschotten naar Securex indien er geen signaletiek is te versturen Bij de export van de voorschotten naar Securex trad er een probleem op indien er bij de export van de voorschotten geen signaletiek is te versturen. De export van voorschotten heeft er normaliter geen probleem mee indien er geen signaletiek valt te exporteren.
Een LON-bestand heeft altijd de naam van het VIS-bestand, uitgezonder de extensie. Bij export signaletiek wordt er een VIS-bestand met datum aangemaakt. Indien er geen signaletiek valt te exporteren is er geen VIS-bestand met datum. Het VIS-bestand kan dan ook niet genomen worden voor naamgeving LON-bestand. Er wordt dan als nog een VIS-NAAM aangemaakt (en een LON-naam die gebaseerd is op de VIS-naam. VIS-naam = MSG
<strDateTimeSuffix>.VIS Het probleem was dat op deze plaats de strDateTimeSuffix nog niet was ingevuld. 8
Dus men bekomt dan MSG.VIS en MSG.LON. Op een gegeven moment na de export van de voorschotten, wordt de MSG.LON overgekopieerd naar MSG<strDateTimeSuffix>.LON, maar vermits strDateTimeSuffix leeg is, wordt getracht een bestand over te kopiëren naar hetzelfde bestand --> Probleem.
De programmatie is aangepast om het probleem te verhelpen.
(EROP) #DOC - programma aangemaakt om 276T gegevens aan te maken en te raadplegen, zowel op basis van Sonet-database als Hiant-database Tevoren was het zo dat 276T-documenten enkel maar aangemaakt werden bij Sonet-klanten. dus op basis van de Sonet-database. Men wil nu ook deze documenten aanmaken voor Hiant-klanten, op basis van Hiant-gegevens. Met als doel ook voor de interimmers deze voordelen te bekomen. Bovendien zou het samennemen van Sonet-ouput-data en Hiant-output-data meer voordeel kunnen opleveren, omdat de afzonderlijke data afgerond worden en bij het samennemen van de gegevens dit een bijkomende eenheid kan opleveren.
Er is nu een programma aangemaakt (programma Test276T) waarmee, in plaats van een document aan te maken enkel voor Sonet-data, tabellen met outputdata worden ingevuld en dit voor Sonet-inputgegevens en/of Hiant-inputgegevens. Indien men het programma Test276T opstart verschijnt volgend scherm:
Opstartscherm 276T ------------------------------
9
Men dient hierbinnen sowieso de connectie-gegevens naar de Sonet-database in te vullen. Voor volgende reden is de Sonet-connectie vereist: 1) uit de Sonet-tabel “bel_min10_grenzen“ worden grens-bedragen opgehaald, die vereist zijn voor de berekening en 2) de output van de berekening worden bewaard binnen de Sonet-tabellen “bel_min10” (details-tabel die gegevens opslaat per werknemer en kwartaal) en “bel_min10_totalen” (tabel die per werkgever en jaar de eindbalans van de berekening opslaat ).
Verbinding met databases -------------------------------------Men dient eerst de knop “verbinding met databases” te clicken alvorens er een verwerking kan plaatsvinden en alvorens men gegevens kan raadplegen.
10
Indien de verbindingen gelukt zijn, verschijnt een groen kader rond de betreffende verbindingen die gemaakt zijn (bij mislukking een rood kader). Er wordt dus steeds een Sonet-verbinding gemaakt (voor hogervermelde reden). Een Hiant-verbinding wordt enkel gemaakt indien men ook een “Hiant processing” wil uitvoeren. Sonet processing -----------------------Indien men Sonet processing wil (“Sonet processing” aangevinkt), dan verschijnt (indien de Sonet-connectie is gelukt) een grid “Alle Sonet werkgevers” en een grid “Geselecteerde Sonet werkgevers”. Men kan binnen de grid “Alle Sonet werkgevers” zoeken naar werkgevers. Men kan vervolgens werkgevers verplaatsen naar de grid “Geselecteerde werkgevers”. Enkel voor de items binnen grid “Geselecteerde werkgevers” zal een Sonet processing plaatsvinden.
11
Hiant processing -----------------------Indien “Hiant processing” is aangevinkt, zal er een verwerking plaatsvinden voor de volledige Hiant-database (alle kantoren). Als wgnummer binnen de output-tabellen zal bv. 1300 ingevuld worden voor het uzb met kantoornrs 1301 → 1399.
Uitvoeren van een berekening “276T” ---------------------------------------------------------Men dient rechtsonderaan het jaar in te vullen waarvoor men de berekening wil uitvoeren. Vervolgens dient men de knop “Vul 276T tabel” te clicken. Indien “Sonet processing” is aangevinkt zal er eerst een Sonet processing plaatsvinden. Daarna de Hiant processing (indien “Hiant processing” is aangevinkt).
Een berekening bvb. voor jaar 2014 baseert zich op cijfers berekend voor jaar 2012 en 2013. 12
Er wordt steeds in de caption van het scherm de huidige actie met evt. voortgang getoond. Volgende acties worden gemeld: - “Bepalen overzicht Sonet” of “Bepalen overzicht Hiant” - “Bewaren overzicht Sonet naar database: X %" of “Bewaren overzicht Hiant naar database: X %" - "Bepalen details Sonet - werkgever” <wgnummer>" of "Bepalen details Hiant - werkgever” <wgnummer>" - "Bewaren details Sonet naar database - werkgever " <wgnummer> ": X%" of "Bewaren details Hiant naar database - werkgever " <wgnummer> ": X%"
Raadplegen van “276T” outputgegevens ---------------------------------------------------------Men kan ten allen tijde, los van een verwerking, 276T outputs raadplegen. Binnen tabblad “276T overzicht” ziet men de eindbalans van 276T outputs per werkgever en jaar. Al de variabelen, zoals op het 276T-document verschijnen , worden vermeld. Er wordt als “Source” vermeld: “Hiant” of “Sonet”, afhankelijk van waar de output komt. Als laatste kolom wordt vermeld: “Datum”, zijnde de verwerkings datum en tijd waarop de output is geleverd. Standaard is “Enkel laatste verwerking per wg, jaar en trim” aangevinkt. Dit wil zeggen dat men enkel de laatste output voor een combinatie wg-jaar-trim krijgt te zijn. Eventueel kan men “Alles tonen” aanvinken, waarbij men ook de output van eerdere verwerkingen voor een combinatie wg-jaar-trim kan raadplegen.
13
Binnen tabblad “276T detail” ziet men de volledige details van de berekening per werknemer en kwartaal. Er wordt als “Source” vermeld: “Hiant” of “Sonet”, afhankelijk van waar de output komt. Als laatste kolom wordt vermeld: “Datum”, zijnde de verwerkings datum en tijd waarop de output is geleverd. Standaard is “Enkel laatste verwerking per wg, jaar en trim” aangevinkt. Dit wil zeggen dat men enkel de laatste output voor een combinatie wg-jaar-trim krijgt te zijn. Eventueel kan men “Alles tonen” aanvinken, waarbij men ook de output van eerdere verwerkingen voor een combinatie wg-jaar-trim kan raadplegen.
14
(JAVA) #ATT - Bugfix: Runtime error in attest jobstudenten Hiant verwacht in een attest Jobstudent dat je bij documentnummer een aantal dagen ingeeft. Wanneer je hier echter tekst ingaf kon het zijn dat een controle mis liep waardoor een onduidelijke melding getoond wordt. Dit wordt nu opgevangen met de foutboodschap dat het documentnummer een geheel getal moet zijn.
(EROP) #LOO - mobiliteitsvergoeding - automatisch fiscale opsplitsing Er bestaat nu de mogelijkheid, zoals wettelijk voorzien, dat de mobiliteitsvergoeding, ingegeven door de consulent, automatisch wordt opgesplitst in een belastbaar deel en een netto deel.
15
Volgende is de opsplitsing, zoals wettelijk voorzien: - Indien mobiliteitsvergoeding > of gelijk aan 24.78 euro/ maand => 50% onder 613 en 50% onder 417 - Indien mobiliteitsvergoeding < aan 24.78 euro/ maand => 12.39 euro onder 613 en de rest onder 417 - Indien mobiliteitsvergoeding < aan 12.39 euro/ maand => volledig bedrag onder 613
Opdeling input-bedrag in netto deel en belastbaar deel
We voorzien 3 looncodes (instelbaar via parameter): - input-looncode: looncode waarop de gebruiker het totaalbedrag mobiliteitspremie input; Hiervoor gebruiken we bv. een looncode 1417. Er dient een parameter (“Loonberekening”, “SplitsMobiliteitsPremie”, “LooncodeInput”) te bestaan waarmee ingesteld wordt welke looncode gebruikt wordt als “looncode input mobiliteitspremie”. - output-nettocode: onder deze looncode komt het netto-deel terecht van de input-looncode ingegeven door de gebruiker. Er dient een parameter (“Loonberekening”, “SplitsMobiliteitsPremie”, “LooncodeNetto”) te bestaan waarmee ingesteld wordt welke onder welke looncode het“netto deel mobiliteitspremie” terechtkomt. Dit is meestal looncode 613. - output-belastbaar-code: onder deze looncode komt het belastbaar deel terecht van de input-looncode ingegeven door de gebruiker. Er dient een parameter (“Loonberekening”, “SplitsMobiliteitsPremie”, “LooncodeBelastb”) te bestaan waarmee ingesteld wordt welke onder welke looncode het“belastbaar deel mobiliteitspremie” terechtkomt. Dit is meestal looncode 417.
Verder zijn er 3 vaste nieuwe looncodes voorzien via dewelke, via loonformules, gedefinieerd wordt hoe de input-looncode mobiliteitspremie gaat opgedeeld worden in een netto deel en een belastbaar deel: - looncode 988: hiermee wordt grensbedrag 1 ingesteld = bedrag per maand waaronder het volledige input-bedrag terechtkomt op de netto looncode. - looncode 989: hiermee wordt grensbedrag 2 ingesteld. Voor mobiliteitspremie-inputs tussen grensbedrag 1 en grensbedrag 2 komt er momenteel 12.39 EURO (grensbedrag 1) terecht op het netto en het resterende deel onder de belastbare looncode. - looncode 990: hiermee wordt ingesteld welk het percentage is dat toegekend wordt aan de netto-looncode voor mobiliteitspremie-inputs boven grensbedrag 2. 16
Opmerking!!!: het gaat hier steeds over maandbedragen voor de mobiliteitspremie, hetgeen bij weekverloning een aparte bepaling van het “maandbedrag van de input mobiliteitspremie” vereist.
Bepalen van het “maandbedrag input mobiliteitspremie” Om te weten wat het totaal is van de bedragen ingegeven op de mobiliteitspremie gaan we als volgt tewerk: - we bepalen de som van de bedragen aanwezig binnen de geboekte lonen, voor periodes verschillend van de huidig berekende periode, ingeboekt op de “netto code mobiliteitspremie” en “belastbare code mobiliteitspremie” voor de betreffende Maand. We kiezen er bewust voor om apart de “netto code mobiliteitspremie” en “belastbare code mobiliteitspremie” op te halen ipv. het bedrag van de “input looncode mobiliteitspremie”, 17
vermits deze looncode nog niet bestond bij de vroegere geboekte lonen. --> bijhouden als “bedrag mobiliteitspremie reeds geboekt” - hierbij tellen we het bedrag van de “input looncode mobiliteitspremie” van de huidig berekende periode op. --> bijhouden als “totaal maandbedrag mobiliteitspremie” We gaan het bedrag tussen “bedrag mobiliteitspremie reeds geboekt” en ,“totaal maandbedrag mobiliteitspremie” opdelen als volgt: - voor het gedeelte dat ligt beneden grens : komt bij het bedrag van de netto looncode - voor het gedeelte dat ligt tussen grens1 en grens2 : komt bij het bedrag van de belastbare looncode. - voor het gedeelte dat ligt boven grens2: helft komt bij het bedrag van de netto looncode en helft komt bij het bedrag van de belastbare looncode
Weken met maandovergang Indien de huidige te berekenen loonperiode een periode is die over de maandgrenzen heen gaat (week met maandsplitsing), dan wordt de behandeling van de mobiliteitspremie 2 maal uitgevoerd: éénmaal voor mobiliteitspremies ingegeven op het “weekdeel voor maandovergang” en éénmaal voor mobiliteitspremies ingegeven op het “weekdeel na maandovergang”
PALE - #PRE# - Eenvoudige prestatie en premieingave Vanuit het week prestatieingave scherm bestaat de mogelijkheid om een scherm op te roepen vanuit het Actie menu om een eenvoudige prestatie en premieingave uit te voeren. Het menu is standaard niet zichtbaar maar kan geactiveerd worden door de parameter Scherm, frmprestgeg1, Eenvoudigeprestatieingave met de waarde 1 in te geven.
Deze eenvoudige ingave heeft de volgende mogelijkheden : ● ingave van de normale AD uren ● aparte ingave van het aantal uren gepresteerd in een ploeg ● 2 extra prestatiecodes kunnen ingegeven worden ● er kan verplaatsingsvergoeding en een mobiliteitspremie ingegeven worden Deze eenvoudige eengave heeft de volgende mogelijkheden niet : ● ●
koppeling met afdelingen en kostenplaatsen koppeling van niet AD kodes aan een ploeg code 18
● ingave van andere codes dan hierboven opgesomd. Mogelijkheden : ● ● ●
door één prestatiecode naar een andere prestatiecode te slepen kopieert men een volledige lijn door in een ingave veld op shift te klikken, kopieert men de bovenstaande waarde (nog een controle op prestaties/premiecode) door in een ingave veld op ctrl te klikken, vraagt het systeem naar een waarde. Indien deze waarde verschillend is van 0 en kleiner dan de bovenstaande waarde, wordt de ingegeven waarde in het geselecteerde veld ingegeven, en wordt de bovenstaande waarde vermindert met deze ingegeven waarde
Door op OK te klikken worden de ingegeven gegevens doorgekopieerd naar de prestatieingave (het scherm wordt automatisch verfrist)
LET OP : maaltijdcheques worden door dit systeem niet toegevoegd.
PALE - #PRE# - Update afdelingen en kostenplaatsen Vanuit het week prestatieingavescherm is het mogelijk om de afdelingen en kostenplaatsen per dag relatief eenvoudig aan te passen. Het gaat dan over afdelingen/kostenplaatsen die nog niet noodzakelijker wijs in het systeem zijn ingegeven. Hiant zal dus; indien hij een bepaalde code niet terugvindt, automatisch deze afdeling of kostenplaats aanmaken in het systeem.
Men kan het menu “Acties-Update afdelingen en kostenplaatsen” activeren door de waarde 1 bij de volgende parameter in te geven : Scherm, frmprestgeg1, UpdateAfdelingenKostenplaatsen
Er verschijnt dan een nieuw scherm waarbij men per dag één afdeling en één kostenplaats kan ingeven. Hiant controleert voor elke afdeling/kostenplaats of deze reeds bestaat ; en zal de codes dus automatisch aanmaken indien deze nog niet zou bestaan.
TO DO : - systeem uitbreiden tot 15 prestaties en premies - indien er prestaties en manuele premies bestaan worden deze overgenomen naar het vereenvoudige prestatieingave scherm tot een max van 15 verschillende codes (totaal van prestaties en premies te samen) 19
- ook worden de afdelingen mee overgenomen (dit betekent wel dat het systeem alleen kan gebruikt worden indien er maximum 1 afdeling per dag is gebruikt, indien er meerdere afdelingen per dag zijn gebruikt kan het systeem niet gebruikt worden en dient men de aanpassingen in het normale prestatieingave scherm uit te voeren - in het eenvoudige prestatieingavescherm wordt er aan de bovenzijde de afdeling getoond, de gebruiker kan hier een afdelingscode ingeven, indien deze nog niet bestaat wordt deze afdeling bij het ok drukken automatisch aangemaakt in de klantenfiche - bij het bewaren van de prestaties/premies worden dan deze afdelingen mee bewaard - de volgorde van de premies die in het scherm staan worden alfabetisch bepaald
(EROP) #EXS - verbeteringen aan export naar HDP: 1) Indien er bij export loonruns zijn waarbij er geen te exporteren data aanwezig is → loonrun niet mee opnemen bij export 2) Verbeterde logging indien er probleem is 1) Tevoren werd een loonrun waarbij er geen te exporteren data aanwezig was, niet afgehandeld. Indien er totaal geen loon-lijnen in een loonrun aanwezig waren (loonrun bij gesplitste week, waarbij enkel gegevens aanwezig in 1 weekdeel) dan werd er niets met deze loonun gedaan. Indien er wel een loon-lijn aanwezig was, maar er waren geen loon-detaillijnen aanwezig die geëxporteerd moesten worden naar HDP, dan kwam er een melding bij export, te maken met het feit dat het bestand met signaletiek ontbrak.
Er is nu aan dit probleem verholpen: er wordt aan het begin van de export voor de lijst van de te exporteren loonruns gecontroleerd of er loonruns zijn die geen te exporteren gegevens bevatten. Indien dit het geval is, wordt volgende uitgevoerd: - de export-bestandsnaam wordt ingevuld met “nodata” en export-tijdstip wordt ingevuld met de huidige tijd. - de betreffende loonrun wordt verwijderd uit de lijst van te behandelen loonruns 20
- er komt een boodschap aan de gebruiker dit meldt:
2) Verbeterde logging indien er een probleem is Indien er problemen zijn bij de export, ondervonden door de programmatie van de export, dan wordt nu veel meer detail gelogd dan tevoren. Zie hieronder. De bovenste lijn is de melding tgv. een dossierfout : Hiant logt nu veel meer detail (HDPnr, tewerkstellingsnr, looncode…) dan tevoren. De tweede lijn is de melding tgv. een validatiefout . Hier is de werking zoals tevoren. Men vindt hier terug in welk log-bestand van een export men meer info kan vinden.
(EROP) #EXS - export naar HDP aanpassing: er wordt nu per loonrun een aparte export uitgevoerd. Het is dan zo dat bij een uitgebreide selectie loonruns, enkel de loonruns die problemen geven niet geëxporteerd zullen zijn Tevoren was het zo dat, indien de gebruiker een uitgebreide selectie loonruns exporteerde , en er ergens binnen de geselecteerde loonruns een probleem was, geen enkele van de geselecteerde loonruns uiteindelijk geëxporteerd raakte. De gebruiker diende dan het probleem op te lossen en de volledige selectie loonruns 21
opnieuw te exporteren.
De export naar HDP is nu aangepast zodanig dat, indien de gebruiker een hele lijst loonruns tegelijk exporteert, deze export achterliggend opgesplitst wordt in een export per loonrun. Op deze wijze geraken de loonruns, waarbinnen er zich geen problemen voordoen, succesvol geëxporteerd. Dit levert een aanzienlijke tijdswinst op. Nieuwe verloop export naar HDP Volgende is het nieuwe verloop van een export naar HDP: 1. algemene controles/acties voor opstart export, oa.: * controle of al de nodige instellingen/parameters… aanwezig en in orde zijn. * ophalen van instellingen zoals aansluitingsnr bij HDP… * check dat bij de gemarkeerde loonruns niet zowel mastercontracten (vaste DC’ers) als uzk van bepaalde duur (interim, niet-vaste DC’ers…) zitten. → deze stap wordt slechts éénmaal uitgevoerd bij opstart van een export; dus wordt niet uitgevoerd per loonrun
2. De eigenlijke aanmaak van exportbestanden: * controlebestand * signaletiekbestand * bestand met loongegevens: prestaties, vergoedingen, uurlonen * submutaties-bestand → wordt nu uitgevoerd per loonrun (eerste lonen)
3. Validatie van exportbestanden en afhankelijk hiervan actie Bij fouten: * ongeldig maken exportbestanden Bij succes: * zippen van de exportbestanden * invullen exportdatum en “export-bestand“ in de loonrun → wordt nu uitgevoerd per loonrun (eerste lonen) 22
Opdelen van een export in aantal aparte exports - Enkel bij loonruns met eerste lonen zal er een export per loonrun zijn - !!! Bij export van herzieningen en bijboekingen zal er toch slechts 1 export zijn voor al de gemarkeerde loonruns samen: * het gaat hier ook niet over 1000’en lijnen lonen * herzieningen en bijboekingen worden samengenomen tot een aantal herzieningen per zip-bestand (instelbaar, momenteel max. 90 samen). Door hier niet een export per loonrun te doen, vermijden we dat er een overvloedig aantal exportbestanden komt.
Er wordt dus ook per loonrun een exportnummer toegekend, en niet meer één exportnummer voor alle gemarkeerde loonruns samen. Export naar HDP zal dan bv. niet meer aanleiding geven tot zip-bestanden K970858003405001 tem. K970858003405015. Maar in dit geval zal dit aanleiding geven tot zip-bestanden K970858003405001, K970858003406001, K970858003407001...
Op het eind van de export van de selectie loonruns, krijgt men een overzicht in excel voor al de betreffende loonruns.
Dit overzicht bevat volgende info - ExportNbr: een nummer per apart uitgevoerde export. In het overzicht hieronder zijn er 4 loonruns die samenzitten in 1 export; het gaat hier over herziening-loonrunb. 23
- VolgnrInExport: een volgnr binnen een ExportNbr per apart zip-bestand dat zou aangemaakt worden - Loonruns: opsomming van de loonruns die in het betreffende “zip-bestand” (combinatie ExportNbr en VolgNrInExport) zitten. - Verwerkstatus: kan volgende waardes hebben * OK: de export voor het betreffend zip-bestand” (combinatie ExportNbr en VolgNrInExport) gaf geen problemen * DossierFout: Er is een probleem bij een bepaald dossier, gemeld door de export-programmatie * ValidatieFout: de validatie van een exportbestand (signaletiek, loonbestand of submutaties-bestand) gaf problemen * of combinatie van DossierFout en ValidatieFout - Zipfile: naam van zip-bestand. Zal enkel ingevuld zijn indien er voor een bepaalde export geen problemen zijn. In bovenstaand overzicht staat er geen zip-bestand ingevuld: export 3414 was niet succesvol omdat er een dossierfout was. Export 3415 is niet goed gegaan, omdat er binnen 1 zip-bestand een validatiefout was.
- Verzendstatus: Indien een export succesvol was en wel een zip-bestand heeft opgeleverd, wordt hier de status vermeld van het versturen van het zip-bestand per mail. Kan volgende waardes hebben: * SENT * ToDo_Manual: Indien de gebruiker nog zelf het zip-bestand dient door te sturen naar HDP. Redenen hiervoor zijn: 1) de juiste instellingen (smtpserver,, smtpport smtpsender, smtprecipient) zijn niet alle aanwezig voor de mailverzending 2) het bestand is niet succesvol verstuurd kunnen worden.
Indien er in één/meerdere exports een dossierfout of een validatiefout is opgetreden, dan krijgt men hiervan melding.
24
Indien men het gemelde log-bestand opent, vindt men meer info ivm. de problemen
Voorbeeld van log-bestand van een andere export. Bij een dossierfout logt Hiant nu al meer detail (HDPnr, tewerkstellingsnr, looncode…) ivm. het probleem. Bij een validatiefout vindt men terug in welk log-bestand van een export men meer info kan vinden.
Info in log-bestand van bepaalde export:
(EROP) #LOO - Aanpassing berekening vakantiegeld: de percentages worden nu niet meer toegepast op het bruto maar op het “bruto waarbij de aftrekken vakantiegeld terug zijn bijgeteld” De programmatie ivm. berekening vakantiegeld is aangepast: als basis waarop de percentages worden toegepast wordt niet meer het bruto genomen maar het “bruto waarbij de aftrekken vakantiegeld terug zijn bijgeteld”. Het tevoren berekende vakantiegeld bleek te laag berekend te zijn. Er is een nieuwe cdeenheid 58 binnen de loonformules aangemaakt: hierbij wordt er een % toegepast op "bruto waarbij de aftrek vakantiegeld is teniet gedaan". 25
De loonformules voor de looncodes 332, 416, 419, 435 en 4435 van het vakantiegeld hebben hierbij cdeenheid 58. De database-aanpassingen van Hiant versie 6.56 zorgen er voor dat voor looncodes 332, 416, 419, 435 en 4435 de cdeenheid automatisch wordt aangepast van 50 naar 58. Indien een uzb deze werkwijze absoluut niet wil, volstaat het van manueel de cdeenheid voor deze looncodes terug aan te passen naar 50.
Bij de aftrekken vakantiegeld wordt zowel de 3436 (aftrek vakgeld bediende vast), 703 (aftrek vakgeld arbeider) als de 4436 (aftrek vakgeld bediende uzk) in rekening gebracht. Het "bruto waarbij de aftrek vakantiegeld is teniet gedaan" wordt nu ook bijgehouden in een looncode 3391 (Bruto basis vakantiegeld).
(EROP) #DOC - Aanpassing document vakantieattest (type “vakattest2007”) De programmatie voor aanmaak van het vakantieattest (type VAKATTEST2007) is aangepast nav het feit dat bij de berekening van het vakantiegeld nu de “bruto waarbij de aftrekken vakantiegeld terug zijn bijgeteld” ipv. het bruto als basis wordt genomen. Bij Bruto wordt nu de waarde van de 3391 getoond, die nu zowel de 3436 (aftrek vakgeld bediende vast), 703 (aftrek vakgeld arbeider) als de 4436 (aftrek vakgeld bediende uzk) terug bijtelt bij het bruto. Hiervoor wordt volgende uitgevoerd bij de aanmaak van het vakantieattest: zowel voor "jaar" als "jaar - 1" wordt er voor alle periodes een 3391 ingeboekt (als er geen 3391 aanwezig is of als 3391 verschilt van "bruto 391 - aftrekken vakantiegeld [positief]" ). Deze 3391 is gelijk aan: waarde van de 391 waarbij de aftrek van het vakantiegeld terug is bijgeteld. Bij de aftrekken vakantiegeld worden nu zowel de 3436, 703 als 4436 in rekening gebracht. Door parameter ["Afdruk", "vakAttest2007", "391ZonderAftrekVakGeld"] aan te maken met waarde 0 kan men er eventueel wel nog voor zorgen dat het vakantieattest op de oude manier wordt aangemaakt, dwz. dat het bedrag van de 391 wordt getoond. Er is nu ook voorzien dat, als "391ZonderAftrekVakGeld" actief is, het vakantie-attestdocument qua omschrijvingen wordt aangepast: - in de tabellen verschijnt nu "Bruto* (Brut*) ipv Bruto (Brut). - onder beide tabellen wordt een regel tekst toegevoegd (vertaald): "* Bruto waarbij de aftrek 26
vakantiegeld terug is bijgeteld."
(PEZY) #WEB - Aanpassing doorsturen kans op vast naar eigenwebsite + VDAB Er is een aanpassing gedaan aan de Webservices (PSWHiant) om overweg te kunnen met een nieuwe codesoort (208) die gebruikt wordt voor de VDAB module. Standaard wordt voor kansOpVast de code soort 74 genomen. Echter waren zijn er langs VDAB kant meerdere waardes mogelijk met elk hun VDAB term (contract, interim, interim met kans op contract,...)
De parameter "VDAB_XML_bestellingen", "KansOpVast", "CodeSoort" met als standaardwaarde 74 toont aan aan beide applicatie welke code soort gebruikt zal worden om voor kans op vast. De parameter "PWSHiAnt", "Orders", "KansVastGebruikExternalCode" met standaard waarde 0 zal met waarde 1 niet meer de CODE maar de OMSCHR uit het veld ExternalCode (tabel code) gebruiken in de webservices (PSWHiant).
(PEZY) #WEB - Aanpassing doorsturen plaats tewerkstelling naar eigen website Aanpassing op het versturen van de plaats tewerkstelling op de eigen website. Indien de klant de VDAB module heeft draaien en de parameter "VDAB_XML_bestellingen", "Setting", "AdresType" niet op 0 staat, zal (indien ingevuld) de plaats tewerkstelling opgehaald worden vanuit de LOCATION tabel. Mocht daar geen waarde aanwezig zijn voor de betreffende bestelling wordt wel weer de waarde genomen uit de bestelling zelf.
(FRDR) #EXB - Toevoeging Sektie Export Agresso (ticket 126346) Opsplitsen van exportcodes bij export naar boekhouding. nieuwe code voorzien voor payroll dienst, payroll bediende( -> moet naar code 72) en payroll arbeider ( -> moet naar code 82)
(TOSE) #FAC - Rappel en voorschotmodule parameters 27
tegebruiken sektie en wnnr (ticket 127811) Instellen per vennootschapsid
parameter "initialisatie", "faktuurrappelkost", "tegebruikenwnnr", "999999999" vervalt en wordt vervangen door
param1 = "initialisatie" param2 = "faktuurrappelkostWnnr" param3 = default = "999999999"
parameter "initialisatie", "faktuurrappelkost", "tegebruikensektie", "115" vervalt en wordt vervangen door
param1 = "initialisatie" param2 = "faktuurrappelkostSektie" param3 = default = "115"
parameter "initialisatie", "faktuuropstartkost", "tegebruikenwnnr", "999999999" vervalt en wordt vervangen door
param1 ="initialisatie" param2 = "faktuuropstartkostWnnr" param3 = default = "999999999"
parameter "initialisatie", "faktuuropstartkost", "tegebruikensektie", "115" vervalt en wordt vervangen door
param1 = "initialisatie" 28
param2 = "faktuuropstartkostSektie" param3 = default = "115"
PALE #PRE Verschillend basis uurloon per premie De mogelijkheid moet bestaan om tijdens de prestatieingave een ander uurloon dan het basisuurloon in het contract in te kunnen geven.
De prestatie en de prestatie# tabel werkt uitgebreid met een veld “UurloonManueel decimal 10.6”, dat gebruikt dient te worden indien het te gebruiken uurloon afwijkend dient te zijn dat het uurloon in het contract. Let op : het is niet de bedoeling om dit veld te gebruiken voor bv het bepalen van overuren aan een bepaald percentage.
Met de optie UIEP (uurloon in eenvoudige prestatieingave, kan men aangeven dat men de mogelijkheid bij deze klant wenst te voorzien dat men in de eenvoudige prestatieingave , het uurloon wenst in te geven.
Looneenheid 369 If rsloonform!cdeenheid = "369" Then 'bepalen brutoloon If dblBedrag = 0 Then 'IMPACTLOON : volgende regel aangepast - originele is in commentaar geplaatst, als het manueel uurloon verschillend is van 0 wordt het gebruikt, anders het gewonen brutouurloon 'dblBedrag = dblBrutoloon * rsloonform!waarde / 100 dblBedrag = IIf(rsClPremie!uurloonmanueel <> 0, rsClPremie!uurloonmanueel, dblBrutoloon) * rsloonform!waarde / 100 End If 'IMPACTLOON : volgende regel aangepast - originele is in commentaar geplaatst, als het manueel uurloon verschillend is van 0 wordt het gebruikt, anders het gewonen brutouurloon 'dblWaarde = dblWaarde + (dblBrutoloon * rsClPremie!aantal * 29
rsloonform!waarde / 100) dblWaarde = dblWaarde + (IIf(rsClPremie!uurloonmanueel <> 0, rsClPremie!uurloonmanueel, dblBrutoloon) * rsClPremie!aantal * rsloonform!waarde / 100) '***HDP LD_cdeenheid = rsloonform!cdeenheid LD_lfwaarde = rsloonform!waarde 'niets voor ld_basiscode '***HDP
End If
DB Patrick : ADU : arbeidsdag afwijkend uurloon 3201 is de uurcode 369 de loonformule
(GEMA) #PRE - Inlezen van een tikklok in het formaat van Protime Tikklok bestanden van de leverancier Protime kunnen vanaf nu ook ingelezen worden. Om deze tikklok import te configureren moet men in de opties van de klant het volgende toevoegen. TCPROTIME,UBN
(GEMA) #PRE - Inlezen van een tikklok met premies In het tikklokformaat van Protime kunnen er premies meegegeven worden. Als er premie lijnen in voorkomen zullen deze ingelezen worden in de premie tabel. De mapping van de premiecodes zal ook gebeuren via de code tabel met codesoort 50
30
