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.
For more information on migrating data, see "Understanding Conversion Manager".
Important:
Conversion Manager is an optional feature that requires a separate license.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 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 non-extended data. See "Loading Legacy Data into the BRM Database".
Important:
When you import data for new storable classes, you use a different pin_cmt utility parameter (-import_custom). When you migrate data into custom 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.
You can extend the following storable classes:
/service
/device
/payinfo
/profile
For example:
/service/extension1
/service/extension1/extension
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.
Use the following 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:
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, where BRM_Home is the directory in which BRM is installed.
Important:
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.
Important:
To enable XML validation, use the infranet.cmt.preprocess.validation entry in the pin_cmt Infranet.properties file. See "Enabling XML Validation".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.
Important:
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 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.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 Migrating Data by Using New and Extended Storable Classes. In addition, in a virtual column-enabled system, the 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 more information on using virtual columns on event tables.
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 ',' )
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 /billinfo object with a service, set the skip_bal_grp_crt and bal_grp attributes to true. The balance group of the /billinfo object 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>
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 ',' )
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 table="myclassremit_t" elem="0"> <remit_fld type="string">one1</remit_fld> </myArray> <myArray table="myclass_remit_t" elem="1"> <remit_fld type="string">two1</remit_fld> </myArray> <myArray table="myclassremit_t" elem="2"> <remit_fld type="string">three1</remit_fld> </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_REMIT_FLDS PIN_FLD_REMIT_FLD 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 1 PIN_FLD_REMIT_FLDS ARRAY [0] allocated 1, used 1 2 PIN_FLD_REMIT_FLD STR [0] "one1" 1 PIN_FLD_REMIT_FLDS ARRAY [1] allocated 1, used 1 2 PIN_FLD_REMIT_FLD STR [0] "two1" 1 PIN_FLD_REMIT_FLDS ARRAY [2] allocated 1, used 1 2 PIN_FLD_REMIT_FLD STR [0] "three1"
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 ',' )
The following example shows the control file used for loading the data for the /myclass storable class PIN_FLD_REMIT_FLDS array:
myclass_remit_t.ctl LOAD DATA APPEND INTO TABLE MYCLASS_REMIT_T ( OBJ_ID0 INTEGER EXTERNAL TERMINATED BY ',', REC_ID INTEGER EXTERNAL TERMINATED BY ',', REC_ID2 INTEGER EXTERNAL TERMINATED BY ',', REMIT_FLD CHAR TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' )
The following example shows the various attributes that you need to specify for different hierarchy-level accounts 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.
Paying child: The following attributes should exist for the paying child account:
<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.
Nonpaying child: The following attributes should exist for the nonpaying child account:
<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.
The following example shows attributes in the input XML file that you set to define a /billinfo object as the account level /billinfo.
To define a /billinfo object as the account level /billinfo, set the isAccBillinfo attribute in the <ABinfo> /billinfo object to Y. The balance group that is associated with the /billinfo object then becomes the account-level balance group.
Note:
There can only be 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>
The following example shows hierarchical bill units within an account.
Note:
To create the hierarchical /billinfo objects within the same account, set the thisActHierarchy attribute to true. In the following example, the /billinfo objects BI1 and BI2 are in the account A. The BI1 /billinfo 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>