Мобильное приложение для контрольно-пропускного пункта + схема работы КПП

1. Цели и задачи внедрения решения

Есть некая оптово-розничная компания, имеющая около 20 универсальных торговых баз, занимающих значительные площади и включающих в себя до 10 открытых и крытых товарных складов на каждой из баз. ИТ оснащение складов отсутствует по разным причинам: сложности и дороговизны организации соответствующей ИТ-инфраструктуры (оборудование, которое может работать круглый год в сложных физических условиях на открытом уличном складе цемента или пиломатериала стоит дорого), специфичный контингент работающего персонала, ограниченный штат ИТ отдела. Вот в этой организации, с недавних пор стали выявляться случаи подделки товарных документов и вывоза с территории базы ТМЦ на суммы значительно большие (на несколько порядков), чем отраженные в учетной системе. Возникла потребность разработки решения, позволяющего сотрудникам службы безопасности оперативно сравнивать состав, количество товара в выезжающей машине с составом накладной в информационной базе, суммы в бумажной накладной с суммой накладной в ИБ и получать данные о времени проведения накладной в ИБ. Было рассмотрено множество вариантов (от микрокиоска до монитора за стеклом на кпп и выведенным наружу скнером штрихкода). Самым рациональным показалось решение выдать охранникам ТСД с оперативным доступом к информационной базе. Пробовали и RDP соединение с сервером поднимать на терминале, но для дедушки охранника, бывшего милиционера запустить RDP клиент на ТСД это челендж + потери соединения + работа с 1с интерфейсом на маленьком окне без мыши походить на кошмарный сон: хочешь бежать, а тебя будто кто-то держит за ногу сзади. Опять-же были приглашены видные оутсорсеры от 1с (Р…ус, например ), которые предлагали решения на суммы от 40 т.р. за терминал с вялыми ТТХ, что на мой взгляд дороговато. Особенно, с учетом того, что в Китае устройство с ТТХ превышающими предлагаемые в 2 раза стоят от 16 т.р. Руководство дало установку сэкономить, и обещало премию за внедрение более дешевого варианта. Ничто так не стимулирует, как премия. Ознакомился я с существующими платформами разработки и выбрал Xamarin по причине ее универсальности, гибкости и наличия множества сторонних библиотек для работы с оборудованием устройств, а также возможности разработки универсальных(!) решений под Андроид, iOs и Windows. Да и вообще, инетересный очень опыт. Может пригодиться в жизни. 1с mobile меня насторожил по причине слабой поддержки оборудования, с перехватом броадкаста проблемы… Все это пока напоминает фирменную игрушку от 1с. Короче не рискнул… и поступил не патриотично. Использование Xamarin + Visual Studio 2024 — отдельная трагедия в нескольких томах, но в общем, ничего неразрешимого я не встретил. И самое главное — все, что задумал, средства среды позволили реализовать, хотя и с трудозатратами раза в 3 большими, чем в 1с.

2. Аппаратная часть часть решения

Для работы решения подходит, в принципе, любое устройство на Андроиде, будь то планшет, терминал сбора данных или даже телефон. Основные требования: 1. Наличие любого подключения к сети (локальной или интернет), 2. Наличие камеры с разрешением, достаточным для распознавания штрихкода и (или) наличие лазерного считывателя штрихкодов (1D или 2D). Уровень защищенности от внешней среды следует учесть при выборе устройства под конкретные условия эксплуатации и персонал. Стоимость таких устройств начинается от 16 т.р. Приобретали 2 модели китайских устройств разных производителей. Обе проблем при установки софта, работе лазерного сканера и емкости аккумулятора, а также по надежности работы не вызвали. Срок эксплуатации уже ок. 2 мес. Требования по серверной части: любой сервер, способный тянуть базу 1с + апач.

3. Программная часть решения

Решение состояит из приложения под ОС Андроид, версии не ниже 4.1 и HTTP-сервера, обрабатывающего запросы от мобильного приложения. В принципе, на стороне сервера может быть не обязательно 1с-сервер, но и простенький сервис на php + СУБД на mySQL. 

Мобильное приложение осуществляет сканирование штрихкода, подготавливает соотвесттвующую json структуру и передает ее на сервер. Сервер производит  весь анализ данных и передает обратно JSON-структуру такого-же класса, с подготовленной аналитической информацией. В связи с тем, что кодинг в 1с в разы проще, чем на Xamarin, такой подход позволяет быстро изменять логику работы решения и даже отображаемые пользователю мобильного приложения сообщения. Формат обменной JSON-структуры такой: 

   

public class OutputScanData
{
public string Barcode;
public string Purpose = "";
}

В коде 1с она десериализуется в структуру: 

сткВх = новый Структура("Barcode, Purpose")

Мобильное приложение от сервера обратно получает данные в следующей структуре (JSON):

public class InputInfo
{
public string DocumentDate;
public string DocumentTime;
public string DocumentNumber;
public string DocumentSum;
public string BarcodeStatus;
public string Description;
public string Barcode;
public List<Goods> Goods;
}
public class Goods
{
public string Name { get; set; }
public string Sum { get; set; }
public string Amount { get; set; }
}

Или в коде 1с: 

сткВых = новый структура("DocumentDate,DocumentTime,DocumentNumber,DocumentSum,BarcodeStatus,Description,Goods, Barcode"
"","","","","","",новый массив,"");

сткВых.Goods.Добавить(новый структура("Name,Sum,Amount","","",""));

После получения данных с сервера, мобильное приложение отражает их на главной странице. При сканировании следующего штрихкода, либо при нажатии кнопки "Закрыть чек" на сервер передаются инструкция по закрытию чека. Формат структуры такой-же, как при передаче штрихкода, изменяется только значение члена "Purpose".

Вот так в двух словах работает решение.

Возможности мобильного приложения:

1. Сканирование штрихкода с использованием камеры (используется библиотека zxing)

2. Сканирование штрихкода с использованием аппаратного лазерного сканера устройства. Механизм: любой аппаратный сканер штрихкода, работающий на самых массовых ТСД под управлением ОС Андроид, генерирует системное броадкаст сообщение. Его получают все подписавшиеся на сообщение приложения. Сообщение идентифицируется именем фильтра броадкаста ("Action" — в терминологии SDK Андроида) и именем параметра броадкаст-сообщения ("Extras" — в терминологии SDK Андроида). В общем, китайцы, хоть и соседи, хоть и обещали SDK к проданному устройству, но то-ли восток — очень тонкое дело, то-ли английский у них очень ломаный был и друг друга мы не поняли, но SDK они нам не прислали. Пришлось вооружиться Андроидным отладчиком (LogKat) и задампить все системные сообщения ОС в течении 3х секунд после срабатывания лазера на ТСД. Текстовый поиск по полученному дампу строки со словом <intent> дал результат вроде …… Intent<scan.rcv.enter>…… Снарядив перехватчик с таким фильтром, но уже в отладчике Xamarin, я перехватил броадкаст и уже там расколупал структуру данных и нашел имя переменной со штрихкодом: "codestr". 

В общем, вот таких небольших проблемок было достаточно, конечно. Но решить их удалось почти все.

3. Автофокус сканера (при сканировании камерой) с изменением частоты цикла автофокуса.

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

5. Все настройки имеют подобранные эмпирически оптимальные значения "по умолчанию".

6. Подсветка при сканировании камерой в темное время суток (включается автоматически при начале сканирования).

7. Пароль супервизора на изменение настроек приложения (уж очень руки неспокойные у охранников).

8. Отображение аналитической информации по накладной (длительность жизни, погашенность, большая сумма и т.д.)

9. Брутальный фон. На самом деле почему-то цвет фона у приложений на Xamarin белый и я потратил кучу времени, чтоб сделать его черным и стильным, но зато теперь белые буковки на черном фоне на солнышке видны хорошо, а вот черные буковки на белом фоне при сильном дневном свете — сливаются.

10. И да, есть автообновление. Но я его отключил. Вообще в Андроиде автообновление — вещь хитрая. Его можно реализовать двумя способами. Через GooglePlay, который проверяется на наличие обновлений всего установленного софта штатным сервисом ОС и, при наличии обновлений, тихо их ставит. Но вот не хочу я приложение класть в GooglePlay по причине его узкоспециализированного использования. Второй способ реализуется через скачивание файла установочного пакета и запуск намерения ("Intent" — в терминологии SDK Андроид) на установку приложения. Вот все-бы хорошо, но есть 2 проблемы: 1. Устанавливать приложения "тихо" Андроид разрешает только с рут-правами, которые надо получить разными сторонними тулзами, иначе вылезает запрос на разрешение установки. Но это мелочь. Раз в месяц пользователь может и нажать Install. 2. А вот сохранение скачанного файла в ОС Андроид — это проблема. Система дает сохранить файл только на внешний накопитель, т.е. флэшку. На встроенную память ось сохранять произвольное файло не дает. Бился я долго над этой задачей, ибо оснащать каждый ТСД еще и флэшкой — не вариант. Этот вопрос задает много народу — от индийска до американска программиста, но рабочего решения чего-то никто не предложил. Ну, подумав, решил, что допиливать я софтину буду редко и отложил пока вопрос. Хотя весь код в исходниках есть.

11. Возможность работы с произвольным HTTP сервисом и унифицированность формата передаваемых данных.

Для запуска решения в архивах в эксплуатацию требуется следующее программное оснащение:

— ОС андроид

— http-сервер (Апач или IIS).

— 1с