Application gérée. Application gérée Application gérée de contrôle d'interface logicielle 1c

Chaque administrateur 1C: Enterprise sait que la tâche de séparation des droits d'utilisateur et des modifications correspondantes dans l'interface de travail est l'une des tâches principales lors de l'introduction d'un système comptable ou de l'apparition de nouveaux utilisateurs. L'efficacité du travail et la sécurité des données dépendent de la qualité de l'exécution de cette tâche. Par conséquent, nous parlerons aujourd'hui des spécificités de la personnalisation des droits d'utilisateur et de l'interface dans une application gérée.

Tout d'abord, je voudrais souligner les principaux aspects de ce type de paramètres. De nombreuses personnes abordent cette question de manière unilatérale, les considérant uniquement comme une mesure de protection contre l'accès non autorisé aux données ou leur modification non qualifiée. Dans le même temps, ils oublient le revers de la médaille: créer un environnement de travail simple et pratique pour l'utilisateur. Dans les cas où l'interface utilisateur est surchargée d'éléments inutiles, dont la signification, de plus, ne lui est pas tout à fait claire, une fausse idée de la complexité excessive du programme se pose et il y a une crainte de se tromper. Il est clair que cela ne contribue en aucune façon à une augmentation de la productivité des employés.

Idéalement, chaque employé ne devrait voir que les éléments d'interface dont il a besoin pour accomplir ses tâches immédiates. Ensuite, il sera plus facile de travailler et les tentations de grimper là où ce n'est pas nécessaire ne se présenteront pas. De plus, il est logique d'effectuer de tels réglages également lorsque certains sous-systèmes ne sont tout simplement pas utilisés ou qu'une restriction d'accès à ceux-ci n'est pas requise. Cela rendra l'interface plus simple et plus compréhensible, et, par conséquent, l'utilisateur sera plus facile et plus confortable à utiliser.

Si nous remontons un peu dans le passé, nous pouvons nous rappeler que dans des configurations normales Les rôles et Interfaces faisaient partie de la configuration et pour leur mise au point, il était nécessaire de permettre la possibilité d'apporter des modifications, et dans les versions de base, c'était impossible du tout.

Les inconvénients de cette approche sont évidents: ils sont à la fois la complication de la maintenance de l'infobase et les conflits possibles lors des mises à jour ultérieures, lorsque des objets de configuration modifiés nécessitent des droits d'accès modifiés.

Dans une application gérée, les droits et les paramètres d'interface ont finalement été déplacés en mode utilisateur et sont configurés directement depuis l'interface du programme. Les droits d'utilisateur sont attribués en fonction de leur appartenance au groupe d'accès. Allons à Administration - Paramètres utilisateur et droits - Groupes d'accès - Profils de groupe d'accès, où nous verrons des profils déjà prédéfinis pour les principaux groupes d'accès.

Un utilisateur peut être membre de plusieurs groupes d'accès à la fois, dans ce cas le total des droits sera résumé. En général, tout est assez clair et familier, sauf si les réglages sont maintenant effectués en mode utilisateur, et non dans le configurateur.

Mais si nous essayons de trouver les paramètres d'interface, nous échouerons. Dans une application gérée, l'interface de l'espace de travail est automatiquement générée en fonction des droits d'accès. Par exemple, comparons les interfaces du panneau de la section Administrateur et Directeur des ventes:

En général, l'idée est bonne, il y a des droits d'accès à l'objet - on le montre dans l'interface, non - on le cache. C'est beaucoup mieux que les messages apparaissant dans une application normale sur les violations d'accès lorsqu'ils ne correspondent pas à l'interface attribuée. Si vous ajoutez des droits à un groupe d'accès ou, au contraire, les supprimez, les éléments d'interface qui leur sont associés apparaîtront ou disparaîtront d'eux-mêmes. Idéalement? Oui.

De plus, l'utilisateur peut personnaliser indépendamment son espace de travail dans la limite de ses droits d'accès. À première vue, tout semble bon, mais ce n'était pas sans une mouche dans la pommade. Il n'existe aucun mécanisme pour configurer et affecter de manière centralisée une interface par défaut aux utilisateurs dans une application gérée.

Si nous regardons Administration - Paramètres utilisateur et droits - Paramètres utilisateur personnels - Paramètres utilisateur, nous y verrons une liste de tous les objets dont les paramètres ont été modifiés par l'utilisateur, mais nous ne pouvons en aucun cas les modifier.

Ceux. il nous est proposé de passer directement sous l'utilisateur et de configurer l'interface de travail en son nom. Une décision controversée, surtout s'il n'y a pas deux ou trois utilisateurs. Heureusement, les développeurs ont fourni la possibilité de copier les paramètres utilisateur, ce qui permet de personnaliser l'interface de l'un des utilisateurs de la manière dont nous avons besoin d'appliquer rapidement les paramètres pour tous les autres.

Pour ne pas être infondé, analysons un exemple pratique. En vue de la transition vers les caisses enregistreuses en ligne, il a été décidé d'automatiser les distributeurs automatiques d'un petit réseau de cliniques dentaires. La base de l'automatisation des cliniques était le logiciel de l'industrie qui n'était pas basé sur 1C et ne prévoyait pas la possibilité de connecter un registraire fiscal, il a donc été décidé d'utiliser la configuration Enterprise Accounting 3.0 pour automatiser la caisse enregistreuse, qui contient toutes les fonctions nécessaires.

Nous sommes ici confrontés à deux difficultés, bien que si vous regardez de plus près, vous constaterez que ce sont les deux faces d'une même médaille. En bref: le personnel n'avait jamais travaillé avec 1C auparavant, et il était donc nécessaire de créer l'environnement de travail le plus facile à apprendre, tout en protégeant la base d'informations contre une éventuelle exposition du personnel non qualifié. Une application gérée permet de combiner facilement l'utile à l'agréable, ce qui fait que l'utilisateur est limité et en même temps lui permet de travailler confortablement sans remarquer les restrictions.

Commençons. Tout d'abord, vous devez créer un profil de groupe d'utilisateurs. Si nous ouvrons les profils standards, nous verrons qu'il n'y a aucune possibilité de les modifier. Cela, à notre avis, est correct, l'histoire connaît de nombreux exemples où, dans un accès de zèle au service, des droits standard ont été poussés à un tel état qu'ils ont dû être restaurés à partir de la configuration de référence. Cela peut également induire en erreur d'autres utilisateurs ou administrateurs de cette base de données, qui s'attendent à voir des ensembles de droits standard sous des profils standard.

Par conséquent, nous trouverons le profil le plus adapté à nos tâches, dans notre cas, il s'agit du directeur des ventes, et en ferons une copie, que nous nommerons le caissier. Nous pouvons désormais personnaliser les droits à notre propre discrétion. Cependant, la liste plate par défaut n'est pas très pratique à utiliser, à moins que vous ne deviez trouver rapidement une option que vous connaissez déjà, dans la plupart des cas, il est beaucoup plus pratique de travailler avec la liste en activant le regroupement par sous-systèmes.

Nous ne nous attarderons pas sur cette question de la même manière, puisque l'attribution des droits dépend des tâches spécifiques auxquelles est confronté l'utilisateur, nous ne pouvons que vous conseiller de faire preuve de prudence et de ne pas aller aux extrêmes. N'oubliez pas que votre travail consiste à créer un environnement de travail confortable et sûr, et non à tout interdire.

Après avoir créé un profil, attribuez un groupe d'accès aux utilisateurs requis et exécutez le programme sous l'un d'eux. En fonction des droits attribués, vous verrez une interface générée automatiquement.

En principe, c'est déjà assez bon, mais dans notre cas, tout ne fait que commencer. A notre grande surprise, de nombreux utilisateurs et administrateurs n'ont toujours aucune idée de la configuration de l'interface "Taxi", continuant à se plaindre de ses "inconvénients".

Allons à Menu principal - Affichage, où nous verrons un certain nombre de paramètres liés à l'interface.

Commençons avec paramètres du panneau de coupe, dans notre cas, l'assortiment était limité à une courte liste de services, de sorte que la section entrepôt s'est avérée superflue, afin de ne pas compliquer et alourdir l'interface, nous allons simplement la supprimer.

Ensuite, dans chaque section, en cliquant sur l'engrenage dans le coin supérieur droit, nous allons configurer séquentiellement la navigation et les actions. Ici, nous supprimerons également tout ce qui n'est pas nécessaire dans le travail quotidien, mais, au contraire, nous mettrons le nécessaire au premier plan.

Vous pouvez même comparer comment c'était et comment il est devenu:

Enfin, configurons les panneaux. Comme nous avons peu de sections, il est logique de déplacer le panneau de coupe vers le haut et le panneau ouvert vers le bas, élargissant ainsi l'espace de travail horizontalement, ce qui est important pour les moniteurs avec une petite diagonale ou un format 4: 3.

Une fois terminé, vous devez vérifier à nouveau tous les paramètres, il est préférable de le faire en imitant les actions réelles du caissier, ce qui aidera immédiatement à évaluer la commodité de travailler avec l'interface. Dans notre cas, nous avons eu un lieu de travail de caissier simple et pratique, dans tous les cas, il n'y a pas eu de problèmes avec son développement par le personnel:

Maintenant, nous allons à nouveau entrer dans le programme sous l'administrateur et aller à Administration - Paramètres utilisateur et droits - Paramètres utilisateur personnels - Paramètres de copie. Notre tâche est de distribuer les modifications que nous avons apportées aux autres utilisateurs du groupe Caissiers. L'opération elle-même est assez simple: nous sélectionnons l'utilisateur dont nous copions les paramètres, indiquons à qui et choisissons lequel.

Et enfin, vous pouvez empêcher l'utilisateur de configurer l'interface lui-même, pour ce faire, revenez au profil du groupe et décochez l'action Sauvegarde des données utilisateur.

Comme vous pouvez le constater, la configuration de l'interface et des droits utilisateur dans une application gérée est assez simple et, malgré certains inconvénients, offre aux administrateurs beaucoup plus de flexibilité et de commodité, leur permettant de créer rapidement un environnement de travail pratique et sécurisé.

  • Mots clés:

Veuillez activer JavaScript pour afficher le

"1C: Enterprise 8. Application gérée". Nouvelles opportunités

Nikita Zaitsev

Nous continuons à examiner les capacités et les concepts architecturaux de la plate-forme technologique de nouvelle génération - «1C: Enterprise 8. Managed Application». L'article examinera différents types d'applications clientes, un nouveau principe d'utilisation de sous-systèmes de configuration, des mécanismes d'options fonctionnelles et de rapports gérés, et quelques autres innovations de l '«application gérée».

Types d'application client

Dans les versions précédentes de 1C: Enterprise 8, il n'existait aucune option pour lancer l'application client. Pour qu'un utilisateur puisse travailler avec des infobases, un seul type d'application cliente a été utilisé, appelé le «client». Pour organiser le travail à distance des utilisateurs avec une infobase, diverses technologies ont été (et sont toujours utilisées), chacune ayant ses propres avantages et inconvénients. L'accès à distance peut être organisé à l'aide des outils standard 1C: Enterprise 8:

Créer une infobase distribuée. Chaque groupe d'utilisateurs distants travaille avec sa propre base de données locale et les données sont régulièrement synchronisées entre la base de données principale et les bases de données distantes. L'avantage de cette technologie est que les utilisateurs distants n'ont pas du tout besoin d'un accès direct à la base d'informations "principale". Mais il y a aussi un inconvénient: les modifications de données effectuées dans l'un des nœuds de l'infobase distribuée ne sont pas transmises aux nœuds voisins immédiatement, mais après un certain temps.

Utilisation de l'interface Web (basée sur la plate-forme d'extension 1C: Enterprise 8.Web). Avantages - la possibilité de travailler sur des canaux de communication à faible vitesse, pas besoin d'installer "1C: Enterprise 8" sur l'ordinateur de l'utilisateur. Inconvénients - épuisement fonctionnel important de l'interface utilisateur par rapport au «client lourd», nécessité d'attirer des programmeurs connaissant la technologie ASP.NET pour développer une application Web.

L'accès à distance à l'infobase peut également être organisé à l'aide de moyens non système:

Travaillez via le service terminal. Avantages - la possibilité de travailler sur des canaux de communication à faible vitesse, il n'est pas nécessaire de modifier quoi que ce soit dans la configuration. Mais d'un autre côté, des licences supplémentaires pour le logiciel serveur et des ressources matérielles supplémentaires sont nécessaires (idéalement, un serveur dédié pour les utilisateurs «terminaux»).

Travaillez via une connexion VPN. Avantage - l'utilisateur travaille avec l'infobase distante comme d'habitude, comme si elle se trouvait dans son réseau local local. Inconvénient - un canal de communication à haut débit fiable est nécessaire, de gros volumes de trafic sont consommés.

Interaction client-serveur

L '«Application gérée» est conçue pour simplifier et minimiser les coûts d'organisation du travail à distance des utilisateurs avec des infobases - les utilisateurs peuvent désormais travailler avec des infobases en ligne à la fois au sein du réseau local de l'entreprise et via Internet.

Il existe trois types différents d'applications clientes que vous pouvez utiliser dans une «application gérée».

"Gros client". Il est similaire à l'application client des versions précédentes de 1C: Enterprise 8, mais il est compatible avec deux modes de fonctionnement - normal et géré. La principale différence entre eux est le principe de construction d'une interface de commande globale (pour plus de détails sur le nouveau modèle d'interface de l '"Application Managée", voir l'article précédent de notre série). Le "client lourd" consomme plus de ressources système sur l'ordinateur de l'utilisateur, mais il n'impose aucune restriction fonctionnelle sur l'utilisation de la configuration.

"Client léger". Une toute nouvelle application incluse dans 1C: Enterprise. Il fonctionne uniquement en mode contrôlé, il est destiné aux utilisateurs de travailler avec des infobases via Internet (bien sûr, il peut également fonctionner sur le réseau local de l'entreprise). Pour un «client léger», il existe un mode «faible vitesse de connexion», lorsque l'on y travaille, la plateforme optimise les processus d'interaction entre l'application client et le serveur pour les canaux de communication bas débit. Le "client léger" nécessite beaucoup moins de ressources système que le "client lourd", mais il est fonctionnellement limité - il ne fonctionne qu'avec des formes de configuration gérées, le mode Configurateur n'est pas disponible.

Client Web. Dans ce cas, il n'est pas nécessaire d'installer 1C: Enterprise 8 ou tout autre logiciel supplémentaire sur l'ordinateur de l'utilisateur. Le travail avec les bases d'informations "1C: Enterprise 8" est réalisé via un navigateur Internet classique (MS Internet Explorer ou Mozilla FireFox). Les limitations fonctionnelles du client Web sont les mêmes que celles du "client léger": travaillant uniquement avec des formulaires gérés, le mode Configurateur n'est pas pris en charge. L'identité presque complète (à l'exception de quelques restrictions mineures) de l'apparence et du comportement du système lors de l'utilisation d'un client léger et Web est déclarée. Malheureusement, au moment de la rédaction de cet article, la technologie du client Web n'avait pas encore été publiée par 1C, de sorte que les informations fournies sur cette technologie sont basées uniquement sur la documentation d'accompagnement de l'application gérée.

Interface de commande basée sur le sous-système

Afin de ne pas être confus et de comprendre clairement quelles méthodes de connexion aux infobases et quels modèles d'interface sont pris en charge par différents types d'application client 1C: Enterprise 8, les informations sont mieux présentées sous forme de tableau (voir les tableaux 1 et 2).

Lorsque vous travaillez avec l'application gérée, l'organisation de l'accès en ligne à l'infobase 1C: Enterprise 8 se résume essentiellement à la mise en place d'un serveur Web. Chaque infobase nécessitera en outre:

Créez un fichier descripteur d'infobase (deux lignes de XML);

Configurez l'application (répertoire virtuel) correspondant à l'infobase côté serveur Web (MS IIS ou Apache).

Ces opérations sont effectuées une fois pour chaque infobase avec laquelle un travail à distance est attendu. Bien entendu, pour que les utilisateurs distants puissent travailler avec l'infobase en mode «client léger» ou client Web, la configuration doit être développée et (ou) modifiée pour le nouveau modèle d'interface «Application gérée» et doit contenir les formulaires gérés des objets avec lesquels ils travailleront utilisateurs distants.

Notez qu'avec l'avènement de la technologie client Web, 1C: Enterprise 8 acquiert des fonctionnalités multi-plateformes à part entière. Désormais, tous les éléments du système d'information peuvent fonctionner à la fois sous Windows et sous Linux (voir tableau 3).

Le seul lieu de travail sur lequel Windows doit être installé est celui de l'administrateur du système d'information, où vous devez exécuter 1C: Enterprise 8 en mode Configurateur.

Définition de la visibilité des commandes par défaut

Il faut également noter les évolutions de l'architecture client-serveur 1C: Enterprise 8 liées à l'émergence de nouveaux types d'applications clientes. Dans les versions précédentes de la plate-forme, la seule forme d'interaction entre le client et le serveur était une connexion, c'est-à-dire un lien physique entre l'application cliente et l'un des processus de travail du cluster de serveurs. Cette connexion est établie lorsque le client se connecte à l'infobase et persiste jusqu'à ce que l'application cliente soit fermée.

Personnalisation de l'interface utilisateur

Dans "Application gérée", lorsque vous travaillez avec un "client léger" ou un client Web, un schéma d'interaction client-serveur plus flexible est utilisé: une session utilisateur. Chaque appel de l'application client au serveur est séparé et est traité par le cluster de serveurs indépendamment des appels précédents. Ce schéma permet:

Augmenter la «survivabilité» du système. Si un processus de travail de cluster de serveurs devient indisponible pour une raison quelconque, les applications clientes basculent vers d'autres processus de travail disponibles (dans les versions précédentes, le «plantage» du flux de travail entraînait la rupture de toutes les connexions et le «blocage» de toutes les applications clientes servies par le processus).

Améliorez les performances du système en équilibrant dynamiquement les charges de travail. Dans les versions précédentes, la charge n'était distribuée qu'au moment où le client accédait pour la première fois au serveur. Dans l '«Application gérée», le gestionnaire de cluster surveille en permanence la charge de travail des processus de travail et répartit la charge entre eux. Si le processus de travail ou le serveur de travail qui a servi l'application client est soudainement surchargé, lors du prochain accès au serveur, le client sera basculé vers un processus ou un serveur moins chargé.

Sous-systèmes de configuration

Dans les versions précédentes de 1C: Enterprise 8, les sous-systèmes de configuration ne supportaient aucune charge fonctionnelle. Bien entendu, on ne peut pas dire qu'avant l'avènement de "Managed Application", le mécanisme du sous-système était purement décoratif - les développeurs de configuration et les spécialistes impliqués dans la maintenance des bases d'informations l'utilisaient pour résoudre une variété de problèmes technologiques. Mais les sous-systèmes n'avaient absolument aucune influence sur le comportement de la configuration en mode utilisateur. De plus, aucun sous-système ne pouvait être défini dans la configuration du tout, et cela n'affectait en rien son fonctionnement.

La situation dans «l'application gérée» est complètement différente: la structure hiérarchique des sous-systèmes est l'élément de configuration clé sur lequel repose l'interface de commande globale. L'interface utilisateur est formée selon les principes suivants:

Les sections de l'interface de commande sont créées sur la base des sous-systèmes de configuration racine (situés au premier niveau de la hiérarchie).

Sur la base de l'appartenance au sous-système racine correspondant et aux sous-systèmes subordonnés de certains objets de configuration, un ensemble de commandes de la section correspondante est créé.

Pour chaque commande de l'ensemble, il est déterminé si elle est en principe disponible pour l'utilisateur actuel. La décision se fait en deux étapes: d'abord, les commandes pour lesquelles l'utilisateur n'a pas de droits d'accès sont supprimées de l'ensemble, puis les commandes désactivées au moyen d'options fonctionnelles.

Pour chacune des commandes disponibles pour l'utilisateur, le mode de visibilité est déterminé: afficher la commande dans le panneau d'interface correspondant ou masquer la commande. La plate-forme vérifie les paramètres spécifiés par le développeur de configuration et l'utilisateur de la base de données. Le développeur de configuration peut définir différents modes de visibilité d'une commande pour différents rôles, et l'utilisateur, s'il le souhaite, peut remplacer la visibilité de chacune des commandes dont il dispose pour son lieu de travail.

Ainsi, lors du passage à une configuration "Application gérée", les sous-systèmes de configuration d'un objet "service" se transforment en un objet clé, et la tâche de concevoir avec compétence la structure des sous-systèmes et de répartir les objets de configuration entre eux devient primordiale pour le développeur.

Mécanisme d'options fonctionnelles

En utilisant le mécanisme d'options fonctionnelles, l'implémenteur peut dynamiquement inclure ou exclure de l'application de l'utilisateur certaines fonctionnalités et ses éléments d'interface correspondants, et aucune modification n'est requise de la configuration réelle. Les options fonctionnelles sont basées sur les données d'application de l'infobase et peuvent être activées à la volée directement pendant le fonctionnement du système.

Impact des options fonctionnelles sur une interface

La meilleure façon d'expliquer le fonctionnement des options fonctionnelles est d'utiliser un exemple spécifique. Disons que nous créons une configuration pour automatiser un petit point de vente. Lorsque nous concevons notre configuration, nous notons un ensemble de fonctionnalités «transversales» à la configuration, le besoin de ces capacités étant déterminé par le contexte d'une implémentation particulière ou même d'un processus particulier.

L'entreprise peut utiliser divers équipements commerciaux (par exemple, des scanners de codes-barres) pour automatiser la comptabilité.

Plusieurs entrepôts peuvent être organisés dans une entreprise; en conséquence, il peut être nécessaire de tenir des registres par entrepôts.

La comptabilité peut se faire de différentes manières pour les produits locaux et d'exportation, pour les fournisseurs locaux et étrangers.

En fonction des spécificités d'une implémentation particulière, les mêmes objets de configuration doivent avoir une apparence et agir différemment, par exemple:

Si des scanners de codes-barres sont utilisés, certains types de formulaires de document doivent contenir une commande pour contrôler le scanner.

Si la comptabilité est effectuée dans le contexte des entrepôts, les détails et les commandes associés à l'entrepôt doivent être affichés dans les formulaires appropriés (documents de vente, rapports).

Si l'entreprise travaille avec des fournisseurs étrangers, les formulaires appropriés (documents de règlement, rapports) doivent afficher les détails et commandes liés à la comptabilité des devises (devise, taux de change, «recalculer au taux actuel», etc.).

Le mécanisme des options fonctionnelles permet au développeur d'applications de prévoir l'ajustement de l'apparence et du comportement des objets de configuration aux exigences d'une implémentation spécifique et aux spécificités d'une entreprise particulière sans codage incroyablement fastidieux des fonctions qui contrôlent la visibilité et l'accessibilité des éléments d'interface. Le développeur définit de manière déclarative un ensemble de fonctions (objets et commandes de configuration) et définit les règles selon lesquelles la plateforme doit activer ou désactiver l'ensemble spécifié. L'utilisateur, en revanche, reçoit une interface d'application qui n'est pas surchargée de «détails inutiles» et ne perd pas de temps sur la procédure, «dans quels cas ce champ est significatif et quand il est logique d'appuyer sur ce bouton» - tout ce qui se trouve devant ses yeux est significatif.

Un point important est à noter: l'état des options fonctionnelles et de leurs paramètres n'a aucun effet ni sur la composition des objets de configuration, ni sur la composition des tables et des champs de la base de données. Les objets de métadonnées et leurs attributs, contrôlés par des options fonctionnelles, disparaissent uniquement de l'interface utilisateur, mais pas de l'infobase. Les options fonctionnelles ne sont pas utilisées pour réduire les possibilités de configuration de l'application, mais pour désactiver et masquer à l'utilisateur les fonctions qui sont redondantes et / ou non pertinentes dans le contexte actuel de l'utilisateur.

Rapports gérés Formulaire de rapport géré

Le mécanisme de rapport "Application gérée" a conservé les "caractéristiques familiales" du mécanisme de rapport de la version précédente de "1C: Entreprise 8":

Le rapport est basé sur le schéma de composition des données. En général, pour créer un nouveau rapport dans la configuration, il suffit de développer un schéma de mise en page - le formulaire de rapport (comprenant diverses fonctionnalités de service - décryptage, sélection, conception conditionnelle, etc.) sera automatiquement généré par la plateforme.

En mode personnalisé, chaque utilisateur peut, s'il le souhaite, modifier certains paramètres du schéma de mise en page, créer et enregistrer ses propres «variantes de rapport» personnelles.

Configurer une variante de rapport

Les rapports gérés (les soi-disant rapports mis en œuvre à l'aide de la technologie «Application gérée») présentent un certain nombre de différences importantes par rapport à leurs prédécesseurs.

Le rapport est généré uniquement côté serveur, seuls les résultats finis sont envoyés à l'application cliente. Dans les versions précédentes de 1C: Enterprise 8, le rapport pouvait être généré à la fois côté serveur et côté client.

Le mécanisme de gestion des paramètres de rapport a été considérablement repensé. Ce processus est désormais hiérarchique et se compose de variantes de rapport, de paramètres de variante de rapport et de paramètres de rapport personnalisés.

Les paramètres du rapport sont enregistrés dans la table de la base de données système ou (si fourni par le développeur de configuration) dans un objet d'infobase spécial "Stockage des paramètres". Dans les versions précédentes de 1C: Enterprise 8, vous deviez soit enregistrer les paramètres de rapport sous forme de fichier, soit développer votre propre stockage de paramètres basé sur des registres d'informations.

Personnalisation du rapport

Examinons de plus près le mécanisme de gestion des paramètres de rapport. À première vue, cela peut sembler trop compliqué, mais en fait, tout est très simple et pratique. Les paramètres de rapport sont gérés à plusieurs niveaux:

Niveau du configurateur. Le concepteur de configuration crée un schéma de composition de données et définit des variantes de rapport (une variante de rapport est un ensemble de paramètres de schéma de composition de données). Par exemple, pour le rapport "Analyse des ventes" les options "Par périodes" (analyse du volume des ventes dans le contexte des périodes) et "Par groupes" (analyse du volume des ventes dans le cadre des groupes d'articles) peuvent être définies. Le concepteur de configuration détermine également les éléments de paramétrage que l'utilisateur pourra modifier lors de l'utilisation du rapport.

Niveau de spécialiste de la mise en œuvre. Effectue un «réajustement» du rapport pour les besoins d'une entreprise particulière. Le spécialiste de l'implémentation a accès aux mêmes opérations que le développeur de configuration, mais une nuance importante doit être notée: vous pouvez modifier les options de rapport existantes et en ajouter de nouvelles dans le mode utilisateur 1C: Enterprise 8 sans apporter de modifications à la configuration.

Utilisateur de la base d'informations. L'utilisateur contrôle les éléments de personnalisation de rapport mis à disposition par le développeur de configuration et le spécialiste de l'implémentation.

Développement d'options de rapport

La commodité de la nouvelle structure des paramètres de rapport par rapport aux versions précédentes de "1C: Enterprise 8" est que:

Les éléments de paramètres personnalisés sont modifiés soit directement sur le formulaire de rapport (si l'indicateur «accès rapide» est sélectionné pour l'élément de paramètres), soit dans un formulaire simple séparé. Ce formulaire ne contient que les contrôles les plus nécessaires, n'est pas surchargé de fonctionnalités et ne jette pas les utilisateurs non préparés dans un état de choc (comparez simplement l'apparence de ce formulaire avec le formulaire de gestion de l'option de rapport).

L'ensemble des options de rapport et des paramètres utilisateur peuvent être modifiés dans l'application client, l'administrateur système ou un utilisateur expérimenté peut modifier le rapport à la volée, simplifiant ou compliquant sa personnalisation.

Du fait que tous les paramètres définis sont stockés dans l'infobase, le processus d'échange de paramètres entre utilisateurs peut être simplifié à la limite - pour cela, le mode de configuration doit être configuré pour stocker les paramètres de rapport dans un objet de configuration spécial "Stockage des paramètres". L'administrateur système configure les options requises pour le rapport, il suffit à l'utilisateur d'ouvrir le formulaire de rapport, de sélectionner une option, de définir les valeurs des paramètres utilisateur «rapides» et de cliquer sur le bouton «Générer».

Personnalisation des rapports à plusieurs niveaux

Si nous essayons de formuler les avantages des rapports gérés par rapport aux rapports «réguliers» de «1C: Entreprise 8» en trois mots, alors ces mots seront: productivité, flexibilité, commodité. Les rapports gérés sont plus rapides - toute la génération de rapports est effectuée côté serveur. Ils fournissent un mécanisme de configuration beaucoup plus flexible en divisant les paramètres en deux niveaux. Enfin, les rapports gérés sont simplement plus faciles à utiliser. Mais les rapports, plus précisément les informations présentées dans les rapports, sont le produit final du système d'information, c'est le résultat que le système fournit au consommateur.

Ceci conclut notre examen de l'innovation «Managed Application». Nous reviendrons peut-être sur ce sujet après la première version. Bien sûr, vous ne pouvez obtenir une image complète des capacités de la nouvelle génération de la plate-forme qu'en la tenant entre vos mains et en lisant attentivement la documentation - les partenaires de 1C et les utilisateurs enregistrés de 1C: Enterprise 8 ont déjà cette opportunité.

Nouvelles. 15 à 15

Des ordinateurs

ASUS (http://asus.com.ru) a annoncé la sortie de l'ordinateur personnel Eee Box. Le produit est assemblé dans un corps ultra-compact, la Eee Box peut être montée sur un support VESA. Le système implémente les moyens de téléchargement à haut débit et de connexion Internet (ASUS Express Gate), il existe un adaptateur sans fil WiFi 802.11n.

Bonjour.

Dans le dernier article que j'ai écrit sur les applications courantes et gérées, les formes courantes et gérées de "1C: Enterprise", l'article est ici.
L'avenir appartient à l'application gérée, maintenant de nombreuses configurations typiques sont construites sur la base de l'application gérée, elles comprennent:
1. «1C: Trade Management 11»;
2. "1C: Gestion d'une petite entreprise 8";
3. "1C: Flux de documents 8";
4. «1C: Enterprise Accounting 3.0»;
5. "1C: Manufacturing Enterprise Management 2.0" (sera publié prochainement);

Ces applications sont basées sur des formulaires gérés et sont automatiquement ouvertes dans le client léger.

De nombreux processus et rapports externes n'ont pas de formulaires gérés, et lorsqu'ils sont ouverts dans une application gérée, ils s'ouvriront mais seront vides, c'est-à-dire pas en tant que travailleurs, ils travaillent dans des applications ordinaires.

Un exemple de traitement d'ouverture est décrit dans l'article: ""

La plupart des génériques et autres traitements ne peuvent être exécutés que dans une application standard.

Considérons maintenant la question suivante: Comment lancer une application classique si par défaut l'application est lancée dans un client léger?

Le paramètre du configurateur doit être défini Application gérée et application régulière, puis en fonction de la priorité lors du choix du lancement de l'application.

La priorité lors du choix du lancement de l'application est la suivante:
1. La propriété de l'enregistrement de l'infobase est analysée en premier.
2. La seconde consiste à analyser si l'utilisateur est obligé de configurer une application standard ou gérée. Si la valeur est Auto, la transition vers le niveau suivant est effectuée.
3. Et le dernier est analysé le mode principal du lancement de la configuration.

Afin de saisir le moment où l'application démarre et le moment où le travail est arrêté, il sert.

Examinons chacun des points plus en détail

La création de formulaires réguliers et gérés devient disponible si le paramètre est défini en mode configurateur Service - Général - Application gérée et application ordinaire

Priorité de lancement de l'application

La première lors du choix d'un client à lancer, la propriété d'enregistrement de l'infobase sur cet ordinateur est analysée. Pour ce faire, dans la fenêtre d'enregistrement de l'infobase, cliquez sur le bouton Modifier, allez dans le troisième onglet du formulaire d'édition de l'infobase, et dans le groupe Mode de lancement de base sélectionnez le type de client à lancer.

Seconde le mode de lancement de l'application pour un utilisateur spécifique est analysé. Il est défini dans la liste des utilisateurs. Administration - Les utilisateurs sélectionnent un utilisateur et sur l'onglet Autre dans le champ de sélection Mode de lancement sélectionnez la valeur de l'application gérée ou Application régulière.
Pour les rôles cochés dans la liste Rôles disponibles, vous devez spécifier le droit d'exécuter le client lourd.


Je publie le deuxième chapitre de mon livre "Les bases du développement en 1C: Taxi"

Chapitre 2: Application 1C commune et gérée

Dans ce chapitre, nous verrons ce que sont une application standard et une application gérée et en quoi elles diffèrent l'une de l'autre, mais avant cela, examinons le concept d '«interface».

Qu'est-ce qu'une "interface" de toute façon? En fait, il s'agit d'une frontière commune entre deux systèmes en interaction (très souvent une personne est un système). Prenons une voiture, par exemple. At-il une interface? Oui bien sûr. Mais quelle est la frontière commune entre une voiture et une personne? Tout d'abord, c'est un lieu de travail, c'est-à-dire directement le siège conducteur et les commandes (volant, pédale d'accélérateur, pédale de frein, etc.). Deuxièmement, ce sont les principes de l'interaction homme-voiture, qui sont une sorte d'ensemble de règles. Par exemple, pour accélérer la voiture, vous devez appuyer sur la pédale d'accélérateur, pour ralentir - la pédale de frein, pour tourner à droite, vous devez dévisser le volant vers la droite, etc. Grâce à ces deux entités, une personne peut conduire une voiture. Enlevez une chose et la conduite ne sera pas possible.

C'est la même chose dans le monde du logiciel. Un système est une personne - un opérateur, un utilisateur. Et le deuxième système est une application créée pour automatiser un certain type d'activité humaine (nous envisageons la programmation appliquée).

Par exemple, nous devons gérer indépendamment les registres de l'entrepôt: pour effectuer l'arrivée des marchandises à l'entrepôt, radier ce produit et surveiller les soldes. Quelle sera la frontière commune entre l'application, peu importe comment et où elle est écrite, et l'utilisateur? Premièrement, ce sont les organes de saisie des informations - sinon, comment pouvez-vous transférer au programme que 5 pièces d'un produit sont arrivées à l'entrepôt. Dans notre cas, il s'agit d'un clavier d'ordinateur et d'une souris d'ordinateur. Deuxièmement, c'est un système d'interaction entre un ordinateur et une personne. Par exemple, il peut s'agir d'une interface de ligne de commande: vous utiliserez le clavier pour saisir différentes lignes de texte (commandes) et les utiliserez pour effectuer les actions nécessaires (enregistrer l'arrivée des marchandises, la consommation des marchandises, etc.). Une telle interface ressemble à ceci: voir fig. 1.2.1.

Figure. 1.2.1 Exemple de ligne de commande

Cette figure montre la ligne de commande du système d'exploitation Windows, avec l'aide de celle-ci, vous pouvez effectuer presque toutes les opérations que vous faites dans l'Explorateur: copier des fichiers, supprimer des fichiers, créer des répertoires, etc.

Ce type d'interface a longtemps été archaïque et a été remplacé par une interface utilisateur graphique (eng. interface utilisateur graphique GUI). Dans cette interface, l'interaction entre l'utilisateur et l'application se fait à travers différents éléments graphiques dessinés sur l'écran (boutons, icônes, interrupteurs, etc.). Dans l'interface graphique, l'opérateur a un accès aléatoire via les commandes à tous les éléments graphiques. Dans notre cas, lorsque nous automatisons la comptabilité d'entrepôt, l'interaction peut ressembler à ceci: l'opérateur clique sur le bouton «Arrivée», le formulaire de sélection de produit s'ouvre, où l'opérateur sélectionne le produit souhaité dans la liste et entre sa quantité. Si vous avez besoin de faire une dépense, l'opérateur clique sur le bouton «Consommation», le formulaire de sélection s'ouvre également, où l'opérateur sélectionne également le produit souhaité et entre sa quantité. Lorsqu'il est nécessaire de rapprocher les soldes, l'opérateur clique sur le bouton «Balances» et le programme affiche les soldes des marchandises dans l'entrepôt. Ainsi, en utilisant cette interface graphique, vous pouvez suivre avec succès les marchandises dans l'entrepôt.

Terminons par la partie théorique et passons directement au sujet de ce chapitre. À savoir, aux types d'interfaces d'application du programme 1C, qui sont toutes des interfaces utilisateur graphiques. Le programme 1C: Enterprise 8 dispose de deux types globaux d'interfaces d'application graphiques. Il s'agit du mode Application normal et du mode Application sous Managed Forms (ou Managed Application).

Plateformes édition 8.0 et 8.1. ne fonctionnant qu'en mode normal, les versions supérieures de la plate-forme (8.2, 8.3, etc.) peuvent fonctionner à la fois en mode d'application normal et en mode d'application gérée.

Mode d'application normal

Pratiquement toutes les configurations modernes s'exécutent déjà en mode géré, mais il existe encore des organisations qui utilisent des configurations héritées qui s'exécutent en mode d'application normal. Par conséquent, vous devez savoir comment fonctionne une application typique. Ceci est discuté en détail dans mon livre (chapitres 3 et 4). Nous n'aborderons ici que les points les plus généraux.

Le mode d'application normal utilise l'interface et les formulaires utilisés dans les plates-formes 8.0 et 8.1. Auparavant, ce mode n'était appelé d'aucune façon, mais maintenant il est appelé "mode d'application normal", et les formulaires qui sont utilisés dans ce mode sont appelés "formulaires normaux".

Jetons un coup d'œil à ce à quoi ressemble ce mode. Cela sera familier à beaucoup, mais certains, en particulier ceux qui n'ont pas trouvé de travail sous les plates-formes 8.0 et 8.1, le verront pour la première fois.

Après avoir chargé le programme, l'utilisateur voit une interface avec un menu en haut (voir Fig. 1.2.2).

Fig 1.2.2 Vue de l'interface d'une application standard

En naviguant dans les éléments de menu, l'utilisateur peut ouvrir divers formulaires. Fondamentalement, ce sont des formes de listes d'ouvrages et de documents de référence (voir Fig.1.2.3), mais il peut également y avoir des rapports, des traitements, des plans de comptes, etc.

Fig. 1.2.3. Formulaire de liste de documents

À partir du formulaire de liste, l'utilisateur peut ouvrir le formulaire d'un document ou d'un ouvrage de référence (voir Fig. 1.2.4).

Figure. 1.2.4. Formulaire de document

Le développeur peut utiliser des formulaires générés automatiquement ou les concevoir indépendamment.

Le développeur doit construire les formulaires habituels avec la souris: placez les éléments nécessaires (bouton, champ, tableau) sur le formulaire, déplacez-les vers un endroit approprié et déterminez la taille (voir Fig. 1.2.5).

Fig 1.2.5. Construire des formes régulières

Très souvent, lors du développement de formulaires complexes, il était nécessaire de prendre en compte l'interaction des éléments de formulaire les uns avec les autres. Pour cela, des consolidations ont été établies. Parfois, ils se confondaient et la forme prenait une apparence pas très belle. Nous n'entrerons pas dans une grande partie de ce mécanisme et des conséquences de son utilisation abusive, car dans le cas des formes contrôlées, il a perdu de sa pertinence.

Enfin, je voudrais noter que contrairement à une application gérée, une application ordinaire ne peut fonctionner que sous un "client lourd". Dans l'ensemble, c'est la principale différence entre les formes conventionnelles et contrôlées. Parce que le mode d'application géré a été conçu spécifiquement pour fonctionner sous un «client léger».

Mode d'application géré

Alors, quelle est la fonctionnalité et la différence fondamentale entre le mode d'application géré et le mode habituel? La principale différence est l'utilisation d'une interface de commande gérée et de formulaires gérés. Analysons chacune de ces entités séparément. Qu'est-ce qu'une interface de commande gérée? Pour répondre à cette question, il est nécessaire de plonger à nouveau dans le passé.

Considérons dans sa forme la plus simple comment la configuration a été développée dans une application classique. Tout d'abord, nous avons conçu la logique métier: documents, répertoires, rapports, traitement et leur interaction les uns avec les autres. Ensuite, nous paramétrons les rôles, par exemple, un utilisateur avec le rôle "Fournisseur" avait accès au document "Arrivée de marchandises", mais pas au document "Consommation de marchandises". Et inversement, un utilisateur ayant le rôle «Vendeur» avait accès au document «Consommation de marchandises», mais pas au document «Arrivée de marchandises». L'étape suivante consistait à développer des interfaces pour chaque type d'utilisateur. Ceux qui ont pratiqué le développement sous une application ordinaire se souviennent qu'il existait un objet de configuration tel que "Interface", dans lequel il était possible de configurer chaque menu comme le menu de la Figure 1.2.2. Et dans notre cas, le développeur a dû travailler dur pour réaliser deux interfaces: une pour le fournisseur et l'autre pour le vendeur. Car s'il avait développé une interface commune dans laquelle vous pouvez ouvrir à la fois le document «Entrée de marchandises» et le document «Consommation de marchandises», il ne serait pas tout à fait correct que le fournisseur, en essayant d'ouvrir la liste des documents «Consommation de marchandises», reçoive un message système qu’il n’a pas le droit de le faire. Pour éviter cela, il était nécessaire de créer deux interfaces et de spécifier pour chaque utilisateur sur quelle interface il devait travailler.

C'est beaucoup plus facile en mode application gérée. Nous explorerons l'interface de commande gérée plus en détail dans la partie suivante. Dans cette partie, nous allons le décomposer dans les termes les plus généraux. Dans le cas de l'interface taxi, l'interface de commande gérée ressemble à ceci:

Figure. 1.2.6. Interface de commande contrôlée

Lors du développement d'une application gérée, le programmeur devra emprunter un chemin légèrement différent. Avant de développer la logique métier, nous devons définir les sous-systèmes dans lesquels nos objets seront inclus (dans une application régulière, ils existent également, mais sont plutôt de nature déclarative). Par exemple, le document «Arrivée des marchandises» sera inclus dans le sous-système «Fourniture», et le document «Consommation de marchandises» sera inclus dans le sous-système «Ventes». Parallèlement, certains objets peuvent être localisés dans plusieurs sous-systèmes à la fois: le répertoire "Produits" sera inclus dans le sous-système "Ventes", et dans le sous-système "Achats", et dans le sous-système "Marketing". Dans ce cas, le développeur n'a pas besoin de créer un objet «Interface», le système construira automatiquement le type d'interface souhaité en fonction des paramètres des droits d'utilisateur et des options fonctionnelles.

Si un utilisateur a un rôle qui n'a pas de droits pour afficher le sous-système, par exemple, "Fournir", alors lorsque l'application 1C démarre, il ne verra tout simplement pas cet élément de menu. De plus, il ne verra pas un document dans la liste du menu, auquel il n'a au moins le droit de voir.

Dans la Figure 1.2.6, vous avez vu l'interface utilisateur avec tous les droits, et, par exemple, l'interface du vendeur ressemblera à ceci:

Figure. 1.2.7. Interface utilisateur limitée

Une autre différence par rapport à l'interface habituelle est que l'utilisateur peut déterminer indépendamment l'apparence de son interface en utilisant les paramètres de navigation, les actions, les sections, etc. et "Produit". Il ressemblera à ceci:

Figure. 1.2.8. Interface utilisateur avec des fonctions épurées de la section actuelle

Nous aborderons plus en détail la personnalisation de l'interface utilisateur dans les prochains chapitres de cette partie, et nous étudierons la relation entre les rôles et l'apparence de l'interface dans la partie suivante de ce cours. En attendant, notons nous-mêmes les principales différences entre l'interface de commande gérée et celle habituelle.

  • Le type d'interface de commande gérée est configuré automatiquement à l'aide des mécanismes de la plate-forme, en fonction des paramètres des droits d'utilisateur et des options fonctionnelles.
  • L'utilisateur peut personnaliser indépendamment l'apparence de l'interface à volonté.

Voyons maintenant ce que sont les formulaires gérés.

Apprenez la programmation en 1C à l'aide de mon livre "Programme en 1C en 11 étapes"

  1. Pas de termes techniques compliqués.
  2. Plus de 700 pages de matériel pratique.
  3. Chaque tâche est accompagnée d'une photo (capture d'écran).
  4. Une collection de tâches pour les devoirs.
  5. Le livre est écrit dans un langage clair et simple - pour un débutant.
  6. Le livre est envoyé par e-mail au format PDF. Peut être ouvert sur n'importe quel appareil!


Si cette leçon vous a aidé à résoudre un problème, que vous l'avez aimé ou s'est avérée utile, vous pouvez soutenir mon projet en transférant n'importe quel montant:

vous pouvez payer manuellement:

Yandex.Money - 410012882996301
Argent Web - R955262494655

Rejoignez mes groupes.

Attention! Désormais, le cours se déroule également le soir de 18h30 à 21h30 dans un format d'immersion.

Le cours fait partie intégrante du cours complet "Travail efficace dans le système" 1C: Entreprise 8 ".

Le but de la formation: familiariser les étudiants avec le mode de fonctionnement contrôlé de la plate-forme technologique 1C: Enterprise 8, montrer aux spécialistes les approches de la construction d'un système pour utiliser cette version du système.

Le cours couvre nouveau modèle de construction de l'interface applicative, nouvelle implémentation de l'architecture client-serveur, mécanisme des formulaires. Au cours du cours, les étudiants acquerront des compétences pratiques en configuration, administration, programmation dans le progiciel étudié. Ces compétences seront acquises au fur et à mesure que le problème d'apprentissage sera résolu. L'essence de cette tâche: mettre en place la configuration fournie pour garantir la possibilité de travailler en mode «client léger».

Le cours est destiné: pour les spécialistes expérimentés dans la configuration de solutions applicatives sur la plateforme 1C: Enterprise (versions 7.7, 8.0, 8.1, 8.2 - une application commune).

Mécanismes abordés dans le cours:

  • Principes de construction d'une interface gérée
  • Nouveaux modules, contexte d'exécution du module, mécanisme d'interaction
  • Propriétés de l'interface de l'objet de configuration
  • Personnalisation de formulaire (en mode configurateur, en mode exécution)
  • Directives, programmation client / serveur, fonctionnement du formulaire géré
  • Mécanisme d'options fonctionnelles, forme des options fonctionnelles
  • Formulaires de liste, listes dynamiques
  • Le mécanisme de formation des plaques d'impression
  • Changements dans le mécanisme de composition des données (particularités de travailler dans une application gérée)
  • Modes privilégiés / sûrs
  • Stockage temporaire, nouvelle technologie pour travailler avec des fichiers, des images
  • Mécanisme d'interaction des formes, organisation de la sélection
  • Travailler avec les paramètres système, remplacer le mécanisme de stockage des paramètres
  • Sources externes
  • Mécanisme de partage de données
  • Test automatisé
  • Plateforme mobile

Le coût d'un cours de jour à temps plein comprend:

  • 2 jours de 10h00 à 17h00
  • matériel méthodologique
  • déjeuners, pauses café
  • certificat de la firme "1C"

Le coût du cours WEB comprend:

  • Cours de 5 semaines, 5 webinaires avec un enseignant
  • certificat du 1C-Training Center No.3 (soumis à la pratique)

Le coût du cours d'immersion à temps plein comprend:

  • 5 jours de 10h00 à 17h00 ou 9 soirs de 18h30 à 21h30
  • résumé, casque
  • déjeuners, pauses café
  • accès pendant 2 ans à des vidéos mises à jour après la fin du cours
  • certificat du 1C-Training Center No.3

Formats d'apprentissage

Journée à temps plein

À qui s'adresse ce format:Pour ceux qui peuvent suivre une formation à temps partiel et préfèrent une formation classique à temps plein.

Durée:16 heures académiques

Formation WEB

Quel est ce format:Le format proposé combine de nombreux avantages de l'apprentissage à distance avec une composante face à face de matériel vidéo et de consultations en ligne.
Le cours WEB se compose de vidéos, de tâches pratiques et de webinaires avec des enseignants. Tous les supports de cours sont disponibles 24h / 24 et 7j / 7 via Internet - vous pouvez étudier à un moment opportun. Le cours est divisé en classes. Pendant la leçon, du matériel sur le sujet actuel est étudié, des ateliers sont organisés, des questions sont posées à l'enseignant. À la fin de chaque leçon, un webinaire est organisé, dans lequel l'enseignant analyse toutes les questions qui ont été reçues, les erreurs typiques, et explique la bonne solution. L'enregistrement du webinaire est disponible sur le portail. De cette façon, plusieurs cours ont lieu les uns après les autres. À la fin, un dernier travail indépendant et un webinaire final sont réalisés.

Durée:5 semaines

Quel est ce format:


Durée:40 heures académiques

Quel est ce format:Le cours d'immersion à temps plein est un format qui combine tous les avantages de l'enseignement à temps plein, des technologies d'apprentissage à distance et de la formation individuelle. Les cours ont lieu dans une salle de classe équipée, vous étudiez de manière indépendante le matériel de cours (vidéos étape par étape) et réalisez des ateliers. En même temps, il y a un enseignant dans la classe qui est prêt à tout moment à répondre à une question et à aider à résoudre des problèmes pratiques, ainsi qu'à vérifier l'exactitude de leur mise en œuvre.
Avantages - consultations individuelles de l'enseignant sur vos questions, rythme de passage du matériel qui vous convient personnellement.
Tout cela donne une étude plus approfondie du matériel de cours.
Il est possible de suivre ce cours depuis votre lieu de travail avec le plein effet de la présence du professeur là où se trouve l'étudiant! Si cette opportunité vous intéresse, appelez-nous!

Durée:40 heures académiques

Programme de cours

BUTS ET OBJECTIFS DU COURS

INTRODUCTION

1. OPTIONS DE FONCTIONNEMENT

2. STRUCTURE TECHNIQUE DE L'INTERACTION

  • Option client-serveur:
  • Option de fichier:
  • Protocoles utilisés
  • Structure du cluster de serveurs
  • Séances
  • Types de modules, caractéristiques communes

3. INTERFACE DE COMMANDE

  • Sous-systèmes
  • Commandes
  • Préréglage
  • Améliorer l'interface

4. PROPRIÉTÉS DE L'INTERFACE

  • Représentation personnalisée des objets
  • Conditions requises standard
  • Contrôle du remplissage des détails des objets
  • Définition de la valeur par défaut
  • Utiliser la subordination

5. OPTIONS FONCTIONNELLES

6. FORME CONTRÔLÉE

  • Réglage de la boîte de dialogue
  • Définition des gestionnaires d'événements
  • Calcul du montant du document
  • Vérifier le remplissage, les messages
  • Manipulation du remplissage
  • Utilisation de l'interrupteur à bascule
  • Gestion des modes privilégiés
  • Mode sans échec
  • Nouvelle méthodologie de conduite par registres
  • Modèle de formulaire géré basé sur les événements
  • Formulaire d'options fonctionnelles
  • Afficher les mouvements de registre

7. CRÉATION D'UN FORMULAIRE D'IMPRESSION

  • Décryptage simple

8. FORMES DE LA LISTE

  • Forme de la liste de documents "Vente de marchandises"
  • Formulaire de sélection de l'ouvrage de référence "Nomenclature"
  • Utilisation du gestionnaire "OnFetchingDataOnServer"
  • Récupération des données affichées par une liste dynamique

9. REFUS DES APPELS MODAUX.

10. STOCKAGE TEMPORAIRE

  • Travailler avec des fichiers (images)
  • Organisation de la sélection

11. RAPPORTS GÉRÉS

  • Rapport d'élément restant
  • Options de rapport
  • Paramètres personnalisés
  • Obtenir la valeur de déchiffrement

12. HISTORIQUE DES DONNÉES

13. MÉCANISME DES UNITÉS

14. LIMITES DE L'INTERVALLE DE STOCKAGE

15. TYPES DÉFINIS

16. BUREAU

17. ENREGISTREMENT DES PARAMÈTRES

  • Enregistrement des paramètres de rapport

18. DÉTAILS GÉNÉRAUX

  • Définition d'attributs communs pour les objets
  • Mécanisme de partage de données

19. EXTENSIONS DE CONFIGURATION

20. PLANIFICATEUR

21. SOURCES DE DONNÉES EXTERNES

  • Accéder à la connexion à la base de données

22. TESTS AUTOMATISÉS

23. PLATEFORME MOBILE

  • Introduction (extraits de "http://v8.1c.ru/overview/Term_000000818.htm")
  • Développement de bases de données
  • Préréglage
  • Créer une application mobile
  • Tester l'application

Les pré-requis techniques:

  • accès Internet (vous pouvez vérifier votre canal de communication en vous connectant à l'accès "test"),
  • disponibilité de la plateforme 1C: Enterprise 8.3 pour pratiquer les tâches pratiques du cours.

Vous pouvez utiliser la version "1C: Enterprise 8.3" pour l'enseignement de la programmation.

Partagez ceci