A cikk leírja az 1C:Enterprise konfigurációs 7.7-es és 8.2-es verziói közötti adatcseréhez szükséges lépéseket, ugyanazt a konfigurációt használva. Adatkonverzió, 2.1.4.1. kiadás.

Keressük meg az MD82Exp.epf feldolgozófájlt az adatkonverziós konfigurációs terjesztési készlet részeként. Le kell töltenie a vevő alap konfigurációs metaadat-struktúrájának leírását.

Ugyanezen disztribúciós készlet részeként megtaláljuk a V8Exchan82.epf feldolgozófájlt is - " univerzális csere adatok XML formátumban. A vevőalap kirakásához lesz szükség. Ahogy a neve is sugallja, ezeket a feldolgozásokat az 1C:Enterprise 8.2 verzióval való együttműködésre tervezték.

Ezután találunk eszközöket az 1C:Enterprise 7.7 verzióval való munkához.

Az Adatkonverziós konfiguráció terjesztési készlete tartalmazza az MD77Exp.ert feldolgozófájlt. Le kell töltenie a forrásadatbázis konfigurációs metaadat-struktúrájának leírását.

Ugyanezen disztribúciós készlet részeként megtaláljuk a V77Exp.ert feldolgozó fájlt is – „Univerzális adatfeltöltés XML formátumban”. A forrásadatbázis eltávolításához lesz szükség.

Tehát kezdjük:

Először töltsük ki a forrás és cél metaadat-struktúra leírását.

1. Nyissuk meg a forrásadatbázist 1C:Enterprise 7.7 módban, és kezdjük el az MD77Exp.ert feldolgozását a forrás metaadat-struktúra leírásának eltávolításához. Mentse a forrás metaadat-struktúrát a Rules1.xml fájlba.
2. Nyissuk meg a vevő adatbázisát 1C:Enterprise 8.2 módban, és kezdjük el feldolgozni az MD82Exp.epf fájlt a vevő metaadat-struktúrájának leírásának eltávolításához. Mentsük el a fogadó metaadat-struktúráját a Rules2.xml fájlba.

Töltsük be mindkét konfiguráció metaadat-struktúrájának leírását.

1. Futtassa az Adatkonverziós konfigurációt 1C:Enterprise 8.2 módban.
2. Nyissa meg a „Konfigurációk” könyvtárat (Könyvtárak—>Konfigurációk). Információkat tárol azokról a konfigurációkról, amelyek között csereszabályok konfigurálhatók.
3. Adjunk konfigurációs információkat a forráshoz. Kattintson a "Hozzáadás" gombra vagy a "Beszúrás" gombra.
4. Adja meg a fájl elérési útját a Rules1.xml forrás metaadat-struktúrával. Kattintson a "Letöltés" gombra.
5. Adjunk hozzá információkat a vevő konfigurációjáról. Kattintson a "Hozzáadás" gombra vagy a "Beszúrás" gombra.
6. Adja meg a fájl elérési útját a Rules2.xml fogadó metaadat-struktúrával. Kattintson a "Letöltés" gombra.

Tehát betöltöttük a forrás és a cél információit. Most konfigurálhatjuk a csereszabályokat.

1. Nyissa meg a „Konverziók” könyvtárat (Könyvtárak—>Konverziók). Ez a könyvtár olyan információkat tartalmaz, amelyek meghatározzák, hogy mely konfigurációk között és milyen irányban történik a csere.
2. Tegyük hozzá új elem. Kattintson a "Hozzáadás" gombra vagy a "Beszúrás" gombra.
3. Adja meg a forráskonfigurációt a "Konfigurációk" könyvtárból. A „Konfiguráció – Forrás:” mező.
4. Adja meg a vevő konfigurációját a "Konfigurációk" könyvtárban. "Konfiguráció - vevő:" mező.
5. Fontos részlet!!! Nyissa meg a "Speciális" lapot. Az "Unload modul file name:" mező.
6. Adja meg a kirakodómodul fájl helyét, például: C:BasesUnloadingModule.txt.
7. Ennek a fájlnak a tartalma szükséges ahhoz, hogy a jövőben a teljes modult lecseréljük a V77Exp.ert feldolgozása során (erről bővebben lentebb). A kirakodás e csere nélkül lehetetlen!
8. Nyomjuk meg az "OK" gombot.

Remek, beállítottuk a csereszabályokat. A csereszabályokat fel kell tölteni egy fájlba.

1. A „Konverziók” könyvtárban válassza ki az újonnan létrehozott elemet.
2. A referenciapanelen kattintson a "Go to Rules" gombra. Megnyílik egy űrlap a konverziós szabályokkal.
3. Az „Adatfeltöltési szabályok” fülön jelezzük, hogy pontosan mit is szeretnénk feltölteni.
4. A "Property Conversion" fülön megadhatjuk a csereobjektumok attribútumainak leképezését.
5. Ezen az űrlapon a bal felső sarokban találjuk a „Szabályok mentése” gombot.
6. Adja meg a fájl nevét és elérési útját (például C:BasesDataExchangeRules.xml). Nyomjuk meg a "Megnyitás" gombot.
7. Később a „Konverziók” könyvtárban módosíthatjuk a megadott elérési utat —> „Aktuális elem módosítása (F2)” —> a „Speciális” fülön —> az „Exchange rule file name:” mezőben.
8. A szabályok mentése közben az unload modul is az általunk korábban megadott elérési útra íródik: C: Bases Unload module.txt.

Az átalakítási szabályok készen állnak! Most végezzük az adatcserét.

Nyissuk meg a forrásadatbázist 1C:Configurator 7.7 módban, majd nyissuk meg a V77Exp.ert feldolgozást - "Univerzális adatfeltöltés XML formátumban". Nyissa meg a "Modul" lapot, törölje a modul összes tartalmát. Illessze be a következő sort: #LoadFromFile C:BasesUploadModule.txt.

A "LoadFromFile" direktívával átkapcsoljuk a letöltést szoftver modul szöveges fájlból betölteni. Most meg kell győződnünk arról, hogy az Upload Module.txt feltöltési kóddal rendelkező fájl mindig az általunk megadott mappában van.

Mentse el a V77Exp.ert feldolgozást.

Az adatok feltöltéséhez a következőket kell tennie:

1. Nyissa meg a forrásadatbázist 1C:Enterprise 7.7 módban, majd nyissa meg az éppen mentett V77Exp.ert feldolgozást.
2. A "Rules file name:" mezőben adja meg a csereszabályfájl nevét (itt mentettük: C: BasesData Exchange Rules.xml), és az "Adatfájl neve:" mezőben válassza ki azt a fájlt, amelybe az adatok bekerülnek. fel kell tölteni (például C: Bases Data Upload From 7. 7.xml).
3. Ezután le kell töltenie a csereszabályokat a "Csereszabályok letöltése" gombra kattintva.
4. Egy bizonyos időközönkénti dokumentumok feltöltéséhez meg kell adnia az időszakot - "Kezdő dátum" és "Befejező dátum".
5. Az „Adatfeltöltési szabályok” listában található jelölőnégyzetek jelzik, hogy mely adatok kerülnek feltöltésre és melyek nem.

Most töltsük be az adatokat a vevő adatbázisba. Nyissuk meg 1C:Enterprise 8.2 módban, és kezdjük el feldolgozni az "Univerzális adatcsere XML formátumban" elemet a forrásadatok betöltéséhez.

Ez a V8Exchan82.epf feldolgozófájl. Vagy nyissa meg az "Eszközök" -> "Egyéb adatcserék" -> "Univerzális adatcsere XML formátumban" lehetőséget.

1. Az „Adatbetöltés” ​​fülön lévő feldolgozásnál válassza ki az adatfájl nevét (itt mentettük el: C: Bases Data Upload From 7.7.xml).
2. Kattintson az "Adatok betöltése" gombra (a felső panelen található).

Adatok betöltve!

Az 1C:Enterprise 7.7 verzióból történő kirakodáshoz ugyanazok a lépések vonatkoznak az 1C:Enterprise 8.1 és 1C:Enterprise 8.0 verziókra is. Az adatkonverziós konfiguráció terjesztési készlete az MD81Exp.epf és V8Exchan81.epf, MD80Exp.epf és V8Exchan.epf verziókhoz tartozó feldolgozó fájlokat tartalmazza.

Ha adatokat szeretne feltölteni az 1C:Enterprise 7.7-be, akkor V77Imp.ert feldolgozást kell használnia. Az adatok betöltése előtt ugyanazokat a műveleteket kell végrehajtania a V77Imp.ert feldolgozó modullal, amelyeket a V77Exp.ert feldolgozásakor leírtak.

Ha a listából a feldolgozást választja gyors hozzáférés(Fájl - V77Exp.ert), és megjelenik egy üzenet, hogy a fájl nem található, bár a fájl ugyanazon a helyen található, és a név nem változott, akkor csak annyit kell tennie, mint az elején - „Fájl | Nyissa meg", és válassza ki újra a V77Exp.ert fájlt.

1. Bemutatkozás.

2. Amire szüksége van: 1C konfiguráció: Adatátalakítás 2. * és feldolgozás a csomagból. Példaként a feladatokra vesszü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ük és elindítottuk a konverziós bázist.

Az 1C: Trade Management 11 és az 1C: Enterprise Accounting 3 (UT / BUH csereszabályok) konfiguráció között írjuk meg a csereszabályok fejlesztését.

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 kiürítési folyamat segítségével történik.

Valójában a kicsomagolt konfigurációs könyvtárban a bekapcsolt konfigurációkhoz kezelt űrlapok az MD83Exp.epf feldolgozása iránt érdeklődünk. Ha a kirakodást a szokásos űrlapokon lévő konfigurációkból kell végrehajtani, akkor az MD82Exp.epf feldolgozást használják. Ez akkor van így, ha például olyan konfigurációkból kell struktúrát beszereznie, mint az 1C: UT 10, 1C: Manufacturing Enterprise Management 1.3, 1C: Integrated Automation 1.1, 1C: Zup 2.5 és így tovább.

Továbbá az adatok 1C-ben történő feltöltéséhez és letöltéséhez szabályaink szerint szükség van az "Univerzális adatcsere XML formátumban" V8Exchan83.epf feldolgozására olyan kezelt űrlapokon, mint például az 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. A konfigurációs metaadat-struktúra feltöltése 1C: Trade Management 11.3 és 1C: Enterprise Accounting 3.0. *

Kezdjük a metaadat-struktúra eltávolításával az 1C konfigurációból: Enterprise Accounting 3.
Nyílt feldolgozás MD83Exp.epf

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-ben történő kirakását. Választható az is, hogy a kirakodás hol fog megtörténni: az 1C szerveren vagy a „kliensen”. Adja meg annak a fájlnak a nevét, ahova az adatstruktúra ki lesz töltve. Hasonlóképpen eltávolítjuk a Trade Management 11 konfigurációs metaadat-struktúrát.

Most be kell töltenie a konfigurációt a konverziós adatbázisba. Ez az elem a konfigurációk listájából és a konverziók listájából is elérhető. Indítsuk csak az asztalról:

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

És hasonlóan - a Kereskedelmi Minisztérium szerkezete.

Amikor a letöltés befejeződött, megjelenik egy párbeszédpanel, ahol megadhat egy Önnek megfelelő nevet.

6. Konverziós szabályok létrehozása az 1C-ben a feladat konkrét példáján.

Ezután lépjen az "Objektumszabályok beállítása" részre, ahol létrehozunk egy új beállítást.
Az átalakítás létrehozására szolgáló párbeszédpanelen válassza ki a "forrás" é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 az alkotást „a semmiből” és „szemét nélkül” mutatom be, emlékeztetem Önt, 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 rakjunk ki az egyikbe, hanem egy típust egy 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 könyvtárakkal a BP 3 Áruk és szolgáltatások átvétele dokumentumhoz.

Tehát létrehozunk egy új PKO-t (az objektumok 1C-vé alakításának szabályát)

Válassza ki a Szolgáltatások értékesítése forrást és a Szolgáltatási áru átvételének címzettjét, majd kattintson az OK gombra.
Ebben az esetben egy párbeszédpanel jelenik meg, ahol ismét megtagadjuk a PKC (Property Conversion Rules) automatikus létrehozását. Ezután csak a szükségeseket választjuk ki.

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

Létrejönnek a VDP-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.

Ezenkívül nyilvánvaló, hogy alapértelmezés szerint az FSP keresése az objektum belső azonosítója alapján javasolt. Ezt a PKO melletti nagyító jelzi. A keresést saját kezűleg végezzük, a nap eleji dokumentumszám és dátum alapján.

Az UIO keresésének törlése:

Most kezdjük el az objektum szükséges tulajdonságainak (rekvizitjainak) egyeztetését. Ehhez kattintson a "Tulajdonság 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"). Eltávolítjuk 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, mire van szüksége:

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 olyan adatot is, amelyek név szerint nem egyeznek, például „Pénznem” és „Dokumentum”. valuta".

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

Kezdjük a részletekkel, hogy végigmegyünk és leírjuk. Először is beállítjuk a bizonylat keresését, ahogy korábban írtam, kirakjuk és a dátum elején keressük meg a bizonylatot, és változtatjuk a számozást. Az első három karaktert az "UTB" előtagunkra cseréljük. És mivel BP-ben és UT-ban a számozás egyenként 11 karakterből áll, ezért egy összetett számot készítünk: az előtagunk és a forrásból származó 8 karakter. Képernyőkép példa alább.

Mindig kirakjuk azokat a dokumentumokat, amelyeket nem vittek ki és nem mozdultak el. Feltételezzük, hogy a dokumentumokat a felhasználó ellenőrzése után a fogadóban tároljuk.

Ehhez a PCS-t, miután beállította a not hold, 0 vagy 1 értéket, logikai értékként használjuk.

A pénznemet példaként használva létrehozunk egy szabályt egy objektum PCS-hez való konvertálására. Ugyanakkor figyelembe vesszük, hogy mindkét bázisban van pénznem, és ezeket kóddal kell szinkronizálni. Ezért nem hozzuk létre az összes PCS-t a pénznemek CSP-jében, hanem csak a kódot adjuk hozzá a kereséshez. Azok. az objektum PCS-jének létrehozására vonatkozó javaslatból - elutasítjuk.

A létrehozott konverziós szabályt a dokumentum PQS-jében az SCS helyettesítette. Magát az alapértelmezett szabályt pedig egy egyedi azonosító kínálja fel. Javítjuk, keresést végzünk a kódban, és úgy állítjuk be a tulajdonságot, hogy ne hozzunk létre új objektumot.

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

Továbbá analógia útján elkészítjük a PKO és a PKS többi részletét. Ezenkívül beállítjuk a szervezet keresését a partnerek szerint, és fordítva, a TIN alapján. Minimális részletekkel így néz ki (szükség esetén kiegészítheted).

A szerződő felek PKO-szerződései esetében a PKS-partnert, a nevet és a tulajdonost keressük.

Nézzük meg, hogyan adjuk meg a kívánt értéket a felsorolás típusában a PCS-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 „homlokba” karakterláncként beírni a kívánt értéket.

Az alábbiakban bemutatjuk, hogyan állíthat be nehézségek nélkül, és a legtöbb esetben PKS-t az elszámolási többszörösségre, az elszámolási rátára, a számlákra.

A PKO-nómenklatúra esetében meghagyjuk a belső egyedi azonosító alapján történő keresést. De figyelni fogok arra, hogyan határozhatja meg újra a csoportját. Például megállapodunk abban, hogy egy új nómenklatúra kerül kiürítésre az 1C konfigurációból: Trade Management 11, de szükséges, hogy a nómenklatúrát egy adott „Csoportunk” csoportba gyűjtsük.

A feladat végrehajtásához létrehozunk egy másik PKO-t. Nevezzük "Nómenklatúra Szülő"-nek, amit a szülő PDN-jében fogunk jelezni a konverziós szabályban.

Két keresést állítottunk be: név szerint, ahol a csoportunk neve kemény kódolású, és a "ThisGroup" attribútum kötelező tulajdonságát igazra állítottuk.

Mivel úgy döntöttünk, hogy az összes nómenklatúra a mi csoportunkba tartozik, így kirakáskor nem kell kirakni a csoportokat az UT 11-ből, ehhez a Nomenclature PKO-ban a „Kirakás előtt” eseménykezelőben egy szűrőt teszünk. hogy nem szükséges kirakni a „Failure = Source” csoportokat. Ez a csoport;".

A DRP (adatfeltöltési szabályok) Áruk és szolgáltatások implementációjában egy szűrőt adunk hozzá, hogy a törlésre jelölt dokumentumok ne kerüljenek feltöltésre. Ehhez a PDP-ben a "BeforeUnloading" eseménykezelőkbe írjuk a "Rejection = Object.DeletionMark;" szűrőt.

Mentse el a kidolgozott szabályokat egy fájlba.

7. Összegzés: Adatfeltöltés és letöltés a kidolgozott adatcsere-szabályok segítségével.

Az 1C: Trade Management 11-ben megnyitjuk az "Univerzális adatcsere XML formátumban" V8Exchan83.epf feldolgozást.

A kirakodás elmúlt, most ugyanazzal a feldolgozással töltjük be az 1C: Enterprise Accounting 3-ba.

Letöltés befejeződött. Ellenőrizzük, hogy fel van-e töltve. Tehát a dokumentum betöltődik, ahogy akartuk - a Szervezetet betöltjük a partnerbe, a partnert pedig a szervezetbe. A fiókok mindegyike letöltődik és telepítve van. A dokumentumszámot az előtagunkkal és a nap elején kaptuk. Minden regisztrált adatot kitöltöttek.

Ellenőrizzük a nómenklatúra betölté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. Sok finomság van az átalakításban, és néhány egyszerű, de szükséges dolog, ami segít az átalakítás pontos megírásában. És ez lehetővé teszi a hibák minimalizálását, nem rontja el a meglévő adatokat, és nem szabadul meg tőlük felesleges szemetet. Ez az egyik legtöbb egyszerű példák. Azt is megteheti, hogy egy objektumot sokré alakítson át, vagy fordítva, sok - egyet.

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 értékelnie kell a tevékenységi területén eltöltött időt, és ez a feladat kérje meg a szakembereket.

A feltöltendő adatok típusainak meghatározása, az 1C Enterprise könyvelési rendszer adatbázisából történő adatkiválasztás leírása, a forrás adatmező illesztése a webáruház adatbázisának mezőivel, táblázataival.

Fontos!!! A csereszabályok beállítása csak haladó felhasználók számára lehetséges. Nem ajánlott önbizalom nélkül megtenni.

A szabályok beállításához programozási ismeretekre van szükség az 1C nyelven és az 1C lekérdezési nyelven.

A szabályok felállításához nem adunk tanácsot, csak leírás alapján. Ha javításra van szüksége, jobb, ha megrendeli tőlünk a felülvizsgálatot.

Feltöltési szabályok listája

Szabálylista feltöltése vezérlőpult

Teremt– új kirakodási szabályok hozzáadása;

változás– módosítsa a kirakodási szabályokat;

Betöltés fájlból– kész szabályok betöltése a fájlból való kirakodáshoz;

Frissítse a fájlból való kirakodás szabályait– frissítse a kiválasztott szabályokat a fájlból;

– jelentés a kirakodás szabályairól. Kiterhelt adattípusok listája, adatcélpontok.

ban ben

Fő

A kód– a kirakodási szabályok azonosítója;

Név– a kirakodási szabályok neve;

Leírás– megjegyzések a kirakodási szabályokhoz.

Fájlok

Kiterjesztés- fájl sablon. A (Picture Extensions) kifejezés azt jelenti, hogy az összes képkiterjesztést használni fogja;

Katalógus– a kép fogadó könyvtára a webhelyen, a webhely gyökeréhez viszonyítva, perjelek nélkül az elején és végén, a "/" sesh könyvtárak között;

Átnevezés ebből– másoláskor átnevezendő fájlsablon;

Átnevezés erre– fájlsablon, amelyre át kell nevezni a fájlt az oldalra másoláskor.

Szűrők

Név– szűrőfej;

Terület– szűrőmező a kérésekben;

Egy tárgy– szűrőobjektum típusa (csak egy érték).

Lehetőségek

Szükségszerűen– kötelező paraméter, ha nincs kitöltve, állítsa le a kirakodást;

A kód– paraméter azonosító;

Név– paraméter fejléce;

Kilátás– a paraméterobjektum típusa.

Adat

Adattípusok

Adattípus lista eszköztár

Hozzáadás– új típusú adatok;

Töröl– adattípus törlése;

Mozgás felfelé– mozgassa felfelé az adatnézetet;

Mozgás lefelé– mozgassa lefelé az adatnézetet;

Másolás a szabályokból– adattípus másolása az összes beállítással más szabályokból;

Szabályok– forrásszabályok másolása;

Másolat– megjelöli, hogy milyen adatok kerülnek másolásra

Az adatnézet testreszabása

Forrás

A kód– adattípus azonosító;

Név– az adattípus megnevezése;

Kérés- egy kérés az 1C lekérdezési nyelven, amelyhez az adatokat kiválasztják a feltöltéshez. Lehetőség van a kérésben a feltöltési paraméterekkel megegyező azonosítójú paraméterek használatára.

A kérelem szövegének szöveges címkéket kell tartalmaznia:

• [További részletek]- írja be a részletek listájának végére;
• [További táblázatok]- írjon a táblázatok listájának végére;
• [További feltételek]- írja a feltételek végére, ha nincs feltétel, akkor írja be a [Feltételek] a kérés végére

Eljárások

Az eljárás célja:

• Paraméterek beállítása– adatkiválasztás előtt kerül végrehajtásra, az eljárásban lehetőség van a Report Builder további paramétereinek beállítására is, az Unload Parameters mellett;
• ProcessingResult– az adatok lekérése után kerül meghívásra, hogy további adatokat állítson be a táblázatban az eredménnyel, a lekérdezéssel nem elérhető adatokkal;
• Eredménykarakterlánc feldolgozása– a kirakodás során hívódik meg a formálás pillanatában, amikor az eredménytábla adatait rendezi.

Egyéb

Példa a nómenklatúra tételeinek kirakodására

Példa a tételek árának kirakodására

Ne törölje az adatokat a szerveren– ha engedélyezve van, a webhely adatbázisában lévő adatok törlésére vonatkozó kérés nem generálódik, még akkor sem, ha a feltöltési profilban engedélyezve van a tisztítás;

Csak teljes letöltés– a teljes letöltés mindig használatban lesz, még akkor is, ha a frissítési mód engedélyezve van a letöltési profilban;

Adatfrissítés\Frissítés mező– a kérelemben szereplő attribútum neve, amellyel a kérésből származó adatok betöltetlennek jelölik;

Adatok frissítése \ Elérési út kérésben– az update attribútum elérési útja;

Listaszűrő \ Listakód– adatlista kódja szűrőnként. Ha a feltöltési adathalmaz közös hivatkozású adatokat tartalmaz, például Cikkek és lesznek Cikkárak, akkor a tétel lehet összetett szűrővel az egyenlegekre, az árak rendelkezésre állására stb., hogy ne mindenben ugyanazok a szűrők legyenek. lekérdezi a tétel kirakásakor a kirakott nómenklatúra listát képez, és az ezt követő adatokban a szűrő automatikusan felkerül a Nómenklatúra listájára;

Listaszűrő \ Adatmező– attribútumnév, amellyel a következő szűrők listája kitöltésre kerül;

Listaszűrő \ Lekérdezési útvonal– elérési út a feltétel kialakításának kérésében.

Vevő

Asztalok listája

Táblázat lista eszköztár

Töltse fel a webhelytáblázatok listáját– olvassa el a táblázatok listáját az online áruház adatbázisából. A funkció működéséhez meg kell nyitni a szabályszerkesztőt a konfigurált online áruházprofilból.
Táblázat lista oszlopai

asztal– az internetes áruház adatbázisában szereplő táblázat neve;

Kitöltési feltétel mező– mezőnév a forrástáblában, hogy feltételt képezzen arra az esetre, ha a forrástábla nem minden sora esik az aktuális táblába;

Kitöltési állapot értéke– állapotérték;

Tisztítási állapot– ha a helyadatbázis táblájában lévő adatok nem törölhetők a TRUNCATE-n keresztül, adja meg a feltételt, amely szerint az adatbázis törlődik a DELETE-en keresztül.

A táblázat mezőinek listája

Táblázat mezőlista oszlopai

Név– mezőfejléc;

Forrás– mező neve az adatforrás táblájában. Forrásként speciális értékek használhatók:

• Jelentése– az „Érték \ Paraméter \ Dinamikus kódok sorozata” oszlopban kiválasztott állandó érték;
• ParameterUploads– a kirakodási paraméter értéke, a paraméter neve az "Érték \ Paraméter \ Dinamikus kódok sorozata" oszlopba kerül;
• Kitöltés dátuma- az aktuális dátumot veszik;

Vevő– mezőnév az online áruház adatbázistáblájában;

Azonosító– a mező egy azonosító, amelyet az UPDATE kérésben feltételként használnak;

Beállítás– a kirakodási profilban letiltható a mező kirakodása;

Érték \ Paraméter \ Dinamikus kód sorozat– állandó érték vagy paraméter neve, ha a megfelelő forrás van kiválasztva, vagy Kódsorozat;

Útvonal kérésben– azon objektumok kérésében szereplő adatok elérési útja, amelyeken a dinamikus kód generálódik;

Kiegészítő paraméter- mező neve ehhez további paraméter dinamikus kód;

Útvonal kérésben– a kiegészítő paraméter kérésében szereplő adatok elérési útja;

Első kód– dinamikus kódok első kódjának értéke;

Átalakítani– mezőadatok konverziós szabályai:

• DynamicCode– konvertálni dinamikus kódra;
• Szám- számmá alakítani;
• DateLinks- kapja meg a címtár elemének 1C-ben történő bejegyzésének dátumát, az adatok a belső GUID azonosítóból származnak;
• Kép– lekérni a képfájlt a képre mutató hivatkozásról a tartalomkezelőben;
• Formátum– konvertálja a formázási értéket, formázási karakterláncot 1C nyelvre;
• SQL függvény– SQL függvény beszúrása célként.
• Kezelés- eljárás 1C nyelven egy érték tetszőleges feldolgozására.

Általános eljárások

Az eljárások célja:

• Kirakodás előtt– az adatok feltöltése előtt indul;
• Kirakodás után– az adatok kirakodása után indul;
• Fájlok feltöltése előtt– az előkészített fájlok szerverre való feltöltése előtt indul;
• Fájlok feltöltése után- a fájlok szerverre való feltöltése után indul el.

Adatbázis módosítás

A webáruház adatbázisának módosításához szükséges lekérdezések listája, az adatfeltöltés használata előtt.

Figyelem! A lekérdezéseket egyszer kell lefuttatni.

• Következő >

Automatizált rendszerek az ellenőrzések a legtöbb esetben abból állnak különálló alapok adatok, és gyakran földrajzilag elosztott szerkezetűek. Ugyanakkor a helyesen megvalósított adatcsere elengedhetetlen feltétele az ilyen rendszerek hatékony működésének.

Ebben az esetben a kezdeti cserebeállítás számos intézkedést igényelhet, nem csak a programozás, hanem a tanácsadás terén is, még akkor is, ha homogén forrásokkal van dolgunk, mint az 1C:Enterprise platformon alapuló termékek esetében. Ebben a cikkben megvizsgáljuk, hogy az 1C központ beállítása (vagy ahogy más néven adatszinkronizálás az 1C 8.3-ban) miért válhat az integrációs projekt legidőigényesebb és legdrágább feladatává.

Az 1C környezetben történő adatcsere lehetővé teszi, hogy:

• Szüntesse meg a dokumentumok kettős bevitelét;
• Kapcsolódó üzleti folyamatok automatizálása;
• Optimalizálja az elosztott részlegek közötti interakciót;
• Az adatok azonnali frissítése a különböző osztályok szakembereinek munkájához;
• "elhatárolás" különböző típusok könyvelés.*

* Abban az esetben, ha az egyik számviteli típus adatai jelentősen eltérnek a másiktól, biztosítani kell az információk bizalmas kezelését és „behatárolását” információáramlások. Például az 1C UT és az 1C Accounting közötti adatcsere nem igényli a kezelési adatok feltöltését a hatósági számviteli adatbázisba, pl. a szinkronizálás az 1C-ben itt nem lesz teljes.

Ha az elsődleges adatcsere megvalósításának standard folyamatát képviseljük, amikor annak legalább egy objektuma 1C termék, akkor a következő szakaszok különböztethetők meg:

• A csere összetételének koordinálása;
• A szállítás meghatározása (csereprotokollok);
• Szabályok felállítása;
• Ütemezés.

A csere összetételének azonosítása 1C

Az Exchange objektumok feltételesen feloszthatók "forrásra" és "vevőre". Ugyanakkor egyszerre két szerepet is betölthetnek, amit kétirányú cserének neveznek. A forrás és a rendeltetési hely meghatározása logikus módon történik, igénytől vagy igénytől függően funkcionalitás rendszerek.*

*Például a WA: Financier, az 1C:Enterprise alapján kifejlesztett pénzügyi elszámolási és pénztári folyamatok menedzselésére szolgáló megoldás integrálásakor a WiseAdvice szakemberei mesterrendszerként ajánlják. Ez annak köszönhető, hogy az alkalmazási szabályzat szabályainak betartását, és ennek megfelelően a megoldás hatékonyságát biztosító vezérlőeszközök rendelkezésre állnak.

Továbbá a felhasználóktól kapott és rögzített igények alapján elkészítik a cserére szánt adatok listáját, meghatározzák azok mennyiségét, az adatcsere gyakoriságára vonatkozó követelményeket, előírják a hibákkal való munkavégzés és a rendkívüli helyzetek (ütközés) kezelésének folyamatát.

Ugyanebben a szakaszban, a meglévő rendszerek flottájától és a vállalat felépítésétől függően, meghatározzák a csereformátumot:

Elosztott információs bázis

• A RIB cserét jelent az azonos 1C adatbázis-konfigurációk között, világos master-slave vezérlőstruktúrával minden cserepárhoz. A technológiai platform egyik elemeként a RIB az adatokon túl az adatbázis konfigurációjában és adminisztratív információiban bekövetkezett változásokat is át tudja vinni (de csak a mastertől a slave-ig).

Univerzális adatcsere 1C-ben

• Egy olyan mechanizmus, amely lehetővé teszi az 1C adatbázisok cseréjének konfigurálását, mind az 1C:Enterprise platform konfigurációival, mind harmadik féltől származó rendszerekkel. A csere az adatok univerzális xml formátumba történő átvitelével történik a „Cseretervek” szerint.

EnterpriseData

• Az 1C cég legújabb fejlesztése, amelyet az adatcsere megvalósítására terveztek xml formátumban az 1C:Enterprise platformon létrehozott termékek között bármilyen automatizálási rendszerrel. Az EnterpriseData használata leegyszerűsíti a cserével kapcsolatos fejlesztéseket. Korábban, amikor egy új konfiguráció került be a rendszerbe, szükséges volt egy adatimportálási és -exportálási mechanizmus megvalósítása, mind az adatokhoz, mind a meglévő rendszerekhez. Mostantól az EnterpriseData-t támogató rendszereket nem kell módosítani, csak egy belépési-kilépési pontjuk van.

A szállítás meghatározása (csereprotokollok)

Az 1C:Enterprise 8 platformon alapuló rendszer esetén széleskörű lehetőség csereszervezésre bármely információs forrásokáltalánosan elfogadott univerzális szabványokon (xml, szöveges fájlok, Excel, ADO kapcsolat stb.). Ezért az adatcsere szállításának meghatározásakor egy harmadik féltől származó rendszer adatbázisának képességeiből kell kiindulni.

Könyvtárak szinkronizálása

A hatékony címtár-szinkronizálás fő elve egy belépési pont jelenléte. De ha beszélgetünk Ha olyan könyvtárakkal dolgozunk, amelyeket korábban különböző szabályok szerint töltöttek ki, akkor egyértelműen meg kell határozni a szinkronizálási mezőket, hogy a csere „közös nevezőre” kerüljön.*

*Ebben a szakaszban szükség lehet a referenciaadatok normalizálására az adatforrás oldalán. A könyvtárak állapotától és mennyiségüktől függően az elemek összehasonlítása, a hibák és ismétlődések felismerése, azonosítása, valamint a hiányzó mezők kitöltése és a szinkronizálási mezők hozzárendelése egy egész szakértői csoport munkáját igényelheti, mind a az integrátor (a referenciaadat-normalizációs módszertan tulajdonosa) és az ügyfél oldaláról.

Szabályok felállítása

A forrásrendszerekből származó adatok vevőben való megjelenítésének képessége a megfelelően meghatározott csereszabályoktól függ. Az xml formátumban bemutatott szabályok szabályozzák a forrás-cél objektumok kulcsattribútumainak megfelelését. Az 1C: Data Conversion megoldást úgy tervezték, hogy automatizálja a szabályok létrehozását mind az egyszeri, mind az állandó csere végrehajtásához.

Biztosítja az adatvesztést az Exchange Exchange-terv során. Ez az 1C:Enterprise platform bármely konfigurációjának szerves része, amely teljes mértékben leírja az 1C cserefolyamatot: adatösszetétel ("azonosító" részleteket tartalmazó dokumentumok) és csomópontok ( információs bázisok vevők-adók), valamint a RIB aktiválása a kiválasztott csereirányokhoz.

A Cseretervbe bevitt adatok bármely változása rögzítésre kerül, és a „változás” jelet kapja. Amíg a vevő-adó csomópontokban a megváltozott adatok nem egyeznek meg egymással, addig a jelző nem nullázódik, és a rendszer mindkét csomópontnak vezérlőüzenetet küld. Az adatok eltávolítása és mindkét rendszerben való teljes megfelelőségük megerősítése után a jel visszaáll.

Csere menetrend 1C-ben

A rendszeres adatcsere automatizálása érdekében be van állítva az adatfeltöltés gyakorisága. A csere gyakorisága az igénytől és a technikai lehetőségektől függ. Ezenkívül az 1C:Enterprise platform konfigurációi lehetővé teszik az adatcsere konfigurálását esemény bekövetkeztekor.

Figyelembe véve a csere végrehajtásának szokásos folyamatát, figyeljünk azokra a tényezőkre, amelyek különböző szakaszokban fejlesztést igényelnek:

• Nem szabványos, erősen módosított adatbázis-konfigurációk;
• különböző verziók 1C: Vállalati platformok;
• Hosszú ideig nem frissítették, a konfiguráció nem naprakész verziói;
• A korábban módosított objektumok cseréje;
• Nem szabványos csereszabályok szükségessége;
• Nagyon eltérő készlet és összetétel a rendelkezésre álló könyvtárakban.

Mivel az elsődleges adatcsere végrehajtásához szükséges szabványos műveletek is szakértői ismereteket igényelnek, ajánlatos ezeket az 1C szakemberek részvételével végrehajtani. Csak a fenti lépések végrehajtása után folytassa a csere beállításával a konfigurációban. Fontolja meg az adatbázisok integrációját az "1C: UPP" és az "1C: Retail" példáján (ugyanannak a sémának megfelelően az "1C: UT"-vel való csere van konfigurálva). A tipikus szinkronizálás magában foglalja az SCP - SCP cseréjét is, amely jellemző a legnagyobb ipari vállalatok nagyméretű automatizálási rendszereire.

A „Szolgáltatás” almenüben válassza az „Adatcsere a platformon lévő termékekkel...” lehetőséget (a „Kiskereskedelem” közvetlen cseréjének kiválasztása gyakran COM-objektumok szintű hibákkal fenyeget). Figyeld a hivatalos üzenetet" Ez a lehetőség nem érhető el."

A probléma megoldásához válassza az "Adatmegosztási beállítások" lehetőséget.

...és jelölje be a négyzetet. Továbbá a hibaüzenetet figyelmen kívül hagyja.

Az adatszinkronizálási beállításoknál válassza a "Csere létrehozása a" Kiskereskedelem" elemet...

Mielőtt helyi vagy hálózati címtáron keresztül konfigurálja a csatlakozási beállításokat, győződjön meg arról, hogy a lemezen van hely a könyvtár számára. Bár általában nem igényel többet 30-50 MB-nál, kivételes esetekben akár 600 MB-ot is igényelhet. A szükséges könyvtárat közvetlenül a konfigurátorból hozhatja létre.

Ha az ajánlat hálózati címtárán keresztül csatlakozik, konfigurálja a kapcsolatot az FTP-cím és a email figyelmen kívül hagyja a "Tovább" gombra kattintva.

A beállításokban kézzel írja le az előtagokat - az adatbázisok szimbólumait (általában BP, UPP, RO), állítsa be a szabályokat és az adatok feltöltésének kezdő dátumát. Az előtag a dokumentumok címében jelenik meg, jelezve, hogy milyen alapon készültek. Ha a feltöltési szabályok nincsenek szerkesztve, az alapértelmezett adatok az összes elérhető paraméternek megfelelően kerülnek feltöltésre.

Létrehozunk egy cserebeállítási fájlt a Retail számára, hogy ne ismételjük meg tevékenységeinket. Ha a szinkronizálás beállítása után azonnal adatokat kell küldenie, jelölje be a négyzetet.

A cserefolyamat automatizálásához ütemezést kell beállítani.

Kiskereskedelmi menü.

Jelölje be a négyzetet, és válassza a Szinkronizálás lehetőséget.

A „fordított” beállítást a Gyártó vállalat kezelése lehetőség kiválasztásával végezzük.

Töltse be a fájlt az SCP-ben létrehozott beállításokkal.

Kipipáljuk, a rendszer automatikusan felveszi a címet.

Ugyanúgy járunk el, mint az UPP-ben.

Az adatok ellenőrző összehasonlítása (Az adatok kézi összehasonlítását javasolt az előkészítő szakaszban elvégezni, mivel ez a munka a legidőigényesebbé válhat a csere megvalósításának folyamatában). Az összehasonlító ablak az egér dupla kattintásával nyílik meg.

Szinkronizálási hiba esetén a „Részletek…” helyére „Soha…” lép.

A „Részletek…” megnyitja a regisztrációs naplót a tőzsdére vonatkozó frissített információkkal.

Kész.