При кастомизации конфигурации 1С:Управление торговлей 11 часто возникает необходимость увеличить точность реквизита Количество. Это актуально для отраслей, работающих с весовым товаром, жидкостями или специфическими строительными материалами (например, м3 пеноплекса), где три знака после запятой не позволяют корректно отразить первичную документацию от поставщика. Однако после такого изменения типовая синхронизация с 1С:Бухгалтерией 3.0 перестает работать, выдавая ошибку формирования объекта XDTO.
В данной статье мы разберем, почему возникает эта проблема, проанализируем технические ограничения формата EnterpriseData и рассмотрим несколько вариантов решения: от быстрого "костыля" в коде до методически правильной настройки системы.
Рассмотрим механику обмена. Современная синхронизация между УТ 11 и БП 3 строится на технологии КД 3.0 и формате EnterpriseData. Этот формат описывается набором XSD-схем, которые жестко определяют типы данных для каждого передаваемого поля.
Проанализируем ситуацию: в типовой поставке 1С для типа Количество в XDTO-пакете EnterpriseData установлено ограничение decimal(15, 3). Это означает, что на уровне транспортного сообщения XML система не может принять число, в котором более трех знаков после запятой. Когда вы меняете тип данных в метаданных документа (например, РеализацияТоваровУслуг) на Число(15, 4), программный код обмена пытается передать в фабрику XDTO значение с четырьмя знаками. Фабрика, сверяясь со схемой, выдает ошибку: "Тип свойства <Количество> не соответствует значению".
Если проблему нужно решить "здесь и сейчас", чтобы документы начали уходить в бухгалтерию, можно воспользоваться методом принудительного округления данных непосредственно в момент формирования XDTO-пакета. Этот способ применил автор темы на форуме.
Для реализации этого метода необходимо внести изменения в расширение, перехватив работу общего модуля. Выясним, где именно происходит сбой. Ошибка обычно возникает в общем модуле ОбменДаннымиXDTOСервер. Нам нужно найти место, где вызывается метод ФабрикаXDTO.Создать.
Разберем пример кода, который позволит обойти проверку типа:
// В расширении для общего модуля ОбменДаннымиXDTOСервер
&Вместо("ЗначениеXDTOИзДанныхXDTO")
Функция ИмяРасширения_ЗначениеXDTOИзДанныхXDTO(КомпонентыОбмена, ЗначениеСвойства, СвойствоТипЗначения)
Попытка
// Пытаемся создать значение XDTO стандартным способом
Возврат ФабрикаXDTO.Создать(СвойствоТипЗначения, ЗначениеСвойства);
Исключение
// Если возникла ошибка (например, из-за точности), округляем до 3 знаков
Если ТипЗнч(ЗначениеСвойства) = Тип("Число") Тогда
Возврат ФабрикаXDTO.Создать(СвойствоТипЗначения, Окр(ЗначениеСвойства, 3));
Иначе
ВызватьИсключение; // Если ошибка в чем-то другом, пробрасываем её дальше
КонецЕсли;
КонецПопытки;
КонецФункции
Важно: Этот метод является рискованным. Округляя количество "на лету" при выгрузке, вы создаете ситуацию, при которой в УТ 11 числится 1.0004 единицы товара, а в БП 3 придет ровно 1.000. Со временем это приведет к расхождению остатков на складах и проблемам с расчетом себестоимости в бухгалтерской базе.
Вместо того чтобы ломать типовую структуру метаданных, проанализируем штатные возможности 1С. В УТ 11 реализован мощный механизм Упаковок (Единиц измерения). Если поставщик отгружает товар в м3 с 4 знаками, мы можем создать для этого товара единицу измерения, которая будет кратна базовой.
Рассмотрим по шагам, как это настроить:
При использовании упаковок в документах вы сможете вводить количество, которое при пересчете в базовую единицу даст нужную точность, при этом сам обмен данными будет использовать стандартные поля и коэффициенты, которые корректно обрабатываются типовой синхронизацией без ошибок XDTO.
Если бизнес-процесс требует именно 4 знака в обеих базах (и в УТ, и в БП), и использование упаковок невозможно, необходимо модифицировать саму схему обмена. Это требует глубоких знаний работы с XDTO-пакетами.
Процесс выглядит следующим образом:
XDTO-пакета EnterpriseData (например, 1.15).ТипКоличество (или аналогичный, используемый в табличных частях) и меняем его фасет fractionDigits с 3 на 4.Количество во всех документах и регистрах, иначе данные будут обрезаться при записи в базу.Этот путь наиболее трудоемок при обновлениях конфигурации, так как 1С часто выпускает новые версии формата EnterpriseData, и вам придется поддерживать изменения в каждой новой версии пакета.
Проанализируем ситуацию с точки зрения бухгалтера. В бухгалтерском учете действует жесткое правило: Цена * Количество = Сумма. Если при синхронизации мы округляем количество, но передаем исходную сумму документа из УТ, в БП 3 может возникнуть ошибка при проведении документа или "краснота" на счетах учета НДС.
Посмотрим на пример:
На больших объемах такие расхождения могут составить значительные суммы, что приведет к проблемам при сверке с контрагентами и сдаче налоговой отчетности. Поэтому перед внедрением программных правок (Вариант 1) обязательно согласуйте этот момент с отделом бухгалтерии.
Мы выяснили, что ошибка обмена вызвана несоответствием ваших данных жесткой XSD-схеме формата EnterpriseData. Для решения проблемы мы рассмотрели три пути:
Рекомендуем начать с анализа возможности использования Упаковок, так как это единственный путь, сохраняющий целостность обеих систем без внесения критических изменений в логику синхронизации 1С.