Ändra konfigurationen 1s 8.3. Personlig erfarenhet: hur man snabbt och kostnadseffektivt uppdaterar en ändrad konfiguration. Uppdatering av delad modul

Uppdatering av 1C görs genom att trycka på en "ett"-knapp, en typisk konfiguration kan själv ladda ner 1C-uppdateringen och installera den. Användaren kommer endast att behöva ange registreringsdata.

Vad ska man göra om konfigurationen inte är typisk? Eller en typisk sådan, men förbättringar har gjorts i den - en uppslagsbok, ett par detaljer, en rapport har lagts till?

Vi kommer att ta reda på svaret på denna fråga idag.

Vad är atypisk konfiguration 1C

Atypisk 1C-konfiguration är när:

• Konfigurationen skrivs från början av programmeraren
• Konfigurationen var typisk, men ändringar lades till i den
• Även om de lagt till en rekvisita.

För att göra några ändringar i den typiska konfigurationen måste du .

När du uppdaterar 1C en icke-standardkonfiguration som tas bort från supporten, kommer 1C att erbjuda att "sätta tillbaka den icke-standardiserade konfigurationen för support". Då kommer alla ändringar att avbrytas (raderas).

För att säkerställa att när du uppdaterar 1C av en icke-standardiserad (ändrad) 1C-konfiguration, ändringarna kvarstår och 1C-uppdateringen tillämpas, kan du använda ett annat 1C-uppdateringsläge.

Låt oss titta på ett exempel på en modifierad konfiguration som vi vill uppdatera. Detta är en typisk 1C Accounting-konfiguration (till vänster), som har ändrats (till höger):

4) I katalogen "Individuals", i formulärmodulen, i funktionen ReadPlace of Birth() lades en rad av programmet till

Hur kommer alla dessa ändringar att fungera vid tidpunkten för uppdatering av 1C av en icke-standardiserad 1C-konfiguration?

Uppdaterar 1C med att spara ändringar av den icke-standardiserade 1C-konfigurationen

1C-konfigurationsuppdateringen distribueras vanligtvis som ett självextraherande arkiv. Efter uppackning måste du köra installationsfilen för att installera 1C-uppdateringen på din dator (inte i 1C!).

När du installerar uppdateringen väljer du var 1C-uppdateringen ska installeras. Vanligtvis detta. Du kan installera till vilken annan mapp som helst på disken och 1C anger var .

1C-uppdateringsfiler kan ha följande form:

• fil med CF-tillägg - innehåller en helt ny typ av konfiguration
• fil med CFU-tillägget - innehåller endast ändringar från den tidigare versionen.

Båda filerna lagras i 1C-uppdateringskatalogen, i en mapp med namnet på versionen.

Var försiktig när du använder CFU-filen - den låter dig bara uppgradera från !

Så, för att uppdatera 1C, välj ett av menyalternativen:

• Konfiguration/Jämför sammanfogning med konfiguration från fil - för CF-filer
• Konfiguration / Support / Uppdatera konfiguration / 1C-uppdateringsfilval - för CF- eller CFU-filer.

Först och främst kommer 1C att jämföra de två konfigurationerna. Din databaskonfiguration kallas "Huvudkonfiguration" och konfigurationen från uppdateringen heter "Konfigurera från fil".

1C kommer att visa alla skillnader i form av ett välbekant träd, där ändringarna visas till höger.

Titta - i vårt exempel är kataloger som har ändrats eller lagts till markerade.

Eftersom vi uppdaterar den icke-standardiserade 1C-konfigurationen, som har ändrats - det vill säga det var en gång typiskt, måste du ange några inställningar.

Klicka på knappen Inställningar. Välj "Lastad konfiguration är en avkomling av huvudet" (det vill säga det är en modifierad typ).

Kryssrutan "Tillåt radering av huvudkonfigurationsobjekt" låter dig ta bort om de raderas i 1C-uppdateringen. Eftersom vi lagt till detaljer och kataloger i konfigurationen, men de inte finns i 1C-uppdateringen, kommer 1C att anta att de togs bort i 1C-uppdateringen. Därför behöver du inte markera den här rutan.

Låt oss ta en närmare titt på skillnaderna som upptäckts av plattformen.

Låt oss öppna grenen av referensboken Nomenclature. I Requisites-grenen ser vi att det inte finns några rekvisita i den typiska konfigurationen, och vi lägger till det. Minus betyder att den kommer att tas bort.

Eftersom vi inte behöver ta bort rekvisita som vi själva har lagt till, måste vi göra följande (alternativ):

• I knappen "Inställningar", SÄTTA INTE kryssrutan "Tillåt borttagning av huvudkonfigurationsobjekt"
• Om kryssrutan fortfarande är markerad, avmarkera kryssrutan för detta attribut. Det finns ingen bock framför rekvisitan i bilden, eftersom det inte är tillåtet att ta bort objekt.

Formen på nomenklaturuppslagsboken har också ändrats. 1C såg detta och visar oss också katalogformuläret i listan över ändrade objekt.

För att se vilka ändringar som har gjorts på formuläret kan du göra följande (alternativ):

• Högerklicka först på formuläret i den vänstra kolumnen och välj menyalternativet "Öppna formulär" och sedan till höger. Jämför de två formerna visuellt.
• Högerklicka på formuläret och välj menyalternativet "Objektjämförelserapport" (detaljerad, kalkylbladsdokument)

Objektjämförelserapporten visar vid jämförelse av blanketter många skillnader. Detta beror på det faktum att när vi bara lägger till ett fält i formuläret, ändras många intilliggande element automatiskt - indrag, bindningar, etc.

I listan över ändringar ser vi våra ändringar - ändringar i inskriptionen och ersättning av fältet.

Vi kan godkänna eller vägra att ändra formuläret genom att markera kryssrutan bredvid. Detta medför följande konsekvenser:

a) om vi markerar rutan

• formuläret kommer att ersättas med ett nytt
• våra ändringar av standardkonfigurationen kommer att raderas
• ändringar från uppdatering 1C kommer att tillämpas
• då kommer det att bli nödvändigt att återställa våra ändringar manuellt

b) om vi inte bockar

• formuläret lämnas som det är
• våra förändringar kvarstår
• nya ändringar från uppdatering 1C tillämpas inte
• sedan manuellt kommer det att vara nödvändigt att lägga till ändringar från 1C-uppdateringen.

Du kan använda det tredje alternativet. Expandera formulärgrenen till slutet och välj "Sammanfoga" i kolumnen "Merge Mode".

c) om vi valde "Kombinera"

• formen kommer att vara någon ny, i vilken det kommer både nya förändringar och gamla
• våra förändringar kvarstår
• nya ändringar dyker upp
• om ett fält raderades och ett annat fält sattes i dess plats, som ett resultat av sammanslagningen, kommer båda fälten att finnas på samma plats samtidigt - både det gamla och det nya
• chansen är att formen ser ok ut
• sedan manuellt måste du kontrollera att det inte fanns några "excesser"

2) I katalogen "Individuals", i formulärmodulen, i funktionen ReadPlace of Birth() lades en rad av programmet till

För att se ändringarna i formulärmodulen som 1C upptäckte, expandera formulärgrenen till slutet, högerklicka på den, välj menyalternativet "Visa skillnader i moduler".

Ändringar visas i sammanhanget för varje funktion, men med detta visningsläge kan du antingen välja att uppdatera 1C för hela modulen eller neka den.

Ett annat sätt är att använda förstoringsglasknappen på den här raden.

Då ser vi inte bara ändringarna i varje funktions sammanhang, utan vi kan även använda kryssrutorna för att välja vilken funktion vi vill uppdatera och vilken som inte.

3) I katalogen "Elektroniska representationer .." bort flera detaljer

1C har bestämt att vi har raderat detaljerna i standardkatalogen och erbjuder oss att återställa dem.

Katalogen som vi lade till föreslår 1C att ta bort. I det här fallet gäller samma regel som i fallet med attributet som lagts till av oss (se tidigare).

Så vår uppgift är att noggrant studera ändringarna som upptäckts av 1C och, med hjälp av kryssrutor, acceptera dem eller vägra. Efter det klickar du på knappen Kör.

Observera att om du raderade attributet som ett resultat av uppdateringen av 1C, så raderade du också de data som angavs i det av användare, vilket innebär att om du lägger till samma attribut igen kommer denna data inte att återställas.

Om det finns flera relaterade objekt i konfigurationen - till exempel ett attribut och en form; samtidigt tillät du att uppdatera 1C-formuläret, men avmarkerade rekvisita, då uppstår en motsägelse.

Efter att ha tryckt på Kör-knappen hittar 1C sådana situationer och rapporterar från dem.

Efter att ha klickat på Kör-knappen har du ytterligare en möjlighet att tänka.

För att bekräfta 1C-uppdateringen måste du välja menyalternativet Konfiguration / Uppdatera databaskonfiguration.

För att vägra uppdatera 1C måste du välja menyalternativet Konfiguration / Återgå till databaskonfiguration.

Det tredje alternativet (sekvensen av menyalternativ anges):

• Välj Arkiv/Spara
• Konfiguration/Spara konfiguration till fil
• Konfiguration/Databaskonfiguration/Återgå till databaskonfiguration.

Således laddar du bort den resulterande sammanslagna konfigurationen till en fil och vägrar ändringarna. Du kan analysera den resulterande konfigurationen, göra manuella ändringar och senare helt enkelt ladda den med hjälp av menyn Konfiguration/Ladda in konfiguration från fil.

Det här är en ganska gammal artikel av mig, men den är fortfarande relevant. Därför bestämde jag mig för att det skulle vara lämpligt att publicera den på www..

Den här artikeln beskriver inte metoder för att tillämpa automatiska och automatiska konfigurationsuppdateringar med hjälp av externa komponenter och/eller mjukvaruprodukter. Du kan hitta information om dem på andra Internetresurser.

Du kanske har märkt att antalet objekt som kräver din uppmärksamhet bara ökar för varje uppdatering. Samtidigt vet du säkert att till exempel bara ett dokument har ändrats och vid uppdatering visas en lista med flera dussin ändrade objekt. Naturligtvis kan du använda metoden som beskrivs i min artikel "Teknik för uppdatering av icke-standardiserade konfigurationer 1C: Enterprise 7.7" daterad 2003-06-27. Ja, det kommer att fungera. Många gör uppdateringar på detta sätt. Men jag anser att detta tillvägagångssätt är ineffektivt och tidskrävande när du uppdaterar konfigurationer på plattformen 1C:Enterprise 8. Till skillnad från plattformen 1C:Enterprise 7.7 tillåter 1C:Enterprise 8-plattformen dig att öppna flera konfigurationer (*.cf-filer) på samtidigt och utför flera konfigurationsjämförelser i en kopia konfigurator. Det enda undantaget är kanske bara konfigurationer byggda på SCP (Manufacturing Enterprise Management) - de är för tunga, plattformen faller.

Processen att uppdatera 1C:Enterprise 8-konfigurationer är mer automatiserad jämfört med 1C:Enterprise 7.7. En tillräckligt hög nivå av automatisering kan avsevärt minska komplexiteten i arbetet vid uppdatering av icke-standardiserade konfigurationer. Tyvärr kan processen med att uppdatera icke-standardiserade konfigurationer oftast inte utföras helt automatiskt och kräver ingripande av en specialist.

Är det möjligt att uppdateringsprocessen kommer att utföras helt automatiskt? Säkert. För att göra detta måste föränderliga objekt läggas till och får inte använda funktionen hos en befintlig konfiguration. De där. dessa objekt ska lösa helt andra redovisningsuppgifter som utökar funktionaliteten i leverantörens typiska konfiguration. Håller med om att den beskrivna situationen är extremt sällsynt. Nästan alltid påverkar ändringarna objekten för den typiska konfigurationen av leverantören.

Observera att databasen kan innehålla upp till tre typer av konfigurationer:

• databaskonfiguration - det här är konfigurationen som användare arbetar med;
• fungerande konfiguration (huvud) är en konfiguration som vi kan göra ändringar i, medan användare kan fortsätta att arbeta;
• leverantörens konfiguration är den initiala konfigurationen av leverantören, från vilken fungerande konfiguration Och databaskonfiguration. En databas kan ha flera konfigurationer från olika leverantörer. Konfigurationsleverantören kan inte bara vara 1C.

Om konfigurationen tas bort från supporten, leverantörens konfiguration ska inte. Vilket i sin tur ökar komplexiteten i uppdateringen avsevärt.

Låt oss överväga uppdateringsprocessen och analysera möjliga fel med hjälp av exemplet med att uppdatera SCP-konfigurationen (leverantören av en typisk konfiguration är 1C, förbättringar av Inform Service). Till en början utfördes inte uppdateringen av denna konfiguration med den teknik som beskrivs i den här artikeln, så de fel som diskuteras i artikeln är de vanligaste i praktiken. Uppgraderingen kommer att utföras från version 1.2.6.2 till version 1.2.14.1.

Steg 1. Förberedelser.

I det första skedet kommer vi att harmonisera fungerande konfiguration till leverantörens konfiguration. Detta är ett mycket viktigt steg, som avsevärt kommer att minska mängden arbete med analysen av de förändringar vi gjort tidigare.

Det här steget kan hoppas över om den senaste uppdateringen gick igenom "support" (menyn "Konfiguration" → "Support" → "Uppdatera konfiguration") eller utfördes enligt metoden som beskrivs i den här artikeln.

Version matchar inte fungerande konfiguration Och leverantörens konfiguration kan inträffa när du använder *.cf-filer för uppdatering, inte från leverantörens distributionskit, eller när du använder andra uppdateringsmetoder än de som beskrivs i den här artikeln. Till exempel lades objekt till i arbetskonfigurationen genom att kopiera via urklipp eller Dra och släpp.

1. Jämförelse av versioner.

Kontrollerar versionsnummer fungerande konfiguration Och leverantörens konfiguration. siffra fungerande konfiguration titta i menyn "Konfiguration" → "Öppna konfiguration"-menyn "Redigera" → "Egenskaper". I blocket "Utveckling" väljer du "Version". (Bild 1).

siffra leverantörens konfiguration titta i menyn "Konfiguration" → "Support" → "Inställningsstöd ..." objektet "Version". (Figur 2).

Om siffrorna matchar, gå till nästa steg. Centimeter. .

I det här exemplet måste du matcha fungerande konfiguration Och leverantörens konfiguration med stöd för föremål som tagits bort från stöd eller lagts till utan stöd. För att göra detta, utför följande steg:

2. Spara den fungerande (huvud)konfigurationen.

Låt oss spara fungerande konfiguration till en fil som work.cf . För att göra detta, välj menyalternativet "Konfiguration" → "Spara konfiguration till fil ...".

3. Hämta uppdateringsfilen för leverantörens konfiguration.

För att matcha konfigurationerna behöver vi en *.cf-fil från leverantörsdistributionen med samma versionsnummer som fungerande konfiguration(Figur 3 och 4). Den här filen kan erhållas när du installerar lämplig distribution. Som standard är koinstallerat i katalogen C:/Program Files/1cv81/tmplts. Mer information om installation av konfigurationsmallar finns i dokumentationen.

Låt oss kolla mallkatalogen. Om det finns en *.cf-fil av den version som krävs i mallkatalogen, gå till .

Vad kan göras om det inte finns någon *.cf-fil av den version som krävs leverantörens konfiguration? I det här fallet kan du använda *.cfu-filerna och upprepa proceduren som beskrivs i steg 1 flera gånger för att sekventiellt öka versionsnumret till den nödvändiga versionen, i det här fallet till 1.2.6.2. Det bör noteras att användningen av *.cfu-filer kanske inte avslöjar fel som gjorts tidigare under uppdateringen. Vilket, du ser, är ganska konstigt, med tanke på det faktum att leverantörsfilen först sätts ihop baserat på *.cfu-filen, och sedan utförs uppdateringen. Kanske beror detta på att av någon anledning inte alla konfigurationsobjekt deltar i jämförelsen. Därför föreslår jag att använda den längsta möjliga vägen, men också mer pålitlig.

Skapa en tom databas med "gammal" leverantörskonfiguration. Uppdatera leverantörens konfiguration till den version som krävs och använder den redan när du utför arbete på det första steget. För att få "ny" leverantörskonfiguration du måste göra följande:

1. Skapa en "gammal" leverantörsfil för den aktuella konfigurationen. Filen 1cv8.cf kan hämtas från leverantörsdistributionen eller sparas från arbetsbasen om konfigurationen stöds. För att spara filen 1cv8.cf från arbetsbasen, i menyn "Konfiguration" → "Support" → "Stöd för inställningar ...", klicka på knappen "Spara till fil" och ange katalog och filnamn. Till exempel på skrivbordet.
2. Skapa en databas med en ny leverantörskonfiguration. Databasen kan skapas med hjälp av leverantörsdistributionen från ITS-disken eller med 1cv8.cf som erhölls tidigare från skrivbordet. I det första fallet, följ instruktionerna som ingår i distributionen. I det andra fallet, för att skapa en databas från en fil som finns på skrivbordet, skapa en ny infobas utan konfiguration och kör konfiguratorn. I menyn "Konfiguration" → "Ladda konfiguration från fil ..." ange filen som tidigare sparats på skrivbordet. Öppna konfigurationen via menyn "Konfiguration" → "Öppna konfiguration" och uppdatera till önskad version genom menyn "Konfiguration" → "Support" → "Uppdatera konfiguration" med *.cfu-filer.
3. Skapa en "ny" leverantörskonfigurationsfil. För att göra detta, välj objektet i menyn "Konfiguration" → "Spara konfiguration till fil ...". Vi anger platsen och filnamnet 1cv8.cf. Klicka på "Spara".

4. Justera den fungerande konfigurationen med leverantörens konfiguration genom en uppdatering.

Använder den resulterande *.cf-filen leverantörens konfiguration låt oss göra uppdateringen. För att göra detta, välj menyalternativet "Konfiguration" → "Support" → "Uppdatera konfiguration", "Välj uppdateringsfil", "Slutför" (Figur 5), "Kör" (Figur 6).

Lösningsalternativ:

• avmarkera objektet som finns i leverantörens konfiguration;
• ta bort referensen till objektet som finns i leverantörens konfiguration.

Baserat på att länken i det tillagda gränssnittet "Avdelningschef" görs till objektet leverantörens konfiguration, från vilket stöd drogs tillbaka av leverantören (kanske på grund av en ändring i redovisningsmetoden), så skulle den korrekta lösningen i denna situation vara att ta bort länken till denna rapport från gränssnittet "avdelningschef". Vi stänger inte fönstret för jämförelse av konfigurationer, vi tar bort länken till rapporten "Betalning för beställningar" i gränssnittet "avdelningschef". Efter att ha tagit bort länken, låt oss jämföra konfigurationerna igen. För att göra detta, klicka på knappen "Uppdatera" i uppdateringsfönstret (Figur 6).

5. Återställning av inställningar som delvis förlorades i föregående steg.

För att återställa delvis förlorade inställningar, låt oss slå samman med en tidigare sparad fil fungerande konfiguration work.cf. För att göra detta, välj menyalternativet "Konfiguration" → "Jämför, slå samman med konfigurationen från filen ...".

6. Sparar resultatet av uppdateringen.

Spara ändringar fungerande konfiguration och uppdatera databaskonfiguration. För att göra detta, välj menyalternativet "Konfiguration" → "Uppdatera databaskonfiguration".

Här står vi inför ett annat problem (Figur 8).

För att lösa detta problem, låt oss titta på orsaken till dess förekomst. Det kan finnas flera skäl, men följande är de mest troliga. Dessa objekt har kopierats till fungerande konfiguration från leverantörens konfiguration eller så har leverantören tagit bort tidigare givna objekt, och senare lagt till nya med samma namn, men med olika interna identifierare. Som ett resultat av detta visas objekt med olika interna identifierare men samma namn i konfigurationen.

Vi agerar helt enkelt med roller - vi tar bort dem, eftersom rollerna har inte ändrats (detta kan kontrolleras genom att jämföra och fungerande konfiguration). Vi agerar annorlunda med detaljerna i dokumentet. Attributet måste döpas om, till exempel OrderReserve1, och efter uppdateringen överför du värdena från det omdöpta attributet till det nya. För att göra detta kan du använda bearbetningen av UniversalSelectionAndProcessingObjects.epf från ITS-disken.

Tänk på en annan situation som liknar den föregående, men som uppstod när 1C: Enterprise Accounting 8.1 uppdaterades. Vad ska man göra med formulär? (Figur 9)

I figuren kan vi se att ListForm har tagits bort från leverantören och sedan har ett nytt formulär med samma namn lagts till av leverantören. Följaktligen är det nödvändigt att markera båda formulären för uppdatering och klicka på knappen "Kör".

Om ett meddelande visas om att det finns länkar till objekt som ska raderas, är det nödvändigt att rensa länkarna till formuläret som ska raderas i objektegenskaperna utan att stänga uppdateringsformuläret. I detta fall i registrets egenskaper. Efter det, i uppdateringsformuläret, klicka på knappen "Uppdatera", markera registeregenskaperna för uppdatering och klicka på knappen "Kör" igen.

Spara ändringar fungerande konfiguration och uppdatera databaskonfiguration"Konfiguration" → "Uppdatera databaskonfiguration".

Överför vid behov värdena för OrderReserve1-attributet till OrderReserve med hjälp av extern bearbetning i 1C:Enterprise-läge.

Steg 2. Uppdatering.

Efter att ha utfört det förberedande arbetet i steg 1 går vi vidare till uppdateringen huvudkonfiguration och överföra tidigare gjorda förbättringar till leverantörens typiska konfiguration.

För att uppdatera konfigurationen behöver vi en *.cfu-fil eller en *.cf-fil från leverantörens distribution. Du kan läsa mer om hur du skaffar dem.

Om uppdateringen utförs genom flera konfigurationsversioner, bör du vara uppmärksam på situationen som beskrivs i artikeln "". Om uppdateringen inte utförs på en fungerande databas, sparar vi *.cf-filerna efter att ha slutfört förberedelserna av varje nytt steg. De kommer att behövas vid uppdatering av kundens produktionsdatabaskonfiguration.

Om du uppgraderar över flera versioner bör du vara säker på att vara uppmärksam på de objekt som raderas och objekten med ändrade namn, samt de åtgärder som utförs vid första starten efter uppgraderingen, under uppgraderingen. Om dessa objekt används i bearbetningen vid den första starten efter uppdateringen, bör de inte tas bort, och för objekt med ändrade namn bör lämpliga ändringar göras i bearbetningsmodulens text. I det här fallet kan de övergivna objekten tas bort under den andra eller nästa uppdateringen.

Om uppdateringen utförs genom flera versioner, då för att minska komplexiteten i uppdateringen, kan du använda metoden med beräkning av nyckelversioner, som beskrivs i artikeln "Uppdatering av 1C: Enterprise 8-konfigurationer. Hoppa genom 20 versioner".

1. Upprättande av databaser.

Så, enligt resultaten från det första steget, förbereder vi två identiska baser. Det första (huvudsakliga) är vårt framtida resultat. Den andra (hjälp) är för att utföra jämförelser, öppna konfigurationer och andra förberedande åtgärder. För filversionen är detta helt enkelt att kopiera filerna i huvuddatabasen till en annan katalog och ansluta denna katalog till listan över databaser, för serverklienten - uppladdning / nedladdning.

2. Trevägsjämförelse av konfigurationer.

Låt oss öppna båda databaserna i Configurator-läget och utföra en trevägsjämförelse av konfigurationerna i båda databaserna med hjälp av den befintliga leverantörens nya konfigurationsfil. För att göra detta, välj i båda databaserna menyalternativet "Konfiguration" → "Support" → "Uppdatera konfiguration", "Välj uppdateringsfil", "Slutför" (Figur 10).

Som ett resultat av att jämföra tre konfigurationer ( gammal leverantörskonfiguration, ny leverantörskonfiguration Och fungerande konfiguration) får vi en lista över ändrade objekt. Ställ in filtret "Visa endast två gånger ändrade egenskaper" (figur 11 och 12).

Det är med dessa objekt som du måste ta itu med först och främst, eftersom. Efter uppdateringen kan de tidigare gjorda inställningarna gå förlorade.

På detta arbete i den andra (hjälp) basen avbryter vi och fortsätter i den huvudsakliga. "Kör"-knappen i den extra basen behöver inte tryckas in. Vi behöver den här databasen i det här formuläret till slutet av uppdateringsprocessen.

Så som ett resultat får vi en lista över objekt som har ändrats två gånger under revisionen typisk konfiguration och i . Om du godkänner uppdateringen kommer de förbättringar som gjorts tidigare i dessa objekt att gå förlorade. För varje objekt måste därför ett beslut fattas om hur det ska uppdateras (Figur 13). I detta skede gör vi en preliminär jämförelse enbart för att minska arbetsmängden i framtiden. Utvärdering är inte exakt snabbt - "med ögat".

ny leverantörskonfiguration lämnar vi en instans av leverantörsobjektet. Vi lämnar en bock. Sedan överför vi ändringarna från fungerande konfiguration.

Om det finns fler ändringar i objektet i fungerande konfiguration, sedan lämnar vi en instans av objektet fungerande konfiguration. Vi avmarkerar rutan. Sedan överför vi ändringarna från leverantörens konfiguration.

Vi hanterar moduler lite olika, eftersom vi har möjlighet att jämföra moduler procedurmässigt. De där. i fall i vår konfiguration och olika modulprocedurer har ändrats i leverantörskonfigurationen, så genom att markera rutorna korrekt kommer vi att rädda oss från att manuellt överföra kodändringar. För att komma till detta, tryck på knappen som visas i figur 14.

Efter att vi har bestämt oss för vilka objekt som ska uppdateras omedelbart och som kryssrutorna finns kvar på, duplicerar vi tillståndet genom kryssrutorna i hjälpdatabasen, och i huvuddatabasen trycker vi på knappen "Kör". I huvuddatabasen får vi en nästan färdig konfiguration.

Vidare utförs alla jämförelser i hjälpdatabasen. Vi har redan en jämförelse - en tresidig. För att fastställa de tidigare gjorda ändringarna utför vi ytterligare en andra jämförelse gammal leverantörskonfiguration från grundläggande konfiguration. För att göra detta, välj objektet i menyn "Konfiguration" → "Jämför konfigurationer:", välj för jämförelse " Leverantörskonfiguration"och" Grundläggande konfiguration

På liknande sätt jämför vi gammal leverantörskonfiguration med nya. För jämförelse behöver vi en fil ny leverantörskonfiguration. Om det inte finns någon sådan fil kan den nu hämtas från huvuddatabasen. För att spara till fil ny leverantörskonfiguration i huvuddatabasen i menyn "Konfiguration" → "Support" → "Inställningsstöd:" tryck på knappen "Spara till fil". (Figur 2). Ange filnamnet, till exempel new.cf. Därefter gör vi den tredje konfigurationsjämförelsen och, när vi jämför, anger vi filen new.cf som den andra konfigurationen.

Så vi fick en lista över två gånger ändrade objekt i den extra databasen. Och ytterligare två jämförelser som hjälper oss att mer effektivt överföra tidigare gjorda inställningar från den gamla versionen till den nya. I huvuddatabasen fick vi en nästan färdig konfiguration, där vi måste hantera två gånger ändrade objekt.

För att minska tiden för att analysera ändringar av en typisk konfiguration och följaktligen för uppdatering, skulle det vara lämpligt att kommentera alla ändringar som gjorts i konfigurationen, och notera bara den ändrade texten i modulerna, men också syftet med de ändringar som gjorts. Av flera skäl görs detta ofta inte. När du utför en uppdatering är du inte intresserad av anledningarna till att göra ändringar, utan av deras konsekvenser. Nämligen behovet av att bevara funktionaliteten i den ändrade konfigurationen. Kanske kommer detta att kräva att de ändrade raderna inte överförs, utan en fullständig omarbetning av den tillagda (ändrade) koden för att passa funktionaliteten hos den nya leverantörskonfigurationen.

Jämförelse av formulär, tabeller och moduler av objekt i konfigurationen utförs med en tillräcklig detaljgrad (Figur 17). Detta är tillräckligt för beslutsfattande.

Men i vissa fall presenteras uppgifterna i jämförelserapporterna på ett sätt som inte gör att du snabbt kan fatta ett beslut. Till exempel, vid ändring av typen av attribut som har en sammansatt datatyp, sammansättningen av indata baserat på objekt, etc. Det är i detta skede, på grund av dess komplexitet, som det sker en förlust av förbättringar under uppdateringen. Låt oss överväga denna situation med hjälp av exemplet med attribut som har en sammansatt datatyp. Vid generering av en rapport om jämförelse av objekt (Figur 17) presenteras olika data i de jämförda konfigurationerna som listor som innehåller sammansättningen av datatyper separerade med kommatecken. Samtidigt visar rapporten inte alls vilka typer av data som har lagts till eller tagits bort. Naturligtvis, för att identifiera skillnader, kan rapporten skrivas ut och "gömmas". I det aktuella exemplet finns det cirka 200 sådana objekt.Det är uppenbart att jämförelseprocessen verkar vara ganska mödosam och kommer att ta cirka 50 timmar.

För att minska komplexiteten i arbetet när du jämför objekt kan du använda bearbetningen "Jämförelse av celler" som utvecklats av Inform Service. Cirka 20 gånger arbetsintensiteten i arbetet kan minskas när man jämför sammansatta objekt.

Bearbetning av "Jämförelse av celler" startas i 1C:Enterprise-läget och låter dig presentera information från objektjämförelserapporten i en visuell form (figur 18 och 19). Som jämförelse används funktionerna i 1C:Enterprise 8.

Bearbetningsschemat är enkelt. I konfiguratorn skapar vi en rapport om jämförelse av objekt (Figur 17) och sparar den i en fil, till exempel Comparison Report.mxl. Öppna 1C:Enterprise och i dialogrutan (Figur 18) välj den sparade filen och ange cellerna som ska jämföras. För att göra detta, dubbelklicka med höger musknapp på den valda cellen i kalkylarksdokumentet. Genom att klicka på knappen "Jämför" får vi resultatet av jämförelsen, där de olika positionerna är markerade i färg (Figur 19).

Baserat på det faktum att jämförelsen utförs enligt samma principer för att jämföra objekt, kommer handlingsschemat att se ut så här. Spara nästa rapport under samma filnamn. Klicka på "Uppdatera" och "Jämför" knapparna.

Särskild uppmärksamhet bör ägnas RLS-mallar för ändrade användarroller.

Efter att ha slutfört uppdateringen och överföringen av de tidigare gjorda ändringarna till den typiska konfigurationen kommer vi att utföra syntaktisk kontroll av modulerna och kontrollera funktionen för de ändrade objekten. Efter framgångsrik testning kan processen med att uppdatera konfigurationen anses vara avslutad. Nu återstår att uppdatera externa tryckformulär, rapporter och bearbetning. För vissa konfigurationer är det nödvändigt att kontrollera rapporteringsformulären som är anslutna som externa.

Steg 3. Leverans av verk.

I det givna exemplet är arbetsmängden för att korrigera fel som gjorts under tidigare uppdateringar, samt att uppdatera till version 1.2.14.1 och överföra ändringar som tidigare gjorts till standardkonfigurationen cirka 100-150 timmar. Det är inte möjligt att utföra en sådan arbetsvolym genom att uppdatera direkt i kundens databas. Följaktligen måste förarbete utföras på en kopia av databasen och resultatet av uppdateringen ska överföras till kundens arbetsdatabas.

Studera först noggrant instruktionerna från leveransdistributionssatsen. Vi utför det nödvändiga arbetet innan uppdatering i arbetsdatabasen.

Om inget arbete gjordes för att ändra konfigurationen i kundens arbetsdatabas under förberedelsen av uppdateringen, och uppdateringen förbereddes på den aktuella kopian av arbetsdatabasen, sparar vi arbetskonfigurationen för att överföra inställningarna till en fil, till exempel work_2.cf, genom att välja menyalternativet "Konfiguration" → "Spara konfiguration till fil...".

• överför ändringarna med filen work_2.cf. För att göra detta, välj menyalternativet "Konfiguration" → "Ladda konfiguration från fil ...";
• vi kommer att svara på frågan om uppdatering av databaskonfigurationen med ja.

Om kundens produktionsdatabas genomgick konfigurationsändringar under förberedelserna av uppgraderingen, måste dessa ändringar också återspeglas under uppgraderingen.

Om uppdateringen inte förbereddes på den aktuella kopian av arbetsdatabasen, kommer vi att använda den teknik som användes i det första steget för att överföra inställningarna. För att göra detta behöver vi *.cf-filen för den typiska leverantörskonfigurationen (1.2.14.1) och resultatet av uppdateringen i form av en *.cf-fil också. För att göra detta, låt oss spara den fungerande konfigurationen till en fil, till exempel work_2.cf, genom att välja menyalternativet "Konfiguration" → "Spara konfiguration till fil ...".

Nästa steg på klientens sida är följande:

• skapa en säkerhetskopia av databas;
• Låt oss uppdatera med *.cf-filen för leverantörens typiska konfiguration. För att göra detta, välj menyalternativet "Konfiguration" → "Support" → "Uppdatera konfiguration", "Välj uppdateringsfil", "Slutför" (Figur 10), "Kör";
• överför ändringarna med filen work_2.cf. För att göra detta, välj menyalternativet "Konfiguration" → "Jämför, slå samman med konfigurationen från filen ...";
• spara ändringarna i den pågående konfigurationen och uppdatera databaskonfigurationen. För att göra detta, välj menyalternativet "Konfiguration" → "Uppdatera databaskonfiguration".

Korrekt implementering av detta steg gör att du kan undvika det arbete som beskrivs i steg 1 i framtiden.

Att uppdatera en icke-standardiserad, kraftigt modifierad konfiguration är en mycket tidskrävande och ansvarsfull uppgift. Vanligtvis utförs en releaseuppdatering för konfigurationer som innehåller ett reglerat rapporteringsblock. Till exempel, .

Låt oss överväga det enklaste sättet att göra en icke-standarduppdatering utan fel, med hjälp av exemplet med 1C Enterprise Accounting-konfigurationen.

Början av varje uppdatering beskrivs i artikeln. Vi kommer bara att överväga det viktigaste - nyanserna i en atypisk uppdatering.

En liten teori om icke-standardiserade konfigurationer:

• Den konfiguration som inte stöds innehåller 2 konfigurationer: databaskonfigurationen och huvudkonfigurationen.
• Konfigurationen på support utan möjlighet till redigering innehåller 2 konfigurationer: databaskonfigurationen och huvudkonfigurationen (alias leverantören).
• En konfiguration som stöds med möjlighet att ändra innehåller redan 3 konfigurationer: en databaskonfiguration, en huvudkonfiguration och en leverantörskonfiguration.

1. Förbereder för uppdateringen

Innan du börjar alla steg, se till att leverantörens konfiguration matchar huvudkonfigurationen - detta kommer att underlätta atypisk uppgradering avsevärt. Om leverantörens konfiguration är en äldre version har konfigurationen tidigare uppdaterats felaktigt. Du kan uppdatera en leverantörs release genom att köra uppdateringen en i taget och inte välja något objekt för jämförelse.

Först och främst distribuerar jag 2 baser med den initiala konfigurationen. En för att göra ändringar, den andra för att jämföra med den nya.

Få 267 1C-videolektioner gratis:

Om din konfiguration inte är typisk kommer systemet att börja jämföra huvud- och leverantörskonfigurationen genom att trycka på knappen "Uppdatera" i konfiguratorn:

Utåt verkar det som att vi har ändrat ett stort antal objekt. Men låt oss föreställa oss situationen: du ändrade dokumentet, men det ändrades inte - behöver du uppdatera det manuellt? Självklart inte. För att välja sådana objekt efter jämförelse, se till att klicka på knappen Filtrera och kryssa i rutan

Efter filtrering ser vi att det är mycket färre ändrade objekt:

Vi fick en lista över objekt som vi ska arbeta med. I vårt fall fanns det bara ett komplext objekt - RecordKUDiR-dokumentet.

2. Överföring av 1C-uppdateringsändringar

För att överföra ändringar öppnar jag 2 konfiguratorer - i en kör jag jämförelser och plockar upp ändringar, och i den andra gör jag förbättringar.

Nästa steg är att överföra ändringarna direkt. Tänk på de grundläggande teknikerna för att uppdatera icke-standardiserade konfigurationer.

3. Skillnader i moduler

En ganska enkel, men mycket ansvarsfull operation - vi överför helt enkelt moduler från en ny version till en gammal. Om koden kommenteras bör det inte vara några problem:

4. Jämförelser av formulär och layouter

Här är processen mycket mer komplicerad. Du måste fånga de minsta ändringarna på formulären. Jag rekommenderar att du skapar en detaljerad rapport om skillnaderna med en grafisk reflektion:

När du har överfört alla objektändringar från den nya konfigurationen, starta jämförelsen och slå samman igen, ta bort objekten som du ändrade manuellt för jämförelse.

Atypisk uppdatering av den modifierade 1C-konfigurationen är klar!

Notera! Om du inte vet hur man programmerar i 1C 8 är chansen att framgångsrikt uppdatera en icke-standardkonfiguration extremt liten. Du kommer att spendera mycket tid och sluta med en konfiguration som inte ens körs. Jag rekommenderar att du kontaktar för snabb hjälp.

Den här artikeln kommer att prata om att uppdatera en icke-standardiserad 1C-konfiguration (utgåvor 8.2 och 8.3), och spara alla ändringar som du (eller andra utvecklare) har gjort till en typisk 1C 8-konfiguration.

Betrakta ett exempel på en konfigurationsuppdatering Bokföring 2.0 med icke-standardiserade förändringar i moduler, roller, eventprenumerationer, utbytesplaner m.m. De fall som diskuteras här kommer inte att vara så svåra att uppdatera, jag ska bara visa dig hur du uppdaterar med dem så att du kan lista ut dina fall.

Uppdatering av en icke-standardiserad 1C-konfiguration steg för steg-instruktioner

Överväg steg för steg algoritmen för uppdatering av 1C 8-konfigurationen. Denna algoritm är universell, dess första elva steg beskriver processen för att uppdatera vilken typisk 1C 8-konfiguration som helst, och alla punkter tillsammans beskriver uppdatering av en icke-standardiserad 1C 8-konfiguration:

• Ladda ner konfigurationsuppdateringsfilen från webbplatsen users.v8.1c.ru eller hämta den från andra tillgängliga källor (till exempel från ITS-disken);
• Packa upp och installera 1C 8-uppdateringsfilen i valfri mapp på din hårddisk;
  
• I mappen med releasenummer 1C 8, hitta filen 1cv8.cfu - det är denna fil som innehåller konfigurationsuppdateringar;
  
  
• Springa 1C:Företag i läge Konfigurator;
• Gå till menyn Konfiguration -> Support -> Uppdatera konfiguration.
  
  
• I det öppnade fönstret "Konfigurationsuppdatering" ställer du in flaggan på objektet Väljer en uppdateringsfil och tryck på knappen Ytterligare(om du vill kan du använda första stycket Sök efter tillgängliga uppdateringar och sök efter uppdateringsfiler automatiskt) ;
• I fältet "Ange uppdateringsfilen" väljer du .cfu-filen från mappen med releasenummer. Observera att du inte kan uppdatera konfigurationen av 1C 8-basen för någon version. För varje uppdateringsfil finns en lista över utgåvor som den är avsedd för. Därför kan du behöva installera flera uppdateringsfiler i följd;
• I nästa fönster kommer du att se en beskrivning av denna uppdatering. Du kan också se vilka versioner av konfigurationen den här filen är avsedd för uppdatering. Klicka på knappen Fortsätt uppdatera;
• Om denna version av konfigurationen inte kan uppdateras med den valda filen, kommer du att få ett fönster med en ledtråd om vilka versioner som ska installeras;
• Om den valda filen är lämplig för uppdatering av konfigurationen kommer ett fönster med information om versionen av uppdateringen att visas. Klicka på knappen för att fortsätta uppdatera. OK;
  
• Därefter startar uppdateringsprocessen. Om din konfiguration är typisk, när den är klar, återstår allt som återstår att acceptera att ändra den nuvarande konfigurationen och köra 1C 8 i läge Företag;
• Om du uppdaterar en konfiguration med ändringar (icke-standard), så kommer ett fönster att jämföra och slå ihop de gamla och nya konfigurationerna efter att uppdateringsprocessen är klar.

Uppdatering av en icke-standardkonfiguration 1C analys av ett exempel

Låt oss gå vidare till en detaljerad analys av den korrekta uppdateringen av en icke-standardiserad 1C 8-konfiguration. Hela problemet med att uppdatera en sådan konfiguration är att tredjepartsändringar har gjorts i typiska metadataobjekt (vanliga moduler, roller, dokument, kataloger) , etc.). Det är nödvändigt att se till att alla dina ändringar förblir på sin plats, säkra och sunda, men samtidigt tillämpades alla ändringar av 1C-företaget som finns i uppdateringsfilen. För detta, när du uppdaterar den ändrade konfigurationen, visas ett jämförelsefönster. Huvudkonfiguration(med dina ändringar) och Ny leverantörskonfiguration(uppdaterad typisk konfiguration).

Det här fönstret har två kolumner som var och en innehåller ett metadataträd. Den första visar aktuell databaskonfigurationsmetadata och den andra visar uppdaterad leverantörskonfigurationsmetadata (uppdaterad generisk konfiguration). Ändrade objekt markeras med gröna pennor, de typiska metadataobjekten som du har ändrat är markerade i den första kolumnen och de typiska metadataobjekten som har ändrats av uppdateringen är markerade i den andra kolumnen. För att korrekt uppdatera en icke-standardiserad 1s-konfiguration måste du alltså hitta alla metadataobjekt som har ändrats av både dig och uppdateringen (det vill säga ändrat två gånger).

För att göra detta, klicka på knappen längst ner i fönstret. Filtrera, sätt flaggan i det öppnade fönstret och tryck OK.

Nu kommer bara de objekt vi behöver att synas i jämförelsefönstret, vilket avsevärt förenklar uppdateringsprocessen. Det bör noteras att om nya icke-standardiserade dokument, kataloger, roller, moduler, etc. läggs till i din konfiguration, kommer uppdatering av konfigurationen inte att skriva över dem, de kommer att förbli på sin plats och ingenting kommer att hända med dem. Problemet är bara modifierade generiska objekt.

För att korrekt uppdatera olika metadataobjekt behöver du ditt eget tillvägagångssätt, så låt oss titta på olika situationer med enkla exempel. Jag noterar också att uppdatering av kraftigt omskrivna konfigurationer är en svår uppgift och kräver maximal omsorg och koncentration.

Uppdatering av delad modul.

• Tänk på ett exempel: Till en gemensam modul Konfiguration av versionskontroll du gjorde följande ändringar:
  • I procedur CheckConfigVersion() kommenterade raden: //OpenFormModally("CommonForm.DeprecatedConfigurationVersion", Parametrar);
  • Vi lade till vår egen procedur i modulen med namnet MyTestProcedure().

  Vid uppdatering har denna modul ändrats, genom att sätta ett filter på två gånger ändrat i jämförelsefönstret kommer vi att se att det finns med i listan.
  
  Låt oss ta en närmare titt på det här fönstret och förstå vilken information vi kan få från det. Först kan vi se att den gemensamma modulen har ändrats i både huvudkonfigurationen och den uppdaterade leverantörskonfigurationen, vilket indikeras av de gröna pennorna i båda kolumnerna. För det andra, i den första kolumnen ser vi en kryssad ruta bredvid namnet på den gemensamma modulen, den indikerar att modulerna kommer att slås samman (vad vi har ändrat och standarden uppdaterad). För det tredje, i den sista kolumnen ser vi i vilket läge modulerna kommer att kombineras. I det här fallet är värdet satt till: Ta från den nya leverantörskonfigurationen, detta innebär att våra ändringar kommer att skrivas över helt och att ändringarna som görs av uppdateringen kommer att tillämpas fullt ut.

  Andra sammanslagningslägen erbjuder partiell sammanslagning av moduler, med olika prioriteringar. Men jag rekommenderar starkt att du inte använder dessa lägen, eftersom din modul efter det kan sluta med en naturlig "gröt": några av dina ändringar kommer att skrivas över och vissa typiska ändringar kommer inte att tillämpas. Så ändra värdena i kolumnen Sammanfogningsläge... vi kommer aldrig att göra det. För det fjärde, om du avmarkerar kryssrutan i den första kolumnen mittemot modulen, kommer sammanslagningen inte att utföras och modulen kommer att förbli som den var före uppdateringen. Baserat på ovanstående punkter finns det två sätt att uppdatera den gemensamma modulen:

  • Skriv över dina ändringar genom att ställa in standardinställningarna. Gör sedan manuellt de överskrivna ändringarna i den uppdaterade modulen;
  • Uppdatera inte modulen och gör typiska ändringar manuellt.

  Mekanismer för konfigurationsjämförelse

  För att jämföra ändringar i en modul kan du använda följande inbyggda mekanismer i fönstret för konfigurationsjämförelse-sammanslagning:

  • Se modulskillnader. För att göra detta, högerklicka på modulen i jämförelsefönstret, välj objektet Visa skillnader i moduler... Därefter öppnas ett moduljämförelsefönster där du kan se exakt vilka procedurer som skiljer sig åt i modulen som du uppdaterade och ändrade. Den övre delen av skärmen är uppdelad i två kolumner: till vänster finns en lista över de huvudsakliga konfigurationsprocedurerna som har ändrats, och till höger finns en liknande lista med procedurer för den uppdaterade typiska konfigurationen. Den nedre delen av fönstret är också uppdelad i två delar, enligt samma princip. Den visar koden för de valda procedurerna. Rader som endast finns i huvudkonfigurationen är markerade i blått. Rader som endast finns i den uppdaterade typiska konfigurationen är markerade i grönt. Rader som finns i båda konfigurationerna, men som inte matchar, är markerade i rött.
    
    
    
    
    
    
    
  • . Du kan också använda objektjämförelserapporten för att jämföra moduler. För att anropa det i jämförelsefönstret, högerklicka på modulvalsobjektet I fönstret som öppnas, i området Formatera, sätta flaggan Detaljerad. I rapporten som öppnas kan du se vilka rader i modulen som har ändrats och hur de ser ut i båda konfigurationerna.
    
    
    Trots att denna rapport ger all information om ändringarna är den inte bekväm att använda (åtminstone vid uppdatering av moduler). Två av dess modifieringar är mycket mer intressanta: O rapport om jämförelse av objekt i huvudkonfigurationen med leverantörens gamla konfiguration(endast ändringar gjorda av dig är synliga i denna rapport) och (endast de ändringar som gjorts i modulen av uppdateringen är synliga i denna rapport).
    
    
    
    Med hjälp av den första rapporten kan du se på hur många ställen dina ändringar har gjorts i modulen, detta gör att du snabbt kan hitta dem i fönstret Se skillnader i moduler. I den andra rapporten kan du se på hur många ställen en typisk uppdatering har gjort sina ändringar.

  Vi har sorterat ut alla verktyg som behövs för att uppdatera modulen. För att visa deras praktiska tillämpning, låt oss ta en steg-för-steg-process för att uppdatera modulen. Konfiguration av versionskontroll med ovanstående ändringar. Låt oss uppdatera modulen på två sätt:

  • Låt oss uppdatera modulen och skriva över ändringarna som gjorts i den. Vi kommer att ange dem manuellt efter uppdateringen;
  • Vi kommer inte att uppdatera modulen. Ändringar som tas emot i uppdateringen kommer att göras senare.

  Första sättet:

  • • Innan jag beskriver algoritmen noterar jag att vi överväger ett väldigt enkelt uppdateringsexempel så att beskrivningen inte tar mycket utrymme, utan uppdateringsprocessen i ett komplext fall består av exakt samma steg, även om det kräver mer koncentration och vård;
    • Innan vi uppdaterar konfigurationen, låt oss skapa ett textdokument. I den kommer vi att registrera de ändringar som måste göras manuellt efter uppdateringen. Data i ett textdokument bör presenteras på det mest begripliga sättet, det vill säga vara strukturerat. I vårt exempel kommer vi att skriva så här: 1. Vanliga moduler 1.1 Version ControlConfiguration
    • Låt oss hitta en gemensam modul Konfiguration av versionskontroll Modul. Högerklicka på den och välj O från snabbmenyn Rapport om jämförelse av objekt i huvudkonfigurationen med den gamla. Sätt flaggan i fönstret som öppnas Detaljerad. Jag satte också flaggan Utdata till textdokument, eftersom det är bekvämare att se förändringarna, men det här är redan en fråga om vana. Låt oss trycka på knappen OK. Rapporten som öppnas kommer att se ut så här:
      
      
    • Rapporten visar att två ändringar har gjorts i modulen (före varje ny ändring skrivs numren på raderna där den gjordes):
      • Rad 34 har ändrats, den kommenteras ut i huvudkonfigurationen, men inte i den gamla leverantörskonfigurationen;
      • En procedur har lagts till, i den gamla konfigurationen av leverantören är den tom på sin plats, men i huvudkonfigurationen är den det. Vi stänger inte rapporten, den kommer att vara användbar för oss;
    • Låt oss nu hitta den första skillnaden i moduljämförelsefönstret. För att göra detta, högerklicka på grenen igen Modul och välj objektet i snabbmenyn Visa skillnader i moduler... Eftersom radnumren (global numrering) inte är synliga i moduljämförelsefönstret, för att hitta den första ändringen, scrollar vi igenom alla procedurer i den övre halvan av fönstret. Vi vet också från rapporten att den första ändringen är förknippad med en radbyte, så vi letar efter texten markerad i rött. Den ändrade raden kan hittas i CheckConfigVersion()-proceduren.
      
      
    • Låt oss öppna textdokumentet som skapats för att registrera ändringarna. I stycket "1.1.1" skriver vi ner namnet på proceduren där ändringen ligger. Efter det måste vi ange den hittade förändringen i den så att vi enkelt kan hitta den i modulens text. För att göra detta kopierar jag vanligtvis inte en utan flera rader av proceduren i dokumentet på en gång, före och efter ändringarna. Men i det här fallet är proceduren liten och därför räcker det att kopiera den ändrade raden själv. Följande post kommer att erhållas: 1. Vanliga moduler 1.1 ConfigurationVersion Control 1.1.1 CheckConfigVersion //OpenFormModally("CommonForm.DeprecatedConfigurationVersion", Parametrar);
    • Låt oss nu öppna konfigurationsjämförelserapporten igen, titta på nästa ändring och även hitta den i moduljämförelsefönstret. Den här gången är det en ny procedur. Eftersom denna procedur är helt frånvarande i den gamla leverantörskonfigurationen, kommer dess text att markeras i blått:
      
      
    • Låt oss öppna textdokumentet som skapats igen för att registrera ändringarna. I stycket "1.1.2" skriver vi namnet på den tillagda proceduren. Efter det kopierar du hela texten i den tillagda proceduren dit. 1.1.2 MyTestProcedure Procedure MyTestProcedure() Export //Procedure Text EndProcedure
    • Konfiguration av versionskontroll en flagga sätts, vilket betyder att denna modul bör uppdateras och skriva över alla ändringar som gjorts;
      
    • Därefter måste du skriva ändringar av andra två gånger ändrade metadataobjekt i ett textdokument. Men eftersom vi i det här exemplet överväger en specifik gemensam modul, kommer vi att hoppa över detta steg;
    • Efter att arbetet med de två gånger modifierade objekten har slutförts, i jämförelse-/sammanfogningsfönstret, tryck på knappen Springa;
    • Om ett fönster visas med texten "Det finns objekt ändrade i huvudkonfigurationen ...", tryck på knappen Ja;
      
      
    • I nästa fönster Ställa in supportregler, ändra inga inställningar, utan klicka bara på knappen Ja;
      
      
    • Det sista meddelandet som visas är: "Konfigurationssammanslagning slutförd." Klicka på knappen OK;
      
    • Spara konfigurationen med hjälp av menyn Arkiv -> Spara, piktogram Spara(blå diskett) eller kortkommandon ctrl+s;
    • När konfigurationen har sparats, återställ de överskrivna moduländringarna. Hitta och öppna modulen i metadataträdet Konfiguration av versionskontroll;
    • Låt oss öppna ett textdokument där ändringar har gjorts i denna modul;
    • Punkt "1.1.1" specificerar proceduren CheckConfigVersion, hitta den i modulen och öppna den;
    • Textdokumentet anger att raden ska kommenteras bort: OpenFormModally("CommonForm.DeprecatedConfigurationVersion", Parametrar);

      Hitta den i modulen och ställ in kommentaren;

    • Punkt "1.1.2" specificerar proceduren Min testprocedur, som ska läggas till modulen. Kopiera det från ett textdokument och klistra in det i slutet av modulen;
    • Vi sparar konfigurationen på något av ovanstående sätt;
    • Konfigurationsuppdateringen är klar på detta, det återstår bara att uppdatera konfigurationen med hjälp av nycklarna F5 eller F7 eller motsvarande ikoner, och i 1C:Enterprise-läge, bekräfta lagligheten av uppdateringen;
      
      
  • Andra sättet:
    • Den andra metoden upprepar helt den första, förutom att den agerar från motsatsen. Därför kommer jag att beskriva det kortfattat;
    • Vi skapar ett textdokument med samma struktur;
    • Låt oss skapa en rapport Rapport om att jämföra objekt för den nya leverantörskonfigurationen med den gamla leverantörskonfigurationen;
    • Med hjälp av den genererade rapporten och moduljämförelsefönstret skriver vi ut ändringarna som införts av den nya leverantörskonfigurationen i ett textdokument;
    • I fönstret för att jämföra / slå samman konfigurationer kontrollerar vi det bredvid modulen Konfiguration av versionskontroll FLAGGA AV. Detta innebär att denna modul inte kommer att uppdateras;
    • Uppdatera konfigurationen, gör ändringar från textdokumentet till modulen Konfiguration av versionskontroll.

Uppdatering av utbytesplan.

Tänk på ett exempel: som en del av en utbytesplan Efter Organisation du har inkluderat guiden Extern bearbetning. Vid uppdatering av den icke-standardiserade konfigurationen 1c har sammansättningen av denna utbytesplan ändrats och vi står inför uppgiften att korrekt uppdatera utbytesplanen utan att förlora vare sig standardändringarna eller vår egen. Verktygen som används för att jämföra ändrade metadataobjekt har beskrivits i detalj i de föregående styckena, så för det här fallet kommer allt att beskrivas kortfattat.

Överväg stegen för att uppdatera sammansättningen av utbytesplanen Efter Organisation med följande ändringar:

• Lägg till nya rader i textdokumentet som skapades vid uppdatering av den gemensamma modulen: 2. Utbytesplaner 2.1 Efter organisation
• Låt oss hitta en utbytesplan Efter Organisation i jämförelse-/sammanfogningsfönstret utökar du det till en gren Sammansättning. Jag noterar att i utbytesplanen kan modulen även ändras av dig, den ska uppdateras enligt reglerna som beskrivs för den allmänna modulen. I det här fallet är vi intresserade av att uppdatera utbytesplanens sammansättning;
  
• Som i fallet med den gemensamma modulen, kan sammansättningen av utbytesplanen antingen uppdateras, sedan lägga till dina ändringar manuellt, eller inte uppdateras, lägga till typiska ändringar manuellt. Om det finns fler av dina förändringar i sammansättningen än typiska, är det bättre att uppdatera det andra sättet, om det är färre, då det första. Du kan se vilka ändringar som är fler med samma rapporter:
  
• I vårt exempel finns det mer typiska ändringar, så vi kommer att skriva ut våra ändringar i ett textdokument: 2. Utbytesplaner 2.1 Efter organisation - *** Kataloger - --> Katalog Extern bearbetning
• Kontrollera att kryssrutan bredvid utbytesplanen är markerad i fönstret för jämförelse/sammanslagning Efter organisation;
• Vi sparar konfigurationen;
• Efter att konfigurationen har sparats kommer vi att återställa de överskrivna ändringarna i utbytesplanen. Hitta och öppna utbytesplanen i metadataträdet Efter organisation;
• I avsnitt "2.1" i textdokumentet anges en uppslagsbok Extern bearbetning, hitta den i metadataträdet för utbytesplanens sammansättning och ställ in flaggan som indikerar katalogens deltagande i utbytet;
  
  
• Spara och uppdatera konfigurationen;

Uppdatera ett eventprenumeration.

Tänk på ett exempel: till en källa för evenemangsprenumeration Innan du tar bort katalog för Exchange genom att arrangera du har inkluderat guiden Extern bearbetning. Vid uppdatering har sammansättningen av källorna ändrats, uppgiften liknar de tidigare - att uppdatera den icke-standardiserade 1c-konfigurationen korrekt.

Låt oss ta en titt på att uppdatera sammansättningen av händelseprenumerationskällor med de angivna ändringarna steg för steg:

Uppdaterar roller i 1C

Innan du börjar prata om att uppdatera roller i 1C 8, skulle jag vilja notera att det är bättre att inte ändra typiska roller, det finns inget behov av detta, och att uppdatera en icke-standard 1c-konfiguration är också mycket svårt. Om du slutför en typisk konfiguration och lägger till dina dokument, kataloger, etc. till den, skapa din egen roll (eller flera, beroende på situationen), där du inkluderar nya metadataobjekt. Om du inte gör detta kommer det med tiden att bli väldigt svårt för dig att uppdatera typiska roller (och det är omöjligt på en timme), eftersom de förändras mycket i nästan varje utgåva och konfigurationsjämförelserapporter kanske inte ser särskilt tydliga ut.

Men ändå finns det ofta fall när rollen redan har ändrats, och mer än en gång, men det finns ingen tid att ta reda på varför och varför. Tänk därför på ett exempel: i en typisk roll Revisor som referens Skattemyndigheter rättigheterna att läsa och se har lagts till, samtidigt som uppdateringen av uppsättningen av rollrättigheter har ändrats.

Överväg att uppdatera rollen steg för steg:

• Låt oss hitta en roll Revisor i jämförelse-/sammanfogningsfönstret utökar du det till en gren Rättigheterna;
  
• I det här exemplet är det bara en förändring av rollen, men så är det vanligtvis inte. Därför är det mycket lättare att inte uppdatera rollen, utan att göra standardändringar manuellt;
• Låt oss bilda Rapport om att jämföra objekt i den nya leverantörskonfigurationen med den gamla leverantörskonfigurationen. Vanligtvis finns det mycket information i den, men allt behövs inte för att uppdatera:
  
• Antingen har nya metadataobjekt lagts till, eller så har rättigheterna ändrats för gamla:
  • De tillagda objekten ser ut så här: - -->

    När man lägger till ett nytt objekt visar rapporten inte information om vilka rättigheter som måste ställas in för det. Därför kan du efter uppdateringen antingen se deras arrangemang i leverantörens konfiguration eller installera alla tillgängliga.

  • De modifierade objekten ser ut så här: - ***Referenser - ***Skattemyndigheter - ***Behörigheter - ***Läs - ***Värde -->Tillåtet<--Запрещено - ***Просмотр - ***Значение -->Tillåten<--Запрещено

    Den beskriver vilka rättigheter som har ändrats;

• I vårt exempel finns det bara en rad användbar information i jämförelserapporten, vi lägger till den i textdokumentet: 4. Roller 4.1 Revisor - --> Objekt - Reglerad rapportstatistik Form 11HA

  I det här fallet kan du ange vilket metadataobjekt det är, men i det här fallet är det redan klart att rapporten;

• Avmarkera rutan bredvid rollen i fönstret för jämförelse/sammanslagning Revisor;
• Efter det är det nödvändigt att skriva ändringar av andra två gånger ändrade metadataobjekt i ett textdokument och uppdatera (processen beskrivs i detalj ovan);
• Vi sparar konfigurationen;
• När konfigurationen har sparats måste du göra typiska ändringar i rollen Revisor. Hitta och öppna den här rollen i metadataträdet;
• Paragraf "4.1" i textdokumentet säger att ett objekt har lagts till rollen RegulatedReportStatisticsForm11NA, hitta den i rollmetadataträdet, markera rutorna till höger Användande Och Se;
  
  
• Spara och uppdatera konfigurationen.

Den här artikeln om uppdatering av en icke-standardiserad 1C-konfiguration är klar. Om du har några frågor efter att ha läst, ställ dem gärna i kommentarerna! På begäran av läsare kan jag i nästa artikel prata om andra intressanta och komplexa aspekter av att uppdatera en icke-standardiserad 1C 8-konfiguration.

Personlig erfarenhet: hur man snabbt och kostnadseffektivt uppdaterar en ändrad konfiguration

Att uppdatera konfigurationen för flera utgåvor samtidigt är mycket farligt. Poängen är att efter varje konfigurationsuppdatering startas infobasuppdateringen i 1C:Enterprise-läge. Därför, om du bara uppdaterar den senaste versionen, kanske infobaser inte matchar den senaste konfigurationen. I artikeln delar Dmitry Rudakov, en specialist på Siberian Agrarian Group CJSC, sin personliga erfarenhet i en engångskonfigurationsuppdatering för 12 utgåvor.

Kontrollerar konfigurationsändringsläget

Låt oss föreställa oss en sådan situation. Utvecklarna av "Manufacturing Enterprise Management" (hädanefter kallad PPM) i release 1 (releasenummer nedan tilldelas villkorligt) till dimensionen (indikatorn) i beräkningsregistret, de tilldelade typen "DirectoryReference.Individual" med namnet " Enskild". I release 2 lade de till ytterligare en dimension - "Employee" med typen "ReferenceReference.Employees". När 1C:Enterprise lanseras aktiveras bearbetning som fyller i dimensionen "Anställd" på samma sätt som dimensionen "Individuell". Och sedan i release 3 tog "1C"-utvecklarna bort dimensionen "Individuell" och lämnade bara "Anställd". Om du uppdaterar konfigurationen från release 1 omedelbart till release 3 kan du rensa hela beräkningsregistret.

Och om konfigurationen stöds med möjlighet till förändring, och reglerad rapportering genereras i samma databas, så är det nödvändigt att uppdatera konfigurationen för varje release, vilket kan bli mycket dyrt i termer av mantimmar. Till exempel kan en uppdatering av en kraftigt modifierad "SCP" för 1 version ta 30 timmars arbetstid för en erfaren specialist.

Innan du fortsätter med uppdateringen måste du därför bestämma: arbetar du i en typisk konfiguration med möjlighet till förändring eller i en konfiguration utan möjlighet till förändring? För att göra detta, gå till konfiguratorn, där i menyn, följ stegen "Konfiguration - Support - Supportinställningar".

Figur 1. Anropar inställningsfönstret för konfigurationssupport

Om den är inställd på "På support", är denna konfiguration typisk, och om "Changeable is enabled" - konfigurationen ändras troligen (åtminstone en sådan möjlighet ingår). Det tredje tillståndet är "Konfigurationen är utfasad". De olika konfigurationstillstånden visas i figurerna 2, 3, 4.

Ris. 2. Typisk konfiguration utan möjlighet till ändringar

Ris. 3. Typisk konfiguration med ändring aktiverad

Ris. 4. Konfigurationen har tagits bort från supporten

Algoritm för att uppdatera ändrade konfigurationer

Nyligen stod jag inför uppgiften att uppdatera den ändrade konfigurationen "Trade Management", release 10.3.13.2. Konfigurationen har ändrats som ett resultat av sammanslagning med branschlösningen "BIT: Car Service Management 8" och har kontinuerligt förfinats under två år. Nu var konfigurationen tvungen att uppdateras till release 10.3.25.1, det vill säga 12 releaser. Jag har delat upp hela uppdateringsproceduren i flera steg.

Steg 1. Uppskattning av kostnaden och tidpunkten för förnyelseförfarandet

Innan jag påbörjade självständigt arbete bestämde jag mig för att få en oberoende bedömning av experter inom detta område. Det enda företaget som har möjlighet att uppdatera ändrade konfigurationer med automatiserade metoder är 1C-IzhTiSi LLC. Jag kontaktade det här företagets specialister med en begäran om att uppskatta kostnaden för att uppdatera min konfiguration. För att uppskatta tiden och kostnaden för arbetet tillhandahöll jag den nuvarande konfigurationen som behöver uppdateras. En dag senare fick jag ett mejl med en rapport.

Rapportera om resultatet av bedömningen av kostnaden och tidpunkten för konfigurationsuppdateringen:

Konfiguration: Trade Management Revision 10.3
Aktuell konfigurationsversion: 10.3.13.2
Uppdatering till version: 10.3.25.1
Antal uppgraderbara moduler: 1 847
Antal kontrollsläpp: 8

Resultaten av bedömningen överraskade mig, eftersom priset per aktie angavs på företagets webbplats - 1000 rubel. för en versionsuppdatering. Kommentar "1C-IzhTiSi":

"Kostnaden för uppdatering för varje missad utgåva är inte högre än 2 000 rubel. Nu finns det en kampanj, så kostnaden överstiger inte 1 000 rubel. Men det slutliga priset för tjänster bestäms av resultaten av en bedömning av arbetskostnader för uppdatering och kan vara lägre än 1 000 rubel per release."

Jag klargjorde också hur de utgåvor som behövs för uppdateringen valdes ut. Som svar på min fråga fick jag en skärmdump där detta tydligt visades (fig. 5). Kolumnen Versionsnummer anger vilken konfigurationsversion du vill uppgradera till. Kolumnen "Uppgradera version" anger vilken version du kan uppgradera från. Som ett resultat av utvärderingen reducerades antalet nödvändiga uppdateringar till 9.

Ris. 5. Urval av utgåvor som måste användas för att uppdatera konfigurationen korrekt

Efter att ha studerat 1C-IzhTiSi-rapporten beräknade jag den personliga tiden som spenderades på samma mängd arbete. Varje uppdateringsprocedur tar mig cirka 6 timmar. Därför är den totala tidsåtgången 56 (9x6) arbetstimmar, det vill säga cirka sju arbetsdagar. Dessutom finns det en möjlighet att några brister kommer att avslöjas efter uppdateringen: till exempel kommer användaren att klaga på att de konfigurationsändringar han behöver går förlorade, och då kommer tidskostnaderna att öka allvarligt. Samtidigt erbjuder specialisterna på företaget "1C-IzhTiSi" att göra hela mängden arbete på tre till fyra arbetsdagar. Så jag bestämde mig för att använda deras tjänster.

Nu ska jag kort förklara exakt vad som ändrades i konfigurationen.

Kraftigt modifierade föremål. Detta är objekt där många typiska egenskaper har ändrats. Justeringarna är komplexa. Detaljerna för objektet läggs till i tabelldelen, som visas i objektets form och i listformuläret. Lade till hanterare för ytterligare detaljer i formulär. Den typiska mekanismen för att posta ett dokument eller registrera en uppsättning rörelser för registret har ändrats.

Kraftigt modifierade dokument:
"Beställning till leverantören";
"Förflyttning av varor";
"Krav-faktura";
"Mottagande av varor och tjänster".

Kraftigt modifierade register:
"Sändningar av varor i lager";
"Varor i lager".

Betydligt modifierade objekt. Objekt där detaljer har lagts till, antingen formerna för objekten eller modulerna för objektet har ändrats (som regel är dokumentet inte maskinskrivet).
Dokument "Inkommande kontantorder";
Register över information "Komponentnomenklatur";
Register över information "Avskrivningsvaror";
Allmänna moduler.

Lite ändrade föremål. I objekten har endast formulären ändrats och detaljer har lagts till.

Uppslagsverk:
"Typer av nomenklatur";
"Motpartsavtal";
"Entreprenörer";
"Nomenklatur";
"Nomenklaturpristyper";
"Ett antal informationsregister".

Ändrade prenumerationer på evenemang, layouter, roller, vanliga moduler i avsnittet "Allmänt". Nästan allt har förändrats genom ett branschbeslut.

Steg 2. Ta bort konfidentiell information

Innan de tillhandahåller 1C-IzhTiSi-anställda en informationsbas för testning är det nödvändigt att radera konfidentiell information i den. För sådana fall rekommenderar 1C att man använder behandlingen "Ändring av konfidentiell information", som inte är särskilt allmänt känd.

Behandling "Ändring av konfidentiell information" är avsedd för selektiv ändring eller rensning av information i infobasen.Bearbetning kan användas för att förbereda en infobas innan den skickas vidare för testning, där det är nödvändigt att dölja (rensa, ändra) viss information.

Bearbetar ChangePrivateInformation.epf finns på ITS-disken i katalogen 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Denna bearbetning kan också laddas ner från länken: http://its.1c.ru/db/method81#content:1644:1.

Naturligtvis är konfidentiell information i varje företag olika, men jag uppmärksammar dig på de uppgifter som med största sannolikhet behöver ändras:

• Kataloger: Individer, Kontaktpersoner, Kontaktpersoner för motparter, Motparter, Pristyper.
• Informationsregister: Passuppgifter för en individ, fullständiga namn på individer.

Din lista kommer förmodligen att bli längre, men dessa är de vanligaste uppgifterna. Att ändra dem kommer sannolikt inte att påverka möjligheten att testa din infobas. Du kan också radera alla de objekt som tjänsteföretaget inte ska arbeta med genom gruppbearbetning.

Steg 3. Få resultatet av uppdateringen

Tre dagar senare fick jag cf-filer och omfattande instruktioner för att installera dem. För kontrollreleaser tillhandahålls cf-filer som inte kan användas för användararbete, eftersom endast metadata har uppdaterats i dem. De är endast avsedda att korrekt uppgradera till den senaste versionen.

Som ett resultat av det utförda arbetet kan jag säga att alla ändringar i konfigurationen sparades; när de ses visuellt behöll alla objekt som ändrades sina egenskaper och skillnader från den typiska konfigurationen. Under driften rapporterade ingen av användarna att några ändringar gick förlorade.

Som ett resultat av uppdateringen identifierade jag två små uppgifter för en oberoende lösning.

Först. På grund av att uppdateringen utförs med hjälp av mekanismen "Jämför, sammanfoga" är databaskonfigurationen verkligen uppdaterad, och uppdaterad korrekt, utan tekniska risker på grund av kontrollreleaserna. Leverantörskonfigurationen uppdateras dock inte. Naturligtvis kommer en tekniskt kompetent specialist att komplettera detta arbete utan problem, men jag bad 1C-IzhTiSi att skicka mer fullständiga instruktioner för uppdatering. I enlighet med det kan även en oerfaren specialist uppdatera.

Andra. Som ett resultat av uppdateringen förblir alla objekt stödda med möjlighet till förändring, vilket också kan vara en indirekt nackdel. Om du behöver använda dessa tjänster åt gången måste du sätta alla objekt på support igen. Hittills kan jag bara göra detta genom att räkna upp alla metadataobjekt. Tyvärr, medan denna process utförs manuellt, men i framtiden kommer den att automatiseras.

Utöver de två nämnda uppgifterna upptäcktes en liten brist, som i princip inte påverkar kvaliteten på uppdateringen och som sällan visar sig. Som ett resultat av uppdateringen sammanfaller kodraderna för den ursprungliga konfigurationen och den uppdaterade visuellt, men av någon anledning läggs mellanslag till i slutet av raderna. Detta är en nackdel, eftersom det ökar mängden modifierad kod något. Och i fallet med ytterligare manuella uppdateringar skulle det vara bättre att inte ha sådana kodsektioner. På fig. 6 visar ett exempel före uppdateringen, och i fig. 7 är ett exempel efter uppdateringen.