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

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

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

Стратегии переноса: использовать типовой или сделать свой?

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

• Если Вы переносите остатки на конец года после Закрытия года;
• Если у Вас однородные настройки по сериям, характеристикам, признакам алкогольной продукции, ГТД, наборам дополнительных свойств внутри вида номенклатуры в 1С:УПП;
• Если у Вас нет недопоставленных заказов клиентов, поставщикам;
• Если у Вас нет расхождений между регламентированным и управленческим учетом;

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

Сама обработка переноса хранится здесь: ХХХХХХ\tmplts\1c\Enterprise20\Версия ERP\AddFiles\Переходы с других конфигураций\\УПП_КА1\. Обработка появляется в этом каталоге, когда программа устанавливается на компьютер с помощью файла setup (полная установка) актуальной версии ERP. Файл полной установки можно скачать с сайта https://releases.1c.ru/total при наличии действующей подписки ИТС и приобретенной программы.

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

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

Советы по переносу констант и справочников

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

• Отключите выгрузку констант в настройках и сделайте всё самостоятельно – заполните константы вручную. Это будет менее трудоемко, чем потом править косяки переноса;
• Организации тоже лучше занести самостоятельно – типовой перенос не переносит все учетные политики и прочую сопутствующую информацию;
• Структура предприятия переносится типовым переносом, но без признаков производственных подразделений – расставьте их самостоятельно;
• Склады (места хранения) переносятся удовлетворительно, но ячейки нужно настроить отдельно. Очень рекомендуется завершить ввод ордеров в 1С:УПП при использовании ордерной схемы;
• Контрагенты переносятся без разделения по партнерам. Делить надо вручную. Доп. свойства и характеристики не переносятся;
• Договоры переносятся, но надо обязательно проверить ГФУР (группы финансового учета расчетов) - лучше вообще создать их заранее в ERP и настроить правила переноса. Реквизиты для ГОЗ тоже надо заполнить вручную;
• На каждого партнера-покупателя при переносе создаются индивидуальные соглашения. Типовые соглашения надо создавать вручную;
• ОС и НМА переносятся остатки всегда с ошибками - проверяем перенос путём начисления амортизации;
• Статьи расходов после переноса нужно перепроверить, а лучше создать вручную. Тем более каждую статью после переноса мы настраиваем индивидуально: указываем правила распределения, ГФУДР и пр.;
• Статьи ДДС переносятся хорошо, но без настройки ограничений по хозяйственным операциям;
• Бюджетирование хоть и переносится, но лучше не переносить – настраиваем его отдельно в 1С:ERP.

И отдельно про перенос справочника "Номенклатура":

• Виды номенклатуры переносятся штатным образом, но наша рекомендация - создать виды номенклатуры в 1С:ERP вручную и настроить правила обмена так, чтобы именно они использовались при загрузке данных;
• Создайте ГФУН (группы финансового учета номенклатуры) в 1С:ERP вручную и настройте правила обмена так, чтобы они использовались при загрузке данных, или удалите лишние в 1С:ERP после загрузки, предварительно обработкой заменив их на правильные;
• Если серии у Вас использовались только для хранения ГТД – исправьте правила обмена так, чтобы они не задействовали справочный серийный учет.
• Обратите внимание на упаковки и единицы измерения – скорее всего, правила выгрузки придется доработать. Есть проблемы с "размножением" упаковок и единиц измерения при штатном переносе – они создаются отдельно для каждой единицы номенклатуры.

Советы по переносу остатков

Основными данными для переноса считаются данные остатков счетов регламентированного учета. Там, где это возможно, переносятся остатки по управленческому учету.

При переносе остатков стоит помнить о следующих нюансах типового переноса:

• Отрицательные количественные или суммовые остатки по товарам и расчетным счетам не переносятся. Также не переносятся нулевые остатки.
• Остатки по счетам учета производства не переносятся.
• На счетах учета товаров в информационной базе-источнике должен быть включен суммовой учет по складам. Иначе не будет определен суммовой остаток товаров в разрезе складов, и сами товары не будут выгружены. После установки суммового учета по складам необходимо перепровести документы, если ранее суммовой учет не бы включен.
• Остатки по НЗП по 20 и 23 счетам переносятся только проводками.
• Остатки невыполненных заказов переносятся, но без установки резервов. Ставим резерв самостоятельно после переноса остатков по ТМЦ.
• Если по данным управленческого учета количественные остатки больше, разница записывается на предопределенную Управленческую организацию. Таким образом, после переноса остатки совпадут по регламентированному и управленческому учету.
• Если количественные остатки по регламентированному учету были больше, то произойдет коррекция данных управленческого учета - остатки по управленческому учету приравняются к регламентированному учету. Если не планируете в ERP использовать Управленческую организацию, то перед переносом выверяйте и "равняйте" остатки по видам учета.

• Разницы между УУ и БУ не переносятся. И это нерешаемая проблема. Поэтому перед переносом максимально сверяем и устраняем все разницы между бухгалтерским и управленческим контуром. Остальное принимаем как данность.
  

Проблемы переноса и общие рекомендации

При подготовке переноса нужно продумать и учесть ряд технических и методических моментов.

• Обновляем релиз УПП до последнего – для корректной работы правил переноса.
• Обязательно проводим нормализацию данных в базе-источнике: устраняем отрицательные остатки ТМЦ, устраняем расхождения УУ и БУ, выверяем расчеты с контрагентами, устраняем расхождения между регистрами и проводками.
• Перенос делаем только после закрытия месяца в исторической системе.
• Перенос делаем из эталонной копии базы. Это нужно для облегчения сверки и исключения ситуации, когда кто-нибудь изменит данные "задним числом".
• На перенос требуется время. Обычно мы буквально по дням и часам планируем, когда и как будем осуществлять перенос. Если объем данных большой, то лучше разбить его на отдельные блоки: сегодня переносим номенклатуру, завтра - контрагентов, послезавтра – остатки и т.д.
• Нехватка памяти при переносе большого количества данных - лучше сделать пробный перенос, чтобы понять, как вообще "ворочается" база и есть ли, риск, что все может обвалиться на 97 процентах прогресса. Если подобные риски есть, то привлекаем технических специалистов и работаем над быстродействием баз и сервера.
• Невозможно догрузить добавленные или измененные справочники после того, как был выполнен перенос НСИ - тут смотрите предыдущую главу. Перенос справочников моделируем и планируем особенно тщательно, чтобы не переносить по несколько раз тот же справочник "Номенклатура".
• Невозможно перенести документы - сейчас разрабатываются новые методики переноса, которые могут позволить перенос документов (Синхронизация через EnterpriseData), но пока к ним доверия особого нет. Документы никогда не переносили и не советуем. Многие документы переносятся с незаполненными или неверно заполненными данными.

• В связи с применением разных методик и способов учета ТМЦ, основных средств, взаиморасчетов и т.д. данные после переноса могут отличаться - это нужно понять и принять. И самое главное – донести до пользователей, которые будут проверять перенос. Яркий пример: в УПП были контрагенты, а в ERP теперь есть Партнеры и контрагенты. И как теперь мы будем сверять взаиморасчеты по партнеру, который может включать в себя несколько контрагентов? Вырабатываем методику, согласовываем ее с профильной службой, проводим перенос и проверяем данные, согласно методике. Просто сверить цифры в УПП и ERP в этом случае не получится.
• Различия в методиках управления производством делают невозможным перенос информации о производстве. Методики управления производством в ERP настолько отличаются от УПП, что вносить их в структуру типового переноса бессмысленно и опасно. Производственные справочники и невыполненные заказы вносим и настраиваем строго вручную, согласно ранее согласованному Техническому заданию.

Дублировать или нет – вот в чем вопрос?

При переходе на новую программу часто у сотрудников предприятия возникают опасения: а вдруг новая не взлетит, а мы старую программу уже похоронили? Может, стоит пока поработать в обоих программах, пока не придет полная уверенность в успехе?

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

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

Минусы:

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

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

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

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

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

Общие рекомендации коллегам по переносу данных

• Трудозатраты на перенос нужно планировать в двойном объеме: для тестового переноса и финального "чистового". Это окупится вдвойне, поверьте.
• Продумывайте все условия переноса: ряд рекомендаций, которые нужно обязательно учесть, мы дали в этой статье. Об остальных нюансах рассказываем на нашем авторском курсе "Переход с 1С:УПП на 1С:ERP".
• Часть остатков можно просто перенести вручную: если данных относительно немного – не заморачивайтесь обработками и последующей проверкой. Остатки по денежным средствам, подотчетникам, налогам и взносам - быстро можно забить вручную и не вспоминать о них.
• Иногда нужен повторный перенос или актуализация (дебиторская задолженность, остатки ТМЦ и пр.) – обсудите этот момент с вашей командой. Например, остатки ТМЦ и дебиторской задолженности при интенсивном документообороте нужны с первого дня работы системы, и мы их обязательно сразу переносим. Но бухгалтерия может потом на протяжении месяца-двух-трех ещё уточнять остатки, проводить документы прошлых месяцев. Это потребует потом переноса обновленных остатков.
• Не надо переносить обороты прошлого (данные БУ и НУ и пр.) – это ошибка. Типового переноса такого рода информации нет – придется писать обработку с нуля. А разные архитектуры конфигураций и принципы учета кратно усложнят эту задачу. Поэтому добиться того, чтобы данные по оборотам сошлись с исторической системой – это тот еще веселый квест. В итоге – масса устаревшей НСИ из прошлой системы и огромные трудозатраты. Исключение составляют данные об оборотах затрат и данные продаж прошлых периодов – для этого в ERP есть специальные документы
• Защищайте источники переноса – закройте для пользователей эталонную базу или установите дату запрета редактирования. Иначе при сверке долго будете искать концы, пока в рабочей бае пользователи весело исправляют данные предыдущих периодов.