Lors de la création de rapports sur l'ACS, il devient souvent nécessaire d'afficher le choix de la 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 dans la liste périodes normales, tels 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 sera généré comme "Afficher l'erreur de traitement, l'incompatibilité de type, le numéro de paramètre ...".

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 réglages rapides rapport, activez le drapeau correspondant pour les paramètres du rapport.

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

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) :

A noter que la fréquence table virtuelle- "Enregistrement".

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

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:

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, à titre d'exemple, une requête simple qui récupère tous les documents de Vente de Biens/Services pour une période donnée (voir Fig. 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

Certaines fonctionnalités de réglage de la période dans l'ACS.

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, la saisie de la période est organisée à l'aide de paramètres, en utilisant la construction suivante, voir 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 publications consacrées au développement en 1C , alors prenons-le comme base. Considérons, à titre d'exemple, une requête simple qui récupère tous les documents de Vente de Biens/Services pour une période donnée (voir Fig.

Lors de l'utilisation de ce rapport, l'utilisateur définit la période via les paramètres, voir 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 :

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.

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. Un bon programme doit avant tout être pratique pour l'utilisateur, car le programme existe pour l'utilisateur, et non l'inverse, par conséquent, vous devrez «enseigner» 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 est :

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

ALORS DATEHEURE(3999,12,31)

QUAND &Période.DateFin<&Период.ДатаНачала

ALORS DATEHEURE(3999,12,31) DATEHEURE(3999,12,31,23,59,59)

&Période.DateFin

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

Remarque : ce mécanisme de paramétrage est destiné aux anciennes plates-formes 1C 8.1 et 8.2 (et aux configurations fonctionnant sous leur contrôle), les anciennes versions de la plate-forme 1C ont des mécanismes intégrés pour contrôler les paramètres non remplis et il n'est pas nécessaire de recourir au mécanisme décrit dans cet article, en plus sur certaines versions de la plate-forme 1C, des erreurs et des travaux incorrects sont possibles.

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, nous voyons les deux dans les paramètres disponibles. 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.

Dans 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, EmployeesSP.ReasonChangeState, EmployeesSP.Period, EmployeesSPotherDate.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, exactement le même problème est observé avec les tables virtuelles d'accumulation et les registres comptables 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".