The roads I take...

In den letzten paar Monaten habe ich (mit einem Kollegen) ein neues Unternehmen unter dem Namen Trade Post 47 aufgebaut. Während wir es uns als eine kleine Raumstation im Orbit eines schönen Planeten vorstellen, wird es für die meisten Menschen als Handelsunternehmen für Science-Fiction-Merchandise gesehen werden, mit einem Online-Shop sowie Ständen bei Veranstaltungen wie lokalen Comic-Cons in Mitteleuropa, vor allem in Österreich. Für alle, die mehr erfahren wollen, haben wir eine komplette Seite über uns auf unserer Shop-Website erstellt.


Um unsere Produkte zu verwalten, die wir von verschiedenen Anbietern (manchmal das gleiche Produkt über verschiedene Anbieter) erhalten, sowie unsere Bestellungen zu planen und zu verwalten, habe ich ein internes, benutzerdefiniertes Warenmanagement in meinem eigenen PHP-Framework bzw. CMS CBSM (das zum Beispiel auch für dieses Blog verwendet wird) aufgebaut. Zum Großteil fiel die Entscheidung dafür aus Bequemlichkeit, nachdem ich dieses System sowieso betreibe und warte und ich einige Datenbanktabellen benötigte, inkl. passender Benutzeroberfläche für die Verwaltung unserer Waren, Anbieter und mehr (sogar Conventions, auf denen wir Stände betreiben möchten).

Andererseits ist der öffentliche Shop (wie Sie es bemerken können, wenn Sie sich die Website ansehen) eine Installation von Magento 2 (d.h. die Open-Source-Version von dem, was heute "Adobe Commerce" genannt wird). Wir haben uns für dieses System entschieden, weil wir eng mit MCO Shop zusammenarbeiten, einem lokalen CB-Funk- und Elektronikgeschäft, und dort bereits zuvor diese Software auf den Servern lief, die wir mitverwenden und das Wissen bereits da ist, wie damit gearbeitet wird, die Upgrades ausführt werden und das System gewartet wird. Schließlich hilft es beim Aufbau eines neuen Unternehmens immer, wie in so vielen Lebensbereichen, wenn man einige Ressourcen und Wissen mit anderen gemeinsam nutzen kann. Für unseren Teil, habe ich zuerst das Magento-Theme angepasst, um den Shop "Weltraum-ähnlicher" aussehen zu lassen, vor allem mit einem dunklen statt hellen Hintergrund. Sobald das gut genug funktionierte, musste ich immer noch jene Produkte aus meinem selbstgebauten Warenmanagement, die wir tatsächlich bestellt haben, in diesen Magento-Shop bekommen. Anfangs habe ich dafür eine große CSV-Datei erstellt und in den Shop importiert habe, aber es war klar, dass wir auf lange Sicht eine feinkörnige Lösung brauchten, die Einträge einzeln hinzufügen bzw. aktualisieren kann.

Zusätzlich, wann immer wir Stände auf unseren "Außenmissionen" auf Veranstaltungen/Conventions betreiben (oder wann immer wir sonst etwas persönlich verkaufen), verlangt das österreichische Recht die Verwendung eines Registrierkassensystems, das strengen Regeln befolgt und entsprechend zertifiziert ist, damit von Seiten der öffentlichen Verwaltung sichergestellt werden kann, dass wir korrekt unsere Steuern abführen. In diesem Bereich haben wir uns für die integrierte Lösung unseres Buchhaltungssystems entschieden, die auch online als Web-Service läuft, eine spezialisierte österreichische Lösung namens FreeFinance. Und natürlich braucht die Registrierkasse auch eine vollständige Liste der Produkte und Preise, die wir zunächst auch mit einer CSV-Erstellung und -Import gelöst haben, in Erwartung einer detaillierteren Lösung nach unserem ersten großen Auftritt auf der Austria Comic-Con Anfang Juni.


Zur Abrundung wollten wir auch schön gestaltete Rechnungsdokumente in FreeFinance für alle Online-Shop-Bestellungen generieren, die nicht über die Registrierkasse bezahlt wurden, und in Zukunft möchten wir den Online-Shop automatisch auf Waren aufmerksam machen, die auf Veranstaltungen verkauft werden, so dass sie für Online-Käufe aus dem verfügbaren Lagerstand entfernt werden.

Um dies zu erreichen, habe ich mir die APIs angesehen, die sowohl Magento als auch FreeFinance bieten, und baute Verbindungen auf diese vom eigenen internen System auf, auf das ich vollen Zugriff habe und das für die Bereitstellung der Warendaten sowieso erforderlich ist. Ich fand heraus, dass die FreeFinance API relativ einfach und gut dokumentiert ist und die Authentifizierung über OAuth2 durchführt, von denen ich bereits durch andere Projekte einige Kenntnisse hatte (und Code für den Zugriff darauf), einschließlich einigem Code, der bereits im CBSM-System zur Durchführung von Logins verwendet wird. Magento dagegen ist eine andere Baustelle: sein Produktkatalog-Funktionsumfang ist viel komplexer, und ebenso die API dazu. Außerdem gibt es keine gut strukturierte kollektive Dokumentation, die erklären würde, was verschiedene Dinge bedeuten oder was vorzugsweise auf welche Weise getan wird (oft gibt es mehrere Wege zum gleichen Ergebnis) - Im Endeffekt resultiert die Arbeit meist im Einschalten des Entwicklermodus, so dass eine Swagger/Open-API-Benutzeroberfläche auf der Installation verfügbar ist und dann in Herumprobieren und im Internet herumsuche, was wie funktionieren könnte und welche Wert was heißen könnte. Darüber hinaus erfolgt die Authentifizierung über OAuth1, was komplizierter ist als sein Nachfolger, und wofür den ich keinen bereits bestehenden Code hatte, obwohl ich auf Code aus dem Tutorial aufbauen konnte. Da wir Magento selbst auf der Serverseite betreiben, konnte ich leichter mit Dingen herumprobieren, als bei FreeFinance, einem gehosteten Dienst, wo ich Zugangsdaten von ihrem Team anfordern musste. Aber FreeFinance gab uns Zugang zu einem Testsystem, während wir für Magento aus verschiedenen Gründen nur ein Live-System und kein Staging-/Test-Umgebung haben, so dass wir beim Testen nicht sehr viel "herumspielen" können.

Im Endeffekt habe ich ziemlich viel Code für all diese Fälle geschrieben, der einfachste Teil war und aktualisiert sicherlich die Kasse mit unseren Produkten, die einzige leichte Komplikation dort war Kategorien hinzuzufügen, wenn nötig. Um Produkte in den Shop zu bringen, musste ich alle möglichen Dinge respektieren, wie das Erstellen und Verwalten konfigurierbarer Produkte, Werte zu einigen Attributen anzulegen, Hochladen von Bildern, Verwalten von Kategorien und mehr. Und die merkwürdige Struktur der Magento-API, die viel detailliertere Aktionen als der CSV-Import-Weg erfordert, macht dies manchmal noch komplizierter - aber es funktioniert jetzt und ich kann einfach ein Produkt im Warenmanagement hinzufügen oder ändern und spätestens am nächsten Tag sind sowohl der Shop als auch die Registrierkasse mit den Änderungen aktualisiert (ich kann die Jobs auch früher auslösen, wenn benötigt). Für die Erstellung der Rechnungsdokumente konnte ich einige Dinge auf einem make.com "Blueprint" von FreeFinance aufbauen, aber zum einen möchten wir keinen bezahlten Drittanbieter-Service verwenden, wenn wir dies selbst automatisieren können, und zum anderen haben wir einige Einschränkungen und Spezialitäten unsererseits auch dabei (wie Rechnungen nur zu generieren, wenn Zahlungen direkt im Online-Shop gemacht wurden und nicht persönlich über die Registrierkasse). Ich bin dort auch auf einige Kuriositäten gestoßen, wie dass die Magento-Bestellungs-API manche Datensätze mehrmals enthält, oder wir haben zunächst eine Dokument-Layout-Vorlage verwendet, die nicht unterschiedliche Mehrwertsteuersätze unterstützt (was wir allerdings benötigen) - aber das funktioniert jetzt auch. Die umgekehrte Variante, Registrierkassen-Einkäufe im Online-Shop zu reflektieren, steht immer noch auf meiner Liste, aber ich habe jetzt einen guten Plan, wie ich das erledigen kann, und einige Zeit bis zu unserer nächsten großen "Außenmission", bei der dies wichtig sein wird.

Alles in allem war es eine ziemlich interessante Erfahrung, und nachdem ich mich jetzt mit der Arbeit mit diesen Systemen und APIs wohlfühle, bin ich mir sicher, dass ich werde auf lange Sicht mehr mit ihnen machen werde - und unser Trade Post 47 wird hoffentlich auch weiter wachsen und daher in Zukunft zusätzliche Anforderungen haben. Wenn ihr Entwickler seid und Fragen zu einigen Details habt, könnt ihr mich gerne kontaktieren - und wenn ihe solche Systeme selbst betreibt und einen Entwickler benötigt, der diese in ähnlicher Weise anpassen kann, bin ich auch gerne bereit, diese Dienste anzubieten!

In the last few months, I have been building up a new business called Trade Post 47. While we envision it as a little space station in orbit of a nice planet, to most people it will be a science fiction merchandise trading company, with an online shop and booths at events like local Comic-Cons in Central Europe, especially in Austria. If you want to learn more, we have put up a complete page about us on our shop website.


To manage our products, which we get from different vendors (sometimes the same product via different vendors) as well as plan and manage our orders, I built an internal, custom merchandise management in my own PHP framework or CMS CBSM (which is also used for this blog, for example). I did this mostly out of convenience as I have and maintain this system anyhow and I needed some database tables with fitting UI for managing our merchandise, vendors, and more (even conventions we may want to run booths at).

OTOH, the public shop is (as you may notice when looking at the website) an installation of Magento 2 (i.e. the open-source version of what is nowadays called "Adobe Commerce"). We decided to run that system because we are partnering closely with MCO Shop, which is a local ham radio and electronics shop, and they already had this software running previously on the servers we share and know how to work with it, run the upgrades, and maintain it. After all, when building a new business, as in so many areas of life, it always helps if you can share some resources and knowledge with others. First, I adapted the Magento theme to make it look more "space-like", mostly importantly, having a dark instead of light background. Once that worked well enough, I still had to get those products that we actually ordered from my custom management system into this Magento shop. Initially, I did this via creating a big CSV file and importing that into the shop, but it was clear that we needed a more fine-grained solution in the long run that can add and update entries individually.

Additionally, when we run booths on our "away missions" to events/conventions (or whenever we otherwise sell anything in person), Austrian law requires us to use a cash register system that follows strict rules and passes a certification so that the government can be sure we pay taxes for everything we sell. For that we decided to use a solution integrated into our bookkeeping system, which runs online as a web service as well, a specialized Austrian solution called FreeFinance. And of course, the cash register needs a full list of products and prices as well, which we also initially solved with a CSV creation and import in anticipation of a more fine-grained solution after our first big appearance at Austria Comic-Con in early June.


As icing on the cake, we also wanted to generate nicely styled invoice documents in FreeFinance for all online shop orders that weren't paid via the cash register, and in the future, we'll want to make the online shop automatically aware of merchandise sold at events so they are removed from available stock for online purchases.

To achieve that, I looked into the APIs that both Magento and FreeFinance provide, accessing them from the custom internal system that I have full access to and that is required for providing the merchandise data anyhow. I found that the FreeFinance API is relatively simple, well-documented and does authentication via OAuth2, which I already had some knowledge of (and code to access it) from other projects, including some code already in the CBSM system for facilitating its own logins. That said, Magento is a different beast: its product catalog feature set is way more complex, and so is its API. Also, there is no well-structured collective documentation that would explain what various things mean or what is preferably done in what way (often there are multiple paths to the same result), it's a lot of turning on developer mode so that a Swagger/OpenAPI UI is available on your installation and then trying around there and searching the web for what could work how and what value could mean what. In addition, authentication is done via OAuth1, which is more complicated than its successor, and which I didn't have any pre-existing code for, though I could build on some code from their tutorial. Also, as we're running Magento ourselves on the server side, I could more easily try around things than with FreeFinance, which is a hosted service and I needed to request access credentials from their team. But FreeFinance gave us access to a testing system, whereas for Magento, for various reasons, we only have a live system and no staging/testing environment, so we can't "play around" very much when testing.

I wrote quite a bit of code for all those cases, the simplest part was and is surely updating the cash register with our products, the only slight complication there is adding categories if needed. For adding products to the shop, I needed to respect all kinds of things, like creating and managing configurable products, adding values to some attributes, uploading images, managing categories, and more. And the curious structure of the Magento API, which requires way more detailed action than the CSV import route, did at times make this even more complicated - but it works now and I can just add or change a product in the merch management and at the latest on the next day, both the shop and the cash register have updated to those changes (I can trigger the sync jobs earlier if required). For creating the invoice documents, I could base some things on a make.com "blueprint" provided by FreeFinance, but for one thing, we don't want to use a paid third-party service if we can automate this ourselves, and for the other, we have some restrictions and specialties of our own there (like only generating invoices for orders actually paid via the web shop payment integration and not in person via the cash register). I did run into some curiosities there, like the Magento order API result containing several pieces of data multiple times, or us initially using a document layout template that didn't allow for different products having different VAT rates (which we require) - but that's working now as well. The reverse part about getting cash register purchases into the online shop is still on my plate, but I now have a good plan for how to do that, and some time until our next big "away mission" where this will be important to have.

All in all, this has been a quite interesting experience, and I'm sure now that I am comfortable with working with those systems and APIs, I will do more with them in the long run - and our Trade Post 47 hopefully will still grow as well and therefore have additional requirements in the future. If you are a developer and have questions about some details, feel free to contact me - and if you are running such systems yourself and need a developer who can adapt them in a similar fashion, I'm happy to offer those services as a contractor!