Форум по программам и оборудованию > > >

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

19.10.2019 15:12


16.08.2018 15:55
Fomka
 
AndreyZh, Андрей, без обид, но даже твой ответ тяжело читать из-за перегруженности инфой :)
И так во всём, слишком много лишней информации, которую подавать не надо :)
16.08.2018 16:16
AndreyZh
 
Цитата:
FinSoft Я Андрею уже говорил, у него и программы такие же многословные. "Добрый день, милый друг", "Извольте, нажмите на эту кнопочку, мадам"...
Цитата:
Fomka AndreyZh, Андрей, без обид, но даже твой ответ тяжело читать из-за перегруженности инфой :)
И так во всём, слишком много лишней информации, которую подавать не надо...
Замечания услышал! Спасибо! В принципе схожие зачастую бывают из виртуального мира, однако в реале часто жалуются на лаконичность Постоянно ищу и буду продолжать искать компромисс.
16.08.2018 18:19
FinSoft
 
Да, Егаис не простая тема...
Изображения
 
16.08.2018 18:54
AndreyZh
 
Цитата:
FinSoft Да, Егаис не простая тема...
Нетучки

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





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

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

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

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

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

P.S. При отладке технологий увидел - если думаете о закрытии алкогольного бизнеса, то пора поспешить… скоро, технически это будет сложно производить, в отличии от настоящего, когда магазин можно прикрыть "за пять минут": https://olegon.ru/showthread.php?t=26006
25.09.2018 16:08
AndreyZh
 
Сегодня для разработки сменил носитель на RuToken и записал новый ключ. Кратко отчитаюсь - всё идет по плану! Продолжается переписывание программы под новый интерфейс: https://olegon.ru/showthread.php?t=29916 и при этом:

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

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


28.09.2018 12:31
AndreyZh
 
Дьявол кроется в деталях...

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

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

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

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

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

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






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

28.09.2018 16:23
plvn24
 
Здравствуйте!

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

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

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

Смотрим в УТМ - видим три непрочитанных тикета, первые два на акт подтверждения, третий реджект на акт отказа.


Вроде бы раньше после подтверждения накладной вторичный вход был только для просмотра или я что-то путаю?
28.09.2018 20:32
AndreyZh
 
Добрый вечер! Вы и "УСЕга" друг друга запутали, правда не Ваша в том вина, а историческая "несправедливость"

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

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

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

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

Цитата:
plvn24 4. "Взять входящие запросы.."
5. "Обработка входящих ТТН..." - видим ТТН со статусом "Принята"
Что определилось из файла WBA*.XML

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

Цитата:
plvn24 6. Выход с отправкой акта отказа
- акт уходит
7. "Взять входящие запросы.."
8. "Обработка входящих ТТН..." - видим ТТН со статусом
"Отказана" ???
Файл заменяется на новый с другим статусом - Вы сами себя запутали... ЕГАИС всё равно вернёт тикет отказа, т.к. акт уже был раннее послан... Что Вы сами указали
Цитата:
plvn24 Смотрим в УТМ - видим три непрочитанных тикета, первые два на акт подтверждения, третий реджект на акт отказа.
Цитата:
plvn24 Вроде бы раньше после подтверждения накладной вторичный вход был только для просмотра или я что-то путаю?
И так работало всегда, что этот вариант подхода правильный доказано "шаловливыми ручками" операторов поставщиков и своими продавцами... вне зависимости от изменения "правил" ЕГАИСа
04.10.2018 15:27
AndreyZh
 
Не только занимаюсь переделкой интерфейса и сопутствующим устранением недоработок: https://olegon.ru/showthread.php?t=29916, а так же вношу правки простых и ошибок проектирования обнаруживаемые пользователями, которые, как их не прошу - не хотят общаться на форуме. Скоро выложу очередной промежуточный релиз, а так, как не "описалова", то отражу здесь инфу по ИСПРАВЛЕННЫМ технологическим "косякам" программы.

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

Цитата:
Решил начать разбираться с Вашей программой т.к. видел (у товарищей) как в ней можно делать некоторые операции, которые невозможно сделать в других программах. Начал с выравнивания остатков и сразу же столкнулся с проблемой переноса остатков с 1-го на 2-ой регистр. Делал по https://olegon.ru/showthread.php?t=26029. При попытке отправить акт в ЕГАИС получил ошибку. Почему программа жалуется на недостаточное количество? ведь я это количество получил запросом?
Был в отпуске, а посему "отправил" к новости: https://olegon.ru/showpost.php?p=314079&postcount=3 - эта проблема так же имела место быть! Не занимался ей, т.к. в реале данная ситуация невозможна, но при переделке режимов добавил ещё один контрол. В примере, для отладки, ну нет таких объемов, назначено меньшее значение и теперь программа запрашивает разрешение у пользователя, авось опять в тихушку изменят правила:




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

Цитата:
проблема была и в этом и в том что на 1-ом регистре оказались "раздробленные" кеги пива, не знаю как так получилось и почему ЕГАИС дробил кегу на разные справки (например на 0,27 и 0.73), сейчас это уже не важно. Проблема в том, что эти дроби невозможно ни списать ни передать на 2-ой регистр. Хотел из списка передаваемых справок убрать дроби, но в программе видно только целое количество. В любом случае, чем больше разбираюсь с Вашей программой, тем больше вижу плюсов по сравнению с другими программами
Сложность в том, что в реале не работаю с разливным пивом и технологии правятся, когда пользователи обнаруживают косяки.


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




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

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


Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.