Electronic Invoicing

@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.

1 Like

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 https://www.manager.io/guides/10645.

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 https://www.absia.asn.au/ato-stp-products/
In Italy https://www.fatturapa.gov.it/export/fatturazione/en/normativa/f-2.htm?l=en
In the UK https://www.gov.uk/guidance/making-tax-digital-for-vat-as-an-agent-step-by-step
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

Any answer @Giorgio_Flores, @Dimitris_Kontodimos to your concerns?

After looking into local XML standards in my country based on European regulation for electronic invoicing, if possible it would be very beneficial to have some minor tweeks in Manager. Maybe big part of this is only some minor adjustments of database tables for Custom Reports although not being a programmer. Such tweeks atleast could help a great deal in the mapping process when doing XML invoices based on the Manager platform. I know some of this has been discussed somewhat before in the forum but maybe not in relation to XML invoice mapping. These are suggestions for small steps to changes in line with what @Roberts mentioned previously.

1-UNIT NAMES
A more robust central list of Unit Names, just like Tracking codes in settings, would help in safeguarding that only specific unit names are used and minimize risk of accidental typos of Unit Names which is open for input, see figure below. The figure for Tracking Code shows the input is not accepted. Such input on the other hand would be possible for users to type into Unit Name
Acc. to XML standards Unit Name is never optional and all XML invoice records have to have a Unit Name.

Unit Name Tracking Code dropdown

2-ITEM CODE/ITEM NAME AND UNIT NAME IN SALES RECORDS
When selling inventory items, feeding Unit Name, Item Code and Item Name into the corresponding Sales Invoice database records would help in getting detailed information on Sales records in Custom Reports which is otherwise not possible.

3-DISCOUNT
Having Discount Percentage in one column and Discount Amount in another column in the database alongside sales records, would help in Custom Reports based Sales records but this is not possible today to have such detailed sales reports. Both types of discount can be zero if either is not applied by the user when making Sales Invoices.

Above mentioned suggestions are integral part of modern Sales Invoices just like Quantity which is included in Sales Invoices records in Custom Reports. All this XML mapping is timeconsuming and complicated enough and obviously has to be done locally and will never be included in Manager software and therefore having such tweeks would help much in modern XML invoice mapping

My two cents suggestion since European electronic invoices have been introduced in Italy more than one year ago: subscribe an online service for the invoices so that it’s always in line with the always changing specs and create a plugin to import invoices in Manager.

@Davide, as Sales Invoices have to be issued inside of Manager where customers information is updated and Invoices are part of processes like sales orders transformed to invoice or Inventory Items is being sold etc I don’t think its usually a viable option to use online service although in some business scenarios it might possible.

Fine… so you have to solve all the issue linked to your local implementation of the e-invoice, transmission, permanent electronic storage and also keeping it update with the continuous changes in the protocol. It depends on you budget.

We had a small budget so we could only create a plugin to sync data between an official online service and manager. We manage everything under manager except the issue of the invoices whose draft is created in manager, imported in the website, transmitted and sync back in manager. The most functional thing of this implementation is that we don’t have to worry about being compliant to the law since it’s a problem of the service provider.

@davide I was only talking about making Sales Invoices inside Manager and not outside of Manager or the sending process. I know that in the property business lease agreements sometimes have complicated payment structure and therefore have to be in a special software and then invoicing info is moved to the accounting system afterwards as an example but I think usually businesses always want to use the sales module in their accounting software if they can

Sending these XML textfiles is then a whole other thing and could be considered the next step in the process where as “forwarding” these XML files through special hubs is done by local IT houses which have access to the European PEPPOL message system which everyone can access, most likely also you in Italy :slight_smile:

More specificly what I do with Sales Invoices (made inside Manager) is to map them into XML code of approx. 500 lines (outside of Manager) according to the EU regulation or Business Interoperability Interfaces on Public Procurement in Europe (BII) and European Committee for Standardization (see https://www.cen.eu/Pages/default.aspx) and then write this to a textfile which is then a standardized XML invoice. A benefit of building XML invoices yourself is you can easily move between IT houses in search of best prices for their services. Maybe when Manager has finalized API the IT houses can “plug in” knowing how mapping is done for Manager from someone who knows Manager but until then this is my setup as of now.

Yes IT houses or service providers can take care of things but in my country the problem is Manager is not there yet. Until then, as all XML invoices are first validated by IT houses before they are forwarded, one can always fix the XML code or API which is very simple code once you get the hang of it but of course this is not for the ordinary Manager user to do but I am sure once there is XML mapping solution for Manager built by someone locally in each country which knows Manager, every Manager user can benefit from that, like with API used by the local IT houses.

The most likely way I can see this happening is for someone in each country to write a localisation to produce the XML report. For an example of the sort of thing that can readily be done now see


Clearly the specific interface to efficiency use it to export invoices is not in place but the programming interface is appropriate. The produced file could then be sent to an IT interface service provider, as is currently done in several countries localisation using text files.

Lubos was apparently intending to extend the capability of the localisation system. I don’t know was the current plans are.

Why not just uses a custom field if type list

As each inventory item is given a Unit Name, for example kg, when first entered into the Inventory Module, it would be intuitive for Unit Name to come through when the inventory item is selected for sale on the line of a sales invoice. Why all the work to do it again in a custom field on the lines on the sales invoice for each inventory item on all sales invoices. Some businesses have huge inventories. Besides Custom Field Line Items does not work in Manager, only Custom Fields on a higher level or for the invoice as such

It would save much work for many users if Manager can handle the basics for XML invoices for as many countries as possible, like atleast the three items I mention earlier, where database tables are more connected so Unit Name and Discount is passed on with the Sales Invoice records in the database.

Using API, which seems ubiquitous these days, seems like a viable approach once finalized in Manager. Until then, Custom Reports will have to do. IMO working with data extraction can be done and maintained fairly efficiently whether Manager or XML invoice standards change. I am not necessarily keen on using some standard reports but its alright of course if such reports work well but usually there is more needed. So having access to all the data with API and extract what I want, besides I can add Custom Fields where needed and get that data also in the API, seems more flexible to get the building materials for XML invoices.

The XML code based on Universal Business Language (UBL from www.cen.eu) also has the flexibility to contain tags which users themselves have need for, like for a clothing item what is the color or size or if its a computer seller what is the memory in gb or hard drive gb etc. All such usertags would therefore likely need custom fields which are unique to each business. This is on top of all the vast variety of tags in XML invoices themselves and all countries have different requirements for the local standardization of XML invoices. For example, if I were to send an XML invoice to Italy, I would first have to talk to my IT house and ask if they have done the country mapping (surprise another mapping level) on their side to cover the differences between those two countries before the XML invoice is sent.

So although this is called “standardised” invoice, I think the wild variety of “standardised” options in setting up such an invoice to the liking of each company in each country calls for flexibility for extraction of data for mapping.

Akoma tipota!!!

I think that a more simple and feasible solution would be to handle the XML invoices in a cloned way of invoices template. Starting from the standard XML invoice, with some custom fields if needed, one can quite easily create the XML that he needs.

No API or difficult programming language. Just a fill in the blanks of the XML with the same standard of the actual themes.

This hax been fixed in custom reports