Работа с договорами в Ax2012

В Dynamics AX 2009 для ведения договоров использовались, так называемые, «Общие заказы» (Blanket Orders). Общие заказы помогают организации работать более эффективно, снижая накладные расходы на транзакции. Они эффективно фиксируют согласованную цену и сокращают время, затрачиваемое на ввод заказов. Создавая большие общие заказы и периодически выпуская объемы заказов, организации могут работать с меньшими операционными издержками. Без использования общих заказов пользователи должны будут создавать индивидуальные заказы на услуги и/или продукты, которые будут повторять заказы по согласованной цене. Функциональные возможности и структура Dynamics AX сильно изменились с 2009 по 2012 версии, включая, помимо прочего, возможности в рамках заказов.

В AX 2009 общие заказы по сути рассматриваются как другой «тип» заказа на продажу или заказа на покупку. Такой подход ограничивает гибкость, функциональность и уменьшает видимость. Общие заказы допускают только покупку или продажу определенного товара, определенного количества и по определенной цене. Такая функциональность ограничивает организацию от создания контрактов ценообразования для конкретных объемов.

Agreement Framework

«Agreement Framework» в Dynamics AX 2012 заменил модель данных и функциональные возможности, которые обеспечивались общими заказами в АХ 2009. Эта новая инфраструктура предлагает пользователям Dynamics AX широкий набор инструментов применения и отслеживания коммерческих соглашений между компанией, ее клиентами и поставщиками. Соглашения могут касаться покупки или продажи определенного количества или объема определенного товара. Соглашения могут также относиться к ряду предметов в пределах определенной категории, к которым применяется специальная политика для установления согласованной цены, для торговли товарами или услугами.

Новая физическая модель данных базируется на расширенных технологиях, которые доступны в AX 2012 для моделирования данных. Физическая модель данных полностью отделяет данные «Agreement Framework» от заказов общего назначения.

Новая инфраструктура по работе с соглашениями включает следующее:

• Установление договорного обязательства продавать или покупать определенное количество или количество определенного товара, определенной категории или любой комбинации товара и категорий.
• Обеспечение соблюдения ценовых соглашений для покупок или продаж, которые являются предметом соглашения.
• Отслеживание покупок и продаж, чтобы видеть были ли выполнены договорные обязательства.
• Включение обязательств, основанных на объеме.
• Управление обязательствами на основании категорий.
• При создании заказов применять обязательства, которые система автоматически предлагает.
• Получение чистой физической модели данных, которая не включает нерелевантные данные и походящей для дальнейшего расширения и настройки.

В AX 2009 функциональность общего заказа была интегрирована в подсистемы общего назначения. Другими словами, общие заказы считались другим типом заказа на продажу или заказа на покупку. Из-за этого подхода, структура данных, которая использовались общими заказами, не была оптимальной. Такой подход также требовал громоздкой организации кода, который должен был поддерживать иерархию классов вслед за таблицами данных, и постоянное условное отклонение кода, основанное на типе данных, которые хранились в одной таблице данных.

Как результат, общие заказа предоставляли ограниченные возможности для обеспечения соблюдения цен на товары, которые продавались и покупались в соответствии с конкретным общим заказом. Кроме того, возможности отслеживать определенный общий заказ практически не существовало.

Функциональность общего заказа также была ограничена, потому что он обрабатывал только количества определенных товаров на складе и не давал возможности устанавливать договорные обязательства по продаже или покупке определенного объема товаров или услуг в пределах определенной категории.

Физическая модель данных

В Microsoft Dynamics AX 2012 модель данных Agreement Framework была разработана таким образом, чтобы полностью отделить ее от модели данных общего назначения. Такое разделение позволяет объектам Agreement Framework создать оптимальную структуру данных, в которой объекты, хранящиеся в базе данных, не должны иметь свойства, не связанные с соглашениями.

Физическая модель данных также была разработана для использования новой функции наследования таблиц AX 2012, а также для реализации всех требуемых подтипов данных и поведенческих отклонений этих подтипов в качестве лестницы наследования таблиц. Эти конструктивные особенности инкапсулируют как связанные с данными, так и функциональные специализации в одном объекте — таблицах данных Dynamics AX. В результате иерархия классов больше не должна поддерживаться за используемыми таблицами данных.

Физическая модель данных основана на принципах нормализации данных и контролируемой денормализации данных (в нескольких обоснованных сценариях, по соображениям производительности). Следовательно, физическая модель данных Agreement Framework обеспечивает логичный и сбалансированный способ хранения и доступа к данным.

Основные объекты

Изображение выше показывает первое важное отличие между физической моделью данных AX 2012 и моделью данных общих заказов AX 2009: сущности, связанные с Agreement Framework, не используют повторно таблицы общих заказов Dynamics AX (SalesTable, SalesLine, PurchTable и PurchLine) и сохраняют все свои данные в новых выделенных таблицах. Эти новые таблицы используют существующие соглашения об именах Dynamics AX. Поэтому имя каждой новой таблицы начинается с префикса Agreement, SalesAgreement или PurchaseAgreement.

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

Например, таблицы SalesAgreementHeader и PurchAgreementHeader, которые представляют договора в модулях «Продажи и макретинг» и «Закупки и источники» («Sales and marketing» и «Procurement and sourcing») соответсвенно наследуются от одной и той же базовой таблицы «AgreementHeader».

Хотя подробное объяснение функции наследования таблиц Dynamics AX 2012 выходит за рамки темы, некоторые из основных функций следующие:

• Наследование таблиц похоже на «классическую» концепцию наследования в ООП. Это позволяет дочерним объектам специализироваться или расширять общий базовый набор свойств, наследуемый от родительского объекта. Следовательно, все свойства объекта «AgreementHeader» (например, столбцы Currency, AgreementState и DefaultAgreementLineEffectiveDate) применимы к объектам SalesAgreementHeader и PurchaseAgreementHeader. Однако, свойство «CustAccount» применим только для заголовка соглашения модуля «Продажи и макретинг» и поэтому будет объявлено только для объекта «SalesAgreementHeader».
• Наследование таблиц также позволяет специализировать поведение базовой таблицы. Каждый метод базовой таблицы может быть локально перезаписан в унаследованном табличной объекте. (Эта возможность напоминает реализацию виртуальных методов дочерним классом в языках, поддерживающих ООП). Наследование позволяет не только изменить поведение унаследованной таблицы, но также устраняет необходимость поддержки иерархии классов для настройки поведения таблицы в зависимости от типа записи. (Этот шаблон широко использовался в предыдущих версиях Microsoft Dynamics AX для поддержки поведенческих отклонений для записей разных типов, которые хранились в одной таблице.)

Третье важное отличие, это реализация шаблона мягкого удаления для нескольких объектов «Agreement Framework». Мягкое удаление предотвращает физическое удаление из базы данных записей, которые представляли сущности, которые были логически удалены пользователем AX. Обычно сущности, для которых реализован шаблон мягкого удаления содержать свойство «IsDeleted». Например, сущности «AgreementHeader» и «AgreementLine» поддерживают функциональность мягкого удаления и содержат свойство «IsDeleted». Если пользователь удаляет конкретную запись из конкретного соглашения, то соответствующая физическая запись на самом деле не удаляется из базы данных. Вместо этого, строка просто маркируется как удаленная («IsDeleted» устанавливается в истину). В результате, система может распознать записи, которые были удалены и, например, не выводить их на формы, которые отображают все строки соглашения.

Когда запрашиваются данные непосредственно из базы данных или проектируется запрос для приложения, важно знать о сущностях, которые реализуют функцию мягкого удаления и реализовывать условие для поля «IsDeleted» записи.

В заключении, обратите внимание, что «Agreement Framework» использует классический шаблон «Шапка-Строки», точно также как в общих заказах. Таким образом, несколько строк соглашения в Microsoft Dynamics AX 2012 могут быть связаны с одним заголовком соглашения. Это единственное сходство между новой физической моделью данных «Agreement Framework» и моделью данных общих заказов в Dynamics AX 2009.

microsoft