Что-то сидел сидел и задался вопросом: "Каким образом может быть построена БД?".
Поискал в интернете описание.
Нашел вот это по большой части рекламное (рекламу мимо ушей пропускаем), но описывают два основных варианта и третий гибридный:
http://www.cnews.ru/reviews/free/trade/s/fit/
1. Информационная система с распределенными базами данных.
2. Информационная система с единой базой данных.
3. Гибрид первых двух.

Минусы есть во всех.

РБД - обновлять и сопровождать трудоемко с ростом числа торговых точек. Как миниму с точки зрения контроля автоматических обменов и автоматических обновлений (прошли / не прошли - руками).

Единая база - узкое место постоянный канал связи.

Собственно вопрос:
Какие средние и крупные (пусть будет от 40 торговых точек) торговые сети используют 1С и какую структуру они используют?

(0) Если розничная сеть с большим постоянным оборотом числа покупателей, то только распределенка без вариантов.

"розничная сеть с большим постоянным оборотом числа покупателей" должна быть не на 1С

В реальности всегда используется гибрид. Даже банальная Розница РИБ имеет встроенный дисконтный сервер для онлайна.

(2) да ладно. Ни чем не хуже других платформ.

(3) Возле моего дома магазин розничный. Работает на екселе.
У них запущен макрос на VBA с кнопочками и формочками и пишется все в ексель файл.
Никакого тебе инета, только хардкор. Зато работает.

(1) "оборот покупателей" - это имеется ввиду большим количеством чеков в день?
(2) Не совсем понял, а как же тогда МАГНИТ? По моему он на 1С работает. Маленькой сеть никак не назовёшь.
(5) Ну так это один только магазин, а не сеть - хоть в тетрадке в клеточку.

(6) "оборот покупателей" - это имеется ввиду большим количеством чеков в день?

Именно. Количество чеков в единицу времени.
Недопустимо чтоб стояла толпа покупателей с полными тележками и ждали пока там кассир будет разбираться инет там пропал или еще чего.
Если же это есть магазинов по продаже кофеапаратов за 100 тыр и к ним приходит 5 клиентов в день, то можно и общую базу через инет.

"Ну так это один только магазин, а не сеть - хоть в тетрадке в клеточку."

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

[Какие средние и крупные (пусть будет от 40 торговых точек) торговые сети используют 1С и какую структуру они используют?]страх и ненависть,брррр

Тут ещё упоминается многоуровневая РБД на 1С:
v8: РИБ 1С:Розница на 150 магазинов

Кто-нибудь создавал многоуровневый РБД на практике?

А почему фронтол с их синхронизатором не рассматриваете? Зачем Геморой с риб?

(0) там вариант 3, причем и 1С, и не 1С. На 1С в основном всякого рода бюстгалтерия и связанные с ней экономические всякие планово-фактически промудохеровыверты. Фронт на 1С у крупной сети быть не может. Равно как и то место, в которое стекаются почековые продажи.

38 магазинов розничная сеть в Москве второй год РИБ все летает. MAGAZKA
Дисконтные карты.бонусные .подарочные сертификаты .актуальные остатки по сети.

На фронтах однозначно не 1С

(13) МММ. Все всем платиться

(15) Как там дела у Мавра, до сих пор живет? По сколько месяцев без перезапуска?

(2) (14) Как минимум два крупных сотовых ритейлера используют на форнтах 1С, причем один из них 7.7

По существу вопроса присоединяюсь к (1)

(0)В крупной организации главное продуманность архитектуры.
Центру нужна информация со всех точек, но надо понимать что далеко не вся.
Поэтому мелкая точка работает со своей базой, обмениваясь с центром лишь необходимой информацией.

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

Поэтому построить можно и на 1с.
Просто под крупную контору не пойдут типовые решения. Ибо не бывает типовых пригодных на все случаи.

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

Просто основное достоинство 1с это готовые решения для автоматизации из коробки.
Взял поставил и пользуйся.
Немного неподходит - немного допилил.

А в случае крупного внедрения немногоо допилить не получиться, там надо все перепиливать.
Т.е речь идет практически о написании решения с нуля.
А когда пошла такая пьянка, что решение пишется, то основное достоинство 1с теряется - написать с нуля можно на чем угодно, и что угодно.

Ко мне на склад ТЭК зашла - автоматизация на нуле. Операторов получила Эксель, закрасила цветом сто надо и отправила обратно

Адидасы вроде были на рарус магазин

(19) Угу и при большом кол-ве рабочих мест/компов встает сразу минус 1С в лицензиях.

Если стоимость разработки не на 1С сравнима только с ценой нужного кол-ва лицензий 1С то логичен отказ от 1С.

Если это непродовольсвенная р0зница: 2-100 чеков в день на 1 кассу.
Можно в центр. офисе ставить:
1С УТ /КА/УПП /Бух.
Правильнее делать в центр. офисе: 1С Розница центр. узел
В торговых точках ставить 1С Розница.
Обмен можно и нужно и лучше делать нетиповой - упрощая ход объектов. Возможно делать фильтры по объектам/базам и пр. При большом кол-ве магазинов, вообще изменить логику хождения номенклатуры, цен, скидок, под. сертификатов, диск. карт и прочего.   С периодическим обрезанием баз данных в магазинах (напр. инфо не более 3 лет в магазе).


Если продовольственная розница или супермаркеты - обычно на кассах стоит какой-нить фронтолл, кот. заточен под быструю продажу.

напр. Евросеть, Связной, Линзмастер и прочие вообще сидели на Рарус магазине - долгое время.

Можно смело использовать 1С Розница (можно аналогичные решения от Штриха и прочее).  
   Если говорить про непродовольственную розницу и не супермаркеты. До 3-5 касс в магазине, до 10 чеков в час по одной кассе до 500 ед.в день. Общее кол-во магазинов например до 100.
  
Другие варианты:
   Все равно на кассах можно ставить решения от 1С. Напр 1С розница (и она реально тянет на 50 магазинов без проблем при правильном подходе)!
   В центр. офисе: SAP, MS Axapta, Oracle или любые другие решения, которые требуются. Между ними программерами настраивается обмен всеми документами (сажают таких людей в штат в крупных сетях) и вуаля - пожалста, работайте ;)
----------------
   Также необходимо понимать, что аналитика online как и по каждому чеку нужна редко и под это дело лучше иметь отдельную базу данных. А в центр. офисе агрегировать общую инфо за кассовую смену (т.о. значительно уменьшается объем данных в центр. базе).
   А в случае, необходимости анализа по чекам - анализ проводится в доп. базе (вообще-то это нужно не часто при принятии управл. решений или расчета премий). А в центр. базу передается общая инфо: кол-во чеков по продавцам, средний чек за день, общее кол-во поситетелей и пр.
   я вот как-то так это вижу )))

Имеется ввиду:
А в центр. базу передается общая инфо по чекам: кол-во чеков по продавцам, средний чек за день, общее кол-во поситетелей и пр.!
При этом товарный состав, кол-во, НДС, суммы и аналитики по диск. картам, под.сертификатам, купонам и т.п. передаются в полном объеме.
Железо надо подбирать в зависимости от объемов и под каждую конкретную организацию, магазин и центр. офис (кстати, при этом). Также необходимо помнить, что в таких организациях и должна быть достаточно хорошая автоматизация склада/ов. а дальше начинается полёт фантазии и реальные условия.
что касается стоимости внедрения: то при большом кол-ве сотрудников, намного проще заплатить программистам: 10 тр., чтобы запретить пользвателям нажимать на какую-то кнопочку, нежели исправлять косяки за 100 пользователями за 2 месяца (то на то и выходит).
Что касается разработки с нуля или из коробки: все-таки разработка с нуля - значительно дороже, т.к. обычно все таки работа магазинов разнообразна. И еще неявный фактор: это поддержка: что делать если те, кто разработал приложение для розницы - исчезнут (слишком малая/большая ЗП, стало неинтересно или "ушли")! не всегда легко найти разрабов за адекватные деньги! А еще бывают сложности в техн. развитии продукта, т.к. изначально была выбрана неправильная платформа (напр. ее утвердил техн. директор, кот. ее хорошо знал)! А в компании на 40 (не)больших магазинов  - IT отдел может быть от 1-9 сотрудников и не стоит скидывать со счетов: что решение главным по ИТ может быть принято из корыстных целей (или его ограниченности в знаниях)!

а такой вопрос. на УТ как часто поводят обрезания или на 100 магазинов история хранится годами?

(19) //написать с нуля можно на чем угодно, и что угодно

Тут вроде про учетные системы речь?

Поэтому позволю себе спросить: а пыль глотать не замучаетесь при написании "на чем угодно" с нуля нормального масштабируемого клиент-сервера со связью с СУБД, контролем ссылочной целостности, авторизацией, РЛС, регистрами, СКД, да, блин, теми же нормальными контролами?

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

(22) Помимо стоимости разработки есть еще стоимость владения. Ну и риски, см выше. Да, собственно, и разработка..
Если, конечно, мы не про сеть из трех ларьков с китайскими трусами.

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

(10) у нас УТ , от нее РТ, а от нее 6 магазинов с РТ. Это многоуровневая?

А вот многие говорят что бек должен быть фронтол, как они в этом фронтоле скидки настраивают? Если 50 магазинов и принципы расчета скидок меняются каждый месяц.

еще Агат в 1C работает. Интернесно как у них построено

(0) у меня на поддержке 1С в 9 розничных магазинах.
Но сразу огорчу ...на кассовых терминалах пришлось отказать от 1С, т.к. часто висла. В итоге там поставили программу Set Retail и настроили обмен с 1С базой магазина.

>> пришлось отказать от 1С, т.к. часто висла
Что вы вкладываете в понятие "висла"?

(27) Фронт - это достаточно узко заточенное решение. Накой там РЛС, если с ним кроме кассира никто толком и не работает? И СКД?

(33) там компы слабые
база 1С файловая - либо висла вообще либо драйвер какой-то глюкнет (весы, сканер, ФР)

(0) Уже 16 лет работаю (в основном с 1С) "программером" в розничных сетях. На практике используются все три варианта. Выбор конкретного определяется спецификой товара и бизнеспроцессов, тараканами владельцев, и "исторически так сложившихся" причин. Вплоть до экзотики типа 100 с лишним магазинов по схеме 2 или чуть ли не дюжины центральных баз в схеме 1

(6) Магазинный софт в Магните (по слухам) - самописка, разработанная не на 1С.

>да, блин, теми же нормальными контролами?

давно в 1с завезли нормальные контролы?

(35) На поддержке ~20 магазинов, на кассах Розница 1.0 файловая, не виснет, драйверы не глючат, ЧЯДНТ?

Справедливости ради в магазинах с большой проходимостью файловая всё-таки не подходит из-за проблем с производительностью, ну или по крайней мере база должна лежать на кассе локально.

А так основная масса проблем носит аппаратный характер: отошел usb провод до фискальника, и тому подобное

1с активно выпиливается из розницы

в текущем виде она там накуй не упала... только в виде куска бэкофиса

(35) ну вы бе еще на нокию поставили.

(37) давно

(37) Попробуй на досуге - взять C#, взять аналог управляемого интерфейса в 1С - WPF, и реализовать хотя бы аналог 1С-овской табличной части, со всеми плюшками (оформление, настройка колонок, сортировки, отборы, события, привязка данных к сложным объектам, построчные картинки, элементы управления в ячейках).
Замучаешься пыль глотать, и все равно такое же не получишь.

(42) В плане быстроты разработки интерфейсов для бизнес-приложений - 1С'у нет равных

Половина народу в теме говорит про фронт, половина про бэк, никто не знает, что ТС имел в виду, а некоторые умудряются еще и путать эти термины.
(39) Видел узкую нишу, где Розница 2 вообще хороша. Это маленькие чисто алкашные магазины, которые заказывают товар поставщику минуя ЦО и принимают товар так же. Относительно мало чеков и весь валидол с ЕГАИСом (прием, продажа, остатки) на точке. Фронт и бэк объединены в одну базу, на одном компе, за 3.5к (или сколько там базовая стоит) - просто сказка.

(37) Я б тоже послушал, что у 1с контролов нет такого, что СИЛЬНО мешало бы делать интерфейсы УЧЕТНЫХ СИСТЕМ.

(38) Кода до 100 дойдете тогда можно будет еще раз посмотреть

>взять аналог управляемого интерфейса в 1С - WPF, и реализовать хотя бы аналог 1С-овской табличной части, со всеми плюшками (оформление, настройка колонок, сортировки, отборы, события, привязка данных к сложным объектам, построчные картинки, элементы управления в ячейках

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

А мне вот любопытно и РЦ в 1с тащите или на обмены еще и складскую логистику?

(46) А вы уже дошли? Поделитесь опытом?

(49)Боже упаси,Аксапта,а 1с только нужна тока для сдачи отчетности и кое-что еще по мелочи.

(50) А у аксапты есть решения для маленького ларька в котором 2 кассы, 1 комп товароведа + директор из дома иногда отчеты смотрит?

(51)Я не об этом

40 розничных магазинов. Используем УТ 11 на кассах и в центральной базе. Схема - обмен с одной центральной базой типовой обмен по подразделениям (доработанный)

(0) На примере мобильных ритейлерских сетей:
конфа у каждого своя, обновление через центр, нераспреденная. Торговые точки обмениваются с утра и вечером обязательно, днем у кого как устроен онлайн обмен.

+(54) на ТТ переделанные решения, не Розница.

+(54) конфа обновляется службой поддержки

(52) Ну а раз для маленьких ларьков альтернативы нет, то и смысл такие разговоры начинать? Когда дойду до 100 магазинов, будут все те же самые недостатки что и сейчас, только не в 20 магазинах а в 100

(57)Я и написал,что до пока точек мало то пойдет,а расширитесь то весьма сомнительно.Что не так?

(58) А что должно измениться при росте точек с 20 до 100?

(59)У кого-то ничего

Объемы,автозаказ,маркетинг,РЦ или несколько.Может часть прямых поставок на точки вкупе с РЦ

А на фронте что поменяется?

да фронт самое простое или разговор о кассовом по вообще?

(58) Да всё в порядке, Вы написали, я не согласился. Форум ведь и нужен чтобы делиться обмениваться мнениями.
Просто мы друг друга немного не поняли, 20 магазинов - это не одна сеть, несколько ларёчников на обслуге, поэтому я скорее из тех о ком в (60)
А так то да, в крупных сетях нужны другие решения

(42) было, причём под дельфи ещё во времена семёрки. Гуглить DeveloperExpress, InfoPower, QuantumGrid, EhLib (кстати, последнее отечественная разработка)

(65) Да, в делфях много чего было, и трехзвенка и работа с разными базами и таймеры и мат формулы. Сейчас 1С все ближе и ближе приближается к делфям.

(29) Не.
Я понял как-то так например:
УТ ЦБ (одна база центральная РБД) -> УТ промежуточный (несколько баз РБД подчинённый центральной и имеющий в подчинении магазины) -> УТ РБД конечная магазина.

Я так понял для того что бы в обмены засунуть большое количество магазинов делят как бы на кластеры по 20-50 магазинов (зависит от объема магазинов и как часто обмен должен ходить в зависимости от преследуемых целей).
РБД что бы база была единая везде: общее НСИ, не надо обновлять каждый узел отдельно и т.д.

Вот собственно и спрашиваю - кто-то видел такое вживую и каковы впечатления.

(36) Ну заглядывал я в программу мельком, в которую товаровед вбивает накладные. По моему это 1С была.
Может конечно у них разнородные программы, но вряд ли.

(66) Не движется 1С к Делфям.
В Делфях полноценный компилятор. 1С интерпретатор.

(67) была структура 1 - 8 - 70 баз, самописка на базе КА 1.0, работает нормально. Она еще и фронтом на кассах при этом была.

(70) Обмены - каждые 2 часа выгрузка и ещё каждые 2 часа загрузка для 70 производились (т.е. полный цикл 4 часа)?
Или выгрузка вместе с загрузкой сразу?

(71) загрузка + выгрузка в один прием, синхронизировано через веб сервисы (заодно инфа о прохождении обмена есть), с центром раз в пол часа, в остальных уровнях сразу после этого. временной лаг получался около 30-40 минут получался. сверху прикручена система для внеочередной передачи нужных данных.

через те же веб сервися

(72) как обновляется конфигурация в узле? пакетным запуском? как контролируется успешность обновления?

(74) Обновляется скорее всего только ночью.
Если какие-то обмены обратные не прошли, то либо не обновилась конфигурация либо обмены к узлу не прошли, либо выгрузка не прошла.

(74) Суть в том, что дешевле (трудозатраты) разово/периодически обновить подчиненные узлы и решать текущие проблемы с обменами по расписанию, чем следить за онлайном базы на 100+ узлов, которые разнесены на сотни км по области (или нескольким областям).

(0) Соответственно - либо 1 - полный РИБ для всех узлов (и даже каждой кассе отдельный узел)
либо, если где-то позволяет - небольшие узлы на несколько магазинов.

Разумеется, от 20 узлов нужно создавть 3/4 звенную структуру РИБ
Типа - центральная база - областные узлы - районные узлы - магазины - кассы.
При этом - на каком-то участке , например, магазин-кассы - может быть смена и конфигурации и обмен уже не РИБ.

Пример
- центральная база УТ
- областные узлы УТ
- районные узлы УТ
- магазины УТ
- кассы Розница (или другое кассовое ПО от 1С или нет).

Пример
- центральная база УТ
- областные узлы УТ
- районные узлы УТ
- магазины Розница
- кассы Розница (или другое кассовое ПО от 1С или нет).

Пример
- центральная база УТ
- областные узлы УТ
- районные узлы Розница
- магазины Розница - кассы в этой же базе

Пример
- центральная база УТ
- областные узлы УТ
- районные узлы Розница - магазины и кассы в этой же базе

И т.д. как вниз, так и вверх, если сеть федеральная, то между центром и областными бывает смысл сделать еще один слой (зависит еще и от структуры самого предприятия).

Если сеть международная (хотя бы СНГ) - то еще хлеще структура может получиться

Разумеется, примеры - УТ и Розница - это не панацея, а просто для примера - отраслевых конфигураций - как грязи.

(0) тема интересная... у нас сейчас (3) но в планах переходить на (1).
Думаем, анализируем, считаем....

+77 дабы не смущать... сейчас 3. в планах переход на 1. ))

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

это все безотносительно сферы деятельности....

Связной. 2700 магазинов:) И везде 1С.

(23) Так и сидим на Рарусе)

сеть ювелирных магазинов. РИБ УТ 10 (не помню какая точно). порядка 30 магазинов (5 лет назад) в разных часовых поясах. трехуровневая структура: магазин - региональный офис - центральная база в Москве. соответственно, до ЦБ из магазинов добегает только то, что надо, например, чеки так и остаются только в магазинах, а летели отчёты о продажах или что-то там. считалось, что 2 дня задержка данных - это норм.

Online нужен:
- Дисконтно-бонусный сервер для обслуживания карт.
- Планирование общих закупок с распределением заказов по магазинам.
- Актуальные остатки для планирования перемещения между магазинами.
- Получение документов и оплата товара клиентом в одном офисе, а получение - в другом (или в других).

(83) Только, например, в рознице дисконтный сервер работает отдельно на веб-сервисах, и специально сделан для работы именно в РИБ, когда использующие его узлы являются подчиненными к центральной базе. И поток этих онлайн запросов на несколько порядков меньше, чем постоянный онлайн к базе и, как правило, кратен количеству чеков (т.к. обычно скидка рассчитывается однократно перед пробитием чека и его оплатой и после оплаты - данные чека передаются серверу). Ну или если оплата бонусами - то еще 1-2 доп. запроса при оплате.
При времени на чек - 5-15 минут (просканировать товар, принять оплату, выдать сдачу и т.д.), то это менее 1 запроса в минуту, что обеспечить намного легче.

Все остальные задачи в (83), как правило, решается аналогичными способами, а в целом базы синхронизируются именно регламентным обменом.