1c საწარმოს გადასინჯვა

გჭირდებათ 1C ფუნქციონირების გაფართოება? გჭირდებათ პროგრამა თქვენი საწარმოს არა მხოლოდ ტიპიური, არამედ კონკრეტული ამოცანების გადასაჭრელად? "Active-IT" გაუმჯობესების სერვისი 1C დაგეხმარებათ ამ საკითხების სწრაფად მოგვარებაში.

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

შემობრუნების დრო- 5 დღემდე. 10 დღემდე დაგვიანების შემთხვევაში, ჩვენ ვაკეთებთ გადახედვას თქვენთვის უფასოდ.

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

1C პროგრამისტის მუშაობის ღირებულება

კონფიგურაციის გადამუშავების ღირებულება: 1500 რუბლი პროგრამისტის მუშაობის საათში.

შედეგად, თქვენ მიიღებთ:

  • გამოცდილ პროგრამისტებთან თანამშრომლობა.
  • აბსოლუტურად ნებისმიერი დონის სირთულის გაუმჯობესების შექმნა და განხორციელება.
  • სამუშაოების შესრულება რაც შეიძლება მალე- 5 დღემდე.
  • ფულის დაბრუნების გარანტია დროის დაგვიანების შემთხვევაში.
  • Ხარისხის გარანტია.

შეუკვეთეთ გაუმჯობესება 1C ბუღალტერია "Aktiv-IT"-დან!
დააკონფიგურირეთ 1C მუშაობა თქვენი საწარმოს სპეციფიკისთვის ჩვენთან ერთად.

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

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

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

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

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

შეცვლილი კონფიგურაციის უპირატესობები

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

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

  1. უპირველეს ყოვლისა, პროგრამული უზრუნველყოფის გადაწყვეტა ადაპტირდება ორგანიზაციის კონკრეტული აღრიცხვის მოთხოვნებთან.
  2. ახლად შემუშავებული და მომხმარებელთა უფლებებისა და როლების კონფიგურაციის სტრუქტურაში დანერგვის წყალობით, შესაძლებელია უფრო მოქნილად აღწეროთ ნებადართული და აკრძალული ქმედებები ერთი ან თანამშრომელთა ჯგუფის დოკუმენტებთან და დირექტორიებთან მუშაობისას.
  3. მომხმარებლის ინტერფეისების კონფიგურაცია და შეცვლა (მართული პროგრამებისთვის, ბევრი რამ ხორციელდება რეგულარულად).
  4. დოკუმენტების, ფორმებისა და ანგარიშების ნაბეჭდი ფორმების შეცვლის უნარი.
  5. შიდა პროგრამული უზრუნველყოფის გამოთვლების მექანიზმების შეცვლა, რთული გამოთვლების შექმნა, წარმოების ფორმულები, დოკუმენტების რთული სფეროები და ა.შ.
  6. შეცვლის შესაძლებლობა გარეგნობადოკუმენტები, დოკუმენტების ჟურნალები, მომხმარებლის რეგისტრები, დირექტორიის ელემენტები.
  7. ობიექტების ვიზუალური წარმოდგენის დამატების უნარი.

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

კონფიგურაციის გადამუშავების უარყოფითი მხარეები

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

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

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

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

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

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

რა არის ყველაზე ხშირი გაუმჯობესება 1C– ში?

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

მოდიფიკაციების მაგალითები 1C

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


სპეციალისტების მომსახურების ღირებულება 1C– სთან მუშაობისთვის

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

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

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

პრობლემა

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

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

დოკუმენტაცია, ინსტრუმენტები

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

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

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

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

კონფიგურაცია

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

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

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

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

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

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

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

გარე ბეჭდვის ფირფიტები

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

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

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

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

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

განსაკუთრებული ყურადღება უნდა მიექცეს შემდეგ თვისებებს:

  • დავალებების მასივი. შეიცავს მეტამონაცემების ობიექტების სახელს, რომლებისთვისაც დასაბეჭდი დარეგისტრირდება. დასაშვებია ობიექტების დაზუსტების რამდენიმე ვარიანტი: "დოკუმენტი. ფულადი შეკვეთის მიღება", "დოკუმენტი. *". ბოლო ჩანაწერი მოიცავს სისტემაში არსებულ ყველა დოკუმენტს.
  • ნახვა. განსაზღვრავს გარე დამუშავების ტიპს. სხვადასხვა სახის მკურნალობა ჩაწერილია სხვადასხვა გზით. ფორმების დასაბეჭდად ჩვენ ვნიშნავთ "ბეჭდვის ფორმას", დანარჩენი ხელმისაწვდომი ტიპები მოცემულია კომენტარებში.
  • სახელი. მკურნალობის სახელწოდება სისტემაში.
  • იდენტიფიკატორი. გამოიყენება რამოდენიმე ადგილას, რეკომენდებულია მნიშვნელოვანი სახელის მიცემა. ყველაზე ხშირად, დამუშავების სახელი აქ არის მითითებული, მაგალითად: "RogaICOexperience_Mayout of the cash order".
  • მოდიფიკატორი. თუ ცხრილების დოკუმენტი გამოიყენება როგორც განლაგება, მაშინ ჩვენ ვაჩვენებთ "PrintXML".

Პროცედურა " ბეჭედი»ასრულებს მომსახურების როლს და მას უწოდებენ სისტემის ჩამონტაჟებული მექანიზმები. უმეტეს შემთხვევაში, მისი შინაარსი უცვლელი რჩება, გარდა ზარის პარამეტრებისა "DisplayTableDocumentInCollection" (იხ. პროცედურის ძირითადი ნაწილი).

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

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

  • სახელი ბეჭდვის პარამეტრების შესანახად. უფრო ხშირად ისინი იყენებენ შაბლონს: "PRINT_PARAMETERS_PrintName".
  • განლაგება GetLayout მეთოდი მოითხოვს თქვენ მიუთითოთ სახელი განლაგებისათვის.

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

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

შევსების დამუშავება

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

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

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

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

რეგისტრაციის პარამეტრები = დამატებითი ანგარიშები ANDProcessing.ExternalProcessing information ("2.1.2.1"); რეგისტრაციის Parameters.View = AdditionalReportAndProcessingClientServer.ProcessingViewFillingObject (); რეგისტრაციის პარამეტრები. დანიშვნა. დამატება ("Document.ContinsurancePolis"); რეგისტრაციის პარამეტრები. სახელი = НСтр ("ru =" მოთხოვნების გადაწყვეტის მეთოდების შევსება ""); რეგისტრაციის პარამეტრები.SafeMode = მცდარი; RegistrationParameters.Information = "აჩვენებს შევსების სახელურების შექმნის მექანიზმს"; რეგისტრაციის პარამეტრები. ვერსია = "1.0.1"; NewCommand = RegistrationParameters.Commands.Add (); NewCommand.Presentation = НСтр ("ru =" შეავსეთ მოთხოვნების გადაწყვეტის მეთოდები ""); NewCommand.Identifier = "FillLoss SettlementWays"; NewCommand.Usage = AdditionalReportAndProcessingClientServer.CommandTypeFormOpening (); დაბრუნების რეგისტრაციის პარამეტრები;

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

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

  • ობიექტების მინიჭება (თვითნებური) - მითითებების მასივი ობიექტების შესავსებად.
  • იდენტიფიკატორი (სიმებიანი) - ბრძანების იდენტიფიკატორი.
  • დამატებითი დამუშავების ბმული (ReferenceRef.AdditionalReports andProcessing).

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

სტანდარტული ფორმების მოდერნიზაცია

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

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

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

ახალი გაფართოებები იქმნება კონფიგურატორში გაფართოების მენეჯერის გამოყენებით ("კონფიგურაცია" -> "კონფიგურაციის გაფართოებები"). მენეჯერის ფანჯარაში ნაჩვენებია ყველა დაინსტალირებული გაფართოება (იხ. სურათი 3) და ინტერფეისი ახლის შესაქმნელად.

ახალი გაფართოების შესაქმნელად დააჭირეთ ღილაკს "დამატება" და შეავსეთ ველები ფანჯარაში, რომელიც გამოჩნდება (სურათი 4):

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

დააწკაპუნეთ „Ok“ - ზე და დამატებითი კონფიგურაციის ხე გამოჩნდება თქვენს თვალწინ (სურათი 5).

გაფართოების კონფიგურაციის ხეზე მუშაობის პრინციპი დიდად არ განსხვავდება სტანდარტული კონფიგურაციის ხეზე მუშაობისგან. საინფორმაციო ბაზა... განსხვავება მდგომარეობს შეზღუდვებში (http://its.1c.ru/db/v839doc#bookmark:dev:TI000001513).

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

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

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

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

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

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

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

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

გაფართოების იდეები

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

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

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

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

კიდევ რისი გაკეთება შეუძლია გაფართოებებს?

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

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

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

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

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

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

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

ღონისძიების ხელმოწერები

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

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

ფორმების პროგრამული შევსება

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

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

როლის მოდიფიკაცია

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

იდეალურ შემთხვევაში, შეეცადეთ როლები მაქსიმალურად გაყოთ. გამოყავით როლები დოკუმენტების / დირექტორიების კითხვისა და წერისთვის, ნუ აერთიანებთ უფლებებს ერთ როლში. რასაკვირველია, თქვენ არ უნდა გააკეთოთ ეს ყოველი კონფიგურაციის დოკუმენტისთვის / მითითებისთვის, მაგრამ ეს უნდა გაკეთდეს მინიმუმ ობიექტების ჯგუფებისთვის. განვიხილოთ მაგალითი - " ფულადი დოკუმენტები". ეს მოიცავს მინიმუმ "PKO" და "RKO". ეს აადვილებს უსაფრთხოების მოქნილი პროფილების (FSP) შექმნას.

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

არ დაიზაროთ

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

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

აბა, ყველას, კეთილი იყოს თქვენი მობრძანება კატის ქვეშ.

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

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

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

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

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

ტიპიური კონფიგურაციებში მოდიფიკაციების დიზაინის 9 მარტივი წესი

1. ტიპიური კონფიგურაციის "განადგურების" მინიმიზაციის კონცეფცია

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

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

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

მეორე წესი არის ის, რომ ლ კოდის ნებისმიერი ცვლილება უნდა იყოს კომენტარი.

ჩვენს კომპანიაში ჩვენ ვიყენებთ შემდეგ სქემას:

  • ცვლილების დასაწყისში არის გახსნის კომენტარი(იწყება ნიშნებით //++ )
  • Ბოლოს - დახურვის კომენტარი(იწყება ნიშნებით //-- )
  • ა დეველოპერის მიერ განხორციელებული ცვლილებები შუაშია.

ეს არის სავალდებულო წესი ნებისმიერი ცვლილებისთვის.

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

  • პროექტის პრეფიქსი- სტანდარტულად ჩვენ ვიყენებთ FTO- ს
  • დეველოპერის დომენის სახელი... ის ძალიან მოხერხებულად იქმნება: კომპანია არის დიდი, განაწილებული და თუ არ იცნობთ დეველოპერს, მაგრამ თქვენ უნდა ჰკითხოთ მას რაიმე მის შესახებ, შეგიძლიათ აიღოთ მისი მეტსახელი ამ ეტიკეტიდან, განათავსეთ @ fto.com.ru უფლება და გაუგზავნე წერილი ისე, რომ დაუკავშირდეს მას.
  • შემდგომი მიდის ცვლილების თარიღი... როდესაც ცვლილებები ხდება რამდენიმე ამოცანის ფარგლებში, კომენტარების ეს ჩალიჩები შეიძლება ერთმანეთში იყოს ჩასმული და ყოველთვის არ არის ნათელი, რომელ დახურულ ბლოკს ეკუთვნის ეს დახურული კომენტარი, ამიტომ ჩვენ ყურადღებას ვაქცევთ თარიღს. გარდა ამისა, თარიღი დაუყოვნებლივ აჩვენებს, თუ როდის მოხდა ცვლილებები: სამი წლის წინ, ექვსი თვის წინ, ან გუშინ.
  • შემდეგ მოდის დავალების ნომერი, რომელი განთავსებულია მხოლოდ გახსნის კომენტარში... რატომ მხოლოდ იქ? ისე, რომ ამოცანის ნომრით გლობალური ძებნისას მხოლოდ კოდის ცვლილებების დასაწყისი იქნება შერჩევაში, საიდანაც შეგიძლიათ უფრო ქვემოთ იხედოთ, წინააღმდეგ შემთხვევაში ის გაორმაგდება. მაგალითად, ამოცანის წარდგენისას კოდი-განხილვისთვის, ძალიან მოსახერხებელია ეტიკეტით ძებნა.

მაგალითები

ეს ასე გამოიყურება ჩასმის კოდი:

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

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

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

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

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

3. ზედა დონის ობიექტების დამატება

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

ეს წესი არის ის ობიექტის სახელები უნდა დაიწყოს პრეფიქსით.Რისთვის?

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

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

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

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

ასე რომ, შეჯამება:

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

4. დაქვემდებარებული ობიექტების დამატება

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

აქ ჩვენ დაუყოვნებლივ უნდა გამოვყოთ ორი სიტუაცია, როდესაც ჩვენ დავამატებთ დაქვემდებარებულ ობიექტს:

  • ტიპიური კონფიგურაციის ობიექტში
  • ან რაიმე ობიექტში, რომელიც ადრე დაემატა პროექტის ფარგლებში.

მოდით განვიხილოთ თითოეული ეს სიტუაცია ცალკე.

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

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

  • სინონიმი ივსება პრეფიქსის გარეშე, რადგან აღარ არის საჭირო ჩვენი ობიექტების, ჩვენი რეკვიზიტების შერჩევა.

  • Და ბოლოს, კომენტარი ასევე შეიცავს სპეციალურ ეტიკეტსიმის გასაგებად, ვინ, როდის და რატომ.

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

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

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

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

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

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

ახლა შევაჯამოთ, თუ როგორ ემატება დაქვემდებარებული ობიექტები პროექტის ფარგლებში დამატებულ ობიექტებს:

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

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

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

5. წინასწარ განსაზღვრული ელემენტების დამატება

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

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

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

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

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

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

  • მისი სახელი არ შეიცავს პრეფიქსს, ვინაიდან არ არის საჭირო მისი როგორმე ხაზგასმა.

ასე რომ, თუ ჩვენ გავამახვილებთ ანალოგიას წინა ცხრილთან, მაშინ:

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

6. საერთო მოდულების გამოყენება და მათი მკაცრი სტრუქტურა

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

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

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

მესამე, მოდულის სახელები უნდა იყოს შესაბამისი სტანდარტული მოდულების მსგავსი.

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

  • FTO_GeneralAppointment კლიენტი,
  • FTO_GeneralDesignationServer,
  • FTO გენერალური დანიშნულება გლობალური,
  • FTO_RegularJobsServer
  • და ა.შ.

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


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

შემდეგი წესი არის ხელმოწერების გამოყენება და მათი მკაცრი სტრუქტურა. რა არის მისი არსი?

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

  • ჩაწერის დაწყებამდე
  • ჩაწერისას
  • და ა.შ.

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

ხელმოწერა ემატება შემდეგი შეთანხმებული წესების შესაბამისად:

  1. მხოლოდ ერთი გამოწერა ემატება სისტემაში ერთი და იგივე ტიპის ყველა მოვლენას... მაგალითად, თუ მე მჭირდება ჩემი ალგორითმის გამოყენება სხვადასხვა მითითებისთვის ღონისძიებაში "მითითების ჩაწერამდე", მაშინ ყველა ამ მითითებისთვის ვიყენებ მხოლოდ ერთ დამატებით გამოწერას "მითითების ჩაწერამდე".
  2. წყარო ირჩევს ამ კლასის ყველა ობიექტს(მაგალითად, ყველა დირექტორია)
  3. დამატებული ხელმოწერისთვის იქმნება ცალკე მოდული, რომელსაც ზუსტად იგივე ჰქვია.(მხოლოდ მოხერხებულობისთვის).
  4. მთავარი მოვლენის დამმუშავებელში არის პირობა, რომელიც აანალიზებს ობიექტის ტიპს(ერთგვარი საცნობარო წიგნი).
  5. და უკვე ობიექტის ტიპიდან გამომდინარე, გარკვეული მოქმედებები ხორციელდება.

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

პირველი, ჩვენ დავამატებთ ზოგად მოდულს FTO_DocumentsProcessingWith ყველა წესით.

  • ჩვენ აღვნიშნავთ DocumentObject (ყველა დოკუმენტი) როგორც წყარო;
  • როგორც დამმუშავებელი - ჩვენი მოდული დაემატა ზემოთ.

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

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

შედეგად, გამოწერის შექმნის პროცედურა ასეთია:

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


8. ფორმების რედაქტირება

შემდეგი წესი არის ფორმების რედაქტირება.

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

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

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

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

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

BSP 2 -ზე დაფუძნებული კონფიგურაციებში(როგორიცაა ERP, ბუღალტერია და ა.შ.) დაემატა ღონისძიების დამმუშავებელიForm.OnCreateAtServer ()რომელიც, სხვა საკითხებთან ერთად, შემოდისასევე გადაფარებულ მოდულში.

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

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

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

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

9. როლებთან მუშაობის პრინციპები

და ბოლო წესი არის როლებთან მუშაობის პრინციპები.

როლებთან მუშაობის პრინციპები შემდეგია:

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

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

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

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

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

1. საცდელი ბაზების თვითიდენტიფიკაცია

პირველი ტექნიკა არის ტესტის ბაზების თვითგამოვლენა.

დასკვნა ისაა, რომ:

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

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

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

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

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

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

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

2. ინიციალიზაციის დამუშავება

შემდეგი ხრიკი არის ინიციალიზაციის დამუშავება.

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

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

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

დიაგრამაზე, ეს ოპერაციული პროცედურანაჩვენებია ასე:

  • სისტემის დაწყება
  • მუდმივი ვერსიის შედარება დამუშავების ვერსიასთან.
  • თუ არ ემთხვევა, ტარდებათანმიმდევრულად ყველა საჭირო დამმუშავებლები,
  • დადგენილია მუდმივის ახალი მნიშვნელობა.

შედეგად, მონაცემები განახლებულია ყველგან, ყველა მონაცემთა ბაზაში.

3. წინასწარ განსაზღვრული ღირებულებების დირექტორია

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

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

რა არის განხორციელების ვარიანტები?

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

ეს დირექტორია შეიცავს მხოლოდ ერთ ატრიბუტს Directory typeLink– ით(ბმული ყველა საცნობარო წიგნზე).

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

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

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

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

4. დროებითი ცხრილების ნახვა გამართვაში

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

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

  • და დასახელებარატომღაც მოკლე, მაგალითად BT ()

Ამ შემთხვევაში:

  • ᲛᲔ ᲕᲐᲠ დააყენეთ შესვენების წერტილიიმ ადგილას, სადაც მაქვს მოთხოვნა.
  • ფანჯარაში "გამოთვალე გამოთქმა" ვწერ VT (მოთხოვნა);
  • მე დააჭირეთ "გამოთვალეთ" და დროებითი შეკითხვის ცხრილების სტრუქტურის მიღებარომ ნახოთ რა მონაცემები არსებობს.

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

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

დასკვნა

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

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

მსგავსი გამოცემები