Изменение вида контрагента; предотвращение ввода неверного вида контрагента; мониторинг заполнения полей контрагента

При проектировании конфигурации Торговля и Склад 7.7 фирма 1С сделала ошибку интерфейса, установив по умолчанию одно из значений ВидКонтрагента в ЮрЛица. В результате пользователи вводят подавляющее большинство контрагентов как юрлицо. Проблема осложняется тем, что эти ошибки проблематично отловить и исправить в пакетном режиме.

Данная несложная модификация элемента справочника контрагента и списка контрагентов предназначена для
— предотвращения ошибочного указания вида контрагента на этапе ввода;
— ручного исправления вида контрагента путем изменения вида контрагента;
— мониторинг правильности указания вида контрагента и правильности указания ИНН прямо в списке контрагентов с помощью пиктограмм.

Подробности см в описании ниже U95;

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

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

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

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

Незначительная модификация кода формы элемента справочника «контрагенты» исправляет это недоразумение. Теперь при изменении вида контрагента поля, имеющие одинаковый смысловой тип (наименование, полное наименование, телефоны, ИНН, адреса юридический и фактический), заполняются копированием значений полей из другого слоя.

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

Старый, неверный элемент юрлицо или физлицо, оставшийся в другом справочнике, при этом НЕ помечается на удаление. Пометить на удаление такие элементы можно несложной обработкой поиска содержания элемента юр- или физлица в реквизите «ЮрФизЛицо» справочника «Контрагенты».

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

А именно, добавлен столбец с пиктограммой (см скриншот ↓). Поле с пиктограммой может содержать четыре иконки: если контрагент является физлицом или ИП, отображается один человек. Если это юрлицо — несколько человек. Плюс копии этих двух иконок с красными маркерами, указывающими на ошибки в данном элементе.

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

Аналогично проверяется физлицо, имеющее признаки ООО (вхождение строки «ООО» в наименование и в полное наименование, длина ИНН, наличие символа «» в позиции 11).

В завершение реализована автоматическая замена символа-разделителя ИНН от КПП «/» на «», что избавляет пользователя от необходимости искать правильный символ, применяя различные клавиши-модификаторы.

Для программистов:

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

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

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

Изменены: Форма элемента, код формы элемента, форма списка, код формы списка.

Для управленцев (организаторов рабочих мест):

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