Scambio attraverso un formato universale. Scambio tramite formato universale Fasi preparatorie per l'impostazione dello scambio in BP

27.08.2015

1C ha rilasciato la prima versione di un nuovo formato di scambio dati aziendali, EnterpriseData, basato su XML. Il formato consente di organizzare in modo efficace lo scambio di dati tra i sistemi di automazione aziendale eterogenei utilizzati in azienda, indipendentemente da chi sia il loro sviluppatore e a quali aree di attività siano destinati.

Il rilascio dello standard è stato il passo successivo per 1C nel percorso volto ad aumentare l'apertura dei suoi prodotti all'integrazione con software di terze parti. L'azienda 1C ha sempre prestato particolare attenzione a questo ambito. I prodotti 1C supportano il formato CommerceML, utilizzato per lo scambio di informazioni commerciali in formato XML. Una menzione speciale merita il formato per lo scambio di documenti finanziari tra il sistema 1C:Enterprise e i moduli dei sistemi bancari remoti (Client-Bank), sviluppato da 1C insieme ai principali sviluppatori di sistemi informativi bancari. Questo formato, supportato oggi da centinaia di banche russe (tra cui Sberbank of Russia, VTB 24, Gazprombank, Rosselkhozbank) è diventato sostanzialmente uno standard del settore. Questa direzione è stata ulteriormente sviluppata nella tecnologia di scambio diretto DirectBank, che rende l'interazione con una banca di 1C:Enterprise ancora più comoda e sicura.

Allo stesso tempo, in precedenza i formati supportati da 1C servivano principalmente a risolvere problemi di scambio di dati tra diverse organizzazioni solo in alcune aree di attività (commercio elettronico, integrazione con i sistemi bancari). Ora il nuovo formato EnterpriseData copre tutte le aree dell'azienda: finanza, produzione, acquisti e vendite, operazioni di magazzino, ecc. La prima versione del formato comprende le descrizioni di 94 tipi di documenti provenienti da diverse aree aziendali. Il formato è estensibile; 1C aggiungerà nuovi documenti e dettaglierà quelli esistenti.

Il formato è consigliato per l'uso quando si integrano applicazioni di terze parti con programmi 1C. Il formato può essere utilizzato anche per scambiare informazioni tra eventuali altri sistemi informativi: non dipende dalle caratteristiche del software o delle strutture di base delle informazioni che partecipano allo scambio e non contiene evidenti restrizioni d'uso.

Attualmente, il formato Enterprise Data è già utilizzato per sincronizzare i dati tra i prodotti software della stessa azienda 1C; è supportato nei prodotti:

• 1C:Gestione aziendale ERP 2.0
• 1C:Contabilità 8, edizione 3.0
• 1C:Contabilità 8 CORP, edizione 3.0
• 1C: Vendita al dettaglio, edizione 2.0
• 1C: Gestione commerciale, edizione 11

Uno dei casi più comuni di integrazione dei prodotti 1C è il tandem “1C: Contabilità” - “1C: Gestione commerciale”; questi due famosi prodotti aziendali scambiano 73 tipi di documenti nel formato EnterpriseData, che consente di mantenere i propri dati aggiornati e sincronizzati tra loro. Gli sviluppatori 1C notano che l'adozione del formato EnterpriseData ha migliorato la qualità e la velocità di sviluppo delle soluzioni applicative del sistema 1C:Enterprise grazie all'unificazione del codice.

Per i prodotti di terze parti che si integrano con i prodotti 1C, l'uso del formato ridurrà sia la quantità di sviluppo che i costi di manodopera per l'implementazione e il supporto dei sistemi. In precedenza, quando ogni prodotto supportava il proprio formato di scambio dati, se c'erano N prodotti nel sistema di scambio dati, l'aggiunta di un nuovo prodotto richiedeva 2*N modifiche (vedere Fig. 1); ogni prodotto esistente necessitava di modifiche per supportare l'importazione dei dati dal nuovo prodotto e il nuovo prodotto doveva supportare l'importazione dei dati dai prodotti esistenti. Dopo l'introduzione di un formato unico, l'aggiunta di un nuovo prodotto richiederà solo l'implementazione dell'importazione e dell'esportazione nel formato EnterpriseData e non causerà modifiche ai prodotti esistenti.

Figura 1 Scambio di dati senza un formato comune

Figura 2 Scambio di dati tramite formato EnterpriseData

Il formato supporta la compatibilità dal basso verso l'alto: tutti i programmi di terze parti che scambiano dati nel formato EnterpriseData con il software 1C continueranno a funzionare quando verranno rilasciate nuove versioni del formato.

• per integrare i propri sviluppi sulla piattaforma 1C:Enterprise (sia su misura che prodotti in serie) con soluzioni 1C standard
• per l'integrazione di altri sistemi (non 1C) con soluzioni sulla piattaforma 1C:Enterprise
• organizzare l'interazione di altri sistemi (non 1C) tra loro.

1C ha presentato la prima versione del nuovo formato per lo scambio di dati aziendali EnterpriseData, che si basa su XML e, secondo i suoi autori, è destinato non solo a unificare l'interazione delle soluzioni applicative e dei loro singoli componenti creati dall'azienda stessa, ma anche a essere utilizzato come meccanismo universale di integrazione delle informazioni per qualsiasi applicazione aziendale su qualsiasi piattaforma software, incluso, ovviamente, 1C:Enterprise.

L'azienda da tempo si dedica alla creazione e all'utilizzo di standard aperti per l'interazione delle informazioni delle sue applicazioni con software di sviluppatori indipendenti, ma fino ad ora ciò ha riguardato solo alcune aree tematiche specializzate. Questo è esattamente ciò che serve il formato CommerceML, creato quasi quindici anni fa, per risolvere il problema dell'e-commerce, così come "Client-Bank" e DirectBank per la comunicazione tra applicazioni 1C e sistemi bancari esterni. EnterpriseData, d'altra parte, è un meccanismo universale in grado di coprire tutte le aree delle attività di un'impresa: finanza, produzione, acquisti e vendite, operazioni di magazzino, ecc. La prima versione del formato include una descrizione di 94 tipi di documenti provenienti da vari aree di attività. 1C prevede di aggiungervi nuovi documenti e di dettagliare quelli esistenti.

Come spiegano i rappresentanti di 1C, l'emergere di EnterpriseData è spiegato dalla necessità non solo di integrare le applicazioni dell'azienda nel software di altri sviluppatori, ma anche, forse anche principalmente, di creare un meccanismo unificato per la comunicazione delle informazioni all'interno della famiglia di software 1C:Enterprise. Fino a poco tempo fa, per risolvere questi problemi veniva utilizzata un’ampia gamma di soluzioni, spesso create caso per caso. La transizione dei prodotti 1C a EnterpriseData è già iniziata e viene utilizzata in tutte le ultime versioni delle sue applicazioni chiave (“1C: ERP Enterprise Management 2.0”, “1C: Accounting 8” 3.0, “1C: Accounting 8 KORP” 3.0, "1C: Vendita al dettaglio" "2.0, "1C: Gestione commerciale" 11). Allo stesso tempo, non è prevista la sostituzione degli standard già utilizzati (CommerceML, collaborazione con le banche) con EnterpriseData, poiché algoritmi specializzati testati nel tempo funzionano in modo più efficiente rispetto agli strumenti universali.

1C ritiene che il nuovo formato troverà ampio utilizzo tra gli sviluppatori indipendenti che creano applicazioni sulla piattaforma 1C:Enterprise; per loro vengono offerti componenti software già pronti come parte della Library of Standard Subsystems (qualcosa come l'SDK per 1C:Enterprise).

Quando si utilizza lo standard EnterpriseData, i dati vengono trasferiti tra applicazioni sotto forma di file XML utilizzando schemi XML appropriati, mentre il trasferimento fisico delle informazioni può essere eseguito utilizzando vari meccanismi: servizi web, condivisione di file tramite directory, FTP ed e-mail. Un punto importante è che l'algoritmo di interazione implica la capacità del destinatario di confermare il fatto di ricevere ed elaborare i dati che gli sono stati inviati. Il file XML stesso viene fornito fisicamente in forma compressa (ZIP), il che spesso consente di ridurre notevolmente il traffico di informazioni.

1C promette un ulteriore sviluppo del formato EnterpriseData e il suo supporto in un numero crescente di applicazioni. Questo standard sarà gestito dall’azienda stessa; i suoi creatori non hanno ancora intenzione di trasformarlo in uno standard di settore indipendente.

Lo scopo di questo articolo è rispondere alle prime domande su CD3 e utilizzare un semplice esempio per mostrare come perfezionare le regole standard. Le informazioni sono utili per i principianti e per coloro che hanno già iniziato ad apprendere e hanno nuove domande.

Abbreviazioni accettate in questa pubblicazione

KD2- Configurazione Conversione dati, edizione 2.0.
KD3- Configurazione Conversione dati, edizione 3.0, configurazione 3.0.5.3.
ED- Formato di scambio universale EnterpriseData.

Risposte alle domande dopo una conoscenza superficiale di KD3. Se sai perché è necessario KD3, non devi leggere questo paragrafo;)

Domande e risposte

• KD3 è una nuova versione di KD2? NO! Questo è un altro strumento che risolve problemi simili a KD2. Ogni strumento ha il suo uso.
• KD3 è migliore di KD2? Non possono essere paragonati perché... Si tratta di strumenti diversi e ognuno ha i suoi pro e i suoi contro.
• Per modificare le regole di scambio KD3 è necessario rimuovere la configurazione dal supporto? NO Non è necessario rimuoverlo dal supporto! Nelle configurazioni standard, normalmente puoi connettere l'elaborazione esterna con le regole e nelle configurazioni che supportano la piattaforma 8.3.10 e versioni successive, puoi modificare le regole utilizzando un'estensione.
• È necessario trasferire i dati dalle proprie configurazioni personalizzate. Per motivi di studio posso utilizzare KD3? Se ti stai ponendo questa domanda, molto probabilmente è impossibile. Per KD3, la configurazione deve includere BSP 2.3 e versioni successive con sincronizzazione tramite formato universale. KD2 ti si addice al 100%, KD3 è discutibile.
• È possibile utilizzare KD3 per configurazioni modificate standard? Si, puoi. Se i tuoi dati non standard possono essere trasmessi utilizzando ED o l'attributo AdditionalInfo, allora va bene. Altrimenti c'è un'opzione per cambiare il formato di scambio (schema XML). In questo caso, le capacità di KD3 saranno quasi uguali a KD2, ma il vantaggio principale di KD3 - l'universalità del formato di scambio - scomparirà.
• È possibile scambiare tra loro le configurazioni abilitate per ED? SÌ! Ma per lo scambio di BP 3.0 - BP 3.0, quando si crea la sincronizzazione, non è possibile selezionare BP 3.0. Nessun problema, seleziona “Altro programma”. Se hai bisogno di uno scambio una tantum, utilizza semplicemente l'elaborazione "Carica Carica EnterpriseData" nel menu Tutte le funzioni.
• Dopo aver aggiornato la configurazione, è necessario scaricare le regole più recenti dal kit di distribuzione? NO! Le regole sono contenute nel modulo di configurazione. Per lo scambio con altri database 1C, non è necessario scaricare le regole di un altro database. Perché? Dettagli in questo articolo.
• Dopo aver aggiornato un database, è necessario aggiornare l'altro database che partecipa allo scambio? NO! Non è necessario aggiornare in modo sincrono tutti i database che partecipano allo scambio. Questo è uno dei vantaggi di KD3.
• Le nostre configurazioni sono state notevolmente migliorate, ci sono nuove tipologie di documenti e libri di consultazione, KD3 può trasferirli? Esiste la possibilità che non sia possibile farlo senza modificare il formato. Questo è uno degli "svantaggi" di KD3 rispetto a KD2.

Perché allora abbiamo bisogno di KD3? Vantaggi e svantaggi

Pro di KD3

Diamo un'occhiata al vantaggio principale di CD3 usando l'esempio di un'attività riscontrata di frequente. Esiste una configurazione UT 11.3 che per qualche motivo non viene aggiornata. È necessario organizzare uno scambio con BP 3.0, che è costantemente aggiornato alla versione attuale.

Nessun problema.

• Il formato di scambio universale utilizzato nel CD3 è progettato per risolvere tali problemi.
• Le regole di scambio in UT non vengono create per lo scambio con il BP, ma per lo scambio con il formato universale EnterpriseData.
• Se operiamo in termini di CD2, allora l'UT si scambia con la configurazione ED, che non cambia. BP 3.0 scambia anche con ED.

Ogni configurazione ha le proprie regole per lo scambio con ED. Pertanto, l'UT carica sempre i dati nello stesso formato. La configurazione BP 3.0, non importa quanto sia nuova, deve essere in grado di accettare dati da questo formato.

Si scopre che nell'UT non è necessario preoccuparsi del fatto che la BP cambi alcuni dettagli. Il compito è semplice: caricare su ED e la configurazione dell'alimentatore deve essere in grado di accettare dati da questo formato.

• Dato che la configurazione di origine viene caricata sempre in un formato, qualsiasi configurazione del ricevitore può caricare dati da questo formato universale.
  Quelli. per una combinazione arbitraria di scambi UT - BP, UT - KA, UT - ERP, KA - BP, ERP - BP. non è necessario scrivere regole individuali. In KD3 le regole sono universali. Qualsiasi configurazione che supporti lo scambio nel formato universale può essere scambiata con qualsiasi configurazione che supporti il ​​formato ED.

Il debug di algoritmi e regole è disponibile nella configurazione stessa, perché tutte le regole sono codice da un modulo comune o elaborazione esterna. Puoi fare a meno del CD3 per correggere rapidamente l'errore.

Contro di KD2

Le regole di scambio sono individuali per ciascuna coppia di configurazioni. Tutte le combinazioni di scambio di cui sopra tra diversi tipi di configurazioni e diverse versioni di configurazioni richiedono le proprie regole di scambio. Pertanto, per risolvere il problema sopra menzionato relativo allo scambio di UT 11.3 e BP 3.0, sarà necessario eseguire il debug e perfezionare le regole di scambio dopo quasi ogni aggiornamento di BP 3.0.

Il debug di algoritmi e regole è difficile per un programmatore alle prime armi o per qualcuno che incontra raramente questo compito. Le regole sono memorizzate in un file xml. Non è disponibile una soluzione rapida. È necessario caricare le regole nel CD2, correggerle e caricarle nuovamente.

Contro di KD3

Il formato universale impone restrizioni sui tipi di documenti e libri di consultazione. È progettato per configurazioni tipiche. Se disponi di dettagli o tipologia di documento non standard, potrebbero sorgere difficoltà durante lo scambio.

Per abilitare la sincronizzazione ED, la configurazione deve supportare questi meccanismi. Tutto questo è in BSP 2.3 e versioni successive. Questo non è davvero un aspetto negativo, è più una caratteristica.

Il vantaggio principale si attenua un po’ a causa del periodo di tempo limitato per il supporto del formato. Ciò è già stato sperimentato dagli utenti di UT 11.1, UT 11.2, che scambiano con BP 3.0. I periodi di supporto sono elencati a questo link. Dice che il periodo minimo garantito di supporto per il formato è di un anno, anzi circa 3 anni. Pertanto, se imposti la sincronizzazione oggi, non potrai aggiornare il database UT 11 per almeno un anno, quindi aggiornare la configurazione o semplicemente aggiungere un nuovo formato, apportare una piccola modifica al BSP e alle regole se necessario . Come farlo? Verrà specificato più avanti in questo articolo.

Pro di KD2

Le possibilità di KD2 sono infinite. Puoi creare regole di scambio per qualsiasi configurazione su qualsiasi piattaforma. Dal 1C 7.7 all'ultimo 8.3. Non è richiesto nulla dalla configurazione, non è richiesto BSP. Le regole possono essere create automaticamente e modificate.

In relazione ai pro e ai contro di cui sopra, si consiglia di utilizzare KD3 per configurazioni tipiche. KD2 può essere utilizzato per qualsiasi configurazione, ma visti i suoi svantaggi, non dimenticare che a volte è più consigliabile utilizzare KD3.

Spero si capisca perché serve KD3, andiamo avanti nel merito.

Abbreviazioni accettate di seguito

BSP- Libreria di sottosistemi standard.
SOTTO- norma sul trattamento dei dati.
PKO- regola di conversione degli oggetti.
PKPD- regola per la conversione dei dati predefiniti.
PKS- regola di conversione della proprietà.

Consideriamo un esempio: è necessario modificare le regole standard per lo scambio di BP 3.0 e UT 11.3

I passaggi delle istruzioni, che si aprono nel CD3, sono indicati su uno sfondo giallo. La sequenza di passaggi proposta in questo articolo è diversa, per non confondersi e completare immediatamente in modo logico l'azione iniziata.

Come cambiare le regole ED?

1. Modificare il modulo con regole di scambio direttamente nella configurazione. Non stiamo ancora valutando questa opzione, perché... Per capire cosa è necessario modificare e dove, è necessario farlo almeno una volta nel CD3. In questo caso, in futuro sarà più semplice risolvere rapidamente i problemi, eseguirne il debug nel modulo e trasferirli su CD3 se necessario.
2. Usa KD3.
   Come viene fatto in KD2? Scarichiamo i metadati di entrambe le configurazioni e li carichiamo nel CD2.
   Passo 1. Per KD3 facciamo lo stesso: in ogni configurazione in modalità aziendale con elaborazione \tmplts\1c\Conversione\3_0_5_3\MD83Exp.epf caricare i metadati di configurazione,
   ad esempio, nella cartella " D:\Regole BP3\BP 3.0.54.15\", nome del file " MD.xml».

Non è chiaro per quale scopo le impostazioni per questo trattamento siano nascoste; di conseguenza, per impostazione predefinita, i dati nei registri di informazioni non vengono caricati. Eliminiamo questa mancanza.
Nella procedura ChangeProcessingMode() del modulo principale, commentare la riga

// Elements.Settings.Visibility = False;

Salviamo l'elaborazione, la apriamo in modalità enterprise, impostiamo il flag su "Scarica registri informazioni" e la scarichiamo.

Passaggio 3. Caricare il file precedentemente creato" MD.xml"in KD3, flag di sezione" Alla nuova versione della configurazione».

Perché in KD3 per lo scambio viene utilizzata una “configurazione intermedia” (ED), di cui carichiamo anche i “metadati”, che è uno schema XML, un file con estensione “xsd”. Passo 2. Puoi prenderlo dalla configurazione UT 11 o BP 3.0. Loro sono la stessa cosa. Apri la configurazione, inserisci “ accedere", vediamo nell'albero Generale: pacchetti XDTO pacchetti come questo: EnterpriseData_1_3_8, EnterpriseData_1_4_4 e simili.. Si tratta delle versioni di formato 1.3 e 1.4, rispettivamente, e 1.2, 1.1, 1.0 se disponibili. Fare clic con il tasto destro sul pacchetto e selezionare "" dal menu contestuale.

Passaggio 4. Nella sezione CD3, seleziona i file precedentemente caricati con estensione “xsd”. È necessario selezionare un file! Scelta multipla con ExchangeMessage non è necessario! Questo era suggerito nelle vecchie istruzioni KD3 delle versioni precedenti. Nell'ultimo CD3 questo non è richiesto.

Dopo aver caricato il formato nella sezione Formato dati - Struttura oggetto formato, seleziona la versione del formato. Se sono presenti documenti e libri di consultazione, hai caricato il file corretto. In caso contrario, ricominciare da capo con un nuovo CD3 vuoto e prima caricare il formato e controllare l'albero.

Fase 2. Dopo aver caricato i metadati nel CD3, procediamo al caricamento delle regole di scambio standard.
Come viene fatto in KD2? Le regole vengono caricate nella conversione.
È quasi lo stesso in KD3. Scarichiamo le regole da quella standard, creiamo una conversione e quindi carichiamo le regole al suo interno.

Scaricamento delle regole standard dalla configurazione per il caricamento nel CD3

Le configurazioni vengono scambiate utilizzando la versione comune massima del formato di scambio. Ad esempio, una configurazione ha un formato massimo 1.5, un'altra 1.6, il che significa che si scambieranno tra loro in formato 1.5. Pertanto è sufficiente scaricare il formato 1.5 da entrambe le configurazioni e caricarlo nelle regole.

Apriamo la configurazione di BP 3.0 o UT 11.3 in modalità configuratore, nella barra di ricerca puoi inserire “ università maschile", aprire il modulo generale. Se questo è BP 3.0, apri . Nel modulo aperto, vai al menu File: salva una copia, salva il file con un nome arbitrario, ad esempio " D:\Regole di BP3\BP 3.0.54.15\Modulo generale Gestore di scambio tramite il modulo Universal Format_».
Apri la configurazione di BP 3.0 o UT 11.3 in modalità aziendale, apri l'elaborazione \tmplts\1c\Conversion\3_0_5_3\Caricamento regole di sincronizzazione.epf

Svantaggio dell'elaborazione tipica:

• spesso fallisce;
• scarica le regole dall'elaborazione esterna connessa al nodo, ma abbiamo bisogno di regole standard;
• non funziona in BP 3.0.53 e versioni successive.

Miglioramento del modulo del modulo di elaborazione principale. Apportiamo modifiche alle procedure Quando creato sul server.

&OnServerProcedureWhenCreatingOnServer(Failure, StandardProcessing) // Elenco di selezione della versione del formato. FormatVersions = Nuova corrispondenza; DataExchangeOverridable.OnReceivingAvailableFormatVersions(FormatVersions); Per ogni ExchangePlan From DataExchangeRe-UseExchangePlansBSP() Ciclo Se DataExchangeRepeatThisExchangePlanXDTO(ExchangePlan) Allora ExchangePlanFormatVersions = Nuova corrispondenza; VersionBSP243 = Scopo generaleClientServer.CompareVersions(StandardSubsystemsServer.LibraryVersion(), "2.4.3.1") >= 0; ModuleDataExchangeServer = GeneralPurpose.GeneralModule("DataExchangeServer"); Se VersionBSP243 Allora ExchangePlanFormatVersions = Data ExchangeModuleServer.CommunicationPlanSettingsValue(ExchangePlan, "ExchangeFormatVersions"); ElseExchangePlans[ExchangePlan].GetExchangeFormatVersions(ExchangePlanFormatVersions); finisci se; Per ogni ExchangePlanVersion da ExchangePlanFormatVersion CycleModuleManager = FormatVersions.Get(ExchangePlanVersion.Key); Se ManagerModule = Non definito Oppure ManagerModule<>ExchangePlanVersion.Value ThenFormatVersions.Insert(ExchangePlanVersion.Key, ExchangePlanVersion.Value); finisci se; FineCiclo; finisci se; FineCiclo; Per ogni FormatVersion DAL ciclo FormatVersion Elements.FormatVersionNumber.SelectionList.Add(FormatVersion.Key); FineCiclo; FormatVersionStorageAddress = PlaceInTemporaryStorage(FormatVersions, UniqueIdentifier); Fine della procedura

• Seleziona "Formatta numero di versione", ad esempio " 1.3 »,
• "Directory di Exchange": crea una cartella, ad esempio ""
• Premi il bottone " Scaricare».

Ripetiamo questi passaggi per altre versioni del formato e li salviamo nelle cartelle appropriate “1.4”, “1.5”, ecc. Per BP 3.0 è sufficiente scaricare tutti i formati dalla 1.3 e successive. Per altre configurazioni dalla 1.2 e successive.

Le regole sono state scaricate, ora devi caricarle nel CD3. In KD2 le regole vengono caricate contemporaneamente alla creazione della conversione. In KD3 devi creare una conversione e caricarvi le regole.
Nella sezione KD3 Conversioni - Conversioni - Crea. . Seleziona una configurazione. Per comodità, puoi modificare il nome della configurazione accedendo alla modalità di modifica dell'elemento. Ad esempio, invece di ContabilitàImprese indicare " BP 3.0.54.15" Oggetti di scena Nome non c'è bisogno di cambiare! Nome le conversioni possono essere specificate allo stesso modo, ad esempio " BP 3.0.54.15" Nella sezione tabella selezioniamo le versioni dei formati supportati. Le versioni del formato sono quelle che abbiamo scaricato dal database sopra. Salva la conversione.

Vai alla sezione Conversione: caricamento delle regole di sincronizzazione dai file.
:

Posizione di caricamento: " Alla conversione esistente»

Directory di scambio: " D:\Regole BP3\BP 3.0.54.15\1.3»

• File con modulo di scambio: " D:\Regole BP3\BP 3.0.54.15\Modulo generale Exchange Manager Through Universal Format13_ Module.txt»
• Conversione: " BP 3.0.54.15»

Durante il caricamento delle regole di sincronizzazione dai file per UT 11.3, viene visualizzato un errore " Campo oggetto non trovato". Motivo - per TekPKO.UseToReceive=False KD3 richiede informazioni sull'opzione di identificazione al momento della ricezione. Se queste non sono nel file delle regole, si verifica un errore. Correggiamo questo malinteso. Rimuovere questo modulo dal supporto o utilizzare l'estensione.

// La forma principale di elaborazione Caricamento delle regole di sincronizzazione dai file // Prima di apportare modifiche: // La procedura carica le regole per la conversione degli oggetti &Sulla procedura server LoadPKO() ... CompilaPropertyValues(TechPKO, AttributeStructure); // Opzione di identificazione - logica speciale. Opzione TechPKO.Identification = Enumerazioni.Opzioni di identificazione oggetto[Struttura attributo.Opzione di identificazione]; ElseIf ReadXML.NodeType = XMLNodeType.EndElement Then // Scrive il software caricato. ... // Le modifiche sono contrassegnate con "//ED" // La procedura carica le regole di conversione degli oggetti &Sulla procedura server LoadPKO() ... FillPropertyValues(TechPKO, AttributeStructure); // Opzione di identificazione - logica speciale. Se TechPKO.UseToReceive Then //ED TechPKO.IdentificationOption = Enumerations.ObjectIdentificationOptions[AttributeStructure.IdentificationOption]; finisci se; ElseIf ReadXML.NodeType = XMLNodeType.EndElement Then // Scrive il software caricato. ...

Premi il bottone " Scaricamento». « I gestori sono destinati ad un'altra conversione: BP 3.0.44 (formato 1.4). Continuare il download?» Fare clic su « SÌ».
Senza chiudere il modulo, seleziona un altro “ Directory di scambio" e premere il pulsante " ". Ripetiamo più volte il caricamento delle regole per ciascun formato nella conversione corrente.
Dopo aver scaricato con successo, vai alla sezione “ Conversioni" - "Impostazione delle regole di conversione", apri la nostra conversione dal modulo elenco.
Se vediamo , POD, ecc., il caricamento nel CD3 è avvenuto con successo.

Verifica che le regole siano caricate correttamente

Questa è un'operazione facoltativa! Se utilizzi una versione del formato nelle regole, non è necessario garantire che il testo del modulo sia identico.

• Apri il configuratore BP, crea una nuova elaborazione esterna, ad esempio Nome " Sincronizzazione EDBP", sinonimo" Sincronizzazione ED BP 3.0».
• In KD3 nella forma " Impostazione delle regole di scambio"Fai clic sul pulsante "" e incolla questo codice dagli appunti nella nostra nuova elaborazione.
• Nel configuratore dell'alimentatore controlliamo il modulo per eventuali errori di sintassi. Salviamo l'elaborazione.
• creare un'altra elaborazione vuota nel BP, ad esempio Nome " Sincronizzazione EDBP tipica", sinonimo" Sincronizzazione ED BP 3.0 tipica" Copia il testo del modulo generale BP ManagerExchangeThroughUniversalFormat13 nel modulo di elaborazione e salvarlo.

Confrontiamo entrambi i trattamenti. Menù File: confronta i file.

Se un modulo standard contiene procedure che non sono presenti nelle nostre regole, significa che non hai caricato le regole nella conversione per tutti i formati di dati. Se necessario Carichiamo le regole nel formato mancante nella conversione e ripetiamo il confronto delle nostre regole con quelle standard. Quando hai raggiunto l'identità puoi tranquillamente iniziare a modificare le regole. Non è necessario ottenere l'identità completa se si sa quale formato di scambio non verrà utilizzato durante la sincronizzazione.

In modo simile creiamo una conversione per UT 11.3 in KD3.

BP 3.0.54.15

• È stato rilevato un caricamento errato del software " Directory_Utenti". Deve essere corretto. Deve.
• Nel PKO" Documento_Inventario Merci_Spedizione"per PKS" Persona responsabile" il software non è specificato. Aprire, selezionare nuovamente la proprietà di configurazione e la proprietà di formato in modo che venga compilato il loro tipo, dopodiché sarà disponibile una scelta nel campo " Regola di conversione della proprietà". Selezionare " Directory_Individui_Dispatch".

Vediamo un esempio di modifica

Lo scopo principale dell'esempio è mostrare la possibilità di modifiche per trasferire dati aggiuntivi che non rientrano nel formato di scambio.

E' necessario trasferire gli oggetti di scena" TipoNomenclatura" directory "Nomenclatura", tipo di attributo " Directory.TypesNomenclatura". Questo tipo di directory non è ripreso dalle regole standard di KD3 e non è supportato dalla versione del formato ED inferiore alla 1.6.

Esistono diverse opzioni per risolvere questo problema

• Miglioramento del pacchetto XDTO, aggiungendo al formato l'oggetto "Directory.Types of Nomenclature". Di conseguenza, il vantaggio principale del formato universale va perso: cessa di essere universale. Sarà richiesto un miglioramento del pacchetto XDTO in tutti i database che partecipano allo scambio.
• Utilizza la proprietà formato " Dettagli aggiuntivi", che si trova in molti oggetti. Non considereremo questa opzione in questo articolo a causa di una certa complessità. Teniamo presente che esiste un tale metodo.
• Oggetti di scena Informazioni addizionali.È presente nell'intestazione di tutti gli oggetti formato. Digita anyType. Progettato per questi casi. Usiamolo come il modo più semplice.

Prima di iniziare a finalizzare le regole standard, creiamo due gruppi nel gruppo delle regole “ Aggiunto», « Cambiato" Questo viene fatto in " Conversioni -".
Nuovo AML, software, algoritmi, ecc. Creeremo nel gruppo "Aggiunto", oggetti tipici a cui apportiamo modifiche e li trasferiremo nel gruppo "Modificato". Ciò renderà più semplice mantenere le regole modificate in seguito.

Quindi iniziamo.

Modifiche alle regole in UT 11.3

In KD3 nella forma " UT 11.3.4.12 Impostazione delle regole di scambio» nella scheda Algoritmi creazione di un nuovo algoritmo

• Nome dell'algoritmo “AdditionalInfoInsert”
• Gruppo: "Aggiunto"

Parametri: "Dati XDTO, nome, valore aggiuntivo"

Codice dell'algoritmo

Se DataXDTO.Property("AdditionalInfo") AND TypeValue(DataXDTO.AdditionalInfo) = Type("Structure") Allora AdditionalData = DataXDTO.AdditionalInfo; Altrimenti Dati Aggiuntivi = Nuova Struttura; finisci se; DatiAddizionali.Insert(Nome, ValoreAddizionali); DataXDTO.Insert("Info aggiuntive", Dati aggiuntivi);

Salva l'algoritmo e vai alla scheda " Regole di conversione degli oggetti»

Tramite il pulsante " Trovare» cerca “Nomenclatura”, apri il PKO « Directory_Nomenclatura_Invio" Vai alla scheda " Durante l'invio" Lì vediamo il campo "Nome gestore:" "". Puoi apportare modifiche direttamente lì.
Nella configurazione è possibile scrivere codice più complesso che richiede il debug. Stiamo cercando una procedura nel modulo di scambio in UT 11.3 con il nome “ PKO_Directory_Nomenclature_Sending_WhenSendingData"e lo finalizziamo lì.
Per trasferire le modifiche da UT 11.3 a KD3, copiare l'intera procedura negli appunti, in KD3 nella forma “ Impostazione delle regole di scambio"Premi il bottone "".

Per il nostro esempio, il codice è così

Se il valore è riempito (IB Data.Item Type) Allora //ED AdditionalInfoInsert(XDTO Data, "Item Type", Line (IB Data.Item Type.UniqueIdentifier())); Informazioni aggiuntiveInserisci (dati XDTO, "Nome tipo elemento", Scopo generale. Valore attributo oggetto (Dati IB. Tipo nomenclatura, "Nome")); //AdditionalInfoInsert... //aggiungi altri dettagli del servizio EndIf;

Dopo aver trasferito le modifiche sul CD3, premere il pulsante " Salva il modulo del gestore di scambio" e trasferire il codice dal buffer al modulo UT 11.3.

Modifiche alle regole in BP 3.0

Stiamo apportando modifiche al PKO" Directory_Nomenclatura_Ricevuta", nella scheda " Durante la conversione dei dati XDTO", nome della procedura" PKO_Directory_Nomenclature_Receipt_During Data ConversionXDTO".

Codice aggiunto al modulo "PKO_Directory_Nomenclature_Receipt_WhenConvertingDataXDTO"

Se DataXDTO.Property("AdditionalInfo") AND TypeValue(DataXDTO.AdditionalInfo) = Type("Structure") Allora //ED AdditionalData = DataXDTO.AdditionalInfo; Se AdditionalData.Property("Item Type") Allora Nomenclature Type = Data ExchangeXDTOServer.ObjectLink By ObjectUIDXDTO(AdditionalData.Nomenclature Type, Type("DirectoryLink.Nomenclature Types"), Exchange Components); If Item Type.GetObject() = Unfined And AdditionalData.Property("Nomenclature TypeName") Then //Crea un nuovo Nomenclature TypeObject = Directories.Nomenclature Types.CreateElement(); ItemTypeObject.SetLinkNew(NomenclatureType); Nomenclature TypeObject.Name = Dati aggiuntivi.Nomenclature TypeName; // inserisci altri dettagli del servizio FillPropertyValues(NomenclatureTypeObject,AdditionalData); NomenclatureTypeObject.Write(); Tipo di elemento = Nomenclatura TypeObject.Link; finisci se; ReceivedData.ItemType = Tipo oggetto; finisci se; finisci se;

Il codice da solo non è sufficiente. È necessario aggiungere un PCS con la proprietà di configurazione " " e la casella di controllo " nella scheda "Regole di conversione proprietà" Algoritmo di conversione utilizzato".

Trasferiamo il modulo di gestione dello scambio al modulo di configurazione BP 3 o all'elaborazione esterna.

Come caricare le regole KD3 modificate nel database?

Nelle configurazioni che scambiano regole su CD2, ciò avviene nelle impostazioni del nodo. Per le regole create nel CD3, vedremo solo l'opportunità di modificare le regole di registrazione.

Le regole preparate in KD3 possono essere installate nella configurazione in tre modi

1. Rimuovere la configurazione dal supporto e apportare modifiche al modulo comune Gestore di Exchange tramite formato universale;
2. Nelle configurazioni eseguite in modalità compatibilità con la piattaforma 8.3.10 e successive, è possibile apportare correzioni al modulo comune utilizzando un'estensione.
3. Collega un'estensione che sostituisce completamente il modulo generale con regole.
4. Senza rimuovere la configurazione dal supporto, connettere l'elaborazione esterna con regole al nodo;

Con la prima opzione è tutto chiaro, è descritto nella documentazione, lo svantaggio è che bisogna togliere la configurazione dal supporto. La seconda opzione - anche correggere la procedura selezionata con un'estensione non sarà difficile per il programmatore 1C - è necessario confrontare due trattamenti con regole standard e con quelle modificate come descritto sopra in questo articolo, e apportare una modifica alla procedura desiderata .

Terza opzione - utilizzando un'estensione con regole di scambio in un formato universale attualmente il più ottimale. Finora c'è solo un inconveniente: è necessario deselezionare il flag "Modalità provvisoria" quando si collega questa estensione. Ciò ne limita l'utilizzo nei servizi cloud. Stiamo aspettando una decisione da 1C sulla procedura per sostituire le regole di scambio in un formato universale in 1C Fresh.

Il punto è che devi trovare una sezione di codice nella configurazione che è responsabile della selezione di un modulo comune a seconda della versione del formato di scambio e di sostituire la selezione del modulo con il tuo modulo. Esempio per BP 3.0.67:

//////// // Modulo generale Scambio dati sovrascritto &Invece di ("Alla ricezione di AvailableFormatVersions") Procedura ED_WhenReceivingAvailableFormatVersions(FormatVersions) ED_DataExchangeServer.WhenReceivingAvailableFormatVersions(FormatVersions); La fine della procedura //////// // Sincronizzazione della Sincronizzazione del Denyvercalformat: il modulo Manager # Source (); Impostazioni.ThisExchangePlanXDTO = Vero; Impostazioni. Avvertenza sulle mancate corrispondenze della versione ExchangeRule = False; Impostazioni.ExchangeFormat = "http://v8.1c.ru/edi/edi_stnd/EnterpriseData"; FormatVersions = Nuova corrispondenza; ED_DataExchangeServer.WhenReceivingAvailableFormatVersions(FormatVersions); //Impostazioni ED.ExchangeFormatVersions = FormatVersions; Impostazioni.ExchangePlanUsedInServiceModel = Vero; Impostazioni.Algorithms.WhenReceivingExchangeSettingsOptions = True; Impostazioni.Algorithms.WhenReceivingOptionDescriptionSettings = True; Impostazioni.Algorithms.ViewSelectionInteractiveUpload = Vero; Impostazioni.Algorithms.Configure Caricamento interattivo = True; EndProcedure #EndIf //////// // Modulo generale nell'estensione ED_Data ExchangeServer Procedura alla ricezione di AvailableFormatVersions(FormatVersions) ExportFormatVersions.Insert("1.2", ExchangeManagerThroughUniversalFormat); FormatVersions.Insert("1.3", ED_ExchangeManagerThroughUniversalFormat); FormatVersions.Insert("1.4", ED_ExchangeManagerThroughUniversalFormat); FormatVersions.Insert("1.5", ED_ExchangeManagerThroughUniversalFormat); FormatVersions.Insert("1.6", ED_ExchangeManagerThroughUniversalFormat); Fine della procedura //////// // Modulo generale in ED_Exchange Manager Attraverso l'estensione Universal Format // Conversione di BP 3.0.44 (formato 1.6) dal 27/11/2018 11:23:58 // Revisione per BP 3.0.67.x dal 31/12... .

Consideriamo la quarta opzione, che non è descritta nella documentazione, perché non esiste tale possibilità in BSP. Questa opzione è già obsoleta. Elaborazione esterna con regole utilizzato nelle prime versioni con formato di scambio universale. Ora 1C sta gradualmente eliminando questa funzionalità.

In modalità enterprise, nella sezione amministrazione, segui il collegamento Sincronizzazione dati: impostazioni di sincronizzazione dati, premi il bottone " Sintonizzare..."se è presente una sola impostazione oppure " Modifica", se sono presenti più impostazioni. Andare alla modalità di modifica del modulo tramite il menu " " , Espandi " Gruppo", includiamo un elemento del modulo nascosto " ", " OK".
Sulla "scheda" Informazioni sul servizio"scegliere" Percorso per il gestore dello scambio", sostituiamo la nostra elaborazione con le regole presenti.

Collegamento dell'elaborazione esterna con regole a BP 3.0.52 e versioni successive

Nella BP 3.0.52 e versioni successive, per ragioni sconosciute, non viene utilizzata l'elaborazione esterna con regole. L'interfaccia per il collegamento dell'elaborazione rimane. Almeno grazie per quello.

Puoi abilitare l'elaborazione con regole utilizzando un'estensione. È necessario apportare una correzione al modulo comune" Scambio datiXDTOServer", funzione " Versioni del formato di scambio".

Procedura EDm_GetExchangeFormatVersion(FormatVersions, InformationBaseNodeValue) Richiesta = Nuova richiesta("SELECT DIFFERENT | Data SynchronizationThroughUniversalFormat.PathToExchangeManager AS PathToExchangeManager, | Data SynchronizationThroughUniversalFormat.ExchangeFormatVersion AS VersionFor Exchange Mata | FROM | Exchange Plan. Sincronizzazione dei dati tramite il formato universale COME sincronizzare i dati tramite Formato universale | DOVE | Sincronizzazione dei dati tramite il formato universale Percorso al gestore di Exchange<>"""" | E Sincronizzazione dei dati Attraverso UniversalFormat.Link = &Link"); Request.SetParameter("Link", InformationBase Node); Selection = Request.Execute().Select(); While Selection.Next() Loop ProcessingName = Selection.PathToExchangeManager; If NON Scopo generaleClientServer.DebugMode () Quindi Dati di elaborazione = Nuovi dati binari (Nome di elaborazione); Indirizzo di elaborazione = Posiziona nell'archivio temporaneo (Dati di elaborazione); Se per scopo generale. Esiste protezione contro azioni pericolose () Quindi Nome di elaborazione = Elaborazioni esterne. Connect (Indirizzo di elaborazione, Scopo generale. Descrizione della protezione senza avvisi ()); Else Processing Name = Elaborazioni esterne. Connect (Indirizzo di elaborazione funziona); EndIf; EndIf; ExchangeManager = ExternalProcessing.Create(ProcessingName); FormatVersions.Insert(Selection. ExchangeFormatVersion, ExchangeManager); EndCycle; EndProcedure &Instead("ExchangeFormatVersions") Funzione EDm_ExchangeFormatVersions(ValueInformationBaseNode) ExchangeFormatVersions = Nuovo effetto di corrispondenza; Se ValueFilled(InformationBaseNode) Allora ExchangePlanName = InformationBaseNode.Metadata().Name; ExchangeFormatVersions = Dati ExchangeServer.ExchangePlanSettingsValue(ExchangePlanName,"ExchangeFormatVersions"); EDm_GetExchangeFormatVersion(ExchangeFormatVersions, nodo InformationBase); In caso contrario, DataExchangeOverridden.WhenReceivingAvailableFormatVersions(ExchangeFormatVersions); finisci se; Se ExchangeFormatVersions.Quantity() = 0 Quindi richiama l'eccezione StringFunctionsClientServer.Substitute ParametriIntoString(NStr("ru = "Non è specificata alcuna versione del formato di Exchange. |Nome del piano di Exchange: %1 |Procedura: Ottieni ExchangeFormatVersions(<ВерсииФорматаОбмена>)""), InformationBaseNode.Metadata().Name); finisci se; Risultato = Nuova corrispondenza; Per ogni versione dal formato Exchange Versione Ciclo Risultato.Insert(AbbrLP(Version.Key), Version.Value); FineCiclo; Risultato restituito; EndFunction

Come eseguire il debug delle regole nell'elaborazione esterna

Nel configuratore" Servizio -> Opzioni -> Avvia 1C:Enterprise -> Opzione di avvio", specificare il parametro " ".

• Di seguito è riportato il codice per l'estensione, per UT 11.4, KA 2.4, ERP 2.4. Il codice per BP 3.0 è riportato sopra. Modulo di gestione del piano di scambio Sincronizzazione dei dati tramite un formato universale.

Codice di estensione EDdebugging

&Invece di("GetExchangeFormatVersions") Procedura ED_GetExchangeFormatVersions(FormatVersions) UT Data Exchange.AvailableVersionsofUniversalFormat(FormatVersions); Richiesta = Nuova richiesta("SELECT DIFFERENT | Sincronizzazione dei dati tramite il formato universale. PathToExchangeManager, | Sincronizzazione dei dati tramite il formato universale. Versione del formato Exchange | DA | Piano di Exchange. Sincronizzazione dei dati tramite il formato universale COME Sincronizzazione dei dati tramite il formato universale | DOVE | Sincronizzazione dei dati tramite il formato universale .PathToExchangeManager<>"""""); Selection = Query.Execute().Select(); While Selection.Next() Loop ProcessingName = Selection.PathToExchangeManager; Se NON General PurposeClientServer.DebugMode() Then //ED ProcessingData = New BinaryData(ProcessingName ) ;ProcessingAddress = PlaceInTemporaryStorage(ProcessingData); If GeneralPurpose.ThereisProtectionFromDangerousActions() ThenProcessingName = ExternalProcessings.Connect(ProcessingAddress, GeneralPurpose.ProtectionDescriptionWithoutWarnings()); AltrimentiProcessingName = ExternalProcessings.Connect(ProcessingAddress); EndIf; EndIf; Gestore di Exchange = ExternalProcessings .Create( ProcessingName); FormatVersions.Insert(Selection.ExchangeFormatVersions, ExchangeManager); EndCycle; EndProcedure &Instead("AvailableVersionsExchangeFormat") Procedura ED_AvailableVersionsExchangeFormat(FormatVersions)Data ExchangeUT.AvailableVersionsofUniversalFormat(FormatVersions); For request = New Request("SELECT VARIOUS | Sincronizzazione dei dati tramite Universal Formato: PathToExchangeManager, | Sincronizzazione dei dati tramiteUniversalFormat.VersionExchangeFormat |FROM | Piano di scambio Sincronizzazione dei dati tramite il formato universale COME Sincronizzazione dei dati tramite il formato universale | DOVE | Sincronizzazione dei dati tramite Universal Format.PathToExchangeManager<>"""""); Selection = Query.Execute().Select(); While Selection.Next() Loop ProcessingName = Selection.PathToExchangeManager; Se NON General PurposeClientServer.DebugMode() Then //ED ProcessingData = New BinaryData(ProcessingName ) ;ProcessingAddress = PlaceInTemporaryStorage(ProcessingData); If GeneralPurpose.ThereisProtectionFromDangerousActions() ThenProcessingName = ExternalProcessings.Connect(ProcessingAddress, GeneralPurpose.ProtectionDescriptionWithoutWarnings()); AltrimentiProcessingName = ExternalProcessings.Connect(ProcessingAddress); EndIf; EndIf; Gestore di Exchange = ExternalProcessings .Create( ProcessingName); FormatVersions.Insert(Selection.ExchangeFormatVersion, ExchangeManager); EndCycle; EndProcedure

Il debug è più semplice da eseguire in un database di file. Impostiamo un punto di interruzione nell'elaborazione con regole. Per trovare la procedura richiesta, utilizziamo KD3. Troviamo PKO, POD o Algoritmo, guarda " Nome del gestore" O " Nome dell'algoritmo", cerca questa procedura nel modulo delle regole. Dopo aver modificato il modulo, non dimenticare di copiare la procedura nel buffer e premere il pulsante "" nel CD3. Fai attenzione, la stessa conversione deve essere aperta.

È tutto per ora. Queste informazioni sono già sufficienti affinché un programmatore 1C possa padroneggiare autonomamente KD3 e mantenere un metodo moderno di sincronizzazione tra i database 1C. Se ci sono ancora dei punti vuoti, chiedi, l'articolo verrà integrato e potrai ritornarci se hai dimenticato qualcosa.

Collegamenti noti alla documentazione su KD3:

• 1C-Centro di formazione n. 3, "Conversione dati 3.0" - http://www.1c-uc3.ru/konvert30.html

È possibile espandere l'ambito di applicazione di KD3 utilizzando queste pubblicazioni:

• - le configurazioni delle versioni precedenti sulla piattaforma 8.2 e precedenti vengono convertite in compatibili con ED.

Puoi risparmiare tempo e utilizzare regole già pronte per le ultime versioni delle configurazioni qui

• - Funzionalità ampliate, correzioni di bug.

Stampa (Ctrl+P)

Scambio tramite un formato universale

Il sottosistema “Scambio dati” della libreria dei sottosistemi standard contiene 4 opzioni (tecnologie) per lo scambio di informazioni tra varie basi di informazioni:

• basi di informazione distribuite (RIB);
• scambio dati attraverso un formato universale;
• scambio dati secondo regole di scambio (le regole di scambio vengono create utilizzando la configurazione “Conversione dati”, edizione 2.1);
• scambio di dati senza regole di scambio.

Questo articolo discute la tecnologia dello scambio di dati tramite formato EnterpriseData universale. Questa tecnologia è disponibile nella “Libreria dei sottosistemi standard” a partire dalla versione 2.3.1.62. rilasciato all'inizio del 2016. Attualmente, l'ultima edizione di BSP 2.3 (da utilizzare con la piattaforma 1C:Enterprise 8.3 non inferiore alla versione 8.3.8.1652 con modalità compatibilità disabilitata) ha la versione 2.3.6.17.

Riso. 1 Ultime versioni di BSP 2.3

Tra i file per la fornitura delle soluzioni applicative 1C, c'è un file di testo “Versioni libreria”, dove è scritto sulla base di quale versione del BSP è stata sviluppata l'applicazione, ad esempio, sulla base della soluzione applicativa UT 11.3.3.231, È stato formato BSP 2.3.5.65.

Tieni presente che per l'utilizzo con la versione della piattaforma "1C:Enterprise 8.3" non è inferiore 8.3.10.2168 l'edizione è stata rilasciata con la modalità di compatibilità disabilitata BSP2.4.

Descrizione del formato EnterpriseData

Qual è il formato EnterpriseData?

Si tratta di un formato che permette di descrivere un oggetto della base informativa (controparte, fattura, ecc.) o di segnalare il fatto che tale oggetto è stato cancellato. Si prevede che la configurazione che riceve il file nel formato EnterpriseData reagirà di conseguenza: creerà nuovi oggetti ed eliminerà quelli contrassegnati come eliminati nel file. È destinato allo scambio di informazioni tra le configurazioni UT, RT, UNF, BP. Il formato può essere utilizzato anche per scambiare informazioni con qualsiasi altro sistema informativo: non dipende dalle caratteristiche del proprio software o delle strutture di base delle informazioni che partecipano allo scambio e non contiene evidenti restrizioni d'uso.

Versione in formato EnterpriseData

I dati del formato sono archiviati nei pacchetti XDTO nei rami generali di configurazione del database, come mostrato in Fig. 2

Nella fig. 2 mostra che esistono diversi pacchetti XDTO. Queste sono diverse versioni del formato. Il numero di versione del formato è composto da X.Y.Z, dove X.Y è la versione, Z è la versione minore. La versione Minor viene aumentata in caso di correzioni di bug e altre modifiche in cui: viene mantenuta la funzionalità della logica di conversione dei dati basata sulla versione precedente del formato (mantenendo la compatibilità con le versioni precedenti degli attuali algoritmi di trasferimento dati attraverso il formato); Il supporto per le nuove funzionalità di formato per la logica di conversione è volontario. Un esempio di tali modifiche potrebbe essere la correzione di un errore, la modifica delle proprietà degli oggetti formato, l'aggiunta di proprietà il cui utilizzo non è obbligatorio durante la conversione dei dati. Negli altri casi, quando cambia il formato, la versione Major aumenta: X – in caso di ristrutturazione globale, Y – negli altri casi.
Il formato descrive la rappresentazione di oggetti (documenti o elementi di directory) sotto forma di file XML. La versione 1.0.1 contiene la descrizione di 94 oggetti di diversi settori (finanza, produzione, acquisti e vendite, operazioni di magazzino). I nomi dei tipi, di regola, sono ben compresi e non necessitano di ulteriori spiegazioni: ad esempio "Documento.Atto di lavoro completato" o "Directory.Controparti". Come puoi vedere, la descrizione dei tipi di documento inizia con il prefisso "Documentario." e l'elemento directory inizia con il prefisso "Directory.". Una descrizione più dettagliata del formato può essere trovata
L'ultima versione è la 1.3, tuttavia la versione più comunemente utilizzata è la 1.0. Non c'è molta differenza tra le versioni. Formato EnterpriseDataExchange_1_0_1_1 utilizzato durante lo scambio tramite un servizio web.
Notare che con cui viene utilizzato il pacchetto di formati dati EnterpriseData ExchangeMessage durante la creazione delle regole di conversione. È questo pacchetto che contiene l'oggetto tipo Informazioni addizionaliche può avere qualsiasi tipo di valore e viene utilizzato durante la creazione di una regola di conversione tra oggetti di configurazione. che non sono nel formato dati. Esattamente, grazie Informazioni addizionaliPuoi adattare e personalizzare le regole di scambio senza modificare i dati del formato nei pacchetti XDTO.

Come scambiare dati in formato EnterpriseData?

Lo scambio di dati in formato EnterpriseData con configurazione è uno scambio di file. In risposta al file ricevuto dall'applicazione esterna, la configurazione lo elaborerà e creerà un file di risposta. I file possono essere scambiati:

• tramite una directory di file dedicata,
• tramite directory FTP,
• attraverso un servizio web distribuito sul lato infobase. Il file di dati viene passato come parametro ai metodi web.

Nota. Per lo scambio dati bidirezionale tra un'applicazione di terzi e la configurazione lato infobase è necessario effettuare una serie di impostazioni: l'applicazione di terzi deve essere registrata nell'infobase, per essa deve essere definito un canale di scambio (tramite un file o una directory FTP), ecc. Ma nei casi di integrazione semplice, quando è sufficiente trasferire solo le informazioni da un'applicazione di terze parti all'infobase e non è richiesto il trasferimento inverso dei dati dall'infobase a un'applicazione di terze parti (ad esempio, l'integrazione di un negozio online che trasferisce le informazioni sulle vendite a 1C: Contabilità), esiste una versione semplificata del funzionamento tramite un servizio web che non richiede impostazioni laterali.

Quando si effettua uno scambio utilizzando i piani di scambio della configurazione durante la sincronizzazione, vengono trasmesse solo le informazioni sulle modifiche avvenute dall'ultima sincronizzazione (per ridurre al minimo la quantità di informazioni trasferite). La prima volta che esegui la sincronizzazione, la configurazione scaricherà tutti gli oggetti formattati EnterpriseData in un file XML (poiché sono tutti "nuovi" per l'applicazione di terze parti).

Il passaggio successivo riguarda l'applicazione di terze parti: deve elaborare le informazioni dal file XML e inserirle nella sezione durante la successiva sessione di sincronizzazione informazione che un messaggio dalla configurazione con un certo numero è stato ricevuto con successo (inserire il numero del messaggio ricevuto dalla configurazione nel campo ReceivedNo). Il messaggio di ricezione segnala alla configurazione che tutti gli oggetti sono stati elaborati con successo dall'applicazione esterna e non è più necessario trasmettere informazioni su di essi. Il file XML proveniente da un'applicazione di terze parti può contenere, oltre alla ricevuta, anche i dati per la sincronizzazione (nella sezione ).

Dopo aver ricevuto il messaggio di ricezione, la configurazione contrassegna tutte le modifiche inviate nel messaggio precedente come sincronizzate correttamente. Solo le modifiche non sincronizzate agli oggetti (creazione di nuovi, modifica ed eliminazione di quelli esistenti) verranno inviate all'applicazione esterna durante la successiva sessione di sincronizzazione.

Quando si trasferiscono i dati da un'applicazione esterna alla configurazione, l'immagine è invertita. La domanda deve compilare la sezione di conseguenza, e nella sezione posizionare gli oggetti da sincronizzare nel formato EnterpriseData.

Dopo l'elaborazione del file, la configurazione genererà un file XML che conterrà un messaggio di ricezione e nuovi dati per la sincronizzazione dal lato configurazione (se presenti dall'ultima sessione di sincronizzazione).

Puoi vedere maggiori dettagli sullo scambio di dati con soluzioni applicative sulla piattaforma 1C:Enterprise nel formato EnterpriseData

Modulo generale del “gestore degli scambi attraverso un formato universale”.

Procedure e funzioni che descrivono completamente le regole per scaricare i dati dalla base di informazioni nel formato di scambio e le regole per caricare i dati dal formato di scambio nella base di informazioni sono sviluppate in un modulo comune: il modulo di gestione dello scambio attraverso un formato universale.

Il modulo viene creato automaticamente utilizzando la configurazione “Conversione Dati”, edizione 3.0, in base alle regole di scambio configurate, oppure manualmente nel configuratore.

Il modulo è composto da diverse grandi sezioni, ciascuna delle quali contiene il proprio gruppo di procedure e funzioni.

1. Un commento. La prima riga del modulo contiene un commento con il nome della conversione. Questa riga è necessaria per identificare il modulo quando si utilizza il comando, ad esempio, nel programma Data Conversion, edizione 3.0. // Conversione UP2.2.3 dal 01/06/2017 19:51:50
2. Procedure di conversione. Contiene procedure predefinite eseguite in diverse fasi della sincronizzazione dei dati: prima della conversione, dopo la conversione, prima del riempimento differito.
3. Regolamento sul trattamento dei dati (DPR). Contiene procedure e funzioni che descrivono le regole per il trattamento dei dati.
4. Regole di conversione degli oggetti (OCR). Contiene procedure e funzioni che descrivono le regole per la conversione degli oggetti, nonché le regole per la conversione delle proprietà di questi oggetti.
5. Regole predefinite di conversione dei dati (PDC). Contiene una procedura che compila le regole per la conversione dei dati predefiniti.
6. Algoritmi. Contiene algoritmi arbitrari chiamati da altre regole (POD o PKO).
7. Opzioni. Contiene la logica per compilare i parametri di conversione.
8. Scopo generale. Contiene procedure e funzioni ampiamente utilizzate in regole e algoritmi.

Di seguito sono descritti i parametri delle procedure e delle funzioni utilizzate in diversi tipi di procedure nel modulo di gestione.

Componenti di scambio. Tipo - Struttura. Contiene parametri e regole di scambio inizializzate come parte della sessione di scambio.

Direzione dello scambio. Tipo: stringa. O "Invia" o "Ricevi".

Dati IB. Tipo: DirectoryObject O DocumentOggetto.

Procedure relative agli eventi di conversione

Esistono tre procedure predefinite che vengono richiamate durante il processo di conversione:

• Prima della conversione. Chiamato prima che venga eseguita la sincronizzazione dei dati. Questa procedura in genere ospita la logica per inizializzare vari parametri di conversione, inserire valori predefiniti, ecc. Parametri: Scambio di componenti.
• DopoConversione. Chiamato dopo il completamento della sincronizzazione dei dati, ma prima che si verifichi il riempimento lento. Opzioni: Scambio di componenti.
• Prima del riempimento ritardato. Chiamato prima che si verifichi il riempimento lento. Qui può essere localizzata la logica per ordinare o aggiustare la tabella degli oggetti soggetti a riempimento lento. Opzioni: Scambio di componenti.

Procedure antiriciclaggio

Compila le Norme sul trattamento dei dati. Una procedura di esportazione che contiene la logica per la compilazione delle regole di elaborazione dei dati. Contiene chiamate ad altre procedure che aggiungono una regola per l'elaborazione di un oggetto specifico alla tabella delle regole (vedere le procedure di seguito Aggiungi antiriciclaggio). Opzioni: Direzione dello scambio, Regole per il trattamento dei dati

Aggiungi UNDER_<ИмяПОД>. Un insieme di procedure che popolano la tabella SOTTO le regole per oggetti specifici. Il numero di tali procedure corrisponde al numero di AML previsto per questa conversione nel programma Data Conversion, versione 3.0. Opzioni: Regole per il trattamento dei dati(una tabella di valori inizializzata nell'ambito della sessione di scambio).

SOTTO_<ИмяПОД>_Durante l'elaborazione. La procedura contiene il testo del gestore Durante l'elaborazione per una specifica AML. Il gestore è progettato per implementare la logica di conversione a livello di oggetto. Ad esempio, assegnare un PQO specifico a un oggetto specifico a seconda del contenuto dell'oggetto. Opzioni:

• Dati InformazioniB O DatiXDTO(a seconda della direzione dello scambio):
• durante l'invio – oggetto ( DirectoryObject,DocumentOggetto);
• al ricevimento: una struttura con una descrizione dell'oggetto XDTO.
• Uso del PKO. Tipo - Struttura. La chiave contiene una stringa con il nome del PCO e il valore di type Booleano (VERO– Viene utilizzato PKO, Menzogna– PKO non viene utilizzato).
• Scambio di componenti.

SOTTO_<ИмяПОД>_Campionamento dati. La funzione contiene il testo del gestore Durante lo scarico. Il gestore è progettato per implementare un algoritmo arbitrario per la selezione degli oggetti da scaricare. Valore restituito: un array di oggetti da scaricare. L'array può contenere sia collegamenti a oggetti dell'infobase sia una struttura con dati per il caricamento. Opzioni: Scambio di componenti.

Procedure PKO

Compila le Regole di conversione degli oggetti. Una procedura di esportazione che contiene la logica per compilare le regole per la conversione degli oggetti. Contiene chiamate ad altre procedure che aggiungono una regola di conversione di oggetti specifica alla tabella delle regole (vedere le procedure di seguito Aggiungi PKO). Opzioni: Direzione dello scambio, Regole di conversione(una tabella di valori inizializzata nell'ambito della sessione di scambio).

AggiungiPKO_<ИмяПКО>. Un insieme di procedure che popolano la tabella PKO con regole per oggetti specifici. Il numero di tali procedure corrisponde al numero di PKO previsti per questa conversione nel programma Data Conversion, versione 3.0. Opzioni: Regole di conversione(una tabella di valori inizializzata nell'ambito della sessione di scambio).

PKO_<ИмяПКО>_WhenSendingData. La procedura contiene il testo del gestore Durante l'invio per uno specifico PKO. Il gestore viene utilizzato durante il caricamento dei dati. Progettato per implementare la logica per convertire i dati contenuti in un oggetto infobase in una descrizione di un oggetto XDTO. Opzioni:

• Dati InformazioniB. Tipo - DirectoryObject, DocumentOggetto. L'oggetto della base informazioni in fase di elaborazione.
• DatiXDTO. Tipo - Struttura. Progettato per accedere ai dati degli oggetti XDTO.
• Scambio di componenti.
• StackUploads. Tipo - Vettore. Contiene collegamenti a oggetti scaricati, tenendo conto della nidificazione.

PKO_<ИмяПКО>_Durante la conversione dei dati XDTO. La procedura contiene il testo del gestore Durante la conversione di DataXDTO per uno specifico PKO. Il gestore viene utilizzato durante il caricamento dei dati. Progettato per implementare la logica di conversione dei dati XDTO arbitraria. Opzioni:

• DatiXDTO. Tipo - Struttura. Proprietà dell'oggetto XDTO che sono state preelaborate per facilitarne l'accesso.
• Dati ricevuti. Tipo - DirectoryObject, DocumentOggetto. Un oggetto infobase formato convertendo i dati XDTO. Non registrato nel database delle informazioni.
• Scambio di componenti.

PKO_<ИмяПКО>_Prima di registrare i dati ricevuti. La procedura contiene il testo del gestore Prima di registrare i dati ricevuti per uno specifico PKO. Il gestore viene utilizzato durante il caricamento dei dati. Progettato per implementare una logica aggiuntiva che deve essere eseguita prima di registrare un oggetto nell'infobase. Ad esempio, le modifiche dovrebbero essere caricate nei dati di sicurezza delle informazioni esistenti o dovrebbero essere caricate come nuovi dati. Opzioni:

• Dati ricevuti. Tipo - DirectoryObject, DocumentOggetto. Un elemento dati generato dalla conversione dei dati XDTO.

Registrato se questi dati sono nuovi per l'infobase (parametro Dati InformazioniB contiene il valore Non definito).

Altrimenti Dati ricevuti sostituire Dati InformazioniB(tutte le proprietà da Dati ricevuti trasferito a Dati InformazioniB).

Se non è richiesta la sostituzione standard dei dati di sicurezza delle informazioni con i dati ricevuti, è necessario scrivere la propria logica di trasferimento e quindi impostare il parametro Dati ricevuti Senso Non definito:

• Dati InformazioniB. Tipo - DirectoryObject, DocumentOggetto. Un elemento di dati dell'infobase corrispondente ai dati ricevuti. Se non vengono trovati dati corrispondenti, contiene Non definito.
• Conversione delle proprietà. Tipo - Tabella dei valori. Contiene le regole per la conversione delle proprietà dell'oggetto corrente, inizializzate come parte della sessione di scambio.
• Scambio di componenti.

Procedure PCPD

Compila le Regole di Conversione dei Dati Predefiniti. Una procedura di esportazione che contiene la logica per compilare le regole per la conversione dei dati predefiniti. Opzioni: Direzione dello scambio, Regole di conversione(una tabella di valori inizializzata nell'ambito della sessione di scambio).

Algoritmi

Nel programma “Data Conversion”, edizione 3.0, è possibile creare algoritmi arbitrari chiamati dai gestori AML e PKPD. Il nome, i parametri e il contenuto degli algoritmi vengono determinati durante lo sviluppo delle regole.

Opzioni

Compila i parametri di conversione. Una procedura di esportazione in cui viene compilata la struttura con i parametri di conversione. Opzioni: Opzioni di conversione(tipo - Struttura).

Procedure e funzioni per scopi generali

EseguiManagerModuleProcedure. Opzioni: Nomeprocedura(linea), Opzioni(struttura). Una procedura di esportazione, che ha lo scopo di chiamare una procedura del modulo non di esportazione, il cui nome e parametri vengono ricevuti come input. Consente di chiamare una procedura o una funzione su una riga senza utilizzare un metodo Eseguire.

EseguiManagerModuleFunction. Opzioni: Nomeprocedura(linea), Opzioni(struttura). Funzione e scopo simili EseguiManagerModuleProcedure. La differenza è che chiama una funzione e ne restituisce il valore.

Invia questo articolo alla mia email

Le ragioni principali della necessità di implementare lo scambio tra i database 1C sono la presenza di filiali e la separazione delle tipologie contabili, perché Spesso le aziende operano in diversi database di informazioni. L'impostazione dello scambio 1C 8.3 consente di eliminare il doppio lavoro: inserendo gli stessi documenti e directory in due programmi, nonché di fornire rapidamente gli oggetti di sistema necessari per varie filiali e dipartimenti.

Nel caso in cui sia necessario lo scambio tra filiali, viene utilizzata la RIB (Distributed Information Base). Questo è un meccanismo di scambio tra configurazioni identiche. Rappresenta un albero con il nodo radice più importante in alto, sotto una coppia di nodi interconnessi. Le modifiche possono essere apportate in qualsiasi nodo di questo sistema e verranno trasmesse agli altri nodi collegati. Inoltre distribuisce non solo i dati, ma anche le modifiche alla configurazione dal nodo radice ai nodi slave.

Se è necessario separare i tipi di contabilità, ad esempio mantenendo quelli operativi nel database di negoziazione e quelli regolamentati nel database di contabilità, sono disponibili meccanismi di scambio universali con impostazioni flessibili di sincronizzazione dei dati.

Uno degli ultimi sviluppi 1C è il formato di scambio dati EnterpriseData. È facile da usare ed è destinato allo scambio all'interno dell'azienda sia tra database 1C che programmi di terze parti.

L'implementazione dello scambio di dati in un'impresa può essere rappresentata sotto forma di procedure sequenziali.

Innanzitutto è necessario determinare tra quali banche dati deve avvenire lo scambio; sarà uno scambio bidirezionale o unidirezionale; se unidirezionale, quale database trasmetterà le informazioni e quale le riceverà solo; se si tratta di una rete di filiali complessa, è necessario registrare uno schema di costruzione del database.

Quindi selezioniamo il formato appropriato: RIB, formato universale; scambiare secondo le regole di scambio; scambio senza regole di scambio.

Il passo successivo è selezionare un veicolo per effettuare lo scambio. È disponibile un'ampia selezione di tecnologie, evidenziamo le principali: directory (locale o di rete), risorsa FTP, connessioni COM, servizio web, posta elettronica.

Il quarto passo sarà quello di identificare i dati: documenti, libri di consultazione e, se necessario, dettagliarli fino alle singole generalità da trasferire.

E in conclusione, viene prescritto un programma di frequenza di scambio

Ogni opzione per l'impostazione dello scambio 1C 8.3 richiede un'attenta preparazione. La sua implementazione va oltre le capacità di ogni utente, è necessario tenere conto di molte sfumature e comprendere i principi dello scambio. Particolare attenzione dovrà essere posta alla configurazione se i database: contengono modifiche o molte aggiunte. dettagli, differiscono nelle versioni della piattaforma o utilizzano versioni obsolete delle configurazioni, l'impresa è grande e utilizza un sistema automatizzato costituito da un gran numero di database. Qui gli errori non sono accettabili perché... può portare a conseguenze irreparabili. L'implementazione indipendente dello scambio in 1C è consigliata solo se è necessario impostare un semplice trasferimento di informazioni tra configurazioni standard.

Se dubiti delle tue capacità, è meglio non salvare, ma contattare uno specialista competente che ti aiuterà a risolvere il complesso problema della configurazione degli scambi 1C 8.3.

Se si decide comunque di configurare gli scambi 1C senza coinvolgere esperti, si consiglia di effettuare prima dei test su copie dei database e, prima di iniziare a lavorare nei database funzionanti, caricare le configurazioni per poter tornare allo stato originale in caso di errori.

Di seguito forniamo un esempio dettagliato di impostazione unilaterale dello scambio 1C 8.3 tra le configurazioni standard Trade Management 11 (UT) e Enterprise Accounting 3.0 (BP). L'esempio è rilevante per molte aziende impegnate nel commercio all'ingrosso e al dettaglio. Nell'UT viene mantenuta la contabilità di gestione, nella BP - regolamentata, lo scambio è necessario per facilitare il lavoro degli utenti.

Questo algoritmo è adatto anche per altre configurazioni standard sulla piattaforma 1C 8.3

Innanzitutto, svolgeremo un lavoro preparatorio per il destinatario delle informazioni, ad es. per la BP. Lanciamo il programma in modalità Enterprise. È necessario impostare la costante Sincronizzazione dati (sezione Amministrazione → Sincronizzazione dati).

Presta attenzione al campo Prefisso; qui devi specificare un valore che ti permetterà successivamente di distinguere (tramite il valore del codice directory o del numero documento) in quale programma sono stati originariamente creati gli oggetti. Nel nostro esempio, è adatta la solita abbreviazione BP e UT, se l'impostazione dello scambio 1C 8.3 viene eseguita per uno scambio complesso tra un numero elevato di database, nonché configurazioni identiche, sarà necessario inserire ciascun database con la propria designazione chiara .

Poiché l'alimentatore è solo un ricevitore di informazioni, procediamo alla configurazione dell'UT.

Qui, proprio come nel BP, è necessario abilitare la sincronizzazione e specificare un prefisso. Queste informazioni sono disponibili nella sezione Anagrafica e amministrazione → Impostazioni sincronizzazione dati.

Selezionare il metodo di configurazione: specificare le impostazioni manualmente. Ulteriore.

Impostiamo un'opzione di connessione diretta, quando entrambi i programmi si trovano sulla stessa rete locale, specifichiamo i parametri per la connessione alla directory di sicurezza delle informazioni su questa rete e inseriamo anche le informazioni di autenticazione dell'utente (nel database BP). Ulteriore.

Il sistema verificherà la correttezza dei dati specificati e, in caso di esito positivo, visualizzerà la finestra delle impostazioni di scambio 1C 8.3.

Fare clic sul collegamento Modifica regole di caricamento dati per accedere alle impostazioni per lo scambio. Chiariremo i dati anagrafici - caricare solo quelli utilizzati nei documenti, selezionare le organizzazioni e la possibilità di lavorare con i contratti - senza riferimento, separazione dei documenti per magazzino. Lo scambio inizia il 1 marzo dell'anno in corso.

Scriviamo le regole introdotte e le chiudiamo.

Poiché l'esempio riguarda la trasmissione unidirezionale di informazioni, nella finestra delle impostazioni successiva per ricevere dati da un altro programma, è necessario impostare i valori su Non inviare. Registra e chiudi. Ulteriore.

Ora bisogna controllare i parametri inseriti e se sono corretti cliccare su Avanti, altrimenti tornare al passo precedente cliccando Indietro.

Ti verrà quindi richiesto di sincronizzare. Fare clic su Fine.

Se è necessario correlare oggetti identici di due configurazioni, si aprirà una finestra per il confronto dei dati. Eseguiamo il confronto e facciamo clic su Avanti.

Durante il trasferimento degli oggetti possono verificarsi situazioni problematiche; è possibile visualizzare i risultati cliccando sul collegamento Avvisi durante la sincronizzazione dei dati.

Una volta completata la sincronizzazione, verrà visualizzata una finestra che conferma il corretto completamento di questo processo.

Qui, utilizzando il comando Configura o successivamente, nello script di sincronizzazione, è possibile configurare una pianificazione per l'esecuzione automatica dello scambio.

Hai bisogno di impostare lo scambio di dati?

DA 15 ANNI PROGRAMMIAMO 1C E REALIZZIAMO VIDEO ISTRUZIONI GRATUITE

Abbiamo un team di programmatori che hanno una vasta esperienza nella creazione di scambio 1C:

Tra le configurazioni 1C,

Nell'impostare lo scambio 1C con altri programmi.

Perché scegliere noi?

Fino a 2 ore di tempo di risposta per attività urgenti, anche nei fine settimana e nei giorni festivi.

Oltre 40 programmatori a tempo pieno con esperienza 1C da 5 a 20 anni.

Realizziamo istruzioni video sulle attività completate.

Comunicazione dal vivo tramite qualsiasi messenger conveniente per il cliente.

Il 99% delle attività viene eseguito tramite accesso remoto (TeamViewer o RDP), il che riduce significativamente i tempi di completamento delle attività.

Partner ufficiali dell'azienda 1C dal 2006.

Esperienza di automazione di successo da piccole imprese a grandi aziende.

Il 99% dei clienti è soddisfatto dei risultati, il che è confermato dalle lettere di ringraziamento.