При интеграции 1С с внешними веб-сервисами, написанными на Java (например, портал государственных закупок РК или ИС ЭСФ), разработчики часто сталкиваются с ошибкой Unmarshalling Error: java.text.ParseException. Эта ошибка означает, что принимающая сторона не может распознать строку даты, которую вы передаете в XML-пакете. Даже если в документации указан стандартный тип string или dateTime, внутренняя реализация на стороне сервера может требовать строго определенную маску.
В этой статье мы проанализируем, почему стандартные форматы даты 1С могут не подходить, и разберем пошагово, как найти и реализовать правильный формат для успешной передачи данных.
Большинство Java-сервисов используют класс SimpleDateFormat для обработки дат. Этот класс крайне чувствителен к каждому символу в строке. Разберем основные нюансы, которые могут привести к ошибке:
Z в маске формата Java ожидает часовой пояс без двоеточия (например, +0500), в то время как символ X или стандарты ISO часто требуют двоеточие (+05:00). Если сервер настроен на Z, а 1С отправляет +05:00, произойдет ошибка парсинга..000).T между датой и временем. Однако некоторые обработчики требуют её экранирования или, наоборот, не воспринимают её, если она не предусмотрена конкретной маской yyyy-MM-dd'T'HH:mm:ss.Если документация сервиса (например, для метода queryAwp) не дает точного ответа, рассмотрим наиболее вероятные варианты, которые стоит попробовать по очереди:
2024-05-30T09:30:10.000+05:00 — Полный формат ISO 8601 с миллисекундами и двоеточием.2024-05-30T09:30:10.000+0500 — Формат с миллисекундами, но без двоеточия в часовом поясе.2024-05-30T09:30:10Z — Формат UTC (нулевой часовой пояс).30.05.2024 — Локальный формат (иногда встречается в системах Казнета, вопреки спецификациям XML).Проанализируем самый надежный способ узнать нужный формат. Как правило, API содержит методы не только для отправки (query...), но и для получения данных (например, queryViewAwp). Выясним формат даты следующим образом:
Важный вывод: В 99% случаев формат, в котором сервис отдает данные, является единственно верным форматом, который он готов принять на вход.
Стандартный механизм 1С при использовании ЗаписьXML.ЗаписатьДату() может автоматически подставлять формат, который не подходит серверу. Если нам нужно передать специфическую строку, проанализируем, как это сделать правильно. Мы должны передавать дату как строку, чтобы полностью контролировать её вид.
Рассмотрим пример формирования даты в формате с миллисекундами и часовым поясом без двоеточия:
Функция СформироватьДатуДляСервиса(Знач ИсходнаяДата) Экспорт
// Предположим, нам нужен формат yyyy-MM-dd'T'HH:mm:ss.SSS+0500
СтрокаДаты = Формат(ИсходнаяДата, "ДФ=yyyy-MM-dd") + "T" + Формат(ИсходнаяДата, "ДФ=HH:mm:ss") + ".000+0500";
Возврат СтрокаДаты;
КонецФункции
При записи в XML используем следующий подход:
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.УстановитьСтроку();
ЗаписьXML.ЗаписатьНачалоЭлемента("dateFrom");
// Записываем дату как текст, а не как тип Дата
ЗаписьXML.ЗаписатьТекст(СформироватьДатуДляСервиса(ТекущаяДата()));
ЗаписьXML.ЗаписатьКонецЭлемента();
Проанализируем ситуацию с часовыми поясами, особенно для систем Республики Казахстан. С 1 марта 2024 года в РК введен единый часовой пояс UTC+5. Если вы используете в запросе старое смещение +06:00, сервер, уже переведенный на новую логику, может отклонить запрос с ошибкой ParseException, так как время и пояс не будут соответствовать внутренним правилам валидации календаря.
Совет: Всегда проверяйте актуальное смещение времени на сервере и используйте его в строке формирования даты.
Если вы получаете ошибку парсинга даты в Java-системе, выполните следующие действия:
.000).+05:00 на +0500).View) и скопируйте формат оттуда "один в один".Формат() и записывайте её в XML через ЗаписатьТекст(), чтобы избежать автоматических преобразований платформы 1С.