Всем привет! Меня зовут Таня, я руководитель группы разработки Axapta в компании Lamoda. В этой статье пойдет речь о разработке нашего первого проекта на платформе Microsoft Dynamics 365 For Finance and Operations. 
Я расскажу вам о подходах, которые мы использовали, допущенных ошибках, поделюсь полученными знаниями и опытом.
Эта статья может быть интересна тем, кто начинает разработку проекта в D365 или только задумывается об этом.
Это бесплатная расшифровка отчет с встречи Mycrosoft Dynamics 365 и Power Platform. Цель проекта и техническая основа Наш филиал в Германии закупает товары и продает их российскому юридическому лицу.
Раньше мы использовали систему «Ценит», которая позволяла вести учет только на уровне финансовых данных, но не справлялась с задачами учета продукции и логистики.
Для решения этих задач у нас были дополнительные инструменты.
Данные хранились сразу в нескольких базах данных.
Все это негативно сказалось на скорости и надежности всей системы.
Мы хотели, чтобы система бухгалтерского учета помогла немецкому филиалу сдавать отчеты, платить налоги и проходить проверки.
Предыдущая ERP с трудом решала эти проблемы, поэтому мы решили разработать и запустить собственную систему учета.
Наша ERP должна была объединить финансы, бухгалтерию и логистику филиала в единый контур.
В качестве основного программного обеспечения мы выбрали Microsoft Dynamics 365 (ранее Dynamics AX, также известное как Axapta).
Бизнес-составляющая описана в статье «Технологии, аутсорсинг и менталитет» .
Здесь речь пойдет о технической реализации.
Итак, нам нужно было автоматизировать несколько бизнес-процессов:
- Закупка товаров у поставщиков;
- Продажа российскому юридическому лицу;
- Интеграция D365 и Ax2012 — учетной системы российского юридического лица;
- Автоматизация выбора налоговых схем;
- Подача отчетности в соответствии с требованиями немецкого законодательства.
Для небольших удаленных филиалов схема SaaS оптимальна, поскольку позволяет получить все необходимое программное обеспечение и среды разработки для начала внедрения сразу после подписания договора с провайдером.
У нас были сжатые сроки: всю разработку нужно было завершить за 3 месяца.
Поскольку старая система вела инвентаризацию в электронных таблицах, миграция всего набора исторических данных была бы непосильной задачей в середине финансового года.
Но на начало отчетного периода достаточно перенести только остатки.
Таким образом, запуск пришлось произвести либо 1 января 2019 года, либо перенести еще на год. У нашей команды не было опыта разработки в D365. Несмотря на все обстоятельства, мы планировали начать этот проект как можно быстрее.
Далее я отдельно опишу все этапы разработки.
Я подробно расскажу о каждой итерации: какой опыт мы получили и какие ошибки допустили.
Первая итерация, изменения в версии приложения 7.3. 
Чтобы быстро приступить к работе, мы сначала разработали простую архитектуру приложения.
Он состоял из сред разработки — 1-уровневых сред DevBox. Все компоненты были установлены на одном сервере/виртуальной машине: Application Object Server (AOS), база данных, Dynamics 365 Retail и Management Reporter. Для тестирования мы решили использовать среду SAT — 2-х уровневую среду Standard Acceptance Test. Двухуровневая среда — это среда Multi-box, компоненты которой установлены в нескольких облачных сервисах и обычно включают в себя более одного сервера объектов приложений (AOS).
По сути, она максимально приближена к продуктивной среде, поэтому мы решили протестировать на ней.
Первые среды разработки мы развернули на существующей локальной инфраструктуре, но ее мощности оказалось недостаточно для дальнейшего развития проекта.
Поэтому, когда к проекту присоединились еще два разработчика, мы быстро и элегантно развернули для них DevBox в облаке.
Наши облачные среды управлялись через портал сервисов жизненного цикла.
Закончив с окружением, команда приступила к разработке.
Мы настроили среды разработки на Visual Studio и подключили их к контролю версий Azure DevOps, предварительно создав ветку для загрузки кода.
Далее мы разработали подход к разработке и переносу изменений в среду SAT. В архитектуре D365 нет уровней; весь стандартный код заложен в модели.
Модификации переносились в среду SAT через портал LCS в пакете, содержащем скомпилированную модель.
Модель — это минимальная единица передачи изменений в производство, поэтому мы решили сделать одну модель — одну модификацию, чтобы самостоятельно передать наши модификации для тестирования и дальнейшего производства.Для начала мы реализовали самую простую и распространенную модификацию — добавление нового поля в стандартную таблицу, его инициализацию при создании записи и вывод в стандартную форму.
Даже в таком простом проекте появились новые типы объектов.
Мы сделали расширение для добавления новых полей в стандартную таблицу.
Для отображения поля на стандартной форме мы создали новый тип объекта — расширение формы.
И чтобы инициализировать поле, мы создали класс, расширяющий методы таблицы.
Это позволило инициализировать поле при создании записи.
В такой простой модификации мы увидели один из главных принципов D365 – не изменение, а расширение стандартных объектов.
Следующей модификацией стало создание новой формы.
Теперь при создании формы нужно было указывать ее образец.
Паттерн — это шаблон, который полностью определяет структуру дизайна формы.
Пока мы полностью не воспроизведем структуру, заложенную в шаблоне, наша форма не скомпилируется.
Изменить шаблон готовой формы невозможно.
Поэтому, прежде чем приступить к разработке, мы заранее продумали, как будет выглядеть наша форма.
Также мы сохранили возможность самостоятельно контролировать дизайн формы.
Если мы указывали паттерн — Custom, то мы полностью отвечали за оформление формы: какие объекты на ней были и с какой вложенностью.
Выводы после первой итерации
1. Не менять стандарт, а только расширять его.
2. Обратитесь к модели, если мы используем ее объекты в другой модели.
В этом одно из отличий моделей D365 от предыдущих версий: объект существует только в одной модели.
3. Имеются ограничения на изменение свойств стандартных объектов.
Не все свойства стандартных полей можно изменить в их стандартных расширениях объектов.
Например, расширением таблицы PurchTable является поле LineDisc. Мы можем контролировать видимость и метку поля, но такие свойства, как «обязательные» и «редактируемые», изменить нельзя.
4. В D365 нет заданий, все делается через классы.
5. Мы обыграли модели слишком мелко, и оказалось, что наш принцип «одна модификация = одна модель» не работает. Вторая итерация и переход на одну модель В начале второй итерации у нас было две модели, ссылающиеся друг на друга.
Из-за этого мы больше не могли портировать эти модификации самостоятельно.
Поэтому мы решили работать над одной новой моделью, в которую нужно было перенести все существующие модификации.
Модель в D365 — это набор исходных файлов, расположенных в отдельном каталоге.Поэтому объединение в одну модель на DevBox сводилось к перемещению файлов из одной директории в другую и удалению старых директорий.При компиляции они собираются в отдельную библиотеку, имеющую связи с другими библиотеками.
Итак, мы построили новую модель, установили ее последнюю версию на каждый DevBox, а затем продолжили работать в рамках той же модели в средах разработки.
Естественно, пару моделей мы уже передали на тестирование в среду SAT. Поэтому пришлось их удалить и выпустить одну новую.
Все обновления среды SAT выполнялись с использованием пакетов, включая удаление моделей.
Мы создали пакет с пустыми моделями, которые нужно удалить, и добавили в него скрипт с названиями этих моделей.
Далее мы собрали пакет с новой моделью и выкатили его в среду SAT. Таким образом, компания SAT приобрела новую модель.
Когда мы объединили модели, мы заметили, что каждый разработчик называет расширения объектов по-разному.
Мы договорились о правилах именования объектов по шаблону: PurchTable.LamodaModelFormExtension, PurchTableTypeLamodaModelClass_Extension .
Также мы как команда договорились, что для одного стандартного объекта мы создаём только одно расширение и вносим изменения во всё.
Я выбрал несколько интересных модификаций, которые мы сделали на этом этапе.
Показаны возможные подходы к разработке в D365. Проблема 1 При проводке счета по заказу на продажу необходимо было заменить номер счета на номер из заказа.
Для этого мы определили стандартный расширяемый класс, который позволил нам выполнить эту модификацию.
Мы сделали расширение стандартного класса SalesInvoiceJourCreate. У его метода getNumAndVoucher() есть Next — это наш новый супер, он говорит о вызове стандартного кода метода.
После вызова стандартного кода мы заменили номер счета на нужное значение.
Это один из наших подходов к разработке: использование расширений и добавление собственного кода до или после (необязательно как до, так и после) выполнения стандартного кода.Проблема 2 Необходимо было изменить отображение итогов заказа на покупку: сгруппировать итоги по номеру накладной поставщика из строк заказа на покупку.
В данном случае мы не нашли куда расшириться без снижения производительности вдвое, поэтому сделали свою версию результатов, не трогая стандартные.
Проблема 3
Еще одна интересная модификация: в строки формы заказа на закупку пришлось добавить поля из справочника товаров с возможностью фильтрации.
В предыдущих версиях модификация была совершенно неинтересной и решалась простым добавлением таблицы в качестве источника данных на форму и перекрытием двух методов.
В версии 7.3 мы не могли расширять методы источника данных стандартной формы.
Чтобы делать фильтрацию, а не создавать для этого новую форму, мы добавили в форму представление в качестве источника данных.
Возможность расширения методов источника данных появилась в версии 8.1 D365. 
Выводы после второй итерации
На этом этапе мы разработали основные модификации, необходимые для запуска проекта.
- Мы ввели правила именования расширений.
Они не только помогли сделать именование последовательным и понятным, но и упростили последующее обновление, поскольку наши имена не совпадали со стандартными объектами в пакете обновления.
- Порадовало то, как быстро происходят перекрестные ссылки при построении проекта или модели — в этой версии это очень удобно организовано.
- Модели обновляются по-разному в разных типах сред. В этом мы убедились на примере объединения моделей.
- Прежде чем приступить к разработке новой модификации, вам необходимо получить последнюю версию модели, так как разработка ведется в рамках одной модели.
- Очень удобным оказался механизм data-субъекта для загрузки и выгрузки данных в Excel при обновлении данных в производстве.
Наш отдел данных и аналитики в настоящее время использует его для получения данных из нашего облачного D365.
Релиз на Go Live состоялся, модель находится в производстве.
И мы столкнулись с проблемой выпуска только проверенных модификаций внутри модели.
Также мы хотели упростить процесс отладки при тестировании модификаций и ускорить обновление тестовой среды.
Как все работает сейчас В последней итерации мы добавили две среды: сборку и тестирование.
После того как все среды были настроены и протестированы, мы упростили тестирование и научились выпускать только проверенные модификации внутри модели.
Для тестирования мы развернули 1-уровневую среду и подключили ее к ветке разработки в системе контроля версий.
Обновление теперь заключалось в получении последней версии самой модели и ее сборке.
В этой среде мы отлаживали как в обычном DevBox. 
Сборка пакетов для выпуска теперь выполнялась в новой среде сборки.
Протестированные модификации переносились в новую ветку в системе контроля версий ревизиями (пакетами изменений, загруженными в систему контроля версий), по принципу от самых ранних к последним.
Затем мы развернули пакет в среде SAT, где проходило пользовательское тестирование, а затем запланировали выпуск пакета на портале LCS для выпуска в производство.
Вот как мы установили процесс выпуска с использованием среды сборки.
Мы также решили проверять не проекты, а наборы модификаций, загруженные в контроль версий.
Первое обновление облачной версии У нас была облачная версия, поэтому нам нужно было регулярно обновляться.
Первым обновлением стал переход с версии 7.3 на версию 8.0. Это заняло около двух недель.
Главные проблемы мы, конечно, создали себе, но и себя выиграли:
- Мы не сразу договорились о правилах наименования стандартных объектов.
В первом обновлении имена наших объектов совпадали с именами объектов в пакете обновления.
- При обновлении облачных сред мы всегда выходили из AOS-машин, иначе процесс обновления не мог быть завершен, пока пользователь был в системе.
- Пакет обновления для производственной среды и среды SAT необходимо было объединить с пакетом модели.
Мы даже можем выпустить релиз одновременно с обновлением, главное, чтобы билд, SAT и прод были одной версии.
Процесс обновления заключается в загрузке пакета обновления на портале lcs. Первыми обновляются DevBox и тест, затем обновляется сборка, последними - SAT и так далее.
Результаты всего первого проекта
- Мы накопили опыт построения архитектуры приложений D365.
- Мы разработали новый подход к проверке кода.
- Мы сделали регламент переноса баз данных на DevBox (в D365 важно проводить первоначальное тестирование на DevBox, а теперь даже разработчиков тестируем на DevBox).
- Написали регламент ведения разработки в D365.
- Научились разрабатывать в облачной среде.
Выстроенные процессы вокруг проекта позволяют довольно легко подключить к нему разработчиков, впервые пишущих для D365. Теги: #ERP-системы #динамика 365 #Axapta
-
Ссылка Из Pdf-Файла
19 Oct, 24 -
Почему Oracle Хочет Купить Sun (Объяснение)
19 Oct, 24 -
Подкаст С Обзором Контента № 01
19 Oct, 24 -
Подарок Админу
19 Oct, 24
