ERPNext и 1С:Бухгалтерия: что передавать, чтобы управленческий учёт не дублировал бухгалтерский

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

Что остаётся в 1С, а что живёт в ERPNext

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

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

Таблица ниже повторяет схему из инфографики, чтобы её можно было найти поиском и скопировать в регламент. | Зона | Где ведётся | Комментарий | |---|---|---| | Заявки на материалы, согласование | ERPNext | Видно автора и время каждого шага | | Заказ поставщику, складской приход | ERPNext | Склад объекта ведёт кладовщик | | Платёжная заявка | ERPNext | Создаётся из утверждённого счёта | | Регламентированный учёт, НДС | 1С | Закрытие периода только здесь | | Банковские выписки, ЭДО | 1С | Источник фактов об оплате | | Контрагенты, номенклатура, оплаты | Пересечение | Нужен явный мастер, см. следующий раздел |

Кто мастер: правило одного источника для контрагентов, номенклатуры и договоров

Для каждого объекта обмена до начала работ назначается система-источник. Это не формальность: если контрагента можно править и в ERPNext, и в 1С, то через месяц в одной системе у поставщика будет ИНН с опечаткой, в другой нет, и автоматический обмен либо создаст дубль, либо перезапишет правильное неправильным. Поэтому неконтролируемой двусторонней синхронизации справочников я избегаю в любом проекте, независимо от того, какой канал обмена выбран.

Мои правила по умолчанию простые. Контрагентов заводит бухгалтерия в 1С, потому что там проверяются ИНН и КПП, и в ERPNext они приходят как справочник на чтение для снабженца. Номенклатуру материалов ведёт снабжение в ERPNext (там живёт Item с единицами измерения и складскими настройками), а в 1С она уходит вместе с первым документом. Оплаты, наоборот, мастером имеют 1С: факт платежа подтверждает банк, а ERPNext только получает статус. Договоры и спецификации договоров — в ERPNext, пока они нужны для контроля перебора; в 1С достаточно номера и даты договора как реквизита документа.

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

Как данные идут в 1С: файл, REST, очередь

Технически канала три, и выбираются они не по моде, а по зрелости 1С у клиента и по тому, как часто лежит сервер. Первый канал: файл (CSV или JSON), который выгружается из ERPNext и загружается в 1С обработкой. Он прост и прозрачен, любой сбой виден глазами, но требует действий человека. Второй: REST. ERPNext (Frappe) отдаёт любой DocType по адресу /api/resource/<DocType>, а свою логику можно вызвать через /api/method/<путь>; авторизация для интеграции — заголовок Authorization: token api_key:api_secret, как описано в документации Frappe. С другой стороны 1С принимает данные через HTTP-сервис или стандартный интерфейс OData; какой из механизмов доступен, зависит от версии платформы и конфигурации, это нужно проверить на вашей базе.

Третий канал: очередь сообщений с повтором. Выгруженный документ кладётся в очередь, и если 1С в этот момент недоступна (идёт обновление, перезапуск службы, обрыв связи), сообщение не теряется, а отправляется позже. Это самый устойчивый вариант, но и самый дорогой в сопровождении: появляется ещё один сервис, который надо мониторить.

# пример чтения утверждённых счетов поставщиков за день через REST Frappe
curl -s -G 'https://erp.example.com/api/resource/Purchase%20Invoice' \
  -H 'Authorization: token API_KEY:API_SECRET' \
  --data-urlencode 'filters=[["docstatus","=",1],["posting_date","=","2026-10-01"]]' \
  --data-urlencode 'fields=["name","supplier","grand_total","modified"]'

Для запуска «по событию» в Frappe есть DocType Webhook: он срабатывает на событие документа (например, обновление) и отправляет запрос на указанный адрес. В документации Frappe описана подпись запроса: при включённом секрете добавляется заголовок X-Frappe-Webhook-Signature с HMAC-SHA256 от тела запроса, закодированным в base64. Принимающая сторона обязана эту подпись проверять. Автоматические повторы в документации не описаны, но по исходному коду Frappe v15 фоновая задача делает до трёх попыток подряд с паузами в несколько секунд, после чего событие не досылается. Поэтому вебхук годится как быстрый сигнал, а если нужна гарантия доставки, берут очередь или периодическую сверку по REST.

И один запрет без исключений: никакой прямой записи в SQL-базу 1С. Она обходит проведение, регистры и контроль платформы, и документ, созданный таким способом, нельзя считать документом. Только HTTP-сервис, OData, расширение или файл со стандартной загрузкой. Инфографика после этого раздела показывает три канала и красным знаком отмечает именно этот запрещённый путь.

• Файл CSV или JSON: просто и видно глазами, но нужны действия человека
• REST и HTTP-сервис: автоматически, требуется сервис в 1С и контроль доступа
• Очередь с повтором: устойчиво к сбоям, но ещё один компонент в сопровождении
• Прямой SQL в базу 1С: не использовать никогда

Почему поступление и счёт поставщика нельзя сопоставлять «по названию»

В ERPNext Purchase Invoice (счёт поставщика) отражает задолженность перед поставщиком. Складской приход оформляется другим документом, Purchase Receipt, а если в счёте включена опция Update Stock, приход проводится самим счётом, и тогда повторный приход надо отключить, иначе материал оприходуется дважды. Это прямо сказано в документации ERPNext. В 1С же есть «Поступление товаров», которое двигает и склад, и долг, и «Счёт-фактура полученный», который нужен для НДС. Три разных объекта, три разных смысла, и ни один не равен Purchase Invoice один к одному.

Сопоставление «по названию» ломается на первой же мелочи: «Арматура А500С 12 мм» и «Арматура А500С d12» для человека одно и то же, для обмена два разных товара. То же с документами: счёт № 118 от 3 октября и приход № 118 от 5 октября могут быть разными поставками. Поэтому для каждой пары строится отдельное соответствие по внешнему ключу: приход к приходу, долг к долгу, счёт-фактура к счёту-фактуре. Что именно и как маппить на «Поступление товаров», зависит от конфигурации 1С заказчика, и это одно из главных мест, которое проверяют на стенде до запуска.

Есть и более глубокая причина, почему общий экспорт проводок (GL Entry) я не советую. В ERPNext проводки (GL Entry) строятся по плану счетов ERPNext, где аналитика по контрагенту лежит в полях party_type и party каждой строки, а в 1С проводки формирует сам документ по своему плану счетов РСБУ с субконто и налоговыми регистрами. Если выгружать проводки напрямую, придётся в обмене воспроизводить то, что 1С делает при проведении, и сопоставлять два разных плана счетов. Поэтому экспорт делается на уровне конкретного документа (Purchase Invoice, контрагент), а проводки уже формирует 1С по своим правилам.

Разберём типичные симптомы расхождений и что за ними стоит. | Симптом | Причина | Действие | |---|---|---| | Двойной контрагент в 1С | Нет внешнего ключа, поиск по названию | Ключ «источник + ID», поиск до создания | | Сумма не сходится с поступлением | Счёт и приход сопоставили по названию | Раздельные соответствия для прихода, долга, счёта-фактуры | | Оплата не вернулась в ERPNext | Статус не передан обратно | Webhook или регулярный разбор файла | | Один счёт попал в 1С дважды | Повторная отправка без идемпотентности | Обновлять по ключу, а не создавать заново |

«Бетонный Ритм»: односторонняя выгрузка вместо двустороннего коннектора

Условный пример (все цифры вымышленные, но внутренне согласованные). Подрядная организация «Бетонный Ритм», 12 рабочих мест: снабженец, два прораба, главный инженер, три бухгалтера, остальные на объектах. Бухгалтерия стоит в 1С:Бухгалтерии, снабжение переехало в ERPNext. Первая идея владельца была логичной: сделать «полный обмен», чтобы всё везде было одинаковое. Мы посчитали, что в месяц меняется около 40 карточек контрагентов и 300 строк номенклатуры. Двусторонний обмен в реальном времени при таком потоке означал бы проверку конфликтов правок почти каждый день.

Вместо этого выбрали узкую схему. Бухгалтерия ведёт контрагентов в 1С и раз в сутки выгружает их файлом для чтения в ERPNext. Утверждённые счета поставщиков (Purchase Invoice с docstatus 1) выгружаются по REST с ключом ERPNEXT:<имя документа>; на стороне 1С по этому ключу создаётся или обновляется документ, повторная отправка того же счёта дубля не создаёт. Обратно, раз в час, приходят только статусы оплат: ключ счёта, дата платежа, сумма. По ним в ERPNext закрывается платёжная заявка (Payment Request) или создаётся Payment Entry, смотря по принятому в компании регламенту.

Что получили на пилоте (условный пример). За две недели через обмен прошло 86 счетов; 3 раза система вернула ошибку «контрагент не найден», потому что снабженец успел завести поставщика раньше бухгалтера: правило «только с пометкой ожидает проверки» появилось именно после этого. Двойных документов в 1С не появилось ни разу, потому что тест на повторную отправку мы прогнали до запуска. Время бухгалтера на «перенос счетов руками» сократилось с примерно часа в день до проверки журнала обмена за 10–15 минут. Это не обещание для вашей компании, а иллюстрация того, что даёт узкая схема.

Про деньги честно. Стоимость внедрения ERPNext под ключ для команды из 5–6 человек — 65 000 ₽ разово, далее 40 000 ₽ в год или 6 500 ₽ в месяц за сервер, обновления, бэкапы и поддержку; лицензии ERPNext 0 ₽ (GPLv3). В пакет за 65 000 ₽ входит выгрузка утверждённых счетов и контрагентов штатными средствами экспорта (CSV или Excel), то есть файловый канал из раздела выше. Автоматический обмен с 1С (REST и HTTP-сервис, очередь, возврат статусов оплат, как в примере «Бетонного Ритма»), двусторонний коннектор и отдельное приложение Frappe оплачиваются отдельно и оцениваются после обследования вашей базы. Живой ход цепочки покажем на демостенде erp-demo.itfresh.ru по запросу.

Что проверить до запуска: дубли, повторная отправка, статусы оплат

Обмен проверяется не «успешным тестом на одном документе», а сериями. Мой минимальный набор из пяти проверок перед боевым включением такой. Первое: отправить один и тот же счёт дважды и убедиться, что в 1С один документ, а не два. Второе: отправить счёт с новым поставщиком, которого ещё нет в 1С, и проверить, что обмен остановился с понятной ошибкой, а не создал контрагента-призрака. Третье: изменить сумму счёта уже после отправки (в ERPNext для проведённого документа это отмена и исправление) и посмотреть, что произойдёт в 1С.

Четвёртое: выключить на час сервис в 1С и проверить, что ничего не потерялось и после включения всё дослано. Пятое: вернуть статус оплаты на счёт, который уже оплачен частично, и сверить остаток в ERPNext. Любая из этих проверок, пройденная только «на бумаге», обычно оказывается первым инцидентом в боевой работе. Подробнее про отмену и исправление проведённых документов в ERPNext есть отдельный разбор по кнопке Amend, он написан для той самой третьей проверки.

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

Где такая схема не подходит

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

Вторая граница: ERPNext не заменяет 1С в российском регламентированном учёте. Региональной локализации для РФ в коробке нет, печатные формы (УПД, КС-2) требуют настройки, налоговая отчётность остаётся в 1С. Если вы рассчитывали закрыть всё одной системой, лучше сразу сравнить варианты; для этого есть материал про то, какую систему учёта на Linux выбрать.

Третья: если у вас нет сервера 1С с доступом по HTTP или OData (например, только файловая база на одном компьютере без сетевого доступа), канал REST недоступен, и остаётся файловый обмен. Он тоже рабочий, но ручной шаг в нём неизбежен. Заранее проверьте, какой вариант платформы у вас стоит, и не обещайте себе автоматики, которой технически нет. Если вам нужна сквозная картина того, как устроен обмен учётных систем с CRM, посмотрите, как это устроено в статье про интеграцию 1С с Битрикс24 и amoCRM, принципы мастер-данных там те же, а механизмы другие.

Частые вопросы