Osiguranje

Upisivanje podataka u registar akumulacije. Dokumenti, registri akumulacije, skd. Mjerenja registra akumulacije

16.12.2019

Svaki stručnjak za optimizaciju zna da morate započeti rad na ubrzanju 1C iz uskog grla sistema.

U 1C: Enterprise 8 takvo usko grlo je često upis u registar:

  • Samo po sebi, pisanje u bazu podataka je dovoljno dug proces (u vezi čitanja)
  • Pisanje registra je u toku pri svakom provođenju i ponovnom vođenju dokument
  • Često dokumenti su veoma veliki.(Sa velika količina linije)
  • Može se generirati jedan dokument kretanja u desetinama registara
  • Prilikom ponovnog objavljivanja dokumenta pisanje u bazu podataka se često izvodi 2 puta- stare pokrete treba očistiti, nove snimiti.

Optimizacija pisanja registra može značajno ubrzati sistem, na projektima nakon optimizacije, proces snimanja se često ponekad ubrzao.

U ovom članku ćemo pokriti glavne razlozi i načini optimizacije sporog upisivanja u registre.

Ukratko...

Glavni razlozi za sporo pisanje su sljedeći:

Rijetko se javlja samo jedan od uzroka na ovoj listi, obično se morate nositi s nekoliko problema odjednom u raznim kombinacijama.

Greška u dizajnu

Ponekad se u procesu revizije učinka dešavaju situacije kada klijent ima jedan registar koji zauzima 70% ili više od ukupne baze podataka. To dovodi do velikog opterećenja registra i prilikom čitanja i pisanja. Svako želi nešto da upiše u ovaj registar i pročita nešto, jer postoji večina podaci. Kao rezultat, dolazi do čekanja na zaključavanje, što negativno utiče na performanse i, između ostalog, uvelike usporava bilo kakvu modifikaciju podataka u registru.

Neophodno je izbjegavati situacije kada u jednom objektu imate pohranjenu veliku količinu podataka. Ako se takva situacija otkrije, naravno, možete napraviti konvoluciju, premjestiti stare podatke u zasebnu bazu podataka i smanjiti volumen registra, ali to će dati samo privremeni učinak. Ispravno rješenje bi bilo promijeniti arhitekturu rješenja. Ovdje dobro dolazi princip “zavadi pa vladaj”.

Naravno, realnost se prilagođava sama sebi, jer kada neko rešenje dugo funkcioniše, prilično je teško promeniti arhitekturu. Međutim, ovo se mora uzeti u obzir pri razvoju novih konfiguracija.

Postoji još jedan zanimljiv način optimizacije zapisa - ovo je odsustvo zapisa, također na neki način dizajnersko rješenje. Ako arhitektura vašeg računovodstvenog sistema ne zahteva visoku brzinu odziva na podatke, tada se upisivanje u takve registre koji nisu u realnom vremenu može obaviti kasnije.

Na primjer, sistem prvo jednostavno zapisuje dokumente na disk, ali ih ne objavljuje. Zatim, jedan ili više pozadinskih poslova zapisuju ove podatke tokom van radnog vremena. U ovom slučaju neće biti čekanja na brave.

Ova tema je detaljnije obrađena na kursu:

Vodimo VKontakte grupu -

U bilo kojoj stvarno funkcionalnoj bazi podataka 1C može nastati situacija kada dokument napravi veliki broj pokreta tokom izvršenja - nekoliko hiljada ili čak nekoliko desetina hiljada. Ovaj članak je posvećen karakteristikama pisanja tako velikih skupova zapisa u bazu podataka.

Prilikom jednog od poslova analize performansi koje su obavili naši tehnološki stručnjaci, morali su se suočiti s problemom poništavanja knjiženja dokumenta koji čini nekoliko hiljada kretanja u jednom od računovodstvenih registara. Problem se očitovao u nepredvidivosti vremena poništenja dokumenta. Ovo vrijeme je variralo od normalnog (od jednog minuta) do namjerno neadekvatnog (pola sata ili više) za isti dokument. U nekim slučajevima naši stručnjaci uopće nisu bili u mogućnosti otkazati postupanje - proces se nije završio prije kraja radnog dana i otkazan je ponovnim pokretanjem 1C servera.

Problem pisanja velikih skupova posebno je akutan za otkazivanje dokumenata za slanje. To je zbog činjenice da se prilikom izvođenja setovi mogu dodati u porcijama:

Mala studija sprovedena na ovu temu pokazala je da kada se koristi trenutno (u vreme pisanja ovog teksta) izdanje platforme 1C: Enterprise 8.1.15.41, vreme snimanja za setove linearno zavisi od broja zapisa u setu, tj. , vrijeme snimanja za 6 porcija od 3.000 transakcija i jednu od 18.000 transakcija je isto. Međutim, imali smo i informaciju da snimanje u nekoliko porcija u nekim slučajevima može biti efikasnije, a u toku rada opisanog u ovom članku u nastavku dobili smo teorijsko objašnjenje zašto bi to moglo biti tako.

Nažalost, prilikom otkazivanja izvršenja nije moguće snimati skupove u porcijama - možete samo izbrisati cijelu stvar, jedini predefinirani odabir od strane registratora ne ostavlja opcije.

Poznato je da pisanje velikih skupova zapisa registra akumulacije pomoću 32-bitnog 1C:Enterprise servera može propasti s porukom o nedostatku memorije, ali ovaj slučaj, iako je korišćen 32-bitni server, nije bilo izdavanja poruka, a nije se radilo sa registrom akumulacije, već sa registrom računovodstva.

Pokrenuli smo raspravu o ovom problemu na 1C partnerskoj konferenciji http://partners.v8.1c.ru/forum/thread.jsp?id=856332 (zahteva registraciju).

Kolege su me umirile, potvrđujući da u ovom slučaju nema suštinskih ograničenja i da problem mora imati rješenje. Kao primjer, dati su podaci o stvarnim dokumentima koji čine po 250.000 unosa.

Jedna od zanimljivih ideja (Sergey Doronin, VDGB-Soft, Yoshkar-Ola http://www.vdgb-soft.ru/) bila je da se otkaže objavljivanje dokumenta izvan transakcije:

Rješenje je pronašao stručnjak kompanije kupca, koji je otkazao postavljanje problematičnog dokumenta prebacivanjem baze podataka u ekskluzivni način rada (fragment koda iz Syntax Assistant-a):

O ovoj činjenici, dobili smo pojašnjenja od 1C (na istom mestu na konferenciji):

“U ekskluzivnom načinu rada, nema pristupa upravljanom upravitelju zaključavanja. Pošto imate prilično veliki broj poteza, menadžer zaključavanja troši značajnu količinu vremena zaključavajući resurse jedan po jedan u split modu. U vašoj situaciji, može se savjetovati da stavite upravljano zaključavanje na cijeli računovodstveni registar prije početka evidentiranja kretanja, umjesto postavljanja ekskluzivnog načina rada.

Dobiveni odgovor je omogućio ne samo da se potkrijepi eksperimentalno pronađena metoda za rješavanje problema, već je razjasnila još dvije stvari:

  • Zašto pisanje skupa zapisa u nekoliko dijelova u nekim slučajevima može biti efikasnije od jednog, kao što je gore objašnjeno.
  • Zašto u standardna rješenja 1C, na primjer, u konfiguraciji "1C: Upravljanje proizvodni pogon 8" u modulu dokumenta "Revalorizacija valutna sredstva» postavljeno je takvo, očigledno suvišno, blokiranje.

Nakon što je problem riješen, stigle su informacije o alternativnom načinu rješavanja problema (Pigolkin Stanislav, Axelot, Moskva http://www.axelot.ru/). U tu svrhu preporuča se onemogućiti korištenje zbroja:

O metodi SetUseTotals(<Признак>) u Syntax Helper-u kaže:

“Postavlja zastavu za korištenje zbroja. Ako je upotreba zbroja onemogućena, tada se prilikom pisanja skupa registarskih zapisa zbrojevi neće preračunavati, ali virtuelne tabele za obračun stanja i prometa neće biti dostupne.
Ovaj način rada registra vam omogućava da povećate brzinu pisanja skupa zapisa registra. Može biti korisno za masovna preuzimanja podataka.
Prilikom postavljanja zastavice za korištenje totala, svi zbrojevi se ponovo izračunavaju.

Pisanje velikih skupova zapisa u 1C registre ima neke posebnosti, ali je sasvim izvodljivo. U teškim slučajevima, gore navedene metode, kao što su:

  • snimanje u nekoliko porcija;
  • zapis izvan transakcije;
  • prebacivanje baze u ekskluzivni način rada;
  • postavljanje upravljanog ekskluzivnog zaključavanja na cijeli registar;
  • onemogućiti upotrebu zbroja

pomoći će u rješavanju problema. Upotreba svake od metoda trebala bi biti u skladu s postojećim realnostima specifične baze i organizacije rada kompleksa koristeći platformu 1C: Enterprise 8.

GK Trade Soft, Moskva

U ovom članku želim razmotriti takav mehanizam 1C: Enterprise 8 kao registre akumulacije. Ovaj mehanizam nam omogućava da akumuliramo numeričke indikatore o aktivnostima kompanije, te obrađuje te indikatore, izračunava rezultate i omogućava nam da dobijemo stanja i promet za te indikatore. Kao primjer dat ću registar akumulacije GoodsInWarehouses iz konfiguracije „Upravljanje trgovinom“.

Ovaj registar služi za čuvanje stanja robe u skladištima preduzeća u kontekstu nomenklature, karakteristika nomenklature, serije i kvaliteta robe. One. u svakom trenutku možemo vidjeti koliko u određenom magacinu, na primjer „Centralno skladište“, imamo artikle „Čizme za muškarce“, sa karakteristikom „43 veličina“, serijom od „20.08.2011“ i kvalitetom „novo ”.


A da bi to bilo moguće, podaci moraju biti upisani u registar. Platforma 1C:Enterprise je dizajnirana na način da je moguće upisati podatke u registar samo uz upućivanje na dokumente. One. ako se nešto promijeni u registru (prijem robe, odnosno njena prodaja), mora se navesti dokument koji je to napravio. Obično se podaci upisuju u registar kada se dokument knjiži. U modulu dokumenta postoji unapred definisana procedura Obrada knjiženja, u kojoj programer opisuje algoritam kojim se formiraju zapisi u registrima akumulacije.

Pogledajmo proces kreiranja registra od samog početka. Kao što se sjećate, kreirali smo konfiguraciju u kojoj već imamo direktorije i dokumente. Sada ćemo mu dodati registar akumulacije. Dodamo registar akumulacije, naziv “Roba u skladištima”, tip registra “Ostaci”. Kasnije ćemo razmotriti vrstu registra „Promet“. Na kartici podataka dodajte dimenziju “Nomenklatura” tipa “Referentna nomenklatura” i dodajte resurs “Količina” tipa broja (15,3).


Sada morate osigurati formiranje registarskih unosa prilikom objavljivanja dokumenta. Ali od dokumenata imamo samo “Ulazni nalog za gotovinu” i “Račun o troškovima”. U našem registru nemamo dokument koji bi vršio dolazna kretanja. Hajde da ga stvorimo. Kreiramo dokument, naziv je “Knjiženje robe”, na kartici podataka dodajemo tabelarni dio “Roba”, u njemu detalje “Nomenklatura” i “Količina”.


Da bi naš dokument vršio kretanja po registru akumulacije „Roba u magacinima“, na kartici Kretanje označite ga (registar) kvačicom i pritisnite dugme „Graditelj kretanja“. Ovaj konstruktor nam pomaže da napišemo algoritam za generisanje registarskih unosa, koji se nalazi u već pomenutoj proceduri „Obrada knjiženja“.

U konstruktoru ostavljamo tip kretanja registra kao “Dolazni”, u polju Tabularni dio biramo “Roba”, kliknemo na dugme “Popuni izraze” a zatim na dugme U redu.


Otvara se modul dokumenta u kojem je već kreirana procedura knjiženja obrade.
Procedura Handling Performing (Failure, Mode)
//((__REGIST_MOTION_CONSTRUCTOR
// Ovaj fragment gradi konstruktor.
// Ako se konstruktor ponovo koristi, ručne promjene će biti izgubljene!!!

// registrirati GoodsInWarehouses prijem
Movements.GoodsInWarehouses.Record = Tačno;
Movements.GoodsInWarehouses.Clear();
Za svaki ciklus proizvoda TekRowProducts From Products
Kretanje = Pokreti.GoodsInWarehouses.Add();
Movement.MovementType = MovementTypeAccumulation.Incoming;
Pokret.Period = Datum;


EndCycle;

//)) __REGISTER_MOTION_CONSTRUCTOR
EndProcedure

Sada pokrenimo Enterprise mod i kreiramo neke dokumente. Dokumenti u gornjem panelu sada imaju podmeni „Idi na“, koji vam omogućava da vidite kreirane dokumente kretanja u registrima.


Da vidimo koju robu imamo na zalihama, sačinićemo izveštaj koji će prikazati stanja prema registru „Roba u magacinima“.
Prebacite se na način rada konfiguratora i kreirajte izvještaj. Postavili smo naziv “Ostaci robe”. Na kartici obrazac kreirajte nova forma izvještaj i dodijelite ga kao glavni. Obrascu dodajemo polje dokumenta tabele, to se može uraditi preko menija „Kontrola za umetanje obrasca“ i odabrati tip elementa - polje dokumenta tabele, dodeliti mu naziv TabDoc i postaviti ga na ceo obrazac.


Zatim idemo na rukovalac gumba “Kreiraj”, izbrišemo komentar koji se tamo nalazi, postavimo kursor u tekst procedure rukovanja događajima, kliknemo desnim klikom i izaberemo “Konstruktor upita s obradom rezultata”. Ovo će nam omogućiti da kreiramo upit i odmah prikažemo njegov rezultat u izvještaju.
Na kartici Obrada rezultata izaberite „Izlaz u dokument tabele“, idite na karticu „Tabele i polja“. Vidimo da je tabela GoodsInWarehouses predstavljena kao četiri tabele.

Prva tabela je lista zapisa koje smo formirali u obradi knjiženja dokumenata, ostalo su virtuelne tabele koje platforma kreira sama. Ove tabele nam omogućavaju da dobijemo obrađene podatke na registru - promete za period, stanja na dan ili stanja i promete u jednoj tabeli. Želimo prikazati stanja, pa biramo tabelu Stanja. Iz ove tabele izaberite sva polja Nomenklatura i Preostala količina. Pritisnite dugme OK.
Konstruktor je generisao algoritam koji će nam prikazati izveštaj o stanju, samo treba da odredimo gde da prikažemo izveštaj.
Dodajmo red:
“TabDoc = FormElements.TabDoc;” prije teksta koji je generirao konstruktor.
TabDoc = FormElements.TabDoc;
//((REQUERY_CONSTRUCTOR WITH_RESULT_PROCESSING
// Ovaj fragment gradi konstruktor.
// Ako se konstruktor ponovo koristi, ručne promjene će biti izgubljene!!!

Layout = Reports.Stocks.GetLayout("Layout");
Zahtjev = Novi zahtjev;
Request.Text =
„IZABIR
| RobaU Skladištima Ostaci.Nomenklatura,
| ZASTUPANJE (Roba u magacinskim ostacima. Nomenklatura),
| RobaU skladištimaOstaci.KoličinaOstaci
OD
| Registar akumulacije. Roba u skladištima. Ostaci KAO roba u magacinima ostaje";

Rezultat = Request.Run();

AreaHeader = Layout.GetArea("Header");
AreaFooter = Layout.GetArea("Podrum");
TableHeader Area = Layout.GetArea("TableHeader");
AreaFooterTables = Layout.GetArea("FooterTables");
AreaDetailRecords = Layout.GetArea("Detalji");

TabDoc.Clear();
TabDoc.Output(RegionHeader);
TabDoc.Output(TableHeaderArea);
TabDoc.StartAutogroupRows();

SelectionDetailRecords = Result.Select();
Dok SelectionDetailRecords.Next() Loop
AreaDetailedRecords.Parameters.Fill(SelectionDetailedRecords);
TabDoc.Output(AreaDetailRecords, SelectionDetailedRecords.Level());
EndCycle;
TabDoc.EndAutoGroupRows();
TabDoc.Output(RegionFooterTable);
TabDoc.Output(RegionFooter);

//)) REQUEST_CONSTRUCTOR WITH_RESULT_PROCESSING
Pokrenimo način rada 1C:Enterprise i vidimo kako funkcionira izvještaj.


Kao što vidite, dizajner je napravio nešto manje-više prihvatljivo za nas.
Imamo i „Rasprodaju robe“, koja bi trebala smanjiti naše bilance. Napravimo tako da formira i kretanje registra.
Otvorite dokument, na kartici Pokreti, postavite “kvačicu” ispred našeg registra i pritisnite dugme “Motion Builder”.

Podesite vrstu kretanja registra na trošak, izaberite tabelarni deo „Proizvodi“, kliknite na „Popuni izraze“ i „OK“. Konstruktor je generisao algoritam za držanje dokumenta, hajde da ga proverimo. Da bismo to učinili, ponovo ćemo pokrenuti način rada 1C: Enterprise i ponovo objaviti kreirane dokumente „Prodaja robe“.
Zatim ćemo ponovo generirati izvještaj o stanju.


Kao što vidite, bilansi su se smanjili, čak su i za neke pozicije postali negativni. To je zato što ne kontrolišemo prisustvo salda prilikom prodaje robe.
Naš registar “Roba u magacinima” tipičan primjer registar stanja, ima kretanja i dolaznih i odlaznih. Ali u 1C sistemu još uvijek postoje registri prometa.
Kao primjer navešću registar „Prodaja“. Svaki put kada prodamo proizvod kupcu, bilježimo ko je šta kupio i koliko od nas. I onda u izvještaju možemo vidjeti koliko je robe neko kupio kod nas. Ovaj registar neće evidentirati kretanja zasebno prihode ili rashode. Pokreti će biti isti. U tim slučajevima koristi se registar prometa.

Kreirajmo takav registar u našoj konfiguraciji. Dodajmo novi registar akumulacije, naziv "Prodaja", tip registra "Promet", na kartici podataka ćemo dodati dimenziju "Kupac" i "Nomenklatura", resurse "Količina" i "Iznos".


Vratimo se na dokument “Prodaja robe”, na kartici kretanja, postavite “kvačicu” ispred registra “Prodaja” i pritisnite dugme “Graditelj kretanja”. Pritisnite dugme (+) (dodaj) i izaberite registar „Prodaja“, zatim, kao i obično, izaberite tabelarni deo i kliknite na „Popuni izraze“. "UREDU".
// Registar prodaje
Moves.Sales.Record = Tačno;
Moves.Sales.Clear();
Za svaki ciklus proizvoda TekRowProducts From Products
Kretanje = Pokreti.Prodaja.Dodaj();
Pokret.Period = Datum;
Movement.Client = Klijent;
Movement.Nomenclature = CurrentLineProducts.Nomenclature;
Movement.Quantity = CurrentStringProducts.Quantity;
Movement.Amount = CurrentLineProducts.Amount;
EndCycle;

Pokrećemo 1C u Enterprise mod, prenosimo dokumente „Prodaja robe“, provjeravamo da li su kretanja formirana. Izvještaj možete sami generirati, sve se to radi po istom principu kao i prethodni izvještaj, potrebno je odabrati tabelu „Prodaja. Promet“.

A sada dodajmo sučelje našoj konfiguraciji tako da ne moramo otvarati dokumente kroz meni „Operacije“. Otvorite granu "Općenito" u konfiguratoru, potražite Interface u njoj i dodajte novi. Otvara se program za izgradnju interfejsa, u njemu pritisnemo dugme „Izgradi“. Sve. Pojednostavljeni interfejs je spreman. Da bi se otvorio po zadanim postavkama, potrebno je sučelje koje smo kreirali postaviti kao glavni interfejs u svojstvima konfiguracije (desni klik na gornji element stabla konfiguracije - Svojstva) kao glavni interfejs.
Pogledajte ovaj izgled:

To je sve što sam danas htio reći o registrima akumulacije. Ako imate pitanja pišite, rado ću vam pomoći.

Napisao: Roman Zabolotin
Email: eval(unescape("%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72% 65%66%3d%22%6d%61%69%6c%74%6f%3a%72%7a%61%62%6f%6c%6f%74%69%6e%40%67%6d%61% 69%6c%2e%63%6f%6d%22%3e%72%7a%61%62%6f%6c%6f%74%69%6e%40%67%6d%61%69%6c%2e% 63%6f%6d%3c%2f%61%3e%27%29%3b"))

Registar akumulacije 1C ovo je strukturirani skup podataka koji sadrži informacije o svim kretanjima (primanju / izdatku ili prometu) odabranih dokumenata.

Vrste registra akumulacije

U 1C postoje samo dvije vrste registra akumulacije:

  • Promet
    Ako planirate primati samo promete iz registra, obavezno postavite vrstu prometa.
    Na primjer, prilikom registracije prodaje, broj prodaja nam je važan i bilansi ovdje apsolutno nisu potrebni. Stoga se tip registra mora postaviti na "Promet".
  • Ostaje
    Ako planirate primati stanja i promete iz registra, postavite vrstu stanja. Na primjer, uzmimo registar akumulacije "Roba u skladištima" u njemu važna informacija biće i stanja i prometa. Stoga, tip registra mora biti postavljen na "Ostaci".

Pažnja: ne pravi izbor tip registra akumulacije će rezultirati niskim performansama baze podataka.

Dimenzije, resursi, atributi i standardni atributi

U bilo kojem registru akumulacije postoje mjerenja, resursi, detalji i standardni detalji.

mjerenja potrebni su za formiranje ključnih podataka evidencije, prema kojima u budućnosti možete dobiti stanja ili vidjeti promet po dimenzijama koje vas zanimaju.
Također u svojstvima dimenzije možete postaviti provjeru popunjavanja dimenzije (prazna vrijednost će uzrokovati grešku)

Resursi potrebno za pohranjivanje podataka o zbroju u registru: količina, iznos itd. U budućnosti ćemo resurse dobijati mjerenjem.

Requisites uglavnom su potrebni za pohranjivanje povezanih informacija i rijetko se koriste.

Standardni detalji su kako slijedi:

  • period - datum kada je izvršeno kretanje registra
  • matičar - dokument kojim je izvršen upis u registar
  • vrsta kretanja - prihod ili rashod (priliv povećava količinu resursa, a potrošnja se smanjuje)

Registrari

Registratori su dokumenti koji mogu izvršiti kretanje u registru akumulacije. Kretanja u registru akumulacije 1C mogu se vršiti samo putem dokumenata (registratora). Većina algoritama za kreiranje kretanja u akumulacionom registru formira se kada se dokument knjiži u objektnom modulu, proceduri „Knjiženje obrade“.


Indeksiranje dimenzija

Indeksiranje je potrebno za povećanje performansi baze podataka.
Svojstvo "Indeks" mora biti specificirano za dimenzije za koje se planira izvršiti više selekcija i koje imaju veliki broj elemenata.

Na primjer: registar akumulacije "Serije robe u skladištima". Postoji dimenzija "Nomenklatura" i "StatusParty". Za dimenziju „Nomenklatura“ je svrsishodnije postaviti atribut indeksiranja nego za „Status stranke“, jer je broj opcija za nomenklaturu mnogo veći nego za status serije.

Jedinstvenost zapisa

1C Enterprise kontroliše jedinstvenost unosa u registru akumulacije, te stoga nećete pronaći dva identična unosa.

Mogućnosti registra akumulacije

  • izbor zapisa za određeni period prema datim dimenzijama
  • izbor evidencije od strane matičara
  • dobijanje stanja i prometa na odabrani datum sa navedenim mjerenjima
  • izračunavanje ukupnih iznosa za određeni datum

Primjeri rada sa registrom akumulacije

Primjer dobijanja stanja za tekući datum

Procedura GetRemainderOnDate()
Novi zahtjev = Novi zahtjev;
NewRequest.Text =
„IZABIR
| Robni ostaci. Nomenklatura,
| CommodityRemains.QuantityRemainder
OD
| Registar akumulacije.GoodsInWarehouses.Remains(&CurDate,) AS ToVRemains";
NewQuery.SetParameter("CurrentDate", CurrentDate());

EndCycle;
EndProcedure

Primjer dobijanja prometa za tekuću godinu

Novi zahtjev = Novi zahtjev;
NewRequest.Text =
„IZABIR
| Robni promet. Nomenklatura,
| CommodityTurnover.QuantityTurnover
OD
| Registar akumulacije.ItemsInWarehouses.Turnovers(&StartPeriod, &EndPeriod,) AS TovTurnovers";

NewQuery.SetParameter("StartPeriod",StartYear(CurrentDate()));
NewQuery.SetParameter("EnPeriod", CurrentDate());

RequestFetch = NewQuery.Execute().Select();

Dok Query Fetch.Next() petlja
EndCycle;

Primjer kako odabrati kretanje u registru akumulacije

Novi zahtjev = Novi zahtjev;
NewRequest.Text =
„IZABIR
| Roba u skladištima. Period,
| Roba u magacinima.Registar,
| RobaU skladištima.TipKretanje,
| Roba u skladištima. Nomenklatura,
| Roba u skladištima. Količina
OD
| Registar akumulacije. Roba u skladištima AS Roba u skladištima";

RequestFetch = NewQuery.Execute().Select();

Dok Query Fetch.Next() petlja
EndCycle;

Obrasci liste registara akumulacije

Obrasci se koriste za vizualni pregled svih kretanja odabranog registra. U njemu možete vidjeti koji dokumenti čine trošak ili prihod, kao i po kojim mjerama. Takođe tamo možete sortirati pokrete ili napraviti selekciju.
Sistem će automatski biti u mogućnosti da generiše obrazac liste ili ga možete sami prilagoditi.