Selve ideen om å arbeide programmatisk med forhåndsdefinerte elementer, er etter min mening veldig riktig. Det er bare noen nyanser som må tas i betraktning når du arbeider.
Først må du forstå selv at det er forhåndsdefinerte elementer i konfigurasjonen og det er forhåndsdefinerte elementer i infobasen (IB). Teknisk forhåndsdefinerte IB-elementer er de vanligste elementene i ordbøker, der "PredefinedDataName"-attributtet spesifiserer hvilket forhåndsdefinert konfigurasjonselement de tilsvarer. De er ikke mer forskjellige fra vanlige elementer. Følgelig kan et hvilket som helst ordinært IB-element gjøres forhåndsdefinert, hvilket som helst forhåndsdefinert ordinært. For å gjøre dette, skriv bare inn ønsket verdi i rekvisittene. "Forhåndsdefinert DataName".
Med jevne mellomrom viser det seg at denne eiendommen ikke er verdien som utvikleren ga. Som et resultat oppstår det feil i arbeidet til 1C. Fra kritisk, der arbeid i prinsippet er umulig, til ikke-kritisk, der logikken til algoritmene brytes.
Det kan skilles betinget tre typer feil:
1. "Det forhåndsdefinerte elementet mangler fra dataene";
3. Ugyldig indikasjon på et forhåndsdefinert element;
1. "Et forhåndsdefinert element mangler i dataene" - o Fraværet av et forhåndsdefinert element beskrevet i konfigurasjonen i IB-dataene.
Dette er den enkleste typen feil å feilsøke og fikse. Dens enkelhet er at plattformen korrekt nok rapporterer om denne situasjonen "Et forhåndsdefinert element mangler fra dataene", og det er ganske klart hvordan det skal fikses.
Når du får tilgang til det manglende elementet i koden "Directories.Types of ContactInformation.EmailContactPerson" vises meldingen
Når det refereres til et element i forespørselen "VALUE (Directory.Types of ContactInformation.EmailContactPerson)" vises følgende melding:
Denne feilen oppstår hvis et element er beskrevet i konfigurasjonen, men elementet ikke er knyttet til det i databasen.
Til å begynne med, la oss presisere at denne situasjonen ikke alltid er feil. Det er fullt mulig å bruke forhåndsdefinerte data i en slags programlogikk, som for de fleste brukere kanskje ikke brukes. I dette tilfellet, for ikke å rote opp referanseboken for alle brukere av konfigurasjonen, er det logisk å definere forhåndsdefinerte elementer i konfigurasjonen, men ikke å lage dem i alle informasjonssikkerhetssystemer, men bare for de informasjonssikkerhetssystemene i som den nødvendige konfigurasjonslogikken brukes. I dette tilfellet kan programmereren spesifisere egenskapen "Ikke oppdater forhåndsdefinerte data" for referanseboken og opprette elementer programmatisk når du får tilgang til modulens funksjonalitet. Eller for å gjøre det mulig for brukeren å uavhengig binde de forhåndsdefinerte elementene i modulen til de vanlige elementene han har.
Den automatiske opprettelsen av forhåndsdefinerte elementer brukes heller ikke når du arbeider i RIB-modus. Siden nye elementer skal overføres fra den sentrale basen, og ikke opprettes i noder med forskjellige UIDer.
De. noen ganger er det en feil å referere til en gjenstand uten sidestykke, i stedet for selve tilstedeværelsen av en slik gjenstand.
Du må analysere hvorfor varen ikke ble opprettet. Kanskje den bør opprettes når en eller annen modus av programmet kjøres. For eksempel etter å ha utført en utveksling i RIB. Eller kanskje det bare ble slettet ved et uhell.
Hvis logikken sørger for å fylle ut forhåndsdefinerte elementer ikke automatisk, men i en separat modus, før du bruker kallet med navn " Kataloger.Typer kontaktinformasjon.E-postkontaktperson"for å forhindre et unntak, er det tilrådelig å sjekke at elementet allerede er i databasen. Hvis elementet er fraværende, informer brukeren om dette og forklar hvilken modus han må utføre for å fylle elementet. For en slik sjekk, du kan kjøre en spørring på dataene.
Request = Ny forespørsel; Query.Text = "VELG | Kontaktinformasjon EmailContactPerson"" "; ElementNoNo.VD = Request.Run (). Tom ();
Hvis dette fortsatt er en feil i databasedataene, er det nødvendig å binde seg til et forhåndsdefinert element i IB-elementet. De. det er nødvendig å forklare systemet hvilket element av informasjonssikkerhet programkoden skal referere til med dette navnet. Teknisk sett er binding bare å spesifisere navnet på et forhåndsdefinert element i en egenskap "Forhåndsdefinert DataName"IB-element. For å installere det, bare kjør koden:
2. "Det forhåndsdefinerte elementet er ikke unikt" - h advoi forhåndsdefinerte elementer:
Denne situasjonen består i at flere IB-elementer er bundet til ett forhåndsdefinert element. I dette tilfellet, når det refereres til et forhåndsdefinert navn, vil elementet bli valgt tilfeldig. Denne situasjonen er alltid feil. Vanskeligheten ligger i det faktum at plattformen ikke kommuniserer om det på noen måte. Det er bare det at algoritmene begynner å fungere feil.
Rammeverket vil bare rapportere feilen "Forhåndsdefinert element er ikke unikt" når du prøver å redigere et duplisert element.
Inntil ingen trenger å redigere elementet, vil ingen vite om feilen.
Slike duplikater kan opprettes, for eksempel hvis RIB brukes til referanseboken og "Oppdater automatisk"-modus er spesifisert i egenskapene for forhåndsdefinerte data. I dette tilfellet, når utvekslingen utføres, vil én forekomst av de forhåndsdefinerte dataene bli opprettet når konfigurasjonen oppdateres. En andre forekomst av forhåndsdefinerte elementer med samme navn vil bli overført fra den sentrale databasen under utvekslingen.
Disse duplikatene vil også oppstå ved bruk av utvekslingsbehandling mellom konfigurasjoner i tilfelle forskjellige informasjonssikkerhetselementer tilsvarer forhåndsdefinerte elementer i forskjellige databaser. I dette tilfellet finnes en kopi av de forhåndsdefinerte dataene allerede i databasen, den andre kommer når data lastes inn med en annen UID. Hvis du utfører dataoverføringer, må du bestemme hvilke databaseelementer som anses som primære og bruke dem i den underordnede databasen. I den underordnede basen er det nødvendig å erstatte bruken av gamle elementer med elementer av hovedbasen.
Slike feil i databasen kan oppdages av en spørring av skjemaet:
VELG Typer av kontaktinformasjon. Forhåndsdefinert Data Navn, ANTALL (ULIKE TYPER KONTAKTINFORMASJON.Link) SOM Nummer Forhåndsdefinert fra katalogen.Typer av kontaktinformasjon AS Typer av kontaktinformasjon.
Denne spørringen vil returnere en liste over forhåndsdefinerte elementer med mer enn ett IB-element tilknyttet.
Hvis det er slike elementer, er det nødvendig å fjerne forbindelsen med den forhåndsdefinerte for en av dem. De. det er nødvendig å entydig bestemme for systemet hvilket IS-element programkoden skal referere til ved bruk av dette navnet. For å gjøre dette trenger du bare å utføre koden.
3. Ugyldig indikasjon på et forhåndsdefinert element.
Feilen ligger i det faktum at det forhåndsdefinerte elementet tilsvarer feil element, som leveres av programlogikken. Slike feil er de vanskeligste å diagnostisere. I motsetning til de to første typene, kan du ikke automatisk sjekke konfigurasjonen for disse feilene. De kan bare identifiseres ved å analysere logikken i arbeidet. Hvis du er i tvil, kan du sjekke om riktig vare blir brukt.
For å gjøre dette, kjør bare en av kommandoene.
// Definisjon av et IB-element som er knyttet til den nødvendige forhåndsdefinerte rapporten (Directories.Types of ContactInformation.EmailContactPerson) // Bestem det forhåndsdefinerte elementet som den valgte rapporten er knyttet til (ReferenceOnItem.Name of PredefinedData)
Hvis slike feil blir funnet, er det nødvendig å fjerne den feilaktige koblingen med det gamle elementet og legge til en kobling med det nye elementet. Op-koden ligner på korrigeringskoden for de to første typene feil.
Vel, kort om feil under programdrift eller i konfiguratormodus:
"Det forhåndsdefinerte elementet tilhører ikke<Имя справочника>" - en feil oppstår når du prøver å skrive et forhåndsdefinert element med et navn som ikke samsvarer med navnet i medkonfiguratoren.
"Ikke-forhåndsdefinerte objekter kan ikke ha forhåndsdefinerte subconto-typeoppføringer" - det oppstår en feil når du prøver å gjøre et forhåndsdefinert kontoplanelement udefinert. For å eliminere feil, er det nødvendig å fjerne merket for "Forhåndsdefinert"-flagget for hver linje i elementunderkontrakten.
"Ikke-forhåndsdefinerte objekter kan ikke ha forhåndsdefinerte poster over ledende typer beregninger"- en feil oppstår når du prøver å gjøre et forhåndsdefinert element i et diagram med beregningstyper udefinert. For å eliminere feil, er det nødvendig å fjerne "Forhåndsdefinert"-flagget for hver linje i den ledende typen elementberegning.
"Forhåndsdefinerte elementer er ikke unike"- en feil vises i konfiguratoren når du oppdaterer infobasen til en konfigurasjonsutgivelse uten 8.3.4-kompatibilitetsmodus. Det er nødvendig å sjekke duplikater og eliminere dem før oppdatering.
"Navnet på det forhåndsdefinerte elementet er ikke unikt" - feilen oppstår hvis det er flere forhåndsdefinerte elementer med samme navn i konfigurasjonen ved oppdatering til plattformen8.3.6.2332 og senere. Det er nødvendig å eliminere duplikater i konfigurasjonen.
For å jobbe med forhåndsdefinerte data anbefaler jeg behandling. Hun vet hvordan hun skal utføre alle handlinger med forhåndsdefinerte data, og kan også sjekke konfigurasjonen som helhet for tilstedeværelsen av feil av de to første typene (dupliserte og manglende elementer) i alle informasjonssikkerhetsobjekter (referansebøker, kontoplaner, PVC) , PVR).
Alle vet forskjellen mellom forhåndsdefinerte elementer og vanlige: "Forhåndsdefinerte elementer opprettes i konfiguratormodus og kan ikke slettes i 1C: Enterprise-modus." I brukermodus kan du skille et forhåndsdefinert element fra de som er lagt til av brukere med et spesielt ikon (se neste skjermbilde).
I utgangspunktet lages forhåndsdefinerte elementer av utviklere for å knytte algoritmene til dem i ulike konfigurasjonsobjekter. For eksempel, i "Manufacturing Enterprise Management"-konfigurasjonen i "Quality"-referansen, la utviklerne til et forhåndsdefinert element "New".
Dette elementet brukes i mange konfigurasjonsmoduler. Så i dokumentet "Mottak av varer og tjenester", når du posterer i alle registre hvor det er en dimensjon "Kvalitet", erstattes verdien av et forhåndsdefinert element. Følgende er en liste over hvordan du fyller ut tabellen over transaksjoner i "Organisasjonsvarer"-registeret:
// VARER I REGISTRET VarerOrganisasjoner. Sett med bevegelser = bevegelser. Produkter Organisasjoner; Hvis Kvitteringstype = Overføringer. Typer av inntektsgoder. På lager da // Få en tabell med verdier som samsvarer med strukturen til registerets rekordsett. Flytt tabell = Flytt sett. Avlast (); // Fyll ut bevegelsestabellen. Generelt formål. LoadInTableValues (TableBy-produkter, TableMotions); // Manglende felt. Tabell over bevegelser. FillValues (Organisasjon, "Organisasjon"); Tabell over bevegelser. FillValues (Udefinert, "kommisjonær"); Tabell over bevegelser. FillValues (Referanser. Kvalitet. Nytt, "Kvalitet"); // Fyllkvalitet fra et forhåndsdefinert elementDermed er egenskapene til de forhåndsdefinerte elementene og deres formål ganske enkle. La oss se på hvordan de er lagret i databasetabeller og hvordan det skiller seg fra vanlige elementer.
Forskjeller
Katalogen "Produkter" er opprettet i testkonfigurasjonen. "Testelementer"-gruppen er opprettet i den. Du kan se innholdet i gruppen i skjermbildet i begynnelsen av artikkelen. For referansen "Produkter" i SQL-databasen er det en tilsvarende tabell "_Reference37" med følgende struktur:
Men hvordan bestemme korrespondansen mellom attributter til konfigurasjonstreet og feltene i SQL-tabellen?
La oss bruke standardmetoden for den globale konteksten "GetDatabaseStorageStructure ()", som vil returnere oss en tabell med verdier med en beskrivelse av strukturen til tabellene.
I verditabellen "Felt" ser vi samsvaret mellom SQL-tabellfeltene og objektattributtene i metadatatreet. I vårt eksempel vurderer vi strukturen til "Produkter"-katalogen. Alle kataloger har et standard "Forhåndsdefinert" boolsk typeattributt, som er satt til TRUE for forhåndsdefinerte elementer:
I henhold til tabellen med strukturen for lagring av referanseboken i databasen, kan vi definitivt si at feltet "Forhåndsdefinert" tilsvarer feltet "IsMetadata". Hvis vi ser på innholdet i "_Reference37"-tabellen i SQL-databasen, vil vi se følgende:
I posten for et forhåndsdefinert element er verdien av "IsMetadata"-feltet satt til "0x01", som tilsvarer TRUE-flagget. For vanlige varer settes verdien til "0x00". Dette er hovedforskjellen mellom forhåndsdefinerte elementer og vanlige. Alle andre felt lagres i databasen på samme måte som for vanlige brukertillagte elementer.
De forhåndsdefinerte elementene kan vise seg å ha svært interessante bruksområder. Med deres hjelp kan du forby sletting / markering for sletting av en gruppe elementer i oppslagsboken og andre objekter der de kan legges til. Hvis vi prøver å slette eller markere for sletting, "Testelementer"-gruppen. da får vi følgende feil:
Dermed gjør forhåndsdefinerte elementer gruppen de er plassert i også "forhåndsdefinert".
Fullføring
Forhåndsdefinerte elementer er en integrert del av de fleste konfigurasjoner. Bruken av dem forenkler utviklingen og gjør konstruksjonen av funksjonalitet logisk mer "harmonisk" og sammenhengende.
Når du arbeider på 1C: Enterprise 8.x-plattformen, er det ofte nødvendig å binde inn programkoden til de vanlige (ikke forhåndsdefinerte) elementene i kataloger. For eksempel kan en organisasjon ha fem typer priser som brukes i nesten alle mekanismer. Samtidig utføres programmatisk tilgang til en bestemt pris i beste fall enten ved å knirke av en kode i oppslagsboken, i verste fall ved navnet på elementet.
Jeg så hvordan i rapportene for å få den nødvendige prisen, ble valg etter pristype brukt i en forespørsel ved navn (se neste skjermbilde).
I tillegg, hvis du binder deg til navnet eller koden til katalogelementene, vil det alltid bli utført et søk i katalogtabellen når du mottar en lenke til elementet. Til tross for at standardsystemattributtene er indeksert av DBMS, kan søket med dem i noen tilfeller ta betydelige ressurser. I tillegg vil det være mer rasjonelt å ikke utføre et søk på oppslagstabellen hvis, la oss si, lenken til elementet allerede er "kjent på forhånd".
Som en utvei kan du lagre en referanse til hver ofte brukte vare i oppslaget "Varepristyper" i separate konstanter og få verdier fra dem i spørringen. I dette tilfellet vil imidlertid utvikleren måtte legge til en separat konstant for hvert slikt element. Situasjonen vil bli mye mer komplisert hvis slike elementer ikke bare er i katalogen "Varepristyper", men også i andre kataloger ("Objektkategorier", "Kvalitet", "Nomenklatur" og andre). Da kan antallet konstanter i systemet øke flere ganger!
Selvfølgelig kan man legge til forhåndsdefinerte elementer til hver av katalogene, og det ville være mye lettere å få tilgang til dem. En endring av de generiske objektene vil imidlertid komplisere prosessen med å oppdatere konfigurasjonen fra leverandørpakker.
Det er en bedre tilnærming både når det gjelder å utvikle og når det gjelder systemytelse. I dag skal vi snakke om ham.
One-stop løsning
Essensen av en universell løsning vil være som følger: en referanse vil bli opprettet som utvikleren vil legge til forhåndsdefinerte elementer. Variabelen "Verdi" er lagt til ordboken, hvis type avhenger av verdiene som korrespondansen "Forhåndsdefinert ordbokelement -> Tilknyttet verdi" vil bli opprettet for. Katalogmetadatastrukturen ser slik ut (se neste skjermbilde).
For å få et forhåndsdefinert element er det beste alternativet å bruke den globale metoden "Forhåndsdefinert verdi (<Имя>)" ... Den fullstendige banen til det forhåndsdefinerte elementet sendes til metoden som en parameter. Syntaksen ligner på "VALUE ()" spørringsspråkfunksjonen.
For enkel utvikling anbefaler jeg å flytte funksjonen for å få verdien knyttet til et forhåndsdefinert element inn i en felles modul. I testkonfigurasjonen, tilgjengelig for nedlasting på lenken på slutten av artikkelen, er det opprettet en felles modul "PredefinedElement Values" med en eksportfunksjon "GetValuePredefinedElement (<ИмяПредопределенногоЭлемента>)" ... Programkoden til funksjonen mottar en lenke til et forhåndsdefinert element, og mottar deretter, på forespørsel, verdiene til "Value"-attributtet. Følgende skjermbilde viser den fullstendige listen over funksjonen.
Som vi kan se, genererer funksjonen en forespørsel til "Value"-attributtet til det forhåndsdefinerte elementet som sendes som en parameter. Funksjonsparameteren er en streng med navnet på et forhåndsdefinert element.
For at den opprettede mekanismen skal fungere ordentlig, må du binde et forhåndsdefinert element med et vanlig katalogelement i brukermodus ved å velge det tilsvarende elementet i "Verdi"-attributtet. La oss gå videre til spørsmålet om innvirkning på ytelse.
Innvirkning på ytelse
Gjennomførte en hastighetstest for begge søkealternativene: etter navn og ved referanse fra et forhåndsdefinert element. Søket gikk gjennom «Produkter»-katalogen med 20 000 poster. Når du utførte tester på en fildatabase, ble følgende resultater oppnådd:
Resultatene viste at for filversjonen av arbeid fungerer bruk av forhåndsdefinerte elementer for å få ofte brukte elementer fra andre kataloger nesten 4 ganger tregere!
I klient-serverversjonen av verket viser testresultatene et helt annet bilde. Hastigheten for å få en lenke til ønsket element gikk ikke nevneverdig ned (en av testene viste 0,002 sek. For søk på navn og 0,0008 sek. Ved arbeid gjennom et forhåndsdefinert element) økte imidlertid programmets pålitelighet betydelig!
konklusjoner
I tilfeller hvor det ofte er nødvendig å binde til vanlige katalogelementer, anbefaler jeg å ikke bruke binding med kode eller navn. Denne tilnærmingen reduserer påliteligheten og ytelsen til systemet.
Under arbeidet med plattformen har jeg gjentatte ganger møtt situasjoner der de fleste ikke-standardrapporter krasjet etter å ha endret navnet, for eksempel for elementet i referanseboken "PriceNomenclature Types".
Jo flere algoritmer som er knyttet til vanlige katalogelementer gjennom en kode eller navn, jo mindre stabilt er systemet.
I tillegg vil denne tilnærmingen tillate deg å ikke endre typiske konfigurasjonsobjekter hvis du trenger å legge til et forhåndsdefinert element til dem. I fremtiden vil dette gjøre prosessen med å oppdatere konfigurasjonen noe enklere.
Nedlastinger:
- Lossing av testbasen med eksempler fra artikkelen.
God dag.
I dag skal vi snakke om en innovasjon i 8.3-plattformen angående forhåndsdefinerte elementer.
Introduksjon
La meg minne deg på at jeg tidligere, i praksis, veldig ofte ønsket å se på et katalogelement for å finne det forhåndsdefinerte navnet. For eksempel har du opprettet to forhåndsdefinerte kontraktører og kalt dem IPSidorov og OOOMeteor. Og de sydde en slags logikk på dem.
Da alt ble feilsøkt og fungerte, viste det seg at oppgaven ble satt omvendt og logikken for eneeier er nødvendig for LLC, og logikken til LLC er for eneeier. "Ikke noe problem," sier vi, og i bedriftsmodus gir vi nytt navn til varene. Det er mye vanskeligere å komme inn i koden. Et år går og du får en ny oppgave: å sette opp litt mer logikk for IP Sidorov. Du går inn i konfiguratoren, skriver logikken, begynner å sjekke og ingenting fungerer, fordi i konfiguratoren til IPSidorov, og i bedriften - OOO Meteor. Hjernen er ødelagt og jeg vil ødelegge denne raken. Det enkleste og mest intuitive er å skrive ut navnet på et forhåndsdefinert element i form av en liste. Her er et bakhold, du kan få navnet på forhåndsdefinerte i 8.2 bare ved metoden. Og metoden har sin egen ulempe, den kan ikke fås i forespørselen. De. den første ulempen er å få navnet på den forhåndsdefinerte ved referanse til katalogen.
Den andre ulempen er når vi allerede har et katalogelement og vi må gjøre det forhåndsdefinert. Vi lager et forhåndsdefinert element og får to elementer i katalogen. En forhåndsdefinert, en annen fungerer, som det refereres til i alle våre dokumenter. Å erstatte lenker hjelper absolutt, men hvis databasen er stor, er det vanskelig.
Nå på forretningsreise
Den første er at referansen nå har egenskapen "Oppdater forhåndsdefinerte data".
Hva gir dette feltet oss? Hvis den er satt til "Ikke oppdater automatisk", så ved å legge til et forhåndsdefinert element, vil vi ikke se det i referansen umiddelbart. De. metadata har ingenting med data å gjøre. Og hvis det ikke er opprettet i katalogen, vil det å referere til det ved navn gjennom katalogbehandleren forårsake en syntaksfeil.
Veldig interessant, men hvorfor? Hvordan lager vi et element i referansen? Og som du ønsker, kan du opprette, eller du kan koble den til en eksisterende. Nå har oppslaget «PredefinedDataName»-attributtet. Vi oppretter et katalogelement programmatisk som vanlig gjennom "References.Contractors.CreateElement ()" og fyller dets "PredefinedDataName"-attributt lik navnet på den forhåndsdefinerte varen. Eller, hvis elementet allerede eksisterer, henter vi objektet og fyller igjen "PredefinedDataName" i det. Alt.
Og til slutt litt sirup
Denne nye rekvisitten er ikke bare lese / skrive, men også tilgjengelig i forespørsler. Dermed kan du pålegge den betingelser i spørringer, bestemme om den er forhåndsdefinert eller ikke.
Takk for oppmerksomheten.
I den fjerde leksjonen av vår vi vil fortsette å gjøre oss kjent med programmet. I dag skal vi bli kjent med oghierarkiske kataloger, samt lære hvordan du lager forhåndsdefinerte elementer.
Tidspunkt for 4 leksjoner av kurset:
00:19
Endringer i medarbeiderveiledningen etter fullført lekser til 3. time i kurset
00:35
Redigere rekkefølgen på attributter i kataloger
02:54
Opprette referanseboken for nomenklaturen
03:40
Opprette og konfigurere en hierarkisk katalog
05:10
Opprette grupper Tjenester og produkter i nomenklaturkatalogen
06:05
Fyller ut referanseboken for nomenklaturen
07:14
3 måter å flytte et katalogelement til en annen gruppe
08:21
Oppretting av varehuskatalogen
09:19
Opprette forhåndsdefinerte katalogelementer
11:25
Fyller ut varehuskatalogen
12:20
Ta materialtestleksjon 4
Hierarkisk katalog- en oppslagsbok med mulighet for hierarkisk ordning av elementene. For eksempel, i nomenklaturkatalogen, kan grupper opprettes: Varer, Tjenester, etc., der elementene som tilhører disse gruppene er plassert. I tillegg kan kataloggrupper inkludere andre grupper, og dermed skape en hierarkisk struktur på flere nivåer.
I tillegg støtter ordbøker også en annen type hierarki, der elementene i ordbøkene vil referere ikke til grupper, men til andre elementer i de samme ordbøkene. Denne typen hierarki ( element hierarki) kan for eksempel brukes når du oppretter katalogen Underavdelinger, der en underavdeling (en underavdeling i dette tilfellet, et element i katalogen, ikke en gruppe) kan inkludere flere andre underavdelinger. Denne typen hierarki brukes sjelden.
Katalogskjemaer- visuell presentasjon av oppslagsboken. Avhengig av hva slags handlinger vi ønsker å utføre med katalogen vår, må vi vise katalogen i "forskjellige visninger". Så i den fjerde leksjonen av kurset redigerte vi rekkefølgen av rekvisita i form av en liste og i form av et referanseelement.
Systemet lager (genererer) skjemaer automatisk, men om nødvendig kan utvikleren "tegne" skjemaene på egen hånd.
Det er 5 skjemaer (typer av skjemaer) for oppslagsverk:
- elementets form- for å opprette eller redigere et katalogelement;
- gruppeform- for å opprette eller redigere en kataloggruppe;
- listeskjema- for å vise en liste over katalogelementer;
- valgskjema- brukes til å velge ett av elementene i denne katalogen i et felt av en bestemt form. For eksempel, for å velge et spesifikt lager fra lagerkatalogen i Varemottaksdokumentet i lagerfeltet;
- gruppevalgskjema- brukes til å velge en av gruppene i denne katalogen i et felt av en eller annen form.
Forhåndsdefinerte katalogelementer- katalogelementer opprettet av utvikleren i konfiguratormodus, og som kan nås fra det innebygde 1c-språket etter navn.
Det er en grunnleggende forskjell mellom vanlige og forhåndsdefinerte katalogelementer. Vanlige elementer er inkonsekvente i konfigurasjonen. Under brukerens arbeid kan de opprettes, redigeres og slettes, og derfor bør de ikke stoles på når du utfører noen algoritmer (koden og navnet på elementet kan endres av brukeren).I motsetning til dette er forhåndsdefinerte elementer permanente. I løpet av arbeidet, selv om brukeren gir nytt navn til et slikt element, vil det være mulig å få tilgang til det fra det innebygde 1c-språket. Dette oppnås på grunn av at det forhåndsdefinerte elementet har en rekvisitt Navn som ikke er tilgjengelig for brukeren. Vanlige elementer i katalogen har ikke et slikt attributt.
Viktig! Teknisk sett har brukeren muligheten til å slette et forhåndsdefinert ordbokelement, men som regel er brukere deaktivert fra rettighetene til å slette forhåndsdefinerte ordbokelementer.
Lekser til 4. leksjon i kurset
Lekser til den fjerde leksjonen av kurset vil være tilgjengelig for deg umiddelbart etter at du har løst teoriprøven.
