I noen tilfeller (for eksempel med en stor dokumentflyt eller med kompleks regnskap) er det mye mer praktisk for sluttbrukeren å distribuere regnskap mellom flere applikasjoner, og utveksle data mellom dem fra tid til annen. Før utgivelsen av 1C-plattformen versjon 8.3 skjedde standard datautveksling utelukkende på brukerens forespørsel gjennom opplasting og nedlasting av informasjon ved hjelp av XML-filer. Nylig har datasynkroniseringsmekanismen i 1C blitt stadig mer brukt.

Det er flere grunner til populariteten til synkronisering:

• Det er ikke nødvendig å kjøre prosessene for å laste og losse data separat;
• Automatisk utførelse av informasjonsutveksling forstyrrer ikke manuell utveksling;
• Enkel å konfigurere (for standardkonfigurasjoner trenger du ikke engang å lage utvekslingsregler;
• Det er nok å opprette synkronisering én gang og erklære en tidsplan for utførelse.

Betingelsene for vår oppgave

Ved inngangen har vi to standard databasekonfigurasjoner:

1. Lønn og personalstyring (versjon 3.1.3);
2. Regnskap for en landbruksbedrift (versjon 3.0.52).

Begge databasene fungerer i filmodus. Synkronisering kan konfigureres fra hvilken som helst database.

Hvis synkronisering skal konfigureres fra "Regnskap" til "ZUP", må avkrysningsboksen "Synkronisering" aktiveres og omvendt.

Hvor er innstillingene

I "Regnskap", gå til undersystemet "Administrasjon", i "Innstillinger"-menyen og finn elementet "Datasynkronisering" (fig. 1)

Syåpnes (fig. 2)

Ris. 2

Her kan vi:

1. Aktiver eller deaktiver synkronisering;
2. Forby lasting av irrelevante data;
3. Angi et prefiks for å identifisere de overførte dataene;
4. Gå til andre synkroniseringsinnstillinger.

Ved å starte synkronisering ved å krysse av i den aktuelle boksen og definere et prefiks, kan vi stenge regnskapsavdelingen. Videre arbeid vil bli gjort i "Lønn".

Innstillingsvinduet for datasynkronisering er vist i fig. 3

Ris. 3

La oss se nærmere på det.

Synkroniseringsinnstillinger-vinduet

La oss starte i rekkefølge:

Separat vil jeg henlede leserens oppmerksomhet på vinduet "Registrering av endringer" (fig. 5). Øverst er det antall sendte og mottatte meldinger; etter en vellykket utveksling må tallene i kildedatabasen og måldatabasen samsvare. I noen tilfeller (synkronisering skjedde med en kopi av databasen, funksjonsfeil), er nummereringen i databasene ødelagt. Du kan rette opp denne situasjonen ved å klikke på hyperkoblingen med tall. Denne handlingen lar deg angi gjeldende antall sendte og innkommende meldinger manuelt (fig. 6)

Ris. 6

Synkroniseringsinnstillinger

Det er to kommandoer på fanen "Datasynkroniseringsinnstillinger":

• Melodi;
• Last ned regler.

Når du kjører kommandoen "Load Rules" åpnes skjemaet (fig. 7)

Ris. 7

Her kan vi velge om vi skal bruke standard utvekslingsreglene som følger med i konfigurasjonen, eller om vi skal synkronisere etter våre egne regler lagret i arkivfilen.

De resterende innstillingene gjøres ved å klikke på "Konfigurer"-knappen (fig. 8).

Ris. 8

I det første vinduet som åpnes kan du:

1. Åpne konfigurasjonsskjemaet for synkroniseringsskript;
2. Se hendelser for sending og mottak av informasjon;
3. Bestem datoen som utvekslingen vil finne sted;
4. Hvis det føres regnskap for flere organisasjoner, kan du spesifisere hvilke av dem som skal delta i utvekslingen;
5. Definer parametrene for opplasting av lønnstransaksjoner: med eller uten detalj etter ansatt (sammendrag).

Kommandoen "Last sett med regler" ligner på den samme kommandoen i forrige innstillingsvindu.

Det er verdt å se nærmere på tilkoblingsparametrene (fig. 9)

Ris. 9

I vårt tilfelle er destinasjonsbasen og kildebasen plassert på samme datamaskin og fungerer i filmodus, så synkronisering mellom dem skjer gjennom en direkte forbindelse.

Vi må:

• Bestem banen til mottaksbasen;
• Angi autorisasjonsparametere (en bruker med administratorrettigheter må opprettes i mottakerdatabasen);
• Etter å ha kontrollert tilkoblingen, kan vi anta at oppsettet vårt er fullført.

Hvis utvekslingen skjer gjennom andre tilkoblingstyper, må du konfigurere parametrene deres på de tilsvarende fanene.

Tidsplaninnstillinger

Og på slutten, noen få ord om å sette opp synkroniseringsplanen, den utføres i den tilsvarende fanen i vinduet (fig. 3) og er ikke forskjellig fra den tilsvarende formen for å sette opp tidsplanen for andre rutineoppgaver.

1C presenterte den første versjonen av det nye foEnterpriseData, som er basert på XML og, ifølge forfatterne, ikke bare er ment å forene samspillet mellom applikasjonsløsninger og deres individuelle komponenter laget av selskapet selv, men også brukes som en universell ialle forretningsapplikasjoner på alle programvareplattformer, inkludert selvfølgelig 1C:Enterprise.

Selskapet har lenge øvd på å lage og bruke åpne standarder for informasjonsinteraksjon av sine applikasjoner med programvare fra uavhengige utviklere, men til nå har dette kun dreid seg om enkelte spesialiserte fagområder. Dette er nøyaktig hva CommerceML-formatet, opprettet for nesten femten år siden, er for å løse problemet med e-handel, samt "Client-Bank" og DirectBank for kommunikasjon mellom 1C-applikasjoner og eksterne banksystemer. EnterpriseData er derimot en universell mekanisme som kan dekke alle områder av virksomhetens aktiviteter – økonomi, produksjon, innkjøp og salg, lagerdrift osv. Den første versjonen av formatet inneholder en beskrivelse av 94 typer dokumenter fra ulike typer dokumenter. forretningsområder. 1C planlegger å legge til nye dokumenter og detaljere eksisterende.

Som 1C-representanter forklarer, er fremveksten av EnterpriseData forklart med behovet for ikke bare å integrere selskapets applikasjoner i programvare fra andre utviklere, men også – kanskje til og med primært – å skape en enhetlig mekanisme for informasjonskommunikasjon innenfor 1C:Enterprise-programvarefamilien. Inntil nylig ble et bredt spekter av løsninger brukt for å løse disse problemene, ofte laget fra sak til sak. Overgangen av 1C-produkter til EnterpriseData har allerede begynt; den brukes i alle de nyeste versjonene av nøkkelapplikasjonene ("1C: ERP Enterprise Management 2.0", "1C: Accounting 8" 3.0, "1C: Accounting 8 KORP" 3.0, "1C: Detaljhandel" "2.0, "1C: Handelsledelse" 11). Samtidig forventes det ikke å erstatte allerede brukte standarder (CommerceML, arbeid med banker) med EnterpriseData, siden tidstestede spesialiserte algoritmer fungerer mer effektivt enn universelle verktøy.

1C tror at det nye formatet vil finne bred bruk blant uavhengige utviklere som lager applikasjoner på 1C:Enterprise-plattformen; ferdige programvarekomponenter tilbys for dem som en del av Library of Standard Subsystems (noe sånt som SDK for 1C:Enterprise).

Ved bruk av EnterpriseData-standarden overføres data mellom applikasjoner i form av en XML-fil ved hjelp av passende XML-skjemaer, mens fysisk overføring av informasjon kan utføres ved hjelp av ulike mekanismer: webtjenester, fildeling gjennom en katalog, FTP og e-post. Et viktig poeng er at interaksjonsalgoritmen innebærer muligheten for mottakeren til å bekrefte det faktum å motta og behandle dataene som er sendt til ham. Selve XML-filen leveres fysisk i komprimert form (ZIP), som ofte lar deg redusere informasjonstrafikken betraktelig.

1C lover videreutvikling av EnterpriseData-formatet og dets støtte i et økende antall av sine applikasjoner. Denne standarden vil bli administrert av selskapet selv; dens skapere har ennå ingen planer om å transformere den til en uavhengig industristandard.

I denne artikkelen vil jeg beskrive min, så langt lille, erfaring med å organisere datautveksling gjennom det universelle EnterpriseData-formatet.

I mitt tilfelle er utvekslingen konfigurert mellom "Trade Management 11.2" (heretter UT) og "Enterprise Accounting 3.0.43" (heretter kalt BP) konfigurasjonene. Utvekslingen er enveis, fra UT til BP. Før du oppgraderte Trade Management 11.1 til 11.2, ble datautveksling konfigurert ved hjelp av Data Conversion 2.0-konfigurasjonen. Etter å ha byttet til "11.2", dukket det imidlertid opp feil i "Trade Management" for brukere. Prosedyren for å oppdatere utvekslingsreglene ble utført, men den ga ingen resultater. Debuggeren viste at problemet var i datautveksling. Det ble besluttet å fjerne datautvekslingsinnstillingen i begge konfigurasjonene og konfigurere den på nytt.

Både "Trade Management" og "Enterprise Accounting" fungerer i en klient-serverversjon. Jeg begynte å sette opp synkronisering med UT. Jeg utførte det på en slik måte at dataene ble lastet opp fra UT til en fil. Det vil si synkronisering gjennom en nettverkskatalog. I BP konfigurerte jeg sentralen på en slik måte at ingen data lastes ned fra BP.

Feil ved oppkalling av kontekstmetode (Bekreft): XDTO-datavalideringsfeil:
Strukturen til objektet "/Motpartsbankkonto/Bank" samsvarer ikke med typen: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)KeyPropertiesBank
Sjekke "BIK"-egenskapen:
form: Element
navn: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)BIK
type:
Nødvendig eiendom mangler
Objekt: Avtale med motpart nr. ...

For å analysere feilen, klikket jeg på ikonet "Sammensetning av sendte data" og i listen over entreprenøravtaler registrert for sending fant jeg avtalen som feilen dukket opp for. Jeg åpnet avtalen og husket motpartens bankkonto spesifisert i avtalen. Så gikk jeg videre til bankkontoene registrert for frakt. Det viste seg at den nødvendige kontoen ikke var på listen over registrerte. Jeg gjorde om den problematiske bankkontoen og kontrakten. Etter det registrerte jeg den nødvendige bankkontoen manuelt.

Jeg prøvde igjen å synkronisere data fra UT. Denne gangen ble dataene lastet opp. En XML-fil ble generert i nettverksmappen som inneholder data som skal overføres fra UT til BP.

Det neste trinnet er å laste inn dataene fra filen til bedriftens regnskapsavdeling. I «Enterprise Accounting»-konfigurasjonen klikket jeg på «Synkroniser»-knappen, et behandlingsskjema åpnet med meldingen «Dataanalyse pågår». Litt senere ble meldingen endret til "Dataopplasting pågår." Samtidig viste indikatoren og telleren at mer enn 80 tusen gjenstander ble losset fra strømforsyningsenheten. Dette forvirret meg, fordi jeg indikerte i innstillingene at ingenting skulle avlastes fra strømforsyningen. Behandlingen tok ganske lang tid og endte med feilen:

Hendelse: Datautveksling
(GeneralModule.Long-runningOperations.Module(371)): Arbeiderprosess i bakgrunnen ble avsluttet unormalt
RaiseException(Feiltekst);

For å lokalisere feilen prøvde jeg å endre synkroniseringsinnstillingene og driftsalternativene til strømforsyningsbasen. Som et resultat, da jeg konverterte databasen til en filversjon, fungerte systemet tilstrekkelig: et skjema for å sammenligne to databaser åpnet. Etter å ha matchet objektene, var den første synkroniseringen vellykket. Så byttet jeg databasen tilbake til klient-serverversjonen.

Med videre testing av synkronisering var det nødvendig å gjøre noen endringer i reglene for konvertering av objekter. Det er på tide å bruke Data Conversion 3.0-konfigurasjonen. Den innebygde konfigurasjonshjelpen beskriver hvordan den fungerer. Artikler på ITS-nettstedet hjalp også.

Som et resultat lastet jeg følgende data inn i "Data Conversion 3.0":

• Tekster fra den generelle modulen "Data Exchange Manager Through a Universal Format" fra to databaser
• Layout av begge baser
• Beskrivelse av EnterpriseData-formatet (fra en database)
• Konverteringsregler

Etter nedlasting åpnet jeg reglene for konvertering av data, objekter og egenskaper i "Data Conversion 3.0". Gjorde de endringene jeg trengte. Deretter brukte jeg knappen "Last av utvekslingsadministratormodul". Modulteksten er kopiert til utklippstavlen. Alt som gjenstår er å sette den inn i konfigurasjonen.

Etter å ha eksperimentert med å sette opp reglene i "Datakonvertering 3.0", konkluderte jeg for meg selv at i tilfelle endringene som gjøres er ubetydelige, er det lettere å sette opp reglene direkte i UT- og BP-konfigurasjonene, i den generelle modulen "Data Exchange Manager gjennom Universal Format". Hvis endringene er seriøse, som for eksempel å legge til et nytt objekt til børsen, bør du bruke konfigurasjonen " Datakonvertering 3.0".

Jeg utførte oppgaven med å legge til dokumentet "Ordre til leverandør" i bytteplanen ved hjelp av " Datakonvertering 3.0". I standardversjonen av UT - BP er dette dokumentet ikke inkludert i utvekslingsplanen.

La oss huske at reglene for registrering av objekter for opplasting fortsatt er konfigurert i "Data Conversion 2.0"-konfigurasjonen.

Dette er de første inntrykkene av datasynkronisering gjennom det universelle EnterpriseData-formatet.

P.S. Hvis du har spørsmål eller dine egne observasjoner om datautveksling via Universal Format and Configurations" Datakonvertering 3.0", skriv i kommentarfeltet. Vi vil utveksle erfaringer.

• Datasynkronisering
• Universal EnterpriseData Format
• Datakonvertering 3.0
• Datakonvertering 2.0
• Handelsledelse
• Bedriftsregnskap

Skriv ut (Ctrl+P)

Utveksling via et universelt format

"Data Exchange" undersystemet til biblioteket av standard undersystemer inneholder 4 alternativer (teknologier) for informasjonsutveksling mellom ulike informasjonsbaser:

• distribuerte informasjonsbaser (RIB);
• datautveksling gjennom et universelt format;
• datautveksling i henhold til utvekslingsregler (utvekslingsregler opprettes ved å bruke "Datakonvertering"-konfigurasjonen, utgave 2.1);
• datautveksling uten utvekslingsregler.

Denne artikkelen diskuterer teknologien for datautveksling gjennom universelt EnterpriseData-format. Denne teknologien er tilgjengelig i "Standard Subsystems Library" fra og med versjon 2.3.1.62. utgitt tidlig i 2016. For øyeblikket har den siste utgaven av BSP 2.3 (for bruk med 1C:Enterprise 8.3-plattformen ikke lavere enn versjon 8.3.8.1652 med kompatibilitetsmodus deaktivert) utgivelse 2.3.6.17.

Ris. 1 Siste utgivelser av BSP 2.3

Blant filene for å levere 1C-applikasjonsløsninger er det en tekstfil "Biblioteksversjoner", der det er skrevet på grunnlag av hvilken versjon av BSP applikasjonen ble utviklet, for eksempel basert på applikasjonsløsningen UT 11.3.3.231, BSP 2.3.5.65 ble dannet.

Vær oppmerksom på at for bruk med "1C:Enterprise 8.3"-plattformversjonen ikke lavere 8.3.10.2168 utgaven ble utgitt med kompatibilitetsmodus deaktivert BSP 2.4.

Beskrivelse av EnterpriseData-formatet

Hva er EnterpriseData-formatet?

Dette er et format som lar deg beskrive et informasjonsbaseobjekt (motpart, faktura osv.) eller rapportere at dette objektet er slettet. Det forventes at konfigurasjonen som mottar filen i EnterpriseData-formatet vil reagere deretter – den vil lage nye objekter og slette de som er merket som slettet i filen. Den er beregnet for informasjonsutveksling mellom UT, RT, UNF, BP konfigurasjoner. Formatet kan også brukes til å utveksle informasjon med andre informasjonssystemer: det er ikke avhengig av funksjonene til egen programvare eller informasjonsbasestrukturer som deltar i utvekslingen og inneholder ikke åpenbare begrensninger for bruk.

EnterpriseData-formatversjon

Formatdataene lagres i XDTO-pakker i de generelle databasekonfigurasjonsgrenene, som vist i fig. 2

Fig. 2 XDTO – EnterpriseData-dataformatpakker

I fig. 2 viser at det er flere XDTO-pakker. Dette er forskjellige versjoner av formatet. Formatets versjonsnummer består av X.Y.Z, der X.Y er versjonen, Z er Minor-versjonen. Minor-versjonen økes i tilfelle feilrettinger og andre endringer der: funksjonaliteten til datakonverteringslogikken basert på den forrige versjonen av formatet opprettholdes (vedlikeholde bakoverkompatibiliteten til gjeldende dataoverføringsalgoritmer gjennom formatet); Støtte for nye formatfunksjoner for konverteringslogikk er frivillig. Et eksempel på slike endringer kan være å rette en feil, endre egenskapene til formatobjekter, legge til egenskaper hvis bruk ikke er obligatorisk ved konvertering av data. I andre tilfeller, når formatet endres, øker Major-versjonen: X – ved global restrukturering, Y – i andre tilfeller.
Formatet beskriver representasjonen av objekter (dokumenter eller katalogelementer) i form av XML-filer. Versjon 1.0.1 inneholder en beskrivelse av 94 objekter fra ulike områder (økonomi, produksjon, innkjøp og salg, lagerdrift). Navnene på typene er som regel godt forstått og trenger ikke ytterligere forklaringer: for eksempel "Document.Act of Completed Work" eller "Directory.Counterparties". Som du kan se, begynner beskrivelsen av dokumenttyper med prefikset "Dokumentær.", og katalogelementet begynner med prefikset "Katalog.". En mer detaljert beskrivelse av formatet finner du
Den siste versjonen er 1.3, men den mest brukte versjonen er 1.0. Det er ikke mye forskjell mellom versjonene. Format EnterpriseDataExchange_1_0_1_1 brukes ved utveksling via en nettjeneste.
Noter det som EnterpriseData-dataformatpakken brukes sammen med ExchangeMessage når du oppretter konverteringsregler. Det er denne pakken som inneholder typeobjektet Tilleggsinformasjonsom kan ha hvilken som helst verditype og brukes når du oppretter en konverteringsregel mellom konfigurasjonsobjekter. som ikke er i dataformatet. Akkurat, takk TilleggsinformasjonDu kan tilpasse og tilpasse utvekslingsregler uten å endre formatdataene i XDTO-pakker.

Ris. 3 Strukturen til XDTO-pakkenExchangeMessage

Hvordan utveksle data i EnterpriseData-format?

Utveksling av data i EnterpriseData-format med konfigurasjon er en filutveksling. Som svar på filen mottatt fra den eksterne applikasjonen, vil konfigurasjonen behandle den og opprette en svarfil. Filer kan utveksles:

• via en dedikert filkatalog,
• via FTP-katalogen,
• gjennom en nettjeneste distribuert på infobasesiden. Datafilen sendes som en parameter til webmetoder.

Merk. For toveis datautveksling mellom en tredjepartsapplikasjon og konfigurasjonen på infobasesiden må det gjøres en rekke innstillinger - tredjepartsapplikasjonen må registreres i infobasen, det må defineres en utvekslingskanal for den (via en fil eller FTP-katalog), etc. Men for tilfeller av enkel integrasjon, når det er nok å bare overføre informasjon fra en tredjepartsapplikasjon til infobasen og omvendt overføring av data fra infobasen til en tredjepartsapplikasjon er ikke nødvendig (for eksempel integrasjon av en nettbutikk som overfører salgsinformasjon til 1C: Regnskap), finnes det en forenklet versjon av å jobbe gjennom en webtjeneste som ikke krever innstillinger på siden.

Ved utveksling ved hjelp av konfigurasjonsutvekslingsplaner under synkronisering, overføres kun informasjon om endringer som har skjedd siden siste synkronisering (for å minimere mengden informasjon som overføres). Første gang du synkroniserer, vil konfigurasjonen dumpe alle EnterpriseData-formaterte objekter inn i en XML-fil (siden de alle er "nye" for tredjepartsapplikasjonen).

Det neste trinnet er for tredjepartsapplikasjonen - den må behandle informasjonen fra XML-filen og plassere den i seksjonen under neste synkroniseringsøkt informasjon om at en melding fra konfigurasjonen med et bestemt nummer ble mottatt (plasser nummeret på meldingen mottatt fra konfigurasjonen i MottattNr-feltet). Kvitteringsmeldingen er et signal til konfigurasjonen om at alle objekter har blitt behandlet av den eksterne applikasjonen og at det ikke lenger er behov for å overføre informasjon om dem. I tillegg til kvitteringen kan XML-filen fra en tredjepartsapplikasjon også inneholde data for synkronisering (i seksjonen ).

Etter å ha mottatt kvitteringsmeldingen, merker konfigurasjonen alle endringer som ble sendt i forrige melding som vellykket synkronisert. Kun usynkroniserte endringer av objekter (opprette nye, endre og slette eksisterende) vil bli sendt til den eksterne applikasjonen under neste synkroniseringsøkt.

Når data overføres fra en ekstern applikasjon til konfigurasjonen, blir bildet reversert. Søknaden må fylle ut seksjonen tilsvarende, og i avsnittet plassere objekter som skal synkroniseres i EnterpriseData-format.

Etter å ha behandlet filen vil konfigurasjonen generere en XML-fil som vil inneholde en kvitteringsmelding og nye data for synkronisering fra konfigurasjonssiden (hvis det er noen siden siste synkroniseringsøkt).

Du kan se flere detaljer om datautveksling med applikasjonsløsninger på 1C:Enterprise-plattformen i EnterpriseData-formatet

Generell modul for "børsansvarlig gjennom et universelt format".

Prosedyrer og funksjoner som fullt ut beskriver reglene for nedlasting av data fra informasjonsbasen til utvekslingsformatet og reglene for innlasting av data fra utvekslingsformatet inn i informasjonsbasen, utvikles i en felles modul – sentralledermodulen gjennom et universelt format.

Ris. 4 Struktur av utvekslingsledermodulen gjennom et universelt format

Modulen opprettes automatisk ved hjelp av "Data Conversion"-konfigurasjonen, utgave 3.0, basert på konfigurerte utvekslingsregler, eller manuelt i konfiguratoren.

Modulen består av flere store seksjoner som hver inneholder sin egen gruppe av prosedyrer og funksjoner.

1. En kommentar. Den første linjen i modulen inneholder en kommentar med navnet på konverteringen. Denne linjen er nødvendig for å identifisere modulen når du bruker kommandoen i Data Conversion-programmet, utgave 3.0, for eksempel. // Konvertering UP2.2.3 fra 06/01/2017 19:51:50
2. Konverteringsprosedyrer. Inneholder forhåndsdefinerte prosedyrer som utføres på forskjellige stadier av datasynkronisering: før konvertering, etter konvertering, før utsatt fylling.
3. Databehandlingsregler (DPR). Inneholder prosedyrer og funksjoner som beskriver reglene for behandling av data.
4. Regler for objektkonvertering (OCR). Inneholder prosedyrer og funksjoner som beskriver reglene for konvertering av objekter, samt reglene for konvertering av egenskaper til disse objektene.
5. Forhåndsdefinerte regler for datakonvertering (PDC). Inneholder en prosedyre som fyller ut reglene for konvertering av forhåndsdefinerte data.
6. Algoritmer. Inneholder vilkårlige algoritmer som kalles fra andre regler (POD eller PKO).
7. Alternativer. Inneholder logikken for å fylle ut konverteringsparametrene.
8. Generelt formål. Inneholder prosedyrer og funksjoner som er mye brukt i regler og algoritmer.

Parametrene til prosedyrer og funksjoner som brukes i flere typer prosedyrer i ledermodulen er beskrevet nedenfor.

Bytt komponenter. Type - Struktur. Inneholder parametere og utvekslingsregler initialisert som en del av utvekslingsøkten.

Retning av utveksling. Type – String. Enten "Send" eller "Motta".

IB data. Type – DirectoryObject eller DocumentObject.

Prosedyrer knyttet til konverteringshendelser

Det er tre forhåndsdefinerte prosedyrer som kalles under konverteringsprosessen:

• Før konvertering. Ringes før datasynkronisering skjer. Denne prosedyren inneholder vanligvis logikken for initialisering av ulike konverteringsparametere, fylling av standardverdier osv. Parametre: Komponentutveksling.
• Etterkonvertering. Kalt opp etter at datasynkronisering er fullført, men før lat polstring har skjedd. Alternativer: Komponentutveksling.
• Før Forsinket Fylling. Ringes før lat fylling skjer. Logikken for sortering eller justering av tabellen over gjenstander som er utsatt for lat fylling kan lokaliseres her. Alternativer: Komponentutveksling.

AML-prosedyrer

Fyll ut databehandlingsreglene. En eksportprosedyre som inneholder logikken for å fylle ut databehandlingsregler. Inneholder kall til andre prosedyrer som legger til en regel for behandling av et spesifikt objekt i regeltabellen (se prosedyrer nedenfor Legg til AML). Alternativer: Retning av utveksling, Regler for databehandling

Legg til UNDER_<ИмяПОД>. Et sett med prosedyrer som fyller ut tabellen UNDER reglene for spesifikke objekter. Antall slike prosedyrer tilsvarer antallet AML som er gitt for denne konverteringen i Data Conversion-programmet, utgave 3.0. Alternativer: Regler for databehandling(en tabell med verdier initialisert som en del av utvekslingsøkten).

UNDER_<ИмяПОД>_Ved behandling. Prosedyren inneholder behandlerteksten Under behandlingen for en spesifikk AML. Behandleren er designet for å implementere konverteringslogikk på objektnivå. For eksempel, tilordne en spesifikk PQO til et bestemt objekt avhengig av innholdet i objektet. Alternativer:

• InformasjonB-data eller DataXDTO(avhengig av utvekslingsretningen):
• når du sender – objekt ( DirectoryObject,DocumentObject);
• ved mottak - en struktur med en beskrivelse av XDTO-objektet.
• Bruk av PKO. Type - Struktur. Nøkkelen inneholder en streng med navnet på PCO, og verdien av typen boolsk (ekte– PKO brukes, Å ligge– PKO brukes ikke).
• Komponentutveksling.

UNDER_<ИмяПОД>_Sampling av data. Funksjonen inneholder behandlerteksten Ved lossing. Behandleren er designet for å implementere en vilkårlig algoritme for å velge objekter som skal losses. Returverdi: en rekke objekter som skal losses. Matrisen kan inneholde både lenker til infobaseobjekter og en struktur med data for opplasting. Alternativer: Komponentutveksling.

PKO-prosedyrer

Fyll ut reglene for objektkonvertering. En eksportprosedyre som inneholder logikken for å fylle ut reglene for konvertering av objekter. Inneholder kall til andre prosedyrer som legger til en spesifikk objektkonverteringsregel til regeltabellen (se prosedyrer nedenfor Legg til PKO). Alternativer: Retning av utveksling, Konverteringsregler(en tabell med verdier initialisert som en del av utvekslingsøkten).

AddPKO_<ИмяПКО>. Et sett med prosedyrer som fyller PKO-tabellen med regler for spesifikke objekter. Antallet slike prosedyrer tilsvarer antallet PKOer som er gitt for denne konverteringen i datakonverteringsprogrammet, versjon 3.0. Alternativer: Konverteringsregler(en tabell med verdier initialisert som en del av utvekslingsøkten).

PKO_<ИмяПКО>_WhenSendingData. Prosedyren inneholder behandlerteksten Ved sending for en spesifikk PKO. Behandleren brukes ved opplasting av data. Designet for å implementere logikken for å konvertere data i et infobaseobjekt til en beskrivelse av et XDTO-objekt. Alternativer:

• InformasjonB-data. Type - DirectoryObject, DocumentObject. Informasjonsbaseobjektet som behandles.
• DataXDTO. Type - Struktur. Designet for å få tilgang til XDTO-objektdata.
• Komponentutveksling.
• StackUploads. Type - Array. Inneholder lenker til ulastede objekter, med hensyn til hekking.

PKO_<ИмяПКО>_Ved konvertering av XDTO-data. Prosedyren inneholder behandlerteksten Ved konvertering av DataXDTO for en spesifikk PKO. Behandleren brukes ved lasting av data. Designet for å implementere vilkårlig XDTO-datakonverteringslogikk. Alternativer:

• DataXDTO. Type - Struktur. XDTO-objektegenskaper som er forhåndsbehandlet for å gjøre dem lettere tilgjengelige.
• Mottatt data. Type - DirectoryObject, DocumentObject. Et infobaseobjekt dannet ved å konvertere XDTO-data. Ikke registrert i informasjonsdatabasen.
• Komponentutveksling.

PKO_<ИмяПКО>_Før registrering av mottatte data. Prosedyren inneholder behandlerteksten Før du registrerer de mottatte dataene for en spesifikk PKO. Behandleren brukes ved lasting av data. Designet for å implementere ytterligere logikk som må utføres før du registrerer et objekt i infobasen. Skal endringer for eksempel lastes inn i eksisterende informasjonssikkerhetsdata eller skal de lastes inn som nye data. Alternativer:

• Mottatt data. Type - DirectoryObject, DocumentObject. Et dataelement generert ved å konvertere XDTO-data.

Registreres hvis disse dataene er nye for infobasen (parameter InformasjonB-data inneholder verdien Udefinert).

Ellers Mottatt data erstatte InformasjonB-data(alle eiendommer fra Mottatt data overført til InformasjonB-data).

Hvis standard erstatning av informasjonssikkerhetsdata med mottatte data ikke er nødvendig, bør du skrive din egen overføringslogikk, og deretter angi parameteren Mottatt data betydning Udefinert:

• InformasjonB-data. Type - DirectoryObject, DocumentObject. Et infobasedataelement som tilsvarer de mottatte dataene. Hvis ingen samsvarende data er funnet, inneholder Udefinert.
• Konvertering av egenskaper. Type - Tabell over verdier. Inneholder regler for konvertering av egenskapene til det gjeldende objektet, initialisert som en del av utvekslingsøkten.
• Komponentutveksling.

PCPD-prosedyrer

Fyll ut konverteringsreglene for forhåndsdefinerte data. En eksportprosedyre som inneholder logikken for å fylle ut reglene for konvertering av forhåndsdefinerte data. Alternativer: Retning av utveksling, Konverteringsregler(en tabell med verdier initialisert som en del av utvekslingsøkten).

Algoritmer

I «Data Conversion»-programmet, utgave 3.0, er det mulig å lage vilkårlige algoritmer som kalles opp fra AML- og PKPD-behandlerne. Navn, parametere og innhold av algoritmene bestemmes når reglene utvikles.

Alternativer

Fyll inn ConversionParameters. En eksportprosedyre der strukturen med konverteringsparametere fylles ut. Alternativer: Konverteringsalternativer(skriv - Struktur).

Generelle prosedyrer og funksjoner

ExecuteManagerModuleProcedure. Alternativer: Prosedyrenavn(linje), Alternativer(struktur). En eksportprosedyre, som er ment å kalle en ikke-eksportmodulprosedyre, hvis navn og parametere mottas som input. Lar deg kalle en prosedyre eller funksjon på en linje uten å bruke en metode Henrette.

ExecuteManagerModuleFunction. Alternativer: Prosedyrenavn(linje), Alternativer(struktur). Funksjon, formål lignende ExecuteManagerModuleProcedure. Forskjellen er at den kaller en funksjon og returnerer verdien.

La oss se på et enkelt eksempel fra det virkelige liv. La oss si at vi har en bedrift som driver med engros- og detaljhandel, og i denne bedriften, som i alle andre, drives det regnskap. Foretaket har to standarddatabaser, disse er henholdsvis UT (handelsstyring) og BP (foretakets regnskap), i hver av databasene føres egne journaler, i UT er det ledelse for å reflektere alle transaksjoner knyttet til handel, i BP det er regnskap. For ikke å gjøre dobbeltarbeid, dvs. ikke opprett de samme dokumentene i to databaser (tross alt bør bevegelser være i administrasjon og regnskap) vi vil bare sette opp synkronisering mellom disse databasene.

Vi vil sette opp datautveksling enveis, fra UT ---> BP. Det er også mulig å sette opp en toveis utveksling, men i praksis er dette ikke ofte nødvendig, så vi vil ikke vurdere det i vårt eksempel.

Forberedende trinn for å sette opp utveksling i BP

La oss begynne å sette opp synkronisering, gå først til 1C "Enterprise Accounting 3.0"-databasen (mottaker), vi må sjekke om synkronisering er aktivert for denne databasen, for å gjøre dette må vi først gå til databasen. Så snart databasen åpnes, gå til fanen "Administrasjon" ---> "Innstillinger for datasynkronisering"

En ny fane åpnes foran oss, den må fylles ut på samme måte som i skjermbildet nedenfor, med unntak av informasjonsbaseprefikset. Prefikset må bestå av to bokstaver, du kan angi hvilken som helst, men i henhold til 1C-standarden er det bedre å sette prefikset med navnet på konfigurasjonen, det vil si at for "Enterprise Accounting" vil prefikset være "BP". Hvis du setter opp komplekse utvekslinger og det er flere regnskapsdatabaser, bør prefiksene tydelig skille seg fra hverandre; her kan du bruke de to første bokstavene i organisasjonens navn som en forkortelse.

Vi fortsetter å sette opp datasynkronisering i UT

Etter at vi har gjort alle nødvendige handlinger i mottakerdatabasen (BP 3.0), for å fortsette å sette opp datautveksling må vi åpne kildedatabasen (UT 11.1). Gå til fanen "Administrasjon", velg "Innstillinger for datasynkronisering" i menyen til venstre. Hvis synkronisering ikke er aktivert, aktiver den ved å bruke avmerkingsboksen, og ikke glem å spesifisere kildebaseprefikset. Når vi har fullført alle trinn 1-4 som vist i bildet nedenfor, må du klikke på hyperkoblingen "Datasynkronisering" (trinn 5).

I det nye vinduet som vises, må du klikke på det grønne plusstegnet (Sett opp datasynkronisering), i rullegardinmenyen velger du elementet "Enterprise Accounting 3.0".

Sette opp viktige punkter i datautveksling mellom UT og BP

Nå ser vi et vindu med innstillinger for datasynkronisering i 1C, velg "Spesifiser innstillinger manuelt" og klikk "Neste".

Vi fortsetter å sette opp datautveksling i 1C, på neste fane må vi velge alternativet for å koble til mottakerens infobase (direkte tilkobling til programmet), tilkoblingsparametere (på denne datamaskinen eller på det lokale nettverket), katalogen der mottakerbasen er lokalisert, samt nødvendige autentiseringsdata (brukernavn og passord i databasen).

På neste side må vi fylle ut reglene for sending og mottak av data fra BP 3.0 (mottaker) konfigurasjonen. Klikk på «endre regler for dataopplasting».

Vinduet "Regler for sending av data" har åpnet seg foran oss, i det setter vi følgende parametere:

• Hvilke referansedata vil bli sendt (i vårt eksempel er vi bare interessert i dokumenter og referansedataene som brukes i dem, så vi valgte det riktige elementet; hvis du velger det første elementet "Send alle", vil alle referansebøker lastes inn på nytt sammen med dokumentene, ofte hvis informasjonen ikke brukes i dokumentene, er den ubrukelig for mottakeren, fordi den ikke påvirker regnskapet på noen måte)
• Fra hvilken dato skal all informasjon sendes (vi vil ikke vurdere manuell synkronisering i denne artikkelen)
• Til hvilken eller hvilke organisasjoner som skal sendes data (i vårt eksempel valgte vi én organisasjon, IP "Entreprenør")
• Regler for inngåelse av kontrakter
• Generalisert lager
• Bør jeg rulle opp dokumenter etter lager?

Etter at vi har gjort innstillingene, klikk "Lagre og lukk".

Siden vi i vårt eksempel setter opp og bruker enveis utveksling, fra UT til BP, så er ikke innstillingene for reglene for innhenting av data fra "Enterprise Accounting 3.0" av interesse for oss, så vi klikker på "Neste".

I et nytt vindu blir vi bedt om å konfigurere regler for mottakerbasen (RB). I punkt 1 navngir vi databasen vår, gir den et prefiks. PREFIX må være det samme som vi satte det i selve BP-databasen i begynnelsen av denne artikkelen; hvis prefiksene er forskjellige, vil ikke datasynkronisering i 1C-programmet fungere. Klikk deretter på punkt 2 og deretter punkt 3.

I punkt 3 må vi tillate at dokumenter behandles når de lastes inn i databasen. Klikk "Lagre og lukk".

Nå skal vinduet se omtrent ut som det som vises nedenfor, klikk på "Neste".

Dette vinduet inneholder referanseinformasjon om synkroniseringen som opprettes i 1C. Bare klikk på "Neste"-knappen. Hvis programmet genererte en feil ved oppsett av datasynkronisering, må du kontakte oss slik at vår 1C-spesialist kan hjelpe deg akkurat nå!

Neste steg programmet vil tilby å synkronisere umiddelbart etter å ha opprettet datautvekslingsinnstillingene. La oss godta dette og klikk "Ferdig".

Et vindu vil dukke opp foran deg hvor du vil se informasjon om hvordan synkroniseringen foregår. Hvis mottakerbasen ikke er tom, dvs. Det er allerede lagret opptegnelser i den, så vil brukeren i 1C-programmet bli bedt om å foreta en sammenligning av objekter manuelt. Sammenligning av objekter i 1C ved synkronisering av data er en sammenligning av identiske objekter til mottakeren med identiske objekter i kilden.

La oss se på et eksempel, la oss si at det i UT er en motpart med navnet "PharmGroup LLC" og TIN 1234567, og i BP er det også en motpart med TIN 1234567, men navnet "PharmGroup", hvis vi ikke sammenligner disse to objekter ved sammenligning av data på synkroniseringsstadiet, så vil vi etter synkronisering i mottakeren (Enterprise Accounting 3.0), ha to motparter med TIN 1234567 og to navn henholdsvis "PharmGroup LLC" og "PharmGroup". For å unngå slike situasjoner ble en mekanisme for å sammenligne objekter oppfunnet.

I vårt eksempel er mottakerdatabasen tom, og derfor åpnet ikke objektsammenligningsvinduet. Men etter å ha utført noen operasjoner, vil systemet definitivt be brukeren om å legge til noen ekstra data og vise følgende vindu. Vi trenger ikke å overføre ytterligere data, vi har allerede konfigurert alt vi trenger tidligere, så på dette trinnet velger vi "Ikke legg til dokumenter for å sende." Klikk "Neste".

Det siste stadiet av datautveksling mellom 1C

På det siste stadiet vil programmet vise følgende vindu, der brukeren vil bli informert om at synkroniseringen var vellykket, klikk "Fullfør". På dette tidspunktet er synkronisering mellom databaser i en enveis utveksling fra "Trade Management 11.1" (UT) til "Enterprise Accounting 3.0" (BP) fullført.