Ajalugu 1s 8.3., Kust leida. Andmete ajalugu

Ettevõtte protsessis on sageli vaja dokumendis või programmijuhendis välja selgitada, kes, millal ja mis täpselt on muutunud.

Väga sageli küsivad nad minult küsimusi:

• Kuidas muudetud dokumenti 1C 8.2-s näha?
• Kuidas muuta muudetud dokumenti 1 sekundiga?
• Kuidas 1C-s teada saada, kes millal dokumente muutis?
• Kuidas 1C-s teada saada, kes muutis dokumendis esitatud juhtmestikku?
• Kuidas näha, kes muutis dokumenti 1 sekundiga?

Püügipäevik

See sisaldab teavet selle kohta, millised sündmused infopunktis teatud ajahetkel toimusid või milliseid toiminguid konkreetne kasutaja tegi. Iga andmete muutumist kajastava päevikukirje korral kuvatakse tehingu lõpuleviimise olek (tehing on edukalt lõpetatud või tehing tühistatud).

Püügipäevik on saadaval nii režiimis 1C: Enterprise kui ka konfiguraatori režiimis.

Juurdepääs logiraamatule on võimalik nii konfiguraatori režiimis (menüü kaudu Administreerimine - logiraamat) ja režiimis Ettevõtte (menüü Teenus - registreerimispäevik) Taksorežiimis ( Peamenüü - Kõik funktsioonid - Tavaline - Püügipäevik)

Logi tüüp   (Tavapärased vormid ja taksod):

Valik püügipäevikus   (Tavapärased vormid ja taksod):

Loenditega töötamiseks mõeldud tööriistu kasutades on võimalik logiraamat üles laadida arvutustabelisse või vajadusel tekstidokumenti (toimingute - loendi kaudu), mida saab hiljem salvestada näiteks Exceli, TXT või HTML-vormingus. Samal ajal on võimalik kohandada nii päevikusse salvestatavate sündmuste taset kui ka eraldi failideks jagamise logi sagedust (menüü konfiguraatori režiimis)   Administreerimine - logimise seadistamine).

Ja seal on ka võimalik vähendada selle ajakirja sissekannete arvu teatud kuupäevani, mis tehakse selleks, et kiirendada tööd süsteemis toimuvate sündmuste analüüsimise ja registreerimise mehhanismiga või vananenud teabe kasutuse tagamiseks.

Kus logi peetakse

Failide andmebaasis:   baaskataloogis 1Cv8Log -see on logiraamatut sisaldav kataloog.

Kui plaanite failiandmebaasi üle kanda ja soovite salvestada registreerimislogi ajalugu, peate kindlasti kopeerima kausta 1Cv8Log uue 1C andmebaasi kategooriasse. Kui peate failibaasis kustutama 1C logi, kustutage lihtsalt kaust 1Cv8Log.

SisseKlient-server baas: C: \\ programmifailid \\ 1cv8 \\ srvinfo \\<Имя кластера сервера>\<Идентификатор базы на сервере>\\ 1Cv8Log

Alates versioonist 8.3.5.1068. Logiraamatu olulist ümberkujundamist, et kiirendada logi päringute kiirust ja suurendada andmete salvestamise usaldusväärsust.

Selleks, sealhulgas, tuli muuta logiraamatu salvestusvormingut. Nüüd on see salvestatud ühte SQLite andmebaasi faili. Selle faili laiend on lgd.

Objektide versioonimine

Mõnes 1C konfiguratsioonis võetakse kasutusele spetsiaalne mehhanism „Objektide versioonimine”.

Versioon on vaikimisi välja lülitatud, et lubada avada Teenus - raamatupidamisseaded - raamatupidamisseaded

Nuppu “Objekti versioonimise konfigureerimine” kasutades valime, milliseid katalooge ja dokumente tuleb versioonida (jälgige, kes mida ja millal muutis).

Vaikimisi ei jälgita teabebaasi objekte, nii et märk „Ära versiooni” on seatud igat tüüpi dokumentide vastas. Kui soovite, et järelevalvet teostataks, peate installima huvipakkuva dokumendipäeviku vastas versiooni "Versioonimine".

Kõik, kui akna sulgete ja klõpsate nuppu "OK", jälgitakse objekte.

Kõigi muudatuste vaatamiseks, mille keegi dokumendis või teatmikus tegi, minge menüüsse: Teenus - objekti muutuste ajalugu

Kuidas saada kiiret vastust, milline kasutaja saaks programmi andmeid vastavalt dokumendile muuta? Mida ta täpselt muutis? Nii et see vastus oleks võimalikult kiire ja iga kasutaja saaks selle vastuse ilma süsteemiadministraatoriga ühendust võtmata.

Tüüpilises konfiguratsioonis on tootmisettevõtte 1.3 haldusel (SCP) moodul objektide versioonidega töötamiseks. See võimaldab salvestada praegusesse andmebaasi kõik muudatused, mida kasutajad teevad kataloogide ja dokumentidega. See alamsüsteem võimaldab teil valikuliselt märkida, millist tüüpi katalooge ja dokumente kasutada ja milliseid mitte.

Üldiselt on selle tööriista peamine probleem see, et need andmed andmebaasis kasvavad nii tugevaks, et andmete hulk muutub võrreldavaks selle jaoks talletatud ajaloo salvestusmahuga. Suurte aluste puhul muutub see katastroofiliseks probleemiks.

Kui kaua võtab aega põhjuse leidmine, kes mida muutis? Mitu võrdlust on vaja, kui näiteks ajalukku salvestatakse seda, et dokumenti muudeti 30–100 korda? Kuid dokumentide rühmalise hoidmise ajal tehtud lihtne kirje lisab siia muudatuste versiooni ja tegelikult ei muuda dokumendis midagi sellist sisestust. Üldiselt kehtivad selle arvu versioonide korral jõuga seotud muudatused 2-3-5. Aga ülejäänud? Ja see on liigne prügi.

Üldiselt on süsteem hea, see võimaldab teil muudatusi üksikasjalikult salvestada. Kuid siin pole seda, kuidas neid andmeid täiendavalt kasutada, pole eriti mugav. Enamikul juhtudel, kui kasutajad leiavad, kes andmebaasis muutis administraatorit 1, kasutab seda aruannet ja määrab need asjad.

Kuidas muuta see kiireks vastuse leidmise vahendiks, kes on mida muutnud?

"Rääkige mu peeglist, aga rääkige kogu tõest ..."

Asjade loogika järgi ei tühista meie täpsustus versiooniversiooni. Töötas välja oma operatiivjuhtimise süsteemi selle jaoks, kes mida muutis. Versioonimine võib töötada paralleelselt. Süsteemi nimetatakse "kataloogide ja dokumentide muutumise ajalugu". See on üsna lihtne kasutatav süsteem, mis on vajalik dokumendi muutnud vastuse kiireks saamiseks, viide.

Tegelikult on selle süsteemi eesmärk lihtsalt kiiresti teavitada, kes ja millal dokumenti muutis. Üksikasjalik vastus selle kohta, mida kasutaja on muutnud, pole alati vajalik. Teisisõnu, siin on lihtne "logiraamatu" analoog, mis ütleb ka selle kohta, millal ja kes toimingu tegi. Kuid kasutaja pääseb sellele juurde palju kiiremini. Tüüpilise logiraamatuga töötamine on ebamugav ja tohutu hulga andmete korral pole isegi kiiret vastust võimalik saada. Ja siin on register andmebaasis endas ja annab kohe vastuse. Pealegi ainult üks nupp "Ajalugu" dokumendis endas (!).

Iga kasutaja saab kiiresti näha, kes dokumendiga töötas. Ja juba siis, kui vajate vastust, mida see kasutaja sellega täpselt tegi (tõendusmaterjalina), saate juba kasutada kõiki versioone süsteemis olevaid andmeid.

"Kui midagi saab teoga tõestada, pole vaja sõnu raisata."
Aesop

"Kelle kinga?"

Ka meie süsteemis on veel üks võimalus - see on lao ja toodangu raamatupidamisdokumentide, aga ka hinnakujundusdokumentide tabeli osa muudatuste ajaloo säilitamine. Täpsemalt, enamikul juhtudel on kirjete pidamisel huvitav tabelite osade "Kaubad", "Materjalid", "Tooted" muudatuste ajalugu.

Kuidas see töötab? Oletame, et soovite saada vastust: millal on uus hind määratud? Kes kustutas rea kolimisdokumendist? Kes asendas nomenklatuuri teise nomenklatuuriga? Kes eemaldas koguse? Kes määras allahindluse? Kes muutis hinda? Näete dokumendis hindade tüüpi muutnud isikuid.

Sellisel juhul võrreldakse praeguses süsteemis muudatuste registreerimisel varem salvestatud ajaloo andmeid ja ajaloos registreeritakse ainult see, mis on muutunud. Üleliigset ajaloo talletamist pole.

Muuda aruannet

Kogu protokoll on visuaalselt esitatud aruande vormis „Aruanne dokumentide tabeliosade muutuste kohta“. See aruanne avaneb ainult dokumendis ühe nupu “Ajalugu” vajutamisega ja näitab koheselt, millise nomenklatuuri järgi on muutunud ja mis kõige tähtsam, kes ja millal. Tegelikult võimaldab see aruanne kohe saada vastuse ülaltoodud küsimustele. Ja ilma administraatori 1 osaluseta.

« Inimese tõelised omadused avastatakse alles siis, kui saabub aeg neid praktikas tõestada. ”
L. Feuerbach

Operaatorite tasustamine

Tulevikus kasutatakse neid andmeid kataloogides ja dokumentides tehtavate muudatuste osas. Seal on aruanne “Aruanne kataloogides ja dokumentides tehtud muudatuste kohta”. See võimaldab kasutajatel kasutajatel näha, mitu sammu kataloogide ja dokumentidega on tehtud (lõi uue, muutis, kulutas). Lisaks on sellel aruandel funktsionaalne funktsioon isegi töötasu arvutamisel. Määratakse ühe objekti muutmise määr (iga eraldi) ja aruanne näitab näiteks seda, kui palju operaator on teeninud.

Üksikasjalikult

"On küsimusi, millele pole vastuseid, kuid on vastuseid, mis põhjustavad palju küsimusi"
E. Sevrus

See töötlemine töötab pehmete starterite 1.3, UT10.3 konfiguratsioonides. Ja selle saab integreerida ka suvalisse 1c konfiguratsiooni, kus on lao- ja tootmisrekordid. Töötab tavalistel vormidel.

Järeldus

Teabeajalugude hoidmiseks turul on palju võimalusi. Seal on koht, kus isegi andmebaas on salvestatud. Võimalik, et seda rakendatakse palju paremini ja universaalsemalt. Kiire vastuse andmine oli meie jaoks peamine. Nii et iga kasutaja (laopidaja, operaator, raamatupidaja) ei raiska vastamisele aega, vaid võtab selle kohe vastu. Ja veel üks tingimus on andmete edasine kasutamine kasutajate palkade arvutamisel.

Sisselogimine 1C 8.3-s on väga kasulik, kuna see kuvab infopunktis toimunud sündmused aja, arvuti nime ja kasutajanimega ning linke muudetavate andmetega. Kasutajate autentimisel luuakse logisse ka logid, mis näitavad programmi sisenemise viisi. See mehhanism võimaldab teil vastata ühele kõige tavalisemale küsimusele - kes viimati konkreetses objektis muudatusi tegi.

Kust leida registreerimisloki 1C 8.3? Menüü „Kõik funktsioonid” - „Standard” kaudu või tüüpilistes konfiguratsioonides 1C menüüs „Administreerimine” - „Tugi ja hooldus”.

Püügipäeviku seadistamine toimub konfiguraatori režiimis. Valige menüüs "Administreerimine" "Logimise seadistamine".

Siin saate konfigureerida sündmusi, mida logis kuvatakse.

Esimese sätte valimine lubab teil mitte sisse logida. Ülejäänud seaded on tähtsuse järjekorras järjest suurenenud. Suure hulga kasutajate puhul pole soovitatav märkmeid registreerida, et mitte andmebaasi risustada.

Uue infobaasi loomisel on vaikimisi režiim kõigi sündmuste registreerimine.

Kannete vaatamine ja otsimine

Kui avate registreerimispäeviku ise, võib esmapilgul tunduda, et teavet on palju ja selle leidmine on lihtsalt ebareaalne. See pole tegelikult nii.

Vaikimisi kuvatakse logiraamatus 200 kirjet. Suure hulga kirjete kuvamine võib teie programmi jõudlust ebasoodsalt mõjutada või see lihtsalt ripub.

Püügipäeviku nimekirja kujul saate valiku teha ja otsingut kasutada. Otsimine toimub ainult juba kuvatavate kirjete peal (sel juhul viimased 200 sündmust). Valik kehtib kõigi kirjete kohta.

Otsimine toimub vastavalt tabeliosas kuvatud andmetele, nii et selle kasutamisel peate määrama ainult veeru ja andmed, mida peate leidma.

Valik võimaldab teil valida konkreetsete kasutajate andmeid, arvutinimesid, sündmusi jne. Samuti on teil võimalus kuvada ainult konkreetsete metaandmete, andmete (näidatakse linki soovitud objektile, näiteks konkreetne dokument) ja muude sätete logikirjeid.

Selles näites kuvatakse logi sätted administraatori kasutaja kõigi sündmuste valimiseks alates 06./2017.

Kus on salvestatud 1cv8.lgd logifail

Logi füüsilise salvestuse asukoht sõltub otseselt sellest, kas failibaas või klient on server.

Failibaas

Selle paigutusrežiimi korral asub logiraamat kaustas andmebaasi endaga. Selle asukoha leiate kas andmebaaside loendist või spikrist "Teave programmi kohta".

Sellele aadressile minnes leiate kausta nimega "1Cv8Log". Siin asuvad faili 1Cv8.lgd logiandmed.

Kui peate andmebaasi ühest kohast teise üle kandma, saate selle kataloogi kopeerida samal viisil, siis edastatakse logiraamatu andmed koos andmebaasiga.

Kui kustutate selle kataloogi, kustutatakse logi.

Klient-server baas

Selles režiimis on kõik sama, mis eelmises, serverisse salvestatakse ainult 1C logiandmeid. Enamasti on selle asukoht järgmine:

• C: \\ programmifailid \\ 1cv8 \\ srvinfo \\<место расположения информационной базы>\\ 1Cv8Log

Optimeerimine

Registreerimislogi saab vajadusel optimeerida, eriti kui andmebaasis toimub suur arv sündmusi.

Üks võimalus on konfigureerida ainult teatud sündmused, mida eespool salvestada. Näiteks pole vaja märkmeid jälgida, kui te neid lihtsalt ei vaja.

Vanemates platvormi väljaannetes oli püügipäeviku sätetes eraldatud püügipäevik perioodide kaupa. Kogu ajakirja võiks jagada eraldi failideks kindlaksmääratud sagedusega (päev, kuu, aasta jne).

Alates platvormi versioonist 1C 8.3.5.1068 salvestatakse logi sqlite andmebaasi faili laiendiga * .lgd ja see säte on muutunud kättesaamatuks. See logipäeviku salvestamise meetod on palju produktiivsem kui vana.

Kuidas vähendada sisselogimist 1C

Kui seadete aknas on vaja logikirjed osaliselt või täielikult kustutada, klõpsake nuppu “Vähenda”. Ilmuvas aknas määrake kuupäev, milleks kõik kirjed tuleb kustutada. Kustutatud kirjeid saab igaks juhuks faili salvestada.

Kui sageli teie ettevõte vajab näha kes muutis 1C dokumenti?

Või kuidas teada saada kumb töötajatest muutis ühte või teist rekvisiiti   Dokument 1s 8?

Kuidas vaadata 1C dokumendi muutuste ajalugu?

Moodul “Muutuste ajalugu” põhineb 1C 8

Mugav ja kiire instrument   analüüs ja kontroll   kasutaja toimingud 1C.

Mooduli lahendatud ülesanded “Muudatuste ajalugu”   1C 8:

• Erand võimalus   pettus   dokumentide tagasiulatuvad kasutajad;
• Süüdlase tuvastamine ekslikud andmed   dokumentidesse;
• Identifitseerimisvõime programmi talitlushäired   dokumentide automaatse muutmise või uuesti esitamise osas;
• Identifitseerimine andmete tahtlik moonutamine (muutmine)näiteks ebaausate klientide kontaktteabe sisestamine hoolimatute juhtide poolt;
• Võimalus   vaata, mis juhtus   enne selle muutmist dokumendi või kataloogiga ja vajadusel tagastage kõik tagasi.

Mehhanismi eelised “Muudatuste ajalugu”   1C 8:

• Kõik andmed salvestatakse 1C andmebaasi, mis tagab   suur otsingukiirus   vajalik teave ja vajalike aruannete koostamine.
• Moodul 1C 8 “Muudatuste ajalugu” avaldab jõudlusele minimaalset mõju. Meie alamsüsteemiga ja ilma selleta töötades te praktiliselt vahet ei tunne.
• Moodul   universaalne   ja lihtne integreerida   mis tahes, isegi standardses süsteemipõhises konfiguratsioonis « 1C: ettevõte   versioon 8.2   ja versioonid 8.3 koos versiooniga.

Mooduli omadused:

Moodul võimaldab teil paindlikult konfigureerida objekte, mille üle juhtimine toimub.

Andmemuudatuste ajaloo vaatamine on võimalik otse dokumendi- või kataloogivormist ja see on saadaval kasutajatele, kellel on vastavad õigused.

Juhtimismehhanismi kuuluvad muudatused kataloogide ja dokumentide üksikasjades. Samal ajal säilitatakse rekvisiitide nii vana kui ka uus väärtus.

1C dokumentide ridade muutuste juhtimise mehhanism on saadaval. Näiteks kuvatakse konkreetsel real muutused hindades, kogustes ja muudes andmetes.

Dokumentide tabeli osades on võimalus näha kustutatud ja lisatud ridu. Sellisel juhul ignoreerib programm dokumendis ridade sorteerimise muutust, mis tegelikult ei ole andmete muutumine. Selguse huvides on muudetud andmete aruandes lisatud read sinised ja kustutatud roosad.

Registreerimispäevik 1C 8.

Kuidas teada saada, kes muutis 1C dokumenti?

Näib, et kõik on lihtne - näete, kes muutis 1C dokumenti "Registreerimisajakiri". Tõepoolest, see salvestab andmebaasi objektide muutustega seotud sündmusi, samuti andmebaasiga töötades aset leidvaid sündmusi (kasutaja sisend ja väljund, vead, aruandlus). Nii et ajakirja saab väga palju lisakirjeid, mille tõttu ajakirja maht kasvab kiiresti ja kellel on probleeme   ja ajakirja säilitamisega ning otsides selles tõesti kasulikku ja vajalikku teavet.

Aga tavalise ajakirja suurim miinus   registreerimine- võimetus välja selgitada, mida objektis täpselt muudeti: tabeli osas olev rekvisiit või rida - vastust te ei leia. Ja kindlasti ei tea te, millised andmed olid enne muudatust ja mis said pärast seda.

Samuti pole sisseehitatud logi võimalik seadistada nii, et avatud dokumendist või kataloogist oleks ühe nupuvajutusega näha kogu 1C 8 muudatuste ajalugu .Sellised manipulatsioonid nõuavad ettevalmistamata kasutaja jaoks üsna keerulist, logide valikute seadistamist.

Moodul   “Muudatuste ajalugu”   - See on mugav ja toimiv tööriist 1C kasutajate tegevuse analüüsimiseks ja jälgimiseks.

Et Moodul "Muutuste ajalugu" 1C 8 hakkas oma tööd tegema, see tuleb korra üles seada. Seadistamine ei nõua palju aega ning hõlmab dokumentide, kataloogide ja nende üksikasjade valimist, mida jälgitakse ja talletatakse muudatuste ajalugu.

Mooduli hind sõltub selle paigaldamise ja konfigureerimise teenuste vajadusest. Koos võtke meiega igal sobival viisil ühendust ja saate teada maksumuse.

See artikkel on teadaanne uue funktsionaalsuse kohta.
   Uute funktsioonide õppimiseks ei ole soovitatav selle artikli sisu kasutada.
   Uue funktsiooni täielik kirjeldus antakse vastava versiooni dokumentatsioonis.
   Uue versiooni muudatuste täielik loetelu on esitatud failis v8Update.htm.

Rakendatud versioonis 8.3.11.2867.

Oleme juurutanud uue mehhanismi, andmete ajalugu, mis salvestab kompaktselt kasutajate rakenduste andmete muutuste ajaloo. Kasutades valmis liideselahendusi või sisseehitatud keelt, saate nüüd andmete muutusi paindlikult analüüsida, erinevaid versioone võrrelda ja taastada andmed olekusse, mis neil oli valitud versioonis.

Milliseid stsenaariume peate andmeajalooga töötama

Enamasti on andmete muutmiseks vaja juurdepääsu andmeajaloole. Näiteks müüdi toodet vastaspoolele liiga suure allahindlusega ja nüüd tahan aru saada, kes sellise allahindluse kehtestas. Või teine \u200b\u200bolukord, kus kauba hind tundub õige, kuid varem oli selle toote müük madalama hinnaga. Peate välja selgitama, kes hinda muutis ja seejärel selle tagasi oma eelmisele väärtusele.

Teine olukord, kus on vaja andmete ajalugu, on see, et hetkel on raamatupidamissüsteemis teatud atribuudi väärtus seatud selliselt, et see tooks kaasa negatiivseid tagajärgi. On vaja välja selgitada, millal see väärtus täpselt installiti ja milline kasutaja selle installis.

Olukorra edasiseks analüüsimiseks peate võib-olla välja selgitama kõik muudatused, mille tegi mõni konkreetne kasutaja, kes tegi kunagi midagi valesti. Sest muudel juhtudel oleks ta võinud sarnase vea teha.

Lõpuks, pärast kõigi sobimatute muudatuste leidmist, võib tekkida loomulik soov taastada andmete eelmine, korrektne olek või taastada isegi otse kustutatud andmed.

Kõigis neis stsenaariumides soovin, et need funktsioonid saavutataks minimaalse jõudluse ja kettaruumi kaotamisega.

Nii et ei selgu, et objektide muutuste ajalugu võtab rohkem ruumi kui kasulikud objektid, millega töötate. Või nii, et ei õnnestu välja mõelda, et selle funktsiooni pakkumine viib kasutajakogemuse olulise aeglustumiseni.

On selge, et jõudluskadusid pole võimalik täielikult eemaldada, kuna ühe toimingu asemel peate tegema kaks: salvestage objekt ja salvestage ikkagi selle ajalugu. Kuid samal ajal tahan, et need kaotused oleksid märkamatud.

On veel üks funktsioon, mis pole seotud funktsionaalsuse ja mitte tehniliste nõuetega, vaid 1C: ettevõtte turu eripäradega. Võite välja pakkuda väga hea mehhanismi, mis töötab kiiresti ja funktsionaalsus on suurepärane. Kuid kui selle konfigureerimiseks, lubamiseks ja hooldamiseks on vaja olulisi tehnilisi teadmisi, võib see kaotada kõik selle eelised.

Seetõttu ei tohiks sellise mehhanismi haldamine olla keeruline nii teabebaasi arendajale kui ka haldajale. Tõepoolest, väikestes failide juurutamistes on administraator sageli üks kasutajatest ja mõnikord selle rakenduse lahenduse ainus kasutaja.

Millised võimalused ajaloo analüüsimiseks on platvormil juba olemas

Peamine tööriist, mille abil saate süsteemis toimuvat analüüsida, on logiraamat. Muu hulgas registreerib see andmete muutuste fakte. See tähendab, et saate teada, kes ja millal objekti andmeid muutis. Kuid tema võimalused arutatavas piirkonnas lõpevad sellega, sest registreerimislogi järgi on võimatu täpselt aru saada, milliseid rekvisiite muudeti, milline oli tema eelmine olek. Ja veelgi enam, rekvisiitide või kogu objekti eelmist olekut on registreerimislogi abil võimatu taastada.

Teine tööriist, mis on pikka aega eksisteerinud ja on kõigis ringluslahendustes, on BSP - standardsete alamsüsteemide raamatukogu. Sellel on objektide versioonimise alamsüsteem. See alamsüsteem sisaldab kõiki loetletud funktsioone, kuid sellel on mõned praktilised piirangud.

Esiteks on see raamatukogu osa, nii et selle rakendamine rakenduselahenduses nõuab kvalifitseeritud arendaja osalemist. On hea, kui BSP on rakenduse lahenduses algselt olemas. Kuid kui seda seal pole, ei saa administraator või eriti kvalifitseeritud kasutaja seda iseseisvalt rakendada.

Teiseks on andmete ajaloo säilitamise ülesanne ise madala taseme ülesanne ja seda on tõhusam lahendada platvormi tehnoloogilises kihis.

Platvormi eelised

Kui analüüsisime hetkeolukorda, BSP kasutamise kogemust, kaalusime plusse ja miinuseid, jõudsime järeldusele, et kõige tõhusam lahendus oleks andmeajaloo rakendamine tehnoloogilises platvormis endas. Sellega saavutatakse järgmised eelised:

• Selle mehhanismi kasutamiseks ei pea administraator ega kasutaja konfiguratsiooni muutma, kõik vajalik on juba platvormis. Peate selle lihtsalt sisse lülitama.
• See mehhanism töötab kiiremini kui konfiguratsiooni osana rakendatud analoogid, näiteks ta kasutab funktsioone, mis pole sisseehitatud keeles saadaval.
• Andmeajalugu ise võtab vähem ruumi, kuna andmete koopiaid ei salvestata, vaid ainult nende erinevus eelmise versiooniga. Lisaks ei saa versioonimist ise rakendada kõigi üksikasjade suhtes, vaid ainult nende jaoks, mis pakuvad huvi. See annab ka täiendavat kokkuhoidu.
• Võimalik on toetada mitte ainult unikaalse viitega objektide (kataloogid, dokumendid jne), vaid ka objektideta üksuste, näiteks inforegistrite kirjete, versioonide versioonimist.

Mehhanismi põhitõed

Andmeajaloo mehhanism on platvormis täielikult rakendatud, see ei vaja lisatarkvara installimist, on igal ajal töövalmis, kuid vaikimisi pole sisse lülitatud.

Saate selle lubada nii konfiguraatoris kui ka režiimis 1C: Enterprise. Konfiguraatoris saab seda teha arendaja režiimis 1C: Ettevõtte kasutaja, kasutades manustatud keeles kirjutatud töötlemist.

Mehhanismi kaasamine näitab, milliste konkreetsete konfiguratsiooniobjektide puhul muudatuste ajalugu hoitakse. Lisaks saab ajalugu lisada mitte ainult kogu objektile, vaid ka selle üksikutele komponentidele: detailidele, mõõtmistele, ressurssidele. Sealhulgas tabeli osade üksikasjad. Seega saate valida: kas salvestada täielikku teavet või säästa ruumi.

Rakendasime kataloogide, dokumentide, ülesannete, äriprotsesside ja inforegistrite ajaloo säilitamise. Võib-olla laiendame tulevikus seda nimekirja.

Salvestame ajaloolisi andmeid infoobaasi eraldi tabelites. Tõhususe huvides salvestame ainult andmete versioonide erinevuse. Kui teil on „raske” dokument, mille tabeliosas on palju ridu, ja muudate dokumendis endas ainult ühte atribuuti, siis ainult see muudatus salvestatakse andmete ajalukku. See tähendab, et teid ei salvestata selle objekti palju koopiaid ja see võtab ruumi kettaruumi.

Lisaks andmemuutustele salvestame versiooni kirjutamise ajal ka objektide metaandmeid. See on vajalik selleks, et õigesti koostada aruandeid objektide kohta, mis salvestati erinevas konfiguratsiooni olekus. Näiteks kui mõnda detaili nimetati erinevalt, siis muid detaile polnud ja teised olid alles, kuid hiljem kustutati.

Andmete muutmise töötlemine

Andmeversiooni loomise protsess koosneb kahest etapist. Esiteks, objekti (näiteks dokumendi) salvestamisel genereeritakse spetsiaalne teade, mis pannakse järjekorda. Seda etappi täidab platvorm, arendaja pole sellega seotud.

Kuid teise etapi algatab arendaja. Teine etapp on see, et järjekorra töötlemisel need andmed ekstraheeritakse, asetatakse versioonipoodi ja need saavad nendega töötamiseks kättesaadavaks.

Järjekorra sellisel viisil töötlemiseks on andmeajaloo haldur ( ManagerData lood) on olemas meetod Värskenda ajalugu (). Eeldame, et kasutate seda samamoodi nagu täistekstiotsingu indeksi värskendamiseks mõeldud sarnast meetodit. See tähendab, et värskendate ajalugu teatud ajastatud toiminguga, mis viiakse läbi teatud sagedusega.

Usume, et sellise asünkroonse töö tulemusel tagatakse nii objektide tõhus salvestamine kui ka jõudluskadude minimeerimine.

Kasutajaliides

1C: Enterprise kasutajaliideses nimetatakse uut mehhanismi Muutuste ajalugu. See sisaldab mitmeid vorme, mis võimaldavad teil teostada toiminguid, mis olid loetletud selle artikli alguses.

Konkreetse objekti versioonide loend

Kui objekti ajaloo salvestamine on lubatud, ilmub objekti tavakäskude hulka uus käsk Muutuste ajalugu.

See võimaldab teil näha objekti kõigi muudatuste (versioonide) loendit.

Veerus Allikas muutused   vahetusplaani sõlme võidakse näidata ka juhul, kui sõlmes tehti muudatus ja andmevahetuse tulemusel sellesse andmebaasi “saabuti”.

Selle loendi veerus