სტანდარტული 1c კონფიგურაციების დახვეწა. წინასწარ განსაზღვრული ელემენტების დამატება

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

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

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

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

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

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

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

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

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

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

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

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

1. სტანდარტული კონფიგურაციის „განადგურების“ მინიმიზაციის კონცეფცია

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

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

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

//++ VION 07/20/2016 0001234 დასრულება დასაწყისში //-- VION 07/20/2016

• //++ - ბლოკის დაწყება
• //— — ბლოკის დასასრული
• VION - დეველოპერის სახელი (ან მეტსახელი).
• 0001234 - დავალების ნომერი ტრეკერის მიხედვით, მოთავსებულია მხოლოდ გახსნის კომენტარში, ისე რომ კოდის თითოეული ცვლილება გლობალური ძიების შედეგებში ჩნდება დავალების ნომრის მიხედვით მხოლოდ ერთხელ.
• გაუმჯობესებები დასაწყისში- თვითნებური კომენტარი, საჭიროების შემთხვევაში გამოიყენება, მაგრამ თუ დავალების ნომერი არ არის, მაშინ საჭიროა მოკლე განმარტებითი ტექსტი

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

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

2.1 კოდის ჩასმა

მაგალითი:

გახსნის პროცედურა() თუ ეს არის ახალი() მაშინ შეავსეთ ველები ნაგულისხმევად(); დაასრულე თუ; SetFormElements(); //++ VION 07/20/2016 0001234 ConfigureAdditionalElements(); //-- VION 07/20/2016 SetFieldVisibility (); პროცედურის დასასრული

2.2 კოდის ამოღება

მაგალითი:

პროცედურა OnOpen() //++ VION 07/20/2016 0001234 //If This is New() შემდეგ // შეავსეთ ნაგულისხმევი ველები(); //Დაასრულე თუ; ConfigureAdditionalItems(); //-- VION 07/20/2016 SetFieldVisibility (); პროცედურის დასასრული

2.3 არსებული კოდის შეცვლა

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

მაგალითი:

პროცედურა OnOpen() თუ ეს ახალია() მაშინ //++ VION 07/20/2016 000123 //შეავსეთ ველები ნაგულისხმევად(); FieldFillSetting = GetFieldFillSetting(); FillFieldsDefaultExtended(SettingFillFields); //-- VION 20.07.2016 EndIf; SetFormElements(); SetFieldVisibility (); პროცედურის დასასრული

2.4 მოდულში პროცედურების და ფუნქციების დამატება

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

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

მაგალითი:

//++ VION 07/20/2016 000123 Variable mSettingField Filling; პროცედურა ModifyFormProgrammatically () ... ... დასრულების პროცედურა//-- VION 07/20/2016 //++ VION 07/20/2016 000123პროცედურების თარიღიგაგზავნის დამუშავების არჩევა () ... ... დასრულების პროცედურა//-- VION 20.07.2016წ

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

თუ დასკვნით კომენტარს განათავსებთ შემდეგ სტრიქონზე:

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

3. უმაღლესი დონის ობიექტების დამატება

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

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

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

მაგალითი: შექმენით "პროექტების" დირექტორია.

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

• დასახელება: AB_Projects
• სინონიმი: (AB) პროექტები

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

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

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

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

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

მაგალითი: შექმენით „პროექტის“ ატრიბუტი „წინასწარ გადახდის“ დოკუმენტში.

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

• დასახელება: AB_Project
• სინონიმი: პროექტი
• კომენტარი: // VION 07/20/2016 000123

4.2 პროექტის ფარგლებში დამატებულ ობიექტებს დაქვემდებარებული ობიექტების დამატება

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

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

მაგალითი: შექმენით "პასუხისმგებელი" ატრიბუტი "(AB) პროექტები" დირექტორიაში.

დეველოპერის მოქმედებები: თუ დავალება განსხვავდება იმისგან, რომელშიც შეიქმნა “(AB) Projects” დირექტორია, მაშინ კონფიგურაციაში იქმნება შემდეგი დეტალები:

• დასახელება: პასუხისმგებელი
• სინონიმი: პასუხისმგებელი
• კომენტარი: // VION 07/20/2016 000456

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

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

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

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

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

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

• სახელი: AB_FormsStrictReporting
• კოდი: 10.15
• დასახელება: მკაცრი ანგარიშგების ფორმები

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

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

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

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

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

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

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

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

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

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

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

მაგალითი: „წინასწარ გადახდის“ დოკუმენტის განთავსებისას გააკეთეთ ჩანაწერები დაგროვების რეესტრში „(AB) პროექტის ხარჯები“.

დეველოპერის მოქმედებები:

1. შექმენით გამოწერა „AB_DocumentsProcessingProcessing“ (თუ ასეთი გამოწერა ადრე არ შექმნილა), მიუთითეთ ყველა დოკუმენტი, როგორც წყარო, მოვლენა არის „ProcessingProcessing“.

2. შექმენით საერთო სერვერის მოდული "AB_DocumentsProcessing".

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

4. „ავანსის გადახდა“ დოკუმენტის მოდული უნდა დარჩეს უცვლელი.

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

8.1 სტანდარტული ობიექტების ფორმების რედაქტირება

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

მაგალითი: დოკუმენტის ძირითად ფორმაზე „წინასწარი გადახდა“ დაამატეთ დეტალი „(AB) პროექტი“.

დეველოპერის მოქმედებები: ფორმის დამმუშავებელში „When CreatedOnServer“ დაამატეთ პროცედურა „EditFormProgrammatically()“. ამ პროცედურაში დაამატეთ სასურველი ელემენტი ფორმის ელემენტებს.

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

BSP 2-ზე დაფუძნებულ ტიპურ კონფიგურაციებში უკვე არსებობს სპეციალური ფუნქციონირება ამ მიზნებისათვის:

ზოგადი მოდულის "როდესაც CreateOnServer" პროცედურაში "Configuration of Overridden" შეგიძლიათ დაურეკოთ საკუთარ დამმუშავებელს.

სადაც, ფორმის სახელწოდებით, შეგიძლიათ დარეკოთ საჭირო პროცედურა ფორმის პროგრამული მოდიფიკაციით.

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

8.2 პროექტში დამატებული ობიექტების ფორმების რედაქტირება

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

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

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

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

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

10. გარე ანგარიშები და დამუშავება

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

BSP 2-ზე დაფუძნებულ კონფიგურაციებში (ERP, UT 11, BP 3.0, ZUP 3.0 და ა.შ.) ეს მექანიზმი მნიშვნელოვნად გაფართოვდა. მისი დახმარებით, კონფიგურაციის შეცვლის გარეშე, შესაძლებელია გარე მოხსენებების შექმნა და დამუშავება (ბრძანების ინტერფეისში გაშვების ბრძანების განთავსებით და სხვადასხვა მომხმარებლისთვის წვდომის კონფიგურაციის შესაძლებლობით), დოკუმენტის შევსების დამუშავება, დამუშავება. საფუძველზე დოკუმენტის შექმნა, დამატებითი ნაბეჭდი ფორმები და ა.შ.

ეს სტატია დაგეხმარა?

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

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

რა ახალი რამ კეთდება ჩვეულებრივ 1C-ში?

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

1C 8.3-ში ცვლილებების მაგალითები:

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

1C სპეციალისტის მუშაობის ერთი საათის ფასი

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

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

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

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

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

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

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

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

1. სტანდარტული კონფიგურაციის „განადგურების“ მინიმიზაციის კონცეფცია

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

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

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

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

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

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

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

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

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

მაგალითები

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

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

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

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

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

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

3. უმაღლესი დონის ობიექტების დამატება

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

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

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

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

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

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

ასე რომ, შევაჯამოთ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

თუ ჩვენ გავაერთიანებთ ამ წესს ორივე შემთხვევისთვის და „დავყოფთ მას ნაწილებად“, მივიღებთ შემდეგ ცხრილს:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• FTO_General Purpose Client,
• FTO_General Purpose სერვერი,
• FTO_General Purpose Global,
• FTO_RoutineTasksServer
• და ა.შ.

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

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

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

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

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

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

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

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

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

პირველ რიგში ვამატებთ ზოგად მოდულს FTO_DocumentsProcessingProcessing ყველა წესის მიხედვით.

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

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

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

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

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

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

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

აქ ჩვენ გამოვყოფთ ორ პუნქტს, ორ სიტუაციას:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

საქმე ისაა:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• და სახელიროგორმე მოკლედ, მაგალითად VT()

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

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

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

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

დასკვნა

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

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

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

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

როგორ გავაუმჯობესოთ 1C პროგრამები

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

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

ყველაზე გავრცელებული ცვლილებები 1C

ქვემოთ ჩამოვთვლით განსაკუთრებით პოპულარულ გაუმჯობესებებს 1C პროგრამებში:

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

1C-ში გაუმჯობესების ჩვენთვის მინდობის უპირატესობები

არსებობს მრავალი მიზეზი, რის გამოც ჩვენი კომპანიისგან მოდიფიკაციების შეკვეთა მომგებიანია:

• Მაღალი ხარისხი.ჩვენი 1C პროგრამისტები არიან მაღალკვალიფიციური სპეციალისტები, რაც დასტურდება შესაბამისი 1C სერთიფიკატებით.
• Დაბალი ფასი.ჩვენი კომპანია არის პატარა, მაგრამ სწრაფად მზარდი, ჩვენ ვაშორებთ შუამავლებს მომხმარებელსა და პროგრამისტს შორის, ამის გამო ვახერხებთ 1C სერვისების ღირებულებას დაბალ დონეზე, 1000 რუბლიდან შევინარჩუნოთ. სპეციალისტის მუშაობის საათში.
• სამუშაოს სწრაფი დასრულება. ჩვენი კომპანიისთვის არ არის მომგებიანი თქვენი დავალების შესრულების გადადება. შესაბამისად, გარანტირებული გაქვთ თქვენი მუშაობის შედეგის მიღება არაუგვიანეს სამი სამუშაო დღისა. თუ დავალება მცირეა, მაშინ სავარაუდოა, რომ თქვენ შეძლებთ მიიღოთ საჭირო მოდიფიკაცია 1C-ში იმ დღეს, როდესაც მას დაუკავშირდებით.
• 100% გარანტია მოდიფიკაციის შესრულებისთვის.ჩვენი კომპანია გარანტიას იძლევა ჩვენი თანამშრომლების მიერ თქვენს პროგრამაში გაუმჯობესების ფუნქციონირებაზე. მისი განხორციელებიდან ერთი წლის განმავლობაში შეგიძლიათ გვითხრათ თუ აღმოაჩენთ ფარულ დეფექტებს და ჩვენ მათ სრულიად უფასოდ გამოვასწორებთ რაც შეიძლება მალე.
• მიუხედავად იმისა, რომ ჩვენ გეოგრაფიულად მდებარეობენ პეტერბურგი, ჩვენ შეგვიძლია დისტანციურად შეასრულოთ თქვენთვის ნებისმიერი სამუშაო, მიუხედავად იმისა, თუ სად ხართ მსოფლიოში.