1c 8 virtuális asztal.

A cikk az ügyfél-szerver üzemmódban működő konfigurációs maradványok virtuális táblájának fizikai megvalósítását írja le példaként az MS DBMS segítségével. SQL szerver.

Alkalmazhatóság

A cikk az 1C:Enterprise platform 8.3.5.1383 verziójával foglalkozik. A platform jelenlegi verziójában bizonyos változtatások lehetségesek az anyagban leírt szövegben, T-SQL lekérdezés a DBMS szerver oldalon végrehajtva.

A virtuális maradéktáblázat eszköze

Nézzük meg, hogy a DBMS-nek milyen lekérdezéssé alakul át a lekérdezés a felhalmozási regiszter egyenlegeinek virtuális táblája segítségével. Például a következő kérés szövegét veszi figyelembe a rendszer:

VÁLASZT
CommodityStocksRemains.Commodity,
CommodityStocksRemains.Warehouse,
CommodityStocksRemains.QuantityRemains
TÓL TŐL
Felhalmozási nyilvántartás. Árukészletek. Egyenlegek(&Dátum , Raktár = &Raktár ) HOGYAN
CommodityStocksRemains

Először a globális kontextus módszerével GetDatabaseStorageStructure() kap egy listát az „Árukészletek” felhalmozási nyilvántartás adatait tároló adatbázistáblákról:

A felhalmozási regiszter főtáblázata és az összegek táblázata mezőinek összetétele az alábbiakban látható:

Összesítések tárolása: ezt a nyilvántartást 1C:Enterprise 8 módban az alábbiak szerint konfigurálva:

Töltse ki a paramétereket a kérdéses kérésben az alábbiak szerint:

A platform a kérés szövegét a következő kéréssé alakítja, amely a DBMS-kiszolgálón kerül végrehajtásra:

KIVÁLASZTÁS
Q_000_T_001.Fld82,
Q_000_T_001.Fld83,
Q_000_T_001.Fld84Balance
TÓL TŐL
(SELECT Fld82 ,
fld83,

TÓL TŐL
(SELECT Fld82 ,
fld83,
SUM (Fld84 ) AS Fld84Balance
AccumRgT85-től
WHERE periódus = DATETIME (3999 , 11 , 1 )
ÉS ((Fld83 = ))
ÉS (Fld84<>0 ) ÉS (Fld84<> 0 )
GROUP BY Fld82 , Fld83
Fld84Balance birtokában<> 0
UNIÓ MINDEN
SELECT Fld82 ,
fld83,
SUM (ESET, AMIKOR RecordKind = 0, THEN - Fld84 ELSE Fld84 VÉGE ) AS Fld84Balance
AccumRg81-től
WHERE Időszak >= DATETIME (2012 , 9 , 1 )
ÉS időszak< DATETIME (3999 , 11 , 1 )
ÉS Aktív
ÉS ((Fld83 = 9:))
GROUP BY Fld82 , Fld83
Fld84Balance birtokában<>0) T
GROUP BY Fld82 , Fld83
Fld84Balance birtokában<>0) Q_000_T_001

Elemezzük részletesebben a beérkezett kérelmet.

Először is, az összekapcsolásban szereplő első lekérdezéssel, az eredményül kapott AccumRgT85 táblából kijelöljük az adatokat. A végösszegeket az aktuális összegek tárolásának napján (3999. 11. 01.) kapjuk meg, a Raktár mezőben egy további feltétel van érvényben (mivel a virtuális tábla paramétereiben ilyen feltételt használtunk). Ezenkívül ellenőrzi, hogy az eredményben nincsenek-e nulla maradék sorok.

Felhívjuk figyelmét, hogy a csoportosítás a lekérdezés szövegében kiválasztott méretek szerint történik. Éppen ezért az 1C:Enterprise lekérdezési nyelv szövege nem igényel további dimenziók szerinti csoportosítást.

A második összekapcsolási lekérdezés az AccumRg81 regisztermozgás táblát használja. A mozgás típusától függően (ha a RecordKind egyenlő 0-val, akkor ez a beáramlás, egyébként - Outflow) egy jel kerül a kifejezésbe. A platform a virtuális tábla paramétereként megadott dátumtól az aktuális összegek tárolásának dátumáig (3999.11.01.) terjedő időszakra választ adatokat.

Ezenkívül csak az aktív rekordok vannak kiválasztva, a Raktár mezőnek meg kell egyeznie a megadott értékkel. Az első csatlakozási lekérdezéshez hasonlóan ez is a kiválasztott dimenziók szerint csoportosít, és elveti a nulla erőforrásértékkel rendelkező rekordokat.

Ha az MS SQL Server DBMS-t használjuk, és az adatbázishoz 2000-es dátumeltolás van beállítva, akkor az összes dátum a megadott eltolással kerül tárolásra, pl. 3999.11.01. helyett 5999.11.01.

Ha letiltja az aktuális összegeket a felhalmozási regiszterben, akkor a platform először a virtuális tábla Időszak paraméterében megadott dátumnál korábbi dátummal számított legfrissebb összegeket kapja meg.

Ezután hasonlóan a mozgások táblázatából is kiegészülnek ezek az adatok, de csak az utolsó összesítés dátumától a virtuális tábla időszakáig terjedő időszakra.

KIVÁLASZTÁS
Q_000_T_001.Fld82,
Q_000_T_001.Fld83,
Q_000_T_001.Fld84Balance
TÓL TŐL
(SELECT Fld82 ,
fld83,
SUM (Fld84Balance) AS Fld84Balance
TÓL TŐL
(SELECT Fld82 ,
fld83,
SUM (Fld84 ) AS Fld84Balance
AccumRgT85-től
WHERE periódus = DATETIME(2012 , 4 , 1 )
ÉS ((Fld83 = 9:))
ÉS (Fld84<> 0 )
ÉS (Fld84<> 0 )
GROUP BY Fld82 , Fld83
Fld84Balance birtokában<> 0
UNIÓ MINDEN
SELECT Fld82 ,
fld83,
SUM (ESET, AMIKOR RecordKind = 0, THEN Fld84 ELSE – Fld84 VÉGE ) AS Fld84Balance
AccumRg81-től
WHERE Időszak >= DATETIME (2012 , 4 , 1 )
ÉS időszak< DATETIME (2012 , 9 , 1 )
ÉS Aktív
ÉS ((Fld83 = 9:))
GROUP BY Fld82 , Fld83
Fld84Balance birtokában<>0) T
GROUP BY Fld82 , Fld83
Fld84Balance birtokában<>0) Q_000_T_001

Figyelje meg a következő feltételt a kérelem törzsében.

Ha hasznos volt számodra a bejegyzésem, ne felejts el szavazni :-)

Itt van egy rubrikátor a gyűjtemény összes feladatához(egy oldal linkekkel a fórum témáira minden feladathoz)
http://chistov.spb.ru/forum/16-969-1

Nos, most az én fejlesztéseim és jegyzeteim, amelyeket az előkészítés során készítettem.
Megpróbálom legalább a fent említett kettővel megismételni utolsó kiadványok.

Tehát kezdjük:

Távoli kézbesítés esetén a vizsga végén két objektumnak kell lennie az asztalon:

1. Végső feltöltés információs bázis(dt fájl)
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ást választottál.
A kódban a kulcsfontosságú helyeken is jobb rövid megjegyzéseket hagyni, 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.
Jobb előre tudni)

Az „és” jelű bejelentkezési lekérdezések használata.

Néha gyorsabb a tárcsázás kiegészítő billentyűzet mint az elrendezés oda-vissza váltása időt takarít meg
&=Alt+38

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

A felhalmozási regiszterek lekérdezéseinél, a könyvelésnél, mint virtuális tábla (időszak) paraméternél nem a bizonylat dátumát, hanem a Moment paramétert kell használni, ami a kódban az alábbiak szerint van definiálva:

Moment = ?(PostMode = PostModeDocument.Online, Undefined, MomentTime());

*************************************************************************************************
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 a következő:

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

Lehetséges, hogy a lebonyolítás során elemezni kell a nyilvántartásban szereplő rekordokat.
Tehát, hogy az aktuális rekordok (a régiek, a dokumentum megváltoztatása előttiek) elemzésekor ne pontosan kerüljenek a kijelölésbe, a fenti két sorhoz hozzáadhat még egy sort:

Movements.RegisterName.Write();

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

De mindenhol csak ennek a három sornak a felépítését jeleztem egyszerre:

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

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

1) Hagyományos felügyelt zárolás, a dokumentum feladásának régi módja (DataLock objektum)

Akkor kerül beállításra, ha először az egyenlegeket ellenőrzik, majd leírják.
Abban az esetben, ha a mozgalom kialakításához szükségünk van bizonyos információkra a nyilvántartásból.

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 az önköltségi árat - nem.
Ezt csak a regiszterből tudjuk megtanulni, de ahhoz, hogy az egyenlegek beérkezésé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 le kell zárni a regisztert.
Tehát ebben az esetben a DataLock objektumot használjuk. Létrehozásakor pedig helyesebb megjelölni, hogy milyen méretekkel blokkoljuk a regisztert (például esetünkben - csak a dokumentumban megadott nómenklatúra szerint) -, hogy ne legyenek felesleges zárak, és egy másik felhasználó eladhasson egy másik nómenklatúrát.

1. Állítsa be a zárat a DataLock objektum segítségével
2. Olvasd el a többit
3. A terhelés lehetőségének ellenőrzése
4. Mozgásokat alakítunk ki, például árut írunk le
5. A bizonylat feladása után a zárolás automatikusan feloldásra kerül (a zárolás a könyvelési tranzakció keretében érvényes, és a rendszer automatikusan feloldja). Vagyis nem kell külön feloldani az objektumot.

2) Új módszertan a dokumentumok vezetésére (a LockForChange = True tulajdonság használatával)

Akkor használjuk, ha nincs szükségünk regiszterekből származó információkra a mozgások kialakításához, illetve ellenőrizhetjük, hogy mínuszba mentünk-e a terhelésnél, ha rögzítés után megnézzük a regiszteregyenlegeket, és azt látjuk, hogy negatívak vannak. Ebben az esetben megértjük, hogy a többletet leírtuk, és megszakítjuk a leírási műveletet.

Példa:
Fontolja meg az árueladás 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 dokumentumban megadott számmal mozgásokat alakítunk ki és rögzítünk. Ezután elolvassuk a regisztert, megnézzük a maradékokat, elemezzük, hogy vannak-e negatívak. Ha van, akkor hibát jelenítünk meg, és Refusal = True értéket állítunk be.

Tehát a sorrend a következő:
1. A regiszterben való mozgáshoz állítsa be a LockForChange = True tulajdonságot
2. Mozgásokat alakítunk ki - leírjuk az árut
3. Rögzítse a mozdulatokat
4. Olvassa el a nyilvántartást, 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 dimenziókon kell blokkolnunk a regisztert.
A mozgásaink rögzítése előtt egyszerűen beállítjuk a BlockToChange = True tulajdonságot, megalkotjuk 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 elemzi a rögzítetteket.
Ha elkészült, a zár eltávolításra kerül.

Ez a lehetőség (a második) egyszerűbb, "új dokumentumkezelési módszernek" nevezik, é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 Lock objektumhoz használjuk (lásd alább). a fenti példa).

Azt is megjegyzem, hogy a választott módszertől függetlenül a mozdulatokat törölni kell, mielőtt velük dolgozna (lásd az előző tippet)

*************************************************************************************************
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 felügyelt zárkód beszerzésének leggyorsabb módja a "DataLock" beírása, a Syntax Helper meghívása, és onnan csak a példakód másolása. Ezután könnyen megváltoztatható a regiszter és a mérések neve alatt.

Így néz ki:

Lock = New DataLock; LockElement = Lock.Add("Felhalmozási nyilvántartás.GoodsInWarehouses"); LockItem.Mode = DataLockMode.Exclusive; LockItem.DataSource = PM; LockElement.UseFromDataSource("Nómenklatúra", "Nómenklatúra"); Lock.Lock();

*************************************************************************************************
A dokumentumok táblázatos részét inkább egyszerűen "PM"-nek nevezzük.

A táblázatos rész a dokumentumok 99%-ában egy. Ilyen egységes név táblázatos részek Ezzel sok időt takaríthat meg, mert:
1) Nagyon rövid - írjon gyorsan
2) Ugyanez minden dokumentumra vonatkozik, nem kell emlékezned a kód írásakor, hogy mi a neve

*************************************************************************************************
Mielőtt kiválasztaná vagy feltöltené a TK-ba, ellenőrizze az ürítéskérés eredményét.

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

A minta teljesítmény szempontjából optimálisabb a rendszer számára, mivel csak az adatok olvasására van "kihegyezve" (a TK-val ellentétben).

De mindenesetre a Select() metódus előtt érdemes ellenőrizni az ürességkérés eredményét, ez tovább csökkenti a rendszer terhelését.

Eredmény = Request.Run(); Ha nem Result.Empty() then Selection = Result.Select(IteratingQueryResult.By Groupings); ... EndIf;

És arra az esetre, ha csak egy értéket kell kapnunk a kérésből
(például csak a leírási módszerrel összhangban számviteli politika erre az évre beállítva):

Eredmény = Request.Run(); Ha nem Result.Empty() akkor Selection = Result.Select(); Selection.Next(); Költségleírási módszer = Minta Költségleírási módszer; EndIf;

*************************************************************************************************
A BU feladat "Üzemeltetése" dokumentuma

Ügyeljen arra, hogy a BU feladatokhoz hozzon létre egy Műveleti dokumentumot.

A vezetését általánosságban kikapcsoljuk (a "Conducting = Deny" tulajdonságokban), jelezzük, hogy mi teszi a mozgásokat a számviteli nyilvántartásban, kihúzzuk a mozgásokat az űrlapon.

*************************************************************************************************
A dokumentumok operatív 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" dokumentum esetében a feladást általában le kell tiltani (a "Post = Disable" dokumentum tulajdonságainál),
mivel írja csak az adatokat közvetlenül a regiszterbe írja íráskor.

*************************************************************************************************
Feltétel egy lekérdezésben, például "Vagy a megadott nómenklatúra, vagy bármely, ha nincs megadva"

A lekérdezéseknél van egy ilyen feladat: például ki kell választani a megadott 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(Katalógus.Nómenklatúra.Üres hivatkozás)

De optimálisabb és helyesebb lesz ezt a feltételt átalakítani (köszönet yukonnak):

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

EndIf;

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

Ha ValueFilled(Nómenklatúra) Akkor
Query1.Filter.Add("Nómenklatúra = &Nómenklatúra");
Query.SetParameter("Nómenklatúra", Nómenklatúra);
EndIf;

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

Az összes rekord száma nem attól függ, hogy a csatolt tábla mezője megjelenik-e, csak a beállított hivatkozásoktó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 csatlakozik.

*************************************************************************************************
A jellemzők típusai (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 jellemző típusok (pl. szín, méret, max. sebesség stb.) lesznek. A beállításokban válassza ki a jellemző értékek összes lehetséges típusát, és ha szükséges, hozzon létre egy objektumot az 1.2 bekezdésből, és adja meg azt is a beállításokban.

1.2. A további PVC-értékekért létrehozunk egy annak alárendelt ExtraValues of Characteristics (vagy egyszerűen csak a jellemzők értékei) könyvtárát.
A jellemzők abban tárolódnak, ha nincsenek meglévő könyvtárakban. Nem tudjuk létrehozni, 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 valójában három objektumot köt össze:
- Az objektum, amelyhez kapcsoljuk a jellemzők mechanizmusát
- Jellemzők típusa (PVC típus)
- Jellemző érték (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 a jellemző értéke felvehet).
Az információs regiszterben feltüntetjük, hogy a Jellemző típus a Tulajdonos érték tulajdonosa (kiválasztási paraméter kapcsolat), valamint a Jellemző érték típuskapcsolata, ismét a Jellemző típusból.

További jellemző, hogy minden létrehozott jellemzőtípusnál megadható a jellemző értékének típusa, ha nincs szükség minden lehetséges típusra a jellemző értékének leírásához.

2. PVC használata számviteli regiszter alkonto mechanizmus létrehozásához .

2.1. PVC típusú Subconto-kat készítünk.

2.2. Létrehozunk egy alárendelt Subconto Values 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 kapcsolat a számlatükör segítségével történik.

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

Összeg – egyenleg,
Mennyiség – mérlegen kívüli és számviteli jellel társított Mennyiségi

*************************************************************************************************
A számviteli nyilvántartás virtuális táblái:

Forgalmak: egy számla forgalma
ForgalomDtKt: 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étrehozzuk a számviteli „valuta” jelét.
A számviteli nyilvántartásban ezenkívül létrehozzuk:
- Pénznem dimenzió (üres értékek tiltása, nem mérleg, számviteli előjel - pénznem)
- CurrencyAmount erőforrás (mérlegen kívüli, számviteli jel - pénznem, az összeget pénznemben, azaz például 100 dollárban tárolja)
Minden.

Így a regiszter szerkezete:

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

Így a devizaszámítás csak a Fehérorosz Köztársaságban szokásos könyvelés finomítása, a lényegen nem változtat, például az erőforrás összegé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 számla pénznemszámítási attribútuma ki van kapcsolva, akkor ez a Fehérorosz Köztársaság szokásos struktúrája (erő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 legfrissebb, hanem az utolsó rekordot kapjuk a megadott erőforrás értékkel - lehet, hogy nem az utolsó a mérési halmazban.

*************************************************************************************************
Az erőforrás és az attribútum jelentése a számítási regiszterben

A számítási regiszterekben egy erőforrás létrehozása lehetővé teszi annak fogadását a regiszter alapjának kiszámításakor.
És még az adott időszak arányában is újraszámításra kerül az erőforrás értéke (ha a bázisidőszak nem esik egybe a nyilvántartás gyakoriságával).

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

*************************************************************************************************
"Alap" jelölőnégyzet a számítási regiszter dimenziójának tulajdonságainál
Ez azt jelenti, hogy a jövőben ennek a dimenziónak az alapja lesz beszerezve, és 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 rekordok írásakor,
ha a vakáció egy sorban van megadva a dokumentumban több hónapra, egyszerre egy sorban:

StartDateCurMonth = KezdőHónap(CurStringBasicAccruals.ActionPeriodStart); EndDateCurMonth = EndHónap(CurStringBasicAccruals.ActionPeriodStart); Current Month = dátum; DateBeginTecMonth<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 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 "Generate" parancsot, és beírjuk a következőt az űrlap modulba:

&AtClient eljárás Generate(Command) GenerateAtServer(); EndProcedure &AtServer eljárás GenerateAtServer() DG.Clear(); DG.Update = Hamis; Запрос = Новый Запрос("ВЫБРАТЬ |ОсновныеНачисленияФактическийПериодДействия.Сотрудник, |ОсновныеНачисленияФактическийПериодДействия.ВидРасчета, |ОсновныеНачисленияФактическийПериодДействия.ПериодДействияНачало КАК ПериодДействияНачало, |ОсновныеНачисленияФактическийПериодДействия.ПериодДействияКонец КАК ПериодДействияКонец |ИЗ |РегистрРасчета.ОсновныеНачисления.ФактическийПериодДействия КАК ОсновныеНачисленияФактическийПериодДействия |ГДЕ |ОсновныеНачисленияФактическийПериодДействия.ПериодДействия МЕЖДУ &ДатаНачала И &ДатаОкончания "); Query.SetParameter("StartDate", Period.StartDate); Query.SetParameter("EndDate", Period.EndDate); Selection = Query.Execute().Select(); Míg Sample.Next() Loop Point = DG.SetPoint(Selection.Employee); Sorozat = DG.SetSeries(Selection.Calculation Type); Érték = DG.GetÉrték(pont, sorozat); Intervallum = Value.Add(); Interval.Start = Sample.PeriodActionStart; Interval.End = Sample.PeriodActionEnd; EndCycle; DG.Update = igaz; Vége eljárás

Igazából itt nekünk csak a ciklusban lévő kód a fontos, a többi csak segédlet, én most hoztam el ennek a részfeladatnak a teljes megvalósítását.
A megkeresésben számunkra fontos, hogy szerepeljen munkavállaló, számítás típusa, 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

*************************************************************************************************
"storno" rekordok feldolgozása elszámolási feladatokban:

A feladás feldolgozási eljárásban (objektum modul) minden mozgást képezünk, majd ha más időszakokban vannak rekordok, akkor ezeket így kapjuk
(a rendszer automatikusan generálja őket – segít nekünk):

RecordsAdditions = Movements.BasicAccruals.GetAdditions(); // Nem kell rögzíteni a mozgásokat a kiegészítéshez

Minden TekLine számára a RecordAddition Loopból
Record = Movements.BasicAccruals.Add();
FillPropertyValues(Record, CurrentString);
Record.RegistrationPeriod = CurrentString.RegistrationPeriodStorno;
Record.ActionPeriodStart = CurrentString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = CurrentString.ActionPeriodEndReverse;
EndCycle

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

Ha CurrentMovement.Reversal Akkor
CurrentMovement.Amount = - CurrentMovement.Amount;
EndIf;

*************************************************************************************************
Hogyan határozható meg, hogy mi szerepeljen a fő időbeli elhatárolásokban, és mit - a további számítási feladatokban.

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 havi munkanapok számától függő bónusz az OH).

Alap elhatárolások:
Ha a számítás típusa szerint az ütemezéstől (értsd: naptári dátumú információs nyilvántartástól) van függés, akkor az a fő passzív időbeli elhatárolásokra vonatkozik.

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

További díjak:
Mi számít a felhalmozott összegből, vagy MEGMUNKÁLT (és nem a norma!) Időnek, vagy egyáltalán nem függ - ez további. díjak.

Vagyis: az elhatárolás, amelynek kiszámításához az időnormát használjuk (talán tény is), az OH, és amelyhez tényleges adatokra vagy semmire nincs szükség - ez a DN.

Vagy más szóval:

Ha az RT időnormát használ, akkor az érvényességi időszakot bele kell számítani az RT-be.

*************************************************************************************************
Adjon hozzá egy opciót a „Nómenklatúra” referenciakönyv listaformájához, hogy megnyissa a beépített súgórészt „A kézikönyvekkel való munka”.

Futtassa a következő parancsot az űrlapon:

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

A szakaszvonal meghatározása a következő:
Lépjen a konfigurációs objektum referenciainformá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, majd a hivatkozás automatikusan beillesztésre 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 űrlapból nyissa meg a kívántat az "OpenForm()" metódussal, második paraméterként adjuk át a struktúrát paraméterekkel (ha szükséges). Harmadik paraméterként egy linket adhatunk át ehhez az űrlaphoz - ThisForm.

2. A megnyitott űrlapon az "OnCreateOnServer()" kezelőben az 1. lépésben átadott paramétereket a "Parameters.[ParameterName]"-en keresztül tudjuk elkapni. Az űrlap megnyitását inicializáló űrlap a „Tulajdonos” azonosítón keresztül lesz elérhető (természetesen, ha az (1) bekezdésben meg van adva).

És ami a legfontosabb, a tulajdonos űrlap export funkciói elérhetőek lesznek. Vagyis meghívhatjuk az eredeti űrlap export függvényét és átadhatunk ott valamit paraméterként a kijelölés feldolgozásához. És ez a funkció már az eredeti formában kitölti, amire szüksége van. Csak egy figyelmeztetés - az értéktáblázatot nem lehet átvinni az ügyféleljárások között, de átmeneti tárolóba helyezhetjük, és csak a BX címét vihetjük át, majd kivonhatjuk a BX-ből.

*************************************************************************************************
Formaparaméterek életciklusa

Az űrlapnak a megnyitásakor átadott összes paraméter csak az OnCreateOnServer 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 azok a paraméterek, amelyek az űrlapszerkesztőben a "Kulcsparaméter" attribútummal vannak deklarálva.
Meghatározzák a forma egyediségét.
Egy ilyen 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 - így minden érezhetően kompaktabb és megszokottabb.
Ez különösen igaz, ha távolról bérel - a képernyő felbontása nagyon kicsi, lehetetlen semmit csinálni a "taxi" felülettel.
Csak ne felejtse el, amikor minden készen van, tegye újra a "Taxi"-t!Ellenkező esetben a vizsgáztató pontokat vesz el!

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

PS: E Vannak külön tipikus 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, hol mások, csak különböző kombinációkban). Sőt, a gyűjtemény már régóta ígéretet kapott, hogy kiad egy újat (ha még nem jelent meg), amiben sokkal több probléma kellene, vagyis nincs értelme az egyes problémák megoldásait memorizálni, van értelme hogy megtanulja az egyes tipikus részfeladatok megoldását, akkor bármilyen problémát megold.

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

Úgy döntöttem, hogy hozzájárulok és leírom a nyelv azon jellemzőit, amelyeket a fenti cikkek nem vettek figyelembe. A cikk kezdő fejlesztőknek szól.

1. Építés "TÓL".

Ahhoz, hogy adatokat kapjunk az adatbázisból, nem szükséges a "FROM" konstrukció használata.
Példa: A bankkönyvtárból ki kell választanunk a bankokkal kapcsolatos összes információt.
Kérés:

VÁLASZTÁSA Címtár.Bankok.*

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

SELECT Banks.* FROM Directory Banks AS Banks

2. Rendelje meg az adatokat referenciamező szerint

Amikor a lekérdezési adatokat primitív típusok szerint kell rendeznünk: "String", "Szám", "Dátum" stb., akkor mindent az "ORDER BY" konstrukcióval oldunk meg, ha referenciamező szerint kell adatokat rendezni? A hivatkozási mező egy hivatkozás, egy egyedi azonosító, azaz. Nagyjából elmondható, hogy egy bizonyos tetszőleges karakterkészlet és a szokásos sorrend nem hozza meg a várt eredményt. A referenciamezők megrendeléséhez az "AUTOORDER" konstrukciót használjuk. Ehhez először közvetlenül a referenciatípus szerint kell az adatokat az "ORDER BY" konstrukcióval, majd az "AUTOORDER" konstrukcióval rendezni.

Ebben az esetben a dokumentumoknál a rendelés a "Dátum-> Szám" sorrendben történik, a címtáraknál - a "Fő nézet" szerint. Ha a rendezés nem referenciamezőkön alapul, akkor az "AUTOORDER" konstrukció használata nem javasolt.

Egyes esetekben az "AUTOORDER" konstrukció lelassíthatja a mintavételi folyamatot. Hasonlóképpen átírhatja a dokumentumok automatikus elrendezése nélkül:

3. A referenciatípus szöveges ábrázolásának beszerzése. "BEMUTATÁS" konstrukció.

Ha meg kell jelenítenie egy hivatkozási típusú mezőt a megjelenítéshez, például a "Bank" mezőt, amely a "Bankok" könyvtár elemére mutató hivatkozás, akkor meg kell értenie, hogy amikor ez a mező megjelenik, egy részlekérdezés a A "Banks" könyvtár automatikusan végrehajtásra kerül a könyvtár kikereséséhez. Ez lelassítja az adatkimenetet. Ennek elkerülése érdekében a kérésben a "REPRESENTATION" konstrukciót kell használni, hogy azonnal megkapjuk az objektum reprezentációját és máris megjelenítsük megtekintésre.

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

4. Az adatmintavétel feltétele a sablon szerint.

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

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

A "_" karakter szolgáltatás, é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, ilyenkor az összesített függvények elhagyhatók.

SELECT Services.Organization AS Szervezet, Szolgáltatások.Nómenklatúra AS Nomenklatúra, SUM(Szolgáltatások.Dokumentum összege) AS Bizonylat összege FROM Dokumentum.Szolgáltatások AS Szolgáltatások CSOPORTOK SZERVEZETEK SZERINTI SZERVEZÉSÉNÉRE, Szolgáltatások.Nómenklatúra EREDMÉNYEK ÁLTALÁNOS, Szervezet, Nómenklatúra szerint

Ebben az esetben a kérés majdnem ugyanazt adja vissza, mint ez:

VÁLASZTÁSA Szolgáltatások Szervezet AS Szervezet, Szolgáltatások Nómenklatúra AS Nómenklatúra, Szolgáltatások Dokumentum összege AS Bizonylat összege A dokumentumból.

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ő-hivatkozás megszüntetési 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, amelybe az „Adminisztrációs egység” attribútum értéke érkezik. 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

Az összetett típusú referenciamezők hivatkozásának megszüntetésekor a keretrendszer megpróbál implicit összekapcsolásokat létrehozni a mezőtípus részét képező összes táblához. 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 a konstrukcióval típusonként kell korlátozni az ilyen mezőket. EXPRESSZ().

Például létezik egy felhalmozási nyilvántartás "Nem allokált kifizetések", ahol több dokumentum is iktatóként működhet. Ebben az esetben helytelen a regisztrátor adatainak értékeit így lekérni:

KIVÁLASZTÁS: Fel nem osztott kifizetések.Regisztrátor.Dátum, ..... FROM Felhalmozási nyilvántartás. Nem allokált kifizetések AS Unallokált kifizetések

korlátoznia kell az összetett mezőnaplózó típusát:

SELECT EXPRESS (Nem allokált kifizetések. Nyilvántartó mint dokumentum. Befizetés). Dátum, ..... A felhalmozási nyilvántartásból. Fel nem osztott kifizetések, mint fel nem osztott kifizetések

7. Építés "HOL"

Két tábla bal oldali összekapcsolása esetén, amikor a "WHERE" feltételt a jobb oldali táblára állítja, hasonló eredményt kapunk, mint a táblák belső összekapcsolása esetén.

Példa. Az Ügyfélkönyvtárból ki kell választani az összes Ügyfelet, é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 vásárlót. Ezért először egy ideiglenes táblában kell megkapnia az "ilyen és ilyen" szervezetre vonatkozó összes kifizetést, majd bal oldali csatlakozással csatlakoznia kell az "Ügyfelek" könyvtárhoz.

SELECT Payment.Reference AS Fizetés, Fizetés.Részvényes AS Ügyfél PUT tofizetések FROM Dokumentum.Fizetés AS Fizetés WHERE Fizetés.Osztály = &Osztály; ////////////////////////////////////////////////// //////////////////////////////////////// Select Clients.Reference As Client, Isnull (Topayments.Payment, ") Fizetésként Címtár .Clients AS Clients LEFT CSATLAKOZÁS

Ezt az állapotot más módon is megkerülheti. közvetlenül a két tábla kapcsolatában szükséges a "HOL" feltételt előírni. Példa:

SELECT Clients.Reference, Payment.Reference FROM Directory.US_Subscribers AS ST_Subscribers LEFT JOIN Document.Payment AS Payment SOFTWARE (Clients.Reference = Payment.Client AND Payment.Client.Name LIKE "Cukorzsák") GROUP BY Clients, Payment.Reference. Link

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

Allekérdezések gyakran szükséges az adatok valamilyen feltétel szerinti kiválasztásához. Ha ezután más táblákkal együtt használja őket, akkor ez kritikusan lelassíthatja a lekérdezés végrehajtását.

Például egyes ügyfelek esetében meg kell kapnunk az egyenleg összegét az aktuális dátumra.

SELECT UnallocatedPaybalances.Customer, UnallocatedPaymentsRemains.AmountBalance FROM (SELECT Clients.Reference AS Reference FROM Directory.Clients AS Clients WHERE Clients.Reference B(&Clients)) AS NestedQuery

Egy ilyen lekérdezés végrehajtásakor a DBMS-optimalizáló valószínűleg hibákat követ el a terv kiválasztásakor, ami szuboptimális lekérdezéshez vezet. Két tábla összekapcsolásakor a DBMS-optimalizáló a két táblában lévő rekordok száma alapján kiválaszt egy algoritmust a táblák összekapcsolásához. Beágyazott lekérdezés esetén 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álni. Tehát írjuk át a lekérdezést.

SELECT Clients.Link AS Link PUT Clients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&kliensek) ; ////////////////////////////////////////////////// /////////////. tClients.Reference FROM tClients)) AS UnallocatedPaymentsBalances ON tClients.Reference = 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 kiválaszthatja az optimális táblaillesztési algoritmust.

Virtuális asztalok , lehetővé teszi, hogy a legtöbb alkalmazási feladathoz szinte kész adatokhoz jusson.(Slice of the First, Slice of the Last, Residuals, Turnovers, Residuals and Turnovers) A kulcsszó itt a virtuális. Ezek az asztalok nem fizikaiak, hanem menet közben szereli össze a rendszer, azaz. a virtuális táblákból származó adatok fogadásakor a rendszer a regiszterek végső tábláiból gyűjti az adatokat, összeállítja, csoportosítja és kiadja a felhasználónak.

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

SELECT Clients.Link AS Link PUT Clients FROM Directory.Clients AS Clients INDEX BY Link WHERE
Clients.Link B (&kliensek) ; ////////////////////////////////////////////////// / ///////////////////////////// KIVÁLASZTÁSA UnallocatedPayments.AmountBalance, UnalllocatedPayments.Customer AS Customer AZ egyenlegeket TEGYE A Felhalmozási Nyilvántartásból.UnalllocatedPayments. Egyenlegek(, Client IN (SELECT tClients.Reference FROM tClients)) AS UnallocatedPaymentsBalances; ////////////////////////////////////////////////// ////////////////////////////// SELECT tClients.Reference, thenRemains.SumRemainder AS SumRemainder FROM tClients AS tClients tClients.Reference = tRemainder .Ügyfél

9.A lekérdezés eredményének ellenőrzése.

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

RequestRes = Request.Execute(); Ha reQuery.Empty() then Return; EndIf;

Módszer Üres() módszerek előtt kell használni Választ() vagy Unload(), mivel időbe telik a gyűjtemény megszerzése.

Nem felfedezés senki számára, hogy nagyon 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érésben szereplő összes adatot megkapja, és csak ezután dolgozza fel az adatokat hurokban. De néha vannak olyan esetek, amikor lehetetlenné válik a kérés kivonása a hurokból. 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 helyettesítheti a szükséges paramétereket, és végrehajthatja a lekérdezést.

Ez megmenti a rendszert a kérés ciklusban történő elemzésétől.

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

A lekérdezésekben meglehetősen ritka konstrukció. 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, csoportosítania kell a rekordokat a fizetés összege szerint, majd feltételt kell szabnia. A "HAVING" konstrukció segít ennek elkerülésében.

KIVÁLASZTÁS Fizetés.Ügyfél, SUM(Fizetés.Összeg) MINT összeg A dokumentumból.Fizetés AS Fizetés WHERE HÓNAP(Fizetés.Dátum) = 9 CSOPORT Fizetés szerint.Ügyfél, HA VONATKOZIK ÖSSZEG(Fizetés.Összeg) > 13000

A konstruktorban mindössze annyit kell tennie, hogy 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

Itt nem írom le az adatbázisban szereplő háromértékű logika alapelveit, sok cikk van ebben a témában. Csak egy pillantás, 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 nincs definiálva, ismeretlen. Ezért a NULL-on végzett bármely 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: NULL = NULL, NULL<>A NULL nem igaz vagy hamis, ez ismeretlen.

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

Azon ügyfeleknél, akiknek nincs fizetésük, meg kell jelenítenünk az „Attribútum” mezőt „Nincs befizetés” értékkel. És 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 PUT a kifizetésekhez; ////////////////////////////////////////////////// /////////////////////////////// SELECT Clients.Link AS Client, Payment.Link AS Payment PUT tClientPayment FROM Directory.Clients AS Clients LEFT JOIN Document.Payment AS Payment Software Clients.Link = Fizetés.Részvényes; ////////////////////////////////////////////////// /////////////////////////////// tClientPayment.Customer FROM FROM tClientPay AS tClientPayment INTERNAL JOIN topayments AS topayments BY tClientPayment.Payment = dokumentumokat

Ügyeljen a második ideiglenes táblára tCustomerPayment. 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ő ideiglenes táblában a "kifizetések" 2 mezőt jelöltem ki, ezek közül az egyik NULL, a második a "Nincs befizetés" sor. A harmadik táblázatban a "tClientPayment" és a "tPayment" táblákat a "Fizetés" és a "Dokumentum" mezőkkel egy belső összekapcsolással csatlakozom. Tudjuk, hogy az első táblában a "Dokumentum" mező NULL, a másodikban pedig azok is NULL, akiknek nincs befizetése a "Fizetés" mezőben. Mi adja vissza nekünk ezt a kapcsolatot? És nem ad vissza semmit. Mivel a NULL = NULL összehasonlítás nem igazodik ki.

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

KIVÁLASZTÁSA "Nincs kifizetés" AS Sign, ÉRTÉK (Dokumentum. Fizetés. Üres hivatkozás) AS Dokumentum PUT to Payments; ////////////////////////////////////////////////// /////////////////////////////// SELECT Clients.Reference AS Client, ISNULL(Fizetés.Referencia, ÉRTÉK(Dokumentum.Fizetés .EmptyReference )) HOGYAN KELL ELHELYEZNI a tClientPayment-et a Directory-ból.Clients AS Clients LEFT JOIN Document.Payment AS Payment ON Clients.Reference = Payment.Shareholder; ////////////////////////////////////////////////// /////////////////////////////// tClientPayment.Customer FROM FROM tClientPay AS tClientPayment INTERNAL JOIN topayments AS topayments BY tClientPayment.Payment = dokumentumokat

Most, a második ideiglenes táblázatban jeleztük, hogy ha a "Fizetés" mező NULL, akkor ez a mező = üres hivatkozás a fizetési bizonylatra. Az első táblázatban a NULL-t is null hivatkozásra cseréltük. Most nem NULL mezők vesznek részt a kapcsolatban, és a lekérdezés a várt eredményt adja vissza.

A cikkben szereplő összes kérés olyan helyzeteket tükröz, amelyeket meg szeretnék fontolni, és semmi több. RÓL RŐL nem is lehetnek őrültek vagy nem optimálisak, a lényeg, hogy a példa lényegét tükrözze.

13. Nem dokumentált tervezési jellemző "VÁLASZTÁS MIKOR...AKKOR....VÉG".

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

SELECT CHOICE WHEN Users.Name = "Vasya Pupkin" THEN "Kedvenc alkalmazottunk" EGYÉB "Ezt nem tudjuk" END AS Mező1 FROM Címtárból.Users AS Users

De mi van akkor, ha például a hónap nevét kell megkapnunk a lekérdezésben? Hatalmas konstrukciót írni egy lekérdezésben csúnya és időigényes, ezért a fenti jelölési forma segíthet nekünk:

SELECT HÓNAP(US_Fogyasztásszámítás_Forgalomütemezés.Számítási időszak) 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 "7" THEN "7" Július" MIKOR 8. MAJD "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 nem tűnik olyan nehézkesnek, és könnyen észlelhető.

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

Annak érdekében, hogy ne hozzon létre kéréseket, létrehozhat egy nagy kérést, csomagokra bonthatja, és már dolgozhat vele.
Például a "Felhasználók" könyvtárból be kell szereznem a következő mezőket: "Születési dátum" és elérhető szerepek minden felhasználó számára. hogy az űrlapon különböző táblázatos részekre rakja ki. Természetesen ezt megteheti egy lekérdezéssel, majd ismételgetni kell a rekordokat vagy össze kell csuknia, vagy megteheti ezt:

SELECT Users.Link AS Name, Users.Date of Birth, Users.Role ENTER Users FROM Directory.Users AS Users; ////////////////////////////////////////////////// / /////////////////////////////// SELECT tuUsers.Name, tuSers.Date of Birth FROM tuUsers AS tuUsers GROUP BY tuUsers. Név, Tusers Születési idő; ////////////////////////////////////////////////// /////////////////////////////// SELECT wUsers.Name, wUsers.Role FROM wUsers AS wUsers GROUP BY wUsers.Name, wUsers. Születési dátum

tPackage = Request.ExecutePackage();

TP_BirthDate = tCsomag.Unload();
TP_Roles = tPackage.Unload();

Amint látjuk, a lekérdezés kötegben is végrehajtható, és az eredménnyel tömbként dolgozhat. Egyes 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ételekkel rendelkező rekordokat.

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

Ilyen feltételeket alkalmazhat:

WHERE Individuals.Code At (SELECT TueUsers.Code FROM TuUsers) AND Individuals.Name At (SELECT TueUsers.Code FROM TuUsers) AND Individuals.Date of Birth at (SELECT TueUsers.Date of Birth FROM TuUsers)

És ez így lehetséges:

WHERE (Individuals.Code, Individuals.Name, Individuals.Date of Birth) AT (SELECT TueUsers.Code, TueUsers.Name, TueUsers.Date of Birth FROM TueUsers)

És feltétlenül tartsa be a szabályokat.

16. Hívja a Query Builder alkalmazást a „Condition” (állapot) értékhez a Batch Queryben

Amikor feltételt kell előírnia, mint a fenti példában, elfelejtheti, hogyan hívják ezt vagy azt a mezőt a virtuális táblában.
Például feltételt kell szabnia a "Születési dátum" mezőben, és a virtuális táblázatban ez a mező neve "Az adós születési dátuma", és ha elfelejtette a nevet, akkor ki kell lépnie a szerkesztésből. feltételt mentés nélkül, és nézze meg a mező nevét. Ennek elkerülésére használhatja a következő trükkö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 helyet és meghívni a lekérdezés konstruktorát. A konstruktor hozzáférhet az összes kötegelt lekérdezési táblához. A vétel mind a virtuális regisztertáblákon, mind a „Feltételek” fülön működik. Ez utóbbi esetben be kell jelölni az "A (tetszőleges feltétel)" jelölőnégyzetet, és be kell lépni az "F4" szerkesztési módba.

A lekérdezéseket gyakran menet közben találják ki, és csak arra szolgálnak, hogy megjelenítsék azokat a „trükköket”, amelyeken gondolkodtam.

Meg akartam fontolni az indexek használatát a lekérdezésekben, de ez egy fájdalmasan kiterjedt téma. Felteszem egy külön cikkbe, vagy később felteszem ide.

upd1. 11., 12. bekezdés
upd2. 13,14,15,16 tételek

Használt könyvek:
1C:Enterprise 8 lekérdezési nyelv - E.Yu. Khrustalev
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 (bizonyos esetek kivételével), de 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 kényelmes számunkra (vagyis a lekérdezést végzők számára), hogy a virtuális táblákat pontosan valódinak tekintsük. Mi fog történni az 1C Enterprise 8 rendszerben, ha az általunk összeállított lekérdezés még mindig a virtuális táblára vonatkozik?

Első lépésben a rendszer egy virtuális táblát készít. A második lépésben a kapott táblából kiválasztásra kerülnek azok a rekordok, amelyek megfelelnek a WHERE záradékban meghatározott feltételnek:
Jól látható, hogy a virtuális táblából (és ennek következtében az adatbázisból) nem minden rekord kerül a végső kiválasztásba, hanem csak azok, amelyek megfelelnek a megadott feltételnek. A többi rekordot 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 plusz adatokon alapuló virtuális tábla felépítésére fordítanak erőforrásokat (az ábrán „A és B adatterületként” vannak jelölve), majd tovább kell dolgozni ezen adatok kiszűrésén a végeredményből.

Lehetséges-e azonnal, egy virtuális tábla felépítésének szakaszában megtagadni a szükségtelen adatok felhasználását? Kiderült, hogy lehet. A virtuális asztal beállításai erre szolgálnak:

A 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 az "Append Method" virtuális tábla paraméter értékei között?
Ha a ComplementMethod "mozgások" értékre van állítva, csak azok az időszakok jelennek meg, amelyekben mozgások voltak. Ha be van állítva a "Mozgások ÉS periódushatárok", akkor a fenti mozgásokhoz 2 rekord kerül hozzáadásra: mozgások a BT 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ó

Felhalmozási nyilvántartások az 1C:Enterprise rendszerben két típusra oszthatók: felhalmozási regiszterek maradékés felhalmozási nyilvántartások forradalmak.

A regiszter típusa a konfigurátorban történő létrehozásakor kerül kiválasztásra

Ahogy a neve is sugallja, egyesek egy bizonyos dátumra, míg a második egy kiválasztott időszakra vonatkozó forgalom fogadására szolgál. A felhalmozási regiszter típusától függően az 1C:Enterprise platform különböző virtuális táblákat állít elő. Ebben a cikkben megfontoljuk a felhalmozási regiszterek virtuális tábláival való munkát. Ehhez létrehozunk egy nyilvántartást az egyenlegek felhalmozására - Goods Remainsés a forgalom-felhalmozási nyilvántartás - Áruforgalom.

Most nézzük meg, hogy a platform milyen virtuális táblákat biztosít az egyes regiszterekhez.

Forgalmi nyilvántartás

Az egyértelműség kedvéért nyissuk meg, és nézzük meg, mely táblák állnak rendelkezésre a regiszterhez Áruforgalom. Ez magának a regiszternek a táblázata − Áruforgalom, amely fizikailag létezik az adatbázisban, és egy virtuális tábla - Áruforgalom

A standard táblázattal minden világos. Nézzük meg közelebbről a virtuális valóságot.

Virtuális asztal forgalom

Ez a táblázat lehetővé teszi az erőforrások forgalmának mérését a mérések keretében. A mi esetünkben két dimenziónk van: KészletÉs Termék. És egy erőforrás Mennyiség

Legyen nyilvántartásunk a következő bejegyzésekkel

Térjünk vissza a lekérdezéskészítőhöz, és kezdjük azzal, hogy egyszerűen kiválasztunk a táblázatból Áruforgalom minden mező

Ennek megfelelően a kérés így fog kinézni:

VÁLASZTÁS ÁruForgásokForgások.Raktár, ÁruForgásokForgások.Termék, ÁruForgásokForgások.Mennyiség Forgalom Regiszterből Felhalmozás.Áruforgalom.Forgalom(,) AS ÁruForgásokForgások

A lekérdezés eredménye így néz ki:

Vagyis teljes időre áru- és raktárkörnyezetben kaptunk forgalmat. Tegyük fel, hogy nem érdekelnek minket a raktárak, és csak árukontextusban szeretnénk forgalmat elérni.

Ehhez zárja ki a dimenziót a lekérdezésből Készlet

KIVÁLASZTÁS ÁruForgásokForgások.Termék, ÁruForgásokForgások.Mennyiség Forgalom Regiszterből Felhalmozás.Áruforgalom.Forgalom(,) AS ÁruForgásokForgások

és ennek eredményeként csak két sorunk lesz

De általában nem szükséges a nyilvántartás teljes fennállásának idejére forgalmi bevételt szerezni. Alapvetően egy meghatározott időszakra van szükség: hónap, negyedév, év stb. Ráadásul általában méretek szerint kell kiválasztani (Termék, Raktár). Ezt használatával érik el virtuális tábla paraméterei. Kényelmes a paraméterek kitöltése a konstruktorból. Gomb által Virtuális asztal opciók megnyílik egy párbeszédpanel, amelyben mindent regisztrálhat, amire szükségünk van:

Ezt követően az eredeti lekérdezésünk a következő formában jelenik meg

SELECT ÁrukForgásokForgások.Raktár, ÁruForgásokForgások.Termék, ÁruForgásokForgások.MennyiségForgalom Felhalmozási Nyilvántartásból ÁruForgások.Forgások(&Időszak eleje, &Időszak vége, Raktár = &RaktárforgalomTur) AS Áruk

Mint látható, a különbség az, hogy a virtuális tábla neve után zárójelben jelentek meg a paraméterek, amelyeket a lekérdezés végrehajtása előtt ki kell tölteni.

Azok számára, akik most kezdenek dolgozni a virtuális táblákkal, gyakran csábító, hogy a kijelölést a szokásos módon állítsák be a paraméterek használata helyett:

FROM Felhalmozási Nyilvántartásból.Áruforgalom.Forgalom(,) AS ÁrukForgásokForgások HOL ÁrukForgásokForgások.Raktár = &Raktár

A paraméterek kitöltésekor kihagytuk Periodikaság. Nyissuk meg a listát, és válasszunk a lehetséges lehetőségek tömegéből Hónap. Az összes többi paramétert eltávolítjuk, hogy ne keveredjünk össze.

Ezt követően megfigyeljük, hogy a táblázat mezőiben egy mező jelent meg Időszak.

A kiválasztott mezőkhöz hozzáadva a következő lekérdezési szöveget kapjuk:

VÁLASSZON ÁruForgásokForgások.Időszak, ÁruForgásokForgások.Raktár, ÁruForgásokForgások.Termék, ÁruForgásokForgások.MennyiségForgalom Felhalmozási Nyilvántartásból.ÁruForgások.Forgások(, Hónap,) AS ÁruForgásokForgások

A kérést teljesítjük:

Így a kiválasztott időintervallumon belül a forgalmat a kiválasztott gyakoriságnak megfelelően kisebb intervallumokra bonthatjuk.

Egyenlegfelhalmozási regiszter

Csakúgy, mint a fordított regiszternél, nézzük meg a lekérdezéskészítőben, hogy mely virtuális táblák állnak rendelkezésre az egyenlegfelhalmozási regiszterhez

Mint látható, három virtuális tábla áll rendelkezésre az egyenlegfelhalmozási regiszterhez: Forgások, Maradványok, Maradékok és forgalom. Tekintsük mindegyiket külön-külön.

Virtuális asztal forgalom

Bár a regiszter típusa az Maradványok, továbbra is forgalmunk lehet belőle. Ezen kívül két további forrásunk van itt: EljövetelÉs Fogyasztás

Emlékeztetnék arra, hogy az egyenlegnyilvántartásba történő bejegyzéskor a felhalmozás mozgásának fajtája (bevétel vagy kiadás) kerül feltüntetésre, míg a forgalmi nyilvántartásnál a mozgás típusa nincs feltüntetve. Ezért itt van egy további bónuszunk egy olyan lehetőség formájában, amely nemcsak az időszak egészének forgalmát kapja meg, hanem külön-külön bevételt is kap a kiadásokkal együtt. De persze, ha a metaadatokban van egy forgalmi regiszter hasonló méréskészlettel, akkor érdemesebb ezt használni a forgalom lekéréséhez. Általánosságban elmondható, hogy a virtuális táblával való munkavégzés hasonló a virtuális táblával való munkavégzéshez Forgások a fent tárgyalt forgalmi nyilvántartás.

Virtuális asztali egyenlegek

Ez a táblázat a fennmaradó erőforrások dimenziók szerinti lekérdezésére szolgál. A táblázat paramétereiben megadhatjuk, hogy milyen dátumra kapjuk az egyenlegeket, és beállíthatjuk a szűrőket:

Nézzünk egy kis példát. A következő nyilvántartási bejegyzéseink vannak:

Az összes rendelkezésre álló mezőt kiválasztjuk, és az egyenlegek beérkezésének dátumaként június végét jelöljük ki. A kiválasztás méréssel nem történik meg. Ekkor a kérés szövege így fog kinézni:

SELECT GoodsRemainsRemains.Warehouse, GoodsRemainsRemains.Product, GoodsRemains.MennyiségEgyenleg FROM Felhalmozási Nyilvántartásból.Termékmaradékok.Maradványok(&Maradványdátum,) AS GoodsRemainsRemains

És a végrehajtás után a következő eredményt kapjuk

Virtuális asztal

Ez a táblázat ötvözi a korábban tárgyalt kettőt, és lehetővé teszi, hogy megkapja a kiválasztott időszak forgalmát, valamint az időszak eleji és végi egyenlegeket. Kiválasztást is beállíthat.

E táblázat használata akkor indokolt, ha egy jelentésben egyidejűleg szükséges az időszak eleji és végi forgalom és egyenlegek beszerzése. Más esetekben a használatával nem szabad visszaélni.