Scenario
"It's approaching the end of the year and you will soon be receiving an order from one of your large corporate customers for 1000 desk calendars. Before printing all 1000 calendars, you would like to ensure the output is exactly how it should be prior to submitting the entire job to press and possibly wasting a significant amount of time and materials. By implementing proofs within your Infinity workflow you will be able to submit a single proof to press in order to validate the output is correct before submitting the entire job."
Solution overview
Generating a proof involves cloning an existing order in the system and setting the quantity of that order to 1, leaving the original order intact with its initial quantity. A proof of an order can be generated from the products tab, or you can identify an order as "Proof Required" which will place the order in a special sort group to let the operator know that a proof is required. When you mark an order as Proof Needed, two new attributes will show up for the order called Proof, with a value of yes or no which simply indicates if an order is a proof or not, and Proof Sent Time stamp, which indicates when the proof was generated. To better keep track of orders requiring a proof, we will also configure the system to assign a unique color to the proof sort group to reinforce that it is a special order.
Prerequisites
Infinity software version 10.1 or later
High level steps
- Configuring the environment
- Creating the decorator and matcher to update sort group color for proofs
- Generating a proof order from the products tab
- Marking orders as requires proof
Configuring the environment
To enable the proof functionality and have all of the information necessary to successfully manage proofs within the UI, the following steps must be completed.
- Browse to the <serverName>\idf\sharedconfig\workflow\workflowdef on the master core host (DB) server
- Verify the file IDFOrderProof.workflowdef.xml exists at this location
- If the file doesn't exist, create a new text file with this name, exactly how it is shown above, matching case
- Past in the XML shown below in to this file and close/save the file
- Once the file has been saved, you will need to restart all distributed core (DCore) services within the environment
<workflow> <transitions> <transition from="start" onSuccessTo="Order Inject" onErrorTo="error" /> <!-- <transition from="IDFOrderInject" onSuccessTo="IDFOrderAnalyze" onErrorTo="error" /> <transition from="IDFOrderAnalyze" onSuccessTo="IDFOrderSort" onErrorTo="error" /> --> <transition from="Order Inject" onSuccessTo="Order Analyze" onErrorTo="Order Inject Error" /> <transition from="Order Analyze" onSuccessTo="Order Prebatch" onErrorTo="Order Analyze Error" /> <transition from="Order Prebatch" onSuccessTo="Order Sort" onErrorTo="Order Prebatch Error" /> <transition from="Order Sort" onSuccessTo="Order Proof Batch" onErrorTo="Order Sort Error" /> <transition from="Order Proof Batch" onSuccessTo="Order Proofed" onErrorTo="Order Proof Batch Error" /> <!-- A single step workflow for order late prebatch. On success state is important, because the batch step will be looking for this state name --> <transition from="Order Late Prebatch Prep" onSuccessTo="Order Late Prebatch" onErrorTo="Order Late Prebatch Error" /> <transition from="Order Late Prebatch" onSuccessTo="Order Late Prebatch Complete" onErrorTo="Order Late Prebatch Error" /> </transitions> <queues> <queue id="Order Inject" start="true" /> <queue id="Order Late Prebatch Prep" start="true" /> <queue id="Order Sort" workerclass="com.infdig.framework.idfordersort.subsystem.OrderSortQueueCallbackWorker" /> <queue id="Order Analyze" workerclass="com.infdig.framework.prebatchsubsystem.AnalyzeOrderQueueCallbackWorker" /> <queue id="Order Prebatch" workerclass="com.infdig.framework.prebatchsubsystem.EarlyPrebatchQueueCallbackWorker" /> <queue id="Order Late Prebatch" workerclass="com.infdig.framework.prebatchsubsystem.LatePrebatchQueueCallbackWorker" /> <queue id="Order Proof Batch" workerclass="com.infdig.framework.prebatchsubsystem.OrderProofBatchQueueCallbackWorker" /> <queue id="Order Proofed" end="true" /> <queue id="Order Late Prebatch Complete" end="true" /> <queue id="Order Workflow Complete" end="true" /> <queue id="Order Inject Error" error="true" /> <queue id="Order Analyze Error" error="true" /> <queue id="Order Sort Error" error="true" /> <queue id="Order Prebatch Error" error="true" /> <queue id="Order Late Prebatch Error" error="true" /> <queue id="Order Batch Error" error="true" /> </queues> </workflow>
- Update the autobatch.config.xml file located in the sharedconfig location to include the proof batch range to be used. The actual batch ID range can be the same as the current batch ID range since we will append the word PROOF in front of the batch ID. An example that can be copied in to your autobatch.config.xml file is shown below.
<proofBatchIDFormatString>PROOF-%06d</proofBatchIDFormatString> <proofBatchIDAttributes>generatedBatchId</proofBatchIDAttributes> <proofHighBatchNumber>999999</proofHighBatchNumber> <proofLowBatchNumber>100000</proofLowBatchNumber>
Creating the decorator and matcher to update sort group color for proofs
- Browse to the <serverName>\idf\sharedconfig\ordersort\matcher on the master core host (DB) server
- Create a new text file in this location called ProofNeeded.matcher.xml
- Copy the contents shown below to your xml file created above and save/close the file
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <matcherdef> <andmatcher> <matcher comparelevel="order" compareattribute="proofNeeded" comparator="equals" compareto="true"/> </andmatcher> </matcherdef>
- Browse to the <serverName>\idf\sharedconfig\ordersort\decorator on the master core host (DB) server
- Create a new text file called ProofColorOverride.decorator.xml
- Copy the contents shown below to your xml file created above and save/close the file
<decorator> <!-- If matcher matches --> <matcher>ProofNeeded</matcher> <!-- Run early to apply a default --> <runLevel>2</runLevel> <!-- Applies to the sortgroup building --> <workflowContext>sortgroup</workflowContext> <!-- Applies to the sort group level --> <objectContext>sortgroup</objectContext> <!-- Then apply these attributes to the object --> <attributes> <attribute> <key>colorOverride</key> <type>string</type> <value>rgb(153,51,255)</value> </attribute> <attribute> <key>colorOverride</key> <type>string</type> <value>rgb(128,0,128)</value> </attribute> </attributes> <!-- Then apply these attributes to the object --> <onNoMatchAttributes> </onNoMatchAttributes> </decorator>
- Update all splitby lists to include an entry for proofNeeded and colorOverride, as shown in the below xml
<com.infdig.framework.idfordersort.splitby.SplitBy> <attributeName>colorOverride</attributeName> <enabled>true</enabled> </com.infdig.framework.idfordersort.splitby.SplitBy> <com.infdig.framework.idfordersort.splitby.SplitBy> <attributeName>proofNeeded</attributeName> <enabled>true</enabled> </com.infdig.framework.idfordersort.splitby.SplitBy>
Generate a proof order from the products tab
- Locate the order on the products tab that you would like to generate a proof for
- Right-click on the order, select Proofs, and then click Create Proof
- Click Yes to create the proof batch
- Select the desired destination from the batch dialog and click
At this point, a few things will have occurred. If you look at the image of the products tab shown below, we can see the following.
- The original order 9152168 still shows the original quantity of 3
- The newly created proof order has -proof appended to the order ID and also has a new quantity of 1
- Both the original order as well as the proof order show a value for Proof Sent Timestamp, indicating when the proof was generated
If we switch to the batches tab, we can see a new proof batch has been generated as shown below. Just like the products tab, the batches tab will now include (once you enable them) several columns specific to the proof batch.
- The batch ID will be prefaced with PROOF
- The Proof column will show yes, indicating that this is a proof batch
- The Proof Needed column will show No, as the order has already been generated
- Proof Sent Timestamp will show the date and time when the proof was generated
Marking orders as Requires Proof
- Select one or more orders from the products tab requiring a proof. For this example, we will select 5
- Right-click on the orders requiring a proof
- Select Proofs from the menu and then click Mark Order Requires Proof
From the products tab, it may appear that very little happened. The only thing you should notice is that the Proof Needed column will now show Yes for each of our 5 orders we selected. However, if we switch to the sort groups tab, we will see one or more purple sort group indicating we have orders marked as proof required which need to be submitted to press.
A proof batch can be generated from the sort groups by following the steps shown below.
- Right-click on a sort group containing orders requiring proofs
- Click Create Proof Batch in the menu
- On the batch dialog, select the order that you would like to create a proof for
- Click Ok
When you generate a proof batch from the sort group, the system will remove that order from the proof sort and return the original order to its normal sort group with the initial quantity intact, ready for final production.
Beyond the basics
Now that you have a functional proof workflow, you can now start looking at way to automate this process when it makes sense to do so. By using order decorators, you can have the Infinity software automatically mark orders as "Requires Proof" as they arrive in the system based on criteria you define. Let's assume that given the scenario mentioned above, you know you will be receiving a large number of desk calendar orders, all with quantities of 1000. You know that you will need to proof each of these orders but don't really want to have to manually mark each one of them as "Requires Proof". This process can be easily automated by creating a new matcher which simply looks for the calendar products by their product type, having a quantity greater than or equal to 1000. Then, we create a decorator that calls on this matcher and sets the value of "proofNeeded" to true. When an order has the "proofNeeded" attribute with a value of true, that instructs the Infinity software to treat that order as "Requires Proof".
Need additional help?
If you get stuck or have further questions on something we may not have covered, don't hesitate to contact our support team. You can reach us using any of the following options.
|
(800) 625-0599 |
|
help@infdig.com |
|
http://support.infdig.com |