• Hjem
  •  > 
  • OS problemer
  •  > 
  • SKD 1s hvordan lage en periode. Vi lager en rapport med en spesifisert frekvens på lagringssystemet

SKD 1s hvordan lage en periode. Vi lager en rapport med en spesifisert frekvens på lagringssystemet

Når du oppretter rapporter på et adgangskontrollsystem, er det ofte behov for å vise et periodevalg på rapportskjemaet, slik at du ikke trenger å legge inn datoer manuelt, men velge fra en liste med standardperioder, for eksempel: "År" , "Måned", "Uke" osv. . For parametere av datotypen kan du bare spesifisere "Begynnelsen av dette året, måneden osv.", men "Slutt" er ikke oppgitt.

Saken er at av datatypene er bare typen "Standard startdato" tilgjengelig, men jeg vil også ha "Standard sluttdato".

Det er en måte å komme seg rundt dette på.

  1. La oss lage en ny parameter, kall den "Periode"
  2. Sett denne parameteren til typen "Standardperiode"
  3. I "Uttrykk"-feltet til "Start of Period" og "End of Period" parametere, som brukes i forespørselen, setter du uttrykkene " &Period.StartDate" og " &Periode.sluttdato".

Men det er en liten subtilitet. Hvis vi bruker virtuelle tabeller i spørringen, vil mest sannsynlig rapporten slutte å fungere og en feilmelding som "Feil ved behandling av visningen, type mismatch, parameternummer..." vil vises.

For å unngå dette må du fjerne alle virtuelle tabellparametere.

Og legg dem til i tabellene på fanen "Datasammensetning".

For at parameterne skal vises i hurtigrapportinnstillingene, aktiver det tilsvarende flagget for rapportparameterne.

Nå ser periodeutvalget på rapportskjemaet slik ut.

God dag, kjære lesere av bloggsiden! I den siste artikkelen lærte vi hvorfor disse rollene er nødvendige. Og i dag, i den andre av denne artikkelserien, skal vi se på sette opp en rolle med egenskapen "Period"., og vurder også eksempler på å fylle disse rollene. Resten beregnes ved å bruke feltet med "Periode"-rollen. Akkurat som i felten med rollen «Dimension», som vi skal snakke om en annen gang. Så la oss komme i gang!

La oss lage en ny rapport:

  1. I konfiguratoren velger du menypunktet "Fil" - "Ny" - "Ekstern rapport".
  2. Klikk på knappen "Åpne datasammensetningsdiagram". Klikk på "Fullfør"-knappen i dialogboksen som åpnes.
  3. La oss nå lage en som får tilgang til den virtuelle tabellen "Akkumuleringsregistre".
  4. Høyreklikk på "Datasett"-noden og velg linjen "Legg til datasett - spørring".
  5. Klikk nå på "Query Builder"-knappen. La oss velge akkumuleringsregisteret "GoodsInWarehousesRemainsAndTurnover" (USP-konfigurasjon).
  6. La oss åpne dialogboksen "Virtuelle tabellparametere" og spesifisere at frekvensen "Auto" skal brukes, det vil si at det vil være mulig å spesifisere flere perioder.

La oss nå konfigurere utdatafeltene. La disse være følgende felter: "Registrar", "PeriodMonth", "Nomenklatur", "Kvalitet" og informasjon om saldoer. Å legge til et felt gjøres ved å dobbeltklikke med venstre museknapp på ønsket felt eller bruke “>”-knappen. Etter å ha lagt til feltene, klikk på "OK"-knappen.

Vær oppmerksom på at for noen felt blir en rolle med egenskapen "Periode" automatisk konfigurert.

La oss se på hva som finnes rolleinnstillinger for «Periode»-egenskapen. Først angis periodens serienummer. Nummereringen må være kontinuerlig, fra én, fra de laveste periodene til den høyeste, det vil si først vil det være for eksempel linjenummeret, deretter "Recorder", deretter den andre, dag, uke, måned, kvartal, år.

Dermed bør feltene som vises i vår forespørsel nummereres. Legg merke til at vi har to periodefelt - "Registrar" og "PeriodMonth". Det lave feltet er "Registrar", det er tildelt en, og det høye feltet er "PeriodMonth", det er tildelt to. Vi skal se nærmere på dette i neste artikkel.

La oss sette opp rapporten vår:

  1. La oss gå til "Ressurser"-fanen og definere ressursene til rapporten vår.
  2. Klikk på ">>"-knappen for å velge alle feltene for ressurser.
  3. La oss nå gå til fanen "Innstillinger" og lage en innstilling i form av en liste.
  4. Klikk på "Data komposisjonsinnstillinger designer"-knappen (knappen i form av en tryllestav).
  5. Rapporttype: "Liste". Klikk på "Neste"-knappen.
  6. La oss konfigurere utdatafeltene ved å klikke på ">>"-knappen. La oss ordne dem slik: "PeriodMonth", "Nomenklatur", "Kvalitet", "Registrar".
  7. Klikk på "Neste"-knappen og sett opp grupperingen. Vi vil sette opp grupperingen i følgende rekkefølge: "PeriodMonth", "Nomenklatur", "Kvalitet". "Registrar"-grupperingen vil bli vist i form av detaljerte poster.
  8. Klikk på "OK"-knappen.

La oss åpne rapporten vår. Hvis vi kjører denne rapporten, vil vi se noen funksjoner når vi mottar saldoer. Hvis du ser nøye på rapportresultatet, vil du umiddelbart legge merke til flere feil. Spesielt, av en eller annen grunn, helt i begynnelsen av selskapets aktivitetsperiode, er det en innledende balanse.

Og denne feilen er relatert til funksjonen for å motta saldo fra registraren. For at disse saldoene skal vises riktig, må du legge til ett felt til i utdatafeltene for forespørselen - feltet "PeriodSecond". For å legge til "PeriodSecond"-feltet, åpne rapporten i konfiguratoren og klikk på knappen "Åpne datasammensetningsskjema". Klikk nå på "Query Builder"-knappen og legg til "PeriodSecond". I dette tilfellet vil "Registrar"-feltet forbli det første feltet i perioden, "PeriodSecond" vil være det andre, og "PeriodMonth" vil være det tredje.

Hva er et sekund for? Datasammensetningssystemet beregner saldoene ved beregning, og for entydig å bestemme posisjonen til opptakeren på tidsaksen, er koblingen til selve opptakeren også nødvendig, det vil si datoen til denne opptakeren , og da vil layoutsystemet kunne oppnå riktig balanse ved beregning. Hvis vi spesifiserer riktig rekkefølge på feltene og genererer rapporten på nytt, får vi:

Nå er det ingen balanse igjen for oppstart av aktiviteter under Sokkelnomenklaturen. Så for neste periode faller det sammen med den endelige balansen, det vil si at vi ser et virkelig riktig resultat. Du kan laste ned en eksempelrapport fra lenken nedenfor. Likte du artikkelen? Hva kan endres, hva kan legges til? Del gjerne om det i kommentarfeltet!

På slutten av artikkelen vil jeg anbefale deg en gratis fra Anatoly Sotnikov. Dette er et kurs fra en erfaren programmerer. Den vil vise deg på eget grunnlag hvordan du bygger rapporter i tilgangskontrollsystemet. Du trenger bare å lytte nøye og huske! Du vil få svar på følgende spørsmål:
  • Hvordan lage en enkel listerapport?
  • Hva er felt-, bane- og tittelkolonnene på "Felter"-fanen for?
  • Hva er begrensningene for layoutfelt?
  • Hvordan konfigurere roller riktig?
  • Hva er rollene for layoutfelt?
  • Hvor finner jeg fanen for datasammensetning i en spørring?
  • Hvordan konfigurere parametere i tilgangskontrollsystemet?
  • Det blir enda mer interessant...
Kanskje du ikke burde prøve å surfe på Internett selv på jakt etter nødvendig informasjon? Dessuten er alt klart til bruk. Bare sett i gang! Alle detaljer om hva som er i de gratis videoleksjonene

Her er en av leksjonene om å bokmerke datasammensetningen i en spørring:



Denne artikkelen diskuterer noen av funksjonene ved å sette opp en periode ved bruk av et Data Composition System (DCS), problemer som oppstår på grunn av forskjeller i konseptet med en periode mellom en vanlig bruker og 1C-systemet, og foreslår også måter å løse dem på .
De fleste rapporter som er utviklet ved hjelp av et Data Composition System (DCS) krever at brukeren oppgir perioden rapporten skal bygges for. Som regel, i ACS, er perioderegistrering organisert gjennom parametere, ved å bruke følgende konstruksjon, se. Fig.1 Denne metoden for å gå inn i en periode anses som "klassisk" den er beskrevet i en artikkel om ITS og annen litteratur viet utvikling i 1C, så la oss ta det som grunnlag. La oss som et eksempel vurdere en enkel forespørsel som mottar alle dokumenter Salg av varer og tjenester for en gitt periode, se Fig.2 Ved bruk av denne rapporten setter brukeren perioden gjennom parametrene, se. Fig.3 Alt ser ut til å være riktig... MEN det er et lite problem:

Saken er at de aller fleste brukere "forstår" perioden annerledes enn 1C "forstår" den, eksempler:
1). La oss vurdere Fig.3
Fra brukerens side er ikke perioden spesifisert, det vil si UBEGRENSET, det vil si at ALLE dokumenter uten datobegrensninger skal inkluderes i rapporten.
"Fra synspunktet" til 1C-systemet er periodeparameteren satt og ... begge grensene er lik 01.01.0001 og kun dokumenter med tom dato vil bli inkludert i rapporten, noe som i praksis betyr ikke et enkelt dokument vil bli inkludert.
2). La oss vurdere Fig.4
Fra brukerens synspunkt bør rapporten inneholde alle dokumenter fra og med datoen 28.01.2010.
"Fra synspunktet" til 1C vil perioden 28.01.2010 – 01.01.0001 forårsake et unntak.

Du kan selvfølgelig prøve å forklare brukeren hvorfor rapporten ikke viser dokumentene han forventer å se og hvordan perioden presenteres fra 1Cs "synspunkt", men dette er en utakknemlig oppgave, og det er også feil. Et godt program bør for det første være brukervennlig, fordi programmet eksisterer for brukeren, og ikke omvendt, derfor må du "lære" 1C for å forstå perioden slik brukeren forstår den, nemlig:
1). Start på periode og slutt på periode er ikke spesifisert -> alle dokumenter.
2). Bare begynnelsen av perioden er spesifisert -> alle dokumenter som starter fra begynnelsen av perioden
3). I tillegg vil vi sjekke at End of Period >= Start of Period, og hvis dette ikke stemmer, vil vi anta at End of Period ikke er spesifisert, dvs. 2).
Basert på ovenstående vil uttrykket for End Date-parameteren se slik ut:

SELECT WHEN &Period.EndDate=DATETIME(1,1,1) THEN DATETIME(3999,12,31,23,59,59) ELLES SELECT WHEN &Period.EndDate<&Период.ДатаНачала ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ &Период.ДатаОкончания КОНЕЦ КОНЕЦ

Den endelige formen for vårt periodeutvalgsdesign vises i Fig.5

Noen funksjoner ved innstilling av perioden i adgangskontrollsystemet.

De fleste rapporter som er utviklet ved hjelp av et Data Composition System (DCS) krever at brukeren oppgir perioden rapporten skal bygges for.

Som regel, i ACS, er perioderegistrering organisert gjennom parametere, ved å bruke følgende konstruksjon, se Denne metoden for perioderegistrering regnes som "klassisk" den er beskrevet i en artikkel om ITS og annen litteratur viet til utvikling i 1C la oss ta det som grunnlag. La oss som et eksempel vurdere en enkel forespørsel som mottar alle dokumenter Salg av varer og tjenester for en gitt periode, se

Når du bruker denne rapporten, setter brukeren perioden gjennom parameterne, se Alt ser ut til å være riktig... MEN det er et lite problem:

Saken er at de aller fleste brukere "forstår" perioden annerledes enn 1C "forstår" den, eksempler:

Fra brukerens side er ikke perioden spesifisert, det vil si UBEGRENSET, det vil si at ALLE dokumenter uten datobegrensninger skal inkluderes i rapporten.

"Fra synspunktet" til 1C-systemet er periodeparameteren satt og ... begge grensene er lik 01.01.0001 og kun dokumenter med tom dato vil bli inkludert i rapporten, noe som i praksis betyr ikke et enkelt dokument vil bli inkludert.

Fra brukerens synspunkt bør rapporten inneholde alle dokumenter fra og med datoen 28.01.2010.

"Fra synspunktet" til 1C vil perioden 28.01.2010 - 01.01.0001 forårsake et unntak.

Du kan selvfølgelig prøve å forklare brukeren hvorfor rapporten ikke viser dokumentene han forventer å se og hvordan perioden presenteres fra 1Cs "synspunkt", men dette er en utakknemlig oppgave, og det er også feil. Et godt program bør for det første være brukervennlig, fordi programmet eksisterer for brukeren, og ikke omvendt, derfor må du "lære" 1C for å forstå perioden slik brukeren forstår den, nemlig:

1). Start på periode og slutt på periode er ikke spesifisert -> alle dokumenter.

2). Bare begynnelsen av perioden er spesifisert -> alle dokumenter som starter fra begynnelsen av perioden

3). I tillegg vil vi sjekke at End of Period >= Start of Period, og hvis dette ikke stemmer, vil vi anta at End of Period ikke er spesifisert, dvs. 2).

Basert på ovenstående er uttrykket for parameteren Sluttdato:

WHEN &Period.EndDate=DATETIME(1,1,1)

DA DATOTIME(3999;12;31)

NÅR &Periode.sluttdato<&Период.ДатаНачала

DA DATOTIME(3999;12;31) DATOTIME(3999;12;31;23;59;59)

&Periode.sluttdato

Den endelige formen for vårt periodeutvalgsdesign vises i

Merk: denne mekanismen for innstilling av parametere er beregnet på eldre plattformer 1C 8.1 og 8.2 (og konfigurasjoner som kjører under deres kontroll har innebygde mekanismer for å kontrollere tomme parametere, og det er ikke nødvendig å ty til mekanismen); beskrevet i denne artikkelen, i tillegg På noen versjoner av 1C-plattformen er feil og feil drift mulig.

Så la oss begynne.

For enkelhets skyld, for å forstå eksemplet, vil vi bygge på ett enkelt sirkulerende akkumuleringsregister.

I mitt tilfelle er dette akkumuleringsregisteret "Work in Progress Accounting".

For eksempel vil vi indikere parametrene stivt (ikke gjennom myk påføring av parametere på tilgangskontrollsystemet):

Vær oppmerksom på at frekvensen til det virtuelle bordet er "Record".

Men, som nevnt ovenfor, trenger vi perioden når det gjelder periodisitet, så jeg foreslår å beregne "Periode"-feltet på følgende måte (ikke veldig hyggelig, men jeg har ikke sett noen bedre alternativer):

Som det fremgår av skjermbildet, sendes en parameter til forespørselen, som brukeren spesifiserer på skjemaet: Verdien av "Frequency"-oppregningen - denne oppregningen finnes i nesten alle standardløsninger.

Vi vil indikere tilgjengelige typer på "Parameters"-fanen:

Med denne innstillingen formaterer vi perioden slik at alt er vakkert og behagelig for øyet)

Her er selve formatene:

Måned: DF="MMMM åååå "å.""

Dag: DF = dd.MM.åååå

Uke: DF = ""Uke fra "dd.MM.åååå"

Kvartal: DF = "til "kvart" yyyy "y.""

År: DF = "åååå "å.""

Tiår: DF = ""Tiår fra "dd.MM.åååå"

Halvår: DF = ""Halvår fra" dd.MM.åååå"

Det er alt. Resultatet er et fantastisk bilde: