Rewrite of the simple tax plugin: questions about account countries?

[Benjamin Gandon]

Hi Pierre & Stéphane,

The simple tax plugin was too simple :-)

I could not send to production this “single tax rate” that would apply to every taxable items.

So, inspired by the concept of "tax code" I saw in the avatax plugin, I rewrote the simple tax plugin to implement tax codes.

I documented the result and just finished covering it with tests (≈95.3%).

The plugin now allows to setup various tax rates with cutoff dates.

Regulation-specific rules can be adapted with custom implementations of the TaxResolver interface.

The idempotent nature of the plugin is now driven by the tax codes set on invoice items custom fields.

Upcoming in my TODOs, I'll allow tax codes to apply to specific countries only.

With this in mind, I wonder how countries are stored in Kill Bill accounts, and how they are validated and used.

A first test on the createAccount endpoint shows that an account country can be quite anything.

What is usually stored there? Two letters country codes (ISO 3166-1 alpha-2)? Three letters country codes (ISO 3166-1 alpha-3)?

Do you have any thought about how I could enforce mandatory and consistent data in there,

so that the simple tax plugin can always know the applicable country for an account?

Do you recommend using a custom field instead for storing the tax-related country information?

Next, I'll also need to store the VATINs for accounts.

Indeed, my foreign customers won't get taxed with the French system, but I need their VAT number appear on their invoices.

Do you think custom fields are the right approach to store those VAT numbers?

Cheers

[Pierre-Alexandre Meyer]

On Thu, Oct 29, 2015 at 10:00 AM, Benjamin Gandon <benj...@gandon.org> wrote:

With this in mind, I wonder how countries are stored in Kill Bill accounts, and how they are validated and used.

A first test on the createAccount endpoint shows that an account country can be quite anything.

What is usually stored there? Two letters country codes (ISO 3166-1 alpha-2)? Three letters country codes (ISO 3166-1 alpha-3)?

Good question. Looking at the code, we indeed don't enforce any specific format today, so it's up to the user in practice to be consistent. Personally, we always use the two letters format.

Do you have any thought about how I could enforce mandatory and consistent data in there,

so that the simple tax plugin can always know the applicable country for an account?

The easiest way would be to enforce it at the database level (e.g. set the field to a char(2) or char(3)). Otherwise, besides a code change in killbill-account, I don't think there is a way around it.

Will you own the client(s) talking to your Kill Bill instance? If so, can you do client-side checks?

Next, I'll also need to store the VATINs for accounts.

Indeed, my foreign customers won't get taxed with the French system, but I need their VAT number appear on their invoices.

Do you think custom fields are the right approach to store those VAT numbers?

Yes, that's a perfect place for them. Alternatively, if your plugin already has a DAO layer, you could store them in a plugin specific table.

--

Pierre