Всем привет!
Задача.
У клиента имеются две однотипные (подобные) файловые базы на УТ 10.3. В них ведутся продажи в разных магазинах. Каталог товаров одинаковый, артикулы товаров уникальны (уникальность поддерживается программно). Розничные цены приходится проставлять отдельно в каждой базе. Каталог товаров "прилетает" из центральной базы дистрибьютора. Базы не распределенные (технология РИБ не используется).
Требуется настроить обмен между двумя базами магазинов так, чтобы розничные цены и дисконтные карты покупателей мигрировали из одной базы в другую и совпадали. Среди баз нельзя выделить главную и подчиненную - цены и диск. карты задаются в любой базе.
Анализ постановки задачи.
1) Обмен диск. картами.
Диск. карты покупателей представляют собой справочник Информационные карты, уникальность диск. карт поддерживается и проверяется по номеру телефона, указанному в качестве Наименования и реквизита КодКарты. У диск. карты есть также реквизит ВладелецКарты (тип справ. Контрагенты), в котором прописывается имя покупателя - более ничего.
Итак, по диск. картам имеем два основных параметра-идентификатора покупателя: телефон и имя покупателя. Я решил, что можно не использовать универсальный механизм обмена через xml-файл, можно попробовать реализовать обмен через csv-файл вида:
телефон1;Имя1;
телефон2;Имя2;
телефон3;Имя3;
Для того, чтобы понимать какие диск. карты добавились и чтобы выгрузить их в другую базу, используется механизм платформы 1С - механизм регистрации изменений - для этого надо использовать объект метаданных ПланыОбмена и встроенный механизм сообщений.
2) Обмен ценами на товар.
Цены на товары хранятся в регистре сведений ЦеныНоменклатуры. Это "связанный" регистр - подчиненный документу Установка цен номенклатуры.
Для цен товаров нужно знать только уникальный артикул товара и последнюю (текущую) розничную цену - формат файла обмена такой:
Артикул1;ЦенаБезДисконта1;ЦенаСДисконтом1;
Артикул2;ЦенаБезДисконта2;ЦенаСДисконтом2;
Артикул3;ЦенаБезДисконта3;ЦенаСДисконтом3;
Цены по товарам будут выгружаться отдельным csv-файлом. Регистрация изменений производится через объект ПланОбмена также, как и для диск. карт.
В целом получается, что система 1С всегда знает, какие изменились цены и на какой товар, какие диск. карты добавились. Регистрация изменений происходит автоматически (см. рис. 1).
Чтобы выгрузить диск. карты и цены я использовал такую конструкцию - см. рис. 2 и 3.
Для подготовки файла по ценам сначала я готовлю таблицу значений - накапливаю информацию о том, по какой номенклатуре произошли изменения в ценах. Изменения могут произойти как в прошлых ценах, так и в закупочных ценах - ни те, ни другие сведения для выгрузки не подходят.
Поэтому таблица значений с номенклатурой предварительно обрабатывается. По измененной номенклатуре я определяю последние розничные цены и выгружаю их. Так как в программе используются диск. карты, значит будет две цены - без дисконта и с дисконтом.
Напишу наперед, что при загрузке цен я предварительно обрабатываю сведения - установлена проверка на то, что если загружаемые цены не отличаются от имеющихся розничных, то загрузка не производится. Также при загрузке установлена проверка на последнюю дату установки цен в базе-приемнике, которая сравнивается с датой из базы-источника.
Проверок при выгрузке и при загрузке можно написать много и разных - это будет зависеть от вашей задачи. Я же хочу акцентировать внимание и продемонстрировать применение смешанного способа для обмена данными между двумя базами - при этом базы не обязательно должны быть подобными и однотипными (идентичными или однородными).
Чтобы не копить и удалять изменения в базах, которые выгрузились и загрузились в другую базу, я использовал такую конструкцию - см. рис. 4.
Номера отправленного и принятого сообщений я отправляю первой строкой csv-файла:
НомерОтправленного;НомерПринятого;
Создание диск. карт и задания новых цен по списку артикулов отнесены в отдельные процедуры. Процедуры простые, но с разными проверками: к примеру, сначала произвожу поиск номенклатуры по артикулу, или по ценам - сначала определяю последние розничные цены, затем сравниваю их с полученными сведениями, принимаю решение загружать или нет.
Первоначальная оценка работ составила 6 часов (по 3 часа на диск. карты и цены). И это с учетом того, что у меня были наработки использования csv-файлов, обменов через ФТП, использования планов обмена классическими способами (например, для идентичных конфигураций).
По факту, тестирование и написание разного рода проверок и технологических нюансов платформы заняло 3,5 дня. Если бы я заранее разглядел весь айсберг работ (не только верхушку, но и подводную часть), самой работы не случилось бы.
И это правда жизни нашей работы - зачастую бесценный опыт мы получаем забесплатно.
Выводы. Для решения задачи я применил смешанный способ - использовал для регистрации изменений План обмена и механизм сообщений, а для выгрузки-загрузки данных - использовал Обмен с помощью файлов *.csv.
Научился выгружать и загружать новые справочники и документы для разного рода конфигураций (не обязательно идентичных) для случаев, когда передаваемую информацию легко представить текстовым файлом формата *.csv или *.txt - для дальнейшего последовательного чтения. Недостатки и плюсы подобного способа - понятны из реализации. Взял на вооружение подобный способ!
На этом все.
Всем добра!