1c změnit pravidla směny prostřednictvím univerzálního formátu. 1C nabízí formát EnterpriseData pro výměnu obchodních dat. Co je to formát EnterpriseData

Účelem tohoto článku je odpovědět na první otázky týkající se KD3 a pomocí jednoduchého příkladu ukázat, jak upravit standardní pravidla. Informace jsou užitečné pro začátečníky a ty, kteří již zvládli a mají nové otázky.

Povolené zkratky v této publikaci

KD2- Převod konfiguračních dat, revize 2.0.
KD3- konfigurace Převod dat, revize 3.0, konfigurace 3.0.5.3.
ED- univerzální výměnný formát EnterpriseData.

Odpovědi na otázky po povrchním seznámení s KD3. Pokud víte, proč KD3 potřebujete, můžete tento odstavec přeskočit;)

Otázky a odpovědi

KD3 je nová verze KD2? Ne! Toto je další nástroj, který řeší problémy podobné KD2. Každý nástroj má svou vlastní aplikaci.
Je KD3 lepší než KD2? Nelze je srovnávat, protože jsou to různé nástroje a každý má svá pro a proti.
Chcete -li změnit pravidla pro výměnu KD3, potřebujete odebrat konfiguraci z podpory? Ne NEPOTŘEBUJTE odstoupit od podpory! V typických konfiguracích můžete standardně propojit externí zpracování s pravidly a na konfiguracích, které podporují platformu 8.3.10 a vyšší, můžete upravovat pravidla pomocí rozšíření.
Je třeba přenášet data z interních konfigurací. Pro studijní účely můžete použít KD3? Pokud si kladete tuto otázku, s největší pravděpodobností nemůžete. U KD3 musí konfigurace obsahovat BSP 2.3 a vyšší se synchronizací přes univerzální formát. KD2 vám bude stoprocentně vyhovovat, KD3 je diskutabilní.
Lze KD3 použít pro typické modifikované konfigurace? Ano můžeš. Pokud lze vaše atypická data předávat pomocí rekvizit ED nebo AdditionalInfo, je to v pořádku. V opačném případě existuje možnost změnit formát výměny (schéma XML). V tomto případě se schopnosti CD3 budou téměř rovnat CD2, ale ztratí se hlavní výhoda CD3 - univerzálnost výměnného formátu.
Lze vzájemně vyměňovat konfigurace podporující ED? Ano! Ale pro výměnu BP 3.0 - BP 3.0 při vytváření synchronizace nemůžete vybrat BP 3.0. Nevadí, zvolte „Jiný program“. Pokud potřebujete jednorázovou výměnu, stačí použít zpracování „Nahrát / načíst EnterpriseData“ v nabídce Všechny funkce.
Potřebujete po aktualizaci konfigurace stáhnout nejnovější pravidla z distribuční sady? Ne! Pravidla jsou obsažena v konfiguračním modulu. K výměně s jinými 1C databázemi nemusíte načítat pravidla jiné databáze. Proč? Podrobnosti v tomto článku.
Je nutné po aktualizaci jedné databáze aktualizovat druhou databázi účastnící se výměny? Ne! Není nutné synchronně aktualizovat všechny databáze účastnící se výměny. To je jedna z výhod KD3.
Naše konfigurace byly výrazně vylepšeny, existují nové typy dokumentů a adresářů, dokáže je KD3 přenést? Existuje šance, že bez změny formátu to nepůjde. To je jedna z „nevýhod“ KD3 ve srovnání s KD2.

Proč tedy potřebujeme KD3? Výhody a nevýhody

Výhody KD3

Zvažme hlavní výhodu KD3 na příkladu často se vyskytujícího úkolu. Existuje konfigurace UT 11.3, která není z nějakého důvodu aktualizována. Je nutné zorganizovat výměnu s BP 3.0, který je neustále aktualizován na aktuální verzi.

Žádný problém.

Univerzální výměnný formát, který se používá v KD3, je určen k řešení takových problémů.
Pravidla výměny v UT nejsou vytvořena pro výměnu s BP, ale pro výměnu v univerzálním formátu EnterpriseData.
Pokud pracujeme z hlediska KD2, pak se UT směňuje s konfigurací ED, která se nemění. BP 3.0 se také vyměňuje za ED.

Každá konfigurace má svá vlastní pravidla pro výměnu s ED. UT tedy vždy nahrává data do stejného formátu. Konfigurace BP 3.0, bez ohledu na to, jak je nová, by měla být schopna přijímat data z tohoto formátu.

Ukazuje se, že UT si nemusí dělat starosti s tím, že BP změní některé detaily. Úkol je jednoduchý - nahrát do ED a konfigurace zdroje by měla být schopna přijímat data z tohoto formátu.

Vzhledem k tomu, že zdroj vždy nahrává konfiguraci v jednom formátu, může jakýkoli konfigurační příjemce nahrávat data z tohoto univerzálního formátu.
Tito. pro libovolnou kombinaci burz UT - BP, UT - KA, UT - ERP, KA -BP, ERP - BP. není třeba psát jednotlivá pravidla. V KD3 jsou pravidla univerzální. Jakákoli konfigurace, která podporuje univerzální výměnu formátů, lze vyměňovat s jakoukoli konfigurací, která podporuje formát ED.

Ladění algoritmů a pravidel je k dispozici v samotné konfiguraci, protože všechna pravidla jsou kódová společný modul nebo externí zpracování. Chcete -li chybu rychle opravit, obejdete se bez KD3.

Nevýhody KD2

Pravidla výměny jsou individuální pro každou dvojici konfigurací. Všechny výše uvedené kombinace výměny mezi různými typy konfigurací a různými verzemi konfigurací vyžadují svá vlastní pravidla pro výměnu. K vyřešení výše zmíněného problému výměny UT 11.3 a BP 3.0 bude tedy nutné téměř po každé aktualizaci BP 3.0 ladit a upřesňovat pravidla výměny.

Ladění algoritmů a pravidel je obtížné pro začínajícího programátora nebo pro někoho, kdo se s tímto úkolem potýká jen zřídka. Pravidla jsou uložena v souboru xml. Rychlá oprava není k dispozici. Je nutné načíst pravidla do KD2, opravit a uvolnit je zpět.

Nevýhody KD3

Univerzální formát ukládá omezení na typy dokumentů a adresářů. Je určen pro typické konfigurace. Pokud máte atypický požadavek nebo typ dokumentu, může být obtížné jej vyměnit.

Pro synchronizaci ve formátu ED musí konfigurace podporovat tyto mechanismy. To vše je v BSP 2.3 a vyšším. To není opravdu mínus, ale spíše funkce.

Hlavní plus trochu mizí kvůli omezenému časovému rámci pro podporu formátu. To již pocítili uživatelé UT 11.1, UT 11.2, kteří si vyměňují s BP 3.0. Zde jsou uvedeny časy podpory. Říká, že minimální doba podpory zaručeného formátu je rok, ve skutečnosti asi 3 roky. Pokud tedy nastavíte synchronizaci dnes, pak po dobu nejméně jednoho roku nemůžete aktualizovat databázi UT 11 a poté buď aktualizovat konfiguraci, nebo jednoduše přidat nový formát, provést malou změnu v BSP a v pravidlech, Pokud je třeba. Jak to udělat? Bude zmíněno později v tomto článku.

Výhody KD2

Možnosti KD2 jsou nekonečné. Pravidla výměny můžete vytvořit pro libovolnou konfiguraci na jakékoli platformě. Od 1C 7,7 do posledních 8,3. Z konfigurace není nic požadováno, BSP je volitelný. Pravidla lze vytvořit v automatický režim a rafinované.

V souvislosti s výše uvedenými pro a proti se pro typické konfigurace doporučuje použít KD3. KD2 lze použít pro libovolnou konfiguraci, ale vzhledem k jeho nevýhodám nezapomeňte, že někdy je vhodnější použít KD3.

Doufám, že chápete, proč je KD3 potřeba, pokračujeme ve věci samé.

Akceptované zkratky dále

BSP- Knihovna standardních subsystémů.
POD- pravidlo zpracování dat.
PKO- pravidlo převodu objektu.
PKPD- pravidlo pro převod předdefinovaných dat.
PKS- pravidlo převodu majetku.

Zvažte příklad - je nutné změnit standardní pravidla pro výměnu BP 3.0 a UT 11.3

Na žlutém pozadí jsou kroky z pokynů, které se otevírají v KD3. Posloupnost kroků navržených v tomto článku je odlišná, aby nedošlo k záměně a okamžitě logicky dokončilo započatou akci.

Jak změním pravidla ED?

Upravte modul s pravidly výměny přímo v konfiguraci. O této možnosti zatím neuvažujeme, protože Abychom pochopili, co a kde je třeba změnit, je nutné to udělat alespoň jednou v KD3. V takovém případě bude v budoucnu snazší rychle řešit problémy, ladit modul a v případě potřeby přenést do KD3.
Použijte KD3.
Jak se to dělá v KD2? Vyjmeme metadata obou konfigurací a načteme je do KD2.
Krok 1. Pro KD3 děláme totéž - v každé konfiguraci v podnikovém režimu zpracováním \ tmplts \ 1c \ Konverze \ 3_0_5_3 \ MD83Exp.epf nahrát metadata konfigurace,
například do složky „ D: \ Pravidla BP3 \ BP 3.0.54.15 \", Název souboru " MD.xml».

Není jasné, za jakým účelem jsou nastavení tohoto zpracování skryta, v důsledku čehož ve výchozím nastavení nejsou data o informačních registrech uvolněna. Tuto závadu odstraňujeme.
V proceduře ChangeProcessingMode () hlavního formuláře okomentujte řádek

// Elements.Settings.Visibility = False;

Uložíme zpracování, otevřeme jej v podnikovém režimu, umístíme příznak na „Vyložit informační registry“, uvolnit.

Krok 3. Načíst dříve vytvořený soubor „ MD.xml"V KD3, příznak sekce" PROTI nová verze konfigurace».

Protože v KD3 slouží k výměně „mezilehlá konfigurace“ (ED), načteme také jeho „metadata“, která jsou XML schéma, soubor s příponou "xsd". Krok 2. Můžete to vzít z konfigurace UT 11 nebo BP 3.0. Jsou stejné. Otevřete konfiguraci, do vyhledávacího pole zadejte „ vstoupit“, Vidíme na stromě Obecné - balíčky XDTO některé balíčky takto: EnterpriseData_1_3_8, EnterpriseData_1_4_4 a podobně .. Jedná se o verze formátu 1.3 a 1.4 a 1.2, 1.1, 1.0, pokud existují. Pravé tlačítko myš na obalu, v kontextová nabídka Vybrat "".

Krok 4. V sekci KD3 vyberte dříve nahrané soubory s příponou „xsd“. Musíte vybrat jeden soubor! Více možností ve spojení s ExchangeMessage není potřeba! To bylo navrženo ve starých pokynech KD3 předchozí verze... U posledního CD3 to není nutné.

Po načtení formátu v sekci Formát dat - formátování stromu objektů, vyberte verzi formátu. Pokud tam jsou dokumenty a adresáře, pak jste nahráli správný soubor... Pokud ne, začněte znovu s novým prázdným CD3 a nejprve načtěte formát a zkontrolujte strom.

Fáze 2. Po načtení metadat do CD3 přistoupíme k načtení standardních pravidel výměny.
Jak se to dělá v KD2? Pravidla se načtou do převodu.
V KD3 je to téměř stejné. Vyjmeme pravidla ze standardního, vytvoříme převod a poté do něj načteme pravidla.

Uvolnění typických pravidel z konfigurace pro načtení do CD3

Konfigurace se vyměňují v maximální běžné verzi formátu výměny. Například jedna konfigurace má maximální formát 1,5, druhá 1,6, což znamená, že si mezi sebou budou vyměňovat ve formátu 1,5. Proto stačí uvolnit formát 1.5 z obou konfigurací a načíst jej do pravidel.

Konfiguraci BP 3.0 nebo UT 11.3 otevíráme v režimu konfigurátoru, do vyhledávacího pole můžete zadat „ muži uni”, Otevřete obecný modul. Pokud je to BP 3.0, otevřete jej. V otevřeném modulu přejděte do nabídky Soubor - Uložit kopii, uložte soubor s libovolným názvem, například „ D: \ Rules BP3 \ BP 3.0.54.15 \ Common module ExchangeManager Via UniversalFormat_Module».
Otevřete konfiguraci BP 3.0 nebo UT 11.3 v podnikovém režimu, otevřené zpracování \ tmplts \ 1c \ Konverze \ 3_0_5_3 \ Nahrát pravidla synchronizace.epf

Nedostatek typického zpracování:

často selhává;
uvolňuje pravidla z externího zpracování připojeného k uzlu, ale potřebujeme typická pravidla;
nefunguje v BP 3.0.53 a vyšší.

Úprava modulu hlavního zpracovatelského formuláře. Provádění změn v postupech OnCreateAtServer.

& AtServer Procedura OnCreateAtServer (Cancel, StandardProcessing) // Seznam výběru verzí formátu. Verze formátu = nová shoda; Data ExchangeRedefinable.WhenGettingAvailableFormatVersions (FormatVersions); Pro každý ExchangePlan z cyklu DataExchangeRepUsedExchangePlansBSP () If DataExchangeRepeat ThisExchangePlanXDTO (ExchangePlan) Then ExchangePlan Format Versions = New Match; Verze BSP243 = GeneralPurposeClientServer.CompareVersions (StandardSubsystemsServer.Library Version (), "2.4.3.1")> = 0; ModuleDataServer = General Purpose. CommonModule ("Data ExchangeServer"); If BSP243 Version Then ExchangePlaneFormatVersions = DataExchange ModuleServer.ExchangePlanSettingsValue (ExchangePlan, "ExchangeFormatVersions"); Jinak ExchangePlans [ExchangePlan] .GetExchangeFormatVersions (ExchangePlanFormatVersions); EndIf; Pro každý ExchangePlaneVersion od ExchangePlanFormatVersion Module CycleManager Module = FormatVersions.Get (ExchangePlaneVersion.Key); If Manager Unit = Undefined Nebo Manager Unit<>ExchangePlaneVersion.Value Then FormatVersions.Insert (ExchangePlaneVersion.Key, ExchangePlaneVersion.Value); EndIf; Konec cyklu; EndIf; Konec cyklu; Pro EachFormatVersion FROMFormatVersion.Loop Items.FormatVersionNumber.SelectionList.Add (FormatVersion.Key); Konec cyklu; FormatVersionStoreAddress = PutToTemporaryStore (verze formátu, UniqueIdentifier); Konec postupu

Vybereme „Formátovat číslo verze“, například „ 1.3 »,
„Adresář Exchange“ - vytvořte složku, například „“
Zmáčknout tlačítko " Vyložit».

Tyto kroky opakujeme pro další verze formátu a uložíme je do odpovídajících složek „1.4“, „1.5“ atd. U BP 3.0 stačí vyložit všechny formáty od 1.3 a výše. Pro ostatní konfigurace od 1.2 a vyšší.

Pravidla byla uvolněna, nyní je musíte načíst do KD3. V KD2 se pravidla načítají současně s vytvořením převodu. V CD3 musíte vytvořit převod a načíst do něj pravidla.
V sekci KD3 Konverze - Konverze - Vytvořit... ... Volba konfigurace. Pro usnadnění můžete název konfigurace změnit v režimu úpravy prvků. Například místo ÚčetnictvíPodniky označit " BP 3.0.54.15“. Rekvizity název není třeba měnit! název konverze lze zadat stejně, například „ BP 3.0.54.15“. V tabulkové části vyberte podporované verze formátu. Verze formátu jsou ty, které jsme stáhli z výše uvedené databáze. Ukládáme převod.

Přejděte do sekce Konverze - načítání pravidel synchronizace ze souborů.
:

Místo nakládky: " Do stávající konverze»

Adresář Exchange: " D: \ Pravidla BP3 \ BP 3.0.54.15 \ 1.3»

Soubor s modulem pro výměnu: " D: \ Rules BP3 \ BP 3.0.54.15 \ Common module Exchange Manager Via UniversalFormat13_ Module.txt»
Konverze: " BP 3.0.54.15»

Při načítání synchronizačních pravidel ze souborů pro UT 11.3 se zobrazí chyba " Pole objektu nebylo detekováno". Důvodem je, že TekPKO.UseForReceive = False CD3 vyžaduje po obdržení informace o možnosti identifikace. Pokud to není v souboru pravidel, dojde k chybě. Opravíme toto nedorozumění. Buď tento formulář odstraníme z podpory, nebo použijeme rozšíření.

// Hlavní forma zpracování LoadingSynchronizationRulesFromFiles // Před provedením změn: // Procedura načte pravidla pro převod objektů & Na proceduře serveru LoadPKO () ... FillProperty Values (TekPKO, Attribute Structure); // Možnost identifikace - speciální logika. TekPKO.ObjectIdentification Option = Enumerations.Object Identification Options [AttributesStructure.Identification Option]; ElseIf XMLReader.NodeType = XMLNodeType.EndItem Then // Napište načtený POC. ... // Změny jsou označeny "// ED" // Procedura načte pravidla pro převod objektů & Na proceduře serveru LoadPKO () ... FillProperty Values (TekPKO, Attributes Structure); // Možnost identifikace - speciální logika. If TekPKO.UseFor Získání Then // ED TekPKO.Identification Option = Enumerations.Object Identification Options [Attributes Structure.Identifying Option]; EndIf; ElseIf XMLReader.NodeType = XMLNodeType.EndItem Then // Napište načtený POC. ...

Zmáčknout tlačítko " Stažení». « Obslužné rutiny jsou určeny pro jinou konverzi: BP 3.0.44 (formát 1.4). Pokračovat ve stahování?"Kliknout" Ano».
Bez zavření formuláře vyberte jiný " Adresář Exchange"A stiskněte tlačítko" ". Opakujeme několikrát načítání pravidel pro každý formát do aktuálního převodu.
Po úspěšném načtení přejděte do sekce " Conversion "-" Konfigurace pravidel převodu“, Otevřete naši konverzi ze seznamu.
Pokud vidíme POD atd., Pak bylo načtení do CD3 úspěšné.

Kontrola správnosti pravidel načítání

Toto je volitelná operace! Pokud v pravidlech použijete stejnou verzi formátu, nemusíte dosáhnout identity textu modulu.

Otevřete konfigurátor BP, vytvořte nové externí zpracování, například Název „ Synchronizace EDBP", Synonymum pro" Synchronizace ED BP 3.0».
V KD3 ve tvaru " Nastavení pravidel výměny"Stiskněte tlačítko" "a vložte tento kód ze schránky do našeho nového zpracování.
V konfigurátoru BP kontrolujeme modul, zda neobsahuje chyby syntaxe. Ukládáme zpracování.
v BP vytvořte další prázdné zpracování, například Název „ Synchronizace EDB Typické", Synonymum pro" Typická synchronizace ED BP 3.0“. Zkopírujte text obecného napájecího modulu Exchange Manager prostřednictvím univerzálního formátu13 do modulu zpracování a uložte jej.

Porovnejme obě léčby. Jídelní lístek Soubor - Porovnání souborů.

Pokud standardní modul obsahuje postupy, které v našich pravidlech chybí, znamená to, že jste nenačetli pravidla pro převod pro všechny datové formáty. Pokud je třeba načtěte pravidla do chybějícího formátu do převodu a zopakujte srovnání našich pravidel se standardními. Když jsme dosáhli identity můžete bezpečně přistoupit k finalizaci pravidel... Není nutné dosáhnout úplné identity, pokud víte, který z formátů výměny nebude použit pro synchronizaci.

Podobným způsobem vytvoříme převod pro UT 11.3 v KD3.

BP 3.0.54.15

Puntíkovaný nesprávné načítání PKO " Reference_Uživatelé„Je třeba opravit.
V PKO " Document_Product Inventory_Shipment"pro PKS" Odpovědná osoba"není specifikován PQS. Otevřete, znovu vyberte vlastnost konfigurace a vlastnost formátu, abyste vyplnili jejich typ, a poté výběr v" Pravidlo převodu majetku". Vyberte" Directory_Persons_Send".

Zvažte příklad revize

Hlavním účelem příkladu je ukázat možnosti vylepšení pro přenos dalších dat, která se nevejdou do výměnného formátu.

Musíte převést rekvizity “ TypNomenklatura"referenční kniha" Nomenklatura ", typ proměnné" Directory.ViewsNomenclatures". Tento druh příručky není standardními pravidly KD3 podporován a není podporován verzí formátu ED pod 1.6."

Existuje několik možností, jak tento problém vyřešit.

Úprava balíčku XDTO, přidání objektu "Reference.Nomenclature Types" do formátu. V důsledku toho se ztrácí hlavní výhoda univerzálního formátu - přestává být univerzální. Úprava balíčku XDTO bude vyžadována ve všech databázích účastnících se výměny.
Použít vlastnost formátu " Další detaily", což je v mnoha objektech. Tato možnost nebude v tomto článku zvažována kvůli nějaké složitosti. Všimněte si, že taková metoda existuje."
Rekvizity Doplňující informace. Je přítomen v záhlaví všech formátových objektů. Jakýkoliv typ. Navrženo pro takové případy. Použijeme to jako nejjednodušší způsob.

Než budeme pokračovat v upřesňování standardních pravidel, vytvořme dvě skupiny ve skupině pravidel „ Přidal», « Změněno“. To se provádí v " Konverze -".
Nové POD, PKO, algoritmy atd. vytvoříme ve skupině „Přidáno“, standardní objekty, u kterých provedeme změny, budou přeneseny do skupiny „Změněno“. To usnadní následnou údržbu změněných pravidel.

Začněme tedy.

Změny pravidel v UT 11.3

V KD3 ve tvaru " UT 11.3.4.12 Nastavení pravidel výměny„Na kartě Algoritmy vytvoření nového algoritmu

Název algoritmu „AdditionalInfoInsert“
Skupina: „Přidáno“

Parametry: „DataXDTO, název, další hodnota“

Kód algoritmu

Pokud DataXDTO.Property ("AdditionalInfo") AND TypeValue (DataXDTO.AdditionalInfo) = Type ("Structure") Then AdditionalData = DataXDTO.AdditionalInfo; Jinak AdditionalData = nová struktura; EndIf; AdditionalData.Insert (Název, AdditionalValue); DataXDTO.Insert ("AdditionalInfo", AdditionalData);

Algoritmus uložíme a přejdeme na „ Pravidla převodu objektů»

Tlačítkem " Nalézt"Hledáme" Nomenklaturu ", otevřete PKO" Reference_Nomenclature_Send“. Přejít na kartu " Při odesílání“. Tam vidíme pole „Jméno psovoda:“ „“. Změny můžete provádět přímo tam.
Složitější kód, který vyžaduje ladění, lze zapsat do konfigurace. Hledáme do výměnného modulu v UT 11.3 proceduru s názvem „ PQS_Reference_Nomenclature_Send_When SendingData„A dokončuji to tam.
Chcete -li přenést změny z UT 11.3 do KD3, zkopírujte celý postup do schránky, do KD3 ve tvaru „ Nastavení pravidel výměny"Zmáčknout tlačítko" ".

V našem případě je kód

If ValueFilled (DataIB.NomenclatureView) Then // ED AdditionalInfoInsert (DataXDTO, "NomenclatureView", String (DataIB.NomenclatureView.UniqueIdentifier ())); InsertInfo Insert (XDTO Data, "NomenclatureNomenclatureName", General Purpose.ObjectAttributeValue (DataIB.NomenclatureView, "Name")); // AdditionalInfo Vložit ... // přidat další podrobnosti o službě EndIf;

Po přenesení změn do KD3 stiskněte tlačítko " Uložte modul správce výměny"a přeneste kód z vyrovnávací paměti do modulu UT 11.3.

Změny pravidel v BP 3.0

Provádíme změny v PKO “ Reference_Nomenclature_Getting", na" Při převodu dat XDTO", název procedury" PKO_Reference_Nomenclature_Getting_WhenXDTODataConversion".

Kód přidán do modulu „PKO_Reference_Nomenclature_Getting_WhenXDTODataConversion“

Pokud DataXDTO.Property ("AdditionalInfo") AND TypeValue (DataXDTO.AdditionalInfo) = Type ("Structure") Then // ED AdditionalData = DataXDTO.AdditionalInfo; If AdditionalData.Property ("NomenclatureType") ThenNomenclatureType = ExchangeDataXDTOServer.ObjectLinkPoUIDObjectXDTO (AdditionalData.NomenclatureView, Type ("DirectoryLink.NomenclatureType"), Exchange Components); IfNomenclature.GetObject () = Undefined AND AdditionalData.Property ("NomenclatureKindName") Then // Create a newNomenclatureKindObject = Directories.NomenclatureTypes.CreateElement (); NomenclatureKindObject.SetNewLink (NomenclatureKind); Nomenclature typeObject.Name = AdditionalData.Nomenclature typeName; // vyplňte další podrobnosti služby FillPropertyValues (NomenclatureKindObject, AdditionalData); NomenclatureKindObject.Write (); NomenclatureKind = NomenclatureKindObject.Ref; EndIf; ReceivedData.NomenclatureType = NomenclatureType; EndIf; EndIf;

Samotný kód nestačí. Na záložku "Pravidla převodu vlastností" je nutné přidat PKS s konfigurační vlastností "" a zaškrtávacím políčkem " Použitý konverzní algoritmus".

Modul správce výměny přeneseme do konfiguračního modulu BP 3 nebo na externí zpracování.

Jak nahrát upravená pravidla CD3 do databáze?

V konfiguracích vyměňujících pravidla na CD2 se to provádí v nastavení uzlu. U pravidel vytvořených v KD3 tam uvidíme pouze možnost změnit pravidla registrace.

Pravidla připravená v KD3 lze do konfigurace nainstalovat třemi způsoby

Odeberte konfiguraci z podpory a proveďte změny ve společném modulu Exchange Manager prostřednictvím univerzálního formátu;
U konfigurací spuštěných v režimu kompatibility platformy 8.3.10 a vyšším můžete sdílený modul opravit pomocí rozšíření.
Připojte rozšíření, které zcela nahradí obecný modul pravidly.
Připojte externí zpracování s pravidly k uzlu bez odebrání konfigurace z podpory;

U první možnosti je vše jasné, je to popsáno v dokumentaci, nevýhodou je, že musíte odebrat konfiguraci z podpory. Druhá možnost - oprava zvoleného postupu pomocí rozšíření také nebude pro programátora 1C obtížná - musíte porovnat obě zpracování se standardními pravidly a s upravenými, jak je popsáno výše v tomto článku, a provést změnu požadovaného postup.

Třetí možnost je pomocí rozšíření s pravidly výměny v univerzálním formátu aktuálně nejoptimálnější. Existuje pouze jedna nevýhoda - je nutné odstranit vlajku " Nouzový režim"při připojování tohoto rozšíření. To omezuje jeho použití v cloudové služby... Čekáme na rozhodnutí od 1C o postupu při výměně pravidel výměny v univerzálním formátu v 1C fresh.

Pointa je, že v konfiguraci musíte najít část kódu, která odpovídá za výběr společného modulu, v závislosti na verzi formátu výměny, a nahradit výběr modulu vlastním modulem. Příklad pro BP 3.0.67:

//////// // Obecný modul pro výměnu dat přepsán a namísto („Při získávání dostupných verzí formátu“) postup ED_ při získávání dostupných verzí formátu (verze formátu) ED_Exchanging DataServer.Při získávání dostupných verzí formátu (verze formátu) ; EndProcedure //////// // Synchronizace dat plánu plánu pomocí univerzálního formátu: modul správce # Pokud je server nebo tlustý klient běžná aplikace nebo externí připojení, pak místo toho (postup „Při přijímání nastavení“) ED_Při přijímání nastavení (nastavení) Nastavení .DefaultName = GeneralConfigurations; Settings.ThisExchangePlanXDTO = True; Settings.WarningOnMismatchRuleVersions = False; Settings.ExchangeFormat = "http://v8.1c.ru/edi/edi_stnd/EnterpriseData"; Verze formátu = nová shoda; ED_DataServer.When Receiving AvailableFormat Versions (Format Versions); // ED Settingss.ExchangeFormatVersions = FormatVersions; Settings.ExchangePlanUsedInServiceModel = True; Settings.Algorithms.WhenGettingExchangeSettingsVariants = True; Settings.Algorithms.OnGettingOptionDescriptionSettings = True; Settings.Algorithms.InteractiveOffsetSelection View = True; Settings.Algorithms.ConfigureInteractiveOffload = True; EndProcedure #EndIf ////////// // Obecný modul v rozšíření ED_DataServer Procedura OnGetAvailableFormatVersions (FormatVersions) ExportFormatVersion.Insert ("1.2", ExchangeManagerViaUniversalFormat); Formát Versions.Insert ("1.3", ED_ExchangeManagerViaUniversalFormat); Formát Versions.Insert ("1.4", ED_ExchangeManagerViaUniversalFormat); Formát Versions.Insert ("1,5", ED_ExchangeManagerViaUniversalFormat); Formát Versions.Insert ("1.6", ED_ExchangeManagerViaUniversalFormat); EndProcedure //////// // Společný modul v rozšíření ED_ExchangeManager Prostřednictvím UniversalFormat // Převod BP3.0.44 (formát 1.6) z 27. 11. 2018 11:23:58 // Vylepšení pro BP 3.0.67. x od 31.12 ... ...

Zvažme 4. možnost, která není v dokumentaci popsána, protože v BSP taková možnost není. Tato možnost je již zastaralá. Externí zpracování s pravidly byl použit v prvních verzích s univerzálním výměnným formátem. Nyní se 1C této funkce postupně zbavuje.

V podnikovém režimu klikněte v sekci pro správu na odkaz Data Sync - Nastavení synchronizace dat, zmáčknout tlačítko " Naladit...„pokud je nastavení jedno nebo“ Změna"pokud existuje několik nastavení. Přejít do režimu úpravy formuláře prostřednictvím nabídky" " , Rozbalit " Skupina", zahrneme skrytý prvek formuláře" "," OK".
Na " Servisní informace"Vybrat" Cesta ke správci burzy“, nahrazujeme naše zpracování tamními pravidly.

Připojení externího zpracování s pravidly k BP 3.0.52 a vyšším

V BP 3.0.52 a vyšším z neznámých důvodů externí zpracování s pravidly se nepoužívá. Rozhraní pro připojení zpracování zůstává. Díky za to.

Zpracování pomocí pravidel můžete povolit pomocí rozšíření. Společný modul je třeba opravit " Server pro výměnu dat XDTOS", funkce" Formát VerzeExchange".

EDm_PoluchitVersiyuFormataObmena postup (VersiiFormata znamená UzelInformatsionnoyBazy) query = nový dotaz ( „vybrat různé | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzheruObmena AS PutKMenedzheruObmena, | SinhronizatsiyaDannyhCherezUniversalnyyFormat.VersiyaFormataObmena AS VersiyaFormataObmena | Z | PlanObmena.SinhronizatsiyaDannyhCherezUniversalnyyFormat SinhronizatsiyaDannyhCherezUniversalnyyFormat JAK | kde | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzheruObmena<>"" "" | A synchronizace dat přes GenericFormat.Ref = & Link "); Query.SetParameter (" Reference ", InformationBase Node); Fetch = Query.Run (). Select (); While Fetch.Next () Loop ProcessingName = Fetch.Path to správce, pokud SharedOnder NENÍ k dispozici; () Then ProcessingData = New BinaryData (ProcessingName); ProcessingAddress = PutToTemporaryStore (ProcessingData); If GeneralPurpose.There is Protection Against Dangerous Actions () Then ProcessingName = ExternalProcessing.Descriptions. EndIf; EndIf; ExchangeMan = ExternalProcessing.Create (ProcessName); Format Versions.Insert (Selection.ExchangeFormatVersion, ExchangeManager); End of Loop; EndProcedure & instead of ("ExchangeFormatVersion") EDMNodeVersionNodeVersionValue Přidáno (uzel InfoBase) Potom ExchangePlaneName = InfoBaseNode.Metadata () .Name; ExchangeFormatVersions = DataExchangeServer.ExchangePlanSettingsValue (ExchangePlaneName, "ExchangeFormatVersions"); EDm_GetExchangeFormatVersion (ExchangeFormatVersions, InformationBase Node); JinakDataExchangeRedefinable.WhenGettingAvailableFormatVersions (ExchangeFormatVersions); EndIf; Pokud ExchangeFormatVersions.Number () = 0 Then CallExceptionStringFunctionsClientServer.SubstituteParametersVSString (NStr ("ru =" Verze formátu Exchange nejsou zadány. | Název plánu výměny:% 1 | Postup: GetExchangeFormatVersions (<ВерсииФорматаОбмена>) ""), DatabaseNode.Metadata (). Název); EndIf; Výsledek = Nový zápas; Pro každou verzi FromVersionFormatExchange Cycle Result.Insert (AbbrLP (Version.Key), Version.Value); Konec cyklu; Výsledek vrácení peněz; Koncová funkce

Jak ladit pravidla v externím zpracování

V konfigurátoru " Služba -> Parametry -> Start 1C: Enterprise -> Start Parameter", zadejte parametr" ".

Níže je uveden kód rozšíření pro UT 11.4, KA 2.4, ERP 2.4. Kód pro BP 3.0 je uveden výše. Modul správce plánu Exchange Synchronizace dat pomocí univerzálního formátu.

Ladicí kód ED rozšíření

& Místo („GetExchangeFormatVersions“) Procedura ED_GetExchangeFormatVersions (FormatVersions) DataExchangeUT.AvailableUniversalFormatVersions (FormatVersions); Požadavek = Nový dotaz („VYBRAT JINAK | Synchronizace dat přes UniversalFormat.PathTo Exchange Manager, | Synchronizace dat přes UniversalFormat.ExchangeFormatVersion | OD | Výměnný plán.<>"" "" "); Fetch = Query.Execute (). Select (); While Fetch.Next () Loop ProcessingName = Fetch.PathToExchange Manager; IF NOT SharedPurposeClientServer.Debug Mode () Then // EDProcessingData = New BinaryData) (( NameProcessingData; AdresObrabotki = PomestitVoVremennoeHranilische (DannyeObrabotki) Pokud ObschegoNaznacheniya.EstZaschitaOtOpasnyhDeystvy () Poté ImyaObrabotki = VneshnieObrabotki.Podklyuchit (AdresObrabotki, ObschegoNaznacheniya.OpisanieZaschityBezPreduprezhdeny ()), jinak ImyaObrabotki = VneshnieObrabotki.Podklyuchit (AdresObrabotki); ENDIF; ENDIF; MenedzherObmena VneshnieObrabotki.Sozdat = ( ImyaObrabotki) VersiiFormata.Vstavit (Vyborka.VersiyaFormataObmena, MenedzherObmena) KonetsTsikla; KonetsProtsedury a místo ( "DostupnyeVersiiFormataObmena") ED_DostupnyeVersiiFormataObmena postup (VersiiFormata) ObmenDannymiUT.DostupnyeVersiiUniversalnogoFormata (VersiiFormata) Query = new dotaz ( „volit různé | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzher na burze, | Data SynchronizationViaUniversalFormat.ExchangeFormatVersion | OD | Exchange Plan. Synchronizace dat Prostřednictvím UniversalFormat AS Synchronizace dat prostřednictvím UniversalFormat | KDE | Synchronizace dat prostřednictvím univerzálního formátu. Cesta k Exchange Manager<>"" "" "); Fetch = Query.Execute (). Select (); While Fetch.Next () Loop ProcessingName = Fetch.PathToExchange Manager; IF NOT SharedClientServer.Debug Mode () Then // EDProcessingData = New BinaryData) (( NameProcessingData; AdresObrabotki = PomestitVoVremennoeHranilische (DannyeObrabotki) Pokud ObschegoNaznacheniya.EstZaschitaOtOpasnyhDeystvy () Poté ImyaObrabotki = VneshnieObrabotki.Podklyuchit (AdresObrabotki, ObschegoNaznacheniya.OpisanieZaschityBezPreduprezhdeny ()), jinak ImyaObrabotki = VneshnieObrabotki.Podklyuchit (AdresObrabotki); ENDIF; ENDIF; MenedzherObmena VneshnieObrabotki.Sozdat = ( ProcessingName); Format Versions.Insert (Fetch.ExchangeFormatVersion, ExchangeManager); EndLoop; EndProcedure

Ladění se nejsnadněji provádí v databázi souborů. Nastavili jsme zarážku při zpracování pomocí pravidel. Chcete -li najít požadovaný postup, použijte KD3. Našli jsme PKO, POD nebo algoritmus, podívejte se " Jméno obsluhy"nebo" Název algoritmu", tento postup hledáme v modulu pravidel. Po úpravě modulu nezapomeňte postup zkopírovat do schránky a v CD3 stisknout tlačítko" ". Pozor, stejný převod musí být otevřený.

To je prozatím vše. Tyto informace jsou již dost na to, aby 1C programátor dokázal samostatně zvládnout KD3 a udržovat moderní způsob synchronizace mezi 1C základnami v provozuschopném stavu. Pokud jsou bílá místa, zeptejte se, článek bude doplněn a můžete se k němu vrátit, pokud jste na něco zapomněli.

Známé odkazy na dokumentaci k KD3:

1C-Training Center No. 3, „Data Conversion 3.0“-http://www.1c-uc3.ru/konvert30.html

Rozsah použití KD3 můžete rozšířit pomocí těchto publikací:

- konfigurace předchozích verzí na platformě 8.2 a níže jsou kompatibilní s ED.

Ušetřete čas a použijte hotová pravidla pro nejnovější verze konfigurace najdete zde

- rozšířená funkčnost, opravy chyb.

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 burza konfigurována mezi konfiguracemi „Trade Management 11.2“ (dále jen UT) a „Enterprise Accounting 3.0.43“ (dále jen BP). Výměna je jednosměrná, od UT do BP. Před upgradem z Trade Management 11.1 na verzi 11.2 byla výměna dat konfigurována pomocí konfigurace Data Conversion 2.0. Po přepnutí na „11.2“ v „Trade Management“ se však v práci uživatelů objevily chyby. Byl proveden postup aktualizace pravidel výměny, ale nepřinesl to žádný výsledek. Ladicí program ukázal, že problém je v komunikaci. Bylo rozhodnuto odstranit nastavení komunikace v obou konfiguracích a znovu jej nastavit.

„Trade Management“ i „Enterprise Accounting“ pro nás fungují ve verzi klient-server. Začal jsem nastavovat synchronizaci s UT. Spustil jsem to tak, že data byla uvolněna z UT do souboru. Tedy synchronizaci přes síťový adresář. V napájecí jednotce jsem nastavil výměnu tak, aby se z napájecí jednotky nevykládala žádná data.

Při volání kontextové metody (Kontrola) došlo k chybě: Chyba při kontrole dat XDTO:
Struktura objektu „/Bankovní účet protistrany/Banka“ neodpovídá typu: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)
Kontrola vlastnosti „BIC“:
Tvar: Prvek
název: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1) BIC
Typ:
Chybí požadovaný majetek
Předmět: Smlouva s protistranou č. ...

Abych chybu analyzoval, klikl jsem na ikonu „Složení dat k odeslání“ a v seznamu dodavatelů registrovaných k odeslání jsem našel dohodu, podle které se objevila chyba. Otevřel smlouvu, pamatoval si bankovní účet protistrany uvedený ve smlouvě. Poté jsem přešel na bankovní účty registrované k odeslání. Ukázalo se, že požadovaný účet není v seznamu registrovaných. Znovu jsem odeslal problémový bankovní účet a smlouvu. Poté jsem požadovaný bankovní účet zaregistroval ručně.

Zkusil jsem znovu synchronizovat data z UT. Tentokrát byla data úspěšně uvolněna. PROTI síťová složka tvořil XML soubor obsahující data pro přenos z UT do BP.

Dalším krokem je načtení dat ze souboru do oddělení podnikového účetnictví. V konfiguraci „Podnikové účetnictví“ jsem stiskl tlačítko „Synchronizovat“, otevřel se zpracovávací formulář se zprávou „Probíhá analýza dat“. O něco později se zpráva změnila na „Vykládání dat“. Indikátor a počitadlo zároveň ukazovaly, že z napájecí jednotky bylo vykládáno více než 80 tisíc předmětů. To mě zmátlo, protože jsem v nastavení naznačil, že z napájecí jednotky by se nemělo nic vykládat. Zpracování trvalo poměrně dlouho a skončilo chybou:

Událost: Výměna dat
(SharedModule.LongedOperations.Module (371)): Pracovní postup úlohy na pozadí byl neobvykle ukončen
CallException (ErrorText);

Abych chybu lokalizoval, pokusil jsem se změnit nastavení synchronizace a možnosti provozu základny BP. V důsledku toho, když jsem přepnul databázi na verzi souboru, 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.

Při dalším „záběhu“ synchronizace bylo nutné provést určité změny pravidel pro převod objektů. Nyní je čas použít konfiguraci Data Conversion 3.0. Online pomoc s konfigurací popisuje, jak pracovat. Pomohly také články na webu ITS.

V důsledku toho jsem do „Data Conversion 3.0“ nahrál následující data:

Texty společného modulu „DataExchangeManagerViaUniversalFormat“ ze dvou základen
Schéma obou základen
Popis formátu EnterpriseData (z jakékoli databáze)
Pravidla převodu

Po načtení jsem otevřel pravidla pro převod dat, objektů, vlastností v „Data Conversion 3.0“. Provedl pro mě potřebné úpravy. Poté jsem použil tlačítko „Vyložit modul správce směnárny“. Text modulu byl zkopírován do schránky. Zbývá ji pouze vložit do konfigurace.

Po experimentování s nastavením pravidel v „Data Conversion 3.0“ jsem pro sebe dospěl k závěru, že v případě, kdy jsou provedené změny nevýznamné, je jednodušší nastavit pravidla přímo v konfiguracích UT a BP, v obecném modulu „DataExchange ManagerVia UniversalFormat “. Pokud jsou úpravy závažné, jako například přidání nového objektu do ústředny, měli byste použít konfiguraci " Konverze dat 3,0 ".

Úkol přidat dokument „Objednávka dodavateli“ do plánu výměny jsem provedl pomocí „ Konverze dat 3,0 ". standardní verze UT - BP tohoto dokumentu ve výměnném plánu není.

Pamatujte, že pravidla pro registraci objektů pro nahrávání jsou stále konfigurována 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 a svá vlastní vyjádření k výměně dat prostřednictvím univerzálního formátu a konfigurace “ Data Conversion 3.0 ", napište do komentářů. Vyměníme si zkušenosti.

Synchronizace dat
Obecný formát dat Enteprise
Konverze dat 3.0
Konverze dat 2.0
Řízení obchodu
Podnikové účetnictví

Podívejme se na jednoduchý příklad ze skutečného života. Řekněme, že máme společnost, která se zabývá velkoobchodem a maloobchodem, stejně jako v této společnosti, stejně jako v jakékoli jiné, se provádí účetnictví. Podnik má dvě standardní základny, a to UT (správa obchodu) a BP (podnikové účetnictví). Každá ze základen si vede vlastní účetnictví, v UT managementu odráží všechny účetní transakce související s obchodem v účetnictví BP. Abychom nedělali dvojitou práci, tj. nevytvářejte stejné dokumenty ve dvou základnách (koneckonců pohyby musí být pro správu a účetnictví) právě nastavíme synchronizaci mezi těmito základnami.

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

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

Začněme nastavovat synchronizaci, nejprve přejděte k databázi (přijímač) 1C „Enterprise Accounting 3.0“, musíme zkontrolovat, zda je pro tuto databázi povolena synchronizace, abychom to mohli udělat, musíme nejprve přejít do databáze. Jakmile se základna otevře, přejděte na kartu "Správa" ---> "Nastavení synchronizace dat"

Před námi se otevře nová karta, kterou je třeba vyplnit stejným způsobem jako na níže uvedeném snímku obrazovky, s výjimkou předpony infobase. Předpona by měla sestávat 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 „podnikové účetnictví“ bude předpona „BP“. Pokud nastavujete složité burzy a existuje několik účetních databází, předpony by se od sebe měly jasně lišit, zde můžete použít první dvě písmena názvu organizace jako zkratku.

Pokračujeme v konfiguraci synchronizace dat v UT

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

V novém okně, které se objeví, musíte kliknout na zelené znaménko plus (Konfigurovat synchronizaci dat), v rozevírací nabídce vyberte položku „Podnikové účetnictví 3.0“.

Konfigurace důležitých bodů při výměně dat mezi UT a PSU

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

Pokračujeme v konfiguraci výměny dat v 1C, na další kartě musíme vybrat možnost připojení k infobáze přijímače ( přímé spojení do programu), parametry připojení (na tento počítač nebo v lokální síť), adresář, kde se nachází základna příjemce, a také potřebná ověřovací data (uživatelské jméno a heslo v základně).

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

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

Který NSI bude odeslán (v našem příkladu nás zajímají pouze dokumenty a v nich použitý NSI, takže jsme přešli na příslušnou položku, pokud vyberete první položku „Odeslat vše“, pak se všechny adresáře znovu načtou spolu s dokumenty, často pokud informace v dokumentech nejsou použity, pak jsou pro příjemce zbytečné, protože nijak neovlivňují účetnictví)
Od jakého data posílat všechny informace (v tomto článku nebudeme zvažovat ruční synchronizaci)
Pro které nebo kterým organizacím zasílat data (v našem příkladu jsme vybrali jednu organizaci IE „Podnikatel“)
Pravidla pro tvorbu smluv
Generalizovaný sklad
Zda skládat dokumenty ve skladu

Jakmile provedeme 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, od UT do BP, pak nás nastavení pravidel pro získávání dat z „Enterprise Accounting 3.0“ nezajímá, proto klikněte na „Další“.

V novém okně jsme pozváni ke konfiguraci pravidel pro základnu přijímače (BP). V bodě 1 nazýváme naší základně nějaké jméno, dáme mu předponu. PREFIX by měl být stejný, jaký jsme nastavili v samotné databázi BP na začátku tohoto článku, pokud se prefixy liší, synchronizace dat v programu 1C nebude fungovat. Poté stiskneme bod 2 a poté bod 3.

V odstavci 3 musíme povolit zveřejňování dokumentů při jejich načítání 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 vytvořené synchronizaci v 1C. Stačí kliknout na tlačítko „Další“. Pokud program při nastavování synchronizace dat zobrazí chybu, musíte nás kontaktovat, aby vám náš specialista 1C právě teď pomohl!

V dalším kroku program nabídne provedení synchronizace ihned po vytvoření nastavení výměny dat... Souhlasíme s tím a klikneme na „Dokončit“.

Před vámi se zobrazí okno, ve kterém uvidíte informace o tom, jak synchronizace probíhá. Pokud základna přijímače není prázdná, tj. protože v něm již bylo vedeno účetnictví, bude uživatel v programu 1C vyzván k ručnímu porovnání objektů. Porovnání objektů v 1C během synchronizace dat je srovnání stejných objektů přijímače se stejnými objekty ve zdroji.

Uvažujme příklad, řekněme, že v UT existuje protistrana s názvem „PharmGroup LLC“ a TIN 1234567 a BP má také protistranu s TIN 1234567, ale název „PharmGroup“, pokud tyto dva objekty neporovnáme, když 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 předešlo takovým situacím, byl vynalezen mechanismus pro párování předmětů.

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

Konečná 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“. Tím je dokončena synchronizace mezi základnami v jednosměrné výměně z „Trade Management 11.1“ (UT) do „Enterprise Accounting 3.0“ (BP).

Automatizované systémy správa ve většině případů sestává z oddělených databází a často má geograficky distribuovanou strukturu. Správně implementovaná výměna dat je přitom předpokladem efektivního provozu takových systémů.

Počáteční nastavení výměny přitom může vyžadovat řadu akcí, a to nejen z hlediska programování, ale i poradenství, i když máme co do činění s homogenními zdroji, jako je tomu u produktů na platformě 1C: Enterprise. Proč se nastavení výměny 1C (nebo, jak se jí také říká synchronizace dat v 1C 8.3) může stát časově nejnáročnějším a nejdražším úkolem integračního projektu, se budeme zabývat v tomto článku.

Výměna dat v prostředí 1C umožňuje:

Vyloučit podvojné zadávání dokumentů;
Automatizace souvisejících obchodních procesů;
Optimalizace komunikace mezi distribuovanými jednotkami;
Rychle aktualizovat data pro práci specialistů z různých oddělení;
„Vymezte“ různé druhy účetnictví. *

* V případě, že se údaje jednoho typu účetnictví výrazně liší od jiného, je nutné zajistit důvěrnost informací a „ohraničit“ informační toky. Například výměna dat mezi 1C UT a 1C Accounting nevyžaduje nahrání dat správy do běžné účetní databáze, tj. zde nebude synchronizace v 1C kompletní.

Pokud představujeme standardní proces implementace primární výměny dat, když alespoň jeden z jejích objektů je produkt 1C, lze rozlišit následující fáze:

Koordinace složení burzy;
Definice transportu (výměnné protokoly);
Nastavení pravidel;
Plánování.

Odhalení složení burzy 1C

Předměty lze podmíněně rozdělit na „zdroj“ a „přijímač“. Současně mohou vykonávat dvě role současně, kterým se bude říkat - dvoustranná výměna. Určení zdroje a cíle probíhá logicky, v závislosti na potřebě nebo na funkčnost Systém. *

* Například při integraci WA: Financier, řešení pro finanční účetnictví a řízení procesů treasury, vyvinutého na základě 1C: Enterprise, jej odborníci WiseAdvice doporučují jako hlavní systém. Důvodem je dostupnost ovládacích nástrojů, které jsou v souladu s pravidly aplikační politiky, a v souladu s tím zajišťuje účinnost řešení.

Dále je na základě přijatých a zaznamenaných požadavků od uživatelů vytvořen seznam dat pro výměnu, je určen jejich objem, požadavky na frekvenci výměny, je zpracován proces práce s chybami a zpracování výjimečných situací (kolizí) předepsané.

Ve stejné fázi se v závislosti na flotile stávajících systémů a struktuře podniku určí formát výměny:

Distribuovaná informační základna

RIB znamená výměnu mezi identickými konfiguracemi 1C databází s jasnou strukturou řízení master-slave pro každý pár výměn. Jako prvek technologické platformy může RIB kromě dat přenášet změny v konfiguračních a administrativních informacích databáze (ale pouze z masteru do slave).

Univerzální výměna dat v 1C

Mechanismus, který vám umožňuje konfigurovat výměnu databází 1C, a to jak s konfiguracemi na platformě 1C: Enterprise, tak se systémy třetích stran. Výměna probíhá převodem dat do univerzálního formátu xml v souladu s „výměnnými plány“.

EnterpriseData

Nejnovější vývoj 1C, navržený k implementaci výměny dat ve formátu xml mezi produkty vytvořenými na platformě 1C: Enterprise s jakýmikoli automatizačními systémy. Použití EnterpriseData zjednodušuje vylepšení související s výměnou. Dříve, když byla do systému zahrnuta nová konfigurace, bylo nutné implementovat mechanismus pro import a export dat, a to jak pro něj, tak pro stávající systémy. Nyní systémy podporující EnterpriseData nepotřebují žádné úpravy, protože mají pouze jeden bod „vstup-výstup“.

Definice transportu (výměnné protokoly)

Pro systém založený na platformě 1C: Enterprise 8 je k dispozici široká škála příležitostí pro organizaci výměny s jakýmikoli informačními zdroji prostřednictvím obecně uznávaných univerzálních standardů (xml, textové soubory(Excel, připojení ADO atd.). Při definování transportu pro výměnu dat byste proto měli vycházet z možností systémové databáze třetí strany.

Synchronizace adresářů

Hlavním principem efektivní synchronizace adresářů je přítomnost jednoho vstupního bodu. Pokud ale mluvíme o práci s referenčními knihami, které byly historicky vyplňovány podle různých pravidel, je nutné jasně definovat synchronizační pole, aby se směna stala „společným jmenovatelem“. *

* V této fázi může být nutné provést práci na normalizaci referenčních dat na straně zdroje dat. V závislosti na stavu referenčních knih a jejich objemu může proces párování prvků, rozpoznávání, detekce chyb a duplikátů, stejně jako vyplňování chybějících polí a přiřazování synchronizačních polí, vyžadovat práci celé skupiny odborníků, a to jak z integrátor (vlastník standardizační metody referenčních dat) a ze strany zákazníka.

Nastavení pravidel

Možnost zobrazit data ze zdrojových systémů v přijímačích závisí na správně zadaných pravidlech výměny. Pravidla uvedená ve formátu xml upravují korespondenci klíčových atributů objektů cílového zdroje. Řešení 1C: Data Conversion je navrženo tak, aby automatizovalo vytváření pravidel pro implementaci jednorázové i trvalé výměny.

Zajišťuje žádnou ztrátu dat při výměně plánu výměny. Toto je nedílnou součástí jakékoli konfigurace na platformě 1C: Enterprise, která plně popisuje postup pro výměnu 1C: složení dat (dokumenty s „identifikačními“ detaily) a uzly ( informační základny vysílače-přijímače), stejně jako aktivace RIB pro vybrané směry směny.

Jakákoli změna v údajích zadaných do burzovního plánu je zaznamenána a obdrží znak „změny“. Dokud se změněná data v uzlech vysílač-přijímač vzájemně neshodují, příznak nebude vymazán a systém bude odesílat řídicí zprávy do obou uzlů. Po vyložení dat a potvrzení jejich úplné shody v obou systémech se značka resetuje.

Plán výměny v 1C

K automatizaci pravidelné výměny je nastavena frekvence odesílání dat. Frekvence výměny závisí na potřebě a technických možnostech. Konfigurace na platformě 1C: Enterprise vám také umožňují nastavit výměnu dat, když dojde k události.

Po zvážení procesu implementace standardní výměny věnujme pozornost faktorům, které budou vyžadovat zlepšení v různých fázích:

Netypické, vysoce modifikované konfigurace databáze;
Různé verze 1C: Podnikové platformy;
Dlouho neaktualizováno, ne aktuální verze konfigurace;
Předměty, které dříve prošly úpravami;
Potřeba nestandardních pravidel výměny;
Velmi odlišný soubor a složení požadavků ve stávajících referenčních knihách.

Protože i standardní akce pro implementaci primární výměny dat vyžadují odborné znalosti, doporučuje se, aby byly prováděny za účasti specialistů 1C. Teprve po dokončení všech výše uvedených kroků byste měli pokračovat v nastavení výměny v konfiguraci. Uvažujme integraci databází na příkladu „1C: UPP“ a „1C: Retail“ (podle stejného schématu je nakonfigurována výměna s „1C: UT“). Typická synchronizace také zahrnuje výměnu SCP - SCP, což je typické pro rozsáhlé automatizační systémy v největších průmyslových podnicích.

V podnabídce „Služba“ vyberte „Výměna dat s produkty na platformě ...“ (volba přímé výměny s „Maloobchodem“ často hrozí chybami na úrovni objektů COM). Věnujte pozornost servisní zprávě „Tato funkce není k dispozici“.

Chcete -li tento problém vyřešit, musíte vybrat „Nastavení komunikace“

... a zaškrtněte políčko. Dále chybovou zprávu ignorujeme.

V nastavení synchronizace dat vyberte „Vytvořit výměnu pomocí„ Maloobchod “...

Před konfigurací nastavení pro připojení prostřednictvím místního nebo síťového adresáře se ujistěte, že je na disku dostatek místa pro adresář. I když to zpravidla nezabere více než 30–50 MB, ve výjimečných případech to může vyžadovat až 600 MB. Požadovaný adresář můžete vytvořit přímo z konfigurátoru.

Při připojení přes síťový adresář nabízí nabídky konfigurace připojení přes FTP adresu a přes e-mailem ignorovány kliknutím na „Další“.

V nastavení ručně odložíme předpony - konvence základen (zpravidla BP, UPP, RO), nastavíme pravidla a datum zahájení nahrávání dat. Předpona bude uvedena v názvu dokumentů, aby označila základ, ve kterém byly vytvořeny. Pokud pravidla pro vykládku nejsou upravena, data se ve výchozím nastavení uvolní pro všechny dostupné parametry.

Vytváříme soubor nastavení výměny pro „Maloobchod“, aby se naše akce neopakovaly. Pokud potřebujete odeslat data ihned po nastavení synchronizace, zaškrtněte políčko.

Chcete -li automatizovat proces výměny, musíte nastavit plán.

Maloobchodní menu.

Zaškrtněte políčko a vyberte „Synchronizace“.

Nastavení „obráceného“ provedeme výběrem Manufacturing Enterprise Management.

Načtěte soubor nastavení vytvořený v SCP.

Zaškrtneme, systém adresu vyzvedne automaticky.

Jednáme stejně jako v UPP.

Porovnání ověřovacích údajů (v přípravné fázi se doporučuje ruční porovnání dat, protože tato práce se může stát časově nejnáročnějším v procesu implementace výměny). Okno mapování se otevře pomocí dvojklik myši.

V případě chyby v synchronizaci bude „Podrobnosti ...“ nahrazeno „Nikdy ...“.

„Podrobně ...“ otevře registrační protokol s aktualizovanými informacemi o burze.

Připraven.