სპეციალიზებული კონფიგურაცია "1C: მონაცემთა კონვერტაცია 2.0"

1C:Enterprise პლატფორმის მერვე ვერსიის გამოშვება გახდა მნიშვნელოვანი ნაბიჯი ავტომატიზაციის სისტემების განვითარებაში. 1C:Enterprise 8 პლატფორმის დიზაინის შექმნისას მხედველობაში იქნა მიღებული 1C:Enterprise 7.7 პლატფორმაზე დაფუძნებული გადაწყვეტილებების გამოყენების დიდი გამოცდილება: პლატფორმის ჩაშენებული ენა და ტიპიური კონფიგურაციები სერიოზულად შეიცვალა, მონაცემთა შენახვის სტრუქტურა და წვდომა. შეიცვალა, შეიქმნა ახალი ინდუსტრიული გადაწყვეტილებები, რომლებიც აცნობიერებენ ახალი პლატფორმის უპირატესობებს. ახალ პლატფორმაში წინა ენის კონსტრუქციების გამოყენება შეუსაბამო გახდა.

ამ პრობლემის გადაჭრის გასაადვილებლად (მონაცემთა გადაცემა 7.7 ვერსიიდან 8 ვერსიამდე), 1C გამოუშვა სპეციალიზებული კონფიგურაცია "მონაცემთა კონვერტაცია 2.0". იგი შეიქმნა იმისათვის, რომ დაეხმაროს სპეციალისტებს მონაცემთა გადაცემის სხვადასხვა პრობლემის გადაჭრაში. 1C-მ გამოუშვა მზა წესები იმავე ტიპის კონფიგურაციებიდან მონაცემების გადასატანად, მაგალითად, 1C: Accounting 7.7-დან 1C: Accounting 8-მდე, მაგრამ არასტანდარტული ან შეცვლილი სტანდარტული კონფიგურაციის მომხმარებლები 1C: Enterprise 8 პლატფორმაზე გადასვლისას. მოგიწევთ დამოუკიდებლად შექმნათ გადაცემის წესების მონაცემები.

მონაცემთა გადაცემის პრობლემების გადაჭრის კერძო მეთოდების მრავალფეროვნებით, გადასაჭრელი საკითხების სპექტრი პრაქტიკულად უცვლელი რჩება:

საცნობარო ინფორმაციის სინქრონიზაცია (ახლის შექმნა, განახლება არსებული ელემენტებიდირექტორიები, იერარქიის წაშლა, შენახვა ან შეცვლა, მონაცემების განშტოება, პერიოდული დეტალების მნიშვნელობების შეცვლის ისტორიის გადაცემა);

დოკუმენტებისა და ოპერაციების სინქრონიზაცია (დოკუმენტების შექმნა, მოდიფიცირება ან ერთი ტიპის დოკუმენტის მეორეში გადაქცევა, გაერთიანება ან რეპროდუცირება);

სააღრიცხვო რეესტრის წარმოებისთვის საკმარისი საწყისი პირობების შექმნა ეკონომიკური აქტივობა(ნარჩენი საქონლის გადაცემა და ა.შ.).

მონაცემთა შენახვის სტრუქტურები 1C: საწარმოში სხვადასხვა ვერსიები და/ან კონფიგურაციები განსხვავებულია, ამიტომ მონაცემთა გადაცემა არ არის მხოლოდ ფაილების ან ცხრილების კოპირება, არამედ მათი კონვერტაცია. იმისთვის, რომ ტრანსფორმაცია იყოს ცალსახა და სწორი, აუცილებელია მონაცემთა გადაცემის წესების შექმნა და კონფიგურაცია. სხვადასხვა ინფობაზებს შორის მონაცემთა გადაცემის წესების შექმნა და კონფიგურაცია შესაძლებელია, თუ ცნობილია წყაროსა და დანიშნულების მონაცემთა ბაზებში მონაცემთა შენახვის სტრუქტურა. კონფიგურაციის მეტამონაცემების სტრუქტურის აღწერა უნდა იყოს ერთიანი. Data Conversion 2.0 კონფიგურაცია გამოიყენება მონაცემთა გადაცემის წესების შესაქმნელად და კონფიგურაციისთვის, რომელიც ეფუძნება წყაროსა და დანიშნულების კონფიგურაციის მეტამონაცემების სტრუქტურის აღწერილობებს.

ინფორმაციის ბაზებს შორის მონაცემთა გადაცემის პროცესი შედგება შემდეგი ნაბიჯებისგან:

• 1. მეტამონაცემების აღწერილობის ფაილების შექმნა.
• 2. კონფიგურაციების შექმნა „მონაცემთა კონვერტაციაში“.
• 3. თავად კონვერტაციის შექმნა.
• 4. მონაცემთა კონვერტაციის წესების თანმიმდევრული შექმნა.
• 5. მონაცემთა ატვირთვის წესების თანმიმდევრული შექმნა.
• 6. ერთი კონფიგურაციიდან მეორეში მონაცემების გადმოტვირთვისა და ჩატვირთვის რეალური პროცედურა.

იმიტომ რომ ამ სპეციალიზებული კონფიგურაციის გამოყენება ერთ-ერთი ყველაზე ეფექტურია ამ მომენტშიამ ტიპის პრობლემების გადაჭრის გზები და გარდა ამისა, პირადი გამოცდილების წყარო, რომელიც ძალიან სასარგებლოა საგანმანათლებლო მიზნებისთვის, შემდეგ შეიმუშავეთ მონაცემთა გაცვლის მექანიზმი IS-ს შორის "სერვერი: ქირის გაანგარიშება" და "1C: საწარმოს აღრიცხვა" შპს " LLC" მეთოდი, რომელიც დაფუძნებულია "მონაცემთა კონვერტაციის 2.0" კონფიგურაციის გამოყენებაზე.

მონაცემთა კონვერტაცია 2.0 და 2.1 არის 1C ტექნოლოგიური კონფიგურაცია, რომელიც დანერგილია პლატფორმის ვერსიებზე 8.1-დან 8.3-მდე.

ინსტრუმენტის მთავარი ამოცანაა 1C 8 და 7 აპლიკაციური გადაწყვეტილებების გაცვლის წესების დაწერა.მონაცემთა კონვერტაციის მიმდინარე ვერსია დღეს არის 3.0.

მონაცემთა კონვერტაცია ძალიან სასარგებლო კონფიგურაციაა, მასთან ერთად შეგიძლიათ გადაჭრათ არა მხოლოდ ინფორმაციის ერთი ინფობაზიდან მეორეზე გადატანის საკითხი, არამედ, მაგალითად, ინფორმაციის კონვერტაცია ერთი მონაცემთა ბაზაში.

კონფიგურაცია ძალიან მოსახერხებელია გამოსაყენებლად, როდესაც .

მონაცემთა კონვერტაცია სასარგებლო იქნება ნებისმიერი პროგრამისტისთვის: გაცვლის წესების შექმნის უნარების ფლობა სერიოზული პლიუსია პროფესიული უნარებისთვის.

იმისათვის, რომ ისწავლოთ კონფიგურაციასთან მუშაობა, საუკეთესოდ შეეფერება პრაქტიკული პრობლემების გადაჭრას. შეეცადეთ შეასრულოთ ამოცანები თქვენთვის, მაგალითად: გადაიტანოთ ნებისმიერი ინფორმაცია ერთი მონაცემთა ბაზიდან მეორეში, გადააკეთოთ განხორციელების დოკუმენტი ქვითრის დოკუმენტად, „დრაივი“ მიმდინარე ნაშთები on აღრიცხვადოკუმენტში „ნაშთების შეყვანა“ და სხვა ამოცანები.

ძალიან სასარგებლო იქნება 1C 8.3 გაცვლის "ტიპიური" წესების გაგება, აქ ხშირად შეგიძლიათ იპოვოთ ამოცანების შესრულების საინტერესო მაგალითები.

საფუძვლების გასაგებად, დაგჭირდებათ მასალები, განიხილეთ ისინი ქვემოთ.

ვიდეო ინსტრუქცია კონვერტაციისთვის

1C-ში მონაცემთა გაცვლის დაყენების საფუძვლებისთვის „1C მონაცემთა კონვერტაციის“ კონფიგურაციის გამოყენებით, იხილეთ ვიდეო მაგალითისთვის:

მასალები, სახელმძღვანელოები 1C მონაცემთა კონვერტაციის შესასწავლად 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" კონფიგურაცია არის ერთგვარი ვიზუალური კონსტრუქტორი, რომლითაც დეველოპერი ქმნის გაცვლის წესებს. მან არ იცის როგორ ატვირთოს მონაცემები. ამაზე პასუხისმგებელია დამატებითი გარე სერვისის დამუშავება, რომელიც შედის CD განაწილების კომპლექტში. რამდენიმე მათგანია (ფაილის სახელში XX არის პლატფორმის ვერსიის ნომერი):

• MDXXExp.epf- დამუშავება საშუალებას გაძლევთ ატვირთოთ ინფორმაციის ბაზის სტრუქტურის აღწერა xml ფაილში. სტრუქტურის აღწერა ჩაიტვირთება CD-ში შემდგომი ანალიზისა და გაცვლის წესების შესაქმნელად.
• V8ExchanXX.epf- ატვირთავს/ჩამოტვირთავს მონაცემებს ინფობაზიდან გაცვლის წესების შესაბამისად. უმეტეს ტიპურ კონფიგურაციებში, დამუშავება ხელმისაწვდომია ყუთიდან (იხ. მენიუს პუნქტი „სერვისი“). დამუშავება უნივერსალურია და არ არის მიბმული რაიმე კონკრეტულ კონფიგურაციასთან/წესთან.

კარგი, ახლა ყოველივე ზემოთქმულიდან გამომდინარე, მოდით განვსაზღვროთ ახალი კონვერტაციის შემუშავების ეტაპები:

1. დავალების განსაზღვრა. აუცილებელია ნათლად გვესმოდეს, რა მონაცემების გადაცემაა საჭირო (რომელი კონფიგურაციის ობიექტები) და, რაც მთავარია, სად გადაიტანოს.
2. კონფიგურაციის სტრუქტურების (წყარო/მიმღები) აღწერილობის მომზადება CD-ში შემდგომი ჩატვირთვისთვის. ამოცანა მოგვარებულია სერვისის დამუშავებით MDXXExp.epf.
3. IS-ში სტრუქტურების მომზადებული აღწერილობების ჩატვირთვა.
4. გაცვლის წესების შექმნა CD-ის ვიზუალური საშუალებების გამოყენებით.
5. ატვირთვა/ჩამოტვირთვა შექმნილი მონაცემთა კონვერტაციის წესების მიხედვით V8ExchanXX.epf დამუშავების გამოყენებით.
6. გამართვის გაცვლის წესები (საჭიროების შემთხვევაში).

უმარტივესი კონვერტაცია

დემონსტრაციისთვის ჩვენ გვჭირდება ორი განლაგებული კონფიგურაცია. გადავწყვიტე შევჩერდე ვარიანტზე: „ვაჭრობის მენეჯმენტი“ მე-10 გამოცემა და პატარა თვითნაწერი გადაწყვეტა. ამოცანა იქნება მონაცემთა გადაცემა ტიპიური UT კონფიგურაციიდან. მოკლედ, ჩვენ დავარქვათ თვითნაწერი გადაწყვეტა "მიმღები", ხოლო სავაჭრო მენეჯმენტი "წყარო". დავიწყოთ პრობლემის გადაჭრა „ნომენკლატურის“ დირექტორიაში ელემენტების გადატანით.

უპირველეს ყოვლისა, მოდით გადავხედოთ მონაცემთა კონვერტაციის სქემას და ხელახლა წავიკითხოთ მოქმედებების სია, რომლებიც უნდა გაკეთდეს. შემდეგ ჩვენ ვიწყებთ "Source" კონფიგურაციას და ვხსნით მასში სერვისის დამუშავებას MD82Exp.epf.

დამუშავების ინტერფეისი არ ანათებს პარამეტრების სიმრავლით. მომხმარებელმა მხოლოდ უნდა მიუთითოს მეტამონაცემების ობიექტების ტიპები, რომლებიც არ მოხვდება სტრუქტურის აღწერაში. უმეტეს შემთხვევაში, ამ პარამეტრების შეცვლა არ არის საჭირო, რადგან დაგროვების რეგისტრებში მოძრაობის გადმოტვირთვას განსაკუთრებული აზრი არ აქვს (მაგალითად).

უფრო სწორია მოძრაობის ფორმირება მიმღებში დოკუმენტების შენახვისას. გადარიცხვის შემდეგ ყველა მოძრაობა განხორციელდება თავად დოკუმენტის მიერ. ნაგულისხმევი პარამეტრების დასაცავად მეორე არგუმენტი არის ატვირთული ფაილის ზომის შემცირება.

ზოგიერთი დოკუმენტი (განსაკუთრებით ტიპიურ კონფიგურაციებში) აყალიბებს მოძრაობას მრავალ რეესტრში. მთელი ამ ეკონომიის გადმოტვირთვა მიღებულ XML ფაილს ძალიან დიდს გახდის. ამან შეიძლება გაართულოს შემდგომი ტრანსპორტირება და ჩატვირთვა მიმღების ბაზაში. რაც უფრო დიდია მონაცემთა ფაილი, მით მეტი ოპერატიული მეხსიერებაა საჭირო მის დასამუშავებლად. ჩემი პრაქტიკის დროს, შემხვდა უხამსად დიდი ატვირთვის ფაილები. ასეთი ფაილები სრულიად უარს ამბობდნენ სტანდარტული საშუალებების გაანალიზებაზე.

ასე რომ, ჩვენ ვტოვებთ ყველა ნაგულისხმევ პარამეტრს და ატვირთავთ კონფიგურაციის აღწერას ფაილში. იგივე პროცედურას ვიმეორებთ მეორე ფუძისთვის.

გახსენით CD და აირჩიეთ მთავარი მენიუდან "დირექტორიები" -> "კონფიგურაციები". დირექტორიაში ინახება ყველა კონფიგურაციის სტრუქტურის აღწერილობები, რომლებიც შეიძლება გამოყენებულ იქნას კონვერტაციის შესაქმნელად. ჩვენ ვტვირთავთ კონფიგურაციის აღწერილობას ერთხელ და შემდეგ შეგვიძლია მისი განმეორებით გამოყენება სხვადასხვა კონვერტაციის შესაქმნელად.

დირექტორიაში, დააჭირეთ ღილაკს " დამატებადა ფანჯარაში, რომელიც გამოჩნდება, აირჩიეთ ფაილი კონფიგურაციის აღწერით. შეამოწმეთ ყუთი „ატვირთვა ახალ კონფიგურაციაში“ და დააჭირეთ ღილაკს „ატვირთვის შესრულება“. ჩვენ ვასრულებთ მსგავს მოქმედებებს მეორე კონფიგურაციის სტრუქტურის აღწერით.

ახლა ყველაფერი მზად არის გაცვლის წესების შესაქმნელად. CD-ის მთავარ მენიუში აირჩიეთ "References" -> "Conversions". ახალი ელემენტის დამატება. ახალი კონვერტაციის შექმნის ფანჯარაში, თქვენ უნდა მიუთითოთ: წყაროს კონფიგურაცია (აირჩიეთ UT) და მიმღების კონფიგურაცია (აირჩიეთ "მიმღები"). შემდეგ გახსენით "Advanced" ჩანართი და შეავსეთ შემდეგი ველები:

• გაცვლის წესები ფაილის სახელი - შექმნილი გაცვლის წესები შეინახება ამ სახელით. ფაილის სახელი შეიძლება შეიცვალოს ნებისმიერ დროს, მაგრამ უმჯობესია დააყენოთ ახლავე. ეს დაზოგავს დროს მომავალში. მე დავასახელე დემო-ს წესები: "rules-ut-to-priemnik.xml".
• სახელი - კონვერტაციის სახელი. სახელი შეიძლება იყოს აბსოლუტურად ნებისმიერი, მე შემოვიფარგლე „დემოთი. UT მიმღებამდე“.

ეს არის ის, დააჭირეთ "Ok". მაშინვე ჩვენს თვალწინ ჩნდება ფანჯარა, რომელიც გვთხოვს ავტომატურად შევქმნათ ყველა წესი. ასეთ მაცდურ შეთავაზებაზე დათანხმება მასტერს მისცემს ბრძანებას ავტომატურად გააანალიზოს არჩეული კონფიგურაციების აღწერა და დამოუკიდებლად შექმნას გაცვლის წესები.

მოდი, მაშინვე დავასრულოთ წერტილი "და". ოსტატი ვერაფერს სერიოზულს ვერ გამოიმუშავებს. თუმცა, ეს შესაძლებლობა არ უნდა იყოს შემცირებული. თუ თქვენ გჭირდებათ გაცვლის დამყარება იდენტურ კონფიგურაციებს შორის, მაშინ ოსტატის მომსახურება ძალიან სასარგებლო იქნება. ჩვენი მაგალითისთვის სასურველია მექანიკური რეჟიმი.

მოდით უფრო ახლოს მივხედოთ "გაცვლის წესების პარამეტრების" ფანჯარას. ინტერფეისი შეიძლება ცოტა დამაბნეველი ჩანდეს - ჩანართების დიდი რაოდენობა, რომლებიც სავსეა კონტროლით. სინამდვილეში ყველაფერი არც ისე რთულია, ამ სიგიჟეს აპლიკაციით რამდენიმესაათიანი მუშაობის შემდეგ იწყებ შეგუებას.

ამ ეტაპზე ჩვენ გვაინტერესებს ორი ჩანართი: „ობიექტის კონვერტაციის წესები“ და „მონაცემების ატვირთვის წესები“. პირველზე უნდა დავაწესოთ შესატყვისი წესები, ე.ი. შეადარეთ ორი კონფიგურაციის ობიექტები. მეორეზე, განსაზღვრეთ შესაძლო ობიექტები, რომლებიც ხელმისაწვდომი იქნება მომხმარებლისთვის განტვირთვისთვის.

"ობიექტების კონვერტაციის წესების" ჩანართის მეორე ნახევარში არის დამატებითი პანელი ორი ჩანართით: "საკუთრების კონვერტაცია" და " ღირებულების კონვერტაცია". პირველი შეარჩევს არჩეული ობიექტის თვისებებს (რეკვიზიტებს), ხოლო მეორე აუცილებელია წინასწარ განსაზღვრულ მნიშვნელობებთან მუშაობისთვის (მაგალითად, წინასწარ განსაზღვრული ლექსიკონის ელემენტები ან აღრიცხვის ელემენტები).

კარგია, ახლა მოდით შევქმნათ დირექტორიების კონვერტაციის წესები. თქვენ შეგიძლიათ შეასრულოთ ეს მოქმედება ორი გზით: გამოიყენეთ ობიექტების სინქრონიზაციის ოსტატი (დააწკაპუნეთ "") ან დაამატეთ შესატყვისები თითოეული ობიექტისთვის ხელით.

სივრცის დაზოგვის მიზნით, ჩვენ გამოვიყენებთ პირველ ვარიანტს. ოსტატის ფანჯარაში მოხსენით ველი " Დოკუმენტები” (ჩვენ გვაინტერესებს მხოლოდ დირექტორიები) და გავაფართოვოთ ჯგუფი ” Ცნობარები". ჩვენ ყურადღებით გადავხედავთ სიას და ვათვალიერებთ დირექტორიების სახელებს, რომელთა შედარებაც შესაძლებელია.

ჩემს შემთხვევაში, არსებობს სამი ასეთი დირექტორია: ნომენკლატურა, ორგანიზაციები და საწყობები. ასევე არის კლიენტების დირექტორია, რომელიც ასრულებს იგივე სემანტიკურ დატვირთვას, როგორც " კონტრაგენტები”კონფიგურაციიდან” UT". მართალია, ოსტატმა ვერ შეძლო მათი შედარება მათი შესანიშნავი სახელების გამო.

ჩვენ თვითონ შეგვიძლია გამოვასწოროთ ეს ხარვეზი. იპოვნეთ ფანჯარაში ობიექტების რუქები»სახელმძღვანელო» კლიენტები", ხოლო სვეტში "წყარო" აირჩიეთ საცნობარო წიგნი "კონტრაგენტები". შემდეგ მონიშნეთ ყუთი "ტიპი" სვეტში და დააჭირეთ ღილაკს "Ok".

Object Synchronization Wizard მოგთხოვთ ავტომატურად შექმნათ წესები ყველა არჩეული ობიექტის თვისებების კონვერტაციისთვის. თვისებები დაემთხვევა სახელს და ჩვენი დემონსტრირებისთვის ეს სავსებით საკმარისი იქნება, ვეთანხმებით. შემდეგი შეკითხვა იქნება წინადადება ატვირთვის წესების შესაქმნელად. მოდით შევთანხმდეთ.

გაცვლის წესების საფუძველი მზად არის. ჩვენ შევარჩიეთ ობიექტები სინქრონიზაციისთვის და ავტომატურად შეიქმნა თვისებების კონვერტაციისა და წესების ატვირთვის წესები. მოდით შევინახოთ გაცვლის წესები ფაილში, შემდეგ გავხსნათ IB “Source” (ჩემს შემთხვევაში ეს არის UT) და დავიწყოთ მასში სერვისის დამუშავება. V8Exchan82.epf.

უპირველეს ყოვლისა, დამუშავების ფანჯარაში აირჩიეთ ჩვენ მიერ შექმნილი გაცვლის წესები. წესების ჩატვირთვის კითხვას დადებითად ვპასუხობთ. დამუშავება გააანალიზებს გაცვლის წესებს და ააშენებს ამავე სახელწოდების ხეს განტვირთვისთვის ხელმისაწვდომი ობიექტებისთვის. ამ ხისთვის ჩვენ შეგვიძლია დავაყენოთ ყველა სახის ფილტრი ან გავცვალოთ კვანძები, რომელთა შეცვლით უნდა შევარჩიოთ მონაცემები. ჩვენ გვინდა ავტვირთოთ აბსოლუტურად ყველა მონაცემი, ამიტომ არ არის საჭირო ფილტრების დაყენება.

ფაილში მონაცემების ატვირთვის პროცესის დასრულების შემდეგ, გადადით IB " მიმღები". ჩვენ ასევე ვხსნით მასში დამუშავებას V8Exchan82.epf, მხოლოდ ამჯერად გადავდივართ ჩანართზე „მონაცემების ჩატვირთვა“. აირჩიეთ მონაცემთა ფაილი და დააჭირეთ ღილაკს "ატვირთვა". ყველაფერი, მონაცემები წარმატებით იქნა გადაცემული.

ამოცანები რეალური სამყაროდან

პირველი დემო შეიძლება იყოს შეცდომაში შემყვანი. ყველაფერი საკმაოდ მარტივი და ლოგიკური ჩანს. სინამდვილეში ეს სიმართლეს არ შეესაბამება. რეალურ სამუშაოში წარმოიქმნება ამოცანები, რომელთა გადაჭრაც მხოლოდ ვიზუალური საშუალებების გამოყენებით (პროგრამირების გარეშე) რთული ან სრულიად შეუძლებელია.

იმისთვის, რომ ტექნოლოგიაში იმედგაცრუებული არ ვიყო, მოვამზადე რამდენიმე რეალური დავალება. მათ სამსახურში აუცილებლად შეხვდებით. ისინი არც ისე ტრივიალურად გამოიყურებიან და აიძულებენ მონაცემთა კონვერტაციას ახალი კუთხით შეხედოთ. ყურადღებით გაითვალისწინეთ წარმოდგენილი მაგალითები და მოგერიდებათ გამოიყენოთ ისინი როგორც ფრაგმენტები რეალური პრობლემების გადაჭრისას.

დავალება ნომერი 1. შეავსეთ გამოტოვებული დეტალები

დავუშვათ, რომ ჩვენ გვჭირდება დირექტორია " კონტრაგენტები". მიმღებს აქვს მსგავსი საცნობარო წიგნი "კლიენტები" ამისათვის. ის სრულიად შესაფერისია მონაცემთა შესანახად, მაგრამ მას აქვს საყრდენი " ორგანიზაცია”, რაც საშუალებას გაძლევთ გამოყოთ კონტრაგენტები ორგანიზაციის კუთვნილებით. ნაგულისხმევად, ყველა კონტრაგენტი უნდა ეკუთვნოდეს მიმდინარე ორგანიზაციას (მისი მიღება შესაძლებელია ამავე სახელწოდების მუდმივიდან).

პრობლემის რამდენიმე გამოსავალი არსებობს. ჩვენ განვიხილავთ რეკვიზიტების შევსების ვარიანტს ” ორგანიზაცია”სწორედ ბაზაზე” მიმღები“, ე.ი. მონაცემთა ჩატვირთვის დროს. მიმდინარე ორგანიზაცია ინახება მუდმივში, ამიტომ არ არსებობს ბარიერი ამ მნიშვნელობის მისაღებად. მოდით გავხსნათ ობიექტის კონვერტაციის წესი (შემდგომში FRP) ” კლიენტები” (ორჯერ დააწკაპუნეთ ობიექტზე) და წესების დაყენების ოსტატში გადადით განყოფილებაში “მოვლენის დამმუშავებლები”. დამმუშავებელთა სიაში ვხვდებით " ჩატვირთვის შემდეგ”.

მოდით აღვწეროთ კოდი მიმდინარე ორგანიზაციის მისაღებად ატრიბუტზე შემდგომი მინიჭებით. „ჩატვირთვის შემდეგ“ დამმუშავებლის გაშვების მომენტში, ობიექტი სრულად ჩამოყალიბდება, მაგრამ ჯერ არ ჩაიწერება მონაცემთა ბაზაში. არავინ გვიკრძალავს მის შეცვლას ჩვენი შეხედულებისამებრ:

თუ NOT Object.ThisGroup, მაშინ Object.Organization = Constants.CurrentOrganization.Get(); Დაასრულე თუ;

რეკვიზიტების შევსებამდე " ორგანიზაცია» აუცილებელია ატრიბუტის მნიშვნელობის შემოწმება « ეს ჯგუფი". მეგზურისთვის" კლიენტები» იერარქიული დროშა დაყენებულია, ამიტომ ჯგუფის შემოწმება აუცილებელია. ანალოგიურად, ნებისმიერი დეტალის შევსება ხორციელდება. დარწმუნდით, რომ წაიკითხეთ დახმარება სხვა დამმუშავებლის ვარიანტებისთვის " ჩატვირთვის შემდეგ". მაგალითად, მათ შორის არის პარამეტრი " უარი". თუ მას მიენიჭება მნიშვნელობა "True", მაშინ ობიექტი არ ჩაიწერება მონაცემთა ბაზაში. ამრიგად, შესაძლებელი ხდება ჩატვირთვის დროს ობიექტების შეზღუდვა ჩასაწერად.

დავალება ნომერი 2. დეტალები საინფორმაციო რეესტრში

სახელმძღვანელოში " კონტრაგენტები"UT კონფიგურაცია, არის დეტალები" მყიდველი"და" პროვაიდერი". ორივე რეკვიზიტი არის ტიპის " ლოგიკური” და გამოიყენება კონტრაგენტის ტიპის დასადგენად. IB-ში" მიმღები”, საცნობარო წიგნში ” კლიენტები„მსგავსი დეტალები არ არსებობს, მაგრამ არის ინფორმაციის რეესტრი“ კლიენტების ტიპები". ის ასრულებს მსგავს ფუნქციას და შეუძლია შეინახოს მრავალი ტეგი ერთი კლიენტისთვის. ჩვენი ამოცანაა დეტალების მნიშვნელობების გადატანა საინფორმაციო რეესტრის ცალკეულ ჩანაწერებში.

სამწუხაროდ, მარტო ვიზუალური საშუალებები აქაც ვერ უმკლავდება. დავიწყოთ მცირედით, შევქმნათ ახალი PCO საინფორმაციო რეესტრისთვის " კლიენტების ტიპები". ნუ ჩამოთვლით არაფერს წყაროდ. უარი თქვით ატვირთვის წესების ავტომატურ შექმნაზე.

შემდეგი ნაბიჯი არის ატვირთვის წესების შექმნა. გადადით შესაბამის ჩანართზე და დააჭირეთ ღილაკს " დამატება". ატვირთვის წესების დამატების ფანჯარაში შეავსეთ:

• შერჩევის მეთოდი. შეცვლა „თვითნებურ ალგორითმზე“;
• კონვერტაციის წესი. აირჩიეთ საინფორმაციო რეესტრი „მომხმარებელთა ტიპები“;
• წესის კოდი (სახელი). ჩვენ ვწერთ მას, როგორც „კლიენტის სახეობების ატვირთვა“;

ახლა თქვენ უნდა დაწეროთ კოდი ასატვირთად მონაცემების შესარჩევად. აქ არის პარამეტრი " მონაცემთა შერჩევა". მასში შეგვიძლია მოვათავსოთ კოლექცია მომზადებული მონაცემთა ნაკრებით. Პარამეტრი " მონაცემთა შერჩევა” შეუძლია მიიღოს სხვადასხვა მნიშვნელობა- შეკითხვის შედეგი, შერჩევა, მნიშვნელობების შეგროვება და ა.შ. ჩვენ ვაკეთებთ მას მნიშვნელობების ცხრილის სახით ორი სვეტით: კლიენტი და კლიენტის ტიპი.

ქვემოთ მოცემულია მოვლენის დამმუშავებლის კოდი " დამუშავებამდე". ის ახდენს პარამეტრის ინიციალიზაციას " მონაცემთა შერჩევა” რასაც მოჰყვება მონაცემების შევსება დირექტორიადან” კონტრაგენტები". აქ ღირს ყურადღება მიაქციოთ სვეტის შევსებას ” კლიენტის ტიპი". "UT"-ში გვაქვს "Boolean" ტიპის მახასიათებლები, ხოლო მიმღებში - ჩამოთვლა.

ამ ეტაპზე მათ სასურველ ტიპამდე ვერ მივიყვანთ (UT-ში არ არის), ამიტომ ამ დროისთვის დავტოვებთ სტრიქონების სახით. თქვენ არ გჭირდებათ ამის გაკეთება, მაგრამ მე დაუყოვნებლივ მინდა გაჩვენოთ, თუ როგორ უნდა გადაიტანოთ წყაროში დაკარგული ტიპი.

DataFetch = NewValueTable(); მონაცემთა შერჩევა.Columns.Add("კლიენტი"); Data Selection.Columns.Add("ClientType"); შერჩევა DataFrom the Directory = Directories.Contractors.Select(); DataFromCatalog.Next()-ის მოპოვებისას ციკლი If FetchingDataFromCatalog.ThisGroup შემდეგ გააგრძელეთ; Დაასრულე თუ; If DataFetchFromCatalog.Buyer მაშინ NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "მყიდველი"; Დაასრულე თუ; If DataFetchFromCatalog.Provider მაშინ NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "მიმწოდებელი"; Დაასრულე თუ; საბოლოო ციკლი;

შეინახეთ მონაცემთა ატვირთვის წესი და დაბრუნდით " ობიექტების კონვერტაციის წესები". დავამატოთ საინფორმაციო რეესტრი“ კლიენტების ტიპები” ქონების კონვერტაციის წესები: კლიენტი და კლიენტის ტიპი. წყაროს ცარიელი ვტოვებთ და ღონისძიების „განტვირთვამდე“ ვწერთ:

//„კლიენტი“ თვისებისთვის Value = Source.Client; //„CustomerType“ თვისებისთვის If Source.Customer = "Buyer" Then Expression = "Enumerations.CustomerTypes.Buyer" ElseIf Source.Customer = "Supplier" then Expression = "Enumerations.CustomerTypes.Supplier"; Დაასრულე თუ;

ჩამონათვალში დეტალები ივსება გაკეთებული მონაცემების შერჩევის საფუძველზე. ჩვენ კლიენტს გადავცემთ უბრალოდ ბმულის სახით და ვწერთ კლიენტის ტიპს პარამეტრში " გამოხატულება". ამ პარამეტრის მონაცემები ინტერპრეტირებული იქნება მიმღებში და შესრულებისას ატრიბუტი შეივსება სწორი მნიშვნელობით ჩამოთვლიდან.

ესე იგი, გაცვლის წესები მზადაა, განხილული მაგალითი საკმაოდ უნივერსალური აღმოჩნდა. მსგავსი მიდგომა ხშირად გამოიყენება 7.7 პლატფორმაზე შექმნილი კონფიგურაციებიდან მონაცემების გადაცემისას. ამის ნათელი მაგალითია პერიოდული დეტალების გადაცემა.

დავალება ნომერი 3. ტაბულური ხრიკები

ხშირად არის დავალებები, რომლებიც მოითხოვს ერთი ცხრილის ნაწილის რიგების რამდენიმე ნაწილად განთავსებას. მაგალითად, საწყის კონფიგურაციაში სერვისები და საქონელი რეგისტრირებულია ერთ ცხრილის განყოფილებაში, ხოლო ამ ერთეულების შენახვა გამოყოფილია მიმღებში. ისევ და ისევ, პრობლემა ვერ მოგვარდება ვიზუალური საშუალებებით. აქ მოსახერხებელია მეორე პრობლემის გადაწყვეტის საფუძველი.

ჩვენ ვქმნით მონაცემთა ატვირთვის წესს, ვაზუსტებთ თვითნებურ ალგორითმს და ვწერთ შეკითხვას "ატვირთვამდე" დამმუშავებელში, რათა მივიღოთ მონაცემები ცხრილის განყოფილებიდან.

სივრცის დაზოგვის მიზნით, მე არ მივცემ მოთხოვნის კოდს (ყოველთვის შეგიძლიათ მიმართოთ წყაროს კოდს) - მასში უჩვეულო არაფერია. ჩვენ ვახარისხებთ მიღებულ ნიმუშს და ვათავსებთ დახარისხებულ შედეგებს უკვე ნაცნობ პარამეტრში. მონაცემთა შერჩევა". კიდევ ერთხელ, მოსახერხებელია ღირებულებების ცხრილის გამოყენება, როგორც კოლექცია:

DataFetch = NewValueTable(); //აქ იქნება კიდევ ერთი ცხრილის განყოფილება Data Selection.Columns.Add("პროდუქტები"); //აქ ასევე იქნება ცხრილის განყოფილება Data Selection.Columns.Add("სერვისები"); მონაცემების შერჩევა.Columns.Add(„ბმული“);

დავალება ნომერი 4. მონაცემთა გადაცემა ოპერაციაზე

თუ ორგანიზაცია იყენებს რამდენიმე სააღრიცხვო სისტემას, მაშინ ადრე თუ გვიან საჭირო იქნება მონაცემთა მიგრაცია შემდგომი განცხადებების ფორმირებით.

კონფიგურაციაში " BP"არსებობს უნივერსალური დოკუმენტი" Ოპერაცია”და იდეალურია მეტი მავთულის ჩამოსაყალიბებლად. აქ მხოლოდ ერთი პრობლემაა - დოკუმენტი ეშმაკურად არის შედგენილი და მასში მონაცემების გადატანა არც ისე ადვილია.

ასეთი კონვერტაციის მაგალითი შეგიძლიათ იხილოთ სტატიის საწყის კოდში. კოდის რაოდენობა საკმაოდ დიდი აღმოჩნდა, ამიტომ სტატიისთვის მის გამოქვეყნებას აზრი არ აქვს. მხოლოდ იმას ვიტყვი, რომ ატვირთვა ისევ იყენებს თვითნებურ ალგორითმს მონაცემთა ატვირთვის წესებში.

დავალება ნომერი 5. მონაცემთა სინქრონიზაცია მრავალი ატრიბუტით

ჩვენ უკვე განვიხილეთ რამდენიმე მაგალითი, მაგრამ ჯერჯერობით არ გვისაუბრია ობიექტის სინქრონიზაციაზე მიგრაციის დროს. წარმოვიდგინოთ, რომ ჩვენ გვჭირდება კონტრაგენტების გადაცემა და ზოგიერთი მათგანი ალბათ მიმღების მონაცემთა ბაზაშია. როგორ გადავიტანოთ მონაცემები და თავიდან აიცილოთ დუბლიკატები? ამასთან დაკავშირებით, CD გთავაზობთ რამდენიმე გზას გადაცემული ობიექტების სინქრონიზაციისთვის.

პირველი არის უნიკალური იდენტიფიკატორით. ბევრ ობიექტს აქვს უნიკალური იდენტიფიკატორი, რომელიც უზრუნველყოფს ცხრილის უნიკალურობას. მაგალითად, სახელმძღვანელოში " კონტრაგენტები” არ შეიძლება ჰქონდეს ორი ელემენტი იგივე ID-ით. CD აკეთებს გამოთვლას ამისათვის და ყველა შექმნილი PSP-ისთვის, იდენტიფიკატორის მიხედვით ძიება დაუყოვნებლივ ჩართულია ნაგულისხმევად. PSP-ის შექმნისას თქვენ უნდა შეემჩნიათ გამადიდებელი შუშის ხატი ობიექტის სახელთან.

უნიკალური იდენტიფიკატორით სინქრონიზაცია საიმედო მეთოდია, მაგრამ ის ყოველთვის არ არის მიზანშეწონილი. დირექტორიების შერწყმისას " კონტრაგენტები” (რამდენიმე სხვადასხვა სისტემიდან) მას მცირე დახმარება აქვს.

ასეთ შემთხვევებში უფრო სწორია ობიექტების სინქრონიზაცია რამდენიმე კრიტერიუმის მიხედვით. უფრო სწორია კონტრაგენტების მოძიება TIN-ის, KPP-ის, დასახელების მიხედვით ან ძიების რამდენიმე ეტაპად გაყოფა.

მონაცემთა კონვერტაცია არ ზღუდავს დეველოპერს საძიებო კრიტერიუმების განსაზღვრაში. განვიხილოთ აბსტრაქტული მაგალითი. დავუშვათ, რომ ჩვენ გვჭირდება დირექტორიების სინქრონიზაცია " კონტრაგენტები“ სხვადასხვა საინფორმაციო ბაზებიდან. მოდით მოვამზადოთ PCP და ობიექტის კონვერტაციის წესების პარამეტრებში, მონიშნეთ ყუთი ” განაგრძეთ საძიებო ველების ძებნა, თუ მიმღების ობიექტი ID-ით ვერ მოიძებნა". ამ მოქმედებით ჩვენ დაუყოვნებლივ განვსაზღვრეთ ძიების ორი კრიტერიუმი - უნიკალური იდენტიფიკატორით და თვითნებური ველებით.

ჩვენ გვაქვს უფლება თავად ავირჩიოთ სფეროები. TIN, KPP, სახელის აღნიშვნის შემდეგ, ჩვენ დაუყოვნებლივ მივუთითებთ ძიების რამდენიმე კრიტერიუმს. კომფორტული? საკმაოდ, მაგრამ კიდევ ერთხელ, ეს საკმარისი არ არის. და რა მოხდება, თუ გვინდა ძიების კრიტერიუმების შეცვლა? მაგალითად, ჯერ ვეძებთ TIN + KPP-ის თაიგულს და თუ ვერაფერს ვიპოვით, მაშინ ვიწყებთ ბედის ცდას სახელით.

ასეთი ალგორითმის განხორციელება სავსებით შესაძლებელია. ღონისძიების დამმუშავებელში საძიებო ველებიჩვენ შეგვიძლია განვსაზღვროთ ძიების 10-მდე კრიტერიუმი და თითოეული მათგანისთვის განვსაზღვროთ საძიებო ველების საკუთარი შემადგენლობა:

თუ SearchOptionNumber = 1, მაშინ SearchPropertyNameString = “TIN, KPP”; ElseIfSearchVariantNumber = 2 ThenSearchPropertyNameString = „Name“; Დაასრულე თუ;

ყოველთვის არის მრავალი გამოსავალი.

ნებისმიერ ამოცანას აქვს რამდენიმე გამოსავალი და მონაცემთა გადაცემა სხვადასხვა კონფიგურაციას შორის არ არის გამონაკლისი. თითოეულ დეველოპერს აქვს უფლება აირჩიოს საკუთარი გადაწყვეტის გზა, მაგრამ თუ თქვენ მუდმივად გიწევთ მონაცემთა რთული მიგრაციის განვითარება, მაშინ გირჩევთ, ყურადღება მიაქციოთ "" კონფიგურაციას. დაე, თავიდან მოგიწიოთ რესურსების (დროის) ინვესტიცია ტრენინგში, მაგრამ ისინი უფრო მეტს გადაიხდიან პირველ მეტ-ნაკლებად სერიოზულ პროექტზე.

ჩემი აზრით, 1C კომპანია დაუმსახურებლად გვერდს უვლის მონაცემთა კონვერტაციის გამოყენების თემას. ტექნოლოგიის არსებობის მთელი პერიოდის განმავლობაში მასზე მხოლოდ ერთი წიგნი გამოიცა: „1C: Enterprise 8. მონაცემთა კონვერტაცია: გაცვლა აპლიკაციის გადაწყვეტილებებს შორის“. წიგნი საკმაოდ ძველია (2008), მაგრამ მაინც სასურველია მისი გაცნობა.

პლატფორმის ცოდნა ჯერ კიდევ საჭიროა

» არის უნივერსალური ინსტრუმენტი, მაგრამ თუ თქვენ აპირებთ მის გამოყენებას მონაცემთა მიგრაციის შესაქმნელად 1C:Enterprise 7.7 პლატფორმისთვის შემუშავებული კონფიგურაციებიდან, მაშინ მოგიწევთ დროის დახარჯვა ჩაშენებული ენის გასაცნობად. ენის სინტაქსი და იდეოლოგია ძალიან განსხვავებულია, ამიტომ დრო უნდა დახარჯო სწავლაზე. დანარჩენი პრინციპი იგივე რჩება.

მოვლენის დამმუშავებლის მექანიზმი არის მონაცემთა კონვერტაციის ერთ-ერთი მთავარი ტექნოლოგია "მონაცემთა კონვერტაცია 2.0"-ის გამოყენებით. ამ მექანიზმის კომპეტენტური და ოსტატურად გამოყენება დეველოპერს საშუალებას აძლევს სწრაფად გადაჭრას მონაცემთა კონვერტაციის თითქმის ნებისმიერი ამოცანა. პროცესორის ტექნოლოგიის დახმარებით, მონაცემთა შერჩევა, მონაცემთა კონვერტაცია ადვილად ხორციელდება განსხვავებული ტიპები, მონაცემთა რთული შერჩევა, კონვერტაციის პარამეტრები და მრავალი სხვა დავალება.

განვიხილოთ ამ ტექნოლოგიის ძირითადი პრინციპები. უნივერსალური გაცვლის დამუშავებისას მონაცემთა გადმოტვირთვისა და ჩატვირთვის ალგორითმების საკვანძო პუნქტებში შესაძლებელია მონაცემთა გაცვლის წესებიდან აღებული პროგრამის კოდის შესრულება და არა "მყარი" მონაცემების გადმოტვირთვის ან ჩატვირთვის დამუშავებისას. "Data Conversion 2.0" კონფიგურაცია იძლევა შესაძლებლობას მონაცემთა გაცვლის წესებში ასეთი პროგრამის კოდის ინტეგრირება.

საერთო ჯამში, მონაცემთა გაცვლის ალგორითმებში ოცზე მეტი განსხვავებული ადგილია, სადაც მესამე მხარის კოდი შეიძლება შესრულდეს. შესაბამისად, კონფიგურაცია ითვალისწინებს სხვადასხვა ტიპის მოვლენის დამმუშავებლების შექმნას.

მოვლენის დამმუშავებლების კოდი "მიმაგრებულია" გაცვლის წესების ობიექტებზე - დირექტორიების ელემენტებზე: კონვერტაციები, ობიექტების კონვერტაციის წესები, ქონების კონვერტაციის წესები, მონაცემთა ატვირთვის წესები და მონაცემთა გაწმენდის წესები. ბუნებრივია, მოვლენის დამმუშავებლის კოდი უნდა აკმაყოფილებდეს უამრავ მოთხოვნას. კერძოდ, დამმუშავებლის კოდში კონვერტაციის პროცესის გასაკონტროლებლად აუცილებელია სპეციალური ცვლადების - პარამეტრების გამოყენება. ყველა ტიპის ღონისძიების დამმუშავებლისა და ხელმისაწვდომი ცვლადების სრული აღწერა შეგიძლიათ იხილოთ დამმუშავებლების შესახებ ინფორმაციას შესაბამის ფორმებში.

ყურადღება!!!

მონაცემთა კონვერტაციის 2.0 ტექნოლოგიები იძლევა მონაცემთა გაცვლას 1C:Enterprise 7.7 და 1C:Enterprise 8.0 პლატფორმებზე დანერგილ ინფობაზებთან. 1C:Enterprise 7.7 პლატფორმის ფუნქციონირების თავისებურებებიდან გამომდინარე, მონაცემთა გაცვლის წესების მომზადებას ამ პლატფორმაზე განხორციელებული ინფობაზებისთვის ღონისძიებების დამმუშავებლების გამოყენებით, აქვს მრავალი მახასიათებელი.

1C:Enterprise 7.7 პლატფორმისთვის შეუძლებელია თვითნებური კოდის შესრულება (ანალოგური Run ფუნქცია V8-ისთვის). თუ საჭიროა V7.7 პლატფორმისთვის მოვლენის დამმუშავებლების გამოყენება, საჭიროა მონაცემთა ატვირთვის ან ჩამოტვირთვის დამუშავების ტექსტის ჩანაცვლება იმ დამუშავების ტექსტებით, რომლებსაც აწარმოებს "Data Conversion 2.0" კონფიგურაცია.

თუ გჭირდებათ მონაცემების გადატანა V7.7-დან V8-მდე, მაშინ:

გადმოტვირთვისას, წესების ფაილის გარდა, სისტემა აგენერირებს მოდულის ტექსტს V77Exp.ert-ის დასამუშავებლად ფუნქციებით, რომლებიც ახორციელებენ მოვლენის დამმუშავებლებს. შემდეგ, კონფიგურატორში, ჩვენ უნდა შევცვალოთ სტანდარტული V77Exp.ert მოდული ახლით, რომელიც გენერირებულია "Data Conversion 2.0".

მონაცემთა გაცვლის გადაწყვეტილებების შემუშავებისას 1C:Enterprise 7.7 პლატფორმაზე, თქვენ უნდა გახსოვდეთ ეს მნიშვნელოვანი "წვრილმანი". თქვენი წესები სწორად იმუშავებს მხოლოდ იმ შემთხვევაში, თუ იყენებთ შეცვლილ დამუშავებას, რომლის მოდულის ტექსტი შეიქმნა მონაცემთა გაცვლის წესების გადმოტვირთვისას. ამ წესს აქვს ერთი გამონაკლისი - თუ არ იყენებთ მოვლენის დამმუშავებლებს, მაშინ შეგიძლიათ გამოიყენოთ სტანდარტული დამუშავება.

პატივისცემით, ვლადიმერ მილკინი(მასწავლებელი და დეველოპერი).