0. ellavs 644 07.04.19 00:10 Сейчас в теме

О расширениях замолвите слово...

О чём стоит задуматься при принятии решения о создании расширения конфигурации…

Перейти к публикации

Вознаграждение за ответ
Показать полностью
Лучшие комментарии
37. Darklight 19 08.04.19 11:53 Сейчас в теме
За статью спасибо. Но, напишу свои замечания к Вашим предложениям:

1. Не дробить расширения для одного и того же объекта конфигурации
Дельный совет. Но я бы пошёл бы ещё дальше - ВООБЩЕ НЕ ДРОБИТЬ расширения - т.е. если какую-то конфигурацию. поддерживает команда разработчиков с разными проектами - они могут вести их в отдельных расширениях в своих тестовых базах и отдельных хранилищах конфигураций расширений (но это тоже не обязательно - можно вести всё в одном расширении/хранилище)
А перед установкой в рабочую базу (вернее в продакшен-конфигурацию, возможно так же имеющую своё отдельное хранилище) переносить изменения из разных конфигураций-расширений - в одну (дабы сравнение-объединение для конфигураций-расширений вполне нормально работает) - если их несколько или так и подключать к продуктивным базам единое расширение (если оно сразу был одно). То есть - сводить все свои доработки, в итоге, к одной конфигурации-расширения (ну, максимум к 2-3 - если уже очень приспичит) и подключать ко всем ИБ.

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

2. Изменения расширяемых форм делать программно
Тоже дельный совет. Он касается не только расширений. Увы, даже в управляемых формах и без расширений надёжнее все изменения вносить программно. Эх... жаль-только, что нет возможности писать программные макросы, которые отработают ещё на стадии компиляции в конфигураторе - один раз внеся изменения в форму - а не каждый раз при её создании в runtime.
Ну и фреймов не хватает - ведь один раз так перенести элементы в программный код это не страшно. А если их постоянно приходится модифицировать - это дальше чаще придётся уже работать исключительно с программным текстом, а нес формой.
И ещё есть сложности - порой при добавлении новых элементов на форму приходится перемещать имеющиеся - это самое неприятное. Впрочем это может быть чревато большими проблемами при любом подходе: и программном и при изменении на самой форме.

3. Минимизировать использование аннотации &Вместо
Конечно, с приходом аннотации "&ИзменениеИКонтроль" использование "&Вместо" должно существенно сократиться, но 15- релиза ещё нет даже в бете. Ну а далее - боюсь всё-равно будет куча проблем с сопровождением - там время покажет, пока ещё нечего даже пощупать.
Но, сам формат данной аннотации - мне уже сейчас не нравится - идея хорошая - исполнение отвратительное (Увы это норма для 1С).
Лучше бы парадигму аспектного программирования в 1С привнесли - вот это был бы прорыв.

4. Делать независимые друг от друга расширения
Совет был бы дельным. Но, я уже написал, в самом начале, что лучше вообще делать одно расширение (или пару - полностью независимых друг от друга). Иначе - будут проблемы другого рода - если разные расширения имеют общую основу (как общие модули, так и другие метаданные) - то если их делать полностью автономными - то - эти общие элементы будут в них дублироваться от того сразу ряд проблем:
а. Дублирование кода и метаданных - нужно будет во всех расширениях вручную поддерживать его актуальность - особенно сложно, когда его будут менять в разных проектах и разные команды.
б. Дублирование метаданных так же вызовет конфликт дублирования имён - при установки таких автономных расширений в одну ИБ. Да, конечно же - придётся
разграничивать их все префиксами разными расширений
в. Дублирование метаданных, сохраняемых в СУБД - вообще, можно сказать, невозможно, в большинстве случаев
г. Дублирование да даже не сохраняемых в СУБД метаданных - может быть проблемным - когда, скажем, нужно будет иметь расшаренные глобальные перенные
(параметры сеанса пока расширения вообще не поддерживают - в 14 релизе).
д. Дублирование метаданных приведёт ещё и к дублирование прав доступа к ним (ролей) - настройка прав превратится в хаос.
е. Дублирование перехватчиков событимй (да и просто вызовов функций), реализующих одну и ту же логику - создаст ещё больший хаос.
ж. И отдельно упомяну о том, что многие алгоритмы нуждаются в настройках - их где-то надо хранить - плрохая идея дублировать один и тотжемеханизм работы
с настройками для каждого расширения - ведь его ещё и настраивать придётся в отдельных автономных формах.
В общем, проблем много. Лучше всё-таки все свои изменения вести в одном расширении. Как я написал выше - можно сначала вести отдельные расширения, в и т.ч. создавать общие-расшаренные (ну тут тоже желательно не плодить много таких общий расширений) - а потом всё переносить в одно (сравнением/объединением), без дублей - его уже ставить в продакшен-базы.

5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию
Может и дельный совет. Пока расширения не поддерживают всех объектов метаданных. Но тут главная проблема именно в том, что приходится разделять проекты на части - что будет размещено в расширениях, что в нужно будет разместить в основной конфигурации. Жить с этим вполне можно - но очень неудобно. Но, пока без этого вообще не обойтись. Самое неприятное, что нельзя предопределённые элементы вот так нормально добавить, и не бояться их потерять. И с расширением составным типов всё тоже не очень гладко.

6. Вести реестр расширений
Совет дельный, но делать это очень не удобно. Увы - с документированием конфигураций в 1С Предприятие 8 всё очень печально. А вести в отдельном приложении - не очень удобно. Разве что только настраивать GIT и подключать сторонние приложения для решения вопросов документирования уже к GIT-депозитарию -- но это очень не простой путь для 1С разработчиков.
Вести в OneNote - тоже как-то не очень удобно (лично сколько раз порывался - но так и не смог полюбить OneNote - мне не удобно, но, возможно, я просто не научился его готовить).
Ввёл, как-то в отдельной кустарной конфигурации (ещё до появления расширений - для фиксации доработок обычных конфигураций) - это даже как-то удобнее было (метаданные автоматически туда подтягивались фоновым процессом - та же был учет задач и проектов - нужно было только подцепить метаданные к уже имеющимся там задача и всё) - но такую конфигурацию нужно разрабатывать себе самостоятельно - под свои предпочтения и свой учет планирования работа ИТ-отдела.
Mi4man; jif; davdykin; kostas; dvpk1c; user1183297; VladC#; YPermitin; Il; Vladimir Litvinenko; +10 Ответить
79. 77dream77 170 10.04.19 12:59 Сейчас в теме
использую расширения на проектах давно (более 2 лет), даже читал курсы по ним 😊
Из последнего проекта перехода с КА 1.1 на КА 2.4 - там все изменения сделаны через расширения (41 расширение), в конфигурации только новые объекты/реквизиты и одно изменение кода из-за нежелательности применения расширения в данном случае. Было 3 обновления с начала года - никаких проблем
много расширений настраивал для типовых ЗУП, БП, Итилиума, КА, ДО
Много расширений приходится переделывать после других, если неправильно настроены – то они валятся после очередного обновления.
при правильной настройке расширения - очень удобный и стабильный механизм, нужно просто понимать что можно делать через расширение, а что нет

к статье я бы добавил следующее:
1. полностью согласен, для одного объекта/формы отдельное расширение.
одно расширение опасно тем, что при ошибке подключения теряется весь функционал, который заложен в нем
а при отдельных расширениях только небольшая часть отключается и его можно будет легко поправить
2. да, лучше делать программные изменения
но новые элементы формы я обычно добавляю на форму в редакторе. Для них обязательно использую префиксы, новые группы с префиксами и никогда не изменяю типовые реквизиты на форме, только программно
проблем пока не было
3. согласен, аннотация Вместо - это крайний случай и часто бывают проблемы с расширением после обновления, но есть и плюсы…
Последний раз ее применял для доработки печати ТТН и УПД.
Вместо вызывает типовую процедуру получения данных, которая возвращает результат запроса
Этот результат выгружается в ТЗ, обрабатывается, добавляются новые колонки с данными при необходимости и помещаются обратно в результат.
Таким образом при изменении типовой процедуры ничего не сломается даже при изменении запроса или колонок результата, а дальше в коде я ориентируюсь на свои добавленные колонки, которые тоже останутся и не мешают работе типовой.

4. согласен, но если функционал как-то пересекается, то можно общий функционал вынести в отдельный общий модуль конфигурации, например.
Здесь все зависит от решаемой задачи.
5. да, я пока тоже не доверяю хранение важных данных расширению, добавляю новые объекты в конфигурацию.
6. отдельного реестра не веду, все описание в комментариях в расширении или в отдельном макете.
Но для удобства анализа версии расширений – использую реквизит Версия, в него записываю последнюю дату редактирования расширения, например, 10.04.2019
Таким образом при большом количестве расширений очень удобно понимать в какой базе какая версия и переносить изменения, например, из копии в рабочую. Присваивать просто номер версии типа 1.1 неудобно, потому что не известно какая версия последняя, а с датой всегда понятно.

Также после окончательной готовности расширения удаляю все не используемые реквизиты/объекты, отключаю все не нужные для меня зависимости и контроли, добиваюсь, чтобы проверка конфигурации расширения не выдавала ошибок.
Таким образом в расширении остается только измененные и важные для расширения объекты с отключенными контролями и т.п.
При обновление обязательно проверяю все расширения на применимость и еще раз запускаю проверку конфигурации, если она выдает ошибку – ищу причину и устраняю. Таким образом после обновления можно быт спокойным, что на следующий день рабочая будет стабильна и тебя не засыпят ошибками пользователи.
Из недавнего – в КА 2.4 изменилось название документов с ПоступлениеТоваров на Поступление товаровНаСклад, а оно использовалось в двух расширениях в проверке типа и в запросе. Проверка конфигурации естественно выдало эту ошибку, и я ее исправил сразу после обновления до наката на рабочую. Если бы не делал такую проверку, то на следующий день два важных функционала отвалилось бы с ошибкой и утро началось бы не с кофе…
bazelyukandrei; Angealtor; AllexSoft; o.nikolaev; Krio2; worker1c; ellavs; +7 Ответить
73. rpgshnik 1733 10.04.19 07:23 Сейчас в теме
Хорошая публикация. Расширения использую. Фактически самостоятельно пришел к тем же рекомендациям/правилам:
1. Не дробить расширения, где-то слышал сплетни, что несколько расширений - тормозят базу, а одно нет. По этому одно расширение на одну конфигурацию, желательно конечно!
2. Изменять свойства элементов форм программно, согласен.
3. Минимизация использования директивы &Вместо это вообще святое, уже не однократно черпнул горя. Надеюсь директива &ИзменениеИКонтроль поможет в этом, но практика показывает, режим совместимости на типовых конфигурациях очень сильно не успевает за актуальной рабочей версией платформы. Когда она будет? Через год, минимум наверное :)
4. Независимые расширения, это наверное правило а не рекомендация. Да и вообще пункта 4 не должно быть, учитывая пункт 1 :)
5. Все новые объекты строго в основной конфигурации, удаление расширения явно приведёт к потере данных. Тем более создание новых объектов ни как не повлияет на обновление. А уже обработка их на форме и т.п. строго в расширение. Так же слышал по сплетням, что общие модули так же лучше создавать в основной конфигурации и якобы длительные операции значительно быстрее отрабатывают в основной конфигурации, а не в расширении.
6. Реестры доработок в целом для всего это плюс.
ids79; kostas; Interrupted; lefthander; ellavs; +5 Ответить
90. e-tixom 10.04.19 21:13 Сейчас в теме
(0) (86) Хорошая статья. Спасибо.
У нас Бухгалтерия 3.0. На расширении сделана целая подсистема со своими справочниками и документами. https://infostart.ru/public/956446/ Сначала были опасения о потере данных, но было условие не менять конфигурацию. Рискнули. Пока все нормально. Были глюки с установкой обновлений, кажется февральских. Приходилось отключать расширения и после загрузки конфигурации закрывать конфигуратор и продолжать обновлять уже в пользовательском режиме. Но сейчас проблема ушла. В принципе, расширения - довольно хороший инструмент. Среди плюсов также можно также отметить возможность использования его для отладки, например, новых печатных форм или отчетов.

Из проблемных ситуаций могу отметить:
1. никогда не получалось динамическое обновление расширений и подключение новых при работающих пользователях. Возможно это был глюк платформы или релиза, но я больше не рискую: быстрота не стоит возможной потери данных. Лучше как положено: архив и т.д. ...
2. В формах списков добавленных справочников и документов отсутствует стандартная команда "вывести список". Создавала даже тему на форуме https://forum.infostart.ru/forum29/topic204577/ . Но решение не известно (по крайней мере мне).
3. В добавленных документах нет стандартных кнопок "Дт Кт" и "Структура подчиненности" (соответственно они не отображаются в структуре подчиненности объектов основной конфигурации). Допилить, конечно, можно, но уже с помощью своих кнопок.
Yashazz; ellavs; acanta; +3 Ответить
92. dsdred 1242 12.04.19 11:28 Сейчас в теме
45. nagimo 2 08.04.19 13:19 Сейчас в теме
Спасибо.
Очень полезная статья!

насчет Используете ли Вы расширения в своей работе?
Использую. Я их фанат! )) Очень доволен. Но в основном использую в небольших организациях.

Из проблем:
1. Действительно, после каждого обновления приходится пока актуализировать заимствованные формы. Думаю воспользоваться советом и формировать их программно. Хотя в большинстве случаев обхожусь дополнительными реквизитами формы без изменения самой формы.
2. Так и не связал их с хранилищем 1С.
3. Постоянно забываю про проблему с конструктором запроса - сначала ступор - почему нет большинства объектов конфигурации, и только потом доходит, что это же расширение. Приходится делать лишние движения с вызовом конструктора из обработки или кода основной конфигурации.
4. Периодически (но вообще не часто) приходится переписывать некоторые наследованные процедуры - когда меняется состав аргументов. И это не только для процедур с оператором &Вместо.
Остальные комментарии
Избранное Подписка Сортировка: Древо
1. user-z99999 22 07.04.19 00:29 Сейчас в теме
5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию.

Это совет для какой платформы 1С?
8.3.13 кажется всё хорошо с этим. К тому же, должны быть бэкапы, если переживаете за сохранность данных.

Второй момент, получится ли обновить конфигурацию снятую с поддержки с возможностью изменений - скриптом, когда баз много?
Чтобы не программист 1с нажимал кнопки?
11. ellavs 644 07.04.19 10:26 Сейчас в теме
(1) да, разработчики сделали многое в направлении безопасного хранения данных в расширениях, у нас пока побаиваются, поэтому в нашем случае - всё хранение только в конфигурации. Я честно предлагала попробовать, но руководство отказывается.
31. A_kryl 138 08.04.19 08:25 Сейчас в теме
(1) А пробовали запросы например писать из основной конфы к реквизиту расширения, или код какой? или внешний отчет/обработку? Мне показалось крайне неудобно, может какой то фокус есть с настройкой? пока вижу новые объекты только для полностью независимого от основной конфы расширения.
32. dock 35 08.04.19 08:43 Сейчас в теме
(1)
Второй момент, получится ли обновить конфигурацию снятую с поддержки с возможностью изменений - скриптом, когда баз много?
Чтобы не программист 1с нажимал кнопки?


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

Второй вариант - обновление из хранилища.Но обновлять из хранилища рабочие базы... Ну это если один разработчик держит все эти базы :)

З.Ы. не все комменты внимательно прочитал, но при беглом просмотре не увидел ответа на данный вопрос :)
33. acanta 74 08.04.19 08:50 Сейчас в теме
(32) На рабочей базе без возможности изменения? А если придет другой разработчик, он сможет включить возможность и выполнить доработки?
2. Dream_kz 93 07.04.19 05:38 Сейчас в теме
0. Не использовать расширения, так как это кривой механизм, который работает неизвестно как
maksa2005; bsturtle; Mi4man; MSK_Step; sergathome; paybaseme; AnddnA; frkbvfnjh; Evg-Lylyk; asupsam; triviumfan; Soloist; Vladimir Litvinenko; +13 10 Ответить
3. peterxx 19 07.04.19 07:19 Сейчас в теме
(2)
так как это кривой механизм, который работает неизвестно как

Да бросьте уже нагнетать обстановку, ну или примеры кривизны в студию. Я, признаться, побаиваюсь еще добавлять данные в расширения, но что касается кода, особых претензий к механизму нет.
Рамзес; DolPew; OlgaKonyakhina; ellavs; +4 1 Ответить
12. Vladimir Litvinenko 1826 07.04.19 11:01 Сейчас в теме
(3)

Пример 1: https://t.me/ssl1c/18325
Пример 2: https://t.me/ssl1c/18731

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

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


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

Совет из этой публикации менять формы только программно - из той же области.


P.S.: Для Бухгалтерий и ЗУП-ов расширения хороши. Постоянная надёжность конфигурации не нужна, на исправление багов времени всегда достаточно. Ценность замочка на объектах метаданных высока по психологическим причинам )) Почему бы и нет )) Проблема только в том, что набив руку на нетребовательных к надёжности конфигурациях специалисты потом эти приёмы переносят на конфигурации, требующие больших модификаций и высокой надёжности, в том числе отсутствия косяков сразу после операции обновления, а не через неделю после вала сообщений от пользователей.
bsturtle; o.nikolaev; Danil.Potapov; kostas; AnddnA; sergathome; Dream_kz; +7 Ответить
42. triviumfan 10 08.04.19 12:30 Сейчас в теме
Поддерживаю.
(12)
особенно для нечётных релизов 8.3.11, 8.3.13 на которых обкатываются нововведения

Откуда инфа? Сторонник теории заговора релизов или офф. источник?
53. Vladimir Litvinenko 1826 08.04.19 14:23 Сейчас в теме
(42) Достаточно наблюдений за режимом совместимости ERP и сообщений о "детских" ошибках платформы на форумах, которых значительно меньше в четных релизах. На 8.3.11 багов и в конфигураторе было достаточно с незакрывающимися окнами и нераскрывающимися объектами в дереве метаданных ))


ERP 2.0 была в режиме совместимости 8.3.6, ERP 2.1 и 2.2 - 8.3.8 и 8.3.10, ERP 2.4 - 8.3.12. Аналогично конфигурации КА 2 и УТ 11. За бухгалтериями не следил, но подозреваю, что там аналогичная ситуация.

Официально заявлений о том, что функционал нечетных релизов "сырой" мы конечно нигде не увидим, да и вообще всё это неправда, и, как Вы написали, несостоятельная теория заговора )) Может быть там внутри 1С другие причины так между релизами переключаться. Но наиболее вероятно, что ERP на 8.3.15 с директивой в расширениях &ИзменениеИКонтроль мы не увидим. Надо будет ждать режима совместимости с 8.3.16.
AllexSoft; gregoryz; +2 Ответить
56. triviumfan 10 08.04.19 16:08 Сейчас в теме
(53) Ясно, тогда это всего лишь стечение обстоятельств и некий "пук", услышанный на сарафанном радио/ОБС.
58. Vladimir Litvinenko 1826 08.04.19 18:13 Сейчас в теме
(56) При отсутствии официальной информации нужно полагаться на наблюдения и практику и находить чёткие закономерности. Потом можно к удивлению обнаружить подтверждение того, что это не просто наблюдение, а "политика партии", где-нибудь на партнерском форуме или в презентациях 1С ))
kostas; sergathome; +2 Ответить
104. MSK_Step 19 18.07.19 19:05 Сейчас в теме
(42)Разработчики 1с на конференции так говорят, что нечетные номера - это тест версии
26. Dream_kz 93 08.04.19 07:54 Сейчас в теме
(3) Ну вот, данные не добавляете, а просите примеров. Лезем на партнерский форум, либо на багбоард, и смотрим ошибки по расширениям.
Понятно, что для простых изменений (форму подправить и т.п.), все нормально работает, а вот что-то сложное, ну такое.
sergathome; +1 Ответить
106. Crazy_kz 19 19.07.19 08:40 Сейчас в теме
(3) УТ 11, добавил в расширение документ "Реализация товаров услуг" перестала формироваться структура подчиненности документов.
6. insurgut 196 07.04.19 09:27 Сейчас в теме
(2) Может вы просто не умеете их готовить? С переходом на расширения я уже и забыл, когда снимал с поддержки типовые конфигурации. Много чего снятого с поддержки поставил обратно на поддержку, перенеся доработки в расширение. Полет нормальный :)
o.nikolaev; kit; elvira17; Jeka44; Риник; ids79; mvxyz; ellavs; +8 Ответить
19. vcv 86 07.04.19 13:25 Сейчас в теме
(6) Или готовить не умеем, или у вас изменения мелкие. У меня сейчас проект по ЕРП. От расширений отказались, проблем много было. Хотя изменений типовой конфы не так много - десяток документов, десяток справочников, пара десятков общих модулей...
o.nikolaev; kostas; sergathome; AnddnA; triviumfan; Vladimir Litvinenko; +6 Ответить
21. noprogrammer 191 07.04.19 14:16 Сейчас в теме
(19) Можно озвучить проблемы с которыми столкнулись при использовании расширений? интересны именно проблемы (причины отказы от расширений). У нас в расширения вынесены следующие контуры (меркурий,егаис,онлайн-кассы и много чего еще)

В статье по большому счету о проблемах ни слова. А проблемы действительно есть, хотя и многие из них решаются.

Самая большая их них - расширения ничего не знают о типах расширяемой конфигурации (как впрочем и о других расширениях), как следствие невозможно в расширениях использовать тип "ЛюбаяСсылка" (так же как и типы других расширений).
Другими словами невозможно использовать "критерии отбора" т.е. структуру подчиненности через стандартных механизм критериев отбора уже не получить,
как вариант можно использовать Структура подчиненности

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

Есть в расширениях замечательная опция "Активно", вот только отключить ее не всегда есть возможность, точнее отключить то ее можно, но вот если есть заимствованный регистр накопления и добавленный новый документ который участвует в движении по этому регистру то увы и ах провести документ не удастся ибо выйдет вот такая шибка:

Работа с таблицей невозможна. Структура таблицы несовместима с текущими расширениями конфигурации.
27. Dream_kz 93 08.04.19 07:58 Сейчас в теме
(6) Возможно, но какие доработки у вас перешли в расширения? Добавьте справочник, регистр, а потом с радостью узнайте что при обновлении потеряются данные.
При обновлении доработанных конфигураций у меня тоже проблем не наблюдается, движения делаются по подпискам, формы меняются программно через переопределяемые модули, отчеты/обработки через механизмы БСП.
kostas; sergathome; +2 Ответить
103. MSK_Step 19 18.07.19 19:04 Сейчас в теме
(2)+++ , при грамотной доработке, намного лучше, чем расширения
4. МимохожийОднако 129 07.04.19 08:13 Сейчас в теме
По поводу документирования. В расширения можно добавить объект, хранящий историю изменений и документацию.Например, в виде макета.
Это не исключает копирование этой информации в отдельное место, но позволяет при работе с расширением сразу же получать нужную информацию. Я такое использую во внешних обработках и отчетах, добавляя текстовый макет История.
Для сложных случаев там же храню описание задачи (ТЗ), которая решалась в данной разработке
AllexSoft; o.nikolaev; Deslime; AndrewKop; _Farsh_; Doom2w; mondordom; Aleskey_K; Jeka44; nagimo; lefthander; A_Max; cherptat; NightAngel; ids79; frkbvfnjh; Leon29; PowerBoy; DNN13; andreich_ru; mvxyz; tormozit; ellavs; +23 Ответить
8. ellavs 644 07.04.19 10:21 Сейчас в теме
(4) Хорошая идея, спасибо.
105. MSK_Step 19 18.07.19 19:06 Сейчас в теме
(4)а просто хранить документацию к нас не умеют, это все печально.
5. insurgut 196 07.04.19 09:26 Сейчас в теме
Все по делу. Жаль только конструкцию &Вместо все-таки приходится использовать :(

По п.5 можно ещё максимально продумать структуру дополнительных данных - может можно обойтись дополнительными и реквизитами и сведениями? Хранение их так же безопасно и не требует снятия конфигурации с поддержки.
o.nikolaev; ellavs; +2 Ответить
9. ellavs 644 07.04.19 10:23 Сейчас в теме
(5)
Жаль только конструкцию &Вместо все-таки приходится использовать

Новая аннотация &ИзменениеИКонтроль частично должна решить этот вопрос...
7. vcv 86 07.04.19 10:09 Сейчас в теме
Главная проблема расширений - это режим совместимости в типовых. В Документообороте, например, 8.3.8 :(
Aleskey_K; Jeka44; Kamali; dsdred; ellavs; +5 Ответить
10. ellavs 644 07.04.19 10:24 Сейчас в теме
(7) Да, есть такое. Очень хочется использовать новшества платформы в области расширений, а не получается (
13. Vladimir Litvinenko 1826 07.04.19 11:31 Сейчас в теме
(7) Главная проблема - это отсутствие трехстороннего сравнения/объединения и сокрытие от релиз-инженера информации о том, что наши алгоритмы требуют адаптации к новому релизу типовой конфигурации. Возможность завершить объединение не зная о том, что надо изменить наши алгоритмы.
AllexSoft; +1 Ответить
14. ellavs 644 07.04.19 11:47 Сейчас в теме
(13) как вариант новая аннотация &ИзменениеИКонтроль частично может помочь (естественно, если есть возможность использовать платформу 8.3.15). Там автоматически происходит проверка на изменение кода заимствованных модулей и оповещение, если произошли изменения.
15. Vladimir Litvinenko 1826 07.04.19 12:08 Сейчас в теме
(14) Да, это поможет выявить проблему. Но:

1) Система сообщит "ваш метод требует адаптации", но что именно адаптировать нам придётся узнавать самим. Трехстороннее сравнение/объединение придётся организовывать самим, например выгружая все версии кода в файл и применяя внешние инструменты или делая попарное сравнение файлов в 1С. Кто будет с этим заморачиваться? Скорее глазами по тексту пробегать будут, что повышает риск ошибки. На небольших примерах в "Зазеркалье" всё выглядит красиво. А если метод на 300-500 строк и код разделён большими блоками запросов? Так часто бывает в типовых.

2) &ИзменениеИКонтроль появится в 8.3.15. А значит для того же семейства конфигураций ERP/КА/УТ станет доступно только в 8.3.16 где-то через год. На "пробную" нечетную платформу их переводить не будут. Ждать ещё долго. А расширения массово лепятся как снежки уже сейчас, без всяких аннотаций &ИзменениеИКонтроль.


Не говоря уже о ставших популярными шутках на счёт необходимости применять беспощадные аннотации &КонецУдалить и &КонецВставить совместно с &ИзменениеИКонтроль ))
AllexSoft; sergathome; ellavs; +3 Ответить
17. ellavs 644 07.04.19 12:46 Сейчас в теме
(15) тут соглашусь. Как в том анекдоте про пожарных. Как обновление, так хоть увольняйся )) приходится брать из реестра все блоки модулей, помеченные как наследуемые &Вместо, и ручками каждый проверять. Хорошо хоть в конфигурации, с которой чаще всего работаю, подняли совместимость до 8.3.12. Так и до 8.3.15 недалеко, может &ИзменениеИКонтроль хоть немного облегчит труд.
36. Darklight 19 08.04.19 10:48 Сейчас в теме
(7)Режим совместимости можно повышать вручную (не дожидаюсь когда он повысится вендором конфигурации):
1. Обычно это не вызывает больших проблем - всё быстро можно урегулировать
2. Но возникают некоторые дополнительные сложности при установке апдейт-обновлений - но, обычно, тоже нет больших сложностей
3. Главное при апдейте обновления от вендора не забыть о том, что режим совместимости надо поправить снова (у корня конфигурации)
4. Ну, и сначала надо на копии тестировать - выявить косяки, поправить и переходить потом к рабой базе (бэкап обязателен)

Мы так повышали уровень совместимости и для документооборота и даже для УПП - где без повышения уровня совместимости, например, расширения вообще не будут доступны. Ничего страшного в этом нет - но проблемы всё-равно решать придётся.
123. Terve!R 05.11.19 12:04 Сейчас в теме
(36) а можно озвучить с какими примерно проблемами придется столкнуться и сколько по времени у вас уходит на адаптацию?
124. Darklight 19 05.11.19 12:28 Сейчас в теме
(123)Давно это было, уже не помню, при обновлении уже сейчас нет больших проблем (разве что много изменений показывает - которых либо вовсе нет, либо какая-то ерунда и надо просто взять версию поставщика), только при переходе были проблемы.
В основном проблемы были с именами полей метаданных и функций - в новых версиях конфигураций появляются новые встроенные или появляются просто запрет какого-то имени - и возникает конфликт, когда в конфигурации это имя использется -чаще все го нужно просто везде переименовать (дабы платформа сейчас это легко позволяет автоматизировать).
Вроде как с регистрами (вроде сведений_ были какие-то траблы - не реструктуризировались (парочка - но это индивидуально) - пришлось их выгружать, очищать и потом загружать.

Не бойтесь сами посмотреть - сделайте копию и на ней проверьте. Рекомендую только делать всё на серверной базе и менять режим совместимости поэтапно (по одной версии) - делать реструктуризацию - как при обновлении.
А в конце на копии запустить перепроведение всех документов. Ну и РИБ перенастроить заново и проверит (конфигурацию придётся так же по частям переносить в другой узел, возможно через РИБ не пройдёт - придётся вручную переносить) - если используете.

Поищите на инфорстарте - тут вроде были статьи на то как перейти на версию совместимости с поддержкой расширений для старых конфигураций
16. YPermitin 5794 07.04.19 12:13 Сейчас в теме
(0) хорошая статья.

Иногда вижу применение расширений необдуманно на столько, что они напоминают оператор GOTO.

Но сам механизм хороший, если разумно подходить.
18. ellavs 644 07.04.19 12:47 Сейчас в теме
(16) Спасибо. Сложно всё обдумать наперед. Столько на грабли наступили уже, пока более-менее пришло какое-то понимание.
20. andryandry 37 07.04.19 14:12 Сейчас в теме
Поделитесь опытом кто как борется с такой проблемой - в конструкторе запросов в расширении не доступны системные ревизиты добавленных в расширение справочников - например "Владелец" или "родитель".
Сам ставлю времмено реквизит "ссылка", потом меняю руками в тексте модуля.
22. ellavs 644 07.04.19 15:49 Сейчас в теме
(20) честно говоря, даже не задумывалась об этом, т.к. не пользовалась конструктором в расширениях...
28. agent00mouse 194 08.04.19 08:09 Сейчас в теме
(20)
например "Владелец" или "родитель".

!!!Для этого нужно захватить форму списка.!!!

А теперь вопрос! ДЛЯ ЗАЧЕМ??!?!?! Если Я и так уже справочник захватил и его родителя или владельца!

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

По моему расширения годны пока только для модификации или замены чистого кода, не более.
34. andryandry 37 08.04.19 09:08 Сейчас в теме
(28) Да, спасибо за совет. действительно после захвата формы списка справочника в конструкторе запроса появляется родитель.

Я не сохраняю захваченные для построения запросов объекты в расширении ))) не переживайте.
43. lefthander 08.04.19 12:39 Сейчас в теме
(20)Я необходимый реквизит просто добавляю в объект. Потом можно будет его удалить из расширения.
57. andryandry 37 08.04.19 16:52 Сейчас в теме
(43) с родителем и владельцем такое не прокатывает
23. dsdred 1242 07.04.19 22:31 Сейчас в теме
Статья хорошая.
Из неудобств можно отметить работу с СКД и прочие запросы, но выход простой писать запрос либо в обработке, либо другим способом.
Раньше много было косяков в конфигурациях 8.3.8 например, отладку надо было с ключем "РежимОтладки" запускать, но сейчас с этим все хорошо.
Из последних Косяков, при переходе на платформу 8.3.12.1469 напарывался на описанное в данной теме https://forum.infostart.ru/forum9/topic191359/
24. oldcopy 122 08.04.19 01:33 Сейчас в теме
Из реальных косяков с расширениями мы столкнулись только в РИБ, когда расширение распространившись в базы фактически обрушило их работу. Это было крайне неприятно, хорошо что изменения уехали в ночь и хватились утром, успели все исправить до наплыва покупателей.
44. ildary 08.04.19 12:59 Сейчас в теме
(24) Не могли бы Вы подробнее сказать, что именно сломало расширение в РИБ? Мы сейчас планируем создавать расширения, распространяемые по РИБ и хотелось бы избежать проблемы как у Вас.
46. oldcopy 122 08.04.19 13:42 Сейчас в теме
(44)
Не могли бы Вы подробнее сказать, что именно сломало расширение в РИБ? Мы сейчас планируем создавать расширения, распространяемые по РИБ и хотелось бы избежать проблемы как у Вас.


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

Самое гадкое в этом то, что расширение сломало типовой механизм обмена и "починить" базы РИБ просто удалив расширение из центрального узла не получится. Нам пришлось отвязывать базы от центрального узла, удалять в них расширение руками и привязывать заново. Хорошо что заметили это рано утром и магазинов было всего три.

Конфигурация: Розница 2.2.1.24, платформа 8.3.13.1690
Прикрепленные файлы:
47. ildary 08.04.19 13:46 Сейчас в теме
(46) то есть главная особенность Вашего расширения - добавление данных (а не только изменение текущих)? Мы пока не планируем добавлять что-то новое в расширение, а в первую очередь только для оперативных патчей (очень много баз и цикл обновления довольно тяжелый из-за выгоняния пользователей).
25. krollzlat 08.04.19 07:54 Сейчас в теме
У нас одно расширение, и плодить не хочется. Как писали выше уже и забыли когда конфигурацию трогали...Более 100 новых объектов методанных, с данными проблем нет. Была недавно забавная проблема, сняли совместимость, добавили в расширение план обмена и изменили состав типового.Но потом пришлось откатить совместимость, из расширения удалили изменения по планам обмена, но оно все равно ругалась что такие объекты есть.Решили какими то танцами.
107. s22 19 19.07.19 11:34 Сейчас в теме
(25)
план обмена
а как решили? использовали типовую синхранизацию?
и как создавать Регламентированные задания?
29. oberonm 9 08.04.19 08:18 Сейчас в теме
Были косяки на первых расширениях, Доработки в ДО. более 150 пользователей онлайн.
1. в локальной сети всё работало стабильно
2. Тонкий клиент и web с удаленными пользователями происходили ошибки из серии "Ошибка разбора XML" при открытии формы с расширением. Ошибки происходили нерегулярно. раз-два в день. у некоторых пользователей.

в итоге, пока побаиваюсь работать с расширением когда пользователей более 100 пользователей и не все работают в одной локальной сети
30. ids79 4326 08.04.19 08:18 Сейчас в теме
Спасибо, хорошая статья.
"Из этой ситуации теперь есть выход. В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль,"
Не знал об этом.
38. Darklight 19 08.04.19 11:54 Сейчас в теме
(35)15-релиз пока ещё не вышел даже для ознакомоления
39. dsdred 1242 08.04.19 12:06 Сейчас в теме
(38)Знаю.
В статье упоминается особенность 8.3.15.

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

Пример использования директивы &ИзменениеИКонтроль (только с версии платформы 8.3.15)
40. Darklight 19 08.04.19 12:13 Сейчас в теме
(39)Я знаю, что Вы знаете. Но большинство не знает - т.к. данного релиза ещё нет в "свободном" доступе. От того и такие удивления.
92. dsdred 1242 12.04.19 11:28 Сейчас в теме
93. ellavs 644 12.04.19 11:44 Сейчас в теме
97. rpgshnik 1733 17.04.19 12:22 Сейчас в теме
(92) я ещё к 12...13... 14... не успел привыкнуть :))) ждём 8.4 чтоли уже :))
98. dsdred 1242 17.04.19 12:45 Сейчас в теме
(97)
ждём 8.4 чтоли уже

Дождемся ли? ;))
99. rpgshnik 1733 17.04.19 13:22 Сейчас в теме
(98) дождемся... дождемся и версию Х :)
37. Darklight 19 08.04.19 11:53 Сейчас в теме
За статью спасибо. Но, напишу свои замечания к Вашим предложениям:

1. Не дробить расширения для одного и того же объекта конфигурации
Дельный совет. Но я бы пошёл бы ещё дальше - ВООБЩЕ НЕ ДРОБИТЬ расширения - т.е. если какую-то конфигурацию. поддерживает команда разработчиков с разными проектами - они могут вести их в отдельных расширениях в своих тестовых базах и отдельных хранилищах конфигураций расширений (но это тоже не обязательно - можно вести всё в одном расширении/хранилище)
А перед установкой в рабочую базу (вернее в продакшен-конфигурацию, возможно так же имеющую своё отдельное хранилище) переносить изменения из разных конфигураций-расширений - в одну (дабы сравнение-объединение для конфигураций-расширений вполне нормально работает) - если их несколько или так и подключать к продуктивным базам единое расширение (если оно сразу был одно). То есть - сводить все свои доработки, в итоге, к одной конфигурации-расширения (ну, максимум к 2-3 - если уже очень приспичит) и подключать ко всем ИБ.

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

2. Изменения расширяемых форм делать программно
Тоже дельный совет. Он касается не только расширений. Увы, даже в управляемых формах и без расширений надёжнее все изменения вносить программно. Эх... жаль-только, что нет возможности писать программные макросы, которые отработают ещё на стадии компиляции в конфигураторе - один раз внеся изменения в форму - а не каждый раз при её создании в runtime.
Ну и фреймов не хватает - ведь один раз так перенести элементы в программный код это не страшно. А если их постоянно приходится модифицировать - это дальше чаще придётся уже работать исключительно с программным текстом, а нес формой.
И ещё есть сложности - порой при добавлении новых элементов на форму приходится перемещать имеющиеся - это самое неприятное. Впрочем это может быть чревато большими проблемами при любом подходе: и программном и при изменении на самой форме.

3. Минимизировать использование аннотации &Вместо
Конечно, с приходом аннотации "&ИзменениеИКонтроль" использование "&Вместо" должно существенно сократиться, но 15- релиза ещё нет даже в бете. Ну а далее - боюсь всё-равно будет куча проблем с сопровождением - там время покажет, пока ещё нечего даже пощупать.
Но, сам формат данной аннотации - мне уже сейчас не нравится - идея хорошая - исполнение отвратительное (Увы это норма для 1С).
Лучше бы парадигму аспектного программирования в 1С привнесли - вот это был бы прорыв.

4. Делать независимые друг от друга расширения
Совет был бы дельным. Но, я уже написал, в самом начале, что лучше вообще делать одно расширение (или пару - полностью независимых друг от друга). Иначе - будут проблемы другого рода - если разные расширения имеют общую основу (как общие модули, так и другие метаданные) - то если их делать полностью автономными - то - эти общие элементы будут в них дублироваться от того сразу ряд проблем:
а. Дублирование кода и метаданных - нужно будет во всех расширениях вручную поддерживать его актуальность - особенно сложно, когда его будут менять в разных проектах и разные команды.
б. Дублирование метаданных так же вызовет конфликт дублирования имён - при установки таких автономных расширений в одну ИБ. Да, конечно же - придётся
разграничивать их все префиксами разными расширений
в. Дублирование метаданных, сохраняемых в СУБД - вообще, можно сказать, невозможно, в большинстве случаев
г. Дублирование да даже не сохраняемых в СУБД метаданных - может быть проблемным - когда, скажем, нужно будет иметь расшаренные глобальные перенные
(параметры сеанса пока расширения вообще не поддерживают - в 14 релизе).
д. Дублирование метаданных приведёт ещё и к дублирование прав доступа к ним (ролей) - настройка прав превратится в хаос.
е. Дублирование перехватчиков событимй (да и просто вызовов функций), реализующих одну и ту же логику - создаст ещё больший хаос.
ж. И отдельно упомяну о том, что многие алгоритмы нуждаются в настройках - их где-то надо хранить - плрохая идея дублировать один и тотжемеханизм работы
с настройками для каждого расширения - ведь его ещё и настраивать придётся в отдельных автономных формах.
В общем, проблем много. Лучше всё-таки все свои изменения вести в одном расширении. Как я написал выше - можно сначала вести отдельные расширения, в и т.ч. создавать общие-расшаренные (ну тут тоже желательно не плодить много таких общий расширений) - а потом всё переносить в одно (сравнением/объединением), без дублей - его уже ставить в продакшен-базы.

5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию
Может и дельный совет. Пока расширения не поддерживают всех объектов метаданных. Но тут главная проблема именно в том, что приходится разделять проекты на части - что будет размещено в расширениях, что в нужно будет разместить в основной конфигурации. Жить с этим вполне можно - но очень неудобно. Но, пока без этого вообще не обойтись. Самое неприятное, что нельзя предопределённые элементы вот так нормально добавить, и не бояться их потерять. И с расширением составным типов всё тоже не очень гладко.

6. Вести реестр расширений
Совет дельный, но делать это очень не удобно. Увы - с документированием конфигураций в 1С Предприятие 8 всё очень печально. А вести в отдельном приложении - не очень удобно. Разве что только настраивать GIT и подключать сторонние приложения для решения вопросов документирования уже к GIT-депозитарию -- но это очень не простой путь для 1С разработчиков.
Вести в OneNote - тоже как-то не очень удобно (лично сколько раз порывался - но так и не смог полюбить OneNote - мне не удобно, но, возможно, я просто не научился его готовить).
Ввёл, как-то в отдельной кустарной конфигурации (ещё до появления расширений - для фиксации доработок обычных конфигураций) - это даже как-то удобнее было (метаданные автоматически туда подтягивались фоновым процессом - та же был учет задач и проектов - нужно было только подцепить метаданные к уже имеющимся там задача и всё) - но такую конфигурацию нужно разрабатывать себе самостоятельно - под свои предпочтения и свой учет планирования работа ИТ-отдела.
Mi4man; jif; davdykin; kostas; dvpk1c; user1183297; VladC#; YPermitin; Il; Vladimir Litvinenko; +10 Ответить
60. ellavs 644 08.04.19 22:26 Сейчас в теме
(37)
переносить изменения из разных конфигураций-расширений - в одну

хорошее предложение, но не всегда можно применять. Например, некоторые расширения у нас носят "сезонный" характер (например, используются только летом) и периодически "вырезать" их из одного большого расширения было бы не очень удобно.

так и не смог полюбить OneNote

Просто это один из моих любимых программных продуктов, поэтому не смогла удержаться и не упомянуть его ;)

По остальным пунктам во многом соглашусь.
63. Darklight 19 09.04.19 09:48 Сейчас в теме
(60)хорошее предложение, но не всегда можно применять. Например, некоторые расширения у нас носят "сезонный" характер (например, используются только летом) и периодически "вырезать" их из одного большого расширения было бы не очень удобно.

а. Как я написал - при ОЧЕНЬ БОЛЬШОЙ и ОБОСНОВАННОЙ ПОТРЕБНОСТИ - можно иметь 2 ну максимум 3 консолидированных расширения, реально мало связанных друг с другом (или одно общее-основное - и несколько дополняющих). Но это скорее исключение - когда это реально удобнее, чем всё в одномю

б. Для Вашего же примера - идеально подходя, как раз таки, опции настройки - которыми Вы будете включать/выключать функционал в ИБ по потребности (если его реально нужно выключать, т.е. он будет мешать не в своё время).
Для опций - просто заводите регистр сведений (лучше не периодический) и ПВХ (будут едины для всех расширений; константы расширения пока не поддерживают). И коде, через модуль повторного использования получаете и проверяете эти опции - и выбираете использовать или не использовать те или иные алгоритмы; отображать или нет те или иные элементы формы.
При желании - подключаете к этим регистрам - функциональные опции (но их расширения пока тоже не поддерживают - поэтому их придётся добавлять в основу. конфигурацию) - но я не вижу большой потребности в их использовании.

По поводу "OneNote"
Мне кажется настоящий разработчик на 1С в короткие сроки сделает куда более удобный инструмент документирования, чем "OneNote". Особенно, если уже возьмёт за основу какую-нибудь готовую конфигурации класса ITIL или класса ITSM, с поддержкой работы через WEB.
А потом ещё и с GIT её интегрирует или с другими WEB-ориентированными специализированными продуктами.
Но это просто моё мнение ;-)
41. Pr-Mex 124 08.04.19 12:24 Сейчас в теме
Разрабатываем и тестируем типовые конфигурации.
Расширения очень сильно помогают.
Иногда надо поле своё на форму добавить.
Иногда колонку вывести в форме списка.
Очень сильно выручают.
45. nagimo 2 08.04.19 13:19 Сейчас в теме
Спасибо.
Очень полезная статья!

насчет Используете ли Вы расширения в своей работе?
Использую. Я их фанат! )) Очень доволен. Но в основном использую в небольших организациях.

Из проблем:
1. Действительно, после каждого обновления приходится пока актуализировать заимствованные формы. Думаю воспользоваться советом и формировать их программно. Хотя в большинстве случаев обхожусь дополнительными реквизитами формы без изменения самой формы.
2. Так и не связал их с хранилищем 1С.
3. Постоянно забываю про проблему с конструктором запроса - сначала ступор - почему нет большинства объектов конфигурации, и только потом доходит, что это же расширение. Приходится делать лишние движения с вызовом конструктора из обработки или кода основной конфигурации.
4. Периодически (но вообще не часто) приходится переписывать некоторые наследованные процедуры - когда меняется состав аргументов. И это не только для процедур с оператором &Вместо.
54. lefthander 08.04.19 15:25 Сейчас в теме
(45)Тоже использую в работе. На закрытых конфигурациях небольшие доработки кода.
Из проблем
1. Сам столкнулся когда изменилась форма документа и перестала нормально работать. Обновил в расширении и потерял то что добавлял... Вот тогда на собственном опыте дошел что надо программно добавлять элементы в форму расширения. Пришлось переписать процедуры для большей структурности добавления, и в последующем уже именно туда вписывал необходимые элементы для модификации. Благо таких форм не так много.

3. Просто в расширение заимствую необходимые реквизиты, потом их можно удалить или не обращать внимания...

4 Наследованные в таком случае всегда видны, а вот с оператором &Вместо - это действительно скоро будет засада, ну когда их будет много. Тоже стараюсь их избегать, но не всегда это возможно.
59. ellavs 644 08.04.19 22:17 Сейчас в теме
(45)
Так и не связал их с хранилищем 1С.

Да, у меня тоже что-то не особо хорошо это выходит, поэтому предпочитаю работать с ними через git.
64. Darklight 19 09.04.19 09:52 Сейчас в теме
(45)
Периодически (но вообще не часто) приходится переписывать некоторые наследованные процедуры - когда меняется состав аргументов. И это не только для процедур с оператором &Вместо
.
Насколько мне известно с 12 релиза (или чуть позже, не помню точно) эта проблема частично решилась. То есть, теперь если в исходной процедуре после обновления появится новый аргумент (со значением по умолчанию) - то это не вызовет ошибки в расширении. Главное, чтобы не в середину вклеили новый аргумент - а то логика может нарушиться.
48. oldcopy 122 08.04.19 13:49 Сейчас в теме
Ну попробуйте, только перед продакшеном обязательно потренируйтесь на кошках, чтобы не было потом мучительно больно.
49. Petr54-ru 73 08.04.19 13:54 Сейчас в теме
Месяц назад впервые сделал расширение для УТ11. История такая, где то пару лет назад делал клиентам доработку УТ11 для работы с кассовой программой Frontol. Часть функционала касающееся маркетинга получилось сделать при помощи дополнительной внешней обработки, а часть функционала касающегося получения данных с кассы пришлось допиливать конфигурацию.

Тогда чесались руки это сделать в виде расширения, но были отзывы, что этот механизм пока сырой и не хотелось пускать под это своих клиентов. А тут недавно УТ глобально обновилось и Библиотека подключаемого оборудования поменялась кардинально. Обрадовался, что теперь наконец то можно будет поработать с расширениями. Я в восторге.
50. vadim1011985 71 08.04.19 13:55 Сейчас в теме
Стоило еще упомянуть о свойстве расширения "Назначение расширения конфигурации" , так как правильное его использование позволяет правильно идентифицировать для чего предназначено расширение , плюс есть особенности с порядком выполнения расширения в зависимости от указанного значения в данном свойстве.
51. kembrik 3 08.04.19 13:57 Сейчас в теме
По первому пункту, как говорится, есть нюансы.

Очередностью расширений прекрасно можно управлять (Утверждение справедливо для платформы 8.3.13.1644 и режиму совместимости Версия 8.3.12)

Для этого открываем свойство расширения и меняем назначение расширения конфигурации. Сначала выполняется Исправление, потом Адаптация а потом Дополнение
Прикрепленные файлы:
52. vadim1011985 71 08.04.19 14:06 Сейчас в теме
С its.1c.ru

Каждое расширение имеет свое назначение (свойство расширения Назначение расширения конфигурации). Назначение расширения конфигурации описывает, для какой цели создается это расширение. Расширение может иметь одно из следующих назначений:

● Исправление ‑ такое расширение предназначено для исправления ошибок в прикладном решении. В таких расширениях предполагается использование потенциально «опасных» возможностей расширений, например, применение расширения метода с помощью аннотации Вместо. Исправления предназначено для определенной версии прикладного решения. При выходе следующей версии этого решения автор расширения должен проводить анализ применимости созданных расширений в новой версии. Допускается наличие нескольких расширений с таким назначением, но необходимо обеспечить отсутствие конфликтов между такими расширениями, например, несколько таких расширений не должны расширять один и тот же метод с разными целями. Такие расширения могут не учитывать наличия расширений другого назначения.

● Адаптация ‑ такое расширение предназначено для адаптации прикладного решения под условия конкретного клиента. В таких расширениях рекомендуется не использовать потенциально «опасных» возможностей, т. е. тех возможностей, которые могут привести к конфликту расширений при их совместной работе или которые зависят от порядка подключения расширений. Тем не менее, допускается аккуратное использование «опасных» возможностей, при условии, что автор расширения берет на себя полную ответственность за обеспечение корректного функционирования результирующей конфигурации в новых версиях прикладных решений, и с учетом расширений, имеющих назначение Исправление. Предполагается, что в каждый момент времени в информационной базе существует минимальное количество таких расширений. Если в одно расширение невозможно включить весь набор изменений, то рекомендуется расширения с назначением Адаптация разбивать по максимально крупным блокам расширяемого прикладного решения.

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


И вот тут еще был вопрос по взаимодействию расширений в зависимости от назначения расширения
55. lefthander 08.04.19 15:32 Сейчас в теме
(52)Самое смешное что все выше описанное не обязательно, кроме порядка исполнения. А какой порядок будет у 6 исправлений? или трех адаптаций?
Так что предпочитаю если есть возможность все делать в одном расширении определенного типа.
61. ellavs 644 09.04.19 08:33 Сейчас в теме
(52) да, если всего три расширения, то можно им назначить разные назначения и регулировать последовательность, при большем количестве - это уже сложно регулировать.
62. user872488 09.04.19 08:41 Сейчас в теме
Вообще все вот эти возмущения по поводу расширений, это такие же предъявы к 1С со стороны классических программерах / пользователей, работавших в похожих системах учета. А основная предъява такая: О, это у вас не работет, а это работает, но не так. ООП нет (как у некоторых). Т.е. при оценке нового (особенного отечественного) продукта сводиться только к его минусам. Человек толком не разобрался, но уже отвергает. Хотя, при этом, в его старой системе (текущей) таких функций (не платформы, а системы учета) нет, какие он хочет сразу увидеть в новой программе. И его это устраивает. Ну это же SAP (или как его там). Надо вызывать этаж аналитиков и 2 этажа программистов, чтобы пару полей и кнопку на форму добавить и отвалить кучу бабла.
ЛИЦИМЕРы.
А вот, что касается расширений, то использовать их можно и нужно. Здесь, да и в других делах, главное без фанатизма. + 100 к карме)
65. Darklight 19 09.04.19 10:13 Сейчас в теме
(62)На безрыбье и расширения сгодятся, ну, по крайней мере, после режима совместимости 12 (хотя, вот, возможность добавление в расширение параметров сеанса появилось только в 14 релизе) , а своих констант, определяемых типов, подписок на события, и регламентных заданий, функциональных опций, БП и задач - в расширениях нет до сих пор. Так что они пока ещё обрезки, но определённые задачи ими решать уже можно. Главное, чтобы режим совместимости был не ниже 12 (минимум), а лучше не ниже 14.

Но всё равно - недостатков у архитектуры расширений - море! Хоть те же конфликты дублирования одинаковых метаданных. И невозможность делать приватные (изолированные) метаданные (доступные только внутри расширения). Нет возможностей указывать зависимости (от других расширений, подсистем, версий конфигураций; уж про желание указывать ветвление состава метаданных и реализацию алгоритмов в рамках одного расширения в зависимости от версии конфигурации/платформы куда оно устанавливается), и просто требовать наличие определённых метаданных (хотя бы функциональных опций и привязывать свой функционал к ним, или, в случае отсутсвия некоторых метаданных - автоматически их добавлять - так сказать "в минимально требуемом объёме"). И нет возможности в расширениях добавлять предопределённые данные. Ну уж про отсутсиве возможности расширять расширения - я вообще молчу.


Ещё -до сих пор было нельзя конвертировать проекты расширений и обычных конфигураций друг в друга (хотя бы сравнением объединением) - что очень неудобно в ряде случаев.

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

Лично я считаю расширения любопытной - но тупиковой ветвью развития.

Но никакой классический ООП тут бы ничего лучше бы тоже не предложил.

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

А ещё должны быть опции интеграции - типа функциональных опций - но определяемых значениями на уровне конфигуратора (в т.ч. по различным условиям - например проверка на наличие тех или иных версий требуемых модулей или версию платформы сборки; ну или задаваемым в ручную - как настройка) - и уже по этим опциям различные части кода и метаданных включаются или выключаются для использования в ИБ. Всё лишнее и несовместимое можно было бы сразу отключить - чтобы оно не загружало ИБ лишним содержимым и не снижало её эффективность (расход памяти, скорость алгоритмов и эффективность запросов к СУБД).
Вот такое моё мнение! А расширения - это лишь жалкая пародия на модульную схему.
sergathome; triviumfan; +2 Ответить
67. user872488 09.04.19 10:37 Сейчас в теме
(65) Вот. Адекватная критика (не меня... расширений). Если бы разработчики 1С (те самые на С) сразу сделали все хорошо, то ни у нас ни у них работы бы не осталось. С другой стороны: есть идея. Для ее воплощения нужно много ресурсов (времени, деньги и т.д.). Но можно сделать более менее рабочий вариант. Да обрезанный, да глючный. А дальше по Скраму.
Это я к тому, что пока мы (или они) будут делать идеальный продукт (типа водопадной модели), к релизу он станет уже не идеальный (в той или иной степени), т.к. время снятие показаний и их реализация самый главный наш враг.
Аминь.
69. lefthander 09.04.19 15:07 Сейчас в теме
(65)
а своих констант, определяемых типов, подписок на события, и регламентных заданий, функциональных опций, БП и задач - в расширениях нет до сих пор.

Что то мне интуиция шепчет а их и не будет. ;) и даже намекает почему... Посудите сами - идея расширений дополнение типовых решений. В идеале не снимая с замка. Но идеал не достижим, а раз так то: подписки - добавление своих в основную конфигурацию типовой функционал не пересекают, а значит при обновлениях никаким образом не мешают.
Остальные объекты аналогично. То есть, все то что можно добавить не используя типовой функционал вполне можно, и я для себя решил, вполне нужно, реализовать в основной конфигурации.

(65)
А расширения - это лишь жалкая пародия на модульную схему.

Пародия, не пародия, но жизнь по доработке на текущий момент существенно облегчает. Учитывая что модульность в принципе не заложена, то это можно считать началом будущей модульности. Во всяком случае я на это сильно рассчитываю....
70. Darklight 19 09.04.19 16:44 Сейчас в теме
(69)У подписок есть два важных положительных отличия:
1. Можно сделать одну подписку сразу на несколько источников, в т.ч. на обобщённые - типа ДокументОбъект - без этого просто невозможно делать универсальные подписчики, которые, скажем, должны срабатывать при записи любого ссылочного объекта (в т.ч. которые появятся в будущем), при необходимости проверяя источник уже в самом обработчке на любые условия.
2. В рамках одной конфингурации можно делать несколько подписчиков на одно событие - когда они не пересекаются друг с другом и относятся к решению разных задач, и могут разрабатываться параллельно разными разработчиками, не мешая друг другу. Заодно можно проверить в одном месте всех подписчиков (особенно в EDT где наконец-то их можно группировать по источникам - хоть и всё-равно через жопу).

Конечно, наиболее важным тут является пункт 1.

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

Добавлять в прямо конфигурацию - это же кошмар - как я написал делить проект на части и по разному размещать его в ИБ - это БРЕД! Особенно если думать о расширениях - именно как о шаге к модульным поставкам решений - когда поставщик поставляет дополнительный функционал к основной конфигурации в самостоятельном расширении. И через него осуществляет обновления.

Даже для внутренней разработки расширения, содержащие именно внутри новые метаданные, могут быть очень полезны - вот, к примеру у меня в группе компаний сотни баз, несколько десятков разных конфигураций, нескольких базовых типовых видов. У меня есть функционал - который мне нужно в них все поставить (на 80% он общий для всех баз), который мне потом нужно будет сопровождать и поддерживать. Что мне проще - заморачиваться с отдельной поставкой конфигурации поставщиком (старый проблемный подход) - или завести расширение в хранилище - и подключить его сразу ко всем базам (и обновлять потом через единое хранилище, а оставшимся 20% различий в функционале управлять через встроенные в расширение функциональные опции на базе встроенных же констант)?

Так что пока расширения выглядят больше как издёвка - но я не буду спорить - даже в таком виде (не ниже 12 релиза совместимости) они могут быть вполне полезны - но только как суррогат - т.к. как по-другому выходит не лучше!
sergathome; +1 Ответить
71. lefthander 09.04.19 17:55 Сейчас в теме
(70)Резюмирую - для основной массы текущих потребителей типовых продуктов 1С функционала расширений вполне хватает. Вполне допускаю что есть проекты которым расширение все равно что припарка, но так это уже и не типовые решения.
76. Darklight 19 10.04.19 09:22 Сейчас в теме
(71)Думаю, что основная масса потребителей расширений как раз таки обходит их стороной. А кто действительно был бы готов активно использовать расширения - недовольны их урезанностью. Впрочем, с 14 релиза платформы, даже с этой урезанностью, "проливая крокодильи слёзы", ограниченно применять расширения можно, всё-равно чередуя их с необходимостью менять основную конфигурацию для отдельных случаев. Вот только режим совместимости платформы 8.3.14 ещё ни у одной типовой конфигурации не стоит - ждёмс....
А про конфигурации на на обычных формах я вообще молчу - они без "танцов в бубном" вообще расширения не поддерживают. И не говорите, что их инсталлировано меньше, чем на управляемом приложении.
sergathome; +1 Ответить
81. lefthander 10.04.19 15:49 Сейчас в теме
(76)Не хочу и не буду с Вами спорить. У нас разный круг решаемых задач. Сказу за себя - ЕРП 2.4.6 вполне доработана под специфику задач, режим совместимости - НЕ ИСПОЛЬЗОВАТЬ и на 12 платформе вполне все работает. Раньше была отключена от конфы поставщика, сейчас практически полностью поставлена на поддержку. ;)
avk72; acanta; +2 Ответить
85. Darklight 19 10.04.19 16:39 Сейчас в теме
(81)Я с Вами и не спорю. При сопровождении ERP 2.4 применять расширения вполне можно и это вполне эффективно (чем без них). Но это капля в море возможностей, где можно было бы применить расширения; и очень скромный ареал программистов, кому они тут интересны (не как эксперимент или мелочная доработка), а как основная стратегия сопровождения типовой конфигурации.
66. kembrik 3 09.04.19 10:30 Сейчас в теме
(62)
А основная предъява такая: О, это у вас не работет, а это работает, но не так. ООП нет (как у некоторых). Т.е. при оценке нового (особенного отечественного) продукта сводиться только к его минусам. Человек толком не разобрался, но уже отвергает. Хотя, при этом, в его старой системе (текущей) таких функций (не платформы, а системы учета) нет, какие он хочет сразу увидеть в новой программе. И его это устраивает.


Про слои в Axapta я читал, открыв рот, году так в 2007, и уже тогда приходил в восторг от имеющихся возможностей у "вражеского лагеря". А в 1С прям открытие сделали, с худшей, чем у конкурентов, реализацией
Darklight; +1 Ответить
68. baracuda 2 09.04.19 14:41 Сейчас в теме
спасибо за статью, узнал много чего нового для себя
72. alexsey777 10.04.19 04:16 Сейчас в теме
Работаю с расширениями немного. Но на практике понял, что на расширениях делать удобно внешние механизмы, работающие с данными. Например, очень удобно делать HTTP и WEB сервисы. Какие-нибудь сервисы обработки данных.
Что-то связанное с хранением данных пока тоже не рискую делать. Хотя в этом направлении наверное тоже идет развитие. Поэтому когда-нибудь мнение свое изменю.
Иногда расширения используем для исправления ошибок при обновлении. Для критических исправлений.
74. ellavs 644 10.04.19 08:38 Сейчас в теме
(72) кстати да, мы тоже активно используем расширение для HTTP-сервиса, на основную конфигурацию вообще никак не влияет, зато разрабатывать маленькое решение (а именно разбор в git) гораздо удобнее, чем ворошить всю конфигурацию.
73. rpgshnik 1733 10.04.19 07:23 Сейчас в теме
Хорошая публикация. Расширения использую. Фактически самостоятельно пришел к тем же рекомендациям/правилам:
1. Не дробить расширения, где-то слышал сплетни, что несколько расширений - тормозят базу, а одно нет. По этому одно расширение на одну конфигурацию, желательно конечно!
2. Изменять свойства элементов форм программно, согласен.
3. Минимизация использования директивы &Вместо это вообще святое, уже не однократно черпнул горя. Надеюсь директива &ИзменениеИКонтроль поможет в этом, но практика показывает, режим совместимости на типовых конфигурациях очень сильно не успевает за актуальной рабочей версией платформы. Когда она будет? Через год, минимум наверное :)
4. Независимые расширения, это наверное правило а не рекомендация. Да и вообще пункта 4 не должно быть, учитывая пункт 1 :)
5. Все новые объекты строго в основной конфигурации, удаление расширения явно приведёт к потере данных. Тем более создание новых объектов ни как не повлияет на обновление. А уже обработка их на форме и т.п. строго в расширение. Так же слышал по сплетням, что общие модули так же лучше создавать в основной конфигурации и якобы длительные операции значительно быстрее отрабатывают в основной конфигурации, а не в расширении.
6. Реестры доработок в целом для всего это плюс.
ids79; kostas; Interrupted; lefthander; ellavs; +5 Ответить
75. ellavs 644 10.04.19 08:41 Сейчас в теме
(73)
4. Независимые расширения, это наверное правило а не рекомендация. Да и вообще пункта 4 не должно быть, учитывая пункт 1 :)

Вы будете смеяться, но рекомендации разработаны, а подогнать под них уже созданные ранее решения всё никак руки не доходят, поэтому пункт 4 у нас существует в проекте (т.е. есть расширение, которое используют другие расширения, по хорошему либо переносить код в общий модуль в конфигурации, либо объединять расширения в одно).
94. Angry 11 12.04.19 12:39 Сейчас в теме
(73)
несколько расширений - тормозят базу, а одно нет

Расскажите: откуда информация? Замеров нигде не видел, на глаз разницы не увидел (версия 8.3.7 и ниже не в счет). Лично общался с разработчиками функционала расширений, уверяли, что на производительность работы количество расширений не влияет и у них это контролируется.

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

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

Отсюда с тем что для 1 базы использовать одно расширение - не соглашусь. Если в базе много доработок, разного времени и разного назначения, то под каждую задачу нужно отдельное расширение. Естественно, пересекающиеся задачи, которые используют одни объекты (например несколько раз доработали форму заказа, под разные хотелки) - по сути 1 задача и расширение одно. К этому пришел после неоднократных, не очень удачных обновлений, когда 1С переработают конфигурацию на столько, что не работает почти ни чего. Когда расширение одно - оно отвалилось и пока весь функционал не пройдем, в продакшине ни чего не работает. А на это не всегда есть время, лучше все же если обновление поджимает - его сделать и функционал доработок запустить по очереди в порядке приоритета. Бывают же функции которые раз в квартал используют, а из-за этого мы не можем первичку оперативную печатать - не хорошо.
77. tolstyak_2000 10.04.19 10:37 Сейчас в теме
"В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль"

Ошибка номера платформы - поправьте.
78. ellavs 644 10.04.19 11:19 Сейчас в теме
(77) уточните где, что-то никак не найду, где написала не 8.3.15...
87. tolstyak_2000 10.04.19 18:11 Сейчас в теме
(78)

В тексте статьи есть фраза: "В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль"
88. tolstyak_2000 10.04.19 18:15 Сейчас в теме
(78)

Сейчас последняя платформа 8.3.14
89. ellavs 644 10.04.19 20:07 Сейчас в теме
(88)
8.3.14

В 8.3.14 этой аннотации еще нет. Только в 8.3.15.
79. 77dream77 170 10.04.19 12:59 Сейчас в теме
использую расширения на проектах давно (более 2 лет), даже читал курсы по ним 😊
Из последнего проекта перехода с КА 1.1 на КА 2.4 - там все изменения сделаны через расширения (41 расширение), в конфигурации только новые объекты/реквизиты и одно изменение кода из-за нежелательности применения расширения в данном случае. Было 3 обновления с начала года - никаких проблем
много расширений настраивал для типовых ЗУП, БП, Итилиума, КА, ДО
Много расширений приходится переделывать после других, если неправильно настроены – то они валятся после очередного обновления.
при правильной настройке расширения - очень удобный и стабильный механизм, нужно просто понимать что можно делать через расширение, а что нет

к статье я бы добавил следующее:
1. полностью согласен, для одного объекта/формы отдельное расширение.
одно расширение опасно тем, что при ошибке подключения теряется весь функционал, который заложен в нем
а при отдельных расширениях только небольшая часть отключается и его можно будет легко поправить
2. да, лучше делать программные изменения
но новые элементы формы я обычно добавляю на форму в редакторе. Для них обязательно использую префиксы, новые группы с префиксами и никогда не изменяю типовые реквизиты на форме, только программно
проблем пока не было
3. согласен, аннотация Вместо - это крайний случай и часто бывают проблемы с расширением после обновления, но есть и плюсы…
Последний раз ее применял для доработки печати ТТН и УПД.
Вместо вызывает типовую процедуру получения данных, которая возвращает результат запроса
Этот результат выгружается в ТЗ, обрабатывается, добавляются новые колонки с данными при необходимости и помещаются обратно в результат.
Таким образом при изменении типовой процедуры ничего не сломается даже при изменении запроса или колонок результата, а дальше в коде я ориентируюсь на свои добавленные колонки, которые тоже останутся и не мешают работе типовой.

4. согласен, но если функционал как-то пересекается, то можно общий функционал вынести в отдельный общий модуль конфигурации, например.
Здесь все зависит от решаемой задачи.
5. да, я пока тоже не доверяю хранение важных данных расширению, добавляю новые объекты в конфигурацию.
6. отдельного реестра не веду, все описание в комментариях в расширении или в отдельном макете.
Но для удобства анализа версии расширений – использую реквизит Версия, в него записываю последнюю дату редактирования расширения, например, 10.04.2019
Таким образом при большом количестве расширений очень удобно понимать в какой базе какая версия и переносить изменения, например, из копии в рабочую. Присваивать просто номер версии типа 1.1 неудобно, потому что не известно какая версия последняя, а с датой всегда понятно.

Также после окончательной готовности расширения удаляю все не используемые реквизиты/объекты, отключаю все не нужные для меня зависимости и контроли, добиваюсь, чтобы проверка конфигурации расширения не выдавала ошибок.
Таким образом в расширении остается только измененные и важные для расширения объекты с отключенными контролями и т.п.
При обновление обязательно проверяю все расширения на применимость и еще раз запускаю проверку конфигурации, если она выдает ошибку – ищу причину и устраняю. Таким образом после обновления можно быт спокойным, что на следующий день рабочая будет стабильна и тебя не засыпят ошибками пользователи.
Из недавнего – в КА 2.4 изменилось название документов с ПоступлениеТоваров на Поступление товаровНаСклад, а оно использовалось в двух расширениях в проверке типа и в запросе. Проверка конфигурации естественно выдало эту ошибку, и я ее исправил сразу после обновления до наката на рабочую. Если бы не делал такую проверку, то на следующий день два важных функционала отвалилось бы с ошибкой и утро началось бы не с кофе…
bazelyukandrei; Angealtor; AllexSoft; o.nikolaev; Krio2; worker1c; ellavs; +7 Ответить
80. ellavs 644 10.04.19 13:40 Сейчас в теме
(79) да, тоже вместо версии пишем дату (и время, если изменений было несколько в течении дня), и это не только в расширениях, но и отчетах и обработках.
AllexSoft; o.nikolaev; +2 Ответить
82. lefthander 10.04.19 15:52 Сейчас в теме
(80)Я в расширениях для БП писал версию такую же как и БП.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист, аналитик, эксперт 1С
Санкт-Петербург
По совместительству

Технический лидер, архитектор 1С, руководитель проектов
Санкт-Петербург
зарплата от 150 000 руб.
Полный день

Ведущий 1С консультант по БГУ
Омск
зарплата от 50 000 руб. до 95 000 руб.
Полный день

Специалист внедрения и сопровождения 1С
Омск
зарплата от 25 000 руб. до 50 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству