Programa de gestión desde 0
Hola compañeros mi idea es montar un programa de gestión desde 0, por supuesto animo a los compañeros a corregirme, aportar y a criticar, sugerir etc. En primer lugar decir que no creo que yo sea el más adecuado para crear un programa desde 0 pero, como empiezo uno nuevo he dicho por que no, lo voy haciendo y lo publico.
He de decir que lo haré a ratos y mientras pueda y tenga disponibilidad y siempre que los miembros del club estén de acuerdo con la idea. Intentare ser los más especifico posible y explicar todo claramente, espero perdonéis mis faltas de ortografía. Por que hacer otro programa de gestión, por que por lo que veo, falta muchas cosas en los programas de gestión que se suelen hacer, ejemplos ADR, LOPD, REQ términos que ya iré especificando y que son muy muy sencillos de llevar al programa:rolleyes: Por supuesto como lo hago con mi sistema, pondré que componentes uso, el código completo del modulo y una imagen del mismo, usaré los estándar de Delphi y los míos propios, lo haré con firbird y Delphi 2010 e Ibexpert edición personal, si hubiese otros programas ya os iria diciendo. Doy por hecho que sabéis, usarlos y por lo tanto crear la base de datos, tablas, dominios, formularios, aplicaciones, etc. Aquí pongo una imagen de los dominios usados Pues bien comenzamos creando la B.D. en mi caso la llamo PGF2 (Programa de Gestión y Fabricación) y creamos la tabla Confi (Configuración), a cada campo le e antepuesto la X para cuando estemos haciendo consultas sepamos si es de la configuración o de la tabla que sea oportuna. Aquí os pongo la estructura de la tabla:
Ahora iré detallando los campos
Espero que estén de acuerdo con este proyecto, que exista bastante colaboración, que aporten ideas, código e imágenes, para poder mejorar nuestros programas. Por cierto lo lógico sería seguir con este hilo para ir poniendo las diferentes partes del mismo. El siguiente el módulo de configuración |
Se que dije que pondría primero el módulo de configuración, pero primero tengo que poner el módulo de datos (Data Module) en mi caso el nombre de la Unidad es UDM
Aquí una imagen Aquí el código
Como podemos ver tenemos en el evento IBDatabase1BeforeConnect el buscar la base de datos donde esta el ejecutable o en su defecto dentro de la carpeta bd\ que debe estar donde este el ejecutable, con lo que podemos usar el programa desde un pendrive por ejemplo (teóricamente) |
Por ahora solo una cuestión. (no pondría campos Blob de tipo texto) los dejaría solo para el subtipo binary.
Varchar soporta desde 1 to 32,765 bytes |
Cita:
Por cierto, creo que el dominio T10 debería ser varchar(10) En cuanto a campos memo "grandes" yo uso también blob de texto. |
Hola PepeLolo, suelo usar campos memos muy a menudo y no creas que me han crecido mucho las bases de datos, de todas maneras, mi idea es ponerlos en una tabla independiente con llamadas al módulo.
Hola Casimiro Notevi, cierto en el Dominio tendría que ser un varchar 10 pero esta a 20 gracias. |
Hola...
Aquí metiendo mi cuchara... :p Yo te recomendaría usar UTF8 en el chartset y UNICODE_CI_AI en el collation, esto si usas Firebird 2.5. Esto por que en Delphi 2010 los tipos string ahora son Unicode. Saludos... |
Gracias maeyanes, pero uso firebird 2. algo pero no es 2.5
|
Muy buena la idea.
Cita:
He hecho integraciones a decenas de ERPs, y no sabes lo complicado que es porque los nombres son obtusos y poco claros. Las abreviaciones y las construcciones tipo "XXXAAAYYTT" no solo obscurecen sino que son innecesarias, no ganan nada en cuanto a desempeño, almacenamiento ni nada por el estilo. El el sistema que tengo, uso asi (estoy estandarizado a hacer todo en ingles):
No tengo que documentar que significa los campos (los comentarios no deben usarse para saber lo que el codigo te puede decir) sino para decir que valores se esperan (que realmente es lo necesario). Ya que los nombres son claros, cuando construyo la interfaz de usuario, puedo hacer gracias como:
Osea, puedo reusar los nombres como etiquetas. Puedo mostrar la tabla a clientes, sin mucho lio. Puedo hacer consultas SIN MIRAR DOCUMENTACION, solo mirando tablas y nombres de campos. ----- Y aproposito, que piensas hacer con esto? Un proyecto open source? Si es asi, considera montarlo en github o bitbucket... |
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 ():
|
Cuando se tiene razón se da y aqui como queda ahora la base de datos
|
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 :D de BBDD |
Vamos por partes (que dijo Jack el destripador :D:D), 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:
|
Cita:
|
Cita:
|
Cita:
1 Terabyte. |
Cita:
Es que con un giga a mi me sobra :) |
Cita:
Si la cosa prospera, creo que podemos organizarlo mejor, pero esperemos a ver cómo se desarrolla el proyecto. ^\||/ |
|
Aquí la 1º parte del código del archivo pas 682 lineas
|
La franja horaria es GMT +2. Ahora son las 02:59:09. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi