| Сущность |
Смысл |
| Person / пользователь |
Учётная запись и контакты |
| Partner / партнёр |
B2B-клиент в ТС, ценовой уровень, скидка, валюта, склады |
| Payer / плательщик |
Юридическое/физическое лицо, от имени которого оформляется заказ |
| Receiver / грузополучатель |
Получатель и адреса; для Global не должен блокировать checkout |
| Warehouse / склад |
Источник остатка, цены, срока и правил отгрузки |
| Warehouse group |
Группирует склады для доставки и доступности |
| Cross group |
Группа взаимозаменяемых артикулов |
| Forthcoming / ожидаемое поступление |
Будущая партия, которую можно предзаказать/зарезервировать на RF |
- пользователь может войти с уже существующими в ТС данными или зарегистрироваться на сайте;
is_self_registered должен различать самостоятельную регистрацию и первый вход из ERP; это требование ТЗ №10, факт выкатки не подтверждён;- партнёр и плательщик идентифицируются ERP ID, а не только email;
- изменения пользователя/компании из ТС доставляются на сайт входящими API-методами;
- привязка корзины к партнёру, а не только к логину, позволяет добавлять товар в корзины всех связанных учётных записей.
sequenceDiagram
participant C as Клиент
participant W as Global
participant B as Bitrix24
participant M as Менеджер
participant E as ТС Spain
C->>W: Регистрация + email-код
W->>B: Лид
M->>C: B2B-проверка
M->>E: Партнёр, плательщик, цены, склады
E->>W: Обновление/привязка
C->>W: Повторный вход
W-->>C: Цены, склады, личный кабинет
- карточка объединяет фото, характеристики, кроссы, цены/наличие и применяемость;
- поиск должен игнорировать лишние пробелы и обрабатывать кросс-номера;
- статистика поиска записывает основной артикул при переходе в одну карточку/из подсказки и исходный запрос при множественной выдаче;
- синонимы марок автомобилей ведутся отдельным справочником;
- при смене названия кросс-группы должны обновляться title, description и поисковые ключи;
- после импорта нужно сбрасывать кэш применяемости и корректно удалять исчезнувшие документы из Elasticsearch.
Конечная цена зависит от базовой цены, валюты клиента, персональных и брендовых скидок, акций, минимальной отпускной цены и признака запрета скидок. Цену нужно перепроверять на backend перед созданием заказа.
Важная эксплуатационная оговорка: корзина может получать актуальные остатки без кэша, а карточка/модальное окно — из кэша. Такое расхождение не всегда является ошибкой, но должно объясняться пользователю.
- строка корзины должна учитывать артикул, бренд, склад, цену и конкретную партию/пул остатка;
- если несколько строк после истощения партий ссылаются на один пул, доступное количество должно распределяться последовательно, а не показываться целиком каждой строке;
- заказ обычно разделяется по складам;
- после создания ТС становится мастером статуса и истории;
- ошибки
basket update чаще всего требуют сверки строк корзины с живыми остатками, ценой и партией.
Для RF поддержаны поля IsNoDiscount, MinPriceEur, MinPriceRub, IsReserveWithoutCancel, ReserveComment, ReserveDiscount.
Сценарий:
- Сайт рассчитывает цену клиента с учётом всех скидок и ограничений.
- Для «резерва без отмены» применяется дополнительная скидка.
- Перед резервированием клиент видит явное предупреждение о невозможности отмены.
- В ERP передаются цена, признак и комментарий; ERP также блокирует DELETE.
- При поступлении товара ERP формирует заказ на этапе «Сверка»; клиент видит его в истории и получает email.
На 11.03.2026 API-изменения были опубликованы на production RF. Полная UI-приёмка всех комбинаций цены и скидки в материалах не найдена.
Более позднее решение заменяет старую логику «город в шапке не дальше 100 км от склада»:
- способ доставки привязывается к группе складов;
- для заказа показываются общие способы и те, что доступны его группе;
- новый адрес передаётся в ТС с привязкой к складу/группе;
- дубли адресов должны отсекаться;
- курьерская доставка показывается по настройке ТС, а не по GeoIP города в шапке.
ТЗ №13 содержит старую 100-км логику как объяснение кейса, но сам документ помечен «на согласовании». До утверждения source-of-truth противоречие остаётся открытым.
- при регистрации создаётся лид;
- при временной ошибке Bitrix24 лид не должен теряться;
- ТЗ №10 требует фоновую очередь: флаг ожидания, ID лида, worker каждые 5 минут и повтор до успеха;
- реализация этой очереди в production не подтверждена;
- дубли ERP partner ID в карточках компаний CRM могут привести к показу неверного менеджера и его контактов;
- для Global предложена кнопка «Хочу купить», создающая задачу по товару без предложений; реализация не подтверждена.