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

Question

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

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

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

Answer 1

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

Пример:

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

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

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

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

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

Answer 2

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

Answer 3

Вот пример города с «самоуправлением» в столичном регионе Денвера, штат Колорадо:

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

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

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