Bieži praksē ir situācijas, kad dažādas nodaļas vai filiāles ģeogrāfiski atrodas dažādās vietās. Tajā pašā laikā datiem, kas ievadīti programmā attālās nodaļās, kaut kādā veidā jānokļūst galvenajā birojā, lai tiktu uzturēta vispārīga uzskaite.

Šobrīd šī problēma nereti tiek risināta, nodrošinot ģeogrāfiski attāliem darbiniekiem attālinātu piekļuvi kopējai datubāzei. To var izdarīt, publicējot datubāzi tīmekļa serverī, izmantojot attālo darbvirsmu utt.

Taču neretas ir situācijas, kad ģeogrāfiski attālā birojā interneta vienkārši nav, vai arī tas nav pietiekami stabils, lai strādātu kopējā informācijas datubāzē. Šim nolūkam 1C ir mehānisms izplatītas datu bāzes izveidošanai.

Vienkārši sakot, galvenais birojs ir vieta, kur atrodas galvenā bāze. Attālā nodaļa izmanto padoto. Šādas vergu bāzes var būt vairākas. Rezultātā šāda izplatīta datu bāze tiek apvienota vienā, izmantojot sinhronizāciju. To var izdarīt vai nu automātiski saskaņā ar grafiku, vai manuāli.

Šajā rakstā mēs aplūkosim izplatītas datu bāzes iestatīšanu 1C: Grāmatvedība 3.0. Neskatoties uz to, instrukcijas ir piemērotas lielākajai daļai citu 1C 8.3 konfigurāciju.

Lūdzu, ņemiet vērā ka visas nepieciešamās konfigurācijas izmaiņas jāveic tikai galvenajā RIB datubāzē. Sinhronizācijas laikā šīs izmaiņas tiks pārsūtītas uz visām vergu datubāzēm un stāsies spēkā.

Galvenā informācijas bāze

Izmantojot izplatīto datu bāzi, galvenie iestatījumi attiecas uz galveno datu bāzi. Tie ir jāveic sadaļā “Administrēšana”, kā parādīts attēlā zemāk.

Atvērtajā logā nekavējoties atzīmējiet izvēles rūtiņu “Datu sinhronizācija”. Apakšā norādiet galvenās (pašreizējās datu bāzes) prefiksu. Tas var sastāvēt no ne vairāk kā divām rakstzīmēm. Mūsu gadījumā prefikss būs “BG”, jo mēs domājam, ka šis RIB 1C ir “Galvenā grāmatvedība”.

Tagad varat sākt pašas sinhronizācijas iestatīšanu, proti, norādīt, ar kuru datu bāzi (vai datu bāzēm) tiks veikta datu apmaiņa. Lai to izdarītu, sekojiet hipersaitei “Datu sinhronizācijas iestatījumi”. Tas būs pieejams navigācijai tikai tad, ja ir atzīmēta izvēles rūtiņa kreisajā pusē.

Atvērtajā logā izvēlnē atlasiet “Pilns...”. Tas ļaus mums norādīt jebkuru 1C informācijas bāzi sinhronizācijai.

Pirmajā pakārtotās datu bāzes savienošanas logā, kas atrodas ģeogrāfiski attālā birojā, atzīmējiet izvēles rūtiņu, ka savienojums tiks izveidots, izmantojot lokālo vai tīkla direktoriju. Mūsu gadījumā tas ir “D:\DB\InfoBase”. Mēs arī iepriekš pārbaudīsim, vai varat uz to rakstīt.

Noteikti norādiet dažādus prefiksus dažādām datu bāzēm. Fakts ir tāds, ka, sinhronizējot datus, no katras datu bāzes pārslogotajiem datiem tiek piešķirts savs prefikss. Ja tie tiks dublēti, darbs būs nepareizs, tāpēc programma jums nedos šo iespēju.

Kad programma piedāvā izveidot starta attēlu, atlasiet šo opciju. Šī procedūra prasīs kādu laiku, pēc tam saglabājiet to savā datorā ar nosaukumu “1Cv8.1CD”.

Sinhronizāciju var veikt automātiski saskaņā ar grafiku, ko varat iestatīt pats, vai manuāli. Otrajā gadījumā vienkārši noklikšķiniet uz pogas “Sinhronizēt” jums ērtā laikā.

RIB vergu mezgls

Vergu datu bāzē veikto iestatījumu skaits ir ievērojami mazāks. Tajā pašā sadaļā iestatiet karodziņu "Datu sinhronizācija" un, noklikšķinot uz atbilstošās saites, būs pieejama poga "Sinhronizēt".

Mūsu piemērā galvenajai datubāzei tika pievienoti divi vienumu vienumi: "Siju" un "Dēļa". Pēc sinhronizācijas tie nokļuva vergu datu bāzē. Kā redzams zemāk esošajā attēlā, tiem tika piešķirts prefikss "BG". Pārējām divām pozīcijām (“Virpa” un “Palete”) tiek piešķirts prefikss “BP”, jo tās tika izveidotas tieši pakārtotajā datu bāzē.

Lūdzu, ņemiet vērā ka elementu numerācija mūsu gadījumā ir nepārtraukta, bet tikai viena un tā paša prefiksa ietvaros.

Šis ir mans pirmais raksts, konstruktīva kritika ir apsveicama.

Mērķauditorija ir tie, kuri UBR sastopas pirmo reizi.

RDB uzdevumi

Pirmā lieta, ar ko jums jāsāk, ir atbilde uz jautājumu "Kāpēc mums ir nepieciešams RDB?" Ir daudzas iespējamās atbildes, jo īpaši:

1. Mums ir filiāles, kas darbojas atvienotās datubāzēs. Tagad mēs vēlamies, lai informācija starp tām tiktu sinhronizēta;
2. Mums ir filiāles, bet slodze uz datubāzi ir pārāk liela (tas nozīmē darījumu bloķēšanu, nevis datu bāzes apjomu) un tiešsaistes atbilstība (nejaukt ar aktualitāti dažās minūtēs, tiešsaistē ir tad, kad pēc katra darījuma dati tiek pārsūtīts uz otro mezglu) nav nepieciešami dati par filiālēm;
3. Mums ir filiāles, kurās notiek tikai datu ievade (piemēram, mazumtirdzniecības veikali), tāpēc varam būtiski samazināt centrālās datu bāzes slodzi;
4. Drošības apsvērumu dēļ vēlamies, lai filiālēm pat teorētiski (ar administratora paroli) nebūtu piekļuves svarīgiem datiem, piemēram, uzņēmuma bilancei.

Vienā gadījumā man bija aktuāls 2. un 4. jautājums, citā – 2. un 3. Pirmais punkts ir pārāk plašs un netiks aplūkots šī raksta ietvaros.

Labāk ir arī nekavējoties apsvērt apmaiņas failu transportēšanas problēmu, jo dažos gadījumos tas var uzlikt būtiskus ierobežojumus datu apmaiņas īstenošanai. Pirmkārt, jums ir jānosaka, kurās filiālēs tieši parādīsies RDB mezgli (parasti tās ir reģionālās filiāles). Tālāk mēs apsveram, kur vēl mēs vēlamies instalēt RDB mezglus un vai tiem ir nepieciešama tiešsaistes atbilstība. Piemēram, mazumtirdzniecības veikaliem ne vienmēr ir iespējams uzstādīt pat modemu, un bezvadu savienojuma uzstādīšana būs pārāk dārga. Šeit jums ir jāpieņem lēmums - iespējams, šis veikals var darboties bezsaistē un periodiski apmainīties ar centru (reizi dienā / reizi nedēļā), izmantojot fizisku datu nesēju, piemēram, zibatmiņu.

Dažos gadījumos apmaiņa, izmantojot fiziskos datu nesējus, nav iespējama, piemēram, šī ir ļoti attāla filiāle, kur ir būtiskas problēmas ar ātrgaitas sakaru izveidi. Šeit ir vērts aptuveni aprēķināt apmaiņas informācijas apjomu. Bieži vien, ja tas ir aktuāli reizi stundā vai vairākas reizes dienā, pietiek ar 32k modemu. Tomēr der atcerēties, ka līdz ar datu atjauninājumiem dažkārt nāksies sūtīt arī pašas konfigurācijas vai ārējo failu (drukātas veidlapas, preču fotogrāfijas) atjauninājumus, tāpēc ik pa laikam radīsies situācija, kad apmaiņas fails ievērojami palielinās sakarā ar šādiem atjauninājumiem.

Topoloģija

Kopumā mēs saņēmām šādus jautājumus, uz kuriem jāatbild:

1. Kurās nodaļās mēs garantējam RDB mezglu uzstādīšanu un vai tur ir iespējams ierīkot ātrgaitas kanālu;
2. Kurās nodaļās UBA bloka uzstādīšana nav nepieciešama?
3. Kuras nodaļas var atbilstoši strādāt vairāku stundu laikā;
4. Kuras nodaļas var strādāt bezsaistē (datu apmaiņa mazāk nekā 3-4 reizes dienā).

Atbildot uz šiem jautājumiem, mēs iegūstam aptuvenu mūsu RDB diagrammu. Lieliem uzņēmumiem parasti iznāk kaut kas līdzīgs šim:

1. attēls. Tipiska liela uzņēmuma RDB diagramma

Ja ar “Branch” mezgliem viss ir salīdzinoši skaidrs - tie ir lieli centri, kuriem nepieciešama automatizācija, tad “Store” mezgli nozīmē mezglu ar nopietnu datu ievades slodzi datu bāzē, kas ir jāatdala, lai samazinātu slodzi. Piemēram, veikals ar 50 kases aparātiem un dienas apgrozījumu vairāk nekā 10 000 vienību.

• Veikali - ievadiet datus par savu apgrozījumu un naudas plūsmu. Analītika ir virspusēja, tikai jūsu veikalam.
• Filiāles - neautomatizēto punktu datu ievade, grāmatvedība, algas un personāls, ražošana u.c. Analīze jūsu filiālē.
• Centrs - neautomatizēto filiāļu datu ievade. Uzņēmuma analīze kopumā.

Ir svarīgi saprast, kādiem nolūkiem datubāze tiks izmantota katrā mezglā. No mērķiem tiek veidoti īstenošanai nepieciešamie uzdevumi, piemēram:

• Filiāles redz savstarpējo norēķinu vēsturi ar viena otras darījuma partneriem;
• Veikali redz pārpalikušos preces visā uzņēmumā (vai tā daļā);
• Ienākumu/izdevumu, budžeta izpildes uc analīze ir redzama tikai jūsu nodaļas hierarhijā;
• Grāmatvedība, algu uzskaite un personāls ir redzami tikai jūsu paša nodaļas hierarhijā;
• Nomenklatūra, visas tās īpašības un raksturlielumi ir redzami visos RDB mezglos;
• Attiecībā uz departamentu hierarhiju visi dati plūst uz augšu, bet tiek filtrēti uz leju;
• Centrā ir pilnīgi visa informācija par uzņēmumu.

Uzdodot sev šādus jautājumus, var atbildēt uz grūtāko jautājumu – kādai informācijai, kur un kā jāplūst starp RDB mezgliem? Kāpēc visgrūtākais? Zinot, kuras datu kopas cirkulē starp mezgliem, varat skaidri saprast, kā “izgriezt” pašreizējo datu bāzi, lai dati paliktu loģiski konsekventi. Piemēram, datus par preču atlikumiem nevar atdalīt no datiem par kārtējām rezervēm.

Tagad, atkarībā no informācijas plūsmām, pārzīmēsim RDB diagrammu:

Ko mēs redzam 2. attēlā? Atbilstoši uzņēmuma nodaļu hierarhijai tika izveidota informācijas plūsmas topoloģija starp datu bāzes mezgliem. Ir pievienots arī mezgls “Centrs 2”, kāpēc? Ieviešot Star topoloģiju, centra slodze vienmēr ir lielāka nekā perifēro mezglu slodze, un bieži vien mezgla radītā slodze jau ir augsta. Mezglu “1. centrs” un “2. centrs” izmantošanas piemēri:

1. “Centrs 1” kalpo tikai datu konsolidācijai no citiem RDB mezgliem. Tam ir piekļuve tikai administratoram. "Centrs 2" kalpo galvenā biroja darbam;
2. “Centrs 1” kalpo galvenā biroja darbam. Tomēr mezglā “Centrs 2” tiek veiktas smagas analītiskās un testēšanas darbības, kas rada milzīgu slodzi datu bāzei; piemēram, secības atjaunošana, slēgto periodu atkārtota palaišana, kopsavilkuma pārskatu ģenerēšana visam uzņēmumam ilgākā laika periodā, analītikas ģenerēšana, kas izraisa izmaiņas datos;
3. “Centrs 1” kalpo galvenā biroja darbam. “Centrs 2” ir rezerves kopija neparedzētu situāciju gadījumā ātrai visa RDB atjaunošanai.

Apmaiņas īstenošana

Ir 2 RDB darbības iespējas:

1. Automātiski - notiek bez lietotāja iejaukšanās. Ārkārtas situāciju kontrole tiek uzticēta datu bāzes administratoram vai pieredzējušam lietotājam;
2. Manuāla - apmaiņa notiek tikai pēc lietotāja pieprasījuma.

Pēc manas pieredzes es vienmēr visas ieviešanas vadīju uz automātisko versiju. Ja radās problēmas ar apmaiņas failu transportēšanu (tīkla klātbūtne mezglā nav nemainīga), tad maksimālais, ko lietotājs varēja darīt, bija noklikšķināt uz pogas “Apmainīties tūlīt”. Situācijas, kad papildus datu atjaunināšanai ir arī konfigurācijas atjauninājums, to vēlams veikt arī pilnībā automātiski (piemēram, izmantojot trešās puses programmatūru).

Atjaunināšanas pakotņu ģenerēšana

Tā kā pastāv nepārprotams lēmums par to, kuriem RDB mezgliem tiek piešķirtas funkcijas, ir iespējams ģenerēt tikai šim mezglam nepieciešamo datu paketi. No vienas puses, ir jānorāda, kāda veida objekti tiks sinhronizēti starp mezgliem. Piemēram, mezgla “Veikals 1” uzskaites reģistrus vispār nevajadzētu sinhronizēt, jo Dati tiek ievadīti tikai filiāles mezgla līmenī. No otras puses, tie datu veidi, kuri ir pakļauti apmaiņai, ir jāfiltrē, atsaucoties uz nodaļu. Piemēram, dati par naudas saņemšanu no mezgla “Veikals 1 filiāle 2” var atrasties tikai mezglos “2. filiāle”, “Centrs 1” un “Centrs 2”.

Tomēr ir arī pretēja problēma: ja jūs pārāk daudz filtrējat apmaiņas datus, datu pakete zaudēs savu loģisko integritāti. Piemēram, preču atlikumi tiek ņemti vērā noliktavu kontekstā, bet rezerves tiek ņemtas vērā uzņēmuma kontekstā kopumā, tad, ja preču atlikumus filtrē pa noliktavām un nefiltrē rezerves, dati būs nepareizi.

Jums arī jāizlemj, kurā dzīves posmā objekts ir jāmaina. Piemēram, var apmainīt tikai izrakstītos rēķinus, bet ne vienkārši saglabātos. Vai nu veikala rēķini nekad netiek izlādēti no centra mezgla, pat pēc to koriģēšanas, taču ir jāņem vērā pretējais efekts - dati var būt nesinhronizēti, vai arī dažas izmaiņas var tikt pārrakstītas.

Ir svarīgi saprast, ka, veicot apmaiņu starp mezgliem, vienam no tiem ir prioritāte. Apsveriet situāciju:

1. Mezglā “Veikals 1” tika izveidots dokuments;
2. Apmaiņas laikā viņš nokļuva mezglā “Branch 1”;
3. Dokuments tiek labots vienlaicīgi abos mezglos.

Kurš dokuments tiks uzskatīts par patiesu? 1C 8.x, izmantojot “Apmaiņas plānu” mehānismu, noklusējuma prioritāte ir galvenais mezgls, t.i. šajā gadījumā mezglā “Veikals 1” veiktās izmaiņas tiks zaudētas un aizstātas ar datiem no mezgla “1. filiāle”.

Ir vēl viena, sarežģītāka situācija, kad vienlaicīgi tiek regulēti divi savienoti objekti. Piemēram, rēķins un tam paredzētais PQR tiek koriģēts dažādos mezglos, ja tiek mainītas cenas, maksājumu summas, darījumu partneri utt.

Svarīgi ir arī kontrolēt objektu dzēšanu, pretējā gadījumā tas var novest pie tā, ka, piemēram, rēķins vairs nepastāvēs, bet uzskaites kustības paliks.

Apmaiņas mehānismi 1C 8.x

Ir divas ieviešanas pieejas:

1. “Apmaiņas plānu” mehānisms;
2. Pašu objektu reģistrācijas realizācija.

Apsvērsim abus variantus.

Apmaiņas plānu mehānisms ļauj bez konfigurācijas dažu minūšu laikā izveidot datu bāzi ar pilnīgu datu apmaiņu. Ja iestatāt karogu “Distributed infobase”, tad, veidojot atjauninājumu pakotni, tiks lejupielādēti arī konfigurācijas atjauninājumi. Atverot apmaiņas plāna sastāvu, jūs varat iestatīt noteikumus, kas ļauj/aizliedz dažāda veida datu apmaiņu, tikai dažu minūšu laikā. Ja karogu “Automātiskā reģistrācija” iestatāt pozīcijā “Aizliegt”, šāda veida objekti nekad netiks apmainīti bez papildu piepūles.

Kāpēc nepieciešama reģistrācija, kāpēc gan neaugšupielādēt visu uzreiz? Jebkurā gadījumā fails, kurā ir tikai izmaiņas datu bāzes stāvoklī, būs mazāks nekā pilnīgs pašas datu bāzes momentuzņēmums. Tāpēc pilnīgas izkraušanas iespēja netiks izskatīta.

Kā iestatīt datu filtrēšanu pēc nodaļas piederības? Šeit jau būs jāprogrammē. Manā realizācijā uz jebkura objekta ieraksta tika uzstādīts notikuma “Rakstot” abonements, kur, izmantojot rekvizītu “Datu apmaiņa” var iestatīt šī objekta adresātu sarakstu. Tie. Izkraujot, izmantojot standarta līdzekļus mezglam, kas nav sarakstā, objekts netiks izkrauts. Ir arī cits risinājums - apmaiņas plāna moduļa procedūrās “Nosūtot datus padotajam” un “Nosūtot datus meistaram” var izvēlēties, vai objektu izkraut tieši, izkraujot objektu.

Abām iespējām ir tiesības pastāvēt. Taču es izvēlējos pirmo variantu kā labāko variantu, jo priekšielādējamības atribūta aprēķins notiek uzreiz pēc objekta ierakstīšanas, kas palielina objekta ierakstīšanas ilgumu par 3-5% (var optimizēt, atsevišķos gadījumos var jāsamazina līdz 0,01%), t.i. vidēji 0,1-0,3 sekundes, un gadījumā, ja tiek aprēķināta objekta izkraujamība tieši datu nosūtīšanas laikā, kas jau rada ievērojamu datu bāzes slodzi, šis laiks būs līdz pat vairākām minūtēm.

Lai pilnībā izprastu “Apmaiņas plānu” mehānisma darbību, iesaku izlasīt grāmatas “Profesionālā attīstība 1C:Enterprise 8 sistēmā” 15. nodaļu, Gabets A.P., Goncharov D.I.

Jebkura pati realizācija, manuprāt, vai nu atkārtos “Apmaiņas plānu” mehānismu, vai arī izlādēs objektu uzreiz mainot, vai arī izlādēs vairāk nekā “Apmaiņas plānu” mehānisms (piemēram, izlādēs visas izmaiņas uz šodienu). Es neuzskatu šo jautājumu ieviešanas pieredzes trūkuma dēļ.

Transports

Failu pārsūtīšanas uzdevums no galvenā uz pakārtoto mezglu tiek samazināts līdz maksimālajai kļūdu pielaidei. Nav nekas neparasts, ka faili tiek šifrēti vai pārsūtīti pa drošu kanālu. Lai pārsūtītu failus, ieteicams izmantot vairākus dažādus pakalpojumus vai sagatavot vairākas dažādas savienojuma iespējas. Piemēram, galvenā pārsūtīšanas metode ir FTP servera izmantošana, kas savienots, izmantojot VPN tuneli; Rezerves serveris ir e-pasta serveris ar TLS savienojumu. Kāpēc jums ir nepieciešams rezerves kanāls ar citu pakalpojumu? Kā liecina prakse, 2 dažādu FTP serveru izmantošana ir mazāk uzticama nekā FTP servera un e-pasta izmantošana.

Atjaunināšanas pakotnes izveides servisu iesaku atdalīt no transporta servisa, tas palielinās visa datu apmaiņas kompleksa kļūdu toleranci. Ja failu transportēšanas pakalpojums nedarbojas, atjauninājumu pakotņu izveides pakalpojums turpinās darboties kā parasti un noteiktos apstākļos restartēs transporta pakalpojumu un otrādi.

Mana RDB ieviešana

Ieviešana ir pilnīgi autonoma, tāpēc maksimāla kļūdu tolerance bija apakšuzdevums. Tā rezultātā tika izveidoti 2 pakalpojumi - atjaunināšanas transporta pakalpojums un datu importēšanas/eksportēšanas pakalpojums. Abi pakalpojumi darbojas neatkarīgi viens no otra.

Pēc katra veiksmīga datu importēšanas-eksportēšanas cikla tika saglabāts pēdējās apmaiņas laiks ar šo mezglu. Ja apmaiņa nenotika ļoti ilgu laiku, transporta dienests sāka augšupielādēt failus visos tam pieejamajos sakaru kanālos, cerot, ka otrais mezgls joprojām saņems atjauninājumus un augšupielādēs savus failus. Ārkārtas situāciju gadījumā sistēma pati nosūta administratoram ziņojumu ar detalizētu kļūdas aprakstu.

Lai samazinātu trafika apjomu, xml faili tika iesaiņoti zip arhīvos. Sistēma atbalsta divus transporta veidus – FTP un e-pastu.

Ir divas tabulas kā datu filtra iestatījumi. Viena (apmaiņas plānu tabulas daļa) glabā nosacījumus vispārīgām detaļām (katram objektam sistēma mēģina atrast šo detaļu), otrā satur iestatījumus konkrētam metadatu objektam. Ierakstot jebkuru objektu, vispirms tiek meklēti nosacījumi pēc vispārīgām detaļām (piemēram, Dalījums), pēc tam sistēma, izmantojot visas tā detaļas, mēģina noteikt, vai šāda veida objektam ir kāds personisks noteikums. Neiesaku filtrēt sarakstus - ir liela iespēja kļūdīties, piemēram, no rēķina tabulas daļas pazudīs vairākas rindas, un atlikusī atlikums pārvietosies un otrādi.

Ir svarīgi saprast, pie kura sistēmas lietotāja pakalpojumi darbosies, jo Jums var nebūt pietiekami daudz tiesību, lai izveidotu failus pat pagaidu mapē 1C. Lai veiktu atkļūdošanu, es ļoti iesaku katru veiksmīgi pabeigto darbību ierakstīt reģistrācijas žurnālā vai txt failā. 1C 8.1 servera koda izpildi nevar atkļūdot.

Atkļūdošanas un ieviešanas iestatīšanas ērtībai pievienoju apstrādi “Izmaiņu reģistrācija”, kuras apraksts ir pašā apstrādē.

Datu apmaiņas kompleksa vispārīgā darbības shēma parādīta 3. att.

Datu filtrēšana notiek katra objekta notikuma “BeforeRecording” abonementā. Neaizmirstiet, ka, veidojot sākotnējo mezgla attēlu, arī dati ir jāfiltrē. Sākotnējā attēla izveides procedūra ir diezgan ilga, tāpēc iesaku maksimāli optimizēt tā kodu (piemēram, kešatmiņas filtrēšanas iestatījumus).

Pēcvārds

Galvenais uzdevums ir atbildēt uz jautājumu sarakstu:

1. Kāpēc mums ir vajadzīgs RDB?
2. Kas nepatīk darbā ar LAP klientu?
3. Kur un kāpēc mēs vēlamies instalēt RDB mezglus?
4. Kā tiks pārsūtīti atjauninājumi?
5. Kāds defektu tolerances līmenis tiks ieviests?

Apstrāde "Izmaiņu reģistrācija"

Apstrāde ļauj piespiest izmaiņas reģistrētajos objektos. Ir vairākas izmaiņu reģistrēšanas iespējas:

1. Ja ir atzīmēti kādi metadati un nav atlasīts neviens objekts un NAV iestatīts karodziņš "Ielādēt pēc visām vērtībām", tad IR REĢISTRĒTA TIKAI IZVĒLĒTĀ TABULA;
2. Ja ir iestatīts karogs "Augšupielādēt visām vērtībām", atlasītie metadati tiks izlādēti visiem cikla objektiem;
3. Ja slēdzis ir iestatīts uz režīmu "Augšupielādēt tikai atlasītos objektus", tiks izlādēti tikai atlasītie objekti (piemēram: karoga iestatīšana metadatiem, neatlasot objektus, ir līdzvērtīga karoga "Augšupielādēt pēc visām vērtībām" un slēdža ieslēgšanai. pozīcijā "Izlādēt tikai atlasītos objektus";
4. Ja slēdzis ir iestatīts uz režīmu "Izlādēt atlasītos un tieši saistītos objektus", tad tiks izlādēti atlasītie objekti un tie objekti, kuru esamība ir atkarīga no izvēlētā objekta esamības (piemēram: direktorijiem - pakārtotie direktoriji);
5. Ja slēdzis ir iestatīts uz režīmu "Augšupielādēt, izmantojot visas saites", tiks izlādēti VISI objekti, kuros ir saite uz atlasīto objektu.

Pieejama papildu funkcionalitāte:

• Atkļūdošanai bieži ir nepieciešama reģistrēto objektu pārreģistrācija;
• Lai veiktu atkļūdošanu, bieži vien ir jānoņem reģistrētie;
• Drukāt izmaiņas - izdrukāt pilnu objektu sarakstu, kas atzīmēti kā mainīti;
• Konfigurācijas koka drukāšana ir paredzēta tikai visas konfigurācijas apskates ērtībai.

Šajā materiālā ir ietverti detalizēti norādījumi par RIB apmaiņas iestatīšanu 1C:Enterprise 8 un problēmas, ar kurām autors saskārās.

1. Mezglu izveide
Mēs izveidojam jaunus mezglus (galveno un pakārtoto): lietotāja režīmā "Operācijas / Apmaiņas plāni / Pilns"
Izvēlēsimies apmaiņas plānu "Pilns"
Mēs izveidojam divus ierakstus:
- pirmo ierakstu nosauksim par “CB” (galveno mezglu), norādiet kodu “CB”,
- sauksim otro ierakstu “Pakārtotais mezgls”, norādiet kodu “PU”.
Ikona ar zaļu apli - "CB" (galvenais mezgls)

Vergu mezglam noklikšķiniet uz ikonas “Izveidot sākotnējo attēlu”. (Nepieciešama ekskluzīva piekļuve)
Izveidojiet sākuma attēlu
Pēc tam atvērtajā logā aizpildiet jaunās datu bāzes parametrus. Kad esat pabeidzis, noklikšķiniet uz pogas "Pabeigt".
Sākotnējā informācijas drošības attēla izveide
Sāksies izplatītās informācijas bāzes pakārtotā mezgla sākotnējā attēla izveide, un pēc pabeigšanas parādīsies ziņojums “Sākotnējā attēla izveide ir veiksmīgi pabeigta”. Noklikšķiniet uz pogas "OK".
Mēs pievienojam vergu mezgla bāzi bāzu sarakstam un palaižam to.
Šajā pakārtotajā datu bāzē mēs atveram pilnu apmaiņas plānu - ikona “CB” ir sarkana, tas nozīmē, ka šis mezgls ir galvenais mezgls informācijas bāzei, kurā mēs atrodamies.

2. Prefiksu iestatīšana
Katrai datu bāzei uzskaites parametru iestatījumos (UPP "Pakalpojums / Grāmatvedības parametri") cilnē "Datu apmaiņa" mēs iestatām prefiksus. Tas tiek darīts, lai nebūtu pretrunu divās datu bāzēs izveidoto dokumentu un direktoriju numuriem un kodiem.
Automātiskajai apmaiņai atzīmējiet izvēles rūtiņu "Izmantot automātiskās maiņas mehānismu..."
Cilne "Datu apmaiņa"

3. Pievienojiet iestatījumu datu apmaiņai starp mezgliem
Atveriet: "Pakalpojums\Izplatītā informācijas bāze (RIB)\Configure RIB mezgli"
Noklikšķiniet uz "Pievienot" un tiks atvērts logs "Datu apmaiņas iestatījumi".
Datu apmaiņas iestatīšana

Noklikšķiniet uz ikonas "Mainīt atbilstoši pašreizējiem iestatījumiem".
Veiciet apmaiņu atbilstoši pašreizējam iestatījumam

Tagad par slazdiem
1. Datu apmaiņa var tikt veikta automātiski un var tikt uzsākta šādos gadījumos:
* Palaižot programmu. Apmaiņa tiks veikta, kad programma sāksies,
* Kad esat pabeidzis darbu ar programmu. Apmaiņa tiks veikta, pirms lietotājs pabeidz darbu ar programmu,
* Kad parādās katalogs. Apmaiņa tiks veikta tikai tad, ja lietotāja norādītais direktorijs bija neredzams, bet tagad kļuvis redzams. Iestatījumu var izmantot, lai veiktu automātisku apmaiņu, kad ir izveidots savienojums ar vietējo tīklu vai zibatmiņas karti. Programma periodiski pārbaudīs iestatījumos norādītā direktorija redzamību un atzīmēs tā pašreizējo stāvokli,
* Kad tiek parādīts fails. Ja parādās ienākošs datu apmaiņas fails, ieteicams izmantot datu režīmu, ja nepieciešams veikt apmaiņu. Šajā gadījumā pietiek norādīt pilnu ceļu uz ienākošo datu apmaiņas failu. Programma periodiski analizē faila klātbūtni, un, tiklīdz tas parādīsies, apmaiņa tiks veikta, un pēc apmaiņas šis fails tiks piespiedu kārtā DZĒST (tas tiek darīts, lai apmaiņas procedūra netiktu veikta pastāvīgi),
* Periodiska datu apmaiņa. Apmaiņa tiks veikta atbilstoši periodiskas datu apmaiņas iestatījumiem. Ja informācijas bāze darbojas failu servera režīmā, tad periodiskā apmaiņa tiek veikta tikai lietotājam, kurš grāmatvedības politikas iestatījumos ir norādīts kā “Lietotājs ikdienas uzdevumiem faila režīmā”. Klienta-servera versijā apmaiņa tiek veikta serverī 1C:Enterprise.

Man ir opcija Client-Server — lai rutīnas automātiskā apmaiņa darbotos, man bija jāpārslogo serveris

2. Windows kodējums.
Apmaiņa tika pārtraukta kļūdas dēļ, jo fails nebija saspiests. Tas ir saistīts ar kirilicas kļūdu komandrindā saspiešanas laikā.
To var apstrādāt, labojot kodējumus reģistrā.
Piemēram, operētājsistēmai Windows Server 2008 -
Kods

REGEDIT4
"1250"="c_1251.nls"
"1251"="c_1251.nls"
"1252"="c_1251.nls"
"1253"="c_1251.nls"
"1254"="c_1251.nls"
"1255"="c_1251.nls"

3. Veidojot datu bāzes kopiju (piemēram, modificēšanai) klients-servera versijā, NEPIECIEŠAMS, lai DATU BĀZES KOPIJAS REGULĀRAJIEM UZDEVUMIEM BŪTU IZSLĒGTS. Ieslēgts kopēšanas rutīnas uzdevumu bloķēšana

Ja tie nav bloķēti, kopija veiks apmaiņas pēc tāda paša grafika kā galvenā datu bāze. Tas nozīmē, ka daži ziņojumi attālajiem mezgliem tiks ģenerēti no darba datu bāzes, bet daži no kopijas, kas novedīs pie konfigurāciju desinhronizācijas.