Diseñar correctamente una tabla (Recibo de pago)

[luffy_90]

Hola buen día :D, tengo esta tabla en donde expido un recibo de pago por productos vendidos.
Manejador: MySQL
Lenguaje de programación: PHP

Recibo
-----------------
IdRecibo (int)
IdProducto(int)
folio(int)
descuento(decimal)
total(double)
descripcion(text)
fecha(date)

Y ahora a este recibo también se puede agregar un servicio prestado, ademas de que se puedan agregar productos que no están registrados en la BD, lo que quiero saber es si de la siguiente manera sería correcto hacerlo, nose si este bien el enum o este de mas:

Recibo
-----------------
IdRecibo (int)
IdProducto(int) NULL
folio(int)
descuento(decimal)
total(double)
descripcion(text)
fecha(date)
IdServicio(int) NULL
tipo(enum 'PRODUCTO','SERVICIO','OTRO')

Muchas gracias...

[gnzsoloyo]

Un recibo, usualmente, es un comprobante de recepción de fondos, referido a una Factura. En ciertos países, incluso, un Recibo se usa sólo para la cobranza de servicios, y no productos.
Más alla de eso, cualquier documento que sea comprobante de pago de productos y servicios requiere una relacion maestro-detalle, es decir que deberías tener a menos dos tablas: CabeceraRecibo y Detalle_recibo. La primera con los datos generales de un documento de ese tipo, y la segunda con un registro por cada producto/servicio cobrado.
La emisión del comprobante físico es un tema de aplicación, no de BBDD, aunque puede existir una tabla de ComprobantesEmitidos, para guardar ese detalle.
Adicionalmente, para que el modelo del recibo funcione en el mudo real, es posible que necesites muchas tablas mas, en un esquema algo complejo. Sería el caso de incluir los Medios de Pago, Cuentas de Clientes, Clientes, Stock, Listados de Precios (si hay variaciones de precio en el tiempo), Productos, Servicios, y un largo etcétera.
El nivel de complejidad dependerá del modelo del sistema.

Sobre los tipos de campo que tu has elegido, hay dos errores graves:
1) Todo campo monetario debe sí o sí ser DECIMAL, al menos en MYSQL. En los demás debe usarse un tipo de campo que no sea de punto flotante, ya que ese tipo es por aproximación, y no de precisión. Para darte una idea, un FLOAT o DOUBLE podría hacer que un valor de 395,00 se almacenase como 394,999999998... con lo que pueden acumularse errores e inexactitudes contables.
2) Un campo de descripción NUNCA puede ser TEXT. Este tipo de campos no es indexable y además es innecesariamente lago para una descripción de producto, que muy rara vez requiere más de 500 caracteres.