1c uniwersalna wymiana danych w formacie xml. Wygląd i cechy wykorzystania uniwersalnej wymiany danych. Dlaczego więc potrzebujemy KD3? Zalety i wady

• Wideo – 21 godzin dydaktycznych
• Materiały dydaktyczne w formacie PDF - 117 stron A4
• 16 praktycznych zadań z rozwiązaniami nauczyciela

Forma kursu, wsparcie

Materiały dostępne są od razu po opłaceniu zamówienia – pobierasz je ze strony i zapoznajesz się z nimi w dogodnym dla siebie momencie.

Wsparcie jest zapewniane za pośrednictwem Grupy Master na stronie internetowej.

Należy aktywować pełny dostęp do grupy Master nie później niż 100 dni od daty zakupu.

Znaczenie kursu

Materiały szkoleniowe dotyczą wersji BSP 2.3.2.73.

Jeśli planujesz korzystać ze starszych wersji BSP, to pamiętaj, że zmieniły się mechanizmy operacyjne podsystemu „Wymiana danych” BSP, zmieniły się także interfejsy.

Nowy kurs dla najnowszych wersji BSP jest w fazie opracowywania i zostanie wydany za kilka miesięcy. Ale w przypadku wersji BSP 2.3.2.73 i młodszych istotna będzie aktualna stawka.

Opłata za kurs

9700 rubli

Gwarancja

Uczymy od 2008 roku, jesteśmy pewni jakości naszych kursów i dajemy z siebie wszystko standardowa 60-dniowa gwarancja.

Oznacza to, że jeśli zacząłeś brać udział w naszym kursie, ale nagle zmieniłeś zdanie (lub powiedzmy, że nie masz możliwości), to masz 60 dni na podjęcie decyzji – a jeśli dokonasz zwrotu, zwracamy 100 % płatności.

Płatność ratalna

Nasze kursy można opłacić w ratach lub w ratach, w tym bez odsetek. W której Otrzymujesz natychmiastowy dostęp do materiałów.

Jest to możliwe przy wpłatach od osób fizycznych w wysokości 3000 RUB i więcej. do 150 000 rubli.

Wszystko, co musisz zrobić, to wybrać metodę płatności „Płatność przez Yandex.Checkout”. Następnie na stronie systemu płatności wybierz „Zapłać w ratach”, podaj termin i kwotę płatności, wypełnij krótki formularz – a za kilka minut otrzymasz decyzję.

Opcje płatności

Akceptujemy wszystkie główne formy płatności.

Od osób fizycznych– płatności kartami, płatności pieniądziem elektronicznym (WebMoney, YandexMoney), płatności za pośrednictwem bankowości internetowej, płatności za pośrednictwem sklepów komunikacyjnych i tak dalej. Istnieje również możliwość zapłaty za zamówienie w ratach (na raty), w tym bez dodatkowych odsetek.

Rozpocznij składanie zamówienia - w drugim kroku możesz wybrać preferowaną metodę płatności.

Od organizacji i indywidualnych przedsiębiorców– płatność bezgotówkowa, zapewniamy dokumenty dostawy. Wprowadzasz zamówienie i od razu możesz wydrukować fakturę do zapłaty.

Szkolenie kilku pracowników

Nasze kursy przeznaczone są do nauki indywidualnej. Trening grupowy na jednym zestawie jest nielegalną dystrybucją.

Jeśli firma musi przeszkolić wielu pracowników, zazwyczaj oferujemy „zestawy dodatkowe”, które kosztują o 40% mniej.

Aby złożyć zamówienie na „zestaw dodatkowy” wybierz w formularzu 2 lub więcej zestawów kursów zaczynając od drugiego seta koszt kursu będzie o 40% tańszy.

Istnieją trzy warunki korzystania z zestawów dodatkowych:

• Nie można dokupić jedynie zestawu dodatkowego, jeśli wcześniej nie zakupiono (lub wraz z nim) przynajmniej jednego zestawu zwykłego
• Nie ma innych rabatów na dodatkowe zestawy (są już przecenione, byłoby to „rabatem na rabacie”)
• promocje nie obowiązują na dodatkowe zestawy (na przykład rekompensata w wysokości 7000 rubli) z tego samego powodu

Drukuj (Ctrl+P)

Wymiana w uniwersalnym formacie

Podsystem „Wymiana Danych” biblioteki podsystemów standardowych zawiera 4 opcje (technologie) wymiany informacji pomiędzy różnymi bazami informacji:

• rozproszone bazy informacji (RIB);
• wymiana danych w formacie uniwersalnym;
• wymiana danych zgodnie z regułami wymiany (reguły wymiany tworzone są za pomocą konfiguracji „Konwersja danych” wydanie 2.1);
• wymiana danych bez zasad wymiany.

W artykule omówiono technologię wymiany danych poprzez uniwersalny format EnterpriseData. Technologia ta jest dostępna w „Standardowej Bibliotece Podsystemów” począwszy od wersji 2.3.1.62. wydany na początku 2016 roku. Obecnie najnowsza edycja BSP 2.3 (do użytku z platformą 1C:Enterprise 8.3 nie niższą niż wersja 8.3.8.1652 z wyłączonym trybem zgodności) ma wersję 2.3.6.17.

Ryż. 1 Najnowsze wydania BSP 2.3

Wśród plików dostarczających rozwiązania aplikacyjne 1C znajduje się plik tekstowy „Wersje bibliotek”, w którym zapisano, na podstawie której wersji BSP aplikacja została opracowana, na przykład w oparciu o rozwiązanie aplikacyjne UT 11.3.3.231, Powstał BSP 2.3.5.65.

Należy pamiętać, że do użytku z platformą „1C:Enterprise 8.3” w wersji nie niższej 8.3.10.2168 edycja została wydana z wyłączonym trybem zgodności BSP 2.4.

Opis formatu EnterpriseData

Co to jest format EnterpriseData?

Jest to format, który pozwala opisać obiekt bazy informacji (kontrahent, faktura itp.) lub zgłosić fakt usunięcia tego obiektu. Oczekuje się, że konfiguracja otrzymująca plik w formacie EnterpriseData zareaguje odpowiednio - utworzy nowe obiekty i usunie te, które w pliku są oznaczone jako usunięte. Przeznaczony jest do wymiany informacji pomiędzy konfiguracjami UT, RT, UNF, BP. Format może być również używany do wymiany informacji z dowolnymi innymi systemami informatycznymi: nie jest zależny od cech własnego oprogramowania lub struktur baz informacji biorących udział w wymianie i nie zawiera oczywistych ograniczeń w użyciu.

Wersja formatu EnterpriseData

Dane w formacie są przechowywane w pakietach XDTO w ogólnych gałęziach konfiguracji bazy danych, jak pokazano na rys. 2

Rys. 2 XDTO – pakiety formatu danych EnterpriseData

Na ryc. 2 pokazuje, że istnieje kilka pakietów XDTO. Są to różne wersje formatu. Numer wersji formatu składa się z X.Y.Z, gdzie X.Y to wersja, Z to wersja mniejsza. Wersja Minor zostaje zwiększona w przypadku poprawek błędów i innych zmian, w których: zachowana zostaje funkcjonalność logiki konwersji danych w oparciu o poprzednią wersję formatu (zachowanie wstecznej kompatybilności bieżących algorytmów przesyłania danych poprzez format); Obsługa nowych możliwości formatowania logiki konwersji jest dobrowolna. Przykładem takich zmian może być poprawienie błędu, zmiana właściwości obiektów formatu, dodanie właściwości, których użycie nie jest obowiązkowe przy konwersji danych. W pozostałych przypadkach przy zmianie formatu zwiększa się wersja Major: X – w przypadku restrukturyzacji globalnej, Y – w pozostałych przypadkach.
Format opisuje reprezentację obiektów (dokumentów lub elementów katalogów) w postaci plików XML. Wersja 1.0.1 zawiera opis 94 obiektów z różnych obszarów (finanse, produkcja, zakupy i sprzedaż, operacje magazynowe). Nazwy typów z reguły są dobrze zrozumiałe i nie wymagają dodatkowych wyjaśnień: na przykład „Dokument.Akt ukończonej pracy” lub „Katalog.Kontrahenci”. Jak widać, opis typów dokumentów zaczyna się od przedrostka „Dokument.”, a element katalogu zaczyna się od przedrostka „Katalog”. Bardziej szczegółowy opis formatu można znaleźć
Najnowsza wersja to 1.3, jednak najczęściej używaną wersją jest 1.0. Nie ma zbyt dużej różnicy pomiędzy wersjami. Format EnterpriseDataExchange_1_0_1_1 używane podczas wymiany za pośrednictwem usługi internetowej.
Zauważ to z którym używany jest pakiet formatu danych EnterpriseData Wiadomość wymiany podczas tworzenia reguł konwersji. To właśnie ten pakiet zawiera obiekt typu Dodatkowe informacjektóry może mieć dowolny typ wartości i jest używany podczas tworzenia reguły konwersji pomiędzy obiektami konfiguracyjnymi. które nie są w formacie danych. Dokładnie, dzięki Dodatkowe informacjeMożesz dostosowywać i dostosowywać reguły wymiany bez zmiany formatu danych w pakietach XDTO.

Ryż. 3 Struktura pakietu XDTOExchangeMessage

Jak wymieniać dane w formacie EnterpriseData?

Wymiana danych w formacie EnterpriseData z konfiguracją jest wymianą plików. W odpowiedzi na plik otrzymany z aplikacji zewnętrznej konfiguracja go przetworzy i utworzy plik odpowiedzi. Pliki można wymieniać:

• poprzez dedykowany katalog plików,
• poprzez katalog FTP,
• poprzez usługę sieciową wdrożoną po stronie bazy informacji. Plik danych jest przekazywany jako parametr do metod internetowych.

Notatka. W celu dwukierunkowej wymiany danych pomiędzy aplikacją obcą a konfiguracją po stronie infobazy należy dokonać szeregu ustawień - aplikacja obca musi być zarejestrowana w infobazie, należy dla niej zdefiniować kanał wymiany (poprzez plik lub katalog FTP) itp. Natomiast w przypadku prostej integracji, gdy wystarczy jedynie przenieść informacje z aplikacji innej firmy do bazy danych i nie jest wymagane odwrotne przesyłanie danych z bazy danych do aplikacji innej firmy (np. integracja sklepu internetowego który przekazuje informacje o sprzedaży do 1C: Księgowość), istnieje uproszczona wersja pracy za pośrednictwem usługi internetowej, która nie wymaga ustawień z boku.

W przypadku wymiany przy użyciu planów wymiany konfiguracji podczas synchronizacji przesyłane są tylko informacje o zmianach, które zaszły od ostatniej synchronizacji (aby zminimalizować ilość przesyłanych informacji). Podczas pierwszej synchronizacji konfiguracja zrzuci wszystkie obiekty w formacie EnterpriseData do pliku XML (ponieważ wszystkie są „nowe” w aplikacji innej firmy).

Kolejny krok dotyczy aplikacji innej firmy - musi ona przetworzyć informacje z pliku XML i umieścić je w sekcji podczas kolejnej sesji synchronizacji informacja o tym, że wiadomość z konfiguracji o określonym numerze została pomyślnie odebrana (w polu OtrzymaneNie należy wpisać numer wiadomości otrzymanej z konfiguracji). Komunikat odbioru jest sygnałem dla konfiguracji, że wszystkie obiekty zostały pomyślnie przetworzone przez zewnętrzną aplikację i nie ma już potrzeby przesyłania informacji o nich. Oprócz paragonu plik XML z aplikacji innej firmy może zawierać również dane do synchronizacji (w sekcji ).

Po odebraniu wiadomości potwierdzającej konfiguracja oznacza wszystkie zmiany przesłane w poprzedniej wiadomości jako pomyślnie zsynchronizowane. Jedynie niezsynchronizowane zmiany obiektów (tworzenie nowych, zmiana i usuwanie istniejących) zostaną przesłane do aplikacji zewnętrznej podczas kolejnej sesji synchronizacji.

Podczas przesyłania danych z aplikacji zewnętrznej do konfiguracji obraz się odwraca. We wniosku należy wypełnić sekcję odpowiednio i w sekcji umieść obiekty do synchronizacji w formacie EnterpriseData.

Po przetworzeniu pliku konfiguracja wygeneruje plik XML, który będzie zawierał wiadomość potwierdzającą oraz nowe dane do synchronizacji od strony konfiguracyjnej (jeśli takie istnieją od ostatniej sesji synchronizacji).

Więcej szczegółów na temat wymiany danych z rozwiązaniami aplikacyjnymi możesz zobaczyć na platformie 1C:Enterprise w formacie EnterpriseData

Moduł ogólny „menedżera wymiany w formacie uniwersalnym”.

Procedury i funkcje w pełni opisujące zasady pobierania danych z bazy informacji do formatu giełdowego oraz zasady ładowania danych z formatu giełdowego do bazy informacji opracowane są we wspólnym module - module menedżera wymiany poprzez format uniwersalny.

Ryż. 4 Struktura modułu zarządzającego giełdą w formacie uniwersalnym

Moduł tworzony jest automatycznie przy pomocy konfiguracji „Konwersja Danych” wersja 3.0, w oparciu o skonfigurowane reguły wymiany lub ręcznie w konfiguratorze.

Moduł składa się z kilku dużych sekcji, z których każda zawiera własną grupę procedur i funkcji.

1. Komentarz. Pierwsza linia modułu zawiera komentarz z nazwą konwersji. Linia ta jest niezbędna do identyfikacji modułu w przypadku użycia polecenia np. w programie Data Conversion wersja 3.0. // Konwersja UP2.2.3 z 01.06.2017 19:51:50
2. Procedury konwersji. Zawiera predefiniowane procedury, które są wykonywane na różnych etapach synchronizacji danych: przed konwersją, po konwersji, przed odroczonym wypełnieniem.
3. Zasady przetwarzania danych (DPR). Zawiera procedury i funkcje opisujące zasady przetwarzania danych.
4. Reguły konwersji obiektów (OCR). Zawiera procedury i funkcje opisujące zasady konwersji obiektów, a także zasady konwersji właściwości tych obiektów.
5. Predefiniowane reguły konwersji danych (PDC). Zawiera procedurę wypełniającą reguły konwersji predefiniowanych danych.
6. Algorytmy. Zawiera dowolne algorytmy wywoływane z innych reguł (POD lub PKO).
7. Opcje. Zawiera logikę wypełniania parametrów konwersji.
8. Ogólny cel. Zawiera procedury i funkcje powszechnie stosowane w regułach i algorytmach.

Poniżej opisano parametry procedur i funkcji wykorzystywanych w kilku typach procedur w module menadżerskim.

Wymień komponenty. Typ - Struktura. Zawiera parametry i reguły wymiany zainicjowane w ramach sesji wymiany.

Kierunek wymiany. Typ – ciąg. Albo „Wyślij”, albo „Odbierz”.

Dane IB. Typ – Obiekt katalogu Lub Obiekt dokumentu.

Procedury związane ze zdarzeniami konwersji

Istnieją trzy predefiniowane procedury, które są wywoływane podczas procesu konwersji:

• Przed konwersją. Wywoływane przed wystąpieniem synchronizacji danych. Procedura ta zazwyczaj obejmuje logikę inicjowania różnych parametrów konwersji, wprowadzania wartości domyślnych itp. Parametry: Wymiana komponentów.
• Po konwersji. Wywoływane po zakończeniu synchronizacji danych, ale przed wystąpieniem leniwego dopełniania. Opcje: Wymiana komponentów.
• Przed opóźnionym napełnianiem. Wywoływane przed wystąpieniem leniwego napełniania. Tutaj można znaleźć logikę sortowania lub dostosowywania tabeli obiektów podlegających leniwemu wypełnianiu. Opcje: Wymiana komponentów.

Procedury AML

Wypełnij Zasady przetwarzania danych. Procedura eksportu zawierająca logikę wypełniania reguł przetwarzania danych. Zawiera wywołania innych procedur, które dodają regułę przetwarzania określonego obiektu do tabeli reguł (patrz procedury poniżej Dodaj AML). Opcje: Kierunek wymiany, Zasady przetwarzania danych

Dodaj UNDER_<ИмяПОД>. Zestaw procedur wypełniających tabelę ZGODNIE z regułami dla określonych obiektów. Liczba takich procedur odpowiada liczbie AML przewidzianej dla tej konwersji w programie Data Conversion w wersji 3.0. Opcje: Zasady przetwarzania danych(tabela wartości inicjowana w ramach sesji giełdowej).

POD_<ИмяПОД>_Podczas przetwarzania. Procedura zawiera tekst procedury obsługi Podczas przetwarzania dla konkretnego AML. Procedura obsługi została zaprojektowana w celu implementacji logiki konwersji na poziomie obiektu. Na przykład przypisz określone PQO do konkretnego obiektu w zależności od zawartości obiektu. Opcje:

• Dane informacyjneB Lub DaneXDTO(w zależności od kierunku wymiany):
• podczas wysyłania – obiekt ( Obiekt katalogu,Obiekt dokumentu);
• po otrzymaniu - struktura z opisem obiektu XDTO.
• Korzystanie z PKO. Typ - Struktura. Klucz zawiera ciąg znaków z nazwą PCO i wartością typu Wartość logiczna (PRAWDA– stosuje się PKO, Kłamstwo– PKO nie jest stosowane).
• Wymiana komponentów.

POD_<ИмяПОД>_Próbkowanie danych. Funkcja zawiera tekst procedury obsługi Podczas rozładunku. Procedura obsługi ma na celu implementację dowolnego algorytmu wyboru obiektów do rozładunku. Wartość zwracana: tablica obiektów do wyładowania. Tablica może zawierać zarówno linki do obiektów bazy danych, jak i strukturę z danymi do przesłania. Opcje: Wymiana komponentów.

Procedury PKO

Wypełnij Zasady konwersji obiektów. Procedura eksportu zawierająca logikę wypełniania reguł konwersji obiektów. Zawiera wywołania innych procedur, które dodają konkretną regułę konwersji obiektu do tabeli reguł (patrz procedury poniżej Dodaj PKO). Opcje: Kierunek wymiany, Zasady konwersji(tabela wartości inicjowana w ramach sesji giełdowej).

DodajPKO_<ИмяПКО>. Zestaw procedur wypełniających tabelę PKO regułami dla konkretnych obiektów. Liczba takich procedur odpowiada liczbie PKO przewidzianych dla tej konwersji w programie Data Conversion w wersji 3.0. Opcje: Zasady konwersji(tabela wartości inicjowana w ramach sesji giełdowej).

PKO_<ИмяПКО>_WhenSendingData. Procedura zawiera tekst procedury obsługi Podczas wysyłania dla konkretnego PKO. Procedura obsługi jest używana podczas przesyłania danych. Zaprojektowany do implementacji logiki konwersji danych zawartych w obiekcie infobase na opis obiektu XDTO. Opcje:

• Dane informacyjneB. Typ - Obiekt katalogu, Obiekt dokumentu. Przetwarzany obiekt bazy informacji.
• DaneXDTO. Typ - Struktura. Zaprojektowany, aby uzyskać dostęp do danych obiektowych XDTO.
• Wymiana komponentów.
• Przesyłanie stosu. Typ - Szyk. Zawiera łącza do rozładowanych obiektów, z uwzględnieniem zagnieżdżenia.

PKO_<ИмяПКО>_Podczas konwersji danych XDTO. Procedura zawiera tekst procedury obsługi Podczas konwersji DataXDTO dla konkretnego PKO. Procedura obsługi jest używana podczas ładowania danych. Zaprojektowany do implementacji dowolnej logiki konwersji danych XDTO. Opcje:

• DaneXDTO. Typ - Struktura. Właściwości obiektu XDTO, które zostały wstępnie przetworzone w celu ułatwienia dostępu.
• Otrzymane dane. Typ - Obiekt katalogu, Obiekt dokumentu. Obiekt bazy danych utworzony przez konwersję danych XDTO. Nie odnotowane w bazie danych informacyjnych.
• Wymiana komponentów.

PKO_<ИмяПКО>_Przed zarejestrowaniem odebranych danych. Procedura zawiera tekst procedury obsługi Przed zarejestrowaniem odebranych danych dla konkretnego PKO. Procedura obsługi jest używana podczas ładowania danych. Zaprojektowany, aby zaimplementować dodatkową logikę, którą należy wykonać przed zapisaniem obiektu w bazie danych. Na przykład, czy zmiany należy załadować do istniejących danych dotyczących bezpieczeństwa informacji, czy też należy je załadować jako nowe dane. Opcje:

• Otrzymane dane. Typ - Obiekt katalogu, Obiekt dokumentu. Element danych wygenerowany przez konwersję danych XDTO.

Rejestrowane, jeśli te dane są nowe dla bazy danych (parametr Dane informacyjneB zawiera wartość Nieokreślony).

W przeciwnym razie Otrzymane dane zastępować Dane informacyjneB(wszystkie właściwości z Otrzymane dane przeniesiony do Dane informacyjneB).

Jeżeli nie jest wymagana standardowa zamiana danych bezpieczeństwa informacji na otrzymane dane, należy napisać własną logikę przesyłania, a następnie ustawić parametr Otrzymane dane oznaczający Nieokreślony:

• Dane informacyjneB. Typ - Obiekt katalogu, Obiekt dokumentu. Element danych bazy danych odpowiadający otrzymanym danym. Jeśli nie zostaną znalezione żadne pasujące dane, zawiera Nieokreślony.
• Konwersja właściwości. Typ - Tabela wartości. Zawiera reguły konwersji właściwości bieżącego obiektu, inicjowanego w ramach sesji wymiany.
• Wymiana komponentów.

Procedury PCPD

Wypełnij Zasady konwersji danych predefiniowanych. Procedura eksportu zawierająca logikę wypełniania reguł konwersji predefiniowanych danych. Opcje: Kierunek wymiany, Zasady konwersji(tabela wartości inicjowana w ramach sesji giełdowej).

Algorytmy

W programie „Data Conversion” wersja 3.0 istnieje możliwość tworzenia dowolnych algorytmów wywoływanych z procedur obsługi AML i PKPD. Nazwa, parametry i zawartość algorytmów są ustalane podczas opracowywania reguł.

Opcje

Wypełnij parametry konwersji. Procedura eksportu polegająca na wypełnieniu struktury z parametrami konwersji. Opcje: Opcje konwersji(typ - Struktura).

Procedury i funkcje ogólnego przeznaczenia

Wykonaj proceduręManagerModule. Opcje: Nazwa procedury(linia), Opcje(Struktura). Procedura eksportu, która ma wywołać procedurę modułu nieeksportowego, której nazwa i parametry są odbierane jako dane wejściowe. Umożliwia wywołanie procedury lub funkcji w linii bez użycia metody Wykonać.

Funkcja ExecuteManagerModule. Opcje: Nazwa procedury(linia), Opcje(Struktura). Funkcja, przeznaczenie podobne Wykonaj proceduręManagerModule. Różnica polega na tym, że wywołuje funkcję i zwraca jej wartość.

Podczas opracowywania reguł wymiany 1C 8 powszechnie stosuje się możliwość programowego przedefiniowania zachowania reguł wymiany - mechanizm obsługi. Programy obsługi zdarzeń znacznie rozszerzają funkcjonalność i są niezbędnym narzędziem do konfigurowania reguł wymiany w przypadkach, gdy możliwości interaktywnej konfiguracji nie są wystarczające.

Procedury obsługi i algorytmy są pisane w języku platformy, na której będą wykonywane podczas wymiany.

Jeśli jest to platforma 1C: Enterprise 7.7, kod obsługi jest zintegrowany z kodem przetwarzania przesyłania lub pobierania. W związku z tym każdy moduł obsługi lub algorytm jest podzielony na oddzielną funkcję i jest dostępny do debugowania podczas wymiany.

Jeśli przesyłanie lub pobieranie odbywa się na platformie 1C: Enterprise 8, kod obsługi nie jest zintegrowany z kodem przetwarzania wymiany danych, ale jest przesyłany do pliku reguł wymiany. Podczas procesu wymiany danych kod procedur obsługi lub algorytmów jest pobierany z pliku reguł i wykonywany bezpośrednio w kontekście instrukcji „Run”. Do debugowania kodu procedur obsługi i algorytmów można użyć przetwarzania „Universal XML Data Interchange”.

Zautomatyzowane systemy sterowania w większości przypadków składają się z odrębnych baz danych i często mają strukturę rozproszoną geograficznie. Jednocześnie prawidłowo zrealizowana wymiana danych jest warunkiem koniecznym efektywnego działania takich systemów.

Wstępna konfiguracja giełdy może wymagać szeregu działań, nie tylko w zakresie programowania, ale także doradztwa, nawet jeśli mamy do czynienia z jednorodnymi źródłami, jak ma to miejsce w przypadku produktów na platformie 1C:Enterprise. Dlaczego konfiguracja wymiany 1C (lub, jak to się nazywa, synchronizacja danych w 1C 8.3) może stać się najbardziej czasochłonnym i kosztownym zadaniem projektu integracyjnego, omówimy w tym artykule.

Wymiana danych w środowisku 1C pozwala na:

• Wyeliminuj podwójne wprowadzanie dokumentów;
• Automatyzuj powiązane procesy biznesowe;
• Optymalizuj interakcję pomiędzy rozproszonymi działami;
• Niezwłocznie aktualizuj dane dotyczące pracy specjalistów z różnych działów;
• „Rozróżnij” różne rodzaje rachunkowości.*

*W przypadku, gdy dane jednego rodzaju rachunkowości znacznie różnią się od drugiego, konieczne jest zapewnienie poufności informacji i „ograniczenie” przepływów informacji. Na przykład wymiana danych między 1C UT a 1C Accounting nie wymaga przesyłania danych zarządczych do regulacyjnej bazy danych rachunkowości, tj. synchronizacja w 1C będzie tutaj niekompletna.

Jeśli wyobrazimy sobie standardowy proces realizacji pierwotnej wymiany danych, gdy przynajmniej jeden z jego obiektów jest produktem 1C, możemy wyróżnić następujące etapy:

• Koordynacja składu giełdy;
• Definicja transportu (protokoły wymiany);
• Ustalanie zasad;
• Planowanie.

Identyfikacja składu wymiany 1C

Przedmioty wymiany można podzielić na „źródło” i „odbiorca”. Jednocześnie mogą pełnić dwie role jednocześnie, co będzie nazywane wymianą dwukierunkową. Źródło i miejsce docelowe ustalane są logicznie w zależności od potrzeby lub funkcjonalności systemu.*

*Przykładowo przy integracji „WA: Financier” – rozwiązania do prowadzenia księgowości finansowej i zarządzania procesami skarbowymi, opracowanego na bazie „1C:Enterprise”, eksperci WiseAdvice rekomendują go jako system nadrzędny. Wynika to z dostępności narzędzi kontrolnych pozwalających zachować zgodność z zasadami polityki aplikacyjnej, a co za tym idzie, zapewnić skuteczność rozwiązania.

Następnie na podstawie otrzymanych i zarejestrowanych wymagań użytkowników tworzona jest lista danych do wymiany, ustalana jest jej objętość, wymagania dotyczące częstotliwości wymiany, a także wyznaczany jest proces pracy z błędami i obsługi sytuacji wyjątkowych (kolizji).

Na tym samym etapie, w zależności od floty istniejących systemów i struktury przedsiębiorstwa, ustalany jest format wymiany:

Rozproszona baza informacji

• RIB oznacza wymianę pomiędzy identycznymi konfiguracjami baz danych 1C, z jasną strukturą sterowania „master-slave” dla każdej pary wymiany. Jako element platformy technologicznej, RIB oprócz danych może przesyłać zmiany konfiguracyjne oraz informacje administracyjne bazy danych (ale tylko z mastera na slave).

Uniwersalna wymiana danych w 1C

• Mechanizm pozwalający skonfigurować wymianę baz danych 1C, zarówno z konfiguracjami na platformie 1C:Enterprise, jak i z systemami innych firm. Wymiana odbywa się poprzez przesłanie danych do uniwersalnego formatu xml zgodnie z „Planami Wymiany”.

Dane przedsiębiorstwa

• Najnowsza wersja 1C, mająca na celu wdrożenie wymiany danych w formacie xml pomiędzy produktami stworzonymi na platformie 1C:Enterprise z dowolnymi systemami automatyki. Zastosowanie EnterpriseData upraszcza modyfikacje związane z wymianą. Wcześniej, gdy w systemie znajdowała się nowa konfiguracja, konieczne było wdrożenie mechanizmu importu i eksportu danych, zarówno dla niego, jak i dla istniejących systemów. Teraz systemy obsługujące EnterpriseData nie wymagają żadnych modyfikacji, posiadają tylko jeden punkt wejścia-wyjścia.

Definicja transportu (protokoły wymiany)

Dla systemu na platformie 1C:Enterprise 8 zapewniono szeroki zakres możliwości organizacji wymiany z dowolnymi zasobami informacyjnymi przy użyciu ogólnie przyjętych uniwersalnych standardów (xml, pliki tekstowe, Excel, połączenie ADO itp.). Dlatego przy ustalaniu transportu danych do wymiany należy polegać na możliwościach baz danych systemu zewnętrznego.

Synchronizacja katalogów

Podstawową zasadą skutecznej synchronizacji katalogów jest obecność jednego punktu wejścia. Jeśli jednak mówimy o pracy z katalogami, które historycznie były wypełniane według różnych zasad, konieczne jest jasne zdefiniowanie pól synchronizacji, aby sprowadzić wymianę do „wspólnego mianownika”.*

*Na tym etapie może zaistnieć konieczność przeprowadzenia prac zmierzających do normalizacji danych referencyjnych po stronie źródła danych. W zależności od stanu katalogów i ich objętości proces porównywania elementów, rozpoznawania, identyfikowania błędów i duplikatów, a także uzupełniania brakujących pól i przypisywania pól synchronizacyjnych może wymagać pracy całej grupy ekspertów, zarówno po stronie części integratora (właściciela techniki normalizacji danych podstawowych) oraz po stronie klienta.

Ustalanie zasad

Możliwość wyświetlania danych z systemów źródłowych w odbiornikach uzależniona jest od prawidłowo zdefiniowanych reguł wymiany. Reguły przedstawione w formacie xml regulują zgodność kluczowych szczegółów obiektów źródło-odbiornik. Rozwiązanie 1C:Data Conversion ma na celu automatyzację tworzenia reguł realizacji zarówno jednorazowych, jak i stałych wymian.

Gwarantuje brak utraty danych podczas wymiany Plan wymiany. Jest to integralna część dowolnej konfiguracji na platformie 1C:Enterprise, która w pełni opisuje procedurę wymiany 1C: skład danych (dokumenty ze szczegółami „identyfikującymi”) i węzły (bazy informacji o odbiorniku-nadajniku), a także aktywację RIB dla wybrane kierunki wymiany.

Każda zmiana danych wprowadzonych do Planu Giełdy jest rejestrowana i opatrzona znakiem „zmieniona”. Dopóki zmienione dane nie zostaną dopasowane do siebie w węzłach odbiorczo-nadawczych, znak nie zostanie zresetowany, a system będzie wysyłał komunikaty sterujące do obu węzłów. Po wczytaniu danych i potwierdzeniu ich pełnej zgodności w obu systemach następuje reset znaku.

Harmonogram wymiany w 1C

Aby zautomatyzować regularną wymianę, ustawiana jest częstotliwość przesyłania danych. Częstotliwość wymiany uzależniona jest od potrzeb i możliwości technicznych. Ponadto konfiguracje na platformie 1C:Enterprise pozwalają skonfigurować wymianę danych w przypadku wystąpienia zdarzenia.

Po rozważeniu standardowego procesu wdrażania giełdy zwróćmy uwagę na czynniki, które będą wymagały usprawnień na różnych etapach:

• Niestandardowe, mocno zmodyfikowane konfiguracje baz danych;
• Różne wersje platformy 1C:Enterprise;
• Wersje konfiguracji, które nie były aktualizowane przez długi czas;
• Przedmioty wymiany, które uległy wcześniej modyfikacjom;
• Potrzeba niestandardowych zasad wymiany;
• Zupełnie inny zestaw i układ szczegółów w istniejących podręcznikach.

Ponieważ nawet standardowe działania mające na celu wdrożenie pierwotnej wymiany danych wymagają wiedzy eksperckiej, zaleca się ich przeprowadzanie przy udziale specjalistów 1C. Dopiero po wykonaniu wszystkich opisanych powyżej kroków należy przystąpić do ustawiania centrali w konfiguracji. Przyjrzyjmy się integracji baz danych na przykładzie 1C:UPP i 1C:Retail (wymiana z 1C:UT jest konfigurowana według tego samego schematu). W standardowej synchronizacji zawarta jest także wymiana SCP - SCP, która jest typowa dla wielkoskalowych systemów automatyki w największych przedsiębiorstwach przemysłowych.

W podmenu „Serwis” wybierz „Wymiana danych z produktami na platformie...” (wybranie bezpośredniej wymiany z „Retail” często skutkuje błędami na poziomie obiektów COM). Zwróć uwagę na komunikat serwisowy „Ta funkcja jest niedostępna”.

Aby rozwiązać ten problem, musisz wybrać „Konfiguruj komunikację”

...i zaznacz pole. Następnie zignoruj ​​komunikat o błędzie.

W ustawieniach synchronizacji danych wybierz „Utwórz giełdę z „Retail”...

Przed skonfigurowaniem ustawień połączenia poprzez katalog lokalny lub sieciowy należy upewnić się, że na dysku jest miejsce na ten katalog. Choć z reguły nie zajmuje więcej niż 30-50 MB, w wyjątkowych przypadkach może wymagać nawet 600 MB. Możesz utworzyć wymagany katalog bezpośrednio z konfiguratora.

Łącząc się poprzez katalog sieciowy ignorujemy ofertę skonfigurowania połączenia poprzez adres FTP i e-mail klikając „Dalej”.

W ustawieniach ręcznie wpisujemy prefiksy - symbole baz danych (najczęściej BP, UPP, RO), ustalamy zasady i datę rozpoczęcia przesyłania danych. Przedrostek będzie wskazany w nazwie dokumentów w celu wskazania bazy, w której zostały utworzone. Jeżeli zasady przesyłania nie zostaną zmodyfikowane, dane zostaną domyślnie przesłane według wszystkich dostępnych parametrów.

Tworzymy plik ustawień wymiany dla „Retail”, aby nie powtarzać naszych działań. Jeśli chcesz wysłać dane natychmiast po skonfigurowaniu synchronizacji, zaznacz to pole.

Aby zautomatyzować proces wymiany, musisz ustawić harmonogram.

Menu „Handel detaliczny”.

Zaznacz pole i wybierz „Synchronizacja”.

Konfigurację „odwrotną” wykonujemy wybierając opcję Zarządzanie przedsiębiorstwem produkcyjnym.

Załaduj plik ustawień utworzony w UPP.

Zaznaczamy, system automatycznie pobiera adres.

Postępujemy identycznie jak w UPP.

Weryfikacyjne porównanie danych (Zaleca się ręczne porównywanie danych na etapie przygotowawczym, ponieważ ta praca może stać się najbardziej pracochłonna w procesie realizacji wymiany). Okno porównania otwiera się po dwukrotnym kliknięciu myszką.

W przypadku błędu synchronizacji „Szczegóły…” zostaną zastąpione przez „Nigdy…”.

„Szczegóły…” otwiera dziennik z aktualnymi informacjami o giełdzie.

Gotowy.

Co jest potrzebne do automatycznej wymiany danych, bez dokonywania zmian konfiguracyjnych:
1) Przetwarzanie „Uniwersalnej wymiany danych w formacie XML”, który jest zawarty w większości standardowych konfiguracji. Jeśli go tam nie ma, łatwo go znaleźć na dysku ITS lub w Internecie. W konfiguracji nazywa się to „Universal XML Data Exchange”
2) Zasady wymiany danych. Utworzono przy użyciu „konwersji danych”. Praca, którą będziesz musiał opanować. Istnieją również kursy wideo i samouczki. Na przykład: http://programmist1s.ru/wp-content/uploads/2013/06/Konvertatsiya_dannyih._Metodika_rabotyi_i_primeryi.pdf
3) Przetwarzanie zewnętrzne, zawierający procedury załadunku/rozładunku. Zacznijmy go tworzyć:
W module obiektowym tworzone jest przetwarzanie zewnętrzne, które będzie zawierało poniższy tekst (zastąp swoje dane bazami danych i użytkownikami). Wskazane jest utworzenie osobnego użytkownika z pełnymi uprawnieniami do wymiany danych. Nazwijmy przetwarzanie na przykład „Data Exchange.epf”.

Jeśli LaunchParameter = „Prześlij”, wówczas Processing=Processing.UniversalXMLDataExchange.Create(); //Ustaw parametry niezbędne do przesłania (opcjonalnie do edycji) Processing.ExchangeMode="Upload"; Processing.LoadDataInExchangeMode=True; Processing.WriteRegistersRecordSets = True; Processing.RememberLoadedObjects=True; Processing.UseSelectionByDateForAllObjects=True; Przetwarzanie.UploadOnlyAllowed=True; //!Ustaw parametry niezbędne do przesłania //Te parametry muszą zostać uzupełnione OBOWIĄZKOWE //Ustaw ograniczenia dotyczące przesyłania według dat obiektów Processing.StartDate = CurrentDate() - 60*60*24*2; Processing.EndDate = "00010101"; //Jeżeli chcemy załadować dane do pliku ustawmy na False.Jeśli True to dane zostaną przesłane do odbierającej bazy danych Processing.DirectReadingVIBReceiver=True; //Jeśli bazą danych odbierającą przesłane dane jest serwer, wówczas False. Jeśli plik - True Processing.InformationBaseForConnectionType=True; //!Wymagane parametry zostały uzupełnione //Jeśli przesyłamy dane do pliku If Not Processing.DirectReadingVIBReceiver then Processing.ExchangeFileName = "C:\Inbox\OlegA\Conversion\upload.xml"; //Jeśli przesyłamy dane do bazy danych Inaczej Processing.PasswordInformationBaseForConnection="Admin"; Processing.ConnectionInfoBaseUser="supercool"; Processing.AuthenticationWindowsInformationBaseForConnection=False; //Jeśli odbiorcą danych jest serwer. If Processing.ConnectionInformationBaseType = False then Processing.ConnectionInformationBaseServerName="MainServ"; Processing.InformationBaseNameOnServerForConnection="Buhia"; //Jeśli odbiorcą danych jest plikowa baza danych, w przeciwnym razie Processing.InformationBasePlatformVersionForConnection="V82"; Processing.InformationBaseDirectoryForConnection="C:\Inbox\OlegA\Clients\Zeus BP20\Zeus BP20"; koniecJeśli; koniecJeśli; //Działania przy rejestracji przy rozładunku zgodnie z planami wymiany Processing.RegistrationDeletionTypeofChangesForExchangeNodesAfterUpload=0; // 0 - nie wyrejestrowuj, // 1 - wyrejestruj Processing.LoadExchangeRules(); //JEŚLI POTRZEBUJESZ WGRAĆ ZGODNIE Z PLANAMI WYMIANY, WTEDY WŁĄCZ TEN BLOK I PRZEŚLIJ WŁASNY WĘZEŁ PLANU WYMIANY //Dla każdej strony z Processing.UploadRulesTable.Lines Cycle //Page.Enable=1; // Dla każdej strony 1 z pętli PageLine // Line1.Enable=1; // Page1.LinkToExchangeNode=ExchangePlans.Full. FindByCode("BP20"); //Koniec cyklu; //Koniec cyklu; Przetwarzanie. Wykonaj przesyłanie (); System zamykania (fałsz); ElseIf LaunchParameter = „Załaduj” Następnie ExchangeProcessing = Processing.UniversalXMLDataExchange.Create(); ExchangeProcessing.ExchangeFileName = "C:\Inbox\OlegA\Upload.xml"; ExchangeProcessing.ExchangeMode = "Ładowanie"; ExchangeProcessing.OpenDownloadFile(True); ProcessExchange.ArchiveFile = Fałsz; ProcessExchange.PerformLoad(); ExchangeProcessing = Niezdefiniowany; System zamykania (fałsz); koniecJeśli;

4) Przesyłanie pliku Bat, który uruchomi 1C i przetwarzanie zewnętrzne z parametrem uruchamiania pod użytkownikiem, który jest przeznaczony do wymiany danych. Plik należy utworzyć np. w notatniku++ z kodowaniem OEM (MS-Dos), inaczej nie zadziała. Nazwijmy plik na przykład „BatVygruz.bat”. Tekst będzie następujący:

Jeśli baza danych jest plikiem:
"C:\Program Files (x86)\1cv82\common\1cestart.exe" ENTERPRISE /F"C:\Inbox\KBF\1Cv8_Base_8.1\Zeus 83 BP3\Zeus 83 BP3" /N"Robot wymiany danych" /P "pass" /DisableStartupMessages /RunModeManagedApplication /Execute"C:\Inbox\OlegA\DataExchange.epf" /C"Prześlij"
Wyjaśnienia:

b) C:\Inbox\KBF\1Cv8_Base_8.1\Zeus 83 BP3\Zeus 83 BP3 - Twoja ścieżka do bazy plików, z której będziemy przesyłać dane
c) Robot wymiany danych - nazwa użytkownika, pod którą 1C działa w celu wymiany danych
d) pass - hasło użytkownika
e) /DisableStartupMessages - zamknij wyskakujące okna podczas uruchamiania 1C
e) /RunModeOrdinaryApplication - uruchom grubego klienta w trybie normalnym
g) C:\Inbox\OlegA\Data Exchange.epf - ścieżka do naszego przetwarzania, które rozpocznie się przy uruchomieniu
h) Prześlij - przekazujemy parametr uruchomienia 1C, mówi nam, że musimy przesłać dane

Jeśli baza danych jest oparta na serwerze:
"C:\Program Files (x86)\1cv82\common\1cestart.exe" ENTERPRISE /S"Server1C/DataBase" /N"Data Exchange Robot" /P"pass" /DisableStartupMessages /RunModeManagedApplication /Execute"C:\Inbox\ Oleg\ Data Exchange.epf" /C "Prześlij"
Wyjaśnienia:
a) C:\Program Files (x86)\1cv82\common\1cestart.exe - Twoja ścieżka do startera 1C
b) Server1C/DataBase – Twój serwer, na którym znajduje się baza danych oraz nazwa samej bazy danych, z której pobieramy dane.
Pozostałe parametry są podobne do wersji pliku bat

5) Pobieranie pliku Bat (jeśli to konieczne). Jeśli zdecydujesz się na przesłanie danych do pliku, a nie bezpośrednio do bazy danych. Wtedy też będziemy potrzebować tego przedmiotu (zwykle koniecznego).
Tworzenie pliku do pobrania Bat przebiega podobnie jak w przypadku pliku wysyłania, różni się tylko parametr uruchamiania, zamiast „Prześlij” wstawiamy „Pobierz”

6) Ustaw harmonogram uruchamianiaładowanie/przesyłanie naszych plików Bat na serwer. W tym celu należy przejść do panelu administracyjnego na serwerze i w harmonogramie zadań utworzyć nowe zadanie polegające na uruchamianiu pobierania pliku codziennie o godzinie 23 oraz zadanie pobierania określające plik pobierania Bat (jeśli konieczne) na przykład o godzinie 04:00.