Новости от MS

[Raven Melancholic]

Цитата:

Сообщение от EVGL

...По опыту, до 3-5 недель на документ в зависимости от сложности...

3-5 недель на печатную форму?
Чтоб я так жил с повременной оплатой.

Я понимаю, сарказм, гротеск, но ...

[EVGL]

Цитата:

Сообщение от Raven Melancholic

3-5 недель на печатную форму?
Чтоб я так жил с повременной оплатой..

1) Надо иметь в виду, что на захiде нет предписанных форм, а есть скупые требования к минимальному содержанию счета. Соответственно, все изобретают кто на что горазд, дорабатывают под запросы основных клиентов, отдел маркетинга пригладывает свою руку, так что каждый раз TORG-12 приходится во многом изобретать заново.

2) Я имел в виду длительность, а не трудозатраты. Общие трудозатраты на хороший захiдний счет составляют от 1,5 до 3 недель.

[Raven Melancholic]

Цитата:

Сообщение от EVGL

Надо иметь в виду, что на захiде нет предписанных форм

Вы, видимо, давно не отслеживали требования к первичной учетной документации в России. Тут тоже очень давно нет предписанных первичных форм кроме, того, что касается взаимоотношений компаний с государством и в большинстве случаев работают правила:

• Соответствие требованиям, указанным в законе о Бухгалтерском учете.
• Договоренность между контрагентами сделки.
• Баланс "сил" между продавцом и покупателем.

В общем, множество форм разрабатываются по принципу "кто во что горазд". Нередкая ситуация, когда первичная форма делается под конткретного клиента.

Цитата:

Я имел в виду длительность, а не трудозатраты. Общие трудозатраты на хороший захiдний счет составляют от 1,5 до 3 недель.

Всё равно, какой-то перебор, даже если абстрагироваться от технологий.

PS: ну и sukhanchik-у лучше такие сроки не видеть. У нас для его команды на подходе десяток форм первички намечаются.

[sukhanchik]

Цитата:

Сообщение от Raven Melancholic

PS: ну и sukhanchik-у лучше такие сроки не видеть. У нас для его команды на подходе десяток форм первички намечаются.

Спасибо . От себя скажу, что в случае отчёта и внятного ТЗ - трудозатраты от сроков не сильно отличаются (при фуллтаймовой работе). Опять-таки - в SSRS важно знать грабли. Это существенно упрощает разработку. Пока все грабли себе в базу знаний не положил - могут быть действительно по срокам прогибы. При этом в силу отсутствия обновлений по AX2012 - количество новых граблей явно не увеличивается, в отличие от D365FO
AX 2012:
1. Здесь важно иметь корректную настройку SSRS (чтобы студия смотрела и деплоила куда надо, чтобы приложение смотрело и деплоило куда надо и т.д.). Актуально, когда есть DEV / TEST / PROD - 3 (а может и больше) разных приложений.
2. Разрабатывать SSRS-отчет нужно строго на том приложении, где можно относительно в любой момент собрать полный CIL и рестартануть AOS.
3. Добавление нового параметра в класс-контракт чревато корректировкой параметров в источнике данных отчета, т.е. лучше этого не делать, либо делать минимальное количество раз. Аккуратно надо следить за списком параметров в отчете и соответствии его списку параметров в источнике данных отчета
4. Добавление нового поля в источник данных (для DP-класса) требует перевыбор источника данных (чтобы обновился список полей)
5. Контролы не должны наезжать друг на друга в дизайне, но в целом система только "ворчит", в отличие от D365FO, где это является ошибкой компиляции
6. SSRS-отчеты вместе с их Visual Studio-проектами (которые хранятся в АОТе) не поддерживают работу в системе контроля версий.

D365FO:
В силу особенностей разработки в D365FO (отдельная виртуалка, билд без отдельной сборки CIL-а, постоянный рестарт IIS) - пп1 и 2 - по сути не актуальны.
п.3 и 4 - остаются
п.5 наезд контролов - это уже ошибки компиляции. Надо править. Особенно весело отдублировать стандартный отчет, чтобы чуть-чуть чего-то поменять, после чего заняться "причёсыванием" контролов, которые не трогались, после чего плюнуть и сделать всё-таки свой отчёт "с нуля"
6. Система контроля версий поддерживается, но исходя из того, что дизайн отчета - это один файл. При этом Visual Studio проекты не хранятся теперь в АОТ - они поддерживаются системой контроля версий уже на уровне Visual Studio
7. Добавление поля в Tablix (табличную часть) в последних версиях системы требует открытия rdl-файла в XML-виде и правки отдельных блоков в XML. В противном случае отчет либо не сбилдится, либо сбилдится, но не задеплоится. Если всё сбилдилось и задеплоилось - Вам крупно повезло. Такое тоже бывает
8. SSRS-отчеты, основанные на Query (а не на DP-классе) не расширяются (нельзя новое поле, добавленное в расширение таблицы, входящей в Query - вывести в отчет, даже если отдублировать дизайн). Ну т.е. можно расшибиться лбом, но нет. Поэтому даже если Вам не нужно менять дизайн - Вам придется его откопировать и скорее всего дальше перейти на DP-класс (либо копировать Query)

Для SSRS-отчетов (D365FO) есть замечательное (кажется платное) расширение от Docentric, которое позволяет по сути нарисовать любой дизайн отчета в Word продвинутому пользователю на базе простейшего отчета. Т.е. программисту можно нарисовать простейший отчет, выведя в него все данные, а дальше отдать его ответственному человеку-дизайнеру, который его переделает (т.е. программисту не придется заниматься дизайнерством). Итоговый результат будет также в виде SSRS.
https://www.docentric.com/product/how-to-use
Также Docentric предлагает тулзу для конвертации SSRS -> ER (где-то там же на сайте видел. Но с ходу найти не могу)

С ER - многие вещи в интерфейсе поначалу неочевидны (например, что надо встать на конкретный узел, чтобы появилась кнопка). Потом привыкаешь.
В целом - могу сказать, что очень жаль, что в AX2012 нету ER - это бы радикально упростило построение любой отчетности. При этом я бы не сказал, что ER- это какая то фишка D365FO, которая привязана именно к архитектуре D365FO (то, что это веб-сайт или облако). Просто это развитие системы.