Closed sethobey closed 2 years ago
Do we need to consider the use case where a merchant adds an additional nexus address that does not exist in TaxJar? Because the Magento plugin sends over all the nexus addresses in requests, I believe that adding additional nexus locations in Magento could be being used by merchants to override the settings in TaxJar and possibly to handle situations where they might have multiple nexus locations in a single state.
I think this approach would also remove all of the additional nexus states that have been manually added.
@dallendalton Yeah, I considered that during development and I'm open to any suggestions as I may have misjudged the impact of that decision.
The core issue is we have no way of knowing what nexus addresses were created by the API vs manually, and maybe that is something that should be addressed here. Although we allow administrators to create and edit addresses in Magento, as you know, those addresses also can't be synced back to TaxJar, so I would take the position that TaxJar should be the source of truth for nexus data. Our M2 extension only supports one nexus address per state/region, so I don't think that last concern of multiple addresses is an issue.
While the sync feature in this PR will remove additional manually configured nexus addresses (as we also do when disabling the extension), if we didn't remove all nexus addresses, whenever a merchant removes a state from their TaxJar account, we will continue collecting tax there until they manually remove the entry.
It could be argued (and rightly so) that there is inherently more liability in under-collecting than over-collecting, so maybe that should guide our decision, but in the case that the merchant has manually configured a nexus address in Magento for a given state/region and later tries to sync their TaxJar nexus addresses, creating a proper entry for that nexus region will also fail if a different address exists in TaxJar for the same state/region since the pre-existing manually created entry will take precedence, so we're still not collecting/calculating accurate tax.
I'm not really sure how to quantify the impact of a change like we do/don't delete nexus addresses when syncing from TaxJar, so maybe for that reason alone the last approach mentioned above is the best/only option. Thoughts?
@dallendalton & @jordan-k-johnson - I should've noticed the first time around that there is a field nexus.api_id
that is only written to API-created entities, so I was able to constrain the collection delete to only the API-created entities which should resolve the issue of also removing user-defined nexus addresses.
Context
Bug was discovered where existing nexus addresses are not being overwritten causing additional incomplete entries to be written.
Description
When syncing nexus addresses, all existing addresses will now be removed before writing the addresses from API response.
Performance
N/A
Testing
Versions