Uppdatera en icke-standardkonfiguration 1c steg för steg instruktioner. Personlig erfarenhet: hur man snabbt och kostnadseffektivt uppdaterar en ändrad konfiguration. Hämta en leverantörsfil

Att uppdatera en icke-standardplattform är mycket svårt. Vi kommer att titta på hur man uppdaterar en icke-standardiserad 1C-konfiguration och beskriver en steg-för-steg-lösning på de svårigheter som uppstår.

Som i inte typisk konfiguration 1C för att uppdatera.

Allmänna begrepp

Vid uppdatering (uppdatering, engelska) en icke-standardiserad plattform, påverkar ändringar alltid elementen i den typiska konfigurationen (konfiguration, engelska) för leverantören.

Databasen (DB) innehåller upp till tre typer av konfigurationer:

själva databasen - logiska algoritmer fungerar med den;
fungerar (den så kallade main, ConfigOR) - som vi regelbundet ändrar;
leverantörskonfiguration (ConfigP - på grundval av detta skapas både arbets- och databaskonfigurationen av användaren.

Om programmet tas bort från supporten kommer det inte längre från leverantören. Men då är ökningen av arbetskostnaderna för uppdatering oundviklig. Överväg att uppdatera en icke-standard 1C-konfiguration. Ett exempel skulle vara PPM-plattformen (Manufacturing Enterprise Management).

Blandning

I det första steget måste du ta bort skillnaderna mellan den fungerande och den medföljande konfigurationen. Detta kommer att minska utvärderingen av de förbättringar vi tidigare har infört. Inkonsekvenser mellan dem uppstår när främmande filer (inte från det medföljande distributionspaketet) användes under uppdateringen eller när uppdateringsmetoderna skilde sig från de vanliga.

Versionsjämförelse

Vi kontrollerar versionsnumren (fungerar och levereras). Den första är markerad i "Konfiguration" / "Öppna" / "Redigera" / "Egenskaper". I avsnittet Utveckling/Version. Andra i "Configuration"/"Support"/"Support Setting"/"Version":

Om siffrorna stämmer överens kan du hoppa vidare till Hämta en fil genom en uppdatering.

Nästa steg visar hur man matchar drift- och leverantörskonfigurationen. För att sätta på stöd de objekt som har tagits bort eller lagts till av användaren utan stöd. För detta:

Spara konfigurationen (fungerar)

Låt oss spara ConfigOR till en fil med ett namn, till exempel work.cf. För att göra detta, välj "Konfiguration" / "Spara ...".

Hämta en leverantörsfil

För att matcha ConfigOR med ConfigP behöver du en cf-fil från leverantörens distributionskit (av samma version). Som standard kommer det att vara i C:/Program Files/1cv81/tmplts. Låt oss kontrollera närvaron av den nödvändiga cf-filen i malltabellen. Vad händer om den nödvändiga leverantörskonfigurationsversionsfilen inte finns? Då måste du skapa en tom databas från den gamla, uppdatera den till den version som krävs och först därefter använda den.

Få en fil via uppdatering

För att utföra uppdateringen av cf-filen ConfigP väljs kommandot i menyn: "Konfiguration / Support / Uppdatera ... / Filval / Klar / Kör" (sekventiellt i bilderna):

För att lösa det måste du avmarkera objektet för radering i leverantörens konfiguration. Sedan, efter borttagning, utför vi jämförelsen igen - klicka på knappen "Uppdatera" i uppdateringsfönstret.

Återställ inställningar

En del av de förlorade inställningarna återställs genom att slås samman med den tidigare sparade work.cf-filen. För att göra detta, välj "Konfiguration / Jämför, sammanfoga ... fil".

Spara och justera

För att spara ConfigOR och uppdatera databasen, välj "Uppdatera...DB" i menyalternativet "Konfiguration". Här möter vi ett nytt problem:

Anledningen till detta var troligen att dessa objekt kopierades från ConfigP eller att de raderades av leverantören och senare lades till nya under samma namn. Dock med andra identifierare. Som ett resultat dök det upp föremål med samma namn, men med olika identifikationsnycklar.

Roller kan helt enkelt tas bort, eftersom de inte har ändrats. Behovet måste döpas om, till exempel, till OrderReserve1. Och efter uppdateringen gör du värdena från det omdöpta till det skapade. Ännu ett uppdateringsproblem. Hur är det med formulär?

Från figuren kan du se att ListForm togs bort av leverantören och sedan lades till igen under samma namn. Du måste markera båda för uppdatering och klicka på "Execute".

Om ett meddelande utfärdas under uppdateringen om närvaron av länkar till objekt som ska raderas, måste du, utan att stänga formuläret, rensa länkarna till det i egenskaperna för själva objekten. Här finns det i registret fastigheter. Välj sedan uppdateringsalternativet i uppdateringsformuläret, markera registeregenskaperna för uppdatering nu och klicka på "Kör" igen.

Spara ändringar i arbets- och uppdatering av databaskonfigurationen: "Konfiguration / Uppdatera ... DB". Överföring av värdet av attributet OrderReserve1 till OrderReserve utförs genom extern bearbetning av 1C:Enterprise-läget.

Basförberedelse

Baserat på resultaten av informationen upprättar vi två identiska databaser. Det första (huvudsakliga) är vårt önskade resultat. Den andra (hjälp) är för att utföra förberedande åtgärder. När det gäller filversionen kopierar vi dem helt enkelt till katalogen och ansluter dem till IB-listan, med alternativet klient-server gör vi uppladdningen/nedladdningen.

Jämförelse

Efter att ha öppnat båda databaserna med konfiguratorn kommer vi att göra en trevägsjämförelse. Vi använder den nya ConfigP-filen för detta - "Konfiguration / Support / Uppdatering ... / Filval ... / Klar":

Jämförelse av fungerande, gamla och nya leverantörskonfigurationer ger oss en lista över ändrade objekt genom filtret "Visa egenskaper ändrade två gånger". Med dem måste du först och främst lösa problemet:

Vid denna tidpunkt avbryts arbetet med hjälpbasen tills hela processen är slut, knappen "Kör" är inte längre nedtryckt. Vi fortsätter att arbeta i huvuddatabasen med den resulterande listan med två gånger ändrade objekt. Om du går med på uppdateringen kommer tidigare gjorda förbättringar att gå förlorade. Därför krävs det för vart och ett av objekten att fatta ett beslut - hur det kommer att ändras.

Vi kommer att göra en preliminär bedömning endast för att minska arbetet i framtiden. Om det finns fler ändringar av elementet i den nya ConfigP lämnar vi leverantörsobjektet. Vi sätter en bock. Överför ändringar från ConfigOR. Om det finns fler ändringar av elementet i arbetskonfigurationen lämnar vi en instans av ConfigOR-objektet. Vi tar bort dawn. Låt oss överföra ändringarna från ConfigP. Moduler måste jämföras procedurmässigt. För att göra detta, tryck på knappen som i bilden:

Markera rutorna för att ange procedurer och funktioner som ska ersättas eller raderas:

Nu måste du duplicera statusen för kryssrutorna i den extra databasen. I huvudet - klicka på "Kör". Vid det här laget får vi en nästan färdig konfiguration.

Efterföljande jämförelser utförs igen i hjälpdatabasen. Vi hittar de tidigare gjorda ändringarna genom ytterligare jämförelse av den gamla ConfigP med ConfigOR - "Configuration / Compare ...":

På samma sätt jämför vi den gamla ConfigP med den nya. Om det inte finns någon ny fil kan den nu tas från huvuddatabasen.

Så två gånger ändrade objekt tas emot. I huvuddatabasen har en nästan färdig konfiguration mottagits. Det måste hantera två gånger ändrade element.

VIKTIG. Vid analys bör användaren inte vara intresserad av skälen till att göra vissa ändringar, utan av deras konsekvenser. Det vill säga, det viktigaste är behovet av att bevara funktionaliteten. Kanske kommer detta inte att kräva överföring av ändrade linjer, utan en fullständig omarbetning av koden för den nya ConfigP.

För att fatta ett beslut räcker det att jämföra formulär, tabeller och objektmoduler. Ibland presenteras uppgifterna i rapporterna på ett sådant sätt att du inte snabbt kan fatta ett beslut. I detta steg uppstår förlusten av förbättringar om ändringarna gäller objektattributen av den sammansatta typen.

I en jämförelserapport ges olika data i form av en lista, från vilken det inte framgår vilka typer av data som har lagts till / tagits bort. Om antalet rader i rapporten når tvåhundra, verkar processen med "manuell" jämförelse vara ganska tidskrävande (cirka femtio timmar).

Minskning av arbetsintensiteten uppnås genom att till exempel använda konfigurationen "Jämförelse av celler" från företaget Inform Service. Den är tillgänglig för lansering i 1C:Enterprise-läge och presenterar jämförelserapportdata i en bekväm form. Jämförelse utförs av kapaciteten hos 1C:

Arbetsschemat är enkelt. En jämförande objektrapport skapas i konfiguratorn. Sparad i en fil, till exempel Comparison Report.mxl. I dialogrutan 1C:Enterprise öppnas den och de jämförda cellerna indikeras (genom att dubbelklicka på höger musknapp på den valda cellen kalkylarksdokument). Genom att klicka på "Jämför" ges resultatet av jämförelsen, medan olika positioner markeras i färg.

Ytterligare instruktioner för åtgärder ser ut så här.

Nästa rapport sparas med samma namn.
Efter att uppdateringen är klar och ändringarna av standardkonfigurationen har överförts, utförs den syntaktiska kontrollen av modulerna och testning av driften av de ändrade objekten.
Efter framgångsrik testning kan processen anses vara avslutad. Det återstår att uppdatera utskriftsformulär, rapporter och bearbetning. I vissa fall kontrollera externa rapporteringsformulär.

Vi arbetar med 1C 7.7

Att uppgradera en typisk plattform till samma skapar vanligtvis inga svårigheter. Följ bara anvisningarna i instruktionerna. De finns i UPDATE.TXT i distributionskatalogen.

Dessutom finns det inga svårigheter om ytterligare redovisningselement läggs till plattformen (kataloger, konstanter, urval, rapporter, register, beräkningsloggar, etc.). De kommer att passa när plattformarna kombineras. De tillagda dokumenten kommer inte heller att införa disharmoni om det inte fanns några ändringar i skyltarna för att ange "baserat på" sådana tillagda dokument.

Det rekommenderas att köra uppdateringen på en snabb dator med mycket RAM. Med sin brist kan 1C vägra att träna några av funktionerna och "frysa". En stor mängd virtuellt minne löser inte detta problem.

Skapa en arkivkopia

För detta ändamål måste du använda alternativet: "Administration / Spara data ...". Det är bekvämt att ange namnet på arkivet och matcha det med datumet för skapande (till exempel ÅÅMMDD.zip).

Katalogberedning

För att fungera behöver du sex konfigurationsfiler (1cv7.md):

"WorkingNew" för att förbereda uppdateringen (resulterande md-fil);
"WorkingOld" för att spåra ändringar vid jämförelse och för att överföra inställningar till TypeNew_2;
Typiskt (gammalt) "TypeOld_1". På grundval av detta skapades tidigare en fungerande.
typer. (tidigare) "TypeOld_2". För att spåra förändringar i 1C-företaget i den nya standardversionen;
Sorts. (ny) "TypNy_1". Förbättringar av 1C-företaget i den nya versionen;
"TypeNew_2" för komplexa objekt.

Och fem körande konfiguratorer (alla utom "TypeNew_1").

Till en början är katalogerna identiska i par:

"Working New" och "Working Old";
"TypOld_1 och TypeOld_2";
"TypNy_1" och "TypNy_2".

Att kombinera element

Först jämför vi mellan 3 och 2, 4 och 5, 1 och 6. För att göra detta, välj var och en av de första i paret "Configuration / Association ..." och ange metadatafilen 1cv7.md för tvåa i paret. Ett formulär med ett träd med ändrade element kommer att visas på skärmen. Därefter är det nödvändigt att analysera resultaten av en parvis jämförelse av 3 med 2 och 4 med 5. Lämna för att kombinera elementen i de uppdaterade plattformarna (1 och 6), där det fanns förändringar från 1C (4 från 5), men återspeglades inte i 3 och 2. 1 och 4 måste kombineras i åsidosättande läge.

Övrig

Detta inkluderar kontoplan och användargränssnitt. Om det skett ändringar i kontoplanen måste den uppdateras i läget "Kombinera objekt" Working New tillsammans med Typ New_2. Efter att ha slagit samman gränssnittet söker den efter fel: duplicering av menyalternativ, duplicering av verktygsfält, inställningstecken för verktygsfält "Plats från en ny rad".

Nedladdningen utförs över nätverket eller på en server (föredraget). För det första ges endast tillgång till databasen. Och sedan laddas databasen genom konfiguratorläget. Före och efter nedladdningen arkiveras data (som beskrivs i början av avsnittet). Följ sedan instruktionerna i filen UPDATE.TXT. När nedladdningen är klar kan alla kataloger, förutom WorkingNew, raderas.

Vi hoppas att vår publikation hjälpte dig att hantera uppdateringen av den icke-standardiserade 1C-konfigurationen. Vi granskade detta med avseende på både den sjunde och åttonde versionen.

Lämna kommentarer, skriv om din erfarenhet av att uppdatera 1C.

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 tagits bort från support, 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 hela den nya sorten 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 i 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 formulär många skillnader. Detta beror på det faktum att när vi lägger till bara 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 det. 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 i kolumnen "Merge Mode" väljer du "Merge".

c) om vi valde "Kombinera"

formen kommer att vara någon ny, där det kommer både nya och gamla ändringar
våra förändringar kvarstår
nya ändringar dyker upp
om ett fält raderades och ett annat fält sattes på 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 att 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 finns många instruktioner för att uppdatera de ändrade typiska konfigurationerna för 1C-plattformen. Därför, för att inte öka essensen, kommer jag inte att helt beskriva hela processen. Dessutom - det antas att denna text är för en person som redan har uppdaterat de ändrade konfigurationerna och känner till huvudpunkterna och "fallgroparna". Den här metoden förenklar bara denna process och erbjuder i huvudsak att använda automatisk jämförelse av konfigurationsändringar och ändringar i moduler på nivån för jämförelse av textfiler. Med detta tillvägagångssätt reduceras sannolikheten för fel ("överskrivning" genom uppdatering av viktiga ändringar på grund av ouppmärksamhet) förknippade med den "mänskliga faktorn" avsevärt.

ALLA konfigurationsuppdateringar börjar med IB-avlastning. Detta är den "gyllene regeln", detta måste alltid komma ihåg, detta måste göras med vilken metod som helst (även om de glömt att nämna det där). Därefter kan du gå på två sätt: antingen uppdatera i testdatabasen eller uppdatera i arbetsdatabasen. Här är den viktiga punkten följande: vanligtvis uppdateras inte de ändrade konfigurationerna för varje utgåva (eftersom det enkelt kan göras med standardversioner), utan för flera samtidigt, eftersom denna process är arbetskrävande. I den första metoden (uppdatering på en testbas) antas den slutliga överföringen av uppdateringen till arbetsbasen genom att ladda en cf-fil. I det här fallet kan fel relaterade till raderade detaljer uppstå (många artiklar kan hittas om detta). Så - det finns vissa risker, men under uppdateringen (som kan ta en hel dag eller till och med längre) kan användare säkert arbeta och ändra databasen. På det andra sättet (uppdatering på en fungerande databas) är dessa risker uteslutna, men nyckelanvändare kommer inte att kunna arbeta i denna databas under hela uppdateringens varaktighet. Det finns tillräckligt med diskussioner i forumen om vilken metod som är bra och om det är värt att överföra uppdateringen genom konfigurationsfilen. Jag kan bara säga: baserat på erfarenheten av att arbeta med den första metoden, liknande misstag hände inte när cf-filen laddades. I vilket fall som helst kan du återställa databasen med hjälp av en säkerhetskopia. Det är den första metoden som kommer att övervägas här, men detta påverkar inte kärnan i metoden och om så önskas kan du agera enligt den andra metoden med den föreslagna metoden.

Så – efter att ha distribuerat testbasen på en ny säkerhetskopia, gör vi successiva uppdateringar av utgåvor till den senaste. Efter varje release startar vi "Debug" för att spara ändringar i konfigurationen och omorganisera data. I alla dialogrutor klickar du på OK / Nästa / Acceptera / Ja / Fortsätt ...

Därför uppdaterade vi konfigurationen på testbasen till den senaste utgåvan, men vi måste kontrollera om vi har skrivit över några ändringar, och om vi har skrivit över dem måste vi överföra dem till denna utgåva. Nu börjar det roliga, så jag kommer att beskriva det steg för steg. Varje steg kommer att vara med en viss förklaring: det vill säga essensen beskrivs först, och sedan mer detaljerad beskrivning. Om essensen är tydlig kan beskrivningen utelämnas.

1. Vi sparar konfigurationsändringar FÖRE och EFTER uppdateringen i textfiler.Öppna arbets- och testbaserna i konfiguratorläget. Låt oss öppna konfigurationerna. Och i båda databaserna börjar vi bearbeta konfigurationsjämförelsen ("Konfiguration - Jämför konfigurationer ..."). VIKTIG: i båda databaserna, välj konfigurationer på samma sätt:

Dessutom sparar vi det enligt följande: i arbetsdatabasen (där konfigurationen är INNAN uppdateringen) - till en fil med slutet "gammal", och i testdatabasen (där konfigurationen är EFTER uppdateringen) - till en fil med slutet "ny".

2. Göra förlorade ändringar i en uppdaterad konfiguration. Vi går vidare till nyckelstadiet i metoden. Eftersom detta är huvudpoängen, så för en liten förklaring av vad som händer, lite av den matematiska delen. På 1C 7.7-plattformen var uppdateringsfilen en komplett konfiguration. Och uppdateringen i 1C 7.7 bestod i att ladda en ny konfiguration och omorganisera databasen för denna konfiguration. Så både konfigurationen och uppdateringen var i huvudsak samma md-fil. Till skillnad från 1C 7.7-plattformen, på 1C 8.x-plattformen: konfigurationen överförs via cf-filen, och uppdateringen överförs via cfu-filen. Skillnaden mellan dessa filer är att cf-filen innehåller alla konfigurationsobjekt, och cfu-filen innehåller endast de som ändras av den här uppdateringen. Och därför, vid uppdatering på 1C 8.x-plattformen, påverkas endast de konfigurationsobjekt som faktiskt har ändrats i den nya utgåvan. Som ett resultat, om ett sådant objekt ändrades av oss, kommer det efter uppdateringen att ersättas helt av ett standardobjekt, och vi kommer att behöva upprepa ändringarna som det hade före uppdateringen så att det här objektet innehåller både våra ändringar och ändringarna av den nya utgåvan, samtidigt . Men om konfigurationsobjektet vi ändrade inte påverkades av uppdateringen, kommer våra ändringar att finnas kvar i det efter uppdateringen. För att göra det lättare att förstå detta kommer jag att avbilda det i form av ett diagram:

Det här diagrammet visar en typisk konfiguration under ändring och uppgradering. Linjer är dess objekt (dokument, kataloger, bearbetningar och så vidare). Först (numrerad I) är bara en typisk konfiguration: alla objekt utan några ändringar. Sedan, under nummer II, ser vi redan en typisk ändrad konfiguration: vissa objekt har ändrats och dessa ändrade objekt är markerade med rött. Nummer III är en annan uppdatering för en typisk konfiguration: i själva verket innehåller den bara de objekt som påverkas av ändringarna i den nya utgåvan, som är markerade med grönt, men för tydlighetens skull har jag ritat klart alla andra objekt. Och vi behöver få en uppdaterad typisk konfiguration (avbildad i diagram I), men med ändringar i både diagram II och diagram III. På detta exempel- den här slutliga konfigurationen visas som nummer IV och innehåller ett objekt som har ändrats av både oss och uppdateringen. Resten av objekten vi ändrade förblev uppenbarligen orörda av den här uppdateringen. Nu är frågan: hur gör vi ALLA våra ändringar av objektet som påverkades av uppdateringen? Uppenbarligen måste vi ta två steg: för det första, hitta det här objektet, och för det andra, hitta platserna i det där våra förändringar ska vara och göra dem igen. Jag noterar att det naturligtvis kan finnas flera sådana objekt och det krävs att hitta och fixa alla. Så låt oss gå vidare till detta sista steg av uppdateringen. För tillfället bör vi ha en testdatabas öppen i Configurator-läget. Om resultatet av bearbetning av konfigurationsjämförelse eller något annat fönster fortfarande är öppet där, kommer vi att stänga dem alla för att inte bli förvirrade. Nästa - vi öppnar arbetsdatabasen i Configurator-läget (det var möjligt att stänga den under uppdateringen av testdatabasen) och kör en konfigurationsjämförelse där. Och jag kommer att lägga beskrivningen av de två sista stegen (hitta och fixa) i separata stycken:

2.1. Sök efter ett objekt med överskrivna ändringar. Det är dags att komma ihåg txt-filer med gamla/nya ändelser. Faktum är att dessa filer återspeglar alla konfigurationsändringar (i förhållande till den typiska) FÖRE respektive EFTER uppdateringen. Således, om vi skriver över någon ändring med en uppdatering, kommer den bara att finnas i filen "ReportComparison_old.txt". Det vill säga att sökningen efter de nödvändiga konfigurationsobjekten handlar om att jämföra dessa två filer. Vi kommer att jämföra dessa filer med hjälp av filhanterare Total befälhavare och dess inbyggda verktyg. Jag tror att det inte finns något behov av att förklara här vad Total Commander är, var man kan få tag på det och hur man använder det ... Jag kommer dock kort att beskriva de nödvändiga stegen av dess tillämpning här. Så vi startar Total Commander. Om gränssnittsspråket är engelska (huvudmeny, etc.), kan du ändra det till ryska: "Konfiguration - Alternativ ...", i dialogrutan, välj avsnittet "Språk" i den vänstra kolumnen, sök / välj "Russian (Russian)" i listan och klicka på "OK". Därefter, genom Total Commander, letar vi efter txt-filer med rapporter, väljer dem ("Infoga" eller "högerklicka") och startar filjämförelse: "Filer - Jämför efter innehåll ..." (i Engelskt gränssnitt: "Filer - Jämför efter innehåll..."). I fönstret som öppnas visas filernas innehåll till vänster respektive höger, knapparna "Nästa skillnad" / "Föregående skillnad" låter dig söka efter skillnader. Det här verktyget gör att du snabbt kan hitta föremålen som är intressanta för oss.

Kommentar: den omvända situationen kan också inträffa - skillnader dök upp i konfigurationen EFTER uppdateringen, som inte fanns där FÖRE uppdateringen. Detta innebär att uppdateringsversionen tog bort motsvarande objekt från konfigurationen. I princip kan dessa objekt helt enkelt hoppas över i våra korrigeringar, eftersom det inte skett några ändringar i dessa objekt.

2.2. Göra ändringar i uppdaterade objekt. Efter att vi har hittat ett objekt med överskrivna ändringar måste vi bestämma exakt var dessa ändringar fanns: i modulen (programtext), dialogrutan (på formuläret) eller andra inställningar. Här kommer jag att separera två fall: en förändring i en modul och alla andra ändringar. Låt oss överväga dessa två fall separat.

2.2.1. Ändringarna som skrevs över av uppdateringen fanns i modulen. Faktum är att detta är huvudfallet (detta händer mycket oftare) och det här fallet är bara i vårt exempel: ändringen togs bort i modulen "Redovisning för moms". Som vi redan nämnt ovan har vi ett fönster för jämförelse av konfigurationer öppet i Workbase Configurator. Vi letar efter föremålet vi behöver där. Faktum är att dess position i konfigurationsträdet beskrivs i vår textfil, nämligen: "GeneralModule.VAT accounting.Module". Det är precis vad vi letar efter i jämförelsefönstret. Vi utökar underordningsträdet tills vi hittar den nödvändiga modulen - på vänster kant mittemot den ska det finnas en grön penna, vilket indikerar att objektet har ändrats jämfört med leverantörens konfiguration. På den hittade raden, högerklicka och välj "Visa skillnader i moduler ...":

Därefter öppnas moduljämförelsefönstret:

Här överst finns förfaranden och funktioner, där det finns ändringar (i vårt fall är detta en procedur "Visa faktura till kalkylbladsdokument"), och i den nedre delen - texterna för den valda proceduren eller funktionen med markerade ändringar. Vi måste överföra dessa ändringar till vår testdatabas. Men det tar inte bort ändringarna från uppdateringen. Du kan automatisera detta på följande sätt. Vi ställer markören till den nedre vänstra delen (där texten i den valda proceduren med våra ändringar) och trycker på Ctrl + A (välj alla) och Ctrl + C (kopiera markeringen till urklipp) i följd. Sedan skapar vi en fil med det villkorliga namnet "old_izm.txt", öppnar den i textredigerare och tryck på Ctrl + V (klistra in innehållet i klippbordet). Vi gör samma sak för den nedre högra delen (där texten i den valda proceduren kommer från den typiska konfigurationen av den icke-uppdaterade utgåvan) - som ett resultat skapar vi en fil med det villkorliga namnet "old_type.txt". Efter det, gå till Test Base Configurator (den ska vara öppen i närheten, men utan några fönster inuti, för att inte bli förvirrad i dessa två konfiguratorer) - och i konfigurationen letar vi efter vår modul (i det här exemplet är det är "GeneralModule.VAT Accounting.Module") och den nödvändiga proceduren i den (i detta exempel är det "OutputInvoiceIntoSpreadsheetDocument"): välj allt och kopiera det till ett nytt textfil med det villkorliga namnet "new_type.txt". Således har vi tre filer ("old_izm.txt", "old_type.txt", "new_type.txt"), på grundval av vilka vi måste skapa den fjärde filen - "new_izm.txt". Denna fjärde fil bör bara innehålla våra ändringar, men med hänsyn till uppdateringen. Vi kommer att forma det sekventiellt genom att jämföra de tillgängliga tre filerna. Till att börja med, låt oss avgöra om det finns spår av uppdateringsändringar i den här proceduren? För att göra detta jämför vi genom Total Commander (se ovan) filen "old_type.txt" och "new_type.txt". Om jämförelsen visade att filerna är identiska eller skillnaden i antalet mellanslag eller flikar - betyder det att vi har tur med denna del av ändringar och du kan överföra ändringarna helt enkelt genom att kopiera innehållet i filen "old_izm.txt" och klistra in den i den öppna testbasmodulen, ta bort motsvarande procedur innan dess (med andra ord - ersätta den). Här är det viktigt att noggrant övervaka utrymmena före och efter proceduren så att det inte är överflödigt i den fortsatta jämförelsen: detta kommer naturligtvis inte att påverka funktionaliteten, men det kommer att komplicera verifieringen något. Om jämförelsen av "old_type.txt" och "new_type.txt" visade att det finns verkliga skillnader - betyder det att det i denna procedur finns både våra ändringar och uppdateringsändringar. För att förenkla överföringsuppgiften: först kan du visuellt bedöma vilka ändringar som är fler - från uppdateringen eller vår. För att göra detta, återigen, genom Total Commander, jämför vi "old_type.txt" sekventiellt med "new_type.txt" och "old_izm.txt". Och vi tittar där det finns fler förändringar: i jämförelsen av "old_type.txt" och "new_type.txt" eller i jämförelsen av "old_type.txt" och "old_izm.txt". Om det är fler ändringar i den första jämförelsen (uppdateringen ändrade funktionen mer) så är det lättare att fixa den uppdaterade filen genom att göra våra ändringar, det vill säga vi ändrar "new_type.txt". Vi kommer villkorligt att kalla detta det första fallet att göra ändringar. Om det finns fler ändringar i den andra jämförelsen (vi hade fler ändringar), så är det lättare att fixa vår fil genom att göra uppdateringsändringar, det vill säga vi ändrar "old_izm.txt". Vi kommer villkorligt att kalla detta det andra fallet med ändringar. Nu, exakt hur man överför ändringarna snabbt och exakt. För att göra detta skapar vi en fjärde fil och, som redan överenskommits, kallar den "new_izm.txt". Med hänsyn till optimeringen av överföringen av korrigeringar kopierar vi innehållet i antingen "new_type.txt" eller "old_izm.txt" till den här filen (respektive det första eller andra fallet med ändringar).
Nu öppnar vi två filjämförelsefönster samtidigt. För det första fallet att göra ändringar är dessa jämförelser för filerna "new_izm.txt"/"old_izm.txt" och "old_type.txt"/"old_izm.txt". För det andra fallet är dessa jämförelser av filerna "new_izm.txt"/"new_type.txt" och "old_type.txt"/"new_type.txt". Det finns en "Redigera"-knapp i jämförelsefönstret: tryck på den i jämförelsen av det första paret. Låt oss nu förklara vad vi ser. I det första jämförelseparet är objekt synliga både från vår ändring och från uppdateringen. I enlighet med vårt fall behöver vi bara överföra våra ändringar, eller bara uppdateringar. I det andra jämförelsefönstret är endast de ändringar som vi måste överföra synliga. Om du är uppmärksam - i båda fallen är den andra filen av både den första och andra jämförelsen densamma. Därför vägleds vi av raderna i den här filen, och av raderna i den andra jämförelsen gör vi ändringar i fönstret för den första jämförelsen: den nedtryckta "Redigera"-knappen låter oss bara göra detta.

För "tydlighet", låt oss grafiskt avbilda åtgärderna under överföringen i det första fallet (vi ändrar den uppdaterade filen och gör våra ändringar):

Handlingar i det andra fallet är absolut lika och handlingsprincipen är exakt densamma.

Det svåraste och obehagligaste fallet är när våra ändringar och uppdateringsändringar finns på ETT ställe. Det vill säga, det var faktiskt två ändringar på ett segment av koden. I det här fallet krävs ingripande av programmeraren. Även programmerarens ingripande, men i mindre utsträckning, krävs om till exempel uppdateringen ändrar namnen på de variabler som används i våra ändringar. Det är också värt att notera att i filen "old_type.txt" eller "old_izm.txt" kan det finnas tomma rader - dessa är "spåret" av våra ändringar. Det är nödvändigt att överföra dem så att de inte finns i den slutliga filen. Detta påverkar inte funktionaliteten, men i ytterligare jämförelser (med efterföljande uppdateringar) kommer det att göra det lite svårare att analysera åtgärderna. Så efter att vi har genererat den fjärde filen, efter att ha överfört alla ändringar, måste vi kopiera dess innehåll till konfigurationen. I testdatabasen Configurator bör den nödvändiga modulen öppnas på en ny plats: ta bort den befintliga proceduren och klistra in innehållet i vår slutliga fil, med hänsyn till alla mellanslag mellan föregående / efterföljande funktioner. Således överförde vi ändringar till EN procedur för det hittade objektet. Vi har (Fig. 6) denna procedur är verkligen en. Om det finns flera sådana procedurer måste de beskrivna åtgärderna göras för var och en. Om proceduren är ny (endast i den vänstra halvan), lägg helt enkelt till den i motsvarande modul i testbasen (för korrektheten av ytterligare jämförelse måste du behålla ordningen på procedurerna, som i motsvarande modul av arbetsbas, där det fortfarande finns en gammal version).

2.2.2. Ändringarna som skrevs över av uppdateringen fanns INTE i modulen. För att överföra sådana ändringar kommer en sådan jämförelse inte att förenkla arbetet på något sätt, därför överförs ändringarna helt enkelt genom visuell jämförelse av objekt i arbets- och testdatabaserna.

Således överför vi ändringarna för varje objekt där våra ändringar skrevs över av uppdateringen. För att kontrollera hur korrekt vi överförde alla ändringar sparar vi konfigurationen i testdatabasen, laddar upp konfigurationsjämförelsen till filen "Comparison Report_new2.txt" och jämför den med filen "Comparison Report_old.txt". Om allt är perfekt, kommer meddelandet "Filer är identiska" att visas. Om vissa objekt raderades av uppdateringen, kommer endast dessa objekt i skillnad att vara synliga om ändringarna överförs korrekt. Det blir korrekt om endast mellanslag / tomma rader / flikar är synliga i jämförelsen, men i det här fallet är det bättre att rensa upp det och få meddelandet "Filer är identiska". Efter att ha sparat ändringarna i testbasen laddar vi alltså upp jämförelsen till en fil och jämför den med ändringarna i den gamla versionen - vi upprepar detta tills jämförelsen visar att vi har överfört alla nödvändiga ändringar.

3. Överföra den uppdaterade konfigurationen från testdatabasen till produktionsdatabasen. I de tidigare stegen uppdaterade vi testdatabasen till den senaste versionen, kontrollerade och migrerade nödvändiga ändringar och sparade den resulterande konfigurationen. Nu laddar vi ner den i en cf-fil och laddar in den i arbetsdatabasen. Innan du laddar ner - du måste göra en kopia av arbetsdatabasen och ta bort konfigurationen från supporten. ALLT. Användare "inaktiv" endast i början, när vi lossade basen och i slutet, när vi lossade basen igen och laddade konfigurationen.

Detta slutför uppdateringen.

Originalartikeln finns på hemsidan

En icke-standardiserad 1C-konfiguration är när: 1) 1C-konfigurationen skrevs från början av programmeraren själv, 2) 1C-konfigurationen var typisk, men ändringar lades till i den, även om ett attribut lades till.

I den här artikeln kommer vi att titta på hur man korrekt uppdaterar 1C-konfigurationer, samt flera knep för att mjukt ändra typiska konfigurationer, d.v.s. korrekt ändring som inte kommer att påverka möjligheten att uppgradera senare.

För att göra några ändringar i den typiska 1C-konfigurationen är det nödvändigt att låsa upp ändringen i den typiska 1C-konfigurationen och i vissa fall "ta bort den från supporten".

I det mest optimala uppdateringsalternativet kan 1C-konfigurationen uppdateras i sin helhet automatiskt läge, detta är möjligt när vi har inaktiverat konfigurationsändringar. Ganska ofta krävs det att inkludera en konfigurationsändring, eftersom det är nödvändigt att anpassa applikationslösningar till kundens affärskrav, och vi kommer att stanna vid detta alternativ.

Innan du uppdaterar rekommenderas starkt att göra säkerhetskopiering databas kan detta göras via menyn Administration / Ladda upp infobas.

Det finns 2 alternativ för uppdatering: a) 1C-uppdatering via support (ringa via konfigurationsdialogrutan Konfiguration / Support / Uppdatera) och b) genom Jämförelse och sammanfogning med konfigurationen från en fil. Bör betalas Särskild uppmärksamhet att skillnaden mellan dessa två punkter är att i det första fallet uppdateras både huvudkonfigurationen och leverantörens konfiguration och vid jämförelse av sammanslagning av konfigurationer är det bara huvudkonfigurationen som uppdateras, leverantörens konfiguration förblir den gamla. Därför är det mest rekommenderade alternativet att uppdatera via Update Configuration. För att uppdatera via Configuration Support används leverantörens CF- eller CFU-distributionsfiler, som kan hittas genom att söka i mallkatalogen genom att ange sökvägen på Internet, eller direkt ange sökvägen till önskad fil på hårddisken.

När du uppdaterar 1C-konfigurationen utan möjlighet att göra ändringar, sker uppdateringen efter val av uppdateringsfil automatiskt, om konfigurationen är aktiverad för att göra ändringar, sedan efter val av uppdateringsfil, kommer ett konfigurationsjämförelsefönster att visas. I den här dialogrutan kan vi se hur systemet uppmanar oss att uppdatera vår icke-standardiserade 1C-konfiguration. I den nedre delen av dialogrutan finns en motsvarande förklaring om objektstatus: "Status efter objektöverensstämmelse" betyder jämförelse av "Huvudkonfiguration" och "Ny konfiguration", "Status efter objekthistorik" betyder jämförelse av konfigurationsobjekt med objekt " gammal konfiguration leverantör".

Genom att markera rutorna bredvid objekten kan du välja om det aktuella konfigurationsobjektet ska ändras eller förbli det gamla, samt metoden för att ändra objektet. I åtgärdsmenyn är det möjligt att markera rutorna för delsystem (detta är användbart om konfigurationen stöds av flera leverantörer). Även i den här menyn är det möjligt att ange sammanslagningsprioritet för alla objekt samtidigt, som standard anser systemet att leverantörskonfigurationen har högre prioritet. Filterinställningarna låter dig specificera vilka konfigurationsobjekt vi ska visa för att kunna specificera sammanslagningsläget i detalj. Det finns flera standardfiltermönster, och du kan ange filter för varje par av konfigurationer du jämför. Det är möjligt att ställa in kryssrutan "Visa endast två gånger ändrade egenskaper" i "Filter"-inställningarna, detta gör att du kan filtrera bort objekt vid uppdatering som det inte fanns några konflikter mellan leverantörens ändringar och ändringarna av dessa objekt:

Så resultatet kommer att bli en lista över objekt som har ändrats två gånger vid förfining av den typiska konfigurationen och i den nya leverantörskonfigurationen. 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 beslut fattas om hur det ska uppdateras. I detta skede bör en preliminär jämförelse göras enbart för att minska arbetsmängden senare. Utvärdering är inte exakt snabbt - "med ögat". Om det finns fler ändringar i objektet i den nya leverantörskonfigurationen lämnar vi instansen av leverantörsobjektet. Vi lämnar en bock. Sedan måste du överföra ändringarna från den fungerande konfigurationen. Om det finns fler ändringar i objektet i arbetskonfigurationen, lämnar vi en instans av arbetskonfigurationsobjektet. Vi avmarkerar rutan. Du måste sedan migrera ändringarna från leverantörens konfiguration. Med moduler kan du göra lite annorlunda, eftersom. det är möjligt att jämföra moduler procedurmässigt.

De där. i händelse av att olika modulprocedurer har ändrats i vår 1C-konfiguration och i leverantörens konfiguration, kommer vi, genom att korrekt placera kryssrutorna, att rädda oss från att manuellt överföra kodändringar. För att komma till detta måste du klicka på knappen i form av ett förstoringsglas bredvid namnet på läget för att kombinera moduler:

När du visar en meny med åtgärder på ett objekt (till exempel genom att trycka på höger knapp mus), kan vi ta fram objektjämförelserapporten.

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

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

Några regler som förenklar den framtida uppdateringen av 1C-konfigurationer:

Grundregeln för att uppdatera 1C: du måste lägga till nya objekt, eftersom. vid uppdatering påverkas inte nya objekt av systemet

När du ändrar texterna i moduler är det också önskvärt att lägga till dina egna nya procedurer och funktioner och anropa dina nya från befintliga.

Genom att använda händelseprenumerationer, tack vare detta, kan du förfina de typiska mekanismerna utan att ändra den typiska koden

Använder den typiska konfigurationsfunktionen

Programmatiskt skapa formulärelement (i OnFormCreateOnServer-händelsen)

Tack!

Personlig erfarenhet: hur man snabbt och kostnadseffektivt uppdaterar en modifierad 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 inte infobaser matchar 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 "Production Enterprise Management" (nedan kallad PPM) i release 1 (releasenummer tilldelas nedan villkorligt) till mätningen (indikatorn) för 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 sett till mantimmar. Till exempel kan 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 avgöra: 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 den här konfigurationen typisk, och om "Changeable är aktiverad" - är konfigurationen troligen ändrad (å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 uppdatering av ändrade konfigurationer

Nyligen stod jag inför uppgiften att uppdatera den ändrade konfigurationen "Trade Management", release 10.3.13.2. Konfigurationen har ändrats till följd 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 specialisterna på detta företag med en begäran om att uppskatta kostnaden för att uppdatera min konfiguration. För att uppskatta tiden och kostnaden för arbetet gav jag nuvarande konfiguration i behov av uppdatering. 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 version config: 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/släpp."

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 versioner 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. Objektdetaljer har lagts till tabelldel, visas på objektformuläret 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.

Något ä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 informationsbas innan du passerar 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. Också denna bearbetning kan laddas ner från länken: http://its.1c.ru/db/metod81#content:1644:1.

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

Kataloger: Individer, Kontaktpersoner, Kontaktpersoner för motparter, Motparter, Pristyper.
Informationsregister: Passdata enskild, fullständiga namn

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.

Enligt resultatet av det utförda arbetet kan jag säga att alla ändringar i konfigurationen sparades; under visuell visning behöll alla objekt som ändrades sina egenskaper och skillnader från den typiska konfigurationen. Under drift 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 lätt att lägga till detta jobb, men jag bad "1C-IzhTiSi" att skicka mer fullständiga instruktioner genom 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 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 vid ytterligare manuell uppdatering det vore bättre att inte ha sådana kodavsnitt. På fig. 6 visar ett exempel före uppdateringen, och i fig. 7 är ett exempel efter uppdateringen.