Конвертирање на размена на податоци помеѓу апликативни решенија. Видео инструкција за конвертирање

1. Вовед.

2. Што ви треба: 1C конфигурација: Конверзија на податоци 2. * и обработка од пакетот. За пример на задачи, ги земаме конфигурациите 1C: Trade Management 11 и 1C: BP 3. *.

Значи, за да развиете правила за поставување податоци на 1C, ќе ви треба конфигурација 1C: Конверзија на објекти 2, како и обработка вклучена во пакетот.

На пример, веќе ја распоредивме базата за конверзија и ја лансиравме.

Ќе напишеме развој на правила за размена помеѓу конфигурацијата 1C: Trade Management 11 и 1C: Enterprise Accounting 3 (правила за размена на UT / BUH).

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: Trade Management 11. *, 1C BP 3, 1C : ERP 2. * и слично. И соодветно V8Exchan83.epf - за конфигурации на редовни форми.

4. Поставување на структурата на конфигурациските метаподатоци 1C: Trade Management 11.3 и 1C: Enterprise Accounting 3.0. *

Да почнеме со растоварување на структурата на метаподатоци од конфигурацијата 1C: Enterprise Accounting 3.
Отворете ја обработката MD83Exp.epf

Во формуларот за обработка има дополнителни поставки, каде што можеме да ја овозможиме или оневозможиме опцијата за растоварување на регистри и движења во 1C. Исто така, постои избор каде ќе се одвива истоварот: на серверот 1C или „на клиентот“. Наведете го името на датотеката каде што ќе се истовари структурата на податоци. Слично на тоа, ние ја растоваруваме структурата на конфигурациските метаподатоци Trade Management 11.

Сега треба да ја вчитате конфигурацијата во базата на податоци за конверзија. До оваа ставка може да се дојде и од списокот со конфигурации и од списокот со конверзии. Само да се подигнеме од работната површина:

Во полето за дијалог, вчитајте ја структурата на BP:

И слично - структурата на Одделот за трговија.

Кога ќе заврши преземањето, ќе се појави дијалог-кутија каде што можете да наведете име погодно за вас.

6. Создавање правила за конверзија во 1C на конкретен пример на задачата.

Следно, одете во „Поставување правила на објектот“, каде што создаваме нова поставка.
Во дијалог прозорецот за креирање на конверзија, изберете ја конфигурацијата „извор“ и конфигурацијата „дестинација“ (која претходно сте ја вчитале) и кликнете OK.

Бидејќи во оваа статија планирав да ја прикажам креацијата „од нула“ и „без ѓубре“, ве потсетувам дека ние автоматски не создаваме ништо. Нема прототипови.

Ние нема да направиме ништо во овој дијалог прозорец, само кликнете - "Затвори".

Ајде да создадеме правила за растоварување не еден документ во еден, туку еден тип во друг, на пример, документот Продажба на стоки и услуги од UT 11 со потребните директориуми до документот Прием на стоки и услуги во БП 3.

Значи, создаваме нов PKO (правило за претворање на објекти во 1C)

Изберете го изворот Реализација на стоки на услуги и примачот на прием на стоки на услуги и кликнете OK.
Во овој случај, ќе се појави дијалог-кутија, каде што повторно го одбиваме автоматското создавање на PKC (Правила за конверзија на имот). Следно, ги избираме само потребните.

Но, на предлогот да се создаде PVD (правила за поставување податоци), ние одговараме „Да“.

Се создаваат VDP, што ќе се рефлектира во обработката на универзалната XML размена за избор:

Ќе се креираат и правила за конверзија на податоци со правила за конверзија на празни својства.

Покрај тоа, јасно е дека стандардно се предлага да се бара FSP со внатрешниот идентификатор на објектот. Ова е означено со лупа во близина на PKO. Ние ќе направиме сопствено пребарување и ќе го направиме според бројот на документот и датумот на почетокот на денот.

Отстранување на пребарувањето за UIO:

Сега да почнеме да ги совпаѓаме потребните својства (реквизити) на објектот. За да го направите ова, кликнете на „Синхронизација на имот“ (ознака „1“ на екранот). Го отстрануваме рекурзивното креирање правила („2“). Ги отстрануваме сите означени детали („3“). И ние самите ќе избереме што ни треба.

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

Вашето внимание го обрнувам на фактот дека ПКС на другата страна ќе го направиме во организацијата, а организацијата во договорна страна, а исто така ќе споредиме некои детали што не се совпаѓаат по име, на пример, „валута“ и „документот валута“.

Каде што гледаме дека сè уште нема правила за конверзија.

Ајде да почнеме со детали за да поминеме и да опишеме. Прво, го поставивме пребарувањето за документот како што напишав претходно, го растовараме и бараме документот на почетокот на датумот и ќе го смениме нумерирањето. Ќе ги замениме првите три знаци со нашиот префикс „UTB“. И бидејќи во BP и UT нумерирањето е по 11 знаци, правиме композитен број: нашиот префикс и 8 знаци од изворот. Пример од екранот подолу.

Секогаш растоваруваме документи кои не се извршени и без движење. Претпоставуваме дека документите ќе се чуваат во ресиверот по проверка од страна на корисникот.

За да го направите ова, PCS, откако постави како не се држи, 0 или 1, се користи како бул.

Користејќи ја валутата како пример, создаваме правило за конвертирање на објект за PCS. Во исто време, сметаме дека има валути и во двете основи, и тие мора да се синхронизираат со код. Затоа, нема да ги креираме сите PCS во CSP на валути, туку само ќе го додадеме кодот за пребарување. Оние. од предлогот за креирање на ПКС за објектот – одбиваме.

Создаденото Правило за конверзија беше заменето во PQS на документот за SCS. И самото стандардно правило е понудено од единствен идентификатор. Го поправаме, пребаруваме во кодот и го поставуваме имотот за да не создадеме нов објект.

Како резултат, ја добиваме опцијата:

Понатаму, по аналогија, создаваме за останатите детали за PKO и PKS. Покрај тоа, го поставивме пребарувањето за организација по договорна страна и обратно по TIN. Вака изгледа со минимални детали (можете да додадете доколку е потребно).

За PKO договори на договорни страни, бараме договорна страна на PKS, име и сопственик.

Ајде да видиме како да ја наведете саканата вредност во типот на набројување во PCS. На пример, атрибутот „Тип на операција“. Овде можете да користите различни услови и заменски вредности. На пример, ни треба „тип на работа“ секогаш да се растоварува „Стока“, во овој случај доволно е да ја напишете саканата вредност во „челото“ како низа.

Следното покажува како се поставува без потешкотии и во повеќето случаи PKS за множество на порамнување, стапка на порамнување, сметки.

За номенклатурата PKO, го оставаме пребарувањето по внатрешен единствен идентификатор. Но, ќе обрнам внимание на тоа како можете да ја редефинирате вашата група. На пример, се согласуваме дека нова номенклатура ќе биде истоварена од конфигурацијата 1C: Trade Management 11, но неопходно е номенклатурата да се собере во одредена група „Нашата група“.

За да ја спроведеме оваа задача, создаваме уште една PKO. Да го наречеме „Родител на номенклатура“, што ќе го означиме во PDN на родителот во правилото за конверзија.

Поставивме две пребарувања: по име, каде што името на нашата група е тврдокодирано и задолжителното својство на атрибутот „ThisGroup“ е точно.

Бидејќи решивме целата номенклатура да падне во нашата група, нема потреба да се растовараат групите од UT 11 при истовар. дека не е неопходно да се растовараат групите „Неуспех = Извор“. Оваа група;“.

Во DRP (правила за подигање податоци) Имплементација на стоки и услуги, ќе додадеме филтер за да не се прикачат документите означени за бришење. За да го направите ова, во PDP во управувачите на настани „Пред да се растовариме“ ќе го напишеме филтерот „Одбивање = Object.DeletionMark;“.

Зачувајте ги развиените правила во датотека.

7. Сумирање: Поставување и преземање на податоци со користење на развиените правила за размена на податоци.

Отвораме во 1C: Trade Management 11 обработката „Универзална размена на податоци во XML формат“ V8Exchan83.epf.

Растоварот помина, сега со истата обработка се вчитуваме во 1C: Enterprise Accounting 3.

Преземањето е завршено. Ајде да провериме дали е вчитан. Значи, документот е вчитан, како што сакавме - ја имаме Организацијата вчитана во другата страна, а договорната страна во организацијата. Сите сметки се преземаат и инсталираат. Го добивме бројот на документот со нашиот префикс и на почетокот на денот. Сите податоци кои се регистрирани се пополнети.

Го проверуваме вчитувањето на номенклатурата. Гледаме дека се испадна како што планиравме.

Ги создадовме и пополнивме деталите како што сакавме. Има многу суптилности во конверзијата и некои едноставни, но неопходни работи кои помагаат точно да се напише конверзијата. И ова ви овозможува да ги минимизирате грешките, да не ги расипувате постоечките податоци и да се ослободите од непотребното ѓубре. Ова е еден од наједноставните примери. Можете исто така да направите конверзија на еден објект во многу, или обратно, многу - во еден.

Сега има конверзија на податоци 3, решава други проблеми. Затоа, потребна е и конверзија 2. Среќно на сите во учењето и совладувањето.

Се разбира, ако сте програмер и ова е вашата главна работа, можете сами да се обидете да ја напишете конверзијата. Но, ако не, тогаш треба да го цените вашето време во вашето поле на активност и да побарате од професионалци да ја завршат оваа задача.

1C: Enterprise 8. Конверзија на податоци: размена на податоци помеѓу апликативни решенија (со апликација на CD-ROM) (член 4601546049094)

„1C: Enterprise“ е универзален систем за автоматизирање на активностите на претпријатието и може да се користи за решавање на различни проблеми со управувањето и сметководството. Во моментов, на платформата 1C:Enterprise се развиени голем број стандардни и специјализирани решенија, кои можат да работат во тесна интеграција со други решенија, како на оваа платформа, така и со софтвер од трети страни.

Од големо значење за ефективна работа е способноста да се организира размена помеѓу различни информациски системи. Платформата 1C: Enterprise обезбедува различни алатки за размена на податоци и интеграција на апликативни решенија.

Книгата детално ја прикажува размената на податоци во XML формат, што денес е општо прифатено средство за претставување на податоци. Опишани се процедурите за развивање правила, чија примена ќе обезбеди пренос на информации од еден информативен систем на друг, вклучително и размена на податоци помеѓу типични конфигурации 1C: Enterprise.

Книгата е придружена со ЦД што содржи демо-инфобази со примери на правила за размена и конфигурација „1C:Enterprise. Data Conversion“.

Внимание! Во првото издание, на крајот од книгата беше дозволен технички брак. Поправените страници можат да бидат

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

Купи:

Контактирајте со партнерот 1C што ја опслужува вашата организација и нарачајте му кажете му го кодот доделен на книгата (прикажано во табелата подолу). Книгата можете да ја купите и од други. партнери на компанијата „1C“.

• во онлајн продавницата „1C-Interest“ (испорака на книги по курир, Руска пошта, DHL, EMS)
• во книжарниците во вашиот град

Исто така види:

цена на книгата

структура на книгата

Вовед

Поглавје 1. Општи принципи на поставување правила

Поглавје 2 Користење правила

Поглавје 3 Автоматско генерирање правила

Поглавје 4 Структура на правилата

Поглавје 5

Поглавје 6 Ракувачи со настани

• Опции
• Ракувачи за „конверзија“.
• Ракувачи за „Правила за поставување податоци“.
• Ракувачи со „Правила за конверзија на објекти“.
• Ракувачи со „Правила за конверзија на група на имот“.
• Ракувачи со „Правила за конверзија на имот“.

Поглавје 7 Полиња за пребарување

Поглавје 8. Правила за чистење податоци

Поглавје 9 Алгоритми и прашања

Поглавје 10. Типични примери на правила. Заобиколни решенија

• Вкупна конверзија
• Конверзија на директориум
• Конверзија на документ
• Конверзија на регистарот на информации
• Сметковна конверзија
• Конвертирање на план од карактеристични типови
• Конверзија на план за тип на пресметка
• Постојана конверзија 1C: Enterprise 7.7
• Конверзија на сметководствени трансакции 1C: Enterprise 7.7

Поглавје 11 Правила за оптимизирање

• Правила за поставување податоци
• Правила за конверзија на објекти
• Се обработува „Универзална XML размена на податоци“

Конверзија на податоци 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-датотека со опис на структурата во која ќе се подигнат податоците од IB. Услугата за обработка која врши подигање/симнување на податоци ги анализира правилата за размена и го врши подигнувањето врз основа на нив. За време на преземањето, се случува обратен процес.

Конфигурацијата „KD“ е еден вид визуелен конструктор со кој развивачот создава правила за размена. Не знае како да прикачува податоци. За ова е одговорна дополнителна надворешна обработка на услуги вклучена во комплетот за дистрибуција на ЦД. Има неколку од нив (XX во името на датотеката е бројот на верзијата на платформата):

• MDXXExp.epf- обработката ви овозможува да испратите опис на структурата на инфобазата во датотека xml. Описот на структурата е вчитан во ЦД-то за понатамошна анализа и креирање правила за размена.
• V8ExchanXX.epf- поставува/презема податоци од инфобазата во согласност со правилата за размена. Во повеќето типични конфигурации, обработката е достапна надвор од кутијата (видете ја ставката од менито „Услуга“). Обработката е универзална и не е поврзана со никакви специфични конфигурации/правила.

Добро, сега врз основа на сето горенаведено, ајде да ги дефинираме фазите на развој на нова конверзија:

1. Дефиниција на задача. Неопходно е јасно да се разбере кои податоци треба да се пренесат (од кои објекти на конфигурацијата) и што е најважно, каде да се пренесат.
2. Подготовка на опис на конфигурациските структури (Извор/приемник) за последователно вчитување во ЦД-то. Задачата се решава со сервисна обработка MDXXExp.epf.
3. Вчитување на подготвени описи на структури во IS.
4. Креирање правила за размена со помош на визуелни средства на ЦД.
5. Поставување/симнување според креираните правила за конверзија на податоци со користење на обработката V8ExchanXX.epf.
6. Правила за размена на дебагирање (ако е потребно).

Наједноставна конверзија

За демонстрација, потребни ни се две распоредени конфигурации. Решив да застанам на опцијата: „Трговско управување“ 10-то издание и мало самостојно напишано решение. Задачата ќе биде да се префрлат податоци од типичната UT конфигурација. За краткост, ќе го наречеме самонапишаното решение „Приемник“, а управувањето со трговијата „Извор“. Да почнеме да го решаваме проблемот со пренесување на елементите од директориумот "Номенклатура".

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

Интерфејсот за обработка не свети со изобилство на поставки. Корисникот треба само да ги наведе типовите на објекти на метаподатоци кои нема да спаѓаат во описот на структурата. Во повеќето случаи, овие поставки не треба да се менуваат, бидејќи нема посебна поента во движењата на растоварање во акумулационите регистри (како пример).

Поправилно е да се формира движењето при чување на документи во ресиверот. Сите движења ќе бидат направени од самиот документ по трансферот. Вториот аргумент во одбрана на стандардните поставки е да се намали големината на поставената датотека.

Некои документи (особено во типични конфигурации) формираат движења во повеќе регистри. Растоварувањето на целата оваа економичност ќе ја направи добиената XML-датотека преголема. Ова може да го отежне последователниот транспорт и вчитување во базата на приемникот. Колку е поголема датотеката со податоци, толку повеќе RAM е потребна за нејзина обработка. За време на мојата пракса, се случи да наидам на непристојно големи датотеки за испраќање. Таквите датотеки целосно одбија да бидат анализирани со стандардни средства.

Значи, ги оставаме сите стандардни поставки и го поставуваме описот на конфигурацијата во датотека. Истата постапка ја повторуваме и за втората основа.

Отворете го ЦД-то и изберете од главното мени „Директориуми“ -> „Конфигурации“. Директориумот зачувува описи на структурите на сите конфигурации што може да се користат за креирање конверзии. Го вчитуваме описот на конфигурацијата еднаш, а потоа можеме да го користиме постојано за да креираме различни конверзии.

Во прозорецот на директориумот, притиснете го копчето „ Додадете” и во прозорецот што се појавува, изберете датотека со опис на конфигурацијата. Проверете го полето „Подигни во нова конфигурација“ и кликнете на копчето „Изврши поставување“. Ние извршуваме слични дејства со описот на структурата на втората конфигурација.

Сега сè е подготвено за креирање на правилата за размена. Во главното мени на ЦД-то, изберете „Референци“ -> „Конверзии“. Додавање нов елемент. Во прозорецот за креирање нова конверзија, треба да наведете: конфигурација на изворот (изберете UT) и конфигурација на приемникот (изберете "Приемник"). Следно, отворете го табулаторот „Напредно“ и пополнете ги следните полиња:

• правила за размена име на датотека - креираните правила за размена ќе бидат зачувани под ова име. Името на датотеката може да се смени во секое време, но најдобро е да го поставите сега. Ова ќе заштеди време во иднина. Правилата за демото ги именував: „rules-ut-to-priemnik.xml“.
• име - името на конверзијата. Името може да биде апсолутно се, се ограничив на „Демо. UT до ресиверот“.

Тоа е сè, кликнете „Во ред“. Веднаш, пред нас се појавува прозорец кој бара автоматски да ги креираме сите правила. Согласувањето со таква примамлива понуда ќе му даде на господарот команда автоматски да го анализира описот на избраните конфигурации и самостојно да генерира правила за размена.

Ајде веднаш да ставиме точка на „и“. Господарот нема да може да генерира ништо сериозно. Сепак, оваа можност не треба да се намалува. Ако треба да воспоставите размена помеѓу идентични конфигурации, тогаш услугите на волшебникот ќе ви бидат многу корисни. На нашиот пример, се претпочита рачниот режим.

Да го разгледаме подетално прозорецот „Поставки за правилата за размена“. Интерфејсот може да изгледа малку збунувачки - голем број јазичиња исполнети со контроли. Всушност, сè не е толку тешко, почнувате да се навикнувате на ова лудило по неколку часа работа со апликацијата.

Во оваа фаза, ние сме заинтересирани за две јазичиња: „Правила за конверзија на објекти“ и „Правила за поставување податоци“. На првиот, треба да поставиме правила за совпаѓање, т.е. споредете објекти од две конфигурации. На вториот, определете ги можните објекти што ќе му бидат достапни на корисникот за истовар.

Во втората половина од табулаторот „Правила за конверзија на објекти“ има дополнителен панел со две јазичиња: „Конверзија на имот“ и „ Конверзија на вредност“. Првиот ќе ги избере својствата (реквизитите) на избраниот објект, а вториот е неопходен за работа со однапред дефинирани вредности (на пример, предефинирани елементи на речник или елементи за набројување).

Одлично, сега ајде да создадеме правила за конверзија за директориуми. Можете да го извршите ова дејство на два начина: користете го волшебникот за синхронизација на објекти (кликнете на „“) или додавајте совпаѓања за секој објект рачно.

За да заштедиме простор, ќе ја искористиме првата опција. Во прозорецот на волшебникот, отштиклирајте го полето „ Документите” (ние сме заинтересирани само за директориуми) и проширете ја групата “ Референтни книги“. Внимателно се движиме низ списокот и ги разгледуваме имињата на директориумите што може да се споредат.

Во мојот случај, има три такви директориуми: Номенклатура, Организации и Магацини. Исто така, постои директориум за клиенти што го извршува истото семантичко оптоварување како „ Контрастрани„од конфигурација“ UT“. Точно, мајсторот не можеше да ги спореди поради нивните одлични имиња.

Овој дефект можеме сами да го поправиме. Најдете во прозорецот Мапирања на објекти»прирачник « Клиенти“, а во колоната „Извор“ изберете ја референтната книга „Договорни страни“. Потоа проверете го полето во колоната „Тип“ и кликнете на копчето „Ок“.

Волшебникот за синхронизација на објекти ќе ве поттикне автоматски да креирате правила за конвертирање на својствата на сите избрани објекти. Својствата ќе се поклопат по име, а за нашата демонстрација тоа ќе биде сосема доволно, се согласуваме. Следното прашање ќе биде предлог за креирање правила за прикачување. Ајде да се согласиме со тоа.

Основата за правилата за размена е подготвена. Ги избравме објектите за синхронизација, а правилата за конвертирање на својствата и правилата за прикачување беа креирани автоматски. Ајде да ги зачуваме правилата за размена во датотека, потоа да го отвориме IB „Извор“ (во мојот случај, тоа е UT) и да започнеме со обработка на услугата во неа V8Exchan82.epf.

Прво на сите, во прозорецот за обработка, изберете ги правилата за размена што ги создадовме. На прашањето за вчитување на правилата одговараме потврдно. Обработката ќе ги анализира правилата за размена и ќе изгради истоимено дрво за објекти достапни за истовар. За ова дрво, можеме да поставиме секакви филтри или да размениме јазли, со промена на кои треба да избереме податоци. Сакаме да ги поставиме апсолутно сите податоци, така што нема потреба да инсталираме филтри.

Откако ќе заврши процесот на поставување податоци во датотека, одете на IB " Приемник“. Во него отвораме и обработка V8Exchan82.epf, само овој пат одиме на табулаторот „Вчитување податоци“. Изберете ја датотеката со податоци и кликнете на копчето „Подигни“. Сè, податоците беа успешно пренесени.

Задачи од реалниот свет

Првото демо може да биде погрешно. Сè изгледа прилично едноставно и логично. Всушност, ова не е вистина. Во вистинската работа се јавуваат задачи кои се тешки или целосно невозможни да се решат само со помош на визуелни средства (без програмирање).

За да не бидам разочаран од технологијата, подготвив неколку реални задачи. На работа сигурно ќе наидете на нив. Тие не изгледаат толку тривијални и ве тераат да гледате на конверзијата на податоците од нов агол. Внимателно разгледајте ги презентираните примери и слободно користете ги како фрагменти кога решавате вистински проблеми.

Задача број 1. Пополнете ги деталите што недостасуваат

Да претпоставиме дека треба да го пренесеме директориумот“ Контрастрани“. Приемникот има слична референтна книга „Клиенти“ за ова. Целосно е погоден за складирање податоци, но има реквизити “ Организација“, овозможувајќи ви да ги одвоите договорните страни со припадност на организацијата. Стандардно, сите договорни страни мора да припаѓаат на тековната организација (може да се добие од константата со истото име).

Постојат неколку решенија за проблемот. Ќе ја разгледаме опцијата за пополнување на реквизитите “ Организација„Веднаш во основата“ Приемник“, т.е. во моментот на вчитување на податоците. Тековната организација се чува во константа, така што нема бариера за добивање на оваа вредност. Ајде да го отвориме правилото за конверзија на објекти (во натамошниот текст како FRP) “ Клиенти” (двоен клик на објектот) и во волшебникот за поставување правила, одете во делот „Оддржувачи на настани“. Во списокот на ракувачи наоѓаме „ По вчитувањето”.

Ајде да го опишеме кодот за добивање на тековната организација со последователно доделување на атрибутот. Во моментот кога ќе се активира управувачот „По вчитување“, објектот ќе биде целосно формиран, но сè уште не е запишан во базата на податоци. Никој не ни забранува да го промениме по наша дискреција:

Ако НЕ Објект.ThisGroup Потоа Object.Organization = Constants.CurrentOrganization.Get(); EndIf;

Пред да ги пополните реквизитите“ Организација» потребно е да се провери вредноста на атрибутот « Оваа група“. За водич“ Клиенти» хиерархиското знаменце е поставено, затоа е неопходно да се провери дали има група. Слично на тоа, се врши пополнување на какви било детали. Не заборавајте да ја прочитате помошта за други опции за ракувачот " AfterLoading“. На пример, меѓу нив има параметар " Одбивање“. Ако му се додели вредноста „True“, тогаш објектот нема да биде запишан во базата на податоци. Така, станува возможно да се ограничат објектите за пишување во моментот на вчитување.

Задача број 2. Детали во информативниот регистар

Во прирачникот“ Контрастрани„УТ конфигурација, има детали“ Купувач"и" Провајдер“. Двата реквизити се од типот „ булови” и се користат за одредување на типот на договорна страна. во ИБ“ Приемник“, во референтната книга „ Клиенти„Нема слични детали, но има регистар на информации“ Видови клиенти“. Врши слична функција и може да складира повеќе ознаки за еден клиент. Наша задача е да ги пренесеме вредностите на деталите во посебни записи на информативниот регистар.

За жал, визуелните средства сами не можат да се справат и овде. Ајде да започнеме со мали димензии, да создадеме нов PCO за регистарот за информации " Видови клиенти“. Не наведувајте ништо како извор. Одбијте автоматско креирање правила за прикачување.

Следниот чекор е да ги креирате правилата за прикачување. Одете на соодветното јазиче и кликнете на " Додадете“. Во прозорецот за додавање правила за прикачување, пополнете:

• метод на земање примероци. Промени во „Арбитрарен алгоритам“;
• правило за конверзија. Изберете го регистарот за информации „Типови клиенти“;
• Код (име) на правилото. Ние го пишуваме како „Прикачување видови на клиенти“;

Сега треба да го напишете кодот за избор на податоци за поставување. Тука е параметарот „ Земање примероци на податоци“. Во него можеме да поставиме збирка со подготвен сет на податоци. параметар " Земање примероци на податоци” може да земе различни вредности - резултат на барање, избор, збирки вредности итн. Ја иницијализираме како табела со вредности со две колони: клиент и тип на клиент.

Подолу е кодот на управувачот со настани “ Пред обработка“. Го иницијализира параметарот „ Земање примероци на податоци“ проследено со пополнување податоци од директориумот “ Контрастрани“. Тука вреди да се обрне внимание на пополнување на колоната “ Тип на клиент“. Во „UT“ имаме карактеристики од типот „Boolean“, а кај примачот набројување.

Во оваа фаза не можеме да ги доведеме до саканиот тип (не е во UT), така што засега ќе го оставиме во форма на жици. Не мора да го правите ова, но веднаш сакам да покажам како да фрлам на тип што недостасува во изворот.

DataFetch = NewValueTable(); Data Selection.Columns.Add("Client"); Data Selection.Columns.Add("ClientType"); Избор на DataFrom the Directory = Directories.Contractors.Select(); При преземање на DataFromCatalog.Next() Јамка If FetchingDataFromCatalog.ThisGroup Потоа продолжете; EndIf; Ако DataFetchFromCatalog.Buyer Потоа NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = „Купувач“; EndIf; Ако DataFetchFromCatalog.Provider Потоа NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "Добавувач"; EndIf; Краен циклус;

Зачувајте го правилото за поставување податоци и вратете се на „ Правила за конверзија на објекти“. Ајде да додадеме за регистарот за информации “ Видови клиенти” Правила за конверзија на имот: тип на клиент и клиент. Го оставаме изворот празен и во управувачот за настани „Пред да се истовари“ пишуваме:

//За својството „Клиент“ Вредност = Извор.Клиент; //За својството „CustomerType“ If Source.Customer = „Buyer“ Then Expression = „Enumerations.CustomerTypes.Buyer“ ElseIf Source.Customer = „Supplier“ then Expression = „Enumerations.CustomerTypes.Supplier“; EndIf;

Во огласот, деталите се пополнуваат врз основа на извршениот избор на податоци. Го пренесуваме клиентот едноставно како врска и го пишуваме типот на клиентот во параметарот " Изразување“. Податоците од овој параметар ќе се толкуваат во приемникот, а при извршувањето, атрибутот ќе се пополни со точната вредност од набројувањето.

Тоа е тоа, правилата за размена се подготвени Разгледаниот пример се покажа како доста универзален. Сличен пристап често се користи при пренос на податоци од конфигурации создадени на платформата 7.7. Впечатлив пример за ова е преносот на периодични детали.

Задача број 3. Табеларни трикови

Честопати има задачи кои бараат објавување на редови од еден табеларен дел на неколку. На пример, во почетната конфигурација, услугите и стоките се регистрирани во еден табеларен дел, додека складирањето на овие ентитети е одвоено во приемникот. Повторно, проблемот не може да се реши со визуелни средства. Тука е погодно да се земе решението на вториот проблем како основа.

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

За да заштедам простор, нема да го дадам кодот (секогаш можете да се повикате на изворниот код) на барањето - нема ништо необично во него. Го подредуваме добиениот примерок и ги ставаме подредените резултати во веќе познатиот параметар “ Земање примероци на податоци“. Повторно, погодно е да се користи табела со вредности како колекција:

DataFetch = NewValueTable(); //Овде ќе има уште еден табеларен дел Data Selection.Columns.Add("Производи"); //Овде ќе има и табеларен дел Data Selection.Columns.Add("Услуги"); Избор на податоци од.Columns.Add(„Врската“);

Задача број 4. Пренесување податоци во операција

Ако една организација користи неколку сметководствени системи, тогаш порано или подоцна ќе има потреба од миграција на податоци со последователно формирање на објави.

Во конфигурацијата " БП„Постои универзален документ“ Операција“ и е идеален за формирање повеќе жици. Еве само еден проблем - документот е направен лукаво и не е толку лесно да се префрлат податоци во него.

Пример за таква конверзија може да се најде во изворниот код за статијата. Количината на кодот се покажа доста голема, така што нема смисла да се објави за статијата. Само да кажам дека прикачувањето повторно користи произволен алгоритам во правилата за поставување податоци.

Задача број 5. Синхронизирање податоци преку повеќе атрибути

Веќе опфативме неколку примери, но досега не сме зборувале за синхронизација на објекти за време на миграцијата. Ајде да замислиме дека треба да префрлиме договорни страни и некои од нив веројатно се во базата на податоци на примачот. Како да префрлите податоци и да спречите дупликати? Во овој поглед, ЦД нуди неколку начини за синхронизирање на пренесените објекти.

Првиот е со единствен идентификатор. Многу објекти имаат единствен идентификатор кој гарантира уникатност во табела. На пример, во прирачникот " Контрастрани“ не може да има два елементи со ист ID. ЦД-то прави пресметка за ова, и за сите креирани PSP, пребарувањето по идентификатор веднаш е стандардно овозможено. За време на креирањето на PSP, требаше да ја забележите иконата со лупа до името на објектот.

Синхронизирањето со единствен идентификатор е сигурен метод, но не е секогаш соодветен. Кога се спојуваат директориуми“ Контрастрани“ (од неколку различни системи) тој е од мала помош.

Во такви случаи, поправилно е да се синхронизираат објекти според неколку критериуми. Поправилно е да се пребаруваат договорни страни по TIN, KPP, Име или да се подели пребарувањето во неколку фази.

Конверзијата на податоците не го ограничува развивачот во дефинирањето на критериумите за пребарување. Ајде да разгледаме апстрактен пример. Да претпоставиме дека треба да ги синхронизираме директориумите “ Контрастрани“ од различни информативни бази. Ајде да подготвиме PCP и во поставките на правилата за конвертирање објект, штиклирајте го полето „ Продолжете со пребарување на полињата за пребарување ако објектот на примачот не е пронајден со ID“. Со оваа акција, веднаш дефиниравме два критериуми за пребарување - со единствен идентификатор и произволни полиња.

Ние имаме право сами да ги избираме полињата. Откако ги забележавме TIN, KPP, Име, веднаш ќе наведеме неколку критериуми за пребарување. Удобно? Сосема, но повторно, ова не е доволно. А што ако сакаме да ги промениме критериумите за пребарување? На пример, прво бараме куп TIN + KPP, а ако не најдеме ништо, тогаш почнуваме да си ја пробуваме среќата со името.

Сосема е можно да се имплементира таков алгоритам. Во управувачот на настани Полиња за пребарувањеМожеме да одредиме до 10 критериуми за пребарување и за секој од нив да дефинираме свој состав на полињата за пребарување:

Ако SearchOptionNumber = 1 тогаш SearchPropertyNameString = „TIN, KPP“; ElseIfSearchVariantNumber = 2 ThenSearchPropertyNameString = „Име“; EndIf;

Секогаш има повеќе решенија.

Секоја задача има неколку решенија, а преносот на податоци помеѓу различни конфигурации не е исклучок. Секој развивач има право да избере свој пат за решение, но ако постојано треба да развивате сложени миграции на податоци, тогаш силно препорачувам да обрнете внимание на конфигурацијата "". Нека прво треба да вложите ресурси (време) во обуката, но тие повеќе од ќе ви се исплатат на првиот повеќе или помалку сериозен проект.

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

Сè уште е потребно знаење за платформата

» е универзална алатка, но ако планирате да ја користите за да креирате миграции на податоци од конфигурации развиени за платформата 1C:Enterprise 7.7, тогаш ќе треба да потрошите време за да го запознаете вградениот јазик. Синтаксата и идеологијата на јазикот се многу различни, па затоа треба да потрошите време за учење. Остатокот од принципот останува ист.

"1C: Претпријатие"е универзален систем за автоматизирање на активностите на претпријатието и може да се користи за решавање на различни менаџмент и сметководствени проблеми. Во моментов, на платформата се развиени голем број стандардни и специјализирани решенија " 1C: Претпријатие“, што може да работи во цврста интеграција со други решенија, како на оваа платформа, така и со софтвер од трети страни.

Од големо значење за ефективна работа е способноста да се организира размена помеѓу различни информациски системи. Платформа " 1C: Претпријатие„ обезбедува разновидни алатки за размена на податоци и интеграција на апликативни решенија.

Книгата детално ја прикажува размената на податоци во XML формат, што денес е општо прифатено средство за претставување на податоци. Опишани се процедурите за развивање правила, чија примена ќе обезбеди пренос на информации од еден информациски систем на друг, вклучително и размена на податоци помеѓу типични конфигурации. 1C: Претпријатие".

Книгата е придружена со ЦД што содржи демо-информациски бази со примери на правила за размена и конфигурација. 1C: Претпријатие. Конверзија на податоци".

структура на книгата

Вовед

Поглавје 1.Општи правила за поставување принципи

Поглавје 2Користење на правила

Поглавје 3Автоматско креирање правила

Поглавје 4Структура на правила

Поглавје 5Детално проучување на правилата

Поглавје 6Ракувачи на настани

• Опции
• Ракувачи за „конверзија“.
• Ракувачи за „Правила за поставување податоци“.
• Ракувачи со „Правила за конверзија на објекти“.
• Ракувачи со „Правила за конверзија на група на имот“.
• Ракувачи со „Правила за конверзија на имот“.

Поглавје 7Полиња за пребарување

Поглавје 8Правила за чистење на податоците

Поглавје 9Алгоритми и прашања

Поглавје 10Типични примери на правила. Заобиколни решенија

• Вкупна конверзија
• Конверзија на директориум
• Конверзија на документ
• Конверзија на регистарот на информации
• Сметковна конверзија
• Конвертирање на план од карактеристични типови
• Конверзија на план за тип на пресметка
• Постојана конверзија 1C: Enterprise 7.7
• Конверзија на сметководствени трансакции 1C: Enterprise 7.7

Поглавје 11Оптимизација на правила

• Правила за поставување податоци
• Правила за конверзија на објекти
• Се обработува „Универзална XML размена на податоци“