Всем привет.

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

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

Пути решения:
1. Отдельная база УТ + обмен через КД2.0;
2. Все в одной базе, RLS.

Кто нибудь уже подобный велик делал? Может есть еще путь как можно это реализовать?

http://v8.1c.ru/overview/Term_000000788.htm
мб в тему будет мб нет

2. конечно

1.2) Отдельная база + обмен через HTTP-сервисы.

Админы, прикрутите голосовалку пожалуйста. Чет затормозил.

(2) (3) Можно с аргументами?

+(1) Общие реквизиты здесь однозначно, а не RLS. Но не все данные удастся поделить. Тогда уже RLSом прятать

(3) Это конечно круто. Но тут подводных камней столько, что даже купленный 1С сервер не является аргументом )

Тут ньансов просто миллион, поднять полноценный обмен из УТ->УТ это не просто, там так накручено, там так навинчено, одни скидки перенести из базы в базу эта задачка на 2-3 дня. Хотя что я говорю, перенести справочник Скидки это 15 минут, а вот перенести так что бы акции и скидки заработали полноценно это где то 1-2 дня. Потом надо еще понять как акции выгружать, т.к. они настраиваются на склады, виды карт и номенклатуру. Это сложновастенько выходит. И когда ты понимаешь что все так сложно, то значит ты что то делаешь не так.

А почему не РИБ?

(1) (6) Кака же. Не факт, что будет использован кластерный индекс и получите днищще по производительности.

(7) как будто пилить ризделитель+RLS за полчаса.

С RLS-ом у меня опасения что производительности будет очень мало. У них сейчас в УТ около 90 человек работает, она еле шевелится.

(8) В РИбе насколько я помню нет правил конвертации. А тут в обмене будут метамарфозы, когда ПТиУ - РТиУ, ПКО -> РКО и т.д.

(4) Слева от заголовка ветки кнопка vote

(9) Так говоришь будто использование кластерного это прям бальзам на душу )

(11) ну вот про мутации документов надо было догадаться.
Нормального решения, что бы на калькуляторе и 100500 пользователей и хитрые мутации - не выйдет.
Вариант 1, все остальное рано или поздно выйдет в вариант 1

Чем не устраивает УТ + розница то?

(11) RLS по Организациям не ресурсоёмок
если не включать интеркомпани, то и с учетом проблем не будет
[У них сейчас в УТ около 90 человек работает, она еле шевелится. ]
это плата за оперативность

(0) "общая схема бонусных карт" - накопление бонусов планируется? Сколько покупателей с картами? Бонусы общие по всей сети франчайзи? Нужна будет нехилая отдельная база бонусов с веб-сервисом, в который будут стучаться локальные базы франчайзей.

(15) Раньше была розница, я не застал этот переход, они с Розницы ушли на УТ, больше про розницу не хотят слышать, говорят что проблем у них было много в ней. Да и бонусные баллы и карты лояльности реализованы в Рознице?

(0) > Пожелания заказчика: франчи живут как хотят.

Чё вы тут обсуждаете? Этому требованию соответствует только пункт 1.
Причем даже вряд ли тут нужны планы обмена.

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

Я бы уточнил сначала задачу бизнеса. Что именно означает "живут как хотят".

(19) - Вряд ли франчи захотят показывать всю свою информацию владельцам франшизы.

Для франчей франчедаватель купил сервер 1С, лицензии, поэтому в доступ базы франчей у него будет 24 часа в сутки, 7 дней в неделю и так далее.

-Я бы уточнил сначала задачу бизнеса. Что именно означает "живут как хотят".
Это значит, что они могут расширять ассортимент из баз франчайзи выгружаются документы в базы БП франчей. Документ который будет через мутации выгружаться в нашу УТ установлен, остальное пусть делают как хотят, ну или насколько прав хватит.

Только топикстартер не указал, а что они подразумевают делать, если какая-то часть франчайзи выделится на другой сервер, например. Или по регламентированному учету потребуется ее обособление...

В принципе, я бы выбрал Свой вариант

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

Просто в топике не разъяснено, как у них некая обособленная часть фирмы регистрирует работы розницы, например. Там же все равно и места хранения обособленные и ККМ. Могут быть разные нюансы и потребности.

(21) Можно подробнее, почему по регл учету нужно будет обосолбление? Тут вообще разные юр лица, какая разница как они обособлены или нет?


- Просто в топике не разъяснено, как у них некая обособленная часть фирмы регистрирует работы розницы, например. Там же все равно и места хранения обособленные и ККМ. Могут быть разные нюансы и потребности.

Пока традиционно.
Открытие смены -> Чеки ККМ + Чеки на возврат -> Отчет о розничных продажах.

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

(22) // вообще разные юр лица, какая разница как они обособлены или нет?

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

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

РИБ по организации. Но нужно будет разобраться с бонусными картами, если они печатаются из центра и выдаются на франчи тогда проблем не должно быть если филиалы сами генерируют бонусные карты тогда нужно будет подпилить. Но в этом случае в центре владелец франшизы будет видеть ВСЕ что касается франчей, а это уже не совсем франшиза а обычный филиал.
Если все таки у вас партнерские отношения с франчами и они вам не все должны показывать, то нужно писать свой обмен, а на КД или нет это уже вопрос реализации.

(25) С бонусными есть стратегия.

В центральной базе:
1. Создание в центральной базе HTTP сервиса, который будет передавать сумму накопленных Бонусных баллов.

В Базе Франча:
1. При создании документа ЧЕК ККМ, Отчет о розничных продажах, РТиУ Создается документ Начисление/Списание бонусных баллов, проводки по РС документы продажи не делают;
2. Документ Начисление/Списание бонусных баллов выгружается в центр по плану обмена через правила.

(26) РИБ, думал над рибом, там обмены с закидонами (11)

(28) Не что не мешает дописать РИБ под эти требования, если в центре нужно видеть все что касается филиалов.
Была подобная задача с сетью алкомагазинов. Делали  через КД. Из центра выгружалась только НСИ(товары, цены). И документы реализации из центра в конкретный магазин падали как поступление, бонусная программа была единая, карты выдавались из центра на магазины накопленные бонусы выгружались по всем магазинам. + была одна пустая база филиала(не привязана ни к какой организации) и если открывался новый магазин то им передавали копию этой базы и ее уже настраивали.

(28) резюмирую: твой вариант должен быть хорошим сочетанием из 1 и 2 пункта голосовалки.

Вам все равно будет необходима сводная управленческая по пункту 2, пусть даже без идеального RLS
И все равно будут необходимы средства и способы для обеспечения работ с базами с планом обмена по пункту 1.

(30) На данный момент в нашей базе БОСС хочет видеть следующее:
1. Кому сколько и кода продали;
2. Сколько из проданного оплаченно;
3. Сколько и когда вернули;
4. Сколько вернуть денег за вернутый товар.

Больше ничего из базы франчи он видеть не хочет. Может ошибается.

Как человек, работавший над автоматизацией франчайз сети могу сказать одно.
Если данные хранить в одной базе - все скатиться в сраные костыли.
Если Организация.Наименование = "VIPОрганизация" тогда...
Потому что внезапно окажется, что учет в каждой орге будет разнится, хотите вы того или нет.

(31) А завтра он захочет другое. True story

(33) Да пофигу, я программист, а не фокусник. Если он решит менять свой бизнесс по 100 раз на дню, то пусть готовится много и очень много платить.

(34) Если ты сейчас не продумаешь схему то ничего не запустишь

(35) Браво кеп! Именно поэтому я и думаю, а правильную ли схему придумал.

Заказчик не хочет цветок из конфигураций.
франчи живут как хотят
Вы понимаете, что проблемы начинаются тут.
Как я вижу решение этой проблемы:
Каждому участнику сети вы даете УТ.
Разрабатываете свою уникальную подсистему, вот с этим "общая схема бонусных карт, скидок, цен, и прочего"
Пишете обмены необходимыми данными в рамках своей уникальной подсистемы.
А с остальным функционалом УТ, пусть развлекаются как хотят.
(36) не хамил бы.

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

(38) Ну да, делаешь свою отдельную поставку "уникального" функционала, так будет просто поддерживать, вполне себе рабочая схема.

(38) ну да, сложный. расскажи какой из путей проще?

(39) Вот то что функционал "уникальный" я согласен, уверен как то подобные поделки делаются проще.

(40) Если что то слишком сложно, значит ты что то делаешь не так. Жизнь - приключение, все должно быть легко и просто, как АКМ.

(41) сервисы это же просто. тут получаешь запросы и обрабатываешь их параметры, там пихаешь параметры в запросы и суешь в сервис. все просто, как АКМ.

(42) Давай не будем вдаваться в подробности. На уровне как ты пишешь я сервисы разрабатывать умею. Не решит все вопросы твой сервис. Потому что задача ставится примерно так: нужно гарантированно перенести все движения бонусных баллов. Ключевое слово гарантированно.

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

(44) ну так то там есть ответ на запрос, в котором можно разместить флаг успешности исполнения и описание ошибки.

(43) а со стороны отправки городишь очередь отправки и регламент по отправке.

Лан, что бы не резало глаза, можно навтыкать кучу сервисов, ты лучше скажи еще раз, ты за 1 базу и РЛС + разделение или за много баз + планы обмена и сервисы?

(47) много баз с 3 компановками.
первая) Центральный узел, вебсервис приемопередачи данных от удаленных узлов. развитая подсистема для работы с франчами. хорошо попиленная УТ.
вторая) Оперативный узел, вебсервис приема данных по оперативным данным (бонусы, шмонусы). писать нетленку.
третья) Удаленный узел. ограниченная подсистема для работы с головным офисом. писать расширение к УТ или лепить свою поставку поверх УТ.
и главное - никаких планов обмена.

(48) ... писать нетленку ...
Ага, допиши еще разместить ее у себя на сервере, и сдавать в аренду, а аренду начислять по количеству рассчетов твоей нетленки.

(48) Почему никаких планов обмена?

(0)

Один франч равно одна база - это 100%.

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

НО по-началу это будет трудно и лучше сразу делать норм систему, чтобы потом на лету не изменять её. По прошествии какого-то времени будет еще труднее.
А также придется задуматься о расширении штата техподдержки.

ТОЧНО не стоит делать РИБ, достаточно будет обмена по правилам обмена.
ТОЧНО это не простая работа.

Я проходил этот путь для одной крупной сети (к частным 200 точкам продаж добавилось на текущий момент 50 точек франшизы) и набил на этом большое количество шишек и получил огромное количество опыта, и ТОЧНО могу сказать, что во всем этом главный враг - это непродуманость модели франшизы изначально (от этого не уйти) и завышенные ожидания от скорости изменения информационной системы (над этим надо работать).

(51) о. у тебя есть релевантная экспа. зацени (48)

(43)
Для этого можно воспользоваться:
1. Сервером очередей напримеир RabbitMQ - реализовывать событийную модель синхронизации
2. Или просто планами обменов - это очень хороший механизм платформы, который покрывает почти все требования по синхронизации данных, но по своей сути не является оперативным и довольно затратным по части серверных ресурсов.

(52) Похоже на правду, кроме планов обмена)

Если УТ10 то только РИБ, если УТ11 то можно в одной базе, по сути свой фреш сделать.

(55)+ Для франчей которые не хотят переходить на общую учетную систему (у них своя есть) сделать дисконтный сервер на сервисах и обмены чем надо с готовыми примерами.

(56)+ Имхо Розница 2 готовое решение, и УФ и даже дисконтный сервер есть.
А УТ оставить для опта.

(55) как человек, прошедший с компанией путь от 1 офиса к филиальной сети, потом отказ от филиальной сети к франчазевой с условием "наш функционал не трогать с типовым делайте что хотите", могу сказать, ведения в одной базе / Риб будет очень дорогостоящей ошибкой.
Это на свой филиал ты можешь повлиять административными мерами, на франчайзи - нет.
И творился там ад, каждый вертел как хотел.
В итоге перешли на отдельные базы. Естественно с перепиской с нуля.

(58) Правильно настроенный РИБ, где все запрещено кроме того что разрешено (продавать и делать возвраты) отлично защищает от кривых рук.

Все НСИ только в ЦБ и накладные готовые на точки.
Даже пользователя завести в базу специальные люди в одном месте, не говоря уже о прочем более важном.

А вот если пустить на самотек дав полные права тут все логично что будет.

(59) Ты не понял.
Речь идет о доработках типового функционала в рамках "франчи живут как хотят"
Через год конфа была в решето от Если Организация.Наименование = "Клиент1" тогда

В рамках (31) ясно, что доработки типового функционала, не связанного с франчайзи будут.

(60) Эээ допиливали конфу под хотелки (извращения) франчей?

(62) Конечно.
Шеф деньги за это брал

(62) Тогда стандартизировать планы обмена вместо единого РИБ.

(63) Та это по сути уже бизнес на софте а не на франшизе выходит.
Толпу прогов надо нанимать для реализации хотелок.

(64) ну и возвращаемся к отдельной поставке "Франчайзи" строго стандартизированной, и остальному УТ.
Ну да конфа на поддержке 2х поставщиков получится, норм работало.
(65) И то и то.

Врать не буду, в месяц фиксированный взнос франчайзи был около 100К, туда входило много чего, в том числе некоторое число часов разработки на 1С

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

(59)
РИБ для целей (0) - это ошибка.

(69) Надо знать больше инфы чтобы выбрать наилучший вариант из наихудших.

(69) Я согласен, что РИБ делать не нужно, пусть гарантии что план провалится нет, но как говорил Эдд: " Если дерьмо может случиться, оно обязательно случится".

Выводить в отдельную базу НСИ и справочники это крутая идея, но пока она в перспективе.

Странно что 1С или рарус не сделал нетленку или модуль для франчей, развитая ведь тема в РФ

(72) Как бы объяснить:
Франчайзи, это не только право на размещение вывески, это какая то модель ведения бизнеса, уникальная.
В той компании которой я работал продавали свое видение управленческого учета в том числе. Сфера - работа с наемным персоналом. Что такое себестоимость, как мы планируем, как мы привлекаем и так далее и так далее. Да можно сказать, что ближайшая конфа это ЗУП(если очень хорошо поискать то можно было найти кусочки кода из ЗУП), но от ЗУП там ничего в итоге не осталось. Ибо табель ЗУП и табель наемного рабочего кроме количества дней в месяце ничего общего не имел. И как показало время, а это в итоге более 15 лет развития компании, эта модель успешна, появились люди, которые хотели работать также.
Автоматизировать можно лишь то, что уже существует, то чего нет автоматизировать не выйдет.
(71) А вот то, что ты думаешь сейчас об MDM это очень здорово.

В план обмена включить только отдельные справочники и регистры сведений.
Для каждого франчайзи поставлять единообразную конфигурацию, чтобы не делать для каждой базы отдельный план обмена. Пункт 3 тоже бы подошёл, т.к. наверняка не все исходные условия озвучены.

(0) У меня есть подобные клиенты, сделали так: сторонние товарищи все колбасятся в одной базе с RLS по подразделению, у этой базы обмен с базой бухгалтерии. Бухи в основной, прежде чем грузить данные из "партнерской" базы, проверяют их документы, ставят галки, запрещающие редактировние этих выгружаемых доков (чтобы сторонние задним числом не правили ничего).

Итого 2 базы.

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

Вот и как тогда делать универсальную нетленку для бизнеса, если бизнес этого не признАет?

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

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

в центре - заводим типы цены, скидки, номенклатуру и т.д.

вопросы бонусов - я бы решал некой внешней СУБД с хранением этих бонусов и доступом к ней из любой базы, так и для безопасности полезнее и для доступа к единой системе бонусов из различных источников (на будущее)....

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

РИБ - в случае, если Вы не планируете отдавать франчам доработку конфы (а как правило в ритейле так и есть) и не РИБ - если Вы отдаете конфу на редактирование, но тогда, это странная ритейловская франшиза, я бы точно так не делал...

(78) однако, никаких заметных затрат, если это РИБ и кучка ПБ

Только на единой конфигурации для ПБ франшизе будет весьма сомнительно удержаться

(80) поддержка большЕго кол-ва узлов, хранение дублей информации - это затраты от которых никуда не денешься если будешь плодить ПБ и когда ПБ - 2-3 это одно, а когда их 20-50 - это совсем другое...

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

(79) а зачем им "отдавать на редактирование", когда он сами будут дорабатывать конфигурации для своих партнеров по бизнесу, если для этого у них есть централизованный отдел по оказанию ай-ти услуг

(81) извиняюсь, смешно читать, что это какие-то особые затраты, на фоне современных стоимостей носителей, каналов связи и т.д.

(82) у кого у них? у франчей? в розничных магазинах франчей есть отделы ИТ?! да ладно...

(85) не пиши, я не заставляю тебя не писать :-)

(84) у них - это у топикстартера - у топикстартера есть кому разрабатывать. И фрашиза у них = это поиск удобной формы ведения бизнеса, когда возможно, что уже  существующие кусочки бизнеса, выводятся в форму франшизы и получением дополнительной свободы.

ой... в (86) опечатался
* заставляю тебя не писать

(89) я так понял, что предупреждение тебя не впечатлило.

(89) Я бы не реагировал, но некоторые высказывания в других ветках просто провоцируют меня на крайние меры.

Я думаю, что остановлюсь на связке План обмена + сервис. потом будем тюнить.

Можно кстати и "нестрогий" РИБ, т.е. который не падает от того что в одной базе реквизит добавлен в объекту, а в другой нет

(93) Апну, а как такое реализуется? Я такого не видел, что бы РИБ и не строгий? Выпилить из него передачу структуры конфы?