Система учета, пишу сам, запутался, распутайте

12
humbert
На сайте с 16.03.2006
Offline
501
1304

Два интернет-магазина, склад один.

Клиенту надо с общего склада синхронизировать остатки по обоим магазинам.

Поступает заказ в магазин, моя система учета видит заказ, т.к. он поступает уже оплаченным (неоплаченные заказы не регистрируются), то моя система вычитает товар из заказа на складе. Передает данные по остаткам в оба магазина, синхронизирует.

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

И тут я в ступор впал, поэтому и пишу буквами, так мне проще разобраться, да и помощь может предложит.

Итак, сценарий №1 - клиент меняет количество товара. Моя система это видит, она сравнивает сколько было товара в заказе на момент заказа, добавляет или убирает товар со склада в зависимости от текущего состояния заказа в магазине. Синхронизирует остатки по магазинам.

Сценарий 2 - клиент меняет статус заказа на отменный, но при этом в админке и БД магазина состав заказа не изменяется (так устроен движок магазина), но сами товарные остатки увеличиваются на количество товаров в заказе, который был отменен.

И еще куча сценариев может быть. В таком хаосе я не могу придумать решения :)

Мне бы идеально было бы чтобы клиент вел все изменения заказа в моей системе, т.е. работал напрямую со складом, но при этом ему придется дублировать свои действия в магазинах.

Парсинг прайс-листов, наполнение интернет-магазина товаром. (https://humbert.ru) Любая CMS (Битрикс, OpenCart, Prestashop и даже Woo Commerce )
vimpel77
На сайте с 27.03.2012
Offline
106
#1

магазины на чем сделаны? Как по мне, тут надо не отдельная система учета, а допиливать админку самого магазина. Хотя, не понятно почему нельзя обрабатывать заказы в crm

------------------------- Стратегические просчеты невозможно компенсировать тактическими успехами
zhitov
На сайте с 30.01.2005
Offline
220
#2

Так действие же простое по сути. Где-то убыло - где-то прибыло...

Одна функция/скрипт - ее всегда можно дорабатывать под конкретные действия. Она же может слать данные на склад в реальном времени.

Строительные калькуляторы (http://www.zhitov.ru/)
humbert
На сайте с 16.03.2006
Offline
501
#3

zhitov, проблема в том, что действия простые, но делаются вне склада, на склад действия не передаются, склад раз в минуту смотрит данные в магазинах, работает напрямую через БД.

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

Но понемногу начинаю придумывать как и что, все-таки написанные мысли лучше чем просто в голове.

zhitov
На сайте с 30.01.2005
Offline
220
#4
humbert:
действия простые, но делаются вне склада, на склад действия не передаются

Доступ к скриптам магазинов есть?

В БД в отдельную таблицу писать изменения...

id | наименование | со склада |обратно на склад
1 673 2 1
2 886 3 -
3 777 4 2
Magazinshik
На сайте с 15.06.2016
Offline
56
#5
humbert:
zhitov, проблема в том, что действия простые, но делаются вне склада, на склад действия не передаются, склад раз в минуту смотрит данные в магазинах, работает напрямую через БД.

Так в этом и проблема. Вы сейчас в любом случае пытаетесь придумать костыль, где будет определенный рассинхрон. Надо передавать действия на склад и считать одну базу эталонной, а остальные всегда работают с ней.

Домены/сайты в Google News (/ru/forum/1001331) - мгновенная индексация и трафик
humbert
На сайте с 16.03.2006
Offline
501
#6

Magazinshik, там каждая база главная в своих задачах.

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

А вот считать остатки с помощью моей системы учета.

Вот в этом и заковыка. Но вроде как решил вопрос, написал механизм синхронизации.

Magazinshik
На сайте с 15.06.2016
Offline
56
#7
humbert:
Magazinshik, там каждая база главная в своих задачах.
Менять статус заказа, выставлять счета, редактировать товар в заказе удобней и правильней с помощью движка магазина.
А вот считать остатки с помощью моей системы учета.

Вот в этом и заковыка. Но вроде как решил вопрос, написал механизм синхронизации.

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

humbert
На сайте с 16.03.2006
Offline
501
#8

Что значит неправильно спроектирована?

Есть стандартный движок магазина, 2 штуки, разные версии, разные дизайны (шаблоны), разные домены - PrestaShop.

Нужно синхронизировать остатки в этих магазинах. Я не нашел ничего лучшего, как быстренько (2 недели ушло) набросать отдельную БД и админку под общий склад с возможностью синхронизации остатков в магазинах.

Magazinshik
На сайте с 15.06.2016
Offline
56
#9
humbert:
Что значит неправильно спроектирована?

Есть стандартный движок магазина, 2 штуки, разные версии, разные дизайны (шаблоны), разные домены - PrestaShop.

Нужно синхронизировать остатки в этих магазинах. Я не нашел ничего лучшего, как быстренько (2 недели ушло) набросать отдельную БД и админку под общий склад с возможностью синхронизации остатков в магазинах.

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

humbert
На сайте с 16.03.2006
Offline
501
#10

Magazinshik, потому что движком магазина не предусмотрена работа нескольких доменов с одной базой.

12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий