Когда возникает необходимость объяснить программисту какой состав объектов должен участвовать в обмене все время возникает дублирование трудозатрат. Один человек (БА) описывает где-то состав объектов, программист потом это описание преобразует в правила обмена, по-сути повторяя 70% работы БА - т.к. обычно в обменах большинство объектов просто переносятся 1 в 1, и только с некоторыми их них возникают методологические нюансы. Возникла идея как этот дубль убрать.
Как БА анализирует какие объекты нуждаются в переносе? Зачастую открывает две базы и смотрит - вот надо перенести поступление, ага в приемнике есть такой же документ, запишем.. Таким образом набирается файл xls или doc с кучей заметок "на полях" - вот здесь надо вместе с поступлением создавать еще и принятие ОС, тут надо ставить галочку, а здесь контрагента оставляем пустым, и т.д. Чем плохо такое описание? Во-первых оно может быть очень большим, а нюансов различных немало, в итоге есть шанс получить огромный трудновоспринимаемый документ. Во-вторых - все мы люди, легко забыть про какой-то реквизит. Конечно, программист при разработке может обратить на это внимание. Но может и не обратить. Еще частая ошибка в таких постановках - отсутствие полей, по которым идет синхронизация.
Можно минимизировать и трудозатраты, и ошибки. Если БА напишет базовые правила сам. Имеется в виду самые простые - объект в объект, без ПВД. Ему удобно - не надо лазить в двух базах, а можно пользоваться инструментами сопоставления реквизитов самой КД. Удобно программисту - самую нудную работу сделали, остается проработать каждое ПКО, и создать ПВД. Остается вопрос - как быть с нюансами? Т.е. с теми методологическими тонкостями, когда например один объект преображается в два (или наоборот), или когда по данным регистра сведений надо создавать бизнес-процесс? Их и следует описать в файле. Но не в произвольном с потолка взятом формате. По написанным базовым правилам можно построить прилагаемый к публикации отчет, выгрузить его в Excell - и уже там, пользуясь колонкой "Комментарий" дописать все что нужно.
Внешний вид отчета:
Отчет делится на две части: ПКО для ПКС и ПКО для ПКЗ:
Первыми идут поисковые реквизиты - выделены жирным. В отчете работает расшифровка - можно открыть произвольное ПКО \ ПКС и посмотреть его содержание.
К сожалению, под рукой не было примера где можно было бы показать сопоставление по планам счетов - в отчете по ПКЗ добавлена колонка синоним, благодаря которой можно видеть код счета напротив его идентификатора.
Этот подход позволит избежать лишних трудозатрат, и даст удобный инструмент БА для составления маппинга того же плана счетов. Кроме того сам отчет может быть полезен при обзоре существующих правил.
