Egyéni konfiguráció frissítése. A tipikus konfigurációk helyes kitöltése A betöltött konfiguráció a fő leszármazottja

Tekintsük a frissítést egy nem szabványos SCP 1.3-as konfiguráció példáján, amely támogatás alatt áll, azzal a lehetőséggel, hogy az 1.3.61.2-es kiadásról az 1.3.62.1-es kiadásra váltson. Mivel maga a konfiguráció meglehetősen nehéz, ez bizonyos funkciókat igényel, különösen nem mindig lehetséges több konfiguráció-összehasonlító ablak megnyitása egy konfigurátorban.

A frissítéshez a régi kiadási adatbázis két azonos példányát használom. Az egyikben készülök *.vö frissíteni, nevezzük pl. for_frissítése. A másik alap érintetlen marad, és csak segédanyagként szolgál, a konfigurációk összehasonlításához, nevezzük így bázis. Elvileg a munkaalap konfigurációja segédeszközként is használható.

Az alapban for_updating előadni *.cfuúj kiadás. A frissítési folyamat elindul, és megjelenik a frissítési ablak.

Nyomja meg a gombot " Fuss”, ebben a szakaszban még nem kell nézegetni semmit, hiszen csak az új kiadás gyártójának konfigurációja a cél.

A frissítés során egy ablak jelenhet meg Feloldhatatlan linkek", nyomja meg" Folytatni". Az alábbiakban az ablak megjelenésének okairól fogunk beszélni.

Megjelenik egy üzenet, hogy az általunk módosított objektumok az új konfigurációból töltődnek be, egyetértünk.

Az ablak " Támogatási szabályok felállítása" - új objektumokhoz (felső rész) mindkét oldalra helyezzük " Az objektum szerkesztése a támogatás fenntartása mellett történik”, a meglévő beszállítói objektumokhoz (alsó rész) mind a négy helyen beállítjuk a „ Az aktuális mód mentése", nyomja meg" rendben».

A fő konfiguráció frissítve lett. Önmagában ebben a szakaszban nincs szükségünk a fő konfigurációra, a cél egy új szállítói konfiguráció beszerzése. Ezért nem mentjük el a fő konfigurációt, nem frissítjük az adatbázis konfigurációját.

végrehajtjuk" Konfiguráció» - « Támogatás» - « Támogassa a testreszabást". A megnyíló ablakban válassza a " Mentés fájlba» és mentse ide *.vöúj kiadás gyártó konfigurációja.

Nincs szükségünk a fő konfigurációra abban a formában, ahogy jelenleg elérhető. Bezárjuk a konfigurációt. " Konfiguráció» - « Konfiguráció bezárása". Megtagadjuk a változtatások mentését.

Összehasonlításképpen konfigurációban bázis Futtassa le a szállítói konfiguráció (régi kiadás) és a szállítói konfiguráció összehasonlítását egy fájlból (új kiadás).

Így csak azokat a változtatásokat fogjuk látni, amelyeket a konfigurációban végrehajtanak az új kiadásra való frissítéskor.

Az alapban for_updating futtassa újra a konfigurációs frissítést a támogatáson keresztül "Konfiguráció" - "Támogatás" - "Konfiguráció frissítése", a megnyíló ablakban válassza ki a lehetőséget *.cfuúj kiadás. A frissítési folyamat elindul, és megjelenik a frissítési ablak.

A " gomb megnyomásával Szűrő» megnyílik az ablak « Nézetszűrők beállítása". Ebben az ablakban állítsa be a " Csak olyan tulajdonságokat jelenítsen meg, amelyek kétszer változtak».

A mi beavatkozásunk nélküli frissítéskor a következő történik:

- az objektumot nem mi változtattuk meg, az új kiadásban módosult - frissítve az új kiadástól;
- az objektumot mi változtatjuk meg, az új kiadásban nem változtatjuk meg - az objektumunk megmarad;
- az objektumot mi változtattuk meg, az új kiadásban változtattuk meg - ez az objektum kétszer változott, ha nem változik semmi - az új kiadásból töltődik be.

Így a legnagyobb figyelmet a kétszer megváltoztatott objektumokra kell fordítani, ezeket figyelembe vesszük.

Ebben a példában több általános modul megváltozott, beleértve a közös modult "ÁFA könyvelés».

Alapértelmezés szerint a frissítési ablak a fő és az új szolgáltató konfigurációja, valamint a régi szolgáltatói konfiguráció közötti különbségeket mutatja.

Ha megnézi a konfigurációs különbségeket a közös modulban " ÁFA könyvelés”, akkor a következő képet fogjuk látni:

Ha ezeket a modulokat összehasonlítjuk az adatbázisban összehasonlítás céljábólbázis, akkor más lesz a kép:

Nyilván a funkciók CollectDataForPrintCorrectionInvoicesInvoices», « A DataToPrintAdjustment InvoiceInvoice gyűjtése” és mások tartalmazzák a fejlesztéseinket, de a frissítés során nem változnak, vagyis nincs értelme a megtekintésükre és elemzésükre időt vesztegetni.

Ezért a kiválasztott eljárások és funkciók eljárási frissítése során eltávolíthatja a zászlókat:

Sokan azt mondják, hogy láthatja a különbségeket a régi gyártói konfiguráció és az új között, ha módosítja a nézetszűrő beállításait az aktuális konfigurátorban, anélkül, hogy az adatbázisban lévő konfigurációk összehasonlítását használná.bázis.

Például így:

A gyakorlati tapasztalatok szerint azonban ez nem így van, az eljárások és funkciók továbbra is megjelennek a modul összehasonlító ablakban, még a szűrővel is " megmutatja az új szállítói konfiguráció és a régi szállítói konfiguráció közötti különbségeket».

Nem nagy szellemi erőfeszítéssel, kétszer is feltárjuk a megváltozott eljárásokat, funkciókat, csak az összevonás után még javítani kell. Ezekkel az eljárásokkal és funkciókkal el kell döntenie, melyik a könnyebb:

- vagy vegyünk át egy eljárást vagy függvényt egy új szállítói konfigurációból, majd egyesítés után végezzük el a fejlesztéseinket;
- vagy távolítsa el a frissítési jelzőt, ezzel elmentve a fejlesztéseinket, és csak ezután adja hozzá a szükséges kódot a gyártó konfigurációjából.

A fő konfiguráció prioritásával egyesítve és a szállító új konfigurációjának prioritásával kombinálva ritkán használom, elvileg még ezen módok használata nélkül is jó minőségű lesz az eredmény.

A közös modulok elemzése és egyes eljárások frissítési jelzőinek törlése után azt látjuk, hogy a modulok összevonási móddal rendelkeznek - ez egy egyedi beállítás:

Továbbmegyünk. A kétszer módosított objektumok között van egy hivatkozási elem " BasicMeans". Mielőtt eldöntené, hogy frissít-e egy adott űrlapot egy új szolgáltatói konfigurációból, meg kell találnia, hogy valójában mi változik a frissítés során.

Ehhez az adatbázisban bázis a helyi menü használatával hívja a " Tárgy-összehasonlító jelentés…”. Az "Objektumok" csoport összes jelzőjének a megnyíló ablakban kell lennie.

Szeretem a táblázatos dokumentumban a riportkimeneti módot, amikor a különbségek grafikusan jelennek meg, de ez ízlés dolga.

A hivatkozási elem formájának összehasonlítása eredményeként " BasicMeans» azt látjuk, hogy csak az űrlapmodulban vannak változások, a frissítésben az űrlap párbeszédablakban nincs változás.

De mivel az elem formája kétszer megváltozott objektumokba került, a fejlesztéseink vagy az űrlap párbeszédablakban vagy a modulban találhatók.

Hasonló összehasonlítás végrehajtása az adatbázisban for_updating láthatja, hogy vannak fejlesztések az űrlap párbeszédpanelen.

Ennek az az oka, hogy a könyvtár hozzáadása BasicMeans» a jellemző típusok tervéhez « PropertiesObjects". Ha frissíti a hivatkozási elem formáját " BasicMeans"Feloldhatatlan hivatkozásokat fogunk kapni, mivel az ablak ezt jelzi:

Ebben az esetben a legjobb megoldás az, ha nem frissíti a hivatkozási elem formáját " Fő felszerelés” és csak ezután adja hozzá a szükséges kódot az elem űrlap modulhoz. Ebben az esetben az ablak Feloldhatatlan linkek” nem jelenik meg a frissítés során.

Tegyünk egy kitérőt, és képzeljük el, hogy a könyvtár form elemének párbeszédablaka " Fő felszerelés' módosul, amikor új kiadásra frissít, akkor a legjobb megoldás az űrlap frissítése. Később, az összevonás után, a módosításainkat kell hozzáadnunk az űrlaphoz, mind a modulban, mind a párbeszédablakban. Ha a modulon sok a mi fejlesztésünk, és kevés a beszállítótól, akkor az összevonás után teljes mértékben visszaküldheti a modulunkat, és változtatásokat fűzhet hozzá a szállítóhoz.

Ebben az esetben az egyesítési folyamat során az ablak „ Feloldhatatlan címkék". Ebben az ablakban két lehetőség van: 1) " Jelölje meg az összeset egyesítéshez"; 2) " Folytatni».

Véleményem szerint jobb választani Jelölje meg az összeset egyesítéshez».

Ebben az esetben a jellemzők típusainak terve " PropertiesObjects" lesz hozzáadva a fába egyesítendő objektumként az újonnan megnyíló ablakban " Frissítés…»

Természetesen a jellemzőtípusok tervének frissítése után " PropertiesObjects» hozzá kell adni a változtatásainkat, javítani kell a jelenlegi konfigurációval való összehasonlítással és összevonással.

Gondoljuk át, mi történne, ha azt választanánk Folytatni"az ablakban" Feloldhatatlan linkek". Ebben az esetben a hivatkozási elem formája " BasicMeans” újjá válna, és a jellemzőtípusok terve” PropertiesObjects' régi maradt volna. Ebben az esetben felülírjuk a változtatásokat a referenciaelem űrlap párbeszédablakban, mégpedig a " PropertiesFValues”, lásd az alábbi ábrát.

Ez a probléma sem megoldhatatlan, hacsak persze nem feledkezünk meg róla.

Természetesen az a legjobb, ha megpróbálja a lehető legkevesebb változtatást végrehajtaniűrlap párbeszédablakok , például részletek és gombok programozott létrehozásához az űrlapon.

Sokan általában azt javasolják, hogy ne változtassuk meg a szabványos űrlapokat, hanem készítsünk belőlük másolatot a mi módosításainkkal, és tegyük azokat a fő űrlapokká. Nem szeretem ezt az opciót, mert ha a beszállító hozzáadott valamit az űrlap párbeszédablakban, akkor az nem jelenik meg az űrlapomon, és manuálisan kell kiegészíteni, és sokkal több beszállító változás történhet, mint a miénk.

Szeretnék külön figyelmet fordítani eljárási úton űrlapok frissítése (az eljárások egy részét a szállító konfigurációjából veszem át, és vannak, amelyek nem - egyéni beállítások). Nézzük meg, hogy ebben a módban hogyan frissül az űrlap párbeszédablak, ellentétben a " móddal"venni a gyártó konfigurációjából».

A példa erre a konfigurációs frissítésre nem vonatkozik, de tájékoztató jellegű, ezért nézzük meg.

A kézikönyvben" Ügyfelek» néhány kelléket adunk hozzá, és az elem formájára helyezzük.

Amikor egy konfigurációt egy új kiadásra frissít a támogatáson keresztül, egy összehasonlító és egyesítő konfigurációs ablak jelenik meg, amelyben különféle beállításokat végezhet. Hasonlítsunk össze több lehetőséget:

1. Az űrlapfrissítés jelzője be van állítva, de a frissítés megtörtént eljárási úton , azaz valójában a testreszabás megtörtént

Sokan úgy gondolják, hogy az űrlap párbeszédablakot a szolgáltató konfigurációjából kell átvenni, és a beállításoktól függően az eljárásokat. Lássuk, mi a helyzet az unió után. Hasonlítsuk össze a szállító konfigurációját a fő konfigurációval.

Nyilvánvaló, hogy a nyomtatványokon eltörtek a kötések és így tovább, pl. az űrlap párbeszédablakot nem vették át teljesen a szolgáltató konfigurációjából. Ebben az esetben az űrlap párbeszédablakban maradtak az objektumaink, ez egyrészt jó, másrészt nem mindig optimális az elemeink elhelyezése az űrlapon, különösen új beszállítói elemek hozzáadása kapcsán, változás történik a bypass pozíciókban és a kötések megsértése. Bizonyos esetekben egyszerűbb manuálisan hozzáadni elemeinket az űrlap párbeszédablakhoz, mint a javításokat elvégezni.

2. Az űrlapfrissítés jelzője be van állítva, a frissítés a " Vegye át az új szolgáltatói konfigurációból»

Ebben az esetben az elem űrlap párbeszédablaka teljesen egybeesik a szállító elem űrlap párbeszédablakával.

Térjünk vissza a frissítéshez. Az objektummodulokat és a dokumentumkezelő modulokat ugyanúgy kezeljük, mint a gyakori modulokat, procedúrálisan frissítjük azokat. A dokumentumok nyomtatványaival ugyanúgy járunk el, mint a címtárak űrlapjaival.

Külön ki kell emelni a szerepekkel végzett munkát. Annak ellenére, hogy a példában nem kötelező frissíteni a szerepeket, érdemes erről beszélni. Tekintsük a legegyszerűbb esetet, amikor a szolgáltató konfigurációja új objektumot tartalmaz. Ebben az esetben frissítenie kell a szerepet"Teljes jogok”, de ez a szerepkör tartalmazhat néhány általunk létrehozott objektumot, például könyvtárakat, dokumentumokat stb.

Úgy tűnik, hogy a szereppel Teljes jogok» minden egyszerű, teljesen kombináljuk őket, a nem szabványos objektumokhoz való jogok egyébként is megmaradnak bennük. Így van, a nem típusú objektumok jogai soha nem vesznek el, de ezeknek az objektumoknak a zászlója lesz " Interaktív eltávolítás", ami nem mindig jó. A régi és az előkészített új kiadás konfigurációinak összehasonlításakor ez jól látható:

A többi szerepkörrel ugyanúgy járunk el, mint a modulokkal - ha több változtatásunk van, akkor a szerepkört nem vonjuk össze, frissítés után hozzáadjuk azt, amit a szállító az új kiadásban hozzáadott.

Miután a frissítési ablakban végigdolgoztuk az összes kétszer módosított objektumot, kattintson a " Fuss»

Arra a kérdésre, hogy az általunk megváltoztatott objektumok az új konfigurációból töltődnek be, igennel válaszolunk.

A megnyílt ablakban" Támogatási szabályok felállítása"Ellenőrizze, hogy a zászlók be vannak-e állítva, bár alapértelmezés szerint helyesnek kell lenniük, nyomja meg a" rendben».

Az egyesítési folyamat végén elmentjük a fő konfigurációt, az adatbázis konfigurációt még nem frissítjük.

Most a konfiguráláshozfor_frissítésehozzáadjuk azokat a minimális fejlesztéseket, amelyeket rendszeres eszközökkel nem lehetett megfelelően frissíteni.

A folyamat végrehajtásának egyszerűbb ellenőrzése érdekében az adatbázisban bázis Kezdjük összehasonlítani a gyártó konfigurációját a régi kiadás fő konfigurációjával.

Az alapban for_updating tegyük ugyanezt. Kétszer módosított objektumokat vezérelünk, nem lehetnek különbségek.

Az adatbázis frissítése utándátumozáshozbefejeződik, frissítjük az adatbázis konfigurációt és tesztelünk néhány pontot, hogy pontosan mit lenne jó tesztelni, az a frissítés során kiderül, itt minden egyéni.

A működő adatbázist célszerű a támogatás segítségével frissíteni"Konfiguráció" - "Támogatás" - "Konfiguráció frissítése".Ebben az esetben az új kiadásból kétszer módosított objektumok töltődnek be, pl. a módosításaink felülíródnak (nem mentjük el a konfigurációt!), de az előkészített konfigurációval kombinálva visszaállítjuk azokat. Ezt követően elmentheti a konfigurációt, frissítheti az adatbázis konfigurációját.

Ebben a módosított 1s 8.3 nem szabványos frissítésére vonatkozó utasításban nem írok le alapvető dolgokat, például: hogyan kell megnyitni a konfigurátort, mi az adatbázis konfigurációja, a szállító konfigurációja és a fő konfiguráció. Sokat írtak erről és ott, és ezeket az információkat függetlenül megtalálhatja az interneten. Megpróbálom leírni a frissítési folyamat főbb pontjait és azt, hogy mire kell figyelni.
Példaként az atipikus számviteli 3.0.51.22-es verziót vettem, és megmutatom, hogyan kell frissíteni a 3.0.53.29-es verzióra. A 8.3.10.2561-es platformverzión (nincs nagy különbség a régebbi platformokon, csak az összehasonlító ablak egy kicsit másképp nézett ki korábban).
Azonnal mondom, hogy sok kép és kevés szöveg lesz. Szerintem vizuálisan könnyebb megjegyezni egy folyamatot, mint elolvasni egy tengernyi szöveget.

1. Ellenőrizze, hogy az adatbázis-konfiguráció megfelel-e a szállítói konfigurációnak.

Ehhez kell

Ha egyetért, nyugodtan folytathatja a 2. ponttal.

1a. A konfiguráció beállítása a támogatáshoz.

Ha az adatbázis és a szállítói konfiguráció verziója eltérő, akkor az aktuális konfigurációt ugyanazon a menün keresztül kell törölnie: konfiguráció - támogatás - támogatási beállítások. És kattintson a "Kilépés a támogatásból" gombra.

„Rövid” várakozás után távolítson el minden pipát. Nos, törölheti a "Beállítások automatikus mentése" jelölőnégyzet jelölését. És kattintson a végrehajtáshoz.

Ennek eredményeként egy támogatott konfigurációt kapunk ugyanazokkal az adatbázis-verziókkal.

2. Adatbázis frissítése.

Most folytathatja a frissítést.

Azonnal azt mondom, hogy CSAK a "Konfiguráció" - "Támogatás" - "Konfiguráció frissítése ..." menün keresztül kell frissítenie.
Használja az "Összehasonlítás, összevonás a konfigurációval fájlból..." parancsot NE!!! Ha ezt a mechanizmust használja, a következő frissítéskor az 1a lépésre kell lépnie. Ezért ne csináljuk ezt, és ne okozzunk magunknak (vagy valakinek, aki legközelebb frissíti az adatbázist) felesleges problémákat.

Ezután válassza ki a frissítési fájlt.
A frissítésről szeretnék szólni több kiadás után. Az 1C nem javasolja a fájlok CF-re való frissítését, egyszerre több kiadást is átugorhat. Ezt sorrendben kell végrehajtani. Elméletileg ez helyes.
Hadd magyarázzam el, hogy ez miért nem ajánlott. Ha a programozók el akarnak távolítani bármilyen kelléket, először a „delete” előtagot rendelik hozzá, majd néhány kiadás után eltávolítják. És információkat tudnak átvinni belőle valamilyen kiadásban. Ennek a kiadásnak a kihagyásával adatokat veszíthet. De a gyakorlatban az 1c adatbázisokkal való 10 éves munkám során volt egy ilyen esetem. Amikor valamilyen oknál fogva a fejlesztők úgy döntöttek, hogy adatokat visznek át a felsorolásból a címtárba. Ez azonban nem lett kritikus számomra. Írtam egy egyszerű feldolgozást, amely átvitte ezeket az adatokat az archívumból az aktuális adatbázisba. Nem volt szükség újbóli frissítésre.
Lehet engem kővel dobálni, de mindig frissítem az adatbázist cf fájlokkal több kiadásnál.
Így megnyomtuk a frissítést, üzenetet kaptunk, hogy melyik verzióra készül a frissítés. Kattintson az OK gombra.

Várjuk az összehasonlítandó tárgyakat.
Ezután a lista alján ki kell választanunk a „csak kétszer megváltozott tulajdonságok megjelenítése” elemet.

A régi verziókról is szeretnék szólni, azelőtt zászló volt.

Így most sokkal kevesebb tárgyat látunk.

Ha a tiéd üres, akkor hihetetlenül szerencsés vagy, és nyugodtan megnyomhatod a "végrehajtás" gombot, és befejezettnek tekintheted a frissítést. Nos, itt nem minden olyan egyszerű, ezért áttekintem a főbb tárgyakat.

Az első dolog, amit el akarok mondani. Soha ne váltson egyesítési módot. Ennek a következőnek kell lennie: „Vegye az új szállítói konfigurációból”. Ellenkező esetben szemetet kap az adatbázisban az MGR megjegyzéssel.
Nincsenek "modulkülönbségek megjelenítése..." gombok!
Kattintson a modul melletti fogaskerék ikonra

Megnyílik egy ablak, amelyben sok változás történik a funkciókban és eljárásokban.

Annak megértéséhez, hogy melyik funkcióban történtek változások, vagy másolatot kell készítenünk az adatbázisról, vagy a konfigurációt fájlba kell mentenünk a konfigurációs menün keresztül. Ezután töltsön be egy üres adatbázisba. Ezután lépjen a "konfiguráció" menübe, és kattintson a "Konfigurációk összehasonlítása..." gombra.
Válassza ki a fő konfiguráció és a szállító konfigurációjának összehasonlításához.

És most már láthatja a változásokat a "Modulok különbségeinek megjelenítése ..." részben. Mivel nem fogunk semmit megváltoztatni, csak látni akarjuk, mi változott.

És azt látjuk, hogy egy kódrészletet hozzáadtak a Decline függvényhez. A kék nyilakra kattintva minden változás megtekinthető.

Térjünk vissza a frissített konfigurációhoz. Ott a fogaskerék ikonon keresztül beléptünk a modulok kombinálásának módjába. Ezután az összes jelölőnégyzetet behelyeztük ... manuálisan .. "köszönöm" a platform fejlesztőinek :)

Úgy találjuk, hogy funkciónk hanyatlik. Keresse meg a megváltozott elemet. Remélem, most már világossá vált, hogy miért kell a hozzáadott kódokat megjegyzésekkel elválasztani – ugye, hogy ne találgassunk frissítéskor, honnan származik ez a kód.
Kattintson a nagyító ikonra, és a platform kiemeli azt a kódsort, amelyhez ezt a szöveget hozzá kívánja adni.

Másolja ki a felső ablakból, és illessze be az alsó ablakba.

Tegye ezt az összes modulhoz. Ha a modult nem változtatták meg, mint a mi esetünkben a devizahivatkozásnál. Egyszerűen beállítjuk az üzemmódot „Vegyük át az új gyártói konfigurációból” és NE kattintsunk a fogaskerékre (ne legyen zöld pipa a fogaskerék mellett, ez azt jelenti, hogy a kód teljesen átkerül az új konfigurációból, manuális nélkül konfiguráció).

Bírság. Most, miután végigfutott az összes objektumon, törölheti a "beállítások automatikus mentése" jelölését, majd a "végrehajtás" jelölőnégyzetet.

A „Vannak olyan objektumok, amelyek megváltoztak a fő konfigurációban a régi konfigurációhoz képest…” üzenetre… Ezek az objektumok a frissítés során lecserélődnek! Végrehajtani?" Nyugodtan nyomja meg a YES gombot.

A következő ablakban hagyja be a jelölőnégyzeteket a képen látható módon. És semmi más!!! Mindkét jelölőnégyzetet be kell jelölni - "az objektumok szerkesztése a támogatás fenntartása mellett történik." Nyomjuk meg az OK gombot.

Minden. A nem szabványos 1s konfiguráció frissítése befejeződött.
Ez a módszer nem ideális, de szerintem sokan hibáznak ezekben a lépésekben.
Persze nem mondtam el mindent, még sok a buktató. De szerintem a frissítések 90%-a biztonságosan frissíthető ezen utasítás szerint.

Egyszerre több kiadás konfigurációjának frissítése nagyon veszélyes. A lényeg, hogy minden konfigurációfrissítés után 1C:Enterprise módban indul el az infobase frissítés. Ezért ha csak a legújabb kiadást frissíti, előfordulhat, hogy az infobázisok nem egyeznek a legújabb konfigurációval. A cikkben Dmitrij Rudakov, a Szibériai Agrárcsoport CJSC specialistája megosztja személyes tapasztalatait a 12 kiadás egyszeri konfigurációs frissítésével kapcsolatban.

A konfigurációmódosítási mód ellenőrzése

Képzeljünk el egy ilyen helyzetet. A "Manufacturing Enterprise Management" (a továbbiakban: PPM) fejlesztői az 1. kiadásban (a kiadási számok a továbbiakban feltételesen vannak hozzárendelve) a számítási regiszter dimenziójához (mutatójához) a "DirectoryReference.Individual" típust "névvel" rendelték hozzá. Egyedi". A 2. kiadásban hozzáadtak még egy dimenziót - "Alkalmazott" a "ReferenceReference.Employees" típussal. Az 1C:Enterprise elindításakor a feldolgozás engedélyezve van, amely ugyanúgy kitölti az „Alkalmazott” dimenziót, mint az „Egyéni” dimenziót. Aztán a 3. kiadásban az „1C” fejlesztők eltávolították az „Egyéni” dimenziót, és csak az „Alkalmazottat” hagyták meg. Ha a konfigurációt az 1. kiadásról azonnal frissíti a 3. kiadásra, törölheti a teljes számítási regisztert.

Ha pedig a konfiguráció változtatási lehetőséggel támogatott, és ugyanabban az adatbázisban generálódik a szabályozott jelentés, akkor minden kiadáshoz szükséges a konfiguráció frissítése, ami munkaórákat tekintve igen költséges lehet. Például egy erősen módosított "SCP" 1 kiadásra történő frissítése 30 órát vesz igénybe egy tapasztalt szakember számára.

Ezért, mielőtt folytatná a frissítést, meg kell határoznia: tipikus konfigurációban dolgozik-e változtatási lehetőséggel, vagy olyan konfigurációban, ahol nincs lehetőség változtatásra? Ehhez lépjen a konfigurátorba, ahol a menüben kövesse a lépéseket " Konfiguráció - Támogatás - Támogatás beállítása".

1. ábra. A konfigurációs támogatás beállítási ablakának hívása

Ha be van állítva " a támogatásról", akkor ez a konfiguráció jellemző, és ha " Módosítás engedélyezve"- a konfiguráció valószínűleg megváltozott (legalábbis egy ilyen lehetőség benne van). A harmadik állapot az A konfiguráció elavult." A különböző konfigurációs állapotok a 2., 3., 4. ábrán láthatók.

Rizs. 2. Tipikus konfiguráció változtatási lehetőség nélkül

Rizs. 3. Tipikus konfiguráció engedélyezett változtatással

Rizs. 4. A konfiguráció eltávolítva a támogatásból

Algoritmus a megváltozott konfigurációk frissítéséhez

Nemrég szembesültem azzal a feladattal, hogy frissítsem a megváltozott "Trade Management" konfigurációt, a 10.3.13.2 kiadást. A konfiguráció a "BIT: Car Service Management 8" iparági megoldással való egyesülés eredményeként módosult, és két éve folyamatosan finomodik. Most frissíteni kellett a konfigurációt a 10.3.25.1 kiadásra, azaz 12 kiadásra. A teljes frissítési eljárást több lépésre bontottam.

1. szakasz. A megújítási eljárás költségének és időzítésének becslése

Az önálló munka megkezdése előtt úgy döntöttem, hogy független szakértői értékelést kérek ezen a területen. Az egyetlen vállalat, amely képes automatizált módszerekkel frissíteni a megváltozott konfigurációkat, az 1C-IzhTiSi LLC. Megkerestem a cég szakembereit azzal a kéréssel, hogy becsüljék meg a konfigurációm frissítésének költségeit. A munka idő- és költségbecsléséhez megadtam az aktuális konfigurációt, amely frissítésre szorul. Egy nappal később levelet kaptam jelentéssel .

Jelentés a konfigurációfrissítés költségének és időzítésének felmérésének eredményeiről:

Konfiguráció: Trade Management Revision 10.3
A jelenlegi konfigurációs verzió: 10.3.13.2
Frissítés a verzióra: 10.3.25.1
Bővíthető modulok száma: 1847
Ellenőrzési kibocsátások száma: 8

Az értékelés eredménye meglepett, mivel a részvényenkénti árat a társaság honlapján tüntették fel - 1000 rubel. egy kiadás frissítéséhez. "1C-IzhTiSi" megjegyzés:

"Az egyes kihagyott kiadások frissítésének költsége nem haladja meg a 2000 rubelt. Most promóció van, így a költség nem haladja meg az 1000 rubelt. De a szolgáltatások végső árát a frissítéshez szükséges munkaerőköltségek felmérésének eredményei határozzák meg, és alacsonyabb lehet 1000 rubel/kiadásnál".

Azt is tisztáztam, hogy a frissítéshez szükséges kiadásokat hogyan választottam ki. Kérdésemre kaptam egy képernyőképet, amelyen ez egyértelműen kimutatható (5. ábra). A Verziószám oszlop azt a konfigurációs verziót jelzi, amelyre frissíteni kíván. A „Frissítési verzió” oszlop jelzi, hogy melyik kiadásról frissíthet. Az értékelés eredményeként a szükséges frissítések száma 9-re csökkent.

Rizs. 5. A konfiguráció helyes frissítéséhez használandó kiadások kiválasztása

Az 1C-IzhTiSi jelentés tanulmányozása után kiszámoltam az azonos mennyiségű munkára fordított személyes időt. Egy-egy frissítés körülbelül 6 órát vesz igénybe. A teljes ráfordított idő tehát 56 (9x6) munkaóra, azaz hozzávetőlegesen hét munkanap. Emellett fennáll annak a lehetősége, hogy a frissítés után néhány hiányosságra is fény derül: például a felhasználó panaszkodik, hogy elvesznek a számára szükséges konfigurációs változtatások, és akkor az időköltségek is komolyan megnőnek. Eközben az "1C-IzhTiSi" cég szakemberei felajánlják, hogy a teljes munkamennyiséget három-négy munkanap alatt elvégezzék. Ezért úgy döntöttem, hogy igénybe veszem a szolgáltatásaikat.

Most röviden elmagyarázom, hogy pontosan mi változott a konfigurációban.

Erősen módosított objektumok. Ezek olyan objektumok, amelyekben sok jellemző tulajdonság megváltozott. A kiigazítások összetettek. Az objektum adatai a táblázatos részhez kerülnek, az objektum űrlapján és a lista űrlapon megjelennek. Hozzáadott kezelők az űrlapok további részleteihez. Módosult az iratok feladásának vagy a nyilvántartáshoz szükséges mozgások rögzítésének tipikus mechanizmusa.

Erősen módosított dokumentumok:

„Megrendelés a szállítónak”;
„áruk mozgása”;
"Követelmény-számla";
"Áruk és szolgáltatások átvétele".

Erősen módosított regiszterek:

„Raktárban lévő áruszállítmányok”;
"Áruk a raktárakban".

Jelentősen módosított objektumok. Azok az objektumok, amelyekhez részleteket adtak hozzá, akár az objektumok formája, akár az objektum moduljai megváltoztak (a dokumentum általában atipikus).

„Bejövő készpénzes megbízás” dokumentum;
Információs nyilvántartás „Alkatrész-nómenklatúra”;
Információk nyilvántartása "Leírható áruk";
Általános modulok.

Kissé megváltozott tárgyak. Az objektumokban csak az űrlapokat módosították és részleteket adtak hozzá.

Útmutató könyvek:

"Nómenklatúra típusai";
„A szerződő felek szerződései”;
„Vállalkozók”;
"Elnevezéstan";
"Nómenklatúra ártípusai";
"Számos információs nyilvántartás".

Módosult az eseményekre, elrendezésekre, szerepekre és közös modulokra való feliratkozás az „Általános” részben. Szinte mindent megváltoztatott egy iparági döntés.

2. szakasz: Bizalmas információk eltávolítása

Mielőtt az 1C-IzhTiSi alkalmazottai számára információs bázist biztosítana a teszteléshez, törölni kell benne a bizalmas információkat. Ilyen esetekben az 1C a "Bizalmas információ megváltoztatása" feldolgozást javasolja, amely nem túl széles körben ismert.

A „Bizalmas információk megváltoztatása” feldolgozás célja az információs bázisban található információk szelektív megváltoztatása vagy tisztítása. A feldolgozás segítségével a tesztelésre való átadás előtt egy infobázist készíthetünk, ahol bizonyos információk elrejtésére (törlésére, módosítására) van szükség.

A ChangePrivateInformation.epf feldolgozása az ITS lemezen található a 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation könyvtárban. Ez a feldolgozás a következő linkről is letölthető: http://its.1c.ru/db/metod81#content:1644:1.

A bizalmas információk természetesen cégenként eltérőek, de felhívom a figyelmet azokra az adatokra, amelyeken nagy valószínűséggel változtatni kell:

Címtárak: Magánszemélyek, Kapcsolattartók, Partnerek kapcsolattartói, Partnerek, Ártípusok.
Információs nyilvántartások: Magánszemély útlevéladatai, magánszemélyek teljes neve.

A listája valószínűleg hosszabb lesz, de ezek a leggyakoribb adatok. Ezek módosítása valószínűleg nem befolyásolja az információs bázis tesztelésének képességét. Csoportos feldolgozással törölheti azokat az objektumokat is, amelyekkel a szolgáltató cégnek nem kellene dolgoznia.

3. szakasz. Szerezd meg a frissítés eredményeit

Három nappal később megkaptam a cf-fájlokat és átfogó utasításokat a telepítésükhöz. A vezérlőkiadásokhoz olyan cf fájlok állnak rendelkezésre, amelyek nem használhatók felhasználói munkára, mivel csak a metaadatok frissültek bennük. Csak a legújabb verzióra való megfelelő frissítésre szolgálnak.

Az elvégzett munka eredményeként elmondhatom, hogy a konfiguráció minden változtatása elmentésre került, vizuálisan szemlélve minden módosított objektum megőrizte jellemzőit és eltéréseit a tipikus konfigurációtól. Működés közben egyik felhasználó sem számolt be arról, hogy a változtatások elvesztek.

A frissítés eredményeként két kisebb feladatot azonosítottam egy önálló megoldáshoz.

Első. Tekintettel arra, hogy a frissítés az "Összehasonlítás, Egyesítés" mechanizmussal történik, az adatbázis konfiguráció valóban frissül, és megfelelően frissül, a vezérlőkiadások miatti technikai kockázatok nélkül. A szállítói konfiguráció azonban nem frissül. Természetesen egy műszakilag hozzáértő szakember könnyedén kiegészíti ezt a munkát, de megkértem az 1C-IzhTiSi-t, hogy küldjön teljesebb utasításokat a frissítéshez. Ennek megfelelően még egy tapasztalatlan szakember is frissítheti.

Második. A frissítés eredményeként minden objektum támogatott marad a változtatás lehetőségével, ami közvetett hátrányt is jelenthet. Ha ezeket a szolgáltatásokat egyszerre kell használnia, akkor az összes objektumot újra támogatásra kell helyeznie. Eddig ezt csak az összes metaadat-objektum felsorolásával tudom megtenni. Sajnos, bár ez a folyamat manuálisan történik, de a jövőben automatizált lesz.

Az említett két feladaton kívül egy apró hibát fedeztek fel, ami elvileg nem befolyásolja a frissítés minőségét, és ritkán jelentkezik. A frissítés hatására az eredeti konfiguráció és a frissített kódsorai vizuálisan egybeesnek, de valamiért szóközök kerülnek a sorok végére. Ez hátrány, mivel kis mértékben növeli a módosított kód mennyiségét. További kézi frissítések esetén pedig jobb lenne, ha nem lenne ilyen kódrészlet. ábrán A 6. ábra egy példát mutat a frissítés előtt, és a 2. ábra. 7 egy példa a frissítés után.

Az 1C licencszabályzat lehetőséget biztosít a szabványos konfigurációk javítására és mentésére, és ennek megfelelően azok frissítésére.*

* Módosított vagy nem szabványos konfigurációk Az 1C az 1C:Enterprise platformon alapuló szoftvertermék, amely a teljes automatizált vállalatirányítási rendszer részét képezi vagy alkotja, amely számos változáson ment keresztül az üzletág igényei és sajátosságai miatt, a címtárak, dokumentumok, szerepkörök, modulok stb. formáit és összetételét tekintve tehát az 1C konfiguráció módosításokkal történő frissítése egyáltalán nem egyenlő egy szabványos megoldás frissítésével.

Az 1C által kiadott frissítések célja a hibák kijavítása, valamint a jogszabályok miatti változtatások és kiegészítések. A közelmúltban piacra került új konfigurációkat az első típusú frissítések nagy száma jellemzi. Az olyan konfigurációkhoz, amelyek főként a szabályozási jelentések összeállítását célozzák, például "1C: ZUP", "1C: Számvitel", több, a második típusú frissítés létezik.

A nem szabványos konfigurációk frissítésének sajátosságai az, hogy minden változtatást el kell végezni az 1C legújabb kiadásán, miközben maradéktalanul meg kell őrizni a korábban elvégzett fejlesztéseket. Ez egy nem triviális feladat, amelynek megoldása nem rendelkezik szabványos szkripttel, ami azt jelenti, hogy nem automatizálható teljesen. Emiatt a nem szabványos konfigurációk frissítésének módszertanában a szakember közreműködését igénylő kézi műveletek érvényesülnek.

A nem szabványos konfigurációk frissítésének megvalósítási szakaszait nem befolyásolja a rendelkezésre álló fejlesztések mennyisége. Röviden a következőképpen jellemezhetők:

Megváltozott objektumok keresése és összehasonlítása;
Frissítések készítése az új kiadásból;
Korábban végrehajtott változtatások bevezetése, az előző szakaszban "felülírva";
Folyamatok kompatibilitásának és működésének ellenőrzése.

A különbség a megvalósítási időben lesz: ha sok fejlesztés történik, a folyamat ennek megfelelően több időt vesz igénybe, összpontosítást, odafigyelést és kézi ellenőrzést igényel.

Fontolja meg az 1C környezet nem szabványos konfigurációjának frissítését az „1C: Trade Management” (2014-es kiadás) példájával a következő elérhető kiadáshoz.

Ez egy nagyon egyszerű példa, de mint fentebb említettük, egy bonyolultabb konfiguráció frissítése természetesen sok időt és koncentrációt igényel a szakembertől, de ugyanazok a szakaszok lesznek - frissítés (új szabványra). konfiguráció), a bevitt adatok és az elvégzett változtatások egyeztetésével, stb.

A konfiguráció frissítése előtt töltse ki az információs bázist. Ezt a műveletet ajánlatos elvégezni, mielőtt bármilyen manipulációt végezne kivétel nélkül az összes adatbázissal, különösen a nem szabványos adatbázisokkal:

Infobázis kirakodás befejeződött:

Felhívjuk figyelmét, hogy ha a konfiguráció nem lett volna véglegesítve, azaz tipikus, akkor a névvel szembeni Konfiguráció ablakban a sárga kocka mellett a lakat ikon is megjelenne:

A Konfiguráció menüben válassza a "Támogatás" és a "Konfiguráció frissítése" lehetőséget. Valójában ebben a szakaszban a műveletek teljesen megegyeznek egy tipikus konfiguráció frissítésének folyamatával:

Az adatbázis méretétől és módosításaitól függően az elérhető frissítések automatikus keresése eltarthat egy ideig. Ezért az ajánlások ellenére érdemes a „Frissítési fájl kiválasztása” lehetőséget választani, és önállóan, az archívum frissítésekkel való kicsomagolása és mentése után manuálisan adja meg az elérési utat:

Ablak súgó információkkal, utasításokkal és a frissítések sorrendjével:

Konfiguráció-összehasonlító ablak. A fa bal oldalán a meglévő konfiguráció állapota, a jobb oldalon az új, szabványos verzió információi láthatók. A változásokon átesett szakaszok is kiemelve vannak. Ezután meg kell találnia, hogy mely szakaszok módosultak részünkről, és mely szakaszok mentek át egyidejűleg az új konfigurációban:

Ha meg szeretné tudni, hogy mely tipikus metaadat-objektumok módosultak korábban, és mely metaadat-objektumok módosulnak az új szolgáltatói konfiguráció telepítésekor is, válassza a "Csak kétszer módosított tulajdonságok megjelenítése" lehetőséget:

Csak olyan objektumok vannak, amelyek megfelelnek ennek a feltételnek:

A metaadat-fát kibontva láthatja, hogy mely objektumok módosulnak. Részletes információkért kattintson a jobb gombbal a módosított objektum kiválasztásához:

A módosításokat kódszinten kiértékelheti a "Modulok különbségeinek megjelenítése" funkcióval, de mivel a frissítések telepítése után ezeket is meg kell jegyezni, ezért két jelentést készítünk: "Jelentés a fő konfiguráció objektumainak összehasonlításáról a régi gyártóval. konfiguráció" (rendelkezésre álló fejlesztések) és "Új szállítói konfigurációs objektum a régi szállítói konfigurációs jelentéshez képest" (Frissítések).*

*Tegyük félre a terminológiát:

"Fő konfiguráció" - nem szabványos konfiguráció, amelyet frissíteni kell;
„Régi gyártó konfigurációja” – tipikus konfiguráció, amelyből a frissítések utoljára lettek telepítve;
„Új szolgáltatói konfiguráció” – az, amelyre most frissítünk.

Állítsa be a jelentési űrlapot, és töltse fel. A korábban végrehajtott módosítások listája rögzített:

A jelentések eltávolítása után lépjen közvetlenül a frissítéshez, és kattintson a "Futtatás" gombra. A konfigurátor felajánlja a „Vétele az új szállítói konfigurációból” frissítési szabályt (a harmadik oszlopban látható). Ez azt jelenti, hogy minden fejlesztés törlődik, és szabványos frissített objektumokra cserélődik. Ezt a szabályt a csábító "Merge Mode"-ra változtatni nem érdemes, mert. az automatikus összevonás káoszhoz vezet. Ennek ellenére jobb időt tölteni és kézzel végrehajtani a változtatásokat:

A konfiguráció támogatásból való eltávolításáról szóló általános információkat tartalmazó ablakban semmit sem kell módosítania. Az "OK" gombra kattintva az objektumok egyesülnek. Ezután elindítjuk az "Enterprise"-t, és leírjuk a változtatásokat a frissítési folyamat pontos befejezése érdekében:

A változtatások listáját elfogadjuk:*

*Ha az "Elfogadás" gomb inaktív, futtassa a "Patch Testing"-et:

Elkezdjük a hibakeresést az F5-ön keresztül, és megerősítést kapunk a frissítések jogszerűségéről:

Miután megérkezett a megerősítés, hogy a frissítési folyamat teljesen befejeződött, térjen vissza a konfigurátorhoz, lépjen a kétszer módosított metaadat-objektumokhoz, és manuálisan hajtsa végre a rögzített módosításokat kódszinten a letöltött jelentések segítségével. Befejezésül hozzátesszük, hogy ezt követően ellenőrizni kell a beállítások helyességét és a munkafolyamatok megfelelőségét.

Az összes konfigurációs módosítás megtalálásához össze kell hasonlítania az adatbázis-konfigurációt (jelenlegi konfiguráció) a szállítói konfigurációval (az eredeti konfiguráció változtatás nélkül). Ez megtehető szabványos platformfunkciókkal. A konfigurátorban lépjen a konfigurációs támogatási beállításokhoz:

Megnyílik előttünk egy konfigurációs támogatási beállítások ablak.

Az "Összehasonlít, egyesít" parancs végrehajtásával listát kapunk azokról az objektumokról, amelyek a fő konfigurációban megváltoztak a szállító konfigurációjához képest. Ez az alapértelmezett szűrő a megjelenített metaadat-fához. Így nézhet ki a szállítói konfigurációval való összehasonlítás eredménye.

Ezen a ponton kellő részletességgel megtekinthetjük a fő és a szolgáltató konfigurációs objektumok közötti különbségeket. Például a következő képernyőkép egy tipikus alkalmazás moduljainak összehasonlítását mutatja konfigurációkban.

A legtöbb esetben a metaadat-objektumok ilyen módon történő összehasonlításával frissíthetjük a tipikus konfigurációt, miközben megtartjuk az összes fejlesztést. Természetesen minden a végrehajtott változtatások összetettségétől függ, hiszen ha a teljes konfigurációt "többször átírják", akkor a gyártó hivatalos frissítési csomagjából való frissítés lehetetlenné válhat.

Kinyomtatni

A kényelem érdekében az összes konfigurációs változást listázhatja egy táblázatos dokumentumban, és felhasználhatja egy későbbi frissítésben, amikor ki kell választania a modulok kombinálásának módját, prioritást adva a fő konfigurációnak vagy a szállítói konfigurációnak. A konfiguráció-összehasonlítások eredményeinek mentéséhez részletes összehasonlítási jelentést kell készítenie a teljes konfigurációra vonatkozóan.

Az "OK" gombra kattintva részletes jelentést kapunk a tipikus konfiguráció változásairól táblázatos dokumentum formátumban, amelyet az 1C:Enterprise platform lehetővé tesz más formátumban (például Excel táblázat) is menteni. .

Ezen a ponton a változásjelentés készen áll, kezdjük el a frissítést. Ne felejtse el megvizsgálni a metaadat-objektumok frissítésének helyességét a kapott jelentésnek megfelelően.