FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Ciertamente maeyanes y mamcx tienen razón.
No es necesario ser "crípticos" con los nombres de campos y demás, no estamos limitados a 8 caracteres de longitud Ejemplo ():
|
#2
|
||||
|
||||
Cuando se tiene razón se da y aqui como queda ahora la base de datos
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#3
|
||||
|
||||
Buenos otro aporte haber si gusta.
Yo no soy partidario de múltiples campos idénticos en una tabla, ya que complican el asunto y necesitas meter código de programación, tanto en aplicación como en BBDD, por lo que los siguientes campos los incluiría en otras entidades Una entidad nueva para estos campos, siendo cada uno de ellos un registro. De este modo no bloqueo la entidad principal cada vez que tenga que actualizar un contador. Solo se bloqueará el registro del contador que estés actualizando. Tercera, si añades un modulo nuevo que requiera de un contador, solo tienes que añadir un registro nuevo y no tendrás que andar modificando estructura de datos
Lo mismo que antes, incluso añadiría un segundo campo boolean que indicará la serie por defecto que quiero usar. Si solo hay un registro pos esa.
En esto también haría lo mismo, un registro por cada registro de LOPD
Impuesto y recargos de equivalencia también los llevaría a una entidad aparte y cada tipo impuesto quedando algo así:
PD: Me gustan mucho las tablas de BBDD
__________________
PepeLolo El hombre el único virus que mide más de unas cuantas micras |
#4
|
||||
|
||||
Bueno, puestos a opinar yo opino.
En vez de limitar a X series el programa debería de haber un fichero de series tanto de compra como de venta con sus contadores y formatos de impresos independiente. Es habitual que en las empresas si hacen una factura en mostrador tenga un formato pequeño por ejemplo y que las facturas de crédito tengan un formato grande, que puedan querer tener distintos tipos de formatos de albaranes, valorados, sin valorar, etc. Para eso yo crearía un fichero de series de venta en el que tendría un registro por cada una de las posibles series y que cada una de estas tuviera los impresos y contadores de los distintos tipos de documentos relacionados con las ventas, presupuestos, pedidos de clientes, etc. Por otro lado otro fichero de series de compra en el que estuvieran los contadores e impresos de pedidos a proveedores y compras. Por otro lado debería de haber algún sitio donde se marcaran las series por defecto genéricas y en el fichero de clientes y proveedores un campo para la serie por si se quiere forzar la compra o venta a una serie determinada dependiendo del cliente o proveedor. Adjunto un ejemplo de como lo tengo yo en mis programas. P.D: Imagino que sabes en el jardín que te has metido, esto se te puede hacer eterno y tanta gente opinando puede ser contraproducente. Saludos Edito: ¿Alguien me dice una web para subir imágenes que no de muchos problemas?
__________________
Be water my friend. Última edición por newtron fecha: 22-05-2013 a las 20:16:28. |
#5
|
||||
|
||||
Vamos por partes (que dijo Jack el destripador ), la idea es hacer un programa de ejemplo, se que podemos crear una tabla de impuestos i poner los que nos da la gana, lo mismo con las series y demás, pero tener en cuenta que la inmensa mayoría de personas suelen trabajar con una única empresa y de esta manera esta más centralizado, en cuanto ala L.O.P.D. debe estar en configuración ya que como comente, si vamos a emitir un a factura, albarán o pedido, elegimos el texto por defecto LDPD1, en cambio si es un presupuesto recibo, etc, podemos elegir el LDPD2 o el LPD·, e incluso en el primer caso si el cliente es de contado, genérico, etc se puede elegir el LDPD2-3 según los textos el orden en el que lo introducimos y los que nos dicte el gestor de Protección de Datos. En cambio si lo ponemos en una tabla independiente, es más fácil perder el control de estos datos.
Así que tener en cuenta que no espero crear un super programa, sólo uno de gestión aceptable y que sirva de ejemplo y que incluya más apartados que el común. De todas maneras con cuantas series soléis trabajar, y los numeradores son estáticos, sólo sirven para mantener el último número registrado y asir poder llevar el contador. Nada si tengo que cambiar cambio el programa pero como ha dicho Javier Cita:
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#6
|
||||
|
||||
Cita:
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#7
|
||||
|
||||
Cita:
|
#8
|
||||
|
||||
__________________
El malabarista. |
#9
|
||||
|
||||
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
llamar un programa desde otro programa en un computador con dos monitores | RONPABLO | Varios | 0 | 10-10-2011 18:20:51 |
Cargar tu programa desde otro programa | rmendoza83 | Varios | 7 | 05-01-2009 19:51:33 |
Lanzar programa desde mi programa | Pablo Carlos | API de Windows | 32 | 09-09-2004 13:56:26 |
Ejecutar un programa externo desde un programa de Delphi | Roger_Fernandez | Varios | 3 | 02-09-2004 18:05:36 |
ISC ERROR CODE:335544344 I/O error for file "c:\gestion\gestion.gdb" | eliasterrero | Firebird e Interbase | 2 | 28-06-2004 12:20:25 |
|