I denne artikel vil vi se på paletten med konfigurationsegenskaber ved hjælp af eksemplet med 1C Trade Management 11 på platform 8.3.

Indstilling af 1C-konfigurationsegenskaber

Lad os se nærmere på hver af konfigurationsindstillingerne.

• Grundlæggende starttilstand- kan tage værdierne af en administreret applikation eller en almindelig. I fremtiden kan den indstilles separat for hver bruger.
• Indbygget sprogmulighed— definerer standardprogrammeringssprogets syntaks. Hvis du ændrer det, vil modulkonfigurationen ikke automatisk ændre sproget.
• Hovedrolle— rolle i standardkonfigurationen. Normalt er rollen med de største rettigheder installeret.
• Administreret (eller almindeligt) applikationsmodul— et modul, der beskriver globale konfigurationsvariabler og globale konfigurationsbehandlere - Før systemet starter, når systemet starter, før systemet lukker ned, når systemet lukker ned, ekstern hændelsesbehandling.
• Sessionsmodul— en handler, der kører ved systemstart, hvor det er sædvanligt at initialisere .
• Eksternt tilslutningsmodul - Modulet, tilgængeligt via en ekstern forbindelse, indeholder handlere - Ved systemnedlukning, ved systemstart.

Få 267 videolektioner på 1C gratis:

• Primært sprog— standardgrænsefladesprog.
• Hurtige fakta, detaljerede oplysninger, logo, splashskærm, ophavsret— egenskabsinformationsfelter til konfigurationsoplysninger.
• Leverandør- oge— egenskaber, hvor du skal angive oplysninger om udvikleren og en side om denne løsning.
• Rapportens hovedform, rapportindstillinger, rapportmuligheder— formularer, der åbnes som standard for de tilsvarende objekter.
• Leverandør- virksomheden, der har produceret udviklingen.
• Version- konfigurationsversion, ejendom skal næsten altid matche leverandørversionen.
• Opdater katalogadresse— et sted på internettet, hvor du kan downloade de seneste opdateringer.
• Baggrundsinformation— generelle referenceoplysninger om konfigurationen. Afkrydsningsmærke Inkluder i hjælpeindhold tilføjer aktuelle referenceoplysninger til den generelle liste over dokumentation.
• Datalås kontroltilstand— valg af tilstand. Der er 3 muligheder - kontrolleret(konfigurationsudvikleren er ansvarlig for blokering), auto(DBMS er ansvarlig for låsning), automatisk og kontrolleret(kombineret tilstand, styret på objektniveau).
• Automatisk objektnummereringstilstand- to muligheder er mulige, frigives automatisk Og frigives ikke automatisk. Den første mulighed giver dig mulighed for at udfylde huller i nummereringen, hvis de opstår. Slip ikke automatisk gør nummereringen kontinuerlig.
• Kompatibilitetstilstand- et rent teknisk flag, der giver dig mulighed for at aktivere eller deaktivere kompatibilitetstilstand med ældre konfigurationsversioner - 8.1 og 8.2.13 og 8.3. Disse to versioner af platformen var overgangsbestemte, nye metadataobjekter blev tilføjet, så systemet kræver konfigurationsomdannelse. Dette skal håndteres meget varsomt,

Udgifter til arbejde og muligheder for oversættelser fra forskellige udgivelser

	Oversættelse 8.1 → 8.2.13	Oversættelse 8.2.13 → 8.2.16	Oversættelse 8.2.16 → 8.3.10
Pris, gnid. *	54.000 ₽	12.000 ₽	76.800 RUR

En liste over alle ændringer i forskellige versioner af platformen er tilgængelig på følgende links:
For platform 8.2:
http://downloads.v8.1c.ru/content/Platform/8_2_19_106/1cv8upd.htm

Før du starter arbejdet med oversættelsen til 8.3, har du brug for:

Kontroller den kontrollerede blokeringstilstand. Hvis "Automatisk" bruges, kan der ved migrering til 8.3 være behov for yderligere omkostninger for at skifte til administreret låsetilstand.
Hvis du bruger kompatibilitetstilstand med 8.2.16 og nyere, skal du kontrollere, om tabellerne er blevet omstruktureret
Bestem, hvilke typer klienter der bruges (tynd, tyk, webklient)
Bestem, om der er maskiner, der kører Linux

Oversættelse af konfiguration 8.1 → 8.2.13

Udgifter til arbejde: 54.000 rub.

Oversættelse af konfiguration 8.2.13 → 8.2.16 (inklusive omstrukturering)

Nøgleændringer:
Tilstanden til lagring af konstanter og indstillinger af akkumuleringsregistre er blevet ændret. Hvert objekt har sin egen databasetabel
Implementeringen af ​​den administrerede låsemekanisme er blevet omarbejdet.
For den teknologiske loghændelse "TLOCK" skrives egenskaben "Txt" kun i kompatibilitetstilstand med version 8.2.13
Indflydelsen af ​​fejlretningstilstanden på driftshastigheden i 1C:Enterprise-tilstand for tynd klient, tyk klient, server og ekstern forbindelse er blevet reduceret.
Udførelsen af ​​en forespørgsel i formen "ValueType(Field1) = ValueType(Field2)" er blevet optimeret, hvis "Field1" og "Field2" indeholder værdier af en referencetype.
For administrerede formularfelter, der viser attributter af en kompleks type, er åbningen af ​​hurtigvalgslisten blevet fremskyndet i tilfælde, hvor den komplekse type inkluderer referencetyper med forskellige hurtigvalgsindstillinger.
For det nye uafhængige og ikke-periodiske informationsregister er dimensionsindekset samlet

Ændringer, der kræver konfigurationsændringer:

Når kompatibilitetstilstand er deaktiveret, er "Period"-parameteren for den periodiske informationsregister-managermetode "Get()" påkrævet. I kompatibilitetstilstand med version 8.2.13 og version 8.1 er adfærden uændret (metoden kan bruges uden at angive en parameter, men resultatet er udefineret).
Når du bruger "SetValue()"- og "UseFromDataSource()"-metoderne for "DataLockElement"-objektet på samme tid, fremkommer der en undtagelse. I kompatibilitetstilstand med version 8.2.13 er adfærden ikke ændret (værdien indstillet af "UseFromDataSource()"-metoden har forrang).
Det er ikke understøttet at gemme dataværdier, der ikke understøtter serialisering. I kompatibilitetstilstand er adfærden ikke ændret.
Hvis databasen er fil-baseret, så skal infobasen konverteres. Efter konverteringen er begyndt, vil det ikke være muligt at arbejde med denne informationsbase med tidligere versioner af 1C:Enterprise 8-platformen. Hvis udviklingen udføres ved hjælp af et konfigurationsdepot, skal du lave en kopi af depotet, før du konverterer infobasen

VIGTIG. For at få effekten af ​​at ændre kompatibilitetstilstanden skal du foretage en omstrukturering gennem konfiguratoren: "Administration → Test og rettelse → Omstrukturering af infobase-tabeller."

Det er først nødvendigt at udføre omstrukturering på en testbase og måle udførelsestiden for denne operation.
Hvis du bruger en 1C-serverversion ældre end 8.2.19, for eksempel version 8.3, kan følgende fejl opstå, når du udfører omstrukturering:

I dette tilfælde skal du gøre følgende:
Installer en separat 1C-server version 8.2.19 og implementer den database, der undersøges, på den
Åbn databasen i konfiguratoren på 1C-serveren version 8.2.19, skift kompatibilitetstilstanden til "Brug ikke"
Omstrukturer infobasetabeller
Når omstruktureringen er fuldført, skal du flytte informationsbasen til den originale 1C-serverversion 8.3

Omkostningerne ved at overføre konfigurationen fra 8.2.13-kompatibilitetstilstand til 8.2.16-tilstand (ikke-kompatibel tilstand ved brug af 8.2.16, 8.2.19-platformen og 8.2.16-kompatibilitetstilstand ved brug af 8.3-platformen) er 12.000 rub.

En arbejdskontraktskabelon kan downloades.

Oversættelse af konfiguration 8.2.16 → 8.3.10

Konfigurationsoversættelsesarbejdet omfatter følgende konfigurationsændringer:

1. Eliminer ejendomsnavnekonflikter. Ændring af variabelnavne, så de matcher de nye egenskaber, der dukkede op i 1C:Enterprise 8.3.

2. Fjern modstridende billednavne. Omdøbning af navnene på billeder med navne, der matcher navnene fra billedbiblioteket.

3. Forfining af koden ved ændring af egenskaberne for den faste struktur. Udskiftning af indikationen af ​​en fast strukturs egenskaber med genskabelse af en fast struktur eller udskiftning af dens anvendelse med en lignende "Struktur" type.

4. Udskiftning af placeringen af ​​ikke-serialiserbare værdier i midlertidig lagring med kode understøttet i 1C:Enterprise 8.3.

5. Erstat brugen af ​​at kalde "Vis"-metoden for administrerede formulardetaljer med brugen af ​​"CurrentElement", "CurrentPage"-egenskaberne og "Aktiver"-metoden

6. Erstatning af metadataobjektnavne længere end 80 tegn med navne på 80 tegn eller mindre for metadataobjekter

7. Omdøbning af metoder og egenskaber i henhold til metoden for migrering til version 8.3.

8. Forbedring af mekanismer til at arbejde med markeringer, betinget formatering, grupperinger og rækkefølge i dynamiske lister.

9. Forfining af koden for forespørgsler med søgeordet "GENERAL RESULTS", udlæst i "Omgå forespørgselsresultat ved at gruppere", for at bevare den tidligere logik i arbejdet.

10. Ændringer i COM-objektklassenavne. Udskiftning af navnene "V82.COMConnector" med "V83.COMConnector" og "V82.Application" med "V83.Application".

11. Afvisning i programkoden for hændelsen "Start af valg fra liste" for inputfelter i tilstanden for valg fra en liste

12. Afvisning i programkoden fra egenskaben "ChoiceList Button" for inputfelter ved at indstille egenskaben "Dropdown List Button".

13. Ændring af koden for at tage højde for ændringen i værditypen, der returneres af den globale kontekstmetode "SafeMode()"

14. Ændring af koden for at tage højde for ændringen i resultatet af en forespørgsel for konstanter (ved adgang til "Værdi"-feltet i konstanttabellen, hvis konstanten gemmer en værdi af typen "Value Storage", "UniqueIdentifier" eller "Ekstern DataSourceTableReference".

15. Udskiftning af "MainRole"-konfigurationsegenskaben med "MainRoles"

16. Afvisning af egenskaberne "Bruger" og "Password" for "InternetProxy"-objektet og erstatning med metoderne "Set()", "User()", "Password()".

17. Forbedring af koden til at understøtte kommandoen "Vis på liste", i henhold til metoden for overgang til version 8.3.

18. Forfining af koden for at opretholde den tidligere logik for systemdrift, når returværdien af ​​egenskaben SystemInformation.OSVersion er ændret,

19. Forfining af koden for at bevare systemets tidligere logik, når man nægter at bruge systemopregningen OptionOpenWindow, som ikke længere er tilgængelig i version 8.3.

20. Forfining af koden under hensyntagen til afvisningen af ​​at bruge modale vinduer.

21. Forfining af koden til at understøtte webklienten, nemlig afvisning af serverkald og åbning af vinduer i "Før Lukning", afvisning af serverkald i "Ved Lukning".

22. Forbedring af koden for at gøre det muligt korrekt at bruge funktionen RoleAvailable() ved at overføre funktionen som en parameter til en manglende rolle.

23. For en administreret applikation: startende fra version 8.3.8 i hændelseshandlere af en administreret applikation BeforeSystemShutdown, WhenSystemShutdown, såvel som i hændelseshandlere af en administreret form, der er i lukketilstand, BeforeClosing, WhenClosing, Det er forbudt at åbne vinduer og foretage serverkald. Konfigurationen skal forbedres, så formularer kan lukkes korrekt - uden serverkald.

24. Variabelnavnkonflikt: du kan ikke bruge variabelnavnet FormParameters i et formularmodul. Derfor er det nødvendigt at ændre alle administrerede formularmoduler, der bruger variabler kaldet FormParameters, ved at omdøbe disse variable.

Prisen for disse værker er foreløbig og gælder for de fleste konfigurationer. Inden arbejdet påbegyndes ved kontraktindgåelse, tjekker vi konfigurationen og Efter kontrol bekræfter vi prisen og arbejdsvilkårene. Kontrol er nødvendig, fordi konfigurationer kan være meget forskellige, herunder stærkt omskrevet.

Udgifter til arbejde: 76.800 rub.

En arbejdskontraktskabelon kan downloades.

Omkostningerne ved at overføre konfigurationen til kompatibilitetstilstand med 8.3.10 kan være steget, hvis:
Konfiguration bruger administrerede formularer
Det er nødvendigt at opgive brugen af ​​modalitet
Det er nødvendigt at opretholde funktionaliteten af ​​konfigurationen i Linux OS

En ny udgivelse af platformen 8.3.11 er blevet frigivet, som giver dig mulighed for at tilføje og ændre metadataobjekter gennem en udvidelse. Kan vi virkelig nu implementere nogen forbedringer uden at fjerne konfigurationen fra supporten? Er det værd at love en kunde bjerge af guld uden konsekvenser?

Først og fremmest skal du være opmærksom på de begrænsninger, som udvidelser har.

Begrænsning af oprettede objekter

I øjeblikket kan du oprette:

• Vejviser
• Dokumenter
• Informationsregistre
• Udvekslingsplaner

Du kan tilføje detaljer til:

• Vejviser
• Dokumenter

Hvad ender vi med? Ikke alle typer metadataobjekter kan tilføjes. De mest almindelige og populære, men stadig ikke alle. Derudover kan nye dimensioner og ressourcer ikke tilføjes til informationsregistre. Du kan kun oprette et helt nyt register.

Funktionaliteten af ​​udvidelser afhænger af kompatibilitetstilstanden for den konfiguration, som udvidelsen anvendes på.

Kompatibilitetstilstand 8.3.8- du kan kun ændre formerne for objekter og deres moduler, tilføje dine egne rapporter og behandling.

Kompatibilitetstilstand 8.3.10- du kan ændre generelle moduler, objekt- og ledermoduler, roller, brug "Før", "Efter", "I stedet"-direktiverne for alle moduler.

Kompatibilitetstilstand "Brug ikke"- du kan bruge alle funktionerne i udvidelser, inklusive tilføjelse af nye objekter.

I øjeblikket har standard UT 11.3 kompatibilitetstilstand 8.3.8. I UT 11.4 er kompatibilitetstilstanden 8.3.10, det vil sige, for eksempel, for UT er det meste af udvidelsesfunktionaliteten ikke tilgængelig, herunder oprettelse af metadataobjekter.

Dette lader til at stille spørgsmålet: hvorfor ikke bare fjerne supporten af ​​roden, indstille kompatibilitetstilstanden til "Brug ikke" og stille og roligt bruge udvidelserne? Når du ændrer kompatibilitetstilstanden, kan adfærden af ​​formularer og forespørgselsresultater ændre sig, dvs. opførsel af systemet som helhed. Det anbefales kraftigt ikke at ændre kompatibilitetstilstanden uden først at have testet. Men det er indlysende, at det synes muligt fuldt ud at teste (eller i det mindste delvist teste de anvendte dokumenter) en hel applikationsløsning. Derfor bør du ikke bruge denne mulighed.

Når du forbinder en udvidelse til en standardkonfiguration og låner standardobjekter, kontrollerer udvidelsen kompatibilitetstilstanden for hovedkonfigurationen og typerne af lånte objekter og deres detaljer. Hvis de overvågede egenskaber ikke stemmer overens, er udvidelsen deaktiveret og virker ikke, før årsagen er elimineret. Det vil sige, at med en større opdatering er der stor sandsynlighed for at ændre mindst én af de kontrollerede egenskaber og få udvidelsen til at miste funktionalitet.

Derudover, hvis ændringerne er væsentlige, udskiftes mange procedurer og funktioner i standardkonfigurationen, det vil være nødvendigt at omhyggeligt overvåge dem og om nødvendigt bringe dem i overensstemmelse med standardkonfigurationen, idet de tidligere foretagne ændringer bevares.

I ovenstående tilfælde vil du stadig få brug for hjælp fra en programmør og muligvis betydelig tid til ændring (men stadig mindre end ved opdatering af en konfiguration, der er blevet fjernet fra support).

Konklusioner

• Den nye udgivelse af platformen gav nye muligheder for at bruge udvidelser, det blev muligt at tilføje metadataobjekter, men på trods af dette har funktionaliteten visse begrænsninger.
• Kompatibilitetstilstanden for den konfiguration, som udvidelsen anvendes på, begrænser i høj grad udvidelsens muligheder. Det anbefales ikke at ændre kompatibilitetstilstanden.
• Store opdateringer kræver stadig udviklerens opmærksomhed, da der er stor sandsynlighed for at ændre kontrollerede egenskaber.

Mange har hørt ordet "1C: Compatible!", men få ved, hvad der gemmer sig bag det. For de fleste betyder dette ganske enkelt korrekt betjening af softwaren og support til 1C-produktet. For nylig var jeg nødt til at få et "1C: Compatible!"-certifikat. for at supplere konfigurationen, og jeg vil gerne fortælle dig, hvilket arbejde en udvikler skal udføre, og hvad denne certificering giver.

For det første har certificeringen til formål at forbedre kvaliteten af ​​programmer skrevet i 1C:Enterprise 8-systemet og er rettet mod brugere. Når du køber et softwareprodukt med "1C: Compatible!" køberen kan være sikker på, at:

• Dette produkt leveres med detaljeret dokumentation, der indeholder en klar beskrivelse af produktinstallationen, beskrivelse af dets drift og datastruktur;
• med hver opdatering vil innovationerne i den nye version og en beskrivelse af opdateringsprocessen blive beskrevet;
• ved opgradering til en ny version eller udgave vil alle aktuelle data blive overført (med forbehold for instruktionerne for overførsel);
• softwareproduktet vil indeholde skrivebordet og indstillinger, som alle kender (eller servicemenupunktet i en almindelig applikation), som alle brugere af standardkonfigurationer er så vant til;
• Leveringspakken indeholder en demobase, der kan bruges til træning i softwareproduktet;
• Koden til softwareproduktet er skrevet i henhold til 1C-standarder, forsynet med kommentarer, der beskriver kodens funktion.

Certificering vil forbedre forbrugernes holdning til dit produkt og øge produktsalget.

Alt certificeringsarbejde falder på bygherrens skuldre. Det følgende beskriver kort de vigtigste certificeringskrav Hvis du udvikler en konfiguration, der skal certificeres i fremtiden, råder jeg dig til at sætte dig ind i 1C-kravene med det samme, så du ikke har, når du beslutter dig for at gennemgå certificeringen. at omskrive kommentarer og gentage grænsefladen for hele konfigurationen. Men jeg vil med det samme sige, at det meste af arbejdet består i at skabe dokumentation og leveringssæt. Efter min mening er det sværeste ved at skrive kode i første omgang at fylde databasen, spore versioner og vise en besked om ændringer i den nye version.

Følgende kan certificeres:

1. Programmer beregnet til massedistribution, der interagerer med programmer i 1C:Enterprise-systemet (konfigurationer, rapporter, tilføjelser til standardkonfigurationer, eksterne komponenter, klientbanker, udvekslingssoftware)
2. Computere beregnet til brug i forbindelse med 1C:Enterprise 8-softwaresystemet som 1C:Enterprise 8-servere
3. Kasseapparat og andet specialiseret tilsluttet udstyr.
4. Mobile enheder designet til at organisere arbejde med 1C:Enterprise-data direkte på en mobilenhed.

Konfigurationsudvikleren skal opfylde følgende betingelser:

1. Du kan ikke bruge ordet "1C" eller "1C"-logoet i navnet på konfigurationen uden tilladelse fra 1C.
2. Der kræves en skriftlig garanti fra administratoren og et segl fra producentens firma for, at produktet ikke krænker nogens ophavsret.
3. Det er nødvendigt at nummerere konfigurationsversioner i overensstemmelse med Systemet af standarder og metoder til udvikling af konfigurationer til 1C:Enterprise-platformen 8. Desuden skal udgivelsen af ​​en ny version give en overgang fra den tidligere, mens dataene bevares, og ved udgivelse af en ny udgave skal der gives en overgang samtidig med, at dataene bevares, eller proceduren for migrering til en ny udgave skal beskrives.
4. Du kan ikke bruge udtrykket "standardkonfiguration" i forhold til den konfiguration, du opretter.
5. Hvis din konfiguration er skrevet ved hjælp af administreret applikationstilstand, skal dette angives i dokumentationen. Det skal også fungere i nettet og tynde klienter. Hvis nogle funktioner ikke kan udføres i webklienten, bør dette beskrives i dokumentationen.
6. Konfigurationen skal kunne skelne mellem første og efterfølgende kørsler. Når den startes for første gang, skal konfigurationen udføre obligatorisk indledende udfyldning af databasen og bør have valgfri valgfri udfyldning for at forenkle arbejdet med databasen. Efter den første lancering eller efter den første lancering af en ny version, skal konfigurationen give en rapport om ændringerne i infobasen.
7. Alle metadataobjekter skal have et synonym defineret
8. Metadataobjekter på øverste niveau skal sorteres alfabetisk, undtagen objekter med præfikset "Slet". De skal være i bunden.
9. Der skal være en rolle for administratoren med alle rettigheder undtagen interaktiv sletning.
10. Hvis der er en rollefordeling, så bør der være en opdeling i roller med rettigheder fælles for alle og roller, hvor der er nogle andre rettigheder. For eksempel rollen "Grundlæggende rettigheder"
11. Referenceoplysningerne for de vigtigste konfigurationsobjekter skal udfyldes.
12. Administreret låsetilstand skal bruges.
13. Spørgsmål skal udfyldes for alle elementer, hvori brugeren indtaster data.
14. For en administreret applikation skal der altid være en desktop, den sidste sektion skal være administrationssektionen.
15. For en almindelig applikation skal der være en fælles og komplet grænseflade, samt muligheden for at skifte den fra menuen "Værktøjer".
16. For en normal anvendelse skal alle formularelementer justeres.
17. I koden skal hver linje kun indeholde et udsagn, kodeteksten skal justeres med faner, der skal ikke være fejl ved kontrol af moduler og kontrol af konfiguration. Funktioner skal have kommentarer, der beskriver handling, parametre og returneringsresultat.