Figyelem! Íme a lecke próbaverziója, melynek anyagai nem biztos, hogy teljesek.
Jelentkezzen be diákként
Jelentkezzen be tanulóként az iskolai tartalmak eléréséhez
1C 8.3 lekérdezési nyelv kezdő programozóknak: ÉRTÉK függvény
Funkció JELENTÉS kezelésére tervezték a kérelmező szervben rendszer enum értékekhezÉs előre meghatározott adatok.
Mi más az átutalások és az előre meghatározott adatok, kérdezed. Beszéljünk mindent sorban.
Felsorolások
Felsorolások- ez egy alkalmazásobjektum (emlékezz rá, hogy vannak még Útmutató könyvekÉs Dokumentáció). Miért volt rá szükség?
A lényeg az, hogy a felsorolás egy speciális tárgy. Ellentétben a kézikönyvekkel és dokumentumokkal minden lehetséges felsorolási érték be van állítva a konfigurációs szakaszbanés felhasználói módban nem változtatható tovább.
A megváltoztathatatlanság a fő ütőkártyájuk. Ezek amolyan adatbázis-konstansok.
És ha a programozó konfigurációs módban létrehozott egy elnevezésű felsorolást Padlóés értékeket FérfiÉs Női, akkor a program írásakor biztos lehet benne, hogy ennek a felsorolásnak az értékei a jövőben nem változnak. Ezért biztonságosan hozzáférhet ezekhez az értékekhez a kódból.
Képzeld el, mi fog történni, ha megpróbálja a címtárat ezekre a célokra használni?
Először is, néhány felhasználó továbbmegy, és hozzáad egy "Marsi padlót".
Másodszor, egy másik felhasználó az igent választja, és törli a már meglévő nemek egyikét, vagy megváltoztatja a nevét.
És a program emiatt megszakad, mert a munkájához pontosan két nemnek kell lennie, és "Férfi" és "Nő" névvel.
Ilyen esetekben léteznek felsorolások: annak érdekében, hogy egyszer (még a konfigurációs szakaszban is) mereven beállítsuk az összes lehetséges értéket, majd később felhasználjuk őket a programkódban.
Nézzünk egy példát egy ilyen felsorolásra a "Gastronom" adatbázisunkban. Ön a lecke próbaverzióját olvassa, a teljes leckék megtalálhatók.
Itt van a névsorunk Padló. Milyen értékeket vehet fel?
Csak két érték van. „Férfi” és „Nő” névvel. Amire szükségünk van.
Hol használhatjuk ezt a felsorolást a jövőben? Hát persze, az útmutatóban Ügyfelek. Vegye figyelembe, hogy a listában egy új kellék található Padlóés írja be Enum.Gender:
Így az ügyfélkártya már felhasználói módban történő kitöltésekor csak két Férfi és Nő értéket választhatunk az ügyfél nemének:
Most készítsünk egy lekérdezést, amely kiválasztja az ügyfeleket és nemüket az adatbázisból:
Most változtassuk meg a lekérdezést úgy, hogy csak férfiak maradjanak. Ha megpróbálunk valami ilyesmit írni:
akkor nem kapunk semmit:
Mert a felsorolási értékekhez ilyen módon nem lehet hozzáférni. Ezeket a funkció segítségével kell elérni JELENTÉS:
Tehát a függvény egyik feladata JELENTÉS- felsorolási értékek használata a lekérdezésekben.
előre meghatározott adatok
Jobb lenne, ha egy példával megmutatnám, mi is az előre meghatározott adat a könyvtárakhoz. Ön a lecke próbaverzióját olvassa, a teljes leckék megtalálhatók.
A "Gastronom" adatbázisunkban (felhasználói módban) nyissa meg a "Mértékegységek" hivatkozást:
Vessen egy pillantást az elemeire. Látja a sárga köröket egyes elemek mellett? Ezek az elemek (amelyek körökkel rendelkeznek) olyanok előre meghatározott adatok.
Általánosságban elmondható, hogy ha a könyvtár bármely eleme előre definiált (vagyis egy sárga kör van rajta), akkor ez az elem speciális.
Először is ez azt jelenti, hogy az elemet a programozó a konfiguráció szakaszában hozta létre (esetünkben ezek az 1, 2 és 3 kódú elemek).
Másodszor, ez azt jelenti, hogy ez az elem nagyon fontos a program működéséhez. Hogy az adatbázisban valamilyen kód hozzá van kötve (vagy inkább az előre meghatározott nevéhez).
Éppen ezért egy ilyen elem egyszerű törlése nem fog működni. Próbálja meg megjelölni törlésre:
Váltsunk most a konfigurációs módba, és nézzük meg, hol jönnek létre ezek a nagyon előre definiált elemek (jelen esetben a mértékegységek referenciakönyvében):
Itt ezek az összes előre meghatározott elemünk a referencia mértékegységhez. Vegye figyelembe, hogy minden előre meghatározott elemnek van egy speciális neve, amely nem jelenik meg felhasználói módban.
Az 1-es kódú elemnél ez a név Ton, 2-es kóddal - Gram és így tovább. Ezt a nevet hívják előre meghatározott elemnévés ezen a néven lehet hivatkozni a kódból (vagy esetünkben a kérésből).
Felmerülhet a kérdés, miért nem lehetett a mértékegységeket egyszerűen felsorolni a Ton, Gram és Pack elemekkel? És mindezt azért, mert ebben az esetben számunkra fontos, hogy a referencia mértékegység mindig tartalmazzon valamilyen konkrét elemet (tonna, gramm és csomag), ugyanakkor nem akarjuk megtiltani a felhasználónak, hogy bármely elemét hozzáadja ( kilogramm, darab és így tovább). Ön a lecke próbaverzióját olvassa, a teljes leckék megtalálhatók.
Ezért az előre meghatározott elemek határozottan alkalmasabbak itt, mint az enumok.
Előre definiált elemeinket pedig a kérésből érhetjük el a számunkra már ismert függvény segítségével JELENTÉS:
Csináld meg a tesztet
Indítsa el a tesztet
1. Enum értékek be vannak állítva
2. Egy cég raktárainak listájának tárolásához a típus
3. A mértékegységek listájának raktárban való tárolásához a típus
4. Olyan adókulcsok tárolására, amelyek listáját a felhasználó nem módosíthatja, típusát
5. A lekérdezésben a felsorolási értékre való hivatkozáshoz egy függvény alkalmas
6. Adókulcsok tárolására, melyek listáját a felhasználó módosítani fogja, típusát
7. Az előre meghatározott adatok innen származnak
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).
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 átadva a metódusnak teljes útvonal egy előre meghatározott elemre. A szintaxis hasonló a "VALUE()" lekérdezési nyelvi függvényhez.
A fejlesztés kényelme érdekében azt javaslom, hogy az előre definiált elemhez tartozó értéket egy közös modulba helyezzük át. 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(<ИмяПредопределенногоЭлемента>)" . Program kód függvény 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.
Ahhoz, hogy a létrehozott mechanizmus megfelelően működjön, hozzá kell rendelnie egy előre meghatározott elemet felhasználói módban egy normál szótárelemhez ú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ést az „Áruk” címtárban végezték, 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 fájl verzió működik, 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:
- 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 ÁrukSzervezetek. 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.
Érvényes az 1C:Enterprise 8.3.3 és újabb platformverziókhoz a 8.2-es verzióval való kompatibilitási mód nélkül
1.1. A könyvtárakban, számlatáblázatokban, jellemző típusok diagramjaiban és számítási típusok diagramjaiban lehetőség van előre meghatározott elemek automatikus vagy programozott létrehozására.
1.2. A legtöbb esetben ajánlatos előre definiált elemeket automatikusan létrehozni, mert folyamatosan szükség van rájuk, és szeretné megkönnyíteni ezeknek az elemeknek a kódból való elérését.
Például egy előre meghatározott ország Oroszország a címtárban A világ országai, előre meghatározott hozzáférési csoportok profilja Adminisztrátor stb.
Ezért
- a referenciakönyvben, számlatükörben, jellemzőtípusok tervében vagy számítási típusok tervében az értéket be kell állítani Auto(alapértelmezett), és nem engedélyezheti a metódus programozott hívását SetUpdatePredefinedData ezeket az objektumokat az üzemmód váltásához.
- megakadályozza, hogy a felhasználók töröljenek előre meghatározott elemeket az alábbi jogok letiltásával minden szerepkörben (alapértelmezés szerint le van tiltva):
- InteractiveDeleting PredefinedData
- InteractiveDeletionMarkPredefinedData
- InteractiveUnflaggingDeletingPredefinedData
- InteractiveDeletingLabeledPredefinedData
1.3. Ez alól kivételt képeznek a RIB gyermekcsomópontjai, amelyekben az előre meghatározott elemek nem jönnek létre automatikusan (és nem frissülnek, amikor a metaadatok megváltoznak), hanem át kell őket vinni a fő csomópontból a konfigurációs változtatásokkal együtt.
Ahol:
a) a konfigurációnak biztosítania kell, hogy a csereüzenet betöltésre kerüljön a RIB szolga csomópontjába, mielőtt egy másik alkalmazáskódot végrehajtanánk, amely hozzáfér a fő csomóponttól kapott előre meghatározott elemekhez;
b) a fő csomópontból (eseménykezelő) adatok betöltésének alkalmazási logikájában Adatok fogadásakor a Mestertől, objektumregisztrációs szabályok) kerülni kell az előre definiált elemekre való hivatkozásokat, mivel nincs garancia arra, hogy ezek már betöltésre kerültek a csereüzenetből;
c) az előre meghatározott elemeket feldolgozó IS frissítéskezelők kódját nem szabad végrehajtani a RIB szolga csomópontokban:
Ha Csere tervek. MainNode() = Nem definiált Akkor // előre meghatározott elemek kitöltése// ... EndIf ;Ha az „Adatcsere” alrendszert használja a Library of Standard Subsystems (BSP) 2.1.4-es és újabb verzióinak konfigurációjában, az (a) és (b) követelmények megszűnnek.
1.4. Az olyan előre meghatározott elemekkel rendelkező táblákhoz, amelyek nem részei a RIB cseretervnek (és amelyekre nem hivatkoznak a RIB csereterv részét képező egyéb táblák), ajánlatos beállítani a tulajdonságot. PredefinedData frissítése jelentésbe Automatikus frissítés, valamint a RIB slave csomópont első indításakor, állítsa be automatikus frissítés az adatokban hívással:
Útmutató könyvek. DirectoryName> . SetUpdatePredefinedData(UpdatePredefinedData. UpdateAutomatically) ;
2. Bizonyos esetekben az előre meghatározott elemeket nem kell automatikusan létrehozni, ha jelenlétük valamilyen feltételtől függ: engedélyezett funkcionális opció, program működési mód stb.
Például bizonyos előre meghatározott számítási típusok a számítási típusok tervében időbeli elhatárolások a funkcionális opciók értékétől függ A Time TrackingEmployeesIn Hours használata, Használja a Darabmunkából származó bevételt satöbbi.
Ezért
- ingatlanban PredefinedData frissítése referenciakönyv, számlatükör, jellemző típusok diagramja vagy számítási típusok diagramja "Nem frissül automatikusan" értékre kell állítani.
- adjon meg kódot egy előre meghatározott elem létrehozásához (és érvénytelenítéséhez), az üzleti logikától függően, például:
- vegye figyelembe az előre meghatározott elemek hiányát az IS-ben az alkalmazáskódban. Ellenkező esetben, amikor egy nem létező előre definiált elemhez fér hozzá a kódból vagy a kérés szövegéből, a rendszer kivételt dob:
Ha a Library of Standard Subsystems (SSL) 2.1.4-es vagy újabb verzióját használja a konfigurációban, ajánlott a funkció használata PredefinedElement közös modul General PurposeClientServer, ami visszatér Határozatlan előre meghatározott elemekhez, amelyek nem léteznek az IB-ben.
Nyomtatás (Ctrl+P)
Munka előre meghatározott értékekkel az Objektumkezelő használatával
Előre meghatározott értéket kaphat az 1C:Enterprise szerver oldalon a megfelelő objektumkezelő használatával. A kapott attribútumot meghatározó karakterlánc a következő alakú:
PredefinedValueType.MetadataObjectName.Value
● PredefinedValue Type– előre meghatározott értékek eléréséhez a következő adattípusok adhatók meg (beírva
többes szám):
● Kézikönyvek,
● Jellemzőtípusok tervei,
● Számlatáblázatok,
● Számítási típusok tervei,
● Felsorolások.
● Metaadat objektumnév
● Érték – a következők egyike lehet:
● felsorolásoknál a felsorolási érték nevét kell megadni;
● RoutePoints.PointName az üzleti folyamat útvonali pontja.
Abban az esetben, ha szükség van egy üzleti folyamat útvonali pontjának beszerzésére, a kapott értéket leíró karakterlánc így fog kinézni:
BusinessProcesses.MetadataObjectName.RoutePoint.RoutePointName
Példa:
Fajta = Felsorolások. Áruk típusai. Áruk;
// Az előre meghatározott könyvtáradatok beszerzése.
Elem = Directories.Currency.Ruble;
// Üzleti folyamat útvonali pontja
Pont = Üzleti folyamat Jóváhagyás Útvonalpontok Jóváhagyás;
Munka előre meghatározott értékekkel A funkció használata előre definiáltérték()
Tekintettel arra, hogy az alkalmazásobjektumok nem érhetők el a kliens oldalon, lehetetlenné válik az előre definiált attribútumok beszerzése az objektumkezelők segítségével. Ezért ezek beszerzéséhez létezik egy globális kontextus metódus, a PredefinedValue(). Ennek a metódusnak a paramétere egy karakterlánc, amely leírja, hogy milyen előre meghatározott értéket kell lekérni. Az előre meghatározott érték leírásának szintaxisa megegyezik a lekérdezési nyelv VALUE operátorának szintaxisával.
A kapott attribútumot meghatározó karakterlánc a következő alakú:
Nézzük meg közelebbről ennek a sornak az összetevőit:
● PredefinedValue Type– előre meghatározott értékek eléréséhez a következő adattípusok adhatók meg (beírva
egyedülálló):
● Kézikönyv,
● TervFajjellemzők,
● Számlaterv,
● NövénytípusokSzámítás,
● Listázás,
● BusinessProcess.
● És ObjectNameMetadata– adja meg a metaadat objektum nevét a konfigurátorban megadott módon.
● Érték – a következők egyike lehet
● felsorolásoknál a felsorolási érték nevét kell megadni;
● egy előre definiált érték lekéréséhez adja meg a nevét a konfigurátorban megadott módon;
● RoutePoint.PointName – üzleti folyamat útvonali pontja;
● EmptyLink – üres hivatkozás lekérése.
Ha meg kell kapnia a rendszer felsorolásának értékét, a metódus paramétere így fog kinézni:
SystemEnumName.SystemEnum Value.
Például:
ChartType = PredefinedValue("ChartType.ConcaveSurface“);
Ha üzleti folyamat útvonali pontot szeretne kapni, a kapott értéket leíró karakterlánc így fog kinézni:
Példa:
// Az enum értékének lekérése.
Nézet = PredefinedValue(„Felsorolás. Áruk típusai. Áruk”);
// Egy üres hivatkozás értékének lekérése.
Üres hivatkozás =
PredefinedValue(„Document.Invoice.EmptyReference”);
// Az előre meghatározott könyvtáradatok beszerzése.
Elem = PredefinedValue(„Kézikönyv. Pénznem. Rubel”);
// Business Process Waypoint
Dot = előre meghatározott érték(„Üzleti folyamat.Megállapodás.Útvonalpont.Jóváhagyás”);
Betöltés...