bseddon

I think you are missing something. Your test environment does not delegate authentication to another service.

We also use the ‘authenticate’ filter but to delegate the authentication to another service. That is, in our case WordPress is *not* used for authentication as this is delegated to another system.

It appears that your plugin is using the ‘authenticate’ filter in which to test whether the user has reached the threshold of attempts to sign in.

Our use of the ‘authenticate’ filter precedes your use of the filter. The result of this is that our user is authenticated by the time your filter runs but you do not check in your use of the ‘authenticate’ to see if the user is already signed in.

This has the effect of saying ‘we can use the authenticate filter but no one else is able to use it’.

Hope that helps. Will it be helpful for me to reproduce this behavior in a test WP environment so you can experience the behavior and have full machine access?

Thanks for your response. As an image speaks a thousand words…

Is it likely to be because the site delegate sign in authentication to another server using the ‘authenticate’ filter? I can see in bootstrap the authenticate filter uses the ‘maybe_allow_login’ function of the security class.

What I can’t see in there is any test that the user is already signed in by a previous execution of an authenticate filter with a lower priority.

If so, how is the function detecting a previous successful authentication?

Hi

The mistake was to make the metabox available to WooCommerce users. The VAT plugin for EDD does not automatically add a label for the VAT rate type to the purchase but the plugin for WooCommerce does. The VAT MOSS plugin compenstates for the omission by the EDD VAT plugin but also make it available from within WooCommerce. This is not correct.

The VAT plugin for WooCommerce adds a meta value to each purcahse which is held in a field called ‘_tax_type’. This is the value retrieved on line 295 of ./includes/integrations/class-wooc.php. To affect the tax rate type for each product you will need to use the relevant feature supplied by the WooCommerce VAT plugin.

I will update the code to return a default value of ‘standard’ not ‘reduced’ and to prevent the metabox appearing for WooCommerce shop admins. Preventing the metabox appearing will eliminate the warning ‘Use of undefined constant VAT_GROUP_CLASS_REDUCED’.

At the moment the default value is being used on line 295. Currently this is ‘reduced’ and should be ‘standard. My guess is that the default value is being used because _tax_type field is empty if the standard rate applies though it could be that the location of this value within the WooCommerce purchase record has changed since the VAT MOSS plugin was first weritten.

When I have an opportunity I’ll take a more detailed look. The will allow me to look at the isse with the call to a deprecated method and to review how the _tax_type value is stored.

In the meantime you should be able to stick with the change you made today.

Regards

Bill

So it seems the WooCommerce integration class does not use VAT rate type added to a product by the meta box (I agree with you that they are called meta boxes).

If you review line 526 of ./includes/integrations/class-wooc.php you will see that the implementation attempts to pull what the VAT MOSS plugin calls the ‘VAT Rate Type’ from an array element called ‘_tax_class’ of a variable called ‘$item_meta’ which is set by calling the WooCommerce function $order->get_item_meta( $item_id ) called on line 475 . In turn $order is set by calling wc_get_order( $payment_id ) on line 454.

I think if you change ‘reduced’ at the end of line 526 it may solve your problem. My guess is that since the VAT MOSS plugin was written, how the tax class information is stored has changed (or was never really correct).

If you are able to verify my guess I will update the plugin.

Bill

• This reply was modified 5 years, 4 months ago by bseddon.

Hi. You have me confused. In your orginal question you mention that you have used the ‘meta’ box on the right of a download to select the correct rate type to use and in the previous post you include an INSERT statement that shows the VAT MOSS meta key. This suggests you are using Easy Digital Download. On the other hand you mention that you are using the VAT plugin for WooCommerce.

Can you let me know if you are using EDD or WooCommerce?

Thanks

Bill

I’m struggling to see how that’s happening. If you look on line 105 of ./includes/meta-box.php you will see that the meta box stores the selected rate type with a key of ‘_moss_rate_type’. This value is returned by the function ‘vat_rate_type_to_use’ that can be found on line 22 of the same file.

The function ‘vat_rate_type_to_use’ is used on line 351 of ./includes/integrations/class-edd.php. It is used to select the rate type name (standard, reduced, etc.) for each item associated with each purchase (assuming you are using the standard set of rate).

If the rate type has been set for each product the it should be pulling the rate type name ‘standard’.

Can you see the meta key ‘_moss_rate_type’ in the postmeta table for the post_id records assicated with the EDD download definitions? Does it read ‘standard’?

The other point of potential failure is on line 306 of ./includes/class-integrations.php. The name reported is not strictly the name mentioned above. Instead it is a lookup of that name so that, for example, ‘standard’ is turned in to ‘Standard’.

However, I don’t see this issue (I submitted on July 1st) and no one else has reported an issue since Martin and Garry commented on the post you reference.

I am happy to try to figure out what may be wrong but as I can’t reproduce the issue I will need your input.

Hi Martin

Thanks for the information. The message will not affect what you want to do and occurs because the block of code defined by lines 41-49 in new-submission.php should not be there – they are part of a feature never implemented.

Until an update is pushed out, to remove this block you have 3 choices of the steps you can take to remove the message from your log file:

1) Define constants STATE_SUBMITTED and STATE_ACKNOWLEDGED in your functions.php file. Use the values ‘STATE_SUBMITTED’ and ‘STATE_ACKNOWLEDGED’ to avoid any issues. Using ‘published’ would be a bad idea.

2) Remove the lines 41-49 from ./includes/admin/new-submissions.php

3) Install the VAT-ECSL plugin from this site (https://www.ads-software.com/plugins/vat-ecsl/). Although you do not need this plugin (because it supports a reporting requirement of UK businesses) the feature never implemented in VAT-MOSS is implemented in the VAT-ECSL plugin so the constants are defined by this plugin. I never see the message in the log because I have the VAT-ECSL plugin installed.

Regards

Bill

The VAT MOSS plugin is an admin only plugin. This code should only be executed by someone using the WordPress backend functions so visitors should not see any effect because for them this line should not execute.

If you look in the plugin’s main file (vat-moss.php) on line 502 you will see that there are no plugin files included unless a number of conditions are met. One of those conditions is that the WordPress function ‘is_admin’ returns true.

Even for an admin there should be no effect because the call to ‘setlocale’ fails so the locale remains unchanged.

Hi Ben

The statement on line 45 is:

setlocale( LC_ALL, $locale );

The $locale variable is set by this statement:

$locale = ( isset($_COOKIE[‘locale’]) )
? $_COOKIE[‘locale’]
: (isset( $_SERVER[‘HTTP_ACCEPT_LANGUAGE’] )
? $_SERVER[‘HTTP_ACCEPT_LANGUAGE’]
: ‘en_GB’
);

As you can see, it defaults to ‘en_GB’ will first try to obtain the locale value from your cookie (the one set by WordPress) or from the HTTP header value ‘HTTP_ACCEPT_LANGUAGE’ set by your browser.

My guess is that one of these values exceeds the length of a valid value permitted by the PHP ‘setlocale’ function (which is 255 characters).

This Stack Overflow post suggests that on some Linux operating systems distributions the locale is not stored as an array but instead a string and that this causes the error.

The issue is that I have not anticipated this possibility and it seem I should be checking for a string and converting it to an array and passing the array to the ‘setlocale’ function.

You immediate solution is to edit submissions.php and edit line 45 to read something like:

setlocale( LC_ALL, ‘en_GB’ );

In the meantime I will have to figure out how to replicate this scenartio.

You are correct that VAT should always be charged on domestic B2B sales – but only on the sales of digital products. For example, if the sale is for a hard copy of the publication then VAT does not need to be charged on B2B sales.

I will be surprise if WooCommerce is not doing the right thing or does not have an option to enable charging on domestic digital sales. Are you sure you have specified that the products you are selling are digital?

There is no ‘click a button’ way to make it default to ‘standard’. You can change line 26 of the meta-box.php file to return the defined constant VAT_GROUP_CLASS_STANDARD instead of VAT_GROUP_CLASS_REDUCED.

You can also create a function to update your downloads to make sure the post meta value ‘_moss_rate_type’ exists for each download and has the value ‘standard’.

But I’m not sure it is worth the effort. The VAT class name is just some text included in the MOSS summary report generated by the plugin. You are going to have to transcribe the text of this report into a format suitable for the MOSS portal provided by your tax authority anyway. So instead of cutting and pasting the output ‘Reduced’ you can paste ‘Standard’.

A MOSS report only has one line per country so even if you sell to buyers across all 28 member states every quarter there will only ever be 28 instances of the word to change. It has taken me longer to write this response than it will take you to change the text for MOSS reporting quarters years into the future.

The VAT rate category shown should reflect the setting on your EDD download. Among the list of meta boxes on the right hand side of the EDD download definition page is one titled “VAT MOSS Rate Type”. By default this is set to reduced (when the plugin was created back in 2014 all the digital rates were classed as ‘reduced’). Change it to ‘Standard’.

I’m interested in this answer.

VAT MOSS and the EC Sales list are two different things and both must be reported. If you have a letter from HMRC stating otherwise I think you may have asked the wrong question.

VAT-MOSS is about reporting to EU tax authorities (through a single authority) sales to consumers.

The EC Sales is is about sales to businesses. That is, sales to entities able to enter a VAT number. It is essential that these are reported separately because they are subject to the reverse charge mechanism (a separate and preexisting provision of the tax legislation). Without it tax authorities cannot determine when they should be expecting VAT revenues on purchases from businesses in other EC countries.

You are correct about SAF-MOSS but until the first audit queries begin we’ll not know what will and will not be accepted.

Thanks for the report. The test was wrong and has been fixed.

The message is informational only and does affect the plugin (except to the extent that if a suitable VAT plugin is really not available, it will not work).