Компания заказчика вела кадры и зарплату в отдельной базе ЗУП, а остальной учёт — в ERP. Двойной ввод данных, постоянные сверки между системами, невозможность получить сводную картину. Руководство решило: хватит — переводим всё в ERP. При переносе данных за 2022—2025 годы с использованием штатных механизмов возникли многочисленные ошибки в ERP, которые непонятно как исправлять. Разобрались в проблеме заказчика, исправили ошибки и добились того, что 6-НДФЛ и расчётные листки формируются корректно, без ручных правок.
С какой ситуацией пришёл клиент
Заказчик — производственная компания из сферы текстильной промышленности с несколькими юридическими лицами.
С заказчиком работаем 8 лет по схеме аутсорсинга: некоторые специфические задачи передают нам в работу. Таким образом, имеют альтернативный источник мнений и поддержки, когда требуется помощь.
Клиент обратился с задачей провести внешний аудит базы ERP после неудачного переноса данных из 1С: ЗУП в 1С: ERP.
Изначально кадровый и зарплатный учёт в компании вели в 1С: ЗУП, а закупки, продажи, финансы и производство — в 1С: ERP. Это неудобно, потому что:
- Двойная работа. Данные о сотрудниках приходилось вносить в обе системы. Приняли человека в ЗУП — нужно продублировать в ERP. Изменилась должность — снова в два места.
- Сложно получить общую картину. Чтобы понять, сколько потратили на ФОТ в разрезе проектов или подразделений, приходилось вручную сводить данные из двух баз.
- Риск ошибок при сверке. Когда информация живёт в разных местах, рано или поздно данные начинают расходиться. А потом — разбирательства, почему в одной системе одни цифры, а в другой — другие.
Руководство решило: перевести зарплатный учёт в ERP. Данные переносили силами программистов компании заказчика через типовые инструменты переноса. В результате выявилось большое количество ошибок в ERP. Часть из них удалось устранить на стороне заказчика. Чтобы ускорить процесс и получить независимую техническую оценку, заказчик привлёк нас для внешнего аудита. По итогам аудита исправить часть ошибок доверили нам.
Какие проблемы нашли и как их решили
Важно отметить, что большинство выявленных проблем связано не с ошибками разработчиков заказчика, а с особенностями миграции исторических данных между ЗУП и ERP, а также ограничениями типовых механизмов переноса. Все это невозможно учесть, если не занимаешься такими задачами постоянно.
Проблема №1. «Битые» ссылки в документах и регистрах
После миграции база напоминала картотеку, из которой вырвали страницы:
- Открываешь документ, а вместо фамилии сотрудника надпись <Объект не найден>;
- Пытаешься перепровести начисление зарплаты — 1С выдаёт ошибку.
Таких ссылок было более двухсот. Каждую надо опознать и вместо неё подставить правильную ссылку. Титаническая работа, если делать вручную.
Как решили:
Написали обработку для поиска и замены битых ссылок, которые мешали работе. То, что не удалось исправить обработкой, поправили вручную. Но после автоматической обработки ручной работы осталось минимум.
Перепровели все документы, чтобы обновились расчёты.
Проблема №2. Фантомные доходы и налоги х2
Сверили начисления доходов. Сюрприз: у 72 сотрудников доход и налог в отчётах удвоились. При этом если открыть документ начисления — там всё верно. Цифры расходились только в сводных отчётах. Сдай бухгалтер такую отчётность в налоговую — компания получит штрафы и требования пояснений.
Как решили:
Наши разработчики провели расследование. Оказалось, проблема глубоко в регистрах (внутренних таблицах 1С). Из-за сбоя при переносе у сотрудников появились дублирующие записи в одном из регистров, откуда отчёты берут данные о начислениях. Грубо говоря, система считала одного человека за двоих.
Мы вычистили дубли — отчёты стали показывать верные цифры.
Проблема №3. Дубли базовых видов расчёта
После миграции данных в ERP появилась ошибка «Дублирование базовых видов расчетов». Пришлось выяснять, откуда происходит ошибка.
Для пользователей неприятно то, что ошибка возникает при проведении документов. И простым способом невозможно определить в чём причина.
Как решили:
Выяснили, что такая ошибка возникает, когда разные виды расчёта имеют одинаковое название. Нашли такие виды расчётов и удалили дубли.
Проблема №4. Куда исчезли выплаты?
Это была самая объёмная часть работы.
В 1С: ЗУП документ «Ведомость в банк» — это финал. Подписали ведомость = выплатили деньги.
В 1С: ERP логика строже. Ведомость — это только намерение заплатить. Чтобы система поняла, что деньги ушли, нужен банковский документ («Списание с расчётного счета») или кассовый ордер. Получается, что начисления есть, долги перед сотрудниками висят, а выплат… нет. По отчетам компания никому не платила зарплату четыре года.
Как решили:
Вручную создавать тысячи платёжек за 4 года — адский труд на несколько недель. Мы пошли другим путём:
- Написали специальную обработку, которая проанализировала все ведомости за 2022—2025 годы.
- Обработка сама создала недостающие документы «Списание с расчётного счета» и «Расходный кассовый ордер».
- Чтобы не испортить реальную банковскую выписку в бухгалтерии, мы использовали технические (транзитные) счета, которые потом закрыли.
Закрыли долги по зарплате за 4 года. Система «увидела» выплаты, сальдо по сотрудникам выровнялось.
Другие проблемы
Помимо этих проблем, были и другие, не такие интересные, но о которых надо упомянуть:
- Ошибка при проведении документов начисления зарплаты (Null в расчёте взносов);
- Ошибка «Неуникальный индекс» при подборе сотрудников в отчёт;
- НДФЛ по премиям не попадает в отчёты;
- Некоторые документы (Возврат НДФЛ, Заявление на вычет по НДФЛ, Акт приёмки выполненных работ) не были перенесены;
- Битые ссылки в регистрах сведений (не редактируются через интерфейс);
- другие ошибки.
Что получилось в итоге
Исправлены ошибки по двум организациям за 4 года — вся история начислений, удержаний, кадровых изменений с 2022 по 2025 год.
Отчёты формируются корректно:
- Расчётные листки сходятся с данными из старой системы
- 6-НДФЛ формируется без ошибок и ручных корректировок
- Своды по начислениям и удержаниям — копейка в копейку
Устранены все технические проблемы:
- Исправлены «битые» ссылки в документах
- Ликвидировано удвоение сумм в отчётах по 72 сотрудникам
- Созданы недостающие документы выплаты за весь период
Разработаны инструменты, которые пригодятся и в будущих проектах:
- Обработка массового создания документов выплаты
- Обработки для исправления служебных данных
Выводы
Почему миграция — это не «просто перенести данные»
Предварительная подготовка миграции данных — залог успеха. Прежде чем начинать процесс переноса данных, нужно тщательно подготовить базы ЗУП и ERP.
Штатные инструменты переноса — только начало. Они перенесут 80% данных. Оставшиеся 20% потребуют ручной работы, разработки дополнительных инструментов и глубокого понимания того, как устроены обе системы.
ЗУП и ERP — не одно и то же. Даже если в ERP есть «подсистема ЗУП», внутри она работает иначе. Некоторые вещи, привычные в отдельном ЗУП, в ERP делаются по-другому. Это нужно учитывать при планировании.
Без хорошей диагностики — никуда. Большинство проблем не видны на поверхности. «Документ не проводится» — а причина в отсутствии настройки, которую никто не подумал проверить. «Отчёт врёт» — а дело в дублях служебных записей. Чтобы найти такие вещи, нужна экспертиза и инструменты анализа.
Как подготовиться к миграции данных
Чтобы избежать проблем, нужно выстроить процесс в несколько этапов — с проверками на каждом шаге.
- Аудит и чистка базы-источника. Прежде чем переносить данные, надо навести порядок в старой базе ЗУП.
- Проверка целостности данных.
- Сопоставление справочников.
- Пробная миграция в тестовую базу. Перед финальным переносом провести полную репетицию на копии рабочей базы ERP.
- Чистовая миграция данных. Финальная миграция проводится в нерабочее время. Перед началом сделать полный бэкап базы ERP. Написать план возврата бэкапа на непредвиденный случай.
Стоимость и сроки
Всю работу можно описать следующими действиями: диагностика ошибок; поиск причин и их устранение; поиск и удаление дублей объектов; разработка служебных инструментов и их применение; финальная проверка текущих ошибок и широкая диагностика возможных ошибок. Всё это стоило клиенту 640 000 рублей и заняло 2 месяца.
Сталкиваетесь с похожей ситуацией?
Планируете перенести данные из ЗУП в ERP — или уже начали и столкнулись с проблемами? Давайте обсудим ваш случай. Разберёмся, какие подводные камни могут быть именно в вашей ситуации, и предложим план действий.⬇️
