Коллеги, поделитесь опытом тиражирования Розницы или любого фронт-офисного решения на крупный масштаб. Вопросы примерно следующие:
1) мини сервера 1С в магазины. Имеет ли смысл? Много проблем с сопровождением? Пользовались ли "хитростями" вроде виртуализации?
2) РИБ Розница 2.2 - штатный "выживет" на 150 - 200 узлов с единым центром? Или нужны будут существенные "допилы"? Или схема уже нужна "снежинка"?
3) Тонкий клиент - был ли реальный опыт использования? Кроме проблем с каналом связи какие ещё возможны трудности?
1) мини сервера 1С в магазины. Имеет ли смысл? Много проблем с сопровождением? Пользовались ли "хитростями" вроде виртуализации?
2) РИБ Розница 2.2 - штатный "выживет" на 150 - 200 узлов с единым центром? Или нужны будут существенные "допилы"? Или схема уже нужна "снежинка"?
3) Тонкий клиент - был ли реальный опыт использования? Кроме проблем с каналом связи какие ещё возможны трудности?
По теме из базы знаний
Найденные решения
Поделюсь пока 1С висит :)
Бооольшой ритейл, по СНГ и части восточных европейцев.
В торговых точках 1С:Розница файловая. 1-4 человека в смену 1-2 смены.
Узловые сервера 1С:Розница на sql в зависимости от региона от 4 до 30 точек, заливаются по закрытию кассовой смены 1-2 раза в день.
Региональные сервера 1С:Розница sql до 50 узловых серверов, обмен раз в сутки. Все успевают залиться к 3 утра по Минску.
Москва 5 серверов 1С:Розница sql 2-5 региональных серверов, обмен раз в сутки. Заливаются к 6 утра.
Рабочая база 1С:Торговля sql заливаются к 10 утра.
В 11 справка о продажах на столе генерального.
Как то так :)
Бооольшой ритейл, по СНГ и части восточных европейцев.
В торговых точках 1С:Розница файловая. 1-4 человека в смену 1-2 смены.
Узловые сервера 1С:Розница на sql в зависимости от региона от 4 до 30 точек, заливаются по закрытию кассовой смены 1-2 раза в день.
Региональные сервера 1С:Розница sql до 50 узловых серверов, обмен раз в сутки. Все успевают залиться к 3 утра по Минску.
Москва 5 серверов 1С:Розница sql 2-5 региональных серверов, обмен раз в сутки. Заливаются к 6 утра.
Рабочая база 1С:Торговля sql заливаются к 10 утра.
В 11 справка о продажах на столе генерального.
Как то так :)
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Сервера - всегда имеют смысл - если позволяет бюджет - то только сервер.
Схема "Снежинка", разумеется, напрашивается сама собой - в одну центральную слить поочередно 100 узлов - достаточно долго.
Тонкий клиент - когда много касс в одной базе начнутся блокировки со всеми вытекающими. Лучше, когда каждая касса автономна (но ставить сервер на каждую кассу - накладно, а файловая база известна своей слабой живучестью и низкой производительностью). Поэтому, на мой взгляд, как минимум, магазин должен быть автономен.
Сервера - всегда имеют смысл - если позволяет бюджет - то только сервер.
Схема "Снежинка", разумеется, напрашивается сама собой - в одну центральную слить поочередно 100 узлов - достаточно долго.
Тонкий клиент - когда много касс в одной базе начнутся блокировки со всеми вытекающими. Лучше, когда каждая касса автономна (но ставить сервер на каждую кассу - накладно, а файловая база известна своей слабой живучестью и низкой производительностью). Поэтому, на мой взгляд, как минимум, магазин должен быть автономен.
(2) lenochka-semicova,
ИИИ? Какой вариант вы бы выбрали если все плохи? :)
ставить сервер на каждую кассу - накладно, а файловая база известна своей слабой живучестью и низкой производительностью
Тонкий клиент - когда много касс в одной базе начнутся блокировки со всеми вытекающими
ИИИ? Какой вариант вы бы выбрали если все плохи? :)
(4) Сервер - всегда предпочтительнее - но дорого очень.
Большинство (в моей практике) помимо РИБ по магазину выделяют каждую кассу в РИБ по кассе - отдельная файловая базулька, подчиненная магазинной базе. При этом - если есть бюджет на магазиную базу серверную - то это еще лучше.
Т.е. на 100 узлов я бы поставила
1. серверный центр,
2. ему подчиненных несколько узлов (условно - группы по районам, например) тоже серверных,
3. от районных узлов - магазинные базы. тут смотреть - файловые или серверные, как бюджет ляжет
4. в каждом магазине РИБ по кассе - файловые узлы касс.
Таким образом, обеспечивается максимальная автономность касс, магазинов и т.д.
Большинство (в моей практике) помимо РИБ по магазину выделяют каждую кассу в РИБ по кассе - отдельная файловая базулька, подчиненная магазинной базе. При этом - если есть бюджет на магазиную базу серверную - то это еще лучше.
Т.е. на 100 узлов я бы поставила
1. серверный центр,
2. ему подчиненных несколько узлов (условно - группы по районам, например) тоже серверных,
3. от районных узлов - магазинные базы. тут смотреть - файловые или серверные, как бюджет ляжет
4. в каждом магазине РИБ по кассе - файловые узлы касс.
Таким образом, обеспечивается максимальная автономность касс, магазинов и т.д.
(7) lenochka-semicova,
Купить сервер ещё можно... Но вот тут вопрос обслуживания.
У вас на практике было более 100 серверов 1С + SQL Express? Как часто бывают инцеденты с "съел память, упал не запускается" и т.п.... Не увеличит ли сервер в каждом магазине объём саппорта в 10-ки раз и не снизит ли стабильность и производительность системы...
Сервер - всегда предпочтительнее - но дорого очень
Купить сервер ещё можно... Но вот тут вопрос обслуживания.
У вас на практике было более 100 серверов 1С + SQL Express? Как часто бывают инцеденты с "съел память, упал не запускается" и т.п.... Не увеличит ли сервер в каждом магазине объём саппорта в 10-ки раз и не снизит ли стабильность и производительность системы...
(10) На базу для 100 магазинов SQL нужно не ниже стандарт. Експресс вообще для продакшена не стоит использовать.
По поводу "съел память, упал и т.д.": администрировать базы надо. Есть куча статей, в т.ч. на ИТС, как и что надо настраивать и мониторить:
В частности периодически выполнять:
Обновление статистик
Очистка процедурного КЭШа
Дефрагментация индексов
и не забывать про
Реиндексация таблиц базы данных
Ну и в принципе - на "серьезный проект" надо "серьезно подходить к администрированию сервером приложений и СУБД".
По поводу "съел память, упал и т.д.": администрировать базы надо. Есть куча статей, в т.ч. на ИТС, как и что надо настраивать и мониторить:
В частности периодически выполнять:
Обновление статистик
Очистка процедурного КЭШа
Дефрагментация индексов
и не забывать про
Реиндексация таблиц базы данных
Ну и в принципе - на "серьезный проект" надо "серьезно подходить к администрированию сервером приложений и СУБД".
(14) lenochka-semicova,
А это просто чушь, простите :)
Експресс вообще для продакшена не стоит использовать
ещё один крутой совет. посчитайте стоимость 200 instans-ов SQL Standart :)))))))
и не забывать про
Реиндексация таблиц базы данных
Реиндексация таблиц базы данных
А это просто чушь, простите :)
(10) Что же касается - не увеличит ли сервер то и сё - нужно понимать, что в файловой версии есть определенный предельный размер файла базы данных. В сети на 100 магазинов он выберется за неделю/месяц/год (зависит от базы, размера магазинов и т.д.).
Были проекты, где начальный образ базы получался более 30Гб, что уже сразу превышало размер файловой базы. Но там на кассах была, разумеется, не розница и даже не 1С - 1С был бэком. Но это показательный пример, что такое файловая база - т.е. - ничто - во всех магазинах, разумеется, был SQL.
Также часто бывает падение файловых баз (практически ежедневное/еженедельное) при интенсивной работе на предельных объемах - это распространенное явление, особенно, там где есть сетевые проблемы.
Были проекты, где начальный образ базы получался более 30Гб, что уже сразу превышало размер файловой базы. Но там на кассах была, разумеется, не розница и даже не 1С - 1С был бэком. Но это показательный пример, что такое файловая база - т.е. - ничто - во всех магазинах, разумеется, был SQL.
Также часто бывает падение файловых баз (практически ежедневное/еженедельное) при интенсивной работе на предельных объемах - это распространенное явление, особенно, там где есть сетевые проблемы.
(7) дополню. В магазинах можно ещё посмотреть в сторону "1С:Предприятие 8.3. Сервер МИНИ на 5 подключений", по идее на 2-3 кассы должно хватить. Ну а для самой базы (если брать MS SQL) понадобится, скорее всего, редакция Standart.
(23) comol, я ведь сказал "скорее всего". Зависит от того, какой поток продаж. Я с большими базами не работал ещё, только с несколькими магазинами разливного пива: в центре УТ 11 файловая, в 4-х магазинах РТ 2 файловая. За 12 часов 150-200 чеков по 2-3 позиции (грубо - каждые 4 минуты), базы по 1.5-2 года. Размер РТ - 500-800 МБ. Вот и не понятно, влезет это добро в Express, если, например, будет 2 кассы и по 400 чеков на каждой. Точнее, через сколько оно перестанет влезать. Может быть имеет смысл один раз сделать обработку, делающую аккуратную свертку базы и тогда спокойно жить на редакции Express.
(1) Вопрос интересный "поделитесь опытом тиражирования Розницы или любого фронт-офисного решения на крупный масштаб"
И предложены 3 варианта для обсуждения.
И каждый из вариантов имеет право на существование.
Но есть ещё старый и проверенный временем "Толстый клиент"
Этот вариант очень много лет используют огромное количество компаний, и многие (которые я лично знаю) не собираются переходить на "новинки" от 1С. Когда начинаешь им рассказывать про web-сервисы, то просят не "выражаться" в присутствии дам.
Не поверите, до сих пор 7.7 используют.
В Датацентре, на широком канале работает серьёзный сервер, а в каждой из торговых точек - терминал и принтер (и не один).
Тут поднимался вопрос за обслуживание.
Сервер в датацентре можно арендовать сразу с поддержкой, а на местах (в каждом городе) для настройки терминалов и подключения принтеров достаточно приходящего специалиста, со знаниями 8-ми классника.
Всё зависит от требований руководителя - стабильность или красота.
Если у вашего основного конкурента все менеджера работают с планшета не выходя из автомобиля, то простые решения не для вас...
Осваивайте работу в облаке.
И предложены 3 варианта для обсуждения.
И каждый из вариантов имеет право на существование.
Но есть ещё старый и проверенный временем "Толстый клиент"
Этот вариант очень много лет используют огромное количество компаний, и многие (которые я лично знаю) не собираются переходить на "новинки" от 1С. Когда начинаешь им рассказывать про web-сервисы, то просят не "выражаться" в присутствии дам.
Не поверите, до сих пор 7.7 используют.
В Датацентре, на широком канале работает серьёзный сервер, а в каждой из торговых точек - терминал и принтер (и не один).
Тут поднимался вопрос за обслуживание.
Сервер в датацентре можно арендовать сразу с поддержкой, а на местах (в каждом городе) для настройки терминалов и подключения принтеров достаточно приходящего специалиста, со знаниями 8-ми классника.
Всё зависит от требований руководителя - стабильность или красота.
Если у вашего основного конкурента все менеджера работают с планшета не выходя из автомобиля, то простые решения не для вас...
Осваивайте работу в облаке.
(1) Ещё. Для однозначного ответа необходимы более полные параметры задачи.
Необходима информация об предполагаемых объёмах продаж.
Если это розница, с ассортиментом в миллион наименований, то однозначно, в такой точке должен стоять свой сервер, который использует РИБ для обмена с центральным. В этом случае экономия на специалистах "на местах" - неуместна.
Если это салон, продающий пару тройку автомобилей Ford, то достаточно терминала подключенного по RDP к центральному серверу.
Скорее всего, при проектировании, надо предусмотреть все возможные варианты.
Ещё был поднят вопрос про "допилы" конфигурации.
Вот реально. Даже не представляю себе организацию, у которой 200 торговых точек, руководитель которой не имеет собственного видения тех или иных бизнесс процессов и готов довольствоваться тем что предлагают типовые решения.
"допилы" - обязательно будут необходимы.
Необходима информация об предполагаемых объёмах продаж.
Если это розница, с ассортиментом в миллион наименований, то однозначно, в такой точке должен стоять свой сервер, который использует РИБ для обмена с центральным. В этом случае экономия на специалистах "на местах" - неуместна.
Если это салон, продающий пару тройку автомобилей Ford, то достаточно терминала подключенного по RDP к центральному серверу.
Скорее всего, при проектировании, надо предусмотреть все возможные варианты.
Ещё был поднят вопрос про "допилы" конфигурации.
Вот реально. Даже не представляю себе организацию, у которой 200 торговых точек, руководитель которой не имеет собственного видения тех или иных бизнесс процессов и готов довольствоваться тем что предлагают типовые решения.
"допилы" - обязательно будут необходимы.
(19) CaptainMorgan,
А какие там процессы в розничных торговых точках ? Например наши потребности на 99% перекрываются функционалом типовой розницы. Да ещё и с лихвой. Есть специфичные моменты в виде доп отчётов которые должны быть доступны в магазине.
Другое дело когда выходят за рамки процесса купил-продал. Тогда уже доработки нужны.
Вот реально. Даже не представляю себе организацию, у которой 200 торговых точек, руководитель которой не имеет собственного видения тех или иных бизнесс процессов и готов довольствоваться тем что предлагают типовые решения.
А какие там процессы в розничных торговых точках ? Например наши потребности на 99% перекрываются функционалом типовой розницы. Да ещё и с лихвой. Есть специфичные моменты в виде доп отчётов которые должны быть доступны в магазине.
Другое дело когда выходят за рамки процесса купил-продал. Тогда уже доработки нужны.
(25) Вы пишите "эээ... А торговое оборудование? Выкинуть?"
Дело в том, что RDP позволяет использовать абсолютно всё торговое оборудование.
Вы думаете, если бы фирма 1С не разработала конфигурацию "Управление торговлей" и "Розница" так весь мир до сих пор выполнял бы расчёты с помощью верёвки с узелками.
Технология существует достаточно давно и широко распространена.
Моей ключевой мыслью было: "Необходима информация об предполагаемых объёмах продаж и на основе этого при проектировании, надо предусмотреть все возможные варианты"
А если вам нужен ответ, который вы точно знаете и желаете услышать подтверждение, то
Имеет не просто смысл. Это обязательное условие современной автоматизации.
При грамотном распределении нагрузки Розница 2.2, без особых доработок вполне сможет существовать и на большем количестве узлов.
Трудности, это не то что останавливает развитие прогресса.
Именно трудности стимулируют дальнейшее развитие.
Если вы предполагаете, что "на берегу" заранее можно просчитать все возможные подводные омуты и камни, то глубоко ошибаетесь. Вам нужно обратиться к грамотному франчайзи и все ваши проблемы будут решены.
Дело в том, что RDP позволяет использовать абсолютно всё торговое оборудование.
Вы думаете, если бы фирма 1С не разработала конфигурацию "Управление торговлей" и "Розница" так весь мир до сих пор выполнял бы расчёты с помощью верёвки с узелками.
Технология существует достаточно давно и широко распространена.
Моей ключевой мыслью было: "Необходима информация об предполагаемых объёмах продаж и на основе этого при проектировании, надо предусмотреть все возможные варианты"
А если вам нужен ответ, который вы точно знаете и желаете услышать подтверждение, то
1) мини сервера 1С в магазины. Имеет ли смысл? Много проблем с сопровождением? Пользовались ли "хитростями" вроде виртуализации?
Имеет не просто смысл. Это обязательное условие современной автоматизации.
2) РИБ Розница 2.2 - штатный "выживет" на 150 - 200 узлов с единым центром? Или нужны будут существенные "допилы"? Или схема уже нужна "снежинка"?
При грамотном распределении нагрузки Розница 2.2, без особых доработок вполне сможет существовать и на большем количестве узлов.
3) Тонкий клиент - был ли реальный опыт использования? Кроме проблем с каналом связи какие ещё возможны трудности?
Трудности, это не то что останавливает развитие прогресса.
Именно трудности стимулируют дальнейшее развитие.
Если вы предполагаете, что "на берегу" заранее можно просчитать все возможные подводные омуты и камни, то глубоко ошибаетесь. Вам нужно обратиться к грамотному франчайзи и все ваши проблемы будут решены.
(38) CaptainMorgan,
А я вот как раз ищу людей которые с этим уже сталкивались. Пока что человек с реальной практикой не совсем с нами согласен (36)
RDP позволяет использовать абсолютно всё торговое оборудование
Ну ну... И сканеры в режиме COM и кассы, и всё так замечательно работает на медленном и-нете. Весь мир понимает что такое Front и Back уже лет так 50... а то и больше :)))).
Имеет не просто смысл. Это обязательное условие современной автоматизации.
Тут важен опыт? У вас был опыт развёртывания системы с более чем 100 серверами 1С и SQL? Судя по тому что вы пишите про RDP нет...
А я вот как раз ищу людей которые с этим уже сталкивались. Пока что человек с реальной практикой не совсем с нами согласен (36)
(39) Замечание интересное "Ну ну... И сканеры в режиме COM и кассы, и всё так замечательно работает на медленном и-нете."
Попробуйте ознакомиться с "WTware — операционная система тонких клиентов"
WTware работает со всеми известными RDP серверами. Мы проверяли службы терминалов Windows Server от 2000 до 2012R2, Hyper-V VDI, удаленное управление Windows, xrdp на Linux, Mac Terminal Server, XP Unlimited.
WTware работает на любом компьютере, если у него есть x86-совместимый процессор. На новых неттопах Intel NUC, на тонких клиентах HP или ТОНК, на обычных офисных компьютерах. И на тех старых Celeron, которые вы списали в позапрошлом году, тоже будет работать.
Работа с USB COM без проблем с любым оборудованием.
Попробуйте ознакомиться с "WTware — операционная система тонких клиентов"
WTware работает со всеми известными RDP серверами. Мы проверяли службы терминалов Windows Server от 2000 до 2012R2, Hyper-V VDI, удаленное управление Windows, xrdp на Linux, Mac Terminal Server, XP Unlimited.
WTware работает на любом компьютере, если у него есть x86-совместимый процессор. На новых неттопах Intel NUC, на тонких клиентах HP или ТОНК, на обычных офисных компьютерах. И на тех старых Celeron, которые вы списали в позапрошлом году, тоже будет работать.
Работа с USB COM без проблем с любым оборудованием.
(39) Замечание "Тут важен опыт? У вас был опыт развёртывания системы с более чем 100 серверами 1С и SQL? Судя по тому что вы пишите про RDP нет... "
Автоматизация сети АЗС на базе УПП - не в счёт. Вас тут пугнули 50-ю километрами. А у меня разброс точек - 2 области.
Только не совсем понятна причина "Развешевания" ярлыков.
Разве Вы объявили кастинг? или экзаменуете посетителей форума?
Автоматизация сети АЗС на базе УПП - не в счёт. Вас тут пугнули 50-ю километрами. А у меня разброс точек - 2 области.
Только не совсем понятна причина "Развешевания" ярлыков.
Разве Вы объявили кастинг? или экзаменуете посетителей форума?
(42) CaptainMorgan, (41) CaptainMorgan, (40) CaptainMorgan,
Уважаемый, прекратите спамить, все давно слышали и про
Все эти технологии редко используются нормальными людьми для автоматизации удаленных торговых точек, требование COM порта к ping 10мс при пробросе никто не отменял.
Уважаемый, прекратите спамить, все давно слышали и про
WTware
и RDS НА ОСНОВЕ СЕАНСОВ В WINDOWS SERVER 2012 R2
и RemoteApp
Все эти технологии редко используются нормальными людьми для автоматизации удаленных торговых точек, требование COM порта к ping 10мс при пробросе никто не отменял.
(1) comol, Был опыт поддержки РИБ из 160 узлов (не Розница, но думаю все аналогично).
Штатно обмен работает нормально, но сама выгрузка вешает центральный узел.
Если нужна синхронизация в рабочее время, то нужен отдельный узел именно под синхронизацию с остальной сотней, в котором никто не будет работать
Сервер в узлы ставить необходимости не вижу. Зависит, конечно, от количества рабочих мест. Основное преимущество SQL перед файловой это надежность. Для узлов РИБ надежность не сверх критична. На несколько рабочих мест достаточно файловой+веб-сервер+тонкий клиент.
3. Тонкий клиент в смысле к удаленной базе? Опыта не было, но я бы так не рисковала. Любая проблема с сетью и продажи остановились.
Штатно обмен работает нормально, но сама выгрузка вешает центральный узел.
Если нужна синхронизация в рабочее время, то нужен отдельный узел именно под синхронизацию с остальной сотней, в котором никто не будет работать
Сервер в узлы ставить необходимости не вижу. Зависит, конечно, от количества рабочих мест. Основное преимущество SQL перед файловой это надежность. Для узлов РИБ надежность не сверх критична. На несколько рабочих мест достаточно файловой+веб-сервер+тонкий клиент.
3. Тонкий клиент в смысле к удаленной базе? Опыта не было, но я бы так не рисковала. Любая проблема с сетью и продажи остановились.
1C использовать только как бэк-офис, фронты - свои РМК, типа Фронтола - самое оно! И безопасно (так как файлы можно заливать по защищенному протоколу, либо через почту), и довольно надежно (розница не зависит от состояния сервера, провайдера, магнитных бурь на Солнце и т.п.). Для инвентаризации можно использовать ТСД: провел инвентаризацию, слил файл - готово! Количество точек (в Вашем случае - около 100) будет влиять только на то, как "ворочается" сам сервер.
80 магазинов. В каждом своя розница, правда 1.0, дописанная. Обмен идёт по веб-сервисам, утром. Центральная на серваке в облаке - всё работает, всё хорошо.
Причём, компы в точках не жутко сильные, продавцы не жалуются.
Само собой с таким обменом нужен широкий канал, но нам 1Мб хватает.
Причём, компы в точках не жутко сильные, продавцы не жалуются.
Само собой с таким обменом нужен широкий канал, но нам 1Мб хватает.
возможные требования влияющие на выбор ПО:
1. автономность кассы, требуются ли остатки по складу онлайн (в магазине/центре)
2. функциональность РМК (скидки, бонусы и.т.д.)
3. используемое торговое оборудование
из вариантов которые встречал/настраивал больше
"снежинка" (с сервером в магазине, автономными кассами)
Атолл (центр 1С УТ), магазины атолл с общей базой
SetRetail (большая продуктовая розница) win MSSQL + MSDOS
Звезда
АвторМаг на 7.7
Централизованно
сервер терминалов с 1С Розница
все нормально, стабильно работает, вопрос в том что вам (вашему ИТ отделу) удобнее и дешевле будет администрировать
форматы обмена между узлами везде разные со своими плюсами и минусами
1. автономность кассы, требуются ли остатки по складу онлайн (в магазине/центре)
2. функциональность РМК (скидки, бонусы и.т.д.)
3. используемое торговое оборудование
из вариантов которые встречал/настраивал больше
"снежинка" (с сервером в магазине, автономными кассами)
Атолл (центр 1С УТ), магазины атолл с общей базой
SetRetail (большая продуктовая розница) win MSSQL + MSDOS
Звезда
АвторМаг на 7.7
Централизованно
сервер терминалов с 1С Розница
все нормально, стабильно работает, вопрос в том что вам (вашему ИТ отделу) удобнее и дешевле будет администрировать
форматы обмена между узлами везде разные со своими плюсами и минусами
У меня в данный момент более 150 магазинов в РИБ на самописной базе. Хотим переходить на Розницу 2.2
Магазины маленькие. Ассортимент 200+ товарных позиций. Продаж в день максимум 200 чеков.
В каждом магазине один ПК и одна касса. В качестве ПК обычные ноутбуки.
Самые частые проблемы это падение производительности. Когда в базе всё начинает происходить ооооочень медленно. Спасает выгрузка/загрузка.
Поломки узлов. Вылетают при обменах с ошибкой "Ошибка формата потока". При чём как я понял проблема с объектом "план обмена". База работает, но при попытке сделать обмен или ТиИ вылетает в ошибкой. Восстанавливаем выгрузкой нового узла. Но такие проблемы не сильно часто бывают.
Ещё проблемы бывают при обновлениях узлов. Либо конфигурация перестаёт принимать обновление. Либо после обновления база начинает очень сильно тормозить, либо вообще зависать на запуске или зависает на получении файла обмена после обновления. Спасает выгрузка/загрузка.
Чем меньше обновлений тем проще работать :)
Обмен с одним магазином проходит за 40-70 секунд. Но у нас проблема с самим обменом в нём очень много мусора. Который что бы вычистить нужно много чего переделывать. А так реально его сократить раза в 2-3.
Вообще нюансов очень много. От тех поддержки всей сети до организации работы.
Магазины маленькие. Ассортимент 200+ товарных позиций. Продаж в день максимум 200 чеков.
В каждом магазине один ПК и одна касса. В качестве ПК обычные ноутбуки.
Самые частые проблемы это падение производительности. Когда в базе всё начинает происходить ооооочень медленно. Спасает выгрузка/загрузка.
Поломки узлов. Вылетают при обменах с ошибкой "Ошибка формата потока". При чём как я понял проблема с объектом "план обмена". База работает, но при попытке сделать обмен или ТиИ вылетает в ошибкой. Восстанавливаем выгрузкой нового узла. Но такие проблемы не сильно часто бывают.
Ещё проблемы бывают при обновлениях узлов. Либо конфигурация перестаёт принимать обновление. Либо после обновления база начинает очень сильно тормозить, либо вообще зависать на запуске или зависает на получении файла обмена после обновления. Спасает выгрузка/загрузка.
Чем меньше обновлений тем проще работать :)
Обмен с одним магазином проходит за 40-70 секунд. Но у нас проблема с самим обменом в нём очень много мусора. Который что бы вычистить нужно много чего переделывать. А так реально его сократить раза в 2-3.
Вообще нюансов очень много. От тех поддержки всей сети до организации работы.
(26) comol,
Узлы да файловые. Центральная на СУБД.
Обмен два раза в сутки. Утром и ночью. Нам чаще не надо. Но в принципе руками можно хоть каждые пять минут делать. Если цены меняются или какое нибудь ЧП типа не правильного штрих кода и тд. То там руками делаем обмен и на точке продавец жмёт кнопку и обменивается.
Обновление сделано через запрет работы в программе если пришло обновление. На раб столе ярлык который запускается пользователем и выполняется обновление.
У вас файловые? 8.3? Обмен раз в сколько времени?
Узлы да файловые. Центральная на СУБД.
Обмен два раза в сутки. Утром и ночью. Нам чаще не надо. Но в принципе руками можно хоть каждые пять минут делать. Если цены меняются или какое нибудь ЧП типа не правильного штрих кода и тд. То там руками делаем обмен и на точке продавец жмёт кнопку и обменивается.
Обновление сделано через запрет работы в программе если пришло обновление. На раб столе ярлык который запускается пользователем и выполняется обновление.
Поделюсь пока 1С висит :)
Бооольшой ритейл, по СНГ и части восточных европейцев.
В торговых точках 1С:Розница файловая. 1-4 человека в смену 1-2 смены.
Узловые сервера 1С:Розница на sql в зависимости от региона от 4 до 30 точек, заливаются по закрытию кассовой смены 1-2 раза в день.
Региональные сервера 1С:Розница sql до 50 узловых серверов, обмен раз в сутки. Все успевают залиться к 3 утра по Минску.
Москва 5 серверов 1С:Розница sql 2-5 региональных серверов, обмен раз в сутки. Заливаются к 6 утра.
Рабочая база 1С:Торговля sql заливаются к 10 утра.
В 11 справка о продажах на столе генерального.
Как то так :)
Бооольшой ритейл, по СНГ и части восточных европейцев.
В торговых точках 1С:Розница файловая. 1-4 человека в смену 1-2 смены.
Узловые сервера 1С:Розница на sql в зависимости от региона от 4 до 30 точек, заливаются по закрытию кассовой смены 1-2 раза в день.
Региональные сервера 1С:Розница sql до 50 узловых серверов, обмен раз в сутки. Все успевают залиться к 3 утра по Минску.
Москва 5 серверов 1С:Розница sql 2-5 региональных серверов, обмен раз в сутки. Заливаются к 6 утра.
Рабочая база 1С:Торговля sql заливаются к 10 утра.
В 11 справка о продажах на столе генерального.
Как то так :)
(29) comol, сначала были попытки на ms express в торговых точках, потом попытки на postgree, файловая проще в обслуживании неквалифицированным персоналом и виндой.
Если есть персонал обученный, то и сервер и sql вполне встанут и будут жить.
Если есть персонал обученный, то и сервер и sql вполне встанут и будут жить.
(28) babys, прошу прощения выгрузку не расписал :)
Поставки централизованные через несколько 3PL операторов, в течение дня пересылка доков на 3PL-ра, получение подтверждения о формировании развозки.
В зависимости от уровня 3PL глобальный, региональный, местный выгрузка в соответствующие филиалы глобальный - центральная бухия, региональный - региональный маркетинг.
Региональный маркетинг _ОБЯЗАТЕЛЬНО_ перед отправкой развозки в торговую точку выгружает на уровень узлового сервера 1С:Розница.
Каждые 2 часа рабочего времени торговой точки 1С:Розница лезет в узловой и забирает поставки.
Подтверждение о получении товара в торговую точку поднимается только до регионального маркетинга. После обработки в регионе уже по цепочке серверов 1С:Торговля
поднимается в Москву.
Ну как-то так.
Поставки централизованные через несколько 3PL операторов, в течение дня пересылка доков на 3PL-ра, получение подтверждения о формировании развозки.
В зависимости от уровня 3PL глобальный, региональный, местный выгрузка в соответствующие филиалы глобальный - центральная бухия, региональный - региональный маркетинг.
Региональный маркетинг _ОБЯЗАТЕЛЬНО_ перед отправкой развозки в торговую точку выгружает на уровень узлового сервера 1С:Розница.
Каждые 2 часа рабочего времени торговой точки 1С:Розница лезет в узловой и забирает поставки.
Подтверждение о получении товара в торговую точку поднимается только до регионального маркетинга. После обработки в регионе уже по цепочке серверов 1С:Торговля
поднимается в Москву.
Ну как-то так.
(31) comol, к сожалению нет, мы суппортеры, "вам не надо" :)
Я так прикидывал, точек около 800 в Мск. Чеки - ну не знаю, я там редко бываю, но позиций вряд ли больше 5, скорее 2-3 и это я думаю 60% всех чеков.
Объем чеков за смену, ну скажем по той точке что рядом со мной, 1 чек в 20 минут, за смены по 7 часов 3*7=21 чек.
Я так прикидывал, точек около 800 в Мск. Чеки - ну не знаю, я там редко бываю, но позиций вряд ли больше 5, скорее 2-3 и это я думаю 60% всех чеков.
Объем чеков за смену, ну скажем по той точке что рядом со мной, 1 чек в 20 минут, за смены по 7 часов 3*7=21 чек.
Не удивлюсь, что про ЭТО Вы даже не слышали.
Еще можно RDS НА ОСНОВЕ СЕАНСОВ В WINDOWS SERVER 2012 R2
Приложения RemoteApp представляют собой программы, удалённый доступ к которым предоставляется с помощью служб удалённых рабочих столов, но выглядят они так, будто это локальные приложения. Проще говоря, приложение RemoteApp представляет собой доступ к удалённому рабочему столу, ограниченному одним приложением. Однако, несмотря на формулировку выше, пользователь может запускать несколько приложений или несколько экземпляров одного и того же приложения в одном сеансе.
Еще можно RDS НА ОСНОВЕ СЕАНСОВ В WINDOWS SERVER 2012 R2
Приложения RemoteApp представляют собой программы, удалённый доступ к которым предоставляется с помощью служб удалённых рабочих столов, но выглядят они так, будто это локальные приложения. Проще говоря, приложение RemoteApp представляет собой доступ к удалённому рабочему столу, ограниченному одним приложением. Однако, несмотря на формулировку выше, пользователь может запускать несколько приложений или несколько экземпляров одного и того же приложения в одном сеансе.
ну не фронтол же внедрять и файлами по почте обмениваться, сорри, у нас более серьёзное решение.
ещё один крутой совет. посчитайте стоимость 200 instans-ов SQL Standart :)))))))
Чем то мне настоящая ситуация напоминает возмущение попрошайки на паперти, когда ему вместо бумажных денег, в шапку кинули горсть мелочи.
Нет?
Да СОМ порты при пробросах работают крайне медленно - увы такой протокол оборудования. Чуть улучшает ситуацию если использовать сторонние программы для проброса СОМ порта через Езернет, но это дело такое на любителя.
Про розницу и много точек - пока варианта кроме как центральный узел на СКЛ и быстром серваке, что ыб успевать делать обмены , все РИБы стартуют по регламенту в одно время, выполняются от имени одного пользователя, один за другим. Промежуток запуска выбираем методом разумного )
У нас поднимается сеть около 70 точек. РИБ по магазинам. Пока работают 11 точек, интервал обмена 1500с.
Как будет когда точек станет 50 и бала подрастет пока не знаю... буду с вами обсуждать ))
Про розницу и много точек - пока варианта кроме как центральный узел на СКЛ и быстром серваке, что ыб успевать делать обмены , все РИБы стартуют по регламенту в одно время, выполняются от имени одного пользователя, один за другим. Промежуток запуска выбираем методом разумного )
У нас поднимается сеть около 70 точек. РИБ по магазинам. Пока работают 11 точек, интервал обмена 1500с.
Как будет когда точек станет 50 и бала подрастет пока не знаю... буду с вами обсуждать ))
(46) TODD22, это интервал запуска регламентного задания для обмена.
сами обмены с каждым магазином проходят примерно по 1-2 минуты. База пока файловая, скоро переедет в скуль.
Так часто - клиенту надо видеть в центре все чеки с магазинов с интервалом минут 15-20... Так что пока сделали так.
Основная проблема была в зависании регламентных заданий. Или подвисало какое то, и весь механизм вставал (к примеру пришлось вообще отключить обновление списков банков), или какой то сбой внутри 1С, и задания не выполнялись - писали мол сеанс не найден или завершен..
Решилось запретом из комндной строки запуска у всех запускать задания, а одному сеансу разрешено. Он и работает и под ним все выполняется.
Платформа 8.3.8. розница 2.2.2.20
сами обмены с каждым магазином проходят примерно по 1-2 минуты. База пока файловая, скоро переедет в скуль.
Так часто - клиенту надо видеть в центре все чеки с магазинов с интервалом минут 15-20... Так что пока сделали так.
Основная проблема была в зависании регламентных заданий. Или подвисало какое то, и весь механизм вставал (к примеру пришлось вообще отключить обновление списков банков), или какой то сбой внутри 1С, и задания не выполнялись - писали мол сеанс не найден или завершен..
Решилось запретом из комндной строки запуска у всех запускать задания, а одному сеансу разрешено. Он и работает и под ним все выполняется.
Платформа 8.3.8. розница 2.2.2.20
(47) vacony,
Сильно часто обмен лучше не делать. При обмене таблицы блокируются. Потом чеки могут не проведённые болтаться...
Что то мне кажется на 70 магазинах всё это дело помрёт. У меня 150 магазинов, на самописной пока конфе... обмен с одним магазинов 40 сек. Со 150 идёт 2 часа...
Я пошёл другим путём выделил в отдельную базу сервер бонусов. И в него же закидываю продажи через web сервисы. Вернее это я ещё доделываю. Но думаю это решит вопрос с оперативностью получения данных по продажам в офисе. А сами обмены буду раз-два в сутки запускать....
Так часто - клиенту надо видеть в центре все чеки с магазинов с интервалом минут 15-20... Так что пока сделали так.
Сильно часто обмен лучше не делать. При обмене таблицы блокируются. Потом чеки могут не проведённые болтаться...
Что то мне кажется на 70 магазинах всё это дело помрёт. У меня 150 магазинов, на самописной пока конфе... обмен с одним магазинов 40 сек. Со 150 идёт 2 часа...
Я пошёл другим путём выделил в отдельную базу сервер бонусов. И в него же закидываю продажи через web сервисы. Вернее это я ещё доделываю. Но думаю это решит вопрос с оперативностью получения данных по продажам в офисе. А сами обмены буду раз-два в сутки запускать....
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот