1. Deferred Recognition
1.1. Linked to MSP NonCMP
2. Product Centre Mediation
2.1. SOAP UI WSDLs
2.2. Pull Data from Product Centre dB for full rule set
2.2.1. Schema definitions and aggregation SQL in LAE into denormalized EDW table
2.3. Extra attributes for product centre
2.3.1. Account Code, Marketing Codes and NominalNumbers for RevenueShare.
2.4. Pull model from EDW v's push model via the LAE
2.5. Require bulk upload mechanism for publishing video into ProductCentre
3. MSP Non CMP
3.1. Linkage of Packages/Services for Monthly Subscription
3.1.1. Need to look at defined MSP packages
3.1.2. Find the PoS service and recurring service part
3.1.3. Fabricate the POS transaction for each month
3.1.4. Tie the cash receipt to the MSP
3.2. Decomissioning the MSP provisioing and cash collections jobs
3.2.1. Phased approach to porting from diseMP billing to LAE oriented billing
3.2.2. LAE will invoke the Complete Order and Confirm Order for the recurring part of the MSP or alternative is to have LAE generate the batch XML as per refunds.
3.2.3. Action: Complete HLD Sequence flows
3.3. Creation of the MOR based on join of the Inv Detail and SubPurchase
4. Tax Reporting
4.1. On hold until business requirements are captured
4.2. ADP Taxware is capable of calculating tax in realtime
4.3. Issue surrounding the user meta data captured during portal puchase path. The portal has removed the billing data and currently there is no AVS checking involved.
4.4. MSP Taxation Rule Defn
4.5. Link Address Data for Taxation
5. Store and Forward
5.1. Store based on Rev ByPass, requires ESB and portal running
5.2. AMS, is ACPU based, data stored in Oracle dB
5.3. RSA encrypted data
5.4. Requirements
5.4.1. PCI requirements
5.4.2. Reusable component for Refund oriented
5.4.3. Declined Auth's are written off via reconcillation component at end of graph
5.4.4. MOR Purchase defines a status depending on business rules
5.4.5. Strip the card info from the revBP dB and mark transaction as flushed
5.4.6. Purchase date populated as store date
5.4.7. Activation date populated as forward date
5.4.8. SLAs
5.4.8.1. Settlement within 48/72 hours
5.4.8.2. Scheduled at low time
5.4.8.3. Driven by Oracle storage
5.4.8.4. Create Workflows for each store and forward event
5.4.9. Decouple payments from diseMP, front loaded payments. Phase ++
5.4.10. GoGo WebService call hosted in ESB
5.4.10.1. Delayed playback of BPOE WebServices
5.4.10.2. Complete and Confirm Order based
5.4.10.3. Fixed Product defined
5.4.10.3.1. If blank, fetch default product
5.5. Sales Channels
5.5.1. POS
5.5.2. MSP
5.5.3. Enterprise
5.5.4. Video
5.5.5. Ground
6. Refund Automation
6.1. Scanning Refunds
6.2. Care oriented funds
6.2.1. Intention to automate the current process
6.2.2. Care create a refund diseMP workflow
6.2.2.1. Workflows are either auto approval or assigned to supervisors as per standard diseMP workflow
6.2.3. Possible for LAE to create a batch of workflows
6.2.4. LAE polls diseMP dB for approved workflows. Workflows will contain the POSREF for the transaction to refund
6.2.5. LAE will validate the refund
6.2.5.1. Validate the POS transaction
6.2.5.2. Validate the number of refunds against the POS transaction, by validating the Purchase MOR
6.2.5.3. Extract the TxRefNum for the POS transaction by using the PaymentID (ACLLIVE) and extracting the TxRefNum from the joined OneOffTxNum
6.2.6. Generate the batch refund XML as per Orbital XML Spec. The transaction type is NewOrder with substype of Refund using the TxRefNum
6.2.7. PGP encrypt the XML using the ChasePaymentech public key
6.2.8. SFTP the .pgp file to the Orbital Gateway
6.2.9. Poll the Orbital Gateway for the response
6.2.10. decrypt the rsp.pgp using the MDS private key
6.2.11. Process the refunds
6.2.11.1. Generate a refunded Workflow
6.2.11.2. Add the SLA to diseMP. NOT REQUIRED!!
6.2.11.3. Update/Confirm the care approved workflow adding a note on the status of the refunded transaction
6.2.12. Promo based refunds
6.2.12.1. Workflow Generation for Promo refund
6.2.12.2. Questions for care on promo types