WHERE PEOPLE AND SOFTWARE MEET

WHERE PEOPLE AND SOFTWARE MEET

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

Pagina 1/9

WHERE PEOPLE AND SOFTWARE MEET Signing

#SIG

SMS

#SMS

Tarificaties

#TAR

Webservices

#WEB

Werkgever

#WG

Werknemers

#WER

Werkpostfiches

#WPF

Zoekmodule

#ZOE

Ziektemodule

#ZIE

Release Notes HiAnt versie 6.54

Pagina 2/9


Compilatie Volgende projecten worden voor de vrijgave van v6.54.0 geparkeerd en gecompileerd.

VB6 Projecten ● HiAnt (exe) v6.54.0 ● Project PratoOcx (Prato_Ado_Gridbrowse aangepast) ● Bij Link2Europe volgende parameter terug juistzetten (hier zijn de prefixen beginnend met 048 uitgehaald anders probleem met poolse nrs die herkend worden als belgische gsm) ■ param1='inputgsm' and param2='prefixen' ● loonbrief.exe

.NET Projecten ●

Pagina 3/9


INTERN (FRDR) #EXB Aanpassing Multivers, extra veld BtwScenario voor MTV3 Aanpassing aan de export van MultiVers, Multivers heeft nieuwe kolommen voorzien, vandaar dat achteraan de bestanden een nieuwe kolom moet komen met het BTWScenario de nieuwe kolom krijgt de naam !BS Voor de factuurlijnen (de lijnen waar het karakter op positie 146 een "F" is) moet een nummer meegegeven worden (met leading spaces). De overige lijnen mogen met drie spaties opgevuld worden of met dezelfde waarde. Dit zijn de BTW scenario nummers met hun omschrijving 8: Verkoop binnenland 9: Verkoop binnenland medecontractant 10: Verkoop binnen EU ? IC Levering 11: Verkoop buiten EU onbelast / overige handelingen Deze waarde zal ingevuld moeten worden in de code-tabel, cd_srt 84 bij de ExternalCode Standaard wordt dit nu aangemaakt voor de export naar multivers (aangezien iedereen zal moeten overschakelen naar de nieuwe multivers-versie) Indien men dit extra veld niet wenst, dan moet men volgende parameter aanmaken met waarde 0 param1 "Export" param2 "factuurMTV" param3 "ExtraBTWScenario" nieuwe parameter om aan de code aante geven voor de Medecontractanten, geefparamwaarde("Export", "factuur", "MTV_BM", 9) indien afwijkend van 9 dan moet deze parameter aangemaakt worden

(EROP) #CON - Verder aanpassing “checkdatabase” voor invulling van veld “mastergroep” binnen de mastercontracten Vanaf Hiant versie 6.53 wordt er binnen de contracten (enkel van nut voor mastercontracten) een veld "mastergroep" aangemaakt. Dit veld wordt aangemaakt met default value 0. Indien er "mastercontract aanpassing" of "beheer mastercontract" (voor Securex-exporters) wordt uitgevoerd, waarbij er een "nieuwe historiek" wordt aangemaakt voor eenzelfde "wettelijke master (dimona)" krijgt deze nieuwe master dezelfde mastergroep als deze waarop de aanpassing wordt doorgevoerd. We weten dus in het vervolg welke mastercontracten zo bij elkaar horen.

Pagina 4/9


Nadat het veld is aangemaakt, wordt bij al de bestaande mastercontracten waarbij mastergroep op 0 staat, deze ingevuld. ☺Echter bij de bestaande mastercontracten staat dit veld op null ipv. 0 (default value 0 wordt enkel toegepast bij nieuw aangemaakte mastercontracten).

De mCheckDatabase is nu aangepast: ipv "where prestmaster.mastergroep = 0" wordt nu "where isnull(prestmaster.mastergroep, 0) = 0" uitgevoerd. Nu wordt wel voor alle bestaande mastercontracten veld mastergroep ingevuld.

(JAVA) #CON - Bugfix - Ticket 115881 - Z-Group Import prestaties Ortec Bij de jaarovergang kon in sommige gevallen de week en het jaar van het vorige ipv huidige jaar gebruikt worden door het ontbreken van een filter. Dit is gecorrigeerd.

(JAVA) #DOC Statistiek mailing HiAnt 6.53 maakte de xml file aan met een fout structuur. Dit werd nu rechtgezet. De release notes van 6.53 waren juist maar de file werd anders gemaakt. Code komt nu overeen met release notes.

(JAVA) #OPV Nieuwe velden in opvolgingsdetailscherm In het kader van de NPS module werden een aantal velden toegevoegd aan de opvolgingstabel. Deze velden bevatten info over mails die verstuurd werden naar werknemers of klanten. Meer info: zie NPS project. Deze hebben geen extra functie binnen HiAnt en zijn louter informatief.

(EROP) #ALG Functie “ControlHasProperty” voorzien binnen Hiant; men kan nu via deze functie opvragen of een scherm-control een bepaalde property bevat; vroeger ving men de fout bij benaderen van een niet-bestaande property op in een errorhandler Er is een nieuwe functie "ControlHasProperty" binnen Hiant aangemaakt. Men kan dus nu checken of een bepaalde control een bepaalde property heeft. Er hoeft dus niet telkens een fout op te treden (die door een error handler wordt opgevangen) bij het accessen van een bepaalde property op bv. alle controls van een scherm. Dit vergemakkelijkt het debuggen waardoor men zonder zorgen “break on all errors” kan opzetten.

EXTERN (TOSE) #FAC : Automatische Voorschotfacturen/rappelkosten

Pagina 5/9

WHERE PEOPLE AND SOFTWARE MEET Module te activeren met licentie parameter te verkrijgen bij prato “Licentie”,”Activatie”,”VoorschotRappelModule”. Verdere parameters ● "initialisatie","Faktuur","AanmaningsActiesRappel","" ○ bepaalt welke aanmaningsactiesIds ervoor zorgen dat er tijdens facturatie eventuele openstaande rappels automatisch worden toegevoegd aan de berekening ● "initialisatie","Faktuur","gekoppeldevoorschotcode","" ○ bepaalt de facturatiecode die wordt gebruikt om een eventueel voorschot te koppelen tijdens facturatieberekening ● "initialisatie","Faktuur","manuelevoorschotcode","" ○ bepaalt de facturatiecode die wordt gebruikt om te bepalen of er een voorschot moet klaargezet worden tijdens boeken van fakturen ● "initialisatie","Faktuur","rappelkostcode","" ○ bepaalt de facturatiecode van de rappelkost ● "initialisatie","faktuurrappelkostwgnr",, ○ bepaalt het te gebruiken kantoornr in de detailrecord van faktuur van de rappelkost (wgnr en wgnruzk). Dit is een mogelijke instelling per vennootschap. Indien niet ingevuld wordt de kantoornummer van de klant gebruikt. ● "initialisatie","rappelkost",","" ○ bepaalt het bedrag per aanmaningsactie. Er wordt rekening gehouden met het veld ts_crea, degene die op boekingsdatum actief is wordt gebruikt (mogelijkheid om bv. indexeringen toe te passen) ● "initialisatie", "fakturatie", "VoorschotFaktuurDagen",”0” ○ bepaalt aantal dagen dat een openstaand voorschot dient open te staan om te kunnen koppelen aan een faktuur ● "initialisatie", "faktuurrappelkost", "tegebruikenwnnr", "999999999" ○ te gebruiken wnnr bij toevoegen van een rappelkost aan een faktuur (standaard is zelfde als opslaan zonder wnnr in detail van faktuurtransaktierecord) ● "initialisatie", "faktuurrappelkost", "tegebruikensektie", "115" ○ te gebruiken sektie bij toevoegen van een rappelkost aan een faktuur (standaard is dit 115 arbeider -> elke faktuurdetaillijn dient aan een bestaande sektie gekoppeld te zijn) ● "initialisatie", "voorschotrappel", "tooninternefactnr", "0" ○ indien op 1 gezet wordt in overzicht de interne factuurnr getoond Indien module actief staat, zal er in de facturatiemodule een extra tabblad zichtbaar zijn (Voorschot/Rappel)

Pagina 6/9


Werking voorschotfaktuur -> klaarzetten van voorschot. De gebruiker maakt een manuele faktuur aan, waarbij de facturatiecode voor voorschot wordt gebruikt (in te stellen via parameter "initialisatie","Faktuur","manuelevoorschotcode","") en als week/jaar wordt week/jaar gebruikt waarop dit voorschot betrekking heeft. Tijdens het boeken van een manuele faktuur met deze specifieke code, zal er in een aparte tabel een voorschot worden klaargezet (het netto bedrag van deze manuele voorschotcode wordt gebruikt), zodat deze automatisch kan verwerkt worden bij de eigenlijke facturatie van de prestaties van het jaar/week. De voorschotten die klaargezet zijn, zijn steeds zichtbaar in het tabblad “Voorschot/Rappel” met status 0. Volgende statussen zijn mogelijk : ● 0 : niet verwerkt ● 1 : transaktie ● 2 : verwerkt ● 3 : manueel verwerkt In de grid zijn volgende kolommen zichtbaar ● Klnr : klantnummer waar voorschotfaktuur betrekking op heeft ● KlNaam : klantnaam ● Code : De gebruikte (voorschot)code ● Omschrijving : De omschrijving van de gebruikte (voorschot)code ● Jaar : Jaar van de voorschotfaktuur ● Week : Week van de voorschotfaktuur

Pagina 7/9

WHERE PEOPLE AND SOFTWARE MEET ● Netto : Netto bedrag van voorschot ● FaNr Man : Factuurnummer van manuele voorschotfaktuur ● FaNr Tran : Id van fakturatierunteberekenen waaraan voorschotfaktuur is gekoppeld (in transaktie) ● FaNr Fac : Factuurnummer waar voorschot is aan gekoppeld (in mindering gebracht) -> na boeken (of internfactnr indien parameter "initialisatie", "voorschotrappel", "tooninternefactnr", "0" op 1 is ingesteld) ● Fa Jaar : Jaar van geboekte faktuur waar voorschot is aan gekoppeld ● Fa Week : Week van geboekte faktuur waar voorschot is aan gekoppeld ● Status : Status van voorschot/rappel -> zie hierboven mogelijke statussen Werking voorschotfaktuur - Start facturatie - verwerking van voorschotfaktuur. Wanneer men een facturatierun opstart zal het systeem eerst de volledige berekening doen. Op het einde van de berekening zal INDIEN HET NETTO GROTER DAN 0 IS, het systeem controleren of er voor de klnr, jaar en week van de faktuur een overeenkomstig voorschot is gevonden (klnr, jaar en week) met status = 0 - niet verwerkt. Indien dit zo is, zal er aan deze faktuur automatisch het klaarstaande voorschot in mindering worden gebracht (status wordt 1). Verder zal het systeem ook eventuele openstaande voorschotten met jaar/week kleiner dan de te factureren jaar/week kunnen meenemen. Hierbij wordt er gecontroleerd of er nog openstaande voorschotten staan voor deze klnr, waarvan de boekingsdatum van het voorschot (= manuele faktuur met voorschotcode) X dagen geleden is gebeurd. Dit wordt ingesteld met de parameter "initialisatie", "fakturatie", "VoorschotFaktuurDagen",”0”. Indien aantal dagen is overschreden zal ook dit openstaand voorschot automatisch in mindering gebracht worden op de faktuur. Werking voorschotfaktuur - Handmatig op verwerkt zetten. Stel dat een klant stopt en men kan een openstaand voorschot niet meer koppelen, dan is men in de mogelijkheid om dit handmatig op verwerkt te zetten (status = 3). Dit kan men doen door in het tabblad “Voorschot/Rappel” op de knop “Zet op verwerkt” te klikken. Gebruiker krijgt de volgende mogelijkheid

Voor de selectie zal het systeem dan alle openstaande voorschotten (status = 0 ) op status 3 zetten. Werking rappel - klaarzetten. Via het debiteurensysteem zal er bij het verwerken van een aanmaningsrun, automatisch een “laatste aanmaningsactie” worden toegekend aan de klantenfiche. De bedragen van de rappels kunnen per aanmaningsactie ingesteld worden via parameters "initialisatie","rappelkost",","". Indien bij het verwerken (boeken) van

Pagina 8/9

WHERE PEOPLE AND SOFTWARE MEET een aanmaningsrun er klanten zijn gevonden waarvan een geldige parameter is gevonden (ts_crea<= systeemdatum), zal het systeem voor die klant automatisch een rappelkost klaarzetten. Als jaar wordt jaar van systeemdatum gebruikt, en het bedrag is het bedrag gevonden in de parameter. De Rappels zijn ook zichtbaar in het tabblad “Voorschot/Rappel” in de fakturatiemodule. Werking rappel - Start facturatie - verwerking van rappel. Wanneer men een facturatierun opstart zal het systeem eerst de volledige berekening doen. Op het einde van de berekening zal INDIEN HET NETTO GROTER DAN 0 IS, het systeem controleren of er voor de klnr een openstaande rappel (status=0) is gevonden, EN de laatste aanmaningsactie in de klantenfiche voorkomt in de opsomming van aanmaningsacties in de parameter "initialisatie", "Faktuur", "AanmaningsActiesRappel", "". Indien gevonden, zal er aan deze faktuur automatisch de klaarstaande rappel toegevoegd worden aan de faktuur(status wordt 1). Werking rappel/voorschot - Automatisch terug op status 0 bij verwijderen klant uit fakturatierunteberekenen. Wanneer men in transaktie een klant uit de berekening zou gooien (uit fakturatierunteberekenen), zullen de eventuele gekoppelde voorschotten/rappels terug van status 1 (transaktie) naar status 0 (niet verwerkt) worden gezet, zodat ze terug klaarstaan voor een eventuele volgende fakturatie.

(TOSE) #DEB : Versturen mail (individueel/bulk) klnr in subject Men kan via parameter instellen of in het onderwerp van de mail die kan verstuurd worden via het actie menu in debiteurenbeheermodule bepalen of de klantnummer mee gestuurd wordt tuusen 2 # tekens Hiervoor dient de parameter "initialisatie", "debiteuren", "KlnrInSubjectMail", "0" op 1 ingesteld te worden.

(PEZY) #WER : Vreemdelingen module HiAnt - aanpassing beslissingstabel Parameter "VreemdelingModule", "Controle", "FamVerwantschap" Standaard waarde = 0 ⇒ Uitgeschakelt. Met bovenstaande parameter kan men de controle familiale verwantschap uitzetten binnen de vreemdelingen module.

(PEZY) #FAC : Ticket 111997 - Zichtbaar maken gestructureerde mededeling voor consulenten? Parameter "frmFactGeg", "ToonGestrucMed", "*" Door de parameter de waarde 1 te geven zal hiant in het Factuur Detail scherm onderaan (indien aanwezig) de gestructureerde mededeling van de factuur tonen. Dit is enkel van toepassing voor de geboekte facturen.

Pagina 9/9


(TOSE) #ZIE : Aanpassing ziektemodule eenheidsstatuut Vanaf 1/1/2014 zal hiant de ziekteinterpretatie toepassen volgens eenheidsstatuut. D.w.z. dat de carensdag niet meer zal bestaan. De ziektemodule zal kijken naar de begindatum van de ziekte. Als deze groter of gelijk is aan 1/1/2014, zal dit toegepast worden. De begindatum van toepassing is in te stellen via onderstaande parameter (standaard 2014-01-01) "initialisatie", "ZiekteInterpretatie", "EenheidsStatuutVanaf", "2014-01-01"

(PEZY) #DOC : Foutieve c131b Parameter "frmC131B", "Rooster", "UrenOptellen" Bovenstaande parameter zorgt dat het opvullen van de rooster binnen een C131B gebeurt als volgt. Indien een werknemer meerdere contracten heeft in een zelfde dag, worden de uren samen opgeteld en getoond in de dagen van het rooster.

(EROP) #LOO - Aanpassing query ivm controle op ingegeven maaltijdcheque-codes binnen “boeken loonrun per uzk” tgv. probleem van een “divide by zero” Bij het boeken van een loonrun gebeurt er een controle op ingegeven maaltijdcheque-codes. Binnen deze query kwam er bij “boeken loonrun per uzk” een groepering voor op “ewaarde/aantal”. Er kwam een geval voor waarbij men, naast de automatisch berekende 653, men een 653 had ingegeven met tegengesteld aantal. Met als gevolg een resulterend aantal 0 naar de lonen toe. De vermelde query gaf hierbij een “divide by zero”. De groepering “ewaarde/aantal” was zelfs helemaal niet nodig. Deze groepering verwijderd. Erna lukte het boeken van de loonrun.

(EROP) #DOC - Aanpassing programmatie van programma loonbrief.exe: indien overgeschakeld naar de e-docs funtionaliteit gaf de “mail manueel” van de loonbrieven een fout De “mail manueel” van de loonbrieven gaf nog een fout.

Pagina 10/9

WHERE PEOPLE AND SOFTWARE MEET Er zijn aanpassingen doorgevoerd moeten worden: - Link met de betaalp-tabel miste - "Positioneervelden" gaf een probleem binnen de "mail manueel" Deze heb ik in commentaar dienen te zetten - er hoeft geen "herpositionering" van crystal-velden binnen de designer te gebeuren ingeval van "mail manueel" want er wordt geen Crystal Reports designer getoond. Daarentegen gebeurt er nu STEEDS een "PositioneerVelden" binnen de funktie "MaakPdfPerLoonbrief". Dit wil zeggen dat bij de aanmaak van de pdf-documenten deze "PositioneerVelden" steeds wordt aangeroepen. Tevoren gebeurde dit niet. Dit wil concreet zeggen: als er bij een uzb een herpositionering van velden binnen het document dient te gebeuren, via parametrisering ingesteld, dan gebeurt dit nu ook bij de aanmaak van de individuele pdf-documenten. Concreet houdt dit bv. bij bepaalde uzb in dat binnen de loonbrief-documenten bovenaan links de werknemer verschijnt en bovenaan rechts de werkgever (standaard is dit: links de werkgever en rechts de werknemer).

(EROP) #CON - Aanpassing contracten-overzicht: bij nieuwe invulling van de grid worden eerst de grid-properties geïnitialiseerd met lege waardes; om probleem te voorkomen dat er fout optreedt bij overgang van gewone-contracten-lijst naar master-contracten-lijst... Volgende probleem trad soms op: De grid in het contractenoverzichtscherm wordt telkens opnieuw opgevuld, bij switchen van gewone contracten naar mastercontracten, bij het gaan naar een ander overzicht…, zonder dat de properties van de grid eerst worden geinitialiseerd. In het gewone contractoverzicht zijn er bv. 49 kolommen; bij het mastercontract-overzicht zijn er 48 kolommen. Dit geeft een probleem bv. bij switchen van gewone contractenoverzicht naar mastercontract-overzicht. Bv. de columnwidths bestaan nog voor 49 kolommen, de columnheadings zijn al terug ingevuld met 48 kolommen. Dit geeft een probleem bij de nieuwe grid: gaat er van uit dat alle properties zijn ingevuld (maar dit is in feite niet zo, vermits ze nog waren opgevuld van de vorige load). De programmatie is nu aangepast zodat bij een nieuwe invulling van de grid eerst de grid-properties worden geinitialiseerd met lege waardes. Dit zorgt dat het probleem niet meer optreedt.

Pagina 11/10


(JAVA) #WER - bugfix - Verwijderen van read-only attesten De controle op een alleen-lezen attest bij verwijderen werkte alleen indien dit attesttype ook nog was opgenomen in een oudere parameter "codeboekcode", "attest", "Budgetbeheer". De controle is nu aangepast dat slechts aan 1 van deze 2 voorwaarden moet voldaan worden, niet aan allebei.

(JAVA) #KLA - Ticket 113934 - Controleer vakbond enkel bij klanten De bestaande parameter "Scherm", "Frmklgeg1", "ControleerVakbond" zorgt ervoor dat bij het bewaren van de klantenfiche een aantal controles op aanwezigheid van vakbond lopen. Deze controle gebeurde echter ook voor prospecten, en hier was deze info vaak nog niet gekend. Door nieuwe parameter "scherm", "frmklgeg1", "ControleerVakbondEnkelBijKlanten" aan te maken met waarde 1 kan je er voor zorgen dat deze controle enkel gebeurt wanneer de fiche in kwestie een klant is en geen prospect.

(JAVA) #CON - Ticket 113986 - Vanuit contractenlijst naar werknemer- of klantenfiche gaan Vanaf nu kan je vanuit het contractenscherm rechtstreeks naar de werknemers- of klantenfiche van de geselecteerde rij gaan via het menu of sneltoetsen F2 / F3:

(TOSE) #ONG - mogelijkheid tot aanduiden van “vast personeel” in aangifte Uitbreiding in ongevallenmodule zodat men kan aanvinken dat de aangifte over een vast

Pagina 12/11

WHERE PEOPLE AND SOFTWARE MEET personeelslid gaat. Het vinkje is te zien in tabblad getroffene.

Indien vinkje wordt aangeduid, zal bij afdruk van ongevalsaangifte bij rubriek “Is getroffene een uitzendkracht” “Nee” komen te staan. Ook bij de export naar OASYS systeem zal men een aparte polisnummer kunnen meesturen. Dit wordt gestuurd door de parameter "Export", "Ongeval", "PolisnrVast", "". Als vinkje “Vast personeel” op staat, zal dus de polisnummer genomen worden die in deze parameter staat. Ook bij afdruk van aangifte zal, indien het gaat om een aangifte met vinkje “vast personeel” deze polisnummer worden geprint

(EROP) #DOC - E-docs (HiantDocMailing) mogelijkheid om bij iedere mailing van documenten per type document 1 document met algemene voorwaarden toe te voegen Sinds enige tijd bestaat er de E-docs (HiantDocMailing) functionaliteit binnen Hiant, waarmee men documenten kan mailen en/of afdrukken. Bij sommige uitzendbedrijven is het zo dat, wanneer men een bepaald document afdrukt, men dit doet op voorgedrukt papier waarbij zich aan de achterzijde van elke bladzijde de algemene voorwaarde bevinden. Deze uitzendbedrijven wilden nu dat, indien documenten worden gemaild, er per mail en per type document een document wordt meegestuurd met de algemene voorwaarden. De programmatie van het “mail-verzend-programma” is nu aangepast. Er bestaat nu de mogelijkheid dat men per type document, eventueel per taal, een parameter aanmaakt waarin het pad en bestandsnaam van het document met algemene voorwaarden wordt ingegeven. Men dient dus volgende parameters aan te maken: param1 = “HtmlMail_DocAfdrukken” param2 = “DocAlgVw_FullFileName” param3 = Deze kan momenteel de volgende waardes hebben: factuur, prestatieformulier, klcontract, loonbrief, wpf, uzkcontract cd_taal = deze vult men in met 1 als het gaat over een NL-talig document, met 2 voor een FR-talig document. Men maakt dan ook normaliter 2 parameters aan, één voor het NL-talig document met algemene voorwaarden en één voor het FR-talig document met algemene voorwaarden. Voor een uzb dat enkel uzk en klanten aan het werk heeft met dezelfde taal, volstaat één parameter waarbij cd_taal 0 is.

Pagina 13/12


waarde = bevat pad en bestandsnaam van het document met algemene voorwaarden. Dit dient ingegeven te worden in de vorm \\<servernaam>\<subfolder1>\<subfolder2>\....\<document algemene vw.pdf> Dit document is bij voorkeur een .pdf document, zodanig dat dit door de geadresseerde niet kan aangepast worden. Per geadresseerde (mail) en type document wordt slechts éénmaal het document met algemene voorwaarden toegevoegd. Dus als er ineens voor 4 weken contracten worden doorgemaild naar een uzk, zal er een mail verstuurd worden met 4 uzk-contracten en slechts 1 document met algemene voorwaarden bij het uzk-contract.

(PEZY) #DOC - Ticket 115163 - Emailmodule : logo en vaste tekst Voor de E-DOC module is er nu een bijkomende functionaliteit waarbij men per document kan aangeven of er een verschil in layout dient te komen tussen een document dat wordt afgedrukt en gemaild. Met verschil wordt bedoelt dat een logo of vaste tekst al dan niet dient weergegeven te worden. Het activeren van deze procedure doet men via de parameter "Afdruk", #DOCUMENT#, "LayoutVerschil" met als waarde 1. Waarbij #DOCUMENT# overeenkomt met de benaming van het type document. Momenteel is dit mogelijk voor de volgende waardes/types: Factuur UZKcontract KLcontract PrestatieFormulier WPF Let wel op! De eigenlijke verschillen dienen door prato ingesteld/geprogrammeerd te worden binnen de Crystal Reports sjablonen.

(JAVA) #CON - Ticket 115811 - Controle gesplitste contracten met reden instroom Door een fout in de software kan de gebruiker onterecht een blokkerende melding krijgen dat een contract met reden instroom moet beginnen op maandag. Dit kon gebeuren wanneer het om een gesplitst contract ging, en het 2e deel van het contract werd geopend. HiAnt ging dan naar de begindatum van het deel ipv de begindatum van het originele contract kijken en blokkeerde:

Pagina 14/13


Dit is nu rechtgezet, de datum van het volledige contract worden bekeken in de controle.

(JAVA) #LOO - Ticket 110371 - Naam loonrun te lang om te boeken In HiAnt wordt de omschrijving van de loonrun ook wegggeschreven in o.a. de maaltijd- of ecocheque tabellen bij het boeken. De max.lengte van deze velden kwam echter niet overeen, waardoor je een foutmelding kreeg wanneer de naam van de loonrun langer was dan 50 karakters. Vanaf nu zal HiAnt een te lange naam afknippen op 50 karakters wanneer ze weggeschreven worden naar de cheques-tabellen (deze velden groter maken was geen optie omdat deze mogelijk meegestuurd worden in electronische bestanden).

(JAVA) #WER - Ticket 115455 - MaakUZK icm leeg rekeningnummer Indien je een persoon UZK wil maken en zijn bankrekeningnr is niet ingevuld, krijg je een Invalid use of NULL. Dit werd gecorrigeerd.

(PALE) #FAC - boeken facturen Nieuw factuurnummer type 7 Bij het boeken van de facturen is er een nieuw factuurnr type ingebouwd : type 7 : factuurnummer per jaar en vennootschap (en dus niet per type document). Het activeren van dit type gebeurt met de volgende parameter : INITIALISATIE, FactuurnrType, *, 7 Het eigenlijke factuurnummer wordt dan ook opgehaald uit een parameter die als volgt is samengesteld : Param1 = "FACTUURNRKantoorgroepJaar" Param2 = "FC" & StrKantoorgroepid& "_" & intInternFactnrJaar Param3 = “Volgendnr” waarde = het te gebruiken volgend factuurnummer voor de vennootschap en jaar waarbij :

Pagina 15/14

WHERE PEOPLE AND SOFTWARE MEET StrKantoorgroepid: de waarde is van het veld kantoorgroepid uit de wg tabel intinternfactnrjaar : de waarde van het jaar waarin de facturen aangemaakt zijn. Dit systeem houdt ook rekening met de minimumjaar instelling , die men kan ingeven met de parameter : Factuurnummering, MinimumJaar, * De bedoeling is dat men deze parameter invult met de waarde van het huidige jaar indien de boekhouding is van het vorige jaar is afgesloten. Let op : we spreken hier steeds over kalenderjaren en dus niet over verschoven of verlengde boekhoudjaren. Er wordt automatisch ook gecontroleerd dat er maar één kantoorgroep per run aanwezig is. Indien er in één facturatierun meerdere kantoorgroepen aanwezig zouden zijn, zal het boeken niet kunnen uitgevoerd worden.

(PALE)#WG Nieuw veld in WG tabel DagBoekCDCN Er is een nieuw veld aan de werkgever tabel toegevoegd : DagboekCdCn (dagboekcode voor creditnota’s). Dit veld kan momenteel enkel gebruikt worden in combinatie met de export naar BOB. Het label en het tekst veld zijn standaard niet zichtbaar, maar kunnen geactiveerd worden door de volgende controls visible te maken : ● lblgeg(66) (changecontrols,frmwggeg,lblgeg(66).visible,1) ● dtbgeg(53) (changecontrols,frmwggeg,dtbgeg(53).visible,1) Gelieve bij de implemantatie van deze velden goed te controleren dat deze gegevens per kantoor kunnen aangepast worden, en dus dat een wijziging van deze velden in één van de kantoren geen aanleiding is tot het aanpassen van de gegevens in alle kantoren. Deze dagboekcode mag maximaal 5 tekens lang zijn.

PS : indien er voor bepaalde exporten geen onderscheid wordt gemaakt tussen facturen en credinota’s is het voldoende om enkel het gewenste dagboek in te vullen bij DBC F

Pagina 16/15

WHERE PEOPLE AND SOFTWARE MEET (dagboekcode facturen) en hoeft men het veld DBC CN (dagboekcode credinota’s) ook niet te visualiseren.

(PALE) #EXB Export bob aanpassing gebruik dagboekcode per kantoor en type document bij facturen If geefparamwaarde("export", "bob", "gebruikdagboekcodeperkantoor", "0") <> 0 Then blUseDBCPeroffice = True 'controler of er kantoren zijn waarbij de dagboekcodes niet zijn ingevuld. rscontrole.open "select wgnr,naam, dagboekcd ,dagboekcdcn from wg where Actief = 1 and (ISNULL(dagboekcd,'')='' or ISNULL(dagboekcdcn,'')='')", con, adOpenKeyset, adLockReadOnly If rscontrole.BOF And rscontrol.EOF Then Else MsgBox "De dagboekcodes zijn niet in alle kantoren ingevuld. Het boeken wordt gestopt. " FilePath = gLocalPath & "nietingevuldedagboekcodes" & "_" & Format(Date, "yyyymmdd") & Format(Time, "hhmmss") & ".xls" ExportRecordsetToExcel rscontrole, FilePath, True End If Else blUseDBCPeroffice = False End If Zowel in de hoofdfile als de detail file zijn de aanpassingen uitgevoerd. Het geheel wordt gestuurd door de variabele blUseDBCPerOffice (PEZY) #DOC - BugFix - Foutmelding Hiant bij het afsluiten van een cv Als je na het kilkken op de knop CV op de knop annulereren drukt, krijg je een foutmelding. Er wordt dan de functie MWnGeg.ControleerEnEvtBewaarAfdrukData opgeroepen. Aangezien de velden ivm de e-docs module niet zijn ingesteld, probeert Hiant de focus te zetten op .lubgeg3(nFirstErrField).SetFocus Na het drukken op de knop CV, gebeurt het volgende (in FrmWnGeg1.cmdCV_Click()): SSTab1.Visible = False frmcv.Visible = True Aangezien SSTab1 niet zichtbaar is, kan de focus niet op de control lubgeg3(nFirstErrField) gezet worden. En krijg je dus de 'Invalid procedure call or argument'. Hiant controleert nu of de control SSTAB1 zichtbaar staat vooraleer de focus erop te zetten.

(STFL) #WER - BugFix - Blanco Knoppen Pagina 17/16

WHERE PEOPLE AND SOFTWARE MEET In de fiche van uzk’s staan onderaan 2 blanco knoppen. De pijlen zijn onzichtbaar. Pijlen zijn terug toegevoegd.

(EROP) #LOO - Aanpassing export naar HDP voor weekverloning om dubbele uurloon-codes in exportbestand te vermijden Er trad een probleem op bij de export naar HDP van de weekverloonden; binnen het exportbestand kwam dezelfde uurloon-code meermaals voor voor eenzelfde tewerkstelling. Dit trad enkel op bij herzieningen. Dit had uiteindelijk te maken met een afrondingsprobleem, in samenspel met en/of VB6, MDAC en sql server 2012. Een voorbeeld van zo’n probleem: - Bij uitvoeren van de query voor het ophalen van de uurlonen binnen SQL server management studio gaf het resultaat 3 lijnen terug; 3 verschillende uurloon-codes met hun bedrag. - Binnen VB6 bevatte de recordset die bovenstaande query uitvoert 4 lijnen terug??? Met als gevolg 2 maal dezelfde uurloon-code in het exportbestand. De programmatie is aangepast om dit probleem te verhelpen. Bij het linken van de loond met de “loond met uurlonen” is een bijkomende voorwaarde opgelegd.

(EROP) #LOO - Aanpassing export naar HDP voor maandverloning om negatieve uurloon-codes in exportbestand te vermijden Er trad een probleem op bij de export naar HDP; binnen het exportbestand kwam van tijd tot tijd een negatief uurloon. Dit trad enkel op bij herzieningen (de loond van de tegenboeking werd genomen voor het uurloon). De programmatie is aangepast om dit probleem te verhelpen. De query voor het ophalen van de uurlonen is herschreven.

(EROP) #DOC - Binnen printaanvragen voor klant-documenten opslaan van het klnr Pagina 18/17


Er is mbt. het e-docs verhaal nodig dat we binnen de printaanvragen voor de klant-documenten beschikken over het klnr van de betreffende klant. Hiervoor is er een nieuw veld “pa_KlIdentific” binnen de printaanvragen-tabel. Bij de uzb gebruik makend van het e-docs verhaal wordt bij de klant-documenten dit veld pa_KlIdentific ingevuld met het klnr van de klant waarvoor het document wordt aangevraagd. Dit geldt momenteel voor de klant-documenten “klcontract”, “faktuur” en “prestatieformulier”. In de andere gevallen zal dit veld de waarde 0 hebben.

(EROP) #WER - Oplossing voor probleem “Email-gegeven verschijnt binnen hoofdscherm uzk bij importeren van een websubscribe-fiche” Er was het probleem dat bij binnenhalen van een websubscribe-fiche naar Hiant het “email-veld” binnen het uzk-hoofdscherm niet werd ingevuld. Het email-adres was wel degelijk geimporteerd binnen Hiant, bij de communicatie nrs (binnen het scherm dat je via de knop "inschrijvingen" bereikt). Het is bovendien zo dat het gegeven "email" binnen het hoofdscherm van de uzk gehaald wordt uit deze "communicatie nrs" (van type email). Maar volgende was wel het probleem: op het moment van laden van dit hoofdscherm en dus laden van dit email-gegeven zijn wel reeds de basisgegevens van de uzk geimporteerd, maar nog niet de communicatienrs. Dus het gegeven email VERSCHEEN niet binnen de uzk-fiche, maar het email-gegeven was wel geimporteerd. Dit kan je zien als je vanuit dit hoofdscherm uzk gaat naar "inschrijvingsgegevens". De programmatie is aangepast, zodat na het initieel laden van het hoofdscherm en na inladen van de communicatie-nrs het email-veld nog eens wordt herladen. Met als gevolg dat dan wel het email-veld direct verschijnt bij importeren van een web-gegeven. (PEZY) #DOC - Ticket 116883 - cv uit HiAnt Parameter "afdruk", "WordCV", "ToonExtraInfoAlgemeen"

Pagina 19/18

WHERE PEOPLE AND SOFTWARE MEET Bij waarde 1 zal de WordRap van hiant (OUDE CV!!!) bijkomend onderstaande info op het CV plaatsen Burgerlijke staat Kinderen of geen kinderen Indien we een heftruckattest hebben toegevoegd zou er op moeten komen te staan: in het bezit van een heftruckattest Wagen en eventueel rijbewijs

(KART) #SMS - BugFix - Opzoeklijst Standaardberichten in SMSDetail-scherm gaat filteren op id ipv msg_id Hierdoor krijg je een foutmelding. Dit is opgelost. Technisch: Code aangepast in frmMain.LubBerichten_SelectedItem With LubBerichten Set .con = con .sqlstring = "select msg_id,msg_subject from msgSMS where (isnull(msg_officenr,0)=0 or msg_officenr=" & gKantoorNr & ")" 'and msg_language=" & gTaal .TestSQLNumeric = "select msg_id,msg_subject from msgSMS where (isnull(msg_officenr,0)=0 or msg_officenr=" & gKantoorNr & ") and msg_id = #TEXTBOX#" .TestSQLString = "select msg_id,msg_subject from msgSMS where (isnull(msg_officenr,0)=0 or msg_officenr=" & gKantoorNr & ") and msg_subject >= '#TEXTBOX#' AND msg_subject <= '#TEXTBOX1#'" .LookUpSQLString = "select msg_id,msg_subject from msgSMS where msg_id = #TEXTBOX#" .DatabaseValueColumn = 0 .TextColumn = "1" .DatabaseField = "" .DatabaseValue = "" End With

(KART) #EXS - BugFix - Bestandsnamen kunnen meerdere keren voorkomen bij GroupS Bij GroupS worden de bestandsnamen opgebouwd uit verschillende delen. Het laatste deel is variabel en bestaat uit 3 numerieke karakters. Na 999 wordt er opnieuw met 001 begonnen. Hierdoor kan het zijn dat 1 bestandsnaam meerdere keren voorkomt. Als je dan een export ongedaan wil maken, neemt Hiant al de loonruns die in een bestand voorkomen met dezelfde naam, zonder rekening te houden met de exportdatum. Dit is nu aangepast. Technisch: Code aangepast in FrmLoonber.mnuActie_Click: Case 8 strSelectie = brwloonrun.GiveMeSelectedItemAsString strSelectie = VolgendItem(strSelectie, "|") Set rsTemp = New ADODB.Recordset

Pagina 20/19

WHERE PEOPLE AND SOFTWARE MEET rsTemp.open "select id, Omschrijving, ExportedToExternalSocSec, ExpToSocSecFileName from loonrun where id = " & strSelectie, con, adOpenKeyset, adLockReadOnly If ls(rsTemp!ExportedToExternalSocSec) <> "" And ls(rsTemp!ExpToSocSecFileName) <> "" Then strDatumTijd = Format(rsTemp!ExportedToExternalSocSec, "YYYY-MM-DD") Bestandsnaam = rsTemp!ExpToSocSecFileName rsTemp.Close rsTemp.open "select id, omschrijving, ExpToSocSecFileName, NoExportToSocSec from loonrun " & _ " where ExpToSocSecFileName = '" & Bestandsnaam & "' and cast(exportedtoexternalsocsec as DATE) = '" & strDatumTijd & "'", con, adOpenKeyset, adLockReadOnly ... Select Case UCase(Trim(ls(strExportToExternalSocSec))) Case "GROEPS", "GROEPSINTERIM" con.Execute "delete from ExportGroepSSigt where FileName = '" & Bestandsnaam & "' and cast(verzenddatum as DATE) = '" & strDatumTijd & "'"

(EROP) #FAC en #LOO - In de logtable per loonrun/fakturatierun info weggeschreven ivm tijdsmeting berekenen/boeken Vanaf versie 6.54 van Hiant wordt in de logtable per loonrun/fakturatierun bij zowel het berekenen als het boeken, en zowel bij verwerking manueel/batch en boeken PerUzk/PerFactuur aan het begin en aan het eind een lijn weggeschreven. Bij de eind-lijn wordt info weggeschreven ivm het aantal verwerkte combinaties en de verwerkingsduur. Bij de fakturen wordt het aantal klnr-periode-wnnr combinaties geteld. Zie in de tekening hieronder de logtype die hiervoor gebruikt worden. Bij een batchverwerking (berekenen/ boeken van loonrun/facturatierun) wordt binnen param1 per batch-verwerking éénzelfde timestamp gebruikt. Dus per timer-event met een verwerking wordt er éénzelfde timestamp weggeschreven. Bij manueel berekenen/boeken van loonrun/facturatierun wordt er per loonrun/facturatierun bij het begin en bij het eind eenzelfde timestamp gebruikt.

Pagina 21/20


Zie hier de query die dan kan gebruikt worden om de duur per combinatie op te vragen: select Type, Omschrijving, timestamp, duur, aantalcombi, convert(decimal(12, 2), (duur / (aantalcombi + 0.0000000001))) as DuurPerLijn_s from ( select type, omschrijving, param1 as timestamp, case when Type in ('132', '134') then convert(int, param4) when Type in ('128', '130') then

Pagina 22/21

WHERE PEOPLE AND SOFTWARE MEET convert(int, param5) when Type in ('112', '126', '136') then convert(int, param6) end as duur, case when Type in ('132', '134') then convert(int, param3) when Type in ('128', '130') then convert(int, param4) when Type in ('112', '126', '136') then convert(int, param5) end as aantalcombi from LogTable where Type in ('112', '126', '128', '130', '132', '134', '136') ) as t order by Type, timestamp

(EROP) #PRE bugfix - bij “manueel” zet op te berekenen werd er niet steeds meer gelogd naar de logtable met type 48 (‘Prestaties klaargezet') Er was een probleem met de logging bij het manueel klaarzetten van de prestaties: er werd niet steeds meer gelogd naar de logtable met type 48 (‘prestaties klaargezet’). Dit was erin geslopen na aanpassing van de programmatie ivm. uitbreiding van de wnbetaalperiodestatussen. Indien men werkt met het automatisch berekenen van premies en het automatisch klaarzetten, komen er veel meer statussen voor, en komen er dus ook tussen-statussen voor alvorens een dossier op “klaargezet” komt te staan. Men kan in dit geval ook een dossier “manueel” op te berekenen zetten indien een dossier zich bevind in een tussen-status van het automatisch klaarzetten (statussen “ -15 = eerste loon, klaar om er de automatische premies voor te berekenen”, “ -14 = eerste loon, probleem opgetreden bij berekening automatische premies”, “ -13 = eerste loon, klaar om er de “controles bij zet op te berekenen” voor uit te voeren”, “ -12 = eerste loon, niet klaargezet, probleem bij “controles bij zet op te berekenen”). Er worden nu bij het klaarzetten 2 queries uitgevoerd: - een “insert into wnbetaalperiodestatus” voor de combinaties waarvoor er nog geen wnbetaalperiodestatus is - een “update wnbetaalperiodestatus” naar “klaargezet” voor de dossiers die zich in een tussen-status van het automatisch klaarzetten bevinden Steeds worden beide queries uitgevoerd, waarbij er steeds slechts één van de twee een uitwerking hebben. Bij het uitvoeren van elke query wordt ook teruggegeven hoeveel rijen er zijn aangepast door de betreffende query. Er is echter bij de aanmaak van de programmatie over het hoofd gezien dat dit “aantal rijen” verderop in de programmatie gebruikt werd. Indien het aantal rijen groter is dan 0, dan pas wordt er gelogd naar de logtable. Slechts één van beide queries had maar effect (OF insert into wnbetaalperiodestatus als er nog geen wnbetaalperiodestatus bestaat OF update wnbetaalperiodestatus naar "klaargezet" als er al een tussen-status bestaat). De programmatie in zowel frmPrestGeg1 als frmPrestGeg2 is nu aangepast, zodat de update-query slechts wordt uitgevoerd als het uitvoeren van de insert-query geen effect had (er was geen lijn waarvoor nog geen wnbetaalperiodestatus bestond). If nAantalRecords = 0 --> dan pas update-query

Pagina 23/22

WHERE PEOPLE AND SOFTWARE MEET Dit zorgt ervoor dat nAantalRecords niet terug op 0 komt als er een insert uitgevoerd is (en een update geen effect zou hebben).

(JAVA) #WER Ticket 118347 - Naam in hoofdletters HiAnt gaat automatisch de achternaam in hoofdletters zetten tenzij de woorden "van", "de" of "den" erin voorkomen. Aan deze lijst is nu ook "der" toegevoegd nav de melding van een persoon met de naam Van der Eyken. HiAnt maakte hier onterecht Van Der Eyken van.

(FRDA) #WER Ticket 118759 - Maand overzicht Jaar - Parameter inbouwen De fout is opgemerkt doordat er een verkeerd maandbedrag werd getoond voor de rubriek 592 - bedrijfsvoorheffing. Er werd een bedrag voor de bedrijfsvoorheffing getoond, terwijl dit eigenlijk 0 moest zijn. Bij nazicht bleek dat indien het berekende bedrag van de BV 0 is, dan werd automatisch het basisbedrag getoond wat gebruikt werd voor eventuele BV op te berekenen. Dit probleem is nu opgelost door een parameter toe te voegen ‘GebruikSteedsEWaarde’ (default waarde is 1) die aangeeft hoe dat het totaalbedrag moet getoond worden: ● Waarde 1: toon altijd het totaalbedrag van de berekende waarde (ook indien dit 0 bedraagt) ● Andere waarde: indien het berekende bedrag > 0, toon dan het berekende bedrag, anders toon het bedrag wat als basis gebruikt wordt voor de berekening.

(EROP) #PRE Aanpassing aanmaak ADM-documenten ivm probleem: indien men “verander werkgever” had uitgevoerd binnen de prestatie-ingaveschermen, dan werd de aanmaak van de ADM-documenten toch uitgevoerd voor het actieve kantoor van Hiant Indien men “verander werkgever” had uitgevoerd binnen de prestatie-ingaveschermen, dan werd de “actie ADM-documenten” toch uitgevoerd voor het actieve kantoor van Hiant. De programmatie van Hiant is aangepast, zodat de aanmaak van de ADM-documenten wordt uitgevoerd voor het kantoor dat men gekozen heeft bij “verander werkgever”. Indien men “verander werkgever” niet heeft aangeroepen of indien men “verander werkgever” heeft aangeroepen en men 0 heeft ingegeven (prestaties van alle kantoren), dan wordt de aanmaak van de ADM-documenten toch aangeroepen voor het actieve kantoor van Hiant. De aanpassing geldt zowel voor het geval men vanuit Hiant effectief de documenten aanmaakt als voor het geval waarbij men enkel printaanvragen aanmaakt [parameter (“ADMDocumenten", "ToPrintAanvragen", "*”) bestaat met waarde 1].

Pagina 24/23


(EROP) #ZOE Algemene aanpassing: aan de Prato_Ado_Gridbrowse kan men nu een commandtimeout meegeven; binnen de wn-zoek kan men nu aan een “zoek-overig”-zoekitem via parameter een commandtimeout instellen Ten eerste is algemeen aangepast: aan de nieuwe prato-grid (Prato_Ado_Gridbrowse) kan men nu een bijkomende eigenschap “CONCOMMANDTIMEOUT” meegeven. Dit zorgt ervoor dat aan de query voor opvullen van de grid een afwijkende timeout geldt, afwijkend van de standaard-timeout van 30 (seconden). Concreet is er binnen Hiant aangepast: binnen de “zoek-overig” (Shift-F2; Gegevens/zoek , submenu’s van menu “overige”) kan men nu voor een bepaald menu-item een commandtimeout instellen. Dit is voorzien om ervoor te zorgen dat men bij de "zoek overig" voor een bepaalde lijst met een zware query een hogere timeout zou kunnen instellen. Het instellen van deze afwijkende timeout doet men door voor de betreffende lijst (parameters( (“list”, , …) ] een bijkomende parameter (“list”, , “CONCOMMANDTIMEOUT”) toe te voegen waarbij men in waarde de afwijkende timeout ingeeft, bvb. 90.

(JAVA) #KLA Bugfix - Klanten veranderen van kantoor In het verleden werd onderstaande wijziging gedaan: Standaard kunnen enkel co medewerkers en programmeurs klanten en prospecten van kantoor wijzigen. Het is nu echter ook mogelijk om uitzendconsulten deze mogelijkheid te geven. Het is instelbaar via de parameter Scherm, FrmKllst1, VeranderWgnr Mogelijke waarden : · 0 (standaard waarde) : menu is niet zichtbaar · 1 : menu is enkel zichtbaar voor programmeurs en co medewerkers · 2 : menu is voor iedereen zichtbaar Om een klant van kantoor te kunnen wijzigen, is het natuurlijk noodzakelijk dat je de klant of prospect al kunt zien in het overzicht. Het is voor consulenten dus niet mogelijk om een klant of prospect van kantoor te wijzigen die niet tot zijn/haar actief – of steunkantoor behoort. Dit zorgde echter enkel voor de zichtbaarheid van het menu, het effectieve wijzigen van kantoor werd in de code enkel toegelaten door CO's. De code werd aangepast zodat er ook naar deze parameter wordt gekeken.

Pagina 25/24


(KART) #FAC - BugFix - Afdeling wijzigen van manuele factuur gaat niet Het was onmogelijk om de afdeling van een manuele factuur te wijzigen omdat een manuele factuur steeds facturatie systeem (FS) -1 heeft. Er wordt gelinkt naar de fakturatiep tabel aan de hand van onder andere het facturatie systeem. Aangezien dit -1 is, kan de link niet gelegd worden en werd de startdatum van de factuur ingesteld op ‘1900-01-01’. Als er op deze datum geen geldige afdelingen zijn, kan er dus niets gekozen worden. Dit is aangepast. Als er geen begindatum voor de factuur gevonden wordt, wordt nu de huidige datum gebruikt. Technisch: Code aangepast in FrmFactGeg.mnuAdaptAfd_Click: If Not (rsTemp.BOF And rsTemp.EOF) Then datBeginPeriode = ld(rsTemp!fpbegind) Else datBeginPeriode = Date End If

(TOSE) #ALG - Bewaren van DefaultValue in lookupbox indien niet ingevuld Tijdens bewaren van een scherm met lookupboxen, en deze waren niet ingevuld werd aangepast dat dit als null werd bewaard. Dit gaf op meerdere plaatsen problemen in HiAnt. Aanpassing is gebeurd zodat hier ook rekening gehouden wordt met de parameter "initialisatie", "HiAnt", "AllowSaveNullValues", "0". Indien op 1 zal wel een null in de database gestoken worden indien dit veld allownulls op heeft staan

(PEZY)- #DOC - PrestatieFormulieren zonder uren in uurrooster Klanten die geen uren getoond willen hebben op hun prestatieformulieren dienen de optie PZU (PrestatieFormulier Zonder Uren) in hun optiebalk te hebben.

(TOSE) #DEB : Toewijzen van aanmaningsacties Het bepalen van de mogelijke aanmaningsacties in combinatie met openstaande schuld is nu parameteriseerbaar. “initialisatie”,”debiteuren”,”geenactie”,”6,7” : bepaalt voor welke aanmaningsactieids er geen verdere actie moet gebeuren “initialisatie”,”debiteuren”,”actiesSaldoMinTussen”,”1,2” : bepaalt welke acties betrekking hebben op klanten met salodplus 0 en som van salodmin en saldotussen verschilt van 0 “initialisatie”,”debiteuren”,”actiesSaldoPlus”,”3,4,5” : bepaalt welke acties betrekking hebben op klanten met saldoplus verschillend van 0

Pagina 26/25

WHERE PEOPLE AND SOFTWARE MEET De volgorde van toekenning van de volgende aanmaningsactie wordt nu geregeld door het veld externalcode in codesoort 231. (wordt gesorteerd op numerieke waarde van externalcode) Via het menu “acties - pas actie aan” kan een niet debiteurbeheerder enkel de huidige en volgende actie selecteren (actie+1). Ook hier wordt rekening gehouden met sortering via het veld externalcode om de volgende actie (actie +1 ) te bepalen.

(TOSE) #DEB : Verwerken van aanmaningsrun Wanneer een aanmaningsrun wordt verwerkt, wordt de tabel printaanvragen opgevuld, zodat deze tabel kan gebruikt worden voor het versturen/afdrukken van de documenten voor de klant. Ook hier is een aanpassing gebeurd. "initialisatie", "debiteuren", "aanmaningsactiesnaarprintaanvragen", "" : bepaalt welke aanmaningsactieids moeten opgenomen worden in de printaanvragen tabel. Indien niet ingevuld krijgt de gebruiker een melding en kan men aanmaningsrun niet verwerken. De code die in het veld pa_document van de tabel printaanvragen wordt gestoken moet nu uit het veld omschr_kort van codesoort 231 komen. Indien er aanmaningsacties gevonden zijn waar geen omschr_kort is ingevuld, krijgt de gebruiker een melding en excel met ontbrekende omschr_kort en kan men de aanmaningsruns niet verwerken.

(TOSE) #FAC : Automatische opstartkosten Er is een mogelijkheid ingebouwd om bij een opstartende klant een opstartkost aan te rekenen bij de eerste faktuur. Deze mogelijkheid werkt samen met de Module voorschot/rappel te activeren met licentie parameter te verkrijgen bij prato “Licentie”,”Activatie”,”VoorschotRappelModule”. Parameters "initialisatie", "Faktuur", "opstartkostcode", "" -> bepaalt de nieuw aangemaakt fakturatiecode die gebruikt wordt om opstartkostcode te definiëren “initialisatie”, “opstartkost”, “maakklant”,”” -> bepaalt de waarde van de opstartkost bij aanmaak klant. Hierbij wordt gekeken naar het veld ts_crea, zodat men ook indexatie kan uitvoeren op deze opstartkost. "initialisatie", "faktuuropstartkost", "tegebruikenwnnr", "999999999" -> bepaalt welke wnnr moet gebruikt worden in de faktuurd tabel (standaard fictief nummer) "initialisatie", "faktuuropstartkost", "tegebruikensektie", "115" -> bepaalt welke sektienr moet gebruikt worden in de faktuurd tabel (standaard arbeider) "initialisatie", "faktuuropstartkostWgnr", , -> bepaalt welke waarde moet gebruikt worden om in faktuurd.wgnr en faktuurd.wgnruzk te zetten. Dit kan men per vennootschapsid instellen. Standaard is dit de wgnr van de klant. Bij de actie “Maak klant” in een prospectenfiche zal, indien de module is geactiveerd en de fakturatiecode is gedefinieerd en een waarde is gevonden met opstartkost, automatisch een opstartkost worden klaargezet in de faktuurvsrappel tabel, op voorwaarde dat de optie GOK niet aanwezig is in de prospecten fiche. GOK-optie betekent “Geen opstart kost”

Pagina 27/26


Tijdens de facturatie zal er gekeken worden of er voor de betreffende klantnummer een nog niet verwerkte opstartkost is gevonden. Deze wordt dan opgenomen in de fakturatie, op voorwaarde dat het totaal netto positief is. (dus niet bij creditnota’s). Indien er een nog niet verwerkte opstartkost voor een klant is gevonden, maar er staat momenteel de optie GOK in de fiche van deze klant, dan zal deze opstartkost niet worden opgenomen en krijgt de status 4 ‘overruled’ in de tabel faktuurvsrappel.

(KART) #OPV en #KLA - BugFix - Fout bij ingeven stuk klantnaam in klanten lookupbox in opvolgingen scherm Blijkbaar krijg je een foutmelding doordat de parameter "initialisatie", "ClientsAlwaysVisible", "*" een lege waarde heeft. Deze parameter wordt automatisch onderhouden indien de parameter "initialisatie", "automodify", "parameterClientsProspectsAlwaysVisible" aan staat. Indien bij de laatste klant de optie “NKP” verwijderd wordt, komt er een lege string in de waarde te staan. Deze waarde wordt echter gebruikt in query’s en indien deze leeg is, geeft dit foutmeldingen. Ook nog een fout gevonden bij het verwijderen van de laatste komma. Dit is ook opgelost. Technisch: Code aangepast in frmklgeg1.cmdBewaar_Click: 'verwijdere mogelijke comma op laatste positie If Right(strVisibles, 1) = "," Then strVisibles = Mid(strVisibles, 1, Len(strVisibles) - 1) End If strVisibles = IIf(strVisibles = "", "-1", strVisibles) 'als er niets meer in de string staat, default waarde instellen

(TOSE) #SMS : Nieuwe voetnoot mogelijkheden nieuwe voettekstnoot 4 toegevoegd waar wg.naam + wg.kantoornaam wordt getoond. 2 nieuwe parameters om te bepalen wat de wg.naam en wg.kantoornaam moet zijn "scherm", "frmsmsdetail", "wgnaam", ls(rsTemp!naam) -> standaard is dit dus de waarde uit wg.naam "scherm", "frmsmsdetail", "kantoornaam", ls(rsTemp!kantoornaam) -> standaard is dit dus de waarde uit wg.kantoornaam

(JAVA) #DOC - bugfix - mogelijk dubbele afdruk / mails bij gebruik eDoc module Door een bug in de software is het mogelijk dat afdruk/email voorkeuren dubbel in de database kwam te staan. Hierdoor kon het voorkomen dat documenten meerdere keren

Pagina 28/27

WHERE PEOPLE AND SOFTWARE MEET afgedrukt of gemaild werden. Dit is nu opgelost.

(EROP) #EXS - aanpassing export naar HDP voor de weekverloonden: andere, meer performante, werkwijze voor invullen van tewerkstellingsnrs Er ging redelijk wat tijd uit binnen de export naar HDP van de weekverloonden na opstart van de export en voordat er effectief begonnen werd met de aanmaak van exportbestanden. Er is gezien dat de tijd die opgebruikt wordt, na start van de export en voordat er effectief wordt begonnen met aanmaak van bestanden, bijna volledig uitgaat aan het invullen van de tewerkstellingsnrs in de contracten. De stap van het invullen van de tewerkstellingsnrs duurde 8 tot 10 minuten voor een 1000-tal lonen. Er zijn 2 aanpassingen getest: - aanmaak van een index op de tussentabel (die overigens maar 3 velden heeft) waarbinnen het hoogste tewerkstellingsnr per uzk wordt bijgehouden - andere werkwijze voor invulling van tewerkstellingsnrs: recordset clientside nemen en pas op het einde een "update batch" Een export, waarbij de nieuwe index bestond, maar waarbij de export nog op de oude manier werd uitgevoerd (NIET: "recordset clientside nemen en pas op het einde een 'update batch' " ) duurde 4 minuten. Een export, waarbij de nieuwe index bestond, en waarbij ook de export-aanpassing werd gebruikt (WEL: "recordset clientside nemen en pas op het einde een 'update batch' " ) duurde rond 2 minuten 20 seconden. De export naar HDP is dus definitief aangepast zodat de werkwijze bij opvulling van de tewerkstellingsnrs in de contracten anders is: "recordset clientside nemen en pas op het einde een 'update batch' ". Deze aanpassing zal geen effect hebben op: - export van correcties (geen bijboekingen): bij correcties zijn voor de meeste contracten (behalve evt. contracten die men na vorige verloning heeft bijgemaakt) de tewerkstellingsnrs al ingevuld, dus het aantal contracten waarbij het tewerkstellingsnr moet ingevuld worden is een pak lager - bij de export van de vaste DC worden er geen tewerkstellingsnrs in de contracten ingevuld; het tewerkstellingsnr wordt bepaald door de jaar en maand; dus er gaat ook

Pagina 29/28

WHERE PEOPLE AND SOFTWARE MEET geen tijd op aan het invullen van tewerkstellingsnrs.

(EROP) #FAC - aanpassing query voor detectie nulfakturen in een fakturatierun Er is op gegeven moment het geval voorgekomen dat bij een uzb men er toch in is geslaagd om een faktuur met bedrag 0 uit een fakturatierun te boeken. Er is vanalles nagezien en er is geen overtuigend antwoord uit de bus gekomen met de mogelijke oorzaak van deze boeking van een 0-faktuur. Om toch nog zeker te zijn dat bepaalde denkpistes mogen uitgesloten worden, is ervoor gezorgd dat de detectie van 0-fakturen is aangepast (bij 0-fakturen wordt de berekende faktuur met bedrag 0 immers ook verwijderd uit de fakturatierun). De query om 0-fakturen op te sporen is aangepast van 'sqlstring = "select * from fakturatierunteberekenen where fakturatierunnr = " & gfrid & " and fs <> -1 and isnull(enetto,0) =0" naar sqlstring = "select * from fakturatierunteberekenen where fakturatierunnr = " & gfrid & " and fs <> -1 and round(isnull(enetto,0),4) =0" Dus er wordt een afronding toegepast, om te vermijden dat bv. een faktuur toch zou geboekt worden indien een fakturatierunteberekenen!enetto, binnen de database voorkomend met bv. waarde. 0.000000001 niet zou verwijderd worden uit de fakturatierun.

(EROP) #DOC - Emailmodule: voorzien dat bij 'mail manueel' de documenten met de algemene voorwaarden ook worden meegestuurd De "mailmanueel"-functionaliteit is aangepast, zodat er nu ook de mogelijkheid is dat er een document met algemene voorwaarden wordt meegestuurd. De "MailManueel" voor zowel uzkcontract, wpf, loonbrief, klcontract, prestatieformulier en factuur aangepast en dit bij zowel 1) Documenten voor meerdere contacten waarbij mail per contact 2) Documenten voor meerdere contacten waarbij er slechts 1 mail wordt aangemaakt en 3) Al of niet meerdere documenten voor één geadresseerde. Men dient natuurlijk voor het type document een document met algemene voorwaarden te hebben opdat deze actie genomen wordt. Hiervoor dient er een parameter ("HtmlMail_DocAfdrukken", "DocAlgVw_FullFileName", ) te zijn met als waarde het pad (in formaat "\\...") naar het document met algemene voorwaarden. Er dient ook een paarameter aangemaakt te worden opdat bij "mail manueel" al of niet

Pagina 30/29

WHERE PEOPLE AND SOFTWARE MEET een document met algemene voorwaarden wordt meegestuurd. Parameter ("HtmlMail_DocAfdrukken", "MailManueel", "DocAlgVw") kan volgende waardes aannemen: - 1 --> document algemene voorwaarden niet meesturen bij 'mailmanueel' - 2 --> er wordt gevraagd aan de gebruiker of het document algemene voorwaarden bij 'mailmanueel' dient meegestuurd te worden Standaard geldt waarde 1, dus standaard wordt er bij "mail manueel" geen document met algemene voorwaarden meegestuurd.

(EROP) #DOC - Aanpassing loonbrief-project; tevoren zag men bij “mail manueel” van loonbrieven binnen het mail-scherm de bijlages niet staan Het loonbrief-project is aangepast op volgend punt: binnen het loonbrief-project gold tevoren een maximum grootte voor elk scherm, met als gevolg dat het mail-scherm verkleind werd zodat de bijlages niet meer zichtbaar waren. De funktie die "de schermgrootte beperkt" is nu aangepast: dit geldt niet meer voor het mail-scherm.

(KART) #PRE - Kostenplaatsen staan dubbel in de lijst onderaan in het prestatie-ingave scherm Blijkbaar werd de lijst op 2 plaatsen in de code opgevuld. Dit is nu op 1 plaats verwijderd. Technisch: In frmprestgeg1.LaadLookupBoxen: code voor het opvullen van LstKostenplaats in commentaar gezet. Omdat dit ook al werd uitgevoerd in LaadLubgeg1.

(TOSE) #SMS - Bewaar knop van standaardberichten De bewaar knop in detailscherm van sms verzenden is standaard enkel voor co en programmeurs beschikbaar. Nu kan men instellen met een parameter dat iedereen deze knop kan gebruiken. "scherm", "frmSMSDetail", "EnableSaveButton", "0" -> door deze op 1 in te stellen kan iedereen de bewaar knop gebruiken

(KART) #DOC - Niet mogelijk om C63 af te drukken vanuit Personenoverzicht (alle personen) voor UZK met meerdere fiches Voor dat je een submenu kan kiezen krijg je een scherm om de sectie te kiezen. Na het kiezen van de sectie doet Hiant niets meer. Probleem is opgelost. Het tussenscherm wordt nu niet meer getoond bij het klikken op het menu C63.

Pagina 31/30

WHERE PEOPLE AND SOFTWARE MEET Technisch: Code aangepast in frmwnlst.sub2_click (Index = 14) toegevoegd: If Index = 9 Or Index = 10 Or Index = 14 Then Exit Sub End If

(EROP) #LOO - In de logtable info weggeschreven ivm tijdsmeting export naar sociaal secretariaat Vanaf versie 6.54 van Hiant wordt in de logtable voor elke export naar een sociaal secretariaat aan het begin en aan het eind een lijn weggeschreven. Bij de eind-lijn wordt info weggeschreven ivm het aantal geëxporteerde lonen, de duur van export en het slaagresultaat van de export. Deze logging gebeurt bij elk type export: Acerta, GroepS, Securex, HDP...

Pagina 32/31


Volgende param’s worden weggeschreven: - param1: timestamp van het begin van de export; zowel bij de begin-lijn als de eind-lijn wordt de timestamp van het begin weggeschreven - param2: een opsomming van de loonruns, gescheiden door komma, die binnen de betreffende export worden geëxporteerd - param3: naam van het sociaal secretariaat - param4: aantal lonen dat bij de export geëxporteerd zijn - param5: duur in seconden van de export. Bij deze tijdsduur zit de tijdsduur niet begrepen die er verloren wordt door wachten op de gebruiker bij: * messageboxen die gegeven worden en wachten op clicken op OK door de gebruiker * wachten op input van data door de gebruiker - param6: slaagresultaat van de export. Deze kan volgende waardes hebben: * STOP: de export is voortijd gestopt, omdat een bepaalde controle een blokkering opleverde * FAIL: de export is doorlopen, maar is afgekeurd omwille van een probleem met waardes van signaletiek/loongegevens bij een bepaalde uzk. * SUCCESS: de export is doorlopen en succesvol bevonden

Zie hier de query die dan kan gebruikt worden om de duur per combinatie op te vragen: select Type, Omschrijving, timestamp, duur, aantallonen, convert(decimal(12, 2), (duur / (aantallonen + 0.0000000001))) as DuurPerLijn_s from ( select type, omschrijving, param1 as timestamp, convert(int, param5)as duur, convert(int, param5) as aantallonen from LogTable where Type in ('137', '138') ... ) as t order by Type, timestamp

(EROP) #ALG - Een functie “HiantMsgBox” aangemaakt: deze roept de gewone VB-functie “Msgbox” op, maar houdt ook de duur bij van het wachten op de click op OK door de gebruiker Er is een functie “HiantMsgBox” bijgekomen binnen hiant. Deze roept gewoon de functie “MsgBox” op, maar houdt ook de duur bij van het wachten van de click op OK door de gebruiker. Aan het begin wordt de actuele tijd gemeten en na bevestiging door de gebruiker wordt de tijd gemeten. De duur in seconden tussen beiden wordt gemeten in seconden. Deze tijd wordt bijgeteld bij de variabele “lngUserInputWaitTimeSec” in Hiant. Men kan ahv. de variabele “lngUserInputWaitTimeSec” meten hoeveel tijd er opgaat aan wachten op de gebruiker bij “HiantMsgBox” en “HiantInputBox”. volgende is de werkwijze ivm. aftrekken van de tijdsduur van wachten op de gebruiker bij het meten van de tijdsduur van een proces: - de programmeur dient aan het begin van het te meten proces de variabele

Pagina 33/32

WHERE PEOPLE AND SOFTWARE MEET “lngUserInputWaitTimeSec” op 0 te zetten - Binnen elke “HiantMsgBox” en elke “HiantInputBox” wordt de tijd van wachten op de gebruiker bijgeteld bij variabele “lngUserInputWaitTimeSec” - de programmeur dient ervoor te zorgen dat hij de tijd uit “lngUserInputWaitTimeSec” aftrekt van de tijdsduur van het proces - vanzelfsprekend dient de programmeur elke “Msgbox” te vervangen door “HiantMsgBox” en elke “InputBox” door “HiantInputBox”. Bij vervangen van “InputBox” door “HiantInputBox” dient er wel op gelet te worden dat de volgorde van functie-parameters licht anders is.

(EROP) #ALG - De functie “HiantInputBox aangepast” aangepast, ivm. bijhouden van de duur van het wachten op input door de gebruiker De functie “HiantInputBox” is aangepast: aan het begin wordt de actuele tijd gemeten en na bevestiging door de gebruiker wordt de tijd gemeten. De duur in seconden tussen beiden wordt gemeten in seconden. Deze tijd wordt bijgeteld bij de variabele “lngUserInputWaitTimeSec” in Hiant. Men kan ahv. de variabele “lngUserInputWaitTimeSec” meten hoeveel tijd er opgaat aan wachten op de gebruiker bij “HiantMsgBox” en “HiantInputBox”. volgende is de werkwijze ivm. aftrekken van de tijdsduur van wachten op de gebruiker bij het meten van de tijdsduur van een proces: - de programmeur dient aan het begin van het te meten proces de variabele “lngUserInputWaitTimeSec” op 0 te zetten - Binnen elke “HiantMsgBox” en elke “HiantInputBox” wordt de tijd van wachten op de gebruiker bijgeteld bij variabele “lngUserInputWaitTimeSec” - de programmeur dient ervoor te zorgen dat hij de tijd uit “lngUserInputWaitTimeSec” aftrekt van de tijdsduur van het proces - vanzelfsprekend dient de programmeur elke “Msgbox” te vervangen door “HiantMsgBox” en elke “InputBox” door “HiantInputBox”. Bij vervangen van “InputBox” door “HiantInputBox” dient er wel op gelet te worden dat de volgorde van functie-parameters licht anders is.

(EROP) #LOO - Alle exports naar sociale secretariaten nagezien en getest: overal is functie “Msgbox” vervangen door “HiantMsgbox en de functie “Inputbox” door “HiantInputbox” Alle exports naar sociale secretariaten zijn aangepast en getest: overal is functie “Msgbox” vervangen door “HiantMsgbox” en de functie “InputBox” door “HiantInputBox”

(KART) #OPV - Vinkje ‘Toon automatische opvolgingen’ in de opvolgingenlijst, werkt niet altijd Als je vanuit het werknemeroverzicht of het bestellingenoverzicht komt, doet het vinkje

Pagina 34/33

WHERE PEOPLE AND SOFTWARE MEET ‘Toon automatische opvolgingen’ niets doordat dit niet is opgenomen in de code. Dit is nu aangepast. Technisch: Code toegevoegd in frmOpvLst.LoadOpvGrid: Select Case gbytTypeOpvolging Case 0 'sqlstring = sqlstring & IIf(gCO, " ", " where (t.wgnr in (" & gSteunkantoren & ") or klnr in ( " & gClientsAlwaysVisible & "))") sqlstring = sqlstring & IIf(gCO, " where 1=1 " & strExtraWhereAuto, " where (opvolging.wgnr in (" & gSteunkantoren & ") or kl.klnr in ( " & gClientsAlwaysVisible & ")) " & strExtraWhereAuto) Case 1 'sqlstring = sqlstring & IIf(gCO, " ", " where (klantid in ( select id from kl where wgnr in (" & gSteunkantoren & ")) or klnr in ( " & gClientsAlwaysVisible & "))") sqlstring = sqlstring & IIf(gCO Or BeperkLijsttotSteunkantoren = 0, " where 1=1 " & strExtraWhereAuto, " where (kl.wgnr in (" & gSteunkantoren & ") or kl.klnr in ( " & gClientsAlwaysVisible & "))" & strExtraWhereAuto) Case 2 ''''''''????????????????????? sqlstring = sqlstring & " where 1=1 " & strExtraWhereAuto Case Else sqlstring = sqlstring & " where 1=1 " & strExtraWhereAuto End Select

(EROP) #EXS - Aanpassing export naar HDP voor de artiesten - bij een artiest bediende dient node “code_notie_nr” ingevuld te worden met “AC”; bij artiest arbeider blijft “code_notie_nr” opgevuld worden met “A” Volgende is de uitleg van HDP ivm artiesten: 1/ Arbeider Een artiest kan als arbeider doorgegeven worden . Hiervoor zijn volgende velden van belang op tewerkstellingsniveau: TW => code_srt_wkn_nr = 10 TW => code_notie_nr = ‘A’ Met deze combinatie wordt het kengetal 046 gevormd. 2/ Bedienden Een artiest kan ook als bediende doorgegeven worden: Hiervoor zijn volgende velden van belang op tewerkstellingsniveau: TW => code_srt_wkn_nr = 01 TW => code_notie_nr = ‘AC’ Met deze combinatie wordt het kengetal 046 gevormd. De RSZ-bijdrage wordt berekend zoals voor een arbeider (108%).

Pagina 35/34


De programmatie van de export naar HDP is aangepast dienen te worden voor de artiesten: ingeval van een artiest bediende wordt nu bij veld “code_notie_nr” de waarde “AC” doorgegeven; bij een artiest arbeider blijft er “A” doorgestuurd worden.

(EROP) #OPV - Aanpassing opvullen opvolgings-grid binnen opvolgingslijstscherm; de grid wordt nu bij elke nieuwe invulling van de grid opnieuw geinitialiseerd, omdat er foutmeldingen kwamen bij een ander aantal kolommen of andere invulling van kolommen Volgende probleem trad soms op: De grid binnen het opvolgingsoverzichtscherm kan op verschillende manieren worden opgebouwd, oa. afhankelijk van het feit of men de checkbox “toon automatische opvolgingen” heeft aangevinkt. HIerbij verandert het aantal kolommen en/of is er een andere invulling van de kolommen. Bij deze gewijzigde opbouw van de grid trad er soms een runtime error op. Dit was te wijten aan het feit dat de grid-properties nog waren ingevuld met de data van de vorige load. De programmatie is nu aangepast zodat bij een nieuwe invulling van de grid eerst de grid-properties worden geinitialiseerd met lege waardes. Dit zorgt dat het probleem niet meer optreedt.

(TOSE) #FAC - Import van excel voor gezinsbijdrage (ASAP HOME SERVICE) Mogelijkheid is ingebouwd om automatisch manuele fakturen aan te maken in een lege facturatierun op basis van een vooraf gedefineerde excel. Menu moet opgezet worden met een changecontrols parameter (changecontrols,frmfrberlst,sub4(19).visible,1) Systeem vraagt dan naar de facturatierun. Indien deze niet gevonden wordt, krijgt de gebruiker een melding. Indien wel gevonden maar heeft al status 1, wordt procedure gestopt. Ook indien in de run al gegevens zitten, zal de procedure stoppen. De excel bevat volgende kolommen, en hierop wordt ook gecontroleerd Kolom(1) = "WGNR" Kolom(2) = "KLNR"

Pagina 36/35

WHERE PEOPLE AND SOFTWARE MEET Kolom(3) = "AANTAL" Kolom(4) = "EENHEIDSBEDRAG" Kolom(5) = "TOTAAL BEDRAG" Kolom(6) = "BEGIN" Kolom(7) = "EINDE" Kolom(8) = "WEEK" De te gebruiken fakturatiecode komt uit volgende parameter "initialisatie", "importgezin", "fakturatiecode", "" De sektie is vast 915 De wnnr is vast 999999999 De vrijetekst in faktuurtransaktie zal steeds de melding “periode:dd/mm/yyyy-dd/mm/yyyy” bevatten. met begin- en einddatum die in kolommen BEGIN en EINDE zijn gevonden

(EROP) #LOO - Aanpassing programmatie voor opvullen SEPA-bankbestand, ivm. afhandeling van uzk met een chequenr De aanmaak van de SEPA bankbestanden is verder aangepast, ivm afhandeling cheques. Binnen frmLoonBer is naast de bestaande variabele Dim gStrChequeNummers As String nu ook variabele Dim gStrChequeNummersIBAN As String aangemaakt. Hierbinnen worden de IBAN's overeenkomend met de chequenrs (ConvertNumbertoIBAN van elk chequenr) opgeslagen (elk omgeven door een enkele quote). Worden nu opgenomen in een SEPA-bestand: - bankd.bedrag moet groter zijn dan 0 - bankd.betaal moet op 1 staan (dus men mag niet gedubbelclicked hebben op een lijn) EN OF - binnen de bankrun moet aangeduid staan "cheques via bank" OF - binnen de bankrun staat NIET aangeduid "cheques via bank", maar het ibannr zit niet in de lijst van "iban's overeenkomend met de chequenrs" (geldt dus sowieso voor de buitenlandse iban's)

(JAVA) #ALG Ticket 120978 - Overzichtslijsten - Instroom Bij deze lijsten wordt vanaf nu eerst de mogelijkheid gegeven 1 of meerdere kantoornummers te specificeren:

Wanneer je 0 ingeeft worden alle kantoren waartoe te gebruiker toegang heeft gebruikt.

Pagina 37/36


(PEZY) #DOC Ticket 121134 - TOF uitbreiding. Met de nieuwe PrintFacturatie module binnen Hiant is het mogelijk om meerdere TOF teksten te doen verschijnen op de facturen van de betreffenden klant. De TOF codes dienen natuurlijk eerst aanwezig te zijn in de vertaalUZB tabel. Hiant zal vervolgens eerst controleren op de TOFALWAYS code die op ALLE facturen dient te staan. daarna zal Hiant alle aanwezige TOF codes bij de betreffende klant plaatsen.

(TOSE) #FAC vrije tekst bij gezinsbijdrage ASAP Services. Wanneer men fakturatie van gezinnen doet via type 2, kan men nu ook een gestructureerde vrije tekst laten meegaan in de fakturen. Door de parameter "Factuur", "Vrijetekst", "Type",”0” op 2 in te stellen, zal bij dit type van fakturatie de vrije tekst in de faktuur als volgt worden samengesteld. vertaling uit vertaal(UZB)tabel met code familycontribution (taal van klant wordt gebruikt) gevolgd door de maand en jaar van de fakturatieperiode.

(KART) #CON klanten niet zichtbaar in lijst contracten. Indien PCA of PCB niet is ingevuld in de klantenfiche, wordt er soms NULL weggeschreven in de database en in dit geval worden de klanten niet opgenomen in de klantenlijst in het contract. Dit is gewijzigd. Ook als er NULL in de database staat. Technisch: Code aangepast in frmContgeg.ExtraWhere_KLCheckPc: Isnull-functie rond pca en pcb gezet.

(EROP) #CON - Bij toevoegen van contract (+ knop) op basis van een geselecteerd contract werden initieel niet meer alle cycli en roosters geladen van toepassing op deze kl/uzk combinatie Bij toevoegen van een contract (+ knop vanuit conctractenoverzicht) op basis van een geselecteerd contract (initieel wordt klant en uzk overgenomen van het geselecteerde contract) werden initieel niet meer alle cycli en roosters geladen, van toepassing op deze kl/uzk combinatie. Het was wel zo dat, indien men de kl of uzk binnen het contract wijzigde, de opzoeklijsten van cycli en roosters worden herladen. Ook indien men een contract aanmaakte vanuit een lege lijst van contracten (geen klant en uzk geselecteerd; men moest dus nog klant en uzk invullen [wijzigen] in het contract), dan werden bij invullen van klant en/of uzk de lijst met cycli en roosters herladen. Samenvattend trad het ongewenste dus enkel op in volgend geval: men maakte voor een uzk een contract voor een nieuwe week, waarbij men een contract voor dezelfde kl en uzk van een andere week had geselecteerd. Kl en uzk werden dus niet veranderd en bijgevolg laadden de lijsten met cycli en roosters niet met de cycli en roosters van de kl/uzk combinatie. De programmatie is aangepast om dit te verhelpen.

Pagina 38/37


(EROP) #FAC - Aanpassing wegschrijven info berekenen facturen in de logtable - in bepaalde gevallen was er bij de bestaande programmatie een fout indien er zeer vele jaar-systeem-periode-klnr-wnnr combinaties voorkwamen binnen de facturatierun → type variabele aangepast van integer naar long Sinds kort wordt er bij het berekenen van een facturatierun info weggeschreven binnen de logtable ivm. tijdsmetingen. Hier was nog een probleem mee: indien er binnen de facturatierun zeer vele jaar-systeem-periode-klnr-wnnr voorkwamen, trad er een fout op. Het datatype van een variabele is aangepast moeten worden van integer naar long om dit probleem te verhelpen.

(EROP) #LOO - Bij gebruik van de nieuwe Edocs-functionaliteit was het zo dat bij afdruk/mailen van loonbrieven voor een gesplitste week (en voor het geval men de weekdelen samenneemt in 1 loonbrief) er 2 loonbrieven werden afgedrukt/gemaild Bij gebruik van de nieuwe Edocs-functionaliteit was het zo dat bij afdruk/mailen van loonbrieven voor een gesplitste week (en voor het geval men de weekdelen samenneemt in 1 loonbrief) er 2 loonbrieven werden afgedrukt/gemaild. De programmatie van het loonbrief-programma is aangepast om dit te verhelpen.

Pagina 39/38

WHERE PEOPLE AND SOFTWARE MEET

Recommend Documents