Bilancet dhe qarkullimi i tavolinës virtuale 1c. Skeda e grupit të pyetjeve

Vendosa të jap kontributin tim dhe të përshkruaj ato veçori të gjuhës që nuk u diskutuan në artikujt e mësipërm. Artikulli u drejtohet zhvilluesve fillestarë.

1. Dizajni “IZ”.

Për të marrë të dhëna nga baza e të dhënave, nuk është aspak e nevojshme të përdoret ndërtimi "FROM".
Shembull: Ne duhet të zgjedhim të gjitha informacionet për bankat nga drejtoria e bankave.
Kërkesë:

SELECT Directory.Banks.*

Zgjedh të gjitha fushat nga drejtoria e Bankave. Dhe është e ngjashme me kërkesën:

SELECT Bankat.* FROM Directory.Banks AS Banks

2. Renditja e të dhënave sipas fushës së referencës

Kur duhet të organizojmë të dhënat e pyetjeve sipas llojeve primitive: "String", "Number", "Date", etj., atëherë gjithçka zgjidhet duke përdorur konstruktin "ORDER BY" nëse duhet të renditni të dhënat sipas një fushe referimi? Fusha e referencës është një lidhje, një identifikues unik, d.m.th. Përafërsisht, disa grupe arbitrare karakteresh dhe renditje të zakonshme mund të prodhojnë një rezultat që nuk pritet plotësisht. Për të porositur fushat e referencës, përdoret ndërtimi "AUTO ORDER". Për ta bërë këtë, së pari duhet të renditni të dhënat drejtpërdrejt sipas llojit të referencës duke përdorur konstruksionin "ORDER BY" dhe më pas konstruksionin "AUTO ORDER".

Në këtë rast, për dokumentet, renditja do të bëhet në rendin "Data->Numër", për librat e referencës në "Pamje kryesore". Nëse renditja nuk ndodh sipas fushave të referencës, atëherë përdorimi i konstruksionit "AUTO ORDER" nuk rekomandohet.

Në disa raste, konstrukti "AUTO ORDER" mund të ngadalësojë procesin e përzgjedhjes. Në mënyrë të ngjashme, ju mund të rishkruani pa porositur automatikisht dokumente:

3. Marrja e një paraqitjeje teksti të një lloji referimi. Dizajni "PREZANTIM".

Kur duhet të shfaqni një fushë të një lloji referimi, për shembull, fusha "Banka", e cila është një lidhje me një element të drejtorisë "Bankat", duhet të kuptoni se kur shfaqni këtë fushë, një nënpyetje në " Drejtoria e Bankave" do të ekzekutohet automatikisht për të marrë një pamje të drejtorisë. Kjo do të ngadalësojë prodhimin e të dhënave. Për të shmangur këtë, duhet të përdorni konstruksionin "PREZANTIM" në kërkesë në mënyrë që të merrni menjëherë një paraqitje të objektit dhe më pas ta shfaqni atë për shikim.

Në sistemin e përbërjes së të dhënave, ky mekanizëm përdoret si parazgjedhje, por kur krijoni paraqitje në qeliza, duhet të specifikoni paraqitjen e fushës së referencës dhe, për shembull, të vendosni vetë lidhjen në transkript.

4. Kushti për marrjen e të dhënave sipas një shablloni.

Për shembull, ju duhet të merrni telefona celularë të punonjësve të formularit (8 -123- 456-78-912). Për ta bërë këtë, duhet të vendosni kushtin e mëposhtëm në kërkesë:

SELECT Punonjës.Emri, Punonjës.Telefoni AS Telefon NGA Direktoria.Punonjësit AS Punonjës WHERE Phone LIKE "_-___-___-__-__"

Karakteri "_" është një karakter shërbimi dhe zëvendëson çdo karakter.

5. Përdorimi i njëkohshëm i totaleve dhe grupimeve.


Totalet shpesh përdoren në lidhje me grupimet; në këtë rast, funksionet e përgjithshme mund të mos specifikohen në total.

SELECT Ofrimi i Sherbimeve.Organizimi AS Organizimi, Ofrimi i Sherbimeve.Nomenklatura AS Nomenklature, SUM(Ofrimi i Sherbimeve.Shuma e Dokumentit) AS Shuma e Dokumentit FROM Document.Organizimi i Sherbimeve AS Ofrimi i Sherbimeve GROUP BY Ofrimi i Sherbimeve.Organizimi, Ofrimi of Sherbime.Nomenklature REZULTATET SIPAS PERGJITHSHME, Organizata, Nomen klatura

Në këtë rast, pyetja do të kthehet pothuajse njësoj si pyetja e mëposhtme:

SELECT Ofrimi i Sherbimeve.Organizata AS Organizimi, Ofrimi i Sherbimeve.Nomenklatura AS Nomenklatura, Ofrimi i Sherbimeve.Shuma e Dokumentit AS Shuma e Dokumentit FROM Document.Sigurimi i Sherbimeve AS Ofrimi i Sherbimeve REZULTATET SHUMIA (Shuma e Dokumentit) NGA PERGJITHSHME Nomenklatura

Vetëm pyetja e parë do të rrëzojë të dhënat me të njëjtën nomenklaturë.

6. Dereferencimi i fushave.

Referimi i fushave përmes një pike quhet operacioni i çreferencimit të fushës së referencës. Për shembull Pagesa.Organizata.Njsia Administrative. Në këtë rast, në fushën e referencës “Organizimi” i dokumentit “Pagesa” i referohet një tabelë tjetër “Organizatat”, në të cilën do të merret vlera e atributit “Njësi Administrative”. Është e rëndësishme të kuptohet se kur hyni në fusha përmes një pike, platforma krijon në mënyrë implicite një nënpyetje dhe bashkon këto tabela.

Kërkesë:

Mund të përfaqësohet si:

SELECT Payment.Link, Payment.Organization, Payment.Organization, Organizations. Njësia Administrative FROM Document.Payment AS Pagesa LEFT JOIN Directory.Organizations AS Software Organizations Payment.Organization = Organizations.Link

Kur çreferencohen fushat e referencës të një lloji të përbërë, korniza përpiqet të krijojë bashkime të nënkuptuara me të gjitha tabelat që janë pjesë e llojit të asaj fushe. Në këtë rast pyetja nuk do të jetë optimale.Nëse dihet qartë se për çfarë lloj fushe bëhet fjalë, është e nevojshme të kufizohen këto fusha sipas llojit me një konstrukt. EXPRESS().

Për shembull, ekziston një regjistër akumulimi "Pagesat e pashpërndara", ku disa dokumente mund të veprojnë si regjistrues. Në këtë rast, është e gabuar të merren vlerat e detajeve të regjistruesit në këtë mënyrë:

SELECT UnallocatedPayments.Register.Date, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

ju duhet të kufizoni llojin e fushës së përbërë në logger:

SELECT EXPRESS(Pagesat e pandara. Regjistrohu AS Document.Payment).Data, ..... FROM RegisterAccumulation.Payments Unallocated AS UnallocatedPayments

7. Ndërtimi "KU"

Me një bashkim majtas të dy tabelave, kur vendosni një kusht "KU" në tabelën e djathtë, do të marrim një rezultat të ngjashëm me rezultatin me një bashkim të brendshëm tabelash.

Shembull. Është e nevojshme të zgjidhen të gjithë Klientët nga Direktoria e Klientëve dhe për ata klientë që kanë një dokument pagese me vlerën e atributit "Organization" = &Organization, të shfaqet dokumenti "Pagesa", për ata që nuk kanë, mos e shfaqin atë.

Rezultati i pyetjes do të kthejë rekorde vetëm për ata klientë që kishin pagesë sipas organizatës në parametrin dhe do të filtrojë klientët e tjerë. Prandaj, së pari duhet të merrni të gjitha pagesat për organizatën "kështu dhe të tillë" në një tabelë të përkohshme dhe më pas ta lidhni atë me drejtorinë "Klientë" duke përdorur një bashkim majtas.

SELECT Payment.Link AS Payment, Payment.Aksioner AS Klient PLACE toPages FROM Document.Pagement AS Pagesë KU Pagesa.Dega = &Dega; ///////////////////////////////////////////////////////////////// ////////////////////////// ZGJIDH Klientët.Link AS Klient, ISNULL(tPayment.Payment, "") AS Pagesa NGA Drejtoria .Klientët AS Klientët LËNË LIDHJE TË LËNDËS pagesat AS SOFTWARE për pagesat Clients.Link = toppayments.Client

Ju mund ta shmangni këtë gjendje në një mënyrë tjetër. Është e nevojshme të vendoset një kusht "KU" drejtpërdrejt në marrëdhëniet midis dy tabelave. Shembull:

SELECT Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers LIDHJA LEFT Document.Payment AS Payment Software (Clients.Link = Payment.Client AND Payment.Client.Emri LIKE "Sugar Packet",ClientsLinkY) Klienti.Link. Lidhje

8. Bashkohet me Tabelat e Nested dhe Virtuale

Pyetjet e mbivendosura shpesh e nevojshme për të marrë të dhëna bazuar në disa kushte. Nëse më pas i përdorni ato në lidhje me tabela të tjera, kjo mund të ngadalësojë në mënyrë kritike ekzekutimin e pyetjes.

Për shembull, ne duhet të marrim shumën e bilancit që nga data aktuale për disa klientë.

SELECT UnallocatedPaymentsRemains.Customer, UnallocatedPaymentsRemains.AmountRemaining FROM (SELECT Clients.Link AS Lidhje FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Clients)) AS NestedQueryIN LEFTALOCATLocationsPastimi. yments BY Nested Request.Link = PaymentsBalances të pashpërndara. Klienti

Gjatë ekzekutimit të një pyetjeje të tillë, optimizuesi i DBMS mund të bëjë gabime kur zgjedh një plan, gjë që do të çojë në ekzekutimin jo optimal të pyetjes. Kur bashkoni dy tabela, optimizuesi DBMS zgjedh një algoritëm të bashkimit të tabelave bazuar në numrin e regjistrimeve në të dyja tabelat. Nëse ka një pyetje të mbivendosur, është jashtëzakonisht e vështirë të përcaktohet numri i rekordeve që do të kthejë pyetja e mbivendosur. Prandaj, duhet të përdorni gjithmonë tabela të përkohshme në vend të pyetjeve të mbivendosura. Pra, le ta rishkruajmë kërkesën.

ZGJIDH Klientët.Lidhja AS VENDI Lidhje tKlientët NGA Drejtoria.Klientët AS Klientë WHERE
Klientët.Lidhja B (&Klientët) ; ///////////////////////////////////////////////////////////////// ////////////////////////// SELECT tClients.Link, UnallocatedPaymentsRemains.Amount Remaining, FROM tClients AS tKlientët LËNË SHQIPTAR RegjistrohuAkumulimet.Pagesat e paalokuara,Balancat e klientëve IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

Në këtë rast, optimizuesi do të jetë në gjendje të përcaktojë se sa rekorde përdor tabela e përkohshme tClients dhe do të jetë në gjendje të zgjedhë algoritmin optimal për bashkimin e tabelave.

Tabelat virtuale , ju lejon të merrni të dhëna praktikisht të gatshme për shumicën e detyrave të aplikuara. Këto tabela nuk janë fizike, por janë të përpiluara nga sistemi në fluturim, d.m.th. Kur merr të dhëna nga tabelat virtuale, sistemi mbledh të dhëna nga tabelat e regjistrit përfundimtar, mbledh, grupon dhe ia lëshon përdoruesit.

Ato. Kur lidheni me një tabelë virtuale, bëhet një lidhje me një nënpyetje. Në këtë rast, optimizuesi DBMS mund të zgjedhë gjithashtu një plan lidhjeje jo optimale. Nëse pyetja nuk gjenerohet mjaft shpejt dhe pyetja përdor bashkime në tabela virtuale, atëherë rekomandohet të zhvendoset qasja në tabelat virtuale në një tabelë të përkohshme dhe më pas të bëhet një bashkim midis dy tabelave të përkohshme. Le të rishkruajmë kërkesën e mëparshme.

ZGJIDHNI Klientët.Lidhni AS VENDIN e Lidhjes tKlientët NGA Drejtoria.Klientët AS Klientë INDEKSI SIPAS Lidhjes WHERE
Klientët.Lidhja B (&Klientët) ; ///////////////////////////////////////////////////////////////// /////////////////////////// ZGJIDHni pagesat e paalokuara.AmountBalance, UnallocatedPayments.Client AS Klient PLACE balancat FROM RegisterAcumulations.Payments Unallocated.Balances(, Klienti B ( ZGJIDHni tClients.Lidhja NGA tClients)) AS balancat e pagesave të pashpërndara; ///////////////////////////////////////////////////////////////// ////////////////////////// ZGJEDHNI tClients.Link, teRemainders.Sasia e mbetur AS Shuma e mbetur NGA tKlientët AS tKlientët LEFT JOIN për të mbeturinat AS mbetjet BY tnkC. = t Mbetjet.Klienti

9.Kontrollimi i rezultatit të kërkesës.

Rezultati i pyetjes mund të jetë bosh; për të kontrolluar vlerat boshe, përdorni konstruktin e mëposhtëm:

ResRequest = Kërkesë.Execute(); Nëse resQuery.Empty() Pastaj Kthehu; fundNëse;

Metoda Bosh () duhet të përdoret para metodave Zgjidhni () ose Shkarko (), pasi marrja e koleksionit kërkon kohë.

Nuk është një zbulim për askënd që është jashtëzakonisht e padëshirueshme të përdoren pyetje në një lak. Kjo mund të ndikojë në mënyrë kritike në kohën e funksionimit të një funksioni të caktuar. Është shumë e dëshirueshme që të merren të gjitha të dhënat në kërkesë dhe më pas të përpunohen të dhënat në një cikli. Por ndonjëherë ka raste kur bëhet e pamundur zhvendosja e kërkesës jashtë ciklit. Në këtë rast, për optimizim, mund të zhvendosni krijimin e pyetjes jashtë ciklit, dhe në ciklin, të zëvendësoni parametrat e nevojshëm dhe të ekzekutoni pyetjen.

Kërkesë = Kërkesë e re; Query.Text = "ZGJIDH | Klientët.Lidhja, | Klientët.Data e lindjes |NGA | Drejtoria.Klientët SI Klientë | KU | Klientët.Lidhja = &Klient"; Për çdo rresht FROM TableClients Loop Query.SetParameter("Klient", Klient); QueryResult = Query.Execute().Select(); Cikli i Fundit;

Kjo do ta shpëtojë sistemin nga kontrollimi i sintaksës së kërkesës në një lak.

11. Ndërtim “HAVING”.

Një dizajn që është mjaft i rrallë në kërkesa. Ju lejon të vendosni kushte për vlerat e funksioneve agregate (SHUMË, MINIMUM, MESATAR, etj.). Për shembull, ju duhet të zgjidhni vetëm ata klientë, shuma e pagesës së të cilëve në shtator ishte më shumë se 13,000 rubla. Nëse përdorni kushtin "WHERE", fillimisht do t'ju duhet të krijoni një tabelë të përkohshme ose një pyetje të ndërthurur, të gruponi regjistrimet atje sipas shumës së pagesës dhe më pas të aplikoni kushtin. Ndërtimi "HAVING" do të ndihmojë në shmangien e kësaj.

SELECT Payment.Customer, AMOUNT(Payment.Amount) AS Amount FROM Document.Payment AS Payment WHERE MUAJ(Data.Payment) = 9 GROUP BY Payment.Customer HAVING AMOUNT(Payment.Smount) > 13000

Në konstruktor, për ta bërë këtë, thjesht shkoni te skeda "Kushtet", shtoni një kusht të ri dhe kontrolloni kutinë e kontrollit "Custom". Pastaj thjesht shkruani Shuma (Pagesa.Shuma) > 13000


12. Vlera NULL

Unë nuk do të përshkruaj këtu parimet e logjikës me tre vlera në bazën e të dhënave; ka shumë artikuj për këtë temë. Vetëm shkurtimisht se si I PAVLEFSHËM mund të ndikojë në rezultatin e pyetjes. Vlera NULL nuk është në fakt një vlerë, dhe fakti që vlera është e papërcaktuar është i panjohur. Prandaj, çdo operacion me NULL kthen NULL, qoftë mbledhje, zbritje, pjesëtim apo krahasim. Një vlerë NULL nuk mund të krahasohet me një vlerë NULL sepse ne nuk dimë se çfarë të krahasojmë. Ato. të dyja këto krahasime janë: NULL = NULL, NULL<>NULL nuk është e vërtetë apo e rreme, është e panjohur.

Le të shohim një shembull.

Për ata klientë që nuk kanë pagesa, duhet të afishojmë fushën “Sign” me vlerën “Nuk ka pagesa”. Për më tepër, ne e dimë me siguri që kemi klientë të tillë. Dhe për të pasqyruar thelbin e asaj që shkrova më lart, le ta bëjmë në këtë mënyrë.

ZGJIDH "Nuk ka pagesa" SI Atribut, NULL AS Toppagesat e VENDIT të dokumentit; ///////////////////////////////////////////////////////////////// ///////////////////////// ZGJIDH Klientët.Lidhja AS Klient, Pagesa.Lidhja SI Pagesa VENDOSI tClientPayment NGA Drejtoria.Klientët AS Klientët LËNË Dokumentin e LIDHJES. Pagesa AS Software Payment Clients.Link = Pagesa.Aksionar; ///////////////////////////////////////////////////////////////// ////////////////////////// ZGJIDHni tClientPayment.Client NGA tClientPayment AS tClientPayment BASHKOHU I BRENDSHËM tPagesën SI tTë paguaj NGA tClientPayment.Pagesa = tPagesë.

Kushtojini vëmendje tabelës së dytë të përkohshme tClientPayment. Me bashkimin e majtë zgjedh të gjithë klientët dhe të gjitha pagesat për këta klientë. Për ata klientë që nuk kanë pagesa, fusha “Pagesa” do të jetë NULL. Sipas logjikës, në tabelën e parë të përkohshme “tPayments” caktova 2 fusha, njëra prej tyre NULL, rreshtin e dytë “Nuk ka pagesa”. Në tabelën e tretë, unë lidh tabelat "tClientPayment" dhe "tPayment" duke përdorur fushat "Pagesë" dhe "Dokument" me një bashkim të brendshëm. Dimë që në tabelën e parë fusha “Dokument” është NULL, kurse në tabelën e dytë, ata që nuk kanë pagesa në fushën “Pagesa” janë gjithashtu NULL. Çfarë do të na rikthejë një lidhje e tillë? Por nuk do të kthejë asgjë. Sepse krahasimi NULL = NULL nuk vlerësohet në True.

Në mënyrë që kërkesa të kthejë rezultatin e pritur, le ta rishkruajmë atë:

ZGJEDH "Nuk ka pagesa" SI Atribut, VLERA(Document.Payment.EmptyLink) AS VENDI I dokumentit tePagesat; ///////////////////////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(Payment.Link, VALUE(Document.Payment.EmptyLink)) SI Pagesa PUT tClientPayment FROM Directory.Klientët SI Klientë Dokumenti LIDHJA E LETË.Pagesa SI Pagesa NGA Klientët.Lidhja = Pagesa.Aksionari; ///////////////////////////////////////////////////////////////// ////////////////////////// ZGJIDHni tClientPayment.Client NGA tClientPayment AS tClientPayment BASHKOHU I BRENDSHËM tPagesën SI tTë paguaj NGA tClientPayment.Pagesa = tPagesë.

Tani, në tabelën e dytë të përkohshme, ne kemi treguar se nëse fusha "Pagesa" është NULL, atëherë kjo fushë = një lidhje boshe me dokumentin e pagesës. Në tabelën e parë ne gjithashtu zëvendësuam NULL me një referencë boshe. Tani lidhja përfshin fusha jo NULL dhe kërkesa do të kthejë rezultatin e pritur.

Të gjitha kërkesat e përfshira në artikull pasqyrojnë situatat që do të doja të merrja në konsideratë dhe asgjë më shumë. RRETH Ato mund të mos jenë delirante ose nënoptimale, gjëja kryesore është që ato pasqyrojnë thelbin e shembullit.

13. Një tipar i padokumentuar i dizajnit "ZGJEDHJA KUR...PËSHTJET...FUND".

Në rastin kur është e nevojshme të përshkruhet ndërtimi "Kushtet" në kërkesë, ne përdorim sintaksën standarde:

SELECT SELECTION WHEN Users.Name = "Vasya Pupkin" THEN "Punonjësi ynë i preferuar" ELSE "Ne nuk e dimë këtë" FUND AS Field1 FROM Directory.Përdoruesit AS Përdorues

Por, çka nëse, për shembull, duhet të marrim emrin e muajit në një kërkesë? Shkrimi i një ndërtimi të madh në një kërkesë është i shëmtuar dhe kërkon shumë kohë, kështu që kjo formë e shkrimit më lart mund të na ndihmojë:

ZGJIDH MUAJIN(US_CalculationConsumption_ScheduleTurnover.CalculationPeriod) WHEN 1 PASTAJ "Janar" WHEN 2 PASTA "shkurt" WHEN 3 PASTAJ "Mars" WHEN 4 PASTAJ "Prill" WHEN 5 PASTAJ "THENJHËN "THENJNH" KUR 8 PASTAJ "Gusht" KUR 9 PASTAJ "Shtator" KUR 10 PASTA "Tetor" KUR 11 PASTAJ "Nëntor" KUR 12 PASTAJ "Dhjetor" PËRFUNDON SI një muaj

Tani dizajni duket më pak i rëndë dhe është i lehtë për t'u kuptuar.

14. Ekzekutimi i pyetjes në grup.


Për të mos shumëzuar kërkesat, mund të krijoni një kërkesë të madhe, ta ndani në paketa dhe të punoni me të.
Për shembull, më duhet të marr fushat e mëposhtme nga drejtoria "Përdoruesit": "Data e lindjes" dhe rolet e disponueshme për secilin përdorues. ngarkoni këtë në pjesë të ndryshme tabelare në formular. Sigurisht, ju mund ta bëni këtë me një kërkesë, atëherë do t'ju duhet të përsërisni regjistrimet ose t'i fshini ato, ose mund ta bëni këtë:

SELECT Users.Link AS Emri i plotë, Përdoruesit.Data e lindjes, Përdoruesit.Roli PUT vtUsers FROM Directory.Users AS Users; ///////////////////////////////////////////////////////////////// ///////////////////////// ZGJIDHni tueUsers.Emri i plotë, tueUsers.Data e lindjes NGA tueUsers AS tueUsers GRUPI SIPAS tueUsers.emri i plotë, tueUsers . Data e lindjes; ///////////////////////////////////////////////////////////////// ///////////////////////// ZGJIDHni wUsers.Emri i plotë, wUsers.Roli FROM përdoruesit AS përdoruesit GRUPI BY Users.Emri i plotë, përdoruesit. Data e Lindja

tPackage = Request.ExecutePackage();

TP_Data e lindjes = tPaketa.Ngarko();
TP_Rolet = tPaketa.Shkarko();

Siç mund ta shohim, pyetja mund të ekzekutohet në një grup dhe rezultati mund të përpunohet si një grup. Në disa raste është shumë i përshtatshëm.

15. Kushtet në një kërkesë grupi

Për shembull, ne kemi një kërkesë grupi, ku fillimisht marrim fushat: “Emri, data e lindjes, kodi” nga direktoria “Përdoruesit” dhe duam të marrim regjistrime me kushtet për këto fusha nga direktoria “Individët”.

SELECT Users.Individual.Name AS Emri, Users.Individual.Data e lindjes AS data e lindjes, Users.Individual.Code AS Code PLACE vtUsers FROM Directory.Users AS Users; ///////////////////////////////////////////////////////////////// ////////////////////////// SELECT Individë Lidhja AS Individual FROM Directory Individët AS Individë

Ju mund të vendosni kushte si kjo:

WHERE Individuals.Code IN (SELECT vtUsers.Code FROM vtUsers) AND Individuals.Emri IN (SELECT vtUsers.Code FROM vtUsers) DHE Individuals.BirthDate IN (SELECT vtUsers.DateBirth FROM tv)

Dhe ju mund ta bëni këtë si kjo:

WHERE (Individuals.Code, Individuals.Name, Individuals.Date of Birth) IN (ZGJIDHni tueUsers.Code, tueUsers.Name, tueUsers.Data e lindjes FROM tueUsers)

Për më tepër, është e nevojshme të ruani rendin.

16. Thirrja e ndërtuesit të pyetjeve për "kusht" në një kërkesë grupi

Kur është e nevojshme të vendosni një kusht, si në shembullin e mësipërm, mund të harroni se si thirret kjo apo ajo fushë në tabelën virtuale.
Për shembull, duhet të vendosni një kusht në fushën "Data e lindjes", dhe në tabelën virtuale kjo fushë quhet "Data e lindjes së debitorit", dhe nëse harroni emrin, do të duhet të dilni nga redaktimi i kushtit pa duke ruajtur dhe shikoni emrin e fushës. Për të shmangur këtë, mund të përdorni teknikën e mëposhtme.

Është e nevojshme të vendosni kllapa pas konstruksionit "B" dhe të lini një hapësirë ​​(hapësirë) boshe midis kllapave, zgjidhni këtë hapësirë ​​dhe thirrni konstruktorin e pyetjes. Projektuesi do të ketë akses në të gjitha tabelat e pyetjes së grupit. Teknika funksionon si në tabelat e regjistrave virtualë ashtu edhe në skedën "Kushtet". Në rastin e fundit, duhet të kontrolloni kutinë "P (kusht arbitrar)" dhe të futni modalitetin e redaktimit "F4".

Pyetjet shpesh bëheshin menjëherë dhe ato thjesht shërbejnë për të ilustruar "teknikat" që po shqyrtoja.

Doja të shikoja përdorimin e indekseve në pyetje, por kjo është një temë shumë e gjerë. Do ta vendos në një artikull të veçantë, ose do ta shtoj këtu më vonë.

upd1. Pikat 11,12
upd2. Pikat 13,14,15,16

Librat e përdorur:
Gjuha e pyetjes "1C: Enterprise 8" - E.Yu. Khrustaleva
Zhvillimi profesional në sistemin 1C: Enterprise 8."

Gjatë organizimit të mostrave në probleme reale, në shumicën dërrmuese të rasteve, përzgjedhja e të dhënave organizohet në përputhje me kritere të caktuara.

Në rastin kur zgjedhja bëhet nga një tabelë e vërtetë, nuk lindin vështirësi. Të dhënat përpunohen absolutisht në mënyrë të parëndësishme:

Në rastin kur burimi në pyetje është një tabelë virtuale, situata bëhet disi më e ndërlikuar.


Gjuha e pyetjes ju lejon të vendosni një kusht në një përzgjedhje nga tabelat virtuale në dy mënyra: në klauzolën WHERE dhe duke përdorur parametrat e tabelës virtuale. Të dyja metodat do të çojnë në të njëjtin rezultat (me përjashtim të disa rasteve specifike), por, megjithatë, ato janë larg nga ekuivalenti.

Ne tashmë e dimë se tabelat virtuale quhen virtuale sepse ato nuk janë në të vërtetë në bazën e të dhënave. Ato formohen vetëm në momentin kur u bëhet kërkesa. Pavarësisht kësaj, është e përshtatshme për ne (d.m.th., ata që shkruajnë pyetjen) t'i konsiderojmë tabelat virtuale si ato reale. Çfarë do të ndodhë në sistemin 1C Enterprise 8 kur pyetja që përpiluam të hyjë ende në tabelën virtuale?

Në hapin e parë, sistemi do të ndërtojë një tabelë virtuale. Në hapin e dytë, të dhënat do të zgjidhen nga tabela që rezulton që plotësojnë kushtin e specifikuar në klauzolën WHERE:
Shihet qartë se mostra përfundimtare nuk do të përfshijë të gjitha rekordet nga tabela virtuale (dhe, rrjedhimisht, nga baza e të dhënave), por vetëm ato që plotësojnë kushtin e dhënë. Dhe të dhënat e mbetura thjesht do të përjashtohen nga rezultati.

Kështu, sistemi nuk do të bëjë vetëm punë të padobishme, por dyfishon punë të padobishme! Së pari, burimet do të shpenzohen për ndërtimin e një tabele virtuale bazuar në të dhëna të panevojshme (në figurë ato janë shënuar si "zonat e të dhënave A dhe B"), dhe më pas do të punohet për të filtruar këto të dhëna nga rezultati përfundimtar.

A është e mundur që menjëherë, në fazën e ndërtimit të një tabele virtuale, të ndaloni përdorimin e të dhënave të panevojshme? Rezulton se është e mundur. Kjo është pikërisht ajo për të cilën janë krijuar parametrat e tabelës virtuale:

Duke parametrizuar një tabelë virtuale, ne kufizojmë menjëherë sasinë e të dhënave që do të përpunohen nga pyetësori.

Cili është ndryshimi midis vlerave të parametrit të tabelës virtuale "Metoda e Shtimit"?
Kur Metoda e Shtimit vendoset në "lëvizje", atëherë do të kthehen vetëm ato periudha në të cilat ka pasur lëvizje. Kur vendoset "Lëvizjet dhe kufijtë e periudhës", atëherë lëvizjeve të mësipërme do t'u shtohen 2 rekorde: lëvizjet në fillim dhe në fund të periudhës së specifikuar në parametrat VT. Fusha "Regjistruesi" do të jetë bosh për këto 2 regjistrime.

Informacioni i marrë nga faqja

Gjatë organizimit të mostrave në probleme reale, në shumicën dërrmuese të rasteve, përzgjedhja e të dhënave organizohet në përputhje me kritere të caktuara.

Në rastin kur zgjedhja bëhet nga një tabelë e vërtetë, nuk lindin vështirësi. Të dhënat përpunohen absolutisht në mënyrë të parëndësishme:

Në rastin kur burimi në pyetje është një tabelë virtuale, situata bëhet disi më e ndërlikuar.

Gjuha e pyetjes ju lejon të vendosni një kusht në një përzgjedhje nga tabelat virtuale në dy mënyra: në klauzolën WHERE dhe duke përdorur parametrat e tabelës virtuale. Të dyja metodat do të çojnë në të njëjtin rezultat (me përjashtim të disa rasteve specifike), por, megjithatë, ato janë larg nga ekuivalenti.

Ne tashmë e dimë se tabelat virtuale quhen virtuale sepse ato nuk janë në të vërtetë në bazën e të dhënave. Ato formohen vetëm në momentin kur u bëhet kërkesa. Pavarësisht kësaj, është e përshtatshme për ne (d.m.th., ata që shkruajnë pyetjen) t'i konsiderojmë tabelat virtuale si ato reale. Çfarë do të ndodhë në sistemin 1C Enterprise 8 kur pyetja që përpiluam të hyjë ende në tabelën virtuale?

Në hapin e parë, sistemi do të ndërtojë një tabelë virtuale. Në hapin e dytë, të dhënat do të zgjidhen nga tabela që rezulton që plotësojnë kushtin e specifikuar në klauzolën WHERE:


Shihet qartë se mostra përfundimtare nuk do të përfshijë të gjitha rekordet nga tabela virtuale (dhe, rrjedhimisht, nga baza e të dhënave), por vetëm ato që plotësojnë kushtin e dhënë. Dhe të dhënat e mbetura thjesht do të përjashtohen nga rezultati.

Kështu, sistemi nuk do të bëjë vetëm punë të padobishme, por dyfishon punë të padobishme! Së pari, burimet do të shpenzohen për ndërtimin e një tabele virtuale bazuar në të dhëna të panevojshme (në figurë ato janë shënuar si "zonat e të dhënave A dhe B"), dhe më pas do të punohet për të filtruar këto të dhëna nga rezultati përfundimtar.

A është e mundur që menjëherë, në fazën e ndërtimit të një tabele virtuale, të ndaloni përdorimin e të dhënave të panevojshme? Rezulton se është e mundur. Kjo është pikërisht ajo për të cilën janë krijuar parametrat e tabelës virtuale:


Duke parametrizuar një tabelë virtuale, ne kufizojmë menjëherë sasinë e të dhënave që do të përpunohen nga pyetësori.

Cili është ndryshimi midis vlerave të parametrit të tabelës virtuale "Metoda e Shtimit"?
Kur Metoda e Shtimit vendoset në "lëvizje", atëherë do të kthehen vetëm ato periudha në të cilat ka pasur lëvizje. Kur vendoset "Lëvizjet dhe kufijtë e periudhës", atëherë lëvizjeve të mësipërme do t'u shtohen 2 rekorde: lëvizjet në fillim dhe në fund të periudhës së specifikuar në parametrat VT. Fusha "Regjistruesi" do të jetë bosh për këto 2 regjistrime.

Le të thërrasim dialogun për futjen e parametrave të tabelës virtuale PriceSliceLast dhe të tregojmë se periudha do të kalohet në parametrin ReportDate. Për ta bërë këtë, zgjidhni këtë tabelë në listën e Tabelave dhe klikoni butonin Opsionet e tabelës virtuale. Pastaj zgjidhni fushat e mëposhtme nga tabelat:

    SprNomenklatura. prind,

    ÇmimetFjala e fundit.Çmimi.

Bashkohu në tabelën e majtë

- Në faqerojtësin Lidhjet: në fushën e kushtit Link, që vlera e dimensionit të Nomenklaturës së regjistrit të informacionit duhet të jetë e barabartë me referencën në elementin e drejtorisë së Nomenklaturës. Dhe gjithashtu zgjidhni kutinë e kontrollit Të gjitha për tabelën e regjistrave dhe kontrolloni atë për tabelën e kërkimit, duke vendosur kështu llojin e lidhjes si lidhje majtas për tabelën e kërkimit:

Oriz. 13.15. Marrëdhënia midis tabelave në një pyetje

- Në faqerojtësin Kushtet le të vendosim kushtin për zgjedhjen e elementeve nga drejtoria e Nomenklaturës - elementët e zgjedhur duhet të korrespondojnë me llojin e nomenklaturës të kaluar në parametrin e kërkesës Lloji i nomenklaturës:

Oriz. 13.16. Kushtet për përzgjedhjen e elementeve

- Në faqerojtësin Sindikatat/Emërtimet: specifikoni pseudonimin e fushës Prindër = Grupi i Shërbimit dhe fushës Lidhja = Shërbimi. - Kliko OK -

Pas kësaj, ju duhet të redaktoni skemën e paraqitjes së të dhënave, për ta bërë këtë në skedën Burimet, klikoni në butonin shtoni dhe zgjidhni një burim - Çmimi

- Në faqerojtësin Opsione vendosim vlerën e parametrit Nomenklature Type - Enumeration.Llojet e nomenklaturës.Shërbimi. Përveç kësaj, ne do të heqim kufizimin e disponueshmërisë për parametrin ReportDate. Në fushën Lloji i këtij parametri, vendosni përbërjen e datës - Data. Për parametrin Periudha, përkundrazi, vendosëm një kufizim disponueshmërie:

Oriz. 13.17. Opsionet e skemës së paraqitjes

Cilësimet

- Le të shkojmë te faqerojtësi Cilësimet: Le të krijojmë një grupim bazuar në fushën e Grupit të Shërbimit, duke specifikuar llojin e grupimit Hierarki.

Llojet e mëposhtme të hierarkisë ekzistojnë për grupimet e raporteve: Pa hierarki - vetëm të dhënat johierarkike shfaqen në grupim. Hierarkia - të dhënat johierarkike dhe hierarkike shfaqen në grupim. Vetëm hierarkia - vetëm të dhënat hierarkike (prindërore) shfaqen në grupim. Brenda këtij grupi do të krijojmë një tjetër, pa specifikuar fushën e grupit. Në nën-skedën Fushat e zgjedhura: specifikoni fushat e prodhimit Shërbimi dhe Çmimi:

Oriz. 13.18. Struktura dhe fushat e raportit

Në nën-skedën Të tjera cilësimet ne do të kryejmë hapat e mëposhtëm:

Oriz. 13.19. Cilësimet për shfaqjen e totaleve të përgjithshme për grupimin "Grupi i Shërbimit".

Oriz. 13.20. Vendosja dhe shfaqja e rezultateve për një raport global

Më në fund, le të përfshijmë parametrin Data e raportimit në cilësimet e përdoruesit dhe të vendosim modalitetin e tij të redaktimit në Qasje të shpejtë. Le të mbyllim projektuesin e skemës së përbërjes së të dhënave dhe në dritaren për modifikimin e objektit List of Services, shkoni te skeda Nënsistemet. Në listën e nënsistemeve të konfigurimit, vini re nënsistemet Ofrimi i Shërbimit dhe Kontabiliteti.

    Në 1C: Modaliteti i ndërmarrjes

Le të hapim 1C: Enterprise në modalitetin e korrigjimit dhe para së gjithash të hapim regjistrin periodik Çmimet. Pastaj do të testojmë raportin.

Duke përdorur këtë raport si shembull, ne studiuam se si sistemi i përbërjes së të dhënave merr vlerat më të fundit nga regjistri periodik i informacionit dhe si shfaqen grupimet sipas hierarkisë së drejtorive.

Nëse publikimi im është i dobishëm për ju, mos harroni t'i jepni një plus :-)

Këtu është një rubrikator për të gjitha detyrat në koleksion(një faqe që përmban lidhje me temat e forumit për secilën detyrë)
http://chistov.spb.ru/forum/16-969-1

Epo, tani zhvillimet dhe shënimet e mia që kam krijuar gjatë procesit të përgatitjes.
Do të përpiqem të përsëris sa më pak me dy të përmendura më sipër e fundit publikimet.

Pra, le të fillojmë:


Nëse e merrni nga distanca, duhet të keni dy objekte në desktopin tuaj në fund të provimit:

1. Ngarkimi përfundimtar i bazës së informacionit (skedari dt)
2. Shënim shpjegues

Nuk duhet të ketë asgjë tjetër, asnjë kopje të ndërmjetme, etj.

Sigurohuni që të shkruani një shënim shpjegues!
Në rastin e një detyre të formuluar në mënyrë të paqartë, sigurohuni që të shkruani atje se keni zgjedhur pikërisht këtë dhe atë opsion zgjidhjeje.
Gjithashtu, në vendet kyçe të kodit, është më mirë të lihen komente të shkurtra, pa fanatizëm, por aty ku ekzaminuesi mund të ketë pyetje, është më mirë të shkruhet.

Por për këtë do t'ju thuhet në udhëzimet që do t'ju jepen të lexoni përpara provimit.
Është më mirë të dihet paraprakisht)


Përdorimi i karakterit ampersand në pyetje.

Ndonjëherë është më shpejt të shkruash nga një tastierë shtesë sesa të ndërrosh paraqitjen përpara dhe mbrapa, duke kursyer kohë
& = Alt+38

*************************************************************************************************
Përdorimi i TimePoint() në pyetje

Në pyetjet për regjistrat e akumulimit dhe kontabilitetit, është e nevojshme të përdoret jo data e dokumentit si parametër i tabelës virtuale (periudha), por parametri Moment, i cili përcaktohet në kod si më poshtë:

Momenti = ?(Mënyra e kalimit = Mënyra e postimit të dokumentit. Operacional, i papërcaktuar, Momenti i kohës());

*************************************************************************************************
Gjatë gjenerimit të lëvizjeve të dokumenteve me regjistër, në fillim të procedurës së përpunimit të postimit, është e nevojshme të pastrohen lëvizjet e dokumentit aktual me regjistër.

Kodi është:

Movement.RegisterName.Write = E vërtetë; Movements.RegisterName.Clear();

Është e mundur që gjatë procesit të jetë e nevojshme të analizohen të dhënat nga ky regjistër.
Pra, në mënyrë që kur analizoni të dhënat aktuale (të vjetrat, para se të ndryshonte dokumenti) ato përfundimisht të mos përfshihen në mostër, mund të shtoni një rresht më shumë në dy rreshtat e mësipërm:

Movement.RegisterName.Write();

Ose, kur analizoni të dhënat, tregoni në mënyrë eksplicite një kufi që nuk përfshin pikën kohore të dokumentit aktual.

Por kudo thjesht tregova ndërtimin e këtyre tre rreshtave:

Movement.RegisterName.Write = E vërtetë; Movements.RegisterName.Clear(); Movement.RegisterName.Write();

*************************************************************************************************
Ekzistojnë dy mënyra për të bllokuar të dhënat, zgjedhja midis tyre varet nga metoda e përdorur - e vjetër ose e re:

1) Bllokim i rregullt i kontrolluar, metodë e vjetër e përpunimit të dokumenteve (objekt i bllokimit të të dhënave)

Vendosni nëse balancat fillimisht kontrollohen dhe më pas fshihen.
Në rastin kur duhet të kemi ndonjë informacion nga regjistri për të formuar një lëvizje.


Shembull:

Në dokument - sasi, në regjistër - sasi dhe shumë (kosto)
Pra, ne e dimë sasinë e mallrave nga dokumenti - sa fshijmë, por koston - jo.
Këtë mund ta zbulojmë vetëm nga regjistri, por për të siguruar që askush të mos e ndryshojë regjistrin midis momentit të marrjes së bilanceve dhe momentit të regjistrimit të lëvizjeve, duhet të bllokojmë regjistrin edhe para se të lexojmë bilancet.
Pra, në këtë rast përdoret objekti Data Locking. Dhe kur e krijoni atë, është më e saktë të tregoni se me çfarë dimensionesh po bllokojmë regjistrin (për shembull, në rastin tonë - vetëm nga artikulli i specifikuar në dokument) - në mënyrë që të mos ketë bravë të panevojshme dhe një përdorues tjetër të mund të shesë një tjetër artikull.


1. Vendosni një kyç duke përdorur objektin Data Lock
2. Lexoni pjesën tjetër
3. Ne kontrollojmë mundësinë e shlyerjes
4. Ne krijojmë lëvizje, për shembull, fshijmë mallrat
5. Pas postimit të dokumentit, bllokimi hiqet automatikisht (bllokimi është i vlefshëm si pjesë e transaksionit të postimit dhe hiqet automatikisht nga sistemi). Kjo do të thotë, nuk ka nevojë të zhbllokoni posaçërisht objektin.

2) Metodologji e re për përpunimin e dokumenteve (duke përdorur veçorinë LockForChange = E vërtetë)

Përdoret nëse nuk kemi nevojë për informacion nga regjistrat për të formuar lëvizje dhe mund të kontrollojmë nëse kemi kaluar në negativ gjatë fshirjes nëse, pas regjistrimit, shikojmë bilancet në regjistër dhe shohim se ka negative. . Në këtë rast, ne do të kuptojmë se kemi hequr shumë dhe do të anulojmë operacionin e fshirjes.

Shembull:
Le të shqyrtojmë funksionimin e shitjes së një produkti.
Në dokument - sasi, në regjistër - vetëm sasi
Pra, sasinë e mallit e dimë nga dokumenti.
Ne formojmë lëvizje me sasinë e specifikuar në dokument dhe i regjistrojmë ato. Më pas, lexojmë regjistrin, shikojmë bilancet dhe analizojmë nëse ka ndonjë negativ. Nëse ka, shfaqni një gabim dhe vendosni Refuzimin = E vërtetë.

Kjo do të thotë, sekuenca është si kjo:
1. Për të lëvizur nëpër regjistër, vendosni veçorinë BlockForChange = True
2. Ne krijojmë lëvizje - fshijmë mallrat
3. Regjistroni lëvizjet
4. Lexoni regjistrin dhe sigurohuni që të mos ketë bilanc negativ. Nëse ka, atëherë ata e fshinë tepricën, nëse jo, atëherë gjithçka është në rregull.

Pra, në këtë rast, nuk ka nevojë të tregojmë se me cilat dimensione duhet të bllokojmë regjistrin.
Ne thjesht vendosim veçorinë BlockForChange në True përpara se të regjistrojmë lëvizjet tona, të formojmë lëvizjet dhe të regjistrojmë.
Vetë sistemi do të bllokojë regjistrin në momentin e regjistrimit sipas matjeve që nevojiten, duke analizuar atë që kemi regjistruar.
Pasi të përfundojë, bllokimi do të hiqet.

Ky opsion (i dyti) është më i thjeshtë, quhet "metodologjia e re për përpunimin e dokumenteve" dhe 1C rekomandon përdorimin e tij nëse është e mundur dhe zbret pikë nëse përdoret opsioni i parë, por në disa raste thjesht nuk mund të zbatohet dhe opsioni i parë me përdoret objekti Data Locking (shih shembullin e mësipërm).

Unë gjithashtu vërej se pavarësisht nga metoda e zgjedhur, lëvizjet duhet të pastrohen përpara se të punoni me to (shih këshillat e mëparshme)

*************************************************************************************************
Bllokimi i të dhënave (metoda e bllokimit nr. 1 nga përshkrimi i mësipërm)

Kërkohet kyçje e kontrolluar ku lexohen të dhënat dhe lëvizjet bëhen në bazë të këtyre të dhënave
Mënyra më e shpejtë për të marrë kodin e menaxhuar të kyçjes është të futni "Bllokimi i të dhënave", telefononi Asistentin e Sintaksës dhe thjesht kopjoni kodin shembull nga atje. Pastaj thjesht ndryshoni atë në emrin e regjistrit dhe dimensionet tuaja.

Duket diçka si kjo:

Lock = NewDataLock; Elementi i kyçjes = Mbyllje.Shto ("Regjistri i Akumulimit.MallratNëMagazinat"); LockElement.Mode = DataLockMode.Exclusive; BlockingElement.Burimi i të dhënave = PM; Elementi i kyçjes.UseFromDataSource("Nomenklatura", "Nomenklatura"); Lock.Lock();

*************************************************************************************************
Është më mirë ta quani pjesën tabelare të dokumenteve thjesht "TC"

Ekziston vetëm një pjesë tabelore në 99% të dokumenteve. Një emër i tillë i unifikuar për pjesët tabelare do të ndihmojë shumë në kursimin e kohës, pasi:
1) Shumë e shkurtër - shkruani shpejt
2) E njëjta gjë për të gjitha dokumentet, nuk duhet të mbani mend se si quhet kur shkruani kodin

*************************************************************************************************
Rezultati i pyetjes duhet të kontrollohet për zbrazëti përpara se të merret ose të ngarkohet në specifikimet teknike.

Në përgjithësi, kam përdorur kampionimin në të gjitha detyrat.

Marrja e mostrave është më optimale për sistemin për sa i përket performancës, pasi është "mprehur" vetëm për leximin e të dhënave (ndryshe nga TK).

Por në çdo rast, përpara metodës Select(), është më mirë të kontrolloni rezultatin e pyetjes për zbrazëti, kjo do të zvogëlojë më tej ngarkesën në sistem.

Rezultati = Query.Run(); Nëse Jo Result.Empty() Pastaj Select = Result.Select(TravelQueryResult.ByGrouping); ... FundNëse;

Dhe në rast se duhet të marrim vetëm një vlerë nga kërkesa
(për shembull, vetëm metoda e fshirjes në përputhje me politikën kontabël të vendosur për këtë vit):

Rezultati = Query.Run(); Nëse nuk rezulton.Empty() Pastaj Select = Result.Select(); Përzgjedhja.Next(); Metoda e fshirjes së kostos = Sample.Cost Write-off Method; fundNëse;

*************************************************************************************************
Dokumenti "Operacioni" për një detyrë kontabël

Është e nevojshme të krijohet një dokument operimi për detyrat e kontabilitetit.

Ne e çaktivizojmë fare postimin për të (në vetitë "Posimi = Moho"), tregojmë se bën lëvizje në regjistrin e kontabilitetit dhe i tërheqim lëvizjet në formular.

*************************************************************************************************
Përpunimi i shpejtë i dokumenteve:

Duhet të jetë përfshirë:
Në operim dhe kontabilitet. duhet të aktivizohet kontabiliteti i dokumenteve (përveç dokumentit "Operacioni", shih më poshtë).

Duhet të jetë fikur:
në detyrat e llogaritjes nuk ka kuptim për një dokument të listëpagesave.

Për dokumentin "Operacioni", postimi duhet të çaktivizohet fare (në vetitë e dokumentit "Posimi = Ndalohet"),
meqenëse ai shkruan thjesht shkruan të dhëna direkt në regjistër kur shkruan.

*************************************************************************************************
Kushti në një kërkesë të formularit "Ose nomenklatura e specifikuar ose ndonjë, nëse nuk specifikohet"

Në pyetje, ndeshet detyra e mëposhtme: për shembull, ju duhet të zgjidhni dokumentet me një nomenklaturë të specifikuar ose të gjitha dokumentet nëse nomenklatura nuk është e specifikuar.
Ajo zgjidhet nga kushti i mëposhtëm në vetë kërkesën:

Nomenklatura = &Nomenklatura OSE &Nomenklatura = Vlera (Directory.Nomenclature.EmptyLink)

Por do të ishte më optimale dhe më e saktë për ta transformuar këtë gjendje (faleminderit yukon):


Request.Text = Request.Text + "KU Nomenklatura = &Nomenklatura";

fundNëse;

Me ardhjen e modelit të objektit të pyetjes në 8.3.5, do të jetë e mundur të shtohet një kusht më i sigurt:

Nëse ValueFilled (Nomenklatura) Atëherë
Query1.Selection.Add("Artikulli = &Nomenklatura");
Request.SetParameter("Nomenklatura", Nomenklatura);
fundNëse;

*************************************************************************************************
Bashkimi i tabelave në pyetje:

Numri i të dhënave totale nuk varet nga afishimi i fushës së tabelës së bashkuar, por varet vetëm nga marrëdhëniet e konfiguruara.
Kjo do të thotë, fusha e tabelës së bashkangjitur mund të mos shfaqet.

Nëse dëshironi të bashkëngjitni një tabelë pa asnjë kusht, atëherë në skedën e kushteve thjesht shkruani kushtin "E VËRTETË".
Në këtë rast, tabela do të bashkohet saktësisht.

*************************************************************************************************
Përdorimi i planit të llojeve të karakteristikave (PVC):

1. Përdorni si mekanizëm për përshkrimin e karakteristikave të objekteve.

1.1. Ne krijojmë PVC. Këto do të jenë Llojet e Karakteristikave (për shembull, ngjyra, madhësia, shpejtësia maksimale, etj.). Në cilësimet, zgjidhni të gjitha llojet e mundshme të vlerave karakteristike dhe, nëse është e nevojshme, krijoni objektin nga pika 1.2 dhe gjithashtu tregoni atë në cilësimet.

1.2. Për vlerat shtesë të PVC, ne krijojmë një drejtori vartëse Vlerat shtesë të karakteristikave (ose thjesht vlerat e karakteristikave).
Ai do të ruajë karakteristikat nëse ato nuk janë në drejtoritë ekzistuese. Mund të mos e krijojmë nëse të gjitha karakteristikat që na nevojiten janë në drejtoritë ekzistuese, ose këto vlera mund të përfaqësohen nga llojet elementare të të dhënave. Në cilësimet PVC ne tregojmë se kjo direktori do të përdoret për qëllime shtesë. vlerat e karakteristikave.

1.3. Ne krijojmë një regjistër informacioni, i cili në fakt lidh tre objekte:
- Objekti me të cilin lidhim mekanizmin e karakteristikave
- Karakteristikat e tipit (lloji PVC)
- Vlera e karakteristikave (lloji - karakteristik, ky është një lloj i ri që u shfaq në sistem pas krijimit të PVC
dhe duke përshkruar të gjitha llojet e mundshme të të dhënave që mund të marrë një vlerë karakteristike).
Në regjistrin e informacionit, ne tregojmë se Tipi Karakteristik është pronar për Vlerën Karakteristike (lidhja me parametrin e përzgjedhjes), si dhe lidhja e tipit për Vlerën Karakteristike, përsëri nga Lloji Karakteristik.

Një veçori tjetër është se për çdo lloj karakteristike të krijuar, mund të specifikoni llojin e vlerës karakteristike, nëse nuk ju nevojiten të gjitha llojet e mundshme për të përshkruar vlerën e kësaj karakteristike.

2. Përdorimi i PVC për të krijuar një mekanizëm nën-konto për regjistrin kontabël .

2.1. Ne krijojmë PVC TypesSubconto.

2.2. Ne krijojmë një drejtori vartëse ValuesSubConto (si me karakteristikat, ajo do të përmbajë vlera nënkonto nëse nuk ka të tilla në drejtoritë e tjera).

2.3. Komunikimi bëhet duke përdorur një skemë llogarish.

*************************************************************************************************
Burimet e regjistrit të kontabilitetit:

Shuma - bilanci,
Sasia - jashtë bilancit dhe e lidhur me karakteristikën kontabël Sasiore

*************************************************************************************************
Tabelat e regjistrit virtual të kontabilitetit:

Qarkullim: qarkullim i një llogarie të vetme
QarkullimDtKt: qarkullim ndërmjet çdo dy llogarish, domethënë të gjitha transaksionet e njëjta për periudhën.

*************************************************************************************************
Kontabiliteti i monedhës në regjistrat e kontabilitetit - si të zbatohet:

Ne krijojmë një atribut kontabël "monedhë" në grafikun e llogarive.
Në regjistrin e kontabilitetit, ne gjithashtu krijojmë:
- Dimensioni i monedhës (ndalimi i vlerave bosh, jashtë bilancit, atributi kontabël - valuta)
- burimi CurrencyAmount (jashtë bilancit, atributi i kontabilitetit - monedhë, ai do të ruajë shumën në monedhë, domethënë 100 dollarë për shembull)
Të gjitha.

Pra, struktura e regjistrit është:

Matjet:
- Monedha
Burimet
- Sasi
- Shuma (shuma në rubla)
- MonedhaShuma (shuma në monedhë)

Kështu, kontabiliteti i monedhës është vetëm një përsosje e kontabilitetit konvencional në Republikën e Bjellorusisë; ai nuk ndryshon thelbin e, për shembull, shumën e burimit
(aty, si zakonisht, shuma është në rubla, pavarësisht nëse llogaria është në valutë apo jo).
Dhe nëse funksioni i kontabilitetit të monedhës është i fikur për llogarinë, atëherë kjo është struktura e zakonshme e Republikës së Bjellorusisë (burimet - vetëm sasia dhe shuma).

*************************************************************************************************
Kur vendosim parametrat e një tabele virtuale për të marrë një pjesë të kësaj të fundit, ne vendosim kushte për dimensionet dhe jo për burimet.

Përndryshe, nuk do të marrim një pjesë të atyre më të fundit, por rekordin e fundit me vlerën e burimit të specifikuar - mund të mos jetë i fundit në grupin e dimensioneve

*************************************************************************************************
Kuptimi i burimit dhe detajet në regjistrin e llogaritjes

Në regjistrat e llogaritjes, krijimi i një burimi bën të mundur marrjen e tij gjatë llogaritjes së bazës duke përdorur këtë regjistër.
Dhe madje në proporcion me periudhën e caktuar, vlera e burimit do të rillogaritet (nëse periudha bazë nuk përkon me periodicitetin e regjistrit).

Dhe vlera e atributit është e disponueshme vetëm në tabelën reale të regjistrit të llogaritjes; ajo nuk është e disponueshme në tabelat virtuale.

*************************************************************************************************
Kutia e kontrollit "Bazë" në vetitë e dimensionit të regjistrit të llogaritjes
Do të thotë që nga ky dimension do të merret një bazë në të ardhmen dhe shërben për indeksimin shtesë të vlerave për këtë fushë.

*************************************************************************************************
Ndarja e periudhës së vlefshmërisë së pushimeve sipas muajve kur regjistrohen grupet e regjistrimeve në regjistër,
nëse pushimet specifikohen në dokument në një rresht për disa muaj menjëherë në një rresht:

Data e fillimit të muajit aktual = Fillimi i muajit (TexLineMainAccruals.ActionPeriodStart); CurrentMonthEndDate = FundMonth(TexLineMainAccruals.ActionPeriodStart); Muaji aktual = Data; NdërsaDataFillimiMuaji aktual<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;

*************************************************************************************************
Ndërtimi i një grafiku Gantt:

Ne vendosim një element të tipit "Gantt Chart" në formular, e quajmë DG, më pas krijojmë komandën "Generate" dhe shkruajmë sa vijon në modulin e formularit:

Procedura &OnClient Generate(Command) GenerateOnServer(); Fundi i Procedurës &Në Server Procedura GenerateOn Server() DG.Clear(); DG.Update = False; Kërkesë = Kërkesë e re("ZGJIDH |Periudha bazëAktualeAksioni.Punonjësi, |Periudha eVeprimitBasicAccruals.Lloji i Llogaritjes, |Periudha eVeprimitAktuale.Periudha e Veprimit. ctionsFund |FROM |Llogaritja Regjistro.BasicAccruals.ActualPeriodActions AS BasicAccrualsPerioda AktualeVeprimet |KU |AktualeAccrualsBazëPeriudhaAksionet.PeriudhaVeprimet MES &Data e Fillimit DHE &Data e Fundit "); Query.SetParameter ("Data e fillimit", Period.Data e Fillimit); Request.SetParameter ("Data e Fundit", Period.Data e Fundit); Zgjidh = Query.Run().Select(); Ndërsa Selection.Next() Loop Point = DG.SetPoint(Selection.Employee); Seria = DG.SetSeries(Selection.CalculationType); Vlera = DG.GetValue(Pika, Seria); Interval = Vlera.Shto(); Interval.Start = Sample.PeriodActionStart; Interval.Fund = Mostra.Periudha e VeprimitPërfundim; Cikli i Fundit; DG.Update = E vërtetë; Fundi i procedurës

Në fakt, vetëm kodi në lak është i rëndësishëm për ne këtu, pjesa tjetër e gjërave janë ndihmëse, unë thjesht dhashë të gjithë zbatimin e kësaj nëndetyre.
Në kërkesë është e rëndësishme për ne që të ketë një punonjës, llojin e pagesës, datën e fillimit dhe datën e përfundimit të periudhës.
Kodi është në fakt shumë i thjeshtë, i lehtë për t'u mbajtur mend, mos u shqetësoni nëse ju duket i rëndë

*************************************************************************************************
Përpunimi i hyrjeve të "kthimit" në detyrat e llogaritjes:

Në procedurën e përpunimit të transaksionit (moduli i objektit), ne formojmë të gjitha lëvizjet, dhe më pas nëse ka regjistrime në periudha të tjera, i marrim ato si kjo
(sistemi i gjeneron ato automatikisht - na ndihmon):

Regjistrimet e shtimit = Movements.MainAccruals.GetAddition(); // Nuk ka nevojë të regjistroni lëvizjet për të marrë shtimin

Për çdo linjë teknike nga cikli i shtesave të regjistrimeve
Record = Movements.MainAccruals.Add();
FillPropertyValues ​​(Record, TechString);
Record.RegistrationPeriod = TechString.RegistrationPeriodReversal;
Record.ActionPeriodStart = TechString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = TechString.ActionPeriodEndReversal;
Fundi i Ciklit

Dhe kur llogaritni të dhënat, futni kontrollet:

Nëse TechMotion.Përmbysja Pastaj
Lëvizja aktuale.Sum = - Lëvizja aktuale.Shuma;
fundNëse;

*************************************************************************************************
Si të përcaktoni se çfarë përfshihet në llogaritjet kryesore dhe çfarë përfshihet në llogaritjet shtesë në detyrat e llogaritjes.

Por kjo nuk është gjithmonë 100% e qartë; ka edhe raste më të ndërlikuara, megjithëse ka mjaft prej tyre
(për shembull, një bonus që varet nga numri i ditëve të punës në një muaj - ky është HE).

Tarifat bazë:
Nëse lloji i llogaritjes varet nga orari (që do të thotë një regjistër informacioni me data kalendarike), atëherë i referohet tarifave kryesore.

Shembull OH:
- Paga
- Diçka që llogaritet nga numri i ditëve të punës (dhe për këtë ju duhet të përdorni një orar): qoftë në periudhën e vlefshmërisë (si paga) ose në periudhën bazë

Tarifa shtesë:
Ajo që konsiderohet ose nga shuma e përllogaritur, ose koha e PUNUAR (dhe jo norma!), ose nuk varet fare - kjo është shtesë. akruale.

Kjo do të thotë: akrualet për llogaritjen e të cilave përdoret standardi kohor (ndoshta edhe fakt) është OH, dhe për të cilat nevojiten të dhëna aktuale ose asgjë fare janë DN.

Ose me fjalë të tjera:

Nëse VR përdor një standard kohor, atëherë periudha e vlefshmërisë duhet të përfshihet për VR.

*************************************************************************************************
Shtoni mundësinë për të hapur seksionin e integruar të ndihmës "Puna me libra referencë" në formën e listës së drejtorisë "Nomenklatura".

Ekzekutoni komandën në formular:

&OnClient
Ndihmë për procedurën (komandë)
OpenHelp ("v8help://1cv8/EnterprWorkingWithCatalogs");
Fundi i procedurës

Ne përcaktojmë vijën e seksionit si më poshtë:
Shkoni te informacioni i ndihmës së objektit të konfigurimit (në konfigurues), shkruani një fjalë, zgjidhni atë, shkoni te menyja Elements/Link dhe zgjidhni seksionin e dëshiruar të Ndihmës 1C, pas së cilës lidhja futet automatikisht. Duket e ndërlikuar, por në praktikë është e lehtë.

*************************************************************************************************
Zbatimi i ndërveprimit midis formave, për shembull, përzgjedhja:

1. Nga forma aktuale, hapni atë të dëshiruar duke përdorur metodën “OpenForm()”, duke kaluar strukturën me parametra si parametër të dytë (nëse është e nevojshme). Parametri i tretë mund të kalojë një lidhje në këtë formë - ThisForm.

2. Në formën e hapur, në trajtuesin “When CreatedOnServer()”, ne mund të kapim parametrat e kaluar në hapin 1 përmes “Parameters.[ParameterName]”. Formulari që nisi hapjen e këtij formulari do të jetë i aksesueshëm përmes identifikuesit "Owner" (nëse ishte, sigurisht, specifikuar në hapin 1).

Dhe më e rëndësishmja, funksionet e eksportit të formularit të pronarit do të jenë të disponueshme. Kjo do të thotë, ne mund të thërrasim funksionin e eksportit të formularit burim dhe të kalojmë diçka atje si parametër për të përpunuar përzgjedhjen. Dhe ky funksion tashmë do të plotësojë atë që nevojitet në formën origjinale. Ekziston vetëm një paralajmërim - nuk mund të kaloni një tabelë vlerash midis procedurave të klientit, por ne mund ta vendosim atë në ruajtje të përkohshme dhe thjesht të kalojmë adresën VX, dhe më pas ta nxjerrim atë nga VX.

*************************************************************************************************
Cikli jetësor i parametrave të formës

Të gjithë parametrat e transferuar në formular në momentin e hapjes së tij janë të dukshëm vetëm në procedurën "When CreateOnServer".
Pasi të krijohen, të gjithë parametrat shkatërrohen dhe nuk janë më të disponueshëm në formular.
Përjashtim është për parametrat që deklarohen në redaktuesin e formularit me atributin “Key Parameter”.
Ato përcaktojnë veçantinë e formës.
Ky parametër do të ekzistojë për aq kohë sa ekziston vetë forma.

*************************************************************************************************
Duke përdorur ndërfaqen Taxi

Gjatë zhvillimit, mund të vendosni ndërfaqen e zakonshme të menaxhuar 8.2 në vetitë e konfigurimit - kjo e bën gjithçka dukshëm më kompakte dhe më të njohur.
Kjo është veçanërisht e vërtetë nëse merrni me qira nga distanca - rezolucioni i ekranit është shumë i vogël dhe është e pamundur të bësh asgjë me ndërfaqen "taksi".
Vetëm mos harroni të vendosni përsëri "Taxi" kur të keni mbaruar!Përndryshe, ekzaminuesi do të zbresë pikë!

*************************************************************************************************

PS: E Ekzistojnë nën-detyra standarde të veçanta që përdoren në të gjitha detyrat, dhe janë këto që ju duhet të jeni në gjendje t'i zgjidhni (për shembull, shlyerja sipas grupeve, përdorimi i PVC (epo, kjo është me të vërtetë e rrallë) dhe të tjera). Dhe në të gjitha detyrat ato thjesht përsëriten (diku ka disa nën-detyra, diku tjetër, thjesht në kombinime të ndryshme). Për më tepër, ata kanë premtuar prej kohësh të nxjerrin një koleksion të ri (nëse nuk e kanë bërë tashmë), në të cilin duhet të ketë shumë më tepër probleme, domethënë nuk ka kuptim të memorizosh zgjidhje për problemet individuale, ka kuptim të mësosh se si të zgjidhni nëndetyrat standarde individuale, atëherë do të zgjidhni çdo problem.

PSS: Kolegë, nëse dikush ka ndonjë informacion tjetër të dobishëm për përgatitjen për provimin dhe kalimin e tij, ju lutemi shkruani në komente dhe ne do ta shtojmë artikullin.