Konvertering av datautveksling mellom applikasjonsløsninger. Videoinstruksjoner for konvertering

1. Introduksjon.

2. Hva du trenger: 1C-konfigurasjon: Datakonvertering 2.* og behandling fra pakken. For eksempeloppgaver, la oss ta konfigurasjoner 1C: Trade Management 11 og 1C: BP 3.*.

Så for å utvikle regler for opplasting av data til 1C, trenger du 1C-konfigurasjonen: Objektkonvertering 2, samt behandlingen inkludert i pakken.

For eksempel har vi allerede distribuert en konverteringsdatabase og lansert den.

Vi vil skrive utviklingen av utvekslingsregler mellom 1C: Trade Management 11 og 1C: Enterprise Accounting 3 konfigurasjon (UT / ACCOUNT utvekslingsregler).

3. Vi trenger prosessering for å laste ut metadatastrukturen og utveksle.

Det første du må skaffe deg for utvikling er filer med en metadatastruktur. Dette gjøres ved å bruke prosessering for lossing av metadatastrukturen inkludert i objektkonverteringspakken.

Faktisk, i den utpakkede konfigurasjonskatalogen for konfigurasjoner på administrerte skjemaer, er vi interessert i behandlingen av MD83Exp.epf. Hvis lossing må gjøres fra konfigurasjoner på vanlige skjemaer, brukes MD82Exp.epf-behandling. Dette er hvis du for eksempel trenger å få en struktur fra slike konfigurasjoner som 1C: UT 10, 1C: Manufacturing Enterprise Management 1.3, 1C: Integrated Automation 1.1, 1C: Zup 2.5 og så videre.

Videre, for å laste opp og laste ned data til 1C ved å bruke reglene våre, må du behandle "Universell datautveksling i XML-format" V8Exchan83.epf for konfigurasjoner på administrerte skjemaer som 1C: Trade Management 11.*, 1C BP 3, 1C: ERP 2. * og lignende. Og følgelig V8Exchan83.epf - for konfigurasjoner på vanlige skjemaer.

4. Laste opp metadatastrukturen til konfigurasjonen 1C: Trade Management 11.3 og 1C: Enterprise Accounting 3.0.*

La oss starte med å laste ned metadatastrukturen fra 1C: Enterprise Accounting 3-konfigurasjonen.
La oss åpne behandlingen av MD83Exp.epf

I behandlingsskjemaet er det tilleggsinnstillinger der vi kan aktivere eller deaktivere muligheten til å laste opp registre og bevegelser til 1C. Det er også et valg om hvor opplastingen skal finne sted: på 1C-serveren eller "på klienten." Angi navnet på filen der datastrukturen skal lastes opp. På lignende måte laster vi ut metadatastrukturen til Trade Management 11-konfigurasjonen.

Nå må du laste opp konfigurasjonen til konverteringsdatabasen. Dette punktet kan nås både fra listen over konfigurasjoner og fra listen over konverteringer. La oss bare starte opp fra skrivebordet:

Last inn BP-strukturen i dialogboksen:

Og på samme måte - strukturen til Trade Management.

Når nedlastingen er fullført, vises en dialogboks der du kan angi et navn som passer for deg.

6. Lage konverteringsregler i 1C ved å bruke et spesifikt eksempel på en oppgave.

Deretter går du til "Sett opp objektregler", hvor vi oppretter en ny innstilling.
I dialogboksen for opprettelse av konvertering velger du "kilde"-konfigurasjonen og "destinasjon"-konfigurasjonen (som du lastet inn tidligere) og klikker OK.

Siden jeg i denne artikkelen planla å vise skapelsen "fra bunnen av" og "uten søppel", minner jeg deg om at vi ikke lager noe automatisk. Ingen prototyper.

Vi vil ikke gjøre noe i denne dialogboksen, bare klikk på "Lukk".

La oss lage regler for å laste opp ikke ett dokument til ett, men en type til et annet, for eksempel dokumentet Salg av varer og tjenester fra UT 11 med nødvendige oppslagsverk til dokumentet Mottak av varer og tjenester i BP 3.

Så vi lager en ny PKO (regelen for konvertering av objekter i 1C)

Velg kilden Salg av varer og tjenester og mottak av varer og tjenester og klikk OK.
I dette tilfellet vil en dialogboks vises, hvor vi igjen nekter automatisk opprettelse av PKS (Property Conversion Rules). Deretter velger vi bare de nødvendige.

Men på forslaget om å opprette DVP (dataopplastingsregler), svarer vi "Ja".

PVD-er opprettes, noe som vil gjenspeiles i behandlingen av den universelle XML-utvekslingen for valg:

Datakonverteringsregler med tomme eiendomskonverteringsregler vil også bli opprettet.

Dessuten er det klart at det som standard foreslås å søke etter programvaren ved hjelp av den interne objektidentifikatoren. Dette indikeres av forstørrelsesglasset nær PCO. Vi vil gjøre vårt eget søk, og vi vil gjøre det etter dokumentnummer og dato på begynnelsen av dagen.

Vi fjerner søket fra UIO:

La oss nå begynne å sammenligne de nødvendige egenskapene (detaljene) til objektet. For å gjøre dette, klikk "Synkroniser egenskaper" (etikett "1" på skjermen). Vi fjerner den rekursive opprettelsen av regler ("2"). Fjern alle de merkede detaljene ("3"). Og vi velger selv hva vi trenger.

Velg for eksempel det du trenger:

Jeg gjør oppmerksom på at vi vil gjøre motpartens PKS til organisasjonen, og organisasjonen til motparten, og vi vil også sammenligne noen detaljer som ikke stemmer med navn, for eksempel "Valuta" og "Dokument Valuta".

Der vi ser at det ikke er noen konverteringsregler ennå.

La oss begynne å gå gjennom detaljene og beskrive dem. Først setter vi opp et dokumentsøk som jeg skrev tidligere, laster opp og søker etter et dokument på begynnelsen av datoen, og endrer nummereringen. Vi vil erstatte de tre første tegnene med prefikset "UTB". Og siden nummereringen i BP og UT er 11 tegn hver, lager vi et sammensatt tall: vårt prefiks og 8 tegn fra kilden. Et eksempel i skjermbildet nedenfor.

Vi laster alltid opp dokumenter ulastet og uten bevegelse. Vi antar at dokumentene vil bli behandlet i mottakeren etter verifisering av brukeren.

For å gjøre dette, setter vi PKS som ikke utført, 0 eller 1, bruker vi det som en boolsk.

Ved å bruke valuta som eksempel lager vi en objektkonverteringsregel for PKS. Samtidig mener vi at det er valutaer i begge databasene, og de bør synkroniseres med kode. Derfor vil vi ikke opprette alle PKS i Valuta PQS, men vil bare legge til en søkekode. De. Vi avslår tilbudet om å opprette en PKS for objektet.

Den opprettede konverteringsregelen ble erstattet med PQR-en til dokumentet for PKS. Og selve standardregelen tilbys av en unik identifikator. Vi fikser det, søker i koden og setter egenskapen for ikke å lage et nytt objekt.

Som et resultat får vi følgende alternativ:

Deretter, analogt, lager vi PKO og PKS for de resterende detaljene. Dessuten søker vi etter en organisasjon etter motpart og omvendt etter TIN. Omtrent slik ser det ut med minimale detaljer (du kan legge til om nødvendig).

For PCO Motpartsavtaler søker vi på PKS Motpart, navn og eier.

La oss se hvordan du spesifiserer den nødvendige verdien i oppregningstypen i PKS. For eksempel «Type of Operation»-attributtet. Her kan du bruke ulike forhold og erstatningsverdier. For eksempel trenger vi "type operasjon" for alltid å bli losset "Varer", i dette tilfellet er det nok å skrive den nødvendige verdien i "pannen" -linjen.

Nedenfor er vist hvordan du installerer uten problemer og i de fleste tilfeller PCS for gjensidig oppgjørsmultiplikitet, gjensidig oppgjørssats, regnskapskonto.

For PKO Nomenklatura vil vi forlate søket med intern unik identifikator. Men la meg trekke oppmerksomheten din til hvordan du kan redefinere gruppen din. For eksempel godtar vi at en ny vare vil bli lastet opp fra 1C: Trade Management 11-konfigurasjonen, men det er nødvendig at varen samles i en bestemt gruppe "OurGroup".

For å implementere denne oppgaven oppretter vi en annen PKO. La oss kalle det "NomenclatureParent", som vi vil indikere i foreldrenes PCS i konverteringsregelen.

Vi setter opp to søk: etter navn, der vi strengt tatt angir navnet på gruppen vår, og den nødvendige egenskapen til «This is a Group»-attributtet er satt til sann.

Siden vi har bestemt at alle våre varer faller inn i vår gruppe, er det ikke nødvendig å losse grupper fra UT 11. For å gjøre dette, i Nomenclature-programvaren i hendelsesbehandleren «Før avlasting», vil vi sette et filter som det er ikke nødvendig å laste ut grupper "Feil = Kilde. Denne gruppen;".

I DRP (dataopplastingsregler) for salg av produkter og tjenester vil vi legge til et filter slik at dokumenter merket for sletting ikke lastes opp. For å gjøre dette, i VDP i hendelsesbehandlerne "Før avlasting", vil vi skrive filteret "Failure = Object.DeletionMark;".

La oss lagre de utviklede reglene i en fil.

7. For å oppsummere: Opplasting og lasting av data ved hjelp av utviklede regler for datautveksling.

Åpne i 1C: Trade Management 11 behandlingen "Universell datautveksling i XML-format" V8Exchan83.epf.

Lossingen er fullført, nå bruker vi den samme behandlingen for å laste inn i 1C: Enterprise Accounting 3.

Lasting fullført. La oss sjekke hvordan den lastet. Så dokumentet er lastet inn, slik vi ønsket - organisasjonen vår lastes inn i motparten, og motparten i organisasjonen. Regnskapskontoer er alle lastet ned og installert. Vi fikk dokumentnummeret med vårt prefiks og på begynnelsen av dagen. Alle opplysninger som ble gitt er fylt ut.

Vi sjekker lasting av varene. Vi ser at alt ble som vi hadde planlagt.

Vi har laget og fylt ut detaljene slik vi hadde tenkt. Det er mange finesser i konvertering og noen enkle, men nødvendige ting som hjelper deg med å skrive konverteringen nøyaktig. Og dette lar deg minimere feil, ikke ødelegge eksisterende data og kvitte seg med unødvendig søppel. Dette er et av de enkleste eksemplene. Du kan også konvertere ett objekt til mange, eller omvendt, mange til ett.

Nå er det datakonvertering 3, det løser andre problemer. Derfor er også konvertering 2 nødvendig. Lykke til alle med læring og mestring.

Selvfølgelig, hvis du er en programmerer og dette er hovedjobben din, kan du prøve å skrive konverteringen selv. Men hvis ikke, bør du verdsette tiden din i ditt aktivitetsfelt, og be fagfolk utføre denne oppgaven.

1C:Enterprise 8. Datakonvertering: datautveksling mellom applikasjonsløsninger (med applikasjon på CD-ROM) (artikkel 4601546049094)

"1C:Enterprise" er et universelt system for automatisering av virksomhetsaktiviteter og kan brukes til å løse ulike administrasjons- og regnskapsproblemer. For tiden er det utviklet et stort antall standard- og spesialiserte løsninger på 1C:Enterprise-plattformen, som kan fungere i tett integrasjon med andre løsninger, både på denne plattformen og med tredjeparts programvare.

Av stor betydning for effektivt arbeid er evnen til å organisere utveksling mellom ulike informasjonssystemer. 1C:Enterprise-plattformen tilbyr en rekke verktøy for datautveksling og integrering av applikasjonsløsninger.

Boken undersøker i detalj datautveksling i XML-format, som i dag er en allment akseptert måte å presentere data på. Prosedyrene for å utvikle regler er beskrevet, hvis anvendelse vil sikre overføring av informasjon fra ett informasjonssystem til et annet, inkludert utveksling av data mellom standard 1C:Enterprise-konfigurasjoner.

Boken er ledsaget av en CD som inneholder demoinformasjonsbaser med eksempler på utvekslingsregler og "1C:Enterprise. Data Conversion"-konfigurasjonen.

Merk følgende! I den første trykkingen var det en teknisk feil på slutten av boken. Korrigerte sider kan være

Foreløpig er restene av mangelen trukket fra salg og en korrigert utgave er utgitt.
Vi beklager ulempen og er klare til å erstatte defekte varer gratis.

Kjøpe:

Kontakt 1C-partneren som betjener organisasjonen din og legg inn en bestilling, og fortell ham koden som er tildelt boken (vist i tabellen nedenfor). Du kan også kjøpe boken fra andre partnere til selskapet "1C".

• i nettbutikken "1C-Interest" (levering av bøker med bud, Russian Post, DHL, EMS)
• i bokhandlere i byen din

Se også:

Bokkostnad

Bokstruktur

Introduksjon

Kapittel 1. Generelle prinsipper for oppsett av regler

Kapittel 2: Bruke regler

Kapittel 3. Automatisk oppretting av regler

Kapittel 4. Regelstruktur

Kapittel 5. Detaljert studie av reglene

Kapittel 6. Hendelsesbehandlere

• Alternativer
• "Konverterings"-behandlere
• Behandlere "Dataopplastingsregler"
• Behandlere «Regler for objektkonvertering»
• Behandlere «Regler for eiendomsgruppekonvertering»
• Behandlere "Regler for eiendomskonvertering"

Kapittel 7. Søkefelt

Kapittel 8. Regler for datarydding

Kapittel 9. Algoritmer og spørringer

Kapittel 10. Typiske eksempler på regler. Feilsøking

• Konvertering av overføringer
• Konvertering av kataloger
• Konvertering av dokumenter
• Konvertering av informasjonsregistre
• Kontoplankonvertering
• Konvertering av en karakteristisk typeplan
• Konvertering av beregningstyper plan
• Konvertering av konstanter 1C:Enterprise 7.7
• Konvertering av regnskapstransaksjon 1C:Enterprise 7.7

Kapittel 11. Optimaliseringsregler

• Regler for opplasting av data
• Regler for objektkonvertering
• Universal XML Data Interchange-behandling

Datakonvertering 2.0 og 2.1 er en teknologisk konfigurasjon av 1C, implementert på plattformversjoner fra 8.1 til 8.3.

Hovedoppgaven til verktøyet er å skrive regler for utveksling mellom applikasjonsløsninger 1C 8 og 7. Dagens versjon av datakonvertering er 3.0.

Datakonvertering er en veldig nyttig konfigurasjon; med dens hjelp kan du løse ikke bare problemet med å overføre informasjon fra en informasjonsbase til en annen, men også for eksempel konvertere informasjon i en database.

Konfigurasjonen er veldig praktisk å bruke med .

Datakonvertering vil være nyttig for enhver programmerer: å ha ferdighetene til å lage utvekslingsregler er et seriøst pluss for profesjonelle ferdigheter.

For å lære å jobbe med en konfigurasjon er det best egnet å løse praktiske problemer. Prøv å finne på oppgaver for deg selv, for eksempel: overføre noe informasjon fra en database til en annen, gjøre om et salgsdokument til et kvitteringsdokument, "legge inn" gjeldende regnskapssaldo i et dokument "innføre saldo" og andre oppgaver.

Det vil være veldig nyttig å forstå "standard" utvekslingsreglene i 1C 8.3; der kan du ofte finne interessante eksempler på implementering av oppgaver.

For å forstå det grunnleggende, trenger du materialer, vi vil vurdere dem nedenfor.

Videoinstruksjoner for konvertering

For det grunnleggende om å sette opp datautveksling i 1C ved å bruke "1C Data Conversion"-konfigurasjonen, se eksemplet i videoen:

Materialer, lærebøker for å studere 1C Data Conversion 2.0

Det er ikke for mye materiale og dokumentasjon på Internett, jeg prøvde å samle det viktigste og mest interessante materialet:

0. Først av alt anbefaler jeg det gratis videokurset av Ilya Leontyev, det er tilgjengelig på link.

1. Jeg vil først og fremst råde deg til å bruke den innebygde hjelpen i konfigurasjonen. Det er veldig godt skrevet og teknisk godt implementert:

2. Den nest viktigste informasjonskilden er nettstedet http://www.mykod.info/ (nettstedet er stengt), spesialisert spesielt på datakonvertering. Der kan du laste ned et stort antall materialer ved konvertering.

3. Separat vil jeg fremheve læreboken - (forfatter - Olga Kuznetsova).

Migrering av data mellom ulike konfigurasjoner er ikke en triviell oppgave. Som alltid finnes det flere løsninger, men ikke alle er optimale. La oss prøve å forstå nyansene i dataoverføring og velge en universell strategi for å løse slike problemer.

Problemet med datamigrering (vi snakker utelukkende om 1C-selskapsprodukter) fra en løsning til en annen oppsto ikke i går. 1C-selskapet forstår utmerket godt hvilke vanskeligheter utviklere møter når de oppretter migreringer, så det prøver på alle mulige måter å hjelpe med verktøy.

Under utviklingen av plattformen introduserte selskapet en rekke universelle verktøy, samt teknologier som forenkler dataoverføring. De er innebygd i alle standardløsninger, og problemet med migrering mellom identiske konfigurasjoner er generelt løst. Seieren bekreftes nok en gang av den tette integrasjonen av standardløsninger.

Med migrasjoner mellom ikke-standardløsninger er situasjonen noe mer komplisert. Et bredt utvalg av teknologier lar utviklere uavhengig velge den optimale måten å løse et problem fra deres synspunkt.

La oss se på noen av dem:

• utveksling via tekstfiler;
• bruk av utvekslingsplaner;
• etc.

Hver av dem har sine egne fordeler og ulemper. For å oppsummere, vil den største ulempen være dens detaljerthet. Uavhengig implementering av migrasjonsalgoritmer er full av betydelige tidskostnader, samt en lang feilsøkingsprosess. Jeg vil ikke engang snakke om ytterligere støtte til slike beslutninger.

Kompleksiteten og høye kostnadene for støtte fikk 1C-selskapet til å lage en universell løsning. Teknologier som gjør det mulig å forenkle utvikling og støtte av migrasjoner så mye som mulig. Som et resultat ble ideen implementert i form av en egen konfigurasjon - "Datakonvertering".

Datakonvertering - standardløsning, uavhengig konfigurasjon. Enhver bruker med et "ITS:Prof"-abonnement kan laste ned denne pakken helt gratis fra brukerstøttesiden eller ITS-disken. Installasjon utføres på standard måte - som alle andre standardløsninger fra 1C.

Nå litt om fordelene med løsningen. La oss starte med det viktigste - allsidighet. Løsningen er ikke skreddersydd for spesifikke plattformkonfigurasjoner/versjoner. Det fungerer like bra med både standard og tilpassede konfigurasjoner. Utviklere har en universell teknologi og en standardisert tilnærming til å skape nye migrasjoner. Allsidigheten til løsningen lar deg forberede migreringer selv for andre plattformer enn 1C:Enterprise.

Det andre store pluss er visuelle hjelpemidler. Enkle migreringer lages uten programmering. Ja, ja, uten en eneste kodelinje! For dette alene er det verdt å bruke tid på å lære teknologien én gang, og deretter bruke uvurderlige ferdigheter gjentatte ganger.

Den tredje fordelen jeg vil merke meg er fraværet av restriksjoner på datadistribusjon. Utvikleren velger selv metoden for å levere data til mottakerkonfigurasjonen. Det er to tilgjengelige alternativer umiddelbart: opplasting til en xml-fil og direkte tilkobling til infobasen (COM/OLE).

Studerer arkitektur

Vi vet allerede at datakonvertering kan gjøre underverker, men det er ennå ikke helt klart hva de tekniske fordelene er. Det første du må forstå er at enhver datamigrering (konvertering) er basert på utvekslingsregler. Exchange-regler er en vanlig xml-fil som beskriver strukturen som data fra informasjonssikkerheten skal lastes opp til. Tjenestebehandlingen som laster opp/laster ned data analyserer utvekslingsreglene og utfører opplastingen basert på dem. Under lasting skjer den omvendte prosessen.

"CD"-konfigurasjonen er en slags visuell konstruktør ved hjelp av hvilken utvikleren lager utvekslingsregler. Den vet ikke hvordan den skal laste ned data. Ytterligere ekstern tjenestebehandling inkludert i CD-distribusjonspakken er ansvarlig for dette. Det er flere av dem (XX i filnavnet er plattformens versjonsnummer):

• MDXXExp.epf- behandling lar deg laste opp en beskrivelse av infobasestrukturen til en xml-fil. Strukturbeskrivelsen lastes inn i CD-en for videre analyse og oppretting av utvekslingsregler.
• V8ExchanXX.epf- laster opp/laster ned data fra informasjonsbasen i henhold til utvekslingsreglene. I de fleste typiske konfigurasjoner er prosessering tilstede fra esken (se menypunktet "Service"). Behandlingen er universell og er ikke knyttet til noen spesifikke konfigurasjoner/regler.

Ok, la oss nå, basert på alt ovenfor, definere stadiene for å utvikle en ny konvertering:

1. Definisjon av oppgaven. Det er nødvendig å tydelig forstå hvilke data som må overføres (fra hvilke konfigurasjonsobjekter) og, viktigst av alt, hvor de skal overføres.
2. Utarbeidelse av beskrivelser av konfigurasjonsstrukturer (Kilde/Sink) for etterfølgende innlasting på CD. Problemet løses ved tjenestebehandling MDXXExp.epf.
3. Laster inn utarbeidede beskrivelser av strukturer i informasjonssikkerhet.
4. Lage utvekslingsregler ved hjelp av et visuelt CD-verktøy.
5. Utføre opplasting/nedlasting i henhold til de opprettede reglene for datakonvertering ved å bruke V8ExchanXX.epf-behandling.
6. Feilsøking av utvekslingsregler (om nødvendig).

Den enkleste konverteringen

For demonstrasjonen trenger vi to utplasserte konfigurasjoner. Jeg bestemte meg for å gå med alternativet: "Trade Management" 10. utgave og en liten hjemmeskrevet løsning. Oppgaven vil være å overføre data fra standard "UT" konfigurasjon. For korthets skyld, la oss kalle den selvskrevne løsningen "Sink", og handelsledelsen "Kilde". La oss begynne å løse problemet ved å overføre elementer fra "Nomenclature"-katalogen.

Først av alt, la oss ta en titt på datakonverteringsskjemaet og lese listen over handlinger som må gjøres på nytt. Deretter starter vi "Kilde"-konfigurasjonen og åpner MD82Exp.epf-tjenestebehandlingen i den.

Behandlingsgrensesnittet har ikke en overflod av innstillinger. Brukeren trenger kun å angi hvilke typer metadataobjekter som ikke skal inkluderes i strukturbeskrivelsen. I de fleste tilfeller trenger ikke disse innstillingene å endres, fordi Det er ikke noe særlig vits i å losse bevegelser ved å bruke akkumuleringsregistre (som et eksempel).

Det er mer riktig å danne bevegelsen mens du holder dokumenter i mottakeren. Alle bevegelser vil bli gjort av dokumentet selv etter overføringen. Det andre argumentet til forsvar for standardinnstillingene er reduksjonen i filstørrelse med opplasting.

Noen dokumenter (spesielt i standardkonfigurasjoner) genererer bevegelser over flere registre. Hvis du laster ut alt dette, blir den resulterende XML-filen for stor. Dette kan komplisere etterfølgende transport og lasting i mottakerbasen. Jo større datafilen er, jo mer RAM vil kreves for å behandle den. Under praksisen min hadde jeg muligheten til å møte uanstendig store opplastingsfiler. Slike filer nektet fullstendig å bli analysert med standardverktøy.

Så vi forlater alle standardinnstillingene og laster opp konfigurasjonsbeskrivelsen til en fil. Vi gjentar en lignende prosedyre for den andre basen.

Åpne CD-en og velg i hovedmenyen "Kataloger" -> "Konfigurasjoner". Katalogen lagrer beskrivelser av strukturene til alle konfigurasjoner som kan brukes til å lage konverteringer. Vi laster inn konfigurasjonsbeskrivelsen én gang, og deretter kan vi bruke den flere ganger for å lage forskjellige konverteringer.

I katalogvinduet, klikk på knappen " Legg til” og i vinduet som vises, velg filen som beskriver konfigurasjonen. Merk av for «Last inn i en ny konfigurasjon» og klikk på «Last inn»-knappen. Vi utfører lignende handlinger med beskrivelsen av strukturen til den andre konfigurasjonen.

Nå er du klar til å lage utvekslingsregler. I CD-hovedmenyen velger du "Kataloger" -> "Konverteringer". Legg til et nytt element. I vinduet for å opprette en ny konvertering, må du spesifisere: kildekonfigurasjonen (velg UT) og destinasjonskonfigurasjonen (velg "Mottaker"). Deretter åpner du fanen "Avansert" og fyller ut følgende felt:

• utvekslingsregler filnavn - de opprettede utvekslingsreglene vil bli lagret under dette navnet. Du kan endre filnavnet når som helst, men det er best å angi det nå. Dette vil spare tid i fremtiden. Jeg kalte reglene for demoeksemplet: "rules-ut-to-priemnik.xml".
• navn – navnet på konverteringen. Navnet kan være absolutt hva som helst, jeg begrenset meg til «Demo. UT til mottaker.»

Det er det, klikk "Ok". Umiddelbart dukker det opp et vindu foran oss som ber oss lage alle reglene automatisk. Å godta et slikt fristende tilbud vil gi mesteren en kommando om automatisk å analysere beskrivelsen av de valgte konfigurasjonene og uavhengig generere utvekslingsregler.

La oss prikke "i'et" med en gang. Veiviseren vil ikke kunne generere noe alvorlig. Denne muligheten bør imidlertid ikke utelukkes. Hvis det er nødvendig å etablere en utveksling mellom identiske konfigurasjoner, vil tjenestene til en spesialist være svært nyttige. For vårt eksempel er manuell modus å foretrekke.

La oss se nærmere på vinduet "Innstillinger for utvekslingsregler". Grensesnittet kan virke litt forvirrende – et stort antall faner stappfulle av kontroller. Faktisk er alt ikke så vanskelig; du begynner å bli vant til denne galskapen etter noen timers arbeid med applikasjonen.

På dette stadiet er vi interessert i to faner: «Regler for objektkonvertering» og «Regler for dataopplasting». Først må vi konfigurere samsvarsreglene, dvs. sammenligne objekter med to konfigurasjoner. På den andre bestemmer du mulige objekter som vil være tilgjengelige for brukeren for opplasting.

I andre halvdel av fanen "Regler for objektkonvertering" er det et ekstra panel med to faner: "Egenskapskonvertering" og " Konvertering av verdier" Den første vil velge egenskapene (detaljene) til det valgte objektet, og den andre er nødvendig for å jobbe med forhåndsdefinerte verdier (for eksempel forhåndsdefinerte katalogelementer eller oppregningselementer).

Flott, la oss nå lage konverteringsregler for kataloger. Du kan utføre denne handlingen på to måter: bruk veiviseren for objektsynkronisering (“”-knappen) eller legg til korrespondanse for hvert objekt manuelt.

For å spare plass bruker vi det første alternativet. I veiviservinduet fjerner du merket for gruppen " Dokumentasjon" (vi er bare interessert i kataloger) og utvide gruppen " Kataloger" Vi blar nøye gjennom listen og ser på navnene på oppslagsverk som kan sammenlignes.

I mitt tilfelle er det tre slike kataloger: Nomenklatur, Organisasjoner og Varehus. Det er også en katalog kalt Clients, som tjener samme formål som " Motparter"fra konfigurasjon" UT" Det er sant at mesteren ikke kunne sammenligne dem på grunn av deres forskjellige navn.

Vi kan fikse dette problemet selv. Vi finner i vinduet " Objektmatcher" oppslagsverk " Kunder", og velg "Motparter"-katalogen i kolonnen "Kilde". Merk deretter av i boksen i "Type"-kolonnen og klikk på "Ok" -knappen.

Objektsynkroniseringsveiviseren tilbyr å automatisk lage regler for konvertering av egenskaper for alle valgte objekter. Eiendommene vil bli sammenlignet med navn og for vår demonstrasjon vil dette være ganske tilstrekkelig, er vi enige. Det neste spørsmålet vil være et forslag om å lage opplastingsregler. La oss også gå med på det.

Grunnlaget for byttereglene er klart. Vi valgte objektene for synkronisering, og reglene for konvertering av egenskaper og opplastingsregler ble opprettet automatisk. La oss lagre utvekslingsreglene i en fil, åpne deretter IB "Kilde" (i mitt tilfelle er det UT) og starte tjenestebehandling i den V8Exchan82.epf.

Først av alt, i behandlingsvinduet, velg utvekslingsreglene vi opprettet. Vi svarer bekreftende på spørsmålet om lasteregler. Behandling vil analysere utvekslingsreglene og bygge et tre med objekter med samme navn tilgjengelig for opplasting. For dette treet kan vi sette opp alle slags utvalg eller utveksle noder, ved å endre hvilke vi trenger for å velge data. Vi ønsker å laste ned absolutt alle dataene, så det er ikke nødvendig å installere filtre.

Etter å ha fullført prosessen med å laste opp data til en fil, gå til IB " Mottaker" Vi åpner også for behandling i den V8Exchan82.epf, bare denne gangen går vi til fanen "Data Loading". Velg datafilen og klikk på "Last ned"-knappen. Det er det, dataene har blitt overført.

Problemer i den virkelige verden

Den første demoen kan være misvisende. Alt ser ganske enkelt og logisk ut. Dette er faktisk ikke sant. I virkelig arbeid oppstår problemer som er vanskelige eller helt umulige å løse ved bruk av visuelle virkemidler alene (uten programmering).

For ikke å bli skuffet over teknologien forberedte jeg flere virkelige problemer. Du vil garantert møte dem på jobben. De ser ikke så trivielle ut og får deg til å se på datakonvertering fra en ny vinkel. Vurder nøye de presenterte eksemplene, og bruk dem gjerne som utdrag når du skal løse reelle problemer.

Oppgave nr. 1. Fyll inn de manglende detaljene

Anta at vi må overføre katalogen " Motparter" Mottakeren har en lignende "klient"-katalog for dette formålet. Den er helt egnet for datalagring, men den har rekvisitter " Organisasjon”, som lar deg skille motparter ved å tilhøre organisasjonen. Som standard må alle motparter tilhøre gjeldende organisasjon (dette kan hentes fra konstanten med samme navn).

Det er flere løsninger på problemet. Vi vil vurdere muligheten for å fylle ut detaljene " Organisasjon"rett i databasen" Mottaker", dvs. på tidspunktet for datainnlasting. Den nåværende organisasjonen er lagret i en konstant, derfor er det ingen hindringer for å oppnå denne verdien. La oss åpne objektkonverteringsregelen (heretter referert til som PKO) " Kunder” (dobbeltklikk på objektet) og i veiviseren for oppsett av regler, gå til delen “Hendelsesbehandlere”. I listen over behandlere finner vi " Etter nedlasting”.

La oss beskrive koden for å få den gjeldende organisasjonen og deretter tilordne den til detaljene. På det tidspunktet "Etter lasting"-behandleren utløses, vil objektet være fullstendig utformet, men ennå ikke skrevet til databasen. Ingen forbyr oss å endre det etter eget skjønn:

Hvis IKKE Object.ThisGroup Then Object.Organization = Constants.CurrentOrganization.Get(); slutt om;

Før du fyller ut detaljene " Organisasjon"Det er nødvendig å sjekke verdien av attributtet" Denne gruppen" For oppslagsboken " Kunder"Den hierarkiske funksjonen er satt, så det er nødvendig å se etter gruppen. Fyll inn eventuelle detaljer på lignende måte. Husk å lese hjelpen for andre behandleralternativer " AfterLoading" For eksempel, blant dem er det parameteren " Avslag" Hvis du tildeler det verdien "True", vil ikke objektet bli skrevet til databasen. Dermed blir det mulig å begrense objektene som kan skrives ved lasting.

Oppgave nr. 2. Detaljer for informasjonsregisteret

I katalogen " Motparter"UT-konfigurasjoner, detaljer tilgjengelig" Kjøper"Og" Forsørger" Begge detaljene er av typen " boolsk” og brukes til å bestemme typen motpart. I IB " Mottaker", i katalogen " Kunder"Det er ingen lignende detaljer, men det er et register over informasjon" Typer klienter" Den utfører en lignende funksjon og kan lagre flere attributter for én klient. Vår oppgave er å overføre verdiene til detaljene til separate oppføringer i informasjonsregisteret.

Dessverre kan visuelle virkemidler alene ikke klare seg her heller. La oss begynne i det små, lage en ny programvare for informasjonsregisteret " Typer klienter" Ikke oppgi noe som kilde. Unngå å opprette opplastingsregler automatisk.

Det neste trinnet er å lage reglene for opplasting. Gå til riktig fane og klikk på " Legg til" I vinduet for å legge til opplastingsregler fyller du ut:

• Prøvetakingsmetode. Bytt til "Vilkårlig algoritme";
• Konverteringsregel. Velg informasjonsregisteret "Kundertyper";
• Kode (navn) til regelen. Skriv det ned som "Lasting av klienttyper";

Nå må du skrive kode for å velge data for opplasting. Parameteren " Dataprøvetaking" Vi kan plassere en samling med et forberedt datasett i. Parameter " Dataprøvetaking" kan ta på seg forskjellige verdier - søkeresultat, utvalg, samlinger av verdier, etc. Vi initialiserer den som en verditabell med to kolonner: klient og klienttype.

Nedenfor er koden for hendelsesbehandleren " Før behandling" Den initialiserer parameteren " Dataprøvetaking" etterfulgt av å fylle ut data fra katalogen " Motparter" Her bør du være oppmerksom på å fylle ut kolonnen " Klienttype" I "UT" er attributtene våre av typen "boolsk", og mottakeren er en oppregning.

På dette stadiet kan vi ikke konvertere dem til den nødvendige typen (det er ikke i UT), så foreløpig vil vi la dem være i form av strenger. Du trenger ikke å gjøre dette, men jeg vil umiddelbart vise hvordan du caster til en manglende type i kilden.

DataFetch = New ValueTable(); DataSelection.Columns.Add("Klient"); DataSelection.Columns.Add("ClientType"); SelectingDataFromDirectory = Directories.Accounts.Select(); While SelectingDataFromDirectory.Next() Loop If SelectingDataFromDirectory.ThisGroup Fortsett deretter; slutt om; If Data Selection From Directory.Buyer Then NewRow = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewRow.ClientType = "Kunde"; slutt om; If DataFetchFromDirectory.Supplier Then NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Leverandør"; slutt om; EndCycle;

La oss lagre dataopplastingsregelen og gå tilbake til fanen " Regler for objektkonvertering" La oss legge til for informasjonsregisteret " Typer klienter” eiendomskonverteringsregler: klient og klienttype. Vi lar kilden være tom, og i hendelsesbehandleren "Før avlasting" skriver vi:

//For “Client”-egenskapen Value = Source.Client; //For egenskapen “ClientType” If Source.Client = "Buyer" Then Expression = "Enumerations.ClientTypes.Buyer" ElseIf Source.Client = "Supplier" Then Expression = "Enumerations.ClientTypes.Supplier"; slutt om;

I oppføringen fylles detaljene ut basert på det valgte datautvalget. Vi sender ganske enkelt klienten som en lenke, og skriver klienttypen i parameteren " Uttrykk" Dataene til denne parameteren vil bli tolket i mottakeren, og når den utføres, vil rekvisitten fylles med riktig verdi fra oppregningen.

Det er det, utvekslingsreglene er klare.Det vurderte eksemplet viste seg å være ganske universelt. En lignende tilnærming brukes ofte ved migrering av data fra konfigurasjoner opprettet på 7.7-plattformen. Et slående eksempel på dette er overføring av periodiske detaljer.

Oppgave nr. 3. Triks med borddeler

Ofte kommer du over oppgaver som krever å legge ut rader fra én tabelldel til flere. For eksempel, i den første konfigurasjonen, er tjenester og varer registrert i en tabelldel, og i mottakeren er lagringen av disse enhetene delt. Igjen, problemet kan ikke løses med visuelle midler. Her er det praktisk å ta løsningen av det andre problemet til grunn.

Vi lager en regel for lossing av data, spesifiserer en vilkårlig algoritme, og i behandleren "Før avlasting" skriver vi en forespørsel om å hente data fra tabelldelen.

For å spare plass vil jeg ikke gi koden (du kan alltid referere til kildene) for forespørselen - det er ikke noe uvanlig i den. Vi sorterer gjennom det resulterende utvalget, og plasserer de sorterte resultatene i den allerede kjente parameteren " Dataprøvetaking" Det er igjen praktisk å bruke en verditabell som en samling:

DataFetch = New ValueTable(); //Det vil være en annen tabelldel her Data Selection.Columns.Add(“Products”); //Her vil det også være en tabelldel Data Selection.Columns.Add(“Tjenester”); SelectionData.Columns.Add(“Link”);

Oppgave nr. 4. Overføre data til en operasjon

Hvis en organisasjon bruker flere regnskapssystemer, vil det før eller siden være behov for å migrere data med den påfølgende genereringen av transaksjoner.

I konfigurasjonen " BP"det er et universelt dokument" Operasjon” og den er ideell for å forme flere ledninger. Det er bare ett problem - dokumentet er laget på en snedig måte, og dataene kan ikke overføres til det så enkelt.

Du finner et eksempel på en slik konvertering i kildekoden til artikkelen. Kodemengden viste seg å være ganske stor, så det er ingen vits i å publisere den i forbindelse med artikkelen. La meg bare si at opplasting igjen bruker en vilkårlig algoritme i reglene for opplasting av data.

Oppgave nr. 5. Datasynkronisering på tvers av flere detaljer

Vi har allerede sett på flere eksempler, men vi har fortsatt ikke snakket om synkronisering av objekter under migrering. La oss forestille oss at vi trenger å overføre motparter og noen av dem er sannsynligvis i mottakerdatabasen. Hvordan overføre data og forhindre at duplikater vises? I denne forbindelse tilbyr CD flere måter å synkronisere overførte objekter på.

Den første er med en unik identifikator. Mange objekter har en unik identifikator som garanterer unikhet i en tabell. For eksempel i katalogen " Motparter” det kan ikke være to elementer med samme identifikatorer. CD foretar beregninger for dette og for alle opprettede PCO-er, er et søk etter identifikator umiddelbart aktivert som standard. Under opprettelsen av PCO bør du ha tatt hensyn til bildet av et forstørrelsesglass ved siden av navnet på objektet.

Synkronisering ved hjelp av en unik identifikator er en pålitelig metode, men det er ikke alltid hensiktsmessig. Når du slår sammen kataloger " Motparter” (fra flere forskjellige systemer) vil det ikke hjelpe mye.

I slike tilfeller er det mer riktig å synkronisere objekter etter flere kriterier. Det er mer riktig å søke etter motparter etter INN, KPP, Navn eller dele søket i flere stadier.

Datakonvertering begrenser ikke utvikleren i å definere søkekriteriene. La oss se på et abstrakt eksempel. Anta at vi må synkronisere kataloger " Motparter” fra ulike informasjonsbaser. La oss forberede PKO og i innstillingene for objektkonverteringsregler, sjekk " Fortsett å søke i søkefelt hvis mottakerobjektet ikke blir funnet av identifikator" Med denne handlingen definerte vi umiddelbart to søkekriterier - med en unik identifikator og tilpassede felt.

Vi har rett til å velge felt selv. Ved å krysse av for TIN, KPP og Name, vil vi umiddelbart angi flere søkekriterier. Komfortabel? Helt, men igjen er dette ikke nok. Hva om vi ønsker å endre søkekriteriene? For eksempel, først søker vi etter TIN+KPP-kombinasjonen, og hvis vi ikke finner noe, begynner vi å prøve lykken med navnet.

En slik algoritme er ganske i stand til å implementeres. I hendelsesbehandleren " Søkefelt” vi kan spesifisere opptil 10 søkekriterier og for hvert av dem definere sin egen sammensetning av søkefelt:

Hvis SearchOptionNumber = 1 så SearchPropertyNameString = "TIN, KPP"; OtherwiseIfSearchOptionNumber = 2 ThenSearchPropertyNameString = "Navn"; slutt om;

Det finnes alltid flere løsninger

Enhver oppgave har flere løsninger, og overføring av data mellom ulike konfigurasjoner er intet unntak. Hver utvikler har rett til å velge sin egen løsningsbane, men hvis du hele tiden må utvikle komplekse datamigrasjoner, anbefaler jeg på det sterkeste å ta hensyn til "". Du må kanskje investere ressurser (tid) i trening i starten, men de vil mer enn lønne seg på det første mer eller mindre seriøse prosjektet.

Etter min mening ignorerer 1C-selskapet urettferdig temaet bruk av datakonvertering. Under hele eksistensen av teknologien ble det bare publisert én bok om den: "1C: Enterprise 8. Datakonvertering: utveksling mellom applikasjonsløsninger." Boken er ganske gammel (2008), men det er likevel lurt å sette seg inn i den.

Kunnskap om plattformer er fortsatt nødvendig

"er et universelt verktøy, men hvis du planlegger å bruke det til å lage datamigrasjoner fra konfigurasjoner utviklet for 1C:Enterprise 7.7-plattformen, må du bruke tid på å bli kjent med det innebygde språket. Syntaksen og ideologien til språket er veldig forskjellige, så du må bruke tid på å lære. Ellers forblir prinsippet det samme.

"1C:Bedrift"er et universelt system for automatisering av virksomhetsaktiviteter og kan brukes til å løse ulike ledelses- og regnskapsproblemer. For tiden er det utviklet et stort antall standard- og spesialiserte løsninger på plattformen" 1C:Bedrifter", som kan fungere i tett integrasjon med andre løsninger, både på denne plattformen og med tredjepartsprogramvare.

Av stor betydning for effektivt arbeid er evnen til å organisere utveksling mellom ulike informasjonssystemer. Plattform" 1C:Bedrift" gir en rekke verktøy for datautveksling og integrasjon av applikasjonsløsninger.

Boken undersøker i detalj datautveksling i XML-format, som i dag er en allment akseptert måte å presentere data på. Prosedyrene for å utvikle regler er beskrevet, hvis anvendelse vil sikre overføring av informasjon fra ett informasjonssystem til et annet, inkludert utveksling av data mellom standardkonfigurasjoner " 1C:Bedrifter".

Boken er ledsaget av en CD som inneholder demoinformasjonsbaser med eksempler på utvekslingsregler og konfigurasjon " 1C:Bedrift. Datakonvertering".

Bokstruktur

Introduksjon

Kapittel 1. Generelle prinsipper for oppsett av regler

Kapittel 2. Bruk av regler

Kapittel 3. Automatisk opprettelse av regler

Kapittel 4. Regelstruktur

Kapittel 5. Detaljert studie av reglene

Kapittel 6. Eventbehandlere

• Alternativer
• "Konverterings"-behandlere
• Behandlere "Dataopplastingsregler"
• Behandlere «Regler for objektkonvertering»
• Behandlere «Regler for eiendomsgruppekonvertering»
• Behandlere "Regler for eiendomskonvertering"

Kapittel 7. Søkefelt

Kapittel 8. Regler for rengjøring av data

Kapittel 9 Algoritmer og spørringer

Kapittel 10. Typiske eksempler på regler. Feilsøking

• Konvertering av overføringer
• Konvertering av kataloger
• Konvertering av dokumenter
• Konvertering av informasjonsregistre
• Kontoplankonvertering
• Konvertering av en karakteristisk typeplan
• Konvertering av beregningstyper plan
• Konvertering av konstanter 1C:Enterprise 7.7
• Konvertering av regnskapstransaksjon 1C:Enterprise 7.7

Kapittel 11. Regeloptimalisering

• Regler for opplasting av data
• Regler for objektkonvertering
• Universal XML Data Interchange-behandling