So, you want to print custom labels from an iPad (or Android tablet, phone, whatever)? We recently finished this exact project. Here’s how we did it…
First, a little background: our custom labels are price labels we print for our customers. The labels must contain the following:
- The retail price (not the price we charge our customers but the price they charge consumers)
- Barcode that can be scanned for reordering inventory from us
- Information about the item, such as SKU, brand, and description
There are several tech components – starting with software:
- Pricing application – our retail pricing is controlled within our LEGACY MULTI-VALUE ERP (your prayers are welcome)
- Web server – we decided to handle this as a web app
- Mobiprint App – handles the actual printing
- iPad (or Android or mobile phone or whatever)
- Bluetooth label printer – we’re using Zebra QLn320
And the most important component of a successful project – a GREAT team! I had the privilege of working with a fantastic Multi-Value Web Coder and my rock-star SysAdmin.
Our first major decision (after finding the right components) was how to develop the actual application. We decided on a web app, because:
- The development is easier
- We can maintain 100% control over the development and implementation process (no 2-week Apple approval required)
- It will support all mobile devices
- It eliminates the need to push data to the device (other than web pages)
The elimination of data being pushed to the device is a fairly big deal for us, because of our infinitely-flexible pricing application (that MULTI-VALUE ERP I mentioned earlier). Our iPads are already loaded with many pricing records to support the prices we charge customers, which is managed through the fantastic Handshake application our sales reps use. Retail pricing is another infinitely-flexible set of prices that may result in many more pricing records. We decided it makes more sense to leave the data on the ERP and just request what we need, when we need it, since retail prices are not required for all customers at all times.
So, we decided it will be a web app, and all of the pricing logic happens within our legacy ERP system. There are really two primary ways to build this application:
- Use an existing web framework to develop the web application and hit the ERP with an API for the retail pricing logic.
- Develop the whole thing in the ERP and make it available as a url.
Both options are valid.
If you work in the multi-value world, you may be familiar with MVI (multi-value integrator) – a GREAT tool (I originally purchased WAY back in 1999) that allows the development of APIs within a legacy MV application. You can read about this tool and the great guys who created it here. We’re not using MVI, but something very similar that does the same thing. It makes the connection from the ERP to the web possible.
OK – we have the web application built, it retrieves the correct retail price based on customer and product combination, now we simply need to deal with the printing aspect of this project.
Remember that rock-star SysAdmin I mentioned earlier? He found MobiPrint, which allows us to pass all of the variables and printer formatting commands through a URL that is then interpreted by the iPad MobiPrint app and ultimately sent to the bluetooth printer. The label format must be set up in advance to include all of the variables we want to print on the label. Since we’re using the Zebra QLn320 printer, we need to use Zebra utilities and CPCL setup language. After the label format is set up, we use the variables to build each label print URL. The result? A nicely-formatted shelf-tag label!
Put it all together and we have:
- iPad user visits the web application.
- The web app prompts for the customer#, then allows the user to scan or enter up to 10 products. We accept SKUs or UPCs – scanned or entered manually.
- When ready, the user taps ‘print’.
- The web app creates a URL for each label, passing the individual variables for all print fields.
- MobiPrint prints the labels and returns back to the app for the next instruction.
What could be easier?
Well, we hit several challenges that I’ll share here, just in case you are following along and have similar problems…
- Our web app only works in Chrome. Safari doesn’t return back to the application cleanly (see next bullet below).
- We had to mess around with opening/closing new browser tabs in order to allow the MobiPrint app to handle each label, while also returning back to the app after all 10 labels are printed.
- We ran into a problem where the cursor doesn’t refocus on subsequent product inputs. What’s that now? User scans productA, the scanner injects a <CR>, but the cursor does NOT automatically refocus on the next input line for the next scan.
- Turns out this is an Apple problem [sigh].
- I suspect we may be able to bully it into submission.
- While considering bullying tactics, our rock-star SysAdmin suggested we simply put all 10 product scans into one text box and parse it in the app. Works great.
We have rolled this application out to our field testers and will be expanding roll-out over the next 2 weeks.