Настройка OneBox OS

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

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

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

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

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

Что касается чат-бота - возможно, неверно выразились, это просто группа в тг, в которую мы добавляем менеджера, и куда должно отправляться автоматическое сообщение. У нас на данный момент уже есть таких минимум 2 группы, куда отправляются ТТН с товарами, и другая, в которую поступают уведомления о том, что нужно проверить статус оплаты или заказа, это не что-то космическое. Настраивались они много лет назад за 15-30 минут. Это не требует много времени.

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

Ключевая ремарка - система работает, система довольно хорошо настроена и автоматизирована, это доработка функционала и автоматизаций, не настройка с 0 или добавление чего-то абсолютно нового.

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

Хаббер - дані вже передаються, тобто умова джерело - хаббер вже є, тут лише автоматично проставляти значення 2 полів, які вже існують. 

Коефіцієнти вже є, але потрібно зробити їх більш гнучкими, переробити формулу, щоб ми мали можливість самостійно визначати цінові діапазони і розмір коефіцієнта. 

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

Дані для формування звітів - усі поля наявні у самих замовленнях - і статус, і джерело, і позиції, і кількість, і ціна продажу і закупівлі, і місто, і спосіб оплати і доставки, і бренд. Все це є, просто ці поля потрібно згрупувати, підрахувати за певний період і видати у налаштовуваному звіті/звітах. 

Стосовно чат-боту - можливо, невірно висловились, це просто группа в тг, в яку ми додаємо менеджера, і куди має відправлятись автоматичне повідомлення. В нас наразі вже є таких мінімум 2 групи, куди відправляютсья ттн з товарами, та інший, в який надходять сповіщення про те, що потрібно перевірити статус оплати чи замовлення, це не щось космічне. Налаштовувались вони багато років тому за 15-30хв. Це не потребує багато часу. 

Стосовно оновлення стоку - потрібні 2 кнопки, одна - моментальне списання всього товару у картці товару, друга - моментальне оновлення стоку/ціни, якщо відбулись зміни, щоб прямо в цей момент система оновила дані в самій собі і передала ці дані по конкретному товару на усі майданчики через синхронізацію, яка працює). Також перевірити поточну автоматизацію по оновленню, якщо не сильно навнатажує систему, то зробити оновлення не раз на 4 години, як зараз, а кожні 2, наприклад. 

Ключова ремарка - система працює, система доволі добре налаштована і автоматизована, це допилювання функціоналу і автоматизацій, не налаштування з 0 чи додавання чогось абсолютно нового.

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

1. Аудит системы (преимущество, если вы свободно чувствуете себя в OneBox OS и вам не нужен время на ознакомление, вы сразу понимаете, где, что и как настроить).

2. Показать, где настраивается коэффициент цен для различных площадок, и сделать его таким, что можно клонировать и выставить разный для различных ценовых диапазонов товаров. Пример — для товаров стоимостью 0–999 — коэфф. 1,3; 1000–3000 — 1,25; 3001+ — 1,2 и т.д. Чтобы можно было создавать несколько таких коэффов и моментально пересчитывать цены в соответствии с ними нажатием кнопки «Обновить» на странице этих коэффов, чтобы синхрон сразу шёл на все площадки.

3. Настройка отчета/отчетов с экспортом в Excel.

4. Автоматическое выделение цветом в экселе ячеек роста/падения и формирование диаграмм для анализа данных таблиц отчета/отчетов

5. Автоматическое заполнение способа оплаты и доставки для заказов с хаббер (интеграция есть, просто автозаполнение двух полей). Если сможете еще настроить, чтобы правильно заполнялись поля адреса — топ, потому что на данный момент весь адрес заходит сплошным текстом по типу Нова Пошта. Адрес доставки: Винница, №1: Якова Шепеля, 1. Способ оплаты: Наложенный платеж, вместо того, чтобы зайти в правильные поля - город, отделение, способ оплаты и т.д.)

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

7. Кнопка списания всех доступных остатков со всех складов, включая возможное зарезервированное количество в карточке товара и в интерфейсе заказа.

8. Кнопка обновления товара в карточке товара, которая запускает сразу синхронизацию товара со всеми площадками, не дожидаясь синхрона каждые 4 часа (если возможно синхронизировать только конкретный товар - идеально, чтобы не запускать обновление сразу всех тысяч товаров)

9. Округление цен до 49 и 99 после применения коэффициентов из пункта 2.

10. Чек-бокс "Ручная цена", при выборе которого в карточке товара приоритет будет иметь именно ручная цена над всеми коэффициентами и правилами (бывают случаи, когда товар дефицитный и нужно быстро поднять цену на него, чтобы при этом правила автоматически не вернули эту цену назад. Соответственно, если выбран этот чек-бокс, пишем цену в отдельное поле и после нажатия кнопки "Сохранить" цена не изменяется правилами, пока не снят этот чек-бокс и не сохранены настройки карточки товара.

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

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

12. Переименование склада Алекс на ДРОП, приоритизация продаж товаров, которые имеются на складе ДРОП над складом Макс в случае, если в заказе все товары имеются на складе ДРОП. При этом решить вопрос одновременного наличия одного товара с одинаковым артикулом на обоих складах, чтобы не было на площадках двух позиций, а была объединенная (если объединение дорого - оставляем тогда оба товара, но цена должна устанавливаться определенная для склада Макс, игнорируя коэффициент цены для поставщика KSM. В основном это касается бренда Ugreen — на нашем складе их артикулы сугубо числовые, например, 12345, а у KSM UGR-12345, соответственно, таким товарам в поле Артикул должно записываться 12345.1 (то есть убирать "UGR-" и добавлять в конце ".1"), а UGR-12345 должно записываться в поле "Внешний ID". То есть, всем товарам бренда Ugreen при импорте данных товаров через ссылку на xml заполнение полей артикул и внешний ID должно происходить даже до того, как мы их выставим на продажу через процедуру добавления - в момент синхронизации).

Возможно, дальше будет )

Для прозорості та спрощення вибору партнера та взаємодії пропонуємо оцінити покроково наступні налаштування:

1. Аудит системи (перевага, якщо ви вільно почуваєте себе у OneBox OS і вам не потрібен час на ознайомлення, ви одразу розумієте, де, що і як налаштувати). 

2. Показати, де налаштовується коефіцієнт цін для різних майданчиків, та зробити його таким, що можна клонувати та виставити різний для різних цінових діапазонів товарів. Приклад — для товарів вартістю 0–999 — коеф. 1,3; 1000–3000 — 1,25; 3001+ — 1,2 тощо. Щоб можна було створювати кілька таких коефів і моментально перераховувати ціни відповідно до них натисканням кнопки «Оновити» на сторінці цих коефів, щоб синхрон одразу йшов на усі майданчики. 

3. Налаштування звіту/звітів з експортом в Excel. 

4. Автоматичне виділення кольором в ескель клітинок зростання/падіння і формування діаграм для аналізу даних таблиць звіту/звітів

5. Автоматичне заповнення способу оплати і доставки для замовлень з хаббер (інтеграція є, просто автозаповнення двох полів). Якщо зможете ще налашувати, щоб правильно заповнювалися поля адреси — топ, бо наразі вся адреса залітає суцільним текстом по типу Нова Пошта. Адреса доставки: Вінниця, №1: Якова Шепеля, 1. Спосіб оплати: Наложенный платеж, замість того, щоб зайти в правильні поля - місто, відділення, спосіб оплати, тощо)

6. Перехід на інший етап в інтерфейсі замовлення кліком по етапу в цьому замовленні або кнопкою з випадаючим списком статусів з можливістю прописати текст статусу, щоб не скроллити (рішення по реалізції буде вибиратись відповідно до оцінки 1 та другого варіанту переходу)

7. Кнопка списання усіх доступних залишків з усіх складів, включно із можливою зарезервованою кількістю у картці товару та в інтерфейсі замовлення. 

8. Кнопка оновлення товару в картці товару, яка запускає одразу синхронізацію товару з усіма майданчиками, не чекаючи синхрону кожні 4 години (якщо можливо синхронізувати лише конкретний товар - ідеально, щоб не запускати оновлення одразу всіх тисяч товарів) 

9. Округлення цін до 49 і 99 після застосування коефіцієнтів з пункту 2. 

10. Чек-бокс "Ручна ціна", при виборі якого в карті товару пріоритет матиме саме ручна ціна над усіма коефіцієнтами та правилами (бувають випадки, коли товар дефіцитний і потрібно швидко підняти ціну на нього, щоб при цьому правила автоматично не повернули цю ціну назад. Відповідно, якщо вибрано цей чек-бокс, пишемо ціну в окреме поле і після натискання кнопки "Зберегти" ціна не змінюється правилами, допоки не знято цей чек-бокс і збережено налаштування картки товару. 

Доналаштування інтеграції з файлом постачальника

11. Група в тг з передачею інформації про замовлення постачальнику , в якій зазначається наш номер замовлення, назва товару, наш артикул, зовнішній ID постачальника, ціна, кількість, сума, ТТН (якщо створено системою). В цій групі менеджер буде відписуватись, чи готові виконати замовлення. Наразі подібні 2 групи в боксі для тг створені, але для інших задач. Клонувати під дану задачу. 

12. Перейменування складу Алекс на ДРОП, пріоретизація продажів товарів, які наявні на складі ДРОП над складом Макс у разі, якщо в замовленні усі товари наявні на складі ДРОП. При цьому вирішити питання одночасної наявності одного товару з однаковим артикулом на обох складах, щоб не було на майданчиках дві позиції, а була об'єднана (якщо об'єднання дороге - лишаємо тоді обидва товари, але ціна має проставлятись визначена для складу Макс, ігноруючи коефіцієнт ціни для постачальника KSM. В основному це стосується бренду Ugreen — на нашому складі їхні артикули суто числові, наприклад, 12345, а у KSM UGR-12345, відповідно, таким товарам в поле Артикул має записуватися 12345.1 (тобто прибиратися "UGR-" та додаватися в кінці ".1"), а UGR-12345 має записуватися у поле "Зовнішній ID". Тобто, усім товарам бренду Ugreen при імпорті даних товарів через посилання на xml заповнення полів артикул та зовнішній ID має відбуватися навіть до того, як ми їх виставимо на продаж через процедуру додавання - в момент синхронізації). 

Можливо, далі буде )