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