ასე რომ, დავიწყოთ.

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

ჩემს შემთხვევაში ეს არის აკუმულაციური რეესტრი „სამუშაო მიმდინარე ბუღალტერია“.

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

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

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

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

ჩვენ მივუთითებთ მის ხელმისაწვდომ ტიპებს "პარამეტრების" ჩანართზე:

ამ პარამეტრით ჩვენ ვაფორმებთ ჩვენს პერიოდს ისე, რომ ყველაფერი ლამაზი და სასიამოვნო იყოს თვალისთვის)

აქ არის თავად ფორმატები:

თვე: DF="MMMM წწწწ "y.""

დღე: DF = dd.MM.yyyy

კვირა: DF = ""კვირა "dd.MM.yyyy"-დან

კვარტალი: DF = "კვარტალამდე" წწწ "y.""

წელი: DF = "yyyy "y."

ათწლეული: DF = ""ათწლეული ერთად "dd.MM.yyyy"

ნახევარი წელი: DF = ""ნახევარი წელი" dd.MM.yyyy"

სულ ესაა. გამომავალი არის შესანიშნავი სურათი:

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

დარჩენილია პროდუქტების შერჩევა საწყობებში. საწყობი, საქონელი საწყობებში რჩება. ნომენკლატურა, პროდუქტები საწყობებში დარჩენილი. QuantityBalance FROM დაგროვების რეესტრიდან. პროდუქტები საწყობებში. რჩება (&MyDate ,) AS პროდუქცია საწყობებში ნარჩენები

ახლა გადავიდეთ პარამეტრების ჩანართზე და ვნახოთ, რომ სისტემამ ჩვენი &MyDate პარამეტრის გარდა შექმნა &Period პარამეტრიც.
პერიოდების ვიზუალური მონიტორინგის მიზნით, ჩვენ შევქმნით ძირითადი მოხსენების ფორმას და განვათავსებთ ცხრილის ველს მასზე მონაცემებით: Settings Composer.Settings.DataParameters

შევინახოთ ანგარიში და გავხსნათ საწარმოში. ცხრილის ველში პარამეტრებით ნაჩვენებია მხოლოდ &პერიოდის პარამეტრი:

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

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

მოხსენით ველი. ახლა ორივეს ვხედავთ ხელმისაწვდომ პარამეტრებში. მხოლოდ ანგარიშის გენერირებისას დავინახავთ, რომ ანგარიში რეაგირებს &პერიოდის პარამეტრზე და არა &MyDate-ზე.

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

დარჩენილია პროდუქტების შერჩევა საწყობებში. საწყობი, საქონელი საწყობებში რჩება. ნომენკლატურა, პროდუქტები საწყობებში დარჩენილი. QuantityBalance FROM დაგროვების რეესტრიდან. პროდუქტები საწყობებში. რჩება ((&MyDate) ,) AS პროდუქცია საწყობებში ნარჩენები

UPDმომხმარებლისგან ბუ:

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

მაგალითს მოგიყვან:

SELECT EmployeesSP.Employee, WorkersSP.ReasonChangesConditions, WorkersSP.Period, WorkersSPAnotherDate.Period AS Period2, WorkersSPAnotherDate.ReasonChangesStates AS ReasonChangesState2 FROM RegisterInformergeL,Employe ეე ) AS სამუშაო nikkiSP მარცხენა კავშირიინფორმაციის რეესტრი.ორგანიზაციების თანამშრომლები. უახლესი (&სხვა თარიღი ,) AS EmployeesSPAსხვათარიღი თანამშრომლების მიერSP.Employee = EmployeesSPAnotherDate.Employee

მეორე ქვემოთხოვნაში „სტანდარტული“ PERIOD პარამეტრის მნიშვნელობა გამოყენებული იქნება თარიღის თარიღის პარამეტრად და არა სხვა თარიღის მნიშვნელობად.

ეს „შეფერხება“ შეინიშნება მაშინაც კი, თუ მეორე ქვემოთხოვნა გამოვა მეორე მონაცემთა ნაკრებში და დაკავშირებული იქნება ACS-ის გამოყენებით. მეორე მოთხოვნაში "ADDATE(&Period, MONTH, -1)" გამონათქვამის გამოყენების ვარიანტი ასევე არ იმუშავებს, თვე არ გამოკლდება. მაგრამ "პერიოდის" პარამეტრის გადარქმევა მოთხოვნაში, მაგალითად, "FirstDate" აგვარებს ამ პრობლემას.

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

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

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

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

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

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

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

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

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

1C-ს „თვალსაზრისით“, პერიოდი 01/28/2010 - 01/01/0001 გამოიწვევს გამონაკლისს.

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

1). პერიოდის დასაწყისი და პერიოდის დასასრული არ არის მითითებული -> ყველა დოკუმენტი.

2). მითითებულია მხოლოდ პერიოდის დასაწყისი -> ყველა დოკუმენტი პერიოდის დასაწყისიდან

3). გარდა ამისა, ჩვენ შევამოწმებთ, რომ პერიოდის დასასრული >= პერიოდის დაწყება და თუ ეს სიმართლეს არ შეესაბამება, მაშინ ვივარაუდებთ, რომ პერიოდის დასასრული არ არის მითითებული, ე.ი. 2).

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

WHEN &Period.EndDate=DATETIME(1,1,1)

მაშინ DATETIME(3999,12,31)

WHEN &Period. დასრულების თარიღი<&Период.ДатаНачала

მაშინ DATETIME(3999,12,31) DATETIME(3999,12,31,23,59,59)

&პერიოდ.დამთავრების თარიღი

ჩვენი პერიოდის შერჩევის დიზაინის საბოლოო ფორმა ნაჩვენებია

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