Példa objektumkonverziós szabályra. Példa az objektumok átalakítására vonatkozó szabályra Tipikus adatátviteli szabályok 1c

Az évek kemény munkája során összegyűjtött adatok és fontos dokumentumok nem veszhetnek el csak azért, mert egy újabb platform vagy 1C konfiguráció jelent meg. Ennek elkerülése érdekében lehetőség van adatátvitelre.

Az adatok átvitele az egyik legkritikusabb része az egyik konfigurációról a másikra való átmenetnek.

Annak érdekében, hogy az adatok biztonságosan és megbízhatóan továbbíthatók legyenek, ezt a munkát szakemberekre kell bízni. Csapatunk minden munkát minőségileg és határidőre elvégez.

A migráció lépései

Az adatátvitel 5 szakaszból áll. Igyekeztünk a lehető legrészletesebben és legvilágosabban leírni őket.

Miért jobb az adatátvitelünk?

Egy tipikus adatátvitel költsége

Az új program karbantartása

Az összes adat átvitele után szükség lehet a program karbantartására. Készen állunk, hogy Ön rendelkezésére bocsássuk!

Áttérés 1C-re 8.2

Részletek az egyik platformról a másikra való átmenet egyéb szakaszairól. Licenc frissítés, konfiguráció, képzés, támogatás. Szakértőink készséggel állnak az Ön rendelkezésére minden szükséges segítséget!

Miért vagyunk jobbak?

Megrendelés átadása

Csapatunk

Miért jobb az 1C átvitelünk?

Átláthatóság

Az 1C 8.2 címtárak és egyéb adatok átvitele előtt szakembereink részletesen tájékoztatják Önt a munka minden szakaszáról. Ha ránk bízza bázisát, mindig tudja, hogy mi történik, milyen sorrendben, és mennyit fizet az egyes munkafázisokért.

Egyéni megközelítés

Mielőtt közvetlenül az 1C 7.7-ről az 1C 8.2-re költözne, szakembereink mélyreható elemzést végeznek az adatbázisban. Nagy a valószínűsége annak, hogy be új verzió Az 1C már rendelkezik minden szükséges fejlesztéssel. Mindenesetre ajánljuk, mire lehet még szüksége a kényelmes munkához.

Minőség

Az átvitel legdöntőbb szakasza előtt szakembereink mindig végrehajtják az 1C adatbázisok próbaátvitelét, hogy azonosítsák lehetséges hibákat, ismétlés és adatvesztés. De még maga az átadás után is mindenképp ellenőrizni fogunk mindent, hogy még biztosabbak lehessünk a minőségében.

Dolgozz az eredményért

A munka csak akkor tekinthető befejezettnek, ha megbizonyosodott arról, hogy az 1C 8 könyvtárak és egyéb adatok átvitele megfelelően megtörtént, és Ön elégedett az eredménnyel. Nem hagyjuk el ügyfeleinket!

1. szakasz. A forrásadatbázis általános elemzése

Milyen munkát végeznek:

a forrásadatbázishoz hasonló verzió tipikus konfigurációjának beszerzése;

az adatstruktúra változásainak általános elemzése (összehasonlítás egy tipikus konfigurációval);

a konfigurációs formák és modulok változásainak általános elemzése (összehasonlítás egy tipikus konfigurációval);

nem szabványos számviteli számlák jelenlétének ellenőrzése a számviteli konfigurációkhoz;

az elszámolás helyességének általános ellenőrzése a forrásadatbázisban ("piros" egyenlegek, le nem zárt időszakok, vissza nem térített sorozatok stb.);

a forrásadatbázis frissítése a szabványos migrációs szabályok által megkövetelt verzióra;

próba adatátvitel;

lehetséges ajánlások elkészítése az 1C 8 címtárak és egyéb adatok átviteléhez szükséges forrásbázis elkészítéséhez.

Miért:

tipikus transzfer alkalmazási lehetőségének meghatározása;

a fejlesztések összetettségének felmérése és az átadáshoz szükséges műszaki dokumentáció elkészítése (ha nem lehetséges tipikus átadás alkalmazása).

A forrásbázis általános elemzése után megerősítést nyerhetünk, hogy az adatok szabványos úton továbbíthatók, ebben az esetben az átviteli szolgáltatás további költsége egy tipikus átutalás árlistája szerint kerül meghatározásra, attól függően, hogy konfigurációt.

Ha a megfelelő tipikus átadás nem lehetséges, akkor ajánlatot készítünk a konfigurációk véglegesítésének, a csereszabályoknak és a nem szabványos átutalásnak a munka költségével.

Ár: 2000 rubel

2. szakasz Műszaki dokumentáció elkészítése nem szabványos átadáshoz

Milyen munkát végeznek:

elvégzik a forrásbázis szabványos konfigurációjának meglévő módosításainak mélyreható elemzését, összehasonlítják ezeket a módosításokat egy tipikus, hasonló verziójú konfigurációval és a vevőbázis szabványos konfigurációjának friss verziójával;

kommunikáció a Megrendelő felelőseivel az azonosított fejlesztések szükségességének megállapítása, a fejlesztések felhasználási módjainak tisztázása, a fejlesztések javítására vonatkozó javaslatok összegyűjtése (szükség esetén);

összeállítják a forrásbázis szabványos konfigurációjának elérhető fejlesztéseinek listáját;

összeállítják és megállapodnak a vevőbázis szabványos konfigurációjának javasolt fejlesztéseinek listája, figyelembe véve a tipikus konfiguráció szabványos funkcionalitását (talán nem kell átvinni a revíziót, ha a vevőkonfiguráció már rendelkezik hasonló szabványos funkcióval );

projekt kidolgozása és jóváhagyása megtörtént feladatmeghatározás a fogadó bázis konfigurációjának véglegesítéséhez, a csereszabályok véglegesítéséhez, leírása
nem szabványos átviteli eljárások (ha szükséges).

Miért:

az 1C adatbázisok nem szabványos átvitelével kapcsolatos munka minőségének és átláthatóságának garantálása;

pontos költségbecslés és a munka időtartama;

a migrációs munka elvégzésének képessége teljes munkaidős 1C programozó bevonásával, a szükséges minőségi szinten.

Ha a megadott műszaki dokumentációkészlet nem áll rendelkezésre, az 1C konfigurációk közötti nem szabványos átvitel csak óránként történik. Ebben az esetben lehetetlen előre pontosan garantálni a munka költségét és időtartamát. Ebben az esetben azonban némi idő- és költségmegtakarítás lehetséges a dokumentációs csomag elkészítéséhez.

Ár: A forrásbázis általános elemzésének eredménye alapján kerül meghatározásra.

3. szakasz. A vevő konfigurációjának véglegesítése

Milyen munkát végeznek:

a vevőbázis szabványos konfigurációja a műszaki előírások alapján, vagy a Megrendelő utasításai szerint (óramunka esetén) véglegesítés alatt áll;

elvégzik a fejlesztések előzetes tesztelését;

a fejlesztéseket egy tipikus konfiguráció változásairól szóló jelentés formájában dokumentálják (a szervizmérnök általi további frissítés lehetőségéhez);

a fejlesztések bemutatása a felhasználó számára (munkák átadása és átvétele);

a módosításokhoz felhasználói kézikönyv készül (ha szükséges).

Miért:

kapsz legújabb verzió konfigurációk a szükséges változtatásokkal;

Dokumentációt kap a további szükséges fejlesztésekről
szervizmérnök frissítései.

4. szakasz. Az átigazolási szabályok véglegesítése

Milyen munkát végeznek:

az 1C szabványos átviteli szabályait véglegesítik, hogy figyelembe vegyék a forrásbázis szabványos konfigurációjának adatszerkezetében bekövetkezett változásokat, valamint a forrásbázisban használt nem szabványos számviteli számlákat;

a változások figyelembevételével elvégzik az átadás előzetes tesztelését.

Miért:

Biztosítja azon adatok helyes továbbítását, amelyeket nem a szabványos csereszabályok továbbítanak;

Az átviteli szabályok finomítására akkor is szükség lehet, ha a forrásadatbázisban a könyvelés a standard megoldási módszertan szempontjából helytelenül történt, bár a forráskonfiguráció esetleg nem tartalmaz fejlesztéseket.

Ár: műszaki dokumentáció alapján alakul ki.

5. szakasz. Adatátvitel

Milyen munkát végeznek:

referencia információ átadása (összesen vagy linkekkel), egyenlegek átutalása egy adott napon;

az átvitel helyességének ellenőrzése - a forrásbázis és a célbázis adatainak összehasonlítása;

lehetséges ajánlások elkészítése a fogadó adatbázis egyenlegeinek korrekciójára, figyelembe véve a különböző konfigurációkban történő elszámolás sajátosságait (szükség esetén).

Miért:

Készülj az indulásra új alap adatokat az aktuális egyenlegével.

Az átutalás az 1C által kidolgozott átutalási szabályok szerint, kifejezetten az Ügyfél számára készített fejlesztések felhasználásával történik. Az átvitt adatok összetétele a konfigurációs verziókonként eltérő lehet, szakembereink tanácsot adnak a lehetséges lehetőségekről
átviteli funkciók.

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ás formájában vannak további beállítások, ahol engedélyezhetjük vagy letilthatjuk a regiszterek és mozgások kirakásának lehetőségét 1C-ben. 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 megjelenik egy párbeszédpanel, ahol ismét elutasítjuk automatikus létrehozás PKS (Property Conversion Rules). 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. 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. 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.

közötti adatmigráció különféle konfigurációk 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ó (ez tisztán az 1C cég termékeiről van szó) tegnap fel sem merült. Az 1C cég jól ismeri azokat a nehézségeket, amelyekkel a fejlesztők szembesülnek az áttelepítések létrehozásakor, ezért igyekszik minden tőle telhetőt eszközzel segíteni.

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. Ezek be vannak építve minden szabványos megoldásba és a közötti migráció problémájába azonos konfigurációká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 skálája lehetővé teszi a fejlesztők számára, hogy önállóan válasszák ki a probléma megoldásának legjobb módját.

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

• 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 bőbeszédűsé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 karbantartás bonyolultsága és magas költsége arra késztette az 1C vállalatot, hogy univerzális megoldást hozzon létre. Technológia, amely lehetővé teszi, hogy a lehető legnagyobb mértékben leegyszerűsítse a migráció fejlesztését és támogatását. Ennek eredményeként az ötletet egy külön konfiguráció - „Adatkonverzió” - formájában valósították meg.

Adatkonverzió - standard megoldás, önkonfigurálás. Bármely ITS:Prof előfizetéssel rendelkező felhasználó teljesen ingyenesen letöltheti ezt a csomagot a felhasználói támogatási oldalró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 legfontosabbal - a sokoldalúsággal. A megoldás nem szabott bizonyos platformkonfigurációkhoz/verziókhoz. Egyformán jól működik mind a szabványos konfigurációkkal, mind a saját maga által írt konfigurációkkal. A fejlesztők univerzális technológiát és szabványosított megközelítést kapnak az új migrációk 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 merész plusz a vizuális segédeszkö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 egyszer a technológia elsajátítására, majd ismételten felhasználni a felbecsülhetetlen értékű készségeket.

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 az információs bázissal (COM/OLE).

Építészet tanulása

Azt már tudjuk, hogy az adatkonverzió csodákra képes, de még nem világos, hogy mik a technikai előnyei. Az első dolog, amit meg kell tanulni, hogy minden adatmigráció (konverzió) csereszabályokon alapul. Exchange-szabályok - egy normál xml-fájl, amely leírja azt a struktúrát, amelybe az adatokat feltölti az IB-ből. Az adatfeltöltést/letöltést végző szolgáltatás-feldolgozás elemzi a csereszabályokat, és azok alapján végzi el a feltöltést. A letöltés során fordított folyamat történik.

A „KD” konfiguráció egyfajta vizuális konstruktor, amellyel a fejlesztő csereszabályokat hoz létre. Nem tudja, hogyan kell adatokat feltölteni. A CD-elosztó készletben 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 az infobase szerkezet leírásának feltöltését egy xml fájlba. A struktúra leírása betöltődik a CD-re további elemzés és csereszabályok létrehozása céljából.
• V8ExchanXX.epf- a csereszabályoknak megfelelően adatokat tölt fel/letölt az infobázisból. 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 az új konverzió fejlesztésének szakaszait:

1. 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 átvinni.
2. Konfigurációs struktúrák leírásának elkészítése (Forrás/Receiver) a későbbi CD-re való betöltéshez. A feladat megoldása az MDXXExp.epf szolgáltatásfeldolgozással történik.
3. Készített szerkezetleírások betöltése IS-be.
4. Csereszabályok létrehozása CD vizuális eszközeivel.
5. Feltöltés/letöltés 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 demonstrációhoz két telepített konfigurációra van szükségünk. Úgy döntöttem, megállok a lehetőségnél: „Trade Management” 10. kiadás és egy kis saját írású megoldás. A feladat az adatok átvitele lesz a tipikus UT konfigurációból. A rövidség kedvéért a saját kezűleg írt megoldást „Receiver”-nek, a kereskedelemmenedzsmentet „Forrásnak” nevezzük. Kezdjük a probléma megoldását a "Nómenklatúra" könyvtár elemeinek átvitelével.

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

A feldolgozó felület nem ragyog a rengeteg beállítástól. A felhasználónak csak meg kell adnia azokat a metaadat-objektumokat, amelyek nem tartoznak bele a struktúra leírásába. 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 a halmozási regiszterekben (példaként).

Helyesebb a mozgást a dokumentumok fogadóba tartása közben kialakítani. Az átvitel után minden mozgást maga a dokumentum hajt végre. A második érv az alapértelmezett beállítások védelmében a feltöltött fájl méretének csökkentése.

Egyes dokumentumok (különösen a tipikus konfigurációkban) több regiszterben mozgatnak. Mindezen gazdálkodás kirakodása meghozza az eredményt XML fájl túl nagy. 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 véletlen hozzáférésű memória feldolgozásához. Gyakorlásom során véletlenül illetlenül nagy feltöltési fájlokkal találkoztam. Az ilyen fájlok teljesen elutasítottá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. Ugyanezt az eljárást megismételjük a második alappal.

Nyissa meg a CD-t, és válassza ki a főmenüből "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 nyomja meg a „ Hozzáadás” és a megjelenő ablakban válasszon ki egy fájlt a konfiguráció leírásával. Jelölje be a „Feltöltés ide új konfiguráció” és kattintson a „Letöltés” ​​gombra. Hasonló műveleteket hajtunk végre a második konfiguráció felépítésének leírásával.

Most már minden készen áll a csereszabályok létrehozására. A CD főmenüjében válassza a „Referenciák” -> „Konverziók” menüpontot. Hozzáadás új elem. Az új konverzió létrehozására szolgáló ablakban meg kell adnia: a forrás konfigurációját (válassza ki az UT-t) és a vevő konfigurációját (válassza a "Vevő" lehetőséget). 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ájlnév bármikor megváltoztatható, de a legjobb, ha most beállítja. Ezzel időt takaríthat meg a jövőben. A demó szabályait elneveztem: "rules-ut-to-priemnik.xml".
• name - a konverzió 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, amely arra kér bennünket, hogy hozzuk létre az összes szabályt automatikusan. Egy ilyen csábító ajánlat elfogadása azt a parancsot kapja a mesternek, hogy automatikusan elemezze a kiválasztott konfigurációk leírását, és önállóan generálja a csereszabályokat.

Azonnal pontozzuk az "és"-et. A mester nem lesz képes semmi komolyat generálni. Ezt a lehetőséget azonban nem szabad figyelmen kívül hagyni. Ha cserét kell létrehoznia az azonos konfigurációk között, akkor egy varázsló szolgáltatásai nagyon hasznosak lesznek. Példánkban a kézi üzemmód előnyösebb.

Nézzük meg közelebbről az „Exchange szabályok beállításai” ablakot. A felület kissé zavarónak tűnhet - nagyszámú vezérlőkkel tömött lapok. Valójában minden nem olyan nehéz, néhány óra alkalmazás 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”. Az elsőnél egyezési szabályokat kell felállítani, pl. Hasonlítsa össze két konfiguráció objektumát. A másodiknál ​​határozza meg a lehetséges objektumokat, amelyek a felhasználó rendelkezésére állnak a kirakodáshoz.

Az „Objektumkonverziós szabályok” lap második felében egy további panel található két lappal: „Tulajdonkonverzió” és „ Értékátalakítás". Az első a kiválasztott objektum tulajdonságait (rekvizitjait), a második pedig az előre meghatározott értékekkel való munkához szükséges (pl. előre meghatározott elemek könyvtárak vagy felsorolási elemek).

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ó varázslót (kattintson a "" gombra), vagy manuálisan adjon hozzá egyezéseket az egyes objektumokhoz.

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

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

Ezt a hibát magunk is kijavíthatjuk. Keresse meg az ablakban Objektumleképezések» kézikönyv « Ügyfelek”, és a „Forrás” oszlopban válassza ki a „Counterparts” referenciakönyvet. Ezután jelölje be a "Típus" oszlopban található négyzetet, és kattintson az "OK" gombra.

Az Objektumszinkronizálás varázsló felkéri, hogy automatikusan hozzon létre szabályokat az összes kiválasztott objektum tulajdonságainak konvertálásához. Az ingatlanok névvel lesznek párosítva, és a bemutatónkhoz ez bőven elég lesz, egyetértünk. A következő kérdés a feltöltési szabályok létrehozására vonatkozó javaslat lesz. egyezzünk bele.

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

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

Miután az adatok fájlba feltöltésének folyamata befejeződött, lépjen az IB " Vevő". A feldolgozást is megnyitjuk benne V8Exchan82.epf, ezúttal csak az „Adatok betöltése” fülre lépünk. Válassza ki az adatfájlt, és kattintson a "Feltöltés" gombra. Minden, az adatok átvitele sikeresen megtörtént.

Feladatok a való világból

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

Hogy ne csalódjak a technikában, elkészítettem néhány valós feladatot. Munka közben biztosan találkozni fogsz velük. Nem tűnnek olyan triviálisnak, és új szemszögből nézik az adatátalakítást. Gondosan fontolja meg a bemutatott példákat, és bátran használja őket 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őegységnek van ehhez hasonló „Clients” kézikönyve. 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 (az azonos nevű konstansból szerezhető be).

A problémára többféle megoldás is létezik. Megfontoljuk a kellékek kitöltésének lehetőségét " Szervezet"közvetlenül a bázisban" Vevő”, azaz. az adatok betöltésekor. Az aktuális szervezet konstansban van tárolva, így nincs akadálya ennek az értéknek a megszerzésének. Nyissuk meg az objektumkonverziós szabályt (a továbbiakban: FRP) Ü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 Betöltés után”.

Leírjuk az aktuális szervezet lekéréséhez szükséges kódot az attribútumhoz való későbbi hozzárendeléssel. Abban a pillanatban, amikor a „Betöltés után” kezelő aktiválódik, az objektum teljesen formálva lesz, de még nincs beírva 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;

A kellékek kitöltése előtt " Szervezet» ellenőrizni kell az attribútum értékét « Ez a csoport". az útmutatónak" Ügyfelek» a hierarchikus zászló be van állítva, ezért szükséges egy csoport ellenőrzése. Hasonlóképpen minden részlet kitöltése megtörténik. Feltétlenül olvassa el a súgót a kezelő egyéb lehetőségeiről " AfterLoading". Például van köztük egy paraméter " Elutasítás". Ha „True” értéket kap, akkor az objektum nem kerül beírásra az adatbázisba. Így lehetővé válik az objektumok korlátozása az írásra a betöltéskor.

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

A kézikönyvben" Ügyfelek"UT konfiguráció, vannak részletek" Vevő"És" Szolgáltató". Mindkét kellék "típusú" logikai érték” és a szerződő fél típusának meghatározására szolgálnak. IB-ben" Vevő”, a kézikönyvben „ Ügyfelek"Nincsenek hasonló adatok, de van információs nyilvántartás" Ügyfelek típusai". Hasonló funkciót lát el, és több címkét is képes tárolni egyetlen ügyfélhez. Feladatunk az adatok értékeinek átvitele az információs nyilvántartás különálló nyilvántartásaiba.

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

A következő lépés a feltöltési szabályok létrehozása. Lépjen a megfelelő lapra, é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 „Ügyféltípusok” információs nyilvántartást;
• A szabály kódja (név). Ezt úgy írjuk, hogy „Client fajok feltöltése”;

Most meg kell írnia a kódot a feltöltéshez szükséges adatok kiválasztásához. Itt a paraméter " Adatmintavétel". Ebben elhelyezhetünk egy gyűjteményt egy előkészített adatsorral. Paraméter " Adatmintavétel” különböző é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.

Alul látható 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 odafigyelni a „ oszlop kitöltésére Ügyfél típusa". Az „UT”-ban „boolean” típusú jellemzőink vannak, a címzettben pedig egy felsorolás.

Jelenleg nem tudjuk őket a kívánt típusra hozni (nem az UT-ban van), ezért egyelőre sztringek formájában hagyjuk. Ezt nem kell megtenned, de azonnal meg akarom mutatni, hogyan kell a forrásban hiányzó típusra leadni.

DataFetch = NewValueTable(); Data Selection.Columns.Add("Kliens"); Data Selection.Columns.Add("ClientType"); DataFrom kiválasztása a könyvtárból = Directories.Contractors.Select(); While Fetching DataFromCatalog.Next() Loop If FetchingDataFromCatalog.ThisGroup then Continue; EndIf; Ha DataFetchFromCatalog.Buyer akkor NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "Vevő"; EndIf; Ha DataFetchFromCatalog.Provider Then NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "Beszállító"; EndIf; EndCycle;

Mentse el az adatfeltöltési szabályt, és térjen vissza a „ Objektumkonverziós szabályok". Tegyük hozzá az információs nyilvántartáshoz „ Ügyfelek típusai” tulajdonság átalakítási szabályok: kliens és ügyféltípus. A forrást üresen hagyjuk, és a „Kirakás előtt” eseménykezelőben ezt írjuk:

//Az "Ügyfél" tulajdonsághoz Value = Source.Client; //A „CustomerType” tulajdonsághoz If Source.Customer = "Buyer" Then Expression = "Enumerations.CustomerTypes.Buyer" ElseIf Source.Customer = "Supplier" Then Expression = "Enumerations.CustomerTypes.Supplier"; EndIf;

A kiírásban az adatok az elvégzett adatkiválasztás alapján kerülnek kitöltésre. Egyszerűen linkként adjuk át az ügyfelet, és a "" paraméterbe írjuk be az ügyfél típusát. Kifejezés". Ennek a paraméternek az adatai a vevőben lesznek értelmezve, és végrehajtásukkor az attribútum a felsorolásból a megfelelő értékkel kerül kitöltésre.

Ennyi, készen vannak a csereszabályok A vizsgált példa elég univerzálisnak bizonyult. Hasonló megközelítést gyakran alkalmaznak a 7.7-es platformon létrehozott konfigurációkból származó adatok átvitelekor. Ennek frappáns példája az időszakos részletek átadása.

3. számú feladat. Táblázatos trükkök

Gyakran vannak olyan feladatok, amelyeknél egy táblázatos rész sorait több sorba kell feladni. Például a kezdeti konfigurációban a szolgáltatások és az áruk egy táblázatos szakaszban vannak nyilvántartva, míg ezeknek az entitásoknak a tárolása a vevőben el van különítve. A probléma ismételten nem oldható meg vizuális eszközökkel. Itt célszerű a második probléma megoldását alapul venni.

Készítünk egy adatfeltöltési szabályt, adunk meg egy tetszőleges algoritmust, és írunk egy lekérdezést a „Feltöltés előtt” kezelőben, hogy adatokat kapjunk a táblázatos részből.

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

DataFetch = NewValueTable(); //Itt lesz még egy táblázatos rész Data Selection.Columns.Add("Termékek"); //Itt lesz egy táblázatos rész is Data Selection.Columns.Add("Szolgáltatások"); Data from.Columns.Add("Link") kiválasztása;

4. számú feladat. Adatok átvitele műveletbe

Ha egy szervezet több könyvelési rendszert használ, akkor előbb-utóbb szükség lesz adatmigrációra, majd a könyvelések kialakítására.

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

Az ilyen átalakításra példa a cikk forráskódjában található. A kód mennyisége elég nagynak bizonyult, így nincs értelme közzétenni a cikkhez. Csak annyit mondok, hogy a feltöltés ismét egy tetszőleges algoritmust használ az adatfeltöltési szabályokban.

5. számú feladat. Adatok szinkronizálása több attribútum között

Néhány példával már foglalkoztunk, de eddig nem beszéltünk az objektum-szinkronizálásról a migráció során. Képzeljük el, hogy partnereket kell átadnunk, és néhányuk valószínűleg a fogadó adatbázisban van. Hogyan lehet adatokat továbbítani és elkerülni a duplikációkat? 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ézikönyvben " Ügyfelek” nem tartalmazhat két azonos azonosítójú elemet. A CD elvégzi erre a számítást, és az összes létrehozott PSP-nél alapértelmezés szerint azonnal engedélyezve van az azonosító szerinti keresés. A PSP létrehozása során észre kellett volna venni a nagyító ikont az objektum neve mellett.

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

Ilyenkor helyesebb az objektumok több szempont szerinti szinkronizálása. Helyesebb a partnerek keresése TIN, 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őből információs bázisok. Készítsünk elő egy PCP-t, és az objektum konvertálására vonatkozó szabályok beállításainál jelölje be 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 tetszőleges mezők alapján.

Jogunk van a mezőket magunk választani. Miután feljegyeztük a TIN-t, a KPP-t, a nevet, azonnal megjelölünk több keresési feltételt. Kényelmes? Igen, de ez megint nem elég. És mi van, ha meg akarjuk változtatni a keresési feltételeket? Például először keresünk egy csomó TIN + KPP-t, és ha nem találunk semmit, akkor elkezdünk szerencsét próbálni a névvel.

Teljesen lehetséges egy ilyen algoritmus megvalósítása. 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”; ElseIfSearchVariantNumber = 2 ThenSearchPropertyNameString = "Név"; EndIf;

Mindig többféle 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ási utat választani, de ha folyamatosan összetett adatmigrációkat kell fejlesztenie, akkor nyomatékosan javaslom, hogy figyeljen a "" konfigurációra. Hagyja, hogy először erőforrásokat (időt) kell befektetnie a képzésbe, de ezek bőven megtérülnek az első többé-kevésbé komoly projektnél.

Véleményem szerint az 1C cég méltatlanul megkerüli az adatkonverzió használatának témáját. A technológia fennállásának teljes ideje alatt egyetlen könyv jelent meg róla: „1C: Enterprise 8. Data conversion: Exchange alkalmazásmegoldások között”. A könyv meglehetősen régi (2008), de még mindig kívánatos, hogy megismerkedjen vele.

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

» egy univerzális eszköz, de ha az 1C:Enterprise 7.7 platformra kifejlesztett konfigurációkból adatmigrációt kíván létrehozni vele, 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ítani a tanulásra. Az elv többi része ugyanaz marad.

É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
• Hogyan lehet letölteni a modellszabályokat és univerzális formátum csere 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 külső feldolgozásként mentésre kerülnek további felhasználás céljából.

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 feltalál egy biciklit, amikor van kész egyablakos 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ó.

Jelenleg az 1C: Enterprise 7.7-ről 8.3-ra (hasonlóan a 8.2-re) való átállás fejfájást okozott a könyvelőknek. Lehetőleg minél előbb és hibamentesen. Ha Ön 1C: Számviteli programozó, és ezeket a dokumentumokat a hetedik verzióból a nyolcadikba kell konvertálnia, akkor ez a cikk az Ön számára készült.

Csak néhány lépést kell megtennie, és az adatátviteli problémák megoldódnak. Felolvas ezt a kézikönyvet a végéig, és meg fogja találni a módját, hogyan teheti meg. A kezdéshez fel kell készülnie munkahely számítógépén a szükséges manipulációkhoz. Először is a tiéd HDD legalább 100 GB méretűnek kell lennie. Erre azért van szükség, mert az egyenlegek átadása többszintű. És több 7.7-es konfigurációval kell dolgoznia.

Ha gyors és minőségi átállásra van szüksége az 1C Accounting 7.7-ről az 1C 8.3-ra, forduljon hozzánk! A kulcsrakész átállás átlagos költsége 6600 rubel.

Adatátvitel 1C 7.7-ből 1C 8.3 számvitel 3.0

Tehát, mielőtt az adatok 1C 8.3-as verziójába történő átvitelével foglalkozna, elő kell készítenie ezeket az adatokat a 7.7-es verzióban. Ehhez a következőket kell tennie. Tegyük fel, hogy a számítógépén van egy működő „Vállalkozás könyvelése” adatbázis, amellyel a könyvelői dolgoznak. Az Export77 feldolgozás segítségével töltse fel az összes szükséges dokumentumot egy szöveges fájlba, és attól a pillanattól kezdve ne térjen vissza a fő munkabázisra. A további manipulációk más konfigurációkkal történnek.

Telepítse a friss Release 1C:Enterprise 7.7-et az új könyvtárba. (a csomag tartalmaz egy szabványos üres (adat nélküli) és egy demó verziót). A standard verzióval fogunk dolgozni. Most futtassa ezt az adatbázist, és az Import 77 feldolgozás segítségével töltse be az adatokat a fő adatbázisból egy szöveges fájlból.

Az adatok konvertálásakor előfordulhat, hogy egyes dokumentumok nem kerülnek feladásra. Nem ijesztő. A trükk az, hogy ezt könnyen kijavíthatod az átutalás után, hiszen a standard adatbázisban a fő standard számlatáblázattal dolgozol. Ezért bármennyire is kifinomultak az alszámlák, a működő adatbázisában könnyen kijavítható körülbelül 3 óra alatt úgy, hogy minden fel nem könyvelt dokumentumba bemegy, és módosítja a konfigurációjában lévő fiókokat a fiókmezőkben.

Természetesen előzetesen, az átutalás előtt összhangba hozza a standard konfigurációjú számlatükröt a fő munkabázisa számlatükrével. A lehetőségek tisztán egyéniek, a szervezet sajátosságaitól függően. Miután elvégezte ezt a munkát, egy szabványos konfigurációt kap, amely tele van a munkabázisa adataival.

Most újabb adatátvitelt kell végrehajtanunk. Ehhez telepítse újra a normál nulla konfigurációt egy új könyvtárba. És már ott is továbbíthatja az adatokat a szabványos konfigurációból az Ön adataival, így egy ideális 7-es verziójú adatbázist kap, amely készen áll a 8.2-es verzióra való átvitelre.

Az a tény, hogy az adatok közvetlenül a nyolcadik verzióba kerülnek átvitelre, kizárólag az „érintetlen” szabványos 7.7-es verzióból. És most neked is van ilyen konfigurációd. De most nem üres, hanem a munkaadataiddal.

Minden! Elindítjuk az 1C:Enterprise 8.2-t. Válassza az "Adatátvitel a 7.7-es verzióból" lehetőséget. és élvezze, ahogy a program maga viszi át a feldolgozott 7.7.-ből az adatokat, viszi át a dokumentumokat, és megjeleníti a képernyőn a 7.7 és 8.3 verzió mérlegének összehasonlító táblázatát.

Természetesen 100%-os eredmény nem lesz. De 70-80 százaléknál megkapod a megfelelést. És akkor a munkája csak a 8.3-as verzióban történik.

Az esetleges pontatlanságok könnyen kijavíthatók. Még mindig 3-4 óra. Lépjen a bizonylatnaplóba, és módosítsa a számlákat vagy a mezőket (például "Szerződés" vagy "Fő pénztár"). Attól függ, hogy mekkora a különbség az alap 7.7. szabványtól. Mindezen műveletek eredményeként az Ön 8.3-as verziójú működő konfigurációja ideális formában képes lesz számviteli adatokat kiadni a mérlegen keresztül.

Az átállás után hasznos lesz, ha megtanulja, hogyan dolgozzon új program. Ehhez elkészítettük a Képzés 1C Számvitel 8.3 fejezetet.

Apropó! Ha véglegesíteni kell az 1C programokat, forduljon hozzánk!

Az 1C 7.7 adatbázis átvitele 8.3-ra, hogyan kell csinálni?

Sok általános (és néhány iparág-specifikus) oktális megoldás már rendelkezik beépített migrációs eszközökkel a 7.7-től, vagy további fájlként a sablon telepítési könyvtárában.

Ha saját maga viszi át, akkor az ITS-lemezen (valamint sok helyen az interneten - a Google segít) a "Letöltés innen táblázatos dokumentum”, amely lehetővé teszi tetszőleges táblázatos adatok betöltését könyvtárakba / dokumentumokba / regiszterekbe. Megfelelően magas képzettségi szinttel használhatja a harci tüzérséget - egy speciális "Data Conversion 2" konfigurációt (nem tévesztendő össze a 3-mal).

Meg tudná mondani, miért fordul elő ilyen hiba? Az 1C dokumentációjában mindenki túlságosan zavarosan ír - elvégre fizetést kell kapnia, így egyáltalán nem érti a kézirataikat, a háború és a béke könnyebben jön be, mint az oktatóprogramjaik a távolról sem bonyolult rendszerük működtetéséről.

Maxim Kravchenko, hát minden oroszul van írva 🙂

Tapasztalataim szerint a leggyakoribb okok a következők:

1) A 7.7-től kezdődő Exchange beállításaiban rossz elérési út van megadva. Vagy csak elírási hibák vannak, vagy rossz könyvtár elérési útja van megadva. Vagy egy helyi elérési út van megadva a számítógépén, és a csere az 1C vállalat szerver oldalán történik, és ez a szerver természetesen nem lát semmit az Ön útvonalán (gyakori probléma).
2) A számítógép azon oldalán, amely 7.7-tel próbál cserélni (helyi vagy szerver), nincs teljesen telepített 7.7-es platform. Azok. nincs regisztrált COM-objektum, és a 7.7-es alaphoz hagyományosan egy kompromittált platformú könyvtár használatával csatlakoztak, amelyhez nincs szükség sem kulcsra, sem rendszeradatokra.
3) A 7.7-es alapkönyvtárhoz nincsenek hozzáférési jogok (különösen fontos, ha olyan kiszolgálón dolgozik, ahol az rphost munkafolyamat szolgáltatásfelhasználó alatt fut, és a 7.7-es alapkönyvtár meghatározott személyek számára nyitva áll).

Maxim Kravchenko, miért ne az IRC-n keresztül vagy chaten keresztül az emberek "ördög udvaraiban"? 🙂
Nem, többé nem lépek ugyanarra a gereblyére. Már egy hálátlan odaadta a skype-ját és a nyakába ült.

ha van általános kérdéseket, amelyekre adott válaszok segíthetnek másoknak – kérdezz. Tegyünk együtt egy jót. Nincsenek titkos tárgyalások.

P.S. Annak érdekében, hogy az emberek ne veszítsék el a vágyat, hogy válaszoljanak erre a forrásra, érdemes megjelölni a megoldásokat, vagy a "tetszik" gombra kattintani a leginkább releváns válaszoknál, még akkor is, ha azok közvetlenül nem segítettek.

Maxim Kravchenko, a GYIK lehetetlen, mert a tiszta 7.7 nem létezik a természetben. A szabványos/ipari megoldások egész palettája létezik különböző verziók azonos konfigurációjú, de a készlet egyike sem fedezi a vállalatok igényeit, és a telepítés után eladott 7.7 már évek óta elkészült. Figyelembe véve azt a tényt, hogy a 7.7-es tömeges értékesítést több mint tíz éve leállították, az adott adatbázisban nem maradhatott semmi a tipikus funkcionalitásból.

Az egy dolog, ha átveszed a szabványos átviteli mechanizmusokat, amelyekről a válaszomban írtam, és átviszed, felismerve, hogy te vagy a felelős a jambokért, és az összes következetlenséget beülteted a "lányok" javítására. És egészen más dolog pénzért munkára vonzani a szakembert. Le kell írnia az átutaláshoz szükséges összes hivatkozást, az átadandó információ mennyiségét (cikkek, vonalkódok, TIN stb.), honnan szerezheti be a hiányzó információkat stb. Jelenleg nem állok készen arra, hogy elvállaljam a projektjét. Javaslom ezt a feladatot szabadúszó oldalakon regisztrálni, és közöttük pályázatot kiírni.

Átigazolási szabályok 1s 8

Adatátvitel az "1C: Accounting 8 rev. 2.0" programból az "1C: Accounting 8 rev. 3.0" programba

Elsősorban haladó konfigurációkhoz tervezték 1C: Számvitel 8 ed.2.0(lehetséges nevek az interneten: BP 2.0 vagy BP 8.2) a konfigurációra való átvitel eredeti szabályainak kidolgozásának alapjaként 1C: Számvitel 8 ed.3.0(lehetséges nevek az interneten BP 3.0 vagy BP 8.3), természetesen szabványos konfigurációk közötti adatátvitelre is alkalmas.

A lehetséges migrációs stratégiák 2.0-tól 3.0-ig itt találhatók.

Áttérés innen 1C: Számvitel 8 ed.2.0 tovább 1C: Számvitel 8 ed.3.0új időszak (év, negyedév, hónap) elején javasolt teljesíteni az előző időszak ütemezett működésének befejezése után.

Az adatátvitel univerzális feldolgozás segítségével történik, amely az információs bázisból tölti ki az adatokat 1C: Számvitel 8 ed.2.0 egy XML fájlba. Az eredményül kapott fájl feltöltődik az információs bázisba 1C: Számvitel 8 ed.3.0 univerzális adatbetöltési feldolgozás segítségével.

Az adatátvitelhez a következő fájlok szükségesek:

ACC20_30.xml - adatkonverziós szabályok.

Az infobázisból BP 2.0 V BP 3.0áthelyezve:

információ az „1C: Számviteli 8. rev. 2.0” információs adatbázis számviteli számláin lévő folyó egyenlegekről az információs bázis konvertálásának időpontjában

infobázis dokumentumok BP 2.0 a kiválasztott időszakra

szükséges referencia Információk az "1C: Accounting 8 rev.2.0" információs bázisból

- adatok az 1C információs bázisból BP 8.2 külön fájlba (adatfájlba) feltöltve;

- a fogadott fájl betöltődik az 1C információs bázisba BP 8.3.

Telepítés nem szükséges, mivel a tipikus konfigurációkba épített feldolgozást használják, in 1C: Számvitel 8 ed.2.0És 1C: Számvitel 8 ed.3.0.

(A speciális feldolgozás lehetőségéről lásd alább)

Egy programban 1C: Számvitel 8 ed.2.0 meg kell nyitnia a feldolgozást (menü: Szolgáltatás — Egyéb adatcsere), válassza ki az átviteli szabályokat tartalmazó mappát (lásd 1. ábra), és töltse be a csereszabályokat. Azt javaslom, hogy minden alkalommal erőszakkal töltse be a csereszabályokat, még akkor is, ha a feldolgozás kezdetén automatikusan betöltődnek. Ehhez jelölje ki újra a szabályfájlt, vagy kattintson a gombra Olvassa el újra a csereszabályzatot. Nem kell minden szállítási szabályt megadnia. Csak azokat használja, amelyek az egyenlegek és (vagy) dokumentumok átutalásához szükségesek. Az összes könyvtárat szükség szerint linkekkel továbbítják, pl. csak azokat, amelyek részt vesznek az egyenlegekben és a dokumentumokban. Ez biztosítja, hogy ne legyen "szemét" az új információs bázisban.

Ha év végén kell egyenlegeket kirakni, például 2014. december 31-én a nap végén, i.e. helyesebb 2015 elején mondani, akkor a kirakodási időszak 2015.01.01 - XX.XX.XXXX. Az egyenlegek beírásához szükséges dokumentumok BP 3.0 dátuma 2014. december 31. 2015.01.01-től ig BP 3.0 az aktuális műveleteket tükröző dokumentumokat kell létrehoznia. Ha csak maradékra van szüksége, akkor engedélyeznie kell a szakaszból az adatok feltöltésének szabályait Bejövő egyenlegek(lásd 1. ábra). Szabályok adatfeltöltés egy szakaszból Dokumentáció ebben az esetben ki kell kapcsolni (lásd 3. ábra). A kirakodási időszak például 2015.01.01-2015.01.31 a 2015. januári dokumentumok átadását jelenti. Szabályok adatfeltöltés egy szakaszból Dokumentáció ebben az esetben szerepelnie kell.

Rizs. 1 . Adatfeltöltés feldolgozás

Először is javasoljuk a szervezet számviteli politikájának átadását (hivatkozás Szervezetek hivatkozással átvitt). Adatátvitelkor további paramétereket is beállíthat (lásd 2. ábra). Az alapértelmezett értékekhez való visszatéréshez újra kell töltenie a csereszabályokat.

2. ábra Paraméterek beállítása

Paraméter Figyelmen kívül hagyja az áfás tételek nyilvántartását mindenekelőtt meghatározza, hogy ki lesz-e töltve BP 3.0 az egyenlegek megadásakor TMC asztal Adatok a beérkezett számlákról. Ez azt is befolyásolja, hogy az alkonton hogyan lesz kitöltve. a felek: alapján LEHURROGÁS vagy a nyilvántartás többi részével A vásárolt eszközök áfája.

A paraméter beállításával kezelheti a használó szervezetek egyenlegeinek kiürítését USN. Amikor a könyvelés fut, amikor a nyilvántartás adatai nem egyeznek Költségek az egyszerűsített adórendszerben hasznosabb lehet a számviteli regiszter számára, ha csak a számviteli adatok alapján, kis- és nagybetűk megkülönböztetése nélkül rakja ki az egyenlegeket USN, ami sok hibát okozhat. Ebben az esetben a nyitóegyenleg-bevezetési bizonylatokban BP 3.0 kellékek Reflexió az USN-benÉs Fogyasztási állapot tele van alapértelmezett értékekkel.

A paraméter beállításakor Igen az iratokkal egyidejűleg átadásra kerülnek az ezekhez a dokumentumokhoz kapcsolódó nyilvántartási készletek. Ellenkező esetben az iratok tartalma átadásra kerül, és a mozgások átvételéhez a dokumentumokat az adatbázisba kell felvenni. BP 3.0 az átadás után. Meg kell érteni, hogy nem minden országban létező dokumentummozgáshoz BP 8.3, vannak benne egyezések BP 8.2. Ezért még akkor is, ha a bizonylatok mozgással történő átvitelét választja, bizonyos típusú bizonylatokat fel kell könyvelni az összes szükséges főkönyvi készlet létrehozásához.

3. ábra A BP 3.0-ba átvitt dokumentumok listája

Az átvitelhez szükséges információs könyvtárak és regiszterek listája a 4. ábrán látható. Ha valakit érdekel a lista bővítése, forduljon a szerzőhöz. Számos könyvtár esetében vannak szabályok az objektumok átvitelére. Érthető, mert számos dokumentumban sokféle könyvtár található, és ennek megfelelően linkeken keresztül töltődnek le. A kirakodási szabályokat belőlük nem nehéz elkészíteni, megteheti saját maga. A címtár kiürítési szabályra akkor van szükség, ha a teljes címtárat át akarjuk vinni, és nem csak hivatkozásokkal.

Rizs. 4 Az átadandó információk jegyzékeinek és nyilvántartásainak listája

A 76.AB és 76.BA számlák egyenlegének átvezetésének jellemzői

Amikor be van állítva Igen paraméter Korrekt átsorolás a partnerekkel való elszámolásokhoz a könyvelési hibák kijavíthatók. Az 5.1. ábrán jól látható, hogy mihez folyamodik: a partnernél az egyenleg nulla, de a második részkontónál az összegek nem nullák. Az ilyen egyenlegek nem kerülnek átadásra.

5.1. ábra Újraosztályozás a maradékokban

Ha be van állítva Igen paraméter Üzenetek részletesen, akkor a kirakodás során magyarázó üzenetek jelennek meg (lásd 5.2. ábra).

5.2. ábra Üzenetek az átminősítés során a maradékokban

Az áruk és anyagok számviteli számláinak egyenlegátvitelének jellemzői

A hibák kijavítására szolgáló algoritmus, például az egyenlegek igénybevétele által TMC. Ez az algoritmus a paraméter beállításakor működik Javítsa ki az áru- és anyagmaradványok átminősítését jelentésbe Igen. Egy példa látható az 5.3. ábrán. A 10.03 számla elszámolása a nómenklatúra, a raktárak és a tételek összefüggésében történik. A nómenklatúra többi része AI-92 benzin tovább raktár №4 nulla, de ha kötegekkel bővíti az egyenlegeket, sok lesz belőlük. A kötegek egyenlegeinek algebrai összege nulla, ez a rendezés. Az ilyen maradványokat nem szabad átvinni, mert ez egyértelmű hiba. A paraméter beállításakor nem kerülnek átvitelre.

5.3. ábra Újraosztályozás a maradékokban TMC a forrás adatbázisban BP 2.0

A maradékkal rosszabb a helyzet raktár №6. A maradék nem nulla, így az üdülőhely-korrekciós algoritmus nem fog működni, a maradék átkerül. És fontoljuk meg, hogyan kerülnek átadásra. Összeg -155,29 nem fog beleesni az átvitelbe, mert egy ilyen maradék be BP 3.0 nem lehet beírni, nem lehet nulla mennyiséget és nem nulla összeget beírni, az egyenlegbeviteli bizonylat nem kerül feladásra, ezért nem töltünk fel. Ennek eredményeként in BP 3.0 a fennmaradó két összeg le fog esni (lásd 5.4. ábra). A többit mintha hibával vitték volna át. Valójában itt persze nem átutalási hiba van, hanem könyvelési hibák.

5.4. ábra A következőre átvitel eredménye BP 3.0

A felhasználó dönti el, hogy használja-e a leírt átsorolási korrekciós algoritmust vagy sem. Csak emlékeznie kell arra, hogy a nulla mennyiségi egyenlegek soha nem kerülnek átadásra. A szerző szerint ez a legkorrektebb magatartás, legalábbis lehetővé teszi az egyenlegbevezetési bizonylat beírását és az egyeztetést. A közötti egyensúlyok közötti eltérések pozícióinak gyorsabb kereséséhez BP 2.0És BP 3.0 az átvezetés eredménye alapján javasolható a forrásban az ilyen problémás pozíciók kiválasztása a mérleg megfelelő beállításával. Ennek módját lásd az 5.5. ábrán.

5.5. ábra Nulla mennyiségű pozíciók kiválasztása

A kirakodás befejezése után futtatnia kell a programot 1C: Számvitel 8 ed.3.0. A betöltést mind a kezdeti, mind az ismételt adatmigráció vagy további migráció során típusfeldolgozással kell végrehajtani Univerzális adatcsere XML formátumban(lásd a 8.1. ábrát). A menüben nyithatja meg: Minden funkció - Feldolgozás - Univerzális adatcsere XML formátumban. Ha nincs menüpont Minden funkció, akkor el kell mennie ide Szolgáltatás - Paraméterekés jelölje be a négyzetet Parancs megjelenítése Minden funkció.

Az adatok 1C: Accounting 8 Edition 3.0 adatbázisba való betöltése után dokumentumokat kell készíteni a kezdeti egyenlegek beviteléhez, hogy az összes szükséges mozgást megkapjuk. Használhatja a feldolgozást Dokumentumok csoportos újraküldése(lásd a 8.2. ábrát) vagy tegyen fel dokumentumokat a naplóba (menü: Minden funkció - Dokumentumok - Egyenlegek bevitele). Ha a dokumentumokat mozgás nélkül vitték át (opció Dokumentummozgások feltöltéseértékre állítva Nem), akkor a feladások és a nyilvántartásokba való bejegyzések fogadásához bizonylatok feladása is szükséges.

Adatkonverziós technika.

Az átalakítás, ha szükséges, több szakaszban is végrehajtható, például először könyvtárak, majd egyenlegbeviteli bizonylatok, majd egyéb bizonylatok. Lehetőség van az információk újbóli továbbítására. Az átvitelek között ne végezzen javításokat az átvitt adatokon 1C: Számvitel 8 ed.3.0, ellenkező esetben ezek a javítások elveszhetnek az ismételt átvitel során.

Az egyenlegek átutalása dokumentumokon keresztül történik Nyitóegyenlegek megadása.

Az egyenlegbevitel módszertanáról további részletek az 1C ITS webhelyén található cikkben találhatók.

Fontos! A kezdeti egyenlegek megadása előtt be kell állítani a paramétereket számviteli politika. A szervezet számviteli szabályzatának beállításai az egyenlegek rögzítésének dátumát követő napon kerülnek beolvasásra. Például, ha az egyenlegek rögzítésének dátuma 2013.12.31., akkor a 2014.01.01-i dátummal beállított számviteli politika paraméterek kerülnek figyelembevételre, ami lehetővé teszi az aktuális számviteli politika paramétereinek figyelembevételét. (például: ha a szervezet 2013-ban az egyszerűsített adózási rendszert alkalmazta, és 2014-től áttér közös rendszer- akkor a 2013. december 31-i egyenlegek rögzítésekor a 2014. évi számviteli politika paramétereit veszik figyelembe). Éppen ezért, mint fentebb említettük, mindenekelőtt a szervezet számviteli politikájának átadását javasoljuk.

Fontos! Ha úgy dönt, hogy elkezd dolgozni 1C: Számvitel 8 ed.3.0 mielőtt a maradványokat oda szállították volna, a munka megkezdése előtt szükséges 1C: Számvitel 8 ed.3.0 könyvtárak átvitele. Ellenkező esetben, ha a maradékokat nem üres adatbázisba viszi át, hibák léphetnek fel.

Fontos: lehetőség van a szinkronizálási probléma megoldására egy nem üres adatbázisba való betöltéskor - az objektumok egyeztetése.

Hogyan kell dolgozni speciális adatátviteli feldolgozással.

A feldolgozás csak módban történik fájlt. Feldolgozás Data Transfer_from_BP20_to_BP30.epf el kell indítani abban az infobázisban, ahol az adatátvitel történik, pl. V 1C Vállalati számvitel rev.3.0. Az első ablakban (lásd a 9. ábrát) meg kell adnia az adatok betöltésének lehetőségét az 1C:Enterprise platformon lévő információs bázisból:

Adatok betöltése közvetlenül az információs bázisból

9. ábra Kezdőablak az adatátvitel feldolgozásához

A következő ablakban (lásd: 10. ábra) be kell állítania az átvitelt:

Válasszon ki egy információs bázist a listából (a lista ugyanaz, mint az alkalmazás indításakor 1C Enterprise).

Adja meg a felhasználónevet és a jelszót

Adja meg, hogy milyen információkat kell átvinni

Ezenkívül ellenőrizheti a forrásban szereplő adatokat az átvitel helyességét illetően

A szótárak migrálásakor az adatok a kiválasztott információs bázis szótáraiból kerülnek átvitelre, amelyekhez vannak feltöltési szabályok. Ebben az esetben a címtárak teljes egészében átvitelre kerülnek. Ha a jelölőnégyzet nincs bejelölve, de bármely más átviteli lehetőség be van jelölve, akkor a címtárak is átkerülnek, de csak az átadott tranzakciókban, bizonylatokban szereplő adatok kitöltéséhez szükséges mértékben. Az adatátvitel során az év elejére lehet átvinni címtárakat, bizonylatokat, egyenlegeket. Az átviteli lehetőségek bármilyen kombinációban kiválaszthatók. Az egyenlegek átutalásakor a kiválasztott év január 1-jei számviteli számlák egyenlegének adatai az 1. ábrán jelzett szabályok szerint kerülnek átadásra. Az 1C: Számvitel 8-ban a „Kezdő egyenlegek megadása” dokumentumok a kiválasztott év december 31-én jönnek létre.



10. ábra Átviteli beállítások ablak

Ha az adatellenőrzés opciót választja, akkor a betöltés előtt megtörténik az ellenőrzés, és az ellenőrzés eredménye megjelenik a képernyőn (lásd 11. ábra). Ha az ellenőrzési folyamat során hibákat találnak, az áttelepítési folyamat szünetel, hogy lehetővé tegye a hibák kijavítását. Ha a hibák ellenére adatokat szeretne feltölteni és letölteni, törölje a jelölést Letöltés előtt ellenőrizze az adatokat vagy kattintson Folytatni. Az ellenőrzési szabályok listája folyamatosan frissül.



11. ábra Az adatok feltöltés előtti ellenőrzésének eredménye

A forrásból a vevőbe történő adatátvitel során egy kép frissül a képernyőn, amely jelzi az aktuális szakaszt: csatlakozás az infobázishoz, adatok feltöltése, adatok betöltése stb. Ezen kívül több részletes információk lent egy karakterláncként jelenik meg, például "Adatfeltöltés: Dokumentumok(3 /3)". Az adatfeltöltés befejeztével megkezdődik a feltöltött dokumentumok könyvelése, majd a feltöltött adatok ellenőrzése. Ha a dokumentum feladása vagy az adatellenőrzés során hiba történik, akkor az erről szóló üzenetek a végén megjelenő üzenetablakban jelennek meg. A hibaüzenetek külön ablakban is megtekinthetők a hiperhivatkozásra kattintva Hibainformáció(Lásd a 12. ábrát).



12. ábra Az adatátvitel folyamatának jelzése

A hibarekordokat tartalmazó táblázat egy töredéke a 13. ábrán látható. A táblázat először a dokumentumok feladása közben fellépő hibaüzeneteket jeleníti meg, majd az ellenőrzés során fellépő hibákat. A feltöltött adatok ellenőrzése az egyenlegek forrás- és rendeltetési helyben történő rögzítésének napján keletkezett mérlegek összehasonlításából áll. Ha egyes számlákon egyenleg eltérés mutatkozik, erről rekord készül. A hibatáblázat egyik bejegyzésére duplán kattintva megnyithatja a problémás dokumentumot javításra és kézi végrehajtásra. Ugyanezt megteheti az üzenetablakban is.



13. ábra Hibarekordokat tartalmazó táblázat töredéke

A célbázisban végzett javítások után nincs értelme ugyanazt az információt újra átvinni a forrásbázisból, mert a második átvitel során ezek az adatok ismét hibásan kerülnek kiírásra. Ezért próbálja meg a kijavításokat a forrásnál elvégezni, ne a célállomáson, vagy kerülje az azonos információ továbbítását. Például a kezdeti egyenlegek átutalása és az összes bizonylat kijavítása után a kezdeti egyenlegek címzettbe történő beírásához ne állítsa be a jelzőt a további utalásokhoz Egyenleg év elején.

A frissítések a vásárlás után 6 hónapig ingyenesek. Az időszak végén ingyenes frissítések, Frissítéseket díj ellenében kaphat (a költségeket lásd alább). Ugyanakkor, ha több szoftverterméket vásárolt, készlet részeként vagy külön-külön, akkor jogában áll kedvezményre számolni. A kedvezményrendszerről bővebben tájékozódhat.

A technológia által létrehozott szabályok Adatkonverziók: könnyen szerkeszthető.
Teljesen nyitott, a replikáció tilalmán kívül nincs más licenckorlátozás.

Fájl TransferDemo20_30 Az .xml egy kitöltés az adatbázisból, amelyet az 1C által terjesztett BP 2.0 demo adatbázisnak a BP 3.0 adatbázisba való átvitelével kapunk. Hozzon létre egy üres BP 3.0.44.94 adatbázist, használhatja az 1C sablont vagy az 1Cv8.cf konfigurációs fájlt. A könyvelési beállításokban állítsa be Számlaterv beállítása a készletek raktáronkénti és tételenkénti elszámolása. Töltse le a demo fájlt TransferDemo20_30.xml feldolgozással Univerzális adatcsere XML formátumban. A demó adatbázis a 2009. 01. 01-i egyenlegek átutalását és a 2009. 01. 01. és 2009. 12. 31. közötti időszakra vonatkozó dokumentumokat mutatja.

A szabályokat rendszeresen frissítik az új kiadásokhoz, amelyek alkalmasak a BP 2.0.64.23 és újabb kiadásaira. Nem kell keresni és kiválasztani a kívánt verziójú portolási szabályokat, a megadott tartomány bármely SOURCE kiadásához alkalmasak. Ha szabályokra van szüksége a korábbi kiadásokhoz, forduljon a szerzőhöz. A RECEIVER kiadásnak meg kell lennie pontosan úgy mint a szabályokban.

2018.08.29. A szakasz szerinti egyenlegek kirakodása külön szabályba kerül. Hitelek és kölcsönök(66., 67. számla), korábban része volt Egyéb számviteli számlák

2018. 08. 20. Frissítés 2.0.66.59-re és 3.0.64.48-ra

2018.03.06. Hozzáadott dokumentumok átadása A fizetés tükrözése a szabályozott számvitelben

2018. 05. 18. Frissítés 2.0.66.54 és 3.0.61.37

2018. 02. 23. Frissítés 2.0.66.48 és 3.0.58.41

2018. 01. 18. Frissítés 2.0.66.46-ra és 3.0.57.17-re

2017.12.22. Frissítés 2.0.66.42 és 3.0.56.22

2017. 11. 03. Frissítés 2.0.66.37-re és 3.0.53.38-ra

2017. 09. 26. Frissítés 2.0.66.37 és 3.0.52.35

2017. 06. 14. Frissítés 2.0.66.29-re és 3.0.50.18-ra

2017. 05. 05. Frissítés 2.0.66.25-re és 3.0.49.27-re

2017. 04. 04. - hozzáadta a beérkezett számlák létrehozását, amikor a BP 2.0 csak számmal és dátummal rendelkezik. Paramétert kell beállítani Számlakonverzió végrehajtása(hozzon létre újakat, ha a forrás csak a számot és a dátumot tartalmazza)

2017. 02. 06. BP 3.0.47.23 frissítés

2017.01.26. Hozzáadott dokumentumok átadása ÁFA elhatárolás tükrözéseÉs A levonható áfa tükrözése

2017.11.01. BP 2.0.66.8 és BP 3.0.46.16 frissítés. Nyilvántartásba helyezés kizárva ÁFA az OSiNMA szerint. A korábbi verziókban, ahol a konfigurációban szerepel, nem kerül átvitelre.

2016.12.14. Frissítés a BP 3.0.44.203-hoz

2016.12.07. Hozzáadott dokumentumok átadása Adósságrendezés

2016.12.01. Paraméter hozzáadva Ne vegye figyelembe az egyszerűsített adórendszer költségeinek nyilvántartását, amely lehetővé teszi az egyszerűsített adórendszert alkalmazó szervezetek egyenlegek kiürítésének kezelését

2016. 11. 21. A címtár letöltése hozzáadva Felhasználók külön szabály az IS felhasználók létrehozásával a vevőben (részletek itt). Hozzáadott egyenlegek RS általi átvitele A szervezet alkalmazottai(Személyi adatok). A 76.AB és 76.BA számlák egyenlegének átutalásakor lehetőség van a rendezés ellenőrzésére és javítására a második alkontó segítségével.

2016.11.08 A dokumentumok listája bővült.

2016.10.28. Hozzáadott dokumentumok átadása. Az átvitel bemutatója hozzáadva, ez a BP 2.0 demo adatbázis átvitelének eredménye.

2016.10.26. Fix üres bizonylatok létrehozása az egyenlegek rögzítéséhez, ha 07.10-én számlaegyenleg van

2016. 09. 09. BP 3.0.44.102 frissítés

2016. 03. 23. Javított adatátvitel a beérkezett számlákról (készletegyenlegek átutalásakor)

2016.01.11. Hozzáadott magánszemélyek elérhetőségi adatai, állampolgárság, útlevéladatok, fogyatékossági adatok, személyek állapota. Szabályok hozzáadva a bankszámlák és a cikkszámla átvezetésére.

2015.12.23. Frissítés a BP 3.0.43.29-hez. A szerződő felek és kapcsolattartóik elérhetőségi adatainak átadása hozzáadva.

2015.12.14. Szabályok létrehozva a BP 3.0.42-hez

A csomag tartalma: Átigazolási szabályok "ACC20_30"és feldolgozás Adatátvitel_BP20-ról_BP30-ra. Ha az Ön szervezete nem rendelkezik főállású programozóval a munkához, készek vagyunk felajánlani szakemberünk szolgáltatásait (a programozó az interneten keresztül csatlakozik az Ön számítógépéhez, speciális program távmunkára és termelni fog szükséges munkát). Ha lehetséges munkabázist biztosítani "1C: Számvitel 8 rev.2.0", mi magunk is átvihetjük az adatokat és továbbíthatjuk a fájlt" 1C: Számvitel 8 ed.3.0» átvitt egyenlegekkel. A szolgáltatás díját a csomag teljes költsége nem tartalmazza.

Fontos. Nem minden dokumentum kerül áttelepítésre (a régebbi BP 2.0-s kiadásokkal való kompatibilitás érdekében). Vásárlás előtt figyelmesen olvassa el a 3. ábrán látható listát.

Adatátvitel az "1C: Accounting 7.7" és az "1C: USN 7.7" programokból az "1C: Accounting 8" programba

Néhány szó az adatok átviteléről egy tipikus konfigurációból " Könyvelés”, 4.5-ös kiadás az 1C: Enterprise 7.7-hez vagy a „” konfigurációhoz (a továbbiakban: Forráskonfigurációk) a szabványos konfigurációba Vállalati könyvelés”, 3.0-s kiadás az 1C: Enterprise 8-hoz (3.0.52-es verzió), a továbbiakban: „Cél konfigurációja”.

FONTOS! Adatátvitel a konfigurációból lehetséges Könyvelés 4.5-ös kiadás 1C:Enterprise 7.7 7.70.569-es és újabb verzióihoz, vagy a konfigurációból Egyszerűsített adózási rendszer, szerk. 1.3» 7.70.219 és újabb verziók.

Javasoljuk, hogy a Forrás konfigurációról a Cél konfigurációra váltson egy új időszak (év, negyedév, hónap) elején az előző időszak ütemezett műveleteinek befejezése után.

Az adatátvitel speciális feldolgozás segítségével történik, amely XML formátumú fájlba tölti ki az adatokat a forrás konfigurációs információs bázisból. Az eredményül kapott fájl az univerzális adatfeltöltési feldolgozás segítségével feltöltődik a címzett konfigurációjának információs bázisába.

ACC_ACC8.ert - külső feldolgozás adatok feltöltése ide külső fájl konfigurációból" Számvitel, rev.4.5»;

USN_ACC8 .ert - adatok külső feldolgozása külső fájlba a konfigurációból Egyszerűsített adózási rendszer, szerk. 1.3»;

ACC_ACC8 .xml - adatkonverziós szabályok.

USN_ACC8 .xml – adatkonverziós szabályok.

A következők kerülnek átvitelre a forráskonfiguráció információs bázisából a célkonfigurációba:

— információk a Forráskonfiguráció információs bázis számviteli számláinak aktuális egyenlegeiről az infobázis konverziós napján;

— aktuális dokumentumok, amelyek dátuma nagyobb, mint az infobázis átalakítási dátuma.

Az átalakítás két lépésben történik:

— a Source Configuration infobázisból származó adatok egy külön fájlba (adatfájlba) kerülnek feltöltésre;

— a fogadott fájl betöltődik a címzett konfigurációjának információs bázisába.

Az adatmigrációs feldolgozás telepítéséhez használja a setup.exe telepítőt. A program elindítása után (ha nagy az 1C:Enterprise infobázisok száma, akkor egy idő után) megjelenik egy párbeszédpanel, amelyben meg kell jelölni azokat az információs bázisokat, ahol az adatátviteli feldolgozást telepíteni kell. Az ablak úgy néz ki, mint az 1. ábrán. Ha az információs bázisok száma több mint hét, használja a fel és le gombokat a navigáláshoz. Ha több információs bázis van kiválasztva, akkor csak az utoljára kiválasztott információs bázis helye jelenik meg az "útvonal" sorban. Ezek az információk kiegészítő jellegűek, és tetszés szerint használják fel a felhasználó által a telepítőprogram eredményének további ellenőrzésére, ne fordítson rá különösebb figyelmet, a program maga határozza meg, hogy az Ön által kiválasztott infobázisok hova legyenek telepítve.



1. ábra Infobase kiválasztó ablak telepítés közben

Ezen kívül megadható, hogy melyik mappába kerüljön az adatátviteli feldolgozás is, ehhez a mappaválasztó ablakot kell használni (a hárompontos gombra kattintva). A kiválasztott mappa teljes elérési útja megjelenik a kijelölősávban. A "Telepítés" gombra kattintás után a telepítés megtörténik szükséges fájlokat a kiválasztott információs bázisokhoz és (vagy) a kiválasztott mappához. A befejezés után kattintson a "részletek" gombra, és megtekintheti a részletes telepítési naplót, amely tartalmazza, hogy mely fájlok és mappák készültek. Ennek eredményeként körülbelül a következő képnek kell megjelennie a kiválasztott mappában, lásd a 2. ábrát.



2. ábra A kiválasztott mappába telepített fájlok

Egy alkönyvtárba ExtForms feldolgozási és átviteli szabályokat határoznak meg. Felhívjuk figyelmét, hogy a feltöltés feldolgozása ACC_ACC8.ertés az adatfeltöltési szabályok felváltják tipikus feldolgozásés szabályokat. Ha meg szeretné tartani a szokásos átmeneti mechanizmust, telepítse az új feldolgozást egy külön könyvtárba, ne az információs bázisba.

A telepítési folyamat részletesebben le van írva a jelentés telepítésének példájával " Az „1C: Számvitel 7.7«.

egy programban" 1C: Számvitel 7.7» tól nyitható meg további jellemzők feldolgozás" Áttérés az 1C-re: Számvitel 8, szerk. 3.0«, válassza ki az átviteli szabályokat tartalmazó mappát (lásd 3. ábra), és töltse le a csereszabályokat. Nem kell minden szállítási szabályt megadnia. Csak azokat használja, amelyek szükségesek például egyenlegek, egyenlegek és bizonylatok átutalásához. Például a szótárak csoportban nem lehet szabályokat felvenni, mert az összes szótár átvitele hivatkozásokkal történik, szükség szerint, pl. csak azokat, amelyek az egyenlegekben vagy a dokumentumokban szerepelnek. Ez biztosítja, hogy ne legyen "szemét" az új információs bázisban. Nem kell minden dokumentumot mellékelnie sem. Például, ha nincsenek dokumentumok az adatbázisban, vagy nem szeretné őket átvinni, akkor nem kell engedélyeznie ezt a szabályt.



3. ábra. Adatfeltöltés feldolgozás

Javaslom, hogy az adatfájl nevét állítsa a „C:\v77_v8\Exp77_80.xml” értékre, ezt a mappát gyakran alapértelmezés szerint használja a „ program 1C: Számvitel 8» amikor adatokat tölt le a platformon lévő programokból « 1C: Vállalati 7.7". Ha szükséges, állítsa be a beállításokat az oldalon. Lehetőségek«.

Az adatok eltávolítása a konfigurációból" Számvitel 7.7» találkozhatnak különféle hibák. Az itt bemutatott migrációs szabályok abban különböznek a tipikusaktól, hogy az adatkitöltés szakaszában tipikus hibák keresése történik. Vegye figyelembe, hogy melyik üzenet jelenik meg közülük.

Nulla mennyiség és nem nulla mennyiségű áru és anyag. Egyenleg megadása a Destination Configuration-ban úgy, hogy az anyag mennyisége nulla és az anyag költségbecslése ne legyen egyenlő nullával lehetetlen, és nincs értelme, mert ez tévedés. Ezért az egyenleg átutalásakor az ilyen tételek (nulla mennyiséggel) nem lesznek elérhetők az egyenlegnyilvántartási bizonylatokban. Ha tehát a hibákat az adatátvitel előtt nem javítják ki, akkor az egyenlegek átutalásakor az adatforrásban és az adatcélpontban szereplő összegek nem egyeznek meg, ami további egyeztetési nehézségeket okoz. Ezért az adatok eltávolítása a konfigurációból " Számvitel 7.7» üzenetek jelennek meg a felmerült hibákról (lásd 4. ábra). Ezen túlmenően a hibák kereséséhez javasoljuk az „Elszámolás expressz ellenőrzése” feldolgozást, nevezetesen a „Nullától eltérő mennyiség hiánya nulla anyagmennyiség mellett” szabályt.



4.1. ábra Hibaüzenetek

Nem nulla egyenleg a második (harmadik) szintű alszámlán, míg az első (második) szinten az egyenleg nulla. Ez a hibás könyvelés meglehetősen gyakori helyzete. Egy tipikus példa látható a 4.2. ábrán. Van egy ilyen állapot az analitikus számvitelben a "megoldás" eredményeként. Például a közlekedési dokumentumokban Pénz a szerződés fel van tüntetve, de az áruk és anyagok feladásáról szóló dokumentumokban nincs szerződés, vagy fordítva, vagy vannak szerződések, de ezek különböznek. Mindezekben az esetekben a szerződések egyenlege nem nulla, annak ellenére, hogy a szerződő fél egyenlege nulla. Hasonló kép rajzolódhat ki az anyagelszámolásban, a nómenklatúrában (amikor a tárolóhelyek összesített elszámolása engedélyezett): a raktárak közötti válogatás, különösen, ha a raktárak anyagi felelősök.



4.2. ábra Példa a könyvelési hibákra

Nyilvánvaló, hogy ez tévedés, és egyértelmű, hogy nincs értelme az ilyen maradványokat átvinni. Az ilyen típusú egyenlegek átutalásának kizárása érdekében van egy "Ne rakd ki az egyenlegeket, ha nulla az egyenleg" paraméter. felső szint". Ha ez a paraméter 1-re van állítva, akkor az 1. ábrán látható üzenetek jelennek meg. 4.3 (vö. 4.2. ábra), és az ilyen pozíciókhoz tartozó egyenlegek nem kerülnek kiürítésre. Ennek a paraméternek a különféle kombinációit használhatja a különböző egyenlegek átutalásának szabályaival. Ha nem az összes egyenleget egyszerre, hanem könyvelési szakaszonként viszi át, akkor a különböző számviteli szekciók egyenlegét eltérő paraméterértékkel tudja átvinni.



4.3. Hibaüzenetek

Üres szerződésértékek vagy mások szerződései. A probléma hasonló a fent leírtakhoz, az ok ugyanaz - átminősítés a szerződések analitikus elszámolásában (lásd 4.4. ábra). De a partner egyenlege nem egyenlő nullával, így a fent leírt ellenőrzési szabály nem fog működni. Adatátvitelkor hiba történik az egyenlegbejegyzési bizonylat könyvelésekor, mert üres szerződésérték nem megengedett.



4.4. ábra: Hibajelentés

Az ilyen hibák átvitel előtti kiküszöbölésére az adatfeltöltési szakaszban hibaüzenetek jelennek meg (lásd 4.5. ábra). Ugyanezen az ábrán látható, hogy egy másik hiba is felmerült: a szerződés nem felel meg a szerződő félnek, pl. a szerződés tulajdonosa egy másik szerződő fél. Ilyen hibákat gyakran találunk a módosított, i.e. atipikus konfigurációk vagy nagy múltú adatbázisokban, amikor a szabványos konfigurációknál még nem ellenőrizték kellően szigorúan a szerződések betartását a dokumentumok kitöltésekor.



4.5. ábra Könyvelési hibaüzenetek

A szerződések és mások szerződéseinek üres értékeinek ellenőrzése akkor történik meg, ha a " Ellenőrizze a szerződések üres értékét és a partnerrel való megfelelést". Ezen túlmenően a hibakereséshez javasolható a „Számvitel expressz ellenőrzése” feldolgozás, nevezetesen a „Nincs üres elemzés a szerződésekhez” és „A szerződő felek és szerződések levelezése” szabályok.

Vannak egyéb hibaellenőrzések, pontosításért forduljon hozzánk (elérhetőségek az oldal alján).

Megmutatjuk, hogyan lehet részletekben, és nem teljes egészében átvinni az adatokat egy külön típusú dokumentumok, vagy akár a kiválasztott típusú dokumentumok különálló példányainak kirakodásának példáján. Csak egy szabályt jelöljünk meg az adatok kiürítésére Fizetési felszólítás» (lásd 5. ábra). Ezzel csak a következő formátumú dokumentumokat töltheti fel Fizetési felszólítás". Ha rákattint a " kirak", akkor az összes dokumentum a következő formában" Fizetési felszólítás", amely a következő időintervallumban található kezdő dátum" által " lejárati dátum". Nyomja meg a gombot " Telepítse a PVD-t", utána a "felirat" Adatok kiválasztása fizetési megbízáshoz«.



5. ábra Hogyan állíthatunk be egy szabályt egy bizonyos típusú adatok feltöltéséhez

Ezután kattintson a „Feltétel hozzáadása” gombra, ekkor kiválaszthatja a kiválasztási attribútumot (lásd 6.1. ábra), leggyakrabban a „ CurrentDocument«, amely lehetővé teszi egyetlen dokumentum kiválasztását az ilyen típusú dokumentumok listájából. Más kijelölési adatok használatával kiválaszthat egy dokumentumcsoportot, például dátum szerint jelölheti ki a dokumentumokat. A dokumentumok kiválasztása minden esetben az időintervallumon belül történik, paraméterezve « kezdő dátum"És" lejárati dátum«.



6.1. ábra Egyetlen dokumentum kiválasztása

Fontos! "1C"), amely bizonyos konfigurációkban nem teszi lehetővé a dokumentumok kiválasztását a kitöltéskor a kiválasztási részletek alapján. Ez annak köszönhető, hogy in modellszabályok a dokumentumokat kérésre, időszak megadása nélkül választják ki. Az ilyen kérések nem mindig működnek.

Hasonlóképpen a könyvtárakat is fel lehet tölteni, de nem a teljes könyvtárat, hanem valamilyen attribútum alapján kiválasztva. Először válassza ki a kívánt adatfeltöltési szabályt, majd nyomja meg egymás után a « gombokat Telepítse a PVD-t"És" Feltétel hozzáadása". Például a 6.2. ábra bemutatja, hogyan lehet csak azokat az alkalmazottakat kirakni, akiknél a programból való átállás időpontjában " 1C: Egyszerűsített adózási rendszer, szerk. 1.3" tovább " 1C: Enterprise Accounting, 3.0 kiadás” (vagy ahogy a felhasználók szokták mondani, a 7.7-ről a 3.0-ra való átállás) munkaviszony jött létre.



6.2. ábra Címtárelemek csoportjának kiválasztása

Fontos! Az adatmigrációra javasolt szabályokban a szabványos szabályok hibáját javították (a cégtől "1C"), ami a címtárelemek helytelen kiválasztásához vezet a kitöltéskor időszakos részletek segédkönyv, i.e. azok, amelyeknek különböző értékei vannak különböző dátumokra. Ennek az az oka, hogy a modellszabályokban a címtárelemek kiválasztása pont megadása nélküli lekérdezéssel történik.

A könyvtár időszakos adatai alapján történő kiválasztás a " paraméter dátumán történik lejárati dátum«.

Használhatja az adatfeltöltési szabályok és szűrők kombinációját. Azok a szabályok, amelyekhez kiválasztottak, a „[SZŰRŐ]” jelzéssel lesznek megjelölve. Egy adott adatfeltöltési szabály kiválasztásának megtekintéséhez vagy szerkesztéséhez duplán kell rákattintani a szabálylistában erre a szabályra, vagy kijelölése után a « Telepítse a PVD-t«.

Fontos! Ha az objektumok kirakodása üresnek vagy hiányosnak bizonyul, ellenőrizni kell, hogy be van-e állítva a szinkronizálási mód az 1C: Accounting 8-mal. Ha ez a helyzet, akkor csak az átvitel befejezése után megváltozott objektumok lesznek unloaded (Referencia. Szinkron elszámolási paraméterek tárolja az Utolsó kirakott bizonylat pozíciója paramétert, amelyet a kirakodás során a CheckOn the Possibility of the Kirakodás funkció ellenőriz) . teljes munka szinkron módban lehetetlenné válik. A szinkronizálási mód a csereszabályok betöltése után kerül ellenőrzésre. Ha a mód be van állítva, akkor egy figyelmeztető ablak generálódik (lásd 6.5. ábra), és felajánlja a szinkronizálási mód letiltását.



Rizs. 6.5 Szinkronizálási mód figyelmeztető ablaka

További eltérések a modellszabályoktól

P&L fix átutalása régi nyugtatípusokkal: ha az Áru- és Szolgáltatás átvételi bizonylatokban a nyugta típusa 2 (elavult érték), és nincs szállítói számla, akkor ez a bizonylat BP 3.0-ban tévesen konvertálódik a vevő visszáru bizonylatává.

Hiba javításra került, amikor olyan kézi műveleteket vittek át, amelyek alfiókkal rendelkeznek a BP PROF verzióra. Az ilyen művelet nem kerül rögzítésre az ÜT-ben, hiba történik: "Az osztály mezőnek üresnek kell lennie." Ennek oka az a tény, hogy a szabályok CORP verziókkal működnek, azonban PROF-ban a számviteli nyilvántartás DivisionDt és DivisionKt dimenzióinak üresnek kell lenniük.

Kijavítottunk egy hibát, amely ismétlődő csoportokat okozott a címtárban szerződésekés ennek eredményeként e könyvtár elemeinek megkettőzésére (mivel a keresés a betöltés során a szülő figyelembevételével történik). Ezt szemlélteti a 6.6. ábra.



6.6. ábra Címtárátvitel eredménye szerződések modellszabályok

Itt a rovatban Szülő(könyvtárcsoport) névvel 2015 van két különböző csoportok azonos nevű könyvtárat (egy csoport van a forrásban), ezért a szerződések duplikáltak.

Kijavítottuk a banki dokumentumok átutalásának hibáját, amikor pénzt utalnak át egyik folyószámláról a másikra. BAN BEN BP 3.0 ebben az esetben létrejön a dokumentum Leírás folyószámláról a művelet típusával Átutalás a szervezet másik számlájára, amelyet a kellékek fel nem töltöttsége miatt nem hajtanak végre Kedvezményezett számlája. Ráadásul az adatok hibásan vannak kitöltve számviteli számlaÉs Betéti számla. Ez akkor nyilvánul meg, ha különböznek, például 55 és 51, akkor ezeket fel kell cserélni. Javított hiba hiányzó részletekkel Kötelezettség típusa adódokumentumokban. A fentiek mindegyike a 3.0.43.215 kiadásra vonatkozik.

A kellékek átvitele folyamatban van főszerződés Könyvtár Ügyfelek.

A kézi kirakodás szabálya megváltozott Elnevezéstan, most az adatkiválasztási módszer egy szabványos kijelölés, amely lehetővé teszi a referenciakönyv elemeinek részletezését (az USN 7.7 - BP 3.0 szabvány szabályaiban ez nem lehetséges). Címtár átvitelekor Elnevezéstan, átkerülnek és Tétel árak linkekkel, pl. az árucikk csak átadott tételeinek árai. A funkció engedélyezéséhez a paraméter értékét egyre kell állítani. Töltsd fel az árakat egy tétel kirakásakor.

Javítva egy hiba az „USN 7.7 – BP 3.0” szabvány szabályaiban a partnerekkel való elszámolások egyenlegének átutalásakor: a szerződés típusa mindig a következőre volt állítva Egyéb. Most - az egyenleg típusától függően, a számviteli szakasz szerint " Elszámolások beszállítókkal, vállalkozókkal» szerződés típusa = « Támogató", a könyvelési rész szerint" Elszámolások vevőkkel és vásárlókkal» szerződés típusa = « a vevővel", egyéb esetekben a szerződés típusa = " Egyéb«.

Javítva egy hiba az "USN 7.7 - BP 3.0" szabvány szabályaiban a partnerekkel való elszámolások egyenlegének átutalásakor: a kölcsönös elszámolások összegét a kezdeti egyenlegek rögzítésére szolgáló dokumentum két részletében rögzítették. ÖsszegÉs ÖsszegKt. Ennek eredményeként nyitóegyenleg-bejegyzési bizonylat nem került feladásra.

Jelölje bea vevővel"(a modellszabályokban" Egyéb"). A " attribútum értéke Fizetési állapot„Fontos a számára jó választás a vevő felé történő fizetésről szóló számlák banki fizetési bizonylatokban a címzett konfigurációjában.

"" formátumú dokumentumok átvitelekor Fizetési felszólítás» szerződés típusa « Támogató"(a modellszabályokban" Egyéb«).

Javítva egy hiba az "USN 7.7 – BP 3.0" szabvány szabályaiban a tárolási helyek átvitelekor: a " attribútum Raktár típus«.

Paraméter hozzáadva " Csere a szabályozó hatóságokkal is": ha értéke 1, akkor kellékek Felügyeleti hatóságokkal való csere típusa könyvtárelem " Szervezetek' értékre van állítva ExchangeInUniversalFormat", egyébként a " Exchange Disabled» mint az általános szabályokban. Ez fontos az ismételt (rendszeres) átviteleknél, hogy ne rontsa el az EDI beállítást.

Módosult a keresési szabály a letöltött elemekre a következő könyvtárban Ügyfelek": először a keresés végrehajtásra kerül ÓNÉs ellenőrző pont(ha ezek az értékek ki vannak töltve), akkor csak a ÓNés végül tovább név. A keresés mindhárom esetben magában foglalja a csoport attribútumait (ThisGroup) és magát a csoportot (Parent). Ez fontos az ismételt (rendszeres) átutalásoknál, hogy ne keletkezzen duplikátum a feltöltés UTÁN megváltozott névvel rendelkező partnerek számára.

A szerződő felek átruházásakor az adatok kitöltésre kerülnek OrszágRegisztráció jelentése "Oroszország". Erre azért van szükség, hogy a partnerek könyvtárának programba való betöltése után "1C számvitel 8" nem kellett kézzel kitöltenie a szükséges adatokat OrszágRegisztráció. Ha nincs kitöltve, akkor hivatkozási elem formájában " Ügyfelek» részletek lesznek elérhetők « Adószám"És" Reg. szám"és részletek" ÓN"És" ellenőrző pont» el lesz rejtve.

Az „USN 7.7 – BP 3.0” átviteli szabályokhoz hozzáadásra került az „Alkalmazottak” címtár átviteléhez szükséges adatok feltöltésére vonatkozó szabály (a szabványos szabályokban csak az egyének névjegyzéke kerül átvitelre).

Az "USN 7.7 - BP 3.0" áthelyezési szabályzatban az Alkalmazottak aktuális fizetési rátája információs nyilvántartás átadására vonatkozó szabályt javították.

Az adófizetési megbízások átutalásának jellemzői

Művelet típusú fizetési megbízásokhoz Adó átutalás további adatokat kell kitölteni: KBK - kód költségvetési besorolás, kezdeményezői státusz stb. Ezeknek a részleteknek a szerkezete a Boom 7.7 (USN 7.7) és benne BP 3.0 nem egyeznek. Különösen benne BP 3.0 ezen adatok egy része egy külön könyvtárban van elhelyezve, amely hivatkozást a fizetési megbízás tartalmazza. Könyvtár Az adók és a költségvetésbe történő befizetések fajtái számos olyan elemet tartalmaz, amelyek megjelennek az információs bázisban, például egy számviteli politika szerkesztésekor. Az adatok migrálásakor ezek az elemek a számviteli politika betöltésekor is megjelennek. Fizetési megbízások feltöltésekor/letöltésénél a directory elem Az adók és a költségvetésbe történő befizetések fajtái a CCC keresett helyettesítésre a fizetési megbízás adatai között Adó. Ezért javasolt a számviteli politika átadása után ellenőrizni, hogy minden szükséges adó megjelent-e a névjegyzékben, szükség esetén kiegészíteni. A forrásban és a fogadóban lévő fizetési megbízások CCC-jének összehasonlításakor (szinkronizálásakor) nem vesszük figyelembe a négy CCC számjegyet, a 14-17 számjegyeket, a jövedelem altípus kódját: adó, kötbér, bírság stb. A könyvtárban Az adók és a költségvetésbe történő befizetések fajtái ezek a bitek nullákkal vannak feltöltve. Amikor új elemeket adunk a könyvtárhoz, a 14-17 számjegyeket is nullákkal kell kitölteni.

Információs bázisok átadása nagy méretű.

Először is, nagy információs bázisok migrálásakor az adatok kiürítésének folyamata nagyon sokáig tarthat. Ez akkor fordul elő, ha egy számviteli szakaszban nagyszámú egyenleg van, például áruegyenlegek. A kirakodási idő csökkentése érdekében használhatja az egyik dokumentum felosztásának módszerét " Nyitóegyenlegek megadása"néhányra. Ha beállítja a paraméter értékét " Az egyenlegbejegyzési bizonylat sorainak száma» nem nulla (lásd 6.3. ábra), akkor az adatok feltöltése egy dokumentumba a megadott értékre korlátozódik. Ez jelentősen (többször) csökkentheti a kirakodási időt.



6.3. ábra Paraméterek beállítása dokumentum méretkorlátozású adatátvitelkor « Nyitóegyenlegek megadása»

Megjegyzés: a paraméter értéke korlátozza az egy dokumentumba feltöltött könyvelési tábla sorainak számát " Nyitóegyenlegek megadása”, és nem állítja be magának a dokumentumnak a sorainak számát. Ezért a dokumentumsorok száma el fog térni a paraméter értékétől, ez nem hiba. Egy dokumentum felosztása során Nyitóegyenlegek megadása” több dokumentumhoz minden dokumentum megjegyzéseihez egy postfix kerül a sor végén: „-1”, „-2” stb.

FONTOS! A leírt algoritmus egy dokumentum felosztására " Nyitóegyenlegek megadása» többre csak az adatfeltöltési idő csökkentésére szolgál, minden dokumentum egy fájlba kerül fel, pl. az adatátvitel egy lépésben történik, a megjegyzések (postfixek) automatikusan generálódnak, csak egy paraméter van beállítva. De ez a technika nem oldja meg a memóriahiány problémáját, amelyet az alábbiakban tárgyalunk.

Nagy infobázisok migrálásakor felmerülhet a RAM hiányának problémája: a program kiürítésekor a program a megfelelő hibaüzenettel vagy üzenet nélkül leáll. A számítógépet erősebbre cserélni hiábavaló. Ebben az esetben az adatokat részekre kell bontani, részekre bontva. Ehhez olyan áttelepítési szabályokra van szükség, amelyek támogatják a megadott módot. Lássuk, hogyan kell kirakni. Először is, az adatátvitelt csak egy feltöltési szabály használatával kell végrehajtani (lásd 6.4. ábra). Ha egy szabály szerint az átvitel lehetetlen, akkor részekre bontjuk, feltüntetve az adagok számát, a kezdeti és a végső adagokat. Minden rész tartalmaz információt egy adott számú első szintű analitikai értékről, például termékegyenlegekről, pl. a „41” számlán lévő egyenlegek meghatározott számú értéke. A fiókban található elemzések teljes számának ismeretében könnyen kiszámítható az adagok száma. Azt, hogy egy időben mennyi adat kerül problémamentesen (egy információba), empirikusan kell meghatározni, főszabály szerint a számlaegyenlegek kirakodásánál több ezer vagy több egyenlegnél jelentkeznek átutalási problémák. Bár az adatfeltöltési idő megtakarítása érdekében, akkor is javasolt a részekre bontás, ha a könyvelési rész összes egyenlege egyszerre feltölthető. A kirakodási idő nem arányosan, nem lineárisan függ az adatrész méretétől. Ezért ha például tízezer áruegyenleget tízezres részre bont, többszörösére csökkentheti a kirakodási időt. Ha az első részt átvisszük, akkor a kezdő rész száma elhagyható, ha az utolsó rész, akkor az utolsó rész száma elhagyható.

FONTOS! Az adatok részenkénti átvitelekor meg kell adni a paraméterekben a postfixet, amely részt vesz a dokumentum megjegyzésének kialakításában " Nyitóegyenlegek megadása". Az adagok sorszámának megváltoztatásakor ne felejtse el megváltoztatni a postfixet, ellenkező esetben a címzett konfigurációjába való betöltéskor az azonos megjegyzésekkel (postfixekkel) ellátott dokumentumok felülíródnak. Az adatfájl neve nem sokat számít. Alkalmazhat szekvenciális átviteli taktikákat: feltöltés - letöltés, feltöltés - letöltés stb. Az adatállomány neve ebben az esetben változatlanul hagyható. Választhat taktikát: először mindent kirak, majd mindent letölt. Ez utóbbi esetben az adatfájl nevét minden feltöltéskor módosítani kell. Még egyszer egy példa. Ha a könyvelési részben az egyenlegek száma (például áruk) mondjuk 10 000, akkor ezt elosztjuk ezerrel, akkor 10 adagot kapunk. Minden résznek egyedi utótaggal kell rendelkeznie: "-1", "-2", "-3", "-4". Ha az összes többi árut kirakjuk, majd mindent felrakunk, akkor az adatfájloknak is egyedinek kell lenniük, például: "41_1", "41_2", "41_3", "41_4". Az „Adagszám kezdete” és „Adagszám vége” paramétereknek a következő értékeket kell venniük: 0, 1000; 1001, 2000; 2001, 3000; 3001, 4000.

• A szolgálati idő felmondása utáni megszakítása 2007. január 1-től az állampolgári szolgálati idő folyamatosságának megállapítására némileg eltérő eljárás vonatkozik. Ezt megelőzően, ha nem telt el 3 hét az egyik munkahelyről a másikra való átmenet során, akkor a tapasztalat nem szakadt meg. 2007 óta […]
• ANKO Tambov Törvényszéki Vizsgálati és Nyomozási Központ, ANO ANKO Tambov Törvényszéki Vizsgálati és Kutatási Központ, az ANO bejegyzett címe: Tambov, Rabochaya St., 37, 40. iroda, 392008.
• Rendelés a munkaidő-beosztásról Rendelés minta a munkaidő-beosztásról A munkaidő-beosztásról Az Orosz Föderáció Munka Törvénykönyve 100., 103., 104., 73. cikkével és a PJSC "Szervezet" belső munkaügyi szabályzatával összhangban, annak érdekében, hogy a vállalkozás működésének optimalizálása és […]
• A jekatyerinburgi 20. számú Központi Városi Klinikai Kórházban, ahol a főorvost elbocsátották, egy eljáró társaságot neveztek ki | Szverdlovszki régió | Az uráli szövetségi körzet Alena Tunist a jekatyerinburgi 20. számú Központi Városi Kórház megbízott főorvosává nevezték ki. Egy riporter szerint […]
• Ohm törvénye a párhuzamosságra multimédiás 8 cella. multimédia 9. évfolyam multimédia 10-11 cella. csillagászati ​​tesztek 7. évfolyam 8 sejtet tesztel. 9 sejtet tesztel. a vizsga bemutató táblázatai […]
• Az RSFSR törvénye a versenyről és a monopolisztikus tevékenységek korlátozásáról az árupiacokon, 1991. március 22. N 948-1 szövetségi törvények 1995.05.25. N 83-FZ, 1998.06.05. N 70-FZ, 2000.02.01. N 3-FZ, kelt […]