1с 8 1с переучет android

Бесплатная программа для инвентаризации в 1С на ТСД/телефоне

Учет товара в 1с.

В данной статье пойдет речь о бесплатном решении, позволяющем провести инвентаризацию с использованием мобильных устройств без дополнительных вложений.

Возможно читатель, заинтересовавшийся данной статьей — индивидуальный предприниматель, для кого ручная инвентаризация превратилась в бесконечные мучения. При этом, ручная инвентаризация требует значительных ресурсов и не дает требуемую точность.

Желание автоматизировать процесс инвентаризации сдвигается до «лучших времен», так как требует существенных дополнительных расходов. Закупка специализированного оборудования, развертывание и настройка беспроводной сети, покупка и настройка специализированного программного обеспечения убивает планы на автоматизацию процесса на корню.

Но все не так плачевно, если использовать программу о которой пойдет речь в данной статье.

Минимальный набор оборудования и программного обеспечения, который необходим:

  • Телефон или терминал сбора данных на ОС Андроид с включаемым режимом точки доступа
  • Ноутбук
  • Типовая конфигурация 1С (управление торговлей, розница или бухгалтерия), установленная на ноутбуке
  • + бесплатное программное обеспечение для инвентаризации (речь о котором, пойдет в данной статье)

Всего этого достаточно!

Программа для проведения инвентаризации.

1. На телефон или ТСД устанавливается клиентское приложение, камерой которого производится сканирование штрих-кода товара и отправка данных по товару и количеству в учетную систему 1с.

В терминале сбора данных уже есть модуль отвечающий за считывание кодов.

2. На ноутбук устанавливается приложение «Сервер ТСД», которое является «связующим звеном» между клиентом на телефоне и 1С.

3. Для того чтобы обеспечить беспроводную связь между телефоном и ноутбуком, телефон переводится в режим точки доступа. Ноутбук подключается к точке доступа телефона.

Установка и настройка

Установочные дистрибутивы и описание настроек предоставлены в данной публикации

  • «1С:ERP» 2.2
  • «1С:Управление торговлей» 11.2
  • «1С:Управление торговлей» 11.3
  • «1С:Управление торговлей» 11.4
  • «1С:Управление торговлей» 10.2
  • «1С:Управление торговлей» 10.3
  • «1С:Розница» 2.2

Работа с инвентаризацией в различных конфигурациях 1С

Сначала необходимо создать документ инвентаризации в системе 1С.

Создание документа в конфигурации «Управление торговлей 11»

В системе 1с необходимо создать документ инвентаризации «ПересчетТоваров». В документе выбрать склад, по которому нужна инвентаризация.

Выбрать отбор и заполнить табличную часть по отбору и сохранить документ.

Создание документа в конфигурации «Управление торговлей 10»

В системе 1с необходимо создать документ инвентаризации «Инвентаризация товаров на складе».

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

Создание документа в конфигурации «Розница 2»

Сначала необходимо создать документ «Приказ на инвентаризацию» и заполнить отборы.

На основании документа «Приказ на инвентаризацию» создать документ «Пересчет товаров» и заполнить табличную часть по отбору.

Работа с инвентаризацией на телефоне

Работа на телефоне с инвентаризацией функционально одинакова для всех конфигураций.

При открытии операции инвентаризации появится список документов.

В списке выбираем документ инвентаризации, после чего появится окно работы с инвентаризацией, в котором необходимо сканировать товар (с помощью встроенной камеры) или вводить штрих-код вручную.

Вводим фактическое количество товара.

После ввода количества на форме отобразится наименование товара, плановое и фактическое (введенное) количество.

Фактическое количество сразу зафиксируется в документе 1С.

В форме инвентаризации можно посмотреть расхождения.

После того, как весь товар проинвентаризирован, необходимо нажать кнопку завершения инвентаризации.

В 1С документ сменит статус на «Выполнен».

Уникальность приложения AllegroClient в том, что оно позволяет автоматизировать инвентаризацию на базовом уровне в любой 1С.

Как с помощью ТСД, так и с помощью обыкновенного смартфона.

Если вам нужен более расширенный функционал, то рекомендуем обратить внимание на решение AllegroClient prof 2.0

Источник

Реверсим мобильную 1с под андроид. Как добавить немного функциональности и угробить несколько вечеров

Сразу скажу что несмотря на громкое, как кому-то могло показаться, название статьи — тут не будет никакого прям уж совсем хардкора. А также несмотря на то что реверсинг чаще всего связывается с информационной безопасностью — здесь опять же ничего такого не будет, ибо никаких защит (за исключением небольшой минификации) обходить не было необходимости. Нет их. Мобильная 1с бесплатный продукт в который не встроено никаких проверок, защит и платных функций.

Так что обращаюсь к тем кто надеется увидеть применение деобфускаторов, использование Frida/Xposed, другого хитрого софта — ничего интересного вы для себя не найдете. Тут мы просто будем использовать apktool, baksmali, apksigner, adb, jadx, консоль, текстовый редактор, javac, d8 и все.

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

С чего все началось

Немного расскажу с чего мне вообще вдруг пришла идея как-то влезать в работу мобилки на 1с. На данный момент я вот уже скоро год как занимаюсь нативной разработкой под андроид, но до этого я проработал 4 года 1с программистом, причем последние года полтора мы часто работали именно с мобильной платформой. Несмотря на то что основные потребности она удовлетворяла, было у нее так же и очень много минусов (помимо языка программирования). В частности нельзя было по-человечески встроить какую нибудь внешнюю библиотеку, по крайней мере штатными средствами и с нашим тогдашним багажом знаний. Так же все было очень грустно, например, с функциональностью отображения меток на карте. Вся возможность ее настройки заключалась в указании текста для меток когда по ним тапаешь. На тот момент единственным способом как-то это обойти было использование специального объекта «ПолеHTMLДокумента», но с ним были свои проблемы. На время работы с 1с все мои знания в нативной разработке под андроид заключались в паре HelloWorld, так что идеи реверсить мобилку 1сную даже в голову не приходило, разные вопросы от заказчиков по нестандартному расширению возможностей 1с мы либо не решали никак, либо пилили очень простые нативные приложения ставившиеся рядом и криво/косо с 1с интегрировали (да и лицензионное соглашение 1с вроде запрещает правки в самой платформе).

Читайте также:  Разборка редми ноте 4 андроид

Так что первая причина заняться реверсингом 1с заключалась в том, что мне стало интересно, а что я могу сделать имея текущий багаж знаний. Сразу скажу, опыт нативной разработки оказался не сказать что нужен, в повседневной работе почти ничего из того что будет описано ниже не встречается. Так что в принципе наверно любой средний 1сник посидев несколько дней/недель смог бы во всем этом разобраться.

Вторая же причина заключается в том, что мне просто захотелось попробовать поковырять чужие apk, ибо до этого я упускал этот, довольно широкий пласт знаний, и, поскольку нужно было с чего то начинать, мне пришла в голову как раз 1с.

Первые шаги

Первое что я сделал, еще когда идея реверсить 1с только смутно бродила в моей голове, просто перетащил мышью apk файл приложения на окно AndroidStudio. Хочу сказать сразу — что мне стало немного грустно, ибо большая часть кода 1с написана на C++ и лежит в .so библиотеках, и их отреверсить посложнее, да и не было интересно. А вот файл classes.dex всецело завладел моим вниманием, тем более что его скромный размер давал мне возможность предположить что и реверсить его будет несложно. В целом так и оказалось. Кстати, интересное следствие того что большая часть кода на C++ — очень много методов и классов избежали обработки с помощью ProGuard. Сложновато делать интероп с минифицированным кодом ;).

Как можно видеть на скриншоте выше — минификации приложение почти не подвергалось (в плане переименования классов и методов). Плюс видно что кода на java очень немного и почти все место занимают so библиотеки.

Повтыкав какое-то время на список классов, я увидел любопытный класс MapImpl, навевающий подозрения что именно он виновник такой грустной ситуации с кастомизацией отображения меток.

Список методов и их сигнатуры внушали надежду что все будет очень просто, и я решил заглянуть в smali код, после чего сильно напрягся и пошел читать список команд smali, и как его читать/писать. Впрочем, именно на этом моменте я решил что дело обещает быть несложным и недолгим, а соответственно вот он, повод поиграться с реверсингом. Приняв для себя решение посвятить этому пару вечеров (как же жестоко я ошибался), пошел со спокойной душой спать ложиться.

Строю планы

Проснувшись с утра я решил что поскольку до этого момента никогда не занимался даже подменой ресурсов в приложениях, не то что изменениями логики, нечего мне замахиваться сразу на замену активити с картой, лучше приближаться к решению задачи маленькими шажками. После чего я составил себе небольшой список шагов который должен был привести меня в конечную точку моего путешествия в виде рабочей мобильной платформы с моими правками. Список этот выглядел следующим образом:

  1. Подготовить конфигурацию 1с для мобильной платформы вся функциональность которой заключается в отображении двух меток на карте.
  2. Распаковать apk мобильной платформы, запаковать без изменений, убедиться в работоспособности конфигурации.
  3. Внести небольшие изменения в smali файлы, не меняющие практически ничего, но которые можно было бы увидеть в логах или изменении логики работы, собрать и убедиться что это работает.
  4. Перегнать smali активности с картой в java, либо же написать активность с таким же интерфейсом, подменить активность в приложении без изменения функциональности. Как альтернативный вариант, если с первым разбираться будет лень или сложновато — написать класс, который будет выполнять часть работы за MapImpl и добавить вызов его методов из smali MapImpl.
  5. Написать эту статью (давно уже хотелось что-то написать, но другие идеи пока еще варятся в голове, а тут показалось что это наконец довольно достойная тема)

Ну, хорошо хоть с первым пунктом у меня проблем не возникло. Скачал бесплатную учебную версию платформы, скачал мобильную платформу, развернул все это у себя на компьютере (1С, сделайте вы уже версию учебную для linux, у меня как раз очередной порыв уйти с винды, а тут приходится часть работы в ней делать). Конфигурация очень простая, при запуске вызывает функцию ПоказатьНаКарте() в которую передает две точки на карте. Все.

А вот со вторым пунктом из-за моей неграмотности вышло грустнее. Да что уж там, проблемы были со всеми пунктами кроме первого.

Читайте также:  Kaspersky internet security для android 5 лет 1 устройство

Перепаковываю приложение без изменений кода

Гугл мне сразу подсказал что есть такой отличный инструмент apktool позволяющий буквально двумя командами разбирать apk до .smali файлов, а так же собирать из них обратно. Им я и решил воспользоваться. Распаковал apk следующей командой (здесь и далее, несмотря на то что временами часть работы делал на linux, все команды буду приводить для windows):

и получил каталог unpacked в котором лежала куча файлов, с ними в будущем предстояло работать. Запаковал apk обратно командой

Попытавшись установить его на эмулятор

я получил следующую ошибку:

В общем нужно было больше внимания базе уделять. Я конечно знал что существуют подписи, и о том что они делятся на дебажные и релизные, но не знал что приложения вообще без подписей не устанавливаются. Я решил воспользоваться своей дебажной подписью, и подписав apk командой

мне удалось запустить приложение. Правда вместо карты с двумя точками меня ждал серый экран с подписью google внизу. Почесав репу я решил что дело в том что используется ключ для гугл карт от 1с, который с моей подписью не работает. Поэтому пойдя в консоль разработчика на сайте google я создал новый проект для работы с api google карт на андроиде, получил api key, который указал в res/values/strings.xml в google_maps_key строке, а так же добавил свой дебажный ключ в разрешенные для проекта. Перепаковал и переподписал apk, запустил, и наконец все снова работало.

Добавляю свои логи

Следующее что я хотел сделать — это автоматизировать запуск приложения и добавление конфигурации 1с в платформу. Вручную после каждых правок делать это делать было бы той еще морокой.

Сначала я нагуглил и попытался воспользоваться утилитами jadx или dex2jar, чтобы не мучиться с чтением smali, а читать более привычный код на java, но по какой-то причине они не работали (в дальнейшем jadx все таки завести удалось каким то шаманством). Пришлось разбирать smali, благо это оказалось не так ужасно как я боялся.

Чтобы понять, как мобильная платформа получает от десктопной платформы команду на запуск конфигурации при подключении по adb, я решил посмотреть точки входа в приложение и добавить вывод в логи интентов и прочей полезной информации. Начать решил с application ( com.e1c.mobile.E1cApplication ) и активности имеющей android.intent.action.MAIN в intent-filter ( com.e1c.mobile.App ). Также меня заинтересовал reciever com.e1c.mobile.Starter с интересным intent filter на com.e1c.mobile.START_TEMPLATE и com.e1c.mobile.START_CMD . Уж очень похоже на то что он принимает интенты с командами 1с, и именно он стартует конфигурацию из шаблона.

В E1cApplication ничего интересного к сожалению обнаружить не удалось, все что там происходит — установка своего хендлера на крэши.

А вот в двух других классах, Starter и App информации было гораздо больше и оказалась она довольно полезной. Метод App.onCreate(Landroid/os/Bundle;)V довольно большой, так что приводить его целиком не буду, приведу только заинтересовавшие меня части.

Из приведенного выше участка кода видно что приложение получает интент, кладет ссылку на него в регистр p1 , через StringBuilder дописывает к имени класса и метода и передает в статический метод V(Ljava/lang/String;)V класса Utils . Видимо какой-то свой логгер. После чего интент проверяется на наличие дополнительных данных, и, при наличии, из него получается Uri , из которого в свою очередь получается строка методом getQuery() и передается классу Starter . Дальше изучать onCreate смысла не видел, пробежался взглядом и убедился что действия довольно стандартные. Разве что вью вроде бы создается программно абсолютно другим классом, вместо использования LayoutInflater , но сильно глубоко я не копал, так что возможно все и не так как я подумал. Следующий класс куда я пошел — Starter . Благо он и в активити упоминался и в манифесте меня заинтересовал.

К сожалению тот метод что вызывался из активити, оказался нативным ( .method static native startCmd(Ljava/lang/String;)V ), потому обратил внимание на метод onRecieve (в котором приложение принимает интенты на которые подписано). Приводить код не буду, меня в нем заинтересовало что интент так же логигуется методом V(Ljava/lang/String;)V класса Utils . Получается что достаточно дописать немного smali кода в этот метод — и я получу свои логи, причем на тех же местах где их задумывали разработчики платформы. Перейдя в класс Utils я увидел сразу 2 пустых метода, V и W. Видимо пустые они потому как при компиляции релизной версии вырезались. Я просто дописал в них запись переданной строки в стандартный android.utils.Log . Для этого сменил количество требуемых локальных регистров с 0 до 1 (для строки тега), поместил эту самую строку в регистр v0 , а также прописал вызов методов Log

Запустил из 1с десктопной 1с мобильную и получил следующие логи

Как видим — есть вся необходимая информация для автоматизации запуска приложения через adb. Правда к этому моменту я словил двойной фейспалм. Во-первых, наконец подобрал ключи с которыми jadx осилил перевод в java (понятно что писать все равно в smali бы пришлось, но все же). А вторым фейспалмом оказалось то что я осознал что зря я мучаю платформу разработчика (нужна только для разработки и отладки конфигураций), правильнее было бы реверсить сборку релизов 1сных приложений, причем там есть полу готовые gradle проекты для сборки, есть файл с перечнем зависимостей и другие плюшки. Я немного по этому поводу погрустил — и решил все таки закончить с тем что начал. Все равно ради фана делаю все это, а не ради практической пользы.

Читайте также:  Period calendar для андроида

Запуск платформы через adb

Автоматизировать установку и запуск через adb приложения я решил с помощью gradle. Все равно к тому моменту у меня уже был написан небольшой перечень тасок (распаковка, копирование модифицированных ресурсов и smali файлов в каталог с распакованным приложением, упаковка, подпись, по сути все таски просто раннеры для команд консольных). К существующим таскам добавил выполняющие следующие команды

Перечисленной выше последовательностью команд мы устанавливаем apk, даем установленному приложению разрешение на чтение диска, копируем конфигурацию 1с на устройство, и даем команды на запуск 1с и загрузку конфигурации. Работает это кстати не на всех версиях андроида, но я тестировал на api 28, и соответственно на нем эта последовательность делает все корректно. На младших версиях могут быть проблемы с выдачей прав.

Внедряюсь в обработку данных от 1с и модифицирую метки

Тут у меня было несколько вариантов дальнейшего развития событий.

  1. Правлю напрямую MapImpl.smali, что обещало быть довольно сложным занятиям учитывая что библиотека для работы с гугл-картами довольно серьезно минифицирована, да еще и в синтаксисе smali все писать пришлось бы.
  2. Использую полученный благодаря jadx файл MapImpl.java, вношу правки в него, используемые в нем классы подменяю на заглушки, перегоняю в smali, подменяю файл, упаковываю. Вариант показался мне напряжным так как уж больно много заглушек пришлось бы городить, к тому же с некоторыми из них были проблемы с которыми у меня не было желания ковыряться.
  3. Комбинирую подходы 1 и 2, вставляю в smali код вызовы специального класса расширения MapImplExtenstion.java который расширяет часть логики — в итоге выбрал этот вариант, просто потому что он проще первого и второго вариантов, и показался мне пусть возможно чуть более сложным чем вариант 4, но зато менее трудоемким (угу, мечтай, наивный).
  4. Вообще заменить гугл карты на что-то другое, например яндекс. Сделать всю работу в другом проекте, просто повторив сигнатуры MapImpl, затем минифицировать распаковать, и просто закинуть готовые smali файлы перед упаковкой приложения на соответствующие места. Никаких проблем с минифицированными библиотеками, но пришлось бы регистрироваться для получения ключа для карт, создавать отдельный проект, заморачиваться со стыковкой ресурсов и прочее.
  5. То же что вариант 4, но заменить гугл на… Гугл. Но тут у меня были подозрения что удастся минифицировать 1 в 1 maps sdk, а ставить эксперименты не было желания.

Пойдя по третьему варианту я создал 2 подкаталога в src: java, для MapImplExtenstion.java и stubJava для файлов которые нужны только для компиляции. Поскольку я решил подправить чуть внешний вид меток, меня заинтересовали два следующих поля:

Используя jadx для декомпиляции в java нашел в декомпилированном коде метод отвечающий за их заполнение

Соответственно у класса MapImplExtension добавил метод ArrayList[] kN(String[] titles, double[] coordinates) который в первом элементе массива вернет список который нужно будет поместить в Xj, а во втором список для Xk.

Скомпилировал следующими командами сначала в class, затем в dex, затем декомпилировал в smali чтобы потом упаковать вместе с остальными файлами

Добавил в MapImpl.smali поле extension типа нашего нового класса, и добавил его инициализацию

А также заменил обработку в классе MapImpl данных от 1с на обработку в классе MapImplExtension

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

Добавление новой функциональности

Сначала немного пояснений как вообще устанавливается маркер для метки. У класса MarkerOptions есть метод public MarkerOptions icon (BitmapDescriptor iconDescriptor) в который передается объект созданный одним из статических методов класса BitmapDescriptorFactory .

И вот здесь собственно меня ждал облом. Поскольку 1с это дело не использует — соответствующие классы были просто вырезаны при минификации. Пришлось их восстанавливать, и было это больно и долго. Точнее классы то были, но были переименованы и не содержали нужных методов. Путем ковыряния в сорцах полной библиотеки для работы с картами — по сигнатурам и константам выяснил соответствия классов библиотеки классам приложения, добавил необходимые методы и поля, пересобрал, и порадовался что этот квест наконец закончил, поскольку все наконец то заработало, пусть и не с первой попытки (несколько раз косячил с сигнатурами и путал минифицированные классы).

Поскольку объем измененного кода довольно большой — включать в статью его не буду, приведу только изменения сигнатур. Если кому интересны все правки которые я сделал на этом шаге — можете посмотреть в этом коммите.

Подводя итоги — опыт был довольно интересный. По крайней мере для меня. Помог разобраться с некоторыми инструментами, узнал немного лучше о работе андроида и формате байткода для dalvik/art, опыт ковыряния минифицированного кода тоже будет полезен (уже был случай когда в релизной версии R8 вырезал поля класса которые на самом деле использовались, в тот раз только методом тыка разобрался, сейчас бы это проблем не доставило).

Если кому-то интересно самому все повторить и возможно расковырять еще больше — я выложил на github все исходники вместе с кривым gradle скриптом осуществляющим сборку из исходного apk модифицированного.

Источник

Оцените статью