feat: new DocType "Duty Tax Fee Type"

[barredterra]

• Added a new DocType Duty Tax Fee Type.

  This represents a standardized Code specifying a type of duty, tax or fee, as defined by UN/EDIFACT.
  This is useful for generating or importing electronic invoices.

• Create Duty Tax Fee Types after install, for new sites.

• Create Duty Tax Fee Types via patch, for existing sites.

• Added a Duty Tax Fee Type Link field to Sales Taxes and Charges.

• Added a Duty Tax Fee Type Link field to Purchase Taxes and Charges.

• Added a Duty Tax Fee Type Link field to Advance Taxes and Charges.

I wish to backport this because it's non-breaking and useful for e-invoice support in prior versions.

[blaggacao]

This is a great idea. I have experiencia with a similar codelist for Colombia.

There's really just one important observation about the implementation that I have to share:

I noticed that in ERPNext's Entity Relation Model, Account Heads are consistently being used as tax/charges entity proxies. At first, I wasn't sure if I agreed, but after a while of ongoing practice, I have come to appreciate this simplification as a very wise choice. By equalling tax to account, there is one less mapping layer to consider for example in order to prepare electronic reporting to tax collection authorities and similar reporting purposes derived from the Balance Sheet and Profit & Loss Statement.

This choice of tax/account type identity places a real, albeit simplifying, restriction on possible Chart of Account layouts. Regardless of whether we ultimately may agree or not, being a historic choice, it should be honored here, a priori.

This code list also represents a type entity and thus should extend account instead (or in addition of) the proposed models.

---

Furthermore, a couple of ancilliary comments

• A similar codelist exists for UOM
• Codelists of a similar purpose (Tax, UOM, etc) may have diverse publishers and maintainers accross the 195 countries in the world and applicability domains (OASIS, UN, Local Government, Industry Associations, bilateral agreements between two companies, special requirements per each supply chain, etc)
• This may be an indication in order not to automatically load the code list
• The generic nature of code-lists and their diversity, may warrant a different Entity Relation Layout across the framework, for example, a single Code List table with many-to-one* refdoc_doc{type,name} association could map the true flexibility required by the concept of data exchange oriented code lists
• Many codelists exists (for example OASIS) in .gc (genericode) format or even are available via Open Data API, a Code List table could have some instrumentation to make it easy to load & cache such available code lista from a variety of publishers through their standard API offerings.

Since I'm currently implementing E Invoicing for Colombia, there could be a great deal of synergy in speccing and implementing a shared and generic model for handling code lists. I'd be happy to throw away my own PoC design that I had chosen so far for something more generic.