Приветствую!
Все, кто столкнулись с необходимостью переводить конфигурации с платформы 8.1 на 8.2 знают о двух центральных моментах перехода - обязательной проверки типа Основания в предопределенной процедуре ОбработкаЗаполнения() и особенности использования запросов с РАЗЛИЧНЫЕ и УПОРЯДОЧИТЬ. Заботливая фирма 1С даже приложила специальную обработку, помогающую найти проблемные места в коде конфигурации. Однако при практическом применении этой обработки выясняется, что ее использование - мягко говоря не эффективно, если не сказать, что крайне неудобно. Т.к. после того, как обработка вываливает список найденных ею возможных проблем, предпологается, что разработчик будет заглядывать в конфигураторе в каждый указанный модуль, что не проблемно, если у вас таких проблем несколько, но крайне затруднительно, если мы говорим о большой конфигурации с огромной кучей потенциально опасных мест. Собственно восполнить этот пробел и должна данная обработка.
1. ОбработкаЗаполнения. Собственно идея проста - в Попытке мы заполняем все существующие документы неожиданным значением (например Неопределно). И смотрим, вызовет, ли это исключение. Если исключения не произошло - можно смело предоложить, что разработчик позаботился о проверке типа Основания и затруднений с данным документом не будет. Но если произошло исключение - это сигнал проблемы. И тут бы можно было бы умыть ручки и радостно рапортовать о проблеме. Но мы пойдем дальше, и заглянув в метаданные определим, какими типами можно заполнить данный документ. И по очереди попытаемся заполнить документ на основании пустой ссылки нужного типа. Если исключения не произошло - можно предопложить, что данный тип основания допустим, если произошло, то скорее всего - нет. На основании такой работы обработка составляет простой код - заглушку, который по условию проверяет тип Основания и возвращается, если переданно основание недопустимого типа. Таким образом мы делаем большую часть грязной работы за разрабочтика. Тут бы вобщем можно было бы сразу вшить созданную нами заглушку в код выгруженных модулей и загрузить их обратно в конфигурацию, но делать этого я не буду - всеж хоть какой то контроль и понимание происходящего со стороны разработчика должны присутствовать.
2. РАЗЛИЧНЫЕ и УПОРЯДОЧИТЬ. К сожалению, придумать сколь либо адекватный алгоритм автоматической проверки мне не удалось. Связанно это с тем, что зачастую запросы составляются кусками и анализировать их с приемлемой результативностью - не совсем простая задача. Поэтому, все, что делает обработка - это в удобном формате отображает найденные в модулях процедуры и функции с РАЗЛИЧНЫЕ и УПОРЯДОЧИТЬ. Таким образом отменяя необходимость мотаться как шельма по конфигуратору туда-сюда, ища нужные места.
В заключение: у обработки определенно есть потенциал, и возможно дальнейшее развитие и доработка функционала. Но на практике, после перевода основной конфигурации на новую платформу я врядли к ней вернусь. Так, что оставляю ее доработку людям, которые часто занимаются решением вышеоговоренных проблем. Из идей развития:
1. Всеж хочется алгортим, если не автоматической проверки, то хотябы подсвечивания нужных кусков запроса
ВЫБРАТЬ (РАЗРЕШЕННЫЕ) РАЗЛИЧНЫЕ
// Вот тут подсвечиваем, и разбираем на ключевые слова
ИЗ
// пофигу на это
УПОРЯДОЧИТЬ ПО
// вот тут подсвечиваем или разбираем на ключевые слова
2. Автоматическая корректировка в модулях, с последующей загрузкой в конфигурацию.
3. мелкие рюшки-менюшки в виде возможности выгрузить модули не выходя из обработки, возможности работы с разными конфами и запоминания процесса их модификации, поиск ключевых слов и т.д. и т.п.
И наконец - ссылки по теме:
//infostart.ru/public/75259/
http://www.nashe1c.ru/materials-view.jsp?id=284
