Подробные характеристики книги В. Филатов '1С:Предприятие 8. Название: 1С:Предприятие 8. Конвертация данных: обмен данными между прикладными решениями (+ CD) Авторы: Бояркин В. Э., Филатов А. Год издания: 2008 Число страниц: 187 Формат: DjVu Размер: 23.5 Mb Качество: Нормальное Язык: Русский. Описание: Практическое пособие по использованию программы 1С:Предприятие, наиболее распространенной системы автоматизации работы предприятия. Именно эта программа позволяет использовать статистические данные для решения различных задач управления и учета.

1. С Предприятие 8 Конвертация Данных Скачать
2. С Предприятие 8 Конвертация Данных Pdf
3. С Предприятие 8 Конвертация Данных Скачать Бесплатно
4. С Предприятие 8 Конвертация Данных

Итак, у вас имеется две системы с совершенно различной конфигурацией. Как правило между такими системами настраиваются планы обмена, которые выгружают/загружают данные по правилам обмена. Эти самые правила обмена удобно написать в конфигурации 'Конвертация данных'. Так же, эта конфигурация пригодится для выгрузки/загрузки данных обработкой 'Универсальный обмен данными XML', имеющейся в любой типовой конфигурации. (Если в вашей системе вы не видите данную обработку встроенной, скачайте её и воспользуйтесь как внешней). Если между системами настроены планы обмена, то в случае записи/проведении объекта в центральном узле, данный объект регистрируется для распределенного узла.

Сочи - Сумочка 08. Парагвай - Скорострел 07. Мистер БЫДЛОЦЫКЛ - Какого 06. Ленинград - Обезьяна и орёл 09. ЙОП ШОУ - Между нами 05.

Вот эти зарегистрированные объекты выгружаются по 'Правилам выгрузки данных' (ПВД), стрелка 1. ПВД необходимо для выгрузки конкретных объекта (ов), например, документов 'НачислениеОценочныхОбязательствПоОтпускам'. Для реквизитов этого документа, имеющих ссылочный тип, например, реквизит 'Организация' с типом 'СправочникСсылка.Организации' ПВД для выгрузки справочника 'Организации' не нужно (ниже в разделе ПКО описано подробнее). Стандартная выборка (стрелка 2) содержит в себе все реквизиты объекта, включая табличные части. В ПВД указано Правило конвертации объекта (ПКО) (стрелка 3), в данном примере это 'НачислениеОценочныхОбязательствПоОтпускам', все ПКО располагаются на первой закладке. С левой стороны имеются обработчики: 'Перед обработкой', 'Перед выгрузкой', 'После выгрузки', 'После обработки' (стрелка 4).

В каждом из этих обработчиков при вызове 'Информации по обработчикам' (стрелка 5) можно получить сведения о выполняемых в нём действиях и его параметрах (в каждом обработчике они немного различаются). Например, обработчик 'Перед обработкой': В Информации по тексту ниже указан вот такой пример: Если Объект.ЭтоГруппа = 0 Тогда Отказ = 1; КонецЕсли; Можно написать своё условие: например, если реквизит 'Флаг' установлен в Истину, тогда такой объект нужно выгрузить по другому ПКО: Если Объект.Флаг Тогда ИмяПКО = 'ИмяПравилаКонвертацииТакогоОбъекта'; КонецЕсли; В случае, если при выгрузке вы пользуетесь произвольным алгоритмом, вам необходимо инициировать параметр ВыборкаДанных (стрелка 6 на втором рисунке). ПКО Теперь перейдем к нашему ПКО (стрелка 7), состоящему из правил конвертации свойств (ПКС): Ссылочные свойства выгружаются по указанным ПКО (стрелка 8). Обратите внимание, что в этом случае в ПВД конвертация не войдёт. При выгрузке документа реквизиты 'Организация' и 'Ответственный' будут выгружены по ПКО 'Организации' и 'Пользователи' без участия ПВД для этих справочников. Другими словами, ПВД для справочников 'Организации' и 'Пользователи' вообще может не быть.

ПВД нужны для выгрузки зарегистрированных объектов, участвующих в обмене, или для выгрузки необходимых вам объектов обработкой 'Универсальный обмен данными XML'. Если вам не нужны все элементы справочника центральной базы в периферийной базе, а нужны только те, которые фигурируют в документах, ПВД для них не нужны.

Если вы не выгружаете все элементы справочника с помощью ПВД, то в ПКО вы указываете правила поиска объекта: Признак (Стрелка 10) не задан, следовательно, в случае, если объект не найден, он будет создан по правилам конвертации свойств данного объекта, в данном случае - элемент справочника 'Организации'. Дополнения: Обратите внимание, на втором сверху рисунке я обозначила раздел 'Важно' стрелкой 6, так вот стрелка 11 - это тот самый признак, который необходимо установить, если вы используете произвольный алгоритм для ПВД. Не забывайте пользоваться информацией по обработчикам (стрелка 12). Если вы решили выгружать все изменения справочников и документов, то обратите внимание в ПВД на закладку 'Дополнительно', там задан 'Порядок выполнения'.

С Предприятие 8 Конвертация Данных Скачать

По ссылкам ниже вы можете почерпнуть дополнительную информацию: Создание с нуля (кратко) У нас есть конфигурация источник и конфигурация приемник (они могут быть идентичными). В случае, если конфигурации различаются, в каждой из конфигураций нужно запустить обработку 'MD82Exp.epf' или 'MD83Exp.epf', в зависимости от версии платформы. Как-то по особому называть файлик выгрузки не нужно.

При загрузке система сама определит наименование конфигурации. Далее выгруженную структуру (структуры) загружаем в конвертацию. Далее выбираем на рабочем столе конвертации пиктограмму 'Правила обмена данными', нажимаем 'Добавить' и в открывшемся окне выбираем конфиггурации.

При появлении картинки ниже, жмите или 'Закрыть' или 'Создать новое правило обмена данными'. Загрузка имеющихся правил (кратко) В случае, если правила есть и их требуется исправить, загружаем правила в КД. Если структура конфигурации была загружена только правилами, то в ней может не быть многих объектов. Чтобы объекты добавить, вам нужно выгрузить структуру метаданных (описано в пункте 'Создание с нуля' немного выше). И далее загрузить эту структуру в имеющуюся конфигурацию. Конвертация данных - это инструмент создания переноса для ленивых.

Умея пользоваться этим инструментом можно быстренько набросать правила и перекинуть из одной базы 1С в другую базу, не обязательно в 1С. Но для реально сложных и постоянных обменов я бы его не рекомендовал. У меня были случаи когда вреда от использования КД было намного больше, чем если бы, долго но качественно, написал свою выгрузку-загрузку через dbf или txt с разделителями. 1) Например обработками из состава КД не контролируется дата запрета редактирования, и можно легко завалить базу в закрытом периоде. Когда данные потащатся по ссылкам.

Найдут эту ошибку через несколько недель, когда будет поздно откатывать из архива. Потом трудозатратное восстановление затертых данных. 2) Отладиться и поймать ошибку в коде, можно, но нужно обладать опытом и сноровкой. 3) Обработки универсального обмена громоздки с плохо читаемым кодом. 4) Файл обмена громоздкий, т.к. Содержит текст правил обмена. Структура файла не очень понятна простому смертному.

Например Нпп - это номер по порядку и т.д. 5) В случае изменения структуры хотя бы одного реквизита приемника или источника, весь обмен перестает работать, пока заного не перегрузишь конфигурации. Это сильно напрягает, когда конфигурация громоздкая, и постоянно ведется ее доработка или обновления. Например если изменили тип реквизита 'строка 100 символов' на 'строка неограниченной длины', будет ошибка несоответстия типов, хотя это никак не влияет на обмен. 6) Свой самописный обмен, проще отлаживать, понятная логика и структура файла, надежнее в использовании, файл меньше размером, не нужно гонять правила в файле. Но разрабатывать дольше по времени.

Каждый выбирает свое. Для этого предусмотрены события вызываемые перед загрузкой объектов в целевую БД, вот там та и нужно проверять закрыт период или нет 2. Ну есть сложности, однако если правила не автоматически создаются, то ошибки легко находятся, так как все своими золотыми ручками делалось 3.

Ну так пишите правила, которые не будут тянуть за собой все данные из базы, а только те что действительно нужны. Файл на выходе не предназначен для конечного юзера, да как и для программиста, это уже из разряда хакерства туда лезть ну или с точки зрения прогера контроль результата 5. Ну к слову сказать, в некоторых ситуациях выгружать конфигурацию свежую не имеет смысла, так как к реквизитам объектов можно обращаться не только, если они явно есть в структуре конфигурации, у вас же под рукой язык программирования с поздним связыванием, к реквизиту можно из кода событий обращаться 6. Сталкивался я с вручную написанными обменами, ничего хорошего, люди могут еще более странным образом так на извращаться, что мама не горюй. Не соглашусь, КД - унифицированный механизм создания правил обмена. Фразы типа 'Лучше я сам напишу своими методами' - ошибочна в большинстве случаев (ошибки переноса объектов, недостаток данных, применимость в узкой среде 'моя конфа-моя конфа'.). 1) Игнорирование/Контроль даты запрета редактирования можно учесть в правилах 2) Отладка - механизм обычной притирки специалиста к работе с конфой 3) Обработки универсального обмена вообще не должны заботить 4) Громоздкость файла обмена - архивируй, в большинстве случаев рукописные варианты (особенно dbf) тяжелее размерами и сложнее в логике.

5) Ну, тут не учтешь и в рукописном обмене 6) 'Свой самописный обмен, проще отлаживать, понятная логика и структура файла' - вообще, простите, дурь. Свой самописный обмен это свои написанные правила обмена, а унификация средст разработки дает возможность другим читать и править легче, так как (о Боже, сколько рукописок я видел) каждый пишет как топор ляжет, то дальнейшее сопровождение другим человеком облегчается. Я не имею права судить Ваши проф качества, но комментарий больше походит на 'Я так привык, а другие делают не правильно!' Раз 20 писал правила на КД разной сложности, и несколько сотен раз свои механизмы обмена, это личной опыт, использования этого инструмента. Про контроль даты запрета, понятно, что после того как на грабли наступишь, будешь уже втыкать проверки во все возможные обработчики. ТС написал статью для новичков, моя задача их предупредить о всех подводных камнях.

Ни слова не писал, что я так привык а другие делают не правильно, старался объективно написать все приемущества и недостатки данного инструмента, с которыми столкнутся новички. Свой обмен - это ни какие не правила, нет там вообще правил, забудьте про термины навязываемые фирмой 1С. По личному опыту, написал свой обмен и забыл на долгие долгие годы. А правила обмена, постоянно требуют вмешательства, практически после каждого обновления. А во времена медленного интернета и дорогово траффика, когда обмен работает по расписанию с интервалом 15 минут, от них больше вреда было чем пользы. Самих данных с гулькин нос, зато правила тащим туда-сюда. 6) Видел пару обменов самописных.

Вот там неделю пришлось копаться только для того, чтобы выловить одну небольшую, но неприятную ошибку. А когда нашли, то еще неделю ломали голову, как ее исправить, т.к. Структура обработки не позволяла исправить это быстро.

В самописном обмене хорошо разбирается только тот, кто его писал. Другой будет копаться только по необходимости (хорошо, если необходимость возникает редко). Если в организацию придет новый человек, то потребуется больше времени на изучение каждой самописки, чем один раз изучить конвертацию. Конвертация - это универсальный механизм. А за универсальность всегда приходится платить. 6) Свой самописный обмен, проще отлаживать, понятная логика и структура файла, надежнее в использовании, файл меньше размером, не нужно гонять правила в файле.

Но разрабатывать дольше по времени. Самый быстрый обмен - это прямая заливка на T-SQL из источника в приемник, без всяких промежуточных файлов и прочего. Но, чтобы напр., написать такой обмен, который бы как и КД тащил все по ссылке, предположим для какого-нибудь типового документа типа РТУ - вы потратите времени столько, сколько на разработку правил для всей конфигурации. Кроме того, в процессе оптимизации, вы придете к еще более сложному варианту когда хранимки хранятся на сервере, вьюшки имеют русские имена и их нужно актуализировать и еще много такой вот магии. Я этого говорю не на бла-бла-бла, а как чел, который ранее такие обмены и писал.

С Предприятие 8 Конвертация Данных Pdf

Поверите ли на слово, но поддерживать такой обмен в актуальном состоянии и тем более баго-фиксить и трейсить - это задача не на, а в - В несколько раз сложнее чем на любой КД. Поэтому, в последствии, я все всем переписал на КД.

Да медленнее, иногда значительно медленнее, но очень просто поддерживаемый и любые вопросы по нему, решаются относительно просто. Аналогичные вопросы на скулевом обмене решаются всегда на стороне скуля и надо обладать хорошими скилами не только в T-SQL как таковом, но и хорошем понимании 'внутренней' кухни самой платформы. В итоге, я сейчас, с позиции именно практического опыта, не могу представить - когда я еще буду писать такие велосипедные обмены на скуле. Конвертация данных, редакция 3.0 (далее КД3.0) - это инструмент для разработки обменов, предполагающих наличие посредника передачи данных между конфигурациями в виде универсального формата данных EnterpriseData. В этом качестве КД3.0 является одним из компонентов технологии обмена данными через формат EnterpriseData. КД3.0 не является заменой конфигурации Конвертация данных, редакция 2.0 (далее КД2.0), но аналогична ей по характеру решаемых задач, общий смысл которых сводится к упрощению разработки логики конвертации данных за счет представления ее объектной модели. Все типовые стараются на 3.0 переписывать.

Но 2.0 будет еще долго актуальна. Сам интуитивно понимал, что КД 3 усвоится лучше, когда есть понимание КД 2 Вот тут я полностью не согласен. Я проходил кук и оратор из (22) по Курс Насипова и Гилева смотри по КД 2 - действительно вещь!!! Думал стоит или нет изучать 3.0 и как раз подвернулся сдвоеный курс 2.0 и 3.0 'кратко, быстро и доступно' - прошел в первом потоке и разочаровался. По 2.0 все связно и лаконично как в полном курсе, а вот 3.0 внес вообще полную кашу - там вообще все по другому и курс был сыроват - много осталось по части 3.0 негатива у многих - надеюсь поправили больше года уже прошло. ИМХО: КД2 - попроще и попонятнее. Я перенос из Бух 7,7 на УПП1,3 делал сам, давно и без вводного курса.

КД2 связывает конфа - конф. КД3 связывает конфа - конф ы (разные) Ну это как я понял из вводного курса:)))) Кстати, картинка из (18) это подтверждает. Вот самое доступное объяснение которое я слышал про то - в чем же разница между КД 2.0 и 3.0, и где плюсы. Есть три конфигурации A, B, C между которыми настроены обмен. Теперь внимание на скрин, и читаем: - Для КД 2.0 будет существовать 6 наборов правил. Для 3.0 - описывается каждый раз не обмен двух баз с различными структурами, а одной базы с универсальным форматом EnterpriseData. Для каждой базы надо написать и выгрузку в этот формат и загрузку из этого формата.

С Предприятие 8 Конвертация Данных Скачать Бесплатно

Вот тут боюсь соврать в силу неопытности работы с КД 3.0: с одной стороны это тоже 6 правил, с другой - это три правила, т.к. Двусторонний обмен с ED рассматривается в контексте одной базы. Теперь предположим что конфигурация 'B' была сильно изменена. Тогда - необходимо учитывать изменения для всех правил между A-B и B-C - для КД 2.0. Это 4 правила.

С Предприятие 8 Конвертация Данных

А для КД 3.0 только два - те, что обменивается с универсальным форматом.