freagle писал(а) 28. Сентября 2007 :: 08:29:

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

Правда УРБД платное 480 у.е. 

Цитата:


Это оно?

freagle писал(а) 28. Сентября 2007 :: 09:44:


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

Для этого на каждый филиал был заведен свой собственный вид документа. Этакий документ шаблон переноса.
Его формирует обработка продажи в филиал.
У него настройка миграции "место создания, центр и база соответствующего филиала.

В филиале при каждом первом запуске за день запускается обработка анализа еще не обработанных документов переноса. Она формирует приходную накладную на основании приехавших данных. В шаблоне ставится флажок обработанности.

Эту обработку анализа можно запустить и ручками. При запуске ручками можно указать период и положить болт на флаг обработанности.

Решение громоздкое и неочевидное для пользователей даже для трех филиалов.

freagle писал(а) 28. Сентября 2007 :: 10:17:


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

fez писал(а) 28. Сентября 2007 :: 10:13:


Можно сделать один вид документа ( но так как у тебя всего три филиала для тебя
не очень принципиально).
Миграция место создания центр.
В шапке документ содержит признак филиала.
Заранее в каждом филиале формируешь пустышки скажем штук по 100 скажем за дату 01.01.1980
Когда надо центр заполняет нужную пустышку и ставит тек дату док.

Цитата:


Ага, мысль хороша... Действительно, что такое IDD MOD, да и любой пользовательский реквизит? Это реализация способа понять что Объект где-то там =  Объект здесь (или !=).
К плюсам идеи - прозрачное встраивание в конфигурацию, т.к. не надо иметь никакой геморрой с добавлением реквизитов, централизованой выдачей уникальных идентификаторов, и тому подобными вещами.

Перехватом записи журнала регистрации получаем DocId, асинхронно дергаем метод сервиса, что-то типа "ОбъектИзменен(Тип,Вид,ID,Действие) " Все. Рабочий поток 1С пошел дальше, тормозов - никаких, а как поступит сервис с этими данными - дело самого сервиса. Главное, что потом по этим данным можно однозначно достать объект из базы. Просто, понятно, прозрачно...

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

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

Цитата:


Хех. Твои бы слова да богу в уши... Чудила, еще как чудила. Я потратил неделю на поиски косяка, пока не начал проверять ВСЕ, в том числе и DocId.

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