ооо21век.рф

Добрый день.
Поясните, по какому принципу функционирует транспортный модуль.

Если я захожу в 127.0.0.1:8080/opt/out, то вижу там накладную, как на картинке.
То есть, транспортный модуль уже загрузил ее в себя и ждет, чтобы какая то товароучетная система заберет ее из него?
Или транспортный модуль просто прочитал с сервера ЕГАИС заголовки, что ТТН есть на сервере?

Например, если я, после захода по адресу 127.0.0.1:8080/opt/out на первом компьютере и видя там накладную как на картинке, зайду с этим же ключом jacarta на соседнем компьютере (где тоже установлен транспортный модуль), я тоже увижу там эту же накладную? Или не увижу, потому что ее получил первый транспортный модуль?

Суть вопроса здесь очень проста.
1. Каждую минуту УТМ проводит сеанс связи с учетом ФСРАР ИД из аппаратного ключа.
2. В одном цикле вначале отправляет данные затем получает с сервера ЕГАИС.(Повторно данные получить нельзя, если только вы их не попросите в ЛК или у поставщика)
3. Данные отправки и получения хранятся во внутренней базе данных установленного УТМ (вот почему переустановка УТМ приведет к потере этой базы данных если ее предварительно не сохранить)
4. После того как ваша учетная система получить данные из УТМ, по просьбе разработчиков, Вы должны удалить записи из базы данных УТМ иначе она будет разрастаться до бесконечности.
Отсюда вывод если УТМ получил данные повторно ни на этот, ни на какой ни будь другой УТМ данные не поступят.

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

Нет при сканировании марки происходит только входящий контроль на читаемость.
После прохождения первичного контроля УТМ присваивает ИД документа и возвращает строку запроса для проверки.
Сам документ записывается в базу данных УТМ и ждет своей отправки на сервер ЕГАИС. Отсюда и появляется определение возраст буфера чеков. От первого чека в базе данных в течении трех суток выдаются подписи чеков. По истечении этого срока подписи более не выдаются. После отправки буфера на сервер ЕГАИС данные из базы данных УТМ удаляются и начинается новое накопление данных.
Из личных наблюдений замечено, что при обнаружении ошибок в чеке в последующем приходит ответ с текстом "error" перед ИД чека, в котором указаны причины отказа в регистрации чека на сервере ЕГАИС.
Отсюда вывод об ошибках при вводе марок (зеркальность, контрафакт и т.д.) вы узнаете от людей которые к вам придут с перечнем чеков в которых выявлены проблемы.
Можно попытаться анализировать ответы по чекам, но скажу честно мы еще не приступали к реализациям с чеками. Поэтому серьезного опыта пока нет.

Не могли бы вы объяснить, от чего зависит, пробьется чек с QR или нет. Как происходит подтверждение подлинности и с чем и где сравнивается PDF417?

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