Mehanizam složenih periodičnih obračuna omogućava vam da implementirate različite modele platnog spiska. Rad mehanizma se zasniva na dvije komponente.

S jedne strane, mehanizam za složene periodične proračune sadrži alate za opisivanje različitih tipova proračuna koji će se koristiti u aplikativnom rješenju. Na primjer, to mogu biti takve vrste obračuna kao što su plata, alimentacija, novčana kazna itd. Pored samog opisa ovih vrsta proračuna, moguće je postaviti pravila prema kojima će neke vrste proračuna uticati na druge vrste proračuna.

S druge strane, ovaj mehanizam pruža mogućnost pohranjivanja međupodataka koji se koriste za izvođenje proračuna i konačnih rezultata proračuna.

Rad mehanizma za složene periodične proračune osiguravaju dva objekta aplikativnog rješenja:

Plan vrsta obračuna i Registar obračuna.

Plan tipova obračuna se koristi za opisivanje tipova obračuna i njihovog međusobnog uticaja. U aplikativnom rješenju može postojati proizvoljan broj planova za tipove obračuna, ovisno o implementiranom računovodstvenom modelu:

Registar proračuna služi za pohranjivanje zapisa o određenim vrstama proračuna koje je potrebno izvršiti, kao i za pohranu međupodataka i rezultata samih proračuna. Aplikacijsko rješenje može sadržavati nekoliko računskih registara dizajniranih da odražavaju podatke iz određenog računovodstvenog odjeljka:

Plan tipova obračuna

Struktura plana obračunskih tipova
Plan tipova obračuna je lista tipova obračuna. Svaka vrsta obračuna ima šifru, naziv i skup detalja koji sadrže dodatne informacije o ovoj vrsti obračuna:

Na primjer, plan za tipove obračuna Osnovna obračunska razgraničenja organizacija može izgledati ovako:

Kreiranje i uređivanje tipova proračuna može vršiti i programer (predefinirani tipovi proračuna) i korisnik dok radi sa aplikativnim rješenjem. Međutim, korisnik ne može izbrisati tipove proračuna koje je kreirao programer.

Tipovi proračuna kreirani u planu tipa proračuna mogu utjecati jedni na druge. Sistem podržava dva tipa takvog uticaja: zavisnost od baznog perioda i pomeranje prema periodu važenja.

Za svaki tip obračuna možete odrediti listu tipova obračuna od kojih će zavisiti za bazni period, a koji će ga zamijeniti za period važenja.

Na primjer, vrsta obračuna alimentacije može ovisiti o baznom periodu na sljedeće vrste obračuna:

A tip obračuna Plaća može se zamijeniti obračunskim tipom Izostanak:

Pored ovih zavisnosti, za neku vrstu proračuna mogu se specificirati i tzv. vodeći tipovi proračuna - oni od kojih direktno ne zavisi, ali koji na njega mogu uticati kroz druge vrste proračuna.

Obrasci plana tipova obračuna
Da bi korisnik mogao da pregleda i promeni podatke sadržane u planu tipova obračuna, sistem podržava nekoliko oblika njegovog prikaza. Sistem može automatski generisati sve potrebne formulare; Uz to, programer ima mogućnost kreiranja vlastitih formulara koje će sistem koristiti umjesto zadanih obrazaca:

Za prikaz tipova proračuna koristite obrazac liste. Omogućava vam navigaciju kroz listu, dodavanje, označavanje za brisanje i brisanje tipova proračuna. Obrazac liste vam omogućava sortiranje i odabir prikazanih informacija prema nekoliko kriterija:

Za pregled i promjenu podataka za pojedinačne tipove proračuna koristite obrazac za vrstu proračuna. Po pravilu, predstavlja podatke u obliku koji je lako razumjeti i uređivati:

Pored ova dva obrasca za tipove obračuna, podržan je i obrazac za izbor određenih vrsta obračuna sa liste. Obično sadrži minimalni skup informacija potrebnih za odabir jedne ili druge vrste proračuna.

Registar obračuna

Struktura registra proračuna
Informacije u registru proračuna pohranjuju se u obliku zapisa, od kojih svaki sadrži mjerne vrijednosti i odgovarajuće vrijednosti resursa.

Dimenzije registra opisuju sekcije u kojima se pohranjuju informacije, a resursi registra direktno sadrže pohranjene informacije. Na primjer, za registar obračuna Osnovna razgraničenja zaposlenih u organizacijama, koji ima sljedeću strukturu:

Zapisi pohranjeni u bazi podataka će izgledati ovako:

Odnos prema planu obračunskih tipova
Registar proračuna je pridružen jednom od planova tipa proračuna koji postoje u aplikacijskom rješenju. Ova veza uzrokuje da svaki registarski zapis ima polje za vrstu izračuna, zahvaljujući kojem mehanizmi registra mogu pratiti međusobni uticaj obračunskih zapisa jedan na drugog.

Periodičnost

Registar proračuna čuva podatke ne samo u smislu napravljenih mjerenja, već iu smislu vremena. To je razlog za postojanje još jednog obaveznog polja za svaki unos u registar obračuna - Period važenja. Prilikom kreiranja registra izračuna, programer može odrediti minimalnu učestalost unosa unosa u registar:

Podređenost matičaru
Promjena stanja registra obračuna obično se dešava kada se dokument knjiži. Dakle, svaki upis u registar je povezan sa određenim dokumentom - registratorom i brojem reda ovog dokumenta. Dodavanje upisa u registar, njihovo mijenjanje i brisanje moguće je samo istovremeno za sve upise koji se odnose na jedan dokument.

Odnos prema vremenskoj liniji
Registar obračuna može se povezati sa vremenskim rasporedom. Vremenska linija je registar informacija koji sadrži vremenski dijagram izvornih podataka uključenih u proračune. Dimenzije ovog rasporeda mogu biti, na primjer, raspored rada i datum, a resurs može biti broj radnih sati na ovaj datum. Tada će biti moguće povezati unos registra obračuna sa određenim rasporedom rada i ubuduće, koristeći ugrađeni jezik, dobiti informacije o broju radnih sati potrebnih za obavljanje proračuna.

Na primjer, vremenska linija sa sljedećom strukturom:

Rekalkulacije
Registar obračuna može uključivati ​​posebne objekte - Rekalkulacije:

U ovim objektima sistem će pohraniti informacije o tome koji su unosi u registru obračuna izgubili relevantnost i podliježu ponovnom izračunavanju kao rezultat rada mehanizama zavisnosti za bazni period i izbacivanja za period važenja.

Jedinstvenost zapisa
Sistem omogućava kontrolu nad jedinstvenošću zapisa pohranjenih u registru obračuna. Dakle, registar obračuna ne može sadržavati dva unosa koji se odnose na isti red istog dokumenta.

Mehanizmi implementirani računskim registrom

Preuzeće po periodu važenja
Mehanizam prečesti perioda važenja vam omogućava da izračunate stvarni period važenja unosa u registru poravnanja na osnovu analize drugih unosa sadržanih u registru.

Općenito, upis u registar naselja sadrži dva datuma koji određuju period u kojem upis važi. Ovaj period se naziva period važenja unosa. Međutim, ako se tip obračuna na koji se odnosi dati unos može zamijeniti drugim tipom obračuna, tada je period važenja datog unosa samo „traženi“ period, odnosno „želimo da unos bude važeći u ovom periodu .” U stvarnosti, stvarni period važenja ovog zapisa može se utvrditi tek nakon analize svih zapisa tipova obračuna koji zamenjuju ovu vrstu obračuna periodom važenja. Stvarni period važenja će biti skup perioda koji su podskup originalnog perioda važenja unosa. Ako se ne nađe nijedan zapis koji pomjera dati u smislu roka važenja, tada će stvarni period važenja ovog zapisa biti jednak njegovom roku važenja. Drugi ekstremni slučaj doživotne deložacije je kada je data evidencija u potpunosti potisnuta drugim evidencijama. U tom slučaju neće postojati stvarni rok važenja za unos.

Svaki unos u registru poravnanja sadrži tip poravnanja na koji se odnosi. Da bi se utvrdilo koji bi unosi trebali zamijeniti dati unos po periodu važenja, registar platnih spiskova koristi vezu sa planom platnih spiskova, koji opisuje međusobni uticaj vrsta platnih spiskova jedni na druge. Korišćenje ovog odnosa omogućava platnom spisku da odredi stvarni period važenja svakog unosa.

Ovisnost prema baznom periodu
Mehanizam zavisnosti baznog perioda vam omogućava da dobijete osnovnu vrednost za unos registra obračuna na osnovu analize drugih unosa sadržanih u registru.

Baza je numerička vrijednost koja se mora koristiti za izračunavanje rezultata datog zapisa. Osnovica se izračunava analizom rezultata obračuna ostalih unosa od kojih zavisi ovaj unos za bazni period. Dakle, u opštem slučaju, zapis registra obračuna sadrži dva datuma koji određuju period u kojem je potrebno analizirati evidenciju vrsta obračuna od kojih ova vrsta obračuna zavisi od osnovice - baznog perioda. Korišćenje veze sa planom tipa obračuna omogućava registru obračuna da odredi tipove obračuna od kojih zavisi dati tip obračuna za bazni period.

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

• zavisnost od roka važenja;
• zavisnost od perioda registracije.

U slučaju zavisnosti od roka važenja, za dobijanje osnove biće odabrani oni zapisi za koje se nađe presek njihovog stvarnog roka važenja sa baznim periodom ovog zapisa. Vrijednost baze koja će se dobiti iz određenog utjecajnog zapisa općenito nije jednaka rezultatu koji ovaj zapis sadrži. Osnovica će se izračunati proporcionalno dijelu stvarnog perioda utjecajnog zapisa koji se preklapa sa navedenim baznim periodom. Ovo će koristiti podatke grafikona povezane s ovim zapisom.

U slučaju zavisnosti od perioda registracije, za dobijanje osnovice, biće izabrani rezultati obračuna onih zapisa koji ulaze u bazni period ovog zapisa po vrednosti njihovog polja „Registracioni period“.

Najkompleksnija verzija zavisnosti od baznog perioda je slučaj kada je za tip obračuna ovog zapisa postavljeno svojstvo „Period važenja je bazni period“. Ovo svojstvo znači da će se osnovni period ovog zapisa koristiti ne osnovni period, koji je naveden u odgovarajućim poljima zapisa, već stvarni period važenja zapisa, dobijen kao rezultat rada mehanizma za iseljenje za rok važenja i koji je, u opštem slučaju, skup nekih perioda.

Generisanje zapisa preračunavanja
Mehanizam za generisanje rekalkulacionih zapisa prati činjenicu da se u registru pojavljuju zapisi koji utiču na rezultat proračuna postojećih zapisa. Mogućnost uticaja novih zapisa na postojeće utvrđuje se kao rezultat analize međusobnog uticaja tipova proračuna i na osnovu rada mehanizama pomeranja za period važenja i zavisnosti za bazni period.

Rezultat mehanizma za generisanje rekalkulacionih zapisa je skup rekalkulacionih zapisa koji sadrže informacije o tome koje unose registra treba ponovo izračunati (preračunati).

Obrasci registra obračuna
Da bi korisnik mogao da vidi podatke sadržane u registru obračuna, sistem podržava oblik prezentacije obračunskog registra - obrazac liste. Omogućuje vam sortiranje i odabir prikazanih informacija prema nekoliko kriterija:

Sistem može automatski generirati ovaj obrazac. Uz to, programer ima mogućnost kreiranja vlastitih obrazaca koje će sistem koristiti umjesto zadane forme, uključujući formu skupa zapisa koja vam omogućava da dodajete, mijenjate i brišete unose u registru obračuna.

Funkcionalnost registra proračuna
Glavna funkcionalnost koju registar proračuna pruža programeru je:

• odabir zapisa u datom intervalu prema određenim kriterijumima;
• izbor evidencije od strane matičara;
• dobijanje osnovne vrijednosti za unose registra koji zadovoljavaju specificirani izbor;
• dobijanje podataka rasporeda za unose u registar koji zadovoljavaju datu selekciju;
• dobijanje podataka o evidenciji koja je predmet preračuna;
• čitanje, modifikovanje i upisivanje skupa zapisa u registar.

Učenje rada sa registrima (1C: Računovodstvo 8.3, izdanje 3.0)

2016-12-08T13:50:45+00:00

Dragi čitatelji, u ovoj lekciji želim se dotaknuti izuzetno važne teme kada radite u 1C: Računovodstvo 8.3 - Registri.

Odmah ću vam na malom primjeru pokazati zašto je ovo toliko važno.

Dajte nam platni spisak za januar:

Početkom februara sa kase kreiramo platni list i kliknemo na dugme „Popuni“:

I dobijamo sledeće:

Ali za januar:

• Obračun od 50.000 rubalja
• Porez na lični dohodak 6.500 rubalja
• Ukupno plativo 43.500 rubalja

Gdje se uvukla greška? Nešto je pošlo po zlu? Da li je zaista moguće da se sada ručno unese iznos koji treba platiti?

Iskusni računovođa će odmah napraviti bilans stanja za račun 70:

A on će biti još više u nedoumici, jer prema izvještaju još uvijek dospijeva istih 43.500! A odakle dodatnih 5.000 rubalja?

Štaviše, takva situacija (sa bilo kakvim proračunima) može se dogoditi i u „trojci“ i u „dvojci“.

Danas ću pokušati da podignem veo tajne - zašto se ponekad program ponaša tako čudno. Reći ću vam kako pronaći i popraviti grešku u takvim slučajevima. Pred kraj članka shvatit ćemo odakle je došlo ovih 5.000 rubalja.

Dakle, idemo!

Naučiti vidjeti registre

Prilikom knjiženja dokumenata, 1C: Računovodstvo 8 vrši unose u računovodstvene račune (dugme DtKt za bilo koji dokument):

Na osnovu ovih transakcija se grade svi računovodstveni izvještaji: analiza računa, kartica računa, bilans stanja...

Ali postoji ogroman sloj podataka koji program piše paralelno sa knjiženjima i koristi se za sve ostalo: popunjavanje KUDIR-a, knjige nabavki i prodaje, regulisano izveštavanje... plate koje se isplaćuju, konačno

Kao što ste verovatno već pretpostavili, ovaj sloj se zove registri, evo ga:

Sada neću ulaziti u detalje opisa samih registara, kako vas ne bih dodatno zbunio.

Reći ću samo da nam je jednostavno od vitalnog značaja da postepeno naučimo da „vidimo“ kretanja u ovim registrima kako bismo bolje razumjeli i, kada je potrebno, ispravili ponašanje programa.

Pogledajmo pobliže registar "Dospjele plaće" - to je ono što ima smisla za rješavanje našeg problema sa dodatnih 5.000:

Vidimo dva upisa u ovom registru napravljena u dolasku, odnosno u plusu. Ako skrolujemo desno od ekrana, videćemo u prvom redu iznos koji treba platiti “-6.500”, au drugom “50.000”.

Stanje u ovom registru -6.500 + 50.000 je jednako 43.500, što treba da bude uključeno u dokument „Izvod za uplatu iz kase“ kada kliknemo na dugme „Popuni“.

Ponavljam još jednom - izvod o uplati utvrđuje naše zaostale plate prema zaposlenom ne po računu 70, već prema registru „Dospele plate“.

Ispada da znamo da se plaća koja se isplaćuje popunjava na osnovu ovog registra, ali ni gledajući upise u registar ne možemo shvatiti šta nije u redu.

Najvjerovatnije ne vidimo cijelu sliku (možda postoje i drugi zapisi za ovaj registar) i naslućuje se neki alat za analizu registra, sličan računovodstvenim izvještajima.

Naučiti analizirati registre

I postoji takav alat, zove se " Univerzalni izvještaj".

Idite na odjeljak "Izvještaji" i odaberite "Univerzalni izvještaj":

Odaberite vrstu registra “Registar akumulacije”, registar “Doplatu plata” i kliknite na dugme “Generiraj”:

Ispostavilo se da nije baš informativno:

To je zato što je potrebno preliminarno podešavanje izvještaja, kliknite na dugme “Prikaži postavke” i na kartici “Grupiranje” dodajte polje “Zaposleni”:

Na kartici “Izbori” vršimo odabir za našu organizaciju:

Kliknite na dugme "Generiraj":

Sada je ovo zanimljivije. Vidimo da je stanje koje treba isplatiti našem zaposleniku istih 48.500 rubalja!

Idite ponovo na postavke izvještaja i dodajte novo polje “Rekorder” na karticu “Indikatori”:

Ponovo generišemo izveštaj:

Sada se jasno vidi da se 5.000 pojavilo kao rezultat operacije (očigledno unošenje bilansa) 31. decembra 2014. godine.

I trebamo ili promijeniti ovu operaciju ili ručno prilagoditi registar „Dospjele plaće“ i zatvoriti ovih 5.000 rubalja, na primjer, 31. decembra 2015.

Idemo drugim putem. Dakle, naš zadatak je da se pobrinemo da početkom 2016. godine ne bude dugovanja prema zaposlenom u registru „Dospjelih plata“.

To se radi ručnim radom.

Učenje podešavanja registara

Idite na odjeljak "Operacije" i odaberite "Operacije unesene ručno":

Kreiramo novu operaciju krajem 2015. godine:

Iz menija "Više" odaberite "Odaberi registre...":

Navedite registar "Plata koja se isplaćuje" i kliknite OK:

Idite na karticu registra koja se pojavi i napravite trošak za 5.000 rubalja:

Na taj način mi, takoreći, oduzimamo 5.000 rubalja iz registra po zaposlenom da bismo do početka 2016. došli do nule.

Izvodimo operaciju i regeneriramo univerzalni izvještaj:

Sve je uspjelo! Vidimo da je naša ručna operacija od 31. decembra 2015. dovela stanje na nulu i da je plata koja se isplati nakon obračuna jednaka očekivanim 43.500.

Nevjerovatno. A sada ćemo to provjeriti na izvodu plaćanja.

Ali prvo želim da vam skrenem pažnju na još jednu važnu tačku:

Imajte na umu da stanja na početku i na kraju grupe „Zaposleni“ pokazuju besmislicu. Ovo nije greška, to je nijansa koju treba uzeti u obzir u vezi sa arhitektonskim karakteristikama 1c.

Zapamti. U slučaju da se prikaže univerzalni izvještaj sa detaljima sve do dokumenta (registratora), stanja po grupisanju će pokazati besmislicu.

Ako zahtijevamo stanja po grupisanju zaposlenika, prvo moramo ukloniti indikator “Registar” koji smo dodali iz postavki.

Mnogi 1C programeri nikada se u svojoj praksi nisu susreli sa komponentom „Izračunavanje“, stoga, kada treba da polažu ispite za Specijalista na Platformi 8.0, gdje svaki zadatak sadrži zadatak o složenim periodičnim proračunima, nastaju poteškoće, prije svega poteškoće u razumijevanju.

Hajde da pokušamo da shvatimo ovu komponentu u 8.0. Umjesto rješavanja raznih računskih problema, pokušajmo razumjeti ovu komponentu kako bismo mogli riješiti bilo koji računski problem. Nakon što proučite ovaj priručnik, shvatit ćete kako su registri proračuna uređeni i funkcioniraju.

Na primjer, koristit ćemo konfiguraciju okvira instaliranu tokom ispita.

Da budem iskren, dugo sam pokušavao da shvatim za šta su još potrebni proračuni, ali nisam mogao da shvatim, pa hajde da razmotrimo problem obračuna plata.

Šta su kalkulacije

U osnovi, konačni proizvod platnog spiska je skup unosa platnog spiska u obliku:

Zaposleni	Period	Vrsta obračuna	Rezultat	Podaci	Komentar
Measurement	Službeno	Službeno			Rekviziti

Vrijednost u koloni „Podaci“ odražava osnovnu platu zaposlenog (prema ugovoru o radu), ali se ovaj iznos može povećati za bonuse, umanjiti za novčane kazne i izostanke itd., stoga se stvarni iznos za isplatu upisuje nakon izračunavanje u koloni “Rezultat”. Ovo je kalkulacija. Iznos u koloni “Resurs” za datog zaposlenog je plata koja mu pripada.

Dakle, registar obračuna je u suštini skup zapisa, sličnih strukturi registru pregovaračke akumulacije. Samo da bi se izvršili složeni proračuni, za njega su specificirana dodatna podešavanja koja vam onda omogućavaju da napravite mnogo virtualnih tabela za registar proračuna, iako je, u suštini, ovaj registar samo skup zapisa prikazanih na slici.

Svaki upis u registar poravnanja odnosi se na određenu vrstu poravnanja i vremenski period.

Vrste proračuna

Svaki zapis tipova obračuna ima atribut usluge - tip obračuna.

Vrsta proračuna se može smatrati elementom posebnog priručnika kao što je “Plan tipova proračuna” – on takođe ima detalje, tabele, unapred definisane i kreirane elemente od strane korisnika. Može postojati nekoliko takvih „direktorija“ u sistemu.

Na primjer, napravimo plan za tipove proračuna Main i u njemu unaprijed definirane tipove proračuna plata, bonus, odsustvo, poslovno putovanje.

Tipovi proračuna se koriste funkcionalno da odražavaju uticaj unosa registra proračuna jedan na drugog. Ali ukratko govore o uticaju tipova obračuna jedni na druge:

Vrsta obračuna	Opis	Primjer
Po baznom periodu	Rezultat obračuna zavisnog perioda zavisi od rezultata baznog perioda. Ako se rezultat baznog perioda promijeni, rezultat zavisnog perioda se mora ponovo izračunati.	Bonus zavisi od plate u baznom periodu.
Brisanje po periodu	Period važenja zavisnog perioda zamjenjuje period važenja baznog perioda, tako da bazni period ima stvarni	Izostanak s posla utiče na stvarni period plate.
Vodeće kalkulacije	Obračun zavisi od vodećeg proračuna, ali ne direktno nego indirektno, tj. proračun A zavisi od osnovnog proračuna B, a proračun B zavisi od osnovnog proračuna B, dakle A indirektno zavisi od B, tj. A ovisi o vodećim proračunima B. U stvari, kada se proračun C promijeni, B se može promijeniti i stoga se A može promijeniti automatski, tako da morate naznačiti koji su kalkulacije vodeći.	Bonus zavisi od osnovice plate, ali indirektno zavisi od izostanaka.

Zbog ovog uticaja, rok važenja upisa u registar naselja podeljen je na četiri perioda:

Period	Opis
Period registracije	U kom periodu je zabeležen događaj, tj. obično kada se unese dokument.
Validnost	U kom periodu događaj funkcioniše, tj. kojem periodu događaj pripada.
Bazni period	Ima smisla samo za periode koji imaju bazni period - opisuje interval baznog perioda.
Stvarni rok važenja	Ako je period važenja zamijenjen drugim vrstama obračuna, onda se stvarni period važenja sastoji od nekoliko perioda kada je ova vrsta obračuna stvarno na snazi.

Period registracije je određen jednim brojem - početkom perioda, koji odgovara učestalosti obračunskog registra. Čak i ako postavimo drugačiji datum u ovom servisnom polju, on će i dalje biti zamijenjen početkom perioda. Preostali periodi su specificirani sa dva polja - početak i kraj perioda Stvarni period važenja je skup perioda, jer može se sastojati od nekoliko datumskih intervala.

Vremenske karte

Sistem ima mogućnost povezivanja podataka iz računskih registara sa vremenskim grafikonima tako da se može dobiti broj radnih sati za bilo koji period.

Vremenska linija je jednostavan registar informacija u kojem jedna dimenzija pohranjuje datum, druga je povezana s dimenzijom pomoću računskog registra, a jedan od resursa se koristi za praćenje vremena.

Dimenzija koja povezan sa registrom obračuna obično nosišto znači "vrsta grafikona".

datum	Vrsta grafikona	Značenje
11.01.05 pet	Pet dana
11.01.05 pet	Šest dana
12.01.05 Sat	Pet dana
12.01.05 Sat	Šest dana

Zašto koristiti dimenziju datuma, a ne periodični registar detalja? Sve je vrlo jednostavno - ako u petak 11. januara imamo 8 radnih sati u periodu od pet dana, to ne znači da ćemo sutradan opet imati 8 radnih sati. Ali ako bismo koristili periodični registar, vrijednost za sljedeći dan bi se uzimala iz prethodnog dana u nedostatku evidencije.

Dakle, imajući određeni period (stvarna akcija, registracija, bazni period itd.) možemo automatski dobiti broj sati za ovaj period prema rasporedu.

Preračunavanje

Ponovno izračunavanje donekle podsjeća na granicu sekvence. S obzirom da imamo zavisne proračune, pri mijenjanju njihovih osnovnih i vodećih proračuna, sistem mora nekako primijetiti da moramo ponovo izračunati zavisne proračune.

Tome služe preračuni.

Ako izračunamo osnovne zapise, sistem će zabilježiti u alokacijama da nam je potrebno da izračunamo zavisne zapise. Kada izračunamo zavisne zapise, alokacije će se obrisati.

U suštini, ponovni izračuni su lista unosa registra proračuna koje treba ponovo izračunati.

Ako ne unesete nijedno mjerenje u rekalkulacije, onda kada se osnovni proračuni promijene, svi zavisni zapisi će biti dodati na listu rekalkulacija.

Ako u rekalkulaciji kreiramo dimenziju „Zaposleni“, onda kada se promijeni osnovna kalkulacija za zaposlenog, zavisne evidencije samo za ovog zaposlenog će se dodati u preračune.

Praktični zadatak

Dosta teorije. Pokušajmo proučiti detalje u praksi. Uzmimo konfiguraciju okvira kao osnovu.

Formulacija problema:

Neka se bonus odredi kao fiksni procenat plate (minus odsustva i putni dodaci).

Putne naknade neka se isplaćuju u duploj plaći + fiksni iznos plaćanja za svaki dan putovanja.

Neka se radniku za izostanak naplati novčana kazna u iznosu od polovine plate za vrijeme odsustva.

napredak:

Inicijalna obuka

Kreirajmo novi plan za tipove proračuna "Glavni".

Hajde da definišemo vrste proračuna i zavisnosti između njih:

	Basic	Displasing	Prezenteri
Plata		Izostanak, službeno putovanje
Nagrada		Izostanak, službeno putovanje	Plata, izostanak, službeno putovanje
Poslovno putovanje
Apsentizam

Dodajmo ove vrste proračuna u plan "Glavne" tipove proračuna i postavimo zavisnosti u svojstvima tipova proračuna prema tabeli.

U registru obračuna plata napravićemo dimenziju “Zaposleni” tipa “Pojedinci” - tako da će registar imati odjeljak za analitiku za zaposlene.

Konfiguracija već sadrži dokument “Payroll”.

U zaglavlju ima dva datuma - "datum" i "period registracije", kao i dva datuma "datum početka" i "datum završetka" u svakom redu.

Podrazumijeva se da je datum jednostavno datum kada je dokument izvršen, period registracije označava za koji mjesec računamo platu, a datumi u svakom redu opisuju period važenja svake vrste obračuna.

Dodajmo početnu postavku atributa “Podaci” u modul dokumenta - u njega ćemo unijeti početnu platu, podesiti period registracije, period važenja i bazni period.

Modul dokumenta će izgledati otprilike ovako:

Za Svakom TechStringList Iz ciklusa liste

// registar Izračuni

Pokret = Pokreti .Izračuni.Dodaj();

Pokret .S torno= False;

Pokret .U idCalculation = TechStringList.CalculationType;

Pokret .PeriodActionsStart= Početak dana ( TechStringList.StartDate);

Pokret .PeriodActionEnd= EndDay();

Pokret .Registracijski period = Period registracije;

Pokret .BasicPeriodStart= Početak dana ( TechStringList.StartDate);

Pokret .BasePeriodEnd= Krajnji dan ( TechStringList.End Date);

Pokret .Employee = TechStringList.Employee;

Pokret .Raspored = TechStringList.Graph;

Pokret .Rezultat = 0;

Pokret .Data = TechStringList.Size;

EndCycle ;

Atribut Reversal je potreban za poništavanje unosa (analogno znaku minus).

Označavamo vrstu obračuna, a datume postavljamo na početak i kraj dana. Naravno, bazni period se može uneti samo za vrste obračuna zavisne od osnovice, a podaci se mogu unositi samo za platu, ali sve tako funkcioniše.

Sve dokumente ćemo datirati 20.01.2003., period registracije će biti postavljen na 01.02.2003. Period registracije preračunato na početak perioda 01/01/2003). Koristimo januar 2003. jer su za ovaj period završeni rasporedi radova.

Kreirajmo "Preračunavanje" za ponovno izračunavanje i dodajmo mu dimenziju "Zaposleni" povezanu s dimenzijom "Zaposleni".

Igranje sa Rekalkulacijama.

Da biste igrali igru, otvorite konzolu zahtjeva - obrada " CustomRequest» u konfiguraciji okvira. Kreirajmo novi upit koristeći konstruktor upita i dodajmo virtuelnu tabelu tamo Rekalkulacije, tekst zahtjeva će biti ovakav:

ODABIR

CalculationsRecalculation.O objektu Recalculation,

CalculationsRecalculation.In Calculation ID,

Obračuni Preračunavanje od zaposlenika

OD

Registar kalkulacije KAKO CalculationsRecalculation

Generisaćemo tri dokumenta - prvo ćemo obračunati plate zaposlenima A i B. Zaposleni A radi od 1. do 31. januara, B radi od 1. do 20. januara. Drugi će dodijeliti bonus zaposleniku B za period od 1. do 31. januara, treći će dodijeliti odsustvo zaposleniku A od 20. do 25. januara.

Igramo se sa stvarnim rokom važenja.

Kreirajmo novi upit - ovog puta ćemo mu dodati tabelarne podatke Proračunski registri.

Kreirajmo zahtjev i vidimo da je plata zaposlenog A podijeljena na dva perioda - od 1. do 19. januara i od 26. do 31. januara. Nadam se da razumete da je period podeljen na dva, jer... izostanak zamjenjuje platu.

Mislim da su nam mehanizmi rada računskog registra sve jasniji pred očima.

Hajde da proučavamo grafove.

Pokušajmo sada izračunati platu na osnovu plate zaposlenika.

Kreirajmo novi upit za registar proračuna koristeći virtuelnu tabelu Računi registri. Možete postaviti parametar za ovu virtuelnu tabelu - uslov za odabir zapisa, na primer Employee=&Odaberite zaposlenika I Tip kalkulacije=&Tip izračuna I Graf=&Grafički prikaz.

Postavimo određene zaposlene, vrste kalkulacija i rasporeda u parametrima zahtjeva i vidimo koliko sati je rezultat.

Kolona rezultata	Značenje
ValuePeriodAction	Za koji rok važenja u satima je izvršen upis u registar.
ValueActualPeriodAction	Koliko sati je zaposlenik stvarno radio?
ValueBasePeriod	Za platu nema smisla, za bonuse - broj radnih sati u baznom periodu.
ValueRegistration Period	Koliko radnih sati ima u periodu registracije (mesec januar)

Objekt Recalculation se koristi za pohranjivanje informacija o tome za koji registar izračunavanja bilježi rezultate proračuna (resurse) koje je potrebno ponovno izračunati. To je konfiguracijski objekt podređen registru proračuna. Potreba za ponovnim obračunom resursa može nastati zbog pogrešnog redoslijeda unosa dokumenta od strane korisnika (retroaktivni unos dokumenata), što dovodi do potrebe preračunavanja rezultata obračuna onih zapisa koji zavise od rezultata obračuna drugih zapisa unesenih u sistem kasnije.

Postavke objekta ponovnog izračuna

Informacije o zapisima koji zahtijevaju ponovno izračunavanje mogu se pohraniti u različitim detaljima.

Zapisi o dodjeli sadrže unaprijed definirana polja:

• Objekat rekalkulacije – link ka registratoru čije rezultate obračuna treba revidirati;
• Vrsta kalkulacije – veza ka tipu obračuna iz plana tipova obračuna koji je dodijeljen registru koji posjeduje objekt Rekalkulacija.

Dakle, u najmanju ruku, informacije o preračunama se pohranjuju tačno prema registratoru (dokumentu) i vrsti obračuna.

Da biste preciznije identificirali zastarjele unose u registar poravnanja, možete unijeti mjere alokacije. Ovo će vam omogućiti da suzite listu zapisa za koje je potrebno ponovno izračunavanje.

Pogledajmo primjer.

Ako registar obračuna pohranjuje podatke o obračunanoj osnovnoj plati zaposlenih u organizaciji i stoga registar obračuna ima dimenziju "Zaposleni", tada preračun može imati i dimenziju "Zaposleni". To će dovesti do toga da će evidencija preračuna značiti potrebu za preračunavanjem onih upisa koji pripadaju određenom matičaru, imaju određenu vrstu obračuna i sadrže vezu do određenog radnika.

Tabelu konverzije sistem može automatski popuniti na osnovu podešavanja napravljenih tokom konfiguracije. Automatsko praćenje zapisa za koje je potrebna revizija rezultata je glavna svrha objekta ponovnog izračunavanja.

Dimenzije alokacije su jedan od alata koji vam omogućavaju da konfigurirate ovo automatsko popunjavanje alokacije.

Ovo se radi pomoću svojstava dimenzije alokacije:

• Dimenzija registra – link ka dimenziji „nadređenog” obračunskog registra kojem je podređeno preračunavanje.
• Podaci vodećih registra – veze do mjerenja i detalji vodećih računskih registara.

Da bismo opisali posebnosti postavljanja mjerenja preračunavanja, dogovorit ćemo se oko sljedećih uslova:

• Glavni registar je računski registar kojem je podređeno preračunavanje i koji „prati“ relevantnost rezultata.
• Vodeći registri su računski registri čiji unosi utiču na rezultat obračuna unosa glavnog registra.

Ako sistem već ima zapise glavnog registra, onda bi svaka promjena u sastavu vodećih registarskih zapisa trebala dovesti do pojave zapisa preračunavanja. Ovi unosi ponovnog izračunavanja će signalizirati potrebu za ponovnim izračunavanjem jednog ili drugog skupa unosa glavnog registra.

Kako bi se tačno opisali koje promjene u vodećim registrskim unosima će dovesti do pojave preračunavanja, koriste se mjerenja ponovnog izračunavanja. Da biste odredili potrebu za ponovnim obračunom evidencije za istog radnika za kojeg su uneseni (promijenjeni) vodeći registarski zapisi, uradite sljedeće. Veza na dimenziju "Zaposleni" glavnog registra unosi se u svojstvo "Dimenzija registra", a veze na dimenziju "Zaposleni" svih vodećih registara se unose u svojstvo "Podaci vodećih registra". Sa ovim podešavanjem, u slučaju bilo kakve promjene u sastavu vodećih registarskih zapisa (tj. prilikom upisivanja odgovarajućeg skupa zapisa), dogodit će se sljedeće:

• Analiziran je skup vodećih registarskih zapisa (recimo da skup evidencija sadrži zapise za zaposlenog Ivanova koji imaju određeni rok važenja (npr. mart)
• Glavni registar će biti automatski zatražen
• Ako već sadrži zapise, prema Ivanovu, a njihov rezultat potencijalno zavisi od zapisa vodećeg registra (šta znači „potencijalno zavisi…” biće reči u nastavku), tada će se u preračunavanje unositi redovi sa sledećim podacima:

U ovom slučaju, redovi će se unositi samo ako takvi redovi već nisu u tabeli konverzije.

Treba napomenuti da pojavljivanje unosa preračuna ne znači nikakve promjene direktno u glavnom registru. Rekalkulacioni zapisi nisu ništa drugo do signal koji sistem daje. A kako tačno reagovati na ovaj signal o potrebi ponovnog izračunavanja unosa u registru zavisi od programera određenog rešenja. O primjerima obrade zapisa preračunavanja raspravljat ćemo u drugim publikacijama.

Postavke plana tipa kalkulacije koje se odnose na alokacije

Zavisnost nekih registarskih unosa od drugih gradi se kroz podešavanja planova za tipove obračuna. Za to se koriste sljedeći koncepti:

• Varijanta zavisnosti od osnove – svojstvo plana obračunskih tipova;
• Osnovni planovi tipova obračuna – svojstvo plana obračunskih vrsta;
• Vodeći tipovi obračuna - svojstvo vrste obračuna;
• Bazni period – detalji unosa u registru obračuna;
• Rok važenja – detalji unosa obračunskog registra;
• Period registracije – detalji unosa obračunskog registra.

Recimo da je glavnom registru obračuna dodijeljen plan tipa obračuna „Glavni“, a vodećem registru plan tipa „Pomoćni“. Zatim glavni plan tipova proračuna treba postaviti sljedeća svojstva grupe svojstava "Izračun":
Zavisnost od osnove – “po roku važenja” ili “po roku registracije”;
Osnovni planovi za obračunske vrste – plan za obračunske vrste „Pomoćni“.

To će značiti da glavni računski registar, koji se ponaša prema planu "glavnog" obračunskog tipa, zavisi od onih registara kojima je dodijeljen plan "pomoćnog" obračunskog tipa (tj. u našem slučaju vodeći računski registar) i na istovremeno sa unosima Glavni registar zavisi od matične evidencije po periodu važenja ili po periodu registracije.

Prilikom postavljanja plana za tipove obračuna "Glavni", njegovi tipovi obračuna (na primjer, tip obračuna "Dodatni dodatak") moraju biti postavljeni u listu vodećih tipova obračuna za tipove obračuna "Pomoćni" plan (npr. vrste obračuna “Lična doplata” i “Mjesečna doplata”). To će značiti da rezultati obračuna glavnih upisnika sa obračunskim tipom „Dodatak“ zavise od rezultata vodećih upisnika sa tipovima obračuna „Lična doplata“ i „Mjesečna doplata“ i moraju se preračunati u slučaju bilo kakve promjene (pojavljivanje ili brisanje).

Istovremeno, kako bi se utvrdilo koje zapise je potrebno preračunati, sistem će uporediti zapise glavnog i glavnog obračunskog registra:

• po vrsti obračuna,
• kada period važenja (ili period registracije) vodeće evidencije registra padne u osnovni period evidencije glavnog registra
• i dimenzijom Zaposleni, koja je gore opisana.

Ovaj materijal će vam omogućiti da napravite postavke koje će dovesti do automatskog popunjavanja tabela konverzije. Za neke zadatke automatsko dovršavanje možda neće biti dovoljno. U takvim slučajevima, trebali biste generirati zapise o dodjeli koristeći ugrađeni jezik sistema. O tome se detaljno govori u odjeljku "Unos alokacija pomoću ugrađenog jezika".

Jedan od zadataka koji se rješava korištenjem računskih registara je dobivanje okretaja registra korištenjem upita do virtualne tablice osnovnih podataka ili GetBase() metode. Registarski prometi se dobijaju na osnovu velikog broja različitih izvornih podataka, uključujući postavke i sadržaj plana obračunskih tipova, podešavanja obračunskog registra, parametre virtuelne tabele osnovnih podataka itd. Ali jednu od značajnih uloga u dobijanju osnovnih podataka imaju merenja registra proračuna.

Uloga dimenzija u parametriziranju virtuelne tabele osnovnih podataka

Jedan od važnih parametara virtuelne tabele osnovnih podataka je lista dimenzija po kojima se upoređuju unosi registra prilikom sumiranja podataka. Da biste riješili različite probleme, možda ćete morati zbrojiti resurse registra preko različitih skupova dimenzija. Pogledajmo primjer registra namijenjenog za obračun plata i ima tri dimenzije:

• organizacija,
• pojedinac,
• Subdivision.

Zamislimo da je potrebno riješiti sljedeće probleme:

• Dobijanje za pojedine evidencije registra prometa registra za sve evidencije sa istom podjelom kao izvorni zapis. To može biti, na primjer, obračun naknade, u zavisnosti od razgraničenja cijelog odjela.
• Dobivanje prometa iz evidencije sa istim pojedincem i odjeljenjem. One. primanje iznosa obračuna zaposlenih koji su mu obračunati u istom odeljenju (isključuju se obračuni za istog zaposlenog koje je primio u drugim odeljenjima).
• Primanje prometa iz evidencije sa istim pojedincem i istom organizacijom (svi obračuni za pojedinca unutar iste organizacije).

Svi navedeni zadaci rješavaju se upitima do virtualne tablice osnovnih podataka. U ovom slučaju, parametri “Mjerenja glavnog registra” i “Mjerenja osnovnog registra” će biti različiti za sva tri zadatka. U prvom slučaju, postoji jedna dimenzija – “Podjela”; u drugom - “Pojedinac” i “Jedinica”; u trećem - “Organizacija” i “Pojedinac”.

Optimizacija prikupljanja osnovnih podataka

Za gore navedene slučajeve, prilikom generisanja upita za virtuelnu tabelu osnovnih podataka, sistem će, u smislu jezika upita, izvršiti „levo spajanje“ tabele registra izračunavanja sa istom tabelom. U ovom slučaju, jedan od uvjeta povezivanja je jednakost vrijednosti u poljima koja su navedena kao dimenzije glavnog i osnovnog registra. Naravno, pored ovog uslova postoji i poređenje perioda važenja ili registracionog perioda sa početkom i krajem baznog perioda, poređenje vrsta obračuna itd., ali najstrožije ograničenje je, po pravilu, je ograničenje mjernih vrijednosti.

Stoga, da bi rezultirajući upit radio efikasno, važno je imati indeks u tablici registra proračuna koji sadrži polja upoređenih dimenzija kao prva polja.

Mogućnost indeksiranja dimenzija računskog registra nam omogućava da riješimo takav problem, ali samo za slučaj kada se jedna dimenzija upoređuje (u našem primjeru zadatak dobijanja podataka za odjel). U slučaju kada postoje dvije ili više uporedivih dimenzija, potrebno je izgraditi indeks za nekoliko dimenzija odjednom.

Upravo to je problem koji vam omogućava da riješite svojstvo osnovne dimenzije registra proračuna. Postavljanjem ovog svojstva na više dimenzija, dizajner konfiguracije na taj način kreira indeks za sve dimenzije označene kao “baza” (za više detalja, pogledajte odjeljak “Indeksi tabele baze podataka”).

Iz navedenog je jasno da se samo jedan takav indeks može kreirati za računski registar za optimizaciju akvizicije osnovnih podataka odabirom određenih dimenzija. Stoga je tokom razvoja važno pravilno procijeniti koje će se virtualne tablice najčešće koristiti i čija je optimizacija performansi najvažnija.

Vratimo se našem primjeru. Zamislimo da će obračuni koji zahtijevaju pribavljanje podataka o pojedincu i odjeljenju biti manje uobičajeni tokom operacije konfiguracije od obračuna koji zahtijevaju pribavljanje podataka o pojedincu i organizaciji. Zatim kao osnovne dimenzije treba navesti dimenzije „Organizacija“ i „Individua“. Istovremeno, moraćemo da se pomirimo sa činjenicom da će dobijanje osnovnih podataka o pojedincu i odeljenju biti relativno sporo.

Prilikom odabira baznih mjerenja treba procijeniti i njihovu „selektivnost“, tj. zamislite koliko će vrijednosti biti u određenoj dimenziji prilikom rada s konfiguracijom. Zamislimo da u našem primjeru jedan pojedinac može imati vrlo malo (jednu ili dvije) organizacije i relativno mnogo odjela. One. Pojedincu se gotovo uvijek isplaćuje plata za jednu organizaciju, a istovremeno se plate često obračunavaju za različite odjele. U takvim okolnostima ima smisla odabrati dimenzije „Individua” i „Divizija” kao osnovne.

Ali važno je zapamtiti redoslijed mjerenja računskog registra...

O redoslijedu mjerenja u računskom registru

Činjenica je da prilikom kreiranja indeksa koji će olakšati dobijanje osnovnih podataka, sistem u njega uključuje dimenzije onim redosledom u kom se nalaze u stablu konfiguracije. To znači da ćemo jednostavnim “promjenom” dimenzija “Individual” i “Division” promijeniti redoslijed polja u indeksu.

U našem primjeru, ako se kao osnovne odaberu dimenzije “Pojedinac” i “Odjeli”, tada njihovim preuređivanjem nećemo promijeniti brzinu dobijanja osnovnih podataka za pojedinca i odjel, ali ćemo radikalno pogoršati situaciju sa dobijanjem podataka za pojedinca i organizaciju. Prilikom upoređivanja vrijednosti u poljima „Organizacija“ i „Pojedinac“, sistem neće moći koristiti indeks Divizija+Pojedinac, jer polje „Pojedinac“ nije prvo u njemu, a uslov nije nametnut divizija. A u slučaju indeksa Individual+Division, i prijem osnovnih podataka za odjel i pojedinca, i prijem osnovnih podataka za organizaciju i pojedinca će imati koristi, jer će polje „Pojedinac“ biti prvo u indeks, sistem će moći da ga koristi „delimično” (jedno polje u isto vreme). Istovremeno, polje “Pojedinac” ima mnogo veću “selektivnost” od polja “Organizacija” i neće trebati mnogo vremena da se razrade uslovi za organizaciju.

Ako je osnovna dimenzija jedna

Ne zaboravimo na zadatak u našem primjeru, koji uključuje dobivanje osnovnih podataka samo za odjel. Čini se da kreiranje indeksa Individual+Division za rješavanje druga dva problema isključuje djelotvoran rad virtuelne tabele osnovnih podataka za jednu dimenziju “Division”. Ali ovdje moramo imati na umu mogućnost indeksiranja dimenzija registra (svojstvo indeksiranja). Mogućnost indeksiranja dimenzije omogućava vam da efikasno rešite problem dobijanja baze podataka na osnovu jedne osnovne dimenzije.

Dakle, u primjeru koji smo razmatrali, potrebno je svojstvo Basic postaviti na dimenzije “Individual” i “Division”, svojstvo Indexing na dimenziju “Division”, a također osigurati da je dimenzija “Individual” “viša ” nego dimenzija “Odjel” (redoslijed dimenzije “Organizacija” nije važan).