Migrating Data by Using New and Extended Storable Classes

4 Migrating Data by Using New and Extended Storable Classes

This chapter describes how to migrate data to your Oracle Communications Billing and Revenue Management (BRM) database when the data requires new or extended storable classes.

About Migrating Data by Using New and Extended Storable Classes

If your legacy data includes data not currently supported in BRM, you support the custom data by creating storable classes or extending storable classes. You can then extend the Conversion Manager XML schema to migrate the data.

Note:

Conversion Manager does not support extensions for all BRM storable classes. See "About Extended Storable Classes for Migration".

To use new or extended storable classes:

Create the new or extended storable classes. See "About Extended Storable Classes for Migration".
Create XML files that include the migrated data. See "Creating XML Files for New or Extended Storable Class Data".
Create control files to add tables to the BRM database. See "Creating Control Files for Extended Storable Classes".
Run the pin_cmt utility as you would for migrating nonextended data. See "Loading Legacy Data into the BRM Database".
Note:
- When you import data for new storable classes, you use a different pin_cmt utility parameter (-import_custom). When you migrate data into custom storable classes, the pin_cmt utility performs the additional step of activating the custom data when it is deployed.
- Import all custom data before you deploy any data. The only exception is if all the custom data belongs to the root account; for example, custom system configuration data.

About Extended Storable Classes for Migration

You can extend the following storable classes:

/service
/device
/payinfo
/profile

For example:

/service/extension1
/service/extension1/extension

About Linking to Data from New or Extended Storable Class Data

Data in new or extended storable classes can include links to other objects. For example, a /service/extended object can include a link to an /account object by including the account ID in the PIN_FLD_ACCOUNT_OBJ field.

You can link to the following types of objects:

/account
/service (and extended service storable classes)
/device (and extended device storable classes)
/payinfo (and extended payinfo storable classes)
/profile (and extended profile storable classes)
/group/sharing/charges
/group/sharing/discounts

When creating new or extended storable classes, follow the BRM standards and restrictions. For example:

You cannot nest substructs.
An array can include an array, but no further levels are allowed.

Creating XML Files for New or Extended Storable Class Data

Use these guidelines when creating an XML file for data for new or extended storable classes:

Use the XML myExtension element for extended data.
Use the XML NewClass element for new custom storable classes.
Use the myArray and mySubstruct elements for arrays and substructs in the extended data.
Use the table attribute in each array and substruct to define the table that stores the data.
Use the elem attribute in each array to define the index.
Use the RefObj element to create links to other objects. To do so, use the ID of the object being linked to. For example:
```
<RefObj type ="/account"> 1234 </RefObj>
```
If the pin_cmt utility does not find the object being linked to, it reports a warning and inserts a null value in the Portal object ID (POID) being referenced.
Use the type attribute in all new and extended elements to define the type of data.
- The type attribute for a new storable class is defined in the base storable class element. For example:
```
<NewClass  id="1243" type="/myclass" table="myclass_t" read="L" write="L" > 
```
- The type attribute for an extended storable class is defined in the base storable class element. For example:
```
<ActSrv id="771" type="/service/extended" precreate="/item/misc" global="true"> 
```

For XML examples, see the following sections:

Creating an XSD File for Extended Data

To validate the XML file, you must create an XSD file for the extended information. You can use the myExtension.xsd file in BRM_home/apps/cmt/sample_data as a starting point. BRM_home is the directory in which the BRM server software is installed.

Note:

For each type of extended information, use a different namespace to avoid collisions caused by using the same name myExtension.

If the extended information contains BRM extensions (for example, /service/x, /payinfo/x, /device/x, and /profile/x), include the custom XSD in the CMT_Subscribers.xsd file. This allows the extended information to be validated along with the subscriber information.

If the extended information includes a custom storable class (for example, /my_profile), the custom XSD does not need to be included in the CMT_Subscribers.xsd file. The extended information can be validated by the custom XSD file.

Put the custom XSD file in the folder specified in the infranet.cmt.schema.location entry in the pin_cmt utility Infranet.properties file. By default, the folder is BRM_home/apps/cmt/schema_files/physical.

Note:

To enable XML validation, use the infranet.cmt.preprocess.validation entry in the pin_cmt Infranet.properties file. See "Enabling XML Validation".

Creating Control Files for Extended Storable Classes

Control files add tables to the BRM database. You create a control file for each table. You need to create a control file for each of the following:

New storable classes
Substructs in new or extended storable classes
Arrays in new or extended storable classes

When you create a control file, the name of the control file is used as the table name. For example, if you create a new storable class named /myclass, which includes a substruct named PIN_FIELD_MYSUBSTRUCT, the table name would be MYCLASS_SUBSTR_T. The control file name would be myclass_substr_t.ctl.

Note:

The order of columns in the control file must be the same as the order of columns in the table.
The order of data in the XML input file must be the same as the order of data in the control file and table.
While adding tables to the BRM database, ensure that the tables listed in the pin_cmt utility Infranet.properties file belong to the main storable class.

For control file examples, see the following sections:

To use your custom control files:

Put the control files in BRM_home/apps/cmt/ctl_files.
Edit the pin_cmt utility Infranet.properties file.
- For control files that add substruct and array data, edit the infranet.cmt.loaders entry. Add the control file names. For example:
```
infranet.cmt.loaders = account_t; account_nameinfo_t; ...; extended2_substr1_t; extended_cust1_t; extended2_cycle_t;
```
- For control files that add data for a new storable class, add the infranet.cmt.customtables entry. Add the table names, separated by semicolons. For example:
```
infranet.cmt.customtables = myclass_t;
```
  Note:
  
  By default, the infranet.cmt.customtables entry is not included in the Infranet.properties file.

Creating Control Files for Custom Event Tables in a Virtual Column-Enabled System

BRM Conversion Manager includes control files that are suitable for a virtual column-enabled system for migrating event tables (the event_t and event_bal_impacts_t tables). If you have custom event tables to be migrated (for event-type objects that are not in the BRM system), you must create the control files as described in this chapter. In addition, in a virtual column-enabled system, the BRM Conversion Manager event control files cannot perform insert operations on the virtual columns (the field_name_type columns) of event tables in the BRM database; they must, instead, perform insert operations on the virtual column's associated supporting column field_name_type_id.

See BRM System Administrator's Guide for information about using virtual columns on event tables.

Example of Extending a Service Storable Class

The following example shows the XML data for an extended /service storable class:

<ActSub>
    <ActSrv id="771" type="/service/extended" precreate="/item/misc" global="true">
        <CWhn>2004-10-02T01:22:15-07:00</CWhn>
        <Log>159-51090219-237205-0-24083-1-tahoe</Log>
        <Pass>md5|5f4dcc3b5aa765d61d8327deb882cf99</Pass>
        <SrvSta>A</SrvSta>
        <Eff>2004-02-02T01:22:15-07:00</Eff>

        <SClsInfo>
        <myExtension>
            <mySubstruct table="extended_substr1_t" >
                <FldCustName type="string">abc</FldCustName>
                <FldCustType type="integer">99</FldCustType>
            </mySubstruct>
            <myArray table="extended_cust1_t" elem="1">
                    <FldAmt type="integer">190</FldAmt>
                    <FldDate="date">2004-02-02T01:22:15-7:00</FldDate>
                    <myArray table="extended_cycle_t" elem="1">
                        <Fldtype type="integer">190</Fldtype>
                    </myArray>
                </myArray>
        </myExtension>

        </SClsInfo>
    
    </ActSrv>
</ActSub>

In Developer Workshop, the extended /service storable class definition looks like this:

/service/extended
    CMT_ARRAY
        CMT_NAME
        PIN_FLD_ACCOUNT_TYPE
    CUST_ARRAY
        PIN_FLD_CYCLE
            PIN_FLD_CUSTOMER_TYPE
        PIN_FLD_CYCLE_DISC_AMT
        PIN_FLD_CYCLE_END_T

After loading the data, the extended fields are included in the stored object like this:

0 PIN_FLD_POID                    POID [0] 0.0.0.1 /service/extended 11813 3
0 PIN_FLD_CREATED_T               TSTAMP [0] (1083337746) Fri Apr 30 08:09:06 2004
0 PIN_FLD_MOD_T                   TSTAMP [0] (1083338129) Fri Apr 30 08:15:29 2004
.
.
.
0 PIN_FLD_TYPE                    ENUM [0] 0
0 PIN_FLD_ALIAS_LIST              ARRAY [0] allocated 1, used 1
1     PIN_FLD_NAME                STR [0] "00491110102"
0 10000                           SUBSTRUCT [0] allocated 2, used 2
1     10004                       STR [0] "abc"
1     PIN_FLD_ACCOUNT_TYPE        ENUM [0] 99
0 10005                           ARRAY [1] allocated 3, used 3
1     PIN_FLD_CYCLE_DISC_AMT      DECIMAL [0] 190
1     PIN_FLD_CYCLE_END_T         TSTAMP [0] (1075713735) Mon Feb  2 01:22:15 2004
1     PIN_FLD_CYCLE               ARRAY [1] allocated 1, used 1
2         PIN_FLD_CUSTOMER_TYPE   ENUM [0] 190

The following examples show the control files used for loading the data for the extended /service storable class. The substruct and arrays require new tables. The array tables include the columns REC_ID or REC_ID2; the substruct does not include these columns.

Example Control File for Substruct

-- extended_substr1_t.ctl

LOAD DATA
APPEND
    INTO TABLE EXTENDED_SUBSTR1_T
    (
        OBJ_ID0    INTEGER EXTERNAL TERMINATED BY ',', 
        NAME       CHAR TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"',
        TYPE       INTEGER EXTERNAL TERMINATED BY ','
     )

Example Control File for Array

-- extended_cust1_t.ctl

LOAD DATA
APPEND
    INTO TABLE EXTENDED_CUST1_T
    (
        OBJ_ID0     INTEGER EXTERNAL TERMINATED BY ',', 
        REC_ID      INTEGER EXTERNAL TERMINATED BY ',', 
        AMOUNT      INTEGER EXTERNAL TERMINATED BY ',', 
        END_T       INTEGER EXTERNAL TERMINATED BY ','
     )

Example Control File for Array

-- extended_cycle_t.ctl

LOAD DATA
APPEND
    INTO TABLE EXTENDED_CYCLE_T
    (
        OBJ_ID0    INTEGER EXTERNAL TERMINATED BY ',', 
        REC_ID     INTEGER EXTERNAL TERMINATED BY ',', 
        REC_ID2    INTEGER EXTERNAL TERMINATED BY ',', 
        TYPE       INTEGER EXTERNAL TERMINATED BY ','
    )

Setting a Service Balance Group

The following example shows attributes in the input XML file that you set to associate a balance group with a service.

To create a balance group and associate it with a service, set the bal_grp attribute to true.

<ActSrv id="50001" type="/service/telco/gsm/telephony" precreate="/item/misc" global="true" bal_grp="true" billInfoElem="1">
        <Log>159-20040202-210000-0-24083-1-zion</Log>
        <Pass>md5|5f4dcc3b5aa765d61d8327deb882cf99</Pass>
        <SrvSta>A</SrvSta>
        <CrtT>2004-05-26T01:22:15-07:00</CrtT>
        <Eff>2004-05-26T01:22:15-07:00</Eff>
        <ServId>ServiceTelephony</ServId>
        </ActSrv>

To associate the balance group of a bill unit (/billinfo object) with a service, set the skip_bal_grp_crt and bal_grp attributes to true. The balance group of the bill unit is associated with the service.

<ActSrv id="50001" type="/service/telco/gsm/telephony" precreate="/item/misc" global="true" bal_grp="true" skip_bal_grp_crt="true" billInfoElem="1">
        <Log>159-20040202-210000-0-24083-1-zion</Log>
        <Pass>md5|5f4dcc3b5aa765d61d8327deb882cf99</Pass>
        <SrvSta>A</SrvSta>
        <CrtT>2004-05-26T01:22:15-07:00</CrtT>
        <Eff>2004-05-26T01:22:15-07:00</Eff>
        <ServId>ServiceTelephony</ServId>
        </ActSrv>

Example of Extending a Device Storable Class

The following example shows the XML data for an extended /device storable class:

<DeviceInfo>
    <Device id="778" type="/device/extended2">
        <DevId>00982110309</DevId>
        <Src>source2</Src>
        <Mnufr>Airtel2</Mnufr>
        <Mdl>A4IR124</Mdl>
    </Device>
    <myExtension>
        <myArray table="dev_extended2_t" elem="1">
            <FldAmount type="integer">11</FldAmount>
            <FldDate type="date">2004-03-15T01:22:15-07:00</FldDate>
        </myArray>
    </myExtension>
</DeviceInfo>

In Developer Workshop, the extended /device storable class definition looks like this:

/device/extended2
    PIN_FLD_ENTRIES
        PIN_FLD_ENTRY_AMOUNT
        PIN_FLD_ENTRY_T

After loading the data, the extended fields are included in the stored object like this:

# number of field entries allocated 14, used 14
0 PIN_FLD_POID               POID [0] 0.0.0.1 /device/extended2 11811 0
0 PIN_FLD_CREATED_T          TSTAMP [0] (1083337746) Fri Apr 30 08:09:06 2004
0 PIN_FLD_MOD_T              TSTAMP [0] (0) <null>
0 PIN_FLD_READ_ACCESS        STR [0] "L"
0 PIN_FLD_WRITE_ACCESS       STR [0] "A"
0 PIN_FLD_ACCOUNT_OBJ        POID [0] 0.0.0.1 /account 1 0
0 PIN_FLD_DESCR              STR [0] ""
0 PIN_FLD_DEVICE_ID          STR [0] "00982110309"
0 PIN_FLD_MANUFACTURER       STR [0] "Airtel2"
0 PIN_FLD_MODEL              STR [0] "A4IR124"
0 PIN_FLD_SOURCE             STR [0] "source2"
0 PIN_FLD_STATE_ID           INT [0] 0
0 PIN_FLD_SERVICES           ARRAY [3] allocated 2, used 2
1     PIN_FLD_ACCOUNT_OBJ    POID [0] 0.0.0.1 /account 11806 0
1     PIN_FLD_SERVICE_OBJ    POID [0] 0.0.0.1 /service/extended2 11813 0
0 PIN_FLD_ENTRIES            ARRAY [1] allocated 2, used 2
1     PIN_FLD_ENTRY_AMOUNT   DECIMAL [0] 11
1     PIN_FLD_ENTRY_T        TSTAMP [0] (1079342535) Mon Mar 15 01:22:15 2004

The following example shows the control file used for loading the data for the extended /device storable class:

LOAD DATA
APPEND
    INTO TABLE DEV_EXTENDED2_t
    (
        OBJ_ID0                 INTEGER EXTERNAL TERMINATED BY ',', 
        REC_ID                  INTEGER EXTERNAL TERMINATED BY ',', 
        AMOUNT                  INTEGER EXTERNAL TERMINATED BY ',', 
        ENTRY_T                 INTEGER EXTERNAL TERMINATED BY ','
    )

Example of Creating a Storable Class

The following example shows the XML data for a new storable class named /myclass:

<NewClass  id="1243" type="/myclass" table="myclass_t" read="L" write="L" >
    <AcctObj>0.0.0.1-indian500</AcctObj>
    <myArray table="myclass_rules_t" elem="0">
        <rum_id type="integer">222</rum_id>
        <descr type="string">sachin</descr>
        <start_t type="date">2006-10-02T01:22:15-07:00</start_t>
        </myArray>
    </myArray>
</NewClass>

In Developer Workshop, the /myclass definition looks like this:

/myclass
    PIN_FLD_ACCOUNT_OBJ
    PIN_FLD_CREATED_T
    PIN_FLD_MOD_T
    PIN_FLD_POID
    PIN_FLD_READ_ACCESS
    PIN_FLD_RULES
        PIN_FLD_RUM_ID
        PIN_FLD_SCENARIO_DESCR
        PIN_FLD_SCHEDULE_DOWNTIME_START
    PIN_FLD_WRITE_ACCESS

After loading the data, the stored object looks like this:

0 PIN_FLD_POID                          POID [0] 0.0.0.1 /myclass 43567 0
0 PIN_FLD_CREATED_T                     TSTAMP [0] (1083780256) 5/6/04 3:04 AM
0 PIN_FLD_MOD_T                         TSTAMP [0] (1083780256) 5/6/04 3:04 AM
0 PIN_FLD_READ_ACCESS                   STR [0] "L"
0 PIN_FLD_WRITE_ACCESS                  STR [0] "L"
0 PIN_FLD_ACCOUNT_OBJ                   POID [0] 0.0.0.1 /account 1 1
0 PIN_FLD_RULES                         ARRAY [0] allocated 4, used 4
1    PIN_FLD_RUM_ID                     INT [0] 222
1    PIN_FLD_SCENARIO_DESCR             STR [0] "sachin"
1    PIN_FLD_SCHEDULE_DOWNTIME_START    TSTAMP [0] (1159732335) 10/2/06 4:52 AM

The following example shows the control file used for loading the data for the new /myclass storable class:

myclass_t.ctl

LOAD DATA
APPEND
    INTO TABLE MYCLASS_T
    (
        POID_DB             INTEGER EXTERNAL TERMINATED BY ',',
        POID_ID0            INTEGER EXTERNAL TERMINATED BY ',',
        POID_TYPE           CHAR TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"',
        POID_REV            INTEGER EXTERNAL TERMINATED BY ',',
        CREATED_T           INTEGER EXTERNAL TERMINATED BY ',',
        MOD_T               INTEGER EXTERNAL TERMINATED BY ',',
        READ_ACCESS         CHAR TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"',
        WRITE_ACCESS        CHAR TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"',
        ACCOUNT_OBJ_DB      INTEGER EXTERNAL TERMINATED BY ',',
        ACCOUNT_OBJ_ID0     INTEGER EXTERNAL TERMINATED BY ',',
        ACCOUNT_OBJ_TYPE    CHAR TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"',
        ACCOUNT_OBJ_REV     INTEGER EXTERNAL TERMINATED BY ','
    )

The following example shows the control file used for loading the data for the /myclass storable class PIN_FLD_RULES substruct:

myclass_rules_t.ctl

LOAD DATA
APPEND
    INTO TABLE MYCLASS_RULES_T
    (
        OBJ_ID0    INTEGER EXTERNAL TERMINATED BY ',', 
        REC_ID     INTEGER EXTERNAL TERMINATED BY ',', 
        RUM_ID     INTEGER EXTERNAL TERMINATED BY ',', 
        DESCR     CHAR TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"', 
        START_T   INTEGER EXTERNAL TERMINATED BY ','
     )

Example of Migrating Hierarchical Accounts

The following example shows the various attributes that you need to specify for different accounts at different hierarchy levels in the input XML file while performing the migration:

Parent account: The following attributes should exist for the parent account:
```
<ActSbsc id="0.0.0.1-10001" isParent="Y"> 
```
Set id to the unique string by which the account will be identified. Set isParent to Y.
Child account whose bill units are paying: The following attributes should exist for the child account whose bill units are paying:
```
<ActSbsc id="0.0.0.1-10002" parenRef="0.0.0.1-10001"> 
```
Set id to the unique string by which the account will be identified. Set parenRef to a reference to the parent ID.

Child account whose bill units are nonpaying: The following attributes should exist for the child account whose bill units are nonpaying:

<ActSbsc id="0.0.0.1-10003" parenRef="0.0.0.1-10001"  payParenRef="0.0.0.1-10001">

Set id to the unique string by which the account will be identified. Set parenRef to a reference to the parent ID. Set payParenRef to a reference to the paying parent ID.

The pay_type (PTyp) attribute under billinfo should be set to NPC as follows:

<ABinfo global="true"> 
            <ACDom>26</ACDom> 
            <ANxt>2004-07-26T01:22:15-07:00</ANxt> 
            <BlWn>1</BlWn> 
            <BlSgmnt>RC</BlSgmnt> 
            <PTyp>NPC</PTyp> 
</ABinfo>

The payinfo_obj_type attribute under payinfo should be set to /payinfo. Also, comment out the payinfo section as follows:

<APinfo id="10004" type="/payinfo">
                     <DDom>26</DDom> 
                     <RelDue>2004-05-26T01:22:15-07:00</RelDue> 
                     <!-- payInvExtn> 
                            <Add>340/C Baker Street</Add> 
                            <Cty>Houston</Cty>
                            <Cntr>USA</Cntr> 
                            <Nm>52345</Nm> 
                            <Stt>Texas</Stt> 
                            <Zip>56009</Zip> 
                     </payInvExtn --> 
</APinfo>

Paying and nonpaying child: Child accounts can have multiple paying bill units and nonpaying bill units:
- Paying bill unit: The following attributes should exist for each paying bill unit:
```
<ActSbsc id="0.0.0.1-10004" parenRef="0.0.0.1-10001">
```
```
<ActSrv id="0.0.1.1-10224" type="/service/telco/fixedretail" billInfoElem="2">
```
```
<ABinfo elem="2" parentElem="1" bal_grp="False" payInfoRefId="0.0.0.1-114">
<APinfo id="0.0.0.1-114" type="/payinfo/invoice">
```
- Nonpaying bill unit: The following attributes should exist for each nonpaying bill unit:
```
<ActSbsc id="0.0.0.1-10004" parenRef="0.0.0.1-10001">
```
```
<ActSrv id="0.0.1.1-10334" type="/service/telco/prepaid" billInfoElem="1">
```
```
<ABinfo elem="1" parentElem="1" payingParenRefId="0.0.0.1-10001">
```
  Set payingParentRefId to a reference to the parent account ID that owns the paying bill unit. This creates another /billinfo record for the child account. The ar_billinfo_obj_id0 field of that record stores the ID of the paying bill unit.

Setting an Account Bill Unit

The following example shows attributes in the input XML file that you set to define a /billinfo object as the account bill unit.

To define a /billinfo object as the account bill unit, set the isAccBillinfo attribute in the <ABInfo> /billinfo object to Y. The balance group associated with the /billinfo object then becomes the account default balance group.

Note:

There can be only one <ABinfo> /billinfo object for which the isAccBillinfo attribute is set to Y. If there are duplicate <ABinfo> /billinfo objects, BRM returns an error and the migration stops.

<ABinfo global="true" spnrCnt="1" spnreeCnt="2" elem="1" bal_grp="true" isAccBillinfo="Y" payInfoRefId="MyAPInfo_1">
	       <ACDom>21</ACDom>
       <ActgType>B</ActgType>
       <ANxt>2013-07-01T01:22:15-07:00</ANxt>
       <CrtT>2013-06-07T01:22:15-07:00</CrtT>
       <BlWn>1</BlWn>
       <BlSgmnt>RC</BlSgmnt>
       <PTyp>INV</PTyp>
       <BISta>A</BISta>
       <BillStat>3</BillStat>
       <ExmtFrmColl>A</ExmtFrmColl>
       <BIStaFlag>SBCA</BIStaFlag>
       <BillInfoId>MyBillInfo_1</BillInfoId>
</ABinfo>

Example of Migrating Hierarchical Bill Units within an Account

The following example shows hierarchical bill units within an account.

Note:

To create the hierarchical bill units in the same account, set the thisActHierarchy attribute to true. In the following example, the bill units BI1 and BI2 are in account A. BI1 is the parent of BI2.

<ABinfo global="true" spnrCnt="1" spnreeCnt="2" elem="1" bal_grp="true" payInfoRefId="MyAPInfo_1">
      <ACDom>26</ACDom>
      <ActgType>B</ActgType>
      <ANxt>2013-07-01T01:22:15-07:00</ANxt>
      <CrtT>2013-06-07T01:22:15-07:00</CrtT>
      <BlWn>1</BlWn>
      <BlSgmnt>RC</BlSgmnt>
      <PTyp>INV</PTyp>
      <BISta>A</BISta>
      <BillStat>3</BillStat>
      <ExmtFrmColl>A</ExmtFrmColl>
      <BIStaFlag>SBCA</BIStaFlag>
      <BillInfoId>MyBillId3</BillInfoId>
	</ABinfo>
<ABinfo global="true" spnrCnt="1" spnreeCnt="2" elem="2" parentElem="1" thisActHierarchy="true" bal_grp="true" payInfoRefId="MyAPInfo_1">
      <ACDom>26</ACDom>
      <ActgType>B</ActgType>
      <ANxt>2013-07-01T01:22:15-07:00</ANxt>
      <CrtT>2013-06-07T01:22:15-07:00</CrtT>
      <BlWn>1</BlWn>
      <BlSgmnt>RC</BlSgmnt>
      <PTyp>NPC</PTyp>
      <BISta>A</BISta>
      <BillStat>3</BillStat>
      <ExmtFrmColl>A</ExmtFrmColl>
      <BIStaFlag>SBCA</BIStaFlag>
      <BillInfoId>MyBillId1</BillInfoId>
</ABinfo>
<ABinfo global="true" spnrCnt="1" spnreeCnt="2" elem="3" parentElem="1" thisActHierarchy="true" bal_grp="true" payInfoRefId="MyAPInfo_1">
      <ACDom>26</ACDom>
      <ActgType>B</ActgType>
      <ANxt>2013-07-01T01:22:15-07:00</ANxt>
      <CrtT>2013-06-07T01:22:15-07:00</CrtT>
      <BlWn>1</BlWn>
      <BlSgmnt>RC</BlSgmnt>
      <PTyp>NPC</PTyp>
      <BISta>A</BISta>
      <BillStat>3</BillStat>
      <ExmtFrmColl>A</ExmtFrmColl>
      <BIStaFlag>SBCA</BIStaFlag>
      <BillInfoId>MyBillId2</BillInfoId>
</ABinfo>