1s 8.3 SCD-rapport beräknade fält. Användbara exempel på att skapa ett datasammansättningsdiagram. Resten av divisionen

  • 1C-Bitrix
  • Ett av de viktigaste områdena inom affärsprogramvara är rapportering. Ett företags öde kan bero (och inte i bildlig mening!) på hur lätt det är att anpassa en befintlig rapport till verksamhetens (och lagstiftningens) förändrade behov eller skapa en ny, vare sig det är en rapport för skatteverket. eller ett diagram över efterfrågan på varors beroende av säsong och andra faktorer. Ett kraftfullt och flexibelt rapporteringssystem som gör det enkelt att extrahera nödvändig data från systemet, presentera den i en begriplig form, så att slutanvändaren kan konfigurera om en standardrapport för att se data i ett nytt ljus - detta är det idealiska för varje affärssystem bör sträva efter.

    I 1C:Enterprise-plattformen är en mekanism som kallas "Data Composition System" (förkortat DCS) ansvarig för att generera rapporter. I den här artikeln kommer vi att försöka ge kort beskrivning idéer och arkitektur för ACS-mekanismen och dess kapacitet.


    ACS är en mekanism baserad på en deklarativ beskrivning av rapporter. ACS är designat för att bygga rapporter och för att visa information som har komplex struktur. Förresten, förutom att utveckla rapporter, används ACS-mekanismen också i 1C:Enterprise i en dynamisk lista, ett verktyg för att visa listinformation med rik funktionalitet (visa platta och hierarkiska listor, villkorlig design av rader, grupperingar, etc. ).

    Lite historia

    I den allra första versionen av 1C:Enterprise 8-plattformen, version 8.0, gjordes rapporter så här:
    1. En eller flera frågor skrevs i frågespråket 1C (SQL-liknande språk, mer om det nedan).
    2. Kod skrevs som överförde resultaten av utförda frågor till ett kalkylarksdokument eller diagram. Koden kan också göra arbete som inte kunde göras i en fråga - till exempel beräknade den värden med det inbyggda 1C-språket.
    Tillvägagångssättet är enkelt, men inte det mest bekväma - det finns minimala visuella inställningar, allt måste programmeras "hand-to-hand". Och ett av trumfkorten på den tiden för den helt nya plattformen "1C:Enterprise 8" var minimeringen i applikationslösningen av mängden kod som måste skrivas manuellt, i synnerhet genom visuell design. Det vore logiskt att följa samma väg i rapporteringsmekanismen. Detta gjordes genom att utveckla en ny mekanism - Data Composition System.

    En av idéerna som låg till grund för passerkontrollsystemet var flexibiliteten och anpassningen av rapporter, vilket var tillgängligt för både utvecklaren och slutanvändaren. Helst skulle jag vilja ge slutanvändaren tillgång till samma uppsättning rapportdesignverktyg som utvecklaren. Det skulle vara logiskt att skapa en enda uppsättning verktyg tillgängliga för alla. Tja, eftersom verktygen kräver slutanvändarens deltagande, betyder det att användningen av programmering i dem bör reduceras till ett minimum (det är bäst att eliminera det helt), och visuella inställningar bör användas maximalt.

    Formulering av problemet

    Uppgiften innan utvecklingsteamet var att skapa ett rapporteringssystem baserat inte på en algoritm (dvs genom att skriva kod), utan på en deklarativ metod för att skapa rapporter. Och vi tror att problemet har lösts framgångsrikt. Enligt vår erfarenhet kan cirka 80 % av den erforderliga rapporteringen implementeras med ACS utan en enda kodrad (förutom att skriva formler för beräknade fält), mestadels genom visuella inställningar.
    Utvecklingen av den första versionen av SDS tog cirka 5 personår.

    Två språk

    Det finns två språk som är involverade i att skapa rapporter. Det ena är ett frågespråk som används för att hämta data. Det andra är uttrycksspråket för datasammansättning, avsett för att skriva uttryck som används i olika delar av systemet, till exempel i datasammansättningsinställningar, för att beskriva uttryck för användarfält.

    Frågespråk

    Frågespråket är baserat på SQL och är lätt att lära sig för dem som är kunniga i SQL. Exempelbegäran:

    Det är lätt att se analoger till sektionsstandarden för SQL-frågor - SELECT, FROM, GROUP BY, ORDER BY.

    Samtidigt innehåller frågespråket ett betydande antal tillägg som syftar till att spegla de specifika finansiella och ekonomiska problemen och maximera minskningen av ansträngningarna för att utveckla applikationslösningar:

    • Åtkomst till fält med hjälp av en punkt. Om fälten i en tabell är av en referenstyp (de lagrar länkar till objekt i en annan tabell), kan utvecklaren hänvisa till dem i texten i begäran genom ".", och systemet begränsar inte antalet kapslingsnivåer av sådana länkar (till exempel Kundorder. Avtal. Organisation. Telefon).
    • Multidimensionell och flernivåbildning av resultat. Summor och delsummor bildas med hänsyn till gruppering och hierarki, nivåer kan passeras i valfri ordning med summering och korrekt konstruktion av totaler enligt tidsdimensioner säkerställs.
    • Stöd för virtuella tabeller. Virtuella tabeller som tillhandahålls av systemet låter dig få nästan färdiga data för de flesta applikationsuppgifter utan att behöva skapa komplexa frågor. Således kan en virtuell tabell tillhandahålla data om produktsaldon efter perioder vid en viss tidpunkt. Samtidigt utnyttjar virtuella tabeller den lagrade informationen maximalt, till exempel tidigare beräknade summor etc.
    • Tillfälliga bord. Frågespråket låter dig använda tillfälliga tabeller i frågor. Med deras hjälp kan du förbättra frågeprestanda, i vissa fall minska antalet blockeringar och göra frågetexten lättare att läsa.
    • Batchförfrågningar. För att göra det enklare att arbeta med tillfälliga tabeller, stöder frågespråket arbete med batch-frågor - sålunda placeras skapandet av en temporär tabell och dess användning i en fråga. En batchbegäran är en sekvens av förfrågningar separerade med semikolon (";"). Förfrågningarna i partiet exekveras en efter en. Resultatet av att exekvera en batchbegäran, beroende på vilken metod som används, kommer antingen att vara resultatet som returneras av den sista begäran i partiet, eller en uppsättning resultat från alla frågor i partiet i den sekvens som frågorna i partiet följer .
    • Hämta representationer av referensfält. Varje objekttabell (i vilken en referensbok eller ett dokument lagras) har ett virtuellt fält - "Visa". Det här fältet innehåller en textrepresentation av objektet och gör rapportskaparens jobb enklare. Så för ett dokument innehåller detta fält all nyckelinformation - namnet på dokumenttypen, dess nummer och datum (till exempel "Rea 000000003 från 07/06/2017 17:49:14"), vilket sparar utvecklaren från skriva ett beräknat fält.
    • och så vidare.
    Begäran mekanismen ändrar automatiskt begäran med hänsyn till de roller som användaren på vars vägnar begäran exekveras tillhör (dvs användaren kommer bara att se de data som han har rätt att se) och funktionella alternativ (dvs i enlighet med med de som konfigurerats i applikationslösningens funktionalitet).

    Det finns också speciella frågespråktillägg för passersystem. Expansion utförs med hjälp av speciella syntaktiska instruktioner inneslutna i lockiga hängslen och placerade direkt i förfrågan. Med hjälp av tillägg bestämmer utvecklaren vilka operationer slutanvändaren ska kunna utföra när rapporten anpassas.

    Till exempel:

    • VÄLJA. Denna mening beskriver de fält som användaren kommer att kunna välja för utdata. Efter detta nyckelord listas alias för fält från huvudfrågevallistan som kommer att vara tillgängliga för konfiguration, separerade med kommatecken. Exempel: (VÄLJ artikel, lager)
    • VAR. Fälten där användaren kan tillämpa urval beskrivs. Detta förslag använder tabellfält. Det är inte tillåtet att använda vallistfältalias. Varje del av förbundet kan innehålla sitt eget WHERE-element. Exempel: (WHERE Item.*, Warehouse), (WHERE Document.Date >= &StartDate, Document.Date<= &ДатаКонца}
    • och så vidare.
    Exempel på användning av tillägg:

    Uttrycksspråk för datasammansättning

    Data Composition Expression Language är utformat för att skriva uttryck som används, särskilt för att beskriva anpassade fältuttryck. SKD låter dig definiera anpassade fält i en rapport med antingen dina egna uttryck eller uppsättningar av alternativ med villkor för deras val (analogt med CASE i SQL). Anpassade fält liknar beräknade fält. De kan ställas in både i konfiguratorn och i 1C:Enterprise-läge, men funktionerna i vanliga moduler kan inte användas i anpassade fältuttryck. Därför är anpassade fält avsedda för användaren snarare än utvecklaren.

    Exempel:

    Processen att skapa en rapport om passerkontrollsystemet

    När vi skapar en rapport måste vi skapa en layout som definierar hur data ska visas i rapporten. Du kan skapa en layout baserad på ett datalayoutdiagram. Ett datalayoutdiagram beskriver kärnan i den data som tillhandahålls till rapporten (varifrån kan du hämta data och hur du kan styra dess layout). Datasammansättningsschemat är grunden på vilken alla typer av rapporter kan genereras. Datasammansättningsschemat kan innehålla:
    • begära text med instruktioner för datasammansättningssystemet;
    • beskrivning av flera datamängder;
    • detaljerad beskrivning av tillgängliga fält;
    • beskrivning av relationer mellan flera datamängder;
    • beskrivning av datainsamlingsparametrar;
    • beskrivning av fältlayouter och grupperingar;
    • och så vidare.

    Du kan till exempel lägga till en fråga i datasammansättningsschemat som en datamängd och anropa frågekonstruktorn, som gör att du grafiskt kan skapa en fråga med godtycklig komplexitet:

    Resultatet av att starta frågedesignern blir frågetexten (på frågespråket 1C:Enterprise). Denna text kan justeras manuellt vid behov:

    Det kan finnas flera datamängder i ett datalayoutschema, datamängder kan länkas i layouten på vilket sätt som helst, beräknade fält kan läggas till, rapportparametrar kan anges osv. Det är värt att nämna en intressant egenskap hos frågemekanismen i 1C:Enterprise. Frågor översätts slutligen till en SQL-dialekt som är specifik för det DBMS som applikationen direkt arbetar med. I allmänhet försöker vi använda funktionerna hos DBMS-servrar maximalt (vi begränsas av det faktum att vi bara använder de funktioner som samtidigt är tillgängliga i alla DBMS som stöds av 1C:Enterprise-plattformen - MS SQL, Oracle, IBM DB2 , PostgreSQL). På frågenivå i beräknade fält kan vi alltså bara använda de funktioner som är översatta till SQL.

    Men på nivån för datasammansättningsschemat kan vi redan lägga till anpassade fält och använda funktioner i dem i det inbyggda 1C-utvecklingsspråket (inklusive de skrivna av oss), vilket avsevärt utökar rapporternas möjligheter. Tekniskt sett ser det ut så här - allt som kan översättas till SQL översätts till SQL, frågan exekveras på DBMS-nivå, frågeresultaten placeras i minnet på 1C-applikationsservern och SKD:n beräknar värdena för varje post av beräknade fält vars formler är skrivna på 1C-språket.


    Lägga till anpassade fält

    Du kan lägga till ett godtyckligt antal tabeller och diagram till rapporten:


    Rapportdesigner


    Körtidsrapport

    Med SKD kan användaren lägga till komplexa val till rapporten (som kommer att läggas till förfrågan på rätt ställen), villkorlig design (så att de visade fälten kan formateras annorlunda - med typsnitt, färg etc., beroende på deras värden ) och mycket mer..

    Processen att konstruera och generera en rapport kan kort beskrivas på följande sätt:

    • Utvecklaren i designtid med hjälp av en designer (eller i runtime med kod) bestämmer datalayoutschemat:
      • Text till förfrågan/förfrågningar
      • Beskrivning av beräknade fält
      • Relationer mellan förfrågningar (om det finns flera av dem)
      • Rapportalternativ
      • Standardinställningar
      • Etc.
    • Ovanstående inställningar sparas i layouten
    • Användaren öppnar rapporten
      • Gör eventuellt ytterligare inställningar (till exempel ändrar parametervärden)
      • Klicka på knappen "Generera".
    • Användarinställningar tillämpas på datasammansättningsschemat som definierats av utvecklaren.
    • En intermediär datasammansättningslayout bildas, som innehåller instruktioner om varifrån data ska tas emot. Särskilt de frågor som anges i layouten justeras. Fält som inte används i rapporten tas alltså bort från begäran (detta görs för att minimera mängden mottagen data). Alla fält som deltar i beräknade fältformler läggs till i frågan.
    • Datakompositionsprocessorn spelar in. Layoutprocessorn kör frågor, länkar datamängder, beräknar värden för beräknade fält och resurser och utför gruppering. Med ett ord, den gör alla beräkningar som inte utfördes på DBMS-nivå.
    • Datautgångsprocessorn startar en begäran om exekvering och visar mottagna data i ett kalkylbladsdokument, diagram, etc.


    Processen att generera en rapport med hjälp av ACS-mekanismen

    Vi försöker minimera mängden rapportdata som överförs från servern till klientapplikationen. När vi visar data i ett kalkylarksdokument, när vi öppnar ett kalkylarksdokument, överför vi från servern endast de rader som användaren ser i början av dokumentet. När användaren rör sig längs dokumentets linjer, laddas den saknade data ner från servern till klienten.

    Anpassade inställningar

    Alla ACS-verktyg är tillgängliga för både utvecklaren och slutanvändaren. Men praxis har visat att slutanvändaren ofta skräms av överflöd av verktygsmöjligheter. Dessutom, i de flesta fall, behöver slutanvändaren inte all kraft med inställningar - det räcker för honom att ha snabb tillgång till att ställa in en eller två rapportparametrar (till exempel period och motpart). Med utgångspunkt från en viss version av plattformen har rapportutvecklaren möjlighet att markera vilka rapportinställningar som är tillgängliga för användaren. Detta görs med hjälp av kryssrutan "Inkludera i användarinställningar". Dessutom har rapportinställningarna nu en "Visningsläge"-flagga, som har ett av tre värden:
    • Snabb åtkomst. Inställningen kommer att visas direkt överst i rapportfönstret.
    • Vanlig. Inställningen kommer att vara tillgänglig via knappen "Inställningar".
    • Inte tillgänglig. Inställningen kommer inte att vara tillgänglig för slutanvändaren.


    Ställa in visningsläge i designtid


    Visa inställningen i snabbåtkomstläge under körning (under knappen Generera)

    Utvecklingsplaner

    Ett av våra prioriterade områden i utvecklingen av passersystem är att förenkla användarinställningar. Vår erfarenhet visar att för vissa slutanvändare är arbetet med användarinställningar fortfarande ett stort uppdrag. Vi tar hänsyn till detta och arbetar i denna riktning. Följaktligen kommer det också att bli lättare för utvecklare att arbeta med passersystem, eftersom Vi vill som tidigare tillhandahålla ett enda verktyg för att sätta upp rapporter för både utvecklaren och slutanvändaren.

    Datalayoutdiagram (1C SKD)- en bekväm designer för att skapa komplexa rapporter i 1C:Enterprise-programvaruprodukter som bidrar till utveckling och spårning av produktionsautomation, vilket gör att de kan göras så flexibla och vackra som möjligt på ett minimum av tid. En ytterligare fördel med Data Composition Scheme (1C SKD) är den automatiska genereringen av ett kontrollerat rapportformulär och med vidareutveckling av detta område är det en viktig faktor vid val av metod för att ta fram en rapport. Men på grund av komplexiteten i strukturen för Data Composition Scheme (1C SKD) och det enorma antalet inställningar, leder det ofta till längre utveckling av rapporten än genom "output form designer". Därför måste en 1C-programmerare förstå alla krångligheterna i Data Composition Scheme (1C DCS) för att ytterligare påskynda utvecklingstiden för att generera rapporter.

    Låt oss titta på de tre första flikarna i Data Composition Scheme (1C SKD) - datauppsättning, datauppsättningsanslutningar och beräknade fält.

    Datauppsättning i 1C SKD

    Datauppsättningen innehåller möjligheten att skapa tre objekt - en fråga, ett objekt och en förening, låt oss ta en närmare titt på vart och ett av dem:

    Detta är en vanlig fråga som genereras med knappen Frågebyggare. Om Autofyll-flaggan är inställd, kommer alla valda detaljer automatiskt att inkluderas i fälten i datamängden. Det är också möjligt att anpassa ifyllningen av fält i begäran på fliken Datasammansättning, där det finns tre flikar:

    Tabeller, här väljs tabellerna som kommer att delta i genereringen av rapporten, vanligtvis väljs standarddata, eftersom vi på fliken Tabeller och fält redan har valt de dokument, kataloger, register vi behöver...

    Fält, här väljer vi de objekt som ska ingå i rapporten, barnflaggan indikerar om det kommer att finnas tillgängliga underordnade element för objektet eller inte, det är logiskt att för sträng, numerisk och liknande data kommer det inte att gå att ställa in flaggan till True.

    Villkor, här väljer vi de objekt som kan användas under förhållanden i passerkontrollsystemet.

    En del av arbetet görs i datasammansättningsschemat, och en del av det görs programmatiskt; låt oss titta på ett enkelt exempel:

    Först skapar vi ett layoutdiagram för dokumentets datalayout och kallar det SKD (till exempel: 1C SKD), i det skapar vi ett datamängdsobjekt, sedan fyller vi i fälten, till exempel har vi ett dokument med en tabelldel av varor med detaljer - nomenklatur, kvantitet och pris.

    Låt oss lägga till tre fält och fylla i varje kolumn med namnet på detaljerna, de återstående kolumnerna kommer att fyllas i automatiskt:

    Låt oss skapa en knapp på dokumentformuläret och beskriva funktionsmekanismen i kontrollerade former:

    &OnClient

    Procedur Print()

    OurReport = PrintOnServer(); //anropar funktionen på servern

    OurReport.Show(); //visa den genererade rapporten

    Slut på procedur

    &På server

    Funktion PrintOnServer()

    DocumentObject = FormAttributeValue(“Objekt”);

    //vi placerar tabelldelen Produkter i en struktur med namnet ProductsSKD på samma sätt som vi angav i själva SKD namnet på objektet som innehåller data

    DataSet = ny struktur;

    DataSet.Insert(“ProductsSKD”, DocumentObject.Products);

    //vi får vår layout och ställer in standardinställningarna så att alla inställningar för rapportutdata tas från vår layout

    OurLayout = DocumentObject.GetLayout(“SKD”);

    Inställningar = OurLayout.DefaultSettings;

    //skapa en datalayoutlayout med våra inställningar

    LayoutLinker = newDataLayoutLayoutLinker;

    LayoutLayout = LayoutComposer.Execute(OurLayout, Settings);

    //utföra datasammansättning med vår datamängd

    DataCompositionProcessor = newDataCompositionProcessor;

    DataCompositionProcessor.Initialize(LayoutLayout, DataSet);

    //Vi skapar ett kalkylark och visar vår rapport i den

    ReportDocument = New TabularDocument;

    OutputProcessor = New OutputProcessorDataCompositionResultInTabularDocument;

    OutputProcessor.SetDocument(ReportDocument);

    OutputProcessor.Output(DataCompositionProcessor);

    Returnera DocumentReport;

    EndFunction

    Om du vill kan du få områden med vilken annan layout som helst och även visa dem i den här rapporten, till exempel har vi en standardlayout för att generera en betalningsorder och rubriken är mycket väl skapad i den, för att inte göra onödigt arbete, vi ska bara först få layouten, visa rubriken, sedan kommer vi att generera och visa vår rapport om passerkontrollsystemet.

    HANDLA OM enande

    Vi kan placera våra frågor och objekt i den, men till skillnad från en anslutning lägger den helt enkelt till tabeller till varandra, det vill säga om vi kopplar ihop två identiska tabeller kommer vi att sluta med en, och när den kombineras kommer den att fördubblas, låt oss titta vid ett enkelt exempel:

    Vi har bord:

    Vid kommunikation får vi:

    Och i kombination:

    Låt oss nu titta på att fylla i kolumner i datamängder (vi hoppar över några, eftersom de är relaterade till andra flikar; vi återkommer till dem i framtida artiklar):

    - fält, ange det allmänna namnet på attributet;

    ­­- väg, ange namnet på de uppgifter som vi kommer att kontakta det med i passersystemet, till exempel i Beräknade fält;

    - titel, ange namnet på attributet som kommer att visas i rapporten;

    - fältbegränsning, ange tillgängligheten för detta krav;

    - Begränsning av detaljer, vi indikerar tillgängligheten av underordnade element, det är viktigt att om tillgängligheten av detaljer anges, så kommer själva fältet att vara tillgängligt, kanske kommer denna mekanik att ändras i framtida utgåvor;

    - uttryck med vilket fältrepresentationen beräknas, det är bekvämt att använda när vi behöver ändra utdata av detaljer lite, till exempel behöver vi efter namnet nomenklatur visades stock, där den finns, fyll sedan i följande: Artikel + "finns på lagret" + Lager. Jag upprepar att tillgången till detaljerna sker genom det namn som anges i kolumnen väg;

    - uttrycksordning, en bekväm mekanism för att ställa in rapportbeställning, där villkoret kan ställas in manuellt, i likhet med föregående punkt, men som praxis visar fungerar denna mekanism ofta inte som vi skulle vilja, och jag råder dig att använda standardsortering;

    - värde typ, anger typen av värde för attributet, detta måste fyllas i om du använder följande fält;

    - tillgängliga värden, fungerar endast när den är full värde typ, öppna formuläret och i kolumnen Menande vi anger elementet som behöver ändras, beroende på typen kan det vara fördefinierade objekt eller numeriska, till exempel detaljer har enkla värden, i presentation Vi anger vad vi behöver ändra till, ett exempel på en boolesk typ:

    - dekor– standardinställningar för fältformat, liknande inställningar i hanterade formulär, gör att du kan anpassa utmatningen av vissa detaljer mer exakt och vackert.

    Datauppsättningsanslutningar i 1C SKD

    Här är den bara installerad vänster gå med, enligt en princip liknande anslutningar i förfrågningar, i kommunikationskälla ange huvudtabellen för anslutningen, i mottagare ytterligare. I uttryckskälla Och uttrycksmottagare Vi anger detaljerna för kommunikationen. Vi kommer att titta på de återstående kolumnerna mer i detalj när vi tittar på fliken. alternativ. Om det inte finns någon ytterligare anslutning med parametrar, rekommenderas det att göra anslutningen i begäran, detta kommer att påskynda rapporten.

    I ljuset av den kommande versionen av 8.2.14 kommer jag att försöka beskriva några nya funktioner i datasammansättningssystemet.

    Öppna datalayoutdiagrammet, helst i en extern rapport, för att göra redigeringen enklare.

    Vi lägger till en datauppsättning av frågetypen och skriver, antingen manuellt eller med hjälp av frågedesignern, en enkel fråga:

    1. Ställ in en begäran i passersystemet.

    2. Ställ in beräknade fält i passersystemet

    3. Konfigurera datalayouten på fliken Inställningar

    4. Starta 1C Enterprise 8.2.14. Öppna rapporten. Vi formar, vi tar emot.

    Beskrivning av själva de nya funktionerna:

    1. Det aktuella datumet()

    Returnerar systemdatumet. När du skapar en layoutlayout, i alla uttryck som finns i layouten, ersätts funktionen CurrentDate() med värdet för det aktuella datumet.

    2. COMPUTEEXPRESSION()

    Syntax:

    BeräknaUttryck(<Выражение>, <Группировка>, <ОбластьВычисления>, <Начало>, <Конец>, <Сортировка>, <ИерархическаяСортировка>, <ОбработкаОдинаковыхЗначенийПорядка>)

    Beskrivning:

    Funktionen är utformad för att utvärdera ett uttryck inom ramen för någon gruppering.

    Funktionen tar hänsyn till urvalet av grupperingar, men tar inte hänsyn till hierarkiska urval.

    Funktionen kan inte tillämpas på en gruppering i gruppvalet för den grupperingen. Till exempel, i valet av Nomenklaturgruppen kan du inte använda uttrycket CalculateExpression("Sum(SumOmsättning)", "TotalTotal") > 1000. Men ett sådant uttryck kan användas i hierarkiskt urval.

    Om slutposten föregår startposten anses det inte finnas några poster för beräkning av detaljerade data och beräkning av aggregatfunktioner.

    Vid beräkning av intervalluttryck för en totalsumma (parametern Gruppering är satt till GrandTotal) antas det att det inte finns några poster för beräkning av detaljerade data och beräkning av aggregerade funktioner.

    När ett uttryck för CalculateExpression-funktionen genereras, ersätter layoutkompositören, om ordningsuttrycket innehåller fält som inte kan användas i gruppering, funktionen CalculateExpression med NULL.

    alternativ

    <Выражение>

    Typ: Sträng. Uttrycket som ska utvärderas.

    <Группировка>

    Typ: Sträng. Innehåller namnet på den gruppering i vilken uttrycket ska utvärderas. Om en tom sträng används som grupperingsnamn kommer beräkningen att utföras i samband med den aktuella grupperingen. Om GrandTotal-strängen används som gruppnamn, kommer beräkningen att utföras i samband med totalsumman. Annars kommer beräkningen att utföras inom ramen för den överordnade grupperingen med samma namn.

    Till exempel:

    Sum(Sales.SumTurnover)/Calculate(“Sum(Sales.SumTurnover)”, “Total”)

    I det här exemplet blir resultatet förhållandet mellan beloppet för fältet Sales.SumOmsättning för grupperingsposten och beloppet för samma fält i hela layouten;

    <ОбластьВычисления>

    Typ: Sträng. Parametern kan ha följande värden:

    • GeneralTotal - uttrycket kommer att beräknas för alla grupperingsposter.
    • Hierarki - Uttrycket kommer att utvärderas för den överordnade hierarkiska posten om det finns en, och för hela grupperingen om det inte finns någon överordnad hierarkisk post.
    • Gruppering - uttrycket kommer att utvärderas för den aktuella grupperingsposten.
    • Icke-resursgruppering - när man beräknar en funktion för en grupppost för resurs, kommer uttrycket att utvärderas för den första gruppposten i den ursprungliga grupperingen.

    Vid beräkning av en funktion CalculateExpression() med värdet Non-Resource Grouping för gruppposter som inte är resursgrupperingar, beräknas funktionen på samma sätt som den skulle beräknas om parametervärdet var lika med Grouping-värdet.

    Layoutbyggaren för datasammansättning placerar ett uttryck i layouten som beräknas med hjälp av funktionen när den genererar en datasammansättningslayout när resursfältet matas ut genom vilket gruppering utförs till layouten. CalculateExpression(), som indikerar parametern Non-Resource Grouping. För andra resurser placeras de vanliga resursuttrycken i resursgrupperingen.

    <Начало>

    Typ: Sträng. Indikerar från vilken post fragmentet ska börja, i vilka aggregerade uttrycksfunktioner som ska beräknas och från vilken post som ska erhållas fältvärden utanför aggregerade funktioner. Värdet kan vara något av följande:

    <Конец>

    Typ: Sträng. Anger till vilken post fragmentet ska fortsätta, i vilken uttryckets aggregerade funktioner ska beräknas. Värdet kan vara något av följande:

    • Först. Det är nödvändigt att erhålla den första grupperingsposten. Efter ordet inom parentes kan du ange ett uttryck, vars resultat kommer att användas som en offset från början av grupperingen. Det resulterande värdet måste vara ett heltal större än noll. Till exempel First(3) – ta emot den tredje posten från början av grupperingen.

    Om den första posten ligger utanför grupperingen anses det inte finnas några poster. Till exempel, om det finns 3 poster, och du vill få First(4), så anses det att det inte finns några poster.

    • Sista. Du måste få den sista grupperingsposten. Efter ordet inom parentes kan du ange ett uttryck, vars resultat kommer att användas som en offset från slutet av grupperingen. Det resulterande värdet måste vara ett heltal större än noll. Till exempel Last(3) – tar emot den tredje posten från slutet av gruppen.

    Om den sista posten ligger utanför grupperingen anses det inte finnas några poster. Till exempel, om det finns 3 poster, och du vill få Last(4), så anses det att det inte finns några poster.

    • Tidigare. Du måste hämta den tidigare grupperingsposten. Efter ordet inom parentes kan du ange ett uttryck, vars resultat kommer att användas som en förskjutning från den aktuella grupperingsposten. Till exempel Previous(2) – hämtar föregående från föregående post.

    Om den föregående posten går utöver grupperingen (till exempel för den andra grupperingsposten måste du hämta Previous(3), då erhålls den första grupperingsposten.

    Vid hämtning av den tidigare posten för en grupperingssumma anses den första posten erhållas.

    • Nästa. Du måste få nästa grupperingspost. Efter ordet inom parentes kan du ange ett uttryck, vars resultat kommer att användas som en förskjutning framåt från den aktuella grupperingsposten. Till exempel Next(2) – hämta nästa från nästa post.

    Om nästa post går utöver grupperingen, anses det inte finnas några poster. Till exempel, om det finns 3 poster och Next() tas emot för den tredje posten, anses det inte finnas några poster.

    När nästa post tas emot för grupperingssumman anses det inte finnas någon post.

    • Nuvarande. Du måste få den aktuella posten.

    Vid hämtning för en grupperingssumma erhålls den första posten.

    • BoundaryValue. Behovet av att få en post med det angivna värdet. Efter ordet LimitingValues ​​inom parentes måste du ange uttrycket med värdet som du vill starta fragmentet av, det första ordningsfältet.

    Den första posten vars beställningsfältvärde är större än eller lika med det angivna värdet kommer att returneras som posten. Till exempel, om fältet Period används som beställningsfält och det har värdena 01/01/2010, 02/01/2010, 03/01/2010 och du vill få LimitingValue(DateTime(2010) , 1, 15)), då erhålls en post med datum 02/01. 2010.

    <Сортировка>

    Typ: Sträng. Listar uttryck, separerade med kommatecken, som beskriver ordningsreglerna. Om det inte anges, utförs beställningen på samma sätt som för den gruppering för vilken uttrycket utvärderas. Efter varje uttryck kan du specificera nyckelord Stig (för ordning i stigande ordning), fallande (för ordning i fallande ordning) och AutoOrder (för ordning av referensfält efter de fält som du vill sortera det refererade objektet efter). Ordet automatisk ordning kan användas med både ordet stigande och fallande.

    <ИерархическаяСортировка>

    Typ: Sträng. Samma som alternativet Sortera. Används för att organisera hierarkiska poster. Om det inte anges genererar layoutkompositören beställningen enligt den ordning som anges i parametern Sortera.

    <ОбработкаОдинаковыхЗначенийПорядка>

    Typ: Sträng. Anger regeln för att fastställa föregående eller nästa post om det finns flera poster med samma ordningsvärde:

    • Separat betyder att en sekvens av ordnade poster används för att fastställa föregående och nästa post. Standardvärde.
    • Tillsammans innebär att föregående och nästa post bestäms baserat på värdena för ordningsuttrycken.

    Till exempel, om den resulterande sekvensen är ordnad efter datum:

    datum Fullständiga namn Menande
    1 1 januari 2001 Ivanov M. 10
    2 2 januari 2001 Petrov S. 20
    3 3 januari 2001 Sidorov R. 30
    4 4 januari 2001 Petrov S. 40

    Om parametervärdet är Separat, då:

    § den föregående posten till post 3 kommer att vara post 2.

    § om beräkningsfragmentet är definierat som Aktuell, Aktuell (respektive parametrarna Start och Slut), kommer detta fragment för post 2 att bestå av en post 2. Uttrycket CalculateExpression(“Summa (Value)”, Current, Current) kommer att vara lika med 20.

    Om parametervärdet är Together, då:

    § den föregående posten till post 3 kommer att vara post 1.

    § om beräkningsfragmentet är definierat som Aktuell, Aktuell (respektive parametrarna Start och Slut), så kommer detta fragment för post 2 att bestå av post 2 och 3. Uttrycket CalculateExpression(“Sum (Value)”, Current, Current) kommer att vara lika med 50.

    När du anger ett parametervärde lika med Tillsammans kan du i start- och slutparametrarna inte ange en offset för positionerna First, Last, Previous, Next.

    CalculateExpression(“Sum(SumOmsättning)”, “First”, “Current”)

    Om du vill få grupperingsvärdet på föregående rad kan du använda följande uttryck:

    CalculateExpression("Rate", "Föregående")

    Lista ny funktioner:

    CalculateExpressionWithGroupArray(<Выражение>, <ВыражениеПолейГруппировки>, <ОтборЗаписей>, <ОтборГруппировок>) –

    Funktionen returnerar en array, vars varje element innehåller resultatet av att utvärdera ett uttryck för gruppering efter det angivna fältet.

    CalculateExpressionWithGroupValueTable(<Выражения>, <ВыражениеПолейГруппировки>, <ОтборЗаписей>, <ОтборГруппировок>) –

    Funktionen returnerar en tabell med värden, vars varje rad innehåller resultatet av utvärdering av uttryck för gruppering efter det angivna fältet

    ValueFilled(<Выражение>) – Returnerar True om värdet är annat än standardvärdet av denna typ, annat än NULL, annat än en tom referens, annat än Odefinierat. Booleska värden kontrolleras för NULL. Strängar kontrolleras för frånvaron av tecken som inte är blanksteg

    Formatera(<Выражение>, <Форматная строка>) – Ta emot en formaterad sträng med det godkända värdet. Formatsträngen ställs in i enlighet med formatsträngen i 1C:Enterprise-systemet.

    Delsträng(<Выражение>, <Начальные символ>, <ДлинаПодстроки>) – Denna funktion är utformad för att extrahera en delsträng från en sträng.

    Linjelängd(<Выражение>) – Funktionen är utformad för att bestämma längden på en sträng. Parameter - stränguttryck

    Linje(<Выражение>) – Om en array skickas som en parameter returnerar funktionen en sträng som innehåller strängrepresentationer av alla arrayelement, åtskilda av tecknen "; ". Om en värdetabell skickas som en parameter, returnerar funktionen en sträng som innehåller strängrepresentationerna för alla rader i värdetabellen, med cellrepresentationerna för varje rad separerade av tecknen "; ", och raderna är en radmatningssymbol. Om något element har en tom strängrepresentation, visas strängen istället för dess representation<Пустое значение>.

    Hej kära läsare! Vi har ytterligare en lektion om grunderna i layoutsystemet. I bekantade du dig med funktionerna i uttrycksspråket SKD, såg funktionerna i layoutsystemet och förstod även de grundläggande inställningarna för layoutfälten. Nu ska vi titta på nytt material. Gå!

    Ytterligare inställningar för ACS-fält.

    Kolumn "Värde typ" Låter dig ange datatypen för layoutfältet. Varför ange typen, till exempel för fältet "Nomenklatur", om du redan vet vilken typ det är? Detta är nödvändigt om layoutfältet är av en sammansatt typ. Du kan välja en specifik typ, och när du väljer detta fält kommer värden av denna typ att väljas.

    Kolumn "Tillgängliga värden" låter dig ange de värden som är tillgängliga för val och begränsa användarens val till vissa gränser.

    Kolumn "Dekor" låter dig specificera utformningen av ett layoutfält utan att använda layouter. Du kan ange teckensnittsfärg, ramfärg, textorientering, etc.

    Kolumn "Redigeringsalternativ" Låter dig ange hur layoutfältet ska redigeras. Du kan till exempel ange ett snabbt urval av element från en lista i ett urval. Som standard ärver ett layoutfält alla redigeringsalternativ från metadataobjektet.

    Beräknade fält

    På fliken "Beräknade fält" i datasammansättningen kan du skapa dina egna beräknade fält.

    Varför behöver du beräknade fält när du kan skapa dem på frågenivå? Alla fält kan inte beskrivas med en fråga. Om du behöver skapa ett komplext fält från olika datamängder, till exempel en fråga och ett objekt, kan du inte klara dig utan beräknade fält. Du kan inte lägga till ett datasammansättningsfält om datakällan är en fråga och autofyll är aktiverat, men med hjälp av beräknade fält kan du lägga till så många fält du vill.

    I kolumnen "Uttryck" i det beräknade fältet måste du skriva ett godtyckligt uttryck som använder datasammansättningsfälten och kommer åt deras sökväg (kolumnen "Sökväg" på fliken "Datauppsättningar"). Antingen kan du använda matematiska transformationsfunktioner eller komma åt funktionerna i vanliga moduler. Låt oss till exempel skriva namnet på det beräknade fältet "Avvikelse" i kolumnen "Datasökväg" och i fältet "Uttryck" följande:

    Belopp - Pris* Antal

    Titta på en annan, och du kan också ladda ner med dessa funktioner.

    I huvudsak har beräknade fält samma inställningar som layoutfält. Det enda som saknas här är kolumnen Hierarkigrupp. När du skriver beräknade fält kan du inte hänvisa till andra beräknade fält.

    Hur överför man parametrar och val till en rapport byggd på ett passersystem utan att skapa ett rapportformulär?

    &OnClient // Skickar parametrar till ACS-rapporten Procedur Kommandobearbetning(Kommandoparameter, Kommandoexekveringsparametrar) Val = Ny struktur("Nomenklatur" , Kommandoparameter) ; FixedSettings = GetFixedSettings() ; FormParameters = New Structure( "Format vid öppning, Selection, Option Key, FixedSettings", Sanning , Urval, "Alternativ för försäljningsrapport", FixedSettings); OpenForm( "Report.SalesReport.Form", FormParameters); EndProcedure &OnServer Funktion GetFixedSettings()SalesReport = Rapporter. Försäljningsrapport. Skapa() ; SKD = ​​Försäljningsrapport. DataCompositionSchema; Inställningar = SKD. Standardinställningar; Periodens början = Inställningar. Dataparametrar. FindParameterValue( NewDataCompositionParameter("BeginPeriod" ) ); Början av perioden. Value = StartMonth(CurrentDate()) ; Början av perioden. Användning = Sant ; Periodens början = Inställningar. Dataparametrar. FindParameterValue( NewDataCompositionParameter("EndPeriod") ); Periodens slut. Value = EndMonth(CurrentDate()) ; Periodens slut. Användning = Sant ; Återgå Inställningar; EndFunction // GetFixedSettings()

    Hur centrerar man kolumnrubriker i en ACS-rapport?

    Du måste ställa in två parametrar i fältet "Design" på fliken "Datauppsättningar":

    Horisontell position: Center Vertikal position: Center

    Även på fliken "Inställningar" längst ner hittar du en annan flik: "Villkorligt utseende". Där för varje gruppering, parameter osv. du kan ställa in designen som du vill.

    Det verkar som att jag har berättat allt för dig! Som du kommer ihåg har du möjlighet att ställa frågor om du har några. Jag ska försöka svara. Jag planerar att skriva fler artiklar om detta ämne i framtiden, så glöm inte att prenumerera på våra webbplatsuppdateringar så att du inte missar något! Dessutom kommer jag definitivt att göra ett test för att förstärka materialet från den här lektionen.

    I slutet av artikeln vill jag rekommendera dig en gratis från Anatoly Sotnikov. Detta är en kurs från en erfaren programmerare. Den kommer att visa dig på separat basis hur du bygger rapporter i passerkontrollsystemet. Du behöver bara lyssna noga och komma ihåg! Du får svar på följande frågor:
    • Hur skapar man en enkel listrapport?
    • Vad är kolumnerna Fält, Sökväg och Titel på fliken "Fält" för?
    • Vilka är begränsningarna för layoutfält?
    • Hur konfigurerar man roller korrekt?
    • Vilka är rollerna för layoutfält?
    • Var kan jag hitta fliken datasammansättning i en fråga?
    • Hur konfigurerar man parametrar i passersystemet?
    • Det blir ännu mer intressant...
    Du kanske inte ska försöka surfa på Internet själv för att leta efter nödvändig information? Dessutom är allt klart för användning. Bara att börja! Alla detaljer om vad som finns i de kostnadsfria videolektionerna

    I denna korta notering vill jag visa hur du kan sammanfatta värden på olika grupperingsnivåer i en rapport med hjälp av ett datasammansättningssystem.
    Som visas i bilden, endast på grupperingsnivån "Artikelgrupper", beräknas resursen "Beställning", den visar hur mycket som behöver beställas för den aktuella varugruppen baserat på vissa villkor:


    Detta värde kan endast beräknas på denna grupperingsnivå, eftersom det inte finns några värden över eller under att beräkna. Till exempel, på nivån för detaljerade poster, finns det inga uppgifter om den maximala kvantiteten i en grupp, eftersom dessa uppgifter endast är giltiga för gruppen som helhet och inte för dess enskilda komponenter.

    Följaktligen är det nu nödvändigt att beräkna summorna för ovanstående grupperingar ("Lager", "Lagertyper") och den totala summan.
    För att göra detta, använd funktionen CalculateExpressionWithGroupArray:
    EVALUATE EXPRESSIONWITHGROUPARRAY (EVALEXPRESSIONWITHGROUPARRAY)
    Syntax:
    EvaluateExpressionWithGroupArray(,)
    Beskrivning:
    Funktionen returnerar en array, vars varje element innehåller resultatet av att utvärdera ett uttryck för gruppering efter det angivna fältet.
    Layoutsammansättaren, när den genererar en layout, konverterar funktionsparametrar till termer av datasammansättningslayoutfält. Till exempel kommer fältet Konto att konverteras till DataSet.Account.
    När layoutbyggaren genererar uttryck för utdata från ett anpassat fält vars uttryck endast innehåller funktionen CalculateArrayWithGroupArray() genererar utdatauttrycket så att utdatainformationen ordnas. Till exempel, för ett anpassat fält med uttrycket:

    CalculateExpressionWithGroupArray("Amount(AmountTurnover)", "Motpart")
    Layoutbyggaren kommer att generera följande uttryck för utdata:

    ConnectRows(Array(Order(CalculateExpressionWithGroupingValueTable("View(Sum(DataSet.AmountTurnover)),Sum(DataSet.AmountTurnover)",,"DataSet.Account"),"2")))

    Alternativ:

    Typ: Sträng. Uttrycket som ska utvärderas. Sträng, till exempel Amount(AmountTurnover).

    Typ: Sträng. Grupperingsfältuttryck – uttryck för grupperingsfält, separerade med kommatecken. Till exempel Entreprenör, Part.

    Typ: Sträng. Ett uttryck som beskriver valet som tillämpas på detaljposter. Uttrycket stöder inte användningen av aggregerade funktioner. Till exempel, DeletionFlag = False.

    Typ: Sträng. Ett uttryck som beskriver valet som tillämpas på gruppposter. Till exempel, Amount(AmountTurnover) > &Parameter1.
    Exempel:

    Maximum(CalculateExpressionWithGroupArray("Amount(AmountOmsättning)", "Motpart"));

    En detaljerad beskrivning av funktionssyntaxen finns på http://its.1c.ru/db/v837doc#bookmark:dev:TI000000582
    Nu, för beräkningen, duplicerar vi fältet "Order", med olika värden "Beräkna med...", med hjälp av följande uttryck, notera att på varje högre nivå används värdena för nivåerna under grupperingarna .

    Som ett resultat får vi följande konstruktion: