Selles modifitseeritud 1c 8.3 mittestandardse värskenduse juhendis ei kirjelda ma põhilisi asju, näiteks: kuidas avada konfiguraatorit, milline on andmebaasi konfiguratsioon, tarnija konfiguratsioon ja põhikonfiguratsioon. Sellest on palju kirjutatud ja selle teabe leiate Internetist iseseisvalt. Püüan kirjeldada värskendusprotsessi põhipunkte ja seda, millele peate tähelepanu pöörama.
Võtsin näitena ebatüüpilise raamatupidamise versiooni 3.0.51.22 ja näitan teile, kuidas seda versioonile 3.0.53.29 värskendada. Platvormi versioonil 8.3.10.2561 (vanematel platvormidel pole suurt vahet, võrdlusaken nägi enne lihtsalt veidi teistsugune välja).
Ütlen kohe, et seal on palju pilte ja vähe teksti. Minu arvates on lihtsam protsessi visuaalselt meelde jätta kui tekstimerd lugeda.

1. Kontrollige, kas andmebaasi konfiguratsioon ühtib hankija konfiguratsiooniga.

Selleks vajate

Kui vaste on olemas, võite julgelt liikuda 2. sammu juurde.

1a. Toe konfiguratsiooni seadistamine.

Kui teie andmebaasi versioon ja tarnija konfiguratsiooniversioon on erinevad, peate praeguse konfiguratsiooni kustutama sama menüü kaudu: konfiguratsioon - tugi - tugiseaded. Ja klõpsake nuppu "Väljuda toest".

Pärast "lühikest" ootamist eemaldame kõik ruudud. Noh, saate tühjendada märkeruudu „Salvesta sätted automaatselt”. Ja klõpsake käsul Käita.

Selle tulemusena saame toetatud konfiguratsiooni samade andmebaasi versioonidega.

2. Uuenda andmebaasi.

Nüüd saate jätkata värskendusega.

Ütlen kohe ära, et värskendamist tuleks teha AINULT menüüst “Konfiguratsioon” – “Tugi” – “Uuenda konfiguratsiooni...”.
Sa EI SAA kasutada “Võrdle, ühenda failist konfiguratsiooniga...”!!! Selle mehhanismi kasutamisel peate järgmisel värskendamisel minema 1a sammu juurde. Seetõttu ärgem tehkem seda ja tekitagem endale (või järgmisel korral andmebaasi uuendajale) asjatuid probleeme.

Järgmisena valige värskendusfail.
Tahaksin rääkida värskendamisest pärast mitut väljalaset. 1C ei soovita CF-faile värskendada, hüpata korraga läbi mitme väljalase. Seda tuleb teha järjepidevalt. Teoreetiliselt on see õige.
Selgitan, miks seda ei soovitata. Kui programmeerijad soovivad rekvisiite kustutada, määravad nad sellele esmalt eesliite “kustuta”, seejärel kustutavad pärast mitut väljalaset selle. Ja nad saavad sellelt teavet mõnes väljaandes edastada. Selle versiooni vahelejätmisel võite andmeid kaotada. Kuid praktikas oli mul 10-aastase 1C andmebaasidega töötamise ajal üks selline juhtum. Kui arendajad otsustasid mingil põhjusel andmed loendist kataloogi üle kanda. Minu jaoks see aga millegi kriitilisega ei lõppenud. Kirjutasin lihtsa töötluse, mis viis need andmed arhiivist praegusesse andmebaasi. Uuendusi teha polnud vaja.
Võite mind kividega loopida, kuid ma uuendan andmebaasi alati mitme väljalase cf-failide kaudu.
Nii et klõpsasime värskendusel, ilmus teade, mis teavitab meid, millisele versioonile värskendus tehakse. Klõpsame OK.

Ootame objektide võrdlemise toimumist.
Järgmisena peame allosas olevast loendist valima "näita ainult kaks korda muudetud omadusi".

Tahan ka öelda, et vanade versioonide järgi oli see enne märkeruut.

Seega näeme nüüd palju vähem objekte.

Kui teie oma on tühi, siis on teil uskumatult vedanud ja võite julgelt vajutada nuppu "Käivita" ja lugeda värskenduse lõpetatuks. Noh, kõik pole siin nii lihtne, nii et ma käsitlen põhiobjekte.

Esimene asi, mida ma tahan öelda. Ärge mingil juhul lülitage liitmisrežiimi. See peaks olema "Võta uuest tarnija konfiguratsioonist". Vastasel juhul jõuate MGR kommentaariga andmebaasi prügi hulka.
Ei mingeid nuppe "näita moodulite erinevusi...".!
Klõpsake mooduli kõrval olevat hammasrattaikooni

Avaneb aken, kus on palju muudatusi funktsioonides ja protseduurides.

Selleks, et mõista, millist funktsiooni muudatusi tehti, peame tegema andmebaasist koopia või salvestama konfiguratsiooni konfiguratsioonimenüü kaudu faili. Ja seejärel laadige see tühja andmebaasi. Järgmisena minge menüüsse "konfiguratsioon" ja klõpsake nuppu "Võrdle konfiguratsioone...".
Valige Võrdle põhikonfiguratsiooni tarnija konfiguratsiooniga.

Ja nüüd näete muudatusi jaotises "Näita moodulite erinevusi...". Sest me ei kavatse midagi muuta, me lihtsalt tahame näha, mis on muutunud.

Ja näeme, et funktsioonile "Slope" on lisatud koodijupp. Kõiki muudatusi saab vaadata sinistel nooltel klõpsates.

Pöördume tagasi värskendatud konfiguratsiooni juurde. Seal kasutasime moodulite kombineerimise režiimi sisenemiseks hammasrattaikooni. Järgmiseks märkige kõik ruudud... käsitsi... öeldes endale "aitäh" platvormi arendajatele :)

Leiame oma langusfunktsiooni. Muudetud elemendi leidmine. Loodan, et nüüd on selge, miks peate kõik lisatud koodid kommentaaridega eraldama - õigesti, et värskendamisel mitte arvata, kust see kood pärit on.
Klõpsake suurendusklaasi ikooni ja platvorm tõstab esile koodirea, kuhu peate selle teksti lisama.

Kopeerige see ülemisest aknast ja kleepige see alumisse aknasse.

Tehke seda kõigi moodulitega. Kui moodulit pole muudetud, nagu meie puhul valuutakataloogi puhul. Seadsime lihtsalt režiimiks "Võta uuest tarnija konfiguratsioonist" ja ÄRGE klõpsake hammasrattal (käigukasti kõrval ei tohiks olla rohelist linnukest, see tähendab, et kood võetakse täielikult uuest konfiguratsioonist ilma käsitsi konfiguratsioon).

Suurepärane. Nüüd, pärast kõigi objektide läbimist, saate tühjendada märkeruudu "salvesta sätted automaatselt" ja seejärel "käivita".

Kirjale “Põhikonfiguratsioonis on objekte, mida on võrreldes vana konfiguratsiooniga muudetud... Uuendamisel need objektid asendatakse! Kas teostada? Klõpsame julgelt JAH.

Järgmises aknas jätke märkeruudud nagu pildil näidatud. Ja ei midagi muud!!! Mõlemad märkeruudud peavad olema märgitud – "objekte redigeeritakse, säilitades samal ajal toe." Klõpsake nuppu OK.

Kõik. Mittestandardse 1c konfiguratsiooni värskendamine on lõpetatud.
See meetod ei ole mõeldud täiuslikuks, kuid ma arvan, et paljud inimesed teevad nendes sammudes vigu.
Muidugi pole ma teile kõike rääkinud, seal on veel palju lõkse. Kuid ma arvan, et 90% värskendustest saab neid juhiseid kasutades ohutult värskendada.

1C platvormi muudetud standardkonfiguratsioonide värskendamiseks on palju juhiseid. Seetõttu, et olemust mitte suurendada, ei kirjelda ma kogu protsessi täielikult. Lisaks eeldatakse, et see tekst on mõeldud inimesele, kes on juba muudetud konfiguratsioone värskendanud ja teab peamisi punkte ja lõkse. See meetod ainult lihtsustab seda protsessi, soovitades sisuliselt kasutada konfiguratsioonimuudatuste ja moodulite muudatuste automaatset võrdlemist tekstifailide võrdlemise tasemel. Selle lähenemisviisiga väheneb oluliselt "inimfaktoriga" seotud vigade (tähelepanematusest tingitud oluliste muudatuste "ülekirjutamine") tõenäosus.

IGA konfiguratsioonivärskendus algab teabeturbe mahalaadimisega. See on "kuldne reegel", seda tuleb alati meeles pidada, seda tuleb teha mis tahes meetodiga (isegi kui nad unustasid selle kohta öelda). Järgmisena saate minna kahel viisil: värskendada testandmebaasis või värskendada tootmisandmebaasi. Oluline punkt on siin järgmine: tavaliselt ei värskendata muudetud konfiguratsioone mitte iga versiooni jaoks (nagu seda saab hõlpsasti teha standardsete versioonidega), vaid mitme jaoks korraga, kuna see protsess on töömahukas. Esimene meetod (uuendus testandmebaasis) hõlmab värskenduse lõplikku ülekandmist töötavasse andmebaasi, laadides alla cf-faili. Sel juhul võivad ilmneda kustutatud üksikasjadega seotud vead (selle kohta leiate palju artikleid). Seetõttu on teatud riske, kuid värskendamise ajal (mis võib võtta terve päeva või isegi kauem) saavad kasutajad andmebaasi muutes ohutult töötada. Teise meetodi puhul (värskendus töötaval andmebaasil) need riskid kõrvaldatakse, kuid kogu uuenduse aja jooksul ei saa võtmekasutajad selles andmebaasis töötada. Foorumites on piisavalt arutlusi selle üle, milline meetod on hea ja kas tasub uuendust konfiguratsioonifaili kaudu üle kanda. Võin vaid öelda: minu kogemuse põhjal esimese meetodi kasutamisel selliseid vigu cf-faili laadimisel ei esinenud. Igal juhul saate andmebaasi taastada varukoopia abil. Siin käsitletakse esimest meetodit, kuid see ei mõjuta meetodi olemust ja soovi korral võite pakutud meetodi abil jätkata teise meetodi järgi.

Nii et pärast testandmebaasi juurutamist värske varukoopia abil teeme järjestikused väljalaskevärskendused uusimale. Pärast iga väljalaset käivitame konfiguratsioonimuudatuste salvestamiseks ja andmete ümberkorraldamiseks funktsiooni "Silumine". Kõigis dialoogiboksis klõpsake nuppu OK/Järgmine/Nõustu/Jah/Jätka...

Seega oleme uuendanud testbaasi konfiguratsiooni uusimale versioonile, kuid peame kontrollima, kas oleme mingeid muudatusi üle kirjutanud ja kui oleme need üle kirjutanud, peame need sellesse versiooni üle kandma. Nüüd algab lõbus, nii et ma kirjeldan seda samm-sammult. Igal sammul on selgitus: see tähendab, et kõigepealt kirjeldatakse olemust ja seejärel üksikasjalikum kirjeldus. Kui olemus on selge, võib kirjelduse ära jätta.

1. Konfiguratsioonimuudatused salvestame tekstifailidesse ENNE ja PÄRAST uuendust. Avage töö- ja testiandmebaasid režiimis Configurator. Avame neis olevad konfiguratsioonid. Ja mõlemas andmebaasis hakkame töötlema konfiguratsiooni võrdlust ("Configuration - Compare configurations..."). TÄHTIS: mõlemas andmebaasis on konfiguratsioonide valimine sama:

Lisaks salvestame selle järgmiselt: tööandmebaasi (kus konfiguratsioon ENNE värskendamist) - faili, mille lõpp on "vana" ja testandmebaasi (kus konfiguratsioon PÄRAST värskendamist) - faili koos lõppu "uus".

2. Kaotatud muudatuste kaasamine värskendatud konfiguratsiooni. Liigume edasi meetodi põhietapi juurde. Kuna see on põhipunkt, on toimuva väikeseks selgituseks veidi materjali. 1C 7.7 platvormil oli värskendusfail täielik konfiguratsioon. Ja 1C 7.7 värskendus seisnes uue konfiguratsiooni laadimises ja selle konfiguratsiooni jaoks andmebaasi ümberkorraldamises. Seega oli nii konfiguratsioon kui värskendus sisuliselt sama md-fail. Erinevalt platvormist 1C 7.7, platvormil 1C 8.x: konfiguratsioon edastatakse cf-faili ja värskendus cfu-faili kaudu. Nende failide erinevus seisneb selles, et cf-fail sisaldab kõiki konfiguratsiooniobjekte ja cfu-fail sisaldab ainult neid, mida see värskendus muudab. Seega mõjutab platvormi 1C 8.x värskendamine ainult neid konfiguratsiooniobjekte, mida uues versioonis tegelikult muudeti. Selle tulemusena, kui sellist objekti muutsime meie poolt, asendatakse see pärast värskendust täielikult standardse objektiga ja peame selles kordama muudatusi, mis sellel olid enne värskendust, nii et see objekt sisaldaks nii meie muudatused ja uue versiooni muudatused, samal ajal . Aga kui meie muudetud konfiguratsiooniobjekti värskendus ei mõjutanud, jäävad meie muudatused sellesse pärast värskendust alles. Et seda oleks lihtsam mõista, kujutan seda diagrammi kujul:

See diagramm näitab mõnda tüüpilist konfiguratsiooni muutmise ja värskendamise protsessis. Stringid on selle objektid (dokumendid, kataloogid, töötlemine jne). Esimene (numbri I all) on lihtsalt tüüpiline konfiguratsioon: kõik objektid ilma muudatusteta. Siis numbri II all näeme juba tüüpilist muudetud konfiguratsiooni: mõnda objekti on muudetud ja need muudetud objektid on tähistatud punasega. Number III on standardse konfiguratsiooni järgmine värskendus: tegelikult sisaldab see ainult uue versiooni muudatustest mõjutatud objekte, mis on tähistatud rohelisega, kuid selguse huvides olen lõpetanud ka kõik muud objektid. Ja me peame hankima värskendatud standardkonfiguratsiooni (näidatud diagrammil I), kuid muudatustega nii diagrammis II kui ka skeemis III. Selles näites on see lõplik konfiguratsioon näidatud numbrina IV ja see sisaldab ühte objekti, mida muutsime nii meie poolt kui ka värskendusega. Ülejäänud objektid, mida me muutsime, jäid sellest värskendusest ilmselgelt puutumata. Nüüd on küsimus: kuidas teha KÕIK meie muudatused objektis, mida värskendus mõjutas? Ilmselgelt peame tegema kaks sammu: esiteks leidma selle objekti ja teiseks leidma selles kohad, kus meie muudatused peaksid olema, ja tegema need uuesti. Märgin, et loomulikult võib selliseid objekte olla mitu ja peate need kõik üles leidma ja parandama. Liigume siis värskenduse viimase etapi juurde. Sel hetkel peaks meil olema konfiguraatori režiimis avatud testandmebaas. Kui konfiguratsioonide võrdluse töötlemise tulemus või mõni muu aken on seal endiselt avatud, sulgeme need kõik, et mitte segadusse sattuda. Järgmiseks avame Configurator režiimis töötava andmebaasi (testandmebaasi uuendamise ajal oli võimalik sulgeda) ja hakkame seal konfiguratsioone võrdlema. Ja ma paigutan kahe viimase sammu kirjelduse (leida ja paranda) eraldi lõikudesse:

2.1. Otsige objekti, mille muudatused on värskendusega kustutatud. On aeg meeles pidada txt-faile, mille lõpud on vana/uus. Tegelikult kajastavad need failid kõiki konfiguratsioonimuudatusi (tavalisega võrreldes) vastavalt ENNE ja PÄRAST värskendust. Seega, kui oleme mõne muudatuse värskendusega üle kirjutanud, on see ainult failis "Võrdlusaruanne_vana.txt". See tähendab, et vajalike konfiguratsiooniobjektide otsimine taandub nende kahe faili võrdlemisele. Võrdleme neid faile failihalduri abil Täielik komandör ja selle sisseehitatud tööriistad. Arvan, et siin pole vaja seletada, mis on Total Commander, kust seda saada ja kuidas kasutada... Küll aga kirjeldan siin lühidalt selle kasutamise vajalikke etappe. Niisiis, käivitame Total Commanderi. Kui liidese keel on inglise keel (peamenüü ja nii edasi), saate selle muuta vene keeleks: "Konfiguratsioon - Valikud...", valige dialoogiboksis vasakpoolses veerus jaotis "Keel", otsige/valige "Vene (vene)" ja klõpsake "OK". Järgmiseks otsime läbi Total Commanderi aruannete txt-failid, valime need ("Sisesta" või "Paremklõps") ja alustame failide võrdlemist: "Failid - Võrdle sisu järgi..." (ingliskeelses liideses: "Failid" - Võrdle sisu järgi ..."). Avanevas aknas kuvatakse failide sisu vastavalt vasakul/paremal, “Järgmine erinevus”/ “Eelmine erinevus” nupud võimaldavad otsida erinevusi. See tööriist võimaldab teil kiiresti leida meile huvitavaid objekte.

Kommenteeri: võib juhtuda ka vastupidine olukord - PÄRAST uuendust ilmnevad konfiguratsioonis erinevused, mida ENNE uuendust polnud. See tähendab, et värskenduse väljalase eemaldas konfiguratsioonist vastavad objektid. Põhimõtteliselt võib need objektid meie paikades lihtsalt vahele jätta, kuna nendes objektides muudatusi ei toimunud.

2.2. Muudatuste tegemine värskendatud objektides. Pärast ülekirjutatud muudatustega objekti leidmist peame kindlaks määrama, kus need muudatused täpselt olid: moodulis (programmi tekst), dialoogiboksis (vormil) või muudes sätetes. Siin eraldan kaks juhtumit: mooduli muudatus ja kõik muud muudatused. Ja vaatame neid kahte juhtumit eraldi.

2.2.1. Värskendusega kustutatud muudatused olid moodulis. Tegelikult on see põhijuhtum (seda juhtub palju sagedamini) ja see juhtum on täpselt meie näites: muudatus kustutati moodulis “Käibemaksuarvestus”. Nagu me juba eespool mainisime, on meil Work Base Configuratoris avatud konfiguratsiooni võrdlemise aken. Otsime sealt vajalikku objekti. Tegelikult on selle asukohta konfiguratsioonipuus kirjeldatud meie tekstifailis, nimelt: "GeneralModule.VAT Accounting.Module". See on täpselt see, mida me võrdlusaknas otsime. Laiendame alluvuspuud seni, kuni leiame vajaliku mooduli - selle vasakpoolses servas peaks olema roheline pliiats, mis näitab, et objekti on tarnija konfiguratsiooniga võrreldes muudetud. Paremklõpsake leitud real ja valige "Kuva erinevused moodulites...":

Pärast seda avaneb moodulite võrdlusaken:

Siin ülaosas on näidatud protseduurid Ja funktsioonid , milles on muudatusi (meie puhul on see üks protseduur “Väljundarve tabeldokumendis”) ja alumises osas - valitud protseduuri või funktsiooni tekstid koos esiletõstetud muudatustega. Peame need muudatused oma testide andmebaasi üle kandma. Kuid see ei eemalda värskendusest muudatusi. Saate seda automatiseerida järgmiselt. Asetage kursor alumisse vasakusse ossa (kus on valitud protseduuri tekst meie muudatustega) ja vajutage järjestikku Ctrl+A (vali kõik) ja Ctrl+C (kopeeri valik lõikepuhvrisse). Seejärel loome faili koodinimega “old_izm.txt”, avame selle tekstiredaktoris ja vajutame Ctrl+V (kleebi puhvri sisu). Sama teeme alumise parempoolse osaga (kus on värskendamata väljalaske standardkonfiguratsioonist valitud protseduuri tekst) - selle tulemusena loome faili koodinimega "vana_tüüp.txt". Pärast seda läheme testbaasi konfiguraatorisse (see peaks olema avatud kõrvuti, kuid ilma akendeta, et mitte nendes kahes konfiguraatoris segadusse sattuda) - ja konfiguratsioonist otsime oma moodulit (selles näites see on “GeneralModule.VAT Accounting.Module” ja selles vajalik protseduur (antud näites on “Väljundarve tabeldokumendis”): vali see kõik välja ja kopeeri uude tekstifaili koodnimega “uus_tüüp. txt”. Seega on meil kolm faili ("vana_izm.txt", "vana_tüüp.txt", "uus_tüüp.txt"), mille alusel peame looma neljanda faili - "uus_izm.txt". See neljas fail peaks sisaldama meie muudatusi, kuid võttes arvesse värskendust. Moodustame selle järjestikku, võrreldes olemasolevat kolme faili. Kõigepealt teeme kindlaks, kas selles protseduuris on värskenduste muudatuste jälgi? Selleks võrdleme Total Commanderi abil faile "vana_tüüp.txt" ja "uus_tüüp.txt" (vt ülal). Kui võrdlus näitab, et failid on identsed või tühikute või tabeldusmärkide arv on erinev, tähendab see, et meil vedas selle muudatusega ja saate muudatused üle kanda lihtsalt faili "old_izm.txt" sisu kopeerides. ” ja kleepides selle testandmebaasi avatud moodulisse, kustutades esmalt vastava protseduuri (ehk asendades). Siin on oluline hoolikalt jälgida tühikuid enne ja pärast protseduuri, et edasisel võrdlusel ei oleks üleliigsust: see muidugi ei mõjuta funktsionaalsust, kuid muudab kontrollimise pisut keerulisemaks. Kui "vana_tüüp.txt" ja "uus_tüüp.txt" võrdlus näitas, et erinevused on tõelised, tähendab see, et see protseduur sisaldab nii meie muudatusi kui ka värskendusega seotud muudatusi. Ülekandeülesande lihtsustamiseks: esiteks saate visuaalselt hinnata, millised muudatused on suuremad - värskendusest või meie omast. Selleks võrdleme Total Commanderi kaudu järjestikku "vana_tüüp.txt" failiga "uus_tüüp.txt" ja "vana_izm.txt". Ja me vaatame, kus on rohkem muudatusi: "vana_tüüp.txt" ja "uus_tüüp.txt" või "vana_tüüp.txt" ja "vana_izm.txt" võrdluses. Kui esimeses võrdluses on muudatusi rohkem (värskendus on funktsiooni rohkem muutnud), siis on uuendatud faili lihtsam parandada meie muudatusi tehes ehk muudame “uus_tüüp.txt”. Nimetagem seda muudatuste tegemise esimeseks juhtumiks. Kui teises võrdluses on rohkem muudatusi (meil oli rohkem muudatusi), siis on meie faili lihtsam parandada värskendusmuudatusi tehes, st muudame faili "old_izm.txt". Nimetagem seda muudatuste tegemise teiseks juhtumiks. Nüüd kuidas täpselt muudatusi kiiresti ja täpselt üle kanda. Selleks loome neljanda faili ja, nagu juba kokku lepitud, nimetame selle “new_izm.txt”. Arvestades paranduste ülekandmise optimeerimist, kopeerime sellesse faili kas “uus_tüüp.txt” või “vana_izm.txt” sisu (vastavalt muudatuste tegemise esimeseks või teiseks juhuks).
Nüüd avage kaks failivõrdlusakent korraga. Esimesel juhul on tegemist failide "uus_izm.txt"/"vana_izm.txt" ja "vana_tüüp.txt"/"vana_izm.txt" võrdlustega. Teisel juhul on need failide "uus_izm.txt"/"uus_tüüp.txt" ja "vana_tüüp.txt"/"uus_tüüp.txt" võrdlused. Võrdlusaknas on nupp "Muuda": klõpsake seda esimese paari võrdluses. Nüüd selgitame, mida me näeme. Esimeses võrdluspaaris on näha nii meie muudatuse kui ka uuenduse objektid. Olenevalt juhtumist peame üle kandma ainult oma muudatused või ainult värskendused. Teises võrdlusaknas on nähtavad ainult need muudatused, mida peame üle kandma. Kui pöörata tähelepanu - mõlemal juhul on nii esimese kui ka teise võrdluse teine ​​fail sama. Seetõttu keskendume selles failis olevatele ridadele ja vastavalt teise võrdluse ridadele teeme muudatused esimese võrdluse aknas: nupu "Muuda" vajutamine võimaldab meil seda lihtsalt teha.

Selguse huvides kujutame esimesel juhul graafiliselt toiminguid ülekande ajal (muudame värskendatud faili oma muudatustega):

Teisel juhul on toimingud täiesti sarnased ja toimimispõhimõte on täpselt sama.

Kõige keerulisem ja ebameeldivam juhtum on see, kui meie muudatused ja uuendusmuudatused on ÜHES ​​kohas. See tähendab, et tegelikult toimus ühes koodisegmendis kaks muudatust. Sel juhul on vaja programmeerija sekkumist. Samuti on vaja programmeerija sekkumist, kuid vähemal määral, kui näiteks uuendus muudab meie muudatustes kasutatavate muutujate nimesid. Samuti väärib märkimist, et fail "old_type.txt" või "old_izm.txt" võib sisaldada tühje ridu - need on meie muudatuste "jäljed". Peate need üle kandma, et need ei oleks lõplikus failis. Funktsionaalsust see ei mõjuta, kuid edasistes võrdlustes (koos järgnevate uuendustega) muudab see toimingute analüüsi veidi keerulisemaks. Seega, kui oleme loonud neljanda faili, mis on kõik muudatused üle kandnud, peame selle sisu konfiguratsiooni kopeerima. Testi andmebaasi konfiguraatoris tuleb vajalik moodul avada uues kohas: kustutada olemasolev protseduur ja sisestada meie lõpliku faili sisu, võttes arvesse kõiki tühikuid eelmiste/järgmiste funktsioonide vahel. Seega kandsime muudatused leitud objekti ÜHE protseduurile. Meil (joonis 6) on tõesti ainult üks protseduur. Kui selliseid protseduure on mitu, tuleb kirjeldatud toimingud läbi viia igaühe jaoks. Kui protseduur on uus (ainult vasakus pooles), lisage see lihtsalt testide andmebaasi vastavasse moodulisse (edasivõrdluse õigsuse huvides peate säilitama protseduuride järjekorra, nagu töö vastavas moodulis andmebaas, kus on veel vana väljalase).

2.2.2. Muudatused, mis värskendusega üle kirjutati, EI olnud moodulis. Selliste muudatuste ülekandmiseks ei lihtsusta selline võrdlus tööd kuidagi, seega kantakse muudatused üle lihtsalt töö- ja testandmebaasis olevate objektide visuaalse võrdlemise teel.

Seega edastame muudatused iga objekti kohta, mille värskendus meie muudatused üle kirjutas. Kontrollimaks, kui õigesti oleme kõik muudatused üle kandnud, salvestame konfiguratsiooni testandmebaasi, laadime konfiguratsioonide võrdluse üles faili “Comparison Report_new2.txt” ja võrdleme seda failiga “Comparison Report_old.txt”. Kui kõik on täiuslik, kuvatakse teade "Failid on identsed". Kui värskendusega kustutati mõned objektid, siis muudatuste korrektsel ülekandmisel on erinevuses nähtavad ainult need objektid. Õige oleks, kui võrdluses on näha ainult tühikud/tühjad read/tablood, kuid sel juhul on parem see kustutada ja kuvada teade “Failid on identsed”. Seega laadime peale muudatuste salvestamist testandmebaasi üles võrdluse faili ja võrdleme seda vana versiooni muudatustega – kordame seda seni, kuni võrdlus näitab, et oleme kõik vajalikud muudatused üle kandnud.

3. Uuendatud konfiguratsiooni ülekandmine testist töötavasse andmebaasi. Eelmistes etappides värskendasime testbaasi uusimale versioonile, kontrollisime ja edastasime vajalikud muudatused ning salvestasime saadud konfiguratsiooni. Nüüd laadime selle üles cf-faili ja laadime töötavasse andmebaasi. Enne allalaadimist peate töötavast andmebaasist koopia tegema ja konfiguratsiooni tugiteenustest eemaldama. KÕIK. Kasutajad olid "tühikäigul" ainult alguses, kui andmebaasi maha laadisime ja lõpus, kui andmebaasi uuesti maha laadisime ja konfiguratsiooni laadisime.

See värskendus on täielikult lõpetatud.

Algne artikkel on veebisaidil

Mittestandardse, väga muudetud konfiguratsiooni värskendamine on väga aeganõudev ja vastutusrikas ülesanne. Tavaliselt tehakse väljalase värskendus konfiguratsioonide jaoks, mis sisaldavad reguleeritud aruandluse plokki. Näiteks, .

Vaatame lihtsaimat viisi mittestandardse värskenduse tegemiseks ilma vigadeta, kasutades näitena 1C ettevõtte raamatupidamise konfiguratsiooni.

Iga värskenduse algust kirjeldatakse artiklis. Vaatleme ainult kõige olulisemat - mittestandardse värskenduse nüansse.

Väike teooria mittestandardsete konfiguratsioonide kohta:

• Toetamata konfiguratsioon sisaldab kahte konfiguratsiooni: andmebaasi konfiguratsiooni ja põhikonfiguratsiooni.
• Toetatud konfiguratsioon ilma redigeerimisvõimaluseta sisaldab kahte konfiguratsiooni: andmebaasi konfiguratsiooni ja põhikonfiguratsiooni (teise nimega tarnija).
• Toetatud konfiguratsioon koos muutmisvõimalusega sisaldab juba 3 konfiguratsiooni: andmebaasi konfiguratsioon, põhikonfiguratsioon ja tarnija konfiguratsioon.

1. Värskenduseks valmistumine

Enne alustamist veenduge, et hankija konfiguratsioon ühtiks põhikonfiguratsiooniga – see hõlbustab oluliselt kohandatud värskendust. Kui pakkuja konfiguratsioon on vanem versioon, ei värskendatud konfiguratsiooni varem õigesti. Saate värskendada tarnija väljalaset, käivitades värskenduse ükshaaval ja valimata võrdluseks ühtegi objekti.

Esiteks juurutan algse konfiguratsiooniga 2 andmebaasi. Üks muudatuse tegemiseks, teine ​​uuega võrdlemiseks.

Hankige 267 videotundi 1C-s tasuta:

Kui teie konfiguratsioon ei ole standardne, klõpsates konfiguraatoris nuppu "Uuenda", alustab süsteem peamise ja uue tarnija konfiguratsiooni võrdlemist:

Väliselt tundub, et suur hulk objekte on muutunud. Kujutagem siiski ette olukorda: muutsite dokumenti, kuid see ei muutunud – kas peate seda käsitsi värskendama? Muidugi mitte. Selliste objektide valimiseks pärast võrdlemist klõpsake kindlasti nuppu Filter ja märkige ruut

Pärast filtreerimist näeme, et muudetud objekte on palju vähem:

Saime nimekirja objektidest, millega tegeleme. Meie puhul oli ainult üks keeruline objekt - dokument RecordKUDiR.

2. 1C värskenduse muudatuste ülekandmine

Muudatuste ülekandmiseks avan 2 konfiguraatorit - ühes teen võrdlusi ja teen muudatusi ning teises teen muudatusi.

Järgmine etapp on muudatuste tegelik ülekandmine. Vaatame mittestandardsete konfiguratsioonide värskendamise põhitehnikaid.

3. Moodulite erinevused

Üsna lihtne, kuid väga vastutustundlik toiming - me lihtsalt teisaldame moodulid uuelt versioonilt vanale. Kui kood on kommenteeritud, ei tohiks probleeme tekkida:

4. Kujundite ja paigutuste võrdlused

Siin on protsess palju keerulisem. Peate tabama vähimaidki muudatusi vormides. Soovitan koostada üksikasjalik aruanne erinevuste kohta graafilise esitusega:

Kui olete uuest konfiguratsioonist kõik objektimuudatused üle kandnud, käivitage võrdlus ja ühendage uuesti, eemaldades võrdlemiseks käsitsi muudetud objektid.

Muudetud 1C konfiguratsiooni ebatüüpiline värskendus on lõpetatud!

Märge! Kui te ei tea, kuidas 1C 8-s programmeerida, on mittestandardse konfiguratsiooni eduka värskendamise võimalus äärmiselt väike. Raiskate palju aega ja saate konfiguratsiooni, mis isegi ei käivitu. Soovitan kiire abi saamiseks ühendust võtta.

Isiklik kogemus: kuidas muudetud konfiguratsiooni kiiresti ja kulutõhusalt värskendada

Mitme väljalase korraga konfiguratsiooni värskendamine on väga ohtlik. Fakt on see, et pärast iga konfiguratsioonivärskendust käivitatakse teabebaaside värskendamine režiimis 1C: Enterprise. Seega, kui värskendate ainult uusimat versiooni, ei pruugi teabebaasid vastata uusimale konfiguratsioonile. Artiklis jagab Siberian Agrarian Group CJSC spetsialist Dmitri Rudakov oma isiklikku kogemust 12 väljalase konfiguratsiooni samaaegsel värskendamisel.

Konfiguratsiooni muutmise režiimi kontrollimine

Kujutagem ette sellist olukorda. “Tootmisettevõtte juhtimine” (edaspidi PPE) väljaandes 1 (väljalaskenumbrid edaspidi omistatakse tingimuslikult) määrasid arvutusregistri dimensiooniks (indikaatoriks) tüübi “Kataloogilink.Individuaal” nimega “Individuaal” . Versioonis 2 lisasid nad veel ühe mõõtme - "Töötaja" tüübiga "DirectoryLink.Employees". Kui käivitate "1C:Enterprise", lülitatakse sisse töötlemine, mis täidab dimensiooni "Töötaja" viisil, mis vastab dimensioonile "Isikisik". Ja siis 3. versioonis eemaldasid 1C arendajad mõõtme "Individuaalne" ja jätsid ainult "Töötaja". Kui värskendate konfiguratsiooni versioonist 1 kohe versioonile 3, saate kogu arvutusregistri tühjendada.

Ja kui konfiguratsiooni toetatakse muutmisvõimalusega ja samas andmebaasis genereeritakse reguleeritud aruandlus, siis on vaja iga versiooni konfiguratsiooni värskendada, mis võib töötundides olla väga kulukas. Näiteks tugevalt muudetud "UPP" värskendamine ühe versiooni jaoks võib võtta 30 tundi kogenud spetsialisti tööajast.

Seetõttu peate enne värskendamise alustamist kindlaks tegema: kas töötate muutmisvõimalusega standardkonfiguratsioonis või muutmisvõimaluseta konfiguratsioonis? Selleks minge konfiguraatorisse, kus menüüs järgige juhiseid "Konfiguratsioon - Tugi - Toe sätted".

Joonis 1. Konfiguratsioonitoe häälestusakna helistamine

Kui see on seatud olekusse "Toetamine", on see konfiguratsioon tüüpiline ja kui "Muutamisvõimalus on lubatud", on konfiguratsiooni suure tõenäosusega muudetud (vähemalt selline võimalus on kaasas). Kolmas olek on "Seadistust enam ei toetata". Erinevad konfiguratsiooniolekud on näidatud joonistel 2, 3, 4.

Riis. 2. Standardkonfiguratsioon ilma muutmisvõimaluseta

Riis. 3. Tüüpiline konfiguratsioon, mille muutmisvõimalus on lubatud

Riis. 4. Aegunud konfiguratsioon

Algoritm muudetud konfiguratsioonide värskendamiseks

Hiljuti seisin silmitsi ülesandega värskendada muudetud Trade Managementi konfiguratsiooni, väljalase 10.3.13.2. Konfiguratsiooni muudeti tööstuslahendusega "BIT: Automotive Service Management 8" integreerimise tulemusena ja seda täiustati pidevalt kahe aasta jooksul. Nüüd tuli konfiguratsiooni värskendada versiooni 10.3.25.1, st 12 väljalase jaoks. Olen jaganud kogu värskendusprotseduuri mitmeks etapiks.

1. etapp. Uuendusprotseduuri maksumuse ja ajastuse hinnang

Enne iseseisva töö alustamist otsustasin saada selle ala spetsialistidelt sõltumatu hinnangu. Ainus ettevõte, kellel on võimalus automaatsete meetodite abil muudetud konfiguratsioone värskendada, on 1C-IzhTiSi LLC. Pöördusin selle ettevõtte spetsialistide poole palvega hinnata minu konfiguratsiooni värskendamise kulusid. Tööde aja ja maksumuse hindamiseks olen esitanud praeguse konfiguratsiooni, mis vajab värskendamist. Päev hiljem sain kirja raportiga.

Aruanne konfiguratsiooni värskenduse kulude ja ajastuse hindamise tulemuste kohta:

Konfiguratsioon: Trade Management, väljaanne 10.3
Praegune konfiguratsiooniversioon: 10.3.13.2
Värskenda versioonile: 10.3.25.1
Uuendatud moodulite arv: 1847
Kontrollväljalaskmiste arv: 8

Hindamise tulemused üllatasid mind, kuna ettevõtte veebisaidil oli märgitud aktsia hind - 1000 rubla. värskenduse kohta versiooni kohta. "1C-IzhtiSi" kommentaar:

"Uuenduse maksumus iga vahelejäänud väljalase kohta ei ületa 2000 rubla. Hetkel on käimas kampaania, nii et hind ei ületa 1000 rubla. Teenuste lõplik hind kujuneb aga värskenduse tööjõukulude hindamisel ja võib olla alla 1000 rubla ühe väljalaske kohta.

Täpsustasin ka seda, kuidas uuenduseks vajalikud väljalasked valiti. Vastuseks minu küsimusele sain ekraanipildi, millel see oli selgelt näidatud (joonis 5). Veerg Version Number näitab konfiguratsiooni versiooni, millele peate uuendama. Veerg "Versiooniuuendus" näitab, millisest versioonist on võimalik uuendada. Hindamise tulemusena vähendati vajalike uuenduste arvu 9-le.

Riis. 5. Väljalasete valimine, mida tuleb konfiguratsiooni korrektseks värskendamiseks kasutada

Pärast 1C-IzhTiS aruande uurimist arvutasin välja isikliku ajakulu sama töömahu kohta. Iga värskendus võtab mul umbes 6 tundi. Seega on ajakulu kokku 56 (9x6) töötundi ehk ligikaudu seitse tööpäeva. Lisaks on võimalus, et pärast värskendust ilmnevad mõned puudused: näiteks kaebab kasutaja, et vajalikud konfiguratsioonimuudatused läksid kaotsi ja siis ajakulu tõsiselt suureneb. Samal ajal pakuvad ettevõtte 1C-IzhTiS spetsialistid kogu töö lõpuleviimiseks kolme kuni nelja tööpäevaga. Seetõttu otsustasin kasutada nende teenuseid.

Nüüd selgitan lühidalt, mida konfiguratsioonis täpselt muudeti.

Tugevalt muudetud objektid. Need on objektid, millel on palju tüüpilisi omadusi muudetud. Kohandused on keerulised. Objekti andmed on lisatud tabeliosale, kuvatakse objekti vormil ja loendi vormil. Lisatud on töötlejad vormidele lisatud üksikasjade jaoks. Muudetud on standardset mehhanismi dokumendi postitamiseks või registri jaoks liikumiste kogumi registreerimiseks.

Tugevalt muudetud dokumendid:
"Tellimine tarnijale";
"Kaupade liikumine";
"Nõue-arve";
"Kauba ja teenuste vastuvõtt."

Tugevalt muudetud registrid:
"Kaubasaadetised ladudes";
"Kaubad ladudes."

Oluliselt muudetud objektid. Objektid, millesse on lisatud detaile, muudetud kas objektivorme või objektimooduleid (reeglina on dokumentide postitamine ebatüüpiline).
Dokument "Kassa laekumise order";
Inforegister "Osad";
Inforegister "Mahakantav kaup";
Üldmoodulid.

Veidi muudetud objektid. Muudetud on ainult objektidel olevaid vorme ja lisatud detaile.

Kataloogid:
"Nomenklatuuri liigid";
"Töövõtjate kokkulepped";
"Vastaspooled";
"Nomenklatuur";
"Kauba hinnaliigid";
"Mitmed teaberegistrid."

Jaotises "Üldine" on muudetud sündmuste tellimusi, paigutusi, rolle ja üldmooduleid. Peaaegu kõik on tööstuse otsusega muutunud.

2. etapp. Konfidentsiaalse teabe eemaldamine

Enne 1C-IzhTiS-i töötajatele testimiseks teabebaasi andmist tuleb konfidentsiaalne teave sellest kustutada. Sellistel juhtudel soovitab 1C kasutada töötlemist "Konfidentsiaalse teabe muutmine", mis pole eriti laialt tuntud.

"Konfidentsiaalse teabe muutmise" töötlemine on ette nähtud teabe valikuliseks muutmiseks või kustutamiseks teabebaasis.Töötlemise abil saab enne testimiseks üleandmist koostada infobaasi, kus on vaja mõnda infot peita (kustutada, muuta).

ChangeConfidentialInformation.epf töötlemine asub ITS-i kettal kataloogis 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Selle töötlemise saab alla laadida ka lingilt: http://its.1c.ru/db/metod81#content:1644:1.

Loomulikult on konfidentsiaalne teave igas ettevõttes erinev, kuid juhin teie tähelepanu andmetele, mis vajavad tõenäoliselt muutmist:

• Kataloogid: Eraisikud, Kontaktisikud, Osapoolte kontaktisikud, Vastaspooled, Hinnaliigid.
• Teaberegistrid: üksikisiku passiandmed, üksikisiku täisnimi.

Teie loend on tõenäoliselt pikem, kuid need on kõige levinumad andmepunktid. Tõenäoliselt ei mõjuta nende muutmine teie teabebaasi testimise võimalust. Grupitöötluse abil saate kustutada ka kõik need objektid, millega teenindusettevõte ei peaks töötama.

3. samm: värskendustulemuste hankimine

Kolm päeva hiljem saadeti mulle cf-failid ja põhjalikud juhised nende installimiseks. Juhtversioonide jaoks on ette nähtud cf-failid, mida ei saa kasutaja tööks kasutada, kuna neis värskendatakse ainult metaandmeid. Need on mõeldud ainult korrektseks värskendamiseks uusimale versioonile.

Töö tulemuste põhjal võin öelda, et kõik konfiguratsiooni muudatused salvestati, visuaalsel vaatlusel säilitasid kõik muudetud objektid oma omadused ja erinevused standardkonfiguratsioonist. Töötamise ajal ei teatanud ükski kasutajatest, et muudatused oleksid kadunud.

Värskenduse tulemusena tuvastasin kaks väikest ülesannet, mis tuleb iseseisvalt lahendada.

Esiteks. Tulenevalt asjaolust, et uuendamine toimub mehhanismi “Võrdle, ühenda” abil, uuendatakse andmebaasi konfiguratsiooni tegelikult ja uuendatakse õigesti, ilma tehniliste riskideta, mis tulenevad kontrollväljaannete arvestamisest. Kuid pakkuja konfiguratsiooni ei värskendata. Loomulikult teeb tehniliselt pädev spetsialist selle töö probleemideta ära, kuid palusin 1C-IzhTiS-il saata täielikumad juhised uuenduseks. Selle kohaselt saab isegi kogenematu spetsialist värskendada.

Teiseks. Värskenduse tulemusena jäävad kõik objektid toele koos muutmisvõimalusega, mis võib olla ka kaudseks puuduseks. Kui teil on vaja neid teenuseid korraga kasutada, peate kõik objektid uuesti tuge panema. Seni saan seda teha ainult siis, kui otsin läbi kõik metaandmeobjektid. Kahjuks toimub see protsess praegu käsitsi, kuid edaspidi automatiseeritakse.

Lisaks kahele mainitud ülesandele avastati üks väike viga, mis põhimõtteliselt värskenduse kvaliteeti ei mõjuta ja esineb harva. Värskenduse tulemusena kattuvad algse konfiguratsiooni ja uuendatud koodiread visuaalselt, kuid millegipärast lisatakse ridade lõppu tühikud. See on puudus, kuna see suurendab veidi muudetud koodi hulka. Ja edasiste käsitsi uuenduste puhul oleks parem, kui selliseid koodilõike ei oleks. Joonisel fig. 6 on näide enne värskendamist ja joonis fig. 7 - näide pärast värskendamist.