Release notes IBS - CGA 4.4 (06/12/2013) (Van 13/09/2013 t/m 10/12/2013)

Transcriptie

1 Release notes IBS - CGA 4.4 (06/12/2013) (Van 13/09/2013 t/m 10/12/2013) Opgesteld door: Mark Verschuren/Ton van de Ven Eindhoven d.d. 06/12/201 Laatst bijgewerkt op 10/12/2013 Bizon Software B.V. Luchthavenweg 99-b, 5657 EA EINDHOVEN

2 Inhoudsopgave SEPA & Techniek... 4 SEPA uitgaand; PAIN Bestand... 4 Bank export formaat afhankelijk van Sepa parameter... 4 PAIN Incasso bestandnaam te lang... 4 SEPA: Naam begunstigde 'leeg' bij maken PAIN... 4 Clieop: Afwijkende tekens... 4 Clieop: velden vaste lengte... 5 Batchverwerking optioneel... 5 Opdrachten en BIC... 5 PAIN: Uitvoerdatum SEPA incasso... 5 Incasso Storno & Onderhoud machtiging... 5 SEPA: Import bankmutaties:... 8 Swift Structured: herkennen tegenrekening... 8 Geen herkenning ivm BBAN in Swift... 8 Import ING MT940 structured... 8 TB pluginn i.c.m. geen tegenrekening... 9 Import Swift; Bepaling tegenrekening in Plugin... 9 Import SWIFT; TAG25 icm IBAN... 9 Machtiging beheer, Lijstnummer blijft Auto conversie naar IBAN via WebService Betaalopdrachten administratie Fiatteren Reservingen in cliëntsaldo Digitaal Dossier voorzien van Zoekbalk Saldo tonen bij Bulkinvoer Betaalregels Ja Nee; leefgeld wijzigen Behandel afgewezen betaalregels, Performance verbetering Opdrachten; BIC code wijzigbaar Waarschuwing icm reservering 'Van Bankrekening' wordt niet getoond Behandel afgewezen betaalregels; eigen rekening fout Centrale kas locking Registratie opdrachten - Doorklikken Rapportage Dagafschrift; lengte omschrijving Dagafschrift + begroting Clientbegroting versus werkelijkheid; Telfout Verantwoording kantonrechter Formaat Centrale kas Kwitanties Cliënt begroting --> sortering Nieuwe uitvoer PDF Logo's in Rapporten Interfacing Import Cura cliënten PrePaidDebetCard import PrePaidDebet Card Interface webkbb Import clientstamgegevens - controle bankrekeningnummer Unieke sorteercode Distributie Import Psygis: bedrijf aansturing mbv Afdeling

3 Stamgegevens Adres afleiden van Postcode Intake; Prioriteit na quick scan Onderhoud schuld meer kolommen Query werkelijk/begroot - sortering Begroting genereren vanuit opdrachten Cliënten samenvoegen Opschonen dubbele relaties Adresboek Generator

4 SEPA & Techniek SEPA uitgaand; PAIN Bestand Bank export formaat afhankelijk van Sepa parameter Formaat wordt nu obv parameter SEPA-status bepaald ipv via opstartscherm. Keuze op opstartscherm bank bestand beperken ivm meldingen ontbrekende machtiging en voorkomen van gebruikers fouten. De Sepa-status parameter kan 3 waarden bevatten, afhankelijk v.d. waarde wordt een bestand formaat gekozen: -Niet -Altijd Clieop -Over op IBAN -Altijd Clieop -SEPA Klaar -Altijd PAIN/SEPA de keuze is dus niet meer te maken via het opstart scherm maar wordt bepaald adhv de parameter waarde, de klant bepaald nog steeds wanneer hij overgaat op het aanleveren van PAIN. Wil de klant weer terug naar Clieop dan kan de parameter weer op Over op IBAN teruggezet worden. Functie: Ca.cmedi PAIN Incasso bestandnaam te lang Klanten maken vaak 2 keer per dag een betaal bestand aan, het komt wel eens voor dat een eerder op de dag aangemaakt bestand wordt overschreven met een nieuw bestand dit is niet wenselijk, graag bestandsnaam uniek maken door datum/tijd of Journaalpostnr op te nemen in de bestandsnaam. Nu worden JP Nummer, alsmede de bedrijfscode in de bestandsnaam gezet. De bestandsnaam kan nu te lang worden (> 35 characters) waardoor het PAIN bestand wordt afgekeurd, zie bijlage van de ING. (SEPA) De foutmelding lijkt uitsluitend betrekking te hebben op het MsgId in het bestand, niet op de bestandsnaam zelf. Maar onze bestandsnaam wordt tevens in het MsgId gezet. Daar is nu de.xml extensie vanaf gehaald, dan past het precies: XXXX XXXXXXXX-CORE-Incasso is precies 35 posities lang (Bedrijf-Lijstnummer-BIC-CORE-Incasso) SEPA: Naam begunstigde 'leeg' bij maken PAIN Indien in het PAIN bestand de naam van begunstigde niet gevuld is komt er een foutmelding bij de import in het bankpakket, ingeval dat de naam begunstigde niet gevuld is, zal deze bij aanmaak van het PAIN bestand gevuld worden met de waarde 'NoName'. Clieop: Afwijkende tekens Aanpassing voor aanmaak Clieop bestand: De richtlijnen voor aanleveren van Clieop zijn bij oa ING aangescherpt bepaalde tekens wordne niet meer geaccepteerd, voor het clieop formaat worden nu door de ING niet geaccepteerde tekens omgezet naar wel acceptabele tekens. Programma's: ca/pmedi.p 4

5 Clieop: velden vaste lengte Alle velden in een ClieOp bestand hebben een vaste lengte (en de regels dus ook). Enige tijd geleden is een aanpassing gedaan, omdat blijkbaar bepaalde tekens (zoals é of ü) niet meer worden toegestaan in dit bestand. Daarbij is iets fout gegaan, waardoor de velden niet meer die vaste lengte hebben. Is nu weer aangepast. ca/pmedi.p Batchverwerking optioneel Voor CGS/IBS kan nu in een systeemparameter 'TB.fbatc' worden aangegeven of de terugmelding door de bank per Batch (YES) of per Transactie (NO) moet plaatsvinden.ca/cmedi.p Opdrachten en BIC Een klant meldt dat er soms geen BIC code automatisch wordt ingevuld bij het invoeren van nieuwe opdrachten De oorzaak is achterhaald, de BIC code wordt alleen automatisch gevuld voor een aantal NL banken, er is een soort van vertaaltabel (BIC lijst) op basis waarvan je vanuit een IBAN de BIC code kunt afleiden De interne BIC lijst in CGA bevatte niet alle NL banken. De bankenlijst is nu aangevuld zodat bij een volgende update de papieren lijst niet meer nodig hebt. Volledige lijst van NL-banken is nu opgenomen in de IBAN naar BIC routine PAIN: Uitvoerdatum SEPA incasso Het programma ca.pmedi is recent aangepast achtergrond: FIRST incasso opdrachten werden te laat aangeleverd, volgens de Sepa spelregels dienen deze 6 werkdagen VOOR de aangegeven uitvoerdatum aangeleverd te worden. Wij hebben altijd begrepen dat de BANK de aangeleverde uitvoerdatum (in PAIN=ReqdColltnDt) gaat verleggen (verrijken) naar een uitvoerdatum die wel in het PAIN aanlever schema valt, dit blijkt niet bij alle banken het geval te zijn, we hebben toen bij FIRST incasso de uitvoerdatum op Today + 1 gezet, ook dit blijkt voor de ING bank niet voldoende. Om verdere werkzaamheden aan deze functie te beperken hebben we het verrijken volledig aan onze kant geregeld, zodat de uitvoerdatum door alle banken geaccepteerd worden. Hoe wordt de uitvoerdatum voor Incasso opdrachten bepaald: 1. CORE: a. FRST: Regel die voor alle banken geldt: Today + 6 werkdagen, b. RCUR: RCUR= Today B2B: Voor FRST en RCUR geldt hetzelfde: Regel die voor alle banken geldt: Today + 2. Toelichting: * Today = aanmaak datum pain bestand mbv functie Boeken en Bankbestand. ** betaalopdrachten; ingegeven uitvoerdatum blijft van toepassing zonder verrijking. *** Indien de ingegeven Uitvoerdatum verder in de toekomst ligt dan de verrijkte uitvoerdatum wordt de ingegeven uitvoerdatum in het Pain bestand gezet. Incasso Storno & Onderhoud machtiging Reject codes mbt Niet uitgevoerde incasso's worden door de bank via CAMT.053 doorgegeven. Daar werd in IBS/CGS niets mee gedaan. 5

6 We moeten klanten toch een mogelijkheid bieden ingeval van een storno, er voor te zorgen dat een incasso opdracht de volgende keer weer als 1e (eerste) wordt aangeboden. Bij onderhoud Machtiging dient een mogelijkheid te komen om deze rubriek (lijstnr) te onderhouden. Programma: tb/mtbmnd Het onderhoud van de machtiging wordt ook aangepast tbv CGS/IBS, klanten van deze pakketten willen vaak het cliëntnummer als machtigingskenmerk gebruiken. Dit kan, en is ook geen enkel probleem, alleen dient het systeem (onderhoud machtiging) hier op aanscherpt te worden, dwz in de situatie dat je 2 cliënten in CGS/IBS hebt gekoppeld aan hetzelfde afrekencontact (de debiteur/iban waar de incasso op losgelaten wordt) dient bij wijziging van het machtigingskenmerk de eerst keer indicator (=lijstnr) bij die machtiging weer AAN gezet te worden. Voorbeeld: Client: 5402 Henk de Vries is sinds 2009 cliënt, Vader Jos de Vries betaald zijn rekening (mbv Incasso) in 2013 wordt zijn jongere broer ook opgenomen: Client: 5853 Karel de Vries, bij het afreken contact = Jos de Vries wordt de machtiging aangemaakt, wat blijkt er is al een machtiging mooi is al geregeld; advies niets doen. indien klant toch een machtiging heeft gestuurd met machtigingskenmerk = 5853 kan de gebruiker het machtigingskenmerk wijzigen maar dan dient het systeem de eerst volgende incasso wel weer als EERSTE (FIRST) aan te bieden. (maw er is een extra controle toegevoegd). In geval van een storno dient de gebruiker ook de mogelijkheid te hebben de machtiging gegevens aan te passen zodat de volgende keer dat onder deze machtiging weer een incasso wordt aangeboden deze weer als FIRST aangeboden wordt, dit moet in de volgende situatie: Incasso opdracht is als FRST aangeboden en rejectcode = 1 of 5, in alle overige situatie mag de incasso de volgende keer als RCUR aangeboden worden. Om de juiste keuze te kunnen maken heeft de gebruiker dan wel de Rejectcode nodig Oplossing: inlezen van de rejectcode bij import swift structured/camt in Bankregelomschrijving. 6

7 Samenvatting wijzigingen: 1. Onderhoud machtiging -Journaalpost nr wordt wijzigbaar; blanco betekent eerst volgende incasso wordt als FIRST Aangeboden, Hier staan nu ook de 'Eerste Lijst' en een 'Eerste'-button op. -Indien het machtiging kenmerk wordt gewijzigd (nav incasso 2e broer) wordt automatisch het journaalpostnr blanco gemaakt. 2. Behandel bankmutaties Punt 1: Aanpassen 'Onderhoud machtiging'. Enkele aanpassingen gedaan om direct inzicht te kunnen verkrijgen in machtigingsinformatie: Functie 'tb.mtblin' (Behandelen Bankmutaties): Storno via Import bankmutaties: Indien een door IBS/CGA aangemaakte incasso opdracht niet wordt uitgevoerd, zal de bankmutatie (reject) paars worden de bijbehorende opdracht kan opgevraagd worden via de nieuwe knop Betaalregel. In het grijze vlak staat nu ook het machtigingskenmerk en de volgorde; Eerste of volgende. Nieuwe button 'Betaalregel' voor het opvragen van de betreffende details. Deze button is alleen zichtbaar wanneer aan de geselecteerde regel een betaalregel is gekoppeld (fgpstl.rsequpm > 0). Functie: Opvragen Betaalregel (ca.qcapmt1): Indien opgevraagde betaalregel betrekking heeft op een incasso, wordt nu ook informatie getoond betreffende machtigingskenmerk en volgorde van de incasso. Deze volgorde kan de volgende waarden hebben: - Geen machtiging gevonden: "Machtiging niet gevonden" 7

8 - Nummer 'Eerste lijst' is 0: "Nog geen incasso uitgevoerd" - Nummer 'Eerste lijst' is gelijk aan journaalpostnummer volgens betaalregel: "Dit was de eerste incasso" - Betaalregel is (nog) niet uitgevoerd (journaalpost <= 0): "Er is eerder geïncasseerd" - Alle overige gevallen: "Dit was een vervolg incasso". SEPA: Import bankmutaties: Swift Structured: herkennen tegenrekening Het inlezen van een swift structured werkt volgens de techniek: alles in tag 86 wordt netjes ingelezen. Voordeel van structured aanlevering in tag 86 is dat er codes in zitten, dus ook de code waarop de tegenrekening van de regel volgt. Helaas zijn deze per bank verschillend. de formattering van Swift structured is als volgt: :86:/ACCW/ /BENM//NAME/Graafland/REMI//IBS / Leefgeld :86:/EREF/ /ACCW/NL76RABO ,RABONL 2U/ORDP//NAME/KRINGLOOP MIDDEN-HOLLAND/REMI/N.A.G.J. de Rooij, sa laris/code/waarde van de code. Bovenstaande voorbeelden zijn van de Rabobank. Codes voor de tegenrekening: Rabobank: /ACCW/ rekeningnummer van de tegenpartij, plus BIC of lokale bankcode. ING: /CNTP/ Counterparty ID(131x) [ACCOUNT/[BIC]/[NAME]/[CITY] ABN: /IBAN the IBAN of the account of the originator afvangen tegenrekening is toegevoegd aan verwerkingsroutine inlezen telebanking. Functie: tb.ptblin Geen herkenning ivm BBAN in Swift De IBS Plug-in gaat niet goed om met de herkenning van BBAN in de ingelezen bankmutaties indien de opdrachten al IBAN nrs bevatten. Klant is over op IBAN, in het ingelezen Swiftbestand staan als Tegenrekening nog BBAN rekeningen. De tegenrekening is voor IBS/CGS klanten zeer belangrijk om de bankmutatie te kunnen boeken. Voor IBS/CGS wordt de herkenning uitgevoerd in 2 stappen: 1. IBS PlugInn 2. TB Maskers Ik constateer dat de vastgelegde inkomstenbron (=opdracht) NIET gevonden wordt omdat de tegenrekening in de bankmutatie een BBAN is. Ook in deze situatie zal de herkenning BBAN -> IBAN nu WEL plaatsvinden. Functie: tb/pmtcibs.p Import ING MT940 structured Bij de klant heeft men getest met het MT 940 Structured formaat. Dit geeft voor de geïmporteerde mutaties de foutmelding ** Decimaal getal is te groot. (536). 8

9 Het lijkt erop dat de er vreemde tekens in het veld tegenrekening gezet worden. Het bestand wordt uiteindelijk wel geïmporteerd maar de tegenrekening is incorrect. De routine die de tegenrekening uit het bank bestand probeert te halen is op dit punt aangepast zodat de foutmelding niet meer komt. TB pluginn i.c.m. geen tegenrekening De telebanking Plugin is een routine die belangrijk is voor de automatische herkenning van bankmutaties obv oa eigen rekening en tegenrekening zal deze routine binnen de cliënt/opdrachten administratie opzoek gaan naar herkenning zodat de tegenboeking gemaakt kan worden, na de Pluginn worden de maskers toegepast. Aanpassing: Indien bankmutatieregel-tegenrekening leeg is dan de IBS Plugin niet toepassen. Programma's: tb/pmtcibs.p Achtergrond: - Er een opdracht soort P of I is zonder een tegenrekening. (bijv. vanuit opdrachten verkort) - We lezen een bankafschrift in, met daarin één of meerdere transactie(s), zonder tegenrekening - De pluginn deze gaat 'herkennen, omdat het bankrekening is gelijk (=leeg) en indien in betaalkenmerk eenzelfde 'kenmerk' staat als in de bankomschrijving? Indien deze situatie zich voordoet levert dat na de aanpassing geen probleem meer op. Import Swift; Bepaling tegenrekening in Plugin Ook Bij incasso's met return code MARF wordt nu de tegenrekening gevonden Het SWIFT MT 940 stuctured van de ING bevat in geval van retourinformatie mbt een automatische incasso, PREF en MARF Codes. De MARF code is de Mandate Reference. achter deze code staat de bankrekening van de tegenpartij. Deze wordt niet opgenomen in het veld tegenrekening. Wanneer de klant kiest voor batch bij het inlezen van het incasso bestand staat er geen tegenrekening in veld 86. :86:/BUSP/Europese Incasso///PREF/1//REMI///TOTAAL 5 POSTEN/ Toch wordt er een tegenrekening in het veld opgenomen, het betreft hier de eigen rekening. Dit doet zich alleen voor bij het eerste record van het SWIFT bestand. Waarschijnlijk zelfs alleen als het eerste record de bijschrijving van het incasso bedrag is. Rekening wordt als tegenrekening opgenomen. Programma's: tb/ptblin.p Ook bij incasso's met returncode MARF wordt nu de tegenrekening gevonden de Returncodes worden nu ook opgenomen in de omschrijving Import SWIFT; TAG25 icm IBAN Er zijn wat wijzigingen geweest mbt de invulling van tag25 in het swift bestand waardoor de herkenning werd verstoord, er is een aanpassing doorgevoerd waardoor nu ook een IBAN rekeningnummer correct ingelezen wordt. Machtiging beheer, Lijstnummer blijft 0 Bij het aanmaken van de incasso lijst wordt het lijstnummer niet altijd correct werd bijgewerkt. De datum wordt wel netjes bijgewerkt. De bedoeling was (en is) dat het journaalpostnummer in de 'Eerste lijst' bij de incassomachtiging wordt gezet. Is nu aangepast. 9

10 Auto conversie naar IBAN via WebService Bij het invoeren van betaalopdrachten dient na Sepa het lange IBAN nummer ingevuld te worden, het belang van een goed gevuld adresboek zal hierdoor toenemen. Om de overgang naar deze lange IBAN nummers te verzachten kunt u deze Web service aanzetten. De werking van de Web service is vergelijkbaar met de IBANBIC service, voor Nederlandse rekeningnummers kunt u gewoon het korte oude bekende bankrekeningnummer invullen de WEB service zet deze direct om naar de bijbehorende IBAN, vervolgens wordt de opdracht eventueel verrijkt met de Naam en plaats vanuit de CGS/IBS database. Deze web service is Ingebouwd in de centrale routine die zowat overal wordt aangeroepen om een bankrekening te controleren. De routine wordt aangeroepen onder de volgende condities: U kunt er zelf voor kiezen om deze Web service te gebruiken, mbv de systeem parameter - Sepa-Plus= YES Overige voorwaarden: - De SEPA-status is Over op IBAN of Sepa klaar - De ingegeven (of anderszins aangeleverde) bankrekening is 3 tot 10 posities lang Opmerking: Gebruik deze web service als een tijdelijk hulpmiddel om de overgang naar Sepa/Iban te verzachten, de gebruikers moeten in de tussentijd het adresboek wel verder vullen. De Web service is niet van Bizon Software wij verzorgen enkel de toegang en u bepaald zelf of u deze service gebruikt of niet. Hoelang deze web service actief blijft kunnen wij niet aangeven, dus het advies is ga voor een toekomst vaste oplossing, geef IBAN nummers in en leg vaak voorkomende relaties vast in het adresboek. Betaalopdrachten administratie Fiatteren. Indien bij fiatteren op de infobutton bij Schuld gedrukt werd (en er geen schulden-combinatiecode "CS" bestond) kwam de FIND FIRST/LASt Progress foutmelding deze situatie is nu netjes afgevangen. Reservingen in cliëntsaldo In het Rekeningafschrift werden de reserveringen meegeteld in het totaalsaldo, dit is niet correct en is nu gecorrigeerd. Programma's: ca/rcltm.p Digitaal Dossier voorzien van Zoekbalk Binnen het Digitaal Client Dossier kan nu ook worden gezocht met de nieuwe woord-index. Met het ixware (OCR-herkenning software) resultaat kan bijvoorbeeld al voor veel documenten een rubriek toegekend worden. Deze 'nieuwe' zoekingang/filter biedt de gebruiker de mogelijkheid om in een mum van tijd bij elk document de juiste cliënt/factuur, etc. aan te wijzen. 10

11 Nieuwe zoek functie Digitaal Dossier: Functie ut.pconn (Documenten Koppelen per Tabel) Saldo tonen bij Bulkinvoer Bij vastleggen opdracht via Bulkinvoer ook saldo tonen naast de vanaf bankrekening? Beheerrekening = caclt.abala CX (overige)rekeningen = tbacn.abala Nu moet men altijd nogmaals klikken om te bekijken wat het saldo is van de cliënt. Twee aanpassingen op 'Bulkinvoer Opdrachten': - Naast het keuzeveld voor 'Eigen Rekening' wordt nu ook een saldo getoond. Als hier de standaard rekening wordt gekozen (Beheerrekening of Bedrijfsrekening) dan wordt het cliëntsaldo getoond. Let op, dit kan dus afwijken van het bijbehorende banksaldo. Bij een afwijkende rekening (bijvoorbeeld spaarrekening) wordt wel het banksaldo getoond. - Knop 'Cliënt' voor het opvragen van de cliëntdetails is nu altijd aanklikbaar, dus ook bij invoeren nieuwe opdracht. Betaalregels Ja Nee; leefgeld wijzigen Leefgeld afhandeling bij onvoldoende saldo is verbeterd/aangepast Idee Vanuit denktank: Splits Knop tbv Leefgeld Indien saldo te laag (status betaalregel=nee) en het betreft leefgeld dan wordt deze knop actief, dit wordt getriggerd indien de tegenrekening (rekening begunstigde) = aan de leefgeldrekening van de cliënt dan volgt de speciale leefgeld afhandeling. Het idee hier achter is dat Leefgeld voor de cliënt heel belangrijk is, indien niet het gehele bedrag maar wel een gedeelte van het geplande leefgeld betaald kan worden kan dit nu mbv deze nieuwe optie soepel geregeld worden. Er komt een klein scherm waarop het beschikbare saldo wordt voorgesteld. Voorbeeld: Leefgeld opdracht = 50,00, beschikbaar saldo = 38,50 Voorstel Splitsknop: Oorspronkelijk bedrag: 50,00 Nu betalen: 38,50 (wijzigbaar) Later betalen: 12,50 (wijzigbaar = oorspronkelijk - nu betalen) 11

12 het bedrag en status van de bestaande betaalregel wordt aangepast en er wordt een nieuwe betaalregel aangemaakt indien het afgesplitste bedrag ingevuld is. Extra: je kan ook direct mbv de radio button een filter instellen op deze leefgeld situaties, alleen geblokkeerde (leefgeld) betalingen worden getoond. Aanvulling signalering: Graag op het verslag van de functie Maak betaalregels (ca.pcapmt), in de recapitulatie de bestaande regel "Regels geblokkeerd voor betaling" splitsen, Huidige opzet: Regels geblokkeerd voor betaling: 42 Nieuwe opzet: Regels geblokkeerd voor betaling: 37 Leefgeld Regels geblokkeerd voor betaling: 5 12

13 Extra regel mbt Geblokkeerde Leefgeld opdrachten: Functies: ca/papof.i ca/pcapmt.p ca/ppmtf.p ca/ppmtsp.p rpt/ca.pcapmt.rpt Behandel afgewezen betaalregels, Performance verbetering Betere indexsturing zorgt voor grote verbetering Programma's: ca/mcapmt.p Opdrachten; BIC code wijzigbaar Bij betaal- en inkomensopdrachten kan nu ook de BIC worden gewijzigd. Waarschuwing icm reservering Bij aanmaken betaalopdrachten kwam een (soms onterechte) melding dat er een saldotekort zou ontstaan, dit werd veroorzaakt door reserveringen die wel als betaling werden meegenomen in het saldo, dit was natuurlijk niet correct en is nu aangepast. 'Van Bankrekening' wordt niet getoond Bij een opdracht kan al geruime tijd een afwijkende 'Van Rekening' worden aangegeven. Je kunt dan betalingen verrichten vanaf bijvoorbeeld een spaarrekening. Standaard lopen de inkomsten en betalingen via de beheerrekening van de cliënt (indien ingevuld) of de centrale cliëntgeldenrekening van het bedrijf. In dat geval wordt een streepje '-' ingevuld in de 'Van Rekening'. Bij het aanmaken van inkomensopdrachten vanuit het boeken van bankmutaties 13

14 (functie behandel bankmutaties Knop 'Inkomsten') werd hier echter toch een bankrekening ingevuld. Omdat de bestaande inkomensopdrachten worden geselecteerd met een filter op 'Van Rekening = Streepje' werden de opdrachten vervolgens niet meer getoond. Dit is aangepast zodat ook deze opdrachten getoond worden. De controlefuncties ca.ccaclt* voor het controleren van cliënten en afdelingen, zijn tevens aangepast om dergelijke fouten te kunnen aanwijzen. Behandel afgewezen betaalregels; eigen rekening fout Indien je via de functie behandel afgewezen betaalregels een opdracht gaat reanimeren (via knop Opdracht) gaat het fout indien de Eigen rekening van de onderliggende opdracht niet de Beheerrekening is van de cliënt. Stel ik heb een betaalopdracht van Spaarrekening naar beheerrekening, deze opdracht komt na X keer proberen in het bakje Behandel Afgewezen betaalregels, indien je nu via knop Opdracht een nieuwe opdracht wenst te maken wordt de Eigen rekening (was spaarrekening) overruled/gedefaulteerd op de Beheerrekening, dit is niet goed. De oorspronkelijke VAN rekening van de gerelateerde opdracht moet natuurlijk als default voorgesteld worden. De bankrekening werd wel goed voorgesteld, maar helaas op de achtergrond niet goed overgenomen, dit is nu gecorrigeerd. Maak Betaalregels gebruikers tikken regelmatig een te hoog aantal dagen in bijvoorbeeld 12 ipv 2, gevolg de Helpdesk moet aan de slag. Graag de opzet van het opstartscherm wijzigen zodat de kans op invoer fouten minimaal wordt, het aantal dagen dat je kan ingeven is nu beperkt tot 1 positie dus maximaal 9 dagen vooruit. Centrale kas locking Centrale kassier doet kasuitgifte middels kasafspraak of extra kasopname. Dit wordt doorgeboekt en er wordt een kwitantie aangemaakt. Precies op hetzelfde moment betaald een decentrale kassier een kaslijst uit. Deze gebruiker krijgt een melding dat de tabellen gelocked zijn door de centrale kassier. Sinds de laatste aanpassing worden de meeste locks al snel vrijgegeven. Er waren echter nog twee records die langer dan strikt noodzakelijk in gebruik bleven, ook die locks worden nu veel sneller vrijgegeven, waardoor het probleem niet meer voorkomt. 14

15 Registratie opdrachten - Doorklikken Doorklikken naar cliëntdetails Bij het vastleggen van opdrachten kan het handig zijn om door te kunnen klikken naar cliëntdetails zonder de opdracht af te sluiten. We kennen deze optie bijvoorbeeld ook bij de bulkinvoer dat er doorgeklikt kan worden naar de functie: cliënt info. Button 'Cliënt' voor het opvragen van details is toegevoegd. Van de vier speciale opties op dit scherm (Historie, Logging, Document, Cliënt) is dit de enige die ook aanklikbaar is wanneer nog geen opdracht is geselecteerd. Voor de andere opties wordt een melding gegeven 'Er is geen opdracht geselecteerd'. Rapportage Dagafschrift; lengte omschrijving Velden verschoven en opgerekt Programma's: ca.rclth.rpt Ivm beperkte ruimte op dit overzicht werd de omschrijving ingekort, hierdoor kan essentiële informatie weg vallen. Veld omschrijving is opgerekt ten koste van datum Ook de datum- en pagina notatie is nu volgens de standaard Dagafschrift + begroting In het Dagafschrift + begroting (ca.rcltmb + ca.rcltmb2) graag grootboek-rekening cliënt banken CX onderdrukken. Dit is de grootboek-rekening die gekoppeld is aan het dagboek met type CX. De totaaltelling graag plaatsen onder de in/uitgaven-rekeningen. De spaarrekening(en) komen hier achter, hiervan hoeven alleen de af- en bij mutaties getoond te worden (informatief). 15

16 In de details staat in de kolomkop 2x 'Rekening' naast elkaar (voor GB-rekening en bankrekening). Lijkt me duidelijker om hiervoor een andere benaming te gebruiken? Graag het 2e veld 'rekening' (met daarin de bankrekening) oprekken met 1 positie zodat de IBAN-nummers van 15 posities er ook in passen. Hiervan valt nu het laatste cijfer weg. Programma's: ca/rcltmb.p Clientbegroting versus werkelijkheid; Telfout Totaaltelling in dit rapport werd niet geinitialiseerd, nu wel. Functie: ca.clbdg2 Verantwoording kantonrechter Er is nav de Mini verreken functionaliteit een derde vaste rekening mbt afrekening toegevoegd (413.C,3) de verantwoording neemt deze vaste rekening nu ook mee. Programma's: ca/rkanton.p Formaat Centrale kas Kwitanties. Ivm de mogelijkheid tot keuze voor A4 of A5 formaat van de kwitanties zijn er 3 nieuwe RPT s gekomen. Obv systeem parameter pcash.cform kan de voorkeur aangegeven worden (waarde A4 of A5, indien niet gevuld dan A4) Cliënt begroting --> sortering met de ingegeven sortering op het opstartscherm werd in het programma niets gedaan, dit is nu aangepast. Functie: ca/clbdg.p Nieuwe uitvoer PDF Als men een rapport heeft gedraaid en dit eerst op het scherm wil bekijken (view) kan men daar met de blauwe pijltjes doorheen bladeren dat werkt op zich prima. Echter willen heel veel klanten 'gewoon' scrollen met het muiswiel, dit kan helaas niet. De bestaande uitvoer VIEW toont een rapport met de Crystal Report Viewer. Werkt prima, maar heeft ook een aantal nadelen. Bijvoorbeeld de scroll is niet zo fijn. Daarom nu een nieuwe methode om het Rapport op het scherm te tonen. We hebben een nieuwe Uitvoer gebouwd waarmee een PDF wordt aangemaakt, deze PDF wordt met de standaard PDF reader die men gebruikt geopend/getoond (meestal Adobe Reader) Deze nieuwe uitvoer werkt prettig en biedt meer mogelijkheden vandaar dat we deze nieuwe uitvoer als standaard VIEW hebben ingesteld, de bestaande VIEW is hernoemd naar CRVIEW (voor gebruikers die de oude VIEW nog willen gebruiken). Hoe wordt de schermpositie bepaalt van acrobat reader. Antwoord: linksboven positie wordt onthouden. Samenvatting: - na opstarten rapport kan er doorgewerkt worden in IBS/CGS - Uw eigen standaard pdf reader wordt gebruikt, - maken van opmerkingen direct in scherm, - Eenvoudig scrollen met de muis door alle pagina's, - Digitaal Ondertekenen van documenten, - via icoon direct opslaan, printen of mailen, 16

17 - eenvoudig in- en uitzoomen, Bestaande uitvoer VIEW is geconverteerd naar CRVIEW De nieuwe uitvoer PDFSHOW heet nu VIEW zodat men geruisloos overgaat op de nieuwe Viewer. Logo's in Rapporten Klanten willen op rapporten die naar externen verstuurd worden vaak het eigen Logo afdrukken. De manier waarop dat tot nu toe gebeurde was niet optimaal, er is daarom een ver beterde opzet mbt Logo aansturing gekozen. Het eerste rapport dat met deze nieuwe opzet werkt is de verantwoording kantonrechter. Interfacing Import Cura cliënten Aanvullingen: Het BSN nummer wordt voortaan ook in het bestand aangeboden met komma's. De opnamedatum niet meer overgenomen.. PrePaidDebetCard import Het bedrag / teken werd niet goed opgepikt. De transacties die we doorkrijgen zijn 'kosten' (debet) maar worden als (credit) ontvangsten gezien. Het teken van de mutaties is omgedraaid. Overige aanpassingen: Tegenrekening werd gevuld met de eigen rekening, wordt nu leeg gelaten. tb/ppdebit.p - Tegenrekening is gevuld met accountnumber uit de kop van het bestand. Deze moet leeg zijn. - Opstartscherm selectie "Groepering" stuurt niet de opbouw van de Journaalposten aan. Aanpassing - tegenrekening leeg. Uitsplitsen JP komt door opstartscherm selectie op maximaal aantal regels... stond op 0. PrePaidDebet Card Interface webkbb Naast PIN (afd) filiaalpas transacties kunne sinds kort ook PrePaid Debet card transacties als rode (NTB) regels doorgegeven worden aan het Webkbb. Veld transaction_flexcard_costcentre wordt toegevoegd aan de in te lezen XML tbv PPDC boekingen: ia/pwebkbb2.p CGA wijzigingen: 1. Export NTB van CGA naar Webkbb. (fg.entbac) Ook indien het een Prepaiddebtcard mutatie betreft dient het veld Community met de afdelingscode (kaart-id) gevuld te worden. 2. Import webkbb Journaalpost in CGA. (ia.pwebkbb) Vanuit het Webkbb is een extra TAG toegevoegd aan de export Journaalposten, nl Transaction_FlexCard_costcentre, Indien Transaction_FlexCard_costcentre is gevuld, vul subcode-1 17

18 afdeling van de NTB boeking (PIN) met Transaction_FlexCard_costcentre anders met community (=huidige opzet) Import clientstamgegevens - controle bankrekeningnummer. Via de interface kunnen cliënt stamgegevens bijvoorbeeld via Excel geïmporteerd worden, de controle op aangeleverde banknummers, zoals Leefgeldrekening en Beheerrekening werden niet altijd gecontroleerd of deze bankrekeningen voldoen aan de 'binnenlandse 11-proef' of aan de IBAN proef! Deze controle werkt nu wel in alle situaties. Unieke sorteercode Distributie Bij overzichten die gesplitst moeten worden (voor uitvoer naar PDFS of MAILS) is het van belang dat elk record op het hoofdniveau een unieke sorteercode krijgt. Bij het gebruik van de distributielijst werden echter soms niet-unieke sorteercodes uitgedeeld. De oorzaak was weliswaar een data corruptie (de soortcontactpersoon gacnt.ccont is blanco), maar het leek ons toch goed om de betreffende programma's daartegen te beveiligen. Immers, het mag niet gebeuren dat een cliënt de cijfers van een andere cliënt in zijn inbox krijgt. Daarom nu een meer unieke sorteercode in de volgende functies: ca.rcltm Rekening Afschrift ca.rcltmb Cliënt Dagafschrift met Begroting ca.rcltmb2 Dagafschrift met Begroting/Cum ca.rcltmv Cliënt Verrekening ca.rcltpay Betalingsachterstanden ca.rcltrem Cliënt Aanmaning Import Psygis: bedrijf aansturing mbv Afdeling Bedrijf wordt nu niet meer aangeleverd, in het geval een klant meerdere bedrijven heeft wordt de juiste bedrijfscode afgeleid van de cliënt of indien het een nieuwe cliënt betreft, van de afdeling. Programma's: ia/clntibs2.p de import cliënten dient aangepast te worden nav 2 nieuwe bedrijven die toegevoegd worden aan het bestaande IBS. Op basis van de afdeling die bij de cliënt wordt aangeboden vanuit het EPD dient het bedrijf bepaald te worden. Stap 1 Zoek obv alleen cliëntnummer. Clientnummer is uniek over de 3 bedrijven, indien cliënt gevonden, controleer of aangegeven afdeling = IBS afdeling JA ; Wijzigingen doorvoeren Nee; Client afdeling NIET wijzigen WEL een Melding (3C1)?Bestaande Client, Afdeling Psygis is XXX, afdeling IBS=YYY? Stap 2 Nieuwe cliënt. De cliënt is in geen van de 3 bedrijven gevonden nu dient obv de meegegeven afdeling eerst het juiste bedrijf bepaald te worden, 18

19 Stamgegevens Adres afleiden van Postcode In diverse interactieve onderhoudsfuncties wordt nu het adres (straat en plaats) afgeleid van de postcode. Beide velden worden alleen gewijzigd indien postcode gewijzigd en gevonden in de postcodetabel. De gebruiker moet uiteraard nog wel even het huisnummer toevoegen aan de voorgestelde straatnaam. Met de systeemparameter 'INTERNET' kan worden aangegeven of er een verbinding bestaat met het internet, die is nodig voor deze functionaliteit. Deze webservice routine is nu ingebouwd in de volgende functies: ga.mgacnt Onderhoud Contact ga.mcarlt1 Onderhoud Relatie Bij gebleken succes en gewenst kunnen we hem uiteraard ook inbouwen in bijvoorbeeld: ca.mcaclt Stamgegevens Cliënt ca.mcaclta Onderhoud Afdeling ca.mcaclti Onderhoud Instantie ga.mcarltc Onderhoud Contactpersoon ga.p07 Onderhoud Bedrijf Intake; Prioriteit na quick scan Voor cliënten in de intake worden opdrachten ingevoerd via de Quick Scan (ca.mcltapo) In deze functie is het niet mogelijk om de prioriteit aan te geven (= juist goed) Op een later tijdstip gaat men de 'korte opdrachten' aanvullen, de standaard prioriteit staat dan op?, na bevestiging van de opdracht wordt dit 00. Dit zou eigenlijk de default prioriteit moeten zijn volgens parameter: caapo.rprio, prioriteit wordt nu ingevuld volgens de systeemparameter 'caapo.rprio'. Onderhoud schuld meer kolommen Nav de IBS denktank is de opbouw van dit scherm uitgebreid, nu worden ook de naam relatie, naam incassobureau en referentie getoond in het regelscherm Omdat een client vaak meer dan 25 schulden heeft is er behoefte aan meer kolommen in de functie schulden. Bij het opvoeren van een schuld staat omschrijving, op het schuldenoverzicht staat Inzake. Dit is gelijkgetrokken. 19

20 Query werkelijk/begroot - sortering In de query werkelijk/begroot werden de rekeningen niet gesorteerd, nu wel ca/qcltbdg.p Begroting genereren vanuit opdrachten nu worden vooraf alleen cliënt begrotingen weggegooid, dus de afdelingsbudgetten blijven bestaan. Functie: ca/cbdgapo.p Cliënten samenvoegen Bij cliënt samenvoegen worden de volgende zaken toegevoegd aan de nieuwe cliënt: -Caapo (Betaalopdrachten) -Utmtx (Memoteksten (digitaal dossier items) -Fgpstl, Fggnrh, fggnrc, tblin (Historische mutaties) De volgende zaken NIET: -Contacten -Schulden -Stamgegevens volgens mij moeten we contactpersonen en schulden gewoon meenemen naar de 'nieuwe' cliënt, de stamgegevens moeten we niet overnemen. Contactpersonen worden alleen samengevoegd indien de combinatie Relatie+SoortContact nog niet bestaat bij de doelcliënt. Dus als bijvoobeeld 'Begeleider Piet' al bestaat bij de doelcliënt, wordt die niet nogmaals aangemaakt. Als dezelfde relatie met als andere contactsoort bestaat, wordt hij nogmaals gekoppeld. Dus wanneer 'Begeleider Piet' is gekoppeld aan de oude cliënt, en 'Bewindvoerder Piet' is gekoppeld aan de doelcliënt, dan zal na samenvoegen de relatie 'Piet' twee keer als contactpersoon zijn gekoppeld aan de doelcliënt. Eén keer als Begeleider en één keer als Bewindvoerder. Er zijn echter een aantal 'Contactsoorten' die maximaal één keer mogen voorkomen per cliënt. Dat geldt bijvoorbeeld voor Afrekencontact, Curator, Kantonrechter, Partner en Rechtbank. Voor contactpersonen van deze soorten geldt dat ze alleen worden overgezet naar de doelcliënt indien de betreffende contactsoort nog niet is gedefinieerd bij die cliënt. Schulden wordt gewoon altijd samengevoegd. Wanneer de doelcliënt ook schulden heeft, zullen de schulden van de oude cliënt een nieuw volgnummer moeten krijgen. Op alle mutaties op die schulden is de tweede subcode ingevuld (Subcode 'Schuld'). Deze moet dan uiteraard ook worden aangepast. Opschonen dubbele relaties Nieuwe routine die dubbele relaties verwijderd, functie: ca.dcarltba Nav de overgang op IBAN zullen gebruikers meer gebruik gaan maken van het Adresboek (relatiebestand), het is dan zeer vervelend indien er eenzelfde Relatie meerdere keren met hetzelfde bankrekening voorkomt in het relatie bestand. MBV deze opschoon functie worden deze dubbelen verwijderd, opstart varianten: 1. Proef - alleen overzicht van de Relatie die bij keuze definitief verwijderd worden 2. Definitief - idem 1 maar nu worden de geselecteerde Relaties daadwerkelijk verwijderd 20

21 zie ook adresboek generator. Adresboek Generator IBS/CGS klanten gaan bij de overgang naar de SEPA (IBAN) versie moeite krijgen met het registreren van (betaal) opdrachten. Het IBAN nummer is vrij lang waardoor er snel invoer fouten zullen ontstaan, het kost ook meer werk, daarnaast verwachten wij dat de komende maanden nog heel vaak het oude vetrouwde BBAN bankrekeningnummer op het Bron document zal staan, de gebruiker dient dit via de IBANBIC service om te zetten naar een IBAN. De verwachting is dan ook dat klanten meer gebruik gaan maken van het Adresboek (Relaties) In feite bevat IBS al een dynamisch adresboek, obv bankrekeningnummer in het opdrachten bestand wordt een en ander al geregeld / gedefaulteerd. Het zou mooi zijn indien wij de klant een tooltje kunnen aanbieden waarmee het Relatie adresboek automatisch wordt gevuld vanuit het opdrachten bestand. Aandachtspunten / input tbv bouw van een Adresboekgenerator: Vanuit het opdrachten bestand zal obv de meest recente opdracht mbt een bankrekening, indien er nog GEEN Relatie bestaat een Relatie aangemaakt worden. -Autonummering Hoogste + 1 Voorwaarde voor aanmaak nieuwe relatie: -Er is nog geen Relatie met dit bankrekeningnummer -Meest recente opdracht is niet ouder dan 2 jaar -Er moeten minimaal 3 cliënten zijn met een opdracht met dit bankrekeningnummer -Soort=P Betaling -U Initieert = YES -Status ongelijk 0 (dus 1, 2 of 3) Toekomst/Structurele Oplossing: vanuit onderhoud opdrachten altijd een relatie aanmaken (indien deze nog niet bestaat) waarmee de deur openstaat om de vaak gewenste autorisatie op NIEUW bankrekening te faciliteren. (mbv veld status op relatie) 21