Szakasz (nyugta) szolgáltatási információkat tartalmaz (az egyszerűség kedvéért tegyük fel, hogy az üzenet az 1C alkalmazástól érkezik egy harmadik féltől származó alkalmazáshoz):

Ha az üzenet az ellenkező irányba megy - innen harmadik féltől származó alkalmazás az 1C alkalmazásban egy harmadik féltől származó alkalmazásnak megfelelően ki kell töltenie a részt .

Az 1C alkalmazások nyilvántartást vezetnek az elküldött és fogadott szinkronizálási üzenetekről, és ugyanezt várják el a harmadik féltől származó alkalmazásoktól is. Az alábbiakban vázoljuk, hogy miért történik ez.

Kézfogás mechanizmus

A szinkronizálás során az 1C-alkalmazások csak azokról a változásokról továbbítanak információkat, amelyek az utolsó szinkronizálás óta történtek az üzleti entitásoknál (az átvitt információ mennyiségének minimalizálása érdekében). Az első szinkronizálás során az 1C alkalmazás az összes vállalati entitást EnterpriseData formátumban feltölti egy XML-fájlba (mivel mindegyik „új” egy külső alkalmazás számára). A harmadik féltől származó alkalmazások következő lépése az XML-fájlból származó információk feldolgozása, és a következő szinkronizálási munkamenet során történő elhelyezése a szakaszban. információ arról, hogy az "1C"-től egy bizonyos számra vonatkozó üzenet sikeresen érkezett (a ReceivedNo mezőbe írja be az "1C"-től kapott üzenet számát). A nyugtaüzenet egy jelzés az 1C alkalmazás számára, hogy az összes üzleti entitást sikeresen feldolgozta egy külső alkalmazás, és a róluk szóló információkat már nem kell továbbítani. A nyugta mellett egy harmadik féltől származó alkalmazás XML-fájlja is tartalmazhat szinkronizálási adatokat (a szakaszban ).

Az átvételi üzenet vétele után az 1C alkalmazás sikeresen szinkronizáltként jelöli meg az előző üzenetben továbbított összes változást. Csak az üzleti entitások nem szinkronizált módosításai (újak létrehozása, meglévők módosítása és törlése) kerülnek elküldésre a külső alkalmazásnak a következő szinkronizálási munkamenet során.

Amikor adatokat viszünk át egy külső alkalmazásból az 1C alkalmazásba, a kép az ellenkezőjére változik. A pályázatnak ki kell töltenie a részt ennek megfelelően és a szakaszban helyezze el az üzleti adatokat a szinkronizáláshoz EnterpriseData formátumban.

A fájl feldolgozása után az 1C alkalmazás létrehoz egy XML-fájlt, amely nyugtaüzenetet és új adatokat tartalmaz a szinkronizáláshoz az 1C oldalról (ha vannak ilyenek az utolsó szinkronizálási munkamenet óta).

Csere webszolgáltatáson keresztül

Webszolgáltatás használatakor a cseremenetet egy harmadik féltől származó alkalmazás kezdeményezi. Ahhoz, hogy az 1C alkalmazásból adatokat fogadhasson, meg kell hívnia a GetData webes metódust, átadva a beírt egyedi alkalmazáskódot. Válaszul az 1C visszaküld egy fájlt, amely az üzleti entitásokról EnterpriseData formátumban tartalmazza az adatokat. A fájlformátum leírása.

Az adatok 1C-be történő átviteléhez az alkalmazásnak meg kell hívnia a PutData webes metódust, paraméterként átadva az egyedi alkalmazáskódot és a tömörített fájlt a fent leírt formátumban.

Megosztás más csatornákon keresztül

Katalóguson / FTP-katalóguson vagy e-mailen keresztül történő adatcsere esetén az 1C alkalmazás jár el a csere kezdeményezőjeként. A megfelelő csatornába kerül (könyvtár vagy Postafiók) fájl a fent leírt formátumban, és válaszfájlokat vár egy harmadik féltől származó alkalmazástól ugyanabban a csatornában. Exchange-könyvtár / FTP-könyvtár esetén a fájlnevet speciális módon kell összeállítani, hogy az 1C alkalmazás feldolgozhassa. Csere esetén email a levél tárgyát meghatározott szabály szerint kell összeállítani, és a levélhez csatolni kell az archivált adatállományt.

Következtetés

Az EnterpriseData formátumot használó integrációs forgatókönyvek készlete széles. Ez magában foglalja az adatcserét ugyanazon a szervezeten belül, például adatátvitelt az 1C: Számvitel más alkalmazásokból a holisztikus könyvelés fenntartásához, vagy adatcserét a központi iroda és a távoli raktárak között. A formátum különböző szervezetek közötti adatcserére is alkalmas.

Egyes esetekben (például nagy munkafolyamat vagy összetett könyvelés esetén) sokkal kényelmesebb a végfelhasználó számára, ha több alkalmazás között osztja el a könyvelést, időről időre adatot cserélve közöttük. Az 1C platform 8.3-as verziójának megjelenése előtt a szabványos adatcsere kizárólag a felhasználó kérésére történt, az információk fájlok segítségével történő feltöltésével és letöltésével XML formátum. Az utóbbi időben az 1C adatszinkronizálási mechanizmusát egyre gyakrabban használják.

A szinkronizálás népszerűségének több oka is van:

• Nincs szükség az adatok be- és kirakodási folyamatainak külön elindítására;
• Az automatikus információcsere nem zárja ki a kézi cserét;
• Könnyű beállítás (standard konfigurációk esetén még csereszabályokat sem kell létrehoznia;
• Elég egyszer létrehozni a szinkronizálást és bejelenteni a végrehajtás ütemezését.

Feladatunk feltételei

A bemenetnél két szabványos adatbázis-konfigurációnk van:

1. Bérszámfejtés és személyzeti menedzsment (3.1.3-as verzió);
2. Mezőgazdasági vállalkozás könyvelése (3.0.52-es verzió).

Mindkét alap benne van fájl mód. A szinkronizálás bármely adatbázisból konfigurálható.

Ha a szinkronizálást "Számvitel"-ről "ZUP"-ra állítja be, akkor a "Szinkronizálás" jelölőnégyzetet aktiválni kell, és fordítva.

Hol vannak a beállítások

A „Számvitelben” az „Adminisztráció” alrendszerre lépünk, a „Beállítások” menüben megtaláljuk az „Adatszinkronizálás” pontot (1. ábra).

Megnyílik a szinkronizálási beállítások ablak (2. ábra)

Rizs. 2

Itt tudjuk:

1. Szinkronizálás engedélyezése vagy letiltása;
2. Az irreleváns adatok letöltésének tiltása;
3. Állítson be egy előtagot az átvitt adatok azonosításához;
4. Nyissa meg a többi szinkronizálási beállítást.

A szinkronizálás elindításával a megfelelő jelölőnégyzet bejelölésével és az előtag megadásával lezárhatjuk a könyvelési osztályt. További munka a „Bérben” fog készülni.

Az adatszinkronizálási beállítások ablaka az ábrán látható. 3

Rizs. 3

Tekintsük részletesebben.

Szinkronizálási beállítások ablak

Kezdjük sorrendben:

Külön szeretném felhívni az olvasó figyelmét a „Változások regisztrációja” ablakra (5. ábra). Amelynek felső részén az elküldött és fogadott üzenetek száma látható, sikeres csere után a forrásbázis és a fogadóbázis számainak meg kell egyeznie. Egyes esetekben (szinkronizálás az adatbázis másolatával, működési hibák) megsértik az adatbázisok számozását. Ezt a helyzetet egyszerűen a számokat tartalmazó hiperhivatkozásra kattintva javíthatja. Ez a művelet lehetővé teszi az elküldött és a bejövő üzenetek aktuális számának manuális beállítását (6. ábra).

Rizs. 6

Szinkronizálási beállítások

Az Adatszinkronizálási beállítások lapon két parancs található:

• Dallam;
• Letöltési szabályok.

A "Szabályok betöltése" parancs elindításával megnyílik az űrlap (7. ábra)

Rizs. 7

Itt választhatjuk ki, hogy a konfigurációban megadott szabványos csereszabályokat használjuk, vagy az archív fájlban tárolt saját szabályaink szerint hajtjuk végre a szinkronizálást.

A többi beállítást a "Beállítások" gombra kattintva végezheti el (8. ábra).

Rizs. 8

Az első megnyíló ablakban a következőket teheti:

1. Nyissa meg az űrlapot a szinkronizálási szkript beállításához;
2. Események megtekintése információk küldéséhez és fogadásához;
3. Határozza meg azt a dátumot, amelytől kezdve a csere megtörténik;
4. Ha több szervezetnél vezetnek könyvelést, megadhatja, hogy melyikük vesz részt a cserében;
5. Határozza meg a bértranzakciók kirakodásának paramétereit: alkalmazotti adatokkal vagy anélkül (összegzés).

A "Szabálykészlet betöltése" parancs hasonló az előző beállítási ablakban szereplő parancshoz.

Érdemes részletesebben elidőzni a csatlakozási paramétereknél (9. ábra)

Rizs. 9

Esetünkben a cél adatbázis és a forrásadatbázis ugyanazon a számítógépen található, és fájl módban működik, így a szinkronizálás közöttük közvetlen kapcsolaton keresztül történik.

Nekünk kell:

• Határozza meg a célbázis elérési útját;
• Engedélyezési paraméterek beállítása (adminisztrátori jogosultsággal rendelkező felhasználót kell létrehozni a fogadó adatbázisban);
• A kapcsolat ellenőrzése után feltételezhetjük, hogy a telepítés kész.

Ha a csere más kapcsolattípusokon keresztül történik, akkor ezek beállításait konfigurálnia kell a megfelelő lapokon.

Ütemezési beállítások

És a végén néhány szót a szinkronizálási ütemezés beállításairól, az ablak megfelelő lapján történik (3. ábra), és semmiben sem különbözik a többi ütemezett feladat ütemezésének megfelelő űrlapjától.

Ebben a cikkben az univerzális EnterpriseData formátumon keresztüli adatcsere megszervezésében szerzett, eddig csekély tapasztalatomat ismertetem.

Az én esetemben a csere a "Trade Management 11.2" (a továbbiakban: UT) és az "Enterprise Accounting 3.0.43" (a továbbiakban: BP) konfigurációk között van konfigurálva. A csere egyirányú, UT-tól BP-ig. A Trade Management 11.1-es verziójának 11.2-es verzióra történő frissítése előtt az adatcserét a Data Conversion 2.0 konfigurációjával konfigurálták. A „Trade Management” „11.2”-re való váltása után azonban hibák jelentek meg a felhasználók munkája során. A csereszabályzat frissítésére irányuló eljárást lefolytatták, de ez nem vezetett eredményre. A hibakereső megmutatta, hogy a probléma az adatcserében van. Úgy döntöttek, hogy mindkét konfigurációban eltávolítják és újra beállítják az adatcsere beállítást.

Mind a "Trade Management", mind a "Enterprise Accounting" ügyfél-szerver verzióban működik nálunk. Elkezdtem beállítani a szinkronizálást az UT-vel. Úgy végeztem el, hogy az adatok az UT-ból egy fájlba kerültek ki. Ez a szinkronizálás a hálózati címtáron keresztül. Az ÜT-ben úgy konfiguráltam a központot, hogy az ÜT-ről ne rakódjanak ki adatok.

Hiba a kontextus metódusának hívásakor (Érvényesítés): Hiba az XDTO adatok érvényesítése során:
A "/Counterparty's Bank Account/Bank" objektum szerkezete nem egyezik a következő típussal: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)KeyPropertiesBank
A "BIC" tulajdonság ellenőrzése:
forma: elem
név: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)BIC
típus:
Szükséges tulajdonság hiányzik
Tárgy: Megállapodás a partnerrel ...

A hiba elemzéséhez a „Küldendő adatok összetétele” ikonra kattintottam és a szerződésküldésre regisztrált felek listájában megtaláltam azt a szerződést, amely alatt a hiba jelentkezett. Felbontotta a szerződést, memorizálta a szerződő fél szerződésben meghatározott bankszámláját. Aztán áttértem a szállításra regisztrált bankszámlákra. Kiderült, hogy a kívánt számla nem szerepel a regisztráltak listáján. Átvezettem a problémás bankszámlát és a szerződést. Ezt követően manuálisan regisztrálta a szükséges bankszámlát.

Megpróbáltam újra szinkronizálni az UT-ból származó adatokat. Ezúttal az adatok feltöltése sikeres volt. BAN BEN hálózati mappa alakított XML fájl, amely adatokat tartalmaz az UT-ról a BP-re történő átvitelhez.

A következő lépés az adatok feltöltése a fájlból a Vállalati Számviteli Osztályra. A "Vállalati könyvelés" konfigurációban a "Szinkronizálás" gombra kattintottam, a feldolgozási űrlap "Adatelemzés folyamatban" üzenettel nyílt meg. Kicsit később az üzenet a következőre változott: „Az adatok feltöltése folyamatban van”. A mutató és a számláló ugyanakkor azt mutatta, hogy több mint 80 ezer tárgyat raknak ki az ÜT-ről. Ez megzavart, mert a beállításoknál jeleztem, hogy a tápegységről semmit sem szabad kirakni. A feldolgozás sokáig tartott, és hibával ért véget:

Esemény: Kommunikáció
(CommonModule.LongOperations.Module(371)): A dolgozói folyamat összeomlott háttérmunka
ThrowException(ErrorText);

A hiba lokalizálásához megpróbáltam módosítani a szinkronizálási beállításokat és a BP alap működési lehetőségeit. Ennek eredményeként, amikor az adatbázist fájlverzióra konvertáltam, a rendszer megfelelően működött: megnyílt a két adatbázis összehasonlító űrlapja. Az objektumok egyeztetése után a kezdeti szinkronizálás sikeres volt. Ezután ismét átvittem az adatbázist a kliens-szerver verzióra.

A szinkronizálás további "futása" során szükség volt néhány változtatásra az objektumok konvertálására vonatkozó szabályokon. Ideje használni az „Adatkonverzió 3.0” konfigurációt. A beépített konfigurációs súgó leírja, hogyan kell dolgozni. Az ITS honlapján található cikkek is segítettek.

Ennek eredményeként a következő adatokat töltöttem be a "Data Conversion 3.0"-ba:

• Szövegek közös modul"Data Exchange Manager Via UniversalFormat" két bázisról
• Mindkét alap diagramja
• Az EnterpriseData formátum leírása (bármely adatbázisból)
• Konverziós szabályok

Letöltés után megnyitottam az adatok, objektumok, tulajdonságok konvertálására vonatkozó szabályokat a "Data Conversion 3.0"-ban. Elvégeztem a szükséges változtatásokat. Ezután a "Cserekezelő modul eltávolítása" gombot használtam. A modul szövegét a vágólapra másoltuk. Csak be kell helyezni a konfigurációba.

Miután kísérleteztem a szabályok beállításával a "Data Conversion 3.0" programban, arra a következtetésre jutottam, hogy abban az esetben, ha a változtatások csekélyek, egyszerűbb szabályokat beállítani közvetlenül az UT és a BP konfigurációkban, az "Adatcsere" általános modulban. Manager Via UniversalFormat". Ha a módosítások komolyak, például egy új objektum hozzáadása cserébe, akkor használja a konfigurációt " Adatkonverzió 3.0".

Elvégeztem azt a feladatot, hogy a "Megrendelés a szállítónak" dokumentumot a cseretervhez a " Adatkonverzió 3.0". Az UT - BP szabványos verziójában ez a dokumentum nem szerepel a cseretervben.

Ne feledjük, hogy az objektumok kirakodáshoz történő regisztrálásának szabályai továbbra is az „Adatkonverzió 2.0” konfigurációban vannak konfigurálva.

Ezek az első benyomások az univerzális EnterpriseData formátumon keresztül történő adatszinkronizálásról.

P.S. Ha kérdései és saját észrevételei vannak az univerzális formátumon és konfigurációkon keresztüli adatcserével kapcsolatban " Adatkonverzió 3.0", írd meg kommentben. Tapasztalatot cserélünk.

• Adatszinkronizálás
• Univerzális EntepriseData formátum
• Adatkonverzió 3.0
• Adatkonverzió 2.0
• Kereskedelmi menedzsment
• Vállalati könyvelés

És megmutatjuk, hogy segítségével ERŐSEN leegyszerűsítheti feladatai megoldását

Ma azt elemezzük, hogyan állíthatjuk be és hajthatjuk végre a címtárak és kezdeti egyenlegek egyszerű átvitelét szó szerint 10-15 perc alatt.

És ez az tömeges és rendszeres feladat, ami szinte elkerülhetetlen a legtöbb bevezetésre kerülő új konfiguráció esetében.

Ezért hívd fel kollégáidat, nekik is nagyon hasznos lesz.

Főleg, ha már látták a CD 3-at és megijedtek :)

Igen, amikor először látod, egyáltalán nem világos.

De valójában - minden NAGYON egyszerű. Olyan egyszerű, hogy később még unatkozni is fogsz :)

Pontosan mi van a mai videókban

Ez 4 videó az adatok megosztásáról ezen keresztül univerzális EnterpriseData csereformátum.

Ezen kívül mutatunk egy példát is szabványos csereszabályok finomítása 1C-ben: Adatkonverzió 3.0

Teljes időtartam - 34 perc. Tartalom:

• Csere beállítása az 1C: Accounting 8 és az 1C: ERP példájával
• A szabványos szabályok és az univerzális csereformátum betöltése a Data Conversion 3.0-ban
• A metaadat-struktúra átvitele a CD 3.0-ra
• Hogyan kell végrehajtani az első adatcserét
• A szabályok finomítása konverziók
• Új szabályok betöltése a konfiguráció megváltoztatása nélkül ( támogatásból való kivonás nélkül)

jegyzet hogy a probléma megoldása során a betöltési szabályok csak a vevő konfigurációjában változnak. A forráskonfiguráció pedig a szabványos szabályok szerint működik.

Ha egy ilyen feladatot a Data Conversion 2.0-ban oldanának meg, akkor mind a forrás, mind a célhely szabályait módosítani kellene.

Ezek az oktatóvideók a BSP-re vonatkoznak felülvizsgálat 2.3.2(a 2.3.2.43-nál régebbi építményekhez).

Ha a BSP régebbi verzióját használja, végezzen „javítást” a megváltozott felületen és a kibővített funkcionalitáson. Ehhez ismételje meg a példát a videóból.

1. videó:
Csereszabályok betöltése tipikus konfigurációk között a Data Conversion 3.0-ban

Ebben a leckében előkészítő műveleteket hajtunk végre a tipikus konfigurációk közötti csereszabályok módosítása során:

• A csereformátum szerkezetének betöltése a CD-re (
• Konverzió létrehozása
• Szabályfájlok feltöltése egy tipikus konfigurációból
• A cserekezelő modul kirakása

2. videó:
A csereszabályok finomítása a CD 3.0-ban

Ebben az oktatóanyagban megmutatjuk, hogyan kell kitölteni az objektumok adatait adatok betöltésekor.

A feladat megoldódik - objektumok betöltésekor a forráskonfigurációból állítsa be a „Betöltés a BP 3.0-ból” megjegyzést.

A probléma megoldásához meg kell csinálni az objektumkonverziós szabályok változásai, a „Beérkezett adatok írása előtt” esetben.

A kidolgozott szabályok a következő néven lesznek elmentve külső feldolgozás további felhasználásra.

3. videó:
Univerzális csere létrehozása a tipikus konfigurációk között

Ebben az oktatóanyagban bemutatjuk, hogyan állíthat be egy új típusú cserét.

A beállításokat a rendszer a forráskonfigurációban végzi el, majd betölti a célkonfigurációba.

Ebben a videóban azt is megmutatjuk, hogyan a konfiguráció megváltoztatása nélkülúj csereszabályok feltöltése.

4. videó:
Nyitóegyenlegek átutalása devizaszabályok segítségével

A leckében bemutatunk egy tipikus függvényt a kezdeti egyenlegek átutalására.

P.S.

Igen, csere txt / dbf / ole stb. joguk van létezni. Egyes speciális esetekben, például dokkolás webszerverrel vagy átvitel kész külső alkalmazásformátumról.

Normál cserék esetén azonban - a szabványos módszerek gyorsabbak és sokkal egyszerűbbek is.

És ha valaki újra feltalálja a kereket, amikor van egy kész univerzális megoldás - olyan, mintha a homlokodra írnád: "Nincs hangszerem, nem akarok tanulni, a pénzedért mankókat építek" .

P.P.S.

Meg akarjuk mutatni, hogy a Data Conversion 3.0 nem nehéz.

Szokatlan – igen. Nem minden azonnal világos – igen. Vannak nagyon kétértelmű pillanatok – igen.

De kész instrukciók és videók segítségével mindössze 1-2 hét alatt elsajátítható.