Модуль 1с стандарт это
Правила создания общих модулей
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1.1. Общие модули создаются для реализации процедур и функций, объединенных по некоторому признаку. Как правило, в один общий модуль помещаются процедуры и функции одной подсистемы конфигурации (продажи, закупки) или процедуры и функции сходного функционального назначения (работа со строками, общего назначения).
1.2. При разработке общих модулей следует выбирать один из четырех контекстов выполнения кода:
(обычное приложение)
(управляемое приложение)
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 .
Сейчас Диадок поддерживает три вида модулей интеграции с системой 1С 8.2 и 8.3: обыкновенный, управляемый и ПРО, который дорабатывается под нетипичные процессы заказчика. Из-за регулярных изменений в законе осуществлять изменения этих решений (добавление опций и дополнительной функциональности) стало намного сложнее. По этой причине мы приняли решение убрать 2 модуля, оставив 1, в котором содержатся все их возможности, имеется усовершенствованный интерфейс и способность функционировать в типичных конфигурациях 1С 8.
Что мы добавили в единый модуль для 1с 8.2 и 8.3?
С 01.10.21 года пользователям будет доступен единый модуль Диадок для 1С. Новая версия будет иметь следующие преимущества:
- Будет очень быстро запускаться.
- Иметь понятный для каждого интерфейс пользователя.
- Легко подстраиваться под запросы клиента.
- Хорошо работать на обыкновенных и управляемых формах.
- Иметь высокую производительность даже при очень крупном потоке документов.
- Позволять осуществлять массовые действия с документацией.
- Иметь широкие возможности фильтрации, в том числе сохранение отобранных данных.
В нашей видеоинструкции мы подробно объяснили, как запускать модуль и работать с его главным функционалом.
Изменение прайса
С 01.10.21 в прайс-листе на модуль Диадок мы оставим только одну позицию из конфигураций 1С. Цена подписки на год будет составлять 13700 рублей. После завершения актуальной на текущий момент годовой лицензии, продлить её вы сможете на обновленную версиюя.
Предположительное прекращение поддержки
Со вступления нововведений в силу ровно через год наша техническая поддержка перестанет обслуживать модуль Контур.Диадок «Стандарт» (в прайсе — модуль «Интеграция»). Вплоть до 01.10.2022 года мы будем убирать ошибки в модуле и дорабатывать его в соответствии с изменениями в законе Российской Федерации.
Переход на единый модуль для пользователей разных тарифов
Если вы использовали модуль «Стандарт»
Обновите текущий модуль по предложенной нами инструкции. Этот процесс не займет у вас более 5 минут. Инсталлируйте модуль и дальше стабильно, бесперебойно работайте со своей документацией. Все настройки, в том числе и взаимосвязь с документами в 1С, будут сохранены в системе. Вы сможете использовать единый модуль без каких-либо доплат. Действие годовой лицензии, актуальной на текущий момент, будет сохранено до необходимости её продления.
Если вы использовали модуль «Стандарт» с доработкой нашими специалистами
После обновления вам будет нужна помощь наших технических специалистов в том случае, если:
- Вы меняли интерфейс модуля для осуществления узкоспециализированных задач в вашей компании.
- Были осуществлены доработки, которые не связаны с содержанием документов на отправку.
- Ваша компания использует уже устаревшую версию системы 1С.
Обо всех изменениях вам сообщит наш менеджер в первом квартале следующего года. Также он расскажет подробный план дальнейших действий. На сегодняшний день изменения вас не касаются.
Если вы пользовались модулем «ПРО»
Если вы пользовались модулем «ПРО»
Подключите лучший тарифный план
Контур. Диадок под ваши потребности
По 7,6 за документ
По 7 за документ
По 6,5 за документ
По 6,2 за документ
По 6 за документ
По 5,7 за документ
Получить ЭЦП для работы с ЭДО
Получите электронная подпись по лучшей стоимости в 1 клик
Больше 12 000 документов?
С Контур.Диадок это
не проблема!
Заказать больше 12 000 док.
Электронная подпись
Сертификат
без лицензии
КЭП без лицензии СКЗИ Крипто-ПРО.
Сертификат
электронной подписи
КЭП со встроенной лицензией СКЗИ Крипто-ПРО, но без носителя Рутокен.
КЭП со встроенной лицензией СКЗИ Крипто-ПРО и носителем Рутокен.
Лицензия СКЗИ Крипто-ПРО на 1 год
Длительность активации лицензии на СКЗИ «КриптоПро CSP» - 12 месяцев.
Получить
электронную подпись
Начните отправлять документы через Контур. Диадок
Сервис Контур. Диадок – это хорошая возможность сделать работу документами быстрой, комфортной и грамотной. Представленные тарифы доступны для всех клиентов. С их помощью можно существенно экономить финансы на ЭДО.
Каждый из представленных тарифов имеет следующий функционал:
- Встроенный текстовый файлообменник;
- Свободный доступ для разрешенных лиц к входящим документам;
- Возможность подписания, согласования и доработки документов;
- Доступ сотрудников к файлам в режиме просмотра;
- Профессиональную и круглосуточную службу поддержки;
- Возможность хранения файлов на сервере Контур бессрочно.
В указанных тарифах на 12 месяцев для пользователя уже внесена сумма предоплаты за транспортировку документов в установленном количестве. По завершению периода активации тарифа пользователь автоматически подключается к пакету «Универсальный». Оплата осуществляется исключительно по тем документам, которые совершали документооборот. В соответствии с НК РФ эти суммы не облагаются налогом НДС.
Чтобы начать работать с Контур.Диадок пользователю не понадобится оформлять договор о сотрудничестве на бумаге. Нужно войти в свой личный кабинет с помощью сертификата ЭП и отметить пункт согласия с условиями договора.
Если вы используете Контур. Экстерн , это означает, что Диадок доступен для вас автоматически на странице «Первичка».
Начните сотрудничество с провайдером Диадок уже сейчас!
Заполните эту форму и нажмите кнопку «Подать заявку». Наши сотрудники позвонят вам в течение часа, чтобы помочь подобрать выгодный тариф, и расскажут о доступных способах интеграции.
Описывается структура областей модулей, которую я использую при разработке на своих проектах. Обсуждаются недостатки стандарта 1С "Структура модуля". Предложен улучшенный подход к работе со структурой модуля.
В этой небольшой статье я попытаюсь продемонстрировать более удачное применение областей модуля. Как мне представляется, на самом деле, требуется не повысить читаемость кода, а структурировать его, улучшить его понимаемость, и облегчить внесение изменений.
На мой взгляд, даже названия разделов неудачны, например:
- "ПрограммныйИнтерфейс" - интересно, а какой еще как не "Программный" он может быть в данном случае,
- "СлужебныеПроцедурыИФункции" - слишком длинно, к тому же в эту область можно включить вообще любую процедуру и функцию. Критерии считать функциональную единицу "служебной" или "не служебной", как правило, размыты.
- "ОбработчикиСобытийТаблицыФормы" - уснешь, пока дочитаешь до конца, проще и компактнее просто "События".
Предложенный подход не использует в полной мере возможности областей кода. Ведь можно создавать вложенные области. Более того, вложенные области могут иметь одинаковые имена, т.е. например мы можем создать область
Вот какие разделы рекомендуется использовать.
Для модуля формы:
В разделе "Форма" собираются все обработчики событий формы.
В разделе "Элементы" собираются все обработчики событий элементов формы (кроме таблиц и табличных полей).
В разделе "Таблицы" собираются обработчики событий всех таблиц формы. При необходимости в область таблицы можно добавить вложенную область "Команды" и включить в нее все команды относящиеся к таблице.
В разделе "Оповещения" собираются все оповещения о событиях формы.
В разделе "Подключаемые" указываются все подключаемые процедуры и функции формы.
Исходный замысел был в том чтобы разделить логику модуля на клиентскую и серверную части соответственно, однако, естественно, при увеличении объема кода, принятый набор областей перестанет справляться со сложностью. В этом случае, я переразбиваю функции, добавляя область "Пакеты", и уже в ней указываю вложенные области, группируя функции. Например:
Хотя появление этой области, скорее говорит о том что функционал формы перегружен. Впрочем, для каких-то сложных обработок, это может быть применимо.
Для модуля объекта:
Для общего модуля (и для модуля менеджера):
Специальные предложения
Если вы укоротили имена областей, это еще не значит, что повысили читаемость кода.
Вот смотрите, например, область " ОбработчикиСобытийФормы ". Любому разработчику понятно, ЧТО в этой области должно храниться. Вы же предлагаете назвать эту область расплывчато " Форма ". Да это название короче, но поставьте себя на место разработчика, который не знаком с вашим стандартом. Сможет ли он без ваших объяснений догадаться, что писать в эту область? Вы уверены, что он впишет туда только обработчики событий формы? То же самое и с другими областями ( Элементы , Таблицы , Интерфейс и т.д.).
По поводу дополнительных областей, которых нет в стандарте, тоже не согласен. Все дополнительные области следует помещать в " СлужебныеПроцедурыИФункции ". Именно поэтому у нее такое общее и расплывчатое название. Внутри нее можно поместить области " Подключаемые ", " Оповещения " и др.
Вообще, гораздо проще освоить общий стандарт, чем придумывать свой. Ведь если придешь в новую команду и начнешь всем объяснять, что вы пишете неправильно, а я правильно, то встретишь непонимание и недоумение со стороны коллег.
Лично я давно уже привык к стандартным областям, и могу с уверенностью заявить, что в них лаконично укладывается 99.9% всех решаемых задач, и был бы сильно против, если бы мне кто-нибудь начал навязывать подобные улучшения.
ShiningPhoenix; shalimski; kaliuzhnyi; Agapov_Stas; AnderWonder; RailMen; TreeDogNight; NeviD; Vladimir Litvinenko; hydro2588_2015; unichkin; alest; Solovyeff; sorb; Бубузяка; kuzyara; dour-dead; JohnyDeath; CSiER; klinval; binex; TODD22; DenisCh; корум; kolya_tlt; h00k; charushkin; Makushimo; + 28 – Ответить
:-) исходя из каких предпосылок вы пришли к умозаключению что я собираюсь
:-)? Пусть это останется загадкой.
Даже в самой 1С точность "стандарта" соблюдается, скажем так, "с доработками". Достаточно посмотреть на исходные коды конфигураций УП, УНФ и Документооборот. Разные команды даже внутри самой 1С изменяют его под себя.
(2) открыл Документооборот 2.0.14.4. Увидел там, что стандартные области соблюдаются. Просмотрел несколько форм, модулей менеджеров, модулей объектов. В чем именно вы заметили несоблюдение? Приведите конкретный пример.
Других конфигураций под рукой нет.
Про вложенные области я не упомянул, т.к. они не регламентированы. Во вложенных областях каждый может писать, что считает правильным.
Скажу вам по своему опыту, что очень трудно приучить разработчиков соблюдать даже типовой стандарт. А уж тем более предлагать кому-нибудь свой стандарт - дело совсем неблагодарное. Но желаю вам удачи в этом начинании)
Функция ПолучитьПолноеИмяПользователя()
Функция СоздатьПараметрыЗаполненияЦенПоставщика()
Функция ОпределитьДатуНачалаСеанса()
Функция ПолноеИмяПользователя()
Функция НовыеПараметрыЗаполненияЦенПоставщика()
Функция ДатаНачалаСеанса()
Не в обиду, но данная статья - велосипед, с квадратными колесами. Желаю автору не тратить время на эти изыскания, а изучать стандарты вендора. Чтобы ваять что-то значимое на 1С - необходим обязательный упор на групповую разработку, а там важны конвенции, которые жестко соблюдаются всеми. Чем больше 1С-негов это осознает, тем проще всем нам будет жить.
слова "Форма" и "Элементы" - это служебные слова, их нельзя использовать в качестве именований переменных.
Но имена областей кода не являются переменными.
:-) там тоже есть ошибки и недочеты, как и в любом творении рук человеческих.
Данная статья, это изложение моего "оценочного суждения" основанного на опыте. Эту информацию я опубликовал для того чтобы поделиться с сообществом, на мой взгляд, полезной идеей. Возможно, кому-то она понравится и кто-то из коллег воспользуется ей.
:-) "Что позволено Юпитеру, то не позволено быку". Я делаю второе, но никогда не буду делать первого :-)
Чтобы ваять что-то значимое на 1С - необходим обязательный упор на групповую разработку, а там важны конвенции, которые жестко соблюдаются всеми
С этим не поспоришь. Но, увы, практика показывает что императив "жестко соблюдаются всеми" является таки мечтой. В реальности обычно "более или менее соблюдаются всеми".
А кто такие 1С-неги?
Все эти попытки группировок модулей с помощью областей - от Лукавого. Как и автор статьи, одно время пытался навести порядок в своих алгоритмах с помощью областей. Придумывал имена, менял порядок следования, ломал голову куда-что перебросить с риском развалить всю хатку. И что? Я стал быстрее программировать? Нахожу быстрее требуемые процедуры-функции? Быстрее переключаюсь? Логика понятней? Не знаю как у вас, Господа, но мне эти группировки никак жизнь не облегчают. Всегда пляшу от формы. И все наши с вами попытки навести красоту и сделать нашу программистскую жизнь легче, - потеря времени, пока сама фирма 1С не обратит свои взоры в эту сторону. Как по мне, боковая навигационная панель к программному модулю, в которой перечислялись бы применительно к текущему модулю все вызывающие и вызываемые модули была бы куда интересней. На ней же события-команды не помешали бы. Ну, может быть, еще чего, - можно пофантазировать. Мне не нужна структура всея конфигурации. мне нужна подсказка по структуре здесь и сейчас, в текущем модуле. А автору за попытку улучшения стиля таки спасибо. Думал. мечтал. фантазировал. решал. предлагал. Ну что с того, что пошел против общего течения? Зато дал повод и нам помечтать. :)
(5)Раззадорился я малость.. :) Ну сами подумайте! С какой стати мы сами должны группировать? Что, при создании нового события не ясно, что это событие и нужно его включить в область событий в модуле формы для конкретного реквизита формы? Нееет, бросим это событие в конец модуля формы, - так думает фирма 1С. Полагает, что нам доставляет удовольствие после создания нового события, выщемить его, найти в модуле формы область событий для реквизита формы и туда его перекинуть, - чтобы красиво было и всем все понятно! :)
Я не в претензии к фирме 1С. Я снимаю перед разработчиками 1С-Предприятие шляпу за труд, который еще никому не удавался. Но. некоторые моменты вызывают улыбку. То же создание стандарта, указанное автором статьи. Не читал, но по контексту уже догадался о чем. Вместо того, чтобы при создании новых событий реквизитов формы бросать их в соответствующие области модуля (ведь понятно какие, можно создать на автомате), опубликуем стандарт! Пусть программисты 1С отдохнут на легком труде. :)
(6) Ну по поводу удобства использования Конфигуратора было написано уже довольно много. Скажем так, в этом плане Конфигуратору есть куда расти. Лично я очень большие надежды возлагаю на новую среду разработки на базе Eclipse.
Вот как минимум процитированное должно соблюдаться, при правильном использовании областей. Так-как точно не надо "шерстить" весь модуль для поиска нужной функции, достаточно развернуть нужную область.
С быстрым переключением та же история - развернул область, нашёл нужную функцию.
С логикой чуть сложнее, больше зависит от образа мышления того разработчика чей код смотришь.
И ещё, стоит учесть, что имена областей в стандарте полностью соответствуют устоявшимся именам областей модулей. Просто раньше приходилось их выделять при помощи комментариев, а сейчас появился более удобный инструмент.
(7) "На безрыбье - и рак рыба!" И есть очевидная польза от областей многим из нас. Равно, как некоторым из нас это лишь дополнительная головная боль при наведении порядка, который в массе можно было бы поддерживать автоматически. Да, области нужны для выделения крупномасштабной структуры. А в плане поиска требуемого. еще ни разу они не ускорили мне работу. Замедлили - да! - в попытке вспомнить что и в какой области. в каком месте находится. Играл я как-то с "свернуть-развернуть" область пытаясь найти что-то, - удовольствия не получил. :) Наверное, от привычек многое зависит, отработанных подходов. Каждый выбирает, что ему удобней.
Можно. И разработчики платформы ведут работы в этом направление. Но, у них есть масса более важных и приоритетных задач, ради ускоренной реализации которых лично я готов мирится с "неинтеллектуальной" вставкой процедур обработчиков в модули.
П.С.: Было уже схожее обсуждение на партнёрском форуме. Лично я тогда голосовал за "отложить" на потом работы по "юзабилити конфигуратора". И сейчас моё мнение не изменилось.
(5) Ну, как говорится, "доброе слово и кошке приятно" :-) Области кода используются во многих средах разработки, та же VS Microsoft например. Лично я нахожу их очень удобными и полезными, но тут, конечно, это вопрос личных предпочтений.
Я не иду против течения, скорее я пытаюсь сделать движение по течению более комфортным и эффективным. :-)
Страсти отшумели, я поздно увидел публикацию. Мне приятно видеть, что автор
1) озабочен качеством кода,
2) при этом не следует слепо чужим правилам. Хочешь сделать жизнь краше-делай!
По моему опыту, и как видно из обсуждения, мотивация некоторых программистов на вопрос "а зачем украшать код (т.е. страдать ерундой)" строится на постулатах:
* "быстрее я писать не стану. А мне и так удобно". " Всегда пляшу от формы" - как написано выше. (5) Короче, жалко времени.
* "Я же это для себя писал". Второй вариант: под индивидуального заказчика, третий вариант: для нормального решения, но для меня это была разовая работа. Вот так происходит трансформация мышления. А в жизни так: если ты в лесу поворот не показываешь, то и везде так-же ездишь.
Только собственник конечного продукта понимает ценность красивого и понятного кода. Это и надежность, и реальные трудозатраты в сопровождении, которые могут превышать первоначальный труд на создание.
А что касается отношения к строгости стандартов, то должна быть некоторая незашоренность. Нравятся тебе более короткие названия - реши и пиши так.
По поводу областей спорят: нужны - не нужны. Обалденно нужны! Но правило должно не быть: "а этот блок обязательно в область". У меня так: размер модуля до 2-3 экранов - можно не разбивать по областям. Больше - обязательно.
Автору - плюс.
(21)Здесь немного упомянули мое имя всуе. :) Хочу дать некоторое дополнительное уточнение (назову так) к свои комментариям. Я, вообще-то, не против областей как это может показаться, и стандартов по их использованию. Напротив, я зА использование областей. И если бы участвовал в разработке типовых решений, непременно следовал бы им для поддержания единообразия в программировании и еще потому, что иначе решение не было бы принято как типовое. Но. я против дурной работы в тех случаях, когда я являюсь единственным постановщиком и исполнителем всех работ, связанных с программированием. В условиях, когда платформа в нынешнем состоянии никак не поддерживает программистов в эффективном использовании этих самых областей. А в большинстве своем эти области могут поддерживаться платформой на автомате (что скорее всего будет реализовано в будущем). А что получается? Я навел порядок в программном коде, разложил все по областям, а потом (спустя длительное время, когда все уже давно забыто) добавил еще пару-тройку событий и. "наша песня хороша - начинай сначала" с наведения порядка, тупого перетаскивания событий по областям. Мы что, обезьяны, чтобы тупо перекладывать все с места на место? Ничего более умного нельзя реализовать? Понятное дело, разработчикам пока что не до таких мелочей. А нам остается ждать. И тогда уж, мы будем поддерживать области собственными усилиями только там, где платформа в принципе не способна разделить процедуры-функции по областям, ибо все "правила" в голове программиста.
(21) Спасибо, Игорь. Divide et impera - разделяй и властвуй. Но как разделить правильно? Как разделить лучше? Статья - размышление на тему как точнее разделять код на ясные блоки, с помощью имеющегося в наличии инструмента - областей кода. Мнения коллег разнятся, конечно, все люди разные. :-)
Поставил плюс, так как затронута важная тема.
В целом со статьей не согласен - нужно следовать стандартам уже имеющимся.
(10) Безусловно, профессиональный подход к командной разработке любого сложного продукта требует чтобы все участники следовали уже имеющимся стандартам. Но разве это утверждение запрещает рассматривать предложения по улучшению действующего стандарта?
"практика показывает что императив "жестко соблюдаются всеми" является таки мечтой" - как-раз из-за того что все хотят "хорошо", но каждый по-своему. Я тоже сперва велся на подчеркивание в областях, пробовал как-то под себя это все подогнать. А потом подумал что в 1С наверное не дураки сидят, не просто так это все. И начал оформляться так, как это сказано на ИТС. Сейчас не представляю зачем изобретать что-то иное - видимо привык. Имхо - разработка стандартов не то, чем надо заниматься на работе. Хотя бы потому что все уже придумано, и это реально удобно)) Только к этому надо придти.
Ваше высказывание, кстати, нарушает 6-ой стандарт 1С :-)
"Ваше высказывание, кстати, нарушает 6-ой стандарт 1С :-) "
- Мы теперь всю прессу стандартом считать будем?) Или только прессу от 1С? Это еще одна ваша идея?
з.ы. Ничего не имею против "изучать чужой опыт, но думать своей головой". Только я не вижу смысла воровать колизей)) Есть правила, вполне удобная база которой надо следовать. А не заниматься фигней, вводя в заблуждение неопытную публику. За публикацию - минус.
В обработке Диадок переходим в настройки. Нажимаем на кнопку "сохранить шаблон подключаемого модуля на диск" (лучше заранее сохранить пустую обработку и ее выбрать). Путь к файлу я делаю через сетевую папку.
Получаем обработку шаблон.
Переходим в модуль обработки. Нас интересует функция ОбработкаСобытияПодключаегогоМодуля()
А в ней нужно разкомментировать событие ПослеОбновленияКонтента
тип контента Utd820SellerContent это УПД. В УПД как правило я больше всего вношу изменеий перед отправкой.
Столкнулся с проблемой невозможности подключить отладку в данном модуле.
Поэтому допилим костыль сохраним в текстовый файл Структуру Параметры.Content
А потом в другой обработке в отладчике уже посмотрим содержимое этой структуры. В этой структуре и нужно менять данные. Чтобы УПД на сайт Диадока выгрузилась в измененном виде.
1С:Комплексная автоматизация 2 (2.4.9.98)
Платформа 1С:Предприятие 8.3 (8.3.16.1148)
Специальные предложения
Их обработка неудобна для отладки (пользуемся PRO версией, а все доп объекты интегрированы в базу), т.к. постоянно вызывается разные методы из макетов, каждый из которых представляет собой внешнюю обработку. Да и вклиниваться на уровне сбора данных мне тоже не хотелось, уж больно длинную цепочку потом прослеживать.
Тогда я просто вклинился в эту процедуру в модуле объекта обработки:
и уже там напрямую добавлю/заполняю те поля, которых мне не хватает для отправки УПД.
А выклинился в нее т.к. это уже конечный результат сборки документа непосредственно перед самой отправкой.
Кстати, если поставить в настройках обработки флаг откладки (Шестеренка - Настройки - Сервисные функции - Режим отладки), то обработка перед получением модулей из макетов будет искать их в директории libs, рядом с файлом обработки диадок про. В эту папку нужно будет посохранять модули из макетов в одноименные файлы. После этого можно будет проваливаться в эти модули в режиме отладки.
Конечно, на днях набросаю инструкцию в картинках. Сейчас как раз интегрируемся, сам долго не мог понять как они там у себя отлаживают, пока не наткнулся в модулях на эту особенность))
(3)
При каком действии срабатывает данный подключаемый модуль, при отправке? Если не сложно, напишите, пожалуйста, наименование ключей структуры отвечающих за строку 5а
Как-то дошёл в их модуле до момента, где они подтягивают свои xml-схемы, и бросил это дело, так как не было уверенности, что на своём сервере они не принимают файлы по своим же форматам, и что изменённый xml пройдёт.
Нет с этим проблем?
У кого-то работают в версии Про события из ТиповойМодульДиадокУФ в подключаемом модуле? Посмотрел в отладчике подключаемый модуль отключен , кэш не доступен в контексте этой обработки.
(9) Разобрался и решил проблемы с дополнением данных контента в событии ПодготовитьЭлектронныйДокумент. Оно вызывается дважды до стандартного заполнения и после него. Параметры.Свойство("Результат_ИМ") указывает, что результат заполнен. Но вызов событий из ТиповойМодульДиадокУФ и вложенных модулей хотелось бы реализовать. Надо переопределить текст запроса данных из РТУ. Пока решил изменением встроенного модуля, но в Диадок стандарт это решал добавлением вызова ПМ и из него передавал текст запроса.
Коллеги, кто может подсказать в каком виде модулю нужно передавать коды маркировки для УКД? Нужен пример подготовки массива с кодами. По УПД все хорошо, но с УКД не понятно. Или если это где то описано то где?
(11) Получилось указать коды маркировки в УКД?
Там есть поля
OriginalItemIdentificationNumbers
CorrectedItemIdentificationNumbers
Заполняю по аналогии с УПД, но маркировка все равно не уходит
Подключаю обработку ДиадокПРО 4.5.29 для конфигурации "ДАЛИОНТренд"
Отладка включается в режиме предприятия при нажатии на галочку ОТЛАДКА. Обработки выгружаются в каталог (лучше на сервере) "\\ИмяКаталогаОсновногоМодуля\libs". Сюда выгружаются обработки из макетов ____ВложенныеФайлы____ . Здесь вроде всё понятно. Но стоит задача, а как отладить обработку Модуль_ИнтеграцияУниверсальный, которая хранится в одном из макетов ТиповойМодульДиадокУФ(Модуль_ДиадокУФ). Сейчас я это сделал и попробую описать. Мне это нужно было для конфигурации "ДАЛИОНТренд".
// Может напишу что-то лишнего или не допишу что-то важного, не судите строго
1. В подключаемом модуле верну мою конфу
2. В обработке Модуль_ДиадокУФ необходимо определить мою конфигурацию "ДАЛИОНТренд":
Вроде после таких махинаций правильно определяется конфигурация и это хорошо. Проверим:
[img]C:\fakepath\метеданные далион.PNG[/img]
3. Необходимо указать КаталогМодулейСервера, по сути каталог где хранится основная обработка diadocPro. Для отладки напишите РежимОтладкиСервера = ИСТИНА
4. Здесь я определяю как должна действовать моя обработка "Модуль_ИнтеграцияУниверсальный"
5. И самое основное, в каком месте я переопределяю ВнешняяОбработкаМодуль_ИнтеграцияУниверсальный.ИспользуемоеИмяФайла. Это здесь:
Здесь создается обработка в каталоге:
Результат.ИспользуемоеИмяФайла = "\\МойСервер\Диадок Про\include\Модуль_ИнтеграцияУниверсальный.epf" - это то, что мне нужно для отладки
Все обработки хранятся в переменных Кэш и ОбщийКэш в модулях
Пожалуй, прикреплю я свою обработку сюда
ПМ_ТорговыеСети - мой подключаемый модуль
ТиповойМодульДиадокУФ.epf - хранится в \\. \ТиповойМодульДиадокУФ.epf и скачивается в каталог при нажатии режима ОТЛАДКИ в основной обработке
Читайте также:
- Устройство не авторизовано для чтения содержимого adobe drm
- Где находится офис эксель болт
- Как обновить яндекс браузер на телефоне айфон
- Диагностика работоспособности компьютерной системы с помощью системы bios
- Программа для ограничения заряда батареи ноутбука