- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Два интернет-магазина, склад один.
Клиенту надо с общего склада синхронизировать остатки по обоим магазинам.
Поступает заказ в магазин, моя система учета видит заказ, т.к. он поступает уже оплаченным (неоплаченные заказы не регистрируются), то моя система вычитает товар из заказа на складе. Передает данные по остаткам в оба магазина, синхронизирует.
Далее клиент, ему так удобно, работает с каждым заказом из админки конкретного магазина - меняет количество товара в заказе, убирает часть товаров, добавляет новые товары - это происходит достаточно редко, но бывает.
И тут я в ступор впал, поэтому и пишу буквами, так мне проще разобраться, да и помощь может предложит.
Итак, сценарий №1 - клиент меняет количество товара. Моя система это видит, она сравнивает сколько было товара в заказе на момент заказа, добавляет или убирает товар со склада в зависимости от текущего состояния заказа в магазине. Синхронизирует остатки по магазинам.
Сценарий 2 - клиент меняет статус заказа на отменный, но при этом в админке и БД магазина состав заказа не изменяется (так устроен движок магазина), но сами товарные остатки увеличиваются на количество товаров в заказе, который был отменен.
И еще куча сценариев может быть. В таком хаосе я не могу придумать решения :)
Мне бы идеально было бы чтобы клиент вел все изменения заказа в моей системе, т.е. работал напрямую со складом, но при этом ему придется дублировать свои действия в магазинах.
магазины на чем сделаны? Как по мне, тут надо не отдельная система учета, а допиливать админку самого магазина. Хотя, не понятно почему нельзя обрабатывать заказы в crm
Так действие же простое по сути. Где-то убыло - где-то прибыло...
Одна функция/скрипт - ее всегда можно дорабатывать под конкретные действия. Она же может слать данные на склад в реальном времени.
zhitov, проблема в том, что действия простые, но делаются вне склада, на склад действия не передаются, склад раз в минуту смотрит данные в магазинах, работает напрямую через БД.
А за минуту можно сначала обновить данные в заказе, а потом отменить, а затем еще что-то добавить. Такие скачкообразные действия, которые мешают :)
Но понемногу начинаю придумывать как и что, все-таки написанные мысли лучше чем просто в голове.
действия простые, но делаются вне склада, на склад действия не передаются
Доступ к скриптам магазинов есть?
В БД в отдельную таблицу писать изменения...
1 673 2 1
2 886 3 -
3 777 4 2
zhitov, проблема в том, что действия простые, но делаются вне склада, на склад действия не передаются, склад раз в минуту смотрит данные в магазинах, работает напрямую через БД.
Так в этом и проблема. Вы сейчас в любом случае пытаетесь придумать костыль, где будет определенный рассинхрон. Надо передавать действия на склад и считать одну базу эталонной, а остальные всегда работают с ней.
Magazinshik, там каждая база главная в своих задачах.
Менять статус заказа, выставлять счета, редактировать товар в заказе удобней и правильней с помощью движка магазина.
А вот считать остатки с помощью моей системы учета.
Вот в этом и заковыка. Но вроде как решил вопрос, написал механизм синхронизации.
Magazinshik, там каждая база главная в своих задачах.
Менять статус заказа, выставлять счета, редактировать товар в заказе удобней и правильней с помощью движка магазина.
А вот считать остатки с помощью моей системы учета.
Вот в этом и заковыка. Но вроде как решил вопрос, написал механизм синхронизации.
Значит неправильно спроектирована база данных. Никто не мешает сделать одну эталонную базу данных, даже внешнюю, а дальше тянуть в каждую учетную систему только те данные, которые нужны ей.
Что значит неправильно спроектирована?
Есть стандартный движок магазина, 2 штуки, разные версии, разные дизайны (шаблоны), разные домены - PrestaShop.
Нужно синхронизировать остатки в этих магазинах. Я не нашел ничего лучшего, как быстренько (2 недели ушло) набросать отдельную БД и админку под общий склад с возможностью синхронизации остатков в магазинах.
Что значит неправильно спроектирована?
Есть стандартный движок магазина, 2 штуки, разные версии, разные дизайны (шаблоны), разные домены - PrestaShop.
Нужно синхронизировать остатки в этих магазинах. Я не нашел ничего лучшего, как быстренько (2 недели ушло) набросать отдельную БД и админку под общий склад с возможностью синхронизации остатков в магазинах.
Почему тогда на отдельную базу не отдаются данные из интернет-магазинов? В такой ситуации БД должна быть одна, вот и всё. Каждый из интернет-магазинов коннектится к общей базе и получает данные. Версии, дизайны, шаблоны, домены и прочее вообще к этому не имеют никакого отношения, т.к. это лишь особенности общей БД.
Magazinshik, потому что движком магазина не предусмотрена работа нескольких доменов с одной базой.