Navodila po korakih za posodobitev nestandardne konfiguracije 1c. Osebna izkušnja: kako hitro in stroškovno učinkovito posodobiti spremenjeno konfiguracijo. Pridobivanje datoteke ponudnika

Posodabljanje nestandardne platforme je zelo težko. Preučili bomo, kako posodobiti nestandardno konfiguracijo 1C in opisali postopno rešitev nastajajočih težav.

Kot v ne tipična konfiguracija 1C izvedite posodobitev.

Splošni pojmi

Pri posodabljanju nestandardne platforme spremembe vedno vplivajo na elemente standardne konfiguracije dobavitelja.

Baza podatkov (DB) vsebuje do tri vrste konfiguracij:

  • sama baza podatkov - z njo delujejo logični algoritmi;
  • delovni (tako imenovani glavni, ConfigOR) - ki ga občasno spreminjamo;
  • konfiguracija dobavitelja (ConfigP - na njegovi podlagi uporabnik ustvari tako delovno kot bazo podatkov).

Če je program izključen iz podpore, ne bo več na voljo pri dobavitelju. Vendar je takrat povečanje stroškov dela za posodobitev neizogibno. Razmislimo o posodobitvi nestandardne konfiguracije 1C. Primer bi bila platforma PPM (Manufacturing Enterprise Management).

Mešanje

Prvi korak je odstranitev razlik med delujočo in dobavljeno konfiguracijo. To bo zmanjšalo vrednotenje izboljšav, ki smo jih naredili prej. Do neskladij med njimi pride, če so bile med posodabljanjem uporabljene tuje datoteke (ki niso iz priložene distribucije) ali pa se metode posodabljanja razlikujejo od standardnih.

Primerjava različic

Preverimo številke različic (delujoča in dostavljena). Prvi je označen v “Konfiguracija” / “Odpri” / “Uredi” / “Lastnosti”. V razdelku "Razvoj/različica". Drugič v »Konfiguracija« / »Podpora« / »Nastavitve podpore« / »Različica«:

Če se številke ujemajo, lahko nadaljujete v razdelek Prejemanje datoteke s posodobitvijo.

Naslednji koraki prikazujejo, kako uskladiti delovno konfiguracijo in konfiguracijo dobavitelja. Da bi dali na podporo tiste predmete, ki jih je uporabnik odstranil ali dodal brez podpore. Za to:

Shranjevanje konfiguracije (deluje)

Shranimo ConfigOR v datoteko z imenom, na primer work.cf. Če želite to narediti, izberite »Konfiguracija«/»Shrani ...«.

Pridobivanje datoteke ponudnika

Če želite združiti ConfigOR s ConfigP, potrebujete datoteko cf iz dobaviteljeve distribucije (ista različica). Privzeto bo v C:/Program Files/1cv81/tmplts. Preverimo prisotnost zahtevane datoteke cf v tabeli predloge. Kaj naj storim, če nimam zahtevane konfiguracijske datoteke prodajalca za zahtevano različico? Nato morate iz stare ustvariti prazno bazo podatkov, jo posodobiti na zahtevano različico in šele nato uporabiti.

Prejemanje datoteke prek posodobitve

Za posodobitev datoteke ConfigP cf izberite ukaz iz menija: “Konfiguracija/Podpora/Posodobi.../Izberi datoteko/Dokončaj/Zaženi” (zaporedoma na slikah):

Če želite to rešiti, morate počistiti oznako za izbris iz predmeta v konfiguraciji dobavitelja. Nato po brisanju znova izvedemo primerjavo - v oknu za posodobitev kliknite gumb »Posodobi«.

Obnavljanje nastavitev

Nekatere izgubljene nastavitve se obnovijo tako, da se združijo s predhodno shranjeno datoteko work.cf. To storite tako, da izberete »Konfiguracija/Primerjaj, združi ... datoteke«.

Varčevanje in prilagajanje

Če želite shraniti ConfigOR in posodobiti bazo podatkov, v točki menija »Konfiguracija« izberite »Posodobi...DB«. Tu naletimo na nov problem:

Najverjetneje je bil razlog za to, da so bili ti objekti kopirani iz ConfigP ali pa jih je dobavitelj izbrisal, kasneje pa so bili dodani novi pod istimi imeni. Vendar z različnimi identifikatorji. Posledično so se pojavili predmeti istega imena, vendar z različnimi identifikacijskimi ključi.

Vloge lahko preprosto izbrišete, saj niso bile spremenjene. Atribut je treba preimenovati, na primer v OrderReserve1. In po posodobitvi vnesite vrednosti iz preimenovane v ustvarjeno. Druga situacija med posodobitvijo. Kaj pa obrazci?

Iz slike je razvidno, da je dobavitelj obrazec Seznam izbrisal in nato ponovno dodal pod istim imenom. Oba morate označiti za posodobitev in klikniti »Zaženi«.

Če se med posodobitvijo izda sporočilo o prisotnosti povezav do predmetov, ki jih je treba izbrisati, morate brez zapiranja obrazca počistiti povezave do njih v lastnostih samih predmetov. Tukaj je v registru lastnosti. Nato v obrazcu za posodobitev izberite možnost posodobitve, označite lastnosti registra za posodobitev zdaj in znova kliknite »Zaženi«.

Shranjevanje sprememb v delujočo bazo podatkov in posodobitev konfiguracije baze podatkov: “Configuration/Update...DB”. Prenos vrednosti atributa OrderReserve1 v OrderReserve se izvede z zunanjo obdelavo načina 1C:Enterprise.

Priprava podlag

Na podlagi rezultatov informacij pripravimo dve enaki bazi podatkov. Prvi (glavni) je naš želeni rezultat. Drugi (pomožni) je za izvajanje pripravljalnih dejanj. V primeru datotečne različice jih enostavno prekopiramo v imenik in povežemo s seznamom informacijske varnosti z možnostjo odjemalec-strežnik, izvedemo nalaganje/prenos.

Primerjava

Po odprtju obeh podatkovnih zbirk s konfiguratorjem bomo izvedli njuno tristransko primerjavo. Za to uporabimo novo datoteko ConfigP - “Konfiguracija/Podpora/Posodobitev…/Izberi datoteko…/Končano”:

Če primerjamo delujoče, stare in nove konfiguracije ponudnika, dobimo seznam spremenjenih objektov s filtrom »Prikaži dvakrat spremenjene lastnosti«. Najprej morate rešiti težavo z njimi:

Na tej točki je delo s pomožno bazo podatkov začasno ustavljeno, dokler ni končan celoten proces; ne pritisnemo več gumba »Zaženi«. Preidimo na delo v glavni bazi podatkov z nastalim seznamom dvakrat spremenjenih objektov. Če se strinjate s posodobitvijo, boste izgubili predhodno opravljene izboljšave. Zato je treba za vsakega od objektov sprejeti odločitev, kako ga bomo spremenili.

Preliminarno oceno bomo izvedli le zaradi zmanjšanja prihodnjega dela. Če je v novem ConfigP več sprememb elementov, zapustimo objekt dobavitelja. Postavili smo kljukico. Spremembe prenesemo iz ConfigOR. Če je v delovni konfiguraciji več sprememb elementov, pustimo primerek objekta ConfigOR. Počistite polje. Prenesimo spremembe iz ConfigP. Module je treba primerjati postopkovno. Če želite to narediti, pritisnite gumb, kot je na sliki:

Označimo polja, ki označujejo postopke in funkcije, ki jih je treba zamenjati ali odstraniti:

Zdaj morate podvojiti stanje potrditvenih polj v pomožni bazi podatkov. V glavnem kliknite »Zaženi«. Na tej točki v glavnem dobimo skoraj pripravljeno konfiguracijo.

Naknadne primerjave se ponovno izvajajo v pomožni bazi podatkov. Prejšnje spremembe najdemo z dodatno primerjavo starega ConfigP s ConfigOR - “Konfiguracija/Primerjava...”:

Podobno primerjamo stari ConfigP z novim. Če ni nove datoteke, jo lahko vzamete iz glavne baze podatkov.

Tako dobimo dvakrat spremenjene objekte. V glavni bazi podatkov je bila pridobljena skoraj že pripravljena konfiguracija. V njem se morate ukvarjati z dvakrat spremenjenimi elementi.

POMEMBNO.

Za odločitev je dovolj, da primerjate obrazce, tabele in objektne module. Včasih so podatki v poročilih predstavljeni v obliki, ki ne omogoča hitrega odločanja. Na tem koraku pride do izgube sprememb, če spremembe zadevajo podrobnosti objekta sestavljenega tipa.

V primerjalnem poročilu so različni podatki predstavljeni v obliki seznama, iz katerega ni jasno, kateri tipi podatkov so bili dodani/odstranjeni. Če število vrstic poročila doseže dvesto, se postopek "ročne" primerjave zdi precej delovno intenziven (približno petdeset ur).

Zmanjšanje delovne intenzivnosti se doseže z uporabo na primer konfiguracije "Cell Comparison" podjetja Inform Service. Na voljo je za zagon v načinu 1C:Enterprise in v priročni obliki predstavlja podatke primerjalnega poročila. Primerjava se izvede z uporabo zmogljivosti 1C:

Shema delovanja je preprosta. V konfiguratorju se ustvari primerjalni objektni izpis. Shranjeno v datoteko, na primer Comparison Report.mxl. V pogovornem oknu 1C:Enterprise se odpre in celice, ki se primerjajo, so označene (z dvojni klik desni klik na izbrano celico dokument s preglednico). S klikom na “Primerjaj” se prikaže rezultat primerjave z barvami označenimi različnimi pozicijami.

Nadaljnja navodila za ukrepanje izgledajo takole.

  1. Naslednje poročilo se shrani z istim imenom.
  2. Po končani posodobitvi in ​​prenosu sprememb standardne konfiguracije se izvede sintaktični nadzor modulov in testiranje delovanja spremenjenih objektov.
  3. Po uspešnem testiranju se lahko šteje, da je postopek zaključen. Ostane le še posodobitev tiskanih obrazcev, poročil in obdelav. V nekaterih primerih preverite zunanje obrazce za poročanje.

Delamo z 1C 7.7

Posodobitev standardne platforme na isto običajno ne povzroča težav. Samo slediti morate navodilom v navodilih. Nahajajo se v UPDATE.TXT distribucijskega imenika.

Prav tako ni težav, če so na platformo dodani dodatni računovodski elementi (imeniki, konstante, selekcije, poročila, registri, obračunski dnevniki itd.). Ustrezali bodo, ko bodo platforme združene. Dodani dokumenti prav tako ne bodo povzročili neskladja, če ni bilo sprememb v karakteristikah za vnos »na podlagi« tako dodanih dokumentov.

Priporočljivo je, da posodobitev izvedete na hitrem računalniku z veliko količino RAM-a. Če ga primanjkuje, lahko 1C zavrne delo nekaterih funkcij in "zamrzne". Velika količina navideznega pomnilnika ne reši te težave.

Ustvarjanje varnostne kopije

V ta namen morate uporabiti možnost: “Administracija/Shrani podatke...”. Primerno je navesti ime arhiva in ga združiti z datumom ustvarjanja (na primer LLMMDD.zip).

Priprava katalogov

Za delo boste potrebovali šest konfiguracijskih datotek (1cv7.md):

  1. “WorkingNew” za pripravo posodobitve (nastala md-datoteka);
  2. “WorkingOld” za sledenje spremembam med primerjavo in za prenos nastavitev v TypeNew_2;
  3. Tipičen (star) “TypeOld_1”. Na njegovi podlagi je bil predhodno ustvarjen delovni.
  4. Vrste. (prejšnji) “TypeOld_2”. Slediti spremembam v podjetju 1C v novi standardni različici;
  5. Vrsta. (novo) "TypeNew_1". Izboljšave iz 1C v novi različici;
  6. “TypeNew_2” za kompleksne predmete.

In pet delujočih konfiguratorjev (vsi razen »TypeNew_1«).

Na začetku so imeniki v parih enaki:

  • “WorkerNew” in “WorkerOld”;
  • "TypeOld_1 in TypeOld_2";
  • "TypeNew_1" in "TypeNew_2".

Kombiniranje elementov

Najprej naredimo primerjavo med 3 in 2, 4 in 5, 1 in 6. Če želite to narediti, za vsakega od prvih v paru izberite postavko »Konfiguracija / Združitev ...« in določite datoteko z metapodatki 1cv7. md drugega v paru. Na zaslonu se prikaže obrazec z drevesom spremenjenih elementov. Nato je treba analizirati rezultate parne primerjave 3 z 2 in 4 s 5. Pustite za združevanje elementov v posodobljenih platformah (1 in 6), v katerih je prišlo do sprememb iz podjetja 1C (4 s 5) , vendar se niso odražala v 3 in 2. 1 in 4 je treba združiti v substitucijskem načinu.

drugi

To lahko vključuje kontni načrt in uporabniške vmesnike. Če je prišlo do sprememb v kontnem načrtu, ga je treba posodobiti v načinu “Kombinacija objektov” WorkerNew skupaj s TypeNew_2. Po združitvi vmesnika se preveri prisotnost napak: podvajanje elementov menija, podvajanje orodnih vrstic, nastavitev zastavic »Postavitev v novi vrstici« za orodne vrstice.

Prenos poteka preko omrežja ali na strežniku (prednostno). Prvič, zagotovljen je ekskluzivni dostop do baze podatkov. V načinu konfiguratorja se nato naloži baza podatkov. Pred in po prenosu se podatki arhivirajo (kot je opisano na samem začetku razdelka). Nato morate slediti navodilom v datoteki UPDATE.TXT. Ko je prenos končan, lahko izbrišete vse imenike razen WorkNew.

Upamo, da vam je naša publikacija pomagala razumeti posodobitev nestandardne konfiguracije 1C. To smo preučili glede na sedmo in osmo različico.

Pustite komentarje, pišite o svojih izkušnjah v posodobitvi 1C.

Posodobitev 1C se izvede s pritiskom na gumb "ena", tipična konfiguracija lahko sama prenese posodobitev 1C in jo namesti. Uporabnik bo moral le vnesti podatke o registraciji.

Kaj storiti, če je konfiguracija netipična? Ali pa standardnega, vendar je bilo na njem narejenih nekaj sprememb - imenik, par podrobnosti, poročilo?

Danes bomo izvedeli odgovor na to vprašanje.

Kaj je nestandardna konfiguracija 1C

Netipična konfiguracija 1C je, ko:

  • Konfiguracijo je iz nič napisal programer sam
  • Konfiguracija je bila standardna, vendar so bile dodane spremembe
  • Tudi če ste dodali en rekvizit.

Če želite spremeniti standardno konfiguracijo, morate.

Pri posodabljanju 1C nestandardne konfiguracije, ki je bila odstranjena iz podpore, bo 1C ponudil, da "nestandardno konfiguracijo vrne v podporo." Nato bodo vse spremembe preklicane (izbrisane).

Če želite zagotoviti, da pri posodabljanju 1C na nestandardno (spremenjeno) konfiguracijo 1C spremembe ostanejo in se uporabi posodobitev 1C, lahko uporabite drugačen način posodabljanja 1C.

Oglejmo si primer spremenjene konfiguracije, ki jo želimo posodobiti. To je tipična konfiguracija 1C Računovodstvo (levo), ki je bila spremenjena (desno):

4) V imeniku »Posamezniki« je bila v modulu obrazca v funkciji ReadPlace of Birth() dodana programska vrstica

Kako bodo vse te spremembe delovale v času posodobitve 1C na nestandardno konfiguracijo 1C?

Posodobitev 1C s shranjevanjem sprememb nestandardne konfiguracije 1C

Posodobitve konfiguracije 1C se običajno distribuirajo kot samoraztegljivi arhiv. Po razpakiranju morate zagnati namestitveno datoteko, da namestite posodobitev 1C v računalnik (ne v 1C!).

Pri nameščanju posodobitve izberete, kam bo nameščena posodobitev 1C. Ponavadi to. Namestite lahko v katero koli drugo mapo na disku, 1C pa navede, kje je .

Posodobitvene datoteke 1C so lahko v naslednji obliki:

  • datoteka s končnico CF – vsebuje v celoti nova vrsta konfiguracije
  • datoteka s pripono CFU – vsebuje samo spremembe prejšnje različice.

Obe datoteki sta shranjeni v imeniku posodobitev 1C, v mapi z imenom različice.

Bodite previdni pri uporabi datoteke CFU - dovoljuje samo posodabljanje iz !

Če želite posodobiti 1C, izberite eno od možnosti menija:

  • Konfiguracija/primerjaj spajanje s konfiguracijo iz datoteke – za datoteke CF
  • Konfiguracija/Podpora/Posodobi konfiguracijo/Izberi datoteko za posodobitev 1C – za datoteke CF ali CFU.

Najprej bo 1C primerjal obe konfiguraciji. Konfiguracija vaše baze podatkov se imenuje »Glavna konfiguracija«, konfiguracija iz posodobitve pa se imenuje »Konfiguracija iz datoteke«.

1C bo prikazal vse razlike v obliki znanega drevesa, kjer so spremembe prikazane na desni.

Poglejte - v našem primeru so imeniki, ki so bili spremenjeni ali dodani, označeni.

Ker posodabljamo nestandardno konfiguracijo 1C, ki je bila spremenjena - torej je bila nekoč standardna, je treba vnesti nekaj nastavitev.

Kliknite gumb Nastavitve. Izberite »Naložena konfiguracija je potomec glavne« (to je spremenjena standardna konfiguracija).

Potrditveno polje »Dovoli brisanje glavnih konfiguracijskih objektov« omogoča brisanje, če so bili izbrisani v posodobitvi 1C. Ker smo konfiguraciji dodali podrobnosti in imenike, vendar jih ni v posodobitvi 1C, bo 1C upošteval, da so bili odstranjeni v posodobitvi 1C. Zato tega polja ni treba potrditi.

Oglejmo si pobližje razlike, ki jih je zaznala platforma.

Razširimo vejo imenika Nomenklatura. V veji Podrobnosti vidimo, da standardna konfiguracija nima podrobnosti, vendar jih dodamo. Znak minus pomeni, da bo izbrisan.

Ker ne potrebujemo odstranitve rekvizitov, ki smo jih dodali sami, moramo narediti naslednje (možnosti):

  • V gumbu »Nastavitve« NE označite potrditvenega polja »Dovoli brisanje glavnih konfiguracijskih objektov«.
  • Če je potrditveno polje še vedno označeno, počistite polje poleg tega atributa. Na sliki ob rekvizitih ni kljukice, ker brisanje objektov ni dovoljeno.

Spremenjena je bila tudi oblika Nomenklaturnega priročnika. 1C je to opazil in nam tudi na seznamu spremenjenih objektov prikaže obrazec imenika.

Če želite videti, katere spremembe so bile narejene na obrazcu, lahko storite naslednje (možnosti):

  • Z desno miškino tipko kliknite najprej na obrazec v levem stolpcu in izberite menijsko postavko “Odpri obrazec”, nato pa še v desnem. Vizualno primerjajte obe obliki.
  • Z desno miškino tipko kliknite na obrazec in izberite menijsko točko "Poročilo o primerjavi objektov" (podrobnosti, preglednica)

Primerjalno poročilo predmetov pri primerjavi oblik pokaže veliko razlik. To je posledica dejstva, da ko obrazcu dodamo samo eno polje, se samodejno spremeni veliko sosednjih elementov - zamiki, sidra itd.

Na seznamu sprememb vidimo naše spremembe - spremembe oznake in zamenjavo polja.

S spremembo obrazca se lahko strinjamo ali zavrnemo tako, da potrdimo polje poleg njega. To ima naslednje posledice:

a) če potrdimo polje

  • obrazec bo zamenjan z novim
  • naše spremembe standardne konfiguracije bodo izbrisane
  • uporabljene bodo spremembe iz posodobitve 1C
  • potem bomo morali ročno razveljaviti naše spremembe

b) če ne označimo polja

  • obrazec bo ostal tak, kot je
  • naše spremembe ostajajo
  • nove spremembe iz posodobitve 1C se ne uporabljajo
  • Nato boste morali ročno dodati spremembe iz posodobitve 1C.

Uporabite lahko tretjo možnost. Razširite vejo Obrazec do konca in v stolpcu »Način spajanja« izberite »Spoji«.

c) če smo izbrali »Združi«

  • pojavila se bo neka nova oblika, v kateri bodo tako nove spremembe kot stare
  • naše spremembe ostajajo
  • se pojavijo nove spremembe
  • če je bilo polje odstranjeno in na njegovo mesto postavljeno drugo polje, bosta zaradi združitve na istem mestu obe polji hkrati - tako staro kot novo
  • obstajajo možnosti, da bo obrazec izgledal normalno
  • potem morate ročno preveriti, da ni prišlo do "ekscesov".

2) V imeniku »Posamezniki« je bila v modulu obrazca v funkciji ReadPlace of Birth() dodana programska vrstica

Če si želite ogledati spremembe v modulu obrazca, ki jih je zaznal 1C, razširite vejo obrazca do konca, jo kliknite z desno miškino tipko in izberite element menija »Prikaži razlike v modulih«.

Spremembe so prikazane v kontekstu vsake funkcije, vendar se lahko v tem načinu ogleda odločite za posodobitev 1C celotnega modula ali pa ga zavrnete.

Drug način je uporaba gumba povečevalnega stekla v tej vrstici.

Potem ne bomo videli le sprememb v kontekstu vsake funkcije, ampak lahko uporabimo tudi potrditvena polja, da izberemo, katero funkcijo želimo posodobiti in katero ne.

3) Več podrobnosti je bilo odstranjenih iz imenika »Electronic Submissions..«.

1C je ugotovil, da smo izbrisali podrobnosti standardnega imenika, in nam ponuja, da jih obnovimo.

Imenik, ki smo ga dodali, 1C predlaga brisanje. V tem primeru velja isto pravilo kot v primeru rekvizitov, ki smo jih dodali (glej prej).

Naša naloga je torej, da skrbno preučimo odkrite spremembe 1C in uporabimo potrditvena polja, da se z njimi strinjamo ali zavrnemo. Po tem kliknite gumb Zaženi.

Upoštevajte, da če ste zaradi posodobitve 1C izbrisali atribut, ste izbrisali tudi podatke, ki so jih vanj vnesli uporabniki, kar pomeni, da ponovno dodajanje istega atributa ne bo obnovilo teh podatkov.

Če ima konfiguracija več povezanih objektov - na primer rekviziti in obrazec; Hkrati ste dovolili posodobitev obrazca 1C, vendar ste počistili potrditveno polje, nato pa pride do protislovja.

Po kliku na gumb Zaženi 1C najde takšne situacije in iz njih poroča.

Po kliku na gumb Run imate še eno priložnost za razmislek.

Če želite potrditi posodobitev 1C, morate izbrati točko menija Konfiguracija/Posodobi konfiguracijo baze podatkov.

Če želite zavrniti posodobitev 1C, morate izbrati točko menija Konfiguracija/Nazaj na konfiguracijo DB.

Tretja možnost (navedeno je zaporedje elementov menija):

  • Izberite Datoteka/Shrani
  • Konfiguracija/Shrani konfiguracijo v datoteko
  • Konfiguracija/Konfiguracija baze podatkov/Nazaj v konfiguracijo baze podatkov.

Tako dobljeno kombinirano konfiguracijo naložite v datoteko in zavrnete spremembe. Nastalo konfiguracijo lahko analizirate, ročno uredite in jo pozneje preprosto naložite z uporabo menija Konfiguracija/Naloži konfiguracijo iz datoteke.

Obstaja veliko navodil za posodobitev spremenjenih standardnih konfiguracij platforme 1C. Zato, da ne bi povečeval bistva, ne bom v celoti opisal celotnega postopka. Poleg tega se domneva, da je to besedilo za osebo, ki je že posodobila spremenjene konfiguracije in pozna glavne točke in pasti. Ta metoda le poenostavlja ta proces, saj v bistvu predlaga uporabo avtomatizirane primerjave sprememb konfiguracije in sprememb v modulih na ravni primerjave besedilnih datotek. S tem pristopom se močno zmanjša verjetnost napak (»prepisovanje« pomembnih sprememb zaradi nepazljivosti), povezanih s »človeškim faktorjem«.

VSAKA posodobitev konfiguracije se začne z razbremenitvijo informacijske varnosti. To je "zlato pravilo", tega se je treba vedno spomniti, to je treba storiti s katero koli metodo (tudi če so o tem pozabili povedati). Nato lahko greste na dva načina: posodobite v testni bazi podatkov ali posodobite v produkcijski bazi podatkov. Pri tem je pomembna naslednja točka: običajno spremenjene konfiguracije se ne posodabljajo za vsako izdajo (saj je to mogoče zlahka storiti s standardnimi), ampak za več hkrati, saj je ta postopek delovno intenziven. Prvi način (posodobitev na testni bazi) vključuje končni prenos posodobitve v delujočo bazo s prenosom cf datoteke. V tem primeru lahko pride do napak, povezanih z izbrisanimi podatki (o tem lahko najdete veliko člankov). Zato obstaja nekaj tveganj, vendar lahko uporabniki med posodobitvijo (ki lahko traja cel dan ali celo dlje) varno delajo in spreminjajo bazo podatkov. Pri drugem načinu (posodobitev na delujočo bazo) so ta tveganja odpravljena, vendar ves čas trajanja posodobitve ključni uporabniki ne bodo mogli delati v tej bazi. Na forumih je dovolj razprav o tem, katera metoda je dobra in ali se splača posodobitev prenesti prek konfiguracijske datoteke. Lahko samo rečem: na podlagi izkušenj z uporabo prve metode, podobne napake se ni zgodilo pri nalaganju datoteke cf. V vsakem primeru lahko bazo podatkov obnovite z varnostno kopijo. Tu bo obravnavana prva metoda, vendar to ne vpliva na bistvo metode in po želji lahko nadaljujete po drugi metodi s predlagano metodo.

Torej, po uvedbi testne baze podatkov s svežo varnostno kopijo naredimo zaporedne posodobitve izdaje na najnovejšo. Po vsaki izdaji zaženemo »Debug«, da shranimo konfiguracijske spremembe in reorganiziramo podatke. V vsem pogovorna okna Kliknite OK/Naprej/Sprejmi/Da/Nadaljuj...

Tako smo konfiguracijo na testni bazi posodobili na zadnjo izdajo, vendar moramo preveriti, ali smo kakšne spremembe prepisali, in če smo jih prepisali, jih moramo prenesti v to izdajo. Zdaj se začne zabava, zato jo bom opisal korak za korakom. Vsak korak bo imel neko razlago: to pomeni, da je najprej opisano bistvo in nato več natančen opis. Če je bistvo jasno, potem lahko opis izpustimo.

1. Spremembe konfiguracije PRED in PO posodobitvi shranimo v besedilne datoteke. Odprite delovno in testno bazo podatkov v načinu konfiguratorja. V njih odpremo konfiguracije. In v obeh zbirkah podatkov začnemo obdelovati primerjavo konfiguracije ("Konfiguracija - Primerjaj konfiguracije ..."). POMEMBNO: v obeh zbirkah podatkov je izbira konfiguracij enaka:

Poleg tega ga shranimo na naslednji način: v delovno bazo podatkov (kjer je konfiguracija PRED posodobitvijo) - v datoteko s končnico "staro" in v testno bazo podatkov (kjer je konfiguracija PO posodobitvi) - v datoteko z konča "novo".

2. Vključitev izgubljenih sprememb v posodobljeno konfiguracijo. Preidimo na ključno fazo metode. Ker je to bistvo, je za malo razlage dogajanja nekaj materiala. Na platformi 1C 7.7 je bila datoteka za posodobitev popolna konfiguracija. In posodobitev v 1C 7.7 je bila sestavljena iz nalaganja nove konfiguracije in reorganizacije baze podatkov za to konfiguracijo. Tako sta bili konfiguracija in posodobitev v bistvu ista datoteka md. Za razliko od platforme 1C 7.7 se na platformi 1C 8.x: konfiguracija prenaša preko cf datoteke, posodobitev pa preko cfu datoteke. Razlika med tema datotekama je v tem, da datoteka cf vsebuje vse konfiguracijske objekte, datoteka cfu pa samo tiste, ki so spremenjeni s to posodobitvijo. Tako so pri posodabljanju na platformi 1C 8.x prizadeti samo tisti konfiguracijski objekti, ki so se dejansko spremenili v novi izdaji. Posledično, če smo tak predmet spremenili mi, bo po posodobitvi popolnoma nadomeščen s standardnim in v njem bomo morali ponoviti spremembe, ki jih je imel pred posodobitvijo, tako da bo ta objekt vseboval naše spremembe in spremembe nove izdaje, hkrati . Če pa posodobitev ni vplivala na konfiguracijski objekt, ki smo ga spremenili, bodo naše spremembe ostale v njem po posodobitvi. Za lažje razumevanje ga bom prikazal v obliki diagrama:

Ta diagram prikazuje nekaj tipičnih konfiguracij v procesu spreminjanja in posodabljanja. Nizi so njegovi predmeti (dokumenti, imeniki, obdelava itd.). Prva (pod številko I) je le tipična konfiguracija: vsi objekti brez sprememb. Nato pod številko II že vidimo tipično spremenjeno konfiguracijo: nekateri objekti so bili spremenjeni in ti spremenjeni objekti so označeni z rdečo barvo. Številka III je naslednja posodobitev za standardno konfiguracijo: dejansko vsebuje le objekte, na katere vplivajo spremembe v novi izdaji, ki so označeni z zeleno, vendar sem zaradi jasnosti dokončal tudi vse druge objekte. Dobiti moramo posodobljeno standardno konfiguracijo (prikazano na diagramu I), vendar s spremembami diagramov II in sheme III. Vklopljeno v tem primeru- ta končna konfiguracija je prikazana kot številka IV in vsebuje en predmet, ki smo ga spremenili mi in posodobitev. Preostali predmeti, ki smo jih spremenili, so očitno ostali nedotaknjeni s to posodobitvijo. Zdaj je vprašanje: kako narediti VSE naše spremembe v objektu, na katerega je vplivala posodobitev? Očitno moramo narediti dva koraka: prvič, poiskati ta predmet, in drugič, najti mesta v njem, kjer bi morale biti naše spremembe, in jih znova narediti. Ugotavljam, da je seveda lahko več takih predmetov in jih morate vse najti in popraviti. Pa pojdimo na ta zadnji korak posodobitve. Vklopljeno ta trenutek, moramo imeti testno bazo odprto v načinu konfiguratorja. Če je tam še vedno odprt rezultat obdelave primerjave konfiguracij ali kakšno drugo okno, jih bomo vsa zaprli, da ne pride do zmede. Nato odpremo delujočo bazo v načinu konfiguratorja (možno jo je bilo zapreti med posodabljanjem testne baze) in tam začnemo primerjati konfiguracije. Opis zadnjih dveh korakov (najdi in popravi) bom postavil v ločene pododstavke:

2.1. Poiščite predmet s spremembami, ki jih je posodobitev izbrisala. Čas je, da se spomnimo datotek txt s končnicami star/novo. Pravzaprav te datoteke odražajo vse spremembe konfiguracije (v primerjavi s standardno) PRED in PO posodobitvi. Tako, če smo kakšno spremembo prepisali s posodobitvijo, bo ta le v datoteki “Comparison Report_old.txt”. To pomeni, da se iskanje potrebnih konfiguracijskih objektov zmanjša na primerjavo teh dveh datotek. Te datoteke bomo primerjali z uporabo upravitelj datotek Total Commander in njegova vgrajena orodja. Mislim, da tukaj ni treba posebej razlagati, kaj je Total Commander, kje ga dobiti in kako ga uporabljati... Bom pa tukaj na kratko opisal potrebne faze njegove uporabe. Torej, zaženimo Total Commander. Če je jezik vmesnika angleščina (glavni meni in tako naprej), ga lahko spremenite v ruščino: »Konfiguracija - Možnosti ...«, v pogovornem oknu izberite razdelek »Jezik« v levem stolpcu, poiščite/izberite »Rusko (rusko)« na seznamu in kliknite »V redu«. Nato prek Total Commanderja poiščemo txt-datoteke poročil, jih izberemo (»Vstavi« ali »desni klik«) in začnemo primerjati datoteke: »Datoteke - Primerjaj po vsebini ...« (v angleški vmesnik: "Datoteke - Primerjaj po vsebini ..."). V oknu, ki se odpre, je vsebina datotek prikazana levo/desno; gumbi »Naslednja razlika«/»Prejšnja razlika« vam omogočajo iskanje razlik. To orodje vam bo omogočilo hitro iskanje predmetov, ki nas zanimajo.

Komentiraj: lahko se zgodi tudi obratna situacija - PO posodobitvi se v konfiguraciji pojavijo razlike, ki jih PRED posodobitvijo ni bilo. To pomeni, da je izdaja posodobitve odstranila ustrezne objekte iz konfiguracije. Načeloma lahko te objekte preprosto preskočimo v naših popravkih, saj na teh objektih ni bilo sprememb.

2.2. Spreminjanje posodobljenih predmetov. Ko najdemo objekt s prepisanimi spremembami, moramo ugotoviti, kje točno so bile te spremembe: v modulu (programsko besedilo), pogovornem oknu (na obrazcu) ali drugih nastavitvah. Tu bom ločil dva primera: spremembo modula in vse ostale spremembe. In poglejmo ta dva primera ločeno.

2.2.1. Spremembe, ki jih je posodobitev izbrisala, so bile v modulu. Pravzaprav je to glavni primer (to se dogaja veliko pogosteje) in ravno ta primer je v našem primeru: sprememba je bila izbrisana v modulu “Obračun DDV”. Kot smo že omenili zgoraj, imamo v konfiguratorju Work Base odprto okno za primerjavo konfiguracije. Tam iščemo predmet, ki ga potrebujemo. Pravzaprav je njegov položaj v konfiguracijskem drevesu opisan v naši besedilni datoteki, in sicer: "GeneralModule.DDV Accounting.Module". Točno to iščemo v primerjalnem oknu. Drevo podrejenosti razširimo, dokler ne najdemo želenega modula - na levem robu nasproti njega mora biti zeleni svinčnik, ki označuje, da je bil predmet spremenjen v primerjavi s konfiguracijo dobavitelja. Z desno miškino tipko kliknite najdeno vrstico in izberite »Prikaži razlike v modulih ...«:

Po tem se odpre primerjalno okno modulov:

Tukaj na vrhu so označeni postopkov in funkcije, v katerem so spremembe (v našem primeru je to en postopek »Izhodni račun v tabelarnem dokumentu«), v spodnjem delu pa besedila izbranega postopka ali funkcije z označenimi spremembami. Te spremembe moramo prenesti v našo testno zbirko podatkov. Vendar to ne odstrani sprememb iz posodobitve. To lahko avtomatizirate na naslednji način. Postavite kazalec v spodnji levi del (kjer se besedilo izbranega postopka z našimi spremembami) in zaporedno pritisnite Ctrl+A (izberi vse) in Ctrl+C (kopiraj izbor v odložišče). Nato ustvarimo datoteko s kodnim imenom "old_izm.txt", jo odpremo urejevalnik besedil in pritisnite Ctrl+V (prilepite vsebino medpomnilnika). Enako naredimo za spodnji desni del (kjer je besedilo izbranega postopka iz standardne konfiguracije neposodobljene izdaje) - posledično ustvarimo datoteko s kodnim imenom "old_type.txt". Po tem gremo v konfigurator testne baze (mora biti odprt drug ob drugem, vendar brez oken v notranjosti, da se ne zamenjamo v teh dveh konfiguratorjih) - in v konfiguraciji iščemo svoj modul (v tem primeru to je “SplošniModul.Obračun DDV.Modul”) in v njem potreben postopek (v tem primeru je to “Izhodni račun v tabelarnem dokumentu”): izberite vse in kopirajte v novega besedilna datoteka s kodnim imenom "new_type.txt". Tako imamo tri datoteke ("old_izm.txt", "old_type.txt", "new_type.txt"), na podlagi katerih moramo ustvariti četrto datoteko - "new_izm.txt". Ta četrta datoteka mora vsebovati naše spremembe, vendar ob upoštevanju posodobitve. Oblikovali jo bomo zaporedno s primerjavo obstoječih treh datotek. Najprej ugotovimo, ali so v tem postopku sledi posodobitvenih sprememb? Da bi to naredili, primerjamo datoteki "old_type.txt" in "new_type.txt" z uporabo programa Total Commander (glejte zgoraj). Če primerjava pokaže, da sta datoteki enaki ali obstaja razlika v številu presledkov ali zavihkov, to pomeni, da smo imeli s to spremembo srečo in lahko spremembe preprosto prenesete s kopiranjem vsebine datoteke »old_izm.txt ” in ga prilepite v odprti modul testne baze podatkov, pri čemer najprej izbrišete ustrezni postopek (z drugimi besedami, zamenjate ga). Pri tem je pomembno skrbno spremljati prostore pred in po posegu, da pri nadaljnji primerjavi ne bo odveč: to seveda ne bo vplivalo na funkcionalnost, bo pa nekoliko otežilo preverjanje. Če je primerjava »old_type.txt« in »new_type.txt« pokazala, da obstajajo resnične razlike, to pomeni, da ta postopek vsebuje naše spremembe in spremembe iz posodobitve. Za poenostavitev naloge prenosa: najprej lahko vizualno ocenite, katere spremembe so večje - od posodobitve ali naše. Da bi to naredili, ponovno prek Total Commanderja zaporedno primerjamo »old_type.txt« z »new_type.txt« in »old_izm.txt«. In pogledamo, kje je več sprememb: v primerjavi »old_type.txt« in »new_type.txt« ali v primerjavi »old_type.txt« in »old_izm.txt«. Če je v prvi primerjavi več sprememb (posodobitev je bolj spremenila funkcijo), potem posodobljeno datoteko lažje popravimo z našimi spremembami, torej spremenimo »new_type.txt«. Recimo temu prvi primer izvajanja sprememb. Če je v drugi primerjavi več sprememb (mi smo imeli več sprememb), potem našo datoteko lažje popravimo tako, da naredimo posodobitvene spremembe, torej spremenimo “old_izm.txt”. Recimo temu drugi primer izvajanja sprememb. Zdaj pa kako natančno prenesti spremembe hitro in natančno. Za to ustvarimo četrto datoteko in jo po dogovoru poimenujemo “new_izm.txt”. Ob upoštevanju optimizacije prenosa popravkov v to datoteko kopiramo vsebino »new_type.txt« ali »old_izm.txt« (oziroma za prvi ali drugi primer spremembe).
Zdaj odprite dve okni za primerjavo datotek hkrati. Za prvi primer spreminjanja so to primerjave za datoteki "new_izm.txt"/"old_izm.txt" in "old_type.txt"/"old_izm.txt". Za drugi primer so to primerjave datotek "new_izm.txt"/"new_type.txt" in "old_type.txt"/"new_type.txt". V primerjalnem oknu je gumb "Uredi": kliknite ga v primerjavi prvega para. Zdaj pa razložimo, kaj vidimo. V prvem paru primerjav so vidni objekti iz naše spremembe in posodobitve. Odvisno od našega primera moramo prenesti samo svoje spremembe ali samo posodobitve. V drugem primerjalnem oknu so vidne samo tiste spremembe, ki jih moramo prenesti. Če ste pozorni - v obeh primerih je druga datoteka tako prve kot druge primerjave enaka. Zato se osredotočimo na vrstice v tej datoteki in glede na vrstice v drugi primerjavi naredimo spremembe v prvem primerjalnem oknu: to nam bo omogočil pritisk na gumb »Uredi«.

Zaradi jasnosti grafično ponazorimo dejanja med prenosom v prvem primeru (spremenimo posodobljeno datoteko s svojimi spremembami):

Dejanja v drugem primeru so popolnoma podobna in načelo delovanja je popolnoma enako.

Najtežji in najbolj neprijeten primer je, ko so naše spremembe in posodobitve sprememb na ENEM mestu. To pomeni, da je v resnici prišlo do dveh sprememb v enem segmentu kode. V tem primeru je potrebna intervencija programerja. Prav tako je potrebna intervencija programerja, vendar v manjši meri, če na primer posodobitev spremeni imena spremenljivk, ki so uporabljene v naših spremembah. Omeniti velja tudi, da je v datoteki "old_type.txt" ali "old_izm.txt" morda prazne vrstice- to so "sledi" naših sprememb. Prenesti jih morate tako, da niso v končni datoteki. To ne vpliva na funkcionalnost, bo pa pri nadaljnjih primerjavah (z naknadnimi posodobitvami) nekoliko otežilo analizo dejanj. Torej, potem ko smo ustvarili četrto datoteko in prenesli vse spremembe, moramo njeno vsebino kopirati v konfiguracijo. V konfiguratorju testne baze podatkov je treba zahtevani modul odpreti na novem mestu: izbrišite obstoječi postopek in vstavite vsebino našega končna datoteka, ob upoštevanju vseh presledkov med prejšnjimi/naslednjimi funkcijami. Tako smo spremembe prenesli na EN postopek najdenega objekta. Mi (slika 6) imamo res samo en postopek. Če je takih postopkov več, je treba opisane korake izvesti za vsakega. Če je postopek nov (samo v levi polovici), ga preprosto dodajte ustreznemu modulu v testni bazi (za pravilnost nadaljnje primerjave morate ohraniti vrstni red postopkov, kot v ustreznem modulu delovnega baze podatkov, kjer je še stara izdaja).

2.2.2. Spremembe, ki jih je posodobitev prepisala, NISO bile v modulu. Za prenos takšnih sprememb takšna primerjava nikakor ne bo poenostavila dela, zato se spremembe prenašajo preprosto z vizualno primerjavo objektov v delovni in testni bazi podatkov.

Tako prenesemo spremembe za vsak objekt, kjer so bile naše spremembe prepisane s posodobitvijo. Da preverimo, kako pravilno smo prenesli vse spremembe, konfiguracijo shranimo v testno bazo, primerjavo konfiguracij naložimo v datoteko “Comparison Report_new2.txt” in jo primerjamo z datoteko “Comparison Report_old.txt”. Če je vse v redu, se prikaže sporočilo »Datoteke so enake«. Če so bili s posodobitvijo izbrisani nekateri predmeti, bodo v razliki, če so spremembe pravilno prenesene, vidni samo ti objekti. Pravilno bi bilo, če bi bili v primerjavi vidni le presledki/prazne vrstice/zavihki, vendar je v tem primeru bolje, da to počistite in dobite sporočilo »Datoteke so enake«. Tako po shranitvi sprememb v testno bazo primerjavo naložimo v datoteko in jo primerjamo s spremembami v stari izdaji – to ponavljamo, dokler primerjava ne pokaže, da smo prenesli vse zahtevane spremembe.

3. Posodobljeno konfiguracijo prenesemo iz testne v delujočo bazo. V prejšnjih fazah smo posodobili testno bazo na zadnjo izdajo, preverili in prenesli potrebne spremembe ter shranili nastalo konfiguracijo. Zdaj ga naložimo v datoteko cf in naložimo v delujočo bazo podatkov. Pred prenosom morate narediti kopijo delujoče baze podatkov in odstraniti konfiguracijo iz podpore. VSE. Uporabniki so bili v "leru" le na začetku, ko smo bazo razbremenili, in na koncu, ko smo bazo ponovno razbremenili in naložili konfiguracijo.

Ta posodobitev je v celoti dokončana.

Izvirni članek je na spletni strani

Nestandardna konfiguracija 1C je, ko: 1) je programer neodvisno napisal konfiguracijo 1C iz nič, 2) je bila konfiguracija 1C standardna, vendar so ji bile dodane spremembe, tudi če je bila dodana ena lastnost.

V tem članku bomo preučili, kako je potrebno pravilno posodobiti konfiguracije 1C, pa tudi več tehnik za mehko spreminjanje standardnih konfiguracij, tj. pravilno spremembo, ki ne bo vplivala na možnost nadaljnjega posodabljanja.

Za kakršno koli spremembo standardne konfiguracije 1C je potrebno odkleniti spremembo standardne konfiguracije 1C in v nekaterih primerih "odstraniti iz podpore".

V najbolj optimalni možnosti posodobitve je mogoče konfiguracijo 1C popolnoma posodobiti avtomatski način, je to mogoče, če ne dovolimo sprememb konfiguracije. Nemalokrat je treba vključiti spremembe konfiguracije, saj je treba aplikativne rešitve prilagoditi poslovnim zahtevam naročnika, na to možnost se bomo osredotočili.

Pred posodobitvijo je zelo priporočljivo narediti varnostno kopijo bazo podatkov, lahko to storite prek menija Administracija/Naloži informacijsko bazo.

Obstajata 2 možnosti posodobitve: a) Posodobitev 1C prek podpore (pokličite prek pogovornega okna Konfiguracija/Podpora/Posodobi konfiguracijo) in b) prek primerjave z združitvijo s konfiguracijo iz datoteke. Treba je plačati Posebna pozornost, da je razlika med tema dvema točkama v tem, da se v prvem primeru posodobita tako glavna konfiguracija kot konfiguracija dobavitelja, pri primerjavi združevanja konfiguracij pa se posodobi samo glavna konfiguracija, konfiguracija dobavitelja ostane stara. Zato je najbolj priporočljiva možnost posodobitev prek posodobitve konfiguracije. Za posodabljanje prek konfiguracijske podpore se uporabljajo dobaviteljeve dostavne datoteke CF ali CFU, ki jih je mogoče najti z iskanjem, v imeniku predlog, tako da navedete pot na internetu ali neposredno navedete pot do zahtevano datoteko na vašem trdem disku.

Pri posodabljanju konfiguracije 1C brez možnosti spreminjanja se posodobitev po izbiri datoteke posodobitve izvede samodejno, če je v konfiguraciji omogočena možnost spreminjanja, nato pa se po izbiri datoteke posodobitve prikaže okno za primerjavo konfiguracije. V tem dialogu lahko vidimo, kako nam sistem ponuja posodobitev naše nestandardne konfiguracije 1C. Na dnu pogovornega okna je ustrezna legenda za statuse objektov: »Statusi za korespondence objektov« označujejo primerjavo »Glavne konfiguracije« in »Nove konfiguracije«, »Statusi za zgodovino objektov« označujejo primerjavo konfiguracijskih objektov z objekti " Stara konfiguracija dobavitelj«.

S potrditvijo polj ob objektih lahko izberete, ali se bo trenutni konfiguracijski objekt spremenil ali ostal star ter kako spremeniti objekt. V meniju z dejanji lahko potrdite polja za podsisteme (to je uporabno, če konfiguracijo podpira več dobaviteljev). Tudi v tem meniju je možno določiti prioriteto združevanja za vse objekte hkrati, sistem ima višjo prioriteto konfiguracijo dobavitelja. Nastavitve filtra nam omogočajo, da določimo, katere konfiguracijske objekte naj prikažemo, da lahko podrobno določimo način združevanja. Obstaja več standardnih predlog filtrov, določite pa lahko tudi filtre za vsak par konfiguracij, ki jih primerjate. Možno je nastaviti potrditveno polje »Prikaži samo dvakrat spremenjene lastnosti« v nastavitvah »Filter«, kar vam bo omogočilo filtriranje predmetov, katerih posodobitev ni povzročila konfliktov med spremembami dobavitelja in spremembami teh predmetov:

Rezultat bo torej seznam objektov, ki so bili dvakrat spremenjeni med finalizacijo standardne konfiguracije in v konfiguraciji novega dobavitelja. Če se strinjate s posodobitvijo, bodo predhodno narejene izboljšave teh predmetov izgubljene. Zato se je za vsak objekt potrebno odločiti, kako ga bomo posodobili. Na tej stopnji je treba opraviti predhodno primerjavo izključno zaradi kasnejšega zmanjšanja količine dela. Ocena ni točna in hitra - "na oko". Če je v novi konfiguraciji dobavitelja v objektu več sprememb, pustimo instanco objekta dobavitelja. Pustite kljukico. Nato boste morali prenesti spremembe iz delovne konfiguracije. Če je v objektu v delovni konfiguraciji več sprememb, pustimo primerek delujočega konfiguracijskega objekta. Počistite polje. Nato boste morali preseliti spremembe iz konfiguracije ponudnika. Z moduli lahko naredite stvari nekoliko drugače, ker ... Možna je proceduralna primerjava modulov.

Tisti. če se v naši konfiguraciji 1C in v konfiguraciji dobavitelja spremenijo različni postopki modulov, se s pravilnim preverjanjem polj rešimo ročnega prenosa sprememb kode. Če želite priti do tega, morate klikniti gumb v obliki povečevalnega stekla poleg imena načina za združevanje modulov:

Pri prikazu menija dejanj na predmetu (na primer s pritiskom na desni gumb miško) lahko prikličemo poročilo o primerjavi objektov.

Če želite potrditi posodobitev 1C, morate izbrati točko menija Konfiguracija/Posodobi konfiguracijo baze podatkov.

Če želite zavrniti posodobitev 1C, morate izbrati točko menija Konfiguracija/Nazaj na konfiguracijo DB.

Več pravil, ki poenostavljajo prihodnje posodabljanje konfiguracij 1C:

Osnovno pravilo za posodobitev 1C: dodati morate nove predmete, ker ... Pri posodabljanju sistem ne vpliva na nove objekte

Pri spreminjanju besedil modulov je priporočljivo dodati tudi svoje nove postopke in funkcije ter priklicati svoje nove iz obstoječih

Z uporabo naročnin na dogodke lahko spremenite standardne mehanizme, ne da bi spremenili standardno kodo

Uporaba standardne funkcionalnosti konfiguracije

Programsko ustvarjanje elementov obrazca (v dogodku FormCreationOnServer)

Hvala vam!

Osebna izkušnja: kako hitro in stroškovno učinkovito posodobiti spremenjeno konfiguracijo

Posodabljanje konfiguracije za več izdaj hkrati je zelo nevarno. Dejstvo je, da se po vsaki posodobitvi konfiguracije zažene posodobitev informacijskih baz v načinu 1C:Enterprise. Če torej posodobite samo zadnjo izdajo, informacijske baze morda ne bodo ustrezale najnovejšo konfiguracijo. V članku Dmitrij Rudakov, specialist pri CJSC Siberian Agrarian Group, deli svoje osebne izkušnje pri hkratnem posodabljanju konfiguracije za 12 izdaj.

Preverjanje načina spreminjanja konfiguracije

Predstavljajmo si takšno situacijo. Razvijalci »Manufacturing Enterprise Management« (v nadaljevanju PPE) so v izdaji 1 (številke izdaj v nadaljevanju so dodeljene pogojno) dodelili dimenziji (indikatorju) računskega registra tip »Directory Link.Individual« z imenom »Individual« . V izdaji 2 so dodali še eno dimenzijo - “Zaposleni” z vrsto “DirectoryLink.Employees”. Ko zaženete "1C:Enterprise", se vključi procesiranje, ki zapolni dimenzijo "Zaposleni" na način, ki ustreza dimenziji za "Posameznik". In potem so v izdaji 3 razvijalci 1C odstranili dimenzijo »Posameznik« in pustili samo »Zaposleni«. Če posodobite konfiguracijo iz izdaje 1 takoj na izdajo 3, lahko počistite celoten register izračuna.

In če je konfiguracija podprta z možnostjo spremembe in se regulirano poročanje generira v isti bazi podatkov, potem je treba posodobiti konfiguracijo za vsako izdajo, kar je lahko zelo drago v delovnih urah. Na primer, posodobitev močno spremenjenega "UPP" za 1 izdajo lahko traja 30 ur delovnega časa izkušenega strokovnjaka.

Zato morate pred začetkom posodabljanja ugotoviti: ali delate v standardni konfiguraciji z možnostjo spreminjanja ali v konfiguraciji brez možnosti spreminjanja? Če želite to narediti, pojdite v konfigurator, kjer v meniju sledite korakom »Konfiguracija - Podpora - Nastavitve podpore«.

Slika 1. Priklic nastavitvenega okna za podporo konfiguracije

Če je nastavljeno na »Vključena podpora«, je ta konfiguracija tipična, če pa je »Možnost spreminjanja omogočena«, je bila konfiguracija najverjetneje spremenjena (vsaj takšna možnost je vključena). Tretje stanje je "Konfiguracija ni več podprta." Različna stanja konfiguracije so prikazana na slikah 2, 3, 4.

riž. 2. Standardna konfiguracija brez možnosti sprememb

riž. 3. Tipična konfiguracija z omogočeno možnostjo spreminjanja

riž. 4. Zastarela konfiguracija

Algoritem za posodabljanje spremenjenih konfiguracij

Pred kratkim sem se soočil z nalogo posodobitve spremenjene konfiguracije Trade Management, izdaja 10.3.13.2. Konfiguracija je bila spremenjena zaradi integracije z industrijsko rešitvijo "BIT: Automotive Service Management 8" in se je v dveh letih nenehno izboljševala. Zdaj je bilo treba konfiguracijo posodobiti na izdajo 10.3.25.1, to je 12 izdaj. Celoten postopek posodobitve sem razdelil na več stopenj.

Faza 1. Ocena stroškov in časovnega okvira postopka posodobitve

Pred začetkom samostojnega dela sem se odločil za neodvisno oceno strokovnjakov s tega področja. Edino podjetje, ki ima možnost posodabljanja spremenjenih konfiguracij z avtomatiziranimi metodami, je 1C-IzhTiSi LLC. Obrnil sem se na strokovnjake tega podjetja z zahtevo, da ocenijo stroške posodobitve moje konfiguracije. Za oceno časa in stroškov dela sem podal trenutna konfiguracija, ki ga je treba posodobiti. Dan kasneje sem prejel pismo s poročilom.

Poročilo o rezultatih ocene stroškov in časa posodobitve konfiguracije:

Konfiguracija: Trade Management, izdaja 10.3
Trenutna verzija konfiguracija: 10.3.13.2
Posodobitev na različico: 10.3.25.1
Število posodobljenih modulov: 1.847
Število krmilnih sprostitev: 8

Rezultati ocene so me presenetili, saj je na spletni strani podjetja navedena cena na delnico - 1000 rubljev. na posodobitev na izdajo. Komentar iz "1C-IzhtiSi":

»Cena posodobitve za vsako zamujeno izdajo je trenutno v teku, tako da cena ne presega 1000 rubljev, vendar se končna cena storitev določi z oceno stroškov dela za posodobitev in je lahko manj kot 1000 rubljev na izdajo.«

Pojasnil sem tudi, kako so bile izbrane izdaje, potrebne za posodobitev. Kot odgovor na moje vprašanje sem prejel posnetek zaslona, ​​na katerem je bilo to jasno prikazano (slika 5). Stolpec Številka različice označuje različico konfiguracije, na katero morate nadgraditi. Stolpec »Nadgradnja različice« označuje, iz katere izdaje je možna nadgradnja. Kot rezultat ocene se je število potrebnih posodobitev zmanjšalo na 9.

riž. 5. Izbira izdaj, ki jih je treba uporabiti za pravilno posodobitev konfiguracije

Po preučitvi poročila 1C-IzhTiS sem izračunal stroške osebnega časa za enako količino dela. Vsaka posodobitev mi vzame približno 6 ur. Skupni časovni strošek je torej 56 (9x6) delovnih ur, torej približno sedem delovnih dni. Poleg tega obstaja možnost, da se po posodobitvi odkrijejo nekatere pomanjkljivosti: na primer, uporabnik se bo pritožil, da so bile spremembe konfiguracije, ki jih je potreboval, izgubljene, nato pa se bodo časovni stroški resno povečali. Medtem strokovnjaki podjetja 1C-IzhTiS ponujajo celotno količino dela v treh do štirih delovnih dneh. Zato sem se odločil za uporabo njihovih storitev.

Zdaj bom na kratko razložil, kaj točno je bilo spremenjeno v konfiguraciji.

Močno spremenjeni predmeti. To so objekti, pri katerih je spremenjenih veliko značilnih lastnosti. Prilagoditve so kompleksne. Podrobnosti o predmetu so bile dodane tabelarnega dela, prikazan na obrazcu objekta in obrazcu seznama. Dodani so bili obdelovalci za dodane podrobnosti v obrazcih. Spremenjen je standardni mehanizem knjiženja dokumenta ali evidentiranja niza gibanj za register.

Močno spremenjeni dokumenti:
"Naročilo dobavitelju";
"Gibanje blaga";
"Zahteva-račun";
"Prejem blaga in storitev."

Močno spremenjeni registri:
"Pošiljke blaga v skladiščih";
"Blago v skladiščih."

Bistveno spremenjeni objekti. Objekti, pri katerih so bili dodani detajli, spremenjene bodisi obrazci objekta bodisi moduli objekta (knjiženje dokumenta je praviloma netipično).
Dokument "Nalog za prejem gotovine";
Register informacij "Sestavni deli";
Register informacij "Odpisano blago";
Splošni moduli.

Nekoliko spremenjeni objekti. Spremenjeni so bili le obrazci v objektih in dodani detajli.

Imeniki:
"Vrste nomenklature";
"Pogodbeni sporazumi";
"Nasprotne stranke";
"Nomenklatura";
"Vrste cen artiklov";
"Številni informacijski registri."

V razdelku »Splošno« so spremenjene naročnine na dogodke, postavitve, vloge in splošni moduli. Skoraj vse se je spremenilo z odločitvijo industrije.

Faza 2. Odstranjevanje zaupnih informacij

Preden zaposlenim v 1C-IzhTiS zagotovite informacijsko bazo za testiranje, je treba iz nje izbrisati zaupne informacije. V takšnih primerih 1C priporoča uporabo obdelave »Sprememba zaupnih podatkov«, ki ni zelo razširjena.

Obdelava »Sprememba zaupnih informacij« je namenjena selektivnemu spreminjanju ali čiščenju informacij v informacijski bazi.Zdravljenje se lahko uporablja za pripravo informacijsko bazo pred oddajo na testiranje, kjer je treba nekatere informacije skriti (počistiti, spremeniti).

Obdelava ChangeConfidentialInformation.epf je na disku ITS v imeniku 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. tudi to obdelavo lahko prenesete s povezave: http://its.1c.ru/db/metod81#content:1644:1.

Seveda so zaupni podatki v vsakem podjetju drugačni, vendar vas opozarjam na podatke, ki jih je najverjetneje treba spremeniti:

  • Imeniki: Fizične osebe, Kontaktne osebe, Kontaktne osebe nasprotnih strank, Nasprotne stranke, Tipi cen.
  • Registri informacij: Podatki o potnem listu posameznik, Polno ime Posameznik.

Vaš seznam bo verjetno daljši, vendar so to najpogostejši podatki. Njihovo spreminjanje verjetno ne bo vplivalo na zmožnost testiranja vaše podatkovne baze. S skupinsko obdelavo lahko izbrišete tudi vse tiste objekte, s katerimi storitveno podjetje ne bi smelo delati.

3. korak: Pridobivanje rezultatov posodobitve

Tri dni pozneje sem dobil datoteke cf in izčrpna navodila za njihovo namestitev. Za nadzorne izdaje so na voljo datoteke cf, ki jih ni mogoče uporabiti za uporabniško delo, saj se v njih posodobijo le metapodatki. Namenjeni so le pravilnemu posodabljanju na najnovejšo različico.

Na podlagi rezultatov dela lahko rečem, da so bile vse spremembe v konfiguraciji shranjene, vsi objekti, ki so bili spremenjeni, so ohranili svoje lastnosti in razlike od standardne konfiguracije. Med delovanjem nobeden od uporabnikov ni poročal o izgubi kakršnih koli sprememb.

Kot rezultat posodobitve sem določil dve majhni nalogi, ki jih moram rešiti sam.

najprej Ker se posodobitev izvaja z mehanizmom »Primerjaj, združi«, je konfiguracija baze dejansko posodobljena in posodobljena pravilno, brez tehničnih tveganj zaradi upoštevanja kontrolnih izpustov. Vendar konfiguracija ponudnika ni posodobljena. Seveda bo tehnično kompetenten strokovnjak zlahka dopolnil to delo, vendar sem prosil 1C-IzhTiSi, da pošlje več popolna navodila s posodobitvijo. V skladu z njim lahko posodobitev izvede tudi neizkušen strokovnjak.

drugič Zaradi posodobitve ostanejo vsi objekti na podpori z možnostjo spremembe, kar je lahko tudi posredna slabost. Če morate te storitve uporabljati hkrati, morate vse objekte vrniti na podporo. Zaenkrat lahko to storim samo z iskanjem po vseh metapodatkovnih objektih. Na žalost se ta postopek trenutno izvaja ročno, v prihodnosti pa bo avtomatiziran.

Poleg obeh omenjenih nalog je bila odkrita ena majhna napaka, ki načeloma ne vpliva na kakovost posodobitve in se redko pojavi. Kot rezultat posodobitve se vrstici kode prvotne in posodobljene konfiguracije vizualno ujemata, vendar so iz nekega razloga na koncu vrstic dodani presledki. To je slabost, ker nekoliko poveča količino spremenjene kode. In v primeru nadaljnjega ročna posodobitev bolje bi bilo, da takšnih delov kode ne bi bilo. Na sl. 6 prikazuje primer pred posodobitvijo, sl. 7 - primer po posodobitvi.