- Для кого
- Выбор способа обмена. Описание API.
- Реализация API на стороне 1С.
- Android. Cтруктура приложения.
- BroadcastReceiver. Получаем данные ШК на примере АТОЛ Smart.Lite.
- Реализуем обмен и хранение данных. Используем Retrofit 2, Room, Coroutines.
- Пользовательский интерфейс. LiveData, PagedList.
1. Для кого
Первые две главы это попытка структурировать опыт интеграции 1С с другими приложениями и веб сервисами. Сам цикл думаю будет интересен программистам 1С, которые пытаются выйти за рамки платформы, и попробовать что-то новое. Разработчики Android приложений ничего нового для себя не узнают, но возможно им будет интересно, а как это выглядит на стороне 1С. Начиная с четвертой части будет попытка объединить несколько разрозненных статей из интернета по использованию библиотек, а также актуализировать данные по ним. Цикл задумывался как учебник, в котором описан опыт разработки реального приложения. Сам я не являюсь разработчиком под Android. Но к окончанию серии надеюсь им стать.
2. Выбор способа обмена. Описание API
В текущем виде с 1С можно связаться тысячей и одним способом. Рассмотрим несколько вариантов, и почему я их не использовал.
- Native компонента — По большей части ее хорошо использовать для Offline обмена. Для Online она плохо приспособлена. Еще хуже стало, когда 1С начала внедрять свои стандарты для обмена с торговым оборудованием. А так же данная компонента вызывается на стороне 1С. Мне не подходит.
- WEB-Сервисы — Больше предназначены для обмена между приложениями которые разрабатывают разные команды. Тяжеловесны, используют XML. Лично для меня очень тяжело разрабатывать. И еще тяжелей интегрировать в JavaScript, Golang и т.д. Не подходит.
- HTTP-Сервисы — Почти тоже самое что и WEB-сервисы, но логику работы и протоколы обмена, мы описываем полностью сами. Здесь мы не ограничены в изобретение собственного велосипеда. По этой причине был выбран именно этот механизм обмена.
Задачи которые решает наше приложение. “Все, что можно сделать на ТСД, надо делать на ТСД”. Ну а так стандартный набор: приемка, инвентаризации, этикетки, ценники.
- Работа с товарами: Печать этикеток и ценников, присвоение штрихкода(ШК), проверка ШК, удаление ШК, просмотр цен и количества по складам.
- Инвентаризация — Собственно проведение инвентаризаций.
- Поступление — Приемка товара по накладной, печать расхождений, печать внутренних документов, статусы накладной.
- Сбор товара, Реализация(Розничная) — Идея состоит в том, что продавцы не находятся за кассой, а ходят или вместе с покупателем, или собирают товар по заявке и т.д. На кассе стоит только один человек, с ТСД передается готовый чек. Покупатель, только оплачивает товар.
- Сбор товара, Реализация (Оптовая) — Собираем товар по счету. Проверяем что есть в наличии. Формируем отгрузку(с пакетом нужных документов). Не забываем про проверку на возможность отгрузки контрагенту.
- Сбор товара, подготовка к отгрузке — Собираем товар по заявкам, складываем на паллету, печатаем документы: упаковочная ведомость и т.д.
- Перемещение — Собираем товар по перемещению, отдаем в доставку.
- Сбор товара, произвольный список — Нужен для проведения переоценок, обновления ценников, этикеток, прочих подобных операций.
Возвращаемся к структуре API. Обмен между ТСД и 1С будет производится в формате JSON. В ответе у нас будет всего два объекта {result, payload} соответственно: результат и полезная нагрузка. В результат мы будет отдавать два поля {code, msg}. И всегда будем отвечать HTTP кодом 200. Так нам будет проще на стороне клиента разбирать структуру ответа. Все остальные ответы будут приходить в виде строки. 1С нам не позволяет кастомизировать ответы вне платформы.
Теперь у нас получается следующая схема. Если ответ 200, то значит наши процедуры в 1С отработали нормально. Если другой ответ, значит у нас проблема ниже. Тут мы можем сильно не углубляться, что же пошло не так, а сразу показать пользователю какая ошибка, и ее описание. Кто-то может сказать, что ошибки нужно обрабатывать без участия пользователя, но у нас может быть две ситуации: 1 — сервер вернул ошибку. 2 — банально нет связи. В первом случае мы даже можем не узнать, что что-то сломалось(Например ошибка 404: приложение запросило не существующий метод. 500: Платформа упала с исключением). Во втором мы не можем передать результат для анализа на сервер. По этому показываем ошибку, и ждем дальнейших действий пользователя.
Полезная нагрузка будет содержать разные объекты. Это может быть список товаров, список документов, там же будет передаваться список действий. На стороне приложения мы их будем описывать моделями и аккуратно складывать в БД. Список действий будем запускать на исполнение, и результаты аккуратно складывать в БД.
Цикл обмена с ТСД будет следующий:
- Приложение по команде отправляет запрос к 1С.
- 1С формирует ответ и возвращает структуру с результатом и данными. В 1С в регистрах сведений накапливаются измененные данные в разрезе ТСД(веб сервиса).
- По запросу от приложения, отправляется список методов, которое должны быть вызваны.
Такая схемы выбрана по причине того, что ТСД может быть выключенным, вне сети и т.д. Но нам ничего не мешает доработать 1С так, чтобы при изменении данных, уведомить об этом другое приложение(веб сервис). При таком обмене мы сообщаем, что есть новые данные. Приложение запрашивает какие данные есть, и цикл повторяется. Пример обмена представлен на диаграмме.
На этом всё. Если есть вопросы, замечания, предложения, прошу писать в комментариях.
Автор: loki82
