Journals are probably one of the most critical endpoints for all consumers using our application.
For those unfamiliar with the accounting jargon – journals (known in danish as kassekladder) contain draft transactions (entries), that represents transaction in your accounting.
/journals-experimental
Currently journals are exposed as experimental, which means that endpoint signature might be changed as we go along. We do not expect heavy changes (if any), due to the fact that the endpoint has been already tested by the selected partners, who confirmed it’s stability.
As of now, we recommend using this endpoint in sandbox environment only, away from the production agreements – until it gets to the stable state. Remaining text will be referencing to the official endpoint name – /journals, however during the experimental phase – /journals-experimental is enforced.
Journals
Calling GET method on /journals provides you with an overview for the journals that are created on the accounting agreement, among with some of the important settings such as minimum and maximum voucher number allowed for the given journal. Besides that we provide convenience links to vouchers collection (entries as assigned by the voucher number), entries (entries in the journal, sorted by entry type they belong to) – this gives different perspectives on the data, and you can decide on which view is more suitable for your needs.
Entry types
Currently in e-conomic web application we support 5 types of entries:
- Journal entry
- Supplier invoice
- Supplier payment
- Manual customer invoice
- Customer payment
And now they can all be created using REST API by calling POST on /journals/:journalNumber/vouchers. Furthermore – we also support bulk creation of different types in one call, to make it as robust as possible.
Attachments on vouchers
We now also support attachments on vouchers – functionality that was heavily used by many of our consumers in SOAP (using CashBook_RegisterPdfVoucher method) is now present in REST API with even more functionality added to it.
Besides supporting .pdf we now also support .jpg, .jpeg, .gif and .png formats, which allows for more flexibility. We have also introduced PATCH method, that enables for adding more pages to the already attached document. This eliminates the need to process the document on your own end, in order to be able to add more pages to it.
Documentation
The /journals endpoint is documented here.
Further expansion
We will be working on additional functionality for /journal endpoint, as we go, if you identify any missing bits please let us know!
Feedback
As this endpoint is new, we are very much looking for the feedback, both in terms of the functionality as well as documentation provided.
Feel free to reach out to our support anytime!
Do I need special approval to use the /journals-experimental endpoint?
I constantly receive
message: ‘You don\’t have sufficient access rights for this action.’,
developerHint: ‘Login succeeded, but you are not allowed to use the specific server resource. You might want to check your settings or check for a typo.’,
The privileges that the app are granted are Sales and Bookkeeping
Hi Lars,
Thanks for reaching out.
You do not need any special approval for being able to use /journals-experimental looking at your error It seems that your e-conomic user has different role than the app that you are requesting (they need to match), so that if your user has bookkeeping and your app has bookkeeping and sales, that would fail. Feel free to reach out to our support at api@e-conomic.com we will be able to guide you, if needed.
Hi guys, it is now the 1 year anniversary of this blog post. Is the journals endpoint still considered experimental or is it production-ready now? If the former, what is the expected timeframe for having it ready?
Hello Daniel,
Thank you for your comment. An endpoint can be used in production, it is still marked as experimental due to the fact that we would like to add entry matching and booking before we fully remove the experimental phrase from it.
I asked this question by email too, but since the answer could be of general interest, I will ask the question here too:
The ‘accountingYear’ seems redundant to me – since each entry has a ‘date’ – and as far as I am aware, accountingYears cannot overlap.
The requirement of supplying an accountingYear basically requires either the integration to ask for all accounting years and find the correct one for a given date – or it requires a manual ‘sync’ of all current accounting years, so that the synced configuration can be used to look up an accounting year from the date when posting data to the API.
Both these solutions seem unnecessary if it is indeed the case that the accountingYear is redundant and (perhaps) might as well be looked up by the API if left out.
If it is indeed not redundant, it would be great with an explanation about why it is not redundant (i.e. if overlapping accounting years indeed exist, or for some other reason that I haven’t thought of)
Hi Morten,
Thank you for sharing the question in general as well.
The presence of accountingYear on the containing voucher object and not solely on the entry data, seems to have been driven by a wish for an explicit accounting year definition.
As far as we could tell from the investigation of the code it is not a hard requirement. As such we’ve noted the removal of the requirement as a feature request so we can prioritize it in, when time allows.
Thank you.