Имя: Пароль:
1C
 
Архитектура компании с сетью франчайзи.
🠗 (Фрэнки 10.05.2019 10:33)
,
0 OnNeOn
 
08.05.19
14:52
1. Вести учет в отдельных базах (план обмена) 50% (3)
2. Свой вариант. 33% (2)
3. Вести учет в одной базе (разделение + RLS) 17% (1)
Всего мнений: 6

Всем привет.

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

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

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

Кто нибудь уже подобный велик делал? Может есть еще путь как можно это реализовать?
1 sqr4
 
08.05.19
14:54
http://v8.1c.ru/overview/Term_000000788.htm
мб в тему будет мб нет
2 zak555
 
08.05.19
14:54
2. конечно
3 lodger
 
08.05.19
14:56
1.2) Отдельная база + обмен через HTTP-сервисы.
4 OnNeOn
 
08.05.19
14:57
Админы, прикрутите голосовалку пожалуйста. Чет затормозил.
5 OnNeOn
 
08.05.19
14:57
(2) (3) Можно с аргументами?
6 Вася Теркин
 
08.05.19
14:59
+(1) Общие реквизиты здесь однозначно, а не RLS. Но не все данные удастся поделить. Тогда уже RLSом прятать
7 OnNeOn
 
08.05.19
15:05
(3) Это конечно круто. Но тут подводных камней столько, что даже купленный 1С сервер не является аргументом )

Тут ньансов просто миллион, поднять полноценный обмен из УТ->УТ это не просто, там так накручено, там так навинчено, одни скидки перенести из базы в базу эта задачка на 2-3 дня. Хотя что я говорю, перенести справочник Скидки это 15 минут, а вот перенести так что бы акции и скидки заработали полноценно это где то 1-2 дня. Потом надо еще понять как акции выгружать, т.к. они настраиваются на склады, виды карт и номенклатуру. Это сложновастенько выходит. И когда ты понимаешь что все так сложно, то значит ты что то делаешь не так.
8 palsergeich
 
08.05.19
15:06
А почему не РИБ?
9 palsergeich
 
08.05.19
15:07
(1) (6) Кака же. Не факт, что будет использован кластерный индекс и получите днищще по производительности.
10 lodger
 
08.05.19
15:09
(7) как будто пилить ризделитель+RLS за полчаса.
11 OnNeOn
 
08.05.19
15:11
С RLS-ом у меня опасения что производительности будет очень мало. У них сейчас в УТ около 90 человек работает, она еле шевелится.

(8) В РИбе насколько я помню нет правил конвертации. А тут в обмене будут метамарфозы, когда ПТиУ - РТиУ, ПКО -> РКО и т.д.
12 Cyberhawk
 
08.05.19
15:24
(4) Слева от заголовка ветки кнопка vote
13 Cyberhawk
 
08.05.19
15:25
(9) Так говоришь будто использование кластерного это прям бальзам на душу )
14 palsergeich
 
08.05.19
15:42
(11) ну вот про мутации документов надо было догадаться.
Нормального решения, что бы на калькуляторе и 100500 пользователей и хитрые мутации - не выйдет.
Вариант 1, все остальное рано или поздно выйдет в вариант 1
15 palsergeich
 
08.05.19
15:43
Чем не устраивает УТ + розница то?
16 shuhard
 
08.05.19
15:45
(11) RLS по Организациям не ресурсоёмок
если не включать интеркомпани, то и с учетом проблем не будет
[У них сейчас в УТ около 90 человек работает, она еле шевелится. ]
это плата за оперативность

Вести учет в одной базе (разделение + RLS)
17 ptiz
 
08.05.19
15:55
(0) "общая схема бонусных карт" - накопление бонусов планируется? Сколько покупателей с картами? Бонусы общие по всей сети франчайзи? Нужна будет нехилая отдельная база бонусов с веб-сервисом, в который будут стучаться локальные базы франчайзей.
18 OnNeOn
 
08.05.19
15:55
(15) Раньше была розница, я не застал этот переход, они с Розницы ушли на УТ, больше про розницу не хотят слышать, говорят что проблем у них было много в ней. Да и бонусные баллы и карты лояльности реализованы в Рознице?
19 unregistered
 
08.05.19
15:55
(0) > Пожелания заказчика: франчи живут как хотят.

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

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

Я бы уточнил сначала задачу бизнеса. Что именно означает "живут как хотят".
20 OnNeOn
 
08.05.19
16:00
(19) - Вряд ли франчи захотят показывать всю свою информацию владельцам франшизы.

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

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

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

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

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

Свой вариант.
22 OnNeOn
 
08.05.19
16:04
(21) Можно подробнее, почему по регл учету нужно будет обосолбление? Тут вообще разные юр лица, какая разница как они обособлены или нет?


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

Пока традиционно.
Открытие смены -> Чеки ККМ + Чеки на возврат -> Отчет о розничных продажах.
23 Фрэнки
 
08.05.19
16:08
(22) // пока традиционно //
ну и для них тогда, как минимум, свои базы должны быть, по идее, чтоб регламентные и прочие заморочки с кассами и не только с кассами на одной фирме не вызывали ступор в работе другой фирмы.
24 Фрэнки
 
08.05.19
16:10
(22) // вообще разные юр лица, какая разница как они обособлены или нет?

Ну это и есть, скажем так, высшая степень обособленности, когда часть управленческой структуры холдинга/фирмы обособоляется в виде регистрации нового юридического лица.
25 Вафель
 
08.05.19
16:10
лучше иметь вебсервис по выдаче данных бонусов + обработки пд типовые конфы.
а ведут пускай сами как хотят
26 edem911
 
08.05.19
16:11
РИБ по организации. Но нужно будет разобраться с бонусными картами, если они печатаются из центра и выдаются на франчи тогда проблем не должно быть если филиалы сами генерируют бонусные карты тогда нужно будет подпилить. Но в этом случае в центре владелец франшизы будет видеть ВСЕ что касается франчей, а это уже не совсем франшиза а обычный филиал.
Если все таки у вас партнерские отношения с франчами и они вам не все должны показывать, то нужно писать свой обмен, а на КД или нет это уже вопрос реализации.

Вести учет в отдельных базах (план обмена)
27 OnNeOn
 
08.05.19
16:15
(25) С бонусными есть стратегия.

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

В Базе Франча:
1. При создании документа ЧЕК ККМ, Отчет о розничных продажах, РТиУ Создается документ Начисление/Списание бонусных баллов, проводки по РС документы продажи не делают;
2. Документ Начисление/Списание бонусных баллов выгружается в центр по плану обмена через правила.
28 OnNeOn
 
08.05.19
16:15
(26) РИБ, думал над рибом, там обмены с закидонами (11)
29 edem911
 
08.05.19
16:23
(28) Не что не мешает дописать РИБ под эти требования, если в центре нужно видеть все что касается филиалов.
Была подобная задача с сетью алкомагазинов. Делали  через КД. Из центра выгружалась только НСИ(товары, цены). И документы реализации из центра в конкретный магазин падали как поступление, бонусная программа была единая, карты выдавались из центра на магазины накопленные бонусы выгружались по всем магазинам. + была одна пустая база филиала(не привязана ни к какой организации) и если открывался новый магазин то им передавали копию этой базы и ее уже настраивали.
30 Фрэнки
 
08.05.19
16:24
(28) резюмирую: твой вариант должен быть хорошим сочетанием из 1 и 2 пункта голосовалки.

Вам все равно будет необходима сводная управленческая по пункту 2, пусть даже без идеального RLS
И все равно будут необходимы средства и способы для обеспечения работ с базами с планом обмена по пункту 1.
31 OnNeOn
 
08.05.19
16:27
(30) На данный момент в нашей базе БОСС хочет видеть следующее:
1. Кому сколько и кода продали;
2. Сколько из проданного оплаченно;
3. Сколько и когда вернули;
4. Сколько вернуть денег за вернутый товар.

Больше ничего из базы франчи он видеть не хочет. Может ошибается.
32 palsergeich
 
08.05.19
16:27
Как человек, работавший над автоматизацией франчайз сети могу сказать одно.
Если данные хранить в одной базе - все скатиться в сраные костыли.
Если Организация.Наименование = "VIPОрганизация" тогда...
Потому что внезапно окажется, что учет в каждой орге будет разнится, хотите вы того или нет.
33 palsergeich
 
08.05.19
16:28
(31) А завтра он захочет другое. True story
34 OnNeOn
 
08.05.19
16:35
(33) Да пофигу, я программист, а не фокусник. Если он решит менять свой бизнесс по 100 раз на дню, то пусть готовится много и очень много платить.
35 palsergeich
 
08.05.19
16:36
(34) Если ты сейчас не продумаешь схему то ничего не запустишь
36 OnNeOn
 
08.05.19
16:37
(35) Браво кеп! Именно поэтому я и думаю, а правильную ли схему придумал.
37 palsergeich
 
08.05.19
16:40
Заказчик не хочет цветок из конфигураций.
франчи живут как хотят
Вы понимаете, что проблемы начинаются тут.
Как я вижу решение этой проблемы:
Каждому участнику сети вы даете УТ.
Разрабатываете свою уникальную подсистему, вот с этим "общая схема бонусных карт, скидок, цен, и прочего"
Пишете обмены необходимыми данными в рамках своей уникальной подсистемы.
А с остальным функционалом УТ, пусть развлекаются как хотят.
(36) не хамил бы.
38 OnNeOn
 
08.05.19
16:45
(37) Ясно, ну значит путь развития своего плана обмена не такой уж нелепый, хоть и капец какой сложный. Лан, будем продолжать разработку.
Всем спасибо!
39 palsergeich
 
08.05.19
16:47
(38) Ну да, делаешь свою отдельную поставку "уникального" функционала, так будет просто поддерживать, вполне себе рабочая схема.
40 lodger
 
08.05.19
16:57
(38) ну да, сложный. расскажи какой из путей проще?
41 OnNeOn
 
08.05.19
16:59
(39) Вот то что функционал "уникальный" я согласен, уверен как то подобные поделки делаются проще.

(40) Если что то слишком сложно, значит ты что то делаешь не так. Жизнь - приключение, все должно быть легко и просто, как АКМ.
42 lodger
 
08.05.19
17:02
(41) сервисы это же просто. тут получаешь запросы и обрабатываешь их параметры, там пихаешь параметры в запросы и суешь в сервис. все просто, как АКМ.
43 OnNeOn
 
08.05.19
17:07
(42) Давай не будем вдаваться в подробности. На уровне как ты пишешь я сервисы разрабатывать умею. Не решит все вопросы твой сервис. Потому что задача ставится примерно так: нужно гарантированно перенести все движения бонусных баллов. Ключевое слово гарантированно.
44 OnNeOn
 
08.05.19
17:08
А что бы гарантированно переносить эти данные нужно иметь какой то флаг, о том, все ли у нас создалось, есть ли карта лояльности в ЦБ, есть ли проводка и т.д.
45 lodger
 
08.05.19
17:10
(44) ну так то там есть ответ на запрос, в котором можно разместить флаг успешности исполнения и описание ошибки.
46 lodger
 
08.05.19
17:11
(43) а со стороны отправки городишь очередь отправки и регламент по отправке.
47 OnNeOn
 
08.05.19
17:16
Лан, что бы не резало глаза, можно навтыкать кучу сервисов, ты лучше скажи еще раз, ты за 1 базу и РЛС + разделение или за много баз + планы обмена и сервисы?
48 lodger
 
08.05.19
17:23
(47) много баз с 3 компановками.
первая) Центральный узел, вебсервис приемопередачи данных от удаленных узлов. развитая подсистема для работы с франчами. хорошо попиленная УТ.
вторая) Оперативный узел, вебсервис приема данных по оперативным данным (бонусы, шмонусы). писать нетленку.
третья) Удаленный узел. ограниченная подсистема для работы с головным офисом. писать расширение к УТ или лепить свою поставку поверх УТ.
и главное - никаких планов обмена.
49 OnNeOn
 
08.05.19
17:27
(48) ... писать нетленку ...
Ага, допиши еще разместить ее у себя на сервере, и сдавать в аренду, а аренду начислять по количеству рассчетов твоей нетленки.
50 OnNeOn
 
08.05.19
17:27
(48) Почему никаких планов обмена?
51 pavig
 
08.05.19
17:29
(0)

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

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

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

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

Я проходил этот путь для одной крупной сети (к частным 200 точкам продаж добавилось на текущий момент 50 точек франшизы) и набил на этом большое количество шишек и получил огромное количество опыта, и ТОЧНО могу сказать, что во всем этом главный враг - это непродуманость модели франшизы изначально (от этого не уйти) и завышенные ожидания от скорости изменения информационной системы (над этим надо работать).
52 lodger
 
08.05.19
17:32
(51) о. у тебя есть релевантная экспа. зацени (48)
53 pavig
 
08.05.19
17:34
(43)
Для этого можно воспользоваться:
1. Сервером очередей напримеир RabbitMQ - реализовывать событийную модель синхронизации
2. Или просто планами обменов - это очень хороший механизм платформы, который покрывает почти все требования по синхронизации данных, но по своей сути не является оперативным и довольно затратным по части серверных ресурсов.
54 pavig
 
08.05.19
18:31
(52) Похоже на правду, кроме планов обмена)
55 Garykom
 
гуру
08.05.19
18:39
Если УТ10 то только РИБ, если УТ11 то можно в одной базе, по сути свой фреш сделать.
56 Garykom
 
гуру
08.05.19
18:40
(55)+ Для франчей которые не хотят переходить на общую учетную систему (у них своя есть) сделать дисконтный сервер на сервисах и обмены чем надо с готовыми примерами.
57 Garykom
 
гуру
08.05.19
18:44
(56)+ Имхо Розница 2 готовое решение, и УФ и даже дисконтный сервер есть.
А УТ оставить для опта.
58 palsergeich
 
08.05.19
19:13
(55) как человек, прошедший с компанией путь от 1 офиса к филиальной сети, потом отказ от филиальной сети к франчазевой с условием "наш функционал не трогать с типовым делайте что хотите", могу сказать, ведения в одной базе / Риб будет очень дорогостоящей ошибкой.
Это на свой филиал ты можешь повлиять административными мерами, на франчайзи - нет.
И творился там ад, каждый вертел как хотел.
В итоге перешли на отдельные базы. Естественно с перепиской с нуля.
59 Garykom
 
гуру
08.05.19
19:24
(58) Правильно настроенный РИБ, где все запрещено кроме того что разрешено (продавать и делать возвраты) отлично защищает от кривых рук.

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

А вот если пустить на самотек дав полные права тут все логично что будет.
60 palsergeich
 
08.05.19
19:27
(59) Ты не понял.
Речь идет о доработках типового функционала в рамках "франчи живут как хотят"
Через год конфа была в решето от Если Организация.Наименование = "Клиент1" тогда
61 palsergeich
 
08.05.19
19:28
В рамках (31) ясно, что доработки типового функционала, не связанного с франчайзи будут.
62 Garykom
 
гуру
08.05.19
19:28
(60) Эээ допиливали конфу под хотелки (извращения) франчей?
63 palsergeich
 
08.05.19
19:29
(62) Конечно.
Шеф деньги за это брал
64 Garykom
 
гуру
08.05.19
19:29
(62) Тогда стандартизировать планы обмена вместо единого РИБ.
65 Garykom
 
гуру
08.05.19
19:30
(63) Та это по сути уже бизнес на софте а не на франшизе выходит.
Толпу прогов надо нанимать для реализации хотелок.
66 palsergeich
 
08.05.19
19:31
(64) ну и возвращаемся к отдельной поставке "Франчайзи" строго стандартизированной, и остальному УТ.
Ну да конфа на поддержке 2х поставщиков получится, норм работало.
(65) И то и то.
67 palsergeich
 
08.05.19
19:32
Врать не буду, в месяц фиксированный взнос франчайзи был около 100К, туда входило много чего, в том числе некоторое число часов разработки на 1С
68 palsergeich
 
08.05.19
19:34
Кому то нужны были печ формы уникальные, кто то отчеты просил, а кому то и в код лезть приходилось.
69 pavig
 
08.05.19
20:54
(59)
РИБ для целей (0) - это ошибка.
70 Garykom
 
гуру
08.05.19
21:37
(69) Надо знать больше инфы чтобы выбрать наилучший вариант из наихудших.
71 OnNeOn
 
08.05.19
21:43
(69) Я согласен, что РИБ делать не нужно, пусть гарантии что план провалится нет, но как говорил Эдд: " Если дерьмо может случиться, оно обязательно случится".

Выводить в отдельную базу НСИ и справочники это крутая идея, но пока она в перспективе.
72 OnNeOn
 
08.05.19
21:44
Странно что 1С или рарус не сделал нетленку или модуль для франчей, развитая ведь тема в РФ
73 palsergeich
 
08.05.19
23:12
(72) Как бы объяснить:
Франчайзи, это не только право на размещение вывески, это какая то модель ведения бизнеса, уникальная.
В той компании которой я работал продавали свое видение управленческого учета в том числе. Сфера - работа с наемным персоналом. Что такое себестоимость, как мы планируем, как мы привлекаем и так далее и так далее. Да можно сказать, что ближайшая конфа это ЗУП(если очень хорошо поискать то можно было найти кусочки кода из ЗУП), но от ЗУП там ничего в итоге не осталось. Ибо табель ЗУП и табель наемного рабочего кроме количества дней в месяце ничего общего не имел. И как показало время, а это в итоге более 15 лет развития компании, эта модель успешна, появились люди, которые хотели работать также.
Автоматизировать можно лишь то, что уже существует, то чего нет автоматизировать не выйдет.
(71) А вот то, что ты думаешь сейчас об MDM это очень здорово.
74 Мимохожий Однако
 
09.05.19
08:02
В план обмена включить только отдельные справочники и регистры сведений.
Для каждого франчайзи поставлять единообразную конфигурацию, чтобы не делать для каждой базы отдельный план обмена. Пункт 3 тоже бы подошёл, т.к. наверняка не все исходные условия озвучены.

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

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

Вот и как тогда делать универсальную нетленку для бизнеса, если бизнес этого не признАет?
77 ILM
 
гуру
09.05.19
15:37
Одна общая база в облаке, доступ к ней от всех пользователей. Скидки цены и бонусы редактировать главному офису, остальным только чтение. Загрузка из филиалов только в спецрегистр, откуда перегружать в  общую базу.

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

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

вопросы бонусов - я бы решал некой внешней СУБД с хранением этих бонусов и доступом к ней из любой базы, так и для безопасности полезнее и для доступа к единой системе бонусов из различных источников (на будущее)....
79 HawkEye
 
09.05.19
15:51
(+78) однозначно, я бы не стал вести все это в единой базе.... тут и безопасность и единая точка отказ и вопрос масштабируемости...

РИБ - в случае, если Вы не планируете отдавать франчам доработку конфы (а как правило в ритейле так и есть) и не РИБ - если Вы отдаете конфу на редактирование, но тогда, это странная ритейловская франшиза, я бы точно так не делал...
80 Фрэнки
 
09.05.19
15:51
(78) однако, никаких заметных затрат, если это РИБ и кучка ПБ

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

по второму вопросу - с теми, с кем сталкивался я - именно на единых метаданных удерживаются.... т.к. это кроме всего прочего, банальный контроль за франчем, гарантии соблюдения бизнес-процессов и единое информационное поле....
82 Фрэнки
 
09.05.19
15:56
(79) а зачем им "отдавать на редактирование", когда он сами будут дорабатывать конфигурации для своих партнеров по бизнесу, если для этого у них есть централизованный отдел по оказанию ай-ти услуг
83 Фрэнки
 
09.05.19
15:57
(81) извиняюсь, смешно читать, что это какие-то особые затраты, на фоне современных стоимостей носителей, каналов связи и т.д.
84 HawkEye
 
09.05.19
15:57
(82) у кого у них? у франчей? в розничных магазинах франчей есть отделы ИТ?! да ладно...
86 Фрэнки
 
09.05.19
15:59
(85) не пиши, я не заставляю тебя не писать :-)
87 Фрэнки
 
09.05.19
16:02
(84) у них - это у топикстартера - у топикстартера есть кому разрабатывать. И фрашиза у них = это поиск удобной формы ведения бизнеса, когда возможно, что уже  существующие кусочки бизнеса, выводятся в форму франшизы и получением дополнительной свободы.
88 Фрэнки
 
09.05.19
16:03
ой... в (86) опечатался
* заставляю тебя не писать
90 Фрэнки
 
09.05.19
18:42
(89) я так понял, что предупреждение тебя не впечатлило.
91 Фрэнки
 
09.05.19
18:44
(89) Я бы не реагировал, но некоторые высказывания в других ветках просто провоцируют меня на крайние меры.
92 OnNeOn
 
10.05.19
01:35
Я думаю, что остановлюсь на связке План обмена + сервис. потом будем тюнить.
93 Cyberhawk
 
13.05.19
10:58
Можно кстати и "нестрогий" РИБ, т.е. который не падает от того что в одной базе реквизит добавлен в объекту, а в другой нет

Вести учет в отдельных базах (план обмена)
94 OnNeOn
 
02.06.19
13:14
(93) Апну, а как такое реализуется? Я такого не видел, что бы РИБ и не строгий? Выпилить из него передачу структуры конфы?
Проблемы невозможно решaть нa том же уровне компетентности, нa котором они возникaют. Альберт Эйнштейн