#caturner81_automatic-tax-address

1 messages · Page 1 of 1 (latest)

nova lakeBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1336103427939369052

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

final pike
#

Hi 👋

I'm taking a look at these objects but it'll take me a minute to review the data.

tawny ginkgo
#

Thanks, no hurry, I appreciate the help.

final pike
#

Okay I'm guessing this is a test customer? Since you first put it in New Mexico and then in Colorado? Or just moved recently?

tawny ginkgo
#

This is all test data, it's in my test account

final pike
#

Then you create an Invoice in this request, which still returns requires_location_inputs for the automatic tax

tawny ginkgo
#

I've tried about 50 things before messaging you, and as I said my test that handle everything from scratch seem to work successfully, but I can't successfully make a payment with that customer I originally linked successfully

#

I experimented with some random addresses thinking maybe it didn't like mine, that Clubhouse Circle address is my actual real address, I was testing with that and have Colorado tax setup in this test environment.

#

I guess I'm trying to figure out exactly what i need to do to invoice in_1QoVf7J3HL2D6vdeawbloWdT or customer cus_RR1JEG65JYb7km to be able to issue an invoice/pay API call successfully against that invoice

final pike
tawny ginkgo
#

I don't see what you're referencing looking at that log

final pike
#

Sorry, you wouldn't. It's an internal log. I"m just flagging in case it jumps out at you. I'm still digging.

tawny ginkgo
#

Ahh ok, every address I've tested with uses "US" as the country code, and the shipping looks correct in the shipping details of that invoice

#

Actually.... that one says "United States", I wonder if somewhere in the frontend code it's... I bet that's it.

#

That invoice got created through the full frontend experience, and that's probably incorrectly putting that there.

final pike
#

Oh..... yeah that will cause it fail. I think we really need to add ISO compliant validation on those inputs

tawny ginkgo
#

Boy, that internal log you had sure would be handy for API users to be able to see, I could have probably tracked that down with that information.

#

Cool, ok, I assume I can sort this from here. I've been banging my head against that for a couple hours. Sorry for it to be something so silly. Thank you for the help.

final pike
#

No worries! I think it's easy to get deep in the weeds with this stuff and we 100% could do a better job surfacing exactly what is wrong.

tawny ginkgo
#

Overall your API is the best I've ever worked with. The only other real issue I've seen is that there are ways to set an address line2 to an empty string rather than null with the API. Some calls interpret an empty string as null, others don't, which is a little funky. Just a heads up.

final pike
#

So is there an issue with handling the line2 value if it's "" vs null?

tawny ginkgo
#

Yeah, I can dig back into it if you want to actually run the details down with your team. One of the API calls interprets an empty string as null when updating line2, which is correct as far as your API goes I think, another call doesn't do that and incorrectly sets line2 to an empty string, so there's no way to null out line2 in that API call without making 2 API calls, one to nuke the entire address, then another to set the new address that doesn't have a line2 value.

final pike
#

I guess I don't see the problem yet. Since you're using Python, both an empty string and a null value should evaluate to False, allowing you to avoid passing that parameter.

tawny ginkgo
#

So, imagine a customer has an address that has a line2 value, I want to update that that value to a new address that does not have a line2, I need that field to be nulled out, it's optional right? Ok, so I pass an empty string to that API call. Some of your APIs interpret that as line2 should be null, others don't and actually set line2 to the empty string, so when you fetch it from the API again it doesn't come back null, it comes back as an empty string.

#

And you have to send the empty string because the update happens per field, so if you don't send it at all it'll stay as the previous value.

final pike
#

Ah, gotcha. So are you saying you just want a consistent behavior wherever this logic is applied?

tawny ginkgo
#

Well, in this case it doesn't even seem possible to do what I want. I want to be able to update the address and null out line2, that's literally not possible in this case because if I send a "null" value it's ignored entirely, and if I set an empty string it isn't interpretted as null, it's interpretted as an empty string. Consistency would certainly help, as there's another API that has basically the same functionality for addresses but behaves completely differently.

final pike
#

Gotcha okay I understand the problem space sufficiently to write a solid feature request.

tawny ginkgo
#

Cool, appreciate it.

#

Alright, I'll stop taking up your time, have a good evening.

final pike
#

Feedback filed! 👋