Paramètre standard &Période et problèmes d'utilisation. Paramètre standard &Période et problèmes d'utilisation Description des constructions du langage de requête

Créons un rapport avec un ensemble de données de requête :

PRODUITS SÉLECTIONNÉS DANS LES ENTREPÔTS Restant. Entrepôt, GoodsInWarehousesRemains. Nomenclature, Produits dans les Entrepôts Restants. QuantityBalance DU registre d’accumulation. Produits dans les entrepôts. Reste(&MyDate,) AS ProductsInWarehousesRemains

Passons maintenant à l'onglet Paramètres et voyons que le système, en plus de notre paramètre &MyDate, a également créé le paramètre &Period.
Afin de surveiller visuellement les périodes, nous allons créer un formulaire de rapport principal et y placer un champ de tableau contenant des données : Paramètres Composer.Settings.DataParameters

Sauvegardons le rapport et ouvrons-le dans l'entreprise. Dans le champ du tableau avec les paramètres, seul le paramètre &Période est affiché :

Par conséquent, toute modification de ce paramètre ne donnera pas le résultat souhaité.

Pourquoi le paramètre &MyDate n'est-il pas disponible ? Bien sûr, car dans l'onglet paramètres, il a une case cochée Limite de disponibilité.

Décochez la case. Maintenant, nous voyons les deux dans les paramètres disponibles. Ce n'est qu'au moment de la génération du rapport que nous verrons que le rapport réagit au paramètre &Period, et non à &MyDate.

Dans cet exemple, la chose la plus simple à faire est de renommer le paramètre &MyDate dans la requête en &Period et d'obtenir le résultat souhaité. Mais peut-être avez-vous une requête dans laquelle le paramètre &Period a déjà été utilisé, ou vos opinions religieuses ne vous permettent pas d'utiliser ce paramètre, dans tous les cas, vous pouvez résoudre le problème comme ceci :

MISE À JOUR de l'utilisateur Huer:

Le principal problème lors de l'utilisation de paramètres « standards » (ajoutés par le système) est que lors de l'utilisation de plusieurs tables virtuelles dans un rapport, si ce paramètre est défini, sa valeur sera utilisée dans tous les autres cas au lieu des « propres ».

Laisse moi te donner un exemple:

SELECT EmployeesSP.Employee, WorkersSP.ReasonChangesConditions, WorkersSP.Period, WorkersSPAnotherDate.Period AS Period2, WorkersSPAnotherDate.ReasonChangesStates AS ReasonChangesCondition2 FROM RegisterInformation.EmployeesOrganizations.SliceLast(&Period , Employee = &Employee ) AS WorkersSP CONNEXION GAUCHE Registre des informations.Employés des organisations.Tranche du dernier(&AutreDate,) AS EmployeesSPAnotherDate BY EmployeesSP.Employee = EmployeesSPAnotherDate.Employee

Dans la deuxième sous-requête, la valeur du paramètre PERIOD « standard » sera utilisée comme paramètre de date de tranche, plutôt que la valeur OtherDate.

Ce « problème » sera observé même si la deuxième sous-requête est sortie vers le deuxième ensemble de données et liée à l'aide d'ACS. L'option utilisant dans la deuxième requête une expression comme « ADDATE(&Period, MONTH, -1) » ne fonctionnera pas non plus, le mois ne sera pas soustrait. Mais renommer le paramètre « Période » dans la requête, par exemple, « FirstDate » résout ce problème.

D'ailleurs, exactement le même problème est observé avec les tableaux virtuels des registres d'accumulation et comptables, utilisés pour obtenir, par exemple, le chiffre d'affaires. Là, le système ajoute les paramètres « Début de période » et « Fin de période ».
Ainsi, dans le cas de demandes d'une complexité même légèrement accrue, il est judicieux de désactiver la disponibilité et l'utilisation des « périodes standards ».

Registres d'accumulation dans le système 1C:Enterprise sont divisés en deux types : les registres d'accumulation les restes et registres d'accumulation tr/min.

Le type de registre est sélectionné lors de sa création dans le configurateur

Comme leur nom l'indique, certains sont destinés à obtenir des soldes à une certaine date, et les seconds sont destinés à obtenir du chiffre d'affaires sur une période choisie. Selon le type de registre d'accumulation, la plateforme 1C:Enterprise génère un ensemble différent de tables virtuelles. Dans cet article, nous verrons comment travailler avec des tables virtuelles de registres d'accumulation. Pour ce faire, nous allons créer un registre d'accumulation des soldes - ProduitsReste et le registre d'accumulation de révolutions - ProduitsChiffre d'affaires.

Voyons maintenant quelles tables virtuelles la plateforme propose pour chacun de ces registres.

Registre d'accumulation de révolution

Pour plus de clarté, ouvrons et voyons quelles tables sont disponibles pour le registre ProduitsChiffre d'affaires. C'est le tableau du registre lui-même - ProduitsChiffre d'affaires, qui existe physiquement dans la base de données, et une table virtuelle - ProduitsChiffre d'affaires.Chiffre d'affaires

Avec le tableau standard, tout est clair. Regardons de plus près le virtuel.

Chiffre d'affaires des tables virtuelles

Ce tableau permet d'obtenir la rotation des ressources en termes de dimensions. Dans notre cas nous avons deux dimensions : Action Et Produit. Et une ressource - Quantité

Laissez notre registre avoir les entrées suivantes

Revenons au concepteur de requêtes et commençons par simplement sélectionner dans le tableau ProduitsChiffre d'affaires.Chiffre d'affaires tous les champs

En conséquence, la demande ressemblera à ceci :

SELECT ProductsTurnoverTurnover.Warehouse, ProductsTurnoverTurnover.Product, ProductsTurnoverTurnover.QuantityTurnover FROM RegisterAccumulation.ProductsTurnover.Turnover(,) AS ProductsTurnoverTurnover

Le résultat de la requête ressemble à ceci :

C'est-à-dire que nous avons réalisé un chiffre d'affaires en termes de marchandises et d'entrepôts pendant tout ce temps. Supposons que les entrepôts ne nous intéressent pas et que nous souhaitons réaliser un chiffre d'affaires uniquement en termes de marchandises.

Pour ce faire, nous excluons la dimension de la demande Action

SELECT ProductsTurnoverTurnover.Product, ProductTurnoverTurnover.QuantityTurnover FROM RegisterAccumulation.ProductsTurnover.Turnover(,) AS ProductsTurnoverTurnover

et du coup il ne nous restera que deux lignes

Mais en règle générale, il n'est pas nécessaire d'obtenir du chiffre d'affaires pendant toute l'existence du registre. En gros, ils sont nécessaires pour une période précise : mois, trimestre, année, etc. De plus, des sélections par dimensions (Produit, Entrepôt) sont généralement nécessaires. Ceci est réalisé en utilisant paramètres de table virtuelle. Il est pratique de renseigner les paramètres du constructeur. Par bouton Options de table virtuelle Une boîte de dialogue s'ouvre dans laquelle vous pouvez saisir tout ce dont nous avons besoin :

Après cela, notre demande initiale prendra la forme suivante

SELECT GoodsTurnoverTurnover.Warehouse, GoodsTurnoverTurnover.Product, GoodsTurnoverTurnover.QuantityTurnover FROM RegisterAccumulation.GoodsTurnover.Turnover(&Début de période, &Fin de période, Entrepôt = &Entrepôt) AS GoodsTurnoverTurnover

Comme on peut le voir, la différence est que entre parenthèses après le nom de la table virtuelle se trouvent les paramètres qui doivent être renseignés avant d'exécuter la requête.

Ceux qui commencent tout juste à travailler avec des tables virtuelles sont souvent tentés de définir la sélection de la manière habituelle au lieu d'utiliser des paramètres :

FROM RegisterAccumulations.ProductsTurnover.Turnover(,) COMMENT ProductsTurnoverTurnover OÙ ProductsTurnoverTurnover.Warehouse = &Warehouse

Lors du remplissage des paramètres, nous avons manqué Périodicité. Ouvrons la liste et choisissons parmi la masse d'options possibles Mois. Nous supprimerons tous les autres paramètres afin de ne pas nous tromper.

Après cela, nous observons qu'un champ apparaît dans la table des champs Période.

En l'ajoutant aux champs sélectionnés, nous obtenons le texte de requête suivant :

SELECT ProductsTurnoverTurnover.Period, ProductsTurnoverTurnover.Warehouse, ProductsTurnoverTurnover.Product, ProductsTurnoverTurnover.QuantityTurnover FROM RegisterAccumulation.ProductsTurnover.Turnover(, Month,) AS ProductsTurnoverTurnover

Nous exécutons la requête :

Ainsi, dans l'intervalle de temps sélectionné, nous pouvons diviser les révolutions en intervalles plus petits en fonction de la fréquence sélectionnée.

Registre d'accumulation de solde

Tout comme pour le registre inverse, regardons dans le concepteur de requêtes quelles tables virtuelles sont disponibles pour le registre d'accumulation de solde.

Comme vous pouvez le constater, trois tables virtuelles sont disponibles pour le registre d'accumulation de solde : Révolutions, les restes, Restes et chiffres d'affaires. Considérons chacun d'eux séparément.

Chiffre d'affaires des tables virtuelles

Malgré le fait que le type de registre soit les restes, nous pouvons néanmoins en tirer du chiffre d'affaires. De plus, nous avons deux ressources supplémentaires ici : À venir Et Consommation

Je vous rappelle que lors d'une inscription au registre du bilan, le type de mouvement d'accumulation (revenu ou dépense) est indiqué, alors que pour le registre du chiffre d'affaires, le type de mouvement n'est pas indiqué. Par conséquent, nous avons ici un bonus supplémentaire sous la forme de la possibilité de recevoir non seulement le chiffre d'affaires global de la période, mais également les revenus et les dépenses séparément. Mais bien sûr, si les métadonnées contiennent un registre inversé avec un ensemble de mesures similaire, alors il est préférable de l'utiliser pour obtenir du chiffre d'affaires. En général, travailler avec cette table virtuelle est similaire à travailler avec une table virtuelle Révolutions le registre négociable évoqué ci-dessus.

Soldes de table virtuelle

Ce tableau permet d'obtenir les bilans de ressources par dimension. Dans les paramètres du tableau, nous pouvons spécifier la date pour laquelle nous recevons les soldes et définir les sélections :

Regardons un petit exemple. Nous avons les entrées de registre suivantes :

Sélectionnons tous les champs disponibles et fixons la fin juin comme date de réception des soldes. Nous ne sélectionnerons pas en fonction des mesures. Le texte de la demande ressemblera alors à ceci :

SELECT ProductsRemainingsRemainings.Warehouse, ProductsRemainingsRemainings.Product, ProductsRemainingsRemainings.QuantityRemaining FROM RegisterAccumulations.ProductsRemainings.Remainings(&DateRemainings,) AS ProductsRemainingRemainings

Et après l'avoir exécuté, nous obtenons ce résultat

Soldes et chiffres d'affaires des tables virtuelles

Ce tableau combine les deux évoqués précédemment et permet d'obtenir le chiffre d'affaires de la période sélectionnée, ainsi que les soldes de début et de fin de période. Vous pouvez également définir la sélection.

L'utilisation de ce tableau peut être justifiée lorsqu'il est nécessaire d'obtenir simultanément le chiffre d'affaires et les soldes de début et de fin de période dans un seul rapport. Dans d'autres cas, il ne faut pas abuser de son utilisation.

Lors de l'organisation d'échantillons dans des problèmes réels, dans la grande majorité des cas, la sélection des données est organisée selon certains critères.

Dans le cas où la sélection est effectuée à partir d'une table réelle, aucune difficulté ne se pose. Les données sont traitées de manière absolument triviale :

Dans le cas où la source de la requête est une table virtuelle, la situation devient un peu plus compliquée.

Le langage de requête permet d'imposer une condition sur une sélection parmi des tables virtuelles de deux manières : dans la clause WHERE et en utilisant les paramètres de la table virtuelle. Les deux méthodes conduisent au même résultat (à l’exception de quelques cas particuliers), mais elles sont néanmoins loin d’être équivalentes.

Nous savons déjà que les tables virtuelles sont appelées virtuelles car elles ne se trouvent pas réellement dans la base de données. Ils ne sont constitués qu'au moment où une demande leur est faite. Malgré cela, il est pratique pour nous (c'est-à-dire ceux qui écrivent la requête) de considérer les tables virtuelles comme des tables réelles. Que se passera-t-il dans le système 1C Enterprise 8 lorsque la requête que nous avons compilée accède toujours à la table virtuelle ?

Dans un premier temps, le système créera une table virtuelle. Dans la deuxième étape, les enregistrements seront sélectionnés dans la table résultante qui satisfont à la condition spécifiée dans la clause WHERE :
On voit clairement que l'échantillon final n'inclura pas tous les enregistrements de la table virtuelle (et donc de la base de données), mais uniquement ceux qui satisfont à la condition donnée. Et les enregistrements restants seront simplement exclus du résultat.

Ainsi, le système fera non seulement du travail inutile, mais un double travail inutile ! Tout d'abord, des ressources seront consacrées à la création d'une table virtuelle basée sur des données inutiles (dans la figure, elles sont marquées comme « zones de données A et B »), puis un travail sera effectué pour filtrer ces données du résultat final.

Est-il possible d'arrêter immédiatement, au stade de la construction d'une table virtuelle, d'utiliser des données inutiles ? Il s'avère que c'est possible. C’est exactement à cela que servent les paramètres de la table virtuelle :

En paramétrant une table virtuelle, on limite immédiatement la quantité de données qui seront traitées par la requête.

Quelle est la différence entre les valeurs du paramètre de table virtuelle « Méthode d'addition » ?
Lorsque la méthode d'addition est définie sur « mouvements », seules les périodes dans lesquelles il y a eu des mouvements seront renvoyées. Lorsque « Mouvements et limites de période » sont définis, alors 2 enregistrements seront ajoutés aux mouvements ci-dessus : mouvements au début et à la fin de la période spécifiée dans les paramètres VT. Le champ « Registrar » sera vide pour ces 2 enregistrements.

Informations extraites du site

L'article décrit la mise en œuvre physique d'une table virtuelle de soldes de configuration fonctionnant en mode client-serveur à l'aide de l'exemple d'utilisation du SGBD MS SQL Server.

Applicabilité

L'article traite de la version 8.3.5.1383 de la plateforme 1C:Enterprise. Dans la version actuelle de la plateforme, certaines modifications sont possibles dans le texte décrit dans le matériel, la requête T-SQL exécutée côté serveur SGBD.

Dispositif d'un tableau virtuel des soldes

Considérons en quel type de requête SGBD une requête est transformée à l'aide d'une table virtuelle des soldes des registres d'accumulation. Par exemple, le texte de demande suivant sera pris en compte :

CHOISIR
CommodityInventoryRemains.Product,
CommodityInventoriesRemains.Warehouse,
CommodityInventoryRemaining.QuantityRemaining
DEPUIS
S'inscrireAccumulations.Inventaires.Remains(&Date , Entrepôt = &Entrepôt ) COMMENT
MarchandisesInventairesRestes

Tout d'abord, en utilisant la méthode du contexte global GetDatabaseStorageStructure() nous obtenons une liste de tables de base de données dans lesquelles sont stockées les données du registre d'accumulation « Inventaires de matières premières » :

La composition des champs du tableau principal du registre d'accumulation et du tableau des totaux est donnée ci-dessous :

Le stockage des totaux pour ce registre est configuré en mode « 1C:Enterprise 8 » comme suit :

Remplissons les paramètres dans la requête en question comme suit :

La plateforme convertit le texte de la requête en la requête suivante, qui sera exécutée sur le serveur SGBD :

SÉLECTIONNER
Q_000_T_001.Fld82 ,
Q_000_T_001.Fld83 ,
Q_000_T_001.Fld84Solde
DEPUIS
(SÉLECTIONNER Fld82,
Fld83,

DEPUIS
(SÉLECTIONNER Fld82,
Fld83,
SOMME (Fld84) AS Fld84Balance
DE AccumRgT85
OÙ Période = DATETIME (3999, 11, 1)
ET ((Fld83 = ))
ET(Fld84<>0 ) ET (Fld84<> 0 )
GROUPER PAR Fld82, Fld83
AVOIR Fld84Balance<> 0
UNION TOUS
SÉLECTIONNEZ Fld82,
Fld83,
SOMME (CAS QUAND RecordKind = 0 THEN – Fld84 ELSE Fld84 END ) AS Fld84Balance
DE AccumRg81
OÙ Période >= DATETIME (2012, 9, 1)
ET Période< DATETIME (3999 , 11 , 1 )
ET Actif
ET ((Fld83 = 9:))
GROUPER PAR Fld82, Fld83
AVOIR Fld84Balance<>0 )T
GROUPER PAR Fld82, Fld83
AVOIR Fld84Balance<>0 ) Q_000_T_001

Examinons plus en détail la demande reçue.

Tout d’abord, la première requête de la jointure sélectionne les données de la table AccumRgT85 résultante. Les totaux sont obtenus à la date de stockage des totaux courants (01.11.3999), une condition supplémentaire est appliquée au champ Entrepôt (puisqu'une telle condition a été utilisée dans les paramètres de la table virtuelle). De plus, une vérification est effectuée pour garantir que le résultat ne contient pas de lignes avec un reste nul.

Veuillez noter que le regroupement est effectué selon les dimensions sélectionnées dans le texte de la demande. C'est pourquoi il n'est pas nécessaire de regrouper en plus par dimensions dans le texte du langage de requête 1C:Enterprise.

La deuxième requête de jointure utilise la table de mouvements de registre AccumRg81. Selon le type de mouvement (si RecordKind vaut 0, alors c'est Income, sinon c'est Expense), un signe est inséré dans l'expression. La plateforme sélectionne les données pour la période allant de la date spécifiée en paramètre de la table virtuelle jusqu'à la date de stockage des totaux actuels (11/01/3999).

De plus, seuls les enregistrements actifs sont sélectionnés, le champ Entrepôt doit être égal à la valeur spécifiée. Comme pour la première requête de jointure, cette opération regroupe également par dimensions sélectionnées et supprime les enregistrements avec des valeurs de ressource nulles.

Si le SGBD MS SQL Server est utilisé et que le décalage de date est défini sur 2000 pour la base de données, alors toutes les dates seront stockées avec le décalage spécifié, c'est-à-dire au lieu du 01.11.3999, vous verrez 01.11.5999.

Si vous désactivez les totaux actuels pour le registre d'accumulation, la plateforme recevra d'abord les derniers totaux calculés à une date antérieure à celle spécifiée dans le paramètre Période de la table virtuelle.

Ensuite, de la même manière, ces données seront complétées à partir du tableau des mouvements, mais uniquement pour la période allant de la date des derniers résultats à la période du tableau virtuel.

SÉLECTIONNER
Q_000_T_001.Fld82 ,
Q_000_T_001.Fld83 ,
Q_000_T_001.Fld84Solde
DEPUIS
(SÉLECTIONNER Fld82,
Fld83,
SOMME (Fld84Balance) AS Fld84Balance
DEPUIS
(SÉLECTIONNER Fld82,
Fld83,
SOMME (Fld84) AS Fld84Balance
DE AccumRgT85
OÙ Période = DATETIME (2012, 4, 1)
ET ((Fld83 = 9:))
ET(Fld84<> 0 )
ET(Fld84<> 0 )
GROUPER PAR Fld82, Fld83
AVOIR Fld84Balance<> 0
UNION TOUS
SÉLECTIONNEZ Fld82,
Fld83,
SOMME (CAS QUAND RecordKind = 0 THEN Fld84 ELSE – Fld84 END ) AS Fld84Balance
DE AccumRg81
OÙ Période >= DATETIME (2012, 4, 1)
ET Période< DATETIME (2012 , 9 , 1 )
ET Actif
ET ((Fld83 = 9:))
GROUPER PAR Fld82, Fld83
AVOIR Fld84Balance<>0 )T
GROUPER PAR Fld82, Fld83
AVOIR Fld84Balance<>0 ) Q_000_T_001

Veuillez noter la condition suivante dans le corps de la demande.