1. Цели и задачи внедрения решения
При разработке приложения решались сразу несколько задач, а именно:
- Обеспечить обработку наборки товара по документам перемещений;
- Обеспечить обработку оприходования товара из приходных накладных;
- Обеспечить инвентаризацию штрихкодов товаров (в .т.ч. создание новых);
- Обеспечить работу в онлайн режиме связи с 1с, посредством локальной сети, через wi-fi;
- Обеспечить дешевизну решения.
При всем, надо было сделать так, чтобы кладовщик не уставал тыкать пальцем в кнопочки и экран, а функциональность программной части можно было бы в значительной степени изменять без переустановки и обновления мобильного приложения - на стороне 1С.
2. Аппаратная часть часть решения
Для работы решения подходит, в принципе, любое устройство на Андроиде, будь то планшет, терминал сбора данных или даже телефон. Основные требования: 1. Наличие любого подключения к сети (локальной или интернет), 2. Наличие камеры с разрешением, достаточным для распознавания штрихкода и (или) наличие лазерного считывателя штрихкодов (1D или 2D). 3. Наличие микрофона. Уровень защищенности от внешней среды следует учесть при выборе устройства под конкретные условия эксплуатации и персонал. Стоимость таких устройств начинается от 18 т.р. Требования по серверной части: любой сервер, способный тянуть базу 1С + апач.
3. Программная часть решения
Решение состоит из приложения под ОС Андроид, версии не ниже 4.1 и HTTP-сервера, обрабатывающего запросы от мобильного приложения. В принципе, на стороне сервера может быть не обязательно 1С-сервер, но и сервис на php + СУБД на mySQL.
Как было ранее сказано, при разработке приложения следовало сделать его пригодным для решения наибольшего круга задач. Это привило к решению о необходимости универсализации структур данных и переноса основной бизнес-логики на сторону 1С. Проще говоря, мобильное приложение реализует только аппаратно специфичные функции (сканирование и распознавание штрихкода, запись и распознавание речи, отображение данных и интерфейс взаимодействия с кладовщиком). Приложение даже не имеет собственной СУБД (хотя она вполне несложно реализуется). Развертка СУБД повлекла бы необходимость создания планов обмена, хранения больших объемов данных на стороне ТСД, соблюдение правил синхронизации и т.д. В существующем-же решении приложение формирует запрос и передает его на сервер 1с, который возвращает минимум нужной информации. Недостаток этого подхода состоит в необходимости постоянного подключения к сети, но при тестировании решения ширина полосы пропускания 3G оказалась достаточной для комфортной работы.
Конфа 1С для формирования выходных и обработки входных структур прилагается.
Реализованный функционал:
1. Сканирование штрихкода с использованием камеры (используется библиотека zxing)
2. Автофокус сканера (при сканировании камерой) с изменением частоты цикла автофокуса.
3. Куча других настроек zxing, призванных улучшить скорость сканирования и снизить количество ошибок.
4. Все настройки имеют подобранные эмпирически оптимальные значения "по умолчанию".
5. Подсветка при сканировании камерой в темное время суток (включается автоматически при начале сканирования).
6. Сканирование штрихкода с использованием аппаратного лазерного сканера устройства. Как это работает - описал в другой статье: //infostart.ru/public/623232/.
7. Пароль супервизора на изменение настроек приложения (уж очень руки неспокойные у пользователей).
8. Возможность голосового ввода значений на русском языке (как цифр, так и фильтров поиска объектов по базе 1с). Есть один забавный момент. Например, чтобы Андроид интерпретировал слово как цифру "1", надо говорить не "один", а "раз". В остальном-же все распознает четко. Там есть куча настроек по распознаванию (уровень подавляемого шума, задержки всякие и т.д.). Я выведу их в настройки потом.
9. Возможность работы с произвольным HTTP сервисом и унифицированность формата передаваемых данных.
10. Возможность адаптации несложного функционала на стороне сервера 1С под свои потребности.
11. Возможность добавлять, изменять, удалять номенклатуру; изменять единицы, серии, характеристики и качество номенклатуры, полученной из документа (поиск производится по фильтру, к наименованию - вводится с виртуальной клавиатуры или голосом. Вид сравнения "СОДЕРЖИТ", впрочем, тоже может быть изменен на стороне 1с. Кроме того, можно добавлять к фильтру кодовую фразу с меткой вида сравнения, например "Фильтр Равен ...." или "Фильтр не равен....", а на стороне 1с это все обрабатывать. Еще раз повторяю, что Андроид речь распознает очень четко.)
12. Исходники приложения на C# (Xamarin), PCL-проект (этот вид проекта позволяет махом его расширить на использование под IOS и Windows - такая вот магия).
Исходники не выкладываю. Т.к. здесь вряд-ли кто-то будет их качать, а размер большой. По запросу - могу скинуть.
Ссылка на исходники: https://github.com/KotVezdehod/ScanBee
Там-же, в проекте, есть и сборка. Так-же называется "СБОРКА.rar". В ней то-же самое, что и здесь, в прикрепленных файлах.
P.S.
Это версия не "из коробки". Предполагается, что в конфе есть реализация сервиса по обмену данными с устройством и при мер реализации алгоритма разбора получаемых данных и подготовки отправляемых данных, а также необходимые универсальные метаданные, наличие которых обусловлено обменным механизмом.
Итого там есть:
1. Общий модуль "ПодготовкаДанныхДляТСД"
2. HTTP-Сервис "Warehouse_1_0"
3. Перечисление "ФункциональноеНазначениеУстройства"
4. РС "ТоварКОбработкеВТСД" (хранятся данные о состоянии наборки документов)
5. РС "ФункциональнаяПривязкаУстройств" (данные о функции, для которой будет использоваться конкретное устройство)
Изменения на 02.02.2018.
1.Добавлено сжатие потока данных при обмене между 1с и мобильным приложением.
Это позволяет примерно в 1,5-2 раза сократить объем передаваемых данных и время передачи.
1.1. Реализация на стороне мобильного приложения. Передаваемая структура json конвертируется в массив байтов, который затем преобразуется в поток и сжимается посредством класса DeflateStream (пространство имен: System.IO.Compression; сборка в NuGet "Microsoft.Bcl.Build" (бета-версия, но за исключением некоторых странностей поведения, свою функцию выполняет)), затем сжатый поток сохраняется в массив байтов и преобразуется в строку BASE64, которая и передается на сторону 1с. Прием - в обратном порядке.
1.2. Реализация на стороне 1с (очень весело). 1с так и не сделала класс для сжатия и извлечения потоков данных, хотя и есть объекты и методы для работы с двоичными данными, чтения zip-архивов и сжатия данных, помещаемых в хранилище значений. Но вот чтобы все вместе, т.е. работа с потоком сжатых данных - нет. Это проблема. Пришлось воспользоваться методами из публикации //infostart.ru/public/618906/ В общем, все работает.
2.Добавлена подсветка строк в таблице товаров документа, по которым набранное количество отличается от количества к наборке.
2.1. Реализация на стороне мобильного приложения. Используется интерфейс "IValueConverter".
3.Добавлена подсветка строк в таблице товаров документа, по задаваемой строковой метке.
Например, в документе 50 позиций к наборке. Товар разложен по типу (краска, гвозди, молотки и т.д.). Штрихкодов, чтобы их ловко отсканировать - нет. Посредством новой фичи, оператор может введя строку поиска подсветить в списке товары определенного вида.
3.1. Реализация на стороне мобильного приложения. Используется интерфейс "IValueConverter".
Изменения на 05.03.2018.
1. Реализовано чтение настроек через сканирование штрихкода, созданного на стороне 1с.
Чтобы не забивать настройки в ТСД (т.к. это утомительно делать на нескольких устройствах) на стороне 1с в регистре сведений "Настройки ТСД" создаются записи с настройками для каждого устройства. При нажатии в форме записи регистра кнопки "показать штрихкод" на экране отображается QR-код с сжатыми алгоритмом Deflate и завернутыми в BASE64 настройками. На стороне ТСД они могут быть прочитаны камерой и применены к устройству. Все это делается за 10-15 секунд.