Стандартно, за да бъде синхронизиран даден документ с друг ком модул, различен от този, в който е създаден, трябва в конфигурацията на общите обекти за синхронизиране, да е настроена поне една от двойките обект/контрагент за източник/посредник/получател от документа да съвпада с настройката на синхронизацията.
Когато се работи с много обекти, включително клиентски и т.н., поддържането на тази конфигурация е много трудно. В резултат, може да се окаже, че централната база не съдържа всичко, което се съдържа по ком модулите и това би могло да е предпоставка за загуба на данни.

Въвеждането на Собственик и Обект НЕ е задължително. В този случай се приема, че ком модула се интересува от всички собственици и техните обекти. За да може те да се синхронизират в таблицата за настройки на ком модулите е достатъчно да се въведе един ред за ком модула, без да се задава собственик и обект.
Възможно е да попълните и само Собственик, тогава пак ще се имат предвид всички обекти на собственика. При наличие на съществуващи записи, ако се създават нови обекти, към съществуващите редове в таблицата за настройки на ком модулите се добавя един ред с посочен ком модула, който ще се интересува и от новите обекти.

При свързване към базата данни на ЕРП системата се извършва проверка в ехе-то, дали има създадени връзки за осъществяване на синхронизация, съответно и синхронизационни тригери. При липса на такива тригери свързването към базата данни не е разрешено. Тази ситуация налага намеса на отдел Поддръжка.

Ако в груповите политики са попълнени Други/Мониторинг на синхронизацията/URL и порт - тогава чрез TCPClient се извиква метода на сървиса за стартиране на синхронизация.

Статусът на нишките за евенти не се показва, тъй като визуализирането им причинява не обновяване на статуса им в синхронизационния клиент, ако при изпълнение на синхронизацията някои ком модули са били спрени или с грешка при стартиране на синхронизационния сървис.
Това изисква смяна на синхронизационния сървис в релийзи след 2016.12 включително.

При работа със синхронизация е важно да се осигури правилното й функциониране, което включва и защита от това, да се изпълни един лог два пъти.

Ако се стартират два сървиса върху една и съща база и има настройка за „онлайн“ синхронизация, е възможно и двата сървиса да се опитат по едно и също време да изпълнят един и същ лог, което може да доведе до множество грешки.
Поради тази причина е реализирана защита да не може да се стартират два синхронизационни сървиса в една база.

В приложението за настройка на синхронизацията (Конфигурация на синхронизацията/Конфигурация) е има поле „Hash на синхр.сървис“. Ако има стартиран сървис това поле се попълва и при втори опит за пускане на друг сървис се прави проверка има ли данни в него. Ако то в попълнено не се разрешава стартирането на втори сървис.

В практиката при наличие на синхронизация се случва да се получават грешки (изключение са ситуациите, когато няма връзка с дадена база) и тъй като от страна на клиента никой не наблюдава постоянно дали всичко се синхронизира успешно, обикновено те се разбират на по-късен етап, когато е необходима спешно намеса на отдел Поддръжка.

Поради тази причина, за да може да се оправя синхронизацията своевременно без намесата на потребителя и още преди той да е разбрал, че има някакъв проблем, е реализирана възможност за автоматично известяване за проблем чрез изпращане на e-mail.
На база e-mail-а директно се създава задача в JIRA за грешката в изпълнението на лога.

За прилагане на e-mail известяването в конфигуриращото екзе на синхронизационния сървис (ERPSyncServiceConfig.exe) са налични полета за пощенски сървър, порт, адреси (e-mail -и) на изпращача (с парола) и получателя/ите.

При изпращане на e-mail-ите не се дублират съобщенията за една и съща грешка. Сървисът създава до себе си файл с име като неговото и разширение .log и в него записва за кои номера на лог е изпратил писма.
По този начин се гарантира, че за дадена грешка се изпраща мейл само веднъж.

При наличие на синхронизация, е реализирана възможност да се задава подразбираща се стойност за Приоритет на лог.
Това не се прави ръчно, а автоматизирано с къстамизация.

Настройването на подобен приоритет се извършва много внимателно, особено на таблици, които зависят една от друга - трябва винаги да се задава еднакъв приоритет на всички таблици в логическата група, иначе може да се получи разместване на синхронизационния лог.
Например таблиците за себестойност и СДЦ трябва винаги да имат еднакъв приоритет, за да се попълват в правилния ред. Същото важи и за таблиците, които формират ТД също - хедър, детайли, серийни номера, снапшот и т.н.

Стандартно, при създаване на лог за GDPR от ком модулите се създава заявка за лога, която да се изпрати в централата, за да може целия GDPR да е налице само в централата.
Ако по време на синхронизацията обаче прекъсне връзката е възможно записът в лога да се запише и последствие да се опита отново да предаде лога, което води до грешка в синхронизацията.
За целта е направена промяна в процедурата за създаване на лог да не е само при вмъкване (insert into), а и при ъпдейт (update).

Вижте още: Синхронизация на данни - технология, конфигурация, мониторинг; Мониторинг на синхронизация - основни положения; Групови политики/Други - при вграден Мониторинг на синхронизацията;