Hello
Here in Greece, will be required from 1/1/2020 for every accounting software to have a connection mechanism with the official national accounting platform (GSIS.gr) to submit the transactions directly there.
Is there any plan for manager to implement such a mechanism?
Thanks
the same is applicable to India. still awaiting a response from @lubos
@Dimitris_Kontodimos it would help with the development if you provide any official links where the requirements are explained clearly.
@sharpdrivetek Let me gather the material and I’ll come back.
You may find it more efficient to look at data transmission companies offerings. I’m only aware of Manager producing coma separated values files for uploading.
@Patch csv is fine. As it has the proper layout. But the whole operation must be automatic I think. Meaning, there must not be a human involved to take the produced csv file and upload it to the platform. I am going to search about this and come back to inform you.
An current example is
https://www.manager.io/localizations/au/07332ba33e824dc194511350f5d84e24
To see how it works you can load it into a test business.
These are done via Localisation, which are currently evolving in Manager. My current understanding is summarized here Localisation: GST/VAT worksheet programming guide
@Patch invoicing and reporting are completely different. localization feature in Manager deals with reporting. E-Invoice needs to be generated in the official govt portal, authorized and stored every time an invoice is recorded in Manager. the need here is to have a feature where an invoice can be exported from Manager in a format acceptable by the govt portal where it is authorized and when imported back to Manager it automatically updates one or two fields of the invoice.
for example, our govt has proposed that the portal would generate a unique reference (separate from the invoice reference in Manager) for invoice after it is authorized. so after authorization the file can be downloaded from the portal in the same format which when imported back to Manager would automatically update a custom field created for recording the unique reference generated by the portal.
if you have the time you can check the links provided in my topic for better understanding.
In my opinion, no one should hold their breath waiting for such capabilities in Manager. There are about 200 sovereign entities in the world today. The task of interfacing electronically with potentially all of them for real-time invoice generation would be staggering, especially for an application with desktop and web-accessible editions.
As you look around the world at nations that are beginning to require direct upload of reports (let alone invoices), you find they are being serviced by small startups focused on one (or at most a few) countries’ submission requirements, or else by gigantic software firms who can charge significant amounts for the service/capability. Even the big firms have no universal solutions.
Many of these concepts sound simple on paper, but will be nightmares to implement. Even something as simple as sales tax is nearly incomprehensible. A sales tax is simpler than VAT, because it includes only the output side, yet no one has a universal solution. As an example of the magnitude of such tasks, in the United States alone, there are close to 11,000 different composite tax codes supporting thousands of independent jurisdictions. Each jurisdiction could end up with its own electronic reporting requirements. How would any program possibly respond? In the UAE, compliance inspectors and tax authority public education personnel apparently do not agree on what the plain language of implementing regulations for the decree-law on VAT means. The UK’s Making Tax Digital scheme has suffered numerous delays. Australia has announced forgiveness or leniency on its own laws on electronic submissions.
Now imagine what might happen when tens or hundreds of thousands of businesses start uploading sales invoices for approval in real time. Are any of us confident of our governments’ abilities to undertake development of such systems, let alone operation and maintenance? What happens when the “National Invoice Approval Agency” experiences a budget cut? Or a simple power outage?
I’ve gone on long enough with my message of gloom. Let me conclude by observing that Manager’s developer has typically waited until final implementation of any jurisdictional requirements before responding to avoid false starts. And he has so far avoided any steps involving direct data interchange with national authorities, thereby avoiding the need for local certification. I doubt that will change. And that outlook may mean Manager becomes unusable in some locations. But I have no knowledge of his plans in this regard.
If I can share my experience with electronic invoicing in Italy, which was the pilot nation for EU, here is my workflow.
I use an official and certified online platform to emit the digital invoices in the correct and always updated format XML file and to submit them to the centrilized national platform.
Done that I created a script, starting from the export file from the online platform to import customer and supplier invoices and credit and debit note through batch create.
The extra time I spend through creating customer invoices in an external software and importing them in manager is completely balances by the time I save importing the supplier invoices without manual entry.
It’s a workflow that was refined since the introduction of electronic invoicing in Italy, ie 1/1/2019.
@Tut the need is not to interface Manager electronically with national authorities but to generate and import a file in an acceptable format which the user can manually exchange with national authorities.
Manager is compatible with importing json files as the localization feature is based on the same. so it should be possible to create json files from Manager. the complexity would be to develop it in a way every user irrespective of the nationality can utilize the same.
the data required for an e-invoice is already available in the Manager form. other necessary data can be added by custom fields.
@lubos an idea for development would be
Electronic or manual, the difficulties are the same. Keeping up with standardized, periodic report filing is hard enough. You described an invoice-by-invoice exchange of very invoice transaction, with submissions and approvals flowing in both directions. It boggles the mind.
the difficulties are not the same.
an invoice generated by any software in its own layout will still be valid even after the e-invoicing system is implemented. the only change is that these invoices need to be authorized to be valid. the authorization is a unique reference code which needs to be recorded on the individual invoice.
for authorization purpose the user needs to submit on the govt portal the invoice details generated by their preferred software.
now the difficulty in manually making the same invoice twice (once in Manager and once in the predefined format acceptable by the govt portal) is not the same as Manager being able to generate a json file of the invoice which can be directly uploaded to the govt portal for authorization.
@sharpdrivetek, I was not addressing the technical steps of the data interchange. I was referring to the difficulties of any software keeping up with requirements and processes in thousands of jurisdictions around the world. And I mentioned the problems tax authorities are having implementing their own sides of systems in their own countries.
Discussions about mapping headings, .json files, XML formats, scripts, and portals probably leave 95% of users in the dust. Experience is showing the current localizations framework is not working. Many users can barely manage to download and install a developed localization package. There are very few examples of users developing their own. What seems simple to you is magic to most people using Manager.
I don’t know the solution, but so far neither do SAP, Oracle, or Intuit.
I think most users are utilising localisations where available. New localisation are not occurring as Lubos removed the ability to upload localisation and said everything implemented under the current scheme will be obsolete.
I agree direct electronic two way communication is an order of magnitude harder than any thing Manager has done. In addition to having the basic data their is physical and electronic registration of the software and user, bidirectional secure identification, message encryption, message flow control, error handling, software validation, and maintenance of all this. There are some tools to help with this and better tools maybe available in the future but it is currently well beyond user localisation, or NG software
When I read the several opinions I would suggest to go for simple improvements. Many reporting tools are able to report in CSV and several others formats like PDF, HTML, XLS, RTF, ODT, TXT and XML files. When this is added to manager.io then several manager users are probably a huge step forwards for their wish to interchange data and it is generic functionality for all users over the world.
There are open source reporting tools which has this functionality standard available without any effort. See jasper reports. Ofcourse it is easy to state and might be tough to combine this with the current neat and quick installation and tough to rebuilt the current reports. May be there are other simple options too to add CSV functionality with less effort which might be sufficient improvement at this moment to help many users.
@Roberts, transactions and reports in Manager can already be exported in TSV format. TSV is used instead of CSV because many number formats available as preferences use commas as delimiters or separators. See Copy lists and reports | Manager.
Seeing this from a users perspective, it seems this XML invoice approach is being pushed down from government in many countries and it seems this is not a question of IT or businesses being ready as such, as this seems to be somewhat political. Reason being this is more convenient for governments and cost effective or for tax surveillance etc. So this XML thing is basicly falling into Manager user’s lap to solve whether we like it or not.
In my country, Iceland, this government XML adoption has been postponed year after year but now in 2020 the government will not accept bills on paper or PDF any more, so XML invoices is the way to go. This is not a problem for the big companies as such as they use software like Nav, SAP etc and this has been programmed into their software but these larger companies have been using XML invoices B2B for a quite long time with good experience it seems. But for smaller companies this is something they are not prepared for.
As a short term solution, and not having to manually type invoices, I agree with @Roberts, regarding if it is possible to take small steps in changes in Manager if it can help users with some manual batch mapping or making the steps fewer in some manual process to produce XML invoices.
I must admit that at first I fell into the pitfall of thinking this is just some simple XML export of some mapping after seeing a XML textfile as these textfiles look rather simple. But after talking to XML experts there are all sorts of small errors which can start to creep up if you are not careful. These small errors demonstrate the complexity of this standardized mapping and this is likely what @Tut was talking about.
For example in my country there is nothing called “unit” like if you sell a couple of units from stock. The XML standardization must be some specific code from United Nations standardization list which says what is exactly being sold, that is “unit”!.
Another example is how to tackle standardization of which currency is used which I gather can also complicate things.
Then also validation of XML is not always enough, if the receiver of the XML bill has to have some special id, which he provides, on the bill for it to be acknowledged, otherwise the bill is discarded.
Sometimes there has also to be not only billing address but also a standardized cost address, like a big company wants to know in which of their branches the cost occurred.
So from all of these examples above and experience of talking to XML experts how XML invoicing has been done locally, it seems that to have this XML mapping automatic and running 100% correct it must be locally programmed/mapped into the accounting software, based on local legal detailed standardization rules and other needs of businesses.
As a long term solution for Manager, which likely only @lubos can answer, mapping to standardized XML would maybe be possible for local programmers to solve, as they seem to be good at this XML mapping, when Manager’s plugins will be available ?
Output in xml is a little more difficult than cvs but not a lot.
The complexity is the bidirectional communication protocol, with the associated authentication, validation and error reporting at transport and application levels. Do this several times in each jurisdiction then multiply by the number of countries Manger supports and the task becomes well beyond NG Softwares resources.
For example in Australia just for payroll DSPANZ - About STP Products
In Italy https://www.fatturapa.gov.it/export/fatturazione/en/normativa/f-2.htm?l=en
In the UK Making Tax Digital for VAT as an agent: step by step - GOV.UK
With tool development at a relatively early stage http://holodeck-b2b.org/
That is why an intermediate data communication supplier is more achievable.
Thanks for your supplement.
You are right that TSV is an option. I overlooked this option.
For data interface it would be better not be able to use different number formats to keep it simple.
When there are many users of TSV exports then configuration/change management will be of greater importance for those exports.
Dimitri do you know if the program will be able to connect with AADE?
There is a way?
thanks