VAT issue with payments!

This is an adult community and providing billing details or invoice address info is not an option for my users. The best scenario is that they give false info there so it will become much worse for the correct VAT charge. This would be possible if i could set the  invoice address in cart as not editable, but i can not!

This problem appeared suddenly last week! We did not have such problems before.

The invoice address is meant to be their billing details pertaining to their payment method. It's sent along with payment to payment providers. They need to be able to edit it because they could move, change phone numbers, etc.. They shouldn't be able to give false info. Your payment provider should be setup to verify it against their payment method (e.g. AVS verification).

I don't understand what you're trying to do with CB Auto Actions here. As I understood you were synchronizing profile fields. Are you forcing a country for them?

This problem appeared suddenly last week! We did not have such problems before.

Do you recall anything changing in the last week? The only update we released in the last week was for CB Gallery.

I investigated the issue further. In the failed to be taxed baskets, ALL invoicing address snapshot fields inside `#__cbsubs_payment_baskets` are NULL:
* address_street
* address_city
* address_state
* address_zip
* address_country
* address_country_code

For the same users, the invoicing address fields already existed correctly in the CB profile (`cb_subs_inv_*` fields) before basket creation.

I have already mentioned a case where:

* one basket was created with all address fields NULL and VAT NULL
* a second basket created minutes later for the same user worked correctly and VAT was calculated normally

So my impression is that the invoicing address snapshot step during basket creation is sometimes skipped, not persisted, or executed with an incomplete/stale basket/user object.

The relevant method seems to be:
`_setInvoicingAddress($user)` in:
`models/order/cbpaidPaymentBasket.php`

The important part is that CBSubs still allows the payment flow to continue even when:
* basket invoicing address fields are NULL
* address_country_code is NULL
* tax is NULL

The important part is that CBSubs still allows the payment flow to continue even when:

That's normally because you don't have invoice address enabled and mandatory. It's entirely optional otherwise.

Will dig into this first thing tomorrow and see if I can enhance the invoice logic further as well as look into adding an invoice address option that would accommodate your needs better. For example mandatory first edit. Basically same mandatory requirements, but only allows supplying the invoice address once (no edits).

Thank you Krileon.

Just one concern: even if CBSubs adds a “mandatory first edit / no later edits” invoice-address option, I am not sure this fully addresses the issue we observed.In our case, the user already had the invoice/country data populated before basket creation (same as supplying the invoice address once**). The failure was that the basket was still created with NULL fields.So the key point is not only that the invoice address exists in the user profile. The key point is that the existing invoice address is copied into Otherwise, even if the user fills a mandatory invoice-address form once, the same failure could still happen if the existing invoice address is not copied into  

**Giving the buyer unrestricted control over the invoice country during checkout is unfortunately not a good solution for our OSS VAT workflow. If users can freely change the invoice country during checkout, many will naturally try to select non-EU countries to avoid VAT, regardless of their actual residence/location.
For this reason, our workflow determines and validates the country earlier during registration/profile setup and then expects CBSubs to reliably use those existing validated values when creating the payment basket and calculating VAT.

Thank you again.

I'll be investigating that as well. I'm going to drill down the basket creation process and make sure every initialization is being properly handled to pass through the invoice fields into the basket. My guess is there's a basket create somewhere causing your issue where for some reason it's not pushing from the cbsubs fields into the basket.

To help with this please describe the exact workflows these users are taking when this happens. You mentioned Upgrades. So I assume they're logged in, don't have an active subscription, and upgrade into a plan from a free plan? Are both plans marked exclusive?

**Giving the buyer unrestricted control over the invoice country during checkout is unfortunately not a good solution for our OSS VAT workflow. If users can freely change the invoice country during checkout, many will naturally try to select non-EU countries to avoid VAT, regardless of their actual residence/location.
For this reason, our workflow determines and validates the country earlier during registration/profile setup and then expects CBSubs to reliably use those existing validated values when creating the payment basket and calculating VAT.

Then I don't understand how you're getting their address to begin with.

At any rate I'll be looking into addressing this. Basically a "Read Only" mode for invoice address that only lets them supply one if they don't have one. So your auto action behavior would cover that requirement forcing it into read only while allowing the mandatory invoice address logic throughout CBSubs to function properly, which would help reject incomplete baskets so you never have to deal with these refunds again. If you're using Read Only profile fields already it'll be similar to that experience.