I denne artikkelen vil vi se på paletten konfigurasjonsegenskaper ved å bruke eksemplet med 1C Trade Management 11 på plattform 8.3.

Innstilling av 1C-konfigurasjonsegenskaper

La oss se nærmere på hver av konfigurasjonsinnstillingene.

• Grunnleggende lanseringsmodus- kan ta verdiene til en administrert applikasjon eller en vanlig. I fremtiden kan den settes separat for hver bruker.
• Innebygd språkalternativ— definerer standard syntaks for programmeringsspråk. Hvis du endrer det, vil ikke modulkonfigurasjonen automatisk endre språket.
• Hovedrolle— rolle i standardkonfigurasjonen. Vanligvis er rollen med de største rettighetene installert.
• Administrert (eller vanlig) applikasjonsmodul— en modul som beskriver globale konfigurasjonsvariabler og globale konfigurasjonsbehandlere - Før systemet starter, når systemet starter, før systemet slås av, når systemet slås av, ekstern hendelsesbehandling.
• Sesjonsmodul— en behandler som kjører ved systemoppstart, der det er vanlig å initialisere .
• Ekstern tilkoblingsmodul - Modulen, tilgjengelig via en ekstern tilkobling, inneholder behandlere - Ved systemavslutning, ved systemoppstart.

Få 267 videotimer på 1C gratis:

• Hovedspråk— standard grensesnittspråk.
• Raske fakta, detaljert informasjon, logo, velkomstskjerm, opphavsrett— egenskapsinformasjonsfelt for konfigurasjonsinformasjon.
• Leverandør- oge— egenskaper der du trenger å spesifisere informasjon om utvikleren og en side om denne løsningen.
• Hovedform for rapporten, rapportinnstillinger, rapportalternativer— skjemaer som åpnes som standard for de tilsvarende objektene.
• Forsørger- selskapet som produserte utviklingen.
• Versjon- konfigurasjonsversjon, eiendom bør nesten alltid matche leverandørversjonen.
• Oppdater katalogadressen— et sted på Internett hvor du kan laste ned de siste oppdateringene.
• referanse informasjon— generell referanseinformasjon om konfigurasjonen. Hake Inkluder i hjelpeinnhold legger til gjeldende referanseinformasjon til den generelle dokumentasjonslisten.
• Datalåskontrollmodus— modusvalg. Det er 3 alternativer tilgjengelig - kontrollert(konfigurasjonsutvikleren er ansvarlig for blokkering), auto(DBMS er ansvarlig for låsing), automatisk og kontrollert(kombinert modus, kontrollert på objektnivå).
• Automatisk objektnummereringsmodus- to alternativer er mulig, frigjøres automatisk Og ikke slipp automatisk. Det første alternativet lar deg fylle ut hull i nummereringen hvis de oppstår. Ikke slipp automatisk gjør nummereringen kontinuerlig.
• Kompatibilitetsmodus- et rent teknisk flagg som lar deg aktivere eller deaktivere kompatibilitetsmodus med eldre konfigurasjonsversjoner - 8.1 og 8.2.13 og 8.3. Disse to versjonene av plattformen var midlertidige, nye metadataobjekter ble lagt til, så systemet krever konfigurasjonskonvertering. Dette må håndteres veldig forsiktig,

Arbeidskostnader og alternativer for oversettelser fra forskjellige utgivelser

	Oversettelse 8.1 → 8.2.13	Oversettelse 8.2.13 → 8.2.16	Oversettelse 8.2.16 → 8.3.10
pris, gni. *	54 000 ₽	12 000 ₽	76 800 RUR

En liste over alle endringer i forskjellige versjoner av plattformen er tilgjengelig på følgende lenker:
For plattform 8.2:
http://downloads.v8.1c.ru/content/Platform/8_2_19_106/1cv8upd.htm

Før du starter arbeidet med å overføre til 8.3 trenger du:

Sjekk den kontrollerte blokkeringsmodusen. Hvis "Automatisk" brukes, kan det ved migrering til 8.3 kreves ekstra kostnader for å bytte til administrert låsemodus.
Hvis du bruker kompatibilitetsmodus med 8.2.16 og nyere, må du sjekke om tabellene har blitt omstrukturert
Bestem hvilke typer klienter som brukes (tynn, tykk, nettklient)
Finn ut om det er maskiner som kjører Linux

Oversettelse av konfigurasjon 8.1 → 8.2.13

Kostnader for arbeid: 54.000 rubler.

Oversettelse av konfigurasjon 8.2.13 → 8.2.16 (inkludert restrukturering)

Viktige endringer:
Modusen for lagring av konstanter og innstillinger for akkumuleringsregistre er endret. Hvert objekt har sin egen databasetabell
Implementeringen av den administrerte låsemekanismen har blitt omarbeidet.
For den teknologiske logghendelsen "TLOCK" skrives egenskapen "Txt" kun i kompatibilitetsmodus med versjon 8.2.13
Påvirkningen av feilsøkingsmodusen på operasjonshastigheten i 1C:Enterprise-modus for tynnklienten, tykkklienten, serveren og ekstern tilkobling er redusert.
Utførelsen av en spørring av formen "ValueType(Field1) = ValueType(Field2)" har blitt optimalisert hvis "Field1" og "Field2" inneholder verdier av en referansetype.
For administrerte skjemafelt som viser attributter av en kompleks type, har åpningen av hurtigvalglisten blitt fremskyndet i tilfeller der den komplekse typen inkluderer referansetyper med forskjellige hurtigvalginnstillinger.
For det nye uavhengige og ikke-periodiske informasjonsregisteret er dimensjonsindeksen gruppert

Endringer som krever konfigurasjonsendringer:

Når kompatibilitetsmodus er deaktivert, kreves "Period"-parameteren til den periodiske inform"Get()". I kompatibilitetsmodus med versjon 8.2.13 og versjon 8.1 er oppførselen uendret (metoden kan brukes uten å spesifisere en parameter, men resultatet er udefinert).
Når du bruker "SetValue()"- og "UseFromDataSource()"-metodene til "DataLockElement"-objektet samtidig, blir det gitt et unntak. I kompatibilitetsmodus med versjon 8.2.13 har ikke virkemåten endret seg (verdien satt av "UseFromDataSource()"-metoden har forrang).
Det støttes ikke å lagre dataverdier som ikke støtter serialisering. I kompatibilitetsmodus har ikke oppførselen endret seg.
Hvis databasen er filbasert, må infobasen konverteres. Etter at konverteringen begynner, vil det ikke være mulig å jobbe med denne informasjonsbasen med tidligere versjoner av 1C:Enterprise 8-plattformen. Hvis utviklingen utføres ved hjelp av et konfigurasjonslager, må du lage en kopi av depotet før du konverterer infobasen

VIKTIG. For å få effekten av å endre kompatibilitetsmodus, må du gjøre en restrukturering gjennom konfiguratoren: "Administrasjon → Testing og korrigering → Restrukturering av infobasetabeller."

Det er først nødvendig å utføre restrukturering på en testbase og måle utførelsestiden for denne operasjonen.
Hvis du bruker en 1C-serverversjon eldre enn 8.2.19, for eksempel versjon 8.3, kan følgende feil oppstå når du utfører omstrukturering:

I dette tilfellet må du gjøre følgende:
Installer en separat 1C-server versjon 8.2.19 og distribuer databasen som undersøkes på den
Åpne databasen i konfiguratoren på 1C-serveren versjon 8.2.19, endre kompatibilitetsmodus til "Ikke bruk"
Omstrukturer infobasetabeller
Etter at omstruktureringen er fullført, flytter du informasjonsbasen til den originale 1C-serverversjon 8.3

Kostnaden for å overføre konfigurasjonen fra 8.2.13-kompatibilitetsmodus til 8.2.16-modus (ikke-kompatibel modus ved bruk av 8.2.16, 8.2.19-plattformen og 8.2.16-kompatibilitetsmodus ved bruk av 8.3-plattformen) er 12.000 gni.

En arbeidskontraktmal kan lastes ned.

Oversettelse av konfigurasjon 8.2.16 → 8.3.10

Koninkluderer følgende konfigurasjonsendringer:

1. Eliminer egenskapsnavnkonflikter. Endre variabelnavn for å matche de nye egenskapene som dukket opp i 1C:Enterprise 8.3.

2. Eliminer motstridende bildenavn. Gi nytt navn til bilder med navn som samsvarer med navnene fra bildebiblioteket.

3. Forfining av koden ved endring av egenskapene til den faste strukturen. Erstatte indikasjonen av egenskapene til en fast struktur med gjenskaping av en fast struktur eller erstatte bruken av den med en lignende "Struktur" -type.

4. Erstatning av å plassere ikke-serialiserbare verdier i midlertidig lagring med kode som støttes i 1C:Enterprise 8.3.

5. Erstatte bruken av å kalle «Vis»-metoden for administrerte skjemadetaljer med bruken av «CurrentElement», «CurrentPage»-egenskapene og «Activate»-metoden

6. Erstatt metadataobjektnavn som er lengre enn 80 tegn med navn på 80 tegn eller mindre for metadataobjekter

7. Gi nytt navn til metoder og egenskaper, i henhold til metodikken for migrering til versjon 8.3.

8. Forbedring av mekanismer for arbeid med utvalg, betinget formatering, grupperinger og rekkefølge i dynamiske lister.

9. Avgrensning av koden for spørringer med nøkkelordet "GENERELLE RESULTATER", lastet ut i "Omgå søkeresultat etter gruppering", for å bevare den tidligere logikken i arbeidet.

10. Endringer i COM-objektklassenavn. Erstatter navnene "V82.COMConnector" med "V83.COMConnector", og "V82.Application" med "V83.Application".

11. Avslag i programkoden for "Start of Selection From List"-hendelsen for inndatafelt i modusen for valg fra en liste

12. Avslag i programkoden fra “ChoiceList Button”-egenskapen for inndatafelt ved å angi “Dropdown List Button”-egenskapen.

13. Endre koden for å ta hensyn til endringen i typen verdi som returneres av den globale kontekstmetoden «SafeMode()»

14. Endring av koden for å ta hensyn til en endring i resultatet av en spørring for konstanter (ved tilgang til "Value"-feltet i konstanttabellen, hvis konstanten lagrer en verdi av typen "Value Storage", "UniqueIdentifier" eller "Ekstern DataSourceTableReference".

15. Bytte ut "MainRole"-konfigurasjonsegenskapen med "MainRoles"

16. Avslag på egenskapene "Bruker" og "Passord" for "InternetProxy"-objektet og erstatning med metodene "Set()", "User()", "Password()".

17. Forbedring av koden for å støtte «Vis i liste»-kommandoen, i henhold til metoden for overgang til versjon 8.3.

18. Avgrensning av koden for å opprettholde den tidligere logikken for systemdrift når returverdien til egenskapen SystemInformation.OSVersion har endret seg,

19. Forbedring av koden for å opprettholde den tidligere logikken til systemet når man nekter å bruke systemoppregningen OptionOpenWindow, som ikke lenger er tilgjengelig i versjon 8.3.

20. Forfining av koden under hensyntagen til avslag på bruk av modale vinduer.

21. Forbedring av koden for å støtte nettklienten, nemlig avvisning av serveranrop og åpning av vinduer i "Før lukking", avvisning av serverkall i "Når lukking".

22. Forbedring av koden for å gjøre det mulig å bruke RoleAvailable() funksjonen korrekt når funksjonen sendes som en parameter til en manglende rolle.

23. For en administrert applikasjon: fra og med versjon 8.3.8 i hendelsesbehandlere av en administrert applikasjon BeforeSystemShutdown, WhenSystemShutdown, så vel som i hendelsesbehandlere av et administrert skjema som er i lukkemodus, BeforeClosing, WhenClosing, Det er forbudt å åpne vinduer og foreta serveranrop. Konfigurasjonen må forbedres slik at skjemaer kan lukkes riktig – uten serverkall.

24. Variabelnavnkonflikt: du kan ikke bruke variabelnavnet FormParameters i en skjemamodul. Derfor er det nødvendig å endre alle administrerte skjemamoduler som bruker variabler kalt FormParameters ved å gi nytt navn til disse variablene.

Prisen for disse arbeidene er foreløpig og gyldig for de fleste konfigurasjoner. Før vi starter arbeidet ved kontraktsinngåelse, kontrollerer vi konfigurasjonen og Etter sjekk bekrefter vi pris og arbeidsvilkår. Kontroll er nødvendig fordi konfigurasjoner kan være svært forskjellige, inkludert sterkt omskrevet.

Kostnader for arbeid: 76.800 rubler.

En arbeidskontraktmal kan lastes ned.

Kostnaden for å overføre konfigurasjonen til kompatibilitetsmodus med 8.3.10 kan være økt, Hvis:
Konfigurasjon bruker administrerte skjemaer
Det er nødvendig å forlate bruken av modalitet
Det er nødvendig å opprettholde funksjonaliteten til konfigurasjonen i Linux OS

En ny utgivelse av plattformen 8.3.11 er sluppet, som lar deg legge til og endre metadataobjekter gjennom en utvidelse. Kan vi virkelig nå implementere noen forbedringer uten å fjerne konfigurasjonen fra støtten? Er det verdt å love en klient fjell av gull uten konsekvenser?

Først av alt må du være klar over begrensningene som utvidelser har.

Begrensning på opprettede objekter

For øyeblikket kan du opprette:

• Kataloger
• Dokumentasjon
• Informasjonsregistre
• Utvekslingsplaner

Du kan legge til detaljer til:

• Kataloger
• Dokumentasjon

Hva ender vi opp med? Ikke alle typer metadataobjekter kan legges til. Den vanligste og mest populære, men fortsatt ikke alle. I tillegg kan ikke nye dimensjoner og ressurser legges til informasjonsregistre. Du kan bare opprette et helt nytt register.

Funksjonaliteten til utvidelser avhenger av kompatibilitetsmodusen til konfigurasjonen som utvidelsen brukes på.

Kompatibilitetsmodus 8.3.8- du kan bare endre formene til objekter og deres moduler, legge til egne rapporter og behandling.

Kompatibilitetsmodus 8.3.10- du kan endre generelle moduler, objekt- og ledermoduler, roller, bruk "Før", "Etter", "I stedet"-direktivene for alle moduler.

Kompatibilitetsmodus "Ikke bruk"- du kan bruke all funksjonaliteten til utvidelser, inkludert å legge til nye objekter.

For øyeblikket har standard UT 11.3 kompatibilitetsmodus 8.3.8. I UT 11.4 er kompatibilitetsmodusen 8.3.10, det vil si at for eksempel for UT er det meste av utvidelsesfunksjonaliteten ikke tilgjengelig, inkludert oppretting av metadataobjekter.

Dette ser ut til å stille spørsmålet: hvorfor ikke bare fjerne støtten til roten, sette kompatibilitetsmodusen til "Ikke bruk" og stille bruk av utvidelsene? Når du endrer kompatibilitetsmodus, kan oppførselen til skjemaer og søkeresultater endres, dvs. oppførselen til systemet som helhet. Det anbefales på det sterkeste å ikke endre kompatibilitetsmodus uten å ha testet først. Men det er åpenbart at det virker mulig å fullstendig teste (eller i det minste delvis teste dokumentene som brukes) en hel applikasjonsløsning. Derfor bør du ikke bruke dette alternativet.

Når du kobler en utvidelse til en standardkonfigurasjon og låner standardobjekter, kontrollerer utvidelsen kompatibilitetsmodusen til hovedkonfigurasjonen og typene lånte objekter og deres detaljer. Hvis de overvåkede egenskapene ikke samsvarer, er utvidelsen deaktivert og fungerer ikke før årsaken er eliminert. Det vil si at med en større oppdatering er det stor sannsynlighet for å endre minst én av de kontrollerte egenskapene og få utvidelsen til å miste funksjonalitet.

I tillegg, hvis endringene er betydelige, erstattes mange prosedyrer og funksjoner i standardkonfigurasjonen, det vil være nødvendig å nøye overvåke dem og, om nødvendig, bringe dem i tråd med standardkonfigurasjonen, og bevare de tidligere utførte endringene.

I de ovennevnte tilfellene vil du fortsatt trenge hjelp fra en programmerer og muligens betydelig tid for endring (men fortsatt mindre enn når du oppdaterer en konfigurasjon som er fjernet fra støtten).

konklusjoner

• Den nye utgivelsen av plattformen ga nye muligheter for bruk av utvidelser, det ble mulig å legge til metadataobjekter, men til tross for dette har funksjonaliteten visse begrensninger.
• Kompatibilitetsmodusen til konfigurasjonen som utvidelsen brukes på, begrenser utvidelsens muligheter i stor grad. Det anbefales ikke å endre kompatibilitetsmodusen.
• Store oppdateringer krever fortsatt oppmerksomhet fra utviklere, da det er stor sannsynlighet for å endre kontrollerte egenskaper.

Mange har hørt ordet "1C: Compatible!", men få vet hva som skjuler seg bak det. For de fleste betyr dette rett og slett riktig drift av programvaren og støtte for 1C-produktet. Nylig måtte jeg få et "1C: Compatible!"-sertifikat. for å supplere konfigurasjonen, og jeg vil fortelle deg hvilket arbeid en utvikler må gjøre og hva denne sertifiseringen gir.

For det første har sertifiseringen som mål å forbedre kvaliteten på programmer skrevet i 1C:Enterprise 8-systemet og er rettet mot brukere. Når du kjøper et programvareprodukt med "1C: Compatible!" kjøperen kan være sikker på at:

• Dette produktet kommer med detaljert dokumentasjon som inneholder en tydelig beskrivelse av produktinstallasjonen, beskrivelse av driften og datastrukturen;
• med hver oppdatering vil innovasjonene i den nye versjonen og en beskrivelse av oppdateringsprosessen bli beskrevet;
• ved oppgradering til en ny versjon eller utgave, vil alle gjeldende data bli overført (med forbehold om instruksjonene for overføring);
• programvareproduktet vil inneholde skrivebordet og innstillinger som er kjent for alle (eller tjenestemenyelementet i en vanlig applikasjon), som alle brukere av standardkonfigurasjoner er så vant til;
• Leveringspakken inkluderer en demobase som kan brukes til opplæring i programvareproduktet;
• Koden til programvareproduktet er skrevet i henhold til 1C-standarder, utstyrt med kommentarer som beskriver hvordan koden fungerer.

Sertifisering vil forbedre forbrukernes holdninger til produktet ditt og øke produktsalget.

Alt sertifiseringsarbeid faller på utbyggers skuldre. Følgende beskriver kort de viktigste sertifiseringskravene Hvis du utvikler en konfigurasjon som må sertifiseres i fremtiden, anbefaler jeg deg å gjøre deg kjent med 1C-kravene umiddelbart, slik at når du bestemmer deg for å gjennomgå sertifisering, har du ikke. å omskrive kommentarer og gjøre om grensesnittet for hele konfigurasjonen. Men jeg vil si med en gang at det meste av arbeidet består i å lage dokumentasjon og leveringssett. Etter min mening er det vanskeligste med å skrive kode i utgangspunktet å fylle databasen, spore versjoner og vise en melding om endringer i den nye versjonen.

Følgende kan sertifiseres:

1. Programmer beregnet for massedistribusjon som samhandler med programmer i 1C:Enterprise-systemet (konfigurasjoner, rapporter, tillegg til standardkonfigurasjoner, eksterne komponenter, klientbanker, utvekslingsprogramvare)
2. Datamaskiner beregnet for bruk i forbindelse med 1C:Enterprise 8-programvaresystemet som 1C:Enterprise 8-servere
3. Kasseapparat og annet spesialisert tilkoblet utstyr.
4. Mobile enheter designet for å organisere arbeid med 1C:Enterprise-data direkte på en mobilenhet.

Konfigurasjonsutvikleren må oppfylle følgende betingelser:

1. Du kan ikke bruke ordet "1C" eller "1C"-logoen i navnet på konfigurasjonen uten tillatelse fra 1C.
2. En skriftlig garanti fra sjefen og et segl fra produsentens selskap kreves for at produktet ikke bryter noens opphavsrett.
3. Det er nødvendig å nummerere konfigurasjonsversjoner i samsvar med Systemet med standarder og metoder for å utvikle konfigurasjoner for 1C:Enterprise-plattformen 8. Videre må utgivelsen av en ny versjon gi en overgang fra den forrige mens dataene tas vare på, og ved utgivelse av en ny utgave må det gis en overgang mens dataene bevares eller prosedyren for migrering til en ny utgave må beskrives.
4. Du kan ikke bruke begrepet "standard konfigurasjon" i forhold til konfigurasjonen som opprettes.
5. Hvis konfigurasjonen din er skrevet med administrert applikasjonsmodus, bør dette oppgis i dokumentasjonen. Den skal også fungere i web og tynnklient. Dersom enkelte funksjoner ikke kan utføres i webklienten, bør dette beskrives i dokumentasjonen.
6. Konfigurasjonen må kunne skille mellom den første og påfølgende kjøringen. Når den startes for første gang, må konfigurasjonen utføre obligatorisk innledende fylling av databasen og bør ha valgfri valgfri fylling for å forenkle arbeidet med databasen. Etter den første lanseringen eller etter den første lanseringen av en ny versjon, skal konfigurasjonen gi en rapport om endringene som er gjort i infobasen.
7. Alle metadataobjekter må ha et synonym definert
8. Metadataobjekter på øverste nivå må sorteres alfabetisk, bortsett fra objekter med "Slett"-prefikset. De skal ligge nederst.
9. Det må være en rolle for administratoren med alle rettigheter unntatt interaktiv sletting.
10. Hvis det er en rolledeling, så bør det være en inndeling i roller med rettigheter felles for alle og roller der det er noen andre rettigheter. For eksempel rollen "Grunnleggende rettigheter"
11. Referanseinformasjonen til hovedkonfigurasjonsobjektene må fylles ut.
12. Administrert låsemodus må brukes.
13. Forespørsler må fylles ut for alle elementer der brukeren legger inn data.
14. For en administrert applikasjon skal det alltid være et skrivebord, den siste delen skal være administrasjonsdelen.
15. For en vanlig applikasjon bør det være et felles og komplett grensesnitt, samt muligheten til å bytte det fra "Verktøy"-menyen.
16. For en normal applikasjon må alle skjemaelementer justeres.
17. I koden skal hver linje kun inneholde én setning, kodeteksten skal være justert med tabulatorer, det skal ikke være feil ved kontroll av moduler og kontroll av konfigurasjon. Funksjoner skal ha kommentarer som beskriver handling, parametere og returresultat.