Зміна виду контрагента; запобігання введення невірного виду контрагента; моніторинг заповнення
При проектуванні конфігурації Торгівля і Склад 7.7 фірма 1С зробила помилку інтерфейсу, встановивши за замовчуванням одне із значень ВідКонтрагента в юрособи. В результаті користувачі вводять переважна більшість контрагентів як юрособа. Проблема ускладнюється тим, що ці помилки проблематично відловити і виправити в пакетному режимі.
Дана нескладна модифікація елемента довідника контрагента і списку контрагентів призначена для
- запобігання помилкового вказівки виду контрагента на етапі введення;
- ручного виправлення виду контрагента шляхом зміни виду контрагента;
- моніторинг правильності зазначення виду контрагента і правильності вказівки ІПН прямо в списку контрагентів за допомогою піктограм.
Детальнішу інформацію дивіться в описі нижче U95;
1. Щоб запобігти невірне зазначення виду контрагента необхідно при введенні нового контрагента дати користувачеві зрозуміти, що він повинен прийняти рішення щодо виду нового контрагента.
Для цього при введенні нового контрагента (тільки при введенні нового) додається нове значення виду контрагента "не вибрано" і призначається поточним. Відповідно, користувачеві демонструється порожній шар з написом про необхідність вибору виду контрагента (див скріншот ↓).
Після першого ж вибору виду контрагента відмінного від "не вибрано". "Не вибрано" відразу ж видаляється, щоб виключити можливість заповнення неактуальних реквізитів і повернення в порожній шар.
При відкритті вже записаного елемента значення "не вибрано" не виникає.
Крім того, внесено зміни до назви видів контрагентів, щоб вони більше відповідали дійсності і уявленням користувачів.
2. Ручне зміна виду контрагента є в типовій конфігурації проблемою. Оскільки при виконанні цієї операції користувачеві виводиться інший шар з іншими елементами, які, природно, ніхто не заповнював. Користувачеві ж здається, що відбулося очищення заповнених полів, на що він резонно робить невтішну ремарку в сторону розумових здібностей програмістів в загальному і фірми 1С зокрема.
Таким чином, щоб змінити вид контрагента вручну, досить в випадаючому списку вибрати інший вид контрагента і зберегти елемент. При цьому алгоритм спробує знайти у відповідному довіднику (юросіб або фізосіб) елемент з таким ІПН (якщо ІПН не вказано, здійснюється пошук по найменуванню) і прив'язати його до контрагента. Якщо елемент знайти не вдасться, створиться новий.
Старий, невірний елемент юрособа або фізособа, що залишився в іншому довіднику, при цьому НЕ позначається на видалення. Помітити на видалення такі елементи можна нескладної обробкою пошуку змісту елемента юр- або фізособи в реквізиті "ЮрФізЛіцо" довідника "Контрагенти".
3. Для того щоб полегшити користувачам пошук контрагентів, що містять невірний вид контрагента і заодно вказати на помилки при заповненні ІПН. була злегка модифікована форма списку контрагентів.
А саме, доданий стовпець з піктограмою (див скріншот ↓). Поле з піктограмою може містити чотири іконки: якщо контрагент є фізособою або ІП, відображається одна людина. Якщо це юрособа - кілька людей. Плюс копії цих двох іконок з червоними маркерами, що вказують на помилки в даному елементі.
Якщо контрагент має ознака фізособи (у найменуванні і в повному найменуванні міститься по входженню рядок "ІП", плюс контроль кількості символів ІПН), але при цьому контрагент в базі має статус юрособи, виводиться піктограма фізособи з добре відомим червоним маркером (див скріншот ↓) . Досить просто відкрити елемент, упевнитися що помилка дійсно є, змінити вид контрагента і закрити елемент зі збереженням.
Аналогічно перевіряється фізособа, яка має ознаки ТОВ (входження рядка "ТОВ" в найменування і в повне найменування, довжина ІПН, наявність символу "" в позиції 11).
На завершення реалізована автоматична заміна символу-роздільника ІПН від КПП "/" на "", що позбавляє користувача від необхідності шукати правильний символ, застосовуючи різні клавіші-модифікатори.
Дана модифікація не претендує на щось особливе в плані реалізації, але тут застосований гнучкий підхід до організації інтерфейсу і взаємодії з користувачем.
Немає жорстких вимог: "заповни всі поля як треба або не дам записати елемент", що часто дратує користувачів і знижує їх продуктивність. Разом з тим, прості помилки будуть виправлені алгоритмом автоматично, а вимагають втручання користувача, будуть нагадувати про себе, дозволяючи користувачеві продовжувати роботу. При цьому їх виправлення максимально спрощено і автоматизовано щоб не викликати у користувачів відторгнення "роботи над помилками" в менш завантажене час.
Приклад стилістики написання коду можна побачити на скріншоті ↓. Думаю, з інтеграцією розібратися не складно. md з модифікованими формами довідника прикріплений. Інтеграцію рекомендується здійснювати попроцедурно.
Змінено: Форма елемента, код форми елемента, форма списку, код форми списку.
Для управлінців (організаторів робочих місць):
Якщо потрібна допомога при впровадженні цієї модифікації або інших, пов'язаних з оптимізацією інтерфейсів, ми можемо почати співпрацю в цій галузі.