Mövzumuzun ikinci hissəsi gələcək sistemimizin ilk sənədi olan Təchizatçı Hesab-fakturasının yaradılması haqqında idi. Bu növ sənəd məhsulların şirkətin anbarına çatdırılmasını əks etdirən biznes fəaliyyətini təsvir edir.
Aydındır ki, növbəti addım müştərilərə məhsul satmaqdır. Buna görə də, yaratmalı olduğumuz sənəd Satış Fakturasıdır.
Davam etməzdən əvvəl onun necə işləməsi və hansı xüsusiyyətlərin daxil olması lazım olduğunu düşünməyi təklif edirəm.
Məhsul satışlarını qeyd etmək istədiyimiz üçün məhsul siyahımız üçün bir cədvəlin olması təbiidir. Bu cədvələ həmçinin məhsulların sayı, vahid qiyməti və ümumi qiymət daxil edilməlidir.
Daha sonra, məhsulları anbarlarda saxladığımız və Təchizatçı Faktura sənədinin alındığı məhsulları müəyyən bir anbara ayırdığımız üçün məhsulları müəyyən bir anbardan göndərməliyik. Bu o deməkdir ki, bizim Satış Faktura sənədimizdə Anbar xüsusiyyətinə ehtiyacımız var.
Əsasən, bu orijinal sənədi yaratmağa davam etmək üçün kifayətdir.
Gəlin 1C Designer-i açıb onu yaradaq. Davam etməzdən əvvəl, Satış (Sales) adlı başqa bir alt sistem yaratmağı təklif edirəm. Burada satışla bağlı obyektlər yerləşir. Yeni yaradılmış alt sistemi komanda interfeysinə daxil etdiyinizə əmin olun:
İndi biz yeni Satış faktura (Sales Invoice) sənədi yarada bilərik:
Yeni sənədi yaratdığımız alt sistemə əlavə edin:
Məlumatlar (Data) bölməsinə keçin və tələb olunan atributları yaradın.
İndi Qeyd (Posting) bölməsinə keçin və bu yeni sənədə qeydlər əlavə etməyə icazə verilən qeydi təyin edin. Hazırda yalnız bir qeydimiz var. Onu seçin:
Reyestr qeydlərini birbaşa sənəd formasında görmək üçün bu formu yaratmalıyıq:
Və reyestrimizi görünən olaraq təyin edin:
Məqalələr seriyamızın ikinci hissəsindən xatırladığınız kimi, belə bir quraşdırma sənəd formasında qeydiyyata dəyişikliklər etməyə imkan verir ki, bu da olduqca rahatdır.
Parametrləri tamamladıq və reyestrlərə yenidən kodlamağa imkan verən kodu yaratmağa kömək edəcək Qeyd Sehrbazını (record wizard) işə salmaq üçün qeyd bölməsinə qayıtmağın vaxtı gəldi. Alqoritm Təchizatçı Faktura sənədinin yaradılması ilə eynidir. Yeganə fərq, reyestr qeyd növü kimi xərcdən istifadə edilməsidir.
Sehrbazın kodu yaratmasına icazə vermək üçün “Ok” düyməsinə klikləyin:
Burada alacağımız kodda bəzi dəyişikliklər etmək lazımdır. Varsayılan olaraq, sehrbaz kodu aşağıdakı sətirlə işə salır:
Bu sətir müvafiq reyestri yazma rejiminə keçir. Prosedur davam edərkən reyestrə əlavə olunan bütün məlumatlar verilənlər bazasında avtomatik olaraq saxlanılır. Başqa sözlə, tərtibatçılar bu sətirlə prosedura başlaya, lazımi məlumatları əldə edə və bu məlumatları reyestrə yaza bilər. Və budur. 1C platforması prosedur başa çatdıqdan sonra məlumatları dərhal verilənlər bazasına əlavə edir. Təchizatçı faktura sənədini yaradarkən məhz bunu etdik.
Lakin satış fakturasının arxasındakı proses daha mürəkkəbdir, çünki biz cari anbar ehtiyatını bilməliyik. Bu o deməkdir ki, satış hesab-fakturasının yerləşdirilməsi reyestrə məlumatların əlavə edilməsi ilə yanaşı bəzi yoxlamalara başlamalıdır. Beləliklə, məlumatların reyestrə əlavə edilməsi prosesini idarə etmək üçün daha çox seçimimiz olmalıdır.
Bu tələbi nəzərə alaraq, təklif olunan kodu aşağıdakı kimi dəyişdirmək istəyirik. Sil (və ya şərh) RegisterRecords.ProductsInWarehouses.Write = True line. Məlumat əldə edildikdən dərhal sonra reyestrə məlumat əlavə etmək üçün açıq əmr əlavə edin. Bununla biz sistemə bildiririk ki, göndərmə proseduru başa çatmazdan ƏVVƏL reyestrə məlumat əlavə etsin.
Bir az sonra bunun nə üçün lazım olduğunu biləcəksiniz. Hələlik yeni yaradılmış satış hesab-fakturasının necə işlədiyini yoxlamağı təklif edirəm.
Dialoq rejimində 1C-ni işə salın, satış alt sisteminə keçin, yeni satış faktura sənədi yaradın və onu məlumatlarla doldurun. Sonra göndərin:
Anbarlardakı məhsulları yoxlayın və reyestrə əlavə edilmiş reyestrlərə baxın:
Gördüyümüz kimi, sənəd gözlənildiyi kimi işləyir. Başa çatdı?
Təsəvvür edək ki, anbarımızda 10 vahidimiz var və biz satış fakturamıza 15 ədəd əlavə etmək istəyirik. Sənədi yerləşdirəndə nə baş verəcək
Məsələ bundadır! Sistem sənədi problemsiz və səhvsiz yerləşdirir. Bu, 1C platformasının ehtiyat balansını idarə etməməsi səbəbindən baş verir və nəzəri olaraq, bu dəyər mənfi ola bilər.
Beləliklə, əgər ehtiyatları nəzarət altında saxlamaq lazımdırsa, biz tərtibatçılar olaraq ehtiyat balansının mənfi olub olmadığını yoxlayan və xəta və ya xəbərdarlıq qaytaran kod yaratmalıyıq.
Beləliklə, sənədin yerləşdirilməsi nəticəsində yaranan mənfi balansın diqqətdən yayınmamasını təmin etmək üçün sehrbaz kodunu bəzi sətirlərlə əlavə edirik.
Buna görə də biz RegisterRecords.ProductsInWarehouses.Write = True line şərhini verdik və proqram vahidinin tamamlanmasından dərhal sonra məlumatların yazılmasını aktiv etdik. Reyestrə məlumat əlavə etdikdən sonra ehtiyat balansının mənfi olub olmadığını yoxlaya bilərik.
İcazə verin bəzi nəzəriyyələri sizinlə bölüşüm. Balansın mənfi olub olmadığını yoxlamağın bir neçə yolu var.
Birinci seçim cari balansı yoxlamaq, sənədi yerləşdirməzdən əvvəl onu sənədimizdə göstərilən dəyərlə müqayisə etmək və ehtiyatın cari ehtiyacları ödəmək üçün kifayət olub-olmadığını yoxlamaqdır. Əslində, bu üsul olduqca məşhurdur, lakin bəzi gizli təhlükələri var.
Təsəvvür edin ki, məhsulları satmaq üçün istifadə edə biləcəyimiz tək bir iş stansiyası var. Satış fakturasını yerləşdirərkən, cari balansı yoxlayırıq, bunu göndərmək istədiyimiz məhsulların sayı ilə müqayisə edirik və anbar balansının mənfi olub olmadığını öyrənirik (yaxud öyrənə bilmirik). Bu vəziyyətdə hər şey gözlənildiyi kimi davam edir.
İndi gəlin bunu daha da mürəkkəbləşdirək. Bir şirkətin məhsul satmaq üçün istifadə etdiyi bir neçə, məsələn, 1000-ə qədər iş stansiyasımız var.
Bu halda iş stansiyalarının sayı daha da çox ola bilər. Düzgün quraşdırma ilə 1C bu yükün öhdəsindən asanlıqla gələ bilər.
Təsəvvür edin ki, biz eyni şeyi edirik: cari balansı yoxlayın və onu sənədimizdəki dəyərlə müqayisə edin. Bir an dayanın! Müqayisə ilə məşğul olsaq da, cari fond dəyişə bilər. Ətrafdakı min həmkardan kimsə eyni məhsul üçün satış fakturası hazırlayıb göndərə bilər.
Nəticə etibarı ilə, cari ehtiyatı yoxlamağa başladığımız zaman (bu, açıq-aydın köhnəlmişdir), məhsulun həmkarlarımızdan biri tərəfindən artıq satılması ehtimalı yaranır. Lakin biz bunu görə bilmədiyimiz üçün göndərmək heç bir səhv yaratmır. Və yalnız dərc etdikdən sonra məhsulun əskik olduğunu öyrənirik.
Nə edə bilərik? 1C DataLock adlı xüsusi bir obyekt təklif edərək problemi həll edir. Bu obyektdən istifadə etməklə biz bütün cədvəli (daha az arzuolunandır) və ya verilənlərin bir hissəsini (bu, daha yaxşı yoldur) kilidləyə, cari ehtiyatı yoxlaya və onu sənədimizdəki dəyərlə müqayisə edə bilərik.
Əslində, tərtibatçılar tez-tez 1C proqramlarında bu üsuldan istifadə edirlər və bu, yaxşı bir həlldir. Yenə də burada bir darboğaz var: biz hər dəfə sənəd göndərəndə məlumatları kilidləməliyik. Məhdud sayda əməliyyatlarla problemlər yaratmamalıdır. Yenə də yük artdıqca, daha çox yerləşdirmə bütün sistemin əhəmiyyətli dərəcədə yavaşlamasına səbəb olan məlumatların daha tez-tez kilidlənməsi ilə nəticələnir. Hər bir yeni sənəd məlumatın müvafiq hissəsinə giriş əldə etmək, onu kilidləmək, ehtiyatı yoxlamaq və s. üçün növbəyə qoşulur.
Buna görə də biz 1C şirkətində ehtiyat balansının idarə edilməsi ilə bağlı proseslər üçün fərqli reyestr yazma metodundan istifadə etməyi məsləhət görürük. Buradakı yanaşma heç bir yoxlama (və kilidləmə) olmadan məlumatların yazılması ilə başlamaq və yalnız bundan sonra balansın mənfi olub olmadığını yoxlamaqdır. Əgər ehtiyat balansı müsbətdirsə, hər şey qaydasındadır. Əks halda, sistem əməliyyatı geri qaytarır və qeydi reyestrdən çıxarır.
Bu üsul, birdən çox sənədin işlənməsinə ehtiyac olduğu yerlərdə ən yüksək emal sürətini təmin edir. Məlumatların kilidlənməsi tələbini aradan qaldırmaqla biz sistemin yavaşlamasının əsas səbəbini aradan qaldırırıq.
1C şirkətinin bu üsulu çoxsaylı əməliyyatlar tələb edən layihələr üçün tövsiyə etməsinin səbəbi də budur. Satış faktura sənədimizə tətbiq etmək istədiyimiz budur.
ehtiyat balansını idarə etmək üsulunun arxasında duran ideyanı sizə xatırlatmaq istəyirəm. Sənədlə bağlı bütün qeydləri reyestrə qoyuruq, sonra balansın mənfi olub olmadığını yoxlayırıq. Heç bir mənfi dəyər qaytarılmırsa, hər şey qaydasındadır və sənədimiz uğurla yerləşdirilir. Mənfi dəyər əməliyyatın geri qaytarılması ilə nəticələnir.
Bu, məlumatların reyestrə yazılması ilə bağlı hissəni tamamlayır. Məlumatların müqayisəsi olan ikinci hissəyə keçək. Bunun üçün cari ehtiyat balansını bilməliyik. Bu məqsədlə bəzi parametrlərlə sorğu yaradırıq. Siz sorğunu əl ilə kodlaya və ya aşağıdakı ekran görüntüsündə olduğu kimi Sorğu Sehrbazını seçə bilərsiniz:
Sehrbazı işə salın və sorğu parametrlərinizi təyin edin. Birinci tabı dəyişmədən buraxın:
Tələb olunan sahələri seçmək üçün ikinci tabdan istifadə edin. Bu sahələr Məhsulun özü, Kəmiyyətdir və buna diqqət yetirsəniz, Məhsul üçün Təqdimat sahəsini alırıq. Bu sahə müvafiq məhsul haqqında bəzi məlumatları təqdim etmək üçün faydalı ola bilər. Burada mənfi ehtiyat balansı haqqında məlumat vermək üçün istifadə etmək istəyirik.
İndi diqqətinizi çəkmək istədiyim çox vacib bir məqam var. Müəyyən bir anbarda müəyyən bir məhsul üçün cari ehtiyat balansını bilməliyik. Beləliklə, sorğuya müvafiq parametrləri daxil etməliyik. Burada tərtibatçılar bəzən bu cür parametrləri düzgün təyin etməkdə çətinlik çəkirlər.
Bunun səbəbi odur ki, biz çox vaxt Şərtlər (Conditions) bölməsini istifadə edərək parametrləri təyin edirik:
Nəzərinizə çatdırım ki, yığım reyestrləri verilənlər bazası daxilində saxlanılan sadə cədvəllərdir. Yenə də bu əsas cədvələ əlavə olaraq, 1C platforması reyestrdəki balansları və dövriyyələri saxlamaq üçün hər reyestrdə bir neçə virtual yaradır. Bu barədə silsiləmizin ilk məqaləsində ətraflı danışdıq.
Siz qeyd etmisiniz ki, mən məlumatları ProductsInWarehouses əsas reyestr cədvəlindən deyil, ehtiyat balansı üçün ProductsInWarehousesBalance virtual cədvəlindən almışam. Bu hərəkətin məqsədi nədir? Cavab sadədir. Bu, emal sürətini əhəmiyyətli dərəcədə artırmaq üçün bir yoldur. Virtual cədvələ edilən sorğu cavabı daha sürətli qaytarır.
Lakin reyestrin virtual cədvəllərinin öz parametrləri var. Əgər onlar varsa, sistem əvvəlcə onları tətbiq edir.
Biz anbar üzrə məhsul seçmək üçün virtual cədvəldən istifadə edə və ya bu seçim şərtini birbaşa sorğu parametrlərinə əlavə edə bilərik. Virtual masa seçiminə sadiq qalsaq, həll daha sürətli işləyir. Bu, virtual cədvəllə sorğunun SQL serveri tərəfindən əvvəlcədən süzülmüş məlumatlarla məşğul olması ilə əlaqədardır. Beləliklə, filtrasiya əvvəlcə burada baş verir. İkinci halda, sorğu bütün anbarlar üzrə məlumatları qaytarır və yalnız bundan sonra filtr tətbiq edir. Beləliklə, birinci həllin daha yüksək emal sürəti təklif etməsi olduqca təbiidir.
Bu məlumatları nəzərə alaraq, ProductsInWarehousesBalance virtual cədvəli üçün parametrləri təyin etməyə davam edirik. Bunu belə edirsiniz:
Balanslarımıza tətbiq etmək istədiyimiz dövrü təyin etməklə başlayırıq:
Sonra virtual cədvəlin parametrlərini təyin edirik:
Kəmiyyətin (Məhsulun Kəmiyyəti) virtual cədvələ daxil edilmədiyini görmək asandır və xatırladığınız kimi, mənfi ehtiyat balansı olan məhsulları seçməliyik. Beləliklə, bizə hələ də Şərtlər bölməsinə ən azı bir parametr lazımdır.
Bölməyə qayıdın və lazımi tənzimləmələri edin:
Bundan sonra sehrbazı bağlaya bilərik (dəyişiklikləri saxlamaq üçün OK düyməsini basdığınızdan əmin olun) və aşağıdakı kodu əldə edə bilərsiniz:
Əsasən, o, üç hissədən ibarətdir: sorğunun mətni, sorğu parametrləri və cavabın işlənməsi.
Cavabın mətnini toxunulmaz saxlayırıq və parametrlərə davam edirik.
Anbar parametri ilə başlayın. Burada olduqca sadədir; biz onu sənəddə seçilmiş anbara bərabər qoyuruq.
Məhsullar parametri üçün IN strukturundan istifadə edirik. Beləliklə, bu parametr ya siyahı, ya da dəyərlər massivi olmalıdır. İndi kodu dəyişdirərək onu yaradaq.
Bütün məhsullarla birlikdə cədvəldən ibarət massiv dəyərlərini yaratmaq üçün UnloadColumn() metodundan istifadə edə bilərik. Bunun üçün kod budur:
İndi Limit parametrini təyin etmək vaxtıdır. Sistemin düzgün işləməsi üçün düzgün dəyərin seçilməsi çox vacibdir.
Davam etməzdən əvvəl, mənfi ehtiyat balansına nəzarət metodu anlayışını daha da dərinləşdirək. Yadınızdadırsa, biz balansı sənədimizdə göstərilən dəyərlə müqayisə etməyə başlayanda və yalnız bundan sonra sənədimizi dərc edib-etməməyimizə (əgər ehtiyat kifayətdirsə) və ya olmamağa (məhsulların sayı kifayət deyilsə) qərar verdiyimiz zaman. Buna görə də cari ehtiyat balansını bilmək bizim üçün çox vacibdir. Bu məqsədlə məlumatları bir müddət kilidləyirik ki, heç kim onu dəyişdirə bilməsin, biz cari ehtiyat məlumatlarını alırıq, dəyərləri müqayisə edirik və göndəririk (və ya əməliyyatı ləğv edirik). Bu o deməkdir ki, bu üsul bizdən balansımızı bir müddət toxunulmaz saxlamaq üçün açıq şəkildə proqram məlumat kilidi qoymağı tələb edir.
Sənədimizdə istifadə etmək istədiyimiz metodda olduğu kimi (və yenə də bu, çox tövsiyə etdiyimiz yanaşmadır), biz qeydləri reyestrimizə əlavə edirik və yalnız bundan sonra ehtiyat balansının mənfi olub olmadığını yoxlayırıq. Sistemdən əldə etdiyimiz cari ehtiyat dəyərinin düzgün olduğuna necə əmin ola bilərik? Yuxarıdakı vəziyyətdə etdiyimiz kimi məlumatları kilidləməliyikmi?
Xoşbəxtlikdən, burada işlər daha sadədir: biz məlumatların kilidlənməsi ehtiyacını aradan qaldıra və prosesi əhəmiyyətli dərəcədə sürətləndirə bilərik. Bəs məlumatları kilidləmədən düzgün rəqəmləri necə əldə edə bilərik? Bunu izah etmək üçün iki obyekti qeyd etməliyik: Boundary və PointInTime.
1C-də hər bir sənəd tarix və vaxtı birləşdirən tarix atributuna malikdir. Başqa sözlə, hər 1C sənədində saniyə dəqiqliyi olan vaxt nişanı var. Təbii ki, iki sənəddə eyni iki vaxt nişanı olub-ola bilməməsi sualı yaranır. Bəs onlar eyni saniyədə yaradılsaydı?
Bu mümkündür. Eyni saniyədə iki və ya daha çox sənəd yaradıla bilər. Beləliklə, ikinci suala gəlirik. Yaradılan sənədlərin düzgün ardıcıllığını necə bilə bilərik? İstifadəçilər hamısını eyni saniyədə göndərirsə, hansı birinci gəlir?
Bunun üçün 1С-də PointInTime adlı xüsusi obyekt var. Tarixi (saniyəlik dəqiqliklə) və konkret sənəd ola bilən obyektə istinadı birləşdirir. 1C-də mövcud olan hər bir sənəddə PointInTime var ki, bu da onu sıralamanın müəyyən bir nöqtəsində yerləşdirir. Beləliklə, eyni tarix və vaxt (və eyni saniyə) olan iki sənəd daxil etsək belə, PointInTime hər bir sənəd üçün fərqlidir və belə sənədləri düzgün ardıcıllıqla sıralamaq asandır.
Məqsədimiz çərçivəsində PointInTime bizə sənədimizin qrafikdə harada olduğunu bilməyə və həmin an üçün ehtiyat balansını əldə etməyə kömək edir.
İzləyəcəyimiz digər əhəmiyyətli obyekt limitdir (Boundary). Müəyyən intervalları təyin etmək üçün ondan istifadə edirik. O, limit dəyərini və bu dəyərin müəyyən diapazona daxil olub-olmaması şərtini müəyyənləşdirir. Limit dəyərini daxil etmək və ya xaric etmək vacib olduqda Boundary istifadə edirik. Buna görə də, bu seçim hesabatları və inventar qalıqlarını və ya dövriyyələri, icmalları və sorğuları qeyd etmək üçün faydalıdır.
Nəzərdən keçirilən tapşırıqda qeydi reyestrimizə əlavə etdikdən sonra cari ehtiyat balansını dəqiq təsvir etmək üçün Boundary obyektinə ehtiyacımız var. Sərhədi müəyyən etmək üçün bizə iki parametr lazımdır: Sənədin PointInTime və BoundaryType. Bu BoundaryType Boundary dəyərinin aralığa daxil edilib-edilmədiyini göstərir. Bizim vəziyyətimizdə, sənədimiz tərəfindən irəli sürülənlər də daxil olmaqla, bütün qeydləri ehtiva etmək üçün reyestrin balansına ehtiyacımız var. Bu o deməkdir ki, BoundaryType Include dəyərinə malik olmalıdır.
Yuxarıdakı sorğuda Boundary parametrinə qayıdaq. Bu parametrli kod belə görünməlidir:
Biz Boundary obyektini yaradırıq, sonra sənədin PointInTime parametrini birinci parametr kimi, BoundaryType isə ikinci parametr kimi əlavə edirik. Sərhəd dəsti ilə sistem sənədimiz tərəfindən təqdim edilən qeydlər hesabına cari ehtiyat balansını hesablayır. Məlumatların kilidlənməsinə ehtiyac olmadığı üçün emal həqiqətən sürətlə baş verir.
Aşağıdakıları nəzərdən keçirin. Təsəvvür edin ki, bizim cari sənədimizdə edilən dəyişiklikləri OLMAYAN bir ehtiyat balansına ehtiyacımız var. Bu halda kod belə görünməlidir:
Beləliklə, müəyyən bir vaxt üçün ehtiyat balansını alırıq, lakin sənəddə olan bütün qeydlər atlanır.
İşimizə qayıtmağın vaxtı gəldi. Parametrlər bölməsi belə görünməlidir:
Kodun növbəti hissəsi sorğu nəticələrimizdən bəhs edir. Nəzərə alın ki, sorğu yalnız sənədimizi dərc etməyə cəhd etdikdə balans mənfi olarsa, cavab qaytarır.
Nəticə etibarilə, sorğunun nəticəsini emal etməliyik. Sorğu hər hansı bir dəyər qaytararsa, istifadəçiyə kifayət qədər ehtiyatın olmaması barədə məlumat verməliyik və sənədi geri qaytarmalıyıq.
Bu məlumatı nəzərə alaraq kodun belə görünməsini gözləməliyik:
İnanıram ki, burada hər şey aydındır və əlavə şərhə ehtiyac yoxdur.
Sənədimizi işlək vəziyyətdə yoxlayaq. Dialoq rejimində 1C-ni işə salın və yeni SalesInvoice sənədi yaradın. Cari ehtiyatı aşan miqdarda məhsul əlavə edin:
Sənədi göndərməyə çalışın. Birincisi, göndərmə xətası mesajı alırıq:
Sonra isə qeyri-kafi miqdar haqqında bildiriş.
Beləliklə, proqram yerləşdirmə zamanı ehtiyat balansını yoxlayır və mənfi dəyərə səbəb ola biləcək qeydin yaradılmasının qarşısını alır.
Deyəsən, hər şeyi yekunlaşdırmağın vaxtıdır. Məhsulların müştərilərə satışına imkan verən SalesInvoice sənədimizi yaratdıq. Bu sənədlə əvvəllər yaradılmış SupplierInvoice arasındakı əhəmiyyətli fərq ondan ibarətdir ki, burada sənədi yerləşdirməzdən əvvəl cari ehtiyat qalıqlarını yoxlamaq lazımdır. Həllini həyata keçirmək üçün iki mümkün üsulu nəzərdən keçirdik və ən yüksək emal sürətini təmin edən birini seçdik.
Növbəti dəfə anbarlarımızın ehtiyat balanslarını tez idarə etmək üçün hesabatların necə yaradılacağını öyrənəcəyik.