Планы обмена VS История данных

11.12.23

Разработка - Механизмы платформы 1С

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?
 
 Содержание:

 

               Почему я решил писать эту статью?

               Какие способы регистрации изменений есть в платформе?

               Недостатки старых подходов при организации интеграций.

               На что способна История данных?

                              Жизненный цикл изменений.

                                            [Киллер-фича №0]

                              Практическая часть.

                                            Создадим конфигурацию с расширениями.

                                            Включим программно Историю данных.

[Киллер-фича №1]

[Киллер-фича №2]

                                            Пример 1: Первое знакомство с пост обработкой.

[Киллер-фича №3]

[Киллер-фича №4]

[Киллер-фича №5]

                                            Пример 2: Обогащение версии.

[Киллер-фича №6]

[Киллер-фича №7]

Пример 3: Включаем автоматику, чистку отработанных версий и отключаем ненужные реквизиты.

[Киллер-фича №8]         

               Итоги.

Полезные статьи по данной тематике.

Небольшой опрос.

 

Почему я решил писать эту статью?

1 Я уже рассказывал, как в 2021 году провел 100 собеседований за 3 месяца и увидел, что 50% собеседуемых не слышали про Историю данных, 20% что-то слышали, но не знают, чем она отличается от БСП Версионирования данных.

Как по мне — это пугающая статистика.

В связи с чем я поставил себе цель на 2023 год – «Максимально донести информацию по данной технологии платформы». Я спланировал все кубики пазла и это последний кубик, который я планировал рассказать, как часть доклада. В докладе был пункт «Плановый переход с планов обмена на историю данных». Доклада не случилось, поэтому последний кубик будет в виде статьи.

 

 

2 Спойлер. Начал писать цикл статей по интеграции, связанных с Шиной, и пришел к выводу, что без данной статьи получится очень громоздко. 

 

Какие способы регистрации изменений есть в платформе?

  • Первое, что приходит в голову, «Планы обмена».
  • Второе, различные вариации на тему Регистров сведений.

Есть варианты отлова изменений прямо на SQL, но это уже совсем другая история.

 

Для начала я рекомендую почитать или посмотреть выступление Дмитрия Жичкина, так как он уже подробно описал архитектуру и основные недостатки планов обмена -> Планы обмена 1С

На последнем INFOSTART EVENT 2023 он же выступал с докладом «Тюнинг планов обмена», в котором пытался оживить Планы обмена за счет своей разработки DaJet. Уверен многие из нас делали регистрацию изменений на Регистрах сведений и часть проблем уходило, но проблем все равно много.

 

Недостатки старых подходов при организации интеграций.

 

 

  • Регистрируется сам факт изменения.

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

 

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

  • Все или ничего.

Нельзя собирать изменения только по части объекта.

Хотя… Можно, но для этого в подписке «ПередЗаписью» придётся сделать проверку изменений до и после только по определенным реквизитам, а потом еще дорабатывать, когда пересмотрите свои взгляды на первоначальные настройки.

 

  • Мы не знаем автора изменений.

Это вытекает из предыдущих недостатков. На помощь может прийти Версионирование объектов или можно изобразить свой велосипед.

 

  • Последовательность.

Мы не знаем, в какой последовательности изменялись данные.

Это решается при использовании Регистров сведений и поля а ля timestamp.

Либо выставляется приоритет загрузки\выгрузки, но этот велосипед устарел…

 

  • Изменение состава через доработки.

Хотите регистрировать новый объект?

Добавьте его в состав.

Хотите, чтобы он попадал в обмен не всегда?

Необходимо запретить Авторегистрацию и написать код в «ПередЗаписью».

И, кстати, не забудьте дать права.

И только после обновления конфигурации и добавления узла регистрация по объекту начнет работать регистрация изменений.

 

  • Нежелательно использовать в расширении.

Если у вас План обмена в расширении и помимо этого расширения есть еще другие расширения… Объект из расширения трудно будет зарегистрировать на Плане обмена из другого расширения.

 

  • Узел = приемник.

Тут вопросы фильтрации, сериализации, настройки подключения и прочие недостатки. Каждый новый Узел увеличивает нагрузку на основную базу (Источник) за счет повторяемых операций.

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

 

Новые фильтры также ведут к доработкам и монстрообразию.

 

Фильтрация происходит «ПередЗаписью», соответственно, чем больше фильтров и узлов, тем дольше происходит запись объекта.

При этом, чтобы сократить трудозатраты на фильтрацию, бывает, делают общий узел для регистрации всех изменений. Данные с общего узла разгребают и фильтруют на другие узлы отдельным регламентом. Что увеличивает временной лаг.

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

  • Размер сообщений.

За счет того, что мы не знаем, что изменилось в объекте, мы каждый раз будем гонять объект целиком, что пагубно влияет на размер сообщений.

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

 

Плюсы:

  • Быстрый старт.
  • Легки в использовании.
  • Все уже придумано до нас и известны все недостатки.

«Если планы обмена такие плохие, тогда что делать?»

Они не плохие, они просто не про крупные организации с большим документооборотом.

Позвольте показать вам еще один вариант регистрации изменений.

Ну вот, теперь пора переходить к рассказу о Истории данных.

 

На что способна История данных?

Первоначально История данных повторяла тот же функционал, который делала подсистема Версионирования, но заимела ряд киллер-фич, о которых я рассказывал в статье Версионирование объектов VS История данныхВ платформе 8.3.15 было добавлено то, чего в Версионировании нет и никогда не будет. Было добавлено то, что позволяет полноценно использовать историю данных для регистрации изменений.

«В версии платформы 8.3.15 появилась Очередь обработки после записи истории данных»

Дальше поговорим о том «Для чего это и как этим пользоваться».

Для начала посмотрим, как выглядит «Жизненный цикл изменений», а дальше разберем, что к чему.

 

Жизненный цикл изменений.

 

1 При изменении объекта данные об изменении попадают в таблицу Очередь истории данных [DataHistoryQueue0]. Происходит это после события «ПриЗаписи». Данные лежат там до тех пор, пока не произойдет Обновление истории.

!!!Важно!!!

  • Очередь истории данных ведется только по объектам, у которых включена История данных.
  • История данных может быть включена как в конфигураторе, так и программно.

Для включения в конфигураторе нужно выбрать у «Истории данных» значение Использовать.

Для программного включения можно использовать обработку из платформы 8.3.24.

Вытащить ее можно простым кодом:

КопироватьФайл("v8res://mngbase/StandardDataChangeHistory.epf ", "C:\StandardDataChangeHistory.epf");

Либо забрать из статьи История данных. Изменения в платформе 8.3.24

Либо взять бесплатную обработку с более богатым функционалом Настройка состава "Истории данных"

 

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

Версии истории данных хранятся в [DataHistoryVersions], происходит это при следующих действиях:

  • Для автоматического создания через конфигуратор необходимо включить «Обновлять историю данных сразу после записи»

  • Можно включить программно. Для этого в «ПередЗаписью» или «ПриЗаписи» нужно добавить код:
Источник.ЗаписьИсторииДанных.ОбновлятьИсториюСразуПослеЗаписи = Истина;
  • Если автоматическое создание выключено, необходимо сделать регламентное задание со следующим кодом:
ИсторияДанных.ОбновитьИсторию();

Очередь обработки после записи истории данных хранится в [DataHistoryAfterWriteQueue], данные попадают туда при следующих действиях:

  • Для автоматического создания через конфигуратор необходимо включить «Выполнять обработку после записи версии истории данных»

  • Можно включить программно. Для этого в «ПередЗаписью» или «ПриЗаписи» нужно добавить код:
Источник.ЗаписьИсторииДанных.ВыполнятьОбработкуПослеЗаписиВерсии = Истина;
  • Если автоматическое создание выключено, необходимо сделать регламентное задание со следующим кодом:
ИсторияДанных.ВыполнитьОбработкуПослеЗаписиВерсий();

 

Либо в регламенте с ОбновитьИсторию() прописать параметр «ВыполнитьОбработкуПослеЗаписиВерсий»:

ОбновитьИсторию(<ВыполнитьОбработкуПослеЗаписиВерсий>, <АвтоУдалениеИзОбработкиПослеЗаписиВерсий>)

 

Параметры:

<ВыполнитьОбработкуПослеЗаписиВерсий> (необязательный)

Тип: Булево.

Если Истина - после выполнения обновления истории выполнится обработка после записи версий истории данных.

 

Обработка после записи истории данных происходит в менеджере объектов:

Можно выбрать в подписке на событие:

  • РегистрСведенийМенеджер
  • ПланСчетовМенеджер
  • ДокументМенеджер
  • БизнесПроцессМенеджер
  • ПланВидовРасчетаМенеджер
  • ЗадачаМенеджер
  • ПланВидовХарактеристикМенеджер
  • СправочникМенеджер

На момент написания статьи в подписке на событие не дает выбрать:

  • ПланОбменаМенеджер
  • КонстантаМенеджер

 

Киллер-фича №0: Создание версий происходит на уровне платформы, а пост обработка работает с уже созданными версиями в фоновом задании минуя блокировки, которые происходят перед регистрацией у Планов обменов.

 

 

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

Для этого нужно выполнить код:

ИсторияДанных.УдалитьИзОбработкиПослеЗаписиВерсий(Данные, НомерВерсии);

Если «НомерВерсии» не указать, тогда удалятся все версии.

 

Давайте на практике посмотрим, что может История данных.

 

Практическая часть.

Создадим конфигурацию с расширениями.

Создаем пустую базу. Добавляем в нее справочник «СправочникКонфигурации» с реквизитами:

  • ПростоТекст – Строка (250)
  • Ненужный – Строка (10)

Табличная часть «ТаблицаТекста» с реквизитом:

  • ТекстТаблицы – Строка (200)

Создаем 2 Расширения:

  • Расширение1 со справочником «СправочникРасширения1» повторяющий структуру «СправочникаКонфигурации»
  • Расширение2 со справочником «СправочникРасширения2» повторяющий структуру «СправочникаКонфигурации»

 

Нам понадобятся еще Подписки на события «ПередЗаписью» с источником (СправочникОбъект) и «ОбработкаПослеЗаписиВерсийИсторииДанных» с источником (СправочникМенеджер), ну и соответственно модуль для хранения кода обработчиков.

Я буду использовать свое универсальное решение для скорости создания подписок и изменения кода без вмешательства в конфигурацию.

Код я буду выполнять во внешней обработке:

  • ПередЗаписью пока без кода.

  • ОбработкаПослеЗаписиВерсийИсторииДанных пока без кода.

Также понадобится регламент или обработка с обновлением истории:

ИсторияДанных.ОбновитьИсторию();

И регламент или обработка с выполнением обработки после записи версий:

ИсторияДанных.ВыполнитьОбработкуПослеЗаписиВерсий();

 

Включим программно Историю данных.

Создадим элемент справочника «СправочникКонфигурации» до того, как включим Историю данных. Нужно, чтобы продемонстрировать в первом примере «ВидыИзмененияДанных».

Я буду использовать бесплатную обработку Настройка состава "Истории данных" и для начала включу историю данных по объектам целиком.

 

Киллер-фича №1: Мы только что включили Историю данных программно, нам не потребовалось заходить в конфигуратор и прописывать состав. Также просто мы можем и отключить историю. Планы обмена, Регистры сведений так не умеют. В планах обмена нужно изменять состав, а в регистрах добавлять в составной тип новое значение, и без конфигуратора не обойтись.

Киллер-фича №2: Мы только что включили Историю данных программно, для объектов из двух расширений. План обмена и Регистры сведений так смогут только если вы их добавите в основную конфигурацию и то не без телодвижений и обновления конфигурации. Если вы добавите План обмена или Регистр сведений в расширение, тогда вы не сможете добавить в состав объект из другого расширения.

 

 

Пример 1: Первое знакомство с пост обработкой.

В данном примере мы накопим небольшое количество изменений и запустим пост обработку программно.

Создадим еще один Элемент в справочнике «СправочникКонфигурации»

 

 

В обработчике «ОбработкаПослеЗаписиВерсийИсторииДанных» поставим точку останова и подключим в отладке остановку по фоновым заданиям.

Запускаем ОбновитьИсторию(), а следом ВыполнитьОбработкуПослеЗаписиВерсий();

Обратите внимание - прилетел элемент 2, который создан после включения Истории данных, и вид изменения у него «Добавление».

 

 

Также мы видим:

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

  • Дату и время создания изменения

  • Номер версии изменения и самая главная фишка «Различия версий» и данные конкретно этой версии.

 

Давайте теперь изменим элемент, созданный до включения Истории данных, и тот, что был создан после.

Элемент 1. Поменял текст в реквизите «Ненужен» и добавил строку ТЗ.

 

 

Элемент 2. Поменял строки местами и изменил текст в реквизите «Ненужен»

 

 

Запускаем ОбновитьИсторию(), а следом ВыполнитьОбработкуПослеЗаписиВерсий();

 

 

Обратите внимание на следующее:

  • Первый элемент был добавлен до второго элемента, но тогда история данных была выключена, а изменен после того, как был добавлен второй. Мы видим, как работает сортировка при пост обработке:
  1. По дате
  2. По номеру версии
  • Второй момент, на который нужно обратить внимание. Вид изменений у объекта, созданного до включения версии, является «Изменение», хотя данная версия ничем не отличается от добавления первой версии.

 

 

Давайте теперь посмотрим на вторую версию элемента 2:

 

 

Мы видим в «РазличияВерсий» только измененные данные, при этом мы видим, что было до и что стало после.

По табличной части мы меняли местами строки и именно об этом нам и сообщают.

 

 

Киллер-фича №3: При создании версии мы видим пользователя, который изменил объект. План обмена так не умеет, Регистр сведений можно научить этому навыку.

Киллер-фича №4: При создании версии мы видим дату и время изменения. План обмена так не умеет, Регистр сведений можно научить этому навыку.

Киллер-фича №5: Мы видим версию и изменения, сделанные в конкретной версии. Видим значения до изменения. План обмена так не умеет, нечто подобное умеет подсистема Версионирования из БСП, но она хранит версию целиком и изменения можно поймать только путем сравнения версий.

 

 

Пример 2: Обогащение версии.

Допустим, нам нужно добавлять в версию значение, которое отсутствует в объекте, или вы хотите видеть комментарий у версии, что для этого нужно сделать?

В подписку перед записью добавим следующий код:

Источник.ЗаписьИсторииДанных.ДобавитьДополнительныеДанные("ТекущаяДатаСеанса", ТекущаяДатаСеанса(), "Текущая дата сеанса");

Теперь давайте сохраним элемент 2 и пару секунд постоим на точке останова, на добавленной строчке:

Что у нас в пост обработке?

 

 

 

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

 

 

Давайте добавим комментарий к версии 3. Напишем «Добавили текущую дату сеанса».

Сделаем небольшую обработку:

 

 

Код кнопки «ЗаписатьКомментарий»:

&НаКлиенте
Процедура ЗаписатьКомментарий(Команда)
	ЗаписатьКомментарийНаСервере(Данные, Версия, Комментарий);
КонецПроцедуры
&НаСервереБезКонтекста
Процедура ЗаписатьКомментарийНаСервере(Данные, Версия, Комментарий)	
	ИсторияДанных.ЗаписатьКомментарий(Данные, Версия, Комментарий);
КонецПроцедуры

 

Также можно создать версию объекта вручную и прописать комментарий.

Код создания версии:

// Процедура - Произвести запись версии
//
// Параметры:
//  Данные 	 -  БизнесПроцессОбъект, 
//				ПланВидовРасчетаОбъект, 
//				ПланСчетовОбъект, 
//				ПланВидовХарактеристикОбъект, 
//				ПланОбменаОбъект,
//				РегистрСведенийНаборЗаписей,
//				КонстантаМенеджерЗначения, 
//				СправочникОбъект, 
//				ЗадачаОбъект, 
//				ДокументОбъект - Объект конфигурации по которому будет создана версия  
//  ВидИзменения - Строка - "Добавление", "Изменение" или "Удаление"
//  Комментарий  - Строка - Текст комментария
//
Процедура ЗаписатьВерсию(Данные, ВидИзменения = "Изменение", Комментарий = "Версия записана вручную") Экспорт  
	
	ДатаСоздания 		= ТекущаяДатаСеанса(); 
	
	ТекущийПользователь 	= ПользователиИнформационнойБазы.ТекущийПользователь() ;    
	 
	ИсторияДанных.ЗаписатьВерсию(Данные, 
				ДатаСоздания, 
				ТекущийПользователь.УникальныйИдентификатор, 
				ТекущийПользователь.Имя, 
				ТекущийПользователь.ПолноеИмя, 
				ВидИзмененияДанных[ВидИзменения], 
				Комментарий);   
								
КонецПроцедуры

 

Киллер-фича №6: Мы можем добавлять значения, в версию которых нет в объекте. План обмена так не умеет, Регистр сведений можно научить этому навыку, но это будут доработки.

Киллер-фича №7: Мы можем добавлять комментарий к версии объекта. План обмена так не умеет, Регистр сведений можно научить этому навыку.

 

 

Пример 3: Включаем автоматику, чистку отработанных версий и отключаем ненужные реквизиты.

Чтобы не запускать вручную обновление и выполнение пост обработки, «ПередЗаписью» добавим код:

	Источник.ЗаписьИсторииДанных.ВыполнятьОбработкуПослеЗаписиВерсии = Истина;
	Источник.ЗаписьИсторииДанных.ОбновлятьИсториюСразуПослеЗаписи = Истина;

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

Примерный код для «ОбработкаПослеЗаписиВерсийИсторииДанных»:

	// Соответствии содержит данные и версию для удаления
	УдаляемыеДанные = Новый Соответствие;
	Для Каждого ТекущаяЗапись Из ИнформацияОЗаписиВерсий Цикл
		

		// Выполняем действия 
		
		
		// Если действия выполнены добавляем в список удаляемых
		УдаляемыеДанные.Вставить(ТекущаяЗапись.Данные, ТекущаяЗапись.НомерВерсии);
		
	КонецЦикла;	
	
	// Чистим отработанные данные
	Для Каждого Данные Из УдаляемыеДанные Цикл 
		
		// Если номер не установлен, то из обработки удаляются все версии по указанным данным.
		ИсторияДанных.УдалитьИзОбработкиПослеЗаписиВерсий(Данные.Ключ);
		
	КонецЦикла;

Проверим, как работает.

Добавил третью строку в элемент 2 справочника «СправочникКонфигурации» и записал.

 

 

Сразу же у нас сработала автоматика, и мы из «ПередЗаписью» прилетели в «ОбработкаПослеЗаписиВерсийИсторииДанных», где произошла чистка отработанных данных из пост обработки.

 

Наш код работает, двигаемся дальше.

Теперь давайте создадим элементы в расширениях.

Расширение 1.

 

 

Расширение 2.

 

 

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

В Расширении1 у справочника отключим реквизит «Ненужный»

 

 

В Расширении2 у справочника отключим табличную часть «ТаблицаТекста»

 

 

В основной конфигурации у справочника отключим все кроме стандартных реквизитов.

 

 

Теперь в «СправочникКонфигурации» у элемента 2 изменим порядок строк и нестандартные реквизиты:

 

 

Записываем и смотрим в пост обработке, какие измененные данные прилетели.

 

 

Вот так просто мы отключаем сбор изменений по ненужным реквизитам. Соответственно для расширений все отработало точно так же.

Киллер-фича №8: Мы можем отключать сбор изменений по ненужным реквизитам. Мы можем работать программно как с основной конфигурацией, так и с расширениями. План обмена так не умеет, Регистр сведений можно научить этому навыку, но это будут доработки.

 

 

Итоги.

Как вы видите, в платформе для регистрации изменений есть не только Планы обмена и Регистры сведений, но и более тонкий механизм, позволяющий перейти на новый уровень интеграции. Он, есть начиная с 8.3.15, а значит ничего не мешает его использовать. Я показал его основные фишки, дальше дело за вами.

Лично я на текущем месте перешел на историю данных для регистрации изменений.

 

Полезные статьи по данной тематике:

1 Настройка состава "Истории данных" - Бесплатная обработка по программному включению истории данных.

2 История данных и БСП - Данная статья показывает процесс перехода с Версионирования на Историю данных.

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

3 Версионирование объектов VS История данных – Сравнение двух конкурирующих механизмов и ковыряние в SQL по части Истории данных. В статье видно, что История данных на данный момент имеет много киллер фич по отношению к Версионированию объектов.

4 История данных. Изменения в платформе 8.3.24 В данной статье я выложил типовую обработку из платформы 8.3.24 и сравнил ее со своей из первого пункта.

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

6 Планы обмена 1С - Подробная статья по устройству Планов обмена.

7 Интегрируй это - Замечательный доклад, в котором упоминается История данных и подписка «ОбработкаПослеЗаписиВерсииИсторииДанных»

 

 У меня есть к Вам пара вопросов. Напишите в комментариях, интересны ли вам следующие темы:

1 Было бы вам интересно сделать сквозной пример (frontend и backend) на NodeJS + Express + React и т.д.?

2 Интересно было бы почитать цикл статей под названием «Добро пожаловать на борт?», затрагивающие следующие темы:

  • Поиск работы. Поиск работников. Взгляд с двух сторон.
  • Собеседование в удовольствие. На что обратить внимание, как не превратить собеседование в допрос. Тайминг, вопросы. Плюсом могу запросить честные отзывы собеседуемых.
  • Программисты из «Желтой коробочки», хорошо это или плохо. Быстро, Дешево, Криво или почему Фирма 1с убивает ИТшников?
  • Виды сотрудников. Виды руководителей.
  • Полезный и вредный опыт.
  • Виды работодателей. От галеры до бюрократической ямы.

Если я увижу интерес, то спланирую график по оформлению материала в ряд статей, а может, замахнусь на канал с видео.

 

На этом статью заканчиваю и ставлю еще одну галочку в выполненные задумки.

Надеюсь, статья была вам полезна. Желаю всем профессионального роста и интересных задач!

Версионирование объектов Планы обмена История данных БСП Платформа версия Киллер-фича расширение 8.3.15 SQL Настройки Метаданные Очередь отборы дополнение версии регистрация изменений ВыполнитьОбработкуПослеЗаписиВерсий ОбработкаПослеЗаписиВерсийИсторииДанных

См. также

SALE! 10%

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки

Обмен между базами 1C Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) в продаже с 2015 года, постоянно работаем над их развитием | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

50722 руб.

04.08.2015    160239    368    268    

349

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 руб.

12.06.2017    135509    728    291    

391

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.223.x) и БП 3.0 (3.0.149.x). Правила подходят для версии ПРОФ и КОРП.

28000 руб.

15.12.2021    20584    136    38    

93

SALE! 10%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0. Переносятся документы, начальные остатки и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | В продаже с 2019г. | Воспользовались более 176 предприятий! | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой, обращайтесь!

38500 34650 руб.

15.04.2019    68801    179    139    

111

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.87.x) и УТ 11.5 (11.5.16.x).

28000 руб.

23.07.2020    46738    199    64    

162

SALE! 10%

Перенос данных из БП 3.0 в УТ 11 / КА 2 / ERP 2. Переносятся начальные остатки, документы и справочники

Обмен между базами 1C Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

В продаже с 2014г. | Воспользовались более 122 предприятий! | Перенос данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных)

50722 45650 руб.

31.10.2014    231847    124    327    

296

SALE! 10%

Перенос данных из БП 3.0 в УНФ 3.0 / УНФ 1.6. Переносятся остатки, документы и справочная информация

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление нашей фирмой 3.0 Россия Платные (руб)

В продаже с 2018г. | Воспользовались более 41 предприятия! | Правила конвертации (КД 2) для переноса данных из БП 3 в УНФ | Переносятся все виды документов, начальные остатки и вся возможная справочная информация | Есть фильтр по организациям | Оперативно обновляем на новые релизы | Оказываем техподдержку | В комплект файлов входит инструкция, авторская версия обработки "Универсальный обмен...", актуальные правила переноса данных и архив старых версий переноса | Учет в БП 3 должен быть корректным, некорректные данные не переносятся | Можно бесплатно проверить на вашем сервере до покупки!

50722 руб.

10.07.2018    67736    41    123    

46

SALE! 10%

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Воспользовались более 79 предприятий! | Предлагаем приобрести готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | В продаже с 2020г. | Оперативно обновляем правила до актуальных релизов 1С | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

48278 43450 руб.

03.12.2020    34401    81    58    

78
Отзывы
3. zhichkin 1455 11.12.23 15:08 Сейчас в теме
Отличная статья! Вот теперь сложилась практически полная картина по всем возможным механизмам регистрации изменений в 1С. Можно ещё добавить механизм взаимодействия, к которому цепляется 1С:Шина - это про объекты конфигурации типа "Сервисы интеграции" (по сути аналог регистрации изменений через регистры сведений) и будет 100%. Кроме этого (надеюсь уважаемый автор не будет против), позволю себе ещё добавить ссылку на свою же статью "История данных 1С".
swenzik; NIKAMED_IT; dsdred; +3
Остальные комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. artbear 1522 11.12.23 11:32 Сейчас в теме
название статьи очень интересно, но размер шрифта статьи уж очень мелкий (
читать больно

а на скриншотах нормальный размерчик )
NIKAMED_IT; dsdred; +2
2. dsdred 3319 11.12.23 11:36 Сейчас в теме
(1)Спасибо за обратную связь.
Шрифт увеличил.
artbear; +1
3. zhichkin 1455 11.12.23 15:08 Сейчас в теме
Отличная статья! Вот теперь сложилась практически полная картина по всем возможным механизмам регистрации изменений в 1С. Можно ещё добавить механизм взаимодействия, к которому цепляется 1С:Шина - это про объекты конфигурации типа "Сервисы интеграции" (по сути аналог регистрации изменений через регистры сведений) и будет 100%. Кроме этого (надеюсь уважаемый автор не будет против), позволю себе ещё добавить ссылку на свою же статью "История данных 1С".
swenzik; NIKAMED_IT; dsdred; +3
4. dsdred 3319 11.12.23 15:17 Сейчас в теме
(3)Спасибо за отзыв.

Про сервисы интеграции я планирую рассказать.
Сначала вводная статья будет с ответами на вопросы, потом про сообщения и сервисы интеграции.
zhichkin; +1
5. van_za 246 11.12.23 20:07 Сейчас в теме
Интересная статья , спасибо.
С регистрации понятно, минус в том что нужно удалять версии и не получится использовать версии как версии.
dsdred; +1
6. dsdred 3319 11.12.23 22:05 Сейчас в теме
(5)
минус в том что нужно удалять версии и не получится использовать версии как версии.

Не совсем понял.

Зачем удалять версии?
Механизм из статьи - это отдельная таблица с изменениями.
Таблицы:
[DataHistoryLatestVersions], [DataHistoryLatestVersions1], [DataHistoryLatestVersions2] – Последние версии истории данных
[DataHistoryVersions] – Изменения в версии (аналогично разносным изменениям в SQL)

В данной статье рассказ про:
[DataHistoryAfterWriteQueue] – Очередь обработки после записи истории данных.
Вот из этой таблицы мы и удаляем уже отработанные данные.
+
13. van_za 246 13.12.23 15:44 Сейчас в теме
(6)
Разобрался, да интересное применение...еще раз спасибо за статью
+
14. dsdred 3319 13.12.23 20:31 Сейчас в теме
(13)Рад, что статья понравилась и разобрались.
+
7. fancy 35 12.12.23 07:26 Сейчас в теме
Отличная статья, единственно я не понял по вашему скриншоту момент
Мы видим, как работает сортировка при пост обработке:
По дате убывания
По номеру версии

на скрине дата по возрастанию же
dsdred; +1
8. dsdred 3319 12.12.23 07:44 Сейчас в теме
(7)Спасибо за замечание.
Видимо забыл убрать слово "убывание"

Пример по которому понятна сортировка прикладываю.
Прикрепленные файлы:
+
9. van_za 246 12.12.23 08:45 Сейчас в теме
(6)
Видимо что не понимаю, если удаляем то как посмотреть потом историю изменений?
Как заменить версиями план обмен если в плане обмена для каждого приёмника фиксируется и комитится своя строчка?
Andreeei; +1
10. dsdred 3319 12.12.23 09:09 Сейчас в теме
(9)
Видимо что не понимаю, если удаляем то как посмотреть потом историю изменений?

Посмотрите в статье на картинку Жизненный цикл изменений.

То есть у нас две таблицы.
1 [DataHistoryVersions] она хранит разносные изменения. Это и есть версии данных

Подробней про версии писал в статье -> Версионирование объектов VS История данных

2 [DataHistoryAfterWriteQueue] хранит тоже изменения, что и в [DataHistoryVersions], но служит не для постоянного хранения, а для того чтобы вы что-то с ними сделали (например отправили сообщения на основании их) и удалили.

Как заменить версиями план обмен если в плане обмена для каждого приёмника фиксируется и комитится своя строчка?

Про это я буду говорить в следующих статьях по интеграции, но кратко опишу.

Самое частое использование планов обмена это КД2-3 там 1 узел = 1 база и настройки подключения хранятся на узле.
КД хорошо подходит для мелких организация, но скажем честно механизм устарел и не годится для среднего и крупного бизнеса где большой поток данных.

Есть более современные инструменты. Брокеры (RabbitMQ, Kafka, NATS и т.д.) С помощью этих решений организовывается другой тип обмена. Создается топик в который шлются изменения или несколько топиков, а в базах приемниках подписываются на эти топики и считывают все что туда попадает. Соответственно сам топик выступает в роле накопительного Узла.

Есть ESB решения (WSO2, 1C Шина, mule esb, DataReon и т.д.), там принцип похож на брокеры, но там маршруты, коннекторы и трансформация данных.

По сути можно либо на стороне 1с в базе источника указывать получателей и отправлять в брокер или ESB. Или организовать трансформацию и маршрутизацию силами ESB. А дальше данные прилетают подписчикам в первоначальном или измененном в ESB виде.


П.С. Об этом всем я хотел рассказывать уже в следующем цикле статей.
+
11. PerlAmutor 129 12.12.23 14:13 Сейчас в теме
Интересно стоит ли ждать в БСП механизм выполнения обработчиков обновления через этот способ, а также механизм Обновления Через Копию в ERP.
+
12. dsdred 3319 12.12.23 15:08 Сейчас в теме
(11) это риторический вопрос. Кто его знает, что нам ждать...

Как показывает практика чаще всего проще самому сделать чем ждать.
+
15. Cyberhawk 135 16.12.23 20:50 Сейчас в теме
как работает сортировка при пост обработке:
1. По дате
2. По номеру версии

Может просто по номеру версии? А то что дата также возрастает (но необязательно) - уже просто приятный бонус...
+
16. dsdred 3319 16.12.23 20:53 Сейчас в теме
(15) я в 8 коментарии изобразил сортировку.
+
17. Cyberhawk 135 16.12.23 20:58 Сейчас в теме
(16) Из которой по идее совершенно спокойно можно убрать сортировку по дате
dsdred; +1
18. dsdred 3319 16.12.23 20:59 Сейчас в теме
(17) впринципе да. Согласен.
+
19. rozer 306 17.12.23 17:42 Сейчас в теме
Как-то давно нашел видео по этой теме https://youtu.be/pqEQYPzZpMw?si=b77uSAGPZxBxszMV
dsdred; +1
20. JohnyDeath 301 07.01.24 10:04 Сейчас в теме
Большой минус истории данных по отношению к планам обмена - это то, что в истории никак не отражается факт изменения регистра накопления. Поэтому, если, например, нужно оперативно отправлять остатки во внешнюю систему, то обойтись только историей данных не получится. Всё равно придется вешать обработчик на регистр и писать факт изменения в какую-то очередь.
А в остальном - да, прекрасный инструмент.
+
21. dsdred 3319 07.01.24 10:40 Сейчас в теме
(20) согласен.
Видимо логика была от документов, а не проводок.
+
22. JohnyDeath 301 07.01.24 13:37 Сейчас в теме
(21) да, хранить "историю" записи регистра накопления или проводки - такое себе.
Но не помешало бы иметь те же самые события "после записи", что и для объектов данных.
Плясать "от документов", а не от записей регистров довольно-таки проблематично. Плюс надо будет постоянно помнить об обменах на базе Истории при добавлении новых документов или допилки старых.
+
23. dsdred 3319 07.01.24 21:15 Сейчас в теме
(22) Что сказать... многое зависит от того как продумаешь интеграцию. При правильном подходе проектирования интеграций, все будет задокументировано и описано, что куда и как летит. Тогда и помнить не надо.
Мне пока достаточно функционала истории данных, не будет хватать буду думать и миксовать с планами обмена.
+
24. user1589569 22.01.24 19:40 Сейчас в теме
Спасибо огромное за интересную, содержательную статью!!!))))
+
25. dsdred 3319 22.01.24 20:29 Сейчас в теме
(24)рад, что статья понравилась.
+
26. Pryanishnikov_Vladimir 06.02.24 06:53 Сейчас в теме
По каким причинам может не заходить в ОбработкаПослеЗаписиВерсийИсторииДанных менеджера обьекта? История данных включена в конфигураторе, глаки на ОбновлятьИсториюСразу и на ВыполнятьОтложеннуюОбработку стоят
+
27. dsdred 3319 06.02.24 09:31 Сейчас в теме
(26) Точка остановы не заходит?
Если да тогда: Отладка должна быть включена и подключение выбрано "Фоновые задания"

Чтобы вручную запустить обработку накопленных изменений необходимо выполнить код:
ИсторияДанных.ОбновитьИсторию(); // создаем версии

ИсторияДанных.ВыполнитьОбработкуПослеЗаписиВерсий(); // запускаем пост обработку
Pryanishnikov_Vladimir; +1
28. Pryanishnikov_Vladimir 06.02.24 09:34 Сейчас в теме
(27) Это все сделано да. Работает в другой базе. Все просто перенес. Проблему нашел. Работает все это начиная с совместимости 8.3.15, в текущей базе стоит 8.3.14 - в копии поднял - заработало. Вынесите это жирно в начале статьи
+
29. user1866782 06.02.24 09:56 Сейчас в теме
Не было проблем с регистрами сведений? Программно включил историю данных, в событие перед записью "ВыполнятьОбработкуПослеЗаписиВерсии" установил в Истину, программно обновляю историю с флагом "ВыполнитьОбработкуПослеЗаписиВерсий", история пишется, а в очередь постобработки не попадает, таблица DataHistoryAfterWriteQueue пустая, со справочниками и документами все норм.
+
30. dsdred 3319 06.02.24 10:04 Сейчас в теме
(29) С регистрами пока не связывался, проверю отпишусь.
+
31. SuraevIS 20.02.24 13:37 Сейчас в теме
Спасибо за статью. Не могли бы Вы пояснить вопрос не по теме:
"Я буду использовать свое универсальное решение для скорости создания подписок и изменения кода без вмешательства в конфигурацию." - Поясните пожалуйста механизм создания подписки не влезая в конфигуратор.
+
32. dsdred 3319 20.02.24 13:54 Сейчас в теме
(31)Добрый день.
Имеется ввиду, что в расширении я создал несколько универсальных подписок, которые позволяют мне выбирать в Клиенте источник и вносить либо код либо указать внешнюю обработку которая содержит код подписки.
В плане сделать возможность выбора внутренней обработки.

Собственно я не лажу в конфигуратор обозначает не дорабатываю конфигурацию, после того как создал универсальные подписки.
SuraevIS; +1
33. Somebody1 68 13.03.24 12:40 Сейчас в теме
Добрый день, спасибо за качественную публикацию!

Вопрос: правильно ли я понимаю, что если мы используем Историю данных для регистрации изменений объектов, и при этом отключим не нужные ДЛЯ ИНТЕГРАЦИИ реквизиты (как у вас в Примере 3), то при этом мы потеряем версионирование при изменении этих реквизитов?

Иными словами, получается, что мы настроим Историю данных для нужд интеграции, но при этом потеряем возможность её полноценно использовать для версионирования объектов.
+
34. dsdred 3319 13.03.24 12:44 Сейчас в теме
(33)Добрый день.
Вопрос: правильно ли я понимаю, что если мы используем Историю данных для регистрации изменений объектов, и при этом отключим не нужные ДЛЯ ИНТЕГРАЦИИ реквизиты (как у вас в Примере 3), то при этом мы потеряем версионирование при изменении этих реквизитов?


Верно понимаете.

Я лично отключаю галочки по тем элементам у которых стоит "Удалить", грубо говоря у тех которые в следующих релизах исчезнут.
+
35. eSpe 17.03.24 04:04 Сейчас в теме
Создали объект история данных для истории данных. Статья посвящена тому как забить гвоздь микроскопом. ИМХО в крупных и промышленных решениях такие подходы обычно не приветствуются.
+
36. dsdred 3319 17.03.24 09:27 Сейчас в теме
(35) создали обьект первоначально для истории данных. А потом добавили пост обработку для обменов.

А какие подходы по вашему "ИМХО" приветствуются?

Я видел в крупных проектак еще в 2019 как делали самописный механизм повторяющий типовой о котором я рассказал в статье, но делали его до того как он появился.
+
Оставьте свое сообщение