Небольшое вступление.
Очень не хочется тратить своё драгоценное время программиста на написание программного кода!
Эта разработка позволяет применить Систему Компоновки Данных (СКД), для поиска несоответствий в таблицах значений.
Возможно, возникает вопрос. А зачем нужно такое?
Разработчик, столкнувшийся с проблемой свёртки базы или объединением двух баз, такой вопрос задавать не будет. Кроме того, этот конструктор удобно использовать для контроля результата обмена или просто сравнить две ТЗ.
Существенной особенностью конструктора является то, что для создания Таблиц значений можно использовать один и тот же макет СКД. Это гарантирует возможность корректной подготовки таблиц для последующего сравнения по наименованию колонок.
Цель – это сокращение трудозатрат программиста на поиск несоответствий в базах, например, с помощью сравнения таблиц значений.
Пояснение к конструктору сравнения таблиц значений.
Естественный для программиста метод сокращения своих трудозатрат – это использование вложенного труда. Так как предлагаемая разработка реализует именно этот метод, то она не предлагает революционное решение, а просто сокращает трудозатраты.
Предлагаемый конструктор методом СКД создаёт две ТаблицыЗначений (ТЗ) исходную (ТЗ_лев) и контролируемую (ТЗ_прав) на основании данных текущей базы или, при необходимости, внешней.
В третьей таблице значений (ТЗразличия) конструктор вычислит различие между таблицами и представит их в удобной форме для визуального анализа или дальнейшей обработки. На экране (ТЗразличия) размещена между (ТЗлев) и (ТЗправ).
Конструктор сравнения таблиц значений можно запускать как в обычном так и управляемом приложении. Однако следует учитывать, что в управляемом приложении функции конструктора ограничены. В управляемом приложении конструктор только подготавливает таблицы значений к сравнению, а операции по вычислению (ТЗразличия) выполняются в обычном приложении. Подробно эта особенность продемонстрирована на видео в разделе 05:14«Проблема_1» и 09:46 «Проблема_4».
На Видео демонстрация представлена на платформе 8.3.15.1830. Возможна ситуация, когда при смене версии платформы потребуется корректировка мотора (модуль ОбщегоНазначенияСКД). Ситуация возможна, но корректировка мотора прозрачна.
ВИДЕО.
Видеоролик наглядно демонстрирует применение конструктора.
Текст к видеоролику прилагается. Если речевое сопровождение отличается от текста, то правильным следует считать письменный текст.
Также в тексте размещены примечания, озвучка которых нарушает ритм видеоролика.
ТЕКСТ демонстрации видеоролика «Конструктор сравнения таблиц значений».
00:00. Заставка. (в озвучку не входит)
Сравнение будет выполнено для ТаблицыЗначений из базы обычного приложения с ТаблицейЗначения из внешней базы управляемого приложения.
В демонстрируемом примере сравниваем справочник.Контрагенты на предмет несовпадения КодаСинхронизации для ИНН и КПП в различных базах.
00:10. Начинается демонстрация конструктора СравнениеТаблицЗначений.
Запускаем Конструктор в базе обычного приложения.
Приступим к заполнению таблиц значений.
00:39. В настройках макета СКД оставим только необходимые реквизиты: ИНН, КПП и КодСинхронизации.
00:51. Укажем месторасположения мотора конструктора – это внешняя база.
00:59. Выберем текущую базу и заполним (ТЗ_лев).
01:07. Выберем внешнюю базу управляемого приложения и заполним (ТЗ_прав).
На экране видим три окна.
В левом представлена таблица (ТЗ_лев) текущей базы данных.
В правом – таблица (ТЗ_прав) контролируемой базы, в нашем примере это внешняя.
По центру – будет получен результат сравнения – это ТЗразличия.
01:36. Продолжаем заполнять таблицы.
Кнопкой «СравнитьТЗлев_прав» вычисляем различия.
В (ТЗразличия) собраны строки, не имеющие аналога в (ТЗ_лев) и (ТЗ_прав).
Небольшой комментарий. (в озвучке отсутствует).
В каждой строке указано из правой или левой таблицы поступила эта строка.
В конкретном примере, База-приемник (ТЗ_прав) предназначена для сбора данных из различных Баз-источников. Поэтому, в базе (ТЗ_прав) присутствуют объекты, не имеющие отношение к базе (ТЗ_лев), однако по формальному алгоритму определения различий эти строки попадут в (ТЗразличия).
01:50. Оставляем в (ТЗразличия) только строки, имеющие отношение к текущей Базе-источнику и представим их в удобной форме.
01:57. Это требование выполняем в два шага.
А) Настроим (ТЗразличия) на поиск строк с одинаковым набором «ИНН и КПП».
В списке колонок клавишей «Delete» удаляем всё, кроме «ИНН и КПП». После чего, кнопкой «СвернутьПоСЗ» выполняем свёртку. Процедура сгруппирует строки по полям свёртки и покажет несовпадения Лев и Прав. Различия разделены знаком ||(две вертикальные черты).
.
02:14. Б) Кнопкой «Оставить пересечения» удалим строки, не имеющие отношения к обмену между конкретными базами (ТЗ_лев) и (ТЗ_прав).
02:26
В) Конструктор предоставляет разработчику возможность обработать результат по своему алгоритму.
Комментируем вариант автоматического исправления кодов синхронизации.
02:29. Перейдем на страницу ДЗ. Проверим уникальность набора «ИНН и КПП».
Получим ДеревоЗначений текущей базы
03:00. и внешней базы данных.
03:30. В конструкторе использована универсальная процедура поиска дублей. Эта процедура будет описана в другой статье.
Как видим, в БазеИсточнике дублирования НЕТ. В БазеПриемнике дублирование ЕСТЬ. Из этого следует, что автоматическую коррекцию «КодаСинхронизации» допустимо выполнить только для уникальных объектов в обеих базах.
03:46. Поясним это утверждение на примере двух строк.
- 03:57. Для ИНН=2901257453 в колонке «Прав» два различных кода синхронизации.
- Для ИНН=5190034244 в колонке «Прав» одно значение.
04:33. Второе значение Дубля не зарегистрировано в (ТЗразличия), так как оно не является различием. Этот вариант следует учесть при автоматической обработке.
04:56.Скрин этой ситуации с пояснениями приведён ниже.
05:08. Такой алгоритм реализован и сейчас его запустим. Оставшиеся контрагенты требуют ручного вмешательства. Об этом сообщено на экране.
05:14. Теперь немного о проблемах Конструктора.
Проблема_1.
Предложенный конструктор корректно работает в обычном приложении. Это обусловлено тем, что сравнение двух ТЗ выполняется по наименованию колонок.
В управляемом приложении одинаковые наименования колонок на одном экране вызовут ошибку.
Поэтому, если обе базы (Источник и Приемник) исполнены в Управляемом приложении, то конструктор необходимо запустить из конфигуратора в обычном приложении. Демонстрируем такой запуск из управляемого приложения.
06:12. Вызываем тот же конструктор.
06:21. Настроимся на поиск различий в КодеСинхронизации.
06:39. Изменим адрес внешней базы. Сейчас обычное приложение назначено внешней базой.
И повторим все операции по заполнению трёх ТЗ.
07:00. Пояснение к интерфейсу.
Зеленые кнопки устанавливают активную таблицу значений. При этом номер активной таблицы указывается в заголовках кнопок.
Рыжим цветом обозначены кнопки заполнения таблиц из текстового файла.
Голубым цветом отмечены кнопки управления таблицей различий (ТЗразличия).
Жёлтым цветом указано место расположения мотора конструктора - «версияСКД 2.8.24».
07:35. Примечание. Для демонстрации используется ранее разработанный КонструкторСКД, описание которого можно найти в моих публикациях. В текущем примере описаны изменения КонструктораСКД, необходимые для решения задачи сравнения (ТЗ_лев) и (ТЗ_прав). Следует учитывать, что желательно использовать последнюю версию модуля СформироватьРезультатСКД «версияСКД 2.8.24». Модуль расположен либо в модуле объекта внешней обработки, либо в общем модуле конфигурации (рекомендуется). Разработчик произвольно выбирает место расположения модуля.
08:10. Возвращаемся к (ТЗразличия) Как видно, результат одинаковый.
Согласен, предложенное решение не очень красиво, но работает.
08:30. Проблема_2.
Один Макет СКД обслуживает различные базы. Поэтому возможна ситуация, когда во внешней базе востребованный реквизит назван иначе. Например, КодСинхронизации и КодДляСинхронизации. В этом случае макет СКД для чтения внешней базы не пригоден.
09:05. Проблема решается применением вычисляемого поля, в котором указано правило для каждой базы индивидуально.
Скрин с пояснениями приложен.
09:30.
МинусПроблема_3.
Конструктор корректно применяет СКД в управляемом приложении. Проблема_1 касается только формирования (ТЗразличия).
То есть, сохранять файл для последующего анализа можно из управляемого приложения по тому же макету СКД.
09:46.
Проблема_4.
Если внешняя база не доступна как ComОбъект.
Этот случай рассмотрим на примере определения различий в наименованиях контрагентов.
Запускаем конструктор в управляемом приложении.
10:13. Выбираем место расположения мотора.
10:25. Настраиваемся на поиск различий в наименованиях.
10:54. Запоминаем Таблицу в файл.
11:13. Настраиваем обычное приложение на поиск различий в наименованиях.
11:52. Читаем данные внешней базы из файла.
И получаем (ТЗразличий) по наименованию.
12:19. Как выясняется (ТЗразличий) чувствительна к регистру.
Устраняем это неудобство предварительной унификацией наименования.
12:45. Повторяем операции по сравнению.
13:00. Бухгалтер примет решение о необходимости вмешательства самостоятельно.
Желаю Успехов всем и каждому.
Рекомендация разработчику.
Если разработчик поставил себе задачу сравнить только одну ТЗ, то можно не заморачиваться с конструктором и использовать другие решения.
Статьи по аналогичной задаче «Сравнение таблиц значений».
Состав файла архива .rar::
1. Внешняя обработка КонструкторТЗразличия, erf.
2. Конфигурация шаблона КонструктораСКД, cf. (версияСКД 2.8.24) – это мотор конструктора.
3. Архив базы шаблона КонструтораСКД, dt. Архив содержит все названные модули.
Из шаблона в свою конфигурацию необходимо обязательно перенести модули ФункцииДляОтчетовСерверСКД и ФункцииДляОтчетовСКД. Эти модули обеспечивают работу в ComСоединении с внешней базой.
Модуль ОбщегоНазначенияСКД желательно разместить в конфигурации. В таком варианте проще поддерживать последний релиз.
