AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 21.01.2013, 16:02   #1  
grishin is offline
grishin
Участник
 
26 / 15 (1) ++
Регистрация: 10.08.2005
Адрес: Москва
Записей в блоге: 1
Мы около трех лет назад написали машинку :
Опрашиваем шаблон Excel какие именованные ячейки есть.
Потом алгорим выводит в данные ячейки нужные значения
Имеем один универсальный алгоритм на любое количество отчетов.
Это дало возможность не программерам каждый раз следить за отчетами,
а самим пользователям корректировать шаблоны как им надо.
Они просто ставят оговоренные метки в нужное место шаблона.
Есть определенный алгоритм разделения меток шапки и табличной части.

Для тех кто будет это использовать хочу предупредить, что есть однако одна неприятность при удаление именованных ячеек в шаблоне.
Они не удаляются из списка ActiveWorkbook.Names и при опросе передаются в Axapta, но при выводе данных Axapta вываливается с ошибкой. На данный момент решили данную проблему созданием VBA макроса, обеспечивающего удаление "неправильных" именнованных ячеек из ActiveWorkbook.Names
Старый 21.01.2013, 17:57   #2  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,342 / 3563 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от grishin Посмотреть сообщение
Имеем один универсальный алгоритм на любое количество отчетов.
Это дало возможность не программерам каждый раз следить за отчетами,
а самим пользователям корректировать шаблоны как им надо.
Они просто ставят оговоренные метки в нужное место шаблона.
Есть определенный алгоритм разделения меток шапки и табличной части.
Любая универсальность усложняет поддержку. Я тоже такую машинку писал - для Word/Excel. Также с разделением шапки и табличной части. Правда не заморачивался выковыриванием именованных ячеек, а просто полагался на корректность настроек машинки, ибо сложность решения ошибки с лихвой компенсировалась ее некритичностью.

Из плюсов такого подхода:
  • Кажущаяся универсальность на этапе проектирования (=можно выбить бюджет)
  • Возможность заполнения шаблона по принципу 80/20, т.е. легкое автоматическое заполнение 80% полей в шаблоне
  • Возможность корректировки шаблона Word/Excel пользователем
Из минусов:
  • Универсальности нет. Вот нет и все. Обработкой каждого отчета все равно занимается свой класс, несмотря на настройки. Настройки могут помочь в выводе информации, но не помогут в ее формировании. Конечно классы являются наследниками, иерархия, почти как наследники RunBase, но ... все же каждый класс индивидуален. Особенно это заметно, когда используется табличная часть, т.к. там используется цикл, уникальный для каждого отчета.
  • Сложность настройки. В качестве источника данных для именованных диапазонов могут быть поля таблиц и дисплей-методы (у меня было так). Даже если не брать в расчет дисплей-методы - то какими же знаниями должны обладать пользователи, чтобы уметь выбрать правильное поле при создании настройки? Особенно учитывая тот факт, что даже в стандартном функционале поля именуются так - что пока не узнаешь, как они называются в АОТе - не поймешь, какое поле требуется выбирать. При этом пользователь обычно не видит, какое поле в терминах АОТа используется в обычной форме, хотя может и знать - что ему надо именно это поле. Про дисплей-методы вообще можно забыть - тут ориентация нулевая. Кстати - при настройке - каким образом облегчается жизнь настройщика? Или он должен знать все поля и методы на таблицах?
  • Неуниверсальность настройки. Представьте себе - вам нужно вывести в одном случае фразу из БД (например, название региона) в именительном падеже, а в другом - в родительном. Это будет 2 источника данных? А настройщик не запутается? А если нужно вывести 3 суммы - без НДС, с НДС и НДС - тоже в именительном и родительном падеже? Без программирования (даже минимального) не обойтись. А если программировать - то зачем тогда себе усложнять жизнь настройками?
  • Переносимость настройки. Программный код переносится легко через XPO. Легко - означает в один клик по проекту. А при импорте - можно сравнить - что поменялось. Плюс есть система контроля версий кода. Обладает ли этим утилита переноса данных? (Группа определений или еще какая?). А можно ли "оптом" переносить настройки ? Например, также легко, как модели в АХ 2012 или приложение в АХ 2009.
  • Отладка настроек. В состоянии ли настройщик адекватно проанализировать - что у него не получается в настройке? Или должен постоянно звать программиста? Если должен звать - то см. пункт выше - зачем тогда себе усложнять жизнь настройками?
  • При подготовке шаблона нужно уделять тщательное внимание именованию ячеек/закладок и следить за тем, чтобы их названия были понятны настройщику. Иначе все опять скатится до программиста.
Так что тут палка как говорится о двух концах...
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 21.01.2013 в 18:02.
Теги
excel, range

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Проверить существование поля в таблице Ax mikki_messer DAX: Программирование 3 08.08.2011 11:52
Sample Design Patterns: Microsoft Dynamics AX - Remedy for slow Microsoft Excel import Blog bot DAX Blogs 0 29.05.2011 17:13
Еще раз про Excel Range.Sort angler DAX: Программирование 7 28.10.2005 13:56
Excel Range.Sort Dmitryus DAX: Программирование 1 08.07.2005 19:11
range.find() в excel Shrike DAX: Программирование 12 10.06.2003 17:40

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:07.