Примеры налоговых двигателей

Question

Мы создаем программное обеспечение для Mac и собираемся обновить нашу налоговую систему. Теперь все довольно просто, с налогами, состоящими из имени, кода и ставки, которые могут применяться к каждому продукту в отдельности. Хотя для некоторых это достаточно, у нас было много запросов на более сложные ситуации. Примерами могут служить налог с продаж в городе / округе США, канадские сложные (сложенные) налоги, французский экотакс и налог на роскошь в Нью-Йорке.

Мы определили большинство характеристик, которые имеют эти налоги, и склоняются к своего рода реализации на основе правил. Нам не нужно поддерживать каждый случай, но мы хотим иметь возможность расширять его при необходимости (чтобы избежать повторной перезаписи).

Мы ищем советы от людей, которые создавали что-то подобное раньше, или примеры проектов, которые пытаются решить эту проблему элегантным способом.

Answer 1

Я бы предложил использовать таблицы базы данных для того, для чего они хороши (для хранения значений), и для правил, для которых они хороши (для бизнес-логики). Я, конечно, не стал бы включать в правила такие вещи, как налоговые ставки или списки юрисдикций - они должны быть в таблицах. Я бы использовал механизм правил для определения логики, определяющей, какая ставка применяется к каким транзакциям. Так, например, если я покупаю набор продуктов через Интернет у компании из государства X, которая отправляет из государства Y в три разных места, какие налоговые ставки применяются к каким частям транзакции? Эта комбинация правил и таблиц базы данных очень распространена - правила гарантируют, что вы ищете правильные вещи, в то время как таблицы помогают в составлении отчетов и т. Д. Например, Калифорнийский DMV сделал это с регистрационными сборами транспортных средств - все различные сборы хранятся в база данных, в то время как правила, которые определяют, какая плата применяется к какому автомобилю, управляются в базе данных. Если вы попытаетесь поместить все в правила, вы не сможете хорошо отчитаться, а если вы попытаетесь поместить все в таблицы базы данных, вы получите десятки таблиц для управления всеми исключениями и угловыми случаями. JT

Answer 2

Вот пример города "домашнего правления" в столичном регионе Денвер, CO:

http://www.c3gov.com/pages/about/division_salestax.html

Вам, как продавцу, может также потребоваться отправить налоговые платежи в разные места. Для городов, которые не являются городами с «домашним правлением» (это специальный термин, который, вероятно, относится только к Колорадо, но тогда, вероятно, в каждом штате есть такой же специальный термин, как он), вы отправите все налоговые платежи в штат, который будет затем раздайте их соответствующим сторонам. В Колорадо есть функция, в которой есть «специальные налоговые округа», которым разрешено собирать налоги с продаж для определенных льгот (на примере ссылки RTD - это район общественного транспорта, а «Invesco Field» - стадион, где играют в Денвер Бронкос).

Чтобы расширить ответ мистера Таллента в этой теме, вам также необходимо включить в таблицу юрисдикции способ представления того, что налоги могут идти в разные места.

Answer 3

Я бы порекомендовал набор таблиц базы данных и объединений.

Пример:

• Юрисдикция : список штатов, округов, стран, городов и т. Д.
• Продукт : очевидный
• Магазин : список мест, где вы продаете
• StoreJurisdiction (StoreID, JurisdictionID): список юрисдикций магазина ответственность за сбор налогов за
• ProductTaxCode (ProductID int, TaxCodeID int): тип продукта для целей налогообложения: базовый, роскошный и т. Д.
• JurisdictionTaxCodeRate (JurisdictionID, TaxCodeID, InterestRate, RateType): для каждой применимой комбинации юрисдикции и Налогового кодекса укажите применяемую ставку налога и тип ставки (составной, простой и т. Д.). ).

Чтобы найти список применяемых налогов, все, что вам нужно, - это ВНУТРЕННЕЕ СОЕДИНЕНИЕ магазина, его юрисдикций, юрисдикция с указанием кодов для этих юрисдикций и налоговых кодов продукта.

Вы можете определить ProductTaxCode как View, чтобы все продукты получали TaxCode по умолчанию, если только не указан специальный. Абстрагируя TaxCode, вы можете иметь одинаковые метаданные о продукте (например, «Продукты питания») для разных регионов. Если в конкретной юрисдикции есть свое собственное определение «еда», вы просто добавляете код для конкретной юрисдикции и применяете его к продуктам по мере необходимости.

Это может потребовать некоторой настройки для покупок через Интернет, оптовых покупок и других ситуаций, когда продажа каким-то образом освобождается от налогов или покупатель несет ответственность за их возврат. Также потребуется настройка для ситуаций, когда местоположение покупателя, а не магазина, определяет ставку налога.

Другие хитрости: например, здесь, в Техасе, у нас выходной день "без налогов", когда государственные и местные налоги не собираются на некоторых классах продуктов, где цена продажи отдельного элемента ниже $ 100. Идея состоит в том, чтобы предоставить детям, отправляющимся в школу на новый год, более дешевые школьные принадлежности, одежду и т.д. Этот вид настройки может быть реализован с помощью таблицы диапазонов дат для каждого JurisdictionTaxCodeRate, выходящего в будущем настолько далеко, насколько это может быть запланировано.