How to design an item-tracking system that tracks different types of items throughout production lifecycle?

Question

This is a design question where I am trying to accommodate a business need.

I have two entities - Item and Job.

Original Situation

Item represents a line item on a ledger, and Job is created only for those Item objects that need it (i.e. a Job to track the line item going through the status change process as it went from one department to another - order, purchase, manufacture, ready to ship, shipped, etc). I have Job::status field to track the status changes.

Example:

1. Item "Toaster"
2. Item "Warranty on Toaster"
3. Item "Discount"

Normally a Job created would for item #1 only as that's the only one that needs to go through the manufacturing cycle. In that cycle it becomes visible to all the persons that are involved in manufacturing it. All other items were dealt with by memory and out-of-the-system, i.e. making notes and remebering to process them.

Job::status for item 1 goes through such status changes as ordered, reviewed, manufactured, shipped and is visible on an item tracker to all in manufacturing and shipping.

The Change

Now there is business need to track all the items, so that all of them can be "Processed". i.e. even though #2 does not need to be manufactured, someone still needs to prepare the warranty papers and make sure they get shipped.

This creates a problem, since with existing code, creating jobs for items #2 and #3, puts them into the manufacturing cycle. And machinists putting parts together on the shop floor will see those items, when they have nothing to do with Warranty or Discount. Without creating those jobs, someone else who needs to do work on those items (2, 3), will not see them in the item tracker.

Question

And here is my question - how do I design making a change to the existing code infrastructure to where there is a mechanism that takes care of tracking items through different cycles. This may mean reusing existing cycles, or creating new ones and gluing them together, or maybe something else.

Most likely I will end up modifying existing approach and/or building on top of it, to meet the business need.

What I have done so far

I've made a change where every single Item gets a job, even if its status chance cycle is different then one mentioned before. This helps non-manufacturing folks see and track the items in the internal job routing system, even if "Discount" goes through the 'manufacturing' and 'ordering' and 'shipped' phase. Also, all manufacturing folks see the Discount Item and have to push the job through on to the next cycle so it can be processed, even if they have nothing to do with it (they make toasters but not discounts).

Thought 1

If each Item gets a Job anyway, I might as well merge them together and extend their statuses to accommodate for different types of items. This may be convoluted, and I don't like this solution.

Thought 2

Alternatively I can move the status property from the Job into the Item, and then create different entities that track Item differently. i.e. Job for traditional Job cycle, such as item 1, and JobSomethingElse for a different class of Item such as items 2 and 3. This may not be very desirable as this involves extensive changes to existing infrastructure (all statuses belong to the Job entity at the moment), and shifting them into Item is considerable effort + debugging.

Overall I am not very clear on how to design or what to design to track each itme properly through its lifecycle in the business. Are there any patterns or designs that can help me here?

Answer 1

The canonical solution for these different processes for different items is to have a separate class for each kind of process.
Your existing Job would become an abstract class or interface, and you would get a hierarchy of Jobs like this

interface Job { ... }
class ManufacturingJob : implements Job { ... }
class PrintingJob : implements Job { ... }
class MiscellaneousJob : implements Job { ... }

The ManufacturingJob class represents the workflow for items that need to be manufactured (comparable to the existing Job). The PrintingJob class represents the workflow for items that only require some paperwork to be printed, like the warranty papers or the manuals. The MiscellaneousJob class is for those items that either don't require explicit processing or where the processing flow is so special that it can't be captured in your system.

In the manufacturing department, only the ManufacturingJobs would be visible and their associated items, while the PrintingJobs and associated items would only be visible to the department(s) dealing with printed materials.