Как правильно выбрать средство для переноса данных. На что нужно обратить внимание при выборе продукта. Об этом пойдет речь в данной статье.

Примечание. Рассматривать будем решение задачи с использованием технологии конвертации данных, разработанной фирмой 1С.

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

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

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

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

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

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

На рис.1 показан фрагмент оборотно-сальдовой ведомости в базе-источнике, отражающий остаток материала Лук репчатый очищенный сырье. Организацией в данном случае является индивидуальный предприниматель, применяющий систему налогообложения Общая. Значит, используется партионный учет, но, что важно, дополнительно к регистру бухгалтерии учет ведется в регистре ИП МПЗ, который необходим для отражения оплаты партий МПЗ. Следовательно, остатки в базе-источнике нужно формировать не только по регистру бухгалтерии, но и по регистру ИП МПЗ.

Рис.1 Фрагмент оборотно-сальдовой ведомости

В результате при вводе остатков в базе-приемнике создаются уже не три, а четыре строки по данному материалу (см. рис.2). Это произошло потому, что одна из партий (с количеством равным 230) оплачена частично, соответственно количество и сумма партии разделены на две строки с разными значениями реквизита Оплачено.

Рис.2 Фрагмент документа ввода остаков

Почему это важно, видно на рис.3: в движениях в регистре ИП МПЗ есть строка, отражающая факт того, что часть партии не оплачена. Если бы остатки формировались только на основе регистра бухгалтерии, то они были бы искажены и не соответствовали бы источнику полностью.

Рис.3 Движения (набор записей) при вводе остатков

Этот пример показывает, как важно, чтобы правила конвертации были пригодны для различных комбинаций параметров учета. Не во всех случаях такая описанная тщательная проработка понадобится, но в других случаях будут другие особенности. Тиражируемый продукт должен быть пригоден для различных вариантов учета. Комбинаций всевозможных настроек может быть много: учет по складам, по партиям, списание по средней себестоимости или ФИФО, УСН доходы минус расходы и т.д. и т.п.

Рассмотрим пример ошибки при сопоставлении реквизитов справочника, где, казалось бы, ошибок быть не должно. Как было указано выше, у справочника Номенклатура есть реквизит СтавкаНДС. Этот реквизит имеет разный тип в конфигурациях УПП и ERP, в УПП  это перечисление, в ERP - справочник. В пустой базе ERP (по крайней мере созданной из шаблона) в справочнике СтавкиНДС уже есть несколько элементов, как бы предопределенных (это не совсем корректно, но будем так их называть). Среди них есть такие, у которых одинаковое значение ПеречислениеСтавкаНДС. В правилах, разработанных фирмой 1С для переноса остатков из УПП в ERP (или из КА 1 в КА 2), синхронизация справочника СтавкиНДС осуществляется именно по реквизиту ПеречислениеСтавкаНДС, это приводит к тому, что неправильно заполняется Ставка НДС у номенклатуры (см. рис.4): 15,25% вместо 18/118 или 16,67% вместо 20/120. Правильно - синхронизировать справочник СтавкиНДС по двум реквизитам: ПеречислениеСтавкаНДС и  Ставка. К тому же, в ERP есть регистр сведений Ставки НДС номенклатуры, его также следует заполнить. В УПП нет аналогичного регистра сведений, поэтому сопоставить здесь нечего, нужно просто знать о наличии такого регистра и создать в нем необходимые записи.

Рис.4 Пример ошибки переноса элемента справочника номенклатура со ставкой 18/118

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

Мы работаем с конвертацией данных много лет, с момента ее появления, а каждый продукт разрабатывается месяцами или даже годами, проходя тестирование на рабочих базах, прежде чем появляется тиражный вариант. Этим объясняется тщательность проработки и качество наших продуктов. Следует подчеркнуть еще один важный момент: может сложиться ошибочное представление о том, что наша команда занимается только конвертацией данных. Это не так. У нас всегда есть проекты по сопровождению различных конфигураций семейства 1С:Предприятие. Именно здесь на рабочих базах, мы досконально изучаем методики и алгоритмы, о которых говорилось выше.

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

• Перенос остатков по регистрам УСН из КА 1.1 в БП 3.0

• Перенос единиц измерения в Комплексную автоматизацию 2

• Перенос предопределенных значений в технологии конвертации данных

Приглашаем Вас к сотрудничеству. Контактные данные Вы найдете внизу страницы. Или воспользуйтесь формой обратной связи.