1C informasjonsregistre det er et strukturert sett med data med dimensjoner og ressurser. Designet for å lagre periodisk informasjon.

Periodisitet

Informasjon lagres etter dimensjon og periode. Du kan stille inn frekvensen til informasjonsregisteret:

• Ikke periodisk
• av registrator
• sekund
• en uke
• måned
• fjerdedel

Frekvens er nødvendig for å velge informasjon fra registeret for en viss tidsperiode. Dersom du spesifiserer en frekvens, vil oppføringer i registeret bli gjort med perioden da oppføringen ble gjort. La oss si at hvis du ser på "Varepriser"-registeret, kan du se historien om prisendringer, med hvilke målinger og i hvilken tidsperiode oppføringen ble gjort.

Periodisitet i informasjonsregistre er nødvendig for informasjon som endrer seg over tid, for eksempel: valutakurser, produktpriser, produktrabatter og påslag mv.

Registratorer

Hvis du registrerer deg i informasjonsregisteret ved hjelp av et dokument, må du sette innføringsmodusen: "Innsending til registraren" og velge dokumentet som registreringen skal gjøres med i registeret. Da vil feltet «Registrar» dukke opp i registeret, hvor det vil bli lagret informasjon om hvilket dokument innførselen er gjort med. Opptakeren kan også brukes som en periode; for å gjøre dette, angi i feltet "Frekvens" - "Ved opptaker". Underordning til registraren gjøres når det er nødvendig å strengt knytte et register til et dokument og endrede oppføringer i registeret manuelt blir utilgjengelige.

Det kan være flere dokumenter som vil fungere som registrarer. For å legge til en registrar, må du gå til egenskapene til det ønskede informasjonsregisteret, gå til fanen "Registrarer" og merke av i boksene ved siden av dokumentene som skal fungere som registrar.

Du kan se bevegelsene opptakeren gjør fra dokumentet. For å gjøre dette, må du gå til dokumentet du er interessert i, klikk: Gå – Dokumentbevegelser av registraren.

Ikke glem å legge til rettigheter i registeregenskapene; de ​​kan tildeles på fanen "Rettigheter". Så i listen over roller må du velge rollen du vil legge til rettigheter til registeret og i rettighetslisten sette rettighetene til for den valgte rollen.

Unikt av poster

Det unike med en post avhenger av perioden og målingene. Hvis du for eksempel vil skrive en post med samme mål i "Varepriser"-registeret samme dag, vil du ikke kunne gjøre dette, og programmet vil forårsake en feil, siden registerets periodisitet er innen en dag.

Hvis frekvensen er fastsatt av registraren, deltar den også i postens unike karakter.

For ikke-periodiske og uavhengige registre avhenger unikhet av kombinasjonen av dimensjoner.

Skjemaer

For å se poster, bruk listeskjemaet, i det kan du sette utvalget i henhold til feltene du er interessert i, se historikken til poster og endre dem gjennom postskjemaet. Du kan se registeroppføringer som følger: i toppmenyen klikker du på knappen "Operasjoner" - "Informasjonsregistre". I vinduet som åpnes velger du registeret du trenger. Etter dette vil et listeskjema åpnes i form av en tabell, hvor hver oppføring er en unik oppføring.

For å redigere/opprette, bruk postskjemaet, hvis posten er underordnet registraren, vil ikke feltet være tilgjengelig og skjemaet kan ikke opprettes.

Du må legge til skjemaer i konfiguratoren ved å gå til informasjonsregisteret, i «Skjemaer»-fanen og klikke på «forstørrelsesglasset» ved siden av ønsket type skjema. Deretter åpnes et vindu der du kan konfigurere feltene til det fremtidige skjemaet (plassering, navn og spesifisere funksjonalitet).

Dimensjoner, ressurser og detaljer

Dimensjoner er ment å danne det unike til en post; i fremtiden kan du velge dem og lage et kutt basert på en bestemt dimensjon. Kombinasjonen av målinger danner rekordnøkkelen. Det er bedre å ikke lage et stort antall dimensjoner slik at bordet ikke vokser og ikke bremser mens du arbeider med det.

Dimensjoner har en "Leading"-avmerkingsboks; hvis det er merket av, vil posten bli lagret i databasen så lenge denne dimensjonen eksisterer. Flere ledende målinger kan gjøres. For eksempel i informasjonsregisteret «Varepriser» er den ledende dimensjonen varen, hvis du sletter en vare som er inkludert i posten, vil oppføringen i informasjonsregisteret for denne varen automatisk slettes.

Ressurser er laget for å lagre sammendragsinformasjon: mengde, pris osv. I fremtiden vil vi motta ressurser for en viss tid (hvis registeret er periodisk), i henhold til målinger.

Detaljer er i de fleste tilfeller ment å lagre tilleggsinformasjon; de tar ikke del i det unike ved posten. For eksempel kan du legge inn informasjon som forfatter, kommentar osv. i detaljene.

Du kan utføre følgende handlinger med informasjonsregisteret:

• Sletting av en oppføring i 1C informasjonsregisteret

Egendommer

— Unikhet til poster basert på et sett med dimensjoner: hver post i informasjonsregisteret er en ny ressursverdi.

— Innføringer i informasjonsregisteret kan enten være periodiske eller ikke.

— Informasjonsregisteret kan være avhengig og uavhengig av registraren.

— Det er mulig å lage et tverrsnitt av første og siste post for ønsket dato. Dette er implementert av virtuelle tabeller: "Slice of the First" og "Slice of the Last". For å bruke disse tabellene kan du bruke både utvalg og spørring (i spørringsdesigneren vil du velge disse virtuelle tabellene og du kan lage en spørring på dem). Disse tabellene vil være tilgjengelige dersom informasjonsregisteret er periodisk.

"Varepriser"-registeret er et periodisk register over informasjon, oppføringer gjøres i henhold til registraren.

Bildet viser at frekvensen er satt til innen en dag. Dette betyr at prisen kan endres en gang i døgnet basert på målinger unike i løpet av dagen.

Registeret er underlagt dokumentet «Sett varepriser». Det betyr at innføringen i registeret kommer fra dette dokumentet. Bevegelser på et spesifikt dokument kan sees fra dokumentskjemaet "Angi varepriser".

Registeret er laget for å lagre informasjon om prisen på en vare, med dimensjonene "Pristype", "Vare" og "Vareegenskaper". Den ledende dimensjonen er alle tre dimensjonsfeltene, det vil være mulig å gjøre valg basert på den ved prøvetaking.

Konklusjon: Etter å ha lest artikkelen vil du kunne opprette et 1C informasjonsregister, legge til dimensjoner og ressurser, konfigurere redigering og liste opp skjemaer. Opprett en post og velg eksisterende poster. Hvis du har spørsmål, bruk kommentarene i artikkelen, jeg vil prøve å raskt svare på spørsmålet ditt.

Noen ganger må du bruke en spørring for å hente data for flere datoer samtidig fra et periodisk informasjonsregister. Et typisk eksempel er arbeid med valutakurser. La oss vurdere en algoritme for å løse dette problemet ved å bruke et eksempel.

Formulering av problemet

Et dokument "Salg av varer og tjenester" er opprettet i databasen, i overskriften som det er attributtet "Valuta". Forespørselen krever for hvert dokument å hente gjeldende valutakurs fra overskriften på datoen for dokumentet. Valutakurser lagres i det periodiske informasjonsregisteret "Valutakurser".
En direkte løsning på dette problemet kan være en spørring i en løkke: innhenting av alle dokumenter med deres datoer og valutaer og, i prøven, tilgang til den virtuelle tabellen med en del av det siste "Valutakurs"-registeret. Men fordi en forespørsel i en loop er "dårlig", la oss prøve å implementere oppgaven med en forespørsel.

Løsning

For å løse problemet vil vi bruke det faktum at tabellene i spørringen kan kobles ikke bare for likestilling av felt.

VELG Salg av varer og tjenester. Link, Salg av varer og tjenester. Valuta, MAKSIMUM (Valutakurser. Periode) SOM Periode PLASS I TPerioder Angi kurser FRA Dokument Salg av varer og tjenester HVORDAN Salg av varer og tjenester VENSTRE TILKOBLING Informasjonsregister. Valutakurser AS Valutakurser Programvare Salg av produkter ovServices.Currency = Valutakurser.Valuta Og Salg av VareTjenester.Dato >= Valutakurser.Periode GROUP Programvare Salg av varer og tjenester Link, Salg av varer og tjenester Valuta; ////////////////////////////////////////////// ////////////////////////// SELECT VTPeriodsSetting Rates.Link, VTPeriodsSetting Rates.Currency, RatesCurrency.Rate FROM VTPeriodsSetting Rates AS VTPeriodsSetting Rates.Link,VTPeriodsSetting Rates.Currency, RatesCurrency.Rate FROM VTPeriodsSetting Rates AS VTPeriodsSetting Rates. Valutakurser AS Valutakurser PÅ VTPeriodsRate Settings.Period = Valutakurser.Period OG VTPeriodsRate Settings.Currency = Valutakurser.Valuta

Prosedyre for forespørsel:

1. Innhenting av perioden for å sette valutakursen for hvert dokument. Dokumentene er koblet til den FYSISKE tabellen "Valutakurser". Her bør du være oppmerksom på tilkoblingsforholdene. Valutaene skal være like, og dokumentdatoen >= perioden for informasjonsregisteret.
   Som et resultat av en slik forbindelse, for hvert dokument, vil et sett med rader bli oppnådd som tilfredsstiller betingelsen: alle registreringer av valutakurser for dokumentets valuta, etablert senest på datoen for dokumentet.
   Det siste trinnet vil være å gruppere radene for å oppnå maksimal satsperiode. Som et resultat vil den nødvendige perioden for å angi valutakursen for den ønskede valutaen for hvert dokument bli oppnådd (maksimal dato for innstilling av valutakursen, men ikke mer enn datoen for dokumentet). Resultatet plasseres i den midlertidige tabellen VTPeriodsSettingRates.
2. Å få et kurs. Den midlertidige tabellen VTPeriodsSetting Rates er koblet til den FYSISKE tabellen "Valutakurser". Tilkoblingen skjer i henhold til dokumentvalutaen og rateinnstillingsperioden definert i den andre midlertidige tabellen.

: Utsnitt av den første Og Slice of the Last La oss vurdere å jobbe med disse virtuelle tabellene ved å bruke 1C. Mye oftere brukt Slice of the Last, så la oss begynne med det.

Et stykke av det siste lar deg få den siste registreringen av informasjonsregisteret for en spesifisert dato i forbindelse med målinger. For den siste (første) skivetabellen er det mulig å spesifisere to parametere i parentes, atskilt med komma. Den første parameteren inneholder datoen da skiven er laget (hvis parameteren ikke er spesifisert, lages skiven på gjeldende dato). Den andre parameteren er en betingelse i 1C-spørringsspråket og lar deg angi ulike valg. Som regel brukes mål i disse valgene. Alt dette høres ganske vagt ut, så det er umulig å gjøre uten et eksempel.
Så la oss ha et periodisk register over opplysninger Pris som lagrer priser etter produkt og leverandør. Hyppigheten av registeret er dag.

Registeret inneholder følgende oppføringer

Til å begynne med vil vi få et stykke av sistnevnte uten å bruke parametere ved å utføre følgende forespørsel:

VELG PriceSliceLast.Period AS Periode, PriceSliceLast.Product AS Produkt, PriceSliceLast.Supplier AS Leverandør, PriceSliceLast.Amount AS Amount FROM Register Information.Price.SliceLast AS PriceSliceLast

Siden parametrene ikke er spesifisert, utføres skiven på gjeldende dato - 02/01/2017. Som et resultat får vi følgende tabell

Her ser vi at kombinasjonen av dimensjoner Produkt + Leverandør er unik, d.v.s. For hver kombinasjon av registermålinger ble posten med maksimumsdato tatt, og registreringsdatoen er mindre enn eller lik gjeldende dato.

La oss si at vi må gjøre det samme, men vi ønsker å få poster med en dato mindre enn eller lik 15.01.2017. For å gjøre dette, må du endre raden med den siste skivetabellen i forespørselen som følger

FRA RegisterInformation.Price.SliceLast(&CutDate,) AS PriceSliceLast

Før du utfører forespørselen, må du selvfølgelig sende en parameter til den &Klippdato. Nå vil søkeresultatet se slik ut

Og til slutt, forestill deg at vi trenger å få et øyeblikksbilde av de siste for samme dato med forutsetning av at vi har varene Blyant, og leverandøren Skrivesaker. For å gjøre dette, spesifiser den andre parameteren i forespørselen

FRA RegisterInformation.Price.Last Cut(&CutDate, Product = &Product AND Supplier = &Supplier) AS PriceLast Cut

Som et resultat får vi kun én rekord

For å unngå å gå seg vill i alle disse parentesene og kommaene, er det bedre å bruke en spørringsbygger. Jeg skal vise deg å bruke den siste forespørselen som eksempel.

Etter å ha valgt en tabell med en del av de nyeste i spørringsdesigneren, må du klikke på knappen Virtuelle bordalternativer og skriv i vinduet som åpnes

Det er ikke vanskelig å gjette at for den første skiven er operasjonsprinsippet det samme, bortsett fra at den første posten etter kuttdatoen er valgt.

/
Gjennomføring av databehandling

Løsning av totaler for periodiske informasjonsregistre

Anvendelsesomfang: administrert applikasjon, mobilapplikasjon, vanlig applikasjon.

1.1. For periodiske informasjonsregistre anbefales det å tillate totaler dersom alle følgende betingelser er oppfylt:

• et stort datavolum forventes i registeret (for eksempel er det berettiget for et register med varepriser; men det gir ikke mening for et register med valutakurser);
• konfigurasjonen gir frekvensspørringer til stykker av sistnevnte på gjeldende tidspunkt og/eller stykker av førstnevnte for å få gjeldende data (dvs. når perioden ikke er spesifisert i parameterne til virtuelle tabeller Utsnitt av den første Og Slice of the Last);
• mens de gjenværende betingelsene for virtuelle tabeller Utsnitt av den første Og Slice of the Last er kun satt til måleverdier (og separatorer i modusen Selvstendig og i fellesskap);
• rbruker bare dimensjoner (og skilletegn som er i modus Selvstendig og i fellesskap).

For en fullstendig liste over alle forhold når forespørsler bruker informasjonsregistertotaler, sedokumentasjon for 1C:Enterprise-plattformen.

For eksempel hvis konfigurasjonen inkluderer ofte utførte spørringer til registeret PriserNomenklaturer for å få gjeldende varepriser:

Velg en. Artikkel AS Artikkel, Prisnomenklatur. Pris AS Pris,. . . FRA katalogen. Nomenklatur AS Nomenklatur VENSTRE TILKOBLING Informasjonsregister. PriserNomenklaturer. SliceLast(, PriceView = &Type priser) HVORDAN PriserNomenklaturer Programvarepriser Nomenklaturer. Nomenklatur = Nomenklatur. Link . . .

deretter, underlagt alle andre vilkår oppført ovenfor, innstilling av eiendommen Tillat totaler: del av de siste vil fremskynde utførelsen av slike forespørsler betydelig, på grunn av det faktum at valget vil bli utført direkte fra tilleggstabeller, som bare lagrer de siste verdiene (for å kutte de siste) og de første verdiene (for å kutte de siste) de første).

1.2. I tillegg bør det vurderes alternative alternativer for å revidere registerspørringene slik at disse betingelsene oppfylles.

For eksempel hvis i noen tilfeller dataene i registeret PriserNomenklaturer registreres på en fremtidig dato, og når du velger varer til dette registeret, blir det alltid utført en spørring for gjeldende dato (datoen er eksplisitt spesifisert i den virtuelle tabellparameteren Slice of the Last), vil ikke resultatene fremskynde utførelsen av slike søk. Siden totalene kun er bygget for den første og siste posten i registeret.

Men hvis du, når du åpner produktvalgskjemaet, analyserer om det er registrarer med en fremtidig dato, og hvis det ikke er noen, kjører du en annen spørring for en del av sistnevnte uten å angi datoen, vil en slik spørring fungere raskere .

2. I alle andre tilfeller bør det ikke tillates summeringer for periodiske informasjonsregistre. Først av alt, hvis

• oftest (alltid) forespørsler gjøres til de virtuelle tabellene i det første/siste periodiske registeret med informasjon for en bestemt periode (for eksempel for datoen for dokumentet).
• under forhold for virtuelle bord Utsnitt av den første Og Slice of the Last Oftest brukes (alltid) underspørringer og sammenføyninger (kaller "gjennom en prikk" til feltene til relaterte tabeller). For eksempel, i dette tilfellet:

3. Det er ikke nødvendig å tilveiebringe en egen mekanisme for å beregne totaler på nytt i konfigurasjonen, siden oppdateringen av totaltabellene utføres automatisk hver gang et sett med poster skrives til registeret.

I testkonfigurasjonen har vi et periodisk informasjonsregister "Nomenklaturpriser" med følgende innledende data:

Figuren viser også strukturen til registermetadataene. Som vi kan se, inneholder registeret «Produkt»-dimensjonen med referansetypen «Produkter», samt den numeriske ressursen «Pris» og «OldPrice»-attributtet.

La oss si at vi i en rapport trenger å få et stykke av de siste postene for produkter og deres priser med forutsetning av at den gamle prisen er mindre enn eller lik 50.

To forespørselsalternativer

Jeg vil si med en gang at vi vil vurdere de riktige og feil alternativene. La oss starte med sistnevnte. Dette er en feil som nybegynnere programmerere ofte gjør. Og derfor ble følgende forespørsel skrevet for rapporten:

Request = Ny forespørsel; Be om. Tekst = " VELG | | | | | FRA | Register over informasjon. PriserNomenklaturer. Utsnitt av det siste HVORDAN PriserNomenklatur Utsnitt av det siste|HVOR | PriserNomenklaturSliceSeneste. Gammel pris< = 50 " ;

Vær oppmerksom på tilstanden i "HVOR"-delen. Dette er hovedfeilen! Denne spørringen vil ikke returnere en enkelt post, og her er grunnen: når du bruker virtuelle tabeller, i vårt tilfelle "Last Slice", hentes data først fra databasen i henhold til betingelsene beskrevet i den virtuelle tabellen, og deretter handlingene beskrevet i spørringstekst utføres (grupperinger, betingelser i "HVOR"-delen, sortering osv.).

Derfor, i vårt eksempel, returnerer ikke forespørselen et resultat. Først mottar han en del av sistnevnte, og først deretter setter betingelsen på "Gamle pris"-attributtet. Slik ser det ut i diagrammet:

For å løse problemet riktig, må betingelsen for "Gamle pris"-attributtet overføres til betingelsene for den virtuelle tabellen. Slik vil den riktige forespørselsteksten se ut:

Request = Ny forespørsel; Be om. Tekst = " VELG PriserNomenklaturSliceSeneste. Periode, PriserNomenklaturSliceSeneste. Produkt, PriserNomenklaturSliceSeneste. Pris, PriserNomenklaturSliceSeneste. Gammel pris FRA Register over informasjon. PriserNomenklaturer. SliceLast(, OldPrice< = 50 ) HVORDAN PRISERNomenklaturSliceLatest"

Nå vil forespørselen motta de riktige dataene, siden en del av de siste prisene vil bli mottatt under hensyntagen til betingelsen for "OldPrice"-attributtet.

resultater

Det skal forstås at ovenstående gjelder for alle tilfeller av bruk av virtuelle tabeller i spørringer (for akkumuleringsregistre, regnskapsregistre, oppgaver osv.).

Dette innebærer også hovedregelen for bruk av virtuelle tabeller: "når du bruker en virtuell tabell, sørg for å sette utvalgsparameterne direkte i den virtuelle tabellen, ellers vil spørringen motta unødvendige data, som deretter vil bli brukt til valg."