Datu konvertēšana 2.0 un 2.1 ir 1C tehnoloģiskā konfigurācija, kas ieviesta platformas versijās no 8.1 līdz 8.3.

Rīka galvenais uzdevums ir rakstīt noteikumus apmaiņai starp lietojumprogrammu risinājumiem 1C 8 un 7. Pašreizējā datu konvertēšanas versija šodien ir 3.0.

Datu konvertēšana ir ļoti noderīga konfigurācija ar tās palīdzību var atrisināt ne tikai informācijas pārsūtīšanu no vienas informācijas bāzes uz citu, bet arī, piemēram, informācijas konvertēšanu vienas datu bāzes ietvaros.

Konfigurācija ir ļoti ērta lietošanai ar .

Datu konvertēšana noderēs jebkuram programmētājam: apmaiņas noteikumu izveides prasmes ir nopietns pluss profesionālajām prasmēm.

Lai iemācītos strādāt ar konfigurāciju, vislabāk ir atrisināt praktiskas problēmas. Mēģiniet izdomāt sev uzdevumus, piemēram: pārnesiet kādu informāciju no vienas datu bāzes uz otru, pārvērtiet pārdošanas dokumentu par kvīts dokumentu, "ievadiet" kārtējos grāmatvedības atlikumus dokumentā "atlikuma ievadīšanu" un citus darbus.

Būs ļoti noderīgi izprast 1C 8.3 “standarta” apmaiņas noteikumus, kuros bieži vien var atrast interesantus uzdevumu izpildes piemērus.

Lai saprastu pamatus, jums būs nepieciešami materiāli, mēs tos apsvērsim tālāk.

Video instrukcijas konvertēšanai

Lai iegūtu pamatinformāciju par datu apmaiņas iestatīšanu 1C, izmantojot konfigurāciju “1C Data Conversion”, skatiet piemēru videoklipā:

Materiāli, mācību grāmatas 1C Data Conversion 2.0 apguvei

Materiālu un dokumentācijas internetā nav pārāk daudz, centos apkopot svarīgākos un interesantākos materiālus:

0. Vispirms iesaku Iļjas Ļeontjeva bezmaksas video kursu, tas pieejams plkst saite.

1. Vispirms ieteiktu konfigurācijā izmantot iebūvēto palīdzību. Tas ir patiešām labi uzrakstīts un tehniski labi īstenots:

2. Otrs svarīgākais informācijas avots ir vietne http://www.mykod.info/ (vietne ir slēgta), kas specializējas tieši datu konvertēšanā. Tur jūs varat lejupielādēt lielu skaitu materiālu par konvertēšanu.

3. Atsevišķi es gribētu izcelt mācību grāmatu - (autore - Olga Kuzņecova).

Lai iestatītu datu apmaiņu starp dažādām (tostarp pašrakstītām) konfigurācijām 1C, ir ļoti elastīgs informācijas pārsūtīšanas iestatīšanas mehānisms - 1C “Datu konvertēšanas” (CD) konfigurācija. Apskatīsim, kā darbojas šis mehānisms, un mēģināsim iestatīt apmaiņas noteikumus starp divām tipiskām konfigurācijām:

• Enterprise Accounting (demo versija), izdevums 3.0.30;
• Algu un personāla vadība (demo versija), izdevums 3.0.25.

Konfigurācijas rīks apmaiņas noteikumu iestatīšanai būs Data Conversion versija 2.1.82. Darbi tiks veikti uz platformas 8.3.9.

Ir svarīgi atzīmēt, ka Data Conversion ļauj organizēt apmaiņu ne tikai starp programmas 8. versijas datu bāzēm, bet arī starp 1C platformas 7. un 8. versiju.

Starta palīgs

Pēc “Data Conversion” konfigurācijas instalēšanas un palaišanas pirmais logs, kas tiek atvērts, ir Startup Assistant (1. att.).

Varat to vēlreiz izsaukt no izvēlnes Darbības->Apstrāde vai no palīdzības, kur šī apstrāde ir iezīmēta kā atsevišķa komanda.

Tā kā mēs neplānojam izmantot standarta noteikumi pārsūtīšanu, bet nākamajā logā gatavojamies izveidot savu, no saraksta atlasīsim atbilstošo vienumu (2. att.).

2. att

Papildus jaunu apmaiņas noteikumu izveidei mēs varam:

Šajā brīdī mums vajadzētu nedaudz atpūsties no apmaiņas noteikumu izveides un runāt par konfigurācijas struktūras failiem.

Metadatu struktūras faili

Konvertācijas konfigurācijas pakotnē ir iekļauti vairāki ārējās ārstēšanas metodes, kas ļauj augšupielādēt metadatu struktūru xml failā.

Svarīgs noteikums! Struktūras izkraušanas apstrādei dažādām datu bāzēm ir jābūt vienai un tai pašai CD versijai.

Priekš dažādas versijas platformas, 1C ir ieviesis dažādu struktūru izkraušanas apstrādi:

• MD77Exp.ert – ļauj saglabāt septiņu datu bāzu konfigurācijas struktūru failā;
• MD82EXP.epf – eksportē datu bāzu struktūru, kas darbojas platformās 8.0-8.2 versijā;
• MD83EXP.epf – paredzēts platformai 8.3.

Tā kā mūsu uzdevuma apstākļos ir nepieciešams organizēt apmaiņu starp datu bāzēm, kas darbojas 8.3 laidienā, mēs izmantosim trešo apstrādi (4. att.).

4. att

Šeit mums jānorāda fails, kurā tiks augšupielādēta struktūra, un mēs varam konfigurēt papildu tabulu kopu, kas piedalīsies apmaiņā.

Pēc mērķa un avota konfigurācijas failu lejupielādes informācija no tiem ir jāielādē rīkā Data Conversion.

Priekš šī:

Otrajai bāzei mēs atkārtojam tās pašas darbības.

Atgriezīsimies pie mūsu asistenta.

Turpiniet strādāt ar palīgu

Pēc mūsu divu datu bāzu pievienošanas direktorijam tas izskatās šādi (6. att.).

Turpināsim strādāt ar palīgu

Nākamajā logā (7. att.) mums jāizvēlas uztvērēja bāze un avota bāze.

7. att

Un tagad mēs nonākam pie loga, kurā mums tiks lūgts noteikt, uz kādiem likumiem un atbilstībām balstīsies mūsu apmaiņa (8. att.).

8. att

Programma var patstāvīgi, izmantojot tajā iegultos algoritmus, izveidot datu apmaiņu. Izvēloties otro slēdzi, mēs varam izvēlēties no automātiski izveidotajiem noteikumiem tos, kas ir vispiemērotākie mūsu problēmas risināšanai. Ja mēs vēlamies patstāvīgi noteikt, ko un kā pārsūtīt un pēc kādiem datiem salīdzināt datus, mums jāiestata slēdzis trešajā pozīcijā.

Tā kā mēs vēlamies radīt savus noteikumus mēs iesim trešo ceļu.

Noteikumu izveide apmaiņai starp direktorijiem

Iestatiet slēdzi uz trešo saraksta vienumu un noklikšķiniet uz pogas “Palaist”.

Mēs atrodamies direktorija vienuma “Objektu konvertēšanas noteikumi” iestatījumu vednī (9. att.)

9. att

Avota datu bāzē mums ir jāizvēlas objekts, kura dati tiks sinhronizēti.

Uztvērēju datu bāzē ir tabula, kur šie dati tiks nodoti.

Nākamajā posmā mums ir jāizlemj par iekraušanas parametriem:

• Kāda informācija tiks izmantota atbilstības meklēšanai;
• Ko darīt ar esošajiem elementiem;
• Vai izveidot trūkstošos elementus;
• Kā rīkoties ar saitēm;
• Kādus noteikumus izmantot jaunu elementu numurēšanai.

Un augšupielādējiet parametrus.

Ja mēs nolemjam veikt automātisku datu saskaņošanu, mēs izlaidīsim šo darbību.

Beigās mums ir jāaugšupielādē izveidotie noteikumi diskā (10. att.).

10. att

Datu apmaiņa

Tālāko datu apmaiņu veiksim, izmantojot V8Exchan83.epf apstrādi (11.att.), kas iekļauta arī piegādes komplektā. Standarta datu apmaiņas izmantošana, kas ir daļa no konfigurācijas vai pašrakstītas apstrādes, izmantojot kompaktdiskā izveidotos noteikumus, var izraisīt ārkārtas situācijas rašanos.

11. att

Un vēlreiz: ir ārkārtīgi svarīgi, lai augšupielādes faila versija, konfigurācija un apmaiņas apstrāde atbilstu un tiktu ņemti no vienas piegādes, tikai šajā gadījumā jūs pēc iespējas vairāk pasargāsit sevi no visa veida problēmām.

Jebkurā gadījumā, ja datu pārsūtīšanas pareizības pārbaude uzrāda konfliktsituācijas un kļūdas, pārsūtīšanas apstrāde ļauj dzēst šos datus no datu bāzes.

Droši vien katrs 1C speciālists ir saskāries ar nepieciešamību pārsūtīt datus no vienas informācijas bāzes uz otru. Gadījumā, ja konfigurācijas atšķiras, jums ir jāraksta datu konvertēšanas noteikumi. Šie noteikumi ir izveidoti 1C konfigurācijā “Datu konvertēšana”.

Datus var pārsūtīt arī, izmantojot . Daudzās 1C 8.3 konfigurācijās ir tipiska funkcionalitāte datu sinhronizācijas iestatīšanai starp dažādām konfigurācijām un netraucētai integrācijai ar 1C Document Flow.

Bet, ja dati ir jāpārsūta starp absolūti identiskām konfigurācijām, varat vienkāršot savu uzdevumu un izmantot standarta apstrādi augšupielādei un lejupielādei, izmantojot XML. Lūdzu, ņemiet vērā, ka šī metode, tāpat kā datu konvertēšana, salīdzina objektus savā starpā pēc unikāla identifikatora (GUID), nevis pēc nosaukuma.

Šo apstrādi var lejupielādēt ITS diskā vai izmantojot saites:

Tas ir universāls un piemērots jebkurai konfigurācijai.

Apskatīsim piemēru direktorija "Nomenklatūra" izkraušanai no vienas 1C 8.3 Grāmatvedības 3.0 informācijas bāzes uz citu. Priekšnoteikums būs vecāku (grupas) atlase “Kokapstrāde”.

Datu augšupielāde no 1C uz XML

Dodieties uz informācijas bāzi, no kuras dati tiks lejupielādēti (avots). Noteikti pārbaudiet tos, ņemot vērā visus iespējamos apstākļus, lai izvairītos no nevēlamām sekām.

Atveriet augšupielādes un lejupielādes apstrādi XML dati(Ctrl+O).

Mūs interesē cilne “Augšupielādēt”. Vispirms norādiet faila nosaukumu, kurā tiks augšupielādēti dati, un saglabāšanas ceļu. IN šajā gadījumā dati tiek augšupielādēti "failā serverī".

Apstrādes galvenē varat konfigurēt periodu, par kuru tiks veikta atlase. Arī periodiskajiem reģistriem varat norādīt atlases piemērošanas metodi pēc perioda. Ja nepieciešams augšupielādēt kustības kopā ar dokumentiem, tiek iestatīts attiecīgais karodziņš. Šajā gadījumā mēs pārslogojam direktoriju, tāpēc galvenē nekas nav jākonfigurē.

Pāriesim pie datu atlases augšupielādei. Apstrādes veidlapas tabulas daļā atzīmējiet pārsūtāmo konfigurācijas objektu izvēles rūtiņas.

Slejā “Izlādēt, ja nepieciešams” ir norādīts, vai ir nepieciešams atkārtoti ielādēt šo objektu, ja uz to atsaucas pārlādējamā direktorija atribūts. Piemēram, ielādējamās preces pozīcijai ir mērvienība, kas nav mērķa datu bāzē. Ja karodziņš kolonnā “Augšupielādēt, ja nepieciešams” ir atzīmēts pretī atsauces grāmatai ar mērvienībām, tiks izveidota jauna pozīcija. Pretējā gadījumā atribūta vērtība būs “<Объект не найден>" un tā unikālais identifikators.

Vienkāršā gadījumā bez atlasēm vienuma pārslodzes iestatījums izskatīsies šādi.

IN šajā piemērā jāatlasa tikai tie vienumi, kas atrodas mapē “Kokapstrāde”.

Līdzīga apstrāde 8.2 ļauj iestatīt atlasi katram konfigurācijas objektam ērtā formā. Diemžēl 8.3 versijā šādas funkcionalitātes nav. Viena izeja šajā situācijā būtu atlasīt nepieciešamos vienumus cilnē “Papildu objekti izkraušanai”.

Šeit varat pievienot objektus vai nu manuāli (poga “Pievienot”), vai pēc pieprasījuma (“Pievienot pēc pieprasījuma...”). Ja to ir liels skaits, priekšroka dodama otrajam variantam.

Šajā gadījumā pieprasījums būs šāds. Aizpildiet parametrus, pēc datu pārbaudes aizpildiet pieprasījumu un noklikšķiniet uz pogas “Atlasīt rezultātu”.

Kad esat norādījis visus augšupielādei nepieciešamos objektus un papildu elementus, noklikšķiniet uz pogas “Augšupielādēt datus”. Viņi iekļūs XML fails, kuras nosaukums un ceļš tika norādīts iepriekš. Šīs darbības rezultāti tiks parādīti ziņojumos.

Šajā piemērā bija nepieciešams izkraut tikai 3 pozīcijas, bet piecas tika izkrautas. Tas ir tāpēc, ka slejā “Augšupielādēt, ja nepieciešams” pretī direktorijai “Nomenklatūra” tika iestatīts karogs. Līdz ar nepieciešamajiem amatiem viņu vecāki bija pārslogoti.

Notiek direktorija ielāde no XML

Pēc veiksmīgas datu lejupielādes no avota konfigurācijas XML failā atveriet mērķa datu bāzi. Objektu struktūrai un to detaļām ir jāsakrīt vienam ar otru. Šajā gadījumā pārsūtīšana tiek veikta starp divām standarta konfigurācijām 1C: Grāmatvedība 3.0.

Atvērta apstrāde uztvērēja datu bāzē. Šī apstrāde izmanto gan datu augšupielādei, gan lejupielādei. Dodieties uz cilni “Lejupielādēt” un norādiet ceļu uz XML failu, kurā dati iepriekš tika lejupielādēti. Pēc tam noklikšķiniet uz pogas “Lejupielādēt datus”.

Lejupielādes rezultāts tiks parādīts ziņojumos. Mūsu gadījumā viss noritēja labi.

Saņēmēja datubāzes direktorijs “Nomenklatūra” netika aizpildīts. Tagad tajā ir pieci elementi: trīs nomenklatūras pozīcijas un divas grupas.

Datu migrēšana starp dažādām konfigurācijām nav triviāls uzdevums. Kā vienmēr, ir vairāki risinājumi, taču ne visi no tiem ir optimāli. Mēģināsim izprast datu pārsūtīšanas nianses un izvēlēties universālu stratēģiju šādu problēmu risināšanai.

Datu migrācijas problēma (mēs runājam tikai par 1C uzņēmuma produktiem) no viena risinājuma uz otru vakar neradās. Uzņēmums 1C lieliski saprot, ar kādām grūtībām saskaras izstrādātāji, veidojot migrācijas, tāpēc visos iespējamos veidos cenšas palīdzēt ar rīkiem.

Platformas izstrādes gaitā uzņēmums ieviesa vairākus universālus rīkus, kā arī tehnoloģijas, kas vienkāršo datu pārraidi. Tie ir iebūvēti visos standarta risinājumos, un migrācijas problēma starp identiskām konfigurācijām kopumā ir atrisināta. Uzvaru vēlreiz apliecina ciešā standarta risinājumu integrācija.

Ar migrāciju starp nestandarta risinājumiem situācija ir nedaudz sarežģītāka. Plašs tehnoloģiju klāsts ļauj izstrādātājiem patstāvīgi izvēlēties optimālāko problēmas risināšanas veidu no viņu viedokļa.

Apskatīsim dažus no tiem:

• apmaiņa, izmantojot teksta failus;
• apmaiņas plānu izmantošana;
• utt.

Katram no tiem ir savi plusi un mīnusi. Rezumējot, galvenais trūkums būs tā daudzvārdība. Neatkarīga migrācijas algoritmu ieviešana ir saistīta ar ievērojamām laika izmaksām, kā arī ilgu atkļūdošanas procesu. Es pat nevēlos runāt par turpmāku atbalstu šādiem lēmumiem.

Atbalsta sarežģītība un augstās izmaksas mudināja 1C uzņēmumu izveidot universālu risinājumu. Tehnoloģijas, kas ļauj pēc iespējas vienkāršot migrācijas izstrādi un atbalstu. Rezultātā ideja tika realizēta atsevišķas konfigurācijas veidā – “Datu konvertēšana”.

Datu konvertēšana - standarta risinājums, neatkarīga konfigurācija. Jebkurš lietotājs ar “ITS:Prof” abonementu var lejupielādēt šo pakotni pilnīgi bez maksas no lietotāja atbalsta vietnes vai ITS diska. Notiek uzstādīšana standarta veidā- tāpat kā visi citi standarta risinājumi no 1C.

Tagad nedaudz par risinājuma priekšrocībām. Sāksim ar pašu svarīgāko – daudzpusību. Risinājums nav pielāgots konkrētām platformas konfigurācijām/versijām. Tas darbojas vienlīdz labi gan standarta, gan pielāgotās konfigurācijās. Izstrādātājiem ir universāla tehnoloģija un standartizēta pieeja jaunu migrāciju izveidei. Risinājuma daudzpusība ļauj sagatavot migrāciju pat platformām, kas nav 1C:Enterprise.

Otrs lielais pluss ir uzskates līdzekļi. Vienkāršas migrācijas tiek izveidotas bez programmēšanas. Jā, jā, bez vienas koda rindiņas! Tikai tādēļ vien ir vērts vienreiz veltīt laiku tehnoloģiju apguvei un pēc tam atkārtoti izmantot nenovērtējamas prasmes.

Trešā priekšrocība, ko es vēlētos atzīmēt, ir datu izplatīšanas ierobežojumu neesamība. Izstrādātājs pats izvēlas datu piegādes metodi uztvērēja konfigurācijā. Ir pieejamas divas iespējas: augšupielāde xml failā un tiešs savienojums ar informācijas bāzi (COM/OLE).

Studē arhitektūru

Mēs jau zinām, ka datu konvertēšana var radīt brīnumus, taču vēl nav pilnībā skaidrs, kādas ir tehniskās priekšrocības. Pirmā lieta, kas jums jāsaprot, ir tāda, ka jebkura datu migrācija (konversija) ir balstīta uz apmaiņas noteikumiem. Apmaiņas noteikumi ir parasts xml fails, kas apraksta struktūru, kurā tiks augšupielādēti dati no informācijas drošības. Pakalpojuma apstrāde, kas augšupielādē/lejupielādē datus, analizē apmaiņas noteikumus un veic augšupielādi, pamatojoties uz tiem. Iekraušanas laikā notiek apgrieztais process.

“CD” konfigurācija ir sava veida vizuālais konstruktors, ar kura palīdzību izstrādātājs izveido apmaiņas noteikumus. Tā nezina, kā lejupielādēt datus. Par to ir atbildīga papildu ārējā pakalpojuma apstrāde, kas iekļauta CD izplatīšanas pakotnē. Ir vairāki no tiem (XX faila nosaukumā ir platformas versijas numurs):

• MDXXExp.epf- apstrāde ļauj augšupielādēt informācijas bāzes struktūras aprakstu xml failā. Struktūras apraksts tiek ielādēts kompaktdiskā turpmākai analīzei un apmaiņas noteikumu izveidei.
• V8ExchanXX.epf- augšupielādē/lejupielādē datus no informācijas bāzes saskaņā ar apmaiņas noteikumiem. Vairumā tipisko konfigurāciju apstrāde notiek ārpus kastes (skatiet izvēlnes vienumu “Pakalpojums”). Apstrāde ir universāla un nav saistīta ar īpašām konfigurācijām/noteikumiem.

Labi, tagad, pamatojoties uz visu iepriekš minēto, definēsim jauna reklāmguvuma izstrādes posmus.

1. Uzdevuma definīcija. Ir skaidri jāsaprot, kādi dati ir jāpārsūta (no kādiem konfigurācijas objektiem) un, galvenais, kur tos pārsūtīt.
2. Konfigurācijas struktūru (Source/Sink) aprakstu sagatavošana turpmākai ielādei kompaktdiskā. Problēma tiek atrisināta ar servisa apstrādi MDXXExp.epf.
3. Sagatavoto būvju aprakstu ielāde informācijas drošībā.
4. Apmaiņas noteikumu izveide, izmantojot vizuālo CD rīku.
5. Augšupielādes/lejupielādes veikšana atbilstoši izveidotajiem datu konvertēšanas noteikumiem, izmantojot V8ExchanXX.epf apstrādi.
6. Atkļūdošanas apmaiņas noteikumi (ja nepieciešams).

Vienkāršākā pārveidošana

Demonstrācijai mums būs nepieciešamas divas izvietotas konfigurācijas. Es nolēmu izvēlēties iespēju: “Trade Management” 10. izdevums un neliels mājās rakstīts risinājums. Uzdevums būs pārsūtīt datus no standarta “UT” konfigurācijas. Īsuma labad pašu rakstīto risinājumu sauksim par “Sink”, bet tirdzniecības vadību – “Avots”. Sāksim risināt problēmu, pārsūtot elementus no direktorija “Nomenklatūra”.

Vispirms apskatīsim datu konvertēšanas shēmu un vēlreiz pārlasīsim veicamo darbību sarakstu. Pēc tam palaižam “Source” konfigurāciju un atveram tajā MD82Exp.epf pakalpojuma apstrādi.

Apstrādes saskarnei nav daudz iestatījumu. Lietotājam tikai jānorāda metadatu objektu veidi, kuri netiks iekļauti struktūras aprakstā. Vairumā gadījumu šie iestatījumi nav jāmaina, jo Nav īpašas jēgas izkraut kustības, izmantojot uzkrāšanas reģistrus (kā piemēru).

Pareizāk kustību veidot, turot dokumentus uztvērējā. Visas kustības pēc pārsūtīšanas veiks pats dokuments. Otrs arguments noklusējuma iestatījumu aizsardzībai ir faila lieluma samazināšana augšupielādes laikā.

Daži dokumenti (īpaši tipiskas konfigurācijas) veido kustības vairākos reģistros. Izkraujot visas šīs lietas, iegūtais XML fails kļūs pārāk liels. Tas var sarežģīt turpmāko transportēšanu un iekraušanu uztvērēja bāzē. Jo lielāks datu fails, jo vairāk jums būs nepieciešams brīvpiekļuves atmiņa lai to apstrādātu. Prakses laikā man bija iespēja sastapties ar nepieklājīgi lieliem augšupielādes failiem. Šādus failus pilnībā atteicās parsēt, izmantojot standarta rīkus.

Tātad, mēs atstājam visus noklusējuma iestatījumus un augšupielādējam konfigurācijas aprakstu failā. Mēs atkārtojam līdzīgu procedūru otrajai bāzei.

Atveriet kompaktdisku un galvenajā izvēlnē atlasiet "Katalogi" -> "Konfigurācijas". Direktorijā tiek glabāti visu konfigurāciju struktūru apraksti, ko var izmantot, lai izveidotu reklāmguvumus. Mēs vienu reizi ielādējam konfigurācijas aprakstu, un pēc tam varam to izmantot vairākas reizes, lai izveidotu dažādus reklāmguvumus.

Kataloga logā noklikšķiniet uz pogas " Pievienot” un parādītajā logā atlasiet failu, kas apraksta konfigurāciju. Atzīmējiet izvēles rūtiņu “Ielādēt jaunā konfigurācijā” un noklikšķiniet uz pogas “Ielādēt”. Līdzīgas darbības veicam ar otrās konfigurācijas struktūras aprakstu.

Tagad esat gatavs izveidot apmaiņas noteikumus. Galvenajā kompaktdiska izvēlnē atlasiet “Katalogi” -> “Reklāmguvumi”. Pievienot jauns elements. Jauna reklāmguvuma izveides logā jānorāda: avota konfigurācija (atlasiet UT) un galamērķa konfigurāciju (atlasiet “Uztvērējs”). Pēc tam atveriet cilni “Papildu” un aizpildiet tālāk norādītos laukus.

• apmaiņas noteikumu faila nosaukums - izveidotie apmaiņas noteikumi tiks saglabāti ar šo nosaukumu. Faila nosaukumu var mainīt jebkurā laikā, taču vislabāk to iestatīt tagad. Tas ietaupīs laiku nākotnē. Demonstrācijas piemēra noteikumus nosaucu: “rules-ut-to-priemnik.xml”.
• nosaukums - reklāmguvuma nosaukums. Nosaukums var būt pilnīgi jebkas, es aprobežojos ar “Demo. UT uztvērējam.

Tas arī viss, noklikšķiniet uz "Labi". Tūlīt mūsu priekšā parādās logs, kurā tiek lūgts automātiski izveidot visus noteikumus. Piekrītot šādam vilinošam piedāvājumam, kapteinis saņems komandu automātiski analizēt izvēlēto konfigurāciju aprakstu un neatkarīgi ģenerēt apmaiņas noteikumus.

Tūlīt atzīmēsim “i”. Vednis nevarēs ģenerēt neko nopietnu. Tomēr šo iespēju nevajadzētu ignorēt. Ja nepieciešams izveidot apmaiņu starp identiskām konfigurācijām, tad speciālista pakalpojumi būs ļoti noderīgi. Mūsu piemēram, priekšroka dodama manuālajam režīmam.

Apskatīsim tuvāk logu "Apmaiņas noteikumu iestatījumi". Saskarne var šķist nedaudz mulsinoša — liels skaits ciļņu, kas pieblīvētas ar vadīklām. Patiesībā viss nav tik grūti, jūs sākat pierast pie šī neprāta pēc dažām stundām, strādājot ar lietojumprogrammu.

Šajā posmā mūs interesē divas cilnes: “Objektu konvertēšanas noteikumi” un “Datu augšupielādes noteikumi”. Sākumā mums ir jākonfigurē atbilstības noteikumi, t.i. salīdziniet divu konfigurāciju objektus. Otrkārt, nosakiet iespējamos objektus, kas būs pieejami lietotājam augšupielādei.

Cilnes "Objektu konvertēšanas noteikumi" otrajā pusē ir papildu panelis ar divām cilnēm: "Īpašuma konvertēšana" un " Vērtību konvertēšana" Pirmais atlasīs atlasītā objekta rekvizītus (detaļas), bet otrais ir nepieciešams darbam ar iepriekš definētām vērtībām (piemēram, iepriekš definētiem direktoriju elementiem vai uzskaites elementiem).

Lieliski, tagad izveidosim direktoriju konvertēšanas noteikumus. Šo darbību var veikt divos veidos: izmantojiet objektu sinhronizācijas vedni (poga "") vai pievienojiet katra objekta atbilstību manuāli.

Lai ietaupītu vietu, mēs izmantosim pirmo iespēju. Vedņa logā noņemiet atzīmi no grupas " Dokumentācija” (mūs interesē tikai katalogi) un paplašināt grupu Katalogi" Mēs rūpīgi ritinām sarakstu un aplūkojam to atsauces grāmatu nosaukumus, kuras var salīdzināt.

Manā gadījumā ir trīs šādi direktoriji: Nomenklatūra, Organizācijas un Noliktavas. Ir arī direktorijs ar nosaukumu Klienti, kas kalpo tam pašam mērķim kā “ Darījuma partneri"no konfigurācijas" UT" Tiesa, meistars tos nevarēja salīdzināt dažādo nosaukumu dēļ.

Šo problēmu varam novērst paši. Mēs atrodam logā " Objektu sakritības" rokasgrāmata " Klienti" un kolonnā "Avots" atlasiet direktoriju "Darījumu partneri". Pēc tam atzīmējiet izvēles rūtiņu kolonnā “Veids” un noklikšķiniet uz pogas “Labi”.

Objektu sinhronizācijas vednis piedāvās automātiski izveidot noteikumus visu atlasīto objektu rekvizītu konvertēšanai. Īpašumus salīdzinās pēc nosaukuma un mūsu demonstrēšanai ar to pilnīgi pietiks, piekrītam. Nākamais jautājums būs priekšlikums izveidot augšupielādes noteikumus. Piekritīsim arī tam.

Apmaiņas noteikumu pamats ir gatavs. Mēs atlasījām objektus sinhronizēšanai, un rekvizītu konvertēšanas un augšupielādes kārtulu noteikumi tika izveidoti automātiski. Saglabāsim apmaiņas noteikumus failā, pēc tam atveram IB “Source” (manā gadījumā tas ir UT) un palaidīsim tajā pakalpojuma apstrādi. V8Exchan82.epf.

Pirmkārt, apstrādes logā atlasiet mūsu izveidotos apmaiņas noteikumus. Uz jautājumu par iekraušanas noteikumiem atbildam apstiprinoši. Apstrāde analizēs apmaiņas noteikumus un izveidos tāda paša nosaukuma objektu koku, kas ir pieejams augšupielādei. Šim kokam mēs varam iestatīt visu veidu atlases vai apmainīties ar mezgliem, kurus mainot, ir jāatlasa dati. Mēs vēlamies lejupielādēt pilnīgi visus datus, tāpēc nav nepieciešams instalēt filtrus.

Pēc datu augšupielādes failā procesa pabeigšanas dodieties uz IB " Uztvērējs" Tajā atveram arī apstrādi V8Exchan82.epf, tikai šoreiz mēs pārejam uz cilni “Datu ielāde”. Atlasiet datu failu un noklikšķiniet uz pogas "Lejupielādēt". Tas arī viss, dati ir veiksmīgi pārsūtīti.

Reālās pasaules problēmas

Pirmā demonstrācija varētu būt maldinoša. Viss izskatās diezgan vienkārši un loģiski. Patiesībā tā nav taisnība. IN īsts darbs Rodas problēmas, kuras ir grūti vai pilnīgi neiespējami atrisināt, izmantojot tikai vizuālos līdzekļus (bez programmēšanas).

Lai nebūtu vīlušies tehnoloģijā, sagatavoju vairākas reālās dzīves problēmas. Jūs noteikti ar viņiem saskarsities darbā. Tie neizskatās tik triviāli un liek paskatīties uz datu konvertēšanu no jauna leņķa. Rūpīgi apsveriet sniegtos piemērus un izmantojiet tos kā fragmentus, risinot reālas problēmas.

Uzdevums Nr.1. Aizpildiet trūkstošos datus

Pieņemsim, ka mums ir jāpārsūta direktorijs " Darījuma partneri" Šim nolūkam uztvērējam ir līdzīgs “Klientu” direktorijs. Tas ir pilnībā piemērots datu glabāšanai, bet tam ir rekvizīti. Organizācija”, kas ļauj nodalīt darījuma partnerus pēc piederības organizācijai. Pēc noklusējuma visiem darījumu partneriem ir jāpieder pie pašreizējās organizācijas (to var iegūt no tāda paša nosaukuma konstantes).

Problēmai ir vairāki risinājumi. Mēs izskatīsim iespēju aizpildīt informāciju " Organizācija“tieši datu bāzē” Uztvērējs”, t.i. datu ielādes laikā. Pašreizējā organizācija tiek glabāta konstantā, tāpēc šīs vērtības iegūšanai nav šķēršļu. Atvērsim objektu konvertēšanas kārtulu (turpmāk tekstā — PKO) " Klienti” (veiciet dubultklikšķi uz objekta) un noteikumu iestatīšanas vednī dodieties uz sadaļu “Notikumu apstrādātāji”. Apdarinātāju sarakstā mēs atradīsim “ Pēc lejupielādes”.

Aprakstīsim kodu pašreizējās organizācijas iegūšanai un pēc tam tā piešķiršanai detaļām. Laikā, kad tiek aktivizēts apdarinātājs “Pēc ielādes”, objekts būs pilnībā izveidots, bet vēl nav ierakstīts datu bāzē. Neviens mums neaizliedz to mainīt pēc saviem ieskatiem:

Ja NAV Object.ThisGroup, tad Object.Organization = Constants.CurrentOrganization.Get(); endIf;

Pirms informācijas aizpildīšanas " Organizācija"Ir nepieciešams pārbaudīt atribūta vērtību" Šī grupa" Uzziņu grāmatai " Klienti"Ir iestatīta hierarhiskā funkcija, tāpēc ir nepieciešams pārbaudīt grupu. Aizpildiet jebkuru informāciju līdzīgā veidā. Noteikti izlasiet palīdzību par citām apdarinātāja opcijām " Pēc ielādes" Piemēram, starp tiem ir parametrs " Atteikums" Ja piešķirat tam vērtību “True”, objekts netiks ierakstīts datu bāzē. Tādējādi kļūst iespējams ierobežot objektus, kurus var rakstīt ielādes laikā.

Uzdevums Nr.2. Sīkāka informācija informācijas reģistram

direktorijā " Darījuma partneri"UT konfigurācijas, pieejama informācija" Pircējs" Un " Pakalpojumu sniedzējs" Abas detaļas ir "tipa" Būla” un tiek izmantoti, lai noteiktu darījuma partnera veidu. In IB " Uztvērējs”, direktorijā “ Klienti"Nav līdzīgas detaļas, bet ir informācijas reģistrs" Klientu veidi" Tas veic līdzīgu funkciju un vienam klientam var saglabāt vairākus atribūtus. Mūsu uzdevums ir rekvizītu vērtības pārnest atsevišķos ierakstos informācijas reģistrā.

Diemžēl arī šeit ar vizuāliem līdzekļiem vien nevar tikt galā. Sāksim ar mazumiņu, izveidosim jaunu programmatūru informācijas reģistram” Klientu veidi" Neko neatsauciet kā avotu. Izvairieties no automātiskas augšupielādes noteikumu izveides.

Nākamais solis ir izveidot augšupielādes noteikumus. Dodieties uz atbilstošo cilni un noklikšķiniet uz " Pievienot" Augšupielādes noteikumu pievienošanas logā aizpildiet:

• Paraugu ņemšanas metode. Mainīt uz “Patvaļīgs algoritms”;
• Konversijas noteikums. Izvēlieties informācijas reģistru “Klientu veidi”;
• Noteikuma kods (nosaukums). Pierakstiet to kā “Klientu veidu augšupielāde”;

Tagad jums ir jāraksta kods, lai atlasītu datus augšupielādei. parametrs " Datu paraugu ņemšana" Tajā varam ievietot kolekciju ar sagatavotu datu kopu. Parametrs " Datu paraugu ņemšana” var iegūt dažādas vērtības - vaicājuma rezultātu, atlasi, vērtību kolekcijas utt. Mēs to inicializējam kā vērtību tabulu ar divām kolonnām: klienta un klienta tips.

Zemāk ir notikumu apstrādātāja kods " Pirms apstrādes" Tas inicializē parametru " Datu paraugu ņemšana", kam seko datu aizpildīšana no direktorija" Darījuma partneri" Šeit jums jāpievērš uzmanība kolonnas " Klienta veids" “UT” mūsu atribūti ir “Būla” tipa, un adresāts ir uzskaitījums.

Šajā posmā mēs tos nevaram novest pareizais tips(tas nav UT), tāpēc pagaidām to atstāsim virkņu formā. Jums tas nav jādara, taču es uzreiz vēlos parādīt, kā apraidīt trūkstošo veidu avotā.

DataFetch = New ValueTable(); DataSelection.Columns.Add("Klients"); DataSelection.Columns.Add("ClientType"); SelectingDataFromDirectory = Directories.Accounts.Select(); Atlasot datus noDirectory.Next() Loop If SelectingDataFromDirectory.ThisGroup then Continue; endIf; Ja datu atlase no direktorija.Pircējs, tad NewRow = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewRow.ClientType = "Klients"; endIf; Ja DataFetchFromDirectory.Supplier Tad NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Piegādātājs"; endIf; EndCycle;

Saglabāsim datu augšupielādes kārtulu un atgriezīsimies cilnē “ Objektu konvertēšanas noteikumi" Papildināsim informācijas reģistram “ Klientu veidi” īpašuma konvertēšanas noteikumi: klients un klienta tips. Mēs atstāsim avotu tukšu, un notikumu apstrādātājā “Pirms izkraušanas” rakstīsim:

//Īpašumam “Klients” Value = Source.Client; //Īpašumam “ClientType” If Source.Client = "Buyer" Then Expression = "Enumerations.ClientTypes.Buyer" ElseIf Source.Client = "Supplier" Then Expression = "Enumerations.ClientTypes.Supplier"; endIf;

Sarakstā dati tiek aizpildīti, pamatojoties uz atlasīto datu paraugu. Mēs vienkārši nododam klientu kā saiti un ierakstām klienta veidu parametrā “ Izteiksme" Šī parametra dati tiks interpretēti uztvērējā, un, izpildot, rekvizīts tiks aizpildīts ar pareizo vērtību no uzskaitījuma.

Tas tā, apmaiņas noteikumi ir gatavi Apskatītais piemērs izrādījās diezgan universāls. Līdzīga pieeja bieži tiek izmantota, migrējot datus no 7.7 platformā izveidotajām konfigurācijām. Spilgts piemērs tam ir periodisku detaļu pārsūtīšana.

Uzdevums Nr.3. Triki ar galda daļām

Bieži vien jūs saskaraties ar uzdevumiem, kuriem ir jāpublicē rindas no vienas tabulas sadaļas vairākās. Piemēram, sākotnējā konfigurācijā pakalpojumi un preces tiek reģistrētas vienā tabulas daļā, un saņēmējā šo entītiju glabāšana ir atdalīta. Atkal problēmu nevar atrisināt ar vizuāliem līdzekļiem. Šeit par pamatu ir ērti ņemt otrās problēmas risinājumu.

Mēs izveidojam datu izkraušanas noteikumu, norādām patvaļīgu algoritmu un apdarinātājā “Pirms izkraušanas” rakstām pieprasījumu iegūt datus no tabulas daļas.

Lai ietaupītu vietu, es nesniegšu pieprasījuma kodu (jūs vienmēr varat atsaukties uz avotiem) - tajā nav nekā neparasta. Mēs šķirojam iegūto atlasi un ievietojam sakārtotos rezultātus jau pazīstamajā parametrā " Datu paraugu ņemšana" Atkal ir ērti izmantot vērtību tabulu kā kolekciju:

DataFetch = New ValueTable(); //Šeit būs vēl viena tabulas daļa Data Selection.Columns.Add(“Produkti”); //Šeit arī būs tabulas daļa Data Selection.Columns.Add(“Services”); SelectionData.Columns.Add(“Saite”);

Uzdevums Nr.4. Datu pārsūtīšana uz darbību

Ja organizācija izmanto vairākas grāmatvedības sistēmas, tad agrāk vai vēlāk radīsies nepieciešamība migrēt datus ar sekojošu darījumu ģenerēšanu.

Konfigurācijā " BP"Ir universāls dokuments" Darbība” un tas ir ideāli piemērots formēšanai vairāk sūtījumi Ir tikai viena problēma - dokuments ir izgatavots viltīgi, un tajā nevar tik viegli pārsūtīt datus.

Šādas konversijas piemēru atradīsit raksta avota kodā. Koda apjoms izrādījās diezgan liels, tāpēc nav jēgas to publicēt kopā ar rakstu. Ļaujiet man tikai teikt, ka atkārtota augšupielāde izmanto patvaļīgu algoritmu datu augšupielādes noteikumos.

Uzdevums Nr.5. Datu sinhronizācija dažādās detaļās

Mēs jau esam apskatījuši vairākus piemērus, taču mēs joprojām neesam runājuši par objektu sinhronizāciju migrācijas laikā. Iedomāsimies, ka mums ir jāpārskaita darījuma partneri, un daži no tiem, iespējams, atrodas saņēmēju datu bāzē. Kā pārsūtīt datus un novērst dublikātu parādīšanos? Šajā sakarā CD piedāvā vairākus veidus, kā sinhronizēt pārsūtītos objektus.

Pirmais ir ar unikālu identifikatoru. Daudziem objektiem ir unikāls identifikators, kas garantē unikalitāti tabulā. Piemēram, direktorijā " Darījuma partneri” nevar būt divi elementi ar vienādiem identifikatoriem. CD veic aprēķinus šim un visiem izveidotajiem PCO, pēc noklusējuma tiek nekavējoties iespējota meklēšana pēc identifikatora. Veidojot PCO, blakus objekta nosaukumam vajadzēja pamanīt palielināmā stikla attēlu.

Sinhronizācija, izmantojot unikālu identifikatoru, ir uzticama metode, taču tā ne vienmēr ir piemērota. Apvienojot direktorijus “ Darījuma partneri” (no vairākām dažādām sistēmām) tas daudz nepalīdzēs.

Šādos gadījumos pareizāk ir sinhronizēt objektus pēc vairākiem kritērijiem. Pareizāk ir meklēt darījumu partnerus pēc INN, KPP, vārda vai sadalīt meklēšanu vairākos posmos.

Datu konvertēšana neierobežo izstrādātāju meklēšanas kritēriju definēšanā. Apskatīsim abstraktu piemēru. Pieņemsim, ka mums ir jāsinhronizē direktoriji " Darījuma partneri"no dažādām informācijas bāzes. Sagatavosim PKO un objekta konvertēšanas noteikumu iestatījumos pārbaudiet “ Turpiniet meklēšanu meklēšanas laukos, ja uztvērēja objekts nav atrasts pēc identifikatora" Ar šo darbību mēs uzreiz definējām divus meklēšanas kritērijus — pēc unikāla identifikatora un pielāgotiem laukiem.

Mums ir tiesības pašiem izvēlēties laukus. Atzīmējot TIN, KPP un Vārdu, mēs nekavējoties norādīsim vairākus meklēšanas kritērijus. Ērti? Diezgan, bet ar to atkal nepietiek. Ko darīt, ja mēs vēlamies mainīt meklēšanas kritērijus? Piemēram, vispirms mēs meklējam kombināciju TIN+KPP un, ja neko neatrodam, tad sākam izmēģināt veiksmi ar nosaukumu.

Šāds algoritms ir diezgan spējīgs tikt ieviests. Pasākumu apstrādātājā " Meklēšanas lauki” varam norādīt līdz 10 meklēšanas kritērijiem un katram no tiem definēt savu meklēšanas lauku sastāvu:

Ja SearchOptionNumber = 1, tad SearchPropertyNameString = "TIN, KPP"; Pretējā gadījumāIfSearchOptionNumber = 2 Tad SearchPropertyNameString = "Nosaukums"; endIf;

Vienmēr ir vairāki risinājumi

Jebkuram uzdevumam ir vairāki risinājumi, un datu pārsūtīšana starp dažādām konfigurācijām nav izņēmums. Katram izstrādātājam ir tiesības izvēlēties savu risinājumu ceļu, taču, ja jums pastāvīgi ir jāizstrādā sarežģītas datu migrācijas, es ļoti iesaku pievērst uzmanību “”. Iespējams, sākumā būs jāiegulda resursi (laiks) apmācībās, taču tie vairāk nekā atmaksāsies pirmajā vairāk vai mazāk nopietnajā projektā.

Manuprāt, uzņēmums 1C negodīgi ignorē datu konvertēšanas izmantošanas tēmu. Visā tehnoloģijas pastāvēšanas laikā par to tika izdota tikai viena grāmata: "1C: Enterprise 8. Datu konvertēšana: apmaiņa starp lietojumprogrammu risinājumiem." Grāmata ir diezgan veca (2008), bet joprojām ir ieteicams ar to iepazīties.

Joprojām ir nepieciešamas zināšanas par platformām

"ir universāls rīks, taču, ja plānojat to izmantot datu migrācijas izveidei no 1C:Enterprise 7.7 platformai izstrādātajām konfigurācijām, tad būs jāpavada laiks, lai iepazītos ar iebūvēto valodu. Valodas sintakse un ideoloģija ir ļoti atšķirīga, tāpēc jums būs jāvelta laiks mācībām. Pretējā gadījumā princips paliek nemainīgs.