Задача такая. Есть торговый холдинг.
В нем 16 подразделений территориально разнесенных по всей России.  Каждое подразделение подключено к инету по оптоволоконному каналу. Всего предполагается около 140 одновременно подключенных пользователей с возможностью расширения до 300.
Каждое подразделение холдинга торгует номенклатурой, которой нет у других подразделений. Всего номенклатурных позиций около 50 000. За каждым подразделением закреплено от 2000 до 30 000 номенклатурных позиций.
Каждая позиция продается примерно 25 раз/год, т.е. всего 1 250 000 реализаций/год.  Подразделения холдинга должны видеть деятельность друг-друга опционально, в соответствии с правами пользователей.
Некоторые процессы (например планы продаж) будут спускаться в подразделения из головной организации.
Теперь собственно вопрос. Как построить такую систему на 1С 8.2 ?  Предлагаются следующие варианты.
1.    Кластер серверов. Терминальный доступ к кластеру. Толстые клиенты.
2.    Сервер. Тонкие клиенты. (отдельный вопрос насколько комфортно будет пользователю при работе со формами списка, т.к потребуется отбор по многомиллионному списку документов например )
3.    Распределенная база данных.
Какой из этих вариантов можете посоветовать в плане построения комфортно работающей для пользователя системы (это на первом месте) и минимизации времени разработки приложения(это как плюс)

можете считать меня ретроградом, но я-бы выбрал п.3  :)

SAP

Ну если хорошие каналы связи то однозначно 1. Если каналы связи плохие, то 2. Если совсем плохие, то 3.

(1) 3 не подойдет для задачи

для терминальной работы каналы не надо толстые...
бюджет каков? если 3-х значная цифра мильёнов то (2), иначе на 1с франч крупный возьмётся

3
От одного сервера, не будет зависеть работа всех подразделений

з.ы. у нас тоже 15 филиалов, РИБ

Кластер серверов, Тонкие клиенты.
в ответ на "отдельный вопрос" - весь отбор в списках все равно идет на сервере  :)

(0)все три варианта рабочие
в чем больше компетенций то и ваяйте

(7) + правда внедрялось когда не было тонких клиентов впринципе. щас переделывать структуру системы никто не будет уже

Такие обороты потянут и клюшки :-))
"крупный холдинг возьмет в лизинг степлер..."

РИБ

1+2

Тут вопрос стоит скорее в принципиальной осуществимости такой темы. Просто никогда не видел как 1С работает на таких объемах. Очень интересно например, с какой скоростью 1С отберет из 6 000 000 реализаций те 200 000 которые должен видеть филиал.
1. При формировании динамического списка на тонком клиенте.
2. Задействовав стандартные отборы на толстом клиенте.

Какого порядка будут тормоза ? Они будут вписываться в разумные рамки ? :) Я лично ниразу не видел 8-ку работающую на огромных объемах. Вообще она их поднимет вот в чем вопрос ?  С распределенной БД там все ясно. Понятно что обхемы она потянет. Но поддержка будет стоить дорого.

с рибом косяк
>>Подразделения холдинга должны видеть деятельность друг-друга опционально, в соответствии с правами пользователей

(9)+ ну вы понимаете что в любом случае нужно будет "железо"

(14) регистры принципиально не планируешь?

(13)+1

я за (1)+(2)

(11) У меня больше обороты на клюшках - всё летает.

(1) Как в РИБ сделать вот это - Подразделения холдинга должны видеть деятельность друг-друга опционально, в соответствии с правами пользователей, качать всем центральную базу? А по безопасности в задании как?

(14)на нормальном железе и с нормальными руками 200-300 пользователей впринципе чувствуют себя комфортно

(15)+ Не заметил

>acsent с рибом косяк
>>Подразделения холдинга должны видеть деятельность друг-друга опционально, в соответствии с правами пользователей

совершенно верно, спасибо за комментарий. Регистры планирую накоплений и сведений.

(23) уже два варианат осталось, теперь исключить один из двух осталось

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

(25) походу из серии чтобы было ))

если не обмены
то единая база потребует построения отказоустойчивой системы
(кластера, резервные сервера, дублирующая бд и прочее)

Если будет выбрано типовое решение 1С, то по варианту 2 скорее всего - нужен будет конкретный допил самой 1С, а это бюджет, бюджет какой?

(27) и если вариант 1, то плюс к серверам 1С нужны сервера терминалов, а это бюджет...

(0) п.1 выльется в копеечку, кроме того 1С запиливает конфы на УФ, к тому времени как внедрите на  толстых формах через терминал, придется все равно запускать на УФ. Так что я за 3

(30) за п.2, извините

(29) не только терминалы, но и еще субд. Трехзвенка же ж.

(2) За бюджет САПА они проведут оптиковолокно от этих самых филиалов ;-0

(32) ну не файловый же

(30) как показывает практика на именно "Больших" системах уже не обновляют до типового функционала, система становится самодостаточным организмом и всё нужное в неё скармливается програмистами поддержки, а они будут нужны полюбому

>SunFox
По безопасности. Базовая структура иерархия ... тоесть эти филиалы они еще и не равнозначны. Соответственно юзер должен видеть вниз по иерархии, а то что выше видеть не должен. Например продажник филиала видит и анализирует продажи только филиала. Продажник региона - всех подчиненных филиалов. Центральный продажник - вообще видет и анализирует все продажи. Но не дай бог чтобы кто-то увидит выше себя. Будет очень плохо

(30)+ (0) начинай размещение вакансий от 100 тыщ

(36)  с такими желаниями вариант 3 уж точно не нужен

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

В критических случаях планируются временные объединения трудовых рессурсов филиалов. Аля один взял на время на себя функции нескольких. Оптимизация ...

> SunFox и если вариант 1, то плюс к серверам 1С нужны сервера терминалов, а это бюджет...
Тоесть по бюджету вариант тонким клиентом будет выгодней ?

Функционал вообще не типовой. Будет писаться с нуля. Посему и стоит вопрос выбора базиса на котором это все делать

как вариант всех кто чтото должен видеть(а их полагаю не много) в терминал

(40) нет, нужен расчет,  с учетом дальнейшей поддержки такой системы

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

>SunFox
Бюджет 2 программиста по 100 рублей на год.

(45) это для поддержки?

(36)(41) тогда да, с нуля дак на тонком пишите всё, РИБ не подходит
(45) бугага) оптимисты ппц. не взлетит, чесно.

поддержка - 2 програмиста по 100 рублей на всю жизнь системы. это раз.
внедрение - мильёны на 2-3 года.

>Maxus43 слишком гибко права надо настраивать, даже хз что за критерий брать тут...
Я вижу что базовый функционал будет определяться ролью (т.е. доступ к классам). А доступ к экземплярам класса уже должен регламентироваться аддитивно галочками в соответсвующих узлах иерархии.

>Maxus43 поддержка - 2 програмиста по 100 рублей на всю жизнь системы. это раз.
>внедрение - мильёны на 2-3 года.

Про поддержку и внедрение ничего не скажу, похоже разумно :) Ну а вот разработку хотелось бы втиснуть мильена в 3 на 2 года.

С нуля писать это жесть. Интересно, кто допускает чукчей-писателей до таких проектов.

(51)+100500 проще из типовой не нужный функционал удалить

(50) это без железа на уже продуманые и описаные бизнес процессы, составленное ТЗ. Кто это всё делает без зарплаты будет?) 2 года... это только 2,5 программиста по 100 тыщ.

только торговля там? бухня, производства нет? УТ 11 пилить, жёстко жёстко

>Злобный Фей С нуля писать это жесть. Интересно, кто допускает чукчей-писателей до таких проектов.
Тема торговли поднята условно, для того чтобы примерно показать масштабность и частично суть задач.

>Maxus43 только торговля там? бухня, производства нет? УТ 11 пилить, жёстко жёстко

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

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

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

(50) к 3 млн. смело нолик дописывай

Т. е если говорить о конценцусе, то я так понимаю вердикт такой: Кластер серверов. Тонкий клиент. На таких объемах сильных тормозов при формировании динамических списков, построении отчетов и пр. быть не должнно (для убыстрения отчетов можно сделать кубы). Принципиально (на уровне возможностей платформы) эта задача вполне реализуема (по мнению пользователей форума :) ).
Таких систем из написавших никто кроме  <NS> не пользовал. По словам <NS> у него все летает и на больших оборотах.

>Vladuha к 3 млн. смело нолик дописывай
Ты забыл что живеш в стране чудес :) 7 лет назад я бы с тобой согласился ...

В сравнимой по параметрам организации (подразделений больше, товаров меньше, пользователей сейчас примерно 120-130) работаем по 1. Не утверждаю, что так оптимально - начинали в 2005 г. с 8.0.
2 терминальных сервера, сервер 1С и сервер СУБД.

(61) БОг в помощь

(41): А почему именно 1С?
Почему на на JAVA и на базе Postgre, например?
Быстро, дёшево, мощно...

(64) Убери одно слово, будет похоже на правду

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

>DeiMos  А почему именно 1С?

На Java планируется отдельный продукт, который будет поддерживать до 1000 одновременных подключений. Решать определенные задачи и экспортировать данные в управленческий контур 1С. 1C выбирается по соображениям легкости саппорта и приемственности разработок. Кроме того, по 1С много специалистов совмещающих в себе предметников и программистов.

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

>Михаил Козлов
Спасибо за конкретику !

(67) "Кроме того, по 1С много специалистов совмещающих в себе предметников" - зачем вам предметники, если у вас не торговля, не производство и не бухия

(68) Ну ок, Резервирование поддерживать должны?
ЗЫ Я так понимаю лям реализаций, это планимруемая пиковая нагрузка
Работа круглосуточная, будет ли сборка и отправка грузов в этой программе или в другой?

(0) Чёто не пойму в чём подвох? 25 реализаций в год? 50000 позиций и в чём проблемы?
Единственно судя по количеству реализаций, непонятно что за продукция. Наверно продажу народных поделок решили автоматизировать, ну там глинянные свистки, деревянные ложки и пр.

(66) Железо-то купить можно...
(67) " Кроме того, по 1С много специалистов совмещающих в себе предметников и программистов." - так почему бы вам не пригласить специалистов?

>DeiMos
На Java ,будет реализовано нечто вроде массового анкетирования. С Мультимедийными вставками. Но это отдельная задача на через год :)

LOTUS

>Krendel работа дневная. возможны регламентные перерывы... железо купим когда получим программный продукт ...

(76) Тогда проблем вообще не вижу, оставляет 2 регистра (с учетом резервирования) под реализацией в пики, и пилите проводки(движения по регистрам), во время простоев оборудования

> GreyK
Подвох в том, что каждый филиал должен видеть в этой единой базе только свою номенклатуру, только свою реализацию ... только свое ... Тоесть конечному клиенту для построения любой формы списка потребуется делать отбор в сотни тысяч записей из десятка миллионов .. и так почти на каждой транзакции. Открыл список документов ... отфильтровалось ... справочников ..туда же..

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

(78) Базовые права доступа не взлетят я так понимаю на видимость? ;-)

(78) может вы уже позовете спецов по 1С ? ))

(80) Как только лизинг степлера погасят, позовут. Если дырокол в аренду не возьмут...

>Турист Ну я думал как раз здесь такие найдутся :)
я и сам с 1С уже лет 8 дружу. Но вот просто не приходилось на нем делать всяких годзил :) А теперь вот приходится :)

(82) Купите платформу, напишите 4 генератора:
Справочника контрагентов+договора
Справочника номенклатуры
Реализаций
ПОступлений

И сделайте лям отгрузок по ляму контрагентов, а потом откройте журнал реализации

цена вопроса, если это УТ 12-к, 64к серверный ключик,+ работа спецов еще оценю в 100-ню

(82) ну и толку от твоей дружбы? некоторые вон, уже 10 лет на 7-ке сидят, но они ведь не лезут мегаконфы на 8.2 писать.
з.ы. сходили бы уже на курсы для начала ))

(83) Ему с фильтрацией надо... :-)))

(85) Ну а чего там такого "мега"? :-)

(86) С фильттрацией он даже пхп подвесит

(87) ну для меня, ничего "мега" здесь нет. в вот судя по тому что у (0) такие вопросы возникают ))

(87) Там мега айсберг с распределением затрат по этим подразделениям, и бюджетированию и казначейству

А еще скорее всего есть задача по управленческой отчетности и прочей хни

серверы в датоцентр,упр.база и может взлетит впринципи около 50 филиалов тянет

(92) Ты спугнул автора ;-(

я так понимаю ТС сбежал? ))

з.ы. кто-нибудь разгадал чем контора ТС банчит? ))

судя по "Подразделения холдинга должны видеть деятельность друг-друга опционально, в соответствии с правами пользователей."

Это несколько бизнесов купи продай срощенных в одном юр лице

А вот такое "Каждая позиция продается примерно 25 раз/год, т.е. всего 1 250 000 "

я даже не могу се в страшном сне представить, как одна позиция продается 25 раз за год?

(96) прикол в том что этих позиций 50000 ))

(78) Ну не будут же ваши пользователи скроллить все миллионы записей явно?
Есть такое подозрение, что им не нужно выводить данные за прошлые месяца или кварталы. Или нужно отбирать по какой-то позиции или группе позиций.
Действительно делается элементарный тест с генерацией данных, индексируется поле "Филиал" и прочие нужные поля отбора и делается тестовый отбор.
Кстати, скорее всего данных в результате отбирается вовсе не миллион, а ровно столько, сколько влазит в окно. Я пока только разбираюсь с 8.2, но если они сделали по другому и на клиента грузятся все миллионы записей, то значит 1С должна умереть как организация. Но я о них лучшего мнения. Опция "Динамическая подгрузка" намекает на то, что так и есть.

(0)
А если так:
РИБ, каждый пользователь работает в своей базе.
Для просмотра консолидированной информации создать "тонкий" интерфейс (отчеты) к центральной базе распределенки.
Минусы:
- теряется оперативность получения общих данных.
- необходимость работы в двух базах.

(99) Ты забыл что это надо бы как-то обслуживать, и 5 баз обслуживать поболе будет

(100)
А одну базу можно и не обслужить вовсе...
Я думаю, что админы все равно какие-то имеются во всех 16 местах. "Самые главные" специалисты могут работать и по удаленному администрированию.
А вот железа по-круче в разы по количеству баз больше надо - это да.

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

1250000 реализаций в год , если по позиционно это не так уж много , у нас в месяц около 300 000 по центральному подразделению холдинга , все подразделения вместе около 500 000 , семерка тащила , восьмерка тащит .
Подразделения работают либо полностью автономно (независимо) , либо п.1 по мере появления надежных каналов связи .

>Sewace
Нормальный саппорт есть не во всех филиалах.
Для РИБ помимо проблем синхронизации и обновления, вижу также необходимость закупки дополнительных 16 лицензий 1С =168000+ пусть даже 16 обычных компов под базу X 15000 рублей=240000. Итого РИБ будет на старте дороже на 400 000 р.
Основной плюс РИБа вижу в безопасности (филиал видит себя и не видит других).

>Maxus43
Я уже склоняюсь к тому, чтобы пожертвовать "Подразделения холдинга должны видеть деятельность друг-друга опционально". С правами дей

действительно слишком мудрено ...

>Humandra, Krendel
Согласен, надо будет завести тестовую базу с большими оборотами и погонять ее на тонком клиенте ...

Еще такой вопрос. Если рассматривать как инструмент разработки 8.2 управляемые формы, имеются ли там средства рахзработки, позволяющие ограничить пользователю область видимости в пределах экземпляров объекта ? Собственно чтобы сходу, на этапе описания конфигурации ввести разграничение по филиалам.
Или придется таки программировать ручками обработку на сервере всех операций обращения к БД в зависимости от филиальности пользователя ?

(106) Почитай про RLS

СоСолнечный лис, спасибо ! :)

>SunFox
В RLS порадовали неожиданные эффекты, особенно:

а) в справочнике с автонумерацией невозможно ввести новый элемент (поле Код недоступно для чтения, а система не может прочитать максимальный код, чтобы увеличить его на 1 и присвоить код новому элементу).

Книга знаний: v8: Права пользователей в 1С:Предприятии 8.0

>SunFox
Ну, понятно что можно решить филиальными префиксами.

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

(110) В типовых все есть - по организациям, подразделениям, складам.
Не нужно велосипед изобритать.

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

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

(114) придется-придется... еще как придется... хотя бы галочки "динамическое чтение" снимать

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

(0) 1250000 реализаций в год -  по одной строке в каждой я так понимаю?
Это то же самое, что 340 реализаций (по 10 строк в каждой) ежедневно.
И это что, "объем"? Не смешите мну.

(116) да хз, кое-где и велосипед... в той же ут 11 полностью переписал подбор, потому что штатный тупил как скотина...

Для административно нормально организованного холдинга совсем не обязательно сливать все в одну базу через РИБ , или вообще вести учет централизовано . По налоговой отчетности подразделения могут отчитываться независимо . А совокупный анализ можно сводить с намного меньшей степенью детализации (типа в фин. анализе и бюджетировании) или совсем не в 1С , например в какой нибудь OLAP ситеме

Обсужение из серии "Какого цвета соски у сферического коня в вакууме"..

(0) Обороты серьезные для торговой компании, но не скзать что это за пределами возможностей 1С. Решайте используя УРБД, это самый надежный и проверенный временем способ, за оптимальные деньги. Вести торговлю через удаленный доступ, таит в себе гораздо больше опасностей, чем удаленно управлять серверами с распределенными базами.
Приходилось поднимать и более крупные проекты, примерно вашей специфики. С типовыми не рискнул связываться, слишком они тяжелые и неповоротливые, а еще приходится сложно и долго допиливать, чтобы система удовлетворяла взыскательным требованиям. Вообщем, в результате все вылилось в вот это http://1c-yy.ru/
Удачи Вам в проекте.

(119) да в олап из того же 1с-а выливать - файл - дтс - скл бд - а оттуда экселем забирать

(121) Для серьезной торговой компании не такой уж большой оборот , кстати в (102) ошибся с числами почти на порядок :) По центральному подразделению за год 21 млн продаж , это 1.7 млн строк в месяц . Нормально 1С тащит , без особых проблем . Филиалы правда работают как обособленные подразделения , в своих базах локально. Выгрузка идет в централизованную систему фин анализа с детализацией до канала сбыта , и брэнда , контрагенты так же укрупнены ,детализации до номенклатуры нет , до торговой точки то же нет, в OLAP идет детализация до номенклатуры и торговой точки , но в кубах не учитываются затраты , чисто детализированный анализ продаж и маржи (сводный) . Подразделения выгружаются с несколько меньшей периодичностью

А зачем такой изврат на 1С? Мазохизм?

А когда число пользователей через 3 года станет 500?

Не станет :) Сейчас максимальная нагрузка на центральную базу порядка 130 пользователей (перписанная УТ 10.3) , в семерке под 90 сидело и ничего .
Обособленные подразделения в основном на семерке еще сидят , и будут достаточно долго на ней сидеть

А что не изврат ? SAP что ли ? Гыыы . 1С это конструктор SQL запросов и формочек , все вопросы к серверу баз данных

(125) пусть становится. Чего тут извратного? Далеко не самый крупный проект на 1С.

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

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