Transactional Document Data Dictionary

The data dictionary configuration for a transactional document looks similar, but has some significant differences from, the data dictionary configuration for maintenance documents. Here, we'll take a look at most all of the data dictionary attributes we can set to configure our document.

The data dictionary is a repository of meta-data about business objects and documents. It's the meta-data which specifically ties everything together - what form attributes should look like, what rules and document authorizers to use, what workflow routing the document should go through.

The basic attributes

The core attributes for the transactional document data dictionary file. All of the data dictionary entries are declared in an XML file, with this general template:

  <bean id="AssetTransferDocument" parent="AssetTransferDocument-parentBean"/>
  <bean id="AssetTransferDocument-parentBean" abstract="true" parent="TransactionalDocumentEntry">  
    <property name="documentTypeName" value="AT"/>
    <property name="documentClass" value="org.kuali.kfs.module.cam.document.AssetTransferDocument"/>
    <property name="businessRulesClass" value="org.kuali.kfs.module.cam.document.validation.impl.AssetTransferDocumentRule"/>
    <property name="documentAuthorizerClass" value="org.kuali.kfs.sys.document.authorization.FinancialSystemTransactionalDocumentAuthorizerBase"/>
    <property name="workflowAttributes">
      <ref bean="AssetTransferDocument-workflowAttributes"/>
    </property>
    <property name="attributes">
      <list>
       ....
      </list>
    </property>

    <property name="defaultExistenceChecks">
      <list>
      .....
      </list>
    </property>

    <property name="relationships">
      <list>
       ....
      </list>
    </property>    
  </bean>

documentClass

This is naturally required: we need to specify which document we are dealing with in the data dictionary file, so we declare the class. Here's how it looks for Asset Transfer:

<property name="documentClass" value="org.kuali.kfs.module.cam.document.AssetTransferDocument"/>

Pretty basic!

The next attributes deal with rules, authorizations, and document types - all of which are covered fully in the Data Dictionary Document Type page.

businessRulesClass

Business rule class here does the validation when events are triggered. For example here the businessRulesClass is AssetTransferDocumentRule which performs the necessary validation which is not configurable. Like validating if financial object sub type indicates if it is eligible for GL offsets or not and similar business rules which are key to this transactional action.

Helpful UI Attributes

While for transactional documents, we do need to create JSP pages for the view, the Kuali Nervous System still allows us to specify some of the look and feel for the JSP page within the document data dictionary. Some of those fields, such as label and help, are covered fully in the Document Data Dictionary page. However, some - such as attributes and header navigation - are very specific to transactional documents.

attributes

Most transactional documents tend not to have associated business object data dictionary files. However, sometimes transactional documents need certain pieces that business object data dictionary files have, specifically attribute lists. Those can be declared in the transactional data dictionary file itself. For instance, org/kuali/kfs/module/cam/document/datadictionary/AssetTransferDocument.xml declares attributes for all the fields available on the AssetTransferDocument BO. Since these are attributes of the document itself and not any related child business objects, the data dictionary has to define them. These are defined just as they would have been in a business object's data dictionary configuration:

  <bean id="AssetTransferDocument-buildingCode" parent="AssetTransferDocument-buildingCode-parentBean"/>

  <bean id="AssetTransferDocument-buildingCode-parentBean" abstract="true" parent="Building-buildingCode">
    <property name="shortLabel" value="Code"/>
    <property name="required" value="false"/>
  </bean>

The documentNumber should NOT be included among these attributes; it is written to the page via the sys:documentOverview tag, as we'll later see, and any attempt to write it out with attributes as well has been known to cause...issues.

Inclusion of attributes in a transactional document configuration is fairly common, even though these configurations are for documents and not business objects.

Special Transactional Document attributes

There are two special tags

allowsCopy

Some transactional documents can be copied directly as new transactional documents. This ability can be turned on or off using this tag. allowsCopy isn't required; it defaults to "false." Of course, it won't work at all unless the class for our transactional document implements the org.kuali.rice.kns.document.Copyable interface.

allowsErrorCorrection

This tag is not required for Transactional Documents. It specifies whether the document can be referred to by an error correcting document, such as the General Error Correction or the Year End General Error Correction.