Что происходит на самом деле

MCP (Model Context Protocol) существует в двух транспортных режимах: Streamable HTTP (новый, статeful, сессионный) и SSE (старый, Server-Sent Events). Vanessa Automation 1.2.x реализует именно SSE-транспорт — это значит, что сервер ждёт долгоживущего HTTP-соединения, через которое сам толкает события.

Claude Desktop при подключении через mcp-remote по умолчанию пытается использовать Streamable HTTP. Он делает POST /mcp для инициализации, получает session ID, а потом отправляет следующий запрос — снова POST /mcp, уже с этим session ID. Vanessa его не находит, потому что для неё сессии не существует: она ждала, что клиент откроет SSE-стрим и подпишется на события.

Результат: 404 Session not found при каждом обращении после initialize.

Правильная схема подключения

Конфигурация в claude_desktop_config.json должна выглядеть так:

{
  "mcpServers": {
    "vanessa": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://127.0.0.1:8080/mcp",
        "--transport", "sse"
      ]
    }
  }
}

Ключ — флаг --transport sse. Без него mcp-remote 0.1.x выбирает Streamable HTTP как дефолт, и именно здесь рассыпается вся цепочка.

Если Vanessa запущена на нестандартном пути, проверь endpoint: в версии 1.2.043 это /mcp, но в более ранних сборках встречался /sse. Загляни в настройки Vanessa в разделе «HTTP-сервер» — там будет точный URL.

Дополнительные причины той же ошибки

Версия mcp-remote. В 0.1.37 есть известный баг с переподключением: если SSE-соединение рвётся и клиент переподключается, новый session ID не передаётся обратно корректно. Попробуй 0.1.35 или последний snapshot из репозитория — там это починено.

Firewall и антивирус. SSE-соединение долгоживущее (минуты и часы), некоторые корпоративные фаерволы режут соединения после 30–60 секунд простоя. Vanessa при этом думает, что клиент отключился, и удаляет сессию. Клиент же при следующем запросе ссылается на уже несуществующий ID. Признак именно этой проблемы — ошибка возникает не сразу, а через некоторое время после успешного старта.

Множественные инстанции. Claude Desktop иногда запускает несколько воркеров, каждый из которых инициализирует свою сессию. Если они конкурируют за один порт — часть запросов теряется. Проверь, что Vanessa обслуживает несколько одновременных SSE-соединений (настройка «Максимальное число подключений» в HTTP-сервере).

Проверка работоспособности без Claude

Прежде чем идти дальше, убедись, что MCP-сервер в принципе работает:

curl -N http://127.0.0.1:8080/mcp/sse

Флаг -N отключает буферизацию — ты должен увидеть поток событий в терминале. Если соединение сразу закрывается или возвращает ошибку, проблема в самой Vanessa, а не в mcp-remote.

Если curl работает, а Claude Desktop — нет, вернись к конфигу. Убедись, что node и npx доступны из того пути, откуда запускается Claude Desktop (на Windows это особенно актуально: PATH в системной среде и PATH в терминале могут отличаться).

Если после всего этого ошибка не ушла — посмотри в issues репозитория modelcontextprotocol/mcp-remote. Эта связка Vanessa + Claude Desktop + mcp-remote активно используется и проблемы там отслеживаются. Часто решение уже есть в закрытых issues, просто не задокументировано в readme.

Почему Sheets API не умеет вставлять картинки напрямую

Google Sheets API v4 оперирует данными ячеек — текстом, числами, формулами. «Вставить изображение в ячейку» в смысле embedded image (то, что в браузере делается через меню «Вставка → Изображение → В ячейку») через REST API в 2026 году всё ещё официально не поддерживается. Это боль всего сообщества.

Что работает через API:

1. Функция =IMAGE(url) — вставляет изображение по публичному URL. Это не настоящий embedded image, но визуально неотличимо.
2. Floating image через batchUpdate — вставляет картинку как плавающий объект поверх ячеек (не в ячейку).

Самый практичный подход для 1С — загрузить изображение на Google Drive и вставить через =IMAGE().

Шаг 1: Получаем OAuth2-токен

Тебе нужен service account (сервисный аккаунт) в Google Cloud Console — это проще, чем OAuth2 для пользователей, потому что не требует браузерного редиректа.

Создаёшь сервисный аккаунт, скачиваешь JSON с ключом, и делишься с этим аккаунтом своим Spreadsheet («Дать доступ» → email сервисного аккаунта).

Получение токена из 1С (через JWT):

Функция ПолучитьТокенGoogleServiceAccount(ПутьКJSON)
    
    ДанныеКлюча = ЗначениеИзСтрокиJSON(ПрочитатьФайл(ПутьКJSON));
    
    // Формируем JWT
    Заголовок = БазовоеКодированиеURL(ЗаписатьJSON(Новый Структура("alg,typ", "RS256", "JWT")));
    ВремяСейчас = ТекущаяУниверсальнаяДатаВМиллисекундах() / 1000;
    
    Payload = Новый Структура();
    Payload.Вставить("iss", ДанныеКлюча["client_email"]);
    Payload.Вставить("scope", "https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/spreadsheets");
    Payload.Вставить("aud", "https://oauth2.googleapis.com/token");
    Payload.Вставить("exp", ВремяСейчас + 3600);
    Payload.Вставить("iat", ВремяСейчас);
    
    // ... подпись через RSA-SHA256 с PrivateKey из JSON ...
    // Используй компоненту подписи или готовую библиотеку с infostart
    
КонецФункции;

Подписать JWT в 1С напрямую непросто — нужна внешняя компонента или готовая библиотека. На infostart есть несколько бесплатных реализаций; ищи по «JWT 1С Google» — найдёшь рабочий код.

Шаг 2: Загружаем файл на Google Drive

Функция ЗагрузитьФайлNaDrive(Токен, ПутьКФайлу, ИмяФайла)
    
    Соединение = Новый HTTPСоединение("www.googleapis.com", 443, , , , , Новый ЗащищенноеСоединениеOpenSSL());
    
    // Multipart-запрос: метаданные + бинарные данные
    Граница = "boundary_1c_upload";
    
    ЧастьМета = "--" + Граница + Символы.ПС
        + "Content-Type: application/json; charset=UTF-8" + Символы.ПС + Символы.ПС
        + "{""name"": """ + ИмяФайла + """}" + Символы.ПС;
    
    ЧастьДанных = "--" + Граница + Символы.ПС
        + "Content-Type: image/jpeg" + Символы.ПС + Символы.ПС;
    
    Конец = Символы.ПС + "--" + Граница + "--";
    
    Заголовки = Новый Соответствие();
    Заголовки["Authorization"] = "Bearer " + Токен;
    Заголовки["Content-Type"] = "multipart/related; boundary=" + Граница;
    
    // Собираем тело запроса (бинарные данные + текст)
    // ...
    
    Запрос = Новый HTTPЗапрос("/upload/drive/v3/files?uploadType=multipart", Заголовки);
    Ответ = Соединение.ОтправитьДляПолучения(Запрос);
    
    ДанныеОтвета = ЗначениеИзСтрокиJSON(Ответ.ПолучитьТелоКакСтроку());
    Возврат ДанныеОтвета["id"]; // FileId на Drive
    
КонецФункции;

Шаг 3: Открываем доступ к файлу

Файл на Drive по умолчанию приватный. Нужно сделать его доступным по ссылке:

Процедура УстановитьПубличныйДоступ(Токен, FileId)
    
    Соединение = Новый HTTPСоединение("www.googleapis.com", 443, , , , , Новый ЗащищенноеСоединениеOpenSSL());
    
    ТелоJSON = "{""role"": ""reader"", ""type"": ""anyone""}";
    
    Заголовки = Новый Соответствие();
    Заголовки["Authorization"] = "Bearer " + Токен;
    Заголовки["Content-Type"] = "application/json";
    
    Запрос = Новый HTTPЗапрос("/drive/v3/files/" + FileId + "/permissions", Заголовки);
    Запрос.УстановитьТелоИзСтроки(ТелоJSON);
    Соединение.ОтправитьДляПолучения(Запрос); // POST
    
КонецПроцедуры;

Шаг 4: Вставляем в ячейку через Sheets API

Процедура ВставитьИзображениеВЯчейку(Токен, SpreadsheetId, Лист, Ячейка, FileId)
    
    URL = "https://lh3.googleusercontent.com/d/" + FileId;
    Формула = "=IMAGE(""" + URL + """)";
    
    ТелоJSON = "{""valueInputOption"":""USER_ENTERED"",""data"":[{""range"":""" 
        + Лист + "!" + Ячейка + """,""values"":[[""" + Формула + """]]}]}";
    
    Соединение = Новый HTTPСоединение("sheets.googleapis.com", 443, , , , , Новый ЗащищенноеСоединениеOpenSSL());
    
    Заголовки = Новый Соответствие();
    Заголовки["Authorization"] = "Bearer " + Токен;
    Заголовки["Content-Type"] = "application/json";
    
    Запрос = Новый HTTPЗапрос("/v4/spreadsheets/" + SpreadsheetId + "/values:batchUpdate", Заголовки);
    Запрос.УстановитьТелоИзСтроки(ТелоJSON);
    Соединение.ОтправитьДляПолучения(Запрос);
    
КонецПроцедуры;

URL формата lh3.googleusercontent.com/d/{FileId} — это прямая ссылка на файл в Drive, которую принимает =IMAGE().

Ограничение: =IMAGE() загружает картинку при открытии таблицы, поэтому изображения при печати и экспорте в PDF могут не отобразиться, если нет интернета. Если нужна именно embedded картинка (для печати) — придётся использовать Google Apps Script, который это делает нативно, но вызвать его из 1С можно только через веб-хук.

Корень проблемы: кто владеет объектом

Когда ты пишешь СоздатьОбъект("Word.Application"), 1С создаёт COM-объект и держит на него ссылку. Но Word как приложение имеет собственный жизненный цикл. Если ты не сделал его видимым явно, Word работает в фоновом режиме — без окна, без сообщений пользователю. При этом он всё равно может отображать диалоги (например, «Сохранить изменения?»), которые ты не видишь и не можешь закрыть.

Самое частое: код заканчивается, переменная выходит из области видимости, 1С вызывает деструктор COM-объекта — и Word закрывается, не спросив, сохранять ли документ. Если файл был открыт на запись, он или не сохранится, или сохранится в неполном состоянии.

Правильная структура кода

Перем ПриложениеWord;
Перем Документ;

Попытка
    ПриложениеWord = СоздатьОбъект("Word.Application");
    ПриложениеWord.Visible = Истина;  // показываем окно явно
    ПриложениеWord.DisplayAlerts = 0; // wdAlertsNone — убираем диалоги
    
    Документ = ПриложениеWord.Documents.Open(ПутьКФайлу);
    
    // ... работа с документом ...
    
    Документ.Save();
    Документ.Close(0); // 0 = wdDoNotSaveChanges — не спрашиваем про сохранение
    
Исключение
    Сообщить("Ошибка: " + ОписаниеОшибки());
КонецПопытки;

// Явно закрываем приложение ПОСЛЕ работы с документом
Если ПриложениеWord <> Неопределено Тогда
    ПриложениеWord.Quit();
    ПриложениеWord = Неопределено;
КонецЕсли;

Три ключевых момента: Visible = Истина (иначе Word-процесс висит невидимым и может накапливаться), DisplayAlerts = 0 (иначе документ застревает на невидимом диалоге), явный Quit() в конце (иначе процесс WINWORD.EXE остаётся в памяти).

Почему документ «мелькает» и закрывается

Это классика: Visible = Истина, но Quit() вызывается до того, как пользователь что-то сделал. Типичная структура с багом:

// НЕПРАВИЛЬНО
Word = СоздатьОбъект("Word.Application");
Word.Visible = Истина;
Документ = Word.Documents.Open(Путь);
// ... код заканчивается, Word уничтожается

Если цель — показать документ пользователю и не закрывать его немедленно, нужно либо не вызывать Quit() вообще (пользователь закрывает сам), либо дождаться закрытия через цикл проверки:

// Ждём, пока пользователь закроет документ
Пока ПриложениеWord.Documents.Count > 0 Цикл
    ОбработкаПрерыванияПользователя();
КонецЦикла;

Скрытые диалоги — самая коварная проблема

DisplayAlerts = 0 убирает большинство диалогов Word, но не все. Диалог «Файл заблокирован другим пользователем» или «Документ содержит макросы» может всё равно появиться. На сервере это катастрофа: WINWORD.EXE висит и ждёт клика, которого никогда не будет.

Для серверной автоматизации (фоновые задания, регламентные операции) COM-автоматизация Word — плохой выбор. Используй вместо этого:

• OpenDocumentFormat через пакет XML — 1С умеет работать с .docx как с ZIP напрямую, без Word
• Шаблоны с заполнением через XML — надёжнее и быстрее в 10 раз
• Сторонние компоненты типа Aspose.Words или LibreOffice в headless-режиме

Если без COM не обойтись (например, сложное форматирование или макросы), запускай его только в клиентском коде, а на сервере никогда.

Если проблема не воспроизводится у тебя локально, но ломается на сервере — проверь, под каким пользователем запущен агент сервера 1С: COM-объекты Word требуют, чтобы у пользователя была настроена интерактивная сессия Windows. Сервисный аккаунт без профиля просто не умеет запускать Word.

Когда статья без единой строчки кода собирает 158 комментариев за пять дней, это не просто хороший контент. Это диагноз.

«OneBase и open-source решения в 1C-разработке» — публикация, которая взорвала ленту infostart.ru в конце мая, посвящена проекту на Go с 1С-подобным синтаксисом. YAML-конфигурации вместо XML-дампов. SQLite или PostgreSQL по выбору. Бинарник в двадцать мегабайт. Работает на Raspberry Pi. Кто-то взял и написал альтернативную платформу — не для того чтобы заменить 1С в корпоративном секторе, а чтобы просто попробовать иначе.

Комментарии разделились ровно так, как делятся всегда, когда задет нерв. Starik-2005 трезво заметил: «Бизнес-логика генерирует трудности — то, что просто в 1С, может быть сложнее здесь». Dmpas возразил: «Низкокодовые платформы справляются быстрее, чем стандартный подход 1С». Спор не закончился — он перетёк в следующий пост, потом в следующий. Сто пятьдесят восемь человек пришли поговорить не про OneBase — они пришли поговорить про то, почему им тесно там, где они работают каждый день.

Это первое, что нужно понять про майский срез infostart.ru: за техническими дискуссиями стоит один и тот же подтекст. Сообщество медленно, но верно конструирует инструментарий, который платформа так и не дала.

Второй сигнал — в статьях про AI. Их в топе семь штук, и только ленивый не написал про ChatGPT или Claude в контексте 1С. Но читаешь комментарии — и понимаешь, что интерес неоднородный. Andrew.ab описывает рабочий процесс: «MCP-агенты для анализа метаданных, IDE Cursor с GLM 4.7» — и это звучит не как эксперимент, а как продакшн-workflow. Человек не пользуется конфигуратором для навигации по коду. Он открыл Cursor, подключил языковую модель — и всё заработало лучше.

Kozusenok идёт ещё дальше: «Gemma 4 26B через LM Studio работает с производительностью 7-11 токенов в секунду» на обычном железе без интернета. Ноль подписок. Ноль телеметрии. Полная автономность. Это не гик-развлечение — это ответ на вопрос «что делать с NDA и закрытым кодом клиента», который в другой ветке собрал семьдесят восемь комментариев сам по себе.

Ibrogim, который, кстати, тот самый автор OneBase, в дискуссии про AI написал просто: «Claude и GPT за двадцать долларов в месяц покрывают разные сценарии». Для архитектурных решений — Claude. Для рутины — что подешевле. Практичная, немного усталая формула человека, который давно перестал ждать встроенных инструментов от вендора.

Вот в чём парадокс, который я не могу не назвать своими словами. Мы обсуждаем AI не потому что AI — это захватывающий новый мир. Мы обсуждаем AI потому что он закрывает дыры. Language server для BSL — сообщество. Фреймворк для unit-тестирования YAxUnit — сообщество. Нормальная работа с рефакторингом в большом проекте — через Cursor и языковую модель, то есть опять сообщество плюс сторонний инструмент. В 2026 году Docker-статья по-прежнему бьёт шестьдесят пять комментариев, потому что контейнеризация 1С-сервера для части аудитории всё ещё открытие.

Я не говорю это как упрёк платформе — я говорю это как наблюдение про сообщество. То, что происходит сейчас на infostart.ru, это экосистема, которая взрослеет. Люди перестали ждать. Они берут Go, пишут альтернативную платформу, выкладывают в open-source и получают сто пятьдесят восемь комментариев. Они подключают MCP-сервер к конфигуратору метаданных и автоматизируют то, на что раньше уходили дни. Они запускают двадцатишестимиллиардную модель локально, потому что не хотят отправлять код клиента в облако.

Это не хаос. Это не разбегание в разные стороны. Это — методом проб — складывается новый профиль профессии. Называть его «1С-разработчик» уже немного неточно. Скорее — инженер, который умеет на 1С, но не ограничен ею.

Тренд номер один по майскому срезу — AI-инструменты (trend_score 390 против 76 у DevOps и столько же у инструментария). Но если смотреть честно, это не сигнал про AI. Это сигнал про инструментальный голод, который наконец начали утолять — и не сверху вниз, а снизу вверх.

Один вопрос, который я оставлю без ответа, потому что он стоит того, чтобы ответить самостоятельно: если вы уже работаете в Cursor, запускаете локальные модели, пишете тесты на YAxUnit и деплоите через Docker — что именно в вашем рабочем дне остаётся специфично «1С»? И вас это устраивает или нет?

Почему стандартный dt-бэкап не работает при нагрузке

Выгрузка в .dt делает логическую копию: блокирует базу, читает все объекты, сериализует. При базе больше 20–30 ГБ это занимает часы. Пользователи не могут работать. На файловой базе это вообще единственный способ, но файловая база при высокой нагрузке — это уже само по себе архитектурная проблема.

Для клиент-серверного варианта (SQL Server или PostgreSQL) правильный ответ — бэкап на уровне СУБД, а не через инструменты 1С.

SQL Server: три уровня защиты

Full backup — полная копия, база онлайн, пользователи работают. SQL Server использует теневое копирование, и для базы 200 ГБ это занимает 20–40 минут в зависимости от диска. Делай раз в сутки, ночью.

BACKUP DATABASE [my_1c_base] 
TO DISK = N'D:\Backups\my_1c_base_full.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;

Differential backup — только изменения с последнего full. Размер и время: 5–15% от full. Делай каждые 2–4 часа.

Log backup — бэкап журнала транзакций, при модели восстановления FULL. Позволяет восстановить базу на любой момент времени. Делай каждые 15–30 минут. Это ключ к точечному восстановлению (point-in-time recovery).

-- Переключи модель восстановления, если ещё SIMPLE
ALTER DATABASE [my_1c_base] SET RECOVERY FULL;

-- Регулярный бэкап лога
BACKUP LOG [my_1c_base]
TO DISK = N'D:\Backups\my_1c_base_log.bak'
WITH COMPRESSION;

Все три типа бэкапа SQL Server делает без остановки работы пользователей. Именно поэтому клиент-серверный вариант — единственный правильный выбор для нагруженной базы.

PostgreSQL: аналогичная схема

Для PostgreSQL-варианта:

# Физический бэкап через pg_basebackup (онлайн, без остановки)
pg_basebackup -D /backup/base -Ft -z -P -Xs -c fast

# WAL-архивирование для point-in-time recovery
# В postgresql.conf:
archive_mode = on
archive_command = 'cp %p /backup/wal/%f'
wal_level = replica

pg_basebackup создаёт консистентный снимок работающей базы. WAL-архивирование — аналог log backup в SQL Server.

Автоматизация и контроль

Бэкап без проверки — это не бэкап. Два обязательных элемента:

Проверка целостности. SQL Server:

RESTORE VERIFYONLY FROM DISK = N'D:\Backups\my_1c_base_full.bak'
WITH CHECKSUM;

Добавь в расписание сразу после каждого бэкапа.

Тестовое восстановление. Раз в месяц разворачивай бэкап на отдельный сервер и проверяй, что 1С запускается и данные на месте. Без этого ты не знаешь, работает ли твоя схема.

Мониторинг. Создай SQL Agent Job для каждого типа бэкапа и настрой уведомления на провал. Стандартная ошибка — «бэкапы работали полгода, потом диск заполнился, скрипт начал падать, никто не заметил».

Когда нужен Always On или зеркалирование

Если требование — восстановление за минуты (RTO < 5 мин) или потеря данных не более 1 минуты (RPO < 1 мин) — бэкапы не спасут. Нужен SQL Server Always On Availability Groups или репликация PostgreSQL. Это отдельная тема, но знай: Always On — это не замена бэкапам, это добавление к ним.

Если ты на файловом варианте и думаешь «а вдруг и так сойдёт» — переходи на клиент-серверный при первой возможности. Это не просто удобство, это базовая гигиена для любой базы, где работает больше 10 человек. Файловый вариант при нагрузке теряет данные тихо и необратимо.

Если проблема с конкретной реализацией бэкапа на SQL Server — покажи план обслуживания или скрипты, и сообщество поможет. Обычно ошибки прячутся в правах доступа к папке бэкапа или в переполнении диска.

Как WB идентифицирует товары

У Wildberries есть три разных понятия, которые легко перепутать:

nmId (числовой, например 296729549) — это ID номенклатуры WB, уникальный в рамках всей платформы. Назначается WB автоматически при создании карточки. Менять нельзя, исчезает при удалении карточки.

vendorCode (строковый, например MY-SKU-001) — это твой артикул, который ты сам задаёшь при создании карточки. Это единственный идентификатор, который ты контролируешь и который должен совпадать с артикулом в 1С.

barcode — штрихкод, может быть несколько на одну позицию.

Золотое правило: матчить 1С ↔ WB нужно по vendorCode. Это поле ты заполнял сам при создании карточки — оно и должно совпадать с полем «Артикул» в номенклатуре 1С.

Получение списка товаров с WB через API v3

API Wildberries v3 — актуальная версия на 2026 год. V2 устарел.

Функция ПолучитьТоварыWB(Токен)
    
    НТТР = Новый HTTPСоединение("suppliers-api.wildberries.ru", 443, , , , , Новый ЗащищенноеСоединениеOpenSSL());
    
    Заголовки = Новый Соответствие();
    Заголовки["Authorization"] = Токен;
    Заголовки["Content-Type"] = "application/json";
    
    Тело = Новый Структура();
    Тело.Вставить("settings", Новый Структура(
        "cursor,filter",
        Новый Структура("limit", 1000),
        Новый Структура("withPhoto", -1)
    ));
    
    Запрос = Новый HTTPЗапрос("/content/v2/get/cards/list", Заголовки);
    Запрос.УстановитьТелоИзСтроки(Формат(ЗначениеВСтрокуJSON(Тело)));
    
    Ответ = НТТР.ОтправитьДляПолучения(Запрос);
    
    Если Ответ.КодСостояния = 200 Тогда
        Возврат ЗначениеИзСтрокиJSON(Ответ.ПолучитьТелоКакСтроку());
    КонецЕсли;
    
    Возврат Неопределено;

КонецФункции;

В ответе ищи поле vendorCode в каждой карточке — это и есть твой артикул для матчинга.

Стратегия синхронизации: три сценария

Сценарий 1: Первичная загрузка (1С → WB) Берёшь номенклатуру из 1С, создаёшь карточки на WB через POST /content/v2/cards/upload. В качестве vendorCode подставляешь артикул из 1С. После создания WB вернёт nmId — его нужно сохранить в дополнительных реквизитах номенклатуры.

Сценарий 2: Обновление остатков и цен (1С → WB) Для остатков: PUT /api/v3/stocks/{warehouseId} — принимает массив {sku, amount}. sku здесь — это barcode, не vendorCode! Нужно заранее получить маппинг barcode ↔ vendorCode. Для цен: POST /public/api/v1/prices — принимает {nmId, price, discount}.

Сценарий 3: Обратная синхронизация (WB → 1С) Продажи, возвраты, штрафы приходят через GET /api/v3/supplier/orders. В заказе есть article — это vendorCode. По нему находишь номенклатуру в 1С и создаёшь документы.

Хранение связей в 1С

Не храни nmId в коде — выноси в справочник или дополнительные реквизиты:

Справочник.НоменклатураWB:
  Номенклатура (ссылка на Номенклатуру)
  nmId (число)
  vendorCode (строка)
  Артикул_WB (строка — barcode для остатков)
  ДатаПоследнейСинхронизации

Если у тебя уже есть товары на WB и ты создаёшь 1С сбоку, первый шаг — выгрузи весь каталог WB, пройди по vendorCode и сопоставь с 1С вручную или через загрузку в промежуточную таблицу.

Если что-то не сматчилось — не паникуй. WB позволяет отредактировать vendorCode через API (POST /content/v2/cards/update), но делать это надо осторожно: изменение vendorCode не меняет nmId, но может сломать существующие интеграции.

Когда матчинг налажен, дальнейшая синхронизация — это уже технические детали. Главный источник боли именно здесь, в первичной связке идентификаторов. Если проблема осталась, посмотри в сторону готовых коннекторов: «1С-Битрикс: Маркетплейс» и несколько сторонних разработок на infostart имеют рабочие реализации этой логики.