Все о программе

  • автор:

Очень часто начинающие пользователи сталкиваются с проблемой выведения кнопочки «Все функции» в 1с 8.3. Для тех кто не знает, эта кнопка в меню позволяет просмотреть дерево всех объектов которые присутствуют в конфигурации. Для чего это может понадобиться? А для всего, ведь то что мы видим в пользовательском интерфейсе, никак не означает что мы видим все объекты конфигурации. Иногда быстрее и проще найти например какой-нибудь нужный документ или справочник в дереве конфигурации 1с 8.3, нежели в самом интерфейсе. Итак давайте приступим к решению нашего вопроса, а именно сделаем видимой кнопку «Все функции» в 1с 8.3 . Вы всегда можете заказать у нас комплексное обслуживание 1с, и тогда вопросов будет гораздо меньше, ведь мы рады помогать каждому нашему клиенту!

Добавление кнопки параметры в 1с 8.3

Для начала нам нужно добавить кнопку параметры, делаем это следующим образом, в правом верхнем углу есть маленькая стрелочка указывающая вниз, нажимаем ее и выпадет меню с доступными кнопками, те которые у нас включены отмечены галочками, те которые нет соответственно выключены. Включаем параметры.

Методология изменения версий продукта программного обеспечения


Software versioning — это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения.
При имеющейся категории номера версии (главная, второстепенная), номера обычно выставляются в возрастающем порядке и соответствуют новым разработкам в программном обеспечении. На начальном уровне отслеживанием постепенно появляющихся версий электронной информации занимается система управления версиями, позволяющая хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определяя, кто и когда сделал то или иное изменение и многое другое. Вместе с тем для отслеживания изменений программного обеспечения было создано большое количество схем присвоения номеров версиям.
Каждой стадии разработки программного обеспечения соответствует уникальный идентификатор, который состоит из последовательности номеров или букв. В некоторых схемах последовательные идентификаторы используются для определения значимости перемен между стадиями разработки: эти перемены классифицируются по уровням значимости. Решение о том какую последовательность изменить между стадиями разработки основано на значимости перемен на последней стадии разработки, например в схеме, с версией, состоящей из последовательности 4 чисел, первое число может быть прибавлено только тогда когда код полностью переписан, в то время как четвертое число изменяется при незначительных переменах в интерфейсе или документации.
В более поздних релизах, главное число (major) увеличивается, когда происходят значительные переходы в функциональности, второстепенное число (minor) прибавляется только тогда, когда были добавлены незначительные функции или внесены исправления. Номер версии изменяется, если исправлены все мелкие неполадки. Для типичного программного продукта используются следующие номера: 0.9 (для бета-версии), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, и т.д. Разработчики порой перескакивают от версии 5.0 сразу к 5.5, для того чтобы обозначить добавление нескольких значимых функций в программе, однако их не достаточно, чтобы изменить главный номер версии, тем не менее такие скачки все же неуместны.
Другой подход использования главных и второстепенных номеров версий заключается в добавлении буквенно-цифровой последовательности, определяя тем самым стадию разработки релиза: «альфа», «бета», «релиз кандидат». Серия версий с использованием этого подхода может выглядеть следующим образом: если к версиям 0.5, 0.6, 0.7, 0.8, 0.9 добавляются новые функции их можно назвать — 1.0b1, 1.0b2, еще плюс новые функции — 1.0b3, затем версия становится 1.0rc1. Если версия 1.0rc1 достаточно стабильна, то она становится 1.0, однако если в 1.0rc1 обнаруживаются ошибки, которые необходимо исправить она будет иметь номер 1.0rc2 и т.д. Важной характеристикой этого подхода является соблюдение идентичности стадий разработки версий. Нельзя вносить никаких изменений между последней бета-версией и первым релиз кандидатом или последним релиз кандидатом и готовым продуктом. Если вы это сделали, необходимо выпустить другую версию на более низкой стадии разработки.

Известные примеры буквенно-цифровых версий — Macromedia Flash MX, Adobe Photoshop CS2.
Иногда присутствие человеческого фактора в создании номеров версий приводит к ошибкам в изменении версий. Например, разработчики могут изменить последовательность между версиями, даже если одна строчка кода не была переписана, лишь для того чтобы создать ложное впечатление, что были внесены значительные изменения.

Обозначение стадии разработки

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

  • 0 — альфа
  • 1 — бета
  • 2 — релиз кандидат
  • 3 — публичный релиз

Например:

Разделение последовательностей

При публикации последовательности могут быть разделены знаками препинания. Выбор знаков препинания и их использования зависит от схемы.
В следующем перечне показаны возможные примеры разделенных схем на одном и том же релизе:

  • Схема может использовать один и тот же знак препинания между последовательностями: 2.4.13, 2/4/13, 2-4-13
  • Выбор схемы, какие числа разделять, а какие нет, может быть противоречивым: 2.413
  • Схема может использовать разные знаки препинания внутри одной последовательности: 2.4_13

Номера последовательностей

Иногда в схемах существует четвертое неопубликованное число, которое обозначает сборку (build) программного обеспечения (как это делает ,Microsoft). ,Adobe Flash наоборот больше всего выделяет четвертое число версии: 10.1.53.64. Некоторые компании также включают дату сборки. Номера версий могут включать буквы и знаки препинания: Lotus 1-2-3 Release 1a.

Приращение последовательности

Существует два разных способа приращения последовательности номеров в версии. Большинство продуктов свободного программного обеспечения используют непрекращаемый поток последовательных номеров: 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, и т.д. Примером такого продукта может служить MediaWiki. В других программах используются десятичные номера: 1.7, 1.8, 1.81, 1.82, 1.9, и т.д. В таких программах после версии 1.8 будет идти версия 1.81, текущие релизы будут обозначаться 1.81a, 1.81b, и т.д.

Использование дат в версиях

Разработчики проекта Wine использовали даты при нумерации версий, они указывали год, месяц и день релиза: «Wine 20040505». Сейчас Wine использует «стандартную» нумерацию релизов, последняя версия 2010 года имеет номер 1.2. Компания Ubuntu Linux использует похожую схему нумерации, например релиз апреля 2010 года пронумерован как Ubuntu 10.04. Номера сборок Microsoft Office тоже на самом деле закодированные даты.
Здесь следует отметить, что при использовании дат в нумерации версий необходимо использовать схему ISO, то есть сначала указывается год, затем месяц, а потом день (YYYY-MM-DD), причем дефис можно опускать.
Существуют также примеры нумерации версии годом выпуска (Adobe Illustrator 88, WordPerfect Office 2003). Хотя такой ход чаще всего используется в маркетинговых целях, и настоящий номер версии все равно существует. Например, версия Microsoft Windows 2000 Server на самом деле имеет номер Windows NT 5.0.

Схема нумерации версий TeX

Система TeX использует уникальную схему нумерации версий. После появления версии номер 3, ко всем последующим обновленным версиям после точки добавляли цифру, соответствующую последовательности числа Π это одна из форм унарной системы счисления – номер версии соответствует номеру цифры в числе Π. Номер последней версии 3.1415926. Такой метод отражает стабильность системы TeX. Разработчик TeX Дональд Кнут сказал, что последняя версия выйдет после его смерти и ее номер будет полное число Π, в которой все оставшиеся недочеты станут постоянными функциями. Подобной схемы придерживается METAFONT, нумеруя версии числами из математической константы e.

Схема Apple

,Apple использует формализованную структуру нумерации версий основанную на структуре NumVersion, она состоит из номера главной версии (1-2 числа), номера второстепенной версии (1 число), номера исправленной версии («bug» version) (1 число), индикатора стадии разработки (преальфа, альфа, бета и т.д.) и номера пререлиза (0-255). При написании этих номеров версий в строке, существовало условное соглашение опускать часть номера, обозначающую нулевую или последнюю стадию разработки. На пример: 1.0.2b12, 1.0.2 (вместо 1.0.2f0), и 1.1 (вместо 1.1.0f0).

Другие схемы

Производители программного обеспечения используют различные схемы для обозначения релиза их софта. Например, операционная система Microsoft Windows появилась на рынке со стандартной числовой схемой обозначения версий (от Windows 1.0 до Windows 3.11). Позднее разработчики Microsoft начали разделять названия версий в маркетинговых целях, то есть, сначала используя год релиза (Windows 95 (4.0), Windows 98 (4.10), Windows 2000 (5.0)), потом буквенно-цифровые коды (Windows Me (4.90), Windows XP (5.1)), после чего названия брендов (Windows Vista (6.0)). Судя по последнему релизу Windows 7, Microsoft снова вернулся к стандартной числовой схеме, хотя официальное название версии Windows 7 это 6.1.
В проекте Debian для релизов операционной системы используется «major/minor» схема, а для названий программных продуктов при разработке используются имена из мультфильма «История Игрушек».

Скрытые номера версий

Продукт программного обеспечения может иметь так называемый «скрытый» номер версии, который не указан в основном названии продукта (обычно в составлении скрытого номера соблюдаются все правила нумерации версий). Например, версия Java SE 5.0 имеет внутренний номер 1.5.0, а версии Windows начиная от NT 4, продолжают внутреннюю стандартную нумерацию версий: Windows 2000 это NT 5.0, XP это Windows NT 5.1, 2003 это NT 5.2, Vista это NT 6.0 и 7 это NT 6.1.

Предварительные версии продуктов программного обеспечения

Вместе с различными схемами обозначения версий, перечисленными выше, система, обозначающая предварительные версии используется в большинстве случаев как программа, прокладывающая себе путь через все стадии разработки программного обеспечения. Программы, находящиеся на ранних стадиях разработки называются «альфа» (первая буква греческого алфавита). Более зрелые программы, но еще не готовые к релизу называются «бета» (вторая буква греческого алфавита). В основном продукты программного обеспечения «альфа» тестируются только разработчиками, в то время как продуты «бета» распространяются на публичное тестирование. Этим двум версиям продукта обычно присваивается номер меньше 1, например 0.9, так как 1.0. это уже для публичного релиза. Однако если создается предварительная версия к уже существующему продукту, то она может быть обозначена буквой «а» (значит альфа) добавленной к номеру версии готового продукта, например версия 2.5 – предварительная версия 2.5.а или 2.5а. Продукты готовые к релизу могут быть обозначены тегом «rc-#», что означает релиз кандидат (release candidate). Когда версия уже выпущена, тег убирается.

Нечетные числа в обозначении версий для разработки релиза

Между сериями 1.0 и 2.6.x, Linux kernel использовал нечетную нумерацию версий, что бы обозначить релизы в разработке, а для стабильных релизов четную нумерацию. Например Linux 2.3 была серия разработок второго главного дизайна Linux kernel, а Linux 2.4 была серия стабильных релизов, в которую перерос Linux 2.3. В номере релиза Linux kernel сначала писался номер второстепенной версии, а затем номер релиза в возрастающем порядке. Например Linux 2.4.0 → Linux 2.4.22. После релиза 2.6 kernel в 2004 году, Linux больше не использует эту систему, теперь цикл релиза намного короче. Сейчас они просто увеличивают третье число, используя четвертое при необходимости.

Apple и нечетные числа

У компании Apple были свои особенности на счет нечетных чисел, особенно во время системы MacOS. Даже тогда когда выпускались второстепенные (minor) релизы номер версии редко был больше чем 1, а если номер нужно было увеличить они перескакивали сразу на 5, предлагая при этом небольшое изменение величины между главным и второстепенным релизом (например, 8.5 значит «восемь с половиной», а 8.6 значит «восемь с половиной точка один»). Завершенная последовательность версий выглядит так: 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (3.1 пропущена), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2.

Версия 1.0 как ключевой этап разработки

Разработчики проприетарного программного обеспечения всегда называют первый релиз программы версия 1, а затем увеличивают номер главной версии после каждого переписывания кода. Это значит, что программа может достичь версии 3 всего за несколько месяцев разработки, при этом она еще возможно не станет стабильной и надежной.
В отличие от компаний, сообщество свободного программного обеспечения используют версию 1.0 как ключевой этап разработки, обозначая тем самым, что продукт завершен, в нем есть все необходимые функции, и он достаточно надежен для публичного использования.
Согласно этой схеме, номер версии медленно приближается к 1.0 пока устраняются все недочеты в подготовке к релизу. Разработчики MAME, например, не стремятся выпускать версию 1.0 программы эмулятора, аргументируя это тем, что она никогда не будет до конца завершена, потому что аркадные игры будут появляться всегда. За версией 0.99 просто следует версия 0.100. Подобный пример Xfire, после релиза 1.99 идет 1.100. Так за 6 лет существования eMule все еще не достигли версии 0.50.

История программ

Winamp выпустил совершенно иную конфигурацию третьей версии программы, в которой отсутствовала обратная совместимость с плагинами и другими ресурсами предыдущей версии. Однако, эта версия стала полностью совместимой с версиями 2 и 3, но нумеровалась пятой, то есть 4 была пропущена… То же самое произошло с UnixWare 7, что было соединением UnixWare 2 и Open Server 5.

Как не отставать от конкурентов

В индустрии проприетарного программного обеспечения существует общая привычка перескакивать в нумерации главных и второстепенных версий в маркетинговых целях.
Это можно увидеть на примере нескольких продуктов Microsoft и America Online, а также в системе нумерации версий Sun Solaris, Java Virtual Machine, в версиях SCO Unix и Corel Word Perfect. Программные продукты filePro DB/RAD имели нумерацию от 2.0 к 3.0 к 4.0 к 4.1 к 4.5 к 4.8 к 5.0, и они уже готовят релиз 5.6, не имея при это ни одного промежуточного. Небольшую разницу можно заметить между версиями программного обеспечения AOL’s PC client, хотя они нумеруют только главные релизы — 5.0, 6.0, 7.0, и т.д. Таким же образом Microsoft Access перескочили от версии 2.0 к версии 7.0, чтобы догнать нумерацию версий Microsoft Word.
У корпорации Microsoft тоже была цель догнать нумерацию версий браузера Netscape, пропустив версию 5 и выпустив сразу шестую версию Internet Explorer.
Разработанный компанией Sun, язык программирования Java местами имел смешанную систему нумерации, при которой номер готовой версии всегда был 1.x, но три раза версия продавалась только со ссылкой на x:

  • JDK 1.0.3
  • JDK 1.1.2 через 1.1.8
  • J2SE 1.2.0 («Java 2») через 1.4.2
  • Java 1.5.0 («Java 5»)
  • Java 1.6.0 («Java 6»)

Компания Sun также упустила первый номер версии Solaris, где Solaris 2.8 (или 2.9) был настоящим номером версии Solaris 8 (или 9) согласно маркетинговым документам.

Суеверия

У релиза 2007 программы Microsoft Office был внутренний номер версии 12. Релиз Office 2010 внутренне нумеровался уже 14, из-за плохой репутации чертовой дюжины.
Версия 13 WordPerfect Office программы Corel обозначена в продаже как «X3» (римская цифра 10 и «3»). Процедура повторилась в следующей версии X4.

Как преодолеть маркетинговые трудности

В середине 1990х быстро развивающиеся на китайском рынке CMMS и Maximo, перескакивали от версии Maximo Series 3 сразу к Series 5, пропуская Series 4, так как неправильное произношение номера 4 на китайском языке могло означать «смерть» или «неудача». Хотя это, однако, не остановило Maximo Series 5 при выпуске релиза 4.0. Следует отметить, что на этом нумерация Series остановилась, но возобновилась вполне успешно, начиная с релиза 1.0.

Значимость нумерации версий в разработке программного обеспечения

Номера версий используются в практических условиях потребителем или клиентом для того, чтобы можно было сравнить имеющуюся у них копию продукта программного обеспечения и новую версию, выпущенную разработчиком. Команда программистов и компании используют нумерацию версий для сравнения отдельных частей и секторов программного кода одних версий с другими, обычно сотрудничая с Системой контроля версий. Не существует абсолютной и определенной схемы нумерации версий продуктов программного обеспечения, поэтому очень часто нумерация зависит от личного выбора программистов.
Использованы иллюстрации из статьи: «A successful Git branching model»
Перевод осуществлен сотрудницей компании «Chyrius» Натальей Володиной.

Приказ Правительства Москвы от 12 августа 2020 года, № 45/182/ПР-335/20 «Об этапах реализации Программы реновации жилищного фонда в городе Москве»Гражданский кодекс Российской Федерации (часть 1) от 30.11.1994 № 51-ФЗ. Гражданский кодекс Российской Федерации (часть 2) от 26.01.1996 № 14-ФЗ. Гражданский кодекс Российской Федерации (часть 3) от 26.11.2001 № 146-ФЗ. Гражданский кодекс Российской Федерации (часть 4) от 18.12.2006 № 230-ФЗ. Федеральный закон от 12 января 1996 года № 7-ФЗ «О некоммерческих организациях» Федеральный закон от 18 июля 2011 года № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» Федеральный закон от 1 июля 2017 года № 141-ФЗ «О внесении изменений в Закон Российской Федерации «О статусе столицы Российской Федерации» и отдельные законодательные акты Российской Федерации в части установления особенностей регулирования отдельных правоотношений в целях реновации жилищного фонда в субъекте Российской Федерации – городе федерального значения Москве»Закон города Москвы от 25 июня 2008 года № 28 «Градостроительный кодекс города Москвы»Закон города Москвы от 17 мая 2017 года № 14 «О дополнительных гарантиях жилищных и имущественных прав физических и юридических лиц при осуществлении реновации жилищного фонда в городе Москве»Постановление Правительства Москвы от 27 сентября 2011 года № 454-ПП «Об утверждении Государственной программы города Москвы «Жилище»Постановление Правительства Москвы от 2 мая 2017 года № 245-ПП «Об учете мнения населения по проекту реновации жилищного фонда в городе Москве»Постановление Правительства Москвы от 1 августа 2017 года № 497-ПП «О Программе реновации жилищного фонда в городе Москве»Постановление Правительства Москвы от 8 августа 2017 года № 515-ПП «Об утверждении Базовых требований к благоустройству территории жилой застройки при реализации Программы реновации жилищного фонда в городе Москве»Постановление Правительства Москвы от 8 августа 2017 года № 516-ПП «Об утверждении Требований к улучшенной отделке равнозначных жилых помещений, предоставляемых взамен жилых помещений в многоквартирных домах, включенных в Программу реновации жилищного фонда в городе Москве»Постановление Правительства Москвы от 8 августа 2017 года № 517-ПП «Об учреждении Московского фонда реновации жилой застройки»

Постановление Правительства Москвы от 1 сентября 2017 года № 624-ПП «О порядке рассмотрения обращений об исключении многоквартирных домов из Программы реновации жилищного фонда в городе Москве» Постановление Правительства Москвы от 26 сентября 2017 года № 708-ПП «Об утверждении адресного перечня кварталов (территорий), в границах которых расположены существующие или подлежащие образованию земельные участки, предназначенные для проектирования и строительства в течение 2017-2021 годов «стартовых» многоквартирных домов, обеспечивающих «волновое переселение» граждан в целях реализации Программы реновации жилищного фонда в городе Москве» Постановление Правительства Москвы от 1 февраля 2018 года № 45-ПП «О порядке приобретения собственниками жилых помещений в многоквартирных домах, включенных в Программу реновации жилищного фонда в городе Москве, или гражданами, имеющими право пользования такими жилыми помещениями на условиях социального найма, за доплату жилых помещений большей площади и (или) жилых помещений, имеющих большее количество комнат, чем предоставляемые им равнозначные жилые помещения» Постановление Правительства Москвы от 10 апреля 2018 года № 282-ПП «Об утверждении Положения о составе, порядке подготовки, согласования и представления на утверждение проектов планировки территории в целях реализации Программы реновации жилищного фонда в городе Москве»

XDTO – механизм 1С, который нужен при создании и использовании веб-сервисов в 1С.

Пакеты XDTO 1С позволяют описать структуру требуемого файла XML для преобразования данных в XML и из XML.

Кому интересно – разберем вопрос подробнее.

Что такое XML

XML – это способ в обычном текстовом файле описать сложную структуру данных. В XML указываются не только сами данные, но и поля, в которых они хранятся.

Пример файла XML:

<root>
<list name=”sky” id=”12”>
<el>Perfect blue sky</el>
</list>
</root>

Названия, которые были использованы в этом файле – root, name, list, el – могут быть совершенно произвольными.

Основные правила формирования XML файла сразу видны из его структуры:

  • Элементы могут быть вложены
  • Начало элемента , конец – то же имя с добавлением символа «/»
  • Внутри элемента могут быть
    o Вложенные элементы
    o Текст
  • У элемента могут быть свойства (атрибуты), у них указывается имя и значение.

В XML нельзя использовать любые символы, так как некоторые из них зарезервированы собственно для XML, например «».

XML очень удобно использовать при обмене со сторонними программами и он используется в механизме обмена данными 1С.

Пространство имен

XML файл часто начинается с заголовка, в котором описывается версия XML, кодировка и прочее. Заголовок в XML необязателен и его часто не используют.

В заголовке также может быть определено – пространство имен.

Файлы XML передаются через интернет, воспринимаются многими программами.

Воспринимаются – значит в их коде зашито – если встретишь в XML файле определенное имя элемента – воспринимай его вот так-то и делай вот это.

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

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

Далее используется в XML вот так:
вместо <apple color=»green»>
надо будет писать <store:apple color=»green»>

Зачем нужен URL?

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

Поэтому указывается некий уникальный идентификатор, определяющий заодно и автора пространства имен.

Естественно подразумевается, что указавший пространство имен исключительно честный человек и указал свой сайт и не использует с одним сайтом несколько разных пространств имен.

Кстати, обычно указывают не только URL сайта, но URL конкретной папки на сайте, чтобы если что, можно было создать другое пространство имен в другой папочке на сайте для его использования в другой ситуации.

DOM

Объект – это определенная структура данных, самодостаточная, содержащая все свои данные.

Так как в XML описаны структурированные данные, то есть в виде структуры, имеющие свои свойства и т.п., то на них можно смотреть как на объекты.

В приведенном примере это может быть объект LIST со свойством и вложенным элементом.

DOM – это способ рассмотрения файла XML не как текст в определенном формате, а как набор объектов со свойствами, полями и так далее.

Описание файла XML

Если мы используем файл определенной структуры постоянно для обмена между двумя программами, мы вероятно хотели бы:

  • Чтобы были использованы определенные названия
  • Чтобы были те элементы, которые мы ожидаем (которые «должны быть для использования в нашем обмене»)
  • Чтобы в атрибутах были указаны те типы, которые мы ожидаем (строка, число и т.п.).

Для описания структуры XML существуют следующие стандарты форматов файлов (которые также хранятся в обычном текстовом файле):

  • Расширение DTD – Document Type Definition
  • Расширение XSD – XML Shema.

Оба формата описывают каков должен быть документ. Процедура проверки соответствия XML описанному в таком файле стандарту называют верификация.

XDTO

XDTO 1С – это объект 1С, который позволяет в конфигурацию добавить описание XML файла. Вернее описывается не файл, а конкретные структуры XML.

Чтобы указать типы, возможные к использованию – используется список, библиотека типов – которую называют фабрика XDTO 1С.

В этой фабрике указаны как простые типы (строка, число, дата), которые принято использовать в других языках, программах и т.п., но и типы 1С, которые используется в 1С и в конкретной конфигурации.

Фабрика XDTO 1С сама состоит из нескольких пакетов. Базовые типы описаны в пакете с именем www.w3.org

Типы данных текущей конфигурации описаны в пакете http://v8.1c.ru/8.1/data/enterprise/current-config

Сами типы называются в соответствии с именем в конфигураторе с добавлением англоязычного вида (CatalogRef, CatalogObject, DocumentRef, DocumentObject), например:

CatalogObject.Номенклатура

Добавление пакета XDTO 1С

Безусловно все это круто звучит. И мы не дошли еще до темы XSLT – способа преобразовывать файлы XML во что-то другое, например в HTML. Тема XML исключительно большая и ее сложно включить даже в отдельную книгу.

Наша задача – понять, что XDTO 1С позволяет описать какие элементы должны быть у пакета XML, который нужно сформировать или считать.

Пакеты XDTO 1С находятся в конфигурации в ветке Общие/Пакеты XDTO 1С.

Добавить пакет XDTO в 1С можно вручную (круто!), но лучше достать соответствующий XSD файл с готовым описанием схемы.

Описание XSD схемы объектов любой конфигурации можно получить нажатием на ветку Общие/Пакеты XDTO 1С и выбрав пункт меню Экспорт XML схемы конфигурации.

Файл текстовый, Вы можете отредактировать его в блокноте Windows, убрав лишние, ненужные Вам объекты.

Добавить готовую XSD схему в 1С можно нажав правой кнопкой на ветку Общие/XDTO 1С пакеты и выбрав пункт меню Импорт XML схемы.

Использование механизма XDTO 1С

Работа с XDTO 1С – это преобразование значений в XML и из XML.

Работа ведется с помощью объектов языка 1С ЧтениеXML/ЗаписьXML.

При работе с механизмом XDTO 1С Вы должны указать пакет, с которым работаете. Это может быть типовой пакет (обсуждали выше, см. XDTO) или добавленный в конфигурацию пакет. Идентификация пакета производится по URL, указанному в пакете.

Два основных простых способа работы – это:

  • Сериализация – автоматическое преобразование значений из 1С в XML и наоборот
  • Создание объекта, заполнение его полей, запись в XML (и соответственно чтение из XML и потом чтение его полей).

Обратная функция – Сериализатор.ПрочитатьXML(), используется с объектов языка 1С ЧтениеXML.

Пример чтения/записи объекта:

Далее можно записать созданный объект в XML точно таким же способом, как и сериализация. При чтении XML тем же способом, что и выше, может вернуться не значение XDTO, а вот такой объект.

  • При создании объекта XDTO – создается структура, аналогичная структуре объекта конфигурации (конечно, если Вы создаете объект конфигурации из пакета, указанного в примере)
  • Типовые поля (код, наименование и т.д.) – англоязычные
  • Объект создается пустой, его нужно заполнять, каждое поле отдельно или с использованием функции ЗаполнитьЗначенияСвойств

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *