OK. Expresemos entonces la información como reglas de negocio básicas:
Cita: - La producción de una empresa se registra por medio de Planillas.
- Cada planilla se relaciona con la produccion en Kg. (pertenecen a una empresa que denominaremos "Productor").
- La producción se envía a otra empresa (la denominaremos "Procesador"), que la procesa, que devuelve información de los kilos que recibe en cada envío (asumo que un ticket es un envio).
- Cada planilla se completa con un envío de 20 Kg en total, repartidos en tickets de hasta 5 Kg cada uno.
- El peso total se redondea, dado que el pesaje puede variar dependiendo del dispositivo usado (no queda claro el margen de variación o si es relevante).
- Parte indeterminada de producción procesada por la segunda empresa se relaciona con tickets, pero estos no se asocian a planillas, sino que representan reportes de produccion directa.
Bueno, en principio, hay más de una forma de modelar un esquema de BBDD consistente.
1) Puedes forzar la creacion de una planilla general, de modo de mantener consistente la relación entre planillas y tickets. Habría que analizar qué condiciones se deben cumplir por dependencias en las planillas para posibilitar la creacion de ésta. Si la planilla tiene relacion con un cliente (productor) registrado en otra tabla, posiblemente esto se pued hacer con un cliente genérico.
2) Puedes modelar a la inversa, es decir relacionar los tickets directamente a Productor y Procesador, y crear una tabla Planilla que se relacione con estos tickets si se corresponden a una. El problema es que requeriría crear una tercera tabla que relacione ambas cosas, por ejemplo Ticket_Planilla
3) Puedes modelar la relación como una generalización, donde una tabla Procesador herede a Planilla y a otra entidad que podemos llamar ProcesadosPorTicket, de donde colgarían los tickets, por ejemplo. Eso posiblemente requiera cambios grandes en el diseño del sistema, y consultas mas elaboradas, aunque también agregaría trazabilidad.
Estas son tres ideas al vuelo. Puede que haya muchas mas soluciones.
Personalmente me decantaría por la primera: Forzar la creación de una Planilla y asociarla a los tickets, cumpliendo con las restricciones que posea la planilla en otras tablas con el uso de entidades genéricas (clientes genéricos, responsables genéricos, etc), que me permitan dar el alta del registro de la planilla sin romper la integridad referencial.
Lo que te debe quedar en claro en esto es que tu, como analista funcional, tienes que proponer una solución, cuando lo que el cliente/usuario te aporta no alcanza para construir una con lo que ya existe.
Queda en ti plantearlo de forma convincente y que lo acepten.