Серия о CdekPoint. Первая часть — обзор продукта и сценариев выдачи. Здесь — отчёт с реальной стойки ПВЗ 13 июля 2026: что вскрылось в работе и что изменили за день (v1.9.1 → v1.13.2, 14 релизов).
CdekPoint — desktop-приложение для менеджеров ПВЗ CDEK: упрощённая «касса выдачи» вместо полного веб-ЭК5. Задача — быстрый онбординг на стойке, особенно для менеджеров после WB Point, которым ЭК5 кажется перегруженным.
13 июля приложение тестировали на реальной стойке — со сканером, живыми клиентами и боевым Gateway. Ниже — не технический changelog, а что вскрылось в работе и что изменили в ответ.
Структура: сначала что поняли, потом что улучшили.
Часть 1. Что поняли
1. Оплату на стойке не «отменить» — её можно только минимизировать
Изначальная идея CdekPoint — стимулировать оплату в приложении CDEK: меньше эквайринга на стойке, быстрее выдача, проще для менеджера. Бизнес-эффект очевиден: чем больше клиентов платят в приложении, тем меньше кассовых операций на ПВЗ.
Но на реальной стойке выяснилось: полностью уйти от приёма оплаты на ПВЗ нельзя. Даже при административных мерах и переводе большинства клиентов в приложение остаются случаи, когда деньги нужно принять здесь и сейчас — наличные, клиент без приложения, оплата не прошла в момент выдачи и другие ситуации.
Вывод: CdekPoint должен не «обходить» оплату, а встроить её в сценарий выдачи — так же, как в ЭК5, но проще для менеджера.
2. Проверка оплаты — обязательный этап перед выдачей и перед приёмом денег
Чтобы встроить оплату в сценарий выдачи, нужен понятный процесс: менеджер должен видеть актуальную сумму к оплате, знать, можно ли уже выдавать, и иметь возможность перепроверить после того, как клиент оплатил — в приложении или на стойке.
Для этого в CdekPoint внедрили живую проверку через payment-info — запрос к серверу ЭК5 в момент работы с заказом. Это не самоцель, а первый рабочий шаг цепочки:
- Проверить — есть ли сумма к оплате
- Предложить оплату в приложении CDEK (предпочтительный путь)
- Принять на стойке — если без этого не обойтись (следующий этап: модуль «Касса» ЭК5)
- Проверить снова — сервер подтвердил, что к оплате 0 ₽
- Выдать
Пока реализованы шаги 1, 2 и 4 (проверка и перепроверка). Шаг 3 — приём оплаты на стойке — в плане.
Вывод: без payment-info невозможно ни корректно блокировать выдачу неоплаченного заказа, ни внедрить приём денег на стойке. Проверка — опорная точка всего платёжного процесса.
3. Два пути оплаты — и оба нужны
| Путь | Роль |
|---|---|
| Оплата в приложении CDEK | Основной, к которому стремимся административно |
| Оплата на стойке | Исключение, но неизбежное — его тоже нужно поддержать |
Принцип: по умолчанию приложение, стойка — исключение, не первый экран — но исключение всё равно должно работать технически и быть понятным менеджеру.
4. «Склад» задумывался для офлайна — а на стойке нашёл другое применение
Раздел «Склад» изначально делали под другой сценарий: работа при проблемах с сетью или ЭК5 — выдача по печатным накладным того, что физически лежит на полке, с последующей регистрацией в системе, когда связь восстановится. Локальный кеш заказов, кеш PDF накладных, сохранение данных при обрыве сессии — всё это заточено под эту задачу.
Но на реальной стойке всплыл другой кейс, которым пользуются опытные менеджеры: они находят заказ быстрее через «Склад», чем через сканирование штрихкода. Клиент называет фамилию или телефон — менеджер ищет в списке, видит метку «Код» или «Паспорт», сумму к оплате — и открывает карточку. Без лишнего шага со сканером.
Вывод: «Склад» оказался не только «запасным аэродромом» на случай офлайна, но и оперативным инструментом поиска для ежедневной работы. Значит, его нужно развивать и как офлайн-контур, и как быстрый путь к заказу — с поиском, фильтрами и подсказками прямо в списке.
5. Карточка заказа перегружала внимание
На реальной стойке стало видно: менеджеру не нужен «мини-ЭК5». Ему нужен пульт действий — кто, куда, что делать сейчас, можно ли выдавать.
Проблемы, которые заметили:
- важные блоки (способ выдачи, оплата, код/паспорт) размазаны по экрану;
- при длинном тексте кнопки «Выдать» и «Снять с примерки» уезжают за нижний край;
- прокручивается вся карточка, а не только второстепенная информация;
- в блоке «особенности» смешаны приём груза и выдача — на выдаче приём только отвлекает;
- в паспортном wizard дублируется заголовок и шаг — создаёт ощущение «застрял на месте»;
- сумма к оплате дублируется в разных местах, когда уже показан блок оплаты.
Вывод: карточка должна быть иерархией: сверху — контекст (получатель, маршрут), по центру — действие (как выдаём, оплата, код), внизу — две кнопки, которые всегда на месте. Всё остальное — в прокрутке.
6. Мелкие трения накапливаются за смену
Казалось бы, мелочи — но за смену они съедают минуты и нервы:
- штрихкод
[CDK]не читается при русской раскладке клавиатуры (сканер эмулирует клавиатуру); - после ошибочного ввода нужно вручную чистить поле скана и поиска;
- в очереди примерки висят уже вручённые заказы;
- открыли заказ со скана, а он не на примерке — показывается нерабочая кнопка «Снять с примерки»;
- при обрыве сессии ЭК5 пропадает список — хотя локально данные уже были;
- на новой машине ПВЗ приложение не стартует без отдельной установки .NET — для стойки это стоп-фактор;
- окно каждый раз открывается в другом размере и положении — на стойке с фиксированным монитором это раздражает.
Вывод: UX стойки — это не «красота интерфейса», а устойчивость к реальным условиям: раскладка клавиатуры, сканер, сеть, «чистый» ПК, один и тот же монитор.
7. Менеджеру нужен объём работы «в один взгляд»
Без счётчиков менеджер постоянно переключается между экранами, чтобы понять: сколько на примерке, сколько готово к выдаче, есть ли «паспортные» заказы.
Вывод: бейджи в шапке, метки на карточках и суммы в списке — не украшение, а снижение когнитивной нагрузки. Каждый индикатор отвечает на конкретный вопрос: «сколько у меня работы прямо сейчас?»
8. Паспортная выдача — отдельный сценарий, не «запасной выход»
Wizard выдачи по документу (v1.9.0) уже был, но на стойке стало видно: это полноценный рабочий процесс, а не fallback «если не получилось по коду». У него свой фильтр на складе, свои шаги, своё подтверждение «Сделал?» перед выдачей.
Вывод: паспортный сценарий нужно поддерживать наравне с выдачей по коду — отдельный фильтр, отдельный UX внутри wizard, без дублирования заголовков.
Часть 2. Что улучшили
Оплата — встроили проверку как первый шаг платёжного процесса
| Что сделали | Зачем на стойке |
|---|---|
Живая проверка payment-info на карточке заказа | Актуальная сумма к оплате в момент выдачи — основа для решения «выдавать / принимать деньги» |
| Блок «К оплате N ₽» / «Оплачено» | Менеджер сразу видит, нужен ли платёжный шаг |
| Кнопка «Проверить оплату» | Перепроверить после оплаты клиентом — в приложении или (в будущем) на стойке |
| Блокировка «Выдать» при сумме > 0 | Выдача только после подтверждения сервером, что оплата прошла |
Логи Payment| в файле | Отладка платёжного сценария на реальном ПВЗ |
| Сумма к оплате в списке склада (красный блок) | «Денежные» заказы видны до входа в карточку |
Версии: v1.10.5, v1.11.0. Следующий шаг — кнопка «Оплатить на стойке» → ККТ → повторный payment-info → «Выдать».
Склад — от офлайн-запаса к оперативному поиску
Изначально: синхронизация заказов на ПВЗ, локальный кеш, кеш печатных форм накладных; при истёкшей сессии или недоступном ЭК5 — данные не пропадают; готовый к выдаче заказ при открытии автоматически попадает на примерку.
Добавили по итогам тестирования — под сценарий «опытный менеджер ищет без ШК»:
- Поиск по фамилии, телефону, номеру заказа в локальном кеше
- Фильтр «Паспорт» — только заказы с выдачей по документу
- Метки «Код» / «Паспорт» на карточках в списке
- Красный блок суммы к оплате прямо в списке
- Компактная шапка — поиск, фильтры и обновление в одной строке
- Компактные карточки — полка, места и сумма в одной панели
- Кнопка × для быстрой очистки поля поиска
- Бейдж «Склад» в шапке — число накладных, готовых к выдаче
Версии: v1.6.0 (базовый склад), v1.9.1 (кеш при обрыве), v1.10.0 – v1.10.6 (поиск, фильтры, метки, компактность).
Карточка заказа — три итерации UX за вечер
- v1.12.0 — единая «зона действий»: способ выдачи, оплата и код/паспорт одним блоком под получателем; сумма не дублируется в деталях
- v1.12.1 — две колонки в шапке; «Проверить оплату» справа от текста; особенности — отдельный скролл
- v1.13.0 — кнопки «Снять с примерки» и «Выдать» закреплены внизу; окно запоминает размер и положение
- v1.13.1 — прокручивается только блок особенностей; в паспортном wizard убрано дублирование шага
- v1.13.2 — скрыты особенности приёма груза; блок переименован в «Особенности выдачи»
Сканирование и очередь «На примерке»
- Распознавание штрихкода
[CDK]при русской раскладке клавиатуры - Кнопка × для быстрой очистки поля на экране выдачи
- Бейдж «Выдача» в шапке — число заказов на примерке (скрывается при 0)
- Автоочистка уже вручённых заказов из очереди примерки
- Кнопка «Закрыть» вместо нерабочей «Снять с примерки», если заказ не на примерке
Версии: v1.9.1 – v1.10.1, v1.9.2 – v1.9.3.
Развёртывание на «чистой» машине ПВЗ
- .NET 8 runtime встроен в дистрибутив
- Логи с первого запуска; при ошибке — путь к логу на экране
- Запасной каталог логов:
%TEMP%\CdekPoint\logs\ - Установщик Windows обновлялся с каждым релизом
Версия: v1.10.4.
Итог
Поняли:
- Оплата на стойке — часть реальности ПВЗ, которую можно минимизировать через приложение, но нельзя игнорировать технически.
payment-info— опорная точка платёжного процесса.- «Склад» — не только офлайн-контур, но и оперативный поиск для опытных менеджеров.
- Стойка ломается на перегруженном UI и мелких трениях, которые за смену превращаются в проблему.
- Менеджеру нужен пульт, а не справочник ЭК5.
Улучшили:
- 14 релизов за один день (v1.9.1 → v1.13.2)
- Проверку оплаты (
payment-info) как первый шаг платёжного процесса - «Склад» — и как офлайн-запас, и как инструмент быстрого поиска
- Карточку заказа — от «простыни ЭК5» до пульта с закреплёнными кнопками
- Устойчивость к реальным условиям: русская раскладка, встроенный runtime, кеш при обрыве сессии, память окна
Дальше: приём оплаты на стойке через модуль «Касса» ЭК5; сценарий CDEK ID; частичная выдача и отказ получателя.
Справка: версии за день
| Версия | Суть |
|---|---|
| 1.9.1 | Русская раскладка штрихкода; бейдж склада; кеш при обрыве сессии |
| 1.9.2 | Чистая очередь примерки |
| 1.9.3 | «Закрыть» вместо нерабочей «Снять с примерки» |
| 1.10.0 | Поиск на складе; метки Код/Паспорт; счётчик примерки |
| 1.10.1 | Быстрая очистка полей (×) |
| 1.10.2 | Фильтр «Паспорт» |
| 1.10.3 | Компактная шапка склада |
| 1.10.4 | Встроенный .NET; логи с первого запуска |
| 1.10.5 | Сумма к оплате в списке склада |
| 1.10.6 | Компактные карточки склада |
| 1.11.0 | Проверка оплаты; логи Payment|; план интеграции кассы |
| 1.12.0 | Единая зона действий на карточке |
| 1.12.1 | Двухколоночная шапка |
| 1.13.0 | Запоминание окна; кнопки закреплены внизу |
| 1.13.1 | Скролл только в особенностях; паспортный wizard |
| 1.13.2 | Только особенности выдачи |
Скачать и документация
Актуальная сборка — v1.13.2 (13 июля 2026):
- Обзор продукта и сценариев выдачи — первая часть серии
- Что нового — полная история версий
- Руководство пользователя
- Лендинг продукта
Пилот для коллег-франчайзи. Ищем 2–3 офиса или ПВЗ с похожим профилем. Напишите через контакты с темой «CdekPoint».
См. также: терминал и АРМ 2.0 в ЭК5, опыт WB Point, BIT CRM для франчайзи СДЭК.
Франчайзи СДЭК: нефискальная печать на кассах АТОЛ требует актуальной прошивки (ИТС Connect). Мы сами партнёры франшизы и знаем ЭК5 — обновление «под ключ» с минимальным участием собственника. Напишите в TechSpot или оформите на marketbit.ru — от 5 500 ₽.