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

Публикация № 1299825

Методология - Рефакторинг и качество кода

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Конечно можно. Читайте внимательнее публикацию, там черным по белому написано - механизм эффективен только тогда когда трудозартраты других способов выше. Ваши замечания основаны на невнимательном прочтении материала, уважаемый.
И всего 1 "кнопка с кодом" сделает:
- Снимет ваш стандартный документ с поддержки. И далее увеличит трудоемкость обновления - сравнение-обьединение конфигураций заставит вас попотеть и переносить код своей кнопки вручную.
- Если 1С изменит форму документа (а на форме ваша кнопка) - пота будет еще больше.
А если у вас 10 "кнопок с кодом"?
В предложенном мною методе меня не беспокоят обновления стандартных документов, если не меняются используемые мною реквизиты. Я избавлен от необходимости вручную обновлять снятые с поддержки документы. Мои доработки находятся в одном месте (или по крайней мере, виды именно как новые обьекты в дереве метаданных), на них обновления 1С не могут повлиять, и их дальнейшую доработку я делаю не в теле стандартного документа (еще более увеличивая его "нестандартность"), а в них же (что облегчает отладку).
Я думаю, обосновывать необходимость держать "свои" функции в отдельном модуле нет нужды?
16. Fominro 02.10.20 11:28 Сейчас в теме
(9)Найти по наименованию элемент справочника, это зло. А вот найти по наименованию элемент справочника "констант" вполне себе приемлемо.
В этом случае хотя бы не нужно добавлять объект в конфигуратор и в крайнем случае можно обойтись динамическим обновлением.
Богатырев Артур; +1 Ответить
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. Богатырев Артур 107 12.10.20 11:00 Сейчас в теме
(19) Интересная идея с ТЧ, запомню :)
Оставьте свое сообщение

См. также

Ускорение расчета себестоимости УПП 1.3 в несколько раз

Закрытие периода Рефакторинг и качество кода v8 УПП1 БУ УУ Бесплатно (free)

Как определить причину медленного расчёта себестоимости в УПП 1.3, один из вариантов поиска проблем производительности с помощью инструментов 1С и ускорения расчёта средствами встроенного языка

02.02.2021    2390    RPGrigorev    19    

Реальный кейс по внедрению CodeReview

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

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

20.01.2021    1186    Alexsandr_Retunskiy    3    

Операторы перехода в программном коде: использовать или нет?

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

Рассмотрим ситуации использования операторов перехода Перейти (GoTo), Возврат (Return), Прервать (Break), Продолжить (Continue). Как вы считаете - это дурной тон, нормальная практика или зависит от ситуации?

16.11.2020    2154    ivanov660    22    

Чистый кот (Clean cat)

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

От автора легендарного бестселлера "Совершенный кот".

04.11.2020    1635    vasilev2015    25    

Метод борьбы с большим количеством комментариев в коде

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

Решил поделиться нашим способом борьбы с сильно закомментированным кодом.

08.09.2020    1345    tambu    9    

Как поставить качество кода на поток и при этом не разориться? Какие шаги стоит сделать уже завтра, чтобы повысить планку качества?

Рефакторинг и качество кода v8 Бесплатно (free)

Наличие в 1С-решениях некачественного кода мешает их поддержке и эффективному развитию. Как добиться соблюдения стандартов разработки при написании кода и внедрить бюджетный Code Review с помощью инструментария на основе АПК (Автоматизированной проверки конфигураций) на конференции Infostart Event 2019 Inception рассказал технический руководитель компании Бизнес Лоджик Иван Козлов.

22.06.2020    3503    kozlov.alians    1    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    4617    grumagargler    14    

Рефакторинг в редакторе модулей

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

Для тех, кто не пользуется Ctrl+Alt+R. “Контролируемый процесс улучшения кода без написания новой функциональности”, “Равносильное преобразование алгоритмов” и т.п в данной статье НЕ рассматриваются. Тема статьи: замечательные команды из подменю Рефакторинг контекстного меню редактора модулей в конфигураторе. В статье описано, как команды из подменю Рефакторинг помогают при написании кода

10.03.2020    4302    pparshin    5    

Качество кода: Поведенческие паттерны проектирования

Рефакторинг и качество кода v8 Бесплатно (free)

Поговорим про применение паттернов проектирования в разработке на 1С.

03.03.2020    7930    ivanov660    0    

Боремся с запросами в циклах. Мой опыт рефакторинга запросов

Рефакторинг и качество кода v8::Запросы 1cv8.cf Бесплатно (free)

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

02.03.2020    7726    aximo    55    

Стабильность превыше всего

Рефакторинг и качество кода v8 Бесплатно (free)

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

07.11.2019    9864    YPermitin    40    

Оценка скорости кода. Сложность алгоритма

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

Эта тема одной из первых всплывает на собеседовании программистов языков вроде Java и C, но она почти неизвестна в "мире 1С". Поговорим о вычислительной сложности алгоритмов.

07.10.2019    5789    m-rv    12    

Управление качеством кода

Математика и алгоритмы Рефакторинг и качество кода v8 Бесплатно (free)

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    18139    Stepa86    33    

По следам код-ревью

Рефакторинг и качество кода v8 Бесплатно (free)

Приведу примеры с картинками и небольшим пояснением по вопросам, связанным с код-ревью (обзором кода).

09.07.2019    13389    ivanov660    110    

Что такое рефакторинг и в чем его цели

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

Что такое рефакторинг, и в каких случаях им стоит заниматься? Евгений Шумилов дает ответы на эти вопросы, а также рассказывает о признаках хорошего и плохого кода. Кроме того, в статье приведены основные проблемы рефакторинга и способы их решения.

30.10.2018    12324    eu_genij    34    

Мастер-класс от Poppy (практикум по рефакторингу)

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

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

04.11.2008    18819    poppy    33