Exemplos de motor de imposto

Question

Criamos o software de ponto de venda para o Mac e pretendemos reformular nosso motor de imposto. Agora é bem simples, com impostos que consistem em um nome, código e taxa que podem ser aplicados a todos os produtos individualmente. Embora isso seja bom o suficiente para algumas pessoas, tivemos muitos pedidos para lidar com situações mais avançadas. Alguns exemplos são impostos sobre vendas da cidade/condado dos EUA, impostos compostos canadenses (empilhados), imposto de luxo em EcoTax e Nova York.

Identificamos a maioria das características que esses impostos têm e estamos inclinados para uma espécie de implementação baseada em regras. Não precisamos apoiar todos os casos por aí, mas queremos ser capazes de estendê -lo, se necessário (para evitar outra reescrita).

Estamos procurando conselhos de pessoas que construíram algo assim antes, ou exemplos de projetos que tentam resolver o mesmo de maneira elegante.

Answer 1

Eu recomendaria um conjunto de tabelas de banco de dados e ingressos.

Exemplo:

• Jurisdição: Lista de estados, condados, países, cidades, etc.
• produtos: óbvio
• Armazenar: Lista de locais que você vende
• StoreJurisdiction(Storeid, JurisdictionID): A lista de jurisdições que a loja é responsável por coletar impostos para
• ProductTaxCode(ProductId Int, TaxCodeId Int): O tipo de produto para fins de impostos: básico, luxo, etc.
• JurisdictionTaxCoderate(JurisdictionID, TaxCodeId, interesse juros, RateType): Para cada combinação aplicável de jurisdição e código tributário, forneça a taxa de imposto a ser aplicada e o tipo de taxa (composto, simples etc.).

Para encontrar a lista de impostos para aplicar, tudo o que você precisa é um JUNÇÃO INTERNA da loja, suas jurisdições, a jurisdictionTaxCoderates para essas jurisdições e os códigos tributários do produto.

Você pode definir o ProductTaxCode como uma visualização para que todos os produtos recebam um código de taxa padrão, a menos que seja fornecido um especial. Ao abstrair o Código de Tax, você pode ter os mesmos metadados sobre um produto ("alimento", por exemplo), se aplicar a diferentes regiões de diferentes maneiras. Se uma jurisdição específica tiver sua própria definição de "comida", basta adicionar um código específico da jurisdição e aplicá-lo aos produtos conforme necessário.

Isso pode exigir alguns ajustes para compras na Internet, compras por atacado e outras situações em que a venda está de alguma forma isenta de impostos ou o cliente é responsável por remitei -las. Também precisaria de ajustes para situações em que a localização do cliente, e não a loja, decide a taxa de imposto.

Outros ajustes: aqui no Texas, por exemplo, temos um fim de semana "isento de impostos", onde os impostos estaduais e locais não são coletados em algum Classes de produtos onde o preço de venda do item individual é inferior a US $ 100. A idéia é fornecer material escolar mais barato, roupas etc. para crianças que vão para a escola para um ano novo. Esse tipo de ajuste pode ser implementado com uma tabela de intervalo para cada jurisdictionTaxCoderate, que se aproxima no futuro, tanto quanto eles podem ser planejados.

Answer 2

Minha sugestão seria usar tabelas de banco de dados para o que elas são boas (armazenando valores) e regras para o que são boas (lógica de negócios). Eu certamente não colocaria coisas como taxas de imposto ou listas de jurisdições nas regras - elas devem estar em tabelas. O que eu usaria um mecanismo de regras é definir a lógica que determina qual taxa aplicar a quais transações. Por exemplo, se eu comprar um conjunto de produtos on -line de uma empresa com sede no estado X que é enviada do estado Y para três locais diferentes, quais taxas de imposto se aplicam a quais partes da transação? Essa combinação de regras e tabelas de banco de dados é muito comum - as regras certifique -se de procurar as coisas certas enquanto as tabelas ajudam a relatar etc. Por exemplo, o DMV da Califórnia fez isso com taxas de registro de veículos - todas as várias taxas são armazenadas em um Banco de dados enquanto as regras que determinam qual taxa se aplica a qual carro é gerenciado em uma base de regras. Se você tentar colocar tudo nas regras, não poderá relatar bem e se tentar colocar tudo nas tabelas de banco de dados, acabará com dezenas de tabelas para gerenciar todas as exceções e casos de esquina. Jt

Answer 3

Aqui está um exemplo de uma cidade de "regra da casa" na área metropolitana de Denver, Co:

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

Você, como varejista, também pode precisar enviar os pagamentos de impostos para diferentes locais. Para cidades que não são cidades de "regra de origem" (que é um termo especial que provavelmente se aplica apenas ao Colorado, mas provavelmente todo estado tem algum termo igualmente especial como esse), você enviará todos os pagamentos de impostos ao Estado que irão Em seguida, lide -os para as partes relevantes. O Colorado possui um recurso em que existem "distritos tributários especiais" que podem coletar impostos sobre vendas para certos benefícios (no link de exemplo, a RTD é o distrito de transporte público e "Invesco Field" é o estádio onde o Denver Broncos toca).

Para expandir a resposta de Tallent neste tópico, você também precisará incluir na mesa de jurisdição uma maneira de representar que os impostos podem ir a lugares diferentes.