Доработайте это "немедленно", или как уменьшить доработки конфигурации

25.09.20

Разработка - Рефакторинг и качество кода

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

          Доработки конфигурации – необходимое зло в 1С. В данной публикации автор предлагает несколько простых подходов и приемов, позволяющих хотя бы немного, но оптимизировать объем доработок конфигурации, упростить их, и облегчить дальнейшие доработки и обновления конфигурации. Все примеры и подходы взяты автором из реальной жизни и основаны на собственных наблюдениях. Примеры ниже будут даваться по конфигурациям семейства "Зарплата", хотя годятся для любых конфигураций. Версия конфигурации и платформы особой роли не играет.

Доработать это? А оно мне надо?

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

Сегодня, как известно, доработать "под себя" функционал 1С можно четырьмя основными способами:

1. Доработать саму конфигурацию, т.е. изменить стандартные документы (регистры, отчеты, обработки и т.п.) системы под свои нужды.

2. Использовать вместо доработок конфигурации - механизм расширений, т.е. механизм своих "надстроек" над конфигурацией, не затрагивающих саму эту конфигурацию.

3. Использовать внешние обработки (в том числе, обработки табличной части), печатные формы и внешние отчеты.

4. Использовать тонкую настройку в режиме «1С: Предприятие» (т.е. провести настройки самой программы на уровне пользователя).

У всех способов есть свои преимущества и недостатки.

  • После доработки стандартных документов 1С мы в будущем столкнемся с проблемами обновления. Опыт обновлений последних лет говорит, что 1С часто переделывает или модифицирует стандартные документы. Ясно, что при любом обновлении от 1С - провести «свое» обновление на уже измененный вами документ, есть удовольствие ниже среднего, мягко говоря.
  • Внешние обработки лишены этого недостатка, но при всех своих преимуществах, однако, и они имеют недостатки - их работа не оставляет "следов" в виде документов.
  • Тонкая настройка на уровне пользователя в режиме «1С: Предприятие», к сожалению, очень ограничена по возможностям.
  • Почти идеальным кажется вариант с расширениями. Однако, несмотря на достижения расширений, не все доработки можно выполнить через них, или это трудоемко (неудобно).

       Пока автор излагает то, что все знают и так, как «Отче наш». Ему, впрочем, видится вполне приемлемое решение в некоем компромиссе между озвученными способами - по сути, комбинации способов 1 и 2. Суть предложения сводится к следующему: производится доработка конфигурации (не расширения, не внешние обработки), но НИКАКИЕ стандартные документы (обработки, отчеты, регистры) НЕ дорабатываются. Вместо этого в систему вводятся НОВЫЕ объекты (документы, регистры и т.п.), которые осуществляют необходимые нам расчеты и действия.

На первый взгляд идея кажется абсурдной - нам что, предлагается копировать и подменить, например, документ "Премия" в ЗУП 3.1.? Ничего подобного! Более того, сама идея подобного копирования - глупая и ненужная. Новые, введенными нами объекты НЕ ЗАМЕНЯЮТ стандартные, а дополняют их! Они существуют отдельно в дереве метаданных конфигурации - как отдельные документы, отчеты, обработки.

Задача таких объектов - провести нужные нам расчеты, показать нужные данные, или преобразовать данные в системе нужным нам способом, а затем передать эти сведения (в нужном нам виде) на вход в обработку стандартных документов. Никаких движений в стандартные регистры эти документы НЕ делают при своем проведении, они максимально «автономны» от прочих объектов конфигурации.

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

Приведем условный пример, чтобы было яснее:

В систему добавлен документ «Расчет премии за продажи». Этот документ в свою табличную часть собирает по определенным алгоритмам сотрудников, которым положена премия за продажи. Затем сумма премии рассчитывается на основе данных в системе 1С, согласно правилам расчета премии на этом предприятии. Сумма премии, данные по сотрудникам и любая прочая вспомогательная информация – все это прекрасно видно пользователю в документе «Расчет премии за продажи», который хранится в своем журнале документов и т.п. После расчета суммы премии, при проведении документа или нажатию на определенную кнопку, документ «Расчет премии за продажи» программно создает стандартный документ «Премии», запоминает его шапку, и помещает в него сотрудников с уже рассчитанной суммой премии за продажи (ссылка на этот документ «Премии» хранится в реквизите нашего документа). При дальнейшем изменении документа «Расчет премии за продажи» - меняется и документ «Премии».

Итог: у нас есть полностью готовый стандартный документ «Премии» с рассчитанной премией за продажи. Все исходные данные остались в документе «Расчет премии за продажи».

Если бы нашего документа «Расчет премии за продажи» не было бы, то рассчитать премию за продажи нам бы пришлось вручную, и вписать затем эти суммы сразу в документ «Премии». Да, в ряде случаев можно настроить формулу в виде расчета в 1С, но практика говорит, что схемы мотивации часто настолько «замудрены», что это крайне непростая, часто невыполнимая задача. Можно было бы использовать обработку, которая проводит эти расчеты и создает документы «Премии», однако обработка не оставляет «следов», а мы эти следы имеем (документы «Расчет премии за продажи»).

В виде картинки это можно представить так:

Используя предложенный механизм "интерфейсных" документов, разработчик достигает следующих выгод:

  • Отсутствуют доработки стандартных документов 1С. При описанном выше способе, это исключено. Стандартные обновления 1С в дальнейшем без проблем обновляют стандартные документы (а вы попробуйте обновить документ с хорошо доработанным кодом – посмеемся вместе J ). На функционале наших доработок это может сказаться только, если в стандартных документах будут затронуты основные реквизиты, которые мы используем в «интерфейсном» заполнении.
  • Новые документы и объекты хорошо видны в конфигурации, в том числе, при обновлениях, особенно, если не забыть выделить их имена, например, префиксами вроде «Д_МоеИмя». Разработчик, в том числе, пришедший позже, четко знает - где находится доработка, они не размазаны по множеству объектов системы в коде, а вынесены в отдельные, легко локализуемые сущности дерева метаданных. Такой подход существенно облегчает нам дальнейшую доработку наших разработок - нужно будет "ковырять" только наш же добавленный блок, и наши добавленные документы. Как живут и поживают стандартные документы – нам неинтересно, повторюсь, мы их не трогали, и не будем трогать.

Естественно, предложенный способ имеет и свои недостатки. Прежде всего, это ограничение по сфере применения – далеко не всегда и не везде этот способ применим, он выгоден только на больших и массовых доработках. Я бы сказал больше – его следует применять только в том случае, когда возможные издержки любых других вариантов (например, расширений) могут стоить больших денежных, временных, и «нервных» затрат. Кроме того, предложенный способ все равно является доработкой конфигурации, и лишает нас возможности проводить автоматические обновления.

Храните константы в сберегательном справочнике. Если конечно они у вас есть…

          Вновь вернемся к известной аксиоме, что многие организации, использующие 1С, вынуждены вводить в конфигурацию свои доработки. Естественно, что при доработках адекватные программисты пытаются писать адекватный же код с использованием, в том числе, неких постоянных переменных, констант и т.п. И тут возникает проблема - если нам для наших доработок нужна новая константа, например, вид расчета "премия за красивые глаза", то логично что эту константу нужно где-то хранить?

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

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

Весь справочник состоит из предопределенных элементов, является иерархическим, и не имеет никаких реквизитов, кроме стандартных (т.е. наименования и кода) и реквизита «Значение» (который имеет составной тип «Любая ссылка, Число, Булево, Строка, Дата»). В режиме Конфигуратора мы заполняем список предопределенных элементов (т.е. устанавливаем имя, код и наименование). Каждый такой предопределенный элемент справочника - одна отдельная константа. Значения констант мы всегда можем удобно посмотреть и выставить в базе, просто открыв в системе в режиме "1С: Предприятие" справочник "КонстантыДоработки".

Теперь в коде легко вызвать нужную константу простейшей конструкцией, например, "Справочники.КонстантыДоработки.ВидПремии.Значение" – даст нам значение константы «Вид премии».  Нам, как программисту, не нужно беспокоится, какое конкретно значение заполнено в этом элементе. Разве что проверить на заполнение, и не забыть конечно в базе саму константу выставить. 

Иерархический режим справочника нужен, чтобы, если констант много – в режиме Предприятия расфасовать их по папкам. Единственная сложность - пополнять справочник можно только в режиме Конфигуратора.

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

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

С помощью справочника констант можно также хранить и "флаги", и через это "включать" и "выключать" наши доработки. Например, в системе есть наша доработка расчета премии. В справочнике констант "КонстантыДоработки" вводим через конфигуратор элемент "АктивностьБлокаПремии" с  типом "Булево". Далее программная конструкция:

ФлагАктивности = Справочники.КонстантыДоработки.АктивностьБлокаПремии.Значение;

Если ФлагАктивности = Истина тогда

// код нашей доработки

КонецЕсли;

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

Большая Советская Энциклопедия своих функций и процедур

      Эта очень простая идея вытекает из предыдущей. Нам, то есть программистам, так удобно пользоваться в работе всякого рода стандартными функциями и процедурами 1С! Но бывает, что их нам не хватает!

"Так напиши свою!" – скажет мне кто-то, и этот совет будет правильным. Ну хорошо, я написал "свою" функцию для очередного отчета или обработки, и она замечательная. Но в другом месте мне нужна эта же функция! Снова ее писать? Копипастить? Нет, есть более разумное решение.

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

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

Я также рекомендовал бы подобные процедуры, и особенно, функции, делать максимально «универсальными», т.е. такими, которые могли бы возвращать различные значения, в зависимости от поданных параметров. Т.е. не создавать 10 функций, каждая из которых возвращает какое-то одно, похожее на другое поле. Например, одна функция возвращает дату приема сотрудника, другая – дату увольнения, третья – должность. Вместо 10 функций сделаем одну универсальную.

Приведу упрощенный пример, чтобы была понятна суть. Пусть есть функция («самописная», вызывается из «самописного» общего модуля «МойМодуль»), с именем, ну например: «ВернутьДанныеПоСотруднику(ДатаПоиска,ПолеВозврата,Сотрудник)». Внутри функции имеется запрос, который возвращает по указанному сотруднику (параметр «Сотрудник») на заданную дату (параметр «ДатаПоиска») целый набор полей кадровых и зарплатных данных – должность, подразделение, оклад, количество ставок, дата приема и т.п. Однако функция возвращает не весь результат запроса, а только то поле, которое передано в параметре «ПолеВозврата». Например, мы пишем в коде:

Сотрудник = Справочники.Сотрудники.НайтиПоНаименованию(«Иванов Иван Иванович»);

ДолжностьСотрудника = МойМодуль.ВернутьДанныеПоСотруднику(ТекущаяДата(),«Должность»,Сотрудник);
ДатаПриемаСотрудникаСотрудника = МойМодуль.ВернутьДанныеПоСотруднику(ТекущаяДата(),«ДатаПриема»,Сотрудник)

И т.п. Внутри самой функции получается примерная программная конструкция вида:

Запрос = Новый Запрос("
//тут текст запроса с выборкой множества полей
");                            
                   Запрос.УстановитьПараметр("ДатаПоиска", ДатаПоиска);
                   Запрос.УстановитьПараметр("Сотрудник", Сотрудник);
 
                   Выборка = Запрос.Выполнить().Выбрать();                                                

                   Если Выборка.Количество() > 0 тогда
                                   Выборка.Следующий();          
                               Попытка
                                      Возврат Выборка[ПолеВозврата];                                                 
                               Исключение                                                                 
                                     Возврат Сотрудник;
                              КонецПопытки;                                  

                   иначе  
                        Возврат Сотрудник;
       КонецЕсли;   

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

 Доработка функции очень легкая – добавляем в запрос с выборкой полей новые поля, и потом просто можно вызывать «новые» поля в коде, не меняя самой конструкции вызова. Конечно, надо следить, чтобы запрос-выборка не был перегружен и усложнен без нужды, но поскольку мы изначально выбираем данные только для одного сотрудника – он никогда не будет слишком уж «тяжелым».

конфигурация доработки метаданные программирование

См. также

Когда понадобился новый оператор

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1171    ZhokhovM    2    

4

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    2708    ZhokhovM    4    

9

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1911    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

27.09.2023    6974    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.09.2023    4355    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9595    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2218    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. wildhog 469 26.09.20 18:38 Сейчас в теме
Лучше для констант не справочник использовать а ПВХ. Тогда можно задавать и тип значения. Когда добавлено много "констант" легко запутаться в типах.
JohnyDeath; ktb; Teut_Vlad; begemot; TerveRus; Богатырев Артур; +6 Ответить
4. Богатырев Артур 125 28.09.20 11:21 Сейчас в теме
(1) Интересная идея с ПВХ...
Teut_Vlad; +1 Ответить
2. МимохожийОднако 141 27.09.20 08:00 Сейчас в теме
Нечто похожее делал в конфигурациях на семерке, т.к. не было возможности создать вторую табличную часть или надо было добавить функционал к табличной части существующего документа.
Богатырев Артур; +1 Ответить
3. Богатырев Артур 125 28.09.20 11:20 Сейчас в теме
(2) да, я об ограничениях 7-ки знаю. На самом деле идея много лет назад начала расти оттуда. Однако за последние три года минимум трижды вполне адекватно работала и на проектах под "восьмерку" :)
5. Sla 28.09.20 15:30 Сейчас в теме
Функцию ВернутьДанныеПоСотруднику можно ещё более универсализировать чтобы она вместо "возвращает не весь результат запроса, а только то поле, которое передано в параметре «ПолеВозврата»" возвращала структуру данных, значения ключей которой ей передают.
Тогда бы она вызывалась один раз, а не для каждого поля.
6. Богатырев Артур 125 28.09.20 21:33 Сейчас в теме
(5) да, со структурой я тоже как то делал вариант. :)
7. ivnik 581 29.09.20 09:30 Сейчас в теме
Считаю, что это хорошая и правильная статья! По такому же методу я добавил в типовую ЗКГУ-3.1 целый довольно большой "блок" Тарификации сотрудников. Правда для констант я использовал не справочник и не ПВХ, а собственный Регистр сведений.
https://infostart.ru/public/898871/
oldcopy; Богатырев Артур; +2 Ответить
8. Богатырев Артур 125 29.09.20 09:43 Сейчас в теме
(7) спасибо. Вариант с регистром я когда-то один раз использовал, но мне показалось немного неудобным в регистре делать отборы, и полей надо вводить столько же, сколько констант. Правда регистр более эффективен, когда есть несколько организаций (тогда 1 запись - для одной организации).
9. TerveRus 30.09.20 13:01 Сейчас в теме
Один минус в этом совете по доработке "сбоку" - оно применимо как раз только для узкой задачи вроде расчета премий, но больше не для чего. Мало существует задач, которые существуют в стороне от учетной системы и никак не влияют на данные или типовую логику работы.

Во-вторых, все эти константы в справочниках - это хорошо, но так же неудобно, как и добавление константы. Все эти НайтиПоНаименованию возникают не просто так, а когда надо срочно доработать код, не выгоняя из базы пользователей, и индусы тут ни при чем. И никто в здравом уме справочники на ровном месте не переименовывает, это все гипотетические проблемы, а не реальные. А вот каждый раз лезть в конфигуратор добавлять предопределенные значения - вот что не реально. Тогда бы уж использовали механизм создания предопределенных значений программно, советую изучить вопрос)
unknown181538; +1 Ответить
10. Богатырев Артур 125 30.09.20 13:31 Сейчас в теме
(9)
Мало существует задач, которые существуют в стороне от учетной системы и никак не влияют на данные или типовую логику работы.

1. Их больше чем вам кажется. Например, таким образом мною был создан целый блок по обучению и аттестации персонала, т.к. стандартный функционал не устраивал заказчика.
2. Вообще то никто не писал что задачи "существуют в стороне". Ежемесячный расчет зарплаты в виде примера - нифига не "в стороне", это самое что ни на есть "корень и поток" текущих задач.
3. Читайте внимательнее публикацию - предполагается, что в работе "интерфейсных документов" будут использованы стандартные же данные системы, и результат более того - влияние на типовые данные. НЕ путем записи в регистры. А путем создания стандартных документов, которые уже повлияют на регистры.

(9)
Все эти НайтиПоНаименованию возникают не просто так, а когда надо срочно доработать код,

Это правда, но ведь вы "костыль" не оставите, а доделлаете до ума, разве нет? :)

(9)
И никто в здравом уме справочники на ровном месте не переименовывает,

Конечно. Не понимаю как это связано с моей публикацией... :)

(9)
. А вот каждый раз лезть в конфигуратор добавлять предопределенные значения - вот что не реально. Тогда бы уж использовали механизм создания предопределенных значений программно, советую изучить вопрос)

Можно и программно создавать. Это не влияет на суть идеи.
11. user1464234 30.09.20 13:34 Сейчас в теме
(10) простите,я не понимаю, что такое костыль.
Есть Бураны как клоны Челенджера и есть ансамбль Бурановские бабушки. Каждое решение хорошо для своей аудитории, даже если и то и другое неэффективно (в отличие от капсулы с парашютом или Большого театра).
Проблема в том, что программисты слишком долго создают свои решения и целевая аудитория уходит раньше.
12. Богатырев Артур 125 30.09.20 13:37 Сейчас в теме
(11)
простите,я не понимаю, что такое костыль.

Костыль - это когда вы БЫСТРО делаете нечто, какую-то "заплатку" в программе, чтобы она изменила свое поведение и сработала так, как нужно, исправила бы ЗДЕСЬ И СЕЙЧАС ошибку. Как правило, это очень слабые с точки зрения построения и тестов и крайних случаев заплатки. В дальнейшем их надо адекватно переписать (но на практике часто так не делают).
И у нас по коду спустя пару лет разбросаны десятки: "найтипонамиенованию"


(11)
Есть Бураны и есть ансамбль Бурановские бабушки. Каждое решение хорошо для своей аудитории, даже если и то и другое неэффективно.

Именно. Я об этом и писал напрямую в публикации.
13. user1464234 30.09.20 13:43 Сейчас в теме
(12) в нашей практике под костылями понимали комментарий куска кода или временный код, который после совершения каких то действий, для других сотрудников восстанавливали как было, но то 7ка с загрузкой модулей из файла(и действия программы не соответствуют ни документации ни задачам).
В системах с компилируемым екзешником такое невозможно по определению, а вот 8чники пытаются усидеть на интерпретаторе с расширениями и это нормально, но разумеется немного медленнее.
14. TerveRus 30.09.20 14:32 Сейчас в теме
(10) Вы дальше ЗУПа вообще не заглядываете? Или дальше премий? Расчет зарплаты идет по кнопке заполнения документа расчета, что затрет все ваши рассчитанные данные. Это все равно, что предлагать своими документами заполнять Операцию Бух в Бухгалтерии - получится черти что.

Ну даже пусть в ЗУПе такой способ поможет, но есть и другие разделы учета. Я бы даже сказал, что заполнение обработкой стандартного документа - это гораздо более узкий круг задач, чем изменение типовых механизмов. А когда обработкой это не сделать, приходится изменять сами формы документов. А зачем делать соседний документ, если можно просто кнопку в типовом документе с кодом? Все эти советы ведут только к усложнению и удорожанию разработок.
15. Богатырев Артур 125 30.09.20 16:23 Сейчас в теме
(14)
Вы дальше ЗУПа вообще не заглядываете?

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

(14)
Расчет зарплаты идет по кнопке заполнения документа расчета, что затрет все ваши рассчитанные данные

Вы невнимательно материал читали, или не поняли его. Механизм не подменяет заполнение основных документов расчета зарплаты. Механизм создает стандартные документы там где стандартное заполнение не работает или не может быть использовано.
Для справки - в зарплате может быть много документов расчета зарплаты (причем разных видов документов), которые друг другу не противоречат. Обычное общее основное заполнение зарплаты будет тем же самым образом происходить.

(14)
что предлагать своими документами заполнять Операцию Бух в Бухгалтерии - получится черти что.

Нет, получится именно то что надо - есть много обработок, которые создают специфические операции БУХ (например для "списывания" всяких "хвостов" с счетов). И ничего, это никому не мешает. Если операцию будет создавать документ а не обработка, сути не меняется.

(14)
А зачем делать соседний документ, если можно просто кнопку в типовом документе с кодом?

Конечно можно. Читайте внимательнее публикацию, там черным по белому написано - механизм эффективен только тогда когда трудозартраты других способов выше. Ваши замечания основаны на невнимательном прочтении материала, уважаемый.
И всего 1 "кнопка с кодом" сделает:
- Снимет ваш стандартный документ с поддержки. И далее увеличит трудоемкость обновления - сравнение-обьединение конфигураций заставит вас попотеть и переносить код своей кнопки вручную.
- Если 1С изменит форму документа (а на форме ваша кнопка) - пота будет еще больше.
А если у вас 10 "кнопок с кодом"?
В предложенном мною методе меня не беспокоят обновления стандартных документов, если не меняются используемые мною реквизиты. Я избавлен от необходимости вручную обновлять снятые с поддержки документы. Мои доработки находятся в одном месте (или по крайней мере, виды именно как новые обьекты в дереве метаданных), на них обновления 1С не могут повлиять, и их дальнейшую доработку я делаю не в теле стандартного документа (еще более увеличивая его "нестандартность"), а в них же (что облегчает отладку).
Я думаю, обосновывать необходимость держать "свои" функции в отдельном модуле нет нужды?
16. Fominro 02.10.20 11:28 Сейчас в теме
(9)Найти по наименованию элемент справочника, это зло. А вот найти по наименованию элемент справочника "констант" вполне себе приемлемо.
В этом случае хотя бы не нужно добавлять объект в конфигуратор и в крайнем случае можно обойтись динамическим обновлением.
Богатырев Артур; +1 Ответить
22. unknown181538 151 25.05.21 17:37 Сейчас в теме
(9) НайтиПоНаименованию(), НайтиПоКоду() считается диким табу.
Но реально, если смена наименования случается, то смена кода - почти фантастика. Конечно, если какой-то элемент вызывается многократно, то с точки зрения читаемости, надежности и прочего - это не лучшее решение, а в остальном - когда, 10-20 клиентов на аутсорсе, и бизнес нуждается в оперативных решениях, то не факт, что целесообразно в каждую базу ПВХ добавлять. Там может и доработок на 5 блоков кода. Все эти брюзжания - это чистоплюйства от чрезмерно раздутых отделов разработки (или я не знаю от кого).
TerveRus; +1 Ответить
24. Богатырев Артур 125 26.05.21 10:16 Сейчас в теме
(22)
Но реально, если смена наименования случается, то смена кода - почти фантастика

Редко да метко бывает. Вот недавно на крупном заводе кто то переименовал имя элемента справочника, который испольховался в доработке. "Все сломалось" и никто сутки не мог понять ничего.

"10-20 клиентов на аутсорсе, и бизнес нуждается в оперативных решениях, то не факт, что целесообразно в каждую базу ПВХ добавлять"
Естественно, нужно гибко подходить.
17. Fominro 02.10.20 11:31 Сейчас в теме
Методом "Документы с боку" дорабатывал Документооборот. Входящие, исходящие и др. документы Документооборота имеют довольно скудную функциональность. Приходиться делать свои документы и связывать их с типовыми.
Богатырев Артур; +1 Ответить
18. maldinitaly 03.10.20 00:04 Сейчас в теме
Согласен с автором на все 100% процентов. Мы тоже такой способ используем для УПП. У нас свои документы для документов "Отчет производства за смену", "Сдельный наряд", "Заказ на производство".Также свои справочники для спецификаций и тех.операций. Об обновлении мы даже не заботимся.Накатываем все типовыми средствами.Т.к обьекты поставщика мы не затронули.
Богатырев Артур; +1 Ответить
19. tenaxxx 09.10.20 04:38 Сейчас в теме
Согласен с автором с удобством справочника "КонтстантыДоработки". Я использовал данный механизм, но немного усовершенствовал - у справочника есть не только реквизит Значение, но и ТЧ Значения, с реквизитом Значение. в модуле менеджера этого справочника:

Функция ПолучитьКонстанту(ИмяКонстанты, Множество = Ложь) Экспорт
      Если Множество Тогда
            Возврат Справочники.КонстантыДоработки[ИмяКонстанты].Значения.ВыгрузитьКолонку("Значение");
      Иначе
            Возврат Справочники.КонстантыДоработки[ИмяКонстанты].Значение;
      КонецЕсли;
КонецФункции

Вызов:
ЗначениеКонстанты = Справочники.КонстантыДоработки.ПолучитьКонстанту("МояКонстанта");
МассивКонстант = Справочники.КонстантыДоработки.ПолучитьКонстанту("МояКонстанта", Истина);
Богатырев Артур; +1 Ответить
20. Богатырев Артур 125 12.10.20 11:00 Сейчас в теме
(19) Интересная идея с ТЧ, запомню :)
21. oldcopy 173 10.05.21 04:24 Сейчас в теме
Поставил плюс, но мы в итоге используем регистр сведений, организованный по принципу "опция - значение опции" и в связку с ней справочники. Непосредственно в регистр пишутся значения, которые пользователь явно задавать не должен, в справочники те, которые явно зависят от пользователя.

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

Плюс подхода - унификация кода. Создаем общий модуль с функцией ВернутьЗначениеСобственнойКонстанты(ИмяКонстанты) и через него получаем значение любых записей.
23. Богатырев Артур 125 26.05.21 10:15 Сейчас в теме
(21)
в итоге используем регистр сведений, организованный по принципу "опция - значение опции"

Да, недавно был опыт и такого подхода.
Оставьте свое сообщение