I’ll admit it, I was a little perplexed when the Kountas-that-be said I’d be writing up a post on CSV imports. Not because I thought it was a weirdly specific yet ho-hum topic, but because I’d just been told that all the posts this month would focus on the theme of speed. These are not two things–CSV imports and speed–I would necessarily conflate. I’d go so far as to say they are mutually exclusive. If you’re not sure what a CSV import is, or even if you are, let’s begin at the beginning. It’s worth taking a moment to reflect on the CSV file, which is at the heart of the import.
CSV stands for comma-separated values, and I for one think it’s hilarious that the words comma and separated are separated by a hyphen. Basically, it’s like a database container invented by James Joyce, with long, run-on lines of text that must mean something to someone but what it is exactly you just can’t say, and everyone pretends to know what it means because there must be some reason it remains so popular after all these years. For the record, that reason is it’s human-readability (I’m talking about CSV, not Joyce, who remains unreadable to this day). CSV is a plain text file of words separated by commas, which our primitive mammal brains understand much better than binary. Outside of a database, it’s one of the better ways to actually read the data. Inside of a database, it’s too dark to read (sorry, Groucho). And being able to read it means being able to edit it; we can tweak the data before it goes back into the binary world and has to interact with your nonhuman processors and code interpreters. It’s really quite a great tool! Also: it sucks. The tiniest little typographical error can capsize the whole operation, and the error message is often cryptically vague at best. Finding that error can take time, and sometimes you don’t quite know what you’re looking for–searching a specific word in the document is out of the question. Sometimes you’ve formatted something wrong, but don’t know what. Using Excel makes it easier to read the contents, but also opens up a can of worms as far as new things that can go wrong. You could sort one column and not the others and find yourself with a completely incorrect inventory (which you also might not notice if the import goes well, and will only become an issue when someone rings up a 20 ounce rib eye steak for $4.99.
The other problem with CSVs occurs when you do it all correctly. Nothing wrong with that, of course, except when you see there’s still more information you need to add to make everything work the way you want. Maybe you need to set accounting codes, or need to further configure food items to send them off to a kitchen printer when ordered. Maybe you need to do all this with every location you have. This is why Kounta’s CSV imports suck so much less than other companies’ implementations. You might even say it’s pretty good.
CSV formatting is admittedly simple, and maybe you think I’m overstating the case. But it’s that simplicity that complicates things. Each app that can take data from a CSV is going to have different ways of “addressing” that data, which can lead to some important bits being left out for simplicity’s sake. But why not just do it right the first time? Get everything in there you’d need to do more than just list and sell your items. If you enter one product in manually–complete every field–you get an idea of what the software is looking for. But then you can also export a CSV, the learning process is complete. You’re given a CSV file formatted the way Kounta expects to see it, complete with an example of how to fill it in. All that’s left is to add new lines following the example and import it back in. Is this a speedy process? No. But it is time-saving, when you consider some of the fields you complete in the template.
- Category. You’re not just adding inventory, you’re creating the POS layout. By adding a category here, you’re already a step ahead in terms of organizing the screen. Bonus use: instant reporting filter.
- Cost/Sell Price, Tax Codes, Account Codes. Items are ready from the get-go for detailed revenue, tax, and profit/loss reporting. You can prevent items you don’t sell (like supplies or ingredients) from even showing up on the sell screen. And by adding in account codes, you’ve primed the data for easy integration into your accounting software, too.
- Tags. These are any kind of descriptive term you might want to attach to your items for reporting purposes. It could be anything: orange, socks, free trade, gluten-free. Including tags sets you up for greater insights into your customers over the long term.
- Print Docket. This flags an item if it needs to be sent automatically to a kitchen printer once it’s ordered. When you setup your printers at each site, the system will already have this and other items listed for selection.
You’ll notice in that last one, that there’s a central theme implied here. I don’t mean there’s some kind of theme central to this piece, but that the actual theme is of centralisation. With the print docket value, you set it company wide and then make site specific tweaks. That’s also the same for every other value. When I said “right right the first time,” it was the same as saying “do it right the only time.” By making the CSV import simple but comprehensive, we’ve certainly sped up the entire setup process. But by centralising all this, you only need to go through the import once, and then spinning up another site is a quick, minutes-long process. And with that, I just talked myself out of my puzzlement over the CSV/speed correlation.