Основная тенденция автоматизации - сократить участие человека в процессе - мы пытаемся уйти от ручного ввода - вместо человека (вместе с ним) пытаемся использовать сканирование, распознавание, автоматическую загрузку документов, заполнение документа самим клиентом.
Это тенденция, а практика такова, что он - ручной ввод на стороне поставщика (оператора внутри нашей компании) - останется с нами ещё на долгие годы и прекратит своё существование только тогда, когда ИИ (при распознавании речи заказчика) достигнет понимания на уровне понимания человека-человеком, автоответчик при заполнении документа справится со всеми пожеланиями сам.
А если это так, то проблема поиска в "библиотеке" продаваемых компанией продуктов при работе оператора - со справочником номенклатуры - останется актуальной на долгие годы.
Как же ускорить работу оператора?
Обратимся к инструментарию:
Посмотрим, что у нас на сегодняшний день есть в арсеналах на примере современной ЕРП/УТ/КА - мы начинаем набирать "искомый" текст и в списке выбора появляется список "подходящих" элементов.
При вводе по строке инициируется событие "ОбработкаПолученияДанныхВыбора" и если мы хотим изменить стандартное поведение платформы, то, расположив такую процедуру в модуле менеджера справочника и отказавшись от стандартного, можем получить нужный результат.
"Возникает на сервере перед стандартным формированием списка при вводе по строке, автоподборе текста и быстром выборе, а также при выполнении метода ПолучитьДанныеВыбора."
Что собственно, в конфигурациях ЕРП/УТ/КА и сделано.
В ЕРП/УТ/КА при этом идёт обращение к процедуре общего модуля НоменклатураВызовСервера.НоменклатураОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка); внутри которой собственно и формируется список значений для выбора.
Поиск осуществляется по шаблону СтрокаПоиска + "%" - по совпадению с начала.
Результатом обработки является список, подходящих элементов, упорядоченных по реквизиту "Порядок"
0 - Наименование
1 - Код
2 - Артикул
3 - Код для поиска
Количество, возвращаемых элементов, ограничивается 50 различными значениями.
Вернёмся к проблеме:
Каждый, наверное, согласится, что выбор нужного значения, даже из 10 вариантов уже может быть затруднителен. Что тогда говорить о похожих 50. А чем больше в базе номенклатуры, тем больше их похожих.
Т.е. чем меньше отображенных вариантов, тем быстрее оператор выберет необходимый.
За счет чего можно этого добиться? Вернёмся к используемым реквизитам:
Наименование - вводится в базу нами и ничто не мешает при его вводе использовать определённые правила, ну, например, всегда начинать наименование товара с существительного, определяющего товар "Бумага белая", в противовес "Белая бумага".
Следование таким правилам не решит нашу задачу - чем больше в базе номенклатуры, тем больше будет таких совпадений.
Код - заполняется базой автоматически, хотя может и редактироваться вручную. Можно установить свои правила и придерживаться их, но слишком накладно, тем более что он должен быть уникален.
Артикул - вводится в базу нами, и как и с наименованием мы можем при вводе придерживаться какого-то шаблона. В Интернете можно поискать "Как правильно составить артикул" и получить массу рекомендаций. Ну, например, как вам "Итоговый внутренний артикул товара - 05M3818R0102AU из которого понятна практически вся информация о элементе каталога."? И как быть, если мы вводим в базу "чужую" номенклатуру с имеющимся артикулом поставщика?
Код для поиска - вот собственно и цель публикации - смею предложить следующий алгоритм использования данного реквизита в практической работе для ускорения ввода оператором номенклатуры:
- заполняем наименование номенклатуры по "узаконенным" нами правила, например "Тип-Бренд-Модель-Прочее" ("Сотейник Tefal Original Cook, с крышкой, диаметр 24 см", "Одеяло Green Line Delphia Теплое Цвет: Белый (140х205 см)")
- заполняем код для поиска по "мнемоническому" алгоритму, кодируем его по первым буквам слов наименования, отбрасывая "запрещённые" символы (кавычки, запятые,точки, скобки и прочее).
Похожее изделие другого бренда "Сотейник TimA "Art Granit", с антипригарным покрытием, со съемной ручкой. Диаметр 24 см", не будет совпадать по коду поиска уже с третьего введённого символа.
Тут возможны "различные" вариации, в зависимости от области деятельности компании, кому-то подойдёт заполнять всё и это можно реализовать "простым" заполнением реквизита "ПередЗаписью", кому-то "посложнее", с учетом, допустим вида номенклатуры, только для определённых групп номенклатуры, оператор по первым двум введённым символам сразу поймёт надо ли использовать мнемонику.
Кто-то возможно обработает имеющую в базе номенклатуру групповой обработкой и будет периодически анализировать текущее положение и что-то менять по результатам.
Приведу пример функции, формирующий код для поиска по первым буквам наименования
КодДляПоиска = ВернутьКодДляПоиска("Сотейник TimA "Art Granit", с антипригарным покрытием, со съемной ручкой. Диаметр 24 см", 4); // второй параметр - максимальная длина возвращаемого кода
Как вариант усовершенствования можно предложить преобразование всех символов к русскоязычной раскладке, при вводе по строке вряд ли удобно помнить что что-то в латинице и переключаться. На Инфостарте есть Транслитерация из латиницы в кириллицу, но придётся вероятно разбираться с нюансами, "СТАГ" для вышеуказанного сотейника годится, но что-то может и плохим вариантом.
Как показала практика операторы очень быстро привыкают к такому использованию мнемоники, старожилы сразу оценят "нововведение", а у новичков операторов уменьшится число вопросов и ошибок - скорость работы с документом повышается в разы.
А как же быть "счастливым" пользователям тех баз, где этого механизма нет - БП и УНФ?
Воспользуйтесь приложенными расширениями, добавляющими работу с кодами для поиска в эти конфигурации.
Номера релизов на которых расширения работают: Бухгалтерия предприятия, редакция 3.0 (3.0.74.69) и Управление нашей фирмой, редакция 1.6 (1.6.19.215)
Для работы расширения необходимо отключать безопасный режим.
