Automatiserade system I de flesta fall består ledningssystem av separata databaser och har ofta en geografiskt fördelad struktur. Samtidigt är korrekt genomfört datautbyte en nödvändig förutsättning för effektivt arbete sådana system.

Den initiala installationen av utbytet kan kräva ett antal åtgärder, inte bara när det gäller programmering, utan också konsultation, även om vi har att göra med homogena källor, som är fallet med produkter på 1C:Enterprise-plattformen. Varför att sätta upp 1C-växel (eller, som det också kallas, datasynkronisering i 1C 8.3) kan bli den mest tidskrävande och kostsamma uppgiften i ett integrationsprojekt, kommer vi att titta på i den här artikeln.

Datautbyte i 1C-miljön låter dig:

• Eliminera dubbelinmatning av dokument;
• Automatisera relaterade affärsprocesser;
• Optimera interaktionen mellan distribuerade avdelningar;
• Uppdatera omgående data för arbetet med specialister från olika avdelningar;
• "Särskilja" mellan olika typer av redovisning.*

*I de fall då uppgifterna för en typ av redovisning avsevärt skiljer sig från en annan är det nödvändigt att säkerställa informationens konfidentialitet och "avgränsa" informationsflöden. Exempelvis kräver datautbyte mellan 1C UT och 1C Accounting inte uppladdning av ledningsdata till den regulatoriska bokföringsdatabasen, d.v.s. synkronisering i 1C kommer att vara ofullständig här.

Om du föreställer dig standardprocess implementering av primärt datautbyte, när minst ett av dess objekt är en 1C-produkt, kan följande steg urskiljas:

• Samordning av utbytets sammansättning;
• Definition av transport (utbytesprotokoll);
• Sätta regler;
• Schemaläggning.

Identifiering av sammansättningen av 1C-utbyte

Utbytesobjekt kan delas in i "källa" och "mottagare". Samtidigt kan de utföra två roller samtidigt, vilket kommer att kallas ett tvåvägsutbyte. Källan och destinationen bestäms logiskt beroende på behovet eller funktionalitet system.*

*Till exempel, när du integrerar "WA: Financier" - en lösning för att upprätthålla finansiell redovisning och hantering av treasury-processer, utvecklad på basis av "1C:Enterprise", rekommenderar WiseAdvice-experter det som ett huvudsystem. Detta beror på tillgången på kontrollverktyg för att följa reglerna för tillämpningspolicyn, och följaktligen för att säkerställa lösningens effektivitet.

Därefter, baserat på mottagna och registrerade krav från användare, skapas en lista över data för utbyte, dess volym, krav på utbytesfrekvens bestäms och processen för att arbeta med fel och hantera exceptionella situationer (kollisioner) föreskrivs.

I samma skede, beroende på flottan av befintliga system och företagets struktur, bestäms utbytesformatet:

Distribuerad informationsbas

• RIB innebär utbyte mellan identiska 1C-databaskonfigurationer, med en tydlig "master-slave"-kontrollstruktur för varje utbytespar. Som en del av en teknologiplattform kan RIB, förutom data, överföra konfigurationsändringar och administrativ information om databasen (men bara från master till slav).

Universellt datautbyte i 1C

• En mekanism som låter dig konfigurera utbytet av 1C-databaser, både med konfigurationer på 1C:Enterprise-plattformen och med tredjepartssystem. Utbytet utförs genom att överföra data till ett universellt xml-format i enlighet med "Utbytesplanerna".

EnterpriseData

• Den senaste utvecklingen av 1C, designad för att implementera datautbyte i xml-format mellan produkter skapade på 1C:Enterprise-plattformen med alla automationssystem. Användningen av EnterpriseData förenklar modifieringarna i samband med utbytet. Tidigare, när en ny konfiguration ingick i ett system, var det nödvändigt att implementera en mekanism för att importera och exportera data, både för det och för befintliga system. Nu behöver system som stöder EnterpriseData inga modifieringar, de har bara en ingångspunkt.

Definition av transport (utbytesprotokoll)

För systemet på plattformen 1C:Enterprise 8 tillhandahålls ett brett utbud av möjligheter för att organisera utbyte med alla informationsresurser med hjälp av allmänt accepterade universella standarder (xml, textfiler, Excel, ADO-anslutning, etc.). Därför, när du bestämmer transporten för utbyte av data, bör du lita på databasfunktionerna hos tredjepartssystemet.

Synkronisering av kataloger

Grundprincipen för effektiv synkronisering av kataloger är närvaron av en enda ingångspunkt. Men om vi pratar om att arbeta med kataloger som historiskt har fyllts i enligt olika regler, är det nödvändigt att tydligt definiera synkroniseringsfält för att få utbytet till en "gemensam nämnare."*

*I detta skede kan det bli nödvändigt att utföra arbete för att normalisera referensdata på sidan av datakällan. Beroende på katalogernas tillstånd och deras volym kan processen att jämföra element, känna igen, identifiera fel och dubbletter, samt fylla i saknade fält och tilldela synkroniseringsfält, kräva arbete av en hel grupp experter, både på del av integratören (ägaren av) och från kundens sida.

Sätta regler

Möjligheten att visa data från källsystem i mottagare beror på korrekt definierade utbytesregler. Reglerna, presenterade i xml-format, reglerar överensstämmelsen mellan nyckeldetaljer för käll-mottagarobjekt. 1C:Data Conversion-lösningen är utformad för att automatisera skapandet av regler för implementering av både engångs- och permanenta utbyten.

Garanterar ingen dataförlust under utbytesplanen. Detta komponent valfri konfiguration på 1C:Enterprise-plattformen, som fullständigt beskriver proceduren för 1C-utbyte: datasammansättning (dokument med "identifierande" detaljer) och noder (mottagare-sändarinformationsbaser), samt aktivering av RIB för utvalda utbytesriktningar.

Alla förändringar i data som matas in i utbytesplanen registreras och får tecknet "förändrat". Förrän de ändrade data matchar varandra i mottagar-sändarnoderna, kommer tecknet inte att återställas, och systemet kommer att skicka kontrollmeddelanden till båda noderna. Efter att ha laddat upp data och bekräftat deras fulla överensstämmelse i båda systemen, återställs skylten.

Utbytesschema i 1C

För att automatisera regelbundet utbyte är frekvensen för datauppladdning inställd. Utbytesfrekvensen beror på behov och tekniska möjligheter. Dessutom tillåter konfigurationer på 1C:Enterprise-plattformen dig att konfigurera datautbyte när en händelse inträffar.

Efter att ha övervägt standardprocessen för att implementera ett utbyte, låt oss uppmärksamma faktorer som kommer att kräva förbättringar i olika skeden:

• Icke-standardiserade, mycket modifierade databaskonfigurationer;
• Olika versioner plattformar "1C:Enterprise";
• Konfigurationsversioner som inte har uppdaterats på länge;
• Bytesobjekt som tidigare har genomgått modifieringar;
• Behovet av icke-standardiserade utbytesregler;
• En helt annan uppsättning och sammansättning av detaljer i befintliga referensböcker.

Eftersom även standardåtgärder för att implementera primärt datautbyte kräver expertkunskap, rekommenderas de att utföras med deltagande av 1C-specialister. Först efter att ha slutfört alla steg som beskrivs ovan bör du fortsätta med att ställa in växeln i konfigurationen. Låt oss titta på integrationen av databaser med exemplet 1C:UPP och 1C:Retail (utbyte med 1C:UT ställs in med samma schema). I standardsynkronisering ingår också SCP - SCP-växeln, som är typisk för storskaliga automationssystem hos de största industriföretagen.

I undermenyn "Tjänst" väljer du "Datautbyte med produkter på plattformen..." (att välja direktutbyte med "Detaljhandel" resulterar ofta i fel på COM-objektnivå). Låt oss vara uppmärksamma på servicemeddelandet " Den här möjligheten inte tillgänglig."

För att lösa det här problemet måste du välja "Konfigurera kommunikation"

...och kryssa i rutan. Ignorera sedan felmeddelandet.

I inställningarna för datasynkronisering, välj "Skapa ett utbyte med "Detaljhandel"...

Innan du konfigurerar anslutningsinställningar via en lokal eller nätverkskatalog bör du se till att det finns utrymme på disken för katalogen. Även om det i regel inte tar upp mer än 30-50 MB, kan det i undantagsfall kräva upp till 600 MB. Du kan skapa den önskade katalogen direkt från konfiguratorn.

När du ansluter via en nätverkskatalog uppmanas du att konfigurera anslutningen med en FTP-adress och e-post ignorera genom att klicka på "Nästa".

I inställningarna anger vi manuellt prefix - symboler databaser (vanligtvis BP, UPP, RO), anger vi reglerna och startdatumet för nedladdning av data. Prefixet kommer att anges i namnet på dokumenten för att ange i vilken databas de skapades. Om uppladdningsreglerna inte redigeras kommer data att laddas upp som standard enligt alla tillgängliga parametrar.

Vi skapar en fil för utbytesinställningar för "Detaljhandel" för att inte upprepa våra handlingar. Om du behöver skicka data direkt efter att du har ställt in synkroniseringen, markera rutan.

För att automatisera utbytesprocessen måste du sätta upp ett schema.

Meny "Detaljhandel".

Markera rutan och välj "Synkronisering".

Vi utför den "omvända" inställningen genom att välja Production Enterprise Management.

Ladda inställningsfilen som skapats i UPP.

Vi sätter en bock, systemet hämtar adressen automatiskt.

Vi agerar på samma sätt som i UPP.

Verifieringsdatajämförelse (Manuell datajämförelse rekommenderas att göras i det förberedande skedet, eftersom detta arbete kan bli det mest arbetsintensiva i processen för att genomföra utbytet). Jämförelsefönstret öppnas genom att dubbelklicka med musen.

I händelse av ett fel i synkroniseringen kommer "Detaljer..." att ersättas med "Aldrig...".

"Detaljer..." öppnar loggen med uppdaterad information om börsen.

Redo.

Hej kära läsare av bloggsidan! Om du har har du alla nödvändiga verktyg för att utbyta data i 1C:Enterprise 8.2, i synnerhet dokument och referensböcker. Artikeln beskriver hur man arbetar i, utgåva 2.1.4.1.

Låt oss hitta bearbetningsfilen MD82Exp.epf som en del av distributionspaketet för konfiguration av datakonvertering.
Det kommer att behövas för att ladda ner en beskrivning av metadatastrukturen för konfigurationen av käll- och måldatabaserna.

Vi hittar även bearbetningsfilen V8Exchan82.epf som en del av samma distribution.
Det kommer att behövas för att ladda ur källdatabasen och ladda destinationsdatabasen.

Vad händer om dina 1C-konfigurationer är identiska? Då är det värt att prova en annan metod, som beskrivs i noten. Den kan också användas för att utbyta data mellan identiska databaser.

Vad händer om du behöver överföra data från version 1C 7.7 till version 1C 8.2? Då bör du använda de tips som beskrivs.

Så låt oss börja:

Låt oss först ladda ner beskrivningar av käll- och målmetadatastrukturen.

1. Låt oss öppna källdatabasen i 1C:Enterprise 8.2-läge och börja bearbeta MD82Exp.epf
   för att ladda ner en beskrivning av källmetadatastrukturen.
   Låt oss spara källmetadatastrukturen i filen Rules1.xml.

1. Låt oss öppna mottagardatabasen i 1C:Enterprise 8.2-läge och börja bearbeta MD82Exp.epf
   för att ladda ner en beskrivning av mottagarens metadatastruktur.
   Låt oss spara mottagarens metadatastruktur i filen Rules2.xml.

Låt oss ladda beskrivningar av metadatastrukturen för båda konfigurationerna.

1. Låt oss köra i 1C:Enterprise 8.2-läge.
2. Låt oss öppna katalogen "Konfigurationer" (Kataloger—>Konfigurationer). Den lagrar konfigurationsinformation,
   mellan vilka utbytesregler kan konfigureras.
3. Låt oss lägga till information om källkonfigurationen. Klicka på knappen "Lägg till" eller knappen "Infoga".
4. Låt oss ange sökvägen till filen med källmetadatastrukturen Rules1.xml. Klicka på knappen "Ladda ner".
   Nu ser vi att det finns i katalogen "Konfigurationer". nytt element med namnet på källkonfigurationen.

1. Låt oss lägga till information om mottagarens konfiguration. Klicka på knappen "Lägg till" eller knappen "Infoga".
2. Låt oss ange sökvägen till filen med mottagarmetadatastrukturen Rules2.xml. Klicka på knappen "Ladda ner".
   Nu ser vi att ett nytt element har dykt upp i katalogen "Konfigurationer" med namnet på mottagarkonfigurationen.

Så vi har laddat källan och destinationsinformationen. Nu kan vi konfigurera utbytesreglerna.
I nästa steg kommer vi att använda de nyskapade elementen i katalogen "Konfigurationer" och välja dem
i katalogen "Konverteringar".

1. Låt oss öppna katalogen "Konverteringar" (Kataloger—>Konverteringar). Den här guiden innehåller information
   där det bestäms mellan vilka konfigurationer utbytet genomförs och i vilken riktning.
2. Låt oss lägga till ett nytt element. Klicka på knappen "Lägg till" eller knappen "Infoga".

1. Vi anger källkonfigurationen från katalogen "Konfigurationer". Fält "Konfiguration - källa:".
2. Låt oss specificera mottagarens konfiguration från katalogen "Konfigurationer". Fält "Konfiguration - Mottagare:".

1. Klicka på knappen "OK".
2. Dialogrutan "Information" kommer upp, med vilken du automatiskt kan skapa alla utbytesregler baserat på
   matchande namn på konfigurationsobjekt, eller bara en regel manuellt.

1. Om du väljer det första alternativet från dialogrutan "Information" kommer en annan dialogruta med texten
   "Skapa regler för datauppladdning?" Klicka på knappen "OK".

Bra, vi har konfigurerat utbytesreglerna. Allt som återstår är att ladda upp dessa utbytesregler till en fil.

Konverteringsreglerna är klara! Låt oss nu utbyta data.

Låt oss öppna källdatabasen i 1C:Enterprise 8.2-läge och börja bearbeta
för att ladda källdata.

Detta är bearbetningsfilen V8Exchan82.epf. Eller öppna "Verktyg" -> "Andra datautbyten" -> "Universellt datautbyte i XML-format"

1. Under bearbetning, på fliken "Dataöverföring", välj namnet på regelfilen (vi sparade den här: C:\Bases\DataExchangeRules.xml).
   Vi går med på att ladda ner reglerna för datautbyte. Låt oss klicka på knappen "Ja".
2. Låt oss ange namnet på datafilen. (Till exempel C:\Bases\Data Upload.xml). Om filen inte finns skapas den.

1. Låt oss ange perioden. Klicka på knappen "Ladda upp data" (finns på panelen högst upp).

Låt oss nu ladda data till mottagardatabasen. Låt oss öppna det i 1C:Enterprise 8.2-läge och börja bearbeta

Detta är bearbetningsfilen V8Exchan82.epf. Eller öppna "Verktyg" -> "Andra datautbyten" -> "Universellt datautbyte i XML-format"

1. Under bearbetning, på fliken "Data Loading", välj namnet på datafilen (vi sparade den här: C:\Bases\Data Upload.xml).
2. Klicka på knappen "Ladda data" (finns på panelen högst upp).

Data laddad!

Det finns fall då vissa detaljer skiljer sig åt i tabelldelen av dokumentet för destinations- och källdatabaserna.
Mottagaren kan ha ett attribut av typen "Directory" och källan kan ha ett attribut med samma namn, men dess typ är "Enumeration".
Vad ska jag göra? Hur ställer jag in reglerna för att konvertera detta objekt korrekt? Använd tipsen från artikeln.

Samma steg gäller för versionerna 1C:Enterprise 8.1 och 1C:Enterprise 8.0. Datakonverterinkluderar bearbetningsfiler för dessa versioner MD81Exp.epf och V8Exchan81.epf, MD80Exp.epf och V8Exchan.epf.

Med hjälp av konfigurationen för datakonvertering kan du dessutom ladda ner data från version 1C:Enterprise 7.7. Bifogade är filerna V77Exp.ert (nedladdning av data), V77Imp.ert (laddar ner data), MD77Exp.ert (nedladdning av en beskrivning av konfigurationens metadatastruktur).

Artikeln beskriver i detalj hur man använder dessa behandlingar.

I verkligheten är det ett sällsynt företag som klarar sig med bara en 1C-databas. Den vanligaste situationen är två baser, redovisning och lön.

Baserna ska kopplas ihop - löner har periodiserats, upplupna skatter ska gå till redovisningsavdelningen för betalning.

För att koppla ihop flera databaser finns Exchange 1C. Hur fungerar han?

Vad är Exchange 1C?

Det finns en butikskedja och ett centralkontor. Varje butik och kontor har ett lager. Varor flyttas från lager till lager (främst från centrallagret till butikslagret) och säljs i butik.

1C Retail-databasen används på kontoret och samma databas i varje butik. Baser i butik är underordnade basen på kontoret.

På kontoret skapas dokument om förflyttning av varor från lager till lager och priser sätts. Dokument laddas upp till underordnade databaser och där "uppstår" varor.

Butiker skapar dokument om genomförda försäljningar av varor. Dokument laddas upp till kontorsdatabasen och där "visas" försäljningen.

Detta schema kallas en distribuerad informationsbas (RIB). Rutiner för att "ladda upp" dokument – ​​tvåvägs 1C-utbyte. Och att sätta upp detta schema är URIB eller URIBD (distributed information databas management).

Principer för att byta kataloger i 1C

1C-kataloger (och uppsättningen av alla kataloger "i komplexet" kallas NSI - normativ referensinformation) – bör vanligtvis vara samma i olika databaser. Det betyder att även om det finns flera databaser är listan över varor, lager och entreprenörer densamma i olika databaser.

En vanlig praxis är när en katalog tillåts redigeras i en databas och den kopieras ("migreras") till de andra. Som vi har diskuterat tidigare har varje 1C-element en unik identifierare - GUID. Kataloger kopieras vanligtvis tillsammans med deras GUID och är således identiska i hela det distribuerade informationssystemet.

Annars, när flera initialt befintliga databaser är anslutna, eller när kataloger kan skapas i olika databaser samtidigt, kommer deras GUID att vara olika. Det finns en matchningsmekanism för detta. I ett speciellt informationsregister under 1C-utbyte registreras information om att elementet från databas nr 1 med GUID xxx är lika med elementet i denna databas med GUID yyy. Inledningsvis måste befintliga element som inte längre är likvärdiga jämföras automatiskt (med hjälp av andra uppgifter, t.ex. med namn eller skatteidentifikationsnummer och kontrollpunkt) eller manuellt.

Principer för dokumentutbyte i 1C

Handlingar i 1C bokförs enligt register och betraktas då som ”postade”. Detta ger upphov till förståeliga svårigheter under överföringen.

Ett alternativ är att bara överföra dokumenten och överföra dem igen efter nedladdning. Denna metod används ofta, men den kan ge upphov till fel - dokumentet får inte läggas upp i den nya databasen, eftersom förutsättningarna under processen kan vara annorlunda än de var när dokumentet lades upp i den ursprungliga databasen.

Ett annat alternativ är att överföra handlingar och register tillsammans. Som vi förstår uppstår frågan omedelbart - antingen överför vi alla handlingar i allmänhet och sedan hela registret i allmänhet, eller så tvingas vi välja för överföring endast rörelser på de överförda handlingarna.

Låt oss säga att vi behöver överföra ett objekt från nomenklaturkatalogen. Denna katalog har 10 fält, varav 5 är strängar och siffror, och 5 är länkar till andra kataloger.

Följaktligen, när vi överför ett element i nomenklaturen, är vi tvungna att söka efter och överföra även 5 element i andra kataloger.

Sålunda, vid överföring av ett katalogelement eller ett dokument, kan 100 eller fler andra 1C-objekt överföras via länk.

Det sägs faktiskt att nästan alla konfigurationsreferenser refererar till varandra på ett eller annat sätt.

1C utbytesplaner

Låt oss anta att vi har skapat en distribuerad databas och genomfört ett 1C-utbyte. Varor har köpts in till centrallagret och förberetts för leverans till butik. I 1C på kontoret introducerade de nödvändiga dokument förflyttning av varor. Kräver att de laddas i butik.

Vad ska man göra? Genomföra ett helt 1C-byte igen? Lång och ineffektiv! Det skulle vara mycket bättre att beräkna exakt vad som lagts till eller ändrats av användare på kontoret, så att endast ändringar skickas till butiker.

Det finns 1C utbytesplaner för detta. Programmeraren skapar en 1C-utbytesplan i förväg för att genomföra 1C-utbyten med någon annan databas, till exempel med våra butiker.

1C-utbytesplanen noterar när användare arbetar med kataloger och dokumenterar vad som har lagts till eller ändrats sedan det senaste 1C-utbytet med denna databas.

Skapandet av URIB 1C

Så vi kommer att skapa en distribuerad databas från början. Inledningsvis har vi en "förälder" kontorsbas. Från den kommer vi att välja databaser med butiker som kommer att vara underordnade den.

Typiska konfigurationer har redan standardutbytesplaner för 1C. De typer av baser som de är avsedda för framgår intuitivt av namnet:

• Byt 1C med en webbplats: utbyte med en 1C:Bitrix-webbplats
• Exchange 1C UPP-UT eller UT-Retail: typiska börser med systerkonfigurationer
• Fullständig – 1C-utbyte med en databas baserad på samma konfiguration.

RIB - distribuerad informationsbas - kan också göras på basis av 1C "Full" utbytesplan. I konfiguratorn, i denna 1C-utbytesplan, ska kryssrutan "Distribuerad infobas" vara markerad.

1C-utbytesplanen som skapats i konfiguratorn indikerar att vi kommer att byta med denna konfiguration. I Enterprise-läge, i samma 1C-utbytesplan, måste du nu specificera specifika databaser baserat på denna konfiguration.

Låt oss gå till 1C-utbytesplanen (Operations/Exchange Plan; kan också finnas i en annan meny, ofta i menyn Service/XXX).

I listan över databaser i 1C-utbytesplanen finns en med en grön cirkel i bilden. Detta element står för DENNA BAS. De återstående elementen indikerar ANDRA baser med vilka 1C byts ut.

Det är nödvändigt att både namn och kod för alla element fylls i.

Så här skapar du en butiksunderbas:

• Placera markören i listan på 1C utbytesplanelementet, som vi skapade som en "butiksbas"
• Välj menyalternativet "Actions/Create initial image".

Som ett resultat kommer en databas att skapas med den ursprungliga data som laddas upp till den. Detta måste upprepas för varje del av 1C-utbytesplanen, förutom AKTUELL BAS.

Teori om 1C-utbyten

Teorin om 1C-utbyte är ganska enkel:

• En av databaserna (vanligtvis centrets databas) initierar 1C-utbyte enligt ett schema eller "efter händelse" (logga in på databasen för en specifik användare, etc.)
• 1C-utbyte består av att ladda ner en fil från databasen
• Filen måste flyttas till en plats där en slavdatabas kan hämta den (vanligtvis en share eller ftp, mer sällan e-post)
• Slavdatabasen laddar ner den mottagna filen
• Som bekräftelse på att informationen har tagits emot laddar slavdatabasen upp en "svars"-fil, som laddas tillbaka till den centrala databasen på samma sätt
• 1C-utbytessessionen är klar.

Det finns andra metoder för att utbyta 1C, inte genom filer, utan till exempel genom en direkt COM-anslutning mellan två databaser. Dess fördelar:

• Inget "utrymme för att lagra och överföra filer" krävs
• Inget behov av att ladda upp bekräftelse igen
• Allt går snabbare på grund av de två första punkterna.

Begränsningen är dock tydlig - baserna måste vara så tillgängliga för varandra för att kunna initiera en COM-uppkoppling.

Installation av RIB 1C

I konstanter typiska konfigurationer(Operationer/Konstanter; eller Service/Programinställningar) - vanligtvis ja allmän inställning 1C börser. Detta är ett prefix i elementkoder och dokumentnummer för att enkelt avgöra i vilken databas det skapades. Samt en intern metod för att lagra information om platsen där kataloger och dokument skapades.

Nu måste du konfigurera hur processen för periodiskt utbyte av 1C-information mellan de skapade databaserna kommer att ske.
Alla RIB-inställningar i 1C är i standardkonfigurationer, vanligtvis i menyn Service/Distribuerade informationsbaser/Konfigurera RIB-noder.

För varje tidigare skapad "fjärrbutiksbas"-element måste du lägga till ett inställningselement.

Inställningarna anger 1C utbytesmetod: fil (dela), fil (FTP), fil (e-post).

Skapa och sätta upp en distribuerad 1C-informationsbas i en tunn klient

Låt oss titta på en liknande inställning i en typisk konfiguration baserat på tunn klient– Trade Management Revision 11.
Inställningar (och skapa från grunden) finns på fliken Administration i gränssnittet. Objekt "Datautbyte".

Välj "Skapa ett utbyte i en distribuerad infobas".

Redan från början kommer 1C att be oss ange hur vi ska utbyta information med den underordnade databasen. Här är konfigurationsalternativet "via en fil på bollen".

Här är konfigurationsalternativet via en FTP-fil.

Namnet på vår 1C-växelinstallation.

Och omedelbart ett förslag om att skapa en "initial bild" - det vill säga själva slavdatabasen med uppladdning av primär information till den.

Till skillnad från konfigurationen på en tjock klient finns båda 1C-växlingsinställningarna på ett ställe.

Vi känner till metadatastrukturen informationsbas källa och mottagare. Denna information är tillräckligt för att vi ska kunna bestämma vilka objekt i källinformationsbasen som ska konverteras till vilka objekt i mottagarinformationsbasen. Det vill säga, vi kan upprätta viss överensstämmelse mellan objekten för källan och mottagarens informationsbas. Till exempel kan vi ange att nomenklaturkatalogen för källinfobasen motsvarar nomenklaturkatalogen (eller någon annan katalog) i mottagarinfobasen.

Vi kommer att kalla en sådan överensstämmelse mellan käll- och destinationsobjekten "Objektkonverteringsregler" eller OCR.

Det visade exemplet visar att för utbytesreglerna (eller omvandlingsreglerna "Två objekt till ett") upprättas överensstämmelsen mellan objekten för katalogerna "Användare" och "Individer". Det vill säga, det specificeras att objekten i "Users"-katalogen från källinfobasen behöver överföras till objekten i "Users"-katalogen i mottagarinfobasen.

När överensstämmelsen mellan objekten är etablerad kan du bestämma hur detaljerna för dessa objekt ska överföras. Det vill säga, vi måste specificera att "Name"-attributet för en katalog motsvarar "Name"-attributet för en annan.

Vi kommer att kalla denna överensstämmelse mellan egenskaperna (eller detaljerna) för käll- och destinationsobjekt för "Property Conversion Rules" eller PCS.

Exemplet som visas visar att för reglerna för konvertering av "Användare"-objekt upprättas 3 överensstämmelser mellan objektens egenskaper (eller detaljer). Det anges att "Name"-attributet i "Users"-katalogen i källinformationsbasen måste omvandlas till "Name"-attributet för "Users"-katalogen i mottagarinformationsbasen.

När överensstämmelsen mellan objektens egenskaper är specificerad behöver programmet specificera kriterierna för matchande objekt (det vill säga det måste ange hur man söker efter ett objekt i destinationen med hjälp av ett källobjekt) i två informationsbaser. För en sådan jämförelse, använd kryssrutan "Sök" för motsvarande objektkonverteringsregel. Om kryssrutan är markerad kommer sökningen efter motsvarande objekt att utföras med den här egenskapen. I det givna exemplet är det tydligt att sökningen efter ett objekt i mottagarens infobas kommer att utföras med attributet "Name". Om sökningen ställs in med hjälp av flera detaljer, kommer sökningen att utföras med alla samtidigt (det vill säga villkoren ställs av "OCH". I detta fall är matchningsregeln följande: Sök i informationsbasen - mottagare för ett objekt för vilket alla sökdetaljer matchar detaljkällans objektsökning).

Dessutom är det möjligt att ställa in en överensstämmelse mellan fördefinierade delar av referensböcker, planer av karaktäristiska typer och uppräkningsvärden. Vi kommer att kalla en sådan jämförelse "Värdekonverteringsregler" för VKZ.

Exemplet som visas visar att för reglerna för att konvertera objekt "Typer av agentavtal" har en överensstämmelse upprättats mellan värdena i uppräkningen. Det vill säga, värdet på "Rent"-uppräkningen i källinfobasen måste konverteras till värdet för "Rent"-uppräkningen i destinationsinfobasen.

Vi bekantade oss med reglerna för omvandling av objekt, egenskaper och värden. Vid första anblicken mycket enkla regler jämförelser låter dig överföra data från en infobas till en annan.

Vänliga hälsningar, Vladimir Milkin(lärare och utvecklare).

Lärobok om 1C Datakonvertering (utgåva 2) Detaljerad introduktion till reglerna för utbyte

Vi vet vad utbytesregler är och varför de behövs. Låt oss ta en närmare titt på den extra funktionaliteten av att arbeta med utbytesregler. Låt oss öppna inställningarna för regler för datautbyte (konvertering):

Utbytesreglerna anger käll- och destinationskonfigurationer för data, dessutom:

Fliken "Avancerat":

Du kan ange standardfilnamnet för att spara utbytesregler, datauppladdning och nedladdningsmoduler för 7.7, namn på utbytesregler.

Fliken "Parametrar":

Låt oss säga att kontoret accepterar beställningar uteslutande för varor, så det är tillrådligt att upprätta ett förbud mot lossningstjänster. Om referenselementet Nomenclature-attributet Service är satt till True, är det garanterat att det inte avlastas. Det är bäst att omedelbart göra kontroll över lossningen av tjänster valfri, för att inte ändra reglerna om fjärrkontoret börjar ta emot beställningar på tjänster.

I det här fallet måste vi lära oss två nya tekniker för att arbeta med konfigurationen "Datakonvertering" - att använda hanterare och ställa in parametrar.

Parametrar är en specialiserad datastruktur för avlastningsalgoritmer som kan användas för att komma åt bearbetningsvariabler. Inställning av strukturen för parametrar för konverteringsregler utförs i konfigurationen "Datakonvertering", och inställning av parametervärden är möjlig i form av bearbetning av datauppladdning och nedladdning.

För att redigera parametrarna, öppna formuläret för katalogelementet Konverteringar för redigerade utbytesregler och gå till fliken parametrar. Låt oss skapa ett nytt katalogelement Parametrar. Låt oss ge parameternamnet – UnloadServices. Parameternamnet används för att referera till det i parameterstrukturen när du skriver programkod hos hanterare. Namnet kommer att visas i tabelldelen av parametrarna i bearbetningsformuläret universellt utbyte data. För att parametern ska synas i dialogrutan när du ställer in uppladdningen måste du markera kryssrutan "Ange i dialogrutan" och välja parametervärdestyp. För att arbeta med parametrar i dialogrutan måste du även markera kryssrutan "Ladda ner parametrar i version 2.01-format" i form av katalogelementet Konverteringar.

Det räcker inte med att bara specificera parametrarna, avlastningsalgoritmen måste "förstå" i vilket fall man ska lossa ett element och i vilket fall inte. För liknande (och många andra) fall används hanterarmekanismen. Dess väsen ligger i det faktum att vid nyckelpunkter i utförandet av alla grundläggande algoritmer för uppladdning och laddning av data, bearbetas koden som skrivits av utvecklaren när man skapar utbytesreglerna. Naturligtvis kräver användningen av ett så känsligt instrument försiktighet och eftertänksamhet. Vi rekommenderar att du noggrant läser hjälpen för "Data Conversion 2.0"-konfigurationen innan du skriver dina egna hanterare, som beskriver alla tillgängliga variabler i hanterarna och hur man använder dem, såväl som typerna av hanterare och funktionerna i anrop. dem i datautbytesalgoritmer.

För vårt syfte måste vi använda avlastningsregelhanteraren "Före lossning". Låt oss öppna regeln för uppladdning av nomenklaturdata och placera följande programkod i fältet "Före uppladdning" på fliken "Händelser":

Vad gör vår handläggare? När vi skrev programkoden använde vi variabler i datauppladdningsalgoritmer. Parameterstrukturen används för att komma åt parametern UnloadServices, som specificeras i bearbetningsformuläret för datautbyte. Objektvariabeln ger åtkomst till objektet som söks. Och variabeln Refusal låter dig styra vägran att ta bort det aktuella objektet. Hanteraren exekveras omedelbart innan objektet lossas, vilket gör det möjligt att avbryta lossningen av objektet.

ENDAST FÖR V8 - V8 UTBYTE OCH UPPLADDNING OCH LADDA NER BEHANDLING MINST 2.0.18.1

Det är möjligt att överföra parametrar från en konfiguration till en annan. För att göra detta räcker det att markera kryssrutan "Pass parameter vid uppladdning" på fliken "Parametrar" och denna parameter kommer att placeras i utbytesfilen och dess värde kan nås när data laddas. Du kan ange en konverteringsregel för en parameter enligt vilken värdena ska konverteras. Genom att använda kryssrutan "Lämna parameter vid uppladdning" kan du bara överföra de parametrar som redigeras i dialogrutan när du laddar upp data. Om du behöver skicka en parameter som inte finns i den här dialogrutan, måste du anropa proceduren:

På fliken Ladda upp parametrar har en parameter dykt upp som ändrar värdena för vilka tjänster som antingen avlastas eller inte avlastas.