thoughts on checkout
September 4th, 2008 by jim winsteadAs I have mentioned before, we are using a piece of point-of-sale software for the store called Checkout. It is, despite all the complaints I am going to make about it in this and future posts, a pretty good piece of software.
My overall summary would be that it is very good, but it could use a lot of polish based on some real user feedback. There are just lots of little annoyances that I am running across in the interface, especially things that make the system harder to use.
For example, receiving an order requires either scanning every item, dragging and dropping each item from one list to another, or manually selecting the number of received items and typing in how many you have received. That doesn’t sound so bad, right? Today we received an order with 522 items of about 150 distinct products. This is mostly our racks of M. Graham gouache, oil, and watercolor paints. With our barcode scanner out for repair, receiving all of these items into the system will require manually clicking on a column (not the whole column — just the existing 0!) and entering the correct number of items of that product that we have received.
There are a couple of things they could do to fix this problem. A cheap shortcut would be to have a way of saying you have received a whole order. Long-term, I hope they can make the spreadsheet-like receiving form actually keyboard-navigable, like a spreadsheet would be. This is true of the other similar forms in the application.
And this is just the warm-up — one of the shipments we receive on Monday has over 1,000 items of about 250 different products. I don’t even want to think about what our drop-ship of Golden acrylic paints and mediums is going to entail.
There are some perks to having a computer nerd (me) as part of the team. To load information about the products into our system, I was able to save the HTML listing of the different colors each line of paints came in and cobble together some Python code to transform that into a format that Checkout could understand. But I still had to manually set the supplier for all of these products because Checkout won’t set that information from the import.
Something nifty I learned about Checkout today is that the printing system is based on using Cheetah templates that are rendered using WebKit. I was able to take the template that the Checkout support team sent me when I asked about printing a signature line on credit card receipts, and improve it so that it only printed the signature line on orders paid via credit card. It is a little fragile, though — an error in the template causes the whole application to exit.
I know I’ll have lots more to say about Checkout, like complaining about the undocumented AccountEdge integration. But like I said in the beginning, it is a pretty good piece of software.


September 18th, 2008 at 1:04 am
Hey Jim,
I am Koen, one of the main developers of Checkout. Thanks for sharing your thoughts online, I wanted to let you know we’re paying attention. We always love real user feedback, as we built most of Checkout based on that.
So I was thinking about your PO comments and would it maybe be handy to have CSV importer for PO’s that either create a new one or update the received item on an open purchase order? That way you can (if you get some sort of digital delivery list) open it up and you’re done, or even build your own workflow with Numbers/Excel.
About the templating: Checkout should not halt if you have a cheetah error and you template loaded in sandbox mode. I’ll double check to see if we have bugs there.
I’m glad you are overall happy with the product, and we’re always interested to hear your thoughts!
Kindest regards,
Koen Bok – madebysofa.com