Typická pravidla pro přenos dat 1c. Příklad pravidla pro převod objektů. Vlastnosti typických pravidel přenosu

Účelem tohoto směnného pravidla je převést zůstatky vzájemného vypořádání z BP 2 do UT11.

Postupné vytvoření pravidla výměny pomocí konfigurace „Převod dat“ (je třeba načíst metadata):

1) Za tímto účelem vytvořte pravidlo pro uvolnění objektu, přejděte na kartu „Pravidla pro uvolnění dat“ a klikněte na Přidat. V okně, které se objeví, vyberte ukázkový objekt, pro nás to bude samonosný registr. Metodu vzorkování změníme na libovolný algoritmus.

2) Pojďme k psaní samotného kódu. Protože v UT není žádný samonosný registr, musíme jej transformovat. Nejprve potřebujeme požadavek, který podle našich parametrů vrátí zůstatky pro vzájemné vypořádání. V obslužné rutině události „Před zpracováním“ napište následující požadavek:

V mém úkolu byla omezení pro skupiny protistran, pro které jsou vykládky vykládány.

Určujeme hodnoty proměnných, které budou použity v budoucnu.

ByDate \u003d date ("20130101");
TD \u003d CurrentDate ();
group \u003d Directories.Contractors.FindByDesign ("Kupující");
group1 \u003d Directories.Contractors.NaytiByName ("Refunds from INDIVIDUALS");

Vytvoříme tabulku, kterou později přeneseme do pravidla převodu hodnoty.

TK \u003d New ValueTable ();
TK.Kolonki.Add ("protistrana");
TK.Kolonki.Add ("Částka");
TK.Kolonki.Add ("SumREGL");
TK.Kolonki.Add ("Dokument o vypořádání");
TK.Kolonki.Add ("datum dokladu o vyrovnání");
TK.Kolonki.Add ("číslo zúčtovacího dokladu");
TK.Kolonki.Add ("partner");
TK.Kolonki.Add ("měna vypořádání");
TK.Columns.Add ("datum platby");

Nastavíme parametry, vyvoláme požadavek, vyplníme tabulku a vyvoláme pravidlo převodu.

požadavek \u003d nový požadavek (text požadavku);
request.SetParameter ("skupina", skupina); request.SetParameter ("skupina1", skupina1);
request.SetParameter ("OnDate", OnDate);
request.SetParameter ("Účet", Plány účtů. Samonosné.CalculationsWith Ostatní dodavatelé a dodavatelé); // 76.05
Načíst \u003d Query.Run (). Select ();
TK.clean ();
While Fetch.Next () Loop
pokud Sample.SumResponseCT \u003d 0 nebo Sample.SumResponseCT \u003d "" pak
pokračovat;
konec pokud;
pokud Sample.SumResponseKT< 0тогда
report ("" + Sample.Subkonto1 + "záporná hodnota" + Sample.SumRemainst hodnota);
konec pokud;
Řetězec TK \u003d TK.Add ();
Řetězec TZ.Contractor \u003d Sample.Subconto1;
Řetězec TZ.sum \u003d Selection.SumRemainst; // Selection.SumResponseKt;
Řetězec TZ.sumRegl \u003d Selection.SumResponseKt; // Selection.SumResponseKt;
Řetězec TZ.Date of SettlementDocument \u003d Sample.Date of SettlementDocument;
Řetězec TZ.Number of SettlementDocument \u003d Sample.Number of SettlementDocument;
Řetězec TZ.PaymentDate \u003d AP;
Konec cyklu;
OutgoingData \u003d nová struktura;
OutgoingData.Insert ("Date", CurrentDate ());
OutgoingData.Insert ("CalculationWithPartners", TK);
OutgoingData.Insert ("TransactionType", "DebtBelowBeforeSuppliers");
OutgoingData. Insert („Komentář“, „Zformováno na účtu 76,05 kreditu“);
report ("76.05 KREDIT start");
UnloadByRule (, OutboundData, "Entering BalancesByMutual Settlements_7605Credit");

Podobně provádíme stejnou operaci se zbytkem požadovaných účtů (jejich popis i připravené pravidlo je v příloze).

3) Přejít na vytváření pravidel pro převod objektů, otevřete tuto kartu „Pravidla pro převod objektů“. Přidejte tam nové pravidlo s názvem „Balance Entry by Mutual Settlements_7605Credit“, zdrojový objekt nechejte prázdný, nastavte objekt příjemce na dokument „Enter balances“, zrušte u nastavení příznak „Hledat objekt příjemce podle interního identifikátoru zdrojového objektu“ záložka.

V obslužné rutině události „Před načtením“ napište následující kód:

Generovat NewNumberORCodeIfNOTSpecified \u003d true;

Do obslužné rutiny události „Po načtení“ napište:

execute (algorithms.AfterLoadingInputResults);

provede algoritmus s následujícím obsahem:

měna \u003d Constants.CurrencyRegulatedAccounting.Get ();
object.Responsible \u003d SessionParameters.CurrentUser;
object.organization \u003d parameters.organization;
pro každou stránku z objektu smyčka výpočtů partnera
Page.AccountingDocument \u003d Directories.Contractors 'agreement.blank link ();
Stránka měny vypořádání \u003d měna;
pokud ValueFilled (protistrana stránky), pak
page.partner \u003d page.partner.partner;
v opačném případě
part \u003d Directories.Partners.FindByDesign (stránka counterparty.Description);
pokud je součástí<> Nedefinováno a rozděleno<> Directories.Partners.blank link () poté
p. partner \u003d stoly;

object2.Partner \u003d párty;
object2.Write ();
v opačném případě
vykonat (algorithms.AddPartner);
konec pokud;

konec pokud;

konec cyklu;

Tento algoritmus bude proveden na straně přijímače (BP). Kromě převodu zůstatků pro vzájemné vypořádání je úkolem převést protistrany, ale partneři se používají v UT, proto po vytvoření dokumentu zkontrolujeme, zda jsou všechny protistrany a partneři k dispozici v databázi příjemce, pokud pro některé protože nejsou, pak je přidáme.

Přidáním protistran bude implementováno pravidlo převodu pro adresář „Účty“. Můžete jej vytvořit stejným způsobem jako předchozí pravidlo, ale umožnit systému mapovat požadovaná pole sama.

Pro partnery byl vytvořen algoritmus, který běží na straně příjemce.

Chcete-li spustit algoritmus na straně přijímače, v pravém horním rohu okna algoritmu (při jeho úpravách) zaškrtněte příznak „Použito při spuštění“.

Níže je uveden kód algoritmu „Přidat partnera“:

nPartner \u003d Directories.Partners.CreateItem ();
nPartner.Name \u003d page.contract.name;
nPartner.Comment \u003d "Vytvořeno při načítání z BP";
nPartner.NameFull \u003d page.contractor.NameFull;
nPartner.Supplier \u003d? (find (page counterparty.AdditionalInformation, "Supplier")\u003e 0, true, false);
nPartner.Client \u003d? (find (page counterparty.AdditionalInformation, "Client")\u003e 0, true, false);
OtherRelations \u003d? (Find (page counterpart.AdditionalInformation, "Other")\u003e 0, true, false);
npartner.Write ();
page.partner \u003d npartner.link;
counterparty \u003d Reference bookss.Contractors.FindByDesign (stránka counterparty.Name);
object2 \u003d contractor.GetObject ();
object2.Partner \u003d npartner.link;
object2.Write ();

Vraťme se k pravidlu převodu objektu. Nyní musíme nastavit korespondenci mezi zdrojovým a cílovým polem, mohlo to být provedeno těsně před napsáním kódu. Aby bylo možné porovnat pole ve spodní části tabulky, je zde tlačítko pro vyvolání průvodce „Synchronizace vlastností“. V tomto průvodci můžeme buď mapovat pole, nebo je nechat bez zdroje nebo bez cíle. V našem případě necháme všechna pole a PM bez zdroje.

Po výběru požadovaných polí v dolním PT pro každé pole nastavte příznak ve sloupci „Získat z příchozích dat“. Tento příznak znamená, že systém vyhledá toto pole v příchozích datech. Je důležité, aby se název pole shodoval s názvem v příchozích datech, jinak se zobrazí zpráva oznamující, že pole nebylo nalezeno.

Text nepopisuje všechny nuance procesu.

A ukážeme vám, jak jej pomocí SILNĚ zjednodušit řešení vašich úkolů

Dnes budeme analyzovat, jak nastavit a provést jednoduchý převod referenčních knih a počátečních zůstatků za pouhých 10-15 minut.

A tohle - masivní a pravidelný úkol, což je pro většinu nových spuštěných konfigurací téměř nevyhnutelné.

Zavolejte proto svým kolegům, bude to pro ně také velmi užitečné.

Zvláště pokud už viděli CD 3 a dokázali se vyděsit :)

Ano, když ji uvidíte poprvé, není to vůbec jasné.

Ale ve skutečnosti - všechno je velmi jednoduché. Tak jednoduché, že se později budete dokonce nudit :)

Co přesně je v dnešních videích

Jedná se o 4 videa o komunikaci prostřednictvím univerzální formát výměny EnterpriseData.

Ukážeme také příklad dokončení standardních burzovních pravidel v 1C: Převod dat 3.0

Celková doba trvání - 34 minut... Obsah:

Nastavení burzy na příkladu 1C: Účetnictví 8 a 1C: ERP
Jak načíst standardní pravidla a formát univerzální výměny v převodu dat 3.0
Přenos struktury metadat na CD 3.0
Jak provést první komunikaci
Upřesnění pravidel konverze
Jak načíst nová pravidla bez změny konfigurace ( bez odstoupení od podpory)

Poznámkaže při řešení tohoto problému se pravidla načítání mění pouze v konfiguraci přijímače. Konfigurace zdroje funguje podle standardních pravidel.

Pokud by byl podobný problém vyřešen v Data Conversion 2.0, musely by být provedeny změny v pravidlech zdroje i cíle.

Tyto videonávody jsou relevantní pro BSP verze 2.3.2 (pro jakoukoli sestavu starší než 2.3.2.43).

Pokud používáte starší verzi BSP 0, proveďte „opravu“ pro změněné rozhraní a rozšířenou funkčnost. Chcete-li to provést, opakujte příklad z videa sami.

Video 1:
Načítání pravidel výměny mezi typickými konfiguracemi v Data Conversion 3.0

V této lekci provedeme přípravné akce při provádění změn pravidel výměny mezi typickými konfiguracemi:

Načítání struktury formátu výměny na CD (
Vytváření konverzí
Uvolnění souborů pravidel z typické konfigurace
Vykládání modulu správce výměny

Video 2:
Úprava pravidel směny v CD 3.0

V této lekci vám ukážeme, jak vyplnit údaje o objektech při načítání dat.

Úloha bude vyřešena - při načítání objektů ze konfigurace zdroje nastavte komentář „Načteno z BP 3.0“.

Chcete-li problém vyřešit, musíte přidat změny v pravidlech pro převod objektů, v případě „Před zaznamenáním přijatých dat“.

Vytvořená pravidla budou uložena jako externí zpracování pro budoucí použití.

Video 3:
Nastavení univerzální výměny mezi typickými konfiguracemi

V tomto kurzu vám ukážeme, jak nastavit novou výměnu mezi obecnými.

Nastavení se provede ve zdrojové konfiguraci a poté se načte do cílové konfigurace.

Také v tomto videu ukážeme jak beze změny konfigurace nahrát nová pravidla výměny.

Video 4:
Přenos počátečních zůstatků pomocí směnných pravidel

V lekci si ukážeme typickou funkci pro přenos počátečních zbytků.

P.S.

Ano, výměny přes txt / dbf / ole atd. mít právo na existenci. V některých zvláštních případech, například při dokování s webovým serverem nebo při přenosu z hotového formátu externí aplikace.

Pro standardní výměny - standardní metody jsou rychlejší a mnohem jednodušší.

A pokud někdo znovu objeví kolo, když existuje hotové univerzální řešení - je to jako psát na čelo „Nevlastním nástroj, nechci studovat, postavím berle za vaše peníze“ .

P.P.S.

Chceme ukázat, že převod dat 3.0 není obtížný.

Neobvyklé - ano. Ne všechno je okamžitě jasné - ano. Existují velmi nejednoznačné body - ano.

Ale s pomocí hotových pokynů a videí to lze zvládnout doslova za 1-2 týdny.

V současné době se přechod z 1C: Enterprise 7.7 na 8.3 (podobně jako 8.2) stal pro účetní problémem. Je to žádoucí co nejrychleji a bez chyb. Pokud jste programátor v 1C: Účetnictví a potřebujete převést tyto dokumenty ze sedmé verze na osmou, pak je tento článek pro vás.

Udělejte jen pár kroků a vaše problémy s přenosem dat budou vyřešeny. Přečtěte si tento návod až do konce a uvidíte způsob, jak to udělat. Nejprve musíte připravit pracoviště na počítači pro nezbytné manipulace. Nejprve musí mít pevný disk velikost alespoň 100 GB. To je nutné, protože přenos zbytků je víceúrovňový. A budete muset pracovat s více konfiguracemi 7.7.

Pokud potřebujete rychlý a kvalitní přechod z 1C Accounting 7.7 na 1C 8.3, kontaktujte nás! Průměrné náklady na přechod na klíč u nás jsou 6600 rublů.

Přenos dat z 1C 7,7 na 1C 8,3 účetnictví 3.0

Než tedy začnete pracovat s přenosem dat na verzi 1C 8.3, musíte si tato data připravit ve verzi 7.7. Chcete-li to provést, musíte provést následující. Řekněme, že máte v počítači funkční databázi „Účetnictví pro podnik“, se kterou pracují vaši účetní. Pomocí zpracování Export77 uvolněte všechny potřebné dokumenty do textového souboru a od této chvíle se již nevracejte na hlavní pracovní základnu. K vašim dalším manipulacím dojde u jiných konfigurací.

Nainstalujte nové vydání 1C: Enterprise 7.7 do nového adresáře. (balíček obsahuje standardní prázdné (žádná data) a ukázku). Budeme pracovat se standardní verzí. Nyní spusťte tuto databázi a pomocí zpracování Import 77 načtěte data z hlavní databáze z textového souboru.

Při převodu dat nemusí být některé dokumenty zaúčtovány. Není to děsivé. Trik spočívá v tom, že to můžete po převodu snadno opravit, protože ve standardní databázi pracujete s hlavní standardní účtovou osnovou. Proto bez ohledu na to, jak sofistikované jsou podúčty, ve vaší pracovní základně je snadné jej opravit asi za 3 hodiny tím, že přejdete do každého nepublikovaného dokumentu a změníte účty, které máte ve své konfiguraci v polích účtu.

Přirozeně, předem, před převodem, přinesete účtovou osnovu standardní konfigurace v souladu s účtovou osnovou vaší hlavní pracovní základny. Možnosti jsou čistě individuální, v závislosti na specifikách práce vaší organizace. Po dokončení této práce získáte standardní konfiguraci plnou dat z vaší pracovní základny.

Nyní musíme provést ještě jeden přenos dat. Chcete-li to provést, proveďte znovu instalaci výchozí nulové konfigurace do nového adresáře. A už tam můžete přenášet data ze standardní konfigurace se svými daty. Ve výsledku budete mít ideální základnu verze 7 připravenou k přenosu do verze 8.2.

Faktem je, že data jsou přenášena přímo do osmé verze výhradně z „nedotčené“ standardní verze 7.7. A teď máte právě takovou konfiguraci. Ale teď to není prázdné, ale s vašimi pracovními daty.

Všechno! Spuštění 1C: Enterprise 8.2. Vybereme možnost „Přenos dat od verze 7.7“. a užívejte si, jak program sám přenáší data z vašich zpracovaných 7.7., přeposílá dokumenty a zobrazuje srovnávací tabulku rozvahy verzí 7.7 a 8.3.

Samozřejmě nebude 100% výsledek. Ale o 70-80 procent získáte shodu. A pak bude vaše práce hotová až ve verzi 8.3.

Možné nepřesnosti lze snadno opravit. Je to další 3-4 hodiny. Přejdete do deníku dokladů a upravíte účty nebo pole (například „Smlouva“ nebo „Hlavní pokladna“). Záleží na tom, jak odlišná je vaše základna. 7.7. ze standardu. V důsledku všech těchto akcí bude vaše pracovní verze verze 8.3 schopna vydávat účetní data prostřednictvím rozvahy v dokonalé podobě.

Po přechodu bude užitečné naučit se pracovat v novém programu. K tomu jsme připravili sekci Školení 1C účetnictví 8.3.

Mimochodem! Pokud potřebujete vylepšit programy 1C, můžete nás kontaktovat!

Jak přenést databázi 1C 7,7 na 8,3?

Mnoho typických (a některých oborových) řešení 8 již má buď integrované nástroje pro migraci od 7.7, nebo jako další soubory v instalačním adresáři šablony.

Pokud si jej přenesete sami, pak na disku ITS (stejně jako na mnoha místech na internetu - google pro pomoc) je zpracování „Načítání z tabulkového dokumentu“, které vám umožní načíst libovolná tabulková data do adresářů / dokumentů / registruje. S dostatečně vysokou úrovní dovedností můžete použít bojové dělostřelectvo - speciální konfiguraci „Data Conversion 2“ (nezaměňovat s 3.).

Můžete mi říct, proč tato chyba vyšla? V dokumentaci pro 1C píše každý příliš matoucí - koneckonců, musíte dostat plat, takže na to ve svých rukopisech nemůžete vůbec přijít, válka a mír přijdou snadněji než jejich návody k ovládání jejich daleko od složitého systému .

Maxim Kravchenko, no, všechno je psáno v ruštině 🙂

Podle mých zkušeností jsou nejčastější důvody následující:

1) V nastavení výměny je zadána nesprávná cesta od 7. 7. Zde jsou zadány pouze překlepy nebo je uvedena cesta k nesprávnému adresáři. Buď je ve vašem počítači zadána místní cesta, a výměna probíhá na straně podnikového serveru 1C a tento server přirozeně na vaší cestě nic nevidí (běžný problém).
2) Na straně počítače, který se pokouší komunikovat s verzí 7.7 (místní nebo serverovou), není plně nainstalovaná platforma 7.7. Ty. neexistuje žádný registrovaný objekt COM a databáze 7.7 byla tradičně připojena pomocí adresáře s kompromitovanou platformou, který nepotřebuje klíč ani žádná systémová data.
3) K základně 7.7 neexistují žádná přístupová práva (zvláště důležité při práci na serveru, kde je pracovní proces rphost spuštěn pod uživatelem služby a základní adresář 7.7 je otevřen konkrétním lidem).

Maxim Kravchenko, proč ne prostřednictvím IRC nebo chatů na Narodovových „zatracených kulichkách“? 🙂
Ne, na stejný hrábě už nevkročím. Již jeden nevděčný člověk dal svůj Skype a sedl si na krk.

Pokud máte obecné otázky, jejichž odpovědi mohou pomoci ostatním - zeptejte se. Pojďme společně udělat dobrý skutek. Žádná tajná jednání.

P.S. Aby lidé neztratili touhu dávat odpovědi na tento zdroj, bylo by hezké označit řešení nebo kliknout na tlačítko „jako“ u nejvhodnějších odpovědí, i když přímo nepomohli.

Maxim Kravchenko, FAQ je nemožné, protože čistá 7.7 v přírodě neexistuje. Existuje celá paleta typických / průmyslových řešení, existují různé verze stejné specifické konfigurace, ale žádná z této sady nepokrývá potřeby společností ihned po vybalení a všech 7,7 prodaných po instalaci bylo roky vylepšováno. Vzhledem k tomu, že před více než deseti lety přestali ve velkém množství prodávat 7,7, nemohlo ve vaší konkrétní databázi z typické funkce zůstat nic.

Jedna věc je, když vezmete standardní mechanismy přenosu, o kterých jsem psal ve své odpovědi, a přenesete je, protože si uvědomíte, že budete zodpovědní za překážky a všechny nesrovnalosti, které dáte k opravě „dívek“. Další věcí je přilákat odborníka, aby pracoval pro peníze. Musíte popsat všechny referenční knihy pro přenos, množství informací k přenosu (články, čárové kódy, DIČ atd.), Odkud získat chybějící informace atd. Nejsem připraven přijmout váš projekt právě teď. Navrhuji zaregistrovat tento úkol na stránkách nezávislých pracovníků a vyhlásit mezi nimi výběrové řízení.

Pravidla převodu 1 s 8

Přenos dat z programů „1C: Accounting 8 vydání 2.0“ do „1C: Accounting 8 vydání 3.0“

Určeno primárně pro upravené konfigurace 1C: Účetnictví 8, vydání 2.0 (možné názvy na internetu BP 2.0 nebo BP 8.2) jako základ pro vývoj původních pravidel pro přenos do konfigurace 1C: Účetnictví 8, vydání 3.0 (možné názvy na internetu BP 3.0 nebo BP 8.3), je samozřejmě také vhodný pro přenos dat mezi typickými konfiguracemi.

Možné migrační strategie od 2,0 do 3,0 najdete zde.

Přechod z 1C: Účetnictví 8, vydání 2.0 na 1C: Účetnictví 8, vydání 3.0 doporučuje se provést na začátku nového období (rok, čtvrtletí, měsíc) po dokončení rutinních operací předchozího období.

Přenos dat se provádí pomocí univerzálního zpracování, které uvolňuje data z informační základny 1C: Účetnictví 8, vydání 2.0 do souboru ve formátu XML. Výsledný soubor se načte do databáze 1C: Účetnictví 8, vydání 3.0 pomocí zpracování obecného načítání dat.

K přenosu dat jsou vyžadovány následující soubory:

ACC20_30.xml - pravidla pro převod dat.

Z informační základny BP 2.0 v BP 3.0 přestoupil:

informace o aktuálních zůstatcích na účetních účtech informační základny "1C: Účetnictví 8 rev. 2.0" k datu převodu informační základny

infobase dokumenty BP 2.0 pro vybrané období

potřebné základní informace z informační základny „1C: Accounting 8 rev.2.0“

- údaje z informační základny 1C BP 8.2 nahráno do samostatného souboru (datového souboru);

- výsledný soubor je načten do informační základny 1C BP 8.3.

Není nutná žádná instalace, protože se používají ošetření zabudovaná do typických konfigurací 1C: Účetnictví 8, vydání 2.0 a 1C: Účetnictví 8, vydání 3.0.

(Přečtěte si o možnosti použití specializovaného zpracování níže)

V programu 1C: Účetnictví 8, vydání 2.0 musíte otevřít zpracování (nabídka: Servis — Další výměny údajů), vyberte složku obsahující pravidla přenosu (viz obr. 1) a načtěte pravidla výměny. Doporučuji, abyste vynutili načtení pravidel výměny pokaždé, i když jsou načtena automaticky na začátku zpracování. Chcete-li to provést, buď znovu vyberte soubor pravidel, nebo klikněte na tlačítko Přečtěte si pravidla výměny... Nemusíte zahrnovat všechna pravidla přenosu. Měli byste použít pouze ty, které jsou nezbytné pro převod zůstatků a (nebo) dokumentů. Všechny adresáře se podle potřeby přenášejí pomocí odkazů, tj. pouze ty, které se podílejí na zůstatcích a dokumentech. Tím je zajištěno, že v nové infobase nejsou žádné „odpadky“.

Pokud potřebujete uvolnit zůstatky na konci roku, například na konci dne 31. 12. 2014, tj. je správnější říci na začátku roku 2015, pak by období vykládky mělo být 01.01.2015 - XX.XX.XXXX. Doklady pro zadávání zůstatků do BP 3.0 bude datováno 31. 12. 2014. Od 01.01.2015 do BP 3.0 musíte vytvořit dokumenty, které odrážejí aktuální operace. Pokud potřebujete pouze zbytky, musíte povolit pravidla pro uvolnění dat ze sekce Příchozí zůstatky (viz obr. 1). Pravidla pro uvolnění dat ze sekce Dokumenty v takovém případě by měl být deaktivován (viz obr. 3). Období vykládky, například 01.01.2015 - 31.01.2015, znamená, že budou přeneseny dokumenty z ledna 2015. Pravidla pro uvolnění dat ze sekce Dokumenty v tomto případě by mělo být zahrnuto.

Postava: jeden . Zpracování nahrávání dat

Nejprve doporučujeme převést účetní zásady organizace (odkaz Organizace přenesené odkazy). Při přenosu dat můžete dodatečně nastavit parametry (viz obr. 2). Chcete-li se vrátit k výchozím hodnotám, měli byste znovu načíst pravidla výměny.

Obr. 2 Nastavení parametrů

Parametr Ignorovat dávkový registr DPH především určuje, zda bude vyplněn BP 3.0 při zadávání zůstatků Zboží a materiály stůl Údaje o přijatých fakturách... Ovlivňuje také to, jak bude subkonto vyplněno Večírek: podle VYPÍSKAT nebo registrovaným zůstatkem DPH z nakoupených aktiv.

Nastavením tohoto parametru můžete řídit vykládání zbytků pro organizace, které používají STS... Když běží účetnictví, když se data registru neshodují Náklady na STS pro účetní účet může být užitečnější uvolnit zůstatky pouze podle účetních údajů bez registrace STScož může přidat spoustu chyb. V tomto případě v dokumentech pro zadání počátečních zůstatků v BP 3.0 náležitosti Reflexe ve zjednodušeném daňovém systému a Stav spotřeby jsou vyplněny výchozími hodnotami.

Při nastavování parametru na Ano současně s dokumenty budou přeneseny sady hlavní knihy spojené s těmito dokumenty. Jinak se přenese obsah dokumentů a pro příjem pohybů by se dokumenty měly zaúčtovat do databáze BP 3.0 po převodu. Je třeba si uvědomit, že ne pro všechny pohyby dokumentů existující v BP 8.3, existují zápasy v BP 8.2... Proto i když zvolíte možnost přenosu dokumentů s pohyby, u některých typů dokumentů budete možná muset zaúčtovat, abyste vytvořili všechny požadované sady účetních knih.

Obr. 3 Seznam dokumentů přenesených do BP 3.0

Seznam adresářů a registrů informací, které mají být přeneseny, je uveden na obr. Pokud má někdo zájem o rozšíření tohoto seznamu, kontaktujte autora. Pro mnoho referenčních knih existují pravidla pro přenos objektů. Je to pochopitelné, protože v mnoha dokumentech je obsažena řada příruček, které jsou stahovány z odkazů. Není těžké z nich udělat pravidla pro vykládku, můžete to udělat sami. Pravidlo vykládání referenční knihy je nezbytné, pokud existuje potřeba přenést referenční knihu jako celek, nejen pomocí odkazů.

Postava: 4 Seznam adresářů a registrů informací, které mají být přeneseny

Vlastnosti převodu zůstatků na účtech 76.АВ a 76.ВА

Při nastavení na hodnotu Ano parametr Správná nesprávná klasifikace vypořádání s protistranami můžete opravit chyby v účetnictví. Co je přeřazování, je zřejmé z obrázku 5.1: protistrana má nulový zůstatek, ale druhý subkonto nemá nulové částky. Takové zbytky nebudou přeneseny.

Obrázek 5.1 Přeřazení zbytků

Pokud je nastaveno na Ano parametr Podrobnosti zpráv, poté se při vykládce zobrazí vysvětlující zprávy (viz obr. 5.2).

Obrázek 5.2 Zprávy o překročení zbytků

Funkce převodu zůstatků na účtech zásob

Algoritmus pro opravu chyb, jako je přehodnocení reziduí pomocí Zboží a materiály... Tento algoritmus funguje při nastavování parametru Správná nesprávná klasifikace zůstatků zásob v hodnotě Ano... Příklad je znázorněn na obrázku 5.3. Účtování účtu 10.03 se provádí v rámci nomenklatury, skladů a večírků. Zůstatek podle položky Benzín AI-92 na sklad # 4 se rovná nule, ale pokud rozložíte zůstatky losem, bude jich mnoho. Algebraický součet reziduí losy se rovná nule, to je špatné hodnocení. Tyto zbytky by se neměly přenášet, protože se jedná o jasnou chybu. Pokud je nastaven parametr, nebudou přeneseny.

Obrázek 5.3 Přeřazení zbytků Zboží a materiály ve zdrojové databázi BP 2.0

Situace je horší s sklad číslo 6... Zbytek je nenulový, takže algoritmus korekce chybného hodnocení nebude fungovat, zbytky budou přeneseny. A jak budou přeneseny, uvažujme. Množství -155,29 nebudou zahrnuty do převodu, protože takový zbytek v BP 3.0 není možné zadat, je nemožné zadat nulové množství a nenulovou částku, doklad pro zadání zůstatku nebude zaúčtován, proto jej nenahráváme. Jako výsledek, v BP 3.0 zbývající dvě částky klesnou (viz obrázek 5.4). Zbytek byl přenesen jako s chybou. Ve skutečnosti zde samozřejmě není chyba přenosu, ale existují účetní chyby.

Obrázek 5.4 Výsledek přenosu do BP 3.0

Zda se použije popsaný algoritmus korekce chybného hodnocení, či nikoli, je na uživateli. Musíte si jen uvědomit, že zůstatky s nulovou částkou se nikdy nepřenášejí. Podle názoru autora je to nejsprávnější chování, přinejmenším vám umožňuje provést dokument pro zadávání zůstatků a zahájení odsouhlasení. Pro rychlejší hledání pozic nesrovnalostí ve zbytcích mezi BP 2.0 a BP 3.0 na základě výsledků převodu je možné ve zdroji doporučit výběr takových problematických pozic příslušnou úpravou rozvahy. Jak na to, viz obr.5.5.

Obrázek 5.5 Výběr položek s nulovým množstvím

Po skončení vykládky musíte spustit program 1C: Účetnictví 8, vydání 3.0... Načítání jak na začátku, tak na opakované přenosy dat nebo další přenosy by se mělo provádět pomocí rutinního zpracování Obecná výměna dat XML (viz obrázek 8.1). Můžete jej otevřít pomocí nabídky: Všechny funkce - Zpracování - Univerzální výměna dat ve formátu XML. Pokud v nabídce není žádná položka Všechny funkce, pak musíte jít do Služba - parametry a zaškrtněte políčko Zobrazit příkaz Všechny funkce.

Po načtení dat do databáze 1C: Accounting 8 rev.3.0 je nutné provést podklady pro zadání počátečních zůstatků, abychom získali všechny potřebné pohyby. Můžete použít zpracování Skupinové přeposílání dokumentů (viz obrázek 8.2) nebo zaúčtujte dokumenty do deníku (nabídka: Všechny funkce - Doklady - Zadávání zůstatků). Pokud byly dokumenty přeneseny bez pohybu (parametr Uvolněte pohyby dokumentů nastaven na Ne), abyste mohli přijímat příspěvky a zápisy do registrů, musíte také zaúčtovat dokumenty.

Technika převodu dat.

Převod, pokud je to nutné, lze provést v několika fázích, například první adresáře, pak dokumenty pro zadání zbytků, pak další dokumenty. Je možný opětovný přenos informací. Mezi přenosy byste neměli provádět opravy přenesených dat 1C: Účetnictví 8, vydání 3.0jinak mohou být tyto opravy ztraceny při opakovaných přenosech.

Zůstatky se převádějí prostřednictvím dokumentů Zadání počátečních zůstatků.

Více informací o způsobu zadávání zůstatků najdete v článku na webových stránkách ITS 1C.

Důležité! Před zadáním počátečních zůstatků je třeba nastavit parametry účetních zásad. Parametry účetních zásad organizace jsou čteny v den následující po datu zadání zůstatků. Pokud je například datum vstupu zůstatků 31. 12. 2013, pak se zohlední parametry účetních zásad nastavené k 1. 1. 2014. To vám umožní zohlednit parametry aktuálních účetních zásad (například: pokud v roce 2013 organizace použila zjednodušený daňový systém a od roku 2014 přesunuta do společného systému - při zadávání zůstatků k 31. 12. 2013 budou zohledněny parametry účetní politiky roku 2014). Proto, jak je uvedeno výše, nejdříve doporučujeme převést účetní politiku organizace.

Důležité! Pokud se rozhodnete začít pracovat v 1C: Účetnictví 8, vydání 3.0 před přesunem zbytků je nutné předem zahájit práci 1C: Účetnictví 8, vydání 3.0 převést adresáře. Jinak jsou možné chyby při přenosu zbytků na neprázdnou základnu.

Důležité: existuje možnost řešení problému synchronizace při načítání do neprázdné databáze - porovnávání objektů.

Jak pracovat se specializovaným zpracováním přenosu dat.

Zpracování se používá pouze v režimu Soubor... zpracovává se Data Transfer_from_BP20_to_BP30.epf by měla být spuštěna na infobase, kde jsou data přenášena, tj. v 1C Enterprise Accounting revize 3.0. V prvním okně (viz obr. 9) byste měli určit možnost načítání dat z infobáze na platformě 1C: Enterprise:

Načtěte data přímo z databáze

Obr. 9 Úvodní okno zpracování přenosu dat

V dalším okně (viz obr. 10) musíte nakonfigurovat přenos:

Vyberte ze seznamu informační základnu (seznam je stejný jako při spuštění aplikace 1C Enterprise).

Zadejte uživatelské jméno a heslo

Uveďte, jaké informace mají být přeneseny

Dále můžete zkontrolovat správnost přenosu ve zdroji

Při přenosu katalogů budou data přenesena z katalogů vybrané informační základny, pro které platí pravidla pro vykládku. V tomto případě jsou adresáře přeneseny úplně. Pokud není zaškrtnuto políčko, ale je vybrána jakákoli jiná možnost přenosu, budou přeneseny také slovníky, ale pouze v rozsahu nezbytném k vyplnění údajů v přenesených transakcích a dokumentech. Při přenosu dat můžete na začátku roku přenést adresáře, dokumenty a zůstatky. Můžete si vybrat libovolnou kombinaci možností přenosu. Při převodu zůstatků budou údaje o zůstatcích na účetních účtech k 1. lednu zvoleného roku přeneseny podle pravidel uvedených na obr.1. V 1C: Účetnictví 8 budou dokumenty „Zadání počátečních zůstatků“ vytvořeny k 31. prosinci roku předcházejícího vybranému.

Obr. 10 Okno parametrů přenosu

Pokud je vybrána možnost kontroly dat, bude taková kontrola provedena před načtením a zobrazí se výsledek kontroly (viz obrázek 11). Pokud během procesu ověřování dojde k chybám, bude proces přenosu pozastaven, aby byla zajištěna možnost chyby opravit. Pokud potřebujete nahrát a stáhnout data i přes chyby, zrušte zaškrtnutí políčka Před nahráním zkontrolujte data nebo stiskněte Pokračovat... Seznam pravidel kontroly stále roste.

Obr. 11 Výsledek ověření dat před načtením

V procesu přenosu dat ze zdroje do přijímače se na obrazovce aktualizuje obrázek, který ukazuje aktuální fázi: připojení k základní databázi, stahování dat, stahování dat atd. Dále se níže zobrazí podrobnější informace ve formě řádku, například „Nahrát data: Dokumenty (3/3)“. Po dokončení stahování dat začne proces zaúčtování stažených dokumentů a následná kontrola stažených dat. Pokud v průběhu ověřování dokumentů nebo údajů došlo k chybám, na konci se v okně zprávy objeví zprávy o tom. Chybové zprávy lze zobrazit také v samostatném okně kliknutím na hypertextový odkaz Informace o chybě (viz obrázek 12).

Obr. 12 Indikace průběhu přenosu dat

Fragment tabulky obsahující chybové záznamy je uveden na obrázku 13. Nejprve se v tabulce zobrazí zprávy o chybách, ke kterým došlo během účtování dokumentu, a poté chyby během ověřování. Ověření stažených dat spočívá v porovnání rozvah vygenerovaných ke dni zadání zůstatků ve zdroji a přijímači. Dojde-li k nesrovnalosti mezi zůstatkem na účtu, vytvoří se o něm záznam. Poklepáním na položku v tabulce chyb můžete otevřít problémový dokument pro ruční opravu a zaúčtování. Totéž lze provést v okně se zprávou.

Obr. 13 Fragment tabulky obsahující chybové záznamy

Po provedení oprav v cílové základně nemá smysl znovu provádět přenos stejných informací ze zdrojové základny, protože při opakování přenosu budou tato data znovu zapsána s chybami. Pokuste se proto provést korekce u zdroje, nikoli u přijímače, nebo neopakujte přenos stejných informací. Například po přenosu počátečních zůstatků a opravě všech dokumentů pro zadání počátečních zůstatků v přijímači během dalších převodů nenastavujte příznak Zůstatky na začátku roku.

Aktualizace jsou zdarma po dobu 6 měsíců po zakoupení. Na konci období bezplatných aktualizací můžete dostávat aktualizace placené (viz cena níže). Současně, pokud jste zakoupili několik softwarových produktů, jako součást sad nebo samostatně, máte právo počítat se slevou. Můžete se dozvědět více o systému slev.

Pravidla vytvořená technologií Datové převody: snadné úpravy.
Zcela otevřené neexistují žádná jiná licenční omezení než zákaz duplikace.

Soubor TransferDemo20_30.xml je vyložení z databáze získané přenosem demo databáze BP 2.0 distribuované společností 1C do databáze BP 3.0. Vytvořte prázdnou základnu BP 3.0.44.94, můžete z šablony 1C nebo pomocí konfiguračního souboru 1Cv8.cf. Nastaveno v účetních parametrech na Sestavování účtové osnovy skladové účetnictví skladů a šarží. Stáhněte si demo databázový soubor TransferDemo20_30.xml se zpracováním Obecná výměna dat XML... Demonstrační databáze zobrazuje převod zůstatků k 1. 1. 2009 a doklady za období od 1. 1. 2009 do 31. 12. 2009.

Pravidla jsou pravidelně aktualizována pro nová vydání, vhodná pro vydání BP 2.0.64.23 a novější. Není třeba hledat a vybírat požadovanou variantu pravidel přenosu, jsou vhodná pro jakékoli vydání SOURCE v uvedeném rozsahu. Pokud potřebujete pravidla pro dřívější vydání, kontaktujte autora. Vydání RECEIVER by mělo být přesně to samé jako v pravidlech.

29. 8. 2018 Přiděleno samostatnému pravidlu pro vykládání zůstatků podle oddílů Úvěry a půjčky (účty 66, 67), dříve byla součástí Ostatní účetní účty

20. 8. 2018 Aktualizace na 2.0.66.59 a 3.0.64.48

06.03.2018 Přidán přenos dokumentů Reflexe platů v regulovaném účetnictví

18. 5. 2018 Aktualizace na 2.0.66.54 a 3.0.61.37

23. 2. 2018 Aktualizace na 2.0.66.48 a 3.0.58.41

18. 1. 2018 Aktualizace na 2.0.66.46 a 3.0.57.17

22. 12. 2017 Aktualizace na 2.0.66.42 a 3.0.56.22

3. 3. 2017 Aktualizace na 2.0.66.37 a 3.0.53.38

26. 9. 2017 Aktualizace na 2.0.66.37 a 3.0.52.35

14. 6. 2017 Aktualizace na 2.0.66.29 a 3.0.50.18

5. 5. 2017 Aktualizace na 2.0.66.25 a 3.0.49.27

04/04/2017 - Přidáno vytváření faktur přijatých, když BP 2.0 obsahuje pouze číslo a datum. Musíte nastavit parametr Převést faktury (vytvořte nové, pokud zdroj obsahuje pouze číslo a datum)

2. 6. 2017 Aktualizace na BP 3.0.47.23

26. 1. 2017 Přidán přenos dokumentů Reflexe přírůstku DPH a Odrážka odpočtu DPH

1. 11. 2017 Aktualizace na BP 2.0.66.8 a BP 3.0.46.16. Převod registrace vyloučen DPH od OSiNMA. V dřívějších verzích, kde je součástí konfigurace, nebude migrována.

14. 12. 2016 Aktualizace na BP 3.0.44.203

12. 7. 2016 Přidán přenos dokumentů Úprava dluhu

1. 12. 2016 Přidán parametr Nezohledňujte výdaje registru pro STS, což vám umožňuje řídit vykládku zbytků pro organizace pomocí zjednodušeného daňového systému

21. 11. 2016 Přidáno vykládání adresářů Uživatelé samostatné pravidlo s vytvořením uživatelů informační bezpečnosti v přijímači (podrobnosti zde). Přidán přenos zbytků pomocí PC Zaměstnanci organizací (osobní údaje). Při převodu zůstatků na účtech 76.АВ a 76.ВА je možné zkontrolovat a opravit chybné zařazení podle druhého podkonta.

11. 8. 2016 Byl rozšířen seznam dokumentů.

28. 10. 2016 Přidán přenos dokumentů. Přidáno demo přenosu, toto je výsledek přenosu demo databáze BP 2.0.

26.10.2016 Vytváření prázdných dokumentů pro zadávání zůstatků za přítomnosti zůstatků na účtech bylo opraveno 10.07

9. 9. 2016 Aktualizace na BP 3.0.44.102

23. 3. 2016 Vylepšený přenos dat o přijatých fakturách (při převodu zůstatků zásob)

01/11/2016 Přidán přenos kontaktních údajů fyzických osob, občanství, pasových údajů, informací o zdravotním postižení, statusů fyzických osob. Přidána pravidla pro převod bankovních účtů a účtů zásob.

23. 12. 2015 Aktualizace na BP 3.0.43.29. Přidán přenos kontaktních údajů dodavatelů a jejich kontaktních osob.

14. 12. 2015 byla vytvořena pravidla pro BP 3.0.42

Balíček obsahuje: pravidla převodu „ACC20_30“ a zpracování Přenos dat_od_BP20_do_BP30... Pokud vaše organizace nemá programátora na plný úvazek k provádění prací, jsme připraveni nabídnout služby našeho specialisty (programátor se k vašemu počítači připojí přes internet pomocí speciálního programu pro vzdálenou práci a provede potřebnou práci). Pokud je možné poskytnout pracovní základnu „1C: Accounting 8 edition 2.0“, můžeme data přenést sami a přenést soubor “ 1C: Účetnictví 8, vydání 3.0»S přenesenými zbytky. Cena této služby není zahrnuta v celkové ceně balíčku.

Důležité... Ne všechny dokumenty jsou migrovány (kvůli kompatibilitě se staršími verzemi BP 2.0). Před zakoupením si prosím pečlivě přečtěte výpis na obrázku 3.

Přenos dat z programů „1C: Účetnictví 7.7“ a „1C: USN 7.7“ do „1C: Účetnictví 8“

Pár slov o tom, jak jsou data přenášena z typické konfigurace " Účetnictví", Vydání 4.5 pro 1C: Enterprise 7.7 nebo konfigurace" "(dále jen" Zdroj konfigurace ") do typické konfigurace" " Podnikové účetnictví", Verze 3.0 pro 1C: Enterprise 8 (verze 3.0.52), dále jen„ Cílová konfigurace ".

DŮLEŽITÉ! Přenos dat je možný z konfigurace Účetnictví vydání 4.5 pro 1C: Enterprise 7.7 verze 7.70.569 a novější nebo z konfigurace " Zjednodušený daňový systém, vyd. 1.3»Verze 7.70.219 a vyšší.

Doporučujeme přepnout ze zdrojové konfigurace na přijímací konfiguraci na začátku nového období (rok, čtvrtletí, měsíc) po dokončení plánovaných operací předchozího období.

Přenos dat se provádí pomocí specializovaného zpracování, které uvolňuje data ze zdrojové konfigurační databáze do souboru ve formátu XML. Výsledný soubor se načte do informační základny konfigurace příjemce pomocí zpracování univerzálního načítání dat.

ACC_ACC8 .ert - externí zpracování vykládání dat do externího souboru z " Účetnictví, rev. 4.5»;

USN_ACC8 .ert - externí zpracování nahrávání dat do externího souboru z " Zjednodušený daňový systém, vyd. 1.3»;

ACC_ACC8 .xml - pravidla pro převod dat.

USN_ACC8 .xml - pravidla pro převod dat.

Z konfigurace zdroje infobase do konfigurace cíle se přenáší následující položky:

- informace o aktuálních zůstatcích účtů zdroje konfigurační infobáze k datu převodu infobase;

- aktuální dokumenty s datem větším než je datum převodu informační základny.

Převod se provádí ve dvou fázích:

- data ze zdrojové konfigurační databáze se nahrávají do samostatného souboru (datového souboru);

- přijatý soubor je načten do informační základny konfigurace příjemce.

K instalaci zpracování migrace dat použijte setup.exe. Po spuštění programu (je-li počet databází 1C: Enterprise velký, pak po chvíli) se zobrazí dialogové okno, ve kterém musíte vybrat ty databáze, na které bude nainstalováno zpracování přenosu dat. Okno vypadá jako na obr.1. Pokud je počet informačních bází více než sedm, použijte k navigaci tlačítka nahoru a dolů. Pokud je vybráno několik informačních bází, pak čára cesty odráží umístění pouze naposledy vybrané databáze. Tyto informace jsou pomocné povahy a jsou používány dle libosti pro dodatečnou kontrolu nad výsledkem instalačního programu uživatelem, nevěnujte jim zvláštní pozornost, program sám určí, kde jsou nainstalovány vybrané databáze.

Obr. 1 Okno výběru databáze během instalace

Dále můžete určit složku, do které se také nainstaluje zpracování přenosu dat; k tomu použijte okno pro výběr složky (kliknutím na tlačítko se třemi tečkami). Na pruhu výběru se zobrazí úplná cesta k vybrané složce. Po kliknutí na tlačítko „nainstalovat“ budou potřebné soubory nainstalovány do vybraných informačních databází a / nebo do vybrané složky. Po dokončení můžete kliknout na tlačítko „podrobnosti“ a zobrazit podrobný protokol instalace, které soubory a složky byly zaznamenány. Výsledkem by měl být následující obrázek ve vybrané složce, viz obr.

Obr. 2 Soubory nainstalované ve vybrané složce

Do podadresáře ExtForms jsou stanovena pravidla pro zpracování a přenos. Vezměte prosím na vědomí, že zpracování nahrávání ACC_ACC8 .ert a pravidla pro vykládku dat nahrazují typické zpracování a pravidla. Chcete-li zachovat typický přechodový mechanismus, nainstalujte nové zpracování do samostatného adresáře, nikoli do databáze.

Proces instalace je podrobněji popsán na příkladu instalace sestavy " Expresní kontrola účtování konfigurace „1C: Účetnictví 7.7«.

V programu " 1C: Účetnictví 7.7„Musíte otevřít zpracování z dalších možností“ Přechod na 1C: Účetnictví 8, vyd. 3.0«, Vyberte složku obsahující pravidla přenosu (viz obr. 3) a načtěte pravidla výměny. Nemusíte zahrnovat všechna pravidla přenosu. Měli byste používat pouze ty, které jsou nezbytné, například k převodu zůstatků nebo zůstatků a dokumentů. Například ve skupině adresářů nelze zahrnout žádná pravidla, protože všechny adresáře jsou podle potřeby přesunuty odkazy, tj. pouze ty, které jsou zahrnuty buď na zůstatcích, nebo na dokladech. Tím je zajištěno, že v nové infobase nejsou žádné „odpadky“. Dokumenty také nemusí obsahovat vše. Například pokud ve vaší databázi nejsou žádné dokumenty nebo je nechcete přenést, není nutné toto pravidlo povolit.

Obr. Zpracování nahrávání dat

Doporučuji nastavit název datového souboru na "C: \\ v77_v8 \\ Exp77_80.xml", je to právě tato složka, která se v programu standardně často používá. " 1C: Účetnictví 8"Při načítání dat z programů na" 1C: Enterprise 7.7". V případě potřeby nastavte parametry na stránce " Možnosti«.

V procesu vykládání dat z konfigurace " Účetnictví 7.7»Mohou se vyskytnout různé chyby. Zde uvedená pravidla přenosu se liší od pravidel obvyklých v tom, že hledají typické chyby ve fázi nahrávání dat. Zvažme ty z nich, o kterých zprávách se zobrazuje.

Nulové množství a nenulový součet zboží a materiálů... Je nemožné zadat zůstatek v konfiguraci přijímače tak, aby se množství materiálu rovnalo nule a odhad nákladů na materiál se nerovnal nule, je nemožné a je to zbytečné, protože se jedná o chybu. Proto se při převodu zůstatků takové položky (s nulovým množstvím) v dokladech o vstupu do zůstatku neobjeví. Pokud tedy chyby nebudou před přenosem dat opraveny, nebudou se částky ve zdroji dat a v přijímači dat během přenosu zůstatků shodovat, což způsobí další potíže s odsouhlasením. Proto v procesu uvolňování dat z konfigurace " Účetnictví 7.7»Zobrazí se zprávy o zjištěných chybách (viz obr. 4). Kromě toho můžete k vyhledávání chyb doporučit zpracování „Expresní kontrola účetnictví“, konkrétně pravidlo „Žádný nenulový součet s nulovým množstvím materiálů“.

Obr. 4.1 Chybová hlášení

Nenulový zůstatek na subkontu druhé (třetí) úrovně, zatímco zůstatek na první (druhé) úrovni je nulový. Jedná se o poměrně běžnou situaci chybného účetnictví. Typický příklad je uveden na obrázku 4.2. Taková podmínka vzniká v důsledku „nesprávného zařazení“ do analytického účetnictví. Například v dokladech o peněžních tocích je uvedena smlouva, ale v dokumentech o kapitalizaci zboží a materiálů není žádná smlouva, nebo naopak, nebo existují smlouvy, ale odlišné. Ve všech těchto případech existuje nenulový zůstatek smlouvy, zatímco zůstatek protistrany je nulový. Podobný obrázek se může vyvinout v účtování o materiálech a položkách (pokud je zahrnuto celkové účtování o skladovacích místech): přeřazení mezi sklady, zejména pokud jsou sklady hmotně odpovědnými osobami.

Obrázek 4.2 Příklad účetních chyb

Je zřejmé, že se jedná o chybu, a je zřejmé, že nemá smysl přenášet tyto zbytky. Aby se vyloučil převod tohoto druhu zůstatků, existuje parametr „Nevykládat zůstatky, pokud je na nejvyšší úrovni nulový zůstatek.“ Pokud je tento parametr nastaven na jeden, pak se zprávy zobrazené na obr. 4.3 (v porovnání s obr. 4.2) a zůstatky pro tyto pozice nebudou uvolněny. Můžete použít různé kombinace tohoto parametru s pravidly pro přenos různých zůstatků. Pokud přenesete ne všechny zůstatky najednou, ale podle účetních sekcí, můžete převést zůstatky pro různé účetní sekce s různými hodnotami parametrů.

Obrázek 4.3. Chybové zprávy

Prázdné hodnoty smluv nebo smluv jiných lidí. Problém je podobný problému popsanému výše, důvod je stejný - špatná klasifikace v analytickém účetnictví podle smluv (viz obrázek 4.4). Ale zůstatek protistrany není nula, takže výše uvedené kontrolní pravidlo nebude fungovat. Při přenosu dat dojde k chybě při zaúčtování dokladu o zůstatku, protože prázdná hodnota kontraktu není povolena.

Obr. 4.4 Zpráva zobrazující chybu

Aby se takové chyby před přenosem vyloučily, ve fázi uvolnění dat se zobrazí chybové zprávy (viz obrázek 4.5). Stejný obrázek ukazuje, že došlo k další chybě: smlouva neodpovídá protistraně, tj. vlastníkem smlouvy je jiná protistrana. Takové chyby se často vyskytují v upravených, tj. atypické konfigurace nebo v dlouho zavedených databázích, kdy ani ve standardních konfiguracích nebyla při vyplňování dokumentů dostatečně přísná kontrola dodržování smluv.

Obrázek 4.5 Chybové zprávy o účtování

Kontrola prázdných hodnot smluv a smluv jiných osob se provádí, pokud je parametr „ Zkontrolujte prázdné hodnoty smluv a dodržování protistrany". Kromě toho můžete k vyhledávání chyb doporučit zpracování „Expresní kontrola účetnictví“, konkrétně pravidla „Absence nevyplněné analytiky na základě smluv“ a „Soulad protistran a smluv“.

Existují i \u200b\u200bjiné kontroly chyb, pro bližší informace nás kontaktujte (kontakty ve spodní části stránky).

Ukážeme vám, jak můžete přenášet data po částech, a ne úplně, pomocí příkladu vykládání dokumentů konkrétního typu nebo dokonce jednotlivých kopií dokumentů vybraného typu. Označme pouze jedno pravidlo vykládky dat “ Platební příkaz"(Viz obr. 5). To vám umožní nahrát pouze dokumenty „ Platební příkaz". Pokud stisknete tlačítko " Vyložit„, Pak všechny dokumenty formuláře“ Platební příkaz„Nachází se v časovém intervalu s“ počáteční datum„od“ Datum spotřeby". Zmáčknout tlačítko " Nainstalujte LDPE", Poté nápis" Výběr údajů pro Platební příkaz«.

Obr. 5 Jak nastavit pravidlo pro nahrávání dat určitého typu

Poté stiskneme tlačítko „Přidat podmínku“, bude možné vybrat atribut výběru (viz obr. 6.1), nejčastěji je to „ CurrentDocument«, Což vám umožní vybrat samostatný dokument ze seznamu dokumentů tohoto typu. Pomocí dalších podrobností výběru je možné získat výběr podle skupiny dokumentů, například vybrat dokumenty podle data. Ve všech případech se výběr dokumentů provádí v časovém intervalu určeném parametry " počáteční datum"A" Datum spotřeby«.

Obrázek 6.1 Jak vybrat jednotlivý dokument

Důležité! „1C“), který v některých konfiguracích neumožňuje výběr dokumentů při vykládce podle podrobností výběru. To je způsobeno skutečností, že ve standardních pravidlech se výběr dokumentů provádí na vyžádání bez určení období. Ne vždy fungují takové dotazy.

Podobným způsobem můžete uvolnit adresáře, nikoli celý adresář, ale provedením výběru některým atributem. Nejprve vyberte požadované pravidlo pro nahrávání dat a poté postupně stiskněte tlačítka „ Nainstalujte LDPE"A" Přidat podmínku". Například obrázek 6.2 ukazuje, jak můžete uvolnit pouze ty zaměstnance, s nimiž v době přechodu z programu " 1C: Zjednodušený daňový systém, vyd. 1.3„zapnuto“ 1C: Podnikové účetnictví, revize 3.0„(Nebo, jak uživatelé často říkají, přechod z účetnictví 7,7 na 3,0) je vytvořen pracovní poměr.

Obr. 6.2 Jak vybrat skupinu prvků adresáře

Důležité! V navrhovaných pravidlech pro přenos dat došlo k chybě ve standardních pravidlech (od společnosti „1C“), což vede k nesprávnému výběru prvků adresáře při vykládání podle pravidelných požadavků adresáře, tj. ty, které mají různé hodnoty pro různá data. To je způsobeno skutečností, že ve standardních pravidlech se výběr prvků adresáře provádí pomocí dotazu bez zadání období.

Výběr podle periodických podrobností adresáře se provádí k datu parametru " Datum spotřeby«.

Můžete použít kombinaci pravidel a filtrů pro uvolnění dat. Pravidla, pro která je výběr nastaven, budou označena jako „[VÝBĚR]“. Chcete-li zobrazit nebo upravit výběr konkrétního pravidla pro vykládání dat, musíte na toto pravidlo dvakrát kliknout v seznamu pravidel nebo po jeho výběru stisknout tlačítko « Nainstalujte LDPE«.

Důležité! Pokud se ukáže, že vykládka objektů je prázdná nebo nedokončená, musíte zkontrolovat, zda je nastaven režim synchronizace s 1C: Accounting 8. Pokud ano, pak se vyloží pouze objekty změněné po provedeném přenosu (Directory.Parameters of SynchronousAccounting ukládá pozici LastDownloadedDocument, která se při vykládání kontroluje funkcí CheckForDownload) ... Plná práce v synchronizačním režimu je nemožná. Režim synchronizace se kontroluje po načtení pravidel výměny. Pokud je režim nastaven, vygeneruje se varovné okno (viz obr. 6.5) a nabídne se deaktivace režimu synchronizace.

Postava: 6.5 Varovné okno režimu synchronizace

Další rozdíly od standardních pravidel

Opravená chyba převodu IT&M se starými typy účtenek: pokud se v dokladech o přijetí zboží a služeb druh dokladu rovná 2 (zastaralá hodnota) a neexistuje žádná dodavatelská faktura, dojde k chybnému převodu tohoto dokumentu na BP 3.0 do vratky od kupujícího.

Opravená chyba při přenosu ručních operací, které mají subkonto Subdivision, do verze BP PROF. Taková operace není v BP zaznamenána, dojde k chybě: „Pole OU musí být prázdné.“ To je způsobeno skutečností, že pravidla jsou navržena pro práci s verzemi CORP, avšak v systému TRAC musí být dimenze DepartmentDt a DepartmentKt účetního registru prázdné.

Opravená chyba vedoucí k duplicitním skupinám adresářů Smlouvy a v důsledku toho k duplikaci prvků tohoto adresáře (protože vyhledávání při načítání se provádí s ohledem na rodiče). To je znázorněno na obrázku 6.6.

Obr. 6.6 Výsledek přenosu adresáře Smlouvy modelová pravidla

Tady ve sloupci Rodič (skupina adresářů) se jménem 2015 existují dvě různé skupiny adresáře se stejným názvem (ve zdroji je pouze jedna skupina), proto jsou smlouvy duplikovány.

Opravena chyba při převodu bankovních dokumentů při převodu peněz z jednoho běžného účtu na jiný. V BP 3.0 v tomto případě je vytvořen dokument Odpis z aktuálního účtu s typem operace Převod na jiný účet organizace, který se neprovádí z důvodu, že není vyplněn požadovaný údaj Účet příjemce... Kromě toho jsou údaje vyplněny nesprávně Účetní účet a Debetní účet... To se objeví, pokud se liší, například 55 a 51, pak je třeba je vyměnit. Opravena chyba nevyplňování rekvizit Typ závazku v dokumentech k převodu daní. Všechny výše uvedené platí pro vydání 3.0.43.215.

Rekvizity se přenášejí hlavní smlouva příručka Dodavatelé.

Pravidlo uvolnění adresáře bylo změněno Nomenklatura, nyní je metoda výběru dat standardní výběr, který vám umožňuje vybrat prvky příručky podle podrobností (ve standardních pravidlech USN 7.7 - BP 3.0 to není možné). Při přenosu adresáře Nomenklatura, jsou přeneseny a Ceny zboží odkazy, tj. ceny pouze převedených položek položek. Chcete-li povolit tuto funkci, nastavte hodnotu parametru na jednu Vykládejte ceny při vykládce zboží.

Opravena chyba ve standardních pravidlech „USN 7.7 - BP 3.0“ při převodu zůstatků pro vypořádání s protistranami: typ smlouvy byl vždy nastaven na jiný... Nyní - podle typu zůstatku, podle účetní sekce " Výpočty s dodavateli a dodavateli"Typ smlouvy \u003d" Dodavatel„V části účetnictví“ Vypořádání s kupujícími a zákazníky"Typ smlouvy \u003d" S kupujícím", V ostatních případech typ smlouvy \u003d" jiný«.

Opravena chyba ve standardních pravidlech „USN 7.7 - BP 3.0“ při převodu zůstatků pro vypořádání s protistranami: výše vzájemných vypořádání byla zaznamenána ve dvou podrobnostech vstupního dokladu o počátečních zůstatcích Množství a ČástkaKt... Z tohoto důvodu nebyl zaúčtován dokument pro zadání počátečních zůstatků.

SkóreS kupujícím„(Ve standardních pravidlech“ jiný"). Hodnota proměnné „ Stát platby“, Je důležité pro správný výběr faktury k platbě kupujícímu v bankovních platebních dokladech v konfiguraci přijímače.

Při přenosu dokumentů formuláře " Platební příkaz„Typ smlouvy je nastaven na“ S dodavatelem„(Ve standardních pravidlech“ jiný«).

Opravena chyba ve standardních pravidlech „USN 7.7 - BP 3.0“ při přenosu umístění úložiště: proměnná “ Typ skladu«.

Přidaný parametr „ Výměna s regulačními orgány v ceně«: Pokud je jeho hodnota 1, pak rekvizity Druh kontrolních orgánů burzy katalogová položka " Organizace„Je nastaveno na“ Sdílení v univerzálním formátu„Jinak v“ ExchangeDisabled»Jako v modelových pravidlech. To je důležité pro opakované (běžné) převody, aby nedošlo k poškození nastavení EDF.

Změněno pravidlo vyhledávání načtených položek pro adresář " Dodavatelé«: První vyhledávání provádí HOSPODA a Kontrolní bod (pokud jsou tyto hodnoty vyplněny), pak pouze pomocí HOSPODA a nakonec název... Ve všech třech případech je do vyhledávání zahrnut atribut skupiny (ThisGroup) a samotná skupina (Parent). To je důležité pro opakované (běžné) převody, aby se nevytvořily duplikáty pro protistrany se změnami jmen PO načtení.

Při převodu protistran je požadovaná položka vyplněna Země registrace což znamená „Rusko“. To je nutné, aby po načtení adresáře dodavatelů do programu „1C účetnictví 8“ Nemusel jsem ručně vyplňovat požadované podrobnosti Země registrace... Pokud není vyplněn, pak ve formě položky adresáře " Dodavatelé„Podrobnosti budou k dispozici“ Daňové číslo"A" Reg. číslo„A podrobnosti“ HOSPODA"A" Kontrolní bod„Bude skryta.

V pravidlech pro přenos „USN 7.7 - BP 3.0“ bylo přidáno pravidlo pro nahrávání dat pro přenos adresáře „Zaměstnanci“ (ve standardních pravidlech se přenáší pouze adresář jednotlivců).

V pravidlech pro přenos „USN 7.7 - BP 3.0“ bylo opraveno pravidlo pro přenos informačního registru „Aktuální tarifní sazba zaměstnanců“.

Zvláštnosti převodu platebních příkazů pro platbu daní

U platebních příkazů s typem operace Převod daně je třeba vyplnit další údaje: KBK - kód klasifikace rozpočtu, stav původce atd. Struktury těchto podpěr v Bukh 7.7 (USN 7.7) a v BP 3.0 neshodují. Zejména v BP 3.0 některé z těchto údajů jsou obsaženy v samostatném adresáři, jehož odkaz je uveden v platebním příkazu. Adresář Druhy daní a plateb do rozpočtu obsahuje řadu dodaných prvků, které se objevují na infobase, například při úpravách účetních zásad. Při přenosu dat se tyto položky objeví také při načítání účetních zásad. Při vykládání a načítání platebních příkazů prvek adresáře Druhy daní a plateb do rozpočtu hledal KBK pro nahrazení v podrobnostech platebního příkazu Daň... Proto se doporučuje po převodu účetních pravidel zkontrolovat, zda se v referenční knize objevily všechny potřebné daně, pokud je to nutné, doplněné. Při porovnávání (synchronizaci) BCC v platebních příkazech ve zdroji a přijímači se nebere v úvahu čtyři číslice BCC, kategorie 14-17, kód příjmového poddruhu: daň, pokuty, pokuty atd. V odkazu Druhy daní a plateb do rozpočtu tyto bity jsou vyplněny nulami. Při přidávání nových prvků do adresáře by číslice 14-17 měly být také vyplněny nulami.

Přenos velkých databází.

Nejprve při přenosu velkých informačních databází může proces vykládky dat trvat velmi dlouho. K tomu dochází, pokud je v jedné účetní sekci velké množství zůstatků, například zůstatky zboží. Chcete-li zkrátit dobu nahrávání, můžete použít techniku \u200b\u200brozdělení jednoho dokumentu. “ Zadání počátečních zůstatků" pro pár. Pokud nastavíte hodnotu parametru " Počet řádků v dokumentu pro zadání zbytků»Kromě nuly (viz obr. 6.3) bude nahrávání dat do jednoho dokumentu omezeno na zadanou hodnotu. To může výrazně (několikrát) zkrátit dobu vykládky.

Obr.6.3 Nastavení parametrů při přenosu dat s omezením velikosti dokumentu " Zadání počátečních zůstatků»

Poznámka: hodnota parametru omezuje počet řádků tabulky transakcí, které jsou nahrány do jednoho dokumentu Zadání počátečních zůstatků„Spíše než specifikovat počet řádků v samotném dokumentu. Proto se počet řádků dokumentu bude lišit od hodnoty parametru, nejedná se o chybu. Při rozdělení dokumentu " Zadání počátečních zůstatků"U několika dokumentů bude do komentářů každého dokumentu na konci řádku přidán postfix:" -1 "," -2 "atd.

DŮLEŽITÉ! Popsaný algoritmus pro rozdělení jednoho dokumentu " Zadání počátečních zůstatků»Používá je jen několik lidí ke zkrácení času pro nahrávání dat, všechny dokumenty se nahrávají do jednoho souboru, tj. přenos dat probíhá v jednom kroku, komentáře (postfixy) jsou generovány automaticky, je nastaven pouze jeden parametr. Tato technika však neřeší problém nedostatku paměti, o kterém bude pojednáno níže.

Při přenosu velkých informačních bází může nastat problém s nedostatečnou pamětí RAM: při pokusu o uvolnění bude program ukončen s odpovídající chybovou zprávou nebo bez zprávy. Pokus o výměnu počítače za výkonnější je zbytečný. V takovém případě byste měli uvolnit data v blocích a rozdělit je na části. To vyžaduje pravidla migrace, která podporují zadaný režim. Zvažme, jak vyložit. Nejprve by měl být přenos dat proveden pouze pomocí jednoho pravidla pro vykládku (viz obrázek 6.4). Pokud je přenos podle jednoho pravidla také nemožný, rozdělíme jej na části označující počáteční a konečnou část. Každá část bude obsahovat informace o zadaném počtu analytických hodnot první úrovně, například zůstatky produktů, tj. stanovený počet hodnot zůstatků účtů „41“. Znáte-li celkový počet analytických údajů na účtu, je snadné vypočítat počet porcí. Kolik dat je přeneseno bez problémů najednou (do jedné informace) je třeba určit empiricky, zpravidla se při vykládání zůstatků na účtu objeví problémy s přenosem, když je počet zůstatků několik tisíc nebo více. Přestože je možné ušetřit čas při nahrávání dat, je možné doporučit rozdělení na části, i když se vám podaří nahrát všechny zůstatky v účetní sekci najednou. Doba nahrávání závisí na velikosti datové části, nikoli proporcionálně, ne lineárně. Rozdělení například deseti tisíc zůstatků podle zboží na deset částí o tisíc tedy může občas zkrátit čas vykládky. Pokud přeneseme první část, lze vynechat číslo počáteční části, pokud poslední část, pak lze vynechat číslo poslední části.

DŮLEŽITÉ! Při přenosu dat po částech je nutné v parametrech označit postfix, který se podílí na tvorbě komentáře k dokumentu “ Zadání počátečních zůstatků". Při změně čísel rozsahu porcí nezapomeňte změnit postfix, jinak budou při načtení do přijímací konfigurace přepsány dokumenty se stejnými komentáři (postfix). Název datového souboru ve skutečnosti nezáleží. Můžete použít taktiku postupného přenosu: vyložit - načíst, vyložit - načíst atd. V takovém případě není nutné název datového souboru měnit. Můžete zvolit taktiku: nejprve vše vyložit, poté vše stáhnout. V druhém případě bude nutné při každém nahrávání změnit název datového souboru. Další příklad. Pokud je počet zůstatků v účetní sekci (například zboží), řekněme 10 000, rozdělen na části tisícem, dostaneme 10 porcí. Každá část musí mít jedinečný postfix: „-1“, „-2“, „-3“, „-4“. Pokud uvolníme všechny zbytky zboží a poté načteme vše, musí být datové soubory také jedinečné, například: „41_1“, „41_2“, „41_3“, „41_4“. Parametry „Počátek čísla porce“ a „Konec čísla porce“ by měly nabývat hodnot: 0, 1000; 1001,2000; 2001, 3000; 3001, 4000.

Když je pracovní zkušenost přerušena po propuštění Od 1. ledna 2007 platí mírně odlišný postup pro stanovení kontinuity pracovní zkušenosti občana. Předtím, pokud při přechodu z jednoho pracoviště na druhé neuplynuly 3 týdny, zážitek nebyl přerušen. Od roku 2007 [...]
ANKO Tambov Center for Forensic Examinations and Research, ANO ANKO Tambov Center for Forensic Examinations and Investigations, ANO registered at Tambov, Rabochaya st., 37, office 40, 392008. ŘEDITEL AUTONOMNÍ NEZISKOVÉ ORGANIZACE TAMBOVSKÉHO CENTRÁLU ...
Objednávka v rozvrhu pracovní doby Vzorová objednávka v rozvrhu pracovní doby V rozvrhu pracovní doby V souladu s články 100, 103, 104, 73 zákoníku práce Ruské federace a Pravidly vnitřního rozvrhu práce PJSC "Organizace", za účelem optimalizace fungování podniku a zvýšení [...]
Úřadující společnost jmenována do centrální městské nemocnice č. 20 v Jekatěrinburgu, odkud byl propuštěn hlavní lékař | Sverdlovská oblast | Federální okruh Ural Alena Tunisová byla jmenována úřadující hlavní lékařkou nemocnice Central City Hospital č. 20 v Jekatěrinburgu. Jak píše zpravodaj [...]
Ohmův zákon paralelně Domů Pamatujte si fyziku: Třída 7 Třída 8 Třída 9 Třída 10-11 Videa z fyziky multimédia 7 stupňů. multimédia 8 cl. multimédia 9 cl. multimédia 10-11 cl. astronomické testy 7 cl. testy 8 cl. testy 9 cl. ukázková tabulka zkoušky [...]
Zákon RSFSR „O hospodářské soutěži a omezení monopolní činnosti na komoditních trzích“ 22. března 1991 N 948-1 (ve znění zákonů Ruské federace ze dne 24. června 1992 N 3119-1, ze dne 15. července 1992 N 3310-1; federální zákony ze dne 05.25. 1995 N 83-FZ, ze dne 06.05.1998 N 70-FZ, ze dne 02.01.2000 N 3-FZ, ze dne [...]

Migrace dat mezi různými konfiguracemi není triviální úkol. Jako vždy existuje několik způsobů řešení, ale ne všechny jsou optimální. Pokusme se pochopit nuance přenosu dat a zvolme univerzální strategii pro řešení těchto problémů.

Problém migrace dat (mluvíme zejména o produktech 1C) z jednoho řešení do druhého včera nevznikl. Společnost 1C dokonale chápe, s jakými potížemi se vývojáři potýkají při vytváření migrací, a proto se všemožně snaží pomoci s nástroji.

Během vývoje platformy společnost představila řadu univerzálních nástrojů i technologií, které zjednodušují přenos dat. Jsou zabudovány do všech typických řešení a problém migrace mezi identickými konfiguracemi byl vyřešen jako celek. Vítězství opět potvrzuje úzká integrace standardních řešení.

S migracemi mezi nestandardními řešeními je situace poněkud komplikovanější. Široká škála technologií umožňuje vývojářům nezávisle si vybrat nejlepší způsob řešení problému z jejich pohledu.

Podívejme se na některé z nich:

výměna prostřednictvím textových souborů;
pomocí výměnných plánů;
atd.

Každý z nich má své vlastní výhody a nevýhody. Stručně řečeno, hlavní nevýhodou je výřečnost. Vlastní implementace migračních algoritmů je plná významných časových nákladů a dlouhého procesu ladění. Nechci ani mluvit o další podpoře takových rozhodnutí.

Složitost a vysoké náklady na podporu přiměly 1C k vytvoření univerzálního řešení. Technologie, která usnadňuje vývoj a údržbu migrací. Výsledkem bylo, že myšlenka byla realizována ve formě samostatné konfigurace - „Data Conversion“.

Konverze dat je typické řešení, vlastní konfigurace. Každý uživatel s předplatným ITS: Prof si může tento balíček stáhnout zcela zdarma z webu uživatelské podpory nebo z disku ITS. Instalace se provádí standardním způsobem - stejně jako u všech ostatních typických řešení od společnosti 1C.

Nyní něco o plusech řešení. Začněme nejdůležitější věcí - všestranností. Řešení není přizpůsobeno konkrétním konfiguracím / verzím platformy. Funguje stejně dobře jak se standardními konfiguracemi, tak s vlastními konfiguracemi. Vývojářům je poskytována univerzální technologie a standardizovaný přístup k vytváření nových migrací. Všestrannost řešení vám umožňuje připravit migrace i pro jiné platformy než 1C: Enterprise.

Druhým velkým plusem je vizuál. Jednoduché migrace se vytvářejí bez programování. Ano, ano, bez jediného řádku kódu! Jen kvůli tomu stojí za to strávit čas jednou učením se technologie a poté mnohokrát použít neocenitelné dovednosti.

Třetí výhodou, na kterou bych poukázal, je absence omezení distribuce dat. Vývojář sám zvolí způsob doručení dat do konfigurace přijímače. Po vybalení z krabice jsou k dispozici dvě možnosti: nahrávání do souboru XML a přímé připojení k informační databázi (COM / OLE).

Studujeme architekturu

Již víme, že konverze dat dokáže zázraky, ale zatím není zcela jasné, jaké jsou technické výhody. První věc, kterou je třeba pochopit, je, že jakákoli migrace (převod) dat je založena na pravidlech výměny. Burzovní pravidla - běžný xml soubor s popisem struktury, do které se budou nahrávat data z IB. Zpracování služby, které uvolňuje / načítá data, analyzuje pravidla výměny a na základě nich provádí uvolnění. Během bootování je proces obrácen.

Konfigurace „KD“ je druh vizuálního konstruktoru, pomocí kterého vývojář vytváří pravidla výměny. Neví, jak uvolnit data. Je za to zodpovědné další zpracování externí služby obsažené v distribuci CD. Existuje několik z nich (XX v názvu souboru je číslo verze platformy):

MDXXExp.epf - zpracování umožňuje uvolnění popisu struktury infobase do souboru xml. Popis struktury je načten na CD pro další analýzu a vytvoření pravidel výměny.
V8ExchanXX.epf - vykládá / načítá data z databáze v souladu s pravidly pro výměnu. Ve většině typických konfigurací je zpracování k dispozici po vybalení z krabice (viz položka nabídky „Servis“). Zpracování je univerzální a není vázáno na žádnou konkrétní konfiguraci / pravidla.

Dobře, nyní na základě výše uvedeného, \u200b\u200bpojďme definovat fáze vývoje nové konverze:

Definice úkolu. Je nutné jasně pochopit, jaká data je třeba přenést (ze kterých konfiguračních objektů) a co je nejdůležitější, kam je přenést.
Příprava popisu konfiguračních struktur (Zdroj / Cíl) pro následné načtení na CD. Úkol je vyřešen zpracováním služby MDXXExp.epf.
Načítání připravených popisů konstrukcí do IB.
Vytváření pravidel výměny pomocí vizuálních nástrojů CD.
Nahrávání / stahování podle vytvořených pravidel převodu dat pomocí zpracování V8ExchanXX.epf.
Ladění pravidel výměny (v případě potřeby).

Nejjednodušší převod

Pro demonstraci potřebujeme dvě nasazené konfigurace. Rozhodl jsem se zůstat u možnosti 10. vydání „Trade Management“ a malého řešení napsaného samostatně. Úkolem bude přenos dat z typické konfigurace UT. Pro stručnost zavoláme samo-napsané řešení „Receiver“ a řízení obchodu „Source“. Začněme problém vyřešit přenesením prvků příručky „Nomenklatura“.

Nejprve se podívejme na schéma převodu dat a znovu si přečtěte seznam akcí, které je třeba provést. Poté spustíme konfiguraci „Zdroj“ a otevřeme v ní zpracování služby MD82Exp.epf.

Rozhraní zpracování nesvítí s množstvím nastavení. Uživatel potřebuje pouze určit typy objektů metadat, které nebudou zahrnuty v popisu struktury. Ve většině případů není nutné tato nastavení měnit. při vykládání pohybů v akumulačních registrech nemá žádný zvláštní smysl (jako příklad).

Pohyb je správnější, aby se vytvořil během dokumentů, které jsou drženy v přijímači. Všechny pohyby po provedení provede samotný dokument. Druhým argumentem na obranu výchozího nastavení je zmenšení velikosti souboru při nahrávání.

Některé dokumenty (zejména v typických konfiguracích) generují pohyby napříč více registry. Po uvolnění celé této farmy by výsledný soubor XML byl příliš velký. To může komplikovat následnou přepravu a nakládku do základny přijímače. Čím větší je datový soubor, tím více RAM je pro jeho zpracování potřeba. V průběhu své praxe jsem narazil na obscénně velké nahrávací soubory. Tyto soubory zcela odmítly být analyzovány standardními prostředky.

Necháme tedy všechna výchozí nastavení a nahrajeme popis konfigurace do souboru. Stejný postup opakujeme pro druhou základnu.

Otevřete CD a vyberte v hlavní nabídce „Adresáře“ -\u003e „Konfigurace“... Odkaz obsahuje popis struktur všech konfigurací, které lze použít k vytvoření převodu. Popis konfigurace načteme jednou a poté jej můžeme použít mnohokrát k vytvoření různých převodů.

V okně adresáře stiskněte tlačítko „ Přidat do„A v okně, které se objeví, vyberte soubor s popisem konfigurace. Zaškrtneme políčko „Načíst do nové konfigurace“ a klikneme na tlačítko „Spustit načtení“. Totéž uděláme s popisem struktury druhé konfigurace.

Vše je nyní připraveno k vytvoření pravidel výměny. V hlavní nabídce CD vyberte „Odkazy“ -\u003e „Konverze“. Přidáme nový prvek. V okně pro vytvoření nové převodu musíte zadat: konfiguraci zdroje (vyberte UT) a konfiguraci přijímače (vyberte „Přijímač“). Dále otevřete kartu „Upřesnit“ a vyplňte následující pole:

název souboru pravidel výměny - vytvořená pravidla výměny budou uložena pod tímto názvem. Název souboru lze kdykoli změnit, ale nyní je výhodnější jej nastavit. To v budoucnu ušetří čas. Pravidla pro ukázku jsem pojmenoval: rules-ut-to-priemnik.xml.
name - název převodu. Název může být naprosto jakýkoli, omezil jsem se na „Demo. UT do přijímače “.

To je vše, klikněte na „OK“. Okamžitě se před námi objeví okno s otázkou, abychom automaticky vytvořili všechna pravidla. Souhlas s takovou lákavou nabídkou dá průvodci příkaz, aby automaticky analyzoval popis vybraných konfigurací a nezávisle vygeneroval pravidla výměny.

Pojďme hned na „a“. Velitel nebude schopen generovat nic vážného. Tato funkce by však neměla být zlevněna. Pokud je nutné navázat výměnu mezi identickými konfiguracemi, pak budou služby hlavního serveru velmi užitečné. V našem příkladu je vhodnější manuální režim.

Podívejme se blíže na okno „Nastavení pravidel serveru Exchange“. Rozhraní se může zdát trochu matoucí - velké množství karet nabitých ovládacími prvky. Ve skutečnosti není všechno tak obtížné, na toto šílenství si začnete zvykat po několika hodinách práce s aplikací.

V této fázi nás zajímají dvě karty: „Pravidla převodu objektů“ a „Pravidla nahrávání dat“. Nejprve musíme nastavit pravidla párování, tj. porovnat objekty dvou konfigurací. Na druhé, k určení možných objektů, které budou uživateli k dispozici pro uvolnění.

Ve druhé polovině karty „Pravidla převodu objektů“ je další panel se dvěma kartami: „Převod vlastností“ a „ Převod hodnot“. První vybere vlastnosti (atributy) vybraného objektu a druhý je potřebný pro práci s předdefinovanými hodnotami (například předdefinované katalogové prvky nebo výčetové prvky).

Skvělé, nyní vytvořme pravidla převodu pro referenční knihy. Tuto akci můžete provést dvěma způsoby: použijte Průvodce synchronizací objektů (tlačítko „“) nebo ručně přidejte shody pro každý objekt.

Pojďme použít první možnost pro úsporu místa. V okně průvodce zrušte zaškrtnutí políček u položky „ Dokumenty„(Zajímají nás pouze referenční knihy) a otevřít skupinu“ Adresáře“. Pečlivě procházíme seznam a díváme se na názvy referenčních knih, které lze srovnávat.

V mém případě existují tři takové adresáře: nomenklatura, organizace a sklady. K dispozici je také referenční kniha Klienti, která plní stejnou sémantickou zátěž jako „ Dodavatelé"Z konfigurace" UT“. Je pravda, že se jim pán nemohl vyrovnat kvůli jejich vynikajícím jménům.

Tuto chybu můžeme opravit sami. Najdeme v okně " Shoda objektů"Příručka" Klienti", A ve sloupci" Zdroj "vyberte adresář" Dodavatelé ". Poté zaškrtněte políčko ve sloupci „Typ“ a stiskněte tlačítko „OK“.

Průvodce synchronizací objektů nabídne automatické vytvoření pravidel pro převod vlastností všech vybraných objektů. Vlastnosti budou mapovány podle názvu a pro naši demonstraci to bude dost, souhlasíme. Další otázkou bude návrh na vytvoření pravidel pro vykládku. Souhlasíme také.

Základ pro pravidla směny je připraven. Vybrali jsme objekty pro synchronizaci a pravidla pro převod vlastností a pravidla pro uvolnění byla vytvořena automaticky. Uložme pravidla výměny do souboru, poté otevřete IB „Zdroj“ (v mém případě je to UT) a spusťte v něm zpracování služby V8Exchan82.epf.

Nejprve v okně zpracování vyberte pravidla výměny, která jsme vytvořili. Na otázku načítání pravidel odpovídáme kladně. Zpracování bude analyzovat pravidla výměny a sestaví strom objektů stejného jména, které jsou k dispozici pro uvolnění. Pro tento strom můžeme nastavit nejrůznější výběry nebo vyměnit uzly, podle jejichž změn musíme vybrat data. Chceme stáhnout absolutně všechna data, takže není třeba instalovat filtry.

Po dokončení procesu nahrávání dat do souboru přejděte na IB “ Přijímač“. V něm také otevíráme zpracování V8Exchan82.epf, pouze tentokrát přejděte na kartu „Stažení dat“. Vyberte datový soubor a stiskněte tlačítko „Načíst“. Všechno, data byla úspěšně přenesena.

Skutečné úkoly

První ukázka by mohla být zavádějící. Všechno vypadá celkem jednoduše a logicky. Ve skutečnosti to není pravda. Ve skutečné práci vznikají problémy, které je obtížné nebo zcela nemožné vyřešit pouze vizuálními prostředky (bez programování).

Abych nebyl zklamán technologií, připravil jsem několik skutečných problémů. Při práci na ně musíte narazit. Nevypadají tak triviálně a nutí vás dívat se na převod dat z nového úhlu. Pečlivě zvažte předložené příklady a neváhejte je použít jako úryvky při řešení skutečných problémů.

Problém číslo 1. Vyplníme chybějící podrobnosti

Předpokládejme, že musíme převést adresář z UT “ Dodavatelé“. Přijímač má podobný adresář „Klienti“. Je zcela vhodný pro ukládání dat, ale má rekvizity „ Organizace”, Což vám umožňuje oddělit dodavatele přidružením k organizaci. Ve výchozím nastavení musí všichni dodavatelé odkazovat na aktuální organizaci (lze ji získat ze stejnojmenné konstanty).

Problém má několik řešení. Zvažujeme možnost vyplnění požadovaného “ Organizace„Přímo v databázi“ Přijímač", Tj. v době načítání dat. Aktuální organizace je uložena v konstantě, proto není překážkou pro získání této hodnoty. Pojďme otevřít pravidlo převodu objektu (dále jen PCO) “ Klienti“(Poklepejte na objekt) a v průvodci pravidly přejděte do sekce„ Obslužné rutiny událostí “. V seznamu manipulátorů najdeme „ Po načtení”.

Popíšeme kód pro získání aktuální organizace s následným přiřazením k požadovanému. V okamžiku, kdy je spuštěna obslužná rutina Po načtení, bude objekt plně vytvořen, ale ještě nebyl zapsán do databáze. Nikdo nám nezakazuje to změnit podle našeho uvážení:

Pokud NE Object.EtoGroup, pak Object.Organization \u003d Constants.CurrentOrganization.Get (); EndIf;

Před vyplněním požadovaných údajů " Organizace"Je bezpodmínečně nutné zkontrolovat hodnotu proměnné" Tato skupina". Pro odkaz „ Klienti»Je nastaven příznak hierarchie, takže je nutná kontrola skupiny. Podobným způsobem jsou vyplněny všechny podrobnosti. Nezapomeňte si přečíst nápovědu k dalším parametrům obslužné rutiny " Po stažení". Například mezi nimi je parametr „ Zřeknutí se". Pokud mu přiřadíte hodnotu „True“, nebude objekt zapsán do databáze. Je tedy možné omezit objekty pro záznam v době načítání.

Problém číslo 2. Podrobnosti do informačního registru

V odkazu „ Dodavatelé"UT konfigurace, tam jsou podrobnosti" Kupující"A" Poskytovatel“. Oba atributy jsou typu „ Booleovský„A slouží k určení typu protistrany. V IB “ Přijímač„, V příručce“ Klienti„Neexistují žádné podobné podrobnosti, ale existuje registr informací.“ Typy klientů“. Provádí podobnou funkci a může uložit několik funkcí pro jednoho klienta. Naším úkolem je převést hodnoty atributů do samostatných záznamů informačního registru.

Samotné vizuální prostředky se s tím bohužel nemohou vyrovnat. Začněme malý, vytvořme nový PKO pro informační registr “ Typy klientů“. Nezadávejte nic jako zdroj. Odmítněte automaticky vytvářet pravidla pro vykládku.

Dalším krokem je vytvoření pravidel pro vykládku. Přejděte na příslušnou záložku a stiskněte tlačítko „ Přidat do“. V okně pro přidání pravidel pro nahrávání vyplňte:

Metoda vzorkování. Změnit na „Free Algorithm“;
Pravidlo převodu. Vyberte registr informací "Druhy klientů";
Kód (název) pravidla. Zapisujeme to jako „Vykládání pohledů klientů“;

Nyní musíte napsat kód pro výběr dat pro nahrání. Parametr „ Načtení dat“. Můžeme dát kolekci s připravenou datovou sadou. Parametr „ Načtení dat„Může nabývat různých hodnot - výsledek dotazu, výběr, kolekce hodnot atd. Inicializujeme to jako tabulku hodnot se dvěma sloupci: klient a typ klienta.

Níže je uveden kód obslužné rutiny události „ Před zpracováním“. Inicializuje parametr „ Načtení dat„Následuje vyplnění dat z adresáře“ Dodavatelé“. Zde byste měli věnovat pozornost vyplnění sloupce „ Typ klienta“. V „UT“ máme znaky typu „Boolean“ a v přijímači je to přenos.

V této fázi je nemůžeme přivést na požadovaný typ (není v UT), takže je zatím necháme ve formě řetězců. Nemusíte to dělat, ale chci vám hned ukázat, jak vrhnout na chybějící typ ve zdroji.

DataFetch \u003d NewValuesTable (); FetchData.Columns.Add ("klient"); FetchData.Columns.Add ("ClientType"); FetchingDataFromDirectory \u003d Directories.Contractors.Select (); While FetchingDataFromDirectory.Next () Loop If FetchingDataFromDirectory.ThisGroup Then Continue; EndIf; Pokud DataFetchFromDirectory.Customer Then NewRow \u003d DataFetch.Add (); NewString.Client \u003d DataFetchFromDirectory.Link; NewString.ClientType \u003d "Kupující"; EndIf; IfFetchDataFromDirectory.Provider Then NewRow \u003d FetchData.Add (); NewString.Client \u003d DataFetchFromDirectory.Link; NewString.ClientType \u003d "Dodavatel"; EndIf; Konec cyklu;

Uložme si pravidlo pro vykládku dat a vraťme se k „ Pravidla převodu objektů“. Přidat pro informační registr “ Typy klientů„Pravidla převodu nemovitosti: klient a typ klienta. Nechejte zdroj prázdný a napište do obslužné rutiny události „Před uvolněním“:

// Pro vlastnost „Klient“ Hodnota \u003d Source.Client; // Pro vlastnost „ClientType“ If Source.Client \u003d "Customer" Then Expression \u003d "Enumerations.ClientTypes.Customer" AnotherIf Source.Client \u003d "Supplier" Then Expression \u003d "Enumerations.ClientTypes.Supplier"; EndIf;

V seznamu jsou podrobnosti vyplněny na základě provedeného výběru dat. Klienta přeneseme jednoduše jako odkaz a typ klienta zapíšeme do parametru „ Výraz". Data tohoto parametru budou interpretována v přijímači a při spuštění bude proměnná vyplněna správnou hodnotou z výčtu.

To je vše, pravidla pro výměnu jsou připravena. Uvažovaný příklad se ukázal jako docela univerzální. Tento přístup se často používá při migraci dat z konfigurací vytvořených na platformě 7.7. Pozoruhodným příkladem toho je přenos pravidelných potřeb.

Problém číslo 3. Triky v tabulkové sekci

Poměrně často narazíte na úkoly, které vyžadují zveřejnění řádků jedné tabulkové sekce do několika. Například v počáteční konfiguraci jsou služby a zboží uspořádány do jedné tabulkové sekce a úložiště těchto entit je v přijímači odděleno. Problém opět nelze vyřešit vizuálními prostředky. Zde je vhodné brát jako základ řešení druhého problému.

Vytvoříme pravidlo pro uvolnění dat, určíme libovolný algoritmus a do obslužné rutiny „Před uvolněním“ napíšeme požadavek na získání dat z tabulkové sekce.

Kvůli úspoře místa nebudu citovat kód žádosti (vždy můžete odkazovat na zdrojový kód) - není v ní nic neobvyklého. Výsledný výběr iterujeme a seřazené výsledky umístíme do již známého parametru „ Načtení dat“. Opět je vhodné použít tabulku hodnot jako kolekci:

DataFetch \u003d NewValuesTable (); // K dispozici bude ještě jedna tabulková sekce DataFetch.Columns.Add („Produkty“); // K dispozici bude také tabulková sekce DataFetch.Columns.Add („Služby“); FetchData.Columns.Add („Odkaz“);

Problém číslo 4. Přenos dat do operace

Pokud organizace používá několik účetních systémů, bude dříve či později potřeba migrace dat s následným vytvořením účtování.

V konfiguraci “ BP„Existuje univerzální dokument“ Úkon„A je ideální pro generování více potenciálních zákazníků. Zde je jen jeden úkol, který není úkolem - dokument je vytvořen rafinovaně a není snadné do něj přenést data.

Příklad takové konverze najdete ve zdrojovém kódu článku. Objem kódu se ukázal být poměrně velký, takže nemá smysl ho publikovat pro článek. Jen řeknu, že vykládka znovu používá libovolný algoritmus v pravidlech pro vykládání dat.

Problém číslo 5. Synchronizace dat pro několik požadavků

Už jsme se podívali na několik příkladů, ale stále jsme nemluvili o synchronizaci objektů během migrace. Představme si, že musíme převést dodavatele a někteří z nich jsou pravděpodobně v databázi příjemce. Jak přenést data a zabránit duplikátům? V tomto ohledu CD nabízí několik způsobů synchronizace přenosných objektů.

První je založen na jedinečném identifikátoru. Mnoho objektů má jedinečný identifikátor, který zaručuje jedinečnost v tabulce. Například v odkazu „ Dodavatelé„Nemohou existovat dva prvky se stejným identifikátorem. CD provede výpočet a pro všechny vytvořené PQS je ve výchozím nastavení zapnuto vyhledávání podle identifikátoru. Během vytváření PCO byste měli věnovat pozornost obrazu lupy vedle názvu objektu.

Synchronizace pomocí jedinečného identifikátoru je spolehlivá metoda, ale zdaleka není vždy vhodná. Při kombinování adresářů “ Dodavatelé„(Z několika různých systémů) to moc nepomůže.

V takových případech je správnější synchronizovat objekty podle několika kritérií. Správnější je hledat protistrany podle TIN, KPP, názvu nebo vyhledávání rozdělit do několika fází.

Konverze dat neomezuje vývojáře při určování kritérií vyhledávání. Uvažujme o abstraktním příkladu. Předpokládejme, že musíme synchronizovat adresáře “ Dodavatelé„Z různých informačních základen. Připravme POC a zaškrtněte políčko “ Pokud cílový objekt nebyl nalezen podle identifikátoru, pokračujte v hledání“. Touto akcí jsme okamžitě definovali dvě vyhledávací kritéria - pomocí jedinečného identifikátoru a vlastních polí.

Máme právo zvolit si pole sami. Po zaznamenání INN, KPP, Název, okamžitě označíme několik vyhledávacích kritérií. Výhodně? Docela, ale opět to nestačí. Co když chceme změnit kritéria vyhledávání? Například nejdříve hledáme odkaz TIN + KPP, a pokud nic nenajdeme, začneme zkoušet štěstí se jménem.

Je docela možné takový algoritmus implementovat. V obslužném programu události „ Vyhledávací pole„Můžeme zadat až 10 vyhledávacích kritérií a pro každé z nich definovat vlastní sadu vyhledávacích polí:

Pokud SearchVariantNumber \u003d 1, pak SearchPropertyNameString \u003d “INN, KPP”; Jinak pokud SearchVariantNumber \u003d 2 Pak SearchPropertyNameString \u003d "Jméno"; EndIf;

Vždy existuje několik řešení

Jakýkoli úkol má několik řešení a přenos dat mezi různými konfiguracemi není výjimkou. Každý vývojář má právo zvolit si vlastní cestu řešení, ale pokud neustále musíte vyvíjet složité migrace dat, pak důrazně doporučuji věnovat pozornost "" konfiguraci. Nejprve je nutné investovat prostředky (čas) do školení, ale na první více či méně seriózní projekt se více než vyplatí.

Podle mého názoru 1C nezaslouženě obchází téma používání převodu dat. Během celé existence této technologie byla na ní vydána pouze jedna kniha: „1C: Enterprise 8. Data Conversion: Exchange between Application Solutions“. Kniha je docela stará (2008), ale je stále žádoucí se s ní seznámit.

Znalost platforem je stále nezbytná

„Je to univerzální nástroj, ale pokud ho plánujete použít k vytvoření migrace dat z konfigurací vyvinutých pro platformu 1C: Enterprise 7.7, budete muset strávit čas seznámením se s vestavěným jazykem. Syntax a ideologie jazyka je velmi odlišná, takže musíte věnovat čas učení. Jinak zůstává princip stejný.

Typická pravidla pro přenos dat 1c. Příklad pravidla pro převod objektů. Vlastnosti typických pravidel přenosu

Co přesně je v dnešních videích

Video 1:
Načítání pravidel výměny mezi typickými konfiguracemi v Data Conversion 3.0

Video 2:
Úprava pravidel směny v CD 3.0

Video 3:
Nastavení univerzální výměny mezi typickými konfiguracemi

Video 4:
Přenos počátečních zůstatků pomocí směnných pravidel

P.S.

P.P.S.

Přenos dat z 1C 7,7 na 1C 8,3 účetnictví 3.0

Jak přenést databázi 1C 7,7 na 8,3?

Pravidla převodu 1 s 8

Studujeme architekturu

Nejjednodušší převod

Skutečné úkoly

Problém číslo 1. Vyplníme chybějící podrobnosti

Problém číslo 2. Podrobnosti do informačního registru

Problém číslo 3. Triky v tabulkové sekci

Problém číslo 4. Přenos dat do operace

Problém číslo 5. Synchronizace dat pro několik požadavků

Vždy existuje několik řešení

Znalost platforem je stále nezbytná

Líbilo se mi to?

Příklady dotazů pro práci s hierarchickými adresáři Získejte nejvyšší úroveň hierarchie 1c

Zvláštnost provádění funkce substring ()

Nerozpoznaná chyba HRESULT \u003d 80004005 nebo proč se databáze nevypisují na dt Relace byla ukončena správcem

Nové funkce pro práci s řetězci

Zarážka nefunguje 1 s 8

Nové funkce pro práci s řetězci

Nové funkce pro práci s řetězci

Scd je externí zdroj dat, načítáme z tz a poté získáváme zůstatky pro každý dokument

Dávkové žádosti o figuríny Spuštění dávky požadavku 1 s 8

Datová struktura 1c 8.3. Struktura úložiště databáze (spravované formuláře). Rozdíly od stávajících implementací

Co přesně je v dnešních videích

Video 1: Načítání pravidel výměny mezi typickými konfiguracemi v Data Conversion 3.0

Video 2: Úprava pravidel směny v CD 3.0

Video 3: Nastavení univerzální výměny mezi typickými konfiguracemi

Video 4: Přenos počátečních zůstatků pomocí směnných pravidel

P.S.

P.P.S.

Přenos dat z 1C 7,7 na 1C 8,3 účetnictví 3.0

Jak přenést databázi 1C 7,7 na 8,3?

Pravidla převodu 1 s 8

Studujeme architekturu

Nejjednodušší převod

Skutečné úkoly

Problém číslo 1. Vyplníme chybějící podrobnosti

Problém číslo 2. Podrobnosti do informačního registru

Problém číslo 3. Triky v tabulkové sekci

Problém číslo 4. Přenos dat do operace

Problém číslo 5. Synchronizace dat pro několik požadavků

Vždy existuje několik řešení

Znalost platforem je stále nezbytná

Líbilo se mi to?

Video 1:
Načítání pravidel výměny mezi typickými konfiguracemi v Data Conversion 3.0

Video 2:
Úprava pravidel směny v CD 3.0

Video 3:
Nastavení univerzální výměny mezi typickými konfiguracemi

Video 4:
Přenos počátečních zůstatků pomocí směnných pravidel