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

CHOISISSEZ MarchandisesDans EntrepôtsReste. Entrepôt, marchandisesDans les entrepôtsRestes. Nomenclature, MarchandisesDans les EntrepôtsRestes. QuantitéSolde DU registre d'accumulation. marchandises dans les entrepôts. Reste(&MaDate ,) AS MarchandisesDans EntrepôtsRemains

Passons maintenant à l'onglet des paramètres et voyons que le système, en plus de notre paramètre &MyDate, a également créé le paramètre &Period.
Afin d'observer visuellement les périodes, créons le formulaire de rapport principal et plaçons un champ de table avec des données dessus : SettingsComposer.Settings.DataParameters

Enregistrez le rapport et ouvrez-le dans l'entreprise. Dans le champ table avec paramètres, seul le paramètre &Période est affiché :

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

Pourquoi &MyDate n'est pas disponible ? Bien sûr, car dans l'onglet paramètres, il y a une case à cocher Restriction de disponibilité.

Nous enlevons le daw. Maintenant en Options disponibles nous voyons les deux. Ce n'est que lors de la génération du rapport que nous verrons que le rapport répond au paramètre &Period, et non à &MyDate.

À cet exemple Le plus simple 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 qui utilisait déjà le paramètre &Period, ou vos croyances religieuses ne vous permettent pas d'utiliser ce paramètre, dans tous les cas, vous pouvez résoudre le problème comme ceci :

CHOISISSEZ MarchandisesDans EntrepôtsReste. Entrepôt, marchandisesDans les entrepôtsRestes. Nomenclature, MarchandisesDans les EntrepôtsRestes. QuantitéSolde DU registre d'accumulation. marchandises dans les entrepôts. Reste((&MaDate) ,) AS GoodsInWarehousesRemains

UPD de l'utilisateur Huer:

Le principal problème lors de l'utilisation de paramètres "standard" (ajoutés par le système) est que lorsque plusieurs tables virtuelles sont utilisées dans le rapport, si ce paramètre est défini, sa valeur sera utilisée dans tous les autres cas à la place de "propre".

Je vais donner un exemple :

SELECT EmployeesSP.Employee, WorkersSP.ReasonChangeState, EmployeesSP.Period,WorkersSPOtherDate.Period AS Period2, EmployeesSPOtherDate.ReasonChangeState AS ReasonChangeState2FROMRegister.EmployeesOrganizations.SliceLast(&Period , Employee = &Employee) AS EmployeesSP JOINT GAUCHE Registre des informations.Employés des organisations.Slice of the Last(&OtherDate ,) AS EmployeesSPOtherDate ON EmployeesSP.Employee = EmployeesSPOtherDate.Employee

Dans la deuxième sous-requête, la valeur du paramètre "standard" PERIOD sera utilisée comme paramètre de date de tranche, et non la valeur OtherDate.

Ce "problème" sera observé même si la deuxième sous-requête est émise vers le deuxième ensemble de données et déjà liée au moyen d'ACS. L'option utilisant dans la deuxième requête une expression du type "ADDDATE(&Period, MONTH, -1)" ne fonctionnera pas non plus, le mois ne sera pas soustrait. Mais renommer le paramètre "Period" dans la requête, par exemple, "FirstDate" résout ce problème.

Soit dit en passant, le même problème se produit avec tables virtuelles registres d'accumulation et de comptabilité utilisés pour obtenir, par exemple, le chiffre d'affaires. Là, le système ajoute les paramètres "StartPeriod" et "EndPeriod".
Ainsi dans le cas de demandes même un peu plus complexes, il est logique de désactiver la disponibilité et l'utilisation des "périodes standard".

Cet article traite de certaines des caractéristiques de la définition de la période lors de l'utilisation du système de composition de données (ACS), des problèmes qui surviennent en raison de la différence de concept de période entre l'utilisateur moyen et le système 1C, et suggère également des moyens de les résoudre. .
La plupart des rapports élaborés à l'aide du système de composition des données (DCS) exigent que l'utilisateur saisisse la période pour laquelle le rapport sera généré. En règle générale, dans ACS, l'entrée de période est organisée à travers des paramètres, en utilisant la construction suivante, voir Fig. Fig. 1 Cette méthode de saisie d'une période est considérée comme "classique", elle est décrite dans un article sur ITS et d'autres littératures consacrées au développement en 1C, nous la prendrons donc comme base. Considérons, par exemple, une requête simple qui récupère tous les documents Période donnée cm. Fig.2 Lors de l'utilisation de ce rapport, l'utilisateur définit la période à travers les paramètres voir. Fig.3 Tout semble être correct... MAIS il y a un petit problème :

Le fait est que la grande majorité des utilisateurs « comprennent » la période différemment que 1C la « comprend », exemples :
une). Envisager Fig.3
Du point de vue de l'utilisateur, la période n'est pas définie, c'est-à-dire qu'elle n'est PAS LIMITÉE, c'est-à-dire que TOUS les documents sans limite de date doivent être inclus dans le rapport.
"Du point de vue" du système 1C, le paramètre-période est défini et ... ses deux limites sont égales à 01.01.
2). Envisager Fig.4
Du point de vue de l'utilisateur, tous les documents à partir de la date du 28/01/2010 doivent être inclus dans le rapport.
"Du point de vue" période 1C 28/01/2010 - 01/01/0001 provoquera une exception.

Bien sûr, vous pouvez essayer d'expliquer à l'utilisateur pourquoi le rapport n'affiche pas les documents qu'il s'attend à voir et comment la période est présentée du «point de vue» de 1C, mais c'est une tâche ingrate et erronée. Bon programme doit être, avant tout, pratique pour l'utilisateur, car le programme existe pour l'utilisateur, et non l'inverse, il faudra donc "apprendre" 1C à comprendre la période telle que l'utilisateur la comprend, à savoir :
une). StartPeriod et EndPeriod ne sont pas définis -> tous les documents.
2). Seul StartPeriod est défini -> tous les documents à partir de StartPeriod
3). De plus, nous vérifierons que la fin de période >= début de période, et si ce n'est pas vrai, alors nous supposerons que la fin de période n'est pas définie, c'est-à-dire 2).
Sur la base de ce qui précède, l'expression du paramètre EndDate ressemblera à ceci :

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

La vue finale de notre conception de sélection de période est illustrée dans Fig.5

Alors, commençons.

Par souci de simplicité, pour comprendre l'exemple, nous nous baserons sur un simple registre d'accumulation inverse.

Dans mon cas, il s'agit du registre d'accumulation "Comptabilité des travaux en cours".

Par exemple, nous spécifierons ses paramètres de manière rigide (et non par une imposition douce de paramètres sur l'ACS) :

Notez que la fréquence de la table virtuelle est "Record".

Mais, comme indiqué ci-dessus, nous avons besoin de la période dans le cadre de la périodicité, je propose donc de calculer le champ "Période" de la manière suivante (pas très beau, mais je n'ai pas vu de meilleures options) :

Comme vous pouvez le voir sur la capture d'écran, un paramètre est passé à la requête, que l'utilisateur spécifie sur le formulaire : Valeur de l'énumération "Périodicité" - cette énumération est disponible dans presque toutes les solutions standard.

Ses types disponibles sont indiqués dans l'onglet "Paramètres" :

Avec ce réglage, on formate notre période pour que tout soit beau et agréable à l'oeil)

Voici les formats réels :

Mois : DF="MMMM aaaa "a.""

Jour : DF = jj.MM.aaaa

Semaine : df = ""Semaine du" jj.MM.aaaa "

Trimestre : DF = "à "trimestre" aaaa "a".

Année : DF = "aaaa "a."

Décennie : DF = ""Décade depuis" jj.MM.aaaa "

Semestre : DF = "" Semestre depuis" jj.MM.aaaa"

C'est tout. En conséquence, nous avons une image magnifique:

Lors de la création de rapports sur ACS, il devient souvent nécessaire d'afficher une sélection de période sur le formulaire de rapport, de plus, de sorte que vous n'avez pas besoin de remplir les dates manuellement, mais de sélectionner parmi une liste de périodes standard, telles que : "Année", "Mois", "Semaine", etc. . Pour les paramètres de type Date, vous ne pouvez spécifier que "Début de cette année, mois, etc.", mais "Fin" n'est pas fourni.

Le fait est que, parmi les types de données, seul le type "Date de début standard" est disponible, mais je souhaite également le type "Date de fin standard".

Il existe un moyen de contourner cela.

1. Créons un nouveau paramètre, appelons-le "Période"
2. Réglez ce paramètre sur le type "Période standard"
3. Dans le champ "Expression" des paramètres "StartPeriod" et "EndPeriod" utilisés dans la requête, définissez les expressions " &Period.StartDate" et " &Period.EndDate" respectivement.

Mais il y a une petite subtilité. Si nous utilisons des tables virtuelles dans la requête, le rapport cessera probablement de fonctionner et un message d'erreur du type "Afficher l'erreur de traitement, l'incompatibilité de type, le numéro de paramètre ..." sera émis.

Pour éviter cela, vous devez supprimer tous les paramètres des tables virtuelles.

Et ajoutez-les aux tables de l'onglet Composition des données.

Pour que les paramètres soient affichés dans les paramètres de rapport rapide, activez le drapeau correspondant pour les paramètres de rapport.

Maintenant, la sélection de période sur le formulaire de rapport ressemble à ceci.