Svojstvo je osnovna dimenzija registra izračuna. Složeni periodični izračuni Prihvatit će izračun na jeziku 1s

Pri radu s obračunskim registrima moguće je dobiti osnovne podatke. Ovo je osebujan način izračunavanja registarskog prometa, u kojem funkcija obračuna prometa nije jednostavna funkcija zbrajanja registarskih resursa mjerenjima za određeno razdoblje, već je više složena funkcija. Ova funkcija ovisi o statusu plana tipa izračuna koji je dodijeljen knjizi obračuna i stoga je kontrolira korisnik.

U ovom odjeljku ćemo razmotriti dvije metode za dobivanje osnovnih podataka koji postoje u sustavu - korištenjem upitnog jezika i korištenjem funkcionalne notacije, metodom GetBase(). U ovom slučaju "glavnim" obračunskim registrom nazvat ćemo registar za koji je potrebno pribaviti osnovne podatke, a "baznim" registrima (kojih u općem slučaju može biti više) bit će oni registri za koje se vrši se zbrajanje resursa.

Nećemo detaljno razmatrati ove metode, razmotrit ćemo samo njihove razlike i opseg.

Metoda GetBase().

metoda GetBase() definiran za objekte RegisterCalculationManager.<Имя регистра расчета> I RegisterCalculationRecord.<Имя регистра расчета> . Metoda omogućuje postavljanje resursa baznih registara za koje trebate dobiti promete, postavljanje polja u čijem kontekstu trebate dobiti promete i postavljanje pravila za usporedbu mjerenja glavnog i baznog obračunskog registra. .

Pravila za usklađivanje zapisa računskih registara određena su strukturom, čiji svaki element specificira za jednu ili drugu dimenziju glavnog registra popis mjerenja osnovnih registara proračuna. Nazivi elemenata strukture moraju odgovarati nazivima mjera glavnog registra, a vrijednosti elemenata strukture moraju biti nizovi, s popisom mjera osnovnih registara odvojenim zarezima. Ako strukturni element s nazivom jedne ili druge dimenzije nije naveden, to znači da se na odgovarajuću dimenziju ne postavlja nikakav uvjet.

Nazivi dimenzija i resursa baznih registara navedeni su u formatu<ИмяРегистраРасчета>.<ИмяПоля>.

Primjer korištenja metode:
Kod 1C v 8.x Resursi = Novi niz(1);
Resursi = "Osnovna razgraničenja. Rezultat, Dodatna razgraničenja. Rezultat";

Dimenzije = Nova struktura ("Pojedinac, organizacija");
Dimensions.Individual = "Osnovna razgraničenja.Pojedinac,Dodatna razgraničenja.Zaposlenik";
Dimensions.Organization = "Osnovna.Organizacija.Organizacija,Dodatna.Organizacija.Organizacija";

Kriške = Novi niz(1);
Sekcije = "Osnovna razgraničenja. Metoda, Dodatna razgraničenja. Metoda";
// Izračunajte baseBaseDataTable = Calculation.Retention Register.GetBase(Selection,
// Resursi, dimenzije, odjeljci);

U gornjem primjeru, dimenzija "Pojedinac" glavnog registra, prilikom primanja prometa, uspoređivat će se s dimenzijom "Pojedinac" osnovnog registra "Osnovna razgraničenja" i dimenzijom "Zaposleni" osnovnog registra "Dodatna razgraničenja". .

Tablica jezika upita za dobivanje osnovnih podataka
Za dobivanje osnovnih podataka u upitnom jeziku definirane su virtualne tablice „Obračunski registar.<Имя регистра расчета>.Baza<Имя базового регистра расчета>" . Parametri virtualne tablice su dimenzije glavnog registra, dimenzije osnovnog registra, te polja u čijem kontekstu trebate dobiti osnovne podatke. Dimenzije i rezovi navedeni su kao niz (ili popis vrijednosti) nizova s nazivima dimenzija.

Primjer pisanja upita korištenjem virtualnih tablica osnovnih podataka:
Kod 1C v 8.x
Dimenzije1 = Niz(2);
Dimenzije1 = "Individualno";
Dimenzije1 = "Organizacija";

Dimenzije2 = Niz(2);
Dimenzije2 = "Zaposlenik";
Dimenzije2 = "Organizacija";

Kriške = Novi niz(1);
Kriške = "Način";

Zahtjev = Novi zahtjev(Tekst zahtjeva);
Query.SetParameter("Dimenzije1", Dimenzije1);
Query.SetParameter("Dimenzije2", Dimenzije2);
Query.SetParameter("Sekcije", Sekcije);

// ...postavljanje dodatnih parametara upita koji se koriste u uvjetima u WHERE// ,..
// dobivanje odabira upita resultSelection = Query.Execute().Select();

Gornji primjer pretpostavlja istu strukturu podataka i isti zadatak koji treba riješiti kao i primjer za metodu GetBase(). U isto vrijeme, vidimo primjetan porast izvornog koda i njegove prividne složenosti.

Usporedba
Značajna razlika između funkcionalne metode dobivanja osnovnih podataka i dobivanja upitom je u tome što se kod funkcionalne metode jednim pozivom metode mogu dobiti osnovni podaci za sve osnovne registre, a kod upotrebe upita dobivanje osnovnih podataka se vrši upitom. nekoliko tablica – brojem baznih registara. Međutim, preporučeni način dobivanja podataka je dobivanje podataka pomoću upita. To će omogućiti, na primjer, dobivanje ne samo podataka o osnovnim vrstama izračuna, već i dodatnih informacija potrebnih za izračun.

Imajte na umu da je izvedba dobivanja podataka korištenjem funkcionalne metode i korištenjem upita ista unatoč očitoj kompliciranosti izvršnog koda u slučaju upita.

Kratka funkcionalna notacija metodom GetBase() dopuštena je samo ako nema potrebe za drugim podacima osim osnovnih podataka, a pritom želite "uštedjeti" na linijama koda. Iz razloga performansi koda, apsolutno je neprihvatljivo koristiti metodu GetBase() ako nakon njezine upotrebe i dalje morate primati dodatne podatke za izračun pomoću upita.

Drugo razmatranje odnosi se na uvjete odabira temeljnih podataka. Za GetBase() metodu, naime, ne postoji način da se osnovni podaci dobiju drugačije nego po jednom zapisu ili po određenom registratoru (uz izbor po određenim dimenzijama). U slučaju upita, programer ima sve mogućnosti upitnog jezika za odabir zapisa.

Kao što znate, prilikom čitanja podataka platforma 1C pristupa tablicama baze podataka. Ali za registre se može formirati platforma 1C, temeljena na stvarnim tablicama virtualni stolovi, koji nisu fizički pohranjeni u bazi podataka. Ovo razvojnom programeru omogućuje da, umjesto složenog upita stvarnoj tablici, odmah dobije podatke iz virtualne tablice jednostavnim upitom. Također uklanja moguće pogreške. Stoga treba koristiti virtualne tablice kad god je to moguće. Pogotovo pri polaganju ispita 1C: Specijalist. Smatrati različiti tipovi registre i pogledajte koje virtualne tablice platforma nudi za svaku vrstu registra.

Informacijski registri

Platforma generira virtualne tablice samo za registre periodičnih informacija. Dostupne su sljedeće vrste

SliceFirst
SliceRecent

Registri akumulacije

Za akumulacijske registre skup ponuđenih virtualnih tablica također ovisi o vrsti registra. Kao što znate, postoje dvije vrste akumulacijskih registara: Ostaci I Preokreti

Registar akumulacije stanja

Dostupni su sljedeći virtualni stolovi

Ostaci
Preokreti
Ostaci i obrti

Registar prometa

Dostupan je samo jedan virtualni stol

Preokreti

Obračunski registri

Ovdje su, ovisno o postavkama, dostupni i sljedeći virtualni stolovi

Računovodstveni registri

Računovodstveni registri imaju najveći skup virtualnih tablica

Ostaci
Preokreti
RPMDtKt
Ostaci i obrti
Subconto
PokretiSubconto

No, brzina pristupa računovodstvenim registrima je najmanja. Stoga, ako je moguće dobiti ista stanja ili promete pomoću akumulacijskih registara, onda ih treba koristiti.

Obračunski registri su konfiguracijski objekti aplikacije. Koriste se u mehanizmu složenih periodičnih izračuna i služe za pohranjivanje zapisa pojedinih vrsta izračuna koje je potrebno izvršiti, kao i za pohranjivanje međupodataka i samih rezultata izračuna.

Struktura

Podaci registra izračuna pohranjuju se kao zapisi, od kojih svaki sadrži vrijednosti dimenzija i njihove odgovarajuće vrijednosti resursa.

mjerenja registri opisuju dijelove u kojima se pohranjuju informacije, i resursi registri izravno sadrže pohranjene informacije. Na primjer, za računski registar Osnovna obračunska razdoblja za zaposlenike organizacija, koji ima sljedeću strukturu:

zapisi pohranjeni u bazi podataka izgledat će ovako:

Odnos prema planu obračunskih vrsta

Registar plaća povezan je s jednim od planova tipa obračuna koji postoje u aplikaciji. Ovaj odnos uzrokuje da svaki zapis registra ima polje Vrsta izračuna, zahvaljujući kojima mehanizmi registra mogu pratiti međusobni utjecaj obračunskih zapisa jednih na druge.

Periodičnost

Registar izračuna pohranjuje podatke ne samo u kontekstu stvorenih mjerenja, već iu kontekstu vremena. To je razlog postojanja još jednog obveznog polja za svaki zapis registra obračuna - Valjanost. Prilikom izrade registra obračuna, programer može odrediti minimalnu učestalost kojom će se unosi unositi u registar:

Predaja matičaru

Promjena stanja obračunskog očevidnika nastaje u pravilu prilikom knjiženja dokumenta. Dakle, svaki upis u upisnik povezan je s određenim dokumentom - upisnikom i rednim brojem tog dokumenta. Dodavanje upisa u upisnik, mijenjanje i brisanje moguće je samo istovremeno za sve upise koji se odnose na jednu ispravu.

Odnos s vremenskom crtom

Registar izračuna može se povezati s vremenskom crtom. Vremenska linija je registar informacija koji sadrži vremensku shemu početnih podataka uključenih u izračune. Dimenzije ovog rasporeda mogu biti npr. raspored rada i datum, a resurs je broj radnih sati na taj datum. Tada će biti moguće povezati zapis registra obračuna s bilo kojim specifičnim rasporedom rada iu budućnosti, koristeći ugrađeni jezik, dobiti podatke o broju radnih sati potrebnih za obavljanje obračuna.

Na primjer, vremenska traka sa sljedećom strukturom:

Preračunavanja

Registar obračuna može uključivati posebne objekte - Preračunavanja:

U tim objektima sustav će pohraniti informacije o tome koji su zapisi registra obračuna izgubili na važnosti i podložni ponovnom izračunu kao rezultat mehanizama ovisnosti po baznom razdoblju i isključenja po roku valjanosti.

Jedinstvenost zapisa

Sustav omogućuje kontrolu jedinstvenosti zapisa pohranjenih u registru naselja. Stoga registar obračuna ne može sadržavati dva unosa koji se odnose na isti redak istog dokumenta.

Mehanizmi koje provodi registar naselja

Mehanizam isključenja prema roku valjanosti omogućuje izračun stvarnog roka valjanosti unosa obračunskog registra na temelju analize drugih unosa sadržanih u registru.

Općenito, unos u registar plaća sadrži dva datuma koji definiraju razdoblje obuhvaćeno unosom. To se razdoblje naziva razdoblje valjanosti zapisa. Međutim, ako vrsta naplate kojoj unos pripada može biti preuzeta drugom vrstom naplate, tada je razdoblje valjanosti unosa samo "traženo" razdoblje, tj. "želimo da unos vrijedi u ovom razdoblju". U stvarnosti, stvarni rok važenja ovog unosa može se utvrditi tek nakon analize svih evidencija tipova obračuna koji istiskuju ovaj način obračuna po roku važenja. Stvarno razdoblje valjanosti bit će skup razdoblja koja su podskup izvornog razdoblja valjanosti unosa. Ako se ne pronađe nijedan unos koji ima prednost nad danim prema razdoblju valjanosti, tada će stvarno razdoblje valjanosti ovog unosa biti jednako njegovom razdoblju valjanosti. Drugi ekstremni slučaj isteka roka valjanosti je kada je određeni upis potpuno izbačen drugim upisima. U tom slučaju neće postojati stvarno razdoblje valjanosti za unos.

Svaki unos u evidenciji plaća sadrži vrstu plaće kojoj pripada. Da bi se utvrdilo koji bi unosi trebali zamijeniti dani unos prema razdoblju valjanosti, registar plaća koristi vezu na plan vrste plaće, koji opisuje međusobni utjecaj vrsta plaće jedne na drugu. Korištenje ovog odnosa omogućuje knjizi izračuna da odredi stvarno razdoblje valjanosti svakog unosa.

Mehanizam ovisnosti o baznom razdoblju omogućuje vam da dobijete osnovnu vrijednost za unos u registar namire na temelju analize drugih unosa sadržanih u registru.

Baza je brojčana vrijednost, koji bi se trebao koristiti za izračun rezultata ovog unosa. Osnovica se izračunava analizom rezultata obračuna drugih evidencija o kojima ta evidencija ovisi u baznom razdoblju. Dakle, u općem slučaju, evidencija registra obračuna sadrži dva datuma koji određuju razdoblje u kojem je potrebno analizirati evidenciju vrsta obračuna, o kojima ova vrsta obračuna ovisi o osnovici - bazno razdoblje. Korištenje veze na plan vrste naplate omogućuje glavnoj knjizi naplate da odredi vrste naplate o kojima ovisi vrsta naplate za osnovno razdoblje.

Registar obračuna podržava dvije vrste ovisnosti o baznom razdoblju:

ovisnost o roku valjanosti;
ovisno o razdoblju registracije.

U slučaju ovisnosti o razdoblju valjanosti, za dobivanje baze će se odabrati oni zapisi za koje se pronađe presjek njihovog stvarnog roka valjanosti s baznim razdobljem ovog zapisa. Vrijednost baze koja će se dobiti iz određenog utjecajnog unosa općenito nije jednaka rezultatu koji taj unos sadrži. Osnovica će se izračunati proporcionalno tome koji je dio stvarnog razdoblja utjecajnog zapisa dio koji se preklapa s navedenim osnovnim razdobljem. Ovo će koristiti podatke grafikona povezane s ovim zapisom.

U slučaju ovisnosti o razdoblju registracije, za dobivanje osnovice odabiru se rezultati izračuna onih slogova koji ulaze u bazno razdoblje ovog sloga po vrijednosti svog polja „Razdoblje registracije“.

Najsloženija verzija ovisnosti o baznom razdoblju je slučaj kada je svojstvo "Razdoblje valjanosti je bazno razdoblje" postavljeno za vrstu izračuna ovog zapisa. Ovo svojstvo znači da se kao osnovno razdoblje ovog zapisa neće koristiti osnovno razdoblje navedeno u odgovarajućim poljima zapisa, već stvarno razdoblje valjanosti zapisa, koje se dobiva kao rezultat mehanizma isključivanja prema razdoblju valjanosti te je u općem slučaju skup nekih razdoblja.

Mehanizam za generiranje rekalkulacijskih zapisa prati pojavu zapisa u registru koji utječu na rezultat izračuna postojećih zapisa. Analizom se utvrđuje mogućnost utjecaja novih zapisa na postojeće međusobni utjecaj vrste obračuna i na temelju rada mehanizama pomaka po razdoblju važenja i ovisnosti po baznom razdoblju.

Rezultat mehanizma za generiranje rekalkulacijskih slogova je skup rekalkulacijskih zapisa koji sadrže informacije o tome koje upisnike treba preračunati (rekalkulirati).

Obrasci registra obračuna

Kako bi korisnik mogao pregledavati podatke sadržane u registru naselja, sustav podržava prezentacijski oblik registra naselja - list obrazac. Omogućuje sortiranje i odabir prikazanih informacija prema nekoliko kriterija:

Sustav može automatski generirati ovaj obrazac. Uz to, programer ima mogućnost kreirati vlastite obrasce koje će sustav koristiti umjesto zadanog obrasca, uključujući obrazac skupa zapisa, koji vam omogućuje dodavanje, modificiranje i brisanje unosa u registar obračuna.

Funkcionalnost registra izračuna

Glavna funkcionalnost koju registar izračuna pruža programeru je:

izbor zapisa u zadanom intervalu prema zadanim kriterijima;
odabir evidencije po matičaru;
dobivanje osnovne vrijednosti za unose u registar koji zadovoljavaju navedeni odabir;
dobivanje podataka rasporeda za unose u registar koji zadovoljavaju navedeni odabir;
dobivanje podataka o evidencijama koje su predmet preračunavanja;
čitanje, mijenjanje i pisanje skupa zapisa u registar.

Sve promjene napravljene u bazi pohranjuju se u odgovarajuće tablice. Za 1C to su tablice dokumenata, dnevnici dokumenata, imenici i registri. O vrstama 1C registara, značajkama i suptilnostima njihove upotrebe raspravljat ćemo u našem članku.

Formiranje evidencije u upisnicima

Jedno od prvih pitanja vezanih uz registre je: zašto?

Zašto morate stvarati zasebne tablice, često duplicirajući postojeće zapise?

Odgovor je ovdje vrlo jednostavan. Naravno, moguće je napraviti složene i dugotrajne upite prema tablicama izvornih dokumenata ispisivanjem uvjeta odabira, provjeravanjem oznaka za brisanje i provođenjem, ali puno je lakše i manje naporno stvoriti određeni isječak skupa zapisa izravno prilikom spremanja dokumenta i pohraniti ga u zasebnu tablicu pristupajući mu po potrebi.

Tako smo saznali da je jedan od načina izrade upisnika pisanje upisnikom (ispravom). Ova opcija postoji u svim vrstama registara.

Proces generiranja upisnika na temelju dokumenta obično se naziva knjiženje dokumenta. Nepostavljeni matičarski dokument nema matičnih kretanja, on je zapravo nacrt ili prazan list.

Druga opcija za generiranje zapisa je izravno, bez izrade registracijskog dokumenta. Zapise na ovaj način možete kreirati samo u informacijskim registrima, dok u svojstvima registra atribut "Način zapisa" mora imati odgovarajuću vrijednost (slika 1).

Zajedničko za sve registre

Unutarnja struktura bilo kojeg registra može se prikazati na sl.2

sl.2

Razmotrimo to detaljnije:

Dimenzije – svojstva zapisa koja određuju u kojim se odjeljcima podaci pohranjuju važna informacija;
Izvori – sadrže informacije koje je potrebno sistematizirati;
Rekviziti - polja zapisa koja sadrže dodatne informacije;
Obrasci su svojstvo koje sadrži grafičke informacije o izgledu popisa, elementa itd. i njihovi interni moduli;
Prijelomi - tiskani obrasci upisnika.

Informacijski registri

Budući da gore govorimo o registrima informacija, razgovarajmo o njima.

Ovo je vjerojatno najjednostavniji i najrazumljiviji tip registara. Obična tablica koja sadrži stupce i stupce koji pohranjuju informacije.

Popis važnih svojstava registra informacija je mali (slika 3), razgovarajmo o glavnima:

sl.3

Periodičnost, označava u kojoj se mjeri kontrolira jedinstvenost zapisa (unutar minute, sata, dana, godine, u skladu s odabranom vrijednošću, ne mogu postojati dva zapisa s istim mjerenjima), također može uzeti vrijednost "Kod matičara", ali za to morate odabrati odgovarajući način snimanja;
Način snimanja je zapravo izbor između dvije vrijednosti: "Neovisni" i "Podređeni matičaru".
1. Važno je razumjeti da odabir nezavisnog načina ne znači da se zapis ne može formirati dokumentom, samo će izbor od strane registratora i kontrola jedinstvenosti zapisa od strane njega biti nemoguća;
Dopusti ukupni odsječak prvog i Dopusti ukupni odsječak zadnjeg: (kombinirajte dvije stavke u jednu) - kada su odabrani odgovarajući potvrdni okviri, može se napraviti zahtjev za registar podataka na dodatnim tablicama (Odsječak prvog i Odsječak od zadnji), koji sadrže odgovarajuće skupove podataka, kao jedan od Parametri ovih tablica su datum na koji je potrebno izvršiti selekciju podataka.

Registri akumulacije

Strukturu jednog od njih vidjeli smo na sl.2. Glavno svojstvo koje snažno utječe na izgled registra, kao i na njegovu unutarnju strukturu je "Vrsta registra" (slika 4)

Ovisno o zahtjevima za pohranjene informacije, oni mogu poprimiti sljedeće vrijednosti:

Ostaci;
Preokreti.

U prvom slučaju, baza podataka će sadržavati informacije ne samo o kretanju resursa u kontekstu mjerenja, već io vrsti operacije (primitak ili trošak). Osim toga, prilikom kreiranja upita bit će dostupna dodatna tablica s ukupnim iznosima.

Jedan od glavnih problema s kojima se programeri početnici susreću pri korištenju tablica Balances i BalancesAnd Turnovers u upitima je da kada upit dobije stanja za određeni datum, podaci u tim tablicama mogu se razlikovati. I ovdje postoji jedna nijansa: prilikom određivanja određene vrijednosti kao datuma završetka razdoblja, platforma uzima podatke iz tablice Stanja bez uključivanja ove vrijednosti u razdoblje odabira.

Ako trebate podatke koji uključuju kraj razdoblja, možete:

Koristite tablicu Stanja i obrti;
Napravite odabir za datum 1 sekundu veći od zadanog (tj. ne 31.12.16 23:59:59, već 01.01.17 00:00:00);
Upotrijebite metodu Boundary koja pomaže konfigurirati opciju za uključivanje točke u vremenu u razdoblju koje se razmatra (slučaj upotrebe: Boundary(EndDate,Inclusive).

Računovodstveni registri

Dovoljno specijalizirani registri, po svom dizajnu nalikuju akumulacijskim registrima. Glavna razlika od ostalih vrsta registara platforme 1C je prisutnost parametra „Kontni plan” u strukturi imovine (slika 5).

sl.5

Kontni plan je zaseban objekt metapodataka koji zahtijeva posebnu raspravu. Ovisno o kontnom planu, moderne tipične 1C konfiguracije sadrže 4 glavna računovodstvena registra:

Budžetiranje;
Međunarodni;
porez;
Samonosivi.

Drugi parametar, tipičan za računovodstvene registre, je "Korespondencija".

Označavanjem ovog okvira možete kreirati dvostruke unose koji sadrže račun kredita AccountKt i račun zaduženja AccountDt te analitiku (podkonto) koja odgovara tim računima. Ako potvrdni okvir nije označen, samo će jedan račun biti upisan u evidenciju.

Obračunski registri

Ovo su vjerojatno najteži registri za razumijevanje. U međuvremenu, u svojoj biti, oni su vrlo slični akumulacijskim registrima tipa "Promet".

Definirajuća razlika registra izračuna od ostalih registara je prisutnost u njegovim svojstvima parametra "Plan vrste izračuna". Osim toga, registar obračuna, kao i registar informacija, je periodičan.

U svakom obračunskom registru može se omogućiti mogućnost povezivanja unosa s terminskim planom navedenim u pripadajućem informacijskom registru. To omogućuje kodu dohvaćanje podataka o radnom vremenu.

Uz dimenzije, resurse i obrasce koji se nalaze u drugim vrstama knjiga, registrima izračuna može se dodijeliti objekt Recalculation za pohranjivanje informacija o zapisima koji su zastarjeli i treba ih revidirati.

Njihova glavna upotreba je u tipične konfiguracije 1C - registracija i olakšavanje rada s obračunima zaposlenicima organizacije.

Jedan od zadataka koji se rješava uz pomoć računskih registara je dobivanje registarskih prometa upitima prema tablici podataka virtualne baze ili metodom GetBase(). Registarski prometi se dobivaju na temelju velikog broja različitih izvornih podataka, uključujući postavke i sadržaje plana obračunskih vrsta, postavke obračunskog registra, parametre virtualne tablice osnovnih podataka itd. No, jednu od bitnih uloga u dobivanju osnovnih podataka imaju mjerenja računskog registra.

Uloga dimenzija u parametrizaciji virtualne tablice osnovnih podataka

Jedan od važnih parametara virtualne tablice baznih podataka je popis dimenzija po kojima se zapisi registra uspoređuju pri sumiranju podataka. Za rješavanje različitih problema, možda ćete morati izvršiti zbrajanje resursa registra preko različitih skupova mjerenja. Razmotrimo primjer registra dizajniranog za obračun plaća i ima tri dimenzije:

Organizacija,
Pojedinac,
Podjela.

Zamislite da trebate riješiti sljedeće zadatke:

Pribavljanje za pojedine evidencije očevidnika o prometu očevidnika za sve evidencije s istom pododjeljkom kao izvorni zapisnik. To može biti, primjerice, izračun dodatka koji ovisi o razgraničenjima cijele jedinice.
Dobijanje prometa u evidenciji s istom osobom i odjelom. Oni. primitak iznosa zaposlenikovih vremenskih razgraničenja koja su mu dospjela u istom odjelu (isključuju se obračunska razgraničenja za istog zaposlenika koja je primio u drugim odjelima).
Potvrda o prometu na evidenciji s istim pojedincem i istom organizacijom (sva razgraničenja na pojedinca unutar iste organizacije).

Svi navedeni zadaci rješavaju se upitima prema virtualnoj tablici osnovnih podataka. U tom će slučaju parametri "Mjerenja glavnog registra" i "Mjerenja osnovnog registra" biti različiti za sva tri zadatka. U prvom slučaju postoji samo jedna dimenzija - "Pododjela"; u drugom - "Pojedinac" i "Pododjel"; u trećem - "Organizacija" i "Pojedinac".

Osnovna optimizacija prikupljanja podataka

Za gore navedene slučajeve, prilikom formiranja upita prema tablici virtualne baze podataka, sustav će, u smislu upitnog jezika, izvršiti "lijevo spajanje" tablice registra izračuna s istom tablicom. U ovom slučaju, jedan od uvjeta povezivanja je jednakost vrijednosti u poljima navedenim kao mjerenja glavnog i baznog registra. Naravno, uz ovaj uvjet postoji i usporedba roka važenja odnosno razdoblja registracije s početkom i završetkom baznog razdoblja, usporedba vrsta obračuna i sl., no najteže "tvrđe" ograničenje, u pravilu, je da se u pravilu radi o usporedbi razdoblja valjanosti ili registracije s početkom i krajem baznog razdoblja. je ograničenje mjernih vrijednosti.

Dakle, za učinkovit rad rezultirajućeg upita važno je imati indeks tablice registra izračuna, koji bi kao prva polja sadržavao polja uspoređivanih mjerenja.

Mogućnost indeksiranja dimenzija registra izračuna omogućuje rješavanje takvog problema, ali samo za slučaj kada se uspoređuje jedna dimenzija (u našem primjeru zadatak dobivanja podataka po odjelima). U slučaju kada postoje dvije ili više uspoređivanih dimenzija, potrebno je izgraditi indeks na više dimenzija odjednom.

Upravo ovaj zadatak omogućuje rješavanje svojstva Osnovna dimenzija registra izračuna. Postavljanjem ovog svojstva na više dimenzija, programer konfiguracije stvara indeks na svim dimenzijama označenim kao "baza" (za više detalja pogledajte odjeljak "Indeksi tablica baze podataka").

Iz navedenog je razvidno da se za registar obračuna može izraditi samo jedan takav indeks kako bi se izborom određenih dimenzija optimizirao prijem osnovnih podataka. Stoga je prilikom razvoja važno pravilno procijeniti koje će se virtualne tablice češće koristiti, a čija je optimizacija najvažnija.

Vratimo se našem primjeru. Zamislite da će obračunska razdoblja koja zahtijevaju dobivanje podataka o pojedincu i odjelu biti rjeđa tijekom rada konfiguracije od vremenskih razgraničenja koja zahtijevaju dobivanje podataka o pojedincu i organizaciji. Zatim, kao osnovne mjere treba istaknuti mjere "Organizacija" i "Pojedinac". Pritom ćemo se morati pomiriti s činjenicom da će dobivanje osnovnih podataka o pojedincu i odjelu biti relativno sporo.

Pri izboru baznih mjerenja treba procijeniti i njihovu "selektivnost", tj. predstavljaju koliko će vrijednosti biti u određenoj dimenziji tijekom rada konfiguracije. Zamislite da u našem primjeru jedan pojedinac može imati vrlo malo (jednu ili dvije) organizacije i relativno mnogo odjela. Oni. pojedincu se gotovo uvijek isplaćuje plaća za jednu organizaciju, au isto vrijeme se plaća često obračunava za različite odjele. U takvim okolnostima, razumnije je odabrati dimenzije "Pojedinac" i "Odjel" kao osnovne.

Ali u isto vrijeme, važno je zapamtiti redoslijed mjerenja registra izračuna ...

O redoslijedu mjerenja u obračunskom registru

Činjenica je da prilikom izrade indeksa, koji će olakšati primanje osnovnih podataka, sustav u njega uključuje dimenzije redoslijedom kojim se nalaze u konfiguracijskom stablu. To znači da ćemo jednostavnim "preuređivanjem" dimenzija "Pojedinac" i "Odjel" promijeniti redoslijed polja u indeksu.

U našem primjeru, ako su mjere "Pojedinac" i "Odjel" odabrane kao bazne, tada njihovim preuređivanjem nećemo promijeniti brzinu dobivanja osnovnih podataka o pojedincu i odjelu, ali ćemo radikalno pogoršati situaciju s dobivanjem podatke o pojedincu i organizaciji. Prilikom usporedbe vrijednosti u poljima "Organizacija" i "Pojedinac", sustav neće moći koristiti indeks Pododjeljak+Pojedinac, budući da polje "Pojedinac" nije prvo u njemu, a uvjet nije nametnut na podgrađu. A u slučaju indeksa, Pojedinac + Odjel će imati koristi od dobivanja osnovnih podataka za odjel i pojedinca, kao i od dobivanja osnovnih podataka za organizaciju i pojedinca, budući da će polje "Pojedinac" biti prvo u indeksu , sustav će ga moći koristiti "djelomično" (po jedno polje) . Istovremeno, polje "Pojedinac" ima puno veću "selektivnost" od polja "Organizacija", te neće trebati puno vremena za izradu uvjeta za organizaciju.

Ako je osnovna dimenzija jedan

Ne zaboravimo na zadatak našeg primjera, koji uključuje dobivanje osnovnih podataka samo za odjel. Čini se da stvaranje indeksa Pojedinac + Odjel za rješavanje druga dva zadatka isključuje učinkovit rad virtualna tablica osnovnih podataka na jednoj dimenziji "Odjel". Ali ovdje se morate sjetiti mogućnosti indeksiranja dimenzija registra (svojstvo indeksiranja). Mogućnost indeksiranja dimenzije omogućuje učinkovito rješavanje problema dobivanja baze iz jedne osnovne dimenzije.

Dakle, u našem primjeru morate postaviti svojstvo Base za dimenzije "Pojedinac" i "Odjel", svojstvo Indeksiranje za dimenziju "Odjel", a također provjerite je li dimenzija "Pojedinac" "viša" od Dimenzija "Odjel" (redoslijed dimenzije "Organizacija" nije bitan).