Ошибки при переносе данных 1С

Начнем с определения

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

Назовем, что именно может передаваться:

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

Примите как неизбежность тот факт, что не всегда база данных - Источник совпадает с БД Приёмник идеально. Хотя каждый должен стремиться к идеалу, чтобы избежать проблем.

Типизируем ошибки при переносе данных

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

Постараемся классифицировать основные ошибки:

1. Применение неправильного формата к записям даты, числам, строкам, включая «запихивание» текста в поле расположения чисел, отнесем к синтаксическому типу.
2. Когда пользователь включил данные в реквизиты неправильно или нарушил связи между справочниками и документами, речь идет о логическом типе. Простой перенос путем клика по кнопке, без учета особенностей версии, конфигурации, приведет к ошибкам. Структура и связи в регистрах кастомной и типовой конфигурации отличаются. К примеру, в одной программе поле «Телефон» — это строка, а в другой – ссылка на справочник «Контакты». Для корректного переноса нужна обработка.
3. Использование неправильной обработки ключей, идентификаторов приводит к дублированию данных.
4. Некорректный маппинг полей, отсутствие правил обработки каких-либо элементов, сбои во время сеанса миграции — прямой путь к частичной потере информации.
5. Человеческий фактор всплывает, когда существует необходимость введения данных вручную. Тогда возникают дубли ключей, записей в новой базе. К примеру, если у двух контрагентов одинаковые ИНН, при ручном вводе у них могут быть расхождения в данных, незаметные с первого взгляда. В базе-Приёмнике после переноса появится дубль.

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

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

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

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

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

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

Важность выбора сценария переноса

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

• Во-первых, распространён переход на новую версию системы «1С» посредством обновлений. Это удобно для конфигураций, не имеющих больших отличий. В пример обычно приводится конфигурация БП 2.0 и более новая БП 3.0. Для осуществления миграции потребуется минимум доработок. Хотя этот пример по совместимости является, скорее, исключением из общего правила. К сожалению, даже он не всегда реально удачен, и процесс стопроцентно проходит без «сучка и задоринки», не потребовав разработки правил конвертации. Такой номер, однозначно, не проходит при наличии значительных изменений в конфигурации. Иначе неизбежны ошибки при кастомизации.
• Во-вторых, чтобы начать работу в новой базе с 1 января, используют вариант «переход остатками в начале года». Эта классика избавляет от двойного ввода документов. Но вносить изменения в документы истёкшего года надо вручную, исправлять остатки.
• В-третьих, применяется переход после закрытия года. Для реализации такого сценария настраиваются, тестируются правила переноса всех документов за прошедший год. Это, естественно, более ёмкие временные затраты на подготовку процедуры миграции данных в новую базу.

Резюмируем и назовём основные ошибки

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

Стараемся избежать потери данных при переносе

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

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

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

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

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

Скрипты для подсчёта количества элементов справочников до и после сеанса переноса помогут сверить перенесённые данные.

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

Следите за соответствием структуры данных в конфигурациях

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

Стремимся автоматизировать процессы

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

Как действовать при несовместимости версий 1С

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

Различия в форматах данных между, к примеру, ИТ-решениями 1С:7.7 и 1С:8.3, требуют уверенного владения встроенными в обозначенные продукты инструментами конвертации данных. Равно, как и подготовки обработки для обмена между кастомной и типовой конфигурациями.

Несовпадения в структуре данных

Ещё одним камнем преткновения на пути корректного переноса может быть неприятное обстоятельство. А именно, — использование базой-Приемником другой логики хранения данных. При этом в целевой базе некоторых справочников и документов просто не будет.

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

Как избежать повреждения данных

Целостность базы следует диагностировать регулярно с помощью встроенных инструментов 1С. Не пренебрегать тестированием на копии базы.

Нагрузка на сервер

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

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

Поиск ошибок при переносе данных в 1С

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

Как поступить в случае несовпадения версий? Во-первых, обновить старую базу до релиза, соответствующего базе-приёмнику. Когда это не получается выполнить, надо применять правила, которые совместимы с действующей версией.

Как правильно понять сообщение об ошибке

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

Вначале указывается, где произошла ошибка. Например, в модуле формы обработки с определённым именем; в обработчике события и т. д. В скобках может стоять номер строки (20) и номер колонки (21), где именно затаилась ошибка.

Мы увидим и описание причины возникновения ошибки. К примеру:

• «Поле объекта не обнаружено (Артикул)»;
• «Переменная не определена (Адресс)».

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

Метод исключений наиболее эффективен для самостоятельного нахождения ошибки

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

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

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

Когда и какие инструменты для переноса данных используются

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

Обмен XML-файлов, являющихся носителями данных. Создается обработка, с помощью которой переносят справочники, документы, регистры.

Когда необходимо один раз перенести данные или проанализировать их вне платформы 1С, подойдут внешние файлы и обработки (Excel, CSV).

Загружать/выгружать данные из одной базы в другую можно с помощью Web-Servis (WS). Это удобно для настройки автоматического режима обмена по расписанию.

Сложные и кастомизированные переносы требуют создания Запросов, Обработчиков событий, Планов обмена.

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

Успешный алгоритм переноса данных

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

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

На следующем этапе очищается база – Источник от лишнего «мусора», создается архив, исправляются ошибки.

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

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

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

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

Следующий этап назовём «движение от одной части к целому». А именно, к полному переносу на тестовую базу и сравнению всех данных в базе-Источнике и базе-Приёмнике. После нахождения и исправления ошибок рекомендуется повторить тестирование.

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

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

Что именно надо проверять по окончании переноса

По окончании сеанса миграции понадобится комплексная проверка соответствия всех данных и корректной работы системы.

Первоочередная проверка перенесённых данных проводится в справочниках:

• Организации;
• Подразделения, Должности;
• Графики работы;
• Виды отпусков;
• Виды стажа.

Проверка переноса сведений по сотрудникам проходит с помощью сравнения личных данных. Например, в 1С:ЗУП 3 открывают Кадры - Кадровые отчеты - Личные данные сотрудников. Сравнивают Ф.И.О., ИНН, СНИЛС, Дата рождения, Адрес места проживания, Страна гражданства.

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

Проверка переноса штатного расписания, кадровых данных. Необходимо учитывать, что при полном или рекомендованном переносе штатного расписания его невозможно загрузить в 1С:ЗУП 3. Придётся заполнять, основываясь на данных о штатной расстановке в старой конфигурации на момент переноса. Какую-то информацию надо дополнить (к примеру, вакансии). Проверять, открыв отчет Штатное расписание (Т-3).

Проверка переноса остатков отпусков в одноимённом отчете Остатки отпусков (кратко) или Остатки отпусков в исторических системах.

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

Внимательно относитесь к проверке займов сотрудникам. При «рекомендованном» переносе данные по ним не переносятся, а заполняются вручную в документе Договор займа сотруднику в программе 1С:ЗУП 3. При включении «полного» переноса данные по займам мигрируют с последующим редактированием.

Проверять после сеанса обмена надо максимальный объём информации, включая также:

• расчет НДФЛ;
• расчет страховых взносов;
• перенос остатков по расчетам с сотрудниками;
• расчет среднего заработка.

Чем объёмнее база, тем больше времени уходит на комплексную проверку результатов переноса.

Опытный подрядчик не боится ответственности за результат

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

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

• размер базы;
• сколько лет вёлся учёт;
• какова производительность серверного оборудования;
• что дорабатывалось из функционала в конфигурации на протяжении эксплуатации;
• по какому графику работает организация.

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

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