Jämför 1c enterprise 8.3 med leverantörens konfiguration. Återställer leverantörskonfiguration
Och så igen Hej kära läsare av bloggen www.site. Idag ska vi prata om hur man laddar upp och laddar ner en konfiguration i 1C Enterprise. Vi har redan diskuterat frågan med dig. Men som det visade sig blir det helt tomt. För att börja arbeta i den måste du ladda konfigurationen från en fil. Processen att ladda upp och ladda konfigurationen är ganska enkel men mycket viktig.
Till exempel kommer jag att använda 1C 8.2, men för version 8.3 kommer denna instruktion också att fungera. Låt oss ta en närmare titt på vad konfiguration är. Jag ska försöka förklara detta för dig med mina egna ord. En konfiguration i 1C är en uppsättning dokument, tabeller, olika rapporter etc. som bara inte är ifyllda, tomma utan data. En analogi kan dras med Excel-dokument, en tom tabell fylld med olika formler och diagram är en konfiguration. Det finns många konfigurationer: Redovisning, Löner och HR, dokumentflöde, Detaljhandel etc. Det finns också en hel del olika självskrivna konfigurationer.
Hur man laddar upp en konfiguration från 1C till en fil
Hur kan vi ladda upp 1C-konfigurationen till en fil. Och så, först och främst, måste vi gå in i själva konfiguratorn, för att göra detta, starta 1C och välj önskad databas, klicka på Konfigurationsobjektet.
I konfiguratorn, gå till objektet Konfiguration och välj Spara konfiguration till fil.
Det var allt, uppladdningen av konfigurationen är klar. Låt oss nu prata om hur man laddar ner det.
Hur man laddar en konfiguration till 1C från en fil
Vi har ordnat uppladdningen, låt oss nu titta på att ladda konfigurationen från en fil. För att göra detta behöver du också gå till konfiguratorn. Och välj alternativet Konfiguration och leta efter Laddar en konfiguration från en fil.
I fönstret som öppnas måste du ange konfigurationsfilen och klicka på Öppna. Sedan väntar vi på att konfigurationen ska laddas.
Stäng konfiguratorn och starta 1C i normalt läge.
Som du kan se visade sig allt vara ganska enkelt.
Låt oss överväga en typisk situation där nybörjare ofta befinner sig. Låt oss säga att det finns en typisk konfiguration av 1C: Integrated Automation 8. Inledningsvis installerades konfigurationen från distributionssatsen (låt oss säga release 1.1.20.1). Sedan, på grund av behovet av att anpassa sig till företagets särdrag, inkluderades möjligheten till förändring (nykomlingar kallar ofta felaktigt denna åtgärd för att ta bort från stödet, även om så i själva verket inte är fallet).
Och nu, efter en tid, har vi en mycket modifierad, men fortfarande standard (för reglerad redovisning uppdaterade vi regelbundet) konfiguration. Låt oss titta på några hypotetiska situationer:
1) En tid efter nästa uppdatering får vi ett meddelande från ekonomiavdelningen om ett fel som uppstår under den rutinmässiga månadsavslutningen. Det fanns inget sådant fel tidigare, så uppdateringen är skyldig. En ganska typisk situation. Vi börjar diagnostisera felet och ser att benen växer från den allmänna modulen Redovisning för moms och bildande av rörelser. Vi börjar förstå och förstå att den här modulen avsevärt gjordes om till en standard och efter sammanslagningen "tappade" vi några av procedurerna/funktionerna (eller, som ofta händer i standardmodulerna, de "hoppade" in i en annan gemensam modul). På grund av de invecklade vanliga modulerna sinsemellan i standardmoduler är det inte alltid möjligt att identifiera ett problem i uppdateringsstadiet som endast visar sig när användarna arbetar.
Så vi förstår att för att ta reda på det behöver vi en typisk konfiguration av den aktuella versionen (låt oss säga 1.1.23.1). Men var kan jag få tag i det? Om det finns en bekant fransman och han snabbt kan skicka distributionspaketet, bra, men låt oss anta att han inte är där och problemet måste åtgärdas omgående. (Föreslå inte Varese!). Dessutom kanske det inte finns något internet, och vad ska man göra i en sådan situation? Jag har upprepade gånger sett en process där en person, för att lösa ett givet problem, installerade en ny databas från den befintliga initiala distributionen och sedan successivt uppdaterade den till den senaste för att se "hur det egentligen borde vara" i en ren databas. Och kistan öppnade sig precis som alltid :)
Låt oss nu titta på olika lösningar:
a) Första alternativet: Meny -> Konfiguration -> Jämförelse av konfigurationer, välj sedan leverantörens konfiguration och jämför den med huvudkonfigurationen.
Överraskande nog finns det de som inte vet om detta. Eller, under alla omständigheter, använd objektet Jämför, kombinera med konfigurationen från filen (har tidigare erhållit/mottagit standarden .cf).
b) Den andra metoden är lämplig om vi inte bara behöver se ändringarna utan också omedelbart utföra sammanslagningen.
Meny -> Konfiguration -> Support -> Supportinställningar och längst ner klicka på knappen Jämför, sammanfoga.
2) En annan situation: låt oss säga att vi ändrade eller raderade någon del av standardkoden, och efter ett tag visade det sig att vi gjorde ett misstag och att vi måste lägga tillbaka allt. Och som ofta händer finns det ingen säkerhetskopia av den sparade konfigurationen innan ändringarna gjordes. Men vi vet med säkerhet att denna kodbit finns i standardkoden, så leverantörskonfigurationen skulle lösa problemet.
Naturligtvis kan du göra samma sak som i det första fallet. Vänta tills jämförelseprocessen har slutförts, och från fönstret för konfigurationsjämförelse öppnar du standardmodulen och kopierar koden därifrån.
Vissa människor gör just det, men om vi har att göra med ett monster som UPP, som också är kraftigt modifierat, kan vi vänta väldigt länge på att jämförelseprocessen ska slutföras. Om vi hade en .cf-fil kunde vi helt enkelt öppna den i konfigurationsfönstret (förresten, inte alla nybörjare känner till den här funktionen heller) och kopiera den nödvändiga koden därifrån.
Och en rimlig fråga uppstår: hur kan du fortfarande spara leverantörens konfiguration till en fil? Varför finns det inget menyalternativ som liknar Spara konfiguration till fil för huvudkonfigurationen eller Spara databaskonfiguration till fil för databaskonfiguration. Var är samma för leverantörskonfigurationen? Faktum är att den finns där också, bara begravd lite djupare. Allt är nämligen i samma form av supportinställningar.
Det är bara det att många människor bara öppnar det här formuläret en gång för att aktivera ändringsalternativet och aldrig återvända till det.
Och i vårt fall var det möjligt att göra det ännu enklare, utan att ens spara konfigurationen i en fil, klicka på knappen Öppna. Effekten är densamma, men mycket snabbare.
Varför annars kan du behöva spara leverantörskonfigurationen i en fil?
3) Tänk på följande situation. Låt oss säga att i det inledande skedet av konfigurationens existens hade standardkonfigurationen inte den funktionalitet vi behövde och ett beslut togs för att förbättra den. Modifieringen var minimal, men i framtiden skapade den ändå besvär vid uppdateringen. Men sedan, efter en tid, upptäcker vi att denna funktionalitet (som var fallet med objektversionering vid en tidpunkt) dök upp i standardversionen (och, som ofta händer, implementerades den i en storleksordning bättre än den "provisoriska" modifieringen ).
Låt mig ge dig några fler exempel på verkliga situationer när du kan behöva återgå till en standardkonfiguration:
1. Ett par gånger stötte jag på konfigurationer där endast layouterna för tryckta formulär var föremål för ändringar. På grund av bristande erfarenhet eller okunnighet tog programmeraren som underhållit konfigurationen, istället för att skapa ett externt tryckt formulär, konfigurationen från supporten och modifierade de inbyggda layouterna (ofta trivialt för att lägga till en företagslogotyp), varefter användarna blev berövade av möjligheten att uppdatera automatiskt.
2. Återigen, på grund av okunskap om standardfunktionaliteten (ex-Sju studenter lider ofta av detta), istället för att använda egenskaper och kategorier, lades detaljer om kataloger/dokument till när det inte fanns någon god anledning till detta (data t.ex. användes endast för utskrift till tryckta formulär).
Naturligtvis är detta inte ett problem om vi har att göra med UT eller annan konfiguration av förvaltningsplaner, där uppdateringar i allmänhet inte är kritiska, men i det här exemplet talade vi om modifierade SCP:er eller komplex automatisering. Och det visar sig att på grund av mindre förbättringar som kunde ha implementerats utan att ta bort fullt stöd, har vi onödiga hemorrojder med standarduppdateringar.
Det finns en rimlig önskan att överge de ändringar som gjorts och sätta konfigurationen tillbaka till fullt stöd. Hur man gör det?
Det enda sättet att återställa konfigurationen till fullt stöd är att ladda (inte i jämförelse- och sammanfogningsläget, utan istället Ladda konfiguration från fil) standard.cf. Det är därför vi behöver möjligheten att spara leverantörskonfigurationen till en .cf-fil. Vi sparar, laddar sedan och efter uppdatering av databaskonfigurationen får vi standardkonfigurationen i dess ursprungliga form, d.v.s. med ett lås :) Innan du utför dessa åtgärder måste du naturligtvis se till att spara/överföra nödvändiga data, som kommer att "tvättas bort" efter återgång till standardkonfigurationen, och se till att göra en säkerhetskopia av databas!
Det här är, som det visar sig, enkla möjligheter tillgängliga för utvecklarens arsenal, men okunnighet om dessa tekniker i praktiken kan resultera i många timmar av onödigt krångel som beskrivs ovan. Så de som visste - bra gjort, och de som inte visste - ta det i bruk och spara din tid.
Den här artikeln är baserad på många års erfarenhet av att utveckla och stödja redovisningslösningar på 1C:Enterprise-plattformen. Artikeln beskriver några ganska vanliga situationer som orsakar svårigheter vid uppdatering av icke-standardiserade 1C:Enterprise 8-konfigurationer.
Den här artikeln beskriver inte metoder för att använda automatiska och automatiska konfigurationsuppdateringar med hjälp av externa komponenter och/eller mjukvaruprodukter. Du kan hitta information om dem på denna och 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 ges en lista på flera dussin ändrade objekt. Naturligtvis kan du använda tekniken som beskrivs i artikeln "Teknik för uppdatering av icke-standardiserade konfigurationer av 1C: Enterprise 7.7" daterad 27 juni 2003. Ja, det kommer att fungera. Många människor utfö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 samtidigt (*.cf-filer) och utföra flera jämförelser av konfigurationer i en kopia konfigurator. Det enda undantaget är kanske konfigurationer byggda på PPM (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 ganska hög nivå av automatisering kan avsevärt minska arbetsintensiteten 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 slutfö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 den befintliga konfigurationens funktionalitet. De där. dessa objekt måste lösa helt andra redovisningsproblem som utökar funktionaliteten i standardleverantörskonfigurationen. Håller med om att den beskrivna situationen är extremt sällsynt. Ändringar påverkar nästan alltid standardleverantörskonfigurationsobjekt.
Observera att databasen kan innehålla upp till tre typer av konfigurationer:
- databaskonfiguration- detta är den konfiguration som användare arbetar med;
- fungerande konfiguration (huvud) är en konfiguration som vi kan göra ändringar i och användare kan fortsätta arbeta;
- leverantörens konfigurationär den initiala leverantörskonfigurationen från vilken produktions- och databaskonfigurationerna vanligtvis skapas. En databas kan ha flera konfigurationer från olika leverantörer. Konfigurationsleverantören kan inte bara vara 1C.
Låt oss överväga uppdateringsprocessen och analysera möjliga fel med hjälp av exemplet med att uppdatera UPP-konfigurationen (leverantören av standardkonfigurationen är 1C, ändringar av Inform Service). Ursprungligen uppdaterades den här konfigurationen utan att använda tekniken som beskrivs i den här artikeln, så de fel som diskuteras i den här artikeln är de vanligaste i praktiken. Uppdateringen kommer att ske 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 matcha arbetskonfigurationen med leverantörens konfiguration. Detta är ett mycket viktigt steg som avsevärt kommer att minska mängden arbete som krävs för att analysera de förändringar vi tidigare har gjort.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.
En diskrepans mellan versionerna av den fungerande konfigurationen och leverantörskonfigurationen kan uppstå när du använder *.cf-filer för uppdatering som inte kommer från leverantörens distribution eller när du använder uppdateringsmetoder som skiljer sig frå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.
Låt oss kontrollera versionsnumren för den fungerande konfigurationen och leverantörskonfigurationen. Vi tittar på det fungerande konfigurationsnumret i menyn "Konfiguration" → "Öppna konfiguration" i menyn "Redigera" → "Egenskaper". I blocket "Utveckling" väljer du "Version". (Bild 1).
Vi tittar på leverantörens konfigurationsnummer i menyn "Konfiguration" → "Support" → "Supportinställningar..." objektet "Version". (Figur 2).
Om siffrorna matchar, gå vidare till nästa steg. Se steg 2.
I det här exemplet är det nödvändigt att stämma av drift- och leverantörskonfigurationerna med tillhandahållandet av support för objekt som tagits bort från supporten eller lagts till utan provisionering för support. För att göra detta, utför följande steg:
2. Spara den fungerande (huvud)konfigurationen.
Låt oss spara den fungerande konfigurationen till en fil, till exempel work.cf. För att göra detta, välj menyalternativet "Konfiguration" → "Spara konfiguration till fil...".
3. Skaffa uppdateringsfilen för leverantörskonfigurationen.
För att anpassa konfigurationerna behöver vi en *.cf-fil från leverantörens distribution med samma versionsnummer som den fungerande konfigurationen (figur 3 och 4). Denna fil kan erhållas när du installerar motsvarande distribution. Som standard är konfigurationsdistributionen installerad i katalogen C:Program Files1cv81tmplts. Mer information om installation av konfigurationsmallar finns i dokumentationen.
Låt oss kolla mallkatalogen. Om det finns en *.cf-fil av den nödvändiga versionen i mallkatalogen, gå till punkt 4 i steg 1.
Vad kan göras om det inte finns någon *.cf-fil för den version som krävs av leverantörskonfigurationen? I det här fallet kan du använda *.cfu-filer och upprepa proceduren som beskrivs i steg 1 flera gånger och successivt höja versionsnumret till den nödvändiga versionen, i det här fallet till 1.2.6.2. Det bör noteras att användning av *.cfu-filer kanske inte fixar fel som gjorts tidigare under uppdateringen. Vilket, du förstår, är ganska konstigt, med tanke på att först leverantörsfilen kompileras utifrån den gamla leverantörskonfigurationen och *.cfu-filen, och sedan utförs uppdateringen. Detta kan bero på att av någon anledning inte alla konfigurationsobjekt ingår i jämförelsen. Därför föreslår jag att du använder en möjligen längre väg, men också en mer tillförlitlig.
Du måste skapa en tom databas med den "gamla" leverantörskonfigurationen. Uppdatera leverantörens konfiguration till den version som krävs och använd den när du utför arbete i steg 1. För att få den "nya" leverantörskonfigurationen måste du göra följande:
Skapar den "gamla" leverantörsfilen för den aktuella konfigurationen. Filen 1cv8.cf kan hämtas från leverantörens distribution eller sparas från arbetsdatabasen om konfigurationen är under support. För att spara filen 1cv8.cf från arbetsdatabasen, gå till menyn "Konfiguration" → "Support" → "Supportinställningar...", klicka på knappen "Spara till fil" och ange katalogen och filnamnet. Till exempel på skrivbordet.
Skapa en databas med den nya leverantörskonfigurationen. Databasen kan skapas med hjälp av leverantörens distribution från ITS-disken eller med 1cv8.cf som erhållits tidigare från skrivbordet. I det första fallet följer vi instruktionerna som ingår i distributionssatsen. I det andra fallet, för att skapa en databas från en fil som finns på skrivbordet, skapar vi en ny infobas utan konfiguration och startar konfiguratorn. I menyn "Konfiguration" → "Ladda konfiguration från fil..." anger vi filen som tidigare sparats på skrivbordet. Vi öppnar konfigurationen genom menyn "Konfiguration" → "Öppna konfiguration" och uppdaterar till önskad version genom menyn "Konfiguration" → "Support" → "Uppdatera konfiguration" med hjälp av *.cfu-filer.
Skapa en "ny" leverantörskonfigurationsfil. För att göra detta, välj menyalternativet "Konfiguration" → "Spara konfiguration till fil...". Vi anger platsen och namnet på filen 1cv8.cf. Klicka på "Spara".
Med hjälp av den mottagna *.cf-leverantörens konfigurationsfil kommer vi att utfö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ösningar:
- avmarkera ett objekt som finns i leverantörskonfigurationen;
- ta bort referensen till objektet som finns i leverantörskonfigurationen.
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 kommer vi att slå samman med den tidigare sparade arbetskonfigurationsfilen work.cf. För att göra detta, välj menyalternativet "Konfiguration" → "Jämför, slå samman med konfiguration från fil...".
6. Sparar uppdateringsresultaten.
Låt oss spara ändringarna i den fungerande konfigurationen och uppdatera databaskonfigurationen. För att göra detta, välj menyalternativet "Konfiguration" → "Uppdatera databaskonfiguration".
Här väntar ett annat problem på oss (Figur 8).
För att lösa detta problem, låt oss titta på orsaken till dess förekomst. Det kan finnas flera anledningar, men de mest troliga är följande. Dessa objekt kopierades till arbetskonfigurationen från leverantörens konfiguration, eller så har leverantören tidigare tagit bort dessa 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 med samma namn, i konfigurationen.
Vi hanterar roller helt enkelt - vi tar bort dem, eftersom rollerna har inte ändrats (detta kan verifieras genom att jämföra den gamla leverantörskonfigurationen och produktionskonfigurationen). Vi agerar annorlunda med dokumentdetaljer. Attributet måste döpas om, till exempel OrderReserve1, och efter uppdatering måste värdena från det omdöpta attributet överföras till det nya. För att göra detta kan du använda bearbetningen av UniversalSelectionAndProcessingObjects.epf från ITS-disken.
Låt oss överväga en annan situation som liknar den föregående, men som uppstod under uppdateringen av 1C: Enterprise Accounting 8.1. Vad ska man göra med blanketter? (Figur 9)
I figuren ser vi att Listformuläret togs bort från leverantören och sedan lades ett nytt formulär med samma namn till av leverantören. Följaktligen måste du markera båda formulären för uppdatering och klicka på knappen "Kör".
Om du får ett meddelande om att det finns länkar till objekt som ska raderas måste du, utan att stänga uppdateringsformuläret, rensa länkarna till formuläret som ska raderas i objektegenskaperna. I detta fall i registret egenskaper. Efter detta måste du klicka på knappen "Uppdatera" i uppdateringsformuläret, markera registeregenskaperna för uppdatering och klicka på knappen "Kör" igen.
Låt oss spara ändringarna i den fungerande konfigurationen och uppdatera databaskonfigurationen "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 fortsätter vi med att uppdatera huvudkonfigurationen och överföra tidigare gjorda ändringar till standardleverantörskonfigurationen.För att uppdatera konfigurationen behöver vi en *.cfu-fil eller en *.cf-fil från leverantörens distribution.
Om uppdateringen utförs genom flera konfigurationsversioner, bör du vara uppmärksam på situationen som beskrivs i artikeln "Uppdatering av 1C: Enterprise 8-konfigurationer. Går igenom 20 versioner." Om uppdateringen inte utförs på en fungerande bas sparar vi *.cf-filerna efter att ha slutfört förberedelserna för varje nytt steg. De kommer att behövas vid uppdatering av konfigurationen av kundens produktionsdatabas.
Om uppdateringen utförs genom flera versioner, bör du under uppdateringen definitivt vara uppmärksam på de objekt som raderas och till objekt med ändrade namn, såväl som de åtgärder som utförs under den första lanseringen efter uppdateringen. Om dessa objekt används i bearbetningen vid 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 texten i bearbetningsmodulen. I det här fallet kan de kvarlämnade objekten raderas under nästa eller nästa uppdatering.
Om uppdateringen utförs genom flera versioner kan du, för att minska arbetsintensiteten för uppdateringen, använda metoden för att beräkna nyckelutgåvor som beskrivs i artikeln "Uppdatering av 1C:Enterprise 8-konfigurationer. Går igenom 20 versioner."
1. Upprättande av databaser.
Så baserat på resultaten från det första steget förbereder vi två identiska databaser. 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 klient-serverversionen är det uppladdning/nedladdning.
2. Trevägsjämförelse av konfigurationer.
Låt oss öppna båda databaserna i Configurator-läge och utföra en trevägsjämförelse av konfigurationer i båda databaserna, med hjälp av den befintliga leverantörens nya konfigurationsfil. För att göra detta, i båda databaserna, välj 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 dessa föremål som måste hanteras först, eftersom... Efter uppdateringen kan tidigare gjorda inställningar gå förlorade.
Vid denna tidpunkt avbryter vi arbetet i den andra (extra) databasen och fortsätter i den huvudsakliga. Det finns ingen anledning att klicka på knappen "Kör" i den extra databasen. Vi behöver denna databas exakt i detta formulär tills uppdateringsprocessen är klar.
Så som ett resultat får vi en lista över objekt som ändrades två gånger under ändringen av standardkonfigurationen och i den nya leverantörskonfigurationen. Om du accepterar uppdateringen kommer tidigare gjorda förbättringar av dessa objekt att gå förlorade. För varje objekt är det därför nödvändigt att fatta ett beslut 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. Bedömningen är inte korrekt och snabb - "med ögat".
Om det finns fler ändringar i objektet i den nya leverantörskonfigurationen lämnar vi instansen av leverantörsobjektet. Lämna en bock. Sedan kommer vi att överföra ändringarna från den fungerande konfigurationen.
Om det finns fler ändringar i objektet i arbetskonfigurationen, lämnar vi en instans av arbetskonfigurationsobjektet. Avmarkera rutan. Sedan överför vi ändringarna från leverantörskonfigurationen.
Vi hanterar moduler lite olika eftersom... Vi har möjlighet att jämföra moduler procedurmässigt. De där. Om olika modulprocedurer ändras i vår konfiguration och i leverantörens konfiguration, kommer vi genom att korrekt markera rutorna 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 de objekt som ska uppdateras omedelbart och som det fortfarande finns bockar på, duplicerar vi tillståndet med bockmärken i hjälpdatabasen, och i huvuddatabasen trycker vi på knappen "Kör". I huvuddatabasen får vi en nästan färdig konfiguration.
Därefter utför vi alla jämförelser i hjälpdatabasen. Vi har redan en jämförelse - en trevägs. För att fastställa tidigare gjorda ändringar utför vi ytterligare en andra jämförelse av den gamla leverantörskonfigurationen med huvudkonfigurationen. För att göra detta, välj menyalternativet "Konfiguration" → "Jämför konfigurationer:", välj "Leverantörskonfiguration" och "Huvudkonfiguration" för jämförelse (Figur 16).
På samma sätt jämför vi den gamla leverantörskonfigurationen med den nya. För jämförelse behöver vi den nya leverantörskonfigurationsfilen. Om det inte finns någon sådan fil kan den nu hämtas från huvuddatabasen. För att spara den nya leverantörskonfigurationen till en fil i huvuddatabasen, i menyn "Konfiguration" → "Support" → "Supportinställningar:", klicka på knappen "Spara till fil". (Figur 2). Ange filnamnet, till exempel new.cf. Därefter gör vi en tredje jämförelse av konfigurationer och när vi jämför, specificera 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 har 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 standardkonfiguration och följaktligen för uppdatering, skulle det vara lämpligt att kommentera alla ändringar som gjorts i konfigurationen, och notera inte bara den ändrade texten i modulerna, utan 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. Detta kan kräva att de ändrade raderna inte överförs, utan att den tillagda (ändrade) koden helt omarbetas för att passa funktionaliteten i 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 att fatta beslut.
Men i vissa fall presenteras uppgifterna i jämförelserapporter på ett sätt som gör det svårt att fatta ett snabbt beslut. Till exempel, vid ändring av typen av detaljer som har en sammansatt datatyp, sammansättningen av de inmatade utifrån objekt osv. Det är i detta skede, på grund av dess komplexitet, som förbättringar går förlorade under uppdateringen. Låt oss överväga denna situation med hjälp av exemplet med detaljer som har en sammansatt datatyp. Vid generering av en rapport om objektjämförelse (Figur 17) presenteras olika data i de jämförda konfigurationerna i form av listor som innehåller sammansättningen av datatyper, separerade med kommatecken. Rapporten visar dock inte alls vilka typer av data som lagts till eller tagits bort. Självklart kan rapporten skrivas ut och "gömmas" för att identifiera skillnader. I det aktuella exemplet finns det cirka 200 sådana objekt.Jämförelseprocessen verkar uppenbarligen vara ganska arbetskrävande och kommer att ta cirka 50 timmar.
För att minska arbetsintensiteten i arbetet när du jämför objekt kan du använda konfigurationen "Jämför celler" som utvecklats av företaget Inform Service. Arbetsintensiteten i arbetet vid jämförelse av sammansatta föremål kan minskas med cirka 20 gånger.
"Cell Comparison"-konfigurationen startas i 1C:Enterprise-läge 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.
Konfigurationsschemat ä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 vilka celler 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å "Jämför"-knappen får vi resultatet av jämförelsen, där de olika positionerna är markerade i färg (Figur 19).
Vidare, baserat på det faktum att jämförelsen utförs enligt samma principer för att jämföra objekt, kommer åtgärdsdiagrammet att se ut så här. Spara nästa rapport under samma filnamn. Klicka på "Uppdatera" och "Jämför" knapparna. En mer detaljerad beskrivning av denna bearbetning finns här "Celljämförelse".
Särskild uppmärksamhet bör ägnas RLS-mallar för ändrade användarroller.
Efter att ha slutfört uppdateringen och överföringen av tidigare gjorda ändringar av standardkonfigurationen kommer vi att utföra syntaktisk kontroll av modulerna och kontrollera funktionen för de ändrade objekten. Efter framgångsrik testning kan konanses vara avslutad. Nu återstår bara att uppdatera externa tryckta formulä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 arbete
I det angivna 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 de ä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örberedande arbete utföras på en kopia av databasen, och resultatet av uppdateringen måste överföras till kundens arbetsdatabas.Först studerar vi noggrant instruktionerna från distributionssatsen. Vi utför det nödvändiga arbetet innan vi uppdaterar arbetsdatabasen.
Om inga konfigurationsändringar utfördes i kundens arbetsdatabas under förberedelsen av uppdateringen, och uppdateringen förbereddes på en aktuell kopia av arbetsdatabasen, sparar du arbetskonfigurationen i en fil, till exempel work_2 för att överföra inställningarna. .cf, genom att välja menyalternativet "Konfiguration" → "Spara konfigurationen till en fil...".
- Med hjälp av work_2.cf-filen överför vi ändringarna. För att göra detta, välj menyalternativet "Konfiguration" → "Ladda konfiguration från fil...";
- På frågan om uppdatering av databaskonfigurationen kommer vi att svara ja.
Om uppdateringen inte förbereddes på en aktuell kopia 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 en *.cf-fil av leverantörens standardkonfiguration (1.2.14.1) och resultatet av uppdateringen i form av även en *.cf-fil. För att göra detta, spara arbetskonfigurationen i en fil, till exempel work_2.cf, genom att välja menyalternativet "Konfiguration" → "Spara konfiguration till fil...".
Ytterligare åtgärder på kundens sida kommer att vara följande:
- skapa en säkerhetskopia av databas;
- Med hjälp av *.cf-filen för standardkonfigurationen för leverantören kommer vi att utföra uppdateringen. För att göra detta, välj menyalternativet "Konfiguration" → "Support" → "Uppdatera konfiguration", "Välj uppdateringsfil", "Slutför" (Figur 10), "Kör";
- Med hjälp av work_2.cf-filen överför vi ändringarna. För att göra detta, välj menyalternativet "Konfiguration" → "Jämför, sammanfoga med konfiguration från fil...";
- Låt oss spara ändringarna i den fungerande konfigurationen och uppdatera databaskonfigurationen. För att göra detta, välj menyalternativet "Konfiguration" → "Uppdatera databaskonfiguration".
Korrekt utförande av detta steg gör att du kan undvika det arbete som beskrivs i steg 1 i framtiden.
Det var en fråga:
Hur många konfigurationer finns det i infobasen?
Rätt svar 3
IS-strukturen inkluderar:
1. Grundläggande konfiguration.
2. Databaskonfiguration.
3. Leverantörskonfiguration(kan vara frånvarande).
4. Plus användardata (dokument, kataloger, etc.)
Konfigurationen bestämmer strukturen på databasen och innehåller algoritmer som säkerställer arbete med data.
Utvecklare arbetar med huvudkonfigurationen. Användare arbetar med databaskonfigurationen.
Leverantörskonfiguration – den initiala konfigurationen av standardlösningsleverantören.
Om infobasen är installerad från en mall och stöds av leverantören, då inne i informationssäkerheten leverantörens konfiguration kommer att hittas.
Om konfigurationen stöds och ändringar av objekt är förbjudna, sedan lagras två konfigurationer i infobasen – den baserade konfigurationen och databaskonfigurationen.
När du aktiverar möjligheten att ändra konfigurationen (kommando Aktivera redigeringsalternativ i dialogen" Ställer in support"), plattform från huvudkonfigurationen skapar leverantörskonfigurationen. Storleken på informationssäkerheten ökar.
Leverantörskonfigurationen är skrivskyddad.
För att se leverantörskonfigurationen, välj
Konfiguration – Support – Supportinställningar – Öppna.
Informationsbasen kan innehålla flera leverantörskonfigurationer, om konfigurationen stöder flera leverantörer. Detta schema uppstår när man använder industricirkulationslösningar.
Grunderna för 1C-stöd
1C-uppdateringen kan göras i användarläge, i konfiguratorläge och i jämförelse- och sammanslagningsinställningar.
Borttagning från support
I dialogrutan "Supportinställningar" när du klickar på knappen Ta bort från support Leverantörskonfigurationen tas bort. Denna funktion måste användas i de fall en standardlösning används som grund för den egna utvecklingen och dess support inte är planerad.
Om du behöver ladda ner leverantörskonfigurationen. Detta kan göras från Support – Supportinställningar. I dialogrutan "Supportinställningar" klickar du på knappen Spara till fil.
I den här artikeln vill jag visa tjänstekapaciteten hos 1C:Enterprise 8-plattformen när det gäller att använda leverantörens konfiguration, som ofta efterfrågas, men som praxis har visat är de inte bekanta för alla nybörjare och till och med erfarna specialister .
Låt oss överväga en typisk situation där nybörjare ofta befinner sig. Låt oss säga att det finns en typisk konfiguration av 1C: Integrated Automation 8. Inledningsvis installerades konfigurationen från distributionssatsen (låt oss säga release 1.1.20.1). Sedan, på grund av behovet av att anpassa sig till företagets särdrag, inkluderades möjligheten till förändring (nykomlingar kallar ofta felaktigt denna åtgärd för att ta bort från stödet, även om så i själva verket inte är fallet).
Och nu, efter en tid, har vi en mycket modifierad, men fortfarande standard (för reglerad redovisning uppdaterade vi regelbundet) konfiguration. Låt oss titta på några hypotetiska situationer:
1) En tid efter nästa uppdatering får vi ett meddelande från ekonomiavdelningen om ett fel som uppstår under den rutinmässiga månadsavslutningen. Det fanns inget sådant fel tidigare, så uppdateringen är skyldig. En ganska typisk situation. Vi börjar diagnostisera felet och ser att benen växer från den allmänna modulen Redovisning för moms och bildande av rörelser. Vi börjar förstå och förstå att den här modulen avsevärt gjordes om till en standard och efter sammanslagningen "tappade" vi några av procedurerna/funktionerna (eller, som ofta händer i standardmodulerna, de "hoppade" in i en annan gemensam modul). På grund av de invecklade vanliga modulerna sinsemellan i standardmoduler är det inte alltid möjligt att identifiera ett problem i uppdateringsstadiet som endast visar sig när användarna arbetar.
Så vi förstår att för att ta reda på det behöver vi en typisk konfiguration av den aktuella versionen (låt oss säga 1.1.23.1). Men var kan jag få tag i det? Om det finns en bekant fransman och han snabbt kan skicka distributionspaketet, bra, men låt oss anta att han inte är där och problemet måste åtgärdas omgående. (Föreslå inte Varese!). Dessutom kanske det inte finns något internet, och vad ska man göra i en sådan situation? Jag har upprepade gånger sett en process där en person, för att lösa ett givet problem, installerade en ny databas från den befintliga initiala distributionen och sedan successivt uppdaterade den till den senaste för att se "hur det egentligen borde vara" i en ren databas. Och kistan, som alltid, öppnades helt enkelt (IMG:)
Låt oss nu titta på olika lösningar:
a) Första alternativet: Meny -> Konfiguration -> Jämförelse av konfigurationer, välj sedan leverantörens konfiguration och jämför den med huvudkonfigurationen.
Överraskande nog finns det de som inte vet om detta. Eller, under alla omständigheter, använd objektet Jämför, kombinera med konfigurationen från filen (har tidigare erhållit/mottagit standarden .cf).
b) Den andra metoden är lämplig om vi inte bara behöver se ändringarna utan också omedelbart utföra sammanslagningen.
Meny -> Konfiguration -> Support -> Supportinställningar och längst ner klicka på knappen Jämför, sammanfoga.
2) En annan situation: låt oss säga att vi ändrade eller raderade någon del av standardkoden, och efter ett tag visade det sig att vi gjorde ett misstag och att vi måste lägga tillbaka allt. Och som ofta händer finns det ingen säkerhetskopia av den sparade konfigurationen innan ändringarna gjordes. Men vi vet med säkerhet att denna kodbit finns i standardkoden, så leverantörskonfigurationen skulle lösa problemet.
Naturligtvis kan du göra samma sak som i det första fallet. Vänta tills jämförelseprocessen har slutförts, och från fönstret för konfigurationsjämförelse öppnar du standardmodulen och kopierar koden därifrån.
Vissa människor gör just det, men om vi har att göra med ett monster som UPP, som också är kraftigt modifierat, kan vi vänta väldigt länge på att jämförelseprocessen ska slutföras. Om vi hade en .cf-fil kunde vi helt enkelt öppna den i konfigurationsfönstret (förresten, inte alla nybörjare känner till den här funktionen heller) och kopiera den nödvändiga koden därifrån.
Och en rimlig fråga uppstår: hur kan du fortfarande spara leverantörens konfiguration till en fil? Varför finns det inget menyalternativ som liknar Spara konfiguration till fil för huvudkonfigurationen eller Spara databaskonfiguration till fil för databaskonfiguration. Var är samma för leverantörskonfigurationen? Faktum är att den finns där också, bara begravd lite djupare. Allt är nämligen i samma form av supportinställningar.
Det är bara det att många människor bara öppnar det här formuläret en gång för att aktivera ändringsalternativet och aldrig återvända till det.
Och i vårt fall var det möjligt att göra det ännu enklare, utan att ens spara konfigurationen i en fil, klicka på knappen Öppna. Effekten är densamma, men mycket snabbare.
Varför annars kan du behöva spara leverantörskonfigurationen i en fil?
3) Tänk på följande situation. Låt oss säga att i det inledande skedet av konfigurationens existens hade standardkonfigurationen inte den funktionalitet vi behövde och ett beslut togs för att förbättra den. Modifieringen var minimal, men i framtiden skapade den ändå besvär vid uppdateringen. Men sedan, efter en tid, upptäcker vi att denna funktionalitet (som var fallet med objektversionering vid en tidpunkt) dök upp i standardversionen (och, som ofta händer, implementerades den i en storleksordning bättre än den "provisoriska" modifieringen ).
Låt mig ge dig några fler exempel på verkliga situationer när du kan behöva återgå till en standardkonfiguration:
1. Ett par gånger stötte jag på konfigurationer där endast layouterna för tryckta formulär var föremål för ändringar. På grund av bristande erfarenhet eller okunnighet tog programmeraren som underhållit konfigurationen, istället för att skapa ett externt tryckt formulär, konfigurationen från supporten och modifierade de inbyggda layouterna (ofta trivialt för att lägga till en företagslogotyp), varefter användarna blev berövade av möjligheten att uppdatera automatiskt.
2. Återigen, på grund av okunskap om standardfunktionaliteten (mycket ofta lider tidigare "sjuårsstudenter" av detta), istället för att använda egenskaper och kategorier, lades detaljer om kataloger/dokument till när det inte fanns någon god anledning till detta (data t.ex. användes endast för utskrift till tryckta formulär).
Naturligtvis är detta inte ett problem om vi har att göra med UT eller annan konfiguration av förvaltningsplaner, där uppdateringar i allmänhet inte är kritiska, men i det här exemplet talade vi om modifierade SCP:er eller komplex automatisering. Och det visar sig att på grund av mindre förbättringar som kunde ha implementerats utan att ta bort fullt stöd, har vi onödiga hemorrojder med standarduppdateringar.
Det finns en rimlig önskan att överge de ändringar som gjorts och sätta konfigurationen tillbaka till fullt stöd. Hur man gör det?
Det enda sättet att återställa konfigurationen till fullt stöd är att ladda (inte i jämförelse- och sammanfogningsläget, utan istället Ladda konfiguration från fil) standard.cf. Det är därför vi behöver möjligheten att spara leverantörskonfigurationen till en .cf-fil. Vi sparar, laddar sedan och efter uppdatering av databaskonfigurationen får vi standardkonfigurationen i dess ursprungliga form, d.v.s. med ett lås (IMG:) Innan du utför dessa åtgärder måste du naturligtvis se till att spara/överföra nödvändiga data, som kommer att "tvättas bort" efter återgång till standardkonfigurationen, och se till att göra en säkerhetskopia av databasen!
Det här är, som det visar sig, enkla möjligheter tillgängliga för utvecklarens arsenal, men okunnighet om dessa tekniker i praktiken kan resultera i många timmar av onödigt krångel som beskrivs ovan. Så de som visste - bra gjort, och de som inte visste - ta det i bruk och spara din tid.
[du måste registrera dig för att se länken]
