Nem szabványos konfiguráció frissítése 1s 8.2 lépésről lépésre. Személyes tapasztalat: hogyan lehet gyorsan és költséghatékonyan frissíteni egy megváltozott konfigurációt

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.

Személyes tapasztalat: hogyan lehet gyorsan és költséghatékonyan frissíteni egy megváltozott konfigurációt

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 "Konfiguráció - Támogatás - Támogatási beállítások" lépéseket.

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

Ha a "Támogatás bekapcsolása" értékre van állítva, akkor ez a konfiguráció tipikus, és ha a "Changeable is enabled" - a konfiguráció valószínűleg megváltozik (legalábbis egy ilyen lehetőség benne van). A harmadik állapot: „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 kaptam egy e-mailt a 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. A szolgáltatások végső árát azonban a frissítés munkaerőköltségei felmérésének eredményei határozzák meg. és kiadásonként 1000 rubelnél alacsonyabb lehet."

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/method81#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.

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.

Az 1C szoftvertermékek különlegesek abban az értelemben, hogy munkájukat nagymértékben befolyásolják annak az országnak a jogszabályai, amelyben ezeket a programokat használják. Éppen ezért nagyon fontos, hogy ezeket a termékeket frissíteni tudjuk, mert a jogszabályi kérdéseken túl a frissített konfigurációk tartalmazzák majd a kritikus hibák javítását, a teljes program gyorsítását, és egyéb hasznos részleteket is. Két lehetőség van az események fejlesztésére: az első lehetőség a szabványos (tipikus) konfiguráció frissítése, ami meglehetősen gyorsan és nem igényel sok erőfeszítést, míg a második lehetőség, amikor frissíteni kell a módosított összeállítást, hosszabb és bonyolultabb.

A konfiguráció típusának meghatározása

Általában a felhasználó pontosan tudja, hogy milyen verziója van, mivel a szabványos összeállítást a program belső objektumaival való interferencia hiánya jellemzi. A másik dolog az, hogy általában a programozók módosítással foglalkoznak, illetve a felhasználó egy már módosított terméket kap, amiről nem is tud. Van egy egyszerű módja annak megértésére, hogy történtek-e változtatások ott vagy sem. Ehhez be kell lépni a Configurator módba, melynek megfelelő gombja a program start ablakában található. Ott felül van egy Konfiguráció fül, amelyen egy Támogatás elem található. Miután rákattintott, válassza a Support Setup lehetőséget. A megnyíló ablakban a „Módosítási lehetőségek engedélyezése” gombnak aktívnak kell lennie, és a szabványos összeállítás jele a lakat ikon jelenléte a build neve mellett. Ezek a jelek azt jelzik, hogy a programmodulok nem változtak, ami azt jelenti, hogy központi frissítést hajthat végre a hivatalos webhelyről az interneten keresztül. Ezen jelek hiányában vitatható, hogy a programozó a termék szerkesztésén dolgozott, miközben lehetséges, hogy a módosítás részleges volt, azaz számos objektum eredeti formájában maradt meg. Minden módosított objektum azonosító ikonok nélkül marad, a szabványos elemeket pedig sárga kockával jelöljük. A részleges módosítás nem távolítja el teljesen a programot a támogatásból, mivel lehetséges lesz az érintetlen objektumok frissítése.

Normál (tipikus) konfiguráció - felkészülés a frissítésre

Ezeken a problémákon kívül, mint például a jogszabályok változása vagy a program teljesítményének romlása, frissítenie kell, amikor az 1C program megfelelő üzenetet ad ki. Azt fogja mondani, hogy ezt a buildet egy ideje adták ki, most van egy továbbfejlesztett konfiguráció, és azonnal frissíthető a webhelyen vagy az ITS lemez használatával. Kezdetben nagyon fontos biztonsági másolatot készíteni az adatbázisról, hogy mindent vissza lehessen állítani, ha valami elromlik. Ez háromféleképpen történik. Egyszerűen átmásolhatja a gyökérmappát az adatbázissal egy lemezre vagy USB flash meghajtóra. Az 1C elindítása után a bázis kiválasztásra kerül, és az ablakban megjelenik az elérési út. Probléma esetén ez a mappa átkerül a nem működő adatbázis helyére. A konfigurátoron keresztül is cselekedhet, ehhez ki kell választania ezt a módot a programban. Az Adminisztráció részben található az Infobázis feltöltése gomb. Egy mappa kiválasztása után megjelenik ott egy .dt fájl, amely később ugyanabban a részben a megfelelő gombbal nyitható meg.

A harmadik módszer valamivel később, az interneten keresztüli frissítés szakaszában történik. A vállalkozáshoz havonta érkező ITS lemezen keresztül mindent megtehet, és ezt a lemezt az ITS-szel szerződésben álló munkatárstól is el lehet venni, csak ügyelni kell a konfigurációk egyezésére. Egyébként minden az interneten keresztül történik. Van egy fontos árnyalat: a szervizcsomagok telepítése szigorúan szekvenciálisan történik, és néhány kiadás kimaradt, a rendszer megköveteli, hogy először telepítse őket. található a Súgó menüben, ahol a Névjegy szakaszra kell kattintania.
Ha minden rendben van az internettel, akkor el kell mennie a usersv8.1c.ru webhelyre, ahol megadja bejelentkezési nevét és jelszavát. Ezután kiválasztja a szükséges konfigurációkat, amelyek a Frissítések letöltése hivatkozáson találhatók. A következő lépés a konkrét kiadások kiválasztása, figyelembe véve a legelső és a közelmúltban megjelenteket. Minden fájl egyenként mentésre kerül a számítógépre. A frissítés előtt meg kell nyitnia az összes archív fájlt, és telepítenie kell az egyes kiadásokat. A kiadások a leírtak szerint letölthetők az ITS lemezről. Most be kell lépnie a Konfigurátor módba, amely után az objektumok bal oldalon jelennek meg, ha nincsenek ott, akkor kattintson a Konfiguráció megnyitása fülre.
A frissítéshez a felhasználó a Konfiguráció-Támogatás-Frissítés konfigurációhoz lép. Az új ablakban kattintson a Keresés gombra.

A rendelkezésre álló lehetőségek közül válassza a Keresés az aktuális frissítési katalógusokban lehetőséget, majd jelölje meg az elérhető kiadást vagy azt, amelynek neve félkövérrel lesz kiemelve. Az összes többi javaslathoz kattintson az Igen gombra, beleértve az utolsó ablakot is. Az utolsó lépés a program éles üzemmódban való futtatása, hogy a frissítések érvénybe lépjenek.

Nem szabványos (módosított) 1C konfiguráció frissítése

A módosított összeállítás frissítésének lényege, hogy a programozók által végrehajtott változtatások ne vesszenek el, és a fejlesztők által végrehajtott változtatások életbe lépjenek. Ezúttal az előző utasításban leírt összes lépés megtörténik, csak az utolsó lépésben jelenik meg egy összehasonlító táblázat, ahol az egyik oszlopban egy konfiguráció található módosított objektumokkal, a második oszlopban pedig a frissítések listája. . Ezek az oszlopok metaadatfákat tartalmaznak. Zöld jelölővel a program megjelöli, hogy a programozó mely konkrét objektumokon végez módosításokat, és melyeket a termékfejlesztők. Ebben a szakaszban meg kell találnia azokat az objektumokat, amelyek ebben a két oszlopban vannak megjelölve.

A keresés egyszerűsítéséhez használhatja a Szűrő gombot, amely lent található, majd jelölje be a Kétszer módosított tulajdonságok megjelenítése négyzetet. Ha mindent helyesen tettünk, akkor csak a szükséges objektumok jelennek meg a munkaablakban. A nem szabványos modulok frissítési eljárása nem befolyásolja a konfigurációt.

Elemeznünk kell ezt a táblázatot. Ebben az esetben jól látható, hogy a változások mindkét esetben megtörténtek, hiszen vannak ceruza ikonok, hiszen a modul neve mellett is van egy ikon, ami azt jelenti, hogy összevonják őket. A jobb oldali utolsó oszlop azt jelzi, hogy a folyamat végén az összes felhasználói kód megváltozik a fejlesztői frissítés javára.

Vannak más módok részleges egyesítéssel (prioritás), de ezeket a módokat a tapasztalt felhasználók használják, mivel egy kezdő minden fejlesztést zavaros modulokká alakít. Ennek megfelelően az utolsó oszlopban nincs értelme változtatni valamit. Másrészt az első oszlopban lévő jelölőnégyzet eltávolításával a kényszerített összevonás megszakítható. Ennek alapján vagy manuálisan adhatja hozzá a kódot a frissített modulhoz, vagy hagyja magára a kódot, és saját kezűleg végezze el a frissítéseket. Ahhoz, hogy megértse, mit kell pontosan elkészítenie, kattintson a jobb gombbal a kiválasztott modulra, és válassza a Különbségek megjelenítése lehetőséget. Ez a lépés megmutatja az egyes eljárások különbségeit. Az ablak alján szintén két oszlopra van osztva, de ott már maga a kód is megjelenik.

A további műveletek a modulváltások mértékétől függenek, ha a konfigurációt radikálisan átírták, akkor rendkívül nehéz lesz mindent önállóan frissíteni, programozó segítsége nélkül.

1C frissítésekor lehetséges

A legtöbb hiba akkor történik, amikor az alap erősen módosítva van, mivel több oldalnyi kód, különféle kézikönyvek és egyéb objektumok megzavarhatják a tapasztalatlan felhasználót. Nagyon fontos, hogy minden változtatás előtt hozzon létre és mentsen el egy archívumot a biztonsági mentés helyreállításához, majd még egyszer ellenőrizze, hogy minden megfelelően történt-e. A klasszikus hiba az, hogy egy nem általános összeállítást úgy frissítenek, mintha szabványos lenne. De még ha követi is a leírt utasításokat, távolról sem tény, hogy a program azonnal úgy fog működni, ahogy kellene. Valószínűleg elengedhetetlen a további konfiguráció. A konfigurátor nem jeleníti meg a párbeszédablak vezérlőiben végrehajtott változtatásokat, ezért ezt a pillanatot manuálisan kell ellenőrizni, különben a frissítések felülírják mindezt. A frissítés után a konfigurátor tiltást jeleníthet meg a régi infobázis frissítésére, mivel a bizonylatszámok már nem egyediek, ugyanez vonatkozik az információs nyilvántartásokra is.

A probléma megoldásához szüksége lesz:
- módosítsa a karakterek számát a kódokban;
- módosítsa a kódokat az infobázisban;
— módosítsa az egyediségvezérlő tulajdonságot az összes könyvtárban.

A frissítés során nem szabad megfeledkezni a felületek és a felhasználói jogok frissítéséről, amit gyakran figyelmen kívül hagynak. A kiadások szekvenciális frissítésének fontosságát már leírtuk, kiemelten fontos a konfigurációs frissítések beépített feldolgozása is, amely lehetővé teszi a szükséges adatok konvertálását és az adatbázisok szükség esetén információkkal való feltöltését. A felhasználó érdeke, hogy figyelemmel kísérje a belső objektumazonosítók vagy -részletek egyezését, ellenkező esetben a frissítés minden fejlesztést felülírhat. Még egy új konfiguráció gondos előkészítése után sem kezdheti el azonnal a használt munkabázissal való kombinálását, mivel azt is frissíteni kell, majd mindent alaposan tesztelnek.

Meg kell értenie, hogy vannak olyan lehetőségek, amikor a konfiguráció visszaküldésre kerül támogatásra, vagyis a frissítési folyamat a program szabványos módjában történik, a kiadás internetről történő letöltésével. A program a módosított modulok termékbe történő bevezetése után megszűnik a támogatásból. Ezeknek a moduloknak az eltávolítása visszaállítja a programot az eredeti állapotába, de nem lehet teljesen megszabadulni tőlük, mivel az 1C normál működése lehetetlen lesz, mert valamiért ezekkel programozták a modulokat. Ennek megfelelően ezek a modulok kivehetők a programból - a munka külső modulok segítségével történik, de ez nem befolyásolja a program működését. Így a könyvtárak és egyéb objektumok a helyükön maradnak, ezt a szükséges ismeretek nélkül saját kezűleg megcsinálni problémás, ezért a programozónak szükség esetén vissza kell adnia a programot a standard assembly keretébe.

Számos tipp is található az 1C szoftvertermékek jövőbeni frissítési folyamatának megkönnyítésére. Mindenekelőtt próbálja meg a lehető legkevesebbet módosítani a programon, és hacsak nem feltétlenül szükséges, akkor ne vezessen be oda semmi harmadik félt, hanem próbálja meg megoldani a problémákat azokkal a tipikus eszközökkel, amelyek rendelkezésre állnak. A konfiguráció minden változását kivétel nélkül kommentálni kell és külön dokumentumban rögzíteni kell, hogy a helyreállítási folyamat során semmi fontos se maradjon el. A típusobjektumokban lévő programkód mennyiségének csökkentése érdekében át kell helyezni a saját közös moduljába, miközben meg kell érteni, hogy az eljárások és függvények hívásait nem lehet megérinteni - ezeknek a típusobjektumokban kell maradniuk, hogy a program működjön. helyesen. Optimalizálási célból célszerű az objektumok "önírt" kódjában és a külső modulok kódjában szereplő szabványos eljárások és függvények összes hívását a saját moduljukból származó eljárások meghívására cserélni. Ezek az eljárások egy egyszerű parancsikon, amellyel az általános modulokból származó eljárások meghívásra kerülnek. Így a változtatások összehasonlításakor a felhasználónak nem kell sokáig keresnie a módosított kódban a szükséges sorokat. Ezeknek az ajánlásoknak megfelelően a frissítési idő több órás munkára csökken, és ha minden a régiben marad, a folyamat több napig elhúzódhat.

A nem szabványos, erősen módosított konfiguráció frissítése nagyon időigényes és felelősségteljes feladat. Jellemzően a rendszer olyan konfigurációkhoz hajt végre kiadásfrissítést, amelyek szabályozott jelentési blokkot tartalmaznak. Például, .

Tekintsük a legegyszerűbb módot a nem szabványos frissítések hibamentes elvégzésére, az 1C Enterprise Accounting konfiguráció példájával.

A frissítés kezdetét a cikk ismerteti. Csak a legfontosabbat vesszük figyelembe - az atipikus frissítés árnyalatait.

Egy kis elmélet a nem szabványos konfigurációkról:

• A nem támogatott konfiguráció 2 konfigurációt tartalmaz: az adatbázis konfigurációt és a fő konfigurációt.
• A szerkesztési lehetőség nélküli támogatási konfiguráció 2 konfigurációt tartalmaz: az adatbázis konfigurációt és a fő konfigurációt (más néven szállító).
• Egy támogatott konfiguráció, amely megváltoztatható, már 3 konfigurációt tartalmaz: egy adatbázis-konfigurációt, egy fő konfigurációt és egy szállítói konfigurációt.

1. Felkészülés a frissítésre

Az összes lépés megkezdése előtt győződjön meg arról, hogy a gyártó konfigurációja megegyezik a fő konfigurációval - ez nagyban megkönnyíti az atipikus frissítést. Ha a szolgáltató konfigurációja egy régebbi verzió, akkor a konfigurációt korábban hibásan frissítették. Frissítheti a szállítói kiadást úgy, hogy egyesével futtatja a frissítést, és nem választ ki egyetlen objektumot sem az összehasonlításhoz.

Először is telepítek 2 alapot a kezdeti konfigurációval. Az egyik a változtatások végrehajtásához, a második az újjal való összehasonlításhoz.

Ingyenes 267 1C videóleckéket kaphat:

Ha az Ön konfigurációja nem jellemző, akkor a konfigurátor „frissítés” gombjának megnyomásával a rendszer elkezdi összehasonlítani a fő és az új beszállítói konfigurációt:

Külsőleg úgy tűnik, hogy nagyon sok tárgyat megváltoztattunk. Azonban képzeljük el a helyzetet: megváltoztatta a dokumentumot, de nem változott - manuálisan kell frissítenie? Természetesen nem. Az ilyen objektumok összehasonlítás utáni kiválasztásához feltétlenül kattintson a gombra Szűrőés jelölje be a négyzetet

Szűrés után azt látjuk, hogy sokkal kevesebb a módosított objektum:

Kaptunk egy listát azokról a tárgyakról, amelyeken dolgozni fogunk. Esetünkben csak egy összetett objektum volt - a RecordKUDiR dokumentum.

2. Az 1C frissítés módosításainak átvitele

A változtatások átviteléhez megnyitok 2 konfigurátort – az egyikben összehasonlítást futtatok és felveszem a változtatásokat, a másikban pedig fejlesztéseket hajtok végre.

A következő lépés a változtatások közvetlen átvitele. Fontolja meg a nem szabványos konfigurációk frissítésének alapvető technikáit.

3. Különbségek a modulokban

Meglehetősen egyszerű, de nagyon felelősségteljes művelet - egyszerűen áthelyezzük a modulokat egy új kiadásról a régire. Ha a kód megjegyzésben van, akkor nem lehet probléma:

4. Formák és elrendezések összehasonlítása

Itt a folyamat sokkal bonyolultabb. Az űrlapokon a legkisebb változásokat is észre kell venni. Azt javaslom, hogy készítsen részletes jelentést a különbségekről grafikus tükrözéssel:

Miután átvitte az összes objektummódosítást az új konfigurációból, indítsa újra az összehasonlítást és az egyesítést, és távolítsa el a manuálisan módosított objektumokat összehasonlítás céljából.

A módosított 1C konfiguráció atipikus frissítése befejeződött!

Jegyzet! Ha nem tudja, hogyan kell programozni az 1C 8-ban, a nem szabványos konfiguráció sikeres frissítésének esélye rendkívül kicsi. Sok időt fog tölteni, és olyan konfigurációt kap, amely nem is fut. Javaslom azonnali segítségért fordulni.