Konfigurációk automatikus ellenőrzése ... és néhány szó a fejlesztési szabványokról. Automatizált konfigurációellenőrzés... és néhány szó a fejlesztési szabványokról, 1c konfigurációellenőrzés

Valójában az 1C konfigurációk összetettsége évről évre növekszik, a csapatok nőnek, és több mint 5 000 000 kódsort tartalmazó termékek jelennek meg. A kódfolyamok rendezése nélkül nehéz dolgozni. És ez nem csak a minimális sorrend fenntartásáról szól – új objektumok előtagjairól, konvenciók megjegyzéséről vagy az objektumok alrendszerek közötti szétszórásáról. A csapatok növekedésével és a konfigurációk összetettebbé válásával egyértelművé válik, hogy szélesebb körű szabványokhoz kell ragaszkodni.

Ahhoz pedig, hogy ne legyünk csizma nélkül cipészek, jó, ha megvannak a megfelelő eszközök erre a célra. Érdekes eszközöket kínálnak konferenciákon és webináriumokon, beleértve a fent felsoroltakat is. Ugyanakkor magától az 1C-től egy meglehetősen kevéssé ismert konfiguráció is figyelmet érdemel. Amint azt a kiadvány címéből már megértette, ennek a terméknek a neve „Automatikus konfiguráció-ellenőrző”. Ingyenes, minden felhasználó számára elérhető (formálisan az ITS-hez való hozzáférés szükséges a használatához), meglehetősen könnyen használható, de egyelőre nem túl elterjedt.

Ez részben annak köszönhető, hogy maga az 1C az 1C: Compatible tanúsítványon keresztül csak a termelési megoldások fejlesztői körében aktívan hirdeti a szabványoknak való megfelelés gondolatát és az erre alkalmas eszközök használatát. A szabványok betartásának és a kódtisztaságnak a hatása a fejlesztők általános tömegére, akik nem foglalkoznak tömegesen gyártott megoldásokkal, sokkal gyengébb. Még az alapvető fejlesztési szabványok megismerése is feltételes zár alatt áll - az ITS-hez való hozzáférés elérhetősége (az információ elavult, jelenleg, 2018-2019-re, regisztráció nélkül elérhető) :

Alapvető információk az agráripari komplexumról

Az APK konfigurációt erre tervezték automatikus keresés hibák és a szabványoktól való eltérések a konfigurációkban. Használatát az 1C 2009 óta javasolja, és nem csak a forgalmi megoldásokat fejlesztő cégeknél, hanem más cégeknél is, ahol a szabványos megoldásokat véglegesítik és adaptálják:

Az első benyomást a konfigurációról az 1C webhelyének oldala adhatja:

Leírja ennek az eszköznek a főbb jellemzőit, és azt mondja, hogy segít:

tartsa be a tipikus fejlesztési szabványokat, és hajtsa végre a platformkonfiguráció ellenőrzését

hozza létre és kövesse a saját konfigurációellenőrzési szabályait

megfelel az 1C: Kompatibilis állapot megszerzéséhez szükséges szabványoknak

ütemezett ellenőrzéseket hajt végre

ellenőrizze a helyesírási hibákat

különböző állapotokat rendelhet az észlelt konfigurációs hibákhoz, beleértve a javítást nem igénylő „szolgáltatásként” való megjelölést

kissé megkönnyítse az ellenőrzési folyamatot, ha saját maga hajt végre bizonyos műveleteket, mint például a demó adatbázis konfigurációjának frissítése a tárolóból, a lépésről lépésre történő ellenőrzés lehetősége stb.

még a DSS-szel való integráció lehetőségét is említik

Egy másik forrás Általános információ a PCMagazine online magazinban megjelent publikáció szolgálhat:

Ezen áttekintő anyagokon kívül szinte semmilyen információ nem található a weben az APK-ról és annak alkalmazásairól, jó hír, hogy magához a konfigurációhoz tartozik egy PDF formátumú felhasználói kézikönyv. Egyes kérdéseket a kézikönyv nem tárgyal olyan részletesen, mint szeretnénk. De még mindig van egy kézikönyv, amely lehetővé teszi az alapvető technikák végrehajtásának megtanulását a konfigurációval végzett munka során.

A felhasználói útmutató megismétlésének elkerülése érdekében itt egy példát veszünk figyelembe az APK használatára egy tipikus konfiguráció ellenőrzésére, nem pedig az APK kézbesítéséből származó demókonfigurációra. Megpróbáljuk figyelembe venni a munka azon részleteit is, amelyekről a kézikönyv nem tesz említést.

Kezdjük a nulláról. Letöltés legújabb verzió Az APK az alábbi linken érhető el:

A cikk megjelenésekor a legújabb kiadás az 1.1.12.26, 2017. 01. 30., de eleinte az 1.1.11.16-os verzióhoz íródott, így a képernyőképek és a megjegyzések egy része erre a verzióra vonatkozik. Az APK 1.1-es verziójával való együttműködéshez legalább 8.3.6-os platformverzió szükséges. A konfigurációs szállítás telepítése után három új elem jelenik meg a konfigurációs sablonok listájában:

Az első sablon egy tiszta APK-adatbázis. Minden szabványos szabály megtalálható benne, de nincsenek teszteléshez betöltött demó adatbázis adatok, amelyek a második sablonban vannak.

A második sablon, „Automatikus konfiguráció-ellenőrzés (demó)” a telepítés után, a demóadatbázis betöltött adatait tartalmazza (a harmadik sablonban található). Segítségével megtekintheti, hogyan működnek a jelentések és a szabványos ellenőrzések. A legjobb, ha a szállításból megtanulja, hogyan kell dolgozni ezzel az adatbázissal a felhasználói kézikönyvvel felvértezve, mivel a kézikönyvben található példák kifejezetten ehhez a demóbázishoz készültek:

Az APC úgy működik, hogy új ellenőrzések végrehajtásakor COM kapcsolaton keresztül tölti be az ellenőrzött konfigurációból származó információkat. Ehhez szüksége van egy meglévő fájl "kísérleti" adatbázisra. Ezért, ha nem csak a demó adatbázis felületével szeretne megismerkedni, hanem a tesztelt adatbázissal való munka teljes ciklusát szeretné elvégezni, akkor érdemes még egy fájladatbázist telepíteni a harmadik sablonból. „Demo konfiguráció teszteléshez”.

Ebben az esetben két adatbázist kapunk - egy demo agráripari komplexumot, amely már betöltött információkat tartalmaz az ellenőrzött Demo bázisról, és magáról az ellenőrzött Demo bázisról, amely lehetővé teszi, hogy gyorsan megismerkedjen az új ellenőrzések csatlakoztatásának és végrehajtásának folyamatával.

Szeretném megjegyezni, hogy a demóbázisokkal való kísérletezés után az agráripari komplexum tiszta bázisa nem telepíthető. A működő konfigurációs ellenőrzések ugyanazon a konfiguráción hajthatók végre, mint a demó adatbázis ellenőrzések. Az APK-ban tetszőleges számú ellenőrizendő adatbázisról tölthet le információkat.

Általánosságban elmondható, hogy az APK működési elve hasonló az „Adatkonverzió” munkájához. Nem szükséges az APK konfigurátorban dolgozni (bár mint később kiderül, aligha lehet nélküle egyáltalán)... Az ellenőrzött konfigurációk szerkezetére vonatkozó információk felhasználói módban töltődnek be. Meghatározza a konfiguráció ellenőrzésére szolgáló algoritmusokat is kód formájában az 1C: Enterprise nyelven, amelyet aztán maga a rendszer hajt végre az operátor segítségével. Végrehajtás”. A kódban használhatja és kell használnia a beépített APK (nem platform) metódusokat - olyan eljárásokat és funkciókat, amelyek automatikusan létrehozott objektumokkal dolgoznak. A konfigurációellenőrzés végrehajtásához szükséges objektumokat a rendszer maga hozza létre, és az ellenőrzéskezelők kódjában válnak elérhetővé. Ezen módszerek, objektumok és kezelők részletes leírása a „Felhasználói kézikönyv” 6. fejezetében található.

Az AIC konfigurációja szinte teljes egészében referenciakönyveken, információs regisztereken és feldolgozáson alapul. Általánosságban elmondható, hogy ha ismeri az „Adatkonverziót”, akkor az APK-val való munka elvei egyértelműek lesznek. Sőt, ha nincs egyértelműen szükség saját ellenőrző algoritmusainkra, akkor eleinte lehetőség nyílik a standard ellenőrzésekre szorítkozni, és nem a rendszer beépített metódusait, programobjektumait tanulmányozni. Ekkor szinte minden beállítást el lehet végezni az egérrel, és úgy tűnik, ez sok feladatra elég lesz.

Csatlakozás konfigurálása az ellenőrzött alaphoz és alapértelmezett ellenőrzések

A demó adatbázis elindítása után a következő felületet látjuk:

A részek célja az APK-fejlesztők szempontjából a kézikönyvben található. Sorrendben megyünk, és először hozzáadunk egy új konfigurációt. Kattintson az "Új konfiguráció" gombra. A rendszer kérni fogja a csatlakozási paraméterek megadását. Valójában megnyílik a "Konfigurációk" katalóguselem űrlapja:

A név és a teljes név tetszőleges szövegmezők, csak a szépségérzet és a mező hossza szabhat határt, hogy mi kerüljön feltüntetésre. De a további korlátozások szigorúbbak. Meg kell adnia a teljes elérési utat végrehajtható fájl platformok 1C. Többben korai változatai Az APK ezenkívül meg kell adnia annak a platformnak a verzióját, amellyel dolgozik. Hadd emlékeztesselek arra, hogy az APK csak a 8.3.6-os és újabb platformverziójú konfigurációkat tudja ellenőrizni.

Információk a fejlesztőktől:

Ha alább megadja a platform elérési útját, akkor a COM-kapcsolat során hiba keletkezik.Ennek oka a következő. A platform fejlesztése és az APK új ellenőrzései kapcsán olyan információkat (metaadat-tulajdonságokat) gyűjtenek, amelyek csak a 8.3.6 vagy újabb platformon jelentek meg. Így például a 8.2-es verziók összehasonlításakor, amikor ilyen információkat gyűjtünk, természetesen hiba jelenik meg. És mivel ezek az új ellenőrzések általában elsőbbséget élveznek, a vizsgálat indításának tilalma alacsonyabb, mint 8.3.6. Ellenkező esetben (ha a platform fő verziója alacsonyabb a kliens számára), akkor feltételezzük, hogy a konfiguráció ellenőrzéséhez használhatja előző verziók Agráripari komplexum.

Ezután meg kell adnia a demó adatbázis elérési útját és a hozzá való csatlakozás paramétereit. Alatt demo alap ebben az esetben nem értünk mást, mint egy speciálisan dedikált fájlbázist, amely tartalmazza az ellenőrzött konfigurációt. Nincs lehetőség SQL-adatbázis csatlakoztatására az APK-hoz. Ez kívánság szerint módosítható, de nincs sok értelme. Először is, ez csak egy konfigurációellenőrzés, nem egységteszt vagy terhelési tesztelés. Ebben az esetben még az olyan nagy konfigurációkhoz is, mint az ERP 2, elegendő egy üres fájlbázis, amely tartalmazza az aktuális konfigurációt. Másodszor, az 1C szabványokkal összhangban minden konfigurációt úgy kell megtervezni, hogy ne csak SQL-adatbázissal, hanem fájlverzióval is működjön.

Ha a tároló használatával fejleszt, akkor az APK képes automatikusan frissíteni az adatbázis-konfigurációt a lerakatból, mielőtt új tesztet hajtana végre. A képernyőképen látható alsó paramétercsoport erre szolgál.

Vegye figyelembe azt is, hogy a DSS-nek az APK-hoz hasonlóan fájlbázisra van szüksége a konfigurációs információk betöltéséhez. Ezért, ha úgy dönt, hogy az 1C által kínált technológiákkal, APK és DSS használatával fejleszt, akkor mindkét rendszer számára elegendő egy fájlbázis létrehozása, ha szükséges, csatlakoztassa a konfigurációs tárolóhoz és konfigurálja. automatikus frissítés konfigurációt a tárolóból az adatok betöltése előtt.

A "Konfiguráció" és a "Könyvtár" mód közötti választás határozza meg az ellenőrzések súlyosságát. A "Könyvtár" módban az ellenőrzések szigorúbbak. A könyvtár olyan konfiguráció, amely másba is beágyazható, ami azt jelenti, hogy meg kell felelnie bizonyos szabályoknak, és „nem csak önmagára kell gondolnia”. Ha a kurzort a kapcsoló mindkét opciója fölé viszi, megjelenik egy tipp az ellenőrzési különbségek leírásával. Különösen az összes kiválasztott követelményt ellenőrizzük a könyvtárra vonatkozóan. A Könyvtárak fejlesztése és használata csoport követelményeit a rendszer nem ellenőrzi a konfiguráció szempontjából, függetlenül attól, hogy kiválasztva vagy sem. Ez a követelménycsoport nagyon hosszú távú érvényesítési szabályokat tartalmaz, amelyek valójában csak a könyvtárakra vonatkoznak.

Fontos pont az APK 1.1.11.16-os és korábbi verzióinál (az 1.1.12.26-os verzióban ezt a hibát javítottuk). A beállítások megadása és a „Konfigurációk” könyvtárban lévő elem lejegyzése után ellenőrizheti a kapcsolatot. De az első alkalommal a rendszer hibát jelezhet a kapcsolat hiányával kapcsolatban.

Ez egy félrevezető üzenet. Ha az elérési utak és a felhasználók helyesen vannak beállítva, akkor csak előre kell rögzítenie ennek a könyvtárnak az elemét, és csak ezután ellenőrizze a kapcsolatot. Ezután a rendszer jelentést küld a sikeres csatlakozásról. Egy nagy adatbázissal, például ERP-vel való kapcsolat ellenőrzése akár 1-2 percet is igénybe vehet:

Valójában most egy új elemet hoztunk létre a "Konfigurációk" katalógusban. Most már többféleképpen nyithatja meg:

• A "Beállítások" -> "Konfigurációk" menüben

• Az "Ellenőrzések" részben kattintson a "Konfiguráció kiválasztása" gombra.

• Vagy egyszerűen nyissa meg a „Konfigurációk” könyvtárat a „Műveletek” menüben

Térjünk vissza a konfigurációs beállítások ablakhoz.

A második „Ellenőrzendő követelmények” lapon konfigurálhatja, hogy milyen ellenőrzéseket kívánunk végrehajtani a konfigurációnkon. Két előre definiált lehetőség áll rendelkezésre: „Teljes ellenőrzés” – a szabványrendszernek való megfelelés ellenőrzése https://its.1c.ru/db/v8stdés a helyesírás-vezérlés, valamint az "1C: Kompatibilis" - ellenőrizze, hogy megfelel-e az 1C: Kompatibilis szabványoknak http://1c.ru/rus/products/1c/predpr/compat/soft/requirements.htm

Tetszőleges ellenőrizendő követelménykészletet is beállíthat, majd beszúrhat egy változat tetszőleges reprezentációját az „Ellenőrzési változat” mezőbe, és elmentheti ezen a néven a „Változat mentése” gombra kattintva. A változatok a konfigurációkhoz kapcsolódóan kerülnek mentésre, vagyis ugyanaz a beállítás nem alkalmazható automatikusan a „Konfigurációk” könyvtár más elemeire:

Hadd jegyezzem meg azok számára, akik az APK-t több konfigurációhoz kívánják használni, és nem akarják mindegyikhez külön konfigurálni az ellenőrzéseket. Az ellenőrzési beállításokat átviheti a konfigurációk között egy egyszerű szkript megírásával, ha tudja, hogy azok a "Konfigurációs követelmények" információs regiszterben vannak tárolva, és maguk az ellenőrzési beállítások az azonos nevű referenciakönyvben vannak tárolva:

Az ellenőrzések listája meglehetősen hosszú. Minden követelmény egy fejlesztési szabvány, amelynek betartása jobbá teheti termékeinket. De az egyéni követelmények vagy csoportjaik letiltásának lehetősége sem felesleges. Például a legtöbb vállalatnál korlátozhatja magát a „Teljes ellenőrzés” opcióra (helyesírás + szabványrendszer), és nem ellenőrizheti az „1C: Compatible”-t. Vagy legalább ellenőrizni a helyesírást, hiszen olyan nincs, hogy évek óta egyetlen helyesírási hiba nélkül zajlanak a fejlesztések.

Az itt kiválasztott követelménylista az automatikus ellenőrzések alapértelmezett listája. A teszt végrehajtása során felülbírálhatja az itt megadott értékeket.

Információk a fejlesztőktől:

Érdemes részletesebben elmondani, mi az a "Szabványrendszer" csoport, és miben különbözik a másik két csoporttól. Tehát kezdjük az „1C: Compatible” csoporttal. Mint korábban írtuk, ez egy kötelező szabványkészlet a konfiguráció bizonyos állapotának megszerzéséhez. Nagyjából ez az a gerinc, amelynek kivétel nélkül minden konfigurációnak meg kell felelnie. Mellesleg, ez a szabványcsoport nem ellenőrzi a konfigurációt a helyesírási hibák miatt ...

További "Helyesírás" egy olyan szabványcsoport, amely csak a helyesírási hibákat ellenőrzi a konfigurációban. Minden önmagát tisztelő fejlesztő ellenőrizheti a konfigurációját. Ez a csoport tartalmazza az összes ellenőrzési szabályt, amelyek nyomon követik a helyesírást a modulszövegekben, metaadatokban (név, szinonimák, megjegyzés), űrlapelemekben, elrendezésekben, általában mindenhol, ahol ellenőrizheti a szöveget. Csak az orosz szöveg kerül kijelölésre a dobozból, de amint azt a megjegyzésekben megjegyeztük, más nyelvek esetén betöltheti szótárait, és akár le is cserélheti a mellékelt konfigurációt.

És most a "Szabványrendszer" csoportról. Ez a legglobálisabb, és tartalmazza a másik két előre meghatározott követelménycsoport ellenőrzését, valamint további speciális ellenőrzéseket. Az ügyfelek számára az ebbe a csoportba tartozó hibák inkább ajánlások, bár a tipikus konfigurációk esetében a legtöbb hibát természetesen ki kell javítani. Hogy. ha valamelyik szabvány az "1C: Kompatibilis" vagy a "Helyesírás" csoportban le van írva, az kétségtelenül a "Szabványrendszer" csoportban is le lesz írva, de talán részletesebben és mélyebb ellenőrzésekkel.

Különféle szűrések vannak beállítva a „Kizárások vizsgálata” lapon. Például beállíthatja az ellenőrzéseket úgy, hogy csak a szabványos konfigurációhoz adott objektumokat adott előtaggal, például " mf_ Szuper vámáru-nyilatkozat”.

Vagy ha úgy fejleszt, hogy az összes módosított vagy hozzáadott objektumot hozzáadja egy adott fejlesztési alrendszerhez, akkor érdemes csak ezen az alrendszeren belül ellenőrizni, és megkerülni a tipikus konfiguráció változatlan objektumait, amelyek zárolva vannak. Ha ideiglenesen ki kell zárnia egy konfigurált szűrőt az ellenőrzések során, akkor nem kell eltávolítania. Elég, ha töröljük a használat jelző jelölését (második oszlop):

A szűrési funkció nagyon hasznos, és van értelme kísérletezni vele, amit legközelebb meg fogunk tenni. Azonnal meg kell mondanom, hogy az olyan megengedő ellenőrzések, mint az "Alrendszer szerepeltetése" és a "Befoglalás előtaggal" a "VAGY" funkcióval működnek. Vagyis egy objektumot a rendszer ellenőrzi, ha megfelel valamelyik feltételnek. Ez nem mindig kényelmes. Szerencsére ezen a viselkedésen nagyon könnyű változtatni. Erről a kérdésről részletesebben a szűréssel foglalkozó részben lesz szó, valamint a szűrőknek az ellenőrzések idejére gyakorolt ​​hatásáról.

Az APK 1.1.11.16-os és korábbi verzióiban a szűrési beállításokat két lapra osztották – „Követelménygyűjtő szűrők” és „Adatgyűjtési kivételek”, de a jelentés ugyanaz:

Ezenkívül a beállítások űrlapon beállíthatja az ütemezett ellenőrzések szükségességét:

Ez a beállítás hogy ne dolgozzon végig egy ütemezett feladaton... Az ütemezett vizsgálat futtatásához az APK-t felhasználói módban kell elindítani és futni. Amikor a rendszer elindul a modulban rendszeres alkalmazása módszert hívják A rendszer elején () ahol a várakozáskezelő csatlakozik RunCheckScheduled (), amely ütemezett ellenőrzéseket végez. Ha az ellenőrzést rutinfeladattal kívánjuk elindítani, akkor a rendszert módosítani kell. Ha megnézi az APK konfigurációját, láthatja, hogy csak két ütemezett feladatot tartalmaz, és mindkettő nem kapcsolódik az ütemezett ellenőrzésekhez:

Információk a fejlesztőktől:

A magyarázat nagyon egyszerű. Ha az APK SQL verzióban van telepítve, akkor amikor megadja a konfiguráció elérési útját (pontosabban a demo adatbázist) az ügyfélen, az ellenőrzés egyszerűen nem indul el, mert egy ütemezett feladat mindig fut a szerveren. Az agráripari komplexum fájlváltozatában természetesen az ütemezett munka jobban megfelelne, mint a várakozó kezelő.

A menetrend nem az utolsó lehetséges lap. Ha a rendszerben engedélyezi az „Alkalmazott megoldások tervezési rendszerével” való integrációt, akkor megjelenik egy másik „Integráció DSS-sel” fül, amely lehetővé teszi a hibák automatikus regisztrálását a DSS-ben. A rendszerszintű integráció beállítása konstansok formájában történik ("Műveletek" - "Konstansok").

A DSS-sel való integráció funkcionalitását az agráripari komplexum fejlesztői belső használatra szánták az 1C-ben (ezt a „Felhasználói kézikönyv” 28. oldalon ismerteti). Biztos vagyok benne azonban, hogy azoknak a cégeknek, amelyek már használják a DSS-t a munkájuk során, vagy tervezik használni, ez a funkció érdekes lesz. Használhatja mintaként a saját integrációs mechanizmusának megvalósításához, vagy kezelheti és a dobozból kivetve felhasználhatja:

Ebben az esetben lehetőség van arra, hogy az agráripari komplexumot a DSS oldaláról emelt webszolgáltatáshoz kapcsoljuk, és fordítva, konfigurálható a kapcsolat az agráripari komplexum oldalán emelt webszolgáltatással. a DSS-ben:

Ellenőrzések elvégzése

A csatlakozási beállítások elvégzése és az elvégzendő ellenőrzések kiválasztása után folytathatja az ellenőrzések végrehajtását.

Új ellenőrzés végrehajtásához először aktualizálnia kell az ellenőrzött konfigurációt. Minden új ellenőrzés az „aktuális konfiguráción” történik. Ehhez az „Ellenőrzések” részben kattintson a „Konfiguráció kiválasztása” lehetőségre, majd válassza ki a konfigurációs hivatkozás azon elemét, amelyhez „aktuális” lesz hozzárendelve.

Az „Új ellenőrzés” gombra kattintva a rendszer két lehetőséget kínál fel – az ellenőrzött konfigurációhoz való csatlakozással, az adatok újragyűjtésével, vagy a korábban gyűjtött adatok ellenőrzésével.

A korábban gyűjtött adatok ellenőrzésének lehetősége lehetővé teszi a hosszadalmas, szakaszos ellenőrzések végrehajtását. Például először összegyűjtheti a konfigurációs adatokat, és szűrt ellenőrzést hajthat végre az alrendszerek egy részhalmazán. Ezután engedélyezze a szűrőket más alrendszerek számára, és végezze el a második ellenőrzést a korábban gyűjtött adatok alapján, amely lehetővé teszi a sokkal gyorsabb végrehajtást.

Információk a fejlesztőktől:

Itt azt is el kell mondani, hogy az összegyűjtött adatok összetétele most közvetlenül függ a kiválasztott követelményektől. Például egy „Helyesírás a modulszövegekben” követelmény ki van választva. Ha megnyitja magát a követelmény kártyáját, és az "Ellenőrzési szakaszok" fülre lép, akkor láthatja, hogy csak 1 "Modulokkal kapcsolatos információk kitöltése" jelölőnégyzet van bejelölve:

Ez azt jelenti, hogy a modulok szövegeinek helyesírási konfigurációjának ellenőrzésekor csak a modulok szövegeinek összegyűjtése történik (sem a metaadat objektumok tulajdonságai, sem az űrlapok elemei, sem az elrendezések nem kerülnek összegyűjtésre - a többi jelzővel minden típusú információgyűjtés kiválasztható).

Az összegyűjtött információknak a kiválasztott követelményektől való függésének ez a funkcionalitása viszonylag nemrégiben jelent meg, korábban minden adatgyűjtési ellenőrzéskor minden információt összegyűjtöttek. Tehát korábban ez a lehetőség sokat segített: valamelyik követelményt kiválasztották, például ugyanazokat a modulokat, minden információt összegyűjtöttek, ennek az egy követelménynek a hibákat kijavították, majd a következő követelményt választották ki, például az űrlapelemek helyesírását, és az ellenőrzést már az összegyűjtött adatok alapján elkezdték, mert formaelemek nem változtak stb.

Most már használható is, de csak a korábban összegyűjtött követelményeket lehet összevetni az összegyűjtött adatokkal. Nos, nem lehet mást mondani, mint azt mondani, hogy ez az ellenőrzési lehetőség rendkívül szükséges az új ellenőrzések fejlesztői számára a hibakereséshez, teszteléshez, felgyorsításhoz és az ellenőrzési szabályok pontatlanságainak azonosításához, mivel nem kell minden alkalommal újraépíteni az adatokat.

Mivel még nem gyűjtöttünk adatokat, az „Adatok gyűjtése és ellenőrzése…” menüpontot választjuk. Megnyílik egy ablak, amelyben kiválaszthatja, hogy folytatja-e vagy automatikus ellenőrzés, az új konfigurációs ablakban korábban elvégzett beállításoknak megfelelően, vagy felülírhatja ezeket a beállításokat. A „Kézi” opció kiválasztása különösen kényelmes a rendszerrel való ismerkedés kezdeti szakaszában, amikor minden következő lépést befolyásolhat.

A „Tovább” gombra kattintva felülbírálhatja a kiadvány előző részében leírt összes beállítást, beleértve az elvégzett ellenőrzéseket is. Ne feledje azonban, hogy ha nem választ ki egyetlen ellenőrzést sem a megfelelő lépésben, akkor a rendszer úgy ítéli meg, hogy MINDEN ellenőrzést el kell végeznie, nem csak csatlakoztatnia kell és le kell töltenie az objektumokkal kapcsolatos információkat az ellenőrzött adatbázisból:

Ezért, ha az indítás célja nem egy teljes ellenőrzés, hanem a konfigurációs struktúra frissítése vagy az APK tesztfutása és a folyamat megismerése, akkor ennél a lépésnél ne törölje az összes jelölőnégyzet bejelölését. Az első alkalommal tanácsos csak egy elemet megjelölni, például - "Platformkonfiguráció ellenőrzése" a következő ágban:

Ebben az esetben az ellenőrzési lépések listája körülbelül a következő lesz:

és akár 20 percet is igénybe vehet még ERP-n is. De ez elég lesz ahhoz, hogy képet kapjon arról, hogyan zajlik a folyamat valójában. Bár a platform érvényesítése meglepetés és időigényes folyamat lehet, választhat egy egyszerűbb elemet is.

Tovább utolsó lépés szűrőket is beállíthat a beolvasott objektumokra. Igaz, ha ez a konfiguráció első ellenőrzése, akkor az APK-nak még nem lesz információja a konfigurációs szerkezetről. Ebben az esetben a konfigurációs fa ennél a lépésnél üres lesz, de betöltheti a "Konfigurációs szerkezet olvasása" gombra kattintva közvetlenül ugyanabból az ablakból:

Most meg kell nyomnia az "Ellenőrzés végrehajtása" gombot. Megkezdődik az ellenőrzési folyamat. Az 1C ablakok villogásával és a folyamatnapló kimenetével az üzenetablakba. A naplókimenet nagyon kényelmetlen. Az ellenőrző ablak modálisan lóg, és ha nem gondolja előre az üzenetablak láthatóvá tételét, akkor a folyamat befejezéséig nem tud semmit megtudni arról, hogy mi történik:

Ezért, ha alacsony a képernyő felbontása, akkor jobb, ha azonnal foglalkozik a költözéssel modális ablak futtassa a vizsgálatot, hogy az üzenetablak látható legyen.

Az ellenőrzés egyik szakaszában a rendszer frissíti a "Konfigurációs szerkezet" könyvtár tartalmát, amely a konfigurátorhoz hasonlóan a metaadat objektumok fát (hierarchiáját) tartalmazza. Egy adott objektumra vonatkozó adatok frissítésre kerülnek, ha ez az objektum megváltozott, vagy egy további alrendszerbe került. Egy katalóguselem törlésre kerül megjelölésre, ha a megfelelő konfigurációs objektumot törölték. Új elemek jönnek létre az új konfigurációs objektumokhoz:

Ezenkívül minden adatgyűjtéssel végzett ellenőrzéskor frissül az "ObjectPropertyValues" és a "CompactObjectPropertiesValues" regiszterek tartalma, amelyek objektumtulajdonságokat, modulokat, elrendezési tartalmat, űrlapelemeket stb. tárolnak. A korábban gyűjtött adatokkal összehasonlítva ez az információ változatlan marad.

Ha olyan ellenőrzéseket választanak ki, amelyek nemcsak a metaadat-struktúra frissítését és a platformellenőrzést igénylik, hanem valami mást is, akkor a rendszer a konfigurációt fájlokba tölti ki a későbbi elemzéshez:

A feltöltés hierarchia nélkül történik - minden fájl egy mappában van:

Információk a fejlesztőktől:

Szóval, mi és mikor megy ( az adatgyűjtéssel történő ellenőrzéskor):

• A konfigurációs struktúra általában mindig, függetlenül attól, hogy milyen követelményeket választanak.
• A gyűjtés futással történik külső feldolgozás a vastag ügyfélben lévő vállalati általános MetadataStructureLoader elrendezésből. A vállalati feldolgozás a "Metadata" platform objektumával működik, és adatokat ír egy külső fájlba, amelyet ezután átvisznek és értelmeznek az APK-ban.

Minden további lépés, amely külső feldolgozást vált ki a vállalatnál, hasonló módon működik. A többi információ, amint azt fentebb említettük, a kiválasztott követelményektől függően kerül összegyűjtésre:

• A metaadatokkal kapcsolatos információk gyűjtése (ez is a metaadat-objektumok tulajdonságai, nem pedig maga a struktúra) úgy történik, hogy külső feldolgozást indítanak el a „MetadataDataLoader” általános elrendezésből.
• Információgyűjtés az űrlapokról (pontosabban az űrlapelemekről) - feldolgozás segítségével a "FormDataLoader" elrendezésből.
• Az űrlapokkal kapcsolatos információk XML-ből gyűjtése az űrlap XML-fájljának elemzésével történik a konfiguráció kitöltéséből XML fájlok... Minden olyan információ összegyűjtésre kerül, amelyet az előző szakaszban nem lehetett beszerezni a vállalkozástól.
• Információgyűjtés a modulokról - modulszövegek kiolvasásával XML feltöltési fájlokból.
• Információgyűjtés a szerepekről (pontosabban az egyes szerepkörök jogainak összegyűjtése az egyes objektumokhoz) - az XML feltöltési szerepfájlból.
• Információgyűjtés az elrendezésekről - a "LayoutDataLoader" elrendezésből történő feldolgozás segítségével.
• Súgó információk gyűjtése - az XML feltöltési fájlok súgófájljainak olvasásával.

A konfiguráció platformellenőrzése - a demo adatbázis kötegelt indítása konfigurátor módban platform-ellenőrző kulcsokkal. Az ellenőrzési naplót tartalmazó fájl is megjelenik. Ezután megérti az APK-t, és platformellenőrzési hibákat produkál, amelyek egy külön „ConfigurationVerification Errors” regiszterben tárolódnak.

Így, ha legalább egy követelmény be van jelölve az űrlapokról XML-ből, szerepkörökről, modulokról vagy súgóból történő információgyűjtés jelölőnégyzetével, akkor a bejelölt bázis XML-fájlokba kerül. Ha a fenti műveletek egyike sem szükséges, akkor a feltöltés nem történik meg.

Korábban minden műveletet egymás után hajtottak végre. Először a struktúra összegyűjtése, majd az XML-be való feltöltés, majd a platform validálás, majd a metaadat tulajdonságok, modulok, űrlapok stb. összegyűjtése indult meg, ami a nagy konfigurációk érvényesítését (adatgyűjtését) nagyon lelassította.

Az APK 1.1.12-ben hozzáadásra került az eredeti adatbázis másolása egy ideiglenes könyvtárba, és azonosításra kerültek az adatgyűjtés leghosszabb szakaszai, ami lehetővé tette az adatgyűjtés párhuzamosítását az ellenőrzés során. Így jelenleg párhuzamosan történik a konfigurációs struktúra összegyűjtése, a platform érvényesítése, az XML-be való kitöltés és a regiszterek törlése. A többi lépés kevés időt vesz igénybe, még az ERP esetében is. A párhuzamos információgyűjtés bevezetése révén az ERP ellenőrzést legalább pár órával sikerült felgyorsítani.

Az ideiglenes fájlok könyvtárában a feldolgozás generálódik és megnyílik az ellenőrzött bázisban, amely metaadat-objektumok példányait, valamint űrlapokat és objektum-elrendezéseket hoz létre. Ezt a mechanizmust eredetileg az űrlapokról, elrendezésekről és metaadat-tulajdonságokról való információgyűjtésre szánták. De ennek köszönhetően olyan hibákat is keresnek, amelyek nem teszik lehetővé, hogy programozottan hozzon létre objektumot vagy űrlapot. Ez persze messze van az egységteszteléstől, de már valami:

Ha egy objektumban vagy űrlapmodulban egy nem deklarált változóhoz vagy a modulkontextusból elérhetetlen objektumhoz próbálnak hozzáférni, akkor a rendszer vagy hibával leállítja az ellenőrzési folyamatot (a megnyitott ellenőrzött adatbázisban lesz egy ablak) , vagy az APK észleli ezt a hibát, és megjeleníti a jelentésekben. Ha az APK leáll az ellenőrzési folyamat során egy ilyen hiba miatt, akkor ez biztosan nem túl kényelmes. Másrészt viszont a modulfordítási hibák jelenléte a programozók kritikus hibája, és jobb, ha az APK segítségével így észlelik, minthogy a gyártásba kerüljön, és erről üzenet érkezik a felhasználóktól!

A teljes ellenőrzés (vagy annak analógja a szabályok és objektumok számát tekintve) során a rendszer megakad az 1. objektum ellenőrzésénél anélkül, hogy bármilyen módon tájékoztatna a folyamatról:

Ez az állapot azzal az üzenettel, hogy a 77 ezerből 1. számú objektumot ellenőrzik, 5-10 óráig lefagy, és úgy tűnik, hogy az agráripari komplexum befagyott. Valójában a folyamat zajlik, ezt a feladatkezelőben megnézve a processzorterhelést, vagy a konfigurátorból a stopot lehívva ellenőrizheti (ha abból indult el az APK). Okoz hosszú csekk Az 1-es számú objektum, nevezetesen maga a konfiguráció a következő:

1) Ennek a lépésnek a részeként az információk összegyűjtése és gyorsítótárazása történik, amelyet a továbbiakban az egyes objektumok ellenőrzésekor használnak fel. Ez gyorsabbá teszi a többi objektum ellenőrzését.

2) Az összes konfigurációs objektumot egyszerre érintő ellenőrzések többsége ebben a lépésben kerül végrehajtásra. Sok ilyen ellenőrzés van, körülbelül 90. De a leghosszabb, legtöbbször csak egy pár. Például „Nem használt szolgáltatás-exportálási módszerek keresése”... Nyilvánvalóan lehetetlen arra következtetni, hogy egy egyedi objektum metódusát használják-e vagy sem, ha csak ezt az egy objektumot vagy egy bizonyos alrendszert ellenőrizzük. Ezt a következtetést csak a teljes konfigurációra kiterjedő módszerhívások elemzésével lehet levonni. És nyilvánvaló, hogy optimális a teljes konfiguráció megkerülése egyszer, az "Object No. 1" ellenőrzésekor, és nem sokszor az egyes dokumentumok és referenciakönyvek ellenőrzésekor. Egy másik példa a hosszadalmas ellenőrzésre "Közös modul, alrendszer, módszer meglétének és a paraméterek összetételének ellenőrzése".

Ha kettőt kikapcsol meghatározott ellenőrzéseketés a konfiguráció platformellenőrzése, majd egy olyan konfiguráció ellenőrzése is, mint az ERP, nem tarthat tovább fél óránál. De valószínűleg nem szabad időt spórolnia és feláldoznia a minőséget. Jobb ezt a problémát szervezetileg megoldani, és előzetesen ellenőrizni.

Mondok egy példát - az ellenőrzés végrehajtási napló elejét és végét, amely azt mutatja, hogy a teljes folyamat az ERP 2.1-en és az APK 1.1.11.16-on körülbelül 15 órát vesz igénybe (természetesen a szám erősen függ a számítógép teljesítményétől is, A sebesség ellenőrzése az APK 1.1.12-ben sokkal gyorsabbés azonos körülmények között körülbelül 10 órát vesz igénybe):

: Az infobázissal való kapcsolat ellenőrzése COM-kapcsolaton keresztül

: Kezdje el a konfigurációs metaadat-struktúrával kapcsolatos információk gyűjtését

: Kezdje el a konfiguráció feltöltését XML-fájlokba

: Kezdje el a metaadat-információk tisztítását

: Kezdje el a konfigurációs szerepkörök információgyűjtését

: Összegyűjtött és rögzített információk a konfigurációs szerepekről

: Összegyűjtött konfigurációs metaadatok információk

: A platformellenőrzés konfigurációja befejeződött

: Kezdje el a konfigurációs objektumok tesztelését

: Kezdje el gyűjteni a konfigurációs űrlapadatokat XML-fájlokból

: A konfiguráció ellenőrzése elindult

…… ... ITT KEZDŐK MEG AZ ÜZENETEK MEGJELENÍTÉSE AZ ÁLLAPOT SORBAN… ..

: A konfiguráció ellenőrzése végrehajtva

Az ellenőrzés eredménye

Mit kapunk az első ellenőrzés eredményeként? Először a konfigurációs verziók könyvtárát kell kitölteni (a "Versions" könyvtár a "Konfigurációk" könyvtárnak van alárendelve). Megjelenik benne az ellenőrzött konfiguráció verziójának megfelelő elem. A verzióinformáció a „Konfigurációk” katalógustétel formájában is frissül:

Másodszor, létrejön egy „Konfiguráció-ellenőrzés” típusú dokumentum, amely meghatározza a „Verziók” könyvtár ezen elemét és egyéb ellenőrzési paramétereket - az ellenőrzött követelmények listáját, az ellenőrzött objektumok listáját és az „Ellenőrzési naplót”, amely megkettőzi a az üzenetablakban korábban megjelenített napló:

Harmadszor, a konfigurációs struktúra adatai frissülnek:

A konfigurációs struktúra egy hierarchikus könyvtár elemhierarchiával, amely a "Versions" könyvtárnak van alárendelve, vagyis a konfiguráció ellenőrzésekor új verzió a „Verziók” katalógus új eleme jön létre, és már ehhez a verzióhoz kapcsolódóan egy új metaadat-struktúra is betöltődik.

Negyedszer pedig kitöltésre kerül a „Talált hibák” regiszter, amely valójában információkat tartalmaz arról, hogy mely hibákat találtuk az ellenőrzési folyamat során, és ez az alapja az APK-jelentéseknek:

Ehhez a nyilvántartáshoz nem készült lista űrlap. Ebben a közös kazánban a szemétlerakó néhány perc alatt rendbe hozható. Például adjon hozzá egy felügyelt űrlapot, felhasználói módban vagy közvetlenül a konfigurátorban jelenítse meg azoknak az objektumoknak a tulajdonosát (a "ConfigurationStructure" katalógus elemei), amelyekhez hibák vannak csatolva. Ezek a tulajdonosok lesznek a konfigurációs verziók.

Ha megjelenítjük a tulajdonosokat és belőlük, akkor lista formájában megkapjuk a hibák szűrésének lehetőségét mind konfigurációk, mind verziók szerint. Csoportosításokat készíthet rajtuk. Ebben az esetben nem csak jelentések segítségével, hanem közvetlenül a nyilvántartáson keresztül is lehet dolgozni a hibákkal, ami néha sokkal kényelmesebb:

Ebben a nyilvántartásban minden bejegyzés eltérést, helyesírási vagy egyéb hibát talált. Bármelyiket megnyitva megbizonyosodhat arról, hogy még az olyan megbízható és bevált rendszerek is, mint az ERP 2.1;)) tartalmaznak elírásokat és hibákat. Sőt, meglehetősen sok közülük:

Szeretném, ha az ilyen hibák jelenléte az ERP-ben nem a fejlesztéseinkben való jelenlétük miatti kényeztetésként fog fel, hanem annak további bizonyítékaként, hogy azonosítani és kiküszöbölni lehet és kell is. Főleg megfelelő eszközökkel. Mert csúnyán néznek ki, és a felhasználók pontosan ezt látják. Az 1C Habré blogja megjegyzi, hogy az ERP 2 fejlesztői az AIC-t használják a konfiguráció ellenőrzésére, de láthatóan az ellenőrzések listáját a saját szempontjukból legfontosabb szabályokra korlátozzák, biztosítva a fejlesztési sebesség és a termékminőség elfogadható arányát. Termékeink fejlesztése során emelhetjük a lécet a minőségre, és ezt az irányt is megragadhatjuk.

Szintén hasznos tudnivaló, hogy a modulok szövegeiről, modulblokkjairól és a konfigurációs objektumok egyéb tulajdonságairól összegyűjtött adatok az „Objektumok összetett tulajdonságainak értékei” és az „Objektumok tulajdonságainak értékei” regiszterekbe kerülnek. ”. A rekordokat ugyanazokkal az objektumokkal, alverziókkal és konfigurációkkal együtt tároljuk:

A modulszövegeket közvetlenül nem láthatja a regiszter űrlapokról, mindegyik értéktárba van csomagolva.

De az APK-ban lévő modulok szövegeinek és a konfigurációs objektumok egyéb tulajdonságainak megtekintéséhez van egy csodálatos eszköz! Ez a "Beállítások" menüben megnyitott "Konfigurációs objektumok tulajdonságainak megtekintése" feldolgozás:

Az APK jelentések

A talált hibákkal kapcsolatos információk jelentések formájában lehetővé teszik a rendszer két szakaszának egyszerre történő elérését. "Hibák" szakasz:

A FoundErrors jelentésre épül:

És a "Jelentések" szakasz

A „Munkaeredmények” jelentés alapján épül fel:

Valójában csak két fő „Jelentés” objektum van az AIC konfigurációban. De jó néhány különböző ACS-elrendezésük van:

Mindegyik a „FoundErrors” információs regiszter elemzésén alapul. A „Jelentések” rovat a hibák összefoglaló információinak megszerzésére szolgál, statisztikai fókuszú, míg a „Hibák” rész a hibákról és azok kezeléséről való részletes tájékoztatást szolgálja. A "Hibák" részben a vezérlés egy speciális parancspanel segítségével és a helyi menün keresztül is lehetséges:

Probléma adódik az APK fájlbázis és a 32 bites 1C platform használatakor. Ha nem telepít elegendő számú szűrőt, akkor a nagy konfigurációs hibák elemzésekor a memória megtelt üzenetet kaphat. ERP 2.x esetén ez az üzenet folyamatosan jelenik meg. Ez a hiba általában már a táblázatos dokumentumba való adatkiadás szakaszában jelentkezik. Általában érdemes szűrőket rakni. Közülük csak kevesen kerültek be a gyorscsapásokba. A többi a "Jelentésbeállítások" paranccsal állítható be.

Megakadályozza, hogy egy opció kiválasztása után azonnal megjelenjenek a jelentések. Ez nagymértékben akadályozza a munkát, és azt sugallja, hogy az agráripari komplexum konfigurációját véglegesíteni kell a saját jelentések megírásáig: kijelöléseket szeretne előírni, mielőtt azok létrejönnének, és hogy a jelentésbeállítások mentésre kerüljenek, és kezelt formábanők voltak. Szerencsére egyetlen információnyilvántartás alapján ezt nem nehéz megtenni.

Vegye figyelembe, hogy ha az APK 1C vagy sql adatbázisának 64 bites verzióját használja, nem figyelhető meg az elégtelen memória miatti hiba.

A jelentések első pillantására úgy tűnik, hogy az APC túlságosan válogatós az ellenőrzött konfiguráció tekintetében. Például megfelelő szinonimák megadását igényli még az elrendezésekhez is nyomtatott űrlapok, tévedésnek tekinti a „logisztikai”, „kiegészítő”, „elszámolható” stb. De először a legtöbb talált hibát valóban ki kell javítani! Másodszor, az ellenőrizendő szabályok kiválasztása a felhasználó rendelkezésére áll, ez megtehető mind az ellenőrzött konfiguráció beállításakor, mind az ellenőrzés során. Harmadszor, az egyes szabályok kívánt esetben módosíthatók, lecserélhetők a sajátjaival, vagy beállíthat szűrést a jelentésekben úgy, hogy csak az érdeklő információkat lássa.

Végül további testreszabási lehetőségek is vannak a rendszerben. Például a „TrueWords” információs regiszter (kezdetben üres). Részt vesz a helyesírás-ellenőrzésben, különösen a Check.Check Spelling () módszerben. Az általunk helyesnek ítélt szavak beírhatók manuálisan vagy letölthetők innen szöveges fájl amelyben minden szó benne van külön sor... Egy ilyen txt fájl mintája kirakható az „Igaz szavak szótára” általános elrendezésből. De ezt a fájlt nem kell betöltenie a regiszterbe. A rendszer alapértelmezés szerint ebből az elrendezésből veszi ki a megfelelő szavakat, és kiegészíti a nyilvántartásból származó adatokkal. Van egy feldolgozás is a rendszerben" Szótár frissítés". Használatát nagyon részletesen és világosan leírja a felhasználói kézikönyv (lásd a 4.6. fejezetet).

Általánosságban elmondható, hogy ha úgy tűnik, hogy a rendszer túl szigorú a mi konfigurációinkhoz, akkor a megfelelő helyeken módosíthatja, és "cajole"))

A legérdekesebb jelentések a "Követelmények hibák" a "Hibák" részben, amelyek a "Követelmények" könyvtár szerkezetének megfelelő csoportosításban jelenítik meg az adatokat:

és a „Jelentések” részben a „Hibaelemzés”, amely az „1C: Kompatibilis”, „Kötelező” és „Ajánlás” besorolás alapján összesítő adatokat jelenít meg:

Konfiguráció érvényesítési szabályok

Saját szabályok létrehozása konkrét példák itt nem vesszük figyelembe. Először magának kell jobban megértenie ezt a kérdést. Az APK-hoz mellékelt felhasználói kézikönyvben egy meglehetősen terjedelmes 5. fejezet foglalkozik új szabályok létrehozásával – ez egy átívelő példa, akár 30 oldalnyi lenyűgöző szöveg és illusztráció formájában))

Nézzük át a szabályokat egy áttekintésben. A rendszer azonos nevű könyvtárában találhatók:

A bal oldali fában a navigáció kényelmetlen – duplán kattintva kiválaszthat egy elemet, hogy a jobb oldali részben megjelenjen az összetétele. Ezért a kiválasztott elem nem mindig esik egybe azzal, amelynek összetétele a jobb oldalon látható.

Mindegyik szabály megnyitható. A directory elem formája hozzáférést biztosít a szabály által ellenőrizendő objektumtípusok listájához, az algoritmus paramétereihez (az algoritmusból hivatkozható hibák számozott listája), magához az algoritmushoz és leírásához, az algoritmus leírásához. a követelmény, valamint a használati beállítások:

A tetején három hasznos gombok... A „Szabványok megjelenítése” az 1C webhely megfelelő szakaszához vezet a szabvány leírásával, a hivatkozás megnyílik a böngészőben. Az „Open Requirements” megnyitja a szabálynak megfelelő „Követelmények” katalóguselemet, és az „Open Debug” parancs megkezdi a „ValidationRulesDebugger” feldolgozását. A használati útmutatóban hallgat, hogy miként működik, de az nyilvánvaló, hogy vagy elérhetőek a hibakereső eszközök, vagy vannak rájuk fejleszthető fejlesztések.

A szabályalgoritmus módosítható, valamint új szabályok, szabálycsoportok hozhatók létre. Ha saját algoritmusokat kell írnia, akkor tanulmányoznia kell a beépített metódusokat és programobjektumokat. Ez a témája a PDF használati útmutató 6. fejezetének megfelelő szakaszának „Az ellenőrzési szabályok szintaxisa”. A meglévő szabályok algoritmusait is használhatja példaként és példaként a másoláshoz.

A program beépített súgója katasztrofálisan kevés. Inkább hiányzik, így a beépített módszerek leírása nem szerezhető be belőle.

Objektumok szűrése ellenőrzések során

Végezetül nézzük meg, hogyan viselkedik az APK 1.1, amikor az előírt szűrőkkel ellenőrzi. Valóban segítenek lerövidíteni az ellenőrzési időt és csökkentik a jelentésekben szereplő információ mennyiségét? Ellenőrizzük az előtag és az alrendszer szűrését is.

Ebben a részben több "betemetés" lesz, mint az agráripari komplexum képességeiről szóló történet. Ha bekapcsolva ezt a szakaszt nem ez a célod – ezt a részt kihagyhatod.

Vegyük ugyanazt a kísérleti konfigurációt, hozzunk létre hozzá egy új elemet a konfigurációs hivatkozásban (csak egy elemet nem másolással kell létrehozni, mivel konfigurációk másolásakor a verziók és az adatszerkezet is másolódik, ez egy hosszú folyamat, és sérti a kísérlet tisztaságát). A dokumentumokat két új alrendszerbe soroljuk:

apk_Document_1_1,apk_Document_1_2és új_Dokumentum_1_3 alrendszerre utalunk apk_Subsystem_1

apk_Document_2_1, apk_Document_2_2és új_Dokumentum_2_3 alrendszerre utalunk apk_Subsystem_2

Kövessünk el helyesírási hibákat a dokumentumokban, és adjunk hozzá egy nem használt export módszert a kezelő modulhoz. A dokumentumokat másolással hozzuk létre.

Adjunk hozzá két szűrőt az információgyűjtéshez - előtagonként apk_és az alrendszeren apk_Subsystem_2 (a képernyőkép az APK 1.1.11.16-os verziójáról készült):

Az ellenőrzés eredményeként csak a szűrőknek megfelelő dokumentumokra számítunk hibák és hibajelentések megjelenésére. (ahogy alább látható, a szűrők „VAGY” alkalmazásra kerülnek)... Az ellenőrzési folyamatot is szeretném felgyorsítani, azzal a kedvezménnyel, hogy bizonyos műveleteket és ellenőrzéseket a vizsgált objektumok számától függetlenül végrehajtanak.

Kezdjük az ellenőrzést. Néhány órás alapellenőrzés (beleértve a platformellenőrzéseket is) után látni fogjuk, hogy a további ellenőrzésre szánt objektumok száma már nem 77 736, hanem csak 65 ijesztő:

Az ellenőrzések eredményeként a jelentések valóban nem adnak információt az "extra" objektumokról, és csak a szűrőknek megfelelő objektumokról adnak jelentést. Ugyanakkor mindkét speciálisan elkövetett hibát találtak, és további megjegyzéseket tettek:

A szűrők ellenőrzési ideje azonban szinte semmi hasznot nem hoz. Ebben a példában a teljes ellenőrzés 15 óra helyett 10 órát vett igénybe, vagyis csak 30%-kal gyorsult fel. Az „Ellenőrzések lefolytatása” részben már kifejtették ennek a viselkedésnek az okait. Most nézzük meg, hogy ez miért történik kódszinten, és egyúttal értsük meg alaposabban, hogyan működnek a konfigurációs szerkezeti elemek szűrésére és az ellenőrzések során történő megkerülésére szolgáló algoritmusok.

A jelentések azt mutatják, hogy a dokumentumokkal kapcsolatos információk mellett az általános ellenőrzések részeként a gyökér konfigurációs elemre vonatkozó információkat is gyűjtik. Az ellenőrzések során pedig nehéz nem észrevenni, hogy ennek az 1. számú objektumnak az ellenőrzéséről szóló üzenet az állapotsoron lóg szinte mind a 10 órán keresztül. (1.1.11.16-os verziónál)... Ezzel egyidejűleg 65 objektum közelgő ellenőrzéséről ad tájékoztatást a rendszer, igaz ebből maximum 6-8 db-ra van szükségünk. Állítsuk le a folyamatot a hibakeresőben, amíg az „Object # 1 is be checking” üzenet lóg az állapotsorban, és nézzük meg, hogy mely modulokat ellenőrzik. Látható, hogy az ellenőrzés első szakaszában a rendszer még elemzi az összes objektumot, beleértve például a fizetési közös modulokat, amelyek biztosan nem szerepelnek az új alrendszerünkben:

De nem követeltük meg a rendszertől, hogy adatokat gyűjtsön a közös modulokról. Melyek azok a 65 objektumok, amelyeket a rendszer ellenőrizni fog?

Ezek listáját úgy kaphatja meg, hogy a "VersionCheck" dokumentumobjektum modulban a hívási veremben felmegy a CheckObjects () metódusra. Arról is információt kaphat, hogy a StructureConfiguration könyvtárból az ÖSSZES olyan objektum, amelyhez adatokat gyűjtöttek, ki van jelölve ellenőrzésre, vagy a rendszer úgy tekinti, hogy az adatgyűjtés megtörtént:

Ezek az objektumok:

Maguk az objektumok 65-nél kisebbek, a rendszer egyszerűen nem csak a dokumentumainkat számolta, hanem azok adatait is. De láthatja, hogy a ConfigurationConfigurations katalógus hierarchiájának gyökéreleme volt a legelső ebben a listában. És láttuk, hogy az ellenőrzés folyamata olyan sokáig tart.

Ezen objektumok listája alapján következtetéseket vonhatunk le a szűrési mechanizmus működéséről és az ellenőrzések szűrőkkel való működéséről:

A szűrés csak az adatgyűjtés szakaszában működik. Magában az ellenőrzés folyamatában a szűrők már nem játszanak szerepet. És ez logikus, mert az algoritmusok felhasználói módban vannak beállítva. Az APC csak akkor küldi el őket a StructuralConfiguration könyvtár elemeinek ellenőrzésére, ha úgy ítéli meg, hogy adatgyűjtés történt róluk.

Az ellenőrzésekhez alkalmazott szűrők ellenére az APK az ÖSSZES konfigurációs objektum moduljáról gyűjt információkat. A modulokon lévő adatokat az APC a teljes konfigurációra jellemző ellenőrzések elvégzéséhez használja fel. Az alábbiakban látható, mi történik, ha letiltja az ilyen ellenőrzéseket.

A gyakori objektumok egy része minden esetben ellenőrzés céljából jelen lesz a listában, függetlenül a szűrőinktől. Beleértve a legfelső gyökérobjektumot - magát a konfigurációt. Ez ismét az "általános" ellenőrzésekhez szükséges. Mivel a listában szereplő konfigurációt továbbra is ugyanazok a szabályok szerint ellenőrzik, mint korábban, és a közös modulokat, azok szövegeit és néhány egyéb adatot nem szűrtük ki az adatgyűjtés során, továbbra is az 1. számú objektum leghosszabb többórás ellenőrzése kerül végrehajtásra. . A szűrők használatával nem lehet radikálisan felgyorsítani a folyamatot.

A rendszer úgy döntött, hogy nem csak azokat a dokumentumokat ellenőrzi, amelyek mindkét szűrőnknek megfelelnek, hanem azokat, amelyek bármelyiket kielégítik. Az előtaggal kezdődő objektumokat is elküldjük ellenőrzésre. apk_és az alrendszerben szereplő objektumok apk_Subsystem2 dokumentumot is beleértve új_Dokumentum_2_3... Csak egy dokumentum tűnt el a szkennelt objektumok listájáról új_Dokumentum_1_3 semmilyen szűrőhöz nem alkalmas. Az eredmény egyértelművé válik, ha belenéz a szűrési funkcióba. A megengedő szűrők az "OR"-on működnek, nem az "AND"-on. Ha ezt meg kell változtatni, akkor ismét kis változtatásokat kell végrehajtania ezen a módszeren:

Most próbáljunk meg „játszani” a kóddal, és nézzük meg, mi történne, ha a szűrés nem csak az adatgyűjtés, hanem az ellenőrzés szakaszában is működne. Ehhez hozzunk létre még egy elemet a konfigurációs könyvtárból ugyanazokkal a szűrőkkel:

A VersionCheck dokumentum CheckObjects () metódusának kódjában mesterségesen kihagyjuk az első kijelölő elemet a lekérdezés eredményének bejárása során. Vagyis hagyjuk ki a ConfigurationConfiguration könyvtár gyökérelemét:

Végezzük el ugyanazt az ellenőrzést, és nézzük meg, mennyi időbe telik a teljes folyamat, és nézzük meg, hogy a jelentések eredményei eltérnek-e a konfiguráció gyökerének kihagyása nélkül kapott eredményektől.

Ebben az esetben 10 óra helyett csak 50 perc telik el a folyamat kezdetétől a befejezéséig:

: Létrehozva dokumentum 8-as verzió ellenőrzése 2017.11.01. 20:51:37-től

………………..

: Kezdje el a konfiguráció feltöltését XML-fájlokba

: A konfigurálás XML-fájlokba való kiíratása befejeződött

………………..

: A konfiguráció ellenőrzése elindult

: A konfiguráció ellenőrzése végrehajtva

Most a beszámoló:

Láthatja, hogy a gyökérelem már nem jelenik meg. Ezenkívül a jelentés 10 helyett 9 sort jelenít meg minden egyes dokumentumhoz kapcsolódóan. Hiányoznak a nem használt exportálási módszereket jelző sorok a dokumentumkezelő modulokban. Vagyis a hibák egy része valóban csak akkor észlelhető, ha a ConfigurationConfigurations könyvtár gyökéreleme részt vesz az ellenőrzési folyamatban. Ellenkező esetben a megfelelő ellenőrzési szabályok egyszerűen nem működnek. Ezek olyan hibák, amelyek észlelésekor a logika szerint ellenőrizni kell az objektum kapcsolatát az összes többi konfigurációs objektummal.

Ha tehát drasztikusan fel akarjuk gyorsítani az ellenőrzéseket a szűrők alkalmazásakor, akkor ezt vagy a leghosszabb, minden modul megkerülését igénylő általános ellenőrzések letiltásával kell megtenni (ezt a beállításokban lehet megtenni), vagy saját alternatív ellenőrzési szabályok kidolgozásával. .

Eredmény:

Az "Automatic Configuration Testing" eszköz valóban lehetővé teszi, hogy konfigurálás után megtalálja a hibákat a konfigurációkban automatikus módban. Az APK lehetővé teszi a durva konfigurációs hibák megtalálását, a helyesírás helyesbítését, összhangba hozását az 1C meglehetősen ésszerű és ésszerű fejlesztési szabványaival.

Az APK nem helyettesítheti teljesen más kódjavító eszközöket, például a kódellenőrzéseket. Nem engedi nyomon követni a szükségtelen másolás-beillesztés (kódduplikáció), több szerverhívást, ahol ezeket egybe lehet csomagolni, illetve nem lehet ellenőrizni a nem optimális kérés legegyszerűbb jeleit. De jelentősen csökkentheti a vizuális ellenőrzés szükségességét, és jó kiindulóponttá válhat más eszközök és gyakorlatok számára. És ha szükséges, írjon saját csekket, amelyek több problémát oldanak meg, mint azok, amelyek már nem kaphatók.

A róla szóló információk hiánya ellenére nem nehéz elsajátítani ezt az eszközt a gyakorlati használathoz. A felhasználói kézikönyv és most ez a cikk jó kiindulópont lehet a lépésenkénti útmutató elkészítéséhez. Maga az APK konfigurációja meglehetősen egyszerű és könnyen módosítható, legalábbis a felületet tekintve. Valóban sok a finomítás. Egy kényelmes és hatékony felhasználása a "tankjainknak" mindig kell egy fájl))

A saját ellenőrzési szabályok kidolgozása megköveteli az APK „beépített nyelvének”, pontosabban a beépített eljárások és funkciók elsajátítását, ezt a felhasználói kézikönyv és a meglévő szabályok segítségével lehet megtenni.

Még a legegyszerűbb műveletek is, amelyek adatgyűjtést igényelnek olyan konfigurációkból, mint az ERP, több mint 20 percet vesz igénybe az AIC számára. Ezért saját ellenőrzési szabályainak fejlesztéséhez és hibakereséséhez vagy saját kis bemutató konfigurációkat és bemutató adatbázisokat kell létrehoznia, amelyekben egyes modulok megsértik ezt a szabályt, vagy végezzen ellenőrzéseket korábban összegyűjtött adatok felhasználásával. Mindkét technika felgyorsítja az új szabályok hibakeresésének folyamatát.

• A konfiguráció eszközöket tartalmaz az új és a meglévő szabályok hibakereséséhez. A velük való munkához foglalkozni kell az APC konfigurációs kóddal, meg kell nézni, hogyan jönnek létre az objektumok, és milyen kontextusban futnak le a felhasználói módban megadott algoritmusok. De ha kívánja, ez teljesen lehetségesnek tűnik, a megközelítéseknek hasonlóaknak kell lenniük az "Adatkonverzió"-ban használt megközelítésekhez.

Előfordul, hogy az 1c adatbázisokban bajok történnek - a korábban működő 1c jelentés nem indul el, a dokumentumot nem tartják meg egy érthetetlen hiba miatt, lehetetlen belépni a programba ... Az 1c hibák kijavításának egyik fő módja a tesztelés és az 1c 8.3 adatbázis javítása a platformba épített segédprogram segítségével.

Ezt szeretném megjegyezni bármelyiknél helytelen munka 1C Enterprise 8.3, a program teljesítményének visszaállításának fő módszerei a következők:

1. A gyorsítótár törlése 1C Enterprise;
2. Az alap tesztelése és rögzítése 1c 8.3.

Az 1C gyorsítótár eltávolításának módszerét a cikk részletesen ismerteti. Fontolja meg a második szolgáltatási eszközt az 1C platform adminisztrálására.

Az 1c 8.3 adatbázis tesztelése és javítása a beépített segédprogrammal

A művelet elindításához nincs szükség speciális ismeretekre, így ezt bármely felhasználó meg tudja oldani anélkül, hogy kapcsolatba lépne az 1c szakembereivel. A tesztelés és a javítás megkezdéséhez be kell lépnie az 1c konfigurátorba, és ki kell választania az "Adminisztráció" - "Tesztelés és javítás ..." menüpontot.

Az "1c infobázis tesztelése és javítása" segédprogram leírása

A megnyíló űrlap számos olyan elemet tartalmaz, amelyek lehetővé teszik a hibák javítását. Professzionálisan használható ezt az eszközt, meg kell érteni az egyes pontok célját és logikáját, ezért nézzük meg őket közelebbről:

• Infobázis táblák újraindexelése.

Mert gyors keresés információ, a fő táblákhoz segédtáblázatok kerülnek hozzáadásra a fő adatokkal, amelyekben az adatok a főtábla - az indexelő tábla - megadott mezői szerint vannak rendezve. Az indexelő táblák használatának köszönhetően az 1c teljesítménye jelentősen megnő, hiszen a kijelöléshez nem kell a teljes fő adattáblát iterálni, az indexfájl segítségével onnan választhatjuk ki a szükséges rekordokat.
A fő adattáblákba történő adatíráskor az indexelő táblák is kitöltésre kerülnek. De különféle technikai okok miatt az indexek elveszhetnek, ami a végén hibákhoz vezethet. Ennek a hibaosztálynak a kijavításához az 1c 8.3 alap tesztelése és javítása során be kell jelölni a menüpont melletti négyzetet.

• Az információs bázis logikai integritásának ellenőrzése

Amikor az 1c konfigurációban új objektumokat hoz létre, új táblák jönnek létre az adatbázisban, amelyek az adatbázis más tábláival való hivatkozásokat jelzik. Különféle okok miatt a csatlakozások hibássá válhatnak (például hibás frissítés vagy váratlan áramszünet miatt a rögzítés idején). Az ilyen jellegű hiba kijavításához válassza ezt a menüpontot.

• Egy információs bázis hivatkozási integritásának ellenőrzése

Ezeknek a hibáknak az azonosításához és kijavításához válassza ezt a menüpontot, miközben az ilyen hibák kezelésének lehetőségei az alábbiakban aktiválódnak (lásd a fenti ábrát). Kiválaszthatjuk, hogyan javítsuk ki a hibákat mikor ha vannak hivatkozások nem létező objektumokra: objektumokat létrehozni, egyértelmű hivatkozások, ne változtass; és részleges adatvesztéssel: objektumokat létrehozni, törölje az objektumot, ne változtassa meg.

• Az összegek újraszámítása

Az 1c adatbázisban történő gyors adatkiválasztáshoz a már számított adatokat tartalmazó táblázatok találhatók, havi gyakorisággal. Amikor erre az adatra jelentkezünk, akkor nem a főtáblákból gyűjtjük össze (hosszú időbe telne), hanem azonnal visszaadjuk az összesítő táblák adataiból. Ennek megfelelően ahhoz, hogy ez a mechanizmus működjön, helyes eredményekre van szükség az elmúlt időszakokra vonatkozóan. Ezért ha az 1s "csal" a jelentésekben, akkor az ilyen hibát ez a menüpont javítja.

• Infobázis táblázatok tömörítése

Az objektumok törlése az adatbázisban meglehetősen fáradságos és időigényes művelet, ezért az 1c konfigurációkban a törlési folyamat 2 szakaszra oszlik. Amikor töröl objektumokat a konfigurációban, az 1c adatbázisban lévő adatok törlődnek, és emiatt nem vesznek részt a további műveletekben, bár fizikailag a helyükön maradnak. A táblák ezen rekordoktól való megtisztításához az 1c 8.3 alap tesztelését és korrekcióját végzik a "Táblázatok tömörítése" menüponttal. információs bázis».

• Infobázis táblák átstrukturálása

Bármely 1c metaadat objektum részleteinek módosításakor az adatbázisnak ki kell egészítenie a megváltozott objektum összes tábláját új rekordokkal. Ez az adatbázistáblák átstrukturálásával történik. Az átstrukturálás során az adatbázis táblákról másolatok készülnek az aktuális konfiguráció felépítésével, majd az adatok átkerülnek a létrehozott táblákba. Ha hozzáadunk egy változót az 1c metaadatokhoz, akkor az új táblában egy üres oszlop jön létre hozzá; ha egy attribútumot törölünk, akkor az új táblában nem jön létre az ehhez az attribútumhoz tartozó oszlop, és ennek megfelelően nem kerül átadásra.
Az átstrukturálási folyamat az adatbázisban lévő összes táblát újra létrehozza, így ez a leghosszabb művelet.

1c 8.3 alap tesztelése és rögzítése a gyakorlatban

Az átfogó információk megszerzése után úgy gondolom, hogy könnyen eligazodhat, hogy milyen segédprogramokat kell kiválasztania a javításhoz.

Az 1c 8.3 alap tesztelése és rögzítése két módban történhet:

1. Tesztelés. Ebben a módban az adatbázist tesztelik, és technikai javításokat végeznek a kisebb hibákhoz.
2. Tesztelés és javítás. Ebben a módban az 1C adatbázis tesztelésre kerül, és megpróbálja kijavítani az összes észlelt hibát (lásd a fenti ábrát).

Az 1c 8.3 alap teszteléséhez és javításához a "Futtatás" gombra kell kattintani, ami után a konfigurátor alján található információs ablakban megtekintheti a tesztelés és a javítások menetét.

Hasonló

Az 1C 8 megvalósítása számos előnnyel jár, azonban a hatékony munka csak akkor lehetséges Jó minőség funkcionális és technológiai rendszerek.

A rendszer funkcionális és technológiai minősége - jellemzők és különbségek Az információs rendszer funkcionális minősége egy bizonyos konfiguráció képessége a vállalat üzleti problémáinak megoldására, a technológiai minőség pedig a magas termelékenység, a meghibásodásmentesség és a stabil működés. A minőségi teljesítménymenedzsment jelentősen eltér:

• a rendszer technológiai minőségét a rendszer meghatározott megvalósítása során ellenőrzik. 1C licencelt program a platformon megvalósítva 1C: Enterprise 8, biztosítania kell több felhasználó stabil működését bizonyos berendezéseken. Ebben az esetben nem mindegy, hogy milyen képességek rejlenek a rendszerben;
• a funkcionális minőséget egy adott konfigurációra és annak képességeire tesztelik. A rendszer minőségét a rábízott feladatok elvégzésének képessége határozza meg, függetlenül a felhasználási feltételektől.

A rendszer funkcionális minősége a következő mutatók segítségével ellenőrizhető:

• Az 1C licencprogram minden üzleti problémát megold;
• minden helyes felhasználói lépésre válaszul a rendszer megfelelően és kiszámíthatóan viselkedik.

Így a funkcionális minőség két területből áll – tárgyi és technikai. A rendszer tantárgyi értékelését csak meghatározott szakterület szakembere végezheti, míg a műszakit a feladatoktól függetlenül.

Miért van szükség a rendszer magas funkcionális minőségére? A megvalósításhoz szükséges rendszer kialakítása több okból is komoly megközelítést igényel. A kiváló minőségű rendszer biztosítja az 1C 8 könnyebb megvalósítását, aminek eredményeként a vállalat időt és pénzt takarít meg. Ezenkívül a jó minőségű 1C rendszer karbantartása sokkal könnyebb, és kevesebb figyelmet igényel a szakemberektől.

A kész rendszerre épülő új megoldások kidolgozásakor minden folyamat sokkal gyorsabb és egyszerűbb, működése pedig kiküszöböli a működési zavarokat.

Hogyan határozzuk meg a funkcionális minőséget? A hibák hiánya a programkódban egyáltalán nem jelenti azt, hogy a rendszer funkcionális minősége egy bizonyos szinten van.

A konfiguráció általános minőségét számos tényező határozhatja meg, például:

• naprakész és részletes referencia információk elérhetősége. Az "F1" megnyomásával a felhasználónak szükségszerűen segítséget kell kapnia minden konfigurációs objektumhoz;
• borravalók elérhetősége. Az egyes űrlapvezérlőkre vonatkozó rövid tippeknek meg kell magyarázniuk ezeknek az űrlapoknak a jelentését;
• a képernyőformák méretei kényelmes munkavégzést biztosítanak, és nem haladhatják meg standard értékek;
• a rendszerek üzeneteinek és figyelmeztetéseinek szövege tömör és érthető legyen, helyesírási és nyelvtani hibák nélkül;
• visszafordíthatatlan műveletek végrehajtása előtt a rendszernek figyelmeztetést kell adnia a műveletről és annak következményeiről;
• programkód naprakész és átfogó megjegyzésekkel kell rendelkeznie.

Teljes lista a rendszer minőségi követelményeit tartalmazza módszertani kézikönyv"Szabványrendszer és konfigurációfejlesztési módszerek". Rendszer minőségirányítás - módszerek és lehetséges problémákat A legtöbb hatékony módszer minőségirányítási rendszer a megelőzés. Mint minden vállalkozásnál, könnyebb a probléma kiváltó okát orvosolni, mint a rossz minőségű következményeket. Egy technika, amely lehetővé teszi a platform konfigurációs hibáinak azonosítását és minimalizálását 1C: Enterprise 8 több pontból áll:

• a konfigurációhoz szükséges alapvető szabványok meghatározása;
• az aktuális verzió ellenőrzése, hogy megfelel-e a megállapított szabványoknak;
• ellentmondások észlelése esetén a szakemberek értesítése a talált hibákról; a hibákkal kapcsolatos statisztikai információk felhalmozása.

Ennek a módszernek azonban az elterjedtsége ellenére számos negatív tulajdonsága van:

• még egy kis rendszer ellenőrzése is sok időt vesz igénybe, és egy összetett konfiguráció, amely több száz objektumot tartalmaz, egyszerűen lehetetlenné teszi a kézi ellenőrzést;
• a konfiguráció-ellenőrzőnek magasan képzettnek kell lennie, és ismernie kell a szabványokat. Még ha a cégnek van is ilyen szakembere, nem a legracionálisabb döntés az idejét a rutinműveletek elvégzésére pazarolni.

Hogyan csökkenthető a rendszer minőségének ellenőrzésére fordított idő? 1C ajánlatok praktikus eszköz"Automatikus konfiguráció-ellenőrzés", amely lehetővé teszi a következőket:

• ellenőrizze, hogy az „1C: Enterprise 8” konfigurációk megfelelnek-e a fejlesztési módszereknek. Ezenkívül a programnyilvántartás kiegészíthető speciális ellenőrzési szabályokkal, amelyek ehhez szükségesek konkrét eset;
• információgyűjtés a talált rendszerhibákról és automatikus elosztás a kritikusság mértéke szerint;
• a hibák elosztása a javításért felelős fejlesztők között.

Alkalmazások automatizált ellenőrzéshez Szoftvertermék használata 1C: Automatikus konfiguráció ellenőrzés, egyszerre több problémát is megoldhat, többek között:

• az adott szervezet számára kifejlesztett konfigurációk funkcionális minőségének ellenőrzése, mind a gyártási, mind az egyedi konfigurációk felett;
• Az 1C támogatás magában foglalja a szabványos és iparág-specifikus programok időszakos revízióit és módosításait, az 1C: Automated Configuration Checker megoldás pedig lehetővé teszi ezen változatok minőségének ellenőrzését;
• a vállalkozás számára kínált konfiguráció minőségének értékelése. A megvalósításra való felkészülés során a program lehetővé teszi, hogy ne csak a konfiguráció technológiai minőségét, hanem a fejlesztők kompetenciáját is megismerje.

A nyilvánvaló előnyök mellett az 1C program automatikus rendszerellenőrzésre való használata segít az informatikai szakemberek képzésében a konfiguráció minden szakaszának alapos tanulmányozására. A módosítások ellenőrzése lehetővé teszi az összes "ideiglenes", rossz minőségű hely gyors azonosítását a rendszerben, a személyre szabás pedig lehetővé teszi, hogy hozzászoktasson ahhoz a gondolathoz, hogy minden konfigurációs részt hatékonyan kell elvégezni, anélkül, hogy későbbi felülvizsgálatra számítana.

Tehát a segítséggel kényelmes program 1C bármely cég képes lesz biztosítani a magas színvonalú rendszer megvalósítását és a konfiguráció hibátlan működését.

29.09.2016

Az 1C Enterprise 8 rendszer programjainak tipikus konfigurációinak telepített frissítéseinek használatának jogszerűségének ellenőrzése.

Hozzáférés az 1C: Fresh felhőhöz 30 napig ingyen!

Az 1C: Enterprise platform 8.3.7 verziójától kezdve az 1C programok bevezettek egy mechanizmust az 1C alkalmazott megoldások használatának jogszerűségének ellenőrzésére, beleértve az 1C konfiguráció frissítéseit.

A tipikus konfiguráció és az 1C: Enterprise platform következő frissítésének telepítése után a program üzenetet jeleníthet meg arról, hogy problémák vannak a telepített konfigurációs frissítés használatának jogszerűségének ellenőrzésével a frissítésvédelmi központban.

Ennek a mechanizmusnak az a célja, hogy a felhasználót időben tájékoztassa a konfiguráció egyes verzióinak vagy kiadásainak tényleges használatáról, amelyekhez nem rendelkezik jogokkal, és az ezzel járó lehetséges jogi kockázatokról.

Az ellenőrzés a fájlverzióban vagy a kiszolgálón a MINI verzióban telepített alkalmazásmegoldások esetében történik. Az érvényesítési ellenőrzést nem hajtják végre az alaplicencet használó alkalmazásmegoldások esetében. Az ellenőrzési eljárást az 1C: Enterprise rendszerkonfiguráció frissítésének befejezése után hajtják végre, és a program kérést küld a Frissítésvédelmi Központnak (a továbbiakban: CPO).

Figyelem! V Ebben a pillanatban lehetséges technikai problémák a frissítésvédelmi központ https://1cv8update.com webhelyének elérhetőségével

A telepített konfigurációs frissítés jogszerűségének ellenőrzése során a programra és az adatokra vonatkozó információk kerülnek felhasználásra fiókot a szoftvertermék regisztrációja és az IT-támogatási megállapodás 1C: ITS Portálon történő regisztrációja során jött létre. Ha a konfigurációs frissítést jogellenesen telepítették, a program időnként létrehoz egy párbeszédpanelt, amely információkat tartalmaz az alkalmazott megoldás jogellenes használatának okairól.

A felhívás sikeres teljesítése esetén a CPO visszaadja a felhasználás jogszerűségi állapotát. Ha a CPO nem erősíti meg a telepített konfigurációs frissítés használatának jogszerűségét, az 1C: Enterprise rendszer elkezdi tájékoztatni az információs bázis összes felhasználóját, hogy ez alkalmazott megoldás illegálisan használják fel, miközben a CPO-tól kapott információ megjelenik.

Az ellenőrzés eredményeivel kapcsolatos információk az "A programról" párbeszédpanelen is megtekinthetők, amely információkat tartalmaz arról, hogy a CPO hívása hogyan végződött:

Ahhoz, hogy az 1C alkalmazott megoldás sikeresen átmenjen az ellenőrzésen a CPO-ban, a következő feltételeknek kell teljesülniük:

• A programnak licenccel kell rendelkeznie.
• A szoftverterméknek érvényes ITS-előfizetéssel kell rendelkeznie.
• A szoftverterméket regisztrálni kell személyes fiók felhasználó az 1C portálon
• Az internetes felhasználói támogatást engedélyezni kell a konfigurációban.

Így, ha az 1C programja problémákat jelez a használt konfiguráció érvényességének ellenőrzésével kapcsolatban, akkor ennek egy vagy több oka lehet:

• Ok 1. Licenc nélküli (kalóz, feltört, "hardver", "foltozott" stb.) verziót használnak szoftver 1C.

  Megoldás: Két lehetőséget kínálunk a probléma megoldására: vásárolja meg az 1C szoftvertermék licencelt verzióját, vagy menjen dolgozni az „1C a felhőben” szolgáltatásba.

  1. lehetőség: Vásárolja meg az 1C szoftvertermék licencelt verzióját.

  Felhívjuk figyelmét, hogy pontosan azt a készletet kell megvásárolnia, amely tartalmazza az Ön által használt konfigurációt, pl. ha például az 1C: Trade Management alkalmazást használja, akkor nincs értelme az 1C: Accounting vásárlásának, mert ez nem oldja meg a konfiguráció használatának érvényességének ellenőrzését.
  Ha a program egyfelhasználós verziója van fájl módban, akkor elegendő csak az alapcsomag vásárlása. Ha a hálózati verziót több számítógépen használja kliens-szerver módban, akkor továbbiakat is kell vásárolnia kliens licencekés licencet az 1C: Enterprise szerverhez.

  1C programok költsége

  Név	Ár dörzsölés.	Egy komment
  1C: Számvitel 8 PROF. Elektronikus kézbesítés
  A legtöbb gyors opció engedélyezés! Szállítási idő a fizetéstől számított 3-4 óra! *		Alapellátás 1-hez munkahely szoftveres védelmi rendszerrel.
  1C: Bérezés és személyi gazdálkodás 8 PROF. Elektronikus kézbesítés A leggyorsabb engedélyezési lehetőség! Szállítási idő a fizetéstől számított 3-4 óra! *		Alapkiszállítás 1 munkahelyre szoftveres védelmi rendszerrel.

  
  Mások költségei szoftver termékek 1C: Vállalati rendszerek, további kliens és szerver licencek az árlistában találhatók.
  Ha sürgősen legalizálnia kell az 1C: Számviteli vagy 1C partnerek nem rendelkeznek ezzel a programmal az Ön régiójában, megvásárolhatja az "Elektronikus kézbesítést" cégünknél. Az elektronikus kézbesítés a program „doboz nélküli” változata, amely 100%-ban licencelt, funkcionálisan nem különbözik a megszokott „doboztól”. A Portal 1C személyes számláján történő fizetés után letöltheti a program telepítési disztribúcióit, az aktiválási kódokat és a dokumentációt elektronikus formátumban(v pdf formátumban). Ha szakembereink segítségére van szüksége a program telepítésénél, távolról, az interneten keresztül segítenek.

  2. lehetőség: Menjen dolgozni az „1C a felhőben” alkalmazásba.

  Ebben az esetben feltölti az adatbázist az összes felhalmozott hitelesítő adattal az 1C Fresh felhőkiszolgálóra (https://1cfresh.com/).
  Nem kell megvásárolnia az 1C szoftvert és telepítenie a programot a számítógépére. A programban végzett munka az interneten keresztül történik egy normál böngésző vagy "1C Thin Client" segítségével, amely legálisan ingyenesen letölthető az 1C hivatalos webhelyéről.
  Az 1C felhőszerverhez való hozzáférés bérleti alapon történik a SaaS (Software as a Service) üzleti modellnek megfelelően. Az 1C felhőverziójához való hozzáférés költsége felhasználónként 500-600 rubel havonta. A pontos költség a felhasználók számától, a használt adatbázisok számától, a választott tarifától és a fizetési módtól függ.

  Az 1C programok bérlésének költségea felhőben a SaaS modell segítségével
  
  

  Név	Mérték "PROF"**	Mérték "TECHNO"
  Felhasználónkénti birtoklási költség havonta 12 hónapra szóló szerződéskötéskor.	495 rubel / hó	525 rubel / hó
  A pontos költség a fizetési feltételektől függ *: Fizetés havonta Előleg 3 hónap 6 hónap előtörlesztés 12 hónapos előtörlesztés	2970 RUB 8031 RUB 15498 RUB 29664 RUB	1200 RUB 3498 RUB 6546 RUB 12528 RUB
  Egyidejű felhasználók száma	5 felhasználó.	2 felhasználó.
  Elérhető alkalmazások a listából: 1C: Számvitel 8 1C: Bérezés és személyzeti menedzsment 8 1C: Egy kis cég vezetése 8 1c számvitel állami intézmény 8 1C: Közintézmény fizetése és személyi állománya 8 1C: Vállalkozói jelentés 8 1C-kandalló: Fizetés	Minden	Az egyik listából választhat
  Információs bázisok száma	Határok nélkül	Egy működő adatbázis + egy teszt / archív / demó

  *A feltüntetett költség a szerződés folyamatosságától függően érvényes.
  ** A PROF tarifával történő csatlakozás költsége 5 felhasználó korlátlan számú adatbázishoz való hozzáférésén túl számos további szolgáltatások: 1C-jelentés; jogi keret „1C: Kezes”; teljes hozzáférés Nak nek tájékoztatási rendszer 1C: ITS; könyvvizsgálók és szakértők konzultációi és válaszai a felhasználók számviteli, adózási és személyzeti kérdéseire (az 1C: ITS webhely személyes fiókjában); hozzáférés a frissítésekhez dobozos változatok 1C platformok: Vállalati és tipikus konfigurációk 1C stb. További részletek.

  Az első 30 nap ingyenes!
  Annak érdekében, hogy Ön saját maga értékelje a rendelkezésre állást, a stabilitást, a sebességet és a használhatóságot, biztosítjuk szabad hozzáférés az 1C felhőszolgáltatáshoz: 30 napig friss.

  Információs anyagok:
  -
  - Útmutató az adatbázis betöltéséhez egy helyi számítógépről az 1C: Fresh felhő szolgáltatásba
  - Útmutató az 1C vékony kliens telepítéséhez és konfigurálásához, hogy működjön együtt az 1C: Fresh felhő szolgáltatással
  - Jelentkezési lap az 1C felhőszolgáltatáshoz való csatlakozáshoz: Friss
  - Jelentkezési űrlap önregisztrációhoz az 1C felhőszolgáltatásban: Friss

• 2. ok. Nincs érvényes szerződés az informatikai támogatásra (ITS).
  
  Megoldás: kössön szerződést informatikai támogatásra. Ha sürgősen elő kell fizetnie egy ITS-re, akkor is előfizethet rá cégünknél, ha az Orosz Föderáció másik régiójában tartózkodik, és egy másik helyen vásárolta meg az 1C programot. Az egyetlen feltétel az, hogy a programnak licenccel kell rendelkeznie.

  ITS előfizetési költség

  Ügyeljen a következő pontokra:

• Az ITS előfizetésre két lehetőség van: ITS Techno és ITS PROF, amelyek információtartalmában különböznek egymástól. Az ITS Techno tartalmazza a minimális támogatási lehetőséget (hozzáférés az 1C technikai támogatási webhelyéhez a frissítések önletöltéséhez). Az ITS Prof a frissítésekhez való hozzáférésen túl számos további szolgáltatást és szolgáltatást is tartalmaz, például 1C: Jelentéskészítés, 1C: Ügyfél, 1C: Friss, 1C: Cloud archívum, jogalap „GARANT” és még sokan mások. Az ITS Techno és a PROF részletes összehasonlítását lásd.
• Az ITS-előfizetés költsége a szerződés időtartamától függ. A minimális lehetőség egy egyszeri, 1 hónapra szóló előfizetés, de mivel az 1C: Accounting számviteli szoftverének rendszeres frissítésére van szükség, javasoljuk, hogy hosszabb ideig fizessen elő.
• Az ITS-előfizetés folyamatos megújítására vonatkozó előfizetés költsége alacsonyabb, mint a megújításé.

  Név	Ár at folyamatos meghosszabbítás dörzsölés.	Ár at megújítás szerződés dörzsölés.
  PROF egyszeri előfizetés 1 hónapra		4818
  ITS Techno 6 hónapig		7854
  ITS Techno 12 hónapig		15036
  PROF 3 hónapig		9636
  PROF 6 hónapig		18600
  PROF 12 hónapig		35592

• 3. ok. A szoftvertermék nincs regisztrálva a felhasználó személyes fiókjában az 1C portálon.

  Megoldás: regisztrálja a szoftverterméket.
  Útmutató a szoftvertermékek regisztrálásához a Portal 1C személyes fiókjában: ITS (portal.1c.ru)
  Ha a felhasználó korábban nem regisztrált a portálon, akkor mielőtt egy szoftverterméket regisztrálna személyes fiókjában, a felhasználónak először önállóan kell regisztrálnia a portálon, és meg kell kapnia egy bejelentkezési nevet és jelszót a személyes fiókjához való hozzáféréshez.
  Útmutató a felhasználók regisztrálásához az 1C: ITS portálon (portal.1c.ru)
  

• 4. ok. A felhasználó internetes támogatása az 1C programban nincs konfigurálva.
  
  Megoldás: állítsa be az internetes támogatást.
  Útmutató az internetes támogatás csatlakoztatásához tipikus konfigurációkban 1C: Enterprise 8

Technikai problémák

Ha a program licencelt verzióját használja, a szoftvertermék regisztrálva van az 1C portál személyes fiókjában, van érvényes ITS-előfizetés, és az internetes támogatás megfelelően van konfigurálva, és a program továbbra is megjeleníti a „Licencközpont nem elérhető” üzenetet. "A konfiguráció regisztrációja a licencközpontban nem fejeződött be", "A távoli csomópont nem ment át az ellenőrzésen" stb., akkor technikai problémák léphetnek fel:

1. A https://1cv8update.com CPO-szerver nem érhető el
Ebben az esetben ellenőrizni kell a szerver állapotát és elérhetőségét a víruskereső, tűzfalak, tűzfalak vagy proxyszerver biztonsági beállításai általi blokkoláshoz.

2. A https://1cv8update.com webhelyen frissítették a biztonsági tanúsítványt, és Ön a régi 1C: Enterprise platformot használja (vagy a kompatibilitási mód van beállítva) a 8.3.8 verzió alatt. Ebben az esetben frissítenie kell a platform verzióját, be kell állítania a kompatibilitási módot, vagy manuálisan kell regisztrálnia a biztonsági tanúsítványt a cacert.pem fájlban a bin könyvtárban.

3. Lehetséges, hogy a Frissítésvédelmi Központ szervere egyszerűen túlterhelt, próbálja meg többször megismételni az ellenőrzési eljárást az "Újra" gombra kattintva, vagy az ellenőrzést később.

Az 1C Enterprise szoftverfrissítések terjesztési feltételeinek pontosítása

Az 1C szoftvertermékek értékesítése során a szoftver használatára vonatkozó nem kizárólagos (korlátozott) jogok a szerzői jog tulajdonosától (1C Company) átszállnak a Licencvevőre (felhasználóra) a szoftvertermék szállítmányában foglalt licencszerződés feltételeinek megfelelően. . A Licencvevő ugyanakkor vállalja, hogy szigorúan betartja és nem sérti meg a szoftvertermékek engedélyezett felhasználására vonatkozó szabályokat, és a „Licencszerződés” feltételeinek megsértése szerzői jogsértésnek minősül, és eljárást von maga után.

A "Licencszerződés" szerint a szoftvertermékek költségében "1C" in jelenleg információtechnológiai támogatást (ITS) tartalmaz 3 hónapig, amely a havi átvételt is tartalmazza DVD lemezek ITS; szoftverfrissítések, konfigurációk és jelentési űrlapok fogadása; konzultációs vonal szolgáltatások; hozzáférést az oldalhoz technikai támogatás"1C" (2016.01.01-től megvásárolhatja az ITS "lemez nélküli" változatát).

Az ingyenes támogatási időszak lejárta után az 1C programokat csak ITS-szerződés alapján, fizetett alapon szolgálják ki.

Ezenkívül a frissítés telepítésekor a felhasználó megerősíti, hogy egyetért a frissítések terjesztési és használati feltételeivel, és vállalja a felelősséget a használati feltételek megsértéséért, ellenkező esetben a felhasználónak meg kell tagadnia a frissítés telepítését.

Így nemcsak maguk a programok, hanem FRISSÍTÉSEK az "1C" cég gyártási programjai az "1C" társaság kizárólagos jogának tárgyát képezik, és az "1C" társaság, mint szerzői jog tulajdonosa által megállapított szabályok szerint kerülnek terjesztésre az Art. 1225. §-a alapján, és egy jogosulatlan TERJEDÉSés HASZNÁLAT a frissítések szerzői jogok megsértésének minősülnek, és büntetőeljárást indítanak ellenük:

• Művészet. 1301 Polg Az RF kódból,
• Művészet. A kódex 7.12 Orosz Föderáció az Orosz Föderáció közigazgatási szabálysértéseiről,
• Művészet. Az Orosz Föderáció Büntető Törvénykönyvének 146. cikke.

A frissítéseket és információs forrásokat a felhasználónak legális terjesztési csatornákon keresztül kell megszereznie:

• információs technológiai támogatás lemezei
• az "1C" cég webhelyei: www.1c.ru, v8.1c.ru, online.1c.ru, its.1c.ru, portal.1c.ru, kiadások.1c.ru, users.v8.1c.ru
• az "1C" cég partnereinek irodái

A más forrásokból származó frissítések ILLEGÁLIS:

• egy baráttól másolva
• a frissítést "Vasya diák" telepítette (forrás ismeretlen)
• olyan webhelyről lett letöltve, amely nem az "1C" hivatalos oldala
• bódében vásárolt
• stb.

A frissítés használatának jogosultságáról nagyon egyszerű tájékozódni: az 1C cég tájékoztatást kap az összes legális ITS-előfizetőről a telepített 1C szoftvertermékek regisztrációs számával és az előfizetési időszakkal, minden frissítés egyedi számmal és kiadással rendelkezik. a frissítés telepítésének dátuma, dátuma és időpontja a felhasználó számítógépére ismert, magában a programban rögzítve van, pl. a frissítések kiadása és telepítése során a felhasználóval történő egyeztetés esetén az ITS-re előfizetést kell kiállítani.

ITS-előfizetés keresése A bűnüldöző szervek követeléseinek elkerülése és a frissítések felhasználásának jogszerűségének tisztázása és információs források, azt javasoljuk, hogy a felhasználók ellenőrizze, van-e ITS-előfizetése szoftvertermékükhöz az 1C webhelyén: . A használt "1C: Enterprise" program regisztrációs számának megadása után egy üzenet jelenik meg a képernyőn az érvényes ITS-előfizetés meglétéről vagy hiányáról. Ellenőrizze, hogy elküldte-e a regisztrációs űrlapot az 1C-nek Ha az adatok megváltoztak - jelentse az "1C"-nek Győződjön meg arról, hogy a csatorna, amelyen keresztül a frissítéseket kapja, legális (az „1C hivatalos partnere”, az „1C” hivatalos webhelyei) Mielőtt feliratkozna egy ITS-előfizetésre, ellenőrizze, hogy az Önt kiszolgáló cég az 1C hivatalos partnere-e A program regisztrációs száma szerint győződjön meg arról, hogy az előfizetés "1C"-ben van regisztrálva az oldalon http://www.1c.ru/rus/support/support.htm Ne felejtse el időben megújítani előfizetését Nincs szükség ITS-előfizetésre: Alap verziók szoftvertermékek "1C: Enterprise", A használt 1C programok "felhő" verziói felhő szolgáltatás 1C: Friss

Címkék: 1c konfigurációk frissítéseinek fogadásának ellenőrzése, 1c 8.3 frissítés jogszerűségének ellenőrzése, 1c frissítés jogszerűségének ellenőrzése, 1s frissítések letöltése, annak, 1s annak, lemeznek, 1c 8.3 7, users.1c jogszerűségének ellenőrzése .ru, its.1c.ru, 1s kíséret 8

Az 1C 8.3 információs bázis tesztelését és javítását el kell végezni, ha hibákat észlel az információs bázisban, és az adatbázis konfigurációjának frissítése előtt. A legtöbb esetben, ha az információs bázis megsérül, az segít.

A tesztelés és a javítás előtt meg kell tennie biztonsági mentés bázis. Ha nem tud belépni a konfigurátorba, akkor a következővel rendelkező mappában telepített program Az 1C rendelkezik egy segédprogrammal a teszteléshez és a javításhoz, amely nem igényli a program futtatását konfigurátor módban. Minderről az alábbiakban fogunk beszélni.

Vessünk egy pillantást erre az eszközre és a vele való munkavégzésre. Nézzük meg közelebbről, milyen zászlókat kell beállítani a felületen.

Indítsuk el a programot konfigurátor módban:

Válassza az Adminisztráció menü "Tesztelés és javítás" menüpontját:

Milyen jelölőnégyzeteket tegyek?

A tesztelés beállítására többféle lehetőség kínálkozik, vegye figyelembe az alábbi jelölőnégyzeteket:

• Infobázis táblák újraindexelése az adatbázis táblákon lévő indexek teljes újraépítése. Az újraindexelés növeli az információs bázis sebességét. Az eljárás hosszadalmas, de soha nem lesz felesleges.
• Az információs bázis logikai integritásának ellenőrzése- ellenőrizze az adatbázis logikai és szerkezeti integritását, javítsa ki az adathibákat;
• Egy információs bázis hivatkozási integritásának ellenőrzése- ellenőrizze, hogy nincsenek-e „megszakadt hivatkozások” az adatbázisban. Ilyen hibák a rendszerobjektumok közvetlen törlésekor vagy meghibásodáskor fordulhatnak elő. Az ilyen hibák kijavítására 3 lehetőség van:
  • Objektumok létrehozása- a rendszer csonkelemeket hoz létre, amelyeket azután kitölthet a szükséges információkkal,
  • Linkek törlése- a "megszakadt" linkek megtisztításra kerülnek,
  • Ne változz- a rendszer csak a hibákat jeleníti meg.
• Az összegek újraszámítása. A Totals a felhalmozási, számítási és számviteli nyilvántartásokban előre kiszámított eredmények táblázata. Az eredmények újraszámítása, valamint az újraindexelés soha nem lesz káros, és növeli a program sebességét;
• Infobázis táblázatok tömörítése- az adatok törlésekor az 1C nem törli a táblázat sorait, hanem csak törlésre "jelöli meg". A felhasználó számára nem láthatók, de továbbra is az adatbázisban maradnak. Az adatbázis tömörítése véglegesen törli ezeket az adatokat. Ugyanez a hatás érhető el egy infobase fájl (* .dt) ki- és betöltésével;
• Infobázis táblák átstrukturálása- egy hosszú folyamat, amelynek során a rendszer újra létrehozza az adatbázistáblákat. Ez az eljárás akkor is megtörténik, amikor módosítják a konfigurációs struktúrát.

Példánkban jelölje be az összes jelölőnégyzetet az ábrán látható módon, és kattintson a "Futtatás" gombra:

A művelet szakaszát az 1C konfigurátor ablakának bal alsó sarkában figyelhetjük meg. Az észlelt hibák a szervizüzenetek ablakban jelennek meg.

A tesztelés befejezése után kattintson a "Bezárás" gombra:

A műveletek eredményét a szervizüzenetek ablakában láthatjuk.

A tesztelés és a javítás befejeződött.

Ha a konfigurátor nem nyílik meg: chdbfl.exe segédprogram

Ha az alap annyira sérült, hogy nem tud belépni a konfigurátorba, használhatja. A segédprogram az 1C platformmal együtt van telepítve, és a telepítési könyvtár Bin mappájában található:

A tesztelés megkezdése előtt feltétlenül másolatot kell készítenie az adatbázisról, mivel ennek a segédprogramnak a használata visszafordíthatatlan következményekhez vezethet. Mivel nem léphet be a konfigurátorba, biztonsági másolatot kell készítenie egyszerű másolás az információs bázis címtárát.

Miután rákattintott a másolásra, kattintson jobb gombbal egy üres helyre a mappaablakban, és kattintson a "Beillesztés" gombra. Másolat készül, futtassa a segédprogramot:

Megjelenik a fő segédprogram ablak. Meg kell adnunk az adatbázisfájl nevét. Kattintson három pontra. Megnyílik egy ablak az adatbázisfájl kiválasztásához. Megkeressük az adatbázisának könyvtárát, és abban az 1Cv8.1CD fájlra mutatunk. Kattintson a "Megnyitás" gombra.

Jelölje be az „Érzékelt hibák javítása” négyzetet, és kattintson a „Futtatás” gombra.

Várjuk a művelet végét. Elviheti hosszú idő, az alap méretétől függően.

A végrehajtás után, ha a hibákat kijavították, azok megjelennek a segédprogram ablakában. Az én esetemben nem találtak hibát. Kattintson a „Bezárás” gombra, és próbáljon meg belépni a programba. Ha továbbra sem tud belépni, szakemberhez kell fordulnia.