Перейти до вмісту

K2 Модуль Magento

Матеріал з K2 ERP Wiki

Синхронізація товарів дає можливість передавати асортимент із K2 ERP у Magento або отримувати товари з Magento в ERP. У K2 ERP це здатна бути пов’язано з:

Категорії та атрибути

У Inventory Management передбачено concepts sources, stocks і source items. # Товари резервуються на складі. # Номер фіскального чека зберігається в ERP.== Можливі помилки під час інтеграції ==

Для обліку: у більшості ERP-сценаріїв реальним складським товаром виступає як simple product, а configurable product виконує роль вітринної групи варіантів. Тому для залишків, резервів і відвантаження потрібно зберігати зв’язки між configurable і simple products.== Для чого потрібен K2 компонент Magento == Можливі сценарії синхронізації:

Для K2 ERP компонент Magento доцільно реалізовувати як окремий канал продажів із власними налаштуваннями API, типом цін, складами, правилами синхронізації, журналом обміну, обробкою помилок, підтримкою подій або регулярної синхронізації та зв’язком із доставкою, оплатами, поверненнями й фіскалізацією. # Magento повертає результат обробки. K2 компонент Magento автоматизує обмін даними. # K2 ERP отримує замовлення через API або подію. # платформа зіставляє товари за SKU або product ID. * K2 ERP виступає як головним джерелом цін;

  • для Magento застосовується для окремий тип цін;
  • ціни оновлюються за розкладом;
  • ціни оновлюються після зміни в ERP;
  • special price застосовується для для акцій;
  • ціни залежать від website;
  • ціни залежать від валюти;
  • ціни округлюються за правилами магазину;
  • частина товарів не оновлюється автоматизовано;
  • ціни груп клієнтів передаються окремо. У K2 ERP потрібно визначити правила зіставлення клієнтів:

інформаційні дані клієнта можуть включати: Для якісної інтеграції з Magento в K2 ERP бажано зберігати:

Simple product

K2 компонент Magento — це інтеграційний компонент для автоматизації обміну між K2 ERP та Magento / Adobe Commerce. Це створює ризики: застарілі залишки, неправильні ціни, дублікати замовлень, несвоєчасне оновлення версій статусів, помилки під час відвантаження та складність контролю фіскалізації. Типові типи товарів:

Magento має гнучку систему категорій та атрибутів.== Авторизація і доступ ==

Загальний SEO-опис

K2 компонент Magento потрібен для автоматизації обміну між ERP і Magento. # платформа створює замовлення клієнта. K2 ERP здатна створювати shipment у Magento або оновлювати shipment-дані після фактичного відвантаження. # платформа створює документ продажу.

Magento GraphQL API дає можливість ефективно для бізнесу отримувати інформаційні дані для storefront і зовнішніх застосунків. У журналі бажано зберігати: РРО

Оплати

Типова реалізація здатна включати:

Фіскалізація замовлень Magento

  • Magento order ID;
  • increment ID;
  • дата створення;
  • дата оновлення версій;
  • статус замовлення;
  • state;
  • покупець;
  • email;
  • телефон;
  • billing address;
  • shipping address;
  • список товарів;
  • order item ID;
  • product ID;
  • SKU;
  • кількість;
  • ціна;
  • знижки;
  • податки;
  • доставка;
  • загальна сума;
  • валюта;
  • payment method;
  • shipping method;
  • customer group;
  • coupon code;
  • comments;
  • invoices;
  • shipments;
  • credit memos за потреби. Він дає можливість синхронізувати товари, категорії, атрибути, ціни, залишки, отримувати замовлення, передавати shipment-статуси, tracking number і забезпечувати зв’язок онлайн-продажів із внутрішнім обліком компанії. Типовий сценарій експорту товарів із K2 ERP у Magento здатна виглядати так:

конкурентні переваги K2 Модуля Magento

  • website;
  • store;
  • store view;
  • мову;
  • валюту;
  • локалізовані назви;
  • локалізовані описи;
  • локалізовані SEO-поля;
  • різні ціни за website;
  • різні статуси публікації;
  • різні категорії за магазином. Для Adobe Commerce as a Cloud Service доступний інший набір endpoint-ів, а customer і guest REST API, доступні в on-premises / PaaS-версіях, у SaaS-версії не доступні в такому самому вигляді. # Покупець оформлює замовлення в Magento. # Shipment і tracking number передаються назад у Magento. Через те, що магазин обробляє замовлення, клієнтів і платежі, застарілі версії та вразливі модулі можуть створювати критичні ризики для бізнесу.

Magento Open Source і Adobe Commerce використовують спільну REST API-архітектуру для on-premises та cloud PaaS-розгортань, а так само мають GraphQL API для ефективного обміну даними між магазином і storefront.Інтеграція РРО в Python OpenCart

K2 компонент Magento здатна забезпечувати такі функції ERP: Під час впровадження модуля Magento потрібно враховувати:

  • доступ до access token;
  • права інтеграційного користувача;
  • права користувачів K2 ERP;
  • журнал дій;
  • обмеження доступу до налаштувань;
  • шифрування секретів;
  • захист логів;
  • резервне копіювання налаштувань;
  • оновлення версій Magento;
  • встановлення security patches;
  • блокування доступу звільнених працівників;
  • розмежування прав між менеджерами й адміністраторами;
  • контроль змін цін і залишків. Для інтеграції критично правильно зіставити їх із моделлю товарів K2 ERP.== Magento REST API ==
  • base URL магазину;
  • тип API;
  • access token;
  • Magento version;
  • website ID;
  • store ID;
  • store view ID;
  • Magento product ID;
  • SKU;
  • product type;
  • configurable parent ID;
  • simple child IDs;
  • source code;
  • stock ID;
  • статус синхронізації товару;
  • дату останнього оновлення версій товару;
  • Magento order ID;
  • increment ID;
  • дату замовлення;
  • order state;
  • order status;
  • Magento customer ID;
  • email покупця;
  • телефон покупця;
  • shipping address;
  • billing address;
  • shipping method;
  • payment method;
  • transaction ID;
  • invoice ID;
  • shipment ID;
  • tracking number;
  • credit memo ID;
  • статус фіскалізації;
  • номер фіскального чека;
  • текст помилки API;
  • журнал запитів і відповідей;
  • кількість спроб синхронізації. Якщо API тимчасово недоступне або замовлення не обробилося з першого разу, платформа повинна повторити операцію та не втрачати замовлення.== Store views, websites і мови ==
  • замовлення клієнта;
  • картка клієнта;
  • резерв товару;
  • задача на пакування;
  • документ оплати;
  • документ доставки;
  • фіскальний чек;
  • видаткова накладна;
  • документ повернення.== Безпека інтеграції ==
  • simple product;
  • configurable product;
  • grouped product;
  • bundle product;
  • virtual product;
  • downloadable product. * основна ціна Magento;
  • акційна ціна Magento;
  • валюта Magento;
  • website для ціни;
  • правило округлення;
  • правило оновлення версій;
  • дата останньої синхронізації. Можливі сценарії:

З Magento у K2 ERP можуть завантажуватися:

У K2 ERP потрібно визначити правила:

У системі K2 ERP компонент Magento здатна використовуватися як окремий канал продажів. Типові REST-напрями інтеграції:

  • дату і час запиту;
  • напрям обміну;
  • тип операції;
  • об’єкт обміну;
  • Magento ID;
  • ідентифікатор K2 ERP;
  • endpoint або GraphQL operation;
  • статус операції;
  • текст помилки;
  • технічну відповідь API;
  • користувача або сервіс, який запустив обмін;
  • кількість повторних спроб;
  • результат повторної обробки. Для безпечної роботи K2 Модуля Magento потрібно контролювати:

Не плутати: access token або admin token — це ключ доступу до магазину Magento. Окремо варто відзначити цінами, залишками, замовленнями, клієнтами, оплатами, доставкою, поверненнями, статусами і фіскалізацією виступає ключовою рисою обміну даними між K2 ERP та платформою електронної комерції Magento / Adobe Commerce. Adobe описує GraphQL API як інструмент для швидкого та ефективного передавання інформації між Commerce store і storefront.== Основні функції ERP == Модуль Prom Magento Inventory Management застосовується для для обліку запасів.== Доставка, shipment і tracking == Magento застосовується для як канал онлайн-продажів. Повернення в Magento можуть бути пов’язані з credit memo, поверненням товару, частковим поверненням коштів або скасуванням замовлення.B2C GraphQL API здатна використовуватися для:

  • конфігурація підключення до Magento;
  • зберігання base URL;
  • зберігання access token;
  • вибір API-режиму;
  • вибір store view;
  • вибір website;
  • вибір складів для залишків;
  • зіставлення Magento sources зі складами K2 ERP;
  • вибір типу цін для Magento;
  • зіставлення товарів за SKU або product ID;
  • зіставлення configurable і simple products;
  • зіставлення категорій;
  • зіставлення атрибутів;
  • експорт товарів;
  • оновлення версій цін;
  • оновлення версій залишків;
  • імпорт замовлень;
  • імпорт клієнтів;
  • створення документів замовлення клієнта;
  • резервування товарів;
  • передавання shipment-даних;
  • передавання tracking number;
  • інтеграцію з доставкою;
  • інтеграцію з оплатами;
  • фіскалізацію;
  • журнал технічного обміну;
  • обробку подій або періодичної синхронізації. # Замовлення надходить із Magento.== Отримання замовлень ==
  • access token недійсний;
  • недостатньо прав доступу;
  • магазин недоступний;
  • API-версія або endpoint не відповідає розгортанню;
  • перевищено ліміт або виникла технічна помилка API;
  • товар не знайдено;
  • дублюється SKU;
  • не зіставлено configurable product;
  • не знайдено simple product;
  • не зіставлена категорія;
  • не зіставлений attribute set;
  • не зіставлене значення атрибута;
  • не завантажується фото;
  • неправильна ціна;
  • неправильний залишок;
  • не зіставлений source або stock;
  • замовлення вже імпортоване;
  • товар із замовлення не знайдено в K2 ERP;
  • неправильний спосіб доставки;
  • неправильний спосіб оплати;
  • shipment не створено;
  • tracking number не передано;
  • помилка фіскалізації;
  • помилка повернення;
  • статус не оновився. Magento відповідає за онлайн-вітрину, каталог, кошик, оформлення замовлення та клієнтський досвід, а K2 ERP має бути центральною системою для товарів, залишків, цін, документів, складів, оплат, доставок і фіскалізації.

компонент K2 Magento здатна передавати назад у Magento:

  • залежність від API Magento;
  • різницю між Magento Open Source, Adobe Commerce PaaS і Adobe Commerce as a Cloud Service;
  • потребу в access token;
  • потребу в правильних правах доступу;
  • складність configurable products;
  • складність attribute sets;
  • різницю між складами ERP і Magento sources;
  • можливі помилки в SKU;
  • потребу в контролі залишків;
  • потребу в обробці дублювань;
  • потребу в тестуванні перед масовим експортом;
  • ризик оновлення версій неправильних цін;
  • ризик передавання неправильних залишків;
  • потребу в контролі персональних даних покупців;
  • потребу в оновленнях і security patches. Подія пришвидшує реакцію на зміну, а регулярна синхронізація користувачі можуть знайти пропущені або некоректно оброблені записи. Практичне сценарії використання: коли K2 ERP передає tracking number у Magento, покупець здатна бачити актуальну інформацію про відправлення, а менеджерам не потрібно вручну оновлювати замовлення в Magento Admin. Magento підтримує різні типи товарів.Tilda Commerce

Одна з ключових функцій модуля — отримання замовлень із Magento у K2 ERP. # Виконується фіскалізація через РРО або ПРРО. * назва товару;

  • SKU;
  • SEO-опис;
  • короткий SEO-опис;
  • ціна;
  • спеціальна ціна;
  • статус активності;
  • visibility;
  • tax class;
  • weight;
  • категорії;
  • атрибути;
  • images;
  • media gallery;
  • stock data;
  • configurable options;
  • related products;
  • upsell products;
  • cross-sell products;
  • SEO-поля;
  • custom attributes. В ERP бажано зберігати:
  • Magento customer ID;
  • ім’я;
  • прізвище;
  • email;
  • телефон;
  • адреси;
  • країну;
  • місто;
  • поштовий індекс;
  • customer group;
  • website;
  • store view;
  • дату створення;
  • дату останнього оновлення версій. Для інтеграції потрібно врахувати:

Magento REST API застосовується для для програмного доступу до даних магазину.Інтеграція з Prom, Rozetka, Hotline

Синхронізація товарів

Для інтеграції K2 ERP із Magento потрібно налаштувати доступ до API.

Типовий сценарій обробки замовлення Magento у K2 ERP здатна виглядати так:

Webhooks і події

  • менше ручного введення;
  • швидше оновлення версій товарів;
  • актуальні ціни;
  • актуальні залишки;
  • підтримку складних товарних структур;
  • підтримку категорій і атрибутів;
  • автоматичне отримання замовлень;
  • менше помилок менеджерів;
  • швидша обробка замовлень;
  • контроль оплат;
  • контроль shipment-статусів;
  • передавання tracking number;
  • зв’язок із фіскалізацією;
  • централізований обліковий облік у K2 ERP;
  • прозорий журнал інтеграції;
  • підтримку кількох каналів продажів. Adobe зазначає, що Inventory Management у Magento Open Source і Adobe Commerce замінює старі core API CatalogInventory та ScalableInventory і додає нові API для розширення функціональності. Не плутати: журнал обміну потрібен для діагностики, але він не має перетворюватися на сховище секретів або зайвих персональних даних покупців. Для багатоскладських сценаріїв критично правильно зіставити склади K2 ERP з Magento sources або stocks. це інтеграційний компонент; так само реалізовано категоріями. У стандартному Magento функції ERP подієвого обміну можуть залежати від версії, розширень або кастомної реалізації.

інформаційні дані, які не можна виводити в логах

Зверніть увагу: конкретні функції ERP модуля залежать від версії Magento або Adobe Commerce, доступних API, типу розгортання, прав інтеграційного користувача, структури товарів, складів, store views, способів доставки, оплат, податків, валюти та бізнес-логіки K2 ERP. # компонент Magento визначає, чи товар уже існує в Magento. Зверніть увагу: якщо Magento застосовується для для кількох мов або магазинів, у K2 ERP потрібно зберігати локалізовані назви, описи та правила публікації для кожного store view.

Magento здатна мати різні payment methods і статуси оплат. До основних переваг модуля можна віднести:

Повернення і credit memo

Синхронізація залишків

  • спосіб оплати;
  • payment method code;
  • payment title;
  • transaction ID;
  • суму замовлення;
  • суму оплати;
  • валюту;
  • комісію за потреби;
  • дату оплати;
  • invoice ID;
  • статус invoice;
  • статус повернення коштів;
  • зв’язок із касовим, банківським або платіжним документом. # За потреби виконується фіскалізація.== Синхронізація цін ==
Без інтеграції менеджерам доводиться вручну переносити товари, категорії, ціни, залишки, клієнтів і замовлення між Magento та ERP.
  • Magento product ID;
  • SKU;
  • назва;
  • тип товару;
  • ціна;
  • статус;
  • категорії;
  • атрибути;
  • залишок;
  • media;
  • store view values;
  • custom attributes.ЕДО
Не плутати: K2 компонент Magento — це не без зусиль імпорт замовлень.

Події можуть повідомляти K2 ERP про:

Типи товарів Magento

критично: K2 компонент Magento не замінює інтернет-магазин і не замінює ERP.== Висновок ==

Журнал обміну

  • підключення одного або кількох магазинів Magento;
  • конфігурація REST API або GraphQL API;
  • конфігурація інтеграційного користувача;
  • імпорт товарів із Magento;
  • експорт товарів у Magento;
  • оновлення версій товарних карток;
  • робота з configurable products;
  • робота з simple products;
  • робота з bundle, grouped або virtual products за потреби;
  • робота з категоріями;
  • робота з атрибутами;
  • синхронізація цін;
  • синхронізація залишків;
  • отримання нових замовлень;
  • отримання клієнтів;
  • отримання оплат і статусів;
  • створення shipment;
  • передавання tracking number;
  • обробка повернень;
  • зіставлення товарів за SKU або Magento ID;
  • зіставлення способів доставки;
  • зіставлення способів оплати;
  • журнал API-запитів;
  • повторна обробка помилок;
  • ручний і автоматичний режим синхронізації. У K2 ERP бажано мати окремі правила:

Для K2 ERP: Magento варто розглядати як зовнішній канал продажів. K2 ERP здатна виступати головним джерелом товарів, цін, залишків, складів, документів, оплат і фіскалізації, а Magento — зовнішнім каналом продажів і вітриною для покупців. # За потреби чек надсилається покупцю. # Статус фіскалізації зберігається у замовленні. Adobe Commerce REST API документація описує REST API для Adobe Commerce PaaS, Adobe Commerce on-premises і Magento Open Source. # K2 ERP перевіряє, чи замовлення вже не імпортоване. Це дає можливість одному Magento-інстансу обслуговувати кілька магазинів, мов або регіонів. Рекомендація: для K2 ERP базовий обмін адміністративними даними зазвичай зручніше будувати через REST API, а GraphQL використовувати там, де потрібно ефективно для бізнесу отримувати складні набори даних або підтримувати headless-сценарії. У модулі Magento бажано зберігати: Configurable product — це товар із варіантами, як приклад за розміром, кольором або іншими параметрами. Він об’єднує кілька simple products, кожен із яких має власний SKU. # Створюється ТТН або інший документ доставки. З K2 ERP у Magento можуть передаватися:

  • які атрибути ведуться в ERP;
  • які атрибути імпортуються з Magento;
  • які атрибути не синхронізуються;
  • як зіставляти довідники значень;
  • як оновлювати атрибути без втрати ручних даних у Magento;
  • хто виступає як головним джерелом атрибутів. Рекомендація: компонент Magento має мати механізм повторної обробки помилок. * отримання товарів;
  • отримання категорій;
  • отримання цін;
  • отримання атрибутів;
  • роботи з cart;
  • роботи з customer;
  • роботи з checkout;
  • отримання order-даних у підтримуваних сценаріях;
  • оптимізації кількості запитів;
  • побудови headless storefront. # Якщо товару немає, платформа створює нову картку товару. * access token;
  • admin token;
  • паролі;
  • приватні ключі;
  • повні інформаційні дані платіжних карток;
  • webhook secrets;
  • персональні інформаційні дані понад необхідний мінімум;
  • production connection strings;
  • внутрішні ключі API;
  • сертифікати;
  • конфіденційні фінансові інформаційні дані. * дерево категорій;
  • прив’язку товарів до категорій;
  • attribute sets;
  • product attributes;
  • значення атрибутів;
  • фільтраційні атрибути;
  • текстові характеристики;
  • числові характеристики;
  • select і multiselect-атрибути;
  • store view значення.== Типовий сценарій обробки замовлення ==

У K2 ERP на підставі замовлення Magento здатна створюватися:

ДПС

  • shipment data;
  • tracking number;
  • carrier code;
  • carrier title;
  • дату відправлення;
  • часткове відвантаження;
  • інформацію про відвантажені позиції;
  • коментарі до shipment. Практичне сценарії використання: K2 компонент Magento особливо корисний для магазинів із великим каталогом, складними атрибутами, кількома store views, частими змінами цін, багатоскладським обліком і регулярними онлайн-замовленнями. # Оновлюються залишки. # У разі повернення формується чек повернення.== інформаційні дані, які бажано зберігати в ERP ==
  1. користувач системи створює або оновлює товар у K2 ERP. Для B2C-продажів через Magento здатна бути потрібна фіскалізація через РРО або ПРРО залежно від країни, способу оплати, юридичної особи та законодавчих вимог. Повноцінна інтеграційні функції ERP має охоплювати товари, категорії, атрибути, configurable products, ціни, залишки, sources, замовлення, клієнтів, оплати, shipment, повернення, фіскалізацію та журнал помилок.== Використання модуля Magento у K2 ERP ==
  • періодичне опитування API;
  • Magento webhooks через розширення;
  • Adobe Commerce events або App Builder-сценарії;
  • власний компонент Magento для відправлення подій;
  • черги повідомлень;
  • інтеграційний middleware. K2 ERP має бути головною системою для товарів, залишків, цін, документів, оплат, доставок і фіскалізації, а Magento — онлайн-вітриною та джерелом замовлень. У складському обліку саме simple product часто відповідає реальному товару. У K2 ERP потрібно коректно зіставити оплату з документом продажу. * назву підключення;
  • base URL магазину;
  • тип API;
  • access token або інший спосіб авторизації;
  • права доступу;
  • store view;
  • website;
  • дату створення підключення;
  • статус підключення;
  • користувача, який налаштував інтеграцію;
  • дату останньої перевірки;
  • версію Magento;
  • журнал помилок авторизації. У магазині Magento покупець переглядає каталог, фільтрує товари, додає їх у кошик, оформлює замовлення, вибирає доставку, оплату та отримує підтвердження покупки. У Magento Open Source і Adobe Commerce on-premises / PaaS можуть використовуватися інтеграційні токени, admin token або OAuth-підходи залежно від конфігурації. Його не можна передавати стороннім особам, зберігати у відкритому коді, публікувати в логах або відправляти в незахищених повідомленнях. Через REST API можна працювати з товарами, категоріями, замовленнями, клієнтами, інвентарем, shipment, invoice, credit memo та іншими об’єктами.
  • залишок з одного складу K2 ERP передається в default source;
  • кілька складів K2 ERP зіставляються з кількома Magento sources;
  • у Magento передається доступний залишок з урахуванням резервів;
  • залишок оновлюється за розкладом;
  • залишок оновлюється після складського руху;
  • при нульовому залишку товар вимикається або змінює stock status;
  • залишок обмежується мінімальним або максимальним значенням для показу. Безпека: Magento і Adobe Commerce потрібно регулярно оновлювати та патчити. Журнал обміну потрібен для контролю інтеграції та швидкого пошуку помилок. У логах інтеграції не варто виводити:
  • за email;
  • за телефоном;
  • за Magento customer ID;
  • за комбінацією email і телефону;
  • створювати нового клієнта, якщо збігу немає;
  • не дублювати клієнта при повторному замовленні;
  • окремо опрацьовувати guest checkout.Інтеграція з Новою поштою в Python
  • як отримувати credit memo з Magento;
  • як створювати документ повернення;
  • як повертати товар на складський облік;
  • як опрацьовувати часткове повернення;
  • як опрацьовувати повернення доставки;
  • як оновлювати фінансовий статус;
  • як виконувати фіскалізацію повернення;
  • як зберігати зв’язок із початковим замовленням. * catalog products;
  • categories;
  • customers;
  • orders;
  • invoices;
  • shipments;
  • credit memos;
  • inventory;
  • source items;
  • stock;
  • payment information;
  • shipping information;
  • store configuration. Рекомендація: для Magento потрібно передавати не бухгалтерський залишок, а доступний до продажу залишок: фактична кількість мінус резерви, очікувані відвантаження та інші блокування. # платформа перевіряє SKU, назву, SEO-опис, ціну, фото, вагу, категорії та атрибути. Синхронізація цін потрібна для того, щоб у Magento відображалися актуальні ціни з K2 ERP. # Менеджер або платформа перевіряє оплату. # ERP перевіряє статус оплати.=== Configurable product ===

через Інтеграційний акцент: подієвий обмін бажано поєднувати з періодичною звіркою. # Для configurable products створюються або оновлюються пов’язані simple products. # Оновлюються ціни. # K2 ERP зберігає Magento product ID і зв’язки з товарами.SaaS

Інтеграція з Укрпоштою в Python

Magento підтримує websites, stores і store views. # Magento створює замовлення.

У K2 ERP потрібно визначити правила: У Magento shipment відповідає за відвантаження замовлення. Для Adobe Commerce as a Cloud Service набір REST endpoint-ів відрізняється, а для автентифікації застосовується для Adobe Identity Management Service. # Формується складське відвантаження.Технічне завдання: інтеграція ПРРО Checkbox для Python

  • створення замовлення;
  • оновлення версій замовлення;
  • оплату;
  • скасування;
  • створення shipment;
  • створення invoice;
  • створення credit memo;
  • оновлення версій товару;
  • зміну залишку;
  • оновлення версій клієнта. * передавання товарів із K2 ERP у Magento;
  • оновлення версій назв, описів, фото, категорій, атрибутів і варіантів;
  • синхронізація цін;
  • синхронізація залишків;
  • робота з кількома складами або джерелами запасів;
  • отримання замовлень із Magento;
  • створення замовлень клієнта в K2 ERP;
  • створення або оновлення версій карток клієнтів;
  • передавання статусів замовлень назад у Magento;
  • передавання shipment-даних;
  • передавання tracking number;
  • контроль оплат;
  • контроль invoice-статусів;
  • контроль повернень і credit memo;
  • підготовка даних для фіскалізації;
  • зберігання історії обміну;
  • обробка помилок інтеграції. # Статус замовлення оновлюється.

Клієнти

У K2 ERP це здатна працювати так:

Джерела

Simple product — це базова товарна позиція з власним SKU, ціною та залишком. # У журналі обміну зберігається статус і можливі помилки. Для практичної інтеграції часто використовують один із підходів:

компонент Magento здатна завантажувати або оновлювати клієнтів у K2 ERP. # Якщо товар існує, платформа оновлює його інформаційні дані. Це критично для товарного каталогу, фільтрів, пошуку і SEO.

Під час роботи модуля Magento можуть виникати такі помилки:

Із замовлення можуть завантажуватися:

Magento GraphQL API

Див. так само

Основні задачі модуля:

Обмеження та ризики

K2 Модуль Shopify

K2 компонент Magento здатна синхронізувати: 

== Типовий сценарій синхронізації товарів ==
Отримано з https://wiki.kyiv.ua/index.php?title=K2_Модуль_Magento&oldid=1166