Create a tax_number field type and use it on customer profiles

I created a patch for new field type commerce_tax_number, also provided validation on widget for EU vies and you have settings only for these countries as well. Field is locked on customer profile and disabled on view mode. Also there is post_update for attaching field and install yml file for creation on install. Please check it if I missed something and let me know if you want any changes done. Tnx

Adding new patch improved patch, moving validations to validator from widget and adding support for country code from address field and from tax number from tax number field.

Moved VIES validation settings on field storage settings for validator

The VAT Number module does a similar thing.
Maybe the new tax_number field should implement some of its features, like checking if the VAT country matches the shipping country.

@daira

VAT number validator (for tax number) currently checks for locked address field (and its country code) if it matches tax number country if VAT applicable so this is already implemented in this patch

I am trying to understand the mess with all the European union VAT... What I found (maybe issues, correct me if not) related with this tax_number fieldtype is:
- The VIES validator is disabled by default and since the field settings are blocked validator cannot be turned on.
- When using the field the checkout process fails, with this error:
InvalidArgumentException: Missing required property "display_label". en Drupal\commerce_tax\TaxZone->__construct() (linea 57 de /var/www/web.scaffolding/web/modules/contrib/commerce/modules/tax/src/TaxZone.php).
FIX: I don't know if it's ok, but adding the display_label to "ic" makes it work.
- Then it complains again when trying to obtain the selected "ic" zone:
PHP Fatal error: Call to a member function getDisplayLabel() on null in /var/www/web.scaffolding/web/modules/contrib/commerce/modules/tax/src/Plugin/Commerce/TaxType/LocalTaxTypeBase.php on line 165
FIX: Adding "ic" zone with getIcZone to the Array returned by buildZones fix it.

Thank you for this patch! I fixed a few minor issues with updating and generally turned the validation in the locked field settings on. Altering the settings of locked fields seems to be the topic of #806102: Locked fields can change the widget but not settings - I guess it would be better to either activate it by default or move the validation setting to the form settings.

I further updated the patch and integrated the remarks from #9. As the EU-Vat exemption basically is it's own zone we have to specially handle it to allow negative adjustments to correctly get applied. With this patch it should be applied correctly.

Corrected botched indenting in patch. There are still a few failed tests which are related to the initialization of the tax_number field.

I refactored this quite a bit and moved the validation logic and configuration to the tax types. This seems more logical and should be more extendable than the current eu-only approach.

I created a pull request on github: https://github.com/drupalcommerce/commerce/pull/839

Patch based on pull request attached.

This patch removes much of the functionality added in #13. Further functionality based on this is (re-)added in #2930722: Tax number validation and validation for tax number in the EU and #2927833: Provide EU event tax handling and VAT exemption.

Fixing commerce tax post update issue and providing updated patch

Patch #15 still applies! But unfortunately gives an error on update.php

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /update.php/start?id=3&op=do_nojs&op=do
StatusText: OK
ResponseText: Error: Class 'Yaml' not found in commerce_tax_post_update_1() (line 12 of /d8/web/modules/contrib/commerce/modules/tax/commerce_tax.post_update.php

Possibly this is the same error that patch 15 was meant to fix.

Further to #16, the issue is that the the two lines with Yaml::parse functions should read \Symphony\Components\Yaml\Yaml::parse.

Secondly, the patch does not integrate cleanly into a site with Commerce Tax already installed. It looks like there's no entity update for the customer profile. The error on admin/people/profiles is "The website encountered an unexpected error. Please try again later.Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mydb.profile__tax_number' doesn't exist.

If you have Commerce Tax disabled, then apply the patch, then turn it on, there's no error. You still have to alter the profile form to show the new Tax number field.

/admin/config/people/profiles/manage/customer/display gives an error when you try to add Tax number to be a displayed field.

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;hidden&quot; plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FormatterPluginManager are: address_plain, address_country_default, address_default, comment_username, comment_permalink, comment_default, commerce_plugin_item_default, commerce_order_item_table, commerce_order_total_summary, commerce_price_plain, commerce_price_default, commerce_price_calculated, commerce_product_attributes_overview, commerce_add_to_cart, commerce_billing_period_default, commerce_scheduled_change_default, commerce_tax_number_field_formatter, datetime_custom, datetime_plain, datetime_default, datetime_time_ago, entity_reference_revisions_entity_view, file_link, file_video, file_extension, file_rss_enclosure, file_default, file_filemime, file_url_plain, file_audio, file_size, file_table, file_uri, image, image_url, link, link_separate, list_default, list_key, state_transition_form, entity_reference_rss_category, text_summary_or_trimmed, text_trimmed, text_default, user_name, author, email_mailto, number_decimal, entity_reference_entity_view, number_integer, entity_reference_label, uri_link, number_unformatted, language, string, basic_string, boolean, timestamp, timestamp_ago, entity_reference_entity_id in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">53</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;hidden&#039;) (Line: 56)
Drupal\Core\Field\FormatterPluginManager-&gt;createInstance(&#039;hidden&#039;, Array) (Line: 81)
Drupal\Core\Plugin\DefaultLazyPluginCollection-&gt;initializePlugin(&#039;hidden&#039;) (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection-&gt;get(&#039;hidden&#039;) (Line: 148)
Drupal\Component\Plugin\LazyPluginCollection-&gt;getIterator() (Line: 114)
Drupal\Core\Plugin\DefaultLazyPluginCollection-&gt;getConfiguration() (Line: 293)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;preSave(Object) (Line: 266)
Drupal\Core\Entity\EntityDisplayBase-&gt;preSave(Object) (Line: 490)
Drupal\Core\Entity\EntityStorageBase-&gt;doPreSave(Object) (Line: 445)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 296)
Drupal\Core\Entity\EntityForm-&gt;save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;entity_view_display_edit_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(&#039;entity_view_display_edit_form&#039;, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

Enough testing for now. I'll be using VAT Number module for now. And I think there will need to be a smooth upgrade from that eventually.

The attached patch just adds a new field type (the patch doesn't contain validation yet, and no field is attached to the customer profile type, but just posting the patch I started.

The attached patch is still far from being ready but pushing my progress here so someone else can take that work over.

Bojan and I discussed this on Slack yesterday and agreed to implement the tax number validation via tagged services.

I started by defining 3 value objects (copied the AccessResult approach for the value objects that should be returned by the validate method on the tagged tax number validation services, but we can do the same with only one.

We need to start by implementing a tax number validator for the EU VAT number, I thought we could avoid passing the country code to the validators since EU VAT numbers always start by the country code, but in fact we can't since we wouldn't be able to determine if the number entered is for a european country or not (If it doesn't start by the country code, we can't just assume it's not a EU VAT number).

Remaining work to do:

1. Implement a Symfony constraint validator plugin for the tax_number field type (The problem with this approach is not being able to access the country code which is required to properly validate the tax number), or perform the validation inside a widget or a validator attached to the profile itself.
2. Implement a tax number validator service for EU VAT numbers.
3. Attach a tax number field to customer profile types.
4. Add tests coverage.

Forgot the patch.