Bytesoft builds e-shops for the Greek market: a catalogue search engines can read, mobile checkout, payments, shipping and an ERP bridge so stock, prices and orders do not live in spreadsheets. We do not ship a stock theme with plugins. You receive a store your team can run — based in Patras, serving Greece.
The brief does not start with a theme. It starts with who buys and how you price.
One price list, cart, payment, shipping. Filters must work on a phone and out-of-stock items must not appear as available in the feed.
A logged-in customer sees their price, not retail. The ERP holds the list; the store applies it in the cart without manual edits.
Two flows in one store: retail visitor and wholesale account. Without clear roles, discounts leak to the wrong group.
The e-shop is the source for Skroutz and BestPrice, not a second, disconnected stock list. Feed availability must match ERP stock.
| Criterion | WooCommerce | Custom |
|---|---|---|
| Catalogue size / SKUs | Holds mid-size catalogues with proper indexes; very large catalogues need careful database and cache design | Designed for your volume from the start |
| Catalogue speed | Depends on hosting, cache and plugins — measured before go-live | Treated as a performance target, not added later |
| Maintenance cost | Core, theme and plugin updates in the agreed scope | Updates to your own codebase — no surprise third-party plugin |
| Checkout flexibility | Extendable; limits when checkout must ignore theme rules | Payment and shipping flow as in the brief |
| Code ownership | Theme and custom code in your repository; WooCommerce core stays open | The store’s code in your name |
Platform selection guide: how to choose an e-shop. WooCommerce vs Shopify: WooCommerce vs Shopify in Greece.
URL structure per category and product, no session ids, no duplicate variant pages. Colour/size variants canonicalise to the parent card when they do not deserve their own URL.
Filters produce indexable pages only when the brief asks; otherwise noindex on infinite combinations. Pagination agrees with crawl.
Product and Offer schema from the same price and availability the customer sees. Out of stock: hidden from the feed, marked in the store, no hidden add-to-cart.
Titles and descriptions are written for someone comparing, not as a keyword pile. Each product card has one main image large enough for a marketplace and a gallery that does not repeat the same crop four times.
Out-of-stock handling is a commercial choice: hide, “notify me”, or pre-order. Whatever you pick must match ERP stock and the feed — otherwise you pay for ads on items you cannot sell.
Below are the fields we sync when they enter scope. Anything missing from the table is not assumed.
| Group | Fields |
|---|---|
| Item identity | SKU, EAN/barcode, ERP item code, title, description |
| Prices | Retail price, offer price, per-customer price list (B2B) |
| Stock and physical | Stock per warehouse, dimensions, weight |
| Catalogue | Categories and subcategories, attributes, filters, manufacturers, colour/size variants, gallery, enable/disable |
| Commerce | Customers, orders, order status, courier vouchers |
We recommend one-way flow per field with one source of truth. The ERP usually owns price and stock; the store owns the order that returns. Bidirectional edits of the same field without a conflict rule produce duplicates and a wrong Skroutz feed.
“Real time” in Greek retail almost always means a window of minutes, not an instant write on every click. A push from the ERP where available; otherwise a scheduled pull with a written interval. The window lives in the project runbook — not as advertising copy.
A bridge without failure rules sells the wrong stock. The mechanics behind that — idempotency, retries, reconciliation — are described under system integrations.
| ERP | Connection method |
|---|---|
| SoftOne | REST / SOAP by version and client access |
| Pegasus | REST / XML by version and client access |
| Entersoft | REST / SOAP |
| Pylon | REST / DB |
| Atlantis | REST / XML |
| Galaxy | REST / SOAP |
| Prisma Win | REST / XML |
| Epsilon Smart | REST |
We take an integration on after analysing access, API and fields. We do not call it a deliverable before we see those — and we are not certified partners of the vendors.
Feeds are built from the same catalogue as the e-shop. Validation before send: required fields, price, availability, image, category. A wrong feed is a commercial error, not a “technical detail”.
Payments and shipping rules in the agreed scope — bank gateways and courier vouchers when the ERP or carrier issues them. Returns: order status back to the ERP so stock is not left “sold”.
On the e-shop, myDATA covers per-order invoicing. A general AADE integration for accounting is covered under system integrations.
Returns and partial shipments need a status the ERP understands. If the store says “returned” and the ERP still says “invoiced”, stock and the document drift until someone fixes them by hand.
We do not quote a price without measuring your catalogue; the bands show what changes scope and the amount locks after discovery. In detail: e-shop cost factors.
Yes, as a store bridge: products, stock, prices and orders sync with the ERP you can access and document. We are not certified partners of the ERP vendors; we build on the documentation and access you hold. Other ERPs enter scope after analysis.
WooCommerce fits a manageable catalogue when you want flexibility without rebuilding checkout. Custom fits when SKUs, B2B prices or checkout exceed what a theme can carry. The choice locks in discovery.
We do not quote a price without discovery. Cost depends on SKUs, languages, warehouses, marketplaces and who supplies the content. After analysis you get a band and milestones. In detail: e-shop cost factors.
Starter with a ready catalogue: a few weeks after kickoff. Business with one ERP bridge and Skroutz: more milestones. Advanced with multiple warehouses: the timeline locks at kickoff.
In the agreed scope: SKU, EAN, item code, title, description, prices, per-customer price lists, stock per warehouse, variants, gallery, customers, orders, order status and courier vouchers. Fields not on the list do not sync silently.
One source of truth per field. Prices and stock usually flow ERP → store. Orders return to the ERP. Editing the same field in both systems causes duplicates — we avoid it unless discovery defines a conflict rule.
Yes, as part of the e-shop: a feed with validation of title, price, availability and images before it is sent. It is not a separate “SEO package”.
On the e-shop, myDATA means invoicing a store order. A general AADE integration for accounting is covered under system integrations.
Yes. You get admin, training and basic documentation. Day-to-day running does not require Bytesoft outside agreed support.
The store must know whether it sells on last-known stock or pauses orders. Those rules lock in discovery. Failure handling is covered under system integrations.
For hosting the store, with resources for ERP/Skroutz cron jobs, see managed hosting for e-shops. For store infrastructure support. For product and category SEO, the monthly SEO plan. Locally, the Patras digital agency.
Last updated: 2026-09-08
Related services: integration mechanics · hosting for e-shops · admin-panel security review for a store