Відео

1с обмін між різними серверами налаштування. Організація обміну з базою філії (роздрібного магазину) у торговій мережі через XML (універсальний обмін)

Плани обміну в 1С 8.3 - об'єкт метаданих конфігурації, що служить для реалізації синхронізації даних у системі 1С 8.

План обміну можна порівняти з довідником, де елементи це вузли інформаційних баз. Однак у роботі з планами обміну є безліч нюансів, про які ми поговоримо нижче.

Зазвичай обмін у 1С побудований з допомогою спеціальних правил обміну, які формуються з допомогою конфігурації .

Як раніше було відмічено, план обміну дуже схожий на стандартний , і тому ми розглянемо лише основні відмінності обміну.

Як працювати з планом обміну

План обміну вміє зберігати інформацію та зміни елементів зі складу плану обміну, а також зберігає інформацію про номер поточного повідомлення. У випадку схема роботи така:

Змінюємо дані (довідники, документи тощо) у базі — план обміну запам'ятовує зміни. Або автореєстрацією, або програмним кодом(наприклад, метод Плани Обмін. Зареєструвати Зміни).
Коли настає час, отримуємо список змінених елементів — метод Прочитати Зміни(), вивантажуємо ці дані.
При розвантаженні/завантаженні для виключення колізій звіряємо номери повідомлень у плану обміну. Якщо вони не збігаються, скасовуємо обмін даними, якщо збігаються, знімаємо реєстрацію змін та збільшуємо номер повідомлення.

Отримайте 267 відеоуроків з 1С безкоштовно:

Розподілена інформаційна база

Якщо цей прапор встановлений у налаштуваннях, цей план обміну є розподіленою інформаційною базою (РІБ).

- територіально розподілена системана основі однакової конфігурації 1С 8.3. РИБ крім змін даних вміє передавати змін конфігурації, що дуже зручно, наприклад, при оновленні релізу конфігурації.

Склад плану обміну

Налаштування, за допомогою якого розробник керує набором об'єктів для обміну:

У складі плану обміну може бути 3 стани об'єкта:

Не включено до плану обмінувідповідно, жодним чином для такого об'єкта Ви не зможете налаштувати обмін даними за цим планом обміну.
Автореєстрація Заборонити— це означає, що реєструвати зміни для даного вузла необхідно лише програмним кодом за якоюсь умовою, як правило. Використовується метод Плани Обміну. Зареєструвати Зміни ().
Автореєстрація Дозволити— якщо встановлена галка, то будь-які зміни елемента автоматично потраплять до списку змін плану обміну.

Плани обміну та продуктивність 1С

Через системні особливості реалізації планів обміну не рекомендується зловживати вивантаженням змін щодо планів обміну. Справа в тому, що під час читання змін блокуються всі таблиці змін. Тобто. під час розвантаження план обміну не дає записати нові зміни, а отже, блокує і самі елементи — довідники, документи тощо.

Виникла необхідність налаштувати обмін між базами 1С центральної компанії та торгових філій. РИБ не підійшов через чутливість до змін конфігурації, особливо до динамічних оновлень. А також через те, що потрібен обмін за певними правилами: вся інформація має йти в один бік – із центру до філії. Тобто. якщо хтось змінить у базі філії довідник номенклатури випадково, це має попадати у центральну базу.

З центральної базиу філію вивантажуються:

каталог товарів,
ціни лише за деякими видами цін,
замовлення із інтернет-магазину.

У центральній базі та у філії торгівля ведеться від різних юр. осіб, керування філією здійснюється незалежно.
Клієнтська база в центрі та у філії ведеться незалежно, загальними є лише ті клієнти, які пройшли через інтернет-магазин. Тобто. клієнти центральної бази не повинні потрапляти до філії, а також клієнти філії не повинні потрапляти до центральної бази. Але частина клієнтів, які проходять через інтернет-магазин, має проходити через центральну базу. Проблема виникає, якщо клієнт зареєструвався у базі філії, а потім вирішив щось замовити через інтернет-магазин. У цьому випадку при вивантаженні з центру у філію він не повинен задублюватися, а має підчепитися існуючий клієнт.

На основі цих вимог було вирішено спробувати обмін через формат EnterpriseData.

Коротка довідка щодо обміну у форматі EnterpriseData

Модуль менеджера обміну - це модуль конфігурації 1С, який реалізує правила конвертації для обміну. Розташовуватиметься у зовнішній обробці, яку ми підключатимемо до вузла плану обміну.

ПКС - правила конвертації властивостей

Створення плану обміну

Для зручності створимо підсистему "ECom_ОбмінСФіліями". Всі нові об'єкти будемо додавати до цієї підсистеми. Зміни в типові модулі виноситимемо в розширення (при підключенні розширення треба буде зняти галочки " безпечний режим", тому що будуть торкатися серверні модулі).

Копіюємо план обміну "СинхронізаціяДанихЧерезУніверсальнийФормат", називаємо новий планобміну "ECom_ОбмінСФіліями".

У налаштуваннях складу плану обміну робимо Дії - Вимкнути все, а потім додаємо довідники:

Види цін
Номенклатура

та документи:

ЗамовленняКлієнта
УстановкаЦенНоменклатури

Заходимо у модуль менеджера. У процедурі ОтриматиВерсіїФорматуОбміну необхідно змінити назву плану обміну в запиті.

Також зручно додати можливість налагодження модуля менеджера обміну (зовнішньої обробки), як це зробити, описано тут:

Процедура Визначити Установки визначає, як план обміну обміну відображатиметься в меню налаштування синхронізації.

Процедура ВизначитиНалаштування

Процедура ВизначитиНалаштування(Налаштування, ІдентифікаторНалаштування = "") Експорт Настройки.ПредупреждатьОнвідповідностіВерсійПравилОбміну = Істина; Налаштування.ШляхКФайлуКомплектуПравілНа КористувальницькомуСайті = "https://users.v8.1c.ru/distribution/project/Trade110"; Налаштування.ШляхКФайлуКомплектуПравілВКаталогуШаблонів = "\1c\trade"; Налаштування.Вставити("ЗаголовокКомандиДляСтворенняНовогоОбмінуДаними", НСтр("ru = "Обмін з філією"")); Налаштування.Вставити("ЗаголовокПомічникаСтворенняОбміну", НСТ("ru = "Обмін з філією"")); Налаштування.Вставити("ЗаголовокВузлаПланаОбміну", НСТ("ru = "Обмін з філіями"")); Налаштування.Вставити("ЦеПланОбмінXDTO", Істина); КінецьПроцедури

А також необхідно у загальному модулі ОбмінДанимиУТУП у процедурі СписокПланівОбміну додати наш план обміну

ПланиОбмінПідсистеми.Додати(Метадані.ПланиОбміну.ECom_ОбмінСФіліями);

В результаті з'явиться можливість настроювати обмін за нашим планом обміну:

Щоб запускати обмін типовими засобами, необхідно ще в загальних командах.

НалаштуватиПараметриТранспортуПовідомленьОбміну
Синхронізувати
Склад НадісланихДаних

В якості "Тип параметра" відзначити наш план обміну

Копіюємо типові підписки на події:

СинхронізаціяДанихЧерезУніверсальнийФорматРеєстрація
СинхронізаціяДанихЧерезУніверсальнийФорматРеєстраціяДокумента

Вказуємо наші об'єкти, що входять до нашого плану обміну.

Копіюємо типовий модуль ОбмінДаннимиПодіїУТ, в отриманому модулі в процедурах змінюємо ім'я плану обміну з СинхронізаціяДанихЧерезУніверсальнийФормат на наш ECom_ОбмінСФіліями.

У створених підписках вказуємо обробники – процедури з нашого нового модуля.

Також додамо в цей модуль функцію ЦеЦентральнаБаза(), яка нам знадобиться надалі. Ознакою центральної бази будемо вважати код вузла, що відповідає поточній базі ("цей вузол"), що дорівнює "ЦБ".

Функція ЦеЦентральнаБаза() Експорт

Функція ЦеЦентральнаБаза() Експорт Запит = Новий Запит; Запрос.Текст = "ВИБРАТИ | ВИБІР | КОЛИ ECom_ОбменСФилиалами.Код = ""ЦБ"" | ТОДИ ІСТИНА | Інакше брехня | Вибірка = Запит.Виконати().Вибрати(); Якщо Вибірка.Наступний() Тоді Повернення Вибірка.Це ЦентральнаБаза; Інакше Повернення Брехня; КінецьЯкщо; КінецьФункції // ЦеЦентральнаБаза()

Т.к. ця функція буде викликатись постійно, необхідно її закешувати за допомогою модуля повторного використання.

Створення правил реєстрації

Для створення правил реєстрації нам потрібна конфігурація конвертації даних v2.

Я для вивчення питання використав ось цю статтю:

За допомогою обробки MD83Exp.epf, що входить до складу постачання Конвертації 2, необхідно вивантажити структуру конфігурації в файл.

Потім необхідно завантажити отриману структуру конфігурації Конвертацію 2.

Створюємо правила реєстрації.

Вибираємо нашу конфігурацію та наш план обміну.

І заходимо у налаштування правил реєстрації.

Створюємо правила реєстрації для наших об'єктів:

Т.к. ми хочемо, щоб у нас був односторонній обмін (тільки з центру до філій), в налаштування правил по кожному об'єкту треба додати до обробника "Перед обробкою" наш фільтр:

Відмова = Не ECom_ОбмінДанимиПовтІсп.ЦентральнаБаза();

На "Замовлення клієнта" накладаємо додатковий фільтр по організації та за датою початку вивантаження:

Для документа "Встановлення цін номенклатури" також додаємо відбір за датою. Плюс до цього в обробник "Під час обробки" додаємо фільтр за видом цін.

ВикористовуватиКеш = Брехня; ВидиЦен = Об'єкт.ВидиЦен.ВивантажитиКолонку("ВідЦіни"); ПараметрыЗапроса.Вставить("ВидиЦен", ВидиЦен); ТекстЗапроса = "ВЫБРАТЬ | ECom_ОбменСФилиалами.Ссылка КАК Ссылка |ИЗ | ПланОбмена.ECom_ОбменСФилиалами.ВидыЦенНоменклатуры КАК ECom_ОбменСФилиаламиВидыЦенНоменклатуры | ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПланОбмена.ECom_ОбменСФилиалами КАК ECom_ОбменСФилиалами | ПО ECom_ОбменСФилиаламиВидыЦенНоменклатуры.Ссылка = ECom_ОбменСФилиалами.Ссылка | И (ECom_ОбменСФилиаламиВидыЦенНоменклатуры.ВидЦенНоменклатуры В (&СвойствоОбъекта_ВидыЦен)) | И (ECom_ОбменСФилиалами.ЭтотУзел = брехня)" ;

Цей обробник за допомогою запиту дозволяє визначити список вузлів, в яких буде здійснено реєстрацію об'єкта. Чомусь хоча наш параметр запиту називається "ВідіЦен", у запиті ми повинні писати "Властивість Об'єкта_ВідіЦен".

На довідник "Види цін" також накладаємо фільтр:

Зберігаємо правила реєстрації у зовнішній файл:

Отриманий XML-файл необхідно завантажити на макет "Правила реєстрації" нашого плану обміну:

Зазначимо, що при роботі зміни правила реєстрації беруться зовсім не з цього макета, а з правил, що зберігаються в регістрі відомостей "Правила для обміну даними". А цей регістр правила завантажуються саме з макета, зашитого в конфігурацію - при створенні налаштування синхронізації. Це призводить до того, якщо у нас вже створено налаштування синхронізації, а нам з якихось причин потрібно змінити правила реєстрації - після зміни правил у макеті конфігурації потрібно оновити їх також у цьому регістрі:

Правила конвертації

Для створення правил конвертації нам потрібна конфігурація конвертації даних v3. Найкраще користуватися чистою базою. Наприклад, розробляючи конвертацію для формату даних EnterpriseData 1.3, для деяких об'єктів чомусь потрібно задавати реквізити (ПКС), що не здавалося б обов'язковими. Виявилося, що вони є обов'язковими у версії 1.2, і просте наявність у базі Конвертації завантаженого опису цього формату вже збивало логіку роботи програми. Тому беремо чисту базу і вантажимо в неї все "з нуля".

Дуже добре робота з конвертацією 3.0 описана тут:

Завантажуємо структуру конфігурації з файлу, вивантаженого раніше (конвертації 2).

Вивантажуємо з УТ 11 XDTO-пакет EnterpriseData_1_3_8 у файл

Завантажуємо отриманий файл до Конвертації 3

Створюємо конвертацію

Версія формату менеджера обміну вказується залежно від конфігурації. Наприклад, для УТ 11.3 це "1", для УТ 11.4 - "2".

Що таке конвертація? Для вивантаження та завантаження об'єкта нам потрібно:

Правило надсилання даних - тут ми можемо накладати фільтр на об'єкти та застосовувати різні правила конвертації (наприклад, для папок номенклатури та елементів вказуються різні правила конвертації через різний набір реквізитів)
Правило конвертації "з 1С в XML" - тут дані 1С перетворюються на дані формату EnterpriseData (наприклад, можна документ "Реалізація" конвертувати в документ "Надходження")
Правило конвертації "з XML в 1С"
Правило отримання даних

Якщо об'єкт бере участь у плані обміну – для нього обов'язково необхідно створити правило надсилання даних. У нашому випадку це:

Види цін
Номенклатура
Замовлення клієнта
Встановлення цін номенклатури

Як поводитимуться реквізити цих об'єктів посилання типу? Наприклад, реквізит "Організація". У кожного "об'єктних" типів у форматі EnterpriseData (наприклад, Довідник.Контрагенти) є звані ключові властивості. Так ось, коли ми вивантажуємо замовлення, у правилах конвертації вказуємо реквізит "Організація". При розвантаженні цього реквізиту вивантажуються та її ключові характеристики. Ми не створюватимемо створювати правила відправки для довідника "Організації", тому що ці дані в працюючій системі змінюються вкрай рідко, ми просто пропишемо алгоритм, який при отриманні замовлення правильно підставить вже існуючу в базі філії організацію.

Отже, правила відправки ми пишемо для об'єктів, що часто змінюються, "статичні" ж об'єкти ми краще одноразово (і повторно при необхідності) вивантажимо через універсальне вивантаження-завантаження.

Створюємо правило конвертації для надсилання номенклатури.

Налаштовуємо "правила конвертації властивостей". Суть у чому. EnterpriseData - це структура даних, насправді та сама конфігурація 1С. Тільки скажемо так трохи спрощеніша й універсальна. Вона повинна підходити для різних конфігурацій 1С, тому склад та назва об'єктів відрізняється від УТ 11. Тому нам потрібно прописати відповідність – як реквізити називаються в УТ11, і як у EnterpriseData. Є так звані ключові властивості - це обов'язкові реквізити для даної версії формату. Їх можна подивитися у "Дереві об'єктів формату":

Отже, вказуємо правила конвертації властивостей для номенклатури:

Як бачимо, у нас з'явилося кілька реквізитів "складного" типу, для них також необхідно створити "Правила конвертації об'єктів", інакше при вивантаженні буде виходити таке повідомлення в помилках: "Структура об'єкта "/Одиниця Вимірювання" не відповідає типу".

Правила конвертації для перерахувань та інших визначених (у конфігураторі) даних створюються на вкладці:

Для цих (і деяких інших) даних зручно, щоб правило працювало одразу і відправлення, і отримання.

Вказуємо створені правила у ПКС для номенклатури:

Тепер створимо правило конвертації "Замовлення клієнта".

Додамо правила конвертації для табличної частини "Товари". Для початку вкажемо відповідність реквізитів ПКС. Необхідно проставити галочку "Використовується алгоритм", т.к. Значення табличної частини формуватимуться не "самі", потрібно ще написати невеликий алгоритм. З використанням алгоритму не обов'язково вказувати реквізити об'єкта з 1С, т.к. значення для вивантаження в файл XMLвсе одно формуватимуться алгоритмом. Необхідно також вказувати правило конвертації якості для "складних" типів.

Тепер потрібно додати алгоритм заповнення табличної частини в обробник "Під час відправки".

#Область Товари // Табличні частини Запит = Новий Запит; Запит.Текст = "ВИБРАТИ | Товари.НомерРядки ЯК НомерРядкиДокумента, | Товари.Номенклатура ЯК Номенклатура, | ВИБІР | НоменклатураДовідник.ЕдиницяВимірювання, ЗНАЧЕННЯ(Довідник.УпаковкиЕдиниціВимірення.ПустаПосилання)) ЯК ОдиницяВимірювання, | |Товари.СтавкаНДС, |Товары.СумаНДС |З |Документ.ЗамовленняКлієнта.Товари ЯК Товари |Ліве З'єднання Довідник.Номенклатура ЯК НоменклатураДовідник |ПО Товари.Номенклатура =НоменклатураДовідникСусилля | БРЕХНЯ" ; Запит.ВстановитиПараметр("Посилання", ДаніІБ.Посилання); ДаніXDTO.Вставити("Товари", Запит.Виконати().Вивантажити()); #КінецьОбласті

У правилах конвертації при отриманні замовлення слід прописати алгоритм, який виконує зворотну операцію

Алгоритм заповнює ОтриманіДані.ДодатковіВластивості.Товари, які потім автоматично записуються в табличну частину "Товари" об'єкта, що завантажується.

МасивСтрокТовари = Новий Масив; ПравилаЗаповнення = Новий Відповідність; ПравилаЗаполнения.Вставить("Номенклатура", "Номенклатура"); Правила Заповнення. Вставити ("Кількість", "Кількість"); Правила Заповнення. Вставити ("Сума", "Сума"); Правила Заповнення. Вставити ( "Ціна", "Ціна"); Правила Заповнення. Вставити ("Ставка ПДВ", "Ставка ПДВ"); Правила Заповнення. Вставити ("Сума ПДВ", "Сума ПДВ"); Правила Заповнення. Вставити ("Склад", "Склад"); Якщо даніXDTO.Властивість("Товари") І ЗначенняЗаповнено(ДаніXDTO.Товари) Тоді Для Кожного Рядка З ДаніXDTO.Товари Цикл СтруктураДанихРядки = Новий Структура; Для кожного ПравилоЗаповнення З ПравилаЗаповнення Цикл СтруктураДляПереносаЗначення = Новий Структура(ПравилоЗаповнення.Ключ, Невизначено); ЗаповнитиЗначенняВластивостей(СтруктураДляПереносуЗначення, Рядок); Значення = СтруктураДляПереносаЗначення[ПравилоЗаповнення.Ключ]; Якщо значення<>Невизначено Тоді СтруктураДанихРядки.Вставити(ПравилоЗаповнення.Значення, Значення); КінецьЯкщо; КінецьЦикл; СтруктураДанихРядки.Вставити("КількістьУпаковок", СтруктураДанихРядки.Кількість); Якщо даніXDTO.Властивість("Склад") Тоді СтруктураДанихРядки.Вставити("Склад", ДаніXDTO.Склад); КінецьЯкщо; МасивСтрокТовари.Додати(СтруктураДанихРядки); КінецьЦикл; КінецьЯкщо; Якщо МасивСтрокТовари.Кількість() > 0 Тоді ОтриманіДані.ДодатковіВластивості.Вставити("Товари", МасивСтрокТовари); КінецьЯкщо;

Тепер реалізуємо такий механізм обміну контрагентами (покупцями): при завантаженні замовлення до бази філії шукаємо існуючого клієнтапо телефону (наприклад, клієнт щось купив у філії, зареєструвався, а потім вирішив придбати щось в інтернет-магазині, і замовлення потрапило до центральної бази). Якщо клієнт по телефону знайдений, то підставляємо його замовлення, якщо ж ні - створюємо нового. Для цього нам необхідно буде разом із замовленням передавати номер телефону клієнта. У типові поля замовлення у форматі EnterpriseData телефон не входить, щоб передати його, можна скористатися полем AdditionalInfo, куди можна записувати додаткову інформацію. Ми передаватимемо додаткову інформацію у вигляді структури з необхідними полями. Через AdditionalInfo можна передавати і структури, і таблиці значень. В обробник "При відправленні" в правила конвертації замовлення під час відправлення

додаємо код:

Текст обробника "Під час відправлення"

СтруктДопДані = Новий Структура; Запит = Новий Запит; Запит.Текст = "ВИБРАТИ | ПартнериКонтактнаІнформація.НомерТелефону |З | Довідник.Партнери.КонтактнаІнформація ЯК ПартнериКонтактнаІнформація |ДЕ | Запит.ВстановитиПараметр("Партнер", ДаніІБ.Партнер); Вибірка = Запит.Виконати().Вибрати(); Якщо Вибірка.Наступний() Тоді структДопДані.Вставити("НомерТелефону", Вибірка.НомерТелефону); КінецьЯкщо; ДаніXDTO.Вставити("Additionalinfo", структДопДані);

Відповідно, в обробник "При конвертації даних XDTO" в налаштування конвертації при отриманні

Додаємо код:

Текст обробника "При конвертації даних XDTO"

Якщо даніXDTO.Властивість("AdditionalInfo") Тоді Якщо даніXDTO.AdditionalInfo.Властивість("НомерТелефона") Тоді НомерТелефона = ДаніXDTO.AdditionalInfo.НомерТелефона; Запит = Новий Запит; Запит.Текст = "ВИБРАТИ | ПартнериКонтактнаІнформація.Посилання ЯК Партнер, | Контрагенти.Посилання ЯК Контрагент |З | Довідник.Партнери.КонтактнаІнформація ЯК ПартнериКонтактнаІнформація | .Вигляд = ЗНАЧЕННЯ(Довідник.ВидиКонтактноїІнформації.ТелефонПартнера)) |І (ПартнериКонтактнаІнформація.НомерТелефону = &НомерТелефона)" ; Запит.ВстановитиПараметр("НомерТелефона", НомерТелефона); Вибірка = Запит.Виконати().Вибрати(); Якщо Вибірка.Наступний() Тоді ОтриманіДані.Партнер = Вибірка.Партнер; ОтриманіДані.Контрагент = Вибірка.Контрагент; Інакше ПартнерОб'єкт = Довідники.Партнери.СтворитиЕлемент(); ПартнерОбъект.Наименование = ДаніXDTO.Контрагент.Найменування; ПартнерОбъект.НаименованиеПовне = ПартнерОбъект.Наименование; ПартнерОб'єкт.Клієнт = Істина; ПартнерОб'єкт.ЮрФізОбличчя = Перерахування.КомпаніяПриватнеОбличчя.ПриватнеОбличчя; НоваРядок = ПартнерОб'єкт.КонтактнаІнформація.Додати(); НоваРядок.Тип = Перерахування.ТипиКонтактноїІнформації.Телефон; НоваРядок.Вигляд = Довідники.ВидиКонтактноїІнформації.ТелефонПартнера; Новий Рядок.НомерТелефона = НомерТелефона; НоваРядок.Представлення = НомерТелефона; НоваРядок.ЗначенняПолів = УправлінняКонтактноюІнформацієюСлужбовийВикликСервера.КонтактнаІнформаціяXMLПо Представленню(НоваРядок.Представлення, Перерахування.ТипиКонтактноїІнформації.Телефон); ПартнерОбъект.ОбменДанными.Загрузка = Істина; ПартнерОбъект.Записать(); КонтрагентОб'єкт = Довідники.Контрагенти.СтворитиЕлемент(); КонтрагентОбъект.Наименование = ПартнерОбъект.Наименование; КонтрагентОбъект.НаименованиеПовне = КонтрагентОбъект.Наименование; КонтрагентОбъект.ЮрФизЛицо = Перерахування.ЮрФізЛіцо.ФізЛіцо; КонтрагентОб'єкт.Партнер = ПартнерОб'єкт.Посилання; КонтрагентОб'єкт.ОбмінДаними.Завантаження = Істина; КонтрагентОб'єкт. Записати (); ОтриманіДані.Партнер = ПартнерОб'єкт.Посилання; ОтриманіДані.Контрагент = КонтрагентОб'єкт.Посилання; КінецьЯкщо; КінецьЯкщо; КінецьЯкщо;

У розвантаженні цін номенклатури є кілька цікавих моментів:

документ установки цін може містити кілька видів цін, а нам потрібно вивантажувати лише ті, що підпадають під фільтр.
У EnterpriseData документ "Встановлення цін номенклатури" має тільки один тип цін. Тобто. один документ у 1С має вивантажуватися як кілька об'єктів EnterpriseData.

Для реалізації фільтра нам потрібно десь зберігати види цін, що вивантажуються, встановлені в налаштуваннях вузла обміну. Для цього нам потрібні "Параметри конвертації":

А також обробка події "Перед конвертацією":

У правилах обробки даних для документа "Встановлення цін номенклатури" нам необхідно відключити використання конвертації "у типовому" варіанті, а натомість генерувати об'єкт XDTO "на ходу":

Для цього ми звернемося безпосередньо до методу ОбмінДанимиXDTOСервер.ВивантаженняОб'єктаВибірки. Перетворимо документ на масив необхідних нам структур з одним типом цін, і вже кожну цю структуру окремо вивантажимо через правила конвертації. Виглядає, звісно, заплутано.

Текст обробника "Під час обробки"

Якщо ТипЗнч(ДаніІБ) = Тип("Структура") Тоді Повернення; КінецьЯкщо; Запит = Новий Запит; Запит.Текст = "ВИБРАТИ | ЦіниНоменклатури.ВидиЦіни ЯК ТипЦен, | ЦіниНоменклатури.Номенклатура ЯК Номенклатура, | ЦіниНоменклатури.Ціна ЯК Ціна |З | Документ.<>0 | І ЦіниНоменклатури.ВидЦены В(&ВидыЦенНоменклатури) |ПІДСУМКИ ПО | ТипЦен "; .Колонки.Додати("Ціна"); ВибіркаВидЦіни = Запит.Виконати().Вибрати(ОбхідРезультатуЗапиту.Погрупуванням); .Наступний() Цикл Якщо НЕ ЗначенняЗаповнено(ВибіркаВидиЦіни.ТипЦен) Тоді Продовжити;КінецьЯкщо; (); Деталі); КінецьЦикл; ДаніІБСтруктура.Вставити("ТипЦен", ВибіркаВідЦени.ТіпЦен); ДаніІБСтруктура.Вставити("Товари", ТаблицяТоварів); ОбмінДанимиXDTOСервер.ВивантаженняОб'єктаВибірки(КомпонентиОбміну, ДаніІБСтруктура, ПравилоУстановкаЦенВідправка); КінецьЦикл; КінецьЯкщо; Використання ПКО.Документ_УстановкаЦенНоменклатури = Брехня;

В правило конвертації в ПКС необхідно додати властивість ТипЦен. При цьому треба вибирати спосіб вибору властивостей "Вручну".

Налаштування синхронізації

Необхідно задати значення константи "Префікс інформаційної бази" - "ЦП":

Створюємо нове налаштуваннясинхронізації

Задамо в налаштуваннях фільтр за датою документів, організації, видом цін:

Щоб підключити нашу зовнішню обробку, що містить модуль менеджера обміну, необхідно в налаштуваннях форми вказати відображення вкладки "службова інформація":

Створимо другу чисту базу (для філії) із cf-ника центральної бази. Також не забуваймо підключити наше розширення. Під час створення бази автоматично створюються довідники "Валюта" та "Одиниці вимірювання". Щоб при завантаженні даних із центральної бази не відбулося завоювання цих даних, необхідно в конвертації за цими довідниками зробити ідентифікацію не за UID, а за кодом.

Префікс інформаційної бази задаємо "ФО" і налаштовуємо синхронізацію, аналогічно центральній базі.

Додаткові файли із наскрізним прикладом.

Склад файлів, доданих до цієї статті:

cf-файл "Додаткові об'єкти конфігурації.cf" для об'єднання з основною конфігурацією УТ 11, що містить розроблений план обміну
cfe-файл із розширенням конфігурації, для коригування модулів конфігурації
xml-файл "Правила реєстрації.xml"
epf-файл "МенеджерДемо.epf"

Порядок встановлення плану обміну. У конфігураторі запускаємо операцію порівняння та об'єднання з "Додаткові об'єкти конфігурації.cf". Знімаємо галочки з усіх об'єктів:

Вибираємо "Дії - відзначити за підсистемами файлу", відзначаємо тільки "ECom_ОбмінСФіліями"

Додаємо розширення з файлу "ECom_ОбмінДанимиСфіліями.cfe", знімаємо галочки про безпеку:

Для коригування правил реєстрації вкладений файл "Правила реєстрації.xml" можна завантажити в конвертацію 2. Попередньо необхідно завантажити структуру конфігурації, як описано .

Для коригування правил конвертації вкладений файл "МенеджерДемо.epf" можна завантажити в Конвертацію 3. Попередньо необхідно створити опис конвертації, як описано .

В реального життяРідкісна компанія обходиться однією базою 1С. Найчастіша ситуація – це дві бази, бухгалтерія та зарплата.

Бази мають бути пов'язані – нарахували зарплату, до бухгалтерії мають піти нараховані податки до сплати.

Для зв'язку кількох баз існує Обмін 1С. Як він працює?

Що таке Обмін 1С?

Є мережа магазинів та центральний офіс. У кожному магазині та в офісі є склад. Товари переміщуються зі складу склад (переважно з центрального склади магазинів), й у магазинах — продаються.

Використовується база 1С Роздріб в офісі та ця ж база у кожному магазині. Бази у магазинах – підпорядковані базі в офісі.

У офісі створюють документи про переміщення товарів зі складу складу, призначаються ціни. Документи заливаються до підлеглих баз і там «з'являються» товари.

У магазинах створюються документи про скоєні продажі товарів. Документи заливаються в офісну базу і там з'являються продажі.

Така схема називається – розподілена інформаційна база(Ріб). Процедури заливки документів - двосторонній обмін 1С. А налаштування цієї схеми – УРІБ чи УРІБД (управління розподіленими інформаційними базами даних).

Принципи Обмін довідниками в 1С

Довідники 1С (а набір усіх довідників «в комплексі» називають НСІ – нормативно Довідкова інформація) – у різних базах зазвичай мають бути єдині. Це означає, що навіть баз кілька, то список товарів, складів, контрагентів – єдиний у різних базах.

Нормальна практика, як у одній основі довідник можна редагувати, а інші він копіюється («мігрує»). Як ми раніше вже обговорювали – кожен елемент 1С має унікальний ідентифікатор – GUID . Довідники зазвичай копіюються разом зі своїм GUID і таким чином ідентичні у всій розподіленій інформаційній системі.

В іншому випадку, коли з'єднуються кілька існуючих баз, або коли довідники можна створювати в різних базах одночасно, їх GUID будуть різними. І тому існує механізм зіставлення. В спеціальний регістрвідомостей при обміні 1С записується інформація, що з бази №1 з GUID ххх дорівнює елементу у цій базі з GUID yyy. Спочатку наявні елементи, які вже не рівні, потрібно порівняти автоматично (за іншими реквізитами, наприклад, за назвою або за ІПН та КПП) або вручну.

Принципи Обміну документами в 1С

Документи в 1С проводяться по регістрам і після цього вважаються проведеними. Це породжує зрозумілі складнощі під час перенесення.

Один варіант – перенести лише документи та провести їх заново після завантаження. Цей метод часто використовується, але може народжувати помилки - документ може і не провести в новій базі, так як умови при проведенні можуть скластися інакше, ніж були в момент проведення цього документа в початковій базі.

Інший варіант – перенесення документів та регістрів разом. Як ми розуміємо, відразу ж постає питання - чи ми переносимо всі документи взагалі і тоді весь регістр взагалі або змушені вибирати для перенесення тільки руху по документах, що переносяться.

Допустимо, нам потрібно перенести елемент довідника Номенклатури. Цей довідник має 10 полів, з яких 5 є рядками та числами, а 5 – посиланнями на інші довідники.

Відповідно при перенесенні одного елемента Номенклатури ми змушені шукати та переносити також 5 елементів інших довідників.

Таким чином, при перенесенні одного елемента довідника або одного документа, за посиланням може бути перенесено 100 і більше інших об'єктів 1С.

Фактично кажуть, що майже всі довідники конфігурації так чи інакше посилаються один на одного.

Плани обміну 1С

Припустимо, що ми створили розподілену базуданих та провели обмін 1С. На центральний склад закуплено товар та підготовлено для відправки до магазинів. У 1С в офісі ввели потрібні документипереміщення товарів. Потрібно, щоб вони завантажилися до магазинів.

Що робити? Провести знову повний обмін 1С? Довго та неефективно! Набагато краще було б обчислити, що саме було додано або змінено користувачами в офіс, щоб у магазини потрапили тільки зміни.

І тому існує – плани обміну 1С. Програміст заздалегідь створює план обміну 1С щодо обмінів 1С з будь-якої іншої базою даних, наприклад з нашими магазинами.

План обміну 1С зазначає під час роботи користувачів з довідниками та документами, що було додано або змінено з моменту проведення останнього обміну 1С із цією базою.

Створення УРІБ 1С

Отже, ми створимо розподілену основу з нуля. Спочатку ми маємо «батьківську» базу офісу. З неї ми виділятимемо бази магазинів, які будуть їй підпорядковані.

У типових конфігураціях вже є типові плани обміну 1С. Види баз, котрим вони призначені – інтуїтивно зрозумілі з назви:

Обмін 1С із сайтом: обмін із сайтом 1С:Бітрікс
Обмін 1С УПП-УТ або УТ-Роздріб: типові обміни з конфігураціями-побратимами
Повний - обмін 1С з базою даних на основі такої конфігурації.

РИБ – розподілена інформаційна база – можна створити зокрема з урахуванням плану обміну 1С «Повний». У конфігураторі у плані обміну 1С має стояти галочка «Розподілена інформаційна база».

План обміну 1С, створений конфігураторі, свідчить, що ми збираємося обмінюватися з такою конфігурацією. У режимі Підприємство в цьому ж плані обміну 1С тепер потрібно вказати конкретні бази даних на базі цієї конфігурації.

Зайдемо до плану обміну 1С (Операції/План обміну; також можуть бути в іншому меню, часто в меню Сервіс/ХХХ).

У списку баз даних у плані обміну 1С є одна із зеленим кружечком на картинці. Цей елемент позначає цю базу. Інші елементи позначають ІНШІ основи, з якими йде обмін 1С.

Необхідно, щоб було заповнено найменування і код у всіх елементів.

Щоб створити підлеглу базу магазину:

Встановіть куховар у списку на елемент плану обміну 1С, який ми створили як «базу магазину»
Виберіть пункт меню "Дії/Створити початковий образ".

В результаті буде створено одну базу з вивантаженими в неї початковими даними. Це потрібно повторити для кожного елемента плану обміну 1С, крім поточної бази.

Теорія проведення обмінів 1С

Теорія обміну 1С досить проста:

Одна з баз (частіше база центру) ініціює обмін 1С за розкладом або за подією (вхід до бази певного користувача і т.п.)
Обмін 1С полягає у вивантаженні з бази файлу
Файл повинен бути переміщений у те місце, звідки його зможе забрати підпорядкована база (частіше кулі або ftp, рідше електронна пошта)
Підпорядкована база завантажує отриманий файл
Як підтвердження, що інформація отримана, підпорядкована база вивантажує "відповідний" файл, який таким же чином завантажується назад в центральну базу
Сеанс обміну 1С завершено.

Існують інші методи обміну 1С, не через файли, а, наприклад, через пряме COM-з'єднання між двома базами. Його плюси:

Не потрібне «місце для зберігання та передачі файлів»
Не потрібно повторного завантаження підтвердження
Все відбувається швидше за рахунок перших двох пунктів.

Однак обмеження зрозуміло - бази повинні бути в такій доступності один до одного, щоб ініціювати COM з'єднання.

Налаштування РИБ 1С

У константах типових конфігурацій (Операції/Константи; або Сервіс/Налаштування програми) — зазвичай є загальне налаштуванняобмінів 1С. Це – префікс у кодах елементів та номерах документів, щоб легко визначати, в якій базі він створений. А також внутрішній метод збереження інформації про місце створення довідників та документів.

Тепер необхідно налаштувати як відбуватиметься процес періодичного обміну 1С інформацією між створеними базами.
Усі налаштування РИБ в 1С знаходяться у типових конфігураціях зазвичай у меню Сервіс/Розподілені інформаційні бази/Налаштувати вузли РІБ.

Для кожного раніше створеного елемента "віддаленої бази магазину" необхідно додати елемент налаштування.

У налаштуванні вказується спосіб обміну 1С: файл (кулі), файл (FTP), файл (e-mail).

Створення та налаштування розподіленої інформаційної бази 1С у тонкому клієнті

Подивимося аналогічне настроювання в типовій конфігурації на базі тонкого клієнта- Управління торгівлею редакція 11.
Налаштування (та створення з нуля) знаходяться на закладці інтерфейсу Адміністрація. Пункт "Обмін даними".

Виберемо "Створити обмін у розподіленій інформаційній базі".

З самого початку 1С нам запропонує вказати, яким чином ми збираємося обмінитися з підлеглою базою інформацією. Ось варіант налаштування "через файл на кулі".

Ось варіант налаштування через файл на FTP.

Назва нашого налаштування обміну 1С.

І відразу ж пропозиція створити «початковий образ» — тобто саму підлеглу бази даних із вивантаженням у неї первинної інформації.

На відміну від конфігурації на товстому клієнті, обидві налаштування обміну 1С знаходяться в одному місці.

Автоматизовані системиуправління здебільшого складаються з окремих баз даних і найчастіше мають територіально розподілену структуру. При цьому правильно реалізований обмін даними - необхідна умовадля ефективної роботитаких систем.

Початкове налаштування обміну при цьому може вимагати низки дій, не тільки в частині програмування, але й консалтингу, навіть якщо ми маємо справу з однорідними джерелами, як у випадку із продуктами на платформі «1С:Підприємство». Чому налаштування обміну 1С (або, як ще це називається - синхронізація даних у 1С 8.3) може стати найважчим і недешевим завданням проекту інтеграції, розглянемо в цій статті.

Обмін даними в середовищі 1С дозволяє:

Виключити подвійне введення документів;
Автоматизувати суміжні бізнес-процеси;
Оптимізувати взаємодію між розподіленими підрозділами;
Оперативно актуалізувати дані для роботи спеціалістів різних відділів;
«Розмежувати» різні видиобліку.

*У разі, коли дані одного виду обліку суттєво відрізняються від іншого, необхідно забезпечити конфіденційність інформації та «розмежувати» інформаційні потоки. Наприклад, обмін даними між 1С УТ та 1С Бухгалтерія не вимагає вивантаження до бази регламентного обліку управлінських даних, тобто. синхронізація у 1С тут буде неповна.

Якщо представляти стандартний процес реалізації первинного обміну даними, коли хоча б один із його об'єктів – продукт 1С, то можна виділити такі етапи:

Узгодження складу обміну;
визначення транспорту (протоколів обміну);
встановлення правил;
Складання розкладу.

Виявлення складу обміну 1С

Об'єкти обміну можна умовно поділити на «джерело» та «приймач». При цьому вони можуть виконувати дві ролі одночасно, що називатиметься – двостороннім обміном. Визначення джерела та приймача відбувається логічним шляхом залежно від необхідності або від функціональних можливостейсистеми.

*Наприклад, при інтеграції «WA: Фінансист» – рішення для ведення фінансового обліку та управління процесами казначейства, розробленого на базі «1С:Підприємство», експерти WiseAdvice рекомендують саме його як майстер-систему. Це пов'язано з наявністю інструментів контролю для дотримання правил заявної політики, а відповідно, і для забезпечення ефективності роботи рішення.

Далі на основі отриманих та зафіксованих вимог з боку користувачів створюється список даних для обміну, визначається їх обсяг, вимоги до частоти обміну, прописується процес роботи з помилками та опрацювання виняткових ситуацій (колізій).

На цьому ж етапі залежно від парку наявних систем та структури підприємства визначаються з форматом обміну:

Розподілена інформаційна база

РИБ має на увазі обмін між ідентичними конфігураціями баз даних 1С, з чіткою структурою управління «головний-підлеглий» для кожної пари обміну. Будучи елементом технологічної платформи, РИБ крім даних може передавати зміни у конфігурації та адміністративну інформацію БД (але з головного до підлеглого).

Універсальний обмін даними у 1С

Механізм, що дозволяє налаштувати обмін баз 1С, як із змінами на платформі «1С:Підприємство», і з системами сторонньої розробки. Обмін здійснюється за допомогою переведення даних в універсальний формат xml відповідно до «Планами обміну».

EnterpriseData

Нова розробка фірми 1С, призначена для реалізації обміну даними у форматі XML між продуктами, створеними на платформі «1С:Підприємство», з будь-якими системами автоматизації. Застосування EnterpriseData полегшує доопрацювання, пов'язані з обміном. Раніше при включенні в систему нової конфігурації була потрібна реалізація механізму імпорту та експорту даних, як для неї, так і для вже наявних систем. Тепер системи, що підтримують EnterpriseData, не потребують доробок, маючи лише одну точку «входу-виходу».

Визначення транспорту (протоколів обміну)

Для системи на платформі «1С:Підприємство 8» передбачено широкий спектр можливостей для організації обміну з будь-якими інформаційними ресурсамиза допомогою загальноприйнятих універсальних стандартів (xml, текстові файли, Excel, з'єднання ADO і т.д.). Тому щодо транспорту для даних обміну слід відштовхуватися від можливостей бази даних сторонньої системи.

Синхронізація довідників

Основним принципом ефективної синхронізації довідників є наявність однієї точки введення. Але якщо йдеться про роботу з довідниками, що історично заповнювалися за різними правилами, необхідно чітко визначити поля синхронізації для приведення обміну до загального знаменника.

*На цьому етапі може знадобитися проведення робіт з нормалізації НСІ на стороні джерела даних. Залежно від стану довідників та їх обсягу, процес зіставлення елементів, розпізнавання, виявлення помилок і дублів, а також заповнення полів, що відсутні, і призначення полів синхронізації, може вимагати роботи цілої групи експертів, як з боку інтегратора (власника методики нормалізації НСІ), так і з боку замовника.

Встановлення правил

Можливість відображення даних систем-джерел у приймачах залежить від правильно заданих правил обміну. Правила, представлені у форматі XML, регулюють відповідність ключових реквізитів об'єктів джерела-приймача. Рішення «1С:Конвертація даних» призначене для автоматизації створення правил реалізації як одноразового обміну, і постійного.

Гарантує відсутність втрат даних під час обміну План обміну. Це складова частинабудь-якої конфігурації на платформі «1С:Підприємство», що повністю описує порядок обміну 1С: склад даних (документи з «пізнавальними» реквізитами) та вузли (інформаційні бази приймачі-передавачі), а також активацію РІБ для обраних напрямків обміну.

Будь-яка зміна даних, занесених до Плану обміну, фіксується і отримує ознаку «зміненості». Доки змінені дані не будуть відповідати один одному у вузлах приймача-передавача, ознака скинута не буде, і система розсилатиме контрольні повідомлення в обидва вузли. Після вивантаження даних та підтвердження їх повної відповідності в обох системах, ознака скидається.

Розклад обміну в 1С

Для автоматизації регулярного обміну встановлюється періодичність розвантаження даних. Частота обміну залежить від необхідності та технічних можливостей. Також конфігурації на платформі «1С:Підприємство» дозволяють налаштувати обмін даними при настанні якоїсь події.

Розглянувши стандартний процес реалізації обміну, звернемо увагу на фактори, які вимагатимуть доробок на різних етапах:

Чи не типові, сильно допрацьовані зміни БД;
Різні версіїплатформи "1С:Підприємство";
Давно не оновлювалися, актуальні версіїконфігурації;
Об'єкти обміну, що раніше зазнали доопрацювань;
Необхідність у нестандартних правилах обміну;
Набір і склад реквізитів у наявних довідниках.

Оскільки навіть стандартні дії щодо реалізації первинного обміну даними вимагають експертних знань, їх рекомендується проводити за участю спеціалістів 1С. Тільки після виконання всіх вищеописаних дій слід переходити до налаштування обміну конфігурації. Розглянемо інтеграцію баз даних на прикладі «1С:УПП» та «1С:Роздріб» (за цією ж схемою налаштовується обмін із «1С:УТ»). Також до типової синхронізації відноситься обмін УПП – УПП, характерний для масштабних систем автоматизації на найбільших промислових підприємствах.

У підменю «Сервіс» вибираємо «Обмін даними з продуктами на платформі…» (вибір прямого обміну з «Роздрібом» часто загрожує помилками на рівні COM-об'єктів). Звернімо увагу на службове повідомлення « Ця можливістьнедоступна».

Щоб вирішити цю проблему, необхідно вибрати "Налаштування обміну даними"

…і проставити галочку. Далі повідомлення про помилку ігноруємо.

У налаштуваннях синхронізації даних вибираємо «Створити обмін із «Роздріб»…

Перед налаштуванням параметрів підключення через локальний або мережевий каталог слід переконатися, що на диску під каталог є місце. Хоча, як правило, він не займає більше 30-50 Мб, у виняткових випадках під нього може знадобитися до 600 Мб. Створити потрібний каталог можна прямо з конфігуратора.

При підключенні через мережевий каталог пропозиції налаштувати підключення за допомогою FTP-адреси та електронною поштою ігноруємо, натискаючи «Далі».

У налаштуваннях вручну проставляємо префікси - умовні позначення баз (як правило, БП, УПП, РО), задаємо правила та початкову дату розвантаження даних. Префікс буде вказуватися в назві документів для позначення бази, в якій вони були створені. Якщо правила вивантаження не будуть редаговані, дані за промовчанням будуть вивантажуватись за всіма наявними параметрами.

Створюємо файл налаштування обміну для "Роздріб", щоб не повторювати свої дії. При необхідності негайного надсилання даних відразу після налаштування синхронізації – проставляємо галочку.

Для автоматизації процесу обміну необхідно настроїти розклад.

Меню "Роздріб".

Проставляємо галочку та вибираємо «Синхронізацію».

Виробляємо «зворотне» налаштування, вибираючи Управління виробничим підприємством.

Завантажуємо файл з налаштуваннями, створений в УПП.

Проставляємо галочку, адресу система підхоплює автоматично.

Діємо так само, як і в УПП.

Перевірочне зіставлення даних (Ручне зіставлення даних рекомендується зробити на підготовчому етапі, оскільки ці роботи можуть стати найтрудомісткішими у процесі реалізації обміну). Відкриття вікна зіставлення відбувається по подвійному клацанню миші.

У разі помилки у синхронізації «Докладно…» буде замінено на «Ніколи…».

"Докладно..." відкриває журнал реєстрації з уточненою інформацією щодо обміну.

Готово.

Обмін даними між прикладними рішеннями 1С 8 - це те, без чого не можлива побудова повноцінного інформаційного просторупідприємства.

Навіщо потрібні обміни даних та як їх використовувати?
Види обмінів між 1С.
Як зробити налаштування обміну даними між базами 1С?

Відповіді на ці запитання Ви дізнаєтесь нижче.

Причин для впровадження обмінів, як правило, дві:

Організація має мережу філій

В цьому випадку Вам просто необхідно налаштовувати обмін між різними філіями. Для цього в системі 1С 8.3 підприємство існує механізм. За допомогою якого можна гнучко настроїти обмін інформацією. Наприклад, для філій можна відключити видимість документів з інших філій і водночас центральний офіс бачитиме документи всіх філій. Інший приклад - налаштування обміну між базами 1С Роздріб офісу та магазинів.

Поділ за видами обліку

Зазвичай, це, що у організації різний облік ведеться у різних інформаційних базах. Такий розділ дозволяє фільтрувати «непотрібну» для іншого виду обліку інформацію для різних інформаційних баз. Приклад: т.зв. «Управлінський облік» введеться у основі «Управління торгівлею», де відбиваються всі операції, і керівництво бачить повну картину подій, а основу регламентованого обліку «Бухгалтерія підприємства» вивантажуються лише необхідні ведення бухгалтерського і податкового обліку документи.

Які бувають механізми обміну між базами 1С?

Обмін даних можна класифікувати за двома напрямками: використовувані механізми та транспорт для обміну.

Механізми обміну даними 1С

Як правило, при обміні використовується два механізми:

Розподілена інформаційна база (РІБ)- Механізм, що дозволяє налаштувати обмін даними між філією. Механізм передбачає, що обмінюються абсолютно ідентичні зміни БД. Механізм вміє передавати зміни баз даних. Механізм реалізований лише на рівні технологічної платформи.
Універсальний механізм обміну між конфігураціямимеханізм є розробкою фірми 1С для прикладні рішення. Він універсальний і ґрунтується на . Обмін даними здійснюється за допомогою правил xml, які створюються спеціальної конфігурації — . З допомогою даного механізму можна реалізувати як одноразовий обмін, і постійний обмін між 1С конфігураціями. Механізм реалізований лише на рівні зміни, вбудувати у конфігурацію можна з технологічної конфігурації .

Транспорт для обміну даними

Транспортом може бути досить широкий спектр технологій. Розглянемо основні, реалізовані в універсальному механізмі обміну 1С 8.2:

Отримайте 267 відеоуроків з 1С безкоштовно:

Локальний або мережевий каталог- Найпростіший транспорт. Одна ІБ створює файл на диску, друга зчитує його та додає свій файл.
FTP-ресурс- обмін, аналогічний обміну через каталог. Відмінність — обмін здійснюється через протокол FTP.
Поштові повідомлення або E-mail- Обмін проходить за коштами електронної пошти. Конфігурації надсилають один одному поштові повідомлення та регулярно перевіряють поштову адресу на наявність нових повідомлень.
Пряме підключення (COM)- Обмін здійснюється через пряме підключення однієї бази до іншої за коштами.
Інтернет (Web service)– транспортом є веб-служба. Одна інформаційна база підключається до , веб-сервіс підключається до другої бази та транспортує повідомлення. Для здійснення такого транспорту необхідно мати.

Як настроїти обмін даними між базами 1С?

Налаштування обміну даними в 1С за допомогою конфігурації «1С Конвертації даних» на прикладі дивіться у відео:

Обмін даними 1С за розкладом 1С 8.2

Якщо потрібно налаштувати автоматичне розвантаження за розкладом, достатньо налаштувати .

Для клієнт-серверного варіанта

У довіднику "Налаштування обміну даними", на вкладці "Автоматичний обмін" необхідно створити нове регламентне завдання, де вказати розклад:

Для файлового варіанта

У довіднику «Налаштування обміну даними», на вкладці «Автоматичний обмін» необхідно створити нове регламентне завдання, де на вкладці «Обмін за подіями» вказати події, за якими виконуватиметься запуск обміну. Наприклад, при старті певного користувача: