21

Release Notes Afdrukdatum: 2013/03/21

Dit document beschrijft vanuit technisch oogpunt de aanpassingen in Hi-Ant aan de betreffende versie. Deze tekst is geenszins bedoeld als document naar de eindgebruiker, maar wel voor de IT verantwoordelijken van de uitzendbedrijven die met Hi-Ant werken. Al deze informatie is confidentieel en mag niet zonder de schriftelijke toestemming van Prato in eender welke vorm verder gedistribueerd of reproduceerd worden. Deze teksten kunnen ook informatie bevatten van funktionaliteiten die niet van toepassing zijn op uw uitzendbedrijf en/of die enkel na bestelling geactiveerd worden. Het feit dat het uitzendbedrijf een onderhoudscontract en/of huurlicentie heeft lopen, impliceert geenszins het recht op de beschreven funktionaliteiten in dit document.

Release Notes Hi-Ant Versie 6.047

1/8

1.

V6.047 1.1.

Bugfixes 1.1.1. Parameter contractnummer maaltijdcheques werd elke opstart van HiAnt opnieuw aangemaakt Indien de parameter "maaltijdcheques", "contractnr", "*" niet bestaat ging HiAnt deze automatisch aanmaken met de waarde van het contractnummer uit het wisonet.ini bestand. Dit is zo gemaakt om de overgang van wisonet.ini naar de parameter-tabel te vergemakkelijken. Nieuwe klanten hebben echter ook in de ini file geen waarde staan, waardoor HiAnt deze parameter ging aanmaken zonder waarde. En bij opstart werd de parameter dan niet gevonden, waardoor hij deze ging aanmaken, … Dit is nu opgelost.

1.1.2. Nieuwe tarificatie vanuit contract Door een fout in de software was het mogelijk om een nieuwe tarificatie aan te maken vanuit een contract. Dit is nooit de bedoeling geweest en brengt veel mogelijke fouten met zich mee. Het menu Tarificatie is gemaakt om de details van de gekozen tarificatie weer te geven. Indien er geen tarificatie ingevuld is in het contract wordt nu correct een boodschap weergegeven.

1.1.3. Bugfix : Ticket 101564: Foutmelding in hoofdscherm bij Acties > Maak mailing bestand

Deze bug is nu opgelost. Technisch: Code aangepast in frmMain.sub2_click: Case 13

1.1.4. Bugfix : Ticket 101669: Foutmelding bij op knop 'Vast werk' klikken in opvolging Als je vanuit het werknemer overzicht naar via de F9 naar het opvolgingen overzicht gaat en daar een opvolging opent en vervolgens op de knop ‘Vast werk’ klikt, krijg je volgende foutmelding.

De koppelid wordt niet doorgegeven naar het detailscherm. Dit is nu aangepast.


2/8

Technisch: Code aangepast in ‘frmWnOpvolging.InitForm’. Als het geen nieuwe opvolging is, wordt m_lKoppelId gelijkgesteld aan gkoppelid.

1.1.5. Bugfix : Ticket 101663: Afwijkende kleur 'blocked-contracten' kleurt gedimoniseerde contracten grijs ipv blocked contracten Via de parameter Dimona, Blocked, afwijkendekleur kan men aangeven dat men voor blocked contracten in het visuele contracten overzicht een andere kleur wenst. De standaardwaarde van deze parameter is 0, blocked contracten worden dan ook in het groen getoond. Om de blocked contracten in het grijs te tonen moet je de parameter op waarde 1 instellen. De contracten zonder dimonastatus en de contracten met dimonastatus "MARKED", "MODIFIED" of "ENDCONT” worden in het rood getoond. Dit was blijkbaar niet helemaal in orde. Enkel de contracten zonder dimonastatus werden in het rood getoond. De contracten met status “MARKED”, “MODIFIED” en “ENDCONT” werden gewoon in het groen getoond. Als de parameter, waarde 1 had, werden ook de contracten met status “OK” in het grijs getoond. Er is ook voor gezorgd dat als er op 1 dag een contract met status ‘BLOCKED’ en een contract met status ‘OK’ is, dit in het groen getoond wordt. Dit is nu allemaal aangepast. Technisch: Code aangepast in ‘frmcontlst1. cmdok_Click()’: Trim() toegevoegd rond de dimona-status, aangezien er spaties achter staan en voorwaarde toegevoegd om enkel status blocked in het grijs te tonen: Sortering aangepast om er voor te zorgen dat blocked steeds voor OK komt. Als er op 1 dag een contract met status ‘BLOCKED’ en een contract met status ‘OK’ is, dan wordt dit in het groen getoond: ‘, Dimona.DimonaStatus’ toegevoegd achteraan OrderByString op 3 plaatsen in de code.

1.2.

Ticket 99426 - Geen waarschuwing bij vervallen attest dat automatisch aangemaakt werd bij afdruk C3.2

Vanaf nu kan je via een parameter instellen dat attesten die automatisch aangemaakt worden bij de afdruk van een C3.2.A controlekaart, of C3.2. werkgevers, ingevuld worden met “Geen waarschuwing op controlelijst bij vervallen attest” aangevinkt. Hiervoor maak je volgende parameter aan met waarde 1: "attest", "C32Aafdruk", "nowarning".

1.3.

Ticket 100452 – Logging bij ingave manuele premie.

Kan er gelogd worden wie in de verloning een manuele premie toevoegt en met welk bedrag: - gebruiker, wnnr, naam, klantnr, klantnaam, jaar, week, code, bedrag Bovenstaande logging gebeurt enkel indien je parameter ("prestatieingave", "manuelepremies", "logging") aanmaakt met waarde 1. De logging werd opgenomen in het logscherm:


3/8

1.4. -

Herafdruk fiche 281.10 vanuit F2-scherm

Extra controle of de geselecteerde persoon wel een fiche heeft gehad in het ingestelde jaar -1 Fiche wordt rechtstreeks op scherm getoond (hoeven niet meer te klikken op herafdruk) Persoonslookupbox is disabled

1.5.

Klantspecifieke aanpassing : Grid opleidingen

Het tabblad met overzicht van de gevolgde opleidingen van de werknemer is aangepast op vraag van klant. Hiervoor dient volgende (reeds bestaande) parameter ingesteld te worden op 3 "Scherm", "frmwngeg1", "GridTypeOpleiding", "0" Door deze op 3 in te stellen zal - het instituut uit codesoort 206 komen = gestructureerd - Opleiding uit codesoort 17 komen = gestructureerd (ipv uit omschrijvingen tabel) - Niveau uit codesoort 141 komen = gestructureerd In overzichtslijst zullen volgende velden getoond worden ; - Periode - Instituut (gestructureerd) - Diploma (gestructureerd) - J/N (gedubbeld) - Niveau (gestructureerd)

1.6.

Klantspecifieke aanpassing : Import excel callcenter

Er wordt nog maar één opvolging aangemaakt ipv twee. Via onderstaande parameter kan men instellen of deze opvolging automatisch op afgehandeld moet worden gezet. "CallCenter", "Opvolging", "AutoAfgehandeld", "0". Standaard = 0 = niet automatisch afgehandeld. 1 = automatisch afgehandeld


4/8

1.7.

Aanpassing programmatie ivm werking bij klanten met optie PIM – het probleem was dat tgv de laatste aanpassing enkel bij premies die voorkwamen in een parameter de aantallen in 60’n werden getoond; zou ook moeten bij uur-looncodes

Sinds een recente aanpassing was de werking bij klanten met opties PIM veranderd, dit omdat de werking ook niet gewenst was. Sinds deze aanpassing was het zo dat enkel bij looncodes die men in een parameter had ingegeven het aantal in 100en uit de database binnen het prestatiescherm terug werd getoond in 60en. Dit had als gevolg bv. dat als uur-looncodes (bv. 201 gewerkte uren) niet waren opgegeven in de parameter, men bij de prestaties bv. 7.15 AD zag staan (in 60en) en bij de berekende 201 men als aantal 7.25 zag staan. Even een uiteenzetting Ivm de werking bij klanten met optie PIM: Bij codes die bij PIM geconverteerd worden, gebeuren er 2 zaken: - Bij MANUELE ingave premie: het ingegeven aantal converteren naar honderdsten (en dit wordt zo bij de premies ook in honderdsten opgeslagen binnen de database) - Bij tonen van al de premies “die via PIM behandeld moeten worden” binnen het prestatiescherm terug omzetten van het aantal, dat in honderdsten is opgeslagen binnen de database, naar 60en

Prestaties worden altijd bij ingave omgezet van 60en naar 100en. Dus indien men 7.15 AD ingeeft wordt dit binnen de database 7.25 AD. Bij tonen op het scherm ziet men echter 7.15. Bij loonberekening na de prestatie-ingave worden de premies aangemaakt op basis van de prestatie. Dus als men een automatisch berekende premie heeft die bv. “per uur” wordt toegekend, zal in het bovenstaande voorbeeld de 7.25 AD ook aanleiding geven tot 7.25 201. Men kan echter via eigenschappen van de looncodes instellen of de looncode “via PIM behandeld moet worden” en dus of er bij tonen op het scherm terug conversie naar 60en gebeurt.

Werking bij klanten met optie PIM --------------------------------------------------------Ingegeven waarde ----------------------------------- Prestatie 7.15 AD - Automatisch berekende premie, die via PIM behandeld moet worden - Automatisch berekende premie, die via PIM NIET behandeld moet worden - Manueel ingegeven premie, die via PIM behandeld moet worden - Manueel ingegeven premie, die via PIM NIET behandeld moet worden

Opgeslagen binnen database -------------------------------------------------------7.15 AD

7.25, dus aantal bij premie 7.25 201 is ook 7.25 als bv. berekend per uur 7.25, dus aantal bij premie 7.25 316 is ook 7.25 als bv. berekend per uur 7.15 346 7.25 346 7.15 313

7.15 313

Getoond op scherm --------------------------------------7.25 AD 7.15 201 7.25 316 7.15 346 7.15 313

De werkwijze “instellen of een looncode behandeld moet worden via PIM” is aangepast: - looncodes waarbij veld RSZuurcode > 0 (looncodes die uren bevatten): moeten standaard altijd via PIM behandeld worden - via eigenschaps specs op positie 16 kan ingesteld worden of de looncode “via PIM behandeld moet worden: * 1 = via PIM behandelen. Men kan hier dus bv. bijkomend instellen dat bij een nietuur-looncode, bv. 346 ploegenpremie morgen, dat deze via PIM behandeld moet worden * 2 = NOOIT via PIM behandelen. Is voor de volledigheid voorzien. Men zou via deze


5/8

waarde 2 er bv. voor kunnen zorgen dat een bepaalde uur-looncode toch niet via PIM behandeld moet worden * 3 = afblijven. Een waarde 0 mag in principe niet voor de specs op positie 16. Wil zeggen dat er niets speciaals gebeurt ivm PIM-verwerking. Dus wil zeggen dat bij uur-looncodes de PIM-verwerking gebeurt en voor de andere looncodes niet.

Voorbeeld 1 ------------------------------ Prestatie 7.15 AD ingegeven en loonberekening uitgevoerd – geen manuele premie ingegeven - bij looncode 346, ploegenpremie morgen, is ingesteld dat deze “via PIM verwerkt moet worden”, specs positie 16 staat op 1 De prestatie binnen de database staat op 7.25 AD De premies staan binnen de database ook op aantal 7.25 omdat bij premiesturing het aantal van de prestatie wordt overgenomen. Looncode 201 is een uur-looncode, dus er wordt wel een aantal 7.15 getoond op het scherm Bij looncode 346 staat ingesteld dat deze “via PIM verwerkt moet worden”, dus er wordt ook een aantal 7.15 getoond. Al de andere premies worden getoond met het werkelijke aantal 7.25


6/8

Voorbeeld 2 -----------------------------2 manuele premies ingegeven – 8.45 347 (ploegenpremie middag) en 8.45 313 (gewone bruto premie). Bij looncode 347 is ingesteld via specs positie 16 met waarde 1 dat deze ‘via PIM verwerkt moet worden”. Dus bij ingave van de 347 is een conversie naar 100en gebeurd – binnen de database komt aantal 8.75 voor. Bij ingave van de 314 is GEEN conversie naar 100en gebeurd – binnen de database komt aantal 8.45 voor. Bij tonen op scherm: Bij de 313 gebeurt er geen conversie terug naar 60en, dus aantal 8.45 die opgeslagen is wordt getoond. Bij de 347 gebeurt er een conversie terug naar 60en, dus aantal 8.75 die opgeslagen is, wordt getoond als aantal 8.45.


7/8

Zoals hierboven vermeld heeft waarde 0 binnen specs positie 16 geen betekens – men zou steeds waarde 1, 2 of 3 moeten invullen. Er is de mogelijkheid dat hierop gecontroleerd wordt. Indien men parameter ("Scherm", "PrestatieIngave", "PremieSpecsPIMEigVerplicht") aanmaakt met waarde 1, dan wordt hierop gecontroleerd (is standaard niet het geval) en kan men geen prestatie-ingavescherm openen.

1.8.

Aanpassing export naar Securex: men kan via parameter instellen dat bij de export naar Securex de indienst-datum van de DCer niet meer wordt ingevuld met de begindatum van zijn eerste contract

De export naar Securex zorgt ervoor dat bij wn-fiches, waarbij de indienst-datum groter is dan de begindatum van het eerste contract, de indienst-datum wordt ingevuld met de begindatum van het eerste contract. Nu zijn er uitzendbedrijven die dit niet willen. Als bv. een DCer een tijdje uit dienst is geweest en erna terug begint te werken, wil men niet dat de indienst-datum van zijn wn-fiche wordt ingevuld met de begindatum van zijn EERSTE contract. Het uitzendbedrijf in kwestie zorgt er zelf voor dat de indienst-datum van de wn-fiche juist is ingevuld. De programmatie van de export naar Securex is aangepast: Indien men parameter ("ExportSecurex", "WnIndienst", "DatumEersteContract") aanmaakt met waarde 0, dan wordt bij export de wn.indienst niet meer ingevuld met de begindatum van het eerste contract.


8/8

21

Recommend Documents