1c 8.3 distribuované informační databáze. Budování RDB od nuly. Základní principy RIB

25. října 2016

Není velký rozdíl mezi konfigurací a údržbou RIB pro 2 uzly a pro 10, ale když počet vzdálených bodů přesáhne stovku, je třeba řešit úplně jiné problémy.

Počáteční údaje:

Konfigurace: Maloobchod 2.2
Nástupiště 1C: 8.3.7.1970

Termín projektu: roč.

Architektura:

Nejprve jsme se rozhodli pro schéma RIB. Bylo rozhodnuto soustředit se na hvězdné schéma co nejdéle; při dosažení technologických limitů - sněhová vločka.

Omezení:
- 2 GB RAM
- 1 fyzický procesor

Ze všeho výše uvedeného zatěžuje především omezení maximální velikosti databáze.

To ale znamená pouze to, že je nutné zorganizovat postup čištění od zastaralých dat v terénu.

Pro 1C a MS SQL server je přidělen samostatný fyzický server. Ponese hlavní břemeno burz a dlouhodobého provozu.
Koncové klientské počítače se nevyměňují, protože budou pracovat s tenkým klientem a zátěž na nich bude minimální.
.

základní nastavení

Od dob UT 10.3, na kterém jsem měl svůj první projekt zavedení RIB na 60 uzlů, samozřejmě „pod mostem proteklo hodně vody“.

1C nestál na místě. Retail 2.2 nyní zohledňuje potřebu selektivního nahrávání dat.
Do databáze obchodu budou nahrány pouze informace, které jsou relevantní pro obchod:
- Všechny referenční knihy (kromě specializovaných)
- Dokumenty pro tento obchod

Další otázkou je, že tak či onak přidání uzlu do báze znamená přidání dalšího záznamu do registrační tabulky pro každý společný prvek, když je zaznamenán.

1) Měl by být rozdělen do samostatných synchronizačních skriptů pro nahrávání a stahování
Jde o to, že nahrávání trvá dlouho a se zámky a stahování je celkem bezproblémové. Často se přitom stává, že potřebujeme rychle přijímat data z maloobchodních prodejen, přičemž je vracíme jen párkrát za den.

2) Vyberte úložiště problémů a odeberte je z obecného scénáře synchronizace. Mohou mít velké vykládání – v tomto případě bude zpomalena celá ústředna včetně dalších uzlů. Po vyřešení problémů jsou vráceny zpět.

3) Vytvořte několik scénářů pro odesílání a přijímání dat. Zde je ale hlavní chytit správnou rovnováhu jejich počtu.
(od verze 8.1).
V důsledku toho je paralelismus při vykládání RIB omezený. V praxi se ukazuje, že paralelně běží 2-3 skripty.

Co bylo třeba dokončit

Nejdůležitější zárubní ve standardní logice 1C RIB jsou aktualizace

Dalším problémem výměny jsou informační registry. Vyprázdněním každého záznamu informačního registru do XML se vytvoří samostatný uzel XML s prvky služby atd. Kromě toho funkce „SelectChanges ()“ pro registr informací, ve kterém 100 záznamů obdrží výsledkovou tabulku o 100 řádcích, současně, pokud se jedná o adresář se 100 řádky v tabulkové části, bude vybrán pouze jeden záznam. A to je doba exkluzivního blokování. Pokud je tedy v PC mnoho záznamů, které se pravidelně evidují k výměně v jiných obchodech, pak je jistě správné prezentovat je ve formě referenční knihy s tabulkovou částí, která v extrémních případech může při evidenci tvořit řádky stejného registru. Tak jako tak, .

Dalším důležitým detailem je za co? Slevových karet se již nashromáždilo téměř 3 mil. Pro práci s nimi je využíván externí online systém. Pokud budete nadále převádět slevové karty do všech obchodů, výrazně se tím zvýší výměny, navíc to může vést k překročení základního objemu 10 GB.

Některé z mechanismů jsou implementovány online kontaktováním centrální databáze: zůstatky v jiných prodejnách, vrácení šekem z jiné prodejny, kontrola platnosti dárkového certifikátu.

Zdvojení

Vytvoření počátečního uzlu RIB běžným způsobem by replikaci v zásadě znemožnilo.
Proto se nový uzel vytvoří následovně:

2) Tato databáze vyměňuje všechna obecná data v RIB, ale nepřijímá specializované (dokumenty)

5) Základ pro obchod je připraven.

Na server je nasazen hotový softwarový balíček, takže to nezabere mnoho času. Poté se nově vytvořená databáze nahraje na server a je připravena k odeslání do obchodu.

Výhody tenkého klienta

Dvě významné výhody Retail 2.2 (Thin Client), které „zahřály duši“:

Podpora a aktualizace

1) Aktualizace rukama obchodů (nepříliš správná, nemusí přijímat změny, budou hovory a problémy) - jako tomu bylo dříve

3) Napište * .cmd nebo 1C skript pro aktualizaci nebo si vezměte hotový skript. Jak ukazuje praxe, takové řešení je vždy poloviční (nestabilní) a bude možné do něj položit trochu funkčnosti.

Jaké jsme měli úkoly:

2) Při aktualizaci je možná interaktivní interakce s uživatelem (zprávy, potvrzení, ukazatel průběhu).

Hlavní funkce:

4) Kontrola stavu agentů
5) Aktualizujte zprávy
6) záloha

Například takto vypadá chybová zpráva po aktualizaci:

Projekt tak má velkou šanci na úspěšné dokončení. Alespoň v polovině cesty "normální let".

Pokud dojdeme k dalším řešením, která se mohou zdát zajímavá, napíšu samostatně

P.S. a hlavně: Správné plánování další podpory je jedním z klíčových faktorů dalšího úspěchu takových projektů. :)

25. října 2016

Není velký rozdíl mezi konfigurací a údržbou RIB pro 2 uzly a pro 10, ale když počet vzdálených bodů přesáhne stovku, je třeba vyřešit úplně jiné problémy.

Takže prvotní údaje:

Konfigurace: Maloobchod 2.2
Nástupiště 1C: 8.3.7.1970
Odhadovaný počet uzlů na konci projektu: 200
Vybavení v centru: žádná významná omezení
Vybavení v bodě: diskutovaný problém.
Termín projektu: roč.

Architektura:

Nejprve jsme se rozhodli pro schéma RIB. Předtím bylo rozhodnuto zaměřit se na schéma „hvězdy“.
PROTI maloobchodní prodejny používá se verze klient-server práce s dedikovaným serverem pod kontrolou OS Windows.
Server 1C bude použit ve verzi „Server 1C MINI“ https://1c.ru/news/info.jsp?id=17577
DBMS server - MS SQL Express 2008 R2.

SQL Express 2008 R2 je zatím nejnovější verze této řady SQL Serveru.
Omezení:

2 GB RAM
- 1 fyzický procesor
- Maximální velikost databáze 10 GB

Ze všeho výše uvedeného je jistě nepříjemné omezení maximálního objemu databáze. Ale ve skutečnosti to znamená pouze to, že bude nutné zorganizovat postup čištění od zastaralých dat v terénu.

Pro 1C a MS SQL server je přidělen samostatný server. Hlavní břemeno směn a operací dopadne na něj.
Koncové klientské počítače se nevyměňují, protože budou pracovat s tenkým klientem a zátěž spodní části bude minimální.
Server v obchodě je pouze výkonný počítač. Předpokladem je ale přítomnost SSD disku – na kterém jsou umístěny databáze MS SQL.
Server také poskytne možnost provádět rutinní operace v noci a přístup k databázi obchodu bez přerušení práce.

základní nastavení

Od dob UT 10.3, na kterém jsem měl svůj první projekt zavedení RIB na 60 uzlů, samozřejmě "pod mostem proteklo hodně vody." 1C nestál na místě. Retail 2.2 nyní zohledňuje potřebu selektivního nahrávání dat.
Do databáze obchodu budou nahrány pouze informace související s nemiu:
- Všechny adresáře (kromě některých)
- Dokumenty o tomto magnazinu
Registrace dat probíhá podle registračních pravidel, vše co lze kešovat. Při registraci nejsou přesně pozorována významná zpoždění.
Další otázkou je, že tak či onak přidání uzlu do báze znamená přidání dalšího záznamu pro každý společný prvek pro všechny báze.

V samotném nastavení vykládky není nic konkrétního. Při nastavování scénářů synchronizace existují určité nuance:

1) Je nutné oddělit synchronizační skripty pro nahrávání a stahování do samostatných synchronizačních skriptů.
Jde o to, že nahrávání trvá dlouho a se zámky a stahování je celkem bezproblémové. Často se přitom stává, že potřebujeme rychle přijímat data z maloobchodních prodejen, přičemž je vracíme jen párkrát za den.

2) Vyberte úložiště problémů a odeberte je z obecného scénáře synchronizace. Mohou mít velké vykládání – v tomto případě se zpomalí celá výměna včetně dalších uzlů

3) Vytvořte několik skriptů pro odesílání a přijímání pro odesílání a přijímání dat. Ale hlavní je zde rovnováha.
Některé věci v 1C se nemění. Stejnou metodu "SelectChanges" lze provádět pouze postupně(od verze 8.1).
V důsledku toho je paralelismus při vykládání RIB omezený. V praxi je možné vyložit 2-3 scénáře najednou.
Co se týče scénáře příjmu - je zde možný mnohem větší paralelismus, pokud je to potřeba, samozřejmě.

Co bylo třeba dokončit

Samozřejmě je to smutné a smutné, ale musel jsem se do BSP důkladně dostat. Nejdůležitější zárubní ve standardní logice 1C jsou aktualizace... Po aktualizaci se zobrazí něco jako toto okno:

To vše se děje v monopolním režimu. Systém se mimo jiné ještě pokusí provést výměnu po aktualizaci v exkluzivním režimu. K čemu to všechno vede, není těžké uhodnout.
Po celou tuto dobu nemůže obchod fungovat, zákazníci jsou u pokladny, firma přichází o peníze.

Dalším problémem výměny jsou informační registry. Vyjmutím každého záznamu registru informací v XML se vytvoří samostatný uzel XML s prvky služby a vším, co odtud plyne. Navíc funkce "vybrat změny" pro registr informací, ve kterém je 100 záznamů, výsledná tabulka bude obsahovat 100 řádků, zároveň pokud se jedná o adresář, ve kterém je 100 řádků v tabulkové části, bude pouze jeden záznam. být vybrán. Pokud je tedy v PC mnoho záznamů, které se pravidelně evidují k výměně v jiných obchodech, pak je jistě správné je prezentovat ve formě referenční knihy s tabulkovou částí, která v krajním případě může tvořit záznamy stejného registru při nahrávání. Tak jako tak, informační registry ve výměnách jsou zlo.

Dalším důležitým detailem je slevové karty jsou z výměny zcela vyloučeny a jednotlivci - pouze zaměstnanci konkrétního obchodu. za co? Slevových karet se již nashromáždilo téměř 3 mil. Pro práci s nimi je využíván externí online systém. Pokud budete nadále převádět slevové karty do všech obchodů, výrazně se tím zvýší výměny, navíc to může vést k překročení základního objemu 3GB.

Některé z mechanismů jsou implementovány online kontaktováním centrální databáze: zůstatky v jiných prodejnách, vrácení šeku z jiné prodejny, kontrola platnosti dárkového certifikátu.

Zdvojení

Replikace samozřejmě probíhá zrychleným tempem.
Vytvoření počátečního uzlu RIB běžným způsobem by samozřejmě znemožnilo replikaci.
Proto se nový uzel vytvoří následovně:

1) Existuje samostatná základna s falešným obchodem
2) Tato báze vyměňuje všechna obecná data v RIB, ale nepřijímá specializovaná
3) Když chceme tvořit nová základna- stačí zkopírovat toto
4) Poté nastavíme nastavení - store, prefix atp.
5) Základ pro obchod je připraven.

Na server je nasazen hotový softwarový balíček, takže to nezabere mnoho času. Poté se nově vytvořená databáze obchodu nahraje na server a je připravena k odeslání do obchodu.

Výhody tenkého klienta

dva výrazné benefity, které „zahřály na duši“.

1) Není potřeba měnit celý počítačový park v maloobchodních prodejnách. 90% operací se provádí na serveru a na server je přiveden "poměrně výkonný počítač"

2) Technika má schopnost odmítnout pracovat, zvláště často se to stává u nově nainstalovaných nebo již opotřebovaných zařízení.
V tomto případě jsou akce nyní extrémně jednoduché - obchod se přepne do práce v centrální základně.
Tento proces netrvá déle než 5-10 minut, takže obchodování není přerušeno ani při výrazných problémech s vybavením.

Podpora a aktualizace

Konečně jsme se dostali k tomu nejzajímavějšímu – jak toto vše udržovat a aktualizovat?
Pro nás jsou aktualizace již delší dobu problémem:

1) Aktualizace z rukou obchodů (nepříliš správná, nemusí přijímat změny, dojde k hovorům a problémům)
2) Obnova silami technická podpora(ne tolik zdrojů)
3) Napište * .cmd pro aktualizaci nebo si vezměte připravený. Jak ukazuje praxe, takové řešení je vždy polovičaté (nestabilní) a je v něm málo funkčnosti.

Jaké jsme měli úkoly:

1) Aktualizace by měla probíhat v několika režimech a měla by být spravována centrálně
2) Při aktualizaci je možná interaktivní interakce s uživatelem.
3) Ujistěte se, že budete dostávat zprávy o stavu a aktualizace chyb
4) Musí existovat záloha
5) Aktualizační systém by se měl bez problémů sám aktualizovat.
6) Systém by měl být bez problémů rozšiřitelný.

Úkoly samozřejmě dalece přesahovaly výčet řešitelných jednoduché metody... Protože automatizace s tolika koncovými body je nepostradatelná a nenašli jsme nic více či méně připraveného s podobnou funkčností
Musel jsem začít vyvíjet software, který nakonec získal jméno MU (MagicUpdater).

Hlavní funkce:

1) Dynamická aktualizace databáze (příkaz nebo plán)
2) Statická základní aktualizace (příkaz nebo plán)
3) automatické agenty na cílových počítačích, když jsou upraveny
4) Kontrola stavu agentů
5) Aktualizujte zprávy
6) zálohování
7) Administrativní akce se serverem 1C a MS SQL
8) Uzavření všech klientských aplikací 1C na počítačích v síti
9) Statická aktualizace s přijetím na hlavní pokladně
10) Zobrazení popisu úprav po aktualizaci
11) Konfigurace pořadí akcí
12) Provádění všech těchto akcí podle plánu

Přibližná schémata interakce:

Kde MU Agent je služba nainstalovaná a nakonfigurovaná v obchodě. Ve skutečnosti dostává z centra příkaz k provedení určitých úkolů.
Server MU - Server, který přijímá všechny požadavky do systému.
Monitor MU - to, co vidí běžní zaměstnanci technické podpory - slouží k prohlížení logů a nastavení úkolů pro aktualizaci, případně další.

Dopadlo to podle mě docela dobře. Nyní aktualizace probíhají téměř v automatický režim.
Takto vypadá například chybová hláška poté, co aktualizace zůstala v centru, vše čeká.

Takto posíláme příkazy do klientských počítačů.

Aplikace rozhodně nejsou 1C, ale s poměrně slušnou sadou možností rozhraní. Například takto vypadá výběr podle data:

Nyní jsme připraveni na další replikaci. Správné plánování další podpory je jedním z klíčových faktorů pro další úspěch takových projektů.

Vytvoření a konfigurace distribuované databáze (RIB) v 1C 8.3 Účetnictví (a další konfigurace) je nutné v případech, kdy není možné pracovat pro více uživatelů při současném připojení k jedné databázi. To je v dnešní době poměrně vzácné, protože standardní vzdálená plocha funguje skvěle a existují i jiné programy, které poskytují vzdálené připojení k centrálnímu počítači, kde je databáze umístěna.

Ale přesto jsou situace, kdy internet prostě není. A data by měla skončit v jedné infobázi. K tomu je vytvořena distribuovaná databáze.

Obvykle se hlavní základna nazývá centrální a zbytek se nazývá periferní. Základem je, že buď v manuálním nebo v automatickém režimu (podle nastavení) jsou databáze sloučeny do jedné. Aby se zabránilo duplikaci čísel nově zadaných dokumentů a kódů adresářů, je každé databázi přiřazen prefix.

V tomto tutoriálu použijeme příklad k vytvoření centrální a periferní databáze, zkontrolujeme výměnu mezi nimi. Tato příručka je vhodná pro 1C 8.3 Accounting a 1C Trade Management (UT) a další konfigurace.

Nastavení hlavní (centrální) distribuované databáze RIB

Pojďme do nabídky Správa 1C a poté přejděte na odkaz „Nastavení synchronizace dat“. V okně, které se otevře, zaškrtněte políčko „Synchronizace dat“. Aktivuje se odkaz "Synchronizace dat". Ihned zde nastavíme předponu pro hlavní infobázi – například „Centrální banka“:

Přejdeme na odkaz "Synchronizace dat", otevře se okno s tlačítkem "Konfigurovat synchronizaci dat". Po kliknutí na toto tlačítko se otevře rozevírací seznam, kde je třeba vybrat režim "Plný". Pokud potřebujete synchronizovat pouze jednu organizaci, musíte vybrat "Podle organizace ...".

V dalším okně nám program nabídne provedení zálohy. Důrazně to doporučuji udělat, protože následující kroky konfigurace mohou být nevratné.

Po vytvoření záloha stiskněte tlačítko "Další". V dalším kroku se musíme rozhodnout, jak bude synchronizace probíhat:

prostřednictvím místního adresáře nebo adresáře v místní síti;
přes internet přes FTP.

Pro jednoduchost a přehlednost příkladu vybereme lokální adresář. Uvedl jsem následující cestu: "D: \ Base 1C \ Synchronization". Nebude zbytečné kontrolovat záznam do tohoto adresáře, k tomu existuje speciální tlačítko:

Získejte zdarma výukové video 267 1C:

Přeskočte další kroky pro konfiguraci FTP a synchronizace e-mailu. Pozastavíme se u nastavení názvů hlavních a periferních databází. Zde nastavíme předponu pro periferní základnu:

Nezapomeňte, že předpony pro každou databázi musí být jedinečné. V opačném případě se zobrazí chyba "Hodnota předpony první infobáze není jedinečná."

Klikněte na "Další", zkontrolujte zadané informace a znovu klikněte na "Další" a poté - "Dokončit". V poli "Celý název základny souborů" zadejte soubor 1Cv8.1CD v adresáři, který byl vytvořen pro synchronizaci. Vytvoříme počáteční obraz distribuované databáze 1C:

Po vytvoření počátečního obrazu RIB v 1C můžete nastavit plán synchronizace nebo synchronizovat ručně:

Po synchronizaci se můžete připojit k nové databázi a ujistit se, že tam byly staženy informace z centrální databáze:

Stačí okamžitě spustit alespoň jednoho uživatele s právy správce v nové periferní základně.

Nastavení synchronizace v databázi periferií

V periferní základně 1C je nastavení mnohem jednodušší. Stačí zaškrtnout políčko „Synchronizace dat“ a přejít na stejnojmenný odkaz. A téměř okamžitě se ocitneme v okně s tlačítkem „Synchronizovat“. Zkusme vytvořit testovací nomenklaturu v periferní databázi a nahrát ji do hlavní pomocí RIB:

Komponenta URBD (Distributed Database Management) se používá, když je potřeba vyměňovat informace mezi dvěma nebo více stejnými informačními bázemi (dále - IB) přes úzký komunikační kanál (například modem, e-mail). Níže je uvedena instrukce krok za krokem a praktické rady o nastavení URBD v 1C: Enterprise 7.7. Je uveden příklad pro dvě informační bezpečnosti, i když není obtížné jej konfigurovat pro větší počet databází analogicky se dvěma databázemi.

Autor článku: romix | Redakce: evGenius
Poslední revize №7 z 22.02.08 | Dějiny
URL:

Klíčová slova: URBD, skript pro automatickou výměnu, výměna mezi pobočkami, pošta, rom-mail.dll, DialMail.dll, CDO, vytáčené připojení, URIB

Komponenta URBD (Distributed Database Management) se používá v případě potřeby výměny informací mezi dvěma stejnými informačními bázemi (dále - IB) přes úzký komunikační kanál (například modem, e-mail). Níže je uveden podrobný návod a praktické rady k nastavení URBD v 1C: Enterprise 7.7. Je uveden příklad pro dvě informační bezpečnosti, i když není obtížné jej konfigurovat pro větší počet databází analogicky se dvěma databázemi.

1) Za provoz komponenty URBD je zodpovědná knihovna DistrDB.dll ve složce BIN programu 1C: Enterprise. Tato součást se kupuje a instaluje samostatně.

2) Pro příklad automatické výměny vytvoříme dvě infobáze, které umístíme do složek pojmenovaných c: \ 1c_base1 a c: \ 1c_base2. Vytvořte tyto složky a v každé z nich - podsložky s názvy CP a PC (latinskými písmeny)

3) Do složky c: \ 1c_base1 umístěte hotovou konfiguraci (například "Obchod a sklad"). Je však lepší trénovat na nejjednodušší informační bázi (obsahující například pouze jednu referenční knihu s několika záznamy). Je pro nás důležité, abychom se ujistili, že data skutečně migrují z jednoho zabezpečení informací do druhého v důsledku automatické výměny URBD, a to lze ukázat jak na komplexním, tak na nejjednodušším testovacím případu.

4) Zavřete všechna okna v Konfigurátoru a aktivujte položku nabídky "Administrace - Distribuovaný IS - Správa". Tato položka nabídky je dostupná, pokud složka BIN programu 1C: Enterprise obsahuje komponentu DistrDB.dll. Pokud má knihovna špatnou verzi nebo je poškozená, stačí přeinstalovat 1C: Enterprise přes aktuální instalaci - knihovna DistrDB.dll bude nahrazena její správnou verzí.

5) V okně, které se otevře, klikněte na tlačítko "Centrální IB". V okně požadavku zadejte kód nové infobáze (zadejte číslo 1) a její popis (například „Centrální IB“).

6) Zhasněte zobrazené varování o nevratnosti změn kliknutím na "OK" (níže je popsán nedokumentovaný způsob, jak v případě potřeby vrátit základnu do původního stavu).

7) Klepněte na tlačítko Nová periferie. IB". V okně požadavku zadejte kód 2 a popis - "Periferní IB".

8) Vyberte periferní základnu jediným kliknutím a stiskněte tlačítko „Konfigurovat“. automatická výměna“. V okně, které se otevře, změňte nastavením přepínače režim automatické výměny „Ruční“ na „Automatický“ a klikněte na tlačítko „OK“.

9) Klikněte na tlačítko Nahrát data. Zapamatujte si (do schránky) název nenačteného souboru "c: \ 1c_base1 \ CP \ 20.zip" - ještě se nám bude hodit. Klepněte na tlačítko OK. Na konci nahrávání 1C napíše „Nahrávání úspěšně dokončeno“.

10) Zavřete Konfigurátor a zadejte (rovněž v režimu Konfigurátor) složku (zatím prázdnou), kde má být umístěn druhý IB (v našem příkladu - c: \ 1c_base2). Označte, že databáze by měla být ve formátu DBF / CDX a klikněte na "OK".

11) Přejděte do položky nabídky Administrace - Distribuovaný IS - Správa. V odpovědi na otázku „Informační databáze nebyla nalezena. Chcete si stáhnout data?" klikněte na "Ano" a zadejte název nahrávaného souboru (v našem příkladu "c: \ 1c_base1 \ CP \ 20.zip") a klikněte na "OK". Na konci stahování 1C napíše „Stahování bylo úspěšně dokončeno“. Úspěšně jsme vytvořili Periferní IS stažením dat z Centrálního IS.

12) Změňte cokoli (například přidejte nový předmět referenční kniha) v jedné z informačních bází. Naším cílem je zajistit, aby se změny v jednom (jakémkoli) zabezpečení informací dostaly do jiného zabezpečení informací prostřednictvím automatické výměny. V každé základně střídavě používejte položky nabídky "Administrace" - "Bezpečnost distribuovaných informací" - "Automatická výměna". Nově se objevující unload soubory s příponou ZIP ve složkách CP a PC je nutné přesouvat (kopírovat) mezi infobázemi podle principu CP-> CP, PC-> PC (v reálných „polních“ podmínkách se to obvykle provádí pomocí E-mailem).

Tipy a recepty

1) Chcete-li změnit distribuovanou databázi na běžnou, odstraňte soubory 1SDBSET.DBF, 1SDWNLDS.DBF, 1SUPDTS.DBF a jejich odpovídající soubory * .CDX a také 1SSYSTEM.DBF. V podstatě stačí odstranit 1SSYSTEM.DBF. Poté musíte obnovit bod relevance spuštěním programu ve výhradním režimu. Tento trik je nezdokumentovaný (hádejte proč), ale přesto funguje.

2) Můžete změnit konfiguraci 1C, ale pouze v Centrálním IB. To je velmi pohodlné – změny v zabezpečení periferních informací se „rolují“ automaticky.

3) Pokud jste ztratili (například v důsledku chyby pošty) jedno nebo více nahrání – nebojte se, protože URBD je schopen takové situace sledovat a znovu se pokusit odeslat ztracená data při příští automatické výměně.

4) Běžná možnost odesílat poštu do 1C je implementována prostřednictvím rozhraní MAPI, když dojde k interakci s e-mailovým klientem (jako je Outlook). Moje rada - neztrácejte čas - s MAPI a všemožnými Outlucks se v praxi neustále objevují problémy, které vyžadují, aby vývojář "rychle projížděl" mezi větvemi. Ze stejného důvodu nedoporučuji používat přímé vytáčené připojení nebo FTP. Je lepší posílat poštu s externími součástmi, jako je rom-mail.dll nebo DialMail.dll.

Další možností je použití CDO
http://avb1c.narod.ru/?=a9
(c) avb, Hubička absurdna

5) Můžete si vzít program, který dokáže automaticky provést automatickou výměnu a odeslat uploadované soubory e-mailem zde:

Pokud správně nastavíte několik konstant ( poštovní adresy, hesla, docházka atd.), uživatel pouze poklepáním na zástupce spustí automatickou výměnu.

Program je implementován jako konfigurace 1C: Enterprise. Detailní popis obsažené v přiloženém souboru DOC.

6) Pokud potřebujete automaticky vytočit číslo vašeho ISP, použijte program E-Type Dialer. Ví, jak po úspěšném připojení spustit externí aplikace. Další možností je použití externí komponenty DialMail, která má prostředky pro práci s modemem (rada - předčíslí "p" v latině před číslem dává pulzní volbu, 9W před číslem - volání přes "devítku" a čekání na oznamovací tón atd.).

Poznámka: Windows XP má vestavěný dialer s názvem rasdial.exe. Klíče příkazový řádek:
rasdial.exe Položka Uživatelské heslo
Prvek rasdial.exe / ODPOJIT

7) Přednostně jsou provedeny změny v Centrálním IS. Upozorňujeme, že prefixy infobáze se používají v typických konfiguracích 1C (viz toto nastavení v Konstantách), aby se kódy položek katalogu a čísla dokumentů vytvořené v různých databázích neshodovaly a nebyla narušena jejich jedinečnost.

stručný popis

Počet instalací	neomezená	Použití s účetní složkou 7.7	Ano

Počet periferních databází	neomezená	Použití s komponentou Operativní účetnictví 7.7	Ano

Samostatný program	Ne	Použití s komponentou výpočtu 7.7	Ano

Typ bezpečnostního klíče	USB	Doprava v rámci Ruska je zahrnuta v ceně	Ano

Distribuční sada	Ano	Nákup funkcí	na aplikaci

Instalační manuál součástí	Ano

Proč potřebujete 1C: Enterprise 7.7. Správa distribuovaných informačních bází (1C URBD, 1C URIB)

Zkratky a zkratky: 1C URBD- Správa distribuovaných databází; 1C URIB- Správa distribuovaných informačních bází.

Další součást „Správa distribuovaných informačních bází“ – 1C URBD – 1C URIB – se používá k organizaci jednotného automatizovaného účetního systému v podnicích, které mají geograficky vzdálené divize (například centrála, prodejna, sklad atd.) není připojeno lokální sítí... Možnosti poskytované touto komponentou umožňují organizovat provoz distribuovaného informačního systému s neomezeným počtem autonomních periferních informačních bází.

Distribuovaná infobáze se skládá z jedné centrální a neomezeného počtu periferních infobází. V každé z infobází se zadávají nová data a ty stávající se nezávisle upravují. Konfigurace systému může být upravována nebo aktualizována výhradně v centrální informační základně. Pro synchronizaci dat mezi centrální a periferní infobází je nutné pravidelně přenášet změněná data. Přenosové soubory lze přenášet jakýmkoliv dostupné způsoby(na disketě, e-mailem atd.). Systém automaticky sleduje všechny změny dat a přenáší je v souladu s popsanými pravidly synchronizace.

Komponentu 1C URBD lze používat pouze s profesionálními verzemi systémových programů 1C: Enterprise 7.7.

Kolik kusů "1C: Enterprise 7.7. Distribuovaná správa infobáze" potřebujete koupit například pro centrálu a dva vzdálené sklady?

Komponenta "1C: Enterprise 7.7. Správa distribuovaných informačních bází" - 1C URBD - je nainstalována pro centrální informační základna. Jedna komponenta umožňuje synchronizovat neomezený počet periferních infobází. Například pro synchronizaci centrály a dvou vzdálených skladů je tedy vyžadována jedna kopie „1C: Enterprise 7.7. Distributed infobase management“.

V praxi často dochází k situacím, kdy jsou různé divize nebo pobočky geograficky umístěny na různých místech. Přitom data zadávaná do programu na vzdálených divizích se musí nějak dostat do centrály, aby bylo vedeno obecné účetnictví.

V současné době tento problémčasto řešeno poskytnutím geograficky vzdáleným zaměstnancům vzdálený přístup ke společné databázi. Lze to provést zveřejněním databáze na webovém serveru, přes vzdálenou plochu atd.

Takové situace však nejsou neobvyklé, když v geograficky vzdálené kanceláři prostě není internet nebo není dostatečně stabilní, aby fungovala ve společné informační základně. Za tímto účelem má 1C mechanismus pro konfiguraci distribuované databáze.

Jednoduše řečeno, hlavní základna se nachází v centrále. Vzdálené oddělení využívá podřízeného. Takových podřízených základen může být několik. Výsledkem je, že taková distribuovaná základna je spojena do jedné prostřednictvím synchronizace. Lze jej provádět jak v automatickém režimu podle plánu, tak ručně.

V tomto článku se budeme zabývat nastavením distribuované databáze pro 1C: Accounting 3.0. Navzdory tomu jsou pokyny vhodné pro většinu ostatních konfigurací 1C 8.3.

Poznámkaže všechny potřebné úpravy konfigurace by měly být prováděny pouze v hlavní databázi RIB. Během synchronizace se tyto změny přenesou na všechny podřízené základny a projeví se.

Hlavní informační základna

Při použití distribuované databáze spadá hlavní nastavení na hlavní databázi. Je třeba je vytvořit v sekci "Správa", jak je znázorněno na obrázku níže.

V okně, které se otevře, okamžitě zaškrtněte políčko „Synchronizace dat“. Ve spodní části zadejte předponu hlavního (aktuálního základu). Může mít až dva znaky. V našem případě bude předpona „BG“, protože máme na mysli, že toto RIB 1C „Oddělení účtů“.

Nyní můžete začít s nastavováním samotné synchronizace, konkrétně určením, se kterou databází (nebo databázemi) budou data vyměňována. Chcete-li to provést, postupujte podle hypertextového odkazu "Nastavení synchronizace dat". Bude k dispozici pro přechod, pouze pokud je zaškrtnuto políčko vlevo.

V okně, které se otevře, vyberte z nabídky položku „Úplné ...“. Umožní nám to specifikovat libovolnou informační základnu 1C pro synchronizaci.

V prvním okně pro připojení podřízené základny umístěné v geograficky vzdálené kanceláři vyberte příznak, že připojení bude provedeno prostřednictvím místního nebo síťového adresáře. V našem případě je to "D: \ DB \ InfoBase". Předem si také prověříme možnost do něj napsat.

Nezapomeňte zadat různé předpony pro různé základny. Faktem je, že při synchronizaci dat je pro data přetížená z každé databáze nastavena jiná předpona. Pokud jsou duplikovány, práce bude nesprávná, takže program vám tuto příležitost nedá.

Když vás program vyzve k vytvoření počátečního obrazu, vyberte tuto možnost. Tento postup bude nějakou dobu trvat, poté jej uložte do počítače pod názvem „1Cv8.1CD“.

Samotnou synchronizaci lze provádět jak automaticky podle harmonogramu, který si můžete sami nakonfigurovat, tak ručně. V druhém případě stačí kliknout na tlačítko „Synchronizovat“ ve vhodnou dobu pro vás.

podřízený uzel RIB

Počet nastavení provedených v podřízené základně je mnohem menší. Ve stejné sekci nastavte příznak "Synchronizace dat" a kliknutím na příslušný odkaz se zpřístupní tlačítko "Synchronizovat".

V rámci našeho příkladu byly do hlavní databáze přidány dvě položky nomenklatury: "Beam" a "Board". Po synchronizaci skončili v podřízené základně. Jak můžete vidět na obrázku níže, byla jim přiřazena předpona „BG“. Další dvě pozice ("Soustruh" a "Paleta") byly označeny prefixem "BP", protože byly zadány přímo v podřízené základně.

Poznámkaže číslování prvků je v našem případě end-to-end, ale pouze v rámci stejné předpony.