Bloggen er flyttet. Du kan finde indlægget på den nye adresse her: Forbedringer i markedspakke 4.
Adressen for den nye e-conomic blog er blog.e-conomic.dk.
Bloggen er flyttet. Du kan finde indlægget på den nye adresse her: Forbedringer i markedspakke 4.
Adressen for den nye e-conomic blog er blog.e-conomic.dk.
2. marts 2009 kl. 23:09
YES! endelig API adgang til abonnementsmodulet – det er vi nogle stykker som har ventet meget på.
4. marts 2009 kl. 17:34
Vedrørende API, så mangler vi stadig en del:
- at kunne få faktura som PDF, selvom fakturaen ikke er bogført endnu
- at kunne lade være med at skulle angive nummer til produkter (ved oprettelse)
- ditto kunder
- ditto kassekladdeentries
For de 3 sidstnævnte mener jeg naturligvis at API’et selv skal tildele det næste nummer i rækken, hvis man ikke selv angiver ét.
I øvrigt har jeg ikke fået en mail vedr. API ændringerne. Jeg skulle da ellers mene at jeg er blevet tilmeldt den “hemmelige” mailingliste.
5. marts 2009 kl. 08:16
Hej Uffe,
Udvikling af vores applikation er “the never ending story” forstået på den måde, at vi kontinuerligt arbejder på at udvikle ny funktionalitet.
Mht. information fra vores udviklere er jeg ikke den rette til at sige, hvorfor du ikke er blevet informeret, men fremover kan du læse om vores forbedringer via markedspakkerne her på bloggen.
5. marts 2009 kl. 14:29
Hej Uffe,
Vi har netop tilføjet en IDebtorUtil.GetNextAvailableNumber()-metode, som kan benyttes til at efterligne applikationens auto-nummererings-funktionalitet.
En tilsvarende funktion er selvfølgelig oplagt for varer – idet det dog i sagens natur kun giver mening for rent numeriske varenumre (debitornumre er faktisk også strenge i API’et – men dét er blot fremtidssikring; p.t. valideres de stadig som tal).
Vi vil gerne se på muligheden for at eksponere PDF’er af ikke-bogførte fakturaer. Bemærk dog, at disse i givet fald stadig vil have “KLADDE” skrevet hen over – ligesom i applikationen
Kassekladdeposter kræver ikke, at du angiver et nummer – hvis du oplever dette, er det en fejl?!?
Mvh.
Christian Estrup
E-conomic
6. marts 2009 kl. 15:55
Hej Christian,
Mht. klassekladde mener jeg nok nærmere indbetalinger. Hvis jeg prøver at oprette en CashBookEntry med type DebtorPayment, får jeg i hvert fald en fejlmeddelelse hvis jeg ikke angiver et nummer, og hvis jeg ydermere angiver et nummer under 50001, får jeg også at vide at det ikke kan lade sig gøre.
Jeg gik bare ud fra at det var ens for alle typer posteringer
Her ville en tilsvarende GetNextAvailableNumber()-metode også være ret fiks..
Muligheden for at få fakturakladder som PDF vil være meget værdsat. Om der står KLADDE henover eller ej er underordnet. Problemet er at i den applikation jeg udvikler, kan folk vælge forskellige fakturalayouts – her ville jeg også gerne give mulighed for at kunne vælge e-conomics layout, men dette kan jeg jo først gøre når fakturaen er bogført, som det er nu. Det er ikke helt så hensigtsmæssigt, især hvis man gerne vil sikre sig at fakturaen ser ud som den skal. Her er man nødt til at gå ind i e-conomic og manuelt tjekke fakturaen.. og det er jo ikke meningen med en integreret løsning
7. marts 2009 kl. 08:36
Hej Uffe,
Fair nok med fakturakladde-PDF’er – det får vi noteret
For kassekladde-poster mener du, så vidt jeg kan forstå, bilagsnummeret – egenskaben VoucherNumber. Hvis du opretter vha. Create() eller fx CreateDebtorPayment(), sættes VoucherNumber faktisk automatisk til det næste ledige. Principielt vil jeg dog til enhver tid anbefale, at der benyttes CreateFromData(), da man herved får sat alle egenskaber i ét round-trip.
Så vidt, jeg kan se af vores kode, accepterer VoucherNumber-set’eren faktisk alle positive heltal – hvilket egentlig er en bug, da den selvfølgelig skal validere mod min/max-indstillingerne i kassekladdens opsætning. Dét forstår jeg dog, at du oplever, den gør alligevel?!?
Er du ikke rar at sende et kode-eksempel, som fejler ved nr. <50001, til vores api-support – så får vi fluks set på det.
Mvh.
Christian Estrup
e-conomic