Desktop 24.9.19.1857 WIN10ProX64
Internal Error when viewing Invoices with Relay Option enabled
There is no Error when doing the same in a Server Test Version 24.9.19.1857
1 Like
Good day,
any update for fixing this bug?
regards,
Working on MANAGER version 24.9.2.1834 and Zatca eInvoice Generation System v24.09.06.0002 and working fine. Is there anything new in the next Zatca eInvoice Generation System versions?
Has the time topic been updated?
The bug report is for newer versions as indicated. When fixed it will be unlisted as a bug and also a post will be made by the developer that it has been fixed.
The issue about timestamp is another topic and not part of this bug report.
1 Like
Yes, there are some changes in data relay. I will release a new version once the bugs in Desktop Edition v24.09.16 or later are fixed.
1 Like
The latest version (24.6.1) adds new concept to Manager called “Relay”
Relay will be used to implement e-invocing, online tax lodgement, bank feeds and all other integrations with external services around the world.
This post is intended for developers who are going to be developing relay services.
Relay is a simple mechanism that will allow external websites to receive data from inside Manager app. When relay is triggered, Manager will make POST request to relay URL. POST request will contain data that external service will require for its processing. External service can then navigate user back to Manager app creating seamless workflow.
This is fine for tax lodgements where figures from tax report are to be simply lodged. But many relays will be bi-directional. This means Manager will send data to relay service and relay service will send back new data.
For example, e-invoicing relay service would return updated sales invoice with additional information. Bank feeds relay service would return list of new payments and receipts etc.
Here is how to get started developing your own relay service:
When you create new sales invoice, there is new field named Relay. Check the checkbox and enter https://relay.manager.io. This is so-called “playground” relay service that will allow you to examine the workflow.
When you view invoice with Relay being set, you will see new button named Relay.
When you click the button, Manager will POST invoice data to relay URL (in this case https://relay.manager.io)
The website you will be redirected to explains the rest.
6 Likes
Can we have this setting in settings Tab?
This works, but it looks like we need more data to be processed by the web services. The most complete data is in the Edit form, can we send the data as in the Edit Form?
1 Like
You are creating a man in the middle with access to Manager users confidential data such as
-
Passwords or other verification data to their tax authority and bank accounts
-
Full financial details of any tax returns
-
details of all a businesses invoices
So while I can see Manager giving that trusted data to a third party web site maybe convenient, doing so creates a huge security risk.
A data processing model which restricts unencrypted data to the source (Manager software and locally run extensions) and true destination (actual bank, Tax authority, other business in B2B) is far more secure and has a far smaller attack surface.
You are heading in a dangerous direction, sure it’s a convenient technical solution however I have seen no evidence the required data security or associated required discipline exists.
Working on it.
I wish you’d have a job advising the government and tell them. Take Australia for example…
- It would be nice if accounting software would be able to connect directly to your bank but only accredited third party organisations can get access to open banking. Less than 200 organizations went through the process since its inception.
- SingleTouch… same story here. You need to be ATO-whitelisted orgranization in order to directly access their STP API. There are less than 20.
So for bank feeds and single touch, it’s not possible to connect directly to the bank or tax authority. You need to go through trusted provider.
That brings me to your comment about man in the middle attack - the government is insisting there is a man in the middle.
In other countries, situation is better. E-invoicing in Saudi Arabia or Greece can be submitted directly to tax authority (no man in the middle). So relay services for these countries could be open source projects that could be hosted by anyone or even by the tax authority themselves. So this would eliminate man in the middle where it’s possible.
3 Likes
What is the difference between the concept of relay and an API - other than the obvious MITM factor that is.
For example bank feeds would rely on an api to pull data from bank. I assume e-invoicing is pushing data from Manager to the tax authority in the relevant countries. This is basically what an api does anyway unless I am missing something?
Will this new Relay allow one to upload VAT returns in the UK to HMRC and maybe even payroll RTI?
Relay is Push method. API is Pull method. Push method will work on desktop edition too. Pull method won’t work on desktop edition because there is no API endpoint that external service could access.
That’s the plan.
2 Likes
So, focussing on where decrypted data is available and authentication interfaces
The most secure solution possible where direct access allowed is
Manager ↔ Bank / Tax authority etc
The most secure solution possible where direct access not allowed is
Manager ↔ Accredited provider ↔ Bank / ATO etc
But what is being proposed is
Manager ↔ Relay ↔ Accredited provider ↔ Bank / ATO etc
In all cases a relay is at least an additional security risk.
Single touch pay roll is an accredited provider who has met the ATO security audit and uses used multi factor authentication when entering or updating ATO account access identifiers. In addition, when Single touch payroll access the ATO, they uses their own login credentials so any security breach is traceable.
Any hosted relay will be at a far lower security level. As proposed it also implies the relay has the Business login credentials to the bank / Tax authority / Accredited provider, enabling anyone who gains access to the relay to impersonate the business.
The security risk of a relay are very significant Imo.
Hi there…
It works but… I got some observations:
1.- I can’t find the UID of the document in the data sent, so I can’t take any further action like set info back to the invoice custom fields using the Manager API.
2.- This should be a setting in the configurations tab. A regular user shouldn’t be able to change the URL nor to copy and paste every time an invoice is created.
3.- It would be great if we can setup the URL and the name of the button as well. A regular user will not understand the “Relay” concept.
Is it there a way to get the document from the URL??
Beste regards!
Nothing stops accredited provider or bank/tax authority to run their own relay. I have no control and no leverage to force them to do so. If the argument is that integration with accredited providers, banks or tax authorities should be done in pure javascript as an extension. Well…
That’s why Manager used to have Extensions module to faciliate that but nobody has motivation to do this because there is no money in it. OK, I shouldn’t say nobody because @Mabaega does have a good attempt but even his solution is not 100% pure javascript.
Making non-trivial javascript application that works within Manager is hard. It’s also brittle because there are no clear boundaries what javascript developer can or cannot do because they can do anything. And when I make updates to the program, it can break their javascript app suddenly and in unexpected ways.
Relays can be programmed in any programming language. That lowers barier of entry. Relays can be also monetized, that increases motivation to create them. And most importantly, they have clear boundaries so they won’t break as often and if they break, it will be much easier to fix them.
It comes down to trust. If relay is open source project, then it can be hosted by anybody including the accredited provider / bank / tax authority themselves. If it’s not an open source project, it’s being run as a business and you are probably their paying customer. Their motivation is not to mess up otherwise their business will fail.
Also, the business can start as untrusted party and eventually can become accredited provider themselves. So either way, eventually this security issue will resolve itself.
But we need to get the ball rolling. When bank feeds started in Australia, you had to give untrusted party your bank credentials. Eventually open banking was established to address this security issue and these untrusted parties became accredited parties. Now nobody needs to surrender their bank credentials. So there is a precedent of temporarily compromising security in order to deliver value.
Don’t use Manager API when using relays. You are meant to POST json object back to the referrer which will update the invoice. This will work across all editions including desktop edition.
Yeah, for e-invocing that would work but there are other types of relays that won’t work with global relay URL.
The user doesn’t have to copy and paste URL every time. There are Form Defaults so the URL is initial value when creating an invoice.
I agree. The latest version supports name= parameter in relay URL.
So you can have URL such as:
https://relay.manager.io/?name=Submit%20this%20invoice
Then it will show as:
The latest version (24.6.2) will post HTML of view screen. So now there is new View parameter. You can parse HTML to extract more information from invoice that is not available in Edit object.
We still need all the CustomField2 on the level Invoice, Lines, Supplier/Customer, Inventory and Non Inventory/InventoryKit to be sent to relay, even though Show custom field on printed documents is not selected. We also need Currency Code information, all Foreign Curency Codes.
Not all data needs to be displayed on the printed invoice, but we need all data to be processed into UBL.
Hi Lubos:
Is it too much to ask for sending the UID regardless I can Post back? It would be easier to have it, because E-Invoicing process can last up to 4 minutes here in Panama, so I have to post back a “Pending” status and then keep tracking till it’s done and then come back through the API. If not, I have to make the user to wait there without closing the window and will be a mess.
I can work with that, but I don’t like the fact that a regular user can mess around with the URL. I’ll be trying a extension to hide this from the final user.
This works perfectly! Thanks!
You won’t come back through the API because in case of desktop edition there is nowhere to “come back”. User will be simply required to click the button twice if the processing takes longer than expected (you said up to 4 minutes). The second time you will recognize the invoice already being processed and if it the process has completed, you will update the invoice by posting the invoice data back to Referrer.
As for how to recognize it’s the same invoice that is already being processed. I will expose UUID of the object in Key parameter. But you can always insert your own data into custom fields of the invoice. For example, e-invoicing service will issue some kind of ID for the invoice. You can store this ID in custom fields. When the invoice is relayed again, you will see it already contains ID in your custom field.
This is minor issue. Maybe I’ll come to conclusion you should be able define relay on either object level or object type level. If it’s defined on object type level, then relay button will show on all invoices. Let’s leave it as it is. We will improve it as we learn more about this workflow.