Добрый день! Мы рассмотрим распространенную проблему, с которой сталкиваются пользователи 1С:Управление торговлей (УТ) версии 11.5. Речь идет об ошибке «Запись не верна! Период не может быть пустым!», которая возникает при попытке провести документ «Заказ клиента» и ссылается на регистр накопления «Плановые оплаты клиентов». Особенность этой ситуации заключается в том, что ошибка проявляется лишь для заказов одного конкретного клиента, в то время как по остальным клиентам все операции проходят без проблем. Мы вместе выясним причины этой ошибки и предложим пошаговые методы ее диагностики и устранения.
Общая причина ошибки и её контекст
Ошибка «Запись не верна! Период не может быть пустым!» является достаточно показательной. Она прямо указывает на то, что в какой-то момент формирования записи для регистра накопления Плановые оплаты клиентов, система не смогла получить значение для обязательного поля Период. Этот реквизит критически важен для всех регистров накопления, поскольку он определяет дату, на которую делается запись, и используется для формирования остатков и оборотов. Если система не может определить, к какой дате относится операция, она не может ее записать.
Тот факт, что проблема возникает только для одного клиента, является ключевой подсказкой. Это означает, что причина, скорее всего, кроется в особенностях данных именно этого клиента, его договоров, условий взаимодействия или в специфике самого документа «Заказ клиента», созданного для него. Это исключает глобальные системные ошибки или общие настройки конфигурации, но не исключает возможные последствия некорректных данных после обменов или доработок, влияющих на обработку информации для данного клиента.
Пошаговая диагностика с использованием отладчика
Наиболее точный и эффективный способ выявления причины этой ошибки — это использование отладчика. Отладчик позволяет нам пошагово отследить выполнение кода программы и увидеть значения всех переменных в момент возникновения ошибки. Мы проделаем следующие шаги:
Запустим 1С в режиме отладки: Для этого обычно требуется запустить клиентское приложение с ключом /Debug или воспользоваться соответствующей функцией в конфигураторе.
Установим точку останова: Нам нужно найти место в коде, где происходит запись в регистр Плановые оплаты клиентов. Откроем модуль проведения документа «Заказ клиента». Мы можем искать по ключевым словам, таким как Движения.ПлановыеОплатыКлиентов.Записать() или Движения.ПлановыеОплатыКлиентов.Добавить(). Установим точку останова непосредственно перед строкой, которая пытается записать данные в регистр.
Воспроизведем ошибку: Проведем проблемный «Заказ клиента». Выполнение программы остановится на нашей точке останова.
Проанализируем значения реквизитов: Находясь в отладчике, мы внимательно изучим значения всех переменных, которые используются для формирования записи регистра. Нас особенно интересуют переменные, из которых формируется поле Период регистра. Как правило, Период регистра накопления берется из даты документа или одной из его реквизитов, связанных с датой.
Изучим запросы: Если формирование движений регистра происходит через запросы, найдем эти запросы в коде. В отладчике мы можем выполнить запрос по частям или просмотреть его окончательный текст и результат. Это поможет нам понять, из каких полей документа или связанных с ним объектов (например, договоров, соглашений) берутся данные для Периода. Особое внимание уделим тем полям, которые могут быть незаполненными.
Пример гипотетического запроса, который может формировать данные для регистра:
ВЫБРАТЬ
ЗаказКлиента.Ссылка.Дата КАК Период,
ЗаказКлиента.Ссылка КАК ДокументОснование,
ЗаказКлиента.Клиент КАК Клиент,
// ... другие поля для регистра ...
ИЗ
Документ.ЗаказКлиента КАК ЗаказКлиента
ГДЕ
ЗаказКлиента.Ссылка = &СсылкаНаДокумент
Если в подобном запросе используются другие даты (например, из условий продаж), мы проверим и их.
Проверка ключевых полей в документе и связанных объектах
Поскольку отладка может быть сложной для неподготовленного пользователя, мы также можем начать с проверки наиболее вероятных мест, где может быть пропущена дата. Это особенно актуально, если ошибка специфична для одного клиента.
Проверим реквизит «Дата отгрузки» в документе «Заказ клиента»: По опыту, одним из наиболее частых виновников является незаполненное поле ДатаОтгрузки. Многие регистры взаиморасчетов и планирования оплат используют эту дату как базовую для определения периода.
Откройте проблемный «Заказ клиента», перейдите на вкладки, связанные с доставкой, оплатой или основными условиями, и убедитесь, что поле «Дата отгрузки» заполнено.
Проанализируем другие даты в документе: Помимо даты отгрузки, система может использовать другие даты, такие как:
Дата документа (Дата)
Планируемая дата оплаты
Дата поступления (если она влияет на планирование)
Дата утверждения (если в документе предусмотрен этап утверждения)
Внимательно просмотрите все вкладки и реквизиты документа «Заказ клиента» на предмет незаполненных дат.
Сравним карточку клиента и его договор с «рабочими» клиентами:
Поскольку проблема специфична для одного клиента, мы должны тщательно сравнить его данные с данными клиента, по которому заказы проводятся без ошибок. Обратите внимание на следующие моменты:
Карточка клиента: Убедитесь, что все основные реквизиты клиента заполнены, включая ИНН, КПП, основной договор и т.д. Хотя эти поля редко напрямую влияют на Период регистра, их отсутствие может указывать на общую «неполноценность» данных клиента.
Договор с клиентом: Откройте договор, который используется в проблемном «Заказе клиента». Сравните его с договором «рабочего» клиента. Особое внимание уделите следующим реквизитам:
ПорядокРасчетов (детализация расчетов): Этот реквизит определяет, как будут детализироваться взаиморасчеты (по договорам, по заказам, по документам расчетов). Если он установлен некорректно или его настройки предполагают использование дополнительных дат, которые не заполнены, это может быть причиной.
НаправлениеДеятельности: Если в вашей УТ используется учет по направлениям деятельности, убедитесь, что этот реквизит заполнен в договоре или в самом заказе. Иногда он может влиять на выбор условий оплаты и, как следствие, на формирование дат.
График оплаты: Проверьте, есть ли в договоре или соглашении с клиентом настроенный график оплаты. Если он есть, убедитесь, что все даты и условия в нем корректны.
Соглашения с клиентами: Если в системе используются типовые или индивидуальные соглашения, проверьте их. Условия продаж и оплаты, заданные в соглашении, могут влиять на заполнение дат в документе.
Возможные причины некорректного заполнения
Мы также должны рассмотреть, почему эти данные могли оказаться незаполненными:
«Кривые» данные после обменов: Очень часто подобные ошибки возникают после переноса данных из других систем или конфигураций, а также после некорректно настроенных обменов данными между базами (например, из БП в УТ, или между разными УТ). При обмене некоторые поля, которые являются обязательными в целевой системе, могли быть не переданы или переданы с пустыми значениями.
Миграция данных: При переходе на новую версию или редакцию конфигурации (например, с УТ 10.3 на УТ 11.5) могут возникнуть ситуации, когда данные были перенесены частично или с ошибками. Реквизиты, которые были необязательными в старой системе, могли стать обязательными в новой и остаться незаполненными для старых документов или клиентов. Для корректной смены версии без ошибок в реквизитах рекомендуется использовать перенос данных УТ 10.3 — УТ 11.
Модификации конфигурации: Если ваша конфигурация УТ 11.5 является доработанной, необходимо тщательно проверить внесенные изменения. Возможно, разработчики внесли правки в модуль проведения «Заказа клиента» или в алгоритмы заполнения регистров, которые нарушили логику формирования поля Период, особенно если эти доработки касались конкретных условий для определенных клиентов или видов договоров.
Отсутствие даты утверждения или других ключевых дат: Как мы упоминали ранее, «Период» может формироваться на основе различных дат. Например, в других конфигурациях похожие проблемы возникали из-за незаполненной «даты утверждения» для спецификаций номенклатуры. Это подчеркивает, что любой не заполненный дату-содержащий реквизит в документе «Заказ клиента» или в связанных с ним объектах может быть причиной.
Алгоритм действий при обнаружении проблемы
После того как мы выяснили потенциальные причины, давайте определимся с дальнейшими шагами:
Если проблема в незаполненном поле документа:
Если поле ДатаОтгрузки или другая критическая дата оказалась пустой, заполните ее вручную в проблемном «Заказе клиента». После этого попробуйте провести документ.
Если это помогло, выясните, почему это поле не заполнилось изначально. Возможно, это была разовая ошибка пользователя, или есть системная проблема, требующая настройки (например, автоматическое заполнение даты из соглашения).
Если проблема в данных клиента или договора:
Корректно заполните все необходимые реквизиты в карточке клиента, его договоре или соглашении, ориентируясь на примеры «рабочих» клиентов.
Возможно, потребуется создать новый договор или соглашение с корректными настройками и изменить его в проблемном заказе (или создать новый заказ на основе нового договора).
Если проблема после обменов или миграции:
Если ошибка связана с некорректным переносом данных, может потребоваться массовое исправление данных с помощью специальных обработок. Это задача для программиста 1С. В таких случаях для точечной миграции и сопоставления объектов удобно использовать перенос данных между похожими конфигурациями 1С.
Также стоит пересмотреть настройки обмена, чтобы исключить подобные ошибки в будущем.
Если есть модификации конфигурации:
Обратитесь к разработчикам, которые вносили изменения. Они должны проанализировать свои доработки и выявить, какая из них привела к ошибке. Возможно, потребуется откат или корректировка внесенных изменений.
Если отладка не дала однозначного ответа или вы не являетесь программистом:
Соберите максимально полную информацию: название документа, номер строки ошибки, текст ошибки, скриншоты проблемного документа и карточки клиента.
Обратитесь к квалифицированному специалисту 1С или в службу поддержки вашей компании. Предоставленная вами информация значительно ускорит решение проблемы.
Мы рассмотрели основные причины и методы устранения ошибки «Период не может быть пустым!» в 1С:УТ 11.5. Помните, что последовательная диагностика, начиная с самых очевидных мест (проверка полей документа) и заканчивая детальной отладкой, позволит вам эффективно найти и устранить корень проблемы.