← На главную

При переходе конфигурации 1С:Управление нашей фирмой с ветки 1.5 на 1.6 (в частности, на релиз 1.6.7 и выше) разработчики и администраторы часто сталкиваются с ошибкой выполнения метода записи документа:

{Документ.ЗаказПокупателя.Форма.ФормаДокумента.Форма(1508)}: Ошибка при вызове метода контекста (Записать) Записать(ПараметрыЗаписи); по причине: Не удалось провести: "Заказ покупателя"!

При этом программа не выводит явного диагностического сообщения, из-за чего проведение прерывается. Разберем по шагам причины такого поведения платформы и практические способы устранения неполадки.

Причина 1. Нарушение цепочки последовательного обновления

Основная причина скрытых ошибок при переходе между мажорными редакциями — попытка «перепрыгнуть» промежуточные релизы (например, прямое обновление с 1.5.4 на 1.6.7). В платформе 1С:Предприятие структура метаданных и логика обработки данных изменяются постепенно:

1. В промежуточных релизах устаревшие реквизиты помечаются к удалению, а новые структуры инициализируются специальными алгоритмами.
2. При «прыжке» через релизы пропускаются процедуры реструктуризации и заполнения новых таблиц, из-за чего типовые механизмы проведения обращаются к пустым или некорректным данным.
3. Начиная с редакции 1.6.7, архитектура работы с заказами претерпела кардинальное изменение: был упразднен механизм разделения на статусы и состояния, а система переведена на единый справочник состояний заказов. Если данные не были сконвертированы промежуточными обработчиками, проверка при проведении аварийно взводит флаг Отказ = Истина.

Решение:

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

1. 1.5.4.56
2. 1.6.4.28
3. 1.6.5.28
4. 1.6.6.54
5. 1.6.7.63 (или актуальный финальный релиз)

После установки каждого промежуточного обновления обязательно запускаем базу в режиме «1С:Предприятие» под учетной записью с полными правами и дожидаемся полного завершения всех процедур обновления и отложенных обработчиков данных (раздел «Администрирование» — «Обслуживание» — «Результаты обновления программы»).

Причина 2. Конфликты в устаревших планах обмена

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

Решение:

1. Откроем список настроенных синхронизаций данных в разделе «Администрирование» — «Синхронизация данных».
2. Удалим старые некорректные настройки синхронизации и узлы соответствующих планов обмена.
3. Создадим и настроим подключение обмена данными заново по актуальным правилам новой редакции.

Причина 3. Ошибки в доработанном коде и скрытые исключения

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

1. В конфигураторе откроем меню «Отладка» — «Остановка по ошибке».
2. Установим флаг «Останавливаться по ошибке», а также включим признак «Останавливаться по предупреждению/обрабатываемому исключению». Это позволит остановить выполнение кода внутри конструкций Попытка ... Исключение, где ошибка могла быть перехвачена без вывода пользователю.
3. Запустим сеанс в режиме отладки и повторим проведение документа ЗаказПокупателя.
4. Проверим стек вызовов в модуле проведения или в процедурах подписок на события (ПередЗаписью, ОбработкаПроверкиЗаполнения, ОбработкаПроведения) на предмет обращения к несуществующим реквизитам.
5. Откроем «Журнал регистрации» и установим отбор по событиям с уровнем «Ошибка» и «Предупреждение» на момент проведения документа.

Причина 4. Некорректный кэш метаданных и повреждение ссылочной целостности

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

Решение:

1. Очистим пользовательский кэш на рабочем месте: удалим содержимое каталогов %LOCALAPPDATA%\1C\1Cv8 и %APPDATA%\1C\1Cv8. При клиент-серверном варианте также очистим серверный кэш сеансов.
2. В режиме Конфигуратора откроем меню «Администрирование» — «Тестирование и исправление...».
3. Отметим флаги «Проверка логической целостности», «Проверка ссылочной целостности» и «Реструктуризация таблиц информационной базы», после чего выполним проверку.
4. Проверим назначенные роли и права текущего пользователя: в новой версии могли появиться новые регистры и объекты, на которые требуются явные права для проведения торговых документов.