ВНЕДРЕНИЕ 1С:ERP и 1С:Управление холдингом     Главная     Проекты, результаты     Консультации (Новый раздел!!)     Обратная связь. Отзывы, рекомендации    
 












Интеграция & Обмены данными

Обмен данными 1с 8.2 и 7.7



Содержание статьи:

  1. Вступительная часть.
  2. Основные способы организации обмена данными между информационными базами "1С:Предприятия".
  3. Моя методика обмена данными: пример использования.
1. Вступительная часть

Прошло уже более 8-ми лет, как фирма «1С» выпустила на рынок первое прикладное решение «Управление торговлей» на платформе «1С:Предприятие 8.0», однако многие серьезные компании до сих пор используют в своей работе программы на платформе «1С:Предприятие 7.7».

Т.е. «как минимум» часть информационных баз этих компаний существует и продолжает работать «на семерке». Конечно, большинство руководителей понимают, что следует перейти на более современные программные продукты, однако на практике – все сложнее.

И причины – разные, но для адекватного понимая общей ситуации (в этой сфере), перечислю основные:

1) Организационная неготовность к "решительному" переходу на «восьмерку».

а) Суть в том, что 8-ка более сложная система. И требуется более качественного выстраивания и управления бизнес-процессами компании.

б) Нужны дополнительные ресурсы: финансовые, кадровые, временные. И к тому же «8-ку» нужно покупать, а «семерка» (почти у всех) уже есть :-) .

с) Процесс перехода сопряжен с рисками, что особенно чувствительно в кризисный период в экономике.

Однако, есть еще несколько весьма значимых (для понимания ситуации) фактора:

2) За последние 8-лет количество новых (открывающихся) бизнесов резко сократилось (т.е по сравнению с концом 90-х годов, когда открылось большинство существующих предприятий).

Как раз в конце 90-х появление 1С 7.7 удачно сопутствовало процессу открытия многих новых предприятий.

И даже, если предприятия уже существовали, то процесс перехода (с EXCEL, ACCESS и "самописных" программ) был резким и решительным.

3) За прошедшие годы компании успели вложить много ресурсов (финансовых, временных и т.д.) в настройку и адаптацию «своих семерок». А необходимость новых вложений (уже в «восьмерку») многих отпугивает.

4) И хотя «восьмерка» (особенно последняя платформа 8.2 и ее прикладные решения) имеют множество полезных и привлекательных функций (по сравнению с «семеркой»): все равно, «семерка» до сих пор может решать (особенно при работе в терминальном режиме) многие важные задачи.

К тому же, стандартные возможности «семерки» давно уже можно расширить, за счет использования различных «надстроек» и компонент. Лучшими примерами, по моей оценке, являются : 1C++ и ToySQL.

Я в своей методике обмена данными (см. 3-ю часть статьи) использую ToySQL (см: Библиотека метазапросов), и это весьма очень эффективно.
....................

И так, существуют две основных стратегии перехода с 1С 7.7 на 1C 8:
  • (1) «Решительная» стратегия. Функционал 77 полностью вытесняется и заменяется 8.
Конфигурация прикладного решения 8 дорабатывается (адаптируется) под бизнес-процессы компании.

При этом, некоторые бизнес-процессы предприятия уже оптимизируют (изменяют), с учетом имеющейся архитектуры прикладного решения на платформы 8.

А далее («в один прекрасный день» :-) ) компания перестает работать в информационной базе 7.7: к этому моменту в информационную базу 1C:8 уже должны быть перенесены (загружены) все необходимые для работы данные (из 1C:77).

Скажу прямо: по моему мнению всегда (когда это, конечно, возможно), лучше выбирать «решительную стратегию». И обязательно нужно фиксировать сроки перехода и жестко отстаивать их соблюдение. Это крайне важно!

При этом, нужно понимать, что «решительный» переход с 7.7 на 8 - это всегда проект. Часто – сложный.

А проектов без сроков не бывает. Т.е «если нет сроков – нет проекта». Это аксиома, многократно подтвержденная практикой.

И тем не менее (:-(), чаще так случается, часто выбирать «решительную» стратегию нельзя. Точнее сказать, что в этом случае проект потерпит фиаско.

И причина опять таки в том, что решительный переход – это проект, а как раз к проектам (и особенно серьезным) многие компании, увы, не готовы (о чем я как раз и писал ранее).

  • (2) Стратегия «постепенного» перехода. Т.е в процессе перехода существуют одновременно и работают информационные базы на 7.7 и на 8. Общая тенденция – постепенное вытеснение 7.7 за счет 8.

    Т.е работа в базе 7.7 прекращается после того, когда все пользователи «переведены» на 8.
Если у компании нет возможностей (ресурсов) «к решительному» переходу, то остается вариант «постепенного перехода».

Однако, необходимо ясно понимать, что осуществить хороший «постепенный переход» (в итоге) получится сложнее, чем «решительный».

Среди причин : и неопределенная растянутость по срокам, и необходимость принимать верные решения «по ходу дела», и необходимость работы + сопровождения нескольких программ + технические вопросы интеграции (обмена данными) между программами.

Далее, как раз техническим вопросам организации обмена данными между 1С 8.2 и 7.7 и будет посвящена данная статья.

Обмен данными будет рассматриваться, приемущественно, с позиции «постепенного» перехода.

2. Основные способы организации обмена данными между информационными базами "1С:Предприятия".

Основные способы организации обмена состоят в следующем:
  • Способ № 1: выгрузка, а затем - загрузка данных между базами «А» и «В».
  • Способ № 2: передача данных между базами путем подключения базы «В» к «А». Далее «B» можно использовать как источник (или приемник) данных.
Сразу замечу, что (1) способ можно использовать во всех ситуациях. Т.е это - универсальный подход и в этом его приемущества. А вот (2) подход можно использовать только, если есть возможность «подключения базы В к базе А».

Т.е если между базами «A» и «В» нельзя обеспечить (устойчивое) подключение, то без выгрузки и загрузки данных (варианта №1) ни как не обойтись.

Однако, если информационные базы, например, расположены в единой локальной сети или (тем более) на одном сервере, то появляется альтернатива использовать вариант (2).

Сложностью (при любом из способов обмена) всегда является т.н. сериализация объектов, т.е необходимость упаковать объект в структуру, состоящую из примитивных типов. А далее, эта структура:
  • либо выгружается в файл, а затем загружается из него в базе-приемнике (в нашем примере «B»), и там необходимо будет создать (собрать из структуры) соответствующий базе «А» новый объект.
  • либо объект сериализуется и структура передается (но уже без выгрузи/загрузки в файлы) в базу «В». И после этого, в базе «B» нужно создать (собрать) новый объект, соответствующий базе «А».
Сразу нужно отметить, что готовый механизм сериализации произвольного объекта заложен в платформу 1С 8. Суть его - в преобразовании объекта в XML-структуру.

Так же важно отменить, что в 1С:8 у объектов есть глобальный уникальный идентификатор (GIUD) и это тоже здорово помогает при организации обмена и синхронизации данных на платформе 1С 8.

Таким образом получается, что задача переноса объекта между информационными базами 1C:8 с одной структурой (объекта) является тривиальной и давно решенной. Это делается (например) типовыми обработками.

И даже, если вы не хотите использовать выгрузку-загрузку через файлы, то все равно можно использовать типовую XML-сериализацию.

А вот для обмена данными между 1С 7.7 и 1C 8 эту сериализацию (а так же GUIDы) уже не применишь.
Т.е необходимо, каким либо образом создавать механизмы конвертации и состыковки объектов между базами источника и приемника.

Однако и здесь «1С» предусмотрела мощное средство, для быстрого создания таких механизмов и осуществления обмена данными. Это средство – конфигурация «Конвертация данных», текущая редакция - 2.

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

Получается, что вопрос уже решен и однозначно следует выбирать «конвертацию данных» ?

Мой ответ: если выбрали «решительную» стратегию перехода с 1С 7.7 на 1С 8, то «ДА».


Однако
, если вы выбрали «постепенную» стратегию, то «НЕ ФАКТ».

Т.е. если процесс перехода будет сложным, по этапным, растянутым по времени, то скорее всего вы «ощутите на себе» так сказать «отрицательные стороны» этой технологии (этого подхода):

  • (1) В процессе работы механизмов конвертации могут (и, к сожалению, возникают) ошибки. Чем сложней обмен, тем сложней их «отловить» и исправить.
  • (2) «Конвертация» особенная хороша, когда конфигурации источника и приемника являются типовыми или близки к типовым «1С» (или схожи между собой), тогда большинство правил конвертации уже написано за нас (или формируется конструктором в автоматическом режиме :-)).
Т.е быстрота создания правил "с лихвой" компенсирует их качество. Тем более, если обмен данными единоразовый, то какой смысл вкладываться в одноразовые программы?.

Получается , что для одноразовой выгрузки-загрузки это «прокатит». А отдельные «косяки» можно будет подправить (доделать) после завершения основного этапа переноса данных. Так всегда и поступают.

Но, если:
  • обмен данными должен проходить многократно;
  • в «каких-то случаях» данные должны повторно выгружаться и перезагружаться, в каких-то нет;
  • или нужно выгружать и загружать данные в зависимости от меняющихся условий;
  • или нужно создавать сложные алгоритмы выборки данных (что актуально для переноса данных из разросшихся семерочных баз).
то - конструктор (мастер автоматического формирования) правил конвертации вам мало поможет.

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

  • (3) И наконец, очень важно понимать, что акцент технологии «конвертации данных» сделан на выгрузку.

Т.е выгружаются (максимально) все необходимые данные + правила обмена. А в момент загрузки (в соответствии с полученными правилами) выполняется загрузка.

Это можно сравнить с ситуацией из жизни, когда человек отправляется в дальнюю дорогу.. Он не знает «будут ли» (и «понадобяться ли») ему лекарства по месту прибытия. И по этой причине, он берет все ему необходимое, т.е «в прок».

Таким образом, для сложных, многократных обменов данными (тем более если "не парится" на тему планов обмена) размеры XML – файлов могут сильно разрастаться. А это замедляет выгрузку и загрузку данных, а еще усложняет поиск «косяков» и отладку программ.

------------------
Далее, в этой статьи будет рассказано о моей методике обмена данными, которую использую я использую для задач «постепенного перехода» c 1C 7.7 на 1С 8.2.

Тип задачи, которая будет рассматриваться, – импорт данных в 1С 8.2 из 1С 7.7.

В данной методика я использую способ (2) организации обмена : т.е. без выгрузки – загрузки данных, а выполняю подключение базы 1С 7.7 к базе 1С 8.2.

Технически, для этого используется Ole-соединение (интерфейс v77.application).

К сожалению (в отличие от 1С 8 ) «семерка» не поддерживает режим com-соединения; есть только интерфейс v77.application.

Надо признать, что это – минус: ole соединение не является таким надежным и быстрым как хотелось бы :-).

И все же, механизм этот - «рабочий»; и многие его используют.
--------------------
Важным для понимания еще является такой вопрос:
  • Использовать внешнюю базу как источник или приемник данных ?
  • или (в другой формулировке): что реализовывать «импорт данных» или «экспорт данных» ?
Я считаю, что ответ прост: всегда (когда это возможно) реализовывайте импорт данных. Внешнюю базу используйте как источник данных.

Если вы работаете с 1С 7.7 (а здесь будет ole-соединение), и захотите что – либо «экспортировать» по ole, то должны понимать, что семерка не поддерживает транзакции при ole-соединении. Таким образом, вы рискуете, что экспорт данных «сорвется».

В случае же импорта - «все в ваших руках». Вам достаточно получить (по ole) объекты (в сериализованном виде + ссылки на них) и все.

Далее, все ответственные операции по записи данных вы можете осуществлять в «базе-импортере», нормально использовать транзакции, попытки-исключения и все остальное.
--------------------

Особенностью моей методики является тесное (одновременное, в едином програмном контексте) использование объектов как 1С:8 так и 1С:7.7.

Таким образом, получается достаточно «продвинутое» Ole.
----------------------
И наконец, еще одной важной особенностью технологии является использовании метазапросов. Для этих целей я подключаю к 1С 7.7 и использую внешняя библиотеку ToySQL.

Приемущества этого подхода состоят в том, что я получаю из 1С 7.7, в табличном виде, нужные мне (отобранные, сгруппированные и т.д.) данные, которые далее удобно загружать в 1С 8.

Табличный вид - простой, но при этом его и хватает (достаточно) для многих задач сериализации объектов.

Возможности языка метазапросов ТoqSQL позволяют провести предварительную обработку и упаковку (сериализацию) данных на стороне 1С 7.7.

Для выгрузки данных мне не нужно писать код на 1С 7.7 – весь код выгрузки я пишу и отлаживаю в консоли метазапросов (собственной разработки), что очень удобно.

При этом, если в процессе загрузки данных, выясняется, что нужны какие-то еще данные из "семерки", то я обращаюсь к ней по средствам ole-подключения и «забираю» эти данные.


3. Моя методика обмена данными: пример использования

Итак, опишу подробнее методику импорта данных (в базу 1С:8 из базы 1C:7.7), которую удобно использовать для решения примерно таких задач (привожу пример):


Краткая постановка задачи:

  1. Оперативный учет фирма ведет в 1С:7.7. В некой конфигурации оформляются все операции по движению товара; товары учитываются на различных складах (цеховая кладовая, пандус склада, зона брака и т.д.), далее - перемещаются между складами. По каждому из складов оформляются документы инвентаризации. Каждый склад относится к какой-либо организации (юр. лицу), но в разрезе «юр. лиц» в 1С:7.7 учет не ведется.
  2. Регламентный учет, в разрезе «юр.лиц», фирма ведет в 1С:8.2 Бухгалтерии. При этом, деления на «внутренние склады» в бухгалтерии нет, то есть все учитывается на «основном складе».
  3. Необходимо: обеспечить автоматическое заполнение фактического количества товара в документе «Инвентаризация товаров на складе» 1С Бухгалтерии 8.2.

    Заполнение табличной части документа «Инвентаризация товаров на складе» должно осуществляться по кнопке «Заполнить фактическими данными из 1С:7.7».

    При этом, по указанной (в документе инвентаризации 1С:8) организации (юр. лицу) и дате документа необходимо:
  • "собрать" все соответствующие документы инвентаризация (из 1С:7.7);
  • подсчитать суммарное количество по каждому товару
  • Загрузить полученные данные в документ «Инвентаризация» 1С:8.2.

    При этом, нужно заполнять колонку «Фактическое количество». Если есть остатки по номенклатуре, (которой нет в базе в 1С:8.2), то эту номенклатуру нужно загрузить (перенести) в 1С 8.2.

Комментарии к реализации:
  • (1) Для взаимодействия с базой 1С:7.7 со стороны базы 1С:8.2 устанавливается Olе соединение.
  • (2) Для получения и агрегации данных (группировка по складам, по указанной организации и дате) используется библиотека метазазапросов (внешняя компонента ТoySQL). Текст метазапроса и параметры (дата, юр. лицо) передаются (через Ole – соединение) из 1С: 8.2 в 1С: 7.7.

    Для передачи запроса, а так же для обратного получения результата используется отдельная экспортная функция глобального модуля.
  • (3) Результат запроса возвращается в 1С 8.2 в виде объекта «Таблица значений», и далее происходит:
    • Загрузка номенклатуры (если необходимо)
    • Загрузка данных о фактическом количестве в документ «Инвентаризация товаров»
  • (4) В конфигурацию 1С Бухгалтерии 8.2 нет необходимости вносить ни строчки кода – вся действия и обработка данных выполняется во внешней обработке (подключенной для документа «Инвентаризация» как обработчик заполнения табличной части).
Структурная схема решения:
Пояснения к реализации:

.......
....
...
...
y
...

На этом, все.

.$.
Открыть

    © 2011 Горский Михаил.