När du skapar rapporter på ett passersystem finns det ofta behov av att visa ett periodval på rapportformuläret, så att du inte behöver ange datum manuellt, utan välja från en lista med standardperioder, såsom: "År" , "Månad", "Vecka" etc. . För parametrar av typen Datum kan du bara ange "Början av detta år, månad, etc.", men "Slut" anges inte.
Saken är att av datatyperna är bara typen "Standard startdatum" tillgänglig, men jag vill också ha "Standard slutdatum".
Det finns ett sätt att komma runt detta.
Men det finns en liten subtilitet. Om vi använder virtuella tabeller i frågan kommer rapporten troligtvis att sluta fungera och ett felmeddelande som "Fel vid bearbetning av vyn, typfel, parameternummer..." kommer att visas.
För att undvika detta måste du ta bort alla parametrar för virtuella tabeller.
Och lägg till dem i tabellerna på fliken "Datasammansättning".
För att parametrarna ska visas i snabbrapportinställningarna, låt oss aktivera motsvarande flagga för rapportparametrarna.
Nu ser periodvalet på rapportformuläret ut så här.
Den här artikeln diskuterar några av funktionerna för att ställa in en period när du använder ett Data Composition System (DCS), problem som uppstår på grund av skillnader i konceptet för en period mellan en vanlig användare och 1C-systemet, och föreslår också sätt att lösa dem .
De flesta rapporter som utvecklas med hjälp av ett Data Composition System (DCS) kräver att användaren anger den period som rapporten ska byggas för. Som regel, i ACS, är periodregistrering organiserad genom parametrar, med hjälp av följande konstruktion, se. Fig.1 Denna metod för att gå in i en period anses vara "klassisk" den beskrivs i en artikel om ITS och annan litteratur som ägnas åt utveckling i 1C, så låt oss ta det som grund. Låt oss som ett exempel betrakta en enkel begäran som tar emot alla dokument Försäljning av varor och tjänster för en viss period, se Fig.2 När denna rapport används ställer användaren in perioden genom parametrarna, se. Fig.3 Allt verkar vara korrekt... MEN det finns ett litet problem:
Saken är att den stora majoriteten av användare "förstår" perioden annorlunda än 1C "förstår" den, exempel:
1). Låt oss överväga Fig.3
Ur användarens synvinkel är perioden inte specificerad, det vill säga UNLIMITED, det vill säga ALLA dokument utan datumbegränsningar ska ingå i rapporten.
"Från 1C-systemets synvinkel" är periodparametern inställd och ... båda dess gränser är lika med 01.01.0001 och endast dokument med ett tomt datum kommer att inkluderas i rapporten, vilket i praktiken betyder att inte ett enda dokument kommer att inkluderas.
2). Låt oss överväga Fig.4
Ur användarens synvinkel bör rapporten innehålla alla dokument från och med datumet 2010-01-28.
"Från 1Cs synvinkel" kommer perioden 2010-01-28 – 01/01/0001 att orsaka ett undantag.
Du kan naturligtvis försöka förklara för användaren varför rapporten inte visar de dokument som han förväntar sig att se och hur perioden presenteras ur 1C:s "synpunkt", men detta är en otacksam uppgift, och det är också fel. Ett bra program bör först och främst vara användarvänligt, eftersom programmet finns till för användaren och inte tvärtom, därför måste du "lära" 1C för att förstå perioden som användaren förstår den, nämligen:
1). Periodens början och Periodens slut anges inte -> alla dokument.
2). Endast periodens början anges –> alla dokument som börjar från periodens början
3). Dessutom kommer vi att kontrollera att Periodens slut >= Periodens början, och om detta inte stämmer kommer vi att anta att Periodens slut inte är specificerat, dvs. 2).
Baserat på ovanstående kommer uttrycket för parametern Slutdatum att se ut så här:
VÄLJ NÄR &Period.EndDate=DATETIME(1,1,1) THEN DATETIME(3999,12,31,23,59,59) ANNAT VÄLJ NÄR &Period.EndDate<&Период.ДатаНачала ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ &Период.ДатаОкончания КОНЕЦ КОНЕЦ
Den slutliga formen av vår tidsvalsdesign visas i Fig. 5
Några funktioner för att ställa in perioden i passerkontrollsystemet.
De flesta rapporter som utvecklas med hjälp av ett Data Composition System (DCS) kräver att användaren anger den period som rapporten ska byggas för.
Som regel, i ACS, är periodinträde organiserad genom parametrar, med hjälp av följande konstruktion, se Denna metod för periodregistrering anses vara "klassisk" den beskrivs i en artikel om ITS och annan litteratur som ägnas åt utveckling i 1C låt oss ta det som grund. Låt oss som ett exempel betrakta en enkel begäran som tar emot alla dokument Försäljning av varor och tjänster för en viss period, se
När du använder denna rapport ställer användaren in perioden genom parametrarna, se Allt verkar vara korrekt... MEN det finns ett litet problem:
Saken är att den stora majoriteten av användare "förstår" perioden annorlunda än 1C "förstår" den, exempel:
Ur användarens synvinkel är perioden inte specificerad, det vill säga UNLIMITED, det vill säga ALLA dokument utan datumbegränsningar ska ingå i rapporten.
"Från 1C-systemets synvinkel" är periodparametern inställd och ... båda dess gränser är lika med 01.01.0001 och endast dokument med ett tomt datum kommer att inkluderas i rapporten, vilket i praktiken betyder att inte ett enda dokument kommer att inkluderas.
Ur användarens synvinkel bör rapporten innehålla alla dokument från och med datumet 2010-01-28.
"Från 1Cs synvinkel kommer perioden 2010-01-28 - 0001-01-01 att orsaka ett undantag.
Du kan naturligtvis försöka förklara för användaren varför rapporten inte visar de dokument som han förväntar sig att se och hur perioden presenteras ur 1C:s "synpunkt", men detta är en otacksam uppgift, och det är också fel. Ett bra program bör först och främst vara användarvänligt, eftersom programmet finns till för användaren och inte tvärtom, därför måste du "lära" 1C för att förstå perioden som användaren förstår den, nämligen:
1). Periodens början och periodens slut anges inte -> alla dokument.
2). Endast periodens början anges -> alla dokument som börjar från periodens början
3). Dessutom kommer vi att kontrollera att Periodens slut >= Periodens början, och om detta inte stämmer kommer vi att anta att Periodens slut inte är specificerat, dvs. 2).
Baserat på ovanstående är uttrycket för parametern Slutdatum:
NÄR &Period.EndDate=DATETIME(1,1,1)
SEDAN DATUMTID(3999;12;31)
NÄR &Period.Slutdatum<&Период.ДатаНачала
SEDAN DATUMTID(3999;12;31) DATUMTID(3999;12;31;23;59;59)
&Period.Slutdatum
Den slutliga formen av vår tidsvalsdesign visas i
Notera: denna mekanism för att ställa in parametrar är avsedd för äldre plattformar 1C 8.1 och 8.2 (och konfigurationer som körs under deras kontroll har inbyggda mekanismer för att kontrollera tomma parametrar och det finns inget behov av att tillgripa mekanismen); beskrivs i den här artikeln, dessutom På vissa versioner av 1C-plattformen är fel och felaktig användning möjliga.
Så låt oss börja.
För enkelhetens skull, för att förstå exemplet, kommer vi att bygga på ett enkelt cirkulerande ackumuleringsregister.
I mitt fall är detta ackumuleringsregistret "Arbetsbokföring".
Till exempel kommer vi att indikera dess parametrar strikt (inte genom mjukt påförande av parametrar på åtkomstkontrollsystemet):
Observera att frekvensen för det virtuella bordet är "Record".
Men, som nämnts ovan, behöver vi perioden när det gäller periodicitet, så jag föreslår att du beräknar fältet "Period" på följande sätt (inte särskilt trevligt, men jag har inte sett några bättre alternativ):
Som framgår av skärmdumpen skickas en parameter till begäran, som användaren anger på formuläret: Värdet på "Frekvens"-uppräkningen - denna uppräkning finns i nästan alla standardlösningar.
Vi kommer att ange dess tillgängliga typer på fliken "Parametrar":
Med den här inställningen formaterar vi vår period så att allt är vackert och tilltalande för ögat)
Här är själva formaten:
Månad: DF="MMMM åååå "å.""
Dag: DF = dd.MM.åååå
Vecka: DF = ""Vecka från "dd.MM.åååå"
Kvartal: DF = "till "kvartal" åååå "å.""
År: DF = "åååå "å.""
Decennium: DF = ""Decennium från "dd.MM.yyyy"
Halvår: DF = ""Halvår från" dd.MM.åååå"
Det är allt. Resultatet är en underbar bild:
Låt oss skapa en rapport med en uppsättning frågedata:
VÄLJ PRODUKTER I LAGER Återstående. Lager, GodsI LagerRemains. Nomenklatur, kvarvarande produkter i lager. Kvantitetsbalans FRÅN Ackumuleringsregistret. Produkter i lager. Remains(&MyDate ,) AS ProductsInWarehousesRemainsLåt oss nu gå till parameterfliken och se att systemet, förutom vår &MyDate-parameter, även har skapat parametern &Period.
För att visuellt övervaka perioderna kommer vi att skapa ett huvudrapportformulär och placera ett tabellfält med data på: Inställningar Composer.Settings.DataParameters 
Låt oss spara rapporten och öppna den i företaget. I tabellfältet med parametrar visas bara parametern &Period:
Följaktligen kommer varje ändring av denna parameter inte att ge det önskade resultatet.
Varför är parametern &MyDate inte tillgänglig? Naturligtvis, för på parameterfliken har han en kryssruta markerad Tillgänglighetsbegränsning.
Avmarkera rutan. Nu ser vi båda i de tillgängliga parametrarna. Först när rapporten genereras kommer vi att se att rapporten reagerar på parametern &Period och inte på &MyDate.
I det här exemplet är det enklaste att göra att byta namn på parametern &MyDate i begäran till &Period och uppnå önskat resultat. Men du kanske har en fråga där parametern &Period redan har använts, eller så tillåter dina religiösa åsikter dig inte att använda den här parametern, i alla fall kan du lösa problemet så här:
VÄLJ PRODUKTER I LAGER Återstående. Lager, GodsI LagerRemains. Nomenklatur, kvarvarande produkter i lager. Kvantitetsbalans FRÅN Ackumuleringsregistret. Produkter i lager. Remains((&MyDate) ,) AS ProductsInWarehousesRemainsUPD från användaren Bua:
Det största problemet när man använder "standard" (systemtillagda) parametrar är att när man använder flera virtuella tabeller i en rapport, om denna parameter är definierad, kommer dess värde att användas i alla andra fall istället för de "egna".
Låt mig ge dig ett exempel:
VÄLJ EmployeesSP.Employee, WorkersSP.ReasonChangesState, WorkersSP.Period, WorkersSPAnotherDate.Period AS Period2, WorkersSPAnotherDate.ReasonChangesStates AS ReasonChangesState2 FROM RegisterInformation.EmliceesOrganizations,SPM Jobba nikkiSP VÄNSTER ANSLUTNING Register of Information.Anställda i Organisationer.Avsnitt av senaste(&OtherDate ,) AS EmployeesSPAnotherDate BY EmployeesSP.Employee = EmployeesSPAnotherDate.EmployeeI den andra underfrågan kommer värdet på parametern "standard" PERIOD att användas som parameter för segmentdatum, snarare än värdet OtherDate.
Detta "fel" kommer att observeras även om den andra underfrågan matas ut till den andra datamängden och länkas med ACS. Alternativet som i den andra begäran använder ett uttryck som "ADDATE(&Period, MONTH, -1)" kommer inte heller att fungera, månaden kommer inte att subtraheras. Men att byta namn på parametern "Period" i begäran till till exempel "FirstDate" löser detta problem.
Förresten, exakt samma problem observeras med virtuella tabeller över ackumulering och redovisningsregister, som används för att få till exempel omsättning. Där lägger systemet till parametrarna "Start of Period" och "End of Period".
Så i fallet med frågor med till och med något ökad komplexitet är det vettigt att stänga av tillgänglighet och användning av "standardperioder".
