Правила жёлтого напильника. Часть 3. Правильного ответа нет

29.06.21

Архитектура

О выборе варианта реализации изменений.

Правильного ответа нет

Когда принимаете решение, каким образом внести изменения в конфигурацию, помните: правильного ответа нет. Всё всегда зависит от контекста, обстоятельств, динамики развития типовой конфигурации, принятой у клиента сложности и интенсивности доработок, ну и вашего желания заработать сейчас и в дальнейшем (или желания/политики вашей компании).

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

Однако, это не значит, что изменения надо вносить, как попало. Надо взвесить плюсы и минусы каждого способа, разделив их на две категории: «сейчас» и «потом». И, по возможности, рассказать клиенту, чтобы выбрал. Если у него есть более или менее приличная история доработок своей системы, он должен, хотя бы примерно, понять, о чём речь.

Рассмотрим несколько примеров.

«Добавь поле, зачем – потом решу»

Заказчик – начальник отдела продаж. Просит добавить флажок «Согласовано» в заказ покупателя/клиента, чтобы был доступен для редактирования только ему. Флажок должен быть виден в формах документа и списка. Цель – проверять все заказы, вдруг там чё не так. Заказчик говорит, что до сего момента обходился комментариями, но это неудобно – менеджеры же сами могут там что-нибудь написать, в том числе и как бы согласовать себе заказ.

Принципиально у вас три варианта, как добавить поле – прямо в конфигурацию, через расширение или использовать доп. реквизиты. Если конфигурация старая, вроде УПП или УТ 10.3, то вариант с расширением исключаем (если только у клиента не повышен режим совместимости до 8.3).

Добавить доп. реквизит

С точки зрения «сейчас» самым простым кажется вариант добавить доп. реквизит. На это уйдут буквально минуты, и пользователю даже не придётся перезапускать 1С. Реквизиту можно дать имя (чтобы потом использовать в коде), вывести на форму документа.

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

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

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

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

Добавить через расширение

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

Через расширение получится реализовать всю функциональность, требуемую начальнику отдела продаж в данный момент. Неприятным местом станет форма списка – будут муки выбора на тему вывода колонки, сделать это кодом или просто добавить в расширенную форму.

Добавить в конфигурацию

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

Влияние на последующие обновления

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

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

Доработка конфигурации окажет самое серьёзное влияние на обновления – они станут «нетиповыми», т.е. их не сможет выполнять ни сам клиент, ни большинство сервис-инженеров (или как их там называют).

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

А что будет дальше?

Варианты развития доработки

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

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

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

Придётся думать программисту. Итак, мы уже наткнулись на необходимость запрета проведения реализации по несогласованному заказу. Сделать это несложно, будь у нас вариант с расширением или доработкой конфигурации. Достаточно добавить подписку на проведение реализации, и выполнить там проверку флага в документе-основании. Как думаете, на этом всё закончится?

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

Поэтому вас попросят сделать так, чтобы реализацию даже создать было нельзя. Соответственно, нам теперь надо вмешиваться в обработку заполнения. Вроде, ничего особо страшного, и суть доработки будет примерно такая же, как в случае с запретом проведения. Но перекроет ли запрет ввода на основании все пути заполнения реализации по заказу?

Нет, не перекроет. Что в УПП, что в ЕРП есть прекрасные обработки, позволяющие подтянуть в реализацию позиции заказов, не используя механизм ввода на основании. Обратите внимание – заказов, а не заказа. Реализация ведь может идти по нескольким заказам одного клиента. В текущий момент такая возможность у клиента отключена? Не будем наивными. Возможно, он про такую функциональность просто пока не знает.

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

Итак, мы наткнулись на ворох доработок, сразу по нескольким объектам, с разными вариантами реализации. Где-то надо код модифицировать, где-то – дин. списки фильтровать (в форме выбора заказа, например), количество объектов для доработки очень быстро возрастает. А ведь мы пока, всего лишь, делаем несколько удобнее – чтобы менеджер не тратил время на создание реализации по несогласованному заказу. А что дальше?

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

Что-то расширяется легко – например, созданием подписки или добавлением реквизита на форму. Но где-то появится зловещее «&Вместо» - и теперь нетиповое обновление будет за счастье.

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

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

Ну и, в качестве вишенки на торт, начальник отдела продаж скажет: так-с, а давай ещё одну галочку добавим, для моего заместителя. А, нет – у нас отдел продаж на два разбился, а я теперь – коммерческий директор. Пусть у начальников отделов продаж будут свои галочки, а у меня – своя, моя любимая. А, погоди… Давай ещё юристы будут согласовывать заказ. Стоп, нафига… Бухгалтерия может? Нет, они-то причём… Не знаю, короче. Добавь пару галок про запас. Пусть пока ни на что не влияют, потом решу, что с ними делать. Здорово ведь у нас получилось!

Понимая весь путь, который нам предстояло бы пройти от маленького флажка до перекройки всей системы, напрашивается более простое и элегантное решение – тупо не давать проводить заказ, пока он не согласован. Большинство механизмов, связанных с заказом, не будут на него реагировать, пока документ не проведён (т.к. используют, в основном, его движения).

Да, чуть не забыл. Функциональность согласования заказа клиента есть в типовой конфигурации (УТ 11, КА2, ЕРП). Начальник отдела продаж просто о ней не знал. А мы, используя «позадачный подход» и чрезмерно увлёкшись качеством внесения изменений, как-то об этом и не подумали.

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

Так какой вариант выбрать?

К чему я всё это? К тому, что написано в начале: нет правильного варианта внесения изменений.

Цепочка событий, которую я описал, может случиться, а может – и нет. Вполне вероятно, что дойдёт лишь до середины. Кто-то сам остановит заказчика, сказав, что его требования нереализуемы. Возможно, начальника отдела продаж остановят ограничения бюджета. А то и увольнение, по независящим от автоматизации причинам, а его преемник скажет: «Чё? Какую галку ставить? Оно мне надо?».

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

Ну и, не стоит исключать, что всё это делается для «проекта-проститутки» (прошу прощения, это устойчивое идиоматическое выражение) – каждая последующая итерация выполняется новым программистом, а то и стажёром. Вникать, что и как было до него – смерти подобно. Надо сделать и бежать.

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

Итак. Оптимальный вариант доработки зависит не только от текущей постановки задачи, но и от её дальнейшего развития. Иногда – растянутого на годы. Соответственно, в общем случае – совершенно неопределённого. В самом начале вы пытаетесь определить лучший способ реализации неизвестно чего.

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

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1677    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1900    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    4399    0    ivanov660    10    

30

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    2209    0    user1754524    15    

16

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    3127    0    ke_almaty    0    

14

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

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

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

10.08.2023    10145    0    1c-izhtc    37    

22

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Внедрение изменений Пользователь Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1597    0    Ingraf    0    

16
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Богатырев Артур 125 29.06.21 11:39 Сейчас в теме
Сегодня статья скучная - пережевано многократное - "конфа или расширение или доп.реквизит".
Рамзес; itoptimum; +2 Ответить
2. 1c-intelligence 12808 29.06.21 11:48 Сейчас в теме
(1) это статья для другой аудитории. Не для таких опытных крутых спецов, как вы.
mikl79; dajen; +2 1 Ответить
3. Богатырев Артур 125 29.06.21 11:52 Сейчас в теме
(2) с чего вы взяли что я опытный крутой спец? Вот еще глупости.
Я ж не сказал что материал плохой или неверный - он просто скучный. Где ваш обычный юмор? Где надрыв? Эмоции?
Ваши предыдущие творения были лучше.
SuhoffGV; itoptimum; sinichenko_alex; +3 Ответить
4. 1c-intelligence 12808 29.06.21 11:58 Сейчас в теме
(3) это учебный материал для моих студентов, какой юмор, вы чё.
7. Богатырев Артур 125 29.06.21 12:37 Сейчас в теме
(4) а деньги, славу и хайп с инфостарта получаете. :)
sinichenko_alex; +1 Ответить
9. 1c-intelligence 12808 29.06.21 12:40 Сейчас в теме
18. Yashazz 4751 29.06.21 13:51 Сейчас в теме
(9) Хайп - возможно, да. С остальным - сомнительно. Хотя, ваши деньги считать это занятие непродуктивное.
Вообще за псевдоумное трепачество неслабо платят, если правильно его подать.
21. Богатырев Артур 125 29.06.21 14:52 Сейчас в теме
(9) почему, я просто факт отметил. Не более.
sinichenko_alex; +1 Ответить
8. akim2040 41 29.06.21 12:40 Сейчас в теме
(4)Видимо коллега другие части напильника не читал. Обучающие (технические) именно в таком формате и ранее были поданы.
22. Богатырев Артур 125 29.06.21 14:52 Сейчас в теме
(8) да читал, читал. Там более живее.
38. AnryMc 849 30.06.21 17:52 Сейчас в теме
(1) Зато почти техническая ;-)
5. profiprog1c 249 29.06.21 12:24 Сейчас в теме
Да уж, статья как обычно очередное графоманское творение - просто побольше налить воды. На входе: клиент заказывает доработать флажок, на выходе программист "должен" сидеть и думать, а вдруг потом клиент захочет неотгруженные заказы бла-бла-бла, а потом еще захочет бла-бла-бла. А на деле клиент хочет флажок, его и просит сделать. Но тогда и писать было бы не о чем эту статью. А писать тут и так не о чем, но писать что-то надо, поэтому идет разлив воды
sinichenko_alex; +1 Ответить
6. 1c-intelligence 12808 29.06.21 12:27 Сейчас в теме
(5) если не секрет, зачем вы читали статью?
Или я неправильно расшифровал ваш ник - "профессиональный программист 1С"?
11. profiprog1c 249 29.06.21 13:20 Сейчас в теме
(6) Я тут многие статьи читаю, в том числе и вашу прочитал
sinichenko_alex; +1 Ответить
12. 1c-intelligence 12808 29.06.21 13:26 Сейчас в теме
(11) зная, что статья моя, и она вам не понравится, вы её прочитали?
14. profiprog1c 249 29.06.21 13:38 Сейчас в теме
(12) Я наперед не знаю, что написано в статье. Статьи читаю, но дочитать до конца очень редко их получается. Часто меня хватает только до половины, иногда и меньше чем до половины, когда становится понятно, что статья либо вода, либо статья из серии Корпоративный туалет, Ослик Иа, 4х ускорение, либо очередные рассказы-поучения как вести бизнес, заниматься программированием и прочие малополезные нравоучения. Самое интересное в ваших статьях, это не сами не статьи, зачастую их чтение бесполезно потраченное время, а самое интересное это комменты, которые пишут другие посетители, вот их с удовольствием читаю)
Award; BomjBandit; sinichenko_alex; Yashazz; +4 Ответить
15. 1c-intelligence 12808 29.06.21 13:42 Сейчас в теме
(14) а зачем вообще начинаете читать мои статьи? Знаете ведь, что в них точно не то, чего бы вам хотелось почитать. Можно сразу мотать на комментарии.
16. profiprog1c 249 29.06.21 13:47 Сейчас в теме
(15) Чтобы понять, что будут писать в комментах, надо хотя бы по диагонали пробежаться, чтобы понимать о чем там пишут в комментах, поэтому читаю.
19. 1c-intelligence 12808 29.06.21 14:00 Сейчас в теме
(16) всё, теперь понял, спасибо.
39. RocKeR_13 1337 30.06.21 18:03 Сейчас в теме
(5)
А на деле клиент хочет флажок, его и просит сделать.

А потом получаем от клиента: я думал, что вы при добавлении флажка учтете то-то и вот это (это же логично!), а так вы сейчас сделали плохо. Есть такие клиенты)
10. Yashazz 4751 29.06.21 12:49 Сейчас в теме
Даже если вы сидите у клиента, уровень неопределённости как минимум такой же. А то и выше. Остальное - вода.

Единственный способ снизить неопределённость - как следует провариться в специфике автоматизируемой области. Узнать всю изнутри. Освоить, пожить в этом. Вот когда оно в подкорке и на кончиках пальцев будет, от и до, тогда вы сможете автоматизировать более-менее адекватно. И никакой супер-методист или аналитик, с наскока да с разгона, вам реальную картину не даст. Только погружение.
teyana; m_aster; +2 Ответить
13. 1c-intelligence 12808 29.06.21 13:28 Сейчас в теме
(10) т.е. вы знаете только один вариант обучения - пожить в специфике?
17. Yashazz 4751 29.06.21 13:49 Сейчас в теме
(13) Взаправду результативный - да, только этот. Более 20 лет практики подтверждают. Один раз был клиент, сам технарь с близким к IT образованием, он задачи отлично ставил, да ещё были простые задачи, но это исключения, а в сложных случаях, имхо, только так.

Только не обучения, а того, о чём я написал - адекватной автоматизации.
20. 1c-intelligence 12808 29.06.21 14:02 Сейчас в теме
(17) меня интересует обучение адекватной автоматизации.

Сказать "поработайте 20 лет и всё поймёте" - не так сложно. Мне когда неохота новичку что-нибудь объяснять, я тоже так говорю (только у меня 15 лет). Но задача "обучить адекватной автоматизации" при этом остаётся нерешённой.

А мне её надо решить, увы. Поэтому приходится думать и пробовать.
oleg-m; LeXXeR; +2 Ответить
23. Богатырев Артур 125 29.06.21 14:55 Сейчас в теме
(20)
не когда неохота новичку что-нибудь объяснять, я тоже так говорю

А вот тут вы совершаете ошибку. Даже две.
1. На сложную задачу не посылают новичка.
2. Обьяснять надо. И не хочешь, а надо. Иначе новичок никогда не станет опытным, или накосячит.

(20)
Но задача "обучить адекватной автоматизации" при этом остаётся нерешённой.

Она решается достаточно просто - анализуруем задачу и по ней выбираем один из вариантов.
Излишняя спешка тут неуместна - она уместна только при ловле блох и на пожаре.
У нас вообще пренебрегают порой анализом задачи, хотя это очень важно на крупных задачах.
Вы верно описали инструменты, так держите их все при себе.
Ремонтник же ходит на починку унитазов не только с 1 разводным ключом.
24. 1c-intelligence 12808 29.06.21 15:01 Сейчас в теме
(23) мне надо учить людей, которые не сидят рядом со мной и должны делать всё сами, без меня.
32. Богатырев Артур 125 30.06.21 07:46 Сейчас в теме
(24) но процессом то вы руководите все равно?
33. 1c-intelligence 12808 30.06.21 07:47 Сейчас в теме
(32) далеко не всегда, и это ограничение надо научиться преодолевать.
37. Богатырев Артур 125 30.06.21 14:54 Сейчас в теме
(33) вот тут момент не понял - у вас есть удаленные сотрудники-новички и они не учатся?
25. starik-2005 3051 29.06.21 15:51 Сейчас в теме
Статья хорошая, но она, к сожалению, школьникам зайти вряд ли сможет - их всю жизнь учили, что ответы делятся на правильные и остальные.
26. Akcium 311 29.06.21 16:42 Сейчас в теме
Доп.реквизит можно вывести в форму списка через настройку формы, если у объекта с доп.реквизитами настроены характеристики (у всех типовых в актуальных версиях конфигураций это сделано). Аналогично - контактная информация.
После этого можно на расширении реализовать необходимую бизнес-логику с простыми алгоритмами в формах или объектах.
27. 1c-intelligence 12808 29.06.21 17:09 Сейчас в теме
(26) спасибо. Я честно искал, как в заказе вывести - не нашёл.
28. pm74 202 29.06.21 21:04 Сейчас в теме
сейчас в типовых конфигурациях на все стандартные обработчики формы, вешаются вызовы общих модулей (УправлениеСвойствами, СобытияФорм итд) ,так что вывести доп. реквизиты раздать доступы ... , вообще не проблема .
да и в обычных формах ут 10 , упп ... не было особых проблем
myoker; m_aster; +2 Ответить
29. m_aster 112 30.06.21 00:57 Сейчас в теме
Иван, спасибо вам за интересные статьи.
Почему бы не использовать доп. реквизиты как механизм ограничения доступа. Это типовой механизм
с привязкой к основной таблице объекта. Это если мы мыслим на уровне таблиц, т.е. как это нагружает систему плюс минимум доработок. Если вы ограничите доступ к элементам таблицы доп. реквизитов, то ничего вроде и придумывать не нужно, все уже есть, тем более, что 1С рекомендует по максимуму использовать типовые механизмы.
30. itoptimum 24 30.06.21 06:40 Сейчас в теме
допреквизит+расширение.
31. 1c-intelligence 12808 30.06.21 07:03 Сейчас в теме
(30) если дошло до расширения, зачем доп. реквизит?
34. itoptimum 24 30.06.21 07:57 Сейчас в теме
(31) в условии не сказано о режиме совместимости. допреквизит универсальнее
35. 1c-intelligence 12808 30.06.21 07:59 Сейчас в теме
(34) а режим совместимости причём?
40. RocKeR_13 1337 30.06.21 18:06 Сейчас в теме
(35) до определенного режима совместимости свои реквизиты нельзя было добавлять в расширении
36. roman72 382 30.06.21 10:41 Сейчас в теме
Описанная в статье ситуация - следствие прямого "программистского" подхода без аналитической и архитектурной проработки, без моделирования. Задача поставлена - решается "на горячую" программистом в рамках его умения и желания предсказать поведение системы и пользователя. Если программист подумает, что у него дел много и "любой каприз за ваши деньги", то решит задачу быстро, не парясь циклом жизни и развития результата "хотелки" заказчика. Проблемы превращения архитектуры в кашу десятками таких допилок - не проблема программиста, а его хлеб.
Одно только смущает - кому оно такое "моделирование и архитектура" надо, когда задача в исходном виде - выглядит проще пареной репы.
41. m_aster 112 30.06.21 18:23 Сейчас в теме
(36)Что не так с "программистским" подходом? Я не согласен с Иваном в следующем контексте:
"Когда принимаете решение, каким образом внести изменения в конфигурацию, помните: правильного ответа нет".
Правильный ответ есть и его дает 1С - по максимуму использовать типовой механизм.
В данной случае все уже проработано и архитектурно и аналитически, есть готовое решение, вопрос в ограничении доступа к объекту по признаку для конкретного пользователя и для всех остальных.
Уже написал выше, вопрос почему не использовать то, что есть - механизм доп. реквизитов, плюс через расширение добавляйте роль, там же прописывайте настройки RLS.
42. roman72 382 01.07.21 10:38 Сейчас в теме
(41) Не так с "программистским" подходом примерно то же что и с автоэлектриком, который в автосервисе и кузовщиком работает и красит авто и двигатели перебирает. Не запрещено. Может человек, почему бы не делать. Но когда от одного хотят всего, то волей-неволей этот один начинает сжимать время выделяемое на "продумать", "зафиксировать архитектуру". Все хотят быстрых решений (заказчики). Если не париться архитектурой и сроком жизни ПО, то сесть и набить код по простейшему варианту решения - хотелка заказчика выполняется быстро и оплачивается.
43. dmitrichenko.ivan 6 03.07.21 13:35 Сейчас в теме
А почему нельзя добавить реквизит в расширение, добавить в расширение процедуру "ПриСозданииНаСервере" модуля "МодификацияКонфигурацииПереопределяемый" и там его уже и выводить на форму программно, и делать всё,что душе угодно?)
Оставьте свое сообщение