Criamos um relatório com uma frequência específica no sistema de armazenamento. Parâmetro padrão &Período e problemas em uso

Este artigo discute algumas das características da configuração de um período ao utilizar um Sistema de Composição de Dados (DCS), problemas que surgem devido às diferenças no conceito de período entre um usuário comum e o sistema 1C, e também sugere formas de resolvê-los .
A maioria dos relatórios desenvolvidos utilizando um Sistema de Composição de Dados (DCS) exige que o usuário insira o período para o qual o relatório será construído. Via de regra, no ACS o lançamento do período é organizado por meio de parâmetros, utilizando a seguinte construção, ver. Figura 1 Este método de inserir um período é considerado “clássico”; é descrito em um artigo sobre ITS e outras literaturas dedicadas ao desenvolvimento em 1C, então vamos tomá-lo como base. Vamos considerar como exemplo uma solicitação simples que recebe todos os documentos de Vendas de Bens e Serviços de um determinado período, veja Figura 2 Ao utilizar este relatório o usuário define o período através dos parâmetros, veja. Figura 3 Tudo parece estar correto... MAS há um pequeno problema:

Acontece que a grande maioria dos usuários “entende” o período de forma diferente de 1C “entende”, exemplos:
1). Vamos considerar Figura 3
Do ponto de vista do usuário o período não é especificado, ou seja, ILIMITADO, ou seja, TODOS os documentos sem restrição de data deverão constar no relatório.
“Do ponto de vista” do sistema 1C, o parâmetro-período é definido e ... ambos os seus limites são iguais a 01.01.0001 e apenas documentos com data em branco serão incluídos no relatório, o que na prática significa nem um único documento será incluído.
2). Vamos considerar Figura 4
Do ponto de vista do usuário, o relatório deverá incluir todos os documentos a partir da data 28/01/2010.
“Do ponto de vista” de 1C, o período 28/01/2010 – 01/01/0001 causará uma exceção.

Você pode, claro, tentar explicar ao usuário por que o relatório não exibe os documentos que ele espera ver e como o período é apresentado do “ponto de vista” de 1C, mas esta é uma tarefa ingrata, e é também está errado. Um bom programa deve, antes de tudo, ser fácil de usar, pois o programa existe para o usuário, e não vice-versa, portanto você terá que “ensinar” 1C a entender o período como o usuário o entende, a saber:
1). O início e o fim do período não são especificados -> todos os documentos.
2). Apenas o Início do Período é especificado -> todos os documentos a partir do Início do Período
3). Além disso, verificaremos se Fim do Período >= Início do Período e, se isso não for verdade, assumiremos que Fim do Período não está especificado, ou seja, 2).
Com base no exposto acima, a expressão para o parâmetro Data de término ficará assim:

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

A forma final do nosso design de seleção de período é mostrada em Figura 5

Ao criar relatórios em um sistema de controle de acesso, muitas vezes é necessário exibir uma seleção de período no formulário do relatório, para que você não precise inserir datas manualmente, mas sim selecionar em uma lista de períodos padrão, como: “Ano” , “Mês”, “Semana”, etc. Para parâmetros do tipo Data, você só pode especificar “Início deste ano, mês, etc.”, mas “Fim” não é fornecido.

Acontece que, dos tipos de dados, apenas o tipo “Data de início padrão” está disponível, mas também quero o tipo “Data de término padrão”.

Existe uma maneira de contornar isso.

Vamos criar um novo parâmetro, chame-o de “Período”
Defina este parâmetro para o tipo “Período padrão”
No campo “Expressão” dos parâmetros “Início do Período” e “Fim do Período”, que são utilizados na solicitação, defina as expressões “ &Período.DataInício" e " &Período.Data de término” respectivamente.

Mas há uma ligeira sutileza. Se usarmos tabelas virtuais na consulta, provavelmente o relatório irá parar de funcionar e uma mensagem de erro como “Erro ao processar a visualização, tipo incompatível, número do parâmetro...” será exibida.

Para evitar isso, você precisa remover todos os parâmetros da tabela virtual.

E adicione-os às tabelas da aba “Composição de Dados”.

Para que os parâmetros sejam exibidos nas configurações do relatório rápido, vamos habilitar o sinalizador correspondente para os parâmetros do relatório.

Agora a seleção do período no formulário do relatório fica assim.

Vamos criar um relatório com um conjunto de dados de consulta:

SELECIONE OS PRODUTOS NOS ARMAZÉNS Restantes. Armazém, MercadoriasEmArmazénsRestos. Nomenclatura, Produtos em Armazéns Restantes. QuantidadeSaldo DO Registro de Acumulação. ProdutosEm Armazéns. Restos(&MyDate,) AS ProdutosEmArmazénsRestos

Agora vamos para a aba de parâmetros e ver que o sistema, além do nosso parâmetro &MyDate, também criou o parâmetro &Period.
Para monitorar visualmente os períodos, criaremos um formulário de relatório principal e nele colocaremos um campo de tabela com dados: Configurações Composer.Settings.DataParameters

Vamos salvar o relatório e abri-lo na empresa. No campo da tabela com parâmetros, apenas o parâmetro &Period é exibido:

Conseqüentemente, qualquer alteração neste parâmetro não dará o resultado desejado.

Por que o parâmetro &MyDate não está disponível? Claro, porque na aba de parâmetros ele tem uma caixa de seleção marcada Limitação de disponibilidade.

Desmarque a caixa. Agora vemos ambos nos parâmetros disponíveis. Somente ao gerar o relatório veremos que o relatório reage ao parâmetro &Period, e não ao &MyDate.

Neste exemplo, a coisa mais simples a fazer é renomear o parâmetro &MyDate na solicitação para &Period e obter o resultado desejado. Mas talvez você tenha uma consulta na qual o parâmetro &Period já tenha sido utilizado, ou suas visões religiosas não permitam o uso deste parâmetro, em qualquer caso, você pode resolver o problema assim:

Atualização do usuário Vaia:

O principal problema ao utilizar parâmetros “padrão” (adicionados pelo sistema) é que ao utilizar diversas tabelas virtuais em um relatório, se este parâmetro for definido, seu valor será utilizado em todos os outros casos ao invés dos “próprios”.

Deixe-me lhe dar um exemplo:

SELECT EmployeesSP.Employee, WorkersSP.ReasonChangesState, WorkersSP.Period, WorkersSPAnotherDate.Period AS Period2, WorkersSPAnotherDate.ReasonChangesState AS ReasonChangesState2 FROM RegisterInformation.EmployeesOrganizations.SliceLast(&Period , Employee = &Employee ) AS Work nikkiSP CONEXÃO ESQUERDA Cadastro de informações.Funcionários de organizações.Fatia do mais recente(&OtherDate ,) AS EmployeesSPAnotherDate BY EmployeesSP.Employee = EmployeesSPAnotherDate.Employee

Na segunda subconsulta, o valor do parâmetro PERIOD “padrão” será usado como parâmetro de data do intervalo, em vez do valor OtherDate.

Essa “falha” será observada mesmo se a segunda subconsulta for enviada para o segundo conjunto de dados e vinculada usando ACS. A opção de usar na segunda requisição uma expressão do tipo “ADDATE(&Period, MONTH, -1)” também não funcionará, o mês não será subtraído. Mas renomear o parâmetro “Period” na solicitação para, por exemplo, “FirstDate” resolve esse problema.

Aliás, exatamente o mesmo problema é observado com tabelas virtuais de acumulação e registros contábeis, utilizadas para obter, por exemplo, giro. Aí o sistema adiciona os parâmetros “Início do Período” e “Fim do Período”.
Assim, no caso de solicitações de complexidade ainda que ligeiramente aumentada, faz sentido desligar a disponibilidade e a utilização de “períodos padrão”.

Então, vamos começar.

Para simplificar, entendendo o exemplo, construiremos um simples registro de acumulação circulante.

No meu caso, este é o registro de acumulação “Contabilidade de Trabalhos em Andamento”.

Por exemplo, indicaremos seus parâmetros de forma rígida (não através da imposição suave de parâmetros no sistema de controle de acesso):

Observe que a frequência da mesa virtual é “Record”.

Mas, como dito acima, precisamos do período em termos de periodicidade, então proponho calcular o campo “Período” da seguinte forma (não muito legal, mas não vi opções melhores):

Como pode ser visto na captura de tela, para a solicitação é passado um parâmetro que o usuário especifica no formulário: O valor da enumeração "Frequência" - esta enumeração é encontrada em quase todas as soluções padrão.

Indicaremos seus tipos disponíveis na aba “Parâmetros”:

Com essa configuração formatamos nosso período para que tudo fique lindo e agradável aos olhos)

Aqui estão os próprios formatos:

Mês: DF="MMMM aaaa "y.""

Dia: DF = dd.MM.aaaa

Semana: DF = ""Semana a partir de "dd.MM.yyyy"

Trimestre: DF = "para "trimestre" aaaa "y.""

Ano: DF = "aaaa "y.""

Década: DF = ""Década com "dd.MM.yyyy"

Semestral: DF = ""Semestral a partir de" dd.MM.yyyy"

Isso é tudo. O resultado é uma imagem maravilhosa:

Algumas características de configuração do período no sistema de controle de acesso.

A maioria dos relatórios desenvolvidos utilizando um Sistema de Composição de Dados (DCS) exige que o usuário insira o período para o qual o relatório será construído.

Via de regra, no ACS, o lançamento do período é organizado por meio de parâmetros, utilizando a seguinte construção, ver. Este método de lançamento do período é considerado “clássico” e é descrito em um artigo sobre ITS e outra literatura dedicada ao desenvolvimento em 1C, portanto; vamos tomar isso como base. Vamos considerar como exemplo uma solicitação simples que recebe todos os documentos de Vendas de Bens e Serviços de um determinado período, veja

Ao utilizar esse relatório o usuário define o período através dos parâmetros, veja. Tudo parece estar correto..., MAS há um pequeno problema:

Acontece que a grande maioria dos usuários “entende” o período de forma diferente de 1C “entende”, exemplos:

Do ponto de vista do usuário o período não é especificado, ou seja, ILIMITADO, ou seja, TODOS os documentos sem restrição de data deverão constar no relatório.

“Do ponto de vista” do sistema 1C, o parâmetro-período é definido e ... ambos os seus limites são iguais a 01.01.0001 e apenas documentos com data vazia serão incluídos no relatório, o que na prática significa nem um único documento será incluído.

Do ponto de vista do usuário, o relatório deverá incluir todos os documentos a partir da data 28/01/2010.

“Do ponto de vista” de 1C, o período 28/01/2010 - 01/01/0001 causará uma exceção.

1). O início e o fim do período não são especificados -> todos os documentos.

2). Somente o Início do Período é especificado -> todos os documentos a partir do Início do Período

3). Além disso, verificaremos se Fim do Período >= Início do Período e, se isso não for verdade, assumiremos que Fim do Período não está especificado, ou seja, 2).

Com base no exposto acima, a expressão para o parâmetro Data de término é:

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

ENTÃO DATAHORA(3999,12,31)

QUANDO &Período.Data de término<&Период.ДатаНачала

ENTÃO DATAHORA(3999,12,31) DATAHORA(3999,12,31,23,59,59)

&Período.Data de término

A forma final do nosso design de seleção de período é mostrada em

Nota: este mecanismo de configuração de parâmetros destina-se a plataformas mais antigas 1C 8.1 e 8.2 (e as configurações executadas sob seu controle, versões mais antigas da plataforma 1C possuem mecanismos integrados para controlar parâmetros vazios e não há necessidade de recorrer ao mecanismo); descrito neste artigo, além disso, em algumas versões da plataforma 1C, erros e operação incorreta são possíveis.

Pode ser útil ler: