Informizely customer feedback surveys




Se de seneste forbedringer




Bestillinger ikke åben i API

0
Hej e-conomic + andre brugere

Vi er igen stødt i problemer på en integration vedr. e-conomic.
Vi kan ikke externt fra oprette en bestilling pga. API delen er for låst og ikke understøtte alle funktioner som er tilgængelige i e-conomic.

Vores forslag er igen at få åbnet så meget som muligt i den API og give os frihed til at kode op imod jeres løsning.
lukket
i Spørgsmål » Andet af (1.4k points)
status opdateret af

6 Svar

 
Bedste svar
Ronni: Alt OK - det vil jeg se frem til

kasser: Ikke tekniske begrænsninger som sådan - men da APIet nu engang er tilkommet senere, er det reelt en slags sidebygning på web-applikationen. Som det dog naturligvis deler en masse forretningslogik med.

Der er med andre ord ikke tale om, at der faktisk er en form for API til alt, som vi bare kan eksponere - derimod kræver eksponering af yderligere funktionalitet i APIet en større eller mindre mængde arbejde i hvert enkelt tilfælde.

Følgelig er dette også underlagt de samme grundlæggende prioriteringsmæssige kriterier som alt muligt andet - primært baseret på, hvordan vi skaber mest mulig værdi for flest mulige nuværende og kommende kunder.

Derudover er der naturligvis også andre forhold, vi tager i betragtning. For så vidt angår ny funktionalitet i applikationen har vi allerede bevæget os et godt stykke hen imod en release early, release often-mentalitet. Dette kan dog godt give nogle udfordringer i forhold til altid at stille al ny funktionalitet til rådighed i APIet også - da de løbende ændringer, der også følger af en sådan strategi, jo nødig skulle resultere i konstante breaking changes i APIet. Derfor ser vi gerne, at en given funktionalitet når en vis modenhed, før vi eksponerer den i APIet.

Jeg har faktisk allerede på enkelte områder måttet sige nej til ønsker til ændringer i <em>applikationen</em>, fordi disse ville medføre ændringer i nogle logiske strukturer, som allerede er eksponeret i APIet. Det er <em>så</em> alvorligt, vi mener det, når vi siger, at vi ikke laver breaking changes - hvis en løsning virkede i går, skal den også virke i morgen

Modenhed skal her ikke nødvendigvis ses i forhold til den enkelte funktionalitets alder - vi bliver jo også klogere hen ad vejen, og for eksempel har vi jo på det seneste ændret fokus i netop lagermodulet til ikke bare at hælde flere og mere komplekse funktioner ind, men også i høj grad at forenkle både strukturer og arbejdsprocesser.

Endelig er der selvfølgelig også support-dimensionen: Vi har som bekendt gratis support til funktionalitet i e-conomic, ligesom vi stiller gratis <em>teknisk</em> support til rådighed for <em>udviklere</em> af integrationsløsninger. Slutbruger-support til selve integrationsløsningerne varetages naturligvis af vores integrationspartnere. Her skal vi så sikre os, at vi ved eksponering af e-conomics mere komplekse funktionalitet i APIet også har vores partnere med i fornødent omfang - ellers risikerer kunderne let at havne i et support-limbo

På den anden side er det naturligvis udfordringer, der kan løses - primært ved, at vi bliver bedre til at formidle det ansvar, man som integrationspartner påtager sig. Heldigvis har vi da også allerede i dag mange spændende og gennemarbejdede integrationsløsninger, som vores partnere står 100% på mål for

Som samlet betragtning er vi således altid åbne for at diskutere eksponering af yderligere funktionalitet i APIet - så længe, vi er forholdsvis trygge ved, at vi ikke vil ønske at ændre den pågældende funktionalitet væsentligt inden for overskuelig fremtid. Vi har da også, alene inden for det seneste år, eksponeret en stor mængde ny funktionalitet i APIet - eksempelvis tilbud, sager, tidsregistreringer, prisgrupper og rapportkoder. Dertil kommer yderligere forbedringer for integrationer generelt, i form af web hooks og brugerdefinérbare faneblade.

Vi kan naturligvis dårligt committe os til, at vi vil eksponere alt - dét vil i øvrigt være nogenlunde lige så værdiløst som at committe sig til, at vi vil lave flere funktioner i modul X.

Til gengæld vil vi altid gerne lytte til, og samarbejde om, ønsker til eksponering af specifik funktionalitet, som I og andre (og vi selv ) vurderer, vil kunne hjælpe et stort antal kunder. Hvad er så et stort antal? Dét tager vi fra gang til gang - jo mindre, opgaven er, jo mindre og mere usikker kan vi naturligvis også leve med, at målgruppen er.

I forhold til eksponering af leverandørbestillinger er det fx interessant for mig at vide, om det vil give nævneværdig værdi kun at få eksponeret bestillinger (= lille opgave), eller om man i praksis også er nødt til at få adgang til modtagelser og leverandørfakturaer, samt overførsler af varelinjer mellem disse (med al den fleksibilitet, dét nu engang indebærer = en væsentlig større opgave). Eller om vi kan lande et sted midt imellem: Eksponere bestillinger - og hvis tilstrækkelig mange tager det i brug, går vi videre...

Mvh.

<p dir="ltr"><b>Christian Estrup</b></p> <p dir="ltr">Director, e-conomic Core</p> <p dir="ltr"><strong>&nbsp;</strong></p> <p dir="ltr"><img src=" width="258" height="27" alt="image"></p>
Spørgsmål af 🔒 (20.9k points)
opdateret af
Enig her.

Det kunne være meget lækkert at få adgang til lidt flere funktioner igennem APIet. Kunderne vælger jo netop en økonomiløsning for at kunne automatisere og lette bogføringingen i dagligdagen. Det er derfor en kæmpe fordel for kunderne at integerere jeres system mod deres eksisterende IT løsninger. Det kræver så bare lige at der er åbnet op for det i APIet.

For os som udviklere er vi flere gange stødt på problemstillinger hvor vi har været nødt til at fravælge e-conomic fordi det låser sig fast mht integration i 3. parts systemer.

E-conomic burde genoverveje strategien for udvikling af APIet. Det burde betyde at E-conomic for hver ny funktion, også API-mæssigt åbner op for det. Så vi rent faktisk får det fulde udbytte af E-conomic.
Spørgsmål af (140 points)
Ja vi slutter bestemt også op om ønsket mere flere funktioner herunder:

Mulighed for oprettelse af leverandørfaktura.
Mulighed for at sende EAN faktura ud fra e-conomic initieret på basis af API (alle data kan allerede sendes der kan bare ikke sendes).
Mulighed for påvirkning af lager status (ved justering for svind, status m.v. som foretages i eksternt system).

Ovenstående 3 vil absolut åbne en hel del nye muligheder og markeder op for e-conomic.
Spørgsmål af (520 points)
Hej Ronni,

For så vidt angår afsendelse af EAN-fakturaer har vi jo tidligere været i direkte dialog.

Jeg har i den forbindelse skrevet til dig for to uger siden med henblik på uddybning af jeres ønske, samt for at høre jeres kommentarer til de udfordringer, vi kunne se ved en sådan løsning.

Eftersom du ikke har gidet svare, troede jeg faktisk ikke, det reelle behov var så stort - i modsat fald er du naturligvis velkommen til at svare...

Mvh.

<p dir="ltr"><b>Christian Estrup</b></p> <p dir="ltr">Director, e-conomic Core</p> <p dir="ltr"><strong>&nbsp;</strong></p> <p dir="ltr"><img src=" width="258" height="27" alt="image"></p>
Spørgsmål af 🔒 (20.9k points)
opdateret af
Hej Christian,

Jeg gider skam godt svare - men har ikke haft tiden til at gå i dybden endnu

Så forvent at jeg skriver inden for den næste uges tid.
Spørgsmål af (520 points)
Hej Christian,

Eftersom man kan se der er behov for løsningen - kunne man måske fortsætte her i tråden så alle kunne aktivt deltage og følge med i projektet om mere åbent API.

Er der nogle tekniske begrænsninger siden man ikke åbner for alle funktioner gennem API med det samme ?
Spørgsmål af (1.4k points)