Багато підприємців, які здійснюють торговельну діяльність, для підвищення ефективності управління набувають одночасно дві програми «1С:Бухгалтерія 8» (Далі БП)та «1С:Управління торгівлею 8» (далі УТ).
БП використовується для ведення регламентованого обліку та здачі звітності, а УТ - для оперативного та управлінського обліку в компанії.
Успіх спільного використання цих програмних продуктівбагато в чому залежить від організації обміну даними між конфігураціями БП та УТ.
Розуміння наведених нижче особливостей типового обміну даними допоможе уникнути помилок у процесі обміну між конфігураціями та порушень обліку у кожній конфігурації окремо.
При написанні цієї статті використані матеріали з документації 1С до програмних продуктів. Спільне використанняконфігурацій Управління торгівлею (11) та Бухгалтерія підприємства», який знаходиться в каталозі шаблонів при встановленні як 1С: Бухгалтерії 2.0 (далі БП), так і 1С: Управління торгівлею 11 (далі УТ); рекомендації, отримані на партнерській конференції 1С та особистий досвід автора щодо створення та зміни налаштувань обміну для клієнтів компанії ТОВ «РГ-Софт Проект Консалтинг».
1. Налаштування одностороннього або двостороннього обміну.
Насамперед, слід враховувати, що з зміни БП у конфігурацію УТ можуть вивантажуватися лише документи, пов'язані з операціями руху готівкових і безготівкових коштів. До них відносяться: Прибутковий касовий ордер, Видатковий касовий ордер, Надходження на розрахунковий рахунок та Списання з розрахункового рахунку. Документи руху товарів, створені в БП, не вивантажуватимуться в УТ.
Фірма 1С рекомендує здійснювати обмін із банком в УТ. «Це забезпечить повноцінну роботу з вихідними платіжними документами та більш просту роботу з документами, що входять». Однак, була ситуація, коли з файлу клієнт-банку не вдалося завантажити в УТ практично жодної платіжки, тоді як у БП цей файл завантажився повністю.
Це пояснюється тим, що до УТ додано більш суворі перевірки змісту файлу клієнт-банку, наприклад: перевірка заповнення ІПН, перевірка номера документа, номер повинен містити лише цифри відповідно до положення ЦБР від 3 жовтня 2002 р. N2-П "Про безготівкові розрахунки" в Російській Федерації" (зі змінами від 3 березня 2003, 11 червня 2004, 2 травня 2007, 22 січня 2008).
Налаштовувати односторонній обмін (з УТ до БП) має сенс лише в тому випадку, якщо всі документи та нормативно- Довідкова інформаціязаповнюються в УТ. Таким чином, можна уникнути дублювання елементів у цій базі.
Для цього необхідно налаштувати наступний сценарій обміну: створити в конфігурації УТ сценарій обміну, в якому зберегти лише вивантаження (мал.1), у конфігурації БП створити сценарій обміну та зберегти лише завантаження.
Необхідно враховувати, що при такому сценарії обміну всі додаткові документи та довідники, створені в БП, будуть реєструватися для обміну, але не завантажуватимуться в УТ, тому реєстрацію рекомендується періодично скидати, інакше файл повідомлення обміну з БП постійно збільшуватиметься, уповільнюючи процес обміну .
Для цього рекомендується використовувати обробку РеєстраціяЗмінДляОбміну82.epf, яку можна знайти у поставці конфігурації "Конвертація даних, ред. 2.1". Після установки конфігурації обробка знаходиться в каталозі установки оновлення: ...\1c\Conversion\...номер_версії…
Якщо нормативно-довідкова інформація заповнюється і в УТ, і в БП, слід налаштовувати двосторонній обмін, але при цьому може знадобитися відстежувати дублі, запускаючи обмін в інтерактивному режимі замість автоматичного (рис. 2).
Для того, щоб обмежити обмін даними лише на рівні документів, не обов'язково налаштовувати односторонній обмін, достатньо у фільтрі обміну на стороні БП поставити дату більше дати останнього документа (див. рис. 5). Але перш ніж встановлювати фільтр на дату, потрібно переконатися, що документи в БП не були раніше зареєстровані для обміну, інакше зареєстровані документи будуть перенесені в іншу базу при обміні.
Пріоритет зміни даних
Якщо спочатку буде виконано обмін в УТ, а потім у БП, то пріоритет будуть мати дані, вивантажені з УТ. Наприклад, В УТ завели документ «Надходження на розрахунковий рахунок», запустили обмін спочатку в УТ, потім у БП – документ з'явився у конфігурації БП. Потім бухгалтер зміни БП вніс зміни до цього документа. При подальшому обміні, якщо черговість запуску обміну не змінювалася, то внесені до документа зміни затруться даними з УТ.
Для коректного обміну з тими об'єктами, які змінені в обох базах, 1С рекомендує організувати роботу, щоб об'єкт редагувався лише з однієї з баз. В іншій базі такий об'єкт повинен відкриватись лише на перегляд. І тому потрібно використовувати налаштування прав доступу користувачів, але такий підхід гарантує відсутність колізій під час обміну, тобто. розбіжностей, що виникають при зміні об'єкта і в одній, і в іншій базі, між обмінами (рис. 3).
2. Відмінності БП та УТ, що впливають на обмін
Договори контрагентів
У конфігурації УТ не ведеться аналітика за договорами контрагентів. Усі операції, що ведуться у конфігурації УТ, при завантаженні у конфігурацію БП завжди оформляються за окремими договорами, створюваним та контрольованим самою системою УТ.
Якщо договору з необхідними параметрами немає зміни БП, відбувається створення такого договора. Необхідно зазначити, що пошук договору здійснюється тільки з раніше завантажених з УТ договорів.
Управлінська організація в УТ
Починаючи з релізу 11.0.6.9, у ПТ у довіднику організації з'явився певний елемент «Управлінська організація». Цей елемент не повинен бути зіставлений (або змінений) з поточною (єдиною чи однією) організацією. Докладніше про використання цього об'єкта можна прочитати у файлі документації "Зміни та доповнення в документації.htm", що входить до постачання УТ.
Структура підприємства
В УТ для управлінського обліку використовується довідник "Структура підприємства", який містить перелік підрозділів компанії. При оформленні документів зазначення підрозділу підприємства є обов'язковим.
Елементи довідника «Структура підприємства» не порівнюються з елементами довідника «Підрозділи організації» в БП. Для того, щоб в УТ не завантажувалися документи із незаповненим реквізитом Підрозділ, у налаштуваннях обміну необхідно заповнити значення за замовчуванням (мал. 4).
Склад у табличній частині
Якщо в УТ планується використати нову можливістьвказівки складів у табличних частинах документів, то у налаштуваннях вузла плану обміну необхідно встановити узагальнюючий склад, який підставлятиметься при вивантаженні документів з ПТ у конфігурацію БП замість складів, дозволених для вибору у табличних частинах документів (рис. 4).
Вид номенклатури
При розвантаженні даних із БП в УТ, у номенклатурі не заповнюється реквізит «вид номенклатури», це пов'язано з тим, що обміном обслуговується сценарій, коли номенклатура створюється у конфігурації УТ, а чи не в БП. У документах руху товарів в УТ немає окремої табличної частини для обліку послуг (послуги заповнюються в таблиці товари), тому, для того, щоб послуги, зазначені в документах УТ, правильно переносилися в табличну частину в БП, потрібно:
1. У розділі нормативно-довідкова інформація відкрити довідник «Види номенклатури», зайти у вигляд номенклатури «послуги» – натиснути «Всі дії» – дозволити редагування та вибрати Тип номенклатури – Послуга.
2. Змінити номенклатуру (послугу) – натиснути «Всі дії» – дозволити редагування та вибрати цей Вид номенклатури з типом Послуга.
3. Налаштування фільтрів обміну (рис. 5)
Зміна дати вивантаження (завантаження) документів
1) Перш ніж пересувати дату вперед, необхідно синхронізувати бази шляхом виконання сеансу обміну, щоб на вузлі не було зареєстрованих до обміну документів на момент зміни налаштування. Інакше такі документи після зміни налаштування в результаті вивантаження можуть стати поміченими на видалення в базі-приймачі, якщо вони були раніше туди вивантажені.
2) Пересувати дату можна, т.к. це лише розширює область даних, що вивантажуються. Варто зауважити, що при цьому документи із раніше закритого періоду не будуть зареєстровані до обміну автоматично. Для того, щоб це зробити, необхідно або змінити документи, або скористатися обробкою РеєстраціяЗмінДляОбміну82.epf.
Фільтр по організаціям
Увімкнення цього фільтра дозволяє обмежити список організацій, за якими дозволено обмін даними. Наявність включеного фільтра впливає як на розвантаження самого довідника організацій, і на розвантаження інших даних, що з організаціями (довідники і документи).
Принцип дії фільтрів вивантаження такий: нові налаштування діють для всіх даних - у момент створення обміну, або тільки для тих даних, які були змінені після моменту застосування нових налаштувань - після створення обміну, тому рекомендується максимально відповідально підійти до налаштування фільтрів при створенні обміну даними .
Приклад:під час створення обміну користувач встановив фільтр з організації. У базу-приймач вивантажилися дані лише з зазначеної організації. Далі користувач вирішив, що в базу-приймач повинні вивантажуватись дані по всіх організаціях. Але оскільки налаштування починають діяти тільки для нових даних, то вже наявні документи і довідники не будуть вивантажені в базу-приймач до тих пір, поки користувач не зробить з ними будь-які зміни.
4. Видалення об'єктів однієї з баз
Позначка на видалення
Можлива ситуація, коли елемент довідника, що використовується раніше, не планується використовувати для подальшого обліку і цей довідник користувачі вважають правильним помітити на видалення. Позначені видалення об'єкти не беруть участь у обміні. Цю особливість слід враховувати.
Видалення дублів
Для видалення об'єктів, що виникли при обміні дублів, ми рекомендуємо скористатися обробкою ПошукІЗамінаЗначень.epf, яка знаходиться в каталозі \1CITS\EXE\ExtReps\Unireps82\SearchAndChange\ на диску ІТС. А для перевірки коректності зіставлення об'єктів двох інформаційних баз можна відкрити Регістр відомостей «Відповідність об'єктів інформаційних баз» та запису даного регіструможуть бути скориговані вручну. Важливо знати, що після видалення об'єкта в одній із баз у записі регістру відомостей залишиться відповідність для віддаленого об'єкта (бите посилання), потрібно буде або зіставити інший об'єкт, або видалити запис.
5. Додаткові налаштування
Статті руху грошових коштів
Для конфігурації УТ може знадобитися проставити реквізит «кор. рахунок» для тих статей руху коштів, які будуть використовуватися та вивантажуватись у БП.
Для зміни БП: може знадобитися проставити вид руху коштів у елементах довідника.
Користувачі
Елементи довідника користувачі можуть бути перенесені в іншу базу в тому випадку, якщо зазначені як відповідальні в одному з об'єктів, що беруть участь в обміні. Для таких об'єктів потрібно налаштувати права.
Префікс бази та префікс організації
В УТ префікс завжди має фіксовану довжину та роздільник (дефіс) "-". Тому, якщо префікс інформаційної бази не заданий чи префікс організації не заданий, він замінюється нулями. Однак при налаштуванні обміну префікс інформаційної бази завжди заповнюється ЦБ (для УТ) і на БП (відповідно для конфігурації БП).
Таке рішення є стандартом для формування номерів документів і кодів об'єктів. Префікс має фіксовану довжину та відокремлюється символом дефісу від номера документа. Якщо надалі в базі буде кілька організацій, достатньо буде встановити для них префікси і не потрібно виконувати перенумерацію всіх об'єктів.
Виправлення помилок
У статті були розглянуті найважливіші моменти організації обміну даними між «1С:Управління торгівлею 8» ред.11 і «1С:Бухгалтерія 8» ред.2.0.
Фахівці компанії ТОВ «РГ-Софт Проект Консалтинг» готові запропонувати не тільки налаштування обміну особливо ведення обліку конкретної організації, але й способи виправлення помилок у діючих обмінах.
У реальному житті рідкісна компанія обходиться однією базою 1С. Найчастіша ситуація – це дві бази, бухгалтерія та зарплата.
Бази мають бути пов'язані – нарахували зарплату, до бухгалтерії мають піти нараховані податки до сплати.
Для зв'язку кількох баз існує Обмін 1С. Як він працює?
Що таке Обмін 1С?
Є мережа магазинів та центральний офіс. У кожному магазині та в офісі є склад. Товари переміщуються зі складу склад (переважно з центрального склади магазинів), й у магазинах — продаються.
Використовується база 1С Роздріб в офісі та ця ж база у кожному магазині. Бази у магазинах – підпорядковані базі в офісі.
У офісі створюють документи про переміщення товарів зі складу складу, призначаються ціни. Документи заливаються до підлеглих баз і там «з'являються» товари.
У магазинах створюються документи про скоєні продажі товарів. Документи заливаються в офісну базу і там з'являються продажі.
Така схема називається – розподілена інформаційна база(Ріб). Процедури заливки документів - двосторонній обмін 1С. А налаштування цієї схеми – УРІБ чи УРІБД (управління розподіленими інформаційними базами даних).
Принципи Обмін довідниками в 1С
Довідники 1С (а набір усіх довідників «в комплексі» називають НСІ – нормативно-довідкова інформація) – у різних базах зазвичай мають бути єдині. Це означає, що навіть баз кілька, то список товарів, складів, контрагентів – єдиний у різних базах.
Нормальна практика, як у одній основі довідник можна редагувати, а інші він копіюється («мігрує»). Як ми раніше вже обговорювали – кожен елемент 1С має унікальний ідентифікатор – GUID . Довідники зазвичай копіюються разом зі своїм GUID і таким чином ідентичні у всій розподіленій інформаційній системі.
В іншому випадку, коли з'єднуються кілька існуючих баз, або коли довідники можна створювати в різних базах одночасно, їх GUID будуть різними. І тому існує механізм зіставлення. У спеціальний регістр відомостей при обміні 1С записується інформація, що з бази №1 з GUID ххх дорівнює елементу у цій базі з GUID yyy. Спочатку наявні елементи, які вже не рівні, потрібно порівняти автоматично (за іншими реквізитами, наприклад, за назвою або за ІПН та КПП) або вручну.
Принципи Обміну документами в 1С
Документи в 1С проводяться по регістрам і після цього вважаються проведеними. Це породжує зрозумілі складнощі під час перенесення.
Один варіант – перенести лише документи та провести їх заново після завантаження. Цей метод часто використовується, але може народжувати помилки - документ може і не провести в новій базі, так як умови при проведенні можуть скластися інакше, ніж були в момент проведення цього документа в початковій базі.
Інший варіант – перенесення документів та регістрів разом. Як ми розуміємо, відразу ж постає питання - чи ми переносимо всі документи взагалі і тоді весь регістр взагалі або змушені вибирати для перенесення тільки руху по документах, що переносяться.
Допустимо, нам потрібно перенести елемент довідника Номенклатури. Цей довідник має 10 полів, з яких 5 є рядками та числами, а 5 – посиланнями на інші довідники.
Відповідно при перенесенні одного елемента Номенклатури ми змушені шукати та переносити також 5 елементів інших довідників.
Таким чином, при перенесенні одного елемента довідника або одного документа, за посиланням може бути перенесено 100 і більше інших об'єктів 1С.
Фактично кажуть, що майже всі довідники конфігурації так чи інакше посилаються один на одного.
Плани обміну 1С
Припустимо, що ми створили розподілену базу даних та провели обмін 1С. На центральний склад закуплено товар та підготовлено для відправки до магазинів. У 1С офісі ввели потрібні документи переміщення товарів. Потрібно, щоб вони завантажилися до магазинів.
Що робити? Провести знову повний обмін 1С? Довго та неефективно! Набагато краще було б обчислити, що саме було додано або змінено користувачами в офіс, щоб у магазини потрапили тільки зміни.
І тому існує – плани обміну 1С. Програміст заздалегідь створює план обміну 1С щодо обмінів 1С з будь-якої іншої базою даних, наприклад з нашими магазинами.
План обміну 1С зазначає під час роботи користувачів з довідниками та документами, що було додано або змінено з моменту проведення останнього обміну 1С із цією базою.
Створення УРІБ 1С
Отже, ми створимо розподілену основу з нуля. Спочатку ми маємо «батьківську» базу офісу. З неї ми виділятимемо бази магазинів, які будуть їй підпорядковані.
У типових конфігураціях вже є типові плани обміну 1С. Види баз, котрим вони призначені – інтуїтивно зрозумілі з назви:
- Обмін 1С із сайтом: обмін із сайтом 1С:Бітрікс
- Обмін 1С УПП-УТ або УТ-Роздріб: типові обміни з конфігураціями-побратимами
- Повний - обмін 1С з базою даних на основі такої конфігурації.
РИБ – розподілена інформаційна база – можна створити зокрема з урахуванням плану обміну 1С «Повний». У конфігураторі у плані обміну 1С має стояти галочка «Розподілена інформаційна база».
План обміну 1С, створений конфігураторі, свідчить, що ми збираємося обмінюватися з такою конфігурацією. У режимі Підприємство в цьому ж плані обміну 1С тепер потрібно вказати конкретні бази даних на базі цієї конфігурації.
Зайдемо до плану обміну 1С (Операції/План обміну; також можуть бути в іншому меню, часто в меню Сервіс/ХХХ).
У списку баз даних у плані обміну 1С є одна із зеленим кружечком на картинці. Цей елемент позначає цю базу. Інші елементи позначають ІНШІ основи, з якими йде обмін 1С.
Необхідно, щоб було заповнено найменування і код у всіх елементів.
Щоб створити підлеглу базу магазину:
- Встановіть куховар у списку на елемент плану обміну 1С, який ми створили як «базу магазину»
- Виберіть пункт меню "Дії/Створити початковий образ".
В результаті буде створено одну базу з вивантаженими в неї початковими даними. Це потрібно повторити для кожного елемента плану обміну 1С, крім поточної бази.
Теорія проведення обмінів 1С
Теорія обміну 1С досить проста:
- Одна з баз (частіше база центру) ініціює обмін 1С за розкладом або за подією (вхід до бази певного користувача і т.п.)
- Обмін 1С полягає у вивантаженні з бази файлу
- Файл повинен бути переміщений у те місце, звідки його зможе забрати підпорядкована база (частіше кулі або ftp, рідше електронна пошта)
- Підпорядкована база завантажує отриманий файл
- Як підтвердження, що інформація отримана, підпорядкована база вивантажує "відповідний" файл, який таким же чином завантажується назад в центральну базу
- Сеанс обміну 1С завершено.
Існують інші методи обміну 1С, не через файли, а, наприклад, через пряме COM-з'єднання між двома базами. Його плюси:
- Не потрібне «місце для зберігання та передачі файлів»
- Не потрібно повторного завантаження підтвердження
- Все відбувається швидше за рахунок перших двох пунктів.
Однак обмеження зрозуміло - бази повинні бути в такій доступності один до одного, щоб ініціювати COM з'єднання.
Налаштування РИБ 1С
У константах типових конфігурацій(Операції/Константи; або Сервіс/Налаштування програми) — зазвичай є загальне налаштування обмінів 1С. Це – префікс у кодах елементів та номерах документів, щоб легко визначати, в якій базі він створений. А також внутрішній метод збереження інформації про місце створення довідників та документів.
Тепер необхідно налаштувати як відбуватиметься процес періодичного обміну 1С інформацією між створеними базами.
Усі налаштування РИБ в 1С знаходяться у типових конфігураціях зазвичай у меню Сервіс/Розподілені інформаційні бази/Налаштувати вузли РІБ.
Для кожного раніше створеного елемента "віддаленої бази магазину" необхідно додати елемент налаштування.
У налаштуванні вказується спосіб обміну 1С: файл (кулі), файл (FTP), файл (e-mail).
Створення та налаштування розподіленої інформаційної бази 1С у тонкому клієнті
Подивимося аналогічне настроювання у типовій конфігурації на базі тонкого клієнта – Управління торгівлею редакція 11.
Налаштування (та створення з нуля) знаходяться на закладці інтерфейсу Адміністрація. Пункт "Обмін даними".
Виберемо "Створити обмін у розподіленій інформаційній базі".
З самого початку 1С нам запропонує вказати, яким чином ми збираємося обмінитися з підлеглою базою інформацією. Ось варіант налаштування "через файл на кулі".
Ось варіант налаштування через файл на FTP.
Назва нашого налаштування обміну 1С.
І відразу ж пропозиція створити «початковий образ» — тобто саму підлеглу бази даних із вивантаженням у неї первинної інформації.
На відміну від конфігурації на товстому клієнті, обидві налаштування обміну 1С знаходяться в одному місці.
7
1. Створюєш зовнішню обробкуабо звіт у ній формі пишеш "ПланиОбміну.ВстановитиГоловнийВузол(Невизначено);" 2. Зберігаєш обробку. 3. Закриваєш конфігуратор 4. Запускаєш власний режим. 5. Запускаєш обробку. Ще Варіант до
7
Відновлення документів 1С з архіву в робочу базу (XML обмін) Нерідко потрібно відновити дані зіпсованого документа 1С з архіву бази після не умисних, а часто помилкових, дій удачливого користувача. Самим простим способомя
6
Автоматизація обміну між базами використовуючи обробку "Універсальний обмін даними у форматі XML" В основу даної публікації покладено знайдені мною матеріали щодо створення обміну між двома базами з використанням обробки
6
Інструкція створення одностороннього обміну даними між конфігураціями " Джерело" та " Приймач" з нуля: 1 Завантажуємо останню версіюконфігурації " Конвертація даних " . Зараз на сайті ІТС перестали чомусь публікувати повні дистрибутиви.
У кожному плані є певний перелік елементів, інформацію про зміну яких може зберігати. Цей список називається "Склад плану обміну". Склад можна розширювати, але підтримка конфігурації знімається.
У «Макеті плану» зберігаються ті самі правила, на основі яких працює синхронізація. Ось саме цей пакет конвертації (Правила реєстрації, Правила Обміну, Правила Обміну Кореспондента) нам і необхідний для подальшого вивчення.
Розглянемо приклад синхронізації даних між конфігураціями «1С:Зарплата та управління персоналом 3» (ЗУП) та «1С:Бухгалтерія підприємства 3» (БП). Зазначимо відразу, у цьому нам доведеться зняти конфігурацію з підтримки. Це знадобиться за умовою.
Живий приклад потреби доопрацювання типових правил обміну
Наприклад, замовник звернувся до нас із такою проблемою: при синхронізації між ЗУП та БП немає можливості передати дані довідника «Реєстрації у податковому органі», які необхідні для заповнення документа «Відображення зарплати у бухобліку». Зараз таблична частина цього документа за приймача БП містить порожню «Реєстрацію…» і користувачам доводиться вручну створювати такі записи у довіднику. Погодьтеся, це незручно. Можемо доопрацювати цей момент. 
Вирішення проблеми: доопрацюємо пакет конвертації з плану обміну ОбмінЗарплата3Бухгалтерія3. Додамо до типових «Правил обміну 1С» нове «Правило конвертації об'єктів» (ПКО) для довідника «Реєстрації у податковому органі» та відповідно «Конвертацію властивостей» цього довідника (ПКС). Обов'язково доопрацюємо типові "Правила реєстрації об'єктів", т.к. виникла потреба зареєструвати зміни довідника на вузлі обміну. І переглянемо "Правила обміну 1С" бази кореспондента.
Де все це редагуватимемо? для написання та зміни правил нам знадобиться конфігурація «1С: Конвертація даних 2».
Доопрацювання типових правил конвертації з Плану обміну ЗУП – БП
Отже, доопрацювання правил обміну 1С почнемо з того, що в конфігураторі для плану обміну до складу додамо новий елемент- довідник Реєстрації В Податковому Органі. Дану зміну зробимо в обох конфігураціях «1С:Зарплата та управління підприємством 3» та «1С:Бухгалтерія підприємства 3».
Збережемо та оновимо конфігурації.
У режимі підприємства кожної бази вивантажимо опис структури метаданих з допомогою обробки MD83Exp.epf для платформи «1С:Підприємство 8.3». Обробку можна знайти в комплекті "1С: Конвертація даних".
На наступному етапі вивантажимо пакет конвертації із ЗУП та БП. Пакет повинен складатися з 3 файлів: Правила Реєстрації, Правила Обміну, Правила Обміну Кореспондента.
У рамках цієї статті не буде опису як налаштовується синхронізація даних, це можна прочитати на сайті компанії «Кодерлайн» у розділі «Статті експертів» або переглянути записи вебінарів. Зараз у базах вже налаштована ця опція. Тому переходимо в налаштування синхронізації (Адміністрування -> Синхронізація даних -> Налаштування синхронізації даних), натискаємо кнопку "Завантажити правила". Перед нами відкриється форма "Правил для синхронізації". За кнопкою "Ще" виберемо пункт "Зберегти правила у файл".
Ось такий пакет після вивантаження має у нас вийти.
Аналогічні дії здійснимо і для іншої інформаційної бази "1С: Бухгалтерія підприємства".
У результаті всі підготовчі роботи для редагування правил готові. У нас є:
Опис структури метаданих для завантаження в "1С: Конвертація даних 2" (для ЗУП та БП);
Пакет конвертації, який містить правила обміну 1С та правила реєстрації, необхідні для завантаження в «1С: Конвертація даних 2» (для ЗУП та БП).
Переходимо в "1С: Конвертація даних 2". Виконаємо такі дії по порядку для обох інформаційних баз:
Завантажуємо структури метаданих конфігурацій;
Створюємо конвертації та завантажуємо правила обміну даними 1С із пакетів конвертації (файл правил називається ExchangeRules);
Створюємо реєстрацію та завантажуємо правила реєстрації з пакетів конвертації (файл правил називається RegistrationRules).
Переходимо безпосередньо до нашого доопрацювання. До правил обміну 1С додаємо нове правило конвертації об'єктів (ПКО) – довідник «Реєстрації у податковому органі». Додаємо правило конвертації властивостей (ПКС) для цього довідника та правило вивантаження даних (ПВД). Такого роду доопрацювання необхідно виконати як правил з пакета ЗУП, так правил обміну з пакета БП. Вивантажуємо наші правила обміну у відповідні файли ExchangeRules.
Переходимо до правил реєстрації нового елемента. Додаємо довідник «Реєстрації у податковому органі». Вивантажуємо правила реєстрації у відповідний файл із пакета RegistrationRules. Цю дію також виконуємо для обох баз.
Допрацьовані правила обміну та правила реєстрації готові. Тепер у правила кореспондента (CorrespondentExchangeRules) із пакета ЗУП копіюємо вміст правил обміну (ExchangeRules) із пакета БП. У правила кореспондента (CorrespondentExchangeRules) із пакета БП копіюємо вміст правил обміну (ExchangeRules) із пакета ЗУП.
У результаті має вийти таке:
На цьому роботу в «1С: Конвертація даних 2» завершено. Допрацьовані пакети правил конвертації готові, залишилося завантажити їх назад до інформаційних баз та перевірити синхронізацію.
Архівуємо файли з пакетів в Архів ZIP і завантажуємо в ЗУП та БП свої пакети конвертації.
Все готово. Залишилось протестувати.
Згадаймо умови завдання. Необхідно було зареєструвати до вивантаження довідник «Реєстрації у податковому органі» та перевірити, як заповнюється ТЧ документа «Відображення зарплати у бухобліку» на боці «1С:Бухгалтерія підприємства 3».
У джерелі «1С:Зарплата та управління підприємством 3» реєструємо до вивантаження наш довідник. Виконуємо синхронізацію. Переходимо до бази приймач і теж виконуємо синхронізацію для отримання даних. Звернемо увагу, що тепер щодо обміну з'явився потрібний довідник для реєстрації змін.
Перевіряємо на стороні «1С:Бухгалтерія підприємства 3»:
Підведемо підсумок. Результат поставленого завдання виконано успішно. Ми доопрацювали план обміну ЗУП – БП, додавши новий елемент для реєстрації змін та дописали правила конвертації для синхронізації даних.
Технологія розподілених інформаційних баз (РІБ) дозволяє створити територіально розподілену систему на основі конфігурацій 1С Підприємство. Це дозволяє мати загальний інформаційний простір навіть із тими підрозділами, які мають надійного каналу зв'язку, поєднуючи високу автономність вузлів із можливістю оперативного обміну інформацією. У наших статтях ми розглянемо особливості та практичну реалізаціюцього механізму на платформі 8.2
Насамперед поставимо питання: чому саме автообмін? Сучасні технології, у поєднанні з недорогим та швидким інтернетом, дозволяють організувати віддалену роботубез будь-яких труднощів. Вибір методів як ніколи широкий: RDP, тонкий і веб-клієнти, об'єднання мереж за допомогою VPN - є над чим задуматися. Однак усі ці способи мають один істотний недолік – сильна залежність від якості каналу зв'язку.
Навіть за ідеальної роботимісцевого провайдера гарантувати 100% доступність каналу зв'язку неможливо. Проблеми у магістрального провайдера, відсутність електропостачання, фізичне ушкодженнялінії зв'язку та багато інших факторів роблять це завдання нерозв'язним. У той же час відсутність інформаційної бази на віддаленому складі або в роздрібному магазині призводить до відчутних збитків. Ну і нарешті не забуватимемо, що є місця (наприклад промзони на околиці міст) у які підвести якісний канал зв'язку дорого та/або проблематично.
Механізм РІБ дозволяє позбутися зазначених недоліків, кожен підрозділ має власний екземпляр інформаційної бази з якою можна працювати автономно навіть за повної відсутності зв'язку із зовнішнім світом. А невеликий обсяг інформації, що передається, дозволяє використовувати для обміну будь-який канал зв'язку, у тому числі мобільний інтернет.
РИБ на платформі 8.2 не є чимось принципово новим, являючи собою подальший розвиток УРІБ платформи 7.7, тільки тепер ця технологія стала доступнішою та простішою. На відміну від компоненти УРІБ, яку потрібно було придбати окремо, РІБ є невід'ємною частиною багатьох типових конфігурацій і працює повністю в режимі користувача, дозволяючи обійтися без Конфігуратора навіть на етапі налаштування.
На цьому місці час би було перейти до практичної частини, але доведеться зробити ще один відступ. Справа в тому, що перехід на платформу 8.2, який начебто вже відбувся, за фактом призвів до появи двох типів конфігурацій: на основі керованого додатка, "рідні" для платформи 8.2 та адаптовані з 8.1, продовжуючи використовувати застарілі технології та механізми. Оскільки істотна частина конфігурацій (Бухгалтерія підприємства, Зарплата та управління персоналом) є адаптованими або перехідними, то скидати їх з рахунків не можна, тому перша частина нашої статті буде присвячена цим конфігураціям (по суті платформі 8.1), тоді як у другій ми розберемо настроювання автообміну для конфігурацій на основі керованої програми (платформа 8.2).
Розглянемо практичне завдання: налаштувати автообмін через FTP конфігурації Бухгалтерія підприємства 2.0. Незважаючи на те, що РІБ дозволяє здійснювати обмін із використанням електронної поштиабо загальних файлових ресурсів, ми рекомендуємо використовувати саме FTP як найбільш простий і надійний спосібзв'язку. Як налаштувати власний FTP-сервер, ви можете прочитати в , або можна використовувати FTP сервіс будь-якого хостинг-провайдера.
Насамперед нам потрібно налаштувати вузли обміну. Для цього запустимо конфігурацію з правами адміністратора та виберемо Операції – Плани обміну.
У списку виберемо Повнийплан або По організації, якщо у основі ведеться облік з кількох фірмам і обмін необхідно виробляти лише однієї з них. У вікні вже існує один вузол - центральний, нам потрібно його відредагувати, вказавши код і назву.
Після чого створимо ще один вузол для філії, заповнивши його аналогічним чином (для додавання натисніть зелений кухоль з плюсом). Наступним кроком буде створення початкового образу для даного вузла, який є готовою інформаційною базою у файловому режимі. Для цього клацніть правою кнопкою миші на потрібному вузлі і в списку виберіть Створити початковий образ.
Тепер перейдемо Сервіс - Розподілена інформаційна база (РІБ) - Налаштувати вузли РІБ.
У вікні, натисніть кнопку Додатита настройте новий обмін, вказавши віддалений вузол, тип обміну (через FTP) та параметри підключення до сервера.
Закладка Автоматичний обміндозволяє налаштувати розклад обмінів, обмін за подіями (початок і завершення роботи тощо), дані настройки виконуються для користувача від імені якого буде здійснюватися обмін, тому переконайтеся в наявності в нього прав для обміну даними.
Не забудьте вказати префікс вузла для нумерації документів (інакше ви отримаєте різні документиз однаковими номерами) в Сервіс - Налаштування програми, тут же можна налаштувати деякі інші параметри обміну. На цій же закладці слід вибрати користувача для виконання завдань обміну, якщо ви не зробите розклад працювати не буде. Пам'ятайте, що обмін буде здійснюватись лише в тому випадку, якщо даний користувачвиконав вхід до програми.
На цьому налаштування центрального вузла закінчено, тепер потрібно зробити аналогічні установки для периферійного вузла, підключивши початковий образ як існуючу ІБ. Після цього можна приступати до обміну даними. Для контролю слід скористатися Монітором обміну даними, він дозволяє не тільки контролювати успішність проходження вивантаження/завантаження, але й показує колізії, що виникли, або відкладені рухи (якщо користувачеві виробляв обмін не вистачає прав для здійснення будь-яких дій в базі). Наявність даного інструментудозволяє швидко і ефективно вирішувати різноманітні проблеми, що виникають при автообміні.
На цьому налаштування обміну можна вважати закінченим і розпочинати роботу в розподіленому режимі. Окремо варто зупинитися на оновлення або внесення змін до конфігурації. Ці дії доступні лише на центральному вузлі, всі внесені зміни будуть автоматично поширені на периферійні вузли під час наступного обміну. Для автоматичного внесення змін потрібно, щоб периферійна база знаходилася в монопольному режимі, інакше потрібно буде запустити Конфігураторта виконати Оновлення конфігурації бази данихвручну.
