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

█ 18.11.2018 08:02

Цитата:

plvn24 ➤ Чего я так уперся?

Скажу честно – создал давно данный сервис и более постоянно его не проверял… Последний раз в июле 2018, когда добавлял анализ новых ошибок, а на форуме ФСРАР данную тему давно забросили. Сейчас даже «улыбки» не вызывают постоянные вопросы по «сбоям ЕГАИС» на форумах, т.к. спецам лень, что проверять по файлу «ошибки.xls», а тем более бесплатной программой «УСЕга» - им проще в течении длительного времени «доставать» операторов ФСРАР и службу техподдержки ФСРАР, имитируя бурную свою деятельность. Кроме того поведение ЕГАИС постоянно, без объявлений видоизменяется, что когда-то «правильное» становится «бесполезным», как пример новая технология программы: https://olegon.ru/showpost.php?p=321191&postcount=109

Как следствие склонен больше доверять Вам, глубоко изучившую данную проблему. Программа при анализе лога транспорта ищет вхождения «текста» в строке файла лога и ищет его в списке ошибок. Приведите пожалуйста пример строки, а лучше несколько последовательных строк лога транспорта, с выделением строки диагностирующей данную ошибку, а я заменю «контекст» в анализаторе логов, что бы «УС Лэнд:ЕГАИС» правильно определяла, что УТМ не смог произвести on-line проверку акцизной марки.

P.S. Не стал «отключать» данную проверку, а просто добавил ещё подзапрос в «анализатор логов УТМ»:

█ 18.11.2018 12:34

Пример 1

Цитата:

2018-11-16 15:00:45,949 INFO es.programador.http.AbstractServlet - Получен чек
2018-11-16 15:00:51,055 ERROR es.programador.http.AbstractServlet - [Future] Ошибка отправки чека
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
at sun.net.)
at sun.net.)
at sun.net.)
at sun.net.)
at sun.net.)
at es.programador.transport.util.d.a(Unknown Source)
at es.programador.http.AbstractServlet.a(Unknown Source)
at es.programador.http.AbstractServlet$2.call(Unknown Source)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2018-11-16 15:00:51,055 INFO es.programador.http.AbstractServlet - [Future] Проверка чека отменена из-за внутренней ошибки.
2018-11-16 15:00:51,055 INFO es.programador.http.AbstractServlet - Сохранение данных для последующей отправки:....ДАННЫЕ ЧЕКА...
2018-11-16 15:02:40,378 INFO es.programador.transport.i.d - Начало задачи обмена документами с сервером ЕГАИС по расписанию
2018-11-16 15:02:40,378 INFO es.programador.transport.i.d - Отправка данных на сервер ЕГАИС по расписанию
2018-11-16 15:02:40,378 INFO es.programador.transport.o - Отправка данных на сервер ЕГАИС
2018-11-16 15:02:40,378 INFO es.programador.transport.o - Публикация данных в кол-ве: 1
2018-11-16 15:02:40,378 INFO es.programador.a.c - Отправка c uuid:dd5dcc9a-2d04-4e7f-97ff-add8abe677a5 docType:Cheque

Пример 2

Цитата:

2018-11-17 19:34:33,370 INFO es.programador.http.AbstractServlet - Получен чек
2018-11-17 19:34:38,768 ERROR es.programador.http.AbstractServlet - Future - Ошибка получения результата проверки позиций чека.
java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask.get(FutureTask.java:205)
at es.programador.http.AbstractServlet.a(Unknown Source)
at es.programador.http.AbstractServlet.doPost(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:821)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1158)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1090)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:56)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119)
at org.eclipse.jetty.server.Server.handle(Server.java:517)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:306)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:261)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:75)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:147)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:748)
2018-11-17 19:34:38,768 INFO es.programador.http.AbstractServlet - Сохранение данных для последующей отправки: ...ДАННЫЕ ЧЕКА...
2018-11-17 19:34:40,375 INFO es.programador.transport.i.d - Начало задачи обмена документами с сервером ЕГАИС по расписанию
2018-11-17 19:34:40,375 INFO es.programador.transport.i.d - Отправка данных на сервер ЕГАИС по расписанию
2018-11-17 19:34:40,375 INFO es.programador.transport.o - Отправка данных на сервер ЕГАИС
2018-11-17 19:34:40,375 INFO es.programador.transport.o - Публикация данных в кол-ве: 1
2018-11-17 19:34:40,375 INFO es.programador.a.c - Отправка c uuid:b6312f59-a88b-4e64-9781-641a9690cc0d docType:Cheque
2018-11-17 19:34:40,484 ERROR es.programador.http.AbstractServlet - [Future] Ошибка отправки чека
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
at sun.net.)
at sun.net.)
at sun.net.)
at sun.net.)
at sun.net.)
at es.programador.transport.util.d.a(Unknown Source)
at es.programador.http.AbstractServlet.a(Unknown Source)
at es.programador.http.AbstractServlet$2.call(Unknown Source)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2018-11-17 19:34:40,484 INFO es.programador.http.AbstractServlet - [Future] Проверка чека отменена из-за внутренней ошибки.

Могу сказать только, что записи из примера 1 у меня например
встречаются чаще..
Думаю, что если после строки "Получен чек" идет запись типа ERROR - то здесь и говорится о незаконченной проверке, если INFO - то онлайн проверка завершена:

Цитата:

2018-11-16 22:55:54,650 INFO es.programador.http.AbstractServlet - Получен чек
2018-11-16 22:55:55,009 INFO es.programador.http.AbstractServlet - [Future] Результат проверки чека: [Проверка пройдена]

█ 18.11.2018 14:34

Добрый день Павел!

Цитата:

plvn24 ➤ Думаю, что если после строки "Получен чек" идет запись типа ERROR - то здесь и говорится о незаконченной проверке, если INFO - то онлайн проверка завершена...

Что мы имеем:

Диагностику описанную и когда-то проверенную на форуме ФСРАР специалистами и подтверденную в то время операторами ФСРАР
При несогласии с правильностью анализа возможность отказаться от данного вида анализа лога транспорта УТМ
Косвенные подтверждения, что исходная диагностика верна на небольшой выборке из "моего" магазина, указанной в письме
Возможные другие проблемы "оборудования" сопутствующие отправке чеков

Конечно, можно и дальше пытаться "угадывать", а можно и "игнорировать" данный анализ... Можно поспрашивать на форуме ФСРАР, где сейчас непринято упоминать отличные от "1С" программы для ЕГАИС... Так, что давайте оставим, как есть? и не будем данной небольшой проблемой "забивать голову"

█ 18.11.2018 18:15

Цитата:

AndreyZh ➤ Так, что давайте оставим, как есть? и не будем данной небольшой проблемой "забивать голову"

Давайте оставим, тем более что что будет опция:

Цитата:

AndreyZh ➤ P.S. Не стал «отключать» данную проверку, а просто добавил ещё подзапрос в «анализатор логов УТМ»:

█ 21.11.2018 09:37

Увы, но что-бы "система не вылетала из головы" приходится постоянно в ней что-то "писать", даже если это "никому не нужно" - получается только мне... 19.10.18 Вынужден "расписаться в бессилии" по проблеме виртуального пользователя, хотя, как всегда задача была сформулирована и отложена "дожидаться своего времени": https://olegon.ru/showpost.php?p=319662&postcount=93

Суть: "При формировании файла для выгрузки в Декларант Алко программа отнесла все поступления по Москва Эфес Калуга на Москва Эфес Ульяновск. Это можно исправить?"

Ответ: Затратил время, но нашел инфу по этому "подарку" ФСРАР на форуме от 15.04.18: https://olegon.ru/showpost.php?p=308611&postcount=31 и в разделе для избранных форума ФСРАР, в теме: "Указан не верный производитель."

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

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

█ 25.11.2018 10:08

В эти, для «нормальных» людей, выходные вынужден был вносить «авральные» технологические изменения в утилиту для ЕГАИС «УС Лэнд:ЕГАИС» в связи с новостью от 22 ноября 2018:

На запрос QueryRestBCode – остатка на регистре №3 по РФУ-2 действует ограничение не чаще чем 1 раз в 10 минут

Также радикальных изменений потребовало обсуждение: https://olegon.ru/showthread.php?t=30568, опять таки в связи с главной новостью сообщения.

1. В настройку программы внесен новый регулирующий атрибут – блокирование анализа наличия марки в пуле при создании и отправки операций в ЕГАИС при помощи программы «УСЕга». Причина: при приёмке ТТН в «чужих» программах «УСЕга» не «знает» о наличии марок в подразделении, а «легализовать» их запросами остатков стало нереально. Конечно – это большая «дыра» в защите от неправильных действий, но ЕГАИС в почти всех случаях корректно анализирует неправильные операции и присылает отказ в их проведении.

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

2. Во всех режимах, запрашивающих остатки на регистре №3 введён контроль периодичности запроса остатков, а в «пакетных», по пачке РФУ-2, режимах перед их отправкой анализируется общее время запроса остатков и запрашивается разрешение на отправку «пакета», которое может происходить «бесконечно долго». Кроме этого для уменьшения «пакета» в таких запросах отсеивается «пиво».

Учитывая, что это «подлое» новшество серьёзно, затрагивающее, точнее «парализующее» учет в оптовках, допуская его «послабление» в настройку программы внесен новый регулирующий атрибут – периодичность запроса остатков регистра №3. По умолчанию 600 секунд – 10 минут, т.е. если «послабление» случится не нужно будет переписывать программу. Рассмотрим, как это происходит на «картинках». Замечу, что как обычно, нашкодив ФСРАР испортил тестовый контур, не давая отладить программу под это, но изменения не касались «документооборота», а лишь добавлялась к нему новая обёртка, т.е. изменения без отладки не приведут к «проблемам».

Например «пакетный» запрос из реестра приходных накладных. Исходно режим предназначался для актуализации остатков регистра №3, если не производилась помарочная приёмка в «УС Лэнд:ЕГАИС», а подтверждение ТТН делалось в другой УС. Везде добавилось «красное» предупреждение:

После анализа «пакета» для отправки программа запрашивает разрешение:

При каждом запросе остатков по конкретной РФУ-2, во всех запросах, справа сверху программа указывает время до момента, когда она сможет отослать запрос, а в пакетных отправках ещё и сколько осталось времени до завершения полной отсылки «пакета»:

P.S. В процессе правки программы выяснил, что для реального мира «УСЕга» ничего страшного, в связи с новостью и обсуждениями не произошло. Все операции, затрагивающие регистр №3 «правильно» ведутся с марта 2018, выявление «фантомных» остатков на нём сделано, когда ещё не было ограничений, т.ч. в негативе остались только «эмоции» от внезапных новшеств и обычного отношения ФСРАР к участникам алкогольного рынка, как к «быдлу».

█ 26.11.2018 12:29

Проблема "марок" скоро станет весьма "актуальной", а тем более у тех, кто использует "УСЕга", как утилиту к своей учетной системе... Вчера получил письмо, где было "непонимание":

Цитата:

Ознакомился с Вашим решением по обходу ограничений "QueryRestBCode". C "таймерами" на формирование запросов пула марок всё понравилось. С "отменой блокировки" при выполнении значимых действий в ЕГАИС остается надеяться на здравый смысл пользователя USLandEgais и порядочность ФСРАР. Для экстренных случаев это, возможно, последний шанс

1. По умолчанию нет "отмены" контроля остатков регистра №3, а до настроек "не всякий пользователь доходит";
2. Не знаю видов операций, где ЕГАИС "пропускает" некорректные операции с марками, т.е. контроль от "УСЕга" избыточен;
3. При любой настройке "УСЕга" контролирует остатки по регистру №1 и №2, отправку "дублей", т.е. просто может "игнорироваться" контроль по маркам регистра №3

А так же предложение:

Цитата:

Если сочтете возможным, то добавьте, plz, в режиме "просмотра входящей накладной" возможность сохранения пула марок с их алкокодами. Например, при сохранении её по "F10". Что-то типа "виртуального" подтверждения ВСЕЙ накладной

Что побудило "вспомнить" алгоритмы, созданные в мае... и внести изменения в поведение программы.

Во первых! При сохранении ТТН в реестр по F10 все марки сохранялись в пул с требуемыми атрибутами: алкокод, справка, принадлежность к рег. №3

Однако доделал более "глобально"! При сохранении по F10 в реестр приходов программа сейчас при наличии марок в ТТН, т.е. вне зависимости от её типа "поштучной" алкопродукции задаёт уточняющий запрос:

При отказе: сохраняет всё, как раньше;

При "да": сохраняет также, все атрибуты сервиса приёмки и назначает остаток по марке вообще и на регистре №3 в частности:

Однако, всё это требует уточняющих замечаний:

1. Понятно, что остатки в пуле программа повышает/понижает только при проведении операций в "УС Лэнд:ЕГАИС"... При необходимости знать реальные остатки (по маркам и на рег.№3) нужно сделать запрос по РФУ-2: программа нулит и переназначает остатки по ответу ЕГАИС

2. В реале приход весь проводится через сервис приёма, а посему при "просто подтверждении" ТТН в пул записываются только марки+алкокод+РФУ-2... Для иммитации "сервиса приёма" нужно исправить выгрузкой через F10

P.S. Описанная выше техника разрешает все проблемы совместного использования с программами от ООО "1С" описанными в теме: https://olegon.ru/showthread.php?t=30568

█ 04.12.2018 09:01

Сегодня будет выложен очередной релиз, связанный с исправлением серьёзного бага: при продаже по чекам или отправки акта постановки на баланс склада программа вылетала по ошибке при обработке параметра блокировки проверки марок в пуле, а так же добавлены ещё 2 класса ошибок в анализатор логов УТМ:

█ 05.12.2018 19:39

Добрый день AndreyZh, пришлось опять взяться за ЕГАИС, как я не отпинывался. Суть проблемы: делаем инвентаризацию по подакцизу, "пропикали" все марки, потом пометили в группу все строки через меню, при этом те позиции которые не пикались но были на остатках почему то не пометились и вопрос номер 1 почему ? Второй вопрос такой, перепометили все позиции которые не "пропикали" т.к. реально их нет, но на остатках болтаются, сделали расчет по группе, создали документы, получилось 2, перемещение из склада в зал, списание из зала. Перемещение отправили и оно прошло успешно. Списание отправляем и приходит отказ, "необеспеченный расход" по одной из позиций. Возвращаюсь в ведомость перемещения и там эта позиция (именно эта, искал по алкокоду, да и название совпадает) перемещена в количестве 3. Возвращаюсь в списание и там эта позиция стоит на списании в количестве 3. Это ошибка самого ЕГАИС или я чего-то непонимаю ?

█ 05.12.2018 21:34

Цитата:

winmasta ➤ Пришлось опять взяться за ЕГАИС, как я не отпинывался.

winmasta, увы ЕГАИС, если не "предохраняться" сильно выматывает нервную систему...

Теперь по вопросу - отвечаю сейчас, т.к. завтра до 14:00 "в поле".

Сейчас есть несколько подходов к проведению данной операции, но основной (Shift+F7) заточен на выборочную и при пропикивании сразу подкачиваются остатки по этим алкокодам.

Далее "манипулирование" с остатками - их можно внести по всем товарам на всех регистрах или только по пропиканной пачки.

По группе: много ограничителей, но если нужно пометить всё, то нужно согласиться с вариантами по умолчанию - знать где то пометку в группу "ограничили"

Это ошибка самого ЕГАИС или я чего-то не понимаю? Возможно было и другое понижение остатков в процессе инвентаризации, а возможно нюанс, например описанный: https://olegon.ru/showpost.php?p=322459&postcount=35 Возможно есть операции и постановки на баланс, которые нужно провести до списаний...

Резюме! Список инвентаризации сохранен, т.е. работа не пропала. Заново запросите остатки, заново закачайте их в таблицу инвентаризации, пересчитайте и повторите создание документов... До этого сохраните данные.