Automatiserad validering av konfigurationer ... och några ord om utvecklingsstandarder. Automatisk konfigurationskontroll ... och några ord om utvecklingsstandarder 1c konfigurationskontroll

Faktum är att komplexiteten i 1C-konfigurationer ökar varje år, teamen växer, produkter som innehåller mer än 5 000 000 rader kod släpps. Det blir svårt att arbeta utan att beställa kodströmmarna. Och det handlar inte bara om att upprätthålla en minimiordning – att prefixa nya objekt, överenskommelser om kommentarer eller sprida objekt i delsystem. Med tillväxten av team och komplexiteten i konfigurationer, blir det tydligt behovet av att följa standarder i en bredare mening.

Och för att inte vara skomakare utan stövlar är det bra att ha rätt verktyg för detta ändamål. Intressanta verktyg erbjuds vid konferenser och webbseminarier, inklusive de som anges ovan. Samtidigt förtjänar en ganska föga känd konfiguration från själva 1C också uppmärksamhet. Som du redan förstått från titeln på publikationen kallas denna produkt för "Automated Configuration Checker". Det är gratis, tillgängligt för alla användare (formellt krävs tillgång till ITS för att använda det), ganska lätt att använda, men än så länge inte särskilt utbrett.

Detta beror delvis på det faktum att 1C själv aktivt främjar idén om överensstämmelse med standarder och användningen av lämpliga verktyg endast bland utvecklare av produktionslösningar genom 1C: Compatible-certifieringen. Effekten av idén om efterlevnad av standarder och kodrenhet på den allmänna massan av utvecklare som inte sysslar med massproducerade lösningar är mycket svagare. Även bekantskap med de grundläggande utvecklingsstandarderna är under en villkorad låsning - tillgången till tillgång till ITS (informationen är föråldrad, för närvarande, för 2018-2019, åtkomst är öppen utan registrering) :

Grundläggande information om det agroindustriella komplexet

APK-konfiguration är designad för automatisk sökning fel och avvikelser från standarder i konfigurationer. Användningen har rekommenderats av 1C sedan 2009, och inte bara i företag som utvecklar cirkulationslösningar, utan även för andra företag där standardlösningar håller på att färdigställas och anpassas:

Det första intrycket av konfigurationen kan ges av sidan på 1C-webbplatsen:

Den beskriver huvudfunktionerna i detta verktyg och säger att det hjälper:

följa typiska utvecklingsstandarder och utföraer

skapa och följ dina egna regler för konfigurationsvalidering

uppfylla de standarder som krävs för att erhålla 1C: kompatibel status

utföra schemalagda kontroller

kontrollera stavfel

tilldela olika statusar till upptäckta konfigurationsfel, inklusive att markera dem som "funktioner" som inte kräver korrigering

underlätta verifieringsprocessen något genom att själv utföra vissa åtgärder som att uppdatera demodatabasens konfiguration från förvaret, möjligheten till en steg-för-steg-verifiering, etc.

även möjligheten till integration med DSS nämns

En annan källa allmän information kan fungera som en publikation i onlinetidningen PCMagazine:

Förutom dessa översiktsmaterial finns det nästan ingen information på webben om APK och dess applikationer. Den goda nyheten är att en PDF-användarmanual medföljer själva konfigurationen. Vissa frågor behandlas inte i manualen så detaljerat som vi skulle vilja. Men det finns fortfarande en manual och den låter dig lära dig hur du utför grundläggande tekniker när du arbetar med konfiguration.

För att inte upprepa användarguiden kommer vi här att överväga ett exempel på hur man använder APK för att kontrollera en typisk konfiguration, och inte en demokonfiguration från APK-leveransen. Vi kommer också att försöka överväga detaljerna i arbetet, som inte nämns i manualen.

Låt oss börja från början. Ladda ner senaste versionen APK finns på följande länk:

Vid tidpunkten för publiceringen av denna artikel är den senaste utgåvan 1.1.12.26 från 30/01/17, men till en början skrevs den för version 1.1.11.16, så några skärmdumpar och kommentarer kommer att referera till denna version. För att arbeta med APK 1.1 behöver du en plattformsversion på minst 8.3.6. Efter installation av konfigurationsleveransen visas tre nya objekt i listan med konfigurationsmallar:

Den första mallen är en ren APK-databas. Alla standardregler finns i den, men det finns ingen laddad demodatabasdata för testning, som finns i den andra mallen.

Den andra mallen "Automatisk konfigurationskontroll (demo)" efter implementering innehåller den laddade informationen om demodatabasen (finns i den tredje mallen). Du kan använda den för att se hur rapporter och standardkontroller fungerar. Det är bäst att lära sig hur man arbetar med denna databas med den medföljande användarmanualen, eftersom exemplen i manualen är utformade specifikt för denna demodatabas:

APC:n fungerar på ett sådant sätt att den, när den utför nya kontroller, laddar information från den kontrollerade konfigurationen via en COM-anslutning. För att göra detta behöver den en befintlig fil "experimentell" databas. Därför, om det finns en önskan att inte bara bekanta sig med gränssnittet för demodatabasen, utan att utföra en hel cykel av att arbeta med databasen som testas, är det vettigt att också distribuera ytterligare en fildatabas från den tredje mallen "Demokonfiguration för testning".

I det här fallet kommer vi att få två databaser - en demo agroindustriellt komplex med redan laddad information om den kontrollerade demobasen och den kontrollerade demobasen själv, vilket gör att du snabbt kan bekanta dig med processen att ansluta och genomföra nya kontroller.

Jag skulle vilja notera att efter att ha experimenterat med demobaser kanske en ren bas av det agroindustriella komplexet inte kan användas. Arbetande konfigurationskontroller kan utföras på samma konfiguration som demodatabaskontrollerna. I APK-filen kan du ladda ner information om valfritt antal databaser som ska kontrolleras.

I allmänhet liknar principen för APK-driften arbetet med "Datakonvertering". Arbete i APK-konfiguratorn krävs inte (även om det, som det kommer att framgå senare, knappast kommer att gå att klara sig utan det alls)... Information om strukturen för de kontrollerade konfigurationerna laddas i användarläge. Den specificerar också algoritmerna för att kontrollera konfigurationen i form av en kod i 1C: Enterprise-språket, som sedan exekveras av systemet självt med operatören " Kör”. I koden kan och bör du använda de inbyggda APK (icke-plattform) metoderna - procedurer och funktioner som utför arbete med automatiskt skapade objekt. De objekt som krävs för att utföra konfigurationskontrollen skapas av systemet självt och blir tillgängliga i kontrollhanterarnas kod. En detaljerad beskrivning av dessa metoder, objekt och hanterare kan erhållas från det sjätte kapitlet i "User's Guide".

Konfigurationen av AIC är nästan helt baserad på referensböcker, informationsregister och bearbetning. I allmänhet, om du är bekant med "Datakonvertering", kommer principerna för att arbeta med APK:n att vara tydliga. Dessutom, om det inte finns något tydligt behov av våra egna kontrollalgoritmer, kommer det till en början att vara möjligt att begränsa oss till standardkontroller och inte studera systemets inbyggda metoder och programobjekt. Då kan nästan alla inställningar göras med musen och det verkar som att detta kommer att räcka för många uppgifter.

Konfigurerar anslutning till den markerade basen och standardkontroller

Efter att ha startat demodatabasen ser vi följande gränssnitt:

Syftet med avsnitten ur APK-utvecklares synvinkel finns i manualen. Vi går i ordning och lägger till en ny konfiguration först. Klicka på knappen "Ny konfiguration". Systemet kommer att uppmana dig att fylla i anslutningsparametrarna. Faktum är att formen för katalogobjektet "Konfigurationer" öppnas:

Namnet och det fullständiga namnet är godtyckliga textfält, bara känslan av skönhet och längden på fältet kan begränsa dig i vad som kommer att anges i dem. Men ytterligare restriktioner är strängare. Du måste ange hela sökvägen till körbar fil plattformar 1C. I mer tidigare versioner APK måste du dessutom ange vilken version av plattformen du arbetar med. Låt mig påminna dig om att APK bara kan kontrollera konfigurationer på plattformsversion 8.3.6 och högre.

Information från utvecklarna:

Om sökvägen till plattformen anges nedan, kommer ett fel att genereras under COM-anslutningen.Anledningen är följande. I samband med utvecklingen av plattformen och nya kontroller av APK:n samlas information (metadataegenskaper) in som endast förekom i plattform 8.3.6 eller högre. Sålunda, när man kontrollerar mot versioner, till exempel, 8.2, när man samlar in sådan information, kommer naturligtvis ett fel att utfärdas. Och eftersom dessa nya kontroller som regel är prioriterade är förbudet mot att starta en skanning lägre än 8.3.6. I det motsatta fallet (om huvudversionen av plattformen är lägre för klienten), antas det att han kan använda för att kontrollera sin konfiguration tidigare versioner Agroindustriellt komplex.

Därefter måste du ange sökvägen till demodatabasen och parametrarna för att ansluta till den. Under demobas i det här fallet menar vi inget annat än en speciellt dedikerad filbas som innehåller den kontrollerade konfigurationen. Det finns inga möjligheter att ansluta en SQL-databas till APK. Detta kan förbättras om så önskas, men det är inte så vettigt. För det första är det bara en konfigurationskontroll, inte enhetstestning eller lasttestning. I det här fallet, även för stora konfigurationer som ERP 2, räcker det med en tom fildatabas som innehåller den aktuella konfigurationen. För det andra, i enlighet med 1C-standarderna, bör alla konfigurationer utformas för att fungera inte bara med en SQL-databas, utan också i en filversion.

Om du utvecklar med hjälp av förvaret kan APK-filen automatiskt uppdatera databaskonfigurationen från förvaret innan ett nytt test utförs. Den nedre gruppen av parametrar i skärmdumpen är avsedd för detta.

Observera också att DSS, liksom APK, kräver en filbas för att ladda konfigurationsinformation. Därför, om du bestämmer dig för att utveckla med tekniken som erbjuds av 1C, med APK och DSS, kommer det att räcka för båda dessa system att skapa en filbas, om nödvändigt, ansluta den till konfigurationsförrådet och konfigurera automatisk uppdatering konfiguration från lagring innan data laddas.

Valet mellan lägena "Konfiguration" och "Bibliotek" avgör hur allvarliga kontrollerna är. För läget "Bibliotek" är kontrollerna tuffare. Ett bibliotek är en konfiguration som kan bäddas in i andra, vilket innebär att det måste uppfylla vissa regler och "inte bara tänka på sig självt". Om du för markören över båda alternativen för omkopplaren kommer en ledtråd med en beskrivning av kontrollskillnaderna att dyka upp. I synnerhet kommer alla valda krav att kontrolleras för biblioteket. Krav från gruppen Utveckla och använda bibliotek kontrolleras inte för konfiguration, oavsett om de är valda eller inte. Denna grupp av krav innehåller mycket långsiktiga valideringsregler som egentligen bara gäller bibliotek.

En viktig punkt för version 1.1.11.16 och tidigare versioner av APK (i version 1.1.12.26 har detta fel åtgärdats). Efter att inställningarna har angetts och posten i katalogen "Konfigurationer" har skrivits ner, kan du kontrollera anslutningen. Men för första gången kan systemet ge ett felmeddelande om bristen på anslutning.

Detta är ett missvisande meddelande. Om sökvägarna och användarna är korrekt inställda behöver du bara spela in elementet i denna katalog i förväg och först därefter kontrollera anslutningen. Sedan kommer systemet att rapportera om den lyckade anslutningen. Att kontrollera anslutningen till en stor databas, till exempel ERP, kan ta upp till 1-2 minuter:

Nu har vi faktiskt skapat ett nytt objekt i katalogen "Konfigurationer". Nu kan du öppna den på olika sätt:

• Via menyn "Inställningar" -> "Konfigurationer"

• I avsnittet "Kontroller" klickar du på "Välj konfiguration"

• Eller bara öppna katalogen "Konfigurationer" via menyn "Operations".

Låt oss gå tillbaka till fönstret för konfigurationsinställningar.

På den andra fliken "Krav som ska kontrolleras" kan du konfigurera vilka kontroller vi vill utföra på vår konfiguration. Det finns två fördefinierade alternativ tillgängliga: "Fullständig kontroll" - kontrollera efterlevnad av standardsystemet https://its.1c.ru/db/v8std och stavningskontroll, samt "1C: Compatible" - kontrollera efterlevnad med 1C: Compatible standards http://1c.ru/rus/products/1c/predpr/compat/soft/requirements.htm

Du kan också ställa in en godtycklig uppsättning krav som ska kontrolleras, sedan köra in en godtycklig representation av en variant i fältet "Verifieringsvariant" och spara den under detta namn genom att klicka på knappen "Spara variant". Varianter sparas i förhållande till konfigurationer, det vill säga samma inställning kan inte tillämpas automatiskt på andra element i katalogen "Konfigurationer":

Låt mig göra en anteckning för dem som planerar att använda APK för flera konfigurationer och inte vill ställa in kontroller för var och en av dem separat. Du kan överföra kontrollinställningar mellan konfigurationer genom att skriva ett enkelt skript, om du vet att de är lagrade i informationsregistret "Konfigurationskrav", och själva kontrollalternativen lagras i referensboken med samma namn:

Listan över kontroller är ganska omfattande. Varje krav är en utvecklingsstandard som kan göra våra produkter bättre. Men möjligheten att inaktivera individuella krav eller deras grupper är inte heller överflödig. Till exempel, på de flesta företag kan du begränsa dig till alternativet "Fullständig kontroll" (stavning + standardsystem) och inte göra kontroller för "1C: kompatibel". Eller åtminstone kontrollera stavningen, eftersom det inte finns något sådant att utveckling har genomförts i åratal utan ett enda stavfel.

Listan med krav som väljs här är standardlistan för automatiska kontroller. När du går igenom testet kan du åsidosätta de värden som anges här.

Information från utvecklarna:

Det är vettigt att berätta mer i detalj vad gruppen "System of Standards" är och hur den skiljer sig från de andra två grupperna. Så låt oss börja med gruppen "1C: Compatible". Som tidigare skrivits är detta en obligatorisk uppsättning standarder för att få en viss status för dess konfiguration. Grovt sett är detta ryggraden som alla konfigurationer utan undantag måste motsvara. Förresten, denna grupp av standarder kontrollerar inte konfigurationen för stavfel ...

Ytterligare "Stavning" är en grupp standarder som kontrollerar konfigurationen endast för stavfel. Varje utvecklare med självrespekt kan stavningskontrollera sin konfiguration. Den här gruppen innehåller alla kontrollregler som spårar stavning i modultexter, metadata (namn, synonym, kommentar), formulärelement, layouter i allmänhet, varhelst du kan kontrollera text. Ur lådan är bara den ryska texten markerad, men som korrekt noterat i kommentarerna, för andra språk kan du ladda dina ordböcker och till och med ersätta den medföljande konfigurationen med dem.

Och nu om gruppen "System of Standards". Det är den mest globala och innehåller kontroller för de andra två fördefinierade kravgrupperna, samt ytterligare specialiserade kontroller. För klienter är fel i denna grupp mer sannolika rekommendationer, även om för typiska konfigurationer, de flesta fel naturligtvis måste korrigeras. Den där. om någon standard beskrivs i gruppen "1C: Compatible" eller "Stavning" kommer den utan tvekan att beskrivas i gruppen "System of Standards", dock kanske mer detaljerat och med djupare kontroller.

Olika filtrering konfigureras på fliken "Scan excludes". Till exempel kan du konfigurera kontroller så att endast objekt du har lagt till i standardkonfigurationen med ett specifikt prefix som " mf_ Supertulldeklaration”.

Eller, om du utvecklar med tillägg av alla ändrade eller tillagda objekt till ett visst delsystem för utveckling, då är det vettigt att kontrollera endast inom detta delsystem och kringgå de oförändrade objekten i den typiska konfigurationen som är låsta. Om du tillfälligt behöver utesluta ett konfigurerat filter under kontroller behöver du inte ta bort det. Det räcker med att avmarkera användningsflaggan (andra kolumnen):

Filtreringsfunktionen är mycket användbar och det är vettigt att experimentera med den, vilket vi kommer att göra härnäst. Jag måste genast säga att tillåtande kontroller som "Inkludera ett undersystem" och "Inkludera med ett prefix" fungerar med "ELLER". Det vill säga, ett objekt kommer att kontrolleras om det uppfyller ett eller annat villkor. Detta är inte alltid bekvämt. Lyckligtvis är det väldigt enkelt att ändra detta beteende. Denna fråga kommer att diskuteras mer i detalj i avsnittet som ägnas åt filtrering, liksom frågan om filters effekt på tidpunkten för kontroller.

I APK-version 1.1.11.16 och tidigare versioner var filtreringsinställningarna uppdelade i två flikar - "Kravsamlingsfilter" och "Undantag för datainsamling", men innebörden var densamma:

I inställningsformuläret kan du också ställa in behovet av schemalagda kontroller:

Detta är inställningen att inte arbeta igenom en schemalagd uppgift... För att köra en schemalagd genomsökning måste APK:n köras i användarläge och fungera. Vid starten av systemet i modulen regelbunden tillämpning metod kallas Vid StartSystem () där väntehanteraren är ansluten RunCheckScheduled (), som utför schemalagda kontroller. Om det finns en önskan att starta en kontroll med en rutinuppgift måste systemet modifieras. Om du tittar på konfigurationen av APK:n kan du se att den bara innehåller två schemalagda uppgifter, och båda är inte relaterade till schemalagda kontroller:

Information från utvecklarna:

Förklaringen är väldigt enkel. Om APK:n distribueras i SQL-versionen, när du anger sökvägen till konfigurationen (mer exakt, demodatabasen) på klienten, kommer kontrollen helt enkelt inte att starta, eftersom det schemalagda jobbet körs alltid på servern. I filversionen av det agroindustriella komplexet skulle naturligtvis ett schemalagt jobb vara mer lämpligt än en väntehanterare.

Schemat är inte den sista möjliga fliken. Om du aktiverar integrationen med "Applied Solutions Design System" i systemet, kommer en annan flik "Integration with DSS" att visas, som låter dig konfigurera den automatiska registreringen av fel i DSS. Integrationsinställningar på systemnivå utförs i form av konstanter ("Operations" - "Konstanter").

Funktionaliteten för integration med DSS var avsedd av utvecklarna av det agroindustriella komplexet för internt bruk i 1C (detta beskrivs i "Användarguide", sidan 28). Jag är dock säker på att för de företag som redan använder DSS i sitt arbete eller planerar att använda det, kommer denna funktionalitet att vara intressant. Du kan ta det som ett exempel för att implementera din egen integrationsmekanism eller ta itu med det och använda det direkt:

Samtidigt är det möjligt att både koppla det agroindustriella komplexet till webbtjänsten upplyft från sidan av DSS, och vice versa, du kan konfigurera anslutningen till webbtjänsten som ligger på sidan av den agroindustriella komplex i DSS:

Genomföra besiktningar

Efter att anslutningsinställningarna har gjorts och vilka kontroller som ska utföras har valts kan du gå vidare till kontrollerna.

För att utföra en ny kontroll måste du först göra den kontrollerade konfigurationen aktuell. Alla nya kontroller utförs på den "nuvarande konfigurationen". För att göra detta, i avsnittet "Kontroller", klicka på "Välj en konfiguration" och välj sedan ett element i konfigurationskatalogen som kommer att tilldelas "aktuell".

När du klickar på knappen "Ny kontroll" kommer systemet att erbjuda två alternativ - att kontrollera igen genom att ansluta till den markerade konfigurationen, samla in data igen eller kontrollera tidigare insamlade data.

Möjligheten att utföra kontroller av tidigare insamlade data möjliggör en steg-för-steg-implementering av långa kontroller. Till exempel kan du först samla in konfigurationsdata och utföra en filtrerad kontroll av delsystemsdelen. Slå sedan på filter för andra delsystem och gör den andra kontrollen baserat på tidigare insamlade data, vilket gör att du kan utföra det mycket snabbare.

Information från utvecklarna:

Det ska också sägas här att nu är sammansättningen av de insamlade uppgifterna direkt beroende av de valda kraven. Till exempel är ett krav "Stavning i modultexter" valt. Om du öppnar kortet för själva kravet och går till fliken "Verifieringsstadier" kan du se att endast 1 kryssruta "Fyll i information om moduler" är markerad:

Detta innebär att vid kontroll av konfigurationen för stavning i modulernas texter kommer endast insamlingen av modulernas texter att utföras (varken egenskaperna för metadataobjekten, inte heller formulärelementen eller layouterna kommer att samlas in - allt typer av informationsinsamling kan väljas av de andra flaggorna).

Denna funktionalitet av beroendet av den insamlade informationen på de valda kraven dök upp relativt nyligen, tidigare, med varje kontroll med datainsamling, samlades all information in. Så tidigare hjälpte det här alternativet mycket: något krav valdes, till exempel samma moduler, all information samlades in, fel korrigerades för detta krav, sedan valdes nästa krav, till exempel stavning i formulärelement, och kontrollen påbörjades redan enligt de insamlade uppgifterna, eftersom formelement ändrades inte osv.

Nu kan den också användas, men endast de krav som samlats in tidigare kan kontrolleras mot den insamlade datan. Tja, man kan inte annat än säga att detta verifieringsalternativ är extremt nödvändigt för utvecklarna av nya kontroller för att felsöka, testa, påskynda och identifiera felaktigheter i verifieringsreglerna, eftersom inget behov av att bygga om data varje gång.

Eftersom vi ännu inte har samlat in någon data kommer vi att välja posten "Samla in och verifiera data ...". Ett fönster öppnas där du kan välja att genomföra eller automatisk kontroll, enligt inställningarna som tidigare gjorts i det nya konfigurationsfönstret, eller åsidosätt dessa inställningar. Att välja alternativet "Manuell" är särskilt bekvämt i det inledande skedet av bekantskap med systemet, när du kan påverka varje nästa steg.

Genom att klicka på knappen "Nästa" kan du åsidosätta alla inställningar som beskrevs i föregående avsnitt av denna publikation, inklusive de kontroller som utförts. Det bör dock komma ihåg att om du inte väljer en enda kontroll vid lämpligt steg, kommer systemet att överväga att du behöver utföra ALLA kontroller, och inte bara ansluta och ladda ner information om objekt från databasen som kontrolleras:

Därför, om syftet med lanseringen inte är en fullständig kontroll, utan att uppdatera konfigurationsstrukturen eller en testkörning av APK-filen och bekanta dig med processen, bör du inte avmarkera alla rutorna i detta steg. För första gången är det lämpligt att endast markera ett element, till exempel - "Konfiguration av plattformskontroll" i följande gren:

I det här fallet kommer listan över verifieringssteg att vara ungefär som följer:

och kan ta så lite som 20 minuter även på ERP. Men detta kommer att räcka för att få en uppfattning om hur processen faktiskt går till. Även om plattformsvalidering kan vara en överraskning och ta lång tid, kan du välja ett annat element som är enklare.

På det sista steget Du kan också ställa in filter på skannade objekt. Det är sant, om detta är den första kontrollen av konfigurationen, kommer AIC:n ännu inte att ha information om konfigurationsstrukturen. I det här fallet kommer konfigurationsträdet i detta steg att vara tomt, men det kan laddas genom att klicka på knappen "Läs konfigurationsstruktur" direkt från samma fönster:

Nu återstår att trycka på knappen "Utför kontroll". Verifieringsprocessen börjar. Med blinkande av 1C-fönster och utmatningen av processloggen till meddelandefönstret. Loggutgången är mycket obekväm. Kontrollfönstret hänger modalt, och om du inte i förväg tänker på att göra meddelandefönstret synligt, kommer du inte att kunna ta reda på något om vad som händer förrän processen är slut:

Därför, om du har en låg skärmupplösning, är det bättre att omedelbart ta hand om att flytta modalt fönster kör skanningen så att meddelandefönstret är synligt.

I ett av verifieringsstadierna uppdaterar systemet innehållet i katalogen "Konfigurationsstruktur", som innehåller ett träd (hierarki) av metadataobjekt som i konfiguratorn. Data om ett specifikt objekt kommer att uppdateras om detta objekt har ändrats eller inkluderats i ett ytterligare delsystem. Ett katalogobjekt kommer att markeras för radering om motsvarande konfigurationsobjekt har tagits bort. Nya objekt kommer att skapas för nya konfigurationsobjekt:

Under varje kontroll med datainsamling uppdateras också innehållet i registren "ObjectPropertyValues" och "CompactObjectPropertiesValues", som lagrar objektegenskaper, moduler, layoutinnehåll, formulärelement etc. När den kontrolleras mot tidigare insamlad data, förblir denna information densamma.

Om några kontroller väljs som inte bara kräver uppdatering av metadatastrukturen och plattformsverifiering, utan också något mer, kommer systemet att ladda ner konfigurationen i filer för efterföljande analys:

Uppladdning sker utan hierarki - alla filer finns i en mapp:

Information från utvecklarna:

Så, vad och när kommer ( vid kontroll med datainsamling):

• Konfigurationsstrukturen är i allmänhet alltid, oavsett vilka krav som väljs.
• Insamlingen sker genom löpning extern bearbetning från den generiska layouten MetadataStructureLoader i företaget i den tjocka klienten. Enterprise processing arbetar med Metadata-plattformsobjektet och skriver data till en extern fil, som sedan överförs och tolkas till APK.

Alla ytterligare steg som utlöser extern bearbetning i företaget fungerar på liknande sätt. Resten av informationen, som nämnts ovan, samlas in beroende på de valda kraven:

• Insamlingen av information om metadata (återigen, dessa är egenskaper hos metadataobjekt, och inte själva strukturen) utförs genom att starta extern bearbetning från den allmänna layouten "MetadataDataLoader".
• Samla information om formulär (mer exakt, om formulärelement) - med hjälp av bearbetning från layouten "FormDataLoader".
• Insamlingen av information om formulär från XML sker genom att tolka XML-filen för formuläret från att ladda konfigurationen till XML-filer... All information som inte kunde erhållas från företaget i föregående skede samlas in.
• Samla information om moduler - genom att läsa modultexter från XML-uppladdningsfiler.
• Samla information om roller (mer exakt, samla in rättigheterna för varje roll för varje objekt) - från XML-uppladdningsrollfilerna.
• Samla information om layouter - med hjälp av bearbetning från layouten "LayoutDataLoader".
• Samla hjälpinformation - genom att läsa hjälpfilerna från XML-uppladdningsfilerna.

Plattformsverifiering av konfiguration - batchstart av demodatabasen i konfiguratorläget med plattformsverifieringsnycklar. Filen med kontrollloggen indikeras också. Sedan förstår den APK:n, och den producerar plattformsvalideringsfel, som lagras i ett separat "ConfigurationVerification Errors"-register.

Således, om minst ett krav är markerat med kryssrutan för att samla in information om formulär från XML, roller, moduler eller hjälp, kommer den kontrollerade basen att dumpas i XML-filer. Om ingen av dessa åtgärder krävs kommer uppladdningen inte att ske.

Tidigare utfördes alla åtgärder sekventiellt. Först startade insamlingen av strukturen, sedan uppladdningen till XML, sedan plattformsvalideringen, sedan insamlingen av metadataegenskaper, moduler, formulär etc., vilket kraftigt bromsade valideringen (datainsamlingen) av stora konfigurationer.

I APK 1.1.12 tillkom kopiering av källdatabasen till en tillfällig katalog och de längsta stadierna av datainsamlingen identifierades, vilket gjorde det möjligt att parallellisera datainsamlingen under verifieringen. Således, för tillfället, insamling av konfigurationsstruktur, plattformsvalidering, avlastning till XML och rensning av register utförs parallellt. Resten av stegen tar lite tid, även för ERP. Som ett resultat av införandet av parallell informationsinsamling var det möjligt att snabba upp ERP-kontrollen med minst ett par timmar.

I katalogen för temporära filer genereras och öppnas bearbetning i den markerade basen, som skapar instanser av metadataobjekt och skapar formulär och objektlayouter. Denna mekanism var ursprungligen avsedd att samla in information om formulär, layouter och metadataegenskaper. Men också tack vare det letar man efter fel som inte ens låter dig skapa ett objekt eller formulär programmatiskt. Naturligtvis är detta långt ifrån enhetstestning, men redan något:

Om det i en objekt- eller formulärmodul görs ett försök att komma åt en odeklarerad variabel eller ett objekt som är oåtkomligt från modulkontexten, kommer systemet antingen att stoppa i processen att kontrollera med ett fel (det kommer att finnas ett fönster i den öppnade kontrollerade databasen) , eller så kommer APK-filen att fånga det här felet och visa det i rapporter. Om APK-filen stannar under verifieringsprocessen på grund av ett sådant fel, är det verkligen inte särskilt bekvämt. Men å andra sidan är förekomsten av modulkompileringsfel ett kritiskt fel för programmerare och det är bättre om det upptäcks med hjälp av APK på ett sådant sätt än att det kommer i produktion och ett meddelande om det kommer från användarna!

I processen med en fullständig kontroll (eller dess analoga när det gäller antalet regler och objekt), fastnar systemet på att kontrollera objekt # 1 utan att informera om framstegen på något sätt:

Denna status med meddelandet att objekt # 1 av 77 tusen kontrolleras hänger i 5-10 timmar och det verkar som att det agroindustriella komplexet är fruset. Faktum är att processen pågår, du kan verifiera detta genom att titta på processorbelastningen i aktivitetshanteraren eller genom att anropa stopp från konfiguratorn (om APK-filen startades från den). Orsaker lång check Objekt nummer 1, nämligen själva konfigurationen, är följande:

1) Som en del av detta steg samlas och cachelagras information som används vidare vid kontroller av enskilda objekt. Detta gör det snabbare att kontrollera resten av objekten.

2) De flesta kontroller som påverkar alla konfigurationsobjekt på en gång utförs inom detta steg. Det finns många sådana kontroller, cirka 90. Men den mest långa, tar det mesta av tiden, bara ett par. Till exempel "Hitta oanvända exportmetoder för tjänster"... Uppenbarligen är det omöjligt att sluta sig till huruvida metoden för ett enskilt objekt används eller inte genom att endast kontrollera det ena objektet eller något särskilt delsystem. Denna slutsats kan endast dras genom att analysera metodanrop över hela konfigurationen. Och det är uppenbart att det är optimalt att kringgå hela konfigurationen en gång, när du kontrollerar "Objekt nr 1", och inte många gånger, när du kontrollerar enskilda dokument och kataloger. Ett annat exempel på en långvarig kontroll är "Kontroll av förekomsten av en gemensam modul, delsystem, metod och kontroll av sammansättningen av parametrar".

Om du stänger av två specificerade kontroller och plattformsverifiering av konfigurationen, sedan kan verifiering av även en sådan konfiguration som ERP inte ta mer än en halvtimme. Men du ska nog inte spara tid och offra kvalitet. Det är bättre att lösa detta problem organisatoriskt och göra kontroller i förväg.

Jag ger ett exempel - början och slutet av kontrollexekveringsloggen, som visar att hela processen på ERP 2.1 och APK 1.1.11.16 tar cirka 15 timmar (naturligtvis beror siffran starkt på datorns prestanda, också verifieringshastigheten på APK 1.1.12 är mycket högre och under samma förhållanden tar det cirka 10 timmar):

: Kontrollera anslutningen till infobasen via en COM-anslutning

: Börja samla in information om konfigurationens metadatastruktur

: Börja ladda upp konfigurationen till XML-filer

: Börja rensa upp metadatainformation

: Börja samla in information om konfigurationsroller

: Samlad och registrerad information om konfigurationsroller

: Samlad information om konfigurationsmetadata

: Konfiguration av plattformskontroll slutförd

: Börja testa konfigurationsobjekt

: Börja samla in information om konfigurationsformulär från XML-filer

: Konfigurationskontrollen har påbörjats

…… … HÄR BÖRJAR MEDDELANDEN VISAS I STATUSRADEN… ..

: Konfigurationskontroll utförd

Resultat av kontroll

Vad får vi som resultat av den första kontrollen? Först fylls katalogen med konfigurationsversioner i (katalogen "Versions" är underordnad katalogen "Konfigurationer"). Ett element som motsvarar versionen av den markerade konfigurationen visas i den. Versionsinformationen uppdateras också i form av katalogposten "Konfigurationer":

För det andra skapas ett dokument av typen "Konfigurationskontroll", som specificerar detta element i katalogen "Versions" och andra kontrollparametrar - listan över kontrollerade krav, uppsättningen av kontrollerade objekt och "Kontrollloggen", som duplicerar logg som visades tidigare i meddelandefönstret:

För det tredje uppdateras data om konfigurationsstrukturen:

Konfigurationsstrukturen är en hierarkisk katalog med en hierarki av element, underordnad katalogen "Versions", det vill säga när du kontrollerar konfigurationen ny version ett nytt element i "Versions"-katalogen kommer att skapas och en ny metadatastruktur kommer att laddas i förhållande till denna version.

Och för det fjärde fylls registret "Found errors" i, som faktiskt innehåller information om vilka fel som hittades under verifieringsprocessen och som ligger till grund för AIC-rapporter:

Inget listformulär har skapats för detta register. Soptippen i denna gemensamma registerpanna kan ställas i ordning på bara några minuter. Till exempel, lägg till ett hanterat formulär, i användarläge eller direkt i konfiguratorn visa ägaren av objekten (element i "ConfigurationStructure"-katalogen), till vilka fel är kopplade. Dessa ägare kommer att vara konfigurationsversionerna.

Om vi ​​visar ägarna och från dem får vi i form av en lista möjligheten att filtrera fel både efter konfigurationer och efter deras versioner. Du kan göra grupperingar på dem. I det här fallet kommer det att vara möjligt att arbeta med fel inte bara med hjälp av rapporter, utan också direkt genom registret, vilket ibland är mycket bekvämare:

Varje post i detta register är ett hittat avvikelse, stavfel eller annat fel. Genom att öppna någon av dem kan du se till att även sådana tillförlitliga och beprövade system som ERP 2.1;)) innehåller stavfel och fel. Dessutom ett ganska stort antal av dem:

Jag skulle vilja att vi ska uppfatta förekomsten av sådana fel i ERP inte som en överseende för deras närvaro i vår utveckling, utan som ytterligare bevis på att de kan och bör identifieras och elimineras. Speciellt med rätt verktyg. För de ser fula ut och det är precis vad våra användare ser. 1C-bloggen på Habré noterar att ERP 2-utvecklare använder agroindustriellt komplex för att kontrollera konfigurationen, men uppenbarligen begränsar listan över kontroller till de viktigaste reglerna ur deras synvinkel, vilket säkerställer ett acceptabelt förhållande mellan utvecklingshastighet och produktkvalitet. Vi kan, när vi utvecklar våra produkter, höja ribban för kvalitet och fånga även detta område.

Det kommer också att vara användbart att veta att den insamlade informationen om modultexter, modulblock och andra egenskaper för konfigurationsobjekt placeras i registren "Värden av sammansatta egenskaper hos objekt" och "Värden av egenskaper hos objekt". Posterna lagras tillsammans med alla samma objekt, subversioner och konfigurationer:

Du kommer inte att kunna se modultexterna direkt från registerformulären, de är alla packade i värdebutiker.

Men för att se texterna i moduler, redan uppdelade i komponentdelar, och andra egenskaper för konfigurationsobjekt i APK finns ett underbart verktyg! Detta är bearbetningen "Visa egenskaper för konfigurationsobjekt", som öppnas via menyn "Inställningar":

APK rapporterar

Information om de fel som hittats i form av rapporter gör att du kan få två delar av systemet samtidigt. Avsnitt "Fel":

Den bygger på FoundErrors-rapporten:

Och avsnittet "Rapporter"

Den är byggd på grundval av rapporten "Arbetsresultat":

Faktum är att det bara finns två huvudsakliga "Rapport"-objekt i AIC-konfigurationen. Men de har en hel del olika ACS-layouter:

Alla är baserade på analysen av informationsregistret "FoundErrors". Avsnittet ”Rapporter” är avsett för att få sammanfattande information om fel, den har ett statistiskt fokus, medan avsnittet ”Fel” är till för att få detaljerad information om fel och deras hantering. I avsnittet "Fel" är kontroll möjlig både med hjälp av en speciell kommandopanel och genom snabbmenyn:

Det finns ett problem när du använder APK-filbasen och 32-bitars 1C-plattformen. Om du inte installerar ett tillräckligt antal filter kan du få ett meddelande om att minnet är slut när du analyserar stora konfigurationsfel. I fallet med ERP 2.x kommer detta meddelande att dyka upp konstant. Detta fel inträffar vanligtvis redan i det skede då data matas ut till ett kalkylarksdokument. I allmänhet är det värt att sätta filter. Endast ett fåtal av dem ingick i de snabba tacklingarna. Resten kan ställas in med kommandot "Rapportinställningar".

Det står i vägen för att rapporter börjar genereras direkt efter att man valt ett alternativ. Detta stör arbetet kraftigt och tyder på att det är nödvändigt att förbättra konfigurationen av det agroindustriella komplexet fram till att du skriver dina egna rapporter: du skulle vilja införa urval innan de genereras och så att rapportinställningarna sparas, och det på hanterad form de var. Lyckligtvis, baserat på bara ett register över uppgifter, är detta inte svårt att göra.

Anteckna det när du använder en 64-bitarsversion av 1C eller sql-databas av APK, observeras inte ett fel med otillräckligt minne.

Vid en första blick på rapporterna verkar det som om APC:n är för kräsen med den kontrollerade konfigurationen. Till exempel kräver det att man ställer in korrekta synonymer även för layouter tryckta blanketter, uppfattar som ett misstag orden "logistisk", "lägg till", "ansvarig" etc. Men först måste de flesta av de hittade felen verkligen åtgärdas! För det andra är valet av regler som ska kontrolleras till användaren, det kan göras både när du ställer in den kontrollerade konfigurationen och när du utför en kontroll. För det tredje kan var och en av reglerna, om så önskas, ändras, ersättas med din egen, eller så kan du ställa in filtrering i rapporter på ett sådant sätt att du bara ser den information som är av intresse.

Slutligen finns det andra anpassningsalternativ i systemet. Till exempel informationsregistret "TrueWords" (inledningsvis tomt). Den deltar i stavningskontrollen, särskilt metoden Check.Check Spelling (). De ord som vi tror är korrekta kan matas in manuellt eller laddas ner från textfil där varje ord finns i separat linje... Ett exempel på en sådan txt-fil kan laddas ner från den allmänna layouten "Dictionary of True Words". Men du behöver inte ladda den här filen i registret. Som standard tar systemet de rätta orden från denna layout och kompletterar den med data från registret. Det finns också en bearbetning i systemet " Uppdatering av ordbok". Dess användning beskrivs mycket detaljerat och tydligt i användarmanualen (se kapitel 4.6).

I allmänhet, om det verkar som att systemet är för strikt för våra konfigurationer, kan du justera det på rätt ställen och "cajole"))

De mest intressanta rapporterna är "Kravfel" i avsnittet "Fel", som visar data i en gruppering som motsvarar strukturen i "Krav"-katalogen:

och "Felanalys" i avsnittet "Rapporter", som visar sammanfattande data baserat på klassificeringen "1C: Kompatibel", "Obligatorisk" och "Rekommendation":

Konfigurationsvalideringsregler

Skapa egna regler för specifika exempel kommer inte att behandlas här. Först måste du förstå detta problem bättre själv. I användarmanualen som medföljer APK-filen ägnas ett ganska omfattande kapitel 5 åt att skapa nya regler - detta är ett tvärgående exempel i form av så många som 30 sidor fascinerande text och illustrationer))

Låt oss gå igenom reglerna i en översikt. De finns i systemets katalog med samma namn:

Navigering i det vänstra trädet är obekvämt - du kan dubbelklicka för att välja ett element för att visa dess sammansättning på höger sida. Därför sammanfaller det valda elementet inte alltid med det vars sammansättning visas till höger.

Varje regel kan öppnas. Katalogelementets form ger tillgång till listan över objekttyper som måste kontrolleras av denna regel, algoritmparametrarna (en numrerad lista över fel som kan refereras från algoritmen), själva algoritmen och dess beskrivning, beskrivning av krav och användningsinställningar:

Överst finns tre användbara knappar... "Visa standarder" leder till motsvarande sektion av 1C-webbplatsen med en beskrivning av standarden, länken öppnas i webbläsaren. "Open Requirements" öppnar "Requirements"-katalogobjektet som motsvarar regeln, och kommandot "Open Debug" börjar bearbeta "ValidationRulesDebugger". Hur det fungerar i användarmanualen är tyst, men det är uppenbart att felsökningsverktyg antingen finns tillgängliga, eller så finns det utvecklingar för dem som kan utvecklas.

Regelalgoritmen kan ändras, liksom nya regler och regelgrupper kan skapas. Om du behöver skriva dina egna algoritmer måste du studera inbyggda metoder och programmera objekt. Detta är ämnet för motsvarande avsnitt "Syntax för kontrollregler" i kapitel 6 i PDF-användarhandboken. Du kan också använda befintliga reglers algoritmer som exempel och exempel för kopiering.

Den inbyggda hjälpen för programmet är katastrofalt knapphändig. Snarare är det frånvarande, så beskrivningen av inbyggda metoder kan inte erhållas från det.

Filtrera objekt under kontroller

Avslutningsvis, låt oss se hur APK 1.1 beter sig när vi kontrollerar med påtvingade filter. Hjälper de verkligen till att minska verifieringstiden och minska mängden information i rapporterna. Låt oss kontrollera både prefix- och subsystemfiltrering.

I det här avsnittet kommer det att finnas mer "begravning i koden" än en berättelse om det agroindustriella komplexets kapacitet. Om på detta stadium detta är inte ditt mål - du kan hoppa över det här avsnittet.

Låt oss ta samma experimentella konfiguration, skapa ett nytt element för det i konfigurationskatalogen (bara du behöver skapa ett element utan att kopiera, eftersom när du kopierar konfigurationer kopieras även deras versioner och datastruktur, detta är en lång process och bryter mot experimentets renhet). Låt oss klassificera dokument som två nya delsystem:

apk_Document_1_1,apk_Document_1_2 och nytt_dokument_1_3 vi hänvisar till delsystemet apk_Subsystem_1

apk_Document_2_1, apk_Document_2_2 och nytt_dokument_2_3 vi hänvisar till delsystemet apk_Subsystem_2

Låt oss göra stavfel i dokumenten och lägga till en oanvänd exportmetod till managermodulen. Vi skapar dokument genom att kopiera.

Låt oss lägga till två filter för att samla in information - per prefix apk_ och på delsystemet apk_Subsystem_2 (skärmdump tagen på APK-version 1.1.11.16):

Som ett resultat av kontrollen förväntar vi oss att se fel och felrapporter som endast gäller dokument som matchar filter. (som visas nedan, filter tillämpas "ELLER")... Jag skulle också vilja påskynda verifieringsprocessen, med rabatt på att vissa operationer och kontroller utförs oavsett antalet objekt som skannas.

Låt oss köra kontrollen. Efter ett par timmars grundläggande kontroller (inklusive plattformskontroller) kommer vi att se att antalet objekt för ytterligare kontroller inte längre skrämmer 77 736, utan bara 65:

Som ett resultat av kontrollerna slutar rapporter verkligen att ge information om "extra" objekt och rapporterar bara om objekt som matchar filter. Samtidigt hittades både specialgjorda misstag och andra kommentarer gjordes:

Det finns dock nästan ingen vinst i att kontrollera tid från filter. I det här exemplet tog den fullständiga kontrollen 10 timmar istället för 15 timmar, det vill säga den accelererades med endast 30 %. Avsnittet om "Utförande av kontroller" har redan förklarat orsakerna till detta beteende. Låt oss nu ta reda på varför detta händer på kodnivå och samtidigt kommer vi att förstå djupare hur algoritmerna för att filtrera och kringgå elementen i konfigurationsstrukturen under kontroller fungerar.

Rapporterna visar att förutom information om dokument, samlas även information om rotkonfigurationselementet in som en del av allmänna kontroller. Och när man gör inspektioner är det svårt att inte märka att det är beskedet om inspektionen av detta objekt nr 1 som hänger i statusfältet i nästan alla 10 timmar (på version 1.1.11.16)... Samtidigt informerar systemet om den kommande kontrollen av 65 objekt, även om vi behöver max 6-8 av dem. Låt oss stoppa processen i debuggern medan meddelandet "Objekt #1 kontrolleras" hänger i statusfältet och se vilka moduler som kontrolleras. Du kan se att i det första verifieringsskedet analyserar systemet fortfarande alla objekt, inklusive till exempel lönegemensamma moduler, som definitivt inte ingår i vårt nya delsystem:

Men vi krävde inte att systemet samlade in data om vanliga moduler. Vilka är samma 65 objekt som systemet kommer att kontrollera?

Du kan få en lista över dem genom att gå upp i anropsstacken till metoden CheckObjects () i dokumentobjektmodulen "VersionCheck". Du kan också få information från den att ALLA objekt från StructureConfiguration-katalogen som data samlades in för väljs ut för verifiering, eller så anser systemet att data har samlats in:

Dessa objekt är:

Själva objekten är mindre än 65, systemet räknade helt enkelt inte bara våra dokument utan också deras detaljer. Men du kan märka att rotelementet i hierarkin i ConfigurationConfigurations-katalogen var det allra första i den här listan. Och vi har sett att det är verifieringsprocessen som tar så lång tid.

Genom att ha en lista över dessa objekt kan vi dra slutsatser om hur filtreringsmekanismen fungerar och hur kontroller fungerar med filter:

Filtrering fungerar endast vid datainsamlingsstadiet. I själva kontrollen spelar filter inte längre någon roll. Och detta är logiskt, eftersom algoritmerna är inställda i användarläget. APC:n skickar dem bara för att kontrollera elementen i StructuralConfiguration-katalogen, om den anser att data har samlats in om dem.

Trots de filter vi använt för kontroller, samlar APK:n information om modulerna för ALLA konfigurationsobjekt. Data på modulerna används av APC:n vid kontroller som är gemensamma för hela konfigurationen. Det kommer att visas nedan vad som händer om du inaktiverar sådana kontroller.

Några av de vanliga objekten kommer att finnas i listan för verifiering i alla fall, oavsett våra filter. Inklusive det översta rotobjektet - själva konfigurationen. Återigen är detta nödvändigt för "allmänna" kontroller. Eftersom konfigurationen som ingår i listan fortfarande kontrolleras enligt samma regler som tidigare, och de gemensamma modulerna, deras texter och vissa andra data inte filtrerades under datainsamlingen, kommer den längsta flertimmarskontrollen av objekt #1 fortfarande att utföras . Det kommer inte att vara möjligt att erhålla en radikal acceleration av processen genom användning av filter.

Systemet bestämde sig för att inte bara kontrollera dokument som uppfyller båda våra filter, utan de som uppfyller något av dem. Objekt som börjar med prefixet kommer också att skickas för verifiering. apk_ och de objekt som ingår i delsystemet apk_Subsystem2 inklusive dokument nytt_dokument_2_3... Endast ett dokument har försvunnit från listan över skannade objekt nytt_dokument_1_3 inte lämplig för något filter. Resultatet blir tydligt om du tittar på filtreringsfunktionen. Tillåtande filter fungerar på "ELLER", inte "OCH". Om detta behöver ändras måste du återigen göra små ändringar i den här metoden:

Låt oss nu försöka "leka" med koden och se vad som skulle hända om filtrering fungerade inte bara vid datainsamlingsstadiet utan också vid verifieringsstadiet. För detta, låt oss skapa ytterligare ett element i konfigurationskatalogen med samma filter:

På konstgjord väg, i koden för metoden CheckObjects () i VersionCheck-dokumentet, kommer vi att hoppa över det första urvalselementet när vi går igenom frågeresultatet. Det vill säga, låt oss hoppa över rotelementet i katalogen ConfigurationConfiguration:

Låt oss utföra samma kontroll och titta på den tid det tar för hela processen och se om resultaten av rapporterna kommer att skilja sig från de som erhållits utan att hoppa över roten av konfigurationen.

I det här fallet tar det bara 50 minuter från början av processen till dess att den är klar istället för 10 timmar:

: Skapade dokument Kontrollera version 8 daterad 2017-11-01 20:51:37

………………..

: Börja ladda upp konfigurationen till XML-filer

: Dumpning av konfiguration till XML-filer slutförd

………………..

: Konfigurationskontrollen har påbörjats

: Konfigurationskontroll utförd

Nu rapporten:

Du kan se att rotelementet inte längre visas. Men dessutom visar rapporten 9 rader istället för 10, relaterade till varje dokument. Rader som anger oanvända exportmetoder i dokumenthanterarens moduler saknas. Det vill säga att vissa av felen verkligen upptäcks endast om rotelementet i ConfigurationConfigurations-katalogen är involverat i verifieringsprocessen. Annars fungerar inte motsvarande verifieringsregler helt enkelt. Dessa är fel, när de upptäcks, enligt logiken, bör förhållandet mellan objektet och alla andra konfigurationsobjekt kontrolleras.

Alltså, om vi vill påskynda kontrollerna drastiskt när vi tillämpar filter, måste detta göras antingen genom att inaktivera de mest utdragna allmänna kontrollerna som kräver att alla moduler förbigås (detta kan göras i inställningarna), eller genom att utveckla våra egna alternativa kontrollregler .

Resultat:

Verktyget "Automatisk konfigurationstestning" tillåter verkligen, när det väl har konfigurerats, att hitta fel i konfigurationer i automatiskt läge. APK gör det möjligt att hitta grova fel i konfigurationen, korrekt stavning, anpassa den till ganska rimliga och rimliga utvecklingsstandarder från 1C.

APK kan inte ersätta andra verktyg för förbättring av kodkvalitet, som kodgranskning. Det tillåter dig inte att spåra förekomsten av onödig copy-paste (kodduplicering), flera serveranrop där de kan packas i ett, eller leta efter de enklaste tecknen på en icke-optimal begäran. Men det kan avsevärt minska behovet av visuell kontroll och bli en bra utgångspunkt för andra verktyg och metoder. Och vid behov, skriv dina egna checkar som löser fler problem än de som ligger utanför lådan.

Trots bristen på information om det är det inte svårt att bemästra det här verktyget för att börja använda det i praktiken. Att ha en användarmanual, och nu den här artikeln, kan vara en bra början för en steg-för-steg-guide. Konfigurationen av själva APK-filen är ganska enkel och lätt att modifiera, åtminstone när det gäller gränssnittet. Det finns verkligen något att förbättra. För en bekväm och effektiv användning våra "tankar" behöver alltid en fil))

Utvecklingen av dina egna kontrollregler kräver att du behärskar det "inbyggda språket" i APK-filen, närmare bestämt inbyggda procedurer och funktioner; detta kan göras med hjälp av användarmanualen och befintliga regler.

Även de enklaste operationerna som kräver datainsamling från konfigurationer som ERP tar över 20 minuter för AIC. För att utveckla och felsöka dina egna verifieringsregler bör du därför antingen skapa dina egna små demokonfigurationer och demodatabaser, där vissa moduler bryter mot denna regel, eller utföra kontroller med tidigare insamlad data. Båda teknikerna kommer att hjälpa till att påskynda processen med att felsöka nya regler.

• Konfigurationen har verktyg för att felsöka nya och befintliga regler. För att arbeta med dem måste du förstå APC-konfigurationskoden, se hur objekt skapas och i vilket sammanhang de algoritmer som anges i användarläget exekveras. Men om du vill, verkar det fullt möjligt, tillvägagångssätten bör vara liknande de som vi använder i "Datakonvertering".

Ibland inträffar problem i 1c-databaser - 1c-rapporten som tidigare fungerade startar inte, dokumentet hålls inte på grund av ett obegripligt fel, det är omöjligt att komma in i programmet ... Ett av de viktigaste sätten att korrigera 1c-fel är att testa och fixa 1c 8.3-databasen med hjälp av verktyget inbyggt i plattformen.

Jag vill notera att för någon felaktigt arbete 1C Enterprise 8.3, de viktigaste metoderna för att återställa programmets prestanda är:

1. Rensa cachen 1C Enterprise;
2. Testa och fixera basen 1c 8.3.

Metoden för att ta bort 1C-cachen beskrivs i detalj i artikeln. Tänk på det andra tjänsteverktyget för att administrera 1C-plattformen.

Testa och fixa 1c 8.3-databasen med det inbyggda verktyget

För att starta denna operation behöver du inte ha några speciella kunskaper, så alla användare kan hantera detta utan att kontakta 1c-specialister. För att börja testa och fixa måste du gå in i 1c-konfiguratorn och välja "Administration" - "Testa och fixa ..."

Beskrivning av verktyget "Testa och reparera 1c infobase".

Formuläret som öppnas innehåller ett antal poster som gör att du kan korrigera fel. Att användas professionellt detta verktyg, det är nödvändigt att förstå syftet och logiken för driften av var och en av punkterna, så låt oss titta närmare på dem:

• Omindexering av infobastabeller.

För snabbsökning information läggs hjälptabeller till i huvudtabellerna med huvuddata, där data sorteras enligt de angivna fälten i huvudtabellen - indexeringstabellen. På grund av användningen av indexeringstabeller ökar prestandan för 1c avsevärt, eftersom det inte finns något behov av att iterera över hela huvuddatatabellen för urval, du kan använda indexfilen och välja nödvändiga poster därifrån.
När du skriver data till huvuddatatabellerna fylls även indexeringstabellerna i. Men av olika tekniska skäl kan indexen gå vilse, vilket så småningom kan leda till fel. För att korrigera denna klass av fel, när du testar och korrigerar 1c 8.3-basen, måste du markera rutan bredvid detta menyalternativ.

• Kontrollera den logiska integriteten för infobasen

Vid tidpunkten för att skapa nya objekt i 1c-konfigurationen skapas nya tabeller i databasen, som indikerar länkar till andra tabeller i databasen. Av olika anledningar kan anslutningar bli felaktiga (till exempel på grund av en felaktig uppdatering eller ett oväntat strömavbrott vid inspelningstillfället). För att åtgärda denna typ av fel, välj detta menyalternativ.

• Kontrollera referensintegriteten för en infobas

För att identifiera och korrigera dessa fel, välj detta menyalternativ, medan alternativen för att hantera sådana fel aktiveras nedan (se bilden ovan). Vi kan välja hur vi ska åtgärda fel när om det finns referenser till icke-existerande objekt: skapa objekt, tydliga länkar, ändra inte; och med partiell dataförlust: skapa objekt, ta bort ett objekt, ändra inte.

• Omräkning av summor

För att utföra snabba dataval i 1c-databasen finns tabeller med redan beräknade data med månadsfrekvens. När vi ansöker om denna data samlas den inte in från huvudtabellerna (det skulle ta mycket tid), utan returneras omedelbart från data i totaltabellerna. Följaktligen, för att denna mekanism ska fungera, är det nödvändigt att ha korrekta resultat för de senaste perioderna. Därför, om 1c "fuskar" i rapporterna, korrigeras ett sådant fel av detta menyalternativ.

• Komprimering av infobastabeller

Att ta bort objekt i databasen är en ganska mödosam och tidskrävande operation, därför är borttagningsprocessen i 1c-konfigurationer uppdelad i två steg. När du tar bort objekt i konfigurationen ogiltigförklaras data i 1c-databasen och deltar på grund av detta inte i ytterligare operationer, även om den fysiskt förblir på plats. För att rensa tabellerna från dessa poster gör de testning och korrigering av 1c 8.3-basen med menyalternativet "Komprimera tabeller informationsbas».

• Omstrukturering av infobastabeller

När du ändrar detaljerna för ett 1c-metadataobjekt måste databasen komplettera alla tabeller för det ändrade objektet med nya poster. Detta görs genom att omstrukturera databastabellerna. Under omstruktureringsprocessen skapas kopior av databastabellerna med strukturen för den aktuella konfigurationen, varefter data överförs till de skapade tabellerna. Om en variabel läggs till i 1c-metadata kommer en tom kolumn att skapas för den i den nya tabellen; om ett attribut tas bort skapas inte en kolumn för detta attribut i den nya tabellen, och den kommer därför inte att överföras.
Omstruktureringsprocessen kommer att återskapa alla tabeller i databasen, så detta är den längsta operationen.

Testa och fixa 1c 8.3-basen i praktiken

Efter att ha fått omfattande information tror jag att du enkelt kan navigera i vilka verktyg du behöver välja för att fixa något.

Testning och fixering av 1c 8.3-basen kan göras i två lägen:

1. Testning. I detta läge testas databasen och tekniska korrigeringar för mindre fel görs.
2. Testa och fixa. I detta läge testas 1C-databasen och försöker fixa alla uppmärksammade fel (se figuren ovan).

För att testa och fixa 1c 8.3-basen måste du klicka på "Kör"-knappen, varefter du i informationsfönstret längst ner i konfiguratorn kan se framstegen med testning och fixering.

Liknande

Implementeringen av 1C 8 ger ett stort antal fördelar, men effektivt arbete är endast möjligt om Hög kvalitet system, både funktionella och tekniska.

Funktionell och teknisk kvalitet på systemet - funktioner och skillnader Den funktionella kvaliteten på informationssystemet är förmågan hos en viss konfiguration för att lösa företagets affärsproblem, och den tekniska kvaliteten är hög produktivitet, inga fel och stabil drift. Kvalitetshanteringen varierar avsevärt:

• den tekniska kvaliteten på systemet kontrolleras under en specifik implementering av systemet. 1C-licensierat program implementerat på plattformen 1C: Enterprise 8, bör säkerställa en stabil drift av flera användare på viss utrustning. Samtidigt spelar det ingen roll vilka förmågor som är inneboende i systemet;
• funktionell kvalitet testas för en specifik konfiguration och dess kapacitet. Kvaliteten på systemet bestäms av förmågan att utföra de tilldelade uppgifterna, oavsett användningsförhållandena.

Systemets funktionella kvalitet kan kontrolleras av följande indikatorer:

• 1C licensierade program löser alla affärsproblem;
• som svar på alla korrekta användaråtgärder, beter sig systemet adekvat och förutsägbart.

Funktionell kvalitet består alltså av två områden - ämne och teknisk. Ämnesbedömningen av systemet kan endast utföras av en fackman inom ett specifikt område, medan den tekniska kan bedömas oavsett arbetsuppgifter.

Varför är den höga funktionella kvaliteten på systemet nödvändig? Att utveckla ett system för implementering kräver ett seriöst tillvägagångssätt av flera skäl. Ett högkvalitativt system säkerställer enklare implementering av 1C 8, vilket som ett resultat sparar företaget tid och pengar. Dessutom är det mycket lättare att upprätthålla ett högkvalitativt 1C-system och kräver mindre uppmärksamhet från specialister.

När man utvecklar nya lösningar baserade på ett färdigt system är alla processer mycket snabbare och enklare och dess drift eliminerar driftstörningar.

Hur definierar man funktionell kvalitet? Frånvaron av fel i programkoden betyder inte alls att den funktionella kvaliteten på systemet är på en viss nivå.

Den övergripande kvaliteten på en konfiguration kan bestämmas av ett antal faktorer, till exempel:

• tillgång till aktuell och detaljerad referensinformation. Genom att trycka på "F1" måste användaren nödvändigtvis få hjälp med varje konfigurationsobjekt;
• tillgång till tips. Korta tips om varje formulärkontroll bör förklara innebörden av dessa formulär;
• skärmformarnas dimensioner bör säkerställa bekvämt arbete och bör inte överstiga standardvärden;
• texten i meddelanden och systemvarningar bör vara kortfattad och begriplig, utan stavnings- och grammatiska fel.
• innan du utför någon oåterkallelig åtgärd måste systemet utfärda en varning med information om operationen och dess konsekvenser;
• programkod måste ha relevanta och uttömmande kommentarer.

Full lista systemkvalitetskrav finns i metodisk handbok"System av standarder och metoder för konfigurationsutveckling". Systemkvalitetsledning - metoder och eventuella problem Mest effektiv metod kvalitetsledningssystem är förebyggande. Som med alla företag är det lättare att åtgärda grundorsaken till ett problem än att åtgärda konsekvenser av dålig kvalitet. En teknik som identifierar och minimerar konfigurationsfel på plattformen 1C: Enterprise 8 består av flera punkter:

• definiera de grundläggande standarder som krävs för konfiguration;
• kontrollera den aktuella versionen för överensstämmelse med etablerade standarder;
• vid upptäckt av inkonsekvenser, meddelande till specialister om de upptäckta felen; ackumulering av statistisk information om fel.

Men trots prevalensen har denna metod flera negativa egenskaper:

• även ett litet system tar mycket tid att kontrollera, och en komplex konfiguration, som inkluderar hundratals objekt, gör manuell kontroll helt enkelt omöjlig;
• Konfigurationsverifieraren måste vara högt kvalificerad och ha en förståelse för standarderna. Även om företaget har en sådan specialist, är det inte det mest rationella beslutet att lägga sin tid på att utföra rutinoperationer.

Hur minskar man tiden på att kontrollera kvaliteten på systemet? 1C erbjuder behändigt verktyg"Automatisk konfigurationskontroll", som ger möjlighet att:

• kontrollera konfigurationer av "1C: Enterprise 8" för överensstämmelse med utvecklingsmetoder. Dessutom kan programregistret kompletteras med särskilda verifieringsregler, som är nödvändiga för specifikt fall;
• insamling av information om hittade systemfel och automatisk distribution enligt graden av kritik;
• fördelning av fel bland de utvecklare som ansvarar för att åtgärda dem.

Användningsområden för automatiserad verifiering Använda en mjukvaruprodukt 1C: Automatisk konfigurationskontroll kan du lösa flera problem samtidigt, inklusive:

• kontroll över den funktionella kvaliteten på konfigurationer, både produktion och individuella, utvecklade för en specifik organisation;
• 1C-stödet inkluderar periodiska revisioner och ändringar av standard- och branschspecifika program, och lösningen 1C: Automated Configuration Checker låter dig kontrollera kvaliteten på dessa revisioner;
• bedömning av kvaliteten på den konfiguration som erbjuds företaget. Under förberedelserna för implementering låter programmet dig ta reda på inte bara den tekniska kvaliteten på konfigurationen, utan också kompetensen hos dess utvecklare.

Utöver de uppenbara fördelarna hjälper det att använda 1C-programmet för att automatiskt kontrollera systemet att utbilda IT-proffs att noggrant studera alla delar av konfigurationen. Genom att kontrollera ändringarna kan du snabbt identifiera alla "tillfälliga" platser av låg kvalitet i systemet, och personalisering gör att du kan vänja dig vid tanken att alla delar av konfigurationen måste göras effektivt, utan att hoppas på efterföljande revidering.

Så med hjälp bekvämt program 1C vilket företag som helst kommer att kunna säkerställa implementeringen av ett högkvalitativt system och en felfri drift av konfigurationen.

29.09.2016

Kontrollera lagligheten av att använda de installerade uppdateringarna av typiska konfigurationer av program i 1C Enterprise 8-systemet.

Få tillgång till molnet 1C: Fresh gratis i 30 dagar!

Från och med versionen av 1C: Enterprise-plattformen 8.3.7 har 1C-program implementerat en mekanism för att kontrollera lagligheten av att använda 1C-applicerade lösningar, inklusive uppdateringar av 1C-konfigurationen.

Efter installation av nästa uppdatering av den typiska konfigurationen och 1C: Enterprise-plattformen kan programmet visa ett meddelande om att det finns problem med att kontrollera lagligheten av att använda den installerade konfigurationsuppdateringen i uppdateringsskyddscentret.

Syftet med denna mekanism är att informera användaren i tid om den faktiska användningen av vissa versioner eller utgåvor av konfigurationen, som han inte har rättigheterna till, och de potentiella juridiska riskerna i samband med detta.

Kontrollen utförs för applikationslösningar som distribueras i filversionen eller på servern i MINI-versionen. Validering utförs inte för applikationslösningar som använder en baslicens. Verifieringsproceduren utförs efter att uppdateringen av 1C: Enterprise-systemkonfigurationen är klar och programmet gör en begäran till Update Protection Center (nedan kallat CPO).

Uppmärksamhet! V det här ögonblicket möjlig tekniska problem med tillgängligheten av webbplatsen för Update Protection Center https://1cv8update.com

Vid kontroll av lagligheten av den installerade konfigurationsuppdateringen används information om programmet och data konto skapades under registreringen av mjukvaruprodukten och IT-supportavtalet på 1C: ITS Portal. Om konfigurationsuppdateringen installerades olagligt, genererar programmet med jämna mellanrum en dialogruta som innehåller information om orsakerna till den olagliga användningen av den applicerade lösningen.

I händelse av framgångsrikt slutförande av samtalet, returnerar CPO status för lagligheten av användning. Om CPO inte bekräftar lagligheten av att använda den installerade konfigurationsuppdateringen, börjar 1C: Enterprise-systemet att informera alla användare av infobasen att detta tillämpad lösning används illegalt, medan informationen som tas emot från CPO visas.

Information om resultatet av kontrollen kan också ses i dialogrutan "Om programmet", som innehåller information om hur samtalet till CPO slutade:

För att den applicerade 1C-lösningen ska klara kontrollen i CPO:n är det nödvändigt att följande villkor är uppfyllda:

• Programmet måste vara licensierat.
• Programvaran måste ha ett giltigt ITS-abonnemang.
• Programvaran måste vara registrerad hos personligt konto användare på Portal 1C
• Internetanvändarsupport måste vara aktiverat i konfigurationen.

Således, om ditt 1C-program rapporterar att det finns problem med att kontrollera giltigheten av den använda konfigurationen, kan detta bero på en eller flera anledningar:

• Orsak 1. En olicensierad (piratkopierad, jailbroken, "hårdvara", "patchad" etc.) version används programvara 1C.

  Lösning: Vi kan erbjuda två alternativ för att lösa problemet: köp en licensierad version av 1C-programvaran eller gå till jobbet i "1C i molnet".

  Alternativ 1: Köp en licensierad version av 1C-programvaran.

  Observera att du behöver köpa exakt det kit som innehåller den konfiguration du använder, dvs. om du till exempel använder 1C: Trade Management, så är det ingen idé att köpa 1C: Accounting, eftersom detta kommer inte att lösa problemet med att verifiera giltigheten av användningen av konfigurationen.
  Om du har en enanvändarversion av programmet i filläge, räcker det med att bara köpa grundpaketet. Om nätverksversionen används på flera datorer i klient-serverläge måste du också köpa ytterligare klientlicenser och en licens för 1C: Enterprise-servern.

  Kostnad för 1C-program

  namn	Pris gnugga.	En kommentar
  1C: Redovisning 8 PROF. Elektronisk leverans
  Mest snabbt alternativ licensiering! Leveranstid 3-4 timmar från betalningsdatum! *		Grundförråd för 1 arbetsplats med ett programvaruskyddssystem.
  1C: Lön och personalhantering 8 PROF. Elektronisk leverans Det snabbaste licensalternativet! Leveranstid 3-4 timmar från betalningsdatum! *		Grundleverans för 1 arbetsplats med ett programvaruskyddssystem.

  
  Kostnaden för andra mjukvaruprodukter 1C: Enterprise-system, ytterligare klient- och serverlicenser finns i prislistan.
  Om du akut behöver legalisera 1C: Accounting eller 1C-partners som inte har detta program i din region, kan du köpa "Elektronisk leverans" i vårt företag. Elektronisk leverans är en "boxless" version av programmet, som är 100% licensierad, funktionellt inte annorlunda än den vanliga "boxen". Efter betalning på Portal 1Cs personliga konto kan du ladda ner installationsdistributionerna för programmet, aktiveringskoder och dokumentation i i elektroniskt format(v pdf-format). Om du behöver hjälp av våra specialister när du installerar programmet, hjälper de dig på distans via Internet.

  Alternativ 2: Gå till jobbet i "1C i molnet".

  I det här fallet laddar du upp din databas med alla ackumulerade referenser till 1C Fresh-molnservern (https://1cfresh.com/).
  Du behöver inte köpa 1C-programvara och installera programmet på dina datorer. Arbetet i programmet utförs via Internet med en vanlig webbläsare eller "1C Thin Client", som lagligt kan laddas ner från den officiella 1C-webbplatsen gratis.
  Tillgång till 1C-molnservern tillhandahålls på leasingbasis enligt affärsmodellen SaaS (Software as a Service). Kostnaden för tillgång till molnversionen av 1C är 500-600 rubel per månad per användare. Den exakta kostnaden kommer att bero på antalet användare, antalet använda databaser, vald taxa och betalningssätt.

  Kostnaden för att hyra 1C-programi molnet med SaaS-modellen
  
  

  namn	Betygsätta "PROF" **	Betygsätta "TEKNO"
  Ägandekostnad per användare och månad vid ingående av kontrakt på 12 månader.	495 rubel / månad	525 rubel / månad
  Den exakta kostnaden beror på betalningsvillkoren *: Betalning månadsvis Förskottsbetalning 3 månader Förskottsbetalning i 6 månader Förskottsbetalning i 12 månader	2970 RUB 8031 RUB 15 498 RUB 29664 RUB	1200 RUB 3498 RUB 6546 RUB 12 528 RUB
  Antal samtidiga användare	5 användare.	2 användare.
  Tillgängliga applikationer från listan: 1C: Redovisning 8 1C: Lön och personalhantering 8 1C: Ledning av ett litet företag 8 1c redovisning statlig institution 8 1C: Lön och personal vid en offentlig institution 8 1C: Entreprenörsrapportering 8 1C-Eldstad: Lön	Allt	En av listan att välja på
  Antal informationsbaser	Utan gränser	En fungerande databas + ett test / arkiv / demo

  *Den angivna kostnaden är giltig under förutsättning att avtalets kontinuitet.
  ** Kostnaden för anslutning till PROF-tariffen, förutom tillgång för 5 användare till ett obegränsat antal databaser, inkluderar ett antal ytterligare tjänster: 1C-Rapportering; regelverk och rättslig ram "1C: Garant"; full tillgång Till informationssystem IC: ITS; konsultationer och svar från revisorer och experter på användarnas frågor om redovisning, beskattning och personalfrågor (i det personliga kontot på 1C: ITS-webbplatsen); tillgång till uppdateringar för förpackade versioner plattformar 1C: Enterprise och typiska konfigurationer 1C, etc. Mer information.

  De första 30 dagarna av åtkomst är gratis!
  För att du själv ska kunna utvärdera tillgänglighet, stabilitet, hastighet och användbarhet kan vi tillhandahålla fri tillgång till molntjänsten 1C: Fresh i 30 dagar.

  Informationsmaterial:
  -
  - Instruktioner för att ladda en databas från en lokal dator till 1C: Fresh-molntjänsten
  - Instruktioner för att installera och konfigurera en tunn 1C-klient för att fungera med 1C: Fresh-molntjänsten
  - Ansökningsformulär för anslutning till molntjänsten 1C: Fresh
  - Ansökningsformulär för självregistrering i molntjänsten 1C: Fresh

• Orsak 2. Det finns inget giltigt kontrakt för informationsteknikstöd (ITS).
  
  Lösning: sluta ett avtal för IT-stöd. Om du brådskande behöver prenumerera på en ITS kan du prenumerera på den i vårt företag även om du är i en annan region i Ryska federationen och köpte 1C-programmet på en annan plats. Det enda villkoret är att programmet måste vara licensierat.

  ITS abonnemangskostnad

  Var uppmärksam på följande punkter:

• Det finns två alternativ för ITS-prenumeration: ITS Techno och ITS PROF, som skiljer sig åt i informationsinnehåll. ITS Techno inkluderar minimisupportalternativet (tillgång till 1C:s tekniska supportwebbplats för självnedladdning av uppdateringar). ITS Prof inkluderar, förutom tillgång till uppdateringar, ett antal ytterligare tjänster och tjänster, till exempel 1C: Rapportering, 1C: Motpart, 1C: Fresh, 1C: Molnarkiv, juridisk bas "GARANT" och många andra. För en detaljerad jämförelse av ITS Techno och PROF se.
• Kostnaden för ett ITS-abonnemang beror på kontraktsperioden. Minimialternativet är en engångsprenumeration under 1 månad, men med tanke på behovet av att regelbundet uppdatera bokföringsprogramvaran för 1C: Accounting rekommenderar vi att du prenumererar under en längre period.
• Kostnaden för ett abonnemang för kontinuerlig förnyelse av ITS-abonnemanget är lägre än för dess förnyelse.

  namn	Pris kl kontinuerlig förlängning gnugga.	Pris kl förnyelse kontrakt gnugga.
  ITS PROF engångsabonnemang i 1 månad		4818
  ITS Techno i 6 månader		7854
  ITS Techno i 12 månader		15036
  DESS PROF i 3 månader		9636
  DESS PROF i 6 månader		18600
  DESS PROF i 12 månader		35592

• Orsak 3. Mjukvaruprodukten är inte registrerad på användarens personliga konto på 1C-portalen.

  Lösning: registrera programvaran.
  Instruktioner för att registrera mjukvaruprodukter på det personliga kontot för Portal 1C: ITS (portal.1c.ru)
  Om användaren inte tidigare har registrerat sig på portalen, innan han registrerar en mjukvaruprodukt på sitt personliga konto, måste användaren först registrera sig på portalen på egen hand och få en inloggning och ett lösenord för att komma åt sitt personliga konto.
  Instruktioner för att registrera användare på 1C: ITS Portal (portal.1c.ru)
  

• Orsak 4. Internetstöd för användaren i 1C-programmet är inte konfigurerat.
  
  Lösning: ställ in internetsupport.
  Instruktioner för att ansluta internetsupport i typiska konfigurationer 1C: Enterprise 8

Tekniska problem

Om du använder en licensierad version av programmet, är mjukvaruprodukten registrerad på det personliga kontot för 1C-portalen, det finns ett giltigt ITS-abonnemang och internetsupporten är korrekt konfigurerad, och programmet visar fortfarande meddelanden "Licenscenter ej tillgängligt", "Konfigurationsregistrering i licenscentret slutfördes inte", "Fjärrnoden klarade inte kontrollen", etc., då är tekniska problem möjliga:

1. CPO-servern https://1cv8update.com är inte tillgänglig
I det här fallet är det nödvändigt att kontrollera serverns hälsa och tillgänglighet för blockering av antivirus, brandväggar, brandväggar eller proxyserversäkerhetsinställningar.

2. På webbplatsen https://1cv8update.com uppdaterades säkerhetscertifikatet och du använder den gamla 1C: Enterprise-plattformen (eller kompatibilitetsläget är inställt) under version 8.3.8. I det här fallet måste du uppdatera plattformsversionen, ställa in kompatibilitetsläge eller manuellt registrera säkerhetscertifikatet i filen cacert.pem i bin-katalogen.

3. Servern för Update Protection Center kanske helt enkelt är överbelastad, försök att upprepa kontrollproceduren flera gånger genom att klicka på knappen "Försök igen nu" eller utföra kontrollen senare.

Förtydliganden om villkoren för distribution av mjukvaruuppdateringar 1C Enterprise

Vid försäljning av 1C-mjukvaruprodukter överförs icke-exklusiva (begränsade) rättigheter att använda programvaran från upphovsrättsinnehavaren (1C-företaget) till Licenstagaren (användaren) i enlighet med villkoren i Licensavtalet som ingår i leveransen av Mjukvaruprodukten . Samtidigt förbinder sig Licenstagaren att strikt följa och inte bryta mot reglerna för licensierad användning av mjukvaruprodukter, och brott mot villkoren i "Licensavtalet" anses vara ett brott mot upphovsrätten och åtalas.

Enligt "Licensavtalet" i kostnaden för mjukvaruprodukter "1C" in för närvarande inkluderar informationsteknikstöd (ITS) i 3 månader, vilket inkluderar månadskvitto DVD-skivor DESS; ta emot mjukvaruuppdateringar, konfigurationer och rapporteringsformulär; konsulttjänster; tillgång till webbplatsen teknisk support"1C" (från 01.01.2016 kan du köpa en "disklös" version av ITS).

Efter utgången av den kostnadsfria supportperioden servas 1C-program endast under ett ITS-kontrakt på betald basis.

Dessutom, vid installation av en uppdatering, bekräftar användaren sitt samtycke till distributionsvillkoren och användningen av uppdateringar och accepterar ansvar för brott mot användarvillkoren, annars måste användaren vägra att installera uppdateringen.

Alltså inte bara själva programmen utan också UPPDATERINGAR till programmen för företaget "1C", är föremål för den exklusiva rätten för företaget "1C" och distribueras enligt reglerna som fastställts av företaget "1C" som upphovsrättsinnehavare i enlighet med art. 1225 i civillagen, och en obehörig SPRIDNING och ANVÄNDANDE uppdateringar anses vara upphovsrättsintrång och åtalas:

• Konst. 1301 Civil Av RF-koden,
• Konst. 7.12 i Koden Ryska Federationen om ryska federationens administrativa brott,
• Konst. 146 i den ryska federationens strafflag.

Uppdateringar och informationsresurser måste erhållas av användaren genom lagliga distributionskanaler:

• diskar med informationsteknikstöd
• webbplatser för företaget "1C": www.1c.ru, v8.1c.ru, online.1c.ru, its.1c.ru, portal.1c.ru, releases.1c.ru, users.v8.1c.ru
• kontor för partners i företaget "1C"

Uppdateringar som tas emot från andra källor är OLAGLIGA:

• kopierat från en vän
• uppdateringen installerades av "student Vasya" (källa okänd)
• laddas ner från en webbplats som inte är den officiella webbplatsen för "1C"
• köpt i stånd
• etc.

Det är mycket enkelt att ta reda på om uppdateringen är berättigad: 1C-företaget förses med information om alla lagliga ITS-abonnenter med registreringsnumren för de installerade 1C-programvarorna och prenumerationsperioden, varje uppdatering har ett unikt nummer och releasen datum, datum och tid för uppdateringsinstallationen på användarens dator är kända är fixerade i själva programmet, d.v.s. i händelse av att kontrollera med användaren vid tidpunkten för release och installation av uppdateringar, måste en prenumeration på ITS tecknas.

Söker efter ett ITS-abonnemang För att undvika anspråk från brottsbekämpande myndigheter och klargöra lagligheten av användningen av uppdateringar och informationsresurser, rekommenderar vi att användare söker efter en ITS-prenumeration för sin mjukvaruprodukt på 1C-webbplatsen: . Efter att ha angett registreringsnumret för programmet "1C: Enterprise" som används kommer ett meddelande att visas på skärmen om närvaron eller frånvaron av ett giltigt ITS-abonnemang. Kontrollera om du har skickat ett anmälningsformulär till 1C Om data har ändrats - rapportera det till "1C" Se till att kanalen genom vilken du får uppdateringar är laglig (officiell partner till "1C", officiella webbplatser för "1C") Innan du registrerar dig för ett ITS-abonnemang, kontrollera om företaget som betjänar dig är en officiell partner till 1C Enligt registreringsnumret för ditt program, se till att prenumerationen är registrerad i "1C" på sajten http://www.1c.ru/rus/support/support.htm Glöm inte att förnya ditt abonnemang i tid Kräv inte ett ITS-abonnemang: Grundläggande versioner mjukvaruprodukter "1C: Enterprise", "Cloud"-versioner av 1C-program som används i molntjänst 1C: Färskt

Taggar: Kontrollera lagligheten av att ta emot uppdateringar till konfigurationer 1c, kontrollera lagligheten av att uppdatera 1c 8.3, kontrollera lagligheten av att uppdatera 1c, 1s ladda ner uppdateringar, its, 1s its, disk its, kontrollera lagligheten av 1c 8.3 7, users.1c .ru, its.1c.ru, ackompanjemang 1s 8

Testning och korrigering av 1C 8.3 infobasen måste utföras om du har fel i infobasen och innan du uppdaterar databaskonfigurationen. I de flesta fall, om din infobas är skadad, hjälper det.

Innan du testar och fixar måste du göra säkerhetskopiering bas. Om du inte kan komma in i konfiguratorn, då i mappen med installerat program 1C har ett verktyg för att testa och fixa, vilket inte kräver att programmet körs i konfiguratorläget. Vi kommer att prata om allt detta nedan.

Låt oss ta en titt på det här verktyget och hur man arbetar med det. Låt oss titta närmare på vilka flaggor som ska ställas in i gränssnittet.

Låt oss starta programmet i konfiguratorläget:

Vi väljer från administrationsmenyn objektet "Testa och fixa":

Vilka kryssrutor ska jag sätta?

Det finns olika alternativ för att ställa in testning, överväg dessa kryssrutor:

• Omindexering av infobastabellerär en komplett ombyggnad av index för databastabeller. Omindexering ökar hastigheten på infobasen. Proceduren är lång, men det kommer aldrig att vara överflödigt.
• Kontrollera den logiska integriteten för infobasen- kontrollera databasens logiska och strukturella integritet, korrigera fel i data;
• Kontrollera referensintegriteten för en infobas- kolla efter "brutna länkar" i databasen. Sådana fel kan uppstå vid direkt radering av systemobjekt eller fel. Det finns tre alternativ för att korrigera sådana fel:
  • Skapa objekt- systemet skapar stubbelement, som sedan kan fyllas i med nödvändig information,
  • Rensa länkar- "trasiga" länkar kommer att rengöras,
  • Ändra inte- systemet kommer bara att visa dig fel.
• Omräkning av summor. Summor - en tabell över förberäknade resultat i ackumulerings-, beräknings- och redovisningsregistren. Omräkning av resultat, såväl som omindexering, kommer aldrig att vara skadligt och kommer att ge ett plus i programmets hastighet;
• Komprimering av infobastabeller- vid radering av data tar 1C inte bort tabellrader utan "markerar" dem bara för radering. De är inte synliga för användaren, men kommer att fortsätta att finnas i databasen. Om du krymper databasen raderas denna data permanent. Samma effekt kan uppnås genom att ladda ur och ladda en infobasfil (* .dt);
• Omstrukturering av infobastabeller- en lång process genom vilken systemet återskapar databastabellerna. Denna procedur inträffar också när ändringar görs i konfigurationsstrukturen.

I vårt exempel, sätta alla kryssrutor som visas i figuren och klicka på "Kör":

Vi kan observera skedet av operationen i det nedre vänstra hörnet av 1C-konfiguratorfönstret. De upptäckta felen visas i fönstret för servicemeddelanden.

När testet är slut, klicka på "Stäng":

Vi kan se resultatet av operationerna i fönstret för servicemeddelanden.

Testning och fixering avslutad.

Om konfiguratorn inte öppnas: chdbfl.exe-verktyget

Om basen är så skadad att du inte kan komma in i konfiguratorn kan du använda. Verktyget installeras tillsammans med 1C-plattformen och kan hittas i mappen Bin i installationskatalogen:

Innan du börjar testa måste du definitivt göra en kopia av din databas, eftersom användningen av det här verktyget kan leda till oåterkalleliga konsekvenser. Eftersom du inte kan komma in i konfiguratorn måste du göra en säkerhetskopia enkel kopiering katalogen för din infobas.

Efter att du klickat på kopiera högerklickar du på ett tomt utrymme i mappfönstret och klickar på "Klistra in". En kopia görs, kör verktyget:

Huvudfönstret för verktyget visas. Vi måste ange namnet på databasfilen. Klicka på tre punkter. Ett fönster för att välja en databasfil öppnas. Vi letar efter katalogen för din bas och i den pekar vi på filen 1Cv8.1CD. Klicka på "Öppna".

Markera rutan "Åtgärda upptäckta fel" och klicka på "Kör".

Vi väntar på slutet av operationen. Hon får ta länge sedan, beroende på basens storlek.

Efter körning, om fel har korrigerats, kommer de att visas i verktygsfönstret. I mitt fall hittades inga fel. Klicka på "Stäng" och försök komma in i programmet. Om du fortfarande inte kan komma in måste du kontakta en specialist.