В этой статье я постараюсь осветить основную, с которыми сталкиваются мои клиенты при внедрении ERP. Сразу оговорюсь, что моими клиентами являются не клиенты (владельцы), а именно пользователи. То есть те, кто является пользователями данной системы и теми проблемами, с которыми они сталкиваются. Так как это проблемы пользователей системы, то соответственно они в основном носят практический характер, а теоретический.
В основном ко мне обращаются с вопросами по обучению, и меньше всего по консультациями. Но если мы говорим про обучение, то все равно получается что человеку необходима прежде всего консультации. Так и так если если человек неправильно понимает тот или иной механизм в 1С ERP или сталкивается с какой-либо проблемой, которую он не может решить, то ему необходимо не только обучение, но также необходимо понять и посоветовать как ему быть в той или иной ситуации. Итак, начнем.
Вообще в 1С ERP очень много проблем которые я знаю, но опишу я пока одну.
Бухгалтерский учет
Самая главная проблема, с которой сталкиваются при внедрении и при использовании 1С ERP, это когда пытаются в одной базе вести бухгалтерский учет и управленческий.
Что это значит? Давайте сначала рассмотрим ситуацию, когда мы не пользуемся 1С ERP.
К примеру, у нас есть какая-либо система, в которой мы ведем производственный учет или торговый учет.
Раз в месяц мы выгружаем данные в 1С-бухгалтерию. Уже в ней подготавливаем отчетность, делаем проводки и тд. И, соответственно, сдает отчетность государству, подготавливает также налоговую отчетность. Но если мы возьмем только 1C ERP, то получается, что у нас нет выгрузок и загрузок. У нас есть одна база для Бухгалтерии и всего предприятия.
Несоответствие сроков сдачи отчетности.
То есть, если мы посмотрим на график сдачи бухгалтерии, то там достаточно… Щадящие сроки. Например, за год сдаем, то мы можем тот же самый НДС сдать , до 25 января за 4 квартал предыдущего года. Ну, то есть у нас практически почти месяц для сдачи отчетности.
Если мы говорим про налог на прибыль, то это, допустим, до 25 марта, то есть 3 месяца. Что это значит на практике для нас? А значит, это то, что мы, вот если мы в бухгалтерии работаем, мы можем документы отражать не сразу, а когда нам будет необходимо. Я такое видел, например, когда восстанавливают учет.
Нам не нужно отражать прям секунду в секунду, день в день. У нас есть определенный лаг, у нас есть определенный период, за который мы можем сдать. А что что касается, скажем так, всего всего остального, а им данные нужны сейчас.
Например задолженность перед поставщиком мы должны контролировать не каждый месяц, а практически по документам, иначе это грозит нам попаданием в стоп лист и проблемами с материалам.
И это не зависит от того, что нам говорит государство, нам государство вообще ничего не говорит по поводу того когда мы должны работать с нашим поставщиком по вопроссам задолженности. Это дело хозяйствующих субъектов.
Смешивание двух видов учета.
Вторая основная проблема, это то, что мы, получается, смешиваем два вида учета. Бухгалтерский, который строго регламентирован государством. И управленческий, который никак не регламентирован государством. Мы можем отражать раз в месяц эту финансовую отчетность, например, Баланс или расчет рентабельности. А они считаются нее так как нам говорит государство, предприятие в данном случае имеет свободу действий.
Как это выглядит на практике? Почти каждый документ мы должны отражать в БУ и поэтому нас практически заставляют советоваться с бухгалтером как мы должны отражать ту или иную хозяйственную операцию. И вот здесь рождается коллизия.
Бухгалтерe может не понравиться то, как мы провели. И что мы должны делать? Мы должны найти того человека, который это сделал. И чтобы он «исправил», чтобы в идеале он умел это отражать по БУ хозяйственную операцию. То есть мы должны человека, человек должен знать бухгалтерский учет, по большому счету. Я это не раз видел.
Кроме того, если мы даем права доступа к бухгалтеру, то мы… даем право редактировать документы, те, которые он не создал. Ему ведь нужно сдавать бухгалтерскую отчетность. Соответственно, мы ему должны это дать. И мы нарушаем таким образом разделение труда и ответсвенности.
Если подитожить мы должны учитывать бухгалтерский учет и правила бухгалтерского учета при работе во всем предприятии, и поэтому что начинает влиять на все предприятие. И второе, то, что мы должны по срокам учитывать то, что касается бухгалтерии и не касается нас. Но так как мы в единой базе работаем, то бухгалтерия заставляет других сотрудников плясать по свою дудку. Иначе неправильно рассчитаем НДС, Налог на прибыль и все! Казенный дом для директора и главбуха. И ведь нее поспоришь, d контрагентами гораздо проще договориться чем с государством.
Что же делать?
Все очень просто — нее ведите Бухгалтерский учет в одной базе со всем остальным. Тем более что
По большому счету в таком случае вы разделяете учет и идея — «все в одном» нее реализуется. Но это не так уж и плохо, не стоит скрещивать ужа с ежом.
Комментарии (26)
fosihas
21.04.2026 08:24Самая главная проблема, с которой сталкиваются при внедрении и при использовании 1С ERP, это когда пытаются в одной базе вести бухгалтерский учет и управленческий.
!!!! так это конфа для это го и приспособлена, чтобы не скакать между базами.
Если у вас особенности учета, не значить что всех так.
SmileyK
21.04.2026 08:24там волей не волей вылазиет особенность учета, но вы правы, что надо смотреть на саму компанию и подойдет ли оно ей, просто большая часть в последнее время смотрит, на то что ERP там все есть давайте брать (да сложно), но типа решит все проблемы и потом да начинается, вай нужен напильник или еще что-то…
ramil_trinion Автор
21.04.2026 08:24О какой особенности идет речь? Это просто БУ
SmileyK
21.04.2026 08:24я не про БУ я про ERP
ramil_trinion Автор
21.04.2026 08:24Если у вас особенности учета, не значить что всех так.
Я про это спрашивал
mixsture
21.04.2026 08:24Да и сама идея смешать в одной базе то, к чему нужны очень частые обновления вендора (бухучет) и то, к чему нужна хорошая кастомизация (упр учет) - так себе идея.
Причем с кучи точек зрения, не только с точки зрения поддержки кода/разработки: вот зайдите сюда со стороны сисадмина - у вас есть 2 набора данных, для которых можно и нужно делать разные планы резервных копий. Для бухов обычно подходят редкие бекапы с ускорением перед периодом отчетности, т.к. там интенсивнее работа становится. Для упр учета нужны частые бекапы (а еще он хранит существенно больше данных). Мы это объединяем - вжух! И теперь нам надо бекапить часто и большой объем данных. Мы теперь не можем восстановить каждый набор данных на свою дату/время.
Более того, единая база позволяет отразить меньшее число состояний (или как минимум кратно повышает сложность/стоимость/требования к квалификации) Пример: произошло нечто нестандартное. Которое должно быть в бухучете отражено так-то, а в управленческом по-другому, никаких вариантов вернуть оба учета в согласованное состояние уже не осталось. С 2мя базами решается на раз два силами пользователей: ставим дату запрета загрузки, чтобы этот период не загружался, меняем в одной базе доки под требования бухучета, в другой под требования упр учета. Закрываем все это датой запрета изменений. В единой базе же мы не можем этого добиться пользовательскими доками, мы обязаны спуститься в ручное редактирование движений: либо у документа, либо корректировками записей (уж совсем не пользовательский инструмент) - никакого варианта сделать это усилиями пользователей уже не осталось.
В итоге этот комбайн ERP очень быстро собирает недостатки, кратно быстрее сбора достоинств. Отсюда сложно, дорого, тормозит.
Naf2000
21.04.2026 08:24И вот в бухгалтерскую базу приходит документ. Бухгалтер считает, что он отражен не совсем корректно с его точки зрения. Что-то меняет в нём. После этого в управленческой базе его перепроводят (даже не затрагивая данные важные для бухгалтерии). И документ снова выгружается в бухгалтерскую базу в первоначальном виде, затирая все что сделал бухгалтер. Бухгалтер недоволен.
Потому что надо было не документ менять, а его настройки. Но изменив настройки, надо все равно перевыгрузить документ
ramil_trinion Автор
21.04.2026 08:24И вот в бухгалтерскую базу приходит документ. Бухгалтер считает, что он отражен не совсем корректно с его точки зрения. Что-то меняет в нём.
где меняет?
Naf2000
21.04.2026 08:24где меняет?
Это хороший вопрос. Но раз вы сказали, что бухучет будет вестись в бухгалтерской базе - значит в ней меняет документ.
mixsture
21.04.2026 08:24Это довольно хорошо разруливается датами запрета загрузки и изменения в обоих базах. Более того, при особо сложных случаях, мы можем в бух базе поставить ручные движения, а в упр они будут автоматические. Кмк, тут как раз очень хорошая и контролируемая изоляция.
Naf2000
21.04.2026 08:24То есть надо сказать бухгалтерии, что до момента Х не стоит лезть в выгруженные данные. Все верно?
mixsture
21.04.2026 08:24Если под лезть вы подразумеваете внесение изменений, то да - какой-то период есть, когда изменения могут свободно приехать в бух базу и заместить локальные (хотя тут тоже есть широкий спектр настроек “кто главнее”), какой-то период, когда изменения могут быть внесены только бухами.
pro3d
21.04.2026 08:24Если бухгалтер увидел не корректный по его мнению документ уже в момент отражения, то это явно ошибочный процесс регистрации документов в 1С:ЕРП и его нужно срочно менять.
FrankNStein
21.04.2026 08:24Вы так пишете, словно вас заставили вести все виды учета в одной базе и других вариантов не было в принципе.
В моей практике выбор решения и архитектуры в целом делается по итогам обследования, когда собраны основные требования и понятны ограничения. И уже дальше внедренцы вместе с заказчиком решают, делать им монолит или выводить какие-то функции в отдельно стоящие системы и вязать их интеграциями.
В некоторых случаях вынос бухгалтерии из базы оперконтура обоснован (обычно так делают при высоконагруженном производстве, или при сильной кастомизации основной конфы, или если бухгалтерии очень нужно творить бухгалтерскую магию, а не отражать объективную реальность).
Если при этом "порешать проблемы пользователей, а не клиента (владельца)" (с) (тм), и не запретить изменение данных на стороне бухгалтерии, потому что "так бухам удобнее" - через годик-другой получим 2 абсолютно несопоставимые реальности, и клиенту придется либо платить постоянно за их сопоставление (а это долго и дорого), либо перевнедряться, чтобы найти истину где-то рядом.
А если запретить бухгалтерии менять данные на своей стороне - получаем целый квест по их исправлению автором в точке ввода, от чего вой на болоте стоит похлеще, чем от собаки Баскервилей совместно с Берримором.
В целом, обычно ведение оперативного и регучета в одной базе - наиболее эффективный вариант работы. Бухгалтерия оперативно (а не раз в месяц) проверяет за операторами корректность ввода первички, опять же - только проверяет, а не вводит (увольняем обезьян, оставляем только специалистов), благодаря этому все службы имеют одинаковые данные об остатках и не думают, где что недосписали или недооприходовали. Не происходит ситуаций с "непредсказуемым прошлым". Руководители всех уровней понимают реальную ситуацию и могут на нее среагировать, а иногда - и предотвратить проблему, а не посмертно через месяц наказывать кого попало чтоб остальные боялись.
ramil_trinion Автор
21.04.2026 08:24Бухгалтерия оперативно (а не раз в месяц) проверяет за операторами корректность ввода первички, опять же - только проверяет, а не вводит (увольняем обезьян, оставляем только специалистов)
Сразу несколько вопросов:
Бухгалтера проверили и нашли ошибку, что дальше?
Что это за предприятие такое где работают обезьяны?
Что это за специалисты такие? В чем они должны быть специалистами?
Как вообще это все поможет решить проблему описанную в статье?
FrankNStein
21.04.2026 08:24-
Правильный вариант: у них стоит запрет на редактирование всех реквизитов, заполняемых из базы оперучета, потому пишут автору документа, что именно исправить. Автор исправляет, документ повторно выгружается в базу бу, ставится флаг проверки бухгалтером, передается в базу оперучета и запрещает редактирование на той стороне (защита от изменений после проверки).
Неправильный вариант (скорее всего тот, что реализуете вы для удобства пользователей): бухгалтер исправляет в своей базе и данные опер и бухучета начинают расходиться. Со временем такие расхождения набирают критическую массу и не позволяют получить корректную информацию из обеих систем.
Тысячи их. Главные признаки - раздутый штат бухгалтерии, огромный бумажный документооборот, отсутствие автоматизации на рабочих местах бухгалтеров (да и по предприятию в целом). Видел маленький заводик со штатом в 30! бухов, у половины даже были компьютеры, они там в эксельках вели учет на основе копий бумажных складских журналов.
Специалисты - это те, кто умеет делать свою работу хорошо. Например, после автоматизации примера из предыдущего пункта штат бухов можно было сократить человек до 5, усеющих работать в ЕРП, остальных на мороз. И главное, оперативность и достоверность данных у управленцев при этом только повысилась.
Если сможете сформулировать, в чем же проблема. Пока я там вижу крайне спорные рекомендации, претендующие на универсальность. И вангую, что связано это с не самым большим кругозором обидчивого автора, который вместо аргументации своей позиции, гадит в карму ;)
-
Alexander590
21.04.2026 08:24В девяти случаях из десяти вы и ваши пользователи получите концентрированную боль (при условии, что речь идёт о среднем заводе на 1-2-3 ярда оборота и не очень сложном производственном процессе) Начнем с того, что без доработок обмена вообще ничего не заведётся, особенно в блоке производства. Как выше было сказано - с перезатиранием документов обменом - разок другой готовьтесь поднимать базу из копии, пока не напишите костыли. Вообще объём доработок в БП3 будет сравним с объёмом доработок ERP(с учётом критериев предприятия, указанных выше). Себестоимость производства у вас не сойдётся никогда даже на простых базах распределения ( и, поверьте на слово, вас однажды попросят их сравнить, даже если на этапе моделирования клялись, что не будут сравнивать). Будет довольно весёлая история с зачётом авансов, актами сверок и, соответственно, декларацией по НДС, если используете метод зачёта сложнее чем просто по договорам. И в целом ERP без контрольной функции бухгалтерии превратится в помойку в лучшем случае через пару лет. Месяц в зелёнку перестанут закрывать через полгода. Программа превратится в систему ввода первички и выписки документов, се ля ви... Поэтому мораль - если организация не готова вести бухгалтерский учёт в ERP то
а) ей не нужна ERP
б) ей нужно по возможности отбелиться, т.к. двойной учёт при отсутствии мути не нужен никому, по крайней мере в здравом уме.
в) ей совсем не нужна ERP
г) ей нужен хотя бы средней руки ГБ и хороший архитектор
Д) ей прямо совсем не нужна ERP. Как вы можете верить в дисциплинированность пользователей организации, когда один из основных пользователей в лице бухгалтерии не в состоянии вести учёт.
Е) если организация хочет познать всю глубину глубин ERP, то настраивайте распределение затрат отдельно для БУ\НУ\УУ.
Ё) выбрать другого подрядчика.
Вот такие мысли. Я есть Грут.
FrankNStein
21.04.2026 08:24Вот на все 100% согласен.
Если у предприятия есть хороший главбух/финдир/CTO, то они могут подобрать адекватного подрядчика и выбрать подходящую архитектуру всего ландшафта.
Жаль, что действительно грамотные спецы что у заказчика, что у внедренцев встречаются не то чтобы часто.
Alexander590
21.04.2026 08:24В точку. Не претендую на истину, конечно, но, по моему мнению, у многих специалистов-внедренцев, которые так себя называют, есть одна проблема - изначально отсутствуют глубокие знания бухучета ( правда в том, что даже у ГБ заказчика иногда проблемы с этим) отсюда и начинается война с системой, костылинг и план-обменинг. А на небольших внедрениях обычно на поддержку всех этих архитектурных излишеств вообще не закладывают бюджет.
Вообще на малых внедрениях, на коих я немного поел canis lupus familiaris, надо сначала выстроить каркас в виде бухгалтерского учёта, потом уже на его базе со временем система обрастает функционалом. Нет бухучета в базе - нет функционирующей ERP - Имхо. Живой пример, когда топ-3 интегратор при обследовании в бухгалтерию зашёл в последний момент, понял что их требования идут вразрез с общей методологией. «внедрил» по итогу блок закупок и продаж (надо признать, что довольно навороченный) без учёта замечаний от бухгалтеров. Взял 18 миллионов ( на минуточку в 2018 году) и ушёл в закат по голливудски на фоне взрывов жепп половины учетчиков... Закономерный итог - перевнедрение в 2021.
pro3d
21.04.2026 08:24Все проблемы описаны представителем новой армии внедренцев, которые кидаются внедрять ерп сразу после сдачи теста «1с профессионал». При правильном внедрении ерп подобных проблем не возникает.
pro3d
21.04.2026 08:24Вы пишите, что занимаетесь 1С 20 лет. Тогда не понятно почему вы описали проблемы, которых просто не может быть.
Архитектура 1С ЕРП так и продумана, что бы проводки можно было отразить при необходимости.
Взаиморасчеты с поставщиками и заказчиками уже давно перестали быть ответственностью бухгалтерии. Они на это не влияют. Счет учета с контрагентами - это шаг согласования договора и его настройка. Отражать или нет проводки - тоже самостоятельная настройка.
Виды учета в 1С ЕРП никогда не смешивались. Их всегда смешивают внедренцы. Порядок учета затрат определяется экономическими правилами и требованиями действующего законодательства. А вот создать правильную модель учета затрат и их настройку уже задача внедренцев-консалтеров.
Для ведения бухучета в отдельной базе есть свои причины, но они никак не подходят под описанное вами.
Вести бухгалтерский учет в одной базе при правильных настройках 1С ЕРП намного проще чем в отдельной базе.
DmitryBurykin
21.04.2026 08:24Можно и 50 лет заниматься 1с и остаться джуном. Мудрость не функция времени. Это не камень в огород - просто мысли вслух. ЕРП это не место где бухгалтер ковыряет каждый документ на предмет нравится не нравится - просто потому что документооборот исчисляется тысячами документов в месяц. Ведется шаблонизированный бух учет с прописанной и выверенной методикой, чек-листами. Перекачки из базы в базу - чтобы в одной базе творить дичь а в другой причесывать/перевыставлять контрагентам и не забывать корректно синхронизироваться при этом? Забавные технологии.
SmileyK
человек меня услышал наверное когда я в церковь ходил просить господа наделить вокруг людей меня мозгами…