Névjegyek

Példa az objektumok konvertálására vonatkozó szabályra. Példa az objektumok konvertálására vonatkozó szabályra Egy tipikus adatátvitel költsége

És megmutatjuk, hogyan használhatod a feladatok megoldásának ERŐS egyszerűsítésére

Ma elemezzük, hogyan állíthatunk be és hajthatunk végre egyszerű könyvtárakat és kezdeti egyenlegeket mindössze 10-15 perc alatt.

És ez - nagy és rendszeres feladat, ami szinte elkerülhetetlen a legtöbb új konfiguráció esetében.

Ezért hívja kollégáit, ez is nagyon hasznos lesz számukra.

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

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

De a valóságban - minden nagyon egyszerű. Olyan egyszerű, hogy később még unatkozni is fog :)

Hogy pontosan mi szerepel a mai videókban

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

Ezenkívül mutatunk egy példát a standard csereszabályok véglegesítése az 1C -ben: Adatkonverzió 3.0

Teljes időtartam - 34 perc... Tartalom:

  • Tőzsde beállítása az 1C példáján keresztül: 8. számviteli és 1C: ERP
  • Hogyan lehet letölteni a minta szabályokat és univerzális formátum Csere az adatkonverzióban 3.0
  • 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
  • Az új szabályok betöltése a konfiguráció megváltoztatása nélkül ( a támogatásból való kivonás nélkül)

jegyzet hogy e probléma megoldásakor 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 hasonló problémát oldottak meg a Data Conversion 2.0 -ban, akkor változtatásokat kell végrehajtani mind a forrás, mind a cél szabályain.

Ezek a videó oktatóanyagok relevánsak a BSP számára 2.3.2 verzió(minden 2.3.2.43 -nál régebbi szerelvénynél).

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

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

Ebben a leckében előkészítő lépéseket hajtunk végre, amikor módosítjuk a csereszabályokat a tipikus konfigurációk között:

  • A csereformátum szerkezetének betöltése CD -re (
  • Konverzió létrehozása
  • Szabályfájlok eltávolítása egy tipikus konfigurációból
  • A központkezelő modul kiürítése

2. videó:
A CD 3.0 csereszabályainak módosítása

Ebben a leckében megmutatjuk, hogyan kell kitölteni az objektumok adatait az adatok betöltésekor.

A feladat megoldódik - amikor objektumokat tölt be a forráskonfigurációból, állítsa be a „Loaded from BP 3.0” megjegyzést.

A probléma megoldásához hozzá kell adnia az objektumok konvertálására vonatkozó szabályok módosítása, „A kapott adatok rögzítése előtt” esetén.

A kidolgozott szabályok külső feldolgozásként kerülnek mentésre a későbbi használatra.

3. videó:
Univerzális adatcsere beállítása a tipikus konfigurációk között

Ebben az oktatóanyagban megmutatjuk, hogyan lehet testreszabni új csere a tipikus között.

A beállításokat a forráskonfigurációban kell elvégezni, majd betölteni a célkonfigurációba.

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

4. videó:
Kezdeti egyenlegek átvitele csereszabályok segítségével

A leckében egy tipikus funkciót mutatunk be a kezdeti maradékok átviteléhez.

P.S.

Igen, txt / dbf / ole stb. létjogosultsága van. Bizonyos speciális esetekben, például webkiszolgálóval való dokkolás vagy külső alkalmazás kész formátumából történő átvitel esetén.

A szokásos cserékhez azonban - standard módszerek gyorsabb és sokkal könnyebb is.

És ha valaki feltalálja a kereket, ha van kész univerzális megoldás - olyan, mintha a homlokodra írnád: „Nincs szerszámom, nem akarok tanulni, mankót építek a pénzedért” .

P.P.S.

Szeretnénk megmutatni, hogy a Data Conversion 3.0 nem nehéz.

Szokatlan - igen. Nem minden azonnal világos - igen. Nagyon ellentmondásos pontok vannak - igen.

De a kész utasítások és videók segítségével szó szerint 1-2 hét alatt elsajátíthatja.

1. Bemutatkozás.

2. Amire szüksége van: 1C konfiguráció: Adatkonverzió 2. * és feldolgozás a csomagból. A feladatok példájához vegyük az 1C konfigurációt: Trade Management 11 és 1C: BP 3. *.

Tehát az adatok 1C -re történő feltöltésére vonatkozó szabályok kidolgozásához szüksége lesz egy 1C konfigurációra: 2 objektumok konvertálása, valamint a csomagban szereplő feldolgozás.

Például már telepítettük és elindítottuk a konverziós bázist.

Megírjuk a csereszabályok fejlesztését az 1C konfiguráció: Kereskedelmi menedzsment 11 és 1C: Vállalati számvitel 3 (UT / ACC cseréjére vonatkozó szabályok) között.

3. Feldolgozásra lesz szükségünk a metaadatstruktúra kirakásához és cseréjéhez.

A fejlesztéshez először a metaadat -struktúrájú fájlokat kell beszereznie. Ez az objektumkonverziós csomagban található metaadat -szerkezet kirakodási feldolgozásával történik.

Valójában a kicsomagolt konfigurációs könyvtárban a konfigurációkhoz kezelt formák az MD83Exp.epf. Ha ki kell töltenie a konfigurációkból a hagyományos formák, akkor MD82Exp.epf feldolgozást használunk. Ez akkor van, ha például struktúrát kell szereznie olyan konfigurációkból, 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á, már az adatok feltöltéséhez és letöltéséhez az 1C -be a szabályaink szerint, feldolgozásra lesz szükség. Univerzális csere adatok XML formátumban "V8Exchan83.epf a felügyelt űrlapokon, például 1C: Trade Management 11. *, 1C BP 3, 1C: ERP 2. * és hasonlók konfigurációihoz. És ennek megfelelően a V8Exchan83.epf - a rendszeres űrlapokon lévő 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 azzal, hogy letöröljük a metaadat -szerkezetet az 1C: Enterprise Accounting 3 konfigurációból.
Nyissuk meg az MD83Exp.epf feldolgozást

A feldolgozási formában vannak további beállítások, ahol engedélyezhetjük vagy letilthatjuk a nyilvántartások és a mozgások 1C -ben történő kirakodásának lehetőségét. Lehetőség van arra is, hogy a kirakodás hol történjen: az 1C szerveren vagy a "kliensen". Megadjuk annak a fájlnak a nevét, ahonnan az adatstruktúrát ki kell tölteni. Ugyanígy kirakjuk a Trade Management 11 konfigurációs metaadat -szerkezetét.

Most be kell töltenie a konfigurációt a konverziós adatbázisba. Erre a pontra a konfigurációk és a konverziók listájáról is eljuthat. Töltsük csak be az asztalról:

A párbeszédpanelen töltse be a BP struktúrát:

És hasonlóan - a Kereskedelmi Hivatal felépítése.

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

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

Ezután lépjen az "Objektumszabályok beállítása" oldalra, ahol új beállítást hozunk létre.
A konverzió létrehozására szolgáló párbeszédpanelen válassza ki a "forrás" konfigurációt és a "vevő" konfigurációt (amelyeket korábban betöltöttek), 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 Önöket, hogy nem hozunk létre automatikusan semmit. Nincs prototípus.

Ebben a párbeszédpanelen nem fogunk semmit tenni, csak kattintson a "Bezárás" gombra.

Szabályokat hozunk létre annak érdekében, hogy ne egy dokumentumot töltsünk ki az egyikbe, hanem az egyik típust a másikba, például egy dokumentumot az Áruk / szolgáltatások végrehajtásáról az UT 11 -ből, a szükséges referenciakönyvekkel az Áruk / szolgáltatások átvétele a BP 3 -ban dokumentumhoz.

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

Válassza ki az áruk / szolgáltatások értékesítésének forrását és az áruk / szolgáltatások á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.

A PVD (adatkiürítési szabályok) létrehozására irányuló javaslatra azonban igennel válaszolunk.

PVD -k jönnek létre, amelyek tükröződnek az egyetemes XML -csere kiválasztásában:

Létrejönnek az adatkonverziós szabályok is üres tulajdonkonverziós szabályokkal.

Ezenkívül látható, hogy a POC alapértelmezés szerint az objektum belső azonosítója alapján történő keresést javasolja. Ezt a PKO közelében lévő nagyító jelzi. Meg fogjuk tenni a keresést, és a nap eleji dokumentumszám és dátum szerint fogjuk tenni.

Töröljük az UIO által végzett keresést:

Most kezdjük el párosítani az objektum szükséges tulajdonságait (attribútumait). Ehhez kattintson a "Tulajdonságok szinkronizálása" gombra (jelölje be az "1" jelzést a képernyőn). Eltávolítjuk a rekurzív szabályok létrehozását ("2"). Eltávolítjuk az összes megjelölt részletet ("3"). És mi magunk választjuk ki, amire szükségünk van.

Például kiválasztjuk a szükségeseket:

Felhívom a figyelmet arra a tényre, hogy elkészítjük a szervezet PCS -jét a szervezethez, a szervezetet pedig a másik félhez, és összehasonlítunk néhány olyan adatot is, amelyek név szerint nem egyeznek, például "Valuta" és "Pénznem" a dokumentumból ".

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

Kezdjük el részletezni és leírni. Először úgy állítjuk be a dokumentum keresését, ahogy korábban írtuk, a dátum elején elvégezzük a dokumentum feltöltését és keresését, és megváltoztatjuk a számozást. Az első három karaktert saját "UTB" előtaggal helyettesítjük. És mivel a BP -ben és az UT -ben a számozás egyenként 11 karakter, összetett számot készítünk: előtagunkat és 8 karaktert a forrásból. Az alábbiakban egy példa látható.

A dokumentumok kirakása mindig feladás és mozgás nélkül történik. Feltételezzük, hogy a dokumentumok a felhasználó általi ellenőrzés után kerülnek a vevőkészülékbe.

Ehhez a nem végrehajtott PCN -t (0 vagy 1) logikai értékként kell használni.

A pénznemet példaként használva hozzon létre egy objektumkonverziós szabályt a PCS -hez. Ugyanakkor úgy gondoljuk, hogy a valuták mindkét bázisban rendelkezésre állnak, és ezeket kóddal kell szinkronizálni. Ezért a PKO pénznemekben nem hozzuk létre az összes PCS -t, hanem csak hozzáadjuk a kereséshez szükséges kódot. Azok. elutasítjuk azt a javaslatot, hogy PCS -t hozzunk létre az objektumhoz.

A létrehozott konverziós szabályt a dokumentum PQS -jével helyettesítették a PKS -hez. Magát a szabályt pedig alapértelmezés szerint egy egyedi azonosító javasolja. Javítjuk, keresést végezünk kód alapján, és beállítjuk a tulajdonságot, hogy ne hozzunk létre új objektumot.

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

Ezenkívül analógia útján létrehozzuk a többi kelléket PKO és PKS. Ezenkívül meghatározzuk a szervezet keresését a partnerek és fordítva a TIN szerint. Körülbelül így néz ki minimális részletekkel (szükség esetén hozzáadhat).

Az ügyfelek PKO szerződéseihez a PKS partnere, neve és tulajdonosa alapján keresünk.

Nézzük meg, hogyan lehet megadni a kívánt értéket a felsorolási típusban a PCN -ben. Például a "TypeOperation" attribútum. Itt különféle feltételeket és helyettesítő értékeket használhat. Például szükségünk van arra, hogy a "művelet típusa" mindig ki legyen rakva "Termékek", ebben az esetben elegendő a kívánt értéket egy "homlokra" sorba írni.

Az alábbiakban bemutatjuk, hogyan kell nehézségek nélkül beállítani, és a legtöbb esetben a PCS -t a kölcsönös elszámolási gyakorisághoz, a kölcsönös elszámolási arányhoz és a számviteli számlákhoz.

A PKO nómenklatúra esetében a belső egyedi azonosító alapján hagyjuk el a keresést. De figyelni fogok arra, hogyan határozhatja meg újra a csoportját. Például egyetértünk abban, hogy az 1C: Trade Management 11 konfigurációból új elem kerül kirakásra, de szükséges, hogy az elemet egy meghatározott "OurGroup" csoportba gyűjtsék.

Ennek a feladatnak a végrehajtásához hozzunk létre még egy PKO -t. Nevezzük "NomenclatureParent" -nek, amelyet a szülő PCS -ben fogunk feltüntetni a konverziós szabályban.

Két keresést állítottunk be: név szerint, ahol a név mereven szerepel a csoportunk számára, és a "ThisGroup" attribútum kötelező tulajdonsága igaz.

Mivel úgy döntöttünk, hogy minden nómenklatúra a csoportunkba tartozik, nincs szükség a csoportok kirakodására az UT 11 -ről a kirakodáskor. állítsa be a szűrőt, hogy nem szükséges kirakni az "Elutasítás = Forrás" csoportokat. Ez a csoport; ".

A PVD (adatkiürítési szabályok) A GoodsServices megvalósításában adjon hozzá egy szűrőt, hogy a törlésre kijelölt dokumentumok ne legyenek kirakva. Ehhez a PVA "Kirakodás előtt" eseménykezelőibe írjuk a "Elutasítás = Objektum. Törlési jel;" szűrőt.


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


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

1C -ben nyitjuk meg: Trade Management 11 feldolgozás "Univerzális adatcsere XML formátumban" V8Exchan83.epf.

A kirakodás megtörtént, most ugyanazt a feldolgozást használjuk az 1C: Enterprise Accounting 3 -ba való betöltéséhez.


A letöltés befejeződött. Ellenőrizzük, hogy mi van feltöltve. Tehát a dokumentumot feltöltjük, ahogy akartuk - Szervezetünk betöltődik a másik félbe, a másik pedig a szervezetbe. A könyvelési fiókok mindegyike letöltődik és telepítve van. Megkaptuk a dokumentum számát az előtaggal és a nap elején. Minden regisztrált adatot kitölt.

Az elem betöltésének ellenőrzése. Látjuk, hogy minden a tervek szerint alakult.


Elkészítettük és kitöltöttük a kellékeket, ahogy terveztük. Az átalakításban sok finomság van, és néhány egyszerű, de szükséges dolog, ami segít a konverzió pontos megírásában. Ez lehetővé teszi, hogy minimalizálja a hibákat, ne rontsa el a meglévő adatokat, és megszabaduljon a felesleges szeméttől. Ez az egyik legtöbb egyszerű példák... Egy objektumot is sokmá alakíthat, vagy fordítva, sok egyé.

Most 3 adatkonverzió van, ez más problémákat is megold. Ezért a 2 -es átalakításra is szükség van. Sok sikert mindenkinek a tanuláshoz és az elsajátításhoz.

Természetesen, ha Ön programozó, és ez a fő feladata, megpróbálhatja saját maga megírni az átalakítást. De ha nem, akkor értékelje az idejét a tevékenységi területén, és kérje meg a szakembereket, hogy végezzék el ezt a feladatot.

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

Az adatáttelepítés problémája (különösen az 1C termékekről beszélünk) egyik megoldásról a másikra nem merült fel tegnap. Az 1C cég tökéletesen megérti, hogy a fejlesztők milyen nehézségekkel szembesülnek a migrációk létrehozása során, ezért minden lehetséges módon megpróbál segíteni az eszközökkel.

A platform fejlesztése során a vállalat számos univerzális eszközt, valamint az adatátvitelt egyszerűsítő technológiákat mutatott be. Mindenbe be vannak építve tipikus megoldásokés a közötti migrációk problémája azonos konfigurációkösszességében elhatároztam. 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álaszthassák a probléma megoldásának legjobb módját az ő szemszögükből.

Tekintsünk néhányat közülük:

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

Mindegyiknek megvan a maga előnye és hátránya. Összefoglalva, a fő hátrány a beszédesség. Az áttelepítési algoritmusok önmegvalósítása jelentős időköltséggel és hosszú hibakeresési folyamattal jár. A további támogatásról hasonló döntések Nem is akarok beszélni.

A támogatás összetettsége és magas költsége arra késztette az 1C -t, hogy univerzális megoldást hozzon létre. Olyan technológia, amely a migrációk fejlesztését és karbantartását a lehető legegyszerűbbé teszi. Ennek eredményeként az ötlet egy külön konfiguráció - "Adatkonverzió" - formájában valósult meg.

Az adatkonverzió tipikus megoldás, önkonfiguráció. Bármely ITS: Prof előfizetővel rendelkező felhasználó teljesen ingyenesen letöltheti ezt a csomagot a felhasználói támogatási webhelyről vagy az ITS lemezről. A telepítés folyamatban van szabványos módon- mint minden más tipikus megoldás az 1C -től.

Most egy kicsit a megoldás előnyeiről. Kezdjük a legfontosabb dologgal - a sokoldalúsággal. A megoldás nincs specifikus platformkonfigurációkhoz / verziókhoz szabva. Egyformán jól működik mind a tipikus konfigurációkkal, mind a saját írásokkal. A fejlesztők univerzális technológiával és szabványosított megközelítéssel rendelkeznek új migrációk létrehozásához. A megoldás sokoldalúsága lehetővé teszi az átállások előkészítését még az 1C: Enterprise kivételével.

A második nagy plusz a látvány. Egyszerű áttelepítés programozás nélkül jön létre. Igen, igen, egyetlen kódsor nélkül! Már csak ezért is érdemes egyszer időt szánni a technológia elsajátítására, majd sokszor felbecsülhetetlen értékű készségeket használni.

A harmadik előny, amelyet kiemelnék, az adatok terjesztésére vonatkozó korlátozások hiánya. A fejlesztő maga választja ki az adatátviteli módot a vevő konfigurációjához. A dobozon kívül két lehetőség áll rendelkezésre: feltöltés xml fájlba és közvetlen kapcsolat az infobase -el (COM / OLE).

Építészetet tanulunk

Már tudjuk, hogy az adatkonverzió csodákra képes, de még nem teljesen világos, hogy milyen technikai előnyökkel jár. Az első dolog, amit meg kell tanulni, hogy minden adatáttelepítés (konverzió) a csereszabályokon alapul. Csereszabályok - egy rendes xml fájl, amely leírja a struktúrát, amelybe az IB -ből származó adatokat feltöltik. Szolgáltatásfeldolgozás, amely ki- / betölti az adatokat, elemzi a csereszabályokat, és ezek alapján végrehajtja a kirakodást. A folyamat fordított a rendszerindítás során.

A "KD" konfiguráció egyfajta vizuális konstruktor, amelynek segítségével a fejlesztő csereszabályokat hoz létre. Nem tudja, hogyan kell kirakni az adatokat. A CD -terjesztő készletben található további külső szolgáltatásfeldolgozás felelős ezért. Ezek közül több van (a fájlnévben XX a platform verziószáma):

  • MDXXExp.epf- a feldolgozás lehetővé teszi az infobase struktúra leírásának letörlését egy xml fájlba. A szerkezet leírását betöltik a CD -re további elemzés és csereszabályok létrehozása céljából.
  • V8ExchanXX.epf- ki- / betölti az adatokat az információs bázisból a csereszabályoknak megfelelően. A legtöbb tipikus konfigurációban a feldolgozás a dobozon kívül történik (lásd a „Szolgáltatás” 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ó kifejlesztésének szakaszait:

  1. A feladat meghatározása. Világosan meg kell érteni, hogy milyen adatokat kell átvinni (mely konfigurációs objektumokból), és ami a legfontosabb, hová továbbítani.
  2. A konfigurációs struktúrák leírásának elkészítése (Forrás / Vevő) a CD -re történő későbbi betöltéshez. A feladatot az MDXXExp.epf szolgáltatásfeldolgozás oldja meg.
  3. Kész szerkezetleírások betöltése az IB -be.
  4. Csereszabályok létrehozása vizuális CD -eszközök segítségével.
  5. Feltöltés / letöltés végrehajtása a létrehozott adatkonverziós szabályok szerint a V8ExchanXX.epf feldolgozás használatával.
  6. Hibakeresési csereszabályok (ha szükséges).

A legegyszerűbb átalakítás

A bemutatóhoz két telepített konfigurációra van szükségünk. Úgy döntöttem, hogy maradok a 10. kiadás „Kereskedelemmenedzsment” opciójánál és egy kis önálló megoldásnál. A feladat az adatok átvitele a tipikus "UT" konfigurációból. A rövidség kedvéért nevezzük az önállóan írt megoldást „vevő” -nek, a kereskedelemirányítást pedig „forrásnak”. Kezdjük a probléma megoldását a "Nómenklatúra" referenciakönyv elemeinek átvitelével.

Először is nézzük meg az adatkonverziós sémát, é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ásfeldolgozást.

A feldolgozási felület nem ragyog a beállítások bőségében. A felhasználónak csak meg kell adnia azokat a metaadat objektumokat, amelyek nem szerepelnek a szerkezet leírásában. A legtöbb esetben ezeket a beállításokat nem kell módosítani. nincs különös értelme a felhalmozási regiszterek mozdulatainak kirakásának (például).

A mozgás helyesebb a fogadóeszközben tartott dokumentumok során. Az átvitel után minden mozdulatot maga a dokumentum fog végrehajtani. A második érv az alapértelmezett beállítások védelmében a fájlméret csökkentése feltöltéssel.

Egyes dokumentumok (különösen tipikus konfigurációkban) mozgásokat generálnak több regiszter között. Ennek az egész gazdaságnak a kirakodása hozza meg az eredményt XML fájl túl nagy. Ez megnehezítheti a későbbi szállítást és behelyezést a vevőegység aljába. Minél nagyobb az adatfájl, annál többre van szüksége véletlen hozzáférésű memória feldolgozására. Gyakorlásom során véletlenül szembejöttem szemtelenséggel nagy fájlokat kirakodás. Az ilyen fájlokat teljesen elutasították, hogy standard módon elemezzék.

Tehát hagyjuk az összes alapértelmezett beállítást, és feltöltjük a konfigurációs leírást egy fájlba. Ugyanezt az eljárást megismételjük a második alap esetében is.

Nyissa meg a CD -t, és válassza ki a főmenüben "Könyvtárak" -> "Konfigurációk"... A hivatkozás tartalmazza az összes konfiguráció szerkezetének leírását, amelyek segítenek a konverziók létrehozásában. Egyszer betöltjük a konfigurációs leírást, majd ismételten felhasználhatjuk különféle konverziók létrehozásához.

A referenciaablakban nyomja meg a „ Hozzáadás”A megjelenő ablakban válassza ki a konfigurációs leírást tartalmazó fájlt. Jelöljük be a „Feltöltés ide:” jelölőnégyzetet új konfiguráció”És kattintson a„ Letöltés ”gombra. Hasonló cselekvések a második konfiguráció felépítésének leírásával tesszük.

Minden készen áll a csereszabályok létrehozására. A CD főmenüjében válassza a "Referenciák" -> "Konverziók" lehetőséget. Új elemet adunk hozzá. Az új konverzió létrehozásának ablakában meg kell adnia: a forráskonfigurációt (válassza az UT lehetőséget) és a vevő konfigurációját (válassza a „Vevő” lehetőséget). Ezután nyissa meg a "Speciális" fület, és töltse ki a következő mezőket:

  • csereszabályok fájlnév - a létrehozott csereszabályok ezen a néven kerülnek mentésre. A fájlnév bármikor megváltoztatható, de nyereségesebb most beállítani. Ez időt takarít meg a jövőben. Elneveztem a demó szabályait: "rules-ut-to-priemnik.xml".
  • név - a konverzió neve. A név abszolút bármi lehet, korlátoztam magam a „Demo. UT a vevőkészülékbe ”.

Ennyi, kattintson az "OK" gombra. Rögtön megjelenik egy ablak előttünk egy kérdéssel az összes szabály automatikus létrehozásához. Ha elfogadja az ilyen csábító ajánlatot, a varázsló parancsot kap arra, hogy automatikusan elemezze a kiválasztott konfigurációk leírását és önállóan hozzon létre csereszabályokat.

Tegyük rögtön az „és” pontot. A mester nem lesz képes semmi komolyat generálni. Ezt a funkciót azonban nem szabad leszámítani. Ha cserét kell létrehozni az azonos konfigurációk között, akkor a mester 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 kezelőfelület kissé zavarosnak tűnhet - nagyszámú lapok tömve vezérlőkkel. Valójában minden nem olyan nehéz, néhány órás alkalmazás után elkezdi megszokni ezt az őrületet.

Ebben a szakaszban két lap érdekel minket: "Objektumkonverziós szabályok" és "Adatfeltöltési szabályok". Először az illesztési szabályokat kell felállítanunk, azaz hasonlítsa össze két konfiguráció objektumait. A második, hogy meghatározza a lehetséges objektumokat, amelyek a felhasználó számára elérhetők lesznek a kirakodáshoz.

Az „Objektumok átalakításának szabályai” lap második felében található egy további panel két lappal: „Tulajdonságok konvertálása” és „ Értékek konvertálása”. Az első a kiválasztott objektum tulajdonságait (attribútumait) választja ki, a második pedig az előre definiált értékekkel való munkához (például előre meghatározott katalógus elemek vagy felsorolási elemek).

Remek, most hozzunk létre konverziós szabályokat a referenciakönyvekhez. Ezt a műveletet kétféleképpen hajthatja végre: használja az Objektumszinkronizáló varázslót (""), vagy adjon hozzá egyezéseket minden objektumhoz manuálisan.

Helytakarékosság érdekében használjuk az első lehetőséget. A varázsló ablakában törölje a jelölést a „ A dokumentumok"(Csak a referenciakönyvek érdekelnek minket) és nyissuk meg a csoportot" Hivatkozások”. Óvatosan lapozzunk a listán, és megnézzük az összehasonlítható referenciakönyvek nevét.

Esetemben három ilyen könyvtár létezik: Nómenklatúra, Szervezetek és Raktárak. Van egy referenciakönyv Clients, amely ugyanazt a szemantikai terhelést teljesíti, mint „ Vállalkozók"A konfigurációból" NS”. Igaz, a mester kiváló nevük miatt nem tudott hozzájuk illeszkedni.

Ezt a hibát magunk is kijavíthatjuk. Megtaláljuk az ablakban " Objektum illesztés"Szakkönyv" Ügyfelek", És a" Forrás "oszlopban válassza ki a" Vállalkozók "könyvtárat. Ezután jelölje be a négyzetet a "Típus" oszlopban, és nyomja meg az "Ok" gombot.

Az Objektumszinkronizáló varázsló felajánlja, hogy automatikusan létrehoz szabályokat az összes kijelölt objektum tulajdonságainak konvertálásához. Az ingatlanokat név szerint térképezzük fel, és ez elég lesz a bemutatónkhoz, egyetértünk. A következő kérdés a kirakodási szabályok megalkotására irányuló javaslat lesz. Egyetértünk vele mi is.

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

Először is, a feldolgozási ablakban válassza ki az általunk létrehozott csereszabályokat. Pozitívan válaszolunk a szabályok betöltésének kérdésére. A feldolgozás elemzi a csereszabályokat, és kiépítésre rendelkezésre álló azonos nevű objektumok fáját építi fel. Ehhez a fához mindenféle kijelölést vagy cserecsomópontot állíthatunk be, amelyek változásainak megfelelően ki kell választanunk az adatokat. Abszolút minden adatot szeretnénk letölteni, így nincs szükség szűrők telepítésére.

Miután befejezte az adatok fájlba történő feltöltésének folyamatát, lépjen az IB -be " Vevő”. A feldolgozást is megnyitjuk benne. V8Exchan82.epf, csak ezúttal lépjen az „Adatok letöltése” fülre. Válassza ki az adatfájlt, és nyomja meg a "Betöltés" gombot. Ennyi, az adatok sikeresen átkerültek.

Valós feladatok

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

Annak érdekében, hogy ne csalódjak a technológiában, több valós problémát készítettem elő. Munka közben találkoznia kell velük. Nem tűnnek olyan triviálisnak, és új szemszögből nézik az adatkonverziót. Gondosan mérlegelje a bemutatott példákat, és bátran használja töredékként a valós problémák megoldásakor.

1. számú probléma. Pótoljuk a hiányzó adatokat

Tegyük fel, hogy át kell vinnünk az UT -ből a könyvtárat Vállalkozók”. A vevő ehhez hasonló „Ügyfelek” könyvtárat tartalmaz. Teljesen alkalmas adatok tárolására, de rendelkezik kellékekkel. Szervezet”, Amely lehetővé teszi a vállalkozók szétválasztását a szervezethez való tartozásuk szerint. Alapértelmezés szerint minden partnernek az aktuális szervezethez kell tartoznia (az azonos nevű konstansból lehet beszerezni).

A problémának több megoldása is van. Megfontoljuk a szükséges kitöltési lehetőséget " Szervezet"Közvetlenül az adatbázisban" Vevő”, Azaz pl. az adatok betöltésekor. A jelenlegi szervezet állandóban tárolódik, ezért nincs akadálya ennek az értéknek a megszerzéséhez. Nyissuk meg az objektumkonverziós szabályt (a továbbiakban PCO) ” Ügyfelek”(Kattintson duplán az objektumra), és a szabályok varázslóban lépjen az„ Eseménykezelők ”szakaszba. A kezelők listájában ezt találjuk: Betöltés után”.

Írjuk le az aktuális szervezet megszerzésének kódját, majd a szükségeshez rendelve. A "Betöltés után" kezelő aktiválásának pillanatában az objektum teljesen formázva lesz, de még nincs beírva az adatbázisba. Senki sem tiltja meg, hogy saját belátásunk szerint változtassunk:

Ha NEM Object.EtoGroup Akkor Object.Organization = Constants.CurrentOrganization.Get (); EndIf;

A szükséges kitöltés előtt " Szervezet"Feltétlenül ellenőrizni kell a változó értékét" Ez a csoport". Hivatkozásul " Ügyfelek»A hierarchia jelző be van állítva, ezért ellenőrizni kell a csoportot. Hasonló módon történik a részletek kitöltése. Feltétlenül olvassa el a súgót a többi kezelői paraméterhez " Letöltés után". Például köztük van egy paraméter „ Elutasítás". Ha hozzá van rendelve az "Igaz" érték, akkor az objektum nem kerül az adatbázisba. Így lehetővé válik a betöltéskor az objektumok rögzítésének korlátozása.

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

A referenciában " Vállalkozók"UT konfiguráció, vannak részletek" Vevő"és" Szolgáltató”. Mindkét attribútum a következő típusú: Boolean”És a szerződő fél típusának meghatározására szolgálnak. IB -ben " Vevő", A referenciakönyvben" Ügyfelek"Nincsenek hasonló részletek, de van egy nyilvántartás az adatokról" Az ügyfelek típusai”. Hasonló funkciót lát el, és egy ügyfél számára több funkciót is tárolhat. Feladatunk az attribútumértékek átvitele az információregiszter külön rekordjaiba.

Sajnos a vizuális eszközök önmagukban nem tudnak megbirkózni ezzel. Kezdjük kicsiben, hozzunk létre egy új PKO -t az információregiszterhez ” Az ügyfelek típusai”. Ne adjon meg semmit forrásként. Nem hajlandó automatikusan létrehozni a kirakodási szabályokat.

A következő lépés a kirakodási szabályok kialakítása. Lépjen a megfelelő lapra, és nyomja meg a gombot Hozzáadás”. A kirakodási szabályok hozzáadására szolgáló ablakban töltse ki:

  • Mintavételi módszer. Váltson "Ingyenes algoritmusra";
  • Konverziós szabály. Kiválasztjuk az "Ügyfelek fajtái" információnyilvántartást;
  • A szabály kódja (neve). „Ügyfélnézetek kirakása” néven írjuk le;

Most kódot kell írnia a feltölteni kívánt adatok kiválasztásához. A paraméter " Adatok lekérése”. Egy gyűjteményt tehetünk bele egy előkészített adathalmazzal. Paraméter " Adatok lekérése”Különböző értékeket vehet fel- lekérdezési eredmény, kiválasztás, értékgyűjtemények stb. Értéktáblázatként inicializáljuk két oszlopból: kliens és ügyféltípus.

Az alábbiakban az eseménykezelő kódja található " Feldolgozás előtt”. Inicializálja a paramétert " Adatok lekérése"Ezt követi a referenciakönyv adatainak kitöltése" Vállalkozók”. Itt figyelni kell az oszlop kitöltésére " Ügyfél típusa”. Az "UT" -ben "Boolean" típusú jelek vannak, és a címzettben - felsorolás.

Ebben a szakaszban nem tudjuk a kívánt típusba hozni őket (az UT -ban nincs), ezért egyelőre karakterláncok formájában hagyjuk őket. Ezt nem kell megtennie, de rögtön meg akarom mutatni, hogyan kell átküldeni egy hiányzó típusra a forrásból.

DataFetch = NewValuesTable (); FetchData.Columns.Add ("Ügyfél"); FetchData.Columns.Add ("ClientType"); FetchDataFromDirectory = Könyvtárak.Contractors.Select (); Míg FetchingDataFromDirectory.Next () Loop IfFetchingDataFromDirectory.This Csoport Ezután folytassa; EndIf; If DataFetchFromDirectory.Customer Then NewRow = DataFetch.Add (); NewString.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Vevő"; EndIf; IfFetchDataFromDirectory.Provider Then NewRow = FetchData.Add (); NewString.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Beszállító"; EndIf; Ciklus vége;

Mentsük az adatkiürítési szabályt, és térjünk vissza a „ Objektumkonverziós szabályok”. Hozzáadás az információs nyilvántartáshoz " Az ügyfelek típusai”Tulajdon -konverziós szabályok: kliens és ügyféltípus. Hagyja üresen a forrást, és írja be a „Kirakodás előtt” eseménykezelőbe:

// Az „Ügyfél” tulajdonsághoz Value = Source.Client; // „ClientType” tulajdonság esetén If Source.Client = "Customer" Then Expression = "Enumerations.ClientTypes.Customer" EgyébIf Source.Client = "Beszállító" Aztán Expression = "Enumerations.ClientTypes.Supplier"; EndIf;

A listában a részleteket a kiválasztott adatok alapján töltik ki. Egyszerűen linkként továbbítjuk az ügyfelet, és beírjuk az ügyfél típusát a „ Kifejezés". Ennek a paraméternek az adatait a vevő fogja értelmezni, és végrehajtásakor a változót a felsorolás helyes értéke tölti ki.

Ennyi, a csereszabályok készen állnak.A megfontolt példa meglehetősen egyetemesnek bizonyult. Ezt a megközelítést gyakran használják, amikor adatokat migrálnak a 7.7 platformon létrehozott konfigurációkból. Feltűnő példa erre az időszakos kellékek átadása.

3. számú probléma. Táblázatos szakasz trükkök

Gyakran találkozik olyan feladatokkal, amelyek megkövetelik, hogy egy táblázatos szakasz sorait többbe tegyék közzé. Például a kezdeti konfigurációban a szolgáltatások és az áruk egyetlen táblázatos részben vannak elrendezve, és ezeknek az entitásoknak a tárolása elkülönül a vevőkészülékben. Ismétlem, a problémát nem lehet vizuális eszközökkel megoldani. Itt kényelmes a második probléma megoldását alapul venni.

Szabályt készítünk az adatok kiürítésére, megadunk egy tetszőleges algoritmust, és a "Kirakodás előtt" kezelőben kérést írunk az adatok lekérésére a táblázatos részből.

A helytakarékosság érdekében nem idézem a kérés kódját (mindig hivatkozhat a forráskódra) - nincs benne semmi szokatlan. Ismétlődünk a kapott kiválasztás felett, és a rendezett eredményeket a már ismert paraméterbe helyezzük Adatok lekérése”. Kényelmes az értékek táblázata is gyűjteményként:

DataFetch = NewValuesTable (); // Lesz még egy táblázatos rész DataFetch.Columns.Add („Termékek”); // Lesz egy táblázatos rész is DataFetch.Columns.Add („Szolgáltatások”); FetchData.Columns.Add („Link”);

4. feladat. Adatok átvitele egy művelethez

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

A konfigurációban " BP"Van egy univerzális dokumentum" Művelet”És ideális az alakításhoz több kiküldetések. Itt csak egy nem feladat - a dokumentumot ravaszul készítik, és nem olyan könnyű átvinni az adatokat.

Az ilyen konverzióra példa található a cikk forráskódjában. A kód mennyisége meglehetősen nagynak bizonyult, így nincs értelme közzétenni a cikkhez. Csak annyit mondok, hogy a kirakodás ismét tetszőleges algoritmust használ az adatok kiürítési szabályaiban.

5. számú probléma. Az adatok szinkronizálása több követelményhez

Már néztünk néhány példát, de még mindig nem beszéltünk az objektumok szinkronizálásáról a migráció során. Képzeljük el, hogy át kell adnunk a vállalkozókat, és néhányuk valószínűleg a vevő adatbázisában van. Hogyan lehet adatokat továbbítani és megakadályozni az ismétlődéseket? E tekintetben a CD többféle lehetőséget kínál a hordozható objektumok szinkronizálására.

Az első egyedi azonosítón alapul. Sok objektum egyedi azonosítóval rendelkezik, amely garantálja a táblázat egyediségét. Például a hivatkozásban „ Vállalkozók”Nem lehet két azonos azonosítójú elem. A CD számítást végez erre, és minden létrehozott PQS esetében az azonosító szerinti keresés alapértelmezés szerint egyszerre be van kapcsolva. A PCO létrehozása során figyelnie kellett volna az objektum neve melletti nagyító képére.

Az egyedi azonosító használatával történő szinkronizálás megbízható módszer, de messze nem mindig megfelelő. A könyvtárak kombinálásakor " Vállalkozók”(Többek közül különböző rendszerek) ez kevés segítséget jelent.

Ilyenkor helyesebb több szempont szerint szinkronizálni az objektumokat. Helyesebb, ha a partnereket TIN, KPP, név alapján keresi, vagy több szakaszra osztja a keresést.

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 " Vállalkozók"másból információs bázisok... Készítsük el a POC -t és állítsuk be a jelölőnégyzetet " Folytassa a keresést a keresési mezőkben, ha a célobjektumot nem találja meg az azonosító”. Ezzel a művelettel azonnal két keresési feltételt határoztunk meg - egyedi azonosító és egyéni mezők alapján.

Jogunk van a területeket magunk választani. A TIN, KPP, név megjegyzése után azonnal több keresési feltételt is feltüntetünk. Kényelmes? Elég, de ez megint nem elég. Mi van, ha meg akarjuk változtatni a keresési feltételeket? Például először az INN + KPP linket keressük, és ha nem találunk semmit, akkor elkezdünk szerencsét próbálni a névvel.

Egy ilyen algoritmus nagyon alkalmas a megvalósításra. Az eseménykezelőben " Keresés mezők"Legfeljebb 10 keresési feltételt határozhatunk meg, és mindegyikhez megadhatjuk a saját keresési mezőinket:

Ha SearchVariantNumber = 1, akkor SearchPropertyNameString = “INN, KPP”; ElseIf SearchVariantNumber = 2 Ezután SearchPropertyNameString = “Név”; EndIf;

Mindig több megoldás létezik

Bármely feladatnak több megoldása van, és az adatátvitel a különböző konfigurációk között sem kivétel. Minden fejlesztőnek joga van saját megoldási útvonalát választani, de ha állandóan összetett adatáttelepítéseket kell kifejlesztenie, akkor nagyon ajánlom, hogy figyeljen a "" konfigurációra. Legyen először szükséges erőforrásokat (időt) fektetni a képzésbe, de ezek több mint megtérülnek az első többé -kevésbé komoly projektnél.

Véleményem szerint az 1C méltatlanul megkerüli az adatkonverzió használatának témáját. A technológia teljes fennállása alatt csak egy könyv jelent meg róla: „1C: Enterprise 8. Adatkonverzió: Exchange az alkalmazásmegoldások között”. A könyv meglehetősen régi (2008), de mégis kívánatos megismerkedni vele.

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

"Ez egy univerzális eszköz, de ha azt tervezi, hogy adatáttelepítéseket kíván létrehozni az 1C: Enterprise 7.7 platformra kifejlesztett konfigurációkból, akkor időt kell töltenie a beépített nyelv megismerésével. A nyelv szintaxisa és ideológiája nagyon eltérő, ezért időt kell fordítania a tanulásra. Ellenkező esetben az elv ugyanaz marad.

E csereszabály célja a kölcsönös elszámolások egyenlegeinek átvitele a BP 2 -ről az UT11 -re.

Csereszabály létrehozása lépésről lépésre az "Adatkonverzió" konfiguráció használatával (a metaadatokat be kell tölteni):

1) Ehhez hozzon létre egy szabályt egy objektum kirakásához, lépjen az "Adatkiürítési szabályok" fülre, és kattintson a Hozzáadás gombra. A megjelenő ablakban válassza ki a mintaobjektumot, számunkra ez önhordó regiszter lesz. A mintavételi módszert tetszőleges algoritmusra cseréljük.

2) Térjünk át a kód írására. Mivel az UT-ban nincs önfenntartó regiszter, át kell alakítanunk. Először is szükségünk van egy kérésre, amely paramétereink szerint visszaadja a kölcsönös elszámolások egyenlegét. A "Feldolgozás előtt" eseménykezelőben írja be a következő kérést:

Kérés szövege = "SELECT
| Önfenntartó mérlegek. Számla,
| Önhordó mérlegek. Subconto1 AS Subconto1,
| NULL (SUM (önhordó egyenleg. SumRemainstDt), 0) AS AmountRemainedDt,
| NULL (SUM (önhordó egyenlegek. SumRemainsKt), 0) AS AmountResponsiveCt,
| MAXIMUM (önhordó egyenlegek. Subconto2.Date) mint az elszámolási dokumentum dátuma,
| MAXIMUM (önhordó egyenlegek. Subconto2.Number) AS Az elszámolási dokumentum száma
| FROM
| RegisterAccounting. Önfenntartó. Balances (& OnDate, Account = & account,) AS Self-support
| HOL
<>& csoport és
| Önhordó egyenlegek Alkonta 1. Szülő<>& csoport1
| LOAD BY
| Önfenntartó mérlegek. Számla,
| Önhordó mérlegek. Subkonto1,
| Önhordó mérlegek.Subkonto2
| RENDELÉS
| Subconto1
| AUTOMATIKUS RENDELÉS ";

Feladatomban korlátozások voltak érvényben azoknak az ügyfeleknek a csoportjaira vonatkozóan, amelyekre a települések ki vannak rakva.

Meghatározzuk a jövőben használt változók értékeit.

ByDate = dátum ("20130101");
TD = AktuálisDátum ();
csoport = Könyvtárak.Contractors.FindByDesign ("Vevők");
group1 = Könyvtárak.Contractors.NaytiByName ("Visszatérítések az EGYÉNEKTŐL");

Létrehozunk egy táblázatot, amelyet később áthelyezünk az értékkonverziós szabályba.

TK = Új értékekTáblázat ();
TK.Kolonki.Add ("Partner");
TK.Kolonki.Add ("Összeg");
TK.Kolonki.Add ("AmountREGL");
TK.Kolonki.Add ("Elszámolási dokumentum");
TK.Kolonki.Add ("Elszámolási dokumentum dátuma");
TK.Kolonki.Add ("Az elszámolási dokumentum száma");
TK.Kolonki.Add ("Partner");
TZ.Kolonki.Add ("Elszámolási pénznem");
TK.Kolonki.Add ("Fizetési dátum");

Beállítjuk a paramétereket, meghívjuk a kérelmet, kitöltjük a táblázatot, és meghívjuk a konverziós szabályt.

request = új kérés (Request Text);
request.SetParameter ("csoport", csoport); request.SetParameter ("csoport1", csoport1);
request.SetParameter ("OnDate", OnDate);
request.SetParameter ("Számla", Számlatervek. Önfenntartó. Számítások más szállítókkal és vállalkozókkal); // 76.05
Fetch = Query.Run (). Válassza a ();
TK. Világos ();
Mintavétel közben.Következő () hurok
ha Sample.SumRespondenceCT = 0 vagy Sample.SumRespondenceCT = "" akkor
folytassa;
fejezze be, ha;
ha Minta.SumResponseKT< 0тогда
report ("" + Minta.Subkonto1 + "negatív érték" + Minta.SumRemainst érték);
fejezze be, ha;
Karakterlánc TK = TK.Add ();
Karakterlánc TZ.Contractor = Selection.Subconto1;
Karakterlánc TZ.sum = Selection.SumResponseKt; // Selection.SumResponseKt;
Karakterlánc TZ.sumRegl = Selection.SumResponseKt; // Selection.SumResponseKt;
Karakterlánc TZ.Date of SettlementDocument = Sample.Date of SettlementDocument;
Karakterlánc TZ.A SettlementDocument száma = Minta.A SettlementDocument száma;
Karakterlánc TZ.PaymentDate = AP;
Ciklus vége;
OutgoingData = Új szerkezet;
OutgoingData.Insert ("Dátum", AktuálisDátum ());
OutgoingData.Insert ("CalculationsWithPartners", TK);
OutgoingData.Insert ("Tranzakció típusa", "Maradék adósság a beszállítók előtt");
OutgoingData. Insert ("Megjegyzés", "76.05 -ös számlán alakult");
jelentés ("76.05 CREDIT start");
UnloadByRule (, OutgoingData, "Egyensúlyok megadása kölcsönös kiegyenlítésekkel_7605Credit");

Hasonlóképpen, ugyanezt a műveletet hajtjuk végre a fennmaradó kötelező fiókoknál (leírásuk, valamint a kész szabály a mellékletben található).

3) Folytassa az objektumok konvertálására vonatkozó szabályok létrehozásával, ehhez nyissa meg az "Objektumok átalakításának szabályai" fület. Adjon hozzá egy új szabályt "Egyenlegbejegyzés a kölcsönös elszámolás_7605Credit" néven, hagyja üresen a forrásobjektumot, állítsa a fogadó objektumot az "Egyenlegbevitel" dokumentumra, és törölje a jelet a "Befogadó objektum keresése a forrásobjektum belső azonosítója" jelölőnégyzetből a beállítások lapon .

A "Betöltés előtt" eseménykezelőbe írja be a következő kódot:

Új szám létrehozásaORCodeIfNOTSpecified = true;

A "Betöltés után" eseménykezelőbe írja be:

execute (algoritmusok.AfterLoadingInputResults);

a következő tartalmú algoritmust hajtja végre:

currency = Constants.CurrencyRegulatedAccounting.Get ();
object.Responsible = SessionParameters.CurrentUser;
object.organization = paraméterek.szervezet;
minden oldalra az objektumból.számításokpartnerek ciklus
Page.CalculatingDocument = Könyvtárak.Vállalkozói megállapodások.blank link ();
Elszámolási pénznem oldal = pénznem;
ha az Érték kitöltve (oldal partnere) akkor
page.partner = oldal.partner.partner;
másképp
part = Könyvtárak.Partners.FindByDesign (oldal partnere.leírás);
ha rész<>Határozatlan és rész<>Könyvtárak.Partners.blank link () akkor
p.partner = asztalok;

object2.Partner = party;
object2.Write ();
másképp
execute (algoritmusok. AddPartner);
fejezze be, ha;

fejezze be, ha;

a ciklus vége;

Ezt az algoritmust a vevő oldalán (BP) hajtják végre. A kölcsönös elszámolások egyenlegeinek átvitele mellett az ügyfelek átutalása is a feladat, de az UT -ben partnereket használnak, ezért a dokumentum kialakítása után ellenőrizzük, hogy minden partner és partner elérhető -e a fogadó adatbázisában, ha mert nem azok, akkor hozzáadjuk őket.

A partnerek hozzáadása végrehajtja a "Fiókok" keresési konverziós szabályt. Létrehozhatja az előző szabályhoz hasonlóan, de lehetővé teszi, hogy maga a rendszer egyezzen a kötelező mezőkkel.

A partnerek számára létrehoztak egy algoritmust, amely a vevőoldalon fut.

Annak érdekében, hogy az algoritmust a vevőoldalon végrehajthassa, a jobb oldalon szükséges felső sarok az algoritmus ablakban (szerkesztéskor) állítsa be a "Használt rendszerindításkor" jelzőt.

Az alábbiakban a "Partner hozzáadása" algoritmus kódja látható:

nPartner = Könyvtárak.Partners.CreateItem ();
nPartner.Name = page.contract.name;
nPartner.Comment = "Létrejött BP -ről történő betöltéskor";
nPartner.NameFull = page.contractor.NameFull;
nPartner.Supplier =? (keresés (oldalpartner.AdditionalInformation, "Beszállító")> 0, igaz, hamis);
nPartner.Client =? (find (oldal partnere.AdditionalInformation, "Client")> 0, igaz, hamis);
OtherRelations =? (Find (oldal párja.AdditionalInformation, "Other")> 0, true, false);
npartner.Write ();
page.partner = npartner.link;
counterparty = Referenciakönyvek.Contractors.FindByName (oldal partner.Name);
object2 = vállalkozó.GetObject ();
object2.Partner = npartner.link;
object2.Write ();

Térjünk vissza az objektumkonverziós szabályhoz. Most be kell állítanunk a forrás és a célmezők egyezését, ezt közvetlenül a kód írása előtt megtehettük. Annak érdekében, hogy megfeleljen az alsó táblázatos szakasz mezőinek, van egy gomb a "Tulajdon szinkronizálása" varázsló meghívásához. Ebben a varázslóban vagy leképezhetjük a mezőket, vagy mind forrás, mind cél nélkül távozhatunk. Esetünkben minden mezőt és PM -et forrás nélkül hagyunk.

Miután minden mezőhöz kiválasztotta a szükséges mezőket az alsó PT -n, állítsa be a zászlót a "Get from becoming data" oszlopban. Ez a zászló azt jelzi, hogy a rendszer ezt a mezőt fogja keresni a bejövő adatok között. Fontos, hogy a mező neve megegyezzen a bejövő adatok nevével, ellenkező esetben megjelenik egy üzenet, amely szerint a mező nem található.

A szöveg nem írja le a folyamat minden árnyalatát.

Jelenleg az 1C: Enterprise 7.7 -ről a 8.3 -ra való átállás (hasonlóan a 8.2 -hez) fejtörést okozott a könyvelőknek. Kívánatos a lehető leggyorsabban és hibák nélkül. Ha Ön 1C: Számviteli programozó, és át kell alakítania ezeket a dokumentumokat a hetedik verzióról a nyolcadikra, akkor ez a cikk az Ön számára.

Tegyen csak néhány lépést, és az adatáttelepítési problémák megoldódnak. Olvass tovább ezt a kézikönyvet a végéig, és látni fogja a módját, hogyan kell ezt megtenni. Először is fel kell készülnie munkahely a számítógépen 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 a maradékok átvitele többszintű. És több 7.7 konfigurációval kell dolgoznia.

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

Adatátvitel 1C 7.7 -ről 1C 8.3 számviteli 3.0

Tehát mielőtt elkezdené az adatátvitelt az 1C 8.3 verzióra, elő kell készítenie ezeket az adatokat a 7.7 verzióban. Ehhez a következőket kell tennie. Tegyük fel, hogy a számítógépen van egy működő adatbázis "Számvitel egy vállalkozáshoz", amellyel könyvelői dolgoznak. Az Export77 feldolgozással töltse ki az összes szükséges dokumentumot egy szöveges fájlba, és ettől a pillanattól kezdve ne térjen vissza a fő munkaállomáshoz. A további manipulációk más konfigurációk esetén is megtörténnek.

Telepítse a friss 1C kiadást: Enterprise 7.7 az új könyvtárba. (a csomag tartalmazza a standard üres (nincs adat) és demót). A standard verzióval fogunk dolgozni. Most indítsa el ezt az adatbázist, és töltse be az Import 77 feldolgozással szöveges fájl adatokat a fő adatbázisból.

Az adatok konvertálása során előfordulhat, hogy egyes dokumentumok nem kerülnek közzétételre. Nem ijesztő. A trükk az, hogy ezt az átutalás után könnyedén kijavíthatja, mivel a standard adatbázisban a fő standard számlatáblával dolgozik. Ezért, bármennyire kifinomult is az alfiók, a munkabázisban könnyen megoldható körülbelül 3 óra alatt, ha bemegy minden egyes nem közzétett dokumentumba, és módosítja a konfigurációban lévő fiókokat a fiók mezőiben.

Természetesen előre, az átutalás előtt hozza össze a szabványos konfigurációjú számlatérképet a fő munkakörének számlarendjével összhangban. A lehetőségek tisztán egyéniek, a szervezet munkájának sajátosságaitól függően. Miután elvégezte ezt a munkát, megkapja szabványos konfiguráció tele van a munkahelyi adatokkal.

Most még egy adatátvitelt kell végrehajtanunk. Ehhez hajtsa végre az alapértelmezett nulla konfiguráció telepítését az új könyvtárban. És már ott is vigye át az adatokat a szabványos konfigurációból az adataival. Ennek eredményeként a 7 -es verzió ideális alapja lesz, készen a 8.2 -es verzióra való átvitelre.

A tény az, hogy az adatokat közvetlenül a nyolcadik verzióba továbbítják kizárólag az "érintetlen" szabványos 7.7 verzióból. És most csak egy ilyen konfigurációval rendelkezik. De most nem üres, hanem a munkaadataival.

Minden! Az 1C elindítása: Enterprise 8.2. Kiválasztjuk az "Adatátvitel a 7.7 -es verzióból" lehetőséget. és élvezze, hogy maga a program hogyan továbbítja az adatokat a feldolgozott 7.7 -ből, küldje újra a dokumentumokat, és jelenítse meg a 7.7 és 8.3 verziók mérlegének összehasonlító táblázatát.

Természetesen nem lesz 100% -os eredmény. De 70-80 százalékkal meccset kap. És akkor a munkája csak a 8.3 -as verzióban lesz elvégezve.

Az esetleges pontatlanságok könnyen kijavíthatók. Még 3-4 óra. Lépjen a dokumentumnaplóba, és módosítsa a számlákat vagy a mezőket (például "Szerződés" vagy "Fő pénztár"). Ez attól függ, hogy mennyire különbözik az alapja 7.7. a szabványtól. Mindezen műveletek eredményeként a 8.3 -as verziójú konfiguráció tökéletes formában képes könyvelési adatokat kiadni a mérlegben.

Az átállás után hasznos lesz megtanulni, hogyan kell dolgozni új program... Ehhez készítettünk egy 1C képzési számvitel szakaszt 8.3.

mellesleg! Ha javítani kell az 1C programokon, lépjen velünk kapcsolatba!

Hogyan lehet átvinni az 1C 7.7 -et a 8.3 adatbázisba?

Sok tipikus (és néhány iparágra jellemző) nyolc megoldás már rendelkezik beépített áttelepítési eszközökkel a 7.7-től, vagy további fájlként a sablon telepítési könyvtárában.

Ha maga viszi át, akkor az ITS -lemezen (valamint az internet sok helyén - a Google segítségért) van egy feldolgozás "Letöltés innen táblázatkezelő dokumentum", Amely lehetővé teszi tetszőleges táblázatos adatok betöltését könyvtárakba / dokumentumokba / nyilvántartásokba. Eléggé magas szint képesítést, akkor használhat harci tüzérséget - egy speciális konfiguráció "Data Conversion 2" (nem tévesztendő össze a 3.).

Meg tudná mondani, miért jön ki ez a hiba? Az 1C dokumentációjában mindenki túl zavarosan ír - elvégre fizetést kell kapnia, így kéziratában egyáltalán nem tud rájönni, a háború és a béke könnyebben jön be, mint az oktatásuk a messze nem komplex működéséről rendszer.

Maxim Kravchenko, hát végül is minden oroszul van írva 🙂

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

1) A csere beállításaiban a 7.7 óta rossz út van megadva. Itt vagy csak a gépelési hibákat, vagy a rossz könyvtár elérési útját kell megadni. Vagy helyi útvonal van megadva a számítógépen, és a csere a vállalati 1C szerver oldalán történik, és ez a szerver természetesen nem lát semmit az útvonalon (gyakori probléma).
2) A számítógép 7.7 -tel (helyi vagy szerver) történő cseréjére irányuló számítógép oldalán nincs teljesen telepített 7.7 -es platform. Azok. nincs regisztrált COM objektum, és a 7.7 adatbázist hagyományosan egy olyan könyvtár segítségével kötötték össze, amely veszélyeztetett platformmal rendelkezik, és nincs szüksége kulcsra vagy rendszeradatokra.
3) Nincs hozzáférési jogosultság a 7.7 bázissal rendelkező könyvtárhoz (ez különösen akkor fontos, ha olyan szerveren dolgozik, ahol az rphost dolgozó folyamata egy szolgáltatási felhasználó alatt fut, és a 7.7 alapkönyvtár nyitott bizonyos személyek számára).

Maksim Kravchenko, miért nem az IRC -n keresztül vagy a Narod "rohadt kulichki -jén" folytatott beszélgetéseken keresztül? 🙂
Nem, nem lépek újra ugyanarra a gereblyére. Már egy hálátlan személy odaadta Skype -ját, és ő a nyakába ült.

Ha általános kérdései vannak, amelyekre adott válaszok segíthetnek másoknak - tegye fel. Tegyünk együtt 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álaszokat adjanak erre az erőforrásra, jó lenne megjelölni a megoldásokat, vagy megnyomni a "tetszik" gombot a legmegfelelőbb válaszokon, még akkor is, ha nem közvetlenül segítettek.

Maxim Kravchenko, a GYIK lehetetlen, mert a tiszta 7.7 nem létezik a természetben. A tipikus / ipari megoldások egész palettája létezik különböző változatok azonos konfigurációjú, de e készlet egyike sem fedezi a "dobozon kívül" lévő vállalatok igényeit, és a telepítés után értékesített összes 7.7 -et évek óta finomítják. Figyelembe véve azt a tényt, hogy több mint tíz évvel ezelőtt abbahagyták a 7.7 értékesítését nagy mennyiségben, semmi sem maradhat az adott adatbázisban a jellemző funkciókból.

Az egy dolog, ha átveszi a szokásos átviteli mechanizmusokat, amelyekről a válaszomban írtam, és átadja, felismerve, hogy Ön a felelős a beakadásokért és minden következetlenségért, amelyet a "lányok" kijavítása érdekében tesz. És egészen más dolog, ha pénzért dolgozót vonzunk dolgozni. Le kell írnia az átutaláshoz szükséges összes referenciakönyvet, az átvitelhez szükséges információk mennyiségét (cikkek, vonalkódok, TIN stb.), Honnan szerezze be a hiányzó információkat stb. Nem vagyok kész vállalni a projektedet. Javaslom, hogy regisztrálja ezt a feladatot a szabadúszók oldalain, és pályázatot tartson közöttük.

Átviteli szabályok 1s 8

Adatok átvitele az "1C: Accounting 8 edition 2.0" programokból az "1C: Accounting 8 edition 3.0" programokba

Elsősorban módosított konfigurációkhoz tervezték 1C: Számviteli 8. kiadás 2.0(lehetséges nevek az interneten BP 2.0 vagy BP 8.2) alapul a konfigurációra való átvitelre vonatkozó eredeti szabályok kidolgozásához 1C: Számviteli 8. kiadás 3.0(lehetséges nevek az interneten BP 3.0 vagy BP 8.3), természetesen alkalmas a tipikus konfigurációk közötti adatátvitelre is.

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

Átmenet a 1C: Számviteli 8. kiadás 2.0 tovább 1C: Számviteli 8. kiadás 3.0 ajánlott elvégezni egy új időszak (év, negyedév, hónap) elején az előző időszak rutinműveleteinek befejezése után.

Az adatátvitel univerzális feldolgozással történik, amely kirakja az adatokat az információs bázisból 1C: Számviteli 8. kiadás 2.0 XML formátumú fájlba. A kapott fájl betöltődik az információs bázisba 1C: Számviteli 8. kiadás 3.0általános adatbetöltési feldolgozás használatával.

Az adatok átviteléhez a következő fájlokra van szükség:

ACC20_30.xml - adatkonverziós szabályok.

Az információs bázisból BP 2.0 v BP 3.0átadva:

információ az "1C: Könyvelés 8 rev.2.0" információs bázis számviteli számláin lévő egyenlegekről az információs bázis átalakításának időpontjában

infobase dokumentumok BP 2.0 a kiválasztott időszakra

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

- az 1C információbázis adatai BP 8.2 kirakodva külön fájl(adatállomány);

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

Nincs szükség telepítésre, mivel a tipikus konfigurációkba beépített kezeléseket használják 1C: Számviteli 8. kiadás 2.0és 1C: Számviteli 8. kiadás 3.0.

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

Egy programban 1C: Számviteli 8. kiadás 2.0 meg kell nyitnia a feldolgozást (menü: SzolgáltatásEgyéb adatcserék), válassza ki az átviteli szabályokat tartalmazó mappát (lásd 1. ábra), és töltse be a csereszabályokat. Javaslom, hogy mindenkor kényszerítse a csereszabályok betöltését, még akkor is, ha a feldolgozás kezdetekor automatikusan betöltődnek. Ehhez vagy újra ki kell választania a szabályfájlt, vagy kattintson a gombra Olvassa el újra a csereszabályokat... Nem kell minden átigazolási szabályt tartalmaznia. Csak azokat használja, amelyek szükségesek az egyenlegek és (vagy) dokumentumok átviteléhez. Valamennyi referenciakönyvet linkek továbbítják, szükség szerint, azaz csak azok, akik mérlegekben és dokumentumokban vesznek részt. Ez biztosítja, hogy ne legyen "szemét" az új információs bázisban.

Ha év végén kell kiürítenie az egyenlegeket, például 2014. 12. 31 -én a nap végén, azaz helyesebb lenne azt mondani 2015 elején, akkor a kirakodási időszak 2015.01.01 - XX.XX.XXXX. Dokumentumok az egyenlegek beviteléhez BP 3.0 2014. 12. 31 -én keltezik. 2015.01.01 -től BP 3.0 olyan dokumentumokat kell létrehoznia, amelyek tükrözik az aktuális műveleteket. Ha csak a maradékra van szüksége, akkor engedélyeznie kell a szakaszból származó adatok kiürítési szabályait Bejövő egyenlegek(lásd 1. ábra). Szakaszból származó adatok kiürítési szabályai A dokumentumok ebben az esetben le kell tiltani (lásd 3. ábra). A kirakodási időszak például 2015. 01. 01. és 2015. 01. 31. között azt jelenti, hogy a 2015. januári dokumentumok átkerülnek. Szakaszból származó adatok kiürítési szabályai A dokumentumok ebben az esetben bele kell foglalni.

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

Először is javasoljuk, hogy helyezze át a szervezet számviteli politikáját (hivatkozás A szervezet linkek hordozzák). Adatátvitelkor további paramétereket is beállíthat (lásd 2. ábra). Az alapértelmezett értékekhez való visszatéréshez töltse be újra a csereszabályokat.

2. ábra A paraméterek beállítása

Paraméter Hagyja figyelmen kívül az ÁFA kötegelt nyilvántartást mindenekelőtt meghatározza, hogy kitöltik -e BP 3.0 egyenlegek megadásakor Áruk és anyagok asztal A beérkezett számlák adatai... Ez befolyásolja az alkonto kitöltésének módját is. Buli: alapján LEHURROGÁS vagy nyilvántartási egyenlegekkel A vásárolt eszközök áfája.

A paraméter beállításával szabályozhatja a maradványok kiürítését a használó szervezeteknél STS... A könyvelés elindításakor, ha a nyilvántartási adatok nem egyeznek Az egyszerűsített adórendszer költségei hasznosabb lehet a számviteli nyilvántartás számára, ha csak a számviteli adatok szerint, regisztráció nélkül rakja ki az egyenlegeket STS amely rengeteg hibát adhat hozzá. Ebben az esetben a kezdeti egyenlegek bevitelére szolgáló dokumentumokban BP 3.0 kellékek Tükröződés az egyszerűsített adórendszerbenés Fogyasztási állapot tele van alapértelmezett értékekkel.

Amikor a paramétert erre állítja Igen a dokumentumokkal egyidejűleg az ezekhez a dokumentumokhoz tartozó főkönyvi készletek kerülnek átvitelre. Ellenkező esetben a dokumentumok tartalma átkerül, és a mozdulatok fogadásához a dokumentumokat közzé kell tenni az adatbázisban BP 3.0áthelyezés után. Meg kell érteni, hogy nem minden dokumentummozgás esetében BP 8.3, meccsek vannak bent BP 8.2... Ezért, még akkor is, ha a dokumentumok mozgással történő átvitelének lehetőségét választja, bizonyos típusú dokumentumok esetében előfordulhat, hogy közzé kell tennie az összes szükséges főkönyvi készlet létrehozását.

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

Az átadandó információk könyvtárainak és nyilvántartásainak listáját a 4. ábra mutatja. Ha valakit érdekel a lista bővítése, vegye fel a kapcsolatot a szerzővel. Számos referenciakönyv esetében vannak szabályok az objektumok átvitelére. Ez érthető, mert számos dokumentumban számos referenciakönyv található, és ennek megfelelően letölthetők a hivatkozásokról. Nem nehéz kirakodási szabályokat készíteni belőlük, saját maga is megteheti. A referenciakönyv kirakásának szabálya szükséges, ha a referenciakönyv egészét kívánja átadni, és nem csak linkeken keresztül.

Rizs. 4 Az átadandó információk könyvtárainak és nyilvántartásainak listája

A 76.АВ és 76.ВА számlák egyenlegeinek átutalásának sajátosságai

Ha értékre van állítva Igen paraméter Az elszámolások félreosztása a partnerekkel a könyvelési hibák kijavíthatók. Mi az átminősítés, az az 5.1. Ábrából egyértelműen kiderül: az ügyfél nulla egyenleggel rendelkezik, de a második részkonto nem rendelkezik nulla összeggel. Az ilyen maradékot nem viszik át.

5.1. Ábra A maradványok újraosztályozása

Ha erre van állítva Igen paraméter Az üzenetek részletei, majd kirakodáskor magyarázó üzenetek jelennek meg (lásd 5.2. ábra).

5.2. Ábra Üzenetek a maradványok túlosztására

A készletszámlák egyenlegeinek átutalásának jellemzői

A hibák kijavítására szolgáló algoritmus, például a maradványok osztályozása Áruk és anyagok... Ez az algoritmus működik a paraméter beállításakor A készletmaradványok téves besorolásának helyesbítéseértékben Igen... Példa az 5.3. A 10.03 számla elszámolása a nómenklatúra, a raktárak és a felek összefüggésében történik. Tétel szerinti egyenleg Benzin AI-92 tovább 4. raktár egyenlő nullával, de ha sorsolással kibővíti az egyenlegeket, akkor sok lesz. A maradékok algebrai összege sorszámokkal egyenlő a nullával, és ez a rossz besorolás. Az ilyen maradékot nem szabad átvinni, mert ez egyértelmű hiba. A paraméter beállításakor nem kerülnek átvitelre.

5.3. Ábra A maradványok újraosztályozása Áruk és anyagok a forrás adatbázisban BP 2.0

A maradékkal rosszabb a helyzet 6. számú raktár... A fennmaradó rész nulla, így a hibás osztályozási algoritmus nem fog működni, a maradékot átviszik. És gondoljuk át, hogyan fogják átvinni őket. Összeg -155,29 nem lesz benne az átigazolásban, mert egy ilyen maradék BP 3.0 lehetetlen megadni, lehetetlen nulla mennyiséget és nem nullát bevinni, az egyenlegbevitelre vonatkozó dokumentum nem kerül kifüggesztésre, ezért nem töltjük fel. Ennek eredményeként, ben BP 3.0 a fennmaradó két összeg csökken (lásd 5.4. ábra). A többit mintha hibával vitték volna át. Valójában természetesen itt nincs átviteli hiba, de vannak számviteli hibák.

5.4. Ábra BP 3.0

Az, hogy a leírt hibás osztályozási algoritmust alkalmazzák-e vagy sem, a felhasználó dolga. Csak emlékeznie kell arra, hogy a nulla összegű egyenlegek soha nem kerülnek átvitelre. A szerző véleménye szerint ez a leghelyesebb viselkedés, legalábbis lehetővé teszi, hogy dokumentumot készítsen a maradványok bevitelére, és kezdje meg az egyeztetést. Többért gyors keresés a maradványok közötti eltérési pozíciók BP 2.0és BP 3.0 az átadás eredményei alapján a forrásban javasolható az ilyen problémás pozíciók kiválasztása a mérleg megfelelő kiigazításával. Hogyan kell csinálni, lásd az 5.5.

5.5. Ábra Nulla mennyiségű tételek kiválasztása

A kirakodás befejezése után futtatnia kell a programot 1C: Számviteli 8. kiadás 3.0... A betöltést kezdetben és ismételt adatátvitelkor vagy további átvitelkor is rutinszerű kezeléssel kell elvégezni Általános XML adatcsere(lásd 8.1 ábra). A menüből nyithatja meg: Minden funkció - Feldolgozás - Univerzális adatcsere XML formátumban. Ha nincs menüpont a menüben Minden funkció, akkor mennie kell a Szolgáltatás -Paraméterekés jelölje be a négyzetet Parancs megjelenítése Minden funkció.

Miután betöltötte az adatokat az 1C: Accounting 8 rev.3.0 adatbázisba, el kell végeznie a dokumentumokat a kezdeti egyenlegek beviteléhez, hogy megkapja az összes szükséges mozgást. Használhatja a feldolgozást A dokumentumok csoportos újraküldése(lásd a 8.2. ábrát), vagy tegyen közzé dokumentumokat a naplóban (menü: Minden funkció - Dokumentumok - Egyenleg bevitele). Ha a dokumentumokat mozgás nélkül továbbították (paraméter Dokumentummozgások kirakásaállítva Nem), akkor a nyilvántartásokba történő bejegyzések és bejegyzések fogadásához dokumentumokat is közzé kell tennie.

Adatkonverziós technika.

Az átalakítás, ha szükséges, több szakaszban is elvégezhető, például először könyvtárak, majd a maradványok bevitelére szolgáló dokumentumok, majd más dokumentumok. Az információ újbóli átadása lehetséges. Az átvitelek között ne javítson az átvitt adatokon 1C: Számviteli 8. kiadás 3.0 ellenkező esetben ezek a javítások elveszhetnek az ismételt átvitel során.

Az egyenlegeket dokumentumok útján utalják át Kezdeti maradványok megadása.

Az egyenlegek bevitelének módjáról további információk találhatók az 1C vállalat ITS webhelyének cikkében.

Fontos! A kezdeti egyenlegek megadása előtt be kell állítani a számviteli politika paramétereit. A szervezet számviteli politikájának paramétereit az egyenlegek bevitelének napját követő napon olvassák be. Például, ha az egyenlegek bejegyzésének dátuma 2013. december 31 -e, akkor a 2014. január 1 -jétől beállított számviteli politika paramétereket veszi figyelembe. Ez lehetővé teszi, hogy figyelembe vegye az aktuális számviteli politika paramétereit ( például: ha 2013 -ban a szervezet egyszerűsített adózási rendszert alkalmazott, és közös rendszer- akkor a 2013. december 31 -i egyenlegek bevitelénél a 2014. évi számviteli politika paramétereit veszik figyelembe). Éppen ezért, amint azt fentebb jeleztük, először is javasoljuk a szervezet számviteli politikájának áthelyezését.

Fontos! Ha úgy dönt, hogy elkezdi a munkát 1C: Számviteli 8. kiadás 3.0 Mielőtt a maradékot oda szállították, előzetesen szükséges a munka megkezdése előtt 1C: Számviteli 8. kiadás 3.0átviteli könyvtárak. Ellenkező esetben, ha a maradékokat nem üres bázisra viszi át, hibák lehetségesek.

Fontos: lehetőség van a szinkronizálás problémájának megoldására, amikor nem üres bázisba töltünk be - objektumillesztést.

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

A feldolgozást csak a módban használják Fájl... Feldolgozás Adatátvitel_from_BP20_to_BP30.epf abban az információs bázisban kell elindítani, ahol az adatokat továbbítják, azaz v 1C vállalati számviteli felülvizsgálat 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 infobázisból az 1C: Enterprise platformon:

Töltsön be adatokat közvetlenül az információs bázisból

9. ábra Az adatátvitel feldolgozásának kezdőablaka

A következő ablakban (lásd a 10. ábrát) konfigurálnia kell az átvitelt:

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

    Adjon meg felhasználónevet és jelszót

    Jelölje meg, hogy milyen információkat kell továbbítani

    Ezenkívül ellenőrizheti a forrás adataiban az átvitel helyességét

    Katalógusok átvitele során az adatok a kiválasztott információs adatbázis katalógusaiból kerülnek átvitelre, amelyekre kirakodási szabályok vonatkoznak. Ebben az esetben a könyvtárak teljes egészében átkerü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 szótárak is átkerülnek, de csak olyan mértékben, amennyi az átvitt tranzakciók és dokumentumok adatainak kitöltéséhez szükséges. Adatátvitelkor az év elején átviheti a címtárakat, dokumentumokat és egyenlegeket. Az átviteli lehetőségek tetszőleges kombinációját választhatja. Az egyenlegek átutalásakor a kiválasztott év január 1 -jei számviteli számlák egyenlegeinek adatait az 1. ábrán jelzett szabályok szerint továbbítjuk. Az 1C: 8. számviteli rendszerben a "Kezdeti egyenlegek bevitele" dokumentumok jönnek létre a kiválasztottat megelőző év december 31 -én.

    10. ábra Átviteli paraméterek ablak

    Ha az adatellenőrzés opció van kiválasztva, akkor a betöltés előtt egy ilyen ellenőrzésre kerül sor, és az ellenőrzés eredménye megjelenik a képernyőn (lásd 11. ábra). Ha hibákat talál az ellenőrzési folyamat során, az átviteli folyamat szünetel, hogy lehetőséget adjon a hibák kijavítására. Ha a hibák ellenére is fel kell töltenie és le kell töltenie az adatokat, törölje a jelölést Feltöltés előtt ellenőrizze az adatokat vagy nyomja meg a gombot Folytassa... Az ellenőrzési szabályok listája folyamatosan bővül.

    11. ábra A betöltés előtti adatellenőrzés eredménye

    Az adatok forrásból a vevőbe történő átvitelének folyamata során a képernyőn frissül egy kép, amely jelzi az aktuális lépést: csatlakozás az információs bázishoz, adatok feltöltése, adatok letöltése stb. Sőt, több részletes információk alatt jelenik meg karakterláncként, például "Adatok feltöltése: dokumentumok (3/3)". Az adatok letöltésének befejezése után megkezdődik a letöltött dokumentumok közzététele, majd a letöltött adatok ellenőrzése. Ha dokumentumok vagy adatellenőrzési hibák során történt, akkor a végén az erről szóló üzenetek jelennek meg az üzenetablakban. A hibaüzenetek külön ablakban is megtekinthetők a hivatkozásra kattintva Hiba információk(lásd a 12. ábrát).

    12. ábra Az adatátviteli folyamat jelzése

    A táblázat a hibarekordokat tartalmazó töredékét a 13. ábra mutatja. Először is, a táblázat üzeneteket jelenít meg a dokumentumok közzététele során bekövetkezett hibákról, majd az érvényesítés során. A betöltött adatok ellenőrzése abból áll, hogy összehasonlítják a mérlegeket, amelyek az egyenlegek bevitelének időpontjában keletkeztek a forrásban és a vevőben. Ha a számla egyenlege eltér, akkor erről jegyzőkönyv készül. Ha duplán rákattint egy bejegyzésre a hibatáblázatban, megnyithatja a problémadokumentumot kézi javításhoz és közzétételhez. Ugyanezt megteheti az üzenetmezőben is.

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

    Miután elvégezte a javításokat a fogadó bázison, nincs értelme ugyanazt az információt újra átvinni a forrásbázisból, mert az átvitel megismétlésekor ezek az adatok ismét hibákkal íródnak. Ezért próbálja meg korrigálni a forrást, nem pedig a vevőt, vagy ne ismételje meg ugyanazon információk továbbítását. Például, miután áthelyezte a kezdeti egyenlegeket, és kijavította az összes dokumentumot a kezdő egyenlegek beviteléhez a vevőbe a további átutalások során, ne állítsa be a zászlót Egyenleg az év elején.

    A frissítések a vásárlás után 6 hónapig ingyenesek. Az ingyenes frissítések időszakának végén fizetett frissítéseket kaphat (lásd az alábbi költségeket). Sőt, ha többet vásárolt szoftver termékek, a készletek részeként vagy külön -külön, akkor joga van kedvezményre számítani. További információ a kedvezményrendszerről.

    A technológia által létrehozott szabályok Adatkonverziók: könnyen szerkeszthető.
    Teljesen nyitott, nincs engedélyezési korlátozás, kivéve a sokszorosítás tilalmát.

    Fájl TransferDemo20_30 Az .xml egy olyan kirakodás az adatbázisból, amelyet az 1C által terjesztett BP 2.0 demo adatbázis átvitelével a BP 3.0 adatbázisba kapunk. Hozzon létre egy üres alapú BP 3.0.44.94 -et, az 1C sablonból vagy az 1Cv8.cf konfigurációs fájlból. Állítsa be a számviteli paramétereket a értékre Számlatér felállítása készletek elszámolása raktárak és tételek szerint. Töltse le a demo adatbázis fájlt TransferDemo20_30.xml feldolgozással Általános XML adatcsere... A bemutató adatbázis a 2009. január 1 -jéig fennálló egyenlegek átvitelét, valamint a 2009. január 1 -jétől 2009. december 31 -ig tartó időszak dokumentumait mutatja.

    A szabályokat rendszeresen frissítik az új kiadásokhoz, amelyek alkalmasak a BP 2.0.64.23 és újabb kiadásokra. Nem kell keresni és kiválasztani az átviteli szabályok kívánt változatát, ezek alkalmasak a megadott tartomány bármely SOURCE kiadására. Ha szabályokra van szüksége a korábbi kiadásokhoz, lépjen kapcsolatba a szerzővel. RECEIVER kiadásnak kell lennie pontosan ugyanaz mint a szabályokban.

      2018.08.29. Külön egyenlegekre osztották ki a mérlegek szakaszonkénti kiürítését Kölcsönök(66., 67. számla), korábban része volt Egyéb könyvelési számlák

      2018. 08. 20. Frissítés 2.0.66.59 és 3.0.64.48 verzióra

      2018.03.06. Dokumentumok továbbítása A fizetések tükröződése a szabályozott számvitelben

      2018.05.18. Frissítés 2.0.66.54 és 3.0.61.37 verzióra

      2018.02.23. Frissítés a 2.0.66.48 -ra és a 3.0.58.41 -re

      2018.01.18. Frissítés a 2.0.66.46 -ra és a 3.0.57.17 -re

      2017.12.22. Frissítés 2.0.66.42 -re és 3.0.56.22 -re

      2017. 03. 11. Frissítés a 2.0.66.37 és 3.0.53.38 verzióra

      2017. 09. 26. Frissítés a 2.0.66.37 és 3.0.52.35 verzióra

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

      2017. 05. 05 Frissítés a 2.0.66.25 és 3.0.49.27 verzióra

      2017. 04. 04. - Hozzáadott számlák létrehozása, amikor a BP 2.0 csak számot és dátumot tartalmaz. Be kell állítania a paramétert Számlák konvertálása(hozzon létre újakat, ha csak szám és dátum szerepel a forrásban)

      2017. 06. 02. A BP 3.0.47.23 frissítése

      2017.01.26. Dokumentumok továbbítása Az áfa -elhatárolás tükröződéseés A levonható áfa tükrözése

      2017. 11. 11. Frissítés a BP 2.0.66.8 és BP 3.0.46.16 verzióra. Regisztrációs átvitel kizárt ÁFA az OSiNMA -ra. A korábbi verziókban, ahol szerepel a konfigurációban, nem kerül átállításra.

      2016.12.14. A BP 3.0.44.203 frissítése

      2016.07.12. Dokumentumok továbbítása Az adósság kiigazítása

      2016/01/01 Hozzáadott paraméter Ne vegye figyelembe a nyilvántartást Költségek az STS -hez, amely lehetővé teszi a szervezetek számára a szermaradványok kirakodásának kezelését az egyszerűsített adórendszer használatával

      2016.11.21. Hozzáadva a könyvtár kiürítése Felhasználók külön szabály az információbiztonsági felhasználók létrehozásával a vevőben (részletek itt). Hozzáadott maradványok számítógépes átvitele Szervezetek alkalmazottai(Személyi adatok). A 76.АВ és 76.ВА számlák egyenlegeinek átutalásakor ellenőrizhető és korrigálható a második alkonto hibás minősítése.

      2016.08.11. A dokumentumok listája kibővült.

      2016.10.28. Dokumentumok továbbítása. Hozzáadva az átvitel demóját, ez a BP 2.0 demo adatbázis átvitelének eredménye.

      2016.10.26. Üres dokumentumok létrehozása az egyenlegek számlaegyenlegek jelenlétében történő rögzítéséhez 10.07

      2016. 09. 09. Frissítés a BP 3.0.44.102 verzióra

      2016. 03. 23. Javított adatátvitel a kapott számlákon (készletmaradványok átvitele esetén)

      2016/01/11 Hozzáadva az egyének elérhetőségének, állampolgárságának, útlevél adatainak, a fogyatékosságra vonatkozó információknak, az egyének állapotának továbbítása. Hozzáadott szabályok a bankszámlák és a cikkszámlázási számlák átviteléhez.

      2015. 12. 23. A BP 3.0.43.29 frissítése. A vállalkozók és kapcsolattartóik elérhetőségeinek továbbítása.

      2015.12.14 Létrehozták a BP 3.0.42 szabályait

      A csomag tartalmazza: átszállási szabályokat "ACC20_30"és feldolgozása Adatátvitel_a_BP20_ -tól_BP30 -ig... Ha szervezetének nincs teljes munkaidős programozója a munka elvégzésére, készen állunk arra, hogy felajánljuk szakemberünk szolgáltatásait (a programozó az interneten keresztül, a speciális program távmunkára és elvégzi a szükséges munkát). Ha lehetőség van munkabázis biztosítására "1C: Számviteli 8. kiadás 2.0", magunk továbbíthatjuk az adatokat, és átvihetjük a fájlt " 1C: Számviteli 8. kiadás 3.0»Átvitt maradványokkal. Ennek a szolgáltatásnak a költségeit nem tartalmazza a csomag teljes ára.

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

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

      Néhány szó az adatok átviteléről egy tipikus konfigurációról " Könyvelés", 4.5. Kiadás az 1C számára: Enterprise 7.7 vagy konfiguráció" "(a továbbiakban: Configuration-source) egy tipikus konfigurációra" Vállalati könyvelés", 3.0-s verzió az 1C: Enterprise 8-hoz (3.0.52-es verzió), a továbbiakban" Konfiguráció-címzett ".

      FONTOS! Adatátvitel a konfigurációból lehetséges Könyvelés 4.5. kiadás 1C -hez: Enterprise 7.7, 7.70.569 és újabb verziók, 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 az előző időszak rutinműveleteinek befejezése után egy új időszak (év, negyedév, hónap) elején váltson át a forráskonfigurációról a fogadó konfigurációra.

      Az adatátvitel speciális feldolgozással történik, amely kirakja az adatokat a forrás konfigurációs információs bázisból egy XML formátumú fájlba. A kapott fájl univerzális adatbetöltési feldolgozással kerül betöltésre a címzett konfigurációjának információs bázisába.

      ACC_ACC8 .ert - külső feldolgozás adatok kicsomagolása egy külső fájlba a konfigurációból " Számvitel, rev. 4.5»;

      USN_ACC8 .ert - az adatok külső fájlba történő kiürítésének külső feldolgozása a " Egyszerűsített adózási rendszer, szerk. 1.3»;

      ACC_ACC8 .xml - adatkonverziós szabályok.

      USN_ACC8 .xml - adatkonverziós szabályok.

      Az alábbiak kerülnek át az információs bázis forráskonfigurációiból a cél konfigurációba:

      - információk a konfigurációs infobázis forrás folyószámla -egyenlegeiről az infobázis -konverzió időpontjában;

      - aktuális dokumentumok, amelyek dátuma meghaladja az információs bázis átalakításának dátumát.

      Az átalakítás két szakaszban történik:

      - a forráskonfigurációs adatbázisból származó adatokat külön fájlba (adatfájlba) töltik fel;

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

      A telepítés feldolgozásának telepítéséhez használja a setup.exe fájlt. A program indítása után (ha az 1C: Enterprise információbázisok száma nagy, akkor egy idő után) megjelenik egy párbeszédpanel, amelyben ki kell választania azokat az információs bázisokat, amelyekre telepíteni kell az adatátviteli feldolgozást. Az ablak úgy néz ki, mint az 1. ábrán. Ha az infobázisok száma több mint hét, akkor a "fel" és "le" gombokkal navigálhat. Ha több infobázis van kiválasztva, akkor az „elérési út” sor csak az utoljára kiválasztott adatbázis helyét tükrözi. Ez az információ kiegészítő jellegű, és tetszés szerint használja fel a felhasználó számára a telepítőprogram eredményének további ellenőrzésére, ne fordítson különös figyelmet arra, a program maga határozza meg, hogy a kiválasztott infobázisok hol vannak telepítve.

      1. ábra Az infobázis kiválasztása ablak a telepítés során

      Ezenkívül megadhatja azt a mappát, amelybe az adatátviteli feldolgozás is telepítésre kerül; ehhez használja a mappaválasztó ablakot (kattintson a hárompontos gombra). A kiválasztott mappa teljes elérési útja megjelenik a kiválasztó sávon. A "telepítés" gombra kattintás után a telepítés végrehajtásra kerül szükséges fájlokat a kiválasztott információs bázisokra és / vagy a kiválasztott mappába. A befejezés után rákattinthat a "részletek" gombra, és megtekintheti a részletes telepítési naplót, mely fájlokat és mappákat rögzítette. Ennek eredményeként a következő képnek kell megjelennie a kiválasztott mappában, lásd 2. ábra.

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

      Alkönyvtárba ExtForms feldolgozási és továbbítási szabályokat állapítanak meg. Kérjük, vegye figyelembe, hogy a feltöltés feldolgozása ACC_ACC8 .ertés az adatkiürítési szabályok felváltják a tipikus feldolgozást és szabályokat. Ha meg szeretné tartani a tipikus átmeneti mechanizmust, telepítse az új feldolgozást egy külön könyvtárba, és ne az információs bázisba.

      A telepítési folyamatot részletesebben ismertetjük a jelentés telepítésének példáján keresztül " A konfiguráció elszámolásának gyorsellenőrzése "1C: Számvitel 7.7«.

      Egy programban " 1C: Számvitel 7.7»Ki kell nyitni innen további lehetőségeket feldolgozás " Átmenet az 1C -re: 8. számvitel, szerk. 3.0«, Válassza ki az átviteli szabályokat tartalmazó mappát (lásd a 3. ábrát), és töltse be a csereszabályokat. Nem kell minden átigazolási szabályt tartalmaznia. Csak azokat használja, amelyek szükségesek, például egyenlegek, egyenlegek és dokumentumok átviteléhez. Például a könyvtárak csoportjában semmilyen szabály nem szerepelhet, mert minden könyvtárat linkek mozgatnak, szükség szerint, azaz csak azok, amelyek vagy egyenlegekben vagy dokumentumokban vesznek részt. Ez biztosítja, hogy ne legyen "szemét" az új információs bázisban. A dokumentumoknak sem kell mindent tartalmazniuk. Például, ha néhány dokumentum nincs az adatbázisban, vagy nem szeretné átvinni őket, akkor nem kell engedélyeznie ezt a szabályt.

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

      Azt javaslom, hogy az adatfájl nevét állítsa "C: \ v77_v8 \ Exp77_80.xml" -re, ez a mappa gyakran használatos alapértelmezés szerint a programban " 1C: Számvitel 8"Amikor adatokat tölt be a programokból a 1C: Vállalati 7.7". Ha szükséges, állítsa be a paramétereket az oldalon " Lehetőségek«.

      Az adatoknak a konfigurációból történő kiürítése során " Számvitel 7.7»Különféle hibák fordulhatnak elő. Az itt bemutatott átviteli szabályok annyiban különböznek a jellemzőktől, hogy az adatok kirakásának szakaszában keresést hajtanak végre tipikus hibák... Nézzük meg közülük azokat, amelyekről az üzenetek megjelennek.

      Nulla mennyiségű és nem nulla mennyiségű áru és anyag... Lehetetlen megadni a mérleget a vevő konfigurációjában úgy, hogy az anyag mennyisége nulla legyen, és az anyag költségbecslése nem egyenlő nullával, lehetetlen, és értelmetlen, mert ez hiba. Ezért az egyenlegek átutalásakor az ilyen tételek (nulla mennyiséggel) nem jelennek meg a mérlegbeviteli dokumentumokban. Ezért ha az adatátvitel előtt nem javítják ki a hibákat, akkor az egyenlegátvitel során az adatforrásban és az adatfogadóban lévő összegek nem esnek egybe, ami további nehézségeket okoz az egyeztetésben. Ezért az adatok konfigurációból történő kiürítése során " Számvitel 7.7»Megjelennek a felmerült hibákról szóló üzenetek (lásd 4. ábra). Ezenkívül a hibák kereséséhez javasolhatja az "Expressz könyvelési ellenőrzés" feldolgozást, nevezetesen a "Nullától eltérő összeg hiánya nulla mennyiségű anyagnál" szabályt.

      4.1. Ábra Hibaüzenetek

      Nem nulla egyenleg a második (harmadik) szintű részkontogon, míg az egyenleg az első (második) szinten nulla. Ez a hibás elszámolás meglehetősen gyakori helyzete. Egy tipikus példa a 4.2. Ez az állapot az analitikus számvitel „rossz besorolása” következtében keletkezik. Például a pénzforgalmi dokumentumokban a szerződés fel van tüntetve, de nincs szerződés az áruk és anyagok tőkésítési dokumentumaiban, vagy fordítva, vagy vannak szerződések, de eltérőek. Mindezekben az esetekben nem szerződéses egyenleg van, míg a partner egyenlege nulla. Hasonló kép alakulhat ki az anyagok és tételek elszámolásánál (ha a tárolási helyek teljes elszámolása is benne van): a raktárak közötti osztályozás, különösen, ha a raktárak anyagilag felelős személyek.

      4.2. Ábra Példa számviteli hibákra

      Világos, hogy ez hiba, és egyértelmű, hogy nincs értelme az ilyen maradékokat átvinni. Az ilyen típusú egyenlegek átvitelének kizárása érdekében van egy paraméter: "Ne töltse le a mérleget, ha a legfelső szinten nulla egyenleg van." Ha ez a paraméter egyre van állítva, akkor a kirakodás során az ábrán látható üzenetek jelennek meg. 4.3 (hasonlítsa össze a 4.2. Ábrával), és az ilyen pozíciókból származó maradék nem lesz kirakva. Ennek a paraméternek a különböző kombinációit használhatja a különböző egyenlegek átvitelére vonatkozó szabályokkal. Ha nem egyszerre, hanem a számviteli szakaszok szerint utalja át az egyenlegeket, akkor átviheti a különböző számviteli szakaszok egyenlegeit, különböző paraméterértékekkel.

      4.3. Hibaüzenetek

      A szerződések vagy mások szerződéseinek üres értékei. A probléma hasonló a fent leírtakhoz, az ok ugyanaz - a szerződés szerinti analitikai számvitel téves minősítése (lásd 4.4. Ábra). De a partner egyenlege nem nulla, így a fenti ellenőrzési szabály nem fog működni. Az adatok átvitele során hiba lép fel a mérlegbeviteli dokumentum közzétételekor, mert üres szerződésérték nem megengedett.

      4.4 ábra Hibajelentés

      Az ilyen hibák kizárásához az átvitel előtt az adatfeltöltés szakaszában hibaüzenetek jelennek meg (lásd 4.5. Ábra). Ugyanez az ábra azt mutatja, hogy újabb hiba történt: a szerződés nem felel meg a másik félnek, azaz a szerződés tulajdonosa egy másik fél. Ilyen hibákat gyakran találnak a módosított, azaz atipikus konfigurációkban vagy régóta működő adatbázisokban, amikor a szabványos konfigurációkban a dokumentumok kitöltésekor nem ellenőrizték kellően szigorúan a szerződések betartását.

      4.5. Ábra Számviteli hibaüzenetek

      A szerződések és más szerződések ü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 partnernek való megfelelést". Ezenkívül a hibák kereséséhez javasolhatja a "Számviteli gyorsellenőrzés" feldolgozását, nevezetesen a "Kitöltetlen elemzések hiánya a szerződések alapján" és a "Partnerek és szerződések megfelelősége" szabályokat.

      Vannak más hibaellenőrzések is, a tisztázás érdekében vegye fel velünk a kapcsolatot (elérhetőségek az oldal alján).

      Megmutatjuk, hogyan lehet részletekben továbbítani az adatokat, és nem teljesen, egy bizonyos típusú dokumentumok vagy akár egy kiválasztott típusú dokumentumok másolatának példáján keresztül. Jelöljük csak az adatkiürítés egyetlen szabályát " Fizetési felszólítás"(Lásd az 5. ábrát). Ez lehetővé teszi, hogy csak a „ Fizetési felszólítás". Ha megnyomja a gombot " Kirakodás", Majd az űrlap összes dokumentumát" Fizetési felszólítás"Időintervallumban található" kezdő dátum" tovább " lejárati dátum". Nyomja meg a gombot " Telepítse az LDPE -t", Utána a felirat" Adatok kiválasztása a fizetési megbízáshoz«.

      5. ábra Hogyan lehet szabályt beállítani egy bizonyos típusú adat feltöltésére

      Ezután megnyomjuk a „Feltétel hozzáadása” gombot, és kiválaszthatjuk a kiválasztáshoz szükséges elemet (lásd a 6.1. Ábrát), leggyakrabban „ CurrentDocument«, Ez lehetővé teszi, hogy külön dokumentumot válasszon ki az ilyen típusú dokumentumok listájából. A kiválasztás egyéb részleteit használva dokumentumok csoportja választhat ki, például kiválaszthatja a dokumentumokat dátum szerint. A dokumentumok kiválasztása minden esetben időintervallumon belül történik, paraméterek adják « kezdő dátum"és" lejárati dátum«.

      6.1. Ábra Az egyes dokumentumok kiválasztása

      Fontos! "1C"), amely egyes konfigurációkban nem teszi lehetővé a dokumentumok kiválasztását a kiválasztás részletei szerinti kirakodáskor. Ez annak köszönhető, hogy ben modell szabályai a dokumentumok kiválasztása kérésre történik, az időszak megadása nélkül. Az ilyen lekérdezések nem mindig működnek.

      Hasonló módon ki is töltheti a könyvtárakat, nem a teljes könyvtárat, hanem valamely attribútum kiválasztásával. Először válassza ki a szükséges adatfeltöltési szabályt, majd nyomja meg egymás után a „ Telepítse az LDPE -t"és" Feltétel hozzáadása". A 6.2 ábra például azt mutatja be, hogyan lehet csak azokat az alkalmazottakat kirakni, akikkel a programból való átmenet idején " 1C: Egyszerűsített adórendszer, szerk. 1.3" tovább " 1C: Vállalati számvitel, 3.0 verzió"(Vagy, ahogy a felhasználók gyakran mondják, a számviteli 7.7 -ről 3.0 -ra való átmenet), munkaviszony jött létre.

      6.2. Ábra A könyvtárelemek csoportjának kiválasztása

      Fontos! Az adatátvitelre vonatkozó javasolt szabályokban a standard szabályok hibáját kijavították (a vállalattól "1C"), ami a könyvtár elemeinek helytelen kiválasztásához vezet, amikor a könyvtár időszakos követelményei szerint kirakod, pl. azok, amelyek különböző értékekkel rendelkeznek különböző dátumokra. Ez annak a ténynek köszönhető, hogy a szabványos szabályokban a könyvtárelemek kiválasztását egy lekérdezés végzi anélkül, hogy pontot adna meg.

      A referenciakönyv 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 adatkiürítési szabályok és szűrők kombinációját. Azokat a szabályokat, amelyekhez a kiválasztás van beállítva, "[SELECTION]" jelzi. Egy adott adatkiürítési szabály kiválasztásának megtekintéséhez vagy szerkesztéséhez kattintson duplán erre a szabályra a szabályok listájában, vagy ha kiválasztja, nyomja meg a «gombot Telepítse az LDPE -t«.

      Fontos! Ha az objektumok kiürítése üresnek vagy befejezetlennek bizonyul, ellenőrizni kell, hogy az 1C: Accounting 8. szinkronizálási mód be van -e állítva. Ha igen, akkor csak azokat az objektumokat kell kirakni, amelyek az elvégzett átvitel után megváltoztak (Referenciakönyv). ... Teljes munka szinkron módban lehetetlenné válik. A szinkronizálási módot a csereszabályok betöltése után ellenőrzik. Ha az üzemmód be van állítva, figyelmeztető ablak jelenik meg (lásd 6.5. Ábra), és felajánlja a szinkronizálási mód letiltását.

      Rizs. 6.5 Szinkron mód figyelmeztető ablak

      További eltérések a szokásos szabályoktól

      Kijavítottuk a hibát az IT&M régi nyugtatípusokkal való átvitelénél: ha az Áruk és Szolgáltatások Nyugta dokumentumokban a nyugta típusa 2 (elavult érték), és nincs szállítói számla, akkor a dokumentum hibás átalakítása BP 3.0 -ra a visszaküldési okmány érkezik a vevőtől.

      Kijavítottuk a hibát, amikor a manuális műveleteket átvittük a felosztási alosztályra a BP PROF verzióra. Az ilyen műveletet nem rögzíti a BP, hiba lép fel: "Az OU mezőnek üresnek kell lennie." Ez annak köszönhető, hogy a szabályokat úgy tervezték, hogy működjenek a CORP verzióival, azonban a TRAC -ban a számviteli nyilvántartás DepartmentDt és DepartmentKt méreteinek üresnek kell lenniük.

      Javítva egy hiba, amely ismétlődő címtárcsoportokhoz vezet Szerződésekés ennek következtében a könyvtár elemeinek megkettőzésére (mivel a betöltéskor történő keresés a szülő figyelembevételével történik). Ezt szemlélteti a 6.6.

      6.6. Ábra A könyvtárátvitel eredménye Szerződések modell szabályai

      Itt az oszlopban Szülő(könyvtárcsoport) névvel 2015 a címtárnak két különböző csoportja van azonos nevű (a forrásban csak egy csoport van), ezért a szerződések megismétlődnek.

      Javítva a banki dokumentumok átutalásának hibája, amikor pénzt utalnak át egyik folyószámláról a másikra. V BP 3.0 ebben az esetben egy dokumentum jön létre Leírás a folyószámláról a művelet típusával Átutalás a szervezet másik fiókjára, amelyet nem hajtanak végre annak a ténynek köszönhetően, hogy a szükséges anyag nincs kitöltve Kedvezményezett számla... Ezenkívül a részletek helytelenül vannak kitöltve. Számviteli számlaés Betéti számla... Ez nyilvánvalóvá válik, ha eltérnek egymástól, például 55 és 51, akkor cserélni kell őket. Javítva a hiba, hogy nem töltötte ki a kellékeket Kötelezettség típusa az adók átutalására vonatkozó dokumentumokban. A fentiek mindegyike vonatkozik a 3.0.43.215 verzióra.

      A kellékek átkerülnek főszerződés kézikönyv Vállalkozók.

      A könyvtár kirakásának szabálya megváltozott Elnevezéstan, most az adatkiválasztási módszer egy standard kiválasztás, amely lehetővé teszi a referenciakönyv elemeinek részletek szerinti kiválasztását (az USN 7.7 - BP 3.0 szabványszabályaiban ez lehetetlen). Könyvtár átvitelénél Elnevezéstan, átviszik és Tétel árak linkekkel, azaz csak az átadott tételek árai. A funkció engedélyezéséhez a paraméter értékét egy értékre kell állítani Tételek kirakásakor ürítse ki az árakat.

      Kijavítottuk a hibát a szabványos "USN 7.7 - BP 3.0" szabályokban, amikor a partnerekkel történő elszámolások egyenlegeit átutaltuk: a szerződés típusát mindig Egyéb... Most - az egyenleg típusától függően, a számviteli szakasz szerint " Számítások beszállítókkal és vállalkozókkal"A szerződés típusa =" Támogató", A számviteli szakasz szerint" Elszámolás a vevőkkel és az ügyfelekkel"A szerződés típusa =" A vevővel", Más esetekben a szerződés típusa =" Egyéb«.

      Kijavítottuk a hibát a "USN 7.7 - BP 3.0" szabványos szabályokban, amikor a partnerekkel történő elszámolások egyenlegeit átutaltuk: a kölcsönös elszámolások összegét a kezdeti egyenlegbeviteli dokumentum két részletében rögzítették Összegés ÖsszegKt... Emiatt a kezdeti egyenlegek megadására szolgáló dokumentumot nem tették közzé.

      Jelölje beA vevővel"(A szokásos szabályokban" Egyéb"). A változó értéke " Fizetési állapot", Ez fontos a számára a helyes választás számlákat a fizetésről az ügyfélnek banki fizetési dokumentumokban a címzett konfigurációjában.

      Az űrlapon lévő dokumentumok átvitele során " Fizetési felszólítás"A szerződés típusa" A szállítóval"(A szokásos szabályokban" Egyéb«).

      Javítva egy hiba az USN 7.7 - BP 3.0 szabványos szabályokban a tárolási helyek átvitelénél: a változó " Raktári típus«.

      Hozzáadott paraméter " Csere a szabályozó hatóságokkal«: Ha értéke 1, akkor a kellékek Az Exchange -ellenőrző szervek típusa a könyvtár eleme " A szervezet"Be van állítva" Csere univerzális formátumban", Különben" ExchangeDisabled»Mint a modell szabályaiban. Ez fontos az ismételt (rendszeres) átutalásoknál, hogy ne rontsa el az EFA beállítását.

      Megváltozott a betöltött elemek keresésének szabálya a könyvtárhoz " Vállalkozók«: Az első keresést a FOGADÓés Ellenőrző pont(ha ezeket az értékeket kitölti), akkor csak FOGADÓés végül által Név... Mindhárom esetben a csoportattribútum (ThisGroup) és maga a csoport (Szülő) is részt vesz a keresésben. Ez fontos az ismételt (rendszeres) átutalásoknál, nehogy duplikátumokat hozzon létre a betöltés után megváltozott nevű partnerek számára.

      A szerződő felek átruházásakor a szükséges kitöltésre kerül A regisztráció országa jelentése "Oroszország". Erre azért van szükség, hogy a partnerek könyvtárának betöltése után a programba "1C számvitel 8" Nem kellett manuálisan kitöltenem a szükséges adatokat A regisztráció országa... Ha nincs kitöltve, akkor könyvtári elem formájában " Vállalkozók"A kellékek rendelkezésre állnak" Adószám"és" Reg. szoba", És a kellékek" FOGADÓ"és" Ellenőrző pont"Rejtve lesz.

      Az "USN 7.7 - BP 3.0" átviteli szabályokhoz hozzáadott egy szabályt az adatok kiürítéséhez az "Alkalmazottak" címtár átviteléhez (a szabványos szabályokban csak az egyének címtára kerül át).

      Az "USN 7.7 - BP 3.0" átviteli szabályaiban kijavították az "Aktuális tarifális bázis alkalmazottak" információnyilvántartás továbbítására vonatkozó szabályt.

      A fizetési megbízások adófizetésre történő átutalásának sajátosságai

      Műveleti típussal rendelkező fizetési megbízásokhoz Adó átutalása további részleteket kell kitölteni: KBK - költségvetési besorolási kód, kezdeményező állapota stb. Ezen kellékek szerkezete Bukh 7.7 (USN 7.7) és ben BP 3.0 nem egyeznek. Különösen ben BP 3.0 ezen adatok némelyike ​​külön könyvtárban található, amelynek linkjét a fizetési megbízás tartalmazza. Könyvtár Az adók és a költségvetésbe történő befizetések típusai számos olyan szállított elemet tartalmaz, amelyek az információs bázisban jelennek meg, például számviteli politika szerkesztésekor. Adatátvitelkor ezek a tételek a számviteli politika betöltésekor is megjelennek. A fizetési megbízások ki- és betöltésekor egy címtári elem Az adók és a költségvetésbe történő befizetések típusai a KBK helyettesítést keresett a fizetési megbízás részleteiben Adó... Ezért ajánlott, hogy a számviteli politika átadása után ellenőrizze, hogy minden szükséges adó megjelent -e a referenciakönyvben, szükség esetén kiegészítve. Amikor összehasonlítja (szinkronizálja) a BCC-t a fizetési megbízásokban a forrásban és a vevőben, négy BCC számjegyet, 14-17 kategóriát, a jövedelem alfaj kódját nem veszi figyelembe: adó, szankciók, szankciók stb. A referenciában Az adók és a költségvetésbe történő befizetések típusai ezek a bitek nullákkal vannak tele. Amikor új elemeket ad hozzá a könyvtárhoz, a 14-17 számjegyeket is nullákkal kell kitölteni.

      Nagy információbázisok átvitele.

      Először is, nagy adatbázisok átvitelénél az adatok kiürítése nagyon sokáig tarthat. Ez akkor fordul elő, ha egy számviteli szakaszban nagy mennyiségű egyenleg található, például árumérleg. A kirakodás idejének csökkentése érdekében alkalmazhatja az egyik dokumentum felosztásának technikáját " Kezdeti maradványok megadása"néhánynak. Ha beállítja a paraméter értékét " A dokumentum sorainak száma a maradványok beviteléhez»A nullától eltérő (lásd a 6.3. Ábrát), akkor az adatok egyetlen dokumentumba történő feltöltése 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 adatátvitelkor, dokumentumméret korlátozással " Kezdeti maradványok megadása»

      Megjegyzés: ennek a paraméternek az értéke korlátozza a tranzakciótábla egy dokumentumba feltöltött sorainak számát " Kezdeti maradványok megadása”, Ahelyett, hogy maga a dokumentum sorainak számát adná meg. Ezért a dokumentum sorok száma eltér a paraméter értékétől, ez nem hiba. Dokumentum felosztásakor " Kezdeti maradványok megadása"Több dokumentum esetén a sor végén minden dokumentum megjegyzéseihez postfix kerül:" -1 "," -2 "stb.

      FONTOS! A leírt algoritmus egy dokumentum felosztására " Kezdeti maradványok megadása»Csak kevesen használják az adatok feltöltésének idejének csökkentésére, minden dokumentum egy fájlba kerül feltöltésre, azaz 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.

      Nagyméretű információs bázisok átvitele esetén az elégtelen RAM problémája merülhet fel: amikor megpróbál kirakni, a program a megfelelő hibaüzenettel vagy üzenet nélkül leáll. Hiába próbálja lecserélni a számítógépet egy erősebbre, haszontalan. Ebben az esetben az adatokat darabokra kell kirakni, részekre osztva. Ehhez olyan áttelepítési szabályok szükségesek, amelyek támogatják a megadott módot. Gondoljuk végig, hogyan kell kirakni. Először is az adatátvitelt csak egy feltöltési szabály alkalmazásával kell végrehajtani (lásd 6.4. Ábra). Ha az átvitel egy szabály szerint nem lehetséges, akkor részekre osztjuk, feltüntetve a kezdeti és a végső részt. Mindegyik rész bizonyos számú első szintű elemzési értékre vonatkozó információt tartalmaz, például termékmérleget, azaz a számlaegyenlegek meghatározott számú értéke "41". A fiók összes elemzésének ismeretében könnyen kiszámítható az adagok száma. Azt, hogy mennyi adatot továbbítanak problémamentesen egy időben (egy információban), empirikusan kell meghatározni, általában, amikor a számlaegyenlegek kiürítésekor átviteli problémák jelentkeznek, ha az egyenlegek száma több ezer vagy több. Bár az adatok feltöltésére fordított idő megtakarítása érdekében javasoljuk a részekre bontást, még akkor is, ha a könyvelési szakasz összes egyenlegét egyszerre ki lehet tölteni. A kirakodási idő az adatrész méretétől függ nem arányosan, nem lineárisan. Ezért, ha például tízezer egyenleget áruval tíz ezrelékre bont, akkor időnként csökkentheti a kirakodás idejét. Ha átvisszük az első részt, akkor az első rész száma elhagyható, ha az utolsó rész, akkor az utolsó rész.

      FONTOS! Az adatok részenkénti továbbításakor a paraméterekben meg kell jelölni azt a postfixet, amely részt vesz a dokumentum megjegyzésének kialakításában „ Kezdeti maradványok megadása". Amikor módosítja a résztartomány számát, ne felejtse el megváltoztatni a postfixet, különben az azonos megjegyzéseket tartalmazó dokumentumok (postfix) felülíródnak, amikor betöltik a Fogadó konfigurációba. Az adatfájl neve nem igazán számít. Alkalmazhat szekvenciális átviteli taktikákat: unload - load, unload - load, stb. Ebben az esetben az adatfájl nevét nem kell megváltoztatni. Választhat egy taktikát: először tegyen ki mindent, majd töltsön le mindent. Ez utóbbi esetben az adatfájl nevét minden feltöltéskor meg kell változtatni. Egy másik példa. Ha a számviteli szakasz egyenlegeinek számát (például áruk), például 10 000 -et ezerrel osztjuk részekre, akkor 10 adagot kap. Minden résznek egyedi utótaggal kell rendelkeznie: "-1", "-2", "-3", "-4". Ha kirakjuk az áruk maradékát, majd mindent betöltünk, akkor az adatfájloknak is egyedinek kell lenniük, például: „41_1”, „41_2”, „41_3”, „41_4”. A "Batch number start" és a "Batch number end" paraméterek értékeit kell megadni: 0, 1000; 1001,2000; 2001, 3000; 3001, 4000.

    • Amikor az elbocsátás után a munkatapasztalat megszakad 2007. január 1 -jétől az állampolgár munkatapasztalatának folyamatosságának meghatározására kissé eltérő eljárás volt érvényben. Előtte, ha nem telt el 3 hét, amikor egyik munkahelyről a másikra költözött, akkor a szolgálati idő nem szakadt meg. 2007 óta [...]
    • ANKO Tambov Törvényszéki Vizsgálati és Kutatási Központ, ANO ANKO Tambov Törvényszéki Vizsgálati és Vizsgálati Központ, ANO bejegyezve: Tambov, Rabochaya str., 37, 40. iroda, 392008. A szervezet igazgatója A TAMBOVSKY CENTRAL AUTONOMUS NON-PROFIT ORGANIZATION ...
    • Rendelés a munkaidő -beosztásról Mintarendelés a munkaidő -beosztásról A munkaidő -beosztásról Az Orosz Föderáció Munka Törvénykönyve 100., 103., 104., 73. cikke és a PJSC "Szervezet" belső munkaügyi szabályzata szerint , a vállalkozás működésének optimalizálása és [...]
    • Az eljáró társaság a Jekatyerinburgi 20. számú Központi Városi Kórházba nevezték ki, ahonnan a főorvost kirúgták | Szverdlovszk régió | Alena Tuniszt, az Uráli Szövetségi Kerületet nevezték ki a Jekatyerinburgi 20. számú Központi Városi Kórház megbízott főorvosának. Ahogy a tudósító beszámol [...]
    • Ohm törvénye párhuzamosan Kezdőlap Emlékezzen a fizikára: 7. évfolyam 8. évfolyam 9. évfolyam 10. évfolyam 10-11. Évfolyam Videók a fizika multimédiájáról 7. évfolyam. multimédia 8 cl. multimédia 9 cl. multimédia 10-11 cl. csillagászati ​​tesztek 7 cl. vizsgálatok 8 cl. tesztek 9 cl. a vizsga bemutató táblázata [...]
    • Az RSFSR törvénye "A versenyről és a monopoltevékenység korlátozásáról az árupiacokon" 1991. március 22. N 948-1 (az Orosz Föderáció 1992. június 24-i törvényeivel módosítva, N 3119-1, 1992. július 15. N 3310-1; Szövetségi törvények 1995.05.05-től N 83-FZ, 1998.05.06-tól N 70-FZ, 2000.01.02-től N 3-FZ, [...]


Tetszett a cikk? Oszd meg