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

ძალიან ხშირად მესმის კითხვები:

• როგორ ვნახოთ ვინ შეცვალა დოკუმენტი 1C 8.2-ში?
• როგორ ვნახოთ ვინ შეცვალა დოკუმენტი 1C-ში?
• როგორ გავარკვიოთ 1C-ში ვინ შეცვალა დოკუმენტები და როდის?
• როგორ გავარკვიოთ 1C-ში ვინ შეცვალა განთავსება დოკუმენტში?
• როგორ ვნახოთ ვინ შეცვალა დოკუმენტი 1C-ში?

ჟურნალი

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

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

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

ჟურნალის ტიპი(რეგულარული ფორმები და ტაქსი):

შერჩევა ჟურნალის წიგნში(რეგულარული ფორმები და ტაქსი):

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

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

სად ინახება ჟურნალის წიგნი?

ფაილების მონაცემთა ბაზაში:საქაღალდე მონაცემთა ბაზის დირექტორიაში 1Cv8Log -ეს არის დირექტორია, რომელიც შეიცავს ჟურნალს.

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

INკლიენტ-სერვერის მონაცემთა ბაზა: C:\Program Files\1cv8\srvinfo\<Имя кластера сервера>\<Идентификатор базы на сервере>\1Cv8Log

8.3.5.1068 ვერსიიდან. ჟურნალი მნიშვნელოვნად გადამუშავდა, რათა გაზარდოს ჟურნალში მოთხოვნების შესრულების სიჩქარე და გაზარდოს მონაცემთა შენახვის საიმედოობა.

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

ობიექტების ვერსია

ზოგიერთ კონფიგურაციაში დანერგილია 1C სპეციალური მექანიზმი"ობიექტების ვერსია".

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

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

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

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

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

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

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

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

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

რამდენი დრო დასჭირდება იმ მიზეზის პოვნას, ვინც რა შეცვალა? რამდენი შედარება გჭირდებათ, როცა, ვთქვათ, ისტორია ინახავს, ​​რომ დოკუმენტი 30-100-ჯერ შეიცვალა? მაგრამ მარტივი ჩანაწერი დოკუმენტების ჯგუფური განთავსების დროს დაამატებს ცვლილებების ვერსიას აქ, მაგრამ სინამდვილეში არაფერი შეიცვლება დოკუმენტში ასეთი ხელახალი გამოქვეყნებით. ზოგადად, ცვლილებების ამ რაოდენობის ვერსიიდან მოქმედი იქნება მაქსიმუმ 2-3-5. და რაც შეეხება დანარჩენს? და ეს ზედმეტი ნაგავია.

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

როგორ გადავაქციოთ ეს სწრაფ ინსტრუმენტად პასუხის საპოვნელად, ვინ რა შეცვალა?

"უთხარი ჩემს პატარა სარკეს, მითხარი მთელი სიმართლე"...

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

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

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

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

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

"ვისი ფეხსაცმელი?"

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

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

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

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

ანგარიშის შეცვლა

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

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

ოპერატორის ანაზღაურება

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

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

დეტალები

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

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

ეს დამუშავებამუშაობს UPP 1.3, UT10.3 კონფიგურაციებში. ის ასევე შეიძლება იყოს ინტეგრირებული ნებისმიერ 1C კონფიგურაციაში, სადაც არის საწყობი და წარმოების აღრიცხვა. მუშაობს ჩვეულებრივ ფორმებზე.

დასკვნა

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

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

განხორციელებული ვერსია 8.3.11.2867.

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

რა სცენარებშია საჭირო მონაცემთა ისტორიასთან მუშაობა?

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

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

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

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

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

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

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

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

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

ისტორიის ანალიზის რა შესაძლებლობები უკვე არსებობს პლატფორმაზე?

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

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

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

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

პლატფორმაში ჩაშენებული გადაწყვეტის უპირატესობები

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

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

ძირითადი ინფორმაცია მექანიზმის შესახებ

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

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

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

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

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

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

მონაცემთა ცვლილებების მართვა

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

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

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

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

Მომხმარებლის ინტერფეისი

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

კონკრეტული ობიექტის ვერსიების სია

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

ის საშუალებას გაძლევთ ნახოთ ობიექტის ყველა ცვლილების (ვერსიის) სია.

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

ამ სიაში, სვეტში

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

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

ჟურნალის წიგნში წვდომა შესაძლებელია როგორც Enterprise რეჟიმში (მენიუ ყველა ფუნქცია ⇒ სტანდარტული ⇒ ჟურნალიდა კონფიგურატორის რეჟიმში ( ადმინისტრაცია ⇒ ჟურნალი):

თუ Enterprise რეჟიმში არ არის მენიუს ელემენტი " ყველა ფუნქცია", მაშინ უნდა ჩართოთ მისი ჩვენება:

ყურადღება!

მომხმარებელს უნდა ჰქონდეს საკმარისი უფლებები ყველა ფუნქციის მენიუსა და ჟურნალში წვდომისთვის.

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

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

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

3. გააანალიზეთ ინფორმაცია:

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

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

• ამისთვის ფაილის მონაცემთა ბაზები— [IS დირექტორია]\1Cv8Log;
• სერვერის მონაცემთა ბაზებისთვის - [კლასტერული სერვისის ფაილების დირექტორია]\[ინსტრუმენტების უსაფრთხოების დირექტორია]\1Cv8Log.

შენახვა შეიძლება განხორციელდეს ორ ფორმატში:

• Ფაილის ფორმატი .ლგდ— SQLite ფორმატის მონაცემთა ბაზა;
• Ფაილის ფორმატი .lgfდა .lgp- რეგულარული ტექსტური ფაილები.

.lgd ფორმატი უფრო თანამედროვეა, ყველა ახალი მონაცემთა ბაზა, დაწყებული გამოშვებით 8.3.5, ინახავს ჟურნალის მონაცემებს ამ ფორმატში.

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

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

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

რამდენად ხშირად სჭირდება თქვენს კომპანიას შეხედე ვინ შეცვალა 1C დოკუმენტი?

ან როგორ გავარკვიოთ რომელმა თანამშრომელმა შეცვალა ესა თუ ის ატრიბუტიდოკუმენტი 1s 8?

როგორ ვუყუროთ დოკუმენტის ცვლილებების ისტორია 1C?

მოდული "ცვლილებების ისტორია" დაფუძნებული 1C 8-ზე

მოსახერხებელი და ეფექტური ხელსაწყოანალიზი და კონტროლი 1C მომხმარებლების ქმედებები.

მოდულის მიერ მოგვარებული პრობლემები "ცვლილებების ისტორია" 1C 8:

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

მექანიზმის დადებითი მხარეები "ცვლილებების ისტორია" 1C 8:

• ყველა მონაცემი ინახება 1C მონაცემთა ბაზაში, რაც უზრუნველყოფს მაღალი სიჩქარეძებნასაჭირო ინფორმაცია და საჭირო ანგარიშების შედგენა.
• მოდული 1C 8 "ცვლილებების ისტორია" აქვს მინიმალური გავლენა შესრულებაზე. ჩვენს ქვესისტემასთან და მის გარეშე მუშაობისას ძნელად იგრძნობთ განსხვავებას.
• მოდული უნივერსალურიდა ადვილად ინტეგრირებანებისმიერ, თუნდაც სტანდარტულ, სისტემაზე დაფუძნებულ კონფიგურაციაში « 1C: საწარმო"ვერსიები 8.2 და ვერსიები 8.3 ვერსიის ჩათვლით.

მოდულის შესაძლებლობები:

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

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

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

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

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

ჟურნალი 1C 8.

როგორ გავარკვიოთ ვინ შეცვალა 1C დოკუმენტი?

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

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

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

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

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

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