A vállalkozásom a franchise. Értékelések. Sikertörténetek. Ötletek. Munka és oktatás
Keresés az oldalon

1c vállalati 8 adatkonverzió. Mindig több megoldás létezik

Könyvek, füzetek, cikkek

1C:Enterprise 8. Adatkonverzió: adatcsere alkalmazási megoldások között (CD-ROM-on lévő alkalmazással) (4601546049094. cikk)

Az "1C:Enterprise" egy univerzális rendszer a vállalati tevékenységek automatizálására, és megoldható különféle feladatokat menedzsment és számvitel. Jelenleg számos szabványos és speciális megoldást fejlesztettek ki az 1C:Enterprise platformon, amelyek szorosan integrálhatók más megoldásokkal, mind ezen a platformon, mind szoftver harmadik fél gyártók.

Nagy érték Mert hatékony munkavégzés képes megszervezni a különböző információs rendszerek közötti cserét. Az 1C:Enterprise platform számos eszközt biztosít az adatcseréhez és az alkalmazási megoldások integrációjához.

A könyv részletesen vizsgálja az XML formátumú adatcserét, amely ma az adatok bemutatásának általánosan elfogadott eszköze. Leírják a szabályok kidolgozásának eljárásait, amelyek alkalmazása biztosítja az információ átadását egytől információs rendszer egy másikra, beleértve a szabványos 1C:Enterprise konfigurációk közötti adatcserét.

A könyvhöz tartozik egy CD, amely demo információs bázisokat tartalmaz példákkal a csereszabályokra és az „1C:Enterprise Data Conversion” konfigurációra.

Figyelem! Az első nyomtatásnál műszaki hiba volt a könyv végén. A javított oldalak lehetnek

Jelenleg a hiba maradványait kivonták az értékesítésből, és megjelent a javított kiadás.
Elnézést kérünk a kellemetlenségért, és készek vagyunk a hibás tételek ingyenes cseréjére.


Az "1C-Publishing" kiadó irodalmával kapcsolatos kérdéseket a következő címre lehet küldeni: [e-mail védett].

Vétel:

Lépjen kapcsolatba a szervezetét kiszolgáló 1C partnerrel, és rendeljen, és adja meg neki a könyvhöz rendelt kódot (az alábbi táblázatban látható). A könyvet másoktól is megvásárolhatja az "1C" cég partnerei.

  • az "1C-Interest" online áruházban (könyvek kiszállítása futárral, orosz posta, DHL, EMS)
  • V könyvesboltok a városod

Lásd még:

Könyv költsége

Kód Név Ajánlott kiskereskedelmi ár, dörzsölje. * Kereskedő Állandó partner Elosztó
4601546049094 1C:Enterprise 8. Adatkonverzió: adatcsere alkalmazási megoldások között (CD-ROM-on lévő alkalmazással) (4601546049094. cikk) 240 150 135 120

A könyv szerkezete

Bevezetés

1. fejezet A szabályok felállításának általános elvei

2. fejezet: Szabályok használata

3. fejezet Szabályok automatikus létrehozása

4. fejezet Szabálystruktúra

5. fejezet A szabályok részletes tanulmányozása

6. fejezet Eseménykezelők

  • Opciók
  • „Konverziós” kezelők
  • Kezelők "Adatfeltöltési szabályok"
  • Kezelők "Objektumkonverziós szabályok"
  • Kezelők "Tulajdoncsoport-konverziós szabályok"
  • Kezelők "Tulajdonátalakítási szabályok"

7. fejezet Keresési mezők

8. fejezet Adattisztítási szabályok

9. fejezet Algoritmusok és lekérdezések

10. fejezet Tipikus példák a szabályokra. Hibaelhárítás

  • Átutalás konvertálása
  • Könyvtárak konvertálása
  • Dokumentumok konvertálása
  • Információs regiszterek konvertálása
  • Számladiagram átalakítása
  • Jellegzetes típusterv átalakítása
  • Számítási típusok tervének konvertálása
  • Konstansok átalakítása 1C:Enterprise 7.7
  • Számviteli tranzakció átalakítása 1C:Vállalkozás 7.7

11. fejezet Szabályok optimalizálása

  • Adatfeltöltési szabályok
  • Objektumkonverziós szabályok
  • Univerzális XML adatcsere feldolgozás

1. Bevezetés.

2. Amire szüksége lesz: 1C konfiguráció: Adatkonverzió 2.* és feldolgozás a csomagból. A példafeladatokhoz vegyük az 1C: Trade Management 11 és 1C: BP 3.* konfigurációkat.

Tehát az adatok 1C-be való feltöltésére vonatkozó szabályok kidolgozásához szüksége lesz az 1C konfigurációra: Object Conversion 2, valamint a csomagban található feldolgozásra.

Például már telepítettünk egy konverziós adatbázist és elindítottuk azt.

Megírjuk az 1C: Trade Management 11 és az 1C: Enterprise Accounting 3 konfiguráció közötti csereszabályok fejlesztését (UT / ACCOUNT csereszabályok).

3. Feldolgozásra lesz szükségünk a metaadat-struktúra eltávolításához és a cseréhez.

Az első dolog, amit a fejlesztéshez be kell szereznie, a metaadat-struktúrájú fájlok. Ez az objektumkonverziós csomagban található metaadat-struktúra eltávolítására szolgáló feldolgozás segítségével történik.

Valójában a kicsomagolt konfigurációs könyvtárban a bekapcsolt konfigurációkhoz ellenőrzött formák az MD83Exp.epf feldolgozása iránt érdeklődünk. Ha fel kell töltenie a konfigurációkból ide szokásos formák, akkor az MD82Exp.epf feldolgozást használják. Ez akkor van így, ha például struktúrát kell beszereznie olyan konfigurációkból, mint az 1C: UT 10, 1C: Management gyártó vállalkozás 1.3, 1C: Átfogó automatizálás 1.1, 1C: Zup 2.5 és így tovább.

Továbbá az adatok 1C-be való feltöltéséhez és letöltéséhez a szabályaink szerint fel kell dolgoznia az „Univerzális adatcsere XML formátumban” V8Exchan83.epf fájlt a felügyelt űrlapokon, például 1C: Trade Management 11.*, 1C BP 3, 1C: ERP 2. * és hasonlók. És ennek megfelelően V8Exchan83.epf - a szokásos űrlapokon történő konfigurációkhoz.

4. Az 1C: Trade Management 11.3 és 1C: Enterprise Accounting 3.0.* konfiguráció metaadat-struktúrájának feltöltése

Kezdjük a metaadat-struktúra letöltésével az 1C: Enterprise Accounting 3 konfigurációból.
Nyissuk meg az MD83Exp.epf feldolgozást

A feldolgozási űrlapon további beállítások találhatók, ahol engedélyezhetjük vagy letilthatjuk a regiszterek és mozgások 1C-be való feltöltésének lehetőségét. Választható az is, hogy a feltöltés hol történjen: az 1C szerveren vagy a „kliensen”. Adja meg annak a fájlnak a nevét, ahová az adatszerkezetet feltölti. Hasonló módon ürítjük ki a Trade Management 11 konfiguráció metaadat-struktúráját.

Most fel kell töltenie a konfigurációt a konverziós adatbázisba. Ez a pont a konfigurációk listájából és az átalakítások listájából egyaránt elérhető. Indítsuk csak az asztalról:

A párbeszédpanelen töltse be a BP szerkezetét:

És hasonlóan - a Trade Management szerkezete.

A letöltés befejezése után megjelenik egy párbeszédpanel, ahol megadhatja az Önnek megfelelő nevet.

6. Konverziós szabályok létrehozása az 1C on-ban konkrét példa feladatokat.

Ezután lépjen az „Objektumszabályok beállítása” részre, ahol létrehozunk egy új beállítást.
A konverzió létrehozása párbeszédpanelen válassza ki a „forrás” konfigurációt és a „cél” konfigurációt (amelyet korábban betöltött), majd kattintson az OK gombra.

Mivel ebben a cikkben azt terveztem, hogy a teremtést „a semmiből” és „szemét nélkül” mutatom be, emlékeztetem, hogy semmit sem hozunk létre automatikusan. Nincsenek prototípusok.

Ezen a párbeszédpanelen nem teszünk semmit, csak kattintson a „Bezárás” gombra.

Hozzunk létre szabályokat arra, hogy ne egy dokumentumot töltsünk fel az egyikbe, hanem egy típust a másikba, például az Áruk és szolgáltatások értékesítése az UT 11-ből dokumentumot a szükséges referenciakönyvekkel a BP 3 Áruk és szolgáltatások átvétele dokumentumba.

Tehát létrehozunk egy új PKO-t (az objektumok konvertálására vonatkozó szabályt az 1C-ben)

Válassza ki az Áruk és Szolgáltatások értékesítésének forrását és a céláru- és szolgáltatásátvételt, majd kattintson az OK gombra.
Ebben az esetben megjelenik egy párbeszédpanel, ahol ismét megtagadjuk a PKS (Property Conversion Rules) automatikus létrehozását. Ezután csak a szükségeseket választjuk ki.

De a DVP (adatfeltöltési szabályok) létrehozására vonatkozó javaslatra „Igen” választ adunk.

Létrejönnek a PVD-k, amelyek tükröződni fognak az univerzális XML-csere feldolgozásában a kiválasztáshoz:

Az üres tulajdonságkonverziós szabályokkal rendelkező adatátalakítási szabályok is létrejönnek.

Sőt, az is látható, hogy alapértelmezés szerint a szoftver a belső objektumazonosító alapján keresendő. Ezt a PCO melletti nagyító jelzi. A keresést saját kezűleg végezzük, a nap eleji dokumentumszám és dátum alapján.

Eltávolítjuk az UIO általi keresést:

Most kezdjük el az objektum szükséges tulajdonságainak (részleteinek) összehasonlítását. Ehhez kattintson a „Tulajdonságok szinkronizálása” gombra (az „1” címke a képernyőn). Eltávolítjuk a szabályok rekurzív létrehozását („2”). Távolítsa el az összes megjelölt részletet ("3"). És mi magunk választjuk ki, mire van szükségünk.

Például válassza ki, amire szüksége van:

Felhívom a figyelmet arra, hogy a partner PKS-jét a szervezetté, a szervezetét pedig partnerré alakítjuk, valamint összehasonlítunk néhány név szerint nem egyező adatot, például „Pénznem” és „Dokumentum” Valuta".

Ahol azt látjuk, hogy még nincsenek konverziós szabályok.

Kezdjük átmenni a részleteken és leírni őket. Először beállítunk egy dokumentumkeresést, ahogy korábban írtam, feltöltünk és a dátum elején keresünk egy dokumentumot, és megváltoztatjuk a számozást. Az első három karaktert az „UTB” előtagunkra cseréljük. És mivel a számozás BP-ben és UT-ban egyenként 11 karakterből áll, egy összetett számot készítünk: az előtagunk és a forrásból származó 8 karakter. Példa az alábbi képernyőképen.

A dokumentumokat mindig kirakodva, mozgás nélkül töltjük fel. Feltételezzük, hogy a dokumentumokat a felhasználó ellenőrzése után dolgozzák fel a fogadóban.

Ehhez a PKS-t nem végrehajtottként 0 vagy 1 értékre állítva logikai értékként használjuk.

Példaként a pénznemet használva létrehozunk egy objektumkonverziós szabályt a PKS-hez. Ugyanakkor úgy gondoljuk, hogy mindkét adatbázisban vannak pénznemek, amelyeket kóddal kell szinkronizálni. Ezért nem hozunk létre minden PKS-t a valuta PQS-ben, hanem csak egy keresési kódot adunk hozzá. Azok. Elutasítjuk a PKS létrehozására vonatkozó ajánlatot az objektumhoz.

A létrehozott konverziós szabályt behelyettesítettük a PKS dokumentum PQR-jébe. Magát az alapértelmezett szabályt pedig egy egyedi azonosító kínálja fel. Javítjuk, megkeressük a kódot és beállítjuk a tulajdonságot, hogy ne hozzunk létre új objektumot.

Ennek eredményeként a következő lehetőséget kapjuk:

Ezután analógia útján létrehozzuk a PKO-t és a PKS-t a fennmaradó részletekhez. Ezen túlmenően partnerek alapján keresünk szervezetet, TIN-szám alapján pedig fordítva. Körülbelül így néz ki minimális részletekkel (szükség esetén kiegészítheted).

A PCO partnerszerződések esetében a PKS szerződő fél, név és tulajdonos szerint keresünk.

Nézzük meg, hogyan adjuk meg a szükséges értéket a felsorolás típusában a PKS-ben. Például a „Művelet típusa” attribútum. Itt különféle feltételeket és helyettesítő értékeket használhat. Például szükségünk van a „művelet típusára”, hogy mindig „Áru” legyen kirakva, ebben az esetben elegendő a „homlok” sorba beírni a kívánt értéket.

Az alábbiakban bemutatjuk, hogyan telepíthető nehézségek nélkül, és a legtöbb esetben PCS a kölcsönös elszámolási többszörös, kölcsönös elszámolási ráta, könyvelési számla érdekében.

A PKO Nomenklatura esetében meghagyjuk a belső egyedi azonosító alapján történő keresést. De hadd hívjam fel a figyelmét arra, hogyan határozhatja meg újra a csoportját. Például beleegyezünk abba, hogy az 1C: Trade Management 11 konfigurációból egy új cikk kerül kirakásra, de szükséges, hogy a tételt a bizonyos csoport"Csoportunk".

A feladat végrehajtásához létrehozunk egy másik PKO-t. Nevezzük „NomenclatureParent”-nek, amelyet a szülő PCS-jében fogunk jelezni a konverziós szabályban.

Két keresést állítottunk be: név szerint, ahol szigorúan feltüntetjük a csoportunk nevét, és az „Ez egy csoport” attribútum kötelező tulajdonsága igaz.

Mivel úgy döntöttünk, hogy minden tételünk a mi csoportunkba tartozik, kirakáskor nem kell csoportokat kirakni az UT 11-ből. Ehhez a Nomenclature szoftverben a „Kirakás előtt” eseménykezelőben beállítunk egy szűrőt, amelyre. nem kell törölnie a csoportokat "Failure = Source;".

A termékek és szolgáltatások értékesítésére vonatkozó DRP-ben (adatfeltöltési szabályok) egy szűrőt adunk hozzá, hogy a törlésre jelölt dokumentumok ne kerüljenek feltöltésre. Ehhez a VDP-ben a „Before Unloading” eseménykezelőkbe írjuk a „Failure = Object.DeletionMark;” szűrőt.


Mentsük el a kidolgozott szabályokat egy fájlba.


7. Összefoglalva: Adatok fel- és betöltése kidolgozott adatcsere-szabályok segítségével.

Nyissa meg az 1C: Trade Management 11 alkalmazásban a V8Exchan83.epf „Univerzális adatcsere XML formátumban” feldolgozást.

A kirakodás befejeződött, most ugyanezt a feldolgozást alkalmazzuk az 1C: Enterprise Accounting 3-ba való betöltéshez.


Betöltés befejeződött. Nézzük, hogyan töltődött be. Tehát a dokumentum betöltődik, ahogy akartuk - a Szervezetünk betöltődik a partnerbe, a partner pedig a szervezetbe. A könyvelési fiókok mindegyike letöltődik és telepítve van. A dokumentumszámot az előtagunkkal és a nap elején kaptuk. Minden megadott adatot kitöltöttek.

Ellenőrizzük az áruk berakodását. Úgy látjuk, minden úgy alakult, ahogy terveztük.


A részleteket szándékunk szerint hoztuk létre és töltöttük ki. Az átalakításnak számos finomsága van, és néhány egyszerű, de szükséges dolog, amelyek segítenek az átalakítás pontos megírásában. Ez pedig lehetővé teszi a hibák minimalizálását, nem rontja el a meglévő adatokat, és megszabadul a felesleges szeméttől. Ez az egyik legtöbb egyszerű példák. Egy objektumot sokré alakíthat át, vagy fordítva, sokat egyé.

Most van adatkonverzió 3, ez megold más problémákat. Ezért a 2. konverzióra is szükség van. Sok sikert mindenkinek a tanuláshoz és a tanuláshoz.

Természetesen, ha programozó vagy, és ez a fő munkád, megpróbálhatod magad megírni az átalakítást. De ha nem, akkor érdemes megbecsülni a tevékenységi területén eltöltött időt, és szakembert kérni a feladat elvégzésére.

Az adatok migrálása a különböző konfigurációk között nem triviális feladat. Mint mindig, most is több megoldás létezik, de nem mindegyik optimális. Próbáljuk megérteni az adatátvitel árnyalatait, és válasszunk egy univerzális stratégiát az ilyen problémák megoldására.

Az egyik megoldásról a másikra való adatmigráció (pusztán az 1C cég termékeiről beszélünk) tegnap fel sem merült. Az 1C cég tökéletesen tisztában van azzal, hogy a fejlesztők milyen nehézségekkel szembesülnek a migráció létrehozásakor, ezért minden lehetséges módon igyekszik segíteni az eszközökkel.

A platform fejlesztése során a cég számos univerzális eszközt, valamint adatátvitelt egyszerűsítő technológiát vezetett be. Mindenbe be vannak építve standard megoldásokés az azonos konfigurációk közötti migráció problémája általában megoldódott. A győzelmet ismét megerősíti a szabványos megoldások szoros integrációja.

A nem szabványos megoldások közötti migrációval a helyzet némileg bonyolultabb. A technológiák széles választéka lehetővé teszi a fejlesztők számára, hogy önállóan válasszák ki a probléma megoldásának optimális módját saját szemszögükből.

Nézzünk ezek közül néhányat:

  • csere szöveges fájlokon keresztül;
  • cseretervek használata;
  • stb.

Mindegyiknek megvannak a maga előnyei és hátrányai. Összefoglalva, a fő hátrány a szóbeliség lesz. A migrációs algoritmusok független megvalósítása jelentős időköltséggel, valamint hosszú hibakeresési folyamattal jár. Az ilyen döntések további támogatásáról nem is akarok beszélni.

A támogatás összetettsége és magas költsége késztette az 1C céget a létrehozásra univerzális megoldás. Technológiák, amelyek lehetővé teszik a migráció fejlesztésének és támogatásának lehetőség szerinti egyszerűsítését. Ennek eredményeként az ötlet egy külön konfiguráció – „Adatkonverzió” – formájában valósult meg.

Adatkonverzió - standard megoldás, független konfiguráció. Bármely „ITS:Prof” előfizetéssel rendelkező felhasználó teljesen ingyenesen letöltheti ezt a csomagot a felhasználói támogatási webhelyről vagy az ITS lemezről. Telepítés folyamatban szabványos módon- mint minden más standard megoldás az 1C-től.

Most egy kicsit a megoldás előnyeiről. Kezdjük a legfontosabb dologgal - a sokoldalúsággal. A megoldás nem szabott platformkonfigurációkhoz/verziókhoz igazodik. Egyformán jól működik szabványos és egyedi konfigurációkkal is. A fejlesztők univerzális technológiával és szabványosított megközelítéssel rendelkeznek az új migráció létrehozásához. A megoldás sokoldalúsága lehetővé teszi, hogy még az 1C:Enterprise-től eltérő platformokra is készítsen migrációt.

A második nagy plusz a szemléltetőeszközök. Az egyszerű migrálások programozás nélkül jönnek létre. Igen, igen, egyetlen kódsor nélkül! Már csak ezért is érdemes időt szánni a technológia egyszeri elsajátítására, majd a felbecsülhetetlen értékű képességek többszöri felhasználására.

A harmadik előny, amit megjegyeznék, az adatterjesztésre vonatkozó korlátozások hiánya. A fejlesztő maga választja ki az adatok vevő konfigurációba való eljuttatásának módját. Két lehetőség közül választhat: feltöltés xml fájlba és közvetlen kapcsolat információs bázissal (COM/OLE).

Építészetet tanulni

Azt már tudjuk, hogy az adatkonverzió csodákra képes, de még nem teljesen világos, mit jelentenek technikai előnyök. Az első dolog, amit meg kell értenie, hogy minden adatmigráció (konverzió) csereszabályokon alapul. Az Exchange-szabályok egy szokásos xml-fájl, amely leírja azt a struktúrát, amelybe az információbiztonságból származó adatok feltöltésre kerülnek. Az adatokat feltöltő/letöltő szolgáltatás feldolgozás elemzi a csereszabályokat és azok alapján végzi el a feltöltést. A betöltés során fordított folyamat megy végbe.

A „CD” konfiguráció egyfajta vizuális konstruktor, melynek segítségével a fejlesztő csereszabályokat hoz létre. Nem tudja, hogyan töltsön le adatokat. A CD-terjesztési csomagban található további külső szolgáltatási feldolgozás felelős ezért. Több is van belőlük (a fájlnévben szereplő XX a platform verziószáma):

  • MDXXExp.epf- a feldolgozás lehetővé teszi a struktúra leírásának letöltését információs bázis xml fájlban. A struktúra leírása betöltődik a CD-re további elemzéshez és csereszabályok létrehozásához.
  • V8ExchanXX.epf- az információs bázisból adatokat tölt fel/letölt a csereszabályoknak megfelelően. A legtöbb tipikus konfigurációban a feldolgozás készen áll (lásd a „Szerviz” menüpontot). A feldolgozás univerzális, és nem kötődik semmilyen konkrét konfigurációhoz/szabályhoz.

Rendben, most a fentiek alapján határozzuk meg egy új konverzió fejlesztésének szakaszait:

  1. A feladat meghatározása. Világosan meg kell érteni, hogy milyen adatokat kell átvinni (mely konfigurációs objektumokból), és ami a legfontosabb, hova kell azokat átvinni.
  2. Konfigurációs struktúrák (Source/Sink) leírásának elkészítése a későbbi CD-re való betöltéshez. A problémát az MDXXExp.epf szolgáltatás feldolgozása oldja meg.
  3. Elkészített szerkezeti leírások betöltése az információbiztonságba.
  4. Csereszabályok létrehozása vizuális CD-eszköz segítségével.
  5. Fel-/letöltés végrehajtása a létrehozott adatkonverziós szabályok szerint V8ExchanXX.epf feldolgozás segítségével.
  6. A csereszabályok hibakeresése (ha szükséges).

A legegyszerűbb átalakítás

A bemutatóhoz két telepített konfigurációra lesz szükségünk. Úgy döntöttem, hogy a következő opciót választom: „Trade Management” 10. kiadás és egy kis házilag írt megoldás. A feladat az adatok átvitele lesz a szabványos „UT” konfigurációból. A tömörség kedvéért nevezzük a saját megírású megoldást „Sink”, a kereskedelmi menedzsmentet pedig „Forrásnak”. Kezdjük a probléma megoldásával elemek átvitelével a „Nómenklatúra” könyvtárból.

Először is vessünk egy pillantást az adatkonverziós sémára, és olvassuk el újra az elvégzendő műveletek listáját. Ezután elindítjuk a „Source” konfigurációt, és megnyitjuk benne az MD82Exp.epf szolgáltatás feldolgozását.

A feldolgozó felületen nincs sok beállítás. A felhasználónak csak a metaadat-objektumok típusait kell megadnia, amelyek nem fognak szerepelni a struktúra leírásában. A legtöbb esetben ezeket a beállításokat nem kell módosítani, mert Nincs különösebb értelme a mozgások kirakodásának halmozási regiszterekkel (példaként).

Helyesebb a mozgást úgy kialakítani, hogy közben dokumentumokat tartunk a vevőben. Minden mozgást maga a dokumentum hajt végre az átvitel után. A második érv az alapértelmezett beállítások mellett a fájlméret csökkentése a feltöltéssel.

Egyes dokumentumok (különösen a szabványos konfigurációkban) több regiszteren keresztül generálnak mozgásokat. Mindezen cuccok kiürítése túl nagy lesz az eredményül kapott XML-fájl. Ez megnehezítheti a későbbi szállítást és a vevőaljzatba való berakodást. Minél nagyobb az adatfájl, annál több RAM-ra lesz szükség a feldolgozásához. A gyakorlatom során alkalmam volt találkozni illetlenül nagy feltöltő fájlokkal. Az ilyen fájlok teljesen megtagadták a szabványos eszközökkel történő elemzést.

Tehát hagyjuk az összes alapértelmezett beállítást, és feltöltjük a konfiguráció leírását egy fájlba. Hasonló eljárást megismételünk a második alapnál is.

Nyissa meg a CD-t, és válassza ki a főmenüben "Könyvtárak" -> "Konfigurációk". A címtár az összes konfiguráció struktúrájának leírását tárolja, amely konverziók létrehozásához használható. A konfiguráció leírását egyszer töltjük be, majd többször is felhasználhatjuk különböző konverziók létrehozására.

A könyvtárablakban kattintson a „ Hozzáadás” és a megjelenő ablakban válassza ki a konfigurációt leíró fájlt. Jelölje be a „Betöltés új konfigurációba” jelölőnégyzetet, és kattintson a „Betöltés” ​​gombra. Hasonló műveleteket hajtunk végre a második konfiguráció felépítésének leírásával.

Most készen áll a csereszabályok létrehozására. A CD főmenüjében válassza a „Könyvtárak” -> „Konverziók” menüpontot. Hozzáadás új elem. Az új konverzió létrehozására szolgáló ablakban meg kell adnia: a forráskonfigurációt (válassza ki az UT-t) és a célkonfigurációt (válassza a „Vevő”). Ezután nyissa meg a „Speciális” lapot, és töltse ki a következő mezőket:

  • Exchange szabályok fájlnév - a létrehozott csereszabályok ezen a néven lesznek elmentve. A fájlnevet bármikor megváltoztathatja, de a legjobb, ha most beállítja. Ezzel időt takaríthat meg a jövőben. A demópélda szabályait elneveztem: „rules-ut-to-priemnik.xml”.
  • name - az átalakítás neve. A név teljesen bármi lehet, én a „Demo. UT a vevőhöz.”

Ez az, kattintson az „OK” gombra. Azonnal megjelenik előttünk egy ablak, amelyben az összes szabály automatikus létrehozását kéri. Egy ilyen csábító ajánlat elfogadása parancsot ad a mesternek, hogy automatikusan elemezze a kiválasztott konfigurációk leírását, és önállóan generálja a csereszabályokat.

Pontosítsuk azonnal az „i”-t. A varázsló nem tud semmi komolyat generálni. Ezt a lehetőséget azonban nem szabad figyelmen kívül hagyni. Ha szükség van az azonos konfigurációk közötti cserére, akkor a szakember szolgáltatásai nagyon hasznosak lesznek. Példánkban előnyösebb a kézi üzemmód.

Nézzük meg közelebbről az „Exchange Rules Settings” ablakot. A kezelőfelület kissé zavarónak tűnhet – sok lap van tele vezérlőkkel. Valójában minden nem olyan nehéz, hogy néhány órányi munka után kezdi megszokni ezt az őrületet.

Ebben a szakaszban két lapra vagyunk kíváncsiak: „Objektumkonverziós szabályok” és „Adatfeltöltési szabályok”. Először konfigurálnunk kell az illesztési szabályokat, pl. Hasonlítsa össze két konfiguráció objektumát. A második lépésben határozza meg a lehetséges objektumokat, amelyek elérhetők lesznek a felhasználó számára a feltöltéshez.

Az „Objektumkonverziós szabályok” lap második felében van egy további panel két lappal: „Tulajdonkonverzió” és „ Értékek konvertálása" Az első kiválasztja a kiválasztott objektum tulajdonságait (részleteit), a második pedig az előre meghatározott értékekkel (például előre meghatározott könyvtárelemekkel vagy felsorolási elemekkel) való munkához szükséges.

Remek, most hozzunk létre konverziós szabályokat a könyvtárakhoz. Ezt a műveletet kétféleképpen hajthatja végre: használja az Objektumszinkronizálás varázslót (a „” gomb), vagy manuálisan adja hozzá az egyes objektumokhoz a megfelelőséget.

A helytakarékosság érdekében az első lehetőséget használjuk. A varázsló ablakában törölje a jelet a csoport „ Dokumentumok” (minket csak a címtárak érdekelnek), és bővítsük ki a csoportot Könyvtárak" Gondosan görgetjük a listát, és megnézzük az összehasonlítható kézikönyvek nevét.

Az én esetemben három ilyen címtár van: Nómenklatúra, Szervezetek és Raktárak. Van egy Clients nevű könyvtár is, amely ugyanazt a célt szolgálja, mint a „ Ügyfelek"konfigurációból" UT" Igaz, a mester nem tudta összehasonlítani őket eltérő elnevezésük miatt.

Ezt a problémát mi magunk is meg tudjuk oldani. Az ablakban találjuk" Tárgyegyezések» referenciakönyv « Ügyfelek", és a "Forrás" oszlopban válassza ki a "Counterparties" könyvtárat. Ezután jelölje be a „Típus” oszlopban található négyzetet, és kattintson az „OK” gombra.

Az Objektumszinkronizálás varázsló felajánlja, hogy automatikusan létrehozza a szabályokat az összes kiválasztott objektum tulajdonságainak konvertálásához. Az ingatlanokat név szerint hasonlítjuk össze, és a demonstrációnkhoz ez bőven elég lesz, egyetértünk. A következő kérdés a kirakodási szabályok megalkotására irányuló javaslat lesz. egyezzünk bele mi is.

A csereszabályzat alapja készen áll. Kiválasztottuk a szinkronizáláshoz szükséges objektumokat, és automatikusan létrejöttek a tulajdonságok konvertálására és a feltöltési szabályokra vonatkozó szabályok. Mentsük el a csereszabályokat egy fájlba, majd nyissuk meg az IB „Source”-t (esetemben UT), és indítsuk el benne a szolgáltatásfeldolgozást. V8Exchan82.epf.

Először is a feldolgozó ablakban válassza ki az általunk létrehozott csereszabályokat. A betöltési szabályok kérdésére igennel válaszolunk. A feldolgozás elemzi a csereszabályokat, és létrehoz egy fát az azonos nevű, feltölthető objektumokból. Ehhez a fához mindenféle kijelölést beállíthatunk, vagy csomópontokat cserélhetünk, amelyek megváltoztatásával adatokat kell kiválasztanunk. Teljesen az összes adatot szeretnénk letölteni, így nincs szükség szűrők telepítésére.

Miután befejezte az adatok fájlba feltöltésének folyamatát, lépjen az IB " Vevő" A feldolgozást is megnyitjuk benne V8Exchan82.epf, ezúttal csak az „Adatbetöltés” ​​fülre lépünk. Válassza ki az adatfájlt, és kattintson a „Letöltés” ​​gombra. Ez az, az adatok átvitele sikeresen megtörtént.

A való világ problémái

Az első demó félrevezető lehet. Minden nagyon egyszerűnek és logikusnak tűnik. Valójában ez nem teljesen igaz. IN igazi munka Olyan problémák merülnek fel, amelyeket csak vizuális eszközökkel (programozás nélkül) nehéz vagy teljesen lehetetlen megoldani.

Annak érdekében, hogy ne csalódjak a technológiában, elkészítettem néhány valós problémát. Munka közben biztosan találkozni fogsz velük. Nem tűnnek olyan triviálisnak, és új szemszögből nézik az adatkonverziót. Gondosan fontolja meg a bemutatott példákat, és bátran használja azokat kivonatként valós problémák megoldása során.

1. számú feladat. Töltse ki a hiányzó adatokat

Tegyük fel, hogy át kell vinnünk a "" könyvtárat Ügyfelek" A vevőnek van egy hasonló „Clients” könyvtára erre a célra. Adattárolásra teljesen alkalmas, de vannak kellékei " Szervezet”, amely lehetővé teszi a partnerek elkülönítését a szervezethez való tartozás alapján. Alapértelmezés szerint minden partnernek az aktuális szervezethez kell tartoznia (ezt az azonos nevű konstansból kaphatjuk meg).

A problémára többféle megoldás is létezik. Megfontoljuk az adatok kitöltésének lehetőségét " Szervezet„közvetlenül az adatbázisban” Vevő”, azaz. az adatok betöltésekor. Az aktuális szervezet konstansban van tárolva, ezért ennek az értéknek a megszerzésének nincs akadálya. Nyissuk meg az objektumkonverziós szabályt (a továbbiakban: PKO) Ügyfelek” (kattintson duplán az objektumra), és a szabályok beállítási varázslójában lépjen az „Eseménykezelők” részre. A kezelők listájában azt találjuk, hogy Letöltés után”.

Leírjuk a kódot az aktuális szervezet megszerzéséhez, majd hozzárendeléséhez a részletekhez. Amikor a „Betöltés után” kezelő aktiválódik, az objektum teljesen formálódik, de még nem íródik be az adatbázisba. Senki sem tiltja meg, hogy saját belátásunk szerint változtassuk meg:

Ha NEM Object.ThisGroup Akkor Object.Organization = Constants.CurrentOrganization.Get(); endIf;

Mielőtt kitöltené az adatokat" Szervezet"Ellenőrizni kell az attribútum értékét" Ez egy csoport" A kézikönyvhöz " Ügyfelek"A hierarchikus jellemző be van állítva, ezért a csoport ellenőrzése szükséges. Hasonló módon töltsön ki minden adatot. Feltétlenül olvassa el a súgót a kezelő egyéb lehetőségeiről " AfterLoading" Például ezek között van a " Elutasítás" Ha „True” értéket ad hozzá, akkor az objektum nem kerül beírásra az adatbázisba. Így lehetővé válik a betöltéskor írható objektumok korlátozása.

2. feladat. Részletek az információs nyilvántartásban

A könyvtárban " Ügyfelek„UT konfigurációk, részletek elérhetők” Vevő"És" Szállító" Mindkét adat "típusú" Boolean” és a szerződő fél típusának meghatározására szolgálnak. Az IB-ben Vevő", a " könyvtárban Ügyfelek"Nincsenek hasonló adatok, de van információs nyilvántartás" Ügyfelek típusai" Hasonló funkciót lát el, és több attribútumot is képes tárolni egy klienshez. Feladatunk az adatok értékeinek külön bejegyzésekbe történő átvitele az információs nyilvántartásban.

Sajnos a vizuális eszközök önmagukban itt sem tudnak megbirkózni. Kezdjük kicsiben, hozzunk létre egy új szoftvert az információs nyilvántartáshoz” Ügyfelek típusai" Ne hivatkozz semmit forrásként. Kerülje a feltöltési szabályok automatikus létrehozását.

A következő lépés a feltöltési szabályok létrehozása. Lépjen a megfelelő fülre, és kattintson a „ Hozzáadás" A feltöltési szabályok hozzáadására szolgáló ablakban töltse ki:

  • Mintavételi módszer. Váltás „Önkényes algoritmus”-ra;
  • Konverziós szabály. Válassza ki az „Ügyfelek típusai” információs nyilvántartást;
  • A szabály kódja (név). Írja le „Ügyféltípusok kiürítése” címmel;

Most kódot kell írnia a feltöltéshez szükséges adatok kiválasztásához. A paraméter " Adatmintavétel" Elhelyezhetünk egy gyűjteményt, benne előkészített adatsorral. Paraméter " Adatmintavétel” különféle értékeket vehet fel - lekérdezés eredménye, kijelölés, értékgyűjtemények stb. Értéktáblázatként inicializáljuk, két oszloppal: kliens és ügyféltípus.

Az alábbiakban található az eseménykezelő kódja " Feldolgozás előtt" Inicializálja a "paramétert" Adatmintavétel", majd az adatok kitöltése a könyvtárból" Ügyfelek" Itt érdemes figyelni a „ oszlop kitöltésére Ügyfél típusa" Az „UT”-ban attribútumaink „boolean” típusúak, a címzett pedig egy felsorolás.

Ebben a szakaszban nem tudjuk elvezetni őket a megfelelő típus(nincs az UT-ban), ezért egyelőre hagyjuk karakterláncok formájában. Ezt nem kell megtenned, de azonnal meg akarom mutatni, hogyan kell a forrásban hiányzó típusra leadni.

DataFetch = Új értéktábla(); DataSelection.Columns.Add("Kliens"); DataSelection.Columns.Add("ClientType"); SelectingDataFromDirectory = Könyvtárak.Accounts.Select(); Míg SelectingDataFromDirectory.Next() Loop If SelectingDataFromDirectory.ThisGroup then Continue;

endIf; Ha Data Selection From Directory.Buyer Then NewRow = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; Ügyfelek típusai NewRow.ClientType = "Ügyfél";

endIf;

Ha DataFetchFromDirectory.Supplier akkor NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Beszállító";

endIf; EndCycle;

Mentsük el az adatfeltöltési szabályt, és térjünk vissza a „ fülre

Objektumkonverziós szabályok " Tegyük hozzá az információs nyilvántartáshoz „ megint nem lehet megoldani a problémát. Itt célszerű a második probléma megoldását alapul venni.

Szabályt készítünk az adatok kirakására, megadunk egy tetszőleges algoritmust, és a „Kirakás előtt” kezelőben írunk egy kérést a táblázatos részből történő adatgyűjtésre.

Helytakarékosság érdekében nem adom meg a kérés kódját (mindig hivatkozhat a forrásokra) - nincs benne semmi szokatlan. A kapott kijelölést átválogatjuk, és a rendezett eredményeket a már ismert paraméterbe helyezzük. Adatmintavétel" Ismét kényelmes értéktáblázatot használni gyűjteményként:

DataFetch = Új értéktábla(); //Itt lesz még egy táblázat rész Data Selection.Columns.Add(“Termékek”); //Itt lesz egy táblázatos rész is Data Selection.Columns.Add(“Szolgáltatások”); SelectionData.Columns.Add(“Link”);

4. feladat. Adatok átvitele műveletbe

Ha egy szervezet több számviteli rendszert használ, akkor előbb-utóbb szükség lesz az adatok migrálására a tranzakciók következő generálásakor.

A konfigurációban " BP"van egy univerzális dokumentum" Művelet” és ideális több vezeték kialakításához. Csak egy probléma van: a dokumentumot ravaszul készítik, és az adatokat nem lehet olyan könnyen átvinni bele.

Ilyen átalakításra talál példát a cikk forráskódjában. A kód mennyisége elég nagynak bizonyult, így nincs értelme a cikkel együtt közzétenni. Csak annyit mondok, hogy az ismételt feltöltés egy tetszőleges algoritmust használ az adatok feltöltésének szabályaiban.

5. feladat. Adatszinkronizálás több részlet között

Már több példát is megvizsgáltunk, de még mindig nem beszéltünk az objektumok migráció közbeni szinkronizálásáról. Képzeljük el, hogy partnereket kell átadnunk, és néhányuk valószínűleg a fogadó adatbázisban van. Hogyan lehet adatokat átvinni és megakadályozni a duplikációk megjelenését? Ebben a tekintetben a CD számos módot kínál az átvitt objektumok szinkronizálására.

Az első egyedi azonosító alapján történik. Sok objektum egyedi azonosítóval rendelkezik, amely garantálja a táblán belüli egyediséget. Például a " könyvtárban Ügyfelek” nem lehet két azonos azonosítójú elem. A CD erre és az összes létrehozott PCO-ra számításokat végez, az azonosító alapján történő keresés alapértelmezés szerint azonnal bekapcsol. A PCO létrehozásakor észre kellett volna venni a nagyító képét az objektum neve mellett.

Az egyedi azonosítóval történő szinkronizálás megbízható módszer, de nem mindig megfelelő. Könyvtárak egyesítésekor " Ügyfelek”(többből különböző rendszerek) nem sokat fog segíteni.

Ilyenkor helyesebb az objektumok több szempont szerinti szinkronizálása. Helyesebb a partnerek keresése INN, KPP, név alapján, vagy a keresést több szakaszra bontva.

Az adatkonverzió nem korlátozza a fejlesztőt a keresési feltételek meghatározásában. Nézzünk egy absztrakt példát. Tegyük fel, hogy szinkronizálnunk kell a könyvtárakat " Ügyfelek” különböző információs bázisokból. Készítsük elő a szoftvert, és az objektumkonverziós szabályok beállításainál ellenőrizze a „ Folytassa a keresést a keresési mezőkben, ha a vevő objektum nem található azonosító alapján" Ezzel a művelettel azonnal meghatároztunk két keresési feltételt – egyedi azonosító és egyéni mezők alapján.

Jogunk van a mezőket magunk választani. A TIN, KPP és Name bejelölésével azonnal több keresési feltételt is jelezünk. Kényelmes? Igen, de ez megint nem elég. Mi van, ha meg akarjuk változtatni a keresési feltételeket? Például először keressük meg a TIN+KPP kombinációt, és ha nem találunk semmit, akkor elkezdünk szerencsét próbálni a névvel.

Egy ilyen algoritmus teljesen megvalósítható. Az eseménykezelőben " Keresési mezők” akár 10 keresési feltételt is megadhatunk, és mindegyikhez meghatározhatjuk a saját keresési mezők összetételét:

Ha SearchOptionNumber = 1, akkor SearchPropertyNameString = „TIN, KPP”; OtherIfSearchOptionNumber = 2 ThenSearchPropertyNameString = "Név"; endIf;

Mindig több megoldás létezik

Minden feladatnak több megoldása van, és ez alól a különböző konfigurációk közötti adatátvitel sem kivétel. Minden fejlesztőnek joga van saját megoldást választani, de ha folyamatosan összetett adatmigrációkat kell fejlesztenie, akkor erősen javaslom, hogy figyeljen a „””-ra. Lehet, hogy eleinte erőforrásokat (időt) kell befektetnie a képzésbe, de az már az első komolyabb projektnél megtérül.

Véleményem szerint az 1C cég méltánytalanul figyelmen kívül hagyja az adatkonverzió használatának témáját. A technológia teljes fennállása alatt egyetlen könyv jelent meg róla: „1C: Enterprise 8. Adatkonverzió: adatcsere az alkalmazásmegoldások között.” A könyv meglehetősen régi (2008), de még mindig tanácsos megismerkedni vele.

A platformok ismerete továbbra is szükséges

"egy univerzális eszköz, de ha azt tervezi, hogy az 1C:Enterprise 7.7 platformra fejlesztett konfigurációkból adatmigrációt szeretne létrehozni, akkor időt kell szánnia a beépített nyelv megismerésére. A nyelv szintaxisa és ideológiája nagyon eltérő, ezért időt kell fordítania a tanulásra. Ellenkező esetben az elv ugyanaz marad.

"1C: Vállalati"egy univerzális rendszer a vállalati tevékenységek automatizálására, és különféle irányítási és számviteli problémák megoldására használható. Jelenleg nagyszámú szabványos és speciális megoldást fejlesztettek ki a platformon" 1C: Vállalkozások", amely szorosan együttműködhet más megoldásokkal, mind ezen a platformon, mind harmadik féltől származó szoftverekkel.

A hatékony munkavégzés szempontjából nagy jelentősége van a különféle információs rendszerek közötti csere megszervezésének képességének. platform" 1C: Vállalati" számos eszközt biztosít az adatcseréhez és az alkalmazási megoldások integrációjához.

A könyv részletesen vizsgálja az XML formátumú adatcserét, amely ma az adatok bemutatásának általánosan elfogadott eszköze. Leírják a szabályok kidolgozásának eljárásait, amelyek alkalmazása biztosítja az információ átvitelét egyik információs rendszerből a másikba, beleértve a szabványos konfigurációk közötti adatcserét is. 1C: Vállalkozások".

A könyvhöz egy CD is tartozik, amely demo információs bázisokat tartalmaz példákkal a csereszabályokra és konfigurációkra. 1C: Vállalati. Adatkonverzió".

A könyv szerkezete

Bevezetés

1. fejezet Általános elvek szabályok beállításait

2. fejezet Szabályok használata

3. fejezet. Szabályok automatikus létrehozása

4. fejezet. Szabályszerkezet

5. fejezet. A szabályok részletes tanulmányozása

6. fejezet. Rendezvénykezelők

  • Opciók
  • „Konverziós” kezelők
  • Kezelők "Adatfeltöltési szabályok"
  • Kezelők "Objektumkonverziós szabályok"
  • Kezelők "Tulajdoncsoport-konverziós szabályok"
  • Kezelők "Tulajdonátalakítási szabályok"

7. fejezet. Keresési mezők

8. fejezet. Adattisztítási szabályok

9. fejezet Algoritmusok és lekérdezések

10. fejezet. Tipikus példák szabályokat Hibaelhárítás

  • Átutalás konvertálása
  • Könyvtárak konvertálása
  • Dokumentumok konvertálása
  • Információs regiszterek konvertálása
  • Számladiagram átalakítása
  • Jellegzetes típusterv átalakítása
  • Számítási típusok tervének konvertálása
  • Konstansok átalakítása 1C:Enterprise 7.7
  • Számviteli tranzakció átalakítása 1C:Vállalkozás 7.7

11. fejezet. Szabály optimalizálás

  • Adatfeltöltési szabályok
  • Objektumkonverziós szabályok
  • Univerzális XML adatcsere feldolgozás

Az adatkonverzió 2.0 és 2.1 az 1C technológiai konfigurációja, amelyet a 8.1-től 8.3-ig terjedő platformverziókon valósítottak meg.

Az eszköz fő feladata, hogy szabályokat írjon az 1C 8 és 7 alkalmazásmegoldások közötti cseréhez. Az adatátalakítás jelenlegi verziója a 3.0.

Az adatkonverzió egy nagyon hasznos konfiguráció, amelynek segítségével nem csak az egyik információs bázisból a másikba történő információátvitel, hanem például az információ egy adatbázison belüli konvertálása is megoldható.

A konfiguráció nagyon kényelmes a használatához.

Az adatkonverzió minden programozó számára hasznos lesz: a csereszabályok létrehozásához szükséges készségek komoly pluszt jelentenek a szakmai készségekhez.

A konfigurációval való munka megtanulásához a megoldás a legalkalmasabb gyakorlati problémák. Próbáljon meg feladatokat kitalálni magának, például: vigyen át bizonyos információkat egyik adatbázisból a másikba, alakítsa át az értékesítési bizonylatot nyugta bizonylattá, „vezessen” folyó egyenlegekÁltal számvitel a „egyenlegek felvétele” és egyéb feladatok dokumentumban.

Nagyon hasznos lesz megérteni az 1C 8.3 „standard” csereszabályait, ahol gyakran találhat érdekes példákat a feladatok végrehajtására.

Az alapok megértéséhez anyagokra lesz szüksége, ezeket alább megvizsgáljuk.

Videó utasítások az átalakításhoz

Az 1C-ben az „1C Data Conversion” konfigurációval történő adatcsere beállításának alapjait lásd a videóban:

Anyagok, tankönyvek az 1C Data Conversion 2.0 tanulmányozásához

Nincs túl sok anyag és dokumentáció az interneten, megpróbáltam összegyűjteni a legfontosabb és legérdekesebb anyagokat:

0. Először is Ilja Leontyev ingyenes videó tanfolyamát ajánlom, elérhető a címen link.

1. Elsősorban a beépített súgó használatát javasolnám a konfigurációban. Nagyon jól van megírva és technikailag jól kivitelezve:

2. A második legfontosabb információforrás a http://www.mykod.info/ oldal (az oldal bezárt), amely kifejezetten adatkonverzióra szakosodott. Ott nagyszámú anyagot tölthet le az átalakításról.

3. Külön szeretném kiemelni a tankönyvet - (szerző - Olga Kuznetsova).