GAX General Design Document



General System Design

AdvantageME Customer: VCC Customer (VCC)

|Document Review and Change Summary |

|Version/ |Brief Summary of Changes From Prior Version |Changed By |Document |

|Review Date | | |Reviewers |

|Version 1.0 |Original |Joo Kook | |

|12/05/11 | | | |

|Version 1.1 |Removed VCC_AD_1099 section and updated attributes per discussion with Maine |Joo Kook |Utkarsh Pansuriya |

|12/07/11 | | | |

|Version 1.2 |Updated DOC_CAT, DOC_TYP, DOC_VERS_NO, DFLT_AD_TYP and AD_AUTO_GEN_FL data types |Joo Kook | |

|12/13/11 |Updated sample XML to include DOC_REC_DT_DC and EXT_DOC_DSCR fields | | |

|Version 1.3 |Updated attributes notes section to require capitalization for alphabetic values |Joo Kook | |

| | | | |

|12/19/11 | | | |

|Version 1.4 |Updated VCC_DOC_VCUST with optional fields INT_ACCT_FL and ALIAS_NM |Joo Kook | |

| |Updated VCC_DOC_AD with optional fields CN_AUTO_GEN_FL, PRIN_CNTAC, ACORSPD_TYP, EMAIL_AD, and | | |

|1/4/2012 |CNTAC_PH_NO | | |

|1/12/2012 |Updated Conditional Requirements, Example of Canadian Province ZIP, and Notes for INT_ACCT_FL |Phillip Platt | |

Table of Contents

1. Overview 3

1.1. Document Definitions and Naming Conventions 3

1.2. Document Usage 5

1.3. Logical Document Component Structure 6

AdvantageME VCC Document Structure 6

2. Publishable Specification 7

2.1. Transaction Layout: VCC 7

2.1.1 Document Prefixes 8

2.1.2 Data Repository 9

2.1.3 DOC_ID Standard 10

2.1.4 VCC AMS_DOC_EXPORT_XML_FILE root element attributes 10

2.1.5 VCC AMS_DOCUMENT root element attributes 11

2.1.6 VCC Document Component: VCC_DOC_HDR 11

2.1.7 VCC Document Component: VCC_DOC_VCUST 13

2.1.8 VCC Document Component: VCC_DOC_AD 15

2.1.9 VCC Document Component: VCC_DOC_CUSTACC 16

2.1.10 VCC Document Component: VCC_DOC_CERT 17

2.1.11 VCC Customer XML Example 18

Overview

1 Document Definitions and Naming Conventions

This section describes/defines the DTD naming conventions applied in this document.

Transaction Layout Definitions

• Attribute – The name of the data element in the database, as well as the name of the XML tag.

• Caption – The label on the User Interface that defines the data element.

• Description – A textual description of the data element.

• R/C – Required/Conditional. Required specifies that the data element is required by the interface for the transaction to successful submit. Conditional means that specified conditions must be adhere to by the interface for the transaction to successful submit. No value specifies that the data element is optional by the interface for the transaction to submit.

• Type – The data type of the data element.

o VarChar – Variable Character text. Alphanumeric data.

o Byte – Unsigned character.

o Char – Character. Fixed length alphanumeric text, required to meet the exact specified size.

o Date – Date Format YYYY-MM-DD

o Decimal – Numeric value with a specified decimal position (9,3) = 999999999.999

o Boolean –True/False. True conditions = “true”, False conditions = “false”.

o Memo – Alphanumeric Text with a maximum of 1500 characters.

o Currency – Numeric, with two decimal positions. Format 9999.99.

o Integer – Numeric value, a whole number.

o Long - Numeric value, a long whole number.

• Size – The (numeric) size of the data element

• AdvantageME Notes – Notes specific to the AdvantageME data element.

XML Definitions and Conventions

• Root - The upgraded MFASIS XML file and document root declaration identify the required root elements that must be contained for the XML file or document (transaction) to load into MFASIS. The upgraded MFASIS XML file must contain a single root element that contains specified attributes, at the file level. Each document transaction contained within the XML file must also contain a root element that contains the specified attributes, at the document level.

• Attributes - Attributes are name-value pairs that occur inside start-tags after the element name.

• Elements - Elements are the most common form of markup. Delimited by angle brackets, most elements identify the nature of the content they surround. Elements normally begins with a start-tag, , and ends with an end-tag, .

• CDATA Tags - In a document, CDATA instructs the parser to ignore (most) markup characters. Between the start of the section, , all character data is passed directly to the application, without interpretation. Elements, entity references, comments, and processing instructions are all unrecognized and the characters that comprise them are passed “literally” to the application.

2 Document Usage

Within the State of Maine financial system, departments process VCC documents to create Vendor Customer records. The VCC document adds new records to the Vendor/Customer (VCUST) table and the Customer Account Options (CACT) table.

 

Parts of the Vendor/Customer Creation Document:

The Vendor/Customer Creation document has 5 components. These components will be populated through the State’s VCC Customer interface:

Header - Contains document description information.

Vendor/Customer – Is the main data entry point in which you will enter information associated with a customer. Fields in this section include vendor/customer code, organization type, company name, taxpayer identification number and other disbursement and EFT information fields.

Address – Contains address as well as contact information related to the customer.

Customer Account – Contains billing information for the customer, such as billing profile and collection cycle.

Certification – Contains the active and approval status information for the customer.

3 Logical Document Component Structure

AdvantageME VCC Document Structure

Publishable Specification

1 Transaction Layout: VCC

| |Action Code (OE) |Component Description |

|Document|AMS_DOC_EXPORT_XML_FILE |R |XML file root element. |

|Componen| | | |

|t | | | |

| |AMS_DOCUMENT |R |Document root element. |

| |VCC_DOC_HDR |R |Lists description information associated with the customer. |

| |VCC_DOC_VCUST |R |Lists customer information such as legal name and various options related to the customer. |

| |VCC_DOC_AD |R |Lists the address and contact information for the customer. |

| |VCC_DOC_CUSTACC |R |Lists the billing related information for the customer. |

| |VCC_DOC_CERT |R |Lists the active and approval status of the customer. |

R – Required

CR – Conditionally Required: Based on the entry from another tag, some tags are either required or prohibited (i.e. First Name and Last Name become required if the Org Type is set to Individual. First Name and Last Name become prohibited if the Org Type is set to Company).

O – Optional

NOTE: Every field listed in the following tables MUST be included in the XML script. For this purpose, “null” may be a valid value (see the XML sample attached). Alphabetic values must be capitalized as listed in the “AdvantageME Notes” column.

1 Document Prefixes

In order to identify the interfaces by agency and type, the following codes have been assigned. References will be made to these codes throughout the mapping document:

|External Interface |File Prefix |Document Creator ID |

|TBD |TBD |TBD |TBD |

3 Data Repository

A central repository will exist for each interface partner. The server location is som-isa1asmom02.som.w2k.state.me.us. Security permissions will be such that only the agency partner specified can access the file structure(s) assigned to them. Note: Advantage technical personnel and OIT systems personnel will have permission to access all folders.

Each agency will PUSH their CR files to corresponding inbound folder (see below). A copy of the file is automatically archived for historical purposes.

The directory structure will look similar to the below:

|som-isa1asmom02.som.w2k.state.me.us |\Archive | | |

| | | | |

|som-isa1asmom02.som.w2k.state.me.us |\Customer | |

| | | | |

| | | | |

|som-isa1asmom02.som.w2k.state.me.us |\Inbound |\INTFAGR |\AGR0325CR1.xml |

| | | |\AGR0325CR1.inf |

| | | | |

|som-isa1asmom02.som.w2k.state.me.us |\Outbound | | |

| | | | |

|som-isa1asmom02.som.w2k.state.me.us |\Vendor | | |

| | | | |

4 DOC_ID Standard

There will be no user-specified prefix for the DOC_ID and will be assigned through the auto-numbering functionality.

6 VCC AMS_DOC_EXPORT_XML_FILE root element attributes

|Attribute |

|Attribute |

|Attribute |

|Attribute |

|Attribute |

AttributeCaption DescriptionR/CTypeSizeAdvantageME

NotesDOC_CATDocument Category The category in which the document is located.RVarChar8Same as in AMS_DOCUMENTDOC_TYPDocument TypeThe type of document, defined in the Document Type table. Each document code must be assigned a document type.RVarChar8Same as in AMS_DOCUMENTDOC_CDDocument CodeThe alpha-numeric identification code assigned to the document on the Document Control table. Each document code must be unique within the application. The document code is a required field when creating a new document. It also may be selection criteria on a parameter table, a key to a specific business rule on a control table, or the document code recorded on a historical record.RVarChar8Same as in AMS_DOCUMENTDOC_DEPT_CDDepartment CodeThe department code assigned to this document.RVarChar4Same as in AMS_DOCUMENTDOC_UNIT_CDUnit CodeThe unit code associated with this document.RVarChar4Same as in AMS_DOCUMENTDOC_IDDocument IdThe document code and number that is either manually assigned or automatically generated by the system if you do not enter this information. The version number is assigned automatically. Duplicate document identification numbers are not allowed in the system.RVarChar20Same as in AMS_DOCUMENTDOC_VERS_NODocument Version NumberThe version number assigned to this document. The version is incremented with each modification draft and after with a cancellation.RNumber10Same as in AMS_DOCUMENTCUST_ACT_STACustomer Active StatusThe active status of the record. Valid values are: Active, Inactive, Suspended, Discontinued, Debarred, Delete, andVSS Rejected. Default is Inactive.RNumber10“2” = ActiveCUST_APRV_STACustomer Approval StatusThe approval status of the record. Valid values are: Incomplete, Reviewed, and Complete. Default is Incomplete. Reviewed indicates the information has been reviewed, but the record is not yet ready for use in the system for purchases/payments. Complete indicates all information has been reviewed and approved for use.RNumber10“3” = Complete

VCC Customer XML Example

This example is for a VCC with one billing address, one customer account,and one certification line.

-----------------------

Document Header

Vendor/Customer

Certification

Address

Customer Account

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download