Explaining the Dividers Gang Planning Page

History

Historically, we used a database table called "print order" to track finals through the production process.

1. order
2. gang
3. print
4. ship

In STARSTIX, sincd dividers were comprised of one or more finals, this meant that the print order was comprised of two main tables:

printorder

This table tracked the dividers to print: one row per store.

printorder_sides:

This table tracked the finals that belonged on each divider.

Because of the indirect relation of finals (reservations) to the printorder, updating and maintaining the printorder in light of changing reservations was a complex process prone to error and confusion. This made the print order unreliable at best. Eric handled this by manually comparing all of the items on it with all of the reservations every cycle - quite a bit of work.

ERPNext

In ERPNext, I opted to take a hybrid approach. We still needed the print order in order to order reprints and track shipping. However, rather than manage the print order programatically in the system, I took three steps to make it more reliable.

Simplify

Rather than track finals through the production process, only begin tracking once the divider's finals have been ganged. This is intended to eliminate the need to compare reservations with print order items, since the gangs are created directly from reservations.

Manage

Fully expose the print order in the system so that users could manage it. This is the Divider Print Order DocType.

De-automate

Since the Dividers Print Order is an ERPNext DocType, it is no longer necessary to manage reprints through a separate process. Instead, the user can use built-in funtionality to request reprints by simply creating a Dividers Print Order Document.