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

Transcription

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

2 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 Appendix... 20

3 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 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.

4 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 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.

5 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 A position COA string that may not require all COA fields may be entered as 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.

6 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.

7 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 Chartfield Header 31 8 Line 39 5 Distribution 45 5

8 For example: 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.

9

10 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 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.

11 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 address ([email protected] or <list>@lists.berkeley.edu) is entered.

12 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.) <?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): <?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.

13 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 Two different internal methods PeopleSoft) 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). <HeaderID/><LineNumber>0</LineNumber> <DistributionNumber>0</DistributionNumber><TodayDate> </TodayDate><BusinessUnit>10000</BusinessUnit><Department>00511</Department><Acco unt>10000</account><chartfield1/><chartfield2/><program/><fundcode/><speedtype/><co AString/><IsCOAValid/><HasWarnings/><IsAccountValid/><IsDepartmentValid/><IsChartfield1V alid/><ischartfield2valid/><isfundcodevalid/><isprogramvalid/><iscombinationvalid/><isspee dtypevalid/><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

14 present in first COA BusinessUnit 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 HasWarnings IsAccountValid IsDepartmentValid IsChartfield1Valid IsChartfield2Valid IsFundCodeValid IsProgramValid IsCombinationValid IsSpeedTypeValid IsGrantFundValid StatusText1 StatusText2 T (true) or F (false) T (true) or F (false) T (true) or F (false) T (true) or F (false) T (true) or F (false) T (true) or F (false) T (true) or F (false) T (true) or F (false) T (true) or F (false) T (true) or F (false) T (true) or F (false) Status error description 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.

15 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 XML Request: Add parameter to end of URL:?COA= EHFEXPEHDPT Parameter may be formatted as position, with dashes or commas: COA= EHFEXP-EHDPT COA=1,56130,94404,11523,40,EHFEXP,EHDPT <?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> <HeaderID></HeaderID><LineNumber>0</LineNumber><DistributionNumber>0</Distrib utionnumber><todaydate> </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> 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>

16 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> <COAString> CIDV01CIGEN</COAString></COA></UC_COA_CHK> <COAString> </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> <COAString> CIDV01-CIGEN</COAString> </COA></UC_COA_CHK> <COAString> </COAString></COA></UC_COA_CHK> </ValidateCOARequest> Or <?xml version='1.0'?> <ValidateCOARequest> <SpeedType>22108OPERS</SpeedType></COA></UC_COA_CHK> <Account>10000</Account> <SpeedType>12248NK1R1</SpeedType></COA></UC_COA_CHK> </ValidateCOARequest> Success Response (both COA Strings are successful):

17 <?xml version='1.0'?> <ValidateCOAResponse></ValidateCOAResponse> Error Response (both COA Strings are unsuccessful): <?xml version="1.0"?> <ValidateCOAResponse> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumbe r> <TodayDate> </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> BCIGEN </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> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumbe r><todaydate/><businessunit>10000</businessunit><department>31490 </Department><DepartmentDescription> UYOLI OLLI General Operations </DepartmentDescription><Account>56130</Account><Chartfield1/><Chartfield2/> <Program/><FundCode>61200</FundCode><SpeedType/> <COAString> </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>

18 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> <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 <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumbe r><todaydate> </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( ) [email protected]</statustext2></coa></uc_coa_chk> </ValidateCOAResponse> XML Request (multiple COA Fields request): <?xml version="1.0"?> <ValidateCOARequest> <BusinessUnit>10000</BusinessUnit><Department>12940</Department> <Account>16190</Account><Chartfield1>LRTLAB</Chartfield1><Program>44</Program> <FundCode>91727</FundCode></COA></UC_COA_CHK>

19 <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> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</Distributio nnumber><todaydate> </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( ) </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> <BusinessUnit>10000</BusinessUnit><Department>12940</Department> <Account>16190</Account><Chartfield1>LRTLAB</Chartfield1><Program>44</P rogram><fundcode>91727</fundcode></coa></uc_coa_chk> <BusinessUnit>10000</BusinessUnit><Department>12940</Department> <Account>10000</Account></COA></UC_COA_CHK> </ValidateCOARequest>

20 XML Response (one is unsuccessful, one is successful - returns both due to options): <?xml version='1.0'?> <ValidateCOAResponse> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumbe r><todaydate> </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> <HeaderID/><LineNumber>0</LineNumber><DistributionNumber>0</DistributionNumbe r><<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>

21 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.

22 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: