Replacing Genius Central #1
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
aka. Scan Genius, Living Naturally etc.
This comes to mind while trying to think of what exactly Theo should "do" in order to see widespread adoption. I've thought for years that "replacing" Genius Central would be somewhat low-hanging fruit.
The basic features of Scan Genius (as I knew it) or Genius Central (today) as I understand them:
Their main advantage as I see it? Genius Central is just that - central. Meaning in particular that accurate cost data is maintained in one place and isn't the separate responsibility of each retailer. For instance, providing the PO and invoice tools in a local app instead of "in the cloud" (at GC.com) is relatively easy to do, but staying on top of those costs is a separate problem.
The other big advantage is GC's vendor relationships. They have digital hooks in each, so to speak, which allows them to stay on top of cost data, but also improves automation options for submitting PO and obtaining invoices.
But self-hosted is surely the place to start, in which case Theo features might be
Not sure what "processing" an invoice means yet in this context, but throwing it out there as a possibility, depending on POS integration etc.
The catalog updates are the tricky part here. Most retailers would want latest/accurate cost data in their POS regardless, but how to accomplish? Obtaining the latest catalog data file is a problem to itself, for now we'll assume they each have ways to do that. So then how to update POS and/or Theo with it? Depends on the POS probably, for instance SMS can receive arbitrary data updates like this quite easily, whereas I doubt so for Catapult. It doesn't seem like a great option, but possibly the cost data should be updated in Theo but then POS can be neglected? Or at least dealt with as a separate problem, and Theo need only concern itself with its own data here. (In other words, Theo could easily provide tools for bringing in new catalog data for its own sake, but updating POS is harder.)
So the implementation plan might look like: