database design - management - Cambio de IVA del Reino Unido de 17.5 a 15%-¿Cómo afectará esto a su código?
gestion cmdb (9)
El sistema de IVA del Reino Unido está cambiando del 17.5% al 15%. ¿Qué estrategias usó en su código para almacenar el IVA y cómo afectará el cambio a sus aplicaciones? ¿Almacena un historial de tanques para que pueda calcular precios antiguos, o son facturas antiguas almacenadas en una tabla separada? ¿Es una configuración de configuración simple, o lo burlaste? ¿Cuál es la forma ideal de almacenar el IVA?
Anoche encontré una tabla en el código que almacena configuraciones de configuración importantes para la aplicación.
Table tbl_config
config_id int
config_name varchar(255)
config_value varchar(255)
Una de estas configuraciones era nuestra combinación principal de usuario y contraseña de administrador para el servidor (unhashed). ¡Supongo que el desarrollador que lo creó siempre quiso tener acceso a él en caso de que lo olvidara! No hace falta decir que ahora ha desaparecido.
Extraemos el IVA de una tabla de base de datos compartida por todas nuestras aplicaciones internas, lo que significa que no es un gran problema para nosotros en lo que respecta a nuestro nuevo código. Mantenerlo centralizado como este tiene que ser un movimiento inteligente.
Mis pensamientos ...
a- Generalmente prefiero calc sobre tienda, pero en este caso el IVA calculado (y la tasa y los códigos utilizados para calcular) deben almacenarse en cada transacción. Esto se debe a que serán los datos de origen de los documentos que deben generarse repetidamente. También desea poder hacer coincidir el importe del IVA de una venta con el importe del IVA en un libro contable financiero. No desea arriesgarse a la posibilidad de no poder generar de nuevo un documento como una factura o un informe de IVA de forma idéntica.
b- Los valores del IVA (u otros impuestos) deben almacenarse absolutamente en una tabla, con fechas y tarifas vigentes. Si está codificado, haga el trabajo ahora para codificarlo, porque es probable que cambie nuevamente en el futuro cercano.
c- Este es un trato enorme (y resuelto) en los EE. UU. porque el impuesto a las ventas varía entre estados, condados e incluso ciudades. Vivo y trabajo en el condado de Los Angeles, y la tasa del impuesto a las ventas es del 8.25%. 10 millas al sur, en el condado de Orange, la tasa de impuesto a las ventas es 7.75%. Los minoristas de Internet y de catálogos deben conocer la tarifa correcta, ¡porque está determinada por la ubicación de entrega!
Buena suerte.
Tenemos nuestros tipos de IVA almacenados en una tabla de base de datos, por lo que no es demasiado importante para nosotros, aunque tengo que levantar la mano y decir que debido a la naturaleza de algunas de las modificaciones que realizamos en el código, el IVA estaba codificado en un par de lugares (¡mi mal!) que he logrado volver a mezclar de otra manera más emocionante!
Tengo la desagradable sensación de que 2 de los sistemas que heredé tienen la frecuencia codificada en alguna parte.
Peor aún es que si está codificado, simplemente reemplazaré los valores codificados ya que no tengo tiempo para cambiarlo correctamente.
Incluso peor que eso, no sé de dónde sacaré el tiempo para realmente hacer el cambio. Entonces me imagino que no se hará a tiempo para el cambio del lunes. Por supuesto, hay cuestiones más interesantes, como que nuestra suscripción de £ 10 se basa en 10 £, incluido el 17,5% de IVA (£ 8,515 o lo que sea). Ahora será £ 9.79 más o menos, haciendo un desastre total de todo lo que lo anuncia en £ 10, y todos los cálculos del sitio basados en £ 10.
Todo esto porque el idiota a cargo de la hucha quería un titular.
No lo calcule ¡Guárdalo!
HMRC son muy quisquillosos acerca de que se les pague la cantidad correcta de IVA. El redondeo de los cálculos del IVA se especifica algo vagamente en las guías del usuario, y dejar que los futuros implementadores lo solucionen es, posiblemente, un problema. Al guardar el importe cuando se ingresa la factura / artículo de línea, se evita este problema.
Esto parece una pérdida de almacenamiento y una violación de los principios de redundancia, pero la cantidad de almacenamiento involucrado es pequeña y podría ahorrar muchos problemas en el futuro. Por supuesto, no hace falta decir que las cantidades de moneda (e incluso las tasas de IVA con una parte fraccionaria) se deben almacenar como un número entero multiplicado para evitar errores de redondeo de representación fraccional binaria.
Almacenamiento de velocidad central
Debería usar absolutamente el almacenamiento centralizado de tarifas. Sin embargo, recomendaría que esto solo proporcione las tasas predeterminadas actuales que se usan al ingresar nuevas facturas. Estos pueden almacenarse con fechas de inicio y finalización para dar cambio automático si es necesario. Estas tasas se pueden almacenar para cada factura (o línea de factura) junto con los importes de IVA calculados en el momento en que se genera la factura para proporcionar una instantánea absoluta de la situación en ese momento.
No olvide incluir también los diferentes tipos de IVA (p. Ej., Estándar, reducido, con calificación cero, sin IVA) y la posibilidad de comerciar con entidades registradas con IVA en otros países de la UE donde es posible que tenga que pagar una factura sin IVA. normalmente estarán sujetos al IVA.
Podrías terminar con una tabla como esta (ejemplo):
id | Rate name | VAT rate | Start date | End date --------------------------------------------------- 1 | Standard | 1750 | 01/01/1991 | 30/11/2008 2 | Standard | 1500 | 01/12/2008 | 31/12/2009 etc
La tabla anterior es solo un ejemplo. La tasa del IVA se almacena como un número entero de "puntos básicos" (por ejemplo, centésimas de punto porcentual), pero supone que la tasa del IVA nunca será superior a 2 decimales. Obviamente, podría ampliar esto con una columna adicional para aliviar este problema, ¡pero parece que es un paso demasiado lejos!
En cuanto a la tienda vs argumento calc. Si lo almacena, siempre puede calcularlo más adelante, si cambia de opinión;)
Solo estoy trabajando en algo para hacer esto cuando la tasa cambie.
De cualquier forma que lo haga, no es necesario registrar un inicio y una fecha de finalización en su tabla de IVA ya que los períodos de IVA se ejecutan directamente uno detrás del otro.
Puede acceder al depósito correcto haciendo una consulta como la siguiente, donde vat_date es la fecha de inicio para el tipo de IVA.
SELECT * FROM vat WHERE NOW() > vat_date ORDER BY vat_date DESC LIMIT 1
No lo guarde ¡Cálculo!
Mi forma recomendada de almacenar porcentajes / intereses basados en porcentajes es:
Debería tener una tabla ''VAT_param'' como
Tasa de interés | A partir de (fecha) | Efectivo hasta (fecha)
Creo,
" Cualquier cosa que se pueda calcular, no se debe guardar"
Especialmente en los casos en los que necesita calcular valores basados en el porcentaje de otros (como impuestos, intereses, etc.). No permita que el trade-off de Time-Space lo esquive. Te bendecirán más tarde por pasar el tiempo en el espacio.
Luego, el IVA debe calcularse cuidadosamente en función de la tasa efectiva durante el período, en función de la fecha de la Factura. Va a
Asegure una menor redundancia (por favor, nunca hable de tablas viejas o nuevas tablas ... en unos años comenzará a jalar su cabello si la tasa de interés cambia una vez al año)
Tener un solo pivote centralizado para controlar la velocidad. Su tabla VAT_param.