1c virtuális asztal egyenlegek és forgalom. Lekérdezés Batch lapon

Úgy döntöttem, hogy hozzájárulok a nyelv azon jellemzőinek leírásához, amelyekről a fenti cikkekben nem volt szó. A cikk kezdő fejlesztőknek szól.

1. „IZ” kialakítás.

Ahhoz, hogy az adatbázisból adatokat nyerjünk, egyáltalán nem szükséges a „FROM” konstrukció használata.
Példa: Ki kell választanunk a bankokkal kapcsolatos összes információt a bankkönyvtárból.
Kérés:

SELECT Directory.Banks.*

Kijelöli az összes mezőt a Banks könyvtárból. És hasonló a kéréshez:

SELECT Banks.* FROM Directory.Banks AS Banks

2. Adatok rendelése referenciamező szerint

Ha a lekérdezési adatokat primitív típusok szerint kell rendeznünk: "String", "Number", "Date" stb., akkor mindent az "ORDER BY" konstrukcióval oldunk meg, ha referenciamező szerint kell az adatokat rendezni? A hivatkozási mező egy hivatkozás, egy egyedi azonosító, azaz. Nagyjából fogalmazva, néhány tetszőleges karakterkészlet és a szokásos sorrend olyan eredményt hozhat, amely nem teljesen elvárható. A referenciamezők megrendeléséhez az "AUTO RENDELÉS" konstrukciót használjuk. Ehhez először közvetlenül a referenciatípus szerint kell rendezni az adatokat az "ORDER BY" konstrukcióval, majd az "AUTO ORDER" konstrukcióval.

Ebben az esetben a dokumentumok esetében a rendelés a "Dátum->Szám" sorrendben történik, a kézikönyvek esetében a "Fő nézetben". Ha a rendezés nem referenciamezők alapján történik, akkor az "AUTO RENDELÉS" konstrukció használata nem javasolt.

Egyes esetekben az "AUTO ORDER" konstrukció lelassíthatja a kiválasztási folyamatot. Hasonlóképpen átírhatja a dokumentumok automatikus rendezése nélkül:

3.Referencia típusú szöveges ábrázolás beszerzése. "BEMUTATÁS" design.

Ha egy referencia típusú mezőt kell megjeleníteni, például a "Bank" mezőt, amely a "Bankok" könyvtár egy elemére mutató hivatkozás, meg kell értenie, hogy ennek a mezőnek a megjelenítésekor egy allekérdezés a " A Banks" könyvtár automatikusan végrehajtásra kerül, hogy megtekinthesse a könyvtárat. Ez lelassítja az adatkimenetet. Ennek elkerülése érdekében a kérésben a „PRRESENTATION” konstrukciót kell használni, hogy azonnal megkapja az objektum reprezentációját, majd megjelenítse azt megtekintésre.

Az adatösszeállítási rendszerben alapértelmezés szerint ez a mechanizmus használatos, de a cellákban lévő elrendezések létrehozásakor meg kell adni a referenciamező ábrázolását, és például magát a hivatkozást elhelyezni az átírásban.

4. Az adatok sablon szerinti mintavételének feltétele.

Például be kell szereznie az alkalmazottak mobiltelefonját a (8 -123-456-78-912) űrlapon. Ehhez a következő feltételt kell beállítani a kérésben:

SELECT Employee.Name, Employee.Phone AS Phone FROM Directory.Employees AS Employees WHERE Phone LIKE "_-___-___-__-__"

A „_” karakter egy szervizkarakter, és bármely karaktert helyettesít.

5. Összegek és csoportosítások egyidejű használata.


Az összegeket gyakran a csoportosításokkal együtt használják; ebben az esetben előfordulhat, hogy az összesített függvények nem adhatók meg az összegekben.

SELECT Szolgáltatásnyújtás.Organization AS Szervezet, Szolgáltatásnyújtás.Nómenklatúra AS Nómenklatúra, SUM(Szolgáltatásnyújtás.Dokumentum összege) AS Dokumentum összege FROM Dokumentum.Szolgáltatásnyújtás AS Szolgáltatásnyújtás CSOPORT Szolgáltatásnyújtás szerint.Szervezet, ellátás. of Services.Nómenklatúra EREDMÉNYEK ÁLTALÁNOS, Szervezet, Nomen klatura

Ebben az esetben a lekérdezés majdnem ugyanazt adja vissza, mint a következő lekérdezés:

SELECT Szolgáltatásnyújtás. Szervezet AS Szervezet, Szolgáltatásnyújtás.Nómenklatúra AS Nomenklatúra, Szolgáltatásnyújtás.Dokumentum mennyisége AS Dokumentum mennyisége Dokumentumból.Szolgáltatásnyújtás AS Szolgáltatásnyújtás EREDMÉNYEK ÖSSZEG (Dokumentum összege) ÁLTALÁNOS, Szervezet, Elnevezéstan

Csak az első lekérdezés fogja össze az azonos nómenklatúrával rendelkező rekordokat.

6. Mezők hivatkozásának megszüntetése.

A mezőkre ponton keresztül történő hivatkozást referenciamező dereferencia műveletnek nevezzük. Például Fizetés.Szervezet.Adminisztratív egység. Ebben az esetben a „Befizetés” bizonylat „Szervezet” hivatkozási mezőjében egy másik „Szervezetek” táblára hivatkozik, amelyben az „Adminisztrációs egység” attribútum értéke kerül leolvasásra. Fontos megérteni, hogy amikor egy ponton keresztül éri el a mezőket, a platform implicit módon létrehoz egy segédlekérdezést, és csatlakozik ezekhez a táblákhoz.

Kérés:

Képviselhető:

SELECT Payment.Link, Payment.Organization, Payment.Organization, Organizations. AdministrativeUnit FROM Document.Payment AS Payment LEFT CSATLAKOZÁS Directory.Organizations AS Szervezetek Szoftver Payment.Organization = Organizations.Link

Kompozit típusú referenciamezők hivatkozásának megszüntetésekor a keretrendszer megpróbál implicit összekapcsolást létrehozni az összes olyan táblához, amely a mezőtípus részét képezi. Ebben az esetben a lekérdezés nem lesz optimális, ha egyértelműen ismert, hogy milyen típusú mezőről van szó, akkor az ilyen mezőket típusonként kell korlátozni egy konstrukcióval EXPRESSZ().

Például létezik egy „Felosztatlan kifizetések” felhalmozási nyilvántartás, ahol több dokumentum is iktatóként működhet. Ebben az esetben helytelen a regisztrátor adatainak értékét így megszerezni:

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

korlátoznia kell az összetett mező típusát a loggerre:

SELECT EXPRESS(UnalllocatedPayments.Register AS Document.Payment).Dátum, ..... FROM RegisztrációAccumulation.UnalllocatedPayments AS UnalllocatedPayments

7. Építés "HOL"

Két tábla bal oldali összekapcsolása esetén, ha a jobb oldali táblára „WHERE” feltételt szabunk, hasonló eredményt kapunk, mint a táblák belső összekapcsolása esetén.

Példa. Minden Ügyfelet ki kell választani az Ügyféltárból, és azoknak az ügyfeleknek, akiknek van "Szervezet" = &Szervezet attribútum értékű fizetési bizonylata, jelenítse meg a "Befizetés" bizonylatot, akinek nincs, ne jelenítse meg.

A lekérdezés eredménye csak azon ügyfelek rekordjait adja vissza, akiknél a paraméterben szerepelt a szervezet szerinti fizetés, és kiszűri a többi ügyfelet. Ezért először egy ideiglenes táblában kell megkapnia az „ilyen és ehhez hasonló” szervezetre vonatkozó összes kifizetést, majd bal oldali csatlakozással csatlakoztatnia kell az „Ügyfelek” könyvtárhoz.

SELECT Payment.Link AS Fizetés, Fizetés.Részvényes AS Ügyfél HELYE a Kifizetésekhez FROM Dokumentum.Fizetés AS Fizetés WHERE Fizetés.Ág = &Branch; //////////////////////////////////////////////// //////////////////////////////////// SELECT Clients.Link AS Client, ISNULL(tPayment.Payment, "") AS Fizetés FROM Directory .Clients AS Ügyfelek BAL KAPCSOLATBAN fizetések AS topayments SZOFTVER Ügyfelek.Link = topayments.Client

Ezt az állapotot más módon is megkerülheti. Közvetlenül a két tábla kapcsolatára "WHERE" feltételt kell szabni. Példa:

SELECT Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers BAL KAPCSOLAT Document.Payment AS Fizetési szoftver (Clients.Link = Payment.Client AND Payment.Client.Name LIKE "Cukorcsomag") GROUP BY Clients.Link, Payment. Link

8. Csatlakozás beágyazott és virtuális táblákhoz

Beágyazott lekérdezések gyakran szükséges az adatok lekéréséhez valamilyen feltétel alapján. Ha ezután más táblákkal együtt használja őket, ez kritikusan lelassíthatja a lekérdezés végrehajtását.

Például egyes ügyfeleknél meg kell kapnunk az aktuális dátum szerinti Egyenleg összegét.

SELECT UnallocatedPaymentsRemains.Customer, UnallocatedPaymentsRemains.AmountRemaining FROM (SELECT Clients.Link AS Link FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Clients)) AS NestedQuery LEFT JOIN =RegiszterAccumulations.ASAllocatedPayments.UnallocatedPayments. allokáltPaymentsBalances. Vevő

Egy ilyen lekérdezés végrehajtásakor a DBMS-optimalizáló hibákat követhet el a terv kiválasztásakor, ami a lekérdezés szuboptimális végrehajtásához vezet. Két tábla összekapcsolásakor a DBMS-optimalizáló kiválaszt egy táblaösszekötő algoritmust a mindkét táblában lévő rekordok száma alapján. Ha van beágyazott lekérdezés, rendkívül nehéz meghatározni, hogy a beágyazott lekérdezés hány rekordot fog visszaadni. Ezért a beágyazott lekérdezések helyett mindig ideiglenes táblákat kell használnia. Tehát írjuk át a kérést.

SELECT Clients.Link AS Link PLACE tClients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&kliensek) ; //////////////////////////////////////////////// /////////////////////////// SELECT tClients.Link, UnallocatedPaymentsRemains.AmountRemaining, FROM tClients AS tClients LEFT JOIN RegisterAccumulations.UnallokatedPayments.Balances (, Client IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

Ebben az esetben az optimalizáló képes lesz meghatározni, hogy a tClients ideiglenes tábla hány rekordot használ, és ki tudja választani az optimális algoritmust a táblák összekapcsolásához.

Virtuális asztalok , gyakorlatilag kész adatok beszerzését teszi lehetővé a legtöbb alkalmazott feladathoz.(Az első szelete, az utolsó szelete, Maradványok, Forgások, Maradványok és Forgások) A kulcsszó itt a virtuális. Ezek a táblázatok nem fizikaiak, hanem menet közben állítja össze a rendszer, azaz. A rendszer a virtuális táblákból származó adatok fogadásakor a végső regisztertáblákból összegyűjti az adatokat, összeállítja, csoportosítja és kiadja a felhasználónak.

Azok. Amikor egy virtuális táblához csatlakozik, a kapcsolat egy részlekérdezéssel történik. Ebben az esetben a DBMS-optimalizáló nem optimális csatlakozási tervet is választhat. Ha a lekérdezés nem jön létre elég gyorsan, és a lekérdezés virtuális táblákban lévő összekapcsolásokat használ, akkor javasolt a virtuális táblákhoz való hozzáférést áthelyezni egy ideiglenes táblába, majd két ideiglenes tábla között összekapcsolni. Írjuk át az előző kérést.

SELECT Clients.Link AS Link PLACE tClients FROM Directory.Clients AS Clients INDEX BY Link WHERE
Clients.Link B (&kliensek) ; //////////////////////////////////////////////// /////////////////////////// SELECT UnallocatedPayments.AmountBalance, UnalllocatedPayments.Client AS Client PLACE egyenlegek FROM RegisterAccumulations.UnalllocatedPayments.Balances(, Client B () SELECT tClients. Link FROM tClients)) AS UnallokatedPaymentsBalances; //////////////////////////////////////////////// tClients.Link, to Remainder = tMaradékok.Client

9.A kérés eredményének ellenőrzése.

A lekérdezés eredménye üres lehet; az üres értékek ellenőrzéséhez használja a következő konstrukciót:

ResRequest = Request.Execute(); Ha resQuery.Empty() akkor Return; endIf;

Módszer Üres() módszerek előtt kell használni Választ() vagy Unload(), mivel a gyűjtemény visszakeresése időt vesz igénybe.

Senkinek sem jelent kinyilatkoztatást, hogy rendkívül nem kívánatos a lekérdezések ciklusban történő használata. Ez kritikusan befolyásolhatja egy adott funkció működési idejét. Nagyon kívánatos, hogy a kérelemben szereplő összes adatot megkapja, majd az adatokat hurokban dolgozza fel. De néha vannak olyan esetek, amikor lehetetlenné válik a kérés áthelyezése a hurkon kívülre. Ebben az esetben az optimalizálás érdekében a lekérdezés létrehozását áthelyezheti a cikluson kívülre, és a ciklusban behelyettesítheti a szükséges paramétereket és végrehajthatja a lekérdezést.

Request = Új kérés; Query.Text = "SELECT | Clients.Link, | Clients.Birthdate |FROM | Directory.Clients AS Kliensek |WHERE | Clients.Link = &kliens"; Minden sorhoz FROM TableClients Loop Query.SetParameter("Client", Client); QueryResult = Query.Execute().Select(); EndCycle;

Ez megmenti a rendszert attól, hogy a kérés szintaxisát ciklusban ellenőrizze.

11. Építés "HAVING".

A kérésekben meglehetősen ritka kialakítás. Lehetővé teszi, hogy feltételeket szabjon az összesített függvények értékeire (SZUM, MINIMUM, ÁTLAG stb.). Például csak azokat az ügyfeleket kell kiválasztania, akiknek a fizetési összege szeptemberben meghaladta a 13 000 rubelt. Ha a „WHERE” feltételt használja, először létre kell hoznia egy ideiglenes táblát vagy egy beágyazott lekérdezést, ahol a rekordokat fizetési összeg szerint csoportosítja, majd alkalmaznia kell a feltételt. A „HAVING” konstrukció segít elkerülni ezt.

KIVÁLASZTÁS Fizetés.Ügyfél, ÖSSZEG(Fizetés.Összeg) MINT ÖSSZEG A Bizonylatból.Fizetés MINT Fizetés WHERE HÓNAP(Fizetés.Dátum) = 9 CSOPORT Fizetés SZERINT.ÜGYFÉL, HOGY ÖSSZEG (Fizetési összeg) > 13000

A konstruktorban ehhez lépjen a „Feltételek” fülre, adjon hozzá egy új feltételt, és jelölje be az „Egyéni” jelölőnégyzetet. Akkor csak írj Összeg(Fizetés.Összeg) > 13000


12. NULL érték

Nem írom le itt az adatbázis háromértékű logikájának alapelveit, sok cikk van erről a témáról. Csak röviden arról, hogyan NULLA befolyásolhatja a lekérdezés eredményét. A NULL érték valójában nem érték, és az a tény, hogy az érték definiálatlan, nem ismert. Ezért minden NULL-lal végzett művelet NULL-t ad vissza, legyen az összeadás, kivonás, osztás vagy összehasonlítás. A NULL értéket nem lehet összehasonlítani a NULL értékkel, mert nem tudjuk, mivel hasonlítsuk össze. Azok. mindkét összehasonlítás a következő: NULL = NULL, NULL<>A NULL nem igaz vagy hamis, nem ismert.

Nézzünk egy példát.

Azon ügyfeleknél, akiknek nincs fizetésük, az „Aláírás” mezőt „Nincs befizetés” értékkel kell megjelenítenünk. Sőt, biztosan tudjuk, hogy vannak ilyen ügyfeleink. És hogy tükrözze a fent leírtak lényegét, tegyük ezt így.

KIVÁLASZTÁSA "Nincs kifizetés" AS Attribútum, NULL AS Dokumentum PLACE a kifizetésekhez; //////////////////////////////////////////////// ////////////////////////// KIVÁLASZT Clients.Link AS kliens, Payment.Link HOGYAN Fizetés PUT tClientPayment FROM Directory.Clients AS Clients BAL KAPCSOLAT Dokumentum. Payment AS Payment Software Clients.Link = Payment.Shareholder; //////////////////////////////////////////////// //////////////////////////////////// KIVÁLASZTÁS tClientPayment.Client FROM FROM tClientPayment AS tClientPayment BELSŐ CSATLAKOZÁS tPayment AS tTopay BY tClientPayment.Payment.

Ügyeljen a második ideiglenes táblára, a tClientPayment. A bal oldali csatlakozással kiválasztom az összes ügyfelet és az összes fizetést ezekhez az ügyfelekhez. Azon ügyfelek esetében, akiknek nincs fizetésük, a „Fizetés” mező NULL lesz. A logikát követve az első „tPayments” ideiglenes táblában 2 mezőt jelöltem ki, ezek közül az egyik NULL, a második sor „Nincs befizetés”. A harmadik táblázatban a „tClientPayment” és „tPayment” táblákat a „Fizetés” és „Dokumentum” mezők segítségével kapcsolom össze belső összekapcsolással. Tudjuk, hogy az első táblázatban a „Dokumentum” mező NULL, a másodikban pedig azok, akiknek nincs befizetésük a „Befizetés” mezőben, szintén NULL. Mit fog visszaadni nekünk egy ilyen kapcsolat? De nem ad vissza semmit. Mivel a NULL = NULL összehasonlítás nem igazodik ki.

Annak érdekében, hogy a kérés a várt eredményt adja vissza, írjuk át:

SELECT "No payments" AS Attribútum, VALUE(Document.Payment.EmptyLink) AS dokumentum PLACE to Payments; //////////////////////////////////////////////// /////////////////////////// SELECT Clients.Link AS Client, ISNULL(Fizetés.Link, ÉRTÉK(Dokumentum.Fizetés.EmptyLink )) HOGYAN Fizetés PUT tClientPayment FROM Directory.Clients AS Clients LEFT CONNECTION Document.Payment AS Fizetés BY Clients.Link = Fizetés.Részvényes; //////////////////////////////////////////////// //////////////////////////////////// KIVÁLASZTÁS tClientPayment.Client FROM FROM tClientPayment AS tClientPayment BELSŐ CSATLAKOZÁS tPayment AS tTopay BY tClientPayment.Payment.

Most a második ideiglenes táblázatban jeleztük, hogy ha a „Fizetés” mező NULL, akkor ez a mező = egy üres hivatkozás a fizetési bizonylatra. Az első táblázatban a NULL-t is helyettesítettük egy üres hivatkozással. Most a kapcsolat nem NULL mezőket tartalmaz, és a kérés a várt eredményt adja vissza.

A cikkben szereplő összes kérés azokat a helyzeteket tükrözi, amelyeket figyelembe szeretnék venni, és semmi többet. RÓL RŐL Lehet, hogy nem tévedések vagy szuboptimálisak, a lényeg, hogy a példa lényegét tükrözzék.

13. A "VÁLASZTÁSA, MIKOR...AKKOR...VÉGE" tervezés nem dokumentált jellemzője.

Abban az esetben, ha a kérésben le kell írni a „Feltételek” konstrukciót, a szabványos szintaxist használjuk:

KIVÁLASZTÁS KIVÁLASZTÁSA WHEN Users.Name = "Vasya Pupkin" THEN "Kedvenc alkalmazottunk" EGYÉB "Ezt nem tudjuk" VÉGE AS Mező1 FROM Címtárból.Users AS Users

De mi van akkor, ha például egy kérésben meg kell kapnunk a hónap nevét? Hatalmas konstrukciót írni egy kérésben csúnya és időigényes, ezért a fenti írásforma segíthet nekünk:

SELECT MONTH(US_CalculationConsumption_ScheduleTurnover.CalculationPeriod) WHEN 1 THEN "január" WHEN 2 THEN "február" WHEN 3 THEN "március" WHEN 4 THEN "április" WHEN 5 THEN "május" WHEN "június"7 THEN "Június"6 MIKOR 8. AKKOR "augusztus" MIKOR 9. MAJD "Szeptember" MIKOR 10. MAJD "Október" MIKOR 11. MAJD "November" MIKOR 12. MAJD "December" HÓNAPNAK VÉGE

Most a kialakítás kevésbé nehézkesnek tűnik, és könnyen érthető.

14. Kötegelt lekérdezés végrehajtása.


Annak érdekében, hogy ne szaporodjanak meg a kérések, létrehozhat egy nagy kérést, feloszthatja csomagokra, és dolgozhat vele.
Például a következő mezőket kell lekérnem a „Felhasználók” könyvtárból: „Születési dátum” és az egyes felhasználók számára elérhető szerepkörök. töltse fel ezt az űrlap különböző táblázatos részeire. Természetesen ezt megteheti egy kéréssel, majd ismételgetnie kell a rekordokat, vagy össze kell csuknia őket, vagy megteheti ezt:

SELECT Users.Link AS Teljes név, Felhasználók.Születési dátum, Felhasználók.Szerep PUT vtUsers FROM Directory.Users AS Users; //////////////////////////////////////////////// /////////////////////////// SELECT tueUsers.Teljes név, tueUsers.Születési dátum FROM tueUsers AS tueUsers GROUP BY tueUsers.full name, tueUsers . Születési dátum; //////////////////////////////////////////////// /////////////////////////// SELECT wUsers.Full Name, wUsers.Role FROM wUsers AS wUsers GROUP BY wUsers.Teljes név, wUsers. Dátum születésének

tPackage = Request.ExecutePackage();

TP_Születési dátum = tCsomag.Feltöltés();
TP_Roles = tPackage.Unload();

Amint látjuk, a lekérdezés kötegben is végrehajtható és az eredmény tömbként feldolgozható. Bizonyos esetekben nagyon kényelmes.

15. A kötegelt kérés feltételei

Például van egy kötegelt kérésünk, ahol először a „Név, születési dátum, kód” mezőket kapjuk meg a „Felhasználók” könyvtárból, és a „Magánszemélyek” könyvtárból szeretnénk lekérni az ezekre a mezőkre vonatkozó feltételeket tartalmazó rekordokat.

SELECT Users.Individual.Name AS Név, Users.Individual.Date of Birth AS Születési dátum, Users.Individual.Code AS Code PLACE vtUsers FROM Directory.Users AS Users; //////////////////////////////////////////////// //////////////////////////////////////////////////////////////.

Ilyen feltételeket írhat elő:

WHERE Individuals.Code IN (SELECT vtUsers.Code FROM vtUsers) AND Individuals.Name IN (SELECT vtUsers.Code FROM vtUsers) AND Individuals.BirthDate IN (SELECT vtUsers.DateBirth FROM tvUsers)

És megteheted így:

WHERE (Individuals.Code, Individuals.Name, Individuals.Date of Birth) IN (SELECT tueUsers.Code, tueUsers.Name, tueUsers.Date of Birth FROM tueUsers)

Sőt, a rend fenntartása is szükséges.

16. A lekérdezéskészítő meghívása a kötegelt kérés „feltételére”.

Ha feltételt kell előírni, mint a fenti példában, akkor elfelejtheti, hogyan hívják ezt vagy azt a mezőt a virtuális táblában.
Például a "Születési dátum" mezőben feltételt kell szabni, és a virtuális táblázatban ennek a mezőnek a neve "Adós születési dátuma", és ha elfelejti a nevet, akkor ki kell lépnie a feltétel szerkesztéséből anélkül, hogy mentse, és nézze meg a mező nevét. Ennek elkerülése érdekében használhatja a következő technikát.

A „B” konstrukció után zárójeleket kell tenni, és a zárójelek között üres helyet (szóközt) kell hagyni, kiválasztani ezt a szóközt és meghívni a lekérdezés konstruktorát. A tervező hozzáfér a kötegelt lekérdezés összes táblájához. A technika virtuális regisztertáblákon és a „Feltételek” fülön is működik. Ez utóbbi esetben jelölje be a "P (tetszőleges feltétel)" négyzetet, és lépjen be az "F4" szerkesztési módba.

A lekérdezéseket gyakran menet közben találták ki, és egyszerűen csak illusztrálják azokat a „technikákat”, amelyeken gondolkodtam.

Meg akartam nézni az indexek használatát a lekérdezésekben, de ez egy nagyon tág téma. Felteszem egy külön cikkbe, vagy később hozzáadom ide.

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

Használt könyvek:
Lekérdezési nyelv "1C:Enterprise 8" - E.Yu. Khrustaleva
Szakmai fejlődés az 1C:Enterprise 8 rendszerben."

Valós problémák esetén a minták rendszerezése során az esetek túlnyomó többségében meghatározott szempontok szerint történik az adatkiválasztás.

Abban az esetben, ha a kiválasztás valódi táblázatból történik, nem merül fel nehézség. Az adatok feldolgozása teljesen triviálisan történik:

Abban az esetben, ha a lekérdezés forrása egy virtuális tábla, a helyzet némileg bonyolultabbá válik.


A lekérdezési nyelv kétféleképpen teszi lehetővé a virtuális táblák kijelölésének feltételét: a WHERE záradékban és a virtuális tábla paramétereinek használatával. Mindkét módszer ugyanarra az eredményre vezet (néhány konkrét eset kivételével), de ennek ellenére közel sem egyenértékűek.

Azt már tudjuk, hogy a virtuális táblákat virtuálisnak nevezzük, mert valójában nincsenek benne az adatbázisban. Csak abban a pillanatban jönnek létre, amikor kérik őket. Ennek ellenére nekünk (vagyis a lekérdezést íróknak) kényelmes, ha a virtuális táblákat valódinak tekintjük. Mi fog történni az 1C Enterprise 8 rendszerben, amikor az általunk lefordított lekérdezés továbbra is hozzáfér a virtuális táblához?

Első lépésben a rendszer egy virtuális táblát készít. A második lépésben az eredményül kapott táblából azokat a rekordokat választjuk ki, amelyek megfelelnek a WHERE záradékban meghatározott feltételnek:
Jól látható, hogy a végső minta nem tartalmazza a virtuális tábla (és így az adatbázis) összes rekordját, hanem csak azokat, amelyek megfelelnek az adott feltételnek. A fennmaradó rekordokat pedig egyszerűen kizárják az eredményből.

Így a rendszer nem csak haszontalan, hanem duplán haszontalan munkát fog végezni! Először a szükségtelen adatok alapján egy virtuális tábla felépítésére fordítják az erőforrásokat (az ábrán „A és B adatterületként” vannak jelölve), majd ezen adatok kiszűrése a végeredményből.

Lehetséges-e azonnal, a virtuális tábla létrehozásának szakaszában abbahagyni a felesleges adatok használatát? Kiderül, hogy lehetséges. A virtuális tábla paramétereit pontosan erre tervezték:

Egy virtuális tábla paraméterezésével azonnal korlátozzuk a lekérdezés által feldolgozott adatok mennyiségét.

Mi a különbség a virtuális tábla "Hozzáadás módja" paraméter értékei között?
Ha az Addition Method beállítása "mozgások", akkor csak azok az időszakok kerülnek visszaadásra, amelyekben mozgások voltak. Ha a "Mozgások és periódushatárok" be van állítva, akkor a fenti mozgásokhoz 2 rekord ad hozzá: mozgások a VT paraméterekben megadott periódus elején és végén. A „Regisztrátor” mező üres lesz ehhez a 2 rekordhoz.

Az oldalról vett információ

Valós problémák esetén a minták rendszerezése során az esetek túlnyomó többségében meghatározott szempontok szerint történik az adatkiválasztás.

Abban az esetben, ha a kiválasztás valódi táblázatból történik, nem merül fel nehézség. Az adatok feldolgozása teljesen triviálisan történik:

Abban az esetben, ha a lekérdezés forrása egy virtuális tábla, a helyzet némileg bonyolultabbá válik.

A lekérdezési nyelv kétféleképpen teszi lehetővé a virtuális táblák kijelölésének feltételét: a WHERE záradékban és a virtuális tábla paramétereinek használatával. Mindkét módszer ugyanarra az eredményre vezet (néhány konkrét eset kivételével), de ennek ellenére közel sem egyenértékűek.

Azt már tudjuk, hogy a virtuális táblákat virtuálisnak nevezzük, mert valójában nincsenek benne az adatbázisban. Csak abban a pillanatban jönnek létre, amikor kérik őket. Ennek ellenére nekünk (vagyis a lekérdezést íróknak) kényelmes, ha a virtuális táblákat valódinak tekintjük. Mi fog történni az 1C Enterprise 8 rendszerben, amikor az általunk lefordított lekérdezés továbbra is hozzáfér a virtuális táblához?

Első lépésben a rendszer egy virtuális táblát készít. A második lépésben az eredményül kapott táblából azokat a rekordokat választjuk ki, amelyek megfelelnek a WHERE záradékban meghatározott feltételnek:


Jól látható, hogy a végső minta nem tartalmazza a virtuális tábla (és így az adatbázis) összes rekordját, hanem csak azokat, amelyek megfelelnek az adott feltételnek. A fennmaradó rekordokat pedig egyszerűen kizárják az eredményből.

Így a rendszer nem csak haszontalan, hanem duplán haszontalan munkát fog végezni! Először a szükségtelen adatok alapján egy virtuális tábla felépítésére fordítják az erőforrásokat (az ábrán „A és B adatterületként” vannak jelölve), majd ezen adatok kiszűrése a végeredményből.

Lehetséges-e azonnal, a virtuális tábla létrehozásának szakaszában abbahagyni a felesleges adatok használatát? Kiderül, hogy lehetséges. A virtuális tábla paramétereit pontosan erre tervezték:


Egy virtuális tábla paraméterezésével azonnal korlátozzuk a lekérdezés által feldolgozott adatok mennyiségét.

Mi a különbség a virtuális tábla "Hozzáadás módja" paraméter értékei között?
Ha az Addition Method beállítása "mozgások", akkor csak azok az időszakok kerülnek visszaadásra, amelyekben mozgások voltak. Ha a "Mozgások és periódushatárok" be van állítva, akkor a fenti mozgásokhoz 2 rekord ad hozzá: mozgások a VT paraméterekben megadott periódus elején és végén. A „Regisztrátor” mező üres lesz ehhez a 2 rekordhoz.

Hívjuk meg a PriceSliceLast virtuális tábla paramétereinek bevitelére szolgáló párbeszédablakot, és jelezzük, hogy a ReportDate paraméterben a periódus átadásra kerül. Ehhez válassza ki ezt a táblázatot a Táblázatok listában, és kattintson a Virtuális tábla beállításai gombra. Ezután válassza ki a következő mezőket a táblázatokból:

    SprNómenklatúra. Szülő,

    Árak Slice of Latest.Price.

Bal oldali asztal csatlakozás

- A könyvjelzőn Kapcsolatok: a Linkfeltétel mezőben, hogy az információs regiszter Nómenklatúra dimenziójának értékének meg kell egyeznie a Nomenclature könyvtárelemre való hivatkozással. Szintén törölje a jelet az Összes jelölőnégyzetből a regisztertáblánál, és jelölje be a keresési táblánál, ezzel beállítva a kapcsolat típusát bal oldali kapcsolatként a keresési táblához:

Rizs. 13.15. Táblázatok közötti kapcsolat egy lekérdezésben

- A könyvjelzőn Körülményekállítsuk be a feltételt az elemek kiválasztásához a Nomenclature könyvtárból - a kiválasztott elemeknek meg kell felelniük a Nomenclature Type kérési paraméterben átadott nómenklatúra típusának:

Rizs. 13.16. Az elemek kiválasztásának feltételei

- A könyvjelzőn Szakszervezetek/álnevek: adja meg a Parent = Service Group és a Link = Service mező álnevét. - Kattintson az OK gombra-

Ezt követően módosítani kell az adatelrendezési sémát, ehhez a fülön Erőforrások, kattintson a gombra add hozzáés válassz egy erőforrást - Ár

- A könyvjelzőn Lehetőségekállítsa be a Nomenclature Type paraméter értékét - Enumeration.Nomenclature Types.Service. Ezenkívül eltávolítjuk a ReportDate paraméter elérhetőségi korlátozását. A paraméter típusa mezőben állítsa be a dátum összetételét - Dátum. Ezzel szemben a Period paraméternél rendelkezésre állási korlátozást állítunk be:

Rizs. 13.17. Elrendezési séma opciók

Beállítások

- Menjünk a könyvjelzőhöz Beállítások: Hozzon létre egy csoportosítást a Szolgáltatáscsoport mező alapján, megadva a Hierarchia csoportosítási típust.

A következő hierarchiatípusok léteznek a jelentéscsoportosításokhoz: Hierarchia nélkül – csak a nem hierarchikus rekordok jelennek meg a csoportosításban. Hierarchia – a nem hierarchikus és a hierarchikus rekordok is megjelennek a csoportosításban. Csak hierarchia – csak a hierarchikus (szülő) rekordok jelennek meg a csoportosításban. Ezen a csoporton belül létrehozunk egy másikat a csoport mező megadása nélkül. Az allapon Kiválasztott mezők: adja meg a Service és Price kimeneti mezőket:

Rizs. 13.18. Jelentés szerkezete és mezői

Az allapon Egyéb beállításokat a következő lépéseket hajtjuk végre:

Rizs. 13.19. Beállítások a "Szolgáltatáscsoport" csoportosítás általános összegeinek megjelenítéséhez

Rizs. 13.20. Az eredmények beállítása és megjelenítése globális jelentéshez

Végül vegyük be a Jelentés dátuma paramétert a felhasználói beállításokba, és állítsuk a Szerkesztési módot Gyors hozzáférésre. Zárjuk be az adatösszetételi sématervezőt, és a Szolgáltatáslista objektum szerkesztési ablakában lépjen az Alrendszerek fülre. A konfigurációs alrendszerek listájában vegye figyelembe a Szolgáltatásnyújtás és a Számviteli alrendszereket.

    1C: Enterprise módban

Indítsuk el az 1C:Enterprise programot hibakeresési módban, és mindenekelőtt nyissuk meg az Prices időszakos regisztert. Ezután teszteljük a jelentést.

Ezt a jelentést példaként felhasználva megvizsgáltuk, hogy az adatösszeállítási rendszer hogyan szerzi be a legfrissebb értékeket a periodikus információs regiszterből, és hogyan jelennek meg a címtárhierarchia szerinti csoportosítások.

Ha a kiadványom hasznos az Ön számára, ne felejtsen el pluszt adni :-)

Itt van egy rubrikátor a gyűjtemény összes feladatához(egy oldal, amely linkeket tartalmaz az egyes feladatok fórumszálaira)
http://chistov.spb.ru/forum/16-969-1

Nos, most az én fejlesztéseim és feljegyzéseim, amiket az előkészítés során készítettem.
Igyekszem a lehető legkevesebbet ismételni a fent említett kettővel utolsó kiadványok.

Tehát kezdjük:


Ha távolról veszi le, akkor a vizsga végén két objektumnak kell lennie az asztalon:

1. Az információs bázis (dt fájl) végső feltöltése
2. Magyarázó megjegyzés

Ne legyen semmi más, ne legyenek köztes másolatok stb.

Mindenképpen írjon magyarázó megjegyzést!
Homályosan megfogalmazott feladat esetén mindenképpen írd oda, hogy pontosan ilyen és ilyen megoldási lehetőséget választottál.
Ezenkívül a kód kulcsfontosságú helyein jobb, ha rövid megjegyzéseket hagyunk, fanatizmus nélkül, de ahol a vizsgáztatónak kérdései vannak, jobb írni.

De erről a vizsga előtt el kell olvasnia az utasításokban.
Csak jobb előre tudni)


Az „és” karakter használata a lekérdezésekben.

Időnként gyorsabb egy további billentyűzetről gépelni, mint ide-oda váltani az elrendezést, így időt takaríthat meg
& = Alt+38

*************************************************************************************************
A TimePoint() használata a lekérdezésekben

A felhalmozási és könyvelési nyilvántartások lekérdezésekor nem a bizonylat dátumát kell virtuális tábla (időszak) paraméterként használni, hanem a Moment paramétert, amely a kódban az alábbiak szerint van definiálva:

Pillanat = ?(Passing Mode = Dokumentum feladási mód. Működési, Nem definiált, Időpillanat());

*************************************************************************************************
Nyilvántartásonkénti bizonylatmozgások generálásakor a könyvelési feldolgozási eljárás legelején szükséges az aktuális bizonylat nyilvántartás szerinti mozgásának törlése.

A kód:

Movement.RegisterName.Write = Igaz; Movements.RegisterName.Clear();

Lehetséges, hogy a folyamat során szükség lesz az ebből a nyilvántartásból származó rekordok elemzésére.
Tehát, hogy a jelenlegi rekordok (régiek, a dokumentum megváltoztatása előtti) elemzésekor biztosan ne kerüljenek bele a mintába, a fenti két sorhoz hozzáadhat még egy sort:

Movement.RegisterName.Write();

Vagy a rekordok elemzésekor kifejezetten jelöljön meg egy határt, amely nem tartalmazza az aktuális dokumentum időpontját.

De mindenhol egyszerűen jeleztem ennek a három sornak a felépítését:

Movement.RegisterName.Write = Igaz; Movements.RegisterName.Clear(); Movement.RegisterName.Write();

*************************************************************************************************
Az adatok blokkolásának két módja van, a választás a használt módszertől függ - régi vagy új:

1) Rendszeres ellenőrzött zárolás, régi dokumentumfeldolgozási módszer (Data Blocking objektum)

Állítsa be, ha az egyenlegeket először ellenőrzi, majd leírja.
Abban az esetben, ha valamilyen információra van szükségünk a nyilvántartásból a mozgalom létrehozásához.


Példa:

A bizonylatban - mennyiség, a nyilvántartásban - mennyiség és összeg (költség)
Tehát a bizonylatból tudjuk az áru mennyiségét - mennyit írunk le, de a költséget - nem.
Ezt csak a nyilvántartásból tudjuk megtudni, de annak érdekében, hogy az egyenlegek átvételének pillanata és a mozgások rögzítésének pillanata között senki ne változtassa meg a regisztert, még az egyenlegek leolvasása előtt zárolni kell a regisztert.
Tehát ebben az esetben a Data Locking objektum kerül felhasználásra. Létrehozásakor pedig helyesebb feltüntetni, hogy milyen méretekkel zároljuk a regisztert (például esetünkben - csak a bizonylatban megadott tétellel) - hogy ne legyenek felesleges zárak, és egy másik felhasználó eladhasson egy másikat. tétel.


1. Állítson be zárolást a Data Lock objektum segítségével
2. Olvasd el a többit
3. Ellenőrizzük a leírás lehetőségét
4. Mozgásokat hozunk létre, például árut írunk le
5. A bizonylat feladása után a zárolás automatikusan megszűnik (a zárolás a könyvelési tranzakció részeként érvényes, és a rendszer automatikusan megszünteti). Vagyis nincs szükség az objektum speciális feloldására.

2) Új módszertan a dokumentumok feldolgozásához (a LockForChange tulajdonság használatával = igaz)

Akkor használatos, ha nincs szükségünk információra a regiszterekből a mozgások kialakításához, és leírásakor ellenőrizhetjük, hogy negatívba mentünk-e, ha a rögzítés után megnézzük a regiszter egyenlegeit és azt látjuk, hogy negatívak vannak. . Ebben az esetben megértjük, hogy túl sokat írtunk le, és megszakítjuk a leírási műveletet.

Példa:
Tekintsük egy termék értékesítésének működését.
A bizonylatban - mennyiség, a nyilvántartásban - csak mennyiség
Tehát a dokumentumból tudjuk az áruk mennyiségét.
A bizonylatban megadott mennyiséggel mozgásokat alakítunk ki és rögzítünk. Ezután elolvassuk a nyilvántartást, megnézzük az egyenlegeket, és elemezzük, hogy vannak-e negatívak. Ha van, jelenítsen meg egy hibát, és állítsa vissza a Refusal = True értéket.

Vagyis a sorrend a következő:
1. A regiszterben való mozgáshoz állítsa be a BlockForChange tulajdonságot = True
2. Mozgásokat hozunk létre - írjuk le az árut
3. Rögzítse a mozdulatokat
4. Olvassa el a nyilvántartást, és győződjön meg arról, hogy nincs negatív egyenleg. Ha van, akkor kiírták a felesleget, ha nem, akkor minden rendben.

Tehát ebben az esetben nem kell jelezni, hogy mely méretekkel kell blokkolnunk a regisztert.
Egyszerűen állítsuk a BlockForChange tulajdonságot True értékre, mielőtt rögzítjük a mozgásainkat, létrehozzuk a mozgásokat és rögzítjük.
A rendszer maga blokkolja a regisztert a rögzítés időpontjában a szükséges méréseknek megfelelően, miután elemezte a rögzítetteket.
A befejezést követően a blokkolás megszűnik.

Ez a lehetőség (a második) egyszerűbb, „új dokumentumfeldolgozási módszertannak” hívják, és az 1C javasolja ennek használatát, ha lehetséges, és pontokat von le, ha az első opciót használják, de bizonyos esetekben egyszerűen nem alkalmazható, és az első opciót a Data Locking objektumot használjuk (lásd a fenti példát).

Azt is megjegyzem, hogy a választott módszertől függetlenül a mozdulatokat meg kell tisztítani, mielőtt velük dolgozna (lásd a korábbi tanácsokat)

*************************************************************************************************
Adatblokkolás (1. blokkolási mód a fenti leírásból)

Ellenőrzött zárolásra van szükség ott, ahol adatokat olvasnak be és ezek alapján mozgásokat végeznek
A kezelt zárolási kód beszerzésének leggyorsabb módja a „Data Locking” beírása, a Syntax Assistant felhívása és a példakód másolása onnan. Ezután egyszerűen módosítsa a regiszter nevére és a méretekre.

Valahogy így néz ki:

Lock = NewDataLock; Locking Element = Locking.Add("Akkumulációs regiszter.GoodsInWarehouses"); LockElement.Mode = DataLockMode.Exclusive; BlockingElement.DataSource = PM; Záróelem.UseFromDataSource("Nómenklatúra", "Nómenklatúra"); Lock.Lock();

*************************************************************************************************
Jobb, ha a dokumentumok táblázatos részét egyszerűen „TC”-nek nevezzük.

A dokumentumok 99%-ában csak egy táblázatos rész található. A táblázatos részek ilyen egységes elnevezése nagyban segít időt takarítani, mivel:
1) Nagyon rövid - írjon gyorsan
2) Ugyanez minden dokumentumra vonatkozik, nem kell emlékeznie arra, hogy mi a neve a kód írásakor

*************************************************************************************************
A lekérdezés eredményének ürességét ellenőrizni kell, mielőtt lekéri vagy feltölti a műszaki specifikációba.

Általában minden feladatnál mintavételezést alkalmaztam.

A mintavételezés a teljesítmény szempontjából optimálisabb a rendszer számára, mivel csak az adatok kiolvasására „élezett” (ellentétben a TK-val).

De mindenesetre a Select() metódus előtt érdemes ellenőrizni, hogy a lekérdezés eredménye üres-e, ez tovább csökkenti a rendszer terhelését.

Eredmény = Query.Run(); Ha nem Result.Empty() akkor Select = Result.Select(TravelQueryResult.ByGrouping); ... EndIf;

És arra az esetre, ha csak egy értéket kell kapnunk a kérésből
(például csak az idei évre megállapított számviteli politika szerinti leírási módszer):

Eredmény = Query.Run(); Ha nem Result.Empty() akkor Select = Eredmény.Select(); Selection.Next(); Költségleírási módszer = Sample.Cost Write-Off Method; endIf;

*************************************************************************************************
Számviteli feladat "Művelet" dokumentuma

Számviteli feladatokhoz Műveleti bizonylatot kell készíteni.

Teljesen letiltjuk a könyvelést (a „Közzététel = Megtagadás”) tulajdonságokban, jelezzük, hogy mozgást végez a könyvelési nyilvántartásban, és ráhúzzuk a mozgásokat az űrlapra.

*************************************************************************************************
A dokumentumok gyors feldolgozása:

Kell, hogy legyen beleértve:
Üzemeltetésben és számvitelben. a bizonylatok elszámolását engedélyezni kell (kivéve a „Művelet” bizonylatot, lásd alább).

Kell, hogy legyen kikapcsolt:
számítási feladatoknál nincs értelme bérszámfejtési bizonylatnak.

A "Művelet" dokumentumnál a könyvelést teljesen le kell tiltani (a "Közzététel = tiltás" dokumentum tulajdonságainál),
mivel ír, egyszerűen ír adatokat közvetlenül a regiszterbe íráskor.

*************************************************************************************************
Feltétel a "Vagy a megadott nómenklatúra, vagy bármely, ha nincs megadva" formátumú kérelemben

A lekérdezések során a következő feladattal találkozunk: például ki kell választani egy adott nómenklatúrával rendelkező dokumentumokat, vagy az összes dokumentumot, ha a nómenklatúra nincs megadva.
Ezt magában a kérésben a következő feltétel oldja meg:

Nomenklatúra = &Nómenklatúra VAGY &Nómenklatúra = Érték(Könyvtár.Nómenklatúra.Üres hivatkozás)

De optimálisabb és helyesebb lenne ezt a feltételt átalakítani (köszi yukon):


Request.Text = Request.Text + "WHERE Nomenclature = &Nómenklatúra";

endIf;

A lekérdezési objektum modell megjelenésével a 8.3.5-ben lehetővé válik egy feltétel biztonságosabb hozzáadása:

Ha ValueFilled(Nómenklatúra) Akkor
Query1.Selection.Add("Elem = &Nómenklatúra");
Request.SetParameter("Nómenklatúra", Nomenklatúra);
endIf;

*************************************************************************************************
Táblázatok összekapcsolása a lekérdezésekben:

Az összes rekord száma nem attól függ, hogy az egyesített tábla mezője megjelenik-e, csak a konfigurált kapcsolatoktól függ.
Vagyis előfordulhat, hogy a csatolt táblázat mezője nem jelenik meg.

Ha feltétel nélkül szeretne táblázatot csatolni, akkor a feltételek fülre egyszerűen írja be az „IGAZ” feltételt.
Ebben az esetben a táblázat pontosan össze lesz kapcsolva.

*************************************************************************************************
A jellemző típusok (PVC) tervének felhasználásával:

1. Használja az objektumok jellemzőinek leírására szolgáló mechanizmusként.

1.1. PVC-t készítünk. Ezek a jellemzők típusai (például szín, méret, maximális sebesség stb.). A beállításokban válassza ki a jellemző értékek összes lehetséges típusát, és ha szükséges, hozza létre az objektumot az 1.2 pontból, és jelezze is a beállításokban.

1.2. A PVC további értékeihez létrehozunk egy alkönyvtárat a További jellemzők értékei (vagy egyszerűen a jellemzők értékei).
A jellemzőket tárolja, ha azok nincsenek a meglévő könyvtárakban. Előfordulhat, hogy nem hozzuk létre, ha az összes szükséges tulajdonság a meglévő könyvtárakban található, vagy ezek az értékek elemi adattípusokkal reprezentálhatók. A PVC beállításoknál jelezzük, hogy ezt a könyvtárat további célokra használjuk fel. jellemző értékek.

1.3. Létrehozunk egy információs regisztert, amely tulajdonképpen három objektumot köt össze:
- Az objektum, amelyhez a jellemzők mechanizmusát kapcsoljuk
- Típusjellemzők (PVC típus)
- Jellemzők értéke (típus - jellemző, ez egy új típus, amely a PVC létrehozása után jelent meg a rendszerben
és az összes lehetséges adattípus leírása, amelyet egy jellemző érték felvehet).
Az információs regiszterben feltüntetjük, hogy a Jellemző típus a Tulajdonos érték tulajdonosa (link a kiválasztási paraméterhez), valamint a Jellemző érték típuskapcsolata, ismét a Jellemző típusból.

További jellemző, hogy minden létrehozott jellemzőtípushoz megadhatjuk a jellemző érték típusát, ha nincs szükségünk minden lehetséges típusra a jellemző értékének leírásához.

2. PVC használata a számviteli nyilvántartás alkonto mechanizmusának létrehozásához .

2.1. PVC TypesSubconto-t készítünk.

2.2. Létrehozunk egy ValuesSubConto alárendelt könyvtárat (a jellemzőkhöz hasonlóan ez is tartalmazni fogja a subconto értékeket, ha más könyvtárakban nincs ilyen).

2.3. A kommunikáció számlatükör segítségével történik.

*************************************************************************************************
Számviteli nyilvántartás forrásai:

Összeg – mérleg,
Mennyiség - mérlegen kívüli és a számviteli jellemzőhöz kapcsolódó mennyiségi

*************************************************************************************************
Virtuális számviteli nyilvántartás táblák:

Forgalom: egyetlen számla forgalma
ForgalomDtKt: tetszőleges két számla közötti forgalom, azaz az időszakra vonatkozó összes tranzakció.

*************************************************************************************************
Pénznem elszámolás a számviteli nyilvántartásokban - hogyan kell végrehajtani:

A számlatükörben létrehozunk egy „valuta” elszámolási attribútumot.
A számviteli nyilvántartásban ezenkívül létrehozzuk:
- Pénznem dimenzió (üres értékek tiltása, mérlegen kívüli, számviteli attribútum - pénznem)
- erőforrás CurrencyAmount (mérlegen kívüli, számviteli attribútum - pénznem, az összeget pénznemben, azaz például 100 dollárban tárolja)
Minden.

Így a regiszter szerkezete a következő:

Méretek:
- Pénznem
Erőforrások
- Mennyiség
- Összeg (összeg rubelben)
- CurrencyAmount (összeg pénznemben)

Így a valutaszámítás csak a hagyományos könyvelés finomítása a Belarusz Köztársaságban, nem változtat például az erőforrás Összeg lényegén.
(ott szokás szerint rubelben van az összeg, függetlenül attól, hogy a számla devizában van-e vagy sem).
És ha a Pénznem elszámolási funkció ki van kapcsolva a számlán, akkor ez a Fehérorosz Köztársaság szokásos struktúrája (források - csak mennyiség és összeg).

*************************************************************************************************
Amikor egy virtuális tábla paramétereit úgy állítjuk be, hogy az utóbbiból egy szeletet kapjunk, akkor a dimenziókra szabunk feltételeket, nem pedig az erőforrásokra.

Ellenkező esetben nem a legfrissebbek szeletét kapjuk, hanem az utolsó rekordot a megadott erőforrás értékkel - lehet, hogy nem az utolsó a dimenziókészletben

*************************************************************************************************
Az erőforrás jelentése és részletei a számítási regiszterben

A számítási regiszterekben az erőforrás létrehozása lehetővé teszi annak fogadását, amikor a bázist ezzel a regiszterrel számítjuk ki.
És még az adott időszak arányában is újraszámításra kerül az erőforrás érték (ha a bázisidőszak nem esik egybe a nyilvántartás periodicitásával).

Az attribútum értéke pedig csak a számítási regiszter valós táblázatában érhető el, virtuális táblákban nem.

*************************************************************************************************
Jelölje be az "Alap" jelölőnégyzetet a számítási regiszter dimenzió tulajdonságainál
Ez azt jelenti, hogy a jövőben ebből a dimenzióból bázist kapunk, és ez a mező értékeinek további indexelésére szolgál.

*************************************************************************************************
A szabadság érvényességi idejének havi bontása a nyilvántartási bejegyzések rögzítésekor,
ha a dokumentumban egy sorban a szabadság van megadva egyszerre több hónapra egy sorban:

Aktuális hónap kezdődátuma = Hónap kezdete(TexLineMainAccruals.ActionPeriodStart); CurrentMonthEndDate = EndHónap(TexLineMainAccruals.ActionPeriodStart); Current Month = dátum; WhileDateStartCurrentMonth<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;

*************************************************************************************************
Gantt-diagram készítése:

Az űrlapon elhelyezünk egy „Gantt-diagram” típusú elemet, nevezzük DG-nek, majd létrehozzuk a „Létrehozás” parancsot, és beírjuk a következőt az űrlap modulba:

&OnClient eljárás Generate(Command) GenerateOnServer(); Az eljárás vége &A kiszolgálón eljárás GenerateOn Server() DG.Clear(); DG.Update = Hamis; Request = New Request("SELECT |BasicAccrualsActualActionPeriod.Employee, |BasicAcrualsActualActionPeriod.CalculationType, |BasicAccrualsActualActionPeriod.ActionPeriodStart AS ActionPeriodStartAccruods. AS PeriodActionsEnd |FROM |Számítási Regisztráció.BasicAccruals.ActualPeriodActions AS BasicAcrualsActualPeriodActions |HOL |BasicAccrualsActualPeriodActions.PeriodActions BETWEEN &StartDate ÉS &EndDate "); Query.SetParameter("StartDate", Period.StartDate); Request.SetParameter("EndDate", Period.EndDate); Select = Query.Run().Select(); Míg Selection.Next() Loop Point = DG.SetPoint(Selection.Employee); Series = DG.SetSeries(Selection.CalculationType); Érték = DG.GetÉrték(pont, sorozat); Intervallum = Value.Add(); Interval.Start = Sample.PeriodActionStart; Interval.End = Sample.ActionPeriodEnd; EndCycle; DG.Update = igaz; Az eljárás vége

Igazából nekünk itt csak a ciklusban lévő kód a fontos, a többi csak segédlet, csak ennek a részfeladatnak a teljes megvalósítását adtam meg.
A kérelemben számunkra fontos, hogy szerepeljen munkavállaló, fizetési mód, az időszak kezdő és záró dátuma.
A kód valójában nagyon egyszerű, könnyen megjegyezhető, ne ijedjen meg, ha nehézkesnek tűnik

*************************************************************************************************
A „visszafordítási” bejegyzések feldolgozása számítási feladatokban:

A tranzakciófeldolgozási eljárásban (objektummodul) minden mozgást kialakítunk, majd ha más időszakokban vannak rekordok, akkor ezeket így kapjuk meg.
(a rendszer automatikusan generálja őket – segít nekünk):

Addition Records = Movements.MainAccruals.GetAddition(); // Nem kell rögzíteni a mozgásokat a kiegészítéshez

Minden technikai sorhoz a rekord-kiegészítési ciklusból
Record = Movements.MainAccruals.Add();
FillPropertyValues(Record, TechString);
Record.RegistrationPeriod = TechString.RegistrationPeriodReversal;
Record.ActionPeriodStart = TechString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = TechString.ActionPeriodEndReversal;
A ciklus vége

És a rekordok kiszámításakor illesszen be ellenőrzéseket:

Ha TechMotion.Reversal Akkor
CurrentMovement.Sum = - CurrentMovement.Amount;
endIf;

*************************************************************************************************
Hogyan határozható meg a számítási feladatokban, hogy mi szerepel a fő passzív elhatárolásokban és mi szerepel a további elhatárolásokban.

De ez nem mindig 100%-ig egyértelmű, vannak bonyolultabb esetek is, bár van belőlük jó néhány
(például egy bónusz, amely egy hónapban a munkanapok számától függ - ez a HE).

Alapdíjak:
Ha a számítás típusa ütemezéstől függ (értsd: naptári dátumokkal ellátott információs nyilvántartás), akkor az a fő díjakra vonatkozik.

OH példa:
- Fizetés
- Valami, amit a munkanapok számából számolnak (és ehhez ütemezést kell használni): vagy érvényességi időszakban (pl. fizetés), vagy bázisidőszakban

További díjak:
Mi számít a felhalmozott összegből, vagy a MUNKAVÉGZÉSI időből (és nem a norma!), vagy egyáltalán nem függ - ez további. időbeli elhatárolások.

Azaz: az az időbeli elhatárolás, amelynek kiszámításához az időszabványt használjuk (talán tény is), az OH, és amelyhez tényleges adatok vagy semmi sem kell, a DN.

Vagy más szóval:

Ha a VR időszabványt használ, akkor a VR érvényességi idejét bele kell foglalni.

*************************************************************************************************
Adja hozzá a „Nómenklatúra” könyvtár lista formájában a beépített súgó megnyitásának lehetőségét, a „Munkakönyvek használata” című részt.

Futtassa a parancsot az űrlapon:

&OnClient
Eljárás súgó (parancs)
OpenHelp("v8help://1cv8/EnterprWorkingWithCatalogs");
Az eljárás vége

A metszetvonalat a következőképpen határozzuk meg:
Menjen a konfigurációs objektum súgó információihoz (a konfigurátorban), írjon be egy szót, jelölje ki, lépjen az Elemek/Hivatkozás menübe, és válassza ki az 1C Súgó kívánt részét, amely után a hivatkozás automatikusan beszúrásra kerül. Bonyolultnak tűnik, de a gyakorlatban egyszerű.

*************************************************************************************************
Az űrlapok közötti interakció megvalósítása, például kijelölés:

1. Az aktuális űrlapról nyissa meg a kívántat az „OpenForm()” metódussal, második paraméterként adjuk át a paraméterekkel ellátott struktúrát (ha szükséges). A harmadik paraméter átadhat egy hivatkozást ehhez az űrlaphoz - ThisForm.

2. A megnyílt formában a „When CreatedOnServer()” kezelőben az 1. lépésben átadott paramétereket a „Parameters.[ParameterName]”-on keresztül tudjuk elkapni. Az űrlap megnyitását kezdeményező űrlap a „Tulajdonos” azonosítón keresztül lesz elérhető (amennyiben természetesen az 1. lépésben megadták).

És ami a legfontosabb, a tulajdonos űrlap export funkciói elérhetőek lesznek. Vagyis meghívhatjuk a forrás űrlap export függvényét, és átadhatunk ott valamit paraméterként a kijelölés feldolgozásához. Ez a függvény pedig már az eredeti formában kitölti a szükségeset. Csak egy figyelmeztetés van: nem adhat át értéktáblázatot az ügyféleljárások között, de elhelyezhetjük ideiglenes tárhelyen, és egyszerűen átadhatjuk a VX-címet, majd kibonthatjuk a VX-ből.

*************************************************************************************************
Az űrlapparaméterek életciklusa

Az űrlapra a megnyitásakor átvitt összes paraméter csak a „When CreateOnServer” eljárásban látható.
A létrehozás után az összes paraméter megsemmisül, és már nem érhető el az űrlapon.
Ez alól kivételt képeznek az űrlapszerkesztőben a „Kulcsparaméter” attribútummal deklarált paraméterek.
Ezek határozzák meg a forma egyediségét.
Ez a paraméter addig létezik, amíg maga az űrlap létezik.

*************************************************************************************************
A Taxi felület használata

A fejlesztés során a konfigurációs tulajdonságokban beállíthatjuk a szokásos, 8.2-es menedzselt felületet – ettől minden érezhetően kompaktabb és ismerősebb lesz.
Ez különösen igaz, ha távolról bérel - a képernyő felbontása nagyon kicsi, és lehetetlen semmit sem csinálni a „taxi” felülettel.
Csak ne felejtse el újra beírni a „Taxi” szót, ha végzett!Ellenkező esetben a vizsgáztató pontokat von le!

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

PS: E Vannak külön szabványos részfeladatok, amelyeket minden feladatban használnak, és ezeket meg kell tudni oldani (például kötegelt kiírás, PVC használata (na, ez nagyon ritka) és mások). És minden feladatban egyszerűen ismétlődnek (hol van néhány részfeladat, máshol, csak különböző kombinációkban). Sőt, már régóta ígérik egy új kollekció kiadását (ha még nem tette), amiben sokkal több probléma kellene, vagyis nincs értelme az egyéni problémák megoldásait memorizálni, van értelme megtanulni, hogyan megoldani az egyes szabványos részfeladatokat, akkor minden problémát megold.

PSS: Kollégák, ha valakinek van egyéb hasznos információja a vizsgára való felkészüléssel és a sikeres letétellel kapcsolatban, írja meg kommentben, és kiegészítjük a cikket.