Pregunta

Creamos software punto de venta para el mac, y estamos buscando para renovar nuestro motor de impuestos. Es bastante simple ahora, con los impuestos que consisten en un nombre, código y tasa que puede ser aplicado a cada producto de forma individual. Si bien esto es suficiente para algunas personas buenas, hemos tenido un montón de peticiones para manejar situaciones más avanzadas. Algunos ejemplos son los impuestos de los EE.UU. City / Condado de ventas, compuestos de Canadá (apilados) impuestos, ecotasa francesa y el impuesto de lujo de Nueva York.

Hemos identificado la mayor parte de las características que tienen estos impuestos y se están inclinando hacia una especie de aplicación basado en normas-motor. No tenemos para apoyar todos los casos por ahí, pero queremos ser capaces de extender si es necesario (para evitar otra reescritura).

Estamos buscando el asesoramiento de personas que construyeron algo como esto antes, o ejemplos de proyectos que tratan de resolver el mismo de una manera elegante.

¿Fue útil?

Solución

Yo recomendaría un conjunto de tablas de base de datos y se une.

Ejemplo:

  • Competencia . Lista de estados, condados, países, ciudades, etc.
  • Producto : obvio
  • Tienda : lista de ubicaciones que venda del
  • StoreJurisdiction (StoreID, JurisdictionID): la lista de las jurisdicciones la tienda es responsable de recaudar impuestos para
  • ProductTaxCode (ProductID int, int TaxCodeID): el tipo de producto a efectos de impuestos:. Básica, de lujo, etc.
  • JurisdictionTaxCodeRate (JurisdictionID, TaxCodeID, InterestRate, RateType): para cada combinación aplicable de jurisdicción y Código Tributario, proporcionar la tasa de impuestos que debe aplicarse, y el tipo de tasa (compuesto, simple, etc .).

Para encontrar la lista de los impuestos a aplicar, todo lo que necesita es un combinación interna de la tienda, sus jurisdicciones, los jurisdictiontaxcoderates para esas jurisdicciones, y códigos de impuestos del producto.

Se podría definir como un ProductTaxCode Ver todos los productos por lo que reciben un TaxCode por defecto a menos que haya una especial. Al abstraer TaxCode, puede tener los mismos metadatos acerca de un producto ( "Alimentación", por ejemplo) se aplican a diferentes regiones de diferentes maneras. Si una jurisdicción en particular tiene su propia definición de "alimento", que acaba de añadir un código de jurisdicción específica y aplicarla a los productos según sea necesario.

Esto puede requerir algunos ajustes para compras por Internet, compras al por mayor, y otras situaciones donde la venta es de alguna manera exentos de impuestos o el cliente es responsable de remitir ellos. También sería necesario ajustar para situaciones en las instalaciones del cliente, en lugar de la tienda, decide el tipo de gravamen.

Otros ajustes: aquí en Texas, por ejemplo, que tienen un fin de semana "libre de impuestos", donde los impuestos estatales y locales no se recogen en algunos clases de productos en los que el precio de venta del artículo individual es menor de $ 100. La idea es proporcionar útiles escolares más baratos, ropa, etc. para los niños de ir a la escuela para un nuevo año. Esta especie de pellizco podría ser implementado por tener una tabla de rango de fechas para cada JurisdictionTaxCodeRate de apagarse en el futuro por lo que pueden ser planificadas.

Otros consejos

Mi sugerencia sería el uso de tablas de la base de lo que son buenas para y reglas (valores de almacenamiento) por lo que son buenos para (lógica de negocio). Sin duda, no pongo cosas como las tasas de impuestos o listas de jurisdicciones en las reglas - los que debe haber en las tablas. Lo que me gustaría utilizar un motor de reglas para definir la lógica es la que determina la tasa que se aplica a cuáles transacciones. Así, por ejemplo, si compro un conjunto de productos en línea de una empresa con sede en el Estado X que los buques de Estado Y a tres lugares diferentes, lo que las tasas de impuestos se aplican a qué partes de la transacción? Esta combinación de reglas y tablas de bases de datos es muy común - las reglas hacen que te mira las cosas correctas, mientras que la ayuda de las tablas de informes, etc. Por ejemplo, el DMV de California hizo con los derechos de inscripción de vehículos - todos los diferentes impuestos se almacenan en una base de datos, mientras que las reglas que determinan qué tarifa se aplica a qué coche se manejen de una base de reglas. Si tratas de poner todo en reglas que no será capaz de informar bien y si usted trata de poner todo en tablas de la base que va a terminar con docenas de mesas para manejar todas las excepciones y casos de esquina. JT

Este es un ejemplo de una ciudad "home rule" en el área de Denver, CO metropolitana:

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

, como minorista, puede que también tenga que enviar los pagos de impuestos a diferentes lugares. Para las ciudades que no son ciudades "home rule" (que es un término especial que probablemente sólo se aplica a Colorado, pero entonces probablemente cada estado tiene un término igualmente especial como él), se le envía todos los pagos de impuestos al estado que lo haga a continuación, tratar a cabo a las partes pertinentes. Colorado tiene una característica que no son "distritos de impuestos especiales" que están permitidos para recaudar impuestos de ventas para ciertos beneficios (en el ejemplo de enlace, RTD es el distrito de transporte público, y "Estadio" es el estadio donde los Denver Broncos jugar).

Para ampliar la respuesta del Sr. Tallent en este hilo, tendrá que incluir también en la tabla jurisdicción alguna manera de representar que los impuestos pueden ir a diferentes lugares.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top