Specjalistyczna konfiguracja „1C: Konwersja danych 2.0”

Wydanie ósmej wersji platformy 1C:Enterprise stało się znaczącym krokiem w rozwoju systemów automatyki. Projektując platformę 1C:Enterprise 8 wzięto pod uwagę ogromne doświadczenie w korzystaniu z rozwiązań opartych na platformie 1C:Enterprise 7.7: wbudowany język platformy i typowe konfiguracje zostały poważnie przeprojektowane, struktura przechowywania i dostępu do danych została zmieniona, powstały nowe rozwiązania branżowe, które realizują zalety nowej platformy. Używanie poprzednich konstrukcji językowych na nowej platformie stało się niewłaściwe.

Aby ułatwić rozwiązanie tego problemu (przenoszenie danych z wersji 7.7 do wersji 8), firma 1C wydała specjalistyczną konfigurację „Data Conversion 2.0”. Został stworzony, aby pomóc specjalistom w rozwiązywaniu różnych problemów przesyłu danych. 1C wydała gotowe reguły przesyłania danych z konfiguracji tego samego typu, na przykład z 1C: Księgowość 7.7 do 1C: Księgowość 8, ale użytkownicy niestandardowych lub zmodyfikowanych standardowych konfiguracji przy przechodzeniu na platformę 1C: Enterprise 8 będziesz musiał samodzielnie utworzyć dane reguł transferu.

Przy całej różnorodności prywatnych metod rozwiązywania problemów z przesyłaniem danych zakres problemów do rozwiązania pozostaje praktycznie niezmieniony:

Synchronizacja informacji referencyjnych (tworzenie nowych, aktualizacja istniejące elementy katalogi, usuwanie, zapisywanie lub zmiana hierarchii, rozgałęzianie danych, przenoszenie historii zmian wartości danych okresowych);

Synchronizacja dokumentów i operacji (tworzenie, modyfikacja dokumentów lub przekształcenie jednego typu dokumentu w inny, scalanie lub powielanie);

Stworzenie wystarczających warunków początkowych dla rejestrów księgowych do prowadzenia działalność gospodarcza(przewóz resztek towarów itp.).

Struktury przechowywania danych w 1C:Enterprise w różnych wersjach i/lub konfiguracjach są różne, więc transfer danych to nie tylko kopiowanie plików lub tabel, ale ich konwersja. Aby transformacja była jednoznaczna i poprawna konieczne jest stworzenie i skonfigurowanie reguł przesyłania danych. Tworzenie i konfigurowanie reguł przesyłania danych pomiędzy różnymi infobazami jest możliwe, jeśli znana jest struktura przechowywania danych w źródłowej i docelowej bazie danych. Opis struktury metadanych konfiguracji powinien być ujednolicony. Konfiguracja Data Conversion 2.0 służy do tworzenia i konfigurowania reguł przesyłania danych na podstawie opisów struktury metadanych konfiguracji źródłowej i docelowej.

Proces przenoszenia danych pomiędzy infobazami składa się z następujących kroków:

• 1. Tworzenie plików opisu metadanych.
• 2. Tworzenie Konfiguracji w "Konwersji Danych".
• 3. Stworzenie samej konwersji.
• 4. Konsekwentne tworzenie reguł konwersji danych.
• 5. Konsekwentne tworzenie reguł przesyłania danych.
• 6. Rzeczywista procedura rozładowywania i ładowania danych z jednej konfiguracji do drugiej.

Dlatego korzystanie z tej wyspecjalizowanej konfiguracji jest jednym z najbardziej efektywnych na ten moment sposoby rozwiązywania tego rodzaju problemów, a ponadto źródło osobistych doświadczeń bardzo przydatnych do celów edukacyjnych, a następnie opracowanie mechanizmu wymiany danych między IS „Server: Rent Calculation” a „1C: Enterprise Accounting” dla LLC ” LLC” metoda oparta na wykorzystaniu konfiguracji „Data Conversion 2.0”.

Konwersja danych 2.0 i 2.1 to konfiguracja technologiczna 1C zaimplementowana na wersjach platformy od 8.1 do 8.3.

Głównym zadaniem narzędzia jest pisanie reguł wymiany między rozwiązaniami aplikacyjnymi 1C 8 i 7. Obecna wersja konwersji danych to dziś 3.0.

Konwersja danych jest bardzo przydatną konfiguracją, dzięki której można rozwiązać nie tylko kwestię przenoszenia informacji z jednej infobazy do drugiej, ale także np. konwertować informacje w ramach jednej bazy danych.

Konfiguracja jest bardzo wygodna w użyciu, gdy .

Konwersja danych przyda się każdemu programiście: posiadanie umiejętności tworzenia reguł wymiany to poważny plus dla umiejętności zawodowych.

Do nauki pracy z konfiguracją najlepiej nadaje się rozwiązywanie praktycznych problemów. Spróbuj wymyślić zadania dla siebie, na przykład: przenieś dowolne informacje z jednej bazy danych do drugiej, zamień dokument wdrożeniowy na dokument odbioru, „jedź” salda bieżące na księgowość w dokumencie „wprowadzanie sald” i inne zadania.

Bardzo przydatne będzie zrozumienie „typowych” zasad wymiany 1C 8.3, często można tam znaleźć ciekawe przykłady realizacji zadań.

Aby zrozumieć podstawy, będziesz potrzebować materiałów, rozważ je poniżej.

Instrukcja wideo do konwersji

Aby zapoznać się z podstawami konfigurowania wymiany danych w 1C przy użyciu konfiguracji „1C Data Conversion”, zobacz przykład wideo:

Materiały, podręczniki do nauki 1C Data Conversion 2.0

W sieci nie ma zbyt wielu materiałów i dokumentacji, starałem się zebrać najważniejsze i najciekawsze materiały:

0. Przede wszystkim radzę bezpłatny kurs wideo Ilyi Leontiev, jest dostępny pod adresem połączyć.

1. Radziłbym przede wszystkim skorzystać z wbudowanej pomocy w konfiguracji. Jest naprawdę dobrze napisany i dobrze zaimplementowany technicznie:

2. Drugim najważniejszym źródłem informacji jest strona http://www.mykod.info/ (strona została zamknięta), specjalizująca się właśnie w konwersji danych. Tam możesz pobrać dużą liczbę materiałów do konwersji.

3. Osobno chciałbym podkreślić podręcznik szkoleniowy podręcznika - (autor - Olga Kuznetsova).

Migracja danych między różnymi konfiguracjami nie jest prostym zadaniem. Jak zawsze rozwiązań jest kilka, ale nie wszystkie są optymalne. Spróbujmy zrozumieć niuanse przesyłania danych i wybrać uniwersalną strategię rozwiązywania takich problemów.

Problem migracji danych (dotyczy to wyłącznie produktów firmy 1C) z jednego rozwiązania do drugiego nie pojawił się wczoraj. Firma 1C doskonale zdaje sobie sprawę z trudności, z jakimi borykają się programiści podczas tworzenia migracji, dlatego stara się jak najlepiej pomóc z narzędziami.

W trakcie rozwoju platformy firma wprowadziła szereg uniwersalnych narzędzi, a także technologie ułatwiające przesyłanie danych. Są one wbudowane we wszystkie standardowe rozwiązania, a problem migracji między identycznymi konfiguracjami został generalnie rozwiązany. Zwycięstwo po raz kolejny potwierdza ścisła integracja standardowych rozwiązań.

Przy migracjach pomiędzy niestandardowymi rozwiązaniami sytuacja nieco się komplikuje. Szeroka gama technologii pozwala programistom samodzielnie wybrać najlepszy z ich punktu widzenia sposób rozwiązania problemu.

Rozważmy niektóre z nich:

• wymiana za pośrednictwem plików tekstowych;
• korzystanie z planów wymiany;
• itp.

Każdy z nich ma swoje plusy i minusy. Podsumowując, główną wadą będzie gadatliwość. Niezależna implementacja algorytmów migracji jest obarczona znacznymi kosztami czasu, a także długim procesem debugowania. Nie chcę nawet mówić o dalszym wspieraniu takich decyzji.

Złożoność i wysokie koszty utrzymania skłoniły firmę 1C do stworzenia uniwersalnego rozwiązania. Technologia, która pozwala maksymalnie uprościć rozwój i obsługę migracji. W efekcie pomysł został wdrożony w postaci osobnej konfiguracji – „Konwersja danych”.

Konwersja danych - rozwiązanie standardowe, samokonfiguracja. Każdy użytkownik posiadający subskrypcję ITS:Prof może pobrać ten pakiet całkowicie bezpłatnie ze strony wsparcia użytkownika lub z dysku ITS. Instalacja odbywa się w standardowy sposób - podobnie jak wszystkie inne standardowe rozwiązania od 1C.

Teraz trochę o zaletach rozwiązania. Zacznijmy od najważniejszego – wszechstronności. Rozwiązanie nie jest dostosowane do niektórych konfiguracji/wersji platformy. Działa równie dobrze zarówno ze standardowymi konfiguracjami, jak i samodzielnie napisanymi. Deweloperzy otrzymują uniwersalną technologię i ustandaryzowane podejście do tworzenia nowych migracji. Wszechstronność rozwiązania pozwala na przygotowanie migracji nawet na inne platformy niż 1C:Enterprise.

Drugi śmiały plus to pomoce wizualne. Proste migracje są tworzone bez programowania. Tak, tak, bez jednej linijki kodu! Tylko dla tego warto poświęcić czas na nauczenie się technologii raz, a potem wielokrotnie korzystać z bezcennych umiejętności.

Trzecią zaletą, na którą chciałbym zwrócić uwagę, jest brak ograniczeń w dystrybucji danych. Deweloper sam wybiera sposób dostarczenia danych do konfiguracji odbiornika. Dostępne są dwie opcje: przesłanie do pliku xml i bezpośrednie połączenie z bazą danych (COM/OLE).

Architektura uczenia się

Wiemy już, że konwersja danych może zdziałać cuda, ale nie jest jeszcze jasne, jakie są zalety techniczne. Pierwszą rzeczą, której należy się nauczyć, jest to, że każda migracja danych (konwersja) opiera się na regułach wymiany. Reguły giełdy - zwykły plik xml z opisem struktury, do której będą wgrywane dane z IB. Przetwarzanie usługi, która dokonuje wgrywania/pobierania danych, analizuje reguły giełdy i na ich podstawie wykonuje wgrywanie. Podczas pobierania następuje proces odwrotny.

Konfiguracja „KD” to rodzaj wizualnego konstruktora, za pomocą którego programista tworzy reguły wymiany. Nie wie, jak przesłać dane. Odpowiada za to dodatkowe przetwarzanie usług zewnętrznych zawarte w pakiecie dystrybucyjnym CD. Jest ich kilka (XX w nazwie pliku to numer wersji platformy):

• MDXXExp.epf- przetwarzanie umożliwia wgranie opisu struktury infobazy do pliku xml. Opis struktury jest ładowany na CD w celu dalszej analizy i tworzenia reguł wymiany.
• V8ExchanXX.epf- wgrywa/pobiera dane z infobazy zgodnie z regulaminem giełdy. W większości typowych konfiguracji przetwarzanie jest dostępne po wyjęciu z pudełka (patrz pozycja menu „Serwis”). Przetwarzanie jest uniwersalne i nie jest związane z żadnymi konkretnymi konfiguracjami/regułami.

OK, teraz w oparciu o powyższe, zdefiniujmy etapy tworzenia nowej konwersji:

1. Definicja zadania. Konieczne jest jasne zrozumienie, jakie dane należy przesłać (z jakich obiektów konfiguracyjnych) i, co najważniejsze, gdzie je przesłać.
2. Przygotowanie opisu struktur konfiguracyjnych (Source/Receiver) do późniejszego załadowania na płytę CD. Zadanie rozwiązuje przetwarzanie usługi MDXXExp.epf.
3. Ładowanie przygotowanych opisów konstrukcji w IS.
4. Tworzenie reguł wymiany z wykorzystaniem wizualnych środków CD.
5. Przesyłanie/pobieranie zgodnie z utworzonymi regułami konwersji danych przy użyciu przetwarzania V8ExchanXX.epf.
6. Debugowanie reguł wymiany (jeśli to konieczne).

Najprostsza konwersja

Do demonstracji potrzebujemy dwóch wdrożonych konfiguracji. Postanowiłem poprzestać na opcji: „Zarządzanie handlem” 10. edycja i małe, własnoręcznie napisane rozwiązanie. Zadaniem będzie przeniesienie danych z typowej konfiguracji UT. Dla zwięzłości napisane rozwiązanie będziemy nazywać „Odbiorcą”, a zarządzanie handlem „Źródłem”. Zacznijmy rozwiązywanie problemu od przeniesienia elementów katalogu „Nomenklatura”.

Przede wszystkim przyjrzyjmy się schematowi konwersji danych i ponownie przeczytajmy listę czynności, które należy wykonać. Następnie uruchamiamy konfigurację „Źródło” i otwieramy w niej przetwarzanie usługi MD82Exp.epf.

Interfejs przetwarzania nie świeci z dużą ilością ustawień. Użytkownik musi jedynie określić typy obiektów metadanych, które nie będą mieściły się w opisie struktury. W większości przypadków tych ustawień nie trzeba zmieniać, ponieważ w rejestrach akumulacyjnych nie ma szczególnego punktu w ruchach rozładunkowych (jako przykład).

Bardziej poprawne jest formowanie ruchu podczas trzymania dokumentów w odbiorniku. Wszystkie ruchy zostaną wykonane przez sam dokument po przeniesieniu. Drugim argumentem w obronie ustawień domyślnych jest zmniejszenie rozmiaru przesyłanego pliku.

Niektóre dokumenty (szczególnie w typowych konfiguracjach) tworzą ruchy w wielu rejestrach. Wyładowanie całej tej ekonomii spowoduje, że wynikowy plik XML będzie zbyt duży. Może to utrudnić późniejszy transport i załadunek do podstawy odbiornika. Im większy plik danych, tym więcej pamięci RAM jest potrzebne do jego przetworzenia. Podczas mojej praktyki zdarzyło mi się napotkać nieprzyzwoicie duże pliki do przesyłania. Takie pliki całkowicie odmówiły przeanalizowania standardowymi środkami.

Pozostawiamy więc wszystkie ustawienia domyślne i wgrywamy opis konfiguracji do pliku. Tę samą procedurę powtarzamy dla drugiej bazy.

Otwórz płytę CD i wybierz z menu głównego „Katalogi” -> „Konfiguracje”. Katalog przechowuje opisy struktur wszystkich konfiguracji, których można użyć do tworzenia konwersji. Opis konfiguracji ładujemy raz, a następnie możemy go wielokrotnie używać do tworzenia różnych konwersji.

W oknie katalogu naciśnij przycisk „ Dodać” iw wyświetlonym oknie wybierz plik z opisem konfiguracji. Zaznacz pole „Prześlij do nowej konfiguracji” i kliknij przycisk „Przeprowadź przesyłanie”. Podobne czynności wykonujemy z opisem struktury drugiej konfiguracji.

Teraz wszystko jest gotowe do stworzenia reguł wymiany. W menu głównym CD wybierz „Referencje” -> „Konwersje”. Dodanie nowego elementu. W oknie tworzenia nowej konwersji należy określić: konfigurację źródła (wybierz UT) i konfigurację odbiornika (wybierz „Odbiornik”). Następnie otwórz zakładkę „Zaawansowane” i wypełnij następujące pola:

• nazwa pliku reguł wymiany - utworzone reguły wymiany zostaną zapisane pod tą nazwą. Nazwę pliku można zmienić w dowolnym momencie, ale najlepiej ustawić ją teraz. Pozwoli to zaoszczędzić czas w przyszłości. Reguły demo nazwałem: „rules-ut-to-priemnik.xml”.
• name - nazwa konwersji. Nazwa może być absolutnie dowolna, ograniczyłem się do „Demo. UT do odbiornika”.

To wszystko, kliknij "OK". Natychmiast pojawia się przed nami okno z prośbą o automatyczne utworzenie wszystkich reguł. Zgoda na tak kuszącą ofertę da mistrzowi polecenie automatycznego przeanalizowania opisu wybranych konfiguracji i samodzielnego wygenerowania reguł wymiany.

Postawmy od razu „i”. Mistrz nie będzie w stanie wygenerować niczego poważnego. Nie należy jednak pomijać tej możliwości. Jeśli potrzebujesz nawiązać wymianę między identycznymi konfiguracjami, bardzo pomocne będą usługi kreatora. W naszym przykładzie preferowany jest tryb ręczny.

Przyjrzyjmy się bliżej oknie „Ustawienia reguł wymiany”. Interfejs może wydawać się nieco mylący - duża liczba zakładek wypełnionych kontrolkami. W zasadzie wszystko nie jest takie trudne, zaczynasz przyzwyczajać się do tego szaleństwa po kilku godzinach pracy z aplikacją.

Na tym etapie interesują nas dwie zakładki: „Reguły konwersji obiektów” oraz „Reguły przesyłania danych”. Na pierwszym musimy ustawić pasujące reguły, czyli porównaj obiekty o dwóch konfiguracjach. Na drugim określ możliwe obiekty, które będą dostępne dla użytkownika do rozładunku.

W drugiej połowie zakładki „Reguły konwersji obiektów” znajduje się dodatkowy panel z dwiema zakładkami: „Konwersja nieruchomości” i „ Konwersja wartości”. Pierwszy z nich wybierze właściwości (rekwizyty) wybranego obiektu, a drugi jest niezbędny do pracy z predefiniowanymi wartościami (na przykład predefiniowanymi elementami słownika lub elementami wyliczenia).

Świetnie, teraz stwórzmy reguły konwersji dla katalogów. Możesz wykonać tę akcję na dwa sposoby: użyj kreatora synchronizacji obiektów (kliknij „”) lub dodaj dopasowania dla każdego obiektu ręcznie.

Aby zaoszczędzić miejsce, skorzystamy z pierwszej opcji. W oknie kreatora odznacz pole „ Dokumenty”(interesują nas tylko katalogi) i poszerzyć grupę” Leksykony”. Uważnie przewijamy listę i patrzymy na nazwy katalogów, które można porównać.

W moim przypadku istnieją trzy takie katalogi: Nomenklatura, Organizacje i Magazyny. Istnieje również katalog Clients, który wykonuje to samo ładowanie semantyczne, co „ Kontrahenci” z konfiguracji” UT”. To prawda, że ​​mistrz nie mógł ich porównać ze względu na ich doskonałe imiona.

Możemy sami naprawić tę usterkę. Znajdź w oknie Mapowania obiektów» podręcznik « Klienci”, aw kolumnie „Źródło” wybierz książkę informacyjną „Kontrahenci”. Następnie zaznacz pole w kolumnie „Typ” i kliknij przycisk „OK”.

Kreator synchronizacji obiektów wyświetli monit o automatyczne utworzenie reguł konwersji właściwości wszystkich wybranych obiektów. Właściwości zostaną dopasowane według nazwy i dla naszej demonstracji to wystarczy, zgadzamy się. Kolejnym pytaniem będzie propozycja stworzenia reguł przesyłania. Zgódźmy się na to.

Podstawa regulaminu giełdy jest gotowa. Wybraliśmy obiekty do synchronizacji, a reguły konwersji właściwości i reguły przesyłania zostały utworzone automatycznie. Zapiszmy reguły wymiany do pliku, a następnie otwórzmy „Źródło” IB (w moim przypadku jest to UT) i rozpocznijmy w nim przetwarzanie usługi V8Exchan82.epf.

Przede wszystkim w oknie przetwarzania wybierz utworzone przez nas reguły wymiany. Na pytanie o ładowanie reguł odpowiadamy twierdząco. Przetwarzanie przeanalizuje reguły wymiany i zbuduje drzewo o tej samej nazwie dla obiektów dostępnych do rozładunku. W tym drzewie możemy ustawić wszelkiego rodzaju filtry lub węzły wymiany, zmieniając potrzebne nam dane. Chcemy wgrać absolutnie wszystkie dane, więc nie ma potrzeby instalowania filtrów.

Po zakończeniu procesu wgrywania danych do pliku przejdź do IB” Odbiorca”. Otwieramy w nim również przetwarzanie V8Exchan82.epf, tylko tym razem przechodzimy do zakładki „Wczytywanie danych”. Wybierz plik danych i kliknij przycisk „Prześlij”. Wszystko, dane zostały pomyślnie przesłane.

Zadania z prawdziwego świata

Pierwsze demo może wprowadzać w błąd. Wszystko wygląda dość prosto i logicznie. W rzeczywistości to nieprawda. W prawdziwej pracy powstają zadania trudne lub całkowicie niemożliwe do rozwiązania za pomocą samych środków wizualnych (bez programowania).

Aby nie zawieść się technologią, przygotowałem kilka realnych zadań. Na pewno spotkasz je w pracy. Nie wyglądają tak trywialnie i sprawiają, że patrzysz na konwersję danych pod nowym kątem. Uważnie rozważ przedstawione przykłady i wykorzystaj je jako fragmenty przy rozwiązywaniu rzeczywistych problemów.

Zadanie numer 1. Uzupełnij brakujące dane

Załóżmy, że musimy przenieść katalog „ Kontrahenci”. Odbiornik ma do tego podobną książkę referencyjną „Klienci”. Całkowicie nadaje się do przechowywania danych, ale ma rekwizyty” Organizacja”, umożliwiając oddzielenie kontrahentów według przynależności do organizacji. Domyślnie wszyscy kontrahenci muszą należeć do bieżącej organizacji (można to uzyskać ze stałej o tej samej nazwie).

Istnieje kilka rozwiązań tego problemu. Rozważymy możliwość wypełnienia rekwizytów” Organizacja”w samej bazie” Odbiorca", tj. w momencie ładowania danych. Obecna organizacja jest przechowywana w stałej, więc nie ma bariery w uzyskaniu tej wartości. Otwórzmy regułę konwersji obiektów (zwaną dalej FRP)” Klienci” (kliknij dwukrotnie obiekt) i w kreatorze konfiguracji reguł przejdź do sekcji „Obsługa zdarzeń”. Na liście handlerów znajdziemy „ Po załadowaniu”.

Opiszmy kod do pobrania bieżącej organizacji z późniejszym przypisaniem do atrybutu. W momencie wyzwolenia obsługi „Po załadowaniu” obiekt będzie w pełni uformowany, ale jeszcze nie zapisany do bazy danych. Nikt nie zabrania nam zmieniać według naszego uznania:

If NOT Object.ThisGroup Then Object.Organization = Constants.CurrentOrganization.Get(); EndIf;

Przed wypełnieniem rekwizytów” Organizacja» należy sprawdzić wartość atrybutu « Ta grupa”. Dla przewodnika ” Klienci» flaga hierarchiczna jest ustawiona, dlatego konieczne jest sprawdzenie grupy. Podobnie odbywa się wypełnianie wszelkich szczegółów. Koniecznie przeczytaj pomoc dotyczącą innych opcji obsługi ” Po załadowaniu”. Na przykład wśród nich jest parametr „ Odmowa”. Jeżeli zostanie mu przypisana wartość „True”, to obiekt nie zostanie zapisany do bazy danych. Dzięki temu możliwe staje się ograniczenie obiektów do zapisu w momencie ładowania.

Zadanie nr 2. Szczegóły w rejestrze informacyjnym

W podręczniku " Kontrahenci"Konfiguracja UT, są szczegóły" Kupujący" oraz " Dostawca”. Oba rekwizyty są typu „ logiczne” i służą do określenia rodzaju kontrahenta. W IB” Odbiorca”, w podręczniku „ Klienci„Nie ma podobnych szczegółów, ale istnieje rejestr informacji” Rodzaje Klientów”. Pełni podobną funkcję i może przechowywać wiele tagów dla jednego klienta. Naszym zadaniem jest przeniesienie wartości danych do odrębnych zapisów rejestru informacyjnego.

Niestety same środki wizualne też tu nie radzą sobie. Zacznijmy od małych, stwórzmy nowe PCO dla rejestru informacyjnego ” Rodzaje Klientów”. Nie podawaj niczego jako źródła. Odrzuć automatyczne tworzenie reguł przesyłania.

Następnym krokiem jest stworzenie reguł przesyłania. Przejdź do odpowiedniej zakładki i kliknij „ Dodać”. W oknie dodawania reguł przesyłania wypełnij:

• metoda próbkowania. Zmień na „Algorytm arbitralny”;
• reguła konwersji. Wybierz rejestr informacji „Typy klientów”;
• Kod (nazwa) reguły. Piszemy to jako „Przesyłanie gatunków klienta”;

Teraz musisz napisać kod do wybierania danych do przesłania. Tutaj parametr „ Próbkowanie danych”. W nim możemy umieścić kolekcję z przygotowanym zbiorem danych. Parametr " Próbkowanie danych" Mogę zaakceptować różne znaczenia- wynik zapytania, wybór, zbiory wartości itp. Inicjujemy go jako tabelę wartości z dwiema kolumnami: klient i typ klienta.

Poniżej znajduje się kod obsługi zdarzeń „ Przed przetwarzaniem”. Inicjuje parametr „ Próbkowanie danych” a następnie wypełnienie danych z katalogu “ Kontrahenci”. Tutaj warto zwrócić uwagę na wypełnienie kolumny „ Typ klienta”. W „UT” mamy cechy typu „Boolean”, a w odbiorcy wyliczenie.

Na tym etapie nie możemy doprowadzić ich do pożądanego typu (nie ma go w UT), więc na razie zostawimy to w postaci sznurków. Nie musisz tego robić, ale od razu chcę pokazać, jak rzutować na brakujący typ w źródle.

Pobieranie danych = NowaTabelaWartości(); Wybór danych.Kolumny.Add("Klient"); Wybór danych.Columns.Add("TypKlienta"); Wybór danych z katalogu = Directorys.Contractors.Select(); Podczas pobierania pętli DataFromCatalog.Next() Jeśli FetchingDataFromCatalog.ThisGroup następnie kontynuuj; EndIf; Jeśli DataFetchFromCatalog.Buyer Then NewString = DataFetch.Add(); NewString.Client = PróbkowanieDanychZKatalogu.Referencja; NewString.ClientType = "Kupujący"; EndIf; Jeśli DataFetchFromCatalog.Provider Then NewString = DataFetch.Add(); NewString.Client = PróbkowanieDanychZKatalogu.Referencja; NewString.ClientType = "Dostawca"; EndIf; Zakończ cykl;

Zapisz regułę przesyłania danych i wróć do „ Zasady konwersji obiektów”. Dodajmy do rejestru informacyjnego „ Rodzaje Klientów zasady konwersji własności: klient i typ klienta. Zostawiamy źródło puste, a w obsłudze zdarzeń „Before discharge” piszemy:

//Dla właściwości „Klient” Value = Source.Client; //Dla właściwości „CustomerType” If Source.Customer = "Buyer" Then Expression = "Enumerations.CustomerTypes.Buyer" ElseIf Source.Customer = "Dostawca" Then Expression = "Enumerations.CustomerTypes.Supplier"; EndIf;

Na liście szczegóły są wypełniane na podstawie dokonanego wyboru danych. Podajemy klienta po prostu jako link i wpisujemy typ klienta w parametrze " Wyrażenie”. Dane tego parametru zostaną zinterpretowane w odbiorniku, a po wykonaniu atrybut zostanie uzupełniony poprawną wartością z wyliczenia.

To wszystko, zasady wymiany są gotowe.Rozważany przykład okazał się dość uniwersalny. Podobne podejście jest często stosowane przy przesyłaniu danych z konfiguracji utworzonych na platformie 7.7. Uderzającym tego przykładem jest transfer danych okresowych.

Zadanie nr 3. Sztuczki tabelaryczne

Często zdarzają się zadania, które wymagają publikowania wierszy jednej części tabelarycznej w kilku. Na przykład w początkowej konfiguracji usługi i towary rejestrowane są w jednym dziale tabelarycznym, natomiast przechowywanie tych podmiotów jest wydzielone w odbiorniku. Ponownie problemu nie da się rozwiązać za pomocą środków wizualnych. Tutaj wygodnie jest przyjąć rozwiązanie drugiego problemu jako podstawę.

Tworzymy regułę przesyłania danych, określamy dowolny algorytm i piszemy zapytanie w module obsługi „Przed przesłaniem”, aby pobrać dane z sekcji tabelarycznej.

Aby zaoszczędzić miejsce, nie podam kodu (zawsze można odwołać się do kodu źródłowego) żądania - nie ma w tym nic niezwykłego. Sortujemy wynikową próbkę i umieszczamy posortowane wyniki w znanym już parametrze „ Próbkowanie danych”. Ponownie wygodnie jest użyć tabeli wartości jako kolekcji:

Pobieranie danych = NowaTabelaWartości(); //Tu będzie jeszcze jedna sekcja tabelaryczna Data Selection.Columns.Add("Produkty"); //Tutaj będzie również sekcja tabelaryczna Data Selection.Columns.Add("Usługi"); Wybór danych z.Kolumny.Dodaj(„Link”);

Zadanie nr 4. Przenoszenie danych do operacji

Jeśli organizacja korzysta z kilku systemów księgowych, prędzej czy później pojawi się potrzeba migracji danych z późniejszym tworzeniem księgowań.

W konfiguracji " BP„istnieje dokument uniwersalny” Operacja” i jest idealny do formowania większej liczby drutów. Oto tylko jeden problem - dokument jest wykonany sprytnie i nie jest tak łatwo przenieść do niego dane.

Przykład takiej konwersji można znaleźć w kodzie źródłowym artykułu. Ilość kodu okazała się dość duża, więc nie ma sensu publikować go do artykułu. Powiem tylko, że przesyłanie ponownie wykorzystuje dowolny algorytm w zasadach przesyłania danych.

Zadanie nr 5. Synchronizacja danych w wielu atrybutach

Omówiliśmy już kilka przykładów, ale do tej pory nie rozmawialiśmy o synchronizacji obiektów podczas migracji. Wyobraźmy sobie, że potrzebujemy przenieść kontrahentów i część z nich prawdopodobnie znajduje się w bazie danych odbiorcy. Jak przesyłać dane i zapobiegać duplikatom? W związku z tym CD oferuje kilka sposobów synchronizacji przesyłanych obiektów.

Pierwszy to unikalny identyfikator. Wiele obiektów ma unikalny identyfikator, który gwarantuje unikalność w obrębie tabeli. Na przykład w podręczniku „ Kontrahenci” nie może mieć dwóch elementów o tym samym identyfikatorze. Płyta CD dokonuje obliczeń w tym zakresie, a dla wszystkich utworzonych PSP wyszukiwanie według identyfikatora jest domyślnie natychmiast włączone. Podczas tworzenia PSP powinieneś zauważyć ikonę lupy obok nazwy obiektu.

Synchronizacja za pomocą unikalnego identyfikatora jest niezawodną metodą, ale nie zawsze jest odpowiednia. Podczas łączenia katalogów „ Kontrahenci” (z kilku różnych systemów) niewiele mu pomaga.

W takich przypadkach lepiej jest synchronizować obiekty według kilku kryteriów. Bardziej poprawne jest wyszukiwanie kontrahentów według NIP, KPP, Nazwy lub rozbicie wyszukiwania na kilka etapów.

Konwersja danych nie ogranicza programisty w definiowaniu kryteriów wyszukiwania. Rozważmy abstrakcyjny przykład. Załóżmy, że musimy zsynchronizować katalogi” Kontrahenci” z różnych baz informacyjnych. Przygotujmy PCP i w ustawieniach reguł konwersji obiektu zaznacz pole „ Kontynuuj wyszukiwanie w polach wyszukiwania, jeśli obiekt odbiorcy nie zostanie znaleziony według ID”. Dzięki tej akcji od razu zdefiniowaliśmy dwa kryteria wyszukiwania - według unikalnego identyfikatora i dowolnych pól.

Mamy prawo do samodzielnego wyboru pól. Po zanotowaniu numeru NIP, KPP, nazwy natychmiast wskażemy kilka kryteriów wyszukiwania. Wygodna? Całkiem, ale znowu to nie wystarczy. A co jeśli chcemy zmienić kryteria wyszukiwania? Na przykład najpierw szukamy garści TIN + KPP, a jeśli nic nie znajdziemy, to zaczynamy próbować szczęścia z nazwą.

Zaimplementowanie takiego algorytmu jest całkiem możliwe. W obsłudze zdarzeń Pola wyszukiwania” możemy określić do 10 kryteriów wyszukiwania i dla każdego z nich zdefiniować własną kompozycję pól wyszukiwania:

Jeśli SearchOptionNumber = 1, SearchPropertyNameString = „TIN, KPP”; ElseIfSearchVariantNumber = 2 ThenSearchPropertyNameString = „Nazwa”; EndIf;

Zawsze istnieje wiele rozwiązań.

Każde zadanie ma kilka rozwiązań, a przesyłanie danych między różnymi konfiguracjami nie jest wyjątkiem. Każdy programista ma prawo wybrać własną ścieżkę rozwiązania, ale jeśli stale musisz opracowywać skomplikowane migracje danych, to zdecydowanie polecam zwrócenie uwagi na konfigurację „”. Niech na początku trzeba zainwestować środki (czas) w szkolenia, ale z nawiązką zwrócą się one na pierwszym mniej lub bardziej poważnym projekcie.

Moim zdaniem firma 1C niezasłużenie omija temat korzystania z konwersji danych. Przez cały czas istnienia technologii opublikowano na niej tylko jedną książkę: „1C: Enterprise 8. Konwersja danych: wymiana między rozwiązaniami aplikacyjnymi”. Książka jest dość stara (2008), ale nadal warto się z nią zapoznać.

Znajomość platformy jest nadal wymagana

» jest narzędziem uniwersalnym, ale jeśli planujesz używać go do tworzenia migracji danych z konfiguracji opracowanych dla platformy 1C:Enterprise 7.7, to będziesz musiał poświęcić czas na zapoznanie się z wbudowanym językiem. Składnia i ideologia języka jest bardzo różna, więc musisz poświęcić czas na naukę. Reszta zasady pozostaje taka sama.

Mechanizm obsługi zdarzeń jest jedną z kluczowych technologii konwersji danych przy użyciu „Konwersji danych 2.0”. Umiejętne i umiejętne wykorzystanie tego mechanizmu pozwala programiście na szybkie rozwiązanie niemal każdego zadania konwersji danych. Za pomocą technologii procesorowej można łatwo wdrożyć wybór danych, konwersję danych różne rodzaje, złożone selekcje danych, ustawienia konwersji i wiele innych zadań.

Rozważ podstawowe zasady tej technologii. W kluczowych punktach algorytmów wyładowywania i ładowania danych w przetwarzaniu uniwersalnej wymiany możliwe jest wykonanie kodu programu zaczerpniętego z reguł wymiany danych, a nie „na stałe” w przetwarzaniu wyładowania lub ładowania danych. Konfiguracja „Data Conversion 2.0” daje możliwości zintegrowania takiego kodu programu z regułami wymiany danych.

W sumie w algorytmach wymiany danych istnieje ponad dwadzieścia różnych miejsc, w których można wykonać kod innej firmy. W związku z tym konfiguracja przewiduje tworzenie różnego rodzaju programów obsługi zdarzeń.

Kod obsługi zdarzeń jest „dołączony” do obiektów reguł wymiany - elementy katalogów: konwersje, reguły konwersji obiektów, reguły konwersji własności, reguły przesyłania danych oraz reguły czyszczenia danych. Oczywiście kod obsługi zdarzeń musi spełniać szereg wymagań. W szczególności do sterowania procesem konwersji w kodzie handler'a konieczne jest użycie zmiennych specjalnych - parametrów. Pełny opis wszystkich typów obsługi zdarzeń i dostępnych zmiennych można znaleźć w informacjach o procedurach obsługi w odpowiednich formularzach.

UWAGA!!!

Technologie Data Conversion 2.0 umożliwiają wymianę danych z bazami informacyjnymi zaimplementowanymi na platformach 1C:Enterprise 7.7 i 1C:Enterprise 8.0. Ze względu na specyfikę działania platformy 1C:Enterprise 7.7 przygotowanie reguł wymiany danych za pomocą programów obsługi zdarzeń dla baz informacyjnych zaimplementowanych na tej platformie ma szereg funkcji.

W przypadku platformy 1C:Enterprise 7.7 nie jest możliwe wykonanie dowolnego kodu (analogicznie do funkcji Uruchom w wersji 8). Jeśli konieczne jest użycie programów obsługi zdarzeń dla platformy V7.7, konieczne jest zastąpienie tekstu przetwarzania przesyłania lub pobierania danych tekstami przetwarzania generowanymi przez konfigurację „Konwersja danych 2.0”.

Jeśli chcesz przesłać dane z V7.7 do V8, to:

Podczas rozładowywania, oprócz samego pliku reguł, system generuje tekst modułu do przetwarzania V77Exp.ert z funkcjami implementującymi obsługę zdarzeń. Następnie w konfiguratorze musimy wymienić standardowy moduł V77Exp.ert na nowy wygenerowany przez "Data Conversion 2.0".

Opracowując rozwiązania do wymiany danych na platformie 1C:Enterprise 7.7, musisz pamiętać o tym ważnym „drobiazgu”. Twoje reguły będą działać poprawnie tylko wtedy, gdy użyjesz zmodyfikowanego przetwarzania, którego tekst modułu został utworzony podczas rozładowywania reguł wymiany danych. Ta reguła ma jeden wyjątek — jeśli nie używasz obsługi zdarzeń, możesz użyć standardowego przetwarzania.

Z poważaniem, Władimir Milkin(nauczyciel i programista).