Просмотр полной версии : Несколько ресторанов со своей номенклатурой и SHHO
Доброго времени суток!
Имеется сеть из 4х ресторанов, у каждого ресторана своя номенклатура блюд, в каждом установлен SH-склад с оператором, который ведет приход товаров, загружает себе реализацию из РКИПЕРа и т.д.
У руководства этой сети возникло желание объединить все эти рестораны центральным складом. Для этого они купили ключ SHHO, для установки его на "Центральном складе".
Правильно ли я понимаю-SHHO подключается к каждому складу ресторана и забирает с него документы движений товара и реализацию себе, а потом объединяет это все в свою общую базу?
И второй вопрос, планируется, что помимо поступлений, которые организуются непосредственно в ресторан (заводит оператор ресторана локально), центральным складом так же будут
приходоваться товары в этот ресторан - возможно ли такое?
Может кто-то скинет ссылку, где можно подробнее почитать про работу SH совместно с SHHO.
Если у кого-то была подобного рода задача - поделитесь, пожалуйста, своим решением.
Заранее, благодарю!
У руководства этой сети возникло желание объединить все эти рестораны центральным складом. Для этого они купили ключ SHHO
Все, дальше можно просто застрелиться. Будет гораздо проще.
Правильно ли я понимаю-SHHO подключается к каждому складу ресторана и забирает с него документы движений товара и реализацию себе, а потом объединяет это все в свою общую базу?
Почти. SHHO занимается словарями и отчетностью.
И второй вопрос, планируется, что помимо поступлений, которые организуются непосредственно в ресторан (заводит оператор ресторана локально), центральным складом так же будут
приходоваться товары в этот ресторан - возможно ли такое?
Только как обычно - с подключением клиента к серверу того ресторана, куда надо сделать приход.
Если у кого-то была подобного рода задача - поделитесь, пожалуйста, своим решением.
Если позволяют объемы - просто единую базу SH4 на всех. Это в разы проще, в т.ч. по администрированию.
Если позволяют объемы - просто единую базу SH4 на всех.
+100500
Единственный минус: невозможно будет разграничить пользователей отдельных ресторанов от того что бы они не лезли в склады, справочники и отчеты других точек.
Еще вариант: подождать пол года до выхода 5-го склада и там будет коммунизм! По крайней мере обещают ;)
Если позволяют объемы - просто единую базу SH4 на всех. Это в разы проще, в т.ч. по администрированию.
Т.е. в одном месте организовать сервер SH, а в ресторанах поставить клиентов, чтобы они подключались к этой базе и заводили/загружали документы в общую базу.
Но если я правильно понимаю - операторы складов будут видеть документы всех ресторанов, не только свои?
Получается - что купили они этот ключ (SHHO), что нет - не решает он их потребность!
Ну я так думаю что теперь (когда уже купили) другого варианта кроме как поднимать SHHO уже не будет ;)
Просто если бы раньше задались этим вопросом, то возможно, взвесив все за и против, сделали бы выбор в пользу общей базы.
...просто если бы раньше задались этим вопросом, то возможно, взвесив все за и против, сделали бы выбор в пользу общей базы.
Я с вами полностью согласен.
А не могли бы вы тогда описать оптимальную схему организации всего выше описанного с учетом наличия ключа SHHO и локальных SH-складов по ресторанам.
А не могли бы вы тогда описать оптимальную схему организации всего выше описанного с учетом наличия ключа SHHO
К сожалению не смогу, т.к. всегда выбор делался в пользу общей БД.
SHBO в живую никогда не ставил :(
Там в целом, ничего хитрого нет.
Все справочники делаются строго в SHHO, в связи с чем лучше сделать чистые базы на местах. В базах на местах ограничить права, чтобы ни в коем случае нельзя было локально править справочники. Строго делать бэкапы как можно чаще, потому что нарушение правил насчет справочников - смерть системы.
Локально вводятся документы. SHHO настраивается на все локальные базы, делает рассылкy справочников, читает накладные.
думаю что теперь (когда уже купили) другого варианта кроме как поднимать SHHO уже не будет
Не согласен, еще не поздно, лучше смириться с затратами и поставить одну базу, чем дальше залезать в дебри и страдать.
---------- Добавлено в 19:10 ---------- Предыдущее сообщение было размещено в 19:09 ----------
если я правильно понимаю - операторы складов будут видеть документы всех ресторанов, не только свои?
Одним складом можно граничить. Калькуляторы, если им надо больше видеть, там да, придется дать возможность видеть чужое. Справочники лучше все равно отдать в одни руки.
у каждого ресторана своя номенклатура блюд,
На сколько в этих ресторанах блюда разные? Смысл объединения в одну базу - упрощение ведения справочников и калькуляций при большой схожести блюд во всех точках. Смысл SHHO - тоже, что и одна база + консолидированная отчетность. Исходя из Вашего описания, наиболее подходящий способ - создать еще одну базу для центрального склада.
На сколько в этих ресторанах блюда разные? Смысл объединения в одну базу - упрощение ведения справочников и калькуляций при большой схожести блюд во всех точках. Смысл SHHO - тоже, что и одна база + консолидированная отчетность. Исходя из Вашего описания, наиболее подходящий способ - создать еще одну базу для центрального склада. Дело в том, что сами по себе рестораны рознятся по своей направленности (японская, славянская кухни, кофейня), поэтому справочники и калькуляции будут совершенно разные.
Подведя всё выше описанное благодаря всем вам, вырисовывается 3 решения:
1. Отдельная база SH в каждом ресторане и подключение оператора
центрального склада к локальным базам sh для приходования товара;
2. Одна база на все рестораны, операторы ресторанов (в т.ч. оператор
центрального склада) подключаются к ней удаленно;
3. У каждого ресторана своя sh база, SHHO у оператора центрального склада;
(все справочники делаются и редактируются строго в SHO !!!, в локальных ресторанах
ставим чистые базы, в этих базах разграничиваем сразу права. Локально вводятся документы,
SHO настраивается на все локальные базы, делает рассылку справочников, читает накладные)
... и как я понимаю, самый оптимальный - это 2й (как по администрированию, так и по работе), единственный неудобный момент - это то,
что оператор склада одного ресторана будет видеть документы всех остальных. И еще вопрос - сможет ли оператор центрального склада исходя из 3-го способа,
добавлять в локальные базы документы (приходовать товар, например). Хотелось бы узнать про конкретные минусы каждого из решений, чтобы организация выбрала для себя оптимальный.
Заранее, благодарю!
единственный неудобный момент - это то,
что оператор склада одного ресторана будет видеть документы всех остальных.
Нет, его можно ограничить одним складом, своим.
сможет ли оператор центрального склада исходя из 3-го способа,
добавлять в локальные базы документы (приходовать товар, например)
Да, точно также, как Вы описали в п.1 - через подключение к локальной базе.
Хотелось бы узнать про конкретные минусы каждого из решений, чтобы организация выбрала для себя оптимальный.
Нужно знать цель объединения, а не просто "руководство решило, что теперь нужен центральный склад". Какие задачи преследуются?
Ребят,подскажите пожалуйста, как ограничить пользователя одним складом? Правильно ли я понимаю-этот пользователь будет видеть только документы своего склада? А можно его ограничить группой складов?
Заранее, большое спасибо!
Группой пока нельзя (обещают в 5-ке сделать)
Выбрать склад для пользователя можно в SDBMan, в карточке юзера.
После этого в списке документов он будет видеть только документы в которых этот склад или поставщик или получатель.
То же и с созданием документов.
Powered by vBulletin® Version 4.2.6 LTS Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot