1С:ERP и 1С:Бухгалтерия: единая база или два контура — что выбрать

На старте ERP-проекта быстро возникает вопрос: оставлять бухгалтерию в отдельной базе или вести её в той же 1С:ERP? Часто на него отвечают по привычке. Одни уверены, что бухгалтерия должна жить отдельно. Другие считают, что при внедрении ERP в неё нужно перенести всё. Оба подхода слишком упрощают выбор.

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь важна не экономия на второй программе, а понятный путь данных. Если при закрытии месяца нашлась ошибка, можно пройти от итоговой суммы к документу и самой операции в одной системе. Не приходится сначала выяснять, где возникло расхождение: в ERP, в обмене или в бухгалтерской базе.

Но в единой базе всем отделам приходится соблюдать общие правила:

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

Особое внимание нужно уделить закрытию периода. Если бухгалтерия запрещает менять документы прошедшего месяца, операционные подразделения должны понимать, какие ошибки исправляются корректирующими документами, кто согласует перепроведение и как изменения попадают в управленческий результат. Эти правила важнее физического количества баз.

Иногда это разумно. Например, ERP постоянно дорабатывается, а бухгалтерскую базу нужно обновлять осторожнее. За независимость приходится платить обменом. Между системами появляется постоянная работа, у которой должны быть свои правила и ответственные.

До запуска нужно договориться о семи вещах:

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

2. Что передаём. Какие документы и справочники переходят между системами, с какой детализацией и в какой момент.

3. Как преобразуем данные. Как сопоставляются аналитики, виды операций, счета и другие реквизиты, если системы устроены по-разному.

4. Как замечаем сбой. Откуда команда узнаёт, что пакет не прошёл, документ отклонён или часть данных загрузилась с ошибкой.

5. Как сверяем результат. Какие контрольные суммы сравниваются, кто разбирается с расхождениями и когда данные готовы к закрытию.

6. Где исправляем ошибку. На какой стороне меняют исходный документ, можно ли править данные в бухгалтерской базе и как не потерять исправление при следующем обмене.

7. Как проверяем изменения. Что нужно протестировать после обновления или доработки одной из систем.

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

Перед решением задайте один вопрос. Где компании будет легче найти и исправить ошибку: внутри общей системы или на границе двух баз? Если ответа нет, выбирать схему ещё рано.

Теперь приложим критерии к практике. Ниже три условные ситуации, а не клиентские кейсы.

Компания внедряет ERP для закупок, запасов, производства, продаж и расчёта себестоимости. Большинство первичных документов будет создаваться внутри ERP. Бухгалтерия готова участвовать в проектировании аналитик и правил отражения, а ключевые доработки можно выпускать по общему графику.

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

ERP постоянно развивается: меняются производство, логистика и управленческая отчётность. В бухгалтерской базе накоплены важные проверенные доработки, а обновляется она по отдельному календарю. Если объединять системы сразу, объём миграции и риск для обязательной отчётности вырастут.

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

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

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

Команды часто спорят о количестве баз ещё до того, как описали процессы и данные. Последовательность должна быть обратной. Сначала подготовьте семь ответов, затем выбирайте систему.

Составьте матрицу юридических лиц, подразделений и процессов. Укажите, в какой системе они будут работать, когда перейдут, какие у них налоговые режимы и нетиповые операции. Отдельно отметьте всё, что остаётся за пределами ERP. Так станет понятно, способна ли одна база охватить нужную часть бизнеса.

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

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

Опишите контрольные даты, запрет изменений, порядок поздних документов и корректировок. Укажите, какие операции закрываются автоматически, какие требуют проверки и кто подтверждает результат. При двух контурах добавьте обязательную сверку до закрытия бухгалтерской базы.

Зафиксируйте, как запрос превращается в доработку, где она тестируется и кто оценивает влияние на соседние процессы. После изменений в одной из двух баз повторно проверяйте обмен. В единой системе прогоняйте сквозные операции и закрытие месяца.

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

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

Выбирать нужно не между «большой ERP» и «привычной бухгалтерией», а между двумя способами организации данных и ответственности.

Единая база подходит, когда компания готова работать по общим процессам, справочникам и правилам изменений. Отдельного обмена нет, зато ошибка в общем справочнике или процессе может задеть несколько подразделений сразу. Значит, нужна дисциплина всей компании, а не только бухгалтерии.

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

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

В проектах внедрения 1С:ERP Smart Process начинает не с установки программы, а с границ процессов и модели данных. Затем определяются правила закрытия, миграции и приёмки. Я бы начал с карты процессов и данных, а потом вынес спорные места на короткую рабочую встречу. Пока разработка не началась, поменять решение гораздо дешевле.