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" запускается из предприятия, где метаданные расширения доступны. Да и если будут проблемы, при генерации правил, можно ручкам добавлять реквизиты. Это не составляет труда.
правильно ли я понял эту идею? :
В целом да, но упустили пару моментов.
В правилах стоит отбор на выгружаемые данные для целевой базы, правила по сути простые они генерируют те же записи в том же расширении, но уже в целевой базе.
Вся логика генерация типовых документов заложена будет в обработку которая будет считывать загруженные в регистр расширения целевой базы данные и генерировать из них типовые документы/справочники/данные.
Обработка является по сути ключевой. Подписки и регистр, просто фиксируют данные к отправке. Правила выгружают эти данные в целевые базы.
А обработка в каждой базе, генерирует из них справочники и документы.
Обработка может запускаться как по регл. так и ручками. С персональными настройками сохраненными для каждой базы.
Можно конечно добавить, функционал обработки сразу в правила, ПослеЗагрузкиДанных.
Но я бы не стал, учитывая ваше количество целевых баз, они могут отличатся, и со временем это вызовет множество коллизий, таких как разные релизы и не совместимость правил, а разными релизами, а так вы вырубаете вопрос совместимости только на уровень обработки которая генерирует данные.
Плюс отлаживать это будет не так удобно, как вам может показаться.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот