Часто встречаю вопросы касаемые программного создания и настройки прав пользователей.
В этот статье я приведу примеры для Обычного и Управляемого приложений, которые программно создают пользователя в конфигураторе и в режиме Предприятие (справочник пользователи) и установку Групп пользователей.
В приложении к статье обработки, код которых приведен ниже: Скачать обработки
Обработки были написаны под УТ, но, при необходимости, вы можете их легко доработать под другие конфигурации.
Управляемое приложение:
В конфигурациях на управляемом интерфейсе (Такси) изменили подход к ведению пользователей. Если вы добавляете не программно, то добавлять нужно из режима Предприятия - тогда пользователь ИБ у вас сам создатся. И если раньше, в обычном приложении, достаточно будет добавить польз в конфигураторе - и при заходе в Предприятие, этот польз сам создавался в спр Пользователи, то с управляемым приложением такой фокус не прокатит - система не даст зайти под пользователем ИБ, которого нет в справочнике Пользователи.
! В типовых конфигурациях для работы с пользователями активно используется БСП !
В общем модуле Пользователи используется программный интерфейс процедур и функций НовоеОписаниеПользователяИБ, ПрочитатьПользователяИБ, ЗаписатьПользователяИБ иУдалитьПользователяИБ.
Код создания нового пользователя с использованием БСП:
Разработчики в управляемых приложениях применили новый механизм настройки прав доступа, о которых и пойдет речь.
Будут перечислены все те грабли, которые собрал автор, чтобы вы о них знали.
Наверняка, уже все знают, что из себя представляет новая система, поэтому предистория вкрадце:
Как было раньше( в обычном приложении):
Есть документ. Есть Роли - ПолныеПрава, ДокументНетДоступа, ДокументТолькоЧтение, ДокументЧтениеИРедактирование. В конфигураторе(аналогичный механизм в реж предприятия) вы выставляете пользователям эти роли и у них появляются соответствующие права доступа на документ. Все просто и скучно и даже зевать хочется.
С введением управляемого приложения разработчики решили усложнить(читается как расширить) настройки прав доступа.
Теперь:
Вводная та же. Чтобы дать пользователю какие-то права на документ - сначала вам необходимо создать элемент справочника Профили групп доступа. Это некий агрегирующий(суммирующий значения) объект, который объединяет роли в группы ролей. Теоритически таких профилей можно создать сколько угодно много с различным набором ролей( N*(n-1), где N - количество ролей), но на практике количество профилей определяется количеством должностных обязанностей пользователей в организации и их гораздо меньше, чем ролей.
Чтобы "привязать" эти профили к пользователям - нужно создать элементы справочника ГруппыДоступа. В типовых они создаются автоматически, когда вы отмечаете галочками профили для пользователя. Этот справочник соединяет профиль и пользователя(или нескольких пользователей).
При записи этого элемента справочника система автоматически добавляет роли (из профиля) в роли пользователя. Поэтому не стоит напрямую редактировать роли в конфигураторе, как раньше - при редактировании прав в Предприятии все роли в конфигураторе будут обновлены на роли из профилей пользователя. Кроме того, будет наблюдаться явное противоречение между набором профилей с ролями и ролями, установленными в конфигураторе.
Как хранятся роли в Профиле групп доступа, спросите вы. Ведь роли - это объекты МД, это не ссылочные типы. Отвечаю - для этого(и не только) разработчики создали служебный справочник ИдентификаторыОбъектовМетаданных, в котором хранится( в иерархии!) имена, синонимы, значения пустых ссылок всех объектов МД. Если вы хотите создать Профиль программно и добавить в него роль, то код примерно будет таким:
Но если мы добавили новую роль в конфигурации, то как она попадет в справочник? Хороший вопрос. У справочника ИдентификаторыОбъектовМетаданных есть метод, позволяющий обновлять его данные. это:
Процедуру следует запускать каждый раз, когда вы вносите изменения в метаданные, особенно когда изменяете роли, объекты, связанные с новыми ролями.
Отлично. Роль добавили, идентификаторы обновили.
Но обратная связь не работает - вы в режиме предприятия назначили пользователю профиль( с созданием группы доступа), а роль у пользователя в конфигураторе не добавилась! Что делать?
За синхронизацию ролей/профилей отвечает константа ПараметрыРаботыПользователей. Если роли не обновляются в конфигураторе, следует обновить её значение:
Хорошо, скажите вы. А как быть, если я хочу создать группы доступа программно? Да не вопрос. Единственное ограничение - не допускаются дубли связок Профиль-Пользоваль в группах доступа. Примерный код будет таким:
После выполнения этого кода, если все, что нужно обновлено - типовая конфигурация добавит пользователю роли.
Раз уж пошли по программному пути, вот код, который добавляет пользователя в справочник Пользователи и ПользователяИБ в ПользователиИнформационнойБазы:
Если вы добавляете не программно, то добавлять нужно из режима Предприятия - тогда пользовательИБ у вас сам создатся.
И если раньше, в обычном приложении, достаточно будет добавить польз в конфигураторе - и при заходе в Предприятие, этот польз сам создавался в спр Пользователи, то с управляемым приложением такой фокус не прокатит - система не даст зайти под пользователемИБ, которого нет в справочнике Пользователи.
Оповещение пользователей в 1с в управляемом приложении могут быть вызваны как самой платформой, например, при записи документа, так и разработчиком, если он применит метод глобального контекста ПоказатьОповещениеПользователя().
Оповещения появляются в отдельном не модальном окне, по умолчанию привязанному к панели задач операционной системы, и затухают через несколько секунд после появления.
Если вывести несколько оповещений подряд, то пользователь сможет увидеть только последнее.
Последние несколько оповещений можно увидеть на панели истории.
При программном формировании оповещений важно помнить, что метод ПоказатьОповещениеПользователя()доступен только в контексте клиентской части, то есть при работе тонкого, толстого клиента или веб-клиента.
В качестве параметров метода ПоказатьОповещениеПользователя() передается строка с текстом оповещения, навигационная ссылка, текст с пояснением и картинка.
Навигационная ссылка будет представлена в области пояснения как гиперссылка, а в том случае если текст с пояснением не задан, то именно представление навигационной ссылки будет отображено в области пояснения. Получить навигационную ссылку можно для любого объекта базы с помощью глобального метода ПолучитьНавигационнуюСсылку().
Проиллюстрируем вывод оповещения при открытии документа, редактирование которого запрещено.
В приведенном примере производится проверка даты запрета редактирования, установленной в константе, и в том случае если открывается документ, попадающий в период запрета, пользователю выводится оповещение. В оповещении установлена навигационная ссылка на открываемый документ, однако в окне оповещения ссылка будет установлена к тексту «Разрешен только просмотр документа».
еще пример:
Для Толстого клиента kojinandrej предложил следующий механизм:
1. В модуле обычного приложения в процеду ПриНачалеРаботыСистемы добавляем текст
2. Создаем ОбщийМодуль под названием "опМодуль" в модуле вставляем текст
4. Добавляем в конфигурацию необходимые Обработки и формы - пользуемся.
Принцип Работы:
При запуске 1с справой стороны в трее открыто оповещение пользователей. Открываем обработку Оповестить, пишим текст сообщения и отметив получателей отправляем сообщение.
Когда сообщение приходит получателю, то форма оповещени появляется с правой стороны. Что бы сообщение считалось прочитаным, его необходимо открыть двойным щелчком правой клавиши мыши и оно откроется в новом окне как показао на третем изображении. В дальнейшем эти сообщения можно будет просматривать во вкладке "Просмотреные"
Программисту, имеющего немного опыта на платформе 1С 8.2, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта, а-а-а-а-аааа!!.....
Именно такое сложное чувство непонимания было поначалу и у меня. В процессе обучения и реального опыта была создана эта шпаргалка, целью которой было "разложить всё по полочкам", чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи объектов.
Для чего нам вообще нужны эти обработчики?
Очень часто программисту требуется переопределить стандартное поведение системы во время записи объектов, а именно: отменить запись, в случае каких-то условий; запросить дополнительную информацию у пользователя; дозаполнить реквизиты; что-то ещё записать в базу данных на основании этой записи; что-то изменить на форме после записи и т.д. и т.п. Каждый программист рано или поздно сталкивается с подобными задачами, потому знать назначение и последовательность запуска этих событий программисту, работающему на платформе 1С 8.2, необходимо.
В модуле формы или в модуле объекта?
Сначала надо определиться нужны ли нам данные формы? Будет ли запись записываться программным способом или только интерактивно? Будем ли вести диалог с пользователем?
Дело в том, что часть событий выполняется на уровне модуля формы и это значит, что они выполняются только при интерактивной записи, а также в этих событиях мы можем обращаться к данным формы, вести диалог с пользователем.
Другая часть событий выполняется на уровне модуля объекта, как при интерактивной, так и при программной записи.
Потому можно сразу определиться с обработчиком модуля формы или модуля объекта будем работать.
Модуль формы: на клиенте или на сервере?
Далее, если выбран модуль формы, то надо определиться какой обработчик потребуется: исполняемый на клиенте, или исполняемый на сервере. Если потребуется диалог с пользователем, то на клиенте, в противном случае на сервере. Их можно отличить по имени директивы компиляции или по имени обработчика (когда на сервере, это пишется в имени, например ПередЗаписьюНаСервере()).
Как выбрать конкретный обработчик?
Выбор зависит от поставленной задачи. Что конкретно можно делать в каждом обработчике опишу ниже, а пока пример.
Пример выбора обработчиков событий записи объекта:
Бывают задачи, когда потребуется использовать несколько обработчиков для решения одной задачи. Например, надо запросить информацию у пользователя во время записи: «Будем создавать новый документ на основании этой записи?» и, если пользователь ответит утвердительно, то надо создать новый документ с ссылкой на записываемый объект. Причем запись нового документа надо выполнять в транзакции, т.к. если текущая запись по каким то причинам будет отменена, то и уже созданный и записанный документ не должен остаться в базе данных.
Для решения этой задачи потребуется использовать обработчики события модуля формы по двум причинам:
1) Диалог с пользователем возможен только на клиенте, а клиентеские обработчики есть только в модуле формы. Для диалога будем использовать клиентскую процедуру модуля формы ПередЗаписью(), и сохраним ответ пользователя в параметре этой процедуры «ПараметрыЗаписи».
2) А в процедуре ПриЗаписиНаСервере() модуля формы примем этот параметр и в зависимости от него будем создавать документ или нет. Почему именно эта процедура? Ссылка будет получена только после записи, но поскольку нам нужно записывать в транзакции, то нужно использовать процедуры ДО завершения транзакции, но уже имеющие ссылку на записываемый объект. ПередЗаписью() не подходит , так как ещё нет ссылки, а ПослеЗаписи() не подходит, так как транзакция уже завершена. Остаётся ПриЗаписи(), но перед нами встаёт выбор: модуля формы или модуля объекта? Поскольку обработчик события ПриЗаписи() модуля объекта не содержит параметр, содержащий ответ пользователя, а событие ПриЗаписиНаСервере() модуля формы содержит, то ответ очевиден-используем это событие ПриЗаписиНаСервере() модуля формы потому что:
1) Это событие выполняется в транзакции 2) Содержит параметр «ПараметрыЗаписи», в котором уже содержится ответ пользователя, который передался из процедуры ПередЗаписью() 3) Ссылка уже создана и можно создавать новый документ, используя эту ссылку.
Ну и теперь последовательность запуска событий (в том порядке, в каком они перечислены) и небольшие подробности :
Во многих обработчиках есть параметр «Отказ». Там, где этот параметр присутствует означает, что в этом обработчике ещё можно отказаться от записи, присвоив параметру «Отказ» значение Истина, и тогда запись произведена не будет. 1) Модуль формы ПередЗаписью(Отказ, ПараметрыЗаписи)
Выполняется на клиенте!
Этот обработчик следует использовать, если необходимо организовать диалог с пользователем перед тем, как записать объект. Запросить дополнительную информацию, предупредить о чём-либо, дать возможность отказаться и т.п.
Второй параметр этого обработчика «ПараметрыЗаписи» имеет тип «Структура». У документов эти параметры заполняются системой предопределенными параметрами РежимЗаписи, РежимПроведения. Можно добавить свои.
Эти параметры передаются между событиями формы ПередЗаписьюНаСервере, ПриЗаписиНаСервере, ПослеЗаписиНаСервере, где их можно благополучно использовать. Например, при записи регистра сведений, надо сделать запись в другой регистр сведений старое значение ресурса. Можно передать старое значение в эти самые параметры и уже в ПриЗаписиНаСервере сделать запись в другой регистр. 2) Модуль формы ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)
3) Модуль объекта ОбработкаПроверкиЗаполнения (Отказ, ПроверяемыеРеквизиты)
Эти два обработчика проверки заполнения реализуются через параметр «ПроверяемыеРеквизиты» типа Массив, содержащий реквизиты, которые надо проверять (т.е. которым установлено свойство проверки заполнения «Выдавать ошибку»)
И если из этого массива убрать реквизит, то проверяться он не будет, если добавить, то будет выполняться проверка заполнения.
Таким образом, можно сказать, что эти два обработчика событий предназначены :
Для включения в проверку заполнения тех реквизитов, у которых в свойствах «ПроверкаЗаполнения» указано «Не проверять». Для этого надо добавить этот реквизит в массив параметр «ПроверяемыеРеквизиты»
Для того, чтобы исключить из автоматической проверки реквизиты, у которых установлено свойство проверки заполнения «Выдавать ошибку» в зависимости от каких-то условий. Для этого надо удалить этот реквизит из массива параметра «ПроверяемыеРеквизиты»
Имеется несколько особенностей, которые необходимо учитывать:
Если у формы из которой записывается объект в свойствах не установлено «ПроверятьЗаполнениеАвтоматически», то тогда эти обработчики проверки заполнения не вызываются и проверки не происходят!
Вызываются только при интерактивной записи! При программной записи не вызываются. Для проверки нужно использовать метод объекта ПроверитьЗаполнение(), который инициирует запуск этих событий.
Для документов, имеющих возможность проведения , эти события проверки заполнения вызываются только при проведении!
Оба эти события выполняются на сервере, отличие в том, что ОбработкаПроверкиЗаполненияНаСервере() это событие модуля формы и, следовательно, есть доступ к данным формы. А ОбработкаПроверкиЗаполнения() - событие модуля объекта. 4) Модуль формы ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
В этом обработчике можно дозаполнять реквизиты объекта или провести дополнительные проверки. Есть доступ к данным формы. Есть параметр ТекущийОбъект.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (СправочникОбъект,ДокументОбъект и т.д). Т.е. экземпляр класса объект создан, и можно обратиться к его свойствам и методам, но в базу данных ещё не записан. Начало транзакции 5) Модуль объекта ПередЗаписью(Отказ)
В этом обработчике можно дозаполнять реквизиты объекта или провести дополнительные проверки.
Для документов в параметры данного обработчика добавляются ещё два параметра:РежимЗаписи, РежимПроведения. Запись 6) Модуль объекта ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)
Возникает в момент, когда выполняется установка номера нового документа, задачи или бизнес-процесса.
Или ПриУстановкеНовогоКода(СтандартнаяОбработка,Префикс)
Возникает в момент, когда выполняется установка нового кода элемента справочника, узла плана обмена или кода плана видов характеристик.
Эти событии вызываются для объектов у которых указано свойство «Автонумерация» и только для новых объектов.
Если установить параметру СтандартнаяОбработка значение Ложь, то новый номер генерироваться не будет и можно программно задать код объекта в данном обработчике. 7) Модуль объекта ПриЗаписи(Отказ)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи.
Ссылка уже есть и можно записать в базу данных дополнительные данные на основании текущего объекта, используя эту ссылку.
Например, при записи создавать другой документ, содержащий реквизит ссылку на записываемый. 8) Модуль формы ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи. Есть доступ к данным формы. Есть последний шанс отказаться от записи.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (СправочникОбъект,ДокументОбъект и т.д). Можно обратиться к его свойствам и методам. Завершение транзакции 9) Модуль формы ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
Выполняется на сервере.
Можно использовать для того, чтобы визуально что-то отобразить на форме. 10) Модуль формы ПослеЗаписи(ПараметрыЗаписи)
Выполняется на клиенте!
Можно использовать для того, чтобы визуально что-то отобразить на форме или выдать предупреждение пользователю.
Событие При записи объекта вызывается всегда, когда объект записывается (интерактивно и программно). Обработчик этого события необходимо использовать для решения задач, которые связаны именно с записью объекта и не имеют отношения к интерфейсу.
Событие При записи формы объекта вызывается всегда, когда объект записывается в этой конкретной форме и вызывается оно расширением формы только при выполнении записи интерактивными командами или методом ЗаписатьВФорме(). Это событие необходимо использовать для решения задач, которые связаны с записью в конкретной форме.
ЗаписатьВФорме()
Возвращаемое значение:
Тип: Булево. Истина - объект записан; Ложь - в противном случае.
Описание:
Записывает объект, редактируемый в данный момент в форме.
Доступность:
Толстый клиент.
Форматированный документ предназначен для оформление текста. Его можно выделить жирным, подчеркнуть, увеличить/уменьшить шрифт, центрировать и т.д. Также можно добавить картинку. Т.е. в 1С теперь можно отформатировать текст, примерно, как в MS Word и др. подобным программам. Это может быть удобно при оформлении различных договоров или, например, при редактировании электронного письма. Таким образом, у нас есть возможность привести текстовый документ в тот вид, который мы пожелаем.
В синтакс-помощнике есть описание. Объект ФорматированныйДокумент (FormattedDocument) имеет одноименный тип данных, который поддерживает функционирование данного объекта и имеет следующие методы: Вставить (I_nsert)
Добавить (Add)
Записать (Write)
ПолучитьHTML (GetHTML)
ПолучитьЗакладкуКонца (GetEndBookmark)
ПолучитьЗакладкуНачала (GetBeginBookmark)
ПолучитьЗакладкуПоПозиции (GetPositionBookmark)
ПолучитьПозициюПоЗакладке (GetBookmarkPosition)
ПолучитьТекст (GetText)
Удалить (Delete)
УстановитьHTML (SetHTML)
Доступен во всех типах приложения: Тонкий клиент, веб-клиент, сервер, толстый клиент, внешнее соединение. Нельзя указать новый тип данных в качестве типа реквизита.
Есть одна важная особенность этого типа. Нельзя задавать тип «Форматированный документ» для реквизита объекта (справочника, документа и др.). Но есть возможность указывать его для реквизитов формы.
Возникает вопрос, как же нам сохранить те изменения при форматировании текста, которые сделал пользователь? Для этого применяется специальный объект «ХранилищеЗначения», который может содержать в себе любой тип данных, в том числе и «форматированный документ». Таким образом, в базе данных сам объект будет храниться как «Хранилище значения», далее при открытии формы необходимо будет извлечь объект из хранилища, отобразить его на форме используя тип «ФорматированныйДокумент». Если пользователь решит сохранить изменения, то при записи объекта нужно снова взять объект «форматированный документ» и записать его в хранилище.
Пример работы
Возьмем за основу каркасную конфигурацию, создадим в ней справочники «Контрагенты» и «Договоры». Установим справочник «Договоры» подчиненным справочнику «Контрагенты» и создадим реквизит «Текст» с типом ХранилищеЗначения.
Создадим форму элемента справочника «Договоры» и добавим на нее новый реквизит, который назовем «ТекстДоговора», укажем тип данных «ФорматированныйДокумент». Обратите внимание, что реквизит «Текст» с типом «ХранилищеЗначения» на форму поместить нельзя.
Создадим также командную панель (меню) содержащую необходимые кнопки для управления форматированным документом. Для этого надо добавить в форму «Группа – Командная панель» и указать в свойстве «Источник команд» реквизит формы «ТекстДоговора» с типом ФорматированныйДокумент.
Запускаем отладчик, проверяем, что у нас получилось…
Все бы хорошо, но есть некоторые проблемы:
Во-первых, если ввести текст и отформатировать его должным образом, то признак модифицированности для формы не возникает. Таким образом, случайно нажав на кнопку закрытия формы, система не задавая вопросов закрывает ее без всякого сохранения.
Для того чтобы подобные неприятности не случались, необходимо установить флаг у свойства «Сохраняемые данные» реквизита формы «ТекстДоговора». В результате, при любом изменении данных в реквизите «ТекстДоговора», будет устанавливаться признак модифицированности формы, а при ее закрытии система спросит: «Сохранить изменения?».
Во-вторых. Попытаемся закрыть форму и сохранить введенные данные. Заново открыв сохраненный договор, видим что текст введенный в форму договора отсутствует. Почему так происходит?
Все дело в том, что мы делаем изменения в реквизите формы, который у нас никак не связан с реквизитом объекта. Давайте настроим связь между реквизитом формы «Текст договора» с типом данных «ФорматированныйДокумент» и реквизитом объекта «Текст» с типом «ХранилищеЗначения».
Пропишем эту связь программно в модуле формы. Опишем алгоритм.
1. При открытии формы, необходимо будет обратиться к реквизиту объекта «Текст», чтобы прочитать из него данные и записать их в форматированный документ «Текст договора».
2. При записи объекта, берем содержимое форматированного документа и помещаем его в реквизит объекта «Текст» с типом «ХранилищеЗначения».
Таким образом у нас будет возникать эффект, что все изменения производимые пользователем, будут сохраняться в базе данных.
Нам понадобятся следующие обработчики событий:
- событие ПриЧтенииНаСервере(ТекущийОбъект)
оно удобно тем, что при ошибочном внесении изменений в данные формы, можно нажать кнопку «Перечитать» и вернутся к исходным данным.
Т.к. реквизит Текст у нас имеет тип «ХранилищеЗначений», надо учесть нюансы работы с ним… В случае чтения объекта используем метод Получить(), а в случае записи используем конструктор объекта Новый ХранилищеЗначения(<Значение>, <АлгоритмСжатияДанных>).
На этом пока всё. В следующий раз попробую рассказать про использование шаблонов для вставки параметров в текст форматированного документа, например, вместо %Контрагент% вставлять наименование контрагента. Сергей (SirYozha)
Автоматическая генерация отчета "Анализ заказов поставщикам"
Отчет анализ заказов является штатным отчетом конфигурации 1С Управление производственным предприятием. Обработка для генерации отчета, рассматриваемая в данной статье, позволяет программно создать и настроить форму отчета, запустить его выполнение. Полученный результат сохраняется в файл Microsoft Excel (XLS, XLSX) и может быть отправлен по электронной почте. Предлагаемое решение состоит из трех файлов:Скачивать файлы может только зарегистрированный пользователь!
service.vbs служит для запуска 1С предприятия и генерации отчета;
emailer.vbs - VBS скрипт предназначен для отправки результатов выполнения запроса отчета на указанный при настройке адрес электронной почты;
rep_email.epf - сама внешняя обработка для генерации отчета, выполняющая настройки отображаемых показателей, группировок строк и столбцов, установки требуемых отборов отчета, обеспечивает выполнение запроса и формирования табличного документа по макету отчета и сохранение сформированного отчета в XLS файл.
Запуск отчета выполняется посредством VBS файла (vbscript) при помощи "Назначенных заданий". VBS программа обеспечивает запуск приложения 1С, устанавливает соединение с сервером 1С и передает управление внешней обработке через экспортную функцию ReportNow(), размещенную в общем модуле обработки по генерации отчета. Пример VBS Script для выполнения внешней обработки 1С из командной строки:
VBS E-Mail скрипт для отправки готового отчета в формате Excel создает новое электронное письмо на заданный адрес, в теле письма указывает пояснение к отчету, а в качестве вложения прикрепляет файл, создание и наполнение информацией которого была произведена при запуске service.vbs
Внешняя обработка по запуску отчета "Анализ заказов поставщику" состоит из двух процедур. Первая - "ReportNow() Экспорт" служит для определения входной точки передачи управления от VBS к 1С. Вторая - "ОткрытьОтчетПоИмени()" - выполняет действия по настройке критериев отбора отчета, группировке строк и столбцов, определению состава количественных показателей. Данный способ вызова отчетов стандартной конфигурации широко применяется в различных формах 1С, и по мере развития конфигурации может быть позаимствован как минимум из нескольких форм списка справочников (Контрагенты, Номенклатура и т.д.). Исходный код первой функции: >
Сохранение отчета из 1С в Excel
Процедура формирования формы отчета принимает в качестве параметра название объекта метаданных конфигурации, в данном случае - "АнализЗаказовПоставщикам". Очевидно, что в зависимости от типа отчета процедура будет меняться пропорционально используемым реквизитам. В рассматриваемом примере добавляется отбор по контрагенту. Для своего ключевого поставщика заменить значение искомого наименования на нужное.
Для того, чтобы отладить обработку в режиме 1С:Предприятие, запущенного из конфигуратора можно создать экранную форму обработки и разместить в ней следующую процедур автоматического запуска отлаживаемого отчета:
Надеемся, что успешная комбинация внешней обработки для запуска отчета по расписанию и vbscript поможет в автоматизации бизнеса вашего предприятия. Данная редакция настроек больше ориентирована на менеджера поставщика для вашей компании, что отслеживать взаимное движение товаров и документов. Источник Руководство компании, хочет получать оперативную сводку продаж по фирме
Механизм бизнес-процессов автоматически формирует задачи по точкам маршрута в соответствии с настройками свойств адресации.
Однако в некоторых случаях встает необходимость программно переопределить стандартное создание задач. Для этого предназначены обработчики ПередСозданиемЗадач() и ПриСозданииЗадач().
Под согласованием понимается предварительная оценка проекта документа и/или получение согласия на его утверждение.
Бизнес-процесс согласования состоит из трех точек маршрута:
* определение списка рецензентов;
* cогласование рецензентами;
* обработка результата согласования.
В бизнес-процессе участвуют инициатор согласования и рецензенты.
После старта бизнес-процесс попадает на 1-ю точку маршрута, на которой инициатора согласования выбирает документ для согласования и определяет список рецензентов. После того, как инициатор выполняет свою задачу, бизнес-процесс переходит к следующей точке маршрута, на которой формируется по одной задаче для каждого из указанных рецензентов. При интерактивной активации задач рецензентов открывается форма для ввода текста согласования, после закрытия которой задача выполняется. После согласования у всех рецензентов, бизнес-процесс возвращается обратно инициатору для обработки результатов согласования.
После выполнения этой задачи бизнес-процесс завершается.
Так как исполнителей заранее определить нельзя , то в пояснении точек маршрута вписаны строки "Инициатор" и "Рецензенты" для того, чтобы сделать карту нагляднее. С этой же целью точке маршрута "На согласование" установлено свойство "Групповая", хотя реально оно не используется механикой бизнес-процесса, т.к. все задачи формируются программно.
Исполнителем первой и последней точки является инициатор бизнес-процесса. Исполнители точки "На согласование" определяются списком рецензентов, который составляет инициатор.
Формирование задач на точках "Определить список рецензентов" и "Обработать результаты" происходит в обработчике ПередФормированиемЗадач() и отличается тем, что в первом случае свойство "Сотрудник" берется из параметра сеанса, а во втором - из свойства "Инициатор" бизнес-процесса:
На точке "На согласование" задачи формируются в обработчике "ПриСозданииЗадач" путем перебора элементов табличной части "Рецензии":
Как то возникла ситуация, когда в справочник, с включенной проверкой на уникальность кода, из вне приходят элементы с такими же кодами. Отключать проверку нельзя. Пришлось делать затычку.
Подключение к SQL в общем то широко описано:
Сервер и БД можно получить и программно, но муторно. Эти данные можно взять из свойств БД на сервере 1С.
Название таблицы и полей в SQL можно получить с помощью команды 1С:
Дальше нам нужно новый элемент справочника все ж таки записать, ну например :
В процессе работы пользователей, зачастую возникает необходимость создать задачу другому пользователю ИБ и проконтролировать ее выполнение.
К примеру, существует следующая задача:
Автоматизируемая компания занимается торговлей оборудованием. Специфика отгрузки оборудования заключается в том, что в основном она сопровождается оказанием услуг по монтажу закупленного оборудования. Исходя из этого, при оформлении заказа покупателя необходимо кроме ответственного за данный заказ указывать ответственного сотрудника по монтажу (в случае если это услуга не предусмотрена, реквизит не виден).
Если услуга по монтажу оборудования предусмотрена, то автоматически должно сформироваться два напоминания (события):
- Для ответственного менеджера на дату и время напоминания
- Для сотрудника ответственного за монтаж за сутки до напоминания ответственному менеджеру.
Когда срабатывает напоминание у ответственного менеджера, он должен видеть отработано ли напоминание сотрудника по монтажу оборудования.
Сформировать отчет, показывающий состояние согласования (когда сотрудник, ответственный за монтаж отработал напоминание) по незакрытым заказам покупателей (в случае оказание услуги по монтажу).
Решим ее следующим способом:
Создаем три реквизита документа Заказ покупателя: М_Монтаж (булево), М_Монтажник (Справочник пользователи) и М_ДатаМонтажа. Размещаем их на форме. Для того что бы сами реквизиты и их надписи были не видимы добавим процедуру:
При открытии формы документа тоже надо проверять можно ли отображать на форме новые реквизиты. Процедура УстановитьВидимость() вызывается из процедуры ПриОткрытии(). Именно здесь продублируем код процедуры М_МонтажПриИзменении(Элемент). Существуют, конечно, варианты. Например, можно управление видимостью организовать только в процедуре УстановитьВидимость() а в МонтажПриИзменении() обращаться к ней, или в процедуре УстановитьВидимость() вызывать МонтажПриИзменении(), однако, в первом варианте при каждом изменении значения реквизита «М_Монтаж» будет происходить установка видимости всех реквизитов в форме, что негативно скажется на производительности. Второй вариант не совсем корректен с точки зрения логики расположения программного кода, по этому сделаем наш код слегка избыточным, но зато логичным и не замедляющим работу программы.
При проведении документа следует создавать Задачу пользователя с взведенным флагом «Напоминание» и установленной датой напоминания. Лучше всего располагать создание задач после проверки на корректность заполнения всех полей документов (ведь документ может не провестись, а задачи создадутся)
Создавать задачи лучше с помощью немного доработанной процедуры РаботаСДиалогами.ПроверитьЗадачиПоОбъекту(Ссылка);
Во-первых, она проверит, есть ли введенные на основании этого документа задачи, и если обнаружит их, выдаст диалоговое окно пользователю с предложением не создавать новые. Этим мы исключим вероятность создания большого числа напоминаний при перепроведении документа. В самой функции ПроверитьЗадачиПоОбъекту() напишем:
Обратите внимание на реквизит «Инициатор» двух создаваемых нами задач. В форме списка задач существует возможность переключаться в режим просмотра заданий выданных текущим пользователем. Именно с помощью такого определения инициатора выполняется условие задачи: «В окошке напоминания менеджера должно быть видно, отработано ли событие монтажником»
Отчет в задании совсем не сложный, правда, могут возникнуть сомнения какой заказ считать закрытым. Как известно, заказ покупателя делает два движения. Одно по регистру «Заказы покупателя» где в разрезе номенклатуры, ведется учет по отгруженным товарам, второе по регистру «Расчеты с контрагентами» и здесь контролируется оплата по заказу. Думаю, что закрытым можно считать заказ, которого нет в остатках ни по одному, ни по второму регистру. Соединив их полным соединением, а так же присоединив таблицу Задач пользователя, получим отчет по незакрытым заказам пользователя. Автор: Максим Нечистяк
Есть три варианта ответов:
1. автоматически в момент ввода информации в регистр из документа-регистратора
2. программно в момент ввода информации в регистр из документа-регистратора
3. вручную после ввода записи в регистр расчета
Считается, что правильный ответ - 2. Да, действительно, видим, что в модуле документа в обработке проведения есть строки:
Вместе с тем, Максим Радченко пишет в своей книге:
"Для указания факта принадлежности записи к какому-либо периоду регистр имеет служебный реквизит ПериодРегистрации типа Дата. При записи данных в регистр платформа всегда приводит значение этого реквизита к началу того периода, в который он попадает. Например, если в регистр расчета с периодичностью месяц записать данные, где ПериодРегистрации задан как 08.04.2004, то регистр сохранит эти данные со значением поля ПериодРегистрации 01.04.2004."
Получается, что период регистрации определяется в два этапа:
а) программно в модуле документа в момент ввода информации в регистр,
б) автоматически системой при записи данных в регистр.
Ответ 2 соответствует пункту а), но сказать, что он полностью правильный, нельзя, т.к. в нем не отражен пункт б).
Вместе с тем, и ответ 1 в его текущей формулировке тоже не подходит. Ответ 3 не подходит в принципе.
Документ «Корректировка записей регистров» в типовых конфигурациях 1С предназначен для ручной корректировки записей регистров накопления, зависимых регистров сведений и регистров бухгалтерии. Типичные ситуации, в которых может понадобиться документ «Корректировка записей регистров», - ввод начальных остатков, исправление ошибок в учете, отражение в учете операций, для которых в конфигурации нет специальных документов. В документе есть сервис автоматического заполнения движений с предопределенным действием «Сторно движений документа». С его помощь можно автоматически создать движения по регистрам бухгалтерии и регистрам накопления, аналогичные движениям указанного документа, но с отрицательными значениями.
Иногда количество вводимых записей по регистрам может быть велико и тогда целесообразно выполнить корректировку регистров программно. Документ «Корректировка записей регистров», как Вы уже, наверно, догадались, не совсем обычный. А иначе бы о нем не стоило и писать.
В качестве примера, когда может потребоваться программно создать документ «Корректировка записей регистров», предлагаю рассмотреть операцию переоценки основных средств. Переоценка основных средств - ситуация хоть и нечастая, но все же вполне реальная, а специального документа для переоценки в типовых конфигурациях 1С нет. Чтобы пример получился более представительным (включал в себя все виды корректируемых регистров), я сделал обработку для конфигурации «1С:Управление производственным предприятием». Но с другой стороны, чтобы не перегружать пример лишней информацией, мы рассмотрим случай, когда в результате переоценки происходит увеличение стоимости основных средств и накопленной амортизации (дооценка).
В этом случае переоценка основных средств отражается в бухгалтерском учете проводками:
В налоговом учете операция переоценки основных средств не предусмотрена, но для того чтобы соблюдалось равенство БУ = НУ + ПР + ВР, мы должны отразить в учете возникновение постоянных разниц. Также мы должны сделать движения в регистрах накопления «СтоимостьОС», «СтоимостьОСБухгалтерскийУчет» и в регистрах сведений «ПараметрыАмортизацииОС», «ПараметрыАмортизацииОСБухгалтерскийУчет», «СобытияОС» и «СобытияОСОрганизаций».
Исходные данные для переоценки ОС берутся из dbf-таблицы с набором полей:
* OS (строка) - код основного средства;
* SumU (число) - сумма дооценки по управленческому учету в единицах валюты управленческого учета;
* SumB (число) - сумма дооценки по бухгалтерскому учету;
* AmortU (число) - сумма дооценки накопленной амортизации по управленческому учету в единицах валюты управленческого учета;
* AmortB (число) - сумма дооценки накопленной амортизации по бухгалтерскому учету.
Упрощенный фрагмент кода обработки, иллюстрирующий запись проводок в регистр бухгалтерии, представлен в листинге:
Как видно из примера, документ «Корректировка записей регистров» используется в качестве регистратора, движения же записываются непосредственно в регистр. Движения по регистрам накопления и регистрам сведений делаются аналогично.
Как программно создать нового пользователя или скопировать настройки существующего? 
В этот статье я приведу примеры для Обычного и Управляемого приложений, которые программно создают пользователя в конфигураторе и в режиме Предприятие (справочник пользователи) и установку Групп пользователей.
