U članku je opisana fizička implementacija virtualne tablice konfiguracijskih reziduala koja radi u klijent-server načinu rada na primjeru MS DBMS-a. SQL Server.
Primjenjivost
Članak se bavi verzijom platforme 1C:Enterprise 8.3.5.1383. U trenutnoj verziji platforme moguće su neke promjene u tekstu opisanom u materijalu, T-SQL upit izvršava se na strani DBMS servera.
Uređaj virtualne tablice ostataka
Razmotrimo u kakvu vrstu upita prema DBMS-u upit se pretvara u korištenje virtuelne tablice stanja registra akumulacije. Na primjer, sljedeći tekst zahtjeva će se uzeti u obzir:
ODABIRATI
CommodityStocksRemains.Commodity,
CommodityStocksRemains.Warehouse,
CommodityStocksRemains.QuantityRemains
OD
Registar akumulacije, robne zalihe, bilansi(&Datum , Skladište = &Skladište ) KAKO
CommodityStocksRemains
Prvo s metodom globalnog konteksta GetDatabaseStorageStructure() dobiti listu tablica baze podataka koje pohranjuju podatke registra akumulacije "Robne zalihe":
Sastav polja glavne tabele registra akumulacije i tabele ukupnih iznosa dat je u nastavku:
Pohranjivanje ukupnih iznosa za ovaj registar konfiguriran u 1C:Enterprise 8 modu kako slijedi:
Popunite parametre u predmetnom zahtjevu na sljedeći način:
Platforma pretvara tekst zahtjeva u sljedeći zahtjev, koji će se izvršiti na DBMS serveru:
SELECT
Q_000_T_001.Fld82 ,
Q_000_T_001.Fld83 ,
Q_000_T_001.Fld84Balance
OD
(ODABIR Fld82 ,
fld83,
OD
(ODABIR Fld82 ,
fld83,
SUM (Fld84 ) KAO Fld84Balance
OD AccumRgT85
WHERE Period = DATETIME (3999 , 11 , 1 )
I ((Fld83 = ))
I (Fld84<>0 ) I (Fld84<>
0
)
GRUPA PO Fld82 , Fld83
IMAJUĆI Fld84Balance<>
0
UNION ALL
SELECT Fld82 ,
fld83,
ZBIR (SLUČAJ KADA RecordKind = 0 ONDA - Fld84 ELSE Fld84 END ) KAO Fld84 Balance
OD AccumRg81
WHERE Period >= DATETIME (2012 , 9 , 1 )
I Period<
DATETIME
(3999
,
11
,
1
)
AND Active
I ((Fld83 = 9:))
GRUPA PO Fld82 , Fld83
IMAJUĆI Fld84Balance<>0 ) T
GRUPA PO Fld82 , Fld83
IMAJUĆI Fld84Balance<>0) Q_000_T_001
Analizirajmo pristigli zahtjev detaljnije.
Prvo, koristeći prvi upit uključen u spajanje, podaci se biraju iz rezultirajuće tablice AccumRgT85. Zbroji se dobijaju na dan skladištenja tekućih zbroja (11.01.3999), dodatni uslov se nameće polju Skladište (pošto je takav uslov korišćen u parametrima virtuelne tabele). Dodatno, provjerava se odsustvo redova sa nula ostataka u rezultatu.
Imajte na umu da se grupisanje vrši prema dimenzijama odabranim u tekstu upita. Zbog toga tekst u jeziku upita 1C:Enterprise ne zahtijeva dodatno grupisanje po dimenzijama.
Drugi upit za spajanje koristi tablicu kretanja registra AccumRg81. U zavisnosti od vrste kretanja (ako je RecordKind jednak 0, onda je ovo Inflow, inače - Outflow), u izraz se stavlja znak. Platforma bira podatke za period od datuma navedenog kao parametar virtuelne tabele do datuma pohranjivanja trenutnih ukupnih vrednosti (01.11.3999).
Osim toga, biraju se samo aktivni zapisi, polje Skladište mora biti jednako navedenoj vrijednosti. Kao i kod prvog upita za spajanje, ovo također grupiše prema odabranim dimenzijama i odbacuje zapise sa nultim vrijednostima resursa.
Ako se koristi MS SQL Server DBMS i za bazu podataka je postavljen pomak datuma 2000, tada će svi datumi biti pohranjeni sa navedenim pomakom, tj. umjesto 11/01/3999 vidjet ćete 11/01/5999.
Ako onemogućite trenutne zbrojeve za registar akumulacije, platforma će prvo primiti najnovije zbrojeve izračunate na datum ranije od navedenog u parametru Period virtualne tablice.
Zatim će se, na sličan način, ovi podaci dopuniti iz tabele kretanja, ali samo za period od datuma poslednjih zbroja do perioda virtuelne tabele.
SELECT
Q_000_T_001.Fld82 ,
Q_000_T_001.Fld83 ,
Q_000_T_001.Fld84Balance
OD
(ODABIR Fld82 ,
fld83,
SUM (Fld84Balance ) AS Fld84Balance
OD
(ODABIR Fld82 ,
fld83,
SUM (Fld84 ) KAO Fld84Balance
OD AccumRgT85
WHERE Period = DATETIME(2012 , 4 , 1 )
I ((Fld83 = 9:))
I (Fld84<>
0
)
I (Fld84<>
0
)
GRUPA PO Fld82 , Fld83
IMAJUĆI Fld84Balance<>
0
UNION ALL
SELECT Fld82 ,
fld83,
ZBIR (SLUČAJ KADA RecordKind = 0 ONDA Fld84 ELSE - Fld84 END ) KAO Fld84Stand
OD AccumRg81
WHERE Period >= DATETIME (2012 , 4 , 1 )
I Period<
DATETIME
(2012
,
9
,
1
)
AND Active
I ((Fld83 = 9:))
GRUPA PO Fld82 , Fld83
IMAJUĆI Fld84Balance<>0 ) T
GRUPA PO Fld82 , Fld83
IMAJUĆI Fld84Balance<>0) Q_000_T_001
Obratite pažnju na sljedeće stanje u tijelu zahtjeva.
Ako vam je moj post koristan, ne zaboravite da date glas :-)
Ovdje je rubrikator za sve zadatke zbirke(stranica sa linkovima na teme na forumu za svaki zadatak)
http://chistov.spb.ru/forum/16-969-1
Pa, sada moji razvoji i bilješke koje sam kreirao u procesu pripreme.
Pokušaću da ponovim u najmanju ruku sa ova dva gore pomenuta zadnji publikacije.
Pa da počnemo:
U slučaju daljinske dostave, trebali biste imati dva objekta na radnoj površini na kraju ispita:
1. Završno učitavanje baza informacija(dt fajl)
2. Objašnjenje
Ne bi trebalo biti ništa drugo, nema međukopija itd.
Obavezno napišite objašnjenje!
U slučaju nejasno formulisanog zadatka, obavezno tu napišite da ste odabrali upravo takvo i takvo rješenje.
Takođe u kodu na ključnim mjestima je bolje ostaviti kratke komentare, bez fanatizma, ali tamo gdje ispitivač može imati pitanja, bolje je napisati.
Ali o tome će vam biti rečeno u uputama koje ćete pročitati prije ispita.
Bolje je znati unaprijed)
Korištenje upita za prijavu znakom ampersand.
Ponekad je brže birati dodatna tastatura nego prebacivanje rasporeda naprijed-nazad štedi vrijeme
&=Alt+38
*************************************************************************************************
Korištenje MomentTime() u upitima
U upitima registrima akumulacije, računovodstvu, kao parametar virtuelne tabele (perioda), potrebno je koristiti ne datum dokumenta, već parametar Moment, koji je u kodu definisan na sledeći način:
Moment = ?(PostMode = PostModeDocument.Online, Undefined, MomentTime());
*************************************************************************************************
Prilikom generisanja kretanja dokumenta po registru, na samom početku postupka obrade knjiženja potrebno je obrisati kretanje tekućeg dokumenta po registru.
Kod je ovakav:
Movements.RegisterName.Write = Tačno; Movements.RegisterName.Clear();
Moguće je da će u postupku sprovođenja biti potrebno izvršiti analizu evidencije u ovom registru.
Dakle, da kada analizirate trenutne zapise (stare, prije promjene dokumenta) ne bi baš upali u selekciju, možete dodati još jedan red u gornja dva reda:
Movements.RegisterName.Write();
Ili, kada analizirate zapise, eksplicitno navedite granicu koja ne uključuje trenutak u vremenu trenutnog dokumenta.
Ali svuda sam samo naznačio konstrukciju ove tri linije odjednom:
Movements.RegisterName.Write = Tačno; Movements.RegisterName.Clear(); Movements.RegisterName.Write();
*************************************************************************************************
Postoje dva načina za blokiranje podataka, izbor između njih ovisi o načinu provođenja - stari ili novi:
1) Konvencionalno upravljano zaključavanje, stari način postavljanja dokumenta (DataLock objekat)
Postavlja se ako se prvo provjeravaju stanja, a zatim otpisuju.
U slučaju kada trebamo imati neke podatke iz registra za formiranje kretanja.
primjer:
U dokumentu - količina, u registru - količina i iznos (trošak)
Dakle, znamo količinu robe iz dokumenta - koliko otpisujemo, ali cijenu koštanja - ne.
To možemo naučiti samo iz registra, ali da niko ne bi mijenjao registar između trenutka prijema stanja i trenutka evidentiranja kretanja, potrebno je blokirati registar i prije očitavanja stanja.
Dakle, u ovom slučaju se koristi objekt DataLock. A kada ga kreirate, ispravnije je naznačiti po kojim dimenzijama blokiramo registar (na primjer, u našem slučaju - samo po nomenklaturi navedenoj u dokumentu) - tako da nema nepotrebnih brava i da drugi korisnik može prodati drugu nomenklaturu.
1. Postavite zaključavanje pomoću DataLock objekta
2. Pročitajte ostatak
3. Provjera mogućnosti zaduženja
4. Formiramo kretanja, na primjer, otpisujemo robu
5. Nakon knjiženja dokumenta, blokiranje se automatski otpušta (blokada važi u okviru transakcije knjiženja i automatski se oslobađa od strane sistema). Odnosno, nema potrebe za posebnim otključavanjem objekta.
2) Nova metodologija vođenja dokumenata
(koristeći svojstvo LockForChange = True)
Koristi se ako nam nisu potrebni podaci iz registara za formiranje kretanja, a možemo provjeriti da li smo ušli u minus prilikom zaduženja, ako nakon evidentiranja pogledamo stanja registra i vidimo da ima negativnih. U ovom slučaju, shvatit ćemo da smo otpisali višak i otkazati operaciju otpisa.
primjer:
Razmotrite operaciju prodaje robe.
U dokumentu - količina, u registru - samo količina
Dakle, količinu robe znamo iz dokumenta.
Pokrete formiramo s brojem navedenim u dokumentu i evidentiramo ih. Zatim čitamo registar, gledamo ostatke, analiziramo da li ima negativnih. Ako postoji, prikazujemo grešku i postavljamo Odbijanje = Tačno.
Dakle, redoslijed je:
1. Za kretanje kroz registar, postavite svojstvo LockForChange = True
2. Formiramo kretanja - otpisujemo robu
3. Zabilježite pokrete
4. Pročitajte registar, uvjerite se da nema negativnih stanja. Ako ima, onda su otpisali višak, ako ne, onda je sve u redu.
Dakle, u ovom slučaju nema potrebe da označavamo na kojim dimenzijama treba da blokiramo registar.
Jednostavno postavljamo svojstvo BlockToChange = True prije snimanja naših kretanja, formiramo kretanje i snimamo.
Sistem će sam blokirati registar u trenutku snimanja prema potrebnim mjerenjima, nakon analize onoga što smo snimili.
Kada se završi, brava će biti uklonjena.
Ova opcija (druga) je jednostavnija, zove se "nova metoda vođenja dokumenata" i 1C preporučuje da je koristite ako je moguće i oduzima bodove ako se koristi prva opcija, ali u nekim slučajevima jednostavno se ne može primijeniti, a prva Opcija se koristi sa objektom Data Lock (vidi dolje). primjer iznad).
Također napominjem da bez obzira na odabranu metodu, pokreti moraju biti očišćeni prije rada s njima (vidi prethodni savjet)
*************************************************************************************************
Blokiranje podataka (metoda blokiranja br. 1 iz gornjeg opisa)
Kontrolirano zaključavanje je potrebno tamo gdje se podaci čitaju i kreću se na osnovu tih podataka
Najbrži način da dobijete upravljani kod zaključavanja je da upišete "DataLock", pozovete pomoćnik za sintaksu i odatle samo kopirate primjer koda. Tada ga je lako promijeniti pod imenom vašeg registra i mjera.
izgleda ovako:
Zaključavanje = Novi DataLock; LockElement = Lock.Add("Registar akumulacije.GoodsInWarehouses"); LockItem.Mode = DataLockMode.Exclusive; LockItem.DataSource = PM; LockElement.UseFromDataSource("Nomenklatura", "Nomenklatura"); Lock.Lock();
*************************************************************************************************
Tabelarni dio dokumenata bolje je nazvati jednostavno "PM"
Tabelarni dio u 99% dokumenata je jedan. Tako jedinstveno ime tabelarni delovi To će vam pomoći da uštedite mnogo vremena jer:
1) Vrlo kratko - pišite brzo
2) Isto za sve dokumente, ne morate pamtiti kada pišete kod kako se zove
*************************************************************************************************
Provjerite rezultat zahtjeva za prazninu prije odabira ili učitavanja u TK.
Općenito, koristio sam uzorkovanje u svim zadacima.
Uzorak je optimalniji za sistem u pogledu performansi, jer je "naoštren" samo za čitanje podataka (za razliku od TK).
Ali u svakom slučaju, prije metode Select() bolje je provjeriti rezultat zahtjeva za prazninom, to će dodatno smanjiti opterećenje sistema.
Rezultat = Request.Run(); Ako nije Result.Empty() onda Selection = Result.Select(IteratingQueryResult.By Groupings); ... EndIf;
I u slučaju da trebamo dobiti samo jednu vrijednost iz zahtjeva
(na primjer, samo metoda otpisa u skladu sa računovodstvena politika postavljeno za ovu godinu):
Rezultat = Request.Run(); Ako nije Result.Empty() onda Selection = Result.Select(); Selection.Next(); Metoda otpisa troškova = Uzorak Metoda otpisa troškova; EndIf;
*************************************************************************************************
Dokument "Operacija" za zadatak BU
Obavezno kreirajte Operativni dokument za BU zadatke.
Isključujemo njegovo vođenje općenito (u svojstvima "Conducting = Deny"), označavamo šta čini kretanja u računovodstvenom registru, izvlačimo kretanja na obrascu.
*************************************************************************************************
Operativna obrada dokumenata:
Mora biti uključeno:
U operativnom i računovodstvenom. obračun dokumenata mora biti omogućen (osim za dokument "Operacija", vidi dolje).
Mora biti ugašeno:
u obračunskim zadacima nema smisla za platni spisak.
Za dokument "Operacija" knjiženje treba općenito onemogućiti (u svojstvima dokumenta "Post = Disable"),
pošto piše samo upisuje podatke direktno u registar prilikom pisanja.
*************************************************************************************************
Uvjet u upitu kao što je "Ili navedena nomenklatura ili bilo koja, ako nije navedena"
U upitima postoji takav zadatak: na primjer, trebate odabrati dokumente s navedenom nomenklaturom ili sve dokumente ako nomenklatura nije navedena.
Rešava se sledećim uslovom u samom zahtevu:
Nomenklatura = &Nomenklatura ILI &Nomenklatura = Vrijednost(Catalog.Nomenclature.EmptyReference)
Ali biće optimalnije i ispravnije transformirati ovo stanje (hvala yukon):
Query.Text = Query.Text + " WHERE Nomenklatura = &Nomenklatura";
EndIf;
S pojavom objektnog modela upita u 8.3.5, bit će sigurnije dodati uvjet:
Ako je ValueFilled (nomenklatura) Onda
Query1.Filter.Add("Nomenklatura = &Nomenklatura");
Query.SetParameter("Nomenklatura", Nomenklatura);
EndIf;
*************************************************************************************************
Spajanje tabela u upite:
Broj ukupnih zapisa ne zavisi od toga da li će se prikazati polje priložene tabele, zavisi samo od konfigurisanih veza.
To jest, polje priložene tabele možda neće biti prikazano.
Ako želite da priložite tabelu bez ikakvih uslova, onda na kartici sa uslovima jednostavno napišite uslov "TRUE".
U ovom slučaju, tabela će se tačno spojiti.
*************************************************************************************************
Koristeći plan tipova karakteristika (PVC):
1. Koristite kao mehanizam za opisivanje karakteristika objekata.
1.1. Izrađujemo PVC. To će biti tipovi karakteristika (npr. boja, veličina, maks. brzina, itd.). U postavkama odaberite sve moguće vrste karakterističnih vrijednosti i, ako je potrebno, kreirajte objekt iz paragrafa 1.2 i navedite ga također u postavkama.
1.2. Za dodatne PVC vrijednosti kreiramo direktorij ekstravrijednosti karakteristika (ili jednostavno vrijednosti karakteristika) koji mu je podređen.
Karakteristike će biti pohranjene u njemu ako se ne nalaze u postojećim direktorijima. Ne možemo ga kreirati ako se sve karakteristike koje su nam potrebne nalaze u postojećim direktorijima ili se te vrijednosti mogu predstaviti elementarnim tipovima podataka. U PVC postavkama označavamo da će se ovaj direktorij koristiti za dodatne. karakteristične vrijednosti.
1.3. Kreiramo registar informacija, koji zapravo povezuje tri objekta:
- Predmet za koji povezujemo mehanizam karakteristika
- Vrsta karakteristika (PVC tip)
- Karakteristična vrijednost (tip - karakteristika, ovo je novi tip koji se pojavio u sistemu nakon kreiranja PVC-a
i opisivanje svih mogućih tipova podataka koje vrijednost karakteristike može uzeti).
U registru informacija navodimo da je tip karakteristike vlasnik za vrijednost karakteristike (odnos parametara izbora), kao i odnos tipa za vrijednost karakteristike, opet iz tipa karakteristike.
Još jedna karakteristika je da za svaki kreirani tip karakteristike možete odrediti tip vrijednosti karakteristike, ako vam nisu potrebni svi mogući tipovi da opišete vrijednost ove karakteristike.
2. Korištenje PVC-a za kreiranje podkonto mehanizma registra računovodstva .
2.1. Izrađujemo PVC tipove Subconto.
2.2. Kreiramo podređeni direktorij Subconto vrijednosti (kao i kod karakteristika, on će sadržavati podkonto vrijednosti ako ih nema u drugim direktorijima).
2.3. Povezivanje se vrši pomoću kontnog plana.
*************************************************************************************************
Resursi računovodstvenog registra:
Iznos - stanje,
Količina - vanbilansna i povezana sa računovodstvenim znakom Kvantitativno
*************************************************************************************************
Virtuelne tabele računovodstvenog registra:
Promet: promet na jednom računu
PrometDtKt: promet između neka dva računa, odnosno sve iste transakcije za period.
*************************************************************************************************
Valutno računovodstvo na računovodstvenim registrima - kako implementirati:
U kontnom planu kreiramo znak računovodstvene "valute".
U računovodstvenom registru dodatno kreiramo:
- Valutna dimenzija (zabrana praznih vrijednosti, vanbilans stanja, obračunski znak - valuta)
- Resurs CurrencyAmount (vanbilansni, računovodstveni znak - valuta, pohranit će iznos u valuti, odnosno 100 $ na primjer)
Sve.
Dakle struktura registra:
Mjerenja:
- Valuta
Resursi
- Količina
- Iznos (iznos u rubljama)
- CurrencyAmount (iznos u valuti)
Dakle, valutno računovodstvo je samo usavršavanje uobičajenog računovodstva u Republici Bjelorusiji, ono ne mijenja suštinu, na primjer, iznos resursa
(tamo je, kao i obično, iznos u rubljama, bez obzira da li je račun u stranoj valuti ili ne).
A ako je atribut valutnog računovodstva za račun isključen, onda je ovo uobičajena struktura Republike Bjelorusije (resursi - samo količina i iznos).
*************************************************************************************************
Prilikom postavljanja parametara virtuelne tabele da bi se dobio deo potonje, namećemo uslove na dimenzije, a ne na resurse.
U suprotnom, nećemo dobiti dio najnovijeg, već posljednjeg zapisa sa navedenom vrijednošću resursa - možda neće biti posljednji u nizu mjerenja
*************************************************************************************************
Značenje resursa i atributa u registru obračuna
U računskim registrima kreiranje resursa omogućava njegovo primanje prilikom izračunavanja osnove za ovaj registar.
Pa čak i proporcionalno datom periodu, vrijednost resursa će biti preračunata (ako se bazni period ne poklapa sa frekvencijom registra).
A vrijednost atributa je dostupna samo u stvarnoj tablici registra proračuna, nije u virtualnim tablicama.
*************************************************************************************************
Potvrdni okvir "Osnovno" u svojstvima dimenzije računskog registra
To znači da će se baza za ovu dimenziju dobiti u budućnosti i služi za dodatno indeksiranje vrijednosti za ovo polje.
*************************************************************************************************
Pregled perioda važenja odsustva po mesecima prilikom upisa matične evidencije,
ako je odmor naveden u dokumentu u jednom redu nekoliko mjeseci odjednom u jednom redu:
StartDateCurMonth = StartMonth(CurStringBasicAccruals.ActionPeriodStart); EndDateCurMonth = EndMonth(CurStringBasicAccruals.ActionPeriodStart); CurrentMonth = Datum; By DateBeginTecMonth<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;
*************************************************************************************************
Izgradnja gantograma:
Stavljamo element tipa "Gantt Chart" na obrazac, nazivamo ga DG, zatim kreiramo naredbu "Generiraj" i upisujemo sljedeće u modul obrasca:
&AtClient Procedura Generate(Command) GenerateAtServer(); EndProcedure &AtServer Procedure GenerateAtServer() DG.Clear(); DG.Update = False; Запрос = Новый Запрос("ВЫБРАТЬ |ОсновныеНачисленияФактическийПериодДействия.Сотрудник, |ОсновныеНачисленияФактическийПериодДействия.ВидРасчета, |ОсновныеНачисленияФактическийПериодДействия.ПериодДействияНачало КАК ПериодДействияНачало, |ОсновныеНачисленияФактическийПериодДействия.ПериодДействияКонец КАК ПериодДействияКонец |ИЗ |РегистрРасчета.ОсновныеНачисления.ФактическийПериодДействия КАК ОсновныеНачисленияФактическийПериодДействия |ГДЕ |ОсновныеНачисленияФактическийПериодДействия.ПериодДействия МЕЖДУ &ДатаНачала И &ДатаОкончания "); Query.SetParameter("StartDate", Period.StartDate); Query.SetParameter("EndDate", Period.EndDate); Selection = Query.Execute().Select(); Dok Sample.Next() Tačka petlje = DG.SetPoint(Selection.Employee); Serija = DG.SetSeries(Selection.Calculation Type); Vrijednost = DG.GetValue(Point, Series); Interval = Value.Add(); Interval.Start = Sample.PeriodActionStart; Interval.End = Sample.PeriodActionEnd; EndCycle; DG.Update = istina; EndProcedure
Zapravo, ovdje nam je važan samo kod u petlji, ostale stvari su pomoćne, upravo sam donio cijelu implementaciju ovog podzadatka.
U zahtjevu nam je bitno da postoji zaposlenik, vrsta obračuna, datum početka i datum završetka perioda.
Kôd je zapravo vrlo jednostavan, lako se pamti, nemojte se uznemiravati ako vam se čini glomaznim
*************************************************************************************************
Obrada "storno" zapisa u zadacima poravnanja:
U postupku obrade knjiženja (objektni modul) formiramo sva kretanja, a onda ako postoje evidencije u drugim periodima dobijamo ih ovako
(sistem ih automatski generiše - pomaže nam):
RecordsAdditions = Movements.BasicAccruals.GetAdditions(); // Ne morate snimati pokrete da biste dobili dopunu
Za svaku TekLine iz RecordAddition petlje
Zapis = Kretanja.BasicAccruals.Add();
FillPropertyValues(Record, CurrentString);
Record.RegistrationPeriod = CurrentString.RegistrationPeriodStorno;
Record.ActionPeriodStart = CurrentString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = CurrentString.ActionPeriodEndReverse;
EndCycle
I prilikom izračunavanja zapisa ubacite čekove:
Ako CurrentMovement.Reversal Then
CurrentMovement.Amount = - CurrentMovement.Amount;
EndIf;
*************************************************************************************************
Kako odrediti šta uključiti u glavne obračunske obaveze, a šta u dodatne u zadacima obračuna.
Ali to nije uvijek 100% jasno, ima i složenijih slučajeva, iako ih ima poprilično.
(na primjer, bonus koji ovisi o broju radnih dana u mjesecu je OH).
Osnovna razgraničenja:
Ako po vrsti obračuna postoji zavisnost od rasporeda (misli se na registar informacija sa kalendarskim datumima), onda se to odnosi na glavne obračune.
OH primjer:
- Plata
- Nešto što se računa od broja radnih dana (a za to je potrebno koristiti raspored): ili u periodu važenja (kao plata) ili u baznom periodu
Dodatne naknade:
Ono što se uzima u obzir ili od naplaćenog iznosa, ili RADNO (a ne norma!) Vrijeme, ili uopće ne ovisi - ovo je dodatno. optužbe.
Odnosno: obračuni za čije se obračunavanje koristi vremenska norma (možda i činjenica) su OH, a za koje su potrebni stvarni podaci ili ništa - to je DN.
Ili drugim riječima:
Ako RT koristi vremensku normu, onda se period važenja mora uključiti za RT.
*************************************************************************************************
Dodajte opciju u obliku liste referentne knjige "Nomenklatura" mogućnost otvaranja ugrađenog odjeljka pomoći "Rad sa referentnim knjigama".
Pokrenite sljedeću naredbu na obrascu:
&AtClient
Pomoć za proceduru (komanda)
OpenHelp("v8help://1cv8/EnterprWorkingWithCatalogs");
EndProcedure
Linija preseka je definisana na sledeći način:
Idite na referentne informacije konfiguracijskog objekta (u konfiguratoru), napišite riječ, odaberite je, idite na izbornik Elementi / Link i odaberite željeni odjeljak 1C pomoći, nakon čega se veza automatski ubacuje. Izgleda komplikovano, ali u praksi je lako.
*************************************************************************************************
Implementacija interakcije između oblika, na primjer, odabir:
1. Iz trenutnog obrasca otvorite traženi metodom "OpenForm()", kao drugi parametar prosljeđujemo strukturu sa parametrima (ako je potrebno). Kao treći parametar, možemo prenijeti vezu na ovaj obrazac - ThisForm.
2. U otvorenom obrascu u rukovaocu "OnCreateOnServer()" možemo uhvatiti parametre proslijeđene u koraku 1 kroz "Parameters.[ParameterName]". Obrazac koji je inicijalizirao otvaranje ovog obrasca biće dostupan preko identifikatora "Vlasnik" (ako je, naravno, navedeno u stavu 1).
I što je najvažnije, bit će dostupne funkcije izvoza obrasca vlasnika. To jest, možemo pozvati funkciju izvoza originalnog obrasca i prenijeti nešto tamo kao parametar za obradu odabira. I ova funkcija će već ispuniti ono što vam je potrebno u originalnom obrascu. Samo jedno upozorenje - ne možete prenijeti tablicu vrijednosti između klijentskih procedura, ali možemo je staviti u privremenu memoriju i prenijeti samo adresu BX-a, a zatim je izdvojiti iz BX-a.
*************************************************************************************************
Životni ciklus parametara forme
Svi parametri proslijeđeni obrascu u trenutku njegovog otvaranja vidljivi su samo u proceduri OnCreateOnServer.
Nakon kreiranja, svi parametri se uništavaju i više nisu dostupni u obrascu.
Izuzetak su parametri koji su deklarisani u uređivaču obrasca sa atributom "Ključni parametar".
Oni definišu jedinstvenost forme.
Takav parametar će postojati sve dok postoji sama forma.
*************************************************************************************************
Korištenje interfejsa Taxi
Tokom razvoja, možete podesiti uobičajeni upravljani interfejs 8.2 u svojstvima konfiguracije - na ovaj način je sve primetno kompaktnije i poznatije.
Ovo je posebno tačno ako iznajmljujete na daljinu - rezolucija ekrana je veoma mala, nemoguće je bilo šta uraditi sa interfejsom "taksi".
Samo ne zaboravite kada je sve gotovo, ponovo stavite "Taxi"!U suprotnom, ispitivač će ukloniti bodove!
*************************************************************************************************
PS: E Postoje zasebni tipični podzadaci koji se koriste u svim zadacima i upravo njih morate znati riješiti (na primjer, otpisivanje po serijama, korištenje PVC-a (pa, ovo je stvarno rijetko) i druge). I u svim zadacima se jednostavno ponavljaju (negdje su neki podzadaci, negdje drugi, samo u različitim kombinacijama). Štoviše, kolekcija je odavno obećana da će objaviti novu (ako još nije objavljena), u kojoj bi trebalo biti mnogo više problema, odnosno, nema smisla pamtiti rješenja pojedinačnih problema, ima smisla da naučite kako riješiti pojedinačne tipične podzadatke, tada ćete riješiti svaki problem.
PSS: Kolege, ako još neko ima neku korisnu informaciju o pripremama za ispit i polaganju neka piše u komentarima, dopunićemo članak.
Odlučio sam da doprinesem i opišem one karakteristike jezika koje nisu razmatrane u gornjim člancima. Članak je namijenjen programerima početnicima.
1. Konstrukcija "OD".
Da biste dobili podatke iz baze podataka, nije potrebno koristiti konstrukciju "FROM".
Primjer: Moramo odabrati sve podatke o bankama iz imenika banaka.
Zahtjev:
ODABERITE Imenik.Banke.*
Bira sva polja iz imenika Banke. I sličan je upitu:
SELECT Banks.* IZ Imenika Banke AS Banke
2. Naručite podatke po referentnom polju
Kada trebamo poredati podatke upita po primitivnim tipovima: "String", "Broj", "Datum" itd., onda se sve rješava upotrebom "ORDER BY" konstrukcije, ako treba podatke poredati po referentnom polju? Referentno polje je veza, jedinstveni identifikator, tj. Grubo govoreći, određeni proizvoljni skup znakova i uobičajeni poredak možda neće dati očekivani rezultat. Za naručivanje referentnih polja koristi se konstrukcija "AUTOORDER". Da biste to učinili, prvo morate poredati podatke direktno prema referentnom tipu koristeći konstrukciju "ORDER BY", a zatim konstrukciju "AUTOORDER".
U ovom slučaju, za dokumente, redosled će se odvijati po redosledu "Datum-> Broj", za imenike - po "Glavnom prikazu". Ako se poredak ne zasniva na referentnim poljima, onda se ne preporučuje upotreba konstrukcije "AUTOORDER".
U nekim slučajevima, "AUTOORDER" konstrukcija može usporiti proces uzorkovanja. Slično, možete prepisati bez automatskog sređivanja dokumenata:
3. Dobivanje tekstualnog prikaza referentnog tipa. "PREZENTACIJA" konstrukcija.
Kada trebate prikazati polje tipa reference za prikaz, na primjer, polje "Banka", koje je veza na element direktorija "Banke", morate razumjeti da kada se ovo polje prikaže, podupit za Direktorij "Banke" će se automatski izvršiti kako bi se dobila pretraga imenika. Ovo će usporiti izlaz podataka. Da bi se to izbjeglo potrebno je u zahtjevu koristiti konstrukciju "REPRESENTATION" kako bi se odmah dobila reprezentacija objekta i već ga prikazala za pregled.
U sistemu sastavljanja podataka ovaj mehanizam se koristi podrazumevano, ali kada generišete rasporede u ćelijama, trebalo bi da navedete reprezentaciju referentnog polja i, na primer, stavite samu vezu u transkript.
4. Uslov za uzorkovanje podataka prema šablonu.
Na primjer, potrebno je nabaviti mobilne telefone zaposlenih na obrascu (8 -123-456-78-912). Da biste to uradili, potrebno je da u zahtevu stavite sledeći uslov:
SELECT Employee.Name, Employee.Phone AS Phone IZ Imenika.Employees AS Employees GDJE Telefon LIKE "_-___-___-__-__"
Znak "_" je servis i zamjenjuje bilo koji znak.
5. Istovremena upotreba zbroja i grupiranja.
Zbirne vrijednosti se često koriste zajedno s grupiranjem, u kom slučaju se agregatne funkcije u zbrojima mogu izostaviti.
SELECT Services.Organization AS Organizacija, Usluge.Nomenklatura AS Nomenklatura, SUM(Usluge.Iznos dokumenta) AS Document Sum FROM Document.Services AS Usluge GRUPA PREMA uslugama.Organizacija, Services.Nomenklatura REZULTATI PO OPŠTIM, Organizacija, Nomenklatura
U ovom slučaju, zahtjev će vratiti gotovo isto kao i ovaj zahtjev:
ODABERITE Usluge Organizacija AS Organizacija, Usluge Nomenklatura AS Nomenklatura, Usluge Iznos dokumenta AS Iznos dokumenta IZ dokumenta.
Samo prvi upit će sažimati zapise sa istom nomenklaturom.
6. Dereferenciranje polja.
Referentna polja kroz tačku naziva se operacija dereferenciranja referentnog polja. Na primjer Plaćanje.Organizacija.Upravna jedinica. U ovom slučaju, u referentnom polju "Organizacija" dokumenta "Plaćanje" se odnosi na drugu tabelu "Organizacije", u kojoj će biti primljena vrijednost atributa "Administrativna jedinica". Važno je shvatiti da kada se pristupi poljima kroz tačku, platforma implicitno kreira potupit i pridružuje ove tabele.
Zahtjev:
Može se predstaviti kao:
SELECT Payment.Link, Payment.Organization, Payment.Organization, Organizations. Administrativna jedinica IZ dokumenta.Plaćanje kao plaćanje LEFT JOIN Directory.Organizacije AS Organizacije Software Payment.Organization = Organizacije.Link
Kada dereferencira referentna polja kompozitnog tipa, okvir pokušava kreirati implicitne spojeve sa svim tablicama koje su dio tipa polja. U tom slučaju upit neće biti optimalan.Ako se jasno zna koji je tip polja, potrebno je konstrukcijom ograničiti takva polja po tipu EXPRESS().
Na primjer, postoji registar akumulacije "Neraspoređena plaćanja", gdje nekoliko dokumenata može djelovati kao registrator. U ovom slučaju, pogrešno je dobiti vrijednosti podataka registratora na ovaj način:
ODABERITE nedodijeljena plaćanja.Registar.Datum, ..... IZ registra akumulacije.Nedodijeljena plaćanja KAO nedodijeljena plaćanja
trebali biste ograničiti tip kompozitnog zapisivača polja:
SELECT EXPRESS(Neraspoređena plaćanja. Registrator KAO dokument. Plaćanje). Datum, ..... IZ registra akumulacije. Nedodijeljena plaćanja KAO nedodijeljena plaćanja
7. Izgradnja "GDJE"
Sa levim spajanjem dve tabele, kada nametnete uslov "WHERE" na desnu tabelu, dobićemo rezultat sličan rezultatu sa unutrašnjim spajanjem tabela.
Primjer. Potrebno je izabrati sve klijente iz Imenika klijenata i za one klijente koji imaju dokument o plaćanju sa atributom vrijednosti "Organizacija" = &Organizacija, prikazati dokument "Plaćanje", za one koji nemaju, ne prikazati ga.
Rezultat upita će vratiti zapise samo za one kupce koji su imali plaćanje po organizaciji u parametru, a filtrirat će ostale kupce. Dakle, prvo morate dobiti sve uplate za "tavu i takvu" organizaciju u privremenu tabelu, a zatim se povezati sa direktorijumom "Klijenti" levim spojem.
ODABERITE Plaćanje.Referenca KAO Plaćanje, Plaćanje.Akcionar KAO Klijent STAVITE uplate IZ dokumenta.Plaćanje KAO plaćanje GDJE Plaćanje.Odjel = &Odjel; ////////////////////////////////////////////////// / /////////////////////////////// SELECT Clients.Reference KAO Klijent, ISNULL(topayments.Payment, "") KAO Plaćanje OD Direktorij .Clients AS Klijenti LEFT JOIN
Ovo stanje možete zaobići na drugi način. potrebno je nametnuti uslov "GDJE" direktno u odnosu dvije tabele. primjer:
SELECT Clients.Reference, Payment.Reference FROM Directory.US_Subscribers AS ST_Subscribers LEFT JOIN Document.Payment AS Payment SOFTWARE (Clients.Reference = Payment.Client AND Payment.Client.Name LIKE "Sugar Bag") GRUPA PO Klijentima.Reference. Veza
8. Spajanja sa ugniježđenim i virtualnim tablicama
Podupitičesto je potrebno odabrati podatke prema nekom uslovu. Ako ih zatim koristite u kombinaciji s drugim tabelama, to može kritično usporiti izvršenje upita.
Na primjer, za neke klijente moramo dobiti iznos salda za tekući datum.
SELECT UnallocatedPayBalances.Customer, UnallocatedPaymentsRemains.AmountBalance FROM (SELECT Clients.Reference AS Reference FROM Directory.Clients AS Clients WHERE Clients.Reference B(&Clients)) AS NestedQuery
Prilikom izvršavanja takvog upita, DBMS optimizator će vjerovatno napraviti greške pri odabiru plana, što će dovesti do neoptimalnog izvršenja upita. Prilikom spajanja dve tabele, DBMS optimizator bira algoritam za spajanje tabela na osnovu broja zapisa u obe tabele. U slučaju ugniježđenog upita, izuzetno je teško odrediti broj zapisa koje će ugniježđeni upit vratiti. Stoga, umjesto ugniježđenih upita, uvijek biste trebali koristiti privremene tabele. Pa hajde da ponovo napišemo upit.
SELECT Clients.Link AS Link PUT Clients FROM Directory.Clients AS Clients GDJE
Clients.Link B (&Clients) ; ////////////////////////////////////////////////// / /////////////////////// SELECT tClients.Reference, UnallocatedPaymentsBalances.SumBalance, FROM tClients AS tClients LEFT JOIN Registar akumulacije.UnallocatedPayments.Balances (, Client IN (SELECT tClients.Reference FROM tClients)) AS UnallocatedPaymentsBalances NA tClients.Reference = UnallocatedPaymentsBalances.Clients
U ovom slučaju, optimizator će moći odrediti koliko zapisa koristi privremena tablica tClients i moći će odabrati optimalni algoritam za spajanje tablice.
Virtual Tables , omogućavaju vam da dobijete gotovo gotove podatke za većinu aplikativnih zadataka (Slice of First, Slice of Last, Residuals, Promet, Reziduals i Turnovers) Ključna riječ ovdje je virtualna. Ove tabele nisu fizičke, već ih sistem sastavlja u hodu, tj. prilikom prijema podataka iz virtuelnih tabela, sistem prikuplja podatke iz konačnih tabela registara, sastavlja, grupiše i izdaje korisniku.
One. kada se pridružite sa virtuelnom tabelom, pridružujete se podupitom. U ovom slučaju, optimizator DBMS-a može također izabrati neoptimalan plan pridruživanja. Ako se upit ne formira dovoljno brzo i upit koristi spojeve u virtuelnim tabelama, onda je preporučljivo prebaciti pristup virtuelnim tabelama na privremenu tabelu, a zatim napraviti spoj između dve privremene tabele. Prepišimo prethodni upit.
SELECT Clients.Link AS Link PUT Clients FROM Directory.Clients AS Clients INDEKS PO LINKU GDJE
Clients.Link B (&Clients) ; ////////////////////////////////////////////////// / /////////////////////////////// SELECT UnallocatedPayments.AmountBalance, UnallocatedPayments.Customer AS Kupac STAVITI saldo IZ Registra akumulacije.UnallocatedPayments. Stanja(, Client IN (ODABIR tClients.Referenca IZ tClients)) AS UnallocatedPaymentsBalance; ////////////////////////////////////////////////// / ////////////////////////////// SELECT tClients.Reference, zatim Remains.SumRemainder AS SumRemainder FROM tClients AS tClients tClients.Reference = tRemainders .Klijent
9.Provjera rezultata upita.
Rezultat izvršenja upita može biti prazan; da biste provjerili ima li praznih vrijednosti, koristite konstrukciju:
RequestRes = Request.Execute(); Ako reQuery.Empty() Onda Return; EndIf;
Metoda Prazan() treba koristiti prije metoda Odaberi() ili istovar(), budući da je potrebno vrijeme za preuzimanje kolekcije.
Nikome nije otkriće da je vrlo nepoželjno koristiti upite u ciklusu. Ovo može kritično utjecati na vrijeme rada određene funkcije. Vrlo je poželjno primiti sve podatke u zahtjevu i tek onda obraditi podatke u petlji. Ali ponekad postoje slučajevi kada postane nemoguće izvući zahtjev iz petlje. U ovom slučaju, radi optimizacije, kreiranje upita možete premjestiti izvan petlje i zamijeniti potrebne parametre u petlji i izvršiti upit.
Zahtjev = Novi zahtjev; Query.Text = "SELECT | Clients.Link, | Clients.Date of Birth |FROM | Directory.Clients AS Clients |WHERE | Clients.Link = &Client"; Za svaki red FROM TableClients Loop Query.SetParameter("Klijent", Klijent); QueryResult = Query.Execute().Select(); EndCycle;
Ovo će spasiti sistem od raščlanjivanja zahtjeva u petlji.
11. Konstrukcija "HAVING".
Konstrukcija koja je prilično rijetka u upitima. Omogućava vam da nametnete uvjete na vrijednosti agregatnih funkcija (SUM, MINIMUM, PROSJEČAN, itd.). Na primjer, trebate odabrati samo one kupce čiji je iznos plaćanja u septembru bio veći od 13.000 rubalja. Ako koristite uslov "GDJE", prvo ćete morati kreirati privremenu tabelu ili ugniježđeni upit, grupirati zapise tamo prema iznosu plaćanja, a zatim nametnuti uvjet. Konstrukcija "IMATI" će pomoći da se ovo izbjegne.
ODABIR Plaćanje.Kupac, SUM(Uplata.Iznos) KAO IZNOS IZ dokumenta.Plaćanje KAO Plaćanje GDJE MJESEC(Datum.Plaćanja) = 9 GRUPA PO Uplati.Kupac IMA IZNOS (Iznos.Uplate) > 13000
U konstruktoru, sve što treba da uradite je da odete na karticu "Uslovi", dodate novi uslov i potvrdite izbor u polju za potvrdu "Prilagođeno". Onda samo napiši Iznos (Iznos plaćanja) > 13000
12. Null vrijednost
Ovdje neću opisivati principe trovrijedne logike u bazi podataka, postoji mnogo članaka na ovu temu. Samo uvid u to kako NULL može uticati na rezultat upita. NULL vrijednost zapravo nije vrijednost, a činjenica da vrijednost nije definirana je nepoznata. Stoga, svaka operacija na NULL vraća NULL, bilo da se radi o sabiranju, oduzimanju, dijeljenju ili poređenju. Vrijednost NULL se ne može uporediti sa vrijednošću NULL jer ne znamo s čime da uporedimo. One. oba ova poređenja: NULL = NULL, NULL<>NULL nije Tačno ili Netačno, to je nepoznato.
Pogledajmo primjer.
Za one kupce koji nemaju plaćanja, potrebno je da prikažemo polje "Atribut" sa vrijednošću "Nema plaćanja". A znamo sigurno da imamo takve klijente. A da bismo odrazili suštinu onoga što sam gore napisao, uradimo to na ovaj način.
SELECT "Bez plaćanja" AS Atribut, NULL KAO Dokument PUT na plaćanja; ////////////////////////////////////////////////// / /////////////////////////////// SELECT Clients.Link AS Client, Payment.Link AS Payment PUT tClientPayment IZ Directory.Clients AS Clients LEFT JOIN Document.Payment AS Payment Software Clients.Link = Plaćanje.Shareholder; ////////////////////////////////////////////////// / /////////////////////////////// ODABIR tClientPayment.Customer IZ tClientPay KAO tClientPayment INTERNO PRIDRUŽENJE topayments KAO topayments PO tClientPayment.Payment = dokument
Obratite pažnju na drugu privremenu tabelu tCustomerPayment. Sa lijevim spojem biram sve klijente i sva plaćanja za te klijente. Za one kupce koji nemaju plaćanja, polje "Plaćanje" će biti NULL . Po logici, u prvoj privremenoj tabeli "topayments" označio sam 2 polja, jedno od njih je NULL, drugo je red "Nema plaćanja". U trećoj tabeli spajam tabele "tClientPayment" i "tPayment" pomoću polja "Payment" i "Document" sa unutrašnjim spajanjem. Znamo da je u prvoj tabeli polje "Dokument" NULL, au drugoj tabeli su NULL i oni koji nemaju uplate u polju "Plaćanje". Šta će nam vratiti takvu vezu? I neće vratiti ništa. Zato što poređenje NULL = NULL ne daje vrijednost Tačno.
Da bi nam upit vratio očekivani rezultat, prepisujemo ga:
ODABERITE "Bez plaćanja" KAO znak, VRIJEDNOST (Dokument. Plaćanje. Prazna referenca) KAO dokument PUT na plaćanja; ////////////////////////////////////////////////// / /////////////////////////////// SELECT Clients.Reference AS Client, ISNULL(Plaćanje.Referenca, VALUE(Dokument.Plaćanje .EmptyReference )) KAKO STAVITI tClientPayment IZ Imenika.Klijenti KAO Klijenti LEFT JOIN Document.Plaćanje KAO plaćanje NA Clients.Reference = Payment.Shareholder; ////////////////////////////////////////////////// / /////////////////////////////// ODABIR tClientPayment.Customer IZ tClientPay KAO tClientPayment INTERNO PRIDRUŽENJE topayments KAO topayments PO tClientPayment.Payment = dokument
Sada, u drugoj privremenoj tabeli, naznačili smo da ako je polje "Plaćanje" NULL, onda je ovo polje = prazna referenca na dokument plaćanja. U prvoj tabeli, NULL smo također zamijenili nultom referencom. Sada su polja koja nisu NULL uključena u vezu i upit će vratiti očekivani rezultat.
Svi zahtjevi sadržani u članku odražavaju situacije koje bih želio razmotriti i ništa više. O niti mogu biti ludi ili neoptimalni, glavno je da odražavaju suštinu primjera.
13. Nedokumentovana karakteristika dizajna "IZBOR KADA ... ONDA .... KRAJ".
U slučaju kada je u zahtjevu potrebno opisati konstrukciju "Uvjeti", tada koristimo standardnu sintaksu:
ODABERITE IZBOR KADA Users.Name = "Vasya Pupkin" ONDA "Naš omiljeni zaposlenik" OSTALO "Mi ovo ne znamo" KRAJ KAO Polje 1 IZ Direktorija.Korisnici KAO Korisnici
Ali šta ako, na primjer, u upitu trebamo dobiti naziv mjeseca? Pisanje ogromne konstrukcije u upitu je ružno i dugotrajno, tako da nam ovaj oblik zapisa iznad može pomoći:
ODABIR MESEC(SAD_Obračun potrošnje_Raspored prometa.Obračunski period) KADA 1 ONDA "januar" KADA 2 ONDA "februar" KADA 3 ONDA "mart" KADA 4 ONDA "april" KADA 5 ONDA "maj" KADA "J" KADA "Ju" jul" KADA 8 PA "Avgust" KADA 9 ONDA "septembar" KADA 10 PA "oktobar" KADA 11 PA "novembar" KADA 12 ONDA "decembar" ZAVRŠAVA SE KAO MESEC
Sada dizajn ne izgleda tako glomazan i lako se percipira.
14. Paketno izvršavanje upita.
Kako ne biste proizvodili zahtjeve, možete kreirati jedan veliki zahtjev, razbiti ga u pakete i već raditi s njim.
Na primjer, moram iz direktorija "Korisnici" dobiti polja: "Datum rođenja" i dostupne uloge za svakog korisnika. da ga istovarite u različite tabelarne dijelove na obrascu. Naravno, ovo možete učiniti u jednom upitu, a zatim morate iterirati zapise ili sažimati, ili možete učiniti ovo:
SELECT Users.Link AS Ime, Korisnici.Datum rođenja, Korisnici.Uloga ENTER Users FROM Directory.Users AS Korisnici; ////////////////////////////////////////////////// / /////////////////////////////// SELECT tuUsers.Name, tuUsers.Datum rođenja OD korisnika KAO korisnika GRUPA PO korisnika. Ime, tuKorisnici Datum rođenja; ////////////////////////////////////////////////// / /////////////////////////////// SELECT wUsers.Name, wUsers.Role FROM wUsers KAO wUsers GROUP BY wUsers.Name, wKorisnici Datum rođenja
tPackage = Request.ExecutePackage();
TP_Datum rođenja = tPaket.Unload();
TP_Roles = tPackage.Unload();
Kao što vidimo, upit se može izvršiti u paketu i raditi s rezultatom kao nizom. U nekim slučajevima, vrlo zgodno.
15. Uslovi u paketnom zahtjevu
Na primjer, imamo paketni zahtjev, gdje prvo dobijamo polja: "Ime, Datum rođenja, Šifra" iz direktorija "Korisnici" i želimo da dobijemo zapise sa uslovom o ovim poljima iz direktorija "Pojedinci".
SELECT Users.Individual.Name AS Ime, Users.Individual.Date of Birth AS Datum rođenja, Users.Individual.Code AS Kôd STAVITE u Users FROM Directory.Users AS Korisnici; ////////////////////////////////////////////////// / ////////////////////////////// SELECT Individuals.Link AS Individual FROM Directory.Individuals AS Individuals
Možete primijeniti sljedeće uslove:
WHERE Individuals.Code At (ODABERITE TueUsers.Code OD TuUsers) I Individuals.Name At (ODABERITE TueUsers.Code FROM TuUUsers) I Individuals.Date of Birth at (ODABRAJTE UtoUsers.Date of Birth FROM TuUsers)
A moguće je i ovako:
WHERE (Pojedinci.Kôd, Pojedinci.Ime, Pojedinci.Datum rođenja) AT (ODABIR UTOKorisnici.Šifra, UtoKorisnici.Ime, UtoKorisnici.Datum rođenja OD UtoKorisnika)
I obavezno se pridržavajte pravila.
16. Pozovite Query Builder za "Stanje" u paketnom upitu
Kada trebate nametnuti uvjet, kao u primjeru iznad, možete zaboraviti kako se ovo ili ono polje poziva u virtualnoj tablici.
Na primjer, potrebno je nametnuti uvjet u polje "Datum rođenja", au virtuelnoj tabeli ovo polje se zove "Datum rođenja dužnika", a ako ste zaboravili ime, morat ćete izaći iz uređivanja stanje bez spremanja i pogledajte naziv polja. Da biste to izbjegli, možete koristiti sljedeći trik.
Potrebno je staviti zagrade iza konstrukcije "B" i ostaviti prazan prostor (razmak) između zagrada, odabrati ovo mjesto i pozvati konstruktor upita. Konstruktor će imati pristup svim tabelama skupnih upita. Prijem radi kako na virtualnim tablicama registara tako i na kartici "Uvjeti". U potonjem slučaju potrebno je označiti polje za potvrdu "A (arbitrary condition)" i ući u mod za uređivanje "F4".
Upiti se često izmišljaju u pokretu i služe samo za prikaz "trikova" o kojima sam razmišljao.
Hteo sam da razmotrim upotrebu indeksa u upitima, ali to je bolno opsežna tema. Staviću to u poseban članak, ili kasnije dodati ovde.
upd1. Paragrafi 11,12
upd2. Stavke 13,14,15,16
rabljene knjige:
Jezik upita 1C:Enterprise 8 - E.Yu. Hrustalev
Profesionalni razvoj u sistemu 1C:Enterprise 8.
Prilikom organizovanja uzoraka u realnim problemima, u ogromnoj većini slučajeva, selekcija podataka je organizovana u skladu sa određenim kriterijumima.
U slučaju kada se odabir vrši iz pravog stola, nema poteškoća. Podaci se obrađuju apsolutno trivijalno:
U slučaju kada je izvor u upitu virtuelna tabela, situacija postaje nešto komplikovanija.
Jezik upita vam omogućava da nametnete uslov za izbor iz virtuelnih tabela na dva načina: u klauzuli WHERE i korišćenjem parametara virtuelne tabele. Oba načina će dovesti do istog rezultata (osim u nekim specifičnim slučajevima), ali su daleko od ekvivalenta.
Već znamo da se virtuelne tabele nazivaju virtuelne jer se zapravo ne nalaze u bazi podataka. Oni se formiraju tek u trenutku kada im se uputi zahtjev. Uprkos tome, zgodno je za nas (to jest, one koji sastavljaju upit) da virtuelne tabele smatramo upravo stvarnim. Šta će se dogoditi u sistemu 1C Enterprise 8 kada se upit koji smo sastavili i dalje odnosi na virtuelnu tabelu?
U prvom koraku, sistem će izgraditi virtuelnu tabelu. U drugom koraku, iz rezultirajuće tabele će biti odabrani zapisi koji zadovoljavaju uslov naveden u klauzuli WHERE:
Jasno se vidi da u konačnu selekciju neće upasti svi zapisi iz virtuelne tabele (a samim tim i iz baze), već samo oni koji zadovoljavaju zadati uslov. A ostali zapisi će jednostavno biti isključeni iz rezultata.
Tako će sistem raditi ne samo beskorisno, već dvostruko beskorisno! Prvo, resursi će biti utrošeni na pravljenje virtuelne tabele zasnovane na dodatnim podacima (na slici su označeni kao „područja podataka A i B“), a zatim će se više raditi na filtriranju ovih podataka iz konačnog rezultata.
Da li je moguće odmah, u fazi izgradnje virtuelne tabele, odbiti korišćenje nepotrebnih podataka? Ispostavilo se da možeš. Ovome služe postavke virtuelne tabele:
Parametrizovanjem virtuelne tabele, odmah ograničavamo količinu podataka koje će upit obraditi.
Koja je razlika između vrijednosti parametra virtualne tablice "Append Method"?
Kada je ComplementMethod postavljen na "pokreti", biće vraćeni samo oni periodi u kojima je bilo kretanja. Kada je postavljeno "Pokreti I ograničenja perioda", tada će se gore navedenim kretanjima dodati 2 zapisa: kretanja na početku i na kraju perioda navedenog u BT parametrima. Polje "Registar" će biti prazno za ova 2 zapisa.
Informacije preuzete sa stranice
Registri akumulacije u sistemu 1C:Enterprise podijeljeni su u dvije vrste: akumulacijski registri ostaci i registre akumulacije revolucije.
Tip registra se bira prilikom kreiranja u konfiguratoru
Kao što naziv implicira, neki su dizajnirani da primaju stanja za određeni datum, a drugi da primaju promet za odabrani period. Ovisno o vrsti registra akumulacije, platforma 1C:Enterprise generira različit skup virtualnih tablica. U ovom članku ćemo razmotriti rad sa virtuelnim tabelama akumulacionih registara. Da bismo to uradili, kreiraćemo registar za akumulaciju stanja - GoodsRemains i registar akumulacije prometa - Robni promet.
Pogledajmo sada koje virtuelne tabele platforma nudi za svaki od ovih registara.
Registar prometa
Radi jasnoće, otvorimo i vidimo koje su tabele dostupne za registar Robni promet. Ovo je tabela samog registra − Robni promet, koji fizički postoji u bazi podataka, i jedna virtuelna tabela - Promet robe
Sa standardnom tablicom je sve jasno. Pogledajmo pobliže virtuelnu stvarnost.
Promet na virtuelnom stolu
Ova tabela vam omogućava da dobijete promet resursa u kontekstu mjerenja. U našem slučaju imamo dvije dimenzije: Stock I Proizvod. I jedan resurs Količina
Neka naš registar ima sljedeće unose
Vratimo se na alat za pravljenje upita i počnimo jednostavnim odabirom iz tabele Promet robe sva polja
Shodno tome, zahtjev će izgledati ovako:
ODABERITE Robni prometPromet.Skladište,Promet robe.Proizvod,Promet robe.Promet Količina IZ registra Akumulacija.Promet robe.Promet(,) KAO Robni prometPromet
Rezultat upita izgleda ovako:
Odnosno, dobili smo promet u okviru robe i skladišta za cijelo vrijeme. Pretpostavimo da nas ne zanimaju skladišta i da želimo ostvariti promet samo u kontekstu robe.
Da biste to učinili, isključite dimenziju iz upita Stock
ODABERITE Robni prometPromet.Proizvod,Promet robePromet.KoličinaPromet IZ registraAkumulacija.Promet robe.Promet(,) KAO Robni prometPromet
i kao rezultat ćemo imati samo dva reda
Ali u pravilu nije potrebno primati promete za cijelo vrijeme postojanja registra. U osnovi, potrebni su za određeni period: mjesec, kvartal, godina itd. Osim toga, obično vam je potreban odabir po dimenzijama (proizvod, skladište). To se postiže upotrebom parametri virtuelne tabele. Pogodno je popuniti parametre iz konstruktora. Po dugmetu Opcije virtuelne tabele otvara se dijaloški okvir u kojem možete registrirati sve što nam je potrebno:
Nakon toga, naš originalni upit će poprimiti sljedeći oblik
ODABIR Promet robe.Skladište, Robni prometPromet.Proizvod, Robni prometPromet.KoličinaPromet IZ registra akumulacije.Promet robe.Promet(&početak perioda, &kraj perioda, skladište ASTurTurnovers)
Kao što vidite, razlika je u tome što se parametri pojavljuju u zagradama iza naziva virtuelne tabele, koji se moraju popuniti pre izvršavanja upita.
Za one koji tek počinju raditi s virtualnim tablicama, često je primamljivo postaviti odabir na uobičajen način umjesto da koriste parametre:
IZ registra akumulacije.Promet robe.Promet(,) AS Robni prometPromet GDJE Robni prometPromet.Skladište = &Skladište
Prilikom popunjavanja parametara, promašili smo Periodičnost. Otvorimo listu i izaberimo iz mnoštva mogućih opcija Mjesec. Sve ostale parametre ćemo ukloniti kako ne bismo bili zabuni.
Nakon toga, uočavamo da se u poljima tabele pojavilo polje Period.
Dodavanjem u odabrana polja dobijamo sljedeći tekst upita:
ODABERITE Robni prometPromet.Period,Promet robe.Promet.Skladište,Promet robe.Proizvod,Promet robe.Promet.KoličinaPromet IZ registra akumulacije.Promet robe.Promet (, mjesec,) KAO Promet robe
Izvršavamo zahtjev:
Tako, unutar odabranog vremenskog intervala, možemo razbiti promet na manje intervale u skladu sa odabranom frekvencijom.
Registar akumulacije bilansa
Baš kao i sa obrnutim registrom, hajde da vidimo u kreatoru upita koje su virtuelne tabele dostupne za registar akumulacije stanja
Kao što vidite, dostupne su tri virtuelne tabele za registar akumulacije stanja: Promet, Ostaje, Ostaci i obrti. Razmotrimo svaki od njih posebno.
Promet na virtuelnom stolu
Iako je tip registra Ostaje, još uvijek možemo dobiti promet od toga. Osim toga, ovdje imamo dva dodatna resursa: Dolazim I Potrošnja
Podsjećam da se prilikom upisa u registar stanja označava vrsta kretanja akumulacije (prihodi ili rashodi), dok se za registar prometa ne navodi vrsta kretanja. Dakle, ovdje imamo dodatni bonus u vidu mogućnosti da dobijemo ne samo promet za period u cjelini, već i prihode sa rashodima posebno. Ali naravno, ako u metapodacima postoji registar prometa sa sličnim skupom mjerenja, onda je bolje koristiti ga za dobivanje prometa. Općenito, rad s ovom virtualnom tablicom je sličan radu s virtualnom tablicom Promet Registar prometa o kojem je gore raspravljano.
Virtuelna salda tabela
Ova tabela se koristi za dobijanje preostalih resursa u smislu dimenzija. U parametrima tabele možemo odrediti datum za koji primamo stanja i postaviti filtere:
Razmotrimo mali primjer. Imamo sljedeće upise u registar:
Odaberemo sva raspoloživa polja i odredimo kraj juna kao datum za prijem stanja. Odabir nećemo utvrđivati mjerenjem. Tada će tekst zahtjeva izgledati ovako:
ODABERITE Ostaci robe.Skladište, Ostaci robe.Ostaci.Proizvod, Ostaci robe.Količinski saldo IZ registra akumulacije.ProizvodiOstaci.Ostaci(&RemainsDate,) KAO Ostaci robe Ostaci
I nakon što ga izvršimo, dobijamo sljedeći rezultat
Virtuelni sto
Ova tabela kombinuje dve prethodno razmatrane i omogućava vam da dobijete promet za odabrani vremenski period, kao i stanja na početku i na kraju perioda. Također možete postaviti odabir.
Upotreba ove tabele može biti opravdana kada je potrebno istovremeno u jednom izveštaju dobiti i promet i stanje na početku i na kraju perioda. U drugim slučajevima, njegovu upotrebu ne treba zloupotrebljavati.
Učitavanje...