Приклад правила конвертації об'єктів. Приклад правила конвертації об'єктів Вартість типового перенесення даних

І показуємо, як з її допомогою СИЛЬНО спростити рішення своїх завдань

Сьогодні ми розберемо, як буквально за 10-15 хвилин налаштувати і зробити простий перенесення довідників і початкових залишків.

А це - масова і регулярна завдання, Яка практично неминуча для більшості запускаються нових конфігурацій.

Тому покличте колег, їм це буде теж дуже корисно.

Особливо, якщо вони вже бачили КД 3 і встигли злякатися :)

Так, коли її бачиш вперше - там взагалі ні фіга не зрозуміло.

Але насправді - все ДУЖЕ просто. Настільки просто, що вам потім навіть нудно буде :)

Що конкретно в сьогоднішніх відео

Це 4 відео з обміну даними через універсальний формат обміну EnterpriseData.

Крім того, ми покажемо приклад доопрацювання типових правил обміну в 1С: Конвертації даних 3.0

Загальна тривалість - 34 хвилини. зміст:

• Налаштування обміну на прикладі 1С: Бухгалтерія 8 і 1C: ERP
• Як зробити завантаження типових правил і універсального формату обміну в Конвертації Даних 3.0
• Перенесення структури метаданих в КД 3.0
• Як виконати перший обмін даними
• доопрацювання правил конвертації
• Як завантажити нові правила без зміни конфігурації ( без зняття з підтримки)

Зверніть увагу, Що при вирішенні цього завдання змінюються правила завантаження тільки в конфігурації-приймачі. А конфігурація-джерело працює за типовими правилами.

Якби подібне завдання вирішувалася в Конвертації даних 2.0, то зміни довелося б вносити в правилах і джерела, і приймача.

Дані відеоуроки актуальні для БСП редакції 2.3.2 (Для будь-якої збірки старше 2.3.2.43).

Якщо Ви використовуєте більш старшу версію БСП, 0 зробіть «поправку» на змінився інтерфейс і розширену функціональність. Для цього самостійно повторіть приклад з відео.

Відео 1:
Завантаження правил обміну між типовими конфігураціями в Конвертацію даних 3.0

У цьому уроці виконаємо підготовчі дії при внесенні змін до правил обміну між типовими конфігураціями:

• Завантаження в КД структури формату обміну (
• створення конвертації
• Вивантаження файлів правил з типової конфігурації
• Вивантаження модуля менеджера обміну

Відео 2:
Доопрацювання правил обміну в КД 3.0

У цьому уроці ми покажемо, як дозаповнити реквізити об'єктів при завантаженні даних.

Буде вирішена задача - при завантаженні об'єктів з конфігурації-джерела встановлювати коментар "Завантажено з БП 3.0".

Для вирішення завдання потрібно внести зміни в правилах конвертації об'єктів, В подію "Перед записом отриманих даних".

Розроблені правила будуть збережені у вигляді зовнішньої обробки для подальшого використання.

Відео 3:
Налаштування універсального обміну між типовими конфігураціями

У цьому уроці ми покажемо, як налаштовувати новий обмін між типовими.

Налаштування будуть зроблені в конфігурації-джерелі і потім завантажені в конфігурацію-приймач.

Також в цьому відео ми покажемо, як без зміни конфігурації довантажити нові правила обміну.

Відео 4:
Перенесення початкових залишків за допомогою правил обміну

В уроці покажемо типовий функціонал перенесення початкових залишків.

P.S.

Так, обміни через txt / dbf / ole і т.д. мають право на існування. В якихось спеціальних випадках, типу стикування з веб-сервером або перенесення з готового формату зовнішнього застосування.

Однак для стандартних обмінів - стандартні методи і швидше, і сильно простіше.

А якщо хтось винаходить велосипед, коли є готове універсальне рішення - це як написати собі на лобі "інструментом не володію, вивчати не хочу, буду будувати милиці за ваші гроші" .

P.P.S.

Ми хочемо показати, що Конвертація Даних 3.0 - це не складно.

Незвично - так. Не всі відразу зрозуміло - так. Є дуже неоднозначні моменти - так.

Але за допомогою готових інструкцій і відео її можна освоїти буквально за 1-2 тижні.

1. Вступ.

2. Що знадобиться: конфігурація 1С: Конвертація даних 2. * і обробки з пакета. Для Прімера завдань візьмемо конфігурації 1С: Управління торгівлею 11 і 1С: БП 3. *.

Отже, для розробки правил вивантаження даних в 1С потрібно конфігурація 1С: Конвертація об'єктів 2, а також обробки, що входять в пакет.

Наприклад, у нас вже розгорнута база конвертації і запущена.

Розробку правил обміну писатимемо між конфігурацією 1С: Управління торгівлею 11 і 1С: Бухгалтерія підприємства 3 (правила обміну УТ / БУХ).

3. Нам знадобляться Обробки для вивантаження структури метаданих та обміну.

Перше, що потрібно отримати для розробки - це файли зі структурою метаданих. Виконується це за допомогою обробок вивантаження структури метаданих, що входять в пакет конвертації об'єктів.

Власне, в розпакованому каталозі конфігурацій для конфігурацій на керованих формах нас цікавить обробка MD83Exp.epf. Якщо вивантаження потрібно зробити з конфігурацій на звичайних формах, Тоді використовується обробка MD82Exp.epf. Це якщо, наприклад, потрібно отримати структуру з таких конфігурацій, як 1С: УТ 10, 1С: Управління виробничим підприємством 1.3, 1С: Комплексна автоматизація 1.1, 1С: зуп 2.5 і так далі.

Далі вже для вивантаження-завантаження даних в 1С за допомогою наших правил знадобиться обробка « універсальний обмін даними в форматі XML »V8Exchan83.epf для конфігурацій на керованих формах таких як 1С: Управління торгівлею 11. *, 1С БП 3, 1С: ERP 2. * і подібних. І відповідно V8Exchan83.epf - для конфігурацій на звичайних формах.

4. Вивантаження структури метаданих конфігурації 1С: Управління торгівлею 11.3 і 1С: Бухгалтерія підприємства 3.0. *

Почнемо з вивантаження структури метаданих з конфігурації 1С: Бухгалтерія підприємства 3.
Відкриємо обробку MD83Exp.epf

У формі обробки є додаткові налаштування, Де ми можемо включити або відключити параметр вивантажувати регістри і руху в 1С. Також є вибір, де буде проходити вивантаження: на сервері 1С або «на клієнті.» Вказуємо назву файлу, куди вивантажиться структура даних. Аналогічним чином робимо вивантаження структури метаданих конфігурації Управління торгівлею 11.

Тепер необхідно завантажити конфігурацію в базу конвертацій. До даного пункту можна прийти і зі списку конфігурацій, і зі списку конвертацій. Зробимо просто завантаження з робочого столу:

У діалоговому вікні завантажуємо структуру БП:

І аналогічно - структуру Управління торгівлею.

Після закінчення завантаження з'явиться діалогове вікно, де можна вказати зручний для вас найменування.

6. Створення правил конвертації в 1С на конкретному прикладі завдання.

Далі переходимо в «Налаштування правил об'єкта», де створюємо нову настройку.
У діалоговому вікні створення конвертації вибираємо конфігурацію «джерело» і конфігурацію «приймач» (які раніше завантажили) і натискаємо ОК.

Так як в цій статті планував показати створення «з нуля» і «без сміття», нагадую, що нічого автоматично не створимо. Ніяких прототипів.

У цьому діалоговому вікні нічого виконувати не будемо, просто натиснемо - «Закрити».

Створимо правила для вивантаження не один документ в один, а один вид в інший, наприклад, документ РеалізацііТоваровУслуг з УТ 11 з необхідними довідниками в документ ПоступленіеТоваровУслуг в БП 3.

Отже, створюємо нове ПКО (правило конвертації об'єктів в 1С)

Вибираємо джерело РеалізаціяТоваровУслуг і приймач ПоступленіеТоваровУслуг і натискаємо ОК.
При цьому з'явиться діалогове вікно, де знову відмовляємося від автоматичного створення ПКС (Правил конвертації властивостей). Далі виберемо тільки необхідні.

А ось на пропозицію створити ПВД \u200b\u200b(правил вивантаження даних) відповідаємо «Так».

Створюються ПВД, які і будуть відображатися в обробці універсального обміну XML для вибору:

Утворюються так само правила конвертації даних з порожніми правилами конвертації властивостей.

Причому видно, що ПКО за замовчуванням пропонується шукати по внутрішньому ідентифікатором об'єкта. На це вказує лупа біля ПКО. Ми ж будемо робити свій пошук, і зробимо його за номером документа і дату на початок дня.

Знімаємо пошук по УДО:

Тепер почнемо зіставлення необхідних властивостей (реквізитів) об'єкта. Для цього тиснемо «СінхронізаціяСвойств» (мітка «1» на скрині). Прибираємо рекурсивне створення правил ( «2»). Знімаємо всі відмічені реквізити ( "3"). І виберемо самостійно, що нам потрібно.

Для прикладу вибираємо необхідне:

Звертаю увагу на те, що ми зробимо ПКС контрагента в організацію, а організацію в контрагента, і ще можна порівняти деякі реквізити, які не збігаються в назві, наприклад, «Валюта» і «Валюта документа».

Де бачимо, що ще немає правил конвертації.

Почнемо з реквізитами проходити і описувати. Спочатку налаштовуємо пошук документа так, як писав раніше, робимо вивантаження і пошук документа на початок дати, і зробимо заміну нумерації. Перші три символи будемо підміняти на свій префікс «УТБ». А так як в БП і УТ нумерація по 11 символів, робимо складовою номер: наш префікс і 8 символів від джерела. Приклад на скрині нижче.

Вивантаження документів робимо завжди непроведення і без руху. Припускаємо, що документи будуть в приймальнику проводитися після перевірки користувачем.

Для цього ПКС встановивши, що не проведено, 0 або 1, використовуємо як логічне.

На прикладі валюти створюємо для ПКС правило конвертації об'єкта. При цьому вважаємо, що в обох базах валюти є, і вони повинні синхронізуватися за кодом. Тому в ПКО валюти не будемо створювати всі ПКС, а тільки додамо Код для пошуку. Тобто від пропозиції створити ПКС для об'єкта - відмовляємося.

У ПКО документа для ПКС підставити створене Правило конвертації. А саме правило за замовчуванням пропонується за унікальним ідентифікатором. Виправляємо, робимо пошук за кодом і встановлюємо властивість, щоб не створювати новий об'єкт.

У підсумку отримуємо варіант:

Далі за аналогією створюємо для інших реквізитів ПКО і ПКС. Причому пошук організації по контрагенту і навпаки встановлюємо по ІПН. Приблизно так це виглядає з мінімальними реквізитами (можна додавати при необхідності).

Для ПКО Договори контрагентів робимо пошук по ПКС Контрагент, найменування і власник.

Подивимося, як вказати в ПКС потрібне значення в типі перерахування. Наприклад, реквізит «ВідОпераціі». Тут можна використовувати різні умови і підставляти значення. Наприклад, нам потрібно, щоб «вид операції» вивантажуються завжди «Товари», в цьому випадку досить в «лоб» написати потрібне значення рядком.

Нижче показано, як встановити без складнощів і в більшості випадків ПКС для КратностьВзаіморасчетов, КурсВзаіморасчетов, Рахунки обліку.

Для ПКО Номенклатура залишимо пошук по внутрішньому унікальним ідентифікатором. Але зверну увагу на те, як можна перевизначити свою групу. Наприклад, ми згодні, що вивантажуватиметься нова номенклатура з конфігурації 1С: Управління торгівлею 11, але потрібно, щоб номенклатура збиралася в певній групі «НашаГруппа».

Для реалізації даного завдання створюємо ще одне ПКО. Назвемо його «НоменклатураРодітель», яке вкажемо в ПКС батька в правилі конвертації.

Встановлюємо два пошуку: по найменуванню, де найменування жорстко вказуємо нашої групи, і обов'язковою властивістю ознаки «ЕтоГруппа» в істина.

Оскільки ми прийняли рішення, що у нас вся номенклатура падає в нашу групу, то немає необхідності при вивантаженні вивантажувати групи з УТ 11. Для цього в ПКО Номенклатура в обробнику подій «ПередВигрузкой» поставимо фільтр, що не потрібно вивантажувати групи «Відмова \u003d Джерело. Це група;".

У ПВД (правила вивантаження даних) РеалізацііТоваровУслуг, додамо фільтр, щоб не вивантажувалися помічені на видалення документи. Для цього в ПВД в обробниках подій «ПередВигрузкой» пропишемо фільтр «Відмова \u003d Об'ект.ПометкаУдаленія;».

Збережемо розроблені правила в файл.

7. Підводимо підсумки: Вивантаження і завантаження даних за допомогою розроблених правил обміну даними.

Відкриваємо в 1С: Управління торгівлею 11 обробку «Універсальний обмін даними в форматі XML» V8Exchan83.epf.

Вивантаження пройшла, тепер цієї ж обробкою робимо завантаження в 1С: Бухгалтерія підприємства 3.

Завантаження пройшло. Перевіряємо, що як загрузилось. Отже, документ завантажений, як ми і добивалися - у нас Організація завантажена в контрагента, а контрагент в організацію. Рахунки обліку все завантажені і встановлені. Номер документа у нас вийшов з нашим префіксом і на початок дня. Всі реквізити, які прописали, заповнені.

Перевіряємо завантаження номенклатури. Бачимо, що все вийшло так, як ми і планували.

У нас створилися і заповнилися реквізити так, як ми це задумували. У конвертації є безліч тонкощів і якихось простих, але потрібних речей, які допомагають точно написати конвертацію. А це дозволяє мінімізувати помилки, не зіпсувати існуючі дані і позбутися від зайвого сміття. Це один з найбільш простих прикладів. Можна так само робити конвертації одного об'єкта до багатьох або ж навпаки багато - в один.

Зараз є конвертація даних 3, вона вирішує інші завдання. Тому конвертація 2, так само потрібна. Всім удачі в вивченні та освоєнні.

Звичайно, якщо Ви програміст і це - основна ваша робота, Ви можете самі спробувати написати конвертацію. Але якщо немає, то варто цінувати Ваш час в своїй сфері діяльності, а це завдання попросити виконати професіоналів.

Міграція даних між різними конфігураціями - завдання не з тривіальних. Шляхів вирішення як завжди кілька, але не всі вони оптимальні. Спробуємо розібратися в нюансах перенесення даних і вибрати універсальну стратегію вирішення подібних питань.

Проблема міграції даних (мова суто про продукти компанії 1С) з одного рішення в інше виникла не вчора. Компанія «1С» прекрасно розуміє, з якими труднощами стикаються розробники під час створення міграцій, тому всіляко намагається допомагати інструментами.

За час розвитку платформи, компанія представила ряд універсальних інструментів, а також технологій, що спрощують перенесення даних. Вони вбудовані в усі типові рішення і проблема міграцій між ідентичними конфігураціями в цілому зважилася. Перемогу зайвий раз підтверджує тісна інтеграція типових рішень.

З міграціями між НЕ типовими рішеннями ситуація дещо складніша. Широкий вибір технологій дозволяє розробникам самостійно вибирати оптимальний з їх точки зору спосіб вирішення завдання.

Розглянемо деякі з них:

• обмін через текстові файли;
• використання планів обміну;
• і т.д.

У кожного з них свої плюси і мінуси. Якщо резюмувати, то головним мінусом буде - багатослівність. Самостійна реалізація алгоритмів міграції чревата істотними тимчасовими витратами, а також довгим процесом налагодження. Про подальший супровід подібних рішень навіть говорити не хочеться.

Складність, дорожнеча супроводу, підштовхнули компанію «1С» на створення універсального рішення. Технології, що дозволяє максимально спростити розробку і підтримку міграцій. У підсумку ідея реалізувалася у вигляді окремої конфігурації - «Конвертація даних».

Конвертація даних - типове рішення, самостійна конфігурація. Будь-який користувач, що володіє підпискою "ІТС: Проф" може абсолютно безкоштовно завантажити цей пакет з сайту підтримки користувачів або диска ІТС. установка виконується стандартним способом - як і всі інші типові рішення від 1С.

Тепер трохи про плюси рішення. Почнемо з самого головного - універсальність. Рішення не заточене на певні конфігурації / версії платформи. Однаково добре працює як з типовими конфігураціями, так і самописні. Розробники отримують в розпорядження універсальну технологію і стандартизований підхід до створення нових міграцій. Універсальність рішення дозволяє готувати міграції навіть для відмінних від «1С: Підприємство» платформ.

Другий жирний плюс - візуальні засоби. Прості міграції створюються без програмування. Так-так, без єдиної строчки коду! Тільки заради цього варто один раз витратити час на вивчення технології, а потім використовувати безцінні навички багаторазово.

Третім плюсів я б відзначив відсутність обмежень на дистрибуцію даних. Розробник сам вибирає спосіб доставки даних в конфігурацію приймач. З коробки є два варіанти: вивантаження в xml файл і пряме з'єднання з інформаційною базою (COM / OLE).

вивчаємо архітектуру

Ми вже знаємо, конвертація даних здатна творити чудеса, але поки не зовсім зрозуміло, в чому ж виражаються технічні плюси. Перше, що необхідно засвоїти - в основі будь-якої міграції даних (конвертації) лежать правила обміну. Правила обміну - звичайний xml файл з описом структури, в яку будуть розвантажуватися дані з ІБ. Сервісна обробка, що здійснює вивантаження / завантаження даних, аналізує правила обміну і на їх підставі виконує вивантаження. Під час завантаження відбувається зворотний процес.

Конфігурація "КД" - свого роду візуальний конструктор, за допомогою якого розробник створює правила обміну. Виконувати вивантаження даних вона не вміє. За це відповідають додаткові зовнішні сервісні обробки, що входять в дистрибутив КД. Їх кілька (XX в імені файлу - номер версії платформи):

• MDXXExp.epf - обробка дозволяє вивантажувати опис структури інформаційної бази в xml файл. Опис структури завантажується в КД для подальшого аналізу і створення правил обміну.
• V8ExchanXX.epf - здійснює вивантаження / завантаження даних з інформаційної бази відповідно до правил обміну. У більшості типових конфігурацій обробка присутня з коробки (див. Пункт меню "Сервіс"). Обробка універсальна і не прив'язується до якихось певних конфігурацій / правилам.

Добре, тепер на підставі всього вищесказаного, визначимо етапи розробки нової конвертації:

1. Визначення завдання. Необхідно чітко розуміти які дані потрібно переносити (з яких об'єктів конфігурації) і найголовніше куди переносити.
2. Підготовка опису структур конфігурацій (Джерела / Приймача) для подальшого завантаження в КД. Завдання вирішується сервісної обробкою MDXXExp.epf.
3. Завантаження підготовлених описів структур в ІБ.
4. Створення правил обміну за допомогою візуальних кошти КД.
5. Виконання вивантаження / завантаження по створеним правилами конвертації даних шляхом використання обробки V8ExchanXX.epf.
6. Налагодження правил обміну (при необхідності).

найпростіша конвертація

Для демонстрації нам буде потрібно дві розгорнуті конфігурації. Я вирішив зупинитися на варіанті: "Управління торгівлею" 10-й редакції і невеликим самопісний рішенням. Завдання полягатиме в перенесенні даних з типової конфігурації «УТ». Для стислості назвемо самопісний рішення "Приймач", а управління торгівлею "Джерелом". Вирішувати завдання почнемо з перенесення елементів довідника «Номенклатура».

Насамперед поглянемо на схему конвертації даних і перечитаємо список дій, які необхідно виконати. Потім запускаємо конфігурацію "Джерело" і відкриваємо в ній сервісну обробку MD82Exp.epf.

Інтерфейс обробки не блищить достатком налаштувань. Користувачеві лише потрібно вказати типи об'єктів метаданих, які не потраплять в опис структури. У більшості випадків ці настройки змінювати не доводиться, тому що особливого сенсу в вивантаження рухів по регістрах накопичення (як приклад) немає.

Рух правильніше формувати під час проведення документів в приймальнику. Всі рухи будуть зроблені документом самостійно після перенесення. Другий аргумент на захист налаштувань за замовчуванням - скорочення розміру файлу з вивантаженням.

Деякі документи (особливо в типових конфігураціях) формують руху по безлічі регістрів. Вивантаження всього цього господарства зробить результуючий XML файл надто великим. Це може ускладнити подальшу транспортування і завантаження в базу приймач. Чим більше файл з даними, тим більше буде потрібно оперативної пам'яті для його обробки. За своє практику мені довелося зіткнутися з непристойно великими файлами вивантаження. Такі файли геть відмовлялися розбиратися стандартними засобами.

Отже, залишаємо все настройки за замовчуванням і робимо вивантаження опису конфігурації в файл. Аналогічну процедуру повторюємо для другої бази.

Відкриваємо КД і в головному меню вибираємо "Довідники" -\u003e "Зміни". Довідник зберігає опису структур будь-яких змін, які допоможуть бути використані для створення конвертацій. Ми один раз завантажуємо опис конфігурації, а потім можемо використовувати її багаторазово для створення різних конвертацій.

У вікні довідника натиснемо кнопку " Додати"І у вікні виберемо файл з описом конфігурації. Відзначаємо прапорець "Завантажити в нову конфігурацію"І натискаємо на кнопку" Виконати завантаження ". аналогічні дії проробляємо з описом структури другий конфігурації.

Тепер все готово для створення правил обміну. У головному меню КД вибираємо "Довідники" -\u003e "Конвертації". Додаємо новий елемент. У вікні створення нової конвертації потрібно вказати: конфігурацію джерело (вибираємо УТ) і конфігурацію приймач (вибираємо «Приймач»). Далі відкриваємо вкладку "Додатково" і заповнюємо наступні поля:

• ім'я файлу правил обміну - під таким ім'ям будуть зберігатися створені правила обміну. Файл можна змінювати в будь-який час, але вигідніше поставити його зараз. В майбутньому це заощадить час. Правила для демонстраційного прикладу я назвав: «rules-ut-to-priemnik.xml».
• найменування - назва конвертації. Назва може бути абсолютно будь-яким, я обмежився "Демо. УТ в Приймач ".

Все, натискаємо "Ok". Відразу ж перед нами з'являється вікно з питанням створити всі правила автоматично. Згода на настільки привабливу пропозицію дасть майстру команду автоматично проаналізувати опис обраних конфігурацій і самостійно згенерувати правила обміну.

Відразу розставимо крапки над "і". Нічого серйозного майстер згенерувати не зможе. Однак, з рахунків цю можливість скидати не варто. Якщо необхідно налагодити обмін між ідентичними конфігураціями, то послуги майстра будуть вельми до речі. Для нашого прикладу краще ручний режим.

Розглянемо детальніше вікно "Налаштування правил обміну". Інтерфейс може здатися злегка заплутаним - велика кількість вкладок, напханих елементами управління. Насправді все не так складно, до цього шаленості починаєш звикати через кілька годин роботи з додатком.

На даному етапі нас цікавлять дві вкладки: "Правила конвертації об'єктів" і "Правила вивантаження даних". На першій ми повинні налаштовувати правила відповідності, тобто зіставляти об'єкти двох конфігурацій. На другий же, визначати можливі об'єкти, які будуть доступні користувачеві для вивантаження.

У другій половині вкладки "Правила конвертації об'єктів" розташована додаткова панель з двома вкладками: "Конвертація властивостей" і " Конвертація значень". Перша буде відбирати властивості (реквізити) вибраного об'єкту, а друга необхідна для роботи з зумовленими значеннями (наприклад, зумовлені елементи довідників або елементи перерахування).

Дуже добре, тепер створимо правила конвертації для довідників. Виконати цю дію можна двома варіантами: скористатися майстром синхронізації об'єктів (кнопка "") або додати відповідності для кожного об'єкта вручну.

Для економії місця скористаємося першим варіантом. У вікні майстра знімаємо прапорці з групи " документи"(Нас цікавлять тільки довідники) і розкриваємо групу" Довідники". Уважно прокрутити список і дивимося назви довідників, які можна зіставити.

У моєму випадку таких довідників три: Номенклатура, Організації і Склади. Є ще довідник Клієнти, що виконує ту ж саму смислове навантаження, що і " контрагенти"З конфігурації" УТ". Правда, майстер не зміг їх зіставити в силу відмінних імен.

Виправити цю недоробку ми можемо самостійно. Знаходимо в вікні « відповідності об'єктів»Довідник« клієнти», А в колонці« Джерело »вибираємо довідник« Контрагенти ». Потім встановлюємо прапорець в колонці «Тип» і натискаємо кнопку "Ok".

Майстер синхронізації об'єктів запропонує автоматично створити правила конвертації властивостей всіх обраних об'єктів. Зіставлення властивостей відбуватиметься по іменах і для нашої демонстрації цього буде цілком достатньо, погоджуємося. Наступним питанням буде пропозиція створення правил вивантаження. Погодимося і на нього.

Основа для правил обміну готова. Об'єкти для синхронізації вибрали ми, а правила для конвертації властивостей і правила вивантаження були створені автоматом. Збережемо правила обміну в файл, потім відкриємо ІБ "Джерело" (в моєму випадку це УТ) і в ній запустимо сервісну обробку V8Exchan82.epf.

Насамперед у вікні обробки вибираємо створені нами правила обміну. На питання завантаження правил відповідаємо позитивно. Обробка проаналізує правила обміну і побудує однойменне дерево об'єктів, доступних для вивантаження. Для цього дерева ми можемо встановлювати всілякі відбори або вузли обміну, по зміни яких потрібно вибирати дані. Ми хочемо вивантажити абсолютно всі дані, тому в установці фільтрів необхідність відсутня.

Після завершення процесу вивантаження даних в файл переходимо в ІБ " приймач". У ній також відкриваємо обробку V8Exchan82.epf, Тільки на цей раз переходимо на закладку "Завантаження даних". Вибираємо файл з даними і натискаємо кнопку "Завантажити". Все, дані успішно перенесені.

Завдання з реального світу

Перший демонстраційний приклад міг ввести в оману. Все виглядає досить простим і логічним. Насправді це не зовсім так. У реальній роботі виникають завдання, вирішити які одними візуальними засобами (без програмування) важко або зовсім неможливо.

Щоб не розчаруватися в технології, я приготував кілька реальних завдань. З ними обов'язково стикаєшся при роботі. Вони не виглядають настільки тривіальними і змушують подивитися на конвертацію даних під новим кутом. Уважно розгляньте представлені приклади, і сміливо використовуйте як сніпети при вирішенні реальних завдань.

Завдання №1. Заповнюємо відсутні реквізити

Припустимо, нам потрібно перенести з УТ довідник " контрагенти". У приймальнику для цього є схожий довідник "Клієнти". Він повністю підходить для зберігання даних, але в ньому є реквізит " організація", Що дозволяє розділяти контрагентів за належністю до організації. За замовчуванням всі контрагенти повинні ставитися до поточної організації (її можна отримати з однойменної константи).

Рішень у задачі кілька. Ми розглянемо варіант заповнення реквізиту " організація"Прямо в базі" приймач", Тобто в момент завантаження даних. Поточна організація зберігається в константі, отже, немає ніяких перешкод в отриманні цього значення. Відкриємо правило конвертації об'єкта (далі ПКО) " клієнти"(Подвійний клік по об'єкту) і в майстра настройки правил перейдемо до розділу" Обробники подій ". У списку обробників знайдемо " після завантаження”.

Наведемо код отримання поточної організації з подальшим присвоєнням реквізиту. На момент спрацьовування обробника "Після завантаження", об'єкт буде повністю сформований, але ще не записаний в БД. Ніхто не забороняє нам його змінювати на свій розсуд:

Якщо НЕ Об'ект.ЕтоГруппа Тоді Об'ект.Організація \u003d Константи.ТекущаяОрганізація.Получіть (); КонецЕсли;

Перед заповненням реквізиту « організація»Обов'язково необхідно перевірити значення реквізиту« Це група». Для довідника « клієнти»Встановлена \u200b\u200bознака ієрархічності, тому перевірка на групу необхідна. Подібним чином виконується заповнення будь-яких реквізитів. Обов'язково прочитайте довідку за іншими параметрами обробника « ПослеЗагрузкі». Наприклад, серед них є параметр « відмова». Якщо йому привласнити значення «Істина», то об'єкт в базу записаний не буде. Таким чином, з'являється можливість обмежувати об'єкти для запису в момент завантаження.

Завдання №2. Реквізити в регістр відомостей

У довіднику " контрагенти"Конфігурації УТ, є реквізити" покупець"І" Постачальник". Обидва реквізиту мають тип " булево"І служать для визначення типу контрагента. У ІБ " приймач", У довідника" клієнти"Аналогічних реквізитів немає, але є регістр відомостей" ВідиКліентов". Він виконує аналогічну функцію і може зберігати для одного клієнта кілька ознак. Наше завдання полягає в перенесенні значень реквізитів в окремі записи регістру відомостей.

Одними візуальними засобами тут, на жаль, теж не впоратися. Почнемо з малого, створимо нове ПКО для регістра відомостей " ВідиКліентов". Як джерело нічого не вказуйте. Від автоматичного створення правил вивантаження відмовтеся.

Наступним кроком сформуємо правила вивантаження. Переходимо на відповідну вкладку і натискаємо кнопку " Додати". У вікні додавання правил вивантаження заповнюємо:

• Спосіб вибірки. Міняємо на "Довільний алгоритм";
• Правило конвертації. Вибираємо регістр відомостей "ВідиКліентов";
• Код (ім'я) правила. Записуємо як "ВигрузкаВідовКліентов";

Тепер необхідно написати код для відбору даних для вивантаження. Тут нам допоможе параметр " ВиборкаДанних". У нього ми можемо помістити колекцію з підготовленим набором даних. параметр " ВиборкаДанних"Може набувати різних значень - результат запиту, вибірка, колекції значень і т.д. Ми його инициализируем у вигляді таблиці значень з двома колонками: клієнт і тип клієнта.

Нижче наведено код обробника подій " перед обробкою". У ньому виконується ініціалізація параметра " ВиборкаДанних"З подальшим заповненням даними з довідника" контрагенти". Тут варто звернути увагу на заповнення колонки " ТіпКліента". В "УТ" у нас ознаки мають тип "Булево", а в одержувача перерахування.

На даному етапі ми їх не можемо привести до потрібного типу (його ж немає в УТ), тому поки залишимо в вигляді рядків. Цього можна і не робити, але мені відразу хочеться показати, як приводити до відсутнього типу в джерелі.

ВиборкаДанних \u003d Новий ТабліцаЗначеній (); ВиборкаДанних.Колонкі.Добавіть ( "Клієнт"); ВиборкаДанних.Колонкі.Добавіть ( "ТіпКліента"); ВиборкаДаннихІзСправочніка \u003d Справочнікі.Контрагенти.Вибрать (); Поки ВиборкаДаннихІзСправочніка.Следующій () Цикл Якщо ВиборкаДаннихІзСправочніка.ЕтоГруппа Тоді Продовжити; КонецЕсли; Якщо ВиборкаДаннихІзСправочніка.Покупатель Тоді НоваяСтрока \u003d ВиборкаДанних.Добавіть (); НоваяСтрока.Кліент \u003d ВиборкаДаннихІзСправочніка.Ссилка; НоваяСтрока.ТіпКліента \u003d "Покупець"; КонецЕсли; Якщо ВиборкаДаннихІзСправочніка.Поставщік Тоді НоваяСтрока \u003d ВиборкаДанних.Добавіть (); НоваяСтрока.Кліент \u003d ВиборкаДаннихІзСправочніка.Ссилка; НоваяСтрока.ТіпКліента \u003d "Постачальник"; КонецЕсли; КонецЦікла;

Збережемо правило вивантаження даних і повернемося на вкладку " Правила конвертації об'єктів". Додамо для регістра відомостей " ВідиКліентов"Правила конвертації властивостей: клієнт і тип клієнта. Джерело залишимо порожнім, а в обробнику подій "Перед вивантаженням" пишемо:

// Для властивості "Клієнт" Значення \u003d Істочнік.Кліент; // Для властивості "ТіпКліента" Якщо Істочнік.Кліент \u003d "Покупець" Тоді Вираз \u003d "Перечісленія.ТіпиКліентов.Покупатель" ІначеЕслі Істочнік.Кліент \u003d "Постачальник" Тоді Вираз \u003d "Перечісленія.ТіпиКліентов.Поставщік"; КонецЕсли;

У лістингу виконується заповнення реквізитів на основі виробленої вибірки даних. Клієнта ми передаємо просто у вигляді посилання, а тип клієнта записуємо в параметр « вираз». Дані цього параметра будуть інтерпретовані в приймальнику, і при виконанні реквізит буде заповненим коректним значенням з перерахування.

Все, правила обміну готові Розглянутий приклад вийшов досить універсальним. Подібний підхід часто застосовується при перенесенні даних з конфігурацій, створених на платформі 7.7. Яскравий тому приклад - перенесення періодичних реквізитів.

Завдання №3. Трюки з табличними частинами

Нерідко трапляються завдання, що вимагають рознесення рядків однієї табличній частині в кілька. Наприклад, у вихідній конфігурації послуги і товари оформляються в одній табличній частині, а приймачі зберігання цих сутностей розділене. Візуальними засобами завдання знову ж таки не вирішити. Тут за основу зручно брати рішення другого завдання.

Робимо правило вивантаження даних, вказуємо довільний алгоритм і в обробнику "Перед вивантаженням" пишемо запит для отримання даних з табличній частині.

Для економії місця я не стану наводити код (ви завжди можете звернутися до ісходникам) запиту - нічого незвичайного в ньому немає. Отриману вибірку перебираємо, і відсортовані результати розміщуємо в уже знайомий параметр " ВиборкаДанних". Як колекції знову ж зручно використовувати таблицю значень:

ВиборкаДанних \u003d Новий ТабліцаЗначеній (); // Тут буде ще одна таблична частина ВиборкаДанних.Колонкі.Добавіть ( "Товари"); // Тут теж буде таблична частина ВиборкаДанних.Колонкі.Добавіть ( "Послуги"); ВиборкаДанниз.Колонкі.Добавіть ( "Посилання");

Завдання №4. Перенесення даних в операцію

Якщо в організації використовується кілька облікових систем, то рано чи пізно виникне необхідність в міграції даних з подальшим формуванням проводок.

В конфігурації " БП"Є універсальний документ" операція"І він ідеально підходить для формування більшої кількості проводок. Ось тільки одна не завдання - документ зроблений хитро, і так просто дані в нього не перенести.

Приклад подібної конвертації ви знайдете в исходниках до статті. Обсяг коду вийшов досить великим, тому немає нікого сенсу його публікувати до статті. Скажу лише, що вивантаження знову ж використовує довільний алгоритм в правилах вивантаження даних.

Завдання №5. Синхронізація даних за кількома реквізитами

Ми вже розглянули кілька прикладів, але до сих пір не поговорили про синхронізацію об'єктів під час перенесення. От уявімо, що нам потрібно перенести контрагентів і частина з них напевно є в базі приймачі. Як перенести дані і не допустити появи дублів? На цей рахунок КД пропонує кілька способів синхронізації переносяться об'єктів.

Перший з них - за унікальним ідентифікатором. Багато об'єктів мають унікальний ідентифікатор, який гарантує унікальність в межах таблиці. Наприклад, в довіднику " контрагенти"Не може бути двох елементів з однаковими ідентифікаторами. КД робить на це розрахунок і для всіх створювані ПКО відразу за замовчуванням включається пошук за ідентифікатором. Під час створення ПКО ви повинні були звернути увагу на зображення лупи біля імені об'єкта.

Синхронізувати за унікальним ідентифікатором - спосіб надійний, але доречний він далеко не завжди. При об'єднанні довідників " контрагенти"(З декількох різних систем) Він мало, чим допоможе.

У таких випадках правильніше синхронізувати об'єкти за кількома критеріями. Контрагентів правильніше шукати по ІПН, КПП, Найменуванню або розбивати пошук на кілька етапів.

Конвертація даних не обмежує розробника у визначенні критерієм пошуку. Розглянемо абстрактний приклад. Нехай нам потрібно синхронізувати довідники " контрагенти"З різних інформаційних баз. Підготуємо ПКО і в настройках правил конвертації об'єкта встановимо прапорець " Продовжити пошук полях пошуку, якщо за ідентифікатором об'єкт приймач не найден". Цією дією ми відразу визнач два критерії пошуку - за унікальним ідентифікатором і довільним полях.

Поля ми маємо право вибирати самі. Відзначивши ІПН, КПП, Найменування ми відразу зазначимо кілька критеріїв пошуку. Зручно? Цілком, але знову ж таки цього буває мало. А що їли ми захочемо змінювати критерії пошуку? Наприклад, спочатку шукаємо по зв'язці ІПН + КПП, а якщо нічого не знаходимо, то починаємо катувати щастя з найменуванням.

Подібний алгоритм реалізувати цілком під силу. У обробнику події " поля пошуку"Ми можемо вказати до 10 критеріїв пошуку і для кожного з них визначити свій склад полів пошуку:

Якщо НомерВаріантаПоіска \u003d 1 тоді СтрокаІменСвойствПоіска \u003d "ІПН, КПП"; ІначеЕслі НомерВаріантаПоіска \u003d 2 Тоді СтрокаІменСвойствПоіска \u003d "Найменування"; КонецЕсли;

Рішень завжди кілька

Будь-яке завдання має кілька рішень і перенесення даних між різними конфігураціями не виняток. Кожен розробник має право вибирати свій шлях вирішення, але якщо вам постійно доводиться розробляти складні міграції даних, то настійно рекомендую звернути увагу на конфігурацію "". Нехай спочатку доведеться інвестувати ресурси (час) в навчання, але вони з лишком окупляться на першому більш-менш серйозному проекті.

На мій погляд, компанія 1С незаслужено обходить тему застосування конвертації даних. За весь час існування технології, по ній вийшла всього одна книга: "1С: Підприємство 8. Конвертація даних: обмін між прикладними рішеннями". Книга досить стара (2008 г.), але ознайомитися з нею все ж бажано.

Знання платформ все ж необхідно

»- універсальний інструмент, але якщо ви плануєте застосовувати його для створення міграцій даних з конфігурацій, розроблених для платформи 1С: Підприємство 7.7, то вам доведеться витратити час на знайомство з вбудованим мовою. Синтаксис і ідеологія мови сильно відрізняється, тому доведеться витратити час на вивчення. В іншому принцип залишається тим же.

Завдання цього правила обміну перенести залишки по взаєморозрахунках з БП 2 в УТ11.

Поетапне створення правила обміну за допомогою конфігурації "Конвертація даних" (метадані повинні бути завантажені):

1) Створюємо правило вивантаження об'єкта для цього переходимо на закладку "Правила вивантаження даних", тиснемо додати. У вікні вибираємо об'єкт вибірки у нас це буде госпрозрахунковий регістр. Спосіб вибірки міняємо на довільний алгоритм.

2) Переходимо до написання самого коду тому в УТ немає госпрозрахункового регістра то ми повинні його перетворити. Спочатку нам потрібен запит який за нашими параметрами буде повертати залишки по взаєморозрахунках. У обробнику події "Перед обробкою" пишемо наступний запит:

ТекстЗапроса \u003d "ВИБРАТИ
| ХозрасчетнийОстаткі.Счет,
| ХозрасчетнийОстаткі.Субконто1 ЯК Субконто1,
| ЕСТЬNULL (СУМА (ХозрасчетнийОстаткі.СуммаОстатокДт), 0) ЯК СуммаОстатокДт,
| ЕСТЬNULL (СУМА (ХозрасчетнийОстаткі.СуммаОстатокКт), 0) ЯК СуммаОстатокКт,
| МАКСИМУМ (ХозрасчетнийОстаткі.Субконто2.Дата) ЯК ДатаРасчетногоДокумента,
| МАКСИМУМ (ХозрасчетнийОстаткі.Субконто2.Номер) ЯК НомерРасчетногоДокумента
| З
| РегістрБухгалтеріі.Хозрасчетний.Остаткі (& НаДату, Рахунок \u003d & рахунок,) ЯК ХозрасчетнийОстаткі
| ДЕ
<> & Група і
| ХозрасчетнийОстаткі.Субконто1.Родітель<> & группа1
| Згруповані за
| ХозрасчетнийОстаткі.Счет,
| ХозрасчетнийОстаткі.Субконто1,
| ХозрасчетнийОстаткі.Субконто2
| УПОРЯДОЧИТЬ ПО
| Субконто1
| АВТОУПОРЯДОЧІВАНІЕ ";

У моїй завдання стояли обмеження на групи контрагентів за якими вивантажуються взаєморозрахунки.

Визначаємо значення змінних які будуть використовуватися в подальшому.

НаДату \u003d дата ( "20130101");
ТД \u003d ТекущаяДата ();
група \u003d Справочнікі.Контрагенти.НайтіПоНаіменованію ( "Покупці");
группа1 \u003d Справочнікі.Контрагенти.НайтіПоНаіменованію ( "Повернення від ФІЗОСІБ");

Створюємо таблицю яку надалі будемо передавати в правило конвертації значень.

ТЗ \u003d Новий ТабліцаЗначеній ();
ТЗ.Колонкі.Добавіть ( "Контрагент");
ТЗ.Колонкі.Добавіть ( "Сума");
ТЗ.Колонкі.Добавіть ( "СуммаРЕГЛ");
ТЗ.Колонкі.Добавіть ( "РасчетнийДокумент");
ТЗ.Колонкі.Добавіть ( "ДатаРасчетногоДокумента");
ТЗ.Колонкі.Добавіть ( "НомерРасчетногоДокумента");
ТЗ.Колонкі.Добавіть ( "Партнер");
ТЗ.Колонкі.Добавіть ( "ВалютаВзаіморасчетов");
ТЗ.Колонкі.Добавіть ( "ДатаПлатежа");

Встановлюємо параметри, викликаємо запит, заповнюємо таблицю викликаємо правило конвертації.

запит \u003d новий запит (ТекстЗапроса);
запрос.УстановітьПараметр ( "група", група); запрос.УстановітьПараметр ( "группа1", группа1);
запрос.УстановітьПараметр ( "НаДату", НаДату);
запрос.УстановітьПараметр ( "Рахунок", ПланиСчетов.Хозрасчетний.РасчетиСПрочіміПоставщікаміІПодрядчікамі); // 76.05
Вибірка \u003d запрос.Виполніть (). Вибрати ();
ТЗ.очістіть ();
Поки Виборка.Следующій () Цикл
якщо Виборка.СуммаОстатокКТ \u003d 0 або Виборка.СуммаОстатокКТ \u003d "" тоді
продовжити;
КонецЕсли;
якщо Виборка.СуммаОстатокКТ< 0тогда
повідомити ( "" + Виборка.Субконто1 + "від'ємне значення" + Виборка.СуммаОстатокКТ);
КонецЕсли;
СтрокаТЗ \u003d ТЗ.Добавіть ();
СтрокаТЗ.Контрагент \u003d Виборка.Субконто1;
СтрокаТЗ.сумма \u003d Виборка.СуммаОстатокКТ; // Виборка.СуммаОстатокКт;
СтрокаТЗ.суммаРегл \u003d Виборка.СуммаОстатокКТ; // Виборка.СуммаОстатокКт;
СтрокаТЗ.ДатаРасчетногоДокумента \u003d Виборка.ДатаРасчетногоДокумента;
СтрокаТЗ.НомерРасчетногоДокумента \u003d Виборка.НомерРасчетногоДокумента;
СтрокаТЗ.ДатаПлатежа \u003d ТД;
КонецЦікла;
ІсходящіеДанние \u003d Новий Структура;
ІсходящіеДанние.Вставіть ( "Дата", ТекущаяДата ());
ІсходящіеДанние.Вставіть ( "РасчетиСПартнерамі", ТЗ);
ІсходящіеДанние.Вставіть ( "ТіпОпераціі", "ОстаткіЗадолженностіПередПоставщікамі");
ІсходящіеДанние.Вставіть ( "Коментар", "Сформовано за кредитом рахунка 76.05");
повідомити ( "76.05 КРЕДИТ початок");
ВигрузітьПоПравілу (, ІсходящіеДанние, "ВводОстатковПоВзаіморасчетам_7605Кредіт");

Аналогічно проробляємо ту ж операцію і для інших необхідних рахунків (їх опис як і готове правило є у вкладенні).

3) Переходимо до створення правил конвертації об'єктів, для цього відкриваємо закладку "Правила конвертації об'єктів". Додамо туди нове правило з ім'ям "ВводОстатковПоВзаіморасчетам_7605Кредіт", об'єкт джерело залишимо порожнім, об'єкт приймач встановимо документ "Введення залишків", на вкладці настройки приберемо прапор "Шукати об'єкт приймача по внутрішньому ідентифікатором об'єкта джерела".

У обробнику події "Перед завантаженням" напишемо наступний код:

ГенеріроватьНовийНомерІліКодЕсліНеУказан \u003d істина;

У обробнику події "Після завантаження" напишемо:

виконати (алгорітми.ПослеЗагрузкіВводаОстатков);

він виконає алгоритм з наступним змістом:

валюта \u003d Константи.ВалютаРегламентірованногоУчета.Получіть ();
об'ект.Ответственний \u003d ПараметриСеанса.ТекущійПользователь;
об'ект.організація \u003d параметри.порганізація;
для кожного стор з об'ект.расчетиспартнерамі цикл
Стр.РасчетнийДокумент \u003d Справочнікі.ДоговориКонтрагентов.пустаяссилка ();
Стр.ВалютаВзаіморасчетов \u003d валюта;
якщо ЗначеніеЗаполнено (стр.контрагент.партнер) тоді
стр.партнер \u003d стр.контрагент.партнер;
інакше
парт \u003d Справочнікі.Партнери.НайтіПоНаіменованію (стр.контрагент.Наіменованіе);
якщо парт<> Не визначено і парт<> Справочнікі.Партнери.пустаяссилка () тоді
стр.партнер \u003d парт;

об'ект2.Партнер \u003d парт;
об'ект2.Запісать ();
інакше
виконати (алгорітми.ДобавітьПартнера);
КонецЕсли;

конецЕсли;

конеццікла;

Цей алгоритм буде виконаний на стороні приймача (БП). Крім перенесення залишків по взаєморозрахунках стоїть завдання перенесення контрагентів, але в УТ використовуються партнери тому після формування документа ми перевіряємо чи все контрагенти і партнери є в базі приймачі, якщо з якоїсь причини їх немає то ми їх додаємо.

Додавання контрагентів здійснить правило конвертації довідника "Контрагенти" його можна створити точно також як і попереднє правило, але дозволити системі самої зіставити необхідні поля.

Для партнерів був створений алгоритм який виконується на стороні приймача.

Для того щоб виконати алгоритм на стороні приймача, треба в правому верхньому кутку вікна алгоритму (при його редагуванні) проставити прапор "Використовується при завантаженні".

Нижче наведено код алгоритму "Додати партнера":

нПартнер \u003d Справочнікі.Партнери.СоздатьЕлемент ();
нПартнер.Наіменованіе \u003d стр.контрагент.наіменованіе;
нПартнер.Комментарій \u003d "Створено при завантаженні з БП";
нПартнер.НаіменованіеПолное \u003d стр.контрагент.НаіменованіеПолное;
нПартнер.Поставщік \u003d? (знайти (стр.контрагент.ДополнітельнаяІнформація, "Постачальник")\u003e 0, істина, брехня);
нПартнер.Кліент \u003d? (знайти (стр.контрагент.ДополнітельнаяІнформація, "Клієнт")\u003e 0, істина, брехня);
ПрочіеОтношенія \u003d? (Знайти (стр.контрагент.ДополнітельнаяІнформація, "Інше")\u003e 0, істина, брехня);
нпартнер.Запісать ();
стр.партнер \u003d нпартнер.ссилка;
контрагент \u003d Справочнікі.Контрагенти.НайтіПоНаіменованію (стр.контрагент.Наіменованіе);
об'ект2 \u003d контрагент.ПолучітьОб'ект ();
об'ект2.Партнер \u003d нпартнер.ссилка;
об'ект2.Запісать ();

Повертаємося назад до правила конвертації об'єкта. Тепер нам треба встановити відповідності полів джерела і приймача, це можна було зробити безпосередньо перед написанням коду. Для того щоб зіставити поля в нижній табличній частині є кнопка виклику майстра "Синхронізація властивостей". У цього майстра ми можемо або зіставити поля, або залишити як без джерела, так і без приймача. У нашому випадку все поля і ТЧ ми залишаємо без джерела.

Після того як необхідні поля були обрані в нижній ТЧ для кожного поля виставляємо прапор в колонці "Отримати з вхідних даних". Цей прапор говорить про те, що система буде шукати це поле у \u200b\u200bвхідних даних. Важливо щоб ім'я поля збігалося з ім'ям у вхідних даних, інакше буде виведено повідомлення про те, що поле, не знайдено.

Текстом описані не всі нюанси процесу.

В даний час головним болем у бухгалтерів став перехід з 1С: Підприємство 7.7 на 8.3 (аналогічно і 8.2). Бажано якомога швидше і без помилок. Якщо Ви програміст 1С: Бухгалтерія і Вам необхідно провести конвертацію даних документів з сьомої версії в восьму, то ця стаття для Вас.

Зробіть всього кілька кроків, і Ваші проблеми з перенесення даних будуть вирішені. дочитайте дану інструкцію до кінця, і Вам відкриється спосіб, як це зробити. Для початку Ви повинні підготувати робоче місце на Вашому комп'ютері для необхідних маніпуляцій. По-перше, Ваш жорсткий диск повинен бути обсягом не менше 100 ГБ. Це необхідно, тому що перенесення залишків є багаторівневим. І Вам буде потрібно працювати з декількома конфігураціями 7.7.

Якщо Вам потрібен швидкий і якісний перехід з 1С Бухгалтерія 7.7 на 1С 8.3, зверніться до нас! Середня вартість переходу «під ключ» у нас становить 6600 рублів.

Перенесення даних з 1С 7.7 в 1С 8.3 бухгалтерія 3.0

Отже, перш ніж працювати з перенесенням даних в версію 1С 8.3, Вам необхідно підготувати ці дані у версії 7.7. Для цього Ви повинні зробити наступне. Припустимо, у Вас на комп'ютері є робоча БД «Бухгалтерський облік для підприємства», з якою працюють Ваші бухгалтера. За допомогою обробки Export77 вивантажите всі необхідні документи в текстовий файл і з цього моменту більше не повертайтеся до основної робочої базі. Подальші Ваші маніпуляції будуть відбуватися з іншими конфігураціями.

Встановіть в новий каталог свіжий Реліз 1С: Підприємство 7.7. (В пакет входять стандартна порожня (без даних) і демоверсія). Ми будемо працювати зі стандартною версією. Тепер запускайте цю базу і за допомогою обробки Import 77 завантажте з текстового файлу дані з Вашої основної бази.

При конвертації даних можуть бути не проведені деякі документи. Це не страшно. Фішка в тому, що Ви легко це виправите після перенесення, так як в стандартній базі Ви працюєте з основним стандартним планом рахунків. Тому якими б навороченими були субрахунка, у Вашій робочій базі це легко виправити приблизно за 3 години, заходячи в кожен непроведений документ і змінюючи в полях рахунку ті рахунки, які у Вас є в Вашій конфігурації.

Природно, попередньо, перед перенесенням, Ви приводите план рахунків стандартної конфігурації у відповідність з планом рахунків Вашої основної робочої бази. Варіанти суто індивідуальні в залежності від специфіки роботи Вашої організації. Виконавши цю роботу, Ви отримуєте стандартну конфігурацію, Заповнену даними з Вашої робочої бази.

Тепер потрібно зробити ще один перенесення даних. Для цього виконайте установку стандартної нульової конфігурації ще раз в новий каталог. І вже туди переносите дані з стандартної з Вашими даними конфігураціі.В результаті у Вас вийде ідеальна база 7 версії, готова для перенесення в версію 8.2.

Справа в тому, що безпосередньо в восьму версію переносяться дані виключно з «недоторканою» стандартної версії 7.7. А у Вас якраз і є тепер така конфігурація. Але тепер вона не порожня, а саме з Вашими робочими даними.

Усе! Запускаємо 1С: Підприємство 8.2. Вибираємо «Перенесення даних з версії 7.7.» і насолоджуємося тим, як програма сама переносить дані з вашої обробленої 7.7., перепроводити документи і видає на екран порівняльну таблицю оборотно-сальдової відомості версій 7.7 та 8.3.

Звичайно, 100% результат не буде. Але на відсотків 70-80 Ви отримаєте відповідність. А далі Ваша робота буде проводитися тільки в версії 8.3.

Можливі неточності виправляються легко. Це ще години 3-4. Ви заходите в журнал документів і або коригуєте рахунку, або поля (наприклад «Договір» або «Основна каса»). Це залежить від ступеня відмінності Вашої бази 7.7. від стандартної. В результаті всіх цих дій Ваша робоча конфігурація версії 8.3 буде здатна видати бухгалтерські дані через оборотно-сальдову відомість в ідеальному вигляді.

Після переходу Вам буде корисно дізнатися, як працювати в нову програму. Для цього ми підготували розділ Навчання 1С Бухгалтерія 8.3.

До речі! Якщо Вам необхідна доробка програм 1С, Ви можете звернутися до нас!

Перенесення бази даних 1C 7.7 в 8.3, як зробити?

У багатьох типових (і деяких галузевих) восьмерочних рішеннях вже є або вбудовані засоби перенесення з 7.7 або у вигляді додаткових файлів в каталозі установки шаблону.

Якщо переносити самостійно, то на диску ІТС (а так само в багатьох місцях інтернету - гугл в допомогу) є обробка «Завантаження з табличного документа», Яка дозволяє завантажувати в довідники / документи / регістри довільні табличні дані. при досить високому рівні кваліфікації можна скористатися бойової артилерією - спеціальної конфігурацією «Конвертація даних 2» (не плутати з 3.).

Чи не підкажете чому виходить така помилка? У документації до 1С все занадто заплутано пишуть - зарплату адже треба отримувати, тому в їх рукописах взагалі не розібратися, війна і мир легше заходить ніж їх туторіали по експлуатації їх далеко не складної системи.

Максим Кравченко, ну так адже все написано російською мовою 🙂

З мого досвіду найпоширенішими причинами можуть бути наступні:

1) Вказано неправильний шлях в налаштуваннях обміну з 7.7 Тут або просто помилки або вказано шлях не до того каталогу. Або вказано локальний шлях на вашому комп'ютері, а обмін відбувається на стороні сервера 1С підприємства і цей сервер на вашу шляху природно нічого не бачить (поширена проблема).
2) На стороні комп'ютера, який намагається обмінятися з 7.7 (локальний або сервер) немає повноцінно встановленої платформи 7.7. Тобто відсутня зареєстрований COM-об'єкт, а до бази 7.7 традиційно підключалися за допомогою каталогу зі зламаної платформою, якій не потрібні ні ключ, ні будь-які дані системи.
3) Відсутні права доступу до каталогу з базою 7.7 (особливо актуально при роботі на сервері, де робочий процес rphost працює під службовим користувачем, а каталог бази 7.7 відкритий для конкретних людей).

Максим Кравченко, а почему не через IRC або чати на народовських «чортових казна»? 🙂
Ні, я вже повторно на одні й ті ж граблі наступати не буду. Уже одному невдячної дав свій скайп і той на шию сіл.

Якщо у вас є спільні питання, відповіді на які можуть допомогти іншим - задавайте. Разом зробимо добру справу. Ніяких таємних переговорів.

P.S. Що б у людей не пропадало бажання давати відповіді на цьому ресурсі, було б непогано відзначати рішення або натискати кнопку «подобається» на найбільш адекватних відповідей, навіть якщо вони прямо і не допомогли.

Максим Кравченко, FAQ неможливий так як чиста 7.7 \u200b\u200bне існує в природі. Є ціла палітра типових / галузевих рішень, є різні версії однієї і тієї ж конкретної конфігурації, але жодне з цього безлічі не покриває «з коробки» потреби компаній і всі продані 7.7 після установки роками допілівать. З урахуванням того, що масово продавати 7.7 перестали ще понад десять років тому, в конкретно вашої базі від типового функціоналу могло нічого не залишитися.

Одна справа, якщо ви берете стандартні механізми перенесення, про які я написав у своїй відповіді, і переносите розуміючи, що відповідальність за косяки на вас і всі нестиковки ви посадите виправляти «дівчаток». А зовсім інша залучати за гроші фахівця на роботу. Вам потрібно описати всі довідники для перенесення, обсяг інформації для перенесення (артикули, штрих-коди, ІПН та ін.), Від куди брати відсутню інформацію і так далі. Я зараз не готовий братися за ваш проект. Пропоную зареєструвати цю задачу на сайтах фрілансерів і провести між ними тендер.

Правила перенесення 1с 8

Перенесення даних з програм «1С: Бухгалтерія 8 ред.2.0» в «1С: Бухгалтерія 8 ред.3.0»

Призначений в першу чергу для доопрацьованих конфігурацій 1С: Бухгалтерія 8 ред.2.0 (Можливі назви в інтернеті БП 2.0 або БП 8.2) як основа для розробки оригінальних правил переносу в конфігурацію 1С: Бухгалтерія 8 ред.3.0 (Можливі назви в інтернеті БП 3.0 або БП 8.3), придатний зрозуміло і для перенесення даних між типовими конфігураціями.

У разі виникнення стратегіями переходу з редакції 2.0 на 3.0 можна ознайомитися тут.

перехід з 1С: Бухгалтерія 8 ред.2.0 на 1С: Бухгалтерія 8 ред.3.0 рекомендується виконувати на початку нового періоду (року, кварталу, місяця) після завершення регламентних операцій минулого періоду.

Перенесення даних проводиться за допомогою універсальної обробки, вивантажуються дані з інформаційної бази 1С: Бухгалтерія 8 ред.2.0 в файл у форматі XML. Отриманий файл завантажується в інформаційну базу 1С: Бухгалтерія 8 ред.3.0 за допомогою універсальної обробки завантаження даних.

Для перенесення даних необхідні наступні файли:

ACC20_30.xml - правила конвертації даних.

З інформаційної бази БП 2.0 в БП 3.0 переносяться:

інформація про поточні залишки на рахунках бухгалтерського обліку інформаційної бази «1С: Бухгалтерія 8 ред.2.0» на дату конвертації інформаційної бази

документи інформаційної бази БП 2.0 за обраний період

необхідна довідкова інформація з інформаційної бази «1С: Бухгалтерія 8 ред.2.0»

- дані з інформаційної бази 1С БП 8.2 вивантажуються в окремий файл (Файл даних);

- отриманий файл завантажується в інформаційну базу 1С БП 8.3.

Встановлення не потрібно, так як використовуються обробки, вбудовані в типові конфігурації, в 1С: Бухгалтерія 8 ред.2.0 і 1С: Бухгалтерія 8 ред.3.0.

(Про можливість використання спеціалізованої обробки читайте нижче)

В програмі 1С: Бухгалтерія 8 ред.2.0 потрібно відкрити обробку (меню: сервіс — Інші обміни даними), Вибрати папку, в якій знаходяться правила перенесення (див. Рис. 1) і завантажити правила обміну. Рекомендую кожен раз завантажувати правила обміну примусово, навіть якщо вони автоматично завантажуються при старті обробки. Для цього потрібно або перевибрать файл правил, або натиснути кнопку Перечитати правила обміну. Не потрібно включати всі правила перенесення. Слід використовувати тільки ті, які необхідні для перенесення залишків і (або) документів. Всі довідники переносяться по посиланнях, в міру необхідності, тобто тільки ті, які задіяні в залишках і документах. Це забезпечує відсутність «сміття» в новій інформаційній базі.

Якщо потрібно вивантажити залишки на кінець року, наприклад на кінець дня 31.12.2014, тобто правильніше говорити на початок 2015 року, то період вивантаження повинен бути 01.01.2015 - ХХ.ХХ.ХХХХ. Документи введення залишків в БП 3.0 будуть датовані 31.12.2014. З 01.01.2015 в БП 3.0 потрібно створювати документи, що відображають поточні операції. Якщо потрібні тільки залишки, то включати треба правила вивантаження даних з розділу вхідні залишки (Див. Рис.1). Правила вивантаження даних з розділу документи в цьому випадку слід відключити (див. рис.3). Період вивантаження наприклад 01.01.2015 - 31.01.2015 означає, що переноситься будуть документи січня 2015 року. Правила вивантаження даних з розділу документи в цьому випадку повинні бути включені.

Мал. 1. Обробка для вивантаження даних

В першу чергу рекомендуємо перенести облікову політику організації (довідник організації переноситься по посиланнях). Під час передавання даних можна додатково встановити параметри (див. Рис.2). Для повернення до значень за замовчуванням слід перезавантажити правила обміну.

Рис.2 Установка параметрів

параметр Не зважати на регістр партій ПДВ визначає насамперед буде заповняться в БП 3.0 при введенні залишків ТМЦ таблиця Дані за рахунками-фактурами отриманим. Також він впливає на те, як буде заповнюватися субконто партії: за даними БО або по залишкам регістра НДСПоПріобретеннимЦенностям.

Установка параметра дозволяє управляти вивантаженням залишків для організацій, що використовують ССО. При запущеному обліку, при не відповідно даних регістра Витрати при ССО регістру бухгалтерії можливо корисніше буде вивантажити залишки за даними тільки бухгалтерського обліку, без урахування регістру ССО, Який може додати масу помилок. В цьому випадку в документах введення початкових залишків в БП 3.0 реквізити Відображення в ССО і стан витрати заповнюються значеннями за замовчуванням.

При установці параметра в значення Так одночасно з документами будуть перенесені набори регістрів, пов'язані з даними документами. В іншому випадку переноситься вміст документів, а для отримання рухів документи слід провести в базі БП 3.0 після перенесення. Треба розуміти, що не для всіх рухів документів, існуючих в БП 8.3, Є відповідності в БП 8.2. Тому, навіть якщо вибрати варіант перенесення документів з рухами, для деяких видів документів може знадобитися проведення з метою створення всіх необхідних наборів регістрів.

Рис.3 Перелік документів, які переносяться в БП 3.0

Перелік довідників і регістрів відомостей до переносу представлений на рис.4. Якщо когось цікавить розширення це переліку, звертайтеся до автора. Правила перенесення об'єктів є для багатьох довідників. Воно й зрозуміло, адже самі різні довідники присутні в багатьох документах і відповідно вивантажуються по посиланнях. Зробити з них правила вивантаження не складає особливих труднощів, можете це робити і самостійно. Правило вивантаження довідника потрібно в тому випадку, якщо є бажання переносити довідник цілком, а не тільки по посиланнях.

Мал. 4 Перелік довідників і регістрів відомостей до переносу

Особливості перенесення залишків за рахунками 76.АВ і 76.ВА

При установці в значення Так параметра Виправляти пересортицу за розрахунками з контрагентами можна виправити допущені в обліку помилки. Що таке пересортиця ясно з Рис.5.1: по контрагенту сальдо дорівнює нулю, але за другим субконто суми не нульові. Такі залишки переноситися не будуть.

Рис.5.1 Пересортиця в залишках

Якщо встановити в значення Так параметр повідомлення детально, То при вивантаженні будуть виводиться пояснюють повідомлення (див. Рис.5.2).

Рис.5.2 Повідомлення при пересортиці в залишках

Особливості перенесення залишків за рахунками обліку ТМЦ

Аналогічно працює алгоритм виправлення помилок типу пересортиця в залишках по ТМЦ. Працює цей алгоритм при установці параметра Виправляти пересортицу по залишкам ТМЦ в значення Так. Приклад показаний на рис.5.3. Облік за рахунком 10.03 ведеться в розрізі номенклатури, складів і партій. Залишок по номенклатурі Бензин АІ-92 на складі №4 дорівнює нулю, але якщо розгорнути залишки по партіях, їх буде багато. Алгебраїчна сума залишків по партіях дорівнює нулю, це і є пересортиця. Такі залишки не варто переносити, тому що це явна помилка. Вони і не будуть переноситися при встановленому параметрі.

Рис.5.3 Пересортиця в залишках ТМЦ в базі джерелі БП 2.0

Гірше справи йдуть із залишками по складу №6. Залишок ненульовий, тому алгоритм виправлення пересортиці не спрацює, залишки переноситися будуть. А як будуть переноситися, давайте розглянемо. сума -155,29 в перенос не потрапить, тому що такий залишок в БП 3.0 ввести неможливо, не можна ввести нульове кількість і ненулевую суму, документ введення залишків не проводитиметься, тому не вивантажуємо. В результаті в БП 3.0 потраплять залишилися дві суми (див. рис.5.4). Залишок перенісся як би з помилкою. Насправді ніякої помилки перенесення тут звичайно немає, а є помилки обліку.

Рис.5.4 Результат перенесення в БП 3.0

Використовувати чи ні описаний алгоритм виправлення пересортиці, вирішувати користувачеві. Потрібно тільки пам'ятати, що залишки з нульовим кількістю не переносяться ніколи. На думку автора це найбільш правильна поведінка, принаймні це дозволяє провести документ введення залишків і почати звірку. для більш швидкого пошуку позицій розбіжності залишків між БП 2.0 і БП 3.0 за результатами перенесення, можна рекомендувати в джерелі відібрати такі проблемні позиції, налаштувавши відповідним чином оборотно-сальдову відомість. Як це зробити см. Рис.5.5.

Рис.5.5 Відбір позицій з нульовою кількістю

Після закінчення вивантаження необхідно запустити програму 1С: Бухгалтерія 8 ред.3.0. Завантаження як спочатку так і при повторних перенесення даних або додаткових перенесення слід виконувати за допомогою типової обробки Універсальний обмін даними в форматі XML (Див. Рис.8.1). Відкрити її можна через меню: Всі функції - Обробки - Універсальний обмін даними в форматі XML. Якщо в меню немає позиції всі функції, То потрібно зайти в сервіс -Параметри і встановити прапорець Відображати команду Всі функції.

Після завантаження даних в базу 1С: Бухгалтерія 8 ред.3.0 необхідно провести документи введення початкових залишків для отримання всіх необхідних рухів. Можна скористатися обробкою Групове перепроведення документів (Див. Рис.8.2) або провести документи в журналі (меню: Всі функції - Документи - Введення залишків). Якщо документи переносилися без рухів (параметр Вивантажувати руху документів встановлений в значення немає), То для отримання проводок і записів в регістрах необхідно провести і документи.

Методика конвертації даних.

Конвертація при необхідності може виконуватися в декілька етапів, наприклад, спочатку довідники, потім документи введення залишків, потім інші документи. Можливий повторне перенесення інформації. Між переносами не слід вносити виправлень в перенесені дані в 1С: Бухгалтерія 8 ред.3.0, Інакше ці виправлення можуть пропасти при повторних перенесення.

Залишки переносяться за допомогою документів Введення початкових залишків.

Детальніше з методикою введення залишків можна ознайомитися в статті на сайті ІТС фірми 1С.

важливо! Перед введенням початкових залишків повинні бути задані параметри облікової політики. Параметри облікової політики організації зчитуються на дату, наступну за датою введення залишків. Наприклад якщо дата введення залишків 31.12.2013 р, то враховуються параметри облікової політики, встановлені на дату 01.01.2014 р Це дозволяє враховувати параметри поточної облікової політики (наприклад: якщо в 2013 р організація застосовувала спрощену систему оподаткування, а з 2014 р . перейшла на загальну систему - то при введенні залишків на дату 31.12.2013 р враховуватимуться параметри облікової політики 2014 р). Саме тому, як зазначено вище, в першу чергу рекомендуємо перенести облікову політику організації.

важливо! Якщо Ви вирішили почати працювати в 1С: Бухгалтерія 8 ред.3.0 раніше, ніж перенесли туди залишки, то необхідно попередньо до початку роботи в 1С: Бухгалтерія 8 ред.3.0 перенести довідники. Інакше при перенесенні залишків в непорожню базу можливі помилки.

важливо: є можливість вирішення проблеми синхронізації при завантаженні в непорожню базу - зіставлення об'єктів.

Порядок роботи зі спеціалізованою обробкою перенесення даних.

Обробка використовується тільки в режимі файловий. обробку ПереносДанних_із_БП20_в_БП30.epf слід запустити в інформаційній базі, куди переносяться дані, тобто в 1С Бухгалтерія підприємства ред.3.0. У першому вікні (див. Рис.9) слід вказати варіант завантаження даних з інформаційної бази на платформі 1С: Підприємство:

Завантажити дані безпосередньо з інформаційної бази

Рис.9 Стартове вікно обробки перенесення даних

У наступному вікні (див. Рис.10) необхідно виконати настройку перенесення:

Вибрати інформаційну базу зі списку (список такої ж як при запуску програми 1с Підприємство).

Вказати ім'я і пароль користувача

Вказати яку інформацію слід перенести

Додатково можна виконати перевірку даних в джерелі на предмет коректності перенесення

При перенесенні довідників будуть перенесені дані з довідників обраної інформаційної бази, для яких є правила вивантаження. Довідники в цьому випадку переносяться цілком. Якщо прапорець не встановлений, але обраний будь-який інший варіант перенесення, то довідники також будуть перенесені, але тільки в тому обсязі, який необхідний для заповнення даних в перенесених проводках і документах. Під час передавання даних можна перенести довідники, документи і залишки на початок року. Варіанти перенесення можна вибирати в будь-якій комбінації. При перенесенні залишків будуть перенесені дані про залишки по рахунках обліку станом на 1 січня обраного року за правилами, зазначеним на рис.1. В 1С: Бухгалтерія 8 будуть створені документи «Введення початкових залишків» на 31 грудня року, що передує обраному.



Рис.10 Вікно параметрів переносу

Якщо обрана опція перевірки даних, то перед завантаженням така перевірка буде проведена і результат перевірки буде виведений на екран (див. Рис. 11). Якщо в процесі перевірки будуть виявлені помилки, то процес перенесення буде припинений, для того, щоб дати можливість виправити помилки. Якщо потрібно виконати вивантаження і завантаження даних незважаючи на помилки, зніміть галочку Перевірити дані перед завантаженням або натисніть продовжити. Список правил перевірок постійно поповнюється.



Рис.11 Результат перевірки даних перед завантаженням

В процесі виконання передачі даних з джерела в приймач на екрані буде оновлюватися картинка, яка відображає поточний етап: підключення до інформаційної бази, вивантаження даних, завантаження даних і т.д. Крім того, більш детальна інформація відображається нижче у вигляді рядка, наприклад, «Вивантаження даних: Документи (3/3)». Після закінчення завантаження даних запускається процес проведення завантажених документів і потім перевірка завантажених даних. Якщо в ході проведення документів або перевірки даних виникли помилки, то після закінчення у вікні повідомлень з'являться повідомлення про це. Повідомлення про помилки можна також переглянути в окремому вікні, натиснувши на гіперпосилання Інформація про помилки (См.Ріс.12).



Рис.12 Індикація процесу передачі даних

Фрагмент таблиці, яка містить записи про помилки, показаний на рис.13. Спочатку в таблиці відображаються повідомлення про помилки, що виникли при проведенні документів, потім помилки при перевірці. Перевірка завантажених даних полягає в зіставленні оборотно-сальдових відомостей, сформованих на дату введення залишків, в джерелі і приймальнику. Що стосується розбіжності сальдо по якомусь рахунку створюється запис про це. За подвійним клацанням на записи в таблиці помилок можна відкрити проблемний документ для виправлення і проведення вручну. Те ж саме можна зробити у вікні повідомлень.



Рис.13 Фрагмент таблиці, яка містить записи про помилки

Після внесення виправлень в базі-приймачі не має сенсу виконувати перенос тієї ж самої інформації з бази-джерела повторно, тому що при повторному перенесення ці дані знову запишуться з помилками. Тому намагайтеся вносити виправлення в джерелі, а не в приймальнику, або не повторювати передачу тієї ж інформації. Наприклад, після перенесення початкових залишків і виправлення всіх документів введення початкових залишків в приймальнику при подальших перенесення не встановлюйте прапор Залишки на початок року.

Оновлення безкоштовні протягом 6 місяців після покупки. Після закінчення періоду безкоштовних оновлень, Ви можете отримувати оновлення на платній основі (вартість див. Нижче). При цьому, якщо Ви придбали кілька програмних продуктів, В складі комплектів або окремо, то Ви маєте право розраховувати на знижку. Ви можете детальніше ознайомитися з системою знижок.

Правила створені за технологією конвертації даних: Легко редагуються.
Повністю відкриті, немає ліцензійних обмежень крім заборони на тиражування.

файл ПереносДемо20_30.xml є вивантаження з бази, отриманої перенесенням демонстраційної бази БП 2.0, поширюваної фірмою 1С, в базу БП 3.0. Створіть порожню базу БП 3.0.44.94, можна з шаблону 1С або з допомогою файлу конфігурації 1Cv8.cf. Встановіть в параметрах обліку в Налаштування плану рахунків облік запасів по складах і партіям. Завантажте файл демо-бази ПереносДемо20_30.xml за допомогою обробки Універсальний обмін даними в форматі XML. У демо-базі показаний перенесення залишків на 01.01.2009 і документів за період з 01.01.2009 по 31.12.2009.

Правила регулярно оновлюються під нові релізи, придатні для релізів БП 2.0.64.23 і пізніших. Не потрібно шукати і вибирати потрібний варіант правил перенесення, вони придатні для будь-якого релізу ДЖЕРЕЛА в зазначеному діапазоні. Якщо потрібні правила для більш ранніх релізів звертайтеся до автора. Реліз ПРИЙМАЧА повинен бути точно таким як в правилах.

29.08.2018 Виділена в окреме правило вивантаження залишків по розділу Кредити та позики (Рахунки 66, 67), раніше це було в складі Інші рахунки бухгалтерського обліку

20.08.2018 Оновлення до 2.0.66.59 і 3.0.64.48

03.06.2018 долучення перенесення документів Відображення зарплати в регламентованому обліку

18.05.2018 Оновлення до 2.0.66.54 і 3.0.61.37

23.02.2018 Оновлення до 2.0.66.48 і 3.0.58.41

18.01.2018 Оновлення до 2.0.66.46 і 3.0.57.17

22.12.2017 Оновлення до 2.0.66.42 і 3.0.56.22

03.11.2017 Оновлення до 2.0.66.37 і 3.0.53.38

26.09.2017 Оновлення до 2.0.66.37 і 3.0.52.35

14.06.2017 Оновлення до 2.0.66.29 і 3.0.50.18

05.05.2017 Оновлення до 2.0.66.25 і 3.0.49.27

04.04.2017 - додано створення рахунків-фактур отриманих, коли в БП 2.0 є тільки номер і дата. Потрібно встановити параметр Виконати конвертацію рахунків-фактур (Створювати нові, якщо в джерелі тільки номер і дата)

06.02.2017 Оновлення до БП 3.0.47.23

26.01.2017 долучення перенесення документів Відображення нарахування ПДВ і Відображення ПДВ до відрахування

11.01.2017 Оновлення до БП 2.0.66.8 і БП 3.0.46.16. Виключений перенесення регістра НДСпоОСіНМА. У більш ранніх версіях, там де він є в складі конфігурації, він переноситися не буде.

14.12.2016 Оновлення до БП 3.0.44.203

07.12.2016 долучення перенесення документів коригування боргу

01.12.2016 Додано параметр Не зважати на регістр Витрати при ССО, Який дозволяє управляти вивантаженням залишків для організацій, що використовують ССО

21.11.2016 Додана вивантаження довідника користувачі окремим правилом зі створенням в приймальнику користувачів ІБ (подробиці тут). Доданий перенесення залишків по РС працівники організацій (Кадрових даних). При перенесенні залишків по рахунках 76.АВ і 76.ВА можлива перевірка і виправлення пересортиці по другому субконто.

08.11.2016 Розширено перелік документів.

28.10.2016 долучення перенесення документів. Додана демонстрація перенесення, це результат перенесення демо-бази БП 2.0.

26.10.2016 Виправлено створення порожніх документів введення залишків при наявності залишків по рахунку 10.07

09.09.2016 Оновлення до БП 3.0.44.102

23.03.2016 Доопрацьовано перенесення даних по рахунках-фактурах отриманим (при перенесенні залишків ТМЦ)

11.01.2016 долучення перенесення контактної інформації фіз.осіб, громадянство, пасп.данние, відомості про інвалідність, статуси фіз.осіб. Додані правила перенесення банк.счетов і рахунків обліку номенклатури.

23.12.2015 Оновлення до БП 3.0.43.29. Доданий перенесення контактної інформації контрагентів і їх контактних осіб.

14.12.2015 Створено правила для БП 3.0.42

У комплект поставки входять: правила перенесення «ACC20_30» і обробка ПереносДанних_із_БП20_в_БП30. У разі якщо Ваша організація не має штатним програмістом для проведення робіт, ми готові запропонувати послуги свого фахівця (програміст підключиться до Вашого комп'ютера через інтернет, за допомогою спеціальної програми для віддаленої роботи і зробить потрібні роботи). Якщо є можливість надати робочу базу «1С: Бухгалтерія 8 ред.2.0», Можемо перенести дані самі і передати файл « 1С: Бухгалтерія 8 ред.3.0»З перенесеними залишками. Вартість даної послуги не входить в загальну вартість пакета.

важливо. Переносяться не всі документи (для сумісності зі старими релізами БП 2.0). Перед покупкою уважно ознайомтеся з переліком на рис.3.

Перенесення даних з програм «1С: Бухгалтерія 7.7» і «1С: ССО 7.7» в «1С: Бухгалтерія 8»

Кілька слів про те як проводиться перенесення даних з типової конфігурації « Бухгалтерський облік», Редакції 4.5 для 1С: Підприємства 7.7 \u200b\u200bабо конфігурації« »(далі по тексту Зміни-джерело) в типову конфігурацію« Бухгалтерія підприємства», Редакція 3.0 для 1С: Підприємство 8 (версія 3.0.52), далі по тексту іменується« Конфігурація-одержувач ».

ВАЖЛИВО! Перенесення даних можливий з конфігурації Бухгалтерський облік редакції 4.5 для 1С: Підприємства 7.7 \u200b\u200bверсій 7.70.569 і більш пізніх або з конфігурації « Спрощена система оподаткування, ред. 1.3»Версій 7.70.219 і вище.

Перехід з Зміни-джерело на Конфігурацію-одержувач рекомендується виконувати на початку нового періоду (року, кварталу, місяця) після завершення регламентних операцій минулого періоду.

Перенесення даних проводиться за допомогою спеціалізованої обробки, вивантажуються дані з інформаційної бази Зміни-джерела в файл у форматі XML. Отриманий файл завантажується в інформаційну базу Зміни-одержувача за допомогою універсальної обробки завантаження даних.

ACC_ACC8 .ert - зовнішня обробка вивантаження даних у зовнішній файл з конфігурації « Бухгалтерський облік, ред.4.5»;

USN_ACC8 .ert - зовнішня обробка вивантаження даних у зовнішній файл з конфігурації « Спрощена система оподаткування, ред. 1.3»;

ACC_ACC8 .xml - правила конвертації даних.

USN_ACC8 .xml - правила конвертації даних.

З інформаційної бази Зміни-джерело в Конфігурацію-одержувач переносяться:

- інформація про поточні залишки на рахунках бухгалтерського обліку інформаційної бази Зміни-джерело на дату конвертації інформаційної бази;

- поточні документи з датою більшою ніж дата конвертації інформаційної бази.

Конвертація виконується в два етапи:

- дані з інформаційної бази Зміни-джерело вивантажуються в окремий файл (файл даних);

- отриманий файл завантажується в інформаційну базу Конфігураціі- одержувача.

Для установки обробки перенесення даних слід скористатися програмою установки setup.exe. Після запуску програми (якщо кількість інформаційних баз 1С: Підприємство велике, то через деякий час) з'явиться діалогове вікно, в якому потрібно зазначити ті інформаційні бази, куди буде встановлена \u200b\u200bобробка перенесення даних. Вікно має вигляд, як на рис.1. Якщо кількість інформаційних баз більше семи, то для навігації використовуйте кнопки «вгору» і «вниз». Якщо вибрано кілька інформаційних баз, то в рядку «шлях» відбивається місцезнаходження тільки останньої обраної бази. Ця інформація носить допоміжний характер і використовується за бажанням для додаткового контролю з боку користувача за результатом роботи програми установки, не звертайте на неї особливої \u200b\u200bуваги, програма сама визначить, де встановлені вибрані Вами інформаційні бази.



Рис.1 Вікно вибору інформаційних баз при установці

Додатково можна вказати папку, в яку також буде встановлена \u200b\u200bобробка перенесення даних, для цього слід скористатися вікном вибору папки (натиснувши кнопку з трьома крапками). Повний шлях для обраної папки буде відображений в рядку вибору. Після натискання на кнопку «встановити» буде проведена установка необхідних файлів в обрані інформаційні бази і (або) в обрану папку. Після завершення можна натиснути кнопку «деталі» і побачити докладний протокол установки, які файли і в які папки були записані. В результаті в обраній папці повинна вийти приблизно така картина, см. Рис.2.



Рис.2 Файли, встановлені в обрану папку

В підкаталог ExtForms встановлюється обробка і правила переносу. Необхідно мати на увазі, що обробка вивантаження ACC_ACC8 .ert і правила вивантаження даних замінюють собою типову обробку і правила. Якщо Ви хочете зберегти типовий механізм переходу, встановлюйте нову обробку в окремий каталог, а не в інформаційну базу.

Детальніше процес установки описаний на прикладі установки звіту « Експрес-перевірка ведення обліку для конфігурації «1С: Бухгалтерський облік 7.7«.

В програмі " 1С: Бухгалтерський облік 7.7»Потрібно відкрити з додаткових можливостей обробку « Перехід на 1С: Бухгалтерію 8, ред. 3.0«, Вибрати папку, в якій знаходяться правила перенесення (див. Рис. 3) і завантажити правила обміну. Не потрібно включати всі правила перенесення. Слід використовувати тільки ті, які необхідні наприклад для перенесення залишків, або залишків і документів. Наприклад в групі довідники жодного правила можна не включати, тому що все довідники переносяться по посиланнях, в міру необхідності, тобто тільки ті, які задіяні або в залишках, або в документах. Це забезпечує відсутність «сміття» в новій інформаційній базі. Документи теж не треба включати всі. Наприклад, якщо якихось документів у Вашій базі немає, або Ви не хочете їх переносити, включати це правило не треба.



Рис.3. Обробка для вивантаження даних

Рекомендую ім'я файлу даних встановлювати «C: \\ v77_v8 \\ Exp77_80.xml», саме ця папка часто використовується за умовчанням в програмі « 1С: Бухгалтерія 8»При завантаженні даних з програм на платформі« 1С: Підприємство 7.7«. При необхідності встановіть параметри на сторінці « параметри«.

У процесі вивантаження даних з конфігурації « Бухгалтерський облік 7.7»Можуть зустрітися різні помилки. Правила перенесення, представлені тут, відрізняються від типових тим, що на етапі вивантаження даних виконують пошук типових помилок. Розглянемо ті з них, про які виводяться повідомлення.

Нульове кількість і ненульова сума ТМЦ. Ввести в Зміни-одержувачі залишок таким чином, щоб кількість матеріалу дорівнювало нулю, а вартісна оцінка матеріалу не дорівнювала нулю, неможливо, та й немає сенсу, тому що це помилка. Тому при перенесенні залишків такі позиції (з нульовим кількістю) будуть відсутні в документах введення залишків. Отже, якщо помилки не виправити до перенесення даних, то суми в джерелі і приймальнику даних при перенесенні залишків не збігатимуться, що викличе додаткові труднощі звірки. Тому в процесі вивантаження даних з конфігурації « Бухгалтерський облік 7.7»Виводяться повідомлення про зустрілися помилки (див. Рис.4). Додатково для пошуку помилок можна рекомендувати скористатися обробкою «Експрес-перевірка ведення обліку», а саме правилом «Відсутність ненульовий суми при нульовому кількості за матеріалами».



Рис.4.1 Повідомлення про зустрілися помилках

Ненульове сальдо по субконто другого (третього) рівня, В той час як сальдо на першому (другому) рівні дорівнює нулю. Це досить часто зустрічається ситуація помилкового ведення обліку. Типовий приклад показаний на рис.4.2. Виникає такий стан як результат «пересортиці» в аналітичному обліку. Наприклад, в документах руху грошових коштів договір вказано, а в документах оприбуткування ТМЦ договору немає, або навпаки, або договори є але різні. У всіх цих випадках існує нульове сальдо за договорами, при тому, що сальдо по контрагенту дорівнює нулю. Аналогічна картина може скластися в обліку матеріалів, номенклатури (коли включений сумовий облік по місцях зберігання): пересортиця між складами, особливо якщо склади - це матеріально-відповідальні особи.



Рис.4.2 Приклад помилок в обліку

Ясно, що це помилка, і ясно, що не має сенсу переносити такі залишки. Для того, щоб виключити перенесення такого роду залишків, існує параметр «Не вивантажувати залишки, якщо нульове сальдо на верхньому рівні». Якщо цей параметр встановлений в одиницю, то при вивантаженні будуть виводитися повідомлення, показані на рис. 4.3 (порівняйте з рис.4.2), а залишки за такими позиціями розвантажуватися не будуть. Можна використовувати різні комбінації цього параметра з правилами переносу різних залишків. Якщо переносити не всі залишки відразу, а за розділами обліку, то можна залишки з різних розділів обліку переносити з різним значенням параметра.



Рис.4.3. Повідомлення про помилки

Порожні значення договорів або чужі договори. Проблема схожа на описану вище, причина та ж - пересортиця в аналітичному обліку за договорами (див. Рис.4.4). Але сальдо по контрагенту не дорівнює нулю, тому описане вище правило перевірки не спрацює. Під час передавання даних виникне помилка при проведенні документа введення залишків, тому що порожнє значення договору не допустимо.



Рис.4.4 Звіт, що показує помилку

Для виключення таких помилок до перенесення, на етапі вивантаження даних видаються повідомлення про помилки (див. Рис.4.5). На цьому ж малюнку видно, що зустрілася і інша помилка: договір не відповідає контрагенту, тобто власник договору - інший контрагент. Такі помилки часто зустрічаються в доопрацьованих, тобто нетипових конфігураціях або в давно створених базах, коли ще в типових конфігураціях не було достатньо суворої перевірки на відповідність договорів при заповненні документів.



Рис.4.5 Повідомлення про помилки обліку

Перевірка на порожні значення договорів і чужі договори проводиться в тому випадку, якщо встановлений в одиницю параметр « Перевіряти договори на порожнє значення і відповідність контрагенту«. Додатково для пошуку помилок можна рекомендувати скористатися обробкою «Експрес-перевірка ведення обліку», а саме правилами «Відсутність незаповненою аналітики за договорами» і «Відповідність контрагентів і договорів«.

Є й інші перевірки на помилки, для уточнення зв'яжіться з нами (контакти внизу сторінки).

Покажемо як можна переносити дані частинами, а не цілком, на прикладі вивантаження документів окремого виду або навіть окремих екземплярів документів обраного виду. Помітимо тільки одне правило вивантаження даних « Платіжне доручення»(Див. Рис.5). Це дозволить вивантажити документи тільки виду « Платіжне доручення«. Якщо при таких параметрах натиснути на кнопку « вивантажити«, То вивантажені будуть всі документи виду« Платіжне доручення«, Що знаходяться в тимчасовому інтервалі з« дата початку»По« дата закінчення«. Натиснемо кнопку « встановити ПВД«, Після цього з'явиться напис« Відбір даних для Платіжне доручення«.



Рис.5 Як встановити правило вивантаження даних певного виду

Далі натиснемо кнопку «Додати умова», з'явиться можливість вибрати реквізит відбору (див. Рис.6.1), найчастіше це - « ТекущійДокумент«, Що дозволяє вибрати окремий документ зі списку документів даного виду. Можна, використовуючи інші реквізити відбору, отримати вибірку по групі документів, наприклад відібрати документи за датою. У всіх випадках, відбір документів проводиться всередині тимчасового інтервалу, заданого параметрами « дата початку»І« дата закінчення«.



Рис.6.1 Як вибрати окремий документ

Важливо! «1С»), Яка в деяких конфігураціях не дозволяє проводити відбір документів при вивантаженні за реквізитами відбору. Це пов'язано з тим, що в типові правила відбір документів проводиться запитом без вказівки періоду. Такі запити працюють не завжди.

Схожим чином можна вивантажувати довідники, які не цілком весь довідник, а виконавши відбір з якого-небудь реквізиту. Спочатку вибираємо потрібне правило вивантаження даних, потім послідовно натискаємо кнопки « встановити ПВД»І« Додати умова«. Для прикладу на рис.6.2 показано, як можна вивантажити тільки тих співробітників, з якими на момент переходу з програми « 1С: Спрощена система оподаткування, ред. 1.3»На« 1С: Бухгалтерія підприємства, редакція 3.0»(Або, як часто говорять користувачі, перехід з бухгалтерії 7.7 на 3.0) встановлені трудові відносини.



Рис.6.2 Як вибрати групу елементів довідника

Важливо! У пропонованих правилах переносу даних виправлена \u200b\u200bпомилка типових правил (від фірми «1С»), Яка призводить до неправильного відбору елементів довідника при вивантаженні з періодичним реквізитами довідника, тобто таким у яких на різні дати встановлюються різні значення. Це пов'язано з тим, що в типових правилах відбір елементів довідника проводиться запитом без вказівки періоду.

Відбір по періодичним реквізитами довідника проводиться на дату параметра « дата закінчення«.

Можна використовувати комбінацію правил вивантаження даних і відборів. Правила, для яких встановлені відбори, будуть позначені як "[ВІДБІР]«. Для того, щоб побачити або відредагувати відбір конкретного правила вивантаження даних, потрібно двічі клацнути мишею по цьому правилу в списку правил або, вибравши його, натиснути кнопку « встановити ПВД«.

Важливо! Якщо вивантаження об'єктів виходить порожній або неповної, потрібно перевірити чи не встановлений режим синхронізації з 1С: Бухгалтерією 8. Якщо це так, то розвантажуватися будуть тільки об'єкти, змінені після виконаного перенесення (Справочнік.ПараметриСінхронногоУчета зберігає параметр ПозіціяПоследнегоВигруженногоДокумента, який перевіряється під час вивантаження функцією ПроверітьНаВозможностьВигрузкі) . повноцінна робота в режимі синхронізації стає неможливою. Перевірка режиму синхронізації проводиться після завантаження правил обміну. Якщо режим встановлений буде сформовано вікно попередження (див. Рис.6.5) і буде запропоновано відключити режим синхронізації.



Мал. 6.5 Вікно попередження про режим синхронізації

Додаткові відмінності від типових правил

Виправлена \u200b\u200bпомилка перенесення ПТіУ зі старими видами надходження: якщо в документах ПоступленіеТоваровІУслуг вид надходження дорівнює 2 (застаріле значення) і немає рахунку-фактури постачальника, виникає помилкова конвертація цього документа в БП 3.0 в документ повернення від покупця.

Виправлена \u200b\u200bпомилка при перенесенні ручних операцій, що мають субконто Підрозділ, в версію БП ПРОФ. Така операція не записується в БП, виникає помилка: «Поле Підрозділ має бути порожнім». Це пов'язано з тим, що правила розраховані на роботу з версіями КОРП, проте в ПРОФ вимірювання ПодразделеніеДт і ПодразделеніеКт регістра бухгалтерії повинні бути порожніми.

Виправлена \u200b\u200bпомилка, що приводить до дублювання груп довідника договори і, як наслідок, до дублювання елементів цього довідника (тому що пошук при завантаженні проводиться з урахуванням одного з батьків). Проілюстровано це малюнком 6.6.



Рис.6.6 Результат перенесення довідника договори типовими правилами

Тут в колонці батько (Група довідника) з найменуванням 2015 присутні дві різні групи довідника з однаковим найменуванням (в джерелі група одна), тому і договори дублюються.

Виправлена \u200b\u200bпомилка перенесення банківських документів при переказі грошей з одного розрахункового рахунку на інший. В БП 3.0 в цьому випадку створюється документ Списання з розрахункового рахунку з видом операції Переклад на інший рахунок організації, який не проводиться через те, що не заповнений реквізит Рахунок отримувача. Крім того невірно заповнюються реквізити рахунок обліку і рахунок дебету. Це проявиться, якщо вони різні, наприклад 55 і 51, тоді їх потрібно поміняти місцями. Виправлена \u200b\u200bпомилка незаповнення реквізиту вид зобов'язання в документах по перерахуванню податків. Все перераховане вище відноситься до релізу 3.0.43.215.

переноситься реквізит Основний договір довідника контрагенти.

Змінено правило вивантаження довідника номенклатура, Тепер спосіб відбору даних - стандартна вибірка, що дозволяє виконувати відбори елементів довідника за реквізитами (у типових правилах ССО 7.7 - БП 3.0 це неможливо). При перенесенні довідника номенклатура, Переносяться і ціни номенклатури по посиланнях, тобто ціни тільки переносяться елементів номенклатури. Для включення такої можливості потрібно встановити в одиницю значення параметра Вивантажувати ціни при вивантаженні номенклатури.

Виправлена \u200b\u200bпомилка в типових правилах «ССО 7.7 - БП 3.0» при перенесенні залишків за розрахунками з контрагентами: вид договору завжди встановлювався в значення інше. Тепер - в залежності від виду залишку, по розділу обліку « РасчетиСПоставщікаміІПодрядчікамі»Вид договору \u003d« З постачальником«, По розділу обліку« РасчетиСПокупателяміІЗаказчікамі»Вид договору \u003d« З покупцем«, В інших випадках вид договору \u003d« інше«.

Виправлена \u200b\u200bпомилка в типових правилах «ССО 7.7 - БП 3.0» при перенесенні залишків за розрахунками з контрагентами: сума взаєморозрахунків записувалася в два реквізити документа введення початкових залишків сума і СуммаКт. Через це документ введення початкових залишків не проводився.

рахунокСПокупателем»(В типових правилах« інше«). Встановлюється значення реквізиту « статус оплати«, Це важливо для правильного вибору рахунки на оплату покупцеві в банківських платіжних документах в Зміни-одержувачі.

При перенесенні документів виду « Платіжне доручення»Вид договору встановлюється в значення« з постачальниками»(В типових правилах« інше«).

Виправлена \u200b\u200bпомилка в типових правилах «ССО 7.7 - БП 3.0» при перенесенні місць зберігання: не заповнюється реквізит « Тип складу«.

Доданий параметр « Обмін з контролюючими органами включений«: Якщо його значення дорівнює 1, то реквізит ВідОбменаСКонтролірующіміОрганамі елемента довідника « організації»Встановлюється в значення« ОбменВУніверсальномФормате«, Інакше в« ОбменОтключен»Як в типових правилах. Це важливо при повторних (регулярних) них, щоб не псувати настройку ЕДО.

Змінено правило пошуку завантажених елементів для довідника « контрагенти«: Спочатку пошук проводиться по ІПН і КПП (Якщо ці значення заповнені), потім тільки по ІПН і нарешті по найменуванню. У всіх трьох випадках в пошуку бере участь ознака групи (ЕтоГруппа) і сама група (Батько). Це важливо при повторних (регулярних) них, щоб не створювати дублі для контрагентів з зміненими ПІСЛЯ завантаження найменуваннями.

При перенесенні контрагентів заповнюється реквізит СтранаРегістраціі значенням «Росія». Це необхідно для того, щоб після завантаження довідника контрагентів в програму «1С Бухгалтерія 8» не довелося вручну заповнювати обов'язковий реквізит СтранаРегістраціі. Якщо він не заповнений, то в формі елемента довідника « контрагенти»Будуть доступні реквізити« Податковий номер»І« Реєстр. номер«, А реквізити« ІПН»І« КПП»Будуть приховані.

В правила перенесення «ССО 7.7 - БП 3.0» додано правило вивантаження даних для перенесення довідника «Співробітники» (в типових правилах переноситься тільки довідник фізичних осіб).

{!LANG-f6fbadbe18cab18058567d2afb7bc7fd!}

{!LANG-295c8b8afb669dfec370eb6081e53d34!}

{!LANG-5ffcc90d73f67290dcc5978f6be84eb8!} {!LANG-2d7a34f52a1843a45fa6f6591b383b5b!}{!LANG-a66fa1af83e6840d906f7ac140be7ab3!} {!LANG-388036ef236b5be2f7939b6853af530f!} ({!LANG-85a0855579a7e5ea2fcfbd3af501490c!}{!LANG-2a86c332104b89f1062438fdbedd0d0e!} БП 3.0{!LANG-259b83c523ae896a649dd088fdbcbdb1!} БП 3.0{!LANG-f2de204f7e2b5f732f0ea596d533d7e7!} {!LANG-63cf28cfd16f028003a21936c2b9ab53!}{!LANG-e8bd5a7a9705323c4a2b59edf15eb571!} {!LANG-63cf28cfd16f028003a21936c2b9ab53!}{!LANG-505c9a6b1b07dde819a660b619d19f00!} {!LANG-3134db116d8fef0d369e53bde4e86217!}{!LANG-1b75a9157790ea69159ce89712669639!} {!LANG-63cf28cfd16f028003a21936c2b9ab53!}{!LANG-bac61ece5c067dd5e8d6981cd033eb86!}

{!LANG-c0acd6ccba93b8dd7d62245f3b999691!}

{!LANG-70610a0cd7aab7397e73513f83b76174!} Введення початкових залишків{!LANG-4868a89c4018eec40b26eaef7d7c3a95!} {!LANG-b136937b2ddec27549e13af1d378f8fd!}{!LANG-e1fdcb54b1dfabe605bd154af54866a4!}



{!LANG-5cba9f26ccd61942759e68deebfe2bdb!} Введення початкових залишків»

{!LANG-71ebbb7e7586adb7826b34ce49b25259!} Введення початкових залишків{!LANG-01a051984ab59c0b04ec20fda798bdf9!} Введення початкових залишків{!LANG-2a5994a3c2d6da3347cdf88143cf056d!}

{!LANG-abc31ba8e9986d3bc4af7239d0aa30ea!}{!LANG-71cf855eeceae9584efae5f3193f97c7!} Введення початкових залишків{!LANG-a6ce0fb610c6ac39e3d27d79a02d4d84!}

{!LANG-4cd180d45ebeb85984da116fc0fbce62!}

{!LANG-abc31ba8e9986d3bc4af7239d0aa30ea!}{!LANG-a3dddb409c4319e6a9acdc22fdb56f22!} Введення початкових залишків{!LANG-00aded3c499d86e7b6192242505fa99d!}

• {!LANG-6fae4c074d059f49bf4c2068622d90bd!}
• {!LANG-e069cb6dcf15368e95c00370bd356878!}
• {!LANG-85d72203b0784e8f8dcf5fe434c85224!}
• {!LANG-6e75b188522039767107a900546bbf27!}
• {!LANG-bdc0e95fc9d2ded24e5a3b8c804cf217!}
• {!LANG-f7620bded4a52b43bbdc1aef01d3cea1!} {!LANG-0f6c81e4227c1e8367494f546542d7ec!}{!LANG-f15f79682d417230898e7cf7dc5336a2!}