Lisenspolicy 1C gir muligheten til å gjøre og lagre endringer i standardkonfigurasjoner, og følgelig muligheten til å oppdatere dem.*

*Modifiserte eller ikke-standardiserte konfigurasjoner 1C er et programvareprodukt på 1C:Enterprise-plattformen, som er en del av eller utgjør hele automatisert system bedriftsledelse, som har gjennomgått en rekke endringer på grunn av behovene og spesifikasjonene til virksomheten, når det gjelder former og sammensetning av kataloger, dokumenter, roller, moduler osv., derfor er det ikke i det hele tatt å oppdatere 1C-konfigurasjonen med endringer det samme som å oppdatere en standardløsning.

Oppdateringer utgitt av 1C er rettet mot å fikse feil og introdusere endringer og tillegg som kreves av loven. Nye konfigurasjoner som nylig har kommet på markedet er preget av utgivelsen av et stort antall oppdateringer av den første typen. For konfigurasjoner med funksjonalitet rettet hovedsakelig mot å kompilere regulatorisk rapportering, for eksempel "1C: ZUP", "1C: Regnskap", utgis flere oppdateringer av den andre typen.

Spesifisiteten ved å oppdatere ikke-standard konfigurasjoner er behovet for å gjøre alle endringer i den siste 1C-utgivelsen, samtidig som tidligere utførte forbedringer opprettholdes fullt ut. Dette er en ikke-triviell oppgave, hvis løsning ikke har et standardskript, noe som betyr at den ikke kan automatiseres fullstendig. Av denne grunn råder manuelle operasjoner som krever deltakelse fra en spesialist i metodikken for oppdatering av ikke-standardiserte konfigurasjoner.

Implementeringsstadiene for oppdatering av ikke-standard konfigurasjoner påvirkes ikke av mengden eksisterende forbedringer. De kan kort beskrives som følger:

• Søk og sammenligning av endrede objekter;
• Lage oppdateringer fra en ny utgivelse;
• Introduserer tidligere gjort endringer som ble "overskrevet" på forrige stadium;
• Sjekke kompatibilitet og drift av prosesser.

Forskjellen vil ligge i implementeringstiden: hvis det er mange forbedringer, vil prosessen tilsvarende ta lengre tid og kreve konsentrasjon, oppmerksomhet og manuell kontroll.

La oss vurdere å oppdatere en ikke-standard konfigurasjon for 1C-miljøet ved å bruke eksempelet "1C: Trade Management" (utgivelse 2014) til neste tilgjengelige utgivelse.

Dette er et veldig enkelt eksempel, men som nevnt ovenfor, vil oppdatering av en mer kompleks konfigurasjon selvfølgelig kreve mye tid og konsentrasjon fra en spesialist, men vil ha de samme stadiene - oppdatering (til en ny standardkonfigurasjon) ), arbeider med avstemming av innlagte og foretatte endringer mv.

Før du oppdaterer konfigurasjonen, bør du laste ned informasjonsgrunnlag. Denne handlingen anbefales å utføres før noen manipulasjoner med alle databaser uten unntak, og spesielt med ikke-standardiserte:

Opplasting av infobasen er fullført:

Vær oppmerksom på at hvis konfigurasjonen ikke var ferdigstilt, det vil si at den var standard, vil et låsikon også vises i konfigurasjonsvinduet ved siden av navnet, ved siden av den gule kuben:

I konfigurasjonsmenyen velger du "Support" og "Update configuration". Faktisk, på dette stadiet, faller handlingene helt sammen med prosessen med å oppdatere en standardkonfigurasjon:

Avhengig av størrelsen på basen og dens modifikasjoner, automatisk søk tilgjengelige oppdateringer kan ta litt tid. Derfor er det verdt, til tross for anbefalingene, å velge alternativet "Velg oppdateringsfil" og uavhengig, etter å ha pakket ut arkivet med oppdateringer og lagret dem, spesifisere banen manuelt:

Vindu med bakgrunnsinformasjon, instruksjoner og rekkefølge av oppdateringer:

Konfigurasjonssammenligningsvindu. Til venstre i treet vises statusen til den eksisterende konfigurasjonen, til høyre – informasjon om den nye standardversjonen. Seksjoner som har gjennomgått endringer er også uthevet. Deretter må vi finne ut hvilke seksjoner som ble endret fra vår side og som samtidig gjennomgikk endringer i den nye konfigurasjonen:

For å finne ut hvilke typiske metadataobjekter som har blitt endret tidligere og også vil bli endret ved installasjon av en ny leverandørkonfigurasjon, må du velge «Vis kun to ganger endrede egenskaper»:

Bare gjenstander som oppfyller denne betingelsen gjenstår:

Ved å utvide metadatatreet kan du se hvilke spesifikke objekter som vil bli endret. For å få detaljert informasjon, høyreklikk for å velge det endrede objektet:

Du kan evaluere endringer på kodenivå ved å bruke "Vis forskjeller i moduler", men siden de også må huskes for å kunne gjøres etter installasjon av oppdateringer, lager vi to rapporter: "Rapport om sammenligning av hovedkonfigurasjonsobjekter med den gamle leverandøren konfigurasjon" (tilgjengelige forbedringer) og "Sammenligningsrapport for ny leverandørkonfigurasjonsobjekt med gamle leverandørkonfigurasjonsobjekter" (oppdateringer).*

*La oss forstå terminologien:

• "Hovedkonfigurasjon" - en ikke-standard konfigurasjon som må oppdateres;
• "Gamle leverandørkonfigurasjon" - typisk konfigurasjon som oppdateringer sist ble installert fra;
• "Ny leverandørkonfigurasjon" er den vi oppdaterer til nå.

Vi tilpasser rapportskjemaet og laster det opp. Listen over tidligere gjort endringer er registrert:

Etter å ha lastet ned rapportene, gå direkte til oppdateringen og klikk "Kjør". Konfiguratoren tilbyr oppdateringsregelen "Ta fra den nye leverandørkonfigurasjonen" (den er angitt i tredje kolonne). Dette betyr at alle modifikasjoner vil bli slettet og erstattet med standard oppdaterte objekter. Det er ikke verdt å endre denne regelen til den fristende "Merge Mode", fordi automatisk sammenslåing vil føre til kaos. Likevel er det bedre å ta seg tid og gjøre endringene manuelt:

I vinduet med generell informasjon om fjerning av konfigurasjonen fra støtte, trenger ingenting å endres. Ved å klikke "OK" vil objektene slås sammen. Deretter starter du "Enterprise" og registrerer endringene for å fullføre oppdateringsprosessen nøyaktig:

Vi godtar listen over endringer:*

*Hvis "Godta"-knappen er inaktiv, bør du kjøre "Fix Testing":



Vi starter feilsøking via F5 og mottar bekreftelse på lovligheten av oppdateringene:

Etter at du har mottatt bekreftelse på at prosessen med å rulle ut oppdateringer er fullstendig fullført, bør du gå tilbake til konfiguratoren, gå til de to ganger endrede metadataobjektene og manuelt gjøre de forpliktede endringene på kodenivå ved å bruke de nedlastede rapportene. Avslutningsvis legger vi til at etter dette er det nødvendig å kontrollere riktigheten av innstillingene og tilstrekkeligheten til arbeidsprosessene.

Dette er en ganske gammel artikkel av meg, men den er fortsatt relevant. Derfor bestemte jeg meg for at det ville være hensiktsmessig å publisere det på www..

Denne artikkelen beskriver ikke teknikker for bruk av automatiske og automatiserte konfigurasjonsoppdateringer ved hjelp av eksterne komponenter og/eller programvareprodukter. Du kan finne informasjon om dem på andre Internett-ressurser.

Du har kanskje lagt merke til at med hver oppdatering øker antallet objekter som krever din oppmerksomhet bare. Samtidig vet du med sikkerhet at for eksempel kun ett dokument er endret, og ved oppdatering gis det en liste med flere titalls endrede objekter. Selvfølgelig kan du bruke teknikken beskrevet i artikkelen min "Teknologi for oppdatering av ikke-standardiserte konfigurasjoner av 1C: Enterprise 7.7" datert 27. juni 2003. Ja, det vil fungere. Mange utfører oppdateringer på denne måten. Men jeg anser denne tilnærmingen som ineffektiv og tidkrevende når du oppdaterer konfigurasjoner på plattformen 1C:Enterprise 8. I motsetning til plattformen 1C:Enterprise 7.7 lar 1C:Enterprise 8-plattformen deg åpne flere konfigurasjoner samtidig (*.cf-filer) og utføre flere sammenligninger av konfigurasjoner i én kopikonfigurator. Det eneste unntaket er kanskje konfigurasjoner bygget på PPM (Manufacturing Enterprise Management) – de er for tunge, plattformen faller.

Prosessen med å oppdatere 1C:Enterprise 8-konfigurasjoner er mer automatisert sammenlignet med 1C:Enterprise 7.7. Et ganske høyt automatiseringsnivå kan redusere arbeidsintensiteten til arbeidet betydelig ved oppdatering av ikke-standardiserte konfigurasjoner. Dessverre kan oftest prosessen med å oppdatere ikke-standard konfigurasjoner ikke fullføres helt i automatisk modus og krever spesialistintervensjon.

Er det mulig at oppdateringsprosessen fullføres helt automatisk? Sikkert. For å gjøre dette må mutable objekter legges til og må ikke bruke funksjonaliteten til den eksisterende konfigurasjonen. De. disse objektene skal løse helt andre regnskapsproblemer som utvider funksjonaliteten typisk konfigurasjon leverandør. Enig i at situasjonen beskrevet er ekstremt sjelden. Endringer påvirker nesten alltid standard leverandørkonfigurasjonsobjekter.

Vær oppmerksom på at databasen kan inneholde opptil tre typer konfigurasjoner:

• databasekonfigurasjon - dette er konfigurasjonen som brukere arbeider med;
• fungerende konfigurasjon (hoved-) er en konfigurasjon som vi kan gjøre endringer i og brukere kan fortsette å jobbe med;
• leverandørkonfigurasjon er den opprinnelige leverandørkonfigurasjonen som fungerende konfigurasjon Og databasekonfigurasjon. En database kan ha flere konfigurasjoner fra forskjellige leverandører. Konfigurasjonsleverandøren kan ikke bare være 1C.

I tilfelle konfigurasjonen fjernes fra støtten, leverandørkonfigurasjon vil ikke bli. Noe som igjen øker kompleksiteten i oppdateringen betydelig.

La oss se på oppdateringsprosessen og analysere mulige feil ved å bruke eksemplet med oppdatering av UPP-konfigurasjonen (leverandøren av standardkonfigurasjonen er 1C-selskapet, modifikasjoner av Inform Service-selskapet). Opprinnelig ble denne konfigurasjonen oppdatert uten å bruke teknologien beskrevet i denne artikkelen, så feilene som er omtalt i denne artikkelen er de vanligste i praksis. Oppdateringen vil være fra versjon 1.2.6.2 til versjon 1.2.14.1.

Trinn 1. Forberedelse.

På den første fasen vil vi bringe i korrespondanse fungerende konfigurasjon Til leverandørkonfigurasjon. Dette er et veldig viktig stadium, som vil redusere mengden arbeid som kreves for å analysere endringene vi tidligere har gjort betydelig.

Du kan hoppe over dette trinnet hvis Siste oppdatering gått gjennom "støtte" (Meny "Konfigurasjon" → "Support" → "Oppdater konfigurasjon") eller ble utført i henhold til metoden beskrevet i denne artikkelen.

Versjonskonflikt fungerende konfigurasjon Og leverandørkonfigurasjon kan oppstå når du bruker *.cf-filer for oppdatering som ikke er fra leverandørens distribusjon, eller når du bruker oppdateringsmetoder som er forskjellige fra de som er beskrevet i denne artikkelen. For eksempel ble objekter lagt til arbeidskonfigurasjonen ved å kopiere via utklippstavlen eller Dra og slipp.

1. Sammenligning av versjoner.

La oss sjekke versjonsnumrene fungerende konfigurasjon Og leverandørkonfigurasjon. Antall fungerende konfigurasjon se i "Konfigurasjon"-menyen → "Åpne konfigurasjon"-menyen "Rediger" → "Egenskaper". I "Utvikling"-blokken velger du "Versjon". (Bilde 1).

Antall leverandørkonfigurasjon se i menyen "Konfigurasjon" → "Støtte" → "Støtteinnstillinger..." elementet "Versjon". (Figur 2).

Hvis tallene stemmer, gå videre til neste trinn. Cm..

I i dette eksemplet må bringes på linje fungerende konfigurasjon Og leverandørkonfigurasjon med støtte for gjenstander fjernet fra støtte eller lagt til uten støtte. For å gjøre dette, utfør følgende trinn:

2. Lagre den fungerende (hoved) konfigurasjonen.

La oss spare fungerende konfigurasjon til en fil, for eksempel work.cf. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Lagre konfigurasjon til fil...".

3. Skaff oppdateringsfilen for leverandørkonfigurasjonen.

For å matche konfigurasjonene trenger vi en *.cf-fil fra leverandørens distribusjon med samme versjonsnummer som fungerende konfigurasjon(Figur 3 og 4). Denne filen kan fås ved å installere riktig distribusjon. Som standard er konfigurasjonsdistribusjonen installert i katalogen C:/Program Files/1cv81/tmplts. For mer informasjon om installering av konfigurasjonsmaler, se dokumentasjonen.

La oss sjekke malkatalogen. Hvis det er en *.cf-fil med den nødvendige versjonen i malkatalogen, gå til .

Hva kan du gjøre hvis det ikke finnes noen *.cf-fil med den nødvendige versjonen? leverandørkonfigurasjon? I dette tilfellet kan du bruke *.cfu-filer og, gjenta prosedyren beskrevet i trinn 1 flere ganger, suksessivt øke versjonsnummeret til den nødvendige utgivelsen, i i dette tilfellet opp til 1.2.6.2. Det bør bemerkes at bruk av *.cfu-filer kanskje ikke fikser feil som ble gjort tidligere under oppdateringen. Hvilket, du skjønner, er ganske merkelig, gitt det faktum at først leverandørfilen kompileres basert på *.cfu-filen, og deretter blir oppdateringen utført. Dette kan skyldes at av en eller annen grunn ikke alle konfigurasjonsobjekter er inkludert i sammenligningen. Derfor foreslår jeg å bruke en muligens lengre vei, men også en mer pålitelig.

Du må opprette en tom database med "gammel" leverandørkonfigurasjon. Oppdater leverandørkonfigurasjon til den nødvendige versjonen og bruk den når du utfører arbeid på trinn 1. For å få "ny" leverandørkonfigurasjon du må gjøre følgende:

1. Opprette den "gamle" leverandørfilen for gjeldende konfigurasjon. 1cv8.cf-filen kan hentes fra leverandørens distribusjon eller lagres fra arbeidsdatabasen hvis konfigurasjonen er under støtte. For å lagre 1cv8.cf-filen fra arbeidsdatabasen, gå til "Konfigurasjon" → "Support" → "Støtteinnstillinger...", klikk på "Lagre til fil"-knappen og spesifiser katalogen og filnavnet. For eksempel på skrivebordet.
2. Opprett en database med den nye leverandørkonfigurasjonen. Databasen kan opprettes ved å bruke leverandørens distribusjon fra ITS-disken eller ved å bruke 1cv8.cf hentet tidligere fra skrivebordet. I det første tilfellet følger vi instruksjonene som følger med distribusjonssettet. I det andre tilfellet, for å lage en database fra en fil som ligger på skrivebordet, oppretter vi en ny infobase uten konfigurasjon og starter konfiguratoren. I menyen "Konfigurasjon" → "Last inn konfigurasjon fra fil..." spesifiserer vi filen som tidligere er lagret på skrivebordet. Vi åpner konfigurasjonen gjennom menyen "Konfigurasjon" → "Åpne konfigurasjon" og oppdaterer til ønsket utgivelse gjennom menyen "Konfigurasjon" → "Support" → "Oppdater konfigurasjon" ved hjelp av *.cfu-filer.
3. Opprett en "ny" leverandørkonfigurasjonsfil. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Lagre konfigurasjon til fil...". Vi spesifiserer plasseringen og navnet på filen 1cv8.cf. Klikk "Lagre".

4. Matche driftskonfigurasjonen og leverandørkonfigurasjonen gjennom en oppdatering.

Bruker den resulterende *.cf-filen leverandørkonfigurasjon La oss oppdatere. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Support" → "Oppdater konfigurasjon", "Velg oppdateringsfil", "Fullfør" (Figur 5), "Kjør" (Figur 6).

Løsninger:

• fjerne merking av et objekt som er i leverandørkonfigurasjonen;
• fjern referansen til objektet som er i leverandørkonfigurasjonen.

Basert på det faktum at koblingen i det tilføyde "Avdelingsleder"-grensesnittet er laget til objektet leverandørkonfigurasjon, hvis støtte er trukket tilbake av leverandøren (muligens på grunn av endring i regnskapsmetodikk), vil den riktige løsningen i denne situasjonen være å fjerne koblingen til denne rapporten fra grensesnittet "Avdelingsleder". Vi lukker ikke vinduet for konfigurasjonssammenligning; vi sletter lenken til rapporten "Betaling for bestillinger" i grensesnittet "Avdelingsleder". Etter å ha fjernet koblingen, vil vi sammenligne konfigurasjonene på nytt. For å gjøre dette, klikk på "Oppdater"-knappen i oppdateringsvinduet (Figur 6).

5. Gjenoppretting av innstillinger som ble delvis tapt i forrige trinn.

For å gjenopprette delvis tapte innstillinger, slå sammen med en tidligere lagret fil fungerende konfigurasjon arbeid.jf. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Sammenlign, slå sammen med konfigurasjon fra fil...".

6. Lagre oppdateringsresultatene.

La oss lagre endringene fungerende konfigurasjon og oppdater databasekonfigurasjon. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Oppdater databasekonfigurasjon".

Her venter et annet problem på oss (Figur 8).

For å løse dette problemet, la oss se på årsaken til dets forekomst. Det kan være flere årsaker, men de mest sannsynlige er følgende. Disse objektene er kopiert til fungerende konfigurasjon fra leverandørkonfigurasjon eller leverandøren har tidligere slettet disse objektene og senere lagt til nye med samme navn, men med ulike interne identifikatorer. Som et resultat vises objekter med forskjellige interne identifikatorer, men med samme navn, i konfigurasjonen.

Vi håndterer roller ganske enkelt - vi sletter dem, fordi rollene har ikke endret seg (dette kan verifiseres ved å sammenligne og fungerende konfigurasjon). Vi opptrer annerledes med dokumentdetaljer. Attributtet må gis nytt navn, for eksempel OrderReserve1, og etter oppdatering må verdiene fra det omdøpte attributtet overføres til det nye. For å gjøre dette kan du bruke behandlingen av UniversalSelectionAndProcessingObjects.epf fra ITS-disken.

La oss vurdere en annen situasjon som ligner på den forrige, men som oppsto under oppdateringen av 1C: Enterprise Accounting 8.1. Hva skal man gjøre med skjemaer? (Figur 9)

På bildet ser vi at ListForm ble fjernet fra leverandøren og deretter lagt til av leverandøren ny form med samme navn. Følgelig må du merke begge skjemaene for oppdatering og klikke på "Kjør" -knappen.

Hvis du får melding om at det er lenker til objekter som skal slettes, må du, uten å lukke oppdateringsskjemaet, slette koblingene til skjemaet som skal slettes i objektegenskapene. I dette tilfellet, i registeret egenskaper. Etter dette må du klikke på "Oppdater"-knappen i oppdateringsskjemaet, merke registeregenskapene for oppdatering og klikke på "Kjør"-knappen igjen.

La oss lagre endringene fungerende konfigurasjon og oppdater databasekonfigurasjon"Konfigurasjon" → "Oppdater databasekonfigurasjon".

Overfør om nødvendig verdiene til OrderReserve1-attributtet til OrderReserve ved hjelp av ekstern behandling i 1C:Enterprise-modus.

Trinn 2. Oppdatering.

Etter å ha utført det forberedende arbeidet på trinn 1, går vi videre til oppdateringen grunnleggende konfigurasjon og overføring av tidligere utførte modifikasjoner til leverandørens standardkonfigurasjon.

For å oppdatere konfigurasjonen trenger vi en *.cfu-fil eller en *.cf-fil fra leverandørens distribusjon. Du kan lese mer om hvordan du får tak i dem.

Hvis oppdateringen utføres gjennom flere versjoner av konfigurasjonen, bør du være oppmerksom på situasjonen beskrevet i artikkelen "". Hvis oppdateringen ikke utføres på en fungerende base, lagrer vi *.cf-filene etter å ha fullført klargjøringen av hvert nytt trinn. De vil være nødvendige ved oppdatering av konfigurasjonen av kundens produksjonsdatabase.

Hvis oppdateringen utføres gjennom flere versjoner, bør du under oppdateringen definitivt være oppmerksom på objektene som slettes og objekter med endrede navn, samt til handlingene som ble utført under den første lanseringen etter oppdateringen. Hvis disse objektene brukes i behandlingen ved første start etter oppdateringen, skal de ikke slettes, og for objekter med endrede navn bør det gjøres passende endringer i teksten til behandlingsmodulen. I dette tilfellet kan objektene som er igjen bli slettet under neste eller neste oppdatering.

Hvis oppdateringen utføres gjennom flere versjoner, kan du for å redusere arbeidsintensiteten til oppdateringen bruke metoden for å beregne nøkkelutgivelser, beskrevet i artikkelen "Oppdatering av 1C:Enterprise 8-konfigurasjoner. Hopper gjennom 20 versjoner."

1. Utarbeidelse av databaser.

Så, basert på resultatene fra den første fasen, utarbeider vi to identiske databaser. Det første (hoved) er vårt fremtidige resultat. Den andre (hjelpe) - for å utføre sammenligninger, åpne konfigurasjoner og andre forberedende handlinger. For filversjonen er dette ganske enkelt å kopiere filene til hoveddatabasen til en annen katalog og koble denne katalogen til listen over databaser; for klient-serverversjonen er det opplasting/nedlasting.

2. Treveis sammenligning av konfigurasjoner.

La oss åpne begge databasene i konfiguratormodus og utføre en treveis sammenligning av konfigurasjoner i begge databasene, ved å bruke den eksisterende leverandørens nye konfigurasjonsfil. For å gjøre dette, i begge databasene, velg menypunktet "Konfigurasjon" → "Støtte" → "Oppdater konfigurasjon", "Velg oppdateringsfil", "Fullfør" (Figur 10).

Som et resultat av å sammenligne tre konfigurasjoner ( gammel leverandørkonfigurasjon, ny leverandørkonfigurasjon Og fungerende konfigurasjon) får vi en liste over endrede objekter. Sett filteret "Vis bare to ganger endrede egenskaper" (figur 11 og 12).

Det er disse objektene som må behandles først, fordi... Etter oppdateringen kan tidligere gjorte innstillinger gå tapt.

På dette tidspunktet stanser vi arbeidet i den andre (hjelpe) databasen og fortsetter i hoveddatabasen. Det er ikke nødvendig å klikke på "Kjør"-knappen i tilleggsdatabasen. Vi trenger denne databasen nøyaktig i dette skjemaet til oppdateringsprosessen er fullført.

Så som et resultat får vi en liste over objekter som ble endret to ganger under revisjon typisk konfigurasjon og i . Hvis du godtar oppdateringen, vil tidligere utførte forbedringer av disse objektene gå tapt. Derfor, for hvert objekt er det nødvendig å ta en beslutning om hvordan det skal oppdateres (Figur 13). På dette stadiet utfører vi en foreløpig sammenligning utelukkende for å redusere arbeidsmengden i fremtiden. Vurderingen er ikke nøyaktig og rask - "etter øye".

ny leverandørkonfigurasjon, så legger vi igjen en forekomst av leverandørobjektet. Legg igjen et merke. Deretter overfører vi endringene fra fungerende konfigurasjon.

Hvis det er flere endringer i objektet i fungerende konfigurasjon, så forlater vi en forekomst av objektet fungerende konfigurasjon. Fjern merket i boksen. Deretter overfører vi endringene fra leverandørkonfigurasjon.

Vi håndterer moduler litt annerledes, fordi... Vi har mulighet til å sammenligne moduler prosedyremessig. De. i tilfelle inn vår konfigurasjon og ulike modulprosedyrer er endret i leverandørens konfigurasjon, så ved å krysse av i boksene vil vi spare oss for å manuelt overføre kodeendringer. For å komme til dette, trykk på knappen som vist i figur 14.

Etter at vi har bestemt oss for objektene som skal oppdateres umiddelbart og som det fortsatt er hakemerker på, dupliserer vi tilstanden ved å hake i hjelpedatabasen, og i hoveddatabasen trykker vi på "Kjør"-knappen. I hoveddatabasen får vi en nesten ferdig konfigurasjon.

Deretter utfører vi alle sammenligninger i hjelpedatabasen. Vi har allerede én sammenligning – en treveis. For å fastslå tidligere gjort endringer, utfører vi en ekstra andre sammenligning gammel leverandørkonfigurasjon Med hovedkonfigurasjon. For å gjøre dette, velg elementet i menyen "Konfigurasjon" → "Sammenlign konfigurasjoner:", velg for sammenligning " Leverandørkonfigurasjon"Og" Grunnleggende konfigurasjon

På lignende måte sammenligner vi gammel leverandørkonfigurasjon med en ny. For sammenligning trenger vi en fil ny leverandørkonfigurasjon. Hvis det ikke finnes en slik fil, kan den nå hentes fra hoveddatabasen. For å lagre til en fil ny leverandørkonfigurasjon i hoveddatabasen i menyen "Konfigurasjon" → "Support" → "Støtteinnstillinger:" klikker du på "Lagre til fil"-knappen. (Figur 2). Angi filnavnet, for eksempel new.cf. Deretter gjør vi en tredje sammenligning av konfigurasjoner, og når du sammenligner, spesifiser filen new.cf som den andre konfigurasjonen.

Så vi mottok en liste over to ganger endrede objekter i tilleggsdatabasen. Og ytterligere to sammenligninger som vil hjelpe oss mer effektivt å overføre tidligere innstillinger fra gammel versjon til en ny. I hoveddatabasen har vi en nesten ferdig konfigurasjon, der vi må håndtere to ganger endrede objekter.

For å redusere tiden for å analysere endringer i en standardkonfigurasjon og følgelig for oppdatering, vil det være hensiktsmessig å kommentere alle endringer som er gjort i konfigurasjonen, og notere ikke bare den endrede teksten til modulene, men også formålet med endringene som er gjort. . Av flere grunner blir dette ofte ikke gjort. Når du utfører en oppdatering, er du ikke interessert i årsakene til å gjøre endringer, men i konsekvensene deres. Nemlig behovet for å bevare funksjonaliteten til den endrede konfigurasjonen. Dette kan kreve at du ikke overfører de endrede linjene, men fullstendig omarbeider den tilføyde (endrede) koden for å passe til funksjonaliteten til den nye leverandørkonfigurasjonen.

Sammenligning av skjemaer, tabeller og moduler av objekter i konfigurasjonen utføres med tilstrekkelig grad av detaljer (Figur 17). Dette er nok til å ta avgjørelser.

Men i noen tilfeller presenteres dataene i sammenligningsrapporter på en måte som gjør det vanskelig å ta en beslutning raskt. For eksempel, i tilfelle endring av typen detaljer som har en sammensatt datatype, sammensetningen av de som legges inn basert på objekter, etc. Det er på dette stadiet, på grunn av kompleksiteten, at forbedringer går tapt under oppdateringen. La oss vurdere denne situasjonen ved å bruke eksemplet på detaljer som har en sammensatt datatype. Når du genererer en rapport om objektsammenligning (Figur 17), presenteres de forskjellige dataene i de sammenlignede konfigurasjonene i form av lister som inneholder sammensetningen av datatyper, atskilt med komma. Rapporten viser imidlertid ikke i det hele tatt hvilke typer data som ble lagt til eller slettet. Selvfølgelig kan rapporten skrives ut og "gjemmes" for å identifisere forskjeller. I eksemplet under vurdering er det omtrent 200 slike objekter. Det er klart at sammenligningsprosessen ser ut til å være ganske arbeidskrevende og vil ta omtrent 50 timer.

For å redusere arbeidsintensiteten til arbeidet når du sammenligner objekter, kan du bruke "Cell Comparison"-behandlingen utviklet av Inform Service-selskapet. Arbeidsintensiteten til arbeidet ved sammenligning av komposittobjekter kan reduseres med omtrent 20 ganger.

"Cell Comparison"-behandlingen lanseres i 1C:Enterprise-modus og lar deg presentere informasjon fra objektsammenligningsrapporten i en visuell form (figur 18 og 19). Til sammenligning brukes egenskapene til 1C:Enterprise 8.

Behandlingsordningen er enkel. I konfiguratoren lager vi en rapport om sammenligning av objekter (Figur 17) og lagrer den i en fil, for eksempel Comparison Report.mxl. Åpne 1C:Enterprise og i dialogen (Figur 18) velg den lagrede filen og angi cellene som skal sammenlignes. For å gjøre dette, dobbeltklikk med høyre museknapp på den valgte cellen i regnearkdokumentet. Ved å klikke på «Sammenlign»-knappen får vi resultatet av sammenligningen, der de forskjellige posisjonene er uthevet i farger (Figur 19).

Videre, basert på det faktum at sammenligningen utføres i henhold til de samme prinsippene for å sammenligne objekter, vil handlingsdiagrammet se slik ut. Lagre neste rapport under samme filnavn. Klikk på "Oppdater" og "Sammenlign"-knappene.

Spesiell oppmerksomhet bør rettes mot RLS-maler for endrede brukerroller.

Etter å ha fullført oppdateringen og overføringen av tidligere foretatte endringer i standardkonfigurasjonen, vil vi utføre syntaktisk kontroll av modulene og kontrollere driften av de endrede objektene. Etter vellykket testing kan konanses som fullført. Nå gjenstår det bare å oppdatere eksterne trykte skjemaer, rapporter og behandling. For noen konfigurasjoner er det nødvendig å sjekke rapporteringsskjemaene som er koblet til som eksterne.

Trinn 3. Levering av arbeid.

I eksemplet som er gitt, er arbeidsmengden for å rette opp feil som er gjort under tidligere oppdateringer, samt å oppdatere til versjon 1.2.14.1 og overføre endringene som tidligere er gjort til standardkonfigurasjonen, omtrent 100-150 timer. Det er ikke mulig å utføre et slikt arbeidsvolum ved å oppdatere direkte i kundens database. Følgelig må forberedende arbeid utføres på en kopi av databasen, og resultatet av oppdateringen må overføres til kundens arbeidsdatabase.

Først studerer vi nøye instruksjonene fra distribusjonssettet. Vi utfører nødvendig arbeid før oppdatering av arbeidsdatabasen.

Hvis det ikke ble utført konfigurasjonsendringer i kundens arbeidsdatabase under forberedelsen av oppdateringen, og oppdateringen ble forberedt på en gjeldende kopi av arbeidsdatabasen, lagrer du arbeidskonfigurasjonen i en fil, for eksempel work_2 for å overføre innstillingene. .cf, ved å velge menypunktet “Konfigurasjon” → “ Lagre konfigurasjonen til en fil...”.

• Ved å bruke work_2.cf-filen overfører vi endringene. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Last inn konfigurasjon fra fil...";
• På spørsmål om oppdatering av databasekonfigurasjonen vil vi svare ja.

Hvis konfigurasjonsendringer ble utført i kundens produksjonsdatabase under utarbeidelsen av oppdateringen, må disse endringene også gjenspeiles under oppdateringen.

Hvis oppdateringen ikke ble forberedt på en gjeldende kopi av arbeidsdatabasen, vil vi bruke teknikken som ble brukt i den første fasen for å overføre innstillingene. For å gjøre dette trenger vi en *.cf-fil med standardkonfigurasjonen til leverandøren (1.2.14.1) og resultatet av oppdateringen i form av også en *.cf-fil. For å gjøre dette, lagre arbeidskonfigurasjonen til en fil, for eksempel work_2.cf, ved å velge menypunktet “Konfigurasjon” → “Lagre konfigurasjon til fil...”.

Ytterligere handlinger på kundens side vil være som følger:

• skape sikkerhetskopi Database;
• Ved å bruke *.cf-filen til standardkonfigurasjonen til leverandøren, vil vi utføre oppdateringen. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Støtte" → "Oppdater konfigurasjon", "Velg oppdateringsfil", "Fullfør" (Figur 10), "Kjør";
• Ved å bruke work_2.cf-filen overfører vi endringene. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Sammenlign, slå sammen med konfigurasjon fra fil...";
• La oss lagre endringene i arbeidskonfigurasjonen og oppdatere databasekonfigurasjonen. For å gjøre dette, velg menypunktet "Konfigurasjon" → "Oppdater databasekonfigurasjon".

Riktig utførelse av dette trinnet vil tillate deg å unngå arbeidet beskrevet i trinn 1 i fremtiden.

Å oppdatere en ikke-standard plattform er veldig vanskelig. Vi vil se på hvordan du oppdaterer en ikke-standard 1C-konfigurasjon og beskriver en trinn-for-trinn-løsning på nye vanskeligheter.

Hvordan oppdatere i en ikke-standard 1C-konfigurasjon.

Generelle begreper

Ved oppdatering av en ikke-standard plattform påvirker endringer alltid elementer av standardkonfigurasjonen til leverandøren.

Databasen (DB) inneholder opptil tre typer konfigurasjoner:

• selve databasen - logiske algoritmer fungerer med den;
• fungerer (den såkalte main, ConfigOR) - som vi endrer med jevne mellomrom;
• leverandørkonfigurasjon (ConfigP - basert på den, er både arbeids- og databasekonfigurasjonen opprettet av brukeren.

Hvis et program utelates fra støtten, vil det ikke lenger være tilgjengelig fra leverandøren. Men da er en økning i lønnskostnader for oppdatering uunngåelig. La oss vurdere å oppdatere en ikke-standard 1C-konfigurasjon. Et eksempel kan være PPM-plattformen (Manufacturing Enterprise Management).

Blande

Det første trinnet er å fjerne forskjellene mellom fungerende og leverte konfigurasjoner. Dette vil redusere evalueringen av forbedringene vi tidligere har gjort. Inkonsekvenser mellom dem oppstår når utenlandske filer (ikke fra den medfølgende distribusjonen) ble brukt under oppdateringen eller oppdateringsmetodene skilte seg fra standard.

Sammenligning av versjoner

Vi sjekker versjonsnumrene (fungerende og levert). Den første er krysset av i "Konfigurasjon" / "Åpne" / "Rediger" / "Egenskaper". I delen "Utvikling/versjon". Andre i "Konfigurasjon" / "Support" / "Støtteinnstillinger" / "Versjon":

Hvis tallene stemmer, kan du gå videre til avsnittet Motta en fil gjennom en oppdatering.

De følgende trinnene viser hvordan du matcher arbeids- og leverandørkonfigurasjonen. For å sette på støtte de objektene som ble fjernet eller lagt til av brukeren uten støtte. For dette:

Lagre konfigurasjonen (fungerer)

La oss lagre ConfigOR i en fil som heter for eksempel work.cf. For å gjøre dette, velg "Konfigurasjon"/"Lagre...".

Henter leverandørfilen

For å kombinere ConfigOR med ConfigP trenger du en cf-fil fra leverandørens distribusjon (samme versjon). Som standard vil det være i C:/Program Files/1cv81/tmplts. La oss sjekke tilstedeværelsen av den nødvendige cf-filen i maltabellen. Hva du skal gjøre hvis ikke ønsket fil nødvendig leverandørkonfigurasjonsversjon? Deretter må du opprette en tom database fra den gamle, oppdatere den til den nødvendige versjonen og først deretter bruke den.

Motta en fil via oppdatering

For å utføre en oppdatering av ConfigP cf-filen, velg kommandoen fra menyen: "Konfigurasjon/Støtte/Oppdater.../Velg fil/Fullfør/Kjør" (sekvensielt i bildene):

For å løse dette må du fjerne merket for slettemerket fra objektet i leverandørkonfigurasjonen. Deretter, etter sletting, utfører vi sammenligningen igjen - klikk på "Oppdater" -knappen i oppdateringsvinduet.

Gjenoppretter innstillinger

Noen av de tapte innstillingene gjenopprettes ved å slå dem sammen med den tidligere lagrede work.cf-filen. For å gjøre dette, velg "Konfigurasjon/Sammenlign, slå sammen... filer".

Lagring og justering

For å lagre ConfigOR og oppdatere databasen, i “Configuration” menyelementet, velg “Update...DB”. Her møter vi et nytt problem:

Mest sannsynlig var grunnen til dette at disse objektene ble kopiert fra ConfigP eller de ble slettet av leverandøren, og senere ble nye lagt til under samme navn. Men med forskjellige identifikatorer. Som et resultat dukket det opp objekter med samme navn, men med forskjellige identifikasjonsnøkler.

Roller kan ganske enkelt slettes, siden de ikke er endret. Attributtet må gis nytt navn, for eksempel til OrderReserve1. Og etter oppdatering, skriv inn verdiene fra den omdøpte til den opprettede. En annen situasjon under oppdateringen. Hva med skjemaer?

Av figuren kan du se at Listeskjemaet ble slettet av leverandøren, og deretter lagt til igjen under samme navn. Du må merke begge for oppdatering og klikke på "Kjør".

Hvis det sendes en melding under oppdateringen om tilstedeværelsen av lenker til objekter som skal slettes, må du, uten å lukke skjemaet, fjerne koblingene til det i egenskapene til selve objektene. Her er det i registeret eiendommer. Deretter velger du oppdateringsalternativet i oppdateringsskjemaet, merker registeregenskapene for oppdatering nå, og klikker på "Kjør" igjen.

Lagre endringer i arbeidsdatabasen og oppdatere databasekonfigurasjonen: "Konfigurasjon/Oppdater...DB". Verdien av OrderReserve1-attributtet overføres til OrderReserve ekstern behandling 1C: Enterprise-modus.

Klargjøring av baser

Basert på resultatene av informasjonen utarbeider vi to identiske databaser. Det første (hoved) er ønsket resultat. Den andre (hjelpe) er for å utføre forberedende handlinger. Når det gjelder filversjonen, kopierer vi dem ganske enkelt til en katalog og kobler dem til informasjonssikkerhetslisten; med klient-server-alternativet gjør vi opplasting/nedlasting.

Sammenligning

Etter å ha åpnet begge databasene med konfiguratoren, vil vi utføre en treveis sammenligning av dem. Til dette bruker vi den nye ConfigP-filen - "Konfigurasjon/Support/Update.../Select file.../Done":

Sammenligning av fungerende, gamle og nye leverandørkonfigurasjoner gir oss en liste over endrede objekter ved å bruke "Vis to ganger endrede egenskaper"-filteret. Du må løse problemet med dem først:

På dette tidspunktet er arbeidet med hjelpedatabasen suspendert til hele prosessen er fullført; vi trykker ikke lenger på "Kjør"-knappen. La oss gå videre til å jobbe i hoveddatabasen med den resulterende listen over objekter som er endret to ganger. Å godta oppdateringen vil føre til tap av tidligere utførte forbedringer. Derfor, for hvert av objektene, er det nødvendig å ta en beslutning om hvordan det skal endres.

La oss gjennomføre foreløpig vurdering bare for å redusere arbeidet i fremtiden. Hvis det er flere elementendringer i den nye ConfigP, forlater vi leverandørobjektet. Vi setter en hake. Vi overfører endringer fra ConfigOR. Hvis det er flere elementendringer i arbeidskonfigurasjonen, etterlater vi en forekomst av ConfigOR-objektet. Fjern merket i boksen. La oss overføre endringene fra ConfigP. Moduler må sammenlignes prosedyremessig. For å gjøre dette, trykk på knappen som i figuren:

Vi krysser av i boksene for å indikere prosedyrer og funksjoner som skal erstattes eller fjernes:

Nå må du duplisere tilstanden til avmerkingsboksene i hjelpedatabasen. I den viktigste klikker du på "Kjør". På dette tidspunktet får vi i hovedsak en nesten ferdig konfigurasjon.

Påfølgende sammenligninger utføres på nytt i hjelpedatabasen. Vi finner tidligere gjort endringer ved å i tillegg sammenligne den gamle ConfigP med ConfigOR - "Configuration/Compare...":

På samme måte sammenligner vi den gamle ConfigP med den nye. Hvis det ikke er noen ny fil, kan du nå ta den fra hoveddatabasen.

Så, to ganger modifiserte objekter oppnås. En nesten ferdig konfigurasjon ble oppnådd i hoveddatabasen. I den må du håndtere to ganger endrede elementer.

VIKTIG. Når du analyserer, bør brukeren ikke være interessert i årsakene til å gjøre visse endringer, men i konsekvensene deres. Det vil si at det viktigste er behovet for å opprettholde funksjonalitet. Kanskje vil dette kreve at de endrede linjene ikke overføres, men en fullstendig omarbeiding av koden for den nye ConfigP.

For å ta en beslutning er det nok å sammenligne skjemaer, tabeller og objektmoduler. Noen ganger presenteres data i rapporter i en form som ikke tillater rask beslutningstaking. På dette trinnet oppstår tap av modifikasjoner hvis endringene gjelder objektdetaljer av en sammensatt type.

I sammenligningsrapporten presenteres de ulike dataene i form av en liste, hvor det ikke fremgår hvilke typer data som ble lagt til/fjernet. Hvis antallet rapportlinjer når to hundre, virker prosessen med "manuell" sammenligning ganske arbeidskrevende (omtrent femti timer).

Å redusere arbeidsintensiteten oppnås ved å bruke for eksempel "Cell Comparison"-konfigurasjonen fra Inform Service-selskapet. Den er tilgjengelig for lansering i 1C:Enterprise-modus og presenterer sammenligningsrapportdata i en praktisk form. Sammenligningen er utført ved hjelp av 1C-funksjoner:

Driftsskjemaet er enkelt. En sammenlignende objektrapport opprettes i konfiguratoren. Lagret i en fil, for eksempel Comparison Report.mxl. I 1C:Enterprise-dialogen åpnes den og cellene som skal sammenlignes indikeres (ved å dobbeltklikke med høyre museknapp på den valgte cellen i regnearkdokumentet). Ved å klikke "Sammenlign", vises resultatet av sammenligningen, med forskjellige posisjoner uthevet i farger.

Ytterligere handlingsinstruksjoner ser slik ut.

1. Den neste rapporten lagres med samme navn.
2. Etter at oppdateringen er fullført og modifikasjoner av standardkonfigurasjonen er overført, utføres syntaktisk kontroll av modulene og testing av driften av de endrede objektene.
3. Etter vellykket testing kan prosessen anses som fullført. Det gjenstår bare å oppdatere de trykte skjemaene, rapportene og behandlingen. Sjekk i noen tilfeller eksterne rapporteringsskjemaer.

Vi jobber med 1C 7.7

Å oppdatere en standardplattform til den samme forårsaker vanligvis ikke vanskeligheter. Du trenger bare å følge instruksjonene i instruksjonene. De er plassert i UPDATE.TXT i distribusjonskatalogen.

Det er heller ingen vanskeligheter hvis ytterligere regnskapselementer legges til plattformen (kataloger, konstanter, utvalg, rapporter, registre, beregningsjournaler, etc.). De vil passe når plattformene kombineres. Tilføyde dokumenter vil heller ikke forårsake disharmoni hvis det ikke var noen endringer i egenskapene for input "basert på" slike tilføyde dokumenter.

Det anbefales å utføre oppdatering på en rask PC med stor mengde RAM. Hvis det er mangel på det, kan 1C nekte å utarbeide noen av funksjonene og fryse. En stor mengde virtuelt minne løser ikke dette problemet.

Opprette en sikkerhetskopi

For dette formålet må du bruke alternativet: "Administrasjon/Lagre data...". Det er praktisk å angi navnet på arkivet, kombinere det med opprettelsesdatoen (for eksempel YYMMDD.zip).

Utarbeidelse av kataloger

For å fungere trenger du seks konfigurasjonsfiler (1cv7.md):

1. "WorkingNew" for å forberede oppdateringen (resulterende md-fil);
2. "WorkingOld" for sporing av endringer under sammenligning og for overføring av innstillinger til TypeNew_2;
3. Typisk (gammel) "TypeOld_1". På grunnlag av det ble det tidligere opprettet en fungerende.
4. Typer. (tidligere) "TypeOld_2". For å spore endringer i 1C-selskapet i den nye standardversjonen;
5. Type. (ny) "TypeNy_1". Forbedringer fra 1C i den nye versjonen;
6. "TypeNew_2" for komplekse objekter.

Og fem kjører konfiguratorer(alle unntatt "TypeNew_1").

Til å begynne med er katalogene identiske i par:

• "WorkerNew" og "WorkerOld";
• "TypeOld_1 og TypeOld_2";
• "TypeNew_1" og "TypeNew_2".

Kombinere elementer

Først gjør vi en sammenligning mellom 3 og 2, 4 og 5, 1 og 6. For å gjøre dette, for hver av de første i paret, velg elementet "Configuration / Merger ..." og spesifiser metadatafilen 1cv7. md av den andre i paret. Et skjema med et tre med endrede elementer vil vises på skjermen. Deretter er det nødvendig å analysere resultatene av en parvis sammenligning av 3 med 2 og 4 med 5. La det være til sammenslåing av elementer i de oppdaterte plattformene (1 og 6), der det var endringer fra 1C-selskapet (4 med 5). , men ble ikke reflektert i 3 og 2. 1 og 4 må kombineres i substitusjonsmodus.

Andre

Dette kan inkludere kontoplan og brukergrensesnitt. Hvis det har vært endringer i kontoplanen, må den oppdateres i «Combining Objects»-modus WorkNew sammen med TypeNew_2. Etter å ha kombinert grensesnittet, kontrolleres tilstedeværelsen av feil: duplisering av menyelementer, duplisering av verktøylinjer, innstilling av "Layout på ny linje"-flagg for verktøylinjer.

Nedlastingen gjøres over nettverket eller på en server (foretrukket). Først gis eksklusiv tilgang til databasen. Og gjennom konfiguratormodusen lastes databasen. Før og etter nedlastingen arkiveres data (som beskrevet helt i begynnelsen av avsnittet). Deretter må du følge instruksjonene i UPDATE.TXT-filen. Etter at nedlastingen er fullført, kan alle kataloger unntatt WorkNew slettes.

Vi håper publikasjonen vår hjalp deg med å forstå oppdatering av en ikke-standard 1C-konfigurasjon. Vi så på dette med hensyn til både den syvende og åttende versjonen.

Legg igjen kommentarer, skriv om opplevelsen din i 1C-oppdateringen.