¿Qué consideraciones especiales se necesitan al diseñar bases de datos para mantener registros financieros?

Espero que esta pregunta no sea demasiado amplia. En el futuro, es posible que necesite agregar algunos sistemas de contabilidad y seguimiento financiero a algunas aplicaciones (principalmente aplicaciones basadas en la web, pero mis preguntas también se refieren a las aplicaciones de escritorio).

Ahora, crear un registro simple de transacciones financieras es teóricamente fácil. Una tabla de base de datos con algunas columnas podría hacer el trabajo. Incluso MS Access, Excel, o incluso un simple archivo de texto ASCII podría usarse para almacenar fechas de transacciones, ID de cuentas y montos en dólares. Sin embargo, creo que incluso una tabla SQL respaldada con frecuencia con integridad transaccional podría no ser lo suficientemente robusta para un seguimiento financiero serio.

Escucho términos como "contabilidad de doble entrada", y tengo la sensación de que la mayoría de las aplicaciones de seguimiento financiero (por ejemplo, Mint.com o GnuCash) tienen una estructura o proceso de datos mucho más complicado para asegurarse de que todo se suma perfectamente, exactamente como debería, y que nunca se pierden ni corrompen datos.

Mi pregunta es: al diseñar una aplicación para rastrear transacciones financieras, ¿qué consideraciones especiales de diseño deben hacerse? Parece que podría haber tantos problemas potenciales ... problemas con la precisión del redondeo, las comprobaciones de paridad, algún tipo de proceso de auditoría, copias de seguridad especiales, seguridad / cifrado, formas adicionales de proteger los datos en el caso de un bloqueo a mitad de la entrada de datos. ... Realmente no sé qué debería preguntar específicamente, pero tengo la sensación de que la industria de la programación tiene un conjunto de mejores prácticas de las que no sé nada. ¿Qué son?

Editar:

Parece que abrí una lata de gusanos más grande de lo que esperaba. Para aclarar, estoy pensando específicamente en dos tipos de aplicaciones:

1. Aplicaciones de tipo "Comprobar registro" como GnuCash o Quicken que mantienen un registro de las transacciones individuales para su propio uso.
2. Aplicaciones que rastrean la facturación / crédito / o "puntos" para proveedores y clientes que tratan con una empresa.

Probablemente no haré ninguna actividad bancaria directa (AFAIK) que tenga un montón de regulaciones gubernamentales relacionadas con las finanzas.

Obtendré muchas respuestas a esto, estoy seguro, muchas respuestas idealistas también, solo puedo responder desde mi experiencia con las finanzas y lo que realmente sucede.

Ya ha cubierto la mayoría de los problemas.

La precisión de redondeo tiende a no ser realmente un problema en mi experiencia. La mayoría de las grandes organizaciones financieras que no han crecido de la noche a la mañana (es decir, todo excepto los fondos de cobertura) tienen una amplia gama de aplicaciones heredadas que se dividen debido a varios combustibles. Tienden a no hacer precisión de redondeo consistentemente; generalmente un cierto error de ganancias y pérdidas simplemente se acepta para el redondeo. De hecho, muchas horas de trabajo se dedican a lugares donde he trabajado, donde los humanos son los mejores selectores de "sí que está lo suficientemente cerca" cuando se trata de igualar sumas exactas / esperadas. Recuerde, esta es una respuesta basada en la realidad, no en lo que debería suceder.

Cifrado: no confíes en él francamente. Almacene datos de identificación en un sistema separado física y lógicamente de los datos no identificados (es decir, código de cuenta en todas partes, datos personales separados).

En general, aunque se requieren copias de seguridad, las copias de seguridad fuera de línea rara vez se solicitan: las cosas han salido muy mal en ese momento. Generalmente se requieren copias de producción en caliente, sin embargo, esto dependerá de sus propias necesidades específicas. En la práctica general, tenemos una copia de producción in situ cálida de todos los sistemas Y un sitio de recuperación ante desastres con su propia producción y copias templadas. Las copias calientes tienden a estar unos minutos atrás en la replicación, etc.

La auditoría es la clave de todos los sistemas financieros en los que he trabajado. Tiene 2 requisitos fundamentales A) ¿Puede hacer un seguimiento de cada cambio realizado en los datos, por quién, cuándo y por qué? B) ¿Puede probar el estado histórico de sus datos? ¿Que no ha sido manipulado?

A) es necesario para los equipos de operaciones: su sistema se utilizará de 100 maneras que nunca esperó, y esta información es vital para la expansión, informes ad-hoc, razones legales y depuración.

B) Vea el caso AMEX vs. Vee Vinhnee, donde AMEX no pudo cobrar 40k debido a ellos, ya que no pudieron probar que sus registros no estaban inventados. La solución generalmente utilizada para esto es el sellado de tiempo confiable. Las grandes empresas financieras tienen bancos garantes que garantizan las transacciones y, por lo tanto, proporcionan inherentemente un sello de tiempo confiable. Hay proveedores comerciales para esto para otros ámbitos de la vida / escenarios.

Las consideraciones son en su mayoría legales . Si lo observa desde una perspectiva de seguridad / confiabilidad, una hoja de Excel puede no ser inherentemente menos segura que una hoja de papel en algún cajón. La integridad transaccional de Access puede ser mejor que la de un empleado que es interrumpido por una llamada.

Pero, para que sus clientes puedan usarlo, debe hacerlo de acuerdo con sus leyes locales. Algunas cosas que encontré (en Alemania)

• Formatos de documentos para el almacenamiento de material , porque hay leyes que las empresas deben conservar sus documentos durante 10 años. En 10 años, tal vez su programa ya no esté disponible. Por lo tanto, debe almacenar documentos de forma certificada por DIN / ISO (.pdf parece ser suficiente en Alemania)
• Los seguimientos de auditoría son a menudo necesarios, por ejemplo, puede que tenga que presentar diferentes versiones del mismo documento, con fechas de modificación.
• La ubicación del almacenamiento es importante , debido a la 'Datenschutz' (privacidad), que puede ser diferente en el país de almacenamiento. Esto hace que los servicios basados ​​en la nube sean un poco complicados.
• Algunos documentos deben almacenarse de forma no mutable . la forma exacta en que se logra esto parece depender en gran medida de la selección legalista (un documento es inmutable, un CD es mutable, un CD firmado por un trabajador no lo es)

Debe comunicarse definitivamente con un abogado, para obtener información específica, o al menos trabajar en estrecha colaboración con un cliente.

Los factores de confiabilidad se vuelven increíblemente importantes cuando se trata con el dinero de las personas. Si Twitter pierde un tweet, no es gran cosa; Si cobra la tarjeta de crédito de alguien pero pierde su pedido, alguien de su organización recibirá una queja de un cliente enojado. Entonces, dos cosas: 1. No desea que eso suceda en primer lugar, pero 2. eventualmente sucederá sin importar cuán cuidadoso sea, por lo que desea poner MUCHA energía en el tipo de mecanismos de registro y rastreo eso lo ayudará a regresar y encontrar la orden "perdida" y corregir la situación.

Lo peor es tener, por ejemplo, un cargo en la tarjeta de crédito, pero NO registrar en absoluto para qué sirve, a quién pertenece, etc.

Para asuntos financieros, realmente necesita pensar incluso en los escenarios aparentemente super improbables y planificar cómo manejarlos: "Cargamos la tarjeta de crédito, pero el servidor de la base de datos está inactivo antes de que podamos actualizar el registro correspondiente". OK, que pasa ahora? Anular la carga? ¿Registrar la transacción en un archivo para que un humano pueda arreglarlo más tarde? Ok, ¿qué pasa si el disco está lleno y no puedes escribir en el archivo? Etcétera etcétera.

[1] Utilice tablas de seguridad (no confunda con los usuarios internos de la base de datos) para los usuarios y para su aplicación. módulos, formularios, páginas web:

User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}

[2] No elimine registros en su aplicación. Utilice un campo de estado, tal vez entero, tal vez booleano o bit, que indique que el registro se considera "eliminado". Haz tu aplicación. muestra registros que no se eliminan (marcados como eliminados, por ese campo) y crea algunos formularios de casos especiales, donde se encuentra la aplicación. muestra los registros marcados como eliminados.

anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }

Esta característica se llama "eliminación virtual". La eliminación real se llama frecuentemente "eliminación física".

[3] Utilice los campos en todas las tablas relacionadas con el acceso, almacene el usuario (único) que creó el registro y el (último) usuario que cambió el registro, y la fecha y hora, si es posible, agregue el módulo o la opción donde estaba cada registro modificado:

AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }

[4] En algunos casos, los valores monetarios o monetarios pueden afectar los resultados, cuando se usan varios registros en detalle y, agregados en un solo valor, en un registro de encabezado.

La mayoría de las marcas de bases de datos admiten, en estos días, un campo de datos de moneda o dinero. Úsalo.

En algunas circunstancias especiales, algunas personas los almacenan en un valor flotante fijo que admite varios dígitos decimales ("decimal") o incluso como valores de cadena.

Esta técnica es una espada de doble filo. Si su aplicación requiere ese tipo de presición, busque en la web un tutorial sobre cómo implementarlo correctamente.

Salud. [no se olvide de dar una lata de atún abierta al gatito, o desatar un voto positivo]

Ha etiquetado su pregunta con, securitypero en su mayoría está hablando de consistencia y confiabilidad, por lo que trataré de responder esa parte de la ecuación:

• Utilice las transacciones de la base de datos para garantizar la integridad de las operaciones por lotes. El ejemplo más básico es una transferencia entre dos cuentas: una cuenta se deduce el monto y la otra se acredita. Utilice las transacciones para garantizar que nunca se realice una transferencia parcial (solo se cambia un lado).
• Para mayor precisión, use el DECIMALtipo en lugar de flotadores. Los cálculos son mucho más lentos, pero no debería sentirlo ya que la mayoría de los cálculos financieros son muy básicos.
• Utilice la replicación para el tiempo de actividad y las copias de seguridad para la copia de seguridad. También debe buscar instantáneas LVM para la recuperación

Algunas de las consideraciones que veo son que debe tener en cuenta los controles internos. Esto significa que todo el acceso para acciones contra tablas (Insertar / eliminar / actualizar) debe ser a través de procesos almacenados (y sin SQl dinámico) para que ninguna tabla permita derechos de escritura o eliminación directamente sobre la tabla a nadie, excepto a un administrador del sistema. También debe tener en cuenta los controles internos que no permiten a alguien crear una nueva empresa y luego cobrar artículos a esa empresa (una ruta para el fraude). Acciones como esa siempre requerirán la aprobación de personas en dos roles diferentes. Además, los controles no deben cortarse a menos que una persona ingrese datos y otra apruebe el gasto.

Todas las tablas deben tener disparadores que creen registros de auditoría. Está buscando prevenir el fraude y, si sucede, determinar exactamente quién tomó las medidas y cuándo.

En las aplicaciones financieras, está mucho más preocupado por muchos procesos de back-end que nunca son vistos por la interfaz de usuario. Su primera preocupación es evitar el fraude y, por lo tanto, muchos controles de los que nadie es consciente se realizan en el back-end.

No abordaría una aplicación financiera de ningún tipo sin leer los PCGA (en los EE. UU., Otros países tienen sus propios estándares de contabilidad) a fondo y tener un CPA como consultor, ya que las prácticas contables incorrectas pueden llevar a la cárcel. Este es un campo altamente técnico y alguien sin el conocimiento necesario no tiene por qué intentar crear software en esta área.

La contabilidad a menudo se trata de verificación. Mientras recuerdes esto y entiendas la relación entre cada entidad, es bastante difícil equivocarse.

Trataré de enumerar todos los controles que pueda, pero siempre perderé algunos, espero que sea suficiente para que pueda comenzar su propia excavación.

Débitos totales == Créditos totales, esto es cierto ya sea que esté hablando del conjunto COMPLETO de cuentas o solo de una transacción aislada. Si no coincide, se perdió al menos una publicación en alguna parte. Así es como se equilibra el Libro mayor.

Cuentas por cobrar (débitos netos a la cuenta de control) == Total facturado (suma total de todas las cantidades facturables) - Total recibido (suma total de todos los pagos recibidos). Este es un ejemplo de cómo los totales de la transacción en términos reales de documentos FÍSICOS y tangibles deben equilibrarse con el Libro mayor (doble entrada).

Saldo bancario (de acuerdo con su extracto bancario) == El total de su Libro mayor de esa cuenta + los cheques recibidos que no se depositan, los cheques emitidos que no están depositados. Este es un ejemplo de cómo las cuentas bancarias / en efectivo concuerdan con el General Libro mayor.

Como puede ver, cada transacción, sub libro mayor, incluso acciones, se vincula directamente con el Libro mayor.

Si está haciendo pruebas unitarias, es bastante fácil ejecutar pruebas que garanticen que estos saldos existan cada vez que inserte / actualice transacciones siempre que sepa qué verificar.

Por supuesto, hay más saldos para verificar / contar, pero debe obtener la esencia del trabajo requerido. Esencialmente, todo se equilibra con todo lo demás, ya sean documentos físicos, partidas del Libro mayor, extractos bancarios. Se supone que es un equilibrio perfecto, o en los casos en que eres flojo para lidiar con el redondeo, casi perfecto.

Cuantas más comprobaciones pueda realizar mientras lo está desarrollando, menores serán las probabilidades de que haga algo mal.

Por cierto, cuando se trata de redondeo, intente ir con decimales en lugar de flotadores, le ahorrará muchos dolores de cabeza en el futuro. :PAG