Разработчикам и продвинутым пользователям. Нюансы и ошибки функционирования ЕГАИС : КИС Lack & УС Land

AndreyZh · █ 20.06.2020 16:41

Нечто "новенькое" и как всегда введенное задним числом без объявлений, но критично для постановки старых марок на регистр №3 --- опять программу "УСЕга" переделывать, дабы не утруждать мозги пользователей

Нельзя привязывать старые марки к РФУ-2 по алкопродукции, поступившей по новым маркам

Это следует из свежего диалога продуктивного контура форума фсрар:

Цитата:

Вчера, 10:16 Здравствуйте. Переводим алкогольную продукцию с партионного учета в поштучный. Создаем документ фиксации акцизных марок и у не которых документов егаис возвращает ошибку "РФУ2 не может содержать марки разных образцов". Документ который мы отправляем ИД документа "6b9f65da-5231-4268-b379-f85d0b41edf3" ФСРАР ИД "02****"

Цитата:

Непрочитанное сообщение operator9 » Вчера, 17:27

Продукция по справке FB-000002409156193 поступила к Вам с новыми марками, а Вы пытаетесь привязать старые марки к этой справке, система не позволит это сделать

… и вопрос недоумения:

Цитата:

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

AndreyZh · █ 22.06.2020 11:35

Ни дня без новенького… Для любителей постоянно обновлять драйвера RuToken и релизы УТМ ЕГАИС стал отвечать ошибкой

Цитата:

PKCS11Exception: CKR_FUNCTION_NOT_SUPPORTED

Решения:

1. Откатить драйвер RuToken до 4.8.5.1 и УТМ до билда 1259

2. Или воспользоваться рекомендациями разработчиков RuToken: , где данная проблема подробно описана

AndreyZh · █ 07.07.2020 10:39

Не верьте глазам своим - просто ЕГАИС снова начал усложнять себя ненужными сущностями

Суть понятая из свежего диалога: сейчас на отправку акта подтверждения / отказа / расхождения приходит ещё одна ненужная квитанция об "утверждении" оборота по накладной ЕГАИСом

Цитата:

Нам пришла ТТН входящая (возврат от покупателя) TTN-0387203034. Мы сделали на нее полный отказ. Вроде как, документооборот должен на этом закончиться (не берем случай с распроведением акта). Но в итоге грузоотправитель отправил какую-то квитанцию о приеме нашего акта ОТКАЗА. В итоге наша система вообще перевела данную ТТН в принятый статус. И на сайте чек1 инфа следующая:

отправка получателю:
Статус: Отправлено в УТМ
Дата вставки: 15.06.2020 23:08:03
Дата смены статуса: 15.06.2020 23:08:29
Связанные документы:
Получателем ( Общество с ограниченной ответственностью Производственно-Коммерческая фирма "Гармония" ) составлен Акт отказа с номером NN0004970 от 16.06.2020 0:00:00
Отправка акта получателю (отправителю накладной):
Статус: Отправлено в УТМ
Дата вставки: 16.06.2020 17:20:37
Дата смены статуса: 16.06.2020 17:22:06
Отправителем ( Общество с ограниченной ответственностью "Традиция Саранск" ) отправлена квитанция о приеме акта от 30.06.2020 15:39:40

Что еще за квитанция о приемке акта ОТКАЗА???

Цитата:

Документ WayBillAct_v3 с указанием в тэге "IsAccept" значения "Accepted" (акт на полное подтверждение накладной) или "Rejected" (т.е. акт на полный отказ от накладной) не требует подтверждения/отказа со стороны грузоотправителя.
После успешной фиксации акта согласия или отказа на сервере накладная соответственно примет статус "Принята" или "Отклонена", и документооборот по ней будет завершен. В случае, если грузоотправитель отправит квитанцию на акт разногласия по накладной, документооборот которой уже завершен, данная квитанция будет отказана сервером с ошибкой: "Отказ при операции с актом приема продукции. Состояние документа не позволяет произвести данную операцию".
В таком случае данную квитанцию грузополучатель может игнорировать.

Продолжение...

Цитата:

Вы пишите "данная квитанция будет отказана сервером с ошибкой: "Отказ при операции с актом приема продукции. Состояние документа не позволяет произвести данную операцию"." В очередной раз имеем "кривую квитанцию", которую зачем-то сервер все равно пересылает грузополучателю. Зачем? Так было в начале помарочного учета с инверсиями дат, когда заведомо ошибочные тикеты приходили второй стороне. Я тогда начал эту тему, меня как котенка заткнули. Слава богу потом fkr и другие форумчане все таки подключились, и вопрос был решен. Логика должна быть единая и простая: если сервер возвращает отправителю документа (ЛЮБОГО документа) ошибку, то не нужно этот документ пересылать получателю. А то получается в духе "на, лови документ с ошибками."
Да, знаю, что меня опять проигнорируют, и никакие изменения внесены не будут, поэтому все таки переспрошу: данное поведение системы - это на данный момент нормально и всегда так будет, или это был разовый сбой?

Цитата:

Непрочитанное сообщение operator8 » 19 минут назад

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

AndreyZh · █ 16.07.2020 09:00

Спасибо R2D2:

Одной из причин возникновения ошибки CKR_KEY_TYPE_INCONSISTENT является выпуск ГОСТ-ключа по ГОСТ Р 34.10 - 2012 с длинным ключом (512 бит). Этот алгоритм электронной подписи не поддерживаются Универсальным транспортным модулем (УТМ), причем в Личный кабинет ЕГАИС зайти по нему получится и есть возможность сгенерировать RSA-ключ.

Решение:
Обратиться в удостоверяющий центр (УЦ) для перевыпуска ГОСТ ключевой пары и сертификата по алгоритму ГОСТ Р 34.10 - 2012 с коротким ключом (256 бит). Просмотреть размер ключа можно в сертификате в разделе "состав", пункт - "открытый ключ"

… и конечно данная причина добавлена в анализатор: https://olegon.ru/showthread.php?t=31234, где данная ошибка уже ловилась, а теперь даёт ещё и дополнительную диагностику

AndreyZh · █ 13.08.2020 12:48

Дабы другие не вляпались в … диагностику УТМ позвольте описать свою жуткую историю? Активно писал программы и пользовал ЕГАИС до 30.07.2020, а затем забросил. Как вдруг 10.08.2020 срочно нужно было взглянуть в БД ЕГАИС по КА, а УТМ не запускается. Пропустил логи через анализатор - нет проблем! Взглянул на логи напрямую, такая фигня с 10.08:

Цитата:

2020-08-13 09:26:21,013 INFO es.programador.transport.q - Проверьте запущен ли Transport Updater.
2020-08-13 09:26:21,013 INFO es.programador.transport.q - Проверьте не занят ли порт [8193] другим приложением
2020-08-13 09:26:21,013 INFO es.programador.transport.Transport - Повторная проверка начнется через [60] сек.
2020-08-13 09:27:21,016 INFO es.programador.transport.q - Проверка состояния Transport Updater
2020-08-13 09:27:23,094 ERROR es.programador.transport.q - Ошибка проверки состояния Transport Updater.

Верю написанному - пытался в ручную всё запускать... не помогало. Начал проверять порт 8193 - закрыт! Изучал в промежутках между более важными и срочными делами, как его открыть - десятки способов не помогли... На разных ПК, с разными ОС, разными провайдерами...

Пришлось сейчас обращаться к "ангелу спасителю" Толе - знакомому системному администратору, а он не обращая внимания на эту диагностику полез в настройки RuToken - а там Rsa ключ закончился 06.08.2020... Ну чё - переписал его и всё заработало!

Однако просмотрел черновики - раньше УТМ четко указывал на просрочку ключа, а по реале сроки его обновления у меня в планировщике.... А тут оказался "сапожник без сапог"

AndreyZh · █ 14.08.2020 12:00

Как много нам открытий чудных… Сейчас просматривая диалоги по ЕГАИС наткнулся на занятную информацию. Вопрос - "от поставщика пришло сырьё, в котором код вида продукции указан - 101. Что это за вид?"... В ОФИЦИАЛЬНОМ классификаторе: его нет???

… Далее обсуждение и наконец ссылка, где ведутся необъявляемые пополнения классификатора кодов видов алкогольной продукции:

P.S. Оставил для себя с целью ревизии настроек своих программ, т.к. навскидку там появились новые по торгуемому алкоголю

AndreyZh · █ 29.09.2020 14:18

Возможно тугодум

однако не смог до конца просчитать последствия данного алгоритма работы ЕГАИС, особенно в преддверии 1 ноября 2020. Необходимость сплошной фиксации старых марок на регистре №3? Нужно ли отлаживать все возможные "подводные камни" или просто нужно ввести жесткий регламент работы продавцов и добавить жесткие ненужные ограничители в работу программы "УС Лэнд:ЕГАИС"? Что после 1.11.20 нельзя будет совместное использования разных программ для ЕГАИС?

Оставлю данные диалог с egais2016 для дальнейшего анализа:

Цитата:

Вопрос: Точно помню, что попытка передачи в регистр2 поштучных остатков, какое-то время назад, заканчивалась неудачей, ЕГАИС отвергал документ с сообщением, что-то типа справка такая-то не является помарочной. Это как бы один из признаков поштучных остатков - их невозможно передать в регистр2.

Занялись переводом оставшихся партионных остатков в поштучные документом ActFixBarCode, предварительно вернув из регистра2 в регистр1.

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

Хороший ответ, который нуждается в проверке, но для этого нужно ломать БД "УСЕга", что неохота:

Цитата:

Если первоначально справка позволяла переводить на регистр 2, то так и будет позволять. Если первоначально не позволяла - не будет позволять и дальше переводить на рег.2.

Как-то так. Связано с тем, как производитель сделал отчёт о производстве - с указанием или без указания справок. Обязательным стало указание марок при производстве/импорте с 01.04.2020.

P.S. Например "раньше" можно старую марку, а точнее все марки РФУ-2, было отвязать указав связку "алкокод + РФУ-2" в расходной накладной или акте списания.

P.P.S. Предположим в "УСЕга" зафиксировали все РФУ-2 на регистре №3 в плане подготовки к 1.11, а затем в другой программе попытались трансфернуть под остаткок в ТЗ, как в легких процессах ликвидации магазинов: https://olegon.ru/showthread.php?t=26006&page=3 ... и вся трудоёмкая работа по ревизии и отнесению в регистру №3 ушла "к коту под хвост"?

P.P.P,S. Конечно в "УСЕга" во всех типах операций всё контролируется по маркам и программа не даст, по внутренним регистрам провести данные операции... но всё же?

plvn24 · █ 29.09.2020 14:48

Цитата:

AndreyZh ➤ Что за странное поведение? Почему система дает передавать из регистра1 в регистр2 поштучные остатки? Что-то поменялось в методике?

Ничего у них не поменялось в методике, потому что признак поштучной партии устанавливается на сервере ЕГАИС только для новых марок.

Возможно, внесут изменения с 01/11..
А пока да, легко можно "коту под хвост" всю работу отправить, если в УС нет контроля

AndreyZh · █ 12.11.2020 15:34

… кажется наступила катастрофа?

Почему? - Просто наказания для предприятий за бардак в ЕГАИС из-за отсутствия методологии вообще никто не отменял! Часть "обхода" выявленных методом тыка проблем описывалось: https://olegon.ru/showthread.php?t=34673 а здесь позвольте описать прочитанный "армагедец" и официальный способ его "исправления" из свежих диалогов - думаю, что читатели данной темы достаточно компетентны, что бы понять практические способы исправления "катастроф"

Цитата:

Остатки запрашиваются каждый день. На утро дня обращения остаток по оптовому регистру по 0003404000001258924 был 2 штуки (фактически в магазине одна бутылка), по 0003404000001258930 был 5 штук (фактически в магазине четыре бутылки). статок на сегодня точно такой же. Что мне можно предпринять?

Цитата:

Проведен анализ. На сервере ЕГАИС был зафиксирован Акт фиксации штрихкодов AFBC-0002955082. В данном акте присутствует марка 22N000000XIM80G2NXO02MK90214047005545ID901UNLWCU808H4VD0DVZCFEC5IV34, которая привязывается к справке FB-000003135470631. Однако данная марка принадлежит справке FB-000002481304872.

После этого фиксируется продажа марки 22N000000XIM80G2NXO02MK90214047005545ID901UNLWCU808H4VD0DVZCFEC5IV34 и обнуление остатка по справке FB-000003135470631.

Для исправления ситуации необходимо произвести возврат продукции, отвязать марку от некорректной справки Б и привязать к корректной. После проделанных действий необходимо сообщить в данную тему.

Аналогичная ситуация со справкой FB-000003105078133. К ней была привязана марка 22N000000XIM80G2NXU02MK9021404800216004Y3MDKM64Y2DF7JMS0XIA3K36IOIME и реализована. Хотя данная марка принадлежит справке FB-000002551104930. Для данной продукции справедливы рекомендации, данные выше.

Цитата:

Так как у меня похожая ситуация по другому магазину, расскажите, пожалуйста,

- Как определить справку Б, глядя на бутылку, которая пришла партионно?

- Как сделать возврат продукции: какой документ, как заполнить?

-Как отвязать от некорректной справки Б? Привязать, думаю, смогу.

- Как делать новую реализацию?

Цитата:

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

Запросить остатки штрихкодов на балансе организации (третьем регистре) можно с помощью документа QueryRestBCode. Ознакомиться с данным документом более подробно Вы можете в технической документации УТМ, пункт 3.7. - Запрос остатков штрихкодов по идентификатору справки 2.

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

Привязать марки к РФУ-2 можно актом фиксации штрихкодов на балансе организации (ActFixBarCode) - п. 3.8 документации. Отвязать - актом отмены фиксации штрихкодов на балансе организации (ActUnFixBarCode) - п. 3.9. документации.
Cкачать актуальную версию технической документации УТМ Вы можете в личном кабинете egais.ru во вкладке "Транспортный модуль".

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

… ну а дальше "риторические" вопросы:

Цитата:

На бумажной первичной документации не указывались номера справок FB-0000, в бумажных есть только дата розлива. По ней и определяли дату прихода. Но продукция с одной датой розлива приходила несколькими партиями. Взяли более позднюю.

Продукция приходила партионно, на третьем регистре марок по этой продукции не будет.

Если в акте фиксации было несколько наименований и другие привязались верно и уже реализованы?

Фиктивные возвраты делать по всем позициям?

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

P.S. Один из возможных способов избежать данных ситуаций - всё, что можно переводить на регистр №2, где уже не будет путаницы с РФУ-2, что лично мне не нравится, т.к. в недалеком будущем всё таки будет отказ от регистра №2 и нужно, как-то будет возвращать всё назад.

Другой, который, как надеюсь, т.к. используется нами - стараться без нужды не привязывать к регистру №3 марки - делать это только для списаний... хотя, доделал УСЕга - можно только кол-во под списание перевести на рег№2, а там спокойно списать... и для перемещения на другое подразделение... и молиться

FinSoft · █ 13.11.2020 08:26

Честно говоря, плохо понимаю, про что речь. Если старая марка пришла без поштучного учета, то информации о ней в егаис нет. В приходах есть связка алкокод+справка 2. Из содержимого марки можно определить алкокод. Ошибка возникнет, если привязать марку к справке 2 с другим алкокодом. Или к справке 2, по которой нет остатка в парционном учете. По моему, в этих случаях егаис возвращает ошибку.
Определять справку 2 по дате розлива, это что-то совсем нереальные дебри, кто это и как будет делать и контролировать?
Или я что-то не так понимаю?