Update states/provinces (Italy)

[Kian]

Here's me with the usual boring thread about billing problems. The array of Italian provinces must to be updated.

Add

SU (https://en.wikipedia.org/wiki/Province_of_South_Sardinia) must be added for billing purposes.

Duplicated

VS (https://en.wikipedia.org/wiki/Province_of_Medio_Campidano) is listed twice hence one record should be removed.

Keep

Abolished in 2016:

• CI - https://en.wikipedia.org/wiki/Province_of_Carbonia-Iglesias
• OT - https://en.wikipedia.org/wiki/Province_of_Olbia-Tempio
• VS - https://en.wikipedia.org/wiki/Province_of_Medio_Campidano
• OG - https://en.wikipedia.org/wiki/Province_of_Ogliastra

Abolished in 2018:

• AO - https://en.wikipedia.org/wiki/Aosta_Valley
• GO - https://en.wikipedia.org/wiki/Province_of_Gorizia
• PN - https://en.wikipedia.org/wiki/Province_of_Pordenone
• TS - https://en.wikipedia.org/wiki/Province_of_Trieste
• UD - https://en.wikipedia.org/wiki/Province_of_Udine

No one knows what to do with them but most of accounting softwares prefer to keep them. The problem is that it all depends on Revenue Agency. Right now abolished provinces are accepted but rules can unilaterally change. What we need is an option to override States like we already do with Countries, whois servers, additional domain fields etc.

Yes, I know that states can be updated from /assets/js/StatesDropdown.js but:

1. No one knows it
2. It gets overwritten with updates
3. If rules change and the js is not updated accordingly, the provider could receive fines up to 250 euro per invoice for reasons that I don't want to explain 😴 (and for sure they will contact me asking for explanations. I'm tired of it)

 

Edited January 28, 2020 by Kian

[brian!]

1 hour ago, Kian said:

What we need is an option to override States like we already do with Countries, whois servers, additional domain fields etc.

that's been previously asked for - at least twice from memory, but probably many more than that - as I mentioned in the thread below, nobody has started a feature request for it.

1 hour ago, Kian said:

Yes, I know that states can be updated from /assets/js/StatesDropdown.js but:

1. No one knows it

not strictly true. ☝️

1 hour ago, Kian said:

It gets overwritten with updates

never tried it, but what happens if you set the file permissions on the file so that it can't be overwritten - does the updater crash?

1 hour ago, Kian said:

If rules change and the js is not updated accordingly, the provider could receive fines up to 250 euro per invoice for reasons that I don't want to explain 😴

whoa! 😧

4. the file is full of errors anyway and has been for years - as mentioned many times previously, the GB list contains so many inaccuracies, it's beyond laughable... so the sooner it can be overridden, the better.

[Kian]

6 minutes ago, brian! said:

nobody has started a feature request for it

I'm not opening a feature request for the simple reason that italian-based companies need this change. I'll be fine with whatever WHMCS decide to do about it. If something bad happens I can show my customers this thread and hopefully they won't accuse me ❤️

19 minutes ago, brian! said:

not strictly true. ☝️  but what happens if you set the file permissions on the file so that it can't be overwritten - does the updater crash?

From my experience teaching Providers what to do would be useless for a number of reasons. On the other hand I don't want to update StatesDropdown.js and CHMOD on 500+ installations of WHMCS. I no longer want to be the sole responsible of billing mistakes especially when it's not even my fault. States overriding is the way to go... alternatively one can move to Canary Islands 💸

[zitu4life]

I will open a future request and link it to this thread. I understand that WHMCS could have lot of tasks related to their software, but would be easier if future requests could be filtered by a staff finding important futures FOR EVERY BODY, like this issue, and not forced us to remenber to replace those files on every update😴.

Hope community guideslines allow me to flag WHMCS staff @WHMCS John

We all know now that Future requests has own database, so just ensure when this future requests gets online developers will remember that this small improvement will save us time and headache.

[brian!]

15 hours ago, Kian said:

I no longer want to be the sole responsible of billing mistakes especially when it's not even my fault.

sadly, that's your role with WHMCS users - you can't resign from it and will have to accept the burden. 🙂

18 hours ago, Kian said:

I'm not opening a feature request for the simple reason that italian-based companies need this change.

as a short-term fix, at least in terms of the client area, have you considered using a clientareafooteroutput hook (limited to those pages that use states) to link to a custom statesdropdown.js file ?

it should override the default file and both the hook and custom js file should be unaffected by WHMCS updates - in the screenshot below, it's using the custom BrianStatesDropdown.js file and StatesDropdown.js is untouched (e.g VS is still there twice)...

sadly, I doubt such a simple solution would work in the handful of pages where states are used in the admin area dropdowns as they would continue to use the default file... maybe they're fixable, but you'd know more than me about that.

ultimately, there still needs to be a countries-type solution for states, but maybe this gives you an update-safe option for the client area.... perhaps your module(s) could be tweaked to use the custom .js file in some way...

15 hours ago, Kian said:

States overriding is the way to go...

that's been asked about since the country changes were made years ago.

4 hours ago, zitu4life said:

I will open a future request and link it to this thread.

also, post a link to the FR in this thread.

[AzeDK]

Please give the related feature request by zitu4life some love 🙂

https://requests.whmcs.com/topic/allow-stateregion-overrides