Sounds to me like one way to model this is to have a PARTS table, a DEPARTMENTS table, a TASKS table, a CUSTOMERS table, a SALESPERSONS table, and a PROCESS join table.
There would be a one-to-many relationship between PARTS and CUSTOMERS, since a part can only have one customer, but a customer can have many parts.
There would be a one-to-many relationship between PARTS and SALESPERSONS, since a part can only have one salesperson, but a salesperson can have many parts.
There would be a many-to-many relationship between PARTS and DEPARTMENTS, since a part can be in many departments, and a department can have many parts. You would need a join table like PROCESS to link between PARTS and DEPARTMENTS.
There would be a one-to-many relationship between PROCESS and TASKS, since each process can only have one task, but one task can have many processes.
You then add a record in the PROCESS table with a Date field indicated when the process starts/ends, and a Department linked field to select the department, and a Task linked field to select the task, and a Quantity field to indicate how many (as a positive number) of that particular part came into the department.
You then add a new record in the PROCESS table indicating in the Date field when the process ended, and in the Department linked field the part is leaving from, and in the Quantity field (as a negative number) to indicate how many of that particular part left the department.
You then add a new record in the PROCESS table indicating in the Date field when the process starts, and in the Department linked field the part is entering to, and the Task linked field what is the task, and the Quantity field (as a positive number) how many of the particular part entered the department.
In this way you can show the various transactions of the various processes or tasks going in and out of each department.
You can run views or reports on the PROCESS table filtered by the desired salesperson, part, department, task, etc. to get the reports you need, rolled up by Quantity to see how many of each part are in each task in each department, etc.
Sounds to me like one way to model this is to have a PARTS table, a DEPARTMENTS table, a TASKS table, a CUSTOMERS table, a SALESPERSONS table, and a PROCESS join table.
There would be a one-to-many relationship between PARTS and CUSTOMERS, since a part can only have one customer, but a customer can have many parts.
There would be a one-to-many relationship between PARTS and SALESPERSONS, since a part can only have one salesperson, but a salesperson can have many parts.
There would be a many-to-many relationship between PARTS and DEPARTMENTS, since a part can be in many departments, and a department can have many parts. You would need a join table like PROCESS to link between PARTS and DEPARTMENTS.
There would be a one-to-many relationship between PROCESS and TASKS, since each process can only have one task, but one task can have many processes.
You then add a record in the PROCESS table with a Date field indicated when the process starts/ends, and a Department linked field to select the department, and a Task linked field to select the task, and a Quantity field to indicate how many (as a positive number) of that particular part came into the department.
You then add a new record in the PROCESS table indicating in the Date field when the process ended, and in the Department linked field the part is leaving from, and in the Quantity field (as a negative number) to indicate how many of that particular part left the department.
You then add a new record in the PROCESS table indicating in the Date field when the process starts, and in the Department linked field the part is entering to, and the Task linked field what is the task, and the Quantity field (as a positive number) how many of the particular part entered the department.
In this way you can show the various transactions of the various processes or tasks going in and out of each department.
You can run views or reports on the PROCESS table filtered by the desired salesperson, part, department, task, etc. to get the reports you need, rolled up by Quantity to see how many of each part are in each task in each department, etc.
Thank you for the very detailed response.