hjem Instagram

1c virtuelle tabellbalanser og omsetning. Spørr batch-fanen

Jeg bestemte meg for å gi mitt bidrag og beskrive de funksjonene ved språket som ikke ble diskutert i artiklene ovenfor. Artikkelen er rettet mot nybegynnere.

1. "IZ" design.

For å hente data fra databasen er det slett ikke nødvendig å bruke "FROM"-konstruksjonen.
Eksempel: Vi må velge all informasjon om banker fra bankkatalogen.
Be om:

SELECT Directory.Banks.*

Velger alle felt fra bankkatalogen. Og ligner på forespørselen:

VELG Banker.* FRA Directory.Banks AS Banker

2. Bestilling av data etter referansefelt

Når vi trenger å organisere spørringsdata etter primitive typer: "String", "Number", "Date", etc., så løses alt ved å bruke "ORDER BY"-konstruksjonen hvis du trenger å bestille dataene etter et referansefelt? Referansefeltet er en lenke, en unik identifikator, dvs. Grovt sett kan et vilkårlig sett med tegn og vanlig rekkefølge gi et resultat som ikke er helt forventet. For å bestille referansefelt brukes konstruksjonen "AUTO BESTILLING". For å gjøre dette må du først bestille dataene direkte etter referansetypen ved å bruke "ORDER BY"-konstruksjonen, og deretter "AUTO ORDER"-konstruksjonen.

I dette tilfellet, for dokumenter, vil bestillingen skje i rekkefølgen "Dato->Nummer", for oppslagsverk i "Hovedvisning". Hvis bestillingen ikke skjer etter referansefelt, anbefales det ikke å bruke konstruksjonen "AUTO BESTILLING".

I noen tilfeller kan "AUTO BESTILLING"-konstruksjonen bremse utvelgelsesprosessen. På samme måte kan du skrive om uten automatisk bestilling av dokumenter:

3.Få en tekstrepresentasjon av en referansetype. "PRESENTASJON" design.

Når du trenger å vise et felt av en referansetype, for eksempel "Bank"-feltet, som er en lenke til et element i "Banks"-katalogen, må du forstå at når du viser dette feltet, vil en underspørring til " Banks"-katalogen vil bli utført automatisk for å få en visning av katalogen. Dette vil redusere datautgangen. For å unngå dette, må du bruke "PREPRESENTATION"-konstruksjonen i forespørselen for umiddelbart å få en representasjon av objektet og deretter vise det for visning.

I datasammensetningssystemet brukes denne mekanismen som standard, men når du lager oppsett i celler, bør du spesifisere representasjonen av referansefeltet, og for eksempel plassere selve lenken i transkripsjonen.

4. Betingelse for prøvetaking av data etter mal.

For eksempel må du få mobiltelefoner til ansatte på skjemaet (8 -123- 456-78-912). For å gjøre dette må du angi følgende betingelse i forespørselen:

VELG Employee.Name, Employee.Phone AS Phone FROM Directory.Employees AS Employees WHERE Phone LIKE "_-___-___-__-__"

Tegnet "_" er et tjenestetegn og erstatter et hvilket som helst tegn.

5. Samtidig bruk av totaler og grupperinger.

Totaler brukes ofte i forbindelse med grupperinger; i dette tilfellet kan det hende at aggregerte funksjoner ikke spesifiseres i totalene.

SELECT Provision of Services.Organization AS Organization, Provision of Services.Nomenclature AS Nomenclature, SUM(Provision of Services.Amount of Document) AS Sum of Document FROM Document.Provision of Services AS Provision of Services GROUP BY Provision of Services.Organisation, Provision av tjenester.Nomenklatur RESULTATER AV GENERELT, Organisasjon, Nomen klatura

I dette tilfellet vil spørringen returnere nesten det samme som følgende spørring:

SELECT Provision of Services.Organization AS Organisation, Provision of Services.Nomenclature AS Nomenclature, Provision of Services.Amount of Document AS Amount of Document FROM Document.Provision of Services AS Provision of Services RESULTATES MOUNT (Amount of Document) BY GENERAL, Organisation, Nomenklatur

Bare den første spørringen vil skjule poster med samme nomenklatur.

6. Frareferansefelt.

Å referere til felt gjennom en prikk kallesen. For eksempel Betaling.Organisasjon.Administrativ enhet. I dette tilfellet, i referansefeltet "Organisasjon" i "Betaling"-dokumentet, refererer det til en annen tabell "Organisasjoner", der verdien av attributtet "Administrativ enhet" vil bli oppnådd. Det er viktig å forstå at når du får tilgang til felt gjennom en prikk, oppretter plattformen implisitt en underspørring og kobler sammen disse tabellene.

Be om:

Kan representeres som:

VELG Payment.Link, Payment.Organization, Payment.Organization, Organisations. AdministrativeUnit FROM Document.Payment AS Payment LEFT JOIN Directory.Organizations AS Software Organizations Payment.Organization = Organisations.Link

Når du refererer til referansefelt av en sammensatt type, forsøker rammeverket å lage implisitte sammenføyninger til alle tabeller som er en del av feltets type. I dette tilfellet vil ikke spørringen være optimal Hvis det er klart kjent hvilken type felt det er, er det nødvendig å begrense slike felt etter type med en konstruksjon UTTRYKKE().

For eksempel er det et akkumuleringsregister "Ufordelte betalinger", der flere dokumenter kan fungere som registrar. I dette tilfellet er det feil å innhente verdiene til registrardetaljene på denne måten:

VELG UnallocatedPayments.Register.Date, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

du bør begrense typen av det sammensatte feltet til logger:

VELG EXPRESS(UnallocatedPayments.Register AS Document.Payment).Dato, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

7. Konstruksjon "HVOR"

Med en venstre sammenføyning av to tabeller, når du pålegger en "WHERE"-betingelse på den høyre tabellen, vil vi få et resultat som ligner resultatet med en indre sammenføyning av tabeller.

Eksempel. Det er nødvendig å velge alle klienter fra klientkatalogen og for de klienter som har et betalingsdokument med verdien av attributtet "Organisasjon" = &Organisasjon, vis dokumentet "Betaling", for de som ikke har det, ikke vis det.

Resultatet av spørringen vil returnere poster bare for de klientene som hadde betaling per organisasjon i parameteren, og vil filtrere ut andre klienter. Derfor må du først motta alle betalinger for "slik og slik" organisasjon i en midlertidig tabell, og deretter koble den til "Kunder"-katalogen ved å bruke en venstre sammenføyning.

VELG Payment.Link AS Payment, Payment.Shareholder AS Client PLASS toPayments FROM Document.Payment AS Payment WHERE Payment.Branch = &Branch; ////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(tPayment.Payment, "") AS Betaling FRA Directory .Clients AS Klienter VENSTRE FORBINDELSE topayments SOM topayments SOFTWARE Clients.Link = topayments.Client

Du kan komme deg rundt denne tilstanden på en annen måte. Det er nødvendig å pålegge en "WHERE"-betingelse direkte på forholdet mellom de to tabellene. Eksempel:

VELG Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers VENSTRE CONNECTION Document.Payment AS Payment Software (Clients.Link = Payment.Client AND Payment.Client.Name LIKE "Sugar Packet") GRUPPE ETTER Clients.Link, Payment. Link

8. Blir med nestede og virtuelle tabeller

Nestede søk ofte nødvendig for å hente data basert på en eller annen tilstand. Hvis du deretter bruker dem sammen med andre tabeller, kan dette redusere utførelsen av spørringen kritisk.

For eksempel må vi få saldobeløpet per gjeldende dato for noen klienter.

SELECT UnallocatedPaymentsRemains.Customer, UnallocatedPaymentsRemains.AmountRemaining FROM (SELECT Clients.Link AS Link FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Clients)) AS NestedQuery LEFT JOIN RegisterAccumulations.UnallocatedPayments.UnallocatedPayments.UnallocatedPayments. ymentsBalanser. Kunde

Når du utfører en slik spørring, kan DBMS-optimalisatoren gjøre feil når du velger en plan, noe som vil føre til suboptimal utførelse av spørringen. Når du kobler sammen to tabeller, velger DBMS-optimalisatoren en tabellsammenføyningsalgoritme basert på antall poster i begge tabellene. Hvis det er en nestet spørring, er det ekstremt vanskelig å bestemme antall poster som den nestede spørringen vil returnere. Derfor bør du alltid bruke midlertidige tabeller i stedet for nestede spørringer. Så la oss omskrive forespørselen.

SELECT Clients.Link AS Link PLASS tClients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&Clients) ; ////////////////////////////////////////////// //////////////////////////////////// VELG tClients.Link, UnallocatedPaymentsRemains.AmountRemaining, FROM tClients AS tClients LEFT JOIN RegisterAccuulations.UnallocatedPayments.Balances (, Client) IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

I dette tilfellet vil optimizeren kunne bestemme hvor mange poster den midlertidige tabellen tClients bruker og vil kunne velge den optimale algoritmen for å slå sammen tabeller.

Virtuelle bord , lar deg få praktisk talt ferdige data for de fleste brukte oppgaver (Slice of the First, Slice of the Last, Remains, Turnovers, Remains og Turnovers) Nøkkelordet her er virtuelt. Disse tabellene er ikke fysiske, men kompileres av systemet på farten, dvs. Ved mottak av data fra virtuelle tabeller, samler systemet inn data fra de endelige registertabellene, monterer, grupperer og sender det til brukeren.

De. Når du kobler til en virtuell tabell, opprettes en tilkobling til en underspørring. I dette tilfellet kan DBMS-optimalisatoren også velge en ikke-optimal tilkoblingsplan. Hvis spørringen ikke genereres raskt nok og spørringen bruker sammenføyninger i virtuelle tabeller, anbefales det å flytte tilgangen til de virtuelle tabellene til en midlertidig tabell, og deretter lage en sammenføyning mellom to midlertidige tabeller. La oss skrive om den forrige forespørselen.

VELG Clients.Link AS Link PLASSER tClients FROM Directory.Clients AS Clients INDEKS BY Link HVOR
Clients.Link B (&Clients) ; ////////////////////////////////////////////// ///////////////////////////// SELECT ULLOSATEDPAYMENTS.AmountBalance, UnfordelPayments.Client as Client Place Balances from RegisterAccumulations.unallocatedPayments.Balances (, klient B ( SELECT tClients. Link FROM tClients)) AS UnallocatedPaymentsBalances; ////////////////////////////////////////////// ////////////////////////// SELECT tClients.Link, toRemainders.AmountRemaining AS AmountRemaining FROM tClients AS tClients VENSTRE JOIN toRemainders AS Remainders BY tClients.Link = tRemainings.Client

9.Sjekker resultatet av forespørselen.

Resultatet av spørringen kan være tomt; for å se etter tomme verdier, bruk følgende konstruksjon:

ResRequest = Request.Execute(); Hvis resQuery.Empty() Returner deretter; slutt om;

Metode Tømme() bør brukes før metoder Velge() eller Lesse(), siden det tar tid å hente samlingen.

Det er ikke en åpenbaring for noen at det er ekstremt uønsket å bruke spørringer i en loop. Dette kan kritisk påvirke driftstiden til en bestemt funksjon. Det er svært ønskelig å motta alle dataene i forespørselen og deretter behandle dataene i en loop. Men noen ganger er det tilfeller der det blir umulig å flytte forespørselen utenfor loopen. I dette tilfellet, for optimalisering, kan du flytte opprettelsen av spørringen utenfor loopen, og i loopen erstatte de nødvendige parameterne og utføre spørringen.

Dette vil spare systemet fra syntakskontroll av forespørselen i en løkke.

11. Konstruksjon "HAVING".

Et design som er ganske sjelden i forespørsler. Lar deg pålegge betingelser for verdiene til aggregerte funksjoner (SUM, MINIMUM, AVERAGE, etc.). For eksempel må du bare velge de kundene hvis betalingsbeløp i september var mer enn 13 000 rubler. Hvis du bruker «WHERE»-betingelsen, må du først opprette en midlertidig tabell eller en nestet spørring, gruppere poster der etter betalingsbeløp og deretter bruke betingelsen. "HAVING"-konstruksjonen vil bidra til å unngå dette.

VELG Betaling.Kunde, BELØP(Betaling.Beløp) SOM Beløp FRA Dokument.Betaling SOM Betaling HVOR MÅNED(Betalingsdato) = 9 GRUPPER ETTER Betaling.Kunde HAR BELØP(Betal.Beløp) > 13000

I konstruktøren, for å gjøre dette, går du bare til fanen "Betingelser", legg til en ny tilstand og merker av for "Egendefinert". Så er det bare å skrive Beløp (Betaling.Beløp) > 13000

12. NULL-verdi

Jeg vil ikke her beskrive prinsippene for logikk med tre verdier i databasen; det er mange artikler om dette emnet. Bare kort om hvordan NULL kan påvirke resultatet av spørringen. Verdien NULL er egentlig ikke en verdi, og det faktum at verdien er udefinert er ukjent. Derfor returnerer enhver operasjon med NULL NULL, enten det er addisjon, subtraksjon, divisjon eller sammenligning. En NULL-verdi kan ikke sammenlignes med en NULL-verdi fordi vi ikke vet hva vi skal sammenligne. De. begge disse sammenligningene er: NULL = NULL, NULL<>NULL er ikke sant eller usant, det er ukjent.

La oss se på et eksempel.

For de kundene som ikke har betalinger, må vi vise "Sign"-feltet med verdien "Ingen betalinger". Dessuten vet vi med sikkerhet at vi har slike kunder. Og for å gjenspeile essensen av det jeg skrev ovenfor, la oss gjøre det på denne måten.

VELG "Ingen betalinger" AS Attributt, NULL AS Document PLACE topbetalinger; ////////////////////////////////////////////// //////////////////////////// select clients.link as client, betaling.link hvordan betaling setter tclientpayment fra katalog.clients som klienter forlot tilkoblingsdokumentet. Payment AS Payment Software Clients.Link = Payment.Shareholder; ////////////////////////////////////////////// ///////////////////////////// Select tclientPayment.client from tclientPayment as tclientPayment Internal join tpayment as ttopay by tclientpayment.payment = tpayment.

Vær oppmerksom på den andre midlertidige tabellen tClientPayment. Med venstre join velger jeg alle klienter og alle betalinger for disse klientene. For de kundene som ikke har betalinger, vil "Betaling"-feltet være NULL. Etter logikken, i den første midlertidige tabellen "tPayments" utpekte jeg 2 felt, ett av dem NULL, den andre linjen "Har ikke betalinger". I den tredje tabellen kobler jeg sammen tabellene "tClientPayment" og "tPayment" ved å bruke feltene "Payment" og "Document" med en intern sammenføyning. Vi vet at i den første tabellen er «Dokument»-feltet NULL, og i den andre tabellen er de som ikke har betalinger i «Betaling»-feltet også NULL. Hva vil en slik forbindelse returnere til oss? Men det vil ikke returnere noe. Fordi sammenligningen NULL = NULL ikke evalueres til True.

For at forespørselen skal returnere det forventede resultatet, la oss skrive det om:

VELG "Ingen betalinger" AS Attribut, VALUE(Document.Payment.EmptyLink) AS Document PLACE toPayments; ////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(Payment.Link, VALUE(Document.Payment.EmptyLink )) HVORDAN Betaling PUT tClientPayment FROM Directory.Clients AS Clients LEFT CONNECTION Document.Payment AS Payment BY Clients.Link = Payment.Shareholder; ////////////////////////////////////////////// ///////////////////////////// Select tclientPayment.client from tclientPayment as tclientPayment Internal join tpayment as ttopay by tclientpayment.payment = tpayment.

Nå, i den andre midlertidige tabellen, har vi indikert at hvis "Betaling"-feltet er NULL, så er dette feltet en tom lenke til betalingsdokumentet. I den første tabellen erstattet vi også NULL med en tom referanse. Nå involverer tilkoblingen ikke-NULL-felt og forespørselen vil returnere det forventede resultatet.

Alle forespørsler i artikkelen gjenspeiler situasjonene jeg ønsker å vurdere og ingenting mer. OM De er kanskje ikke vrangforestillinger eller suboptimale, det viktigste er at de gjenspeiler essensen i eksemplet.

13. Et udokumentert trekk ved "CHOICE WHEN...THEN...END"-designet.

I tilfelle det er nødvendig å beskrive "Betingelser"-konstruksjonen i forespørselen, bruker vi standardsyntaksen:

VELG UTVALG NÅR Users.Name = "Vasya Pupkin" SÅ "Vår favorittansatt" ELSE "Vi vet ikke dette" END AS Field1 FROM Directory.Users AS Users

Men hva om vi for eksempel trenger å få månedens navn i en forespørsel? Å skrive en stor konstruksjon i en forespørsel er stygg og tidkrevende, så denne formen for skriving ovenfor kan hjelpe oss:

SELECT MONTH(US_CalculationConsumption_ScheduleTurnover.CalculationPeriod) NÅR 1 SÅ "Januar" NÅR 2 SÅ "FEBRUAR" NÅR 3. SÅ "MARS" NÅR 4. SÅ "April" NÅR 5. SÅ "6. mai" DEN 7 JUNI" NÅR "JUNI" NÅR 8. SÅ "August" NÅR 9. SÅ "September" NÅR 10. SÅ "Oktober" NÅR 11. SÅ "NOR" NÅR 12. SÅ SLUTTER "DESEMBER" SOM EN MÅNED

Nå ser designet mindre tungvint ut og er lett å forstå.

14. Batch-utførelse av spørringer.

For ikke å multiplisere forespørsler kan du lage én stor forespørsel, dele den opp i pakker og jobbe med den.
For eksempel må jeg hente følgende felt fra "Brukere"-katalogen: "Fødselsdato" og de tilgjengelige rollene for hver bruker. last opp dette til ulike tabelldeler på skjemaet. Selvfølgelig kan du gjøre dette i én forespørsel, så må du iterere gjennom postene eller skjule dem, eller du kan gjøre dette:

SELECT Users.Link AS Fullt navn, Users.Fødselsdato, Users.Role PUT vtUsers FROM Directory.Users AS Users; ////////////////////////////////////////////// ////////////////////////// SELECT tueUsers.Full navn, tueUsers.Fødselsdato FROM tueUsers AS tueUsers GROUP BY tueUsers.fullt navn, tueUsers . Fødselsdato; ////////////////////////////////////////////// ///////////////////////// SELECT wUsers.Full Name, wUsers.Role FROM wUsers AS wUsers GROUP BY wUsers.Full Name, wUsers. Dato for Fødsel

tPackage = Request.ExecutePackage();

TP_BirthDate = tPackage.Upload();
TP_Roles = tPackage.Unload();

Som vi kan se, kan spørringen utføres i en batch og resultatet kan behandles som en matrise. I noen tilfeller er det veldig praktisk.

15. Betingelser i en batchforespørsel

For eksempel har vi en batchforespørsel, hvor vi først får feltene: «Navn, Fødselsdato, Kode» fra «Brukere»-katalogen og ønsker å hente poster med betingelser for disse feltene fra «Individualer»-katalogen.

SELECT Users.Individual.Name AS Name, Users.Individual.Date of Birth AS Fødselsdato, Users.Individual.Code AS Kode PLASS vtUsers FRA Directory.Users AS Users; ////////////////////////////////////////////// ///////////////////////////// Select.

Du kan stille vilkår som dette:

WHERE Individuals.Code IN (SELECT vtUsers.Code FROM vtUsers) OG Individuals.Name IN (SELECT vtUsers.Code FROM vtUsers) OG Individuals.BirthDate IN (SELECT vtUsers.DateBirth FROM tvUsers)

Og du kan gjøre det slik:

HVOR (Individuals.Code, Individuals.Name, Individuals.Date of Birth) IN (VELG tueUsers.Code, tueUsers.Name, tueUsers.Dato of Birth FROM tueUsers)

Dessuten er det nødvendig å opprettholde orden.

16. Ringe spørringsbyggeren for "tilstand" i en batchforespørsel

Når det er nødvendig å pålegge en betingelse, som i eksemplet ovenfor, kan du glemme hvordan dette eller det feltet kalles i den virtuelle tabellen.
For eksempel må du pålegge en betingelse i "Fødselsdato"-feltet, og i den virtuelle tabellen kalles dette feltet "Debitors fødselsdato", og hvis du glemmer navnet, må du avslutte redigering av betingelsen uten lagre og se på navnet på feltet. For å unngå dette kan du bruke følgende teknikk.

Det er nødvendig å sette parenteser etter konstruksjon "B" og la et tomt mellomrom (mellomrom) mellom parentesene, velg denne plassen og kall opp spørringskonstruktøren. Designeren vil ha tilgang til alle tabellene i batch-spørringen. Teknikken fungerer både på virtuelle registertabeller og på fanen "Betingelser". I sistnevnte tilfelle må du sjekke "P (vilkårlig tilstand)"-boksen og gå inn i redigeringsmodusen "F4".

Forespørslene ble ofte gjort på flukt, og de tjener ganske enkelt til å illustrere "teknikkene" jeg vurderte.

Jeg ønsket å se på bruken av indekser i spørringer, men dette er et veldig bredt tema. Jeg legger det inn i en egen artikkel, eller legger det til her senere.

oppd1. Poeng 11,12
oppd2. Poeng 13,14,15,16

Brukte bøker:
Spørrespråk "1C:Enterprise 8" - E.Yu. Khrustaleva
Faglig utvikling i 1C:Enterprise 8-systemet."

Ved organisering av prøver i reelle problemer er datautvalget i de aller fleste tilfeller organisert i henhold til visse kriterier.

I tilfelle når utvalget er gjort fra et ekte bord, oppstår det ingen vanskeligheter. Dataene behandles helt trivielt:

I tilfellet når kilden i spørringen er en virtuell tabell, blir situasjonen noe mer komplisert.

Spørringsspråket lar deg pålegge en betingelse for et utvalg fra virtuelle tabeller på to måter: i WHERE-leddet og ved å bruke virtuelle tabellparametere. Begge metodene vil føre til samme resultat (med unntak av noen spesifikke tilfeller), men likevel er de langt fra likeverdige.

Vi vet allerede at virtuelle tabeller kalles virtuelle fordi de faktisk ikke er i databasen. De dannes bare i det øyeblikket en forespørsel sendes til dem. Til tross for dette er det praktisk for oss (det vil si de som skriver spørringen) å betrakte virtuelle tabeller som ekte. Hva vil skje i 1C Enterprise 8-systemet når spørringen vi kompilerte fortsatt får tilgang til den virtuelle tabellen?

I det første trinnet vil systemet bygge en virtuell tabell. I det andre trinnet vil poster bli valgt fra den resulterende tabellen som tilfredsstiller betingelsen spesifisert i WHERE-leddet:
Det er tydelig at den endelige prøven ikke vil inkludere alle poster fra den virtuelle tabellen (og derfor fra databasen), men bare de som tilfredsstiller den gitte betingelsen. Og de resterende postene vil ganske enkelt bli ekskludert fra resultatet.

Dermed vil systemet ikke bare gjøre ubrukelig arbeid, men dobbelt ubrukelig arbeid! Først skal det brukes ressurser på å bygge en virtuell tabell basert på unødvendige data (i figuren er de markert som «dataområde A og B»), og deretter skal det jobbes med å filtrere disse dataene fra sluttresultatet.

Ved å parameterisere en virtuell tabell, begrenser vi umiddelbart mengden data som vil bli behandlet av spørringen.

Hva er forskjellen mellom verdiene til den virtuelle tabellparameteren "Addition Method"?
Når tilleggsmetoden er satt til "bevegelser", vil bare de periodene det var bevegelser i returneres. Når "Movements and Period Boundaries" er satt, vil 2 poster bli lagt til bevegelsene ovenfor: bevegelser ved begynnelsen og slutten av perioden spesifisert i VT-parameterne. "Registrar"-feltet vil være tomt for disse 2 postene.

Informasjon hentet fra siden

Ved organisering av prøver i reelle problemer er datautvalget i de aller fleste tilfeller organisert i henhold til visse kriterier.

I tilfelle når utvalget er gjort fra et ekte bord, oppstår det ingen vanskeligheter. Dataene behandles helt trivielt:

I tilfellet når kilden i spørringen er en virtuell tabell, blir situasjonen noe mer komplisert.

I det første trinnet vil systemet bygge en virtuell tabell. I det andre trinnet vil poster bli valgt fra den resulterende tabellen som tilfredsstiller betingelsen spesifisert i WHERE-leddet:

Det er tydelig at den endelige prøven ikke vil inkludere alle poster fra den virtuelle tabellen (og derfor fra databasen), men bare de som tilfredsstiller den gitte betingelsen. Og de resterende postene vil ganske enkelt bli ekskludert fra resultatet.

Er det mulig å umiddelbart slutte å bruke unødvendige data på stadiet med å konstruere en virtuell tabell? Det viser seg at det er mulig. Dette er nøyaktig hva de virtuelle tabellparametrene er designet for:

Ved å parameterisere en virtuell tabell, begrenser vi umiddelbart mengden data som vil bli behandlet av spørringen.

La oss kalle opp dialogen for å angi parametere for den virtuelle PriceSliceLast-tabellen og indikere at perioden vil bli passert i parameteren ReportDate. For å gjøre dette, velg denne tabellen i tabelllisten og klikk på knappen Virtuelle tabellalternativer. Velg deretter følgende felt fra tabellene:

SprNomenklatur. Forelder,

PriserSlutt av siste.Pris.

Venstre bord bli med

- På bokmerket Tilkoblinger: i feltet Koblingsbetingelse, at verdien av Nomenklaturdimensjonen til informasjonsregisteret må være lik referansen til Nomenklaturkatalogelementet. Og fjern også merket for Alle avkrysningsboksen for registertabellen og merk av for oppslagstabellen, og angir dermed tilkoblingstypen som venstre tilkobling for oppslagstabellen:

Ris. 13.15. Forholdet mellom tabeller i en spørring

- På bokmerket Forhold la oss angi betingelsen for å velge elementer fra nomenklaturkatalogen - de valgte elementene må samsvare med typen nomenklatur som er sendt i forespørselsparameteren for nomenklaturtype:

Ris. 13.16. Vilkår for valg av elementer

- På bokmerket Fagforeninger/aliaser: spesifiser aliaset til feltet Parent = Service Group, og feltet Link = Service. - Klikk OK-

Etter dette må du redigere datalayoutskjemaet, for å gjøre dette på fanen Ressurser, klikk på knappen Legg til og velg en ressurs - Pris

- På bokmerket Alternativer angi verdien for parameteren Nomenclature Type - Enumeration.Nomenclature Types.Service. I tillegg fjerner vi tilgjengelighetsbegrensningen for ReportDate-parameteren. I Type of this parameter-feltet angir du sammensetningen av datoen - Dato. For Periode-parameteren setter vi tvert imot en tilgjengelighetsbegrensning:

Ris. 13.17. Alternativer for oppsettskjema

Innstillinger

- La oss gå til bokmerket Innstillinger: La oss lage en gruppering basert på Tjenestegruppe-feltet, og spesifisere grupperingstypen Hierarki.

Følgende hierarkityper finnes for rapportgrupperinger: Uten hierarki - kun ikke-hierarkiske poster vises i grupperingen. Hierarki – både ikke-hierarkiske og hierarkiske poster vises i grupperingen. Kun hierarki - bare hierarkiske (overordnede) poster vises i grupperingen. Inne i denne gruppen vil vi opprette en annen, uten å spesifisere gruppefeltet. På underfanen Valgte felt: spesifiser utdatafeltene Service og Price:

Ris. 13.18. Rapportstruktur og felt

På underfanen Annen innstillinger vil vi utføre følgende trinn:

Ris. 13.19. Innstillinger for visning av generelle totaler for "Service Group"-grupperingen

Ris. 13.20. Sette opp og vise resultater for en global rapport

Til slutt, la oss inkludere Rapportdato-parameteren i brukerinnstillingene og sette redigeringsmodusen til Rask tilgang. La oss lukke daog i vinduet for redigering av List of Services-objektet går du til fanen Subsystems. I listen over konfigurasjonsdelsystemer, legg merke til tjenestelevering og regnskapsundersystemer.

I 1C: Enterprise-modus

La oss starte 1C:Enterprise i feilsøkingsmodus og først av alt åpne det periodiske registeret Priser. Så skal vi teste rapporten.

Ved å bruke denne rapporten som eksempel, studerte vi hvordan datasammensetningssystemet henter de siste verdiene fra det periodiske informasjonsregisteret og hvordan grupperinger i henhold til kataloghierarkiet vises.

Hvis publikasjonen min er nyttig for deg, ikke glem å gi den et pluss :-)

Her er en rubrikator for alle oppgaver i samlingen(en side som inneholder lenker til forumtråder for hver oppgave)
http://chistov.spb.ru/forum/16-969-1

Vel, nå mine utviklinger og notater som jeg opprettet under forberedelsesprosessen.
Jeg skal prøve å gjenta så lite som mulig med de to nevnt ovenfor siste publikasjoner.

Så la oss komme i gang:

Hvis du tar det eksternt, bør du ha to objekter på skrivebordet på slutten av eksamen:

1. Endelig opplasting av informasjonsbasen (dt-fil)
2. Forklaring

Det skal ikke være noe annet, ingen mellomkopier osv.

Husk å skrive et forklarende notat!
Ved en vagt formulert oppgave, sørg for å skrive der at du har valgt akkurat et slikt og slikt løsningsalternativ.
Også på sentrale steder i koden er det bedre å legge igjen korte kommentarer, uten fanatisme, men der sensoren kan ha spørsmål, er det bedre å skrive.

Men du vil bli fortalt om dette i instruksjonene som du vil få lese før eksamen.
Det er bare bedre å vite på forhånd)

Bruke og-tegnet i spørringer.

Noen ganger er det raskere å skrive fra et ekstra tastatur enn å bytte layout frem og tilbake, noe som sparer tid
& = Alt+38

*************************************************************************************************
Bruk av TimePoint() i spørringer

I forespørsler til akkumulerings- og regnskapsregistre er det nødvendig å ikke bruke dokumentdatoen som en virtuell tabell (periode), men Moment-parameteren, som er definert i koden som følger:

Moment = ?(Passeringsmodus = Dokumentposteringsmodus. Operasjonell, Udefinert, Tidspunkt());

*************************************************************************************************
Når du genererer dokumentbevegelser etter register, helt i begynnelsen av konteringsbehandlingsprosedyren, er det nødvendig å slette bevegelsene til gjeldende dokument for register.

Koden er:

Movement.RegisterName.Write = Sant; Movements.RegisterName.Clear();

Det er mulig at det i løpet av prosessen vil være nødvendig å analysere poster fra dette registeret.
Så, slik at når du analyserer de nåværende postene (gamle, før dokumentet ble endret) de definitivt ikke er inkludert i prøven, kan du legge til en linje til i de to ovennevnte linjene:

Movement.RegisterName.Write();

Eller, når du analyserer poster, angi eksplisitt en grense som ikke inkluderer tidspunktet for gjeldende dokument.

Men overalt indikerte jeg ganske enkelt konstruksjonen av disse tre linjene:

Movement.RegisterName.Write = Sant; Movements.RegisterName.Clear(); Movement.RegisterName.Write();

*************************************************************************************************
Det er to måter å blokkere data på, valget mellom dem avhenger av metoden som brukes - gammel eller ny:

1) Regelmessig kontrollert blokkering, gammel metode for dokumentbehandling (Data Blocking-objekt)

Angi om saldo først kontrolleres og deretter avskrives.
I tilfellet når vi må ha litt informasjon fra registeret for å danne en bevegelse.

Eksempel:

I dokumentet - mengde, i registeret - mengde og beløp (kostnad)
Så vi vet mengden varer fra dokumentet - hvor mye vi avskriver, men kostnadene - ikke.
Vi kan bare finne det ut fra registeret, men for å sikre at ingen endrer registeret mellom mottak av saldoene og tidspunktet for registrering av bevegelsene, må vi låse registeret selv før vi leser saldoene.
Så i dette tilfellet brukes Data Locking-objektet. Og når du oppretter det, er det mer riktig å indikere med hvilke dimensjoner vi blokkerer registeret (for eksempel i vårt tilfelle - bare av varen spesifisert i dokumentet) - slik at det ikke er unødvendige låser og en annen bruker kan selge en annen punkt.

1. Sett en lås ved hjelp av Data Lock-objektet
2. Les resten
3. Vi sjekker muligheten for avskrivning
4. Vi lager bevegelser, for eksempel avskriver varer
5. Etter bokføring av dokumentet fjernes sperringen automatisk (sperringen er gyldig som en del av konteringstransaksjonen og fjernes automatisk av systemet). Det vil si at det ikke er nødvendig å låse opp objektet spesielt.

2) Ny metodikk for behandling av dokumenter (ved å bruke LockForChange-egenskapen = True)

Den brukes dersom vi ikke trenger informasjon fra registrene for å danne bevegelser, og vi kan sjekke om vi har gått i minus ved avskrivning dersom vi etter registrering ser på saldoene i registeret og ser at det er negative. . I dette tilfellet vil vi forstå at vi har avskrevet for mye og vil avbryte avskrivningsoperasjonen.

Eksempel:
La oss vurdere driften av å selge et produkt.
I dokumentet - mengde, i registeret - kun mengde
Så vi vet mengden varer fra dokumentet.
Vi danner bevegelser med mengden spesifisert i dokumentet og registrerer dem. Deretter leser vi registeret, ser på saldoene og analyserer om det er noen negative. Hvis det er det, vis en feil og sett Refusal = True.

Det vil si at sekvensen er slik:
1. For å gå gjennom registeret, sett BlockForChange-egenskapen = True
2. Vi lager bevegelser - avskriv varene
3. Registrer bevegelsene
4. Les registeret og sørg for at det ikke er negative saldoer. Hvis det er det, så skrev de av det overskytende, hvis ikke, så er alt i orden.

Så i dette tilfellet er det ikke nødvendig å indikere med hvilke dimensjoner vi trenger å blokkere registeret.
Vi setter ganske enkelt BlockForChange-egenskapen til True før vi registrerer bevegelsene våre, danner bevegelsene og registrerer.
Selve systemet vil blokkere registeret ved registreringen i henhold til de målingene som trengs, etter å ha analysert det vi har registrert.
Når den er fullført, vil blokkeringen bli fjernet.

Dette alternativet (det andre) er enklere, det kalles den "nye metoden for behandling av dokumenter" og 1C anbefaler å bruke det hvis mulig og trekker poeng hvis det første alternativet brukes, men i noen tilfeller kan det ganske enkelt ikke brukes og det første alternativet med Data Locking-objektet brukes (se eksempel ovenfor).

Jeg legger også merke til at uavhengig av valgt metode, må bevegelsene rengjøres før du arbeider med dem (se tidligere råd)

*************************************************************************************************
Datablokkering (blokkeringsmetode nr. 1 fra beskrivelsen ovenfor)

Det kreves kontrollert låsing der data leses og bevegelser gjøres basert på disse dataene
Den raskeste måten å få tak i den administrerte låsekoden på er å skrive inn "Datalåsing", ringe Syntax Assistant og ganske enkelt kopiere eksempelkoden derfra. Deretter endrer du det bare til navnet på registeret og dimensjonene.

Det ser omtrent slik ut:

Lås = NewDataLock; Låseelement = Locking.Add("Akkumuleringsregister.GoodsInWarehouses"); LockElement.Mode = DataLockMode.Exclusive; BlockingElement.DataSource = PM; Locking Element.UseFromDataSource("Nomenklatur", "Nomenklatur"); Lås.Lås();

*************************************************************************************************
Det er bedre å kalle den tabellformede delen av dokumentene ganske enkelt "TC"

Det er bare én tabelldel i 99 % av dokumentene. Et slikt enhetlig navn for tabelldeler vil i stor grad bidra til å spare tid, siden:
1) Veldig kort – skriv raskt
2) Det samme for alle dokumenter, du trenger ikke huske hva det heter når du skriver kode

*************************************************************************************************
Søkeresultatet bør kontrolleres for tomhet før det hentes eller lastes opp til den tekniske spesifikasjonen.

Generelt brukte jeg prøvetaking i alle oppgaver.

Sampling er mer optimalt for systemet når det gjelder ytelse, siden det er "skjerpet" kun for lesing av data (i motsetning til TK).

Men i alle fall, før Select()-metoden, er det bedre å sjekke søkeresultatet for tomhet, dette vil ytterligere redusere belastningen på systemet.

Resultat = Query.Run(); Hvis ikke Result.Empty() Then Select = Result.Select(TravelQueryResult.ByGrouping); ... Slutt om;

Og i tilfelle vi bare trenger å få én verdi fra forespørselen
(for eksempel kun avskrivningsmetoden i samsvar med regnskapsprinsippene fastsatt for dette året):

Resultat = Query.Run(); Hvis ikke Result.Empty() Then Select = Result.Select(); Utvalg.Neste(); Kostnadsavskrivningsmetode = Sample.Cost Write-Off Method; slutt om;

*************************************************************************************************
Dokument "Drift" for en regnskapsoppgave

Det er nødvendig å opprette et driftsdokument for regnskapsoppgaver.

Vi deaktiverer kontering for den helt (i egenskapene «Kontering = Avslå»), indikerer at den gjør bevegelser i regnskapsregisteret, og drar bevegelsene over i skjemaet.

*************************************************************************************************
Rask behandling av dokumenter:

Må være inkludert:
Innen drift og regnskap. regnskap for dokumenter må være aktivert (bortsett fra «Drift»-dokumentet, se nedenfor).

Må være slått av:
i beregningsoppgaver gir det ikke mening med et lønnsdokument.

For dokumentet "Operation" bør posting være deaktivert helt (i dokumentegenskapene "Posting = Prohibit"),
siden han skriver skriver ganske enkelt data direkte til registeret når han skriver.

*************************************************************************************************
Tilstand i en forespørsel av formen "Enten den angitte nomenklaturen eller en hvilken som helst, hvis ikke spesifisert"

I spørringer påtreffes følgende oppgave: for eksempel må du velge dokumenter med en spesifisert nomenklatur eller alle dokumenter hvis nomenklaturen ikke er spesifisert.
Det løses av følgende betingelse i selve forespørselen:

Nomenklatur = &Nomenklatur ELLER &Nomenklatur = Verdi(Directory.Nomenclature.EmptyLink)

Men det ville være mer optimalt og riktig å transformere denne tilstanden (takk yukon):

Request.Text = Request.Text + "WHERE Nomenclature = &Nomenklatur";

slutt om;

Med bruken av spørringsobjektmodellen i 8.3.5, vil det være mulig å legge til en betingelse sikrere:

Hvis ValueFilled (Nomenklatur) Da
Query1.Selection.Add("Vare = &Nomenklatur");
Request.SetParameter("Nomenklatur", Nomenklatur);
slutt om;

*************************************************************************************************
Slå sammen tabeller i spørringer:

Antallet totale poster avhenger ikke av om feltet til den sammenføyde tabellen vises, det avhenger bare av de konfigurerte relasjonene.
Det vil si at feltet til den vedlagte tabellen kanskje ikke vises.

Hvis du vil legge ved en tabell uten noen betingelser, skriver du bare betingelsen "TRUE" på fanen betingelser.
I dette tilfellet vil bordet bli satt sammen nøyaktig.

*************************************************************************************************
Ved å bruke planen over karakteristikktyper (PVC):

1. Bruk som en mekanisme for å beskrive egenskapene til objekter.

1.1. Vi lager PVC. Disse vil være Typer av kjennetegn (for eksempel farge, størrelse, maks. hastighet osv.). I innstillingene, velg alle mulige typer karakteristiske verdier og, om nødvendig, opprett objektet fra punkt 1.2 og angi det også i innstillingene.

1.2. For ytterligere verdier av PVC oppretter vi en underordnet katalog Additional Values of Characteristics (eller ganske enkelt verdier av egenskaper).
Den vil lagre egenskaper hvis de ikke er i eksisterende kataloger. Det kan hende vi ikke oppretter det hvis alle egenskapene vi trenger er i eksisterende kataloger, eller disse verdiene kan representeres av elementære datatyper. I PVC-innstillingene indikerer vi at denne katalogen vil bli brukt til flere formål. egenskaper verdier.

1.3. Vi lager et informasjonsregister, som faktisk forbinder tre objekter:
- Objektet som vi kobler egenskapsmekanismen til
- Typekarakteristikk (PVC-type)
- Egenskapsverdi (type - karakteristikk, dette er en ny type som dukket opp i systemet etter etableringen av PVC
og beskrive alle mulige datatyper som en karakteristisk verdi kan ta).
I informasjonsregisteret angir vi at Karakteristikktypen er eier for Karakteristikkverdien (lenke til valgparameteren), samt typeforbindelsen for Karakteristikkverdien, igjen fra Karakteristikktypen.

En annen funksjon er at for hver opprettet type karakteristikk kan du spesifisere typen karakteristisk verdi, hvis du ikke trenger alle mulige typer for å beskrive verdien av denne karakteristikken.

2. Bruk av PVC for å lage en sub-conto-mekanisme for regnskapsregisteret .

2.1. Vi lager PVC-typer Subconto.

2.2. Vi oppretter en underordnet katalog ValuesSubConto (som med egenskaper, vil den inneholde subconto-verdier hvis det ikke er slike i andre kataloger).

2.3. Kommunikasjon skjer ved hjelp av en kontoplan.

*************************************************************************************************
Ressurser for regnskapsregister:

Beløp - balanse,
Mengde - utenfor balansen og knyttet til regnskapskjennetegn Kvantitativ

*************************************************************************************************
Virtuelle regnskapsregistertabeller:

Omsetning: omsetning av en enkelt konto
OmsetningDtKt: omsetning mellom to kontoer, det vil si alle de samme transaksjonene for perioden.

*************************************************************************************************
Valutaregnskap på regnskapsregistre – hvordan implementere:

Vi oppretter et regnskapsattributt "valuta" i kontoplanen.
I regnskapsregisteret oppretter vi i tillegg:
- Valutadimensjon (forbud mot tomme verdier, utenfor balansen, regnskapsattributt - valuta)
- ressurs CurrencyAmount (utenfor balansen, regnskapsattributt - valuta, det vil lagre beløpet i valuta, det vil si $100 for eksempel)
Alle.

Registerstrukturen er derfor:

Målinger:
- Valuta
Ressurser
- Mengde
- Beløp (beløp i rubler)
- CurrencyAmount (beløp i valuta)

Dermed er valutaregnskap bare en foredling av konvensjonell regnskap i Hviterussland; det endrer ikke essensen av for eksempel ressursbeløpet
(der er beløpet som vanlig i rubler, uavhengig av om kontoen er i utenlandsk valuta eller ikke).
Og hvis valutaregnskapsfunksjonen er slått av for kontoen, er dette den vanlige strukturen til Republikken Hviterussland (ressurser - bare mengde og beløp).

*************************************************************************************************
Når vi setter parametrene til en virtuell tabell for å få en del av sistnevnte, pålegger vi betingelser på dimensjoner, og ikke på ressurser.

Ellers får vi ikke et stykke av de siste, men den siste posten med den spesifiserte ressursverdien - den er kanskje ikke den siste i settet med dimensjoner

*************************************************************************************************
Betydningen av ressursen og detaljer i beregningsregisteret

I beregningsregistre gjør oppretting av en ressurs det mulig å motta den ved beregning av grunnlaget ved hjelp av dette registeret.
Og selv i forhold til den gitte perioden, vil ressursverdien bli beregnet på nytt (hvis basisperioden ikke sammenfaller med registerets periodisitet).

Og verdien av attributtet er bare tilgjengelig i den virkelige tabellen i beregningsregisteret; den er ikke tilgjengelig i virtuelle tabeller.

*************************************************************************************************
Avkrysningsboks "Basic" i egenskapene til beregningsregisterdimensjonen
Det betyr at en base vil bli hentet fra denne dimensjonen i fremtiden og tjener til ytterligere indeksering av verdier for dette feltet.

*************************************************************************************************
Fordeling av feriegyldighetsperioden etter måned ved registrering av sett med registeroppføringer,
hvis ferie er spesifisert i dokumentet på én linje i flere måneder samtidig på én linje:

StartDate of CurrentMonth = Start of Month(TexLineMainAccruals.ActionPeriodStart); CurrentMonthEndDate = EndMonth(TexLineMainAccruals.ActionPeriodStart); CurrentMonth = Dato; WhileDateStartCurrentMonth<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;

*************************************************************************************************
Bygge et Gantt-diagram:

Vi plasserer et element av typen "Gantt-diagram" på skjemaet, kaller det DG, lager deretter kommandoen "Generer" og skriver følgende i skjemamodulen:

&OnClient-prosedyre Generate(Command) GenerateOnServer(); Slutt på prosedyre &På serveren Prosedyre GenerateOn Server() DG.Clear(); DG.Update = False; Request = New Request("SELECT |BasicAccrualsActualActionPeriod.Employee, |BasicAccrualsActualActionPeriod.CalculationType, |BasicAccrualsActualActionPeriod.ActionPeriodStart AS ActionPeriodAccrualsPeriodAccrualsP d |FRA |Beregningsregister.BasicAccruals.ActualPeriodActions AS BasicAccrualsActualPeriodActions |HVOR |BasicAccrualsActualPeriodActions.PeriodActions MELLOM &Startdato OG &Sluttdato "); Query.SetParameter("StartDate", Periode.StartDate); Request.SetParameter("EndDate", Period.EndDate); Select = Query.Run().Select(); Mens Selection.Next() Loop Point = DG.SetPoint(Selection.Employee); Series = DG.SetSeries(Selection.CalculationType); Verdi = DG.GetValue(Point, Series); Intervall = Value.Add(); Interval.Start = Sample.PeriodActionStart; Interval.End = Sample.ActionPeriodEnd; EndCycle; DG.Update = Sant; Slutt på prosedyre

Faktisk er det bare koden i loopen som er viktig for oss her, resten av tingene er hjelpemidler, jeg ga bare hele implementeringen av denne deloppgaven.
I forespørselen er det viktig for oss at det er ansatt, type betaling, startdato og sluttdato for perioden.
Koden er faktisk veldig enkel, lett å huske, ikke bli skremt hvis den virker tungvint

*************************************************************************************************
Behandling av "reverserings"-oppføringer i beregningsoppgaver:

I t(objektmodul) danner vi alle bevegelser, og hvis det er poster i andre perioder, får vi dem slik
(systemet genererer dem automatisk - hjelper oss):

Addition Records = Movements.MainAccruals.GetAddition(); // Du trenger ikke å registrere bevegelser for å få tillegget

For hver teknisk linje fra syklusen for rekordtillegg
Record = Movements.MainAccruals.Add();
FillPropertyValues(Record, TechString);
Record.RegistrationPeriod = TechString.RegistrationPeriodReversal;
Record.ActionPeriodStart = TechString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = TechString.ActionPeriodEndReversal;
Slutt på syklusen

Og når du beregner poster, sett inn sjekker:

Hvis TechMotion.Reversal Da
CurrentMovement.Sum = - CurrentMovement.Amount;
slutt om;

*************************************************************************************************
Hvordan fastslå hva som inngår i hovedperiodiseringen og hva som inngår i tilleggsperiodisering i beregningsoppgaver.

Men dette er ikke alltid 100 % klart; det er også mer kompliserte saker, selv om det er ganske mange av dem
(for eksempel en bonus som avhenger av antall arbeidsdager i en måned - dette er HE).

Grunnleggende kostnader:
Hvis type beregning er avhengig av tidsplanen (som betyr et register over opplysninger med kalenderdatoer), så refererer det til hovedkostnadene.

Eksempel OH:
- Lønn
- Noe som regnes ut fra antall virkedager (og for dette må du bruke en tidsplan): enten i gyldighetsperioden (som lønn) eller i basisperioden

Ekstra kostnader:
Hva som vurderes enten fra det påløpte beløpet, eller tiden ARBEID (og ikke normen!), eller ikke avhenger i det hele tatt - dette kommer i tillegg. periodisering.

Det vil si: periodiseringer for beregningen som tidsstandarden brukes (kanskje også et faktum) er OH, og som faktiske data eller ingenting er nødvendig for er DN.

Eller med andre ord:

Hvis VR bruker en tidsstandard, må gyldighetsperioden inkluderes for VR.

*************************************************************************************************
Legg til muligheten til å åpne den innebygde hjelpedelen "Arbeid med oppslagsverk" i listeformen til "Nomenklatur"-katalogen.

Kjør kommandoen på skjemaet:

&På klient
Prosedyrehjelp (kommando)
OpenHelp("v8help://1cv8/EnterprWorkingWithCatalogs");
Slutt på prosedyre

Vi definerer seksjonslinjen som følger:
Gå til hjelpeinformasjonen til konfigurasjonsobjektet (i konfiguratoren), skriv et ord, velg det, gå til Elements/Link-menyen og velg ønsket del av 1C Help, hvoretter linken settes inn automatisk. Det ser komplisert ut, men i praksis er det enkelt.

*************************************************************************************************
Implementering av interaksjon mellom skjemaer, for eksempel utvalg:

1. Fra gjeldende skjema åpner du det ønskede ved å bruke “OpenForm()”-metoden, og sender strukturen med parametere som andre parameter (om nødvendig). Den tredje parameteren kan sende en lenke til dette skjemaet - ThisForm.

2. I det åpnede skjemaet, i "When CreatedOnServer()"-behandleren, kan vi fange parametrene som ble sendt i trinn 1 til "Parameters.[ParameterName]". Skjemaet som startet åpningen av dette skjemaet vil være tilgjengelig via «Eier»-identifikatoren (hvis det selvfølgelig ble spesifisert i trinn 1).

Og viktigst av alt, eksportfunksjonene til eierskjemaet vil være tilgjengelige. Det vil si at vi kan kalle eksportfunksjonen til kildeskjemaet og sende noe der som en parameter for å behandle utvalget. Og denne funksjonen vil allerede fylle ut det som trengs i det originale skjemaet. Det er bare ett forbehold - du kan ikke sende en verditabell mellom klientprosedyrer, men vi kan plassere den i midlertidig lagring og ganske enkelt sende VX-adressen, og deretter trekke den ut fra VX.

*************************************************************************************************
Livssyklus for skjemaparametere

Alle parametere som er overført til skjemaet på tidspunktet for åpningen er kun synlige i prosedyren "When CreateOnServer".
Når de er opprettet, blir alle parametere ødelagt og er ikke lenger tilgjengelige på skjemaet.
Unntaket er for parametere som er deklarert i skjemaeditoren med "Key Parameter"-attributtet.
De bestemmer det unike ved skjemaet.
Denne parameteren vil eksistere så lenge selve skjemaet eksisterer.

*************************************************************************************************
Bruke Taxi-grensesnittet

Under utviklingen kan du sette det vanlige administrerte grensesnittet 8.2 i konfigurasjonsegenskapene - dette gjør alt merkbart mer kompakt og kjent.
Dette gjelder spesielt hvis du leier eksternt - skjermoppløsningen er veldig liten, og det er umulig å gjøre noe med "taxi"-grensesnittet.
Bare ikke glem å sette "Taxi" igjen når du er ferdig!Ellers trekker sensor poeng!

*************************************************************************************************

PS: E Det er egne standard deloppgaver som brukes i alle oppgaver, og det er disse du må kunne løse (for eksempel avskriving i partier, bruk av PVC (vel, dette er virkelig sjeldent) og andre). Og i alle oppgaver blir de ganske enkelt gjentatt (et sted er det noen deloppgaver, et annet sted, bare i forskjellige kombinasjoner). Dessuten har de lenge lovet å gi ut en ny samling (hvis de ikke allerede har gjort det), der det burde være mye flere problemer, det vil si at det ikke er noen vits i å huske løsninger på individuelle problemer, det er fornuftig å lære å løse individuelle standard deloppgaver, så vil du løse ethvert problem.

PSS: Kolleger, hvis noen har annen nyttig informasjon om å forberede seg til eksamen og bestå den, vennligst skriv i kommentarfeltet, så legger vi til artikkelen.