Правильного ответа нет
Когда принимаете решение, каким образом внести изменения в конфигурацию, помните: правильного ответа нет. Всё всегда зависит от контекста, обстоятельств, динамики развития типовой конфигурации, принятой у клиента сложности и интенсивности доработок, ну и вашего желания заработать сейчас и в дальнейшем (или желания/политики вашей компании).
Попытки найти «правильный» способ доработки иногда ставят в тупик даже опытных программистов, потому что, если вы не сидите у конечного клиента, любая доработка связана с высокой неопределённостью. И вы никак эту неопределённость не разрешите, находясь здесь и сейчас.
Однако, это не значит, что изменения надо вносить, как попало. Надо взвесить плюсы и минусы каждого способа, разделив их на две категории: «сейчас» и «потом». И, по возможности, рассказать клиенту, чтобы выбрал. Если у него есть более или менее приличная история доработок своей системы, он должен, хотя бы примерно, понять, о чём речь.
Рассмотрим несколько примеров.
«Добавь поле, зачем – потом решу»
Заказчик – начальник отдела продаж. Просит добавить флажок «Согласовано» в заказ покупателя/клиента, чтобы был доступен для редактирования только ему. Флажок должен быть виден в формах документа и списка. Цель – проверять все заказы, вдруг там чё не так. Заказчик говорит, что до сего момента обходился комментариями, но это неудобно – менеджеры же сами могут там что-нибудь написать, в том числе и как бы согласовать себе заказ.
Принципиально у вас три варианта, как добавить поле – прямо в конфигурацию, через расширение или использовать доп. реквизиты. Если конфигурация старая, вроде УПП или УТ 10.3, то вариант с расширением исключаем (если только у клиента не повышен режим совместимости до 8.3).
Добавить доп. реквизит
С точки зрения «сейчас» самым простым кажется вариант добавить доп. реквизит. На это уйдут буквально минуты, и пользователю даже не придётся перезапускать 1С. Реквизиту можно дать имя (чтобы потом использовать в коде), вывести на форму документа.
Только с формой списка загвоздка – туда доп. реквизит, скорее всего, не выведется. Управлять видимостью реквизита в зависимости от текущего пользователя тоже не получится – механизм видимости/доступности умеет реагировать только на свойства документа, а не на атрибуты контекста, вроде текущего пользователя или его ролей.
Так что, пожалуй, забудем про этот вариант в данной постановке задачи, он не годится. Либо придётся убеждать начальника отдела продаж, что менеджеры не будут нажимать на флажок только потому, что он доступен для нажатия.
Ну и, конечно, неприятная гадость в том, что при копировании заказа значение нашего флажка также будет скопировано. Менеджеры быстро просекут эту фишку.
Теоретически, можно рассмотреть вариант и доп. реквизит использовать, и код его обработки внести в конфигурацию или расширение – обработку копирования, код видимости, в дин. список на форме списка вывести. Если клиент – ваш лютый враг, то можно и так попробовать.
Добавить через расширение
Второй вариант – использовать расширение. По трудозатратам, в данной задаче, он примерно равен добавлению реквизита прямо в конфигурацию, т.к. расширить вам придётся и сам заказ клиента, и две его формы. Плюс, точно так же придётся выгнать всех пользователей, чтобы обновить конфигурацию БД.
Через расширение получится реализовать всю функциональность, требуемую начальнику отдела продаж в данный момент. Неприятным местом станет форма списка – будут муки выбора на тему вывода колонки, сделать это кодом или просто добавить в расширенную форму.
Добавить в конфигурацию
Вариант в лоб – просто взять и добавить в конфигурацию. Всё достаточно просто и быстро. Но этот вариант всё чаще отвергается потому, что конфигурацию надо снимать с поддержки, плюс мифическое «увеличение стоимости обновления», зачастую – из-за лишения пользователя возможности выполнять обновления самостоятельно.
Влияние на последующие обновления
Первый вариант, с доп. реквизитом, тоже оценим, хоть мы его и отвергли. Если мы просто добавили доп. реквизит, то на последующие обновления это никак не повлияет.
Вариант с расширением, в текущей реализации, на обновление будет влиять слабо. Разумеется, будет дёргаться режим совместимости. Также иногда будут сбоить формы, особенно форма списка.
Доработка конфигурации окажет самое серьёзное влияние на обновления – они станут «нетиповыми», т.е. их не сможет выполнять ни сам клиент, ни большинство сервис-инженеров (или как их там называют).
Таким образом, если смотреть на задачу в первом приближении, не пытаясь угадать, что с этим флажком будет дальше, то выбор очевиден – надо делать через расширение. Стоимость невелика, влияние на последующие обновления – тоже.
А что будет дальше?
Варианты развития доработки
В первом варианте реализации наш флажок не оказывает на систему никакого управляющего влияния. Опыт эксплуатации систем подсказывает, что очень скоро начальник отдела продаж захочет, чтобы несогласованные заказы нельзя было, как минимум, отгружать.
Если задача звучит именно так – «запретить отгружать без согласования» - то перед нами опять дилемма. Предположение, что на текущей постановке задачи всё закончится, нас уже подвело – добавлением флажка дело не ограничилось. В принципе, можно снова повестись на неумение или нежелание клиента проектировать архитектуру на несколько шагов вперёд, а самим прикинуться дурачками, исповедующими «позадачный подход» (когда объектом рассмотрения и реализации является только текущая задача). Но я не рекомендую так делать.
При этом хочется, конечно, дать совет – поговорите с пользователем и спросите, как дальше будет жить эта доработка. Наверное, процента 3 клиентов смогут ответить что-то вразумительное – как правило, это люди, имеющие богатый опыт заказа доработок и их развития. Но в большинстве случаев человек исповедует тот же самый «позадачный подход» - решает свою, пользователя, текущую задачу. Поэтому, совет «сделайте вид, что пользователь – архитектор» я давать не буду.
Придётся думать программисту. Итак, мы уже наткнулись на необходимость запрета проведения реализации по несогласованному заказу. Сделать это несложно, будь у нас вариант с расширением или доработкой конфигурации. Достаточно добавить подписку на проведение реализации, и выполнить там проверку флага в документе-основании. Как думаете, на этом всё закончится?
Нет, конечно. Такой способ контроля («в оконцове») не сказать, что прям смущает пользователей… Он их жутчайшим образом выбешивает. Представьте – создаёте вы документ реализации, тщательно и с любовью его оформляете, заполняете все реквизитики, несколько раз в процессе записываете (!), а потом бац – пытаетесь провести и получаете сообщение, что нельзя отгружать несогласованные заказы.
Поэтому вас попросят сделать так, чтобы реализацию даже создать было нельзя. Соответственно, нам теперь надо вмешиваться в обработку заполнения. Вроде, ничего особо страшного, и суть доработки будет примерно такая же, как в случае с запретом проведения. Но перекроет ли запрет ввода на основании все пути заполнения реализации по заказу?
Нет, не перекроет. Что в УПП, что в ЕРП есть прекрасные обработки, позволяющие подтянуть в реализацию позиции заказов, не используя механизм ввода на основании. Обратите внимание – заказов, а не заказа. Реализация ведь может идти по нескольким заказам одного клиента. В текущий момент такая возможность у клиента отключена? Не будем наивными. Возможно, он про такую функциональность просто пока не знает.
Также, кроме ввода на основании и использования специализированных обработок подбора, человек может просто указать заказ в реализации и добавить позиции из него вручную. Теоретически, конечно, он ещё может воспользоваться групповой обработкой объектов, но этот вариант рассматривать не будем, т.к. он лежит в области настройки прав доступа.
Итак, мы наткнулись на ворох доработок, сразу по нескольким объектам, с разными вариантами реализации. Где-то надо код модифицировать, где-то – дин. списки фильтровать (в форме выбора заказа, например), количество объектов для доработки очень быстро возрастает. А ведь мы пока, всего лишь, делаем несколько удобнее – чтобы менеджер не тратил время на создание реализации по несогласованному заказу. А что дальше?
Дальше всё тоже достаточно прогнозируемо. Между заказом и реализацией ещё лежит некоторая пропасть из резервирования, размещения, заказа в производство, выставления счёта, приёма и распределения оплаты, заказа у поставщика или переработчика, сборки на складе, заказа автотранспорта и т.д. Десятки возможных действий в нескольких процессах, используемых на предприятии. Сотни мест, где теперь надо выполнить доработки. Тут и формы, и общие модули, и модули объектов/менеджеров, и обработки.
Что-то расширяется легко – например, созданием подписки или добавлением реквизита на форму. Но где-то появится зловещее «&Вместо» - и теперь нетиповое обновление будет за счастье.
Попробуйте прикинуть, как изменится соотношение затрат на реализацию и последующих трудностей при обновлении, если пойти по пути, который мы тут обозначили. Изменилось ли ваше мнение насчет использования расширения или доработки конфигурации?
Наверняка пользователь захочет видеть разделение данных по заказам на согласованные и несогласованные в отчётах. В каких – одному Богу известно. Повезёт, если пользователю будет достаточно вытащить реквизит из заказа, и группировать по нему. Но частенько группировки недостаточно – люди хотят, чтобы разделение происходило на уровне ресурсов (отдельно «Сумма согласовано» и «Сумма не согласовано») – тут уж придётся потанцевать. Повезёт, если получится обойтись пользовательскими полями. Если же нет – в ваше расширение плавно перетечёт уже половина конфигурации.
Ну и, в качестве вишенки на торт, начальник отдела продаж скажет: так-с, а давай ещё одну галочку добавим, для моего заместителя. А, нет – у нас отдел продаж на два разбился, а я теперь – коммерческий директор. Пусть у начальников отделов продаж будут свои галочки, а у меня – своя, моя любимая. А, погоди… Давай ещё юристы будут согласовывать заказ. Стоп, нафига… Бухгалтерия может? Нет, они-то причём… Не знаю, короче. Добавь пару галок про запас. Пусть пока ни на что не влияют, потом решу, что с ними делать. Здорово ведь у нас получилось!
Понимая весь путь, который нам предстояло бы пройти от маленького флажка до перекройки всей системы, напрашивается более простое и элегантное решение – тупо не давать проводить заказ, пока он не согласован. Большинство механизмов, связанных с заказом, не будут на него реагировать, пока документ не проведён (т.к. используют, в основном, его движения).
Да, чуть не забыл. Функциональность согласования заказа клиента есть в типовой конфигурации (УТ 11, КА2, ЕРП). Начальник отдела продаж просто о ней не знал. А мы, используя «позадачный подход» и чрезмерно увлёкшись качеством внесения изменений, как-то об этом и не подумали.
Но пусть вас это не смущает, мы ведь частный случай рассмотрели. В УПП и УТ 10.3 механизма согласования заказа нет.
Так какой вариант выбрать?
К чему я всё это? К тому, что написано в начале: нет правильного варианта внесения изменений.
Цепочка событий, которую я описал, может случиться, а может – и нет. Вполне вероятно, что дойдёт лишь до середины. Кто-то сам остановит заказчика, сказав, что его требования нереализуемы. Возможно, начальника отдела продаж остановят ограничения бюджета. А то и увольнение, по независящим от автоматизации причинам, а его преемник скажет: «Чё? Какую галку ставить? Оно мне надо?».
Опять же, не исключаю, что кого-то из программистов мало заботит обновляемость системы клиента. Намного важнее, например, выработка в часах. Если не думать «что будет дальше», а выполнять доработки по принципу минимальной стоимости за итерацию, то и клиент доволен будет, и, в итоге, выйдет значительно дороже. Ни в коем случае не осуждаю, просто обозначаю этот вариант, как один из возможных и влияющих на выбор способа выполнения доработки.
Ну и, не стоит исключать, что всё это делается для «проекта-проститутки» (прошу прощения, это устойчивое идиоматическое выражение) – каждая последующая итерация выполняется новым программистом, а то и стажёром. Вникать, что и как было до него – смерти подобно. Надо сделать и бежать.
По моему опыту, наиболее надёжной для прогнозирования является историческая информация о «привычках автоматизации» клиента. Большинство, всё-таки, ограничиваются добавлением флажка.
Итак. Оптимальный вариант доработки зависит не только от текущей постановки задачи, но и от её дальнейшего развития. Иногда – растянутого на годы. Соответственно, в общем случае – совершенно неопределённого. В самом начале вы пытаетесь определить лучший способ реализации неизвестно чего.
Соответственно, вы всегда будете и правы, и не правы. Абсолютной победы не будет, только минимизация ущерба.
