При переходе на новые релизы конфигурации «1С:Бухгалтерия предприятия 3.0» (особенно часто это происходило при переходе с ветки 3.0.58 на 3.0.59 и последующие) технические специалисты часто сталкиваются с неприятным сбоем на этапе запуска базы данных в режиме «Предприятие». Программа аварийно завершает работу, выдавая длинное системное сообщение об ошибке проверки модели XDTO.
Давайте подробно проанализируем, почему возникает эта ошибка, как устроена технология XDTO в системе «1С:Предприятие 8.3» и рассмотрим несколько эффективных практических способов её устранения.
Для начала разберем суть самой ошибки. Полный текст системного сообщения обычно выглядит следующим образом:
Ошибка проверки модели XDTO: xdto-objectType-3.2.1 тип: PositionType пакет: Тип '{ свойства 'alcPercent' не определен
Ошибка проверки модели XDTO: xdto-objectType-3.2.1 тип: PositionType пакет: Тип '{ свойства 'alcPercentMin' не определен
Эта ошибка напрямую связана с механизмами интеграции 1С с государственной системой ЕГАИС (ФСРАР). В конфигурациях 1С для работы с ЕГАИС используются специальные объекты метаданных — XDTO-пакеты. Они представляют собой жестко описанные схемы XML-документов (XSD-схемы), по которым программа обменивается данными с транспортным модулем (УТМ).
В новых версиях формата обмена ЕГАИС (в частности, в v3) для товарных позиций в документах (тип PositionType в пакетах вроде TTNSingle_v3 или RepImportedProduct_v3) появились новые обязательные свойства: alcPercent (содержание алкоголя) и alcPercentMin (минимальное содержание алкоголя). Эти свойства ссылаются на базовый тип данных AlcPercentType.
Тип данных AlcPercentType должен быть определен в общем («родительском») XDTO-пакете с именем EGCommon (пространство имен http://fsrar.ru/WEGAIS/Common). Однако во время обновления конфигурации происходит сбой: новые подчиненные пакеты импортируются и обновляются, а базовый пакет EGCommon остается старой версии, где описание типа AlcPercentType попросту отсутствует. Платформа 1С при чтении метаданных обнаруживает битую ссылку на несуществующий тип данных и блокирует запуск системы.
Почему этот базовый пакет не обновляется автоматически? Как правило, это происходит в конфигурациях, которые находятся на поддержке с возможностью изменения (нетиповые базы). При использовании стандартного файла обновления .cfu или автоматического обновления механизм сравнения и объединения конфигураций может ошибочно сохранить старое состояние общего пакета EGCommon из-за выставленного приоритета основной конфигурации или режима «Сохранять объекты поставщика».
Если ошибка уже возникла в рабочей базе данных, а у вас нет времени или возможности откатывать обновление и проводить его заново, мы можем точечно вылечить конкретный XDTO-пакет. Для этого нам понадобится перенести корректную схему пакета из чистой типовой базы той же версии, на которую вы обновлялись.
Проанализируем этот процесс по шагам:
http://fsrar.ru/WEGAIS/Common).EGCommon.xsd).EGCommon.xsd.После этого тип данных AlcPercentType появится в структуре метаданных вашей базы, и проверка модели XDTO при запуске пройдет успешно.
Для понимания того, как описывается этот тип внутри импортируемого файла схемы, приведем фрагмент правильного XML-кода:
<xs:simpleType name="AlcPercentType">
<xs:restriction base="xs:decimal">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
Если ваша база данных является абсолютно типовой (в нее не вносились доработки программистами, на замочке нет измененных объектов), но обновление «встало криво» из-за сбоев платформы или кэша конфигуратора, лучшим решением будет полное замещение конфигурации.
Давайте рассмотрим, как правильно выполнить эту процедуру:
.dt или копированием файла 1cv8.1CD для файловой базы). Это критически важное правило для любых манипуляций в конфигураторе!1cv8.cf, а не дистрибутив обновления .cfu). Если дистрибутива нет, его можно получить, создав пустую базу из шаблона обновления и сделав выгрузку конфигурации через меню Конфигурация -> Сохранить конфигурацию в файл....1cv8.cf. Платформа предупредит, что текущая конфигурация будет полностью заменена. Соглашаемся.Этот метод гарантирует 100% восстановление исходной структуры метаданных поставщика. Все XDTO-пакеты обновятся до эталонного состояния, исключая любые конфликты версий.
Если ваша база данных содержит уникальные доработки и вы не можете воспользоваться вторым способом, необходимо провести процедуру сравнения и объединения вручную с контролем объектов ЕГАИС.
Разберем этот сценарий:
.cf (или .cfu) нового релиза.EGCommon, TTNSingle_v3, RepImportedProduct_v3, RepProducedProduct_v3).Иногда конкретный промежуточный релиз конфигурации (например, 3.0.59.26) выпускается разработчиками со внутренними ошибками или несовместимостью с текущей версией вашей платформы «1С:Предприятие». Если вы обновляетесь вручную, вы можете попробовать «перепрыгнуть» этот релиз.
Для этого мы можем применить следующую тактику:
В некоторых случаях ошибка проверки XDTO-модели вызвана некорректной работой локального кэша платформы «1С:Предприятие». Платформа кэширует схемы XML для ускорения работы, и при обновлении конфигурации кэш может не очиститься автоматически, продолжая подставлять старую структуру пакета EGCommon.
Для полной очистки кэша выполним следующие действия:
%userprofile%\AppData\Local\1C\1Cv8\%userprofile%\AppData\Roaming\1C\1Cv8\ibases.v8i трогать не нужно.
Применив один из рассмотренных нами методов, вы гарантированно избавитесь от ошибки валидации XDTO-моделей и сможете успешно запустить обновленную базу данных 1С.