Обновлено: 03.01.2025

Общие модули содержат общие алгоритмы, которые могут вызываться из других модулей.

Опции Общего модуля

Вызов метода общего модуля

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

Пример косвенного вызова метода общего модуля:

• присутствует у Справочников, Документов, Отчетов, Обработок, ПВХ
  • отсутствует у Констант, Перечислений, Журналов, Внешних источников данных
  • у Регистров аналогичную роль выполняет Модуль Записи
  • переменные объявленные как Экспорт доступны у объекта как реквизиты <объект>.<Переменная>, но в отличие от реквизита она не сохраняется при записи
  • процедуры и функции описанные как Экспорт доступны у объекта как методы <объект>.<Процедура>(<параметры>)
    • по неизвестной причине доступ к переменным и методам у Обработок не действует

    Примеры

    Пример описания переменной, конструктора объекта, экспортной функции и пример вызова:

    ДанныеИсточника = ИсточникОбъект . ЭкспортнаяФункция ( ) ;

    Модуль предназначен для описания общих статических процедур и функций применимых к прикладному типу без контекста отдельного элемента семейства. Модуль менеджера похож на Общий модуль, но инкапсулирован в своем прикладном типе.

    • присутствует у Справочников, Документов, Журналов, Перечислений, Отчетов, Обработок, ПВХ, Регистров, Бизнес-процессов, Задач
      • отсутствует у Внешних источников данных
      • доступность обеспечивается только из модулей на Сервере
      • могут при необходимости получить объект или ссылку в параметре вызова

      Примеры

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

      ДанныеИсточника = Справочники . Источник . ЭкспортнаяФункция ( ) ;

      Очень похож на Общий модуль, но инкапсулирован в форму, поэтому ему доступны реквизиты данных, реквизиты формы, элементы формы и статические переменные.

      • компиляция по умолчанию выполняется на Сервере, но отдельные фрагменты модуля могут устанавливать другую область компиляции директивами компиляции
      • НаКлиенте
        • реквизиты объекта формы доступны через Объект.<Реквизит>
        • реквизиты формы доступны непосредственно по имени <Реквизит>
        • элементы формы доступны через Элементы.<Элемент>
        • статические переменные существуют только на время обработки события формы, а затем удаляются
        • реквизиты объекта формы доступны через Объект.<Реквизит>
        • реквизиты формы доступны непосредственно по имени <Реквизит>
        • элементы формы на Сервере недоступны
        • статические переменные существуют только на время вызова метода на Сервере, а затем удаляются
        • данные реквизитов при каждом вызове НаКлиенте->НаСервере и возврате НаСервере->НаКлиенте все (целиком в полном объеме) проходят через XDTO сериализацию
        • доступные методы реквизитов на Клиенте и на Сервере отличаются

        Временный динамический модуль создается платформой при использовании оператора Выполнить() :

        Пять директив определяют область исполнения функций и процедур. Их следует применять только в коде модулей управляемых форм и в коде модулей команд, в остальных модулях рекомендуется применять инструкции препроцессора.

        • директива должна предшествовать каждому определению в модуле
        • по умолчанию действует директива &НаСервере
        • директива &НаСервереБезКонтекста имеет смысл только в формах (чей контекст директива подразумевает)
        • определение в общем модуле с директивой &НаСервере в общем модуле имеет
        • директива &НаСервереНаКлиенте применяется только в коде модулей команд
        • приведенный в таблице порядок директив соответствует иерархии доступности, так функции и процедуры определенные с некоторой директивой имеют доступ к процедурам и функциям определенным с той же директивой, либо с любой директивой следующей ниже, но не имеют доступа к определенным с предшествующей директивой
          • определениям с директивой &НаКлиенте доступны все определения на Клиенте и все определения на Сервере, для которых предусмотрен серверный вызов
          • определениям с директивой &НаКлиентеНаСервереБезКонтекста доступны определения только с такой же директивой

          Инструкции препроцессора управляют включением и исключением фрагментов модуля прежде чем он будет скомпилирован для выполнения, все инструкции препроцессора и исключенные ими фрагменты кода отсутствуют в коде передаваемом компилятору модуля.

          Предусмотрены четыре инструкции

          • <Логическое выражение> = [НЕ] <Символ препроцессора> [<Булева операция> [НЕ] <Символ препроцессора> [<Булева операция> [НЕ] <Символ препроцессора>]…]
          • <Символ препроцессора> =
            <Булева операция> =

          Области

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

          Области выделяются с помощью двух инструкций препроцессора:

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

          Конфигурации применяют следующие области:

          Три аннотации позволяют определить перехват порядка вызова типовых методов новыми методами.

          Правила создания общих модулей

          Область применения: управляемое приложение, мобильное приложение, обычное приложение.

          1.1. Общие модули создаются для реализации процедур и функций, объединенных по некоторому признаку. Как правило, в один общий модуль помещаются процедуры и функции одной подсистемы конфигурации (продажи, закупки) или процедуры и функции сходного функционального назначения (работа со строками, общего назначения).

          1.2. При разработке общих модулей следует выбирать один из четырех контекстов выполнения кода:

          Тип общего модуля Пример наименования Вызов сервера Сервер Внешнее соединение Клиент
          (обычное приложение) Клиент
          (управляемое приложение) 1. Серверный ОбщегоНазначения (или ОбщегоНазначенияСервер)

          2. Серверный для вызова с клиента ОбщегоНазначенияВызовСервера 3. Клиентский ОбщегоНазначенияКлиент (или ОбщегоНазначенияГлобальный)

          2.1. Серверные общие модули предназначены для размещения серверных процедур и функций, не доступных для использования из клиентского кода. В них реализуется вся внутренняя серверная бизнес-логика приложения.
          Для корректной работы конфигурации в режимах внешнего соединения, управляемого и обычного приложений, серверные процедуры и функции следует размещать в общих модулях с признаками:

          • Сервер (флажок Вызов сервера снят),
          • Клиент (обычное приложение) ,
          • Внешнее соединение .

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

          Серверные общие модули называются по общим правилам именования объектов метаданных.
          Например: РаботаСФайлами , ОбщегоНазначения .

          В отдельных случаях для предотвращения конфликта имен со свойствами глобального контекста может быть добавлен постфикс "Сервер" (англ. "Server" ).
          Например: РегламентныеЗаданияСервер , ОбменДаннымиСервер, ScheduledJobsServer .

          2.2. Серверные общие модули для вызова с клиента содержат серверные процедуры и функции, доступные для использования из клиентского кода. Они составляют клиентский программный интерфейс сервера приложения.
          Такие процедуры и функции размещаются в общих модулях с признаком:

          Серверные общие модули для вызова с клиента называются по общим правилам именования объектов метаданных и должны именоваться с постфиксом "ВызовСервера" (англ. "ServerCall" ).
          Например: РаботаСФайламиВызовСервера, CommonServerCall .

          Следует иметь в виду, что экспортные процедуры и функции в таких общих модулях не должны содержать параметров мутабельных типов ( СправочникОбъект , ДокументОбъект и т.п.), так как их передача из (или в) клиентского кода невозможна.

          2.3. Клиентские общие модули содержат клиентскую бизнес-логику (функциональность, определенную только для клиента) и имеют признаки:

          • Клиент (управляемое приложение) ,
          • Клиент (обычное приложение) .

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

          Клиентские общие модули именуются с постфиксом "Клиент" (англ. "Client" ).
          Например: РаботаСФайламиКлиент , ОбщегоНазначенияКлиент, StandardSubsystemsClient .

          2.4. Для того чтобы избежать дублирования кода, рекомендуется создавать клиент-серверные общие модули с теми процедурами и функциями, содержание которых одинаково на сервере и на клиенте. Такие процедуры и функции размещаются в общих модулях с признаками:

          • Клиент (управляемое приложение) ,
          • Сервер (флажок Вызов сервера сброшен),
          • Клиент (обычное приложение) ,
          • Внешнее соединение .

          Общие модули этого вида именуются с постфиксом "КлиентСервер" (англ. "ClientServer" ).
          Например: РаботаСФайламиКлиентСервер , ОбщегоНазначенияКлиентСервер, UsersClientServer .

          В то же время, как только возникает необходимость ветвить код в клиент-серверных общих модулях на серверный и клиентский, то не следует использовать для этого инструкции препроцессора. Вместо этого, функциональность, различную для клиента и для сервера, рекомендуется реализовывать по общим правилам в модулях соответствующего типа – см. пп. 2.1 и 2.3. Такое явное разделение клиентской и серверной бизнес-логики продиктовано соображениями повышения модульности прикладного решения, упрощения контроля со стороны разработчика над клиент-серверным взаимодействием и снижением риска ошибок из-за принципиальных отличий требований к разработке клиентского и серверного кода (необходимость минимизации кода, выполняемого на клиенте, разной доступностью объектов и типов платформы и др.). При этом нужно иметь в виду неизбежное увеличение числа общих модулей в конфигурации.

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

          3.1. Имена общих модулей рекомендуется строить по общим правилам именования объектов метаданных. Название общего модуля должно совпадать с названием подсистемы или отдельного механизма, процедуры и функции которой он реализует. Рекомендуется избегать в названиях общих модулей таких общих слов как "Процедуры", "Функции", "Обработчики", "Модуль", "Функциональность" и т.п. и применять их только в исключительных случаях, когда они более полно раскрывают назначение модуля.

          Для того чтобы различать общие модули одной подсистемы, которые созданы для реализации процедур и функций, выполняемых в разных контекстах, рекомендуется задавать им постфиксы, описанные ранее в пп. 2.1-2.4.

          3.2. Дополнительно к общим модулям могут быть добавлены уточняющие постфиксы.

          3.2.1. Для глобальных модулей добавляется постфикс "Глобальный" (англ. "Global" ), в этом случае постфикс "Клиент" добавлять не следует.
          Например: РаботаСФайламиГлобальный, InfobaseUpdateGlobal .

          3.2.2. Модули, выполняющиеся в привилегированном режиме, имеющие признак Привилегированный , именуются с постфиксом "ПолныеПрава" (англ. "FullAccess" ).
          Например: РаботаСФайламиПолныеПрава .

          3.2.3. Модули, предназначенные для реализации на сервере или на клиенте функций с повторным использованием возвращаемых значений (на время вызова или на время сеанса), именуются с постфиксом "ПовтИсп" (англ. "Cached" ) и "КлиентПовтИсп" (англ. "ClientCached" ) соответственно.
          Например: РаботаСФайламиКлиентПовтИсп, UsersInternalCached .

          3.2.4. Серверные и клиентские модули библиотечных конфигураций (которые предназначены не для самостоятельного использования, а для разработки других конфигураций) с процедурами и функциями, допускающие изменение своей реализации, именуются с постфиксами "Переопределяемый" (англ. "Overridable" ) и "КлиентПереопределяемый" (англ. "ClientOverridable" ).
          Например: РаботаСФайламиКлиентПереопределяемый, CommonOverridable .

          3.2.5. В локализуемых конфигурациях, на базе которых выпускаются национальные прикладные решения для различных стран или регионов, модули, реализующие национальную специфику, именуются с постфиксами "Локализация" (англ. "Localization" ) и "КлиентЛокализация" (англ. "Client Localization " ).
          Например: ЭлктроннаяПодписьЛокализация, ElectonicSignature Localization .

          Доброго времени суток. Появляются такие ошибки:
          : Тип не определен (Запрос)
          Запрос = Новый <<?>>Запрос; (Проверка: Тонкий клиент)
          : Тип не определен (Запрос)
          ЗапрУвол = Новый <<?>>Запрос; (Проверка: Тонкий клиент)
          : Тип не определен (Запрос)
          ЗапрУвол = Новый <<?>>Запрос; (Проверка: Тонкий клиент)
          : Тип не определен (Запрос)
          ЗапрОтпуск = Новый <<?>>Запрос; (Проверка: Тонкий клиент)
          : Тип не определен (Запрос)
          ЗапрОтпуск = Новый <<?>>Запрос; (Проверка: Тонкий клиент)
          : Тип не определен (Запрос)
          Запрос = Новый <<?>>Запрос; (Проверка: Тонкий клиент)

          Прошу объяснить, что не так, пожалуйста

          __________________
          Помощь в написании контрольных, курсовых и дипломных работ здесь

          Итератор для значения не определен
          Ситуация такая: имеется документ с реквизитом типа Хранилище значений, у документа нет табличной.

          Тип не определен
          Здравствуйте, в процедуре выходит ошибка: Тип не определен кол =.

          Ошибка при создании scripting.filesystemobject: Тип не определен (СОМОбъект). Учебная версия платформы.
          Почему когда хочу создать обект scripting.filesystemobject выдает ошибку: Тип не определен.

          XDTO - Тип свойства не определен
          Всем привет. Камраден, подскажите кто знает. Конфы самопильные. Ситуация: Есть два xdto-пакета.

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

          
          

          Из обычного приложения в управляемое: ошибка Тип не определен - ДиалогВыбораФайла
          Здравствуйте, переделываю конфигурацию на упф, столкнулся с проблемой. Был следующий рабочий.

          
          

          Пользовательский тип не определен
          я недавно начал разбираться в макросах многого не понимаю это ошибка выходит уже 2 дня помогите ее.

          Модуль приложения 1С предназначен в основном для того чтобы поймать момент запуска приложения и момент завершения работы.
          Здесь же находятся обработчики, которые позволяют перехватить внешнее событие от оборудования.

          Подробно рассказано о модулях 1с их предназначений.

          В платформе 8.2 существует два модуля приложения:
          • модуль управляемого приложения
          • модуль обычного приложения

          Модуль управляемого приложения

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

          
          

          События модуля управляемого приложения срабатывают при запуске Тонкого клиента, Веб-клиента и Толстого клиента управляемого приложения.
          В модуле управляемого приложения отслеживается интерактивный запуск системы.

          Модуль управляемого приложения содержит:
          • раздел объявление переменных
          • раздел описания процедур и функций
          • раздел основной программы
          Процедуры, функции и переменные управляемого модуля могут быть описаны как экспортные (доступные вне данного модуля). Ещё в данном модуле могут содержаться специальные обработчики событий, которые возникают при некоторых обстоятельствах.

          Рассмотрим список обработчиков, который можно вызвать, нажав горячие клавиши 1С (Ctrl+Alt+P).
          ПередНачаломРаботыСистемы — действие ещё не произошло (происходит запуск 1С Предприятия 8.2 но само приложение ещё не появилось на экране). Если параметр “Отказ” выставить в значение “Истина” то приложение попросту не запустится. ПриНачалеРаботыСистемы — действие уже совершилось (параметра “отказ” нет). ПередЗавершениемРаботыСистемы — приложение ещё никуда не исчезло (есть параметр “отказ”).
          ПриЗавершенииРаботыСистемы — интерактивное окно уже закрылось.

          Загляните в синтакс-помощник и почитайте подробней о событиях управляемого и обычного приложения.

          Модуля приложения всегда целиком компилируется на стороне клиента. Т.е. из него можем обратиться к серверным процедурам и функциям общих модулей и не сможем обратится к таким объектам конфигурации как например документы, справочники.
          При старте системы происходит компилирование модуля управляемого приложения и чем больше в нем объявлено экспортных процедур и функций, тем дольше будет продолжаться запуск системы.

          Модуль обычного приложения

          Модуль обычного приложения можно увидеть там же где и модуль управляемого приложения, но если он не виден тогда необходимо в параметрах конфигуратора на вкладке “Общие” опции “Редактирование конфигурации для режимов запуска” в положение “Управляемое приложение и обычное приложение”.
          Как это сделать смотри в статье: Запуск обычного приложения в УТ 11.

          
          

          События модуля обычного приложения срабатывают при запуске толстого клиента обычного приложения.
          Все что было сказано для модуля управляемого приложения справедливо и для модуля обычного приложения.

          События Перед… и При….

          Отличие процедур ПередНачаломРаботыСистемы(Отказ) и ПриНачалеРаботыСистемы()

          ПередНачаломРаботыСистемы(Отказ) — действие еще не свершилось и мы можем отказаться от его выполнения.
          ПриНачалеРаботыСистемы() — действие уже свершилось, и отказаться от запуска приложения или выхода из него мы не можем.

          Вот и все, спасибо за внимание с вами был 1С Программист.
          

          Пожалуйста, оставляйте комментарии, мне важно ваше мнение.

          Постовой: Оформление медицинских справок за 10 минут. Чтоб оформить справку в ГАЙ надо потратить пару дней, но есть вариант справка на права купить. Возможно и доставка справки также прилагается копия лицензий

          Читайте также:

            
          • Как перевести деньги с расчетного счета ип на карту втб через приложение
            
          • Ошибка 0xa00f4292 в приложении камера windows 10 как исправить
            
          • В каком из этих предложений есть обособленное приложение знаки препинания не расставлены
            
          • Как зарегистрировать грин карту в приложении
            
          • Как активировать приложение яндекс