Ошибки обмена СБИС и 1С: дубли, «не выгружается», расхождения

Типовая причина — сопоставление «по наименованию»: одна и та же позиция в СБИС и 1С названа чуть по-разному, и обмен создаёт новую карточку. Правильный порядок — жёсткие ключи (штрихкод, артикул, код), затем нормализованное имя, и только потом создание. Платформа ровно так и связывает, а спорные пары отдаёт человеку — дубль не возникает молча.

Три частых блокера: у контрагента в ЭДО нет ИНН (1С не найдёт карточку), строки документа не связаны с каталогом (нечего писать в табличную часть), не определена организация. Мы показываем прогноз ДО запуска: сколько документов поедет, сколько пропустится и почему — по каждому типу отдельным счётчиком, а не общим «что-то не загрузилось».

Внешние обработки завязаны на конкретную версию конфигурации — обновление их ломает. Облачный коннектор работает через стандартные API (OData 1С, JSON-RPC СБИС), которые стабильны между релизами; изменения API мы отслеживаем ежедневно и обновляем коннекторы сами.

Сначала остановить их источник (правильные ключи сопоставления), затем слить существующие: платформа находит кандидатов-дублей по штрихкодам/артикулам/ИНН и предлагает объединение — решение подтверждает человек, история решений сохраняется в журнале.

Да: помимо оконного опроса платформа читает ленту изменений СБИС (СписокИзменений) — правки задним числом, смены состояний и удаления в корзину доезжают до зеркала и попадают в отчёт.

Да, это режим по умолчанию: «только чтение». Платформа строит зеркало обеих систем и показывает, что и куда поедет; запись в 1С включается отдельным осознанным действием.