1s 8.3 datakonvertering 2.1 hur man använder. Video instruktioner för konvertering

1. Introduktion.

2. Vad du behöver: 1C-konfiguration: Datakonvertering 2.* och bearbetning från paketet. För exempeluppgifter, låt oss ta konfigurationer 1C: Trade Management 11 och 1C: BP 3.*.

Så för att utveckla regler för att ladda upp data till 1C behöver du 1C-konfigurationen: Objektkonvertering 2, såväl som bearbetningen som ingår i paketet.

Till exempel har vi redan distribuerat en konverteringsdatabas och lanserat den.

Vi kommer att skriva utvecklingen av utbytesregler mellan 1C: Trade Management 11 och 1C: Enterprise Accounting 3-konfigurationen (UT / ACCOUNT utbytesregler).

3. Vi kommer att behöva bearbetning för att ta bort metadatastrukturen och utbyta.

Det första du behöver skaffa för utveckling är filer med en metadatastruktur. Detta görs med hjälp av bearbetning för avlastning av metadatastrukturen som ingår i objektkonverteringspaketet.

I den uppackade konfigurationskatalogen för konfigurationer på hanterade formulär är vi faktiskt intresserade av bearbetningen av MD83Exp.epf. Om avlastning behöver göras från konfigurationer på vanliga formulär, används MD82Exp.epf-bearbetning. Detta är om du till exempel behöver få en struktur från sådana konfigurationer som 1C: UT 10, 1C: Manufacturing Enterprise Management 1.3, 1C: Integrated Automation 1.1, 1C: Zup 2.5 och så vidare.

Vidare, för att ladda upp och ladda ner data till 1C med våra regler, måste du bearbeta "Universellt datautbyte i XML-format" V8Exchan83.epf för konfigurationer på hanterade formulär som 1C: Trade Management 11.*, 1C BP 3, 1C: ERP 2. * och liknande. Och följaktligen V8Exchan83.epf - för konfigurationer på vanliga formulär.

4. Ladda upp metadatastrukturen för konfigurationen 1C: Trade Management 11.3 och 1C: Enterprise Accounting 3.0.*

Låt oss börja med att ladda ner metadatastrukturen från 1C: Enterprise Accounting 3-konfigurationen.
Låt oss öppna behandlingen av MD83Exp.epf

I bearbetningsformuläret finns ytterligare inställningar där vi kan aktivera eller inaktivera möjligheten att ladda upp register och rörelser till 1C. Du kan också välja var uppladdningen ska ske: på 1C-servern eller "på klienten". Ange namnet på filen där datastrukturen ska laddas upp. På liknande sätt laddar vi bort metadatastrukturen för Trade Management 11-konfigurationen.

Nu måste du ladda upp konfigurationen till konverteringsdatabasen. Denna punkt kan nås både från listan över konfigurationer och från listan över konverteringar. Låt oss bara starta från skrivbordet:

Ladda BP-strukturen i dialogrutan:

Och på liknande sätt - strukturen för Trade Management.

När nedladdningen är klar visas en dialogruta där du kan ange ett namn som passar dig.

6. Skapa konverteringsregler i 1C med ett specifikt exempel på en uppgift.

Gå sedan till "Sätta upp objektregler", där vi skapar en ny inställning.
I dialogrutan för att skapa konverteringar, välj "källa"-konfigurationen och "destination"-konfigurationen (som du tidigare laddade) och klicka på OK.

Eftersom jag i den här artikeln planerade att visa skapandet "från grunden" och "utan skräp", påminner jag om att vi inte skapar något automatiskt. Inga prototyper.

Vi kommer inte att göra något i den här dialogrutan, klicka bara på "Stäng".

Låt oss skapa regler för att ladda upp inte ett dokument till ett, utan en typ till en annan, till exempel dokumentet Försäljning av varor och tjänster från UT 11 med nödvändiga referensböcker till dokumentet Mottagande av varor och tjänster i BP 3.

Så vi skapar en ny PKO (regeln för att konvertera objekt i 1C)

Välj källan Försäljning av varor och tjänster och destinationen Mottagande av varor och tjänster och klicka på OK.
I det här fallet kommer en dialogruta att visas där vi återigen vägrar automatiskt skapande av PKS (Property Conversion Rules). Därefter väljer vi bara de nödvändiga.

Men på förslaget att skapa DVP (datauppladdningsregler) svarar vi "Ja".

PVD skapas, vilket kommer att återspeglas i behandlingen av det universella XML-utbytet för urval:

Datakonverteringsregler med tomma egenskapskonverteringsregler kommer också att skapas.

Dessutom är det tydligt att det som standard föreslås att söka efter programvaran med den interna objektidentifieraren. Detta indikeras av förstoringsglaset nära PCO. Vi kommer att göra vår egen sökning, och vi kommer att göra det efter dokumentnummer och datum i början av dagen.

Vi tar bort sökningen av UIO:

Låt oss nu börja jämföra de nödvändiga egenskaperna (detaljerna) för objektet. För att göra detta, klicka på "Synkronisera egenskaper" (etikett "1" på skärmen). Vi tar bort det rekursiva skapandet av regler ("2"). Ta bort alla markerade detaljer ("3"). Och vi väljer själva vad vi behöver.

Välj till exempel vad du behöver:

Jag uppmärksammar er på att vi kommer att göra motpartens PKS till organisationen och organisationen till motparten, och vi kommer också att jämföra några detaljer som inte stämmer överens med namnet, till exempel "Valuta" och "Dokument Valuta".

Där vi ser att det inte finns några konverteringsregler ännu.

Låt oss börja gå igenom detaljerna och beskriva dem. Först sätter vi upp en dokumentsökning som jag skrev tidigare, laddar upp och söker efter ett dokument i början av datumet och ändrar numreringen. Vi kommer att ersätta de tre första tecknen med vårt prefix "UTB". Och eftersom numreringen i BP och UT är 11 tecken vardera, gör vi ett sammansatt nummer: vårt prefix och 8 tecken från källan. Ett exempel i skärmdumpen nedan.

Vi laddar alltid upp dokument oladdade och utan rörelse. Vi antar att dokumenten kommer att behandlas i mottagaren efter verifiering av användaren.

För att göra detta, ställer vi in PKS som ej utförd, 0 eller 1, vi använder det som en boolesk.

Med hjälp av valuta som exempel skapar vi en objektkonverteringsregel för PKS. Samtidigt anser vi att det finns valutor i båda databaserna, och de bör synkroniseras med kod. Därför kommer vi inte att skapa alla PKS i Valuta PQS, utan kommer bara att lägga till en sökkod. De där. Vi tackar nej till erbjudandet att skapa en PKS för objektet.

Den skapade konverteringsregeln ersattes med PKS:en i dokumentets PQR. Och själva standardregeln erbjuds av en unik identifierare. Vi fixar det, söker i koden och ställer in egenskapen för att inte skapa ett nytt objekt.

Som ett resultat får vi följande alternativ:

Därefter skapar vi analogt PKO och PKS för de återstående detaljerna. Dessutom söker vi en organisation per motpart och vice versa efter TIN. Ungefär så här ser det ut med minimala detaljer (du kan lägga till vid behov).

För PCO Motpartsavtal söker vi på PKS Motpart, namn och ägare.

Låt oss se hur man anger det önskade värdet i uppräkningstypen i PKS. Till exempel attributet "Type of Operation". Här kan du använda olika villkor och ersättningsvärden. Till exempel behöver vi "typ av operation" för att alltid vara lossad "Varor", i det här fallet räcker det att skriva det erforderliga värdet i "pannan" -raden.

Nedan visas hur man installerar utan svårighet och i de flesta fall PCS för Mutual Settlement Multiplicity, Mutual Settlement Rate, Accounting Account.

För PKO Nomenklatura lämnar vi sökningen med intern unik identifierare. Men låt mig uppmärksamma dig på hur du kan omdefiniera din grupp. Till exempel godkänner vi att ett nytt föremål kommer att laddas upp från 1C: Trade Management 11-konfigurationen, men det är nödvändigt att föremålet samlas in i en specifik grupp "OurGroup".

För att genomföra denna uppgift skapar vi ytterligare en PKO. Låt oss kalla det "NomenclatureParent", vilket vi kommer att ange i förälderns PCS i konverteringsregeln.

Vi ställer in två sökningar: efter namn, där vi strikt anger namnet på vår grupp, och den nödvändiga egenskapen för attributet "This is a Group" är satt till true.

Eftersom vi har bestämt att alla våra artiklar faller in i vår grupp, behöver vi inte lasta av grupper från UT 11 vid lossning. För att göra detta kommer vi att ställa in ett filter i Nomenclature-mjukvaran i händelsehanteraren "Before Unloading". behöver inte ta bort grupper "Fel = Källa. Denna grupp;".

I DRP (datauppladdningsregler) för försäljning av produkter och tjänster kommer vi att lägga till ett filter så att dokument markerade för radering inte laddas upp. För att göra detta, i VDP i händelsehanterarna "Before Unloading", kommer vi att skriva filtret "Failure = Object.DeletionMark;".

Låt oss spara de utvecklade reglerna i en fil.

7. För att sammanfatta: Ladda upp och ladda data med hjälp av utvecklade regler för datautbyte.

Öppna i 1C: Trade Management 11 bearbetningen "Universellt datautbyte i XML-format" V8Exchan83.epf.

Avlastningen har slutförts, nu använder vi samma bearbetning för att ladda in i 1C: Enterprise Accounting 3.

Inläsningen slutförd. Låt oss kolla hur det laddades. Så, dokumentet laddas, som vi ville - vår organisation laddas in i motparten och motparten i organisationen. Alla bokföringskonton laddas ner och installeras. Vi fick dokumentnumret med vårt prefix och i början av dagen. Alla uppgifter som lämnades har fyllts i.

Vi kontrollerar lastningen av föremålen. Vi ser att allt blev som vi planerat.

Vi har skapat och fyllt i detaljerna som vi tänkt. Det finns många finesser i konvertering och några enkla men nödvändiga saker som hjälper dig att korrekt skriva konverteringen. Och detta gör att du kan minimera fel, inte förstöra befintliga data och bli av med onödigt skräp. Detta är ett av de enklaste exemplen. Du kan också konvertera ett objekt till många, eller tvärtom, många till ett.

Nu finns det datakonvertering 3, det löser andra problem. Därför är konvertering 2 också nödvändig. Lycka till alla med att lära och bemästra.

Om du är programmerare och det här är din huvudsakliga uppgift kan du naturligtvis försöka skriva konverteringen själv. Men om inte, bör du värdera din tid inom ditt verksamhetsområde och be proffs att utföra denna uppgift.

Datakonvertering 2.0 och 2.1 är en teknisk konfiguration av 1C, implementerad på plattformsversioner från 8.1 till 8.3.

Verktygets huvuduppgift är att skriva regler för utbyte mellan applikationslösningarna 1C 8 och 7. Den nuvarande versionen av datakonvertering idag är 3.0.

Datakonvertering är en mycket användbar konfiguration, med dess hjälp kan du inte bara lösa problemet med att överföra information från en informationsbas till en annan, utan också till exempel konvertera information i en databas.

Konfigurationen är mycket bekväm att använda med .

Datakonvertering kommer att vara användbar för alla programmerare: att ha kompetens att skapa utbytesregler är ett stort plus för professionella färdigheter.

För att lära sig att arbeta med en konfiguration är det bäst att lösa praktiska problem. Försök att komma på uppgifter för dig själv, till exempel: överföra lite information från en databas till en annan, förvandla ett försäljningsdokument till ett kvittodokument, "mata in" aktuella bokföringssaldon i ett dokument "att lägga in saldon" och andra uppgifter.

Det kommer att vara mycket användbart att förstå "standard" utbytesreglerna i 1C 8.3; där kan du ofta hitta intressanta exempel på att implementera uppgifter.

För att förstå grunderna behöver du material, vi kommer att överväga dem nedan.

Video instruktioner för konvertering

För grunderna för att ställa in datautbyte i 1C med "1C Data Conversion"-konfigurationen, se exemplet i videon:

Material, läroböcker för att studera 1C Data Conversion 2.0

Det finns inte för mycket material och dokumentation på Internet, jag försökte samla det viktigaste och mest intressanta materialet:

0. Först och främst rekommenderar jag den kostnadsfria videokursen av Ilya Leontyev, den är tillgänglig på länk.

1. Jag rekommenderar först och främst att använda den inbyggda hjälpen i konfigurationen. Den är riktigt välskriven och tekniskt väl implementerad:

2. Den näst viktigaste informationskällan är webbplatsen http://www.mykod.info/ (sajten har stängts), specialiserad specifikt på datakonvertering. Där kan du ladda ner ett stort antal material vid konvertering.

3. Separat skulle jag vilja lyfta fram läroboken - (författare - Olga Kuznetsova).

Att migrera data mellan olika konfigurationer är inte en trivial uppgift. Som alltid finns det flera lösningar, men alla är inte optimala. Låt oss försöka förstå nyanserna av dataöverföring och välja en universell strategi för att lösa sådana problem.

Problemet med datamigrering (vi talar enbart om 1C-företagsprodukter) från en lösning till en annan uppstod inte igår. 1C-företaget förstår mycket väl vilka svårigheter utvecklare möter när de skapar migrering, så det försöker på alla möjliga sätt hjälpa till med verktyg.

Under utvecklingen av plattformen introducerade företaget ett antal universella verktyg, samt teknologier som förenklar dataöverföring. De är inbyggda i alla standardlösningar och problemet med migrering mellan identiska konfigurationer har i allmänhet lösts. Segern bekräftas återigen av den nära integrationen av standardlösningar.

Med migrationer mellan icke-standardiserade lösningar är situationen något mer komplicerad. Ett brett urval av tekniker gör det möjligt för utvecklare att självständigt välja det optimala sättet att lösa ett problem ur deras synvinkel.

Låt oss titta på några av dem:

utbyte via textfiler;
användning av utbytesplaner;
etc.

Var och en av dem har sina egna för- och nackdelar. För att sammanfatta kommer den största nackdelen att vara dess mångsidighet. Oberoende implementering av migreringsalgoritmer är fylld med betydande tidskostnader, såväl som en lång felsökningsprocess. Jag vill inte ens prata om ytterligare stöd för sådana beslut.

Komplexiteten och de höga kostnaderna för support fick 1C-företaget att skapa en universell lösning. Teknik som gör det möjligt att förenkla utvecklingen och stödet av migrationer så mycket som möjligt. Som ett resultat implementerades idén i form av en separat konfiguration – "Datakonvertering".

Datakonvertering - standardlösning, oberoende konfiguration. Alla användare med en "ITS:Prof"-prenumeration kan ladda ner detta paket helt gratis från användarsupportsidan eller ITS-disken. Installation utförs på ett standard sätt - som alla andra standardlösningar från 1C.

Nu lite om fördelarna med lösningen. Låt oss börja med det viktigaste - mångsidighet. Lösningen är inte skräddarsydd för specifika plattformskonfigurationer/versioner. Det fungerar lika bra med både standard- och anpassade konfigurationer. Utvecklare har en universell teknik och ett standardiserat tillvägagångssätt för att skapa nya migrationer. Lösningens mångsidighet gör att du kan förbereda migrering även för andra plattformar än 1C:Enterprise.

Det andra stora pluset är visuella hjälpmedel. Enkla migreringar skapas utan programmering. Ja, ja, utan en enda kodrad! Bara för detta är det värt att lägga tid på att lära sig tekniken en gång och sedan använda ovärderliga färdigheter upprepade gånger.

Den tredje fördelen som jag skulle notera är frånvaron av begränsningar för datadistribution. Utvecklaren väljer själv metoden för att leverera data till mottagarkonfigurationen. Det finns två alternativ tillgängliga direkt: uppladdning till en xml-fil och direkt anslutning till infobasen (COM/OLE).

Studerar arkitektur

Vi vet redan att datakonvertering kan göra underverk, men det är ännu inte helt klart vad de tekniska fördelarna är. Det första du behöver förstå är att all datamigrering (konvertering) baseras på utbytesregler. Exchange-regler är en vanlig xml-fil som beskriver strukturen till vilken data från informationssäkerheten ska laddas upp. Tjänstebehandlingen som laddar upp/laddar ner data analyserar utbytesreglerna och utför uppladdningen utifrån dem. Under laddning sker den omvända processen.

"CD"-konfigurationen är en slags visuell konstruktör med hjälp av vilken utvecklaren skapar utbytesregler. Den vet inte hur man laddar ner data. Ytterligare extern tjänstebearbetning som ingår i CD-distributionspaketet ansvarar för detta. Det finns flera av dem (XX i filnamnet är plattformens versionsnummer):

MDXXExp.epf- bearbetning låter dig ladda upp en beskrivning av infobasstrukturen till en xml-fil. Strukturbeskrivningen laddas in i CD:n för vidare analys och skapande av utbytesregler.
V8ExchanXX.epf- laddar upp/laddar ner data från informationsbasen i enlighet med utbytesreglerna. I de flesta typiska konfigurationer finns bearbetning direkt (se menyalternativet "Service"). Behandlingen är universell och är inte bunden till några specifika konfigurationer/regler.

Okej, nu, baserat på allt ovan, låt oss definiera stadierna för att utveckla en ny konvertering:

Definition av uppgiften. Det är nödvändigt att tydligt förstå vilka data som behöver överföras (från vilka konfigurationsobjekt) och, viktigast av allt, var de ska överföras.
Förberedelse av beskrivningar av konfigurationsstrukturer (Source/Sink) för efterföljande laddning till CD:n. Problemet löses genom servicebearbetning MDXXExp.epf.
Laddar förberedda beskrivningar av strukturer i informationssäkerhet.
Skapa utbytesregler med hjälp av ett visuellt CD-verktyg.
Utför uppladdning/nedladdning enligt de skapade reglerna för datakonvertering med V8ExchanXX.epf-bearbetning.
Felsökning av utbytesregler (om nödvändigt).

Den enklaste konverteringen

För demonstrationen behöver vi två utplacerade konfigurationer. Jag bestämde mig för att välja alternativet: "Trade Management" 10:e upplagan och en liten hemskriven lösning. Uppgiften kommer att vara att överföra data från standard "UT"-konfigurationen. För korthetens skull, låt oss kalla den självskrivna lösningen "Sink" och handelsledningen "Källa". Låt oss börja lösa problemet genom att överföra element från katalogen "Nomenklatur".

Först och främst, låt oss ta en titt på datakonverteringsschemat och läsa om listan över åtgärder som behöver göras. Sedan startar vi "Source"-konfigurationen och öppnar MD82Exp.epf-tjänstens bearbetning i den.

Bearbetningsgränssnittet har inte ett överflöd av inställningar. Användaren behöver bara ange vilka typer av metadataobjekt som inte kommer att ingå i strukturbeskrivningen. I de flesta fall behöver dessa inställningar inte ändras, eftersom Det finns ingen speciell mening med att lossa rörelser med hjälp av ackumuleringsregister (som ett exempel).

Det är mer korrekt att forma rörelsen medan du håller dokument i mottagaren. Alla rörelser kommer att göras av själva dokumentet efter överföringen. Det andra argumentet till försvar av standardinställningarna är minskningen av filstorleken vid uppladdning.

Vissa dokument (särskilt i standardkonfigurationer) genererar rörelser över flera register. Om du laddar ner allt detta kommer den resulterande XML-filen att bli för stor. Detta kan komplicera efterföljande transport och lastning i mottagarbasen. Ju större datafil, desto mer RAM kommer att krävas för att bearbeta den. Under min praktik hade jag möjlighet att stöta på oanständigt stora uppladdningsfiler. Sådana filer vägrade helt att analyseras med standardverktyg.

Så vi lämnar alla standardinställningar och laddar upp konfigurationsbeskrivningen till en fil. Vi upprepar en liknande procedur för den andra basen.

Öppna CD:n och välj i huvudmenyn "Kataloger" -> "Konfigurationer". Katalogen lagrar beskrivningar av strukturerna för alla konfigurationer som kan användas för att skapa konverteringar. Vi laddar konfigurationsbeskrivningen en gång och sedan kan vi använda den flera gånger för att skapa olika konverteringar.

I katalogfönstret klickar du på knappen " Lägg till” och i fönstret som visas väljer du filen som beskriver konfigurationen. Markera kryssrutan "Ladda till en ny konfiguration" och klicka på knappen "Ladda". Vi utför liknande åtgärder med beskrivningen av strukturen för den andra konfigurationen.

Nu är du redo att skapa utbytesregler. I CD-huvudmenyn, välj "Kataloger" -> "Konverteringar". Lägg till ett nytt element. I fönstret för att skapa en ny konvertering måste du ange: källkonfigurationen (välj UT) och destinationskonfigurationen (välj "Mottagare"). Öppna sedan fliken "Avancerat" och fyll i följande fält:

utbytesregler filnamn - de skapade utbytesreglerna kommer att sparas under detta namn. Du kan ändra filnamnet när som helst, men det är bäst att ställa in det nu. Detta kommer att spara tid i framtiden. Jag döpte reglerna för demoexemplet: "rules-ut-to-priemnik.xml".
namn - namnet på konverteringen. Namnet kan vara absolut vad som helst, jag begränsade mig till "Demo. UT till mottagare.”

Det är allt, klicka på "Ok". Omedelbart dyker ett fönster upp framför oss som ber oss skapa alla regler automatiskt. Att gå med på ett sådant frestande erbjudande kommer att ge befälhavaren ett kommando att automatiskt analysera beskrivningen av de valda konfigurationerna och självständigt generera utbytesregler.

Låt oss pricka "jag" direkt. Guiden kommer inte att kunna generera något allvarligt. Denna möjlighet bör dock inte uteslutas. Om det är nödvändigt att upprätta ett utbyte mellan identiska konfigurationer, kommer tjänsterna från en specialist att vara mycket användbara. För vårt exempel är manuellt läge att föredra.

Låt oss ta en närmare titt på fönstret "Inställningar för utbytesregler". Gränssnittet kan verka lite förvirrande - ett stort antal flikar fulla av kontroller. Faktum är att allt inte är så svårt; du börjar vänja dig vid denna galenskap efter några timmars arbete med applikationen.

I det här skedet är vi intresserade av två flikar: "Regler för objektkonvertering" och "Regler för datauppladdning". Först måste vi konfigurera matchningsreglerna, dvs. jämför objekt med två konfigurationer. På den andra bestämmer du möjliga objekt som kommer att vara tillgängliga för användaren för uppladdning.

I den andra halvan av fliken "Regler för objektkonvertering" finns ytterligare en panel med två flikar: "Egendomskonvertering" och " Konvertera värden" Den första väljer egenskaperna (detaljerna) för det valda objektet, och den andra är nödvändig för att arbeta med fördefinierade värden (till exempel fördefinierade katalogelement eller uppräkningselement).

Bra, låt oss nu skapa konverteringsregler för kataloger. Du kan utföra den här åtgärden på två sätt: använd guiden för objektsynkronisering (knappen “”) eller lägg till korrespondens för varje objekt manuellt.

För att spara utrymme kommer vi att använda det första alternativet. I guidefönstret, avmarkera gruppen " Dokumentation” (vi är bara intresserade av kataloger) och utöka gruppen ” Kataloger" Vi bläddrar noggrant igenom listan och tittar på namnen på referensböcker som kan jämföras.

I mitt fall finns det tre sådana kataloger: nomenklatur, organisationer och lager. Det finns också en katalog som heter klienter, som tjänar samma syfte som " Motparter"från konfiguration" UT" Det är sant att mästaren inte kunde jämföra dem på grund av deras olika namn.

Vi kan fixa det här problemet själva. Vi hittar i fönstret " Objekt Matcher» referensbok « Kunder", och i kolumnen "Källa" välj katalogen "Motparter". Markera sedan rutan i kolumnen "Typ" och klicka på knappen "Ok".

Objektsynkroniseringsguiden erbjuder att automatiskt skapa regler för att konvertera egenskaper för alla valda objekt. Fastigheterna kommer att jämföras med namn och för vår demonstration kommer detta att vara fullt tillräckligt, vi håller med. Nästa fråga blir ett förslag om att skapa uppladdningsregler. Låt oss också gå med på det.

Grunden för bytesreglerna är klar. Vi valde objekten för synkronisering, och reglerna för konvertering av egenskaper och uppladdningsregler skapades automatiskt. Låt oss spara utbytesreglerna i en fil, öppna sedan IB "Källa" (i mitt fall är det UT) och starta tjänstebearbetning i den V8Exchan82.epf.

Först av allt, i bearbetningsfönstret, välj de utbytesregler vi skapade. Vi svarar jakande på frågan om lastningsregler. Bearbetning kommer att analysera utbytesreglerna och bygga ett träd av objekt med samma namn som är tillgängliga för uppladdning. För detta träd kan vi ställa in alla möjliga urval eller utbyta noder, genom att ändra vilka vi behöver för att välja data. Vi vill ladda ner absolut all data, så det finns inget behov av att installera filter.

Efter att ha slutfört processen att ladda upp data till en fil, gå till IB " Mottagare" Vi öppnar även bearbetning i den V8Exchan82.epf, bara den här gången går vi till fliken "Dataladdning". Välj datafilen och klicka på knappen "Ladda ner". Det är allt, data har överförts framgångsrikt.

Verkliga problem

Den första demon kan vara missvisande. Allt ser ganska enkelt och logiskt ut. Detta är faktiskt inte sant. I verkligt arbete uppstår problem som är svåra eller helt omöjliga att lösa med enbart visuella medel (utan programmering).

För att inte bli besviken på tekniken förberedde jag flera verkliga problem. Du kommer definitivt att stöta på dem på jobbet. De ser inte så triviala ut och får dig att titta på datakonvertering från en ny vinkel. Tänk noga på de presenterade exemplen och använd dem gärna som utdrag när du löser verkliga problem.

Uppgift nr 1. Fyll i de uppgifter som saknas

Anta att vi behöver överföra katalogen " Motparter" Mottagaren har en liknande "klient"-katalog för detta ändamål. Den är helt lämplig för datalagring, men den har rekvisita " Organisation”, vilket gör att du kan separera motparter genom att tillhöra organisationen. Som standard måste alla motparter tillhöra den aktuella organisationen (detta kan erhållas från konstanten med samma namn).

Det finns flera lösningar på problemet. Vi kommer att överväga alternativet att fylla i detaljerna " Organisation"rätt i databasen" Mottagare”, dvs. vid tidpunkten för dataladdning. Den nuvarande organisationen lagras i en konstant, därför finns det inga hinder för att erhålla detta värde. Låt oss öppna objektkonverteringsregeln (nedan kallad PKO) " Kunder” (dubbelklicka på objektet) och i regelinställningsguiden, gå till avsnittet ”Händelsehanterare”. I listan över hanterare hittar vi " Efter nedladdning”.

Låt oss beskriva koden för att få den aktuella organisationen och sedan tilldela den till detaljerna. När "After loading"-hanteraren utlöses kommer objektet att vara helt format, men ännu inte skrivet till databasen. Ingen förbjuder oss att ändra det efter eget gottfinnande:

Om INTE Object.ThisGroup Then Object.Organization = Constants.CurrentOrganization.Get(); endIf;

Innan du fyller i detaljerna " Organisation"Det är nödvändigt att kontrollera värdet på attributet" Denna grupp" För referensboken " Kunder"Den hierarkiska funktionen är inställd, så det är nödvändigt att söka efter gruppen. Fyll i eventuella uppgifter på liknande sätt. Se till att läsa hjälpen för andra hanteraralternativ " AfterLoading" Till exempel, bland dem finns parametern " Vägran" Om du tilldelar det värdet "True", kommer objektet inte att skrivas till databasen. Därmed blir det möjligt att begränsa de objekt som kan skrivas vid laddningstillfället.

Uppgift nr 2. Detaljer för informationsregistret

I katalogen " Motparter"UT-konfigurationer, information tillgänglig" Köpare"och" Leverantör" Båda detaljerna är av typen " Boolean” och används för att bestämma typen av motpart. I IB " Mottagare", i katalogen " Kunder"Det finns inga liknande uppgifter, men det finns ett register över information" Typer av klienter" Den utför en liknande funktion och kan lagra flera attribut för en klient. Vår uppgift är att överföra uppgifternas värden till separata poster i informationsregistret.

Tyvärr klarar inte visuella medel ensamma här heller. Låt oss börja i det små, skapa en ny programvara för informationsregistret " Typer av klienter" Ange inget som källa. Undvik att automatiskt skapa uppladdningsregler.

Nästa steg är att skapa uppladdningsreglerna. Gå till lämplig flik och klicka på " Lägg till" I fönstret för att lägga till uppladdningsregler, fyll i:

Testmetod. Ändra till "Godycklig algoritm";
Konverteringsregel. Välj informationsregistret "Kundertyper";
Kod (namn) för regeln. Skriv ner det som "Ta bort klienttyper";

Nu måste du skriva kod för att välja data för uppladdning. Parametern " Datasampling" Vi kan placera en samling med en förberedd datamängd i den. Parameter " Datasampling” kan anta olika värden - frågeresultat, urval, samlingar av värden, etc. Vi initierar den som en värdetabell med två kolumner: klient och klienttyp.

Nedan finns koden för händelsehanteraren " Innan bearbetning" Det initierar parametern " Datasampling" följt av att fylla i data från katalogen " Motparter" Här bör du vara uppmärksam på att fylla i kolumnen " Klienttyp" I "UT" är våra attribut av typen "Boolean", och mottagaren är en uppräkning.

I det här skedet kan vi inte konvertera dem till önskad typ (det finns inte i UT), så för närvarande lämnar vi dem i form av strängar. Du behöver inte göra detta, men jag vill genast visa hur man castar till en saknad typ i källan.

DataFetch = New ValueTable(); DataSelection.Columns.Add("Klient"); DataSelection.Columns.Add("ClientType"); SelectingDataFromDirectory = Directories.Accounts.Select(); While SelectingDataFromDirectory.Next() Loop If SelectingDataFromDirectory.ThisGroup Fortsätt sedan; endIf; If Data Selection From Directory.Buyer Then NewRow = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewRow.ClientType = "Kund"; endIf; If DataFetchFromDirectory.Supplier Then NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Leverantör"; endIf; EndCycle;

Låt oss spara datauppladdningsregeln och återgå till fliken " Regler för objektkonvertering" Låt oss lägga till för informationsregistret “ Typer av klienter” fastighetsomvandlingsregler: klient och klienttyp. Vi lämnar källan tom och i händelsehanteraren "Before unloading" skriver vi:

//För egenskapen “Client” Value = Source.Client; //För egenskapen “ClientType” If Source.Client = "Buyer" Then Expression = "Enumerations.ClientTypes.Buyer" ElseIf Source.Client = "Supplier" Then Expression = "Enumerations.ClientTypes.Supplier"; endIf;

I listan fylls uppgifterna i baserat på det valda dataprovet. Vi skickar helt enkelt klienten som en länk och skriver klienttypen i parametern " Uttryck" Data för denna parameter kommer att tolkas i mottagaren, och när den exekveras kommer rekvisiten att fyllas med det korrekta värdet från uppräkningen.

Det är det, bytesreglerna är klara.Det övervägda exemplet visade sig vara ganska universellt. Ett liknande tillvägagångssätt används ofta vid migrering av data från konfigurationer skapade på 7.7-plattformen. Ett slående exempel på detta är överföringen av periodiska detaljer.

Uppgift nr 3. Knep med bordsdelar

Ofta stöter du på uppgifter som kräver att rader läggs upp från en tabellsektion till flera. Till exempel, i den initiala konfigurationen, registreras tjänster och varor i en tabelldel, och i mottagaren är lagringen av dessa enheter uppdelad. Återigen kan problemet inte lösas med visuella medel. Här är det bekvämt att ta lösningen av det andra problemet som grund.

Vi gör en regel för avlastning av data, anger en godtycklig algoritm, och i hanteraren "Före lossning" skriver vi en begäran om att få data från tabelldelen.

För att spara utrymme kommer jag inte att tillhandahålla koden (du kan alltid hänvisa till källorna) för begäran - det finns inget ovanligt i den. Vi sorterar igenom det resulterande urvalet och placerar de sorterade resultaten i den redan bekanta parametern " Datasampling" Det är återigen bekvämt att använda en värdetabell som en samling:

DataFetch = New ValueTable(); //Det kommer att finnas ytterligare en tabelldel här Data Selection.Columns.Add(“Products”); //Här kommer det också att finnas en tabelldel Data Selection.Columns.Add(“Tjänster”); SelectionData.Columns.Add(“Länk”);

Uppgift nr 4. Överföra data till en operation

Om en organisation använder flera redovisningssystem, kommer det förr eller senare att finnas ett behov av att migrera data med efterföljande generering av transaktioner.

I konfigurationen " BP"det finns ett universellt dokument" Drift” och den är idealisk för att forma fler trådar. Det finns bara ett problem - dokumentet är gjort listigt, och data kan inte överföras till det så lätt.

Du hittar ett exempel på en sådan konvertering i källkoden för artikeln. Mängden kod visade sig vara ganska stor, så det är ingen idé att publicera den i samband med artikeln. Låt mig bara säga att uppladdning igen använder en godtycklig algoritm i reglerna för uppladdning av data.

Uppgift nr 5. Datasynkronisering över flera detaljer

Vi har redan tittat på flera exempel, men vi har fortfarande inte pratat om att synkronisera objekt under migreringen. Låt oss föreställa oss att vi behöver överföra motparter och några av dem finns förmodligen i mottagardatabasen. Hur överför man data och förhindrar att dubbletter visas? I detta avseende erbjuder CD flera sätt att synkronisera överförda objekt.

Den första är en unik identifierare. Många objekt har en unik identifierare som garanterar unikhet i en tabell. Till exempel i katalogen " Motparter” det kan inte finnas två element med samma identifierare. CD gör beräkningar för detta och för alla skapade PCO:er är en sökning med identifierare omedelbart aktiverad som standard. Under skapandet av PCO bör du ha uppmärksammat bilden av ett förstoringsglas bredvid objektets namn.

Synkronisering med en unik identifierare är en pålitlig metod, men det är inte alltid lämpligt. När du slår samman kataloger " Motparter” (från flera olika system) kommer det inte att hjälpa mycket.

I sådana fall är det mer korrekt att synkronisera objekt enligt flera kriterier. Det är mer korrekt att söka efter motparter med INN, KPP, Namn eller dela upp sökningen i flera steg.

Datakonvertering begränsar inte utvecklaren när det gäller att definiera sökkriterierna. Låt oss titta på ett abstrakt exempel. Anta att vi behöver synkronisera kataloger " Motparter” från olika informationsbaser. Låt oss förbereda PKO och i inställningarna för objektkonverteringsregler, kontrollera " Fortsätt att söka i sökfälten om mottagarobjektet inte hittas av identifierare" Med den här åtgärden definierade vi omedelbart två sökkriterier - med en unik identifierare och anpassade fält.

Vi har rätt att själva välja fält. Genom att markera TIN, KPP och Name kommer vi omedelbart att ange flera sökkriterier. Bekväm? Helt klart, men återigen detta räcker inte. Vad händer om vi vill ändra sökkriterierna? Till exempel, först söker vi efter kombinationen TIN+KPP, och om vi inte hittar något, börjar vi pröva lyckan med namnet.

En sådan algoritm är ganska kapabel att implementeras. I händelsehanteraren " Sökfält” vi kan ange upp till 10 sökkriterier och för vart och ett av dem definiera sin egen sammansättning av sökfält:

Om SearchOptionNumber = 1 då SearchPropertyNameString = “TIN, KPP”; OtherwiseIfSearchOptionNumber = 2 ThenSearchPropertyNameString = “Namn”; endIf;

Det finns alltid flera lösningar

Varje uppgift har flera lösningar, och överföring av data mellan olika konfigurationer är inget undantag. Varje utvecklare har rätt att välja sin egen lösningsväg, men om du ständigt måste utveckla komplexa datamigreringar rekommenderar jag starkt att du uppmärksammar "". Du kanske måste lägga resurser (tid) på träning till en början, men de kommer mer än att löna sig på det första mer eller mindre seriösa projektet.

Enligt min mening ignorerar 1C-företaget orättvist ämnet att använda datakonvertering. Under hela existensen av tekniken publicerades endast en bok om den: "1C: Enterprise 8. Datakonvertering: utbyte mellan applikationslösningar." Boken är ganska gammal (2008), men det är ändå lämpligt att bekanta sig med den.

Kunskap om plattformar är fortfarande nödvändig

"är ett universellt verktyg, men om du planerar att använda det för att skapa datamigreringar från konfigurationer utvecklade för 1C:Enterprise 7.7-plattformen, måste du lägga tid på att bli bekant med det inbyggda språket. Språkets syntax och ideologi är väldigt olika, så du måste lägga tid på att lära dig. I övrigt förblir principen densamma.