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

1C 8.3 და 8.2 მოვლენის გამოწერა არის კონფიგურაციის ობიექტი, რომელიც საშუალებას გაძლევთ დაავალოთ დამმუშავებელი კონკრეტული ობიექტის მოვლენას. ასეთი დამმუშავებელი შეიძლება მიენიჭოს ერთდროულად რამდენიმე კონფიგურაციის ობიექტს, მაგალითად, ერთდროულად ყველა დოკუმენტს.

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

• ახალი ნომრის დაყენებისას
• კოპირებისას
• დამუშავების შევსება
• ჩაწერამდე
• ჩაწერისას
• წაშლამდე
• დამუშავების ჩატარება
• დამუშავება მოცილება მიმდინარეობს
• დამუშავება შემოწმების შევსება

შეგიძლიათ გამოიწეროთ ღონისძიება მხოლოდ ობიექტზე და არა ფორმაზე.

დამმუშავებლების გამოძახების წესი 1C 8-ში

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

მიიღეთ 267 ვიდეო გაკვეთილი 1C-ზე უფასოდ:

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

ღონისძიების გამოწერების გამოყენება 1C-ში

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

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

ღონისძიების გამოწერის დაყენება

გამოწერის დაყენება ძალიან მარტივია:

• წყარო— მონაცემთა ტიპები, რომლებზეც დაყენებულია დამმუშავებელი;
• ღონისძიება— მოვლენა, რომლისთვისაც დაყენებულია დამმუშავებელი;
• დამმუშავებელი— მიუთითებს პროცედურაზე, საიდანაც განთავსდება მოვლენის დამმუშავებელი.

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

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

სტანდარტული ქცევა

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

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

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

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

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

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

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

დაუსაბუთებელი მხარე

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

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

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

უკან დახევა

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

როდესაც მომხმარებელი დააჭერს ღილაკს, იხსნება ან იხურება ფორმა, იწერება დოკუმენტი, ხდება მოვლენა.

თითოეული დოკუმენტის ჩაწერამდე გვინდა შევამოწმოთ, რომ ეს დეტალი შევსებულია.

Როგორ გავაკეთო ეს?

გამოწერები 1C ღონისძიებებზე

1C მოვლენების გამოწერა არის , ის მდებარეობს General/Subscriptions to 1C events კონფიგურაციის ფილიალში.

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

მოდით დავამატოთ ახალი გამოწერა 1C ღონისძიებას და დავაყენოთ სახელი.

1C მოვლენის გამოწერის თვისებაში Source - თქვენ უნდა აირჩიოთ ერთი ან მეტი დოკუმენტი, დირექტორიები - ობიექტები, რომლებზეც ჩვენ ვათავსებთ დამმუშავებელს.

1C Event გამოწერის თვისებაში, თქვენ უნდა აირჩიოთ სტანდარტული მოვლენების ერთ-ერთი ვარიანტი, რომელიც შეიძლება მოხდეს არჩეულ დოკუმენტებთან და დირექტორიაებთან.

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

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

ამის შემდეგ რჩება მხოლოდ დამმუშავებლის ფუნქციის შექმნა. ამისათვის კონფიგურაციას უნდა ჰქონდეს სერვერის ჩამრთველი თვისებებში. როდესაც დააჭირეთ ღილაკს "გამადიდებელი შუშა", შეიქმნება ფუნქცია - დამმუშავებელი.

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

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

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

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

• ხელმოწერების დაყენება;
• შემოქმედება;
• ფუნქციონირების მახასიათებლები.

შექმენით ახალი გამოწერა

ნებისმიერი სხვა მეტამონაცემების ობიექტის მსგავსად, 1C-ში მოვლენის გამოწერა ემატება კონფიგურატორიდან.

ეს ელემენტები განლაგებულია "ზოგადი" ხის ტოტში (ნახ. 1).

ახალი დამმუშავებლის დასამატებლად საჭიროა:

ნახ.3

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

ხელმოწერების ფუნქციონირების მახასიათებლები

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

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

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

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

ამრიგად, დამუშავების თანმიმდევრობა შეიძლება განისაზღვროს შემდეგნაირად:

1. ობიექტის მოდულის მოვლენები დამუშავებულია;
2. მუშავდება ხელმოწერები, რომლებიც დაკავშირებულია უშუალოდ მონაცემთა მიმდინარე ტიპთან;
3. მუშავდება ზოგადი ტიპით მიბმული კოდი.

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

ფორმა ღია მოვლენის დამმუშავებელი

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

ამ დამმუშავებლის ზოგიერთი მახასიათებელი:

• ღონისძიება არ ირთვება, თუ გასახსნელი სტანდარტული ფორმა მკაცრად არის მითითებული კონფიგურაციაში;
• ღონისძიების განხორციელება შესაძლებელია მხოლოდ მართული ფორმებისთვის;
• ამ დამმუშავებლის შემცველ ზოგად მოდულს არ უნდა ჰქონდეს მხოლოდ „სერვერის“ ატრიბუტი, არამედ უნდა შეიცავდეს მონიშნულ ველს „ზარის სერვერის“ ველში.

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

ნახ.4

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