УС Лэнд:ЕГАИС – 2018 и далее? Обсуждение программы, предложения, замечания, вопросы : КИС Lack & УС Land

AndreyZh, Андрей, без обид, но даже твой ответ тяжело читать из-за перегруженности инфой :)
И так во всём, слишком много лишней информации, которую подавать не надо :)

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

Да, Егаис не простая тема...

Изображения

 

Нетучки

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

Унифицированы, расширены и углублены под нюансы работы с регистром №3 технологии подбора алкопродукции "под остаток". Режимы используются для "ликвидации магазинов", взаимодействия с другими учетными системами и т.д. Рассмотрим изменения, например по формированию расходной накладной:





Основные изменения:

1. Под эти режимы, везде выделена другая кнопка Alt+F2;

2. Во всех таких режимах можно отделить работу с пивом от "правильного" алкоголя, т.к. для них разные методологии работы;

3. Введена корректная обработка алкопродукции с регистра №3, где операции, как правило производятся помарочно, а по многим "попыткам" отсылать документ с АП рег.3 ЕГАИС будет присылать отказ. Программа "УС Лэнд:ЕГАИС", как всегда спрашивает Вашего соизволения не дать Вам напортачить и если Вы с ней согласны:

- По связка алкокод+РФУ-2 программа ищет в пуле марок весь комплект алкопродукции;
- Если найдена хоть одна марка принадлежащая связке алкокод+РФУ-2, то данная алкопродукция не включается в документ;
- По остаткам регистра №3 операции в последствии можете провести помарочно….

P.S. При отладке технологий увидел - если думаете о закрытии алкогольного бизнеса, то пора поспешить… скоро, технически это будет сложно производить, в отличии от настоящего, когда магазин можно прикрыть "за пять минут": https://olegon.ru/showthread.php?t=26006

Сегодня для разработки сменил носитель на RuToken и записал новый ключ. Кратко отчитаюсь - всё идет по плану! Продолжается переписывание программы под новый интерфейс: https://olegon.ru/showthread.php?t=29916 и при этом:

1. Исправляются найденные ошибки, в основном грамматические;
2. Унифицируются режимы и кнопки, т.е. смысл в одних режимах идентичен смыслу и назначению в других;
3. Дополняются (в плане унификации) режимы новыми не созданными раннее возможностями;
4. Оптимизируется программа в старых режимах, зачастую переписывается на более быстрых, придуманных позднее алгоритмах.

Например сегодня, наряду с кучкой других дел переписал режим анализа ответов на запрос пачки РФУ-1, где все упомянутые 4 момента имели место быть. На скрине отмечены новые возможности:

Дьявол кроется в деталях...

Развитие идёт по написанному сценарию, но ЕГАИС - это слишком "мутная" и нестабильная сфера, что иногда нужно прерывать плановый процесс и решать "срочные" задачи. Одна из них:

В принципе, даже разработчики её "проигнорировали", а ведь она будет приносить множество головоломок от пользователей: https://olegon.ru/showpost.php?p=318355&postcount=16

Как она касается "меня"? В основном, в реале алкопродукция поступает от иногородних поставщиков, т.е. с момента отправки ТТН в ЕГАИС до фактического поступления товара зачастую проходит более недели... и УТМ автоматом удаляет накладные из своей базы данных.

В тоже время система перезапроса ТТН построена, не как сложный "внутренний" контур, а как простой сервис без анализа ответов (тикетов) ЕГАИС и из-за этого "мелкого" новшества создавать большую подсистему "себе дороже", а если ничего не делать загребут звонками "почему и что не работает".

Поступил просто! Правда создав "на будущее" несколько универсальных механизмов. Отправляя перезапрос ТТН смотрю, когда был сделан предыдущий, а если раньше, чем через 10 минут - запрещаю отправку перезапрос с объяснением этого "проступка" пользователю.

Из контура анализа потерянных в недрах ЕГАИС приходных накладных - это выглядит так:






Из сервиса перезапроса "контура" работы с приходами программа производит сходные анализы и даёт идентичную диагностику:

Здравствуйте!

У меня вопрос по контуру прихода прихода последней версии программы.

На тесте проиграл следующую ситуацию -
- отправляем ТТН ( для простоты с немаркированной АП)

Далее по пунктам
1. "Взять входящие запросы.."
2. "Обработка входящих ТТН..." - видим ТТН со статусом "Не знаю"
3. Выход с отправкой акта подтверждения
- акт уходит
4. "Взять входящие запросы.."
5. "Обработка входящих ТТН..." - видим ТТН со статусом "Принята"
+ накладная доступна для редактирования количества ???
6. Выход с отправкой акта отказа
- акт уходит
7. "Взять входящие запросы.."
8. "Обработка входящих ТТН..." - видим ТТН со статусом
"Отказана" ???
Смотрим в УТМ - видим три непрочитанных тикета, первые два на акт подтверждения, третий реджект на акт отказа.


Вроде бы раньше после подтверждения накладной вторичный вход был только для просмотра или я что-то путаю?

Добрый вечер! Вы и "УСЕга" друг друга запутали, правда не Ваша в том вина, а историческая "несправедливость"

Изначально утилита использовалась, как предполагалось только для формального подтверждения приходов и запросов на информацию в "ожидании" скорого отмена ЕГАИС... Надежды не сбылись, новые, вводимые документы хранились уже "по умному", а в режимах "подтверждения" только менялся "мотор" под новые форматы и нюансы... и скорее всего режим "приходов" таковым и останется (?)

Подходы и механизмы взаимодействия (интерфейса пользователя) не менялись с 2015 года, а лишь пополнялись новым функционалом. Правилами "рулит" ЕГАИС!

Отправляется акт подтверждения в ЕГАИС, а в каталоге DATA\ сохраняется ХМЛ файл акт с именем WBA_КодНакладной.XML В дальнейшем по маске WBA*.XML программа извлекает инфу из этого акта, например "статус"

Что определилось из файла WBA*.XML

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

Файл заменяется на новый с другим статусом - Вы сами себя запутали... ЕГАИС всё равно вернёт тикет отказа, т.к. акт уже был раннее послан... Что Вы сами указали
И так работало всегда, что этот вариант подхода правильный доказано "шаловливыми ручками" операторов поставщиков и своими продавцами... вне зависимости от изменения "правил" ЕГАИСа

Не только занимаюсь переделкой интерфейса и сопутствующим устранением недоработок: https://olegon.ru/showthread.php?t=29916, а так же вношу правки простых и ошибок проектирования обнаруживаемые пользователями, которые, как их не прошу - не хотят общаться на форуме. Скоро выложу очередной промежуточный релиз, а так, как не "описалова", то отражу здесь инфу по ИСПРАВЛЕННЫМ технологическим "косякам" программы.

Замечу, что релизы выкладываются совсем не сразу после правки косяков… Просто порядок моего подхода: написание -> моя отладка всех нюансов -> отработка в реале -> размещение на форуме. Исходное письмо:

Был в отпуске, а посему "отправил" к новости: https://olegon.ru/showpost.php?p=314079&postcount=3 - эта проблема так же имела место быть! Не занимался ей, т.к. в реале данная ситуация невозможна, но при переделке режимов добавил ещё один контрол. В примере, для отладки, ну нет таких объемов, назначено меньшее значение и теперь программа запрашивает разрешение у пользователя, авось опять в тихушку изменят правила:




Получил ещё письмо, которое помогло мне локализовать проблему, а точнее несколько:

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

При создании трансфера под остаток программа дроби округляла до целого (на регистре №2 можно работать только целыми) по математическим правилам, как следствие могла в акте поставить больше, чем на остатки. Как долго искал ошибочную строку… т.к. программа имела "слепую" диагностику, но сейчас сообщение даётся максимально подробным:




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

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