Nos spécialistes ont aidé le client à élaborer Spécifications techniques pour la modernisation du système de ventilation.

Plus de détails sous la coupe..

Tâche technique

pour la modernisation des équipements technologiques des systèmes de ventilation du bâtiment de laboratoire n° 451 452, bâtiment 17 à l'adresse : Moscou

1. Dispositions générales

1.1. Cette mission technique prévoit la réalisation de travaux de modernisation des équipements technologiques, des systèmes de contrôle et d'automatisation des unités de ventilation du bâtiment, laboratoires n° 451 452 du bâtiment 17.

1.2. Pour réaliser les travaux, élaborer une documentation de travail pour les sections des marques AOB, EM, XS, AHS, AK, qui doivent être convenues conformément à la procédure établie.

1.3. Réaliser des travaux dans le respect des exigences de la documentation réglementaire et technique.

1.4. Une fois les travaux terminés, présentez la documentation telle que construite réalisée conformément aux exigences de GOST et SNiP.

1.5. Remettre le travail terminé au Client.

1.6. Certaines dispositions de la présente Spécification Technique pourront être clarifiées en cours de travaux en accord avec le Client.

2. Exigences techniques

2.1. Modernisation des unités de contrôle de chaleur et de refroidissement pour les unités de ventilation.

2.1.1. Unités de contrôle de l'alimentation en chaleur.

Les éléments suivants font l'objet d'une modernisation :

· des centrales de régulation de l'apport de chaleur pour le premier chauffage des unités de ventilation K1, K2, K2a, K4 du bâtiment MIK-V, P2, P6 du laboratoire n°452, P1 du laboratoire.

· régulateurs d'alimentation en chaleur pour le deuxième chauffage des unités de ventilation K1, K2, K2a du bâtiment MIK-V.

Les unités de régulation d'alimentation en chaleur existantes font l'objet d'un démontage, tandis qu'une partie des équipements des unités de régulation (pompes de circulation, vannes d'arrêt) correspondant à l'état et spécifications techniques, à utiliser dans les unités de contrôle montées.

La composition des équipements des centrales installées, ainsi que les équipements utilisés, sont indiqués en annexe n°1.

Réaliser des essais hydrauliques des circuits de chauffage et des réchauffeurs des unités de ventilation avec exécution d'un rapport d'essais hydrauliques.

Réaliser des travaux de peinture de canalisations et d'isolation thermique.

2.1.2.Unités de régulation de l'alimentation en froid des unités de ventilation.

Les groupes frigorifiques des groupes de ventilation K1, K2, K2a, K4 du bâtiment MIK-V, P2, P6 du laboratoire « 452 », P1 du laboratoire n°451 font l'objet d'une modernisation.

Étendue des travaux:

· remplacement des vannes thermostatiques des unités de contrôle de réfrigération ;

· démontage/installation du ventilateur de l'unité compresseur-condensation K1 ;

· démontage/installation des filtres déshydrateurs des unités compresseur-condensation K1, K2 ;

· démontage/installation de l'évaporateur de l'unité de ventilation K4 ;

· tests de pression dans un environnement de gaz inerte, mise sous vide, remplissage des circuits frigorifiques en fréon ;

· restauration de l'isolation thermique des canalisations.

2.1.3. Unités d'alimentation pour circuits d'humidification.

Installez des filtres de purification d'eau froide au niveau des unités de réapprovisionnement des chambres d'irrigation des climatiseurs K1, K2, K2a.

2.2. Armoires de contrôle et d'automatisation pour unités de ventilation.

Armoires de commande pour unités de ventilation K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8, bâtiments MIK-V, P2, P6, V1, V2, V3 laboratoires n°451, laboratoires P1, V1 Les n°451 font l'objet d'un démantèlement 452.

Disposition des panneaux de contrôle nouvellement installés :

SHUA K1 – armoire de commande et d'automatisation pour l'unité de ventilation et l'unité compresseur-condenseur (KKB) du climatiseur K1 (MIK-V) ;

SHUA K2 – armoire de commande et d'automatisation pour l'unité de ventilation et unité de commande pour le climatiseur K2 (MIK-V) ;

SHUA K2 – armoire de commande et d'automatisation pour l'unité de ventilation et unité de commande pour le climatiseur K2a (MIK-V) ;

SHUA K4 – armoire de commande et d'automatisation pour l'unité de ventilation et unité de commande pour le climatiseur K4 (MIK-V) ;

SHUV – armoire de commande pour unités d'extraction RU3, V1, V2, V3, V6, V7, V8 (MIK-V) ;

SHUA P2, P6 – armoire de contrôle et d'automatisation des unités de ventilation et des unités à compresseur-condensation P2, P6 (laboratoire n° 452) ;

SHUV – armoire de commande pour unités d'extraction V1, V2, V3 (laboratoire n° 452) ;

SHUA P1,V1 – armoire de commande et d'automatisation pour unités de ventilation P1, V1 (laboratoire n° 451).

Les armoires de commande modernisées doivent fournir :

· sélection, depuis le panneau avant de l'armoire, du mode de contrôle des unités de ventilation (manuel/automatique) ;

· signalisation lumineuse des modes de fonctionnement normal et d'urgence des équipements de traitement des unités de ventilation (fonctionnement/urgence) ;

· arrêter les unités de ventilation en cas d'incendie ;

· activation automatique des protections et blocage du fonctionnement des équipements en cas de situations d'urgence.

Les convertisseurs de fréquence pour contrôler les moteurs électriques des ventilateurs et des pompes sont susceptibles d'être utilisés ultérieurement.

2.3. Système d'automatisation et de répartition

Le système d'automatisation et de répartition est conçu pour gérer et surveiller le fonctionnement des unités de ventilation, ainsi que pour collecter, traiter, présenter et stocker les informations entrantes.

2.3.1. Système d'automatisation.

Le système d'automatisation doit assurer, fondamentalement, un fonctionnement autonome des unités de ventilation, qui ne nécessite pas l'intervention du personnel de maintenance et un passage, si nécessaire, au mode de contrôle manuel. Pour toute option de contrôle et quel que soit l'état du contrôleur local, la condition d'arrêt automatique du système de ventilation générale en cas d'incendie doit être maintenue. La déconnexion doit être effectuée individuellement pour chaque système tout en maintenant l'alimentation des circuits de mise hors gel.

L'automatisation locale des systèmes de ventilation devrait inclure :

· régulation de la température de l'air soufflé à la sortie de l'unité de ventilation ou, le cas échéant, de la température de l'air extrait du local viabilisé ;

· régulation de l'humidité de l'air soufflé ;

· arrêter les ventilateurs et fermer les vannes d'air lorsqu'une alarme incendie se déclenche ;

· éteindre l'humidification du climatiseur lorsque son ventilateur s'arrête ;

· ouverture et fermeture de la vanne d'air, respectivement, lors du démarrage et de l'arrêt du ventilateur ;

· chauffage automatique des radiateurs avant de démarrer les systèmes en mode hiver ;

· protection contre le gel des chauffe-air et eau (arrêt du ventilateur, fermeture du registre d'air, ouverture de la vanne de chauffage à 100 %) ;

· arrêt du ventilateur en l'absence de chute de pression ;

· contrôle de la contamination des filtres de l'installation.

L'influence à distance sur l'automatisation locale avec poste de travail automatisé est déterminée dans le volume suivant :

· modifier les paramètres des contrôleurs de température et d'humidité ;

· activer/désactiver les paramètres.

Les équipements périphériques existants du système d'automatisation sont soumis à une vérification, un nettoyage et une utilisation ultérieure dans l'ordre suivant :

· les capteurs de température et d'humidité des unités de ventilation sont soumis à vérification ;

· les capteurs du pressostat différentiel doivent être vérifiés et nettoyés ;

· Les thermostats destinés à protéger les radiateurs des appareils de ventilation contre le gel doivent être remplacés.

· les entraînements des vannes de régulation des unités de commande doivent être remplacés conformément à la clause 2.1.1.

· les entraînements de vannes d'air sont soumis à une inspection et à une utilisation ultérieure ;

Pour contrôler la recirculation du climatiseur K1, remplacez les entraînements de vanne d'air tout ou rien par des vannes avec un signal de commande de 0..10V.

2.3.2. Système de répartition.

Le système de répartition doit inclure les éléments suivants :

· un complexe d'appareils de mesure, d'actionneurs et d'équipements d'automatisation basés sur les logiciels et le matériel Honeywell ;

· système de câbles multifonctionnel ;

· complexe de logiciels et de matériel pour le centre de répartition.

Pour l'expédition des systèmes de ventilation, prévoir l'affichage, l'archivage et la journalisation des informations suivantes :

· représentation graphique des installations avec capteurs de température et d'humidité, thermostats antigel, pressostats différentiels, vannes de régulation, humidificateurs, vannes d'air ;

· numéros d'installation ;

· relevés de capteurs de température et d'humidité ;

· lectures du capteur du relais de pression différentielle ;

· relevés de position des vannes de régulation 0..100% ;

· mode fonctionnement/arrêt du ventilateur ;

· mode de fonctionnement/arrêt des pompes ;

· position des vannes d'air « ouvertes/fermées » ;

· arrêter les systèmes lorsqu'une alarme incendie se déclenche ;

· arrêter les systèmes en cas de risque de gel du radiateur ;

· arrêter l'installation s'il n'y a pas de chute de pression aux bornes du ventilateur ;

· éteindre l'humidificateur d'air lorsque le ventilateur du climatiseur s'arrête ;

· exploitation des systèmes selon un horaire donné ou sans celui-ci ;

· signalisation des accidents et des situations d'urgence en cas de dysfonctionnement des équipements, ainsi que lorsque les valeurs des paramètres technologiques dépassent les plages spécifiées ;

· enregistrement des accidents et des situations d'urgence dans le journal des messages ;

· Journal d'enregistrement des paramètres pour l'heure actuelle, indiquant le nom des paramètres contrôlés, les unités de mesure, le numéro du contrôleur et le canal d'entrée/sortie.

2.3.3. L'alimentation électrique du système d'automatisation et de répartition doit être réalisée à partir d'un réseau de courant alternatif avec une tension de 380/220 V, une fréquence de 50 Hz à l'aide de sources Alimentation sans interruption sur piles rechargeables et fourni comme alimentation pour les récepteurs électriques de la première catégorie

Dans la vie, il arrive souvent qu'une personne ne puisse pas expliquer ce qu'elle veut, même dans les choses de tous les jours. Lorsqu'il s'agit d'expliquer ses « désirs » à un programmeur, une personne tombe tout simplement dans la stupeur.

Idéalement, les spécifications techniques devraient être établies par le client – ​​lui seul sait ce dont il a besoin. Mais dans la pratique, en raison de la faible compétence du client dans le domaine 1C, cela doit souvent être fait par l'entrepreneur. Le client exprime verbalement ses besoins et le programmeur (consultant) les met par écrit.

Pourquoi avez-vous besoin de spécifications techniques ?

Idéalement, tout devrait être accompagné de spécifications techniques. Il s'agit d'abord d'une définition claire de la tâche, des délais et du mode de mise en œuvre. Deuxièmement, il s'agit d'un document à l'aide duquel toutes les questions controversées à l'avenir sont résolues. Rédiger ou non des spécifications techniques est bien entendu votre affaire ; pour moi personnellement, les spécifications techniques facilitent mon travail et ma communication avec le client.

Obtenez 267 leçons vidéo sur 1C gratuitement :

Que doit contenir le mandat ?

Ceux. la mission doit contenir :

• cible— le problème que nous allons résoudre en implémentant cette spécification ;
• description — résumé améliorations à venir ;
• méthode de mise en œuvre — Description détaillée méthodes pour résoudre l'objectif. À ce stade, il est nécessaire de décrire toutes les nuances de la tâche dans le langage du programmeur : quel type de tâches nous créons/modifions, à quoi devrait ressembler l'interface, etc. Si vous ne parlez pas le « langage du programmeur », mais « avez entendu quelque chose », il vaut mieux ne pas essayer d'écrire dans un langage technique - cela s'avère assez amusant. La description doit être sans ambiguïté et ne pas soulever de questions. Il peut également contenir un exemple de mise en œuvre d’une solution similaire dans un autre domaine ;
• évaluation des performances- un point très important, une description des coûts de main d'œuvre.

Il existe également des normes nationales pour la rédaction de spécifications techniques - GOST. En pratique, ils sont rarement utilisés, mais parfois le client insiste.

Par expérience, lors de la remise des travaux, il arrive très souvent des situations du genre « on vous l'avait dit alors... », ce qui n'est pas très agréable, et il faut souvent refaire tout le travail. Par conséquent, une spécification technique bien rédigée facilite grandement la vie des deux parties.

Exemples et échantillons de spécifications techniques pour 1C

Une petite sélection que j'ai trouvée disponible gratuitement sur Internet. Du plus simple et du plus accessible aux documents assez complexes.

Du fait que les gens demandent souvent des exemples de spécifications techniques, je partage une partie de mon travail avec la communauté. Ces documents n'ont aucune valeur commerciale (en raison de leur âge et de leur configuration), mais j'espère qu'ils pourront être utiles comme exemples.

Tâche technique :

automatique

Système de VENTE.

Tâche technique

Sur les feuilles

"_" ______________ 2010

1. Informations générales

Nom du système automatisé

"AS Sbyt"

Client

Exécuteur

Base du travail

Dates prévues pour le début et la fin des travaux de création du système

Début des travaux : 01.09.2010

Fin des travaux : 31/12/2010

But et objectifs de la création du système

Objectif du système

Le système automatisé en cours de développement est conçu pour automatiser les processus de vente d'une entreprise.

Objectifs de la création du système

Objectifs de la création d'un système automatisé

Les objectifs du développement de « AS Sbyt » sont :

1. 3. Caractéristiques de l'objet d'automatisation

3.1 Processus métier de l'entreprise

3.1. 1 Processus métier « Conclusion d'un accord »

3.1.2. Processus métier « Calcul des paiements »

1. 4. Configuration requise.

4.1. Exigences pour le système dans son ensemble.

4.1.1. Méthodes développées à AS et modules logiciels devrait contenir des opportunités de développement ultérieur du système.

5.1.1. Le système en cours de développement doit être constitué de systèmes automatisés, de sous-systèmes et de modules comptables, répartis en fonction de leur objectif fonctionnel conformément à la méthodologie établie pour la construction de systèmes automatisés de classe financière et économique.

5.1.2. L'AS en cours de développement devrait garantir la facilité de mise en place d'un poste de travail automatisé (AWS) pour chaque artiste spécifique conformément au système comptable existant.

5.1.3. L'AS en cours de développement doit assurer la différenciation des droits d'accès des utilisateurs et offrir la possibilité d'accéder à l'information dans la mesure nécessaire et suffisante pour exercer les fonctions officielles de chaque artiste interprète ou exécutant.

5.1.4. La protection des informations contre tout accès non autorisé doit être mise en œuvre à l'aide des mécanismes suivants :

1. Restrictions des droits d'accès au niveau de la plateforme 1C:Enterprise 8.1.

2. Restrictions supplémentaires sur les droits d'accès au niveau de l'environnement d'exécution.

5.1.4.1.La priorité devrait être donnée aux restrictions des droits d'accès au niveau de la plateforme. La suppression de restrictions supplémentaires au niveau de l'exécution ne donne pas de droits d'accès aux objets ou aux fonctions du système si une restriction système leur est imposée.

5.1.4.2. Protection des informations au niveau de la plateforme

· La protection des informations au niveau de la plate-forme est assurée par des moyens système. Celui-ci réglemente les droits de lecture et de modification des objets système, d'utilisation des interfaces, fonctions du système et effectuer des opérations de routine avec des données Système d'Information.

· Tous les droits d'accès doivent être systématisés dans des ensembles appropriés - Rôles du système d'information.

· La liste des utilisateurs du système d'information doit être déterminée par l'administrateur du système.

· Les droits d'accès de chaque utilisateur doivent être déterminés par l'ensemble des Rôles système d'information dont il dispose.

· Les ensembles de rôles du système d'information disponibles pour chaque utilisateur doivent être déterminés par l'administrateur système.

· Lorsqu'il commence à travailler dans le système, l'utilisateur doit suivre la procédure d'autorisation en indiquant son nom dans le système et son mot de passe.

5.1.4.3. Protection des informations au niveau de l'exécution

Pour un certain nombre de répertoires du système, des restrictions supplémentaires sur les droits d'édition doivent être prévues.

Répertoires pour lesquels il est nécessaire d'interdire l'édition dans le système :

• Abréviations d'adresses
• Devises
• Types de règlements mutuels
• Types d'activités des contreparties
• Groupe d'utilisateurs
• Documents d'identité
• Postes dans l'organisation
• Divisions
• Utilisateurs
• Éléments de flux de trésorerie
• Dépenses
• Les taux

5.1.5. Pour assurer la sécurité des informations en cas d'accident, un archivage automatique quotidien des données doit être assuré.

5.1.6. Exigences en matière d'ergonomie et d'esthétique technique

5.1.6.1. Pour assurer l'unification de la conception des interfaces utilisateur, les barres d'outils et les menus contextuels générés automatiquement par la plate-forme 1C doivent être utilisés par défaut.

5.1.6.2. La terminologie utilisée pour désigner les objets et les actions des utilisateurs dans le système doit correspondre à la terminologie standard du domaine.

5.2. Exigences pour la structure et le fonctionnement de l'AS "SABYT".

5.2.1. AS "Sbyt" devrait être composé des sous-systèmes automatisés suivants :

Sous-système de saisie des informations primaires sur l'abonné (conclusion d'un accord) ;

Sous-système de génération de documents de paiement ;

Sous-système de communication avec le système ASKUE ;

Sous-système de communication avec les terminaux de paiement.

5.2.2. La composition du sous-système de saisie des informations primaires sur l'abonné (conclusion d'un accord) doit être la suivante :

Document « Accord avec l'abonné » ;

5.2.3. La composition du sous-système de génération des documents de paiement doit être la suivante :

Document "Reçu"

Document « Accumulation des pénalités »

Document "Énergie consommée"

Module de vérification de l'état des règlements mutuels

5.2.4. La composition du sous-système de communication avec le système ASKUE devrait être la suivante :

Module Communication avec le système ASKUE.

5.2.5. La composition du sous-système de communication avec les terminaux de paiement devrait être la suivante :

Module Communication avec les terminaux de paiement.

5.3. Exigences relatives aux fonctions du module Sous-système de saisie des informations primaires sur un abonné (conclusion d'un accord)

5.3.1. Le sous-système de saisie des informations primaires sur l'abonné (conclusion d'un accord) doit remplir les fonctions suivantes :

Saisir et stocker des informations sur la capacité installée de la contrepartie (ci-après dénommée l'abonné) ;

Saisir et stocker des informations sur les compteurs installés de l'abonné ;

Saisir et stocker des informations sur les tarifs des abonnés ;

Saisir et conserver les informations sur les conditions de calcul des pénalités pour l'abonné ;

Saisir et stocker des informations sur la durée du contrat ;

5.4. Exigences relatives aux fonctions du sous-système de génération des documents de paiement

5.4.1. Le sous-système de génération des documents de paiement doit remplir les fonctions suivantes :

Déterminer l'état des règlements mutuels avec le souscripteur et déterminer les conditions de survenance des pénalités.

Génération des documents de paiement (reçus ou factures).

5.5. Exigences pour les fonctions du sous-système de communication avec le système ASKUE

5.5.1. Le sous-système de communication avec le système ASKUE doit remplir les fonctions suivantes :

Transfert de données sur les contrats nouvellement conclus avec les abonnés. La clé de communication doit être l'unicité du couple « ID d'abonné » - « Code d'accord d'abonné ».

Obtention de données sur la consommation électrique de l'abonné. La clé de communication doit être l'unicité du couple « Counter ID » - « Counter Code ».

5.6. Exigences relatives aux fonctions du sous-système de communication avec les terminaux de paiement

5.6.1. Le sous-système de communication avec le système ASKUE doit remplir les fonctions suivantes :

Réception de données sur les paiements effectués par les abonnés pour l'électricité via les terminaux de paiement.

1. 6. La procédure de contrôle et d'acceptation de l'AIS « VENTES ».

6.1. La procédure suivante est établie pour la présentation et la livraison des résultats des travaux au Client :

6.1.1. L'entrepreneur démontre la fonctionnalité du logiciel à l'aide d'un exemple de test.

6.1.2. Les données du scénario de test sont préparées par les représentants du Client.

6.1.3. L'Entrepreneur transmet logiciel au service d'information du Client et forme l'administrateur du Client.

6.1.4. Sur la base des résultats de la solution du scénario de test, un certificat de transfert de logiciel pour une opération d'essai doit être préparé.

6.1.5. En cas de non-conformité Fonctionnalité Selon les exigences des spécifications techniques, l'Entrepreneur élimine les commentaires dans le coût total de développement du SA.

6.1.6. Si des exigences supplémentaires du client par rapport aux spécifications techniques surviennent, une spécification technique supplémentaire à réviser est établie.

6.1.7. La présence d'exigences supplémentaires du client ne doit pas constituer un motif de refus de signer le certificat de transfert de logiciel pour une opération d'essai.

6.1.8. Après avoir transféré le logiciel en opération d'essai, conformément au calendrier de mise en œuvre convenu avec le client, l'entrepreneur forme brièvement le personnel du client à l'utilisation du logiciel et transfère les instructions pour travailler avec le logiciel à chaque sous-système.

6.1.9. Lors de la mise en œuvre du logiciel (opération d'essai), le Client effectue :

Saisir les données de référence requises ;

Saisir des données réelles ;

Générer des rapports et vérifier les résultats des travaux.

6.1.10. Au cours du processus de mise en œuvre, le Contractant doit fournir une assistance au Client dans le cadre du Calendrier de mise en œuvre.

6.1.11. En cas de mauvaise préparation du personnel du Client pour la mise en œuvre et de nécessité d'une assistance supplémentaire de la part du Prestataire pour une mise en œuvre réussie du logiciel, un protocole complémentaire doit être établi pour convenir des prix contractuels pour la fourniture d'informations et de travaux de conseil.

6.2.La procédure de prise en charge ultérieure des tâches de l'AS « VENTES ».

6.2.1. Après la mise en service du logiciel, des modifications supplémentaires et les souhaits du Client peuvent être mis en œuvre conformément aux spécifications techniques convenues avec le Client.

Les TDR doivent indiquer la complexité et le coût des travaux pour mettre en œuvre des exigences supplémentaires.

6.2.2. L'Entrepreneur s'engage à maintenir le téléphone " ligne d'assistance"pour le support logiciel.

6.2.3. À la demande du Client, le Prestataire peut fournir un support logiciel directement auprès du Client, qui doit être effectué sur la base d'un accord complémentaire de support logiciel.

6.2.4. Les erreurs identifiées par le client dans un délai de six mois à compter de la date de mise en service du logiciel doivent être corrigées par le contractant dans les plus brefs délais et gratuitement.

Si l'entrepreneur découvre que l'erreur est survenue à la suite d'actions incorrectes du client, le temps passé par l'entrepreneur pour la trouver et l'éliminer doit être payé en plus.

6.2.5. Le client, dans l'année suivant l'achat de 1C : Entreprise, a le droit de recevoir gratuitement toutes les mises à jour de la société 1C liées au développement des programmes 1C et aux modifications de la législation. L'installation des modifications doit être effectuée par le système de contrôle automatisé du Client.

6.2.6. Le Prestataire garantit la confidentialité du contenu des bases de données du Client et de toute autre information reçue du Client lors du développement, de la mise en œuvre ou de la maintenance de l'AS.

Projet technique :

J'AI APPROUVÉ JE SOUMETTRE POUR APPROBATION

" "______________ 2010 " "_______________ 2010

Annexe aux spécifications techniques en date du « ____ » ________ 2010

automatique

Système de VENTE.

Projet technique

Sur les feuilles

Valable à partir du "__" ____________ 2010

Annuaires. 3

Compteurs. 3

Tarifs.. 3

Sous-stations. 3

Options de pénalité. 3

Transferts. 4

Types de frais. 4

Registres d'informations. 4

Signification des tarifs. 4

Tarifs abonnés. 4

Données des compteurs. 5

Registres d'accumulation. 5

Consommation d'énergie. 5

Documents.. 6

Accord avec l'abonné.. 6

Énergie consommée. 6

Reçu. 7

Calcul des pénalités. 9

Traitement. dix

Réception des données du système ASKUE. dix

Récupération de données de Système de paiement.. 11

Annuaires

Compteurs

Conditions requises :

Les taux

Détails : non

Options de pénalité

Détails : non

Transferts

Types de frais

Valeurs:

Registres d'informations

Durée des contrats

Fréquence : Non périodique

Objectif : Conçu pour stocker les durées de validité des contrats avec les abonnés

Des mesures

Signification des tarifs

Fréquence : Jour

Objectif : Conçu pour stocker les tarifs et les dates à partir desquelles les tarifs commencent à s'appliquer

Des mesures

Accessoires		But
		Coût du tarif journalier
		Coût du tarif de nuit (ne peut pas être précisé)

Tarifs abonnés

Fréquence : Jour

Objectif : Conçu pour stocker les tarifs attribués à l'abonné selon les contrats

Des mesures

Accessoires		But
	Tarifs Annuaire	Tarif abonné

Données des compteurs

Fréquence : Jour

Objectif : Conçu pour stocker les relevés du compteur pour une charge ultérieure

Des mesures

Accessoires		But
IndicationsJour		Relevé du compteur
IndicationsNuit		Relevé du compteur

Registres d'accumulation

Consommation d'énergie

Objectif : Conçu pour stocker des informations sur la consommation d'énergie pour une facturation ultérieure

Type de registre : négociable

Des mesures

Documentation

Accord avec l'abonné

Objectif : Conçu pour refléter le fait de conclure un accord avec l'abonné

Accessoires		But
Contrepartie	Entrepreneurs d’annuaire
Accord de contrepartie
	Tarifs Annuaire
Alimentation branchée		Stocker la puissance installée de l'abonné en KW
Date de débutAction		Date à partir de laquelle le contrat est valable
Date de finAction		Date de fin du contrat
Organisation	Répertoire des organisations
Possibilité d'accumulation d'amendes
Nomenclature	Nomenclature de l'annuaire
Réglage manuel		Signe d'ajustement manuel des entrées de documents

Partie tableau : Compteurs et Tarifs

Publier un document

Le document est réalisé :

D'après le registre d'information « Relevés de compteurs », où sont enregistrés les compteurs et les relevés initiaux de l'abonné ;

Selon le registre d'information « Tarifs Abonnés », où est enregistré le tarif établi pour l'abonné à partir de la date de début du contrat.

Selon le registre d'information « Durées de validité des contrats », où le contrat est rédigé, la date de début et la date d'expiration du contrat

Énergie consommée

Objectif : Conçu pour refléter les relevés de compteurs à une date précise

Remplir le document

Le document peut être rempli de deux manières : manuellement et en appelant le traitement « Réception des données de l'ASKUE ».

Publier un document

Le document est réalisé :

D'après le registre d'information « Relevés des compteurs », où les relevés des compteurs sont enregistrés à la date du document ;

D'après le registre d'accumulation « Énergie consommée selon l'algorithme suivant :

1. Les relevés des compteurs sont extraits du registre d'information « Relevés des compteurs » à la date du document et des relevés de compteurs précédents.

2. Les différences de valeurs de lecture sont inscrites dans les ressources correspondantes du registre d'accumulation.

Formulaires imprimables

Registre des relevés de compteurs

Reçu

Objectif : Conçu pour refléter les frais facturés aux abonnés

Remplir le document

Le document peut être rempli de deux manières : par saisie manuelle et en appelant le traitement « régularisation des paiements »

Partie tabulaire : Relevés de compteurs

Accessoires		But
Contrepartie	Entrepreneurs d’annuaire
Accord de contrepartie	Annuaire Contrats des contreparties
Nomenclature	Nomenclature de l'annuaire
	Tarifs Annuaire	Tarif abonné selon le contrat
	Compteurs d'annuaire
TypeAccumulations	Types de transfert de provisions
Énergie consommée		Énergie consommée
Valeur tarifaire		Valeur tarifaire à la date du document
Accumulé		Montant facturé à l'abonné

Publier un document

Le document est réalisé :

D'après le plan comptable fiscal :

Formulaires imprimables

Registre des charges

Algorithme de remplissage

Le document est rempli sur la base de l'ouvrage de référence « Accords de contrepartie ».

1. Dans l'annuaire sont sélectionnés les contrats pour lesquels, selon le registre d'information « Périodes de validité des contrats », la Date de Début est inférieure à la date du document et la Date de Fin est supérieure à la date du document ;
2. Les compteurs correspondant à ces contrats sont sélectionnés ;
3. Pour les compteurs, la consommation d'énergie est déterminée comme le chiffre d'affaires dans le registre d'accumulation « Consommation d'énergie » pour la période comprise entre la date du document et la date du document précédent ; si la date du document précédent est inconnue, alors la totalité du chiffre d'affaires en le registre est pris. La valeur résultante est enregistrée dans le champ « ConsumedEnergy »
4. Le tarif est établi conformément au contrat et à la valeur du tarif à la date du document ;
5. Le type d'accumulation est défini sur « Selon les relevés des compteurs » ;
6. Le champ accumulé est calculé comme le produit de l’énergie consommée et de la valeur tarifaire.

Algorithme

Kt. 90.01 avec analyses SubcontoKt1 - Nomenclature.NomenclatureGroup, SubcontoKt2 - Nomenclature.Taux de TVA.

S'il existe un solde créditeur sur le compte 62.02, alors l'avance est compensée avec la comptabilisation

Dt. 62.02 avec analyses SubcontoDt1 - Contrepartie, SubcontoDt2 - Accord de contrepartie

Le montant de la transaction est la valeur minimale du solde créditeur du compte 62.02 et la valeur de la variable « accumulé »)

Dt. 90.03 avec analyses SubcontoDt1 - Nomenclature.NomenclatureGroup, SubcontoDt2 - Nomenclature.Taux de TVA

Kt. 62.01 avec analyses SubcontoKt1 - Contrepartie, SubcontoKt2 - Accord de contrepartie

Montant de la transaction = « Accumulés »*Taux de TVA/(100+Taux de TVA), où le taux de TVA est « Nomenclature.Taux de TVA »

Calcul des pénalités

Objectif : Conçu pour refléter l'accumulation d'amendes pour les abonnés

Remplir le document

Le document peut être rempli de deux manières : par saisie manuelle et en appelant le traitement « calcul des amendes »

Partie tabulaire : Relevés de compteurs

Accessoires		But
Contrepartie	Entrepreneurs d’annuaire
Accord de contrepartie	Annuaire Contrats des contreparties
Possibilité d'accumulation d'amendes	Options d'annuaire pour l'accumulation de pénalités
Accumulé		Montant facturé à l'abonné

Publier un document

Le document est réalisé :

D'après le plan comptable autonome :

D'après le plan comptable fiscal :

Formulaires imprimables

Registre des charges

Reçu de paiement avec code barre

Le code-barres est généré à l'aide de la police « Infograftbarcode »

Algorithme de formation Ligne « 0000 »+Code accord abonné+Accumulé

Le layout du ticket de caisse est joint dans le fichier KV_1.mxl

Algorithme

Pour chaque ligne de la section tabulaire « Relevés des compteurs », les inscriptions suivantes doivent être effectuées :

Dt. 62.01 avec analyses SubcontoDt1 - Contrepartie, SubcontoDt2 - Accord de contrepartie

Kt. 91.01 avec analyses SubcontoKt1 - Autres revenus.

Montant de la transaction - la valeur de l'attribut « Accumulé » ;

Traitements

Réception des données du système ASKUE

			Précision	But
				Le code du compteur dans le système Ventes coïncide avec le meter_ID dans le système ASKUE
				Relevés quotidiens des compteurs
				Relevés de compteurs au tarif de nuit

Détails du traitement

Algorithme de traitement :

1. Récupérer le code du compteur à partir d'une ligne de fichier de transfert de données
2. Rechercher l'élément correspondant dans le répertoire « compteurs » par code ; si l'élément n'est pas trouvé, afficher le message « Le compteur avec le code n'est pas trouvé... »
3. Si l'élément est trouvé, ajoutez une ligne au tableau des valeurs, où : "counter" - l'élément trouvé, "ReadingsDay" - "Day", "ReadingsNight" - "Night"
4. Si le traitement est appelé à partir du document « Énergie consommée » et le nombre de lignes

dans le tableau des valeurs est supérieur à 0, puis écrivez le contenu du tableau des valeurs dans la partie tabulaire du document et publiez le document.

1. S'il y a des lignes dans la table de valeurs et que le traitement n'est pas appelé depuis le document « Énergie consommée », alors créez un document « Énergie consommée » avec une date égale à la date du jour puis validez le document.

Réception des données du système de paiement

Le format du fichier de transfert de données est DBF ;

Structure du fichier de transfert de données :

Détails du traitement

Algorithme de traitement :

1. Créez une table de valeurs avec la structure :

1. Sélectionnez les lignes du fichier de transfert de données
2. Commencez à parcourir les lignes du fichier de transfert de données
3. Lire la ligne du fichier de transfert de données
4. Obtenez le code du contrat à partir de la ligne du fichier de transfert de données
5. Rechercher l'élément correspondant par code dans le répertoire « Accords de contrepartie » ; si l'élément n'est pas trouvé, afficher le message « Un accord avec le code n'a pas été trouvé... »
6. Si l'élément est trouvé, ajoutez une ligne au tableau des valeurs, où : « ​​Accord » - l'élément trouvé, « Date » - « Data_plat », « Numéro de paiement » - « Nomer_plat », « Montant » - « Summa_plat »
7. Après avoir reçu la dernière ligne du fichier de transfert de données, terminez le cycle
8. Pour chaque ligne du tableau des valeurs, créez un document « Ordre de paiement pour réception des fonds ». Lors de la création d'un document, vérifiez s'il existe un document dans le système avec la même date et le même numéro que le document entrant. Si le document est présent dans le système, alors le document n'est pas créé.
9. Règles pour remplir les détails du document :

Accessoires	Valeur de remplissage
Type d'opération
	TableLineValue.Date
Numéro du document entrant	Ligne de tableValeur.Numéro de paiement
Date du document entrant	TableLineValue.Date
Accord de contrepartie	TableLineValue.Contract

De nombreuses personnes sont confrontées au fait qu'il est assez difficile d'expliquer brièvement et clairement ce que nous voulons dans la vie de tous les jours. Et lorsque vous devez confier à un spécialiste la tâche d'écrire un programme pour une organisation ou un entrepreneur individuel, en tenant compte des caractéristiques et de vos propres souhaits en matière de fonctionnalité, vous pouvez vous retrouver complètement bloqué.

Qui doit rédiger les spécifications techniques ?

Bien entendu, les spécifications techniques doivent être fournies par le client, puisqu’il connaît certainement ses besoins et ses capacités. Mais, comme le montre la pratique, la grande majorité des clients ne sont pas compétents en 1C. C'est pourquoi l'entrepreneur lui-même est souvent obligé d'examiner les besoins du client, de comprendre de quel produit final il a besoin et, par conséquent, de mettre tout cela par écrit pour le programmeur.

Pourquoi la spécification technique est-elle nécessaire ?

Dans une situation idéale, avec l'une ou l'autre modification d'un produit logiciel 1C, une spécification technique est requise. Tout d'abord, les tâches, les délais et le mode d'exécution doivent être précisés.

Il s'agit d'un document important, car si des questions controversées surgissent, l'élaboration compétente de spécifications techniques deviendra le point de départ des négociations.

Rédiger ou non un cahier des charges technique est une décision que chacun décide lui-même, mais ce ne sera certainement pas superflu : cela simplifiera la communication avec le client et donnera au travail un caractère commercial et concret.



Esquissons une liste des points les plus importants qui devraient figurer dans les spécifications techniques :

1. But/Objectif. Formulez ce qui devrait être mis en œuvre à la fin.

2. Description. Décrivez brièvement le contenu des améliorations prévues.

3. Modalités de mise en œuvre. Décrivez en détail les méthodes par lesquelles l'objectif doit être atteint. Toutes les caractéristiques de la tâche doivent être écrites dans le langage du programmeur : registres, répertoires (les créer ou les éditer) ; conception d'interfaces, etc. Pour ceux qui ne sont pas familiers et qui n'ont entendu parler que d'un langage de programmation spécifique, nous vous conseillons de ne pas faire d'efforts inutiles pour « parler » dans un langage technique. Parce que Idéalement, une description est une déclaration sèche qui élimine toute ambiguïté et la possibilité de questions inutiles. De plus, ce paragraphe peut inclure un exemple de la manière dont une programmation similaire a déjà été réalisée quelque part.

4. Évaluation des performances. Ce point est très important : il doit décrire les coûts de main-d'œuvre.

Deux autres points importants : il existe des normes approuvées pour la rédaction de spécifications techniques - GOST. De nos jours, ils sont rarement utilisés, mais certains clients peuvent demander à les utiliser à l'ancienne.

Et deuxièmement, lorsque le travail est remis, quelque chose comme ceci peut survenir - "mais nous vous avons en quelque sorte demandé de faire telle ou telle chose et ensuite...". Il est possible que vous deviez tout faire dès le début.

C’est pourquoi nous répétons qu’une spécification technique bien rédigée sera utile tant au client qu’à l’entrepreneur.

Exemple de spécifications techniques pour un programmeur

Spécifications techniques 1C pour la finalisation du traitement externe


Cible
Il est nécessaire de configurer le téléchargement des données de 1C vers le lieu de travail automatisé de la banque.


Description

Dans le cadre de la transition de l'organisation vers la configuration 1C « Salaires et personnel d'une institution gouvernementale », il est nécessaire de développer d'autres solutions de traitement qui offriraient des fonctionnalités similaires sur la nouvelle configuration.

Le téléchargement des données doit être basé sur les documents « Demande d'ouverture de compte personnel des employés » et « Déclaration de paiement des salaires à la banque ».


Donnée initiale

Traitement existant pour la configuration 1C « Salaire d'une institution budgétaire », qui télécharge les données du document « Demande d'ouverture de comptes personnels des employés » et d'autres répertoires et s'enregistre dans le fichier DBF pour l'échange de données avec le lieu de travail automatisé de la banque de la norme établie .

Le traitement télécharge les données dans les champs TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN les informations correspondantes de la configuration 1C, préalablement saisies dans le document spécifié et d'autres tableaux comptables. Le numéro personnel, le nom complet de l'employé, son passeport et ses coordonnées, sa date de naissance et sa citoyenneté sont téléchargés.


Méthode de mise en œuvre

Il s'agira de rapports externes et de traitements utilisant le mécanisme d'extension, si les paramètres de compatibilité de base actuels et les capacités de la plateforme le permettent. Lors de la modification de la configuration de la base de données, vous devez créer : des répertoires, des documents, des registres.


Évaluation des performances

P. 5 jours ouvrables de travail de programmeur sont requis.

La précision avec laquelle les spécifications techniques pour la modification de 1C sont rédigées détermine directement si les tâches assignées aux développeurs seront résolues. Cependant, il existe certaines difficultés lorsqu'on travaille avec un tel document. Au sens large, les TDR précisent les normes de création et de modernisation d'un système automatisé (AS), ainsi que la procédure de travail. Cela comprend également un ensemble de normes pour le lancement d'un projet. Cette compréhension du rôle des spécifications techniques est dictée par les exigences de GOST 19.201-78 et 34.602-89, selon lesquelles l'élaboration de spécifications techniques pour 1C est en cours. Il existe une autre interprétation du sens de ce document, plus proche de la pratique.

Selon une autre définition, les termes de référence pour la révision de 1C sont un document réglementant l'objectif et les paramètres du futur système, ainsi que le processus d'élaboration de la documentation et de sa liste. Cette interprétation permet de prendre en compte les intérêts des programmeurs et du client.

Quelle doit être la spécification technique ?

Toute mission technique pour le développement d'un programme 1C est créée par l'entrepreneur. Mais ce n’est pas un programmeur qui le fait, mais un analyste. C'est un point important, puisque le document doit être rédigé dans un langage compréhensible pour le client, sans termes techniques très spécialisés. Lorsque toutes les nuances du projet sont prises en compte et que les informations sont correctement formulées, les spécifications techniques sont convenues avec tous les clients. Si cela est accepté, les programmeurs sont impliqués dans le travail. Dans ce cas, le document doit clairement exposer le résultat souhaité. Cela aide les développeurs à définir le bon objectif et à le vérifier à différentes étapes. De plus, lors de l'élaboration des spécifications techniques pour la modification de 1C, une grande attention doit être accordée au libellé. Il convient de veiller à ce qu'ils soient suffisamment spécifiques et n'impliquent pas d'autres interprétations. C'est la première chose à retenir lorsque l'on travaille avec des spécifications techniques. Vous devez également aborder la conception de manière responsable. Ceci s'applique également à la page de titre du document.

Les principales erreurs dans les spécifications techniques pour le développement de 1C

La structure des spécifications techniques est réglementée par GOST 34.602-89. Ce document contient des exigences claires concernant le nombre et la séquence des blocs d'informations dans les spécifications techniques. Dans le même temps, il n’existe pas de normes strictes concernant les méthodes de présentation. Cette situation recèle un grand potentiel pour résoudre des problèmes complexes et peut en même temps conduire à de nombreuses erreurs lors de la rédaction d'un document. Les inexactitudes les plus courantes sont :

1. Répétition de certaines sections dans différentes interprétations.
2. Les informations sont données de manière aléatoire. Idéalement, il devrait concerner une structure spécifique, telle que des processus métier ou des modules système.
3. Les informations contenues dans les différentes sections sont présentées avec différents degrés de détail.

Tout cela empêche le client de comprendre les informations contenues dans les spécifications techniques. Cela complique le processus de collaboration, le rendant plus exigeant en main-d'œuvre.

Une fois que le client a consulté l'exemple de spécification technique pour la modification de 1C, celui-ci peut changer et pas toujours pour le mieux. Ceci, à son tour, empêche généralement les programmeurs de percevoir correctement les informations. Cela est particulièrement vrai pour les spécialistes peu expérimentés. A ce stade, les erreurs suivantes se produisent souvent :

1. Les exigences des différentes sections se contredisent.
2. La formulation s'avère inexacte.
3. À certains endroits, les informations sont trop détaillées.

Il est facile de se débarrasser de toutes les erreurs répertoriées. Vous devez avant tout vous concentrer sur le résultat et non sur une formulation soigneusement prescrite. Il convient de rappeler que la spécification technique décrit la fonctionnalité du projet, ses principaux paramètres et son objectif.

Comment éviter les erreurs lors de l’élaboration des spécifications techniques ?

La règle de base qui s'applique à toutes les recommandations ultérieures est que la formulation doit être précise. Pour ce faire, vous devez utiliser des références aux GOST et à d'autres documents réglementaires. Cela permet à l'entrepreneur et au client de percevoir les informations de la même manière.

Un exemple de spécification technique pour la modification de 1C suppose l'utilisation de la langue du secteur d'activité pour lequel le projet est réalisé. Cela est nécessaire avant tout pour le client. Cependant, vous ne devez utiliser aucune comparaison dans le texte, car elles peuvent être interprétées de différentes manières.

Règles de base lors de l'élaboration de spécifications techniques pour l'élaboration d'un rapport et d'autres éléments 1C :

1. La spécification technique est établie conjointement par l'entrepreneur et le client.
2. Seules des exigences objectives devraient être imposées au travail des programmeurs. Pour un développement de projet réussi, la vision subjective du client doit être minimisée.
3. Il est nécessaire de décrire en détail le résultat dont le client a besoin. Dans ce cas, dans l'exemple d'une spécification technique pour le développement d'une configuration 1C, il est nécessaire de préciser tous les paramètres selon lesquels l'élément doit fonctionner. Sinon, le résultat peut différer considérablement de celui souhaité.
4. Les risques de l'entrepreneur et du client doivent être à peu près égaux et minimisés.
5. Vous ne pouvez pas utiliser des termes utilisés dans la communication d'entreprise et qui ne sont pas utilisés dans un secteur spécifique.

Pour créer une spécification technique pour l'élaboration d'un rapport en 1C ou autre élément, l'analyste doit connaître toutes les caractéristiques du domaine d'activité du client. Les exigences ne doivent fournir que des informations utiles qui seront utiles à l'entrepreneur. Étant donné que Attention particulière ici, l'accent est mis sur les tâches finales que le logiciel doit résoudre ; il n'existe pas un seul exemple de spécification technique.

Le danger d’une mauvaise rédaction des spécifications techniques

Les erreurs répertoriées ci-dessus peuvent entraîner une augmentation du temps consacré à la création du système. Cela entraîne des coûts inutiles et du mécontentement. Les termes de référence pour le développement d'une base de données ou d'une autre configuration 1C doivent être élaborés par des spécialistes expérimentés. Le bénéfice pour tous les participants dépend de la facilité avec laquelle ce document est compris. Le client reçoit un système automatisé efficace pour résoudre les problèmes commerciaux. Dans le même temps, l'entrepreneur a un autre client satisfait. Les propriétaires d'entreprise doivent être aussi prudents que possible lors du choix des entreprises partenaires 1C, car l'efficacité de l'organisation dépend en grande partie de la qualité de l'élaboration des spécifications techniques à réviser.