Особенности перехода к модели учета при внедрении ERP-систем

Программа конференции

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

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

При локализации западных программных продуктов, как для российского, так и для украинского рынка наиболее типичными являются следующие проблемы:

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

Основной цель локализации – расширение базовой функциональности ERP-систем для того, чтобы привести её в соответствие с местным законодательством (законодательными актами, Положениями по бухгалтерскому учету, методическими указаниями различных контролирующих министерств).

В процессе локализации, как правило, решаются следующие задачи:

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

Эти задачи, на текущий момент времени, ведущими поставщиками ERP-систем практически решены. А вот, что касается решения задачи корреспонденции счетов, т. е. приведения формата учетной записи/проводки в стандарт итальянского конто (в одной строке одновременно присутствует данные о дебетовом и кредитовом бухгалтерском счете, и именно эту пару и называют корреспонденцией), то тут существует ряд принципиальных проблем.

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

Не для кого не секрет, что объемы данных, обрабатываемых бухгалтерией на любом предприятии огромны, а люди, которые эти данные обрабатывают – не совершенны, поэтому, в процессе обработки всегда возникают ошибки. Бухгалтерия любого предприятия имеет свой собственный механизм контроля корректности введенных первичных данных, который базируется, прежде всего, на механизме корреспонденции счетов. А другие механизмы не используются, но не потому, что их нет, а просто такова традиция, исторический опыт нашей бухгалтерии, такова система подготовки бухгалтерских кадров.

Вполне естественно требование, что бы ERP-система поддерживала этот формат представления. В этом случае можно использовать и стандартные (устоявшиеся) механизмы контроля корректности данных, и огромные возможности по сбору и хранению учетных данных, которые предоставляют эти системы.

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

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

Проблема первая. Дело в том, что задачи учета в ERP-системе решаются не в рамках одного модуля, а распределены по тем модулям, где осуществляется регистрация хозяйственных операций (Снабжение, Склад, Производство, Сбыт, Ремонты и т.д.). Поэтому для решения этой задачи требуется внесение изменений во все эти модули.

Кроме того, так же необходимо вносить кардинальные изменения в модуль «Главная книга», который является хранилищем учетных записей/проводок. Какие здесь возможны варианты? Можно создать дополнительное хранилище учетных записей, которое будет хранить данные в формате итальянского конто. Но на самом деле это работа по созданию нового модуля. Либо заменить формат хранения в текущем модуле, что по существу означает создание другой версии системы. В этом случае, перед поставщиками встает проблема одновременного поддержания двух версий системы, что, в общем, очень накладно. А учитывая, что объемы реализации ERP-систем на рынке СНГ составляют доли процента от общих объемов реализации в мире, вероятность осуществления этой работы становится просто мизерной.

Проблема вторая. Переходя к формату хранения «Итальянское конто» будут потеряны те преимущества, которые предоставляют ERP-системы.

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

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

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

Например: в проводках, созданных при регистрации хозяйственной операции «Выставление исходящего счета-фактуры (Customer Invoice)» могут формироваться:

• Дебетовая проводка по счету дебиторской задолженности с аналитическими признаками: договор, условия оплаты, рынок сбыта, способ транспортировки;
• Кредитовая проводка по счету отгруженной продукции с аналитическими признаками: договор, вид продукции; способ обеспечения, склад отгрузки;
• Кредитовая проводка по счету налога на добавленную стоимость (исходящего) с аналитическими признаками: договор; ставка налога, метод учета.

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

При этом необходимо отметить, что во всех системах формирование проводок (субсчета и аналитические признаки) осуществляется автоматически на основании данных регистрируемой хозяйственной операции. В разных системах используются различные способы настройки правил преобразования реквизитов хозяйственной операции в реквизиты учета. Но все они базируются на одних и тех же механизмах. К ним относятся:

• Табличные функции;
• Наследование;
• Выбор из ранее определенного набора.

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

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

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

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

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

Когда работа выполнена, и система запущена в опытную эксплуатацию, то у бухгалтеров возникает вопрос: как осуществлять контроль корректности данных. При чем проблемы возникают при контроле данных не конкретной хозяйственной операции (в этом случае все просто: сверяется соответствие данных первичного документа и данных сформированных проводок), а агрегированных данных (сальдовые и оборотные показатели за учетный период).

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

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

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

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

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

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

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

Как уже говорилось ранее, по одной хозяйственной операции могут создаваться сразу несколько проводок. Но все проводки по одной операции объединяются в один объект, который в разных системах называется по-разному: документ, ордер, ваучер и т.д. Поэтому можно создать классификатор типов этих объектов и использовать тип как признак при формировании значения контрольного показателя;

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

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

В заключении хотелось бы отметить следующее. Различные форматы хранения проводок в ERP-системах и традиционном учете не могут служить основанием для отказа от использования системы как средства автоматизации деятельности бухгалтерии. Но в число задач, решаемых в процессе внедрения ERP-системы, обязательно должны быть включены работы по созданию процедуры контроля корректности агрегированных учетных данных. А эти процедуры принципиально отличаются от ранее используемых. Поэтому заказчик должен хорошо понимать, что организация процесса работы бухгалтерии потребует значительных преобразований.

К сожалению, на вопрос: «Какая модель учета должна использоваться предприятием при эксплуатации ERP-системы?», не возможно дать единственно правильный ответ. И проблема тут заключается не в том, что разные системы требуют различных моделей учета (ведь очень часто, при эксплуатации одной системы на предприятиях одной и той же отрасли, используются различные модели учета). Просто выбор модели учета зависит прежде всего от традиций организации учета на предприятии и применяемых методов, а также от уровня квалификации сотрудников.

Версия для печати