Переход с УПП на ERP с сохранением документов. Фантастика или реальность?

 

 

 

 

Последние шесть лет мы специализируемся на проектах перехода на новые конфигурации 1С и помимо «Конвертации данных» все больше используем дополнительные инструменты для автоматизации выгрузок и выверок данных.

---

Видеозапись доклада можно посмотреть на отдельной странице >>

---

 

Наша команда имеет уникальный опыт по проектам перехода с УПП на ERP с сохранением документов – мы помогли выполнить более 700 проектов по переходу и лично выполнили десятки.

В официальной документации отсутствует информация о том, как переносить документы между УПП и ERP. Этого не найти на ИТС и даже в отчетах о подобных проектах перехода от наших коллег, которые есть на Инфостарте.

 

Почему вопрос перехода с УПП стал актуальным

Есть официальное информационное письмо фирмы «1С» о том, что УПП планируется снять с поддержки весной 2026 года.

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

 

На какую конфигурацию переходить с УПП? Какие есть варианты?

 

 

Многие конечные заказчики даже не предполагают, что можно переходить не только с УПП на ERP.

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

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

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

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

 

Методика переноса данных

 

 

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

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

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

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

Но в ERP с этим есть сложность – перенести историю бухгалтерскими операциями нельзя, регламентированный учет в ERP вторичен. Если перенести какие-то исторические данные в документы «ОперацияБух», эта информация при закрытии месяца будет проигнорирована, потому что регламентная операция «Закрытие месяца» ориентируется только на управленческие регистры.

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

 

Порядок перехода компании на ERP

 

 

Есть три возможных сценария перехода на ERP:

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

• Другой сценарий – когда в ERP не начинают вести учет с 9 января (с начала года), а начинают вести учет только после закрытия года в старой базе. Так как в этот момент еще первый квартал не закрыт, то в момент, когда закрыт год в УПП, переносятся остатки на 1 января и все документы за первый квартал.

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

 

Кому поручить проект перехода

 

Как организовать ресурсы для проекта перехода с УПП.

• Если есть возможность, с проектом перехода хорошо справится внутренняя команда самого предприятия.

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

• Самым оптимальным является комбинированная схема, когда в реализации основного объема задач по переходу участвует нанятая компания подрядчика, а остальные задачи по организации процесса и контроля реализуют внутренние специалисты предприятия. Это правильно, потому что внутренние специалисты знают всю специфику деятельности, знают, без чего пользователи не смогут работать, вести учет в базе. А внешние подрядчики могут иметь хороший опыт выполнения таких проектов. Если вы будете находиться в поиске такой компании, обратите внимание, что корпоративный отдел Инфостарта имеет статус «Центра компетенций по ERP» и занимается проектами перехода с УПП на ERP.

 

Методические отличия при ведении учета и способы их устранения

 

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

 

Ручные операции

 

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

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

 

Счета учета и курс взаиморасчетов

 

 

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

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

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

В ERP аналог корректировки долга – это документ «Взаимозачет задолженности», но он с такими настройками, разумеется, не проведется, воспроизвести такую ситуацию в ERP не получится.

 

Инвентаризация

 

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

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

Наша рекомендация – или не переносить инвентаризации, или переносить непроведенными.

 

Оприходования и списания

 

 

Следующий момент – документ «Оприходование излишков товаров».

В ERP он формирует движения по регистру бухгалтерии, регистрам «Товары организаций» и «Себестоимость товаров», но не формирует движений по регистру «Товары на складах».

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

И, соответственно, «Списание товаров» переносить в «Пересчет товаров» плюс «Списание недостач товаров».

Тогда вы получите аналогичные движения по всем регистрам.

 

Выпуск продукции

 

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

Только документ «Оприходование материалов из производства» мы рекомендуем переносить в документ «Выпуск продукции». В остальных случаях мы рекомендуем использовать документ «Производство без заказа».

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

 

Требование-накладная

 

 

Еще в ERP нет документа с названием «Требование-накладная». В зависимости от счетов затрат, которые указаны в строках табличных частей, мы рекомендуем переносить либо в документ «Списание товаров», либо в документ «Передача материалов в кладовую»:

• если 20-й счет – значит, документ «Передача материалов в кладовую»;

• если 26-й счет, значит, документ «Списание товаров».

 

Поступление товаров и услуг и Авансовый отчет

 

Аналогичная ситуация с документом «Поступление товаров и услуг». Его аналог в ERP – это «Приобретение товаров и услуг».

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

Похожая ситуация с документом «Авансовый отчет». В УПП он содержит табличную часть «Товары», которые приобрел подотчетник. В ERP есть отдельная операция «Приобретение товаров и услуг» с видом операции «Закупка через подотчетное лицо».

 

Счет 08.04

 

Следующая ситуация, которая принесла нам некоторое количество боли – счет 08.04 (строительство основных средств) разделился на два субсчета:

• если вы в дальнейшем хотите использовать основное средство в комплектации, его закупка производится документом «Приобретение товаров и услуг» на счет 08.04.1

• а если вы хотите использовать основное средство при принятии к учету ОС, его нужно приобретать документом «Приобретение услуг и прочих активов» на счет 08.04.2.

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

В УПП основное средство, на которое будете списывать номенклатуру, вы указываете только в документе «Принятие к учету ОС».

Данную ситуацию можно разрешить программно – в момент выгрузки из УПП можно посмотреть, куда будет списан данный закупаемый товар, при строительстве какого основного средства он будет использован. И сразу же создавать программно документы приобретения с указанием этого основного средства.

 

Возвраты

 

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

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

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

 

Корректировки приобретения и реализации

 

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

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

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

 

Справочник «Партнеры»

 

 

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

Что можно с этим сделать? Нужно придумать алгоритм.

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

Или иногда мы создавали одного-единственного головного партнера, привязанного к контрагенту, к которому создавали подчиненных партнеров для каждой торговой точки – когда учет в УПП велся корректно, мы создавали головного партнера по группе.

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

 

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

 

 

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

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

• Конечно же, в реальной информационной базе УПП может быть такое, что у заказчика не по всем товарным регистрам есть корректные остатки. Какие есть товарные регистры? В случае, если используется партионный учет, это «Товары на складах», «Партии товаров на складах» и «Товары организации». Если используется РАУЗ, то это два регистра – «Учет затрат» и «Учет затрат регл». Следовательно, с этим вопросом нужно определиться – в каких отчетах сам заказчик контролирует актуальные остатки и оперативно их отслеживает, чтобы выгружать информацию уже из этих регистров. И, конечно же, нужно помнить, что в таких регистрах как «Товары на складах» и «Товары организаций» нет ресурса «Себестоимость», вам придется придумать, откуда, из какого другого регистра или типа цен брать себестоимость при переносе данных в ERP.

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

 

Решение проблем производительности процесса переноса

 

 

Конечно же, на таких проектах возникает большое количество технологических проблем, сложностей со временем, которое требуется для такого переноса данных. Потому что правила конвертации написаны в «Конвертации данных 2», а правила конвертации КД2 – это большое количество запросов в цикле, не самый оптимальный алгоритм. Поэтому возможны проблемы производительности:

• Крайний случай, с которым мы на реальном проекте сталкивались, когда документы организации за одни сутки (1 января, не самый активный день) выгружались целых 12 часов. Сразу понятно, что здесь дело не в правилах конвертации, которые мы используем, потому что они стандартные, проверенные, в них проведена некоторая оптимизация. Проблема связана с производительностью сервера 1С у заказчика – нужно что-то делать, перемещать на другой сервер.

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

• Быстрее всего загрузка данных работает для базы в файловом варианте и однопользовательском режиме. Перенос данных – это однопоточная работа (понятно, что во время переноса никто еще пока у вас не работает в базе) и для хорошей производительности достаточно иметь не самый лучший серверный процессор, а какой-нибудь i7 или i9 из последних – там очень высокая тактовая частота. И лучше будет, если файловая база 1С лежит на быстром SSD-диске. Поэтому, если у вас приемлемый объем информации, как у большинства средних предприятий, первичный перенос данных лучше выполнять в ERP, которое развернуто в файловом варианте. Когда ERP у вас еще пустая, вы только начинаете перенос, как правило, она с этим справится – база помещается. В этом случае вы получите самую быструю производительность выполнения как выгрузок, так и загрузок данных. Выгрузок у вас не получится, потому что как правило, УПП в файловом варианте не встречали.

 

Технические проблемы

 

 

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

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

Конечно же, при возможности, перейти на самый производительный сервер 1С, который есть.

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

 

При выполнении загрузки данных в УТ11, КА2 и ERP мы часто встречали ситуацию, что процесс прекращается из-за блокировок. При разборе ситуации мы выяснили, что блокировки возникают из-за фоновых заданий, которые запущены регламентными запланированными заданиями.

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

 

 

На скриншоте также приведена часто встречающаяся ошибка «Ошибка при выполнении запроса POST». Очень сложно понять реальную причину ее возникновения – почему так происходит.

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

 

 

Часто встречается ошибка с текстом «Ошибка при попытке вставки записи с неуникальным значением ссылки». Эта ошибка часто проявлялась и раньше, например, при стандартных обменах на КД2.

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

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

Также это может происходить, если у вас несколько правил конвертаций для одного вида объекта.

 

Методика ввода начальных остатков

 

В любой момент времени правильную методику ввода начальных остатков лучше смотреть на ИТС, потому что ERP активно меняется, разрабатывается. То, что было в 2.4, в редакции 2.5 уже неактуально.

 

Плавный переход на ERP

 

 

Некоторые методологические идеи можно почерпнуть из официального доклада фирмы 1С от 2019 года о том, что в УПП и ERP есть план обмен «СинхронизацияДанныхЧерезУниверсальныйФормат», использующий обмен через формат EnterpriseData. И по идее, в дальнейшем, уже после переноса остатков, документы можно переносить с помощью вот этого встроенного стандартного переноса данных.

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

 

 

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

Например, часто сначала переносят зарплатный контур, потому что в ЗУП3 и в ERP интерфейс аналогичен, а потом, например, переводят подсистему «Склад».

 

Выверка документов после переноса — сотни часов работы специалиста 1С или можно сделать автоматически?

 

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

 

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

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

Он работает через COM-подключение и тянет эту информацию из базы-источника – по GUID сравнивает номенклатуру, сверяет остатки.

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

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

 

Вопросы

 

Насколько сильно отличаются сроки и бюджет на перенос в процентном соотношении, если переносить классически (только остатки и справочники) или переносить вместе с документами. Сильная ли разница?

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

Отвечая на вопрос – бюджет может быть значительно выше, примерно в три раза. И то, если документы переносятся всего за один квартал. За годы мы просто не беремся.

А отдельно по месяцам вы документы переносите?

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

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

Обычно на момент перехода есть практика – некоторое время вести учет параллельно в двух системах. Интересует вопрос – насколько часто практикуется перегрузка введенных документов из УПП в ERP, если их ведут пока еще в старой системе? Насколько это в принципе трудоемко и реально сделать? Одно дело – остатки за закрытый период, а другое дело – документы за незакрытый месяц.

Для решения задачи, про которую вы говорите, можно попробовать настроить обмен в универсальном формате. Я упоминал доклад от фирмы «1С» с названием «Плавный переход с УПП на ERP». Доклад на 51 слайд, где подробно рассказано про возможности, которые позволяют это реализовать – фирма «1С» их добавила еще в 2019 году.

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

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

Вы говорите о том, что если мы переводим учет номенклатуры в ERP, то в УПП ее нужно выгружать из ERP в обратную сторону?

Да, так тоже делают, когда проводят плановый переход. В упомянутом докладе от фирмы «1С» есть официальная информация, что УПП и ERP это умеют делать.

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

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere.