OMEGA by KROS is the most widely used double-entry accounting software in Slovakia \u2014 and at the same time a system into which many e-shops still retype their orders by hand. The invoice gets issued twice, the stock prices in the e-shop don’t match the accounts, and product availability is more of a guess. This article sums up what can be transferred between an e-shop and OMEGA automatically, which connection routes exist and what to watch out for.<\/p>\n
OMEGA can be connected to an e-shop \u2014 the question is how. The options are the Konektor<\/strong>, an API service straight from KROS (purchasable only with a valid KROS support package (Bal\u00edk podpory)), batch XML\/Excel imports<\/strong> (free, but manual work) and an integration platform<\/strong> (built to fit the agendas you choose, monitored, two-way). For a small e-shop with a few orders a day, imports are enough; as the number of orders or agendas grows, automation pays off.<\/p>\n<\/div>\n OMEGA is built for Slovak legislation \u2014 VAT, statutory reports and document requirements. For Slovak companies that is an advantage; for Czech entities it is not a fit. The Konektor is tied to the KROS support package (Bal\u00edk podpory)<\/strong>: without valid support the API service cannot be purchased, which the budget has to account for from the start. And a third thing: selling prices are governed by OMEGA. The Konektor sends out cards with fixed prices \u2014 the e-shop is meant to display them, not overwrite them.<\/p>\n Slovak e-shops most often run on Shoptet \u2014 which makes the pair Shoptet + KROS OMEGA<\/a> the connection we build with OMEGA most often: orders from Shoptet into OMEGA, cards, prices and availability the other way. The same principle applies to WooCommerce<\/a>, Upgates<\/a>, PrestaShop<\/a> and Shopify<\/a> \u2014 the e-shop side changes, the OMEGA side stays. There is an overview of the system on the KROS OMEGA<\/a> page.<\/p>\n The most common source of drifting data with OMEGA. The Konektor sends stock cards with fixed selling prices into the e-shop \u2014 if marketing overwrites prices directly in the e-shop, the next synchronisation either overwrites them back, or the data drifts apart and nobody knows which price applies. The fix is simple, but it has to be followed: OMEGA is the source of truth for prices<\/strong>; promotions and discounts are handled there, and the e-shop displays them. This rule is the first thing we set up on every integration.<\/p>\n<\/div>\n For a connection through the Konektor, a valid KROS support package (Bal\u00edk podpory) and the purchased Konektor service. Whether you have them, and in what scope, is something we verify during the initial analysis \u2014 so the budget accounts for it from the start, not when the invoice arrives.<\/p>\n<\/details>\n In batches, yes \u2014 OMEGA can do XML and Excel imports, so you can synchronise via files. But it is not continuous synchronisation: it suits small volumes or serves as a supplement, not as the main route for a growing e-shop.<\/p>\n<\/details>\n The price follows the number of agendas \u2014 a basic connection of one agenda comes to 6\u201312 hours of work depending on type, with the exact scope pinned down after an initial meeting. On top of that, add the KROS support package (Bal\u00edk podpory) and the Konektor on the KROS side, if you don’t have them yet.<\/p>\n<\/details>\nWhat flows between the e-shop and OMEGA<\/h2>\n
\n
Three connection routes<\/h2>\n
\n
OMEGA specifics to plan for<\/h2>\n
The most common case: Shoptet + OMEGA<\/h2>\n
One trap: who sets the prices<\/h2>\n
Frequently asked questions<\/h2>\n
What do I need from KROS for the connection to work?<\/summary>\n
Does the connection work without the Konektor?<\/summary>\n
How much does connecting an e-shop to OMEGA cost?<\/summary>\n