Общие функциональные возможности и приемы работы при обмене данными

Общие функциональные возможности и приемы работы при обмене данными

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

Начнем с того, что объясним, что такое выгрузка по ссылкам. Это когда вместе с объектом информационной базы (например документом) переносится и вся другая (как правило справочная) информация. В документе указана организация, контрагент, номенклатура и т.п., и чтобы создать такой документ в приемнике, там должны быть и перечисленные справочники. Это и есть перенос данных по ссылкам.

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

В частности, у контрагентов есть банковские счета. Если есть документы поступления или реализации, но нет оплаты, то по ссылкам ни один банковский счет в обмен не попадет, т.к. в этих документах не используется.

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

Аналогично работает параметр Выгружать одновременно с контрагентами их контактных лиц. Контактные лица и вовсе не могут попасть в приемник по ссылкам, поскольку практически нигде в документах не присутствуют.

Аналогично работает параметр Выгружать одновременно с контрагентами их договоры.

Описанные алгоритмы - это такой своего рода аналог конвертации объектов по ссылкам, когда прямой ссылки на объект в выгрузке нет, но формируется дополнительный список к выгрузке.

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

В любом случае, эти возможности включаются опционально. При возникновении каких либо проблем (нехватка памяти, долгая выгрузка-загрузка) или невостребованности всегда можно описанные возможности отключить.

Не все параметры, описанные здесь, присутствуют во всех правилах конвертации. Если параметра нет, значит описанная функциональность отсутствует.

Если есть параметр Выгружать свойства справочников, то можно перенести свойства (дополнительные реквизиты) для некоторых справочников. Список таких справочников указан на странице соответствующего проекта.

Если есть параметр Выгружать одновременно с физическими лицами их персональные данные, то можно перенести такие сведения, как документы физических лиц (паспортные данные), гражданство, сведения об инвалидности и т.п.

Если есть параметр Переносить штрихкоды при выгрузке номенклатуры, значит можно переносить их одновременно с номенклатурой. Как правило, для переноса штрихкодов есть отдельное ПВД, которое позволяет конвертировать все такие объекты.

Параметр Дата начала ввода документов (может называться Начало периода переноса документов) указывает, на какую дату введены остатки и соответственно с какой даты вводятся документы в приемнике. Не путайте с началом периода выгрузки. Документы могут выгружаться частями за разные периоды: январь, февраль и т.д., при этом дата начала ввода документов всегда должна соответствовать дате остатков (1 января как правило). Это нужно для того, чтобы не выгружать по ссылкам документы, предшествующие дате остатков. Если такие встречаются в документах периода выгрузки или в движениях, например в проводках, то они либо заменяются на документы расчетов с контрагентами (или первичные документы, в разных конфигурациях могут по-разному называться) либо, если это невозможно из-за структуры базы, выгружаются только как ссылки, т.е. в них заполнены только реквизиты, необходимые для поиска: номер, дата и организация. Не переносятся реквизиты шапки и табличные части документов и соответственно не переносятся по ссылкам справочники, такие как номенклатура например. Это позволяет сократить размер документов в информационной базе.

Как установить дату остатков. Если нужно выгрузить остатки на конец года, например на конец дня 31.12.2021, т.е. правильнее говорить на начало 2022 года, то период выгрузки должен быть 01.01.2022 - ХХ.ХХ.ХХХХ. Документы ввода остатков в базе-получателе будут датированы 31.12.2021. С 01.01.2022 в базе-получателе нужно создавать документы, отражающие текущие операции. Если нужны только остатки, то включать надо правила выгрузки данных из раздела Входящие остатки. Правила выгрузки данных из раздела Документы в этом случае следует отключить. Период выгрузки для документов указывается таким же образом, чтобы перенести документ за год укажите первое и последнее число года. Чтобы перенести документы за месяц, укажите первое и последнее числа этого месяца, например, для выгрузки документов за 2022 года, выставите даты: 01.01.2022 - 31.12.2022 Период выгрузки например 01.01.2022 - 31.01.2022 означает, что переноситься будут документы января 2022 года. Правила выгрузки данных из раздела Документы в этом случае должны быть включены.

Важно! В новых версиях правил дата остатков устанавливается в параметре, чтобы обеспечить независимость от периода выгрузки. Следите за обновлениями. Кроме того, это важно для совместимости правил конвертации с планами обмена, которые позволяют реализовать регулярный перенос данных и регистрацию изменений объектов информационной базы.

Поскольку продолжают задавать вопросы по переносу документов ввода остатков из источника, поясняем еще раз. Неважно каким образом возникли в источнике остатки на дату переноса. Допустим в источнике ввели остатки на 01.01.2022, т.е. документами с датой более ранней, например - 31.12.2021. Перенос остатков в приемник производим на ту же дату - 01.01.2022. Так вот, перенос самих документов ввода остатков из источника, какими бы они не были (это могут быть корректировки регистров например), не нужен. Получаем в источнике информацию по остаткам на 01.01.2022 и формируем в приемнике документы ввода начальных остатков с датой 31.12.2021. Все. Сами документы ввода остатков из источника ни при каких обстоятельствах не переносятся, не нужно это.

Есть ряд параметров типа Вести складской учет (Вести суммовой учет по складам и т.п.), которые позволяют изменить набор аналитики при переходе в другую информационную базу, как правило это касается остатков. Эти параметры устанавливаются при загрузке правил обмена в соответствии с настройками источника и как правило не требуются их корректировки. Но можно отказаться например от складского учета уже на этапе выгрузки, тогда в приемнике его не будет. Впрочем этого можно добиться и в приемнике путем соответствующих настроек, параметры выгрузки в этом случае не важны. Понятно, что если складского учета в источнике не было, то получить остатки в таком разрезе невозможно, какие параметры не устанавливайте. Т.е. такие настройки могут работать как бы в одну сторону, в сторону отказа.

В процессе загрузки, если при выгрузке был установлен параметр Синхронизировать настройки программы и параметров учета в значение Да, будет произведена настройка параметров учета в базе-приемнике. Если настройка в базе-приемнике не совпадает с настройкой в базе-источнике, то она будет скорректирована, о чем появятся записи в окне служебных сообщений (см. рис.1). Понятно, что в дальнейшем, при переносе остальной информации, уже нет необходимости в такой синхронизации.

Сообщения об изменениях в настройке параметров учета

Рис.1 Сообщения об изменениях в настройке параметров учета

Есть еще группа однотипных параметров вида Не учитывать регистр .... Используются они в тех случаях, когда содержание бухгалтерских регистров и специализированных регистров учета не совпадает и нет смысла учитывать их при выгрузке остатков, например НДС по приобретенным ценностям или остатков НДС по авансам. В этом случае будут учтены только остатки регистров бухгалтерии. Или такой параметр влияет на выгрузку остатков ТМЦ: например определяет будет или нет заполняться табличная часть ДанныеПоСФ документа ВводНачальныхОстатков. Если остатки при переносе искажены, нужно в первую очередь попробовать установить такие параметры. Более детальную информацию можно получить из правил конвертации или на странице конкретного продукта.

Еще одна группа параметров вида Исправлять пересортицу ... позволяет избавиться от ошибок, допущенных в учете. Пересортица - это когда остаток по первому (или второму) субконто равен нулю, а по второму (или третьему) есть остатки, в сумме дающие ноль. На практике встречается по несколько десятков тысяч таких остатков на одном счете. Представьте, сколько мусора будет в остатках или сколько времени нужно исправлять такие остатки вручную после переноса, если не воспользоваться описанной опцией. Рассмотрим на примере расчетов с контрагентами, аналогично работает алгоритм исправления остатков ТМЦ. На рис.2 показано, как выглядит такая пересортица в источнике: только по одному договору есть правильное сальдо, по остальным договорам сальдо - это результат ошибок в учете.

Рис.2

В приемнике в документе ввода остатков по данному контрагенту в этом случае только три строки по одному договору (см. рис.3).

Рис.3

При установке параметра Выгружать движения документов в значение Да одновременно с документами будут перенесены наборы регистров, связанные с данными документами. В противном случае переносится содержимое документов, а для получения движений документы следует провести в базе-приемнике после переноса. Надо понимать, что как правило не для всех движений документов, существующих в приемнике, есть соответствия в источнике. Поэтому, даже если выбрать вариант переноса документов с движениями, для некоторых видов документов может потребоваться проведение с целью создания всех необходимых наборов регистров.

Параметр Не выгружать остаток, если нулевое количество, используется, как следует из названия, для отказа от переноса нулевого количества ТМЦ (товаров, материалов и пр.) при ненулевой сумме. Такие остатки образуются в источнике как результат ошибок в учете: неполное списание суммы при полном списании ТМЦ (положительная сумма в остатке) или наоборот избыточное списание (отрицательная сумма). Повторить точно такой остаток в приемнике невозможно, нельзя провести документ ввода с нулевым количеством, но если пользователь хочет точно воспроизвести суммы, то имеет смысл такие остатки перенести, исправить, например, количество вручную после обмена, а затем уже в текущем рабочем периоде исправить ошибку. Поясним еще раз, как исправить эту ошибку в учете, которая приводит к проблемам при вводе остатков (не только при конвертации, а вообще при вводе остатков), каждый пользователь решает сам. Кто-то, возможно, захочет распределить недостающую сумму на другие позиции, кто-то создаст новую номенклатурную позицию, условно назовем ее Номенклатура для исправления остатков, и всю сумму отразить на ней. А кто-то захочет точно повторить остатки, введя нулевое количество и ненулевую сумму ручной операцией. Мы предоставляем пользователю выбор: переносить остатки с нулевым количеством и получить документы, которые не проводятся, но видно все остатки, или не переносить остатки с нулевым количеством и получить документы, которые проводятся, но присутствуют не все остатки.

Параметр Переносить остатки по аренде отдельно от ОС и Контрагентов (используется в различных правилах переноса в БП 3.0) установлен по умолчанию и означает, что остатки по учету аренды и лизинга формируются документом ввода остатков в разделе учета Аренда и лизинг. Если по каким-либо причинам (из-за ошибок в учете) результат вас не устраивает, можно изменить параметр. В этом случае остатки по арендованным основным средствам (счета 01.03, 02.03) будут переноситься в разделе Основные средства, а расчеты по аренде (счет 76.07) - в разделе Расчеты с разными дебиторами и кредиторами.

Параметр Использовать дополнительные субсчета ОС позволяет выгружать остатки по субсчетам 01, 02, 03, добавленным пользователем. Важно понимать, что такие же субсчета должны быть и в приемнике.

Есть ряд параметров, не требующих пояснений, например Переносить только проведенные документы и т.п.

Принципы синхронизации данных (описание параметра Продолжить поиск по реквизитам если по идентификатору не нашли)

В данном разделе будут описаны общие принципы. Понятно, что из любого правила есть исключения, поэтому изложенное ниже не следует понимать буквально и дословно применительно к любому варианту и любому участку процесса обмена данными.

Самым надежным вариантом переноса данных является конечно перенос в пустую чистую базу, причем однократный (например вариант перехода с ведения учета в Комплексной автоматизации на Бухгалтерию предприятия). Надо сразу пояснить, что значит однократный. Это значит что МЕЖДУ ПЕРЕНОСАМИ, данные не изменяются ни в источнике, ни в приемнике. Понятно, что при соблюдении этого условия можно многократно выгружать и загружать информацию (причем можно это делать частями), результат не изменится. Это будем считать однократным переносом, т.е. передачей неизменившейся информации. В таком варианте и вопрос синхронизации остро не стоит. Почему, станет ясно из дальнейших пояснений.

Другое дело, переносы в непустую базу. Здесь нужно различать многократные переносы, когда информация, с течением времени изменившаяся, передается в уже не пустую информационную базу, но созданную первоначально переносом (вариант совместного использования этих программ и регулярного обмена). И другой вариант, загрузка в базу, в которой уже велся учет, либо в которую уже загружали данные из другой базы (вариант слияния нескольких баз в одну).

Во всех этих случаях оптимальными будут различные стратегии синхронизации.

Начнем с регулярного интерактивного обмена. Синхронизация здесь осуществляется по внутренним идентификаторам объектов (это относится в равной степени и к справочникам и к документам), за исключением случаев, когда это невозможно, например когда один объект конвертируется в несколько, перечисление преобразуется в справочник и т.п. Поиск по реквизитам объектов не производится, поэтому при любых изменениях объекта, уже участвовавшего в обменах, не происходит дублирования. Объект, ранее перенесенный, всегда будет найден по УИД, который, как известно, пользователем изменен быть не может. Такая стратегия синхронизации возможна при обменах один к одному, одна база-источник в одну базу-приемник, причем первоначально пустую. Именно она считается основной и реализуется по умолчанию, так как подходит для большинства задач: однократных переходов в новую программу и многократных односторонних обменов в базу, порожденную источником.

При вариантах слияния нескольких информационных баз в одну (загрузка в непустую базу является частным случаем слияния) такой подход, как правило, не устраивает. Хочется объединить справочники, используя для синхронизации те или иные реквизиты. Например для справочников организаций, контрагентов, физических лиц можно использовать для этих целей ИНН и КПП. Справочники номенклатуры можно попробовать синхронизировать по наименованию или артикулу, некоторые справочники-классификаторы по коду и т.д. Для наглядности рассмотрим перенос организации в непустую базу, в которой уже есть организация с нужными ИНН и КПП. Как это происходит. Если установлен поиск по уникальному идентификатору и программа нашла организацию, то поиск прекращается. Но при загрузке в непустую базу этого не будет, так как УИДы не совпадают. Если поиск по уникальному идентификатору не дал положительного результата и нужно продолжить поиск по реквизитам или поиск по уникальному идентификатору не проводился, то программа пытается найти организацию по свойствам поиска, сначала по ИНН + КПП, затем по ИНН (если КПП не заполнен) и наконец по наименованию. При совпадении ключевых реквизитов новый элемент создан не будет. Однако, если однажды отказаться от поиска по реквизитам и вернуться к синхронизации по уникальному идентификатору, то тут же возникнет дубль с теми же реквизитами, но другим УИД. Поэтому выбрав однажды синхронизацию по реквизитам при загрузке в непустую базу, отказаться от этой стратегии при последующих переносах уже нельзя.

Продолжим на примере передачи организации рассмотрение возможных проблем. Что произойдет, если в источнике (или приемнике) изменится КПП (обычная кстати история)? При очередном сеансе обмена организация не будет найдена по реквизитам и будет создан новый элемент справочника Организации. Избежать таких проблем при обменах - слияниях баз невозможно. Можно только в ручном режиме их отслеживать и изменять ключевые реквизиты одновременно во всех базах между сеансами обмена. Именно поэтому, там где это возможно, а именно при однократных переносах или многократных переносах в ту же базу приемника, созданную копированием источника, синхронизация по реквизитам не используется.

Напомню, что такой вариант обмена считается основным, и ему соответствует установка параметров по умолчанию. Если же Вы все-таки приняли решение о синхронизации по реквизитам, нужно установить параметр Продолжить поиск по реквизитам если по идентификатору не нашли в значение Да. Это будет означать отказ от принципа синхронизации только по УИД в пользу поиска по реквизитам, и наоборот, значение Нет означает, что поиск производится только по УИД, реквизиты в поиске не участвуют. Не для всех справочников используется этот режим, если необходимо, уточняйте перед покупкой.

Отдельно стоит заметить, что пустая база - понятие относительное. Если она создается из шаблона типовой конфигурации, то в ней уже есть некоторые непустые справочники: валюты, виды документов физических лиц. Для них синхронизация по уникальному идентификатору невозможна - всегда по реквизитам.

Еще один параметр Не учитывать в остатках подразделения служит для исправления пересортицы аналогичной описанным выше и исправляемым группой параметров вида Исправлять пересортицу .... Разница в том, что здесь остатки испорчены не по субконто, а по разделителю учета Подразделение. Суть проблемы иллюстрирует рис.4. Такие ошибки могут возникнуть в результате неправильного учета в программе БП 3.0 КОРП. Есть отрицательные остатки в разрезе подразделений, это явная ошибка. Если свернуть остатки только по банковским счетам, сальдо положительное. При конвертации базы в другую, н-р в ERP 2, КА 2, УХ 3.1 или другую БП 3.0, сформируются остатки по всем подразделениям, отрицательные остатки "превратятся" в нули, т.к. в базе-приемнике суммы в документах ввода остатков могут быть только положительными. При использовании описанного параметра сформируется сальдо только по банковскому счету, но подразделение будет пустым.

Пример отрицательных остатков по подразделениям

Рис.4 Пример отрицательных остатков по подразделениям

Если Вы используете валютный учет, то рекомендуем перед загрузкой заполнить справочник Валюты и загрузить курсы валют.

Рекомендую также ознакомиться со статьей: Стратегия переноса данных информационной базы 1С.

Важно: есть еще возможность решения проблемы синхронизации при загрузке в непустую базу - сопоставление объектов.

Другие правила переноса данных:

мы не работаем с infostart.ru, просим не путать наши разработки с чужими