Сокращения:
УП - Управляемое Приложение
ОП - Обычное Приложение
ТЧ - Табличная Часть
РН - Регистр Накопления
ПФ - Печатная Форма
Сразу оговорюсь, я не претендую на звание гуру. Написать эту статью меня подвигло множество ситуаций, когда меня просят проверить работу программистов, либо когда ко мне приходят клиенты, имевшие опыт общения с предыдущими программистами. В таких случаях приходится анализировать работу коллег и зачастую плакать хочется от такой реализации (её я далее буду обозначать как "простое решение").
В работе с типовыми конфигурациями, стоящими на поддержке я придерживаюсь принципа внесения минимальных изменений в объекты, стоящие на поддержке, поэтому иногда мои решения сложнее в реализации, но легче в обновлении. Вероятно, после прочтения этой статьи кому-то станет легче жить.
Человек, а особенно программист, ленив. И каждую задачу стремится выполнить с минимальными для себя затратами. Это не всегда плохо - так рождаются рационализаторы. Но в программировании минимализм зачастую обманчив. Рассмотрим это на примерах, а для начала опишем, какие же инструменты платформы и типовых конфигураций у нас есть для реализации своего функционала без модификации стоящих на поддержке объектов:
- Подписки на события
- Внешние обработки
- Внешние обработки заполнения ТЧ
- Внешние отчеты
- В ОП Свойства / категории / характеристики
- В УП "дополнительные реквизиты" и "дополнительные сведения"
* УТ 10.3 Клиент решил использовать значения точки заказа для установки минимальных остатков номенклатуры, но пугается процесса установки значений точки заказа для каждого элемента по каждому складу.
Простое решение. Это случай из практики. Программист снимает всю конфигурацию с поддержки. Добавляет ТЧ "Остатки" в справочник "Номенклатура", назначает использование "Для группы". Модифицирует форму группы, выводя на неё эту ТЧ с колонками "Склад" и "Минимальный остаток". Кроме того создаётся отчёт, который показывает, для номенклатуры по каждому складу установленный минимальный остаток, фактический остаток на дату выдачи отчёта и необходимое количество к заказу (отклонение).
Результат. Это решение не предусматривает разные остатки номенклатуры в одной группе, не реализует возможность формирования заказов поставщикам. Самое интересное - с поддержки снята вся конфигурация целиком. Даже если бы программист приложил мозговые усилия, пришлось бы снимать с поддержки справочник номенклатуры и его форму группы.
Более оптимальное решение. Пример не типичный в том, что показывает не только разные способы реализации, но и разный уровень знания конфигурации. Итак, у нас есть стандартный механизм установки значений точки заказа - одноимённый документ и отчёт "Анализ точки заказа", в котором есть кнопка "Сформировать заказы". Выходит, надо всего лишь оптимизировать процесс заполнения ТЧ документа "Установка значений точки заказа". Сначала пытаемся создать внешнюю обработку заполнения ТЧ документа, но из кода документа следует, что внешние обработки заполнения ТЧ он не поддерживает. Ок, создаём внешнюю обработку, куда интегрируем механизм произвольных отборов на базе построителя отчётов и табличное поле для вывода результата. Отборы работают с запросом, который выдаёт нужную номенклатуру по нужному складу с текущими значениями точки заказа. Т.о. мы предоставляем пользователю мощный механизм любых отборов. Осталось только добавить функции групповой установки для отобранных позиций значений колонок "Склад" и "Точка заказа". Завершаем всё кнопкой "Создать документ", по нажатию которой создаётся и заполняется стандартный документ "Установка значений точки заказа".
Результат. Ни один объект не снят с поддержки. Задействован стандартный и мощный механизм работы с точкой заказа: теперь клиент может не только формировать отчёт по текущему состоянию дел, но и производить из него заказ позиций в необходимом количестве на нужные склады.
Тут стоит ещё пояснить, что в форме "Настройка поддержки" можно включать редактирование не только для конфигурации целиком, как это часто делают, но и для конкретных объектов выборочно. Для создания новых объектов необходимо перевести в режим "Редактирование с сохранением поддержки" саму конфигурацию (корневой элемент), но без подчинённых.
* УТ 10.3 Необходимо, чтобы документ "Чек ККМ" проводился по продажам. Стандартно это делает документ "Отчет о розничных продажах", собирающий в себя все чеки ККМ за смену.
Простое решение. Переводим в режим "Редактирование с сохранением поддержки" РН "Продажи" и документ "Чек ККМ". Добавляем его регистратором к РН "Продажи" и в обработчик проведения добавляем код формирования движений по этому регистру.
Результат. Каждый раз при обновлении конфигурации придётся переносить в новую версию модуля документа свой код.
Более оптимальное решение. Перевести в режим "Редактирование с сохранением поддержки" регистр и документ всё же придётся для добавления его в регистраторы РН "Продажи". Создаём подписку на событие "При проведении" документа "Чек ККМ". Создаём общий модуль, в котором реализуем обработчик подписки. В обработчике пишем код для движений по РН "Продажи". Теперь при каждом обновлении можно смело обновлять и документ, и РН, не забывая перед тем как нажать F7, добавить документ "Чек ККМ" в регистраторы регистра.
* Изменить роль "МенеджерПоПродажам".
Простое решение. Снимаем роль с поддержски и вносим в неё изменения.
Результат. Роли - достаточно часто изменяемый объект и теперь каждый раз при обновлении надо ручками вносить в неё нужные изменения.
Более оптимальное решение. Создаём копированием новую роль. Вносим в неё изменения и назначаем пользователям вместо оригинальной.
Результат. Теперь обновления можно смело накатывать, не забывая в конце сверить роли в механизме "Все роли". Даже если полениться и не сделать этого, мы просто не получим доступа к какому-нибудь новому объекту, но старый функционал вероятнее всего будет работать.
С интерфейсами дело обстоит аналогичным образом.
* УТ 10.3 Необходимо модифицировать рабочее место кассира. РМК является формой документа "Чек ККМ".
Простое решение. Снимаем с поддержки документ "Чек ККМ" и форму "ФормаРегистрацииПродаж". Вносим в неё изменения.
Результат. Документ стал необновляемым даже в полуавтоматическом режиме - надо вручную интегрировать изменения в эту форму.
Более оптимальное решение. Снимаем с поддержки сам документ и его форму. Да, это уже второй описываемый случай, когда в оптимальном решении вроде бы снимаются с поддержки те же объекты. Смотрите дальше. Снимаем с поддержки мы эту форму для того, чтобы переименовать. Зачем? Из глобального модуля есть обращение по имени формы в случае, если у пользователя установлен интерфейс и роль кассира.
Называем её "ФормаРегистрацииПродажСтарая". Копированием создаём форму и называем её старым именем "ФормаРегистрацииПродаж". Вносим в неё изменения.
Результат. Напротив старой формы остался квадратик поддержки с возможностью внесения изменений. Это означает, что при обновлении конфигурации платформа всё равно определит соответствие форм, хоть мы её и переименовали. Смело обновляем документ целиком.
* УТ 10.3, КА и прочие конфигурации на ОП. Необходимо создать механизм для учёта пола контрагентов (М/Ж).
Простое решение. Снимаем с поддержки справочник "Контрагенты" и его форму элемента. Добавляем перечисление "Пол" со значениями "М" и "Ж", добавляем реквизит "Пол" с типом свежесозданного перечисления в справочник. Выводим его на форму.
Результат. Снят с поддержки частообновляемый справочник "Контрагенты". Теперь каждое обновление придётся интегрировать ручками.
Более оптимальное решение. А на что нам дан механизм свойств? Создаём свойство "Пол" с типом "Значения свойств объектов", создаём значения "М" и "Ж".
Результат. Несколько действий в режиме пользователя, без внесения каких-либо изменений. Если клиент будет настаивать на отображении свойства в форме элемента, то необходимо будет по аналогии с предыдущим примером перевести в режим "Редактирование с сохранением поддержки" справочник "Контрагенты". Далее создать новую форму элемента копированием (старую оставим как есть на поддержке) и назначить её формой элемента. Я не обнаружил среди общих модулей функции, возвращающей значение свойства для объекта и в новом общем модуле реализовал её. Теперь на форме смело размещаем поле со списком или обычное поле с кнопкой выбора из списка - кому как удобней и при открытии формы заносим в список значений все значения свойства и устанавливаем текущее его значение. А при записи формы записываем выбранное значение. Это кажется сложнее, но как я уже замечал, новая форма - сторонний объект, который никак не задевает процесс обновления конфигурации. Максимум что может случиться, если в новом релизе в форме реализованы какие-либо новые механизмы, а вы обновляете конфигурацию с закрытыми глазами, то вы просто пропустите этот новый механизм, который в любой момент позже сможете добавить.
Почему более простые в реализации решения не так просты на самом деле? Нередко встречаю типовые конфигурации, сильно модифицированные и с релизами полутора-двухгодичной давности. Иногда даже с избирательной реализацией ручками каких-либо стандартных механизмов, которые появились в более поздних релизах. Как такое произошло? А всё очень просто. Программист без оглядки на будущее ломится снимать всё с поддержки и модифицировать. Через месяц ему говорят - "вышла новая версия со счетами-фактурами по постановлению 1137, которой мы так ждали; давай нам ПФ этого образца". Программер, если сильно прижмут, делает внешнюю печатную форму ручками и прилепляет к старому релизу. Так с годами изменений в типовой конфигурации накапливается целый вал и программеру машут рукой.
Уверен, не все мной предложенные решения являются наиболее оптимальнымы. Буду чуток к комментариям.
