Efterlysning - API - gode historier og hårde facts søges
Siden vi vi gjorde vores elektroniske stikkontakt til omverdenen (API‘et) gratis, har flere hundrede kunder benyttet sig af muligheden for at integrere mod diverse systemer.
Vi kender en hel del af disse løsninger rigtig godt (og vil beskrive dem løbende), men der er også en del løsninger vi kender meget lidt til.
Oftest er integrationen jo udviklet af en 3. parts leverandør direkte i samarbejde med jer - netop den dynamik og kreativitet vi havde i tankerne da vi frigav vores API.
Men anvender I vores API til integration mod et standardsystem andre kan gøre brug af - eller har I bare en rigtig god historie om netop jeres erfaringer, da hører vi meget gerne herom.
RSS til indlæg
februar 11, 2008 kl. 3:27 pm
Jeg ville ønske at vi kunne komme med en succes-historie, men dokumentationen af API’et er desværre så mangelfuld at det er stort set umuligt at udvikle PHP applikationer til at snakke sammen med E-conomic.
En helt simpel proces som at lave og bogføre en faktura kræver jo nærmest ugers detektivarbejde.
februar 12, 2008 kl. 9:49 am
Nikolaj, jeg er ked af at høre, at du har oplevet mangelfuld dokumentation af vores API. Samtidig er jeg glad for din feedback, da vi som jeg skrev, gerne vil blive klogere på hvad vores API anvendes til og hvilke problemer I oplever. Jeg har forstået på vores udviklingsafdeling, at API’et er bedst dokumenteret til .NET applikationer, men jeg vil drøfte med dem, hvorvidt det er muligt at lave en bedre dokumentation til PHP applikationer.
Er der andre der har oplevet lignende problemer med API’et?
februar 14, 2008 kl. 8:09 am
Ja, jeg kunne også godt bruge lidt mere dokumentation. Men hvis man har prøvet at arbejde med API’s før, så synes jeg ikke at det er så slemt igen.
Har set API’er som er dårligere dokumenteret ind jeres.
Jeg benytter forresten Ruby til jeres API.
februar 15, 2008 kl. 9:27 am
Vi ville meget gerne integrere et eksternt timeregistreringssystem til jeres projekt modul, men så vidt jeg kan se er det ikke muligt.
Hvornår åbner i op for det?
februar 15, 2008 kl. 3:05 pm
Hej Bo,
Tak for input.
Du har helt ret. Da vi frigav API prioriterede vi ikke projektmodulet og det er derfor ikke generelt tilgængelig via vores AP - et ærligt bud er at bladene skal nå at falde af træerne inden det bliver tilfældet.
Du har ikke efterladt kontaktinfo. Skriv eventuelt specifikt til vores API-team på api@e-conomic.com for at se om de alligevel ser en hurtig vej frem.
Anders
e-conomic
februar 20, 2008 kl. 11:48 am
Vi har tidligere benyttet jeres API til integration til en webshop, og det kørte uden problemer. Vi benytter dog ikke dette mere da salget mod private er lukket ned.
Noget jeg mangler i economic generelt, er bedre rapportering på abonnementsmodulet. Vi benytter dette modul meget, og mangler overblik over på hvilke måneder vores abonnenter falder i forbindelse med budgettering. Jeg har nævnt det for jer før, men det har sikkert ikke haft prioritet. Nu er mit spørgsmål så, om det er muligt at tilgå abonnementsmodulet via APIét som vi selv kan lave vores rapportering ?
februar 22, 2008 kl. 9:44 am
@Martin: Mange tak for din feedback. Jeg er glad for at høre I har benyttet vores API. Som udgangspunkt understøtter vores API kun grundmodulet og du kan derfor ikke tilgå abonnementsmodulet direkte. Vi arbejder løbende på en lang række forbedringer i systemet, men jeg kan ikke love dig hvornår vi får integration til netop abonnementsmodulet.
Det kunne være rart at høre, om andre også oplever et behov for bedre rapportering på abonnementsmodulet og at kunne tilgå det gennem vores API?
Christian
e-conomic
februar 24, 2008 kl. 11:42 am
@Christian: You eat your own dog food ? Det håber jeg, og i den forbindelse må i da også selv have brug for rapportering på abonnementsmoulet? Ellers har jeg lidt svært ved at se hvorledes i selv får overblikket. Hvis der er noget jeg har overset i modulet af muligheder, må du endelig sige til.
/Martin
februar 24, 2008 kl. 11:46 am
Jeg kan selvfølgelig lave abonnementskørsler månedsvis, 12 måneder frem som ordre og budgetterer efter det, hvorefter jeg så sleter mine ordre, men det havde nu være lækkert med en simpel rapport som stillede dette op månedsvis pr. abonnement.
Fra en ellers generelt tilfreds bruger
/Martin
april 30, 2008 kl. 10:41 am
Hej
Nok er ovenstående post et par måneder gammel, men alligevel vil jeg lige komme med en kommentar.
Selvfølgelig savner vi også API til abonnementsmodulet. Vi har spurgt løbende til dette lige fra abonnementsmodulets fødsel, næsten (det er vel efterhånden flere år). Og hver gang bliver svaret: “Det kommer på en liste over ønskede features”.
Nu har vi nedjusteret vores forventninger kraftigt, og håber nu på en meget simpel eksport til csv-fil (som i de glade 80′ere).
Vores nedjusteret behov er ret enkelt faktisk:
Til hvert abonnement (abonnementsnummer) vil vi gerne kunne hente en csv-fil (el. lignende eksportfil) med debitorerne og deres tilhørende felter.
Måske dette kunne blive en feature i “Eksportér data” under “Indstillinger” indtil API er klart om et par år?
Resten af E-conomic-systemet er vi dog tilfredse med, men da vi bruger abonnementmodulet meget, så er vi lige nu endt med at sidde og trække upræcise oplysninger ud fra andre csv-filer, som _er_ tilgængelige og derved gætte på hvordan tingene hænger sammen i abonnementerne.
Vi har også tilbudt at spytte penge i kassen til udvikling af de features vi har brug for, men har heller ikke fået svar på dette.
Mvh.
Lars
maj 14, 2008 kl. 3:13 pm
Det ville være faktastisk med en succes historie, men desværre….
Forudsætninger:
Sprog: PHP5 + SOAP
Integration med: Egen backend
Stor erfaring med PHP
Ingen erfaring med SOAP.
Vi valgte E-conomic pga den lette tilgængelighed og muligheden for API samt abonnementsmodulet.
Desværre viste det sig, at abonnementsmodulet ikke kan styres via API. Det var første slag. (Man skal lede meget længe for at se hvad API’et understøtter, for det står ikke nogen steder. Kun at ‘alt’ kan lade sig gøre med API.)
Så valgte vi selv at skrive et abonnements modul til vores backend, hvilket ikke er et stort problem, men burde have været overflødigt.
Næste udfordring er så, at alle kunder skal oprettes i E-conomic. Det er lykkedes med API’et. Var lidt besværligt at finde ud af, men al begyndelse er som bekendt svær.
Nu er vi så nået til det punkt hvor der skal oprettes faktura i E-conomic via API. Det har vist sig at være noget nær umuligt for os. Det hænger nok i stor stil sammen med erfaringen med webservices. Men stadig kunne en smule mere dokumentation til PHP være ønskeligt.
Med alle de sager i kender til, må i have mulighed for at offentliggøre en række eksempler på oprettelse af debitor, oprettelse af faktura, oprettelse af kreditnota og evt et par andre.
Nuvel det er et forholdsvist billigt system at benytte, men derfor er det alligevel forventeligt at kunne få svar på spørgsmål hurtigere end 24-36 timer. Det er meeeeget længe at vente på et ‘Nej deet kan desværre ikke lade sig gøre’.
Hvis ikke ‘en fra API-teamet kan svare, må der være andre ude i lille Danmark som kan komme med de vise sten. Hvordan kommer vi videre med integrationen så vi kan oprette faktura og få dem sendt afsted?
Jeg kan kontaktes på kb@liiwin.dk.
Med venlig hilsen
Keld Bendtsen
juni 9, 2008 kl. 11:11 am
Det er ganske interessant læsning her på siden fordi jeg selv har støt på mange af de forhindringer andre også nævner. Først og fremmest vil jeg sige er det er rigtigt fedt at API’et (nu) er gratis, og efter lidt tilvending ganske brugbart. Vi bruger mest API’et til en række små programmer ved FIK betalinger, samt PBS til udenlandske betalere. Andre eksempler er at Skat nu skal have oplyst debitorers CPR sammen med de indbetalte beløb.
Jeg har dog et par forslag til forbedringer. Dels kunne jeg rigtigt godt tænke mig at I afsatte en udvikler til at lave en række ”Best practices” eksempler. Altså programmer der også skalere godt hvis der er mange poster der skal hentes etc. Dette vil støtte op om den dokumentation er engang er. De programstumper der medfølger API’et dækker kun en lille del af API’et. Desuden kunne også godt tænke mig at man offentliggjorte en roadmap for den påtænkte udvikling, ie hvilke moduler man
Pt. kunne jeg ønske mig adgang til abonnent modulet, samt viden om hvordan jeg udtrækker information om de beløb debitor har indbetalt og ikke blot hvilke faktura de har modtaget.
Venlig hilsen
Erik Arndal
juni 9, 2008 kl. 11:22 am
Hej Erik,
Tak for input.
Indrømmet så er vi blevet overrasket over hvor mange der rent faktisk er gået i gang med API-integrationerne.
Faktisk - og for os både glædeligt - men også lidt pinligt støder vi ofte på integrationer vi ikke anede eksisterende.
Glædeligt fordi det viser at vores API virker.
Ærgeligt fordi vi meget gerne vil have et forum hvor disse interfaces kan komme så mange til gode som muligt. (ikke opfinde dybe tallerkener igen….)
Også ærgeligt hvis I bruger forgæves timer på områder vi (endnu) ikke understøtter. F.eks Keld Bentsens problemer med PHP i tidligere indlæg.
Jeg ved at der foregår nogen dialog på http://www.amino.dk som vi følger med i lige, ligesom API har været et velbesøgt område her på denne “forsøgsblog”.
Vores mål er jo selvfølgelig at få et så kompetent miljø omkring vores integrationer som muligt. B
Bag linierne arbejder vi på at lave et egentligt API-forum - forhåbentlig ind over sommeren. Det bliver sikkert noget WIKI, Blog lignende hvor vi håber I vil blive animeret til at deltage.
Gode forslag til et API-forum modtages meget gerne på akh@e-conomic.com
hilsen
Anders K.
juni 9, 2008 kl. 9:33 pm
Erik,
Selvom der ikke er eksplicit adgang til at læse selve debitor-indbetalings-posterne, er der måske alligevel noget, du kan bruge (med udgangspunkt i .NET-API’et - samme funktionalitet er dog naturligvis også tilgængelig i SOAP):
IInvoice-klassen har to felter - Remainder og RemainderBaseCurrency - som eksponerer det endnu ikke udlignede beløb på fakturaen. Remainder er i fakturaens valuta, mens RemainderBaseCurrency er i regnskabets grundvaluta (sandsynligvis DKK).
For at disse felters indhold skal være retvisende, kræver det naturligvis, at evt. indbetalinger er udlignet korrekt mod den pågældende faktura - dette gøres lettest og mest automatisk ved at påføre fakturanummeret ifm. oprettelsen af indbetalings-posterne.
Som sagt er det selvfølgelig ikke det samme som at kunne se ’selve’ indbetalingerne - men de fleste lignende behov, vi er stødt på, har faktisk reelt bundet i behovet for at kunne trække udestående fakturaer, hvilket dette netop giver en let mulighed for (-> hvis Remainder[BaseCurrency] 0, er fakturaen helt eller delvist udestående).
Mvh.
Christian Estrup
E-conomic
juni 10, 2008 kl. 8:21 am
- og så var jeg vist lige ignorant over for, at “ikke-lig-med” blev strippet som potentielt HTML-tag
Derfor, for en ordens skyld: Hvis Remainder[BaseCurrency] IKKE ER LIG MED 0, er fakturaen udestående.
Mvh.
Christian Estrup
E-conomic