Règles de transfert de données 1c. Un exemple de règle de conversion d'objets. Options d'achat de migration de données

La migration de données entre différentes configurations n'est pas une tâche triviale. Comme toujours, il existe plusieurs façons de résoudre, mais toutes ne sont pas optimales. Essayons de comprendre les nuances du transfert de données et de choisir une stratégie universelle pour résoudre de tels problèmes.

Le problème de la migration des données (on parle surtout des produits 1C) d'une solution à une autre ne se posait pas hier. La société 1C comprend parfaitement les difficultés rencontrées par les développeurs lors de la création de migrations, elle essaie donc par tous les moyens d'aider avec des outils.

Au cours du développement de la plate-forme, la société a introduit un certain nombre d'outils universels, ainsi que des technologies qui simplifient le transfert de données. Ils sont intégrés à toutes les solutions standards et le problème des migrations entre configurations identiques a été résolu dans son ensemble. La victoire est une nouvelle fois confirmée par l'intégration étroite de solutions standards.

Avec des migrations entre des solutions non standard, la situation est un peu plus compliquée. Un large éventail de technologies permet aux développeurs de choisir indépendamment la meilleure façon de résoudre le problème de leur point de vue.

Considérons certains d'entre eux :

  • échanger via des fichiers texte ;
  • utiliser des plans d'échange;
  • etc.

Chacun d'eux a ses propres avantages et inconvénients. Pour résumer, le principal inconvénient sera la verbosité. L'auto-implémentation des algorithmes de migration est lourde de coûts de temps importants, ainsi qu'un long processus de débogage. Je ne veux même pas parler d'un soutien supplémentaire à de telles décisions.

La complexité et le coût élevé du support ont poussé 1C à créer une solution universelle. Une technologie qui permet de simplifier au maximum le développement et la maintenance des migrations. En conséquence, l'idée a été réalisée sous la forme d'une configuration distincte - "Conversion de données".

La conversion de données est une solution typique, l'auto-configuration. Tout utilisateur disposant de l'abonnement ITS:Pro peut télécharger ce package entièrement gratuitement depuis le site d'assistance aux utilisateurs ou depuis le disque ITS. L'installation est effectuée de manière standard - comme toutes les autres solutions typiques de 1C.

Maintenant, un peu sur les avantages de la solution. Commençons par la chose la plus importante - la polyvalence. La solution n'est pas adaptée à des configurations/versions de plate-forme spécifiques. Cela fonctionne aussi bien avec les configurations typiques que celles auto-écrites. Les développeurs disposent d'une technologie universelle et d'une approche standardisée pour créer de nouvelles migrations. La polyvalence de la solution permet de préparer des migrations même pour des plateformes autres que 1C : Enterprise.

Le deuxième gros plus, ce sont les visuels. Les migrations simples sont créées sans codage. Oui, oui, sans une seule ligne de code ! Juste pour cela, cela vaut la peine de passer du temps une fois à apprendre la technologie, puis à utiliser des compétences inestimables à plusieurs reprises.

Le troisième avantage que je voudrais souligner est l'absence de restrictions sur la distribution des données. Le développeur choisit lui-même la méthode de livraison des données à la configuration du récepteur. Deux options sont disponibles prêtes à l'emploi : téléchargement vers un fichier xml et connexion directe à l'infobase (COM / OLE).

Nous étudions l'architecture

Nous savons déjà que la conversion de données peut faire des merveilles, mais les avantages techniques ne sont pas encore tout à fait clairs. La première chose à apprendre est que toute migration de données (conversion) est basée sur les règles d'échange. Règles d'échange - un fichier xml standard avec une description de la structure dans laquelle les données d'IB seront téléchargées. Le traitement de service, qui décharge/charge les données, analyse les règles d'échange et, en fonction de celles-ci, effectue le déchargement. Le processus est inversé lors du démarrage.

La configuration "KD" est une sorte de constructeur visuel, à l'aide duquel le développeur crée des règles d'échange. Il ne sait pas comment décharger les données. Le traitement de service externe supplémentaire inclus dans le kit de distribution de CD est responsable de cela. Il y en a plusieurs (XX dans le nom du fichier est le numéro de version de la plateforme) :

  • MDXXExp.epf- le traitement permet de décharger la description de la structure de l'infobase dans un fichier xml. La description de la structure est chargée sur le CD pour une analyse plus approfondie et la création de règles d'échange.
  • V8ExchanXX.epf- décharge/charge les données de l'infobase conformément aux règles d'échange. Dans la plupart des configurations typiques, le traitement est présent dès la sortie de la boîte (voir l'élément de menu « Service »). Le traitement est universel et n'est lié à aucune configuration/règle spécifique.

Bon, maintenant, sur la base de ce qui précède, définissons les étapes de développement d'une nouvelle conversion :

  1. Définition de la tâche. Il est nécessaire de bien comprendre quelles données doivent être transférées (à partir de quels objets de configuration) et, surtout, où les transférer.
  2. Préparation d'une description des structures de configuration (Source / Récepteur) pour le chargement ultérieur dans le CD. La tâche est résolue par le traitement de service MDXXExp.epf.
  3. Chargement des descriptions préparées des structures dans IB.
  4. Création de règles d'échange à l'aide d'outils visuels sur CD.
  5. Effectuer un téléchargement / téléchargement conformément aux règles de conversion de données créées à l'aide du traitement V8ExchanXX.epf.
  6. Débogage des règles d'échange (si nécessaire).

Conversion la plus simple

Pour la démonstration, nous avons besoin de deux configurations déployées. J'ai décidé de m'en tenir à l'option « Gestion du commerce » de la 10e édition et à une petite solution auto-écrite. Le défi sera de transférer des données de configuration typique"UTAH". Par souci de concision, appelons une solution auto-écrite « Récepteur » et la gestion des échanges « Source ». Commençons par résoudre le problème en transférant les éléments du livre de référence "Nomenclature".

Tout d'abord, examinons le schéma de conversion des données et relisons la liste des actions à effectuer. Ensuite, nous lançons la configuration "Source" et ouvrons le traitement du service MD82Exp.epf dedans.

L'interface de traitement ne brille pas avec une abondance de paramètres. L'utilisateur n'a qu'à spécifier les types d'objets de métadonnées qui ne seront pas inclus dans la description de la structure. Dans la plupart des cas, ces paramètres n'ont pas besoin d'être modifiés. il n'y a pas de sens particulier à décharger des mouvements dans des registres d'accumulation (à titre d'exemple).

Le mouvement est plus correct à former lors de la tenue des documents dans le récepteur. Tous les mouvements seront effectués par le document lui-même après le transfert. Le deuxième argument en faveur des paramètres par défaut est la réduction de la taille du fichier avec le téléchargement.

Certains documents (en particulier dans les configurations typiques) génèrent des mouvements sur plusieurs registres. Le vidage de cette ferme entière rendrait le fichier XML résultant trop volumineux. Cela peut compliquer le transport et le chargement ultérieurs dans la base du récepteur. Plus le fichier de données est volumineux, plus vous en avez besoin mémoire vive pour le traiter. Au cours de ma pratique, il m'est arrivé de faire face à des indécences gros fichiers déchargement. De tels fichiers refusaient complètement d'être analysés par des moyens standard.

Nous laissons donc tous les paramètres par défaut et exportons la description de la configuration dans un fichier. Nous répétons une procédure similaire pour la deuxième base.

Ouvrez le CD et sélectionnez dans le menu principal "Répertoires" -> "Configurations"... La référence contient des descriptions des structures de toutes les configurations, qui aideront à être utilisées pour créer des conversions. Nous chargeons une fois la description de la configuration, puis nous pouvons l'utiliser à plusieurs reprises pour créer diverses conversions.

Dans la fenêtre de référence, appuyez sur le bouton " Ajouter« Et dans la fenêtre qui apparaît, sélectionnez le fichier avec la description de la configuration. Nous cochons la case « Télécharger vers nouvelle configuration« Et cliquez sur le bouton« Télécharger ». On fait de même avec la description de la structure de la deuxième configuration.

Maintenant, tout est prêt pour créer des règles d'échange. Dans le menu principal du CD, sélectionnez "Références" -> "Conversions". Nous ajoutons un nouvel élément. Dans la fenêtre de création d'une nouvelle conversion, vous devez spécifier : la configuration source (sélectionnez UT) et la configuration du récepteur (sélectionnez « Receiver »). Ensuite, ouvrez l'onglet "Avancé" et remplissez les champs suivants :

  • nom du fichier des règles d'échange - les règles d'échange créées seront enregistrées sous ce nom. Le nom du fichier peut être modifié à tout moment, mais il est plus avantageux de le définir maintenant. Cela vous fera gagner du temps à l'avenir. J'ai nommé les règles de la démo : "rules-ut-to-priemnik.xml".
  • name - le nom de la conversion. Le nom peut être absolument n'importe quoi, je me suis limité à « Demo. UT dans le récepteur ».

C'est tout, cliquez sur "Ok". Immédiatement, une fenêtre apparaît devant nous avec une question pour créer toutes les règles automatiquement. Accepter une offre aussi alléchante donnera à l'assistant une commande pour analyser automatiquement la description des configurations sélectionnées et générer indépendamment des règles d'échange.

Mettons les points sur le « et » tout de suite. Le maître ne pourra rien générer de grave. Cependant, cette fonctionnalité ne doit pas être négligée. S'il est nécessaire d'établir un échange entre des configurations identiques, alors les services de l'assistant seront très utiles. Pour notre exemple, le mode manuel est préférable.

Regardons de plus près la fenêtre "Paramètres des règles d'échange". L'interface peut sembler un peu déroutante - un grand nombre de onglets bourrés de contrôles. En fait, tout n'est pas si difficile, on commence à s'habituer à cette folie après quelques heures de travail avec l'application.

A ce stade, nous nous intéressons à deux onglets : "Règles de conversion d'objets" et "Règles d'upload de données". Dans un premier temps, nous devons mettre en place les règles de correspondance, c'est-à-dire comparer des objets de deux configurations. Sur la seconde, pour déterminer les éventuels objets qui seront à la disposition de l'utilisateur pour le déchargement.

Dans la seconde moitié de l'onglet "Règles de conversion d'objets", il y a un panneau supplémentaire avec deux onglets : "Conversion des propriétés" et " Conversion de valeurs”. Le premier sélectionnera les propriétés (attributs) de l'objet sélectionné, et le second est nécessaire pour travailler avec des valeurs prédéfinies (par exemple, éléments prédéfinis ouvrages de référence ou éléments d'énumération).

Super, créons maintenant des règles de conversion pour les ouvrages de référence. Vous pouvez effectuer cette action de deux manières : utilisez l'assistant de synchronisation d'objets (le bouton "") ou ajoutez des correspondances pour chaque objet manuellement.

Pour économiser de l'espace, utilisons la première option. Dans la fenêtre de l'assistant, décochez les cases du " Documentation"(Nous ne sommes intéressés que par les ouvrages de référence) et ouvrez le groupe" Annuaires”. Nous parcourons soigneusement la liste et examinons les noms d'ouvrages de référence pouvant être comparés.

Dans mon cas, il existe trois de ces répertoires : Nomenclature, Organisations et Entrepôts. Il existe également un ouvrage de référence Clients, qui remplit la même charge sémantique que « Entrepreneurs"Depuis la configuration" Utah”. Certes, le maître ne pouvait pas les égaler en raison de leurs excellents noms.

Nous pouvons corriger ce défaut nous-mêmes. On trouve dans la fenêtre " Correspondance d'objet"Livre de référence" Clients", Et dans la colonne " Source " sélectionnez le répertoire " Entrepreneurs ". Cochez ensuite la case dans la colonne "Type" et appuyez sur le bouton "Ok".

L'assistant de synchronisation d'objets proposera de créer automatiquement des règles pour convertir les propriétés de tous les objets sélectionnés. Les propriétés seront cartographiées par nom et cela suffira amplement pour notre démonstration, nous en convenons. La prochaine question sera la proposition de créer des règles de déchargement. Acceptons-le aussi.

La base des règles d'échange est prête. Nous avons choisi les objets pour la synchronisation et les règles de conversion des propriétés et les règles de déchargement ont été créées automatiquement. Enregistrons les règles d'échange dans un fichier, puis ouvrons la "Source" de l'IB (dans mon cas, c'est UT) et commençons le traitement du service dans celui-ci V8Exchan82.epf.

Tout d'abord, dans la fenêtre de traitement, sélectionnez les règles d'échange que nous avons créées. Nous répondons positivement à la question du chargement des règles. Le traitement analysera les règles d'échange et créera une arborescence d'objets du même nom disponibles pour le téléchargement. Pour cet arbre, nous pouvons définir toutes sortes de sélections ou de nœuds d'échange, en fonction des changements dont nous avons besoin pour sélectionner des données. Nous voulons télécharger absolument toutes les données, il n'est donc pas nécessaire d'installer des filtres.

Une fois le processus de téléchargement des données dans un fichier terminé, accédez à l'IB " Receveur”. Nous y ouvrons également le traitement. V8Exchan82.epf, seulement cette fois, allez dans l'onglet « Téléchargement de données ». Sélectionnez le fichier de données et appuyez sur le bouton "Charger". Ça y est, les données ont été transférées avec succès.

Tâches du monde réel

La première démo pourrait être trompeuse. Tout semble assez simple et logique. En fait, ce n'est pas vrai. Dans le travail réel, surgissent des problèmes difficiles ou totalement impossibles à résoudre uniquement par des moyens visuels (sans programmation).

Afin de ne pas être déçu par la technologie, j'ai préparé plusieurs problèmes réels. Vous devez les rencontrer lorsque vous travaillez. Ils n'ont pas l'air si triviaux et vous font regarder la conversion de données sous un nouvel angle. Examinez attentivement les exemples présentés et n'hésitez pas à les utiliser comme extraits pour résoudre de vrais problèmes.

Problème numéro 1. Nous remplissons les détails manquants

Supposons que nous ayons besoin de transférer depuis UT le répertoire " Entrepreneurs”. Le récepteur a un répertoire "Clients" similaire pour cela. Il est tout à fait approprié pour stocker des données, mais il a les accessoires " Organisation», ce qui permet de séparer les contractants selon leur affiliation à l'organisation. Par défaut, tous les contractants doivent se référer à l'organisation actuelle (elle peut être obtenue à partir de la constante du même nom).

Le problème a plusieurs solutions. Nous considérerons l'option de remplir le « requis » Organisation"Droit dans la base de données" Receveur", C'est à dire. au moment du chargement des données. L'organisation actuelle est stockée dans une constante, il n'y a donc aucun obstacle à l'obtention de cette valeur. Ouvrons la règle de conversion d'objet (ci-après PCO) " Clients”(Double-cliquez sur l'objet) et dans l'assistant de règles, allez dans la section“ Gestionnaires d'événements ”. Dans la liste des gestionnaires, nous trouvons " Après le chargement”.

Décrivons le code pour obtenir l'organisation actuelle avec l'affectation ultérieure au requis. Au moment de l'activation du gestionnaire "Après chargement", l'objet sera entièrement formé, mais pas encore écrit dans la base de données. Personne ne nous interdit de le modifier à notre discrétion :

Si PAS Object.EtoGroup Then Object.Organization = Constants.CurrentOrganization.Get (); Fin si;

Avant de remplir les champs " Organisation"Il est impératif de vérifier la valeur de la variable" Ce groupe". Pour la référence " Clients»L'indicateur de hiérarchie est défini, une vérification d'un groupe est donc nécessaire. De la même manière, tous les détails sont remplis. Assurez-vous de lire l'aide pour les autres paramètres du gestionnaire " Après le téléchargement". Par exemple, parmi eux il y a un paramètre " Refus". Si la valeur "True" lui est affectée, l'objet ne sera pas écrit dans la base de données. Ainsi, il devient possible de restreindre les objets à enregistrer au moment du chargement.

Problème numéro 2. Détails dans le registre d'information

Dans la référence " Entrepreneurs"Configuration UT, il y a des détails" Client" et " Le fournisseur”. Les deux attributs sont du type " booléen» Et servent à déterminer le type de contrepartie. Dans IB " Receveur", Au livre de référence" Clients"Il n'y a pas de détails similaires, mais il existe un registre d'informations" Types de clients”. Il remplit une fonction similaire et peut stocker plusieurs fonctionnalités pour un client. Notre tâche consiste à transférer les valeurs d'attribut dans des enregistrements séparés du registre d'informations.

Malheureusement, les moyens visuels seuls ne peuvent pas y faire face. Commençons petit, créez un nouveau PKO pour le registre d'information " Types de clients”. Ne spécifiez rien comme source. À partir de création automatique rejeter les règles de déchargement.

L'étape suivante consiste à former les règles de déchargement. Allez dans l'onglet correspondant et appuyez sur le bouton " Ajouter”. Dans la fenêtre d'ajout de règles de déchargement, renseignez :

  • Méthode d'échantillonnage. Passez à « Algorithme gratuit » ;
  • Règle de conversion. Nous sélectionnons le registre d'informations « Types de clients » ;
  • Code (nom) de la règle. Nous l'écrivons comme « Déchargement des vues client » ;

Vous devez maintenant écrire le code pour sélectionner les données à décharger. Le paramètre " Récupération de données”. Nous pouvons mettre une collection avec un ensemble de données préparé. Paramètre " Récupération de données"Peut prendre différentes valeurs - résultat de la requête, sélection, collections de valeurs, etc. Nous l'initialisons sous forme de table de valeurs avec deux colonnes : client et type de client.

Vous trouverez ci-dessous le code du gestionnaire d'événements " Avant le traitement”. Il initialise le paramètre " Récupération de données"Suivi du remplissage avec les données du livre de référence" Entrepreneurs”. Ici, vous devez faire attention au remplissage de la colonne " Type de client”. Dans "UT" nous avons des signes de type "booléen", et dans le destinataire - énumération.

A ce stade, nous ne pouvons pas les amener à le bon genre(il n'est pas en UT), donc pour l'instant nous le laisserons sous forme de chaînes. Vous n'avez pas besoin de le faire, mais je veux juste vous montrer comment convertir un type manquant dans la source.

DataFetch = NewValuesTable (); FetchData.Columns.Add ("Client"); FetchData.Columns.Add ("ClientType"); FetchDataFromDirectory = Directories.Contractors.Select (); Pendant que FetchingDataFromDirectory.Next () boucle IfFetchingDataFromDirectory.ThisGroup Puis continuez ; Fin si; Si DataFetchFromDirectory.Buyer Then NewRow = DataFetch.Add (); NewString.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Acheteur" ; Fin si; Si DataFetchFromDirectory.Provider Then NewRow = DataFetch.Add (); NewString.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Fournisseur" ; Fin si; Fin de cycle ;

Enregistrons la règle de déchargement des données et revenons au " Règles de conversion d'objet”. Ajouter pour le registre d'information " Types de clients« Règles de conversion de propriété : client et type de client. Laissez la source vide et écrivez dans le gestionnaire d'événements « Avant le déchargement » :

// Pour la propriété « Client » Value = Source.Client; // Pour la propriété "ClientType" If Source.Client = "Customer" Then Expression = "Enumerations.ClientTypes.Customer" SinonIf Source.Client = "Supplier" Then Expression = "Enumerations.ClientTypes.Supplier"; Fin si;

Dans la liste, les détails sont remplis en fonction de la sélection de données effectuée. Nous transférons le client simplement sous forme de lien, et écrivons le type du client dans le paramètre " Expression". Les données de ce paramètre seront interprétées dans le récepteur et lors de son exécution, la variable sera remplie avec la valeur correcte de l'énumération.

Ça y est, les règles d'échange sont prêtes.L'exemple envisagé s'est avéré assez universel. Une approche similaire est souvent utilisée lors de la migration de données à partir de configurations créées sur la plate-forme 7.7. Un exemple frappant en est le transfert de conditions périodiques.

Problème numéro 3. Astuces pour les sections tabulaires

Très souvent, vous rencontrez des tâches qui nécessitent de publier les lignes d'une section tabulaire dans plusieurs. Par exemple, dans la configuration initiale, les services et les biens sont organisés dans une section tabulaire et le stockage de ces entités est séparé dans le récepteur. Encore une fois, le problème ne peut pas être résolu par des moyens visuels. Ici, il convient de prendre comme base la solution du deuxième problème.

Nous établissons une règle pour le déchargement des données, spécifions un algorithme arbitraire et dans le gestionnaire "Avant le déchargement", nous écrivons une demande pour obtenir des données de la section tabulaire.

Pour gagner de la place, je ne citerai pas le code (vous pouvez toujours vous référer au code source) de la requête - il n'y a rien d'inhabituel. Nous parcourons la sélection résultante et plaçons les résultats triés dans le paramètre déjà familier " Récupération de données”. Il est également pratique d'utiliser une table de valeurs comme une collection :

DataFetch = NewValuesTable (); // Il y aura une autre section tabulaire DataFetch.Columns.Add ("Produits"); // Il y aura également une section tabulaire DataFetch.Columns.Add (« Services »); FetchData.Columns.Add (« Lien »);

Problème numéro 4. Transfert de données vers une opération

Si une organisation utilise plusieurs systèmes comptables, tôt ou tard, il sera nécessaire de migrer les données avec la formation ultérieure de transactions.

Dans la configuration " PA"Il existe un document universel" Opération« Et est idéal pour générer plus de prospects. Voici juste une non-tâche - le document est fait astucieusement, et il n'est pas si facile d'y transférer les données.

Un exemple d'une telle conversion peut être trouvé dans le code source de l'article. Le volume du code s'est avéré assez important, il ne sert donc à rien de le publier pour l'article. Permettez-moi simplement de dire que le déchargement utilise à nouveau un algorithme arbitraire dans les règles de déchargement des données.

Problème numéro 5. Synchronisation des données pour plusieurs prérequis

Nous avons déjà vu quelques exemples, mais nous n'avons toujours pas parlé de la synchronisation des objets lors de la migration. Imaginons que nous ayons besoin de transférer des entrepreneurs et que certains d'entre eux se trouvent probablement dans la base de données du destinataire. Comment transférer des données et éviter les doublons ? À cet égard, le CD propose plusieurs façons de synchroniser des objets portables.

La première est basée sur un identifiant unique. De nombreux objets ont un identifiant unique qui garantit l'unicité au sein d'une table. Par exemple, dans la référence " Entrepreneurs« Il ne peut pas y avoir deux éléments avec le même identifiant. Le CD fait un calcul pour cela, et pour tous les PQS créés, la recherche par identifiant est activée par défaut en une fois. Lors de la création du PCO, vous avez dû faire attention à l'image de la loupe à côté du nom de l'objet.

La synchronisation par identifiant unique est une méthode fiable, mais elle est loin d'être toujours appropriée. Lors de la combinaison de répertoires " Entrepreneurs”(De plusieurs différents systèmes) cela ne sert pas à grand-chose.

Dans de tels cas, il est plus correct de synchroniser les objets selon plusieurs critères. Il est plus correct de rechercher des contreparties par TIN, KPP, Nom, ou de diviser la recherche en plusieurs étapes.

La conversion des données ne limite pas le développeur dans la définition des critères de recherche. Regardons un exemple abstrait. Supposons que nous ayons besoin de synchroniser les répertoires " Entrepreneurs« À partir de différentes bases d'informations. Préparons le POC et dans les paramètres des règles de conversion d'objet, cochez la case " Continuer la recherche dans les champs de recherche si l'objet cible n'est pas trouvé par l'identifiant”. Par cette action, nous avons immédiatement défini deux critères de recherche - par un identifiant unique et des champs personnalisés.

Nous avons le droit de choisir nous-mêmes les champs. Après avoir noté la DCI, le KPP, le Nom, nous indiquerons immédiatement plusieurs critères de recherche. Idéalement ? Assez, mais encore une fois ce n'est pas suffisant. Et si on voulait changer les critères de recherche ? Par exemple, nous cherchons d'abord le lien INN + KPP, et si nous ne trouvons rien, alors nous commençons à tenter notre chance avec le nom.

Un tel algorithme est tout à fait capable de mettre en œuvre. Dans le gestionnaire d'événements " Champs de recherche« Nous pouvons spécifier jusqu'à 10 critères de recherche et pour chacun d'eux définir son propre ensemble de champs de recherche :

Si SearchVariantNumber = 1 alors SearchPropertyNameString = « INN, KPP » ; Sinon, si SearchVariantNumber = 2 Then SearchPropertyNameString = « Nom » ; Fin si;

Il y a toujours plusieurs solutions

Toute tâche a plusieurs solutions et le transfert de données entre différentes configurations ne fait pas exception. Chaque développeur a le droit de choisir son propre chemin de solution, mais si vous devez constamment développer des migrations de données complexes, alors je vous recommande fortement de faire attention à la configuration "". Qu'il faille d'abord investir des ressources (du temps) dans la formation, mais elles seront plus que payantes sur le premier projet plus ou moins sérieux.

À mon avis, 1C contourne à tort le sujet de l'utilisation de la conversion de données. Pour toute l'existence de la technologie, un seul livre a été publié dessus : « 1C : Enterprise 8. Data Conversion : Exchange between Application Solutions ». Le livre est assez ancien (2008), mais il est tout de même souhaitable de s'y familiariser.

La connaissance des plateformes est encore nécessaire

"Est un outil universel, mais si vous envisagez de l'utiliser pour créer des migrations de données à partir de configurations développées pour la plate-forme 1C: Enterprise 7.7, vous devrez passer du temps à vous familiariser avec le langage intégré. La syntaxe et l'idéologie de la langue sont très différentes, il faut donc passer du temps à étudier. Le reste du principe reste le même.

Probablement, chaque spécialiste 1C était confronté à la nécessité de transférer des données d'une infobase à une autre. Dans le cas où les configurations sont différentes, vous devez écrire des règles de conversion de données. Ces règles sont créées dans la configuration 1C "Conversion des données".

Vous pouvez également transférer des données en utilisant. De nombreuses configurations 1C 8.3 ont des fonctionnalités standard pour configurer la synchronisation des données entre différentes configurations et une intégration transparente avec 1C Document Management.

Mais lorsque des données doivent être transférées entre des configurations complètement identiques, vous pouvez simplifier votre tâche et utiliser le traitement standard de chargement et de téléchargement via XML. Veuillez noter que cette méthode, ainsi que la conversion de données, fait correspondre les objets entre eux par un identifiant unique (GUID), et non par nom.

Vous pouvez télécharger ce traitement sur le disque ITS, ou suivre les liens :

Il est polyvalent et s'adapte à toutes les configurations.

Considérons un exemple de déchargement du répertoire Nomenclature d'une infobase 1C 8.3 Comptabilité 3.0 vers une autre. Une condition préalable sera la sélection par le parent (groupe) « Travail du bois ».

Déchargement des données de 1C vers XML

Accédez à l'infobase à partir de laquelle les données seront téléchargées (source). Assurez-vous de les vérifier en tenant compte de toutes les conditions possibles afin d'éviter des conséquences indésirables.

Ouvrir le traitement de chargement et de téléchargement Données XML(Ctrl + O).

Nous sommes intéressés par l'onglet "Déchargement". Tout d'abord, spécifiez le nom du fichier dans lequel les données seront téléchargées et le chemin d'enregistrement. Dans ce cas, les données sont téléchargées « Dans un fichier sur le serveur ».

Dans l'en-tête de traitement, la période pour laquelle la sélection sera effectuée est paramétrée. De plus, pour les ledgers périodiques, vous pouvez spécifier comment la sélection par période est appliquée. S'il est nécessaire de décharger des mouvements avec des documents, le drapeau correspondant est activé. Dans ce cas, nous surchargeons le répertoire, il n'est donc pas nécessaire de configurer quoi que ce soit dans l'en-tête.

Passons à la sélection des données à télécharger. Dans la section tabulaire du formulaire de traitement, cochez les cases des objets de configuration que vous devez transférer.

La colonne « Décharger si nécessaire » signifie s'il est nécessaire de recharger cet objet s'il est référencé par l'attribut du répertoire que l'on recharge. Par exemple, la position de l'article que vous rechargez a une unité de mesure qui n'est pas dans la base réceptrice. Si la case à cocher dans la colonne "Décharger si nécessaire" est cochée devant l'ouvrage de référence avec les unités de mesure, une nouvelle position sera créée. Sinon, la valeur de l'attribut contiendra l'inscription "<Объект не найден>"Et son identifiant unique.

Dans un cas simple, sans échantillonnage, le paramètre de rechargement de l'élément ressemblera à ceci.

V cet exemple vous devez sélectionner uniquement la nomenclature qui se trouve dans le dossier "Woodworking".

Un traitement similaire pour 8.2 vous permet de définir facilement des sélections pour chaque objet de configuration. Dans la version 8.3, malheureusement, une telle fonctionnalité n'existe pas. Une des solutions à cette situation serait de sélectionner les positions nécessaires dans l'onglet "Objets supplémentaires à décharger".

Vous pouvez ajouter des objets ici soit manuellement (le bouton "Ajouter") soit par demande ("Ajouter par demande ..."). Avec un grand nombre d'entre eux, la deuxième option est préférable.

Dans ce cas, la demande sera la suivante. Renseignez les paramètres, complétez la demande en vérifiant les données, et cliquez sur le bouton "Sélectionner le résultat".

Après avoir spécifié tous les objets et éléments supplémentaires nécessaires au téléchargement, cliquez sur le bouton "Télécharger les données". Ils se retrouveront dans un fichier XML, dont vous avez spécifié le nom et le chemin précédemment. Les résultats de cette opération seront affichés dans des messages.

Dans cet exemple, il n'a été nécessaire de décharger que 3 positions, mais cinq ont été déchargées. En effet, le drapeau a été placé dans la colonne « Décharger si nécessaire » en regard du référentiel « Nomenclature ». Avec les postes nécessaires, leurs parents étaient surchargés.

Chargement d'une référence depuis XML

Après avoir réussi à décharger les données de la configuration source dans un fichier XML, ouvrez la base de données de destination. La structure des objets et leurs détails doivent correspondre. Dans ce cas, le transfert s'effectue entre deux configurations typiques de 1C : Comptabilité 3.0.

Ouvrez le traitement dans la base réceptrice. Ce traitement utilisé à la fois pour le téléchargement et le téléchargement de données. Allez dans l'onglet "Télécharger" et indiquez le chemin vers fichier XML, dans lequel les données ont été précédemment téléchargées. Après cela, cliquez sur le bouton "Télécharger les données".

Le résultat du téléchargement sera affiché dans les messages. Dans notre cas, tout s'est bien passé.

Répertoire "Nomenclature" dans la base - le récepteur n'était pas rempli. Il comporte désormais cinq éléments : trois éléments de nomenclature et deux groupes.

Les données et les documents importants collectés au cours des années de travail acharné ne doivent pas être perdus simplement parce qu'une nouvelle plate-forme ou une configuration 1C est sortie. Afin d'éviter que cela ne se produise, il existe une possibilité de transfert de données.

La migration des données est l'une des parties les plus critiques de la migration d'une configuration à une autre.

Pour que les données soient transférées intactes et sécurisées, vous devez confier ce travail à des professionnels. Notre équipe effectuera tous les travaux avec une haute qualité et dans les délais.

Étapes de transfert

Le transfert de données se compose de 5 étapes. Nous avons essayé de les décrire de la manière la plus détaillée et la plus compréhensible possible.

Pourquoi notre transfert de données est-il meilleur ?

Coût typique de migration de données

Maintien d'un nouveau programme

Après avoir transféré toutes les données, vous devrez peut-être maintenir votre programme. Nous sommes prêts à vous le fournir !

Transition vers 1C 8.2

Détails sur les autres étapes de la transition d'une plateforme à une autre. Mise à niveau des licences, configuration, formation, maintenance. Nos experts sont prêts à vous fournir toute l'aide dont vous avez besoin!

Pourquoi sommes-nous meilleurs ?

Transfert de commande

notre équipe

Pourquoi notre transfert de 1C est-il meilleur ?

  • Transparence
  • Avant de transférer les ouvrages de référence 1C 8.2 et vos autres données, nos spécialistes vous expliqueront en détail toutes les étapes du travail. En nous confiant votre base, vous savez toujours ce qui est fait, dans quel ordre et combien vous payez pour chaque étape du travail.

  • Approche individuelle
  • Avant de procéder directement au transfert de 1C 7.7 vers 1C 8.2, nos spécialistes procéderont à une analyse approfondie de votre base de données. Il y a de fortes chances qu'en nouvelle version 1C a déjà toutes ces améliorations dont vous aviez besoin. Dans tous les cas, nous vous recommanderons ce dont vous pourriez avoir besoin d'autre pour un travail confortable.

  • Qualité
  • Avant l'étape la plus importante du transfert, nos spécialistes effectuent toujours un transfert d'essai des bases 1C afin d'identifier erreurs possibles, la répétition et la perte de données. Mais même après le transfert lui-même, nous vérifierons certainement tout pour une confiance encore plus grande dans sa qualité.

  • Travailler pour des résultats
  • Le travail n'est considéré comme terminé qu'une fois que vous vous êtes assuré que le transfert des répertoires 1C 8 et d'autres données a été effectué correctement et que vous êtes satisfait du résultat. Nous n'abandonnons pas nos clients !

    Étape 1. Analyse générale de la base source

    Quel travail est fait :

  • obtenir une configuration de version type similaire à la base source ;
  • analyse générale des évolutions de la structure des données (comparaison avec une configuration type) ;
  • analyse générale des évolutions des formulaires et des modules de configuration (comparaison avec une configuration type) ;
  • contrôle de la disponibilité des comptes comptables atypiques pour les configurations comptables ;
  • contrôle général de l'exactitude de la comptabilité dans la base source (présence de soldes "rouges", de périodes ouvertes, de séquences non récupérées, etc.) ;
  • mise à jour de la base de données source vers la version requise par les règles de migration standard ;
  • transfert de données d'essai ;
  • préparation d'éventuelles recommandations pour la préparation de la base de données source pour le transfert d'ouvrages de référence 1C 8 et d'autres données.
  • Pourquoi:

  • déterminer la possibilité d'utiliser un transfert type ;
  • évaluation de la complexité des révisions et préparation de la documentation technique pour le transfert (si l'utilisation d'un transfert type n'est pas possible).
  • Après avoir effectué une analyse générale de la base source, il peut être confirmé que les données peuvent être transférées moyens typiques, dans ce cas, le coût supplémentaire du service de transfert est déterminé selon la liste de prix d'un transfert typique, en fonction de la configuration.

    Si le bon transfert typique n'est pas possible, alors une proposition est préparée avec le coût des travaux de finalisation des configurations, des règles d'échange et du transfert atypique.

    Prix ​​: 2 000 roubles

    Étape 2. Préparation de la documentation technique pour le transfert atypique

    Quel travail est fait :

  • une analyse approfondie des modifications disponibles de la configuration standard de la base source est réalisée, une comparaison de ces modifications avec la configuration type de la même version et avec la dernière version de la configuration standard de la base réceptrice ;
  • communication avec les personnes responsables du Client pour déterminer la nécessité des améliorations identifiées, clarifier les modalités d'utilisation des améliorations, recueillir les souhaits d'amélioration des améliorations (si nécessaire) ;
  • une liste des modifications disponibles de la configuration standard de la base source est établie ;
  • une liste de modifications recommandées de la configuration type de la base réceptrice est établie et convenue, en tenant compte de la fonctionnalité standard de la configuration type (il est possible que la modification n'ait pas besoin d'être transférée si la configuration du récepteur a déjà une configuration similaire fonctionnalité standard);
  • un projet de mission technique est élaboré et approuvé pour finaliser la configuration de la base réceptrice, finaliser les règles d'échange, la description
    procédures de transfert atypiques (si nécessaire).
  • Pourquoi:

  • garantie de qualité et de transparence des travaux sur le transfert atypique de bases de données 1C ;
  • estimation exacte des coûts et durée des travaux ;
  • la capacité d'effectuer des travaux sur le transfert avec l'implication d'un programmeur 1C à temps plein, tout en assurant le niveau de qualité requis.
  • Si l'ensemble de documentation technique spécifié n'est pas disponible, les transferts non standard entre les configurations 1C sont effectués uniquement sur une base horaire. Dans ce cas, il est impossible de garantir avec précision à l'avance le coût et la durée des travaux. Cependant, dans ce cas, des économies de temps et d'argent pour la préparation d'un ensemble de documentation sont possibles.

    Prix ​​: A préciser en fonction des résultats d'une analyse générale de la base source.

    Étape 3. Raffinement de la configuration du récepteur

    Quel travail est fait :

  • la configuration standard de la base réceptrice est en cours de finalisation sur la base de la mission technique, ou conformément aux instructions du Client (pour le travail horaire) ;
  • des tests préliminaires des modifications sont effectués ;
  • les améliorations sont documentées sous la forme d'un rapport sur les modifications apportées à la configuration typique (pour la possibilité d'une mise à jour ultérieure par un ingénieur de service) ;
  • une démonstration des améliorations à l'utilisateur est effectuée (livraison-réception des travaux) ;
  • un manuel d'utilisation pour les améliorations est en cours d'élaboration (si nécessaire).
  • Pourquoi:

  • vous obtenez dernière version configurations avec les changements dont vous avez besoin ;
  • Vous recevez la documentation pour les améliorations dont vous avez besoin pour plus
    mises à jour par un ingénieur de service.
  • Étape 4. Affinement des règles de transfert

    Quel travail est fait :

  • les règles standards de transfert depuis 1C sont en cours de finalisation pour prendre en compte les évolutions de la structure des données de la configuration standard de la base source, ainsi que les comptes comptables non standards utilisés dans la base source ;
  • des tests préliminaires du transfert sont effectués en tenant compte des changements.
  • Pourquoi:

    Le transfert correct des données est fourni, qui n'est pas transféré par les règles d'échange standard ;

    La modification des règles de transfert peut également être requise si la comptabilisation dans la base de données source a été effectuée de manière incorrecte du point de vue de la méthodologie de la solution standard, bien que la configuration source puisse ne pas contenir de modifications.

    Prix ​​: formé sur la base d'un ensemble de documentation technique.

    Étape 5. Transfert de données

    Quel travail est fait :

  • reporter Informations de référence(le tout, ou par liens), transfert de soldes à une date donnée ;
  • contrôle de l'exactitude du transfert - comparaison des données de la base de données source et de la base de données de destination ;
  • préparation d'éventuelles recommandations d'ajustement des soldes dans la base réceptrice, en tenant compte des particularités de la comptabilité dans différentes configurations (si nécessaire).
  • Pourquoi:

    Tu te prépares à partir nouvelle base données avec vos soldes actuels.

    Le transfert est effectué en utilisant des règles de transfert développées par 1C, avec l'utilisation de modifications faites spécifiquement pour le Client. La composition des données transférées peut différer pour différentes versions configurations, nos experts vous conseilleront sur
    caractéristiques de transfert.