Продажа через Авито в 1С распадается на три разные задачи, и путаница между ними — причина большинства провалов. Первая: товары из базы должны стать объявлениями на площадке. Вторая: вопросы покупателей и оформленные заказы должны вернуться в базу. Третья: продажи должны попасть в учёт так, чтобы выручка, комиссия площадки и деньги на расчётном счёте сошлись. Их делают разными механизмами, они ломаются независимо друг от друга, и «настроить интеграцию 1С с Авито» без уточнения, о каком из трёх потоков речь, невозможно.
Я занимаюсь этим с той стороны, где виден код: у меня тиражное расширение для выгрузки товаров из типовых конфигураций 1С на Авито, и отдельные проекты, где с площадки в базу приезжают диалоги и заказы. Ниже — как устроен каждый поток, что в нём обычно ломается и во что это обходится.
Как товары из 1С попадают на Авито?
Главное, что нужно понять про выгрузку: 1С ничего никуда не отправляет. Авито сам приходит за файлом по расписанию. Вы формируете XML со всеми объявлениями, кладёте его по постоянному адресу, а в личном кабинете площадки указываете этот адрес и время забора. Дальше площадка скачивает файл, разбирает его и обновляет объявления. Механизм называется автозагрузкой, и он же используется всеми сторонними модулями — своего «API публикации объявлений» для массовой выгрузки нет.
Отсюда три следствия, которые ломают ожидания:
- Результат не мгновенный. Нажали «выгрузить» — файл обновился, но объявления изменятся только после ближайшего забора.
- Ошибки приходят с задержкой и не в 1С. Что не прошло и почему — площадка пишет в своём отчёте. Пока его никто не открывает, половина ассортимента может месяцами не выходить в поиск.
- Файл должен быть доступен снаружи. Папка на сервере 1С, куда добирается только бухгалтер по локальной сети, — не адрес для автозагрузки.
Со стороны 1С задача разбивается на четыре шага: отобрать номенклатуру, сопоставить её с классификатором площадки, собрать XML и положить файл туда, откуда его заберут. Порядок величин прикидывается просто: одно объявление — это единицы килобайт XML, поэтому каталог в несколько тысяч позиций даёт файл в десятки MB, и собирается он не мгновенно — это фоновое задание, а не действие по кнопке. Забор происходит по расписанию, которое вы сами задаёте в личном кабинете, обычно раз в сутки для полного фида. Автозагрузка при этом доступна не на всех тарифах Авито: подключение и лимиты смотрите в условиях площадки, они меняются чаще, чем формат файла.
Сама сборка файла — не самое интересное место. Штатной записи XML хватает, чтобы получить корректный документ:
ПараметрыЗаписи = Новый ПараметрыЗаписиXML("UTF-8", "1.0", Истина);
ДанныеXML = Новый ЗаписьXML;
ДанныеXML.УстановитьСтроку(ПараметрыЗаписи);
ДанныеXML.ЗаписатьНачалоЭлемента("Ads");
ДанныеXML.ЗаписатьАтрибут("formatVersion", "3");
ДанныеXML.ЗаписатьАтрибут("target", "Avito.ru");
Для Каждого Строка Из ДанныеОбъявлений Цикл
ЗаписатьОбъявление(ДанныеXML, Строка);
КонецЦикла;
ДанныеXML.ЗаписатьКонецЭлемента();
ТекстФайла = ДанныеXML.Закрыть();Интересное начинается на шаге, который в этом фрагменте спрятан за вызовом ЗаписатьОбъявление.
Почему нельзя просто выгрузить справочник номенклатуры?
Объявление на Авито — это не «наименование, цена, картинка». Каждая категория площадки требует свой набор полей, и набор этот у неё не абстрактный, а строго словарный: тип шины выбирается из списка допустимых значений, бренд акустики — из списка брендов, состояние товара — из перечисления площадки. Написали «зимняя шипованная» своими словами вместо принятого значения — объявление отклонено, хотя тег на месте и выглядит осмысленно.
Масштаб этого справочника легко недооценить. Когда я выгрузил справку Авито целиком, чтобы сверять с ней своё решение, получилось 2836 страниц категорий, у 2833 из них — шаблон с точным составом и порядком полей, а словарей допустимых значений — 2822 у 1302 категорий. Дерево категорий целиком — 3364 узла. Уникальных имён полей во всей справке 3071.
Это значит, что «сопоставление номенклатуры с Авито» — не разовая настройка на полчаса, а отдельный слой данных: категории площадки, типы товаров внутри категории, словари значений по каждому атрибуту и связь всего этого с вашими группами номенклатуры и характеристиками. В моём расширении под это отведено больше полутора сотен справочников-классификаторов — по одному на категорию плюс словари полей.
Практический вывод для тех, кто пишет выгрузку сам: не пытайтесь описать состав полей условиями в коде. Как только категорий становится больше трёх, ветвление Если Категория = … Тогда превращается в неподдерживаемое месиво. Рабочий приём — описать состав объявления декларативно (например, XDTO-пакетом на каждую категорию) и заполнять его обходом свойств, а не перечислением тегов:
// Объявление создано фабрикой XDTO по типу своей категории.
// Состав тегов задан схемой, код про конкретные поля ничего не знает.
Для Каждого Свойство Из Объявление.Свойства() Цикл
Значение = ДанныеСтроки[Свойство.Имя];
Если ЗначениеЗаполнено(Значение) Тогда
Объявление[Свойство.Имя] = ПривестиТип(Значение, Свойство.Тип.Имя);
КонецЕсли;
КонецЦикла;Здесь работает простое соглашение: имя реквизита в справочнике категории совпадает с именем тега. Добавили в категорию новое поле — оно поехало в фид само, без правки кода выгрузки. Расплата за это — тишина при рассинхроне: разошлись имена, и поле просто останется пустым, ошибки не будет.
Заголовок и описание собираются шаблоном
Наименование номенклатуры в базе — учётное: «Шина зим. ш. 205/55 R16 Nokian Hkpl R3». Для площадки нужен человеческий заголовок, а для описания — текст с характеристиками, условиями доставки и гарантией. Поэтому заголовок и описание собираются шаблоном из реквизитов, а не выгружаются как есть.
Шаблон обычно нужен не один: разные категории требуют разной подачи, а у нескольких точек продаж отличаются адреса, телефоны и сроки. Схема, которая работает, — шаблон на магазин с возможностью переопределить его на конкретной позиции, плюс список адресов внутри шаблона. Из этого, кстати, следует неочевидное: один товар при двух адресах превращается в два объявления со своими идентификаторами.
Остатки едут отдельно от объявлений
Полный фид с описаниями, характеристиками и картинками — тяжёлый файл, и пересобирать его каждый час ради изменившегося количества бессмысленно. Поэтому наличие выносят во второй, лёгкий файл: там только идентификатор объявления и остаток. Полная выгрузка идёт по расписанию раз в сутки, обновление остатков — чаще.
В 1С это два регламентных задания и одна общая точка входа. Важная деталь, о которой вспоминают после первого инцидента: выгрузку нужно защитить от параллельного запуска, иначе два задания начнут писать в один файл.
Функция ЗапуститьФоновыйОбмен() Экспорт
Отбор = Новый Структура("Ключ", "avito");
Для Каждого Задание Из ФоновыеЗадания.ПолучитьФоновыеЗадания(Отбор) Цикл
Если Задание.Состояние = СостояниеФоновогоЗадания.Активно Тогда
Возврат Истина; // выгрузка уже идёт, второй раз не запускаем
КонецЕсли;
КонецЦикла;
ФоновыеЗадания.Выполнить("ВыгрузкаНаАвито.ВыгрузитьОбъявленияВXML", , "avito");
Возврат Ложь;
КонецФункцииКуда положить файл, чтобы площадка его забрала?
Вариантов немного, и выбор обычно диктуется тем, что уже есть в инфраструктуре.
- FTP или SFTP. Самый частый вариант: сервер 1С кладёт файл на хостинг, площадка забирает по ссылке. С FTP в 1С работает штатный
FTPСоединение— ему нужны адрес, порт, логин, пароль и режим (пассивный чаще проходит через корпоративный firewall). С SFTP штатных средств нет: приходится звать внешний клиент, обычно WinSCP в консольном режиме, и держать отпечаток ключа хоста в настройках, иначе первая же попытка соединения зависнет на подтверждении. - Адрес на своём сайте. Если база уже опубликована на веб-сервере, файл удобно отдавать оттуда же. Как поднять публикацию, я разбирал в статье про публикацию 1С на веб-сервере.
- Объектное хранилище. S3-совместимое облако — самый спокойный вариант: постоянная ссылка, никакой возни с правами на папки. Как работать с S3 из кода 1С, показано в отдельной статье.
Отдельная история — картинки. Площадка тянет их по ссылкам, значит фотографии тоже должны лежать снаружи и открываться без авторизации. Присоединённые файлы, доступные только внутри базы, для этого не годятся: их нужно либо выкладывать вместе с фидом, либо хранить в том же объектном хранилище.
Что ломается на практике и почему товар не появился на Авито?
Список причин, по которым «товар не появился на Авито», короткий и почти не меняется от проекта к проекту. Важно, что рубежей три: часть позиций отсеивает ваша собственная проверка ещё до выгрузки, часть отклоняет площадка при разборе фида, а часть просто не доезжает, потому что файл недоступен.
Из этого следует практическое правило: валидируйте на своей стороне. Проверка «есть цена, есть картинка, категория сопоставлена, обязательные атрибуты заполнены» стоит один проход по данным перед записью файла, а взамен даёт отчёт со списком проблемных позиций в понятных терминах — с номенклатурой, а не с идентификаторами объявлений. Без него единственный источник правды — отчёт площадки, который отвечает с задержкой и говорит про теги.
Второй по частоте сюрприз — идентификатор объявления. Он должен быть уникальным внутри файла и постоянным между выгрузками. Если генерировать его заново при каждой выгрузке, площадка каждый раз будет снимать старое объявление и публиковать новое: обнулятся просмотры, потеряется позиция в поиске площадки, а платное продвижение придётся покупать заново.
Обратный поток: вопросы и заказы
Выгрузка — это только половина. Покупатель на Авито пишет в чат, и вопросы у него однотипные: подойдёт ли на мою машину, есть ли в наличии, какая цена, когда доставите. Живой менеджер отвечает не мгновенно и не ночью, а покупатель уходит к тому, кто ответил первым.
Технически это уже не файл, а событийный обмен: площадка присылает уведомление о новом сообщении или заказе на ваш адрес. Схема, которая держится под нагрузкой, выглядит так: уведомление принимает небольшой сервис-приёмник, сразу отвечает площадке и кладёт событие в очередь; 1С разбирает очередь фоновым заданием в своём темпе и отвечает данными из базы — реальным остатком и ценой конкретного контрагента.
Ставить площадку сразу на HTTP-сервис 1С не стоит. Закрытие месяца, блокировка, перезапуск сервера — и события начнут отваливаться по таймауту, а повторной доставки может не быть. Очередь между ними стоит дёшево и снимает весь класс проблем.
Как это выглядит в собранном виде — в кейсе про ИИ-агента продаж автозапчастей в Avito: агент отвечает в чатах, подбирает деталь по марке и модели автомобиля, проверяет наличие в 1С и доводит диалог до заказа. Про устройство таких агентов подробнее — в статье про ИИ-агента для 1С на LangGraph.
Как отразить продажи через Авито в 1С?
Самая недооценённая часть. Товары уехали, заказы пришли, а в базе продажи нет — и через квартал бухгалтер разбирается, почему остатки не сходятся, а на счёт пришло меньше, чем продано.
Первое, обо что спотыкаются: сумма, пришедшая на расчётный счёт, не равна выручке. Площадка удерживает своё — за услуги размещения, за продвижение, за доставку, если она оформлена через неё. Поэтому одной проводкой «пришли деньги» тут не обойтись, и вот почему это ломает учёт:
- если отражать только поступление, товар остаётся на остатках и снова уезжает в фид — продаёте то, чего уже нет;
- выручка занижена на сумму удержаний, а расходы на площадку не видны вообще;
- сходимость проверить нечем: непонятно, все ли отгрузки отражены.
Рабочая схема простая. Продажа отражается обычными документами отгрузки — площадка здесь не более чем канал продаж, ничего специфического в самой реализации нет. Удержания площадки заводятся отдельно, как услуги. А периодический отчёт площадки о продажах загружается в базу и сопоставляется с уже созданными заказами по идентификатору объявления — тому самому, который должен быть постоянным. Итог периода должен сходиться: отгрузки минус удержания равны поступлению.
Оговорюсь честно: конкретные счета и порядок отражения зависят от вашего режима налогообложения и учётной политики — это вопрос к бухгалтеру, а не к разработчику. Задача разработчика здесь другая: сделать так, чтобы данные для этих документов приезжали в базу автоматически и с ними можно было свериться, а не выгружались в таблицу и сверялись глазами.
Своими руками, готовый модуль или под ключ
Три честных варианта, и выбор зависит не от бюджета, а от того, сколько у вас категорий и как часто меняется ассортимент.
Писать самому имеет смысл, если категорий одна-две, ассортимент стабильный и вам нужен полный контроль над кодом. Схема выше — рабочая, повторить её реально. Закладывайте время на сопоставление словарей: код пишется за неделю, а классификаторы заполняются дольше.
Готовый модуль — когда категорий много и хочется, чтобы кто-то другой следил за изменениями формата у площадки. В нашем расширении сейчас 155 справочников-классификаторов под категории и их словари, и почти каждое обновление — это либо «Авито изменил категорию», либо «нужна новая категория». Мы поддерживаем такой модуль для типовых конфигураций: интеграция 1С с Авито для УНФ, УТ, ERP, Комплексной автоматизации, Бухгалтерии и Розницы — устанавливается расширением, типовую конфигурацию не меняет.
Разработка под ключ — если задача выходит за рамки выгрузки: свои правила ценообразования на площадке, обратный поток заказов, ответы в чатах, сведение отчётов с учётом. Это уже разработка на заказ, и начинается она с разбора того, что именно у вас должно ездить между базой и площадкой.
Если хотите разобраться в интеграциях сами и научиться собирать такие обмены — обменом с внешними системами, форматами и HTTP-сервисами мы занимаемся на курсе «Интеграция 1С».