The goal of the zSYNC is to be complete data hub for all your needs. Any source can be put to any destination. The zSYNC shines most, if one of those endpoints is Odoo, but this is no necessity at all.

Every API can be connected. The more exotic it gets the more likely it is that you need at least a little python knowledge. All common APIs can be connected this the most basic of knowledge.

And all this can be done in the trusted and cosy environment of you Odoo frontend. Which means, no update, no downtime, no deployments, no bugs...

One of the biggest advantages with the zSYNC is: You don't need code, deployments, updates.

You could implement an API with 100% code and still profit from lower risk (no updates) and technical advantages (Logging, Monitoring, Queue Jobs)

So even if you are a developer, you maybe profiting from it

Most of the API is configured in the frontend and code will also be implemented via frontend (similar to a automated action)

When your interfaces are developed by multiple people for multiple use-cases, they are normally dedicated bits of code doing their job. So ever interface is an own module behaving like the developer preferenced it.

Was ever interface developed effectively? 
Is every interface on a similar quality level?
Was every interface documented perfectly?
Is configuration hard written in code or has it been moved to frontend? 
Do you have assured then they don't block each other? 
Can they be run synchronous and asynchronous?
What happens when the person developing it is gone?

All this problems do not excist, when you use the Zync. All Interfaces are done in the same framework, which was developed since 2019 with multiple people, with a lot of experience and lot of working hours. And tested with millions of orders, products, moves and many other models. To use the Zync is implementing a standard for all your interfaces, even though they use different technology and different ways of transmission. Additionally you gain the safty, of parallel and asynchronous jobs than acknowledge each other. A documentation is in most cases entirely not needed and still can be printed, at the push of a button. 

Der zSYNC übernimmt den größten teil der Komplexität von Schnittstellen. Wer sich im zSYNC nur ein Bisschen auskennt, kennt sich in allen Schnittstellen der Firma aus und kann Support leisten. Es gibt keine Repositories zu durchsuchen, ich muss nicht Python perfekt verstehen und bevor ich die Antwort in einer Dokumentation finde, habe ich im zSYNC ein Problem schon gefunden und gelöst.

When you have a little bit of technical understanding und a little time to understand the Zync, you can build interfaces, maintain them and support them.

For a lot of cases we recommend to not just save costs but improve your resources.

With the Zync you can hire  IT apprentices and let them do the interfaces. A trainee / junior will cost less than a developer / senior, who will again cost less then external resources.

But this movement can be used to gain pace or features. When you free the expensive Developer or external you can also just be faster with all your other wishes, they can focus on your most important projects. Assure keeping deadlines, complete more features or start other projects whatever is most efficient for you. In our experience good efficient personell is more rare then money :) and normally there is no scarcity of ideas, optimizations or possibilities.  

in  the end IT aprrentice ($) < internal dev ($$) <  external dev ($$$), make the best out of it.

 of course you will have a setup time and learning curve. But as soon as you have the Zync live and the first interface is up and running, changes and additions are a matter of minutes (and very possible in live).

A typical example is: You have (at least) one big interface between two systems e.g. Shopsystem and Odoo. Because a disturbance in the connection is also a financial risk you want to avoid, you touch it as few times as possible. Over time you start to accept how it works, even if it has quirks or you have further wishes for improvement.

With the Zync, you will just add or change it. Live, if the risk and situation allows it. Without even a single second of downtime. The difference is: you just pause the cron and can add / change in very small increments and test on single entities. and yet again -> no deployment or code change. It is easiest shown in a demo.

Sounds kind of unintuitive, no?

But if you see it, you know how and why it is like this. In Essence: because you do all your interfaces in the Zync they all have a very similar look and feel. You know, in the frontend, where to look at, to find e.g. the mapping table. Yet, you can customize even the smallest bit to get the interface how you need it. There is more details to find in our videos or if you have a look around on here.

More         Videos

Don't have a big budged oder internal developer yourself?
Give us a call to install the Zync and just do it yoursef. Either with training from us or you readup yourself

Documentation.    Videos

With a very extensivly developed interface, you can change specific information in the frontend, if someone developed it. With the Sync you have the same luxury for everything all the time in every interface you have

Important income streams, assets, functionalities should never be dependent on few or a single party.

It is true for huge percentages of revenue coming from one partner and surely many other examples, but also for our example:
- If your main business is a webshop, the interface to Odoo should be in your hands and shared over multiple shoulders.

- If your WMS is assuring you deliver your customers and earn money, the interface from Odoo should be in your hands and shared over multiple shoulders.

- if you have high automatization between different systems, the interface to Odoo should be in your hands and shared over multiple shoulders.

- if you have multiple interfaces only maintainable by one person or Partner, the interface hub in Odoo should be in your hands and shared over multiple shoulders.

You get the idea. If you are a SME and used to building interfaces to 3rd parties. They should be maintainable by enough people that you are never dependent.

Because the zSYNC brings most of what an interface needs with it, in most cases we can build them faster and cheaper than normal.

Because customers can help or do it themselves, you get smaller invoices compared to pure development.

Because we can functional prove of concepts, less preparation and overhead is needed.

This is very straight forward:

Developing an interface from scratch, needs experienced personell. Developing a real solid interface, that can be smartly configured, needs even more experienced personell. Typically more experience person or scarce high skill level reflect in high costs per hour.

But if you have a tool that takes most of the complexity lowers the entry point dramatically.

If you generally understand data types and interfaces and have a few hours time, you will be able to implement in in Odoo with the zSYNC.

If all your interfaces have a similar construction, you will be able to support any interface, even some that you are seeing for the first time.

And because the zSYNC has hundrts of thousands of hours runtime and experience, you just will have less support by itself.

This is easier to show than tell, because if you experience it, you will instantly understand where to look for possible mistakes.

Similar to less support. If all your interfaces are constructed similarly. You need less documentation. What you need is a good naming system to find your pipelines. Everything else can be found from experience or the general documentation.

BUT: In a case you need documentation, you can print it at the push of a button. For example: to have someone connect to your Odoo via REST API.

Generell gilt: Je mehr Schnittstellen Sie haben, desto wichtiger sind diese für Sie und sollten intern aufgebaut, gepflegt und unterstützt werden.

Aber: Wenn Sie mit zSYNC auf einer sehr kleinen Ebene beginnen, erweitern Sie Ihre Möglichkeiten so erheblich, dass Sie in Zukunft viel schneller skalieren und viel mehr Funktionen implementieren können.

The apatite comes while eating. When you realise how easy it can be to integrate new services and interfaces, you will do more with a higher success rate.

If you already have or want a lot of APIs, this is where the zSYNC shines the most.

It is hard to put in a small text how much money can be saved, technical debt can be reduced and problems can be resolved, if all your interfaces are handled in a proven framework that can be maintained, supported and improved by anybody in your company with basic IT knowledge and a few hours time to learn the zSYNC

Customer Example: Rendite, MS AX D

When you have a bigger Odoo-Project or just many customisations in your previous system, it is not unusual that you don't want to move over to Odoo in one big bang.

If you are part of a company group where other ERP systems are present

You have a specific functionality Odoo is used for, it will not be the main ERP.

Your migration should not be done via script in only one developers hand.

There are reasons why you want to sync a current / previous / simultaneous system to Odoo. The zSYNC moves it to a very visible, controllable layer, that allows you to move the use cases you need to Odoo in the pace that is working for you.

Migrations are typically done by developers via scrips. But this puts a lot of risk / dependence / trust on very few persons. There are many cases where scripts are the best and fastes way to go about a migration. But there is equally many cases where you want your key users to help with moving the data and you need a repeatable way of testing the migration without your developers beeing hold up.

With the zSYNC you have alle your fields and data readable in your Odoo frontend and you can test run your migration at the push of a button.

Freshdesk, Jira

If Odoo is your ERP and you have a third party groupware / ticket system it is very helpful to have data, links and functions in these systems so your customer support can work faster, make less mistakes and feel more helpful when talking to customers.

The zSYNC was used to get data to tickets, so when customers call, the ticket system can look up all their orders, you see tracking info of the newest one, and a single click is enough to create a RMA, send lost invoices again and seeing similar products for better up-sale.

Example: AX Semantics

With an easy way to send data you can connect to a AI or semantic system to let it write texts for you. This makes it possible to create products and have them ready for your webshop without much manual work needed. With the zSYNC you can also import all master data needed to feed such a system.

Examples: Trusted Shops, Ecomy

a good way to improve your customer service is to provide your agents with data that helps them to help your customers. One way is import data to see useful information on the first glance. One example is customer reviews that gve you an argument of why a product is favourable. This is one thing of multiple improvements one of our customers did. You can also generate product recommendations over partner services or push shopping carts created by your customer service to the shop.

Example: Forto / Freight Hub

If you have a lot of purchases or long delivery times (like containers) there are services that help you plan the disposition, so your warehouse can handle deliveries better and you can display trustworthy restock times to your customers.

Parcellab, Seven Senders

DHL, DPD, HERMES, HES, Schenker

7 Learnings, Patagona, Clousale

Nyris

Wayfair, Zalando, Aldi Nord / Süd, Hofer, Amazon, Ebay, Otto, etc...

Image imports, interface problems, cron acceleration

Inventory, master data, prices, orders. 27 at a customer

quick order entry

RESTful API

Proxess

Odoo without Multicompany, Community and Enterprise

Email to order

Azure - manage users in one place

Azure - manage users in one place

SQL -> MSSQL, MySQL, PostgreSQL, DB2

File -> XML, XLSX, CSV, JSON, JPG, PDF, EDI, SOAP

FTP, SFTP, WebAPI, SQL query, local storage