Hello people. The Law on accounting in my country is changing and we will have to send realtime data to IRS when it comes to invoicing, starting January 1st. For this, as I understand, I need manager.io API and to build another app to build the gap and communicate between them.
This program is going to be rendered useless for me unless there is API available. There has been talks for years now about new API. Am I missing something or it’s still not available?
@lubos do we have any timeline?
In my opinion, this type of issue is best addressed via a report transformation type solution. The advantage being, after it has been done for one Manager businesses the solution can readily be used for every other Manager businesses in your country.
Some questions in order of importance.
Timing. When exactly must the information be sent to the IRS? Daily, weekly, monthly, quarterly, yearly? If any of these apply, the current report transformation structure should be OK. If it must be sent at the same time as the invoice is emailed, then a custom email theme may work (reformatting data and having the data aggregation supplier added to the send a copy of all emails Manager field). If data really needs to be sent asynchronously for every invoice including if sent by printing or pdf, then some form of ready to send flag / custom field would be required and more direct Manager support may also be needed.
What data actually needs to be sent. Sales invoices, purchase invoices, credit notes, debit notes, payments & receipts, summary data?
Transmission standard. What communication protocol is required? Is there data clearing houses which support simplified or more lenient protocols.
Data format. What data formats are allowed? Tab or comma separated values or must it be in XML or some other standard?
@cavlovic can I please ask which country this is ? and doen’t the IRS authorities provide any guidelines on how they want to receive the invoicing data ? maybe through XML and hub (API) or manually through a website…
@Patch @Tor, I was away for the weekend so I couldn’t reply earlier.
Country is Montenegro. The same system is being introduced in neighbouring countries, so it’s not isolated case. This is real-time system, as I understood. XML data is sent right after generating invoice, then TA (tax administration) replies with a QR code for the invoice, which I have to print on it. All of this is happening on the fly in the background and it should not take long as operator shouldnt notice delay.
Simple presentation is attached to this post so you can take a look at it.
EFI - Prezentacija.pdf (1.7 MB)
This topic has clearly diverged from the discussion of API where it was originally posted, so I have moved it to a new topic. The subject has major ramifications.
In Zimbabwe we have something that sounds similar in concept and could be similar in practice too. I don’t fully know how it works yet, as due to supply shortages I still haven’t got mine set up. But my understanding is that it applies to sales invoices and credit notes. We have to purchase a physical device which contains a sim card and is connected to the computer we use for our accounts. There is software installed on our computer, and it monitors a folder, and as soon as a PDF sales invoice or credit note lands in that folder the software reads it, extracts the data which it sends to the tax authority, and the tax authority sends back a code which is printed onto the bottom of the PDF. This would be what we print out or email to our customers.
So, this workflow requires nothing extra of Manager. If the suppliers of the device are to be believed, the sample sales invoices and credit notes I sent them are compatible with their software. But as mentioned, mine hasn’t actually been set up yet. Their guidelines show the text keys and table structure that the software looks for to parse the data from the PDF, and it’s possible that despite their assurances Manager’s documents don’t actually conform, in which case I might need to look at options for changing the format. Larger businesses would use a different type of device, and I’m not sure how those work.
So, this is a long way of saying that it is possible that you also might not need anything extra from Manager, depending on how the system will work in your country.
@cavlovic, after skimming through the attachment you sent, if I understand it correct and correct me if I’m wrong, this seems to be about cash transactions in POS, see image in p4 in the attachment. Therefore the connection would be between the POS hardware and TA servers and so there must be some local IT companies providing solutions for that.
To take care of the accounting in Manager you could use the aggregated sales from the POS, if that is allowed in your country, and if details behind those aggregates are needed then that should be accessible in the TA system. Putting detailed transactions also into Manager is a work not delivering any benefit IMO.
If this is also about PDFs then if the TA provides some software to read PDFs (like from a folder in your computer…) I would check that before anything else.
I think to build a localized solution to connect to Manager, with the API not finalized, is difficult if not impossible and you would always want to check other available solutions first if no one has programmed this already for Manager in your country. I only know that when IT companies are connecting to XML to a local accounting software in the EU its roughly 200 hours work for a programmer, and that is when API is finalized, so you can calculate rougly the cost if you go that route.
I think the Manager programmer @lubos can never program such a localized solution for each country, that is just not possible because of all the local complexities.
Hopefully this helps some but as I said, this is just after rough skimming
@Tor, please take a look at section 5.4.2 of Functional specification and section 3.7 of technical specification. All of the deails are in files attached.
I would appreciate if someone smarter than me took a look at these and told me if this can be done with manager.io at all without API?
Thanks!
Fiscalization service - Functional specification v3.pdf (713.7 KB) Fiscalization service - Technical specification v3.pdf (1.5 MB)
No. Manager has no native functionality for direct data exchange with other computer-based systems.
On a brief read
I haven’t read enough of your requirements to determine what is really required here
The complexity lies in then interface to the “fiscalization service”
XML should be achievable.
Please clarify, @Patch. I don’t believe you are referring to any built-in functionality, are you? Aren’t you looking towards what might be achievable using the API, possibly exploiting report transformations?
Report transformations: Yes
API: No. While it is true it would work for a single user, the subsequent solution could not be distributed to every other Manager business in Montenegro. Which makes the cost per Manager business prohibitively high.
To try to answer my own questions
The tax administration would like reporting to their Central information service (CIS) at the time each sales invoice, at least some purchase invoices, credit note, debit note, Invoice reverse charge, invoice correction (date/time or type or bad debt or deadline), (or cash deposit) is made.
However where a user is off line the data can be batch submitted at later time. They suggest via a USB pen drive. A QR code is printed on invoices which links to the CIS. Should a customer find the supplier has not uploaded the invoice in a timely fashion, the tax administration suggests the customer should report the supplier.
The implications of this are:
The later batch mode would be best implemented using Managers existing Report transformation interface.
Live reporting per invoice / debit note / credit note / correction could be implemented using Managers existing Report transformation interface. Perhaps by having a second Manager tab open on the report transformation and running it for each invoice / credit note / debit note / correction. However in a multiuser environment that would be sub optimal.
A better live reporting solution would require Manager program support. Perhaps a custom field type which calls a report transformation and returns a QR code. However the best solution for Manager would be to enable support of the range of requirements of the majority of the jurisdictions, not just Montenegro’s requirements.
All but summary data. Including
Payment method (Notes/coins, Credit/debit card, Bank cheque, onetime voucher, company card, summary invoice, Advance payment, transaction account, Factoring, Compensation, Transfer of rights or debts, Debit waiver, Kind paying)
Currency & exchange rate
Operator, issuer, buyer, and seller identification
Amount (total, VAT, without VAT, VAT rate), Margin, Fees, Rebate, unit price, quantity.
Date/time submitted to Tax authority, Date & time invoice created, Date & time invoice issued, Invoice deadline date, Date or range of dates supplies delivered.
So more information than Manager normal collects
One way TLS connection using HTTPS (SOAP 1.1) protocol to a web service at the Tax administrations Central information service (CIS).
All messages signed using a private key (issuer or CIS)
Real time error reporting is included
XML, format defined as well as version definition and updating requirements.
In summary, points 1 and 2 above imply a significant body of work to achieve compliance.
Sound about right to me.
May be able to do better with subsequent jurisdiction in Manager.
Maintenance of course becomes an issue with time.
All this is well beyond my expertise, but these requirements sound incredibly intrusive and realistically unachievable outside a dedicated, integrated (on both ends) system.
I think users can share baseline API code to decrease the workload.
See some earlier API discussion in this forumpost:
I have once tested such XML extraction and I posted in the above forumpost which fields need attention in Manager for this to work smoother and that is besides getting the finalized API. So after ploughing through this conversion to XML I can only say that this process is loaded with technical and localized complications. A basically standard multiline invoice is between 200-300 lines of XML code. Therefore it is my opinion it doesnt matter how far Manager can go in setting up XML code, theme, template, custom report or report transformations for this purpose, I think there will always be need for local pruning in some other software. So why not just move all the “raw” data from Manager to this other software with finalized API where the XML code is structured 100%. Such pruning can be done for each government or tax authority’s liking in corresponding countries, states or whatever it may be. Maintainance of code, going forward, can also be done through the API as it has the flexibility and speed locally for XML coding purposes. So although not being a programmer, API is my bet 
It seems tax authorities and/or governments in many countries are going forward with such real-time or XML demands towards businesses. This will put pressure on accounting systems to comply.
I fear you are right, @Tor. Unfortunately, that will mean fewer options for accounting systems on the market. Only a few—or perhaps just one subsidized—developers in most countries will have the resources to develop and field such end-to-end systems. Practically none will pursue universal adaptability for all countries.
This discussion started with an inquiry from Montenegro. In a relatively small economy like that, it is possible to conceptualize such a scheme. Jump to a lager economy with not only national but provincial or state and even municipal layers of governance and taxation, and the idea quickly becomes unimaginable.
The application programming interface (API) in Manager is a low level web interface to Manager (a web program). Being low level, it can replicate most things a user could do manually, but via that interface it can be automated.
This is a very different concept to a standardized data interchange interface. The latter is static across many versions of software on either side of the interface, programs on both sides explicitly convert their internal representation to and from the interface standard.
Personally I would be very surprised if Manager ever provided such a fixed data interchange interface. In my opinion it is far more likely the details of Managers API changes as the underlying program evolves. This assertion is based on what the API is actually offering and the percentage of managers paying customer base depending on it.
The same issue currently also applied to the Report transformation mechanism. The difference is the entire process is visible to all people working on customizations for Manager (including Lubos). And also the percentage of the paying user base relying on it.
I agree choosing a local data integrator with the simplest interface is sensible. I disagree it is optimal for Manager users to to run another program on their computer. The issue is the difficulty in doing so in a manner the majority of Manager uses could reliably achieve.
The new report transformation interface is far more powerful than the old. Most data is now exposed. You are correct it does not currently have the ability to write back to Manager. Not an issue if the user is copying an authorization code from their tax authority back into a Manager custom field, but is a problem if the process is legislated to be completely automatic.
As for programing efficiency across jurisdictions, that is best addressed by making solutions for each jurisdiction public (as report transformations currently are). That way when writing an interface for a new jurisdiction, a programmer can start with a solution for another jurisdiction with similar requirements.
Guys, thanks for your input. Seems like API is the only solution to these issues, if I am understanding right.
Does anyone have any idea when API will be available? If it’s not ready soon, I have to move to another accounting software…
It has been available and worked for several years.
If you want time scales on when something different will be available, then you will need to make your own guess. I’m not aware of a substantial change to the API plan / idea.
Improvements to the report transformations have been discussed recently.
@cavlovic, I took a look at section 3.7 and this seems to be about XML invoices and I think you will always need to talk to some local IT company which provides service and connection to such central hub for XML invoices. Atleast start by consulting local IT company which can give you specific answers based on your business needs.
Getting the data to make the XML files is not a solution provided out of the box in Manager atleast as of now.