Интеграция 1С:Бухгалтерия с интернет-магазином

Заказы на сайте оформляются, деньги приходят, товар уезжает покупателю — а бухгалтер в конце месяца вручную заводит десятки реализаций, сверяет оплаты по выписке и ищет, почему сумма по сайту не сходится с суммой в учёте. Пока заказов немного, это терпимо. Как только интернет-магазин выходит на сотни отгрузок в месяц, ручной перенос данных превращается в источник ошибок, задвоенных документов и вечных расхождений по взаиморасчётам. Решение — интеграция сайта на 1С-Битрикс с 1С:Бухгалтерией, при которой реализации, оплаты и первичные документы попадают в учёт автоматически.

Ниже — практический разбор того, как устроен такой обмен: чем Бухгалтерия отличается от торговой конфигурации, какие данные и в какую сторону передавать, как заказ превращается в документ реализации и как свести оплаты с отгрузками без ручной работы. Это выжимка из наших проектов по интеграции 1С с сайтами на Битрикс — без теории ради теории, с прицелом на реальный учёт.

Зачем связывать сайт с 1С:Бухгалтерией

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

Что это даёт бизнесу на практике. Во-первых, скорость закрытия периода: реализации формируются по мере поступления заказов, а не авралом в последние дни месяца. Во-вторых, снижение числа ошибок — человек, вбивающий сто документов подряд, неизбежно ошибается в суммах, номенклатуре и реквизитах, а обмен переносит ровно те данные, что были на сайте. В-третьих, прозрачность взаиморасчётов: видно, какие заказы оплачены, какие отгружены, где висит дебиторская задолженность. В-четвёртых, готовность к проверкам: первичные документы формируются единообразно и хранятся в учётной системе, а не в переписке менеджеров.

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

Бухгалтерия против торговой конфигурации: кто чем занят

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

• 1С:Бухгалтерия. Ведёт регламентированный учёт: проводки, НДС, налоги, первичные документы, отчётность в госорганы. Её сильная сторона — корректный бухгалтерский и налоговый учёт, а не управление ассортиментом и остатками в реальном времени.
• 1С:Управление торговлей (УТ). Ведёт оперативный торговый учёт: номенклатура, цены, склады, резервы, заказы покупателей, взаиморасчёты. Именно она обычно двусторонне обменивается с сайтом товарами и заказами.
• 1С:УНФ (Управление нашей фирмой). Совмещает упрощённый учёт и торговлю для малого бизнеса. Про её связку с сайтом мы писали в отдельном материале — интеграция 1С-Битрикс с 1С:УНФ.
• 1С:ERP. Комплексное решение для крупного бизнеса, где торговый и производственный контуры объединены с расширенным учётом.

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

Мы подробно разбираем классический двусторонний обмен в статье про интеграцию интернет-магазина с 1С по CommerceML — там речь о выгрузке товаров, цен, остатков и заказов. Настоящий материал сфокусирован на другой части картины: как довести данные заказа до бухгалтерских документов реализации и оплаты.

Мастер данных: главный вопрос интеграции

Прежде чем настраивать хоть один обмен, ответьте на вопрос: какая система является источником истины (мастером) по каждому виду данных? Это не техническая мелочь, а фундамент всей интеграции. Если по одному и тому же справочнику мастера два, данные неизбежно разъедутся, и вы будете вечно бороться с последствиями, а не с причиной.

Разберём типовое распределение ролей для связки с Бухгалтерией:

Ключевое правило: у каждой строки таблицы ровно один мастер. Данные, по которым система является мастером, в ней и редактируются, а во всех остальных местах доступны только на чтение или приходят обменом. Как только вы разрешаете править остатки и на сайте, и в 1С, вы получаете гонку: чьё изменение придёт последним, то и «победит», причём в самый неподходящий момент.

Что именно обмениваем: реализации, оплаты, документы

В контексте Бухгалтерии интеграция с сайтом сводится к трём потокам данных, каждый из которых стоит спроектировать отдельно.

Реализации. Это отражение факта продажи: покупатель оформил заказ, товар или услуга ему переданы, значит в учёте должна появиться реализация товаров и услуг с корректной номенклатурой, количеством, ценами и суммой НДС. Источник — заказ на сайте. Задача обмена — довести заказ до документа реализации, привязать его к контрагенту и договору, провести и вернуть на сайт признак, что документ проведён.

Оплаты. Это движение денег: поступление на расчётный счёт по эквайрингу и безналу или в кассу по наличным. Источник факта оплаты — банк или платёжная система, а не сайт. Сайт лишь фиксирует, что платёж инициирован и подтверждён провайдером. Задача обмена — свести конкретную оплату с конкретной реализацией по ключу заказа, чтобы взаиморасчёты сходились.

Документы. Это первичка, которую нужно отдать покупателю или предъявить проверяющим: счёт на оплату, счёт-фактура, УПД (универсальный передаточный документ), акт для услуг. Часть документов формируется в 1С на основании реализации, часть покупатель хочет видеть в личном кабинете на сайте. Задача обмена — сформировать документы в учёте и при необходимости отдать их печатные формы обратно на сайт.

Обратите внимание, что документооборот с электронными подписями (УПД через операторов ЭДО) — это отдельный контур со своими требованиями. Если вам нужен именно юридически значимый электронный документооборот с контрагентами, посмотрите наш разбор по теме — интеграция ЭДО (Диадок, СБИС) с магазином на Битрикс. Здесь же речь о бухгалтерском формировании документов, а не об их отправке через оператора.

Архитектура обмена: прямая связка и через торговую систему

Есть два принципиально разных способа завести данные сайта в 1С:Бухгалтерию, и выбор между ними определяет весь проект.

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

Вариант Б — обмен через торговую систему. Сайт двусторонне обменивается с 1С:УТ или ERP (товары, цены, остатки, заказы), а торговая система по внутреннему механизму 1С передаёт документы в Бухгалтерию. Плюсы: каждая система занята своим делом, склад и торговля работают корректно, бухгалтерия получает уже выверенные документы. Минусы: больше звеньев, чуть сложнее в настройке и сопровождении.

На практике выбор диктуется тем, что уже есть у бизнеса. Если торговая 1С внедрена — почти всегда правильнее вариант Б, и сайт вообще не должен знать о существовании Бухгалтерии. Если торговой системы нет и не планируется, а продажи простые — уместен вариант А. Отдельно стоит помнить про надёжность канала: любой обмен с внешней системой должен быть устойчив к сбоям, ретраям и дублям. Мы подробно разбираем это в статье про очереди и надёжность интеграций на Битрикс.

CommerceML и штатный модуль обмена

Технической основой обмена в экосистеме 1С-Битрикс служит протокол CommerceML — открытый XML-формат, которым обмениваются сайт и 1С. За обмен на стороне сайта отвечает штатный модуль «Веб-аналитика»/«Интернет-магазин» и его механизм обмена с 1С, доступный по служебному адресу вида /bitrix/admin/1c_exchange.php. С этим адресом соединяется обработка обмена внутри конфигурации 1С.

В части, которая касается Бухгалтерии, работает та же механика, что и при обмене заказами с торговой системой:

• Выгрузка каталога (import). Из 1С на сайт приходят товары, свойства, цены и остатки в формате CommerceML. Для прямой связки с Бухгалтерией этот поток часто минимален или отсутствует — каталог ведётся на сайте.
• Выгрузка заказов (sale). С сайта в 1С уходят заказы (документы Документ с реквизитами покупателя, составом и суммами). Именно они становятся основанием реализаций.
• Возврат статусов. Из 1С на сайт возвращаются изменения по заказам: проведён документ, оплачен, отгружен, присвоен номер.

Связь конкретного заказа сайта и документа в 1С держится по внешнему идентификатору. На стороне Битрикса это, как правило, XML_ID/ACCOUNT_NUMBER заказа, а в 1С — соответствующий реквизит документа. Один и тот же ключ прописывается в обе стороны, и именно по нему обмен понимает, что «этот заказ уже выгружен, второй раз документ создавать не нужно, надо только обновить». Потеря или дублирование этого ключа — причина номер один задвоенных реализаций.

Стоит отдельно оговорить формат и кодировки. CommerceML чувствителен к структуре XML, кодировке (обычно UTF-8 или Windows-1251 в зависимости от настроек), корректности дат и разделителей сумм. Львиная доля «непонятных» ошибок обмена — это на самом деле некорректно сформированный или обрезанный XML, слишком большой пакет, упавший по таймауту, либо несоответствие версий протокола между сайтом и конфигурацией.

Реализации: как заказ становится документом в 1С

Разберём жизненный цикл одной продажи от клика на сайте до проведённой реализации в Бухгалтерии. Это ядро всей интеграции, и понимание последовательности снимает большинство вопросов.

1. Заказ оформлен на сайте. Покупатель прошёл оформление, заказу присвоен номер, зафиксированы состав, цены, покупатель и способ оплаты. Заказ получает статус, при котором он готов к выгрузке.
2. Заказ выгружен в 1С. При очередном сеансе обмена сайт отдаёт заказ в CommerceML. В 1С появляется документ-основание с внешним ключом, равным номеру заказа сайта.
3. Сопоставлена номенклатура. Позиции заказа связываются с номенклатурой 1С по коду/артикулу. Если товар в Бухгалтерии не найден, срабатывает правило: создать номенклатуру или отложить документ до ручного сопоставления.
4. Определён контрагент. Для розницы это может быть обобщённый «Розничный покупатель», для B2B — конкретный контрагент по ИНН с договором. Правильный подбор контрагента критичен для взаиморасчётов.
5. Создана реализация. На основании документа-заказа формируется реализация товаров и услуг с корректными ценами, ставками НДС и суммами.
6. Реализация проведена. При проведении формируются проводки, движения по регистрам, при необходимости — счёт-фактура. Проведение может быть автоматическим или ручным — по политике учёта.
7. Статус возвращён на сайт. Обмен передаёт обратно, что документ проведён (и, например, ему присвоен номер), чтобы менеджер на сайте видел актуальное состояние.

Ключевой архитектурный момент — что считать триггером создания реализации. Возможны два подхода. Первый: реализация создаётся сразу при выгрузке заказа, ещё до фактической отгрузки, — удобно для предоплатных схем. Второй: реализация создаётся только когда заказ перешёл в статус «отгружен», — корректнее отражает момент перехода права собственности. Выбор зависит от учётной политики и должен быть согласован с бухгалтерией, а не выбран разработчиком «как проще».

Оплаты: сведение денег и отгрузок

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

Рассмотрим типичные сценарии оплаты и то, как они отражаются в учёте:

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

Независимо от подхода, действует железное правило: оплата и реализация связываются по одному и тому же ключу заказа. Если оплата разнесена на «Розничного покупателя», а реализация — на конкретного контрагента, взаиморасчёты не сойдутся, и по обоим повиснут «висячие» суммы. Для B2B-схем, где важны договоры и дебиторка, это особенно критично. Про построение личного кабинета с историей заказов и документов для оптовых клиентов мы пишем в разделе про B2B-порталы.

Документы: счета, счета-фактуры, УПД

Третий поток интеграции — первичные документы. Покупатель, особенно юридическое лицо, хочет получить счёт на оплату до перечисления денег и закрывающие документы после. Бухгалтерия должна эти документы сформировать корректно, а сайт — при необходимости показать их в личном кабинете.

Основные документы и логика их появления:

• Счёт на оплату. Формируется для безналичной B2B-оплаты. Может создаваться как на сайте (по шаблону), так и в 1С. Если счёт создаётся в Бухгалтерии, его печатную форму удобно вернуть на сайт в личный кабинет клиента.
• Счёт-фактура. Выписывается на основании реализации при работе с НДС. Формируется в 1С автоматически при проведении реализации, если так настроена учётная политика.
• УПД. Универсальный передаточный документ объединяет накладную и счёт-фактуру. Удобен для отгрузок, формируется в 1С на основании реализации.
• Акт выполненных работ. Для услуг вместо накладной. Тоже создаётся на основании реализации услуг.

Практически важно определить, где документ «живёт» и где его видит покупатель. Часто оптимальна такая схема: документы формируются и хранятся в 1С:Бухгалтерии как в системе учёта, а на сайт возвращаются их печатные формы (PDF) для скачивания в личном кабинете. Так бухгалтерия сохраняет полный контроль над первичкой, а клиент получает самообслуживание без обращения к менеджеру. Отправка юридически значимых электронных версий через оператора ЭДО — это уже отдельный контур, о котором мы говорили выше.

НДС, договоры и статьи учёта

Дьявол интеграции с Бухгалтерией — в реквизитах, без которых документ формально создаётся, но учётно неверен. Даже безупречно переданный заказ станет источником проблем, если в нём не хватает бухгалтерских атрибутов.

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

Договоры. Для B2B-продаж реализация и оплата привязываются к договору с контрагентом. Если договор не определён или подставляется «по умолчанию» не тот, взаиморасчёты ведутся некорректно. Сайт для этого должен уметь связывать заказ B2B-клиента с его контрагентом и договором в 1С.

Организация и склад. Если у компании несколько юрлиц или складов, каждый заказ должен нести признак, от какой организации и с какого склада идёт отгрузка. Иначе документы «свалятся» в одну организацию, и разнести их потом крайне трудоёмко.

Статьи ДДС и учёта. Продвинутые схемы требуют указания статьи движения денежных средств для оплат и аналитики для реализаций. Это уже настройка на стороне правил обмена в 1С, а не на сайте.

Настройка обмена пошагово

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

1. Зафиксируйте мастеров данных. Составьте таблицу «вид данных → мастер → получатель» и согласуйте её с бухгалтерией и коммерцией. Это фундамент, без него дальше идти нельзя.
2. Определите триггеры документов. Решите, в какой момент создаётся реализация (при выгрузке заказа или при отгрузке) и как признаётся оплата (по признаку с сайта или по банковской выписке).
3. Согласуйте состав реквизитов. НДС, договоры, организации, склады, статьи учёта — что и в каком виде передаёт сайт, что подставляет 1С по правилам.
4. Настройте модуль обмена на сайте. В админке 1С-Битрикс включите обмен с 1С, задайте формат CommerceML, статусы заказов для выгрузки и сопоставление свойств.
5. Настройте обработку обмена в 1С. В конфигурации Бухгалтерии (штатно или через расширение/правила конвертации) настройте приём заказов, сопоставление номенклатуры и контрагентов, создание реализаций.
6. Настройте возврат статусов. Пропишите, какие изменения (проведён, оплачен, отгружен, номер документа) возвращаются на сайт и как отображаются в заказе.
7. Проведите тестовый обмен на копии. Прогоните реальные заказы разных типов (розница, B2B, предоплата, постоплата) на тестовой базе и проверьте документы вручную вместе с бухгалтером.
8. Настройте расписание и мониторинг. Задайте периодичность обмена, включите журналирование и оповещения об ошибках.
9. Запустите на бой и наблюдайте. Первую неделю сверяйте каждый документ, затем переходите на выборочный и автоматический контроль.

Как это выглядит в админке 1С-Битрикс

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

Со стороны 1С:Бухгалтерии обмен настраивается в обработке обмена с сайтом. Если типовых возможностей не хватает, правила преобразования данных задаются в подсистеме «Конвертация данных» (форматы Enterprise Data / CommerceML), где описывается, как элементы XML сайта превращаются в объекты конфигурации: заказ — в документ-основание, строки — в номенклатуру, реквизиты покупателя — в контрагента и договор. Логику важно выносить в расширения конфигурации, чтобы не терять возможность обновлять типовую Бухгалтерию.

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

Расписание, очереди и надёжность обмена

Обмен, который «иногда падает», хуже, чем отсутствие обмена, потому что создаёт ложное чувство порядка. Надёжность — это не приятное дополнение, а обязательное свойство интеграции с учётной системой.

Что определяет устойчивость обмена:

• Периодичность. Заказы можно выгружать по расписанию (например, раз в 15–30 минут) или по событию. Тяжёлые операции — по ночам, в часы низкой нагрузки.
• Идемпотентность. Повторная выгрузка того же заказа не должна создавать дубль. Это обеспечивается внешним ключом и проверкой на стороне 1С.
• Ретраи и очереди. Если сеанс упал по таймауту или сети, обмен должен повторить попытку, а не потерять данные. Для нагруженных проектов данные ставятся в очередь.
• Размер пакета. Большие пакеты рвутся по таймауту веб-сервера. Обмен делят на порции, чтобы каждая укладывалась в лимиты времени и памяти.
• Журналирование. Каждый сеанс фиксируется: что выгружено, что принято, где ошибка. Без журнала расследовать расхождения невозможно.

Отдельная тема — что делать при сбое посреди обмена. Правильно спроектированный обмен атомарен на уровне документа: либо заказ полностью корректно превратился в реализацию, либо не создался вовсе и уйдёт в следующий сеанс, но не остаётся «наполовину». Проектирование устойчивого канала с очередями и повторами мы детально разбираем в статье про надёжность интеграций через очереди — принципы оттуда применимы и к обмену с Бухгалтерией.

Сверка и контроль расхождений

Даже безупречно настроенный обмен нужно контролировать. Данные меняются, сотрудники правят документы руками, платёжные системы присылают корректировки. Регулярная сверка — то, что отличает интеграцию, которой доверяют, от интеграции, которую перепроверяют вручную.

Минимальный набор контрольных проверок за период (день, неделя, месяц):

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

Частые ошибки при интеграции

• Не определили мастера данных — остатки и цены правят и на сайте, и в 1С, из-за чего данные постоянно разъезжаются.
• Подключили сайт напрямую к Бухгалтерии там, где нужна торговая система, — обмен остатками и большим каталогом работает нестабильно.
• Меняют номер заказа на сайте после первой выгрузки — теряется внешний ключ, и в 1С появляется дубль реализации.
• Оплату и реализацию разносят на разные ключи (розничный покупатель против контрагента) — взаиморасчёты не сходятся.
• Не согласовали с бухгалтером НДС, договоры и организации — документы формально создаются, но учётно неверны.
• Выгружают весь объём одним пакетом — обмен рвётся по таймауту веб-сервера на больших выгрузках.
• Не ведут журнал обмена — при расхождении невозможно понять, какой заказ и на каком шаге потерялся.
• Правят типовую конфигурацию напрямую вместо расширений — теряется возможность обновлять Бухгалтерию, а логика обмена ломается после апдейта.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность интеграции перед запуском на бой:

1. Мастера данных зафиксированы. Таблица «данные → мастер → получатель» составлена и согласована с бухгалтерией и коммерцией; двойных мастеров нет.
2. Архитектура выбрана осознанно. Решено, идёт ли обмен напрямую с Бухгалтерией или через торговую систему, с учётом планов роста.
3. Триггеры документов определены. Понятно, когда создаётся реализация и как признаётся оплата; решение согласовано с бухгалтером.
4. Реквизиты учёта настроены. НДС, договоры, организации, склады и статьи учёта передаются или подставляются корректно.
5. Ключи связи стабильны. Внешний идентификатор заказа прописан в обе стороны; номер заказа после выгрузки не меняется.
6. Обмен идемпотентен. Повторная выгрузка не создаёт дублей; пакеты разбиты по размеру; есть ретраи.
7. Возврат статусов работает. Проведение, оплата и отгрузка возвращаются на сайт и видны в заказе.
8. Журнал и сверка включены. Каждый сеанс логируется; настроен автоматический отчёт о расхождениях сумм и количеств за период.
9. Протестировано на копии. Прогнаны розница, B2B, предоплата и постоплата; документы проверены вручную вместе с бухгалтером.

Вывод

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