SEPA en IBAN

[hans erik]

Misschien een leuk onderwerp om hier op Clarify verder uit te diepen: how about SEPA?

 

Het zal de meeste ontwikkelaars niet zijn ontgaan dat Europa over 12 maanden op SEPA denkt over te stappen, waarmee al het geklieder (in NL!) met CLIEOP wordt vervangen door door gemodder met XML in de vorm van de ISO 20022 message standard.

Natuurlijk heb ik daar zelf een belang bij. Zijn er al ontwikkelaars die in FMP een implementatie van SEPA hebben draaien? Of is het allemaal OF bedrijfsgeheim OF zo simpel dat het de moeite niet loont om het hier verder uit te werken?

 

HE

[andries]

ik denk niet dat het een kwestie is van "staatsgeheim"

 

wij hebben velden voorzien en in een loopje bouwen we een xml file op. Deze exporteren we dan.

 

Loop
   Set Variable [ $transactie ; "CALCULATIE VOOR TRANSACTIE" ]

   #Gebruiken we niet meer omdat het gewoon te traag werd na een tijdje, nu schrijven we per iteratie direct weg naar de file.    
//  Set Variable [ $transacties ; List ( $transacties ; $transactie ) ]

   Set Variable [ $transacties ; WriteToFile ( $path ; $transactie ) ]

   Go To Record Next [ Exit After Last ]

End Loop

 

WriteToFile is een scriptmaster functie die toelaat om data weg te schrijven naar een tekst bestand. Dit hebben we zo gedaan omdat we zagen dat voor grote foundsets het script exponentieel trager werd naar het einde toe. Ik denk dat hier een soort van memory leak zit bij FileMaker en dat na een tijdje $transacties zo groot werd, dat FileMaker moeite had om een volgende transactie nog toe te voegen. (ik heb hier die script stap in "comment" gezet).

 

we hebben ons op dit document gebaseerd: http://www.febelfin.be/sites/default/files/files/Standard-CreditTransfer-v2-NL_0.pdf

[Felix]

.

Edited October 6, 2015 by Guest

[andries]

omwille van... dat het sneller ontwikkeld via een loop

 

xslt is inderdaad een properdere manier om te werken.

[hans erik]

Ja, XSLT is netter.

Alhoewel je natuurlijk in XSLT ook op verschillende manieren kunt werken dus de ene XSLT is de andere niet.

 

In de 'FileMaker oplossing' van Andries maak je dus alle XML tags in een scriptstap aan. Hoef je geen XSLT te leren!

 

[edit]

Heb er nog eens over nagedacht. Waarom noemen we de methode via XSLT 'properder/netter' dan het direct wegschrijven uit FileMaker naar tekst?

Uiteindelijk is het toch alleen het eindresultaat wat telt? En qua complexiteit zou ik zeggen dat de FileMaker methode simpeler is en dus de voorkeur heeft.

XSLT is net zo foutgevoelig en minstens zo bewerkelijk. En het scheelt je een hele processtap als je het allemaal in FileMaker oplost.

[Vitruvius]

Maar hou er dan wel rekening mee dat je die XML niet dusdanig kan exporteren als bestand omdat filemaker dat in utf 16 doet terwijl het utf 8 moet zijn en dat kan je nergens aanpassen, je kan wel een copy paste doen naar een txt bestandje. Die plugin verhelpt dat probleem waarschijnlijk wel.

[Felix]

.

Edited October 6, 2015 by Guest

[Vitruvius]

Wanneer je niet via een xslt werkt, maar alles in filemaker aanmaakt. Het XML bestand dat je dan in een tekstveld hebt staan, kan je niet als UTF8 exporteren.

[Felix]

.

Edited October 6, 2015 by Guest

[Vitruvius]

Opmaak. In UTF8 heb je geen keuze in opmaak, in utf 16 wel.

 

Het zou natuurlijk oneindig handiger zijn moest je bij export de encoding kunnen kiezen.

Net zoals bij de import overigens.

[Felix]

.

Edited October 6, 2015 by Guest

[Vitruvius]

Maar toch, hoe komt het dan dat een RTF UTF16 is en een TXT UTF8?

in een RTF kan je meer qua opmaak dan in een TXT. Of is dat niet de reden voor UTF16?

In dat geval weet ik niet wat het verschil is, ik weet alleen dat het problemen geeft wanneer het niet UTF8 is, als ziet het er visueel net het zelfde uit.

[Felix]

.

Edited October 6, 2015 by Guest

[Vitruvius]

[hans erik]

Aha, klopt. Daar heb je gelijk in. Dus dat is een argument TEGEN het opbouwen van een xml structuur in een veld en dat dan met Export Field Contents in een bestandje zetten. Gewoon met xslt werken en de normale xml export opties van FM gebruiken is dus het devies!

 

PS Het is dus wel een omissie van de jongens en meisjes bij FIleMaker om bij het exporteren vanuit een veld de encoding niet te kunnen kiezen. Het is mij eerlijk gezegd ook onduidelijk waarom dit is vastgezet op utf16 terwijl de xml export is vastgezet op utf8.

 

Maar je moet dan ook gebruik maken van een plugin om de textfile aan te maken.

Met de ingebouwde export (naar tab-tekst of csv) zal het niet lukken denk ik zo.

 

HE

[Felix]

.

Edited October 6, 2015 by Guest

[Vitruvius]

Maar een XML is in UTF8, daarom dat het hernoemen van het geexporteerde UTF16 bestand naar .xml niet werkt.

Tenzij je eerst die UTF16 omzet naar UTF8

Of je gebruikt de plugin.

[Felix]

.

Edited October 6, 2015 by Guest

[Dre]

Yep

o.a. LibIconv voor windows, http://www.gnu.org/software/libiconv

 

 

Het blijft wel allemaal omslagtig, A.U.B. Filemaker maak een Field export met de benodigde Character Set opties

en meteen keuze uit regeleinde(s).

[hans erik]

Heb je helemaal gelijk in. En als ze toch bezig gaan: doe dat dan ook even voor de importmodule en zorg ervoor dat je dan ook de regeleinden en veld-delimiters kunt instellen.

 

O ja, vergat ik bijna: waarom niet gewoon Paste As Records? In een portal? Daar hebben die MS Access boys ons toch mooi tuk mee.

 

Nog even terugkomend op UTF8 vs UTF16: het verschil is toch gewoon single-byte vs double-byte? Dus of je alleen de letters a t/m z kwijt kunt of de hele Yin en Yang van het Verre oosten erbij?

[Felix]

.

Edited October 6, 2015 by Guest

[Jeroen Aarts]

Inderdaad. Verschil is dat UTF-16 altijd 2 bytes zijn, maar UTF-8 dynamisch 1 of 2 bytes.

 

Ik merk terloops ook op, dat als je de inhoud van een tekstveld wil exporteren, en geen UTF-16 als karakter encoding wil, je gewoon 1 record met de de juiste waarde (of globaal veld) kan isoleren, en dan best voor 'Export Records kiest'. Dan kan je nl. wel de charset kiezen. Zo eenvoudig kan het soms zijn in FileMaker

[Felix]

.

Edited October 6, 2015 by Guest

[Vitruvius]

Als oplossing voor het UTF-8 probleem

 

Onderaan deze webpagina staat een zeer korte XSLT die je in staat stelt om één tekstveld als UTF-8 te exporteren.

Je kan dus in Filemaker je volledige xml (of ander UTF-8 bestand) aanmaken en die via deze eenvoudige .xslt toch exporteren als UTF-8 zonder dat fm daar zijn eigen zooi e.d. bij kletst.

Gebruik ik nu zelf ook.

 

http://filemakerhacks.com/2012/09/23/export-field-contents-as-utf-8/

 

<?xml version="1.0" encoding="UTF-8" ?>
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fm="http://www.filemaker.com/fmpxmlresult"
exclude-result-prefixes="fm">

[bigbadwolf]

Gaandeweg het topic heb ik toch het idee dat het niet meer helemaal gaat over het SEPA en IBAN, maar het heeft bij mij wel een vraag opgeroepen.

Ben redelijk thuis is de simpele xslt-export/import, maar waar ik nu tegenaan loop is het exporteren van gerelateerde records.

Het exporteren zelf lukt wel, alleen niet op een manier die logisch lijkt.

 

Ik wil namelijk een constructie als dit:

 

10

3,10

25

1,90

50

1,18

75

0,98

100

0,97

250

0,60

500

0,51

1000

0,41

 

Maar wat ik krijg is

 

10

25

50

75

100

250

500

1000

3,10

1,90

1,18

0,98

0,97

0,60

0,51

0,41

 

De rest van de export ziet er goed uit, maar net dit ene stukje niet.

[Felix]

.

Edited October 6, 2015 by Guest