Автоматы: решение задач ЕГАИС без участия пользователей для любых учетных систем посредством "УС Лэнд:ЕГАИС" : КИС Lack & УС Land

1. Как, возможно не точно отметил, автомат: https://olegon.ru/showpost.php?p=327754&postcount=1 был неудобен для меня (пользователей ведущих 100% учет на "УСЕга"), т.к. принуждал к ручному формированию списка марок. Новый исключает необходимость в этом

2. Фильтр: https://olegon.ru/showthread.php?t=31150 и запросы остатков регистра №3: https://olegon.ru/showthread.php?t=28919 отчасти альтернативные подходы, например "фильтр" не позволит выявить (исправить) ситуацию, когда марок меньше, чем остаток на складе... ИМХО - запрос по РФУ-2 является более точным механизмом

3. По "hle 02LRFU999999, где z=2" записал в список доработок. Не могу сказать, когда сделаю...

Конечно сделал... Однако на этапе отладки, которую не могу считать "полной" выявилась "занятная" загадка от ЕГАИС: https://olegon.ru/showpost.php?p=330628&postcount=83 но которую "убил" по сути всю эту рабочую неделю, а так и не нашел решения... возможно был по должностным обязанностям переизбыток разноплановых "заморочек". По сути:

* 29.04.2019 Расширяю функционал по параметру, сейчас Z:
* z = 0 - Берем, если есть остаток на регистре №1 складе
* z = 1 - Остаток на рег№1 БОЛЬШЕ остатка по маркам на рег№3
* z = 2 - Остаток на рег№1 МЕНЬШЕ остатка по маркам на рег№3
* z = 3 - Остаток на рег№1 НЕ РАВНО остатку по маркам на рег№3
* Для 1..3 смотрит и по нулевым остаткам, если но y = 0, т.е. предполагаем принадлежность рег№3
* Иначе запрашиваем и закончившуюся алкопродукцию, в зависимости от условия Y

Напомню вызов автомата: HLE yzLRFUxxxx

Сейчас в плане подготовки к ревизиям новых марок и технологий под это "дело" активно используются автоматы, я разбираюсь с "результатами", сверяемся с ЕГАИС и "фактом". Как следствие выявляются необходимые доработки программы. Часть из них, затрагивающих существующие "автоматы":

X. Автомат фоновой подготовки данных для запроса марок регистра №3 https://olegon.ru/showpost.php?p=330537&postcount=19 Очень много алкопродукции (около 1000 наименований) приходит на регистр №3 со старой маркой, по которой не нужно "париться", а просто переводить в партиционную (сделан быстрый механизм)… Затем без проблем проводить по ней инвентаризацию. Однако способы запуска автомата заставляют тратить по 10 минут на каждую РФУ-2. Сделан механизм запроса только по новым маркам, игнорируя "старые" формально на рег.№3, а именно сейчас способы вызова:


I. Автомат пакетного обновления пула марками регистра №3 по РФУ-2 https://olegon.ru/showthread.php?t=31377 Раньше получаемый на вход файл с РФУ-2 - ListRFU2.txt после обработки переименовывался в каталог REPORT на ListRFU2.act, затирая предшедствующий автомат, т.е. "история" для анализа терялась.

Сейчас. Исходный файл сохраняется в REPORT с уникальным именем Lst*.Lst, т.е. доступен для анализа в любое время.

Примечание. Для проверки "всего и вся" мы проверяем факт, ЕГАИС, корректность режимов "УСЕга" и etc

Лето? "мать"... Проснулся, за "бортом" минусовая температура - ни рыбалки, ни грибов, ни настроения, а до отъезда в санаторий ещё 2 дня... включил обогреватель и "пошел" работать...

"На неделе" случилась очередная нервотрепка из-за ЕГАИСа. Привезли товар с новой маркой, дамы собрались проверять марки, попытка открытия ТТН и штатный запрос новых РФУ-1, что нужно для определения алкокодов, т.к. по новым маркам он не высчитывается... До кучи ЕГАИС работал нехотя и процесс запроса РФУ-1 на кассовом ПК с "моргушками" растянулся на 40 минут. Чужой водитель "вопит", покупатели, которым с трудом пытаются пробить чеки волнуются и ругаются, продавцы мне названивают каждые 10 минут, как будто могу пришпорить ЕГАИС... Однако всё это "стимулировало" придумать новую технологию. Которую, правда хотел создать после отпуска, но "не судьба" - сделал сегодня.


XI. Автомат по запросу справок 1 (РФУ-1), алкокодов, марок по алкопродукции с новыми марками, по необработанным приходным накладным

Суть: При вызове автомата, если программе "УС Лэнд:ЕГАИС" не известна РФУ-1 из накладных очереди УТМ, то производится запрос её атрибутов - пакетная имитация открытия каждой ТТН для запроса РФУ-1. Вместо "попадалова" на случайный долгий запрос РФУ-1 при открытии ТТН можно запускать данный процесс с утра или во время чаепития.


Автомат вызывается:

1. Через командную строку, командный файл или ярлык: hle S1NewAkm. Как обычно программа ждёт 3 минуты, в течении которого можно отказаться от его исполнения
2. Из меню "приходы" программы

Сколько это займет времени? На всё воля ЕГАИС: от 5 минут до 2 часов, что так же зависит от числа позиций с новыми справками по алкопродукции с новыми марками.


Теперь картинки:

1. Работа команды hle s1newakm



Высвечивается сообщение, которое висит 3 минуты с предупреждением из которого нажатием кнопки Esc можно отменить выполнение автомата... и пояснением о возможных нюансах от (при) его выполнении. Впрочем и при банальном открытии списка ТТН, УТМ считает, что они прочитаны и удаляет их из своей очереди через неделю

Потом появляется "пустой" экран с сообщение и на нём выдаются различные сообщения режимов комментирующих сеанс обработки данных:



В окончании программа даёт сообщение об успешности или "не очень" проведения автомата и прекращает свою работу.


2. Из меню "приходов" даётся запрос на исполнения автомата и по завершению происходит возврат к программе.




Алгоритм. В принципе здесь частично эмулируется ручная работа пользователя по работе с приходными накладными...

1. Запрос всех входящих запросов
2. Получение списка приходных накладных по активному ключу
3. По каждой накладной, имеющей новые марки проверка "известности" программе соответствующих маркам РФУ-1
- известно. Создание виртуального пула и остатков регистра №1 по отсутствующим маркам
- не известно. Запросы РФУ-1, получение ответа и создание виртуального пула и остатков регистра №1 по отсутствующим маркам


Замечания:
1. Учитывается схема преобразования кривых ТТН и/или настройка её использования
2. Обработанные в автомате накладные открываются сразу, без запросов РФУ-1

Браво! IMXO, давно назрела данная проблема, т.к. непредсказуемость времени ответа ЕГАИС при открытии ТТН с "новыми марками" весьма напрягала.

УФ! На сегодня закончил... Утилита: https://olegon.ru/showthread.php?t=32948 "УС Лэнд:ЕГАИС" является достаточно чистоплотной программой для ЕГАИС всегда предлагая убирать "мусор" - лишние документы из БД УТМ и в частности имея данные режимы для всех типов создаваемых и отслеживаемых операций с ЕГАИС, вызываемые нажатием кнопки F9.

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

Кроме этого штатная операция "каскадного удаления" в "УСЕга" визуально затемненным цветом помечает полностью обработанные и проведенные документы. Однако - это операция выполняется в ручном режиме для каждого документа всех типов, что излишне утруждает пользователей желающих максимальной автоматизации. Думал, думал и придумал...

XII. Автомат каскадного удаления сопутствующих документов по всем полностью проведенным операциям

Суть: При вызове автомата программа обходит все таблицы программы выискивая полностью проведенные, но "каскадом" не обработанные операции и автоматом производит по ним удаление всех сопутствующих запросов в УТМ. Понятно, что эти операции создавались и отправлялись в ЕГАИС через "УС Лэнд:ЕГАИС". Обрабатываемые операции по:

- списаниям склада и торгового зала;
- трасферу со склада в ТЗ и возврату из ТЗ на склад;
- постановке на баланс склада и торгового зала;
- расходным накладным;
- запросам нечитаемых марок


Автомат вызывается:

1. Через командную строку, командный файл или ярлык: hle Kaskad. Как обычно программа ждёт 2 минуты, в течении которого можно отказаться от его исполнения
2. Из меню "сервисов" программы запуском соответствующего режима. Сколько это займет времени? На всё воля ЕГАИС и объема документооборота: от 10 минут до 2 часов.

Картинки с комментариями:

1. После вызова автомата в верхней строке перечисляются операции и обрабатываемые даты





2. Базируясь на штатной обработке каскадного удаления, но с подавлением диалогов с пользователями автомат иногда выдаёт диагностические сообщения





3. Результат обработки списка операций дан на картинке, где выделенным цветом даны не обработанные операции

Как говорят "и на старуху бывает порнуха"... Были жалобы на долгое выполнение и вылеты программы при выполнении автомата: Наконец сам "поймал" ситуацию: при большом количестве операций, на ПК с небольшой оперативной памятью (Win 7 2Gb), с кучей запущенных программ программа вылетала по "переполнению памяти"... при проверке на (Win10/64 16Gb) автомат на "той" БД отрабатывал без ошибок, но относительно долго (20 минут).

Подумал... и обнаружил, что алгоритм автомата "глупый" и не оптимальный - нет смысла смотреть все операции, а нужно лишь за последние 7 дней (сделал 14), т.к. УТМ уже по более старым сам всё удалит. Добавил виртуальный индекс. Сейчас на (Win10/64 16Gb) выполняется 34 секунды... т.ч. до нового релиза при большом объеме операций его использовать не рекомендую.

Может быть в данном режиме формирования списка РФУ-2 добавить ограничитель "только по алкоголю/пиву/все" ?
Ведь автомат запроса остатков по Р3 при наличии общего списка РФУ-2 будет тупо слать запросы по пивным РФУ-2, или я не прав?

Извиняюсь.
Вопрос снимаю, писал в цейтноте..

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

Опять натыкаюсь, т.ч. вынужден описать "особенность работы программы"
В последнее время очень много времени и ресурсов компов тратиться на выполнение этих работ для приведения данных в соответствие с новыми требованиями "партии и правительства": https://olegon.ru/showpost.php?p=346787&postcount=302, а так же в работах по закрытию магазинов: https://olegon.ru/showthread.php?t=26006&page=3 … и обнаружилась неприятная особенность программы "УС Лэнд:ЕГАИС" - вероятно при длительном процессе "съедается" память компьютера. Отследил несколько этапов данного процесса:

1. Другие параллельно работающие приложения резко деградируют по скорости;
2. Перестают запускаться другие приложения, в частности становится недоступным удаленный доступ;
3. Вылетает "неизвестная ошибка" Windows - "УСЕга" перестаёт работать... При нажатии в сообщении ok - работа программы продолжается;
4. Если Windows без работающей "УСЕга" побудет в режиме простоя пару часов, то последующие работы происходят без проблем...

Это сильно зависит от OS и объема памяти... На рабочих ПК (Win10, 8/16Gb) и одного клиента (Win10? 8Gb) их не было даже при работе режима 2 суток, но на реальных ПК (1. Win7, 2Gb, 2. Atom, Win7, 1Gb) возникают при непрерывной работе более 1. - 18 часов, а 2. - 10 часов.

Тщательно изучая код не нашел моих косяков в программе, наверное это косяки инструмента разработки - плохая работа с очисткой памятью? Как бы ни было...

рекомендация: не запускать данный режим на более чем 14 часов, а затем либо перезагрузить ПК, либо дать пару часов Windows, что привести свою "память" в порядок, а лишь затем запускать новое задание