Регламентированный учет разных стран в рамках одного тиражного решения для крупной транснациональной корпорации

Меня зовут Наталья Лосева, я работаю в компании Кодерлайн архитектором по 1С.

Я занимаюсь 1С уже 15 лет. Начинала давным-давно в маленьком франче с программиста и разносчика дисков ИТС, выросла до архитектора.

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

У меня есть сертификаты 1С:Профессионал, 1С:Специалист-консультант и даже два сертификата преподавателя.

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

На слайде – краткое содержание доклада.

• В первую очередь я дам краткую характеристику проекта. Объясню, почему я решила рассказать про регламентированный учет – почему это интересно.

• Потом о том, как мы выбирали программный продукт и подход к внедрению этого продукта.

• Подробно расскажу про реализацию – это основное тело доклада.

• И про препятствия, ошибки, провалы – думаю, многим будет интересно.

• Под конец – итоги, что у нас получилось.

Краткая характеристика проекта

Итак, исходные данные.

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

• Страны внедрения – Казахстан и Киргизия.

• Учет у заказчика велся в системах 1С:Бухгалтерия 7.7 и 1С:Торговля и склад 7.7. Еще у них был SAP Ariba, учет в Excel – лоскутная автоматизация полным ходом.

• Необходимо было построить ERP-систему на базе 1С.

• Инициация проекта была в 2020 году – на тот момент ERP-конфигурации для работы с иностранными компаниями у нас еще не было, ERP World Edition вышла в 2021.

• Целевая дата запуска – февраль 2022-го.

На слайде перечислены ключевые требования.

• Одно из главных требований к проекту – конфигурация должна быть единая. Базы разные, а конфигурация одна. Дело в том, что бюджет затрат на техподдержку у ребят был ограничен – у них не было бы ресурсов, чтобы сопровождать и поддерживать разные конфигурации. Они не хотели накатывать кучу релизов – сначала обновлять одну Бухгалтерию, потом другую, потом ERP. Плюс у них в центральном офисе в Грузии база тоже была на ERP – правда, на предыдущей редакции ERP 2.2.

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

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

• Бизнес-процессы в компании были жестко регламентированы, стандартизированы. Холдинг крупный, мировой, у них есть процессный офис – по процессам все красиво и четко. Нам как интегратору в этом плане с заказчиком повезло, было удобно.

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

Эти требования повлияли на выбор программного продукта.

На слайде перечислены функциональные блоки, которые внедрялись в рамках проекта:

• Закупки.

• Продажи.

• Склад – ордерный.

• Производство – только в Киргизии. И оно простое, через «Производство без заказа».

• Контроль качества пришлось немного допилить.

• Ценообразование – было очень много доработок.

• Доставка и управление транспортом (тоже сильно доработали).

• Внеоборотные активы (тут почти типовое).

• Ремонты (только в Киргизии).

• Учет затрат - с небольшими доработками.

• Регламентированный учет (для каждой страны).

• Международный учет по GAAP.

• Еще я включила сюда Документооборот, но он в скоуп наших работ как интегратора не входил – у них документооборот на 1С:ДО уже был, а нам необходимо было настроить механизмы для общения с ним.

На слайде – схема, как мы работали.

Главное отличие этого проекта от большинства тех, которые мы часто делаем как интеграторы, в том, что мы не взаимодействовали с конечными пользователями. Мы взаимодействовали с бизнес-экспертами – по факту, это бизнес-аналитики на стороне заказчика. Именно они были для нас ключевыми пользователями заказчика.

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

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

Как мы выбирали продукт и подход

Расскажу самое главное – как мы выбирали программный продукт.

Напомню, нам в рамках одной конфигурации нужно было автоматизировать:

• Регламентированный учет

• Оперативный учет – причем оперконтур нам нужен очень разнообразный, с широкими функциональными возможностями.

• И международный учет – про это нельзя было забывать.

В таблице – альтернативные варианты, которые мы рассматривали:

• Для оперучета можно было поставить 1С:УТ плюс 1С:БП 3.0. Но тут мы сразу проваливаемся по международному учету, по ролям пользователей для контроля – тоже проваливаемся.

• Можно было поставить 1С:УТ плюс разные конфигурации бухгалтерии – для Киргизии своя конфигурация, для Казахстана своя. Но фишка в том, что дальше коллеги идут тиражироваться на другие страны Центральной Азии. И это получилось бы дальше. Узбекистан, Таджикистан. Это была куча баз и куча разных конфигураций. А поскольку процессы стандартные, пришлось бы вносить изменения сразу тоже в кучу конфигураций. В результате ключевое требование о единой конфигурации, чтобы ее было просто поддерживать, уже не выполняется.

• И еще один хороший вариант в целом – 1С:УТ + 1С:УХ. Управление холдингом – хорошая система в плане международного учета, плюс там можно настроить регучет, как вам нужно. Но по соотношению цена-качество это решение в данном проекте не подошло – продукт сильно не соответствует ожиданиям заказчика по стоимости лицензий и поддержки.

• В итоге у нас остался один вариант без альтернатив – классический российский 1С:ERP.

Выбрали ERP, решили делать на нем. Как будем делать регламентированный учет? Нам же нужно, чтобы в рамках одной конфигурации было куча планов счетов для каждой страны. И чтобы это можно было тиражировать.

Мы рассматривали два варианта:

• Первый вариант – на подсистеме МСФО.

  • На этой подсистеме можно ввести сколько угодно планов счетов даже в типовой ERP – заводить свои счета и настраивать трансляции без доработок.

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

  • При этом не все нужные операции могут транслироваться: регоперации не транслируются, НДС не транслируется – очень много чего не транслируется.

  • И есть особенности, связанные с налоговым учетом. Они, конечно, ПБУ 18/02 не ведут. Но постоянные и временные разницы у них есть. И отложенный налог у них тоже есть. Отражать его на подсистеме МСФО – очень затратно.

• Второй вариант – доработка типового плана счетов «Хозрасчетный».

  • Просто добавляем в типовой план счетов нужные счета для каждой страны. Это удобно: мы счета добавили, и дальше просто используем типовые возможности системы по настройке счетов – в ГФУ, ГАУ и везде, где надо, нужные счета указываем.

  • Налоговый учет у нас работает по типовым алгоритмам – мы его не дорабатываем.

  • В этом случае схема работы привычна для пользователей. Они провели документ, они знают, как отразить в системе. Многие представители бизнеса параллельно работают в базе головного офиса, где уже стоит ERP – там предыдущая редакция, но в плане регучета не отличается. И для них запускаться с таким вариантом реализации регучета проще.

  • Но и минусы, естественно, есть – план счетов нужно дорабатывать. Недостаточно просто новый счет в план счетов добавить, его еще нужно в конфигураторе прописывать.

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

Мы взвесили все «за» и «против» и решили остановиться на втором варианте.

Подробнее про реализацию

Расскажу, что мы доработали.

• В типовом плане счетов добавили реквизит «Страна» и такую же константу в системе. Если пользователь работает в базе, в которой константа «Страна» установлена в значение «Казахстан», он видит счета учета только для Казахстана.

• Загрузили в конфигураторе план счетов для обеих стран. Добавили эти счета как предопределенные – на слайде справа показано, как примерно это выглядит.

• Поскольку в типовом коде много ссылок на предопределенные счета, многое пришлось переписать – про это потом скажу отдельно. В некоторых местах пришлось прописывать много хардкода.

• Для Киргизии еще добавляли налог с продаж. С ним тоже пришлось заморочиться, потому что он во многом повторяет НДС. Например, его пришлось протягивать во все типовые регистры, которые были нужны в части продаж.

• И много было доработок, связанных с формированием проводок по реализации клиентам – это было отдельное требование.

Вот так выглядит план счетов – в наименовании счета два префикса: префикс для проекта и префикс для страны (для Узбекистана – UZ и т.д.)

Расскажу, что у нас не взлетело в типовой функциональности по счетам учета номенклатуры.

Первое – аналитика на счетах выручки и себестоимости (аналог российских 90-х счетов). Им нужно было видеть там бренд – Агуша, Лейз, Хрусteam и так далее. Но в 1С:ERP субконто к 90-му счету – это ГФУ, мы тут не решились ничего править.

Дальше – когда мы определяем счет учета номенклатуры, которую мы хотим положить на склад, он у нас будет зависеть не только от ГФУ. Он у нас будет зависеть:

• от типа: Молочная продукция (детское питание); Соковая продукция; Снеки;

• от вида продукции – покупная или собственная (произведена собственными силами).

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

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

Если вы помните, при отгрузке в ГФУ номенклатуры у нас определяются счета учета выручки и себестоимости при реализации клиентам: 90.01, 90.02, 90.03 – в России не особо много выбора. Здесь же при реализации счета учета зависят от трех факторов:

• от типа клиента: если это интеркампани (продажа в рамках группы компаний) – это одно; если это внешний клиент – это другое;

• от вида продукции: покупная или собственная;

• и еще отдельно прочая реализация – здесь то, что у нас отражается на 91-м счете.

Получилась вообще трехмерная история. Пришлось дорабатывать.

На основе типового регистра сведений «Порядок отражения на счетах учета», в котором хранятся счета учета номенклатуры, мы сделали свой регистр и добавили туда нужные нам измерения:

• Вид номенклатуры – разделение на собственную и покупную.

• ICO – это признак интеркампани.

• Вид реализации – основная или прочее.

• Склад – потребовался из-за того, что у них нетиповая схема отгрузки без перехода права собственности, но это скорее вопрос к опер. учету.

Вот так у нас выглядит этот регистр:

• Аналитика – это ГФУ, наш бренд.

• Вид номенклатуры.

• Вид заказа.

• Признак интеркампани.

• Место учета (склад).

• И разные вариативности по счетам.

Вот так выглядит карточка настройки порядка отражения на счетах учета – вместо ГФУ для номенклатуры у нас теперь такая карточка.

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

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

• Типовой документ проводится.

• Потом регламентным заданием происходит отражение в регучете – типовым алгоритмом он формирует какие-то типовые проводки.

• Далее в нашем расширении мы получаем эти проводки и движения документа по опорным регистрам.

• Соединяемся с нашим новым регистром со счетами учета, устанавливаем соответствие по измерениям – по виду номенклатуры, по ГФУ и так далее – и заменяем счета в типовых проводках счетами из нашего регистра.

Схема немного замудренная, но работает.

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

• Запросы в типовом коде крайне тяжелые. Мы сменили, наверное, 3-4 или 5 разработчиков, прежде чем нашли человека, который реально с этим разобрался и написал эффективные с точки зрения производительности запросы.

• Запросы, которые выполняют замену счетов, нужно прописывать для каждого типа документа. Например, если вы для документа «Сборка (разборка) товаров» написали запрос, это не значит, что он будет работать для «Перемещение товаров». Такой же запрос нужно повторить и для «Перемещения». И так далее.

• Мест с «хардкодом», где счет учета был прописан в коде – оказалось очень много.

  • Например, в документе «Авансовый отчет»: рублевый – 71.01, валютный – 71.02.

  • Во всех операциях по закрытию месяца – 90-е и 91-е счета просто прописаны в коде.

  • При выборе счетов в ГФУ номенклатуры и ГФУ расчетов – там, когда выбираешь счет долга, прямо в коде прописан перечень счетов: 60.01, 60.21, 60.31.

Все это пришлось дописывать. В итоге на доработку ушло порядка 3-4 месяцев. А если учесть, что мы разработчиков меняли, наверное, все полгода эта история тянулась.

Кроме этого, потребовались следующие доработки.

• Accruals. Планы счетов Казахстана и Кыргызстана приближены к стандартам МСФО, где есть понятие аккруалов – расходов, по которым на момент закрытия месяца первичные документы не оформлены. В российском учете мы не можем принять расходы без первички, а у них – можно. Аккруалы мы дорабатывали. Там не очень сложно. Следующим слайдом покажу это подробнее.

• Инвентарные резервы. В ERP есть функциональность инвентарных резервов, но она заточена под российский ФСБУ. Им это не подошло. Дальше тоже на отдельном слайде можно будет прочитать подробности.

• И налог с продаж. Его пришлось протянуть во всех регистрах. Особенно неприятно было то, что его пришлось тянуть в регистр «Выручка и себестоимость продаж», который дозаполняется в процедуре закрытия месяца. При первом закрытии месяца выяснилось, что алгоритм просто очищает данные этого ресурса – пришлось дорабатывать процедуру расчета себестоимости, чтобы система видела ресурс, добавленный нами.

Подробности доработки под accruals.

Подробности доработок по инвентарным резервам.

Подробности доработок по налогу с продаж.

Теперь про закрытие месяца.

В части регламентированного учета эта процедура на 99% типовая – наши доработки существенно на закрытие месяца не повлияли. Но есть нюансы, конечно.

Поскольку в скоуп проекта не входил налоговый учет, документы по закрытию финрезультатов и по закрытию доходов и расходов мы не дорабатывали. В результате оказалось, что счета доходов и расходов автоматически не закрываются. В оперконтуре распределение затрат работает и все закрывается, но счет доходов не закрывается. И проводки автоматом по документу «Распределение доходов» не формируются.

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

И добавили команду в документе «Операция». Бухгалтерия проводит эту операцию и дальше считает налог на прибыль.

Как обновляться? А никак. Конфигурация необновляемая. Об этом было заранее известно, это было заранее понятно.

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

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

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

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

Препятствия, ошибки, провалы

Факапы… Куда же без них?

• Было очень много ошибок в проводках при определении счетов учета из нашего нового регистра. Конечно, при тестировании что-то отловили, но не все. Из-за того, что при сопоставлении регистров соединение в запросе не всегда происходило по всем полям, происходило умножение количества и суммы в проводке – в 3, в 4, в 800 раз. В первый раз разработчик долго искал эту ошибку, а потом уже стало понятно – где исправлять. Но в первый месяц мы словили очень много таких ошибок.

• Много было ошибок из-за хардкода, когда пользователи жаловались, что не могут выбрать счет учета – его нет в списке. Потом везде, где можно, добавили, но до запуска все это отловить не удалось.

• Был эпик фейл, который потребовал доработки в процессе закрытия месяца. Когда на старте проекта заказчик задал вопрос: «А нам не надо заводить отдельные статьи расходов для 26 и 20 счета (для общехозяйственных и для производственных)?», ему сказали: «Нет, не надо». Заказчик завел общие статьи, все протестировали, согласовали – размножить уже нет возможности. И тут за пару месяцев до запуска выяснилось, что все статьи, которые могут вообще попадать на 20 счет – все производственные. Т.е. они не разделили зарплату производственных рабочих, зарплату АУП, зарплату айтишников – у них была одна статья «Зарплата». В результате мы сделали костыль в процедуре закрытия месяца. Хороший, надежный, работающий костыль. Берем остатки по регистру «Прочие расходы», получаем список статей по всем затратам, которые отражены в непроизводственных подразделениях и сами не закрываются, и списываем типовым документом «Списание на расходы». И все это в процедуре закрытия месяца. Можно было бы делать такое исправление и вручную, но мы автоматизировали ручную работу пользователей. В итоге получили нормальные закрытия.

• В первом закрытии месяца мы выловили еще одну проблему – у нас по аккруалам есть парочка нетиповых документов, которые пишут в регистр «Прочие расходы». Но мы не учли, что ресурс «Сумма без НДС» заполняется только для производственных затрат, и у нас система ругалась на неверное заполнение суммы. Пришлось там поправить.

• И еще одна неприятная история – это отгрузки в старой системе, по которым нужно делать возвраты. Мы их грузили стандартно – документами «Реализация товаров и услуг» без движений. Но у нас был один нюанс – система формировала возвраты от клиентов полностью автоматически. Но чтобы себестоимость считалась корректно, в «Возвратах от клиентов» необходимо корректно заполнять ТЧ «Виды запасов» – очищать ссылку на РТУ, по которой формируется такой возврат, чтобы система брала себестоимость напрямую, а не пыталась искать эту несуществующую на тот момент себестоимость в регистре. При первом закрытии месяца мы эту ошибку словили и исправили.

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

Результат и планы на будущее

Результат:

• Несколько раз откладывали переход на новую систему: в феврале 2022 года мы не запустились, потому что не успели что-то протестировать; в апреле у заказчика были проблемы с оборудованием в ЦОД – у них ЦОД в Лондоне; в мае почему-то решили не запускаться; в итоге запустились с июля.

• Запустились очень успешно – у нас ни разу не вставали склады, у нас ни разу не остановилось производство, у нас ни разу не встали отгрузки. У заказчика очень хорошая регламентация процессов – они вели KPI по всем своим блокам, и потеря для бизнеса по вине проекта за все это время составила 500 долларов. Учитывая их объемы, это, конечно, мизер – можно считать, что это даже меньше 1%. Никто не знает, чего это стоило для команды-интегратора, но для бизнеса, в общем, все прошло более-менее.

• В Казахстане мы запускались 4 января 2023 года. В Казахстане было проще, потому что у них нет производства – мы не грузили производственные мастер-данные, и целый блок выпадает.

• Фактические трудозатраты проекта – примерно 51 тысяча человеко-часов.

• Все это время мы постепенно передавали сопровождение системы на поддержку ИТ-службе заказчика – по блокам, по подфункциям. Сейчас передача знаний завершилась, и они уже самостоятельно тиражируются на Узбекистан и Азербайджан.

• Запуск по Узбекистану назначен на июнь 2023 года. Команда заказчика сама взяла эти затраты на себя – мы им передали всю информацию, и они уже обучают пользователей, у них все готово. Они уже мастер-данные перенесли, теперь собираются переносить остатки. Потом в июле – Азербайджан, Грузия, Белоруссия, Таджикистан.

Вопросы

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

У нас функциональность закупок практически типовая.

Получается, что нарушается первый стандарт?

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

А когда у них финансовый год заканчивается? Апрель?

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

Получается, аудит они не пройдут.

Пройдут, пройдут, не переживайте, у них бизнес-эксперты есть.

На момент, когда принимали решение о том, как реализовывать, вы уже знали, что не потребуется обновление конфигурации? Или отказ от обновления – это был выбор между реализацией и обновлениями?

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

Здесь большую роль сыграло то, что у них нет выгрузки регламентированной отчетности из 1С. Для большинства это важно. Для них не так. Они продолжают работать со своим налоговым порталом – с аналогом нашего «Контур-экстерна». Они собирают данные по оборотке и вручную заносят туда.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции «Анализ & Управление в ИТ-проектах» 2023.