That the Supplier form be given a specific business identifier field as occurs with the Customer form.
Tax authorities are moving towards the formal reporting of both the gross taxable values and the individual transactions made by registered taxpayers. In India, the above dual reporting is already mandatory.
These individual transactions made by registered taxpayers need to be 1) connected to a business identifier and 2) have that business identifier included in the tax reports, per invoice.
Inclusion of the business identifier in the reports would create the documentary support required for the tax filing.
@lubos please consider implementing Business Identifier for Suppliers as a priority.
this is a basic requirement and when creating localizations it would be efficient for users to utilize this field rather than any custom field used at present that would become obsolete when this idea is implemented.
In the latest version (21.11.66), I’ve removed generic Business Identifier field from customer form. Generic business identifier field is not the direction I want to take.
Instead, country-specific custom fields should be created (ideally on localization server so it will be automatically available to all users).
Then this custom field should be leveraged in country-specific reports.
Sorry @Lubos but somehow you seem to start restricting businesses to choosing a location that then renders specific fields, settings, customizations, QR codes, etc.
I try to imagine how this would work in for example the USA that does not even have a VAT regime and many differences between states. Similarly, how would a small business that operates in several countries have sufficient flexibility in setting up Business Identifiers as jurisdictions differ and where suppliers and customers will have their unique needs to get their VAT in or out recorded. What about non-profit organizations that are tax-exempt in one or more countries?
More worrying is that Business Identifiers are data that we entered and should not be deleted as somehow that may break what should not be broken. That there may be a need for localizations to comply with for example how a Tax Identification Number needs to be displayed should in my view be an addition to the generic Business Identifier where both are optional to use.
There is going to be ability to select multiple localizations for business in the future.
Generic Business Identifier field was not used for anything other than the content would show right after the customer address. So the latest version simply appends content of this field as extra line on customer address.
In some cases that may work, but what about USA, or other Federal States or France with different territories and departments? One reason I got interested in Manager was that it was configurable to our needs and wants and customizable where applicable. More like a spreadsheet or word processor where the content is developed by the user and the application provides the framework and interface to do so.
Competing accounting applications that are not Open Source such as Quickbooks have also become more restrictive compared to the Desktop versions and have made people like myself that want more control and host on their own server it a more attractive choice. Manager also surpassess Wave by far in flexibility even though Wave has the attraction of receipts scanning-automation and a handy app for doing so.
Localization is an excellent initiative and many will benefit from the tax guidance it will provide. However, one should be able to opt for it on a business by business basis and retain current less restrictive flexibility.
Thank you, your original post was not clear that the content is moved to the billing address as I just discovered and thus not lost.
@lubos i think the first step before removing existing features and introducing new features should be to provide users a tool to migrate data from one field to another. especially when the said localizations is still a work in progress for most countries.
localization might be a new feature by default in Manager, but every user have been locally customizing Manager for years to suit the needs of their local jurisdictions.
now if I set my country under Business Details, I need to move the business identifier one-by-one from the address field to the custom field provided by localization. when I start to think my work is done, every other form shows new localization custom fields for which we already had custom fields. i am not sure how practical this is to move data one-by-one in a business environment especially when there is no guarantee that the localization custom field would remain static considering they are still under development.
ability to map existing fields to localization custom fields is the need of the hour.
Yes they are but @Lubos explained that he no longer beliefs BI is the right approach. My fear was that the entries were eliminated altogether but they at least were added to an existing field billing address which in essence should be business/company-specific too as that it where possible legal and financial transactions between parties take place.
However, I support @sharpdrivetek points about considerations and migration tools not only in relation to BI but to any such actions also in view that it seems that the changes are driven by prioritizing localizations rather than by making the existing approaches and features more robust and cleaning out the list of ideas that would indicate that customers are listened too, just my 3 cents worth
@lubos I would like to bring to your attention that even though the business identifier has been automatically appended to the customer address field, every sales invoice issued earlier using a custom theme shows only the address of the customer and not the business identifier.
I temporarily changed the theme to the default plain theme and still no business identifier is displayed.
the same goes for credit notes. have not checked any other forms where customers were selected.
I am aware that new implementations should not alter historical transactions because there were changes to tax regimes earlier. but in this case I think it would have been better to migrate data to another field rather than removing it. this would have modified only the necessary past transactions.
Wow, how unique.
The only accounting software I’ve seen that does NOT associate the business number with the business name…
How does putting it in the address fields work for those of us that use invoices/receipts for mailing labels (in invoice pouches)? I don’t know because I will not update because of this.
Will it cause problems with the postal services auto recognition?
Also, if it is missing from historical invoices then those invoices that are required to have the number on them will no longer comply with ATO guidelines/regulations.
But the consequence of this change is that the VAT number is no longer visible on the invoices already created.
Showing the VAT number is indeed an obligation:
“Tax authorities The Netherlands:
Your invoices to customers who submit VAT returns in other EU countries must show the VAT identification numbers of you and your customer. Ask your customer for the VAT identification number. Always check the VAT identification number.”
So all invoices already created (for example for foreign customers) are now missing the client’s VAT number.
How can this be corrected without manually entering the missing VAT number on each invoice?
@ries this needs to be solved using localizations. Netherlands need custom field to capture this identifier on customer level. Then invoice extension which will “inject” this to the correct place on the invoice.
to my understanding this would only solve the business identifier issue.
what we need is a solution to migrate all the relevant existing fields or custom fields to the localization custom fields which would replace them. for example, in our use case we already have custom fields like Place Of Supply and HSN/SAC which need to be migrated to the localization custom fields.
a simpler solution (user perspective) would be to take a step back and provide a tool where users can migrate from the UUID of their existing fields to the UUID of localization fields. after migration the now obsolete existing fields can be deleted.
this suggestion will also enable generating localized reports even for past periods where the data is only fetched from the fields provided in localizations.
@lubos can we have the ability of showing custom fields with custom order in the various forms?
VAT number is crusial for Greek invoices, and it’s not agood practice to search for the end of the form to reach custom forms for such a high priority field. Right now it is like burried down.
Because of my implementation of myDATA is almost finished, i have on my task list an extension that will move the fields with javascript and place them in the right order (for Greeks).
I believe such a feature will be handy for all other countries as well.
