Попробую рассказать о принципах оффлайновой работы 1С.

[Сисой]

На уровне типовых реализованы следующие схемы обмена:
1. Бухгалтерия 7 -> Бухгалтерия 8 (перенос операций при апгрейде)
2. Бухгалтерия 8 <-> Зарплата и Управление персоналом 8
3. Бухгалтерия 8 <-> Управление торговлей 8
4. Бухгалтерия 8 <-> Зарплата и кадры 7
5. Бухгалтерия 7 <-> Зарплата и Управление персоналом 8


В них используются все заявленные мной возможности, включая программные обработчики.
Партнеры 1С разрабатывают и другие схемы обмена, например Комплексная 7.7 - > УПП.
Кроме того, в Бухгалтерии 8 есть механизм обмена со всеми необходимыми настройками для автономной работы бухгалтера в выходные дома.

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

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

Важное замечание: Запись большого количества импортируемых документов в 1С может вызывать блокировки ввода текущих документов. Единственное, что смогла предложить 1С - механизм отложенных движений. В этом случае сначала в БД записываются непроведенные документы, а затем специальная фоновая задача выполняет постинг в максимально щадящем с точки зрения OLTP режиме.

Однако, если объем вводимой информации велик, а репликация нужна оперативная (пример - в территориально распределенном горизонтальном холдинге нужно оперативно передавать в центр информацию о взаиморасчетах и кэше), штатные механизмы 1С становятся "бутылочным горлышком". И тогда на помощь приходят спецы из компаний типа softpoint.ru...

[sobolev]

Вопрос к Сисою по технологии обмена.
Я так понимаю, что система фиксирует идентичность одного и того же объекта в разных разделах по UUID'у, который является уникальным неизменяемым идентификатором объекта как в пределах одного раздела, так и всей совокупности разделов.

Скажем, товар А в разделе X1 имеет идент 1000 (естественно, это - UUID). Когда этот товар передается в другой раздел X2, там он тоже будет товаром А с идентификатором 1000.
Когда в первом разделе (X1) какой-то атрибут товара А изменится и будет передан в раздел X2, то там система найдет товар с идент 1000 и изменит вышеобозначенный атрибут. И т.д.

Если до сих пор я все правильно изложил, то вопрос следующий: что делает система в случае, если один и тот же по сути объект существует в разных разделах независимо друг от друга?
Возвращаясь к примеру, если записи для товара А в разделах X1 и X2 созданы независимо друг от друга (само-собой, их идентификаторы разные).

[Сисой]

UUID - лишь один из возможных вариантов контроля уникальности и сопоставления.
В 1С:Конвертации можно определять, по каким ключевым полям сопоставлять товары.
Например, Поставщик+Артикул. Или Код+Наименование.

[sobolev]

Цитата:

Сообщение от Сисой

UUID - лишь один из возможных вариантов контроля уникальности и сопоставления.
В 1С:Конвертации можно определять, по каким ключевым полям сопоставлять товары.
Например, Поставщик+Артикул. Или Код+Наименование.

ОК. При поступлении нового объекта модуль конвертации распознал наличие аналога и не стал создавать нового объекта. Для определенности придерживаемся прежнего примера с товаром А. Теперь этот товар А в разделе X1 имеет идент 1000, а в разделе X2 - 900 (там аналог был создан раньше).
Т.о. с этого момента при дальнейшей синхронизации кто-то должен следить за тем, чтобы указанный набор ключевых полей ни в коем случае у товара А в обоих разделах не менялся. В противном случае у нас "раздвоятся" ссылки на этот объект (в нашем примере, например, вероятны проблемы с документами, ссылающимися на товар А: вчера мы продавали А, сегодня это будет уже А2, потому что менеджер удалил лишний пробел между словами в наименовании).
Это так?

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

[mazzy]

Цитата:

Сообщение от Сисой

На уровне типовых реализованы следующие схемы обмена:
1. Бухгалтерия 7 -> Бухгалтерия 8 (перенос операций при апгрейде)
2. Бухгалтерия 8 <-> Зарплата и Управление персоналом 8
3. Бухгалтерия 8 <-> Управление торговлей 8
4. Бухгалтерия 8 <-> Зарплата и кадры 7
5. Бухгалтерия 7 <-> Зарплата и Управление персоналом 8

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

ок.
В этом списке нет УПП,
В этом списке нет обмена 7-7.
В этом списке нет несовместимых друг с другом конфигураций типа УТ-УТ.
В этом списке нет того, нет сего.

Но хоть как базу эти уже имеющиеся схемы использовать можно?
Я правильно понимаю, что для синхронизации УПП - БУХ можно взять схему УТ - БУХ и допилить ее? Или не получится?
Сколько по времени может занять создание схемы УПП - БУХ?

[Сисой]

Цитата:

Сообщение от mazzy

В этом списке нет УПП

Есть БП --> УПП, УТ --> УПП

Цитата:

Сообщение от mazzy

В этом списке нет обмена 7-7.

Я их просто не упоминал, т.к. топик про 8-ку.
Есть ТиС<->Бух, ЗиК<->Бух

Цитата:

Сообщение от mazzy

Я правильно понимаю, что для синхронизации УПП - БУХ можно взять схему УТ - БУХ и допилить ее? Или не получится?
Сколько по времени может занять создание схемы УПП - БУХ?

Лучше не допиливать, а настроить заново по образу и подобию. Все-таки УПП содержит больше информации для БУ и НУ, чем УТ (те же счета НУ, к примеру).
Я делал обратную схему (тогда еще не было типовых правил обмена БП --> УПП) для документов кассы, банка, склада дня три (там еще фильтрацию нужно было программно обеспечить).

[mazzy]

Цитата:

Сообщение от Сисой

Есть БП --> УПП, УТ --> УПП

Только сейчас заметил, что есть однонаправленные стрелки, а есть двунаправленные.

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

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

Так?

[Сисой]

Цитата:

Сообщение от mazzy

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

Так?

Да.
При этом следует понимать, что к идее переноса больших массивов информации через текстовые XML-файлы следует относиться с определенной долей скепсиса.
Алгоритм, прекрасно работающий при выгрузке пары сотен документов или перегрузке НСИ из одной конфигурации в другую, оказывается неуклюжим и непрозрачным при попытке перенести десятки тысяч операций. Еще раз повторюсь: концепция распределенных баз, предложенная 1С, вполне работоспособна, но до определенного масштаба.

[korvint]

мысль, просто мысль
а может хватит off-line
на дворе 21-й век
реальный масштаб времени (on-line) рулит сейчас и будет рулить
а на 1С реальный масштаб времени никак?

[mazzy]

ну, почему же "никак"?
очень даже как http://demo-ma.1c.ru/
другое дело, что 1С сильно вложилась в оффлайновый режим (как и в собственную базу данных). Вопрос "зачем?" останется неразгаданным долго.