1ttd.ru: доработка Shop-Script и интеграций с маркетплейсами

Карточки Wildberries: размеры, характеристики и связи с магазином

Размеры в одной карточке вместо отдельных товаров

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

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

Обновление только выбранных характеристик и описания

Добавили выборочную передачу данных: только описание, только одну или несколько характеристик либо выбранные характеристики вместе с описанием. Первую проверку выполняли на ТТД, затем доработку переносили на ОС.

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

Фотографии отдельно от остальных данных карточки

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

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

Дробные значения, категории и справочники

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

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

В журнале также есть отдельная проверка исчезнувших характеристик категории «Ювелирные броши». На двух сайтах разработчик смог открыть сопоставление; окончательное подтверждение заказчиком по этому обращению отдельно не записано.

Вес с упаковкой из нужной характеристики

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

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

Разрешительные документы и признак маркировки КИЗ

В настройки категории WB на ОС и ТТД добавили два поля: «Разрешительные документы» — excludeDocuments и «Маркировка КИЗ» — kizMarked. Для каждого предусмотрен выбор «Да», «Нет» или незаданного значения «-».

Выбранные значения передаются при создании и обновлении карточек соответствующей категории. Если оставлено «-», параметр не отправляется. В ответе по выполненной работе отдельно отмечено сохранение уже загруженных разрешительных документов при обновлении. Эти поля передают настройки карточки; отправка конкретных УИН и КИЗ в заказах реализовывалась отдельно.

Связанные товары, ссылки и артикул WB

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

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

Значение nmID автоматизировали для переноса в характеристику «Артикул WB». Сначала заполнение относилось к новым карточкам, затем добавили обработку ранее связанных товаров через cron. Значение записывается в характеристику товара: его не следует путать с отдельными техническими идентификаторами размеров.

Отдельным незавершённым обращением осталось удаление ссылок конкурентов вместе с удалением связей WB. Требование — не терять независимые конкурентные ссылки при такой операции.

Объединение карточек по общей характеристике

Для ОС и ТТД запросили автоматизацию объединения товаров на Wildberries по одинаковому значению специально заведённой характеристики. В истории работ зафиксированы загрузка уже существующих групп с их imtId и настройка cron для формирования новых групп на ОС.

Это отдельный уровень группировки карточек, а не замена первоначальной задачи с несколькими размерами одного товара. Подтверждение переноса всей автоматизации групп на ТТД отдельно в документе не приведено.

Синхронизация остатков: свои склады, поставщики и размеры

Склад «В наличии» и остатки поставщиков

Для ТТД использовались склады «В наличии», «Склад», «Салон» и отдельный «Склад WB». На ОС им соответствовали собственный склад «РЦ ОС», «Склад ОС», «Салон ОС» и «Склад WB». Собственные товары требовалось отличать от доступных у поставщиков.

Базовая задача состояла в защите от продажи небольшого остатка поставщика, который мог уже уйти по другому каналу. В настройках задавался порог для суммы складов поставщиков: ниже порога на Wildberries передаётся только собственный остаток; при достаточной сумме — собственный склад вместе со складами поставщиков. Если собственного остатка нет и сумма ниже порога, передаётся ноль.

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

Списки исключений и разные режимы для размерных товаров

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

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

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

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

Порог остатков должен работать и в исключениях

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

В последней группе таких исправлений восстановили настройку «Передавать остаток склада “В наличии”, если остаток складов “Склад” + “Салон” меньше определённого значения» на обоих сайтах. В интерфейс выбора списков добавили поиск по вводимому названию и отдельную функцию обнуления остатков по выбранному списку.

Одинаковые правила при ручном обновлении и по cron

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

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

Переход на chrtId и исправление переполнения идентификатора

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

Позднее на ОС новые карточки стали возвращать ошибку NotFound, хотя задание загрузки идентификаторов работало. Причиной оказалось поле базы, рассчитанное на числа не больше 2147483647: более крупные chrtId сохранялись неверно. Поле расширили на обоих сайтах, а для 75 затронутых товаров ОС заново получили корректные идентификаторы. В этом обращении выгрузка остатков ТТД до исправления работала.

Остатки на Wildberries как отдельный источник информации

Для «Ценообразования WB» добавили загрузку данных склада Wildberries в скрытый склад магазина «Склад WB». В таблице появилась колонка «Остатки WB» и фильтрация товаров с таким наличием.

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

Гибкие остатки Ozon и ограничение по закупочной цене

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

Отдельно исправили обнуление бижутерии из-за настройки «Не выгружать товары с ценой ниже». Из-за неё товары дешевле установленного порога получали нулевое количество при обновлении. Проблему проверяли в приложении Ozon, а не считали доказанным побочным действием списка исключений Wildberries.

Расширение пороговой логики на «Ozon: Интеграция» и «Яндекс.Маркет PRO» присутствовало в пожеланиях. Завершение всей первоначально запрошенной реализации для каждого из этих модулей не подтверждено одной общей отметкой.

Списание через «Склады PRO» и остатки в заказе

Доработали использование «Умного выбора склада» для заказов Wildberries, Ozon и AliExpress: списание должно происходить с учётом наличия на главном складе, как в уже работавших сценариях сайта и Яндекс Маркета.

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

Обмен товарами между 1ttd.ru и «Островом Сокровищ»

Связи по артикулу и выбор данных для переноса

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

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

Синхронизация собственного склада после заказа

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

После проверки исправили отсутствие списания между сайтами. В ответе по выполнению уточнён момент срабатывания — перевод заказа в состояние «Заказ подтверждён и принят в обработку». Это не заявлялось как синхронизация сразу после любого несохранённого действия менеджера.

Также доработали подсветку собственного наличия в «Принтере» и в самом заказе: восстановили согласованные жёлтые и зелёные отметки на ТТД и ОС.

Перенос ссылок конкурентов без включения собственного магазина

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

Позднее при переносе ссылок с ОС на ТТД исключали собственную карточку Wildberries магазина-получателя, чтобы она не становилась его конкурентом. Рабочие версии «Ценообразования» также переносились между сайтами отдельными этапами после проверки.

Цены и скидки Wildberries: от наценок до распродажи размеров

«Мультицены» как источник цены для WB API

Поставили задачу связать WB API с плагином «Мультицены»: выбирать оптовую цену, цену распродажи и новые виды цен, которые магазин создаёт позднее. В развитие этого сценария обсуждался выбор источника по складу: при наличии на собственном складе передавать цену распродажи, иначе — розничную.

В «Мультиценах» доработали показ рассчитанной суммы при процентной наценке. Отдельно рассматривались правила расчёта, подобные плагину «Управление товарами», и передача такого результата как «Цены распродажи». Финальная приёмка всех вариантов условного выбора источника по складам в исходнике не выделена.

Градации наценки и индивидуальная цена каждого размера

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

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

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

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

В WB API добавили настройку «Обнуление скидки у проданных товаров РЦ ОС и FBO WB»: выбор списка и процента, который нужно передать в поле «Скидка продавца» после выполнения складского условия. Название «обнуление» не означало обязательные 0% — заказчик мог задать, например, 5%.

Для ТТД первоначально запрашивался отдельный вариант только по складу WB; эту доработку перенесли на нужный сайт и убрали с ОС. Позже на ТТД переносили расширенную логику с собственным складом «В наличии». Список для изменения скидки и дополнительный список для обнуления остальных остатков выполняли разные задачи.

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

Продажи со склада WB и проверка через cron

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

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

Размерные товары: восстановление цены по градации

Для размерных изделий понадобился другой механизм: скидка на площадке применялась ко всему товару, а распродавать нужно было отдельные размеры. Поэтому после продажи соответствующего размера требовалось вернуть его «Цену продавца до скидки» по градации WB API, не менять остальные размеры и сохранить отдельное поведение безразмерных товаров.

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

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

Плагин «Ценообразование WB»: конкуренты, минимальная цена и фильтры

Сравнение конечных цен с учётом скидок

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

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

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

Первоначальную схему корректировали после тестирования: для безразмерных товаров перешли к изменению «Скидки продавца», а для размерных — к изменению «Цены до скидки». Позднее добавили возможность выбрать конкретный размер для обновления вместо изменения всех вариантов товара.

Минимальная допустимая цена и исключения для FBO

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

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

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

Шаг изменения в рублях и процентах

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

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

Маржа и прогноз при переходе к цене конкурента

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

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

Фильтры и сортировка для работы с большим ассортиментом

В плагин поэтапно добавили инструменты отбора и контроля:

• Отбор товаров с небольшой наценкой, в первоначальном запросе — ниже 40% от закупочной цены, и сортировку по уровню наценки в колонке «Наша цена».
• Фильтры по виду изделия, виду металла и конкуренту; поиск по артикулу Wildberries — nmID.
• Сортировки по скидке, марже, марже конкурента, минимальной цене конкурентов, последней цене и времени последней проверки.
• Показ остатков WB и собственного склада; для ТТД отдельно запросили колонку «В наличии».
• Исключение из выборки товаров с остатками на собственном складе и WB, в том числе совместно с другими фильтрами.
• Восстановление перехода между страницами, сброса строки поиска и фильтров после изменений плагина.

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

Отдельное повышение цены и управляемая разница

Добавили самостоятельное cron-задание для повышения цен по «синему» отбору. В настройках появилась процентная разница между своей ценой и ценой конкурента, начиная с которой разрешено такое обновление: например, порог 20% задавался самим магазином.

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

Выбор товаров, массовые операции и Excel

Раздел «Товары» переименовали в «Поставщики». Добавили экспорт результатов в Excel с сохранением состава колонок и применённых фильтров. Для работы со списками дорабатывали выделение диапазона через Shift, массовые чекбоксы и выбор конкретных размеров.

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

Ссылки конкурентов, «Индекс цен» и устойчивость проверок

Ручные ссылки и импорт конкурентного окружения

В карточки добавлялись поля для нескольких ссылок на конкурентов Wildberries, а позднее — отдельное поле «Ссылка на товары конкурентов WB (ручная)». Данные включили в стандартный импорт и экспорт Shop-Script и в работу плагина ценообразования.

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

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

Количество найденных конкурентов и действующие предложения

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

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

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

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

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

Автоматический поиск ссылок Wildberries

Для ОС настроили сбор конкурентных ссылок по расписанию с выводом прогресса и журналом обработки. В тестовом запуске обрабатывались партии по 500 товаров; промежуточный отчёт содержал количество проверенных карточек, карточек без конкурентов и найденных предложений. Такой отчёт описывает ход конкретного запуска, а не гарантированный результат для всего каталога.

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

Самостоятельный раздел «Индекс цен»

На ОС и ТТД добавили поле «Ссылка на товар конкурента (Индекс цен)» и раздел «Индекс цен» по образцу «Поставщиков». Ссылки для него вводились вручную или через стандартный импорт и экспорт.

В новый раздел перенесли сортировку по марже, марже конкурента, минимальной цене и последней цене, фильтр конкурентов, очистку поиска, Excel-экспорт и выделение диапазона через Shift. Для него сделали собственный список «Исключить конкурентов Индекс цен», не смешанный с поставщиками.

Дополнительная настройка скрывает из «Поставщиков» товары, уже включённые в «Индекс цен». Добавление ссылок Ozon в этот раздел обсуждалось, но заказчик прямо отложил его: соответствующий функционал не включали в выполненный объём.

Cron без наложения запусков

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

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

Изменения источника цен, токены и внешние ограничения

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

Отдельно разбирали просроченные токены Wildberries и ответы 429 на ТТД. После замены базового токена на персональный заказчик сообщил об успешной проверке одного товара и продолжил тестирование. Это не подтверждает отсутствие ограничений по всем операциям аккаунта.

Последнее обращение по остановке обновления цен связывалось с проверкой аккаунта у прокси-провайдера. В документе ожидался его ответ; окончательное восстановление после этой проверки не зафиксировано. Этот случай отделён от ранее исправленного наложения cron.

Ценообразование Ozon и участие в акциях

Отдельный плагин под предложения Ozon

По аналогии с WB разработали отдельное «Ценообразование Ozon». В задании требовалось сравнивать конечные цены с учётом скидок, изменять собственную цену, не опускаться ниже минимального значения и обрабатывать выбранный список товаров.

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

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

Сбор предложений через расширение браузера

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

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

Подбор подходящей акции

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

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

Плагин «Принтер»: обработка заказов на одной странице

Рабочая таблица вместо переходов в каждый заказ

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

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

Колонки, выделение и закреплённые элементы

Убрали колонки «Удалить с прихода» и «На складе», переименовали «Подтверждение наличия» в «Есть/Нет». Размер заказанного изделия вынесли в отдельную колонку сразу после наименования.

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

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

Заявки поставщикам и состав письма

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

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

Контроль печати и ответственного сотрудника

В массовой форме WB API добавили колонку «Распечатано» с отбором «Да/Нет». Значение менялось после выбора заказов для печати, чтобы при следующем открытии формы можно было найти ещё не подготовленные этикетки.

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

Шаблоны этикеток Wildberries

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

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

УИН, КИЗ и «Честный знак» в сборке заказов

Сканирование кода прямо в заказе

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

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

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

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

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

Раздельная передача заказа и кодов на Wildberries

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

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

Следующий этап разделил действия ещё явнее: сначала добавить заказы в поставку и сохранить соответствие УИН заказам, затем передать накопленные коды массово или по отдельному изделию. В задаче указана первоначальная проверка на ОС с последующим переносом; дальнейшие обращения охватывают уже оба сайта.

Повторная запись УИН после подготовки спецификаций

Для маркируемых заказов на ОС и ТТД добавили отдельную возможность «Перезаписать УИН». Она потребовалась, когда заказ сначала попадал в поставку, а данные по изделию оформлялись позднее, после чего Wildberries возвращал сообщение об отсутствии УИН в ГИИС ДМДК.

Доработка даёт повторную отправку из заказа и не заменяет оформление сведений об изделии в соответствующей системе учёта.

КИЗ для парфюмерии и правильные названия действий

С добавлением духов и одеколонов запросили передачу КИЗ из того же поля «Честный знак». Для типа «Парфюмерия» требовалось переименовать действие с «Передать УИН» на «Передать КИЗ», включая интерфейс «Принтера».

Исправляли отсутствие кодов у поставщиков, кроме «Красной Пресни», и появление нового поставщика «Новая Заря» в рабочем интерфейсе. По КИЗ отдельно проверяли как сообщение об успешной отправке, так и фактическое наличие значения на Wildberries. После выполненных исправлений оставалась дополнительная проверка повторной отправки отсканированной строки; её завершение отдельно не отмечено.

Заказы и поставки Wildberries: статусы, печать и восстановление обмена

Отмена заказа и защита от повторной загрузки

Исправили смену состояния заказа в магазине после быстрой отмены покупателем на Wildberries: при настроенном сопоставлении заказ должен переходить в «Удалён». Отдельно устраняли массовое дублирование заказов на ОС и ТТД.

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

Большие поставки и печать всех страниц

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

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

Массовая сборка и ошибка 504

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

Для этого обращения рекомендовали меньшие партии — примерно по 5–7 заказов вместо 15–20. Полноценная новая фоновая очередь по данному пункту не зафиксирована, поэтому она не представлена как реализованное решение.

Обращения, требующие дополнительной проверки

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

Интеграция Ozon: сборка, несколько магазинов и этикетки

FBS и rFBS в рабочем интерфейсе магазина

Доработали приложение «Интеграция с Ozon» для работы с «Принтером». Для заказов Ozon добавили действие «Собрать в поставку OZON», передачу в состояние ожидания отгрузки и отправку УИН для ювелирных изделий. Для товаров без обязательной маркировки УИН не требовался.

В исходном задании магазин работал по FBS и rFBS. На ТТД перенесли согласованный функционал с учётом того, что на этом этапе там требовалось оставить интеграцию только с одним приложением Ozon. На ОС одновременно использовались приложение и отдельный плагин «Ozon: Интеграция».

Несколько товаров и несколько единиц в одном заказе

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

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

Разные аккаунты Ozon без смешивания данных

На ОС один товар мог продаваться в трёх магазинах Ozon, подключённых разными модулями. Для них разделили получение данных, штрихкоды, этикетки, добавление в отгрузку и учёт в отчётах. При печати требовалось брать штрихкод именно того магазина, в котором оформлен заказ.

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

Передача УИН до завершения сборки

После изменения обработки Ozon возникали ошибки дополнительной информации: код передавался, но этикетка не появлялась и отправление не переходило в ожидаемое состояние. Дорабатывали последовательность — отправить УИН, дождаться применения, проверить состояние и затем завершать сборку.

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

Восстановление после обновлений приложения

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

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

Ozon SKU и ссылки для каждого размера

Сделали автоматическое получение SKU OZON в характеристику товара или соответствующего размера и сохранение ссылки на карточку площадки. Для размерного товара требовалась своя ссылка у каждого размера, для безразмерного — одна. Эти поля переносили в «Основные данные», раздел «Ещё».

Для загрузки работало отдельное cron-задание; в сопровождение вошли его восстановление и перенос на ТТД. Дополнительно для ОС предоставили способ получить ссылку Ozon в шаблоне товара — по выбранному артикулу либо по первому найденному. Саму кнопку перехода на витрине собирался оформлять администратор заказчика; эта работа не приписана Quadro Design.

Генерация штрихкодов и товарных наклеек

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

Из цифрового значения формировалось изображение штрихкода для собственной товарной наклейки. На раннем этапе обсуждался CODE-128, позднее отдельно корректировали размещение EAN-13. В макете размером 40 × 60 мм дорабатывали шрифт и расположение элементов, в том числе при нескольких товарах в заказе.

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

Яндекс Маркет: заказы, штрихкоды и отгрузки в связанных доработках

Подключение сборки к «Принтеру»

Для ОС сделали сценарий работы с Яндекс Маркетом по аналогии с WB и Ozon: подготовка заказа к отгрузке и печать ярлыка доступны из самого заказа и из «Принтера». Добавили действие «Готов к отгрузке ЯМ».

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

Этикетка для термопринтера и отчёт отгрузок

Изменили формат этикетки с 72 × 120 на 58 × 40 мм. После пробной печати дополнительно уменьшали элементы; заказчик подтвердил подходящий размер.

Создали сводный раздел отгрузок Яндекс Маркета. В него не должны попадать отменённые заказы — только фактически отправленные. Этот раздел относится к работам ОС, а не автоматически к ТТД.

Обновления API, автоматическое создание заказов и время

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

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

Штрихкоды ЯМ и ссылки по артикулам

Для ОС доработали получение штрихкодов Яндекс Маркета и перенос в характеристику «Штрихкод ЯМ». В отчёте по выполнению указано заполнение найденных товаров и ежедневное задание для новых.

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

Ежедневные отгрузки и отчёт по ювелирным изделиям

Ozon: фактические отгрузки по дням

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

Восстанавливали пустой раздел «Ozon отгрузки» на ТТД и ОС. В одном случае причина была в обращении к данным уже удалённого Ozon-плагина. Для ОС дополнительно включили отгрузки ещё одного подключённого магазина.

Отдельный отчёт по отправленным ЮИ

Сделали раздел «Отчёт по отправленным ЮИ» с ежедневными данными о ювелирных изделиях для WB и Ozon. В исходном задании предусмотрены отдельные группы по дню и площадке, раскрытие списка изделий, скачивание таблицы и сохранение истории на сайте без автоматического исчезновения через заданный срок.

В состав данных вошли дата операции, УИН, наименование изделия, размер и покупатель из заказа. Позднее добавили цену продажи и итоговую сумму. На ТТД отдельно исправляли отсутствие УИН Wildberries при корректном отображении Ozon.

Информация ещё до отправки всей партии

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

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

Время добавления кода вместо старых красных строк

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

Старые коды, для которых время добавления неизвестно, из такого отбора исключили. Это не восстановление недостающих дат задним числом. Доработку перенесли на ТТД; отдельно из ювелирного отчёта убрали товары с КИЗ.

Итоги с НДС по настройке заказчика

Строку «Итого» переименовали в «Итого с НДС» и добавили отдельную строку НДС с расчётом сумма × 22 / 122. Здесь описана конкретная формула отчёта из технического задания, а не выбор налогового режима для других магазинов.

Расчёт прибыли и расходов по заказам маркетплейсов

«Расходы WB»: цена продажи, скидки и закупка

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

В таблице собрали цену продавца до скидки, скидку продавца, цену после неё, цену с WB Клубом, рассчитанную скидку WB и фактическую цену заказа с учётом скидок. Дополнительно выводились минимально рекомендуемая цена, показатель, первоначально названный «Минимальная прибыль», и полученная прибыль в рублях и процентах. Названия и пояснения к расчётным строкам затем уточнялись.

Настройки включали процент для минимальной цены по типу товара и общий процент расходов WB. Подписи уточнили: «Фактическая цена в заказе с учётом всех скидок», комментарий с используемым процентом по типу изделия и пояснение к скидке WB Клуба. В одной из настроенных формул в подписи отдельно зафиксировали деление на 0,6; это параметр согласованного расчёта, не универсальная комиссия площадки.

Цена купленного размера и скидка на момент заказа

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

Отдельно исправили последовательность с автоматическим возвратом скидки: в расчёт заказа должна попадать скидка продажи, а не новый процент, который WB API уже установил после распродажи. Иначе выполненный заказ пересчитывался бы по будущей цене товара.

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

Ozon: операции и комиссии без ручного открытия заказа

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

В общей таблице расширили колонку прибыли на WB и Ozon. Исправили отсутствие результата у второго товара в многотоварном Ozon-заказе на ТТД и автоматический вывод после массового подтверждения. Согласованную версию плагина с доработками перенесли с ОС на ТТД.

Отдельный плагин расходов Яндекс Маркета

Для ОС создали расчёт расходов Яндекс Маркета. В настройки вошли средняя миля в рублях, доставка до покупателя в процентах, перевод платежа в процентах, приём платежа фиксированной суммой, размещение по типу товара и виду изделия, прочие расходы в рублях.

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

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

«Заказы маркетплейсов»: сводная прибыль, расходы и план

Общая таблица заказов и фильтры периода

Разработали плагин «Заказы маркетплейсов» для объединённого просмотра продаж. Для ОС учитывались Wildberries, несколько магазинов Ozon, Яндекс Маркет и заказы собственной витрины. Период можно было выбирать как день, неделю, месяц, полгода, год или произвольный диапазон, а площадку — отдельным фильтром.

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

Общие расходы и фактический процент прибыли

Термины «Маржа», «Общая маржа», «Фактический % маржи» и «Средний % маржи» заменили на соответствующие обозначения прибыли. В основную таблицу и сводный блок добавили общие расходы и их процент.

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

Состав статусов и только фактически отгруженные заказы

Добавили настройки состава статусов по каждой площадке и отдельный режим фактических отгрузок. Для него заказчик определил состояния Wildberries, Ozon и Яндекс Маркета, а для собственного сайта — «Отправлен» и выбранные статусы Почты России, СДЭК и DPD.

В согласованный перечень собственного магазина входили «ПОЧТА РФ — Отправляем — ОФИС», «ПОЧТА РФ — Отправлено», «СДЕК — Отправляем — ОФИС», «СДЕК — Доставка», «DPD — Отправляем — ОФИС», «DPD Доставка курьер» и «DPD Доставка самовывоз». При включённом режиме сводные значения должны считаться по выбранным состояниям, а не по всем созданным заказам.

План прибыли по месяцам и доле периода

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

В иллюстрации технического задания месячный план 300 условных рублей для месяца из 30 дней давал 10 за день и 70 за неделю. Это пример алгоритма, не данные бизнеса. Позднее в настройки добавили выбор нового планового года — 2026.

Старые заказы и время формирования отчёта

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

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

Поставщики и SOKOLOV: загрузка товаров, характеристик и остатков

Из API SOKOLOV в YML для существующего импорта

Для работы с SOKOLOV сначала обсуждался новый прямой импорт с повторением возможностей «Поставщиков». Затем согласовали другой вариант: отдельный плагин получает данные оптового каталога через API, формирует YML-файл и отдаёт ссылку для загрузки штатным процессом магазина.

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

Плагин первоначально использовался на ТТД; далее в истории есть его перенос на ОС и доработки получаемого фида.

Название, вставки и состав данных поставщика

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

Повторяющиеся значения объединили в две характеристики — «Вставка» и «Характеристика вставки». Внутри них согласовали разделение запятыми, сохраняя количество, вид, цвет и параметры отдельных вставок. Эта доработка подтверждена проверкой заказчика.

Для первоначального фида отдельно задавался состав исключаемых служебных данных: video, video-on-model, prices-category, min-trade-price, whom-production, base-line-products, trade-price-without-sale и order-problem-tooltip. Из коллекций требовалось оставлять название без служебных ссылок и блоков. Это требования ранней версии фида; позднейшая загрузка товарных видео стала отдельной доработкой.

Ограничения данных SOKOLOV

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

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

Отдельный запрос на выбор производителя SOKOLOV или Diamant в поле vendor заказчик отменил. Его не включали в выполненный объём.

Размеры и новинки в плагине «Поставщики»

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

На ТТД восстанавливали импорт по профилю «Красная Пресня — Серебро»: новые позиции фида появлялись, а часть давно присутствующих товаров не загружалась. Отдельно доработали автоматическое добавление новинок, поскольку ручная кнопка заказчика не устраивала.

После обновления Shop-Script вновь исправляли прекращение импорта новинок серебра и бижутерии «Красной Пресни» на двух сайтах: журнал показывал начало процесса, но дальнейшие действия не выполнялись.

Исключения при обновлении и раздельные расписания

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

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

Отдельно зафиксировано обращение о невозможности изменить или удалить сопоставления picture в «Настройке оффера» на ОС и ТТД. Подтверждение исправления этого редактора сопоставлений отсутствует.

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

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

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

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

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

Рамка с сохранением исходной фотографии

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

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

Характеристики непосредственно на изображении

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

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

Гарнитуры из двух, трёх и четырёх изделий

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

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

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

Артикулы WB и Ozon на коллаже

У гарнитуров Wildberries требовалось использовать артикул площадки вместо заводского. Для Ozon позднее уточнили источник: не внутренний ID товара, а SKU OZON; у размерного изделия в данном макете допускался SKU одного из размеров.

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

Основное изображение, битые миниатюры и повторные проверки

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

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

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

Фото и видео для Wildberries, Ozon и Яндекс Маркета

Наборы изображений для разных площадок

Настроили передачу изображений из нужных групп в WB API, приложение и плагин интеграции Ozon, а для ОС — также в «Яндекс.Маркет PRO». Товар мог иметь общие фото и отдельные гарнитуры или информационные изображения для каждой площадки.

В ходе проекта блоки несколько раз уточнялись. После разделения «Информации» появились отдельные «Магазин WB», «Магазин Ozon» и «Магазин ЯМ», а общий блок «Информация» сохранили перед ними. Изображения одной площадки не должны были автоматически уходить в рекламный блок другой.

Согласованная последовательность фотографий

В поздней редакции задания закреплена последовательность:

• Wildberries: «Заводское фото и видео» → «Фото с характеристиками» → «Наши фотографии» → «Гарнитуры WB» → «Размер кольца» → «Подарочная упаковка» → «Информация» → «Магазин WB» → «Сертификаты».
• Ozon: тот же порядок общих групп, но с «Гарнитурами Ozon» и «Магазином Ozon»; на ОС его согласовали для двух разных интеграционных модулей.
• Яндекс Маркет на ОС: общий порядок с «Гарнитурами ЯМ» и «Магазином ЯМ» через YML-выгрузку.

Для «Яндекс.Маркет PRO» исправили неполное обновление картинок, когда выгружалось одно изображение или только несколько групп. Проверка затрагивала режим «Экспортировать каждый артикул товара как отдельную позицию», используемый для размерного ассортимента.

Массовое управление ссылками через CSV и Excel

В стандартный импорт и экспорт Shop-Script добавили ссылки на изображения из «Наших фотографий», с отдельной колонкой для каждого подраздела. Аналогично включили новые блоки «Информация» и «Магазин» для соответствующих площадок.

Исправили ошибочные заголовки array в экспортируемых колонках и восстановили выгрузку фотографий Ozon из нужных групп после обновлений. Массовое удаление сделали адресным: выбор блока «Информация» должен удалять изображения только из него, а не всю подборку «Наши фотографии».

Отдельными требованиями остались массовая подстановка одинаковых статичных изображений из приложения «Фото» сразу многим товарам, самостоятельное создание и перестановка вкладок и загрузка по cron на выбранный список. Для полного объёма этих пожеланий приёмка не указана.

Несколько видео и разный состав выгрузки

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

Для Ozon в задании требовалась выгрузка нескольких видео — до пяти в тогдашнем сценарии; для WB — только первого, верхнего ролика. Согласованную доработку выполняли и для ТТД. Это условия проекта, а не заявление о текущих лимитах каждой площадки.

Видео из фида поставщика без перезаписи ручных роликов

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

Отдельно доработали передачу видео по ссылке в WB API при создании и обновлении товара и импорт/экспорт видеоссылок стандартными средствами Shop-Script.

На момент отчёта по выполнению видео поступали в фидах «Красной Пресни». Фиды SOKOLOV в используемом Cloudparser тогда не открывались, а у Alikor ссылки были нерабочими. Эти внешние ограничения не означают, что все поставщики уже успешно передавали ролики.

Границы доработок закрытых модулей

Запрос на отдельную кнопку и cron для обновления только фотографий Ozon обсуждался независимо от готового аналогичного действия WB. Для одной из используемых интеграций разработчик сообщил об ограничении из-за закрытого кода. Реализация выборочного обновления только фото в этом модуле не подтверждена.

Шаблонные описания, характеристики и дополнительные требования

Несколько условных блоков в одном описании

Доработали «Описание товаров по шаблону» для использования нескольких последовательных конструкций %start% и %finish%. Заказчик хотел заключать в условный блок каждую характеристику: если значение отсутствует, соответствующая фраза не должна попадать в итоговый текст.

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

Обновление описаний по категории и расписанию

Шаблон задавался дополнительным параметром категории, например tmpl=earrings, и применялся при сохранении товара. Для ОС и ТТД добавили запуск массового обновления по кнопке и cron с отображением времени последнего выполнения.

Это автоматизация подстановки имеющихся характеристик, а не генерация новых неподтверждённых свойств товара.

Длинные значения характеристик

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

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

Товарный блок комплекта на витрине

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

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

Отложенные сценарии ценообразования

Часть пожеланий оставалась отложенной. Для WB запросили отдельную аналитику по образцу «Ценообразования Ozon», а также восстановление стандартной скидки при исчезновении конкурентов, с разными значениями для серебра и бижутерии.

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

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

Дополнительный экран синхронизации Ozon

Для ОС первоначально запрашивался отдельный раздел: выбор способа связывания товара с Ozon, количество синхронизированных позиций, описание ошибки, переход к связанному ассортименту и ручные запуски cron.

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

Сопровождение обновлений и сохранение индивидуальных доработок

Перенос изменений в новые версии интеграций

На протяжении проекта переносили индивидуальные изменения в новые версии WB API, включая переход на API 3.0 и поразмерные цены. Несколько этапов сначала выполнялись на ТТД с проверкой заказчиком, затем на ОС.

Отдельно обновляли Ozon с сохранением ранее изменённых настроек и получения цены из нужного раздела. После обновлений восстанавливали связанные кнопки «Принтера», экспорт изображений, фильтры и данные поставок. Это сопровождение нескольких взаимосвязанных модулей, а не однократная установка стандартных плагинов.

Ручные кнопки для автоматических заданий

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

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

Совместимость Shop-Script, PHP и сторонних плагинов

В задачи поддержки входили сбои после обновления Shop-Script, различия работы кнопок и cron после перехода на PHP 8 и сообщение Ozon-плагина о необходимости версии выше PHP 7.4 при заявленной установке PHP 8. Последнее обращение не содержит подтверждённой причины или окончательного исправления.

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

Новая ставка в настройках интеграций

Заказчик запросил значение 22% в настройках НДС «Экспорт в YML PRO», приложения и плагина Ozon. Для YML PRO прямое изменение настроек ограничивалось закрытым кодом, поэтому использовали новую версию плагина, где нужное значение уже было, и перенесли в неё доработки изображений.

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

Что объединяет выполненные доработки

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

Подтверждённые работы включают разработку «Принтера», «Ценообразования WB», обмена между магазинами и сводных отчётов, доработки интеграций Ozon, обработки УИН, галереи и видео. Отдельные решения первоначально создавались только для ОС или ТТД и переносились по согласованию. Повторные обращения, отложенные функции и ограничения сторонних модулей сохранены в соответствующих разделах, а не представлены как завершённые работы.

Нужна доработка интеграций вашего интернет-магазина?

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

Подробнее об услуге — программирование и доработка интернет-магазинов на Webasyst.