Концепция постановки задачи на разработку правил обмена КД 2.0

Когда возникает необходимость объяснить программисту какой состав объектов должен участвовать в обмене все время возникает дублирование трудозатрат. Один человек (БА) описывает где-то состав объектов, программист потом это описание преобразует в правила обмена, по-сути повторяя 70% работы БА — т.к. обычно в обменах большинство объектов просто переносятся 1 в 1, и только с некоторыми их них возникают методологические нюансы. Возникла идея как этот дубль убрать.

Как БА анализирует какие объекты нуждаются в переносе? Зачастую открывает две базы и смотрит — вот надо перенести поступление, ага в приемнике есть такой же документ, запишем.. Таким образом набирается файл xls или doc с кучей заметок "на полях" — вот здесь надо вместе с поступлением создавать еще и принятие ОС, тут надо ставить галочку, а здесь контрагента оставляем пустым, и т.д. Чем плохо такое описание? Во-первых оно может быть очень большим, а нюансов различных немало, в итоге есть шанс получить огромный трудновоспринимаемый документ. Во-вторых — все мы люди, легко забыть про какой-то реквизит. Конечно, программист при разработке может обратить на это внимание. Но может и не обратить. Еще частая ошибка в  таких постановках — отсутствие полей, по которым идет синхронизация.

Можно минимизировать и трудозатраты, и ошибки. Если БА напишет базовые правила сам. Имеется в виду самые простые — объект в объект, без ПВД. Ему удобно — не надо лазить в двух базах, а можно пользоваться инструментами сопоставления реквизитов самой КД. Удобно программисту — самую нудную работу сделали, остается проработать каждое ПКО, и создать ПВД. Остается вопрос — как быть с нюансами? Т.е. с теми методологическими тонкостями, когда например один объект преображается в два (или наоборот), или когда по данным регистра сведений надо создавать бизнес-процесс? Их и следует описать в файле. Но не в произвольном с потолка взятом формате. По написанным базовым правилам можно построить прилагаемый к публикации отчет, выгрузить его в Excell — и уже там, пользуясь колонкой "Комментарий" дописать все что нужно.

Внешний вид отчета:

Отчет делится на две части: ПКО для ПКС и ПКО для ПКЗ:

Первыми идут поисковые реквизиты — выделены жирным. В отчете работает расшифровка — можно открыть произвольное ПКО ПКС и посмотреть его содержание.

К сожалению, под рукой не было примера где можно было бы показать сопоставление по планам счетов — в отчете по ПКЗ добавлена колонка синоним, благодаря которой можно видеть код счета напротив его идентификатора.

Этот подход позволит избежать лишних трудозатрат, и даст удобный инструмент БА для составления маппинга того же плана счетов. Кроме того сам отчет может быть полезен при обзоре существующих правил.