Por empezar, recordemos una frase que dijo el profesor de Análisis de Sistemas I e primer día de clase:
"Un mismo problema puede ser analizado por dos analistas diferentes, y arribar a soluciones completamente diferentes e incluso interexcluyentes, y aun así ser correctas ambas soluciones."
¿Que significa eso?
Que la solución que te puedo sugerir no es la única posible, sino la que YO considero mas adecuada, y bien puede ser que alguien tenga una visión diferente.
La mía parte de la experiencia que he tenido, luego de aprendizaje formal.
Por empezar, noto un abuso innecesario de la creación de claves primarias denomiandas "ID", cuando en realidad no sin necesarias, son redundantes, y ,pueden terminar complicando tus consultas por un inadecuado manejo de alias.
Mira, si tienes campos como DNI, NUMRECIBO, NUMFACTURA y cosas así
los campos "ID" son redundantes e innecesarios.
Si cada cliente tiene un único DNI, ese campo debería ser PK de la tabla. Sólo se requeriría la existencia de un campo diferente como PK si la entidad es identificada dentro de la empresa con un código de identificación particular o heredado, como podría ser un numero de cliente, por ejemplo. Y aún en ese caso es ese codigo el ID, no un campo inventado numérico y autoincremental.
Además, poner a todos "ID" es una mala práctica, que luego te causa problemas en las consultas. No bromeo.
En consecuencia, deberías normalizar mejor las PK, poniendo como tal los atributos unicos que existan en la entidad, como son los ya mencionados DNI, NUMRECIBO, NUMFACTURA, por ejemplo, y anteponiendole un prefijo a los ID que no se puedan evitar, como CATEGORIA_ID, PRODUCTO_ID, VENDEDOR_ID, y usar esos mismso nombres luego en las FK cuando apunten a esos campos.
Sería mas o menos esto:
Cita: CLIENTE(DNI, nombre, apellido, fnacimiento, dirección, teléfono, fax, IVA)
VENDEDOR(vendedor_id, nombre, apellido, teléfono)
CATEGORIA(categoria_id, nombre, detalle)
PRODUCTO(producto_id, categoria_id, nombre, stock, precio)
Respecto a Facturas y REcibos, por regla general, se requiere una tabla diferente cuando el documento a nivel contable es diferente, po rlo cual aunque Facturas y Tickets se usen para el mismo fin, ambos representan documentos de pago diferentes, que se deben analizar de forma diferente, reportar de forma diferente, y contienen datos distintivos (un ticker, po r ejemplo, implica la existencia de una impresora fiscal, y la factura no).
En consecuencia son tablas diferentes:
Cita: FACTURA(numfactura, femisión, DNI, idvendedor, metodopago)
DETALLE_FACTURA(numfactura, orden_item, producto_id, cantidad, descuento)
RECIBO(numrecibo, femision, vendedor_id, metodopago)
DETALLE_RECIBO(numrecibo, orden_item, productoid, cantidad, descuento)
Que te quede claro: Luego se necesitará analizar por separado ambas cosas, y además los ciclos de análisis y cierre son diferentes (una factura se puede analizar en forma independiente, un ticker requiere el cierre de caja usualmente). POr eso los pagos y sumas totales (que son calculables) no deben ir ni en el detalle, ni en la cabecera de los documentos.
Además, todo dato transitivo, como el precio, el nombre del producto, la categoría de IVA del cliente, se obtienen de los JOIN y no deben replicarse de tabla en tabla.
Luego, hay un detalle: El pago, la acción de pago es usualmente una acción diferente, y que se registra de forma independiente.
Una factura o un recibo son la certificación de una venta que genera una deuda del cliente, pero la emisión de una factura o recibo no implica el pago de caja. El pago es un evento contable separado, donde se ingresa el dinero en algún modo de pago en especial. Ese PAGO es una tabla separada, no solo por esto, sino porque además hay que tomar en cuenta si existen o no cuentas corrientes de los clientes. De haberlas, los pagos son únicos por periodos y pueden imputarse a mas de una factura... y el sistema tiene que tener la flexibilidad necesaria para darle soporte.
Suponiendo una única entidad para eso, no podríamos poner una FK, sino administrarlo programáticamente, para lo cual necesitamos conocer el tipo de documento que se paga, su numero, la fecha y el importe...
Algo como:
Cita: PAGOS(tipo_doc, nro_documento, fecha_pago, importepago, ... otros datos...)
Nota bene: Este bosquejo es puramente teórico y solo te serviría para un trabajo práctico. La realidad es MUCHO mas compleja. 
