/
Текст
А. П. Габец, Д. И. Гончаров, Д. В. Козырев, Д. С. Кухлевский, М. Г. Радченко
ПРОФЕССИОНАЛЬНАЯ
РАЗРАБОТКА В СИСТЕМЕ
1С:ПРЕДПРИЯТИЕ 8
ПАБЛИШИНГ
Москва
ООО «1С-Паблишинг»
[^ППТЕР
Москва • Санкт-Петербург • Нижний Новгород Воронеж
Ростов-на-Дону Екатеринбург Самара Новосибирск
Киев • Харьков Минск
2006
ББК 32.973.23-018.2
УДК 004.382.7
П84
Габец А. П., Гончаров Д. И., Козырев Д. В., Кухлевский Д. С., Радченко М. Г.
П84 Профессиональная разработка в системе 1С:Предприятие 8 (+CD) / Под ред. М. Г. Радченко. —
М.: «1С-Паблишинг»; СПб.: Питер, 2006. — 808 с.: ил.
ISBN 5-9677-0268-7
ISBN 5-91180-076-4
Издание посвящено углубленному изучению вопросов создания, оптимизации и под-
держки прикладных решений на платформе системы 1С:Предприятие 8. В нем рассматри-
вается архитектура системы и прикладных решений, описывается структура и реализа-
ция прикладных механизмов. Значительное внимание уделяется организации хранения
данных и обеспечению эффективной работы прикладных решений. Также описываются
методические подходы к созданию и поддержке прикладных решений, рассматриваются
механизмы системы, которые используются для реализации этих задач.
Книга рассчитана на разработчиков, обладающих некоторым навыком создания и мо-
дификации прикладных решений в системе 1 С: Предприятие 8 и желающих повысить
свой профессиональный уровень. Также она будет интересна IT-специалистам, не занимаю-
щимся разработкой, но желающим получить представление о возможностях системы, ее
идеологии, архитектуре и реализации конкретных механизмов.
В помощь разработчикам прикладных решений книга содержит компакт-диск с демонстра-
ционными конфигурациями и кодом примеров, описанных в книге. Код примеров пред-
ставлен в виде файлов шаблонов текстов, которые могут быть использованы при разра-
ботке конфигураций.
Книга дополняет, но не заменяет штатную документацию к программному продукту,
входящую в комплект поставки, и позволяет более эффективно использовать возможно-
сти программы.
ББК 32.973.23-018.2
УДК 004.382.7
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного
разрешения владельцев авторских прав.
Полное или частичное копирование материалов книги без письменного разрешения фирмы «1С-Паблишинг» запрещается.
ISBN 5-9677-0268-7
ISBN 5-91180-076-4
© ООО «1С-Паблишинг», 2006
© Оформление, ООО «1С-Паблишинг», 2006
© Оформление, ЗАО Издательский дом «Питер», 2006
Введение
Об авторах
Андрей Габец
Андрей Габец имеет высшее техническое образование, ра-
ботает в московской компании «Аналит», которая явля-
ется партнером фирмы «1С». Он специализируется на ре-
шении задач оперативного учета, руководит внедрениями
«торговых» прикладных решений, отвечает за подготовку
специалистов компании по направлению оперативного
учета.
В то же время Андрей преподает в 1 С-Учебном центре
№3. Этот учебный центр — совместный проект фир-
мы «1С» и компании «Аналит». Андрей является автором
и преподавателем целого ряда учебных курсов, в том числе:
♦ Конфигурирование в системе 1С:Предприятие 8.0. Ре-
шение оперативных задач (сертифицированный курс);
♦ 1С:Предприятие 8.0. Внедрение и адаптация конфигу-
рации Управление торговлей (сертифицированный курс).
Помимо своей преподавательской деятельности Андрей
известен читателям как соавтор книги «1 С:Предприятие
8.0. Простые примеры разработки».
В книге «Профессиональная разработка в системе 1С:Пред-
приятие 8.0» Андрей выступил как автор следующих глав:
♦ глава 6, «Хранение информации»;
♦ глава 7, «Документы, последовательности»;
♦ глава 8, «Реализация задач учета движения средств».
Дмитрий Гончаров
Дмитрий Гончаров имеет высшее техническое образова-
ние и работает в московской компании «Аналит». Он ру-
ководит внедрениями прикладных решений в области
торговли и медицины. Специализируется на решении
задач оперативного учета, интеграции с другими инфор-
мационными системами. Является автором нескольких
тиражных прикладных решений, выпущенных как компа-
нией «Аналит», так и компанией «Аналит» совместно
с фирмой «1С».
Помимо работы с клиентами компании, Дмитрий препо-
дает в 1С-Учебном центре № 3 и, кроме этого, принимает
экзамены 1С:Специалист по платформе и прикладным
решениям 1 С:Предприятия 8.0 как в Москве, так и на вы-
ездных аттестациях. Он является автором и преподавате-
лем целого ряда учебных курсов, в том числе:
♦ Введение в конфигурирование в системе 1 С:Предпри-
ятие 8.0. Основные объекты (сертифицированный курс);
♦ Использование запросов в системе 1С:Предприятие 8.0
(сертифицированный курс);
♦ Введение в конфигурирование в системе 1С:Предпри-
ятие 8.0 (дистанционный курс);
♦ Средства интеграции и обмена данными в системе
1 С:Предприятие 8.0 (сертифицированный курс);
♦ Web-расширение.
Дмитрий также известен читателям как соавтор книги
«1С:Предприятие 8.0. Простые примеры разработки».
Для книги «Профессиональная разработка в системе
1 С: Предприятие 8.0» Дмитрий подготовил следующие
главы:
♦ глава 11, «Механизм бизнес-процессов»;
♦ глава 12, «Использование механизма анализа данных
и прогнозирования»;
♦ глава 14, «Интеграция с другими информационными
системами»;
♦ глава 15, «Создание распределенных информационных
систем»;
♦ глава 16, «Web-расширение».
Дмитрий Козырев
Дмитрий Козырев имеет высшее экономическое образова-
ние по специальности «Бухгалтерский учет» и работает в
московской компании «Аналит». Он отвечает за внедрения
бухгалтерских прикладных решений и подготовку специа-
листов компании по направлению бухгалтерского учета.
Сейчас Дмитрий преподает в 1С-Учебном центре № 3.
Он является автором ряда учебных курсов, в том числе:
♦ Конфигурирование в системе 1С:Предприятие 8.0. Ре-
шение бухгалтерских задач (сертифицированный курс);
♦ 1С:Предприятие 8.0. Внедрение и адаптация конфи-
гурации Бухгалтерия предприятия (сертифицирован-
ный курс).
Для этой книги Дмитрий подготовил главу 9 «Реализа-
ция задач бухгалтерского учета».
Дмитрий Кухлевский
Дмитрий Кухлевский имеет высшее экономическое обра-
зование по специальности «Финансы и кредит». Дмит-
рий работал в московской компании «РГ-Софт», которая
является партнером фирмы «1С». Его специализация —
решение задач расчета заработной платы.
Сейчас Дмитрий преподает в 1 С:Учебном центре № 1, ко-
торый является подразделением фирмы «1С». Дмитрий —
автор и преподаватель таких курсов, как:
♦ Конфигурирование подсистем расчета зарплаты и управ-
ления персоналом в прикладных решениях для 1С:Пред-
приятия 8.0;
♦ Бюджетирование в прикладном решении Управление
производственным предприятием (интернет-курс).
Для этой книги Дмитрий подготовил главу 10, «Реализа-
ция сложных периодических расчетов».
Максим Радченко
Максим Радченко имеет высшее техническое образование,
работает в фирме «1С». Его основной специализацией яв-
ляется методика использования платформы 1С:Предпри-
ятия 8.0 для создания прикладных решений.
Максим является автором книги «1С:Предприятие 8.0.
Практическое пособие разработчика. Примеры и типовые
приемы». Кроме этого, под его редакцией была выпущена
книга «1 С: Предприятие 8.0. Простые примеры разработ-
ки» (авторы Андрей Габец и Дмитрий Гончаров).
Книга, которую вы держите в руках, также выпущена
под редакцией Максима Радченко. Кроме того, Максим
выступил в этой книге еще и в роли автора следующих
глав:
♦ Введение;
♦ глава 1, «Архитектура 1С:Предприятия»;
♦ глава 2, «Функциональность 1С:Предприятия»;
♦ глава 3, «Использование встроенного языка»;
♦ глава 4, «Работа с данными»;
♦ глава 5, «Клиент -серверный вариант работы»;
♦ глава 13, «Средства построения отчетов»;
♦ глава 17, «Поставка прикладных решений»;
♦ глава 18, «Методология разработки»;
♦ Приложение.
Благодарности
Написание такой книги, как эта, всегда требует совмест-
ных усилий. В создании этой книги также приняло уча-
стие кроме собственно авторов большое количество спе-
циалистов.
Выражаем признательность всем, кто высказал свои за-
мечания по тем или иным разделам книги — Александру
Алексееву, Александру Безбородову, Александру Вино-
градову, Андрею Волкову, Геннадию Дамье, Одею Деруту,
Дмитрию Зарецкому, Сергею Копиенко, Максиму Лейбо-
вичу, Евгению Митрошкину, Сергею Мурзину, Сергею
Нуралиеву, Константину Рупасову, Павлу Чикову и Анд-
рею Чичерину.
Хочется поблагодарить Одея Дерута, Дмитрия Русанова
и Виталия Филиппова, которые оказали помощь авторам
в разборе сложных вопросов по реализации и функцио-
нированию системы.
При создании книги использовались с разрешения фир-
мы «1С» материалы информационно-технологического
сопровождения и материалы докладов партнерских кон-
ференций. Мы выражаем признательность авторам этих
материалов и выступлений.
Отдельно хочется поблагодарить Константина Рупасова
за материал по методике тестирования и оптимизации па-
раллельности работы прикладных решений.
Также мы благодарим Евгения Медведева, Сергея Позд-
някова, Константина Рупасова и Павла Чикова, которые
выступили в качестве «бета-тестеров» некоторых глав
и разделов книги.
Наконец, мы хотим выразить признательность тем, кто
помогал нам в подготовке издания этой книги. Андрею
Баратынскому — за разработку дизайна оформления кни-
ги. Наталии Моисеенко — за организацию работы с изда-
тельством и типографией. Ирине Ульяновой — за органи-
зационную помощь. Светлане Юткиной — за помощь
в технической подготовке материала.
От редактора
Идея этой книги заключается в том, чтобы собрать воеди-
но и систематизировать наиболее важную информацию,
которая может понадобиться разработчику прикладных
решений 1С:Предприятия 8.0. Уровень изложения мате-
риала предполагает, с одной стороны, что разработчик
уже знаком с системой 1С:Предприятие 8.0, а с другой
стороны — что в этой книге он сможет найти ответ даже
на довольно сложные вопросы, возникающие в процессе
разработки.
В одной книге, пусть даже такой большой, невозможно
охватить абсолютно все ситуации, которые могут возник-
нуть при разработке прикладных решений. Однако на по-
давляющее большинство вопросов, возникающих перед
разработчиками, книга дает ответы. Причем книга будет
одинаково интересна как начинающим разработчикам,
так и более «продвинутым».
Как правило, прикладные разработчики имеют достаточ-
но четко определенную специализацию, сосредоточивая
свои усилия на решении задач одной предметной облас-
ти. Это видно даже по составу авторов этой книги. Вместе
с этим, довольно часто возникают ситуации, когда прихо-
дится осваивать «смежные» прикладные области для
того, чтобы внести небольшие исправления в существую-
щее решение или, наоборот, создать новую подсистему.
Поэтому книга, помимо собственно глубокого изложения
прикладных механизмов, содержит общие сведения как о
самих механизмах, так и об автоматизируемой предмет-
ной области. Благодаря этому разработчик, хорошо зна-
комый с системой, но специализирующийся, например,
на решении задач оперативного учета, всегда сможет бы-
стро разобраться с задачами начисления заработной пла-
ты и понять работу механизмов, которые используются
для решения этих задач.
При написании этой книги мы стремились, чтобы она стала
«серьезным инструментом для серьезных разработчиков»,
книгой, к которой всегда можно обратиться в случае затруд-
нений и которую просто интересно прочитать, чтобы узнать
что-то новое о хорошо известной предметной области или
познакомиться с новым взглядом на привычные вещи.
От себя лично и от всех авторов этой книги хочу поже-
лать вам успехов в изучении системы 1 С:Предприятие
и повышения вашего профессионального мастерства!
Максим Радченко
Особенности книги
Существует ряд особенностей, отличающих эту книгу от
других книг, посвященных системе 1 С:Предприятие 8.0.
Прежде всего, это освещение вопросов, которые обычно
остаются в тени, когда речь идет о прикладных разработ-
ках. Например, такие вопросы, как общая концепция сис-
темы, описание используемых таблиц и принципы хране-
ния информации системы.
При описании тех или иных прикладных механизмов ав-
торы стремились дать общее представление о механизме,
его месте в системе, рассказать идеологию его работы. По
мнению авторов, это поможет разработчику строит эффек-
тивные решения исходя из понимания идеологии работы
механизма, выбирать те или иные варианты реализации,
основываясь на знании принципов работы механизма.
Довольно много внимания в книге уделено методологи-
ческим вопросам разработки прикладных решений, когда
прикладное решение создается коллективом разработчи-
ков. Рассматривается использование механизма групповой
разработки. Также излагается методика настройки произ-
водительности прикладного решения, рассматриваются
конкретные шаги и инструменты, используемые на каж-
дом из уровней, которые следует использовать в обычной
практике. Также, для отдельных случаев, когда требуется
индивидуальная настройка прикладного решения, изла-
гается простейшая методика настройки производитель-
ности, используя средства, предоставляемые SQL Server.
Применительно к вопросам методологии создания при-
кладных решений рассматриваются механизмы интерна-
ционализации, содержащиеся в системе, их влияние и ис-
пользование в каждом из элементов системы. Этот раздел
дает целостное представление о всех средствах интерна-
ционализации, которые содержит 1С:Предприятие 8.0.
При подготовке материала этой книги были использова-
ны самые различные источники информации:
♦ опыт преподавания на учебных курсах по платформе
и прикладным решениям 1С:Предприятия 8.0;
♦ опыт внедрения прикладных решений;
♦ опыт, накопленный разработчиками фирмы «1С»;
♦ материалы информационно-технологической поддерж-
ки (ИТС);
♦ материалы форума партнеров-разработчиков на http://
partners.v8.lc.ru;
♦ общение на партнерских семинарах, проводимых фир-
мой «1С».
Как читать книгу
Главы книги составлены таким образом, чтобы можно
было читать их как подряд, так и выборочно.
Чтение книги по порядку позволяет получить целостное
представление о системе и ее возможностях, постепенно
переходя от общих архитектурных решений к более кон-
кретным прикладным механизмам и их реализации.
В то же время книгу можно читать отдельными главами,
если требуется изучить работу какого-то конкретного
прикладного механизма или понять принципы работы
системных механизмов.
Книга содержит достаточно подробное оглавление, что
позволяет обращаться к отдельным разделам книги в тех
случаях, когда нужно разобраться в конкретных особен-
ностях работы того или иного механизма или просто ос-
вежить их в памяти.
Структура книги
Книга состоит из 18 глав и приложения, которые охваты-
вают практически всю функциональность системы 1С:Пред-
приятие.
Главы 1 и 2 носят общий характер и посвящены системе
1С:Предприятие в целом.
В главе 1 рассказывается об архитектуре 1С:Предпри-
ятия — о том, из каких частей состоит система, какие ар-
хитектурные решения использованы при построении тех
или иных элементов системы.
Глава 2 содержит обзор функциональности, предостав-
ляемой технологической платформой 1С:Предприятия.
Отдельно рассматриваются возможности прикладных ре-
шений, рассказывается о средствах разработки, содержа-
щихся в технологической платформе, а также описыва-
ются средства администрирования информационных баз
1 С:Предприятия.
В главе 3 рассматриваются общие вопросы, касающиеся
использования встроенного языка технологической плат-
формы. Объясняется структура прикладного решения, мо-
дули, которые может содержать конфигурация, а также
рассматриваются возможности работы с метаданными сред-
ствами встроенного языка.
Глава 4 рассказывает об общих принципах и особенностях
работы с данными с точки зрения системы 1С:Предпри-
ятие. Рассматривается два основных подхода к представле-
нию данных системой: объектные и необъектные данные.
Рассказывается о типах данных, которые использует сис-
тема. Описываются принципы использования транзакций
в 1 С:Предприятии, также рассматривается использование
системой транзакций базы данных и уровни блокировок,
устанавливаемые в различных режимах работы системы.
В главе 5 книги излагаются особенности применения
клиент-серверного варианта работы, сервера 1С:Пред-
приятия. Описывается механизм управления исполнени-
ем кода на сервере и на клиенте.
Главы книги, с 6 по 10, посвящены описанию конкретных
прикладных механизмов, которые содержит система. Об-
щим для этих глав является то, что помимо собственно
прикладной функциональности, предоставляемой теми
или иными механизмами, рассматривается их реализа-
ция, описываются алгоритмы формирования виртуаль-
ных таблиц запросов и рассматриваются вопросы дости-
жения оптимальной производительности при работе
с этими механизмами.
Глава 6 излагает общий взгляд на вопросы хранения раз-
личной информации в системе 1С:Предприятие. В зависи-
мости от логической структуры информации, ее назначе-
ния, могут использоваться те или иные средства системы.
В частности, в главе подробно рассматривается использо-
вание регистров сведений и планов видов характеристик.
Глава 7 рассматривает работу с документами, журналами
документов и последовательностями. В главе подробно
рассматриваются различные особенности использования
документов, а также важные моменты, на которые следует
обращать внимание при работе с последовательностями.
Глава 8 целиком посвящена вопросам организации учета
движения различных средств с использованием регист-
ров накопления. Подробно рассматриваются приемы и
особенности получения данных из регистров с использо-
ванием различных виртуальных таблиц.
Глава 9 рассматривает вопросы организации бухгалтер-
ского учета с использованием системы 1С:Предприятие.
Изложение для примера опирается на требования к веде-
нию бухгалтерского учета, принятые в России, однако не
менее подробно рассматриваются и более широкие воз-
можности бухгалтерских механизмов, которые есть в сис-
теме. Полное понимание этих возможностей позволяет
эффективно использовать бухгалтерские механизмы для
решения, например, задач управленческого учета или для
автоматизации бухгалтерского учета в других странах.
В главе 10 описываются возможности системы по органи-
зации сложных периодических расчетов. Основное при-
менение эти механизмы находят, как правило, в задачах
расчета заработной платы, однако могут быть использо-
ваны и в других областях.
В главе 11 речь идет о механизме бизнес-процессов, реа-
лизованном в системе. Рассматривается его назначение
и конкретные примеры использования.
Глава 12 посвящена описанию механизмов анализа данных
и прогнозирования. Эти механизмы, как правило, использу-
ются для получения аналитической информации, при фор-
мировании отчетов для специалистов-аналитиков.
Глава 13 описывает средства системы, используемые для
формирования отчетов. В первой части главы подробно
рассматривается устройство и возможности использова-
ния построителя отчета на конкретных примерах. Вторая
часть главы посвящена описанию текстового и таблично-
го документа как основных средств для отображения по-
лученных данных.
Главы книги с 14 по 16 посвящены различным способам
интеграции информационных баз системы 1 С: Предпри-
ятие с другими информационными системами, в том чис-
ле и не основанными на 1С:Предприятии.
Глава 14 описывает различные способы взаимодействия
1С:Предприятия с «внешним миром». Рассматривается
работа с текстовыми файлами, с файлами DBF, с XML-
документами. Описываются возможности использова-
ния интернет-технологий, взаимодействия по прото-
колам HTTP, FTP, работа с электронной почтой. Также
рассматриваются примеры использования обмена сооб-
щениями на основе технологий MSMQ и WebSphere MQ.
В конце главы излагаются возможности системы по ис-
пользованию технологий COM, Automation, ActiveX
и ActiveDocument.
В 15 главе описываются механизмы обмена данными, со-
держащиеся в системе 1С:Предприятие. Подробно рас-
сматривается универсальный механизм обмена данными
и механизм распределенных информационных баз. Рас-
сматриваются различные сценарии обмена.
В главе 16 речь идет о Web-расширении. В начале главы
дается краткое описание используемых технологий. Да-
лее рассматриваются примеры создания веб-приложений
и веб-сервисов, описываются особенности использования
различных механизмов Web-расширения.
Заключительные главы, 17 и 18, посвящены вопросам ин-
дустриальной разработки и сопровождения прикладных
решений.
В главе 17 рассматриваются механизмы поставки и под-
держки прикладных решений, и механизм создания
комплектов поставки. Приводятся примеры различных
сценариев поддержки прикладных решений, примеры
создания комплектов поставки.
В заключительной 18 главе излагаются методологиче-
ские вопросы создания прикладных решений. Дается об-
щий взгляд на прикладное решение затем более подробно
рассматриваются различные этапы: проектирование,
групповая разработка, оптимизация производительности,
создание многоязычных прикладных решений. Излагает-
ся общая методика и алгоритм оптимизации производи-
тельности, дается целостный взгляд на средства интерна-
ционализации, содержащиеся в системе.
Приложение содержит сведения о размещении данных
системы 1С:Предприятие, особенностях хранения значе-
ний составного типа и построении индексов.
Что находится на компакт-диске
К книге прилагается компакт-диск, который содержит
материалы, предназначенные для самостоятельного изу-
чения и использования.
Прежде всего, это три демонстрационные конфигурации,
которые используются в ходе изложения различных глав
книги:
♦ конфигурация «Хранение информации и учет движе-
ния средств» используется для иллюстрации материа-
ла, изложенного в главах с 6 по 8;
♦ конфигурация «Бухгалтерский учет» используется для
иллюстрации материала, изложенного в главе 9;
♦ конфигурация «Сложные периодические расчеты» ис-
пользуется для иллюстрации материала, изложенного
в главе 10.
Все демонстрационные конфигурации содержатся на ком-
пакт-диске в виде дистрибутивов. После запуска испол-
няемого файла шаблоны конфигураций устанавливаются
в текущий каталог шаблонов. Конфигурации созданы
в версии 1С:Предприятия 8.0.14.
Также компакт-диск содержит все фрагменты листингов,
приведенных в книге. Использование этих фрагментов
может быть полезным как при чтении книги, так и в даль-
нейшей работе. Поэтому фрагменты оформлены в виде
файла шаблонов текста 1 С:Предприятия — DevEnc.st.
Этот файл может быть подключен к любой конфигура-
ции с помощью команды Сервис ► Шаблоны текста ► Дей-
ствия ► Файлы шаблонов ► Добавить (рис. 0.1).
Фрагменты кода сгруппированы по главам, для каждого
фрагмента кода в качестве строковой последовательности,
которая будет заменяться при вводе текста, указывается
номер листинга, содержащего соответствующий фрагмент
кода. Замена строковой последовательности может произ-
водиться автоматически, если установлен режим автозаме-
ны, или вручную, с помощью комбинации клавиш Ctrl + Q.
Режим автозамены устанавливается командой Сервис ►
Параметры ► Тексты ► Модулей ► Автозамена. Также любой шаб-
лон текста может быть просто перенесен мышью в произ-
вольное место модуля.
Рис. 0.1. Шаблоны текста листингов
Скажите нам, чтобы думаете
В процессе подготовки этой книги мы прилагали значи-
тельные усилия для того, чтобы устранить возможные не-
точности и опечатки, однако не можем гарантировать их
отсутствие на 100%.
Мы понимаем, сколько негативных эмоций может доста-
вить пример, который не работает, например, потому, что
в имени переменной допущена ошибка. Поэтому обнару-
женные неточности мы публикуем по адресу http://v8.lc.ru/
book/DevEnc/Erratum.htm.
На этой же странице расположена форма, с помощью ко-
торой вы можете сообщить нам информацию об обнару-
женных неточностях, а также ваши впечатления об этой
книге и пожелания по ее совершенствованию.
Мы ценим обратную связь с читателями и с благодарно-
стью примем как слова критики, так и слова одобрения,
и учтем их в работе над будущими изданиями.
От издателей
Ваши замечания, предложения и вопросы отправляйте по
адресам publishing@lc.ru (издательство «1С-Паблишинг»),
а также comp@piter.com (издательство «Питер», компью-
терная редакция).
Мы будем рады узнать Ваше мнение! Подробную инфор-
мацию о книгах серии «1 С: Библиотека» вы найдете на
сайте фирмы «1С»: www.lc.ru и сайте издательства «Питер»:
www.piter.com.
Глава 1. Архитектура 1С:Предприятия
Говоря о системе 1 С:Предприятие в широком смысле,
можно сказать, что она представляет собой совокупность
четырех составляющих (рис. 1.1):
♦ технологической платформы;
♦ прикладных решений различного масштаба и различ-
ной направленности, созданных на основе технологиче-
ской платформы;
♦ методологии создания прикладных решений;
♦ информационно-технологической поддержки пользо-
вателей и разработчиков.
Рис. 1.1. Структура ^Предприятия
Такая архитектура продиктована, прежде всего, теми зада-
чами, которые призвана решать система 1С:Предприятие.
Во-первых, система должна обеспечивать высокий уро-
вень адаптируемости прикладных решений под требова-
ния заказчика.
Во-вторых, система должна обеспечивать изменение гото-
вого прикладного решения разработчиком, не участвовав-
шим в его создании. Это особенно важно для прикладных
решений в сфере экономических задач, где существенная
часть разработчиков не создает собственные прикладные
решения, а дорабатывает и развивает существующие ти-
повые решения.
В-третьих, система должна обеспечивать эффективное
использование компьютерных технологий и платформ,
не требуя, при этом, глубоких специальных знаний от
разработчика.
В-четвертых, система должна обеспечивать стандартиза-
цию разработки.
Таким образом, можно сказать, что 1С:Предприятие пе
является универсальным средством программирования.
Система обладает достаточно широкими возможностями,
однако ее архитектура и конкретная реализация механиз-
мов и технологий платформы продиктована, прежде все-
го, необходимостью решения специализированных задач
по созданию бизнес-приложений и требованиями, предъ-
являемыми к самой системе.
Платформа и прикладные решения
Основным концептуальным решением, отличающим сис-
тему 1 С:Предприятие 8.0 от универсальных средств про-
граммирования, является четкое разделение на платфор-
му и прикладное решение.
Прикладное решение 1С:Предприятия является самостоя-
тельной сущностью и может выступать в качестве отдель-
ного программного продукта. Однако создание, моди-
фикация и собственно функционирование прикладного
решения невозможны без использования технологий и
механизмов платформы. Поэтому платформа поставляет-
ся с каждым комплектом 1С:Предприятия.
Средства разработки в составе платформы
Прикладные решения 1С:Предприятия являются откры-
тыми. Благодаря этому клиент с помощью разработчика,
или собственными силами, может модифицировать и на-
страивать любое прикладное решение «под себя».
Для модификации прикладных решений не требуется ис-
пользовать какие-либо отдельные программные продук-
ты — все средства разработки входят в состав технологи-
ческой платформы.
Можно сказать, что платформа состоит из двух состав-
ляющих (рис. 1.2):
Рис. 1.2. Структура технологической платформы ^Предприятия
♦ среда исполнения;
♦ среда разработки.
Таким образом, обеспечивается высокий уровень адапти-
руемости прикладных решений под требования заказчика.
Метаданные — способ описания прикладного решения
Прикладное решение 1С:Предприятия не пишется в пря-
мом смысле слова на языке программирования. При созда-
нии прикладных решений 1 С:Предприятия используется
более абстрактная технология — технология метаданных.
Метаданные представляют собой иерархическую струк-
туру объектов, полностью описывающую все прикладное
решение. Среда исполнения 1С:Предприятия исполняет,
«проигрывает» метаданные, аналогично тому, как опера-
ционная система исполняет код привычной программы.
Отличительной особенностью технологии метаданных
является использование визуального конструирования
прикладного решения. Вместо кропотливого написания
кода разработчик просто добавляет визуальными средст-
вами новый объект метаданных в прикладное решение и
получает сразу же описания нужных типов, структур дан-
ных, описаний наборов прав, связи между объектами, ин-
формацию об особенностях их поведения, визуального
представления и т. д.
Метаданные
и встроенный язык
Все прикладное решение представляется не в виде строк
с инструкциями на языке программирования, а в виде -
иерархической структуры объектов метаданных. При
этом разработчик использует встроенный язык и язык за-
просов для того, чтобы описать специфические алгорит-
мы поведения тех или иных объектов конфигурации
в различные моменты исполнения прикладного решения.
Использование встроенного языка при разработке при-
кладных решений ограничено в основном решением тех
задач, которые действительно требуют алгоритмического
описания, например расчета налогов, проверки корректно-
сти введенных данных и пр. Основная же структура при-
кладного решения описывается структурой метаданных.
Почти все объекты метаданных содержат модули, в кото-
рых и могут быть описаны алгоритмы на встроенном язы-
ке. Эти модули будут вызываться средой исполнения в
конкретные, заранее определенные моменты работы при-
кладного решения — события. Таким образом, можно ска-
зать, что использование встроенного языка в прикладных
решениях носит событийный характер.
Подсистемы
Платформа 1С:Предприятия 8.0 позволяет выделить в при-
кладном решении отдельные части — подсистемы, —
в совокупности представляющие все прикладное реше-
ние. Подсистемы могут иметь иерархическую структуру,
то есть одна подсистема может включать в себя несколько
других подсистем.
Каждый объект метаданных, описывающих данное при-
кладное решение, может быть отнесен к одной или не-
скольким подсистемам. Таким образом, в терминах подсис-
тем можно описать всю структуру прикладного решения.
В дальнейшем это описание может быть использовано
в различных средствах разработки, например для автомати-
ческого формирования прав на основе подсистем или для
автоматического построения интерфейсов пользователей.
Создание прикладных решений на основе модели
Важной особенностью системы 1 С: Предприятие являет-
ся то, что для описания структуры прикладного решения
разработчик использует не произвольные, а строго опре-
деленные объекты метаданных.
Платформа 1С:Предприятия содержит ограниченный
набор прототипов (шаблонов) объектов конфигурации.
Среди этих шаблонов есть, например, шаблон справоч-
ника, документа, регистра накопления, бизнес-процесса
и т. д.
Каждый такой шаблон (прототип) содержит определен-
ную базовую реализацию объекта конфигурации (рис. 1.3).
Когда разработчик создает новый объект конфигурации,
этот объект наследует базовую реализацию прототипа:
♦ платформа «знает», какие таблицы (состав полей, коли-
чество таблиц, их взаимная связь) нужно будет создать
в хранилище данных при сохранении конфигурации;
♦ сразу же добавляются новые типы встроенного языка,
позволяющие работать с данными создаваемого объек-
та, причем состав этих типов может быть разным для
различных шаблонов (прототипов);
Рис. 1.3. Состав прототипа (шаблона) объекта конфигурации
♦ сразу же создается набор прав, которые будут использо-
ваться для данного объекта, причем наборы прав также мо-
гут быть различными для разных шаблонов (прототипов),
поскольку различается их базовая функциональность;
♦ определяются стандартные действия, которые система
может выполнять с данными этого объекта конфигурации
и т. д.
Благодаря этому разработчик, не производя никаких до-
полнительных действий, тут же может запустить при-
кладное решение и работать с только что добавленным
объектом — базовая реализация объекта, унаследованная
от прототипа (шаблона), обеспечит выполнение всех не-
обходимых типовых действий.
Таким образом, несмотря на то, что каждое прикладное
решение обладает собственной «индивидуальностью»,
все они созданы по определенной модели, с использова-
нием объектов конфигурации, которые обладают одина-
ковой базовой реализацией. Такой подход значительно
упрощает модификацию прикладных решений разработ-
чиками, которые не участвовали в их создании.
Объектные и необъектные данные
В 1С:Предприятии принято разделять все прикладные
данные на те, которые имеют объектную природу (объ-
ектные данные), и на данные, не имеющие таковой при-
роды (необъектные данные).
Примерами объектных данных могут служить данные
справочников, документов. Необъектными данными яв-
ляются, например, данные регистров.
Подобное деление определяет два различных подхода
к работе с данными. Данные, имеющие объектную приро-
ду, хранятся в базе данных в виде объектов. Например,
объектами является элемент справочника или конкрет-
ный документ. Каждый объект «ценен» для системы уже
одним фактом своего существования и имеет уникаль-
ный идентификатор — ссылку. Могут измениться любые
данные объекта, но это будет все тот же объект. Удалив
объект, его нельзя создать заново. Даже если для нового
объекта будут установлены те же данные, это будет уже
другой объект с точки зрения 1 С: Предприятия, обладаю-
щий другим уникальным идентификатором.
Данные, имеющие необъектную природу, хранятся в базе
данных в виде записей. Каждая запись полностью описы-
вается значениями своих полей и не имеет какого-либо
уникального идентификатора. Поэтому для 1С:Предпри-
ятия собственно факт существования записи не важен.
Можно удалить запись, а затем создать новую, с такими же
значениями полей — состояние базы данных, с точки зре-
ния логики прикладного решения, от этого не изменится.
Подробнее об объектных и необъектных данных можно
прочитать в разделе «Объектные и необъектные данные»,
с. 36.
Три способа представления данных
Для всех прикладных данных (как объектных, так и не-
объектных) 1С:Предприятие поддерживает три способа
представления данных (рис. 1.4):
♦ хранение в базе данных;
♦ представление во встроенном языке;
♦ отображение в формате XML.
Рис. 1.4. Три способа представления данных
В базе данных информация хранится в виде объектов
базы данных или в виде отдельных записей (в зависимо-
сти от ее природы — объектной или необъектной).
Данные, хранимые в базе данных, могут быть считаны
в объекты встроенного языка для их просмотра или изме-
нения и записаны обратно в базу данных.
В то же время объекты встроенного языка могут быть
сериализованы в/из элементы/ов XML. Представление
данных в формате XML используется при обмене данны-
ми в распределенных информационных базах, а также
может использоваться при взаимодействии с другими
информационными системами.
Важно отметить, что все три способа представления данных
используют одну и ту же систему понятий, благодаря чему
от разработчика не требуется специальных усилий для пре-
образования данных из одного представления в другое.
Сквозная типизация
Важной особенностью работы с данными является то, что
в 1С:Предприятии реализована общая система типов встроен-
ного языка, полей баз данных и интерфейса. Иными слова-
ми, разработчик одинаковым образом определяет поля базы
данных, переменные встроенного языка, реквизиты форм,
и одинаковым образом работает с ними (рис. 1.5).
База данных
Встроенный язык
Система типов
Интерфейс
В результате разработчику не приходится заботиться
о преобразованиях между типами данных, поддерживае-
мыми той или иной СУБД, типами, поддерживаемыми
встроенным языком, и типами, используемыми для по-
строения интерфейсных решений.
Подробнее о типах данных, используемых системой
1С:Предприятие, можно прочитать в разделе «Система
типов», с. 47.
Рис. 1.5. Общая система типов
Поддержка составных типов данных
Важной особенностью модели данных 1С:Предприятия
является возможность использования реквизитов объ-
ектов метаданных, имеющих составной тип. Например,
врасходной накладной в качестве покупателя может быть
указано либо юридическое лицо из справочника органи-
заций, либо физическое лицо из справочника частных
лиц. Соответственно, при проектировании базы данных
разработчик может определить реквизит, который будет
хранить значение любого из этих типов.
Подробнее о составном типе можно прочитать в разделе
«Составной тип данных», с. 68.
Смешанный подход к манипулированию данными
1С:Предприятие обеспечивает два способа доступа к дан-
ным — объектный (для чтения и записи) и табличный
(только для чтения).
В объектной модели разработчик оперирует объектами
встроенного языка. В этой модели обращения к объекту,
например документу, происходят как к единому целому —
он полностью загружается в память, вместе с вложенными
таблицами, к которым можно обращаться средствами
встроенного языка как к коллекциям записей и т. д.
При манипулировании данными в объектной модели
обеспечивается сохранение целостности объектов, кэши-
рование объектов, вызов соответствующих обработчиков
событий и т. д.
В табличной модели все множество объектов того или
иного класса представляется как совокупность связанных
между собой таблиц, к которым можно обращаться при
помощи запросов — как к отдельной таблице, так и к не-
скольким таблицам во взаимосвязи.
В этом случае разработчик получает доступ к данным
сразу нескольких объектов, что очень удобно для анализа
больших объемов данных, например при создании отче-
тов. Однако в силу того, что данные, выбираемые таким
способом, содержат не все, а лишь некоторые реквизиты
анализируемых объектов, табличный способ доступа не
позволяет изменять эти данные.
Сочетание табличного и объектного доступа к данным по-
зволяет, с одной стороны, сделать разработку прикладных
решений простой и наглядной, а с другой стороны — полу-
чать сколь угодно сложные выборки данных и использо-
вать возможности агрегирования полученных данных.
Встроенныйязык
Встроенный язык имеет много общих черт с другими
языками, такими как Pascal, Java Script, Basic, что облег-
чает его освоение начинающими разработчиками. Однако
он не является прямым аналогом какого-либо из перечис-
ленных языков.
Вот лишь некоторые, наиболее значимые особенности
встроенного языка:
♦ мягкая типизация (тип переменной определяется ти-
пом значения, которое она содержит, и может изме-
няться в процессе работы);
♦ отсутствие программного описания прикладных типов
(они создаются при добавлении объектов метаданных);
♦ не требуется предварительное описание процедур/функ-
ций, если их вызов выполняется раньше их описания;
♦ событийная ориентированность встроенного языка;
♦ поддерживается обработка исключительных ситуаций;
♦ все операторы имеют как русское, так и английское на-
писание, которое можно использовать одновременно;
♦ используется интерпретатор с предварительной ком-
пиляцией (перед исполнением модули, содержащие
текст на встроенном языке, преобразуются во внутрен-
ний код);
♦ кэширование скомпилированных модулей в памяти.
Язык запросов
Язык запросов основан на SQL, но при этом содержит
значительное количество расширений, ориентированных
на отражение специфики финансово-экономических за-
дач и на максимальное сокращение усилий по разработке
прикладных решений.
Важной особенностью языка запросов является то, что он
предоставляет доступ к данным только на чтение и ис-
пользует те же типы данных, что и встроенный язык.
Можно перечислить наиболее существенные возможно-
сти, реализуемые языком запросов:
♦ обращение к подчиненным полям через точку. Если поля
какой-либо таблицы имеют ссылочный тип (хранят
ссылки на объекты другой таблицы), разработчик мо-
жет в тексте запроса ссылаться на них через «.», при
этом количество уровней вложенности таких ссылок
система не ограничивает;
♦ обращение к вложенным таблицам (например, табличным
частям документов и элементов справочников). К вло-
женным табличным частям можно обращаться и как к от-
дельным таблицам, и как к целым полям одной таблицы;
♦ автоматическое упорядочивание. Режим автоматиче-
ского упорядочивания позволяет выводить информа-
цию в наиболее правильном («естественном») порядке;
♦ многомерное и многоуровневое формирование итогов. Итоги
и подитоги формируются с учетом группировки и иерар-
хии, обход уровней может выполняться в произвольном
порядке с подведением подитогов, обеспечивается кор-
ректное построение итогов по временным измерениям;
♦ поддержка виртуальных таблиц. Виртуальные таблицы,
предоставляемые системой, позволяют получить прак-
тически готовые данные для большинства прикладных
решений без необходимости составления сложных за-
просов. Например, такая виртуальная таблица может
предоставить данные по остаткам товаров в разрезе пе-
риодов на какой-то момент времени. При этом виртуаль-
ные таблицы максимально используют хранимую ин-
формацию, например ранее рассчитанные итоги и т. д;
♦ стандартные SQL-операции. В языке запросов поддер-
живаются стандартные для SQL операции, такие, как
объединение (Union), соединение (Join) и т. д.
Прикладные решения, независимые
от используемого хранилища данных
Платформа изолирует разработчика от понятий и подроб-
ностей более низкоуровневых технологий. При создании
прикладных решений разработчик 1С:Предприятия не об-
ращается к базе данных напрямую. Непосредственно он ра-
ботает с платформой Ю.Предприятия. При этом он может:
♦ описывать структуры данных в конфигураторе;
♦ манипулировать данными с помощью объектов встро-
енного языка;
♦ составлять запросы к данным, используя язык запро-
сов.
Платформа 1 С: Предприятия обеспечивает операции ис-
полнения запросов, описания структур данных и манипу-
лирования данными, транслируя их в соответствующие
команды. Это могут быть команды SQL Server в случае
клиент-серверного варианта работы, или команды собст-
венной СУБД для файлового варианта работы.
Файловый и клиент-серверный варианты работы
1С:Предприятие может работать в двух вариантах:
♦ файловый;
♦ клиент-серверный.
И в том и в другом варианте все прикладные решения ра-
ботают полностью идентично, что позволяет выбирать
один или другой вариант работы без изменения сущест-
вующего прикладного решения.
Файловый вариант работы рассчитан на персональную
работу одного пользователя или работу небольшого ко-
личества пользователей в локальной сети. В этом вариан-
те все данные информационной базы (конфигурация,
база данных, административная информация) располага-
ются в одном файле (рис. 1.6).
Рис. 1.6. Файловый вариант работы
Такой вариант работы обеспечивает легкость установки
и эксплуатации прикладного решения. При этом для ра-
боты с информационной базой не требуются дополни-
тельные программные средства, достаточно иметь опера-
ционную систему и ЮПредприятие.
Клиент-серверный вариант предназначен для использо-
вания в рабочих группах или в масштабе предприятия.
Он реализован на основе трехуровневой архитектуры
«клиент-сервер» (рис. 1.7).
Рис. 1.7. Клиент-серверный вариант работы
На одном из компьютеров работает сервер ЮПредпри-
ятия. Программа, работающая у пользователя, взаимо-
действует с сервером 1 С:Предприятия, а сервер при необ-
ходимости обращается к базе данных SQL Server. При
этом физически сервер Ю.Предприятия и SQL Server мо-
гут располагаться как на одном компьютере, так и на раз-
ных. Это позволяет администратору при необходимости
распределять нагрузку между серверами.
Подробнее о клиент-серверном варианте работы можно
прочитать в разделе «Клиент-серверный вариант рабо-
ты», с. 79.
Сервер 1С:Предприятия
Сервер 1С:Предприятия является приложением СОМ+,
которое преобразует запросы, поступающие от клиент-
ского приложения, в запросы на языке Transact SQL,
передает их SQL Server, получает от него результат вы-
полнения запроса, преобразует его и передает обратно
клиентскому приложению.
Кроме этого, на сервере 1С:Предприятия сосредоточено
выполнение различных общих функций платформы:
♦ чтение и сохранение конфигураций и настроек пользо-
вателя;
♦ операции над базой данных, включая ограничения дос-
тупа к данным;
♦ хранение значений параметров сеанса;
♦ ведение журнала регистрации;
♦ поддержка оперативной отметки времени;
♦ другие функции (управление объектными блокировка-
ми, идентификаторы и т. п.).
Сервер 1С:Предприятия является сервером без состоя-
ния (stateless), то есть он не хранит данные о сеансах и их
состоянии, а просто передает информацию.
Выполнение встроенного
языка на клиенте и сервере
По умолчанию встроенный язык исполняется всегда на
клиенте. Но при работе в клиент-серверном варианте раз-
работчик может организовать выполнение различных
процедур и функций общих модулей и модулей объектов
также и на сервере приложения. Для этого используются
свойства модулей и операторы препроцессора.
Передача выполнения встроенного языка на сервер
1С:Предприятия позволяет, например, сложные алгорит-
мы расчета выполнять не на клиентской машине, а на бо-
лее мощном сервере, что увеличивает общую производи-
тельность прикладного решения.
Высокоуровневая модель интерфейса
В платформу 1С:Предприятия включен целый ряд меха-
низмов, ориентированных на быструю разработку эрго-
номичного пользовательского интерфейса. В них реали-
зована собственная оконная модель, система форм, набор
элементов управления и т. д.
Использование информации
из метаданных
Интерфейсные механизмы 1 С: Предприятия широко ис-
пользуют информацию из метаданных для того, чтобы ав-
томатизировать процесс разработки интерфейса и умень-
шить необходимость детальной настройки, выполняемой
разработчиком.
Расширения форм
и элементов управления
ЮПредприятие использует механизм расширений форм
и элементов управления. Расширения содержат набор
свойств, методов и событий, которыми дополняется стан-
дартное поведение элементов управления и формы после
того, как они связываются с данными. В зависимости от
того, какой тип данных отображает элемент управления
или форма, платформа будет использовать то или иное
расширение.
Такой подход позволяет реализовывать индивидуальные
особенности поведения формы и элементов управления
при работе с различными типами данных.
Автоматическое
формирование
командного интерфейса
Наряду с возможностью явного указания команд, кото-
рые должны входить в состав командных панелей форм
и элементов управления, платформа поддерживает авто-
матическое формирование командного интерфейса. При
этом используется два вида информации. Во-первых, ис-
пользуются команды, характерные для данного элемента
управления или формы, а во-вторых, используются ко-
манды, определяемые тем расширением, которое исполь-
зуется совместно с элементом управления или формой.
Таким образом, командный интерфейс наряду с команда-
ми, общими для данного элемента управления или фор-
мы, содержит и индивидуальный набор команд, опреде-
ляемый конкретным типом данных, с которыми связан
элемент управления или форма.
Генерация форм
по умолчанию
Важной особенностью системы 1 С:Предприятие являет-
ся механизм форм по умолчанию. Этот механизм освобо-
ждает разработчика от необходимости создания всех воз-
можных форм для каждого из объектов прикладного
решения. Разработчику достаточно создать новый объект
прикладного решения, а система сама сгенерирует в нуж-
ные моменты работы пользователя необходимые формы
по умолчанию для работы с данными, содержащимися в
этом объекте. Таким образом, разработчику нужно созда-
вать собственные формы объектов прикладного решения
лишь в том случае, если они должны иметь отличия (дру-
гой дизайн или специфическое поведение) от форм, гене-
рируемых системой по умолчанию.
Собственная модель
оконной системы
Оконная система, используемая в ЮПредприятии, ори-
ентирована на обеспечение высокой эргономичности при
работе с прикладными решениями и содержит специаль-
ные возможности, не поддерживаемые классической Win-
dows-моделью.
Окна, используемые в прикладных решениях, могут иметь
несколько разных состояний, которые определяют пове-
дение этих окон:
♦ обычные окна;
♦ свободные окна;
♦ прикрепленные окна;
♦ прячущиеся окна;
♦ «склеенные» окна;
♦ сложенные окна с закладками.
Кроме этого, оконная система 1С:Предприятия предлага-
ет собственную схему максимизации обычных окон, ко-
торая заменяет собой стандартную для приложений Win-
dows схему. В 1 С:Предприятии максимизация одного
окна не влечет за собой максимизацию всех обычных окон.
Также в ЮПредприятии поддерживается специальный
режим отображения окна — режим рабочего стола. В этом
режиме открытое окно занимает все свободное простран-
ство главного окна приложения, не имеет заголовка окна
и не отображается в списке открытых окон. Такой режим
может быть использован для создания специализирован-
ных рабочих мест (например, рабочего места кассира).
Поддержка различных хранилищ данных
В различных вариантах работы (файловый или клиент-
серверный) ЮПредприятие использует различные хра-
нилища данных.
В файловом варианте работы все данные информацион-
ной базы хранятся в одном файле — !Cv8.1CD. Этот
файл имеет специальный формат, поддерживаемый сис-
темой ЮПредприятие.
В клиент-серверном варианте работы все данные хранят-
ся в базе данных SQL Server.
Бесспорным преимуществом файловой базы данных яв-
ляется простота ее использования и обслуживания, одна-
ко она не рассчитана на интенсивную конкурентную
работу большого числа пользователей и хранение значи-
тельных объемов данных.
В то же время использование базы данных SQL Server по-
зволяет обеспечить большую пропускную способность
системы, хранение значительных объемов данных и надеж-
ность использования. Оборотной стороной этих преиму-
ществ является более сложное, по сравнению с файловой
базой данных, обслуживание и необходимость использо-
вания дополнительного программного обеспечения (в ка-
честве сервера баз данных используется MS SQL Server).
Обновление прикладных решений
Одним из важных архитектурных решений ЮПредпри-
ятия является наличие механизмов обновления приклад-
ных решений. Эти механизмы обеспечивают синхрони-
зацию изменений, сделанных поставщиком прикладного
решения с изменениями, внесенными при внедрении на
конкретном предприятии. Они предоставляют мощные
функции сравнения и анализа изменений, а также средст-
ва управления их синхронизацией. Администратор или
разработчик может детально настроить синхронизацию
обновлений вплоть до отдельных объектов, отдельных
свойств и отдельных процедур модулей.
Например, если специалист, отвечающий за сопровожде-
ние прикладного решения на предприятии, отметит объ-
екты, которые намерен поддерживать самостоятельно,
они не будут в дальнейшем обновляться при установке
очередного обновления от поставщика. Если объекты не-
обходимо объединить, то для упрощения синхронизации
изменений можно настроить приоритеты такого объеди-
нения. В то же время если прикладное решение не изме-
нялось у клиента, то обновление может быть выполнено
в полностью автоматическом режиме.
Подробнее об этих механизмах можно прочитать в разде-
ле «Механизм поставки и поддержки прикладных реше-
ний», с. 652.
Интернационализация
Механизмы интернационализации, заложенные в техноло-
гическую платформу 1С:Предприятия, позволяют исполь-
зовать различные языки как при разработке прикладного
решения, так и при работе пользователей прикладного
решения. Кроме этого, на уровне технологической плат-
формы поддерживаются национальные стандарты пред-
ставления дат, чисел и т. д.
Благодаря этому в 1 С: Предприятии возможно создание
многоязычных прикладных решений, в которых различные
пользователи работают с одной и той же информацион-
ной базой, используя интерфейсы на различных языках.
Подробнее о многоязычных прикладных решениях мож-
но прочитать в разделе «Многоязычные прикладные ре-
шения», с. 764.
Глава 2. Функциональность ^Предприятия
Обзор функциональности прикладных решений
Значительная часть функциональности прикладных ре-
шений, создаваемых на платформе 1С:Предприятие, оп-
ределяется теми возможностями, которые содержит базо-
вая реализация используемых объектов конфигурации.
Не претендуя на полное и глубокое изложение, рассмот-
рим лишь основные функциональные возможности неко-
торых объектов конфигурации. Многие из упомянутых
объектов и механизмов более подробно рассматриваются
в других разделах этой книги.
Кроме этого, рассмотрим также и некоторые «общие»
объекты технологической платформы, не реализующие
конкретной прикладной специфики, но обеспечивающие
важные функциональные возможности для прикладных
решений.
Справочники
Справочники описывают каталоги, содержимое которых
более или менее постоянно. Это может быть, например,
перечень выпускаемой продукции, список клиентов ком-
пании, перечень валют и т. д. Справочники обеспечивают
поддержку иерархических структур, позволяют относить
данные к отдельным объектам и их группам, предостав-
ляют ряд других сервисных возможностей.
Многоуровневая иерархия, поддерживаемая справочни-
ками, включается простой активизацией соответствую-
щего свойства в метаданных. При этом поддержка иерархии
распространяется сразу на все аспекты использования
прикладного объекта.
Например, прототип (шаблон) справочника обеспечивает
поддержку необходимых свойств и методов в объектной
модели манипулирования данными (определение уровня
объекта, контроль зацикливания иерархии и т. д.). В ин-
терфейсных механизмах реализуется представление дан-
ных в виде иерархического списка или дерева с навигаци-
ей по уровням и интерактивным изменением иерархии.
В механизмах отчетов обеспечивается формирование
иерархических документов такого рода и получение мно-
гоуровневой иерархии итогов в любых отчетах, в которых
объекты этого типа выступают в качестве параметров для
группировки.
Подробнее об использовании справочников можно про-
читать в главе 6 «Хранение информации», с. 91.
Документы
Документы отражают в системе события, происходящие
в жизни предприятия: поступление материалов, перечис-
ление денег через банк, прием сотрудника на работу и т. д.
Прототип (шаблон) документа обеспечивает их отра-
жение в различных учетных механизмах, поддерживает
контроль последовательности обработки событий, реали-
зует сквозную нумерацию объектов разного типа и т. д.
Одним из важных функциональных механизмов системы
является механизм проведения документов. Он предлага-
ет разработчику стандартную модель организации связи
между информацией о событиях, происходящих на пред-
приятии, и различными учетными механизмами. Любая
вводимая пользователем в виде документов информация
может отражаться в любых учетных механизмах (плани-
ровании, управленческом учете, бухгалтерском учете и т. д.).
Разработчик должен только указать в свойствах метадан-
ных связь между документами и учетными механизмами,
а также описать алгоритм проведения документа.
Все необходимые действия по проведению и отмене про-
ведения система будет выполнять автоматически. При
этом системой предоставляются дополнительные возмож-
ности, такие как поддержка отражения событий в реальном
времени, поддержка восстановления последовательности
отражения событий, происходящих на предприятии, при
изменении их задним числом и т. д. В результате предо-
ставляется единая модель связи исходных данных и учет-
ных механизмов, которая не просто облегчает разработку,
но и обеспечивает единообразное предсказуемое поведе-
ние всех прикладных решений, что существенно облегча-
ет их освоение и поддержку.
Подробнее об использовании документов можно прочи-
тать в главе 7 «Документы и последовательности», с. 136.
Механизм характеристик
Механизм описания характеристик позволяет организо-
вать хранение свойств объектов (справочников, докумен-
тов и т. д.), которые еще не известны на момент разработ-
ки прикладного решения. Таким образом, например, для
номенклатуры пользователь сможет самостоятельно вво-
дить новые свойства: цвет, размер, габариты, мощность
и т. д. Для каждой группы номенклатуры может быть соз-
дан свой набор свойств: для холодильников — объем мо-
розильной камеры, число компрессоров, уровень шума;
для компьютеров — объем оперативной памяти, объем
жесткого диска; для одежды — размер, рост, цвет.
В дальнейшем на основе этих характеристик можно стро-
ить отчеты, анализировать объемы продаж, получать дру-
гую информацию для принятия решений.
Подробнее об использовании механизма характеристик
можно прочитать в разделе «Хранение дополнительных
характеристик произвольного типа. Использование пла-
на видов характеристик», с. 131.
Механизм сведений
Механизм хранения сведений, реализованный в платфор-
ме 1С:Предприятия, позволяет хранить в прикладном ре-
шении произвольные данные в разрезе нескольких изме-
рений. Например, можно хранить курсы валют в разрезе
валют или цены предприятия в разрезе номенклатуры
и типа цен.
Кроме этого может быть задана различная периодичность
хранения сведений, что позволяет хранить не только
сами значения, но и историю их изменения.
Подробнее об использовании механизма сведений можно
прочитать в разделе «Хранение информации в регистрах
сведений», с. 107.
Механизм учета движения
средств
Механизм учета движения средств (финансов, товаров,
материалов и т. д.) позволяет автоматизировать такие на-
правления, как складской учет, взаиморасчеты, планиро-
вание. Основу этого механизма составляют регистры на-
копления.
Регистр накопления образует многомерную систему из-
мерений и позволяет «накапливать» числовые данные в
разрезе нескольких измерений. Например, в таком реги-
стре можно накапливать информацию об остатках това-
ров в разрезе номенклатуры и склада или информацию об
объемах продаж в разрезе номенклатуры и подразделе-
ния компании.
Подробнее об использовании механизма учета движения
средств можно прочитать в главе 8 «Реализация задач
учета движения средств», с. 177.
Механизм бухгалтерского
учета
Механизмы бухгалтерского учета позволяют реализовать
систему двойной записи бухгалтерского учета. Они не на-
вязывают разработчику собственно принципов ведения
бухгалтерского учета и позволяют создавать модели уче-
та, применимые как в России, так и в других странах.
Можно перечислить следующие основные возможности,
реализуемые механизмами бухгалтерского учета:
♦ ведение многоуровневых планов счетов с произвольной
иерархией, в которых поддерживается фиксированная
или переменная разрядность кодов счетов;
♦ ведение аналитического учета в нескольких разрезах
и уровнях;
♦ ведение учета одновременно по нескольким планам
счетов;
♦ ведение консолидированного учета по нескольким
юридическим лицам;
♦ возможность указания для отдельных разрезов анали-
тики произвольного числа видов учета, таких как коли-
чественный, суммовой, валютный учет и т. д.
Подробнее об использовании механизма бухгалтерского
учета можно прочитать в главе 9 «Реализация задач бух-
галтерского учета», с. 240.
Механизм сложных
периодических расчетов
Механизм сложных периодических расчетов позволяет
реализовывать различные модели расчета заработной пла-
ты. Работа механизма основана на двух составляющих.
С одной стороны механизм сложных периодических рас-
четов содержит средства для описания различных видов
расчета, которые будут использоваться в прикладном ре-
шении. Например, это могут быть такие виды расчета, как
оклад, алименты, штраф и т. д. Помимо собственно описа-
ния этих видов расчета, существует возможность задать
правила, по которым одни виды расчета будут влиять на
другие виды расчета.
С другой стороны, этот механизм предоставляет возмож-
ность хранения промежуточных данных, которые исполь-
зуются для выполнения расчетов, и конечных результа-
тов расчетов.
Расчет зарплаты является наиболее типичным примене-
нием данного механизма, но сам механизм не имеет ори-
ентации именно на эту задачу и успешно используется
для решения других задач, требующих описания перио-
дических расчетов со сложными взаимосвязями, напри-
мер расчета дивидендов, стоимости коммунальных услуг
И т. д.
Подробнее об использовании механизма сложных перио-
дических расчетов можно прочитать в главе 10 «Реализа-
ция сложных периодических расчетов», с. 315.
Механизм бизнес-процессов
Механизм бизнес-процессов позволяет описывать, созда-
вать и управлять выполнением бизнес-процессов в при-
кладных решениях. Целью этого механизма является
автоматизация цепочек связанных операций, направлен-
ных на достижение общей цели, обычно в контексте орга-
низационной структуры, определяющей функциональные
роли и связи.
Этот механизм включает средства для описания в при-
кладном решении схем бизнес-процессов и их ролевой
маршрутизации, для формирования заданий, выполняю-
щихся в каждой точке маршрута, для управления бизнес-
процессом и организации его связи с другими функция-
ми прикладного решения.
Важно отметить, что данный механизм предлагает гото-
вую стратегию автоматизации совместной деятельности
работников предприятия. Для описания простейших биз-
нес-процессов достаточно визуального задания схемы
маршрута и указания условий ветвления в их узловых
точках. Все остальные действия выполняются системой
автоматически. При реализации сложных бизнес-процес-
сов усилия разработчика требуются в основном для тес-
ной их увязки с функциями прикладного решения.
Подробнее об использовании механизма бизнес-процес-
сов можно прочитать в главе 11 «Механизм бизнес-про-
цессов», с. 363.
Механизм анализа данных
и прогнозирования
Механизм анализа данных и прогнозирования позволяет
реализовывать в прикладных решениях инструменты для
выявления закономерностей, которые обычно скрывают-
ся за большими объемами информации.
Например, проанализировав данные о продажах товаров,
можно выявить группы товаров, которые обычно покупа-
ются вместе, и при очередной покупке рекомендовать кли-
енту дополнительные товары, исходя из найденных зако-
номерностей и тех товаров, которые клиент уже выбрал.
Этот механизм поддерживает выполнение нескольких
типов анализа данных, таких как общая статистика, по-
иск ассоциаций, дерево решений, поиск последовательно-
стей, кластерный анализ.
Подробнее об использовании механизма анализа данных
и прогнозирования можно прочитать в главе 12 «Исполь-
зование механизма анализа данных и прогнозирования»,
с. 398.
Интеллектуальные
механизмы подготовки
отчетов
Важным механизмом системы, обеспечивающим значи-
тельную часть функциональности создания и использо-
вания отчетов, является построитель отчета. Он предо-
ставляет возможность динамического создания отчета
как программными, так и интерактивными средствами.
В основе работы построителя отчета лежит текст запроса,
исходя из которого построитель отчета предоставля-
ет пользователю возможность интерактивной настройки
всех основных параметров, содержащихся в тексте запро-
са. Например, пользователь может выбрать все или толь-
ко некоторые исходные поля, может включать в состав
полей поля «через точку» от данного поля, может нало-
жить ограничения на значения некоторых полей и т. д.
Полученные в результате выполнения этого запроса, дан-
ные выводятся в табличный документ с использованием
всех его интерактивных возможностей: сводных таблиц,
диаграмм, сводных диаграмм и т. д.
Для формирования табличного документа построитель
отчета использует макет, генерируемый автоматически.
Средствами встроенного языка этот макет может быть -
изменен и оформлен одним из доступных вариантов
оформления. Также разработчик может использовать
собственный макет, на основании которого будет форми-
роваться итоговый документ.
Также при формировании табличного документа воз-
можно использование условного оформления. Этот меха-
низм позволяет оформлять отчет динамически, в зависи-
мости от значений, выводимых в отчет. Для настройки
доступны цвет текста, цвет фона, шрифт, формат значе-
ния, выделение отрицательных чисел и другие оформи-
тельские свойства.
Разработчик может настроить механизм расшифровки
итогового табличного документа таким образом, что для
получения детальных сведений по какому-либо результату
отчета будет вызываться этот же или другой построитель
отчета с нужными параметрами запроса.
Таким образом, построитель отчета позволяет не только
формировать отдельные отчеты, но и связать воедино це-
лый набор отчетов, обеспечивая получение необходимой
информации во всех требуемых разрезах. Это дает поль-
зователю возможность получать любые аналитические
данные без изменения прикладного решения и привлече-
ния разработчиков.
Подробнее о средствах построения отчетов можно прочи-
тать в главе 13 «Средства построения отчетов», с. 413.
Табличный документ,
географическая схема,
диаграммы, диаграмма Ганта
Технологическая платформа 1С:Предприятия содержит
целый ряд объектов, которые позволяют представлять
итоговую информацию в удобном для пользователя виде,
обеспечивая при этом, в большей или меньшей степени,
интерактивное взаимодействие.
Одним из мощных средств презентации любой информа-
ции и вывода ее на печать является табличный документ.
Он обеспечивает не только эффективную подготовку пе-
чатных документов, но и просмотр их на экране в удоб-
ном для пользователя виде. Перечислим основные воз-
можности табличного документа:
♦ оформление отчета, включая тип и размер шрифта,
цвет текста и фона, тип и цвет рамки, рисунки и т. д.;
♦ использование группировок (как вертикальных, так и
горизонтальных), с помощью которых можно отражать
промежуточные итоги;
♦ поддержка механизма расшифровок, когда при щелчке
на строке или ячейке отчета формируется более деталь-
ный отчет или открывается объект базы данных;
♦ использование примечаний, содержащих дополнитель-
ную информацию о данных, расположенных в ячейке
или области документа;
♦ поддержка сводных таблиц, которые позволяют отобра-
зить многомерные данные в виде плоской таблицы
с вложенными заголовками;
♦ поддержка диаграмм различного вида для наглядного
представления экономической информации в графиче-
ском виде;
♦ возможность сохранения табличного документа в раз-
личных форматах и др.
Для представления итоговых данных в разрезе их гео-
графического положения в 1С:Предприятии использу-
ется специальный объект — географическая схема. Она
позволяет создавать отчеты, иллюстрирующие, напри-
мер, объемы продаж тех или иных товаров в различных
регионах страны. Также географическая схема может
быть использована просто для отображения тех или
иных географических данных, например схемы проезда
к офису или маршрута движения транспортного сред-
ства.
Еще одним объектом, используемым для графического
представления данных, являются диаграммы. Платформа
1С:Предприятия поддерживает работу с различными ви-
дами диаграмм, в том числе:
♦ график (обычный, по шагам, с областями и т. д.);
♦ гистограмма (обычная, с накоплением, объемная и т. д.);
♦ круговая (обычная и объемная);
♦ биржевая (обычная и «свеча»);
♦ изометрическая (обычная, непрерывная и т. д.);
♦ поверхностная (каркасная, выпуклая, вогнутая поверх-
ность, сотовая и др.);
♦ радарная (с областями, с накоплением, нормированная
и др.);
♦ измерительная диаграмма.
Диаграммы акцентируют внимание пользователя на ди-
намике изменения данных и помогают быстро произ-
водить относительное сравнение данных. Кроме этого,
специализированные виды диаграмм могут отражать за-
кономерности, обычно скрытые за большими объемами
данных.
Одним из специальных видов диаграмм, поддерживае-
мых платформой, является диаграмма Ганта. Она содер-
жит набор интервалов, расположенных на оси времени,
и отражает использование объектами (точками) ресурсов
(серий). Этот вид диаграммы широко используется для
визуализации хода выполнения задач, планирования ре-
сурсов, графика рабочего времени и других данных, кото-
рые представляются не конкретными числовыми значе-
ниями, а набором временных интервалов.
Диаграмма Ганта имеет гибкую структуру данных. Как
точки, так и серии представляют собой иерархические
коллекции, что позволяет, например, представить проект
как набор связанных, иерархических задач.
Поддерживается возможность установки связей между
различными интервалами диаграммы, таким образом, окон-
чание одного интервала может быть связано с началом
следующего интервала диаграммы. Также поддерживает-
ся возможность интерактивного перемещения и растяги-
вания интервалов диаграммы в режиме 1С:Предприятие
при помощи мыши.
Средства интеграции
и механизмы обмена
данными
Система 1С:Предприятие является открытой системой
благодаря тому, что технологическая платформа предо-
ставляет возможности для интеграции практически с лю-
быми внешними программами и оборудованием на осно-
ве общепризнанных открытых стандартов и протоколов
передачи данных.
В системе 1С:Предприятие имеется целый набор средств,
с помощью которых можно:
♦ создавать, обрабатывать и обмениваться данными раз-
личных форматов;
♦ осуществлять доступ ко всем объектам системы 1С:Пред-
приятие, реализующим ее функциональные возможно-
сти;
♦ поддерживать различные протоколы обмена;
♦ поддерживать стандарты взаимодействия с другими
подсистемами;
♦ разрабатывать собственные интернет-решения.
Механизмы обмена данными позволяют создавать рас-
пределенные информационные системы на основе:
♦ 1С:Предприятия 8.0;
♦ других информационных систем, не основанных на
1С:Предприятии 8.0.
Обмен данными в системе 1 С.'Предприятие реализуется
благодаря использованию ряда средств технологической
платформы, которые разработчик может применять как
по отдельности, так и в различных комбинациях, в зави-
симости от конкретной решаемой задачи. Такой подход
позволяет обеспечить гибкость механизмов обмена и их
«настраиваемость» на решение как можно большего кру-
га задач.
Подробнее о средствах интеграции можно прочитать
в главе 14 «Интеграция с другими информационными
системами», с. 528. Механизмы обмена данными более
подробно описаны в главе 15 «Создание распределенных
информационных систем», с. 571.
Web-расширение
Одним из средств интеграции, позволяющим расширить
сферу применения 1С:Предприятия, является Web-рас-
ширение. Данный программный продукт позволяет орга-
низовать доступ через веб-интерфейс к функциональности
прикладных решений новых категорий пользователей,
в том числе и тех, у которых на компьютерах не установ-
лена платформа 1С:Предприятия. Это могут быть мо-
бильные пользователи, сотрудники территориально уда-
ленных подразделений, посетители интернет-магазинов
и веб-порталов.
Web-расширение позволяет встраивать доступ к данным
1С:Предприятия в существующие веб-сайты и веб-при-
ложения и создавать готовые веб-приложения и веб-
сервисы, использующие информационную базу 1 (^Пред-
приятия.
Механизмы Web-расширения могут использоваться для
решения задач нескольких уровней, в различных комби-
нациях с другими системами:
♦ реализация веб-доступа к информационной базе
1 С:Предприятия;
♦ встраивание прикладной функциональности 1 С:Пред-
приятия в существующие сайты;
♦ организация доступа к данным 1С:Предприятия для ре-
шения других задач;
♦ организация программного доступа к 1С:Предприятию
из других систем.
Подробнее о Web-расширении можно прочитать в главе 16
«Web-расширение», с. 606.
Обзор функциональности средств разработки
Состав средств разработки достаточно широк и разнооб-
разен. Это позволяет выполнять полный цикл действий,
начиная от создания конфигурации и заканчивая получе-
нием тиражируемого дистрибутива прикладного реше-
ния, не прибегая к помощи каких-либо продуктов сторон-
них производителей (рис. 2.1).
Набор прототипов Средства Средства
объектов метаданных разработки .........
-► Метаданные
Справочная система
Поставка и
поддержка
v Создание
Констрикторы 4- -р оистрив>гввот
-> Окна конфигурации
Смнтакс-помощник
Редакторы
Отладчик
Глобальный поиск и
замена
Шаблоны текстов
Сравнение/объедынение
конфигураций
Групповая разработка '
Рис. 2.1. Состав средств разработки
Проверка
конфигурации
Выгрузка/загрузка
Файлов конфигурации
Внешние обработки —►
_ Редактирование
’ текстов интерфейсов
Перечислим основные средства, используемые при разра-
ботке прикладных решений 1 С: Предприятия.
Метаданные и инструменты
для их редактирования
Прежде всего, это, конечно же, сами метаданные и инст-
рументы для их редактирования — окно конфигурации,
окно редактирования объекта конфигурации и панель
свойств. С помощью этих инструментов выполняется до-
бавление, удаление объектов конфигурации, изменение их
свойств, установка связей с другими объектами конфигу-
рации и пр. Окно редактирования объекта конфигурации
позволяет выполнять, в числе прочего, последовательную
установку свойств объекта, что удобно (особенно для на-
чинающих разработчиков), так как позволяет задать в
первую очередь те свойства объекта, которые могут опре-
делять наличие или отсутствие других свойств объекта.
Палитра свойств также предоставляет возможность из-
менять свойства объекта и получать быстрый доступ к
информации, связанной с данным объектом. Палитра
свойств удобна в использовании для опытных разработ-
чиков, а также тогда, когда необходимо просмотреть или
изменить одноименные свойства у различных объектов
конфигурации.
Конструкторы и редакторы
В состав средств разработки входит довольно большое
количество конструкторов и редакторов. Конструкторы
позволяют автоматизировать и облегчить создание неко-
торых часто используемых элементов прикладного реше-
ния, модификация которых может быть формализована.
Как правило, эти элементы прикладного решения могут
быть созданы и без использования конструктора, но кон-
структор позволяет сделать это быстрее и легче.
Например, текст запроса может быть полностью написан
самим разработчиком. Для этого разработчик должен хо-
рошо знать синтаксис языка запросов и понимать назна-
чение различных предложений языка запросов. В то же
время текст запроса можно создать с помощью конструк-
тора запросов. При этом используется визуальное конст-
руирование запроса, когда с помощью мыши нужно вы-
брать и перетащить нужные таблицы, поля, установить
связи между ними и т. д. После нажатия кнопки ОК конст-
руктор запроса создаст синтаксически верный текст за-
проса.
Можно перечислить, например, следующие конструкто-
ры, присутствующие в интерфейсе разработки и админи-
стрирования:
♦ конструктор запросов;
♦ конструктор выходной формы;
♦ конструктор движений регистров;
♦ конструктор печати;
♦ конструктор ввода на основании;
♦ конструктор форм объектов конфигурации;
♦ конструктор меню;
♦ конструктор форматной строки.
Редакторы позволяют создавать и изменять элементы
прикладного решения, модификацию которых затрудни-
тельно формализовать или для которых подобная форма
лизация не имеет практического смысла.
Например, конструктор форм объектов конфигурации
позволяет создать некоторую типовую форму объекта,
разместить на ней необходимые поля, назначить источни-
ки данных и т. д. Этот процесс легко формализуется и по-
тому может быть выполнен конструктором. Однако даль-
нейшее редактирование формы, как правило, является
процессом творческим и формализации не поддается. По-
этому платформа предоставляет в распоряжение разра-
ботчика редактор форм, с помощью которого он придает
форме нужный вид, располагает дополнительные элемен-
ты управления, настраивает, при необходимости, привязки
и т. д. в соответствии с конкретным назначением формы.
Можно перечислить, например, следующие редакторы,
реализованные в интерфейсе разработки и администри-
рования:
♦ редактор форм;
♦ редактор текстов и модулей;
♦ редактор табличных документов;
♦ HTML-редактор;
♦ редактор интерфейсов;
♦ редактор картинок.
Синтакс-помощник
Синтакс-помощник позволяет получать справку по ис-
пользованию конструкций встроенного языка, свойствам,
методам и событиям объектов встроенного языка (как по-
ставляемых непосредственно платформой, так и созда-
ваемых наследованием от прототипов объектов конфигу-
рации), а также справку по составу таблиц, являющихся
источниками данных в языке запросов. Синтакс-помощ-
ник может быть использован как самостоятельно, так и в
связке с редактором текстов и модулей. Находясь в тек-
сте модуля, можно, используя сочетание клавиш, перейти
к описанию соответствующего свойства, метода, функции
и т. д. в синтакс-помощнике, а конструкции встроенного
языка, описанные в синтакс-помощнике, в свою очередь,
могут быть перенесены в текст модуля с помощью мыши.
Отладчик и режим замера
производительности
Среди средств разработки, используемых наиболее часто
и интенсивно можно отметить также отладчик и режим
замера производительности. Отладчик позволяет проана-
лизировать работу прикладного решения, выполнить ос-
тановку в указанном месте кода на встроенном языке,
просмотреть значения переменных, состояние используе-
мых объектов в определенные моменты работы, вы-
полнить фрагмент кода «по шагам» и т. д. Режим замера
производительности используется для того, чтобы про-
анализировать эффективность выполнения участка кода,
узнать время, затраченное на выполнение каждой из
строк этого участка кода (как абсолютное, так и относи-
тельное, в процентах к общему времени выполнения все-
го участка). Таким образом, можно определить операто-
ры, выполнение которых занимает основное количество
времени, и попытаться оптимизировать используемый
алгоритм. Подробнее об использовании режима замера
производительности можно прочитать в разделе «Режим
замера производительности 1С:Предприятия», с. 736.
Проверка конфигурации
Режим проверки конфигурации позволяет выявить ошиб-
ки, которые не являются критичными для функциониро-
вания прикладного решения в принципе, но наличие ко-
торых может существенно снизить скорость работы при-
кладного решения или даже привести к возникновению
ошибок при р’аботе в некоторых специальных режимах.
Использование этого режима не является обязательным,
но может оказаться очень полезным, например, для про-
верки конфигурации перед поставкой заказчику, перед
выпуском тиражного решения, для проверки после мас-
сированного удаления объектов или после объединения
конфигураций.
Сравнение/объединение
конфигураций
Механизм сравнения/объединения конфигураций позво-
ляет выполнять, например, детальный анализ отличий
между разными версиями одного и того же прикладного
решения. Также с помощью этого механизма можно вы-
полнять переход от одной версии прикладного решения к
другой версии того же самого или другого прикладного
решения. При этом разработчик имеет возможность за-
дать различные правила объединения для различных эле-
ментов прикладного решения, указывая, какой элемент
должен быть взят из новой версии, какой оставлен без из-
менений, а какие элементы, например, должны быть объ-
единены и содержать как старый, так и новый варианты.
После нажатия кнопки Выполнить платформа автоматиче-
ски выполнит объединение в соответствии с правила-
ми, заданными разработчиком. Использование механизма
сравнения/объединения конфигураций позволяет избе-
жать ручной модификации конфигурации (и связанного
с этим большого количества ошибок), при переносе изме-
нений из одной конфигурации в другую, а также значи-
тельно ускорить этот процесс.
Редактирование текстов
интерфейса
Платформа 1С:Предприятия позволяет создавать много-
язычные прикладные решения, в которых каждый из
пользователей может работать с интерфейсом на своем
родном языке. Для того чтобы помочь разработчику при
создании многоязычных прикладных решений, в состав
средств разработки входит механизм редактирования
текстов интерфейса. Этот механизм позволяет находить и
группировать все вхождения той или иной строки в кон-
фигурации и «в одно нажатие» заменить его или доба-
вить аналог этой строки на другом языке. Кроме этого,
механизм позволяет переносить строки на разных языках
из одного прикладного решения в другое. Подробнее о
механизме редактирования текстов интерфейса можно
прочитать в разделе «Редактирование текстов интерфей-
са», с. 772.
Групповая разработка
прикладных решений
Механизм групповой разработки позволяет вести и вер-
сионировать разработку прикладных решений группе
разработчиков, внося изменения в конфигурацию одно-
временно, по мере выполнения каждым из них своего
участка работы. Подробнее о механизме групповой разра-
ботки можно прочитать в разделе «Групповая разработка
прикладных решений», с. 690.
Поставка и поддержка
прикладных решений
Механизм поставки и поддержки прикладных решений
служит для автоматизации процесса поддержки разра-
ботчиками прикладного решения, используемого пользо-
вателем. Задача поставки и поддержки заключается в соз-
дании новых версий прикладного решения и обновления
той версии прикладного решения, которая находится
у пользователей.
Подробнее о механизме поставки и поддержки можно
прочитать в разделе «Механизм поставки и поддержки
прикладных решений», с. 652.
Создание дистрибутивов
Механизм создания дистрибутивов позволяет разработчи-
ку создать комплект поставки — набор файлов, предназна-
ченных для установки на компьютере пользователя. Ком-
плект поставки включает в себя программу установки
Setup.exe и набор файлов поставки, сжатых в архив. Для
установки прикладного решения пользователю достаточно
запустить на своем компьютере программу установки, вхо-
дящую в комплект поставки, и следовать инструкциям, по-
являющимся на экране. Программа установки имеет стан-
дартный интерфейс и помогает пользователю установить
все компоненты прикладного решения. Подробнее о меха-
низме создания дистрибутивов можно прочитать в разделе
«Механизм создания комплектов поставки», с. 668.
Обзор функциональности средств администрирования
Средства администрирования, входящие в состав ин-
терфейса разработки и администрирования, позволяют
управлять составом пользователей информационной
базы, осуществлять регламентные операции по ее обслу-
живанию и выполнять другие административные дейст-
вия (рис. 2.2).
Рис. 2.2. Состав средств администрирования
Перечислим основные средства, используемые для ад-
министрирования информационных баз 1С:Предпри-
ятия.
Список пользователей
Платформа 1 С: Предприятия позволяет вести список
пользователей, которым разрешена работа с данной ин-
формационной базой. Этот список не является частью
прикладного решения, а создается отдельно, в каждой
конкретной организации, в которой используется при-
кладное решение. Существует возможность добавлять,
удалять пользователей системы, назначать им различные
виды аутентификации, набор ролей, доступных в систе-
ме, основной интерфейс, язык пользователя и пр.
Система прав доступа
Для каждого конкретного прикладного решения система
1 С: Предприятие позволяет описать наборы прав, соот-
ветствующие должностям пользователей или виду дея-
тельности. Структура прав определяется конкретным при-
кладным решением.
Все права, поддерживаемые системой 1С:Предприятие,
можно разделить на две большие группы: основные и ин-
терактивные. Основные права описывают действия, вы-
полняемые над элементами данных системы или над всей
системой в целом, и проверяются всегда, независимо от
способа обращения к данным. Интерактивные права опи-
сывают действия, которые могут быть выполнены поль-
зователем интерактивно. Соответственно проверяются
они только при выполнении интерактивных операций
стандартными способами, причем в клиент-серверном ва-
рианте все проверки прав (кроме интерактивных) выпол-
няются на сервере.
Ограничение прав на уровне
записей и полей
Среди действий над объектами, хранящимися в базе дан-
ных, есть действия, отвечающие за чтение или изменение
информации, хранящейся в базе данных. К таким дейст-
виям относятся:
♦ чтение — получение записей или их фрагментов из таб-
лицы базы данных;
♦ добавление — добавление новых записей без изменения
существующих;
♦ изменение — изменение существующих записей;
♦ удаление — удаление некоторых записей без внесения
изменений в оставшиеся.
Для этих действий могут быть заданы дополнительные
условия на данные (ограничение доступа к данным).
В этом случае над конкретным объектом, хранимым в
базе данных, может быть выполнено запрошенное дейст-
вие только в том случае, если ограничение доступа к дан-
ным для данных этого объекта принимает значение Истина.
Аналогичные условия могут быть заданы и для таблиц ба-
зы данных, не имеющих объектной природы (регистров).
Ограничение доступа к данным представляет собой усло-
вие, описанное на языке, который является подмножеством
языка запросов. Это условие применяется для каждой за-
писи таблицы базы данных, над которой выполняется
операция. При просмотре списков и формировании отчетов
существует возможность обеспечить отображение только
тех данных, доступ к которым пользователю разрешен.
Журнал регистрации
Для хранения информации о событиях, происходящих
в информационной базе, система 1С:Предприятие ведет
журнал регистрации. Администратор информационной
базы имеет возможность настроить уровень событий, ко-
торые будут отображаться в журнале регистрации (на-
пример, только ошибки или ошибки, предупреждения
и информация). Просмотр журнала регистрации может
быть выполнен с помощью специального фильтра, позво-
ляющего отбирать информацию по большому количеству
критериев. Также журнал регистрации может быть пол-
ностью или частично выгружен в формат XML для про-
граммного анализа. Подробнее об использовании журна-
ла регистрации можно прочитать в разделе «Журнал
регистрации 1С:Предприятия», с. 734.
Загрузка/выгрузка
информационной базы
Команды загрузки/выгрузки информационной базы по-
зволяют сохранить информационную базу в файл на дис-
ке, или загрузить информационную базу из файла. Эти
команды используются, например, для того, чтобы пере-
нести базу из файлового варианта в клиент-серверный
и обратно.
Консоль сервера
ЮПредприятия
Консоль сервера ЮПредприятия используется при ра-
боте в клиент-серверном варианте и позволяет выпол-
нять такие действия, как:
♦ мониторинг серверов 1 С:Предприятия;
♦ просмотр списка информационных баз;
♦ управление списком администраторов серверов ЮПред-
приятия;
♦ создание и удаление информационных баз;
♦ мониторинг соединений пользователей с информаци-
онными базами;
♦ отключение пользователей от информационной базы.
Консоль сервера ЮПредприятия реализована в виде
подключаемого модуля ММС (Microsoft Management
Console) и может быть использована на компьютерах,
на которых установлено соответствующее программное
обеспечение (для операционных систем Windows 2000/
XP/Server 2003 это программное обеспечение является
стандартным).
Глава 3. Использование встроенного языка
Введение
Как уже говорилось выше, прикладное решение 1 С: Пред-
приятия представляет собой определенную структуру
метаданных, которая исполняется технологической плат-
формой. В то же время технологическая платформа со-
держит в себе интерфейс разработки и администрирова-
ния, позволяющий создавать новые и модифицировать
существующие прикладные решения.
Разработка прикладного решения заключается, по боль-
шому счету, в двух основных действиях: визуальном кон-
струировании объектов конфигурации и описании специфи-
ческого поведения системы с использованием встроенного
языка и языка запросов.
Создание нового прикладного решения начинается с добав-
ления новой информационной базы в список баз 1 С:Пред-
приятия. При этом платформа создает некую «базовую»
структуру метаданных, которая уже представляет собой
работоспособное прикладное решение. В соответствии с
этой структурой метаданных платформа также создает
ряд информационных структур (таблиц), обеспечивающих
работу этой конфигурации и хранение данных. Информа-
ционные структуры создаются в том варианте работы, ко-
торый выбран пользователем (например, файловый или
клиент-серверный).
Таким образом, разработчик начинает создание приклад-
ного решения не «с нуля», а с некоторой «базовой» струк-
туры метаданных (пустой конфигурации), которую он
может изменять в соответствии со своими потребностями.
Следующим шагом в разработке прикладного решения
является, как правило, создание структур для хранения
данных. Отличительной особенностью разработки в сис-
теме ЮПредприятие является то, что платформа изоли-
рует разработчика от физических деталей хранения дан-
ных, предлагая более высокий уровень абстракции -
уровень объектов метаданных. Другими словами, разра-
ботчик добавляет в структуру метаданных нужные ему
объекты, определяет, например, какие реквизиты и таб-
личные части будет содержать тот или иной объект.
Платформа же анализирует изменения, выполняемые
разработчиком, и создает в информационной базе соот-
ветствующие информационные структуры, позволяющие
хранить и эффективно использовать данные. В результа-
те с точки зрения разработчика процесс создания при-
кладного решения в файловом варианте или в клиент-
серверном выглядит совершенно одинаково, так как он не
оперирует физическими таблицами базы данных, а имеет
дело с более абстрактными сущностями — объектами ме-
таданных. Таким образом, вся структура хранимых дан-
ных описывается средствами визуального конфигуриро-
вания и не может быть изменена в процессе работы
прикладного решения (в реальном режиме времени). Та-
кой подход позволяет платформе контролировать целост-
ность информационной базы и данных, которые в ней
хранятся. Платформе «известно» о назначении того или
иного объекта конфигурации, она «знает», в каких табли-
цах должны храниться данные этого объекта, и «обладает
информацией» о том, как эти данные должны взаимодей-
ствовать с данными других объектов конфигурации. Та-
ким образом, ограничивая разработчика в динамической
модификации структуры информационной базы, она
значительно облегчает задачу создания и модификации
прикладного решения, избавляя разработчика от необхо-
димости самостоятельно контролировать правильность
таблиц информационной базы и их связей.
Другим положительным моментом такого подхода явля-
ется то, что структура прикладного решения становится
«прозрачной» и «легко читаемой». Любому разработчи-
ку, не принимавшему непосредственного участия в разра-
ботке данного решения, достаточно взглянуть на структу-
ру объектов метаданных, чтобы понять, в общих чертах,
как оно «устроено». Открыв конфигуратор, он увидит
привычный набор объектов метаданных, назначение каж-
дого из которых ему хорошо известно.
Ограниченный набор объектов конфигурации, которые
может использовать разработчик, является еще одной
особенностью прикладных решений ЮПредприятия.
Платформа поддерживает фиксированный набор про-
тотипов объектов метаданных (например, справочник,
документ, регистр накопления, бизнес-процесс и т. д.).
Разработчик не имеет возможности каким-либо образом
создать собственный объект конфигурации (например,
просто таблицу, содержащую набор колонок). Он может
только добавить в прикладное решение новый объект
конфигурации, соответствующий одному из прототипов,
поддерживаемых системой (например, регистр сведений,
обладающий набором реквизитов). Такой подход позво-
ляет создать среду описания прикладных решений, со-
стоящую из логических сущностей, одинаковых для всех
прикладных решений (рис. 3.1).
Добавление новых объектов конфигурации в прикладное
решение сразу же позволяет использовать их для ввода и
модификации информации. Технологическая платформа
«знает», как работать с данными того или иного объекта
конфигурации, и в определенные моменты работы при-
кладного решения самостоятельно может сгенерировать
нужные формы для работы с данными.
Таким образом, все объекты конфигурации, которые мо-
жет использовать разработчик, обладают некоторым базо-
вым поведением, которое реализуется платформой без
участия разработчика. В простейшем варианте создание
функционального и работоспособного прикладного решения
возможно исключительно средствами визуального конст-
руирования, без написания какого либо текста программы.
Прикладное решение 1С:Предприятия
"Обычное" прикладное решение
_______Конфигурация
Справочник Номенклатура
Справочник Клиенты
Регистр накопления Цены
-----► Бизнес-процесс Получение товаров
Уровень объектов
метаданных
Атализ структуры
метаданных
Технологическая платформа
Рестру ктуризаци я
информационной
базы
Информационная база
Уровень физических
таблиц базы данных
Рис. 3.1. Сравнение логических уровней приложения
Платформа проанализирует состав объектов конфигура-
ции и обеспечит все необходимые функции для работы
с ними.
Однако реальные задачи, решаемые с помощью системы
1С:Предприятие, всегда требуют наличия в прикладном
решении некоторых алгоритмов, специфичных для авто-
матизируемой области. Это могут быть, например, раз-
личные алгоритмы расчета себестоимости, контроля ос-
татков, распределения средств и т. д. Также возникает
необходимость в создании специфических форм, обла-
дающих нестандартным поведением, поскольку удобное
визуальное представление информации является одной
из наиболее важных задач для любого прикладного решения.
В этом случае разработчик имеет возможность использо-
вать встроенный язык 1С:Предприятия для того, чтобы
определить поведение прикладного решения, отличное от
стандартного. С помощью встроенного языка разработ-
чик может «вмешиваться» в работу прикладного реше-
ния: выполнять какие-либо алгоритмы, обрабатывать и
модифицировать данные, изменять или вообще отменять
стандартные действия системы в зависимости от тех или
иных результатов работы.
Ключевым моментом здесь является то, что подобное
«вмешательство» возможно не всегда, а только в опреде-
ленные моменты работы прикладного решения. Таким
образом, встроенный язык не является неким универ-
сальным языком программирования, с помощью которо-
го создаются прикладные решения, а служит лишь для
описания особенных алгоритмов работы прикладного ре-
шения.
Модули конфигурации
Для размещения текста программы на встроенном языке
предназначены модули прикладного решения (например,
модуль приложения, общие модули, модули объектов, мо-
дули форм и т. д.). Эти модули располагаются в различных
местах конфигурации и имеют различное назначение.
Большинство модулей «привязано» к определенным
объектам конфигурации или к самому прикладному ре-
шению. Такие модули вызываются в определенные мо-
менты работы прикладного решения (например, мо-
дуль приложения, который запускается при запуске
системы в режиме 1 С: Предприятие, или модуль объек-
та справочника Номенклатура, который запускается при
создании объекта (элемента) справочника).
Таким образом, если модуль содержит некоторый код, то
этот код будет выполнен и работа прикладного решения
продолжена. В таких модулях могут располагаться про-
цедуры обработки событий, определенных для различных
объектов прикладного решения. Эти процедуры также
будут выполняться при наступлении соответствующего
события.
Глобальный контекст
Экспортируемые
функции и процедуры
Общий модуль
Модуль приложения
Модуль внешнего
соединения
Экспортируемые
переменные,
функции, процедуры
Экспортируемые
переменные,
функции, процедуры
Модуль объекта
Модуль формы
Экспортируемые
переменные,
функцию, процедуры
Экспортируемые
переменные,
функции, процедуры
Рис. 3.2. Контексты прикладного решения
Наряду с модулями, вызываемыми в процессе работы
прикладного решения, существуют общие модули, кото-
рые сами по себе не вызываются в процессе работы при-
кладного решения. Они служат лишь для размещения в
них текстов функций и процедур, которые могут вызы-
ваться из других модулей прикладного решения.
Таким образом, код, располагающийся в общих модулях,
будет исполнен только тогда, когда к нему будет выпол-
нено явное обращение из другого модуля конфигурации
или из командного интерфейса.
Каждый модуль связан с остальной частью конфигура-
ции, и эта связь называется контекстом выполнения мо-
дуля. Контекст определяет набор доступных для модуля
объектов, переменных, процедур и функций.
Для всех программных модулей доступен (с некоторыми
ограничениями, которые будут рассмотрены далее) гло-
бальный контекст задачи. Он образуется значениями
свойств и методов глобального контекста, а также сис-
темными перечислениями и системными наборами зна-
чений. В общем виде связь контекстов различных моду-
лей представлена на следующей схеме (рис. 3.2).
Общий модуль
В конфигурации может быть определено произвольное
количество общих модулей, в том числе и ни одного. Кон-
текст общего модуля образуется глобальным контекстом
и локальным контекстом самого общего модуля, то есть
процедурами и функциями, определенными внутри об-
щего модуля (рис. 3.3).
Поскольку общий модуль не исполняется системой непо-
средственно, в нем отсутствует раздел описания перемен-
ных и раздел основной программы. Общий модуль может
содержать только определения процедур и функций.
Если процедуры или функции общего модуля определе-
ны как экспортируемые, то они становятся частью гло-
бального контекста и будут доступны другим модулям
прикладного решения (за некоторыми исключениями,
о которых будет сказано далее).
Поскольку общий модуль не «привязан» к какому-либо
объекту конфигурации, а относится ко всему прикладному
решению, имена экспортируемых переменных, процедур
и функций должны быть различными в разных общих
модулях. В противном случае будет выдана синтаксиче-
ская ошибка, так как глобальный контекст будет содер-
жать повторяющиеся имена.
Модуль приложения
В конфигурации всегда существует единственный модуль
приложения. Контекст модуля приложения (рис. 3.4) об-
разуется:
♦ глобальным контекстом, в том числе экспортируемыми
функциями и процедурами общих модулей (если для
этих модулей установлено хотя бы одно из свойств Кли-
ент или Сервер);
♦ локальным контекстом самого модуля приложения.
Глобальный контекст
Глобальный контекст
Экспортируемые
функции и процедуры
Экспортируемые
функции и процедуры
Общий модуль
Общий модуль
Модуль приложения
Рис. 3.3. Контекст общего модуля
Рис. 3.4. Контекст модуля приложения
Модуль приложения выполняется при запуске системы
в режиме 1 С: Предприятие или при обращении к прило-
жению как к Autoniation-серверу. Этот модуль пред-
назначен для отработки действий, связанных с сеансом
работы конечного пользователя. Помимо описания пере-
менных и основной программы, модуль приложения мо-
жет содержать описание процедур-обработчиков собы-
тий, связанных с сеансом пользователя и прикладным
решением в целом.
Если переменные, процедуры или функции модуля при-
ложения определены как экспортируемые, то они будут
доступны другим модулям прикладного решения (за не-
которыми исключениями, о которых будет сказано да-
лее), за исключением общих модулей, в которых они дос-
тупны не будут.
Основными событиями, которые могут обрабатываться
в модуле приложения, являются события начала и окон-
чания работы приложения. Последовательность их вызо-
ва представлена на рис. 3.5.
Рис. 3.5. Последовательность вызова событий
модуля приложения
Событие ПередНачаломРаботыСистены возникает при запуске
системы в режиме ЮПредприятие до открытия главного
окна. Обрабатывая это событие, разработчик имеет воз-
можность отказаться от запуска системы в случае, если
какие-либо условия не выполнены. Следует учитывать,
что поскольку это событие вызывается в тот момент, ко-
гда главное окно программы еще не открыто, будет недос-
тупен ряд действий, требующих наличия главного окна
(например, выдача сообщений, открытие форм и т. д.).
Событие ПриНачалеРаботыСистены возникает при запуске сис-
темы в режиме ЮПредприятие после открытия главного
окна. В обработчике этого события разработчик уже не
может отказаться от запуска системы, зато может выпол-
нить действия, которые обязательно должны быть выпол-
нены при начале работы пользователя системы (например,
открыть форму, содержащую справочную информацию
и т. д.).
Событие ПередЗавершениемРаботыСистемы возникает при за-
вершении работы системы в режиме ЮПредприятие до
закрытия главного окна. Обрабатывая это событие, раз-
работчик имеет возможность отказаться от завершения
работы в случае, если какие-либо условия не выполнены.
Событие ПриЗавершенииРаботыСистемы возникает при завер-
шении работы системы в режиме 1 С: Предприятие после
закрытия главного окна. В обработчике этого события
разработчик уже не может отказаться от закрытия прило-
жения, но может выполнить действия, которые обяза-
тельно должны быть выполнены при окончании работы
пользователя. Следует учитывать, что поскольку это
событие вызывается в тот момент, когда главное окно
программы уже закрыто, будет недоступен ряд действий,
требующих наличия главного окна (например, выдача
сообщений, открытие форм и т. д.).
Модуль внешнего соединения
В конфигурации всегда существует единственный мо-
дуль внешнего соединения. Контекст модуля внешнего
соединения (рис. 3.6) образуется:
♦ глобальным контекстом, в том числе экспортируемыми
функциями и процедурами общих модулей (если для
этих модулей установлено хотя бы одно из свойств
Внешнее соединение или Сервер);
♦ локальным контекстом самого модуля приложения.
Глобальный контекст
Экспортируемые
функции и процедуры
Общий модуль
Модуль внешнего
соединения
Рис. 3.6. Контекст модуля внешнего соединения
Модуль внешнего соединения выполняется при обраще-
нии к приложению как к COM-серверу (в режиме внеш-
него соединения). В режиме внешнего соединения запус-
кается не полноценное приложение ЮПредприятия,
а «облегченный» вариант приложения, в котором недос-
тупны все функции, так или иначе связанные с организа-
цией пользовательского интерфейса. Поэтому в режиме
внешнего соединения вместо модуля приложения испол-
няется модуль внешнего соединения. Этот модуль пред-
назначен для отработки действий, связанных с сеансом
работы с приложением ЮПредприятия.
Если переменные, процедуры или функции модуля внеш-
него соединения определены как экспортируемые, то они
будут доступны другим модулям объектов (за некоторы-
ми исключениями, о которых будет сказано далее), за ис-
ключением общих модулей, в которых они доступны не
будут.
Помимо описания переменных и основной программы,
модуль внешнего соединения может содержать описание
двух процедур-обработчиков событий, связанных с нача-
лом и завершением работы: ПриНачалеРаботыСистены и При-
ЗавершенииРаботыСистемы. Последовательность их вызова
представлена на рис. 3.7.
При работе в модуле внешнего соединения следует пом-
нить о том, что ряд объектов встроенного языка, про-
цедур и функций глобального контекста будут не-
доступны для использования, так как СОМ-сервер
1 С:Предприятия не содержит «интерфейсной» части
приложения.
Рис. 3.7. Последовательность вызова событий модуля
внешнего соединения
Например, в режиме внешнего соединения нельзя ис-
пользовать такие объекты, как диаграмма, табличный до-
кумент, недоступны функции для вызова диалога ввода
данных и т. д. Точная информация о возможности ис-
пользования объектов, процедур и функций в модуле
внешнего соединения находится в документации, в опи-
сании конкретных объектов, процедур и функций.
Модуль объекта
Каждый прикладной объект конфигурации, данные кото-
рого могут быть модифицированы в режиме ^Предпри-
ятие, имеет свой модуль. Этот модуль исполняется при
создании объекта встроенного языка, который позволяет
модифицировать данные объекта конфигурации. Соот-
ветствующий объект встроенного языка создается, на-
пример, при вводе нового объекта, при копировании, при
получении данных существующего объекта и т. д. Для
различных объектов конфигурации этот модуль имеет
разное название (табл. 3.1).
Контекст модуля объекта (рис. 3.8) образуется:
♦ глобальным контекстом, в том числе экспортируемыми
функциями и процедурами общих модулей (в зависи-
мости от места создания объекта, о чем будет сказано
далее);
♦ экспортируемыми переменными, процедурами и функ-
циями модуля приложения или модуля внешнего со-
единения (в зависимости от места создания объекта,
о чем будет сказано далее);
♦ свойствами и методами объекта встроенного языка,
контекст которого расширяется модулем;
♦ реквизитами объекта конфигурации, которому «при-
надлежит» модуль;
♦ локальным контекстом самого модуля объекта.
Глобальный контекст
Модуль приложения
Экспортируемые
функции и процедуры
Ч Экспортируемые
переменные,
функции, процедуры
Общий модуль
Модуль объекта
Рис. 3.8. Контекст модуля объекта
Если переменные, процедуры или функции модуля объ-
екта определены как экспортируемые, то они будут дос-
тупны в качестве свойств и методов соответствующих
объектов встроенного языка.
Например, пусть в модуле справочника ТиповыеАнкеты
определена экспортная процедура (листинг 3.1).
Таблица 3.1. Название модуля объекта для различных объектов конфигурации
Объект конфигурации Название модуля Объект встроенного языка, который расширяется модулем
Константа Модуль менеджера значения КонстантаМенеджерЗначения.<имя>
Справочник Документ Отчет Обработка План видов характеристик План счетов План видов расчета План обмена Бизнес-процесс Задача Модуль объекта СправочникОбъект.<имя> ДокументОбъект.<имя> ОтчетОбъект.<имя> ОбработкаОбъект.<имя> ПланВидовХарактеристикОбъект.<имя> ПланСчетовОбъект.<имя> ПланВидовРасчетаОбъект.<имя> ПланОбменаОбъект.<имя> БизнесПроцессОбъект.<имя> ЗадачаОбъект.<имя>
Последовательность Регистр сведений Регистр накопления Регистр бухгалтерш! Регистр расчета Перерасчет Модуль набора записей ПоследовательностьНаборЗаписей.<имя> РегистрСведенийНаборЗаписей.<имя> РегистрНакопленияНаборЗаписей.<имя> РегистрБухгалтерииНаборЗаписей.<имя> РегистрРасчетаНаборЗаписей.<имя> ПерерасчетНаборЗаписей.<имя>
Листинг 3.1. Экспортная процедура в модуле
справочника
Процедура Печать О Экспорт
// Алгоритм вывода на экран печатной формы анкеты
// ...
КонецПроцедуры //
Тогда возможен следующий вызов этой процедуры, на-
пример, из модуля внешней обработки (листинг 3.2).
Листинг 3.2. Пример вызова экспортной процедуры
объекта справочника
Анкета = Справочники.ТиповыеАнкеты.
НайтиПоКодуСООООГ) .ПолучитьОбьектО;
Анкета.ПечатьО;
Помимо описания переменных и основной программы,
модуль объекта может содержать описание процедур-об-
работчиков событий, связанных с данным объектом кон-
фигурации. Состав этих событий различен для разных
объектов, однако есть два события, которые вызываются
для всех объектов — ПередЗаписью и ПослеЗаписи. Последо-
вательность их вызова представлена на рис. 3.9:
Транзакция
записи
Рис 3.9. Последовательность вызова событий
модуля объекта
(например, при открытии формы элемента справочника)
либо явно получаться средствами встроенного языка (лис-
тинг 3.3).
Листинг 3.3. Пример получения формы
Форма = Справочники.Номенклатура.ПолучитьФориуСпискаО;
Контекст модуля формы (рис. 3.10) образуется:
♦ глобальным контекстом, в том числе экспортируемыми
функциями и процедурами общих модулей (если для
этих модулей установлено хотя бы одно из свойств Или -
ент или Сервер);
♦ экспортируемыми переменными, процедурами и функ-
циями модуля приложения;
♦ свойствами и методами объекта, который назначен ос-
новным реквизитом формы, включая экспортируемые
переменные, процедуры и функции, определенные в мо-
дуле этого объекта;
♦ свойствами и методами расширения формы, определяе-
мого основным реквизитом формы;
♦ свойствами и методами объекта Форма встроенного языка;
♦ реквизитами формы, которой «принадлежит» модуль;
♦ локальным контекстом самого модуля формы.
Глобальный контекст
Экспортируемые
функции и процедуры
Общий модуль
Модуль приложения
Экспортируемые
переменные,
функции, процедуры
Модуль объекта
Экспортируемые
переменные,
функции, процедуры
Модуль формы
J
Событие ПередЗаписью вызывается при записи данных, по-
сле начала транзакции записи, но перед непосредствен-
ной записью данных в базу данных. В обработчике этого
события разработчик имеет возможность отказаться от
записи данных, если, например, не выполнены требуемые
условия.
Событие ПриЗаписи вызывается после того, как была вы-
полнена запись данных в базу данных, но до окончания
транзакции записи. В обработчике этого события разра-
ботчик также может отказаться от записи данных, если,
например, в результате записи этих данных в базу нару-
шаются какие-либо условия.
Модуль формы
Каждая форма, определенная в конфигурации, имеет свой
собственный модуль. Этот модуль исполняется при соз-
дании объекта Форма встроенного языка. Этот объект может
создаваться при открытии формы прикладного объекта
Рис. 3.10. Контекст модуля формы
Если переменные, процедуры или функции модуля фор-
мы определены как экспортируемые, то они будут дос-
тупны в качестве свойств и методов соответствующих
объектов Форма встроенного языка.
Помимо описания переменных и основной программы,
модуль формы может содержать описание процедур-об-
работчиков событий, связанных с формой. Основными
событиями, которые могут обрабатываться в модуле форы,
являются события открытия и закрытия окна формы. По-
следовательность их вызова представлена на рис. 3.11.
Событие ПередОткрытиен возникает при открытии формы
до показа ее окна пользователю. Изменения значений ре-
квизитов формы, выполняемые в этом обработчике, не
будут приводить к установке модифицированности фор-
мы, поэтому здесь можно выполнять установку началь-
ных значений и инициализацию необходимых рекви-
зитов.
Рис. 3.11. Последовательность вызова событий модуля формы
В обработчике этого события разработчик имеет возмож-
ность отказаться как от открытия формы, так и от выпол-
нения стандартных действий при открытии формы, если,
например, не выполнены требуемые условия. Набор стан-
дартных действий, выполняемых после события ПередОт-
крытием и до события ПриОткрытии, различен для разных
форм, и определяется расширением формы, соответст-
вующим основному реквизиту формы. Например, для
формы объекта справочника после события ПередОткрыти-
ен будет выполняться процедура генерации нового кода
справочника (если это необходимо) и, соответственно,
будет вызван обработчик события ПриУстановкеНовогоКода.
Событие ПриОткрытии возникает при открытии формы до
показа ее окна пользователю. Это событие предназначено
для выполнения действий, которые необходимо выпол-
нить лишь в том случае, когда форма наверняка будет от-
крыта. В отличие от события ПередОткрытиен, изменение
значений реквизитов формы в этом обработчике будет
приводить к установке модифицированности формы.
Событие ПередЗакрытиен возникает при закрытии формы
до закрытия окна формы. В обработчике этого события
разработчик имеет возможность отказаться как от закры-
тия формы, так и от выполнения стандартных действий
при закрытии формы, если, например, не выполнены тре-
буемые условия. Набор стандартных действий, выпол-
няемых после события ПередЗакрытиен, также различен
для разных форм, и определяется расширением формы,
соответствующим основному реквизиту формы. Напри-
мер, если документ был модифицирован, одним из стан-
дартных действий будет запрос сохранения изменений
перед закрытием формы.
Событие ПриЗакрытии возникает при закрытии формы по-
сле закрытия окна формы. В обработчике этого события
можно описывать алгоритмы, которые должны быть вы-
полнены только в случае, когда форма будет наверняка
закрыта.
Компиляция модулей
При запуске прикладного решения выполняется загрузка
метаданных и компиляция программных модулей, кото-
рые содержатся в метаданных. Первоначально компили-
руются не все модули прикладного решения, а только те,
которые необходимы для начала работы. Компиляция же
большинства остальных модулей выполняется по мере
вызова соответствующих объектов. Причем, после того,
как модуль, например, экземпляра объекта справочника
Номенклатура, скомпилирован, он помещается в кэш моду-
лей. При создании следующего экземпляра объекта спра-
вочника Номенклатура компиляция выполняться не будет —
скомпилированный ранее модуль будет получен из кэша.
Следует заметить, что некоторые модули прикладного ре-
шения могут содержаться в конфигурации уже в виде
скомпилированного образа. Для этого используются воз-
можности механизма поставки, о которых подробнее мож-
но прочитать в разделе «Настройка поставки», с. 659.
В этом случае конфигурация физически не содержит ис-
ходного текста модуля (только скомпилированный об-
раз), поэтому при создании объектов, содержащих такие
модули, компиляция, естественно, не выполняется. Воз-
можность включения модуля в виде скомпилированного
образа является элементом защиты интеллектуальной
собственности, и элементом защиты логической целост-
ности конфигурации от изменения ее пользователем. Она
не влияет на скорость работы прикладного решения,
так как дальнейшая работа с такими модулями также осу-
ществляется через кэш модулей.
Также может существовать и третья ситуация, когда ком-
пиляция модуля не выполняется, а используется скомпи-
лированный образ. Некоторые модули (например, моду-
ли объекта) могут быть закрыты паролем (команда Текст ►
Установить пароль). В этом случае конфигурация будет со-
держать зашифрованный текст модуля. Сам пароль, с помо-
щью которого текст был зашифрован, в конфигурации
не хранится. Поэтому для того, чтобы этот модуль мог
исполняться, одновременно с шифрованием модуля создает-
ся его скомпилированный образ, который и используется
при работе прикладного решения в режиме ЮПредприятие.
В отличие от поставки без исходного текста, в этом слу-
чае разработчик, зная пароль, может просматривать и/или
модифицировать исходный текст модуля в режиме кон-
фигуратора.
Компиляция модулей
и режимы исполнения
встроенного языка
В общем случае компиляция модулей выполняется в не-
скольких контекстах: в контексте сервера и контексте
клиента, то есть компилируется свой экземпляр модуля
на стороне клиента и/или на стороне сервера. Если ис-
пользуется файловый вариант работы, то оба эти контек-
ста «сливаются» и, фактически, в контексте клиента бу-
дут скомпилированы все модули конфигурации. Поэтому
далее мы будем рассматривать работу приложения имен-
но в клиент-серверном варианте, когда контексты клиен-
та и сервера отличаются друг от друга.
Исполнение модулей также может происходить в не-
скольких режимах. Модули, скомпилированные на сто-
роне сервера, всегда исполняются в одном и том же режи-
ме — режиме сервера. В отличие от них модули,
скомпилированные на стороне клиента, могут исполнять-
ся в одном из двух режимов: в режиме клиента или в ре-
жиме внешнего соединения.
Каждый из режимов исполнения имеет свои особенно-
сти, которые в общем виде приведены в табл. 3.2.
Как видно из приведенной таблицы, не все модули могут
быть скомпилированы в любых контекстах и не все ском-
пилированные модули могут быть исполнены в любых
режимах.
Далее будет подробно рассмотрена компиляция модулей
прикладного решения в различных контекстах и возмож-
ность использования инструкций препроцессору для вы-
полнения условной компиляции.
Что же касается исполнения встроенного языка, то система
позволяет выполнить синтаксический контроль модулей
прикладного решения в различных режимах исполне-
ния — для этого предназначена команда Конфигурация ►
Проверка конфигурации...
Особенности исполнения встроенного языка на сервере
и механизм передачи исполнения с клиента на сервер
подробно рассматриваются в разделе «Организация вы-
полнения кода на сервере или на клиенте», с. 86.
Компиляция общих модулей
Экземпляры общих модулей компилируются в соответствии
со значениями свойств Клиент, Сервер и Внешнее соединение этих
модулей. Если для общего модуля установлено только свой-
ство Клиент, то экземпляр этого модуля будет скомпилирован
только на стороне клиента. Если установлено только свойст-
во Сервер — то только на стороне сервера (рис. 3.12).
Компиляция общего модуля
(Клиент = Истина)
1 С.Предприятие
СОМ-соединение
Сервер
Клиент
Сервер • Клиент
Общий
модуль
Компиляция общего модуля
(Сервер = Истина)
Таблица 3.2. Режимы исполнения встроенного языка
Компьютер клиента Компьютер сервера
Исполняемое приложение Клиентское приложение СОМ-соединение Сервер 1С:Предприятия
Режим запуска системы 1С:Предприятие Интерактивный запуск в режиме 1С:Предприятие или запуск в качестве Automation-сервера (V8. Application) Запуск в качестве СОМ- сервера (V8.COMConnector) Присутствует в любом режиме запуска, но имеет смысл только в клиент- серверном варианте работы
Режим исполнения встроенного языка Клиент Внешнее соединение Сервер
Модуль, исполняемый после запуска системы Модуль приложения Модуль внешнего соединения Отсутствует. Может быть исполнен код общего модуля и только в том случае, если исполнение передано с клиента на сервер
Использование общих модулей Если установлено свойство Клиент Если установлено свойство Внешнее соединение Если установлено свойство Сервер
Использование объектов встроенного языка Любые объекты Некоторые объекты. Если объект не может быть использован в режиме внеш- него соединения, в докумен- тации для него указано: «Не используется в модуле внешнего соединения» Некоторые объекты. Если объект не может быть использован на сервере, в документации для него указано: «Недоступен на сервере» 1С:Предприятия»
Использование форм Любые формы Не используются Не используются
Передача объектов на сервер и обратно Могут быть переданы только некоторые объекты, для которых в документации указано: «Возможен обмен с сервером»
Если для общего модуля установлены свойства Клиент
и Сервер одновременно, то экземпляры этого общего мо-
дуля будут скомпилированы как на стороне клиента, так
и на стороне сервера (рис. 3.13).
Если для общего модуля установлено свойство Внешнее
соединение, то экземпляр этого модуля будет скомпилиро-
ван на стороне клиента только в случае запуска 1 (^Пред-
приятия в сеансе внешнего соединения (при обращении
к нему как к COM-серверу) (рис. 3.14).
Если для общего модуля установлены свойства Сервер,
Клиент и Внешнее соединение, то экземпляр этого модуля
всегда будет компилироваться как на стороне сервера, так
и на стороне клиента (рис. 3.17).
Компиляция общего модуля
(Клиент = Истина. Сервер = Истина)
1 С.Предприятие
С ОМ-соединение
Клиент
Клиент
Компиляция общего модуля
(Сервер - Истина, Клиент = Истина. Внешнее
соединение = Истина)
клиенте и в сеансе внешнего соединения
Сервер
Общий
модуль
Сервер
Рис. 3.13. Компиляция общего модуля для исполнения
на сервере и клиенте
Компиляция общего модуля
(Внешнее соединение = Истина)
1 С:Предприятие
Сервер ! Клиент
С ОМ-соединение
Сервер
Клиент
Общий
модуль
Рис. 3.14. Компиляция общего модуля для исполнения
в сеансе внешнего соединения
Компиляция модуля
приложения и модуля
внешнего соединения
Модуль приложения и модуль внешнего соединения все-
гда компилируются только на стороне клиента. Модуль
приложения компилируется в случае, если выполняется
запуск конфигурации в режиме 1 С:Предприятие или
приложение запускается в качестве Automation-сервера.
Модуль внешнего соединения компилируется в случае,
если приложение запускается в качестве СОМ-сервера
(рис. 3.18).
Если для общего модуля установлены свойства Сервер
и Внешнее соединение, то на стороне сервера всегда будет
компилироваться экземпляр этого модуля, а на стороне
клиента — только в сеансе внешнего соединения (рис. 3.15).
Компиляция модуля приложения
и модуля внешнего соединения
1 (^Предприятие
С ОМ-соединение
Сервер
Клиент
Сервер
Клиент
Компиляция общего модуля
(Сервер = Истина. Внешнее соединение = Истина)
1 С: Предприятие
С ОМ-соединение
Сервер
Клиент
Сервер
Клиент
Модуль
приложения
Модуль
внешнего
соединения
Рис. 3.18. Компиляция модуля приложения
и модуля внешнего соединения
Общий
модуль
Общий
модуль
Общий
модуль
Таким образом, можно сказать, что модуль внешнего со-
единения выполняет функции модуля приложения в се-
ансе СОМ-соединения.
Рис. 3.15. Компиляция общего модуля для исполнения
на сервере и в сеансе внешнего соединения
Если для общего модуля установлены свойства Клиент
и Внешнее соединение, то экземпляр этого модуля будет все-
гда компилироваться на стороне клиента (рис. 3.16).
Компиляция общего модуля
(Клиент = Истина. Внешнее соединение = Истина)
1 СПредлриятме
С О М-соединение
Сервер
Клиент
Сервер
Клиент
Общий
модуль
Общий
модуль
Рис. 3.16. Компиляция общего модуля для исполнения
на стороне клиента и в сеансе внешнего соединения
Компиляция модуля объекта
Экземпляр модуля объекта компилируется в процессе ра-
боты прикладного решения, и компиляция может быть
выполнена как на стороне клиента, так и на стороне сер-
вера. Это определяется тем, в каком контексте происхо-
дит обращение к объекту.
Если обращение к объекту выполняется, например, в моду-
ле приложения, то экземпляр объекта будет создан на сто-
роне клиента и, соответственно, экземпляр модуля объекта
будет также скомпилирован па стороне клиента (рис. 3.19).
Если же обращение к объекту выполняется в процедуре
общего модуля, для которого установлено свойство Сервер,
то объект будет создан на сервере и там же будет скомпи-
лирован экземпляр модуля этого объекта (рис. 3.20).
Сервер
Рис. 3.19. Компиляция модуля объекта на стороне клиента
Рис. 3.20. Компиляция модуля объекта на стороне сервера
Чтобы убедиться в том, что объект действительно созда-
ется на сервере или клиенте, можно добавить в модуль
объекта справочника Номенклатура следующие строки (лис-
тинг 3.4).
Листинг 3.4. Использование инструкций условной
компиляции
#Если Сервер Тогда
Сообщить("Объект создан на сервере”);
#ИначеЕсли Клиент Тогда
Сообщить ("Объект создан на клиенте’’):
#КонецЕсли
В этом примере использованы инструкции препроцессо-
ру, о которых более подробно рассказывается в разделе
«Использование инструкций препроцессору».
Следует помнить, что не все объекты могут быть исполь-
зованы на сервере или в сессии СОМ-соединепия. Точ-
ная информация о возможности использования объектов,
процедур и функций на сервере и в модуле внешнего со-
единения находится в документации, в описании кон-
кретных объектов, процедур и функций.
Компиляция модуля формы
Модуль формы всегда компилируется только на стороне
клиента и только в режиме ЮПредприятие, поскольку
объект форма не доступен на сервере и в режиме внешне-
го соединения.
Использование инструкций
препроцессору
В тексте модулей конфигурации, которые могут компи-
лироваться как на стороне сервера, так и на стороне кли-
ента (общие модули и модули объектов), допускается ис-
пользование инструкций препроцессору. Инструкции
препроцессору позволяют указывать, в каком контексте
будет скомпилирован тот или иной фрагмент кода (на
сервере, на клиенте, во внешнем соединении).
Например, если в модуле объекта разместить предыду-
щий текст (листинг 3.4), то в том случае, когда экземпляр
модуля объекта компилируется на клиенте, он будет со-
держать текст:
Сообщить("Объект создан на клиенте"):
Если же этот объект будет создаваться на стороне серве-
ра, тогда модуль объекта будет содержать следующий
текст:
Сообщить("Объект создан на сервере");
Таким образом, например, можно получить информацию
о том, на какой стороне (сервера или клиента) выполня-
ется данный участок кода.
Работа с метаданными
Встроенный язык 1С:Предприятия позволяет работать с
метаданными. Одним из концептуальных моментов этой
работы является то, что доступ к метаданным предостав-
ляется только на чтение. Таким образом, средствами
встроенного языка разработчик не может модифициро-
вать метаданные. Изменение структуры метаданных воз-
можно только средствами визуального конструирования
в режиме конфигуратора.
Для доступа к метаданным из встроенного языка исполь-
зуется объект ОбъектМетаданныхКонфигурация, который дос-
тупен через свойство глобального контекста Метаданные.
Этот объект предоставляет доступ как к свойствам самой
конфигурации, так и к отдельным коллекциям объектов
метаданных, которые описывают различные виды при-
кладных объектов, определенных в прикладном решении.
Например, для доступа к коллекции объектов метадан-
ных, описывающих документы, можно использовать сле-
дующий код (листинг 3.5).
Листинг 3.5. Доступ к коллекции метаданных
МетаданныеДокументов = Метаданные.Документы;
А для того, чтобы получить доступ к объектам конфигу-
рации, описывающим справочники, можно использовать
такой вызов (листинг 3.6).
Листинг 3.6. Доступ к коллекции метаданных
МетаданныеСправочников = Метаданные.Справочники;
Элементами таких коллекций являются объекты мета-
данных, которые позволяют получить доступ как к специ-
фическим свойствам объектов, так и к свойствам, общим
для различных объектов метаданных.
Например, можно получить описание реквизитов объек-
та, табличных частей объекта и их реквизитов, описания
форм, макетов объекта и т. д. (листинг 3.7).
Листинг 3.7. Получение описаний реквизитов объектов
метаданных
// Для объекта метаданных Документ.АккредитивПереданный
// можно получить:
// описание реквизита ВалютаДокумента
Объект = Метаданные.Документы.АккредитивПереданный.
Реквизиты.ВалютаДокумента;
// описание табличной части РасшифровкаПлатежа
Объект = Метаданные.Документы.АккредитивПереданный.
ТабличныеЧасти.РасшифровкаПлатежа;
// описание реквизита табличной
// части ДоговорКонтрагента
Объект = Метаданные.Документы.АккредитивПереданный.
ТабличныеЧасти.РасшифровкаПлатежа.
Реквиз иты.ДоговорКонтрагента;
Реквизиты, табличные части объекта метаданных также
представляют собой коллекцию объектов метаданных,
состоящих из объектов метаданных, описывающих от-
дельный реквизит или отдельную табличную часть.
В качестве примера на следующей схеме представлена
связь объектов, описывающих реквизиты и табличные
части объекта метаданных Документ.АккредитивПередан-
ный (рис. 3.21).
Рис. 3.21. Описание реквизитов и табличных частей документа
Таким образом, в большинстве случаев, значение некото-
рого свойства объекта метаданных может быть получено
по следующей цепочке программных объектов (рис. 3.22).
Рис. 3.22. Цепочка объектов описания метаданных
Такой подход позволяет упростить и унифицировать ра-
боту с метаданными, обращаясь к свойствам и методам
одних и тех же программных объектов. Объекты метадан-
ных имеют различный набор свойств, перечень которых
можно узнать при помощи команды Конфигурация | Отчет
по конфигурации.... Кроме этого, все коллекции объектов
метаданных допускают обращение к элементам коллек-
ции по имени или индексу. Также показанные на схеме
объекты имеют набор следующих методов (рис. 3.23).
Рис, 3.23. Методы объектов описания метаданных
Объект ОбъектМетаданныхКонфигурация содержит два метода,
которые позволяют найти объект метаданных, описываю-
щий некоторое значение или тип. Полученное таким об-
разом значение может быть использовано для того, чтобы
найти его в некоторой коллекции объектов метаданных
(метод Содержит О объекта КоллекцияОбъектовМетаданных) или
сравнить с конкретным объектом метаданных.
Например, в процессе перебора движений документа тре-
буется определить, к какому именно виду регистров отно-
сится данная запись регистра. В этом случае для записи
можно найти соответствующий объект метаданных и за-
тем определить, в какую из коллекций объектов метадан-
ных, описывающих регистры, входит полученный объект
метаданных (листинг 3.8).
Листинг 3.8. Пример использования метода СодержитО
// В качестве примера выбирается первая
// запись из первого набора записей,
// содержащегося в движениях документа
Движения = Документы. АвансовыйОтчет.
НайтиПоНомеруС"ТК000009", '20040101000000').
ПолучитьОбъектО .Движения[0];
Движения.Прочитать();
ОбъектМетаданных = Метаданные.
НайтиПоТипу(ТипЗнч(Движения[0]));
Если Метаданные.РегистрыНакопления.
Содержит(ОбъектМетаданных) Тогда
СообщитьСЭто движения по регистру накопления");
ИначеЕсли Метаданные.РегистрыСведений.
Содержит(ОбъектМетаданных) Тогда
СообщитьСЭто движения по регистру сведений");
ИначеЕсли Метаданные.РегистрыБухгалтерии.
Содержит(ОбъектМетаданных) Тогда
СообщитьСЭто движения по регистру бухгалтерии");
ИначеЕсли Метаданные.РегистрыРасчета.
Содержит(ОбъектМетаданных) Тогда
СообщитьСЭто движения по регистру расчета");
КонецЕсли;
Поскольку метаданные имеют иерархическую структуру,
объект, полученный методом НайтиПоТипуО, не всегда мо-
жет находиться в первом уровне иерархии нужной кол-
лекции объектов метаданных. В этом случае можно ис-
пользовать метод Родитель О объекта метаданных для
того, чтобы получить объект, находящийся на нужном
уровне иерархии.
Например, если некоторая универсальная процедура об-
рабатывает табличные части справочников по одному ал-
горитму, а табличные части документов — по другому, то
проанализировать принадлежность табличной части оп-
ределенному виду метаданных можно следующим обра-
зом (листинг 3.9).
Листинг 3.9. Пример использования метода РодительО
// В качестве примера получается табличная часть Товары
// документа АвансовыйОтчет
ТабличнаяЧасть = Документы.АвансовыйОтчет.
НайтиПоНомеруС"ТК000009",
'20040101000000').ПолучитьОбъект().
Товары;
ОбъектМетаданных = Метаданные.
НайтиПоТ ипу (ТипЗнч (Т абличнаяЧасть)). Родитель ();
Если Метаданные.Справочники.
Содержит(ОбъектМетаданных) Тогда
СообщитьСЭто табличная часть справочника");
ИначеЕсли Метаданные.Документы.
Содержит(ОбъектМетаданных) Тогда
СообщитьСЭто табличная часть документа");
КонецЕсли;
Как уже говорилось выше, коллекция объектов метадан-
ных позволяет обращаться к объектам по имени или ин-
дексу. Кроме этого, коллекция поддерживает итератор
Для Каждого..., с помощью которого, например, может
быть организован перебор всех элементов справочников,
содержащихся в конфигурации (листинг 3.10).
Листинг 3.10. Использование итератора Для Каждого
Для Каждого Справочник из Метаданные.Справочники Цикл
Сообщить (Сим волы. ПС + Справочник. ПолноеИмяО);
МенеджерСправочника = Справочники[Справочник.Имя];
Выборка = МенеджерСправочника.Выбрать!);
Пока Выборка.Следующий() Цикл
Сообщить(Выборка.Наименование);
КонецЦикла;
КонецЦикла;
Глава 4. Работа с данными
Объектные и необъектные данные
Все данные, которые хранятся в базе данных 1С:Пред-
приятия, можно разделить на две категории: объектные
и необъектные данные. Поскольку природа этих данных
различна, различаются и способы работы с объектными
и необъектными данными.
К объектным данным относятся данные справочников,
документов, планов видов характеристик, планов счетов,
планов видов расчета, бизнес-процессов, задач, планов
обмена.
К необъектным данным относятся данные регистров
сведений, регистров накопления, регистров расчета, пе-
рерасчетов, регистров бухгалтерии и последователь-
ностей. Также к необъектным данным относятся кон-
станты.
С точки зрения системы, объектные данные состоят из
отдельных объектов, каждый из которых обладает внут-
ренним уникальным идентификатором, благодаря нали-
чию которого к некоторой совокупности значений, храня-
щихся в базе данных, можно обращаться как к единому
целому — объекту. Например, объектом является элемент
справочника или документ. Каждый объект, помимо того,
что он является совокупностью значений некоторых по-
лей, имеет также определенную значимость сам по себе.
Например, элемент справочника ФизическиеЛица — это
некое физическое лицо, которое имеет набор характери-
зующих его значений: имя, фамилия, отчество, паспорт-
ные данные и т. д. У него может поменяться, например,
фамилия, или паспортные данные, но при этом он оста-
нется тем же самым физическим лицом — объектом, —
с точки зрения системы. Удаление какого-либо объекта
из системы приводит к тому, что состояние базы данных,
с точки зрения прикладного решения, изменяется. Да-
же создав новый элемент справочника ФизическиеЛица с
теми же самыми значениями реквизитов, мы получим
уже другое состояние базы данных, поскольку это будет
уже другой объект с другим уникальным идентифика-
тором.
В отличие от объектных данных, необъектные данные не
имеют собственной ценности и полностью описываются
значениями своих полей. Необъектные данные представ-
ляют собой записи, которые хранятся в базе данных. Для
записей не поддерживаются внутренние уникальные иден-
тификаторы. Удалив некоторую запись и создав новую,
с точно такими же значениями полей, мы получим то же
самое состояние базы данных, которое было до удаления
записи.
Рассмотрим работу с объектными и необъектными дан-
ными более подробно.
Объектные данные
Модель хранения данных
К объектным данным в 1С:Предприятии относятся дан-
ные следующих объектов конфигурации:
♦ Справочник;
♦ Документ;
♦ План видов характеристик;
♦ План счетов;
♦ План видов расчета;
♦ План обмена;
♦ Бизнес-процесс;
♦ Задача.
Для каждой объектной сущности конфигурации система
создает набор связанных между собой таблиц, в которых
и будут храниться данные этого объекта. Количество и
состав таблиц различны для каждого объекта метадан-
ных.
Структура хранения объектных данных всегда состоит из
основной таблицы и, возможно, нескольких других таб-
лиц (по одной таблице на каждую табличную часть объ-
екта). Например, для документа Доверенность, который
имеет некоторый набор реквизитов и табличную часть То-
вары (рис. 4.1), в базе данных будут созданы две таблицы.
Рис. 4.1. Документ Доверенность
Таблица документа будет содержать поля для каждого
реквизита документа, а для табличной части будет созда-
на отдельная таблица, содержащая поля для всех рекви-
зитов табличной части документа (рис. 4.2).
Таблица документа -Доверенность*
номер организация ФизЛицо
0x803650505450303011DA147DCE8D66E9
09.08.2004
12:00:00.000
TKD00003
Торговьй дом
"Комплексный"
Бахшиев П. И.
тически такое значение представляет собой внутренний
идентификатор, который хранится в поле Ссылка таблиц
базы данных.
Например, справочник Валюты хранится в базе данных
в таблице, которая, помимо служебных колонок, содер-
жит отдельные колонки для каждого реквизита справоч-
ника, заданного в конфигураторе. Поле Ссылка — это одно
из служебных полей. Значение этого поля позволяет од-
нозначно отличить один элемент справочника от другого
(проще говоря, одну валюту от другой) (рис. 4.3).
товара
Табличная часть "Товары" документа “Доверенность"
Ссыпка
Единица по
классификатору
Количество
0x803650505450303011DA147DCE8D66E9 1 Ассорти (конфеты) упак 10
0x803650505450303011DA147DCE8DB6E9 2 Барбарис (конфеты) кг 10
0x803650505450303011DA147DCE8D66E9 3 Белочка (конфеты) кг 10
0x803650505450303011DA147DCE8D66E9 4 Грильяж (конфеты) кг 10
Рис. 4.2. Таблицы документа Доверенность
Отличительной особенностью этих таблиц является то, что
каждая из них содержит поле Ссылка, в котором хранится
внутренний идентификатор, соответствующий каждому из
документов. Таким образом, объект документа представля-
ет собой совокупность записи основной таблицы и строк
табличных частей, относящихся к этому документу.
Основная таблица объектных данных также содержит обя-
зательное поле, в котором хранится текущая версия объек-
та. Значение этого поля изменяется при каждой записи
данных объекта в базу данных. Благодаря использованию
этого поля обеспечивается оптимистическая блокировка
объектных данных. Подробнее про оптимистическую бло-
кировку объектных данных можно прочитать в разделе
«Оптимистическая блокировка», с. 44.
Для работы с объектными данными во встроенном языке
существует два основных типа: ссылка и объект. Рассмот-
рим каждый из них более подробно.
Ссылка
Значение ссылочного типа (СправочникСсылка.<имя>, Доку-
нентСсылка.<иня> и т. д.) используется везде, где требуется
однозначно идентифицировать объект базы данных. Фак-
Ссылка Пометка удаления Код Наименован. Наименование полное
0x848A00112F43529A11D955BCBD72D8F9 Ложь Ложь 810 руб. Российский рубль
0x848A00112F43529AHD955eCBD72D8FA Ложь Ложь 840 USD Доллар США
0x848AQ0112F43529A110955В CCS CF4923 Ложь Ложь 978 EUR ЕВРО
Ох848А00112F43529A11D955BD0E617614 Ложь Ложь 792 TRL Турецкая лира
0х848А00112F43529A11D9558D0E617615 Ложь Ложь 001 у.е. Условная единица
Рис. 4.3. Поле Ссылка
Значение ссылки может, например, выбираться в полях
ввода, храниться в полях других таблиц базы данных
и т. д. Например, поля Организация и ФизЛицо документа
Доверенность будут хранить ссылки на элементы справоч-
ников «Организации» и ФизическиеЛица (рис. 4.4).
Значения ссылочного типа можно сравнивать между со-
бой. Важным моментом является то, что для каждого объ-
екта метаданных во встроенном языке создается свой тип
ссылки. Таким образом, например, ссылка на справочник
Организации никогда не будет равна ссылке па справочник
ФизическиеЛица, поскольку это значения разных типов.
Однако две ссылки на справочник Организации могут
быть равны между собой, и это будет выполняться только
в том случае, если это ссылки на один и тот же объект
базы данных (рис. 4.5).
Ссылки, указывающие на один и тот же объект базы дан-
ных, будут равны между собой независимо от того, каким
образом они получены. Например, ссылка на валюту с ко-
дом 810 (рубли), полученная через менеджер справочни-
ка Валюты, будет равна ссылке на эту валюту, полученную
из выборки справочника Валюты (листинг 4.1).
Таблица справочника "Организацкм"
Рис 4.4. Хранение ссылок в полях базы данных
Объект
СправочникСсы л ка. Организации
Объект
СправочникСсылка. Организации
Рис. 4.5. Сравнение объектов Ссылка
Листинг 4.1. Сравнение объектов Ссылка
Ссылка! = Справочники.Валюты.НайтиПоКодуС'ВЮ");
ВыборкаВалют = Справочники.Валюты.Выбрать О;
Пока ВыборкаВалют.Следующий() Цикл
Если Ссылка! = ВыборкаВалют.Ссылка Тогда
Сообщить!"" + ВыборкаВалют.Код + ” ”
+ ВыборкаВалют. Наименование);
КонецЕсли;
КонецЦикла;
Типы ссылок имеют значение по умолчанию — так назы-
ваемую пустую ссылку. Пустая ссылка — это значение
ссылки, которому не соответствует ни один объект в базе
данных. Фактически такой внутренний идентификатор
выглядит следующим образом:
00000000-0000-0000-0000-000000000000
Так как тип ссылки создается для каждого объекта мета-
данных, то, например, пустые ссылки на разные справоч-
ники, никогда не будут равны между собой (листинг 4.2).
Листинг 4.2. Сравнение пустых ссылок
ПустаяСсылкаНоненклатура = Справочники.Номенклатура.
ПустаяСсылкаО;
ПустаяСсылкаКонтрагенты = Справочники.Контрагенты.
ПустаяСсылкаО;
Если ПустаяСсылкаНоненклатура <>
ПустаяСсылкаКонтрагенты Тогда
Сообщить("Ссылки не равны.");
КонецЕсли;
Ссылка позволяет обращаться к свойствам объекта базы
данных, а также получать сам объект. При этом выполня-
ется чтение информации из базы данных, поскольку сама
ссылка не содержит этих данных. Подробнее об этом
можно прочитать в разделе «Объект», с. 39 .
Представление ссылочных значений
Поскольку ссылочные значения могут выбираться в поле
ввода и использоваться в других элементах интерфейса
системы, существует механизм формирования представ-
лений ссылочных значений. Благодаря этому механизму
пользователь может оперировать не безличными внут-
ренними идентификаторами, которые содержит ссылка,
а вполне определенными и понятными ему данными,
идентифицирующими объекты базы данных.
При добавлении объектов конфигурации система само-
стоятельно определяет правила формирования представле-
ний ссылочных значений, и от разработчика не требуется
никаких специальных действий. Однако при необходи-
мости, он может внести изменения в правила формирова-
ния представлений для ссылок на некоторые типы объек-
тов базы данных.
Например, для элементов справочников, видов характе-
ристик, счетов, видов расчетов и узлов планов обмена
представление ссылок может быть задано либо в виде
кода, либо в виде наименования (рис. 4.6).
Рис. 4.6. Задание представления справочника
Для задач разработчик может выбрать между представле-
нием ссылок в виде номера или наименования (рис. 4.7).
Рис. 4.7. Задание представления задачи
А для документов и бизнес-процессов система предостав-
ляет только единственное неизменяемое представление
ссылочных значений в виде совокупности синонима до-
кумента или бизнес-процесса и его даты.
Например: «Приходная накладная от 03.05.2004 15:35:27».
Контроль ссылочной целостности
ЮПредприятие предоставляет разработчику возможность
контролировать ссылочную целостность базы данных,
однако использование этой возможности не является
обязательным. С точки зрения платформы в базе данных
вполне могут содержаться неразрешимые ссылки (то есть
ссылки на объекты, которых не существует в базе дан-
ных), и это не является ошибкой. Необходимость поддер-
жания ссылочной целостности базы данных определяет-
ся логикой прикладного решения, и ситуация, когда база
данных содержит ссылки на несуществующие объекты,
может быть вполне допустимой для данного конкретного
прикладного решения.
Вопрос о необходимости контроля ссылочной целостно-
сти возникает при удалении данных из базы данных. Сис-
тема позволяет гибко использовать возможности контро-
ля ссылочной целостности как при интерактивном, так и
при программном удалении объектов.
Интерактивное удаление объектов может быть выполне-
но двумя способами.
Во-первых, объект может быть удален непосредственно из
базы данных, и в этом случае не будет выполняться ника-
ких проверок ссылочной целостности, и последующее
восстановление объекта будет невозможно. Возможность
непосредственного интерактивного удаления регулирует-
ся правом Интерактивное удаление.
Во-вторых, интерактивное удаление может быть выпол-
нено с использованием механизма контроля ссылочной
целостности. В этом случае удаление выполняется в два
этапа: сначала пользователь устанавливает пометку уда-
ления для тех объектов, которые он собирается удалить,
а затем выполняет процедуру удаления помеченных объ-
ектов. При этом сначала будет выполнен поиск ссылок па
удаляемые объекты в других данных, а затем для объек-
тов, ссылки на которые отсутствуют, будет выполнено
удаление.
При удалении объектов средствами встроенного языка
также существует возможность использовать или не ис-
пользовать контроль ссылочной целостности. Непосред-
ственное удаление объектов может быть выполнено мето-
дом объекта Удалить(), в то время как пометка на удаление
может быть установлена с помощью метода объекта Уста-
новитьПометкуУдаленияО. Последующий поиск помеченных
на удаление объектов может быть выполнен при помощи
функции глобального контекста НайтиПомеченныеНаУдале-
ние(), а их удаление — глобальной процедурой УдалитьОбъ-
ектыО, которая позволяет удалять объекты как с контро-
лем ссылочной целостности, так и без. При этом следует
учитывать, что удаление с контролем ссылочной целост-
ности выполняется в монопольном режиме.
При необходимости может быть выполнен отдельно
только поиск ссылок на удаляемые объекты — для этого
используется функция глобального контекста НайтиПо-
СсылкамО, которая возвращает список найденных ссылок
на переданные ей объекты.
Особенности использования
пометки удаления
Для того чтобы отличить объекты, помеченные на удале-
ние, от других объектов базы данных, таблицы, хранящие
данные этих объектов, содержат специальное поле Помет-
каУдаления. Значение этого поля может быть установлено
двумя способами.
Во-первых, может использоваться интерактивная уста-
новка пометки удаления или программное выполнение
метода объекта УстановитьПонеткуУдаления(). В этом случае,
кроме собственно установки значения этого поля, будет
выполнен ряд дополнительных действий, состав которых
зависит от типа помечаемого объекта. Например, для
справочника будет установлена пометка удаления для
всех подчиненных элементов этого справочника и подчи-
ненных справочников, для документа будет выполнена
отмена проведения и т. д. Также будет вызвано событие
объекта ПередЗаписькК), поскольку будет выполняться сохра-
нение измененного свойства ПонеткаУдаления этого объекта.
Во-вторых, значение поля ПонеткаУдаления может быть уста-
новлено путем непосредственной установки свойства По-
меткаУдаления объекта и последующей его записи. В этом
случае никаких дополнительных действий выполняться
не будет, однако следует учитывать особенности работы
некоторых объектов. Например, документ не может быть
одновременно проведен и помечен на удаление, поэтому,
если требуется пометить на удаление проведенный доку-
мент, предварительно следует установить его свойство
Проведен в значение Ложь или выполнить отмену проведе-
ния документа (Записать(РежинЗаписиДокунента.0тненаПрове-
дения)).
Объект
Тип объекта служит, прежде всего, для модификации
(чтения и изменения) данных, содержащихся в объекте
базы данных. Остальные объекты встроенного языка по-
зволяют только читать информацию базы данных.
Как уже говорилось ранее, объект представляет собой со-
вокупность записи основной таблицы и строк табличных
частей, относящихся к этому объекту. Например, рас-
смотрим документ ЗаказПоставщику, имеющий три таб-
личных части (рис. 4.8).
Конфигурация
» X
ДйЬви. > t t | Ц
u.« ЗаказПоставщику
I ; Bg Реквизиты
В =:ji Табличные части
I I i E Товары *
В Ш! ВозвратмаяТара
Е Услуги ф
В Q Формы
! | В Q Макеты v
Рис. 4.8. Документ ЗаказПоставщику
Объект документа (ДокументОбъект.ЗаказПоставщику) будет
представлять собой совокупность значений полей основ-
ной таблицы документа и полей каждой из таблиц, в ко-
торых хранятся данные его табличных частей (рис. 4.9).
Тип объекта используется при создании новых объектов,
для редактирования и удаления существующих объектов.
Кроме этого, тип объекта используется для отображения
и редактирования всех данных объекта в форме объекта.
Также этот тип используется при редактировании строки
списка объекта.
Значения этого типа, так же как и значения ссылок, мож-
но сравнивать между собой. Однако в отличие от ссылок,
значения этого типа будут равны между собой только тогда,
когда они являются одним и тем же экземпляром про-
граммного объекта.
Например, если в следующем примере (листинг 4.3) в пе-
ременную 0бъект1 получить экземпляр программного объ-
екта, соответствующий элементу справочника Номенклатура,
и затем значение этой переменной присвоить переменной
0бъект2, то значения этих переменных будут равны.
Листинг 4.3. Сравнение объектов
0бъект1 = Справочники.Номенклатура.НайтиПоКоду(1).
ПолучитьОбъектО;
Объект2 = Объект1;
Сообщить(Объект1 = 0бъект2);
Если же в переменные 0бъект1 и 0бъект2 получить экзем-
пляры объекта, соответствующие одному и тому же эле-
менту справочника Номенклатура, то значения этих пере-
менных не будут равны, несмотря на то, что в них считан
один и тот же объект базы данных и совпадают все дан-
ные этого объекта (листинг 4.4).
Листинг 4.4. Сравнение объектов
0бъект1 = Справочники.Номенклатура.НайтиПоКодуШ.
ПолучитьОбъектО;
Объект2 = Справочники.Номенклатура.НайтиПоКоду(1).
ПолучитьОбъектО ;
Сообщить(0бъект1 = 0бъект2);
Значение типа объект может быть получено несколькими
способами.
Во-первых, значение этого типа может быть получено че-
рез менеджер объекта, с использованием соответствую-
щего метода (например, для справочников это метод Соз -
датьЭлементО, для документов — СоздатьДокументО и т. д.).
При этом будет создан новый экземпляр программного
объекта, которому не соответствует ни один объект в базе
данных. В дальнейшем, когда будет выполнена запись
этого объекта, появится и новый объект в базе данных
(рис. 4.10).
Данные
объекта
Рис. 4.10. Создание нового объекта
Во-вторых, значение этого типа может быть получено из
ссылки, путем выполнения метода ПолучитьОбъектО. В этом
случае будет создан экземпляр программного объекта и
выполнено чтение данных из базы данных (или из кеша).
При этом считываются значения всех реквизитов объекта
и значения всех реквизитов всех его табличных частей
(рис. 4.11).
Рис. 4.11. Получение объекта
В-третьих, значение этого типа может быть получено из
выборки, путем выполнения метода с аналогичным на-
званием — ПолучитьОбъектО. В этом случае также будет
создан экземпляр программного объекта, однако чтения
из базы данных выполняться не будет, так как выборка
считывает из базы данных все данные объектов, и данные
созданного экземпляра объекта будут заполнены непо-
средственно из программного объекта выборки (рис. 4.12).
Рис. 4.12. Получение объекта
В связи с тем, что тип объекта позволяет модифициро-
вать данные, он имеет (помимо свойств и методов) целый
ряд событий, позволяющих разработчику определять
собственный алгоритм обработки выполняемых дейст-
вий. Среди основных событий, поддерживаемых этим ти-
пом, можно перечислить следующие события.
ПередЗаписью — это событие возникает перед записью объ-
екта в базу данных, до того, как начата транзакция записи.
В обработчике этого события можно проанализировать
необходимость (или возможность) выполнения записи
данных и отказаться от нее, если какие-либо условия не
выполняются.
ПриЗаписи — это событие возникает после того, как данные
записаны в базу данных, но до того, как окончится тран-
закция записи. В обработчике этого события можно вы-
полнять те действия, которые обязательно должны быть
выполнены только в том случае, если объект записан.
ПриКопировании — это событие возникает у нового объекта
данных в том случае, если он создается путем копирова-
ния (интерактивного или программного) существующего
объекта данных. В обработчике этого события можно
предусмотреть, например, алгоритм заполнения реквизи-
тов создаваемого объекта по умолчанию.
ОбработкаЗаполнения — это событие также возникает у но-
вого объекта данных в том случае, если он создается путем
ввода на основании (интерактивного или программного)
существующего объекта данных. В отличие от копирова-
ния, когда создаваемый и исходный объекты имеют оди-
наковые типы, при вводе на основании новый объект, как
правило, имеет тип отличный от типа объекта-основания.
Например, новый документ может быть введен на основа-
нии элемента справочника и т. д. Поэтому в обработчике
этого события, как правило, предусматривается некото-
рый алгоритм, позволяющий выполнять начальное за-
полнение реквизитов нового объекта в зависимости от
типа объекта-основания.
ПередУдалением — это событие возникает перед непосредст-
венным удалением объекта из базы данных. В обработчи-
ке этого события можно предусмотреть выполнение ка-
ких либо действий перед удалением объекта, а также, при
необходимости, отменить удаление объекта, если не вы-
полняются какие-либо условия.
Кэширование представлений
и объектов
При работе с объектными данными (как программно, так
и интерактивно) система выполняет кэширование считы-
ваемых данных в оперативной памяти. Для этого исполь-
зуется кэш объектов. При любых интерактивных дейст-
виях и при программном доступе к объектным данным с
использованием объектной модели прежде всего система
будет выполнять обращение к кэшу объектов для того,
чтобы получить запрашиваемые данные.
Кэш объектов состоит из двух частей: транзакционного
кэша и обычного кэша. В зависимости от того, происхо-
дит ли чтение в рамках транзакции или нет, будет выпол-
няться обращение к той или иной части кэша (рис. 4.13).
В кэш объектов считываются два «вида» данных: либо все
данные объекта целиком, либо значения полей, необходи-
мые для формирования представления ссылки на данный
объект.
Значения полей, необходимые для получения представ-
ления ссылки, считываются тогда, когда возникает необ-
ходимость отобразить ссылку на объект в каком-либо
элементе интерфейса, а также при явном или неявном
преобразовании ссылочной переменной к типу Строка.
В остальных случаях выполняется полное чтение всех
данных объекта, в том числе и тогда, когда выполняется
обращение к какому-либо реквизиту объекта через точку
от ссылки.
Чтение данных
К Транзакция \ Да
активна7 /
Кэш объектов
Обычный кз ш
Рис. 4.13. Обращение к кэшу объектов
Эту особенность нужно учитывать при проектировании
структуры объектов метаданных. Так, например, если
предполагается хранение в информационной базе карти-
нок, образов файлов или больших текстовых данных, то
рекомендуется создавать для этого отдельные структуры
хранения (например, справочники или регистры сведе-
ний), а не включать эту информацию в состав реквизитов
или табличных частей объектов, которым эта информа-
ция соответствует. Это позволит избежать считывания и
записи больших объемов данных при работе с этими объ-
ектами.
Обычный кэш
Если при обращении к обычному кэшу требуемых дан-
ных в нем нет, то выполняется чтение данных объекта из
базы данных и сохранение их в кэше. Уникальным иден-
тификатором для кэша в данном случае будет являться
ссылка на объект базы данных. Поэтому данные каждого
считанного объекта могут существовать в кэше в одном
из двух видов: либо все данные объекта, либо представле-
ние объекта.
Таким образом, если мы обратимся к кэшу для получения
представления объекта и в кэше есть информация для на-
шей ссылки, данные будут взяты из кэша (если в кэше
весь объект, нужное представление будет получено из
данных объекта). Если в кэше нет информации для на-
шей ссылки — из базы данных в кэш будут считаны толь-
ко поля, необходимые для формирования представления
объекта.
Если мы обратимся к кэшу для получения реквизита объ-
екта (через точку от ссылки) и в кэше есть информация
для нашей ссылки, дальнейшие действия будут зависеть
от того, какие именно данные находятся в кэше. Если в
кэше весь объект — значение реквизита будет получено
из кэша. Если в кэше представление объекта — оно будет
удалено из кэша и в кэш будут считаны все данные объек-
та. Если же при получении реквизита объекта в кэше нет
информации для нашей ссылки — из базы данных будут
считаны все поля объекта.
Считанные данные будут находиться в кэше до тех пор,
пока не наступит одно из четырех событий:
♦ считанные данные будут вытеснены из кэша другими
считанными данными других объектов (переполнение
кэша);
♦ при очередном обращении к кэшу окажется, что счи-
танные данные были изменены в базе данных;
♦ закончится интервал времени в 20 минут;
♦ данные будут изменены в базе данных.
Все считанные данные помещаются в последовательную
очередь, и, поскольку объем кэша ограничен, наиболее
старые данные будут вытесняться из кэша последними
считанными данными.
При повторном обращении к кэшу за данными уже счи-
танного объекта будет анализироваться интервал време-
ни, прошедший с момента появления данных в кэше.
Если обращение происходит в пределах 20 секунд после
поступления данных в кэш, данные считаются верными
(валидными). Если интервал превысил 20 секунд, будет
выполняться проверка на то, что версия данных, храня-
щихся в кэше, соответствует версии данных, находящих-
ся в базе данных. В случае если окажется, что версии дан-
ных не совпадают (то есть произошло изменение данных
в базе данных), данные, находящиеся в кэше, будут уда-
лены из него и выполнено повторное считывание данных
из базы данных. Начиная с этого момента, начнется от-
счет следующего 20-секундного интервала валидности
этих данных.
Кроме всех вышеперечисленных событий, считанные дан-
ные будут удалены из кэша по истечении 20 минут после
их последнего считывания из базы данных.
Рассмотрим последовательное выполнение двух операто-
ров (листинг 4.5), где Номенклатура — это ссылка на объ-
ект справочника, а Наименование и ВидНоменклатуры — ре-
квизиты справочника Номенклатура.
Листинг 4.5. Последовательное обращение
к реквизитам объекта
А = Номенклатура.Наименование;
В = Номенклатура.ВидНоменклатуры;
На выполнение второго оператора будет тратиться гораз-
до меньше времени, поскольку в первом случае (с боль-
шой долей вероятности) будет выполняться обращение к
базе данных и чтение всех данных объекта, а во втором —
чтение из оперативной памяти (кэша объектов).
Транзакционный кэш
Если обращение к данным происходит в рамках транзак-
ции, то оно переадресуется транзакционному кэшу. Тран-
закционный кэш, по сути, представляет собой ту же
последовательную очередь, что и обычный кэш, за исклю-
чением того, что все данные, находящиеся в транзакцион-
ном кэше, являются валидными (гарантированно акту-
альными). При считывании данных в транзакционный
кэш устанавливается блокировка на данные в базе дан-
ных, поэтому они гарантированно не могут быть измене-
ны до окончания транзакции.
Транзакционный кэш хранит считанные данные до тех
пор, пока они не будут вытеснены более поздними счи-
танными данными, или пока не закончится транзакция.
По окончании транзакции транзакционный кэш очищает-
ся, однако действия, выполняемые при этом, зависят от
состояния завершения транзакции.
Если транзакция завершена успешно (Commit), данные
всех объектов, содержащиеся в транзакционном кэше, пе-
реносятся в обычный кэш, а транзакционный кэш очища-
ется (рис. 4.14).
Рис. 4.14. Успешное завершение транзакции
Если был выполнен отказ от изменений (Rollback), то
просто очищается транзакционный кэш (рис. 4.15).
Рис. 4.15. Откат транзакции
Оптимизированная запись объектов
При записи объектов базы данных (программной или ин-
терактивной) выполняется оптимизация записи измене-
ний в базу данных.
Так, например, если не менялись значения реквизитов са-
мого объекта, то будет записана только минимальная ин-
формация об изменении (версия объекта).
Если не менялись строки табличной части, то табличная
часть записываться не будет.
Если менялись только отдельные строки табличной части
или добавлялись новые строки, то будут записаны только
измененные и добавленные строки. Однако если менялся
порядок строк или строки удалялись, то будут записаны
все строки табличной части.
Создание новых объектов
Зачастую при разработке или модификации прикладных
решений требуется выполнять некоторые действия, со-
провождающие создание тех или иных новых объектов
базы данных. Например, при создании новой приходной
накладной может потребоваться автоматически запол-
нять поле Склад, если известно, что все поступающие то-
вары должны приходоваться только на один определен-
ный склад. Также может потребоваться установка каких-
либо других реквизитов документа по умолчанию.
При решении подобных задач следует иметь в виду, что
логика системы разделяет такие понятия, как ввод нового
объекта пользователем и создание нового объекта базы
данных. Одним из следствий этого является отсутствие
какого-либо события, вызываемого при создании нового
объекта, которое может быть обработано в модуле объек-
та. Система не предоставляет разработчику возможность
анализа момента создания нового объекта.
Дело в том, что создание нового объекта базы данных не
всегда представляет собой ввод новой информации в сис-
тему. Например, в процессе обмена данными может вы-
полняться создание нового объекта базы данных узла.
С точки зрения бизнес-логики прикладного решения при
этом не происходит ввода новой информации в систему,
поскольку эта информация уже присутствует в системе
(только в другом узле).
С другой стороны, ввод новой информации, как правило,
выполняется при вводе новых объектов пользователем.
И как раз в этих ситуациях требуется выполнять дейст-
вия, например, по инициализации каких-либо реквизитов
объекта.
Учитывая приведенные выше соображения, рекоменду-
ется обрабатывать создание новых объектов следующим
образом. Если при вводе новой информации в систему и
создании нового объекта требуется выполнять какие-ли-
бо действия по инициализации реквизитов объекта, эти
действия необходимо выделять отдельной экспортной
процедурой в модуле объекта и вызывать эту процедуру
в явном виде в тех ситуациях, когда это необходимо.
Например, поскольку ввод информации пользователем
осуществляется при помощи форм объектов, то в модуле
формы объекта в процедуре ПередОткрытиемО можно ана-
лизировать значение метода ЭтоНовыйО объекта и в явном
виде вызывать созданную процедуру. Аналогичным обра-
зом, если логика прикладного решения подразумевает,
что при создании и записи нового объекта программно,
без участия пользователя, должны быть проинициализи-
рованы реквизиты объекта, то разработчик самостоятель-
но должен обрабатывать такие ситуации и явно вызывать
созданную процедуру модуля объекта.
Блокировки
При работе с объектными данными система обеспечивает
два вида блокировок — пессимистическую и оптимисти-
ческую, — которые позволяют выполнять целостные из-
менения объектов при одновременной работе нескольких
пользователей.
Пессимистическая блокировка
Механизм пессимистической блокировки запрещает из-
менение данных объекта другими сессиями или данной
сессией до тех пор, пока блокировка не будет снята этим
объектом встроенного языка (рис. 4.16).
Механизм пессимистической блокировки используется
системой 1 С: Предприятие для блокировки объектов, ре-
дактируемых в форме. В то же время разработчик также
имеет возможность задействовать этот механизм, исполь-
зуя средства встроенного языка.
Если говорить о системе, то механизмом пессимистиче-
ской блокировки управляют расширения форм приклад-
ных объектов. В тот момент, когда пользователь начинает
модификацию объекта в форме, расширение формы уста-
навливает пессимистическую блокировку. Если после
этого другой пользователь, например, попытается выпол-
нить редактирование того же объекта, ему будет выдано
сообщение о том, что не удалось заблокировать объект.
Когда пользователь, редактировавший объект, закроет
форму объекта, расширение формы снимет пессимисти-
ческую блокировку.
Рис. 4.16. Пессимистическая блокировка
Разработчик, для того чтобы задействовать пессимисти-
ческую блокировку, может использовать метод объекта
Заблокировать). Этот метод позволяет установить песси-
мистическую блокировку объекта и тем самым запретить
изменение данных объекта базы данных другими сессия-
ми 1 С: Предприятия и другими алгоритмами в текущей
сессии, до тех пор пока блокировка не будет снята. Для
снятия пессимистической блокировки разработчик мо-
жет использовать метод объекта Разблокировать!).
Также существует метод объекта Заблокирован!), который
позволяет определить, заблокированы ли данные объекта
базы данных этим объектом встроенного языка.
При работе с пессимистической блокировкой из встроен-
ного языка следует помнить о том, что блокировка уста-
навливается при выполнении метода конкретного экзем-
пляра объекта встроенного языка. Соответственно, снять
блокировку можно, только выполнив соответствующий
метод этого же экземпляра объекта.
Если необходимо узнать, установлена ли блокировка на
данные объекта или нет, нужно использовать метод Забло-
кировать!). В случае если блокировка уже установлена ка-
ким-либо объектом встроенного языка, будет вызвано ис-
ключение (листинг 4.6).
Листинг 4.6. Пример проверки пессимистической
блокировки
0бъектЭкземлляр1 = Справочники.Номенклатура.НайтиПоКоду(1).
ПолучитьОбъектО;
0бъектЭкзенпляр2 = Справочники.Номенклатура.НайтиПоКоду(1).
ПолучитьОбъектО:
0бъектЭкземпляр1.Заблокировать();
Попытка
0бъектЭкземпляр2.Заблокировать();
Исключение
Сообщить("Данные объекта уже заблокированы");
КонецПопытки;
В приведенном примере создается два экземпляра одного
и того же объекта — СправочникОбъект.Номенклатура, кото-
рые содержат данные элемента справочника Номенклатура,
имеющего код 1. После этого первый экземпляр объекта
устанавливает пессимистическую блокировку на данные
объекта. Если в этой ситуации для второго экземпляра
объекта выполнить метод Заблокировано, то он вернет зна-
чение Ложь, так как блокировка была наложена первым эк-
земпляром объекта. Однако если, в свою очередь, попы-
таться выполнить метод Заблокировать О и для второго
экземпляра объекта, то будет выдано сообщение о невоз-
можности установить блокировку (так как данные объек-
та уже заблокированы первым экземпляром объекта).
Оптимистическая блокировка
Оптимистическая блокировка запрещает запись объекта
в базу данных, если после считывания объекта он был из-
менен в базе данных (рис. 4.17).
Рис. 4.17. Оптимистическая блокировка
Строго говоря, оптимистическая блокировка представляет
собой проверку, которая выполняется перед записью объ-
екта в базу данных. Когда программный объект считыва-
ет данные из базы данных, в числе прочего считывается и
версия объекта, хранящегося в базе данных. Предполо-
жим, что до начала редактирования данных (до установ-
ки пессимистической блокировки) данные объекта в базе
данных были изменены (например, другим пользовате-
лем). В этом случае номер версии объекта, хранящийся в
базе данных, также изменится. При попытке первого
пользователя записать или заблокировать этот объект
будет выполнена проверка соответствия версии объекта,
находящегося в памяти, и версии объекта, хранящейся в
базе данных. Так как версии отличаются, будет выдано
сообщение об ошибке, то есть сработает оптимистическая
блокировка.
Оптимистическая блокировка гарантирует, что если поль-
зователь изменяет объект, то его изменения не «затрут»
изменения, сделанные другими сессиями или другими
программными объектами в этой же сессии.
Объектные блокировки и транзакции
Важным моментом является то, что пессимистическая и оп-
тимистическая блокировки обеспечиваются не средствами
базы данных, а средствами собственного менеджера блоки-
ровок, который работает «над уровнем» базы данных.
По этой причине объектные блокировки абсолютно про-
зрачны для транзакций. Единственная особенность за-
ключается в том, что если пессимистическая блокировка
была установлена в транзакции и в результате был вы-
полнен откат этой транзакции (rollback), то блокировка
будет автоматически снята.
Подробнее о транзакциях можно прочитать в разделе
«Транзакции», с. 70.
Необъектные данные
Модель хранения данных
К необъектным данным в 1 С: Предприятии относятся
данные следующих объектов конфигурации:
♦ регистр сведений;
♦ регистр накопления;
♦ регистр бухгалтерии;
♦ регистр расчета;
♦ перерасчет;
♦ последовательность;
♦ константа.
Необъектные данные с точки зрения 1С:Предприятия
представляют собой некоторый набор записей, которые
хранятся в таблице. Каждая из этих записей полностью
описывается значениями своих полей. Для системы эти
записи не обладают какой-либо значимостью, кроме того,
что в их полях содержатся некоторые значения. Запись
можно удалить, а затем создать новую, с такими же значе-
ниями полей. Состояние базы данных при этом не изме-
нится (с точки зрения логики прикладного решения). Это
принципиально отличает необъектные данные от объект-
ных: объект нельзя создать дважды, он ценен сам по себе,
самим фактом своего существования.
Второе важное отличие заключается в том, что, изменив
значения полей записи, мы получаем другую запись, в то
время как изменение значений полей объекта не влечет за
собой появление нового объекта. Объект всегда обладает
некоторой «самостью», которая не зависит от значений
его полей.
Большинство необъектных сущностей конфигурации име-
ют общий порядок работы с данными. Из всей совокупно-
сти необъектных сущностей выделяются только констан-
ты: для каждой константы в базе данных хранится одно
значение. Поэтому в дальнейшем мы их рассматривать не
будем; работа с ними не вызывает сложностей.
Подчинение регистратору
Важным свойством всех записей является их подчинение
регистратору. Регистратор — это некоторый документ,
с которым связаны записи необъектных данных. Не может
существовать записей, не относящихся к какому-либо ре-
гистратору. Исключение составляет лишь регистр сведе-
ний, когда для него выбран независимый режим записи
(без подчинения регистратору). Поэтому любая запись
всегда содержит обязательное поле Регистратор (рис. 4.18).
Записи, относящиеся к одному регистратору, называются
движениями этого регистратора. Движения не являются
частью владеющего ими документа, при записи и чтении
документа они не записываются и не считываются. Одна-
ко они тесно связаны с ним.
Движения могут создаваться при проведении документа,
могут удаляться при отмене проведения документа. Кро-
ме этого, при удалении документа его движения всегда
удаляются. Таким образом, время жизни записей опреде-
ляется их регистратором: если регистратора нет, то и нет
смысла в существовании его движений. Даже в том слу-
чае, когда записи создаются без непосредственного уча-
стия регистратора, они все равно обязательно должны
быть подчинены какому-либо документу; запись нельзя
Наличие или отсутствие движений не связано с прове-
денностью регистратора или с пометкой его на удаление:
непроведенный документ может иметь движения, прове-
денный документ может не иметь движений, помеченный
на удаление документ также может иметь движения. Та-
кой подход позволяет реализовывать в системе ЮПред-
приятие различные способы регистрации изменений
в учетных механизмах (регистрах).
Например, движения документа могут редактироваться
непосредственно в самом документе, и в этом случае по-
нятие проведения документа просто не имеет смысла. Та-
кой прием используется при автоматизации бухгалтер-
ских задач, для ручного ввода проводок.
Также дата движений документа не связана жестко с да-
той регистратора. Например, один и тот же документ мо-
жет иметь движения разными датами. Эта возможность
используется, например, при автоматизации задач плани-
рования, для ввода тех или иных планируемых в будущем
значений.
Наиболее простой моделью использования регистров яв-
ляется создание движений в обработчике проведения ре-
гистратора. В этом случае вся остальная логика работы
будет поддерживаться системой автоматически. Другие
варианты взаимодействия движений и регистратора сле-
дует разрабатывать и описывать самостоятельно, в зави-
симости от конкретной прикладной задачи.
Уникальность записей
Для каждого объекта метаданных в системе определен
ключ записи. Данные объекта конфигурации не могут со-
держать записи с одинаковыми значениями ключа записи.
Ключ записи формируется, как правило, из значений не-
скольких полей объекта конфигурации. Для разных объ-
ектов конфигурации состав ключа записи отличается,
кроме этого, он может быть различным для одного и того
же объекта конфигурации, в зависимости от его свойств.
Для всех необъектных сущностей, подчиненных регист-
ратору, ключ записи включает ссылку на регистратор и
номер строки. Номер строки собственно и используется
для обеспечения уникальности записей, а также для упо-
рядочивания записей в пределах регистратора. Кроме
этого, в состав ключа записи могут входить и другие
поля, например период, измерения регистра — для необъ-
ектных сущностей, не подчиненных регистратору.
Наличие уникального ключа требуется системе для реше-
ния различных задач. Например, это позволяет позицио-
нироваться в табличном поле на некоторую запись.
Набор записей
По аналогии с объектными данными, изменение которых
возможно только при помвщи типов объектов, наборы за-
писей используются для модификации необъектных дан-
ных: они позволяют читать, модифицировать и удалять
необъектные данные. По своей сути набор записей пред-
ставляет собой коллекцию отдельных записей, принадле-
жащих некоторому объекту конфигурации.
В зависимости от объекта конфигурации набор записей
может содержать только некоторые или же все записи,
принадлежащие этому объекту конфигурации. Для ука-
зания того, какие именно записи должны входить в набор
записей, используется его свойство Отбор. Элементы от-
бора в наборе записей для того или иного объекта конфи-
гурации создаются платформой; разработчик не имеет
возможности добавлять собственные элементы отбора, но
может использовать существующие, устанавливая для
них условия равенства нужному значению. В табл. 4.1
представлен состав отбора в наборе записей для различ-
ных объектов конфигурации.
Таблица 4.1. Поля, по которым устанавливается отбор
Объект конфигурации Поля, по которым устанавливается отбор
Регистр сведений (подчиненный регистратору) Регистратор
Регистр сведений (непериодический, независимый) Набор измерений
Регистр сведений ( периодический, независимый) Период и набор измерений
Регистр накопления Регистратор
Регистр бухгалтерии Регистратор
Регистр расчета Регистратор и набор измерений
Перерасчет Объект перерасчета (регистра- тор регистра расчета) и набор измерений перерасчета
Последовательность Регистратор
Существует следующая особенность работы системы с на-
борами записей: если среди элементов отбора существует
отбор по регистратору, то он должен обязательно быть ус-
тановлен, иначе при записи такого набора будет выдано
сообщение об ошибке. Отсюда следует, что для большин-
ства объектов конфигурации, которые хранят необъектные
данные, допускается модификация этих данных только час-
тями, «гранулами» — наборами записей, относящихся к
определенному регистратору (или более мелкими, если
есть возможность установки других отборов). Наряду с
этим для независимых регистров сведений допускается
модификация сразу всех данных, хранящихся в регистре
(если ни одно из условий отбора не задано).
Номенклатура Характеристика Комплектующая Количество Отбор: истика = DURON 1600
Компьютер AMD К7-2200 Клавиатуре 1 Характер
Компьютер AMD К7-2200 Мышь 1
Компьютер AMD К7-2200 Системный блок 1
Компьютер AMD K7-2200 Монитор 1 >-► Отбор не установлен Компьютер DURON 1600 Монитор 2
Компьютер DURON 1600 Клавиатура 1 Компьютер DURON 1600 Модем 1
Компьютер DURON 1600 Мышь 1 Запись с замещением
Компьютер DURON 1600 Системный блок 1
Компьютер DURON 1600 Монитор 1
Номенклатура Характерист Комплектующая Количество
Компьютер AMD К7-2200 Клавиатура 1
Номенклатура Характеристика Комплектующая Количество Компьютер AMD К7-2200 Мышь 1
Компьютер AMD K7-2200 Клавиатура 1 Компьютер AMD K7-2200 Системный блок 1
Компьютер AMD K7-2200 Мышь 1 Компьютер AMD K7-2200 Монитор 1
Компьютер AMD K7-2200 Системный б лок 1 Компьютер DURON 1600 Клавиатура 1
Компьютер AMD K7-2200 Монитор 1 Компьютер DURON 1600 Мышь 1
Компьютер DURON 1600 Клавиатуре 1 - Отбор Компьютер DURON 1600 Системный блок 1
Компьютер DURON 1600 Мышь 1
Компьютер DURON 1600 Монитор 1
Компьютер DURON 1600 Системный блок 1
Компьютер DURON 1600 Монитор 1
Номенклатура Характерист . Комплектующая Количество
Номенклатура Характеристика Комплектующая Количество
Компьютер AMD K7-2200 Клавиатура 1
Компьютер AMD K7-2200 Клавиатура 1
Компьютер AMD K7-2200 Мышь 1
Компьютер AMD K7-2200 Мышь 1
Компьютер AMD K7-2200 Системный блок 1 Отбор Номенклатура = Компьютер Комплектующая = Мышь Компьютер AMD K7-2200 Системный блок 1
Компьютер AMD K7-2200 Монитор 1 Компьютер AMD K7-2200 Монитор 1
Компьютер DURON 1600 Клавиатура 1 Компьютер DURON 1600 Монитор 2
Компьютер DURON 1600 Мышь 1 Компьютер DURON 1600 Модем 1
Компьютер DURON 1600 Системный блок 1 добавлением
Компьютер DURON 1600 Монитор 1 Рис. 4.21. Запись с
Набор записей
База данных
до записи
База данных
после записи
Рис. 4.19. Примеры наборов записей
Регистратор Физическое лицо Организация Результат
Отражение зарплаты 04-00001 от 31.01.2005 Алинов Станислав Иванович ЗАО Станкоимпорт 9840
Отражение зарплаты СИ-00001 от 31.01.2005 Васьков Ринат Леонтьевич ЗАО Станкоимпорт 1754,67
Отражение зарплаты СИ-00001 от 31.01.2005 Гостев Андриан Вячеславович ЗАО Станкоимпорт 6820
Отражение зарплаты ДС-00001 от 31.01.2005 Васьков Ринат Леонтьевич ООО Домстрой 2520
Сдельный наряд СИ-00001 ат 26.01.2005 Рулев Александр Алексеевич ЗнО Станкоимпорт #200
Сдельный наряд СИЧЮ001 от 26.01.2005 Матавии Михаил Якубович ЗАО Станкоимпорт 2800
дельный наряд 04-00001 от 6.01.2005 Петряков Искандер Якубович ЗАО Станкоимпорт 9®
Сдельный наряд ДС-00002 от 26-01.2005 Ханафеев Виталий Зиновьевич ООО Домстрой 3400
Отбор
Характеристика - DURON 1600
Компьютер DURON 1600 Модем 1
Компьютер DURON 1600 Сканер 1
Компьютер DURON 1600 Принтер 1
Запись с
добавлением
Набор записей
Отбор:
Регистратор =
Сдельный наряд
СИ-00001 от
26.01.2005
Рис. 4.20. Примеры наборов записей
Номенклатура Характерист. Комплектующая Количество
Компьютер AMD К7-2200 Клавиатура 1
Компьютер AMD К7-2200 Мышь 1
Компьютер AMD К7-2200 Системный блок 1
Компьютер AMD K7-2200 Монитор 1
Компьютер DURON 1600 Клавиатура 1
Компьютер DURON 1600 Мышь 1
Компьютер DURON 1600 Системный блок 1
Компьютер DURON 1600 Монитор 1
Б аза данных
до записи
Регистратор
Сдельный нар
СИ-00001 О1
Алексеевич
Номенклатура Характерист Комплектующая Количество
Компьютер AMD К7-2200 Клавиатура 1
Компьютер AMD К7-2200 Мышь 1
Компьютер AMD К7-2200 Системный блок 1
Компьютер AMD K7-2200 Монитор 1
Компьютер DURON 1600 Клавиатура 1
Компьютер DURON 1600 Мышь 1
Компьютер DURON 1600 Системный блок 1
Компьютер DURON 1600 Монитор 1
Компьютер DURDN 1600 Модем 1
Компьютер DURON 1600 Сканер 1
Компьютер DURON 1600 Принтер 1
База данных
после записи
Рис. 4.22. Запись с добавлением
Например, для независимого регистра сведений Комплек-
тующие номенклатуры набор записей может включать в се-
бя как все записи регистра (если отбор не установлен),
так и лишь некоторые его записи (рис. 4.19).
В то же время для регистра расчета Основные начисления,
у которого обязательно должен быть установлен отбор по
регистратору, набор записей может включать в себя мак-
симум все записи, принадлежащие одному регистратору,
или некоторое их подмножество (рис. 4.20).
Отличительной особенностью наборов записей является
то, что для них не существует понятия удаления. Набор
записей можно только записать, причем запись может
быть выполнена либо с замещением существующих запи-
сей, удовлетворяющих отбору, либо с добавлением новых
записей к существующим.
При записи с добавлением новые записи будут добавле-
ны к существующим (рис. 4.21).
При записи с замещением существующие записи будут
заменены новыми (рис. 4.22).
Таким образом, для удаления записей необъектных дан-
ных необходимо просто записать с замещением пустой
набор записей (то есть набор записей, не содержащий ни
одной записи).
Набор записей представляет собой коллекцию объектов,
имеющих тип записи. Перебрать все записи, входящие в
набор записей, можно с помощью конструкции Для Каждо-
го Из ... Цикл. Тип записи используется только в наборах
записей. Отдельно от наборов записей этот тип не ис-
пользуется. Основное назначение этого типа — предоста-
вить доступ к значениям полей записи.
Интерактивное редактирование
наборов записей
Для необъектных данных не существует механизма, ана-
логичного объектным блокировкам (оптимистической
и пессимистической). Поэтому при использовании набо-
ра записей для интерактивного редактирования следует
учитывать, что в период после считывания данных из
базы данных и перед записью их обратно в базу данных
они могут быть изменены в базе данных другой сессией
или другим набором записей в этой же сессии.
Таким образом, может возникнуть ситуация, когда изме-
нения, внесенные одним пользователем, могут быть поте-
ряны в результате того, что второй пользователь переза-
пишет их старыми данными.
Система типов
Типы значений
и типы данных
Прикладное решение ЮПредприятия оперирует раз-
личными величинами: числами, символами, объектами.
Каждая величина имеет тип. Тип величины определяет
возможные значения и набор определенных для них опе-
раций.
Существуют типы, определенные на уровне системы,
и типы, создаваемые в конкретном прикладном решении.
Например, на уровне системы определены примитивные
типы, такие как Строка, Число, Булево и т. д. Также на уров-
не системы определены и другие типы, которые могут
быть использованы в прикладном решении, например
универсальные коллекции значений (Массив, Структура,
СписокЭначений), общие типы (ТекстовыйДокумент, Таблич-
ныйДокунент, ПостроительОтчета, АнализДанных) и др. Полный
перечень типов значений, которые может использовать
система ЮПредприятие, приведен в описании встроен-
ного языка и в синтакс-помощнике.
Переменные встроенного языка ЮПредприятия не ти-
пизированы. Это значит, что тип переменной определяет-
ся типом того значения, которое хранится в переменной в
данный момент. Таким образом, в произвольные моменты
работы прикладного решения переменная может иметь
различные типы значения. Подробнее о типах значений
можно прочитать в разделе «Типы значений», с. 48.
В то же время данные ЮПредприятия существуют не
только в оперативной памяти компьютера, где они содер-
жатся в объектах встроенного языка, но и в базе данных,
где осуществляется долговременное хранение этих дан-
ных.
База данных представляет собой совокупность некоторо-
го количества таблиц, создаваемых в соответствии со
структурой метаданных прикладного решения. Таблицы
базы данных состоят их полей, и для каждого поля обяза-
тельно должен быть указан тип значений, которые могут
храниться в этом поле. По этой причине все объекты ме-
таданных, которые «отвечают» за создание тех или иных
полей в базе данных, должны иметь совершенно опреде-
ленный тип. Такими объектами являются, например, рек-
визиты, измерения, ресурсы и т. д.
Для того чтобы указать тип объекта метаданных, «отве-
чающего» за создание того или иного поля базы данных,
в системе 1 С: Предприятие используются не типы значе-
ний, а более сложное понятие — тип данных.
Такой подход позволяет, с одной стороны, изолировать
разработчика от конкретного хранилища данных, а с дру-
гой стороны — сделать работу с данными значительно бо-
лее гибкой.
Отличие типа данных от типа значения заключается в
том, что тип данных является характеристикой, которая
может содержать описание как одного, так и нескольких
типов значений. В результате у разработчика появляются
две важные возможности:
♦ уточнение некоторых примитивных типов значений.
Например, можно указать, что реквизит Количество бу-
дет содержать не просто числовые значения, а неотри-
цательные числовые значения с количеством разрядов
не более 15 и дробной частью из 3 разрядов;
♦ указание одновременно нескольких возможных типов
значений. Например, можно указать, что реквизит Сдел-
ка может содержать ссылку как на счет, выставленный
покупателю, так и на счет, выставленный поставщику.
В результате в реквизите Сделка смогут одновременно
храниться как значения одного, так и другого типа. При
этом тип данных этого реквизита будет всегда одним и
тем же, но тип значения этого реквизита в каждый кон-
кретный момент времени будет определяться типом
значения, которое в нем хранится.
Типы данных используются в системе ЮПредприятия
не только в части, связанной с базой данных, но и в ин-
терфейсной части. Так, например, типы данных должны
быть определены для всех реквизитов форм и для всех
элементов управления, расположенных в форме.
Кроме этого, некоторые объекты встроенного языка, в силу
специфики своего использования, также могут потребо-
вать указания типа данных, которые в них хранятся. На-
пример, указание типа данных может использоваться для
списка значений, для колонок таблицы значений и дерева
значений.
Подробнее о типах данных можно прочитать в разделе
«Типы данных», с. 66.
Типы значений
Примитивные типы
Число
Числовой тип предназначен для представления десятич-
ных чисел. Максимально допустимая разрядность числа,
которое может быть сохранено в базе данных, составляет
32 знака, включая десятичную точку. Для числовых зна-
чений, хранящихся в памяти (являющихся, например,
значением некоторой переменной) разрядность не огра-
ничена.
Литерал значения типа Число
Конкретные значения числового типа во встроенном язы-
ке и языке запросов могут быть заданы литералом, кото-
рый представляет собой набор цифр, написанных непо-
средственно в тексте модуля. Этот набор цифр может
начинаться с символов + («плюс») или - («минус»), обо-
значающих знак числа. В качестве разделителя целой и
дробной части числа используется символ . («точка»)
(табл. 4.2).
Таблица 4.2. Примеры литералов типа Число
Число Литерал
3874 3874
1475,25 1475.25
Значение типа Число по умолчанию
Для числового типа значением по умолчанию является
значение 0. По умолчанию, если не задан специальный
формат, это значение будет представляться как 0.
Однако некоторые элементы управления, используемые
в интерфейсе системы, имеют другое представление ну-
левого значения, что сделано для более удобного пред-
ставления информации пользователю.
Например, в ячейке табличного поля значение по умол-
чанию числового типа отображается как пустое место
(рис. 4.23).
Такое поведение табличного поля позволяет создать спи-
сок, который легко читается и не содержит лишней ин-
формации. Однако если есть необходимость указывать
для нулевых значений определенное представление, то
это можно выполнить, используя свойство Формат соответ-
ствующей колонки табличного поля (в приведенном при-
мере — колонки Значение) (рис. 4.24).
Рис. 4.23. Представление значения типа Число по умолчанию
в табличном поле
Рис. 4.24. Установка формата колонки табличного поля
Для колонки табличного поля форматная строка поддер-
живает параметр ЧН, который задает представление нуле-
вого значения. В результате приведенная выше таблица
будет выглядеть, например, следующим образом (рис. 4.25).
Рис. 4.25. Представление нулевого значения в табличном поле
Аналогичного результата можно добиться средствами
встроенного языка (листинг 4.7).
Листинг 4.7. Установка формата колонки
табличного поля
ЭлементыФормы.ТабличноеПоле1.Колонки.
Значение.Формат - ”ЧН=’- -
При задании представления нулевого значения для ко-
лонки табличного поля следует иметь в виду, что таблич-
ное поле обрежет концевые пробелы при выводе заданно-
го представления нулевого значения.
В поле ввода значение по умолчанию числового типа ото-
бражается в зависимости от разрядности дробной части,
заданной при указании числового типа данных этого
поля ввода (подробнее о числовых типах данных можно
прочитать в разделе «Числовые типы данных», с. 66).
Если количество разрядов дробной части равно нулю, то
будет отображаться как 0, если количество разрядов дроб-
ной части отлично от нуля, то будет отображено как 0,000
(количество нулей после запятой будет соответствовать
количеству разрядов дробной части) (рис. 4.26).
Рис. 4.26. Представление значения типа Число по умолчанию
в поле ввода
В отличие от колонки табличного поля, для поля ввода
нельзя задать собственное представление нулевого значе-
ния.
Операции со значениями типа Число
Для значений типа Число определены арифметические
операции (табл. 4.3).
Для значений типа Число определены логические опера-
ции (табл. 4.4).
Преобразование значений типа Число
Неявное преобразование. Рассмотрим пример, когда пере-
менная, указанная в качестве значения логического выра-
жения в операторе цикла, по каким-либо причинам имеет
тип Число (листинг 4.8).
Листинг 4.8. Неявное преобразование значения типа
Число
Условие = 22;
Если Условие Тогда
КонецЕсли;
В этом случае будет выполняться неявное преобразова-
ние значения типа Число к нужному типу. Такое преобра-
зование в ряде случаев может быть выполнено системой,
если же такое преобразование невозможно — будет вы-
звана ошибка исполнения.
1. Неявное преобразование к типу Строка. Любое значение
типа Число может быть преобразовано к типу Строка. Это
позволяет всегда иметь возможность получения пред-
ставления такого значения (листинг 4.9).
Листинг 4.9. Неявное преобразование значения
типа Число к значению типа Строка
Переменная = 156935.785;
Сообщить(Переменная);
Результатом выполнения этих операторов будет пред-
ставление числа: 156 935,785. Преобразование будет вы-
полняться в соответствии с текущими региональными
настройками информационной базы, например, как в
данном случае, группы разрядов будут отделены друг от
друга символом пробела.
Таблица 4.3. Арифметические операции для типа Число
Операция Операнды Результат
Сложение Число + Число Сумма операндов
Вычитание Число - Число Разность операндов
Умножение Число * Число Произведение операндов
Деление Число / Число Частное операндов. Если второй операнд имеет значение 0 — будет вызвана ошибка исполнения
Остаток от деления Число % Число Остаток от деления первого операнда на второй. Если второй операнд имеет значение 0 — будет вызвана ошибка исполнения
Унарный минус - Число Изменение знака числа
Таблица 4.4. Логические операции для типа Число
Операция Операнды Результат
Больше Число > Число Истина, если первый операнд больше второго. В противном случае Ложь
Больше или равно Число >= Число Истина, если первый операнд больше либо равен второму. В противном случае Ложь
Равно Число = Число Истина, если первый операнд равен второму. В противном случае Ложь
Не равно Число <> Число Истина, если первый операнд не равен второму. В противном случае Ложь
Меньше Число < Число Истина, если первый операнд меньше второго. В противном случае Ложь
Меньше или равно Число <= Число Истина, если первый операнд меньше либо равен второму. В противном случае Ложь
2. Неявное преобразование к типу Булево. При выполне-
нии булевых операций или при вычислении логических
выражений любое ненулевое значение приводится к зна-
чению Истина. Значение, равное нулю, приводится к зна-
чению Ложь (листинг 4.10).
Листинг 4.10. Неявное преобразование значения
типа Число к значению типа Булево
Условие = 22;
Если Условие Тогда
Сообщить("Условие истинно.");
иначе
Сообщить("Условие ложно."):
КонецЕсли:
В приведенном примере будет получено сообщение об
истинности условия, поскольку при вычислении логиче-
ского выражения значение переменной Условие будет
преобразовано к типу Булево, результатом чего будет зна-
чение Истина.
Также, например, при выполнении булевой операции НЕ
в следующем примере значение переменной Условие бу-
дет сначала преобразовано к типу Булево (значение Исти-
на), а затем уже выполнена операция НЕ. В результате
в окно сообщений будет выведено ложь (листинг 4.11).
Листинг 4.11. Неявное преобразование значения
типа Число к значению типа Булево
Условие = 22:
Сообщить(НЕ Условие):
3. Неявное преобразование в операциях сравнения. Поря-
док неявного преобразования типов в операциях сравне-
ния несколько отличается от описанного выше. Если в
операции сравнения один из операндов имеет тип Число,
а другой — Булево, то значение типа Булево будет приво-
диться к типу Число, а затем будет выполнено сравнение.
Например, в результате выполнения следующего кода
(листинг 4.12) будет получено сообщение о ложности ус-
ловия, поскольку булев операнд будет приведен к типу
Число (значение 1), а затем уже будет выполнено сравне-
ние.
Листинг 4.12. Неявное преобразование в операции
сравнения
Условие = 22;
Если Истина = Условие Тогда
Сообщить ("Условие истинно.''):
иначе
Сообщить("Условие ложно."):
КонецЕсли;
Явное преобразование. Встроенный язык позволяет вы-
полнить явное преобразование значения типа Число к ти-
пам Булево и Строка.
1. Преобразование к типу Булево. Для этого используется
встроенная функция БулевоО, в качестве параметра кото-
рой передается преобразуемое число. Значение 0 преоб-
разуется в Ложь, все остальные значения преобразуются в
значение Истина. Например, в результате выполнения опе-
ратора (листинг 4.13) будет получено сообщение истина.
Листинг 4.13. Явное преобразование к типу Булево
Сообщить(Булево(34.456));
А в результате выполнения следующего оператора (лис-
тинг 4.14), будет выдано сообщение ложь.
Листинг 4.14. Явное преобразование к типу Булево
Сообщить(Булево(О)):
2. Преобразование к типу Строка. Любое числовое значе-
ние может быть преобразовано к типу Строка при помощи
встроенной функции СтрокаО. Результатом такого преоб-
разования будет строковое представление числа, полу-
ченное в соответствии с текущими региональными уста-
новками информационной базы.
Например, результатом выполнения оператора (лис-
тинг 4.15) будет сообщение 26 475 834,456, в котором ис-
пользуются, в данном случае, разделители групп разрядов
(символ «пробел») и десятичный разделитель (символ
«запятая»).
Листинг 4.15. Явное преобразование к типу Строка
Сообщить(Строка(26475834.456));
Строка
Строковый тип предназначен для представления строк
в формате Unicode произвольной длины.
Литерал значения типа Строка
Для того чтобы задать конкретные значения строкового
типа, во встроенном языке и языке запросов использует-
ся литералы строкового типа. Они представляют собой
набор символов, заключенных в кавычки (табл. 4.5).
Таблица 4.5. Примеры литералов типа Строка
Строка Литерал
книга "книга"
проверка работы "проверка работы"
Если в строке необходимо задать символ кавычка ("), то
записываются две кавычки подряд (табл. 4.6).
Таблица 4.6. Пример литерала типа Строка
Строка Литерал
фирма "Ваш сад” фирма Ваш сад
Наряду с однострочными литералами во встроенном язы-
ке могут быть использованы строковые литералы, состоя-
щие из нескольких строк. Для обозначения таких литера-
лов используется два различных способа записи.
Во-первых, отдельные строки могут быть заключены в ка-
вычки. В этом случае между ними не должно находиться
никаких символов кроме пробелов, переводов строки и
комментариев. Например, строка Внимание! В документе не
могут присутствовать строки с нулевым количеством! может
быть записана следующим образом (листинг 4.16).
Листинг 4.16. Пример литерала типа Строка
Сообщить("Внимание! "
"В документе не могут присутствовать строки"
"с нулевым количеством!");
Во-вторых, указание многострочных литералов осущест-
вляется с использованием символа «|». В этом случае ка-
вычки используются только в начале и конце литерала,
а символ «|» размещается в начале каждой новой строки
(листинг 4.17).
Листинг 4.17. Пример литерала типа Строка
Сообщить (" Внимание!
|В документе не могут присутствовать строки
|с нулевым количеством!");
Результатом работы как первого, так и второго оператора
будет следующее сообщение:
Внимание!
В документе не могут присутствовать строки
с нулевым количеством!
Значение типа Строка по умолчанию
Для строкового типа значением по умолчанию является
пустая строка (литерал Это значение не имеет пред-
ставления, иначе говоря, оно не отображается. В некото-
рых случаях, например при вычислении значений в от-
ладчике, для наглядности в качестве представления этого
значения может использоваться его литерал
Операции со значениями типа Строка
Для значений типа Строка определена операция конкате-
нации (табл. 4.7).
Для значений типа Строка определены логические опера-
ции (табл. 4.8).
Таблица 4.7. Операция конкатенации
Операция Операнды Результат
Конкатенация Строка + Строка Строка, являющаяся соединением первой и второй строки. Длина результирующей строки равна сумме длин соединяемых строк
При выполнении логических операций больше, больше
или равно, меньше, меньше или равно существует особен-
ность, связанная с тем, что система 1С:Предприятие по-
зволяет создавать прикладные решения на различных
языках.
Для того чтобы прикладное решение максимально соот-
ветствовало национальным особенностям, принятым в
конкретной стране, есть возможность установить регио-
нальные установки информационной базы, соответст-
вующие некоторому языку и стране. Региональные уста-
новки позволяют задать формат представления чисел,
дат, времени, логических значений и, что важно в данном
случае, определяют порядок сортировки строковых зна-
чений, принятый в конкретном регионе.
Внутри платформы 1С:Предприятие 8.0 работа строками
ведется только в UNICODE и строковые данные в базах
данных также сохраняются в UNICODE. Стандартом оп-
ределен некоторый генеральный порядок сортировки для
UNICODE. Но он подходит не для всех языков. Поэтому
для некоторых языков в этот генеральный порядок внесе-
ны минимальные изменения для обеспечения соответст-
вия конкретному языку.
В результате этого, например, для русских и латыш-
ских региональных установок будет различный порядок
следования строк при сортировке их по возрастанию
(табл. 4.9).
Таблица 4.8. Логические операции
Операция Операнды Результат
Больше Строка > Строка Истина, если первая строка больше второй. В противном случае Ложь
Больше или равно Строка >= Строка Истина, если первая строка больше либо равна второй. В противном случае Ложь
Меньше Строка < Строка Истина, если первая строка меньше второй. В противном случае Ложь
Меньше или равно Строка <= Строка Истина, если первая строка меньше либо равна второй. В противном случае Ложь
Равно Строка = Строка Истина, если первая строка равна второй. В противном случае Ложь
Не равно Строка <> Строка Истина, если первая строка не равна второй. В противном случае Ложь
Таблица 4.9. Порядок следования строк
для различных региональных установок
Русский (Россия) Латышский (Латвия)
Аса АсЬ
АсЬ Аса
Такой порядок соответствует принятому в России и Лат-
вии алфавиту.
Поскольку сортировка строковых значений выполняется
на основе сравнения их друг с другом, то один и тот же
оператор (листинг 4.18) при русских региональных уста-
новках будет давать результат Истина, а при латышских —
nepareizs, что значит «ложь».
Листинг 4.18. Сравнение строк
Результат = "асЬ" > "аса";
Таким образом, результат выполнения логических опера-
ций над строковыми значениями будет зависеть не толь-
ко от самих операндов, участвующих в выражении, но и
от региональных установок информационной базы, в ко-
торой выполняется эта операция.
Преобразование значений типа Строка
Неявное преобразование. При выполнении различных опе-
раторов кода могут возникать ситуации, когда значения
типа Строка не подходят для выполнения данных опера-
ций. Например, если при выполнении следующего опера-
тора, переменная Строка будет иметь значение 25 (лис-
тинг 4.19).
Листинг 4.19. Неявное преобразование значения
типа Строка
Строка = "25";
Результат = 35 + Строка;
Сообщить(Результат);
В этом случае будет выполняться неявное преобразова-
ние значения типа Строка к нужному типу.
Такое преобразование в ряде случаев может быть выпол-
нено системой, если же такое преобразование невозмож-
но — будет вызвана ошибка исполнения.
1. Неявное преобразование к типу Число. Если выполнить
приведенный выше пример, то строка 25 будет преобразо-
вана к типу Число и в окно сообщений будет выведено 60.
Однако следует заметить, что преобразование значения
типа Строка к типу Число будет выполняться только тогда,
когда подобное преобразование осмысленно.
Например, если значение переменной Строка будет равно
а25, то в этом случае преобразование уже выполнено не
будет и будет вызвано исключение.
2. Неявное преобразование к типу Булево. Данное преоб-
разование также выполняется лишь тогда, когда такое
преобразование имеет смысл.
Прежде всего, к типу Булево всегда будут преобразованы
русскоязычные и англоязычные представления булевых
значений: истина и ложь, true и false.
Например, рассмотрим выполнение следующего фраг-
мента кода (листинг 4.20).
Листинг 4.20. Неявное преобразование к типу Булево
Если "истина" тогда
Сообщить("Истина"):
Иначе
СообщитьС'Ложь");
КонецЕсли:
Если "false" тогда
Сообщить("Истина”);
Иначе
СообщитьС'Ложь");
КонецЕсли;
В результате в окно сообщений будет выведен текст:
Истина
Ложь
Однако, кроме этого, к булевым значениям будут преоб-
разовываться также строковые значения, соответствую-
щие представлению булевых значений для языка, вы-
бранного в региональных установках информационной
базы. Например, если в региональных установках инфор-
мационной базы выбрать Язык (Страна) равным Чешский
(Чехия), то тогда следующий код (листинг 4.21) будет вы-
полнен без ошибок и в окно состояния будет выведено:
Ложь.
Листинг 4.21. Неявное преобразование к типу Булево
Если " пергаvda" тогда
СообщитьС'Истина");
Иначе
СообщитьС'Ложь"):
КонецЕсли;
Если этот же код попытаться выполнить с региональ-
ными установками Грузинский (Грузия), то будет вызва-
но исключение, в результате того, что значение nepravda
не может быть преобразовано к типу Булево. Если же в
этой ситуации строку nepravda заменить на Ogqjatno, что
значит «ложь» по-грузински, то пример (листинг 4.22)
отработает без ошибок и в окно сообщений будет выве-
дено: Ложь.
Листинг 4.22. Неявное преобразование к типу Булево
Если тогда
Сообщить("Истина");
Иначе
СообщитьС'Ложь"):
КонецЕсли;
Явное преобразование. Строковое значение может быть
преобразовано к типам Число или Дата.
1. Преобразование к типу Число. Встроенный язык позво-
ляет выполнить данное преобразование с помощью встро-
енной функции ЧислоО. При этом будут преобразованы
только те строки, которые представляют собой правиль-
ное строковое представление литерала численного типа.
Например, может быть выполнено преобразование стро-
ки 1125.78 к числу 1125.78 (листинг 4.23).
Листинг 4.23. Явное преобразование к типу Число
Сообщить(Число("1125.78"));
Следует заметить, что если в строке в качестве разделите-
ля целой и дробной части будет использоваться не точка,
а запятая, преобразование также будет выполнено (лис-
тинг 4.24).
Листинг 4.24. Явное преобразование к типу Число
Сообщить(Число("1125,78")):
2. Преобразование к типу Дата. Для этого используется
встроенная функция Дата(). Она позволяет преобразовать
строку, которая представляет собой части даты, записан-
ные в определенном порядке: год, месяц, день, час, мину-
та и секунда.
Например, для того чтобы получить дату 15 апреля 2003
года 17 часов 45 минут 34 секунды, преобразуемая строка
должна иметь вид 20030415174534 (листинг 4.25).
Листинг 4.25. Преобразование к типу Дата
Сообщить(Дата("20030415174534"));
В результате выполнения приведенного кода будет полу-
чена нужная дата: 15.04.2003 17:45:34.
Дата
Тип Дата предназначен для представления значения даты
и времени с точностью до секунды. Минимальным значе-
нием типа Дата является дата 01 января 0001 года 00 часов
00 минут 00 секунд.
Литерал значения типа Дата
Конкретные значения типа Дата могут быть заданы лите-
ралом, который представляет собой последовательность
цифр, заключенных в одинарные кавычки. Последова-
тельность цифр представляет собой части даты в следую-
щем порядке: год, месяц, день, час, минута и секунда. Час-
ти даты могут быть отделены друг от друга различными
разделителями; час, минута и секунда могут быть не ука-
заны — в этом случае предполагается, что они равны
нулю (табл. 4.10).
В языке запросов для указания литералов типа Дата ис-
пользуется ключевое слово ДАТАВРЕМЯ, после которого в
скобках последовательно указываются год, месяц, день,
час, минута и секунда. Последние три указывать не обяза-
тельно (табл. 4.11).
Таблица 4.10. Примеры литералов типа Дата
Дата Литерал
15.04.2003 22:45:33 '20030415224533'
15.04.2003 0:00:00 '20030415'
15.04.2003 22:45:33 '2003-04-15 22:45:33'
15.04.2003 22:45:33 '2003/04/15-22/45/33'
Таблица 4.11. Примеры литералов типа Дата
Дата Литерал
15.04.2003 22:45:33 ДАТАВРЕМЯ(2003, 04,15,22,45, 33)
15.04.2003 0:00:00 ДАТАВРЕМЯ(2003, 04,15)
Значение типа Дата по умолчанию
Для типа Дата значением по умолчанию является 01 янва-
ря 0001 года 00 часов 00 минут 00 секунд.
При выводе значения даты по умолчанию она отобра-
жается в соответствии с используемыми региональными
установками (например, для русского языка это будет
01.01.0001 0:00:00).
Однако при выводе значения даты по умолчанию неко-
торые элементы управления она будет представляться
иначе, что обусловлено удобством ввода или отображения.
Например, значение даты по умолчанию в поле ввода бу-
дет отображено в виде символов-разделителей даты, ис-
пользуемых при данных региональных установках. Со-
став разделителей будет определяться составом даты
(Дата и время, Дата, Время), указанным при описании типа
данных, с которыми работает данное поле ввода (рис. 4.27).
Подробнее о типах данных, описывающих значения типа
Дата, можно прочитать в разделе «Типы данных, описы-
вающие значения типа Дата», с. 67.
Рис. 4.27. Пустая дата в поле ввода
Если существует необходимость задания собственного
представления даты по умолчанию, то это можно выпол-
нить, используя свойство Формат поля ввода (рис. 4.28).
В поле ввода форматная строка поддерживает параметр
ДП, который задает представление значения даты по умол-
чанию. В результате приведенный выше пример будет
выглядеть следующим образом (рис. 4.29).
Аналогичного результата можно добиться, используя
средства встроенного языка (листинг 4.26).
При выводе значения даты по умолчанию в табличное
поле она будет отображаться как пустое место, вне зави-
симости от того, какой состав даты установлен при описа-
нии типа данных (рис. 4.30).
Рис. 4.28. Установка формата в поле ввода
Рис. 4.29. Отображение пустой даты в поле ввода
Рис. 4.30. Пустая дата в табличном поле
Листинг 4.26. Установка формата в поле ввода
ЭлементыФормы.ПолеВводаДатаИВремя.
Формат = "ДП='01.01.2003 00:00:00"';
ЭлементыФормы.ПолеВводаДата.Формат = ”ДП='01.01.2003'":
ЭлементыФормы. ПолеВводаВремя. Формат = "ДП='ОО:ОО:ОО"';
Если есть необходимость указывать для значений даты
по умолчанию определенное представление, то это можно
выполнить, используя свойство Формат колонки таблично-
го поля (в приведенном примере — колонки Значение)
(рис. 4.31).
Для колонки табличного поля форматная строка поддер-
живает параметр ДП, который задает представление пус-
той даты. В результате приведенная выше таблица будет
выглядеть, например, следующим образом (рис. 4.32).
Аналогичного результата можно добиться средствами
встроенного языка (листинг 4.27).
Листинг 4.27. Установка формата колонки
табличного поля
ЭлементыФормы.ТабличноеПоле1.Колонки.Значение.Формат =
"ДП='01.01.2003 00:00:00'";
Рис. 4.31. Установка формата для колонки табличного поля
_ □ X
Действия* X1
Значение Н
05.04 2004 5:50:42 определенное значение
01 01 2003 00 СЮ:ОО ".чачение по умолчанию
05 04 2004 00000
опреде пенное значение
Выполнить Закрыть
Рис. 4.32. Представление пустой даты в табличном поле
Операции со значениями типа Дата
Для значений типа Дата определены арифметические опе-
рации (табл. 4.12).
Для значений типа Дата определены логические операции
(табл. 4.13).
Таблица 4.12. Арифметические операции
Операция Операнды Результат
Сложение Дата + Число Дата, увеличенная на количество секунд
Вычитание Дата - Дата Число, соответствующее разнице между двумя датами, измеренной в секундах
Вычитание Дата - Число Дата, уменьшенная на количество секунд
Преобразование значений типа Дата
Неявное преобразование. При выполнении различных опе-
раторов кода могут возникнуть ситуации, когда значения
типа Дата не подходят для выполнения данных операций.
Например, при выводе значений типа Дата может быть
выполнено преобразование к строке (листинг 4.28).
Листинг 4.28. Неявное преобразование значения
типа Дата
ПерененнаяДата = '20030514234512';
Сообщить(ПерененнаяДата);
Таблица 4.13. Логические операции
Операция Операнды Результат
Больше Дата > Дата Истина, если первый операнд больше второго. В противном случае Ложь
Больше или равно Дата >= Дата Истина, если первый операнд больше либо равен второму. В противном случае Ложь
Равно Дата = Дата Истина, если первый операнд равен второму. В противном случае Ложь
Не равно Дата <> Дата Истина, если первый операнд не равен второму. В противном случае Ложь
Меньше Дата < Дата Истина, если первый операнд меньше второго. В противном случае Ложь
Меньше или равно Дата <= Дата Истина, если первый операнд меньше либо равен второму. В противном случае Ложь
Явное преобразование. Явным образом значение типа дата
может быть преобразовано только к строке. Для этого ис-
пользуется встроенная функция СтрокаО, в качестве пара-
метра которой передается преобразуемая дата. Результатом
такого преобразования будет строковое представление
даты, полученное в соответствии с текущими региональ-
ными установками информационной базы.
Например, результатом выполнения оператора (лис-
тинг 4.29) будет сообщение 27.04.2003 12:36:58.
Листинг 4.29. Явное преобразование типа Дата
Сообщить(Строка('20030427123658'));
Для информационной базы, например, с греческими ре-
гиональными установками, результатом выполнения это-
го же оператора будет сообщение 27/4/2003 12:36:58 цц.
Булево
Тип Булево предназначен для представления логических
величин. Он имеет только два значения: Истина и Ложь.
Литерал значения типа Булево
Конкретные значения типа Булево во встроенном языке
и языке запросов задаются литералами (табл. 4.14).
Таблица 4.14. Литералы типа Булево
Значение Литерал
истина Истина или True
ложь Ложь или False
Значение типа Булево по умолчанию
Значением типа Булево по умолчанию является значение
Ложь.
Операции со значениями типа Булево
Для значений типа Булево определены операции сравне-
ния. При сравнении булевых значений считается, что зна-
чение Истина больше, чем значение Ложь (табл. 4.15).
Таблица 4.15. Операции сравнения
Операция Операнды
Больше Булево > Булево
Больше или равно Булево >= Булево
Равно Булево = Булево
Не равно Булево <> Булево
Меньше Булево < Булево
Меньше или равно Булево <= Булево
Для значений типа Булево определены булевы операции
(табл. 4.16).
Таблица 4.16. Булевы операции
Операция Операнды Результат
И Булево И Булево Истина, если оба операнда имеют значение Истина. В остальных случаях Ложь
ИЛИ Булево ИЛИ Булево Ложь, если оба операнда имеют значение Ложь. В остальных случаях Истина
НЕ НЕ Булево Истина, если значение операнда Ложь. В противном случае Ложь
Преобразование значений типа Булево
Неявное преобразование. При выполнении различных опе-
раторов кода могут возникать ситуации, когда значения
типа Булево не подходят для выполнения данных опера-
ций (листинг 4.30).
Листинг 4.30. Неявное преобразование значений типа
Булево
Число = 10;
Булево = Истина;
Сообщить(Число + Булево);
В этом случае может быть выполнено неявное преобразо-
вание значения типа Булево к нужному типу. Если такое
преобразование не может быть выполнено — будет вызва-
на ошибка исполнения.
1. Неявное преобразование к типу Число. Если логика ис-
полнения требует преобразования значения типа Булево к
типу Число, то это преобразование выполняется по сле-
дующим правилам: значение Истина преобразуется к зна-
чению 1, а значение Ложь — к значению 0. Таким образом,
результатом выполнения предыдущего примера (лис-
тинг 4.30) будет строка 11.
2. Неявное преобразование к типу Строка. Данный тип
преобразования проиллюстрируем следующим примером
(листинг 4.31).
Листинг 4.31. Неявное преобразование к типу Строка
Булево = Истина;
Сообщить(Булево);
В результате будет получено представление значения
в соответствии с текущими региональными установками
информационной базы. Например, для русских регио-
нальных установок это будет значение истина, а для поль-
ских — prawda.
Явное преобразование. Встроенный язык позволяет вы-
полнить явное преобразование значения типа Булево.
1. Преобразование к типу Число. Для этого используется
встроенная функция ЧислоО, которой в качестве парамет-
ра передается булево значение. При этом значение Истина
преобразуется в 1, а значение Ложь — в 0 (листинг 4.32).
Листинг 4.32. Преобразование к типу Число
Результат = Число(Истина);
Сообщить(Результат);
2. Преобразование к типу Строка. Встроенный язык позво-
ляет также преобразовывать значение типа Булево к типу
Строка. Для этого используется встроенная функция Стро-
ка, которая возвращает представление булева значения в
соответствии с текущими региональными установками
информационной базы (листинг 4.33).
Листинг 4.33. Преобразование к типу Строка
Результат = Строка(Истина);
Сообщить(Результат);
В результате выполнения этого кода, в окно сообщений бу-
дет выведено истина (для русских региональных установок).
Неопределено
Значение типа Неопределено применяется тогда, когда не-
обходимо использовать «пустое значение», не принадле-
жащее ни к одному другому типу данных, определенных в
прикладном решении. Тип Неопределено имеет одно един-
ственное значение — Неопределено. Это значение использу-
ется, например, как значение составного типа по умолча-
нию. По этой причине составной тип всегда содержит тип
Неопределено. О составном типе данных подробнее можно
прочитать в разделе «Составной тип данных», с. 68.
Представлением значения Неопределено является пустая
строка.
Литерал значения типа Неопределено
Значение типа Неопределено во встроенном языке и языке
запросов задается литералом Неопределено.
Операции со значением Неопределено
Для значения Неопределено определены операции сравнения
на равенство и неравенство со значениями других типов.
Таким образом, для любой переменной всегда может быть
выполнено сравнение на равенство (или неравенство) ее
значения значению Неопределено (листинг 4.34).
Листинг 4.34. Сравнение со значением Неопределено
Если РеквизитФорныСоставной = Неопределено Тогда
СообщитьС'Истина");
Иначе
СообщитьС'Ложь");
КонецЕсли;
Преобразование значений типа Неопределено
Значение Неопределено может быть преобразовано только
в значение типа Строка. Такое преобразование может вы-
полняться системой неявно (например, при выводе зна-
чения Неопределено) или явно, с использованием встроенной
функции СтрокаО. Результатом преобразования является
пустая строка.
Null
Тип Nul 1, так же как и тип Неопределено, имеет единствен-
ное значение — Null. Это значение используется системой
для обозначения отсутствующего значения при работе
с базой данных.
Такая ситуация может возникнуть, например, при соеди-
нении нескольких таблиц в запросах, когда для одной из
соединяемых таблиц нет записей в другой таблице, удов-
летворяющих указанным условиям.
Кроме приведенного примера, значение Nul 1 может быть
получено и в других случаях. Например, когда выполня-
ется обращение к реквизитам объекта, которые не ис-
пользуются. Допустим, у иерархического справочника
Номенклатура существует реквизит Артикул, для которо-
го свойство Использование установлено в значение ДляЭле-
нента. В этом случае поле Артикул будет доступно для ре-
дактирования только у элементов справочника. У групп
справочника это поле не будет содержать никакой инфор-
мации.
Поэтому при обращении к реквизиту Артикул у группы
справочника Номенклатура система будет возвращать зна-
чение Null (листинг 4.35).
Листинг 4.35. Значение типа Null
Выборка = Справочники.Номенклатура.ВыбратьО;
Пока Выборка.Следующий() Цикл
Если Выборка.ЭтоГруппа Тогда
Префикс = "Группа: ";
Иначе
Префикс = "Элемент:
КонецЕсли;
Сообщить(Префикс + СокрЛГЦВыборка.Наименование) +
", тип артикула: " + ТипЗнч(Выборка.Артикул));
КонецЦикла:
В приведенном примере выбираются все элементы спра-
вочника Номенклатура, и затем выводится информация о
типе значения реквизита Артикул для каждого элемента
выборки.
Литерал значения типа Null
Значение Nul 1 во встроенном языке и языке запросов за-
дается литералом Null, а представлением значения Null
является пустая строка.
Операции со значениями типа Null
Для значения Nul 1 определены операции сравнения на ра-
венство и неравенство со значениями других типов. В ре-
зультате этого для любой переменной всегда может быть
выполнено сравнение на равенство (или неравенство) ее
значения значению Nul 1 (листинг 4.36).
В приведенном примере выбираются все элементы спра-
вочника Номенклатура. Затем для каждого элемента про-
веряется равенство его артикула значению Nul 1, и в зави-
симости от этого формируется строка для вывода сооб-
щения.
Листинг 4.36. Сравнение со значением типа Null
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.СледующийО Цикл
Суффикс = ?(Выборка.Артикул = Null,
"не используется". Выборка.Артикул);
Сообщить(СокрЛГЦВыборка.Наименование) +
", артикул: " + Суффикс);
КонецЦикла:
Преобразование значений типа Null
Значение Nul 1 может быть преобразовано только в значе-
ние типа Строка. Такое преобразование может выполнять-
ся системой неявно (например, при выводе значения
Null) или явно, с использованием встроенной функции
СтрокаО. Результатом преобразования является пустая
строка.
Тип
Значения типа Тип используются для идентификации
различных типов значений и их сравнения.
Значения этого типа возвращаются двумя системными
функциями: Тип() и ТипЗнчО. Также значения этого типа
могут быть получены из объекта ОписаниеТипов в виде мас-
сива значений (метод ТипыО).
Функция Тип() позволяет получить значение этого типа,
соответствующее переданному в качестве параметра име-
ни некоторого типа (листинг 4.37).
Листинг 4.37. Использование функции Тип()
ТипСтрока = ТипССтрока");
ТипЧисло = Тип("Число"):
ТипСсылкаНаСправочникНоменклатура =
Тип("СправочникСсылка.Номенклатура"):
Функция ТипЗнчО также позволяет получить значение
типа Тип, однако в качестве параметра ей передается не
имя типа, а само значение какого-либо типа (листинг 4.38).
Листинг 4.38. Использование функции ТипЗнчО
ТипСтрока = ТипЗнч("произвольная строка");
ТипЧисло = Тип3нч(387.67);
ТипСсылкаНаСправочникНоменклатура =
ТипЗнч(Справочники.Номенклатура.НайтиПоКоду("00001"));
Операции со значениями типа Тип
Для значений типа Тип определены операции сравнения
на равенство и неравенство. Это позволяет выполнять
проверку принадлежности произвольного значения неко-
торому типу (листинг 4.39).
Листинг 4.39. Проверка принадлежности значения типу
Если ТипЗнч(ПроверяемаяПеременная) = ТипССтрока") Тогда
СообщитьСТип проверяемой переменой - строка");
КонецЕсли;
Преобразование значений типа Тип
Значения этого типа могут быть преобразованы только
к значениям типа Строка. Такое преобразование может
быть выполнено системой неявно (при выводе значения,
например) или явно, с использованием встроенной функ-
ции СтрокаО. Результатом такого преобразования будет
представление описываемого типа, полученное в соответ-
ствии с используемым языком интерфейса платформы
(табл. 4.17).
Таблица 4.17. Преобразование к типу Строка
Значение Язык интерфейса платформы Представление
Тип(«Строка») Русский Строка
Тип(«Строка») Украинский Рядок
Тип(«Строка») Латышский Rinda
Тип(«Справочник Ссылка. Номенклатура») Русский Справочник ссылка: Номенклатура
Тип(« Справочник Ссылка. Номенклатура») Казахский Аныктама алтеме: Номенклатура
Тип(«Справочник Ссылка. Номенклатура») Грузинский 0б<п&5бю ЗобоЗбд&д: Номенклатура
Типы, образуемые
в прикладном решении
В отличие от примитивных типов, которые определены на
уровне технологической платформы и поддерживаются в
любом прикладном решении, прикладные типы создаются в
конкретных прикладных решениях в результате добавления
в конфитурацию какого-либо объекта метаданных. Приклад-
ные типы создаются платформой автоматически и позволя-
ют работать с данными, хранящимися в тех структурах, кото-
рые описываются данным объектом конфигурации.
В зависимости от объекта конфигурации будут добав-
ляться различные типы данных. Например, при добавле-
нии справочника Номенклатура будут созданы такие типы
данных, как:
СправочникМенеджер.Номенклатура;
СправочникСсылка.Номенклатура;
СправочникОбъект.Номенклатура;
СправочникВыборка.Номенклатура;
СправочникСписок.Номенклатура.
Если же в конфитурацию добавить, например, регистр све-
дений КурсыВалют, то станут доступны следующие типы:
РегистрСведенийМенеджер.КурсыВалют;
РегистрСведенийВыборка.КурсыВалют;
PerистрСведенийСписок.КурсыВалют;
Таблица 4.18. Основные типы для работы с данными объектов конфигурации
Объект конфигурации Менеджер Список Выборка Ссылка Объект Набор записей Запись Ключ записи
Константа +
Критерий отбора + +
Журнал документов + + +
Перечисление + + +
Справочник + + + + +
Документ + + + + +
План видов характеристик + + + + +
План счетов + + + + +
План видов расчета + + + + +
Бизнес-процесс + + + + +
Задача + + + + +
План обмена + + + +
Отчет + +
Обработка + +
Последовательность + + +
Перерасчет + + +
Регистр сведений + + + + + +
Регистр накопления + + + + + +
Регистр бухгалтерии + + + + + +
Регистр расчета + + + + + +
РегистрСведенийМенеджерЗаписи.КурсыВалют;
РегистрСведенийНаборЗаписей.КурсыВалют;
РегистрСведенийЗапись.КурсыВалют;
PerистрСведенийКлючЗаписи.КурсыВалют.
Как можно заметить из названий, некоторые типы «похо-
жи» (например, СправочникСписок.Номенклатура и Регистр-
СведенийСписок.КурсыВалют), а некоторые нет (например,
СправочникОбъект.Номенклатура и РегистрСведенийНаборЗапи-
сей.КурсыВалют). Это действительно так: типы, создавае-
мые для различных объектов конфигурации и принадле-
жащие к одной группе прикладных типов (например, <вид
обьекта>Список.<имя>), имеют схожую функциональность,
схожее поведение и одинаковые приемы работы с ними.
Такая организация системы прикладных типов сущест-
венно облегчает разработку прикладных решений, по-
скольку если разработчик освоил работу со списком
справочника, то он уже без труда, по аналогии, сможет ра-
ботать и со списком регистра сведений и, например, со
списком бизнес-процесса (табл. 4.18).
Для некоторых объектов конфигурации создаются до-
полнительные типы, реализующие специальную функ-
циональность, присущую только данным объектам кон-
фигурации (табл. 4.19).
Таблица 4.19. Дополнительные типы для работы
с данными объектов конфигурации
Объект конфнпрацни Типы
Константа КонстантаМенеджерЗначения.<имя> КонстантыНабор
План счетов ПланСчетовВидыСубконто.<имя> ПланСчетовВидыСубконтоСтрока.<имя>
План видов расчета ВедущиеВидыРасчета.<имя> ВедущиеВидыРасчетаСтрока.<имя> ВытесняющиеВидыРасчета.<имя> ВытесняющиеВидыРасчетаСтрока.<имя> БазовыеВидыРасчета.<имя> БазовыеВидыРасчетаСтрока.<имя>
Регистр сведений РегистрСведенийМенеджерЗаписи.<имя>
Регистр бухгалтерии РегистрБухгалетрииСубконто.<имя>
Менеджер объектов
Для каждого вида объектов конфигурации (справочники,
документы и т. д.) в системе определен тип менеджера
этих объектов (СправочникиМенеджер, ДокументыМенеджер и т. д.).
Эти типы существуют всегда, вне зависимости от того,
есть ли в конкретном прикладном решении хоть один та-
кой объект или нет.
Каждый из этих типов имеет единственное значение в кон-
кретном прикладном решении. Это можно проиллюстри-
ровать на следующем примере (листинг 4.40).
Менеджеры объектов доступны через соответствующие
свойства глобального контекста (например, Справочники
или Документы).
Листинг 4.40. Сравнение экземпляров объектов
менеджеров
МенеджерСправочников! = Справочники;
МенеджерСправочников2 = Справочники;
Если МенеджерСправочников! = МенеджерСправочников2 Тогда
Сообщить("Объекты равны");
КонецЕсли;
Главная задача этого типа — предоставить доступ к ме-
неджерам конкретных объектов метаданных (Справочник-
Менеджер.<иня>, ДокументМенеджер.<иня> и т. д.) (рис. 4.33).
Рис. 4.33. Структура типов
Кроме этого, менеджер объектов позволяет проверить,
является ли тип какого-либо значения типом ссылки на
объект этого типа (листинг 4.41).
Листинг 4.41. Использование менеджера для проверки
принадлежности к типам ссылок
СсылкиНаВсеСправочники = Справочники.ТипВсеСсылкиО;
Если СсылкиНаВсеСправочники.
СодержитТип(ТипЗнч(АнализируеноеЭначение)) Тогда
Сообщить("Это ссылка на справочник");
Иначе
Сообщить("Значение не является ссылкой на справочник");
КонецЕсли;
В приведенном примере используется метод ТипВсеСсыл-
киО менеджера справочников для того, чтобы в перемен-
ной СсылкиНаВсеСправочники получить объект ОписаниеТипов,
содержащий типы ссылок на все справочники приклад-
ного решения. Затем, используя его метод СодержитТипО,
проверяется, входит ли тип анализируемого значения
в состав этого описания типов или нет.
Менеджеры конкретных объектов метаданных доступны
двумя путями. Во-первых, они доступны как свойства ме-
неджера объектов (листинг 4.42).
Листинг 4.42. Обращение к менеджеру объекта
конфигурации
МенеджерСправочников = Справочники:
МенеджерСправочникаКонтрагенты = МенеджерСправочников.
Контрагенты;
Кроме этого, менеджеры объектов можно получить пере-
бором коллекции значений, которой является менеджер
объектов. Элементами этой коллекции как раз и являют-
ся менеджеры отдельных объектов (листинг 4.43).
Листинг 4.43. Обход коллекции менеджеров объектов
МенеджерСправочников = Справочники;
Для Каждого МенеджерСправочника Из МенеджерСправочников Цикл
Сообщить(ТипЗнч(МенеджерСправочника));
КонецЦикла;
Менеджер
Менеджер прикладного объекта можно назвать «точкой
входа» в конкретный объект метаданных в объектной мо-
дели встроенного языка. Объекты этого типа предостав-
ляют доступ к общим действиям, относящимся к кон-
кретному объекту метаданных (например, к справочнику
Контрагенты или к документу Авансовый отчет). В основ-
ном это:
♦ получение форм и макетов;
♦ получение выборок из данных этого объекта конфигу-
рации;
♦ создание и поиск элементов данных;
♦ доступ к предопределенным элементам данных;
♦ выполнение общих действий, поддерживаемых данным
объектом конфигурации.
В конкретном прикладном решении всегда существует
только один экземпляр каждого менеджера, в чем можно
убедиться на следующем примере (листинг 4.44).
Листинг 4.44. Сравнение экземпляров объектов
менеджеров объекта конфигурации
МенеджерСправочникаКонтрагенты1 = Справочники.Контрагенты;
МенеджерСправочникаКонтрагенты2 = Справочники.Контрагенты;
Если МенеджерСправочникаКонтрагенты! =
МенеджерСправочникаКонтрагенты2 Тогда
Сообщить("Объекты равны”);
КонецЕсли;
Объект
Тип объекта так же как и ссылка, создается не для всех
объектов конфигурации, а только для тех, которых хра-
нят в базе данных объектные данные (справочники, доку-
менты, планы счетов и пр.).
Только с помощью объекта может быть выполнена моди-
фикация данных, хранящихся в базе данных. Другие
типы объектных данных позволяют выполнять только
чтение данных из базы данных.
Более подробно о данных объектного типа можно прочи-
тать в разделе «Объект», с. 39.
Ссылка
Тип ссылки создается не для всех объектов конфигура-
ции, а только для тех, которые хранят данные объектного
типа (справочники, документы, планы счетов и пр.).
Тип ссылки служит, прежде всего, для однозначной иден-
тификации объекта данных (как совокупности логически
связанных данных) в базе данных. Значением ссылки яв-
ляется, фактически, уникальный внутренний идентифи-
катор, который хранится в поле Ссылка таблиц, создавае-
мых системой для объекта конфигурации.
Ссылка позволяет обращаться к свойствам объекта базы
данных, а также получать сам объект. Более подробно об
этом можно прочитать в разделе «Ссылка», с. 37.
Набор записей
Тип набора записей, в отличие от ссылок и объектов,
предназначен для работы с необъектными данными, та-
кими как, например, наборы записей различных регистров.
Так же как и объект для объектных данных, набор запи-
сей является единственным объектом, с помощью кото-
рого, в конечном счете, выполняется модификация не-
объектных данных.
Более подробно о необъектных данных можно прочитать
в разделе «Необъектные данные», с. 44.
Список
Список предназначен для динамического просмотра дан-
ных объекта конфигурации в элементе управления таб-
личное поле. Объекты списков, как правило, создаются
системой автоматически, в процессе визуального конст-
руирования; можно назначить этот тип табличному полю
или просто произвольному реквизиту формы.
Список осуществляет считывание данных из базы дан-
ных порциями, в процессе навигации пользователя по
списку. По этой причине такие объекты называют еще
списками динамического просмотра или динамическими
списками. Каждая очередная порция считанных данных
отражает актуальное состояние списка.
Список позволяет настроить состав полей, которые будут
считаны из базы данных (свойство Колонки), а также уста-
новить отбор и порядок.
Колонки списка
Колонки списка представляют собой объект КолонкиСпи-
ска, являющийся коллекцией отдельных колонок (Колон-
каСписка). Можно добавлять, удалять колонки из коллек-
ции, перебирать колонки списка или обращаться к ним
по индексу.
Поскольку список предназначен для отображения дан-
ных табличным полем, то после того, как табличное поле
будет связано со списком, список будет содержать неко-
торый набор колонок, которые необходимы для функцио-
нирования табличного поля. Эти колонки будут присут-
ствовать в списке даже в том случае, если табличное поле,
отображающее этот список, не будет содержать ни одной
колонки. Состав таких колонок различается для разных
объектов метаданных, и в сводном виде он представлен
в табл. 4.20 и 4.21:
Для справочника некоторые колонки будут присутство-
вать в зависимости от вида справочника:
Родитель — если справочник иерархический с иерархией
элементов,
Родитель, ЭтоГруппа — если справочник иерархический
с иерархией групп и элементов,
Владелец — если справочник подчиненный.
Для плана видов характеристик колонки Родитель и Это-
Группа будут присутствовать, только если план видов ха-
рактеристик иерархический.
Для регистра сведений некоторые колонки будут присут-
ствовать в зависимости от вида регистра:
Период — если регистр сведений периодический,
Активность, Регистратор — если регистр сведений подчинен
регистратору.
Таблица 4.20. Состав полей списков объектов конфигурации, работающих с объектными данными
Ссылка Пометка- Удаления Предопреде- ленный Родитель ЭтоГруппа Дата Проведен Владелец Код Наименование Вид Забалансовый Ведущая- Задача Завершен Стартован Выполнена
Справочник + + + * * *
План видов характеристик + + + * *
План счетов + + + + + + + +
План видов расчета + + +
План обмена + +
Бизнес-процесс + + + + + +
Задача + + + +
Документ + + + +
Журнал документов + + + +
Таблица 4.21. Состав полей списков объектов
конфигурации, работающих с необъектными данными
Активность Регистратор ВидДвижения Период Сторно
Регистр сведений * * *
Регистр накопления + + *
Регистр бухгалтерии + + *
Регистр расчета + +
Для регистра накопления колонка ВидДвижения будет
присутствовать, только если это регистр накопления ос-
татков.
Для регистра бухгалтерии колонка ВидДвижения будет
присутствовать, только если этот регистр не поддержива-
ет корреспонденцию.
Как правило, колонками списка управляет табличное
поле, отображающее данные этого списка. Такой меха-
низм работы позволяет минимизировать обращения к
базе данных, так как выполняется чтение только тех по-
лей, которые отображаются в табличном поле, а также
тех, которые необходимы для обеспечения работы таб-
личного поля. По этой причине, при отключении видимо-
сти или удалении колонки в табличном поле, она будет
удалена и в связанном с этим табличном полем списке.
Однако существуют ситуации, когда необходимо, чтобы
источник данных (список) содержал колонки, которые не
отображаются в табличном поле. Для этого можно ис-
пользовать свойство колонки списка АвтоУдаление. При ус-
тановке этого свойства в значение Ложь соответствующая
колонка уже не будет удаляться из списка при отключе-
нии видимости или удалении ее из табличного поля.
Отбор
Свойство Отбор позволяет ограничивать состав считывае-
мых данных различными условиями, которые накладыва-
ются на считываемые поля. В отбор по умолчанию вклю-
чаются все поля источника данных, за исключением полей
типа ХранилищеЗначения, так как по этим полям отбор невоз-
можен.
Например, если в форме расположено табличное поле, свя-
занное со списком справочника Номенклатура, то отбор спи-
ска может быть настроен следующим образом (листинг 4.45).
Листинг 4.45. Настройка отбора списка
ОтборСписка = СписокСправочника.Отбор;
ОтборСписка.Наименование.ВидСравнения =
ВидСравнения.Содержит;
ОтборСписка.Наименование.Значение = "жен";
ОтборСписка.Наименование.Использование = Истина;
ОтборСписка.ЭтоГруппа.Установить(Ложь, Истина);
В данном примере показаны два способа управления от-
бором.
Во-первых, разработчик имеет возможность для каждого
элемента отбора задать нужный вид сравнения и значе-
ние. При помощи этого способа устанавливается условие
на наименование считываемых элементов справочника —
будут считаны только те элементы, в наименовании кото-
рых содержится строка «жен».
Во-вторых, в большинстве случаев достаточно исполь-
зовать более короткий способ установки отбора, с ис-
пользованием метода УстановитьО элемента отбора. Та-
ким способом задается условие считывания только тех
элементов справочника, которые не являются группой.
Единственное ограничение в данном случае — это то, что
вид сравнения, устанавливаемый таким образом — Равно.
Если необходимо использовать другой вид сравнения —
нужно описывать его отдельно, как в первом случае.
Порядок
Свойство Порядок позволяет указывать, в каком порядке
будут отсортированы записи источника данных.
При выборе полей для упорядочивания следует учиты-
вать, что упорядочивание возможно не по всем полям.
Так, например, для любых прикладных объектов невоз-
можно упорядочивание по полям:
♦ типа Строка неограниченной длины;
♦ типа ХранилищеЗначения;
♦ по полям составного типа (если в состав типов входит
более одного типа);
♦ по полям, являющимся наборами типов.
Настройки порядка имеют важное значение для работы
механизма динамического просмотра данных. Дело в том,
что при работе этого механизма система использует ин-
дексы тех таблиц, содержимое которых отображается.
Если не один из индексов таблицы не соответствует за-
данному пользователем упорядочиванию, механизм ди-
намического просмотра задействован не будет, и из базы
данных будут считываться сразу все данные, которые
должны быть отображены в списке. Это может приводить
к «задержкам» при работе пользователя.
При установке порядка следует учитывать индексирова-
ние, которое система осуществляет по умолчанию, а так-
же индексирование, задаваемое разработчиком (за счет
использования свойств Индексировать и Индексировать с
доп. упорядочиванием). Это позволит использовать динами-
ческие списки максимально эффективным образом.
По умолчанию система упорядочивает данные по полям,
которые представлены в таблицах 4.22 и 4.23. Также сис-
тема выполняет и дополнительное упорядочивание в тех
случаях, когда требуется исключить неоднозначность в
упорядочивании данных. Например, если справочник
упорядочен по полю Наименование, то система выполнит
дополнительное упорядочивание по полю Ссылка, чтобы
для элементов, имеющих одинаковое наименование, так-
же можно было определить порядок.
Таким образом, например, для списка неиерархического
справочника оптимальным будет упорядочивание по
полю Код или по полю Наименование, а для списка регист-
ра накопления — упорядочивание по полю Период.
Таблица 4.22. Упорядочивание в списках объектных данных
Прикладной объект Упорядочивание по умолчанию Дополнительное упорядочивание
Справочник (иерархический, «группы сверху») ЭтоГруппа + Код или ЭтоГруппа + Наименование (в зависимости от основного представления справочника) Ссылка
Справочник (без иерархии или «группы сверху» не установлено) Код или Наименование (в зависимости от основного представления)
План видов характеристик
План счетов
План видов расчета
План обмена
Бизнес-процесс Дата
Задача
Документ
Журнал документов
Таблица 4.23. Упорядочивание в списках необъектных данных
Прикладной объект Упорядочивание по умолчанию Дополнительное упорядочивание
Регистр сведений (периодический) Период Список измерений в той последователь- ности, как они заданы в конфигураторе
Регистр сведений (непериодический) Список измерений в той последователь- ности, как они заданы в конфигураторе
Регистр накопления Период Регистратор + НомерСтроки
Регистр бухгалтерии
Регистр расчета ПериодРегистрации
Таблица 4.24. Варианты упорядочивания для списков объектных данных по умолчанию
и при использовании варианта Индексировать
Прикладной объект Поля, упорядочивание по которым является оптимальным Поля, упорядочивание по которым также является оптимальным, при условии, что для Реквизит (Графа) установлено «Индексировать»
Справочник (иерархический, «группы сверху») ЭтоГруппа + Код ЭтоГруппа + Наименование ЭтоГруппа + Реквизит
Справочник (без иерархии или «группы сверху» не установлено) Код Наименование Реквизит
План видов характеристик
План счетов
План видов расчета
План обмена
Бизнес-процесс Дата Номер Завершен Стартован
Задача Дата Наименование Номер Выполнена
Документ Дата Номер
Журнал документов Дата Графа
Таблица 4.25. Варианты упорядочивания для списков объектных данных по умолчанию
и при использовании варианта Индексировать с доп. упорядочиванием
Прикладной объект Поля, упорядочивание по которым является оптимальным Поля, упорядочивание по которым также является оптимальным, при условии, что для Реквизит (Графа) установлено «Индексировать с доп. упорядочиванием»
Справочник (иерархический, «группы сверху») ЭтоГруппа + Код ЭтоГруппа + Наименование ЭтоГруппа + Реквизит + Код ЭтоГруппа + Реквизит + Наименование
Справочник (без иерархии или «группы свер- ху» не установлено) Код Наименование Реквизит + Код Реквизит + Наименование
План видов характеристик
План счетов
План видов расчета
План обмена
Бизнес-процесс Дата Номер Завершен Стартован Реквизит + Дата
Задача Дата Наименование Номер Выполнена
Документ Дата Номер
Журнал документов Дата Г рафа + Дата
Наряду с тем, что система индексирует по умолчанию
структуры данных, разработчик дополнительно может
указать необходимость индексирования по соответствую-
щему реквизиту, используя его свойство Индексировать.
При этом он может использовать один из двух вариантов
построения индекса: Индексировать или Индексировать с до-
полнительный упорядочиванием.
В варианте Индексировать индекс строится непосредствен-
но по самому реквизиту. Использование такого варианта
позволяет эффективно упорядочивать динамические спи-
ски не только по тем полям, которые индексируются сис-
темой по умолчанию, но также и по данному реквизиту.
В варианте Индексировать с дополнительным упорядочиванием
индекс будет строиться по указанному реквизиту плюс
по некоторому полю, которое обычно используется систе-
мой для упорядочивания по умолчанию. Например, для
неиерархического справочника индекс будет строиться
по данному реквизиту плюс код или по данному реквизи-
ту плюс наименование. Такой вариант позволяет эффек-
тивно отбирать динамические списки по сочетанию поля
реквизита и поля, используемого для упорядочивания по
умолчанию.
В сводном виде различные оптимальные варианты упо-
рядочивания представлены в табл. 4.24-4.26.
Следует также учитывать, что неправильный выбор по-
лей для упорядочивания может привести не только к не-
эффективной работе механизма динамического просмот-
ра списков, но даже к невозможности его использования
вообще.
Это может происходить, например, если в составе полей,
по которым производится упорядочивание, присутствует
поле, которое не является полем примитивного типа. На-
пример, если упорядочить регистр накопления по полю,
имеющему тип СправочникСсылка.Контрагенты, то в этом слу-
чае упорядочивание будет выполняться по полю
основного представления справочника Контрагенты, кото-
рое находится не в таблице регистра сведений, а в табли-
це справочника Контрагенты.
Также динамический просмотр списка не будет работать,
если для полей, по которым выполняется упорядочива-
ние, задано различное направление сортировки.
Более подробно об индексировании таблиц базы данных
можно прочитать в разделе «Индексы таблиц базы дан-
ных», с. 788.
Выборка
Выборка предназначена для динамического обхода эле-
ментов данных, хранимых в структуре объекта конфигу-
рации. Выборка не считывает данные целиком в память,
а получает их блоками, по мере обхода выборки методом
Следующий О (листинг 4.46).
Листинг 4.46. Пример обхода выборки
ВыборкаВалют = Справочники. Валюты. ВыбратьО;
Пока ВыборкаВалют.Следующий() Цикл
Сообщить(ВыборкаВалют.Наименование);
КонецЦикла;
Благодаря тому, что считывание данных осуществляется
порциями, выборку можно использовать для обработки
очень больших объемов информации.
Каждый блок считываемых данных содержит 25 записей.
Для объектных таблиц каждая такая запись содержит все
данные объекта, включая все его поля и табличные части.
Поэтому, например, при обращении к реквизитам выбор-
ки или при получении объекта из выборки не происходит
повторного обращения к базе данных.
Таблица 4.26. Варианты упорядочивания для списков необъектных данных по умолчанию
и при использовании варианта Индексировать
Прикладной объект Поля, упорядочивание по которым является оптимальным Поля, упорядочивание по которым также является оптимальным, при условии, что для Поле установлено «Индексировать»
Регистр сведений (периодический) Период Период + <список измерений> <список всех измерений> + Период Поле + Период Поле + Период + <список измерений>
Регистр сведений (непериодический) Список измерений в той последовательности, как они заданы в конфигураторе Поле + <список измерений>
Регистр накопления Регистр бухгалтерии Период Поле + Период
Регистр расчета ПериодРегистрации ПериодДействия ПериодРегистрации + <список всех базовых измерений> ПериодДействия + <список всех базовых измерений> <список всех базовых измерений> + ПериодДействия <список всех базовых измерений> + ПериодРегистрации ПериодРегистрации + Поле Поле + ПериодРегистрации
Выборка осуществляет считывание данных в определен-
ном порядке. Этот порядок может задаваться, например,
путем указания параметров Отбор и Порядок метода Вы-
братьО.
Отбор может быть выполнен только по одному полю,
причем это может быть только то поле, для которого по-
строен индекс. Кроме полей, которые индексируются
системой по умолчанию, это может быть также поле, для
которого в конфигураторе установлен признак индек-
сирования в значение Индексировать или Индексировать
с дополнительным упорядочиванием. Отбор по таким полям
позволяет выполнять выборку быстро и эффективно. На-
пример, приведенный ниже пример (листинг 4.47) позво-
ляет выбрать из справочника Номенклатура только те эле-
менты, для которых не задан артикул.
Листинг 4.47. Пример использования отбора
СтруктураОтбора = Новый Структура;
СтруктураОтбора.Вставить("Артикул", "");
ВыборкаНоменклатуры = Справочники.Номенклатура.
Выбрать( , , СтруктураОтбора);
Пока ВыборкаНоменклатуры.СледующийО Цикл
Сообщить(ВыборкаНоменклатуры.Наименование);
КонецЦикла;
Отбор задается структурой, содержащей единственный
элемент, у которого ключ соответствует имени поля,
а значение — значению отбора.
Порядок отбираемых записей также может быть задан
с использованием полей, которые либо индексируются по
умолчанию, либо эти поля имеют примитивный тип и
для них построение индекса указано в явном виде в кон-
фигураторе. Например, следующий пример (листинг 4.48)
позволяет выбрать элементы справочника Договоры контр-
агентов в порядке убывания даты договора.
Листинг 4.48. Пример использования порядка
ВыборкаДоговоров = Справочники.ДоговорыКонтрагентов.
Выбрать( , , , "Дата Убыв”);
Пока ВыборкаДоговоров.Следующий() Цикл
Сообщить(ВыборкаДоговоров);
КонецЦикла;
Для иерархических данных (например, справочников, пла-
нов видов характеристик, планов счетов) существует также
иерархическая выборка, получаемая методом ВыбратьИерар-
хическиО. Такая выборка отличается от обычной тем, что
выдает данные путем обхода записей в соответствии с их
иерархией. То есть после выдачи элемента, выдается подчи-
ненный ему элемент, если такой существует. Если подчи-
ненных не существует, то выдается следующий элемент.
Причем каждое считывание подчиненных элементов реали-
зовано как считывание отдельного блока данных.
Кроме отбора и порядка, выборка позволяет задать также
родителя и владельца считываемых данных. При указа-
нии конкретного родителя выборка, получаемая методом
ВыбратьО, будет содержать те элементы, родитель кото-
рых равен указанному (рис. 4.34).
В то же время выборка, получаемая методом ВыбратьИерар-
хическиО, будет содержать все элементы, находящиеся
в иерархии указанного родителя, то есть в первом, втором
и последующих уровнях иерархии (рис. 4.35).
Если в методе Выбрать () в качестве родителя указать пус-
тую ссылку, то будут выбраны все элементы первого
уровня (рис. 4.36).
При указании в параметрах выборки конкретного вла-
дельца будут отбираться записи подчиненного справоч-
ника, владелец которых равен указанному. Например,
в следующем примере (листинг 4.49) будут выбраны все
договоры контрагента с кодом Ю0004.
Листинг 4.49. Выборка подчиненных элементов
Владелец = Справочники.Контрагенты.НайтиПоКоду("Ю0004");
ВыборкаДоговоров = Справочники.ДоговорыКонтрагентов.
ВыбратьИерархически( .Владелец);
Пока ВыборкаДоговоров.СледующийО Цикл
Сообщить(ВыборкаДоговоров);
КонецЦикла;
Особенности использования выборки
Как было показано выше, выборка считывает данные
в определенной последовательности сортировки. При об-
ходе выборки методом СледующийО выполняется получе-
ние очередных блоков данных в соответствии с порядком
сортировки и в соответствии с выдачей записей ранее
считанного блока. Другими словами, очередной блок счи-
тывается как множество записей, которые следуют в ука-
занном порядке после последней полученной записи пре-
дыдущего блока (рис. 4.37).
Особенностью такой схемы работы механизма выборки
является то, что разработчик не имеет контроля над акту-
альностью получаемой информации, даже если выборка
инициирована в транзакции. При получении очередной
записи нет возможности определить, считывается ли эта
запись из уже полученного ранее блока или же она была
только что считана в составе нового блока записей.
Рис. 4.37. Считывание данных блоками
Эта особенность работы механизма выборки может при-
водить к тому, что в выборку могут попасть данные уда-
ленного объекта, некоторые записи могут попасть дваж-
ды или не попасть в выборку вообще.
Получение данных удаленного объекта. Например, после
получения записей очередного блока одна из записей, от-
носящихся к этому блоку, была удалена из базы данных.
В этом случае к моменту окончания обхода выборки фи-
зически эта запись будет отсутствовать в базе данных,
хотя в то же время она будет присутствовать в получен-
Множественное попадание записи в выборку. Например,
в процессе получения выборки справочника в порядке
наименования, элемент справочника Женские сапоги был
переименован в Сапоги женские. В этом случае порядок
следования данной записи изменится, и может возник-
нуть ситуация, когда переименованный элемент справоч-
ника в порядке следования окажется среди записей еще
не считанного блока. В этом случае при получении дан-
ного блока эта запись будет считана повторно (рис. 4.39).
Непопадание записи в выборку. Ситуация, когда запись
может вообще не попасть в выборку, прямо противопо-
ложна предыдущей. Например, в процессе выборки спра-
вочника в порядке наименования элемент справочника
Сапоги женские, находящийся в порядке следования среди
записей еще не считанного блока, был переименован
в Женские сапоги и в соответствии с порядком следова-
ния оказался среди записей уже считанного ранее блока
(рис. 4.40).
Рис. 4.39. Множественное попадание записи в выборку
Рис. 4.40. Непопадание записи в выборку
Грабли
Компьютер
Удаление иерархических данных. Особенность использова-
ния выборки для обхода и удаления иерархических дан-
ных связана с тем, что при удалении элемента (родителя)
удаляются и все его подчиненные элементы (рис. 4.41).
Таким образом, при использовании обычной выборки мо-
жет возникнуть ситуация, когда в результате удаления
элемента могут быть удалены также и элементы, уже счи-
танные в текущем блоке (рис. 4.42).
Рис. 4.42. Удаление родителя в процессе выборки
В этом случае при попытке выполнения каких-либо дей-
ствий с полученным из выборки объектом (на рисунке —
Подчиненный!) будет выдаваться ошибка, так как в базе
данных этот объект уже не существует.
По этой причине, для удаления иерархических данных
следует использовать иерархическую выборку. В этом
случае все подчиненные элементы будут располагаться в
порядке следования в одном или нескольких блоках за
родительским элементом, и после удаления родителя
(и соответственно его подчиненных элементов) просто
будет выполнено чтение следующего за ними по порядку
блока записей (рис. 4.43).
Удаленный элемент
Удаленный подчиненный элемент
Удаленный подчиненный элемент
Удаленный подчиненный элемент
Рис. 4.43. Удаление родителя в процессе иерархической
выборки
Обобщая все перечисленные особенности использования
выборок, можно сказать, что следует внимательно отно-
ситься к изменению объектов в процессе обхода динами-
ческой выборки, так как это может повлиять на порядок
их включения в выборку. Наряду с этим рекомендуется
использовать динамические выборки либо для задач, не
требующих ответственного чтения данных, либо для рег-
ламентных задач, которые могут выполняться в моно-
польном режиме. Также использование динамических
выборок можно рекомендовать в тех случаях, когда объем
данных, выбираемых из базы данных, очень велик, и по-
лучение выборки такого объема другими способами (на-
пример, запросом) неэффективно.
Типы данных
Тип данных в системе 1 (^Предприятие представляет со-
бой перечень возможных типов значений, которые могут
быть использованы тем или иным элементом системы.
Типы данных используются при описании таких элемен-
тов системы, как:
♦ объекты метаданных (реквизиты, измерения, ресурсы
и др.);
♦ реквизиты формы;
♦ элементы управления, расположенные в форме и в таб-
личном документе;
♦ некоторые объекты встроенного языка (список зна-
чений, колонки таблицы значений и дерева значений
и др-).
Тип данных позволяет перечислить типы значений, кото-
рые используются, а также для некоторых примитивных
типов значений позволяет задать квалификаторы, описы-
вающие допустимые значения примитивных типов.
При визуальном конструировании тип данных может
быть описан с помощью палитры свойств или в специаль-
ном диалоге редактирования типа данных. Во встроенном
языке для описания типа данных используется объект
встроенного языка ОписаниеТипов.
Числовые типы данных
При описании допустимых значений типа Число сущест-
вует возможность указать:
♦ допустимый знак числа (он может быть любым или не-
отрицательным);
♦ общую разрядность числа;
♦ разрядность дробной части.
Эта возможность часто используется при организации
интерфейса системы.
При редактировании объектов конфигурации (например,
при указании типа данных реквизита формы) числовой
тип данных описывается средствами визуального конст-
руирования (рис. 4.44).
Рис. 4.44. Редактирование типа данных Число
Кроме этого, числовой тип данных может быть указан
и средствами встроенного языка (например, при созда-
нии таблицы значений, которая в дальнейшем будет ис-
пользована для ввода данных) (листинг 4.50). Для этого
используется объект КвалификаторыЧисла.
Листинг 4.50. Использование квалификаторов числа
КвалификаторЧисла = Новый КвалификаторыЧисла(5, 2,
ДопустиныйЗнак.Неотрицательный);
ОписаниеТипа = Новый ОписаниеТиповСЧисло",
КвалификаторЧисла);
ТаблицаСкидок.Колонки.Добавить("Товар",
Новый ОписаниеТипов("СправочникСсылка.Номенклатура”));
ТаблицаСкидок.Колонки.Добавить("Скидка", ОписаниеТипа);
ЭлементыФормы.ТабличноеПолеСкидки.Создат ьКолонки();
В этом примере сначала создается новый объект Квалифика-
торыЧисла, устанавливающий общее количество разрядов
равным пяти, количество разрядов дробной части равным
двум и допустимый знак числа — неотрицательный. Затем,
на основании этого объекта создается новый объект Описа-
ниеТипов, содержащий описание типа Число с указанными
ограничениями. Далее, при добавлении колонки Скидка в
таблицу значений ТаблицаСкидок этот объект указывается в
качестве описания типа данной колонки. Таким образом,
в колонке Скидка таблицы значений ТаблицаСкидок сможет
находиться неотрицательное число, содержащее пять раз-
рядов, из которых два отведены под дробную часть числа.
Строковые типы данных
При описании допустимых значений типа Строка сущест-
вует возможность указать:
♦ какой вариант ограничения длины будет использовать-
ся для строкового значения (фиксированная длина или
переменная длина);
♦ длину строкового значения (в случае фиксированной
длины).
В зависимости от длины строки различают строки огра-
ниченной и неограниченной длины. Если длина строки
равна нулю, то такая строка имеет неограниченную длину.
В противном случае строка будет иметь ограниченную
длину. Отличие строк ограниченной и неограниченной
длины можно проиллюстрировать следующим примером.
Пусть есть два реквизита: строка длиной 10 (СтрокаОгра-
ниченнаяЮ) и строка неограниченной длины (СтрокаНе-
ограниченная). Тогда при присвоении этим реквизитам
строкового значения, имеющего длину 14 символов,
в первом случае оно будет обрезаться до 10 символов, а во
втором случае — нет (листинг 4.51):
Листинг 4.51. Использование строк ограниченной
и неограниченной длины
СтрокаОграниченнаяЮ = "новое значение":
Сообщить("Строка ограниченной длины (10): " + . +
СтрокаПерененнаяЮ + .);
СтрокаНеограниченная = "новое значение";
Сообщить("Строка неограниченной длины: " + .. +
СтрокаНеограниченная + .);
Результатом выполнения приведенного примера будут
следующие сообщения:
Строка ограниченной длины (10): "новое знач"
Строка неограниченной длины: "новое значение"
Строки ограниченной длины могут быть двух видов:
фиксированной и переменной длины.
Их отличие также лучше всего продемонстрировать на
примере.
Пусть есть два реквизита: строка фиксированной длины
10 символов (СтрокаФиксированнаяЮ) и строка перемен-
ной длины 10 символов (СтрокаПеременнаяЮ). Тогда, при
присвоении этим реквизитам строкового значения, имею-
щего длину 5 символов, в первом случае оно будет допол-
няться пробелами справа до указанной длины, а во вто-
ром случае — нет (листинг 4.52).
Листинг 4.52. Использование строк фиксированной
и переменной длины
СтрокаФиксированнаяЮ = "новое”:
Сообщить!"Строка фиксированной длины (10): “ + . +
СтрокаФиксированнаяЮ + .);
СтрокаПерененнаяЮ = "новое";
Сообщить("Строка переменной длины (10): " + . +
СтрокаПеременнаяЮ +
Результатом выполнения приведенного примера будут
следующие сообщения:
Строка фиксированной длины (10): "новое"
Строка переменной длины (10): "новое"
При редактировании объектов конфигурации (например,
при указании типа данных реквизита формы) строковый
тип данных описывается средствами визуального конст-
руирования (рис. 4.45).
Кроме этого, строковый тип данных может быть указан
и средствами встроенного языка. Например, при созда-
нии таблицы значений, которая в дальнейшем будет ис-
пользована для ввода данных (листинг 4.53). Для этого
используется объект КвалификаторыСтроки.
Рис. 4.45. Редактирование типа данных Строка
Листинг 4.53. Использование квалификаторов строки
КвалификаторСтроки = Новый КвалификаторыСтроки(5,
ДопустинаяДлина.Переменная);
ОписаниеТипа = Новый ОписаниеТипов("Строка",
КвалификаторСтроки);
ТаблицаСкидок.Колонки.Добавить("Товар",
Новый ОписаниеТиповССправочникСсылка.Номенклатура"));
ТаблицаСкидок.Колонки.ДобавитьСАртикул", ОписаниеТипа);
Элем ентыФормы.ТабличноеПолеСкидки. Соз датьКолонкиО;
В этом примере сначала создается новый объект Квалифи-
каторыСтроки, устанавливающий переменную длину строки
в пять символов, затем на основании этого объекта созда-
ется новый объект ОписаниеТипов, содержащий описание
типа Строка с указанными ограничениями. Далее, при до-
бавлении колонки Артикул в таблицу значений Таблица-
Скидок этот объект указывается в качестве описания типа
данной колонки. Таким образом, в колонке Артикул таб-
лицы значений ТаблицаСкидок сможет находиться строка
переменной длины, содержащая максимум пять разрядов.
Типы данных, описывающие
значения типа Дата
При описании допустимых значений типа Дата существу-
ет возможность указать части даты, которые будут ис-
пользованы:
♦ дата и время;
♦ дата;
♦ время.
При редактировании объектов конфигурации (например,
при указании типа данных реквизита формы) использу-
ются средства визуального конструирования (рис. 4.46).
Редактирование типа данных
[^Составной тип данных;
Произвольный
-ДО Число
Строга
Булево___________________________________д
Состав доты (дата и время
т ОК 11 Отмена |
Рис. 4.46. Редактирование типа данных Дата
Кроме этого, тип данных, описывающий значения типа
Дата, может быть указан и средствами встроенного языка.
Например, при создании таблицы значений, которая в
дальнейшем будет использована для ввода данных (лис-
тинг 4.54). Для этого используется объект Квалифика-
торыДаты.
Листинг 4.54. Использование квалификаторов даты
КвалификаторДаты = Новый КвалификаторыДаты(ЧастиДаты.Дата):
ОписаниеТипаДата = Новый ОписаниеТиповС'Дата”,
КвалификаторДаты);
КвалификаторЧисла = Новый КвалификаторыЧисла(15, 2);
ОписаниеТипаЧисло = Новый ОписаниеТиповС'Число".
КвалификаторЧисла);
ТаблицаКурсВалют.Колонки.Добавить("Дата". ОписаниеТипаДата);
ТаблицаКурсВалют.Колонки.Добавить("Курс", ОписаниеТипаЧисло);
ЭленентыФорны.ТабличноеПолеКурсВалют.СоздатьКолонки();
В этом примере сначала создается новый объект Квалифи-
каторыДаты, который устанавливает использование части
даты — Дата. Затем, на основании этого объекта создается
новый объект ОписаниеТипов, содержащий описание типа
Дата с указанными ограничениями. Далее, при добавле-
нии колонки Дата в таблицу значений ТаблицаКурсВалют
этот объект указывается в качестве описания типа созда-
ваемой колонки. Таким образом, в колонке Дата смогут
находиться значения типа Дата, для которых возможно
изменение только непосредственно самой даты. Время у
этих значений всегда будет равно 00 часов 00 минут 00 се-
кунд.
Составной тип данных
До сих пор мы рассматривали типы данных, содержащие
описание только одного типа значений. Однако в общем
случае тип данных может содержать перечень нескольких
типов значений. Такой тип данных называется состав-
ным.
Благодаря наличию составного типа в базе данных могут
храниться реквизиты, значения которых имеют разный
тип в разные моменты времени, однако в один момент
времени может храниться значение только одного из пе-
речисленных типов.
Например, документ Внутренний заказ может иметь рекви-
зит Заказчик, имеющий составной тип данных: Справочник-
Сашка. Подразделения, СправочникСсылка.Склады (рис. 4.47).
Рис. 4.47. Реквизит составного типа
Это значит, что в этом реквизите могут храниться как
значения ссылок на справочник Подразделения, так и зна-
чения ссылок на справочник Склады.
Тип значения такого реквизита в каждый момент време-
ни может быть различным и определяется значением, ко-
торое в данный момент хранится в реквизите. Другими
словами, если реквизиту присвоить значение ссылки на
справочник Подразделения, то тип значения реквизита бу-
дет СправочникСсылка.Подразделения, если присвоить ссылку
на справочник Склады, то тип значения будет — Справоч-
никСсылка. Склады.
Описание значений составного типа
Описание составного типа данных может быть выпол-
нено как средствами визуального конструирования, так
и средствами встроенного языка.
В процессе визуального описания объектов конфигура-
ции для этого используется окно редактирования типа
данных (рис. 4.48).
Рис. 4.48. Окно редактирования типа данных
Разработчик может перечислить типы значений и наборы
типов, которые должны входить в составной тип данных,
а также, при необходимости, задать квалификаторы для
числовых, строковых значений и значений типа Дата.
Описывать составной тип данных можно также средства-
ми встроенного языка. Например, если в форме располо-
жено поле ввода ПолеВводаСоставногоТипа, не связанное с
данными, то задать его составной тип данных можно сле-
дующим образом (листинг 4.55).
Листинг 4.55. Описание составного типа
МассивТипов = Новый Массив;
МассивТипов.Добавить(Тип("Строка"));
МассивТипов.Добавить(Тип("Число")):
МассивТипов.Добавить(ТипС'СправочникСсылка.Номенклатура"));
ОписаниеСоставногоТипа = Новый ОписаниеТипов(МассивТипов);
ЭленентыФорны.ПолеВводаСоставногоТипа.ТипЗначения =
ОписаниеСоставногоТипа:
В этом примере сначала создается массив, содержащий
все нужные типы значений, а затем на его основании соз-
дается новый объект ОписаниеТипов, который присваивает-
ся свойству ТипЗначения нужного поля ввода. Это свойство
как раз и определяет тип данных, которые будут редакти-
роваться в поле ввода.
Значение реквизита составного типа
по умолчанию
Для реквизита составного типа значением по умолчанию
является значение Неопределено (подробнее о значении Не-
определено можно прочитать в разделе «Неопределено»,
с. 55). По этой причине тип Неопределено всегда входит со-
ставной тип данных, наряду с прочими типами. Представ-
лением значения Неопределено является пустая строка.
Если значение реквизита составного типа данных по умол-
чанию отображается в поле ввода, то в этом случае поле
ввода будет содержать дополнительную информацию,
указывающую на то, что этот элемент управления под-
держивает выбор из нескольких типов значений: вместо
многоточия, кнопка выбора будет содержать символ «Т»
(рис. 4.49).
Рис. 4.49. Отображение значения по умолчанию
реквизита составного типа
При нажатии па кнопку выбора система предложит вы-
брать один из возможных типов значений, а после этого
можно будет ввести конкретное значение выбранного типа.
Преобразование значений, хранящихся
в реквизитах составного типа
Неявное преобразование
При присвоении значений реквизитам, имеющим состав-
ной тип данных, могут возникнуть ситуации, когда при-
сваемое значение не соответствует текущему типу значе-
ния реквизита. В этом случае система будет выполнять
неявное преобразование типа присваемого значения к од-
ному из доступных типов значений.
Если составной тип данных содержит тип присваемого
значения, то реквизиту будет установлен новый тип зна-
чения и новое значение.
Например, пусть для реквизита СоставнойРеквизит задан
составной тип данных (рис. 4.50) и текущее значение рек-
визита равно Истина.
Рис. 4.50. Состав типов
После выполнения оператора, приведенного в листин-
ге 4.56, значение реквизита станет равным «новая строка».
Листинг 4.56. Присвоение нового значения
реквизиту составного типа
СоставнойРеквизит = "новая строка":
Если тип присваемого значения не соответствует ни од-
ному из типов, входящих в составной тип данных, тогда
система попытается привести тип присваемого значения
к одному из типов составного типа данных.
Например, после выполнения оператора (листинг 4.57)
значение реквизита СоставнойРеквизит станет равным
строке 10, то есть система приведет значение типа Число к
значению типа Строка, который входит в составной тип
данных.
Листинг 4.57. Присвоение значения реквизиту
составного типа
СоставнойРеквизит = 10:
В случае если система не сможет выполнить приведение
присваемого значение ни к одному типу, входящему в со-
ставной тип данных, реквизиту будет присвоено значение
по умолчанию — Неопределено.
Явное преобразование
Явное преобразование к значению реквизита составного
типа данных может быть выполнено с использованием
объекта встроенного языка ОписаниеТипов. Этот объект
имеет метод ПривестиЗначениеО, который позволяет при-
вести значение произвольного типа к значению, соответ-
ствующему составному типу данных (листинг 4.58).
Листинг 4.58. Приведение значения
МассивТипов = Новый Массив;
МассивТипов.Добавить(Тип ("Строка"));
МассивТипов.Добавить(Тип("Число")):
МассивТипов.Добавить(Тип(”СправочникСсылка.Номенклатура"));
ОписанмеСоставногоТипа = Новый ОписаниеТипов(МассивТипов);
ПриводимоеЗначение = Справочники.Номенклатура.
НайтиПоКодуС"00001"):
Результат = ОписаниеСоставногоТипа.
ПривестиЗначение(ПриводимоеЗначение);
СообщитьС" + ТипЭнч(Результат) + " + Результат);
В результате выполнения этого кода будет выведено сле-
дующее сообщение:
Справочник ссылка: Номенклатура: Сигареты
Если несколько видоизменить код и в качестве приводи-
мого значения получить не ссылку на справочник но-
менклатура, а объект справочника, то результат будет уже
другим:
Строка: Сигареты
Так происходит потому, что тип СправочникОбъект.Номенк-
латура не входит в составной тип данных, и система при-
водит его к одному из типов, входящих в составной тип,
в данном случае к типу Строка.
Наборы типов
При выборе типа данных реквизита система, помимо вы-
бора типов, определенных в конкретном прикладном ре-
шении, предоставляет разработчику возможность выби-
рать наборы типов. Наборами типов, например, являются
ЛюбаяСсылка, СправочникСсылка, Характеристика.<имя> и др.
Наборы типов, так же как и составной тип данных, содер-
жат некий перечень типов, определенных в данном при-
кладном решении, однако, в отличие от составного типа,
этот перечень формируется системой автоматически,
в результате анализа метаданных.
Проведем сравнение на примере ссылок на справочники.
Допустим, в прикладном решении имеются справочники
Номенклатура и Контрагенты. Тогда мы можем определить
реквизит составного типа данных, в который входят типы
СправочникСсылка.Номенклатура и СправочникСсылка.Контраген-
ты. Наряду с этим мы можем определить реквизит, содер-
жащий набор типов СправочникСсылка. И в том и в другом
случае мы будем иметь возможность хранить в реквизите
ссылки как на справочник Номенклатура, так и на справоч-
ник Контрагенты.
Теперь добавим в конфигурацию новый справочник Це-
ны. В реквизите составного типа мы по-прежнему сможем
хранить только ссылки на справочники Номенклатура и
Контрагенты, а в реквизите, описанном как набор типов,
мы сможем хранить ссылку на любой из справочников,
доступных в данной конфигурации, в том числе и на
справочник Цены.
При запуске прикладного решения набор типов преобра-
зуется системой, как правило, в составной тип, содержа-
щий все типы, которые должны входить в этот набор. По-
этому во втором случае в набор типов попадет и новый
справочник Цены.
Однако набор типов не всегда преобразуется системой
в составной тип данных. Если оказывается, что в набор
типов входит единственный тип значений, то набор типов
будет преобразован в этот самый тип значений. Такая си-
туация возможна, например, когда план видов характери-
стик (назовем его Свойства) имеет единственный тип зна-
чений в свойстве ТипЗначенияХарактеристик. Тогда набор
типов Характеристика.Свойства будет преобразован систе-
мой не в составной тип данных, содержащий один тип
значений, а в тот единственный тип значений, который
указан для плана видов характеристик.
Эта особенность может быть важна, когда, например, вы-
полняется проверка реквизита, тип которого описан как
Характеристика.Свойства, на заполненность. В случае когда
Характеристика.Свойства преобразуется системой в состав-
ной тип данных, проверять нужно на значение Неопределе-
но, а если Характеристика.Свойства преобразуется в опреде-
ленный тип значения, то проверять нужно на значение по
умолчанию данного типа.
Транзакции
Независимо о выбранного варианта работы (файловый
или клиент-серверный), система 1 С: Предприятие обеспе-
чивает работу с информацией, хранящейся в базе данных
с использованием механизма транзакций.
Транзакция — это неделимая, с точки зрения воздействия
на базу данных, последовательность операций манипули-
рования данными, выполняющаяся по принципу «все
или ничего», и переводящая базу данных из одного цело-
стного состояния в другое целостное состояние. Если по
каким-либо причинам одно из действий транзакции не-
выполнимо или произошло какое-либо нарушение рабо-
ты системы, база данных возвращается в то состояние, ко-
торое было до начала транзакции (происходит откат
транзакции).
Одним из главных свойств транзакции является ее ато-
марность, то есть неделимость. Рассмотрим простой при-
мер: интерактивная пометка на удаление группы справоч-
ника. Фактически это означает, что нужно выполнить
целую последовательность операций:
♦ для группы справочника установить значение поля По-
меткаУдаления;
♦ записать группу справочника;
♦ выбрать все элементы справочника, находящиеся в иерар-
хии помечаемой группы;
♦ для каждого из них установить значение поля Пометка-
Удаления;
♦ выполнить запись каждого из выбранных элементов.
В общем случае нет гарантии, что каждая из перечислен-
ных операций будет успешно выполнена. Например, один
из подчиненных элементов справочника может редакти-
роваться другим пользователем, и система в этом случае
не сможет изменить данные этого элемента справочника.
В результате часть элементов справочника окажется по-
меченными на удаление, а часть — нет. С точки зрения
системы такая ситуация недопустима и нарушает целост-
ность базы данных, так как результатом интерактивной
пометки на удаление должна быть установка пометки на
удаление самого элемента и всех его подчиненных эле-
ментов. То есть должны быть выполнены либо все пере-
численные операции, либо ни одна из них.
Для того чтобы обеспечить именно такое поведение, уста-
новка пометки на удаление выполняется системой в
транзакции. Если в процессе выполнения этой последо-
вательности операций произойдет ошибка (например,
один из подчиненных элементов будет заблокирован дру-
гим пользователем), будет выполнен откат транзакции, и
изменения, которые к этому моменту произошли в базе
данных, будут отменены (рис. 4.51).
транзакция
ошибка
Рис. 4.51. Отказ от изменений, выполненных в транзакции
Таким образом, перечисленная последовательность опе-
раций становится неделимой с точки зрения базы данных:
изменения будут зафиксированы в базе данных только в
том случае, если транзакция успешно завершена, то есть
выполнены все перечисленные операции (рис. 4.52).
Транзакции могут использоваться как самой системой,
так и разработчиком при написании модулей.
Рис. 4.52. Принятие изменений, выполненных в транзакции
Начать Отменить
транзакцию транзакцию
Рис. 4.53. Отмена изменений
Система осуществляет неявный вызов транзакций при
выполнении любых действий, связанных с модификаци-
ей информации, хранящейся в базе данных. Например,
все обработчики событий, расположенные в модулях объ-
ектов и наборов записей, связанные с модификацией дан-
ных базы данных, вызываются в транзакции.
Наряду с этим разработчик может использовать работу
с транзакциями в явном виде. Для этого используются
процедуры глобального контекста НачатьТранзакциюО, За-
фиксироватьТранзакциюО и ОтменитьТранзакциюО-
База данных
Начать Зафиксировать
транзакцию
транзакцию
Рис. 4.54. Принятие изменений
Использование явного вызова
транзакций
Процедура НачатьТранзакциюО позволяет открыть тран-
закцию. После этого все изменения информации базы
данных, выполняемые последующими операторами, мо-
гут быть либо целиком приняты, либо целиком отверг-
нуты.
Для принятия всех выполненных изменений использует-
ся процедура ЗафиксироватьТранзакциюО.
Для того чтобы отменить все изменения, выполнявшиеся
в открытой транзакции, используется процедура Отме-
нитьТранзакциюО.
Например, может использоваться следующая схема рабо-
ты с транзакцией (листинг 4.59).
Листинг 4.59. Пример использования транзакции
НачатьТранзакциюО;
// Последовательность выполняемых операторов
// Проверка возможности выполнения операции
Если НЕ <условие> Тогда
ОтненитьТранзакциюО;
КонецЕсли;
// Последовательность выполняемых операторов
ЗафиксироватьТранзакциюО;
Суть этой схемы заключается в том, что в процессе вы-
полнения связанной последовательности изменений дан-
ных базы данных проверяется возможность выполнения
некоторых операций. Если операцию выполнить невоз-
можно, осуществляется откат всех произведенных изме-
нений к состоянию, которое существовало перед выпол-
нением оператора НачатьТранзакциюО (рис. 4.53).
Если все операции выполнены успешно, то после выпол-
нения оператора ЗафиксироватьТранзакциюО все произве-
денные изменения будут зафиксированы в базе данных
(рис. 4.54).
Обработка ошибок базы
данных в транзакции
Далеко не во всех случаях разработчик заранее может
предусмотреть все возможные проверки. По большому
счету это и не нужно. Встроенный язык предоставляет
разработчику возможность перехватывать и обрабаты-
вать ошибочные ситуации, возникающие в процессе вы-
полнения модуля с помощью конструкции Попытка ... Ис-
ключение ... КонецПопытки. В конструкцию Попытка ...
КонецПопытки заключаются операторы, при выполнении
которых может произойти исключительная ситуация,
а после оператора Исключение описывается последователь-
ность действий, которая должна выполняться в случае,
если возникает исключительная ситуация (ошибка).
Таким образом, схема работы с транзакцией в более об-
щем виде может выглядеть следующим образом (лис-
тинг 4.60).
Листинг 4.60. Обработка исключительных ситуаций
НачатьТранзакциюО;
// Последовательность операторов
Попытка
// Последовательность выполняемых операторов
Исключение
ОтменитьТранзакциюО
КонецПопытки;
// Последовательность выполняемых операторов
ЗафиксироватьТранзакциюО;
При использовании такой схемы следует помнить о том,
что не все ошибки, возникающие при работе с базой дан-
ных, обрабатываются системой одинаково.
В общем случае, все ошибки базы данных можно разде-
лить на две категории:
♦ невосстановимые;
♦ восстановимые.
Невосстановимые ошибки — это ошибки, при возникнове-
нии которых нормальное функционирование ЮПред-
приятия может быть нарушено, например, могут быть ис-
порчены данные. При возникновении невосстановимой
ошибки выполнение ЮПредприятия прекращается в лю-
бом случае.
Если невосстановимая ошибка произошла в процессе вы-
полнения транзакции, то все изменения, сделанные в рам-
ках этой транзакции, отменяются системой (рис. 4.55).
База данных
невосстановимая
ошибка
Рис. 4.55. Невосстановимая ошибка
Восстановимые ошибки — это ошибки, не вызывающие
серьезных нарушений в работе ЮПредприятия. В случае
возникновения восстановимой ошибки дальнейшая рабо-
та системы может быть продолжена. При этом, естествен-
но, сама операция, вызвавшая ошибку, прекращается,
и вызывается исключение, которое может быть перехва-
чено и обработано конструкцией Попытка ... Исключе-
ние ... КонецПопытки.
Если восстановимая ошибка произошла в процессе вы-
полнения транзакции, то система автоматически не вы-
полняет отмену транзакции, предоставляя разработчику
возможность самостоятельно обработать сложившуюся
ситуацию (рис. 4.56).
База данных
транзакция
восстановимая
ошибка
Рис. 4.56. Восстановимая ошибка
В зависимости от характера произошедшей ошибки воз-
можны различные сценарии обработки этой ситуации.
Если произошедшая ошибка не связана с базой данных,
то возможно продолжение транзакции и дальнейшей ра-
боты модуля. Если разработчик считает это необходи-
мым, он может отменить транзакцию или наоборот, про-
должить выполнение транзакции, если произошедшая
ошибка не нарушает атомарность транзакции.
Если же исключительная ситуация была вызвана ошиб-
кой базы данных, то система фиксирует факт возникнове-
ния ошибки в этой транзакции и дальнейшее продолжение
транзакции или ее фиксация становятся невозможны.
Единственная операция с базой данных, которую разра-
ботчик может произвести в данной ситуации, — это отме-
на транзакции. После этого он может осуществить попыт-
ку выполнения этой транзакции еще раз.
Например, фрагмент кода, реализующий этот подход при
записи некоторых данных в базу данных, может выгля-
деть следующим образом (листинг 4.61).
Листинг 4.61. Обработка исключительных ситуаций
// Признак окончания попыток выполнения записи
Записано = Ложь;
// Попытки записи выполняются в цикле
Пока Не Записано Цикл
Попытка
НачатьТранзакциюО;
Данные.Записать();
ЗафиксироватьТранзакциюО;
// В случае фиксации транзакциии
// прекратить попытки записи
Записано = Истина;
Исключение
// В случае неудачи отменить текущую транзакцию
// и следующую попытку начать с новой транзакции
ОтменитьТранзакциюО;
КонецПопытки;
КонецЦикла;
Вложенный вызов транзакций
В рамках уже выполняемой транзакции можно обращать-
ся к процедурам НачатьТранзакциюО, ЗафиксироватьТранзак-
циюО и ОтменитьТранзакциюО. Например, может использо-
ваться следующая схема вызовов (листинг 4.62).
Листинг 4.62. Вложенный вызов транзакций
НачатьТранзакциюО;
// Вложенный вызов транзакции
НачатьТранзакциюС);
ЗафиксироватьТранзакциюО;
// Вложенный вызов транзакции
НачатьТранзакциюО;
ЗафиксироватьТранзакциюО;
ЗафиксироватьТранзакциюО;
Однако подобное обращение не означает начала новой
транзакции в рамках уже выполняющейся. 1 (^Предпри-
ятие не поддерживает вложенных транзакций. Это озна-
чает, что всегда действует только транзакция самого
верхнего уровня. Все транзакции, вызванные внутри уже
открытой транзакции, фактически относятся к той же
транзакции, а не образуют вложенную транзакцию. Та-
ким образом, отмена изменений, выполняемая во «вло-
женной» транзакции, будет приводить, в конечном счете,
не к отмене изменений самой «вложенной» транзакции
(рис. 4.57), а к отмене всех изменений транзакции верхне-
го уровня (рис. 4.58).
Рассмотрим подробнее механику вложенных вызовов
транзакций, реализуемую 1 С:Предприятием.
Когда в рамках выполняемой транзакции происходит вызов
процедуры НачатьТранзакциюО, фактически выполняется все-
го лишь увеличение на единицу внутреннего счетчика тран-
закций. Процедура НачатьТранзакциюО действительно начи-
нает новую транзакцию только в случае, если значение
внутреннего счетчика транзакций равно нулю (рис. 4.59).
Начать
транзакцию
Зафиксировать
транзакцию
Рис. 4.57. Механика вложенных транзакций
Начать
транзакцию
Зафиксировать
транзакцию
Начать Начать
транзакцию транзакцию „
в Зафргофоеатъ Отменить
транзакцию транзакцию
Рис. 4.58. Обработка вложенных вызовов транзакций в 1С:Предприятии
База данных
Рис. 4.59. Работа метода НачатьТранзакциюО
Счетчик транзакций
Рис. 4.60. Работа метода ЗафиксироватьТранзакциюО
Обращение к методу ЗафиксироватьТранзакциюО приводит
к фиксации результата транзакции только в том случае,
если значение внутреннего счетчика транзакций равно
единице (рис. 4.60).
Обращение к методу ОтменитьТранзакциюО при значении
счетчика транзакций больше единицы приведет не толь-
ко к уменьшению значения счетчика, но и к установке
признака, не позволяющего зафиксировать результа-
ты выполнения всей транзакции в целом. Последующее
обращение к процедуре ЗафиксироватьТранзакциюО при зна-
чении счетчика равном единице приведет, фактически,
к отмене всей транзакции верхнего уровня (рис. 4.61).
Рис. 4.61. Работа метода ОтменитьТранзакциюО
Таким образом, не всегда можно быть уверенным, что об-
ращение к методу НачатьТранзакциюО действительно начи-
нает новую транзакцию, а обращение к методам Зафикси-
роватьТранзакциюО и ОтметинитьТранзакциюО действительно
завершает транзакцию.
По этой причине во многих случаях, при возникновении
ошибки при выполнении транзакции, разумнее выдать
сообщение и предоставить пользователю решать: повто-
рить попытку выполнения операции еще раз или перед
повторением попытки предпринять какие-то действия по
устранению ситуации, приведшей к ошибке.
Влияние транзакций
на работу программных
объектов
Как уже отмечалось выше, механизм транзакций обеспечи-
вает атомарность и согласованность изменений, выполняе-
мых в базе данных. Работа с данными базы данных осущест-
вляется в системе 1С:Предприятие посредством различных
программных объектов, которые используются системой не-
посредственно, а также доступны во встроенном языке.
Результат такого опосредованного взаимодействия не все-
гда является очевидным и иногда может вызвать непони-
мание.
В общем случае программные объекты, используемые
системой 1С:Предприятие, абсолютно «прозрачны» для
транзакций базы данных. Иначе говоря, транзакции базы
данных могут вызываться при выполнении различных
методов программных объектов, однако, например, дейст-
вия, выполняемые базой данных при откате транзакции,
в общем случае никак не влияют на соответствующие
программные объекты.
В качестве примера рассмотрим изменение наименова-
ния элемента справочника, выполняемое в транзакции,
которая затем отменяется.
При выполнении метода ПолучитьОбъектО данные объекта
будут считаны из базы данных в свойства экземпляра
программного объекта СправочникОбъект. Номенклатура (лис-
тинг 4.63).
Листинг 4.63. Получение объекта справочника
Товар = Справочники.Номенклатура.НайтиПоКодуС1).
ПолучитьОбъектО:
Таким образом, и в базе данных, и в свойстве программ-
ного объекта будет находиться одно и то же значение на-
именования — Старое наименование (рис. 4.62).
После этого вызывается транзакция и изменяется значе-
ние свойства Наименование программного объекта на Новое
наименование (листинг 4.64).
Рис. 4.62. Получение объекта справочника
Листинг 4.64. Изменение наименования элемента
справочника в транзакции
Товар = Справочники.Номенклатура.НайтиПоКодуС1).
ПолучитьОбъектО:
НачатьТранзакциюО;
Товар.Наименование = "Новое наименование":
Теперь наименование в базе данных и в свойстве про-
граммного объекта отличаются (рис. 4.63).
Рис. 4.63. Изменение наименования элемента справочника
в транзакции
После этого выполняется запись программного объекта
(листинг 4.65).
Листинг 4.65. Запись объекта справочника
Товар = Справочники.Номенклатура.НайтиПоКоду(1).
ПолучитьОбъектО;
НачатьТранзакциюО;
Товар.Наименование = "Новое наименование";
Товар. Записать О:
После успешной записи данных программного объекта
в базу данных наименование элемента справочника и в
памяти, и в базе данных будет одинаковым: Новое наиме-
нование (рис. 4.64).
Рис. 4.64. Успешная запись объекта справочника
Затем выполняется отмена транзакции (листинг 4.66).
Листинг 4.66. Отмена транзакции
Товар = Справочники.Номенклатура.НайтиПоКодуС!).
ПолучитьОбъектО;
НачатьТранзакциюО:
Товар.Наименование = "Новое наименование":
Товар.Записать!);
ОтненитьТранзакциюО;
Рис. 4.65. Отмена транзакции
В результате того, что изменения, выполненные в базе
данных в транзакции, не принимаются, состояние базы
данных возвращается в исходное, то есть то, которое было
до начала транзакции. Это значит, что наименование эле-
мента справочника снова принимает значение Старое на-
именование.
Однако эти изменения никоим образом не касаются про-
граммного объекта: значение свойства наименование ос-
тается равным Новое наименование (рис. 4.65).
Для того чтобы сравнить наименования в базе данных
и программном объекте, можно выполнить запрос к базе
данных (листинг 4.67).
Листинг 4.67. Сравнение наименования элемента
справочника в базе данных и программном объекте
Товар = Справочники.Номенклатура.НайтиПоКодуО.
ПолучитьОбъектО:
НачатьТранзакциюО;
Товар.Наименование = "Новое наименование":
Товар.ЗаписатьО:
ОтменитьТранзакциюО;
Запрос = Новый Запросе"
| ВЫБРАТЬ Справочник.Номенклатура.Наименование
| ГДЕ Справочник.Номенклатура.Код = 1");
Выборка = Запрос. Выполнить О. Выбрать О;
Выборка.Следующий();
НаименованиеВБазе = Выборка.Наименование;
НаименованиеВПамяти = Товар.Наименование;
Сообщить(НаименованиеВПамяти);
Сообщить(НаименованиеВБазе):
Если теперь заново прочитать данные объекта из базы
данных в программный объект, то значение наименова-
ния в программном объекта станет таким же, как и в базе
данных (листинг 4.68).
Из приведенного примера следует важный вывод: при от-
мене транзакций базы данных разработчик (если в этом
есть необходимость) должен самостоятельно обеспечи-
вать адекватное изменение данных соответствующих
программных объектов. Это можно выполнять путем пе-
речитывания всех данных объекта или путем изменения
некоторых реквизитов программного объекта (если, на-
пример, это необходимо для отображения в интерфейсе).
Однако, как в любом правиле, здесь тоже есть исключе-
ния. В силу значительной прикладной специфики про-
граммных объектов 1 С:Предприятия в некоторых случа-
ях откат изменений, выполненных в базе данных, все же
может влиять на значения свойств соответствующих про-
граммных объектов.
Листинг 4.68. Перечитывание данных объекта
Товар =
Справочники. Номенклатура. НайтиПоКодуО .ПолучитьОбъектО;
НачатьТранзакциюО ;
Товар.Наименование = "Новое наименование":
Товар. Записать О:
ОтменитьТранзакциюО;
Запрос = Новый Запросе
| ВЫБРАТЬ Справочник.Номенклатура.Наименование
| ГДЕ Справочник.Номенклатура.Код = 1"):
Выборка = Запрос.ВыполнитьО.ВыбратьО;
Выборка.Следующий();
НаименованиеВБазе =Выборка.Наименование:
НаименованиеВПамяти = Товар.Наименование;
Сообщить(НаименованиеВПамяти);
Сообщить(НаименованиеВБазе);
Товар.ПрочитатьО;
СообщитьСТовар.Наименование);
Восстановление признака
проведенности документа
При отмене транзакции признак проведенности документа
восстанавливает значение, которое было до начала транз-
акции (листинг 4.69).
Листинг 4.69. Восстановление признака проведенности
документа
НачатьТранзакциюО;
Накладная = Документы. ПриходнаяНакладная.СоздатьДокументО;
Накладная. Дата = ТекущаяДатаО:
Накладная.Записать(РежимЗаписиДокумента.Проведение);
Проведен = Накладная.Проведен:
ОтменитьТранзакциюО:
Сообщить (Накладная. Проведен); //ложь
Сообщить(Проведен); //истина
Очистка ссылки
Если объект был создан в транзакции, то при ее откате
очищается значение ссылки (листинг 4.70).
Листинг 4.70. Очистка ссылки
НачатьТранзакциюО;
Товар = Справочники.Номенклатура.СоздатьЭлементО;
Товар.ЗаписатьО:
Ссылка = Товар.Ссылка;
ОтменитьТранзакциюО;
Сообщить(Товар.Ссылка = Справочники.Номенклатура.
ПустаяСсылкаО); //истина
Сообщить(Ссылка); // «Объект не найден>
// (1:9e4b00055d4c7bcfUd934028f79e857)
Очистка кода/номера объекта
Если объект создавался вне транзакции и при записи его
в транзакции использовался код/номер, сгенерирован-
ный автоматически, то при отмене транзакции код/номер
очищается (листинг 4.71).
Листинг 4.71. Очистка кода
Товар = Справочники.Номенклатура.СоздатьЭлементО;
НачатьТранзакциюО;
Товар.ЗаписатьО;
Код = Товар.Код;
ОтменитьТранзакциюО;
Сообщить(Товар.Код): // О
Сообщить(Код); // В
Уровни изоляции транзакций
В идеальном случае транзакции должны обеспечивать
изоляцию выполняемых изменений. Иными словами, не-
сколько транзакций, выполняющих изменение данных,
не должны мешать друг другу.
Самым простым способом решения этой проблемы явля-
ется последовательное выполнение транзакций. Следую-
щая транзакция выполняется после того, как закончилась
предыдущая.
Однако в реальной ситуации, при многопользователь-
ской работе, такой подход приводит к резкому снижению
производительности базы данных. Поэтому на практике
используются механизмы, позволяющие выполнять не-
сколько транзакций одновременно.
Для того чтобы одновременное выполнение транзакций
стало возможным, используется несколько уровней изо-
ляции транзакций. На самом низшем уровне изоляции
транзакции могут сильно мешать друг другу. На самом
высшем уровне они полностью изолированы.
Таким образом, за большую изоляцию транзакций прихо-
дится платить большими накладными расходами и замед-
лением работы системы.
Возможность изоляции одних транзакций от других реа-
лизуется благодаря блокировкам, накладываемым на
используемые ими данные. В зависимости от уровня изо-
ляции накладываются различные типы блокировок на
различные объекты базы данных на различное время.
С точки зрения базы данных все операции с данными
(в том числе и чтение) выполняются с использованием
транзакций. С точки зрения ЮПредприятия работа
с данными может выполняться в одном из двух режимов:
♦ в транзакции;
♦ вне транзакции.
Режим работы с данными вне транзакции допускает только
операции чтения данных. Этот режим введен для того,
чтобы обеспечить максимальную скорость и параллель-
ность чтения данных. Поэтому любая операция чтения
данных, выполняемая вне транзакции, считается безот-
ветственной. Это означает, что такая операция чтения мо-
жет вернуть устаревшие данные или даже незафиксиро-
ванные изменения, произведенные другой транзакцией,
то есть чтение выполняется «не глядя» на блокировки
данных, расставленные другими транзакциями.
Режим работы с данными в транзакции допускает любые
операции чтения и модификации данных, при этом долж-
ны соблюдаться следующие правила:
♦ чтение данных должно быть воспроизводимым, то есть
любая последующая операция чтения данных с тем же
условием выборки должна возвращать такой же резуль-
тат;
♦ результат чтения должен содержать наиболее актуаль-
ные данные, что означает, что никакая другая транзак-
ция не может изменить данные, считанные в данной
транзакции, до тех пор, пока данная транзакция не бу-
дет завершена;
♦ результат чтения не должен содержать незафиксиро-
ванные изменения данных базы данных.
Независимо от того, в транзакции или нет выполняется
обращение к данным в ЮПредприятии, на уровне SQL
Server это обращение к данным (в том числе и чтение
данных) выполняется в транзакции, явной или неявной.
Таким образом, при любых операциях с данными плат-
форма ЮПредприятия будет указывать SQL Server уро-
вень изоляции транзакций, который необходимо исполь-
зовать для выполнения данной операции, даже если с
точки зрения 1 С:Предприятия эта операция выполняется
вне транзакции.
В силу технологических особенностей реализации базы
данных, в файловом и клиент-серверном вариантах рабо-
ты используются различные уровни изоляции транзакций.
В файловом варианте работы используются блокировки
на уровне таблиц базы данных, одинаковые как для объ-
ектных, так и для необъектных данных.
В клиент-серверном варианте работы используются бло-
кировки на уровне записей таблиц, причем для объектных
и необъектных данных используются различные уровни
изоляции транзакций. Это позволяет обеспечить боль-
шую параллельность (пропускную способность) в конку-
рентных режимах работы.
Файловый вариант
Нетранзакционное чтение
Чтение, выполняемое вне транзакции, не вызывает никаких
блокировок. В файловом варианте платформа ЮПред-
приятия поддерживает версионирование при нетранзак-
ционном чтении. Поэтому при чтении используется со-
стояние данных таблиц, которое имело место на начало
выполнения запроса (рис. 4.66).
Рис. 4.66. Нетранзакционное чтение в файловом варианте
работы
Таким образом, чтение данных одним запросом в файло-
вом варианте всегда позволяет получать целостные дан-
ные.
Чтение в транзакции
Чтение данных в транзакции является ответственным,
то есть данные, считанные в транзакции, гарантированно
не могут быть изменены до тех пор, пока транзакция не
закончится.
В файловом варианте работы для этого используется раз-
деляемая блокировка (Shared Lock), накладываемая на
всю таблицу, данные которой считываются. Таким обра-
зом, данные этой таблицы могут быть прочитаны други-
ми транзакциями, однако изменить их они не смогут,
так как для изменения данных они будут пытаться уста-
новить исключительную блокировку (Exclusive Lock), ко-
торая несовместима с разделяемой блокировкой, уста-
новленной другой транзакцией.
Если чтение данных выполняется запросом с использова-
нием конструкции ДЛЯ ИЗМЕНЕНИЯ, то в этом случае накла-
дывается исключительная блокировка (Exclusive Lock) на
всю таблицу. Другие транзакции не смогут выполнить
чтение данных из этой таблицы до тех пор, пока исключи-
тельная блокировка не будет снята, так как для этого им
потребуется установить разделяемую (Shared Lock) или
исключительную (Exclusive Lock, если они также выпол-
няют чтение с использованием ДЛЯ ИЗМЕНЕНИЯ) блокировки,
которые несовместимы с эксклюзивной блокировкой, ус-
тановленной другой транзакцией.
Модификация
При модификации данных в файловом варианте рабо-
ты используется исключительная блокировка (Exclusive
Lock), накладываемая на всю таблицу, которая содержит
модифицируемые данные. Таким образом, другие тран-
закции будут ожидать снятия исключительной блокиров-
ки с этой таблицы, если им нужны данные, содержащиеся
в ней.
Клиент-серверный вариант
В клиент-серверном варианте работы используются раз-
личные уровни изоляции транзакций, поддерживаемые
SQL Server.
Нетранзакционное чтение
Чтение, выполняемое вне транзакции, использует уро-
вень изоляции READ UNCOMMITED. Этот уровень изоляции
используется потому, что SQL Server не поддерживает
версионирование для считываемых данных. В то же вре-
мя должна быть обеспечена предсказуемая скорость при
выполнении чтения, то есть нельзя «спотыкаться» о бло-
кировки, расставленные другими транзакциями.
Уровень изоляции READ UNCOMMITED является самым низ-
шим и, таким образом, обеспечивает максимальную па-
раллельность выполнения нескольких транзакций. Обо-
ротной стороной является то, что этот уровень изоляции
допускает чтение незафиксированных изменений, выпол-
ненных другими транзакциями (рис. 4.67).
Таким образом, в клиент-серверном варианте работы при
чтении вне транзакции можно получить несогласованные
данные.
Рис. 4.67. Нетранзакционное чтение в клиент-серверном
варианте работы
Наглядное проявление этого эффекта можно наблюдать,
например, в списке справочника при массированном соз-
дании новых элементов этого справочника. Динамиче-
ские списки осуществляют чтение данных вне транзак-
ции. Поэтому, если в одном сеансе работы запустить
обработку, которая в транзакции создает большое коли-
чество элементов справочника, а в другом сеансе работы
открыть и периодически обновлять список этого справоч-
ника, можно увидеть, что, несмотря на то, что транзакция,
открытая обработкой, еще не зафиксирована, в списке
справочника уже появляются все новые и новые эле-
менты.
Чтение в транзакции, модификация
Для чтения и модификации данных в транзакции в кли-
ент-серверном варианте работы используются одни и те
же уровни изоляции, однако эти уровни различные для
объектных и необъектных данных.
Объектные данные
Особенность объектных данных заключается в том, что
они обладают довольно большой гранулярностью и мало
«завязаны» друг на друга. Поэтому при работе с объект-
ными данными используется уровень изоляции REPEATABLE
READ. Этот уровень изоляции осуществляет блокировку
отдельных записей таблицы. Таким образом, другие тран-
закции могут читать и записывать данные других записей
этой же таблицы.
Например, при записи элемента справочника Номенклатура
будет заблокирована только одна запись основной табли-
цы справочника Номенклатура, которая содержит данные
записываемого элемента. Любые соседние записи этой
таблицы могут быть изменены другими транзакциями,
то есть могут быть одновременно записаны любые другие
элементы этого справочника.
Необъектные данные
Необъектные данные характеризуются более сложными
взаимными связями, по сравнению с объектными данны-
ми. Поэтому при работе с необъектными данными ис-
пользуется самый высокий уровень изоляции — SERIALIZA-
BLE. При работе с этим уровнем изоляции SQL Sever на-
кладывает дополнительные блокировки на диапазон зна-
чений индекса. При этом накладывается блокировка как
на саму запись индекса, так и на диапазон значений от те-
кущего значения ключа до ближайшего следующего.
На данном уровне изоляции не допускается не только мо-
дификация другими транзакциями прочитанных данных,
но и добавление новых записей в диапазон данных, огра-
ниченный условиями выполняемого запроса. Это обеспе-
чивает высокую степень целостности и непротиворечиво-
сти обрабатываемых в рамках транзакции данных.
Например, если существуют записи с идентификаторами
3 и 5 и делается попытка изменить запись с идентифика-
тором 4, то, в общем случае, будут дополнительно забло-
кированы записи с идентификаторами 3 и 5. Записи с
идентификаторами меньше 3 и больше 5 могут быть мо-
дифицированы.
Однако при определенных условиях блокировки уста-
навливаемые для этого уровня изоляции, могут приво-
дить к снижению пропускной способности системы. При-
чиной этого являются эксклюзивные блокировки таблиц
базы данных, устанавливаемые SQL Server, для обеспече-
ния целостности и непротиворечивости обрабатываемых
в рамках транзакции данных.
Переход от блокировок на уровне записи таблицы базы
данных к табличным блокировкам (эскалация блокиро-
вок) чаще всего обуславливается отсутствием записей в
некоторых таблицах базы данных, используемых в рам-
ках транзакции. При использовании уровня изоляции
SERIALIZABLE SQL Server блокирует весь диапазон прочи-
танных данных, не допуская добавления, удаления и мо-
дификации данных в рамках этого диапазона. Ввиду от-
сутствия записей в таблице, она блокируется целиком на
все время выполнения транзакции, что приводит к дегра-
дации пропускной способности системы.
Использование конструкции ДЛЯ ИЗМЕНЕНИЯ
Если транзакционное чтение данных в клиент-серверном
варианте выполняется запросом с использованием конст-
рукции ДЛЯ ИЗМЕНЕНИЯ, то в этом случае накладывается бло-
кировка обновления (Update Lock) на считываемые записи
(для объектных данных) или на диапазон записей (для
необъектных данных) таблицы. Другие транзакции не
смогут прочитать эти данные, если они также выполняют
чтение с использованием конструкции ДЛЯ ИЗМЕНЕНИЯ, так
как блокировки обновления несовместимы между собой.
Однако другие транзакции, выполняющие чтение без ис-
пользования конструкции ДЛЯ ИЗМЕНЕНИЯ, смогут читать
эти данные (блокировка обновления (Update Lock) совмес-
тима с разделяемой блокировкой (Shared Lock), наклады-
ваемой при «обычном» чтении), но не смогут изменить
их, так как для этого потребуется установить исключи-
тельную блокировку (Exclusive Lock), которая несовмес-
тима с блокировкой обновления (Update Lock), установ-
ленной другой транзакцией.
Подробнее об использовании конструкции ДЛЯ ИЗМЕНЕНИЯ
можно прочитать в разделе «Использование в запросах
оператора ДЛЯ ИЗМЕНЕНИЯ», с. 726.
Получение согласованных
данных при чтении
Как было показано выше, при нетранзакционном чтении
данных в клиент-серверном варианте работы можно по-
лучить нецелостные данные.
При работе в файловом варианте изменения незавершен-
ных транзакций не читаются, однако все равно есть воз-
можность получить несогласованные данные при неодно-
кратном обращении к базе данных.
Такая ситуация может возникнуть, если между выполне-
нием одного и другого запроса состояние считываемых
данных было изменено другой транзакцией.
Поэтому если требуется считать заведомо целостное со-
стояние данных, то чтение данных (например, запросы)
следует выполнять в рамках транзакции. В этом случае
гарантируется целостность и неизменность считанных
данных.
ВНИМАНИЕ
Если считываемые данные служат основой для каких-либо
расчетов, на основании которых будут производиться из-
менения данных (например, при проведении документов),
то такие операции чтения обязательно должны выполнять-
ся в рамках транзакции.
Вместе с этим следует взвешенно подходить к использо-
ванию транзакций и применять их там, где это действи-
тельно необходимо. Например, стремясь к получению
целостных данных, не следует огульно включать в тран-
закции целые отчеты; но если требуется получение согла-
сованной выборки данных, следует проанализировать не-
обходимость использования транзакции при получении
такой выборки.
Глава 5. Клиент-серверный вариант работы
Общие сведения о клиент-серверном варианте работы
Клиент-серверный вариант работы системы ЮПредпри-
ятие предполагает использование 3-уровневой архитек-
туры: клиент — сервер 1С:Предприятия — сервер баз дан-
ных. В этом варианте работы клиентское приложение
взаимодействует с сервером баз данных посредством специ-
ального приложения — сервера 1С:Предприятия (рис. 5.1).
Рис. 5.1. Схема работы в клиент-серверном варианте
Трехуровневая архитектура 1С:Предприятия разработа-
на таким образом, что пользователю не требуется доступ
ни к каким файловым ресурсам, связанным с 1 (^Пред-
приятием. Пользователю клиентского приложения 1 (^Пред-
приятия также не требуется доступ к базе данных сервера
баз данных.
В качестве клиентского приложения могут выступать
4 вида различных приложений:
♦ консоль сервера 1С:Предприятия;
♦ 1С:Предприятие;
♦ 1 С: Предприятие в режиме конфигуратора;
♦ внешнее соединение 1С:Предприятия.
Консоль сервера 1С:Предприятия предоставляет визуаль-
ный интерфейс, который позволяет выполнять админист-
рирование сервера: просмотр списка активных соедине-
ний, принудительное завершение соединений, создание,
изменение и удаление информационных баз и другие ад-
министративные действия.
Каждый экземпляр приложения 1С:Предприятие и каж-
дый экземпляр внешнего соединения являются для сер-
вера 1С:Предприятия отдельным клиентом. Их соедине-
ние с сервером всегда ассоциируется с определенной
информационной базой.
Для этого сервер 1 С: Предприятия хранит список зареги-
стрированных информационных баз и выполняет аутен-
тификацию пользователей, подключающихся к информа-
ционным базам.
В общем случае сервер 1С:Предприятия обеспечивает од-
новременную работу нескольких пользователей с несколь-
кими информационными базами, которые могут управ-
ляться различными серверами баз данных (рис. 5.2).
Рис. 5.2. Работа нескольких пользователей с несколькими
информационными базами
При запуске 1С:Предприятия соединение создается по-
сле выбора клиент-серверной информационной базы и
режима запуска (1С:Предприятие\Конфигуратор) в диа-
логе Запуск 1 С: Предприятия и разрывается при завершении
приложения.
Модуль внешнего соединения соединяется с сервером
в процессе исполнения метода Connect и получения ука-
зателя на созданный этим методом СОМ-объект внешнего
соединения. Соединение будет разорвано при уничтоже-
нии COM-объекта внешнего соединения. Это происходит
либо при выполнении метода Release интерфейса IUnknown
на языке С\С++, либо при потере указателя на этот объ-
ект (например, при присвоении COM-объекту значения
Nul 1 или Неопределено, при уничтожении локальной среды
процедуры или функции и т. п.), либо после освобожде-
ния объекта «внешнее соединение» сборщиком мусора
(Java, .NET) (листинг 5.1).
Листинг 5.1. Уничтожение СОМ-объекта
внешнего соединения
// Соединений нет
МодульВнешнихСоединений = Новый С0М0бъект("У8.С0МСоппес1ог");
Соединение! = МодульВнешнихСоединений.
Connect!"Srvr=ServerName:Ref=InfoBaseName“);
// Одно соединение
Соединение2 = МодульВнешнихСоединений.
Connect!"Srvr=ServerName:Ref=InfoBaseName");
// Два соединения
Соединение! = Неопределено;
// Одно соединение
Соединение2 = Неопределено:
// Соединений нет
Выполнение общих функций
Основная задача сервера ЮПредприятия — обеспечение
интерфейса клиентского приложения с базой данных. Он
преобразует запросы, поступающие от клиентского прило-
жения, в запросы на языке Transact SQL, передает их SQL
Server, получает от него результат выполнения запроса, пре-
образует его и передает обратно клиентскому приложению.
Кроме этого, на сервере 1 С: Предприятия сосредоточено
выполнение различных общих функций платформы:
♦ чтение и сохранение конфигураций и настроек пользо-
вателя;
♦ операции над базой данных, включая ограничения дос-
тупа к данным;
♦ хранение значений параметров сеанса;
♦ ведение журнала регистрации;
♦ поддержка оперативной отметки времени;
♦ другие функции (управление объектными блокировка-
ми, идентификаторы и т. п.).
Управление сервером
ЮПредприятия
Сервер 1 С:Предприятия является СОМ+ приложением
и не имеет собственного интерфейса.
Управление сервером 1 С: Предприятия возможно тремя
способами:
♦ средствами операционной системы;
♦ с помощью консоли сервера ЮПредприятия;
♦ программно.
Средствами операционной системы могут быть выполнены
простейшие действия: запуск и установка сервера. Посколь-
ку сервер ЮПредпритятия является СОМ+ приложением,
то эти действия можно выполнить, например, с помощью
утилиты Component Services операционной системы.
Консоль сервера 1С .Предприятия позволяет управлять
специфическими функциями сервера ЮПредприятия,
и ее использование подробно описано в документации.
Программное управление сервером может быть осуществ-
лено как средствами встроенного языка, так и средствами
других программных систем, поддерживающих техноло-
гию СОМ (например, из программ на Visual Basic).
Во встроенном языке сервер ЮПредприятия доступен
через COM-объект V8.C0MConnector. Этот объект поддержи-
вает метод ConnectServerO, который позволяет подклю-
читься к серверу ЮПредприятия по имени компьютера,
на котором он запущен. В результате устанавливается со-
единение с сервером, которое не отображается в списке
активных соединений сервера и не привязано к какой-ли-
бо конкретной информационной базе. Это соединение не
влияет на блокировки информационных баз и баз дан-
ных. В результате становится возможным выполнение
следующих административных действий:
♦ получение списка информационных баз, зарегистриро-
ванных на сервере (GetlnfoBasesO). Для выполнения
этой операции аутентификация не требуется;
♦ получение списка администраторов сервера (GetSrvr-
UsersO). Если существует хотя бы один администратор
сервера, то создание и изменение информационных баз,
зарегистрированных на сервере, может выполняться толь-
ко администраторами сервера ЮПредприятия. Если
не существует ни одного администратора сервера, то
создание информационных баз может выполняться
любым пользователем, а для выполнения каких-либо
административных действий над информационной ба-
зой, необходимо аутентифицироваться с правами адми-
нистратора этой информационной базы;
♦ создание объекта описания администратора сервера
(CreateSrvrUserlnfoO);
♦ создание или модификация администратора сервера
(CreateSrvrllser!)). Если существует хотя бы один адми-
нистратор сервера, то для выполнения этой операции
требуется аутентификация администратора сервера;
♦ удаление администратора сервера (DropSrvrllser!)). Для
выполнения этой операции требуется аутентификация
администратора сервера;
♦ аутентификация в одной или нескольких информаци-
онных базах (AddAuthenticationO). Для того чтобы вы-
полнить какие-либо административные действия над
информационной базой, необходимо аутентифициро-
ваться с правами администратора этой информацион-
ной базы;
♦ получение списка соединений клиентских приложений
с конкретной информационной базой (GetIBConnectionsO).
Выполнение этой операции доступно при наличии ад-
министративных прав в данной информационной базе;
♦ создание объекта описания информационной базы
(CreatelnfoBaselnfo!));
♦ создание новой информационной базы (CreatelnfoBaseO).
Если существует хотя бы один администратор сервера,
то для выполнения этой операции требуется аутенти-
фикация администратора сервера;
♦ удаление информационной базы (DropInfoBaseO). Если
существует хотя бы один администратор сервера, то
для выполнения этой операции требуется аутентифи-
кация администратора сервера;
♦ разрыв клиентского соединения (Disconnect!));
♦ подключение к конкретной информационной базе
(Connect!));
Программное управление сервером ЮПредприятия может
быть использовано, например, для принудительного за-
вершения работы пользователей информационной базы.
При этом нужно учитывать, что после разрыва соедине-
ния соответствующее клиентское приложение завершит-
ся аварийно (листинг 5.2).
Листинг 5.2. Завершение работы пользователей
информационной базы
Коннектор = Новый С0М0бъект("У8.С0МСоппес1ог");
Сервер = Коннектор.ConnectServer("TestServer");
// Аутентифицироваться с административными правами
// в нужной базе
Сервер.AddAuthenticationC"Администратор"
// Создать объект нужной информационной базы
ИнформационнаяБаза = Сервер. CreatelnfoBaselnfoO;
ИнформационнаяБаза.Мате = "TestBase";
// Получить соединения базы
СоединенияБазы = Сервер.6еб1ВСоплесб1оп5(ИнформационнаяБаза);
// Разорвать соединения клиентских приложений
Для Каждого Соединение Из СоединенияБазы Цикл
Сервер.Disconnect(Соединение);
КонецЦикла;
Более подробно использование программного управле-
ния сервером ЮПредприятия можно посмотреть в обра-
ботке Консоль сервера ЮПредприятия, которая находится в
информационно-технологическом сопровождении (ИТС).
Для соединения с сервером ЮгПредприятия из других
программных систем также необходимо получить СОМ-
объект V8.C0MConnector.
Например, аналогичная процедура удаления всех соеди-
нений информационной базы VBScript может выглядеть
следующим образом (листинг 5.3).
Листинг 5.3. Завершение работы пользователей
информационной базы
Dim connector
Set connector = Create0bject(”v8.C0MConnector")
Dim server
Set server = connector.ConnectServerC"TestServer")
server.AddAuthentication "UserName", "UserPassword"
Dim ibDesc
Set ibDesc = server.CreatelnfoBaselnfoO
ibDesc.Name = "TestDB"
Dim connections
connections = server.GetIBConnectionsCibDesc)
Dim i
Dim connection
For i = LBound(connections) To UBound(connections)
set connection = connections(i)
server.Disconnect connection
Next
Работа встроенного языка
на сервере
Одной из важных функций сервера ЮПредприятия яв-
ляется возможность выполнения на нем прикладного
кода 1 С: Предприятия. Для этого используются общие
модули конфигурации, с помощью которых можно пере-
носить выполнение кода с клиентского приложения на
сервер.
Техника передачи выполнения прикладного кода на сер-
вер и обратно подробно рассмотрена в разделе «Органи-
зация выполнения кода на сервере или на клиенте», с. 86.
Здесь мы остановимся на общих рекомендациях, касаю-
щихся выполнения прикладного кода на сервере Ю:Пред-
приятия.
Существует две основные причины, по которым имеет
смысл переносить некоторые действия на сервер 1С:Пред-
приятия:
♦ повышение производительности прикладного решения;
♦ выполнение действий, связанных с управлением досту-
пом к данным.
С целью повышения производительности системы имеет
смысл выносить на сервер обработки больших объемов
данных, не требующие сложных вычислений. Такие обра-
ботки на сервере будут выполняться быстрее из-за того,
что отсутствует звено передачи данных между клиент-
ским приложением и сервером ЮПредприятия. Кроме
того, сервер ЮПредприятия осуществляет более быст-
рый доступ к серверу баз данных.
Не следует переносить на сервер абсолютно все такие об-
работки. Дело в том, что перенос выполнения кода на сер-
вер не всегда дает 100% гарантию существенного роста
производительности. В реальной работе загруженность
сервера 1 (^Предприятия может быть достаточно значи-
тельной, и выполнение большого количества кода на сер-
вере может привести даже к замедлению работы. При
разработке прикладного решения не всегда существует
возможность воспроизвести реальную нагрузку на систе-
му, а одиночные тесты производительности, в отсутствие
реальной рабочей нагрузки, дадут, скорее всего, неверные
результаты. Поэтому прежде чем переносить исполнение
того или иного фрагмента кода на сервер, следует проана-
лизировать возможные последствия этого действия.
Однозначно не рекомендуется переносить на сервер дли-
тельные обработки данных. Это может привести к значи-
тельному неудобству администрирования системы, так
как выполнение кода на сервере прервать нельзя. Поэто-
му подобные длительные обработки желательно разби-
вать на фрагменты, длительность которых ограничена и
не зависит от объема хранимых в информационной базе
данных. В этом случае за одно обращение к серверу мож-
но обрабатывать один такой фрагмент.
Безопасная зона
Одной из важных функций сервера ЮПредприятия, по-
мимо собственно обеспечения интерфейса между клиент-
ским приложением и сервером базы данных, является
создание так называемой безопасной зоны — логической
области системы, в которой данные находятся в безопас-
ности.
В общем случае, различные пользователи системы тем
или иным образом подключаются к базе данных и ис-
пользуют те или иные данные. Очевидно, что разные
пользователи обладают разными правами на разные виды
данных. В этой ситуации сервер ЮПредприятия является
своего рода «барьером», дальше которого информация
базы данных может распространяться только с учетом
всех разрешений, назначенных тому или иному пользова-
телю. Внутри безопасной зоны возможны любые дейст-
вия с данными без учета ограничений, накладываемых
правами пользователей (рис. 5.3).
Рис. 5.3. Безопасная зона
Создание безопасной зоны становится возможным благо-
даря тому, что сервер 1С:Предприятия выполняет кон-
троль ограничений доступа к данным при выполнении
операций с базой данных. Это касается как «обычных»
прав, относящихся к отдельным объектам конфигурации,
так и ограничений доступа к данным, задаваемых на
уровне записей и полей таблиц базы данных. Ограниче-
ния доступа к данным накладываются сервером 1 С: Пред-
приятия в момент обращения к базе данных. При моди-
фикации данных, перед тем как обратиться к серверу баз
данных, сервер 1 С: Предприятия анализирует запраши-
ваемое действие в соответствии с имеющимися правами и
только после этого выполняет (или не выполняет) обра-
щение к серверу баз данных. Таким образом, система га-
рантирует, что данные, доступ к которым не санкцио-
нирован клиентскому приложению, могут существовать
только в безопасной зоне.
Однако следует понимать, что вопрос безопасности дан-
ных не может на 100% быть решен самой системой. Суще-
ствует два момента, в которых нельзя исключить влияние
«человеческого фактора». Если этим моментам не уде-
лить должного внимания, существование безопасной зоны
может быть нарушено. Первый момент связан с исполь-
зованием привилегированных модулей, а второй — собст-
венно с администрированием прикладного решения.
Контроль прав
в привилегированных модулях
Привилегированные модули представляют собой общие
модули, которые выполняются в безопасной зоне без кон-
троля прав. Другими словами, привилегированные модули
компилируются только на стороне сервера и, соответст-
венно, могут быть выполнены только на сервере 1С:Пред-
приятия. При выполнении кода, содержащегося в приви-
легированных модулях, контроль прав не осуществляется.
Наличие привилегированных модулей позволяет решать
целый ряд задач, которые невозможно решить с помощью
прав на объекты конфигурации или с помощью ограниче-
ний доступа к данным на уровне записей и полей. Напри-
мер, задачу, требующую предоставить пользователю воз-
можность выполнить какое-либо одно административное
действие, в то время как все остальные административ-
ные действия должны быть для него недоступны. Более
подробно использование привилегированных модулей
рассмотрено в разделе «Выполнение кода на сервере без
проверки прав», с. 89.
В силу того, что при выполнении привилегированного
модуля контроль прав не осуществляется, такой модуль
может стать «лазейкой», через которую клиент сможет
получить данные, на которые у него нет прав.
Чтобы этого избежать, при разработке привилегирован-
ных модулей следует исходить из того, что в общем слу-
чае не известно, откуда выполнение прикладного кода
было передано в этот модуль. Скорее всего, оно будет пе-
редано именно из того места конфигурации, которое име-
ет в виду разработчик. Однако не исключена ситуация,
что выполнение может быть передано и из другого места
(например, из внешней обработки, если известно имя вы-
зываемой процедуры привилегированного модуля).
Поэтому, прежде чем выполнять какие-либо действия
с данными в привилегированном модуле, следует убе-
диться, что ситуация соответствует той, на которую рас-
считана работа этого модуля.
Приведем пример. Допустим, в филиале нужно обеспе-
чить возможность ввода новых пользователей системы.
В то же время нельзя назначить административные права
кому-либо из пользователей, так как информация, хра-
нящаяся в базе данных, довольно конфиденциальная.
В этом случае может быть принято решение, что ввод но-
вых пользователей в систему будет осуществлять, напри-
мер, только главный менеджер филиала Борисов.
В этом случае создается специальная обработка, которая
пользователю Борисов позволяет задать все параметры,
требуемые для ввода нового пользователя. При выполне-
нии этой обработки управление передается в привилеги-
рованный модуль, в котором собственно и выполняется
создание нового пользователя без проверки прав. При
этом, несмотря на то, что этой обработкой никто кроме
Борисова пользоваться не может, в привилегированном
модуле следует обязательно выполнить проверку того,
что текущим пользователем является Борисов. И только
после этого создавать нового пользователя системы.
Если этого не сделать, то потенциально любой пользова-
тель системы, «подсмотревший» имя вызываемой проце-
дуры, может написать внешнюю обработку, с помощью
которой также обращаться к этой процедуре и создавать
новых пользователей.
Администрирование клиент-
серверного варианта работы
Второй момент, который может ослабить безопасную зону,
используемую в клиент-серверном варианте работы, —
это неграмотное администрирование аппаратных средств,
на которых работает прикладное решение.
Информационная база 1 С:Предприятия представляет
собой совокупность данных, доступ к которым должен
осуществляться исключительно средствами ЮПредпри-
ятия. Поэтому необходимо обеспечить такой порядок ра-
боты прикладного решения, при котором невозможно
использовать данные информационной базы напрямую
механизмами, отличными от ЮПредприятия.
Следующие рекомендации помогут правильно сконфигу-
рировать аппаратные и программные средства, исполь-
зуемые в клиент-серверном варианте работы:
Компьютер сервера баз данных
1. Доступ к компьютеру, на котором установлен SQL
Server, должен быть запрещен для всех, кроме админист-
раторов системы. Доступ должен быть запрещен как фи-
зически (организационными мерами), так и программно,
при этом особое внимание следует уделить списку поль-
зователей Windows, имеющих право интерактивного вхо-
да в серверный компьютер.
2. Доступ к файлам баз данных SQL Server должен быть
запрещен всем пользователям Windows, кроме пользова-
теля, от имени которого работает SQL Server. Пользова-
теля, от имени которого работает SQL Server, можно по-
смотреть или изменить при помощи SQL Server Enterprise
Manager в диалоге свойств SQL Server на закладке Security
в рамке Startup service account. Желательно, чтобы этот
пользователь был предназначен только для SQL Server и
не мог входить ни интерактивно, ни удаленно. При необ-
ходимости доступ к этим файлам может быть разрешен
лишь наиболее квалифицированным администраторам.
База данных SQL Server размещается в специальном
файле, например C:\Program Files\Microsoft SQL Server\MSSQL\
Data\InfoBase.mdf. Наряду с этим файлом SQL Server мо-
жет создавать и другие файлы, в частности файл журнала
транзакций, например C:\Program Files\Microsoft SQL Server\
MSSQL\Data\ib_tmp_log.LDF.
3. Рекомендуется полностью запретить удаленный доступ
через сеть к файлам компьютера, на котором установлен
SQL Server и хранятся базы данных.
4. В SQL Server должна быть включена аутентификация
SQL Server and Windows при помощи SQL Server Enterprise
Manager в диалоге свойств SQL Server на закладке Security.
5. Следует создать в SQL Server пользователя, имеющего
полные права на базу данных, хранящую информацион-
ную базу, с паролем и указать имя этого пользователя и
его пароль в диалоге создания информационной базы.
Необходимо ограничить или запретить доступ к этой базе
данных со стороны других пользователей SQL Server.
Также необходимо установить пароль пользователю sa,
который должны знать только администраторы.
Компьютер сервера ЮПредприятия
1. Доступ к компьютеру, на котором установлен сервер
1С:Предприятия должен быть запрещен для всех, кроме
администраторов системы. Доступ должен быть запре-
щен как физически (организационными мерами), так и
программно, при этом особое внимание следует уделить
списку пользователей Windows, имеющих право инте-
рактивного входа в серверный компьютер.
2. Следует запретить доступ к файлам каталога данных
сервера ЮПредприятия (обычно C:\Documents and Settings\
All Users\Application Data\lC\lCv8) всем пользователям Win-
dows, кроме того, от имени которого работает сервер
1 С:Предприятия (обычно USER1CV8SERVER). Наиболее
важным файлом данных сервера ЮПредприятия явля-
ется файл srvrib.lst, который обычно находится в каталоге
C:\Documents and Settings\All Users\Application Data\lC\lCv8.
Доступ к этому файлу должно иметь только приложение,
являющееся сервером ЮПредприятия.
3. Рекомендуется для компьютера, на котором установ-
лен сервер ЮПредприятия, полностью запретить уда-
ленный доступ к файлам через сеть.
Взаимодействие компьютеров
1. Следует выбрать необходимый уровень защиты прото-
кола связи сервера 1 С:Предприятия и SQL Server. Здесь
важно, что для повышения защищенности протокола на
том компьютере, на котором установлен SQL Server,
в диалоге SQL Server Network Utility можно установить флаг
Force Protocol Encryption, что обеспечит шифрование дан-
ных перед их передачей по сети. При этом аналогичный
флаг необходимо установить на компьютере — сервере
1 С:Предприятия в диалоге SQL Server Client Network Utility.
Нужно учитывать, что установка этого флага приведет
к некоторому снижению производительности.
2. Следует выбрать необходимый уровень защиты прото-
кола связи клиента 1 С: Предприятия с сервером ^Пред-
приятия. Соединение с сервером реализуется механизма-
ми COM\DCOM. Защита протокола передачи данных
между клиентом и сервером возложена на встроенную в
СОМ+ систему безопасности. Поэтому настройку защи-
ты можно сделать на компьютере — сервере ЮПредпри-
ятия при помощи утилиты Component Services. На закладке
Security свойств СОМ+ приложения 1CV8 нужно выбрать
необходимое значение Authentication level for calls. Наи-
большую защиту обеспечивает режим Packet Privacy, под-
разумевающий кодирование данных перед тем, как пере-
давать их по сети. Следует учитывать, что использование
этого режима может привести к заметному снижению
производительности.
Администрирование ЮПредприятия
Административные права следует назначать только тем
пользователям ЮПредприятия, которые являются ад-
министраторами. Пользователь с административными
правами имеет, в частности, возможность выполнить вы-
грузку/загрузку информационной базы, а также выпол-
нять любые изменения прав, тем самым получая доступ
к любым данным информационной базы.
Варианты использования
При использовании клиент-серверного варианта работы
допускаются различные варианты взаимного расположе-
ния сервера баз данных, сервера 1 С: Предприятия и кли-
ентского приложения на компьютерах.
Наиболее желательным является размещение всех трех
приложений на разных компьютерах (рис. 5.4).
В этом случае как сервер баз данных, так и сервер
ЮПредприятия смогут полноценно использовать аппа-
ратные ресурсы и работать максимально производитель-
но. Также этот вариант использования предоставляет
лучшие возможности для масштабирования системы, по-
скольку модификацию аппаратных средств можно произ-
водить независимо, исходя из реальной загрузки того или
иного сервера.
Рис. 5.4. Размещение приложений на разных компьютерах
При умеренной нагрузке на прикладное решение и при
небольших объемах вычислений, производимых на серве-
ре 1С:Предприятия, возможно размещение сервера баз
данных и сервера 1С:Предприятия на одном компьютере
(рис. 5.5).
Рис. 5.5. Размещение сервера баз данных и сервера
1С:Предприятия на одном компьютере
Такой вариант является более дешевым, однако менее
эффективным с точки зрения производительности. Рабо-
та обоих серверов на одном компьютере предъявляет,
в частности, повышенные требования к объему оператив-
ной памяти, которая активно используется как одним, так
и другим приложением.
Также возможны и другие варианты взаимного размеще-
ния приложений, например на одном и том же компьюте-
ре (рис. 5.6).
Рис. 5.6. Размещение сервера баз данных и сервера
1С:Предприятия на рабочей станции
Этот вариант вряд ли имеет смысл использовать для ре-
альной многопользовательской работы, однако он может
часто применяться, например, при разработке приклад-
ных решений одним разработчиком.
Особенности использования
При использовании клиент-серверного варианта работы
следует учитывать некоторые особенности его функцио-
нирования.
Запуск и остановка сервера
При установке первого соединения с информацион-
ной базой сервер 1С:Предприятия выполняет чтение наи-
более важных и часто используемых данных из информа-
ционной базы. Эти данные в дальнейшем могут совмест-
но использоваться несколькими соединениями. Поэтому
установка первого соединения может выполняться не-
сколько дольше, чем второго и последующих. Кроме того,
если соединение является первым для всего сервера
1С:Предприятия после долгого бездействия, то к этому
моменту сервер может быть остановлен механизмом СОМ+
и выгружен из памяти. Поэтому потребуется загрузка
всех его компонентов, что тоже может занять некоторое
время.
Разрыв последнего соединения с данной информацион-
ной базой приводит к выгрузке из памяти всех данных
этой информационной базы, а разрыв последнего соеди-
нения с данным сервером 1 С: Предприятия — выгрузке
большинства входящих в его состав компонент. При этом
если используются установки СОМ+ по умолчанию, то
через 3 минуты после разрыва последнего соединения с
сервером 1С:Предприятия он будет остановлен и выгру-
жен из памяти.
Соединения с сервером
Каждое соединение с информационной базой требует не-
значительных ресурсов, однако в следующих случаях лиш-
ние соединения могут мешать нормальной работе:
♦ соединение с Конфигуратором не позволяет подсоеди-
ниться к информационной базе другим Конфигурато-
ром;
♦ обновление конфигурации базы данных и некоторые
другие операции, требующие монопольного доступа к
информационной базе, не могут быть выполнены, если
соединений с данной информационной базой больше
одного;
♦ если в процессе работы 1 С:Предприятия была начата
транзакция, то эта транзакция ассоциируется с соеди-
нением сервера 1 С:Предприятия с данным клиентским
приложением 1 С: Предприятия. Нештатное завершение
клиентского приложения 1 С:Предприятия в этот мо-
мент может привести к тому, что транзакция останется
незавершенной вместе с неразорванным соединением.
Незавершенная транзакция может быть препятствием
для нормальной работы других клиентских приложе-
ний ЮПредприятия;
♦ при начале редактирования объекта или при выполне-
нии метода <объект>.3аблокировать() на данные объекта
устанавливается пессимистическая блокировка. Все
блокировки объектов также ассоциируются с соедине-
нием и сохраняются либо до момента снятия блокиров-
ки (окончание редактирования или выполнение метода
<объект>. Разблокировать О) или до разрыва соединения.
Неснятые блокировки объектов также могут быть
помехой для работы других клиентских приложений
1 (/Предприятия.
В перечисленных случаях нежелательные соединения не-
обходимо разорвать, для чего обычно достаточно завер-
шить установившие их приложения. Если это затрудни-
тельно, то соединения можно разрывать при помощи
консоли сервера ЮПредприятия или программно. При
этом установившие их приложения завершатся аварийно
и все их несохраненные данные будут потеряны.
Отдельный случай представляют соединения, за которы-
ми уже не стоят никакие приложения. Такие соединения
могут остаться от приложений, завершившихся не штат-
но. Механизм СОМ+ следит за активностью прило-
жения, установившего соединение с СОМ+ сервером,
в большинстве случаев распознает соединения, оставшие-
ся без клиентских приложений, и через 6-8 минут авто-
матически разрывает такие соединения. Если это соеди-
нение мешает продолжению работы то, не дожидаясь
автоматического разрыва соединения механизмами СОМ+,
можно разорвать соединение при помощи консоли серве-
ра ЮПредприятия или программно.
Выполнение кода на сервере
Выполнение кода на встроенном языке, исполняемого на
сервере, невозможно прервать. Это значит, что:
♦ процедура ОбработкаПрерыванияПользователя на сервере
недоступна;
♦ разрыв соединения утилитой администрирования ин-
формационных баз невозможен, если управление нахо-
дится на сервере.
Для прерывания исполнения кода, зациклившегося на
сервере, необходимо перезагружать серверное приложе-
ние, что приводит к перерыву в работе всех клиентов это-
го сервера. Поэтому код, исполняемый на сервере, дол-
жен отлаживаться наиболее тщательно. Следует избегать
выполнения на сервере очень долгих действий (занимаю-
щих десятки минут и часы), а также действий, время ис-
полнения которых может неограниченно расти, с ростом
объема информационной базы.
Отладка кода на сервере
Встроенный в ЮПредприятие отладчик не позволяет от-
лаживать код, исполняемый на сервере. Для отладки ис-
полняемого на сервере кода можно применять различные
методы:
♦ исполнение серверного кода перенести на клиента (ус-
тановив соответствующие флаги в свойствах модулей).
Исполнение модуля на клиенте логически ничем не от-
личается от исполнения его на сервере. Однако так
нельзя проверить работу привилегированных модулей;
♦ воспользоваться файловым вариантом информацион-
ной базы. В этом случае все модули, в том числе и при-
вилегированные, выполняются на клиенте и доступны
отладчику 1 С: Предприятия.
Использование аппаратных
ресурсов сервером
Серверу 1 С:Предприятия доступно не более 2 (или 3) ги-
габайт виртуального адресного пространства. Это адрес-
ное пространство делится между всеми пользователями.
Поэтому учитывать ограничения на максимальные раз-
меры коллекций, выборок из базы данных и текстов за-
просов к базе данных в клиент-серверном варианте более
важно, особенно для кода, исполняемого на сервере.
Кроме того, клиент-серверный вариант ЮПредприятия
накладывает ограничения на использование нескольких ин-
формационных баз на одном сервере 1 С: Предприятия. Не
следует через один сервер 1 С: Предприятия работать со
многими информационными базами. Подсоединение к ин-
формационной базе хотя бы одного клиента приводит к за-
грузке ее конфигурации в память сервера (для конфигура-
ции Управление Производственным Предприятием — около
90 мегабайт виртуального адресного пространства). Под-
соединение последующих клиентов к этой же информаци-
онной базе дополнительных больших объемов памяти не
потребует. Однако подсоединение клиента к другой инфор-
мационной базе на этом же сервере приведет к загрузке и ее
конфигурации тоже. Таким образом, факт одновременного
подсоединения клиентов хотя бы к 11 различным информа-
ционным базам с конфигурациями, сравнимыми с Управ-
ление Производственным Предприятием, может привести
сервер ЮПредприятия в неработоспособное состояние.
Совместная работа с сервером
Нежелательно использовать для разработки и тестирова-
ния конфигураций тот сервер ЮПредприятия, на кото-
ром работает большое количество пользователей. Это обу-
словлено тем, что сохранение конфигурации и обновление
конфигурации базы данных требует значительного объема
свободного виртуального адресного пространства, которо-
го в нагруженном сервере 1 С: Предприятия может не быть.
Использование виртуальной
памяти
Размер файла подкачки страниц компьютера, на котором
установлен сервер 1 С: Предприятия, должен быть не менее
2 гигабайт (если используется режим 3Gb, то 3 гигабайт).
Размещение сервера
SQL-сервер целесообразно размещать на отдельном от
сервера 1С:Предприятия компьютере, если:
♦ объем оперативной памяти компьютера с сервером
ЮПредприятия меньше 4 гигабайт;
♦ на сервер 1С:Предприятия вынесена обработка данных;
♦ возможна установка Microsoft SQL Server на 64-разряд-
ной системе.
Если конфигурация выполняет какие-нибудь вычисле-
ния на сервере, то необходимо учитывать возможность
одновременного выполнения таких вычислений по ини-
циативе нескольких пользователей. Если количество
пользователей, которые могут выполнять данное вычис-
ление одновременно, достаточно большое, то серверный
компьютер может быть перегружен, что приведет к сни-
жению производительности системы.
Длительная работа сервера
Длительная работа сервера 1 С:Предприятия приводит
к эффекту фрагментации виртуального адресного про-
странства серверного приложения, что может стать при-
чиной некоторого снижения производительности сервера
ЮПредприятия. Для борьбы с этим эффектом рекомен-
дуется периодическая перезагрузка серверного приложе-
ния 1С:Предприятия.
Организация выполнения кода на сервере или на клиенте
Используя возможность управления компиляцией модулей
можно передавать исполнение кода с клиента на сервер; по-
сле выполнения вызванной процедуры или функции, систе-
ма продолжит исполнение кода на клиенте. Это позволяет,
например, сложные алгоритмы расчета выполнять не на
клиентской машине, а на более мощном сервере, что увели-
чивает общую производительность прикладного решения.
Передача выполнения с клиента на сервер может быть
выполнена только путем вызова процедуры общего модуля.
После запуска прикладного решения выполнение кода
всегда осуществляется на клиенте. В процессе работы ис-
полнение кода, может быть передано на сервер следую-
щим образом: при вызове процедуры или функции, ее по-
иск сначала осуществляется на стороне клиента. Если
скомпилированный контекст клиента не содержит вызы-
ваемой процедуры, ее поиск будет осуществлен на сторо-
не сервера. Если вызываемая процедура будет найдена, то
выполнение кода будет передано на сервер. После того
как вызываемая процедура завершит свою работу, выпол-
нение будет передано обратно на клиента.
Простейшим примером передачи выполнения кода на сер-
вер может служить вызов экспортируемой процедуры об-
щего модуля, у которого установлено только свойство Сер-
вер. Экземпляр этого модуля будет скомпилирован только
на стороне сервера. При вызове в модуле отчета этой экс-
портной процедуры она не будет найдена на стороне кли-
ента, и выполнение будет передано на сервер (рис. 5.7).
Рис. 5.7. Передача выполнения кода на сервер
Аналогичным образом выполнение может быть передано
на сервер при помощи инструкций препроцессору. На-
пример, общий модуль, который компилируется как на
стороне сервера, так и на стороне клиента, содержит сле-
дующий текст (листинг 5.4).
Листинг 5.4. Передача исполнения кода на сервер
с использованием инструкций препроцессора
Процедура ТекущийДолгО Экспорт
КонецПроцедуры
#Если Сервер Тогда
Процедура ПересчитатьО Экспорт
КонецПроцедуры
^КонецЕсли
Процедура Проверить О Экспорт
КонецПроцедуры
Тогда экземпляр этого модуля, скомпилированный на
стороне сервера, будет содержать описание процедуры
Пересчитать, в то время как в экземпляре, скомпилирован-
ном на стороне клиента, это описание будет отсутство-
вать. Тогда, при вызове этой процедуры, например, в мо-
дуле отчета, она не будет найдена на стороне клиента,
и выполнение перейдет на сервер (рис. 5.8).
После того, как выполнение передано на сервер, все ос-
тальные вызовы процедур и функций будут выполняться
также на стороне сервера (рис. 5.9).
Важно отметить, что разработчик не может «управлять»
передачей выполнения с сервера обратно на клиента. Вы-
полнение будет передано только после завершения вы-
полнения вызванной процедуры или функции. Другими
словами, если выполнение осуществляется на сервере и
вызываемая процедура не найдена в скомпилированном
на стороне сервера коде, то будет выдано сообщение об
ошибке даже в том случае, если вызываемая процедура
присутствует в экземпляре, скомпилированном на сторо-
не клиента (рис. 5.10).
Рис. 5.8. Передача выполнения кода на сервер
Рис. 5.9. Исполнение вызовов процедур на сервере
Рис. 5.10. Исполнение вызовов процедур на сервере
Изменение поведения
объектов в зависимости
от контекста выполнения
Инструкции препроцессору могут быть использованы
для того, чтобы изменять поведение объекта в зависимо-
сти от того, создан он на клиенте или на сервере.
Например, пусть после проведения документа Накладная
требуется выводить на экран печатную форму документа
с использованием табличного документа. В этом случае
вызов функции, осуществляющей вывод этой формы Вы-
вестиФормуНакладной в процедуре обработки проведения
документа, можно заключить в инструкции препроцессо-
ру, и этот вызов будет присутствовать только в экземпля-
ре модуля объекта документа Накладная, скомпилирован-
ном на стороне клиента (листинг 5.5).
Листинг 5.5. Условная компиляция модуля объекта
Процедура ОбработкаПроведения(Отказ, Режим)
#Если Клиент Тогда
ВывестиФорнуНакладной();
^КонецЕсли
КонецПроцедуры
Таким образом, если в будущем возникнет необходи-
мость, например, создания обработки для проведения
группы накладных на сервере (ПровестиНакладные), такая
обработка будет работать корректно, поскольку вызов
функции ВывестиФормуНакладной будет отсутствовать в
экземпляре модуля, скомпилированном на стороне серве-
ра; в противном случае попытка использования объекта
ТабличныйДокумент на сервере (для вывода печатной фор-
мы) привела бы к ошибке (рис. 5.11).
Рис. 5.11. Проведение накладной на сервере и клиенте
Рис. 5.12. Использование функции модуля приложения
Особенности использования
экспортируемых переменных,
функций и процедур модуля
приложения (модуля
внешнего соединения)
При написании текстов модулей объектов не рекоменду-
ется использовать экспортируемые переменные, функ-
ции и процедуры модуля приложения или модуля внеш-
него соединения. Это связано с тем, что модуль объекта
может компилироваться как на стороне сервера, так и на
стороне клиента, в то время как модуль приложения и
модуль внешнего соединения компилируются только на
стороне клиента. В результате может возникнуть ситуа-
ция, когда объект будет обрабатываться некоторой сер-
верной обработкой и не сможет обратиться к экспорти-
руемым процедурам/функциям модуля приложения или
модуля внешнего соединения.
Например, если при проведении документа Накладная
с помощью экспортируемой функции модуля прило-
жения проверяется правильность заполнения рекви-
зитов документа, то при групповом проведении доку-
ментов на сервере будет выдана ошибка исполнения
(рис. 5.12).
Передача параметров
на сервер и возврат
значений
При передаче выполнения кода на сервер, как правило,
выполняется передача некоторых параметров вызывае-
мой процедуры или функции. Также, в случае вызова
функции, будет выполняться передача результата работы
функции с сервера на клиента.
Важно учитывать, что не все типы значений и объекты,
работа с которыми возможна на сервере, могут быть пере-
даны с клиента на сервер и обратно. В общем, можно ска-
зать, что на сервер могут быть переданы немутабельные
объекты (то есть объекты, значения которых не могут из-
меняться) и мутабельные объекты некоторых определен-
ных типов.
Немутабельными, например, являются примитивные типы,
ссылки, значения системных перечислений, хранилище
значения. Что касается системных перечислений, то, не-
смотря на то, что в принципе все они могли бы участво-
вать в обмене с сервером, допускается передача только
тех, которые не имеют отношения к интерфейсным объ-
ектам (так как интерфейсные объекты не могут использо-
ваться на сервере). Также могут передаваться некоторые
универсальные коллекции значений: Структура, Соответ-
ствие, ТаблицаЗначений, Массив и др. Важно, что элементы
этих коллекций не должны содержать мутабельных зна-
чений.
Точная информация о возможности использования ти-
пов значений и объектов на сервере, и передаче их между
клиентом и сервером, находится в документации, в опи-
сании конкретных объектов.
Выполнение кода на сервере
без проверки прав
Выполнение кода на сервере, помимо решения задач про-
изводительности прикладного решения, может также
использоваться для выполнения действий, которые за-
прещены текущими правами пользователя. Для этого ис-
пользуются общие модули, у которых установлено свой-
ство Привилегированный. Такие модули могут исполняться
только на сервере, и при их выполнении сервер не осуще-
ствляет проверку прав.
Необходимость в использовании привилегированных мо-
дулей может возникнуть, например, когда стандартных
возможностей системы прав доступа не хватает для того,
чтобы описать специфику работы пользователя.
Например, есть филиал компании, в котором ни один из
сотрудников не имеет административных прав. Инфор-
мационная база обслуживается специалистами централь-
ного офиса, которые периодически приезжают в филиал.
Однако для текущей работы филиала необходимо обес-
печить возможность добавления в информационную базу
новых пользователей самими сотрудниками филиала.
Сложность этой задачи заключается в том, что для того,
чтобы пользователь информационной базы имел возмож-
ность модифицировать список пользователей, он должен
обладать административными правами. Однако админи-
стративные права, помимо модификации пользователей,
позволяют выполнять и целый ряд других операций с ба-
зой данных, например редактирование основной конфи-
гурации, загрузку/выгрузку информационной базы и пр.
В такой ситуации выполнение кода без проверки прав на
сервере позволяет разрешить добавление пользователей
в информационную базу, в то время как все администра-
тивные функции для данного пользователя запрещены.
Реализовать это можно с помощью обработки, которая
создает новый объект ПользовательИнформационнойБазы и пре-
доставляет возможность заполнить все его реквизиты:
имя, пароль, набор прав и пр. Затем выполнение переда-
ется в процедуру привилегированного модуля, в которую,
в качестве параметра, также передается и сам объект Поль -
зовательИнформационнойБазы. Для записи этого объекта тре-
буется наличие административных прав у текущего поль-
зователя, но так как в привилегированном модуле код
выполняется без проверки прав, то новый пользователь
успешно добавляется в список пользователей, после чего
управление передается обратно на клиента.
В приведенной выше последовательности действий есть
один важный момент, на который всегда следуют обра-
щать пристальное внимание при написании текстов при-
вилегированных модулей.
При разработке прикладного решения подразумевается,
что «рядовой» пользователь не обладает административ-
ными правами и не имеет доступа к тексту конфигу-
рации. Однако пользователю может быть разрешено ис-
пользование внешних обработок, а значит, он может
попытаться обратиться к функции привилегированного
модуля из своей собственной обработки и выполнить те
действия, на которые, возможно, у него не должно быть
прав.
Для исключения такой ситуации, перед тем, как в приви-
легированном модуле выполнять какие-либо действия,
следует удостовериться, что эта процедура вызвана именно
тем пользователем, который имеет на это право (рис. 5.13).
Рис. 5.13. Схема проверки прав в привилегированном модуле
Например, добавление новых пользователей в информа-
ционную базу может быть разрешено только менеджеру
филиала, причем даже менеджер не должен иметь воз-
можности добавлять пользователей с административ-
ными правами. В то же время нужно предусмотреть, что
администратор системы должен иметь возможность с по-
мощью той же обработки добавить пользователя с любы-
ми (в том числе и административными) правами. В этом
случае текст привилегированного модуля может выгля-
деть следующим образом (листинг 5.6).
Листинг 5.6. Процедура привилегированного модуля
Процедура ЗаписатьПользователя(ПользовательИБ) Зкспорт
// Проверить наличие роли Администратор
//у добавляемого пользователя.
РольАдминистратор = Метаданные.Роли.Администратор:
Если ПользовательИБ.Роли.Содержит(РольАдминистратор) Тогда
// Проверить у текущего пользователя
// наличие адиинистративных прав.
Если РольДоступна(РольАдминистратор) Тогда
// Выполнить запись нового пользователя.
ПользовательИБ.ЗаписатьО;
Иначе
Сообщить!"Отсутствуют административные права.
(Добавление нового пользователя не выполнено.");
КонецЕсли;
Иначе // у добавляемого пользователя
// нет роли Администратор
// Проверить, что текущий пользователь обладает
// правами Менеджера или Администратора
Если РольДоступна(РольАдминистратор)
ИЛИ
РольДоступнаСМетаданные.Роли.Менеджер) Тогда
// Выполнить запись нового пользователя.
ПользовательИБ.ЗаписатьО;
Иначе
Сообщить("Недостаточно прав доступа
| для добавления пользователя.”);
КонецЕсли:
КонецЕсли:
КонецПроцедуры
Сначала проверяется, назначены ли административные
права добавляемому пользователю. Если добавляется
пользователь с административными правами, то проверя-
ется, является ли текущий пользователь администрато-
ром. Если же добавляется пользователь без администра-
тивных прав, то проверяется, является ли текущий
пользователь менеджером или администратором. Запись
нового пользователя выполняется только при соблюде-
нии перечисленных условий. В противном случае выда-
ется сообщение об отсутствии прав, и выполнение воз-
вращается на клиента.
Глава 6. Хранение информации
Задачи хранения информации
При создании любых решений в области автоматизации
практически всегда приходится решать задачи хранения
информации. При этом поднимаются вопросы собствен-
но предназначения хранимой информации и многочис-
ленные технологические вопросы.
К технологическим вопросам можно отнести те, которые
приходится решать для достижения оптимального соот-
ношения показателей:
♦ объем;
♦ надежность;
♦ функциональность;
♦ быстродействие
Причем на всех этапах жизненного цикла информации:
♦ запись информации;
♦ хранение информации;
♦ получение информации;
♦ удаление информации.
При создании бизнес-приложений сложность решений
этих задач обусловлена наличием противоречий между:
♦ необходимостью обеспечения удобства представления
логики взаимодействия сущностей в информационной
модели;
♦ необходимостью хранения больших объемов информа-
ции;
♦ повышенными требования к широкой функционально-
сти и высокой производительности доступа к этим дан-
ным.
Например, чем больше объем — тем, в общем случае,
сложнее обеспечение скорости доступа к информации
(рис. 6.1).
Рис. 6.1. Схема противоречий между требованиями
к хранимой информации
И в результате «очевидные» прямые решения одних во-
просов ухудшают возможности решения других.
Например, хранение информации о происходящих в жиз-
ни автоматизируемого предприятия событиях в виде на-
бора неструктурированных текстов — идеальное решение
с точки зрения простоты и скорости регистрации. Однако
последующая обработка этой информации для составле-
ния каких бы то ни было аналитических отчетов в таком
случае будет сопряжена с колоссальными временными
затратами. Потому что, как для решения задачи поиска
информации обо всех продажах предприятия, так и для
поиска информации о продажах одному покупателю, не-
обходимо будет пересмотреть данные всех текстов.
И чем больше функциональных возможностей потребу-
ется на этапе получения информации, тем дольше будут
работать соответствующие обработки, зачастую по не-
скольку раз «просматривая» одну и ту же информацию,
но уже с разными целями.
Объектно-реляционная парадигма системы 1С:Предпри-
ятие позволяет в принципе решить проблему соотноше-
ния удобства представления и манипулирования объек-
тами, отражающими прикладные сущности, с должной
надежностью и эффективностью обработки больших объ-
емов информации этих объектов в базе данных.
Объекты и процессы прикладной области отражаются
в решении посредством объектов конфигурации. Таким
образом объекты конфигурации обеспечивают удобство
манипулирования данными, характеризующими приклад-
ные объекты и процессы.
Но сами данные объектов хранятся в реляционной базе
данных (в виде таблиц, полей, индексов), при этом обес-
печиваются вопросы оптимального быстродействия при
больших объемах информации (рис. 6.2).
Рис. 6.2. Схема представления и манипулирования данными
в 1С:Предприятии
В системе 1С:Предприятие все возможные к применению
в решениях прикладные объекты прототипированы. Каж-
дый прототип отвечает за отражение в прикладном реше-
нии определенной совокупности объектов или процессов
прикладной области, имеющих схожие поведенческие ха-
рактеристики и схожую роль в общей картине решения.
Примерами прототипов являются справочники, докумен-
ты, регистры различных видов и так далее.
В рамках средств платформы для каждого прототипа уже
предопределены:
♦ оптимальная, для большинства задач, структура хране-
ния информации в реляционной базе данных;
♦ набор средств встроенного языка для манипулирова-
ния этой информацией;
♦ методы, свойства, события и типовые, для решаемых
задач, операции;
♦ способы отображения и редактирования;
♦ средства регулирования прав доступа и т. д.
Рис. 6.3. Пример представления и манипулирования данными
Таким образом облегчается работа разработчика конкрет-
ного прикладного решения. С точки зрения эффективно-
го хранения информации, вместо решения задач «низко-
го» уровня он занят решением вопросов:
♦ выбора среди прототипов нужных;
♦ создания в рамках прототипов объектов с наиболее подхо-
дящим составом для отражения прикладных сущностей;
♦ обеспечения обмена информацией и взаимодействия
между созданными объектами.
Обеспечение же всей остальной необходимой функцио-
нальности берет на себя система. Но и в этих вопросах
у разработчиков достаточно широкие возможности, при
необходимости «подправления» поведения программы.
В частности, при решении задач, связанных с вводом
и получением информации для последующего ана-
лиза.
Например, при отображении динамических списков сис-
тема считывает из базы данных содержимое только види-
мых полей и полей, необходимых «для технологических
нужд». Если же разработчику необходимо сделать так,
чтобы данные некого поля, не отображаясь, тем не менее,
считывались из базы данных вместе с остальными, он мо-
жет этого добиться. Подробно это описано в разделе «Ко-
лонки списка», с. 59.
Итак, вернемся к общим вопросам, связанным с обеспече-
нием эффективного хранения информации. Прежде все-
го, они не являются самоцелью.
К выбору прототипов объектов для использования в рам-
ках решения необходимо подходить с точки зрения обес-
печения целей автоматизации и областей применимости
прототипов. А вот уже если одинаковая функциональность
может быть достигнута различными, альтернативными,
с точки зрения организации хранения информации, путя-
ми, то выбор оптимального варианта построения конфи-
гурации как раз и будет определяться оптимальностью
решения вопросов хранения информации.
Причем разработчику необходимо решать эти вопросы
в комплексе. Потому что все объекты будут тесно связа-
ны между собой логическими, информационными, интер-
фейсными и прочими связями в интересах преследова-
ния общих целей автоматизации.
В общем виде взаимосвязь и предназначение объектов,
относящихся к соответствующим прототипам, могут быть
описаны следующим образом (рис. 6.4).
Рис. 6.4. Взаимосвязь различных групп объектов
Если требуется хранить в базе данных информацию, из-
меняющуюся достаточно редко, работа с которой строит-
ся по принципу «ввели один раз, но используется много
раз», наиболее удобны для хранения такой информации
объекты из блока условно-постоянная информация. То есть
справочники, перечисления, константы, планы видов ха-
рактеристик — при решении практически любых задач.
Планы счетов, планы видов расчетов и т. п. — при реше-
ниях специфичных задач, сопряженных с использовани-
ем принципа «двойной записи», использованием меха-
низмов сложных периодических расчетов и т. д.
Если требуется хранить информацию о происходящих
в жизни автоматизируемого предприятия действиях (со-
бытиях и выполняемых операциях), то есть — информа-
цию, для которой важна привязка ко времени, то наибо-
лее удобно использовать документы. На схеме к этой же
группе относятся и другие объекты, которые используют-
ся для решения вопросов дополнительной функциональ-
ности системы при обслуживании этой информации:
♦ журналы — средства визуального группирования ин-
формации разных документов;
♦ последовательности — средства логического группиро-
вания информации разных документов;
♦ нумераторы — средства группирования разных доку-
ментов для ведения единой нумерации.
Если требуется хранить информацию о состоянии пока-
зателей, учитываемых в системе, то более удобны для ре-
шения этих задач объекты из группы регистры. Причем
показатели могут иметь привязку ко времени или не
иметь ее, быть наиболее общими или достаточно специ-
фичными, предназначенными к использованию в специ-
альных моделях учета (те же: «двойная запись», «слож-
ные периодические расчеты» и т. д.).
Чаще всего модель обмена информацией между объекта-
ми вышеописанных прототипов обслуживает следующую
модель автоматизации бизнес-решений:
♦ требуемые аналитические и информационные материа-
лы о различных аспектах состояния дел на автоматизи-
руемом предприятии получаются пользователями по-
средством отчетов и обработок (объектов, специально
предназначенных для обеспечения вывода информации
в удобном для пользователя виде);
♦ для обеспечения максимального быстродействия фор-
мирования отчетной информации о состоянии учиты-
ваемых в системе показателей, алгоритмы представле-
ния этой информации берут ее в уже готовом (или
почти готовом виде, с последующей «дообработкой»)
из регистров;
♦ изменение состояния учитываемых показателей в реги-
страх производится не произвольным образом, а при
наличии «документального подтверждения». То есть
информация регистров вторична, она заполняется на
основании данных документов. Ведь именно докумен-
ты служат для обеспечения регистрации происходящих
в жизни автоматизируемого предприятия событий;
♦ однозначность толкования вводимой в документы ин-
формации обеспечивается организацией заполнения до-
кументов посредством выбора элементов объектов хра-
нения условно-постоянной информации, отражающих
объекты прикладной области.
Однако, как уже было замечено выше, разработчик не
обязан слепо следовать предлагаемой логике. В ситуаци-
ях, когда это окажется оправданным, можно применять
приемы, «упрощающие» или даже полностью «отвергаю-
щие» ее.
Например, в платформе системы 1С:Предприятие есть
возможности и средства прямого интерактивного ввода
информации в регистры, формирования отчетов на осно-
вании данных первичных документов, заполнения спра-
вочников посредством обработок и так далее.
Более того, рассмотрение и оценка возможных вариантов
выбора прототипов и объектов будет производиться фак-
тически каждый раз заново, для данной конкретной си-
туации данного конкретного решения. Потому что даже в
рамках преследования одинаковых целей автоматизации,
но для разных условий функционирования эффективная
композиция структуры объектов в рамках решения мо-
жет оказаться разной.
Например, ситуации для предприятия, заключающего
в течение года сто сделок по десять миллионов рублей,
и для предприятия, заключающего в год десять миллио-
нов сделок по сто рублей, — с точки зрения оптимизации
хранения информации различаются.
Поэтому цель данного раздела не навязать «единственно
верную» структурную технологию решения задач хране-
ния информации (тем более что такой не существует),
а показать возможности решения вопросов хранения ин-
формации. И зачастую, — в сравнении плюсов и мину-
сов альтернативных вариантов использования для этих
решений различных видов объектов системы 1С:Пред-
приятие.
Варианты подходов к решению задач хранения информации
Хранение информации, общей
для информационной базы
При решении вопросов хранения общей информации
есть возможности организовать решения в рамках работы
с конфигурацией или с базой данных.
Использование общих картинок
Например, картинки с логотипами юридических лиц ком-
пании могут храниться в составе общих картинок конфи-
гурации, а могут в составе реквизитов справочника (на-
пример, справочника Организации) (рис. 6.5).
С точки зрения надежности хранения информации успеш-
ность обращения к картинке в первом случае «гарантиру-
ется» неизменностью конфигурации, во втором — мерами
разграничения прав доступа пользователей к объектам
базы данных (то есть при неудачном стечении обстоя-
тельств при обращении к картинке может выясниться,
что она удалена или модифицирована пользователем).
Использование макетов
Если предпочтение отдается хранению информации на
уровне конфигурации, то, кроме картинок, возможно ис-
пользование макетов — общих макетов и макетов объек-
тов конфигурации.
При этом могут быть использованы следующие виды ма-
кетов:
♦ макет текстового документа;
♦ макет табличного документа;
♦ макет двоичных данных;
♦ макет ActiveDocument;
♦ макет HTML-документа;
♦ макет географической схемы.
Конфигурация * ? X
Рис. 6.5. Пример хранения картинок в составе конфигурации
Чаще всего макеты используются для хранения данных
шаблонов нужных типов.
Например, когда в конфигурации нужно хранить «краси-
вый» шаблон приглашения, разработанный в Word, с це-
лью его автоматического заполнения при выполнении со-
ответствующей задачи работы пользователя (рис. 6.6).
$ Конфигурация Примеры: Приглашение - ~ X
Рис. 6.6. Пример хранения макета ActiveDocument
При этом можно макеты загружать из файлов, а можно
создавать «пустые» макеты нужного вида (рис. 6.7).
Конструктор макета
Синоним:
Комментарий:
Загрузить из Ф<
X
- Выберите тип »
О Табличный.
О Текстовый.
О Двоичные л
@ Active docur
О HTML докут
О ГеограФиче
| Готово ] | Отмена 11 Справка |
Рис. 6.7. Создание макета
Имя:
Но, кроме того, макеты могут, например, использоваться
в ситуациях, когда необходимо организовать для отчетов
«запоминание» данных для их построения.
Так, в ряде типовых решений фирмы «1С» используются
технологии «универсальных отчетов», основанные на хра-
нении в макете отчета информации, согласно которой от-
чет впоследствии строится, и использовании возможно-
стей «гибкой донастройки» этой информации непосред-
ственно в макете (рис. 6.8).
Рис. 6.8. Хранение настроек отчета в макете
табличного документа
Хранения единичных
значений условно-постоянной
информации
Зачастую при решении задач необходимо реализовывать
хранение данных неких единичных значений, которые
меняются крайне редко.
Использование констант
Константы — классические объекты для хранения таких
данных. Добавлять новые константы или удалять старые
можно только в режиме конфигурирования, но вот запол-
нение и модификация значений обычно производится
пользователями (если не ограничен доступ).
При решении прикладных задач посредством констант
обычно запоминаются общие для всей информационной
базы значения. Можно привести примеры таких констант,
как ОсновнаяБазоваяВалюта или ОсновнаяОрганизация.
Также в константах могут храниться значения по умолча-
нию для поддержания работы критичных к пустым значе-
ниям алгоритмов. Такими константами являются, напри-
мер, константы НачалоРабочегоДня, ОкончаниеРабочегоДня.
Кроме этого, благодаря тому, что значения, хранящиеся
в константе, общие для всех, с помощью констант можно
организовать информирование пользовательских сеансов
работы с программой.
Например, пользователь с административными правами
имеет право устанавливать для булевой константы Заверше-
ниеРаботы значение Истина. А соответствующая обработка
ожидания проверяет значение этой константы и в случае
необходимости завершает пользовательский сеанс. Пример
данного механизма реализован в составе демонстрационной
конфигурации «Хранение информации и учет движения
средств», которая находится на прилагаемом компакт-диске.
Необходимая функциональность реализуется в рамках
модуля приложения (листинг 6.1).
Листинг 6.1. Фрагмент модуля приложения
Перем ЗавершитьРаботу:
Процедура ПриНачалеРаботыСистены()
КонтрольРежимаЗавершенияРаботыПопьзователей();
ПодключитьОбработчикОжидания(
"КонтрольРежинаЗавершенияРаботыПользователей". 180);
КонецПроцедуры
Процедура
КонтрольРежимаЗавершенияРаботыПользователей() Экспорт:
// Определить текущее значение константы
Завершение = Константы.ЗавершениеРаботыПользователей.
Получить!);
Если Завершение Тогда
Если ЗавершитьРаботу Тогда
// Завершить работу окончательно
ЗавершитьРаботуСистемыО;
Иначе
// Предупредить пользователя и приготовиться
// завершить работу в следующий раз
ТекстПредупреждения = "Работа системы будет
|автоматически завершена через 3 минуты!";
Предупреждение(ТекстПредупреждения, 30.
"Завершение работы");
ЗавершитьРаботу = Истина;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
//-...............
// Выполнить начальную инициацию флага завершения работы
ЗавершитьРаботу = Ложь;
Использование регистров
сведений
В случае когда необходимо хранить информацию, общую
для базы данных, но используемую для отдельных на-
правлений учета или отдельных подсистем конфигура-
ции, может оказаться оправданным хранение единичных
условно-постоянных значений не посредством констант,
а посредством ресурсов регистра сведений.
Рассмотрим, например, непериодический независимый
регистр сведений УчетнаяПолитика (рис. 6.9).
йЛ УчетнаяПолитика
i-JL Измерения
ф- Ресурсы
..| ВестиПартионныйУчетПоСклацам
— f СписыватьПартииПриПроведенииДокументов
— f СпособО ценкиМПЗ
..I ПараметрАВСКлассиФикацииПокупателей
--1 ПараметрРаспределенияПокупателейПоСтадиям
— f СтратегияСписанияПартийТоваровПоСтатусам
| Иелмъ зомгьС*л«кW1 оКоличествуТ овара
| ИстжхшхввгьСкмвм^ЛоСуммеДокумента
— g Итзмжв«гкС*мв«»/1о8иад0плать!
..(I ВедениеУчетаПоПроектам
— I НеВключатьНДСВСтоимостьЛаргий
2 Реквизиты
Рис. 6.9. Структура регистра УчетнаяПолитика
Возможности пользователей по модификации значений бу-
дут определяться средствами разграничении прав доступа.
Обратите внимание: в данном регистре не подразумева-
лось использование измерений, а значит, разрезов учета
значений ресурсов. То есть данные регистра могут ис-
пользоваться как общие для всей базы данных.
Подробнее о регистрах сведений можно прочитать в раз-
деле «Хранение информации в регистрах сведений», с. 107.
Использование перечислений
Для решения задач, когда необходимо хранить уже не
единичные значения, а некие конечные наборы значений
и при этом не подразумевается их модификация пользо-
вателями, возможно применение перечислений.
Все операции по добавлению, изменению, удалению зна-
чений измерений производятся только в режиме работы
Конфигуратор.
Само же хранение информации перечислений реализует-
ся в соответствующих таблицах базы данных (по одной
для каждого перечисления) (рис. 6.10).
I. J fI-- "• ЧастноеЛицо \
I !Организация
' {”2 Макеты
&{..} Виды Договоров
Е3{. ) РазмещениеЗаказовПокупэтелей
Й { ) ВиаыОпераций
Таблица перечисления "ВидыКонтрагентов" в базе данных
Порядок Ссылка
0 ЧастноеЛицо
1 Организация
Рис. 6.10. Хранение значений перечислений
Обращение для чтения этой информации возможно как
средствами табличной модели (запросы), так и объектны-
ми методами.
Если, например, в ходе обработки необходимо использо-
вать заранее известное значение перечисления, то его
можно получить с помощью обращения к глобальному
контексту (листинг 6.2).
Листинг 6.2. Пример получения значения перечисления
ЗаполняемоеЗначениеВидаКонтрагента =
Перечисления.ВидыКонтрагентов.ЧастноеЛицо;
Еще раз подчеркнем: при использовании такого кода раз-
работчик уверен, что данное значение перечисления не
может быть удалено или изменено пользователем, по-
скольку модификация этих данных возможна только в ре-
жиме Конфигуратор.
Кроме того, многие «типовые операции», связанные с ис-
пользованием перечислений, уже реализованы средства-
ми платформы.
Например, в ходе некой обработки надо предложить поль-
зователю выбрать значение перечисления Виды Контраген-
тов. Задача может быть решена так (листинг 6.3).
Листинг 6.3. Пример организации интерактивного
выбора значения перечисления
СписокЗначенийПеречисления = Новый СписокЗначений;
// Прочитать значения перечисления из базы данных
Запрос = Новый Запрос;
Запрос.Текст = "
|ВЫБРАТЬ
ВидыКонтрагентов.Ссылка КАК Значение,
ПРЕДСТАВЛЕНИЕ(ВидыКонтрагентов.Ссылка) КАК
ПредставлениеЗначения
| ИЗ
| Перечисление.ВидыКонтрагентов КАК ВидыКонтрагентов";
Результат = Запрос. ВыполнитьО;
Выборка = Результат.ВыбратьО;
Пока Выборка.Следующий() Цикл
// Заполнить значения списка
СписокЗначенийПеречисления.Добавить(Выборка.Значение,
Выборка.ПредставлениеЗначения);
КонецЦикла;
// Предложить пользователю выбрать значение
ВыбранноеЗначение = СписокЗначенийПеречисления.
ВыбратьЗлемент("Выберите вид контрагента"):
Краткий комментарий: запросом из таблицы перечисле-
ния ВидыКонтрагентов считываются значения и представ-
ления для каждой записи. В цикле выборки из результата
запроса заполняются значения и представления списка
значений СписокЗначенийПеречисления. В конце пользова-
телю предлагается выбрать значение из списка СписокЗна-
ченийПеречисления.
Однако если бы выбор значения перечисления нужен
был для заполнения поля, имеющего визуальное пред-
ставление в форме обработки, то данный код писать не
пришлось бы вообще. Достаточно было бы установить со-
ответствующий тип значения поля ввода (Перечисление-
Ссылка.ВидыКонтрагентов) (рис. 6.11).
Дальнейшая функциональность была бы реализована сис-
темой автоматически (рис. 6.12).
Рис. 6.12. Выбор значения перечисления в поле ввода
Использование
предопределенных лементов
В ситуациях, когда требуется сочетать «гарантии нали-
чия» информации с гибкими возможностями модифика-
ции этой информации, интересные возможности предо-
ставляет использование предопределенных элементов спра-
вочников, планов видов характеристик, планов счетов и т. п.
Благодаря тому что добавление и удаление предопреде-
ленных элементов возможно только в режиме работы
Конфигуратор, разработчик может быть уверен в их «со-
хранности» при любых действиях пользователей. Кроме
этого, каждый предопределенный элемент обладает уни-
кальным именем, что позволяет создавать алгоритмы,
использующие, например, предопределенные виды кон-
тактной информации, предопределенные вычеты НДФЛ,
предопределенные счета налогового учета и так далее.
Таким образом, предопределенные элементы не «обезли-
чены» для конфигурации, и конфигурация имеет воз-
можность отличить один предопределенный элемент от
другого (рис. 6.13).
Режим "Конфигуратор*
Метаданные
Й 3 Справочники
ЕЙ ЭидыСобытий ----------s
j r-J Реквизиты
iffi Т абличные части
I | И Формы
= I Макеты
1д__:____ Э
•> Справочник Виды событий
_ П X
Режим ЧС.Предприятие'
Ess____
5
Выставка
1С Предприятие
X
6 Заключение договора
Удаление |ццци^чпг элемента справочника запрещено
Добавит
__________,1g Столяре
Т(ЛеФонныйр
------------«Ц. Измени
П| езентация
3 Ci минар
Рис. 6.11. Тип значения поля ввода
Установить пометку удаления
В Закончить редактирование
Del
Shft+F2
Рис. 6.13. Пример предопределенного элемента справочника
Обращение к предопределенным элементам возможно
посредством обращения к содержимому глобального кон-
текста.
Например, если при создании документа Событие необ
ходимо заполнить значение реквизита ВидСобытия (тип
значения: СправочникСсылка.ВидыСобытий) предопределенным
элементом справочника, это может выглядеть так, как по-
казано в листинге 6.4.
Листинг 6.4. Пример использования предопределенного
элемента справочника
// Создать новый документ
НовоеСобытме = Документы.Событие.СоздатьДокунентО;
// Заполнить поля
НовоеСобытие.Дата = РабочаяДата;
И Заполнить значением предопределенного элемента
НовоеСобытие.ВидСобытия = Справочники.ВидыСобытий.Семинар;
// ..
// Записать документ
НовоеСобытие.Записать();
При работе с объектами встроенного языка предопределен-
ные элементы отличаются от «обычных» лишь значением
свойства Предопределенный (у обычных — Ложь, у предопре-
деленных — Истина). Работа пользователя с предопреде-
ленными элементами, по сравнению с обычными, ограни
чивается лишь невозможностью удалить их. Все остальные
способы модификации предопределенных элементов сле-
дует ограничивать правами доступа или с помощью при
кладных алгоритмов.
Это означает, что пользователь при необходимости мо-
жет изменить наименование предопределенного элемен-
та, код, пометить на удаление и т. д. При этом для сис-
темы этот предопределенный элемент остается тем же
самым предопределенным элементом, так как его внут-
ренний идентификатор не меняется.
Хранение информации
объектных и необъектных
сущностей
При выборе прототипов объектов для хранения инфор-
мации одним из типичных вопросов, возникающих при
неочевидных случаях, является выбор между объектны-
ми и необъектными данными. Например, между регист-
ром сведений и справочником.
Подробно о функциональных отличиях данных объект-
ных и необъектных можно прочитать в разделе «Работа с
данными», с. 36. В рамках текущей темы ограничимся
лишь вопросами выбора.
Для принятия решения рекомендуется обращать внима-
ние на природу данных предметной области. Если они об
ладают некой «самостью», несмотря на смену значений
отдельных свойств этого объекта, то предпочтение следу-
ет отдавать к определению этих данных, как объектных.
Например, сотрудник может сменить фамилию, имя, пас-
порт, цвет глаз и т. д., однако при этом он останется все
тем же сотрудником. Таким образом, мы рассмотрели ти-
пичный пример идентификации сотрудников предпри-
ятия как данных объектных и подлежащих учету посред-
ством справочника.
Однако следует учитывать что выбор вида объекта кон-
фигурации не должен производиться для каждой сущ-
ности отдельно. Необходимо анализировать наличие и
остальных сущностей в комплексе всей прикладной зада-
чи. Причем желательно не только на текущий момент, но
и с учетом развития задачи в будущем.
Например, состав сотрудников предприятия целесооб-
разно хранить посредством объекта конфигурации Спра-
вочник (рис. 6.14).
Справочник "Сотрудники"
Ссылка Код Наименование
Рис. 6.14. Таблица справочника Сотрудники
Однако, если взглянуть на проблему шире, может ока-
заться, что на самом деле тут смешиваются две сущности:
♦ «Физические лица», как отражение реальных людей,
с которыми предстоит иметь дело в рамках решения;
♦ «Сотрудники подразделений предприятия», причем один
и тот же человек может быть сотрудником нескольких
подразделений предприятия, выполняя в них различ-
ные «роли» (должности, круг обязанностей и проч.).
Причем вторая сущность как объект нигде не фигуриру
ет, просто нужно помнить «кто есть кто». Тогда хранение
данных сотрудников подразделений может быть реализо-
вано посредством регистра сведений (рис. 6.15).
Рис. 6.15. Связь таблицы справочника и таблицы
регистра сведений
Если аналогичным образом рассматривать хранение дан-
ных о сотрудниках и их трудовых договорах, то можно
также выделить две сущности.
♦ «Физическое лицо»;
♦ «Сотрудник — трудовой договор», как отражение юри-
дических отношений данного лица с организацией, имею-
щее при этом объектную природу, поскольку впослед-
ствии ссылка на трудовой договор будет фигурировать
во многих документах и регламентированных отчетах.
В этом случае для хранения данных следует использовать
два справочника (рис. 6.16).
Таким образом, выбор каждого из вариантов хранения
информации определяется тем, какую сущность предмет-
ной области будет отражать тот или иной объект. При
этом разработчикам рекомендуется также и имя объекта
определять так, чтобы оно максимально отражало описы-
ваемую сущность. Это позволит впоследствии обеспечить
правильное восприятие и использование объекта.
Справочник “ФизическиеЛица"
Ссылка Код Наименование
Справочник "Г рудовыеДогио><ъэ(. е рудников"
Ссылка Код Наименование ФизЛицо
*
Рис. 6.16. Связь таблиц справочников
Хранение информации
в самих объектах или
в других объектах
Необходимо помнить, что любой объект — это единая
сущность с точки зрения манипулирования данными. То
есть при любых операциях с объектом (чтение, запись,
модификация) происходит обращение к информации
базы данных, касающейся всего объекта.
Например, справочник Договоры Контрагентов имеет под-
чиненные объекты: два реквизита (ДатаПоставки и ВидДо-
говора) и табличную часть Спецификация. В свою очередь,
в состав табличной части тоже входит ряд реквизитов
(рис. 6.17).
Дог лесе* / j” par емтов
□ | Реквизиты
j-— ДатаПоставки
ВиоДоговора
Табличные части
Б-ciaj Спецификация
...— Номенклатура
— Количество
— Цена
— Сумма
Рис. 6.17. Структура справочника ДоговорыКонтрагентов
Хранение этой информации в базе данных будет реализо-
вано системой следующим образом:
♦ в основной таблице справочника будет храниться ин-
формация в следующих полях:
• Ссылка;
• Код;
Наименование;
Пометка удаления;
Предопределенный;
Родитель;
Владелец;
ЭтоГруппа;
ДатаПоставки;
• ВидДоговора;
♦ информация табличной части Спецификация — в от-
дельной таблице, содержащей следующие поля:
• Ссылка (значение этого поля равно значению поля
Ссылка основной таблицы справочника);
• НомерСтроки;
• Номенклатура;
• Количество;
Цена;
Сумма.
Любое обращение к объекту документа приведет к тому,
что из базы данных будет считана информация, соответ-
ствующая данному объекту, из обеих таблиц.
При этом не важно, как именно выполнялось обращение.
Посредством метода «ПолучитьОбъектО» из ссылки
(листинг 6.5) или при открытии формы, основным рекви-
зитом которой является объект договора (рис. 6.18).
Листинг 6.5. Пример получения объекта справочника
из ссылки
ОбъектДоговора = СсылкаНаДоговор.ПолучитьОбъектО:
Рис. 6.18. Открытие формы объекта, отображающей
табличную часть
В последнем случае, кстати, не важно, будут отображать-
ся на форме данные табличной части элемента или нет
(рис. 6.19).
Рис. 6.19. Открытие формы объекта, в которой табличная часть
не отображается
Объект в любом случае считывается целиком, поскольку
при открытии формы система также создает объект спра-
вочника, обеспечивая тем самым целостность изменений,
вносимых в данные объекта как интерактивно, так и про-
граммно, в модуле формы.
Данную особенность нужно иметь в виду для сущностей,
при работе с которыми часто необходим доступ именно
к объектам, а не ссылкам (например, объекты, которые
часто модифицируются пользователями). При чтении
объекта или его модификации данные будут считываться
и записываться по объекту целиком. Таким образом, чем
меньше этих данных будет, тем быстрее будут выпол-
няться операции, меньше будет продолжительность бло-
кировок и т. д.
Из этого можно сделать вывод, что информацию, кото-
рую предполагается хранить в объектах, следует анализи-
ровать на предмет разделения на «активно используемую»
и «не активно используемую». Активно используемую
информацию можно хранить в реквизитах самого объек-
та или его табличных частей. Неактивно используемую
информацию об объекте можно хранить не в самом объ-
екте, а посредством других информационных структур.
Однако при этом придется «самостоятельно» заботиться
о поддержании целостности изменений при модифика-
ции данных объекта.
Для вышеприведенного примера, если информацию спе-
цификаций можно считать «не активно используемой»,
то ее хранение можно организовать посредством, напри-
мер, регистра сведений СпецификацииДоговоров или под-
чиненного справочника СпецификацииДоговоров.
И в том и в другом случае, при считывании объекта дого-
вора обращения к информации спецификации выпол-
няться не будет (рис. 6.20).
Рис. 6.20. Открытие формы объекта
Однако при необходимости выполнить такое обращение,
это будет легко сделать, например с помощью запроса
(листинг 6.6).
Листинг 6.6. Пример получения данных подчиненного
справочника запросом
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
СпецификацииДоговоров.Код.
СпецификацииДоговоров.Наименование.
СпецификацииДоговоров.Номенклатура,
СпецификацииДоговоров.Количество,
СпецификацииДоговоров.Цена,
СпецификацииДоговоров.Сунна
ИЗ
Справочник.СпецификацииДоговоров КАК
СпецификацииДоговоров
ГДЕ
СпецификацииДоговоров.Владелец = &Владелец";
Запрос.УстановитьПараметр("Владелец", Договор);
Результат = Запрос.ВыполнитьО;
Выборка = Результат.ВыбратьО;
Пока Выборка.СледующийО Цикл
// Выполнить действия со информацией строки спецификации
//...
КонецЦикла;
В этом случае из базы данных будет считана лишь нуж-
ная информация спецификаций.
Обратиться к данным подчиненного справочника можно
и с помощью объектной модели работы с данными (лис-
тинг 6.7).
Листинг 6.7. Получение данных подчиненного справочника
с помощью объектной модели работы с данными
Выборка = Справочники.СпецификацииДоговоров.Выбрать(
,СсылкаНа8ладельца);
Пока Выборка.Следующий() Цикл
// Выполнить действия со строкой спецификации
//...
КонецЦикла;
В этом случае, в отличие от табличной модели работы
с данными, будут считаны целиком объекты элементов
подчиненного справочника.
При выборе того или иного варианта хранения, кроме
разницы между «хранением необъектных данных» и «хра-
нением объектных данных» (рассмотренной в разделе
«Хранение информации объектных и необъектных сущ-
ностей», с. 97), можно еще учесть требования к уникаль-
ности информации, накладываемые используемыми объ-
ектами системы ЮПредприятие.
Если необходимо обеспечить жесткую уникальность по-
нятия «Номенклатурная позиция спецификации догово-
ра» (то есть одна и та же номенклатурная позиция не мо-
жет быть указана более одного раза в спецификации
одного договора), тогда предпочтительнее вариант с ис-
пользованием регистра сведений. Он как раз позволяет
хранить информацию только уникальную с точки зрения
ключевых полей (в данном случае — измерений Договор
и Номенклатура).
Для подчиненного же справочника таких ограничений по
уникальности нет. Если необходимо хранить информа-
цию в виде простой таблицы, то этот вариант будет пред-
почтительнее.
Аналогична цепочка рассуждений, если в ходе решения
некой прикладной задачи на этапе конфигурирования
для объекта необходимо ввести много признаков или осо-
бых свойств.
Одно дело, если эти свойства и признаки касаются всех
элементов данной сущности и активно используются при
работе с объектами, им соответствующими. Тогда инфор-
мацию данных свойств уместно хранить в виде реквизи-
тов объекта.
Например, реквизит Услуга булевою типа для справочника
Номенклатура. Очень многие прикладные механизмы, ра-
ботающие с элементами справочника Номенклатура, долж-
ны быстро различать ситуации работы с услугами или
материальными номенклатурными позициями.
Другое дело, если этот признак касается лишь некоторых
элементов и используется лишь в отдельных механизмах.
Тогда для хранения этой информации нерационально ис-
пользовать реквизиты, а можно использовать другие объ-
екты.
Например, информацию о том, какие из физических лиц
являются пользователями, уместнее хранить в отдельном
справочнике (с реквизитом ФизЛицо) или в соответствую-
щем регистре сведений.
Кроме того, возможна ситуация, когда необходимо, чтобы
новые признаки и характеристики могли вводиться не
только на этапе конфигурирования (разработчиками), но
и в режиме работы ЮПредприятие — пользователями.
Для реализации этой возможности удобна организация
хранения информации с использованием объекта План ви-
дов характеристик. Более подробно этой теме посвящен
раздел «Хранение дополнительных характеристик произ-
вольного типа. Использование плана видов характери-
стик», с. 131.
В ситуации, когда требуется с помощью специальных
свойств выделить только один элемент, использование
реквизитов объектов вообще является неверным. Напри-
мер, введение булевого реквизита БазоваяВалюта в состав
справочника Валюты нерационально как с точки зрения
хранения информации (поле будет существовать для всех
элементов, хотя значение Истина, с прикладной точки зре-
ния, уместно только у одного элемента), так и с точки
зрения быстродействия. Для корректного разрешения по-
добных ситуаций уместно считать элементы, обладающие
такими специальными свойствами, данными, общими для
всей базы данных. И организовывать хранение информа-
ции об этом посредством констант или регистров сведе-
ний.
Так же осторожно нужно подходить к использованию
строковых реквизитов неограниченной длины. Крайне не
рекомендуется использовать их для хранения информа-
ции, объем которой может быть достаточно большим или
непрогнозируемым. Примером такого некорректного ис-
пользования реквизита может служить сохранение в рек-
визите значения, получаемого функцией ЗначениеВСтро-
куВнутрО (например, для таблицы значений, содержащей
большое количество строк).
Не рекомендуется хранить в реквизитах активно исполь-
зуемых объектов картинки и образы файлов (использова-
ние полей типа ХранилищеЗначений), если заранее известно,
что размер их будет велик. Для сохранения подобной ин-
формации следует использовать альтернативные методы.
Хранение иерархической
информации
Иерархическими принято считать структуры, у которых
четко прослеживаются отношения «один ко многим». На-
пример, «один руководитель — много подчиненных»
(рис. 6.21).
Рис. 6.21. Пример одноуровневой иерархии
Кроме того, уровней иерархии может быть больше одно-
го: «один руководитель, в подчинении которого находят-
ся руководители подразделений, в подчинении которых
находятся подчиненные» — пример трехуровневой иерар-
хической структуры (рис. 6.22). Ну а в общем случае —
уровней может быть значительно больше.
Рис. 6.22. Пример многоуровневой иерархии
Необходимо отметить, что в прикладных задачах в любом
случае используется не бесконечное количество уровней
иерархии. Например, хотя и говорят, что бюрократия бес-
конечна — составляя организационно-штатную структу-
ру любой организации, всегда приходим к конечному ко-
личеству уровней подчинения, ответственности и т. д.
В данном разделе мы не будем обсуждать достоинства
и недостатки использования иерархических структур в
области их применения. Сосредоточимся на возможно-
стях организации хранения иерархической информации
средствами системы 1 С: Предприятия.
Для «экономного» хранения информации об иерархично-
сти хранимых данных достаточно, если каждый из ниже
стоящих элементов будет «помнить» ссылку на непосред-
ственно стоящий над ним элемент.
Таким образом, информацию об иерархии можно хранить
не только в виде схем, но и в виде таблиц. Например, ин-
формация о вышеприведенной схеме может храниться
так, как показано в табл. 6.1.
Таблица 6.1. Пример хранения иерархической
информации
Сотрудник Руководитель
Директор
Руководитель отдела закупок Директор
Менеджер по закупкам Руководитель отдела закупок
Товаровед Руководитель отдела закупок
Руководитель отдела продаж Директор
Менеджер по продажам Руководитель отдела продаж
Продавец Руководитель отдела продаж
Секретарь Директор
Каждая строка таблицы содержит информацию по одной
персоне. Для каждой строки таблицы упоминание некой
персоны в поле Руководитель означает, что данный со-
трудник непосредственно подчинен именно этому руко-
водителю (а в информации по этому руководителю будет
указано, кому он в свою очередь подчинен). В строке, от-
ражающей информацию по директору поле Руководитель
пусто. Это значит, что в данной схеме у директора нет ру-
ководителей. Еще говорят «директор находится на корне-
вом уровне иерархии».
Данный прием применяется при хранении иерархиче-
ской информации объектов прикладной области на уров-
не объектов базы данных системы 1С:Предприятие. То
есть «нижестоящие» элементы должны помнить ссылку
на «вышестоящие» элементы иерархии.
Однако это не значит, что разработчик в каждом отдельно
взятом случае должен выполнение этого приема «дово-
дить» до уровня таблиц базы данных. В типовых ситуаци-
ях эту работу берет на себя сама система. Разберем, что
же это за ситуации.
При разработке бизнес-решений разработчику чаще всего
приходится иметь дело с иерархическими структурами
при организации хранения условно-постоянной инфор-
мации (справочники, планы видов характеристик), реже —
при работе с регистрацией событий.
В отношении хранения условно-постоянной информации
учтены следующие ситуации:
♦ иерархия объектных данных одной сущности (рассмат-
ривается в разделе «Хранение иерархии данных одной
сущности»);
♦ иерархия объектных данных разных сущностей (рас-
сматривается в разделе «Хранение иерархии данных
разных сущностей», с. 105);
♦ хранение иерархии необъектных данных внутри объек-
та (рассматривается в разделе «Хранение подчиненных
данных в составе объекта», с. 103);
♦ хранение иерархии необъектных данных вне объекта
(рассматривается в разделе «Хранение подчиненных
данных вне объекта», с. 105).
В остальных же случаях или для реализации ситуаций
иерархии событий разработчик всегда может реализовать
свою иерархическую схему посредством добавления рек-
визита к «подчиненным» объектам, значением которого
должна являться ссылка на объект-владелец.
Например, в рамках некоторого договора был оформлен
документ ЗаказПокупателя. На основании документа Заказ-
Покупателя был введен документ РеализацияТоваров. На
основании документа РеализацииТоваров были введены
документы СчетФактура и ПриходныйКассовыйОрдер. Впо-
следствии часть товара была возвращена, то есть на осно-
вании документа РеализацииТоваров был введен документ
ВозвратТоваровОтПокупателя. Аналогичная цепочка доку-
ментов может быть оформлена в отношении другого до-
кумента ЗаказПокупателя (рис. 6.23).
Необходимо хранить информацию о том, что все эти до-
кументы находятся в иерархии конкретного договора
с покупателем.
Решается данная задача включением в состав всех объек-
тов, которые могут «подчиняться» договору, реквизита,
ссылающегося на данный договор.
Этот пример более широко (в отношении вопросов ввода
на основании, отображения иерархии подчинения дого-
вору) рассмотрен в разделе «Ввод на основании», с. 160
и приведен в составе демонстрационной конфигурации
«Хранение информации и учет движения средств», кото-
рая находится на прилагаемом компакт-диске.
Рис. 6.23. Структура документов, введенных на основании
Хранение иерархии данных
одной сущности
Выше обсуждалась схема организационно-штатной струк-
туры компании (рис. 6.24).
Рис. 6.24. Организационно-штатная структура компании
Допустим, при проектировании принято решение, что
персоналии, отраженные в схеме, относятся к одной сущ-
ности прикладной области — пользователи программы,
и являются примерами данных объектного типа. Как ин-
формация об этой иерархии может быть отражена средст-
вами платформы ЮПредприятия?
Для этого при разработке следует произвести настройку
свойств объекта конфигурации — справочника Пользова-
тели, — касающихся иерархии справочника. А именно:
справочник — иерархический, вид иерархии — иерархия
элементов (то есть нижестоящие элементы справочника
иерархически подчиняются вышестоящим именно эле-
ментам справочника), количество уровней иерархии ог-
раничено, только три (рис. 6.25).
Дальнейшую работу возьмет на себя система. В состав ос-
новной таблицы справочника Пользователи будет добав-
лено поле Родитель для хранения в записях иерархически
подчиненных элементов ссылок на элементы, которым
они непосредственно иерархически подчиняются. Обра-
щение к этому предопределенному полю будет возмож-
но посредством соответствующих объектов встроенного
языка для манипулирования данными справочника или
посредством запросов.
Рис. 6.25. Настройка иерархии справочника Пользователи
Кроме того, при записи и модификации данных в справоч-
нике Пользователи система будет отслеживать ограничение
по количеству уровней иерархии, не позволяя реализовать
попытки их превышения, выдавая соответствующие пре-
дупреждения.
Кроме того, в расширения соответствующих форм и эле-
ментов форм будут включены средства, облегчающие реше-
ние задач отображения информации справочника в иерар-
хическом виде. Например, отображение родителей верхних
уровней в табличном поле списка справочника (рис. 6.26).
Рис. 6.26. Список справочника Пользователи
Пример реализации подобной схемы приведен в демонст-
рационной конфигурации «Хранение информации и учет
движения средств» (справочник Пользователи), которая
находится на прилагаемом компакт-диске.
Рассмотренный выше пример касался случая иерархии
элементов.
Однако могут встречаться задачи, когда иерархия ис-
пользуется лишь для логического упорядочивания хране-
ния и отображения данных объектных сущностей.
Например, данные справочника Номенклатура удобнее пред-
ставлять в виде упорядочивания по товарным группам
(рис. 6.27).
Обратите внимание: каждый конечный элемент обладает
конкретной закупочной ценой. Однако говорить о значе-
нии закупочной цены родителя этих элементов — нон-
сенс с прикладной точки зрения. Таким образом, свойст-
ва элементов и свойства их родителей отличаются друг от
друга. Для реализации решений подобных задач исполь-
зуется вид иерархии Иерархия групп и элементов.
С точки зрения хранения данных в базе данных для двух
видов иерархии большой разницы нет, но для приклад-
ной и интерфейсной функциональности — возможности
отличаются сильно.
Каждый реквизит объекта справочника или плана вида
характеристик, если используется иерархия групп и эле-
ментов, может иметь следующие значения свойства Ис-
пользование:
♦ Для элемента;
♦ Для группы;
♦ Для группы и элемента.
Это позволяет легче решать задачи, для которых необ-
ходимо выделять свойства, присущие нужным уровням
иерархии.
Например, значение реквизита ОтветственныйМенеджер
присуще только группам справочника Контрагенты. Счи-
тается, что все элементы нижестоящих уровней данной
группы закреплены за этим менеджером (рис. 6.28).
В этом случае для реквизита ОтветственныйМенеджер зна-
чение свойства Использование указывается — Для группы.
Выгоды использования такого решения проявятся, на-
пример, при решении задачи «перезакрепления» контр-
агентов за другим менеджером. Чтобы «перезакрепить»
все элементы, входящие в группу, не обязательно будет
указывать каждому контрагенту его нового ответственно-
го менеджера, достаточно лишь указать другое значение
реквизита ОтветственныйМенеджер для этой группы.
С другой стороны, реквизит ОтветственныйМенеджер мож-
но сделать используемым и группами и элементами. То-
гда предложенная схема закрепления сможет учитывать
ситуации, когда контрагент находится в группе, закреп-
ленной за одним менеджером, но сам закреплен за другим
менеджером.
** Справочник Номенклатура
Действия
S-JM Мониторы “
В - Номенклатура
КлавидтурЬ-у
Закупочная ц.
ЬбР2в4мыикД1$-720 Mouse А4.
9
D0029
00027
32
1
00060
Мышь 3D-Sensoi_________
Мышь GENIUS "EASY”(.
Мышь Ice Mouse MUS-2
Мышь LOGITECH M-S48 ..
Сам родитель - лишь средство
( упорядочивания элементов (реквизитами
не обладает)
Полное
2,35
1,10
мышь м
Мышь GENIUS Т Д
1,15 MUS2P/1Q0-PS М .
0,80
Х15
Мышь LOSITECIj^
МышыаеттйМо al
Рис. 6.27. Список справочника Номенклатура
Рис. 6.28. Группы и элементы справочника Контрагенты
Для интерфейсных задач, при использовании данного
вида иерархии, система опять же берет на себя реше-
ния большинства вопросов различного поведения групп
и элементов:
♦ «разделение» форм на основную форму элемента и ос-
новную формы группы для операций заполнения и про-
смотра данных объектов;
♦ «разделение» на форму выбора и форму выбора группы
для реализации операций выбора;
♦ определение того, в каких ситуациях правомерен выбор
групп, а в каких нет (по умолчанию, например, реквизиты
документов интерактивно могут заполняться только
значениями элементов);
♦ использование специальных свойств табличных полей,
позволяющих просматривать (в зависимости от необ-
ходимости) только элементы, только группы или эле-
менты и группы и т. д.
Хранение подчиненных данных
в составе объекта
Практически все объекты системы ЮПредприятие, пред-
назначенные для хранения данных объектных сущностей
(справочники, документы, планы видов характеристик,
планы видов расчета и т. д.), имеют возможность хранить
свою информацию не только в виде значений реквизитов,
но и в составе подчиненных табличных частей.
Подобным образом также может решаться задача хране-
ния информации «один ко многим», рассмотренная ранее
в разделе «Хранение иерархической информации», с. 100.
В качестве примера возьмем все ту же организационно-
штатную структуру компании (см. рис. 6.24).
Допустим, на ее основе необходимо реализовать хранение
информации об объектной сущности «Руководители».
Решение может быть реализовано в виде справочника
Руководители так, чтобы руководители были элементами
справочника, а рядовые сотрудники указывались в стро-
ках табличной части ПодчиненныеРядовыеСотрудники, как
ссылки на элементы справочника ФизическиеЛица, (рис. 6.29).
Рис. 6.29. Схема хранения данных справочника Руководители
В результате в системе будет реализовано хранение ин-
формации об объектных сущностях — «Руководителях»,
с указанием подчиненных, в качестве их описания.
Однако необходимо иметь в виду, что информация строк
подчиненной табличной части не имеет своей объектной
сущности. То есть при данном способе хранения инфор-
мации нельзя будет сослаться ни на одного «рядового
подчиненного некого руководителя». В составе докумен-
тов можно будет создавать реквизиты с типом значения
СправочникСсылка.Руководители, но нельзя будет создать ре-
квизиты, ссылающиеся на строки табличной части Подчи-
ненныеРядовыеСотрудники.
Для задач, когда ссылка на такие сведения смысла не
имеет, хранение множества подчиненных данных, харак-
теризующих данный объект, внутри самого объекта мо-
жет быть весьма удобным.
Классическим примером являются документы с такими
табличными частями, как ПоступлениеТоваров, Состав, Со-
бытие, СторонниеЛица и т. д.
Схемы, когда подчиненная информация сама имеет иерар-
хический вид, также могут быть реализованы внутри объ-
екта, если это покажется удобным.
Например, при оформлении заказа покупателя необходи-
мо дать возможность пользователю вводить не только ин-
формацию о том, какие номенклатурные позиции, в каком
количестве и по какой цене желает приобрести покупа-
тель, но и еще произвольное количество дополнительных
пожеланий по любой номенклатурной позиции в свобод-
ной форме, с возможностью отметки, насколько эти по-
желания действительно важны.
Представление информации в этом случае может быть
отображено следующей таблицей (табл. 6.2).
Поскольку речь идет о регистрации события «заказ поку-
пателя», то для хранения информации логично использо-
вать объект — документ ЗаказПокупателя. Таким образом,
получаем три уровня иерархии:
♦ документ;
♦ указание номенклатурных позиций документа с коли-
чественно-суммовыми характеристиками;
♦ указание дополнительных пожеланий к номенклатур-
ным позициям.
Таблица 6.2. Схема представления информации
Заказ Номенклатура Количество Цена Сумма Пожелания
Заказ № 32 от 12.02.05 Лазерный принтер Canon LBP-810 2 200 400 Белого цвета
Дополнительно упаковать в гофро-тару
Телефон LG W7200 10 30 300 Без гарнитуры
Доставку приурочить к 8 марта
Цвет любой, только не черный
Реализация хранения этой информации может быть орга-
низована следующим образом. Для хранения информа-
ции о заказанных товарах с количественно-суммовыми
характеристиками можно использовать табличную часть
Состав. Но дополнительные пожелания хранить в рамках
этой табличной части будет неудобно. Как показано в
таблице выше, к одной номенклатурной позиции может
предъявляться более одного требования и форма инфор-
мации этих требований более «свободная», нежели указа-
ние цены, количества и суммы.
В этом случае для хранения информации о дополнитель-
ных пожеланиях покупателя, если эту информацию надо
хранить внутри объекта, можно использовать еще одну
табличную часть ДополнительныеТребования. Реквизитами
табличной части ДополнительныеТребования будут Требо-
вание, Важность и Номенклатура (рис. 6.30). Соответствие с
информацией табличной части Состав будет организо-
ванно именно по номенклатурным позициям.
□да] ЗаказПокупателя
Е1 Я Реквизиты
|—— Контрагент
|.— Договор
— Размещение
Й Т абличные части
i Б Е:Е| Состав
| !--« Номенклатура
; : 1.— Количество
i i-Цена
: | — Сумма
В-1:11 ДополнительныеТребования
I™ — Номенклатура
:.— Требование
— Важно
Рис. 6.30. Структура документа ЗаказПокупателя
Дополнительный сервис для пользователя может касать-
ся вопроса подбора номенклатурных позиций в таблич-
ную часть ДополнительныеТребования только из перечис-
ленных в табличной части Состав.
В демонстрационной конфигурации «Хранение инфор-
мации и учет движения средств», которая находится на
прилагаемом компакт-диске, в форме документа ЗаказПо-
купателя приведен один из вариантов решения этой за-
дачи.
В форме документа расположена панель с двумя заклад-
ками Состав и Дополнительные требования (рис. 6.31).
Поскольку для выполнения операций заполнения допол-
нительных требований пользователь сначала должен бу-
дет открыть соответствующую закладку, — обработчик
события смены закладки реализован в виде следующей
процедуры (листинг 6.8).
Рис. 6.31. форма документа ЗаказПокупателя
Листинг 6.8. Обработчик события ПриСменеСтраницы
Процедура Панель1ПриСменеСтраницы(Элемент, ТекущаяСтраница)
И Проверить, активизирована ли
И закладка "Дополнительные требования"
Если ТекущаяСтраница = 1 Тогда
И Заполнить список номенклатурных позиций.
И использованных в табличной части "Состав"
мНоменклатураСостава.ЗагрузитьЗначения(
Состав.ВыгрузитьКолонку("Номенклатура"));
КонецЕсли;
КонецПроцедуры
В процедуре обработки события При смене страницы (индекс
страницы ДополнительныеТребования равен 1) происходит
заполнение промежуточного списка значений мНоменкла-
тураСостава номенклатурными позициями из табличной
части Состав.
Для того, чтобы возможности выбора номенклатурных
позиций на странице ДополнительныеТребования ограни-
чивались лишь значениями, выгруженными в список зна-
чений мНоменклатураСостава, — свойства поля ввода Но-
менклатура установлены следующим образом (рис. 6.32).
Обработчик события НачалоВыбораИзСписка реализован
следующим образом (листинг 6.9).
Листинг 6.9. Обработчик события
НачалоВыбораИзСписка
Процедура
ДополнительныеТребованияНоменклатураНачалоВыбораИзСпискаС
Элемент, СтандартнаяОбработка)
И Назначить список выбора полю ввода номенклатуры
Элемент.СписокВыбора = мНоменклатураСостава;
КонецПроцедуры
3 ак <1 з пик чнатр ля
Важно
верование
п
[аЫ| <Поле ввода>
аЯ Попе ввода []
Номер
Контрагент 1
Договор. | Размещение: |
Состав ] Дополнительныетребования |_________
Рис. 6.32. Свойства поля ввода Номенклатура
Необходимо заметить, что в данном примере иерархиче-
ских данных не реализована связь «один ко многим» в
чистом виде. Ведь информация «номенклатурная пози-
ция заказа покупателя» не относится к объектным дан-
ным. В общем случае, одна и та же номенклатурная пози-
ция может быть указана сколько угодно раз в табличном
поле Состав. И значит, невозможно установить, к какой
именно строке состава (с этой номенклатурной позици-
ей) относятся пожелания покупателя, описанные в таб-
личной части ДополнительныеТребования. Однако в поста-
новке задачи это и не требовалось. То есть либо такие
ситуации не критичны для логики работы разрабатывае-
мого решения, либо пользователь сам может описать, что
имелось в виду, — в строковом реквизите «требование».
В ситуациях же, когда поддержание однозначности свя-
зей «один ко многим» критично, разработчику необхо-
димо будет решать этот вопрос. Для этого следует либо
дополнительно обеспечивать уникальность значений рек-
визитов, или комбинаций значений реквизитов в самом
объекте, либо «вынося» хранение этой информации в
другие объекты, специально предназначенные для обес-
печения уникальности комбинаций значений сущно-
стей — регистры сведений.
Хранение иерархии данных
разных сущностей
Допустим, необходимо организовать хранение информа-
ции по предыдущей трудовой деятельности каждого со-
трудника компании. Сами сотрудники признаны сущно-
стями объектного типа и для хранения их информации
в рамках решения создан справочник Сотрудники.
Как решить задачу? С одной стороны, данная информа-
ция непосредственно связана с сотрудником и могла бы
быть реализована посредством включения табличной части
ТрудоваяДеятельность в состав объектов справочника Со-
трудники.
Но к выбору такого варианта надо подходить осторожно.
Как обсуждалось в разделе «Хранение подчиненных дан-
ных в составе объекта», с. 103, — подчиненные табличные
части предназначены для учета только необъектных сущ-
ностей. То есть при таком решении в других объектах
системы невозможно будет использовать поля или рекви-
зиты, соответствующие понятию «место предыдущей ра-
боты конкретного сотрудника».
Если же необходимость в такой объектной сущности есть
или может появиться, то решение видится в использо-
вании подчиненного справочника ТрудоваяДеятельность.
В его элементах можно хранить информацию о должно-
сти, месте работы, дате начала деятельности, дате оконча-
ния деятельности по каждому «эпизоду» предыдущей ра-
боты сотрудника.
Впоследствии эта сущность может быть использована,
например, для организации структуры регистра накопле-
ния СтажРаботы, или для заполнения реквизитов соответ-
ствующих документов.
Хранение подчиненных данных
вне объекта
Для хранения необъектных данных, соответствующих оп-
ределенным комбинациям значений измерений, предна-
значены регистры сведений. Более подробно устройство
и функциональность регистров сведений рассмотрены в
разделе «Хранение информации в регистрах сведений»,
с. 107. Сейчас же лишь рассмотрим лишь один пример.
В торговой компании покупатели закреплены за ме-
неджерами, их обслуживающими. Сами менеджеры ком-
пании, в свою очередь, относятся к тому или иному де-
партаменту. Необходимо иметь представление, кто за кем
закреплен на каждый момент времени.
В данном случае вариант хранения информации в регист-
ре сведений предпочтителен тем, что автоматически бу-
дет обеспечена уникальность значений измерений. То
есть в регистре ЗакреплениеПокупателей невозможно будет
создать две записи с одним и тем же покупателем (соот-
ветственно, невозможно одного покупателя закрепить за
несколькими менеджерами). Аналогично — в отношении
регистра ЗакреплениеМенеджеров.
Кроме того, регистры сведений позволяют хранить не
только статические варианты иерархических структур, но
и изменяющиеся во времени. Если указанные регистры
сведений сделать периодическими, то впоследствии мож-
но будет легко хранить динамику картины отношений. То
есть отражать в системе все изменения, касающиеся за-
креплений (например, менеджер со всей своей клиент-
ской базой передан другому департаменту). И так же легко
получать информацию о состоянии модели закреплений
на любой момент времени.
Также для ситуаций, когда в готовое (и эксплуатируемое)
решение приходится вводить новые сущности, добавле-
ние новых измерений к регистру сведений позволяет лег-
ко решать задачи усложнения «взаимоотношений» дан-
ных.
Например, начиная с какого-то момента закрепление по-
купателей за менеджерами продолжает оставаться одно-
значным, но только в рамках конкретных проектов. То
есть в основном проекте Торговля за обслуживание некого
покупателя по-прежнему отвечает тот же менеджер, но в
проекте Информационное сопровождение — совсем другой
(да еще и из другого департамента).
С точки зрения классификации ситуации хранения дан-
ных такое изменение «революционно», отдельные его час-
ти можно даже рассматривать как переход от схемы «один
ко многим», к схеме «многие ко многим». Однако сама
реализация подобного «поворота событий» очень проста.
В состав регистра ЗакреплениеПокупателей достаточно до-
бавить измерение Проект. И поскольку система обеспечи-
вает в регистре сведений уникальность комбинаций зна-
чений измерений, задача уже фактически решена.
Остается лишь согласовать с пользователями, будет ли в
регистре сведений ЗакреплениеПокупателей пустая ссылка
на проект (для старых данных) с прикладной точки зре-
ния восприниматься проектом основной деятельности
предприятия — Торговля, — либо необходимо произвести
соответствующую обработку для заполнения этих данных.
Так же легко в состав регистра сведений может быть вве-
дена дополнительная информация, характеризующая кон-
кретные комбинации значений измерений. Это реализу-
ется посредством добавления ресурсов.
Например, для регистра ЗакреплениеПокупателей могут быть
введены такие ресурсы, как Лояльность, ЧастотаКонтактов,
СуммаКвотыПродаж и так далее. Для регистра Закрепление-
Менеджеров могут быть введены такие ресурсы, как Базо-
выйОклад, ПроцентПремии, Эффективность и тому подобное.
Хранение информации,
имеющей привязку
ко времени
Практически все объекты, поддерживающие возможность
добавления новых полей (значений, реквизитов), могут
работать с данными типа Дата. Но зачастую предметом
хранения является не информация о датах, а «другая» ин-
формация, которая просто должна храниться в привязке
ко времени. Например, необходимо помнить, начиная с
какого момента времени, для таких-то номенклатурных
позиций действуют такие-то цены.
Информацию, хранящуюся в привязке ко времени, чаще
всего разделяют на содержащую:
♦ объектные данные;
♦ необъектные данные.
Использование документов
В задачах хранения объектных данных, привязанных ко
времени, речь обычно идет о регистрации неких событий
и всего, что с ними связано, например, в хозяйственной
жизни предприятия. Чаще всего для хранения такой ин-
формации выбираются объекты Документ.
В нашем примере (с хранением информации о ценах),
если необходимо в привязке ко времени фиксировать,
как (и вследствие какого события) произошло изменение
цен, то для хранения этой информации можно использо-
вать документ ИзменениеЦенКомпании (рис. 6.33).
В пользу такого решения говорит функциональность объ-
ектов документов, поддерживаемая на уровне платформы
1 С:Предприятия:
♦ заполнение;
♦ запись;
♦ проведение;
♦ формирование движений по регистрам;
♦ расположение на оси времени;
♦ пометка на удаление;
♦ удаление.
Рис. 6.33. Документ ИзменениеЦенКомпании
Кроме этого, положительным моментом является «ре-
шенность» (средствами платформы) вопросов отображе-
ния списков документов, возможности группирования
разных видов документов в единой хронологии для обще-
го отображения или для общей обработки и так далее.
Подробно эти вопросы освещены в главе 7 «Документы
и последовательности», с. 136.
Использование периодических
регистров сведений
Как рассуждали выше, в разделе «Задачи хранения ин-
формации», с. 91, для решения учетных и аналитических
задач кроме учета событий важно, чтобы система в опре-
деленных ситуациях учитывала показатели, которые из-
меняются или при обработке вышеуказанных событий,
или вследствие других действий пользователя.
Возможно, в нашем примере будет необходимо быстро
получить ответ, для какого товара в такой-то момент вре-
мени действует такая-то цена. Получение этой информации
из документов может оказаться неудобным или длитель-
ным по времени, потому что данные разных документов
могут противоречить друг другу, и для определения «ис-
тины» разработчику придется прописать некие алгоритмы.
Использование периодических регистров сведений по-
зволяет в данной ситуации (и подобных ей) достаточно
быстро создать решение, большую часть функционально-
сти которого поддерживает сама платформа (рис. 6.34).
В-.Ц ЦеныНоменклатуры
В Д— Измерения
i I i-Ц Номенклатура
I— ТипЦены
i Й " & Ресурсы
I =.f Цена
Й-S Реквизиты
Ответственный
Рис. 6.34. Структура регистра накопления ЦеныНоменклатуры
Например, получение информации об актуальных значе-
ниях цен на некоторый момент времени (рис. 6.35).
среза
['‘КонецП ери ода"]
Рис. 6.35. Схема получения актуальных цен
Подробно вопросы состава и функциональности регист-
ров сведений рассмотрены ниже, в разделе «Хранение ин-
формации в регистрах сведений».
При этом хотелось бы заметить, что в рассмотренном
нами примере оба варианта хранения данных, имеющих
привязку ко времени, не противоречат друг другу. Они
могут «мирно уживаться» в одном решении и обеспечи-
вать каждый свою функциональность. И даже более того,
«помогают» друг другу. Данный пример полностью при-
веден в составе демонстрационной конфигурации «Хра-
нение информации и учет движения средств», которая
находится на прилагаемом компакт-диске.
Использование объекта
ХранилищеЗначения
При решении вопросов хранения информации желатель-
но различать информацию, обеспечивающую основную
бизнес-логику решения, и другую, вспомогательную ин-
формацию.
Данные основной бизнес-логики активно используются
в учетных и аналитических механизмах. Для них важны
такие вопросы, как индексирование, упорядочивание в
запросах и выборках, суммирование, поиск и т. п. Вопро-
сам обеспечения хранения этих данных, по сути, посвя-
щена большая часть данной главы.
Данные же вспомогательной информации нужно просто
хранить. Все возможное манипулирование этой инфор-
мацией сводится к операциям записи и чтения. Вопросам
организации хранения такой информации посвящен только
текущий раздел.
Итак, платформа системы 1С:Предприятие предоставляет
возможность хранения некоторой вспомогательной ин-
формации в базе данных посредством полей типа Хранили-
щеЗначений. Особенностью использования таких полей яв-
ляется то, что база данных «не обязана ничего знать»
о природе хранимой там информации. Это могут быть
картинки, файлы, таблицы, данные примитивных типов, —
да что угодно. База данных отвечает лишь за хранение
этой информации, не обеспечивая больше никакой функ-
циональности. При этом еще говорят, что тип значения
ХранилищеЗначения позволяет хранить значения различных
типов в сериализованном виде, то есть в виде, который
позволяет записывать данные и восстанавливать их.
ПРИМЕЧАНИЕ
Для всех объектов, чьи данные сериализуются, в описании
встроенного языка данная возможность указывается отмет-
кой «Сериализуется».
Важной особенностью хранилища значений является воз-
можность хранения данных в сжатом виде. Это позволяет
существенно сократить размеры базы данных при необ-
ходимости хранения больших объемов информации.
С прикладной точки зрения, в полях типа ХранилищеЗначения
можно хранить, например, значения каких-то вспомога-
тельных настроек пользователей, фотографии, изображе-
ния, образы файлов и так далее. Например, фотографии
сотрудников или файлы с аудиозаписью важных перего-
воров (то есть данные типа Картинка или ДвоичныеДанные).
При этом, хотя в системе не существует явного ограни-
чения на размер данных, хранящихся в полях типа Храни-
лищеЗначения, следует все-таки осмотрительно подходить
к решению, что именно требуется хранить в базе данных.
Большой объем хранимой вспомогательной информации
может привести к тому, что административные операции
(например, создание резервной копии базы данных) вы-
полняются медленно из-за большого объема базы дан-
ных. А большой объем обусловлен не требованиями обес-
печения основной бизнес-логики, а тем, что кто-то из
сотрудников решил хранить в базе данных любимые
фильмы.
Особенно аккуратно надо относиться к возможности ис-
пользования полей типа ХранилищеЗначений в составе объ-
ектов (например, справочников, документов), активно
использующихся при реализации основной бизнес-логи-
ки. Ведь данные объектов считываются целиком при об-
ращении к ним. Поэтому, например, вопрос хранения тех
же фотографий лучше решать не в составе справочника
Сотрудники, а в отдельном подчиненном справочнике или
регистре сведений. Тогда будет сохранена возможность
идентификации соответствия изображений сотрудникам,
к которым они относятся. И в то же время при использо-
вании объектов справочника Сотрудники для решения
других задач выполняемые операции не будут замедлять-
ся из-за необходимости считывания из базы данных боль-
ших объемов информации.
Хранение информации в регистрах сведений
Удобным средством для реализации задач хранения ин-
формации необъектных данных, развернутой в некоторых
разрезах, является использование регистров сведений.
Для решения таких задач регистры сведений обладают
функциональностью, которая включает в себя:
♦ уникальность записей в разрезах ключей записей;
♦ периодичность;
♦ подчинение записей регистратору.
Разберем использование этой функциональности на при-
мерах.
Уникальность записей
регистра сведений
Одним из основных «показаний» для использования имен-
но регистров сведений для хранения данных является то,
что регистры сведений обеспечивают уникальность хра-
нимой информации для конкретных комбинаций значе-
ний разрезов ее хранения. То есть набор значений разрезов
является уникальным ключом каждой записи регистра.
Сама информация в регистре хранится в виде значений
ресурсов. А разрезы хранения информации реализуются
посредством измерений регистра.
Рассмотрим следующий пример. Для хранения значения
метода списания себестоимости, действующего на авто-
матизируемом предприятии, может использоваться непе-
риодический регистр сведений УчетнаяПолитикаПредприятия.
В случае отсутствия измерений (разрезов хранения ин-
формации) состав регистра будет выглядеть следующим
образом (рис. 6.36).
Й 'Jf УчетааяПогитикаПредтри! тмя
b -jL* Измерения
ф” 4 Ресурсы
*•• | МетодСписамияСебестоимостам
Отсутствие измерений
означает отсутствие
Хранение информации
реализуется на ресурсах
регистра сведений
Рис. 6.36. Структура регистра УчетнаяПолитикаПредприятия
В таком регистре можно хранить только одно значение
метода списания себестоимости (табл. 6.3).
Таблица 6.3. Значение, хранимое в регистре
МетодСписанияСебестоимости
FIFO
Запись другого значения в данный регистр обязательно
должна сопровождаться замещением предыдущего (табл. 6.4).
Два значения одновременно храниться не могут.
Таблица 6.4. Значение, хранимое в регистре
МетодСписанияСебестоимости
Средневзвешенный
Это соответствует требованиям прикладной области. Ведь
действительно, если для решения ряда учетных задач по-
требуется получать значение используемого на предпри-
ятии метода списания себестоимости, то важно, что бы он
был одним и тем же.
Если же автоматизируемое предприятие, например, пред-
ставляет собой ряд самостоятельных юридических лиц
(организаций), то для хранения информации об учетной
политике каждой организации в рассмотренный регистр
сведений можно ввести измерение Организация (рис. 6.37).
В результате данные в регистре смогут храниться в разре-
зе организаций.
Й УчетнаяПотатикзПредприятия
JL. Измерения
ь- I—Организация^-------'
ф- £ Ресурсы
..I Мето дСписанияСебестои моста
Рис. 6.37. Структура регистра УчетнаяПолитикаОрганизации
По каждой конкретной организации в регистре сможет
присутствовать только одна запись. Значение метода спи-
сания себестоимости в этой записи будет «персональ-
ным» для этой организации. И ключом этой записи будет
значение организации (табл. 6.5).
Таблица 6.5. Пример хранения данных в регистре
УчетнаяПолитикаОрганизации
Организация МетодСписания- Себестоимости
ООО «АвтоматикаСвязьПроект» FIFO
ООО «Информационные системы» Средневзвешенный
ООО «Мультимедиа Плюс» Средневзвешенный
Таким образом, важно понимать, что регистр сведений не
является простой таблицей для хранения произвольной
информации. Требование уникальности записей по клю-
чевым полям обязательно. И оно отслеживается систе-
мой автоматически, при любых попытках модификации
данных или модификации состава регистра сведений.
Если в вышеприведенном примере после заполнения дан-
ных регистра информацией об организациях попытаться
удалить измерение Организация из регистра, как объекта
конфигурации, то система не позволит внести эти изме-
нения в конфигурацию базы данных (рис. 6.38).
Рис. 6.38. Сообщения при реорганизации базы данных
Количество используемых в составе регистра сведений
измерений и ресурсов определяется задачами, которые
решаются посредством этого регистра.
Например, если стоит задача хранения информации о
«персональных» для покупателей ценах на товары, она
может быть решена посредством регистра сведений со
следующим составом (рис. 6.39).
Й-ф Щ х. -и-- ванныйПрайс
Й JL. Измерения
t— Покупатель
?--t* Но мен кгв тура
ЙРесурсы
..| Цена
Рис. 6.39. Структура регистра накопления
Однако впоследствии любые «расширения» этой задачи
не приводят к необходимости серьезной структурной пе-
рестройки в вопросах организации хранения информа-
ции и достаточно легко реализуются.
Например, если впоследствии необходимо будет ввести
понятие «Договор», когда по одному договору с покупа-
телем на товары одни цены, а по другому могут быть со-
всем другие. Или если по каждой поставляемой номенк-
латурной позиции понадобится хранить не просто инфор-
мацию о ценах продажи, но и учет сезонной скидки, усло-
вия доставки, процент предоплаты, срок отсрочки плате-
жа и т. д. Все эти требования могут быть реализованы
в рамках все того же регистра, за счет добавления соот-
ветствующих ресурсов и измерений (рис. 6.40).
f' Регистр сведений УчетнаяПодитикаПредприятия
_ □ X.
возможных
*П ериодичность*
значениями.
бизнес-зад ач
Рис. 6.41. Периодичность регистра сведений
ГЦ>х»*«М1*<»овакныйПрайс
Измерения
1-- L. Покупатель
1--Ц Номенклатура
t— Договор
В & Ресурсы
| I...| Цена
| | УчетСе зонной Скидки
|..| Сло со бДо ставки
f Пропен тПредопгиты
*•- | СрокОтсрочки Платежа
Рис. 6.40. Структура регистра сведений
Важно лишь то, что в данном случае «ключом уникально-
сти» записей регистра будет уже номенклатурная пози-
ция конкретного договора с покупателем.
ВНИМАНИЕ
Хотелось бы обратить внимание, что возможность расши-
рения функциональности регистра за счет добавления но-
вых ресурсов не является обязательной к использованию.
В некоторых случаях уместнее добавление новых регист-
ров сведений. Подробно этот вопрос рассматривается в
разделе «Проектирование структуры регистров сведений»,
с. 128.
Периодические регистры
сведений
Одной из возможностей регистра сведений является хра-
нение данных не только в разрезе указанных измерений,
но и в хронологическом разрезе.
Разработчик может создавать периодические регистры
сведений, указывая минимальную периодичность хране-
ния данных.
Например, для случая реализации хранения информации
в регистре сведений УчетнаяПолитикаПредприятия не толь-
ко в разрезе организаций, но и в разрезе лет (в действи-
тельности учетная политика предприятия принимается
сроком на год), в состав объекта конфигурации можно
внести следующее изменение, — указать периодичность
хранения информации регистра В пределах года (рис. 6.41).
В результате в структуру хранения данных регистра бу-
дет добавлено поле «Период». Причем оно будет включе-
но в состав ключа записей регистра. То есть, по сути, яв-
ляется еще одним разрезом хранения информации.
Теперь в регистре УчетнаяПолитикаПредприятия (см. рис. 6.37)
смогут храниться, например, такие данные (табл. 6.6).
Таблица 6.6. Пример хранения данных в регистре
УчетнаяПолитикаОрганизации
Период Организация МетодСписания- Себестоимости
2005 г. ООО «АвтоматикаСвязь Проект» FIFO
2005 г. ООО «Информационные системы» Средневзвешенный
2005 г. ООО «Мультимедиа Плюс» Средневзвешенный
2006 г. ООО «АвтоматикаСвязь Проект» Средневзвешенный
2006 г. ООО «Мультимедиа Плюс» LIFO
Таким образом, в регистре сведений можно хранить не
просто статические данные, но и историю изменений
этих данных.
При такой организации хранения информации появля-
ются возможности:
♦ получения информации, актуальной на тот или иной
временной момент;
♦ получения информации о значениях данных, «вступаю-
щих в силу» после некого временного момента;
♦ получения картины «динамики» изменения данных за
некоторый период;
♦ решения других прикладных задач, связанных с хране-
нием информации в привязке ко времени.
Например, периодический регистр сведений Персонифици-
рованныйПрайс сможет не только хранить информацию о
том, какова цена на определенную номенклатуру сейчас
(или была в прошлом), но и о том, как она будет изменяться
в будущем (если эти изменения будут заранее планировать-
ся). Более подробно вопросы получения информации из
периодического регистра рассмотрены в разделе «Получе-
ние данных из периодических регистров сведений», с. 123.
Подчинение записей
регистратору
В ряде прикладных задач возникает необходимость обес-
печения «обоснования» хранимой в регистрах сведений
информации наличием документов, зарегистрировавших
изменения этой информации.
Ключевые поля
Период
F* Список Цен^Нзменклатуры
Действия- ij-
ИЯ
||я5] И вменение цен компании 1 от 03 01 2165
|Ном.
Акт
Изменение цен ко
Изменение иен компании 1 от 03.01 2005
ЕЗ
Изменение цен ко Алании 1 от 03.01 2005 .
Изменение цен ко Алании 1 от 03 01 2005 ..
Изменение цен ко знании 2 от 17 06 2005,,
Изменение цен ко Алании 2 от 17.06 2005..
Изменение цен ко лпании 2 от 17 06.2005.
Из*
^ot_1ZD6J?005~
Поле “НомерСтроки”
содержит порядковый
номер записи в наборе J
записей, подчиненных /
регистратору 7
щкщ
_ П х
. Номенклатура
ГС Набор записс й,
0Г
£И
Цена
15 '
___17
20
10 .
gLj
___17
19
22
W
ан
Ж
подчиненны i
регистратор j
1706.200512:00:00 Пульт РХ
17 06.2005 12:00:00 Пульт РХ
17 06 200512:00:00 Пульт РХ
17 06 200512:00:00 Пульт УН
Тип цены
Оптовая
Мелкоопт .
Розничная
Оптовая
Мелкоопт
Оптовая
Мелкоопт .
Розничная
Мелкоопт .
2
3
Рис. 6.42. Хранение данных в регистре сведений, подчиненном регистратору Рис. 6.43. Свойства регистра сведений Цены Номенклатуры
Например, изменение отпускных цен компании может
производиться только определенным кругом лиц, и каж-
дое такое изменение должно сопровождаться оформлени-
ем соответствующего документа.
То есть данные регистра сведений должны четко «пом-
нить», в связи с каким именно документом они там оказа-
лась (рис. 6.42).
Чаще всего при этом необходимо обеспечивать грануляр-
ность записи или модификации данных регистра сведе-
ний. В качестве такой «гранулы» используется набор за-
писей, подчиненных документу-регистратору. Например,
при проведении документа-регистратора его набор запи-
сей целиком перезаписывается.
Для того чтобы разработчику не пришлось решать массу
вопросов обеспечения данной функциональности «собст-
венными руками», он может воспользоваться штатными
возможностями платформы.
Для этого достаточно установить значение Подчинение ре-
гистратору свойству Режим записи регистра сведений, как
объекта конфигурации (рис. 6.43).
С точки зрения хранения данных в регистре установка
значения Подчинение регистратору свойства Режим записи
приводит к включению в состав регистра полей Регистра-
тор, НомерСтроки и Активность.
Далее требуется указать, какие именно документы могут
быть регистраторами записей регистра (рис. 6.44).
Это можно сделать как при редактировании самого реги-
стра как объекта конфигурации, так и при редактирова-
нии документа-регистратора как объекта конфигурации.
Благодаря этому облегчается труд разработчика, которому
необходимо сформировать или модифицировать набор (на-
боры) записей регистра (регистров), подчиненных некому
документу. Подробно этот вопрос освещен в разделе «Созда-
ние, изменение, удаление записей регистра сведений», с. ИЗ.
Платформа во многих механизмах будет сама использовать
обращение к данным свойствам объектов конфигурации.
Например, при удалении документа система будет для каж-
дого регистра, в котором он может быть регистратором,
проверять наличие наборов записей, подчиненных этому
документу (движений документа), с целью их удаления или
удалять все движения документа при отмене проведения
или при перепроведении, если свойство Удаление движений
документа имеет значение Удалять движения автоматически.
( Регистр сведений ЦеныНоменклатуры
_ П х
Основные
Данные
[►Регистраторы
Формы
Макеты
Подсистемы
Права
Интерфейсы
Обмен данные
Прочее
Регистраторы:
Г~| РучнаяОперация
О ЗаписьДвижений
О ЗаказПокупателя
О £! Событие
ИзменениеЦенКомпании
Р г-менениеЦенй ймпаним
&
Документ-регистратор
[ Действия у] £
Рис. 6.44. Регистраторы регистра сведений
Хотелось бы обратить внимание, что поле Регистратор
обеспечивает привязку к документу, но не всегда входит
в разряд ключевых полей.
Для того чтобы поле Регистратор стало ключевым, необхо-
димо для такого регистра сведений (с режимом записи
Подчинение регистратору) установить значение По позиции
регистратора свойству Периодичность.
С прикладной точки зрения это означает возможность
хранения в регистре сведений данных с привязкой к вре-
менной оси с «дробностью» до момента времени. То есть
фактически каждый регистратор может делать движения
по любым комбинациям измерений (при этом не будет
конфликтовать по поводу уникальности с другими доку-
ментами). А значения ресурсов можно получать не толь-
ко на определенный период, но и на момент времени до-
кумента (рис. 6.45).
Рис. 6.45. Получение значений ресурсов на момент времени
документа
Однако необходимо понимать, что с точки зрения реше-
ния реальных бизнес-задач точность записи хронологии
изменений информации, большая чем «до секунды», вряд
ли требуется.
Таким образом, исходя из области применения, если тре-
буется разместить действия двух событий в определен-
ном хронологическом порядке, то их нужно «помещать»
в разные периоды. То есть если записи движений форми-
руются так, что поле Период заполняется значением Дата
документа, то надо менять дату документа (рис. 6.46).
Рис. 6.46. Запись движений документов с точностью до даты
Хронология записей регистра сведений с периодично-
стью По позиции регистратора внутри секунды однозначна с
точки зрения чтения информации, но не управляема раз-
работчиком с точки зрения записи информации.
Например, при отображении движений регистра внутри
секунды они упорядочиваются системой по ссылкам на
регистраторы, то есть по внутренним идентификаторам
документов. И такой порядок неизменен при любом обра-
щении на чтение информации, однако нет возможности
произвольно изменить его (внутри секунды).
Структура регистра сведений
В состав регистра сведений, как объекта конфигурации,
включаются:
♦ измерения;
♦ ресурсы;
♦ реквизиты.
Как уже было рассмотрено выше, в разделе «Уникаль-
ность записей регистра сведений», с. 108:
♦ ресурсы хранят данные регистра, то есть ту информа-
цию, ради хранения которой регистр, собственно, созда-
вался и с которой работает функциональность регистра;
♦ измерения используются для обеспечения разрезов хра-
нения этой информации.
Кроме того, для ситуаций, когда необходимо кроме дан-
ных хранить дополнительную информацию о собственно
записях регистра, возможно использование реквизитов.
Хотелось бы особо отметить, что деление информации
регистра на реквизиты и ресурсы — элемент общего под-
хода. И хотя технологически хранение информации ре-
сурсов и реквизитов регистра сведений существенно не
различается, правильное «отнесение» разработчиком дан-
ных к ресурсам или реквизитам позволяет впоследствии
быстро отличить, что является «функцией» регистра, а что
просто комментирует запись.
Строго говоря, это один из ключевых моментов организа-
ции разработки в 1 С:Предприятии — деление структуры
метаданных по ролям, исполняемым конкретными объек-
тами в прикладном решении, а не только по их техноло-
гическому устройству.
Например, регистр сведений ЦеныНоменклатуры хранит
информацию о ценах в разрезах номенклатурных пози-
ций и типов цен. Эта информация впоследствии исполь-
зуется для работы механизмов ценообразования. Но кро-
ме того, для вопросов контроля над изменением цен
в составе регистра есть реквизит Ответственный, в котором
для каждой записи регистра указывается ссылка на поль-
зователя, ответственного за ввод данной записи (рис. 6.47).
хранения
Рис. 6.47. Структура регистра сведений ЦеныНоменклатуры
Далее, как было рассмотрено выше, регистры сведений
могут иметь режим записи Подчинение регистратору, вслед-
ствие чего в состав таблиц регистра добавляется поле Реги-
стратор. И регистр сведений может быть периодическим —
вследствие чего в состав его таблиц добавляется поле Пе-
риод (рис. 6.48).
Данные каждого регистра сведений хранятся в отдельной
таблице базы данных. Каждая такая таблица имеет сле-
дующий состав колонок:
♦ Период — дата записи. Определяет положение данной
записи на временной оси. Это поле существует только
для периодических регистров;
Рис. 6.48. Основные свойства регистра сведений
ЦеныНоменклатуры
♦ Регистратор — содержит ссылку на документ, которому
подчинена данная запись. Это поле существует только
для регистров с режимом записи Подчинение регистра-
тору;
♦ НомерСтроки — уникальный номер данной записи в на-
боре записей регистра, подчиненных документу, ука-
занному в поле Регистратор. Это поле существует только
для регистров с режимом записи Подчинение регистра-
тору;
♦ Активность — имеет тип Булево. Содержит признак влия-
ния записи на получение информации из регистра. За-
писи, для которых значение данного свойства установ-
лено в Ложь, не будут учитываться при получении
«первых» или «последних» записей регистра, а также
при получении сведений на определенный момент вре-
мени. Это поле существует только для регистров с ре-
жимом записи Подчинение регистратору;
♦ <Измерение> — содержит значение измерения. Количе-
ство таких полей равно количеству измерений, опреде-
ленных для регистра как объекта конфигурации;
♦ <Ресурс> — значение ресурса. Количество таких полей
равно количеству измерений, определенных для реги-
стра как объекта конфигурации;
♦ <Реквизит> — значение реквизита. Количество таких по-
лей равно количеству реквизитов, определенных для
регистра как объекта конфигурации.
Таким образом, для регистра ЦеныНоменклатуры с режи-
мом записи «Подчинение регистратору» и периодичностью
«По позиции регистратора» пример заполнения таблицы
базы данных будет следующим (темным фоном выделе-
ны ключевые поля записей) (табл. 6.7).
Теперь рассмотрим непериодический регистр сведений
Сотрудники с независимым режимом записи (рис. 6.49).
□ 11 Сотрудники
Б- JL Измерения
| I--t— Физическое Лицо
U Подразделение
Ресурсы
= L_g Должность
Рис. 6.49. Структура регистра Сотрудники
Таблица регистра Сотрудники, хранящая информацию
в базе данных, может быть заполнена следующим обра-
зом (темным фоном выделены ключевые поля записей)
(табл. 6.8).
Конечно же, функциональность регистра сведений с неза-
висимым режимом записи и регистра сведений с режи-
мом записи Подчинение регистратору различается. Так же
различается функциональность использования периоди-
ческих и непериодических регистров сведений.
Таблица 6.7. Пример заполнения регистра сведений ЦеныНоменклатуры
Период Регистратор Номер- Строки Актив- ность Номен- клатура ТипЦены Цена Ответст- венный
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 1 Истина Пульт РХ Оптовая 150,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 2 Истина Пульт РХ Мелкооптовая 170,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 3 Истина Пульт РХ Розничная 200,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 4 Истина Пульт VH Оптовая 100,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 5 Истина Пульт VH Мелкооптовая 90,00 Семенов
17.06.2005 12:00:00 Изменение цен компании 2 от 17.06.2005 12:00:00 1 Истина Пульт РХ Оптовая 170,00 Иванов
17.06.2005 12:00:00 Изменение цен компании 2 от 17.06.2005 12:00:00 2 Истина Пульт РХ Мелкооптовая 190,00 Иванов
17.06.2005 12:00:00 Изменение цен компании 2 от 17.06.2005 12:00:00 3 Истина Пульт РХ Розничная 220,00 Иванов
17.06.2005 12:00:00 Изменение цен компании 2 от 17.06.2005 12:00:00 4 Истина Пульт VH Мелкооптовая 100,00 Иванов
Таблица 6.8. Пример заполнения регистра сведений
Сотрудники
Физическое лицо Подразделение Должность
Иванов Иван Сергеевич Отдел продаж Руководитель
Семенов Сергей Петрович Отдел продаж Менеджер
Семенов Сергей Петрович Отдел закупок Руководитель
Петровский Семен Иванович Руководство компании Руководитель
Петровская Ирина Ивановна Бухгалтерия Бухгалтер
Поэтому для поддержания должного быстродействия при
обращении к данным информационной базы для таблиц
регистров сведений, в зависимости от вида регистра, соз-
даются, например, следующие индексы:
♦ для регистра сведений с периодичностью «По позиции
регистратора»:
Период + Регистратор + НомерСтроки;
Регистратор + НомерСтроки;
* Измерение! + [Измерение? +...] + Период + Регистратор — если
для данного регистра есть хоть одно измерение. В дан-
ный индекс включаются все измерения в том порядке,
в котором они заданы в составе регистра как объекта
конфигурации, поле «Период» и поле «Регистратор»;
♦ для непериодического регистра сведений:
* Измерение! + [Измерение? +...] — если для данного ре-
гистра есть хоть одно измерение. В данный индекс
включаются все измерения в том порядке, в котором
они заданы в составе регистра как объекта конфигу-
рации.
Использование индексов позволяет сократить время вы-
полнения операций с данными регистра.
Вышеприведенное описание структуры индексов позво-
ляет утверждать, что в общем случае порядок расстанов-
ки измерений регистра сведений имеет важное значение.
Измерения, к значениям которых необходим быстрый
доступ (например, при реализации отборов), следует рас-
полагать первыми, далее — в порядке убывания «попу-
лярности в отборах». Таким образом будет обеспечивать-
ся возможность эффективного применения индексов при
реализации задач чтения информации из таблицы регистра.
Также необходимо иметь в виду, что, например, SQL
Server накладывает определенное ограничение — не более
16 полей в индексе. Поэтому работа с регистрами, имею-
щими очень большое количество измерений, может быть
неэффективна по скорости из-за невозможности исполь-
зования индексов.
Более подробно об индексировании физических таблиц
регистра сведений можно прочитать в разделе «Индексы
таблиц базы данных», с. 788.
Создание, изменение,
удаление записей регистра
сведений
В общем случае, в таблицу регистра сведений записи мо-
гут вводиться пользователем вручную, генерироваться в
процессе выполнения обработок либо при поведении до-
кументов.
Таблица 6.9. Пример заполнения регистра сведений ЦеныНоменклатуры
Период Регистратор Номер- Строки Актив- ность Номен- клатура ТипЦены Цена Ответст- венный
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 1 Истина Пульт РХ Оптовая 150,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 2 Истина Пульт РХ Мелкооптовая 170,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 3 Истина Пульт РХ Розничная 200,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 4 Истина Пульт VH Оптовая 100,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 00:00:00 5 Истина Пульт VH Мелкооптовая 90,00 Семенов
17.06.2005 12:00:00 Изменение цен компании 2 от 17.06.2005 12:00:00 1 Истина Пульт РХ Оптовая 170,00 Иванов
17.06.2005 12:00:00 Изменение цен компании 2 от 17.06.2005 12:00:00 2 Истина Пульт РХ Мелкооптовая 190,00 Иванов
17.06.2005 12:00:00 Изменение цен компании 2 от 17.06.2005 12:00:00 3 Истина Пульт РХ Розничная 220,00 Иванов
17.06.2005 12:00:00 Изменение цен компании 2 от 17.06.2005 12:00:00 4 Истина Пульт VH Мелкооптовая 100,00 Иванов
Для понимания работы механизмов формирования или
модификации записей в таблице регистра сведений необ-
ходимо, прежде всего, исходить из следующих положений:
♦ все записи в регистрах уникальны с точки зрения ком-
бинации значений в ключевых полях;
♦ добавление, изменение, удаление информации в реги-
страх производится «гранулами», представляющими
собой наборы записей.
Поясним эти положения на примерах. Для регистра све-
дений ЦеныНоменклатуры с режимом записи Подчинение ре-
гистратору ключевыми полями являются Период, Регистра-
тор, Номенклатура, ТипЦены. Гранулой обмена информации с
базой данных является набор записей, подчиненных од-
ному регистратору (табл. 6.9).
Разным фоном в таблице выделены наборы записей. Со-
гласно постулату об уникальности записей по значениям
ключевых полей невозможно, например, записать одно-
временно две записи с одинаковыми значениями полей
Товар, ТипЦены, Период, Регистратор (табл. 6.10).
При подобной попытке система выдаст соответствующее
предупреждение и не выполнит запись. Это обосновыва-
ется требованиями прикладной области. Поскольку не-
возможно одновременно установить для одного и того же
товара две разных оптовых цены.
В то же время положение о «гранулярности» модифи-
кации информации регистра облегчает реализацию опе-
раций удаления или модификации данных. Потому что
с прикладной точки зрения:
♦ удаление документа Изменение цен компании №1 должно
повлечь за собой удаление всех записей регистра, под-
чиненных данному документу;
♦ изменение в данных документа при его перепроведении
должно повлечь создание нового набора записей (дви-
жений документа), который должен полностью замес-
тить старые записи регистра, подчиненные этому доку-
менту.
Приемы добавления, удаления и модификации движений
регистров с режимом записи Подчинение регистратору —
универсальны. То есть они одинаковы, что для подчинен-
ных регистров сведений, что для других видов регистров
(накопления, бухгалтерии, расчетов).
ПРИМЕЧАНИЕ
Надо лишь помнить о различии ключей записей регистров
накопления и регистров сведений.
В регистре накопления номер строки входит в ключ записи,
поэтому одним документом можно писать одинаковые
значения в разные записи. В регистре сведений номер за-
писи не входит в ключ, поэтому одинаковые значения из-
мерений и даты одним документом писать нельзя!
Очень подробно примеры подобных действий описаны
в разделе «Свойство Движения объекта документа» и раз-
деле «Запись набора записей регистра без использования
свойства Движения» главы 8 «Реализация задач учета дви-
жения средств».
В отношении регистров сведений с независимым режи-
мом записи «гранулами обмена с базой данных» будут на-
боры записей с установленными отборами по значениям
ключевых полей регистра.
Кроме того, для некоторых прикладных задач может по-
надобиться реализация обмена информацией независи-
мых регистров сведений в рамках распределенных баз
данных. В таких ситуациях в «гранулы обмена между ба-
зами данных» будут включаться комбинации значений
измерений с установленным свойством Основной отбор.
Также в основной отбор может включаться поле Период
для периодических регистров (рис. 6.50).
Е
Ведущее
Запрет незаполненных значений 0
Рис. 6.50. Свойство Основной отбор
Например, в состав демонстрационной конфигурации
«Хранение информации и учет движения средств», кото-
рая находится на прилагаемом компакт-диске, входит
ПерсонифицированныйПрайс — регистр сведений с незави-
симым режимом записи и периодичностью В пределах дня
(рис. 6.51).
С прикладной точки зрения посредством этого регистра
руководство компании может указывать информацию об
Таблица 6.10. Пример записей с одинаковыми значениями ключевых полей
Период Регистратор Номер- Строки Актив- ность Номен- клатура ТипЦены Цена Ответст- венный
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 0:00:00 1 Истина Пульт РХ Оптовая 150,00 Семенов
03.01.2005 00:00:00 Изменение цен компании 1 от 03.01.2005 0:00:00 2 Истина Пульт РХ Оптовая 155,00 Петров
исключительных условиях ценообразования для отдель-
ных покупателей. Причем режим редактирования позво-
ляет заполнять данные этого регистра и «вручную»,
и «программно» (например, посредством обработки Рас-
поряжениеНаУстановкуЦенПокупателя).
ЁНП Пг^>***й«х>мванныйГ^айс
ф'^- Измерения
Ь t-* Покупатель
L-t— Номенкгвтура
ф Ресурсы
I L • g Цена
Рис. 6.51. Структура регистра сведений
ПерсонифицированныйПрайс
Ключевыми полями для этого регистра будут Период,
Покупатель, Номенклатура. Поэтому «гранулой модифика-
ции» может считаться любая комбинация значений этих
полей.
Например, если для решения некой задачи нам необходи-
мо устанавливать или менять на определенный период
для определенного покупателя цены на все номенклатур-
ные позиции сразу. Тогда «гранулами модификации» бу-
дут наборы записей, соответствующие комбинациям зна-
чений полей Период, Покупатель. Таким образом, данные,
хранимые в регистре, можно представить следующим об-
разом (табл. 6.11).
В результате такого гранулирования данные каждой гра-
нулы, то есть наборы записей, соответствующие каждой
грануле, можно удалять или замещать целиком.
Именно это и реализуется посредством обработки Распо-
ряжениеНаУстановкуЦеныПокупателя, входящей в состав де-
монстрационной конфигурации «Хранение информации
и учет движения средств», которая находится на прила-
гаемом компакт-диске.
В форме обработки посредством полей ввода пользова-
тель заполняет реквизиты формы ВыбранныйПокупатель
и ДатаУстановки. А посредством табличного поля можно
ввести в таблицу Товары информацию о том, какие цены
для каких номенклатурных позиций нужно назначить
выбранному покупателю на дату установки (рис. 6.52).
Текст процедуры, вызываемой обработчиком нажатия на
кнопку Выполнить, представлен в листинге 6.10.
Обработка Распоряжение на установку цен п
Действия- (?)ВыбранныйПокупатель
Несткт*,стее*ыь-запись | Посредством Формы набора записей
Для покупателя: [Компания “Риона” «— |*-‘|х| “
Сдаты [06.102005 « ffi-- .
Рис. 6.52. Форма обработки РаспоряжениеНаУстановкуЦен
Листинг 6.10. Обработчик события нажатия на кнопку
Выполнить
Процедура НепосредственнаяЗаписьВРегистрС)
// Создать набор записей, соответствующий грануле "Период
- Покупатель”
НаборЗаписей = РегистрыСведений.ПерсонифицированныйПрайс.
СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Период.Установить(ДатаУстановки);
НаборЗаписей.Отбор.Покупатель.Установить(ВыбранныйПокупатель);
// Добавить записи в созданный набор записей
Для Каждого СтрокаТовара Из Товары Цикл
НоваяЗапись = НаборЗаписей.ДобавитьО;
НоваяЗапись.Период = ДатаУстановки;
НоваяЗапись.Покупатель = ВыбранныйПокупатель;
НоваяЗапись.Ноненклатура = СтрокаТовара.Ноненклатура;
НоваяЗапись.Цена = СтрокаТовара.Цена;
КонецЦикла;
// Записать набор записей с занещениен старого,
// соответствующего той же грануле
НаборЗаписей.Записать();
КонецПроцедуры
Таблица 6.11. Пример заполнения данными регистра сведений ПерсонифицированныйПрайс
Период Покупатель Номенклатура Цена
Гранула «31.01.2005 — Компания «Риона»» 31.01.2005 Компания «Риона» Монитор 17' Philips 107S20 300,00
Гранула «27.08.2005 — ЦветМетМаш» 27.08.2005 ЦветМетМаш Пульт VH 120,00
Гранула «06.10.2005 — Компания «Риона»» 06.10.2005 Компания «Риона» Монитор 17' Philips 107S20 290,00
06.10.2005 Компания «Риона» Монитор 19' Hitachi СМ715ЕТ 290,00
06.10.2005 Компания «Риона» Монитор LCD 22' M8537ZM/A 350,00
Гранула «31.01.2006 — Ялта-Лтд» 31.01.2006 Ялта-Лтд Мышь 3D-Sensor 4,00
Примечание. Серым фоном в таблице выделены ключевые поля.
Таблица 6.12. Данные регистра сведений
Период Покупатель Номенклатура Цена
Гранула «31.01.2005 — Компания «Риона»» 31.01.2005 Компания «Риона» Монитор 17' Philips 107S20 300,00
Гранула «27.08.2005 — ЦветМетМаш» 27.08.2005 ЦветМетМаш Пульт VH 120,00
Гранула «06.10.2005 —Компания «Риона»» 06.10.2005 Компания «Риона» Монитор 17' Philips 107S20 295,00
06.10.2005 Компания «Риона» Монитор 15' LG Studioworks 575N 300,00
Гранула «31.01.2006 - Ялта-Лтд» 31.01.2006 Ялта-Лтд Мышь 3D-Sensor 4,00
В процедуре сначала создается набор записей с установ-
кой значений отбора по ключевым полям. То есть по
полю Период и по измерению Покупатель.
Далее в цикле перебора строк таблицы Товары происхо-
дит заполнение записей в созданном наборе записей.
После чего, сформированный набор записей записывает-
ся с замещением старого набора записей регистра, соот-
ветствующего той же грануле (у параметра Замещать мето-
да набора записей Записать О значение по умолчанию —
Истина).
В результате выполнения обработки (исходные данные
см. рис. 6.52) таблица регистра будет содержать следую-
щие данные (табл. 6.12).
Как видите, информация, соответствующая грануле
«06.10.2005 — Компания «Риона»» заместилась согласно
данным таблицы «Товары» обработки.
Необходимо иметь ввиду, что для независимого регистра
сведений подобное «гранулирование» — умозрительное,
виртуальное. То есть посредством его можем получить
совершенно любой набор записей (главное, чтобы отбор
устанавливался по ключевым полям или ни по одному из
них и только на равенство). Но не всегда можно будет за-
писать любой набор, так как если в отбор включены не
все ключевые поля и выполняется добавление, то можно
пересечься с существующими значениями ключевых полей.
Конечно, выполнение записи набора записей с замещени-
ем просто очистит старые записи, с которыми «пересека-
емся». Но иногда на практике возникают задачи, когда
необходимо запретить такое замещение. В рассмотрен-
ном нами примере, допустим, обработка Распоряжение-
НаУстановкуЦеныПокупателя не должна позволять устанав-
ливать новые цены для покупателя на определенный
период по тем номенклатурным позициям, по которым
цены уже были установлены ранее.
Такое требование легко реализуемо. Достаточно лишь
в той же процедуре установить значение Ложь параметру
Замещать метода Записать О набора записей регистра (лис-
тинг 6.11).
Листинг 6.11. Фрагмент кода
// Записать набор записей с замещением старого,
// соответствующего той же грануле
НаборЗаписей.Записать(Ложь):
При попытке выполнения обработки для условий, ото-
браженных выше (см. рис. 6.52), система выдаст преду-
преждение о том, что запись с такими ключевыми полями
уже существует (табл. 6.13) и запись нового набора запи-
сей не состоится.
Таблица 6.13. Запись с дублирующими значениями
ключевых полей
Период Покупатель Номенклатура
06.10.2005 Компания «Риона» Монитор 17’ Philips 107S20
Для ситуаций, когда необходимо замещать все записи не-
зависимого регистра сведений новым набором записей,
гранулой можно считать весь регистр. Для этого доста-
точно вообще не устанавливать отбор.
То есть если в обработке, подобной вышеприведенной, не
нужно указывать установки отборов (листинг 6.12).
Листинг 6.12. Пример записи набора записей
без установки отбора
Процедура КнопкаВыполнитьНажатие(Кнопка)
// Создать набор записей
НаборЗаписей = РегистрыСведений.ПерсонифицированныйПрайс.
СоздатьНаборЗаписей();
// Добавить записи в созданный набор записей
Для Каждого СтрокаТовара Из Товары Цикл
НоваяЗапись = НаборЗаписей.Добавить!);
НоваяЗапись.Период = ДатаУстановки;
НоваяЗапись.Покупатель = ВыбранныйПокупатель;
НоваяЗапись.Номенклатура = СтрокаТовара.Номенклатура;
НоваяЗапись.Цена = СтрокаТовара.Цена;
КонецЦикла;
// Записать набор записей с замещением старого,
// соответствующего той же грануле
НаборЗаписей.Записать();
КонецПроцедуры
Тогда при записи нового набора записей с замещением
будут замещены все записи регистра.
Для некоторых задач необходимо, чтобы таблица незави-
симого регистра сведений просто полностью очищалась.
Такого результата легко добиться следующим образом
(листинг 6.13).
Листинг 6.13. Пример очистки регистра сведений
НаборЗаписей » РегистрыСведений.ПерсонифицированныйПрайс.
СоздатьНаборЗаписей!):
НаборЗаписей .ЗаписатьО;
В некоторых задачах бывает необходимо модифициро-
вать записи, соответствующие неким сложным условиям,
причем модификации будут подвергаться и значения клю
чевых полей.
Например, в регистре ПерсонифицированныйПрайс нужно
повысить на 20% цены на все номенклатурные позиции,
входящие в группы, в названиях которых упоминаются
слово «принтеры», если они стоят меньше 300, и «переоп-
ределить» их на некого выделенного покупателя. То есть
для остальных покупателей таких цен больше быть не
должно.
Пример реализации такой задачи с использованием
объекта МенеджерЗаписи регистра сведений приведен в
обработке ДействияСДаннымиРегистраСведений демонст-
рационной конфигурации «Хранение информации и
учет движения средств», которая находится на прила-
гаемом компакт-диске (листинг 6.14).
Краткий комментарий: сначала готовится объект манипу-
лирования данными одной записи регистра сведений —
менеджер записи.
Далее посредством запроса из основной таблицы регист-
ра получаются записи, соответствующие условиям. Обра-
тите внимание: условие по наименованию позволяет по-
лучить значения, в которых в любом месте наименования
встречается сочетание символов «принтер».
В цикле перебора выборки результата запроса устанавли-
ваются значения ключевых полей менеджера записи, и
производится чтение записи из базы данных. Далее изме-
няется значение покупателя в записи, а цена в нее уста-
навливается, как увеличенное на 20% значение цены из
выборки.
После этого методом ЗаписатьО менеджера записи произ-
водится непосредственная запись в таблицу базы данных
с замещением.
Хотелось бы отметить, что в данном примере было рас
смотрено использование менеджера записи для программ-
ной работы, но объект РегистрСведенийМенеджерЗаписи.<иня>
предназначен еще и для обеспечения интерактивной ра-
боты с записью регистра сведений. Обязательное усло-
вие — регистру сведений в конфигурации установлен ре-
жим записи Независимый (рис. 6.53).
Обратите внимание: на схеме отображено, что непосред-
ственные операции обмена информацией с базой данных
менеджер записи реализует посредством все тех же объ-
ектов манипулирования данными — наборов записей ре-
гистра. Их два. Один набор записей — пустой. Он исполь-
зуется для удаления записи со старыми ключевыми
значениями. Л второй набор записей содержит одну за-
пись, ту, которую нужно записать в регистр.
Использование интерактивных возможностей формы за-
писи регистра повышает удобство обеспечения работы
пользователя с минимальными затратами труда разра-
ботчика (рис. 6.54).
Листинг 6.14. Процедура ПовыситьЦеныНажатие
Процедура ПереопределитьЦеныНажатие(Элемент)
// Подготовить менеджер записи
Запись - РегистрыСведений.ПерсонифицированныйПрайс.
СоздатьМенеджерЗаписи!);
// Получить данные записей, соответствующих условиям
Запрос = Новый Запрос;
Запрос.Текст = "
ВЫБРАТЬ
ПерсонифицированныйПрайс.Период,
ПерсонифицированныйПрайс.Покупатель.
ПерсонифицированныйПрайс.Номенклатура,
ПерсонифицированныйПрайс.Цена
ИЗ
РегистрСведений.ПерсонифицированныйПрайс
КАК ПерсонифицированныйПрайс
ГДЕ
ПерсонифицированныйПрайс.Номенклатура.Наименование
ПОДОБНО ""^принтерГ"'
И ПерсонифицированныйПрайс.Цена < 300";
Результат = Запрос.ВыполнитьО,
Выборка = Результат. ВыбратьО,
Пока Выборка.СледующийО Цикл
// Установить ключевые поля менеджера записи
Запись.Период = Выборка.Период;
Запись.Покупатель = Выборка.Покупатель;
Запись.Номенклатура = Выборка.Номенклатура;
// Прочитать запись из базы данных
Запись.Прочитать!);
И Убедиться, что запись все еще есть в базе данных
Если Запись.Выбран!) Тогда
И Переопределить покупателя
Запись.Покупатель = ВыделенныйПокупатель;
И Установить новую цену
Запись.Цена = Выборка.Цена * 1.2;
// Записать модифицированную запись в базу данных
Запись.Записать!);
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Рис. 6.53. Схема использования менеджера записи регистра
сведений
(' Регистр сведений ПерсонифицированныйПрайс
Основные
Данные
Регистраторы
► Формы
Макеты
Подсистемы
Права
щий из одной «старой» записи), потом уже записывает
«новый» (состоящий из «новой» записи) (рис. 6.56).
_ П х
-Редактирован! Указание в
„ свойствах объекта
О В списке конфигурации этих
©диалоге способа»
редактирования
боими способами
форн
ft ? пнслх lepco шфмкирпшмиый чра*1
0410.2005
15.11 2005
ea|i6.Q2.2tre
Приводит к возможности выполнения интерактивных
модификаций записей посредством формы записей в
режиме ”1С Предприятие"
А все вопросы
основной
Функциональности
формы записи
“берет на себя"
система.
Рис. 6.54. Использование формы записи регистра сведений
При необходимости у разработчика есть возможность
«вмешиваться» в процесс модификации данных регистра
посредством использования обработчиков событий.
В случае записи новой записи (то есть записи с такими
ключевыми полями еще не было) из формы записи реги-
стра сведений последовательность задействования обра-
ботчиков событий следующая (рис. 6.55).
Рис. 6.56. Последовательность событий, вызываемая при записи
из формы существующей записи регистра сведений
Рис. 6.55. Последовательность событий, вызываемая
при записи из формы новой записи регистра сведений
Как видно на схеме, удаление «старого» набора записей
производится посредством записи пустого набора запи-
сей. При этом получается, что обработчики событий мо-
дуля набора записей будут вызываться дважды.
Итак, подробно рассмотрены возможности работы по-
средством менеджера записи. Однако надо заметить, что
и с набором записей также возможна работа в интерак-
тивном режиме (рис. 6.57).
Обратите внимание: ряд событий выполняются в одной
транзакции. Вследствие этого, если в рамках любого из
обработчиков этих событий установить параметру Отказ
значение Истина, то транзакция будет отменена. То есть
новая запись не запишется, да и любые другие изменения
в базе данных не выполнятся (ведь в рамках этих обра-
ботчиков событий разработчик мог пытаться менять что-
то еще). Это важно с точки зрения обеспечения непроти-
воречивости изменений в информации объектов, связан-
ных единой прикладной задачей.
В случае модификации уже существующей записи реги-
стра посредством менеджера записи могут быть измене-
ны значения ключевых полей. А значит, запись набора с
новыми ключевыми полями сама по себе не заместит
«старый» набор. Поэтому здесь система работает в два
этапа: сначала удаляет «старый» набор записей (состоя-
Рис. 6.57. Схема использования набора записей
регистра сведений
Пример организации интерактивного ввода приведен
в обработке РаспоряжениеНаУстановкуЦеныПокупателя, на
закладке Посредством формы набора записей. Эта обработка
входит в состав демонстрационной конфигурации «Хра-
нение информации и учет движения средств», которая
находится на прилагаемом компакт-диске.
Пользователь заполняет посредством соответствующих
полей ввода реквизиты формы ВыбранныйПокупатель и Да-
таУстановки. Далее, по нажатию кнопки Открыть форму на-
бора записей, управление передается процедуре, которая
представлена в листинге 6.15.
Листинг 6.15. Процедура ОткрытьФормуНабораЗаписей
Процедура ОткрытьФормуНабораЗаписей()
// Создать набор записей, соответствующий
// грануле "Период - Покупатель”
НаборЗаписей - РегистрыСведений.ПерсонифицированныйПрайс.
СоздатьНаборЗаписей():
НаборЗаписей.Отбор.Период.Установить(ДатаУстановки);
НаборЗаписей.Отбор.Покупатель.Установить(
ВыбранныйПокупатель):
// Прочитать его из базы данных
НаборЗаписей.Прочитать():
// Открыть форму набора записей
ФормаНабораЗаписей = НаборЗаписей.
ПолучитьФормуС"ФормаНабораЗаписей”,
Строка(ВыбранныйПокупатель) +
Строка(ДатаУстановки));
ФормаНабораЗаписей.Открыть!);
КонецПроцедуры
Краткий комментарий: сначала создается набор записей
регистра сведений, соответствующий основному отбору
по периоду и покупателю. Затем в него считываются дан-
ные из базы данных.
Потом создается форма данного набора записей с ключом
уникальности, определяемым как строка, составленная из
выбранного покупателя и даты установки. Указание та-
кого ключа уникальности важно для ситуации, когда
пользователь, не закрыв форму одного набора записей,
захочет редактировать информацию в форме другого на-
бора записей. Таким образом, если форма набора записей,
соответствующих ключу «покупатель — период», уже бу-
дет на момент выполнения процедуры открыта, она про-
сто активизируется. Если нет (а, например, будет открыта
форма другого набора записей), то система откроет новую
форму для редактирования именно этого набора записей.
Обработка Распоряжение на установку цен п... _ О X
Действия* (?)
Для покупателя: [Компания *Риона"
.... { ВыбранныйПокупатель
Непосредственная запись | Посредством Формы набор^зы-»—. —-
Рис. 6.58. Использование формы обработки
Распоряжение На Установку Цен Покупателя
Обработку дальнейших действий пользователя можно
доверить самой системе. Поскольку расширения формы
набора записей реализуют всю основную функциональ-
ность, которая может потребоваться при модификации
данных регистра (рис. 6.58).
Если разработчику необходимо изменить эту функцио-
нальность, то это возможно сделать за счет использова-
ния соответствующих обработчиков событий (рис. 6.59).
Рис. 6.59. Последовательность событий при записи
в форме набора записей регистра сведений
При работе с формой набора записей регистра сведений
порядок задействования обработчиков событий не разли-
чается для ситуаций записи нового набора записей и для
ситуации записи уже существовавшего, но модифициро-
ванного набора записей.
Дополнительная
функциональность при создании
и удалении записей
регистра сведений
Кроме рассмотренных выше основных вопросов органи-
зации заполнения и модификации информации регист-
ров сведений хотелось бы еще разобрать ряд вспомога-
тельных, но не менее важных для организации решения
некоторых прикладных задач вопросов.
Так для ряда задач важно не допустить записи данных
с «пустыми» значениями разрезов учета.
В рассмотренном выше примере регистра сведений Пер-
сопифицпроваппыйПрайс с прикладной точки зрения уди-
вительна, например, следующая запись (табл. 6.14). Трак-
товать ее данные не предоставляется возможным.
Таблица 6.14. Пример записи в регистре сведений
ПерсонифицированныйПрайс
Период Покупатель Номенкла- тура Цена
31.01.2005 Компания «Риона» 300,00
Для того чтобы не допустить записи подобной информа-
ции в регистр, можно, конечно выполнять соответствую-
щую проверку в обработчике события ПередЗаписью. Однако,
поскольку подобная задача в практике может встречаться
не раз, данная проверка добавлена к функциональности
платформы.
Для ее автоматического задействования достаточно лишь
установить свойство Запрет незаполненных значений у изме-
рения Номенклатура (рис. 6.60).
1 С: Предприятие X
©Запись не верна] Значение поля Номенклатура не может быть пустым! Компания "Риона” 31 01 2005
0:00:00 (Регистр сведений: П«гш«ццхе|1ьГ прайс)
Таблица 6.15. Пример ссылки на отсутствующий объект
базы данных
Период Покупатель Номенкла- тура Цена
31.01.2005 Компания «Риона» < Объект не найден> 300,00
В результате при выполнении непосредственного удале-
ния элементов справочника система будет производить
запись в регистр сведений пустого набора записей с отбо-
ром по ссылке на удаленный объект.
Кроме того, свойство Ведущее используется еще систе-
мой, например, при заполнении подменю Перейти команд-
ных панелей в формах списков и объектов (рис. 6.62).
Данная функциональность, опять же, облегчает быструю
разработку прикладных решений.
00021
Монитор
Монитор 19'1
00023
00024
Рис. 6.62. Автоматическое формирование пункта меню Перейти
Рис. 6.60. Свойства измерения Номенклатура
Хотелось бы обратить внимание, что данная проверка вы-
полняется именно в момент попытки записи данных в ре-
гистр. Если, например, сначала свойство установлено не
было и регистр уже заполнился данными записей (среди
которых встречаются и записи с пустыми значениями но-
менклатуры), а потом в конфигурации данное свойство
установили, то при реструктуризации базы данных это
действие никак не отрабатывается. Запрет касается имен-
но момента и только момента записи данных в регистр.
В отношении поля Период для периодических регистров
сведений и в отношении поля Регистратор регистра сведе-
ний с подчиненным режимом записи подобная проверка
выполняется всегда (рис. 6.61).
Рис. 6.61. Сообщение об ошибке при попытке записи
«пустого значения» поля Период
Другая особенность связана с удалением информации из
базы данных. Платформа 1 С: Предприятия допускает не-
посредственное удаление объектов без контроля ссылоч-
ной целостности. Если в результате такой операции будут
удалены, например, элементы справочника Номенклатура,
ссылки на которые использованы в записях регистра све-
дений, то информация регистра сведений с прикладной
точки зрения может стать некорректной (табл. 6.15).
Если разработчик хочет, чтобы подобные ситуации кор-
ректно отрабатывались средствами самой платформы, то
достаточно для измерения Номенклатура при конфигури-
ровании установить свойство Ведущее.
Получение данных
из регистров сведений
Только хранение информации, как таковое, вряд ли тре-
буется при решении прикладных задач. Конечно же, все-
гда подразумевается возможность получения хранимой
информации при необходимости.
Можно выделить два больших круга задач, касающихся
получения информации из регистров сведений:
♦ получение информации о записях регистра для техно-
логических целей (обычно касающихся именно хране-
ния этой информации);
♦ получение информации «функции» регистра (обычно
для решения вопросов, ради которых регистр создавали).
Таким образом, например, из рассмотренного выше реги-
стра ПерсонифицированныйПрайс, хранящего цены прода-
жи в разрезах покупателей и номенклатурных позиций,
может понадобиться получить информацию для проведе-
ния операций манипулирования с этими ценами. Напри-
мер, повысить на отдельные товары цены на определенный
процент. А может понадобиться проведение сравнитель-
ного анализа: насколько персональные цены в среднем
ниже общефирменных и как это влияет на вал продаж по
отдельным номенклатурным позициям.
Получение данных
из непериодических регистров
сведений
В случае работы с регистрами сведений, у которых отсут-
ствует привязка данных ко времени (непериодические
регистры), решение задач обоих типов выполняется непо-
средственным обращением к записям таблицы базы дан-
ных, отвечающей за хранение информации регистра.
В зависимости от сложности условий отборов, применяе-
мых при этом, в зависимости от необходимости соединения
информации регистра с информацией других источников,
в зависимости от необходимости использования механизма
динамического чтения данных используют или объектную
модель представления информации (чтение посредством
методов объектов, отвечающих за манипулирование дан-
ных регистров), или табличную модель представления
информации (обращение к данным посредством запро-
сов, написанных на языке запросов 1С:Предприятия).
И тот и другой способ обращения выполняется впослед-
ствии за счет одних и тех же запросов СУБД к таблице
регистра сведений.
Однако, исходя из функциональных возможностей, мож-
но различить ситуации, когда уместнее применять работу
с той или иной моделью.
Объектная модель обычно применяется:
♦ для случаев чтения данных с простейшими отборами
(обязательно только на равенство значению, более того,
применяя метод Выбрать О, отбор можно строить только
по одному полю);
♦ в случае необходимости применения механизма дина-
мического чтения данных. Посредством этого механиз-
ма чтение данных осуществляется по блокам, а не цели-
ком сразу всех. Данная функциональность подробно
описана в разделе «Список», с. 59.
Табличная модель применима:
♦ во всех случаях, когда не требуется использование ме-
ханизма динамического чтения данных.
Таким образом, посредством запросов можно выбирать
данные с отборами какой угодно сложности (как по изме-
рениям, так и по любым другим полям или по подчинен-
ным полям полей записей регистра). Кроме того, при не-
обходимости в том же запросе информацию регистра
можно тут же соединять с информацией других источни-
ков и/или выполнять дополнительную обработку полу-
ченных данных.
Рассмотрим несколько примеров, приведенных в обработ-
ке ДействияСДаннымиРегистраСведений в демонстрационной
конфигурации «Хранение информации и учет движения
средств», которая находится на прилагаемом компакт-диске.
Для непериодического независимого регистра сведений
Сотрудники, все поля которого — ссылки на элементы со-
ответствующих справочников (рис. 6.63), задача перебора
всех записей регистра может быть решена так, как показа-
но в листинге 6.16.
Сотрааники
Измерения
|“'t— Физическое Лицо
1— Подразделение
ф- (и Ресурсы
L.-g Должность
Рис. 6.63. Структура регистра Сотрудники
Листинг 6.16. Пример перебора всех записей регистра
ВыборкаЗаписей = РегистрыСведений.Сотрудники.ВыбратьО;
Пока ВыборкаЗаписей.Следующий() Цикл
И Выполнить действие с очередной записью
//...
КонецЦикла;
Хотелось бы отметить, что по умолчанию дополнитель-
ное упорядочивание записей при работе с выборкой не
производится (табл. 6.16).
Таблица 6.16. Пример результата работы с выборкой
Физическое лицо Подразделение Должность
Иванов Иван Сергеевич Отдел продаж Руководитель
Семенов Сергей Петрович Отдел продаж Менеджер
Семенов Сергей Петрович Отдел закупок Руководитель
Петровский Семен Иванович Руководство компании Руководитель
Петровская Ирина Ивановна Бухгалтерия Бухгалтер
В таблице выше видно, что ссылка по Семенову на отдел
продаж оказалась «раньше» ссылки на отдел закупок.
Хотя порядок мог быть и каким-то другим.
Теперь рассмотрим задачу получения должности опреде-
ленного физического лица в определенном подразделе-
нии. Это пример задачи на «функцию» регистра сведений.
В качестве «параметров» передаем значения физического
лица и подразделения, в качестве «результата функции»
ожидаем значение должности (листинг 6.17).
Листинг 6.17. Пример получения должности
физического лица
И Подготовить структуру отбора по измерениям
СтруктураОтбора = Новый Структура:
СтруктураОтбора.Вставить("ФизическоеЛицо", ПроверяемоеЛицо);
СтруктураОтбора.ВставитьС"Подразделение",
ВыбранноеПодразделение);
И Получить структуру с данными ресурсов записи
СтруктураРесурсов = РегистрыСведений. Сотрудники.
Получить(СтруктураОтбора):
И Сообщить занимаемую должность
Должность = СтруктураРесурсов.Должность:
Если Должность.Пустая() Тогда
Сообщить("В этом подразделении не работает");
Иначе
Сообщить(Должность);
КонецЕсли:
Обратите внимание: для метода ПолучитьО обязательна
передача параметра, содержащего структуру отбора зна-
чений по всем измерениям непериодического регистра.
Результатом применения метода является структура,
в которой для каждого элемента ключом будет название
ресурса регистра, а значением — значение ресурса из най-
денной записи регистра.
Следующая задача — проверить, работает ли в компании
определенное физическое лицо. И если работает — вы-
полнить некоторые действия с записью по этому сотруд-
нику.
Допустим, ссылка на проверяемое физическое лицо будет
в переменной ПроверяемоеЛицо. Тогда решение можно
реализовать следующим образом (листинг 6.18).
Листинг 6.18. Пример проверки наличия записи
по физическому лицу в регистре сведений
И Подготовить структуру отбора по измерению "ФизическоеЛицо"
СтруктураОтбора = Новый Структура(
"ФизическоеЛицо”, ПроверяемоеЛицо);
И Получить выборку с отбором
ВыборкаЗаписей = РегистрыСведений.Сотрудники.ВыбратьС
СтруктураОтбора);
И Выполнить действия
Пока ВыборкаЗаписей.СледующийО Цикл
И Выполнить действия с записью
//...
КонецЦикла;
В данном примере применялся отбор по значению изме-
рения регистра. Вообще в качестве полей для отбора мо-
гут использоваться измерения или реквизиты регистра,
для которых в конфигураторе установлен признак индек-
сирования в значение Индексировать или установлен при-
знак Ведущее.
Но необходимо помнить, что отбор при этом возможен
только по одному полю.
Рассмотренные задачи также могли быть решены и по-
средством соответствующих запросов.
Рассмотрим ряд задач, когда применение запросов более
уместно, нежели применение объектной модели.
Доступ к информации таблицы регистра в базе данных
осуществляется посредством основной таблицы регистра
сведений. Состав ее полей соответствует составу полей
таблицы регистра сведений в базе данных (можно по-
смотреть в разделе «Структура регистра сведений», с. 111).
Допустим, требуется сообщить наименования физиче-
ских лиц, упомянутых в записях регистра сведений «Со-
трудники». Условие — в наименовании должностей этих
лиц должно быть слово «Руководитель». Эта задача мо-
жет быть решена следующим образом (листинг 6.19).
Листинг 6.19. Пример получения физических лиц,
в наименовании должностей которых присутствует слово
Руководитель
Процедура СообщитьСписокРуководителейПредприятияНажатиеС
Элемент)
И Получить перечень нужных физических лиц
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ РАЗЛИЧНЫЕ
| Сотрудники.ФизическоеЛицо.Наименование КАК ФизЛицо
|ИЗ
| РегистрСведений.Сотрудники КАК Сотрудники
I ГДЕ
Сотрудники.Должность.Наименование ПОДОБНО
""^Руководитель^...............................:
I
// Перебрать и сообщить полученный список
Результат = Запрос.Выполнить О;
Выборка = Результат.ВыбратьО:
Пока Выборка.СледующийО Цикл
Сообщить(Выборка.ФизЛицо);
КонецЦикла;
КонецПроцедуры
Краткий комментарий; в запросе выбираем неповторяю-
щиеся наименования всех физических лиц из таблицы
регистра, если наименования должностей в этих записях
содержат набор символов «Руководитель» (в любом месте
наименования). Далее выборка результата запроса пере-
бирается, и в цикле сообщается полученная информация.
Попытка решения этой задачи посредством выборки
была бы грубой методической ошибкой:
♦ во-первых, выборка не может строиться с отбором по
значениям ресурсов. То есть перебирать пришлось бы
все записи регистра;
♦ во-втпорых, условие отбора устанавливается не по зна-
чению поля Должность, а по наличию в наименовании
этой должности сочетания символов «Руководитель».
То есть такая проверка в цикле перебора записей реги-
стра привела бы к необходимости применения запроса
СУБД к таблице данных справочника Должности. И это
на каждом шаге цикла!
♦ в-третьих, сообщать нужно наименования физических
лиц. То есть при выполнения условия проверки для
каждой «подходящей» записи регистра, системе при-
шлось бы еще обращаться посредством запроса СУБД
к таблице справочника ФизическиеЛица для считыва-
ния наименования элемента, соответствующего нуж-
ной ссылке.
Таким образом, решение посредством объектной модели
привело бы к многочисленным обращениям к таблицам
базы данных (на каждом шаге цикла перебора всех запи-
сей регистра).
Решение же посредством запроса будет реализовано сис-
темой за счет левых соединений таблиц регистра и двух
справочников, но за одно обращение к базе данных. Не
говоря уже о том, что выборка результата запроса будет
меньше выборки всех записей регистра.
Следующая задача — сообщить, сколько подразделений
компании задействовано в регистре «Сотрудники». Эта
задача может быть решена посредством следующего за-
проса (листинг 6.20).
Листинг 6.20. Пример получения количества
задействованных подразделений
Процедура СообщитьСколькоПодразделенийВКомпанииНажатиеС
Элемент)
И Установить исходно, что подразделений нет
КоличествоПодразделений = 0;
И Посчитать количество "непустых" подразделений
И в записях регистра
Запрос = Новый Запрос:
Запрос.Текст = "ВЫБРАТЬ
КОЛИЧЕСТВОСРАЗЛИЧНЫЕ Сотрудники.Подразделение)
КАК КоличествоПодразделений
ИЗ
РегистрСведений.Сотрудники КАК Сотрудники
ГДЕ
Сотрудники.Подразделение <> &ПустоеПодразделение";
Запрос.УстановитьПараметр("ПустоеПодразделение".
Справочники.Подразделения.ПустаяСсылка());
Результат = Запрос.ВыполнитьО;
Выборка = Результат.ВыбратьО;
Если Выборка.СледующийО Тогда
КоличествоПодразделений =
Выборка.КоличествоПодразделений;
КонецЕсли;
И Сообщить полученные результаты
Сообщить(КоличествоПодразделений);
КонецПроцедуры
В данном случае применен запрос, вычисляющий количе-
ство упоминаний различных подразделений в соответст-
вующем поле записей регистра. При этом записи с неза-
полненным полем Подразделение не учитываются.
Если выборка запроса будет непустой (есть записи), то
исходное нулевое количество подразделений заменяется
на определенное в запросе.
В данном случае продемонстрирована возможность при-
менения агрегатных функций при чтении информации
регистра запросом.
Следующая задача — получить список «внутренних со-
вместителей» с предоставлением информации: в каких
отделах, на каких должностях они работают. Внутренни-
ми совместителями называются физические лица, зани-
мающие несколько должностей или в одном, или в раз-
личных подразделениях предприятия.
Данная задача может быть решена посредством примене-
ния запроса со следующим текстом (листинг 6.21).
Листинг 6.21. Пример получения списка внутренних
совместителей
ВЫБРАТЬ
Сотрудники.ФизическоеЛицо КАК ФизическоеЛицо,
Сотрудники.Подразделение КАК Подразделение,
Сотрудники.Должность КАК Должность
ИЗ
РегистрСведений.Сотрудники КАК Сотрудники
ГДЕ
Сотрудники.ФизическоеЛицо В
(ВЫБРАТЬ
Сотрудники.ФизическоеЛицо КАК ФизическоеЛицо
ИЗ
РегистрСведений.Сотрудники КАК Сотрудники
СГРУППИРОВАТЬ ПО
Сотрудники.ФизическоеЛицо
ИМЕЮЩИЕ
КОЛИЧЕСТВО(Сотрудники.ФизическоеЛицо) > 1)
В запросе выбирается информация по всем записям реги-
стра, где упоминаются физические лица, соответствую-
щие условию. Условие проверяет вхождения физических
лиц в перечень, полученный вложенным запросом. Во
вложенном запросе применяется группирование с приме-
нением агрегатной функции КОЛИЧЕСТВОО по полю Физиче-
скоеЛицо, при этом условием будут отсечены те физлица,
которые упоминались только один раз.
Получение данных
из периодических регистров
сведений
Для периодических регистров сведений задачи получе-
ния информации для технологических вопросов решают-
ся так же, как и было рассмотрено выше для непериоди-
ческих регистров. Поэтому все примеры, рассмотренные
в разделе «Получение данных из непериодических реги-
стров сведений», с. 120, будут уместны и в этом случае.
Единственное отличие в том, что к перечню ключевых
полей добавляется поле Период, которое можно использо-
вать в отборах. Так, метод ВыбратьО для случая периоди-
ческого регистра позволяет работать не только с отбором
по значению измерения, но и с отбором по временному
интервалу, в который могут попадать значения поля Пе-
риод.
Рассмотрим примеры получения информации из перио-
дического (периодичность — В пределах дня) независимого
регистра сведений ПерсонифицированныйПрайс (рис. 6.64).
В Пер<1»«^мфованныйПрайС
В JL- Измерения
i : 1— Покупатель
1— Номенкгвтура
Й- Ресурсы
I Цена
Рис. 6.64. Структура регистра ПерсонифицированныйПрайс
Для получения выборки всех записей регистра в интерва-
ле дат между значениями, содержащимися в переменных
НачалоИнтервала и КонецИнтервала, с отбором по номенк-
латурной позиции (содержится в переменной Выбранный-
Товар) можно сделать следующий фрагмент кода (лис-
тинг 6.22).
Листинг 6.22. Пример получения записей регистра
И Подготовить структуру отбора по измерению "Номенклатура"
СтруктураОтбора = Новый СтруктураС"Номенклатура",
ВыбранныйТовар);
И Получить выборку записей
ВыборкаЗаписей = РегистрыСведений.ПерсонифицированныйПрайс.
Выбрать(НачалоИнтервала,
КонецИнтервала.
СтруктураОтбора);
Пока ВыборкаЗаписей.Следующий() Цикл
// Выполнить действие с очередной записью
//...
КонецЦикла;
Необходимо помнить, что отбор при этом возможен толь-
ко по одному полю, и в качестве полей для отбора могут
использоваться измерения или реквизиты регистра, для
которых в конфигураторе установлен признак индекси-
рования в значение Индексировать или установлен признак
Ведущее.
Кроме того, для реализации различных задач, в плане не-
обходимости включения/выключения записей «гранич-
ных периодов», нужно иметь в виду следующее:
♦ в параметр НачалоИнтервала передается начало интерва-
ла, в котором будут выбираться записи периодического
регистра. Он может задаваться значениями типа Дата,
МонентВренени, Граница. Если значение данного параметра
не указано, то будут выбираться записи с самой ранней
включительно;
♦ в параметр КонецИнтервала передается конец интервала,
в котором будут выбираться записи периодического ре-
гистра. Он также может задаваться значениями типа
Дата, МонентВренени, Граница. Если значение данного пара-
метра не указано, то будут выбираться записи по самую
последнюю включительно.
В результате, при передаче значений типа Дата или Монент-
Вренени в выборку, получим записи включая значения На-
чалоИнтервала и КонецИнтервала (рис. 6.65).
Если же требуется получить записи, исключая гра-
ничные, то необходимо использовать объект Граница. На-
пример, получение выборки в интервале дат, исключая
границы, может быть выполнено следующим образом
(листинг 6.23).
значения
поля
"Период"
записей
КонецИнтервала
Временная ось
Интервал выборки
Рис. 6.65. Получение записей включая граничные значения
Листинг 6.23. Пример получения записей
регистра сведений
// Установить значения границ
ГраницаНачалаИнтервала = Новый Граница(НачалоИнтервала,
ВидГ раницы.Исключая);
ГраницаКонцаИнтервала = Новый Граница(КонецИнтервала,
ВидГ раницы.Исключая);
И Подготовить структуру отбора по измерению "Номенклатура"
СтруктураОтбора = Новый Структура("Номенклатура",
ВыбранныйТовар);
И Получить выборку записей
ВыборкаЗаписей =
РегистрыСведений.ПерсонифицированныйПрайс.Выбрать(
Г раницаНачалаИнтервала,
Г раницаКонцаИнтервала,
СтруктураОтбора);
Пока ВыборкаЗаписей.СледующийО Цикл
И Выполнить действие с очередной записью
//...
КонецЦикла;
Получение данных в этом случае можно проиллюстриро-
вать следующей схемой (рис. 6.66).
Н ачалоИнтервала
КонецИнтервала
11
Временная ось
поля
"Период"
записей
Интервал выборки
Рис. 6.66. Получение записей исключая граничные значения
Кроме того, если периодичность регистра меньше чем
день (В пределах секунды или По позиции регистратора), то не-
обходимо помнить, что дата в системе 1С:Предприятие
включает в себя и время.
Даже если время не указано явно, оно принимает значе-
ние 00:00:00. То есть если в качестве параметра НачалоИн-
тервала передать значение «1 декабря 2005 года» (данное
значение может быть получено так: ’20051201'), а в каче-
стве параметра КонецИнтервала передать «31 декабря 2005
года» (’20051231'), то в результате выборки будут построены
с даты «01.12.2005 00:00:00» по дату «31.12.2005 00:00:00».
То есть в результат, по сути, не войдут данные 31 декабря
(рис. 6.67).
Для предотвращения возможных недоразумений по это-
му поводу удобно использовать функцию КонецДняО. Эта
функция возвращает значение последней секунды дня
указанной в качестве параметра даты (листинг 6.24).
В результате будут получены записи с даты «01.12.2005
00:00:00» по дату «31.12.2005 23:59:59» включительно.
При использовании запроса можно реализовывать не
только перечисленные выше, но и гораздо более сложные
условия, в том числе и по полю Период.
Рис. 6.67. Пример получения данных регистра сведений,
когда интервал задан без явного указания времени
Листинг 6.24. Пример использования функции
КонецДняО
И Определить конец дня "правой" границы
КонецДняИнтервала = КонецДня(КонецИнтервала):
И Получить выборку записей
ВыборкаЗаписей = РегистрыСведений.ЦеныНоменклатуры.Выбрать(
НачалоИнтервала.
КонецДняИнтервала);
Пока ВыборкаЗаписей.Следующий() Цикл
И Выполнить действие с очередной записью
//...
КонецЦикла:
Например, задача получения выборки данных всех записей
регистра ПерсонифицированныйПрайс, которые датированы
выходными днями (субботами и воскресениями), может
быть решена посредством следующего запроса (листинг 6.25).
Листинг 6.25. Пример запроса
ВЫБРАТЬ
ПерсонифицированныйПрайс.Период,
ПерсонифицированныйПрайс.Покупатель,
ПерсонифицированныйПрайс.Номенклатура,
ПерсонифицированныйПрайс.Цена
ИЗ
РегистрСведений.ПерсонифицированныйПрайс КАК
ПерсонифицированныйПрайс
ГДЕ
ДЕНЬНЕДЕЛИ(ПерсонифицированныйПрайс.Период) > 5
В запросе было применено условие с использованием
функции работы с датами языка запросов — ДЕНЬНЕДЕЛИО.
Данная функция возвращает порядковые номера дней не-
дели по переданному параметру.
Рассмотрим примеры задач получения информации из
периодического регистра сведений не в технологических
целях, а для обслуживания задач учетных или аналитиче-
ских механизмов.
Если необходимо получить информацию значений ресур-
сов одной записи регистра, соответствующей указанным
в параметрах значениям всех измерений и периода, объ-
ектная модель получения информации также позволяет
использовать метод Получить().
Например, нужно сообщить, какую цену установили для
покупателя Покупатель по номенклатурной позиции То-
вар, начиная с ДатаУстановки (листинг 6.26).
Часто встречаются задачи, в которых каждая запись пе-
риодического регистра сведений используется не как
средство для хранения данных, а как средство для хране-
ния информации истории изменения данных.
Листинг 6.26. Пример получения цен по номенклатурной
позиции
И Подготовить структуру отбора по измерениям
СтруктураОтбора = Новый Структура;
СтруктураОтбора.Вставить("Покупатель", Покупатель);
СтруктураОтбора.Вставить("Номенклатура", Товар);
И Получить структуру с данныии ресурсов записи
СтруктураРесурсов =
РегистрыСведений.ПерсонифицированныйПрайс.Получить(
ДатаУстановки,
СтруктураОтбора);
И Сообщить цену
Сообщить(СтруктураРесурсов.Цена);
Ведь в рассмотренном выше примере, если цена на товар
для этого покупателя была установлена не именно на эту
дату, а на какую-то другую, то метод Получить О вернет
структуру с пустыми значениями (рис. 6.68).
В итоге получим желаемый результат (рис. 6.69).
Записи периодического регистра (периодичность - “В пределах дня*']
Рис. 6.69. Пример использования метода ПолучитьПоследнееО
Записи периодического регистра (периодичность - “В пределах дня**]
Рис. 6.68. Пример использования метода ПолучитьО
для периодического регистра сведений
С прикладной точки зрения, в ситуации, отображенной
на схеме, при обращении к данным регистра, пользова-
тель мог хотеть получить «актуальное» для 12.10.2005
значение цены, а не установленное 12.10.2005.
То есть в логике пользователя, как само собой разумею-
щееся, может лежать правило: «пока цена не сменилась —
действует прежняя». И при обращении к данным регист-
ра пользователь желает получить цену, установленную на
некую дату, а если не установлена, то «прежнюю», в об-
щем случае — «последнюю установленную».
Для реализации подобной логики в функциональности
периодического регистра сведений существует метод По-
лучитьПоследнееО. Для тех же переменных получение по-
следних актуальных данных может быть таким (лис-
тинг 6.27).
Листинг 6.27. Пример использования метода
ПолучитьПоследнее()
// Подготовить структуру отбора по измерениям
СтруктураОтбора = Новый Структура;
СтруктураОтбора.Встав ить("Покупатель", Покупатель);
СтруктураОтбора.ВставитьС'Номенклатура", Товар);
// Получить структуру с данными актуальных значений ресурсов
СтруктураРесурсов = РегистрыСведений.
ПерсонифицированныйПрайс.
ПолучитьПоследнееСДатаУстановки.
СтруктураОтбора);
// Сообщить "последнюю" цену
Сообщить(СтруктураРесурсов.Цена);
Может встретиться задача, когда пользователь заранее не
знает, для каких комбинаций значений измерений ему
требуется получить данные «последних актуальных» (на
дату КонецПериода) значений ресурсов регистра. То есть
хочет получить все значения для всех комбинаций изме-
рений (или для некоторых, соответствующих условиям
отбора) (рис. 6.70).
Рис. 6.70. Задача получения последних значений по комбинации
значений измерений
Для решения подобных задач можно использовать метод
СрезПоследнихО, возвращающий таблицу значений, запол-
ненную данными записей, наиболее поздних ближайших
к дате среза (КонецПериода) (табл. 6.17).
Таблица 6.17. Результат получения среза последних
Покупатель Номенклатура Цена
ООО Сигма Пульт VX 120,00
ООО Сигма Пульт PW 218,00
Ялта-ЛТД Пульт VX 135,00
В ходе выполнения метода СрезПоследнихО, платформа
ЮПредприятия фактически выполняет запрос к базе
данных. Данный запрос реализует следующий алгоритм:
♦ выбрать записи таблицы регистра, соответствующие
условиям отбора по значениям измерений, у которых
значение поля Период меньше или равно значению па-
раметра КонецПериода;
♦ по выбранным записям получить максимальные значе-
ния поля Период для каждой комбинации значений по-
лей измерений. Это будут данные вложенного запроса.
Получается, что в нем известны ключи «последних акту-
альных» записей, то есть наиболее близких к дате среза;
♦ соединить таблицу вложенного запроса с основной таб-
лицей регистра по равенству значений полей измере-
ний и поля Период;
♦ из полученной таблицы получить интересующие дан-
ные «последних актуальных» записей.
Подобную функциональность можно реализовать запро-
сом по основной таблице периодического регистра сведе-
ний (листинг 6.28).
Листинг 6.28. Пример получения среза последних
запросом
ВЫБРАТЬ
ПерсонифицированныйПрайс.Покупатель,
ПерсонифицированныйПрайс.Номенклатура,
ПерсонифицированныйПрайс.Цена
ИЗ
(ВЫБРАТЬ
ПерсонифицированныйПрайс.Покупатель КАК Покупатель.
ПерсонифицированныйПрайс.Номенклатура
КАК Номенклатура,
МАКСИМУМ(ПерсонифицированныйПрайс.Период) КАК Период
ИЗ
РегистрСведений.ПерсонифицированныйПрайс
КАК ПерсонифицированныйПрайс
ГДЕ
ПерсонифицированныйПрайс.Период <= &КонецПериода
И Указать другие условия от