Saxlama sistemində müəyyən edilmiş tezliyə malik hesabat yaradırıq. Standart parametr &Dövr və sorğuda 1s standart müddətin istifadə edilməsində problemlər

Gəlin bir sorğu məlumat dəsti ilə hesabat yaradaq:

ANBARLARDA QALAN MƏHSULLARI SEÇİN. Anbar, MallarAnbarlardaQalıqlar. Nomenklatura, Anbarlarda Qalan Məhsullar. Yığım Reyestrindən QuantityBalance. Anbarlarda olan məhsullar. Qalıqlar(&Tarixim,) AS MəhsullarAnbarlardaQalır

İndi parametrlər sekmesine keçək və sistemin &MyDate parametrimizdən əlavə &Dövr parametrini də yaratdığını görək.
Dövrləri vizual olaraq izləmək üçün biz əsas hesabat forması yaradacağıq və orada məlumatların olduğu cədvəl sahəsini yerləşdirəcəyik: Parametrlər Composer.Settings.DataParameters

Hesabatı saxlayaq və müəssisədə açaq. Parametrləri olan cədvəl sahəsində yalnız &Dövr parametri göstərilir:

Müvafiq olaraq, bu parametrdə hər hansı bir dəyişiklik istənilən nəticəni verməyəcəkdir.

Niyə &MyDate parametri mövcud deyil? Əlbəttə ki, parametrlər sekmesinde bir onay qutusu işarələndiyi üçün Əlçatanlıq məhdudiyyəti.

Qutunun işarəsini silin. İndi hər ikisini mövcud parametrlərdə görürük. Yalnız hesabatı yaradan zaman hesabatın &MyDate-ə deyil, &Dövr parametrinə cavab verdiyini görəcəyik.

Bu misalda görüləcək ən sadə şey sorğuda &MyDate parametrinin adını &Period olaraq dəyişdirmək və istədiyiniz nəticəni əldə etməkdir. Amma ola bilsin ki, &Period parametrinin artıq istifadə olunduğu bir sorğunuz var və ya dini baxışlarınız bu parametrdən istifadə etməyə icazə vermir, istənilən halda problemi belə həll edə bilərsiniz:

ANBARLARDA QALAN MƏHSULLARI SEÇİN. Anbar, MallarAnbarlardaQalıqlar. Nomenklatura, Anbarlarda Qalan Məhsullar. Yığım Reyestrindən QuantityBalance. Anbarlarda olan məhsullar. Remains((&MyDate) ,) AS MəhsullarAnbarlardaQalır

UPD istifadəçidən Boo:

“Standart” (sistem tərəfindən əlavə edilmiş) parametrlərdən istifadə zamanı əsas problem ondan ibarətdir ki, hesabatda bir neçə virtual cədvəldən istifadə edilərkən, bu parametr müəyyən edilərsə, onun dəyəri “öz” olanların əvəzinə bütün digər hallarda istifadə olunacaq.

Sizə bir misal verim:

İşçilərSP.İşçi, İşçilərSP.SəbəbDəyişiklikləriDövlət,İşçilərSP.Dövr, İşçilərSPAdigərTarix.Dövr AS Dövr, İşçilərSPAdigərTarixDəyişikliklərDövlət AS SəbəbDəyişikliklərDövlət2 FROM QeydiyyatMəlumatları. İş nikkiSP AS SOL ƏLAQƏ Məlumatların Reyestri. Təşkilatların İşçiləri. Ən Son (&DigərTarix,) AS İşçiləriSPAdigərTarix BY EmployeesSP.Employee = EmployeesSP.Date.Employee

İkinci alt sorğuda “standart” DÖVR parametrinin dəyəri DigərTarix dəyərindən çox, dilim tarixi parametri kimi istifadə olunacaq.

İkinci alt sorğu ikinci məlumat dəstinə çıxarılsa və ACS-dən istifadə edilərək əlaqələndirilsə belə, bu "xətt" müşahidə olunacaq. İkinci sorğuda “ADDATE(&Period, MONTH, -1)” kimi ifadədən istifadə edən seçim də işləməyəcək, ay çıxılmayacaq. Lakin sorğudakı "Dövr" parametrinin adının, məsələn, "Birinci Tarix" olaraq dəyişdirilməsi bu problemi həll edir.

Yeri gəlmişkən, eyni problem, məsələn, dövriyyəni əldə etmək üçün istifadə olunan yığılma və mühasibat registrlərinin virtual cədvəllərində müşahidə olunur. Orada sistem “Dövrün başlanğıcı” və “Dövrün sonu” parametrlərini əlavə edir.
Beləliklə, hətta bir qədər artan mürəkkəblik sorğuları halında, mövcudluğu və "standart dövrlər" dən istifadəni söndürməyin mənası var.

Beləliklə, başlayaq.

Sadəlik üçün nümunəni başa düşmək üçün bir sadə dövriyyə yığım registrini quracağıq.

Mənim vəziyyətimdə bu, "İşlərin Mühasibat Uçotu"nun yığılma reyestridir.

Məsələn, onun parametrlərini sərt şəkildə göstərəcəyik (giriş nəzarət sisteminə parametrlərin yumşaq tətbiqi ilə deyil):

Nəzərə alın ki, virtual cədvəlin tezliyi “Qeyd”dir.

Ancaq yuxarıda qeyd edildiyi kimi, dövrilik baxımından dövrə ehtiyacımız var, ona görə də "Dövr" sahəsini aşağıdakı şəkildə hesablamağı təklif edirəm (çox gözəl deyil, amma daha yaxşı variant görmədim):

Ekran görüntüsündən göründüyü kimi, sorğuya istifadəçinin formada göstərdiyi parametr ötürülür: “Tezlik” sadalamasının qiyməti – bu siyahıya demək olar ki, bütün standart həllərdə rast gəlinir.

"Parametrlər" sekmesinde onun mövcud növlərini göstərəcəyik:

Bu tənzimləmə ilə dövrümüzü elə formatlayırıq ki, hər şey gözəl və gözə xoş gəlsin)

Budur formatların özləri:

Ay: DF="MMMM yyyy "y.""

Gün: DF = gg.MM.yyyy

Həftə: DF = ""Gg.AA.yyyy-dan etibarən həftə"

Rüb: DF = ""rüb" yyyy "y"-ə."

İl: DF = "yyyy "y.""

Onillik: DF = """gg.MM.yyyy" ilə onillik

Yarım il: DF = ""Gg.MM.yyyy"dan "Yarım il"

Hamısı budur. Çıxış gözəl bir şəkildir:

Bu məqalədə Məlumat Tərkibi Sistemindən (DCS) istifadə edərkən dövrün qurulmasının bəzi xüsusiyyətləri, adi bir istifadəçi ilə 1C sistemi arasındakı dövr anlayışındakı fərqlər səbəbindən yaranan problemlər müzakirə olunur, həmçinin onların həlli yolları təklif olunur. .
Məlumat Tərkibi Sistemi (DCS) istifadə edərək hazırlanmış əksər hesabatlar istifadəçidən hesabatın qurulacağı dövrü daxil etməyi tələb edir. Bir qayda olaraq, ACS-də dövr girişi aşağıdakı konstruksiyadan istifadə edərək parametrlər vasitəsilə təşkil edilir, bax. Şəkil 1 Bir dövrə girməyin bu üsulu "klassik" hesab olunur, 1C-də inkişafa həsr olunmuş İTS və digər ədəbiyyatda təsvir edilmişdir, buna görə də onu əsas götürək. Nümunə olaraq bütün sənədləri qəbul edən sadə sorğunu nəzərdən keçirək Müəyyən bir dövr üçün malların və xidmətlərin satışı, bax Şəkil 2 Bu hesabatdan istifadə edərkən istifadəçi parametrlər vasitəsilə dövrü təyin edir, bax. şək.3 Hər şey düzgün görünür... AMMA kiçik bir problem var:

Məsələ burasındadır ki, istifadəçilərin böyük əksəriyyəti dövrü 1C-dən fərqli olaraq “başa düşür”, misallar:
1). Gəlin nəzərdən keçirək şək.3
İstifadəçi nöqteyi-nəzərindən müddət göstərilməyib, yəni LİMİTSİZ, yəni tarix məhdudiyyəti olmayan BÜTÜN sənədlər hesabata daxil edilməlidir.
1C sisteminin "nöqteyi-nəzərindən" parametr-dövr müəyyən edilir və ... onun hər iki sərhədi 01.01.0001-ə bərabərdir və hesabata yalnız boş tarixi olan sənədlər daxil ediləcək, bu da praktikada o deməkdir ki, heç bir sənəd daxil edilməyəcək.
2). Gəlin nəzərdən keçirək Şəkil 4
İstifadəçinin nöqteyi-nəzərindən hesabata 28.01.2010 tarixindən başlayaraq bütün sənədlər daxil edilməlidir.
1C-nin "nöqteyi-nəzərindən" 28.01.2010 - 01.01.0001 dövrü istisnaya səbəb olacaqdır.

Siz, əlbəttə ki, istifadəçiyə hesabatın niyə görməyi gözlədiyi sənədləri göstərmədiyini və dövrün 1C-nin "nöqteyi-nəzərindən" necə təqdim olunduğunu izah etməyə cəhd edə bilərsiniz, lakin bu, nankor bir işdir və da səhvdir. Yaxşı bir proqram, ilk növbədə, istifadəçi üçün əlverişli olmalıdır, çünki proqram istifadəçi üçün mövcuddur və əksinə deyil, buna görə də istifadəçinin başa düşdüyü dövrü başa düşmək üçün 1C-yə “öyrətmək” lazımdır, yəni:
1). Dövrün başlanğıcı və Sonu göstərilməyib -> bütün sənədlər.
2). Yalnız Dövrün əvvəli göstərilir –> Dövrün əvvəlindən başlayaraq bütün sənədlər
3). Bundan əlavə, biz Dövrün Sonu >= Dövrün Başlandığını yoxlayacağıq və bu doğru deyilsə, Dövrün Sonunun göstərilmədiyini güman edəcəyik, yəni. 2).
Yuxarıda göstərilənlərə əsasən, Bitmə tarixi parametri üçün ifadə belə görünəcək:

ZAMAN &Period.EndDate=DATETIME(1,1,1) SONRA DATETIME(3999,12,31,23,59,59) SEÇ<&Период.ДатаНачала ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ &Период.ДатаОкончания КОНЕЦ КОНЕЦ

Dövr seçim dizaynımızın son forması göstərilir Şəkil 5

Girişə nəzarət sistemində dövrü təyin etməyin bəzi xüsusiyyətləri.

Məlumat Tərkibi Sistemi (DCS) istifadə edərək hazırlanmış əksər hesabatlar istifadəçidən hesabatın qurulacağı dövrü daxil etməyi tələb edir.

Bir qayda olaraq, ACS-də dövr girişi aşağıdakı konstruksiyadan istifadə etməklə təşkil edilir, bax: Bu dövr daxiletmə üsulu "klassik" hesab olunur, 1C-də inkişafa həsr olunmuş İTS və digər ədəbiyyatda təsvir edilmişdir; əsas götürək. Nümunə olaraq bütün sənədləri qəbul edən sadə sorğunu nəzərdən keçirək Müəyyən bir dövr üçün malların və xidmətlərin satışı, bax

Bu hesabatdan istifadə edərkən istifadəçi parametrlər vasitəsilə dövrü təyin edir, bax hər şey düzgündür..., AMMA kiçik bir problem var:

Məsələ burasındadır ki, istifadəçilərin böyük əksəriyyəti dövrü 1C-dən fərqli olaraq “başa düşür”, misallar:

İstifadəçi nöqteyi-nəzərindən müddət göstərilməyib, yəni LİMİTSİZ, yəni tarix məhdudiyyəti olmayan BÜTÜN sənədlər hesabata daxil edilməlidir.

1C sisteminin "nöqteyi-nəzərindən" parametr-dövr müəyyən edilir və ... onun hər iki sərhədi 01.01.0001-ə bərabərdir və hesabata yalnız boş tarixi olan sənədlər daxil ediləcək, bu da praktikada o deməkdir ki, heç bir sənəd daxil edilməyəcək.

İstifadəçinin nöqteyi-nəzərindən hesabata 28.01.2010 tarixindən başlayaraq bütün sənədlər daxil edilməlidir.

1C-nin "nöqteyi-nəzərindən" 28.01.2010 - 01.01.0001 dövrü istisnaya səbəb olacaqdır.

Siz, əlbəttə ki, istifadəçiyə hesabatın niyə görməyi gözlədiyi sənədləri göstərmədiyini və dövrün 1C "nöqteyi-nəzərindən" necə təqdim olunduğunu izah etməyə çalışa bilərsiniz, lakin bu, nankor bir işdir və də səhvdir. Yaxşı bir proqram, ilk növbədə, istifadəçi dostu olmalıdır, çünki proqram istifadəçi üçün mövcuddur və əksinə deyil, buna görə də istifadəçinin başa düşdüyü dövrü başa düşmək üçün 1C-ni "öyrətmək" lazımdır, yəni:

1). Dövrün başlanğıcı və Sonu göstərilməyib -> bütün sənədlər.

2). Yalnız Dövrün əvvəli göstərilir -> Dövrün əvvəlindən başlayan bütün sənədlər

3). Bundan əlavə, biz Dövrün Sonu >= Dövrün Başlandığını yoxlayacağıq və bu doğru deyilsə, Dövrün Sonunun göstərilmədiyini güman edəcəyik, yəni. 2).

Yuxarıda göstərilənlərə əsasən, Bitmə tarixi parametri üçün ifadə belədir:

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

SONRA DATETIME(3999,12,31)

ZAMAN &Dövr.Bitmə Tarixi<&Период.ДатаНачала

SONRA DATETIME(3999,12,31) DATETIME(3999,12,31,23,59,59)

&Dövr.Bitmə tarixi

Dövr seçim dizaynımızın son forması göstərilir

Qeyd: parametrləri təyin etmək üçün bu mexanizm köhnə 1C 8.1 və 8.2 platformaları üçün nəzərdə tutulmuşdur (və onların nəzarəti altında işləyən 1C platformasının köhnə versiyalarında boş parametrləri idarə etmək üçün daxili mexanizmlər var və mexanizmə müraciət etməyə ehtiyac yoxdur); bu məqalədə təsvir edilmişdir, əlavə olaraq 1C platformasının bəzi versiyalarında səhvlər və səhv əməliyyatlar mümkündür.

Gününüz xeyir, blog saytının əziz oxucuları! Son məqalədə bu rolların nə üçün lazım olduğunu öyrəndik. Və bu gün, bu məqalələr seriyasının ikincisində baxacağıq “Dövr” xassəsi ilə rolun qurulması, və həmçinin bu rolların doldurulması nümunələrini nəzərdən keçirin. Qalan "Dövr" rolu olan sahədən istifadə etməklə hesablanır. Başqa vaxt danışacağımız “Ölçü” rolu ilə sahədə olduğu kimi. Beləliklə, başlayaq!

Gəlin yeni hesabat yaradaq:

  1. Konfiquratorda "Fayl" - "Yeni" - "Xarici hesabat" menyusunu seçin.
  2. "Məlumat kompozisiyasının diaqramını aç" düyməsini basın. Açılan dialoq pəncərəsində "Bitir" düyməsini basın.
  3. İndi “Yığım Registrləri” virtual cədvəlinə daxil olanı yaradaq.
  4. "Məlumat Dəstləri" qovşağına sağ vurun və "Məlumat Dəsti - Sorğu əlavə et" sətrini seçin.
  5. İndi "Query Builder" düyməsini basın. “GoodsInWarehousesRemainsAndTurnover” (USP konfiqurasiyası) yığılma reyestrini seçək.
  6. "Virtual Cədvəl Parametrləri" dialoqunu açaq və "Avtomatik" tezliyinin istifadə olunacağını, yəni bir neçə dövr təyin etmək mümkün olacağını bildirək.

İndi çıxış sahələrini konfiqurasiya edək. Bunlar aşağıdakı sahələr olsun: “Registrator”, “DövrAy”, “Nomenklatura”, “Keyfiyyət” və balanslar haqqında məlumat. Sahənin əlavə edilməsi siçanın sol düyməsini istədiyiniz sahədə iki dəfə sıxmaqla və ya “>” düyməsini istifadə etməklə həyata keçirilir. Sahələri əlavə etdikdən sonra "OK" düyməsini basın.

Nəzərə alın ki, bəzi sahələr üçün “Dövr” xüsusiyyəti ilə rol avtomatik olaraq konfiqurasiya edilir.

Nəyin mövcud olduğuna baxaq "Dövr" mülkiyyəti üçün rol parametrləri. Əvvəlcə dövrün seriya nömrəsi göstərilir. Nömrələmə birdən başlayaraq, ən aşağı dövrlərdən ən yüksəyə qədər davamlı olmalıdır, yəni əvvəlcə məsələn, sətir nömrəsi, sonra “Yazıcı”, sonra ikinci, gün, həftə, ay, rüb, il.

Beləliklə, sorğumuzda görünən sahələr nömrələnməlidir. Diqqət yetirin ki, bizdə iki dövr sahəsi var - "Registrator" və "PeriodMonth". Aşağı sahə “Qeydiyyatçı”dır, ona bir, yüksək sahə isə “Dövr Ay”dır, ona iki təyin olunur. Bunu növbəti məqalədə daha ətraflı nəzərdən keçirəcəyik.

Gəlin hesabatımızı tərtib edək:

  1. Gəlin "Resurslar" sekmesine keçək və hesabatımızın resurslarını müəyyən edək.
  2. Resurslar üçün bütün sahələri seçmək üçün “>>” düyməsinə klikləyin.
  3. İndi "Parametrlər" sekmesine keçək və siyahı şəklində bir parametr yaradaq.
  4. "Məlumat kompozisiya parametrləri dizayneri" düyməsini (sehrli çubuq şəklində düymə) vurun.
  5. Hesabatın növü: "Siyahı". "Növbəti" düyməsini basın.
  6. “>>” düyməsini sıxaraq çıxış sahələrini konfiqurasiya edək. Gəlin onları belə təşkil edək: “MüddətAy”, “Nomenklatura”, “Keyfiyyət”, “Qeydiyyatçı”.
  7. "Növbəti" düyməsini basın və qruplaşdırmanı qurun. Qruplaşdırmanı aşağıdakı ardıcıllıqla quracağıq: “MüddətAy”, “Nomenklatura”, “Keyfiyyət”. “Qeydiyyatçı” qruplaşması ətraflı qeydlər şəklində göstəriləcək.
  8. "OK" düyməsini basın.

Gəlin hesabatımızı açaq. Bu hesabatı işlətsək, qalıqları qəbul edərkən bəzi xüsusiyyətləri görəcəyik. Hesabatın nəticəsini diqqətlə nəzərdən keçirsəniz, dərhal bir neçə səhv görəcəksiniz. Xüsusən də nədənsə şirkətin fəaliyyət dövrünün lap əvvəlində ilkin balans yaranır.

Və bu səhv registratordan qalıqların alınması xüsusiyyəti ilə bağlıdır. Bu qalıqların düzgün göstərilməsi üçün sorğunun çıxış sahələrinə daha bir sahə əlavə etməlisiniz - “PeriodSecond” sahəsi. "PeriodSecond" sahəsini əlavə etmək üçün Konfiquratorda hesabatı açın və "Məlumat kompozisiya sxemini açın" düyməsini basın. İndi "Query Builder" düyməsini basın və "PeriodSecond" əlavə edin. Bu halda, “Qeydiyyatçı” sahəsi dövrün birinci sahəsi, “DövrSecond” ikinci, “DövrAy” isə üçüncü sahə olaraq qalacaq.

Bir saniyə nə üçündür? Məlumat kompozisiya sistemi hesablama ilə balansları hesablayır və qeyd cihazının vaxt oxundakı yerini birmənalı şəkildə müəyyən etmək üçün yazıcıya bir saniyə də kifayət deyil, yəni bu qeyd cihazının tarixi; , və sonra layout sistemi hesablama ilə düzgün balans əldə edə biləcək. Sahələrin düzgün sırasını təyin etsək və hesabatı yenidən yaratsaq, əldə edəcəyik:

İndi Plinth nomenklaturası üzrə fəaliyyətə başlamaq üçün balans qalmayıb. Sonra növbəti dövr üçün yekun balansla üst-üstə düşür, yəni biz həqiqətən düzgün nəticə görürük. Nümunə hesabatı aşağıdakı linkdən yükləyə bilərsiniz. Məqaləni bəyəndinizmi? Nə dəyişdirilə bilər, nə əlavə edilə bilər? Bu barədə şərhlərdə paylaşmaqdan çekinmeyin!

Məqalənin sonunda sizə Anatoli Sotnikovdan pulsuz olanı tövsiyə etmək istəyirəm. Bu, təcrübəli bir proqramçının kursudur. O, ayrıca girişə nəzarət sistemində hesabatların necə qurulacağını sizə göstərəcək. Sadəcə diqqətlə dinləmək və yadda saxlamaq lazımdır! Aşağıdakı suallara cavab alacaqsınız:
  • Sadə bir siyahı hesabatını necə yaratmaq olar?
  • “Sahələr” tabındakı Sahə, Yol və Başlıq sütunları nə üçündür?
  • Layout sahələri üçün məhdudiyyətlər hansılardır?
  • Rolları necə düzgün konfiqurasiya etmək olar?
  • Layout sahələri üçün hansı rollar var?
  • Sorğuda məlumat tərkibi tabını harada tapa bilərəm?
  • Girişə nəzarət sistemində parametrləri necə konfiqurasiya etmək olar?
  • Daha da maraqlı olur...
Yəqin ki, lazımi məlumatları axtarmaq üçün özünüz İnternetdə gəzməyə çalışmamalısınız? Üstəlik, hər şey istifadəyə hazırdır. Sadəcə başlayın! Pulsuz video dərslərdə olanlar haqqında bütün təfərrüatlar

Sorğuda məlumat tərkibini işarələməklə bağlı dərslərdən biri budur:





Əlaqədar nəşrlər