Архитектура договоров в AX 2012 (Часть 2)

Архитектура договоров в AX 2012 (Часть 2)

Часть 1

Сущности Agreement Classification

На схеме показаны сущности Agreement classification и Agreement Classification Translation.

Предвидя необходимость среди клиентов и партнеров более детальной классификации соглашений, в Agreement Framework была представлена концепция классификации соглашений в Microsoft Dynamics AX 2012. Классификации соглашений предоставляют другое измерение, помимо подтипов «AgreementHeader», которое можно использовать для описания соглашения.

На схеме выше видно, что каждое соглашение в Microsoft Dynamics AX связано с соответствующей классификацией соглашений. Эта связь является обязательной. Соглашения отдельных подтипов могут быть сгруппированы с использованием различных классификаций соглашений, которые предварительно определены в системе.

В настоящее время единственным свойство, которое имеет объект «AgreementClassification», является «Name». Однако свойства могут быть легко расширены с помощью настроек. Связав свойства с сущностью «AgreementClassificationTranslation», пользователи Agreement Framework могут локализовать свойство «Name» для различных языков, которые используются в установке Dynamics AX 2012.

Сущности History

Agreement Framework позволяет пользователям создавать моментальный снимок текущего состояния соглашения в любой момент времени. Этот процесс называется подтверждением соглашений. Система сохраняет эти снимки, которые называются историей соглашений, как отдельные записи в базе данных. Следовательно, постоянное состояние для конкретного соглашения может быть восстановлено системой и доступно пользователю для последующего анализа.

Чтобы включить эту функцию, физическая модель данных Agreement Framework определяет несколько сущностей для ведения истории, которые показаны на рисунке ниже.

Agreement Framework History

Следует отметить несколько важных моментов, связанных с объектами истории физической модели данных.

Первый, явные отношения между историческими и базовыми сущностями устанавливаются только для нескольких сущностей: AgreementHeader, AgreementHeaderHistory, AgreementLine и AgreementLineHistory. Все остальные подобные отношения считались избыточными для модели данных и поэтому не были реализованы.

Также важно обратить внимание на то, что несмотря на очевидное сходство между фрагментом физической модели данных объектов истории и фрагментом физической модели данных для основных объектов, эти два фрагмента значительно отличаются: объекты истории для заголовков и строк соглашения напрямую не реализуют шаблон «Header-Lines». Как видно из схемы выше, нет никакой связи между сущностями «AgreementHeaderHistory» и «AgreementLineHistory».

Эта необычная реализация объектов истории для заголовков и строк соглашения вызвана оптимизацией производительности, которая применяется к физической модели данных Framework соглашения. Логически, каждый экземпляр истории заголовка соглашения содержит несколько экземпляров истории строки соглашения. Однако по соображениям производительности экземпляры «AgreementLineHistory» могут совместно использоваться несколькими экземплярами «AgreementHeaderHistory». Следовательно, явная связь между двумя объектами не может быть установлена физической моделью данных.

Пример

В следующем примере показано, почему это совместное использование важно для производительности. Соглашение содержит 100 строк, и между двумя последовательными снимками, сделанными для этого соглашения, была изменена только одна строка. Если записи истории нельзя разделить между несколькими записями истории заголовков (то есть между несколькими моментальными снимками), необходимо сохранить два идентичных набора из 99 записей истории строк соглашений для неизмененных строк (по одному на каждый моментальный снимок). Такое поведение значительно повлияет на производительность системы.

Вместо этого, когда для соглашения, содержащего только одну измененную строку, берется второй моментальный снимок, то сохраняется только один экземпляр строки истории соглашения. Этот экземпляр представляет только измененную строку. Другие 99 записей не дублируются, но они специально помечаются, чтобы указать, что теперь они принадлежат нескольким снимкам (заголовкам истории). Такое поведение обеспечивается несколькими свойствами, которые определяются как основными, так и историческими объектами. В этом примере сущность «AgreementLine» содержит свойство «isModified», используемое для маркировки строк соглашения, которые были изменены с момента последнего подтверждения пользователем, выполненного пользователем. Кроме того, сущности «AgreementHeaderHistory» и «AgreementLineHistory» содержат свойства «IsModified», «ValidFrom» и «ValidTo», которые используются для определения периода действия для записей истории. Эти свойства контролируются Agreement Framework, который устанавливает или изменяет свойства каждый раз, когда создаются записи истории (в момент, когда пользователь подтверждает соглашение в системе).

Каждый раз, когда состояние для конкретной версии, которая сохраняется в качестве моментального снимка для соглашения, должно быть восстановлено системой, Agreement Framework анализирует интервал между временными метками «ValidFrom» и «ValidTo» записи AgreementHeaderHistory, который соответствует требуемой версии выбранного соглашения. Затем он выбирает только записи «AgreementLineHistory», которые принадлежат этому заголовку и, которые действовали в течение всего периода действия версии заголовка. В результате Agreement Framework может точно воссоздать и представить пользователю любую историческую версию соглашения, для этого нужно только сохранить минимальный набор данных в базе данных.

Связи сущностей Release

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

Чтобы упростить выпуск заказов по соглашениям и предоставить последующую информацию для соглашений, зарегистрированных в системе, физическая модель данных Agreement Framework определяет следующие сущности, как показано ниже: AgreementReleaseHeaderMatch, AgreementLineReleasedLine и ее «теневая история» AgreementLineReleasedLineHistory.

Agreement Framework Release

Если заказ на продажу или покупку содержит хотя бы одну строку, которая добавлена из соглашения, этот заказ называется заказом на выпуск. Для каждого заказа на выпуск существует соответствующая запись в «AgreementReleaseHeaderMatch». Эта запись определяет явную связь между заголовком заказа на выпуск (запись «SalesTable» или «PurchaseTable») и заголовком «AgreementHeader» в системе.

Аналогичный подход используется для установления связи между строкой заказа на выпуск и строкой соглашения. Для каждой строки заказа на выпуск, которая выпускается из соглашения, Agreement Framework создает запись в таблице «AgreementLineReleasedLine». Эта запись явно устанавливает связь между строкой заказа на выпуск (запись «SalesLine» или «PurchLine») и соответствующей строкой соглашения.

Заказы на выпуск

Заказы на выпуск в Dynamics AX 2012 могут смешивать общие строки и строки на выпуск, но все строки на выпуск для одного заказа на выпуск должны относиться к строкам одного и того же соглашения. Другими словами, один заказ на выпуск не может содержать строки на выпуск, которые происходят из разных соглашений.

В отличие от процесса выпуска из общего заказа в Dynamics AX 2009, связь между строкой на выпуск и строкой соглашения в Agreement Framework не является постоянной. Некоторые изменения, которые могут быть внесены в строку на выпуск, могут нарушать условия соответствующей строки соглашения. Однако пользователь может перезаписать условия соглашения (например, выпущенное количество, цена или скидка) и удалить связь между строкой на выпуск и строкой соглашения. В результате на строку на выпуск больше не распространяются условия соглашения. В этом случае строка больше не упоминается как строка на выпуск.

Удаленные связи (записи в таблице AgreementLineReleasedLine) физически не удаляются из базы данных. Вместо этого строки помечаются как удаленные (шаблон мягкого удаления). В соглашении используется этот подход, поскольку он способствует правильному восстановлению истории для любого соглашения в системе.

Для поддержки всех бизнес-сценариев Agreement Framework должен отслеживать связи выпуска на уровне строки для следующих журналов: VendInvoiceTrans, CustInvoiceTrans и ProjInvoiceItem. Каждый раз, когда запись в этих журналах создается из строки на выпуск, создается соответствующий экземпляр AgreementLineReleasedLine. Строка AgreementLineReleasedLine определить связь между созданной записью журнала и строкой соглашения.

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

microsoft

Comments

So empty here ... leave a comment!

Добавить комментарий

Sidebar



X

Ищешь разработчика 1С?
Оставь заявку на консультацию

X

Ищешь разработчика?