Chart of Accounts (COA) Validation Service 6/11/2012 University at California, Berkeley IS&T, Application Services

Release History

Version Date Comments 1.0 6/11/2012 Original

Contents

Overview......................................................................................................................................................................................2

Adhoc Query ................................................................................................................................. 3

Adhoc File Validation ............................................................................................................... 6

Batch File Validation ................................................................................................................. 9

Message Validation .................................................................................................................. 11

Appendix ...................................................................................................................................... 20

Overview Chart of Accounts (COA) Validation allows users to validate General Ledger chart strings used in financial transactions on the UC Berkeley campus. The string consists of seven accounting fields:

• Business Unit – required and defaults to 10000 • Account - required • Fund Code – not required • Department - required • Program – not required • Chartfield 1 – not required and refers to a project identification • Chartfield 2 – not required

Except for account, these fields may be linked together and represented by a single value named “SpeedType”. So, a user may enter in a SpeedType instead of individual COA fields.

Adhoc Query Introduction There are three different methodologies to validate COA: adhoc query, batch file and through messaging. Adhoc query is used to validate a single COA or SpeedType. Adhoc file validation replaces the GUI client developed in the original COA Validation process. Additionally, you have the ability to batch process files containing COAs. The messaging process supports both synchronous and asynchronous simple HTTP Post/Get integrations.

Validating COA fields or COA String or SpeedType

Here is a description of the screen. The starred fields are required with Business Unit defaulting to 10000. Business Unit is shown as five characters long which is the correct size in BFS. For system compatibility, all integrations support the business unit being either one or five characters long.

Each field has a magnifying glass to support looking up valid values. You can put in a partial value and use the magnifying glass to show you all of the values that match. Use the percent sign (%) as a wild character to expand your results.

As shown on the first half of the page, you can validate either a single COA field value, COA String or a SpeedType. To validate a COA field, just enter the value into the appropriate field.

To validate a COA String, enter the complete COA value in one of three different formats: a string delimited by dashes, commas or position. Whether using a field delimiter or position format, indicate all COA fields either by extending the string with the appropriate delimiter or adding blanks. For instance, if the COA string is delimited by dashes or commas, there must be six dashes or commas in the string. As an example of that, a COA string that does not need Program, Chartfield 1 and Chartfield 2 would be entered in as 10000-56130-18083-12663---. A position COA string that may not require all COA fields may be entered as 156130697491224140 IMBKR. When you tab out of COA String, the COA fields populate.

When you wish to check a SpeedType, enter it in and choose the magnifying glass to validate it. When the SpeedType is found, the COA fields associated with it will be automatically populated. From here you can if you wish, you can enter in an Account number and continue to validate the complete COA.

Validating a COA

Once entering all values, just choose the Validate button. Use the Clear button if you wish to clear out all the fields. Validation results are found in the long box above the Load File Advanced Options bar. A successful validation will automatically update the COA String value.

An example of a validation is shown below.

Validation process defaults

The validation process is designed to validate based on a set of options. Except for Adhoc query, these options can be configured before validating a file or processing a message. The options are explained below:

Validate COA Fields – validate that the individual fields (i.e. account, fund code, department, etc.) are currently active. This is the default.

Validate Until Error – validate a COA and as soon as there is an error, stop validating this COA. By default, this is unchecked because we would like to see all of the errors associated with a COA.

Validate Grant Funds – validate a COA which has a fund-related grant. Ensure that these funds have not expired. If they have, show a warning message. This is the default.

Show Errors Only – validate a set of COAs and show only those that have errors and/or warnings. So, the result of processing a set of COAs would not include those that are successful. This is the default.

Validate Unique Distributions – validate a set of COAs associated with accounting header/line structure and ensure that each line has a unique set of distribution COAs. This feature is only applicable when you have specific rules associated with a header/line business object (i.e. requisition, purchase order, invoice, etc.). A header, line and distribution value must be populated in the file or message being processed. By default, this is unchecked.

The default options for Adhoc query that cannot be changed are the following: Validate COA Fields and Validate Grant Funds.

Adhoc File Validation Introduction As was mentioned in the preceding section, you can load and validate a COA file either in adhoc or batch mode. When you view the page, the adhoc file validation sections are collapsed.

To view the options, just choose the arrow in front of Load File Advanced Options. (The second bar will open when there are results to show.)

Setting validation process options The default options for Adhoc File Validation are almost the same as for Adhoc Query and are the following: Validate COA Fields, Validate Grant Funds and Show Errors Only. If you desire, you may change them before choosing the Load and Validate COA File button. Descriptions of these options are mentioned in Validation Process Defaults.

File format options There are two file formats: fixed position and comma-delimited (csv). Below is the fixed position.

Field Starting Position Length Business Unit 1 1 Account 2 5 Fund Code 7 5 Department 12 5 Program 17 2 Space 19 1 Chartfield 1 20 6 Chartfield 2 26 5 Header 31 8 Line 39 5 Distribution 45 5

For example: 151010074272459544 JCSUPPJCOPP (Only the first 30 characters are required when you do not choose Validate Unique Distribution. The rest of the line is ignored. This is compatible with the original COA Validation process.)

Below is the comma-delimited position format (field values separated by a comma).

Field Position Business Unit 1 Account 2 Fund Code 3 Department 4 Program 5 Chartfield 1 6 Chartfield 2 7 Header 8 Line 9 Distribution 10 For example: 10000,51033,10696,30400,68,,,0,0,0 (the last column, distribution, should not have a comma)

The process automatically determines which format is being used.

You may notice that Business Unit is one character in the fixed position format and five characters in the comma delimited format. Business Unit can only be one character in the fixed position format for backward compatibility. But the comma-delimited position accepts either one or five characters.

We recommend moving towards the comma-delimited position format because it is not constricted by length so in the future, adding new COAs fields or perhaps lengthening existing fields will be much easier to accommodate.

Validating a COA file Once you choose your options, just choose the Load and Validate COA File. A second window will pop up and allow you to choose a file. The results will appear in the grid below.

On the top bar (shown above) next to View All there is a checkered box . Choosing this box will allow you to download the results in an Excel spreadsheet for your convenience. Also, choosing any of the column headings will allow you to sort the results by whichever heading you choose.

An example of a validation is shown below.

Batch File Validation Introduction BFS (Berkeley Financial System) supports the ability to schedule a job. Batch File Validation is a job that can be scheduled to process a COA file. To create a job, a functional user must have security privileges to enter in the parameters associated with this job. Setting up a Batch File Validation is described in this section.

BFS file server To batch process a file, users copy files over to specifically named directories on BFS’s FTP file server. In order to get access to the file server, please contact the BFS Technical Team. The directory to copy a COA Validation file will either be “<server>\UCB\COA\IN” or ”<server>\<source>\COA\IN” depending on whether or not there is a security requirement for a department (“source”) to have its own directory. The UCB directory is available and open to all departments.

BFS batch process To find out the current schedule of this batch process, contact the BFS Technical Team.

When the process runs, it retrieves the file from the file server, processes it and sends an email notification of its results. Only those files that have been processed are deleted from the file server.

To set up a job, a run control must be created. An example of a run control record is below.

In this run control, the Law Library is using the common UCB directory. If they had chosen the starting directory to be <Source>, then they would be using their own directory, “LAW”. The name of their batch file is unique to LAW and allows them to include a date and/or time value if they desire after the file prefix of “coaLAW”. Also, their file is a comma delimited file (csv). By convention, a position file name extension would likely have an extension of “txt”. (Please note that file extensions must be in lower case.)

As with the adhoc file validation process, you choose the validation options.

Lastly, an email address (individual@berkeley.edu or <list>@lists.berkeley.edu) is entered.

Message Validation Introduction BFS (Berkeley Financial System) supports the ability to publish and subscribe to XML messages by performing either a HTTP post OR HTTP get using PeopleSoft Integration Broker. This is a simplified method of sending an XML message between heterogeneous systems. Instead of supporting any specific protocol, the generic PeopleSoft Integration Broker envelope is used to wrap the XML message. This envelope along with its URL is shown below.

(URLs starting with bfs.is.berkeley.edu are examples; standard Berkeley SOA URLs start with apis.berkeley.edu.)

http://bfs.is.berkeley.edu/PSIGW/HttpListeningConnector

<?xml version="1.0"?> <IBRequest> <ExternalOperationName>ValidateCOA.v1</ExternalOperationName> <From><RequestingNode>UC_COA</RequestingNode></From> <ContentSections><ContentSection> <Data><![CDATA[<?xml version="1.0"?>myMessage]]></Data> </ContentSection></ContentSections> </IBRequest>

The contents of the XML message would replace myMessage in CDATA section. The header properties of the XML message are Content-Type: text/xml; charset=UTF8.

Additionally, the information shown above is supported as parameters in a URL (and no envelope):

http://bfs.is.berkeley.edu/PSIGW/HttpListeningConnector?&Operation=ValidateCOA.v1&From=UC_COA

<?xml version="1.0"?>

Instead of embedding the XML message, it would be posted to this URL. This URL is further condensed into the standard Berkeley’s SOA URL so that you only need apis.berkeley.edu/coa. (Use apis.berkeley.edu/coa-ts for testing.) Instead of the generic envelope, all examples are shown using the simpler standard Berkeley SOA URL.

Two methodologies are supported: synchronous and asynchronous. The synchronous method expects the external system to execute a HTTP Post request and will send back a response. The asynchronous method has two steps. First, the external system executes a HTTP Post request and response only with a return code of 200. Second to receive the message contents, the external system executes a second HTTP Post request and receives the actual results from the initial request.

Both methodologies use the same XML message structure which is described in the next section.

COA validation XML message COA validation XML message consists of two parts: the validation options (UC_COA_PARM) and the COA strings to validate (UC_COA_CHK). The validation options are mostly Boolean value fields. In the table following the XML section is a description of each field (defaults are in bold).

<UC_COA_PARM> <Options class="R"><ValidationMethod>C</ValidationMethod> <ValidateFields>T</ValidateFields><ValidateCombination>T</ValidateCombination> <ValidateGrantFund>T</ValidateGrantFund><ReturnOnlyErrors>T</ReturnOnlyErrors> <StopProcessingAtFirstError>T</StopProcessingAtFirstError> <ValidateUniqueDistributions>F</ValidateUniqueDistributions> <ReturnWarnings>T</ReturnWarnings></Options></UC_COA_PARM>

Field Value Comments ValidationMethod C (custom) R (delivered

PeopleSoft) Two different internal methods

ValidateFields T (true) or F (false) Validate each field ValidateCombination T (true) or F (false) Combination edit ValidateGrantFund T (true) or F (false) Grant Fund validation ReturnOnlyErrors T (true) or F (false) Return only COAs in error StopProcessingAtFirstError T (true) or F (false) Stop processing COA at first error ValidateUniqueDistributions T (true) or F (false) Ensure that all distributions for a

line are unique ReturnWarnings T (true) or F (false) Return Grant Fund warning status

The COA string section can have one or any number of COAs to validate. The only limitation is that the message size must be less than 10 MB. Following the XML below, there is a description of each field (defaults are in bold).

<UC_COA_CHK><COA class="R"><HeaderID/><LineNumber>0</LineNumber> <DistributionNumber>0</DistributionNumber><TodayDate>2012-04-24</TodayDate><BusinessUnit>10000</BusinessUnit><Department>00511</Department><Account>10000</Account><Chartfield1/><Chartfield2/><Program/><FundCode/><SpeedType/><COAString/><IsCOAValid/><HasWarnings/><IsAccountValid/><IsDepartmentValid/><IsChartfield1Valid/><IsChartfield2Valid/><IsFundCodeValid/><IsProgramValid/><IsCombinationValid/><IsSpeedTypeValid/><IsGrantFundValid/><StatusText1/><StatusText2/></COA></UC_COA_CHK>

Field Value Comments Input fields HeaderID Used to Identify COA – uppercase character,

length 8 LineNumber Used to Identify COA – number, length 5 DistributionNumber Used to Identify COA – number, length 5 TodayDate Date used for all validations – value only

present in first COA BusinessUnit 10000 Either 1 character (1,F,J) or 5 characters Department DepartmentDescription Populated in response message Account Chartfield1 Chartfield2 Program FundCode SpeedType COAString Formats: position, dashes, commas Output fields IsCOAValid T (true) or F (false) HasWarnings T (true) or F (false) IsAccountValid T (true) or F (false) IsDepartmentValid T (true) or F (false) IsChartfield1Valid T (true) or F (false) IsChartfield2Valid T (true) or F (false) IsFundCodeValid T (true) or F (false) IsProgramValid T (true) or F (false) IsCombinationValid T (true) or F (false) IsSpeedTypeValid T (true) or F (false) IsGrantFundValid T (true) or F (false) StatusText1 Status error description StatusText2 Status warning description

Use HeaderID, LineNumber and DistributionNumber to uniquely identify a COA string. If you only need one field to uniquely identify your COA string then populate HeaderID with that value and set LineNumber and DistributionNumber to 1.

Synchronous COA validation This method involves a single HTTP post to BFS Integration Broker connector and returns with the validation results.

There are three techniques available to support COA Validation and are described below:

• Singleton COA String Validation – a single COA String with default validation options. • Multiple COA String Validations – one or more COA Strings or SpeedTypes with optionally

setting validation options. • COA Field Validations – one or more sets of COA fields with optionally setting validation

options.

Singleton COA String validation

Use this method to validate a single COA String using the default validation options. Given a URL, you add the COA String as the value to the parameter “COA”, post an empty XML message and receive an XML response message.

URL: apis.berkeley.edu/coa

Add parameter to end of URL:

?COA=156130944041152340 EHFEXPEHDPT

Parameter may be formatted as position, with dashes or commas: COA=1-56130-94404-11523-40-EHFEXP-EHDPT COA=1,56130,94404,11523,40,EHFEXP,EHDPT

XML Request:

<?xml version='1.0'?>

Success Response:

<?xml version='1.0'?> <ValidateCOAResponse></ValidateCOAResponse>

Error Response:

To determine status, query either IsCOAValid equal to “F” or the value in StatusText1.

<?xml version='1.0'?> <ValidateCOAResponse> <UC_COA_CHK><COA class="R"> <HeaderID></HeaderID><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumber><TodayDate>2012-05-08</TodayDate> <BusinessUnit>10000</BusinessUnit><Department>11523</Department> <DepartmentDescription>EHEEC EO Chair Discretion</DepartmentDescription> <Account>96130</Account><Chartfield1>EHFEXP</Chartfield1><Chartfield2>EHDPT </Chartfield2><Program>40</Program><FundCode>54404</FundCode><SpeedType> </SpeedType><COAString>196130544041152340 EHFEXPEHDPT</COAString> <IsCOAValid>F</IsCOAValid><HasWarnings>F</HasWarnings><IsAccountValid>F </IsAccountValid><IsDepartmentValid>T</IsDepartmentValid><IsChartfield1Valid>T </IsChartfield1Valid><IsChartfield2Valid>T</IsChartfield2Valid><IsFundCodeValid>T </IsFundCodeValid><IsProgramValid>T</IsProgramValid><IsCombinationValid>T </IsCombinationValid><IsSpeedTypeValid>T</IsSpeedTypeValid><IsGrantFundValid>T </IsGrantFundValid><StatusText1>Failure: Invalid Account</StatusText1><StatusText2> </StatusText2></COA></UC_COA_CHK> </ValidateCOAResponse>

Multiple COA String validations

Use this method to validate one or more COA Strings or SpeedTypes and optionally setting validation options. Given a URL, you build a request XML message and receive an XML response message.

URL: apis.berkeley.edu/coa

XML Request:

Do NOT mix formats (position, dashes, commas) in a request – use a single COA String format in a request.

<?xml version='1.0'?> <ValidateCOARequest> <UC_COA_CHK><COA class="R"> <COAString>156130053973116044 CIDV01CIGEN</COAString></COA></UC_COA_CHK> <UC_COA_CHK><COA class="R"> <COAString>156130612003149062</COAString></COA></UC_COA_CHK> </ValidateCOARequest>

Or

<?xml version='1.0'?> <ValidateCOARequest> <UC_COA_PARM><Option class=”R”><ValidateGrantFund>F</ValidateGrantFund></Option> </UC_COA_PARM><UC_COA_CHK><COA class="R"> <COAString>10000-56130-05397-31160-44-CIDV01-CIGEN</COAString> </COA></UC_COA_CHK> <UC_COA_CHK><COA class="R"> <COAString>10000-56130-61200-31490-62--</COAString></COA></UC_COA_CHK> </ValidateCOARequest>

Or

<?xml version='1.0'?> <ValidateCOARequest> <UC_COA_CHK><COA class="R"> <SpeedType>22108OPERS</SpeedType></COA></UC_COA_CHK> <UC_COA_CHK><COA class="R"> <Account>10000</Account> <SpeedType>12248NK1R1</SpeedType></COA></UC_COA_CHK> </ValidateCOARequest>

Success Response (both COA Strings are successful):

<?xml version='1.0'?> <ValidateCOAResponse></ValidateCOAResponse>

Error Response (both COA Strings are unsuccessful):

<?xml version="1.0"?> <ValidateCOAResponse> <UC_COA_CHK><COA class="R"> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumber> <TodayDate>2012-05-09</TodayDate><BusinessUnit>10000</BusinessUnit> <Department>31160</Department><DepartmentDescription>CITRS Operating Funds </DepartmentDescription><Account>56130</Account><Chartfield1>10096B </Chartfield1><Chartfield2>CIGEN</Chartfield2><Program>44</Program><FundCode> 05397</FundCode><SpeedType/><COAString>156130053973116044 10096BCIGEN </COAString><IsCOAValid>F</IsCOAValid> <HasWarnings>F</HasWarnings><IsAccountValid>T</IsAccountValid> <IsDepartmentValid>T</IsDepartmentValid><IsChartfield1Valid>T</IsChartfield1Valid> <IsChartfield2Valid>T</IsChartfield2Valid><IsFundCodeValid>T</IsFundCodeValid> <IsProgramValid>T</IsProgramValid><IsCombinationValid>F</IsCombinationValid> <IsSpeedTypeValid>T</IsSpeedTypeValid><IsGrantFundValid>T</IsGrantFundValid> <StatusText1>Failure: Invalid combination(CF1_FUND/CF1_FUND)</StatusText1><StatusText2/> </COA></UC_COA_CHK> <UC_COA_CHK><COA class="R"> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumber><TodayDate/><BusinessUnit>10000</BusinessUnit><Department>31490 </Department><DepartmentDescription> UYOLI OLLI General Operations </DepartmentDescription><Account>56130</Account><Chartfield1/><Chartfield2/> <Program/><FundCode>61200</FundCode><SpeedType/> <COAString>1561306120031490</COAString> <IsCOAValid>F</IsCOAValid> <HasWarnings>F</HasWarnings><IsAccountValid>T</IsAccountValid> <IsDepartmentValid>T</IsDepartmentValid><IsChartfield1Valid>T</IsChartfield1Valid> <IsChartfield2Valid>T</IsChartfield2Valid><IsFundCodeValid>T</IsFundCodeValid> <IsProgramValid>T</IsProgramValid><IsCombinationValid>F</IsCombinationValid> <IsSpeedTypeValid>T</IsSpeedTypeValid><IsGrantFundValid>T</IsGrantFundValid> <StatusText1>Failure: Invalid combination(ACT_PG/ACT_PG)</StatusText1> <StatusText2/></COA></UC_COA_CHK> </ValidateCOAResponse>

COA Field validations

Use this method to validate one or more sets of COA fields optionally setting validation options. Given a URL, you build a request XML message and receive an XML response message.

URL: apis.berkeley.edu/coa

XML Request (single COA Fields request):

<?xml version="1.0"?> <ValidateCOARequest> <UC_COA_CHK><COA class="R"> <BusinessUnit>10000</BusinessUnit><Department>12940</Department> <Account>16190</Account><Chartfield1>LRTLAB</Chartfield1><Program>44</Program><FundCode>91727</FundCode></COA></UC_COA_CHK> </ValidateCOARequest>

XML Response:

<?xml version='1.0'?> <ValidateCOAResponse <UC_COA_CHK><COA class="R"> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumber><TodayDate>2012-05-09</TodayDate><BusinessUnit>10000</BusinessUnit> <Department>12940</Department><DepartmentDescription>LRTOW Townsend Ctr Gen Ops</DepartmentDescription><Account>16190</Account><Chartfield1>LRTLAB </Chartfield1><Chartfield2/><Program>44</Program><FundCode>91727</FundCode> <SpeedType/><COAString/><IsCOAValid>F</IsCOAValid> <HasWarnings>T</HasWarnings><IsAccountValid>F</IsAccountValid> <IsDepartmentValid>T</IsDepartmentValid><IsChartfield1Valid>T</IsChartfield1Valid> <IsChartfield2Valid>T</IsChartfield2Valid><IsFundCodeValid>T</IsFundCodeValid> <IsProgramValid>T</IsProgramValid><IsCombinationValid>T</IsCombinationValid> <IsSpeedTypeValid>T</IsSpeedTypeValid><IsGrantFundValid>F</IsGrantFundValid> <StatusText1>Failure: Invalid account</StatusText1> <StatusText2>, Fund expired within past 90 days contact Tajal Patel(642-8147) tkpatel@berkeley.edu</StatusText2></COA></UC_COA_CHK> </ValidateCOAResponse>

XML Request (multiple COA Fields request):

<?xml version="1.0"?> <ValidateCOARequest> <UC_COA_CHK><COA class="R"> <BusinessUnit>10000</BusinessUnit><Department>12940</Department> <Account>16190</Account><Chartfield1>LRTLAB</Chartfield1><Program>44</Program><FundCode>91727</FundCode></COA></UC_COA_CHK>

<UC_COA_CHK><COA class="R"> <BusinessUnit>10000</BusinessUnit><Department>10000</Department> <Account>10000</Account></COA></UC_COA_CHK> </ValidateCOARequest>

XML Response (only one is unsuccessful – returns only unsuccessful response):

<?xml version='1.0'?> <ValidateCOAResponse> <UC_COA_CHK><COA class="R"> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumber><TodayDate>2012-05-09</TodayDate><BusinessUnit>10000</BusinessUnit> <Department>12940</Department><DepartmentDescription>LRTOW Townsend Ctr Gen Ops</DepartmentDescription><Account>16190</Account> <Chartfield1>LRTLAB</Chartfield1><Chartfield2/><Program>44</Program> <FundCode>91727</FundCode><SpeedType/><COAString/> <IsCOAValid>F</IsCOAValid> <HasWarnings>T</HasWarnings><IsAccountValid>F</IsAccountValid> <IsDepartmentValid>T</IsDepartmentValid><IsChartfield1Valid>T </IsChartfield1Valid><IsChartfield2Valid>T</IsChartfield2Valid> <IsFundCodeValid>T</IsFundCodeVaid><IsProgramValid>T</IsProgramValid> <IsCombinationValid>T</IsCombinationValid> <IsSpeedTypeValid>T</IsSpeedTypeValid> <IsGrantFundValid>F</IsGrantFundValid> <StatusText1>Failure: Invalid account</StatusText1> <StatusText2>, Fund expired within past 90 days contact Tajal Patel(642-8147) tkpatel@berkeley.edu</StatusText2></COA></UC_COA_CHK> </ValidateCOAResponse>

XML Request (multiple COA Fields request with options set):

<?xml version="1.0"?> <ValidateCOARequest> <ValidateCOARequest> <UC_COA_PARM><Options class="R"> <ValidateFields>T</ValidateFields><ValidateGrantFund>F</ValidateGrantFund> <ReturnOnlyErrors>F</ReturnOnlyErrors></Options></UC_COA_PARM> <UC_COA_CHK><COA class="R"> <BusinessUnit>10000</BusinessUnit><Department>12940</Department> <Account>16190</Account><Chartfield1>LRTLAB</Chartfield1><Program>44</Program><FundCode>91727</FundCode></COA></UC_COA_CHK> <UC_COA_CHK><COA class="R"> <BusinessUnit>10000</BusinessUnit><Department>12940</Department> <Account>10000</Account></COA></UC_COA_CHK> </ValidateCOARequest>

XML Response (one is unsuccessful, one is successful - returns both due to options):

<?xml version='1.0'?> <ValidateCOAResponse> <UC_COA_CHK><COA class="R"> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumber><TodayDate>2012-05-09</TodayDate><BusinessUnit>10000</BusinessUnit> <Department>12940</Department><DepartmentDescription>LRTOW Townsend Ctr Gen Ops</DepartmentDescription><Account>16190</Account> <Chartfield1>LRTLAB</Chartfield1><Chartfield2/><Program>44</Program> <FundCode>91727</FundCode><SpeedType/><COAString/> <IsCOAValid>F</IsCOAValid> <HasWarnings>T</HasWarnings><IsAccountValid>F</IsAccountValid> <IsDepartmentValid>T</IsDepartmentValid><IsChartfield1Valid>T</IsChartfield1Valid> <IsChartfield2Valid>T</IsChartfield2Valid><IsFundCodeValid>T</IsFundCodeValid> <IsProgramValid>T</IsProgramValid><IsCombinationValid>T</IsCombinationValid> <IsSpeedTypeValid>T</IsSpeedTypeValid><IsGrantFundValid>F</IsGrantFundValid> <StatusText1>Failure: Invalid account</StatusText1><StatusText2/> </COA></UC_COA_CHK> <UC_COA_CHK><COA class="R"> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumber><<TodayDate/><BusinessUnit>10000</BusinessUnit> <Department>12940</Department><DepartmentDescription>LRTOW Townsend Ctr Gen Ops</DepartmentDescription><Account>10000</Account><Chartfield1/> <Chartfield2/><Program/><FundCode/><SpeedType/><COAString/> <IsCOAValid>T</IsCOAValid> <HasWarnings>T</HasWarnings><IsAccountValid>T</IsAccountValid> <IsDepartmentValid>T</IsDepartmentValid><IsChartfield1Valid>T</IsChartfield1Valid> <IsChartfield2Valid>T</IsChartfield2Valid><IsFundCodeValid>T</IsFundCodeValid> <IsProgramValid>T</IsProgramValid><IsCombinationValid>T</IsCombinationValid> <IsSpeedTypeValid>T</IsSpeedTypeValid><IsGrantFundValid>T</IsGrantFundValid> <StatusText1>sSuccess</StatusText1><StatusText2/></COA></UC_COA_CHK> </ValidateCOAResponse>

Asynchronous COA validation This method involves two HTTP posts to BFS Integration Broker connector. The first post returns the HTTP return code (zero if successful, non-zero if not successful). The second post is a request for the validation results.

The first post is the ValidateCOARequest message as described in the previous section. Each COA must be uniquely identified using all three fields: HeaderID, LineNumber and DistributionNumber.

The second post is the ValidateCOAResponse message. This message is embedded in Integration Broker Request envelope and must have the same values in HeaderID, LineNumber and DistributionNumber that were used to identify each COA. The response message contains the results of each COA validation.

Summary for XML messaging In summary, there are only two messages used to support COA validation messaging: ValidateCOARequest and ValidateCOAResponse. They can be used in both synchronous and asynchronous protocol.

Also, there are only two XML structures used to support COA validation messaging: UC_COA_PARM and UC_COA_CHK. These structures are optional along with all of their elements.

The design of this web service is optimally flexible because it supports basic protocols and all artifacts are consistent and optional.

Appendix

Maintaining this document Documentation is stored in the database with the file name, 10000_COA_HELP.pdf . To modify this document, you will need to have the UC_COA_ADMIN role assigned to your user profile in BFS. Once assigned, go to this page and download its corresponding Microsoft Word document by choosing GetHelpDOC button. After saving the file as COA_HELP.docx, you will be able to revise it. From Word, generate the new PDF file as COA_HELP.pdf. To upload the new DOCX and PDF versions, choose UpdateHelpDOC and UpdateHelpPDF buttons. The update process prefixes the file name with “10000_”.

If you have UC_COA_ADMIN assigned to your user profile, the page will look like this: