The Consumer Order Process
1. | In the storefront, the print products can be selected by different filters (product groups): Category, Price and Size. All options are imported automatically from the products.xml. We also have a theme cloud (Wedding, Vacation, Brochure, etc.), collected from the PRODUCTGROUPS - Tags. |
2. | Whenever the user selects a product, he sees the product options & price and a download link for the Publisher software. The download page can be customized. |
3. | The customer installs the software, chooses the product in the product wizard, and then designs it through the help of Autofill and page templates. |
4. | Before upload, he has to login to his account or create a new account. A verification mail is sent to his email address, and after clicking this, he can continue by logging in. |
5. | After he uploads the PDF pages to the 3P BackOffice database (failsafe uploading), he is directed to the 3P OpenCart shopping cart. Several uploads can be collected in one shopping cart and then paid in a single order. |
6. | In the shopping basket, the customer sees his uploaded projects with the chosen features, but he cannot change the features anymore. (In a later version we plan to allow changing features that don't affect the dynamic spine width or the layout of the product.) All chosen product options are displayed. He can also view a flipbook preview of his uploaded pages. |
7. | After payment - numerous payment gateways like Paypal are already included in OpenCart - PDF pages are stitched into printable chunk PDFs and placed into definable print queue folders (see oc_3p_queue table). The stitching is done by a cron job (should run at least once every 3 minutes), which also changes the status of the order to Queued (2). Each order item (upload) in the 3P BackOffice and 3P OpenAdmin includes links to the PDF pages and the stitched PDF chunks. |
8. | Any status change sends an automatic email to the user, and creates a record in the oc_order_history table with an optional comment by the Admin or Printer. The following table shows the available order_status_id values: |

The Production Workflow
Printable PDFs can only be generated when an order is paid, because this triggers the Printer to produce the product. This implies, that for immediate (trusted) payments the order status is automatically set to Queued (2) by OpenCart, while for delayed payments the Administrator has to set this status manually in the 3P BackOffice. This then triggers a cron job to send a status change email to the customer and log the action into the oc_order_history table.
The production workflow in detail:
1. | As soon as the customer pays the order with Paypal or other automatic payment gateways, which return an immediate payment status, the order status is automatically changed to Queued (2). If the customer pays through Bank Transfer, the Admin can change the order status manually in the 3P BackOffice as soon as the money has arrived on his account. Whenever the status changes to Queued (2), an Email notification is sent to the customer, and the uploaded PDF pages are stitched into a printable file and placed in the corresponding print queues defined in the oc_3p_queue table. The printer then picks up the files and sets the status to Processing (15) in the job.xml file.
If an upload has not been completed, all files will be deleted after PurgeIncompleteUploadDays (see oc_3p_option table). There will be no email reminder to the customer in this case, or if the order is not paid. |
2. | The Printer (producer, manufacturer) has a special login, where he can see his queues and order items (jobs). He is able to download the PDF directly from the order item record, or download all new items in nighttime batches (through an SMB network share) into his local job queues. Every chunk PDF is accompanied by an invoice.pdf, a job.xml file containing all information about the order and a copy of the original upload.xml file. |
3. | An order item (upload) almost always consists of 2 chunks (cover, content). Since different chunks may need to be printed by different printing machines, they can go into different print queue folders, defined in the oc_3p_queue table. Print queues can also be hot folders, into which PDFs with JDF job tickets are copied in nighttime batches |
4. | If problems with the PDFs are detected, the Printer can change the order status to Failed (10) and re-delegate the order back to the admin, who can then decide what to do:

|
5. | Alternatively, the printer can do Automatic Processing, where he does not need to access the 3P Backoffice. For this he should add the print queue folder as a shared SMB network location to his own network. He can then look for job.xml files and access the print files directly in the same folder. The job.xml file contains information about the possible print states:
<OrderStatusInUse>
<Queued>2</Queued>
<Processing>15</Processing>
<Shipping>3</Shipping>
<Failed>10</Failed>
</OrderStatusInUse>
The printer should then edit the status inside the job.xml file and thus notify the 3P Backend. job.xml files are polled at regular intervals by a cron job, and the status values are transferred to the oc_order_history table, where the admin can check the status in the 3P Backend. Also, status change mails are automatically sent to the user, so if there is a problem with one of the files (10 = Failure), the customer is notified immediately. If the printer puts an OrderStatusMessage inside the job.xml file when there is a failure, the admin will also get an email with this error message.
The printer can change the status from Queued (2) to Processing (15), or from Processing (15) to Shipping (3). If an error occurs, he must set it to Failure (10) and add an error message in the xml attribute OrderStatusMessage. The corresponding section of the job.xml looks like this: |
<OrderProductPrintStatus>
<OrderProductId>3</OrderProductId>
<Quantity>1</Quantity>
<OrderStatus>10</OrderStatus>
<OrderStatusMessage>One of the pages is missing!<br/>This is line2</OrderStatusMessage>
</OrderProductPrintStatus>
Available Order Status IDs
Status
|
ID
|
Meaning
|
Options
|
Queued
|
2
|
The printable chunk PDFs have been copied into the corresponding print queue folders, along with an invoice.pdf and a job.xml file.
|
The printer can change the order_status_id inside the job.xml file, which allows a cron job to detect the status change and to update the order record automatically, or he can change the status in the 3P BackOffice manually.
|
Processing
|
15
|
All order items have been detected in the queue, and the PDFs have been downloaded. They are currently being printed.
|
The Printer should change the order status to Shipping (3) when completed.
|
Shipping
|
3
|
All order items are printed and currently being shipped.
|
The order can now be reordered by the customer (copied back into his shopping cart)
|
PDF/Printing failed
|
10
|
One of the order items has print problems. The whole order is set to failed.
|
The following issues can lead to a failure status:
1. | Set by Cron: The print queue stitching has gone wrong. If the upload PDFs are good, the Admin can repeat the stitching by setting the order status back to Queued (2). |
2. | Set by Admin: The customer would like to recall the order or correct some pages. In this case it may be better to Cancel the whole order, give the customer a coupon and ask him to do a new upload. The 3P backend will notify the printer through the job.xml to stop processing the order, assuming it was not yet in Processing state. |
3. | Set by Printer: A stitched PDF has a faulty layout or a missing picture. The Admin can delete the corresponding order item (with all PDF files) from the order in the 3P BackOffice. He can then ask the customer to upload the item into a new order, and give him a coupon for the item price, which was already paid in the first order. |
|
Reordering
|
18
|
The order items have been copied to the shopping cart by the customer in the store. All uploaded PDF files are now also copied, and the original order status is changed back to Shipping (3).
|
The order is locked. The Admin temporarily cannot delete the order & order items or change the order status to Closed, as this would delete all files and interfere with the copying of the uploaded files.
|
Order Closed
|
5
|
The order cannot be reordered anymore. All upload and print queue PDFs of all order items are deleted to free disk space.
|
Order data and invoice of the order can still be viewed by the Admin. However, the order cannot be reordered anymore. You should close an order only if the customer will not return to reorder, or if you need to free up disk space.
An order is closed automatically by the system, if PurgeOrderFilesDays (see oc_3p_option table) has been reached. Before this however, the customer will receive 2 emails to remind him to reorder. Emails will be sent 10 and 5 days before expiration.
|
Order Cancelled
|
7
|
The order cannot be reordered anymore. All upload and print PDFs of all order items are deleted to free disk space.
|
The payment should be returned to the client. The 3P backend notifies the printer through the job.xml to stop processing the order, assuming it was not yet in Processing state.
|
Notes
• | When an order is reorderd, the order records are copied to the shopping cart and the uploaded PDF files are duplicated. |
• | In the 3P BackOffice, if you delete customers, orders or order items, all associated PDF files are also deleted via cron job. |
• | All status changes, deletions and file purges are logged in the oc_order_history table. Status changes are also notified via email to the customer. |
• | Print related info files (invoice.pdf, job.xml) are stored in the InfoBaseFolder (see table oc_3p_option) |
|