Az előre meghatározott elemekkel rendelkező programozási munka maga véleményem szerint nagyon helyes. Csak néhány árnyalatot kell figyelembe venni a munka során.

Először is világosan meg kell értenie magának, hogy vannak előre meghatározott elemek a konfigurációban, és vannak előre meghatározott elemek az információs bázisban (IB). A műszakilag előre meghatározott IS-elemek a könyvtárak leggyakoribb elemei, amelyekben a "PredefinedDataName" attribútum jelzi, hogy melyik előre definiált konfigurációs elemnek felelnek meg. Nem különböznek a hétköznapi elemektől. Ennek megfelelően az információbiztonság bármely hétköznapi eleme előre definiálható, bármely előre meghatározott elem közönségessé tehető. Ehhez csak írja be a kívánt értéket a kellékekbe. "PredefinedDataName".

Időnként ez a tulajdonság nem tartalmazza a fejlesztő által megadott értéket. Ennek eredményeként hibák lépnek fel az 1C munkájában. A kritikustól, amelyben elvileg lehetetlen a munka, a nem kritikusig, ahol az algoritmusok logikája sérül.

Feltételesen meg lehet különböztetni háromféle hiba:
1. "Az előre meghatározott elem hiányzik az adatokból";

3. Egy előre meghatározott elem helytelen jelzése;

1. "Az előre meghatározott elem hiányzik az adatokból" - ó a konfigurációban leírt előre meghatározott elem hiánya az IS adatokban.

Ez a legegyszerűbb hibakeresési és -javítási típus. Egyszerűsége az, hogy a platform helyesen jelzi ezt a helyzetet "Az előre definiált elem hiányzik az adatokból", és teljesen egyértelmű a javítás módja.

A "Könyvtárak. Kapcsolattartási adatok típusai. Kapcsolattartó e-mail címe" kód hiányzó elemének elérésekor egy üzenet jelenik meg.

Amikor hozzáfér az elemhez a "VALUE(Catalog.KindsofContactInformation.EmailContactPerson)" lekérdezésben, a következő üzenet jelenik meg:

Ilyen hiba akkor fordul elő, ha az elem leírásra került a konfigurációban, de az elem nincs hozzá társítva az adatbázisban.

Először is tisztázzuk, hogy ez a helyzet nem mindig hibás. Valamilyen programlogikában teljesen lehetséges előre definiált adatokat használni, ami a legtöbb felhasználó számára nem biztos, hogy használható. Ebben az esetben, hogy ne legyen tele a könyvtár minden konfigurációs felhasználó számára, logikus, hogy a konfigurációban előre definiált elemeket definiálunk, de nem minden IB-ben hozzuk létre, hanem csak azokra az IB-kre, amelyekben a szükséges konfigurációs logika használatos. Ebben az esetben a programozó megadhatja a "Ne frissítse előre meghatározott adatokat" tulajdonságot a könyvtárhoz, és a modul funkcióihoz való hozzáféréskor programozottan létrehozza az elemeket. Vagy engedje meg a felhasználónak, hogy a modul előre definiált elemeit önállóan hozzákösse a szokásos elemeihez.

Ezenkívül az előre meghatározott elemek automatikus létrehozása nem használatos, ha RIB módban dolgozik. Mivel az új elemeket a központi bázisról kell átvinni, nem pedig különböző UID-kkel rendelkező csomópontokban létrehozni.

Azok. néha hiba egy páratlan elemre hivatkozni, nem pedig magára egy ilyen elem létezésére.

El kell elemezni, hogy miért nem jött létre az elem. Előfordulhat, hogy valamilyen programmód végrehajtásakor létre kell hozni. Például egy csere végrehajtása után a RIB-ben. Vagy csak véletlenül törölték.

Ha a logika biztosítja az előre meghatározott elemek kitöltését nem automatikusan, hanem külön módban, akkor a név szerinti hívás használata előtt " Címtárak. Kapcsolattartási adatok típusai. A kapcsolattartó személy e-mail-címe" a kivétel megelőzése érdekében célszerű ellenőrizni, hogy az elem már benne van-e az adatbázisban. Ha az elem hiányzik, akkor erről tájékoztassa a felhasználót, és magyarázza el, milyen módot kell végrehajtania az elem kitöltéséhez. Egy ilyen ellenőrzéshez lekérdezheti az adatokat.

Request = Új kérés; Query.Text = "SELECT | Kapcsolatfelvételi információ típusok. Link | FROM | Címtár. Kapcsolatfelvételi információ típusok AS kapcsolati információ típusok | WHERE | Kapcsolatfelvételi információ típusok. Előre meghatározott adatok neve = "" EmailContactPerson"""; ElementMissingData = Query.Execute().Empty();

Ha ez továbbra is hiba az adatbázis adataiban, akkor az IB elem egy előre meghatározott eleméhez kell kötni. Azok. el kell magyarázni a rendszernek, hogy a programkód melyik IS elemre hivatkozzon ezen a néven. Technikailag a kötés csak egy előre meghatározott elem nevének megadását jelenti a "PredefinedDataNameA telepítéshez futtassa a következő kódot:

2. "Az előre meghatározott elem nem egyedi" - h javasolt előre definiált elemek:

Ez az a helyzet, hogy több IB elem egy előre meghatározott elemhez van kötve. Ebben az esetben az előre meghatározott név elérésekor az elem véletlenszerűen kerül kiválasztásra. Ez a helyzet mindig rossz. Bonyolultsága az, hogy a platform semmilyen módon nem számol be róla. Csak az algoritmusok kezdenek rosszul működni.

A platform csak az „Előre definiált elem nem egyedi” hibát jelez, amikor megkísérel szerkeszteni egy duplikált elemet.

Amíg senkinek nem kell szerkesztenie az elemet, senki nem fog tudni a hibáról.

Ilyen duplikátumok például akkor hozhatók létre, ha a könyvtárhoz RIB-t használnak, és az előre meghatározott adatok tulajdonságainál az "Automatikus frissítés" mód van megadva. Ebben az esetben a csere végrehajtásakor a konfiguráció frissítésekor létrejön az előre meghatározott adatok egy példánya. Az előre meghatározott elemek azonos nevű második példánya a csere során átkerül a központi adatbázisból.

Ezek az ismétlődések akkor is előfordulnak, ha a konfigurációk közötti csere feldolgozását használják, ha a különböző IS-elemek különböző adatbázisokban előre meghatározott elemeknek felelnek meg. Ebben az esetben az előre definiált adatok egyik példánya már az adatbázisban van, a második pedig más UID-vel való adatok betöltésekor érkezik. Ha adatmigrációt hajt végre, el kell döntenie, hogy mely adatbáziselemek számítanak elsődlegesnek, és ezeket az alárendelt adatbázisban kell használni. Az alárendelt bázisban le kell cserélnie a régi elemek használatát a fő alap elemeivel.

Az adatbázis ilyen hibái egy lekérdezéssel észlelhetők, például:

VÁLASSZA ki a kapcsolattartási adatok típusait. Előre meghatározott adatok neve, MENNYISÉG (KÜLÖNBÖZŐ típusú kapcsolattartási adatok. Link) AS Előre meghatározott FROM címtár száma. Kapcsolatfelvételi adatok típusai AS Kapcsolatfelvételi adatok típusai GROUP BY Kapcsolatfelvételi adatok típusai Előre meghatározott adatok neve MENNYISÉGŰ (KÜLÖNBÖZŐ típusú kapcsolattartási információ. Link) > 1

Ez a lekérdezés előre definiált elemek listáját adja vissza, amelyekhez egynél több IB elem tartozik.

Ha vannak ilyen elemek, akkor az egyiknél el kell távolítani a kapcsolatot az előre meghatározott elemmel. Azok. egyértelműen meg kell határozni a rendszer számára, hogy a programkód melyik IS elemre hivatkozzon e név használatakor. Ehhez egyszerűen futtassa a kódot.

3. Egy előre meghatározott elem hibás jelzése.

A hiba abban rejlik, hogy az előre definiált elem nem egyezik meg a programlogika által biztosított elemmel. Az ilyen hibákat a legnehezebb diagnosztizálni. Az első két típustól eltérően a konfiguráció nem ellenőrizhető automatikusan ezekre a hibákra. Ezeket csak a munka logikájának elemzésével lehet azonosítani. Ha kétségei vannak, ellenőrizheti, hogy a megfelelő elemet használja-e.

Ehhez egyszerűen hajtsa végre az egyik parancsot.

//A szükséges előre definiált jelentéshez kötött IB elem meghatározása (Könyvtár. Kapcsolattartási adatok típusai. Kapcsolattartó személy e-mail címe) //Határozza meg azt az előre definiált elemet, amelyhez a kiválasztott jelentés kötődik (ReferenceToElement.PredefinedDataName)

Ilyen hibák észlelésekor el kell távolítani a régi elemre mutató helytelen hivatkozást, és hozzá kell adni egy hivatkozást az új elemhez. A műveleti kód hasonló az első két típusú hiba javítására szolgáló kódhoz.

Nos, röviden a hibákról, amikor programmunka vagy konfigurációs módban:

"Az előre meghatározott elem nem tartozik ide<Имя справочника>" - hiba történik, amikor egy előre meghatározott elemet próbál írni olyan névvel, amely nem egyezik a konfigurátorban szereplő névvel.

"A nem előre definiált objektumok nem rendelkezhetnek előre meghatározott aldimenziós típusú bejegyzésekkel" - hiba történik, amikor egy előre meghatározott számlatükör elemet próbál előre definiálatlanná tenni. A hibák kiküszöbölése érdekében el kell távolítani az "Előre definiált" jelzőt az elem alérintkezőjének minden sorából.

"A nem előre definiált objektumok nem rendelkezhetnek előre meghatározott lead számítási bejegyzésekkel"- hiba történik, amikor a számítási típusok tervének egy előre meghatározott elemét próbálják előre definiálatlanná tenni. A hibák kiküszöbölése érdekében el kell távolítani az "Előre definiált" jelzőt az elem vezető számítási típusának minden sorából.

"Az előre meghatározott elemek nem egyediek"- frissítéskor hiba jelenik meg a konfigurátorban információs bázis 8.3.4-es kompatibilitási mód nélküli konfigurációs kiadáson. A frissítés előtt ellenőrizni kell, hogy vannak-e ismétlődések, és meg kell szüntetni azokat.

"Az előre meghatározott elemnév nem egyedi" - hiba történik, ha a konfigurációban több azonos nevű előre definiált elem van a platformra való frissítéskor8.3.6.2332 és újabb. Meg kell szüntetni a duplikációkat a konfigurációban.

Az előre meghatározott adatokkal való munkavégzéshez a feldolgozást javaslom. Bármilyen műveletet képes végrehajtani előre meghatározott adatokkal, és a konfiguráció egészét is ellenőrizheti az első két típusú (duplázott és hiányzó elemek) hibáinak megléte szempontjából az összes IS objektumban (könyvtárak, számlatükör, PVC, PVR).

Amikor az 1C:Enterprise 8.x platformon dolgozik, gyakran szükségessé válik, hogy a programkódot a könyvtárak szokásos (nem előre definiált) elemeihez kössék. Például egy szervezet ötféle árat tartalmazhat, amelyeket szinte minden mechanizmusban használnak. Ugyanakkor egy adott árhoz való programozott hozzáférést a legjobb esetben vagy a könyvtárban lévő kód csikorgása, legrosszabb esetben az elem neve hajtja végre.

Tanúja voltam annak, hogy a riportokban a kért ár megszerzéséhez a kérésben szereplő ár típusa alapján, a neve alapján választották ki (lásd a következő képernyőképet).

Ennek eredményeként egy instabil jelentést kapunk, amely leáll, ha az ártípus neve megváltozik. Ha az elemkódhoz kötődik, akkor mindig van lehetőség annak megváltoztatására. Például a keresési kódok egyediségének megsértése miatt az adminisztrátor elkezdheti az objektumok újraszámozását, ami az elemkódok megváltozásához vezet, és a jelentés nem fog megfelelően működni.

Ezen túlmenően, ha a címtárelemek nevéhez vagy kódjához kötődik, akkor az elemre mutató hivatkozás megérkezésekor mindig keresés történik a címtártáblázatban. Annak ellenére, hogy a szabványos rendszerrészleteket a DBMS indexeli, a keresésük bizonyos esetekben jelentős erőforrásokat igényelhet. Ráadásul racionálisabb lenne nem teljesíteni keresési lekérdezés hivatkozási táblázat szerint, ha mondjuk az elemre való hivatkozás már "előre ismert".

Kiútként eltárolhat egy hivatkozást a "Cikkártípusok" könyvtár minden gyakran használt elemére külön állandókban, és értékeket kaphat belőlük a lekérdezésben. Ebben az esetben azonban a fejlesztőnek minden ilyen elemhez külön állandót kell hozzáadnia. A helyzet sokkal bonyolultabb lesz, ha az ilyen elemek nem csak a "Nómenklatúra ártípusai" könyvtárban vannak, hanem más könyvtárakban is ("Objektumkategóriák", "Minőség", "Nómenklatúra" és mások). Ekkor többszörösére nőhet a konstansok száma a rendszerben!

Természetesen lehetőség lenne előre definiált elemeket hozzáadni mindegyik könyvtárhoz, és ezek elérése sokkal egyszerűbbé válna. Az általános objektumok megváltoztatása azonban megnehezítené a konfiguráció frissítését a szállítói csomagokból.

Van egy optimálisabb megközelítés mind a konfigurációs metaadat-struktúra fejlesztése, mind a rendszer teljesítménye szempontjából. Róla ma, és szó lesz róla.

Egyablakos megoldás

Az univerzális megoldás lényege a következő lesz: létrejön egy könyvtár, amelybe a fejlesztő előre definiált elemeket ad hozzá. Az "Érték" attribútum hozzáadásra került a szótárhoz, amelynek típusa attól függ, hogy mely értékekhez jön létre az "Előre meghatározott szótárelem -> Kapcsolódó érték" megfelelőség. A könyvtár metaadat-struktúrája így néz ki (lásd a következő képernyőképet).

Egy előre meghatározott elem beszerzéséhez a legjobb lehetőség a globális módszer alkalmazása "PredefinedValue(<Имя>)" . Paraméterként az előre meghatározott elem teljes elérési útja átadásra kerül a metódusnak. A szintaxis hasonló a "VALUE()" lekérdezési nyelvi függvényhez.

A fejlesztés kényelme érdekében azt javaslom, hogy mozgassa a függvényt, hogy az előre meghatározott elemhez tartozó érték kerüljön be közös modul. BAN BEN tesztkonfiguráció, letölthető a cikk végén található linkről, egy közös "Előre definiált elemek értékei" modul készült export funkcióval "GetPredefinedElementValue(<ИмяПредопределенногоЭлемента>)" . A függvény programkódja hivatkozást kap egy előre meghatározott elemre, majd kérésre megkapja az "Érték" attribútum értékeit. A következő képernyőkép a funkció teljes listáját mutatja.

Amint látjuk, a függvény kérést képez a paraméterként átadott előre definiált elem "Érték" attribútuma felé. A függvényparaméter egy karakterlánc egy előre meghatározott elem nevével.
Mert helyes működés A létrehozott mechanizmusból a felhasználói módban egy előre meghatározott elemet kell társítania a szótár szokásos eleméhez úgy, hogy kiválasztja a megfelelő elemet az "Érték" attribútumban. Térjünk át a teljesítményre gyakorolt ​​hatás kérdésére.

Teljesítményhatás

Mindkét keresési lehetőséghez sebességtesztet hajtott végre: név és link alapján egy előre meghatározott elemből. A keresés az "Áruk" címtárban történt, 20 000 bejegyzéssel. A fájlbázison végzett tesztek során a következő eredményeket kaptuk:

Az eredmények azt mutatták, hogy a munka fájlverziója esetén az előre definiált elemek használata más könyvtárak gyakran használt elemeinek beszerzéséhez közel 4-szer lassabb!

A munka kliens-szerver verziójában a teszteredmények egészen más képet mutatnak. A kívánt elemre mutató hivatkozás megszerzésének sebessége nem csökkent számottevően (az egyik teszt 0,002 másodpercet mutatott a név szerinti keresésnél és 0,0008 másodpercet egy előre definiált elem átdolgozásakor), de a program megbízhatósága jelentősen megnőtt!

következtetéseket

Azokban az esetekben, amikor gyakran szükséges a könyvtár közönséges elemeihez kötni, nem javaslom a kód vagy név szerinti kötés használatát. Ez a megközelítés csökkenti a rendszer megbízhatóságát és teljesítményét.

A platformmal való munka során többször is találkoztam olyan helyzetekkel, amikor a névváltoztatás után például a nem szabványos jelentések többsége összeomlott a "Nómenklatúra árak típusai" című referenciakönyv eleménél.

Minél több algoritmus kapcsolódik a könyvtárak szokásos elemeihez egy kódon vagy néven keresztül, annál kevésbé stabil a rendszer.

Ezenkívül ez a megközelítés lehetővé teszi, hogy ne módosítsa a tipikus konfigurációs objektumokat, ha előre meghatározott elemet kell hozzáadnia hozzájuk. A jövőben ez némileg megkönnyíti a konfiguráció frissítésének folyamatát.

Letöltések:

1. Teszt adatbázis kirakása a cikkből származó példákkal.

Mindenki tudja, hogy mi a különbség az előre definiált és a normál elemek között: "Az előre meghatározott elemek Konfigurátor módban jönnek létre, és nem törölhetők 1C:Enterprise módban." Felhasználói módban egy speciális ikon segítségével megkülönböztetheti az előre meghatározott elemeket a felhasználók által hozzáadottaktól (lásd a következő képernyőképet).

Alapvetően az előre definiált elemeket a fejlesztők hozzák létre, hogy különféle konfigurációs objektumokban algoritmusokat köthessenek hozzájuk. Például a "Minőség" referenciakönyv "Manufacturing Enterprise Management" konfigurációjában a fejlesztők hozzáadtak egy előre meghatározott "Új" elemet.

Ezt az elemet számos konfigurációs modulban használják. Tehát az "Áruk és szolgáltatások átvétele" dokumentumban minden olyan nyilvántartásban való feladáskor, ahol van "Minőség" dimenzió, egy előre meghatározott elem értéke behelyettesítésre kerül. Az alábbiakban a "GoodsOrganizations" nyilvántartás szerinti feladási táblázat kitöltésének listája látható:

// ÁRUK REGISZTRÁCIÓ SZERINT Áruszervezetek. MoveSet = Mozdul. Áruk Szervezetek; Ha ReceiptType = Felsorolások. Árubevételek fajtái. Akkor a raktárba // Szerezzen be egy értéktáblázatot, amely megfelel a regiszterrekordkészlet szerkezetének. MoveTable =MoveSet. Unload() ; // Töltse ki a mozgástáblázatot.Általános rendeltetésű. LoadToValueTable(TableByProducts,TableMovements) ; // Hiányzó mezők. Mozgástáblázat. FillValues(Szervezet, "Szervezet" ) ; Mozgástáblázat. FillValues(Undefined , "Commissioner" ) ; Mozgástáblázat. FillValues(References. Quality. New , " Quality " ) ; // A minőség feltöltése egy előre meghatározott elemből

Így az előre meghatározott elemek jellemzői és rendeltetésük meglehetősen egyszerű. Nézzük meg, hogyan tárolódnak az adatbázistáblákban, és miben különbözik a szokásos elemektől.

Különbségek

A tesztkonfigurációban létrejött az "Áruk" könyvtár. Létrejön benne a "Tesztelemek" csoport. A csoport tartalmát a cikk elején lévő képernyőképen láthatta. Az SQL-adatbázisban található "Termékek" referenciakönyvhöz egy megfelelő "_Reference37" tábla található a következő szerkezettel:

De hogyan lehet meghatározni a megfelelést a konfigurációs fa részletei és az SQL-tábla mezői között?

Használjuk a "GetDatabaseStorageStructure()" globális kontextus szabványos metódusát, amely egy értéktáblázatot ad vissza a táblázat szerkezetének leírásával.

A "Mezők" értéktáblázatban az SQL tábla mezőinek és a metaadatfában lévő objektum részleteinek megfelelőségét látjuk. Példánkban a "Termékek" könyvtár szerkezetét vesszük figyelembe. Minden szótár rendelkezik egy szabványos logikai típusú "Előre definiált" attribútummal, amely előre definiált elemek esetén TRUE értékre van állítva:

Az adatbázisban található címtártároló szerkezetet tartalmazó táblázat alapján határozottan kijelenthetjük, hogy az "Előre definiált" mező az "IsMetadata" mezőnek felel meg. Ha megnézzük a "_Reference37" tábla tartalmát az SQL adatbázisban, a következőket fogjuk látni:

Az előre meghatározott elem bejegyzésében az "IsMetadata" mező értéke "0x01"-re van állítva, ami megfelel az IGAZ jelzőnek. Normál elemeknél az érték "0x00"-ra van állítva. Ez a fő különbség az előre meghatározott és a szokásos elemek között. Az összes többi mező ugyanúgy tárolódik az adatbázisban, mint a felhasználók által hozzáadott közönséges elemek mezői.

Az előre meghatározott elemek nagyon érdekes célt találhatnak. Segítségükkel megtilthatja egy elemcsoport törlését / törlésre való megjelölését a könyvtárban és más objektumokban, amelyekhez hozzáadhatók. Ha megpróbáljuk törölni vagy törlésre jelölni a "Tesztelemek" csoportot. a következő hibákat kapjuk:

Így az előre definiált elemek azt a csoportot, amelybe kerülnek, "előre definiálttá" is teszik.

Befejezés

Az előre meghatározott elemek a legtöbb konfiguráció szerves részét képezik. Használatuk leegyszerűsíti a fejlesztést és logikailag "harmonikusabb" és szilárdabbá teszi a funkcionális felépítést.

Negyedik leckénk folytatjuk a programmal való ismerkedést. Ma folytatjuk gyakorlati példák megismerni éshierarchikus könyvtárakat, valamint megtanulják, hogyan hozhatók létre előre meghatározott elemek.

A tanfolyam 4 órájának ütemezése:

00:19 Változások az Alkalmazottak címtárban a tanfolyam 3. órájának házi feladatának elvégzése után
00:35 Részletek sorrendjének szerkesztése a könyvtárakban
02:54 Könyvtár-nómenklatúra létrehozása
03:40 Hierarchikus könyvtár létrehozása és konfigurálása
05:10 Szolgáltatások és áruk csoportok létrehozása a Nómenklatúra címtárban
06:05 A Nomenclature könyvtár kitöltése
07:14 3 módja annak, hogy egy címtárelemet átvigyen egy másik csoportba
08:21 Raktárak címtár létrehozása
09:19 Előre meghatározott könyvtárelemek létrehozása
11:25 A Raktárak címtár kitöltése
12:20 Tegyen tesztet a 4 tananyagból

Hierarchikus könyvtár– egy könyvtár, melynek elemei hierarchikusan elrendezhetők. Például a Nómenklatúra hivatkozási könyvében csoportok hozhatók létre: Áruk, Szolgáltatások stb., amelyekben ezekhez a csoportokhoz kapcsolódó elemek találhatók. Ezenkívül a címtárcsoportok más csoportokat is tartalmazhatnak, ezáltal többszintű hierarchikus struktúra jön létre.

Ezenkívül a könyvtárak egy másik típusú hierarchiát is támogatnak, amelyben a címtár elemei nem csoportokhoz fognak tartozni, hanem ugyanazon könyvtár más elemeihez. Ez a fajta hierarchia elem hierarchia) használható például a Subdivisions könyvtár létrehozásakor, ahol egy alosztály (egy alosztály ebben az esetben a címtár egy eleme, nem egy csoport) több más alosztályt is tartalmazhat. Ezt a fajta hierarchiát ritkán használják.

Címtár űrlapok- a könyvtár vizuális megjelenítése. Attól függően, hogy milyen műveleteket szeretnénk végrehajtani a könyvtárunkkal, a könyvtárat „különböző nézetekben” kell megjelenítenünk. Így a kurzus 4. óráján lista formájában és hivatkozási elem formájában szerkesztettük a részletek sorrendjét.

A rendszer automatikusan elkészíti (generálja) az űrlapokat, de szükség esetén a fejlesztő önállóan is „megrajzolhatja” az űrlapokat.

Összesen 5 űrlap (űrlaptípus) létezik a könyvtárakhoz:

• elem alakja– könyvtárelem létrehozása vagy szerkesztése;
• csoportforma- címtárcsoport létrehozása vagy szerkesztése;
• lista űrlap– a könyvtárelemek listájának megjelenítése;
• kiválasztási űrlap- az űrlapmező egyik elemének kiválasztására szolgál ezt a kézikönyvet. Például egy adott raktár kiválasztásához a Raktárak címtárból az Áru átvételi bizonylat Raktár mezőjében;
• csoport kiválasztási űrlap- a címtár valamelyik csoportjának kiválasztására szolgál egy bizonyos űrlap mezőjében.

Előre meghatározott könyvtárelemek- a fejlesztő által Configurator módban létrehozott könyvtárelemek, amelyek a beépített 1c nyelvből név szerint elérhetők.

Alapvető különbség van a normál és az előre meghatározott könyvtárelemek között. A közönséges elemek konfigurációja nem állandó. A felhasználó munkája során ezek létrehozhatók, szerkeszthetők, törölhetők, ezért semmilyen algoritmus végrehajtása során nem szabad rájuk támaszkodni (az elem kódját és nevét a felhasználó megváltoztathatja).Az előre meghatározott elemek viszont tartósak. A munka során, ha a felhasználó átnevez egy ilyen elemet, akkor is elérhető a beépített 1c nyelvről. Ez úgy érhető el, hogy az előre meghatározott elemnek kellékei vannak Név, amely nem elérhető a felhasználó számára. A közönséges könyvtárelemek nem rendelkeznek ezzel az attribútummal.

Fontos! Technikailag a felhasználónak lehetősége van egy előre definiált könyvtárelem törlésére, de általában megtagadják az előre meghatározott könyvtárelemek törlésének jogát.

Házi feladat a tanfolyam 4. leckéjéhez

A kurzus negyedik leckéjének házi feladatai az elméleti teszt sikeres megoldása után azonnal rendelkezésedre állnak.

Jó nap.

Ma a 8.3-as platform innovációjáról fogunk beszélni az előre meghatározott elemek tekintetében.

Bevezetés

Hadd emlékeztesselek arra, hogy korábban a gyakorlatban nagyon gyakran szerettem volna megnézni a könyvtárelemet, hogy megtudjam annak előre meghatározott nevét. Létrehozott például két előre meghatározott partnert, és elnevezte őket IPSidorovnak és OOOMeteornak. És varrtak rájuk némi logikát.

Amikor minden hibakeresés megtörtént és kidolgozott, kiderült, hogy a feladat fordítva lett beállítva, és az IP logikája kell az OOO-hoz, az OOO logikája pedig az IP-hez. „Semmi probléma” – mondjuk, és vállalati módban átnevezzük az elemeket. Hiszen a kódba bekerülni sokkal nehezebb. Eltelik egy év, és új feladatot kap: állítson be még logikát a Sidorov IP számára. Bemászsz a konfigurátorba, logikát írsz, elkezded ellenőrizni és semmi sem működik, mert az IPSidorov konfigurátorban és a vállalatban - Meteor LLC. Elromlott az agy, és el akarom pusztítani ezt a gereblyét. A legegyszerűbb és leglátványosabb módja egy előre meghatározott elem nevének megjelenítése lista formában. Itt egy csapda, a 8.2-ben előre definiált nevét csak módszerrel kaphatja meg. A módszer pedig a maga kellemetlensége, a kérésben nem szerezhető be. Azok. az első kellemetlenség az, hogy a címtárra hivatkozva megkapjuk az előre meghatározott nevet.

A második kellemetlenség, ha már van egy könyvtárelemünk, és előre definiálnunk kell. Létrehozunk egy előre meghatározott elemet, és két elemet kapunk a hivatkozásban. Az egyik előre definiált, a másik egy dolgozó, amelyre minden dokumentumunk hivatkozik. A hivatkozások cseréje biztosan segít, de ha nagy az adatbázis, akkor nehéz.

Most üzletben

Az első dolog az, hogy a könyvtár most már rendelkezik az "Előre definiált adatok frissítése" tulajdonsággal.

Mit ad nekünk ez a terület? Ha a "Ne frissítse automatikusan" értékre van állítva, akkor egy előre definiált elem hozzáadásával nem fogjuk azonnal látni a könyvtárban. Azok. a metaadatoknak semmi köze az adatokhoz. Ha pedig nincs létrehozva a könyvtárban, akkor a címtárkezelőn keresztül a nevén való elérése szintaktikai hibát okoz.

Nagyon érdekes, de miért? Hogyan hozzunk létre egy elemet a könyvtárban? És tetszés szerint létrehozhat, vagy összekapcsolhatja egy meglévővel. Most a szótárban van az "PredefinedDataName" attribútum. A szokásos módon programozottan létrehozunk egy szótárelemet a "Directories.Accounts.CreateItem()" segítségével, és az "PredefinedDataName" attribútumot az előre meghatározott elem nevével megegyezően kitöltjük. Vagy ha az elem már létezik, megkapjuk az objektumát, és újra kitöltjük benne az "PredefinedDataName"-t. Minden.

És végül egy kis szirup

Ez új kellékek, nem csak olvasható és írható, hanem lekérdezésekben is elérhető. Így a lekérdezésekben feltételeket szabhat rá, meghatározhatja, hogy előre definiált-e vagy sem.

Köszönöm a figyelmet.