1. Типові архітектури
2. динаміка обміну
3. висновки

Будь-який власник інтернет-магазину в процесі створення або в процесі експлуатації обов'язково зіткнеться з питанням обміну даними між магазином і бухгалтерськими програмами, сторонніми сайтами або веб-додатками, які для однаковості будемо називати «системою обліку». Оскільки всі питання обміну даними, будь сайт створений на Amiro.CMS або на будь-який інший системі управління, практично однакові, спробуємо розглянути їх в даному огляді, розділеному на 3 частини:

1. Визначення розв'язуваних бізнес-завдань. Розгляд типових архітектур рішення
   
2. Особливості реалізації обміну в Amiro.CMS
3. Налаштування експорту в Яндекс.Маркет
   

Перш за все, слід виділити бізнес-завдання по синхронізації між сайтом і системою обліку. Це актуалізація даних про:

1. товари (конентная складова: опису, зображення та інші властивості товару)
   
2. залишках товарів
   
3. цінах
   
4. статус замовлень
   
5. складі замовлень
   
6. покупців
   

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

Типові архітектури

На практиці реалізується архітектура рішення найчастіше залежить від «розміру» бізнесу:

1. від кількості товарних позицій
   
2. від кількості замовлень
   
3. від кількості сайтів
   
4. від числа адміністраторів системи (менеджерів, контент-менеджерів)
   
5. від прав доступу адміністраторів (якщо їх декілька)
   

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

1. Рішення «малий бізнес» (один сайт, один менеджер, середня відвідуваність). Система обліку використовується тільки для побудови звітності:
   • Товари редагуються на сайті
   • Покупці створюються на сайті
     
   • Склад замовлень змінюється на сайті
   • Статуси замовлень змінюються на сайті
   • Залишки враховуються на сайті
   • Обмін: товари, замовлення і залишки передаються з сайту в систему обліку

1. Рішення «середній бізнес» (один або кілька сайтів, один або кілька менеджерів, контент-менеджери, висока відвідуваність). Система обліку - для обліку замовлень та залишків:

   • Товари редагуються на сайті
   • Покупці створюються на сайті
   • Склад замовлень змінюється на сайті
   • Статуси замовлень змінюються в системі обліку
   • Залишки враховуються в системі обліку
   • Обмін: товари і замовлення передаються з сайту в систему обліку, статуси замовлень і залишки з системи обліку на сайт

1. Рішення «великий бізнес» (один або кілька сайтів, кілька менеджерів, контент-менеджери, дуже висока відвідуваність). Система обліку - для управління асортиментом, обліку замовлень та залишків:
   
   • Товарний асортимент редагується в системі обліку, тематична складова (опис, зображення і т.п.) ведеться на сайті
   • Покупці створюються на сайті
   • Склад замовлень змінюється в системі обліку
   • Статуси замовлень змінюються в системі обліку
   • Залишки враховуються в системі обліку
   • Обмін: товари, замовлення і залишки передаються з системи обліку на сайт; з сайту в систему обліку тільки первинний склад замовлення

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

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

динаміка обміну

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

Розглянемо приклад необхідних бізнес-процесів, і на їх основі заповнимо таблицю.

Завдання. Товари будуть створюватися шляхом імпорту з 2 сайтів постачальників. Доповнення інформації про товар буде вироблятися на сайті контент-менеджерами вручну. Користувачі реєструються на сайті і роблять замовлення. Менеджер, який відповідає за склад замовлення, телефонує клієнтом і на сайті змінює замовлення (додає / видаляє позиції, змінює кількість товарів, змінює адресу доставки і т.п.). Підтверджений менеджером замовлення отримує статус «перевірений» і вивантажується з систему обліку. На сайті залишки товару змінюються відповідно до вивантаженим замовленням. В системі обліку також відбувається резервування залишків товарів. Замовлення отримує статус «очікує оплати» якщо оплата, наприклад, йде безготівковим розрахунком. Після отримання оплати, менеджер в системі обліку виставляє статус «сплачено», і замовлення йде в службу комплектації і доставки, після чого відбувається списання залишків товарів. Далі статус замовлення змінюється в процесі доставки (відправлений, доставлений і т.п.). Всі зміни статусу замовлення відображаються на сайті, щоб їх міг відстежити користувач. Все актуалізовані залишки і ціни вивантажуються з системи обліку на сайт 1 раз на добу. Товари вивантажуються в Яндекс.Маркет.

Отримана архітектура зображена на малюнку:

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

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

висновки

1. Формулювання завдання обміну даними - це опис бізнес-процесів: хто і де виробляє зміна даних товарів, замовлень, залишків) і в який момент відбувається синхронізація. Саме точність постановки задачі обміну визначає зручність одержуваного рішення. Тільки власник бізнесу може визначити бажані бізнес-процеси.
2. Існують типові архітектури, залежні від кількісних характеристик (кількість товарів, замовлень, користувачів) і рівня поділу прав адміністраторів. Однак, не завжди типова архітектура зручна в конкретної бізнес-завдання, тому цілком допустимо використання і інших архітектур.
3. Фінальне рішення повинно враховувати і технічні особливості сайту, що накладає деякі обмеження на вихідні вимоги до бізнес-процесів.
4. Результатом даної роботи з побудови схем обміну буде Технічне Завдання з обміну даними.

Автор "Кут зору"

Студія «Кут зору» є провідним розробником нестандартного функціонала для Аміро.CMS. Фахівці студії ведуть блог про ефективне використання системи управління, який корисний не тільки власникам сайтів і інтернет-магазинів, а й технічним фахівцям, що створює сайти на Аміро.CMS - в блозі розкривається досвід створення сайтів і корисних функціональних рішень. Отримати інформацію про нові публікації можна підписавшись на розсилку в профілі автора.