Filemaker & Accountview koppeling dmv xml

[ron@dds.nl]

Hoi Allemaal,

 

We zijn bezig om een koppeling tussen Filemaker en Accountview te maken.

In de factuur zijn een aantal factuur regels, we nemen deze data zoals factuurnummer, grootboekrekening, bedrag, betaalwijze, maken daar een xml van en sturen dit bestand over het netwerk naar een 'watchfolder' op de machine waar accountview draait, zodat die de xml's weer kan importeren.

We hebben de afgelopen week druk onderzoek gedaan, maar het lukt toch nog niet helemaal.

We hebben moeite om scriptmatig de xml samen te stellen. We hebben een Portal met daarin alle records en velden, maar vanaf daar vinden we het moeilijk.

We hebben een functie xmlAllFields gevonden, we hebben ook voorbeelden hoe accountview de xml opmaak wil hebben, maar het lukt ons nog niet om de zaak te verbinden.

Graag zouden we wat willen horen over een geschikte xml functie, werkwijze, etc. Alle input wordt dankbaar in ontvangst genomen

[hans erik]

XML is natuurlijk gewoon tekst, niks meer en niks minder.

 

Dus je kunt op allerlei manieren je XML bestand samenstellen. De 'netste' manier is via de XML export van FileMaker, maar die produceert niet zomaar een bruikbaar XML formaat. Om van de 'platte XML' van de FMPXMLRESULT naar een geschikte ordening voor Accountview te komen moet je XSLT bestand toepassen, d.w.z. een procedure die de hele XML omspit, tags omzet enz. Zelf XSLT schrijven is leuk als je van puzzelen houdt en een hoop vrije tijd over hebt.

 

Een andere mogelijkheid is om met behulp van een script je XML samen te stellen.

Met de tekstfuncties van FileMaker (substitute met name), een paar loops, varaibelen en vaste velden met de gewenste XML-tags kun je dan de complete XML in een tekstveld samenstellen en dat veld exporteren als tekstbestand.

Een generieke oplossing valt echter niet te geven, omdat elk XML formaat weer anders is, met tags binnen tags enz.

 

Bijvoorbeeld:

 

set variabele ( $MijnXML ; "" & facturen::fact_nummer $ "" )

[hans erik]

We hebben moeite om scriptmatig de xml samen te stellen. We hebben een Portal met daarin alle records en velden, maar vanaf daar vinden we het moeilijk.

 

Nog even een tip: ik zou in de factuurregels een XML-veld maken dat je met behulp van een formule vult. Dat bevat de XML tags met inhoud voor alleen die regel.

Hoe die regel eruit ziet hangt natuurlijk van je XML specificatie af.

 

Vervolgens verzamel je in de factuur mbv een tekstfunctie alle XML van de factuurregels met List ( factuurregels::XML); daar zet je dan weer de vaste gegevens omheen.

Je stuurt dus alles vanuit de factuur aan; je hoeft misschien niet eens een script te gebruiken.

[Felix]

.

5 oktober 2015 aangepast door Gast

[ron@dds.nl]

Bij AccountView is men zeer terughoudend met het verstrekken van informatie en in iedere zin worden de woorden Consulancy en Projecteam gebruikt.

Maar ik heb een link gevonden waar onder aan de pagina tal van voorbeelden worden gegeven over de XML syntax voor AccountView

 

http://www.accountsoftware.nl/software/producten/accountplus/comtalk

16 april 2014 aangepast door Gast

[ron@dds.nl]

Nog even een tip: ik zou in de factuurregels een XML-veld maken dat je met behulp van een formule vult. Dat bevat de XML tags met inhoud voor alleen die regel.

Hoe die regel eruit ziet hangt natuurlijk van je XML specificatie af.

 

Dit vind ik een heel goed idee.

Had daar zelf ook al aan gedacht om niet een functie en een grammer file te gebruiken die ik langs alle velden en record moet laten lopen, maar zelf de syntax per record samenstel in een calculation veld en die dan achter elkaar plak en save als een file.

 

Nu nog even de juiste Tags vinden voor AccountView

[Felix]

.

5 oktober 2015 aangepast door Gast

[ron@dds.nl]

Die link geeft je heel wat info waar je best het nodige uit kunt halen. Je wilt denk ik iets voor de debiteuren en voor de verkoopfacturen?

 

Klopt we boeken facturen in per factuurregel, dit gebeurt nu geheel handmatig en met 1000 factureren per maand en gemiddeld 5 regels begint dit uit de hand te lopen

 

Dat moet ook met xslt niet al te ingewikkeld zijn omdat het resultaat nogal platte xml's zijn. Het vinden van de juiste tags is idd even puzzelen.

De export realiseren via berekeningen of via xslt maakt vervolgens niet veel verschil. Persoonlijk zou ik voor xslt gaan. Dat is veel makkelijker te onderhouden.

 

Ik zie nog even geen voordeel waarom de xml hierna om te zetten in een xslt, als eea draait zullen we weinig veranderen. Mettertijd wil ik nog ook een terugkoppeling maken dat betalingen via de bankboeken door AccountView weer teruggaan naar FM omdat daar bijgehouden wordt of een klant zijn factuur (volledig) betaald heeft dmv betaalregels als tegen boeking op de factuurregels.

Vanzelfsprekend hoor ik verdere argumenten om toch een xslt te gebruiken . .

[Felix]

.

5 oktober 2015 aangepast door Gast

[ron@dds.nl]

En gaat dat dan van AccountView naar FM terug via xml?

Dat is wel de bedoeling ja

[Felix]

.

5 oktober 2015 aangepast door Gast

[ron@dds.nl]

Dan zul je daarvoor toch al een xslt moeten maken. Dus waarom niet ook gelijk voor het exporteren?

Dat snap ik niet, waarom zou dat moeten?

[Felix]

.

5 oktober 2015 aangepast door Gast

[hans erik]

Die link geeft je heel wat info waar je best het nodige uit kunt halen. Je wilt denk ik iets voor de debiteuren en voor de verkoopfacturen?

Dat moet ook met xslt niet al te ingewikkeld zijn omdat het resultaat nogal platte xml's zijn. Het vinden van de juiste tags is idd even puzzelen.

De export realiseren via berekeningen of via xslt maakt vervolgens niet veel verschil. Persoonlijk zou ik voor xslt gaan. Dat is veel makkelijker te onderhouden.

 

Mee eens. Is een XSLT 'symmetrisch'? Ik bedoel: kun je met een XSLT voor export ook een import processen (vooropgesteld dat import en export dezelfde layout hebben)?

Of het veel gemakkelijker is te onderhouden is een kwestie van hoe handig je bent met de verschillende omgevingen.

Persoonlijk word ik niet vrolijk van XSLT maar dat kan aan mij liggen.

[ron@dds.nl]

Mee eens. Is een XSLT 'symmetrisch'? Ik bedoel: kun je met een XSLT voor export ook een import processen (vooropgesteld dat import en export dezelfde layout hebben)?

Of het veel gemakkelijker is te onderhouden is een kwestie van hoe handig je bent met de verschillende omgevingen.

Persoonlijk word ik niet vrolijk van XSLT maar dat kan aan mij liggen.

Voor zover wij kunnen zien, gebruikt AccountView voor alle situaties (debiteuren, crediteuren, Stamgegevens, etc) verschillende tags.

Dit is waarschijnlijk hun manier om data te kunnen herkennen en in de juiste module te kunnen verwerken. Dus nee niet symmetrisch.

[Felix]

.

5 oktober 2015 aangepast door Gast

[Felix]

.

5 oktober 2015 aangepast door Gast

[ron@dds.nl]

Even een update:

 

We hebben de factuur regels portal klaar, we hebben de opmaak van de xml regels en document (met de documentatie die we gevonden hebben) zo goed als klaar.

Waar het nu even op hangt is een onwillige software leverancier. Visma software; de leverancier van AccountView weigert ons van de noodzakelijke informatie te voorzien om de xml door Accountview te kunnen importeren. Buiten de module die moet worden aangeschaft wil Visma ons verplichten om via een implementatie partner en bijbehorend projectteam eea werkend te krijgen.

Ik houd jullie op de hoogte . . .

[Felix]

.

5 oktober 2015 aangepast door Gast

[ron@dds.nl]

Wie is die implementatie partner?

Databas

 

http://www.databas.nl

[Felix]

.

5 oktober 2015 aangepast door Gast

[ron@dds.nl]

als ze hier op het forum aanwezig zijn dan lezen ze dit al als het goed is en nodig ik ze hierbij uit

Ik ken iemand bij STB en zal die ook benaderen.

Nu wachten we even op een reactie van Visma software.

Nadat we een pertinent nee hadden gekregen dat we zelf de implementatie wilden doen, heb ik mijn advocaat een brief laten schrijven waarin we vragen wat hun wettelijke rechtvaardiging is van hun in onze ogen verboden koppelverkoop.

Als het goed is krijgen we binnen een paar dagen antwoord

Ik verwacht geen goed nieuws, het is nogal een arrogante club en denk dat ze ons verder willen dwingen het voorgeschreven pad te volgen, of wellicht zelfs van hun kant de klantrelatie opzeggen . . .

[ron@dds.nl]

Even een kleine update tussendoor.

 

Na wat gesteggel hebben we van Visma de aanvullende software ontvangen inclusief documentatie en voorbeeldbestanden.

We zijn nu eea op ons gemak aan het opzetten.

Zodra er interessant nieuws, of een eerste werkende setup is, meld ik me weer.

[rpbteb]

Hi Felix,

 

Dank voor je reactie op mijn email betreffende XML en BankIncasso's.

De 'xsit' opmerkingen begrijp ik niet.

 

Maar de voor de bank noodzakelijke xml incassofile maak ik nu maar simpel in een textveld en exporteer dat veld naar een file met .xml extensie. Op die manier kan het in een bestaand FM ge-integreerd worden voor het SEPA incasseren.

[Felix]

.