Как Магнит перевел теплицы на промышленную платформу?

11 Августа, 2022

Тепличный комплекс "Зеленая линия", входящий в сеть "Магнит", перешел на современное отраслевое решение "1С:ERP Агропромышленный комплекс". Особенности производства потребовали доработки типового инструмента, самая интересная задача проекта, которая была решена, - распределение и списание затрат на неравномерный цикл плодоношения растений.

Тепличный комплекс "Зеленая линия" включает в себя несколько производственных площадок для выращивания томатов, огурцов, баклажанов, салата и грибов. Все площадки расположены в Краснодарском крае, спроектированы по передовым технологиям, оснащены современными автоматизированными системами полива, отопления, освещения и вентиляции. Грибное предприятие осуществляет полный цикл производства - от изготовления компоста до упаковки и реализации готовой продукции. Всего в 2021 году собственные агропромышленные предприятия "Магнита" произвели почти 100 тысяч тонн овощей и грибов.

До внедрения все учетные процессы производства "Грин Лайн" с разной степенью автоматизации велись в программе "1С:Управление сельскохозяйственным предприятием" (1С:УСПП). Но с апреля 2022 года "1С" прекратила поддержку этой программы, так как она была реализована на устаревшей версии ERP-решения "1С". Для предприятия это означало, что в будущем ему придется самостоятельно вносить все законодательные изменения в программу. Решение "1С:ERP Агропромышленный комплекс" (далее 1С:ERP АПК) наиболее полно соответствовало требованиям бизнеса. Обсудив возможные риски и приняв во внимание, что разработчиком программы являлась компания "Черноземье ИНТЕКО", а также предыдущая программа 1С:УСАХП, руководство "Магнита" приняло решение о переходе на новую систему.

К началу календарного года

Цель проекта: осуществить перевод предприятия "Зеленая линия" на новую учетную систему, сохранив существующий функционал в 1С:УШП. По словам Сергея Устименко, руководителя отдела развития информационных систем производственных комплексов компании "Магнит", для финансовых служб было принципиально важно выполнить переход на новую систему в начале календарного года, чтобы годовая отчетность формировалась из одной системы. Мы определили срок - начать вести учет в 1С:ERP АПК с января 2021 года.

Для выполнения этой задачи необходимо было подготовить механизмы переноса остатков на 1 января 2021 года, разработать и согласовать с бизнесом целевые модели учета, адаптировать в новой системе ранее доработанный в 1С:USAHP нетиповой функционал.

Помимо собственной команды, компания Dialog IT была приглашена в качестве субподрядчика для выполнения работ.

"Наша компания давно сотрудничает с компанией "Информационные технологии Магнит" (ИТМ) в области разработки различных проектов и сопровождения информационных систем на платформе "1С:Предприятие", - говорит Павел Тагиев, руководитель группы в компании "Диалог ИТ". - Нам, безусловно, интересны такие масштабные проекты, как полный переход на новую систему, поскольку они помогают реализовать потенциал наших специалистов, выполняющих проекты различной сложности".

Со стороны "Магнита" для реализации проекта была выделена собственная команда из шести человек, со стороны "Диалог ИТ" работали две команды - одна занималась блоком кадрового учета и расчета заработной платы, вторая - остальными блоками.

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

Активная фаза проекта длилась с апреля 2020 по апрель 2021 года. К концу четвертого квартала 2020 года все необходимые инструменты были протестированы, и 1 января 2021 года пользователи начали вести учет в 1С:ERP AIC.

"Мы заранее договорились с бизнесом, что какое-то время придется вести двойную бухгалтерию для сверки результатов, - рассказывает Сергей Устименко. - К февралю 2021 года нам удалось добиться того, что "1С:ERP Агропромышленный комплекс" стал первоисточником, а "1С:УСХП" просто дублировал данные".

Подготовка к сбору урожая

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

Производственный цикл в теплице длится несколько месяцев и состоит из двух этапов.

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

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

В процессе анализа производственных циклов были выявлены дополнительные сложности, например, в одной теплице можно выращивать несколько культур с разными циклами плодоношения. "Мы смоделировали задачу на типовом расчете себестоимости в новом АПК "1С:ERP", также проработали схему долгосрочного производства, но выполнить задачу в рамках типовых решений не удалось", - говорит Сергей Устименко. - После тестовых сборок моделей учета и обсуждения полученных результатов было принято решение построить учет на стандартных механизмах 1С:ERP AIC, а управление стандартными документами осуществлять с помощью дополнительных обработок".

Как вы распределяете расходы?

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

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

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

Возникает вопрос: как перенести затраты с непроизводственной единицы, не имеющей выпуска, на производственную единицу?

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

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

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

В результате такого пошагового подъема на один уровень выше всегда можно найти единицу продукции, на которую можно отнести эти затраты.

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

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

По циклу плодоношения

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

В план выхода включаются подразделения, по которым ожидается производство, - поясняет Сергей Устименко. - В течение всего подготовительного периода в подразделении накапливаются затраты, которые механизм распределения стандартных затрат не может потребить, потому что нет выпуска. Если вы делаете выпуск, то при расчете нормативных затрат все накопленные затраты сразу относятся на текущий месяц, но этого делать не нужно. Только часть накопленных затрат, пропорциональная выпуску этого месяца, должна быть отнесена на выпуск текущего месяца. Поэтому в плане указывается процент выпуска готовой продукции за месяц от общего прогнозируемого объема выпуска за весь производственный цикл. Документы распределения затрат формируются стандартными способами, но процент незавершенного производства корректируется с помощью информации из плана. Из-за процента незавершенного производства и процента расхода затрат, указанного в документе "Распределение затрат", стандартный механизм расчета затрат отнимает не все затраты, а только их часть, остальное будет потреблено в следующем месяце. Мы получаем правильное распределение затрат на выпуск продукции в текущем месяце, а также на выпуск продукции в последующие месяцы, пока длится цикл плодоношения".

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

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

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

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

Для нас внедрение стало новым опытом использования отраслевого решения для автоматизации управления агропромышленным комплексом, - говорит Павел Тагиев. - Особенность проекта в том, что учет был перенесен полностью, "как есть", из текущей системы, при этом перенос остатков осуществлялся с помощью конфигурации "Конвертация данных 2.0". Основные сложности заключались в большом количестве бизнес-клиентов и трудоемкости согласования учетных моделей. Ситуация осложнялась еще и тем, что 98 % работы выполнялось удаленно, и поставка готовых решений также осуществлялась удаленно. Несмотря на то, что основные задачи проекта реализованы и система находится в эксплуатации, мы продолжаем развивать функциональность программного продукта совместно с компанией ITM в соответствии с запросами бизнеса".

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