stpavel163

Качаем deb-пакеты, устанавливаем. Служба uema вроде бы стартует, но касса не работает. Лезем в логи — служба тупо не может подключиться к MQTT-серверу АТОЛа.

Тут спасибо Дмитрию Бачило и его ролику (https://youtu.be/5t0QBE24h58). Оказалось, что гении разработки из АТОЛ просто положили кривой конфиг в дистрибутив под Linux. Дефолтный конфиг — мусор.

Чтобы эта дрянь начала работать, конфиг (/etc/uem/agent/config.yml ) должен выглядеть так: ( жирным выделены изменения )

storage:

file: /etc/uem/agent/storage.db

uema_port: 5050

uemu_port: 5051

info:

modified: 2026-01-06T10:08:23+04:00

uemconfig:

uem_host: mqtt://plt-002.atol.ru

uem_port: 1883

uem_reg_host: https://entry-plt-002.atol.ru

logconfig:

file: /var/log/uem/agent/uema.log

log_level: debug

log_depth_in_days: 50

log_depth_in_mb: 30

monitoringconfig:

static_data_timeout_in_sec: 86400

dynamic_data_timeout_in_sec: 1200

Казалось бы, пофиксили конфиг, служба завелась, коннект есть. Можно выдохнуть? Хрен там плавал.

Акт второй: Танцы с бубном

Самое веселье началось при попытке подружить наш софт с этим чудом.
Запускаем наш Python-скрипт — ошибка драйвера: "Сервер UEMA не запущен" (или что-то в этом духе).

Я проверяю порты: netstat -tulpn | grep 5050. Служба висит! Порт доступен для подключения! Сервер работает и прекрасно себя чувствует.
Но драйвер (библиотека .so, которую использует софт) его в упор не видит.

Я перепробовал всё. Я пытался скармливать параметры подключения в коде. Я перерыл документацию (которой, по сути, нет). Я плясал с бубном вокруг прав доступа.
Запускаю официальную ГУИшную утилиту "Тест драйвера ККТ" от самого АТОЛа. Думаете, она работает? НЕТ! Даже родной софт матерится, что сервер UEMA не запущен.

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

Финал:

Разгадка оказалась настолько тупой и неочевидной, что у меня глаз задергался.
Оказывается, чтобы драйвер под Linux вообще догадался, куда ему стучаться (хотя порт 5050 — это, блин, дефолт!), нужно создать секретный файлик.

Создаем файл: ~/.atol/drivers10/uem.env
Пишем туда одну строку:
ATOL_UEMA_ADDRESS=127.0.0.1:5050

И всё.
Всё, б****! Оно заработало.

Эпилог

Уважаемые (нет) программисты АТОЛ. Вы вообще тестируете свой софт перед релизом? Или у вас "на винде запустилось — и ладно"? Почему пользователь должен искать решение по ютубам и методом тыка создавать environment-файлы, о которых ни слова в мануале? Вы выкатываете критическое обновление перед налоговыми изменениями и подсовываете нам нерабочий кусок кода с битыми конфигами.

Горите в аду со своим uema..

1. Регистрируешься в личном кабинете для бизнеса.

2. Пополняешь баланс. В отличие от СДЭКа, где можно платить по факту, здесь предоплатная система: сначала закинь деньги, потом отправляй.

3. Оформляешь накладные, клеишь штрихкоды.

Всё сделал «по фен-шую», упаковал, прихожу в пункт выдачи. И тут начинается цирк.

Оператор смотрит на мои коробки с немым вопросом: «Это что?».
— Как что? — говорю. — Это Яндекс.Доставка, я через вас отправляю.
— А я не знаю, что с этим делать...

Девушка пытается сканировать штрихкод — система молчит. Звонит кому-то из руководства — ее переключают дальше. Я начинаю терять терпение, звоню в поддержку сам.

Ответ поддержки убил:

«Да, извините, мы выясним. Перезвоним вам в течение пары часов».

Пары часов?! Я уже потратил 40 минут в пункте выдачи. К оператору претензий нет, она искренне пыталась помочь, но система просто не работала.

В итоге я забрал свои «многострадальные» посылки, поехал домой, переоформил всё на Boxberry (которого, к слову, уже не осталось - сожрал Яндекс) и отвез в город. Самое смешное: поддержка Яндекса перезвонила, когда я уже ехал обратно. Разговаривать не стал, просто пожелал им хорошего дня.

Спойлер: Процесс расторжения договора с Яндексом и возврата средств — это отдельная, полная боли история про компетентность их специалистов, но опустим детали.

Акт второй. Посылки с AliExpress, или Логистика уровня «Бог»

Вторая ситуация произошла буквально на днях, уже с позиции меня как покупателя.

Я ждал две посылки с AliExpress. Последние полгода площадка агрессивно навязывала доставку через Яндекс.Маркет, ставя её по умолчанию как «Рекомендуемую». Раньше я выбирал постаматы «Пятерочки», но в какой-то момент они пропали из быстрого выбора (как оказалось позже, их спрятали глубоко в интерфейс карты, оставив на виду только Почту России и Яндекс).

Выбрал Яндекс.Маркет. Срок хранения позволял забрать заказ через несколько дней. Прихожу в пункт выдачи, а мне говорят:
— А мы закрылись вчера.
— В смысле? А где мои посылки?
— Они уехали на склад. Мы ничего не знаем, пишите в поддержку.

Диалог с поддержкой Яндекс.Доставки:
Я описываю ситуацию: ПВЗ закрылся, посылки увезли, они мне очень нужны. Верните их в любой соседний пункт!
Сутки (сутки, Карл!) они думали.
Вердикт: «Раз вы покупали на AliExpress, пишите туда. Мы ни при чем».

Диалог с поддержкой AliExpress:
— По нашим данным (трек-номеру), посылки ждут вас в пункте выдачи. Идите и забирайте.

Получается замкнутый круг. Я отправляю Алиэкспрессу скрины переписки с Яндексом, где черным по белому написано, что ПВЗ закрыт. Они что-то выясняют и выдают финал:

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

Итог

Вдумайтесь в этот абсурд. Вместо того чтобы просто перенаправить посылки в соседний ПВЗ (который может находиться в 500 метрах), логистический гигант, компания, которая кичится своим ИИ и технологиями XXI века, просто отправляет товар обратно в Китай!

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

Для себя я выводы сделал: это был последний раз, когда я связывался с доставкой от Яндекса — хоть как продавец, хоть как покупатель.

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