Əsaslardan başlayaq, yəni 1C platforması məlumatları necə saxlayır. Lakin əvvəlcə xatırlamaq lazımdır ki, 1C, Java kimi universal proqramlaşdırma dili deyil, daha çox biznes proqramlarını sürətlə dizayn etmək üçün istifadə olunan xüsusi dildir. Bəzən 1C platforması biznes proqramlarının dizaynı üçün xüsusi təyinatlı çərçivə kimi təsvir olunur. Bunun səbəbi platformada artıq tərtibatçıları yaratmaq üçün SQL cədvəllərinin sayı haqqında düşünməkdən xilas edən mexanizmlərə malik olmasıdır (birə qarşı birdən çox). Beləliklə, 1C tərtibatçıları verilənlər bazası cədvəllərini (SQL cədvəlləri) bilavasitə idarə etməyə ehtiyac olmayan daha yüksək səviyyədə, yəni biznes məntiqi səviyyəsində proqram tərtib etməkdən həzz ala bilərlər. Burada onlar sənədlər, kataloqlar və s. adlanan obyektlərlə (və ya varlıqlarla) işləyirlər. Beləliklə, biz bu obyektlər haqqında çox vaxt danışacağıq, lakin bəzən məlumatların SQL serverlərində saxlanıldığı daha aşağı səviyyəyə “düşürük”.
Fərz edək ki, tədarükçülərdən məhsul alan, onları anbarlara yerləşdirən və sonra bu cür məhsulları baha qiymətə satan şirkətdə əməliyyatları avtomatlaşdırmalıyıq. Təbii ki, şirkət rəhbərliyi mövcud vəziyyətlə bağlı ən son məlumata malik olmalıdır: anbar inventarları, müəyyən dövr üçün satış dəyəri, kreditor borcları və ən əsası mənfəət. Tapşırığı hissələrə ayıracağıq və anbar inventarının uçotu ilə başlayacağıq.
Gəlin burada dayanaq və mühasibat uçotu əl ilə aparılarkən biznes şirkətinin necə fəaliyyət göstərməsi barədə düşünməyə bir az vaxt ayıraq. Belə bir şey təsəvvür edək. Katib anbarın çatdırılmasının sübutu kimi təchizatçı hesab-fakturasını alır və hesab-fakturanı təyin olunmuş qovluğa yerləşdirir. Menecer öz anbarında nə qədər inventar olduğunu bilməli olduqda, məmur bütün hesab-fakturaları götürür, onlarda göstərilən məhsulların ümumi sayını hesablayır və hesabatı müdirə verir. Bu cür məlumat axışı aşağıdakı kimi görünür:
Əvvəlcə məmur sənədləri qəbul edir. Sonra menecerin tələbi ilə kargüzar hesabat yaratmaq üçün sənədlərdən istifadə edir. Başqa sözlə, bu tənzimləmə ilə bütün məlumatlar sənədlərdə saxlanılır və belə məlumatların təhlilinə ehtiyac olduqda (məsələn, cari ehtiyatı yoxlayın) onlar bütün bu sənədləri toplayıb emal etməlidirlər.
Gəlin görək bu yanaşmanı SQL ilə necə tətbiq edə bilərik. Bu halda, faktura INVOICES SQL cədvəlinə uyğun gəlir.
Əslində kifayət qədər asan görünür. İstədiyimiz dəyərləri (bizim vəziyyətimizdə stok balansı kimi) SQL server alətlərindən istifadə edərək hər zaman yekunlaşdıra və tələb olunan hesabatı yarada bilərik. Amma indi fərz edək ki, şirkətimiz hər gün yüzlərlə təchizatçı faktura alır və bu şirkət illərdir fəaliyyət göstərir bu halda INVOICES SQL cədvəli daim böyüyəcəkdir. Nəticədə, hər gün hesabat yaratmaq üçün daha çox vaxt lazım olacaq. Bu, stok balansı hesabatını hazırlamazdan əvvəl bütün şirkətin əməliyyatları üçün məlumatların ümumiləşdirilməsi üçün SQL serverinə ehtiyac olması ilə bağlıdır. Etiraf etməliyik ki, bu heç də praktik deyil. Hətta daha çox, içindən çıxılmaz bir vəziyyətə gəlir. 1C platformasının üstünlüyü ondan ibarətdir ki, o, məlumatların işlənməsini optimallaşdırmaq üçün həll təklif edir. Yuxarıdakı diaqramda sənədlər və hesabatlar arasında daha bir növ obyekt əlavə etmək istəyirik. Biz onları qeydlər adlandırırıq.
Bu necə işləyir. Katibimiz tədarükçülərin sənədlərini əvvəlki kimi emal edir və onları qovluğa qoyur. Bununla belə, vaxtaşırı, məsələn, bir az boş vaxt olduqda, məmur yekun sənədlərə qayıdır, hazırda şirkətin anbarında nə qədər məhsul olduğunu təxmin edir və əldə edilmiş rəqəmləri müəyyən bir kitaba yazır. Rəhbərliyin mövcud ehtiyat haqqında məlumat vermək tələbi ilə, katib çoxlu sayda fakturalarla işləmək əvəzinə kitabı açır və ən son nömrəni alır. Bu o deməkdir ki, baxdığımız sənədlərin sayından asılı olmayaraq hesabat daha tez hazırlanır.
Başqa sözlə, katibin yeni hesabatlar yaratmaq üçün istifadə olunan məlumatları saxlamaq üçün bir aralıq yeri var və bu yer və daha sonra yeni hesabatlar yaratmaq üçün istifadə olunur.
Məlumatların aralıq yerdə saxlanması prinsipi 1C platformasının əsasını təşkil edir. Fərq ondadır ki, biz hesablama nəticələrini saxlamaq üçün məmur dəftərini, bir toplama qeydi adlanan obyektlə əvəz edirik.
Qeyd edək ki, 1C platformasının qeyd adlanan neçə obyekti var. Onlar mühasibat uçotu, hesablama qeydləri və məlumat qeydləridir. Bu obyektlərin hamısı vacibdir və hamısını vaxtında müzakirə etmək istəyirik. Bununla birlikdə, toplama qeydləri ən əhəmiyyətli olanlardır, çünki onlar platforma mexanizmləri tərəfindən məlumatların idarə edilməsini təmin edirlər.
Beləliklə, 1C platforması sənədlərdən kənarda məlumatları saxlamağa imkan verən bir mexanizmi var. Təbii ki, bir neçə sual yaranır. Bir qeyddə hansı məlumatları saxlamaq olar? Məlumat bir qeydə necə daxil olur? Bir sistemdə neçə qeyd ola bilər?
Tutaq ki, 1C sənədi kimi tədarükçü fakturamız var. Çox sayda atributu var: sənəd tarixi və nömrəsi, məhsulların çatdırılması tarixi, məhsulları, təchizatçı adını və müvafiq müqaviləsi, məhsulları anbarına çatdıran bir göndərmə şirkəti olan bir anbar Stokda olan əşyaların siyahısını, o cümlədən hər bir elementin miqdarını yaratmaq üçün hansı atributlara ehtiyacımız var? Bu sadə sualdır, çünki biz yalnız məhsulun adını və onun mövcud miqdarını bilməliyik. Budur əldə etdiyimiz məlumat strukturu:
Nəzərinizə çatdırım ki, anbar ehtiyatımızın balansını qiymətləndirmək üçün heç bir əlavə məlumat tələb olunmur. Əldə etdiyimiz məlumatlar, şübhəsiz ki, kifayətdir. Əslində, biz indi gələcək qeyd üçün bir struktur hazırlamışıq. Təbii ki, real həyat qeydi burada istifadə etdiyimizdən bir qədər mürəkkəbdir, lakin bu, məlumatların saxlanması yanaşmasını göstərmək üçün kifayətdir. Teorik olaraq, qeyd istənilən məlumatı saxlaya və istədiyiniz kimi təqdim edə bilər. Bununla belə, bir məhdudiyyət var: qeydin ölçüləri (atributları, sahələr) nə qədər azdırsa, o qədər yüksək oxuma və yazma qabiliyyəti təmin edə bilər. Başqa sözlə, ehtiyat balansını qiymətləndirmək üçün yalnız iki sahəyə (məhsul və kəmiyyət) ehtiyacımız varsa, biz yalnız bu iki sahədən istifadə etməli və təchizatçı sahəsini bu qeydə əlavə etməkdən çəkinməliyik.
Növbəti sual, məlumatları bir reyestrə necə qoyduğumuzdur. Qeydlər 1C platforması çərçivəsində müstəqil obyekt olduğundan, məlumat əlavə etmək üçün avtomatik bir proses yoxdur. Yaradıcılar, tətbiq olunan məlumatları bir qeyd-ə yazmaq üçün bir proqram kodu dizayn etməlidirlər. Məlumat yazmaq üçün platformada xüsusi bir proses (və ya mexanizm) var. Göndərmə adlanır.
Bir daha qeyd edək ki, yerləşdirmə, sistemə sənəd əlavə etdikdən sonra məlumatları qeydə (və ya qeydlərə) yazan bir mexanizmdir.
Real həyat ssenarisində məmur 1C proqramında təchizatçı faktura sənədi yaradır, onu müvafiq məlumatlarla doldurur və Göndər düyməsini sıxır. Bunu etməklə, məmur sistemə sənədi saxlamağı əmr edir (və müvafiq sətirləri DBMS cədvəllərinə daxil edin) və sonra əvvəlcədən təyin edilmiş göndərmə prosedurunu işə salır. Tətbiq olunan alqoritm kodu belə görünür:
Yenə də bizə aid bəzi kodlar əlavə etməliyik. Kodun məqsədi etibarlı qeydlərə qeyd əlavə etməkdir. Əsasən, sənədin təqdim edilməsi proseduru iki hissədən ibarətdir: sənədin saxlanması və məlumatların qeydə yazılması.
Daha da dərinə enmək istəyənlər başa düşməlidirlər ki, biz həm sənədə, həm də qeydə məlumat yazarkən, əslində onu kopyalayırıq. O zaman, bunun pis bir şey olduğunu düşünə bilərsiniz. Və mən bunu qəbul etməkdən başqa heç nə edə bilmirəm. Teorik olaraq, məlumatların təkrarlanması sənəd məlumatlarının və qeyd məlumatlarının fərqli olduğu vəziyyətə səbəb ola bilər. Məsələn, təchizatçı hesab-fakturasını təqdim edərkən, bir məhsulun anbar daxili miqdarını artırmalıyıq. Bununla belə, tərtibatçı təqdimetmə proseduru zamanı səhv edə və dəyəri aşağı sala bilər. Bu səbəbdən tərtibatçıların düzgün və yaxşı kodu tərtib etmək üçün böyük məsuliyyəti var. Digər tərəfdən, məlumatların saxlanması və hesabatların yaradılması üçün qeydlərdən istifadə bizə sistemin performansını əhəmiyyətli dərəcədə artırmağa imkan verir, çünki qeydlər lazımsız məlumatların əvəzinə normallaşdırılmış məlumatları saxlayır. Səhm balansı üçün yalnız iki atributdan (sahələrdən) istifadə etdiyimizi hələ də xatırlayırsınız: məhsul və miqdar?
Sistemdə ola biləcək qeydlərin sayı ilə bağlı növbəti sual əvvəlkinin təbii davamıdır. Tutaq ki, biz yuxarıda təsvir olunduğu kimi səhm balansını saxlamaq üçün qeyd yaratdıq. Və birdən-birə rəhbərlik bizə kreditor borclarına da nəzarət etməli olduğumuzu deyir. Bu tapşırığı yerinə yetirməyin ən asan yolu nədir? Qeydə yeni sahələr əlavə edə bilərikmi? Qeyd edək ki, biz bu postu xüsusi olaraq səhm balansı üçün hazırladıq. Ödənişləri uçota alan struktur yoxdur. Həll olaraq nədən istifadə etməliyik?
Təchizatçı ilə bağlı ödənişlər haqqında məlumatları saxlamaq üçün fərqli (tamamilə fərqli!) atributlar (sahələr) dəsti ilə daha bir qeyd yaradırıq. Bu qeyd dəftərindəki məlumatlara əsasən, rəhbərlik kreditor borcları haqqında ən son məlumatları əldə edə bilər. Yuxarıda qeyd edildiyi kimi, məlumatlar avtomatik olaraq yeni qeydə əlavə edilmir. Tərtibatçılar tərəfindən redaktə edilməlidir. Saxlama prosedurunu dəyişdirməklə buna nail ola bilərik ki, sənədin saxlanması məlumatların yeni qeydə əlavə edilməsi ilə nəticələnir.
Sistemdəki qeydlərin limiti ilə bağlı suala gəlincə, cavab sadədir. Tapşırığın tələb etdiyi qədər əlavə edə bilərsiniz. Əsas qayda ondan ibarətdir ki, optimal yazma və oxuma sürətini təmin etmək üçün qeyd strukturu (əslində qeyddə saxlanılan verilənlər serverlər tərəfindən verilənləri saxlamaq üçün istifadə olunan SQL cədvəlidir) normallaşdırılmalıdır. Yüksək sistem tutumu əldə etmək üçün əsas şərtdir.
İndi ehtiyat balansını emal edən kassa aparatına qayıdaq. Biz onun strukturunu tərtib etdik, lakin yuxarıda qeyd edildiyi kimi, real həyat rekordu, ehtimal ki, ehtiva etdiyi əlavə xidmət domenləri (atributları) səbəbindən daha mürəkkəb olardı. Bir qeyddəki sənəd axını diaqramı belə görünə bilər:
Bu xidmət xüsusiyyətlərinə (sahələrə) daha yaxından baxın. Aydındır ki, dövr sahəsi (tarix növü) məlumatın qeydə əlavə olunduğu tarixi əks etdirir.
Qeydiyyatçı sahəsi cərgəni qeyddə qeydə alınmış məlumat mənbəyi olan sənədlə əlaqələndirir. Bu sahə bizi birbaşa qeyddən sənədə apara biləcəyi üçün çox vacibdir.
Digər vacib sahə qeyd növüdür. Bu, təchizatçılardan məhsul aldığımızı və ya müştərilərimizə satdığımızı göstərmək üçün lazımdır. Onun alınması halında 1C platforması kassada olan məhsulların miqdarını artırmalı, satıldıqda isə dəyərini aşağı salmalıdır. Beləliklə, kontekstdən asılı olaraq, qeyd növü sahəsinin əməliyyat növünü göstərdiyini görə bilərsiniz. Təchizatçı sənədləri üçün bu qəbz, satış sənədləri üçün isə xərc olmalıdır.
Son xidmət sahəsi mənbə sənədində sətir nömrəsi olan sətir nömrəsidir. Təchizatçı hesab-fakturalarında qeydə əlavə edilmiş məlumatlar olan cədvəl olduğundan, cədvəldəki hər bir sətri müəyyən etmək üçün bizə sıra nömrəsi lazımdır.
İndi bir az vaxt ayıraq və məlumatların saxlanması və axtarışı ilə bağlı tapşırıqlara qayıdaq. Ümumiyyətlə, məlumat toplamaq üçün iki yol var. Seçim 1 müəyyən bir tarixə qədər nə qədər yığılıb sualına cavab verməkdir və 2-ci seçim müəyyən bir müddət ərzində nə qədər yığılmışdır.
Buna görə də, birinci yanaşma anbar ehtiyatı balansı kimi anbarla bağlı məlumatların saxlanması və əldə edilməsi üçün işləyir. Bundan əlavə, biz mühasibat kitablarına maddələr əlavə edə bilərik (maddə əməliyyatı və ya qəbz üçün müsbət dəyər) və ya silə bilərik (satış, xərc və ya maddə əməliyyatı üçün mənfi dəyər və ya). Bu qeydi tərtib etmək üçün istifadə etdiyimiz saxlama üsulu məhz budur.
Yenə də bu, başqa bir iş növü ola bilər. Təsəvvür edin ki, son bir ayda satılan məhsulların miqdarını bilməliyik. Bu halda, müəyyən bir tarix üçün səhm balansı bizi maraqlandırmır. Bunun əvəzinə, müəyyən bir dövrdə satılan məhsulun miqdarını, yəni dövriyyəni bilməliyik. Bu cür məlumatları saxlamaq üçün 1C fərqli bir qeydiyyat növündən istifadə edir.
Texniki cəhətdən, 1C platformasında yığılma qeydi obyekti iki növ ola bilər - balanslar və ya dövriyyələr. Bir qeyd yaradarkən müəyyən edirik:
Bu məlumatlara əsaslanaraq, indi dizayn etdiyimiz kassa (biz onu məhsul balansları üçün istifadə etmək istəyirik, bildiyiniz kimi) qalıqlar olmalıdır. Bu cür mühasibat dəftərində iki növ qeyd ola bilər, qəbz və xərc.
Transfer qeydləri yalnız köçürmələrlə məşğul olur və heç bir qeyd növü sahəsi yoxdur. Əlbəttə ki, biz bu cür kassalara lazımi diqqət yetirməyi planlaşdırırıq, lakin hələlik balans üçün kassalara qayıdaq.
1C platformasının emal gücünün qeydlərdə məlumatların saxlanmasından gəldiyini gördük. Standart qeydin məlumat saxlama strukturu belə görünə bilər:
Əsasən, bu SQL düz cədvəlidir. "Gözlə! Təkmil emal gücü haradan gəlir? Sənəddəki SQL cədvəlindən və ya qeyddəki SQL cədvəlindən məlumatlara əsaslanan hesabat yaratmaq arasında fərq varmı? Hər iki halda oxumaq və yazma qabiliyyəti təxminən eyni olmamalıdırmı?
Burada biz tədricən 1C-də məlumatların saxlanmasının ikinci əsas qaydasına keçirik (birincisi, qeydlərdə məlumatların saxlanmasıdır). Qeydlərdən məlumatların sürətli oxunmasını təmin etmək üçün (qeyd edirəm, OXUNMASI deyirəm, YAZILMASI yox) platforma aralıq balansları saxlamaq üçün hər bir mövcud qeyd üçün avtomatik olaraq əlavə DBMS cədvəli yaradır (bu, əslində standart DBMS düz cədvəlidir).
Bu nədir və bizə nə üçün lazımdır? Aşağıdakı sxemə baxın:
Yuxarıda qeyddə əsas cədvəl olan sənəd axını cədvəli var. Sənəd təqdimetmə məlumatlarını saxladığımız yer budur. İkinci cədvəl, tərtibatçının yeni qeydiyyat yaratmasından dərhal sonra 1C platformasının avtomatik olaraq yaratdığı balansları əks etdirir. Bundan əlavə, tərtibatçılar bu cədvələ məlumat əlavə edə bilməzlər, çünki yalnız 1C edə bilər. Nə cür məlumatlar?
Bilmək vacibdir ki, bu cədvəl hər ayın sonu üçün qüvvədə olan hər bir qeydin ölçüsü (sahəsi, atributu) üçün ümumi qalıqları saxlayır. Yenidən diaqrama baxın: sistem 1-ci maddə və 2-ci maddə üzrə ayın sonuna qalıqları hesablayıb. Qeyd edək ki, 1C platforması avtomatik olaraq hər qeydiyyat üçün qalıqları hesablayır. Nə tərtibatçılar, nə də istifadəçilər bu prosesə müdaxilə edə bilməzlər. Bunu bilmək və anlamaq çox vacibdir.
Yaxşı, biz hər bir məhsul üçün ümumi qalıqları hesabladıq, lakin bununla emal qabiliyyətini necə yaxşılaşdıra bilərik? Tutaq ki, 6 fevral 2020-ci il tarixinə 1-ci maddənin balansını bilməliyik. Əgər balans hesabatı yoxdursa, həmin tarixə qədər olan dövrü əhatə edən bütün məhsul qəbzlərini emal etməliyik. Yuxarıda izah edildiyi kimi, bu yanaşma sistemi yavaşlatır. Lakin balans cədvəlindən istifadə etsək, məlumatların axtarışı prosesi xeyli sürətlənir. Hər ay üçün balansımız olsa da, 2020-ci ilin yanvar ayının sonu (29 ədəd) üçün Maddə 1 balansından istifadə edə və 1-6 fevral (3 + 10 ədəd) arasında əlavə edilmiş qeydlərlə yekunlaşdıra bilərik. Cəmi 42:
Bu misal olduqca sadədir, lakin məlumatların saxlanması və ən əsası geridə qalan qeydlərdə məlumatların oxunmasının necə baş verdiyini göstərir. Böyük həcmdə məlumatların və ara toplamların saxlanması əhəmiyyətli performans faydası deməkdir.
Nəzərə alın ki, sistem bütün aralıqları avtomatik hesablayır və heç bir tərtibatçının iştirakını tələb etmir. Məlumatların oxunması eyni şəkildə baş verir. 6 Fevral üçün Maddə 1 balansı kimi məlumatları tələb edirik. 1C platforması tərtibatçıların heç bir müdaxiləsi olmadan cəmlər üçün cədvəldən avtomatik olaraq ara cəmi götürür və sənəd axını cədvəlindən qeydləri toplayır. Məhz bu yanaşma 1C platformasını bu qədər güclü edir və böyük həcmdə verilənləri idarə edə bilir.
Yuxarıda qeyd edildiyi kimi, əmanət qeydinin daha bir növü var: dövriyyə rekordu. Bunu bir az sonra daha ətraflı müzakirə etməliyik. Hələlik qeyd edək ki, belə bir rekordun yekunlar üçün cədvəli yoxdur (bu, təəccüblüdür, elə deyilmi?). Bunun əvəzinə, 1C platforması dövriyyələr üçün cədvəl ilə dövriyyə rekordunu təqdim edir. Dövriyyə cədvəli, cəmlər üçün cədvəldə olduğu kimi, hesablanmış aylıq dövriyyələri saxlayır. Müəyyən bir dövr üçün dövriyyə dəyəri tələb olunduqda, platforma dövriyyə cədvəlindən hesablanmış məlumatları götürür və onu xam dövr üçün məlumatlarla ümumiləşdirir. Alqoritm balans elanları ilə eynidir.