Author Archives: Vic_torya

Итак, вам нужно перейти на «восьмерку»…

В этой статье представлена методика перехода для средней или крупной торговой компании из близкого к типовому решения на базе конфигурации «Торговля и склад» (ТиС) на современную платформу версии 8, в базу данных с конфигурацией близкой к типовой «Управление торговлей» (УТ).

Проблемы штурмового перехода из ТиС в УТ знакомы лишь тем, кто в этом принимал непосредственное участие. Отсутствие же такого опыта у человека, принимающего решение о переходе внутри своей компании, естественно, ведь переход осуществляется один раз. Часто подобный переход происходит одновременно с ротацией ИТ персонала: сокращается количество тех, кто поддерживал 7.7, и нанимаются те, кто будет поддерживать 8.х. В таких условиях сборную ИТ команду нельзя назвать сработанной. Кто же является основным источником информации при переходе? Продающая сторона.

Дай Бог, чтобы внедренец со стороны поставщика продукта появился ещё на стадии обсуждения покупки. Бывают и такие случаи, когда покупатель знакомится с внедренцем уже после приобретения и установки (силами сборной ИТ) решения УТ. В таких крайних вариантах внедрения УТ появление внедренца от поставщика похоже на появление чертенка, который выпрыгивает из табакерки с криком «Ну что! Встряли!».

Методика постепенного перехода, представленная в этой статье, позволяет сперва увидеть свои учетные данные в базе УТ, продолжая работать в базах ТиС. И уже гладя на конечный результат, принимать решение о сроках и остальных этапах перехода.

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

Вы можете оставить роботов работать неограниченно долго, не ломая настроенный документооборот, и даже вовсе не переходя на «восьмерку» в некоторых подразделениях

Как же робот «узнает», какие документы изменились в базе данных ТиС? Неужели придется покупать компоненту УРБД или автор предлагает использовать её без покупки?

Информацию об измененных документах робот узнает из журнала записи интерактивных действий пользователей (файл 1cv7.mlg)

Туда могут не попадать действия с документами и справочниками, которые производятся через написанные ИТ службой (или кем-то ещё) обработки, если при написании этих обработок авторы не озаботились записью информации о произведенных изменениях. Конечно в таком случае эти обработки нужно «доделать». Обработки с диска ИТС написанные специалистами Фирмы «1С»  для баз данных на платформе 7.7 имеют в наборе своих алгоритмов процедуры записи выполняемых изменений, использование этих обработок не ведет к потере информации об измененных объектах в журнале 1cv7.mlg, и робот может принимать решение о загрузке соответствующих измененных документов или справочников в базу УТ.

Основной идеей построения решения была конвертация идентификаторов ссылочных сущностей (справочники, документы) из того вида, в котором они хранятся в базах 7.7, к виду в котором они хранятся в 8.х

Для тех, кто видел как данные записаны в файлах наглядным будет такое пояснение:

{«B»,»»,»796″,»»,» 34222МАГ»} -> {7fd98943-5c4c-08b9-0317-99f235792bbf}

Такой подход к конвертации позволит не тащить всякий раз при обмене информацию о наборе полей поиска соответствия справочников и документов, а также не тащить все выгруженные по ссылкам данные, связанные с выгружаемым объектом. Для таких простых объектов, как к примеру, справочники «банки» или «валюты», можно даже не хранить соответствия идентификаторов элементов в базе 7.7 и в базе 8.х, для случая, когда база данных 7.7 только одна. Для более сложных сущностей, таких как элементы справочника «контрагенты», приходится держать такой регистр соответствий для того чтобы «сливать» элемент справочника «Сторонние юридические лица» и элемент справочника «Контрагенты» из базы 7.7 в один элемент справочника «Контрагенты» в базе 8.х, а также для того, чтобы «сливать» в один элемент справочника в базе 8.х одинаковые элементы справочника «Контрагенты» в разных базах 7.7 (для разных Юридических лиц в компании). То есть различия в методиках учета сущностей для баз ТиС и УТ ставят задачу разделить один элемент из ТиС на две (или больше) сущности в зависимости от контекста использования в УТ или же наоборот слить несколько дублирующих сущность элементров из ТиС в один элемент из УТ.

Основное методическое решение для учета контрагентов: пара ИНН + КПП означает одного уникального контрагента. Заполнение данных по контрагенту реализовано через web-сервис для баз данных ЕГРЮЛ и ЕГРИП.

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

Особое внимание при переносе нужно обратить на стандартизацию. В моих алгоритмах переноса стандартизируются адреса доставок и другая адресная информация согласно классификатору ФИАС, а большинство адресов успешно геокодируюся.

Зачастую случается так, что в базах ТиС имеющих более чем годовую историю использования, накапливаются нестандартизированные адреса, телефоны. Как и с контрагентами, правильно заполненными считаются данные из ФИАС, а старые значения адресов с приписками на тему кого и когда спрашивать можно сохранять в наименовании соответствующего справочника или в поле комментария для регистра контактной информации.

Правила обмена данными имеют особенности построения.

Как и при использовании «Конвертации данных» от поставщика, без некоторого дополнительного понимания особенностей процесса переноса данных и методик учета в алгоритмах конфигураций ТиС и УТ (ну, то есть вообще с нуля), свои собственные правила для переноса написать нельзя. Здесь приведу в качестве примера ситуацию, когда один и тот же договор («Основной») используется в ТиС и для продажи, и для поставки, а в УТ согласно реализованным методикам учета договора должны быть разными и иметь разные признаки отношений «с покупателем» и «с поставщиком» соответственно. Анализ того, как эта ситуация отработана в моем решении, позволяет наглядно увидеть архитектуру обмена данными изнутри. Сначала документ (пусть к примеру поставки) преобразовывается согласно правилам в объект базы данных документ вида «ПоступлениеТоваровУслуг», затем происходит анализ заполненных в объекте реквизитов и для тех сущностей, которых в базе УТ ещё нет, происходит их запрос из базы ТиС. Все объекты сериализуются и записываются в пакет для загрузки.

Ни одна битая ссылка в базу данных не загружается вместе с новым объектом. Так происходит «раннее связывание»

В момент загрузки пакета для каждого объекта вызывается процедура, которая выполняется прежде любой подписки на события связанные с записью объекта. Внутри этой процедуры выполняется «позднее связывание» уже сырого объекта из ТиС и методики учета таких объектов в УТ. Вернемся к загружаемому документу из нашего примера: в случае если договор с этим контрагентом («Основной») ранее уже был загружен в контексте отношений «с покупателем», то создается новая копия объекта «договор», для которой признак отношений устанавливается «с поставщиком». Что же будет когда в обмен из ТиС попадет оплата по этому договору? В данном приведенном примере вся оплата ляжет на отношения «с покупателем», потому как первое сопоставление идентификаторов произошло в контексте загрузки документов продажи.

Правила обмена интуитивно понятны программисту 1С.

Вот пример

  // Справочник Проекты

РегистрыСведений.ОписанияОбъектовОбмена.УстановитьПравилоОбменаДанными("B/796", ТекущаяБаза, "СтрМенеджерОбъекта", "Справочник.Проекты");
РегистрыСведений.ОписанияОбъектовОбмена.УстановитьПравилоОбменаДанными("B/796", ТекущаяБаза, "ОписаниеРеквизитов", "B/796/Реквизиты");
    
РегистрыСведений.ОписанияОбъектовОбмена.УстановитьПравилоОбменаДанными("B/796/Реквизиты", ТекущаяБаза, "Родитель", "Скрипт~ОбменСИП77СкриптыПостобработка~ЗаписатьДляНовых~Ссылка.Родитель~ТолькоДляНовых");
РегистрыСведений.ОписанияОбъектовОбмена.УстановитьПравилоОбменаДанными("B/796/Реквизиты", ТекущаяБаза, "ТипГруппы", "Ссылка.ТипГруппы");
РегистрыСведений.ОписанияОбъектовОбмена.УстановитьПравилоОбменаДанными("B/796/Реквизиты", ТекущаяБаза, "Телефон", "Ссылка.Телефон");
РегистрыСведений.ОписанияОбъектовОбмена.УстановитьПравилоОбменаДанными("B/796/Реквизиты", ТекущаяБаза, "КодПартнера", "Ссылка.КодПартнера");

Почему не «Конвертация данных» (КД)? Наше решение обеспечивает автономность, скорость, автоматическое определение измененных объектов, плавность процесса перехода. Нет угрозы остановки учетной системы предприятия, аврального перехода. Переход с помощью КД этого обеспечить не может.

Ещё раз пройдемся по архитектуре формирования базы перехода в предлагаемой методике:

1. Регистрация измененного объекта в базе ТиС в журнале 1cv7.mlg.
2. Автоматическая выборка записей журнала регистрации регламентным заданием в базе УТ согласно заданного расписания — гибкая настройка частоты появления в УТ
   1. Новых документов.
   2. Запрос данных измененного объекта с использованием OLE взаимодействия с запущеным сеансом работы в ТиС.
   3. «Раннее связывание» ссылок и значений данных в полученном объекте, дополнительные запросы в ТиС для ссылок в УТ на отсутствующие документы и справочники (которые представляются в базе данных как <объект не найден>).
   4. Сериализация всех новых согласованных и связанных объектов и запись их в пакет для загрузки.
   5. Запись десериализованных объектов из пакета в базу УТ и «позднее связывание» полученных сущностей с методиками их нового учета в УТ.
   6. Проведение записанных документов.

   В завершение статьи я приведу один примечательный факт о производительности выгрузки, реализованной согласно описанной методике: остатки по складу на 1 500 строк в документе из базы ТиС в базу УТ были загружены менее, чем за 40 секунд.

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

   Лаптев П.А.
   Odin23.ru