Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
человек меня услышал наверное когда я в церковь ходил просить господа наделить вокруг людей меня мозгами…
Самая главная проблема, с которой сталкиваются при внедрении и при использовании 1С ERP, это когда пытаются в одной базе вести бухгалтерский учет и управленческий.
!!!! так это конфа для это го и приспособлена, чтобы не скакать между базами.
Если у вас особенности учета, не значить что всех так.
там волей не волей вылазиет особенность учета, но вы правы, что надо смотреть на саму компанию и подойдет ли оно ей, просто большая часть в последнее время смотрит, на то что ERP там все есть давайте брать (да сложно), но типа решит все проблемы и потом да начинается, вай нужен напильник или еще что-то…
О какой особенности идет речь? Это просто БУ
Да и сама идея смешать в одной базе то, к чему нужны очень частые обновления вендора (бухучет) и то, к чему нужна хорошая кастомизация (упр учет) - так себе идея.
Причем с кучи точек зрения, не только с точки зрения поддержки кода/разработки: вот зайдите сюда со стороны сисадмина - у вас есть 2 набора данных, для которых можно и нужно делать разные планы резервных копий. Для бухов обычно подходят редкие бекапы с ускорением перед периодом отчетности, т.к. там интенсивнее работа становится. Для упр учета нужны частые бекапы (а еще он хранит существенно больше данных). Мы это объединяем - вжух! И теперь нам надо бекапить часто и большой объем данных. Мы теперь не можем восстановить каждый набор данных на свою дату/время.
Более того, единая база позволяет отразить меньшее число состояний (или как минимум кратно повышает сложность/стоимость/требования к квалификации) Пример: произошло нечто нестандартное. Которое должно быть в бухучете отражено так-то, а в управленческом по-другому, никаких вариантов вернуть оба учета в согласованное состояние уже не осталось. С 2мя базами решается на раз два силами пользователей: ставим дату запрета загрузки, чтобы этот период не загружался, меняем в одной базе доки под требования бухучета, в другой под требования упр учета. Закрываем все это датой запрета изменений. В единой базе же мы не можем этого добиться пользовательскими доками, мы обязаны спуститься в ручное редактирование движений: либо у документа, либо корректировками записей (уж совсем не пользовательский инструмент) - никакого варианта сделать это усилиями пользователей уже не осталось.
В итоге этот комбайн ERP очень быстро собирает недостатки, кратно быстрее сбора достоинств. Отсюда сложно, дорого, тормозит.
И вот в бухгалтерскую базу приходит документ. Бухгалтер считает, что он отражен не совсем корректно с его точки зрения. Что-то меняет в нём. После этого в управленческой базе его перепроводят (даже не затрагивая данные важные для бухгалтерии). И документ снова выгружается в бухгалтерскую базу в первоначальном виде, затирая все что сделал бухгалтер. Бухгалтер недоволен.
Потому что надо было не документ менять, а его настройки. Но изменив настройки, надо все равно перевыгрузить документ
И вот в бухгалтерскую базу приходит документ. Бухгалтер считает, что он отражен не совсем корректно с его точки зрения. Что-то меняет в нём.
где меняет?
Это довольно хорошо разруливается датами запрета загрузки и изменения в обоих базах. Более того, при особо сложных случаях, мы можем в бух базе поставить ручные движения, а в упр они будут автоматические. Кмк, тут как раз очень хорошая и контролируемая изоляция.
Если бухгалтер увидел не корректный по его мнению документ уже в момент отражения, то это явно ошибочный процесс регистрации документов в 1С:ЕРП и его нужно срочно менять.
Вы так пишете, словно вас заставили вести все виды учета в одной базе и других вариантов не было в принципе.
В моей практике выбор решения и архитектуры в целом делается по итогам обследования, когда собраны основные требования и понятны ограничения. И уже дальше внедренцы вместе с заказчиком решают, делать им монолит или выводить какие-то функции в отдельно стоящие системы и вязать их интеграциями.
В некоторых случаях вынос бухгалтерии из базы оперконтура обоснован (обычно так делают при высоконагруженном производстве, или при сильной кастомизации основной конфы, или если бухгалтерии очень нужно творить бухгалтерскую магию, а не отражать объективную реальность).
Если при этом "порешать проблемы пользователей, а не клиента (владельца)" (с) (тм), и не запретить изменение данных на стороне бухгалтерии, потому что "так бухам удобнее" - через годик-другой получим 2 абсолютно несопоставимые реальности, и клиенту придется либо платить постоянно за их сопоставление (а это долго и дорого), либо перевнедряться, чтобы найти истину где-то рядом.
А если запретить бухгалтерии менять данные на своей стороне - получаем целый квест по их исправлению автором в точке ввода, от чего вой на болоте стоит похлеще, чем от собаки Баскервилей совместно с Берримором.
В целом, обычно ведение оперативного и регучета в одной базе - наиболее эффективный вариант работы. Бухгалтерия оперативно (а не раз в месяц) проверяет за операторами корректность ввода первички, опять же - только проверяет, а не вводит (увольняем обезьян, оставляем только специалистов), благодаря этому все службы имеют одинаковые данные об остатках и не думают, где что недосписали или недооприходовали. Не происходит ситуаций с "непредсказуемым прошлым". Руководители всех уровней понимают реальную ситуацию и могут на нее среагировать, а иногда - и предотвратить проблему, а не посмертно через месяц наказывать кого попало чтоб остальные боялись.
Бухгалтерия оперативно (а не раз в месяц) проверяет за операторами корректность ввода первички, опять же - только проверяет, а не вводит (увольняем обезьян, оставляем только специалистов)
Сразу несколько вопросов:
Бухгалтера проверили и нашли ошибку, что дальше?
Что это за предприятие такое где работают обезьяны?
Что это за специалисты такие? В чем они должны быть специалистами?
Как вообще это все поможет решить проблему описанную в статье?
Правильный вариант: у них стоит запрет на редактирование всех реквизитов, заполняемых из базы оперучета, потому пишут автору документа, что именно исправить. Автор исправляет, документ повторно выгружается в базу бу, ставится флаг проверки бухгалтером, передается в базу оперучета и запрещает редактирование на той стороне (защита от изменений после проверки).
Неправильный вариант (скорее всего тот, что реализуете вы для удобства пользователей): бухгалтер исправляет в своей базе и данные опер и бухучета начинают расходиться. Со временем такие расхождения набирают критическую массу и не позволяют получить корректную информацию из обеих систем.
Тысячи их. Главные признаки - раздутый штат бухгалтерии, огромный бумажный документооборот, отсутствие автоматизации на рабочих местах бухгалтеров (да и по предприятию в целом). Видел маленький заводик со штатом в 30! бухов, у половины даже были компьютеры, они там в эксельках вели учет на основе копий бумажных складских журналов.
Специалисты - это те, кто умеет делать свою работу хорошо. Например, после автоматизации примера из предыдущего пункта штат бухов можно было сократить человек до 5, усеющих работать в ЕРП, остальных на мороз. И главное, оперативность и достоверность данных у управленцев при этом только повысилась.
Если сможете сформулировать, в чем же проблема. Пока я там вижу крайне спорные рекомендации, претендующие на универсальность. И вангую, что связано это с не самым большим кругозором обидчивого автора, который вместо аргументации своей позиции, гадит в карму ;)
del
В девяти случаях из десяти вы и ваши пользователи получите концентрированную боль (при условии, что речь идёт о среднем заводе на 1-2-3 ярда оборота и не очень сложном производственном процессе) Начнем с того, что без доработок обмена вообще ничего не заведётся, особенно в блоке производства. Как выше было сказано - с перезатиранием документов обменом - разок другой готовьтесь поднимать базу из копии, пока не напишите костыли. Вообще объём доработок в БП3 будет сравним с объёмом доработок ERP(с учётом критериев предприятия, указанных выше). Себестоимость производства у вас не сойдётся никогда даже на простых базах распределения ( и, поверьте на слово, вас однажды попросят их сравнить, даже если на этапе моделирования клялись, что не будут сравнивать). Будет довольно весёлая история с зачётом авансов, актами сверок и, соответственно, декларацией по НДС, если используете метод зачёта сложнее чем просто по договорам. И в целом ERP без контрольной функции бухгалтерии превратится в помойку в лучшем случае через пару лет. Месяц в зелёнку перестанут закрывать через полгода. Программа превратится в систему ввода первички и выписки документов, се ля ви... Поэтому мораль - если организация не готова вести бухгалтерский учёт в ERP то
а) ей не нужна ERP
б) ей нужно по возможности отбелиться, т.к. двойной учёт при отсутствии мути не нужен никому, по крайней мере в здравом уме.
в) ей совсем не нужна ERP
г) ей нужен хотя бы средней руки ГБ и хороший архитектор
Д) ей прямо совсем не нужна ERP. Как вы можете верить в дисциплинированность пользователей организации, когда один из основных пользователей в лице бухгалтерии не в состоянии вести учёт.
Е) если организация хочет познать всю глубину глубин ERP, то настраивайте распределение затрат отдельно для БУ\НУ\УУ.
Ё) выбрать другого подрядчика.
Вот такие мысли. Я есть Грут.
Вот на все 100% согласен.
Если у предприятия есть хороший главбух/финдир/CTO, то они могут подобрать адекватного подрядчика и выбрать подходящую архитектуру всего ландшафта.
Жаль, что действительно грамотные спецы что у заказчика, что у внедренцев встречаются не то чтобы часто.
В точку. Не претендую на истину, конечно, но, по моему мнению, у многих специалистов-внедренцев, которые так себя называют, есть одна проблема - изначально отсутствуют глубокие знания бухучета ( правда в том, что даже у ГБ заказчика иногда проблемы с этим) отсюда и начинается война с системой, костылинг и план-обменинг. А на небольших внедрениях обычно на поддержку всех этих архитектурных излишеств вообще не закладывают бюджет.
Вообще на малых внедрениях, на коих я немного поел canis lupus familiaris, надо сначала выстроить каркас в виде бухгалтерского учёта, потом уже на его базе со временем система обрастает функционалом. Нет бухучета в базе - нет функционирующей ERP - Имхо. Живой пример, когда топ-3 интегратор при обследовании в бухгалтерию зашёл в последний момент, понял что их требования идут вразрез с общей методологией. «внедрил» по итогу блок закупок и продаж (надо признать, что довольно навороченный) без учёта замечаний от бухгалтеров. Взял 18 миллионов ( на минуточку в 2018 году) и ушёл в закат по голливудски на фоне взрывов жепп половины учетчиков... Закономерный итог - перевнедрение в 2021.
А вот тут не соглашусь.
На малых внедрениях ERP и не нужна - это все же система не для ларька "рога и копыта". А там, где она нужна - строить ее надо не вокруг бухучета 100%, потому что логика в бухучете, мягко говоря, странная и бесчеловечная по отношению к другим подразделениям.
Надо просто помнить, что бухгалтерия - это обслуживающее подразделение (одно из), а не основная цель работы предприятия. Они своими требованиями накладывают ограничения на процессы других, но не являются целью проекта ведения ERP.
Если на каком-то проекте при внедрении забыли включить бухучет в контур (заказчик сэкономил) - тут точно не вина подрядчика. Мы по этим граблям тоже проходили, заканчивалось предсказуемо - теперь если бухучет в перспективе надо вести в системе, стараемся продать проекты комплексные. Т.к. расширять рамки проекта и работать бесплатно ради радости бухгалтеров у подрядчика желания нет.
Все проблемы описаны представителем новой армии внедренцев, которые кидаются внедрять ерп сразу после сдачи теста «1с профессионал». При правильном внедрении ерп подобных проблем не возникает.
Вы пишите, что занимаетесь 1С 20 лет. Тогда не понятно почему вы описали проблемы, которых просто не может быть.
Архитектура 1С ЕРП так и продумана, что бы проводки можно было отразить при необходимости.
Взаиморасчеты с поставщиками и заказчиками уже давно перестали быть ответственностью бухгалтерии. Они на это не влияют. Счет учета с контрагентами - это шаг согласования договора и его настройка. Отражать или нет проводки - тоже самостоятельная настройка.
Виды учета в 1С ЕРП никогда не смешивались. Их всегда смешивают внедренцы. Порядок учета затрат определяется экономическими правилами и требованиями действующего законодательства. А вот создать правильную модель учета затрат и их настройку уже задача внедренцев-консалтеров.
Для ведения бухучета в отдельной базе есть свои причины, но они никак не подходят под описанное вами.
Вести бухгалтерский учет в одной базе при правильных настройках 1С ЕРП намного проще чем в отдельной базе.
Можно и 50 лет заниматься 1с и остаться джуном. Мудрость не функция времени. Это не камень в огород - просто мысли вслух. ЕРП это не место где бухгалтер ковыряет каждый документ на предмет нравится не нравится - просто потому что документооборот исчисляется тысячами документов в месяц. Ведется шаблонизированный бух учет с прописанной и выверенной методикой, чек-листами. Перекачки из базы в базу - чтобы в одной базе творить дичь а в другой причесывать/перевыставлять контрагентам и не забывать корректно синхронизироваться при этом? Забавные технологии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Главная проблема при внедрении 1C ERP