Переход со старых платформ на современные решения — это всегда ответственный и технологически сложный процесс. При переносе кадровых и расчетных данных из конфигурации «Зарплата и Кадры 7.7» (ЗиК) в «Зарплата и управление персоналом 3.1» (ЗУП) специалисты нередко сталкиваются со сбоями в правилах конвертации данных. Одним из наиболее неприятных моментов является критическая ошибка загрузки, полностью останавливающая весь процесс переноса.
В этой статье мы подробно проанализируем ошибку с текстом «Дата окончания не может быть меньше даты начала», возникающую при обработке документов по уходу за ребенком, выясним глубинную причину сбоя в программном коде правил обмена и рассмотрим несколько практических способов её устранения.
Сбой происходит на этапе загрузки подготовленного XML-файла данных в приемник (ЗУП 3.1). Процесс обрывается, выдавая в журнал регистрации или в окно выполнения обмена следующее сообщение:
Ошибка в обработчике события ПриЗагрузкеОбъекта
ИмяПКО = ОтпускПоУходуЗаРебенком
ТипОбъекта = Отпуск по уходу за ребенком
Объект = Отпуск по уходу за ребенком 0000-000002 от 26.10.2015
Обработчик = ПриЗагрузкеОбъекта
ОписаниеОшибки = Дата окончания не может быть меньше даты начала.
ПозицияМодуля = ОбщийМодуль.ЗарплатаКадрыОбщиеНаборыДанных.Модуль(51)
КодСообщения = 20
Давайте проанализируем ситуацию. Если мы запустим сеанс отладки в конфигураторе ЗУП 3.1, то увидим, что исключение вызывается в процедуре СоздатьВТПериоды, которая расположена в общем модуле ЗарплатаКадрыОбщиеНаборыДанных. Программа выполняет стандартную валидацию переданных ей дат:
Процедура СоздатьВТПериоды(МенеджерВременныхТаблиц, НачалоИнтервала, ОкончаниеИнтервала, Периодичность = "МЕСЯЦ", ИмяПоляПериод = "Период", ИмяВТ = "ВТПериоды", ИспользоватьКонецПериода = Ложь) Экспорт
Если НачалоИнтервала > ОкончаниеИнтервала Тогда
ВызватьИсключение НСтр("ru='Дата окончания не может быть меньше даты начала.'")
КонецЕсли;
...
КонецПроцедуры
При детальном рассмотрении значений параметров в точке останова выясняется парадоксальная картина. В процедуру передаются следующие значения границ интервала:
НачалоИнтервала = '01.01.2014'ОкончаниеИнтервала = '31.12.2013'Очевидно, что дата начала (2014 год) хронологически позже даты окончания (2013 год). Из-за этого срабатывает проверка, и весь процесс загрузки данных аварийно завершается. Выясним, откуда берутся эти некорректные даты, если в исходном документе в ЗиК 7.7 все периоды заполнены абсолютно правильно (например, отпуск с 26.10.2015 по 07.08.2018).
Ошибка кроется непосредственно в правилах обмена данными, которые поставляются вместе с конфигурацией ЗУП 3.1. Эти правила встроены в систему в виде общего макета с идентификатором ЗарплатаКадрыПереносДанныхИзЗиК23.
Для корректного расчета пособия по уходу за ребенком в новой базе программе ЗУП необходимы сведения о заработке сотрудника за два предшествующих календарных года. За расчет этих периодов отвечает специальный алгоритм правил конвертации. Проанализируем участок кода, выполняющий подготовку дат:
Если Док.РасчетПоПравилам2010Года = 1 Тогда
Иначе
ГодСобытия = ДатаГод(Док.Начало);
Год1 = ГодСобытия-1; // Внимание! Здесь допущена логическая ошибка
Год2 = ГодСобытия-2; // И здесь тоже!
ДокументыОтпуск.ПериодРасчетаСреднегоЗаработкаПервыйГод = Год1;
ДокументыОтпуск.ПериодРасчетаСреднегоЗаработкаВторойГод = Год2;
ДокументыОтпуск.ПериодРасчетаСреднегоЗаработкаНачало = Дата(Год1,1,1);
ДокументыОтпуск.ПериодРасчетаСреднегоЗаработкаОкончание = Дата(Год2,12,31);
КонецЕсли;
Давайте разберем эту логику на конкретном примере. Предположим, наше событие (начало отпуска по уходу за ребенком) произошло в 2015 году (ГодСобытия = 2015). По закону для расчета среднего заработка должны браться два предшествующих года: 2013-й и 2014-й. То есть первый расчетный год должен быть 2013-м (ГодСобытия - 2), а второй — 2014-м (ГодСобытия - 1).
Однако из-за опечатки разработчиков переменной Год1 присваивается значение ГодСобытия - 1 (что дает 2014 год), а переменной Год2 — значение ГодСобытия - 2 (что дает 2013 год). В результате программа формирует следующие реквизиты:
ПериодРасчетаСреднегоЗаработкаНачало = '01.01.2014'ПериодРасчетаСреднегоЗаработкаОкончание = '31.12.2013'Мы видим классическую инверсию временного интервала, которая и приводит к падению платформы при попытке провалидировать даты. Ниже мы детально рассмотрим варианты исправления этой досадной ошибки.
Если вам необходимо осуществить перенос данных прямо сейчас и нет возможности оперативно обновить конфигурацию ЗУП 3.1, лучшим решением будет точечное исправление правил обмена вручную. Для этого выполним несколько шагов.
ЗарплатаКадрыПереносДанныхИзЗиК23. Щелкните по нему правой кнопкой мыши и выберите пункт «Сохранить как...», указав на диске тип файла «Двоичные данные» (файл сохранится в формате архива .zip).Док.РасчетПоПравилам2010Года, чтобы быстро сориентироваться в кодовой структуре.
// Корректный вариант расчета годов для среднего заработка:
Год1 = ГодСобытия-2; // Первый год интервала (более ранний)
Год2 = ГодСобытия-1; // Второй год интервала (более поздний)
Сохраните изменения в файле XML. Теперь у вас есть два пути применения исправленных правил:
V77Exp.ert на стороне «1С:Предприятия 7.7» укажите этот отредактированный XML-файл в поле «Имя файла правил» вместо стандартного. Таким образом, выгрузка сразу произойдет по корректному алгоритму.Поскольку данная ошибка является явным вендорским багом, фирма «1С» оперативно устранила её в последующих релизах конфигурации «Зарплата и управление персоналом 3.1».
Если для вашей компании регулярные обновления не вызывают технических трудностей, настоятельно рекомендуем обновить базу ЗУП 3.1 до самого свежего релиза перед началом процедуры переноса. Вместе с обновлением конфигурации автоматически обновятся и встроенные макеты правил обмена, что полностью нивелирует проблему с переносом документов ОтпускПоУходуЗаРебенком без ручного вмешательства в код.
Также перед выполнением переноса обязательно скачайте актуальные версии внешних обработок выгрузки с официального портала поддержки пользователей «1С». Часто обновленные правила поставляются в составе дистрибутива обновления ЗУП в каталоге шаблонов.
При переносе данных из устаревших версий (таких как ЗиК 7.7) разработчики методологии «1С» часто сталкиваются со скрытыми ошибками ведения учета в старой базе. Попытка перенести всю многолетнюю историю документов «один в один» (так называемый «технический перенос») практически всегда сопряжена с огромным количеством коллизий.
Рассмотрим альтернативный, более надежный вариант — рекомендованный (краткий) перенос данных. Проанализируем преимущества этого подхода:
Если вы выберете рекомендованный перенос, старые документы отпусков по уходу за ребенком физически не будут выгружаться в ЗУП 3.1 в виде документов проведения, а значит, ошибка с интервалами дат попросту не возникнет.
Если вам все же необходимо выполнить полный перенос документов с историей, можно произвести предварительную подготовку данных на стороне источника («1С:ЗиК 7.7»). Рассмотрим, как минимизировать вероятность сбоев:
Резюмируя, отметим, что наиболее технологичным и правильным решением является ручная корректировка формул расчета годов в XML-файле правил обмена (если требуется срочный перенос «здесь и сейчас») либо плановое обновление конфигурации-приемника до актуальной версии.