RedDragon: доработка интернет-магазина на Webasyst

Региональные витрины: отдельные домены, контакты и магазины

Московская витрина на собственном домене

Подключили домен reddragon-msk.ru к московской витрине магазина. Впоследствии исправили ситуацию, когда вместо работы на этом домене посетителя перенаправляло на московский раздел петербургского сайта.

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

Сочи, Симферополь и Севастополь

Для Сочи создали склад торговой точки, связали его с 1С и подготовили отдельную витрину на reddragon-sochi.ru. Позднее дополнили региональное представление сайта отсутствовавшим Сочи.

Для крымского направления работы проходили на разных этапах: корректировали идентификаторы в отдельной копии сайта, затем создавали в основной системе склады магазинов на Севастопольской улице в Симферополе и на улице Пожарова в Севастополе. Для этих складов были предусмотрены отдельные витрины под доменом reddragon-crimea.ru.

В истории проекта также присутствует запрос на перенос оформления петербургского сайта на самостоятельные сайты Ярославля и Крыма. Подтверждение завершения именно этого переноса дизайна отдельно не зафиксировано.

Подготовка сайта для Нижнего Новгорода

Для reddragon-nn.ru поставили задачу создать копию петербургской витрины без переноса заказов, прежнего чата и поискового скрипта. Остатки на новом сайте требовалось обнулить, а вместо прежних складов оставить новую торговую точку.

В последующих исправлениях удалили оставшийся чат и лишние витрины, устранили проблему с очисткой складов и ошибку, мешавшую выбрать основной склад. Для магазина на Большой Покровской настроили связь с соответствующим идентификатором 1С.

Это отдельный региональный запуск: перенос внешнего вида не должен был автоматически переносить историю заказов и доступные остатки другого города.

Контактная информация отдельно для каждого региона

Доработали настройку общей информации по витринам, чтобы телефон и email не подтягивались везде только из Санкт-Петербурга. Для управления использовали региональные настройки и дополнительные поля региона, включая содержимое маркера.

В требования к навигации вошли выпадающий выбор города, переходы на самостоятельные региональные домены и понятная ссылка на адреса магазинов. Отдельно рассматривался вариант окна с адресами, телефонами, временем работы и переходом к карте.

SEO-регионы и витрина по умолчанию

Настроили плагин «SEO-регионы»: расширили перечень городов и подстановку названия выбранного города в SEO-теги. Для остальных городов предусмотрели использование витрины reddragon-spb.ru.

Дополнительно обсуждалась возможность переключения на города, отсутствующие в заранее заведённом списке, через расширенную версию плагина. Её приобретение и включение этой функции не представлены как выполненная часть настройки.

Ранее поступало и отдельное обращение по переключателю регионов: в Яндекс Браузере переход на Крым или Ярославль возвращал на Санкт-Петербург, а в Chrome нажатие не давало результата. Окончательный результат этого конкретного обращения в истории не указан.

Интеграция с 1С: идентификаторы товаров, склады и налог в карточках

Исправление связей товаров по данным заказчика

На основном сайте и в отдельной копии крымского проекта корректировали идентификаторы 1С в карточках товаров. Для массовых изменений использовали предоставленные заказчиком таблицы; отдельно исправляли обнаруженные несоответствия между артикулом, внутренним ID товара и идентификатором учётной системы.

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

Подключение и обновление идентификаторов складов

Создавали новые склады и меняли их сопоставление с 1С при открытии торговых точек и изменении учётных данных. В числе таких задач — магазины в Сочи, Симферополе, Севастополе и Нижнем Новгороде, точки на Туристской улице, улице Шувалова и Московском проспекте.

Отдельно настраивали склады «Адресное 2», «Адресное 3», «Адресное 4», «Адресное хранение 6», магазин в ТРК «Охта Молл» и точку в ТРК «Лето» на Пулковском шоссе. Для каждой использовалось соответствие конкретному складу в 1С, а не только совпадение названия на сайте.

Передача НДС через CommerceML

Проверили и исправили передачу налоговой информации из 1С в карточки товаров. Обращение возникло потому, что в настройках CommerceML присутствовал параметр типа налога, а ожидаемые данные в товарах не отображались.

Эта задача касалась наполнения карточек через обмен. Позднейшая просьба убрать отдельную строку налога из оформления заказа относилась уже к отображению корзины и не означала удаления налоговых данных из учёта.

Расхождения между остатком товара и его артикулами

Разбирали ситуации, когда количество в каталоге, карточке товара, административной панели и 1С не совпадало. В одном из примеров показывалось 177 единиц вместо ожидаемого количества доступных товаров; заказчик также указывал на возможное попадание остатка со склада брака.

Для отдельной карточки помог пересчёт общего количества по артикулам при сохранении товара. Однако дальнейшие проверки показали, что вопрос шире одного товара: повторный обмен не устранил все расхождения, потребовались массовый пересчёт и проверка складских данных.

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

Ассортимент по способу доставки и наличию в выбранном магазине

Выбор товаров без создания отдельной витрины для каждой точки

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

На этапе согласования рассматривались разные способы представления недоступных товаров: скрыть их либо оставить видимыми, но недоступными для заказа. Для такого выбора не требовалось создавать самостоятельную витрину на каждый магазин.

Виртуальные склады для курьерской доставки

В правилах подбора ассортимента отдельно оговаривались курьерская доставка по Санкт-Петербургу, СДЭК и Boxberry: для них требовалось использовать общий виртуальный склад интернет-магазина. Для московского курьера поставили условие учитывать сумму остатков московских магазинов.

Позднее проверили объединение склада интернет-магазина со «Складом Опта» и «Складом Б». Вместо назначения нескольких отдельных складов одному способу доставки использовали виртуальный склад. Такой вариант прошёл проверку в рамках обращения и позволил учитывать дополнительные источники наличия.

Первый выбор доставки и пояснение для покупателя

Для Санкт-Петербурга и Москвы добавили автоматическое открытие окна выбора способа доставки у посетителей, которые его ещё не выбрали. В окно включили пояснение: от указанного способа получения зависят ассортимент и цены на товары.

Эта доработка решала конкретную проблему первого посещения: человек видел наличие, но не понимал, почему доступность покупки меняется после выбора магазина или доставки.

Наличие по сети и по отдельным магазинам

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

По отдельному запросу временно заменили надпись «Нет в наличии» на «Доступно в рознице». Это изменение текста не превращало остатки розничной точки в товары, доступные для доставки с основного склада.

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

Ограничения по складам и повторные проверки

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

Отдельные проверки затрагивали категории косметики и кокосовых продуктов: выбранный магазин имел товар, но карточка продолжала ориентироваться на нулевой остаток интернет-магазина. Это обращение выявило необходимость согласовать источник наличия между фильтром, карточкой и кнопкой покупки; отдельной отметки о завершении именно этого исправления нет.

В более поздней задаче исправили другие расхождения: товар показывал 34 доступные единицы, но корзина принимала только 27; другая позиция находилась через поиск, однако оказывалась недоступной при переходе и добавлении в корзину.

Заказ из разных магазинов

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

Для корзины с товарами из разных магазинов заказчик запросил предупреждение о возможном изменении конечного состава заказа. Эти условия сохранены как отдельная постановка задачи: их нельзя автоматически считать полностью реализованными только на основании более позднего плагина выбора склада.

Интеграция Shop-Script с Яндекс Едой

Каталог, цены, остатки и поступление заказов

Разработали интеграцию с Яндекс Едой для передачи номенклатуры, цен и остатков по торговым точкам. Заказы должны поступать в административную панель магазина, а обработка и переключение состояний выполняться из Shop-Script.

Для рабочего процесса использовали отдельные статусы: «Новый заказ Я.Еда», «В работе Я.Еда», «Изменен Я.Еда», «Отменить заказ Я.Еда», «Отменен клиентом Я.Еда», «Заказ готов Я.Еда» и «Завершен Я.Еда». Их сопоставили с состояниями заказа внешнего сервиса.

Изменение правил передачи остатков

Правила запаса при выгрузке менялись вместе с требованиями заказчика. Изначально из остатка каждого склада требовалось вычитать 10 единиц, затем для Яндекс Еды этот запас уменьшили до 3 единиц.

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

Понятный источник заказа для операторов

Изменили представление заказов Яндекс Еды в административной панели: вместо имени покупателя в согласованном поле стал отображаться источник «Яндекс Еда». Информацию о самом клиенте сохранили в отдельном месте.

Так операторы могли отличать агрегаторные заказы от обычных обращений интернет-магазина, не теряя необходимые сведения о заказе.

Восстановление изображений в каталоге Яндекс Еды

Исправили формирование адресов фотографий в выгрузке. Ранее ссылки передавались без адреса сайта, поэтому Яндекс Еда не могла загрузить изображения.

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

Приём заказа при расхождении остатка одной позиции

Устранили сценарий, при котором нехватка остатка по одной позиции приводила к отклонению всего заказа. В результате такой заказ вообще не появлялся у операторов магазина.

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

В более раннем обращении была зафиксирована другая ошибка при создании заказа — сообщение о необходимости добавить хотя бы один товар и некорректный формат ответа. Отдельный итог исправления именно этой ошибки в материалах не указан.

Самовывоз и передача финального статуса

Расширили интеграцию для самовывоза: доработали создание и обновление заказа, статусную модель и лейблы товаров по предоставленному техническому заданию.

Отдельно исправили передачу финального статуса DELIVERED. Ранее он не отправлялся, что создавало риск автоматической отмены заказов на самовывоз со стороны сервиса.

Интеграция с Купером: каталог, цены и остатки по торговым точкам

Обмен со Сбермаркетом через API

Реализовали обмен со Сбермаркетом, позднее фигурирующим в задачах как Купер. Интеграция охватывала каталог, цены, остатки и заказы; в технической постановке использовались направления Orders API и Content API.

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

Ошибка одной торговой точки блокировала общую выгрузку

При проверке обмена обнаружили, что в выгрузках цен и остатков передавался идентификатор точки, ещё не зарегистрированной на стороне Купера. Сервис возвращал ошибку отсутствующего outlet_id.

Проблема относилась к магазину в ТРК «Охта Молл», но отклонялись выгрузки сразу по всем точкам. Исправили передачу остатков и цен, после чего обмен по действующим магазинам восстановился.

Подключение самой новой точки оставили зависимым от её регистрации в Купере. Для уже заведённых, но отключённых точек на Таганской и площади Ленина требовалось отдельное решение заказчика о включении продаж.

Передача новинок и регионального ассортимента

Восстановили передачу каталога: до исправления новые товары не доходили до Купера. Это была самостоятельная проблема, не ограниченная обновлением цен уже известных сервису позиций.

Ранее отдельно проверялось отсутствие магазина в Сочи. В ответе по этому обращению указали на необходимость завести соответствующую торговую точку на стороне партнёра. Сам факт создания склада в Shop-Script не рассматривался как подтверждение его подключения к внешнему сервису.

Маркетплейсы и товарные фиды: Ozon, Яндекс Маркет, Wildberries и Едадил

Настройка Ozon и Яндекс Маркета

Настроили приобретённые заказчиком интеграции Ozon и Яндекс Маркета. Задача заключалась в подключении существующих кабинетов и плагинов к обмену остатками, ценами и состояниями заказов, а не в разработке этих приложений с нуля.

Для Ozon в задании была указана модель realFBS, для Яндекс Маркета — работа по экспресс-сценарию. Обмен требовалось вести по складам; в первоначальных условиях присутствовал запас в 10 единиц при передаче остатка.

Фоновые задания первой интеграции Wildberries

Настроили расписание задач плагина интеграции с Wildberries: ежеминутную обработку заданий экспорта, обновление цен ночью, передачу остатков каждые 20 минут и синхронизацию заказов каждые 15 минут.

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

Переход к другому плагину Wildberries

При проверке альтернативного плагина «Wildberries: Интеграция» подключили основные команды: актуализацию цен и остатков, получение заказов с обновлением статусов и автоматическую публикацию товаров.

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

Размеры упаковки для выгрузки товаров

Для товаров, у которых отсутствовали необходимые размеры, создали характеристику и массово заполнили согласованное значение 10 × 10 × 10 см. Это была подготовка данных по требованию заказчика, а не измерение фактической упаковки каждого товара.

После заполнения выполнялась пробная публикация через плагин и cron. В переписке осталось замечание об ошибке при отдельной ручной отправке, поэтому подготовка характеристики не представлена как подтверждение успешной выгрузки всего каталога.

Два товарных фида для Едадил

Подготовили отдельные товарные фиды для Санкт-Петербурга и Москвы по требованиям Едадил. В них требовалось передавать актуальные цены и наличие с учётом торговых точек.

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

Поиск по каталогу и интеграция SearchBooster

Настройка поискового плагина и дополнительные пожелания

Настроили приобретённый поисковый плагин wsearch. Ранее заказчик также запрашивал анимированные примеры запросов в поисковой строке и распознавание ввода в неправильной раскладке.

Установленный на тот момент SearchPro не решал эти задачи в нужном виде. Их обсуждение и последующее подключение другого поиска отражены как разные этапы: наличие нового плагина само по себе не подтверждает выполнение всех первоначальных пожеланий.

Отдельная витрина для проверки SearchBooster

Создали копию витрины по адресу /store/ для тестирования поиска SearchBooster отдельно от основной витрины. В её шаблон подключили предоставленные сервисом трекер и виджет.

В код подключения вошли предварительные соединения с используемыми доменами и предусмотренные поставщиком способы загрузки скриптов. Позднее размещение поискового кода в шапке тестовой витрины обновляли по дополнительному обращению.

Расширение YML-фида для поиска и фильтрации

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

Отдельно исправили смешивание брендов и стран: страны попадали в тег <vendor> и выводились как бренды. После корректировки сведения о стране передавались в согласованном параметре «Изготовитель».

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

Корзина и избранное непосредственно из поисковой выдачи

Связали виджет поиска с действиями интернет-магазина. Для этого реализовали функции получения состава корзины и изменения количества товара, а также чтения и переключения избранного.

Интеграция использовала методы sbCartItems, sbOnChangeOfferCount, sbFavouriteItems и sbOnFavouriteChange. Поисковый интерфейс получил возможность взаимодействовать с корзиной и избранным, а не только открывать карточки товаров.

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

Личный кабинет и программа лояльности: MAXMA и kilbil

Интеграция интернет-магазина с MAXMA

Разработали интеграцию личного кабинета с CRM MAXMA. В согласованном сценарии основным идентификатором участника программы выступал номер телефона: при регистрации сайт проверял наличие клиента в CRM и либо связывал существующую запись, либо создавал новую.

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

В дальнейшем отдельно исправили передачу изменённых имени и фамилии из профиля сайта в MAXMA. Без этой доработки в профиле магазина и разделе программы лояльности могли отображаться разные сведения одного участника.

Страница программы лояльности

Для личного кабинета предусмотрели страницу с изображением карты соответствующего уровня, данными участника, балансом и штрихкодом. Первоначальное название «Мои баллы» впоследствии заменяли на «Программа лояльности», в том числе исправляли его повторное появление при переходах внутри кабинета.

Служебную формулировку о переходе на следующий «грейд» заменили на понятное покупателю слово «уровень». Для скидочного уровня требовалось показывать процент скидки вместо блока общего количества баллов.

В требованиях к оформлению были определены отдельные изображения карт и логотип во всплывающем окне. Для макета карты согласовали PNG 1000 × 632 пикселя, для небольшого логотипа — PNG 50 × 50 пикселей.

Добавление карты на iPhone и Android

В кабинет включили кнопки перехода на персональную страницу добавления карты для iPhone и Android. В ходе проверки формирование таких ссылок подтвердили для новых участников.

Повторное добавление карты для ранее созданных клиентов осталось отдельным замечанием: пользователь мог удалить карту и захотеть восстановить её через кабинет. Завершение этого сценария отдельно не подтверждено.

Также уточнили назначение штрихкода на странице: он представляет номер карты лояльности. Его не следует описывать как универсальную ссылку установки карты в электронный кошелёк.

Баллы в корзине и ограничения по уровню

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

Участнику скидочного уровня блок списания баллов не требуется: применяется его скидочная механика. Из корзины убрали лишнее поле «Дисконтная карта».

Исправили и сообщение при превышении доступного списания. Вместо утверждения о недостатке баллов оно должно объяснять ограничение текущего уровня программы: пользователь может иметь больший баланс, но не иметь права потратить его целиком на один заказ.

Промокод, скидка и баллы без суммирования

Исключили сложение скидки по программе лояльности со скидкой по промокоду. В согласованном примере при скидке участника 7% и промокоде на 10% применяется более выгодный для покупателя вариант.

Для бонусного уровня оговаривалось использование либо промокода, либо баллов; для скидочного — промокода либо скидки уровня. Проверка промокода должна учитывать правила системы лояльности, а сайт — использовать полученные данные при перерасчёте заказа.

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

История покупок и ограничения офлайн-данных

В кабинете предусмотрели историю покупок с датой, суммой, начисленными и потраченными баллами. При проверке обмена уточнили, что запись покупки и обновление показателей программы происходят после перевода заказа в согласованные состояния «Оплачен» или «Выполнен».

Заказчик дополнительно запросил раскрывающиеся подробности покупки, строку начисления баллов и разные подписи для бонусного и скидочного уровней: «Оплачено баллами» либо «Скидка».

Для офлайн-операций использовавшийся обмен предоставлял историю баллов, дату и идентификатор действия, но не состав товаров и не номер интернет-заказа. Поэтому одинаковая детализация онлайн- и офлайн-покупок не представлена как реализованная возможность.

По отдельному замечанию удалили строки «Начисление по акции», которые заказчик не хотел выводить в этом представлении истории.

Переход с MAXMA на kilbil

На следующем этапе сменили систему лояльности с MAXMA на kilbil через API. Работы затрагивали петербургский, московский и крымский сайты; заказчик поставил условие сохранить существующую механику программы.

Таким образом, MAXMA и kilbil в этом кейсе относятся к разным этапам развития проекта. Ранние задачи по MAXMA описывают историю создания личного кабинета и бонусных сценариев, а не одновременную работу двух программ лояльности.

Регистрация, подтверждение контактов и восстановление доступа

Форма регистрации и проверка номера телефона

Доработали регистрацию под программу лояльности. В форму вошли имя, фамилия, телефон, email, дата рождения, пол, пароль и подтверждение пароля. Для телефона предусмотрели префикс +7, маску и ввод цифр; для email — проверку заполнения.

После регистрации пользователь должен подтвердить телефон четырёхзначным кодом. В окне ввода предусмотрены обратный отсчёт и возможность запросить новый код после завершения ожидания.

После успешной проверки пользователь получает авторизованный доступ, а на email отправляется письмо подтверждения. Вход в кабинет поддерживает телефон или email в сочетании с паролем.

Изменение данных в профиле

В профиле предусмотрели изменение имени, фамилии и телефона с передачей соответствующих данных в CRM. При добавлении или замене телефона используется подтверждение номера.

Для неподтверждённого email требовались заметный индикатор и кнопка отправки проверочного письма. После подтверждения эти элементы должны исчезать. Дату рождения разрешалось заполнить один раз, без последующего самостоятельного изменения уже сохранённого значения.

Покупатели, ранее зарегистрированные без телефона

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

Окно содержит переход в личный кабинет и действие «Напомнить позже». При откладывании оно не должно повторяться в течение текущей сессии. В профиле выделяется поле номера с маской и подтверждением кодом.

После успешной проверки телефон закрепляется за аккаунтом и передаётся в CRM для связи с участником программы.

Восстановление доступа для офлайн-участников

Доработали восстановление доступа для покупателей, зарегистрированных в MAXMA через розничную точку без email. Для них обычное сообщение об отправке ссылки на почту не решало задачу.

Сценарий предусматривает подтверждение телефона кодом, переход в кабинет и заполнение email и нового пароля. Подтверждённый email затем передаётся в карточку клиента в MAXMA.

В рамках проверки исправили ошибку при подтверждении email, передачу адреса в CRM и расположение предложения установить новый пароль.

Исправление ошибок регистрации

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

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

SMS-агрегатор, капча и альтернативное подтверждение

Перевели SMS-отправку петербургского, московского и крымского сайтов на GreenSMS. Смена агрегатора выполнялась отдельно от правил регистрации и связи аккаунта с программой лояльности.

Заказчик также запрашивал замену SMS-подтверждения звонком и исправление капчи из-за большого количества запросов кодов. Позднее повторно сообщалось о некорректной работе Яндекс SmartCaptcha и штатной капчи Webasyst, не принимавшей правильный ответ.

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

Доработка корзины и оформления заказа

Оформление на одной странице

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

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

В ходе согласования заказчик уточнял соответствие корзины макету, расположение кнопки выбора доставки и стоимости, размеры элементов и повторение итогового блока. Эти требования отделены от конкретных исправлений, завершение которых отмечено в истории работ.

Большие корзины и доступность всех позиций

Исправляли несколько разных сценариев работы с большим количеством товаров. В одном случае после добавления более 20 позиций и прокрутки пропадали первые строки, из-за чего их нельзя было редактировать.

В другом обращении добавление свыше 30 наименований зависало: товары появлялись только после обновления страницы, а открыть корзину было затруднительно. Позднее устранили проблему оформления с более чем 14 позициями, когда отсутствовала прокрутка всего списка.

В последнюю задачу также вошли массовое удаление содержимого и устранение длительного ожидания при удалении отдельного товара.

Изображения, сообщения и информационный блок

Исправили исчезновение изображений товаров при оформлении заказа и некорректные символы в сообщениях формы. Для воспроизведения одного из ошибок проверяли сценарий, когда покупатель вводит телефон, затем удаляет его и пытается оформить заказ.

Устранили дублирование и появление фрагментов кода на странице успешного оформления. В корзину добавили редактируемый текстовый блок, через который заказчик может менять общую информацию без переработки всей страницы.

Поле «Код купона» переименовали в «Промокод», а сообщение об ошибке — в «Промокод недействителен». Эти подписи согласовывались для разных разрешений экрана.

Самовывоз без лишнего адресного требования

Разбирали блокировку заказа при самовывозе из-за незаполненного адреса доставки. В конкретном сценарии отключили лишний адресный ввод: у Boxberry использовались собственные поля выбора адреса и пункта.

Отдельно зафиксировано обращение, когда в Санкт-Петербурге и Москве доставка и оплата продолжали требовать адрес, хотя контактная информация уже была введена. Завершение именно этого обращения в истории не отмечено.

Редактирование заказа в административной панели

Восстановили редактирование заказов для сотрудников. При возникновении ошибки ни один пользователь не мог открыть форму изменения: отображалась бесконечная загрузка без результата.

Эта работа относилась к административной панели, а не к форме заказа для покупателя.

Доставка, самовывоз и совместимость правил оформления

Фильтры оплаты и доставки

Восстанавливали работу плагина фильтрации оплаты и доставки. Позднее отдельно разбирали исчезновение курьерского способа после попытки назначить один склад всем вариантам получения заказа.

Проверка затронула несколько независимых условий: скрытое поле страны с определением местоположения по IP, минимальную сумму заказа для курьера и ограничения по складам. В одном из правил «Основной склад» отсутствовало нужное значение.

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

СДЭК и отображение налоговой строки

Исправили настройки подключения СДЭК, из-за которых доставка не работала при внешне заполненной конфигурации. В рамках того же обращения убрали нежелательное отображение строки налога в корзине.

Настройка доставки и изменение вывода строки выполнялись как отдельные действия: исправление интерфейса не означает отмены налогового учёта товара.

Пункты выдачи 5Post

Исправили первоначальную проблему 5Post, когда в корзине не отображались пункты выдачи. В дальнейшем поступило повторное обращение: доставка снова показывалась недоступной и не загружала ПВЗ.

Первое исправление отмечено выполненным, однако у повторной задачи от сентября 2026 года нет подтверждения завершения. Поэтому подключение 5Post не представлено как окончательно закрытая на весь период проблема.

Представление вариантов доставки

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

Настройку состава и порядка способов планировали проверять после переноса на рабочий сайт. Выполненные изменения размеров и шрифтов не подменяют проверку всех тарифов и ограничений.

Дизайн и развитие темы: главная, каталог, карточка товара и мобильная версия

Структура основных страниц

Исходное задание на дизайн охватывало шесть страниц: главную, категорию, товар, оформление заказа, новости и страницу 404. Требования к структуре уточнялись по макетам и проверкам на разных устройствах.

Для категории предусматривались три колонки, сортировка, плиточный и списочный режимы, постраничная навигация, описание категории и баннер в ширину центрального контента. Повторный вывод одних и тех же подкатегорий под H1 требовалось убрать, оставив навигацию в боковой части.

Для товаров с несколькими фотографиями запрашивалось переключение изображений в каталоге. Эти пункты описывают согласованную структуру и требования; отдельные выполненные исправления перечислены далее.

Карточка товара и наличие по магазинам

В задании карточка занимала всю ширину контента, миниатюры располагались под главным фото. В блок покупки входили артикул, цена, зачёркнутая цена, количество, обычная покупка, покупка в один клик и избранное.

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

Для списка магазинов отдельно ставилось требование скрывать точки без наличия. Впоследствии этот сценарий развивался вместе с выводом количества по складам и выбором способа получения заказа.

Главная страница, категории и редактируемые изображения

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

Отдельно разъяснили редактирование блока «Наши проекты» и его изображений. Для использовавшихся небольших баннеров был указан размер 250 × 50 пикселей; для мобильного баннера — ширина от 768 пикселей с согласованием высоты под композицию.

В требованиях к широким экранам заказчик просил полноразмерный главный баннер вместо квадратного изображения, пересмотр избыточного серого фона, перенос адресов ближе к выбору города и удаление пункта «Как сделать заказ».

Позднее появилась отдельная идея заменить часть блоков баннерами и использовать формат историй. Конкретный вариант поведения — интерактивные истории либо переход по ссылке — остался на согласовании.

Компактный каталог и фильтры

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

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

Различия размеров карточек при переключении плитки и списка разбирали через настройку соответствующего плагина. Для планшетного меню отдельно запрашивались название «Другие категории» вместо «Другие продукты» и более компактный вывод подкатегорий.

Избранное из каталога и между устройствами

Добавили возможность отмечать товар избранным без обязательного перехода в его карточку. Отдельно решали доступность списка избранного для посетителя, который ещё не авторизовался.

Для авторизованных покупателей синхронизировали избранное между компьютером и телефоном: добавление на одном устройстве должно отражаться на другом. Позднее исправили кнопку «Очистить список».

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

Ярлыки, скидки и элементы карточек

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

Изменили отображение скидки с рублей на проценты. При повторном обращении исправили несогласованность между категорией «Скидки» и самой карточкой, где скидка снова показывалась денежной суммой.

Мобильные размеры и расположение блоков

Уменьшили главное фото товара и заголовок в мобильной карточке. Привели высоту ряда кнопок и полей к высоте кнопки каталога, включая фильтры, промокод, «Лучшее предложение» и «Новинки».

Сократили лишние расстояния между иконками, строками и блоками, убрали избыточный промежуток между баннером и «Нашими проектами». В каталоге настроили по два товара в строке вместо трёх; аналогично дорабатывали действия с избранным в компактном представлении.

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

Дополнительные требования к мобильной компоновке

Для макета шириной 320 пикселей заказчик отдельно запросил вывод региона, телефона и почты, масштабирование главного слайдера и двухколоночное размещение ряда блоков.

В постановку вошли подписи под иконками, перенос «Наших проектов» ниже продуктовых категорий, вертикальное размещение баннеров и две колонки «Контакты» и «Магазины» в подвале. Блоки «О нас» и «Отзывы» в этой версии предлагалось убрать.

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

Блог, служебные страницы и вывод кода

В структуре блога предусматривались первая новость горизонтальным блоком, остальные — вертикальными карточками, а для публикаций без фото — изображение-заглушка. Страница 404 должна была соответствовать общему оформлению сайта.

Выполнено отдельное исправление размытых миниатюр блога. Для ранее загруженных изображений требовалось повторное обновление; в рамках настройки рекомендовали квадратные исходники размером более 400 пикселей.

Разбирали появление фрагментов кода в категориях: причиной в рассмотренном случае была переменная, внесённая в заголовок неподходящим способом. Это отличалось от отдельно исправленного вывода кода на странице успешного заказа.

Коммуникации с покупателями, уведомления и подтверждение возраста

Обратный звонок, чат и социальные ссылки

Восстановили обратный звонок после изменения темы. Вместо Chatra подключили виджет чата Битрикс24 через предоставленный код; эта задача относится к чату на витрине, а не к полной интеграции всех процессов магазина с CRM Битрикс24.

Исправляли переход по кнопке YouTube и добавили ссылки с иконками на Telegram, Одноклассники, Яндекс Дзен и Rutube. В подвале также корректировали цвет ссылки и размещение элементов.

Для уже существовавшего мобильного приложения разместили кнопки App Store и Google Play. Разработка самого приложения в этой задаче не заявлялась. Отдельно установили VK-пиксель.

Почта после смены сервера

Настроили отправку почты интернет-магазина с нового сервера. Это было самостоятельное обращение после изменения почтовой конфигурации, не связанное с заменой SMS-агрегатора.

Для рассылок MAXMA также ставилась задача добавить в домен предоставленные CNAME-записи DKIM, чтобы отправлять письма от имени «Красного Дракона». Отдельного подтверждения внесения этих записей в документе нет.

Окно подтверждения возраста

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

В условия вошло применение на нескольких витринах. Для авторизованного участника программы лояльности с указанной датой рождения и возрастом от 18 лет повторное окно не требовалось.

Дополнительно обсуждалось управление областью действия через категории, подкатегории или тип товара. Эта работа описывает интерфейс ограничения просмотра, а не юридическую проверку возраста покупателя.

Уведомление об использовании cookie

Добавили уведомление об использовании cookie по предоставленному визуальному примеру, используя отдельный плагин. В задачу входило размещение соответствующего интерфейса на сайте.

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

Техническая поддержка, сервер и фоновые процессы

Резервная копия и проверка работы на другом сервере

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

В отдельное задание входил перенос петербургского и московского сайтов на VDS с сохранением заказов, SSL-сертификатов, обмена с 1С, интеграции Яндекс Еды и работы плагинов. Полная приёмка каждого условия именно этого переноса в документе отдельно не зафиксирована.

Ошибки 504 и нагрузка на базу данных

Разбирали недоступность сайта с ошибкой 504 и тайм-ауты при авторизации интеграции Яндекс Еды. По сообщению хостинга, в одном из случаев значительную нагрузку создавала база данных, а её перезапуск временно восстанавливал работу.

В рамках обсуждения рассматривались тяжёлые запросы, фоновые скрипты и параметры MySQL. Предложения хостинга по дополнительной настройке и выносу базы на отдельный сервис не представлены как автоматически выполненные работы.

Отдельно поступало обращение об отсутствии соединения с базой данных. Подтверждение его окончательного устранения в истории не указано.

Повторные зависания и диагностика PHP

В последующих обращениях проверялись массовые запросы, длительно работающие процессы PHP-FPM, тайм-ауты Apache и достижение предела обработчиков. В переписке также обсуждалась настройка open_basedir, но она не была подтверждена как единственная причина недоступности.

Ещё одна серия замечаний касалась бесконечной загрузки и ошибок обращения к отсутствующим элементам массивов. Перезагрузка сервера помогала временно; окончательное устранение этой повторной проблемы в документе не отражено.

Эти обращения не используются как основание для заявления о доказанной DDoS-атаке или измеренном ускорении сайта: в материалах есть диагностические предположения, но нет итогового отчёта с такими выводами.

Cloudflare и обсуждение кеширования

Подключили Cloudflare по запросу заказчика. Позднее консультировали по возможности использования Super Cache для ускорения страниц.

Покупка и результат настройки Super Cache отдельно не подтверждены. Подключение Cloudflare также не означает, что все последующие серверные ошибки были устранены этим действием.

Расписание плагинов и подготовка сертификата

Настроили выполнение операций по расписанию для плагинов carts, pricetype и pnotice. Задачи этих модулей рассматривались отдельно от расписаний маркетплейсов.

Для работы с банковским API выполнили генерацию приватного ключа и запроса CSR на выпуск сертификата по инструкции Тинькофф. Это конкретная подготовительная работа с сертификатом, а не заявление о разработке всей банковской интеграции.

Дополнительные требования к развитию проекта

Интеграция с Delivery Club

Заказчик запрашивал обмен с Delivery Club каталогом, остатками и ценами через API в формате JSON. В требованиях присутствовало уменьшение остатка каждого склада на 10 единиц перед передачей.

Рассматривались доработка установленного «API оптовика» либо отдельное решение. Эта задача повторно поднималась в истории проекта, но подтверждения завершённого подключения нет. Она не объединяется с выполненной интеграцией Яндекс Еды.

Обмен с платформой Starter

Поставлена задача связать административную панель магазина со Starter по аналогии с другими каналами продаж. Запрошенный состав обмена — каталог, цены, остатки, заказы и статусы.

Для обсуждения была предоставлена документация сервиса. Реализация и приёмка этой интеграции в материалах не зафиксированы.

Подарочные сертификаты онлайн и в рознице

Обсуждалось соединение плагина подарочных сертификатов Shop-Script с kilbil. Цель — продавать и использовать сертификаты как на сайте, так и в офлайн-магазинах.

Запрос встречается на нескольких этапах сопровождения, однако готовая сквозная схема продажи и списания сертификатов не подтверждена. Поэтому этот функционал сохранён как самостоятельное направление развития.

Баннеры, истории и дополнительные элементы интерфейса

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

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

Результаты разработки и сопровождения RedDragon

Работа над «Красным Драконом» охватила несколько связанных направлений: региональные витрины, обмен с 1С, складские ограничения, внешние каналы продаж, программу лояльности и повседневные сценарии покупки.

Среди подтверждённых результатов — интеграции Яндекс Еды и Купера, исправление передачи каталога и изображений, развитие самовывоза, выбор ассортимента по доставке, настройка региональных складов, создание личного кабинета с MAXMA и последующий переход на kilbil.

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

Нужна доработка магазина на Webasyst?

Для обсуждения похожего проекта достаточно прислать ссылку на сайт и описать рабочий сценарий: какие склады участвуют в продаже, как покупатель выбирает доставку, какие данные должны передаваться в 1С и внешние сервисы, какие правила скидок необходимо сохранить.

Подробнее об услуге — программирование и доработка интернет-магазинов на Webasyst. Другие примеры представлены в разделе доработки и техническая поддержка сайтов.