КД2 или КД3 ?
1С:ERP Управление предприятием 2
1С:Бухгалтерия 3.0
1С:Комплексная автоматизация 2.х
1С:Конвертация данных
1С:Управление холдингом
8.3.14
Аудит и бухгалтерские услуги, юриспруденция
Недвижимость, риэлторская деятельность
Добрый день!
есть холдинг 30 баз БП3 / 50 юрлиц в одной сети. сейчас обменов нет (нет исторической данности которой надо поклоняться)
все бп3 актуальных релизов однообразного наполнения очень близки к типовым . в НСИ нет перекосов на обилие торговой номенклатуры или контрагентов, после выделения целевых контрагентов и физлиц (все с кем были взаиморасчеты за последние 2 года) и свертки дублей контрагентов + физлиц оказалось около 2700шт
Нужна центральная база для ведения казначейства, центральной базой выбрана типовая 1С:УХ.
Стоит задача
1) наполнить центральную базу справочниками (Достаточными для заведения банковской Выписки в УХ - организации, контрагенты, договоры, банки , банковские счета , физлица) и начать централизованное ведение НСИ из центральной базы
т.е. в периферийных базах реализовать запрет ввода и отправлять пользователя вводить требуемые ему справочники в центральную базу.
и далее:
2) Загружать банковскую выписку в центральной базе и распостранять ее по периферийным - начальная задача становления планируемого казначейства.
что нетипового в УХ:
идентичености реквизитов по статьям ДДС финансисты и бухгалтера добиться не смогли , и принято решение о "Натуральном меппинге" - те
при согласовании заявки на расход в УХ одна группа лиц поставит ДДС УУ, другая - ДДС БУХ ( самодельный справочник,
значение которого идентично значениям ДДС в периферийных базах и значение которого надо будет передавать в типовой реквизит ДДС в периферийную базу при переносе документа )
В БП и УХ введены общие реквизиты "Ссылка локальная" и "Ссылка общая" для упрощения обслуживания возможных правил обмена и однозначной идентификациии элементов при обмене.
какую технологию использовать разумнее КД2 или КД3 и какая аргументация может быть использована для обоснования выбора ? пока это достаточно простой односторонний обмен справочниками и двумя документами.
есть холдинг 30 баз БП3 / 50 юрлиц в одной сети. сейчас обменов нет (нет исторической данности которой надо поклоняться)
все бп3 актуальных релизов однообразного наполнения очень близки к типовым . в НСИ нет перекосов на обилие торговой номенклатуры или контрагентов, после выделения целевых контрагентов и физлиц (все с кем были взаиморасчеты за последние 2 года) и свертки дублей контрагентов + физлиц оказалось около 2700шт
Нужна центральная база для ведения казначейства, центральной базой выбрана типовая 1С:УХ.
Стоит задача
1) наполнить центральную базу справочниками (Достаточными для заведения банковской Выписки в УХ - организации, контрагенты, договоры, банки , банковские счета , физлица) и начать централизованное ведение НСИ из центральной базы
т.е. в периферийных базах реализовать запрет ввода и отправлять пользователя вводить требуемые ему справочники в центральную базу.
и далее:
2) Загружать банковскую выписку в центральной базе и распостранять ее по периферийным - начальная задача становления планируемого казначейства.
что нетипового в УХ:
идентичености реквизитов по статьям ДДС финансисты и бухгалтера добиться не смогли , и принято решение о "Натуральном меппинге" - те
при согласовании заявки на расход в УХ одна группа лиц поставит ДДС УУ, другая - ДДС БУХ ( самодельный справочник,
значение которого идентично значениям ДДС в периферийных базах и значение которого надо будет передавать в типовой реквизит ДДС в периферийную базу при переносе документа )
В БП и УХ введены общие реквизиты "Ссылка локальная" и "Ссылка общая" для упрощения обслуживания возможных правил обмена и однозначной идентификациии элементов при обмене.
какую технологию использовать разумнее КД2 или КД3 и какая аргументация может быть использована для обоснования выбора ? пока это достаточно простой односторонний обмен справочниками и двумя документами.
По теме из базы знаний
Найденные решения
(1)
Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б, С .....Ж п е. Основное волшебство в руках разработчика. Пользователи и заказчики вообще без понятия что там происходит и что это за буквы КД2, КД3.
Почему:
Минусы КД2
1) Трудность сопровождения: необходимо отслеживать изменения метаданных и актуализировать правила обмена данными. В типовых конфигурациях это происходит часто, поэтому обновление даже средних по сложности правил порой требует больших трудозатрат, нежели само обновление конфигурации т.к. требуется:
- проанализировать изменения и при необходимости изменить правила
- протестировать обмены на нестандартные ситуации, которые могут быть привнесены обновлением вендора
Для людей, далеких от программирования, обменов можно сказать - сопровождение дорогое.
2) Не развивается, не поддерживается.
Плюсы КД2:
Из-за того, что КД3 как раз решала основные узкие места КД2, к плюсам можно отнести
1) Если требования к составу обмена данными будут изменяться, сопровождение останется все таким же сложным, как и было.
2) разработка сравнительно проще для разработчика - разработка дешевле. Но это субъективно и зависит от ситуации. Что-то в КД3 проще разработчику, что-то в КД2 проще.
Минусы КД3:
1) Если требования к составу обмена данными будут изменяться, сопровождение может стать нереально сложным, что проклянете выбор КД3.
2) Из-за наличия стандарта некоторые вещи разрабатывать сложнее - разработка дороже. Но это субъективно и зависит от ситуации......
3) EnterpriseData уже будет нетиповой из-за нестандартного справочника.
Плюсы КД3
1) Основное преимущество КД3 - нет привязки к метаданным. Это облегчает сопровождение т.к. первая конфигурация выгружает свои данные в формат EnterpriseData. Вторая загружает данные из этого формата. При изменении конфигурации, правила меняются только на 1 стороне. Проще загружать данные из систем не на 1с.
Требуется в конфигурации, которая изменилась проверить выгрузку и загрузку. Вторую конфигурацию, как правило, подпиливать не нужно в 99%
2) Развивается, сопровождается
3) Вроде б как веб сервисы из коробки уже есть (БСП). Почти в реальном времени можно крутить, но я точно хз как оно там все.
Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.
Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б, С .....Ж п е. Основное волшебство в руках разработчика. Пользователи и заказчики вообще без понятия что там происходит и что это за буквы КД2, КД3.
Почему:
Минусы КД2
1) Трудность сопровождения: необходимо отслеживать изменения метаданных и актуализировать правила обмена данными. В типовых конфигурациях это происходит часто, поэтому обновление даже средних по сложности правил порой требует больших трудозатрат, нежели само обновление конфигурации т.к. требуется:
- проанализировать изменения и при необходимости изменить правила
- протестировать обмены на нестандартные ситуации, которые могут быть привнесены обновлением вендора
Для людей, далеких от программирования, обменов можно сказать - сопровождение дорогое.
2) Не развивается, не поддерживается.
Плюсы КД2:
Из-за того, что КД3 как раз решала основные узкие места КД2, к плюсам можно отнести
1) Если требования к составу обмена данными будут изменяться, сопровождение останется все таким же сложным, как и было.
2) разработка сравнительно проще для разработчика - разработка дешевле. Но это субъективно и зависит от ситуации. Что-то в КД3 проще разработчику, что-то в КД2 проще.
Минусы КД3:
1) Если требования к составу обмена данными будут изменяться, сопровождение может стать нереально сложным, что проклянете выбор КД3.
2) Из-за наличия стандарта некоторые вещи разрабатывать сложнее - разработка дороже. Но это субъективно и зависит от ситуации......
3) EnterpriseData уже будет нетиповой из-за нестандартного справочника.
Плюсы КД3
1) Основное преимущество КД3 - нет привязки к метаданным. Это облегчает сопровождение т.к. первая конфигурация выгружает свои данные в формат EnterpriseData. Вторая загружает данные из этого формата. При изменении конфигурации, правила меняются только на 1 стороне. Проще загружать данные из систем не на 1с.
Требуется в конфигурации, которая изменилась проверить выгрузку и загрузку. Вторую конфигурацию, как правило, подпиливать не нужно в 99%
2) Развивается, сопровождается
3) Вроде б как веб сервисы из коробки уже есть (БСП). Почти в реальном времени можно крутить, но я точно хз как оно там все.
Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.
Остальные ответы
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1)
"таблетки от всех болезней нет" - примете стандарт EnterpriseData будете работать с ним ,примете другой будете работать с другим
"Следуя из этого список отличий КД3.0 от КД2.0 можно свести к нескольким пунктам:
*результатом работы КД3.0 является код модуля менеджера обмена, состоящий из процедур и функций, в которых *реализована логика загрузки данных, представленных в формате EnterpriseData, а также логика выгрузки данных в формат;
*алгоритмы конвертации содержат код, выполняемый в одной конфигурации - той, для которой разрабатывается модуль конвертации;
*алгоритмы конвертации не несут в себе информации о внутреннем устройстве конфигурации-корреспондента, вместо этого они ориентированы на структуру формата EnterpriseData (для простоты разработки в КД3.0 объекты формата EnterpriseData представлены аналогично объектам метаданных 1С:Предприятие)."
какую технологию использовать разумнее КД2 или КД3
- Как вам удобнее ту и используйте!
"таблетки от всех болезней нет" - примете стандарт EnterpriseData будете работать с ним ,примете другой будете работать с другим
"Следуя из этого список отличий КД3.0 от КД2.0 можно свести к нескольким пунктам:
*результатом работы КД3.0 является код модуля менеджера обмена, состоящий из процедур и функций, в которых *реализована логика загрузки данных, представленных в формате EnterpriseData, а также логика выгрузки данных в формат;
*алгоритмы конвертации содержат код, выполняемый в одной конфигурации - той, для которой разрабатывается модуль конвертации;
*алгоритмы конвертации не несут в себе информации о внутреннем устройстве конфигурации-корреспондента, вместо этого они ориентированы на структуру формата EnterpriseData (для простоты разработки в КД3.0 объекты формата EnterpriseData представлены аналогично объектам метаданных 1С:Предприятие)."
(1)
Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б, С .....Ж п е. Основное волшебство в руках разработчика. Пользователи и заказчики вообще без понятия что там происходит и что это за буквы КД2, КД3.
Почему:
Минусы КД2
1) Трудность сопровождения: необходимо отслеживать изменения метаданных и актуализировать правила обмена данными. В типовых конфигурациях это происходит часто, поэтому обновление даже средних по сложности правил порой требует больших трудозатрат, нежели само обновление конфигурации т.к. требуется:
- проанализировать изменения и при необходимости изменить правила
- протестировать обмены на нестандартные ситуации, которые могут быть привнесены обновлением вендора
Для людей, далеких от программирования, обменов можно сказать - сопровождение дорогое.
2) Не развивается, не поддерживается.
Плюсы КД2:
Из-за того, что КД3 как раз решала основные узкие места КД2, к плюсам можно отнести
1) Если требования к составу обмена данными будут изменяться, сопровождение останется все таким же сложным, как и было.
2) разработка сравнительно проще для разработчика - разработка дешевле. Но это субъективно и зависит от ситуации. Что-то в КД3 проще разработчику, что-то в КД2 проще.
Минусы КД3:
1) Если требования к составу обмена данными будут изменяться, сопровождение может стать нереально сложным, что проклянете выбор КД3.
2) Из-за наличия стандарта некоторые вещи разрабатывать сложнее - разработка дороже. Но это субъективно и зависит от ситуации......
3) EnterpriseData уже будет нетиповой из-за нестандартного справочника.
Плюсы КД3
1) Основное преимущество КД3 - нет привязки к метаданным. Это облегчает сопровождение т.к. первая конфигурация выгружает свои данные в формат EnterpriseData. Вторая загружает данные из этого формата. При изменении конфигурации, правила меняются только на 1 стороне. Проще загружать данные из систем не на 1с.
Требуется в конфигурации, которая изменилась проверить выгрузку и загрузку. Вторую конфигурацию, как правило, подпиливать не нужно в 99%
2) Развивается, сопровождается
3) Вроде б как веб сервисы из коробки уже есть (БСП). Почти в реальном времени можно крутить, но я точно хз как оно там все.
Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.
Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б, С .....Ж п е. Основное волшебство в руках разработчика. Пользователи и заказчики вообще без понятия что там происходит и что это за буквы КД2, КД3.
Почему:
Минусы КД2
1) Трудность сопровождения: необходимо отслеживать изменения метаданных и актуализировать правила обмена данными. В типовых конфигурациях это происходит часто, поэтому обновление даже средних по сложности правил порой требует больших трудозатрат, нежели само обновление конфигурации т.к. требуется:
- проанализировать изменения и при необходимости изменить правила
- протестировать обмены на нестандартные ситуации, которые могут быть привнесены обновлением вендора
Для людей, далеких от программирования, обменов можно сказать - сопровождение дорогое.
2) Не развивается, не поддерживается.
Плюсы КД2:
Из-за того, что КД3 как раз решала основные узкие места КД2, к плюсам можно отнести
1) Если требования к составу обмена данными будут изменяться, сопровождение останется все таким же сложным, как и было.
2) разработка сравнительно проще для разработчика - разработка дешевле. Но это субъективно и зависит от ситуации. Что-то в КД3 проще разработчику, что-то в КД2 проще.
Минусы КД3:
1) Если требования к составу обмена данными будут изменяться, сопровождение может стать нереально сложным, что проклянете выбор КД3.
2) Из-за наличия стандарта некоторые вещи разрабатывать сложнее - разработка дороже. Но это субъективно и зависит от ситуации......
3) EnterpriseData уже будет нетиповой из-за нестандартного справочника.
Плюсы КД3
1) Основное преимущество КД3 - нет привязки к метаданным. Это облегчает сопровождение т.к. первая конфигурация выгружает свои данные в формат EnterpriseData. Вторая загружает данные из этого формата. При изменении конфигурации, правила меняются только на 1 стороне. Проще загружать данные из систем не на 1с.
Требуется в конфигурации, которая изменилась проверить выгрузку и загрузку. Вторую конфигурацию, как правило, подпиливать не нужно в 99%
2) Развивается, сопровождается
3) Вроде б как веб сервисы из коробки уже есть (БСП). Почти в реальном времени можно крутить, но я точно хз как оно там все.
Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.
(6)что в кд3 сделать проще, чем в кд2?
Вы лукавите, когда говорите о том, что в случае изменения структуры метаданных править придется только на одной стороне, при использовании кд3: обе стороны должны знать об изменениях.
Чтобы изменить правила Кд3 - нужно обновлять конфигурацию, в случае кд2 достаточно просто обновить правила перед выгрузкой данных + выгрузить данные по новым правилам, чтобы загрузка данных так же происходила с учетом изменений.
кд3 - это универсальный формат, на этом его плюсы заканчиваются и начинаются минусы.
Вы лукавите, когда говорите о том, что в случае изменения структуры метаданных править придется только на одной стороне, при использовании кд3: обе стороны должны знать об изменениях.
Чтобы изменить правила Кд3 - нужно обновлять конфигурацию, в случае кд2 достаточно просто обновить правила перед выгрузкой данных + выгрузить данные по новым правилам, чтобы загрузка данных так же происходила с учетом изменений.
кд3 - это универсальный формат, на этом его плюсы заканчиваются и начинаются минусы.
(7)
что в кд3 сделать проще, чем в кд2? - чуть внимательней прочитайте. КД2 разработка проще, КД3 разработка чуть сложнее
обе стороны должны знать об изменениях. - я переименую реквизит в конфигурации, должен изменить правила выгрузки в формат и правила загрузки из формата, зачем второй конфигурации, сайту, модулю на с++ знать об этом? Как он выгружался так и выгружается. Приведите свой пример.
Чтобы изменить правила Кд3 - нужно обновлять конфигурацию - в плане обмена можно выбрать внешнюю обработку, которая может быть модулем выгрузки/загрузки. Обновлять не обязательно.
Может вы плохо знаете КД3 ?
что в кд3 сделать проще, чем в кд2? - чуть внимательней прочитайте. КД2 разработка проще, КД3 разработка чуть сложнее
обе стороны должны знать об изменениях. - я переименую реквизит в конфигурации, должен изменить правила выгрузки в формат и правила загрузки из формата, зачем второй конфигурации, сайту, модулю на с++ знать об этом? Как он выгружался так и выгружается. Приведите свой пример.
Чтобы изменить правила Кд3 - нужно обновлять конфигурацию - в плане обмена можно выбрать внешнюю обработку, которая может быть модулем выгрузки/загрузки. Обновлять не обязательно.
Может вы плохо знаете КД3 ?
(16) Напомните мне, в архиве с правилами обмена КД2 лежат 3 файла, Правила обмена, Правила регистрации и Правила обмена корреспондента. Вот 3ий пункт, он не добавляет трудностей?
И вот это вот "редактирование при помощи текстового редактора" очень неудобное, когда правил больше 5.
И вот это вот "редактирование при помощи текстового редактора" очень неудобное, когда правил больше 5.
(17)
В рамках обсуждаемого переименования реквизита - нет. так же правится в текстовом редакторе при необходимости
Необходимость зависит от того, нужно ли из корреспондента получать что-то в переименованый реквизит.
Т.е. поправить больше 5 пусть даже внешних обработок - это удобно, а сделать исправления в 5 текстовых по-сути файлах - перестало быть удобным. Хорошо.
Напомните мне, в архиве с правилами обмена КД2 лежат 3 файла, Правила обмена, Правила регистрации и Правила обмена корреспондента. Вот 3ий пункт, он не добавляет трудностей?
В рамках обсуждаемого переименования реквизита - нет. так же правится в текстовом редакторе при необходимости
Необходимость зависит от того, нужно ли из корреспондента получать что-то в переименованый реквизит.
И вот это вот "редактирование при помощи текстового редактора" очень неудобное, когда правил больше 5.
Т.е. поправить больше 5 пусть даже внешних обработок - это удобно, а сделать исправления в 5 текстовых по-сути файлах - перестало быть удобным. Хорошо.
(19) Где я в расчетах ошибаюсь?
Правила регистрации (ПР)
Правила обмена (ПО)
Правила обмена корреспондента (ПОК)
Есть 1 шт УХ и 30 шт БУХ. Обмен в обе стороны.
Вариант 1) В БУХ переименовывается реквизит. Был Склад, стал МестоХранения.
КД2
В ПО БУХ изменяются правила, т.к нужно правильно выгрузить. Итого 30 изменений Склад на МестоХранения
В ПО УХ изменяются правила, т.к нужно правильно выгрузить. +30 изменений Склад на МестоХранения
В правилах ПОК УХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
От 60 до 120 изменений
КД3
В БУХ правилах выгрузки 30 изменений Склад на МестоХранения. Нужно правильно Выгрузить/Загрузить
В УХ 0 изменений, она как загружала/выгружала из формата, так будет дальше
30 изменений
Вариант 2) В УХ переименовывается реквизит. Был Склад, стал МестоХранения.
КД2
В ПО БУХ изменяются правила, т.к нужно правильно выгрузить. Итого 30 изменений Склад на МестоХранения
В ПО УХ изменяются правила, т.к нужно правильно выгрузить. +30 изменений Склад на МестоХранения
В правилах ПОК УХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
От 60 до 120 изменений
КД3
В БУХ 0 изменений. Они как загружали/выгружали из формата, так будут дальше
В УХ 1 изменений. Нужно правильно Выгрузить/Загрузить
Правила регистрации (ПР)
Правила обмена (ПО)
Правила обмена корреспондента (ПОК)
Есть 1 шт УХ и 30 шт БУХ. Обмен в обе стороны.
Вариант 1) В БУХ переименовывается реквизит. Был Склад, стал МестоХранения.
КД2
В ПО БУХ изменяются правила, т.к нужно правильно выгрузить. Итого 30 изменений Склад на МестоХранения
В ПО УХ изменяются правила, т.к нужно правильно выгрузить. +30 изменений Склад на МестоХранения
В правилах ПОК УХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
От 60 до 120 изменений
КД3
В БУХ правилах выгрузки 30 изменений Склад на МестоХранения. Нужно правильно Выгрузить/Загрузить
В УХ 0 изменений, она как загружала/выгружала из формата, так будет дальше
30 изменений
Вариант 2) В УХ переименовывается реквизит. Был Склад, стал МестоХранения.
КД2
В ПО БУХ изменяются правила, т.к нужно правильно выгрузить. Итого 30 изменений Склад на МестоХранения
В ПО УХ изменяются правила, т.к нужно правильно выгрузить. +30 изменений Склад на МестоХранения
В правилах ПОК УХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
От 60 до 120 изменений
КД3
В БУХ 0 изменений. Они как загружали/выгружали из формата, так будут дальше
В УХ 1 изменений. Нужно правильно Выгрузить/Загрузить
(20)Ваша ошибка в расчетах:
Этого не нужно делать, т.к. уже изменились ПО для БУХ и УХ.
З0 изменений нужно сделать в том случае, если правила ну прям совсем разные. В идеальном случае: 1 правило для всех 30 БУХ и 1 правило для 1 УХ.
В правилах ПОК УХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
Этого не нужно делать, т.к. уже изменились ПО для БУХ и УХ.
З0 изменений нужно сделать в том случае, если правила ну прям совсем разные. В идеальном случае: 1 правило для всех 30 БУХ и 1 правило для 1 УХ.
(21)
Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б
Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.
Что я не так написал?
Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б
Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.
Что я не так написал?
(23)
Причем здесь ЗУП?......)))
Итак вопрос автора темы:
какая аргументация может быть использована для обоснования выбора ?
Аргументацию я привёл. Автор как-нибудь там разберется.
кд3 - это универсальный формат, на этом его плюсы заканчиваются и начинаются минусы.
все еще придерживаетесь этой точки зрения?
Причем здесь ЗУП?......)))
Итак вопрос автора темы:
какая аргументация может быть использована для обоснования выбора ?
Аргументацию я привёл. Автор как-нибудь там разберется.
кд3 - это универсальный формат, на этом его плюсы заканчиваются и начинаются минусы.
все еще придерживаетесь этой точки зрения?
(22)
На всякий случай проинформирую, что технология обмена в формате EnterpriseData подразумевает доработку XDTO пакета. Если без новой сущности не обойтись, создаём свой формат на основе типового и добавляем туда любые сущности. Размещаем пакет и правила в расширении.
Получается основной минус ED можно устранить. Какие ещё минусы остались? )
дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData
На всякий случай проинформирую, что технология обмена в формате EnterpriseData подразумевает доработку XDTO пакета. Если без новой сущности не обойтись, создаём свой формат на основе типового и добавляем туда любые сущности. Размещаем пакет и правила в расширении.
Получается основной минус ED можно устранить. Какие ещё минусы остались? )
(29) Например из-за того, что современные автомобили становятся всё сложнее и невозможно их качественно обслуживать в гаражном сервисе, их не стали меньше покупать.
Так же и с современными технологиями обмена. Некачественное обслуживание - это не минус технологии, это минус исполнителю.
У КД2 тоже есть подобные проблемы. Правила, созданные вручную в полуавтоматическом режиме как-то приятнее редактировать и обслуживать, чем типовые. Там увлеклись программным формированием данных к выгрузке и пропала возможность мышкой интерактивно поправить правила. Нужно лезть в код. Это в зависимости от личных предпочтений тоже можно отнести к плюсам или минусам.
Всё субъективно.
Так же и с современными технологиями обмена. Некачественное обслуживание - это не минус технологии, это минус исполнителю.
У КД2 тоже есть подобные проблемы. Правила, созданные вручную в полуавтоматическом режиме как-то приятнее редактировать и обслуживать, чем типовые. Там увлеклись программным формированием данных к выгрузке и пропала возможность мышкой интерактивно поправить правила. Нужно лезть в код. Это в зависимости от личных предпочтений тоже можно отнести к плюсам или минусам.
Всё субъективно.
Обмен, написанный на КД3, прозрачен и прост для доработки прямо общем модуле. В обмене КД2 не так просто оперативно отладить код и внести исправления.
При обслуживании 30-ти баз правила обмена для КД2 придётся обновлять во всех базах и следить за синхронностью обновления конфигураций.
КД3 нечувствительна к версии конфигурации, дорабатывать и обновлять можно в произвольное время или вовсе не обновлять какую-нибудь конфигурацию
Обмен в КД3 есть штатно в базах, используются планы обмена. Синхронизацию на КД2 там почти всю выпилили.
И многое зависит от специалиста, который обслуживает обмен.
При обслуживании 30-ти баз правила обмена для КД2 придётся обновлять во всех базах и следить за синхронностью обновления конфигураций.
КД3 нечувствительна к версии конфигурации, дорабатывать и обновлять можно в произвольное время или вовсе не обновлять какую-нибудь конфигурацию
Обмен в КД3 есть штатно в базах, используются планы обмена. Синхронизацию на КД2 там почти всю выпилили.
И многое зависит от специалиста, который обслуживает обмен.
(12) Тут всё просто. Если зная преимущества КД3 появляются такие вопросы, используйте КД2. )
Каждый специалист использует механизм в рамках своих знаний и умений. Можно найти сотню плюсов и минусов при желании.
У меня уже лет 5 как используется универсальная процедура, которая выгружает все реквизиты шапки, не задействованные в ED. Если добавили реквизит в шапку, правила можно не трогать. Они автоматически выгрузят значение нового реквизита и если в другой базе есть такой же, загрузят его.
В типовых правилах ED этого нет, но возможности формата ED позволяют так делать.
Каждый специалист использует механизм в рамках своих знаний и умений. Можно найти сотню плюсов и минусов при желании.
У меня уже лет 5 как используется универсальная процедура, которая выгружает все реквизиты шапки, не задействованные в ED. Если добавили реквизит в шапку, правила можно не трогать. Они автоматически выгрузят значение нового реквизита и если в другой базе есть такой же, загрузят его.
В типовых правилах ED этого нет, но возможности формата ED позволяют так делать.
(14) Потерял нить о какой возможности лично я не знаю в КД2 и при чем тут собственно я при обсуждении принятия решения автором топика? )У каждого инструмента свои возможности. Нужно лишь правильно их использовать к конкретной задаче.
И по поводу конфигурации конвертация данных 3.1 хотелось бы напомнить, что в ней можно редактировать правила как для XDTO, т.е. ED, так и для xml, которые КД2. И правила регистрации.
Поэтому через несколько лет нас могут не понять, если использовать КД2 и КД3 в обсуждении.
И по поводу конфигурации конвертация данных 3.1 хотелось бы напомнить, что в ней можно редактировать правила как для XDTO, т.е. ED, так и для xml, которые КД2. И правила регистрации.
Поэтому через несколько лет нас могут не понять, если использовать КД2 и КД3 в обсуждении.
Нужно понимать, что КД3 выгружает все объекты в стандартный формат ED. Если ваших объектов в этом формате нет - вы не можете их использовать. Если в ваших объектах есть поля, которых нет в ED - вы будете выгружать/загружать их через AdditionalInfo, то есть руками. Либо вы будете править XDTO-пакеты и в целом вкорячивать свои корявки. В целом, перенос любых нетиповых данных тут же делает КД3/ED неуниверсальным, и, естественно, требует доработки на обеих сторонах. Есть вариант вообще выгружать все реквизиты объекта в AdditionalInfo а в приемнике разбирать их, правда, зачем в этой ситуации КД3 как таковая - непонятно, можно вообще выгружать штатными средствами в строку/XML/JSON.
КД2 в этом плане несколько универсальнее, позволяет единообразно переносить любые объекты не опираясь ни на какие существующие структуры, но и она не идеальна.
КД2 в этом плане несколько универсальнее, позволяет единообразно переносить любые объекты не опираясь ни на какие существующие структуры, но и она не идеальна.
1) КД2 но не просто КД2
2) Сделать расширение с общими метаданными распространить его по всем БП с которыми планируется обмен
2.1) В УХ добавить подписки которые регистрируют данные к отправке в переферийки в регистре(без плана обмена или с планом обмена как угодно, но я бы делал без плана) поскольку вы будете генерировать Сообщения в регистре, типа создай в такой базе элемент справочника, с такими то реквизитами. И уже эти данные отправлял бы в переферийку
3) Правила КД2 должны работать только с этими метаданными. При выгрузке из центральной вы должны помещать данные в Регистр расширения или справочник расширения. (таким образом вы решите проблем изменения метаданных при обновлении БП
4) Обработка которая будет запускаться из внешних по расписанию, которая будет тащить данные из регистров и создавать необходимые для вас движения.
Соответственно цепочка такая.
1) Делаем Расширения с регистрами справочниками которые будут переноситься из Управления Холдингом в регистр расширения расположенного в БП.
2) Пишем правила, с отборами и параметрами выгрузки необходимыми для наполнения каждой из БП
3) При выгрузке из УХ данные попаадают в каждую из баз в ограниченном необходимом для каждой из баз составе.
4) В каждой из баз присутсвует обработка, которая из записей регистров генерирует, документы Эта обработка может присутствовать как в Расширении так, и в виде внешей,
5) Таким образом вы получаете генерацию документов из регистров обмена, можете спокойно обновлять БП, в случае изменения типовых документов, вам будет достаточно изменить обработку генерации данных. (удобно для отладки)
Почему не КД3
Потому, что с кд3 вам придется очень много гемороится при рассогласовании регистров, но в целом пункт 1-3 можно реализовать и на 1-3 тогда затрагиваемые метаданные не будут менятся.
Искуственная шина данных у вас получится, реализовать генерацию на кд2 и кд3 я бы не стал, поскольку это довольно трудоемко для поддержки. А так у вас получается
1) Простая выгрузка генерация данных которая не МЕНЯЕТСЯ.
2) И обработка в которой заложена вся бизнес логика генерация данных в целевых базах
2) Сделать расширение с общими метаданными распространить его по всем БП с которыми планируется обмен
2.1) В УХ добавить подписки которые регистрируют данные к отправке в переферийки в регистре(без плана обмена или с планом обмена как угодно, но я бы делал без плана) поскольку вы будете генерировать Сообщения в регистре, типа создай в такой базе элемент справочника, с такими то реквизитами. И уже эти данные отправлял бы в переферийку
3) Правила КД2 должны работать только с этими метаданными. При выгрузке из центральной вы должны помещать данные в Регистр расширения или справочник расширения. (таким образом вы решите проблем изменения метаданных при обновлении БП
4) Обработка которая будет запускаться из внешних по расписанию, которая будет тащить данные из регистров и создавать необходимые для вас движения.
Соответственно цепочка такая.
1) Делаем Расширения с регистрами справочниками которые будут переноситься из Управления Холдингом в регистр расширения расположенного в БП.
2) Пишем правила, с отборами и параметрами выгрузки необходимыми для наполнения каждой из БП
3) При выгрузке из УХ данные попаадают в каждую из баз в ограниченном необходимом для каждой из баз составе.
4) В каждой из баз присутсвует обработка, которая из записей регистров генерирует, документы Эта обработка может присутствовать как в Расширении так, и в виде внешей,
5) Таким образом вы получаете генерацию документов из регистров обмена, можете спокойно обновлять БП, в случае изменения типовых документов, вам будет достаточно изменить обработку генерации данных. (удобно для отладки)
Почему не КД3
Потому, что с кд3 вам придется очень много гемороится при рассогласовании регистров, но в целом пункт 1-3 можно реализовать и на 1-3 тогда затрагиваемые метаданные не будут менятся.
Искуственная шина данных у вас получится, реализовать генерацию на кд2 и кд3 я бы не стал, поскольку это довольно трудоемко для поддержки. А так у вас получается
1) Простая выгрузка генерация данных которая не МЕНЯЕТСЯ.
2) И обработка в которой заложена вся бизнес логика генерация данных в целевых базах
(32) Добрый день! а как в этом решении сопоставлять элементы старых справочников ?
Для КД2 желателен уникальный набор реквизитов , либо по Гуид (что тянет с собой работу в периферийных базах по замене ссылок )
КД3 предлагает использовать "Соответствие объектов информационной базы" в рамках собственного типового инструментария
новые - понятно как появится - сделаны в ЦБ , перенесены в ПБ, ок . если элемент перенесен с Гуид из ЦБ - проблем нет
Для КД2 желателен уникальный набор реквизитов , либо по Гуид (что тянет с собой работу в периферийных базах по замене ссылок )
КД3 предлагает использовать "Соответствие объектов информационной базы" в рамках собственного типового инструментария
новые - понятно как появится - сделаны в ЦБ , перенесены в ПБ, ок . если элемент перенесен с Гуид из ЦБ - проблем нет
(32)
Добрый день!
правильно ли я понял эту идею? :
1) делается расширение с требуемым набором метаданных к передаче вовне
те все справочники с их шапками и табличными частями, все требуемые документы.
+ регистр в который будут складываться объекты к переносу с данными о адресации
критерий - достаточной данных к передаче (например контрагента нужно сделать но его контактные лица могут быть не нужны, тк они не нужны в периферийных базах)
делаем подписки регистрации к обмену.
Пользователь записал справочник - мы склонировали его в расширении и сделали запись в регистре
Пользователь записал документ - мы рекурсивно собрали ссылки в документе и перенесли документ и весь ссылочный тип из документа в расширение.
таким образом у нас в расширении лежат данные предназначенные исключительно к отправки или получения.
делаются правила КД2 по метаданным расширения кстати структура метаданных для кд2 выгружается с учетом новых объектов в расширении?
не будет ли проблем сделать правила для объектов из расширения?
передаются на сторону получателя и локально уже из данных регистра и связанных объектов делаются объекты в типовой части.
Добрый день!
правильно ли я понял эту идею? :
1) делается расширение с требуемым набором метаданных к передаче вовне
те все справочники с их шапками и табличными частями, все требуемые документы.
+ регистр в который будут складываться объекты к переносу с данными о адресации
критерий - достаточной данных к передаче (например контрагента нужно сделать но его контактные лица могут быть не нужны, тк они не нужны в периферийных базах)
делаем подписки регистрации к обмену.
Пользователь записал справочник - мы склонировали его в расширении и сделали запись в регистре
Пользователь записал документ - мы рекурсивно собрали ссылки в документе и перенесли документ и весь ссылочный тип из документа в расширение.
таким образом у нас в расширении лежат данные предназначенные исключительно к отправки или получения.
делаются правила КД2 по метаданным расширения кстати структура метаданных для кд2 выгружается с учетом новых объектов в расширении?
не будет ли проблем сделать правила для объектов из расширения?
передаются на сторону получателя и локально уже из данных регистра и связанных объектов делаются объекты в типовой части.
Прикрепленные файлы:
делаются правила КД2 по метаданным расширения кстати структура метаданных для кд2 выгружается с учетом новых объектов в расширении?
да, поскольку обработка "выгрузка метаданных для КД2" запускается из предприятия, где метаданные расширения доступны. Да и если будут проблемы, при генерации правил, можно ручкам добавлять реквизиты. Это не составляет труда.
правильно ли я понял эту идею? :
В целом да, но упустили пару моментов.
В правилах стоит отбор на выгружаемые данные для целевой базы, правила по сути простые они генерируют те же записи в том же расширении, но уже в целевой базе.
Вся логика генерация типовых документов заложена будет в обработку которая будет считывать загруженные в регистр расширения целевой базы данные и генерировать из них типовые документы/справочники/данные.
Обработка является по сути ключевой. Подписки и регистр, просто фиксируют данные к отправке. Правила выгружают эти данные в целевые базы.
А обработка в каждой базе, генерирует из них справочники и документы.
Обработка может запускаться как по регл. так и ручками. С персональными настройками сохраненными для каждой базы.
Можно конечно добавить, функционал обработки сразу в правила, ПослеЗагрузкиДанных.
Но я бы не стал, учитывая ваше количество целевых баз, они могут отличатся, и со временем это вызовет множество коллизий, таких как разные релизы и не совместимость правил, а разными релизами, а так вы вырубаете вопрос совместимости только на уровень обработки которая генерирует данные.
Плюс отлаживать это будет не так удобно, как вам может показаться.