Maison / Leçons Windows / 1s uv standard choix de période sqd. Paramètre standard &Période et problèmes d'utilisation

1s uv standard choix de période sqd. Paramètre standard &Période et problèmes d'utilisation

Lors de la création de rapports sur le système de contrôle d'accès, il est souvent nécessaire d'afficher une sélection de périodes sur le formulaire de rapport, de sorte que vous n'ayez pas besoin de saisir les dates manuellement, mais de les sélectionner dans une liste. périodes standard, tels que : "Année", "Mois", "Semaine", etc. Pour les paramètres de type Date, vous pouvez uniquement spécifier « Le début de cette année, ce 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 veux aussi la « Date de fin standard ».

Il existe un moyen de contourner ce problème.

  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 « Début de période » et « Fin de période » utilisés dans la requête, paramétrez les expressions « &Période.StartDate" et " &Période.Date de fin »respectivement.

Mais il y a une légère subtilité. Si nous utilisons des tables virtuelles dans la requête, il est fort probable que le rapport cessera de fonctionner et qu'un message d'erreur du type « Erreur lors du traitement de la vue, incompatibilité de type, numéro de paramètre » s'affichera.

Pour éviter cela, vous devez supprimer tous les paramètres de la table virtuelle.

Et ajoutez-les aux tableaux de l'onglet « Composition des données ».

Pour que les paramètres soient affichés dans réglages rapides rapport, activez l'indicateur correspondant pour les paramètres du rapport.

La sélection de période sur le formulaire de rapport ressemble désormais à ceci.

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 en paramètres disponibles nous voyons les deux. 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 dans cet exemple Le moyen le plus simple consiste à renommer le paramètre &MyDate dans la requête en &Period et à 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 :

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

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 Employees JV 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 ».

Quelques fonctionnalités de réglage de la période dans le système de contrôle d'accès.

La plupart des rapports développés à l'aide d'un système de composition de données (DCS) nécessitent que l'utilisateur saisisse la période pour laquelle le rapport sera créé.

En règle générale, dans ACS, la saisie des périodes est organisée par paramètres, en utilisant la construction suivante, voir. Cette méthode de saisie des périodes 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, donc prenons-le comme base. Considérons à titre d'exemple une simple demande qui reçoit tous les documents Ventes de biens et services pour période spécifiée cm.

Lors de l'utilisation de ce rapport, l'utilisateur définit la période via les paramètres, voir. Tout semble correct..., MAIS il y a un petit problème :

Le fait est que la grande majorité des utilisateurs « comprennent » la période différemment de 1C, exemples :

Du point de vue de l'utilisateur, la période n'est pas précisée, c'est-à-dire ILLIMITÉE, c'est-à-dire que TOUS les documents sans restriction 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.0001 et seuls les documents avec une date vide seront inclus dans le rapport, ce qui signifie en pratique aucun document ne sera inclus.

Du point de vue de l'utilisateur, le rapport doit inclure tous les documents à compter de la date du 28/01/2010.

« Du point de vue » de 1C, la période du 28/01/2010 au 01/01/0001 fera exception.

Vous pouvez bien sûr 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 elle est également faux. Bon programme doit avant tout être pratique pour l'utilisateur, car le programme existe pour l'utilisateur, et non l'inverse, il faut donc « apprendre » à 1C à comprendre la période telle que l'utilisateur la comprend, à savoir :

1). Début de période et fin de période ne sont pas précisés -> tous les documents.

2). Seul le Début de la Période est précisé -> tous les documents à partir du Début de la Période

3). De plus, nous vérifierons que Fin de période >= Début de période, et si ce n'est pas vrai, alors nous supposerons que Fin de période n'est pas spécifiée, c'est-à-dire 2).

Sur la base de ce qui précède, l'expression du paramètre End Date est :

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

ALORS DATEHEURE(3999,12,31)

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

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

&Période.Date de fin

La forme finale de notre conception de sélection de périodes est présentée dans

Remarque : ce mécanisme de paramétrage est destiné aux anciennes plates-formes 1C 8.1 et 8.2 (et aux configurations exécutées 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 vides et il n'est pas nécessaire de recourir au mécanisme décrit dans cet article, en plus Sur certaines versions de la plateforme 1C, des erreurs et un fonctionnement incorrect sont possibles.

Alors, commençons.

Pour plus de simplicité, et pour comprendre l'exemple, nous nous appuierons sur un simple registre d'accumulation circulant.

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

Par exemple, nous indiquerons ses paramètres de manière rigide (et non par une imposition douce de paramètres sur le système de contrôle d'accès) :

Veuillez noter que la fréquence de la table virtuelle est « Record ».

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

Comme le montre la capture d'écran, un paramètre est transmis à la requête, que l'utilisateur précise sur le formulaire : La valeur de l'énumération "Fréquence" - cette énumération se retrouve dans presque toutes les solutions standards.

Nous indiquerons ses types disponibles dans l’onglet « Paramètres » :

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

Voici les formats eux-mêmes :

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

Jour : DF = jj.MM.aaaa

Semaine : DF = ""Semaine à partir de "jj.MM.aaaa"

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

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

Décennie : DF = ""Décennie avec "jj.MM.aaaa"

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

C'est tout. Le résultat est une magnifique image :

Cet article traite de certaines des caractéristiques de la configuration d'une période lors de l'utilisation d'un système de composition de données (DCS), des problèmes qui surviennent en raison des différences dans le concept de période entre un utilisateur ordinaire et le système 1C, et suggère également des moyens de les résoudre. .
La plupart des rapports développés à l'aide d'un système de composition de données (DCS) nécessitent que l'utilisateur saisisse la période pour laquelle le rapport sera créé. En règle générale, dans ACS, la saisie des périodes est organisée par paramètres, en utilisant la construction suivante, voir. 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 autre littérature consacrée au développement en 1C, prenons-la donc comme base. Considérons à titre d'exemple une simple demande qui reçoit tous les documents Ventes de biens et services pour une période donnée, voir Figure 2 Lors de l'utilisation de ce rapport, l'utilisateur définit la période via les paramètres, voir. Figure 3 Tout semble correct... MAIS il y a un petit problème :

Le fait est que la grande majorité des utilisateurs « comprennent » la période différemment de 1C, exemples :
1). Considérons Figure 3
Du point de vue de l'utilisateur, la période n'est pas précisée, c'est-à-dire ILLIMITÉE, c'est-à-dire que TOUS les documents sans restriction 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.0001 et seuls les documents avec une date vide seront inclus dans le rapport, ce qui signifie en pratique aucun document ne sera inclus.
2). Considérons Figure 4
Du point de vue de l'utilisateur, le rapport doit inclure tous les documents à compter de la date du 28/01/2010.
« Du point de vue » de 1C, la période du 28/01/2010 au 01/01/0001 fera exception.

Vous pouvez bien sûr 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 elle est également faux. Un bon programme doit avant tout être convivial, 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 :
1). Début de période et fin de période ne sont pas précisés -> tous les documents.
2). Seul le Début de la Période est précisé –> tous les documents à partir du Début de la Période
3). De plus, nous vérifierons que Fin de période >= Début de période, et si ce n'est pas vrai, alors nous supposerons que Fin de période n'est pas spécifiée, c'est-à-dire 2).
Sur la base de ce qui précède, l'expression du paramètre End Date ressemblera à ceci :

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

La forme finale de notre conception de sélection de périodes est présentée dans Figure 5