Account Information in XML How To Import?

[ralph.nusser]

The Swiss Post Bank delivers Account information in XML format. But FileMaker stops with a parsing error. What has to be changed in the XSLT file?

Thank you in advance

[ralph.nusser]

The Swiss Post Bank delivers Account information in XML format. But FileMaker stops with a parsing error. What has to be changed in the XSLT file?

Thank you in advance

[ralph.nusser]

The Swiss Post Bank delivers Account information in XML format. But FileMaker stops with a parsing error. What has to be changed in the XSLT file?

Thank you in advance

2005_02asp308516521_5059770292.tar

[Martin Brändle]

You can not use the XSL file that was sent by Postfinance. This is just used to display the data in your browser or your postfinance software. You can also not import the XML file directly into FM7 because it is in a different grammar than the one that FM7 needs. Instead you have to write your own XSLT file that transforms the XML in the postfinance grammar to the FMPXMLRESULT grammar. When you then import the postfinance XML file, you can then specify this XSLT file in the import dialog.

Beverly Voth has a worked-out example how to write an XSLT that produces FMPXMLRESULT grammar in her book FileMaker Pro 6 Developer's Guide to XML/XSL, ISBN 1-55622-043-X.

Mit freundlichen Gr

[Martin Brändle]

You can not use the XSL file that was sent by Postfinance. This is just used to display the data in your browser or your postfinance software. You can also not import the XML file directly into FM7 because it is in a different grammar than the one that FM7 needs. Instead you have to write your own XSLT file that transforms the XML in the postfinance grammar to the FMPXMLRESULT grammar. When you then import the postfinance XML file, you can then specify this XSLT file in the import dialog.

Beverly Voth has a worked-out example how to write an XSLT that produces FMPXMLRESULT grammar in her book FileMaker Pro 6 Developer's Guide to XML/XSL, ISBN 1-55622-043-X.

Mit freundlichen Gr

[Martin Brändle]

You can not use the XSL file that was sent by Postfinance. This is just used to display the data in your browser or your postfinance software. You can also not import the XML file directly into FM7 because it is in a different grammar than the one that FM7 needs. Instead you have to write your own XSLT file that transforms the XML in the postfinance grammar to the FMPXMLRESULT grammar. When you then import the postfinance XML file, you can then specify this XSLT file in the import dialog.

Beverly Voth has a worked-out example how to write an XSLT that produces FMPXMLRESULT grammar in her book FileMaker Pro 6 Developer's Guide to XML/XSL, ISBN 1-55622-043-X.

Mit freundlichen Gr

[Fenton]

Martin's right (of course). I'm afraid you've got some learning to do. Their xml is, in some ways, fairly straightforward. But in others it is not so simple. There's a fair amount of nesting going on; you're going to have to decifer it in order to create a structure in FileMaker that can receive it. For example, there is much like this:

<KONAUS>

some elements

[Fenton]

Martin's right (of course). I'm afraid you've got some learning to do. Their xml is, in some ways, fairly straightforward. But in others it is not so simple. There's a fair amount of nesting going on; you're going to have to decifer it in order to create a structure in FileMaker that can receive it. For example, there is much like this:

<KONAUS>

some elements

[Fenton]

Martin's right (of course). I'm afraid you've got some learning to do. Their xml is, in some ways, fairly straightforward. But in others it is not so simple. There's a fair amount of nesting going on; you're going to have to decifer it in order to create a structure in FileMaker that can receive it. For example, there is much like this:

<KONAUS>

some elements

[Fenton]

Working on my file a bit, I was able to import from a single "nested" XML file into a relational FileMaker file. It was basically a separate FileMaker Import step per table (going to the correct layout first), using a separate XSL stylesheet per table. This is not as hard as it sounds, because each of the stylesheets is fairly simple; they don't have much processing to do.

What you need in each import is an ID which can tie that particular import's data to the relational level above it. Sometimes you don't have a single ID which will do this for all tables (especially the bottom level(s) of the nested XML. But you can usually combine a couple of IDs to get a unique combo; by imported both.

Because it is a single XML file, all possible IDs are in there. Because XML is structured, the XSL can reach "up" the hierarchy to get the ID(s) you need, by using "../" in the node path.

In your (their) XML file it's impossible to say which are the IDs. There's just too many numbers, with no real description of what they are. Maybe you know.

The empty elements, which nest the data deeper, are only addressed by the XSL in order to specify the data within their nodes. You're only importing the data; but you need to know what those empty elements mean. Perhaps they mean different tables. It's hard to say for sure; one assumes they mean something.

The fields are also pretty cryptic. They are using a lot of codes for field names (in direct violation of the intent of XML to be humanly readable and verbose). This is probably because their original software is like that.

It seems to me there are a lot of fields. Some of it is understandable:

<SG3>

<NAD>

<D_3035 Value="HN"></D_3035>

<C058>

<D_3124 Desc="PostFinance Operations Center">Operations Center</D_3124>

<D_3124>9020 St.Gallen</D_3124>

<D_3124 Desc="Ihre Kontaktperson">Marianne Bodden</D_3124>

</C058>

</NAD>

<COM>

<C076>

<D_3148 Desc="Telefon">071 499 54 65</D_3148>

<D_3155 Value="TE"></D_3155>

</C076>

</COM>

<COM>

<C076>

<D_3148 Desc="Telefax">071 499 57 72</D_3148>

<D_3155 Value="FX"></D_3155>

</C076>

</COM>

</SG3>

<SG3> is some kind of contact record

<NAD> is an address

<CO58> is god knows what

<D_3124> is the address itself, what it is, street address, contact person

<COM> is "communications"

<CO76> guess again

<D_3148> is a contact number, with desc of what it is (finally :-) as an attribute

<D_3155> is a code, in an attribute

Altogether my opinion is that this is pretty crappy structure. Perhaps this was only made like this to produce a "chart" for the web? Another problem is that the XML directly calls the html formatting stylesheet. You can't have that happening to import to FileMaker. I don't know if you can stop it with another xsl stylesheet; theoretical question; anyone know?

[Fenton]

Working on my file a bit, I was able to import from a single "nested" XML file into a relational FileMaker file. It was basically a separate FileMaker Import step per table (going to the correct layout first), using a separate XSL stylesheet per table. This is not as hard as it sounds, because each of the stylesheets is fairly simple; they don't have much processing to do.

What you need in each import is an ID which can tie that particular import's data to the relational level above it. Sometimes you don't have a single ID which will do this for all tables (especially the bottom level(s) of the nested XML. But you can usually combine a couple of IDs to get a unique combo; by imported both.

Because it is a single XML file, all possible IDs are in there. Because XML is structured, the XSL can reach "up" the hierarchy to get the ID(s) you need, by using "../" in the node path.

In your (their) XML file it's impossible to say which are the IDs. There's just too many numbers, with no real description of what they are. Maybe you know.

The empty elements, which nest the data deeper, are only addressed by the XSL in order to specify the data within their nodes. You're only importing the data; but you need to know what those empty elements mean. Perhaps they mean different tables. It's hard to say for sure; one assumes they mean something.

The fields are also pretty cryptic. They are using a lot of codes for field names (in direct violation of the intent of XML to be humanly readable and verbose). This is probably because their original software is like that.

It seems to me there are a lot of fields. Some of it is understandable:

<SG3>

<NAD>

<D_3035 Value="HN"></D_3035>

<C058>

<D_3124 Desc="PostFinance Operations Center">Operations Center</D_3124>

<D_3124>9020 St.Gallen</D_3124>

<D_3124 Desc="Ihre Kontaktperson">Marianne Bodden</D_3124>

</C058>

</NAD>

<COM>

<C076>

<D_3148 Desc="Telefon">071 499 54 65</D_3148>

<D_3155 Value="TE"></D_3155>

</C076>

</COM>

<COM>

<C076>

<D_3148 Desc="Telefax">071 499 57 72</D_3148>

<D_3155 Value="FX"></D_3155>

</C076>

</COM>

</SG3>

<SG3> is some kind of contact record

<NAD> is an address

<CO58> is god knows what

<D_3124> is the address itself, what it is, street address, contact person

<COM> is "communications"

<CO76> guess again

<D_3148> is a contact number, with desc of what it is (finally :-) as an attribute

<D_3155> is a code, in an attribute

Altogether my opinion is that this is pretty crappy structure. Perhaps this was only made like this to produce a "chart" for the web? Another problem is that the XML directly calls the html formatting stylesheet. You can't have that happening to import to FileMaker. I don't know if you can stop it with another xsl stylesheet; theoretical question; anyone know?

[Fenton]

Working on my file a bit, I was able to import from a single "nested" XML file into a relational FileMaker file. It was basically a separate FileMaker Import step per table (going to the correct layout first), using a separate XSL stylesheet per table. This is not as hard as it sounds, because each of the stylesheets is fairly simple; they don't have much processing to do.

What you need in each import is an ID which can tie that particular import's data to the relational level above it. Sometimes you don't have a single ID which will do this for all tables (especially the bottom level(s) of the nested XML. But you can usually combine a couple of IDs to get a unique combo; by imported both.

Because it is a single XML file, all possible IDs are in there. Because XML is structured, the XSL can reach "up" the hierarchy to get the ID(s) you need, by using "../" in the node path.

In your (their) XML file it's impossible to say which are the IDs. There's just too many numbers, with no real description of what they are. Maybe you know.

The empty elements, which nest the data deeper, are only addressed by the XSL in order to specify the data within their nodes. You're only importing the data; but you need to know what those empty elements mean. Perhaps they mean different tables. It's hard to say for sure; one assumes they mean something.

The fields are also pretty cryptic. They are using a lot of codes for field names (in direct violation of the intent of XML to be humanly readable and verbose). This is probably because their original software is like that.

It seems to me there are a lot of fields. Some of it is understandable:

<SG3>

<NAD>

<D_3035 Value="HN"></D_3035>

<C058>

<D_3124 Desc="PostFinance Operations Center">Operations Center</D_3124>

<D_3124>9020 St.Gallen</D_3124>

<D_3124 Desc="Ihre Kontaktperson">Marianne Bodden</D_3124>

</C058>

</NAD>

<COM>

<C076>

<D_3148 Desc="Telefon">071 499 54 65</D_3148>

<D_3155 Value="TE"></D_3155>

</C076>

</COM>

<COM>

<C076>

<D_3148 Desc="Telefax">071 499 57 72</D_3148>

<D_3155 Value="FX"></D_3155>

</C076>

</COM>

</SG3>

<SG3> is some kind of contact record

<NAD> is an address

<CO58> is god knows what

<D_3124> is the address itself, what it is, street address, contact person

<COM> is "communications"

<CO76> guess again

<D_3148> is a contact number, with desc of what it is (finally :-) as an attribute

<D_3155> is a code, in an attribute

Altogether my opinion is that this is pretty crappy structure. Perhaps this was only made like this to produce a "chart" for the web? Another problem is that the XML directly calls the html formatting stylesheet. You can't have that happening to import to FileMaker. I don't know if you can stop it with another xsl stylesheet; theoretical question; anyone know?

[Martin Brändle]

To Fenton: <KONAUS> is short for "Kontoauszug", english "account statement". Some info can also be gathered from the acc_200.dtd, but as you said, the tag names are cryptic. There is a special e-banking software "Yellownet Java" made by Swiss Postfinance, probably the XML/XSL is made for display in this software.

To Ralph Nusser: there are some manuals available at https://www.postfinance.ch/FinancePortal/handle/evtCategory.do?category=servicebizmanual , maybe you can extract some info there. Otherwise you need to get in contact with a technical representative at Swiss Postfinance directly to get the tags explained.

Martin Br

[Martin Brändle]

To Fenton: <KONAUS> is short for "Kontoauszug", english "account statement". Some info can also be gathered from the acc_200.dtd, but as you said, the tag names are cryptic. There is a special e-banking software "Yellownet Java" made by Swiss Postfinance, probably the XML/XSL is made for display in this software.

To Ralph Nusser: there are some manuals available at https://www.postfinance.ch/FinancePortal/handle/evtCategory.do?category=servicebizmanual , maybe you can extract some info there. Otherwise you need to get in contact with a technical representative at Swiss Postfinance directly to get the tags explained.

Martin Br

[Martin Brändle]

To Fenton: <KONAUS> is short for "Kontoauszug", english "account statement". Some info can also be gathered from the acc_200.dtd, but as you said, the tag names are cryptic. There is a special e-banking software "Yellownet Java" made by Swiss Postfinance, probably the XML/XSL is made for display in this software.

To Ralph Nusser: there are some manuals available at https://www.postfinance.ch/FinancePortal/handle/evtCategory.do?category=servicebizmanual , maybe you can extract some info there. Otherwise you need to get in contact with a technical representative at Swiss Postfinance directly to get the tags explained.

Martin Br

[ralph.nusser]

Thank you for the information so far. I'm in contact with PostFinance Switzerland. The manual for the document manager (to view the files) is concerning XML useless. The supporter will see wether there exists another manual.

All I want is to filter out the debit and credit information ( [color:"blue"] date , [color:"green"] debit or credit amount , [color:"red"]account balance ). View example files

[ralph.nusser]

Thank you for the information so far. I'm in contact with PostFinance Switzerland. The manual for the document manager (to view the files) is concerning XML useless. The supporter will see wether there exists another manual.

All I want is to filter out the debit and credit information ( [color:"blue"] date , [color:"green"] debit or credit amount , [color:"red"]account balance ). View example files

[ralph.nusser]

Thank you for the information so far. I'm in contact with PostFinance Switzerland. The manual for the document manager (to view the files) is concerning XML useless. The supporter will see wether there exists another manual.

All I want is to filter out the debit and credit information ( [color:"blue"] date , [color:"green"] debit or credit amount , [color:"red"]account balance ). View example files

AccountPictures.zip

[ralph.nusser]

On request I got the manual with the description of the XML-Output.

[ralph.nusser]

On request I got the manual with the description of the XML-Output.

Handbuch_eKonto_eschrei[1].zip

[ralph.nusser]

The XML data can be importet with MS Excel without any problems (see attached file). I marked the account information data yellow that I want to import in FileMaker 7.

KontoauszugPostfinance.zip