V některých případech (například při velkém toku dokumentů nebo při složitém účtování) je pro koncového uživatele mnohem pohodlnější distribuovat účtování mezi několik aplikací a čas od času si mezi nimi vyměňovat data. Před vydáním platformy 1C verze 8.3 probíhala standardní výměna dat pouze na žádost uživatele prostřednictvím nahrávání a stahování informací pomocí souborů XML. V poslední době se stále více používá mechanismus synchronizace dat v 1C.

Existuje několik důvodů pro popularitu synchronizace:

• Není potřeba samostatně spouštět procesy načítání a vyjímání dat;
• Automatické provádění výměny informací nenarušuje manuální výměnu;
• Snadná konfigurace (u standardních konfigurací ani nemusíte vytvářet pravidla výměny;
• Stačí jednou vytvořit synchronizaci a deklarovat plán jejího provedení.

Podmínky našeho úkolu

Na vstupu máme dvě standardní konfigurace databáze:

1. Mzdový a personální management (verze 3.1.3);
2. Účetnictví pro zemědělský podnik (verze 3.0.52).

Obě databáze pracují v souborovém režimu. Synchronizaci lze konfigurovat z libovolné databáze.

Pokud bude synchronizace konfigurována z „Accounting“ na „ZUP“, musí být aktivováno zaškrtávací políčko „Synchronization“ a naopak.

Kde jsou nastavení

V „Účetnictví“ přejděte do podsystému „Správa“, v nabídce „Nastavení“ najděte položku „Synchronizace dat“ (obr. 1)

Otevře se okno nastavení synchronizace (obr. 2)

Rýže. 2

Zde můžeme:

1. Povolit nebo zakázat synchronizaci;
2. Zakázat načítání irelevantních dat;
3. Nastavte prefix pro identifikaci přenášených dat;
4. Přejděte na další nastavení synchronizace.

Spuštěním synchronizace zaškrtnutím příslušného políčka a definováním prefixu můžeme uzavřít účetní oddělení. Další práce budou provedeny v části „Plat“.

Okno nastavení synchronizace dat je znázorněno na Obr. 3

Rýže. 3

Pojďme se na to podívat blíže.

Okno nastavení synchronizace

Začněme popořadě:

Samostatně bych chtěl čtenáře upozornit na okno „Registrace změn“ (obr. 5). V horní části jsou čísla odeslaných a přijatých zpráv, po úspěšné výměně se musí čísla ve zdrojové a cílové databázi shodovat. V některých případech (proběhla synchronizace s kopií databáze, poruchy) je číslování v databázích porušeno. Tuto situaci můžete napravit jednoduchým kliknutím na hypertextový odkaz s čísly. Tato akce umožňuje ručně nastavit aktuální počet odeslaných a příchozích zpráv (obr. 6)

Rýže. 6

Nastavení synchronizace

Na kartě „Nastavení synchronizace dat“ jsou dva příkazy:

• Naladit;
• Pravidla ke stažení.

Spuštěním příkazu „Načíst pravidla“ se otevře formulář (obr. 7)

Rýže. 7

Zde si můžeme vybrat, zda budeme používat standardní výměnná pravidla dodaná v konfiguraci, nebo zda budeme synchronizovat podle vlastních pravidel uložených v archivním souboru.

Zbývající nastavení se provede kliknutím na tlačítko „Konfigurovat“ (obr. 8).

Rýže. 8

V prvním okně, které se otevře, můžete:

1. Otevřete konfigurační formulář synchronizačního skriptu;
2. Zobrazení událostí odesílání a přijímání informací;
3. Určete datum, od kterého bude výměna probíhat;
4. Pokud je účetnictví vedeno pro více organizací, můžete určit, která z nich se výměny zúčastní;
5. Definujte parametry pro nahrávání mzdových transakcí: s nebo bez detailu podle zaměstnance (souhrn).

Příkaz „Načíst sadu pravidel“ je podobný stejnému příkazu v předchozím okně nastavení.

Stojí za to se blíže podívat na parametry připojení (obr. 9)

Rýže. 9

V našem případě se cílová základna a zdrojová základna nacházejí na stejném počítači a pracují v režimu souborů, takže k synchronizaci mezi nimi dochází prostřednictvím přímého spojení.

Musíme:

• Určete cestu k přijímací základně;
• Nastavte parametry autorizace (v přijímající databázi musí být vytvořen uživatel s administrátorskými právy);
• Po kontrole připojení můžeme předpokládat, že naše nastavení je dokončeno.

Pokud k výměně dochází prostřednictvím jiných typů připojení, musíte nakonfigurovat jejich parametry na odpovídajících kartách.

Nastavení rozvrhu

A na závěr pár slov k nastavení plánu synchronizace, provádí se v příslušné záložce okna (obr. 3) a neliší se od odpovídajícího formuláře pro nastavení plánu pro ostatní rutinní úlohy.

Společnost 1C představila první verzi nového formátu pro výměnu obchodních dat EnterpriseData, který je založen na XML a má podle jeho autorů nejen sjednotit interakci aplikačních řešení a jejich jednotlivých komponent vytvářených samotnou společností, ale také být použit jako univerzální mechanismus pro integraci informací jakékoli obchodní aplikace na jakékoli softwarové platformě, samozřejmě včetně 1C:Enterprise.

Společnost dlouhodobě praktikuje tvorbu a používání otevřených standardů pro informační interakci svých aplikací se softwarem od nezávislých vývojářů, ale dosud se to týkalo jen některých specializovaných oborů. Přesně takový je formát CommerceML, vytvořený před téměř patnácti lety, pro řešení problému e-commerce, stejně jako „Client-Bank“ a DirectBank pro komunikaci mezi aplikacemi 1C a externími bankovními systémy. EnterpriseData je naproti tomu univerzální mechanismus, který dokáže pokrýt všechny oblasti činnosti podniku – finance, výrobu, nákup a prodej, skladové operace atd. První verze formátu obsahuje popis 94 typů dokumentů z různých oblasti podnikání. 1C do něj plánuje přidat nové dokumenty a popsat ty stávající.

Jak vysvětlují zástupci 1C, vznik EnterpriseData je vysvětlen potřebou nejen integrovat firemní aplikace do softwaru od jiných vývojářů, ale také – možná dokonce primárně – vytvořit jednotný mechanismus pro informační komunikaci v rámci softwarové rodiny 1C:Enterprise. Donedávna se k řešení těchto problémů používala široká škála řešení, často vytvářených případ od případu. Přechod produktů 1C na EnterpriseData již začal, používá se ve všech nejnovějších verzích jejích klíčových aplikací („1C: ERP Enterprise Management 2.0“, „1C: Accounting 8“ 3.0, „1C: Accounting 8 KORP“ 3.0, „1C: Maloobchod“ „2.0, „1C: Řízení obchodu“ 11). Zároveň se nepředpokládá nahrazení již používaných standardů (CommerceML, spolupráce s bankami) EnterpriseData, protože časem prověřené specializované algoritmy fungují efektivněji než univerzální nástroje.

1C věří, že nový formát najde široké uplatnění mezi nezávislými vývojáři vytvářejícími aplikace na platformě 1C:Enterprise, jsou pro ně nabízeny hotové softwarové komponenty v rámci Library of Standard Subsystems (něco jako SDK pro 1C:Enterprise).

Při použití standardu EnterpriseData jsou data mezi aplikacemi přenášena ve formě XML souboru pomocí příslušných XML schémat, přičemž fyzický přenos informací lze provádět pomocí různých mechanismů: webové služby, sdílení souborů přes adresář, FTP a email. Důležitým bodem je, že algoritmus interakce znamená pro příjemce schopnost potvrdit skutečnost, že přijal a zpracoval data, která mu byla zaslána. Samotný XML soubor je fyzicky dodáván v komprimované podobě (ZIP), což často umožňuje výrazně snížit informační provoz.

1C slibuje další rozvoj formátu EnterpriseData a jeho podporu ve stále větším počtu svých aplikací. Tento standard si bude společnost spravovat sama, jeho tvůrci zatím neplánují jeho transformaci na nezávislý oborový standard.

V tomto článku popíšu své, zatím malé, zkušenosti s organizací výměny dat prostřednictvím univerzálního formátu EnterpriseData.

V mém případě je výměna nakonfigurována mezi konfiguracemi „Trade Management 11.2“ (dále UT) a „Enterprise Accounting 3.0.43“ (dále BP). Výměna je jednosměrná, z UT do BP. Před upgradem Trade Management 11.1 na 11.2 byla výměna dat nakonfigurována pomocí konfigurace Data Conversion 2.0. Po přepnutí na „11.2“ se však uživatelům objevily chyby v „Správě obchodu“. Postup aktualizace pravidel výměny byl proveden, ale nepřinesl žádné výsledky. Ladicí program ukázal, že problém byl ve výměně dat. Bylo rozhodnuto odstranit nastavení výměny dat v obou konfiguracích a znovu je nakonfigurovat.

„Řízení obchodu“ i „Podnikové účetnictví“ fungují ve verzi klient-server. Začal jsem nastavovat synchronizaci s UT. Provedl jsem to tak, že se data nahrála z UT do souboru. Tedy synchronizace přes síťový adresář. V BP jsem nakonfiguroval výměnu tak, aby se z BP nestahovala žádná data.

Chyba při volání kontextové metody (Ověřit): Chyba ověření dat XDTO:
Struktura objektu "/Bankový účet protistrany/Banka" neodpovídá typu: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)KeyPropertiesBank
Kontrola vlastnosti "BIK":
tvar: Element
název: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)BIK
typ:
Chybí požadovaná vlastnost
Předmět: Smlouva s protistranou č. ...

Pro analýzu chyby jsem kliknul na ikonu „Složení zasílaných dat“ a v seznamu dodavatelských smluv registrovaných k odeslání jsem našel smlouvu, u které se chyba objevila. Otevřel jsem smlouvu a zapamatoval jsem si bankovní účet protistrany uvedený ve smlouvě. Poté jsem přešel na bankovní účty registrované pro přepravu. Ukázalo se, že požadovaný účet nebyl v seznamu registrovaných. Předělal jsem problémový bankovní účet a smlouvu. Poté jsem ručně zaregistroval požadovaný bankovní účet.

Znovu jsem zkusil synchronizovat data z UT. Tentokrát byla data úspěšně nahrána. V síťové složce byl vygenerován soubor XML obsahující data k přenosu z UT do BP.

Dalším krokem je načtení dat ze souboru do podnikového účetního oddělení. V konfiguraci "Enterprise Accounting" jsem kliknul na tlačítko "Synchronizovat", otevřel se formulář pro zpracování se zprávou "Probíhá analýza dat." O něco později se zpráva změnila na „Probíhá nahrávání dat“. Ukazatel a počítadlo přitom ukazovaly, že se z napájecího zdroje vykládá více než 80 tisíc předmětů. To mě zmátlo, protože jsem v nastavení naznačil, že se nemá nic vybíjet ze zdroje. Zpracování trvalo poměrně dlouho a skončilo chybou:

Událost: Výměna dat
(GeneralModule.Long-runningOperations.Module(371)): Proces pracovníka na pozadí byl abnormálně ukončen
RaiseException(ErrorText);

Pro lokalizaci chyby jsem zkusil změnit nastavení synchronizace a možnosti provozu napájecí základny. Výsledkem bylo, že když jsem databázi převedl na souborovou verzi, systém fungoval adekvátně: otevřel se formulář pro porovnání dvou databází. Po spárování objektů byla počáteční synchronizace úspěšná. Poté jsem přepnul databázi zpět na verzi klient-server.

S dalším testováním synchronizace bylo nutné provést některé změny v pravidlech pro převod objektů. Je čas použít konfiguraci Data Conversion 3.0. Vestavěná nápověda ke konfiguraci popisuje, jak to funguje. Pomohly i články na webu ITS.

V důsledku toho jsem do "Data Conversion 3.0" načetl následující data:

• Texty obecného modulu "Správce výměny dat prostřednictvím univerzálního formátu" ze dvou databází
• Rozložení obou základů
• Popis formátu EnterpriseData (z libovolné databáze)
• Pravidla konverze

Po stažení jsem otevřel pravidla pro převod dat, objektů a vlastností v „Data Conversion 3.0“. Provedl jsem změny, které jsem potřeboval. Poté jsem použil tlačítko "Unload exchange manager module". Text modulu byl zkopírován do schránky. Zbývá jen vložit do konfigurace.

Po experimentování s nastavením pravidel v "Data Conversion 3.0" jsem sám usoudil, že v případě, kdy jsou prováděné změny nevýznamné, je jednodušší nastavit pravidla přímo v konfiguraci UT a BP, v obecném modulu „Správce výměny dat prostřednictvím univerzálního formátu“. Pokud jsou úpravy vážné, jako je například přidání nového objektu do výměny, měli byste použít konfiguraci " Konverze dat 3,0".

Úkol přidání dokumentu "Objednávka dodavateli" do plánu výměny jsem provedl pomocí " Konverze dat 3.0". Ve standardní verzi UT - BP není tento dokument součástí výměnného plánu.

Připomeňme, že pravidla pro registraci objektů pro nahrávání se stále konfigurují v konfiguraci „Data Conversion 2.0“.

Toto jsou první dojmy ze synchronizace dat prostřednictvím univerzálního formátu EnterpriseData.

P.S. Máte-li dotazy nebo vlastní postřehy týkající se výměny dat prostřednictvím univerzálního formátu a konfigurací" Konverze dat 3.0", napište do komentářů. Vyměníme si zkušenosti.

• Synchronizace dat
• Univerzální formát EnterpriseData
• Konverze dat 3.0
• Konverze dat 2.0
• Řízení obchodu
• Podnikové účetnictví

Tisknout (Ctrl+P)

Výměna přes univerzální formát

Subsystém „Data Exchange“ knihovny standardních subsystémů obsahuje 4 možnosti (technologie) pro výměnu informací mezi různými informačními bázemi:

• distribuované informační báze (RIB);
• výměna dat prostřednictvím univerzálního formátu;
• výměna dat podle pravidel výměny (pravidla výměny se vytvářejí pomocí konfigurace „Konverze dat“, vydání 2.1);
• výměna dat bez pravidel výměny.

Tento článek pojednává o technologii výměny dat prostřednictvím univerzální formát EnterpriseData. Tato technologie je dostupná v knihovně „Standard Subsystems Library“ počínaje verzí 2.3.1.62. vydáno na začátku roku 2016. V současné době má nejnovější vydání BSP 2.3 (pro použití s ​​platformou 1C:Enterprise 8.3 ne nižší než verze 8.3.8.1652 s vypnutým režimem kompatibility) vydání 2.3.6.17.

Rýže. 1 Nejnovější verze BSP 2.3

Mezi soubory pro dodávání aplikačních řešení 1C je textový soubor „Library Versions“, kde je napsáno, na základě jaké verze BSP byla aplikace vyvinuta, například na základě aplikačního řešení UT 11.3.3.231, Byl vytvořen BSP 2.3.5.65.

Vezměte prosím na vědomí, že pro použití s ​​verzí platformy „1C:Enterprise 8.3“ ne nižší 8.3.10.2168 vydání bylo vydáno s deaktivovaným režimem kompatibility BSP 2.4.

Popis formátu EnterpriseData

Jaký je formát EnterpriseData?

Jedná se o formát, který umožňuje popsat objekt informační báze (protistrana, faktura atd.) nebo nahlásit skutečnost, že tento objekt byl smazán. Očekává se, že konfigurace, která obdrží soubor ve formátu EnterpriseData, bude odpovídajícím způsobem reagovat - vytvoří nové objekty a smaže ty, které jsou v souboru označeny jako smazané. Je určen pro výměnu informací mezi konfiguracemi UT, RT, UNF, BP. Formát lze také použít pro výměnu informací s jakýmikoli jinými informačními systémy: nezávisí na vlastnostech vlastního softwaru nebo struktur informační báze, které se účastní výměny, a neobsahuje zjevná omezení použití.

Verze formátu EnterpriseData

Data formátu jsou uložena v balíčcích XDTO ve větvích obecné konfigurace databáze, jak je znázorněno na Obr. 2

Obr. 2 Balíčky datového formátu XDTO – EnterpriseData

Na Obr. 2 ukazuje, že existuje několik balíčků XDTO. Jedná se o různé verze formátu. Číslo verze formátu se skládá z X.Y.Z, kde X.Y je verze, Z je vedlejší verze. Verze Minor je rozšířena v případě oprav chyb a dalších změn, ve kterých: je zachována funkčnost logiky převodu dat na základě předchozí verze formátu (zachování zpětné kompatibility současných algoritmů přenosu dat prostřednictvím formátu); Podpora nových možností formátování pro konverzní logiku je dobrovolná. Příkladem takových změn může být oprava chyby, změna vlastností formátových objektů, přidání vlastností, jejichž použití není při převodu dat povinné. V ostatních případech, kdy se změní formát, se hlavní verze zvětší: X – v případě globální restrukturalizace, Y – v ostatních případech.
Formát popisuje reprezentaci objektů (dokumentů nebo prvků adresáře) ve formě souborů XML. Verze 1.0.1 obsahuje popis 94 objektů z různých oblastí (finance, výroba, nákup a prodej, skladové operace). Názvy typů jsou zpravidla dobře srozumitelné a nepotřebují další vysvětlení: například „Dokument.Zákon o dokončené práci“ nebo „Directory.Protistrany“. Jak vidíte, popis typů dokumentů začíná předponou „Dokumentář.“ a prvek adresáře začíná předponou „Adresář.“. Podrobnější popis formátu naleznete
Nejnovější verze je 1.3, nicméně nejčastěji používaná verze je 1.0. Mezi verzemi není velký rozdíl. Formát EnterpriseDataExchange_1_0_1_1 používá se při výměně prostřednictvím webové služby.
Všimněte si, že se kterým se používá balíček formátu dat EnterpriseData ExchangeMessage při vytváření pravidel převodu. Právě tento balíček obsahuje objekt typu Doplňující informacekterý může mít libovolný typ hodnoty a používá se při vytváření pravidla převodu mezi konfiguračními objekty. které nejsou v datovém formátu. Přesně tak, díky Doplňující informacePravidla výměny můžete přizpůsobit a přizpůsobit, aniž byste měnili data formátu v balíčcích XDTO.

Rýže. 3 Struktura XDTO packageExchangeMessage

Jak vyměňovat data ve formátu EnterpriseData?

Výměna dat ve formátu EnterpriseData s konfigurací je výměna souborů. V reakci na soubor přijatý z externí aplikace jej konfigurace zpracuje a vytvoří soubor odpovědí. Soubory lze vyměňovat:

• prostřednictvím vyhrazeného adresáře souborů,
• přes FTP adresář,
• prostřednictvím webové služby nasazené na straně infobáze. Datový soubor je předán jako parametr webovým metodám.

Poznámka. Pro obousměrnou výměnu dat mezi aplikací třetí strany a konfigurací na straně infobáze je třeba provést řadu nastavení - aplikace třetí strany musí být zaregistrována v infobázi, musí být pro ni definován výměnný kanál (přes soubor nebo adresář FTP) atd. Ale pro případy jednoduché integrace, kdy stačí pouze přenést informace z aplikace třetí strany do infobáze a zpětný přenos dat z infobáze do aplikace třetí strany není nutný (např. integrace internetového obchodu který přenáší informace o prodeji do 1C: Accounting), existuje zjednodušená verze práce prostřednictvím webové služby, která nevyžaduje nastavení na straně.

Při výměně pomocí plánů výměny konfigurace během synchronizace jsou přenášeny pouze informace o změnách, které nastaly od poslední synchronizace (pro minimalizaci množství přenášených informací). Při první synchronizaci konfigurace vypíše všechny objekty ve formátu EnterpriseData do souboru XML (protože jsou všechny „nové“ pro aplikaci třetí strany).

Další krok je pro aplikaci třetí strany – ta musí zpracovat informace ze souboru XML a umístit je do sekce během příští synchronizační relace informaci, že byla úspěšně přijata zpráva z konfigurace s určitým číslem (číslo zprávy přijaté z konfigurace uveďte do pole ReceivedNo). Zpráva o příjmu je signálem pro konfiguraci, že všechny objekty byly úspěšně zpracovány externí aplikací a není třeba o nich dále předávat informace. XML soubor z aplikace třetí strany může kromě účtenky obsahovat také data pro synchronizaci (v části ).

Po obdržení zprávy o příjmu konfigurace označí všechny změny odeslané v předchozí zprávě jako úspěšně synchronizované. Externí aplikaci budou během příští synchronizační relace odeslány pouze nesynchronizované změny objektů (vytvoření nových, změna a odstranění stávajících).

Při přenosu dat z externí aplikace do konfigurace je obraz obrácený. Přihláška musí vyplnit sekci podle toho a v sekci umístěte objekty, které mají být synchronizovány, ve formátu EnterpriseData.

Po zpracování souboru konfigurace vygeneruje XML soubor, který bude obsahovat zprávu o příjmu a nová data pro synchronizaci ze strany konfigurace (pokud nějaká od poslední synchronizační relace existují).

Další podrobnosti o výměně dat s aplikačními řešeními na platformě 1C:Enterprise můžete vidět ve formátu EnterpriseData

Obecný modul „manažera burzy v univerzálním formátu“.

Postupy a funkce, které plně popisují pravidla pro stahování dat z informační báze do výměnného formátu a pravidla pro načítání dat z výměnného formátu do informační báze, jsou vypracovány ve společném modulu - modulu exchange manager prostřednictvím univerzálního formátu.

Rýže. 4 Struktura modulu správce burzy prostřednictvím univerzálního formátu

Modul se vytváří automaticky pomocí konfigurace „Data Conversion“, vydání 3.0, na základě nakonfigurovaných pravidel výměny, nebo ručně v konfigurátoru.

Modul se skládá z několika velkých částí, z nichž každá obsahuje vlastní skupinu procedur a funkcí.

1. Komentář. První řádek modulu obsahuje komentář s názvem převodu. Tento řádek je nezbytný pro identifikaci modulu například při použití příkazu v programu Data Conversion, edice 3.0. // Konverze UP2.2.3 z 06.01.2017 19:51:50
2. Konverzní procedury. Obsahuje předdefinované procedury, které se provádějí v různých fázích synchronizace dat: před převodem, po převodu, před odloženým plněním.
3. Pravidla zpracování dat (DPR). Obsahuje procedury a funkce, které popisují pravidla pro zpracování dat.
4. Pravidla konverze objektů (OCR). Obsahuje procedury a funkce, které popisují pravidla pro převod objektů a také pravidla pro převod vlastností těchto objektů.
5. Předdefinovaná pravidla konverze dat (PDC). Obsahuje postup, který vyplňuje pravidla pro převod předdefinovaných dat.
6. Algoritmy. Obsahuje libovolné algoritmy, které jsou volány z jiných pravidel (POD nebo PKO).
7. Možnosti. Obsahuje logiku pro vyplňování parametrů převodu.
8. Obecný účel. Obsahuje procedury a funkce, které jsou široce používány v pravidlech a algoritmech.

Níže jsou popsány parametry procedur a funkcí, které se používají v několika typech procedur v modulu manažera.

Výměnné komponenty. Typ – Struktura. Obsahuje parametry a pravidla výměny inicializované jako součást výměnné relace.

Směr výměny. Typ – Řetězec. Buď "Odeslat" nebo "Přijmout".

IB data. Typ – DirectoryObject nebo DocumentObject.

Postupy související s konverzními událostmi

Během procesu převodu jsou volány tři předdefinované procedury:

• Před konverzí. Volá se před synchronizací dat. Tento postup obvykle obsahuje logiku pro inicializaci různých parametrů převodu, naplnění výchozích hodnot atd. Parametry: Výměna komponent.
• AfterConversion. Volá se po dokončení synchronizace dat, ale předtím, než dojde k línému vyplnění. Možnosti: Výměna komponent.
• BeforeDelayedFilling. Volá se dříve, než dojde k línému plnění. Zde se nachází logika pro řazení nebo úpravu tabulky objektů podléhajících línému plnění. Možnosti: Výměna komponent.

AML procedury

Vyplňte Pravidla zpracování dat. Procedura exportu, která obsahuje logiku pro vyplňování pravidel zpracování dat. Obsahuje volání dalších procedur, které přidávají pravidlo pro zpracování konkrétního objektu do tabulky pravidel (viz postupy níže Přidat AML). Možnosti: Směr výměny, Pravidla zpracování dat

Přidat UNDER_<ИмяПОД>. Sada procedur, které naplňují tabulku POD pravidly pro konkrétní objekty. Počet takových procedur odpovídá počtu AML poskytnutých pro tuto konverzi v programu Data Conversion, verze 3.0. Možnosti: Pravidla zpracování dat(tabulka hodnot inicializovaná jako součást výměnné relace).

POD_<ИмяПОД>_Při zpracování. Procedura obsahuje text handleru Během zpracování pro konkrétní AML. Obslužná rutina je navržena tak, aby implementovala konverzní logiku na úrovni objektu. Například přiřaďte konkrétní PQO konkrétnímu objektu v závislosti na obsahu objektu. Možnosti:

• Údaje InformationB nebo DataXDTO(v závislosti na směru výměny):
• při odesílání – objekt ( DirectoryObject,DocumentObject);
• při příjmu - struktura s popisem objektu XDTO.
• Použití PKO. Typ - Struktura. Klíč obsahuje řetězec s názvem PCO a hodnotou typu Boolean (Skutečný– používá se PKO, Lhát– PKO se nepoužívá).
• Výměna komponent.

POD_<ИмяПОД>_Vzorkování dat. Funkce obsahuje text handleru Při vykládání. Obslužná rutina je navržena tak, aby implementovala libovolný algoritmus pro výběr objektů, které mají být vyloženy. Návratová hodnota: pole objektů, které se mají uvolnit. Pole může obsahovat jak odkazy na objekty infobáze, tak strukturu s daty pro nahrání. Možnosti: Výměna komponent.

Postupy PKO

Vyplňte Pravidla konverze objektů. Procedura exportu, která obsahuje logiku pro vyplňování pravidel pro převod objektů. Obsahuje volání jiných procedur, které do tabulky pravidel přidávají konkrétní pravidlo převodu objektu (viz postupy níže Přidejte PKO). Možnosti: Směr výměny, Pravidla konverze(tabulka hodnot inicializovaná jako součást výměnné relace).

PřidatPKO_<ИмяПКО>. Sada procedur, které naplní tabulku PKO pravidly pro konkrétní objekty. Počet takových procedur odpovídá počtu PKO poskytnutých pro tuto konverzi v programu Data Conversion, verze 3.0. Možnosti: Pravidla konverze(tabulka hodnot inicializovaná jako součást výměnné relace).

PKO_<ИмяПКО>_WhenSendingData. Procedura obsahuje text handleru Při odesílání pro konkrétní PKO. Handler se používá při nahrávání dat. Navrženo k implementaci logiky pro převod dat obsažených v objektu infobase na popis objektu XDTO. Možnosti:

• Údaje InformationB. Typ - DirectoryObject, DocumentObject. Zpracovávaný objekt informační báze.
• DataXDTO. Typ - Struktura. Navrženo pro přístup k datům objektů XDTO.
• Výměna komponent.
• StackUploads. Typ - Pole. Obsahuje odkazy na vyložené objekty s přihlédnutím k vnoření.

PKO_<ИмяПКО>_Při převodu dat XDTO. Procedura obsahuje text handleru Při převodu DataXDTO pro konkrétní PKO. Handler se používá při načítání dat. Navrženo pro implementaci libovolné logiky konverze dat XDTO. Možnosti:

• DataXDTO. Typ - Struktura. Vlastnosti objektu XDTO, které byly předzpracovány, aby k nim byl snadnější přístup.
• ReceivedData. Typ - DirectoryObject, DocumentObject. Objekt infobáze vytvořený převodem dat XDTO. Nezaznamenáno v informační databázi.
• Výměna komponent.

PKO_<ИмяПКО>_Před záznamem přijatých dat. Procedura obsahuje text handleru Před záznamem přijatých dat pro konkrétní PKO. Handler se používá při načítání dat. Navrženo pro implementaci další logiky, která musí být provedena před záznamem objektu do informační databáze. Například by měly být změny načteny do existujících dat zabezpečení informací nebo by měly být načteny jako nová data. Možnosti:

• ReceivedData. Typ - DirectoryObject, DocumentObject. Datový prvek generovaný převodem dat XDTO.

Zaznamená se, pokud jsou tato data pro infobázi nová (parametr Údaje InformationB obsahuje hodnotu Nedefinováno).

v opačném případě ReceivedData nahradit Údaje InformationB(všechny vlastnosti z ReceivedData převeden k Údaje InformationB).

Pokud není vyžadováno standardní nahrazení dat zabezpečení informací přijatými daty, měli byste napsat vlastní logiku přenosu a poté nastavit parametr ReceivedData význam Nedefinováno:

• Údaje InformationB. Typ - DirectoryObject, DocumentObject. Datový prvek infobáze odpovídající přijatým datům. Pokud nejsou nalezena žádná odpovídající data, obsahuje Nedefinováno.
• ConvertingProperties. Typ - Tabulka hodnot. Obsahuje pravidla pro převod vlastností aktuálního objektu, inicializovaného jako součást výměnné relace.
• Výměna komponent.

postupy PCPD

Vyplňte Pravidla převodu předdefinovaných dat. Procedura exportu, která obsahuje logiku pro vyplňování pravidel pro převod předdefinovaných dat. Možnosti: Směr výměny, Pravidla konverze(tabulka hodnot inicializovaná jako součást výměnné relace).

Algoritmy

V programu „Data Conversion“, vydání 3.0, je možné vytvářet libovolné algoritmy, které jsou volány z handlerů AML a PKPD. Název, parametry a obsah algoritmů jsou určeny při vývoji pravidel.

Možnosti

Vyplňte ConversionParameters. Procedura exportu, ve které se vyplní struktura s parametry převodu. Možnosti: Možnosti převodu(typ - Struktura).

Obecné postupy a funkce

ExecuteManagerModuleProcedure. Možnosti: Název procedury(čára), Možnosti(struktura). Procedura exportu, která je určena k volání procedury neexportního modulu, jejíž název a parametry jsou přijímány jako vstup. Umožňuje volat proceduru nebo funkci na lince bez použití metody Vykonat.

ExecuteManagerModuleFunction. Možnosti: Název procedury(čára), Možnosti(struktura). Funkce, účel podobný ExecuteManagerModuleProcedure. Rozdíl je v tom, že volá funkci a vrací její hodnotu.

Podívejme se na jednoduchý příklad ze života. Řekněme, že máme firmu, která se zabývá velkoobchodem a maloobchodem a v této firmě se jako v každé jiné vede účetnictví. Podnik má dvě standardní databáze, jedná se o UT (obchodní management) a BP (účetnictví podniku), v každé z databází jsou vedeny vlastní záznamy, v UT je vedení, které odráží všechny transakce související s obchodem, v BP existuje účetnictví. Aby nedošlo k dvojí práci, tzn. nevytvářejte stejné doklady ve dvou databázích (přeci jen pohyby by měly být v managementu a účetnictví) pouze nastavíme synchronizaci mezi těmito databázemi.

Nastavíme výměnu dat jednosměrně, z UT ---> BP. Je také možné nastavit obousměrnou ústřednu, ale v praxi to není často vyžadováno, takže to v našem příkladu nebudeme uvažovat.

Přípravné kroky pro nastavení burzy v BP

Začněme s nastavením synchronizace, nejprve přejděte do databáze 1C "Enterprise Accounting 3.0" (přijímač), musíme zkontrolovat, zda je pro tuto databázi povolena synchronizace, abychom to mohli provést, musíme nejprve přejít do databáze. Jakmile se databáze otevře, přejděte na kartu "Administrace" ---> "Nastavení synchronizace dat"

Otevře se před námi nová karta, kterou je nutné vyplnit stejně jako na obrázku níže, s výjimkou předpony informační báze. Předpona se musí skládat ze dvou písmen, můžete nastavit libovolné, ale podle standardu 1C je lepší nastavit předponu podle názvu konfigurace, to znamená, že pro „Enterprise Accounting“ bude předpona „BP“. Pokud zakládáte složité burzy a existuje několik účetních databází, měly by se předpony od sebe zřetelně lišit, zde můžete jako zkratku použít první dvě písmena názvu organizace.

Pokračujeme v nastavování synchronizace dat v UT

Poté, co jsme provedli všechny potřebné akce v databázi přijímačů (BP 3.0), abychom mohli pokračovat v nastavování výměny dat, musíme otevřít zdrojovou databázi (UT 11.1). Přejděte na kartu „Správa“, v nabídce vlevo vyberte „Nastavení synchronizace dat“.. Pokud synchronizace není povolena, povolte ji pomocí zaškrtávacího políčka a nezapomeňte zadat zdrojovou základní předponu. Jakmile dokončíme všechny kroky 1-4, jak je znázorněno na obrázku níže, musíte kliknout na hypertextový odkaz „Synchronizace dat“ (krok 5).

V novém okně, které se objeví, musíte kliknout na zelené znaménko plus (Nastavit synchronizaci dat), v rozbalovací nabídce vybrat položku „Enterprise Accounting 3.0“.

Nastavení důležitých bodů ve výměně dat mezi UT a BP

Nyní vidíme okno s nastavením pro synchronizaci dat v 1C, vyberte „Zadat nastavení ručně“ a klikněte na „Další“.

Pokračujeme v nastavování výměny dat v 1C, na další záložce je potřeba vybrat možnost připojení k infobázi přijímače (přímé připojení k programu), parametry připojení (na tomto počítači nebo v místní síti), adresář, kde je umístěna základna přijímače a také potřebné autentizační údaje (uživatelské jméno a heslo v databázi).

Na další stránce musíme vyplnit pravidla pro odesílání a příjem dat z konfigurace BP 3.0 (přijímač). Klikněte na "změnit pravidla nahrávání dat".

Otevřelo se před námi okno „Pravidla pro odesílání dat“, v němž nastavujeme následující parametry:

• Které referenční údaje budou odeslány (v našem příkladu nás zajímají pouze dokumenty a referenční údaje v nich použité, proto jsme vybrali příslušnou položku; pokud vyberete první položku „Odeslat vše“, budou všechny referenční knihy znovu načteny spolu s doklady, často pokud informace nejsou použity v dokladech, jsou pro příjemce k ničemu, protože to nijak neovlivňuje účetnictví)
• Od jakého data mají být všechny informace odesílány (v tomto článku nebudeme uvažovat o ruční synchronizaci)
• Komu nebo kterým organizacím zasílat data (v našem příkladu jsme vybrali jednu organizaci, IP „Podnikatel“)
• Pravidla pro uzavírání smluv
• Generalizovaný sklad
• Mám srolovat dokumenty podle skladu?

Po provedení nastavení klikněte na „Uložit a zavřít“.

Protože v našem příkladu nastavujeme a používáme jednosměrnou výměnu, z UT do BP, pak nás nastavení pravidel pro získávání dat z „Podnikového účetnictví 3.0“ nezajímá, a tak klikneme na „Další“.

V novém okně jsme požádáni o konfiguraci pravidel pro základnu přijímače (RB). V bodě 1 pojmenujeme naši databázi, dáme jí prefix. PREFIX musí být stejný, jako jsme jej nastavili v samotné databázi BP na začátku tohoto článku, pokud se předpony liší, synchronizace dat v programu 1C nebude fungovat. Poté klikněte na bod 2 a poté na bod 3.

V bodě 3 musíme umožnit zpracování dokumentů při jejich načtení do databáze. Klikněte na "Uložit a zavřít".

Nyní by okno mělo vypadat podobně jako to zobrazené níže, klikněte na „Další“.

Toto okno obsahuje referenční informace o synchronizaci vytvářené v 1C. Stačí kliknout na tlačítko "Další". Pokud program vygeneroval chybu při nastavování synchronizace dat, musíte nás kontaktovat, aby vám náš specialista 1C mohl pomoci právě teď!

Další krok program nabídne synchronizaci ihned po vytvoření nastavení výměny dat. Souhlasíme s tím a klikneme na „Hotovo“.

Před vámi se objeví okno, ve kterém uvidíte informace o tom, jak synchronizace probíhá. Pokud základna přijímače není prázdná, tzn. v něm již byly vedeny záznamy, pak bude uživatel v programu 1C vyzván k ručnímu porovnání objektů. Porovnání objektů v 1C při synchronizaci dat je porovnání identických objektů přijímače s identickými objekty ve zdroji.

Podívejme se na příklad, řekněme, že v UT existuje protistrana s názvem „PharmGroup LLC“ a DIČ 1234567 a v BP je také protistrana s DIČ 1234567, ale název „PharmGroup“, pokud je neporovnáme dva objekty při porovnávání dat ve fázi synchronizace, pak po synchronizaci v přijímači (Enterprise Accounting 3.0) budeme mít dvě protistrany s TIN 1234567 a dvěma názvy „PharmGroup LLC“ a „PharmGroup“. Aby se takovým situacím předešlo, byl vynalezen mechanismus pro porovnávání objektů.

V našem příkladu je databáze přijímačů prázdná, a proto se okno pro porovnání objektů neotevřelo. Ale po provedení některých operací systém určitě vyzve uživatele k přidání dalších údajů a zobrazí následující okno. Nepotřebujeme přenášet žádná další data, vše potřebné jsme již nakonfigurovali dříve, takže v tomto kroku vybereme „Nepřidávat dokumenty k odesílání“. Klikněte na "Další".

Poslední fáze výměny dat mezi 1C

V konečné fázi program zobrazí následující okno, ve kterém bude uživatel informován, že synchronizace proběhla úspěšně, klikněte na „Dokončit“. V tomto okamžiku je dokončena synchronizace mezi databázemi v jednosměrné výměně z „Trade Management 11.1“ (UT) do „Enterprise Accounting 3.0“ (BP).