Хорошая цепочка: CMS кидает заказы в 1С, а AMO уже “догоняет” статусы. Самое частое узкое место при 4 складах чтобы остатки/резервы в CMS были актуальны и не было “продали то, чего нет”. У вас остатки в CMS обновляются сразу по событиям или раз в N минут выгрузкой? 😄

Такая цепочка и есть.

По событиям. У нас вообще синхронизация по остаткам через микросервис происходит в фоновом режиме. Поэтому не бывает ситуации, когда купили то, чего нет.

Если будет 1, то булет монополия, а это никому не нужно, тк гибкость будет минимальна А так каждый выбирает себе по «душе»

Екатерина, вы как 1С-спец знаете: беда не в двух системах, а в том, что не определили “кто главный” и не мониторят обмен - отсюда дубли и бардак =)

Мастер-система должна определяться первично, настройки обменов уже вторичны и будет всем счастье 🙂 Если запустили и такие «ой», то печаль беда, а программы (и их разработчики) виноваты

Мастер-система это база 👍 настройки обмена “вторичны”, но без них счастье редко наступает: как минимум нужны правила мэппинга и защита от дублей/повторной отправки, иначе мастер начнёт плыть от ошибок интеграции

А вот “виноваты разработчики” частично: чаще всего виноват отсутствующий владелец данных и регламент контроля. У вас в проектах мастер-системой обычно 1С выбирают или срмку?

Повторная отправка хорошая штука, она необходима, как минимум снижает вероятность НЕ загрузки данных, а вот защита от дублей, это да, «это база»😅

Мастер в зависимости от данных, скорее 40/60 из того с чем конкретно я сталкиваюсь ежедневно 40 - срм, 60 - 1С И все это в непрерывных обменах между срм - 1с , 1с-1с (разрых конфигураций), 1с-срм Есть даже более сложные схемы срм - 1с - 1с - срм - 1с

Повторная отправка ок, но важно, чтобы система умела “не принять второй раз”, иначе будут дубли :) что чаще ломается в обмене данных?

Как раз проверка на дубли или сверка данных (например соответствие КА и договора), ожидание ответа от другой МС которая также ждет ответ, если где-то затык (ождание) или ошибка, то очереди могут скопиться колосальные… В нашем случае пришли к золотому UID что минимизирует (исключает) дубли, тк во всех системах по нему можно проверить данные, но исключения как и везде иногда случаются и это в 95% человеческий фактор по итогу

что-то внесли руками или случайно жмакнули не туда

🔥 про “золотой UID” это реально спасает очереди и дубли. А “взаимное ожидание” лечится просто: асинхронно + таймауты/ретраи, без блокировок

У вас чаще косяк от ручных правок в 1С или в CRM?

Наши прекрасные разработчики разные обменя по разному настраивают, как раз для более точечной выборки «взаимных ожиданий» где-то обмены встают, где-то пропускаются ошибки и ждут разбора, тут уже индивидуальный подход )

Косяки и там и там бывают, в равном количестве, но как и везде два лагеря: 1С и говорим, что со сторны срм больше Срм и говорят, что у нас больше

Получается имеем один дом на два хозяина. Тут вступает «у соседа всегда вкуснее», но в интерпретации «сосед всегда косячит» (это если рассматривать только команды разработки и поддержки) А вот соседний дом вообще плохой (пользователь), «траву у дома соком поливает, а не водой» потому что может вообще не понимать,что он делает

Повторная отправка на самом деле нужная вещь. Ситуации бывают - сервер недоступен и заказ не прилетел/не улетел. Или обновление по нему.