Есть две конфы
Одна, назовем ее самописанной, вторая - УТ 11.5
УТ будет собирать данные, обобщать и вываливать их на сайт (битрикс) через стандартные механизмы.

Начал делать обмены через COM, но отпал вариант из-за невозможности держать одинаковые версии сервера для УТ и других баз.
Вот сейчас ломаю голову над тем, как сделать

ХТТП, Веб сервисы?
Может другой вариант

Поделитесь, у кого был опыт настройки таких обменов.

Через планы обмена не предлагать)

Точнее, предлагать можно, но я их рассматриваю в последнюю очередь.

(0)

Планы обмена и конвертация 2.0, 3.0 -- не умеете или ... ?

можно не план, а РС для регистрации использовать

(0) как сделаешь, так и будет

а так как душе угодно - sftp по расписанию, веб-сервис в самопиське (чтобы по запросу данные отдавала)...

(3) Я знал что ты извращенец ,но чтоб настолько)

(5) сам ты извращенец )) на больших объемах - самое то, иначе можно покласть на базу

(0)

а) Регистрация изменений: План обмена, регистр сведений, бумажка+карандаш
б) Механизм выгрузку/загрузки изменений: -- конвертация 2.0, 3.0, что-то своё
в) Транспорт: каталог с файлами, http-сервис, com, ftp

В чём проблема-то?

Уточню про объем данных.

в УТ будет стекаться информация из 3-4 баз данных (у всех одна конфигурация) по номенклатуре и ее остатках на складах

Перечень номенклатуры в каждой базе ~16 тыс позиций, но эти позиции на 99% пересекаются между собой.
т.е. в УТ будут примерно те же 16 тыс наименований.

Пока предполагается, что при каждом обмене будут передаваться не изменения остатков, а все остатки на каждом складе.

(2) с КД не хочу заморачиваться, там свои сложности. В частности, одна и та же номенклатура в разных базах должна быть одной карточкой в УТ.
Честно, даже не думал, как это реализовать в УТ.

Более того, УТ будет в дальнейшем источником по созданию номенклатуры в других базах (через 1С Номенклатура в УТ будут создаваться элементы, другие базы будут брать инфо из УТ)

Это медицинские товары.

(7) так я и прошу поделиться опытом, кто на чем делал и сейчас, обладая знаниями текущими, сделал бы по другому или нет.
Примерно так

(9) Так может сначала выполнить задачу "УТ будет в дальнейшем источником по созданию номенклатуры в других базах"? И остальное легче пойдет.

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

(10) Конвертация долго муторно - как 10 лет назад было что если понимаешь что делаешь через файлы самое быстрое и легкое.

(10)

0) Написать хоть какое подобие тех.задания.
Хотя бы тезисы
Хотя бы нюансы
Хотя бы чеклист
Чтобы потом не пролюбить какую-нибудь мелочь

1)
Типовые вещи: номенклатура, характеристика, единица измерения, склад -- написать кд20, план обмена
{От пары дней до бесконечности}

2) Остатки (раз уже вы все выгружаете): дело хозяйское, хоть XML-файл своего формата
{Полдня на написать две обработки "для этой базы" и "для той", еще день на попить кофе}

(14) "хоть XML-файл своего формата" - зачем? Почему xml?

Тех.Задание:
1. Развернуть РИБ.
...

(15) Ну не хотите XML ? Пусть будет CSV или DBF или "любые три буквы" ?

(11) нужно уже имеющуюся номенклатуру как-то положить в УТ, причем, обработать одинаковые карточки из разных баз.

а правила создания номенклатуры из УТ будут позднее доработаны.

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

(14) Я сейчас как раз на этапе создания ТЗ.

По номенклатуре сразу выбираешь базу источник либо при создании шлешь в главную с таким же уидом - избавит от многих проблем. Ну или если нужна наглядность тупо коды одинаковые с разным префиксом.

+(14) я начинал это делать на COM
Базовая часть уже сделана (сохранение идентификаторов объектов в УТ из источников и их сопоставление с данными УТ)
Загрузка номенклатуры (создание, при необходимости)

(21) см (22).

(22) com - не кросплатформенно и долго. HTTPсервисы или Odata.

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

(25) я начинал на ком делать, потом, когда стало ясно, что версии серверов 100% будут разные, я и переключился на сервисы.
КД не рассматривается.

(0) >Может другой вариант

Есть замечательный вариант: "Нанять программиста"

(0) тут 2 задачи: регистрация/синхронизация(поля поиска?) изменений данных и транспорт сообщений, решайте их отдельно

(27)+ опытного, который в теме современных технологий конечно же
в разных вариантах могут быть разные варианты технологий обмена

для общего развития: https://infostart.ru/1c/articles/792952/

(26) Ну так сделай РИБ для выгрузки номенклатуры и обмен по ХТТП для получения остатков. Будет быстро и малодежно.   Как я понимаю УТ - это просто база, где в отличии от кучи других рабочих, есть вся библиотека для работы с сайтом, ИТС.

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

(24) точно. оДата же еще есть.

(30) Вместо внедрения обмена с 1С битрикс в самописку, я решил сделать через отдельную базу, которая уже умеет с битриксом работать штатно.

Кста если выгрузка в битрикс то это не быстро на таком объеме. Возможно надо будет костылить, учитывая (30) - так действително правильней.

(33) там 5 файлов - запутатся сложно

(33) >решил сделать через отдельную базу, которая уже умеет с битриксом работать штатно

[злодейский закадровый смех]

(36) есть причины для этого

а про какие объемы данных обмена с битриксом идет речь?

если там много позиций номенклатуры и часто меняются они и остатки то гм

(5) как бесит практик. Отказ от регистрации изменений в пользу РС

и не проще сразу начать с
https://dev.1c-bitrix.ru/rest_help/index.php
https://dev.1c-bitrix.ru/rest_help/rest_sum/start.php

(38) ГМ? не понял что это.
(40) гляну, спс

(36) Номенклатура - это лекарственные препараты. В разных базах бардак. Надо все привести к единому виду + сейчас законодательно в сфере лекарств наводят порядок.

Было решено формировать единый справочник на базе сервиса 1С:Номенклатура в отдельной базе. Куплена конфа управление аптечной сетью. В дальнейшем прорабатывается переход на эту конфигурацию для учета. Поэтому и такое решение с ведением номенклатуры в этой базе.
И еще: внедрять 1С Номенклатура в текущую конфигурацию (это чужая разработка) нецелесообразно по ряду причин (в частности, невозможность договориться с правообладателем)

(40) у него сайт на битриксе а не цэрээм

(42) ага. интернет-магазин

(42) какая нахрен разница?
https://dev.1c-bitrix.ru/rest_help/sale/index.php

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

(41) >Номенклатура - это лекарственные препараты

У вас номенклатура это партия поставки или сочетание МНН + ТРН + Форма выпуска + Дозировка + Фасовка?

(41) >внедрять 1С Номенклатура в текущую конфигурацию (это чужая разработка)

что за чужая разработка? может автор тут ))

(46) условно
у заказчика в одной базе: аспирин таблетки 500 мг
во второй: аспирин таб. 500 мг
в третьей: таб.аспирин 500

На сайте, есс-но, надо, чтобы все эти 3 позиции из разных баз выгружались одной позицией и все данные были как в ЕСКЛП.

Исходя из того, что известно на данный момент, на сайте должно отображаться, что в продаже есть: Аспирин, табл. 500 мг, бл. 10, пач. картон. 1 (взято из ЕСКЛП, заказчик хочет синхронизацию по ШК)
Должна быть указана минимальная цена, по которой можно купить данный лекарственный препарат в этой аптечной сети.

(48) я в курсе, мне объяснять не надо ))
много лет в фарме провел, не одна написанная конфа

и вот вопрос и был КАК?
как собираетесь делать "механизм аналогов"

(48) Аспирин =  ТРН
таблетки = Форма выпуска
500 мг = Дозировка
еще должна быть фасовка, например X30 (сиа) или N30 (протек)

(50)+ Международное непатентованное название (МНН) = Ацетилсалициловая кислота

(51) поэтому и задействован ЕСКЛП как базовый справочник

(48) Кстати уже в  курсе про особенность ценообразования ЛС?
Что одно наименование, одна серия и партия но закупили у разных поставщиков = разная цена не только закупки но еще и продажи?

Т.е. вы это в интернет магазине собираетесь одной позицией (номенклатурой) отображать?
Только вопрос с какой ценой

Или несколькими идентичными кроме цены?

(52) Он неполный относительно РЛС

(54)+ Лучше сразу на МДЛП завязываться а не на ЕСКЛП

Про "механизм аналогов" не думал, да и задачи такой не было.
Стартовая задача выгрузить остатки на сайт.
Моя часть - выгрузка на сайт.
Работа движка сайта - это уже не моя компетенция, там другие люди работают.
Но, подозреваю, что аналоги можно по действующему веществу подбирать. Эта информация из ЕСКЛП грузится. она есть в справочниках номенклатуры в УТ.

Кстати, конфа не совсем УТ. там УАС (управление аптечной сетью).

+(55) в 1С Номенклатура вроде сборная солянка из ЕСКЛП + МДЛП

И да кроме ЛП есть еще изделия медицинского назначения
Их тоже надо предусмотреть
Ну и всякие БАДы и прочее что не подпадает под МДЛП

у нас 1С ИТС Медицина.
Там вроде есть все. Или почти все.

(56) действующих веществ может быть несколько в одном МНН - это предусмотрели?
или как обычно создаем/заводим новое ДВ = "ксилометазолин+декспантенол" :)

(54) ага. уже обломались с картинками и инструкциями

(58) сейчас не знаю, давно не работал с фармой
но раньше это была бесполезная почти хрень

(61) https://v8.1c.ru/its/docs/spravochnik-lekarstvennykh-preparatov/
Вот что там есть.

+(59) кстати, в карточке аптечного товара вижу только один элемент справочника "ДВ"

(63) как обычно ))
да очень мало препаратов где два, три и более ДВ
но они есть и надо по ним правильно искать
понимать что это составные по действующему веществу а не просто есть некие вспомогательные в составе

По теме

УТ11.5 бесполезная штука в данном случае для фармацевтики (ЛС или ЛП)
Для использования вместо прокладки между своей самописной конфой и Битриксом

Делайте сразу свой модуль обмена с битрикс или берите готовый и адаптируйте
Для структуризации НСИ лучше всего навать свою конфу - и это отдельная хотя и связанная задача

(65) я выше уточнил, что конфа 1С Управление аптечной сетью.

(66) УАС на базе УТ11.4 хрень
Лучше 1С Розница Аптека (она пока на основе Розница 2.3)
https://solutions.1c.ru/catalog/drugstore/features

Там есть
"Для поддержки мультиканальности продаж, реализована интеграция с сайтами аптек на платформе "1С-Битрикс". Из конфигурации на сайт выгружается номенклатура, фото, цены, остатки и статусы обработанных заказов, с сайта в конфигурацию загружается информация о заказе, оплате заказа и о покупателе."

(67)+ И да.
В Розница Аптека есть и Банк и Взаиморасчета с контрагентами и оптовые продажи.
Уже нормальная работа с МДЛП и чаще обновляется чем УАС, который ждет сначала ERP, затем УТ11 и только затем выходит УАС.

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

В Розница Аптека нет всех этих фишек по менеджерам/продажам и wms

(69) интересное описание. завтра узнаю на тему замены УАС на Розница Аптеку

Угу
Очень не советую связываться с УТ11-УАС для целей только прокладки между своей конфой и 1С-Битрикс
Розница Аптека для этого намного лучше и легче

(71) спасибо. Это я удачно на тебя попал)

"обмены через COM" лучше всего :-)
в том числе с разными версиями платформы
есть несколько способов работать с разными версиями одновременно
самый лёгкий:
1. В консоли администрирования 1С настроить одновременно 2 соединения к одному 1С на разных портах с разными версиями платформы

(73) Я знаю про такую возможность, но, слышал от практиков в этом вопросе, что стабильность и скорость работы весьма посредственные.

(0) План обмена или свой регистр + HTTP сервис, в своё время даже файлы небольшие кидал преобразовав их через Base64

(74) Скорость не пострадает,
стабильность тоже вероятнее не пострадает.
Пострадает нумерация документов т.к. у каждой службы будет свой нумератор.
Если отттуда только читать - ничто не пострадает :-)

(19) >>> КД не рассматриваю вообще. Слишком заморочено, особенно, если в базах-источниках произойдут какие-то серьезные изменения.

уверяю, что КД куда проще чем сырописный обмен.

КД2 вообще близок к идеалу для сопряжения уникальных решений
КД3 хорошее решение для подключения к типовым (которые обновляются)

(74) (73) вместо COM лучше юзать ODATA но его настраивать нужно.

по заявлениям 1с ODATA значительно быстрее чем COM

В типовой УТ 11.5 уже есть готовый обмен через КД3.
Обмениваться можно как угодно - через планы обмена, через файл без планов обмена, через web сервис. Это есть в типовой базе.
На стороне нетиповой базы нужно один раз настроить выгрузку в формат ED. При обновлении УТ обмен не придётся заново настраивать, т.к. все изменения правил будут штатно в этой УТ, а формат ED останется тем же.

Делали обмены между сайтом и 1С через ED. Разработчику на стороне сайта объяснили в каком виде выдавать информацию. Плюсы решения - заработало. Минусы - много лет работает, для обслуживания не обращаются.

(77) у нас ща все обмены на кд3

(79) условия задачи читали?
Нужно сопоставлять номенклатуру из разных баз в одну единую карточку.

Типовыми обменом без переделки такое сделать можно?

+(81) Ну а выбор между свой вариант загрузки (тем более, мне нужны тольки ГУИДы и штрихкод) и постоянно доделывать правила обмена после обновлений - выбор очевиден!

(81) Можно, сделать конечно, но это минимальная переделка в расширении конфигурации, которое будет устойчиво к обновлениям.
при обмене объектом номенклатуры программно сопоставляем с нужной. Соответствие попадает в регистр публичные идентификаторы синхронизируемых объектов.
Потом при обмене ссылками на номенклатуру из РС берётся соответствие.
Это типовые механизмы.
Зачем изобретать свой велосипед? Не найдя решения в 0,5% функционала пытаться полностью реализовать остальной функционал - транспорт обмена, регистрацию изменений и т.п. и потом поддерживать это.
(82) Постоянно переделывать правила в КД3 после обновлений не нужно. Этому заблуждению порядка 10 лет.

Если что, не настаиваю. Делать нужно то, что потом самому будет проще обслуживать. Но не знать других возможностей, заблуждаться и строить свой велосипед, это как-то неправильно.

(83) так для этого и создал тему) чтобы узнать варианты
Ваш вариант изучу, но, боюсь, что долго разбираться с КД3 придется и созданием этого варианта, т.к. не знаком с этим