OneBox OS setup

Clarification - this is not setting up the system from scratch. The system is already operational and works almost like a Swiss watch, with ready-made automations, fields, etc. We will, of course, provide information about what we know - where everything is located, where it is displayed - no problem.

Hubber - data is already being transmitted, meaning the source - hubber condition already exists, we just need to automatically set the values of 2 fields that already exist.

The coefficients already exist, but they need to be made more flexible, the formula needs to be reworked so that we can independently determine the price ranges and the size of the coefficient.

All stages of orders are stable and available, we just need to add functionality to the order interface itself, so that we don't have to go back to the orders page, select with a checkbox - edit - and choose another one, because sometimes we need to change something in an order that was placed some time ago and it's inconvenient to select a specific category of orders through filters, search for it on the page, highlight it, etc.

Data for report generation - all fields are available in the orders themselves - status, source, positions, quantity, selling and purchasing price, city, payment and delivery method, and brand. All of this is available, we just need to group these fields, calculate them over a certain period, and present them in a customizable report/reports.

Regarding the chatbot - perhaps we expressed ourselves incorrectly, it is simply a group in Telegram, to which we add a manager, and where an automatic message should be sent. Currently, we already have at least 2 such groups where shipping documents with goods are sent, and another one where notifications come in that the payment or order status needs to be checked, this is not something cosmic. They were set up many years ago in 15-30 minutes. It does not require much time.

Regarding stock updates - we need 2 buttons, one for instant deduction of all goods in the product card, the other for instant stock/price updates if changes occur, so that at that moment the system updates the data within itself and transmits this data for a specific product to all platforms through synchronization that is working. Also, check the current automation for updates, if it doesn't heavily load the system, then make updates not once every 4 hours, as it is now, but every 2, for example.

Key remark - the system is operational, the system is quite well configured and automated, this is fine-tuning of functionality and automations, not setting up from scratch or adding something completely new.

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

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

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

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

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

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

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

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

For transparency and simplification of partner selection and interaction, we suggest evaluating the following settings step by step:

1. System audit (an advantage if you feel comfortable in OneBox OS and do not need time to familiarize yourself; you immediately understand where, what, and how to configure).

2. Show where to set the price coefficient for different platforms, and make it cloneable and adjustable for different price ranges of products. Example — for products priced 0–999 — coeff. 1.3; 1000–3000 — 1.25; 3001+ — 1.2, etc. So that multiple such coefficients can be created and prices can be recalculated accordingly by pressing the "Update" button on the page of these coefficients, so that synchronization immediately goes to all platforms.

3. Configuration of report(s) with export to Excel.

4. Automatic color highlighting in Excel of cells with growth/fall and formation of charts for data analysis of report(s) tables.

5. Automatic filling of payment and delivery methods for orders from Hubber (integration exists, just auto-fill two fields). If you can also configure it so that the address fields are filled correctly — that would be great, because currently the entire address comes in as a solid text like Nova Poshta. Delivery address: Vinnytsia, №1: Yakova Shepelya, 1. Payment method: Cash on delivery, instead of entering the correct fields - city, department, payment method, etc.)

6. Transition to another stage in the order interface by clicking on the stage in this order or using a button with a dropdown list of statuses with the ability to write the status text, so as not to scroll (the implementation solution will be chosen according to the assessment of the first and second transition options).

7. A button to write off all available balances from all warehouses, including any reserved quantity in the product card and in the order interface.

8. A product update button in the product card that immediately triggers synchronization of the product with all platforms, without waiting for synchronization every 4 hours (if it is possible to synchronize only a specific product - ideal, so as not to trigger updates for all thousands of products at once).

9. Rounding prices to 49 and 99 after applying the coefficients from point 2.

10. A checkbox "Manual price", when selected, the manual price will take priority over all coefficients and rules in the product card (there are cases when a product is scarce and the price needs to be quickly raised without the rules automatically reverting this price back. Accordingly, if this checkbox is selected, we write the price in a separate field and after pressing the "Save" button, the price does not change according to the rules until this checkbox is unchecked and the product card settings are saved.

Final adjustments to the integration with the supplier file.

11. A Telegram group for transmitting order information to the supplier, which specifies our order number, product name, our article, external supplier ID, price, quantity, total, TTN (if created by the system). In this group, the manager will respond whether they are ready to fulfill the order. Currently, there are two similar groups in the box for Telegram created, but for other tasks. Clone for this task.

12. Renaming the Alex warehouse to DROP, prioritizing the sale of products available in the DROP warehouse over the Max warehouse if all products in the order are available in the DROP warehouse. At the same time, resolve the issue of simultaneous availability of one product with the same article in both warehouses, so that there are not two positions on the platforms, but a combined one (if combining is expensive - then we leave both products, but the price must be set as defined for the Max warehouse, ignoring the price coefficient for the supplier KSM. This mainly concerns the Ugreen brand — in our warehouse, their articles are purely numerical, for example, 12345, while in KSM UGR-12345, accordingly, such products in the Article field should be recorded as 12345.1 (i.e., removing "UGR-" and adding ".1" at the end), and UGR-12345 should be recorded in the "External ID" field. That is, for all Ugreen brand products, when importing product data via the XML link, the filling of the article and external ID fields should occur even before we list them for sale through the addition procedure - at the moment of synchronization).

Perhaps there will be more later )

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

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 має відбуватися навіть до того, як ми їх виставимо на продаж через процедуру додавання - в момент синхронізації). 

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