1s 8.3 преобразуване на данни 2.1 как да се използва. Видео инструкции за конвертиране

1. Въведение.

2. Какво ще ви трябва: 1C конфигурация: Преобразуване на данни 2.* и обработка от пакета. За примерни задачи нека вземем конфигурации 1C: Управление на търговията 11 и 1C: BP 3.*.

Така че, за да разработите правила за качване на данни в 1C, ще ви трябва конфигурацията на 1C: Преобразуване на обект 2, както и обработката, включена в пакета.

Например, ние вече разположихме база данни за преобразуване и я стартирахме.

Ще напишем разработването на правила за обмен между конфигурацията 1C: Trade Management 11 и 1C: Enterprise Accounting 3 (правила за обмен UT / ACCOUNT).

3. Ще ни трябва обработка, за да разтоварим структурата на метаданните и обмена.

Първото нещо, което трябва да получите за разработка, са файлове със структура на метаданни. Това се прави с помощта на обработка за разтоварване на структурата на метаданни, включена в пакета за преобразуване на обекти.

Всъщност в разопакованата конфигурационна директория за конфигурации на управлявани формуляри се интересуваме от обработката на MD83Exp.epf. Ако разтоварването трябва да се извърши от конфигурации на обикновени формуляри, тогава се използва обработка на MD82Exp.epf. Това е, ако например трябва да получите структура от такива конфигурации като 1C: UT 10, 1C: Manufacturing Enterprise Management 1.3, 1C: Integrated Automation 1.1, 1C: Zup 2.5 и т.н.

Освен това, за да качвате и изтегляте данни в 1C, като използвате нашите правила, ще трябва да обработите „Универсален обмен на данни в XML формат“ V8Exchan83.epf за конфигурации на управлявани форми като 1C: Управление на търговията 11.*, 1C BP 3, 1C: ERP 2. * и подобни. И съответно V8Exchan83.epf - за конфигурации на обикновени форми.

4. Качване на структурата на метаданните на конфигурацията 1C: Управление на търговията 11.3 и 1C: Enterprise Accounting 3.0.*

Нека започнем с изтегляне на структурата на метаданните от конфигурацията 1C: Enterprise Accounting 3.
Нека отворим обработката MD83Exp.epf

Във формуляра за обработка има допълнителни настройки, където можем да активираме или деактивираме опцията за качване на регистри и движения в 1C. Има и избор къде да се извърши качването: на 1C сървъра или „на клиента“. Посочете името на файла, където ще се качи структурата от данни. По подобен начин разтоварваме структурата на метаданните на конфигурацията Trade Management 11.

Сега трябва да качите конфигурацията в базата данни за преобразуване. До тази точка може да се стигне както от списъка с конфигурации, така и от списъка с реализации. Нека просто стартираме от работния плот:

В диалоговия прозорец заредете структурата на BP:

И по същия начин - структурата на Търговския мениджмънт.

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

6. Създаване на правила за преобразуване в 1C, като се използва конкретен пример за задача.

След това отидете на „Настройване на обектни правила“, където създаваме нова настройка.
В диалоговия прозорец за създаване на преобразуване изберете конфигурацията „източник“ и конфигурацията „дестинация“ (която сте заредили преди това) и щракнете върху OK.

Тъй като в тази статия планирах да покажа създаване „от нулата“ и „без боклук“, напомням ви, че не създаваме нищо автоматично. Няма прототипи.

Няма да правим нищо в този диалогов прозорец, просто щракнете върху „Затваряне“.

Нека създадем правила за качване не на един документ в един, а на един тип в друг, например документа Продажби на стоки и услуги от UT 11 с необходимите справочници в документа Получаване на стоки и услуги в BP 3.

И така, създаваме нов PKO (правилото за конвертиране на обекти в 1C)

Изберете източника Продажби на стоки и услуги и местоназначението Получаване на стоки и услуги и щракнете върху OK.
В този случай ще се появи диалогов прозорец, където отново отказваме автоматичното създаване на PKS (Property Conversion Rules). След това ще изберем само необходимите.

Но на предложението за създаване на DVP (правила за качване на данни) отговаряме с „Да“.

Създават се PVD, които ще бъдат отразени в обработката на универсалния XML обмен за избор:

Ще бъдат създадени и правила за преобразуване на данни с празни правила за преобразуване на свойства.

Освен това е ясно, че по подразбиране се предлага софтуерът да се търси по вътрешния идентификатор на обекта. Това се показва от лупата близо до PCO. Ще направим собствено търсене и ще го направим по номер на документ и дата в началото на деня.

Премахваме търсенето по UIO:

Сега нека започнем да сравняваме необходимите свойства (подробности) на обекта. За да направите това, щракнете върху „Синхронизиране на свойства“ (етикет „1“ на екрана). Премахваме рекурсивното създаване на правила („2“). Премахнете всички маркирани детайли ("3"). И ние сами ще изберем каквото ни трябва.

Например, изберете какво ви трябва:

Обръщам внимание на факта, че ще направим PKS на контрагента в организацията, а организацията в контрагента, а също така ще сравним някои подробности, които не съвпадат по име, например „Валута“ и „Документ Валута".

Където виждаме, че все още няма правила за преобразуване.

Нека започнем да преминаваме през детайлите и да ги описваме. Първо настройваме търсене на документи, както писах по-рано, качваме и търсим документ в началото на датата и променяме номерирането. Ще заменим първите три знака с нашия префикс „UTB“. И тъй като номерацията в BP и UT е по 11 знака, правим съставно число: нашия префикс и 8 знака от източника. Пример в екранната снимка по-долу.

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

За да направите това, задавайки PKS като неизвършено, 0 или 1, ние го използваме като булево.

Като използваме валута като пример, създаваме правило за преобразуване на обект за PKS. В същото време смятаме, че има валути и в двете бази данни и те трябва да бъдат синхронизирани чрез код. Следователно няма да създадем всички PKS в PQS на валутата, а само ще добавим код за търсене. Тези. Отказваме предложението за създаване на ПКС на обекта.

Създаденото правило за преобразуване беше заменено в PQR на документа за PKS. А самото правило по подразбиране се предлага от уникален идентификатор. Поправяме го, търсим кода и настройваме свойството така, че да не създаваме нов обект.

В резултат на това получаваме следната опция:

След това, по аналогия, създаваме PKO и PKS за останалите детайли. Освен това търсим организация по контрагент и обратно по TIN. Приблизително така изглежда с минимални подробности (можете да добавите, ако е необходимо).

За PCO споразумения с насрещни страни търсим по PKS контрагенти, име и собственик.

Нека да видим как да посочим необходимата стойност в типа изброяване в PKS. Например атрибутът „Тип операция“. Тук можете да използвате различни условия и заместващи стойности. Например, ние се нуждаем от „тип операция“ винаги да бъде разтоварен „Стоки“, в този случай е достатъчно да напишете необходимата стойност в реда „чело“.

По-долу е показано как да инсталирате без затруднения и в повечето случаи PCS за множественост на взаимното разплащане, процент на взаимно разплащане, счетоводна сметка.

За PKO Nomenklatura ще оставим търсенето по вътрешен уникален идентификатор. Но позволете ми да насоча вниманието ви към това как можете да предефинирате групата си. Например, съгласни сме, че нов артикул ще бъде качен от конфигурацията 1C: Trade Management 11, но е необходимо артикулът да бъде събран в конкретна група „Нашата група“.

За да изпълним тази задача, ние създаваме друг PKO. Нека го наречем „NomenclatureParent“, което ще посочим в PCS на родителя в правилото за преобразуване.

Настройваме две търсения: по име, където стриктно посочваме името на нашата група, а задължителното свойство на атрибута „Това е група“ е зададено на true.

Тъй като решихме, че всичките ни артикули попадат в нашата група, няма нужда да разтоварваме групи от UT 11 при разтоварване.За да направите това, в номенклатурния софтуер в манипулатора на събития „Преди разтоварване“ ще зададем филтър, който не е необходимо да разтоварва групите „Отказ = Източник. Тази група;".

В DRP (правила за качване на данни) за продажби на продукти и услуги ще добавим филтър, така че документите, маркирани за изтриване, да не се качват. За да направите това, във VDP в манипулаторите на събития „Преди разтоварване“ ще напишем филтъра „Failure = Object.DeletionMark;“.


Нека запазим разработените правила във файл.


7. За да обобщим: Качване и зареждане на данни чрез разработени правила за обмен на данни.

Отворете в 1C: Управление на търговията 11 обработката „Универсален обмен на данни в XML формат“ V8Exchan83.epf.

Разтоварването е завършено, сега използваме същата обработка за зареждане в 1C: Enterprise Accounting 3.


Зареждането приключи. Нека да проверим как се зареди. И така, документът се зарежда, както искахме - нашата организация се зарежда в контрагента, а контрагентът в организацията. Всички счетоводни акаунти са изтеглени и инсталирани. Получихме номера на документа с нашия префикс и в началото на деня. Всички предоставени данни са попълнени.

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


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

Сега има преобразуване на данни 3, което решава други проблеми. Следователно е необходимо и преобразуване 2. Успех на всички в ученето и усвояването.

Разбира се, ако сте програмист и това е основната ви работа, можете да опитате сами да напишете преобразуването. Но ако не, тогава трябва да цените времето си във вашата сфера на дейност и да помолите професионалисти да изпълнят тази задача.

Преобразуването на данни 2.0 и 2.1 е технологична конфигурация на 1C, реализирана на версии на платформа от 8.1 до 8.3.

Основната задача на инструмента е да напише правила за обмен между приложни решения 1C 8 и 7. Текущата версия на преобразуването на данни днес е 3.0.

Преобразуването на данни е много полезна конфигурация, с негова помощ можете да решите не само проблема с прехвърлянето на информация от една информационна база в друга, но също така, например, конвертирането на информация в една база данни.

Конфигурацията е много удобна за използване с .

Преобразуването на данни ще бъде полезно за всеки програмист: притежаването на умения за създаване на правила за обмен е сериозен плюс за професионални умения.

За да научите как да работите с конфигурация, решаването на практически проблеми е най-подходящо. Опитайте се да измислите задачи за себе си, например: прехвърлете информация от една база данни в друга, превърнете документ за продажба в документ за получаване, „въведете“ текущи счетоводни салда в документ „въвеждане на салда“ и други задачи.

Ще бъде много полезно да разберете „стандартните“ правила за обмен на 1C 8.3; там често можете да намерите интересни примери за изпълнение на задачи.

За да разберете основите, ще ви трябват материали, ще ги разгледаме по-долу.

Видео инструкции за конвертиране

За основите на настройка на обмен на данни в 1C с помощта на конфигурацията „1C Data Conversion“ вижте примера във видеоклипа:

Материали, учебници за изучаване на 1C Data Conversion 2.0

В интернет няма твърде много материали и документация, опитах се да събера най-важните и интересни материали:

0. На първо място, препоръчвам безплатния видео курс на Иля Леонтьев, достъпен е на връзка.

1. Бих посъветвал преди всичко да използвате вградената помощ в конфигурацията. Наистина е добре написано и технически добре изпълнено:

2. Вторият по значимост източник на информация е сайтът http://www.mykod.info/ (сайтът е закрит), специализиран именно в преобразуване на данни. Там можете да изтеглите голям брой материали за конвертиране.

3. Отделно бих искал да подчертая учебника - (автор - Олга Кузнецова).

Мигрирането на данни между различни конфигурации не е тривиална задача. Както винаги, има няколко решения, но не всички от тях са оптимални. Нека се опитаме да разберем нюансите на прехвърлянето на данни и да изберем универсална стратегия за разрешаване на такива проблеми.

Проблемът с миграцията на данни (говорим само за продуктите на компанията 1C) от едно решение към друго не възникна вчера. Компанията 1C разбира отлично какви трудности срещат разработчиците при създаването на миграции, така че се опитва по всякакъв възможен начин да помогне с инструменти.

По време на разработването на платформата компанията въведе редица универсални инструменти, както и технологии, които опростяват преноса на данни. Те са вградени във всички стандартни решения и като цяло проблемът с миграцията между идентични конфигурации е решен. Победата още веднъж се потвърждава от тясната интеграция на стандартните решения.

При миграциите между нестандартни решения ситуацията е малко по-сложна. Богат избор от технологии позволява на разработчиците самостоятелно да изберат оптималния начин за решаване на проблем от тяхна гледна точка.

Нека да разгледаме някои от тях:

  • обмен чрез текстови файлове;
  • използване на обменни планове;
  • и т.н.

Всеки от тях има своите плюсове и минуси. За да обобщим, основният недостатък ще бъде неговата многословност. Независимото внедряване на алгоритми за миграция е изпълнено със значителни времеви разходи, както и дълъг процес на отстраняване на грешки. Дори не искам да говоря за по-нататъшна подкрепа за подобни решения.

Сложността и високата цена на поддръжката накараха компанията 1C да създаде универсално решение. Технологии, които позволяват да се опрости разработката и поддръжката на миграциите, доколкото е възможно. В резултат на това идеята беше реализирана под формата на отделна конфигурация – „Преобразуване на данни“.

Преобразуване на данни - стандартно решение, независима конфигурация. Всеки потребител с абонамент за “ITS:Prof” може да изтегли този пакет напълно безплатно от сайта за поддръжка на потребители или ITS диска. Инсталацията се извършва по стандартен начин - както всички други стандартни решения от 1C.

Сега малко за предимствата на решението. Да започнем с най-важното - универсалността. Решението не е пригодено за конкретни конфигурации/версии на платформа. Работи еднакво добре както със стандартни, така и със персонализирани конфигурации. Разработчиците имат универсална технология и стандартизиран подход за създаване на нови миграции. Гъвкавостта на решението ви позволява да подготвите миграции дори за платформи, различни от 1C:Enterprise.

Вторият голям плюс са визуалните помощни средства. Простите миграции се създават без програмиране. Да, да, без нито един ред код! Само за това си струва да отделите време за изучаване на технологията веднъж и след това да използвате безценни умения многократно.

Третото предимство, което бих отбелязал, е липсата на ограничения за разпространение на данни. Самият разработчик избира метода за доставяне на данни до конфигурацията на приемника. Налични са две опции: качване в xml файл и директна връзка с информационната база (COM/OLE).

Учи архитектура

Вече знаем, че преобразуването на данни може да направи чудеса, но все още не е напълно ясно какви са техническите предимства. Първото нещо, което трябва да разберете е, че всяка миграция на данни (преобразуване) се основава на правила за обмен. Правилата за обмен са обикновен xml файл, описващ структурата, в която ще се качват данните от информационната сигурност. Обработката на услугата, която качва/изтегля данни, анализира правилата за обмен и извършва качването въз основа на тях. При зареждането протича обратният процес.

Конфигурацията “CD” е вид визуален конструктор, с помощта на който разработчикът създава правила за обмен. Не знае как да изтегля данни. За това е отговорна допълнителна обработка на външна услуга, включена в пакета за разпространение на CD. Има няколко от тях (XX в името на файла е номерът на версията на платформата):

  • MDXXExp.epf- обработката ви позволява да качите описание на структурата на информационната база в xml файл. Описанието на структурата се зарежда в CD за допълнителен анализ и създаване на правила за обмен.
  • V8ExchanXX.epf- качва/изтегля данни от информационната база в съответствие с правилата за обмен. В повечето типични конфигурации обработката е налице извън кутията (вижте елемента от менюто „Услуга“). Обработката е универсална и не е обвързана с конкретни конфигурации/правила.

Добре, сега, въз основа на всичко по-горе, нека дефинираме етапите на разработване на нова реализация:

  1. Дефиниране на задачата. Необходимо е ясно да се разбере какви данни трябва да се прехвърлят (от кои конфигурационни обекти) и най-важното къде да се прехвърлят.
  2. Подготовка на описания на конфигурационни структури (Source/Sink) за последващо зареждане в CD. Проблемът се решава чрез обработка на услугата MDXXExp.epf.
  3. Зареждане на подготвени описания на структури в информационната сигурност.
  4. Създаване на правила за обмен с помощта на визуален CD инструмент.
  5. Извършване на качване/изтегляне съгласно създадените правила за преобразуване на данни с помощта на V8ExchanXX.epf обработка.
  6. Отстраняване на грешки в правилата за обмен (ако е необходимо).

Най-простото преобразуване

За демонстрацията ще ни трябват две разгърнати конфигурации. Реших да използвам опцията: „Управление на търговията“ 10-то издание и малко домашно написано решение. Задачата ще бъде прехвърляне на данни от стандартната "UT" конфигурация. За краткост нека наречем самостоятелно написаното решение „Мивка“, а търговското управление „Източник“. Нека започнем да решаваме проблема, като прехвърлим елементи от директорията „Номенклатура“.

Първо, нека да разгледаме схемата за преобразуване на данни и да прочетете отново списъка с действия, които трябва да се извършат. След това стартираме конфигурацията „Източник“ и отваряме обработката на услугата MD82Exp.epf в нея.

Интерфейсът за обработка няма изобилие от настройки. Потребителят трябва само да посочи типовете обекти с метаданни, които няма да бъдат включени в описанието на структурата. В повечето случаи тези настройки не трябва да се променят, т.к Няма особен смисъл от разтоварващи движения с помощта на регистри за натрупване (като пример).

По-правилно е да формирате движението, докато държите документи в приемника. Всички движения ще се извършват от самия документ след прехвърлянето. Вторият аргумент в защита на настройките по подразбиране е намаляването на размера на файла при качване.

Някои документи (особено в стандартни конфигурации) генерират движения в множество регистри. Разтоварването на всички тези неща ще направи получения XML файл твърде голям. Това може да усложни последващото транспортиране и зареждане в основата на приемника. Колкото по-голям е файлът с данни, толкова повече RAM ще е необходима за обработката му. По време на моята практика имах възможността да се сблъскам с неприлично големи файлове за качване. Такива файлове напълно отказаха да бъдат анализирани с помощта на стандартни инструменти.

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

Отворете компактдиска и изберете в главното меню „Директории“ -> „Конфигурации“. Директорията съхранява описания на структурите на всички конфигурации, които могат да се използват за създаване на реализации. Зареждаме описанието на конфигурацията веднъж и след това можем да го използваме многократно, за да създадем различни реализации.

В прозореца на директорията щракнете върху бутона „ Добавете” и в прозореца, който се показва, изберете файла, описващ конфигурацията. Поставете отметка в квадратчето „Зареждане в нова конфигурация“ и щракнете върху бутона „Зареждане“. Извършваме подобни действия с описанието на структурата на втората конфигурация.

Сега сте готови да създадете правила за обмен. В главното меню на компактдиска изберете “Директории” -> “Конверсии”. Добавете нов елемент. В прозореца за създаване на ново преобразуване трябва да посочите: конфигурацията на източника (изберете UT) и конфигурацията на местоназначението (изберете „Получател“). След това отворете раздела „Разширени“ и попълнете следните полета:

  • име на файл с правила за обмен - създадените правила за обмен ще бъдат запазени под това име. Можете да промените името на файла по всяко време, но е най-добре да го зададете сега. Това ще спести време в бъдеще. Нарекох правилата за демонстрационния пример: „rules-ut-to-priemnik.xml“.
  • name - името на преобразуването. Името може да бъде абсолютно всяко, аз се ограничих до „Демо. UT към приемника.

Това е всичко, щракнете върху „Ok“. Веднага пред нас се появява прозорец с молба да създадем автоматично всички правила. Съгласяването с такава примамлива оферта ще даде на капитана команда автоматично да анализира описанието на избраните конфигурации и независимо да генерира правила за обмен.

Нека сложим точката на "i" веднага. Съветникът няма да може да генерира нищо сериозно. Тази възможност обаче не трябва да се отхвърля. Ако е необходимо да се установи обмен между идентични конфигурации, тогава услугите на специалист ще бъдат много полезни. За нашия пример ръчният режим е за предпочитане.

Нека да разгледаме по-отблизо прозореца „Настройки на правилата за обмен“. Интерфейсът може да изглежда малко объркващ - голям брой раздели, натъпкани с контроли. Всъщност всичко не е толкова трудно, започвате да свиквате с тази лудост след няколко часа работа с приложението.

На този етап се интересуваме от два раздела: „Правила за преобразуване на обекти“ и „Правила за качване на данни“. Първо трябва да конфигурираме правилата за съвпадение, т.е. сравнете обекти от две конфигурации. На втория определете възможните обекти, които ще бъдат достъпни за потребителя за качване.

Във втората половина на раздела „Правила за преобразуване на обекти“ има допълнителен панел с два раздела: „Преобразуване на свойства“ и „ Преобразуване на стойности" Първият ще избере свойствата (подробностите) на избрания обект, а вторият е необходим за работа с предварително дефинирани стойности (например предварително дефинирани елементи на директория или елементи за изброяване).

Страхотно, сега нека създадем правила за преобразуване за директории. Можете да извършите това действие по два начина: използвайте съветника за синхронизиране на обекти (бутона „“) или ръчно добавете съответствие за всеки обект.

За да спестим място, ще използваме първата опция. В прозореца на съветника премахнете отметката от групата „ Документация” (интересуваме се само от директории) и разширете групата „ Справочници" Ние внимателно превъртаме списъка и разглеждаме имената на справочниците, които могат да бъдат сравнени.

В моя случай има три такива директории: Номенклатура, Организации и Складове. Има и директория, наречена Клиенти, която служи за същата цел като „ Контрагенти"от конфигурация" UT" Вярно, майсторът не можа да ги сравни поради различните им имена.

Можем сами да отстраним този проблем. Намираме в прозореца " Съвпадения на обекти" Справочник " клиенти“, а в колоната „Източник“ изберете директория „Контрагенти“. След това поставете отметка в квадратчето в колоната „Тип“ и щракнете върху бутона „ОК“.

Съветникът за синхронизиране на обекти ще предложи автоматично създаване на правила за конвертиране на свойствата на всички избрани обекти. Имотите ще се сравняват поименно и за нашата демонстрация това ще е напълно достатъчно, съгласни сме. Следващият въпрос ще бъде предложение за създаване на правила за качване. Да се ​​съгласим и с това.

Базата за правилата за обмен е готова. Избрахме обектите за синхронизация и правилата за конвертиране на свойства и правилата за качване бяха създадени автоматично. Нека запазим правилата за обмен във файл, след това отворете IB „Източник“ (в моя случай това е UT) и стартирайте обработка на услугата в него V8Exchan82.epf.

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

След като завършите процеса на качване на данни във файл, отидете на IB “ Приемник" В него отваряме и обработка V8Exchan82.epf, само този път отиваме в раздела „Зареждане на данни“. Изберете файла с данни и щракнете върху бутона „Изтегляне“. Това е всичко, данните са прехвърлени успешно.

Проблеми от реалния свят

Първото демо може да е подвеждащо. Всичко изглежда доста просто и логично. Всъщност това не е вярно. В реалната работа възникват проблеми, които са трудни или напълно невъзможни за решаване само с визуални средства (без програмиране).

За да не бъда разочарован от технологията, подготвих няколко задачи от реалния живот. Със сигурност ще ги срещнете по време на работа. Те не изглеждат толкова тривиални и ви карат да погледнете преобразуването на данни от нов ъгъл. Внимателно разгледайте представените примери и не се колебайте да ги използвате като фрагменти, когато решавате реални проблеми.

Задача No1. Попълнете липсващите данни

Да предположим, че трябва да прехвърлим директорията " Контрагенти" Получателят има подобна директория „Клиенти“ за тази цел. Напълно подходящ е за съхранение на данни, но има подпори “ Организация”, което ви позволява да разделите контрагентите по принадлежност към организацията. По подразбиране всички контрагенти трябва да принадлежат към текущата организация (това може да се получи от константата със същото име).

Има няколко решения на проблема. Ще разгледаме варианта за попълване на детайлите “ Организация„право в базата данни“ Приемник”, т.е. в момента на зареждане на данните. Текущата организация се съхранява в константа, следователно няма пречки за получаване на тази стойност. Нека отворим правилото за преобразуване на обект (наричано по-долу PKO) " клиенти” (щракнете двукратно върху обекта) и в съветника за настройка на правила отидете на секцията „Манипулатори на събития”. В списъка с манипулатори ще намерим „ След изтегляне”.

Нека опишем кода за получаване на текущата организация и след това да я присвоим на детайлите. По време на задействане на манипулатора „След зареждане“ обектът ще бъде напълно оформен, но все още не е записан в базата данни. Никой не ни забранява да го променяме по свое усмотрение:

Ако НЕ е Object.ThisGroup, тогава Object.Organization = Constants.CurrentOrganization.Get(); endIf;

Преди да попълните подробностите " Организация"Необходимо е да се провери стойността на атрибута " Тази група" За справочника " клиенти„Йерархичната функция е зададена, така че е необходима проверка за групата. Попълнете всички подробности по подобен начин. Не забравяйте да прочетете помощта за други опции за обработка " След зареждане" Например, сред тях има параметърът „ Отказ" Ако му присвоите стойността „Истина“, тогава обектът няма да бъде записан в базата данни. Така става възможно да се ограничат обектите, които могат да бъдат записани по време на зареждане.

Задача No2. Данни за информационен регистър

В директорията „ Контрагенти„UT конфигурации, налични са подробности“ Купувач" И " Доставчик" И двата детайла са от тип „ Булева стойност” и се използват за определяне на вида на контрагента. В IB “ Приемник“, в директорията „ клиенти„Няма подобни подробности, но има регистър на информацията“ Видове клиенти" Той изпълнява подобна функция и може да съхранява множество атрибути за един клиент. Нашата задача е да прехвърлим стойностите на детайлите в отделни записи в информационния регистър.

За съжаление и тук само визуалните средства не могат да се справят. Да започнем с малко, да създадем нов софтуер за информационния регистър “ Видове клиенти" Не цитирайте нищо като източник. Избягвайте автоматичното създаване на правила за качване.

Следващата стъпка е да създадете правила за качване. Отидете в съответния раздел и щракнете върху „ Добавете" В прозореца за добавяне на правила за качване попълнете:

  • Метод на вземане на проби. Промяна на „Произволен алгоритъм“;
  • Правило за преобразуване. Изберете информационен регистър „Видове клиенти”;
  • Код (име) на правилото. Запишете го като „Разтоварване на типове клиенти“;

Сега трябва да напишете код, за да изберете данни за качване. Параметърът „ Извадка от данни" Можем да поставим колекция с подготвен набор от данни в нея. параметър " Извадка от данни” може да приема различни стойности - резултат от заявка, селекция, колекции от стойности и др. Инициализираме го като таблица със стойности с две колони: клиент и тип клиент.

По-долу е кодът за манипулатора на събития " Преди обработка" Той инициализира параметъра „ Извадка от данни”, последвано от попълване на данни от указателя “ Контрагенти" Тук трябва да обърнете внимание на попълването на колоната „ Тип клиент" В “UT” нашите атрибути са от тип “Boolean”, а получателят е изброяване.

На този етап не можем да ги конвертираме в необходимия тип (няма го в UT), така че засега ще ги оставим под формата на низове. Не е нужно да правите това, но веднага искам да покажа как да прехвърляте към липсващ тип в източника.

DataFetch = New ValueTable(); DataSelection.Columns.Add("Клиент"); DataSelection.Columns.Add("ClientType"); SelectingDataFromDirectory = Directories.Accounts.Select(); Докато SelectingDataFromDirectory.Next() Loop If SelectingDataFromDirectory.ThisGroup Then Continue; endIf; If Data Selection From Directory.Buyer Then NewRow = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewRow.ClientType = "Клиент"; endIf; Ако DataFetchFromDirectory.Supplier Then NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Доставчик"; endIf; EndCycle;

Нека запазим правилото за качване на данни и се върнем към раздела „ Правила за преобразуване на обекти" Да добавим за информационен регистър “ Видове клиенти” правила за преобразуване на свойства: клиент и тип клиент. Ще оставим източника празен и в манипулатора на събитието „Преди разтоварване“ ще напишем:

//За свойството „Клиент“ Стойност = Source.Client; //За свойството “ClientType” If Source.Client = "Buyer" Then Expression = "Enumerations.ClientTypes.Buyer" ElseIf Source.Client = "Supplier" Then Expression = "Enumerations.ClientTypes.Supplier"; endIf;

В списъка детайлите се попълват въз основа на избраната извадка от данни. Просто предаваме клиента като връзка и записваме типа клиент в параметъра „ Изразяване" Данните на този параметър ще бъдат интерпретирани в приемника и когато бъдат изпълнени, пропът ще бъде попълнен с правилната стойност от изброяването.

Това е всичко, правилата за обмен са готови.Разглежданият пример се оказа доста универсален. Подобен подход често се използва при мигриране на данни от конфигурации, създадени на платформата 7.7. Ярък пример за това е прехвърлянето на периодични детайли.

Задача No3. Трикове с части от маса

Често срещате задачи, които изискват публикуване на редове от една секция на таблицата в няколко. Например в първоначалната конфигурация услугите и стоките се регистрират в една таблична част, а в приемника съхранението на тези обекти е разделено. Отново, проблемът не може да бъде решен с визуални средства. Тук е удобно да вземем за основа решението на втората задача.

Създаваме правило за разтоварване на данни, задаваме произволен алгоритъм и в манипулатора „Преди разтоварване“ пишем заявка за получаване на данни от табличната част.

За да спестя място, няма да предоставя кода (винаги можете да се обърнете към източниците) на заявката - в нея няма нищо необичайно. Сортираме получената селекция и поставяме сортираните резултати във вече познатия параметър „ Извадка от данни" Отново е удобно да използвате таблица със стойности като колекция:

DataFetch = New ValueTable(); //Тук ще има друга част от таблицата Data Selection.Columns.Add(“Products”); //Тук ще има и таблична част Data Selection.Columns.Add(“Services”); SelectionData.Columns.Add(“Връзка”);

Задача No4. Прехвърляне на данни към операция

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

В конфигурацията „ BP„има универсален документ“ Операция” и е идеален за оформяне на повече телове. Има само един проблем - документът е направен хитро и данните не могат да бъдат прехвърлени в него толкова лесно.

Ще намерите пример за такова преобразуване в изходния код на статията. Количеството код се оказа доста голямо, така че няма смисъл да го публикуваме заедно със статията. Нека само да кажа, че качването отново използва произволен алгоритъм в правилата за качване на данни.

Задача No5. Синхронизиране на данни в множество детайли

Вече разгледахме няколко примера, но все още не сме говорили за синхронизиране на обекти по време на миграция. Нека си представим, че трябва да прехвърлим контрагенти и някои от тях вероятно са в базата данни на получателя. Как да прехвърляте данни и да предотвратите появата на дубликати? В тази връзка CD предлага няколко начина за синхронизиране на прехвърлени обекти.

Първият е чрез уникален идентификатор. Много обекти имат уникален идентификатор, който гарантира уникалност в таблицата. Например в директорията „ Контрагенти” не може да има два елемента с еднакви идентификатори. CD прави изчисления за това и за всички създадени PCO, търсенето по идентификатор веднага се активира по подразбиране. По време на създаването на PCO трябва да обърнете внимание на изображението на лупа до името на обекта.

Синхронизирането с помощта на уникален идентификатор е надежден метод, но не винаги е подходящ. При обединяване на директории “ Контрагенти” (от няколко различни системи) няма да помогне много.

В такива случаи е по-правилно да се синхронизират обекти по няколко критерия. По-правилно е да търсите контрагенти по INN, KPP, име или да разделите търсенето на няколко етапа.

Преобразуването на данни не ограничава разработчика при определянето на критериите за търсене. Нека да разгледаме един абстрактен пример. Да предположим, че трябва да синхронизираме директории " Контрагенти” от различни информационни бази. Нека подготвим PKO и в настройките на правилата за преобразуване на обект, проверете „ Продължете да търсите в полетата за търсене, ако обектът приемник не е намерен по идентификатор" С това действие веднага дефинирахме два критерия за търсене - чрез уникален идентификатор и потребителски полета.

Имаме право сами да избираме полетата. Като проверите TIN, KPP и Име, веднага ще посочим няколко критерия за търсене. Удобно? Съвсем, но това отново не е достатъчно. Ами ако искаме да променим критериите за търсене? Например, първо търсим комбинацията TIN+KPP и ако не намерим нищо, започваме да опитваме късмета си с името.

Такъв алгоритъм е напълно способен да бъде приложен. В манипулатора на събития „ Полета за търсене” можем да посочим до 10 критерия за търсене и за всеки от тях да дефинираме собствен състав от полета за търсене:

Ако SearchOptionNumber = 1 тогава SearchPropertyNameString = „TIN, KPP“; OtherwiseIfSearchOptionNumber = 2 ThenSearchPropertyNameString = „Име“; endIf;

Винаги има няколко решения

Всяка задача има няколко решения и прехвърлянето на данни между различни конфигурации не е изключение. Всеки разработчик има право да избере свое собствено решение, но ако постоянно трябва да разработвате сложни миграции на данни, тогава силно препоръчвам да обърнете внимание на „“. Може да се наложи да инвестирате ресурси (време) в обучение в началото, но те ще се отплатят повече от първия повече или по-малко сериозен проект.

Според мен компанията 1C несправедливо игнорира темата за използването на преобразуване на данни. По време на цялото съществуване на технологията е публикувана само една книга за нея: „1C: Enterprise 8. Преобразуване на данни: обмен между приложни решения.“ Книгата е доста стара (2008 г.), но все пак е препоръчително да се запознаете с нея.

Познаването на платформите все още е необходимо

"е универсален инструмент, но ако планирате да го използвате за създаване на миграции на данни от конфигурации, разработени за платформата 1C:Enterprise 7.7, тогава ще трябва да отделите време, за да опознаете вградения език. Синтаксисът и идеологията на езика са много различни, така че ще трябва да отделите време за учене. В противен случай принципът остава същият.