Для формирования и выполнения запросов к таблицам базы данных в платформе 1С используется специальный объект языка программирования Запрос. Создается этот объект вызовом конструкции Новый Запрос. Запрос удобно использовать, когда требуется получить сложную выборку данных, сгруппированную и отсортированную необходимым образом. Классический пример применения запроса - получение сводки по состоянию регистра накопления на определенный момент времени. Так же, механизм запросов позволяет легко получать информацию в различных временных разрезах.
Текст запроса – это инструкция, в соответствии с которой должен быть выполнен запрос. В тексте запроса описывается:
таблицы информационной базы, используемые в качестве источников данных запроса;
поля таблиц, которые требуется обрабатывать в запросе;
правила группировки;
сортировки результатов;
и т. д.
Инструкция составляется на специальном языке – языке запросов и состоит из отдельных частей – секций, предложений, ключевых слов, функций, арифметических и логических операторов, комментариев, констант и параметров.
Язык запросов платформы 1С очень похож на синтаксис других SQL-языков, но имеются отличия. Основными преимуществами встроенного языка запросов являются: разыменование полей, наличие виртуальных таблиц, удобная работа с итогами, нетипизированные поля в запросах.
Рекомендации по написанию запросов к базе данных на языке запросов платформы 1С:
1) Текст запроса может содержать предопределенные данные конфигурации, такие как:
значения перечислений;
предопределенные данные:
справочников;
планов видов характеристик;
планов счетов;
планов видов расчетов;
пустые ссылки;
значения точек маршрута бизнес-процессов.
Также текст запроса может содержать значения системных перечислений, которые могут быть присвоены полям в таблицах базы данных: ВидДвиженияНакопления, ВидСчета и ВидДвиженияБухгалтерии. Обращение в запросах к предопределенным данным конфигурации и значениям системных перечислений осуществляется с помощью литерала функционального типа ЗНАЧЕНИЕ. Данный литерал позволяет повысить удобочитаемость запроса и уменьшить количество параметров запроса.
Пример использования литерала ЗНАЧЕНИЕ:
ГДЕ Город = ЗНАЧЕНИЕ(Справочник.Города.Москва)
ГДЕ Город = ЗНАЧЕНИЕ(Справочник.Города.ПустаяСсылка)
ГДЕ ТипТовара = ЗНАЧЕНИЕ(Перечисление.ВидыТоваров.Услуга)
ГДЕ ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
ГДЕ ТочкаМаршрута = ЗНАЧЕНИЕ(БизнесПроцесс.БизнесПроцесс1.ТочкаМаршрута.Действие1
2) Использование инструкции АВТОУПОРЯДОЧИВАНИЕ в запросе может сильно время выполнения запроса, поэтому, если сортировка не требуется, то лучше вообще ее не использовать. Во большинстве случаях лучше всего применять сортировку с помощью инструкции УПОРЯДОЧИТЬ ПО.
Автоупорядочивание работает по следующим принципам:
Если в запросе было указано предложение УПОРЯДОЧИТЬ ПО, то каждая ссылка на таблицу, находящаяся в этом предложении, будет заменена полями, по которым по умолчанию сортируется таблица (для справочников это код или наименование, для документов – дата документа). Если поле для упорядочивания ссылается на иерархический справочник, то будет применена иерархическая сортировка по этому справочнику.
Если в запросе отсутствует предложение УПОРЯДОЧИТЬ ПО, но есть предложение ИТОГИ, тогда результат запроса будет упорядочен по полям, присутствующим в предложении ИТОГИ после ключевого слова ПО, в той же последовательности и, в случае если итоги рассчитывались по полям – ссылкам, то по полям сортировки по умолчанию таблиц, на которые были ссылки.
Если в запросе отсутствуют предложения УПОРЯДОЧИТЬ ПО и ИТОГИ, но есть предложение СГРУППИРОВАТЬ ПО, тогда результат запроса будет упорядочен по полям, присутствующим в предложении, в той же последовательности и, в случае если группировка велась по полям – ссылкам, то по полям сортировки по умолчанию таблиц, на которые были ссылки.
В случае же, если в запросе отсутствуют предложения и УПОРЯДОЧИТЬ ПО, ИТОГИ и СГРУППИРОВАТЬ ПО, результат будет упорядочен по полям сортировки по умолчанию для таблиц, из которых выбираются данные, в порядке их появления в запросе.
В случае, если запрос содержит предложение ИТОГИ, каждый уровень итогов упорядочивается отдельно.
3) Что бы избежать повторного запроса к базе данных при выводе результата запроса пользователю (например, построение запроса или отображение результата запроса с помощью табличного документа) полезно использовать инструкцию ПРЕДСТАВЛЕНИЕССЫЛКИ, которая позволяет получать представление ссылочного значения. Пример:
Так же возможно использование инструкции ПРЕДСТАВЛЕНИЕ - предназначена для получения строкового представления значения произвольного типа. Отличие этих инструкций в том, что в первом случае, если инструкции передать ссылку, результатом будет строка, В остальных случаях результатом будет значение переданного параметра. Во втором случае, результатом инструкции всегда будет строка!
4) Если в запросе имеется поле с составным типом, то для таких полей возникает необходимость привести значения поля к какому-либо определенному типу с помощью инструкции ВЫРАЗИТЬ, что позволит убрать лишние таблицы из левого соединения с полем составного типа данных и ускорить выполнение запроса. Пример:
Имеется регистра накопления ОстаткиТоваров, у которого поле Регистратор имеет составной тип. В запросе выбираются Дата и Номер документов ПоступлениеТоваров, при этом при обращении к реквизитам документа через поле Регистратор не происходит множество левых соединений таблицы регистра накопления с таблицами документов-регистраторов.
Если приведение типа считается не осуществимым, то результатом приведения типа будет значение NULL.
5) Не стоит забывать про инструкцию РАЗРЕШЕННЫЕ, которая означает, что запрос выберет только те записи, на которые у текущего пользователя есть права. Если данное слово не указать, то в случае, когда запрос выберет записи, на которые у пользователя нет прав, запрос отработает с ошибкой.
6) В случае, если в запросе используется объединение, и в некоторых частях объединения присутствуют вложенные таблицы (документ с табличной частью), а в некоторых нет, возникает необходимость дополнения списка выборки полями – пустыми вложенными таблицами. Делается это при помощи ключевого слова ПУСТАЯТАБЛИЦА, после которого в скобках указываются псевдонимы полей, из которых будет состоять вложенная таблица. Пример:
7) Что бы в результат запроса не попали повторяющиеся строки, следует использовать инструкцию РАЗЛИЧНЫЕ, потому что так нагляднее и понятнее, а инструкция СГРУППИРОВАТЬ ПО применяется для группировки с помощью агрегатных функций. Ксати, при использовании агрегатных функций предложение СГРУППИРОВАТЬ ПО может быть и не указано совсем, при этом все результаты запроса будут сгруппированы в одну единственную строку. Пример:
8) Инструкция СГРУППИРОВАТЬ ПО позволяет обращаться к полям верхнего уровня, без группировки результатов по этим полям, если агрегатные функции применены к полям вложенной таблицы. Хотя в справке 1С написано, при группировке результатов запроса в списке полей выборки обязательно должны быть указаны агрегатные функции, а помимо агрегатных функций в списке полей выборки допускается указывать только поля, по которым осуществляется группировка. Пример:
9) Инструкция ЕСТЬNULL предназначена для замены значения NULL на другое значение, но не забываем, что второй параметр будет преобразован к типу первого в случае, если тип первого параметра является строкой или числом.
10) При обращении к главной таблице можно в условии обратиться к данным подчиненной таблицы. Такая возможность называется разыменование полей подчиненной таблицы.
Пример (поиск документов, содержащих в табличной части определенный товар):
Преимущество этого запроса перед запросом к подчиненной таблице Приходная.Товары в том, что если есть дубли в документах, результат запроса вернет только уникальные документы без использования ключевого слова РАЗЛИЧНЫЕ.
11) Интересный вариант оператора В - это проверка вхождения упорядоченного набора в множество таких наборов (Поле1, Поле2, ... , ПолеN) В (Поле1, Поле2, ... , ПолеN).
Пример:
12) При любой возможности используйте виртуальные таблицы запросов. При создании запроса система предоставляет в качестве источников данных некоторое количество виртуальных таблиц - это таблицы, которые так же являются результатом запроса, который система формирует в момент выполнения соответствующего участка кода.
Разработчик может самостоятельно получить те же самые данные, которые система предоставляет ему в качестве виртуальных таблиц, однако алгоритм получения этих данных не будет оптимизирован, так как:
Все виртуальные таблицы параметризованы, т. е. разработчику предоставляется возможность задать некоторые параметры, которые система будет использовать при формировании запроса создания виртуальной таблицы. В зависимости от того, какие параметры виртуальной таблицы указаны разработчиком, система может формировать РАЗЛИЧНЫЕ запросы для получения одной и той же виртуальной таблицы, причем они будут оптимизированы с точки зрения переданных параметров.
Не всегда разработчик имеет возможность получить доступ к тем данным, к которым имеет доступ система.
13) В клиент-серверном варианте работы функция ПОДСТРОКА() реализуется при помощи функции SUBSTRING() соответствующего оператора SQL, передаваемого серверу баз данных SQL Server, который вычисляет тип результата функции SUBSTRING() по сложным правилам в зависимости от типа и значений ее параметров, а так же в зависимости от контекста, в котором она используется. В большинстве случаев эти правила не оказывают влияния на выполнение запроса, но бывают случаи, когда для выполнения запроса существенна максимальная длина строки результата, вычисленная SQL Server. Важно иметь в виду, что в некоторых контекстах использования функции ПОДСТРОКА() максимальная длина ее результата может оказаться равной максимальной длине строки ограниченной длины, которая в SQL Server равна 4000 символам. Это может привести к неожиданному аварийному завершению выполнения запроса:
Microsoft OLE DB Provider for SQL Server: Warning: The query processor could not produce a query plan from the optimizer because the total length of all the columns in the GROUP BY or ORDER BY clause exceeds 8000 bytes.
HRESULT=80040E14, SQLSTATE=42000, native=8618
Чтобы избежать такой ошибки, не рекомендуют использовать функцию ПОДСТРОКА() с целью приведения строк неограниченной длины к строкам ограниченной длины. Вместо нее лучше использовать операцию приведения типа ВЫРАЗИТЬ().
14) С осторожностью используйте ИЛИ в конструкции ГДЕ, так как использование условия с ИЛИ может значительно "утяжелить" запрос. Решить проблему можно конструкцией ОБЪЕДИНИТЬ ВСЕ. Пример:
15) Условие НЕ В в конструкции ГДЕ увеличивает время исполнения запроса, так как это своего рода НЕ (ИЛИ1 ИЛИ2 ... ИЛИn), поэтому для больших таблиц старайтесь использовать ЛЕВОЕ СОЕДИНЕНИЕ с условием ЕСТЬ NULL. Пример:
16) При использовании Временных таблиц нужно индексировать поля условий и соединений в этих таблицах, НО, при использовании индексов запрос может выполняться еще медленнее. Поэтому необходимо анализировать каждый запрос с применением индекса и без, замерять скорость выполнения запроса и принимать окончательное решение.
Если вы помещаете во временную таблицу данные, которые изначально индексированы по некоторым полям, то во временной таблице индекса по этим полям уже не будет.
17) Если вы не используете Менеджер временных таблиц, то явно удалять временную таблицу не требуется, она будет удалена после завершения выполнения пакетного запроса, иначе следует удалить временную таблицу одним из способов: командой УНИЧТОЖИТЬ в запросе, вызвать метод МенеджерВременныхТаблиц.Закрыть().
Понимание архитектуры используемой СУБД очень важно для правильной эксплуатации, но местами переоценено: администратору, DevOps-специалисту или разработчику прикладных систем вовсе необязательно знать подробности внутреннего устройства B-дерева или тонкости работы легковесных блокировок. Это, конечно, все очень интересно, но существенно загромождает главы Concepts соответствующих руководств или доклады про архитектуру СУБД и оставляет практическим специалистам существенно меньше времени на более важные и насущные с точки зрения повседневной эксплуатации базы данных проблемы.
В рамках данного семинара, мы эту проблему попробовали устранить и рассмотреть несколько жизненно-важных систем PostgreSQL со следующих точек зрения:
теоретические основы;
практическая реализация и суровая практика ежедневной эксплуатации.
Главной основой любой базы данных является транзакционная машина:
Как она реализованная в PostgreSQL?
Какие алгоритмы и протоколы лежат в основе?
Как в PostgreSQL реализованы Undo и Redo?
Как устроен Write Ahead Log?
Для чего нужен и как работает автовакуум?
Какие могут быть проблемы в работе всех этих систем?
Их мониторинг и настройка: как найти и исправить проблемы?
Говоря о каждой системе PostgreSQL мы сравнивали их с другими СУБД, такими как Oracle, IBM DB2 LUW, MS SQL Server & чтобы специалистам, имеющим опыт с другими СУБД было быстрее и проще разобраться.
Разберем, как изменялся (скорее дополнялся) синтаксис текстов запросов на простом примере: Проводится документ Расходная содержащая в табличной части Товары список продаваемых товаров и количество. При проведении такого документа необходимо обеспечить контроль отрицательных остатков хранящихся в регистре накопления остатков ОстаткиТоваров.
Структура конфигурации представлена на рисунке справа:
Сформируем запрос к табличной части документа и виртуальной таблице Остатки регистра накопления. Учтем возможные дубли строк в документе, для этого произведем группирование записей.
Естественно приведенный запрос абсолютно не оптимален. С помощью вложенных запросов оптимизируем его: Произведем группирование табличной части документа до соединения с таблицей остатков, в параметры виртуальной таблицы передадим список товаров как значение условия для расчета остатков. В итоге наш запрос примет следующий вид:
Если бы в запросе необходимо было бы получить данные из остатков разных регистров то значение фильтра, а следовательно и наш второй вложенный запрос, повторялся бы во всех параметрах виртуальных таблиц, естественно что система при каждом вложенном запросе заново обращается к базе данных для получения данных.
Временные таблицы
Не помню уже с какого релиза в запросах стало можно использовать временные таблицы. Для этого используется объект «Менеджер временных таблиц». Фактически менеджер временных таблиц описывает пространство имен временных таблиц и отвечает за их создание и уничтожение в базе данных.
Сами временные таблицы действительно физически создаются в базе, соответственно следует относиться к ним осторожно, так как дисковая подсистема на сегодняшний момент самая медленная часть техники, а скорость создания и уничтожения таблиц напрямую от нее зависит.
Перепишем запрос для использования временных таблиц. Во временные таблицы поместим сгруппированную табличную часть документа и список товаров для фильтра виртуальных таблиц:
При использовании временных таблиц в тексте запроса применяют инструкцию Поместить для создания новой временной таблицы, в этом случае в результат запроса система передает не содержимое этой таблицы (см прим 1 и прим 2 в тексте выше), а количество записей помещенных во временную таблицу, по желанию можно не принимать это значение.
Также допускается использование инструкции Уничтожить в этом случае временная таблица уничтожается, в противном случае временные таблицы уничтожаются вместе с объектом менеджер временных таблиц.
В основном нашем запросе я использовал названия временных таблиц как указание на источник получения данных (им обязательно надо назначать синоним, что мы и видим в тексте). Использовать временные таблицы как источник можно не единожды, что при умелом их применении позволит и сократить текст запроса (улучшиться читабельность сложных запросов) и увеличить скорость (при использовании данных временной таблицы в нескольких местах запроса).
Пакетные запросы
Пакетные запросы логично дополняют функционал временных таблиц и дают больше возможностей при работе с запросами.
В пакетном запросе фактически можно описать несколько запросов, как связанных между собой использованием временных таблиц, так и не связанных (можно, но не понятно зачем?). В итоге можно выполнить последовательно все запросы и принять в результате либо массив с результатами исполнения каждого запроса, либо результат последнего. Для получения массива с результатами запроса применяют метод ВыполнитьПакет() объекта запрос, а для получения результата последнего запроса ВыполнитьЗапрос().
В тексте запроса, запросы пакета разделяются символом «;» (точка с запятой). Область имен виртуальных таблиц у одного пакетного запроса одна. Использование менеджера временных таблиц не требуется, но возможно если вы хотите передать временные таблицы из одного пакетного запроса в другой.
Перепишем процедуру для использования пакетных запросов:
Фактически я убрал определение объекта запрос и использование менеджера временных таблиц, объединил тексты запросов (обратите внимание на разделитель «;» между текстами). В результате текст запроса стал читабельнее (а при использовании конструктора запросов намного увеличивается удобство чтения запроса).
После выполнения запроса в переменную МассивРезультатов у нас попадет 3 элемента. Первые два будут содержать число характеризующее количество записей помещенных во временные таблицы ДокТЧ и СписокТоваров, а третий будет содержать выборку с полями Номенклатура, Док_Количество и Рег_Количество.
В переменную РезультатЗапроса попадет только выборка.
Ну вот и все что касается пакетных запросов. Очень удобный механизм и с точки зрения написания запросов и с точки зрения чтения сложных запросов.
Хранилище конфигурации предназначено для коллективной разработки конфигурации. В хранилище сохраняется история разрабатываемой конфигурации, а также информация о том, когда и кто вносил изменения в конфигурацию. Разработка конфигурации с использованием хранилища может вестись неограниченным числом пользователей.
Принцип работы
Хранилище конфигурации представляет собой базу данных, в которой сохраняются все изменения конфигурации, сделанные в процессе её разработки. После подключения информационной базы к хранилищу из него в информационную базу загружается последняя версия конфигурации, и все объекты метаданных конфигурации становятся недоступными для редактирования.
Гранулой редактирования - объектами разработки - являются все основные объекты метаданных (такие как справочники, документы, регистры сведений), а также формы и макеты. Объекты разработки могут редактироваться независимо друг от друга разными пользователями. Реквизиты, табличные часть и т.д. не являются отдельными объектами с логической точки зрения, поэтому они не были включены в состав объектов разработки. Данные объекты метаданных редактируются в составе своих родительских объектов, являющихся объектами разработки.
Для получения возможности редактирования объекта необходимо произвести его захват в хранилище. При выполнении захвата из хранилища будет получена (в случае наличия) новая версия объекта разработки. После внесения изменений объект необходимо поместить в хранилище, после этого обновленная версия объекта становится доступной для других пользователей, участвующих в процессе разработки конфигурации. Если же изменения не должны быть помещены в хранилище, то предусмотрена процедура отмены захвата, при которой из хранилища получается старая версия объекта разработки. Таким образом, можно выделить четыре простейшие операции работы с хранилищем: захват объекта в хранилище;
помещение объекта в хранилище;
получение объекта из хранилища;
отмена захвата в хранилище.
Для параллельной разработки конфигурации в хранилище используется стратегия пессимистической блокировки: в то время, пока объект разработки редактируется одним пользователем, другие пользователи не имеют возможности его редактировать.
Стоит обратить внимание на тот факт, что при подключении информационной базы к хранилищу конфигурации происходит полная замена текущей редактируемой конфигурации конфигурацией хранилища . Это необходимо для обеспечения полного соответствия идентификаторов объектов метаданных. Если все же имеется информационная база, часть объектов метаданных конфигурации которой необходимо перенести в конфигурацию хранилища, то необходимо: выгрузить конфигурацию из информационной базы в файл,
подключить информационную базу к хранилищу конфигурации,
выполнить захват объектов, которые необходимо заместить,
произвести объединение с требуемой конфигурацией.
Важно понимать, что предметом разработки является конфигурация, а не отдельные объекты. Хранилище ведет историю развития конфигурации. При помещении объектов разработки в хранилище создается новая версия конфигурации, для которой записываются: дата создания версии, пользователь, создавший версию, а также списки объектов разработки, которые были добавлены, изменены, удалены в процессе получения данной версии конфигурации. История объектов разработки не ведется. Несмотря на то, что имеется возможность просмотра истории объекта разработки, отдельно загрузить из хранилища объект разработки какой-либо версии конфигурации невозможно, возможна лишь загрузка из хранилища версии конфигурации целиком. Однако все же имеется возможность получения объекта определенной версии конфигурации: необходимо захватить объект и выполнить объединение с версией конфигурации, в которой данный объект имеет требуемое состояние.
При создании новой версии конфигурации хранилища имеется возможность записать комментарий к этой версии. Рекомендуется комментировать версии конфигурации, для того чтобы впоследствии можно было понять, что именно было изменено в данной версии конфигурации. Для наиболее значимых версий (например: выпуск релиза) рекомендуется также устанавливать метку - строку, кратко описывающую версию конфигурации хранилища.
В процессе разработки конфигурации с использованием хранилища рекомендуется периодически получать актуальное состояние объектов разработки. Это позволяет избежать возможных трудностей при помещении объектов в хранилище (например при удалении объектов метаданных из конфигурации).
Средства работы с хранилищем конфигурации позволяют просматривать историю версий конфигурации хранилища, сохранять конфигурацию определенной версии в файл, сравнивать с другими версиями конфигурации данного хранилища или же сравнивать с другой конфигурацией из файла.
Если по каким-либо причинам хранилище конфигурации недоступно, то имеется возможность продолжать работу с объектами разработки, захваченными ранее в хранилище. Таким образом, можно вести разработку, не имея постоянной непосредственной связи с хранилищем конфигурации.
Режимы использования
Для работы с хранилищем конфигурации предусмотрено несколько способов: с подключением информационной базы к хранилищу;
без подключения информационной базы к хранилищу.
Данные режимы отличаются друг от друга как набором функциональности, предоставляемой платформой 1С:Предприятия, так и своим предназначением.
Работа с подключением информационной базы к хранилищу
Этот режим является основным режимом работы с хранилищем. Он используется для групповой разработки конфигурации несколькими пользователями.
Работа в данном режиме начинается с процедуры подключения информационной базы к хранилищу. К одному хранилищу может быть одновременно подключена одна информационная база от имени одного пользователя. Если пользователь, у которого уже имеется информационная база, подключенная к данному хранилищу, произведет попытку подключения другой информационной базы, то ему будет выдано соответствующее предупреждение. Если же подключение все же будет осуществлено, то прежняя информационная база уже не сможет работать с данным хранилищем конфигурации без предварительного отключения от него. Аутентификация в хранилище от имени пользователя, не подключавшего данную информационную базу к хранилищу, невозможна.
При подключении информационной базы к хранилищу в нем регистрируется строка соединения с информационной базой. Если при последующих соединениях с хранилищем данная строка будет изменена (по каким-либо причинам информационная база была перемещена на другой ресурс), то платформой будет выдано соответствующе предупреждение, и, в случае подтверждения соединения, строка соединения будет обновлена. Если соединение происходило копией информационной базы, то работа оригинала с данным хранилищем будет невозможна без предварительного отключения от него.
Работа без подключения информационной базы к хранилищу
Режим обеспечивает возможность просмотра и администрирования хранилища без подключения к нему, т.е. без замены редактируемой конфигурации конфигурацией хранилища. В данном режиме пользователь может получить конфигурацию определенной версии хранилища, посмотреть историю конфигурации или отдельных объектов разработки, произвести действия по редактированию прав пользователей или изменению их состава.
Работа в данном режиме начинается с открытия хранилища конфигурации, данная процедура заключается в аутентификации пользователя в хранилище, которая будет автоматически предложена при выполнении любого первого действия с хранилищем в данной сессии работы Конфигуратора. Для открытия другого хранилища в данной сессии Конфигуратора необходимо закрыть текущее хранилище конфигурации, выполнив соответствующий пункт меню.
Предполагается, что данный режим будет использоваться для подготовки дистрибутивов конфигураций на основе файлов выгрузки информационных баз. Данная процедура может выглядеть следующим образом:
Создать новую информационную базу.
Открыть хранилище конфигурации.
Из хранилища конфигурации загрузить конфигурацию нужной версии.
Произвести заполнение информационной базы необходимыми данными.
Произвести подготовку дистрибутива конфигурации.
В процессе модернизации конфигурации хранилища для выпуска новых дистрибутивов необходимо повторить процедуру, начиная с пункта 2, и, если новых данных вводить не требуется, сразу выполнить подготовку дистрибутива.
Контроль ссылочной целостности
Стандартные механизмы контроля ссылочной целостности конфигурации обеспечивают контроль на уровне объектов метаданных: нельзя, например, удалить из конфигурации справочник, если на него ссылается реквизит документа и т.д. На уровне интерфейсов, форм и макетов такой контроль не ведется.
Пример: удаление справочника Склады из демонстрационной конфигурации ":
происходит проверка имеющихся на этот объект ссылок в других объектах:
"Справочник.Склады" использован в: Документ.ПриходнаяНакладная.Реквизит.Склад.Тип
Документ.РасходнаяНакладная.Реквизит.Склад.Тип
РегистрНакопления.УчетНоменклатуры.Измерение.Склад.Тип
после удаления обнаруженных ссылок справочник Склады успешно удаляется из конфигурации, хотя ссылка не него по-прежнему имеется в интерфейсе Основной (кнопка Склады из подменю Справочники содержит действие "Склады: Открыть справочник") и формах документов ПриходнаяНакладная, РасходнаяНакладная (поля ввода, предназначенные для редактирования реквизитов Склад по-прежнему имеют тип СправочникСсылка.Склады).
При разработке конфигурации без использования хранилища этого вполне хватает. Однако для параллельной разработки конфигурации такой контроль ссылочной целостности недостаточен.
Хранилище конфигурации обеспечивает более строгий контроль ссылочной целостности конфигурации. Производится полный контроль ссылок между объектами метаданных как на уровне самих объектов, так и на уровне содержимого их форм и макетов, а также содержимого интерфейсов.
Следствием этого факта является необходимость получения из хранилища (помещения в хранилище) объектов, так или иначе связанных с объектом, над которым непосредственно производится действие. Однако хранилище конфигурации производит анализ ссылок объекта и требует получения (помещения) дополнительных объектов только в случае необходимости.
Анализ ссылок производится рекурсивно: сначала производится анализ объекта, с которым производится действие в хранилище; затем при обнаружении необходимости выполнения операции над дополнительными объектами аналогичный анализ производится для них, и так до тех пор, пока ссылки всех требуемых объектов не будут проанализированы.
Особенности конфигурирования
Разработка конфигурации в информационной базе, подключенной к хранилищу конфигурации, имеет некоторые особенности.
Как уже говорилось ранее, для получения возможности редактирования объекта необходимо произвести его захват в хранилище конфигурации. Если необходимо внести изменения в объект метаданных, не являющийся объектом разработки (реквизиты, табличные части), то необходимо произвести захват того объекта разработки, который содержит данные объекты метаданных.
Для добавления нового объекта метаданных или же для изменения порядка следования существующих объектов необходимо произвести захват родительского объекта разработки.
Удаление объектов конфигурации
Особое внимание стоит уделить процедуре удаления объектов метаданных из конфигурации. Для удаления объекта метаданных из конфигурации необходимо захватить в хранилище сам удаляемый объект, его родительский объект, а также все подчиненные объекты удаляемого. После чего появится возможность удалить объект из конфигурации.
Однако при помещении в хранилище, если на удаленный объект имеются ссылки в других объектах, средства работы с хранилищем потребуют помещение этих объектов в хранилище с очищенными ссылками на удаленный объект.
Рекомендуется перед удалением объекта из конфигурации производить поиск ссылок на данный объект. Произвести захват в хранилище всех обнаруженных объектов и вычистить из них все ссылки на удаляемый объект. После этого необходимо удалить все ссылки на удаляемый объект из форм, интерфейсов и макетов. После чего удалить объект из конфигурации и произвести попытку помещения изменений в хранилище. Если помещение в хранилище завершится неудачей из-за обнаружения ссылок на удаленный объект, то необходимо захватить указанные объекты и произвести повторную попытку помещения изменений в хранилище.
Пример: удаление справочника Склады из демонстрационной конфигурации:
Производим поиск ссылок на удаляемый объект:
"Справочник.Склады" использован в: Документ.ПриходнаяНакладная.Реквизит.Склад.Тип
Документ.РасходнаяНакладная.Реквизит.Склад.Тип
РегистрНакопления.УчетНоменклатуры.Измерение.Склад.Тип
Захватываем данные объекты и удаляем из них реквизиты, ссылающиеся на справочник Склады.
Захватываем интерфейс "Основной" и удаляем из него кнопку Склады из подменю Справочники с действием "Склады: Открыть справочник".
Захватываем корневой объект конфигурации и справочник Склады.
Удаляем справочник Склады из конфигурации.
Производим попытку помещения корневого объекта конфигурации в хранилище
Параметры командной строки для работы с хранилищем конфигурации
Параметры командной строки режима работы с хранилищем конфигурации
/ConfigurationRepositoryF <каталог хранилища> — указание имени каталога хранилища.
/ConfigurationRepositoryN <имя> — указание имени пользователя хранилища.
/ConfigurationRepositoryDumpCfg <имя cf файла> [-v <номер версии хранилища>] — сохранить конфигурацию из хранилища в файл (пакетный режим запуска).
-v <номер версии хранилища> v — номер версии, если номер версии не указан, или равен -1, будет сохранена последняя версия.
/ConfigurationRepositoryUpdateCfg [-v <номер версии хранилища>] [-revised] — обновить конфигурацию хранилища из хранилища (пакетный режим запуска).
-v<номер версии хранилища> — номер версии, если номер версии не указан, или равен -1, будет сохранена последняя версия, если конфигурация не подключена к хранилищу, то параметр игнорируется;
-revised — получать захваченные объекты, если потребуется. Если конфигурация не подключена к хранилищу, то параметр игнорируется;
-force — если при пакетном обновлении конфигурации из хранилища должны быть получены новые объекты конфигурации или удалиться существующие, указание этого параметра свидетельствует о подтверждении пользователем описанных выше операций. Если параметр не указан — действмия выполнены не будут.
/ConfigurationRepositoryUnbindCfg [-force] — отключение конфигурации от хранилища конфигурации (у пользователя должны быть административные права в данной информационной базе). Если пользователь аутентифицируется в хранилище (интерактивно или через параметры командной строки), то отключение конфигурации от хранилища также отражается в самом хранилище конфигурации (информация о подключении удаляется), если же пользователь не аутентифицировался в хранилище, то производится только локальное отключение конфигурации от хранилища.
В случае, если в конфигурации имеются захваченные объекты, которые были изменены относительно хранилища, то будет выдано соответствующее сообщение и отключения не выполнится.
–force — ключ для форсирования отключения от хранилища (пропуск диалога аутентификации, если не указаны параметры пользователя хранилища, игнорирование наличия захваченных и измененных объектов).
/ConfigurationRepositoryReport <имя файла> [-NBegin <номер версии>] [-NEnd <номер версии>] [-GroupByObject] [-GroupByComment] — построение отчета по истории хранилища. Если параметры группировки не указаны и режим совместимости указан "Не используется", то отчет формируется с группировкой по версиям. В режимах совместимости "Версия 8.1" и "Версия 8.2.13" отчет формируется с группировкой по объектам. Если конфигурация базы данных отличается от редактируемой по свойству совместимости, при обработке командной строки учитывается значение режима совместимости конфигурации базы данных.
<имя файла> — имя файла, в который выводится отчет;
NBegin — номер сохраненной версии, от которой начинается строиться отчет;
NEnd — номер сохраненной версии, по которую строится отчет;
GroupByObject — признак формирования отчета по версиям с группировкой по объектам;
GroupByComment — признак формирования отчета по версиям с группировкой по комментарию.
Примеры: для конфигурации, не присоединенной к текущему хранилищу:
для присоединенной к хранилищу конфигурации, информация для отчетов берется из текущего хранилища:
Передача команд 1С на выполнение через ссылки в письме. web-сервисы помогают интегрировать 1С с различными программами, делая её более гибкой. Статей в интеренете достаточно можно, но в основном там описывается выгрузка из 1С, обмен между двумя 1С или 1С и каким-то мощным программным продуктом написанным на C или других языках.
Для меня же была поставлена задача возможности управление 1С через браузер. Как пример: обрабатывать завершение задачи БП в 1С по ссылке в письме (примерно такого типа http://site.ru/?user=000000001&bp=000000555, т.е. отсюда видно, что пользователь 000000001 хочет закрыть задачу 000000555), т.е. пользователь со своего смартфона не имеющего доступа к 1С как таковому, должен получить возможность управлять ею извне. Собственно, более сложной задачей можно поставить написание собственных web-форм, более легких и компактных, с произвольным дизайном для управления 1С.
Задача с точки зрения написания кода 1С очень легкая. Основная сложность заключалась в освоении HTML и JavaScript для управления извне. Начальные знаний по этому вопросу я подчерпнул из статьи Примеры пользования web сервисов 1С из браузера.
Настройка 1С
Для возможности использовать 1С в вебе необходимо:
1. Установить модуль расширения веб-сервера;
Программирование 1С
Теперь можно приступить к конфигурированию.
1. Создадим Web-сервис Input:
1.1. Input имеет операцию InputData которая принимает два параметра: User и Command, и возвращает параметр типа "boolean (http://www.w3.org/2001/XMLSchema)". Текст функции InputData:
1.2. Устанавливаем для Input URI пространства имен = "http://infostart.ru". Здесь может быть любое уникальное имя, обычно это ссылка на сайт.
1.3. Устанавливаем для Input имя файла публикации = "input.1cws". Это имя web-сервиса к которому будем устанавливать соединение.
2. Для наглядности примера создадим справочник Данные, все параметры оставим по умолчанию.
3. Публикуем нашу конфигурацию и web-сервис: Администрирование -> Публикация на веб сервере...
На этом конфигурирование заканчивается, всё остальное сделает за нас 1С.
Разработка HTML страницы
Эта часть далась для меня тяжело, т.к. я ещё только делаю первые шаги в этой теме. Буду рад замачаниям и советам. А так, я постараюсь объяснить всё на пальцах тем, кто как и я знаком по большей части с 1С.
После установки ISS (я уже давал ссылку в начале статьи) на диске C появится каталог C:\inetpub\wwwroot, в этом каталоге располагается сайт. Для локальной машины (на которой установили ISS) он виден так http://localhost/, ну а для пользователей извне, как-то так http://infostart.ru (по правде там немного сложнее, но не суть, мы сейчас не про это). Заглавная страница сайта будет грузиться из файла index.htm каталога C:\inetpub\wwwroot
В платформе 1С:Предприятие 8.х реализовано два механизма обмена данными: универсальный механизм обмена данными и механизм распределенной информационной базы. Оба эти механизма базируются на одних тех же технологиях. Одной из этих технологий является служба регистрации изменений данных. Изменения данных могут регистрироваться в автоматическом режиме. Для этого необходимо при включении объекта метаданных в состав плана обмена разрешить автоматическую регистрацию: установить признак Авторегистрация в значение Разрешить.
Однако часто требуется регистрация не каждого изменения данных, или регистрация изменений смежных объектов, или зависящих от изменяемых данных. Это можно выполнить различными способами.
Регистрация изменений всех данных для указанного узла
Для регистрации изменений всех данных для конкретного узла плана обмена необходимо вызвать метод ЗарегистрироватьИзменения() менеджера планов обмена, передав ему в качестве параметра Данные значение Неопределено.
Пример. Регистрация изменения всех данных для узла Узел:
Регистрация изменений всех данных одного типа
Для регистрации изменений данных одного типа необходимо вызвать метод ЗарегистрироватьИзменения() менеджера планов обмена, передав ему в качестве параметра Данные объект описания метаданных, соответствующий данным.
Пример: регистрация изменения всех элементов справочника Номенклатура для узла Узел:
Регистрация изменений конкретных данных различных типов
Для регистрации конкретных данных различных типов необходимо вызвать метод ЗарегистрироватьИзменения() менеджера планов обмена, передав ему в качестве параметра Данные либо сами данные, либо ссылку на них.
Регистрация изменений данных объектных типов
К объектным типам относятся справочники, документы, планы счетов, планы видов характеристик, планы расчета, бизнес-процессы, задачи. Для их регистрации необходимо вызвать метод ЗарегистрироватьИзменения() менеджера планов обмена, передав ему в качестве параметра Данные либо сам объект, либо ссылку на него.
Регистрация изменений наборов записей
Регистрация изменений наборов записей зависит от типа регистра, которому принадлежит набор записей. В общем случае в наборе записей должен быть установлен отбор, определяющий содержимое набора записей с точки зрения логики конфигурации. Чтение данных набора необязательно.
Регистрация изменений наборов записей регистров, подчиненных регистратору
К таким регистрам относятся регистры накопления, регистры бухгалтерии, регистры расчета и регистры сведений со свойством РежимЗаписи, установленным в значение ПодчинениеРегистратору. Для регистрации изменений наборов записей указанных регистров необходимо вызвать метод ЗарегистрироватьИзменения() менеджера планов обмена, передав ему в качестве параметра Данные набор записей с установленным отбором, в котором в элемент отбора Регистратор установлено значение регистратора данного набора записей. При этом чтение данных набора записей перед его регистрацией не обязательно.
Регистрация изменений наборов записей независимых регистров
К таким регистрам относятся регистры сведений со свойством РежимЗаписи, установленным в значение Независимый. Для регистрации изменений наборов записей данного регистра необходимо вызвать метод ЗарегистрироватьИзменения() менеджера планов обмена, передав ему в качестве параметра Данные набор записей. Состав элементов отбора, при этом, должен строго соответствовать основному отбору регистра. Выбирать поля, входящие в основной отбор регистра необходимо в соответствии с логикой работы конфигурации (см. Подготовка конфигурации к работе в распределенной информационной базе).
Для регистрации данных регистра сведений, отбираемых по некоторому критерию, необходимо:
выбрать уникальные значения измерений регистра, входящих в основной отбор (если регистр сведений является периодическим и Период включен в основной отбор, то Период также должен участвовать в отборе)
выполнить регистрацию наборов записей с установленными значениями отбора, соответствующими каждой выбранной комбинации значений измерений (входящих в основной отбор).
Пример. Регистрация всех данных регистра сведений КомплектующиеНоменклатуры, имеющего измерения Номенклатура и ХарактеристикаНоменклатуры (входящие в основной отбор), а также измерения Комплектующая и ХарактеристикаКомплектующей (не входящие в основной отбор) и являющегося непериодическим:
Для понимания особенностей записи и проведения документа в форме следует, прежде всего, разделять особенности записи самого объекта (ДокументОбъект) и особенности работы расширения формы. Расширение формы документа действует, если основной реквизит формы имеет тип ДокументОбъект. Оно обеспечивает специфическую функциональность формы при редактировании и записи документа. Задача расширения заключается в реализации удобного для пользователя поведения формы. Но собственно запись и проведение документа выполняет, разумеется, объект, являющийся реквизитом формы. Расширение документа обрабатывает различные команды пользователя, выполняет предварительные проверки и другие сервисные действия, а затем вызывает запись объекта. Запись объекта выполняется так же, как и если бы она вызывалась средствами встроенного языка. То есть с точки зрения объекта запись в форме и запись средствами языка ничем не различаются. Таким образом, расширение обеспечивает некоторую сервисную функциональность, обращаясь в конечном итоге к функциональности объекта. Следует учитывать, что расширение формы действует, только если используются механизмы формы и не действует, если выполняется обращение непосредственно к объекту. Например, если вызвать метод Записать() у объекта ДокументОбъект, то никакие действия расширения формы не будут выполняться. Чтобы они выполнялись нужно вызывать метод ЗаписатьВФорме().
Далее мы рассмотрим те сервисные действия, которые обеспечивает расширение формы документа. В данном разделе, мы опишем только те действия, которые специфичны именно для расширения формы документа и не будем касаться общих действий, которые поддерживаются расширениями всех объектов.
Установка даты документа
При открытии формы нового документа, если дата документа не установлена (равна значению типа Дата по умолчанию), то документу устанавливается рабочая дата. Следует заметить, что используется именно рабочая дата, а не текущая (если не установлено использование текущей даты в качестве рабочей). Это дает возможность пользователю настроить рабочую дату так, чтобы новые документы вводились определенной датой. При этом в качестве даты устанавливается начало дня (дата без времени), даже если в качестве рабочей даты выступает текущая дата. Но если свойство АвтоВремя имеет значение НеИспользовать, и рабочая дата равна текущей, то устанавливается текущая дата, вместе со временем. Таким образом, для варианта АвтоВремя = НеИспользовать при открытии берется рабочая дата (если она отличается от текущей) или текущая дата вместе со временем, а для остальных вариантов установка времени откладывается на момент записи документа.
При записи нового документа в форме если свойство АвтоВремя имеет значение отличное от НеИспользовать, и не используется оперативное проведение, и время документа пустое (0:00:00), то выполняется автоматическая установка времени на основании значения свойства АвтоВремя. Действие расширения формы в этом случае аналогично вызову метода УстановитьВремя() с вариантом выбранном в свойстве АвтоВремя и с использованием журналов документа.
Расширение формы так же предоставляет команды для установки времени документа в начало дня, конец дня, перед предыдущим и за последующим документом.
Установка режима записи
При нажатии кнопки "ОК", если для документа в метаданных разрешено проведение, документ записывается в режиме проведения.
Кроме того, расширение формы предоставляет две отдельные команды для записи с проведением и записи с отменой проведения.
При любой записи документа в форме, если установлено свойство расширения формы ПриЗаписиПерепроводить и документ проведен, то выполняется запись в режиме проведения. Это позволяет исключить ситуацию, когда пользователь изменит документ, а движения документа не будут обновлены.
Установка режима оперативного проведения
При записи документа в форме, расширение формы выполняет установку режима проведения (оперативное или неоперативное проведение). Установка выполняется по следующему алгоритму.
Вначале если свойство ИспользоватьРежимПроведения имеет значение Авто выполняется первичный подбор режима проведения из вариантов Оперативный, Неоперативный и Запрашивать.
Если у пользователя нет права на неоперативное проведение – используется оперативное проведение.
Если документ не проведен – используется оперативное проведение.
Если дата документа равна текущей, а время меньше или равно текущему, то используется режим Запрашивать. Здесь и далее в этой статье сравнение даты имеется в виду без учета времени, а сравнение времени описывается отдельно.
Если дата документа меньше текущей, то используется неоперативное проведение.
Если дата документа равна текущей и время больше текущего – используется оперативное проведение.
Дальнейшие действия системы определяются уже исходя из трех вариантов (Оперативный, Неоперативный и Запрашивать) установленных непосредственно в свойстве ИспользоватьРежимПроведения или на основании описанного алгоритма для варианта Авто.
Если дата документа меньше текущей, используется оперативный режим и у пользователя есть права на неоперативное проведение, то пользователю предлагается использовать неоперативный режим. Если пользователь отказывается, то запись документа отменяется.
Если дата документа меньше текущей, используется оперативный режим и у пользователя нет права на неоперативное проведение, то запись документа отменяется.
Если дата документа меньше текущей и используется режим Запрашивать, то в зависимости от наличия прав на неоперативное проведение или выбирается неоперативный режим (без запроса пользователя), или запись документа отменяется.
Если дата документа больше текущей и используется оперативный режим, то запись документа отменяется. Штатное поведение расширения формы не разрешает проведение документа завтрашней датой, даже если у пользователя есть права на неоперативное проведение. Это объясняется тем, что после появления документов проведенных завтрашней датой текущие остатки регистров используемых проводимыми оперативно документами перестают соответствовать реальным остаткам и механизм оперативного проведения для всех пользователей перестает работать адекватно.
Далее если используется режим Запрашивать, то пользователю выдается диалог с выбором режима проведения.
Полученный таким образом режим проведения (Оперативный или Неоперативный) используется при выполнении записи документа.
Проверка прав
При открытии формы документа, если документ проведен, а у пользователя нет права "Интерактивное изменение проведенных", то расширение переводит форму в режим ТолькоПросмотр.
При записи документа в форме выполняется проверка прав на интерактивное проведение и интерактивную отмену проведения в соответствии с текущим режимом записи.
Считывание движений
При открытии формы документа, если есть табличные поля, связанные с движениями (наборами записей) объекта редактируемого в форме, то эти движения считываются из базы данных и соответственно отображаются в табличных полях.
- Использовать привилегированный модуль
Размещение программного кода, который должен выполняться БЕЗ КОНТРОЛЯ ОГРАНИЧЕНИЙ, в общий модуль с установкой у модуля флага ПРИВИЛЕГИРОВАННЫЙ.
- Использовать привилегированный режим исполнения программного кода
Аналогичный режиму работы кода привилегированных модулей. Режим можно включить/выключить средствами встроенного языка:
Параметр <Включить> (обязательный)
Тип: Булево. Определяет, будет ли включен привилегированный режим:
Истина - включить режим;
Ложь - выключить режим.
Функция:
позволяет определить, включен привилегированный режим, или нет.
Использование привилегированного режима позволяет, во-первых, ускорить работу, так как не будут накладываться ограничения на доступ к данным, а во-вторых, позволяет выполнять операции с данными от лица пользователей, которым эти данные недоступны.
Привилегированный режим рекомендуется использовать тогда, когда с логической точки зрения нужно отключить проверку прав, или когда можно отключить проверку прав, чтобы ускорить работу. Допустимо использовать привилегированный режим тогда, когда работа с данными от лица некоторого пользователя не нарушает установленные для этого пользователя права доступа.
Один из наиболее актуальных сегодня вопросов создания, поддержки и развития информационных систем организаций — задача интеграции их отдельных подсистем и компонентов. Платформа «1С:Предприятие 8» обладает значительным спектром функций и механизмов взаимодействия с внешними программами и оборудованием на основе общепризнанных открытых стандартов и протоколов.
Довольно большую группу среди них составляют средства обмена данными, которые мы и рассмотрим в этой статье.
Для начала нужно сказать о довольно простых, но в то же время эффективных и часто используемых на практике возможностях.
* Работа с текстовыми документами. Встроенный язык платформы позволяет разработчику создавать, динамически формировать и записывать текстовые документы, в том числе на основе готовых шаблонов. Обмен данными с использованием текстовых документов может быть одним из самых простых способов взаимодействия с другими информационными системами.
* Последовательное чтение текстовых файлов. Дело в том, что такие файлы могут быть очень большого объема, поэтому существуют специальные программные объекты, позволяющие читать и записывать их быстро (с использованием оптимизированных алгоритмов).
* XML. Платформа позволяет организовывать интеграцию с прикладными системами с использованием XML-документов, являющихся на сегодня общепринятым средством представления данных. Поддержка XML выполнена на уровне встроенного языка.
* DBF-файлы. Механизм работы с базами данных формата DBF предназначен для обеспечения возможности манипулирования ими непосредственно из языка системы через объект xBase. Можно как работать с существующими базами данных, так и создавать новые базы данных произвольной конфигурации.
* Работа с файловой системой. Доступ к функциям работы с файловой системой реализован на уровне встроенного языка. Эта возможность может быть использована при организации взаимодействия с другими информационными системами через общие каталоги.
Базовые средства обмена данными
Платформа также содержит набор специализированных средств обмена данными для создания распределенных информационных систем на основе программ «1С:Предприятия» и решений других поставщиков.
Они реализуются благодаря использованию ряда средств платформы, которые разработчик может применять как по отдельности, так и в различных комбинациях, в зависимости от конкретной решаемой задачи. Такой подход позволяет обеспечить гибкость механизмов обмена и их настраиваемость на решение как можно большего круга задач. В состав средств платформы, используемых для построения схем обмена данными, входят:
* объекты «обмена»,
* средства сериализации,
* средства документов.
При помощи этих средств могут быть реализованы две основные технологии собственно обмена данными:
* универсальный механизм обмена данными;
* механизм управления распределенными информационными базами.
Планы обмена содержат информацию об узлах, которые могут участвовать в обмене данными, определяют состав информации и указывают, следует ли задействовать механизм распределенной информационной базы при обмене. В качестве узлов могут выступать информационные базы «1С:Предприятия» или других систем. Для каждого узла можно задать код, наименование и необходимый перечень реквизитов, описывающих узел. Узел может иметь также несколько подчиненных табличных частей для хранения информации, связанной с этим узлом, несколько форм для отображения информации, содержащейся в плане обмена, и т. д.. В плане обмена указывается также состав данных, которыми предполагается вести обмен. Для каждого из объектов прикладного решения, которые могут участвовать в обмене, можно задать режим автоматической регистрации их изменений. Программно разработчик всегда может выполнять регистрацию на уровне встроенного языка.
В одном прикладном решении может существовать несколько планов обмена, каждый из которых может описывать свой порядок обмена данными. Например, если выполняется обмен данными с удаленными складами и удаленными офисами, то, скорее всего, будет существовать два плана обмена (один — для обмена со складами, другой — для офисов), поскольку состав данных, которыми производится обмен со складами, будет значительно уже, чем состав данных, предназначенных для обмена с офисами.
С помощью объектов «план обмена» реализованы два важных внутренних механизма платформы.
* Служба регистрации изменений. Позволяет получать информацию о том, какие элементы данных были изменены и в какой узел обмена их необходимо передать. Для каждого элемента данных, указанного в плане обмена, ведется своя таблица регистрации изменений. Они имеют разную структуру в зависимости от того, для каких элементов данных регистрируются изменения, но все-таки структуры таблиц подобны. Каждая запись указывает на некоторый элемент данных, некоторый узел и содержит номер сообщения, в котором это изменение передано в первый раз.
* Инфраструктура сообщений. Перенос данных между узлами распределенной информационной базы выполняется с помощью сообщений, которые поддерживаются инфраструктурой сообщений. Каждое сообщение относится к определенному плану обмена, имеет определенный узел-отправитель, узел-получатель и целочисленный номер.
XML-сериализация — это процесс преобразования данных «1С:Предприятия» в последовательность данных формата XML и наоборот.
Средства чтения и записи XML-документов позволяют работать с данными формата XML на «базовом» уровне, без привязки к объектам «1С:Предприятия». В частности, они дают возможность открывать XML-документы для чтения, читать из них данные, создавать новые XML-документы и записывать в них данные. Все это активно используется при реализации различных схем обмена данными.
Универсальный механизм обмена данными
Универсальный механизм обмена данными предназначен для создания территориально распределенных систем на основе как «1С:Предприятия», так и решений других поставщиков. Однако этот механизм позволяет переносить только данные, перенос конфигурации и административной информации «1С:Предприятия» при его помощи невозможен. В качестве формата обмена используются XML-документы, при этом при обмене данными между информационными базами «1С:Предприятия» не накладывается ограничений на идентичность конфигурации и структуры конкретных объектов. В то же время в одной конфигурации может быть создано несколько независимых схем обмена с различными информационными системами. Важно также и то, что при организации схемы обмена не накладывается ограничений на структуру распределенной системы. Может быть организована как классическая структура типа «звезда», так и более сложные многоуровневые структуры типа «снежинка» и др.
Разработчику прикладного решения предоставляется возможность гибкого управления составом обмена с точки зрения как структуры передаваемых данных, так и состава передаваемой информации в конкретные узлы обмена. Объект базы данных первоначально создается в одном из узлов обмена, при этом состав передаваемой информации может регулироваться в зависимости от содержимого данных и не зависит от места первоначального ввода информациии.
Механизм управления распределенными информационными базами
Механизм управления распределенными информационными базами (УРИБ) играет ключевую роль в создании территориально распределенных систем на основе идентичных конфигураций «1С:Предприятия 8» (распределенная система должна иметь древовидную структуру, в которой существует корневой узел и определено отношение «главный—подчиненный» для каждой пары связанных узлов). Данная технология обеспечивает регистрацию изменений в базах данных, инфраструктуру сообщений и обмен информацией в формате XML. Централизованное управление конфигурацией системы осуществляется с помощью визуальных средств или программным образом. С ее помощью выполняется не только обмен данными, но и перенос программной конфигурации.
УРИБ реализует следующие основные возможности:
* интерактивное создание распределенной системы и выполнение обмена данными без дополнительного программирования;
* обеспечение идентичности конфигураций информационных баз, входящих в состав распределенной системы;
* подключение новых и отключение существующих узлов;
* создание начального образа информационной базы для нового узла;
* различные способы разрешения коллизий при одновременном изменении данных в разных узлах распределенной системы;
* в рамках одной распределенной информационной базы может быть создано несколько схем обмена;
* распределенная информационная база может содержать схемы обмена с другими информационными системами, в том числе с информационными базами «1С:Предприятия», не являющимися распределенными информационными базами;
* задание условий на передачу и прием изменений на уровне отдельных элементов данных;
* восстановление обмена данными в таких случаях, как восстановление информационных баз из резервных копий и т. д.;
* сжатие сообщений обмена в формате .ZIP и автоматическую распаковку сообщений обмена при приеме.
Различные способы управления обменом данными
Отличительная особенность механизма УРИБ заключается в том, что во всех узлах должны быть одинаковые конфигурации и между двумя связанными узлами должны быть установлены отношения главный—подчиненный. Благодаря этому процесс обмена можно формализовать и создавать распределенные информационные базы даже без программирования, так как система «знает», как обмениваться информацией. В отличие от этого, при использовании универсального механизма обмена данными в узлах может быть что угодно и взаимодействовать они могут как угодно, поэтому обязательно нужно писать код, описывающий правила такого взаимодействия. Таким образом, механизм УРИБ — это быстро и просто, но по определенным правилам, а универсальный механизм обмена данными — это «как угодно» и поэтому сложнее и требует написания всего кода вручную.
В целом же прикладное решение может содержать произвольное количество планов обмена как с использованием механизма УРИБ, так и без его использования. Например, одна и та же информационная база может входить в состав различных распределенных систем. Например, по одному плану обмена (с использованием УРИБ) она будет «общаться» с филиалами, а по другому плану обмена (с применением универсального механизма обмена данными) она может работать с корпоративной информационной системой (не «1С:Предприятие»), поставляя туда данные о работе филиалов для создания консолидированной отчетности по всему холдингу в целом.
Таким образом, программные средства и механизмы «1С:Предприятия» позволяют создавать различные по структуре однородные и неоднородные распределенные информационные системы.
Пожалуй, начнем сразу с практического примера.
В справочник Контрагенты нам необходимо заносить информацию о поставщиках, покупателях, банках, налоговых органах, различных фондах и пр. Для каждого вида контрагента нас интересует разная информация.
Создадим функцию, возвращающую список «важных» реквизитов в зависимости от вида контрагента:
Где же ее правильнее разместить?
Напрашивается вариант - в процедуре Модуля объекта «ПередЗаписью()». Тем самым мы на этапе записи будем контролировать правильность заполнения нужных нам реквизитов. С точки зрения создания, изменения элемента справочника, нас все устраивает. Но если нам необходимо, чтобы некоторые менеджеры заносились контрагентов в ИБ без контроля, а спустя какое-то время мы будем выполнять проверку на корректность заполнения данных в справочнике. Тогда нужно будет написать обработку. И в этой обработке, перебирая элементы, проверять заполнение реквизитов. Т.о. эту функцию придется разместить в коде обработки. А это получается дублирование кода, со всеми вытекающими проблемами. Можно получать объект каждого элемента, обращаться к функции, расположенной в его Модуле объекта. Но это будет дополнительные обращения к БД, тогда как в обработке нам достаточно только ссылок.
Можно выйти из этой ситуации создав Общий модуль «РаботаСКонтрагентами» и разместить в нем функцию возвращающую список реквизитов для проверки. В этом случае будем обращаться так «РаботаСКонтрагентами.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».
Но! На платформе 8.2 как раз для решения подобной задачи и был создан Модуль менежера. Там и разместим нашу функцию. А обращаться мы будем: «Справочники.Контрагенты.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».
Т.о. на ряду с предопределенными методами, мы можем самостоятельно разработать свои процедуры и обращаться к ним как методам Менеджера объекта, через точку. У нас отпадает необходимость создавать «тематические» внешние модули такие как «Работа с Контрагентами», «Процедуры Номенклатуры»...
Обратимся теперь к теории, чтобы «разложить все по полочкам».
Руководство разработчика дает нам следующее описание: «Модуль менеджера существует у всех прикладных объектов и предназначен для управления этим объектом как объектом конфигурации. Модуль менеджера позволяет расширить функциональность менеджеров за счет введения процедур и функций на встроенном языке. Фактически это позволяет описать методы для объекта конфигурации, которые относятся не к конкретному экземпляру объекта базы данных, а к самому объекту конфигурации». Именно это мы и разобрали в нашем практическом примере.
Отобразим иерархию классов прикладных объектов на примере Справочников:
Т.е. мы видим, что появление «Модуля менеджера объекта» логично расширяет свойства класса СправочникМенеджер, так же как экспортные процедуры «Модуля объекта» расширяют методы класса СправочникОбъект. Нужно ли было создавать «Модуль прикладного объекта Справочники (Документы, Перечисления)». Наверное нет. Достаточно трудно придумать какие-либо задачи для единой обработки всех видов справочников.
Кроме возможности расширения методов класса, в модуле менеджера существует предопределенная процедура События . Она возникает на сервере перед стандартным формированием списка при вводе по строке, автоподборе текста и быстром выборе, а также при выполнении метода «ПолучитьДанныеВыбора()».
Так же хочу обратить внимание. При использовании конструктора печати прикладного объекта, платформа расположит процедуру формирования табличного документа непосредственно в Модуле менеджера. И это логично. Теперь, чтобы получить табличный документ элемента справочника нет необходимости получать объект. Достаточно кода: .
Пакетные запросы логично дополняют функционал временных таблиц и дают больше возможностей при работе с запросами.
В пакетном запросе фактически можно описать несколько запросов, как связанных между собой использованием временных таблиц, так и не связанных (можно, но не понятно зачем?). В итоге можно выполнить последовательно все запросы и принять в результате либо массив с результатами исполнения каждого запроса, либо результат последнего. Для получения массива с результатами запроса применяют метод ВыполнитьПакет() объекта запрос, а для получения результата последнего запроса ВыполнитьЗапрос().
В тексте запроса, запросы пакета разделяются символом «;» (точка с запятой). Область имен виртуальных таблиц у одного пакетного запроса одна. Использование менеджера временных таблиц не требуется, но возможно если вы хотите передать временные таблицы из одного пакетного запроса в другой.
Фактически я убрал определение объекта запрос и использование менеджера временных таблиц, объединил тексты запросов (обратите внимание на разделитель «;» между текстами). В результате текст запроса стал читабельнее (а при использовании конструктора запросов намного увеличивается удобство чтения запроса).
После выполнения запроса в переменную МассивРезультатов у нас попадет 3 элемента. Первые два будут содержать число характеризующее количество записей помещенных во временные таблицы ДокТЧ и СписокТоваров, а третий будет содержать выборку с полями Номенклатура, Док_Количество и Рег_Количество.
В переменную РезультатЗапроса попадет только выборка.
Ну вот и все что касается пакетных запросов. Очень удобный механизм и с точки зрения написания запросов и с точки зрения чтения сложных запросов.
Механизм распределенных информационных баз предназначен для создания территориально распределенных систем на основе идентичных конфигураций 1С:Предприятия 8. Этот механизм позволяет переносить как данные 1С: Предприятия, так и изменения конфигурации информационной базы.
В тех случаях, когда предприятие представляет собой территориально распределенную структуру, зачастую сохраняется потребность в ведении единой системы учета. То есть необходимо иметь возможность работать в едином пространстве документов, получать отчеты, отражающие состояние дел как в территориально удаленных подразделениях предприятия, так и на предприятии в целом и т.п. При этом не всегда имеется возможность организовать работу всех подразделений с единой информационной базой в режиме он-лайн.
Для решения подобных задач и предназначен встроенный механизм. Распределенная система в этом случае должна иметь древовидную структуру, в которой существует корневой узел и определено отношение "главный - подчиненный" для каждой пары связанных узлов. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.
Обмен измененных объектов данных между каждым связанным узлом выполняется в формате ХML файлов. Перенос данных непосредственно между периферийными ИБ невозможен. Поэтому изменения данных, произведенные в одном из периферийных узлов распределенной ИБ попадают в другие периферийные узлы только через центральную ИБ.
В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.
Внесение изменений в конфигурацию возможно только в одном (корневом) узле распределенной системы. Изменения конфигурации передаются от главного узла к подчиненным.
Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.
Для того, чтобы документы, элементы справочников и другие объекты, созданные в разных узлах распределенной ИБ можно было различать, если это необходимо, в настройках программы можно указать префикс узла распределенной базы. В этом случае в при создании нового объекта (к примеру документа) будет автоматически добавляться указанный префикс.
В основе механизма распределенных информационных баз лежат универсальные механизмы обмена данными, такие как служба регистрации изменений, инфраструктура сообщений, XML-сериализация и чтение/запись XML-документов. Однако механизм распределенных информационных баз содержит ряд специфических возможностей, недоступных через универсальные механизмы обмена данными.
К таким возможностям относится интерактивное создание начального образа информационной базы, а также интерактивное чтение и запись изменений, которые могут быть выполнены сразу же, после указания того, что данный план обмена будет использовать механизм распределенных информационных баз. Таким образом, распределенная информационная база может быть создана без какого-либо дополнительного программирования, исключительно средствами визуального конструирования. При этом обмен в распределенной информационной базе будет осуществляться на основе некоторых алгоритмов, изначально заложенных в платформе.
Все действия, выполняемые при интерактивном обмене, могут быть продублированы программно, и кроме этого разработчик имеет возможность программно управлять принятием и отправкой изменений, а также выполнять реструктуризацию распределенной информационной базы, добавляя новые и удаляя существующие узлы.
Служба регистрации изменений
Суть регистрации изменений состоит в том, чтобы иметь перечень измененных элементов данных которые должны быть переданы в очередном сообщении тому или иному узлу, с которым производится обмен данными. При каждом изменении данных регистрируется, что имеются изменения, которые предстоит передать во все узлы, с которыми поддерживается обмен этими данными. При получении подтверждения приема сообщения, в котором были отправлены изменения, записи регистрации изменений должны быть удалены.
Состав данных, которыми осуществляется обмен, описывается в Плане обмена и представляет собой перечень элементов данных.
Для каждого элемента данных, указанного в плане обмена, ведется своя таблица регистрации изменений. Таблицы имеют разную структуру, в зависимости от того, для каких элементов данных регистрируются изменения, но все-таки структуры таблиц подобны. Каждая запись указывает на некоторый элемент данных, некоторый узел и содержит номер сообщения, в котором это изменение передано в первый раз.
При описании состава данных в плане обмена, для каждого элемента данных есть возможность указать признак Авторегистрации. Авторегистрацию можно «Разрешить» или «Запретить». Если авторегистрация разрешена, то при изменении данных регистрация изменений будет выполнена автоматически. Если запрещена, то регистрацию изменения можно выполнить «вручную», средствами встроенного языка.
Инфраструктура сообщений
С точки зрения плана обмена, между узлами происходит обмен сообщениями. Каждое сообщение содержит изменения данных, изменения конфигурации (если это распределенная информационная база) и ряд служебной информации. Каждое сообщение точно ассоциировано с планом обмена, имеет уникальный номер и имеет одного отправителя и одного получателя.
Сообщение оформляется как документ XML, имеющий определенную структуру. Инфраструктура сообщений позволяет формировать нужную структуру сообщения, и контролировать ее корректность. В частности, инфраструктура сообщений поддерживает нумерацию сообщений, и позволяет получать подтверждения от узла-получателя о приеме сообщений. Такое подтверждение содержится в каждом сообщении, приходящем от узла-получателя в виде номера последнего принятого сообщения.
Коллизии
При работе в реальных распределенных ИБ один и тот же объект может изменяться одновременно в различных узлах распределенной ИБ. И при переносе измененных объектов из одной ИБ в другую может случиться так, что в какую-либо ИБ будет загружаться объект, зарегистрированный в самой этой ИБ как измененный. Такая ситуация носит название коллизии.
Приведем описание действий системы в наиболее типовых вариантах коллизий: Один и тот же объект изменен более чем в одной ИБ.
Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются. Объект, измененный в одной ИБ, удален в другой.
В данном случае принцип заключается в том, что изменение всегда "главнее" удаления. В случае, если на центральную ИБ прибывает файл переноса, в котором содержится информация, что некоторый объект удален на периферийной ИБ, то в центральной ИБ объект не удаляется, а в записи таблицы регистрации изменений данный объект помечается как измененный. То есть при очередном обмене объект будет восстановлен в той ИБ, в которой он был удален, причем само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ. Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.
При загрузке изменений, если загружается информация об удалении объектов, автоматически включается механизм контроля ссылочной целостности и выполняется проверка наличия ссылок в данной ИБ на объекты, которые переданы как удаленные.
В случае обнаружения коллизии такого рода, вне зависимости от того на какой из ИБ она была обнаружена, выполняется следующее: удаление не выполняется, а в таблицу регистрации изменений заносится запись о том, что объект должен быть перенесен в адрес той ИБ, из которой была прислана информация о его удалении.
При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Таким образом на сегодняшний день платформа 1С:Предприятие предоставляет очень удобный механизм, использование которого относительно просто и не требуется никаких навыков в программировании, а благодаря механизму автоматического обмена от пользователя даже не требуется думать об актуальности его распределенной информационной базы.
В процессе работы пользователей, зачастую возникает необходимость создать задачу другому пользователю ИБ и проконтролировать ее выполнение.
К примеру, существует следующая задача:
Автоматизируемая компания занимается торговлей оборудованием. Специфика отгрузки оборудования заключается в том, что в основном она сопровождается оказанием услуг по монтажу закупленного оборудования. Исходя из этого, при оформлении заказа покупателя необходимо кроме ответственного за данный заказ указывать ответственного сотрудника по монтажу (в случае если это услуга не предусмотрена, реквизит не виден).
Если услуга по монтажу оборудования предусмотрена, то автоматически должно сформироваться два напоминания (события):
- Для ответственного менеджера на дату и время напоминания
- Для сотрудника ответственного за монтаж за сутки до напоминания ответственному менеджеру.
Когда срабатывает напоминание у ответственного менеджера, он должен видеть отработано ли напоминание сотрудника по монтажу оборудования.
Сформировать отчет, показывающий состояние согласования (когда сотрудник, ответственный за монтаж отработал напоминание) по незакрытым заказам покупателей (в случае оказание услуги по монтажу).
Решим ее следующим способом:
Создаем три реквизита документа Заказ покупателя: М_Монтаж (булево), М_Монтажник (Справочник пользователи) и М_ДатаМонтажа. Размещаем их на форме. Для того что бы сами реквизиты и их надписи были не видимы добавим процедуру:
При открытии формы документа тоже надо проверять можно ли отображать на форме новые реквизиты. Процедура УстановитьВидимость() вызывается из процедуры ПриОткрытии(). Именно здесь продублируем код процедуры М_МонтажПриИзменении(Элемент). Существуют, конечно, варианты. Например, можно управление видимостью организовать только в процедуре УстановитьВидимость() а в МонтажПриИзменении() обращаться к ней, или в процедуре УстановитьВидимость() вызывать МонтажПриИзменении(), однако, в первом варианте при каждом изменении значения реквизита «М_Монтаж» будет происходить установка видимости всех реквизитов в форме, что негативно скажется на производительности. Второй вариант не совсем корректен с точки зрения логики расположения программного кода, по этому сделаем наш код слегка избыточным, но зато логичным и не замедляющим работу программы.
При проведении документа следует создавать Задачу пользователя с взведенным флагом «Напоминание» и установленной датой напоминания. Лучше всего располагать создание задач после проверки на корректность заполнения всех полей документов (ведь документ может не провестись, а задачи создадутся)
Создавать задачи лучше с помощью немного доработанной процедуры РаботаСДиалогами.ПроверитьЗадачиПоОбъекту(Ссылка);
Во-первых, она проверит, есть ли введенные на основании этого документа задачи, и если обнаружит их, выдаст диалоговое окно пользователю с предложением не создавать новые. Этим мы исключим вероятность создания большого числа напоминаний при перепроведении документа. В самой функции ПроверитьЗадачиПоОбъекту() напишем:
Обратите внимание на реквизит «Инициатор» двух создаваемых нами задач. В форме списка задач существует возможность переключаться в режим просмотра заданий выданных текущим пользователем. Именно с помощью такого определения инициатора выполняется условие задачи: «В окошке напоминания менеджера должно быть видно, отработано ли событие монтажником»
Отчет в задании совсем не сложный, правда, могут возникнуть сомнения какой заказ считать закрытым. Как известно, заказ покупателя делает два движения. Одно по регистру «Заказы покупателя» где в разрезе номенклатуры, ведется учет по отгруженным товарам, второе по регистру «Расчеты с контрагентами» и здесь контролируется оплата по заказу. Думаю, что закрытым можно считать заказ, которого нет в остатках ни по одному, ни по второму регистру. Соединив их полным соединением, а так же присоединив таблицу Задач пользователя, получим отчет по незакрытым заказам пользователя. Автор: Максим Нечистяк
При работе с запросами нередко возникает ситуация, когда результат запроса необходимо упорядочить по представлению некоторого ссылочного поля. Например, необходимо упорядочить список номенклатуры по представлению. Заметим, что упорядочивание непосредственно по полю Представление приведет к не вполне ожидаемому результату - результат будет упорядочен в порядке возрастания ссылок объектов. Данный эффект проявляется из-за того, что поле Представление является виртуальным и на уровне базы данных состоит из нескольких полей, из которых уже в момент получения значения поля получается строка - представление. При упорядочивании же по этому полю произойдет последовательное упорядочивание по реальным полям, из которого оно состоит, в результате чего упорядочивание произойдет не по строковому представлению, а по внутренней ссылке поля.
Пример неправильного упорядочивания:
На самом деле, упорядочивание по представлению является довольно сомнительной операцией с точки зрения полезности результата. Для примера достаточно посмотреть на представления документов - эти строки содержат в себе даты, а упорядочивание дат как строк не даст осмысленного результата. Для того чтобы обеспечить упорядочивание, которое будет отвечать ожиданиям пользователей, следует использовать упорядочивание непосредственно по ссылочному полю и дополнительно указать в запросе ключевое слово АВТОУПОРЯДОЧИВАНИЕ. В таком случае запрос получит для каждого ссылочного поля реальные поля, по которым его необходимо упорядочить (для документа это будет дата и номер, для справочника - основное представление) и произведет упорядочивание по ним.
Расчетчик завела сотрудника со сроками договора с 01.01.09 по 15.06.09
Система попросила уволить данного сотрудника 16.06.09!
Расчетчик ввела новый док прием на работу в организацию 07.07.09 (продлили договор) при этом ввела нового сотрудника и новое физ лицо.
В результате в начисление з.п. за июнь при заполнении попадают оба этих сотрудника.. Как корректно продлить данному сотруднику договор?
Ответ:
Срочный договор по окончании расторгается, т.е сотрудник увольняется.
Если он не расторгнут, считается бессрочным.
Продление срочного ТД - это нарушение ТК РФ
По закону, если не было приказа об увольнении, и сотрудник не был с ним ознакомлен за три дня до окончания срока - то трудовой договор автоматически становится бессрочным. Читайте ТК РФ.
И еще: Обратитесь к судебной практике, а она такова, что два срочных договора, заключенных с работником по одной и той же специальности (профессии, квалификации и т.д.) подряд будут признаны судом, как один бессрочный трудовой договор. И понесутся проверочки: иснпекция, прокуратура и т.д. в результате нахлабучат административку.
Два подряд - вещь опасная, вызывает у проверяющих подозрения в попытке ущемить права работника, со всеми вытекающими последствиями.
У сотрудника нужно просто очистить поле дата окончания Труд. Договора., т.е сделать договор бессрочным.
17 правил для составления оптимального ЗАПРОСа к данным базы 1С 
В рамках данного семинара, мы эту проблему попробовали устранить и рассмотреть несколько жизненно-важных систем PostgreSQL со следующих точек 
Структура конфигурации представлена на рисунке справа: 
.gif)
