Добрящего времени...

Товарищи,возникла над моей головой грустная туча...

Необходим частый (с интервалом 30 мин.) двусторонний обмен с филиалами (база строго на точке).
Конфы УТ10.3,допускается их колбасить.

Варианты:
1)Но вот незадача,РИБ,опупителен,НО,требует выравнивания конф + возможные приколы на филиалах из-за общего обновления - не подходит
2)Внешнее соединение,то же неплохая тема,но требует (возможно) выравния платформы и одну подсеть - не подходит
3)Правила обмена,фиг с ним,что придется их корректировать,и,еще сопоставлять в ручную справочники,т.к. GUID не одинаковы... но в момент обмена блокируются таблицы,что не даст записывать/проводить документы...
4)RDP/RAPP/УФ к-с ...иными словами база не на точке не предлагать...

...

Что бы Вы изобрели?

"но в момент обмена блокируются таблицы" - на 10 сек?  Или там компы доисторические?

3 и центральную базу сделать только для обменов.
В центре работать на периферийной.

(0) РИБ с доработкой автоматического обновления конфигурации БД при обмене

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

сколько точек?

(1) объем данных будет расти и я не имею таких экспериментов...но при текущей базе (обмене) УТ<>БП,обмен длится 3 часа (базы на одном сервере),обмен каждые сутки.

и да, 30 минут - это совсем и очень даже НЕ частый обмен.

(3) (4)
*на точках кассы и пистолеты,если что пойдет не так с после обнов,это Ж0//@
*придется,создав ЦБ и филиальные образы,туда задвигать единые справочники и переносить остатки...очень долго и не реально остановить работу
*слышал,что РИБ не всегда может гладко работать

(6) Какой объем документооборота?

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

Нюансы:
*филиалы действуют от разных организаций:ИП,ООО...
*из ЦБ необходимо двигать документы и те же с справочники в УТ10.3 в которой ведется основной учет и обмен в БП3

(5) пока 5

(8)
РИБ отлично работает. У меня 20 узлов - вообще не тревожат.
В любом случае не важно РИБ это или нет - тебе придется тиражировать конфигурацию. И вот тут с РИБом как раз все значительно проще: достаточно обновить центр. Далее он сам растиражирует с сообщениями обменов изменения конфигурации.

(12)
А со стороны обменов данными - не придется от слова ВООБЩЕ геморроиться с правилами обменов, держать их актуальными и тратить время на их поддержку. Это абсолютно лишнее.

(9) пока,примерно 150 доков реализации в день,с 50 наименований на документ (около 1000 номенклатурных наименований всего)

(14)
Ну это совсем не много.
Все движения и проверки будут выполняться на узлах. В ЦБ же эти данными придут уже "как есть", в том числе и сформированные наборы записей регистров, вследствие чего запись пакетов будет происходить занчительно быстрее, чем если бы проводились. При обмене УТ<>БП как раз происходит не просто перенос изменений, а и проведение документов, что сильно тормозит обмен.

(13) ок,попробую просимулировать,но стромно с подключенным оборудованием.
Удавалось к РИБ прикручивать WEB-взаимодействие,т.е. что бы филиалы конектились к ЦБ на стороне которой запущен apache или IIS,т.е. что бы избежать FTP?

хотфиксы можно делать через расширения.
В новых версиях платформы, если я не ошибаюсь, в РИБе расширения уже сами тиражируются.
То есть например получился косяк - закинул расширение в ЦБ, оно разлетелось на всю периферию - и всё. У меня в РИБе так ирописходит (но тираж я писал сам через веб-сервисы, потому что платформа тогда еще не поддерживала это сама)

(16)
Да, так и делаю.
Периферийная база формирует сообщение обмена, отправляет его на веб-сервис центральной базы. Там это сообщение принимается и загружается. Всё просто и быстро.

+ (18)
ну и ответ из ЦБ в периферию естественно.

(18) ок...
Бывали случаи форсмажлора/глюки/неувязки с торговым оборудованием при РИБе?

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

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

(21)
Отлично поддерживается.

(0)  Без приведения всей НСИ к единому варианту единое управление из центральной базы не возможно. А после получения единого варианта НСИ РИБ становиться на голову лучше обмена на правилах обмена.
0. Разобраться с зоопарком конфигураций в филиалах и разработать конфигурацию которая устраивает всех. "Конфликтующие" интересы по возможности разрешать управленческим рычагом или внешними доработками. Доработать в РИБ'е фильтрацию выгружаемой информации по филиалам. Исключить из РИБ'а элементы не относящиеся к основной деятельности.
1. Выбрать крупный показательный филиал и взять его НСИ за основу.
2. Запустить 2 узла РИБ - Центральный и филиал.
3. Запустить ещё один узел РИБ для другого филиала. Возможно с занесением начальных остатков.
4. Повторять шаг 3 пока филиалы не кончаться.

главное центральную базу динамически не обновляй

(25) +100500

ок,Спасибо за поддержку,значит РЫБ)

(25) Много раз в рибе обновлял динамикой. Правда, на 8.2.
Ни одного слёта.

(0) А прикрутить к центральной вебморду и прокинуть в филиалы через VPN?

(29) нет,только локальные,т.к. инет может лтваливаться,а продажи регистрировать необходимо

VPN поднят,коннектимся к филиалами по терминалу...при двух точках норм,а при пяти уже геморно так учёт вести

(29) ещё гемор пробрасывать USB по сети (пистолет)
+отклик,если точка будет получать морду с удаленного сервера

Через сторонние (внешние) решения

(33) Какие,например?

(6) Наиболее часто такая ситуация встречается когда не проходит подтверждение приема сообщений при обмене - тогда выгружаются все изменения каждый раз.

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

зы:для общего понимания

(34) В личку

(36)
Смотри БСП, там правила обмена могут храниться либо в макете конфигурации, лабо подключаться "на лету" из файла.

(33)
Кстати, вполне себе хороший вариант. Но вряд ли лучше чем РИБ. Особенно если у них на местах будет использоваться какиой-нибудь дорабатываемый функционал.

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

РИБ - самый быстрый обмен по GUIDам.

Привидение к идентичности конфигураций существующих баз - разовая работа, ничего интересного, рутинная работа.

Вот с привидением НСИ интереснее. РИБ "по умолчанию" работает на соответствии по GUIDам, но это легко изменяется, когда объект получен из сообщения обмена, но ещё не записан в базу - можно задействовать вариант поиска соответствий объектов не-РИБ обменов...

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

Много всего поменялось в РИБ. Например, сейчас совсем не проблема изменять приоритет при коллизиях обмена данными...

(41) все упирается в НСИ,точки открывались не равномерно,так сказать "на прощупать",НСИ создавались на месте и никто не учитывал,как это потом скрестить...теперь походу придется создавать чистую базу (ЦФБ),в нее выгружать НСИ (для идентичности GUID) из действующей центральной базы (ЦБ) и плодить из (ЦФБ) РИБ-имиджы...долго и геморно заморачиваться с переносом остатков,настройкой подключаемого оборудования...

Коль уж зарылся в возможностях обмена/интеграции,для общего понимания,есть новомодный Enterprise Data (ED)...расчитан на УФ конфы...чем он лучше/полезен?

(41) и кстати,есть ли возможность подмены GUID в базах (если да,то как потом быть с подчиненностью) или только через регистр сопоставления? - это к вопросу других баз,которые не должны быть в звене РИБа,но нужно обмениваться.

Если у РИБа возникнут проблемы с квитированием,они без проблем "на лету" решаются или придется останавливать работы базы...?

Есть подписка на конфу КА,есть ли смысл из нее РИБ плодить,что бы обмен не настраивать между УТ и БП,или это излишне на точках филиалов?

Еще нюанс,у нас подписка ПРОФ,какие нюансы возникнут по бухгалтерской части ведя подразделения/филиалы в одной базе БП3 или КА1.1 или 2?

1)Не могу найти ответ на вопрос - о преимуществе "Enterprise Data" (ED) перед "Планом обмена"(ПО),поправьте если я не правильно понимаю идеологию.

2)КМК,ED это некое описание объекта...,для унификации,что то типа набора этих объектов,подходит,связывай с ним (объектом из колекции ED) свой объект и пуляй между разныи,даже не 1с-ными системами,так?

3)Под ED понимается отдельная система типа плана обмена или этот только описание обмена?

зы:прошу понят и простить,знаю о существовании ED,но чего да как,не рублю)

...поправил

1)Не могу найти ответ на вопрос - о ПРЕИМУЩЕСТВЕ"Enterprise Data" (ED) перед "Планом обмена"(ПО),поправьте если я не правильно понимаю идеологию.

2)КМК,ED это некое описание объекта...,для унификации,что то типа набора этих объектов,подходит,связывай с ним (объектом из колекции ED) свой объект и пуляй между разныи,даже не 1с-ными системами,так?

3)Под ED понимается отдельная система типа плана обмена или этот только описание объекта?

зы:прошу понят и простить,знаю о существовании ED,но чего да как,не рублю)

(48) Наверное лучше статью почитать http://catalog.mista.ru/public/695523/

Тут все про рибы на бсп пишут, у тс конфа ут 10.3, по-моему будет не просто прикрутить туда механизмы бсп.

Есть необходимость организовать обмен между двух УТ10.3,одна типовая (Б),другая глубоко переработанная (А).
По сути,для:
*Передачи НСИ из "А" в "Б"
*Передача данных продаж из "Б" в "А"

..."А" в дальнейшем будет РИБом для филиалов.

Возникли вопросы:
1)в УТхе встроен план обмена с кофой на БП3 по правилам,возможно ли этот (штатный) функционал продублировать для нужд обмена с УТ,понимаю что придется подописывать?
2)или лучше подсистему обмена перенести из БСП?

ни кто так не делал (51)

(52) использовал этот план обмена для превращения УТ 10.3 в обмен в универсальном формате EnterpriseData см. общий модуль переопределяемый.
Правила тоже можно подменить, но может не хватить состава плана обмена. Для БП это нормально, а для УТ нет.