Creating my own Point of Sale system, Part 1: Design

This took some time, I'm (mostly) back on track. When I chatted with my SI friends, the first thing I noticed was they asked a fuckton of questions. They grilled me about specifications, use cases, reliability or scalability. They also gave insane price quotes but I'll skip over that. The reason is simple: Specifications save time. I am definitely not used to that. I'm used to quickly hacking together a sqlite database for a chatbot in python and iterating bugfixes/feature additions as I go. So I thought, "Why not do it properly for once?"

Well, that was also a mistake.

The first thing one notices when starting a programming project is the sheer number of decisions. From the programming language to data types, databases and used design patterns, each choice has several impacts and you don't even know the right use case if you don't work with them for some time.

So let's start with the language. I am quite fluent with Python (as in, I can solve most given problems in Python without having massive headaches), which I also consider a scripting language not particularly fitting my "program" image in my head. I wanted to learn C# at some point, but I didn't want to turn get a situation where I don't know what I'm doing in a language I don't know. That's the same reason I turned down Scala, no matter how beautiful the syntax is. I'll probably end up with Java, because I used it at University for 2 years and I consider myself competent in it.

Of course, knowing Java (understanding OO and ORM, getting good grades in programming courses) at a University level is fucking nothing. The only design pattern I know is a singleton. I probably can understand DAO's but for me it's like a holy text to follow blindly. I understood how to design a database and the reasons for transactions, got an A in an exam and then never touched that shit again. So you kinda think you know how to do it but you've never actually coded it.

In machine learning terms, it's similar to how you can know theoretically how to use logistic regression or SVMs or different neural network architectures (An image? Just use convolution! Duh!) but it is also important to know how to do them. Like using Keras or Tensorflow or the sklearn package when no one is looking. That also takes practice.

I'm essentially at 0 knowledge.

Anyway. My vision starts with a simple underlying database. It would contain 3 tables:

• Wares
• barcode(str, primaryKey)
• name(str)
• unit price(float)
• tax rate(float)
• Receipts
• id(int, primaryKey)
• FIK (str) or "fiscal identification code"
• DIC (str) or "tax identification code"
• BK (str) or "security code"
• Date (date)
• total_before_tax(float) - These are actually redundant but I don't want to do a SQL query for everything
• total_after_tax(float)
• a list of wares for the given receipt, probably using foreign keys
• Storage
• a simple mapping of Wares to current amount

Now this is really easy to do using SQL (I know postgresql, but mostly use sqlite for simple things).  It is also braindead simple to do using Objects (in fact, in Java most of the code is generated by the IDE). But a simple ORM in Java? Nah. I've been told it's simple. Lmao. I don't even know what to use, a quick google lead me to hibernate. Well sure, I can spend time to figure out how to install it (I miss imports already), do a basic tutorial and write a XML file with the mappings. A perfect weekend project for fucking masochists. Oh my God.

But let's pretend I'd done all the Data Access Objects and their SQL implementations together with a databaseModel object that initalizes the database. Then we move along to the application. That's probably easier, right? I got two simple use cases. The first one is a bunch of text boxes where you input the name and the price and then do a barcode scan. Afterwards you press a button and the ware gets saved in the database.

The second one is the PoS itself. We need to:

1. Load the barcodes from the scanner
2. Get the corresponding Ware objects.
3. Show the current price on the monitor (and possibly a serialbus output for a LED display too, but let's not get utterly insane here)
4. Put them in a Receipt object
5. Generate the XML code (using a opensource java library from github)
6. Send it to the state
7. Retrieve the return code (the FIK one)
8. Add it to the Receipt, saving it to the database
9. Print it

The storage table is to keep track of our wares and possibly some SQL inference to know how much profit we made (protip: probably low).

The worst part will be the GUI, which I hadn't done for 2 years. I actually thought (after a recommendation) to just use fucking python flask with a simple javascript frontend, which would probably cut like 70% of the time, but it just doesn't feel proper, even though java is verbose overkill.

So what's done is using the barcode scanner (it's a simple keyboard interface) and a shitty drawing of my database along with the java objects (without any annotations or XML mappings yet). After I get the ORM done, I'll try to cobble together some basic javaFX GUI without using an exit bag and we can start filling the database while I do the main app in the meantime.