Ошибка «Преобразование к типу Дата не может быть выполнено» в 1С: причины и исправление

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

Ошибка может проявляться в разных местах: при загрузке данных из Excel или CSV, при обмене между базами, при обработке введённой пользователем строки, при выполнении запросов и при работе типовых обработок переноса данных. В некоторых случаях сообщение появляется и у обычных пользователей — например, при заполнении документа, если в поле даты введён текст в неподдерживаемом формате.

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

Почему возникает ошибка преобразования даты в 1С

Платформа 1С умеет неявно и явно преобразовывать значения к типу «Дата», но делает это по строгим правилам. Функция Дата("20230115") или Дата("15.01.2023") сработает корректно, а вот Дата("15/01/2023") или Дата("2023-13-45") — вызовет исключение. Платформа ожидает либо строку в формате ГГГГММДД (возможно с временем: ГГГГММДДччммсс), либо строку в региональном формате, заданном в настройках информационной базы, либо числовые аргументы: год, месяц, день.

Типичные источники проблемы:

• строка приходит из внешнего файла (Excel, CSV, XML) в формате, отличном от ожидаемого — например, американский ММ/ДД/ГГГГ вместо ДД.ММ.ГГГГ;
• значение пустое или содержит только пробелы, а код не выполняет проверку перед преобразованием;
• в строке присутствуют неразрывные пробелы, табуляции или невидимые символы, скопированные из сторонних программ;
• при обмене между базами с разными региональными настройками дата сериализуется по-разному;
• в запросе используется конструкция ВЫРАЗИТЬ(... КАК Дата) над полем, содержащим строки произвольного вида.

Как найти проблемное значение

Первый шаг — понять, какое именно значение не преобразуется. Если ошибка возникает в собственном коде, откройте конфигуратор, поставьте точку останова перед строкой с преобразованием и посмотрите содержимое переменной через табло (Shift+F9). Часто оказывается, что в переменной не «15.01.2023», а « 15.01.2023 » с пробелами, пустая строка или вообще «Н/Д» из выгрузки контрагента.

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

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

Попытка
НоваяДата = Дата(СтрокаДаты);
Исключение
Сообщить("Не удалось преобразовать: [" + СтрокаДаты + "]");
НоваяДата = Дата(1, 1, 1);
КонецПопытки;

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

1. 1
   Воспроизведите ошибку и зафиксируйте точный текст сообщения и место возникновения
2. 2
   Определите источник данных: ручной ввод, файл, обмен, запрос
3. 3
   Извлеките фактическое значение, которое не преобразуется (отладчик, сообщение, журнал)
4. 4
   Сравните значение с ожидаемым форматом: ГГГГММДД или региональный ДД.ММ.ГГГГ
5. 5
   Исправьте источник данных или добавьте нормализацию строки перед преобразованием
6. 6
   Повторите операцию и убедитесь, что ошибка устранена на всех записях

Исправление в коде: функция Дата() и её правильное использование

Самый надёжный способ избежать ошибки — не преобразовывать строку, а конструировать дату из числовых компонентов. Функция Дата(Год, Месяц, День) принимает числа и никогда не зависит от региональных настроек. Если исходные данные — строка вида «15.01.2023», разберите её на части и соберите дату явно:

Части = СтрРазделить(СтрокаДаты, ".");
Если Части.Количество() = 3 Тогда
НоваяДата = Дата(Число(Части[2]), Число(Части[1]), Число(Части[0]));
КонецЕсли;

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

Если строка гарантированно в формате ГГГГММДД, допустимо прямое преобразование Дата("20230115"). Этот формат платформа понимает всегда, независимо от региональных настроек, поэтому именно он рекомендуется при сериализации дат для обмена между системами. Для даты со временем используйте формат ГГГГММДДччммсс.

Перед любым преобразованием добавляйте проверки: на пустую строку, на длину значения, на допустимые диапазоны чисел (месяц от 1 до 12, день от 1 до 31). Это дешевле, чем перехватывать исключения, и делает поведение кода предсказуемым.

Функция СтрокаВДату(Стр) Экспорт
	Стр = СокрЛП(Стр);
	Если ПустаяСтрока(Стр) Тогда
		Возврат Дата(1,1,1);
	КонецЕсли;
	Части = СтрРазделить(Стр, ".");
	Если Части.Количество() = 3 Тогда
		Возврат Дата(Число(Части[2]), Число(Части[1]), Число(Части[0]));
	КонецЕсли;
	Возврат Дата(Стр); // формат ГГГГММДД
КонецФункции

Исправление при загрузке данных из файлов

При загрузке из Excel или CSV самая частая ситуация — Excel уже интерпретировал значение как дату и показывает её в формате, отличном от того, что ожидает обработка. При чтении через COM-объект или табличный документ вы можете получить как строку, так и готовое значение типа «Дата». Поэтому перед преобразованием проверяйте тип полученного значения: если это уже дата, никакого преобразования не нужно вообще.

Если даты в файле в формате ММ/ДД/ГГГГ (типично для выгрузок из зарубежных систем), прямое преобразование не сработает или, что хуже, молча перепутает день и месяц для дат вроде 03/04/2023. Решение — явный разбор строки с указанием, какая часть есть что. Не полагайтесь на «автоопределение»: оно непредсказуемо для дат, где оба числа не превышают 12.

Практические меры при загрузке:

• сохраняйте исходный файл в CSV с явным форматом дат ГГГГ-ММ-ДД или ДД.ММ.ГГГГ перед загрузкой;
• в собственной обработке загрузки нормализуйте строку: уберите пробелы через СокрЛП(), замените неразрывные пробелы через СтрЗаменить();
• при массовой загрузке собирайте ошибки в таблицу и показывайте пользователю списком, а не останавливайтесь на первой записи;
• после загрузки проверьте несколько документов вручную: даты должны попасть в ожидаемый период.

Ошибка в запросах и при работе с ВЫРАЗИТЬ

В языке запросов 1С оператор ВЫРАЗИТЬ(Поле КАК Дата) вызывает ту же ошибку, если поле содержит строку, которую нельзя привести к дате. Это типично для регистров сведений и документов, где дата хранится в строковом реквизите — например, при интеграции с внешними системами.

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

• очистить данные заранее — обработкой найти записи с некорректными строками и исправить или очистить их;
• не использовать ВЫРАЗИТЬ, а выбирать строковое поле как есть и преобразовывать значения уже в коде, где доступны проверки и попытка;
• если строковое представление имеет фиксированный формат, собрать дату через ПОДСТРОКА и функции языка запросов — но такой запрос быстро становится громоздким.

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

Региональные настройки и обмен между базами

Формат даты, который платформа ожидает при преобразовании строки вида «15.01.2023», зависит от региональных настроек информационной базы или сеанса. Если база настроена на формат ДД.ММ.ГГГГ, строка «01/15/2023» вызовет ошибку; при обратной настройке — наоборот. При обмене между базами с разными настройками это становится источником регулярных сбоев.

Чтобы обмен не зависел от региональных настроек, передавайте даты в независимом формате: ГГГГММДДччммсс или ISO 8601 (ГГГГ-ММ-ДД) с явным разбором на приёмной стороне. В XML-сериализации платформа сама использует формат ISO, поэтому типовые механизмы обмена (XDTO, универсальный формат) от этой проблемы, как правило, защищены. Уязвимы именно самописные обмены через текстовые файлы и строковые представления.

Проверить текущие настройки можно в конфигураторе: Администрирование → Региональные установки информационной базы. Если меняете эти настройки в работающей системе, учтите, что это влияет на отображение и разбор дат во всех сеансах.

Проверка результата и профилактика

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

Для профилактики вынесите преобразование строк в даты в отдельную функцию общего модуля с проверками и используйте её везде вместо прямых вызовов Дата(Строка). Это централизует логику разбора форматов и упрощает исправления, если появится новый источник данных с другим форматом.

Частые вопросы