Свертка базы 1С:ERP

Вступление

В данной статье будет рассказано о процедуре свертки (обрезки) «1С:ERP», то есть об уменьшении размера базы данных и архивирования старых периодов в отдельную копию информационной системы. Здесь мы постараемся рассказать о том, зачем вообще предприятию может понадобиться такая свертка, какую пользу от обрезки предприятие может получить. Также в рамках статьи будут разобраны проблемы, возникающие в процессе выполнения данной задачи и будут приведены пути их решения. Описание будет идти на примере разработки механизма обрезки для завода АО «Редуктор». В этом проекте был создан свой собственный механизм обрезки, который частично базируется на типовой свертке, предоставляемой фирмой «1С» вместе с конфигурацией «1С:ERP». Мы подробно объясним, почему пришлось отказаться от типовой обработки и какую ее часть все-таки использовали в рамках нашего решения.

Задача свертки базы данных в АО «Редуктор»

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

В качестве примера возьмем завод АО «Редуктор», на котором рассматриваемая манипуляция была нами проведена. Основной причиной обрезки здесь явилось то, что на момент начала опытно-промышленной эксплуатации системы не была согласована учетная политика работы в «1С:ERP» и пользователям не было до конца понятно, как предприятие будет работать в новой программе, что потребовало неоднократной перенастройки системы уже на «живой» базе. В частности, был произведен ряд действий, которые в принципе нельзя выполнять в работающей системе. Примером таких действий явилось включение и последующее отключение настроек по видам номенклатуры, которые влияют на то, как остатки товара хранятся в системе (был включен серийный учет по определенным видам номенклатуры, потом серийный учет был отключен; то же самое произошло и с характеристиками – какое-то время номенклатура существовала в базе данных с характеристиками, потом учет по характеристикам был отключен). Так делать нельзя –  большая часть настроек системы должна производиться до начала ее эксплуатации, а после начала эксплуатации изменять их уже нельзя. Так получилось, что в АО «Редуктор» эти правила были нарушены и из-за этого остатки, находящиеся в системе – остатки по товару, остатки по взаиморасчетам (был исправлен также порядок расчетов по договорам) были некорректны и исправить их типовыми средствами было невозможно. Требовалось регулярно проводить ручные корректировки регистров, для чего необходимы высококвалифицированные специалисты, что достаточно дорого для завода.

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

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

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

По масштабам задачи, выполненной нами в АО «Редуктор», можно сказать следующее:

• В момент обрезки базы она содержала 800 Гб данных.
• Предприятие работает в режиме «24 на 6», следовательно есть только одни сутки для проведения каких-либо манипуляций в программе.
• Завод выполняет государственный оборонный заказ, выпускает точные приборы, поэтому какие-либо сбои или проблемы в работе, в том числе в информационной системе, крайне нежелательны.

Зачем предприятию обрезка базы данных

Несколько слов нужно сказать о том, зачем Вам вообще может понадобиться обрезка базы данных «1С:ERP».

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

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

В качестве реалистичных ожиданий от свертки можно определить следующие результаты:

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

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

Ограничения типовой свертки системы «1С:ERP»

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

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

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

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

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

Решение проблем свертки АО «Редуктор»

Чтобы преодолеть ограничения типовой свертки, в рамках проекта обрезки базы данных «1С:ERP» завода АО «Редуктор», был принят ряд стратегических решений. Прежде всего, были приняты решения организационные – мы максимально исключили проблемные ситуации, неподдерживаемые типовой сверткой. То есть, максимально убрали все незавершенные операции. В технической части мы доработали типовую свертку таким образом, чтобы можно было выполнить необходимые действия по переносу незавершенных операций производства (которые исключить было нельзя) и по делению процедуры обрезки на части для последовательного запуска в доступное время. Также мы создали ряд инструментов для автоматизированной проверки качества обрезки, чтобы сверять остатки в системе с эталонной базой данных.

Были приняты следующие организационные решения:

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

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

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

Техническое решение было еще более сложным. Начнем с концепции – что мы хотели получить от обработки по свертке базы данных в итоге:

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

Деление свертки на независимые разделы было выполнено следующим образом. Мы выделили в системе относительно независимые разделы учета:

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

Шаги по каждому разделу выглядят следующим образом:

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

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

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

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

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

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

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

Те, кто знаком с архитектурой системы «1С:ERP», в данный момент скорее всего задаются вопросом, каким же образом мы определяли для каждого раздела какие регистры и как нужно сторнировать. Это самая сложная часть задача, здесь нам пришлось провести аналитическую и техническую работу, в рамках которой мы написали обработки, собирающие по документам, подлежащим сторнированию, все комбинации движения по регистрам (какие регистры и каким образом двигались документами). Каждый документ был привязан к той или иной комбинации. Далее для каждой комбинации мы создали обратную итоговую сторнировочную запись оптом по всем связанным документам, и она вносилась в базу данных в виде ручной корректировки записи регистра.

Перенос незавершенного производства

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

Это следующие разделы незавершенного производства:

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

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

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

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

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

Последний и самый масштабный раздел незавершенного производства – партии производства, которые не были завершены на момент свертки.

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

Мы сделали это и наш инструмент заработал следующим образом.

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

С учетом всего описанного ранее, количество шагов по свертке НЗП у нас было четыре.

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

Практические рекомендации по выполнению свертки

На основании собственного опыта мы можем дать следующие рекомендации:

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

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

Следует создать копию базы и использовать внешнее подключение для проверки остатков регистров накопления в базе после свертки и в эталонной базе.

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

Дополнительные материалы

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

Итоги работы

Свертка базы АО «Редуктор» завершена, эта работа заняла у нас шесть месяцев. Сами обработки были написаны нами за два месяца, четыре месяца заняла сама свертка и обрезка. Работа по обрезки базы могла быть выполнена значительно быстрее, но манипуляции с базой можно было производить только в ограниченные промежутки времени.

Сейчас база данных «1С:ERP» занимает в 10 раз меньше места, чем раньше, устранены все ошибки и достигнуты все цели, заявленные заказчиком, система работает в штатном режиме.