Crear una factura sencilla!

[Raulitho]

Hola amigos del foro! Estoy solicitando su ayuda para crear facturas en mi BD sobre una refaccionaria, pero no tengo la idea de como hacerla, no se que otras tablas necesitare y como ir enlazando para que me de su importe y todo lo q contiene una factura.

[falegria230349]

Hola, aqui te dejo, como ejemplo, la estructura de una tabla para facturas. Espero te sirva de guía para empezar. Modifícala de acuerdo a tus necesidades. (las comillas dobles u otros son requeridos en mi lenguaje de programación)

cCmdSql:= "CREATE TABLE IF NOT EXISTS factura(" +;
"IDREG INT(10) NULL DEFAULT 0 COMMENT 'id registro'," +;
"VEND INT(3) NOT NULL DEFAULT '0' COMMENT 'Cod Vendedor'," +;
"VENDEDOR CHAR(30) NOT NULL DEFAULT '' COMMENT 'Nombre vendedor'," +;
"FECHA DATE NOT NULL COMMENT 'Fecha emision doc'," +;
"FACTU INT(10) DEFAULT '0' COMMENT 'Num factura'," +;
"TP CHAR(2) DEFAULT '' COMMENT 'tipo factura'," +;
"CODIGO INT(20) DEFAULT '0' COMMENT 'Cod Cliente'," +;
"CLIENTE CHAR(45) NOT NULL DEFAULT '' COMMENT 'Nombre cliente'," +;
"NUMPART CHAR(20) NOT NULL DEFAULT '' COMMENT 'codi producto'," +;
"DESCRIP CHAR(55) NOT NULL DEFAULT '' COMMENT 'descripcion'," +;
"CANTI NUMERIC(10,2) NOT NULL DEFAULT 0.00 COMMENT 'cantidad'," +;
"PVENTA NUMERIC(12,4) NOT NULL DEFAULT 0.0000 COMMENT 'precio vtau'," +;
"PVENTAT NUMERIC(15,2) NOT NULL DEFAULT 0.00 COMMENT 'precio vtatot'," +;
"PDESC NUMERIC(6,2) NOT NULL DEFAULT 0.00 COMMENT 'porc desct'," +;
"VDESC NUMERIC(15,2) NOT NULL DEFAULT 0.00 COMMENT 'monto desct'," +;
"GRAVABLE NUMERIC(15,2) NOT NULL DEFAULT 0.00 COMMENT 'monto gravable'," +;
"IVA NUMERIC(15,2) NOT NULL DEFAULT 0.00 COMMENT 'monto iva'," +;
"VALORFACT NUMERIC(15,2) NOT NULL DEFAULT 0.00 COMMENT 'valor facturado' " +;
"ENGINE = InnoDB COMMENT 'factura';"

Saludos.

[gnzsoloyo]

La tabla que propone @falegria230349 es incorrecta desde varios puntos (redundante, sin normalizar, almacena campos calculados, por ejemplo). No te aconsejo que la uses...

En cuanto a un ejemplo de una factura, es un case de manual o tutorial básico. Lo encontrarás en cualquier parte.
En esencia, son dos tablas básicas: La que contiene los datos de cabecera de la factura, y la que contiene el detalle de los artículos facturados.
- La primera debe contener: Numero de Factura, sucursal o punto de venta, fecha, Id del Cliente, forma de pago y descuentos aplicados.
- La segunda contiene el Numero de factura, ID del item facturado (numerados secuencialmente de 1 en 1), ID del producto, y la cantidad.

- No se incluyen datos de domicilio del cliente, porque esos datos provienen de la tabla de clientes.
- Se incluyen, si existen, datos del domicilio de entrega, si se requiere, pero esos datos deberían componer otra tabla, porque se trata de una situación opcional, y no constante.
- No se incluyen precios unitarios porque ese dato proviene de las tablas de stock y precios.
- Tampoco se incluyen subtotales porque se calculan al momento de la consulta y por tanto sólo ocupan espacio en disco.
- No se incluyen datos de los importes de impuestos aplicados, porque esos provienen de las tablas de cliente (condiciones impositivas), y de las e impuestos por condicion impositiva , y por tanto son campos calculables.
- No se incluye el total de la factura, porque es un dato calculable sobre la base de la consulta.
- Se incluyen descuentos aplicados, porque esos pueden ser aplicados manualmente, y no existe un estandar para eso.
- Si se aplican descuentos por diversos conceptos, estos conceptos deben estar en una tabla, y se debe crear otra tabla para relacionar la factura con los descuentos aplicados.
- No se incluyen datos de las cobranzas/pagos, porque una factura no implica un cobro. Son entidades y conceptos diferentes.

Hay muchas otras consideraciones posibles, pero esto te puede dar una idea.

Un esquema genérico de facturación y ordenes de pedido podría ser:

[falegria230349]

Bueno... los criterios aplicados a la tabla en mención, están basados en Contabilidad, Control Interno, Auditoría, y conservación histórica verás de las operaciones... además de no tener que liar con un sinnúmero de tablas (estilo Visual Fox), para una simple consulta.

Ejemplos clásicos: Los nombres de clientes, precios unitarios, entre otros, pueden ser modificados en sus tablas correspondientes y se pierde su historial, a menos que se guarden en la tabla en cuestión. En fín...

Saludos

[gnzsoloyo]

Los criterios aplicados pueden estar, cmo dices, basados en conceptos de contabilidad, pero no se los puede aplicar directamente al diseño de las bases de datos. El modelo E-R tiene ciertas reglas que deben cumplirse para conservar y asegurar la consistencia de datos, evitar la redundancia innecesaria y mantener la integridad referencia.
La historicidad de los precios no se adminisrta poniendo los precios unitarios dentro de la factura, eso es un error grarvísimo que lleva a la inconsistencia. Para resolver el problema de la evolución histórica de los precios se hacen los diseños de la estructura de stock que los soporte.
El hecho de hace pocas tablas, como pareces suponer, no implica hacer ni bases más rápidas, ni más eficientes, ni mejores performances. Muy posiblemente lo contrario. Se deben crear tantas tablas y relaciones como sea necesario para un sistema dado. Sin necesidad de usar VisualFox (como supones), una base de datos creada en SQL Server para administrar un supermercado, puede necesitar un diseño de más de 500 tablas... y eso ni siquiera es complicado.
Por otro lado, el planteo de las modificaciones de clientes, también se considera históricamente, pero si lo razonas, un cliente sólo puede cambiar de nombre por dos razones: 1) Se ingresó mal de entrada, con lo que la correccción debe también corregir las facturaciones ya realizadas., y 2) Porque la sociedad cambia de nombre de fantasía... pero el titular se mantiene. Cuando el titular cambia, entonces no es el mismo cliente y no corresponde "actualizaciones".
Creo que estás mirando el problema desde la optica del contador o del programador. No lo estás haciendo como analista, arquitecto de datos, o DBA .

[falegria230349]

gnzsoloyo:


Sobre la redundancia de datos, sé que debería, al menos, intentar evitar, pero es correcto utilizarla
de menera controlada para mejorar el rendimiento en las consultas (llamémosle en este caso, auditoría,
y no a la pérdida de mili-segundos en la consulta).

Si nos referimos de manera estricta al concepto "redundancia de datos", como tú lo haces, este existe,
y lo veremos siempre en dos, tres tablas (o muchísimas mas, según tu estilo), por ejemplo en códigos IDs
de productos, que son definitivamente necesarios. De modo que la redundancia, en muchos casos, es permitida.

Por otra parte, el uso de mayor espacio en disco sólo es notable en grandes sistemas que contienen bases
de datos enormes. (Una Web, por ejemplo). Para esto, en otros tipos de sistemas completos (Software Comercial),
existen procedimientos para guardar información histórica, limpiando sus tablas de manera conveniente,
en muchos casos cada año.

La integridad de datos, como lo has expuesto en varios posts, te refieres a la inserción de un dato type
mistmacht o incorrecto dentro de un campo, asi mismo, la integridad referencial te refieres al estado
relacional correcto entre las diferentes tablas de una base de datos.

Lo anterior está bien, pero la integridad de datos, en la vida real, va más allá: Es reflejar de manera
exacta cada una de las transacciones tal como se introdujeron. Es absolutamente prohibido modificar los datos
de una factura, un recibo de caja u otro documento oficial que involucre una transaccion monetaria. En estos
casos, se anula el documento y se emite nuevamente. Claro está, que me refiero a sistemas o Software serio
que emite estos documentos, y no a la grabación de documentos pre-procesados externamente que luego se
introducen al sistema. Mucho menos me refiero a las bases de datos que son manipuladas con SGBD.

Esto es sin ánimo de entrar en polémica, pero me da la impresión que tu experiencia en mayoritariamente
teórica y que no has tenido oportunidad para desarrollar software financiero como por ejemplo:
Contabilidad, Presupuesto, Micro-Financieras, Facturación (que incluye Ctas por Cobrar, Cuentas por Pagar,
Resultados, Stock), Inventario, Multi-Bodegas, Nóminas Standard, Nóminas Agrícolas, Nóminas Industriales, Puntos de venta.

Todos los softwares mencionados conllevan principios elemantales de Control Interno y respetan las leyes de mi país.

Saludos.

[gnzsoloyo]

Esto es sin ánimo de entrar en polémica, pero me da la impresión que tu experiencia en mayoritariamente teórica y que no has tenido oportunidad para desarrollar software financiero como por ejemplo: Contabilidad, Presupuesto, Micro-Financieras, Facturación (que incluye Ctas por Cobrar, Cuentas por Pagar, Resultados, Stock), Inventario, Multi-Bodegas, Nóminas Standard, Nóminas Agrícolas, Nóminas Industriales.

Me temo que estás completamente equivocado. Mi experiencia es práctica y se centra en aplicaciones multiplataforma, en tres DBMS distintos, en bases orientada tanto al análisis contable, datos espaciales (geolocalización y zonificación), logística y distribución de empresas de carga, transporte de pasajeros nacionales e internacionales, embarques, riesgos, nominas, perfomance de drivers, telefonía móvil, ventas minoristas de escala nacional y algunas cosillas adicionales que no vienen al caso, pero que me permitieron acceder a un espectro bastante amplio de experiencias.
De todos modos, intentar una descalificación, simplemente porque mi visión es distinta a la tuya, y mis experiencias de otros ordenes, no es ni cortés, ni un rasgo de buena educación y formación profesional.
En todo caso, ten en cuenta que (como nos decían los profesores de Análisis de Sistemas) dos analistas, estudiando el mismo sistema, pueden llegar a conclusiones totalmente distintas, contradictorias e interexcluyentes, y aún así ambas ser totalmente lógicas y verificables.
La experiencia, a través de los años pasados, me ha mostrado que tenían razón.

[Raulitho]

Estoy usando Mysql y PHP tengo las tablas de clientes,una de facturas,inventarios,proveedores,ventas y registro de ventas.
Alguien me puede dar un ejemplo en codigo de como hacerle??
que necesitan para poder ayudarme, para subirlo??

[gnzsoloyo]

¿Código PHP o código MySQL?
Lo que sea código PHP es tema del foro de PHP.
Respecto al uso del SQL embebido en el PHP, necesitaríamos una idea de la estructura de las tablas que tienes para poder darte una guia.

[Misido]

Me parece más racional la estructura que propone falegria230349, basicamente porque gnzsoloyo perdió la brújula al pretender que una persona que parte preguntando "crear una factura sencilla" deba entender la pulcritud de un DBA advanced para desarrollar quizás un simple programa, para un pequeño negocio que vende verduras en un pueblo. Creo que la calidad y eficiencia de un software se mide en la facilidad de uso o en qué tan cercano está del usuario, y que no importa tanto se si demoró 3 o 30 ms en encontrar un dato o si al almacenar gastó más o menos bytes del HDD, porque es más probable que cuando el HDD esté llegando a su maxima capacidad, los discos duros hayan bajado a 1/3 de su valor y hayan duplicado su capacidad.
Por último es probable que Raulitho se fue a otro foro a buscar ayuda porque nunca le contestaron lo que él preguntaba.
Saludos desde Santiago de Chile.