No More Business ( NMB )

Stages :

Final State :

On-Premises implementation :

SAP uses CustomerManagementV3 service (UpdateCustomerStatus operation) to add or remove the NMB Flag on a Customer in CMD. This is a synchronized process.

Cloud implementation :

Stage 1 :

As SAP NFTP doesn’t contain data for all countries, and SAP ECC is still the master maintainer of all data, we still have to continue through existing route of SAP -to- ESB -to- CMD.

New flow for state 1 -

SAP uses CustomerManagementV3 service (UpdateCustomerStatus operation) to add or remove the NMB Flag on a Customer in CMD.

ESB sends this request to CMD Cloud API instead of on-prem service. CMD updates this info in cloud DB & publishes on modern topics.

This is a synchronized process.

Stage 2 :

SAP sends the NMB status of Customer via EMP, and CMD should consume these messages from Kafka topic to add or remove the NMB flag on a Customer.

SAP EMP Topic Details :

Test Environment : MSK.finance.qa2nomorebusiness.topic.internal.any.v1 UAT Environment : MSK.finance.nomorebusiness.topic.internal.any.v1

SAP EMP AVRO Schema :

{
  "type" : "record",
  "name" : "DT_NMBFlag",
  "fields" : [ {
    "name" : "Item",
    "type" : {
      "type" : "array",
      "items" : {
        "type" : "record",
        "name" : "AnonType_ItemDT_NMBFlag",
        "fields" : [ {
          "name" : "changeIndicator",
          "type" : [ "null", "string" ],
          "source" : "element changeIndicator"
        }, {
          "name" : "companyCode",
          "type" : [ "null", "string" ],
          "source" : "element companyCode"
        }, {
          "name" : "scvNumber",
          "type" : [ "null", "string" ],
          "source" : "element scvNumber"
        }, {
          "name" : "lockReason",
          "type" : [ "null", "string" ],
          "source" : "element lockReason"
        }, {
          "name" : "timeStamp",
          "type" : [ "null", "string" ],
          "source" : "element timeStamp"
        } ]
      }
    },
    "source" : "element Item"
  } ]
}

SAP EMP Message Example :

{
	"noMoreBusinessDetail": {
		"noMoreBusinessItems": [
			{
				"changeIndicator": "I",
				"companyCode": "3000",
				"scvNumber": "3344552266",
				"lockReason": "N",
				"datetimeStamp": "2001-12-17T09:30:47Z"
			},
			{
				"changeIndicator": "D",
				"companyCode": "3000",
				"scvNumber": "3344552266",
				"lockReason": "N",
				"datetimeStamp": "2001-12-17T09:30:47Z"
			}
		]
	}
}

Scenarios

Scenario 1: Customer is ACTIVE in CMD (Not in Workflow), SAP wants to suspend

• SAP will be sending “scvNumber” (CMD to find respective Customer Code) and “changeIndicator” as “I”

Scenario 2: Customer is ACTIVE in CMD (In Workflow), SAP wants to suspend

• SAP will be sending “scvNumber” (CMD to find respective Customer Code) and “changeIndicator” as “I”
• What should happen in CMD in this case?
  • CMD should be persisting the request and act upon it later if the customer is in the workflow and pending for approval or rejection.
  • CMD should suspend the Customer with reason “Difficult Collections” after the Customer comes out of Workflow
  • There should be a cron scheduler created in the service to find the Customer records which were actioned in the Workflow in every 5 minutes, and set the NMB status on them.
  • What should happen in SAP?
    • SAP will set the flag at their end and forget and CMD will persist and consume this update once Customer workflow is actioned

Scenario 3: Customer is in a SUSPENDED state in CMD, SAP wants to suspend it with NMB

• SAP will be sending “scvNumber” (CMD to find respective Customer Code) and “changeIndicator” as “I”
• CMD should add one more suspension reason as “Difficult Collections” to the already suspended Customer.
• CMD should publish the Customer with reason “Difficult Collections” when there is another underlying suspension reason. <THIS IS ONLY AS LONG AS CMD SENDS ONLY ONE SUSPENSION REASON IN THE OUTBOUNDS>

Scenario 4: Customer is in a SUSPENDED state in CMD, SAP wants to activate it

SAP will be sending “scvNumber” (CMD to find respective Customer Code) and “changeIndicator” as “D”

• If customer was suspended with NMB reason then NMB will be reset and previous state of customer status will be achieved in CMD.
• If customer was already suspended with some other reason prior NMB status then CMD customer will still be suspended with previous reason

Scenario 5: Customer is in a SUSPENDED state in CMD with NMB (Difficult Collections), and portal user wants to relate it as Master or Duplicate

• If customer was suspended with NMB reason and user tries to add another Customer as Duplicate of it (making the NMB suspended customer as Master), then no action → it can happen normally. No status or reason change in the existing NMB Customer.
• If customer was suspended with NMB reason and user tries to mark this Customer as Duplicate of another Master Customer, then add “Duplicate” as the Suspension Reason in addition to the current “Difficult Collections” reason. In this case Customer would hold 2 suspension reasons.
• Publish Customer should still publish the Customer with suspension reason as “Difficult Collections”. Remember, NMB takes precedence over other reasons. <THIS IS ONLY AS LONG AS CMD SENDS ONLY ONE SUSPENSION REASON IN THE OUTBOUNDS>
• If re-activation request comes on this NMB Customer which is also marked as Duplicate, then just remove the “Difficult Collections” suspension reason from Customer and keep “Duplicate” reason. In this case, publish customer should set suspension reason as “Duplicate”. This is as described in scenario #4.

Scenario 6: Customer which SAP requested to suspend is already suspended as MASTER customer in CMD.

• With recent Discussion with SAP, it has been concluded that SAP will maintain the Master Duplicate relationship in their system and whenever they are sending the NMB status update for a master or Duplicate Customer, they are expected to send auto NMB stratus update for the entire Duplicate group (Master of duplicate , all duplicates of Master )

Scheduler :

Table Name : “MDM_SMDSMD.CUST_STAT_CHNG_REQ_TRCKR”

Schema : MDM_SMDSMD

Name	Type
ROWID	BIGSERIAL
CUSTOMER_CODE	VARCHAR2(20)
REQ_STATUS	VARCHAR2(20)
REQ_SRC_SYS_NAME	VARCHAR2(20)
REQ_PAYLOAD	TEXT
PROCESSED_FLG	CHAR(1)
REQUEST_DATE	TIMESTAMPTZ
PROCESSED_DATE	TIMESTAMPTZ
REQ_USER	VARCHAR2(50)
MAX_RETRY	INT2
RESP_MSG	TEXT

Assumptions

1. SAP system will own the NMB status and NMB status update on a customer will always be initiated from SAP system.
2. NMB status updates(Setting NMB or Resetting NMB) for any customer or set of customer can be initiated from SAP
3. CMD will consume these updates received from SAP and will not be able to update NMB in any scenario
4. With above three statements , this will be only one directional update from SAP to CMD.
5. CMD system will not be allowed to reactivate any customer having NMB set by SAP, It can only be reactivated once SAP initiates NMB status change.
6. If NMB status is set for customer then CMD must not allow any edit on that customer or any status change of the customer unless NMB is reset back from SAP on demand on request. Exception is when update request is coming from BBU/HSUD (non-status update), or Customer is getting assigned as Master/Duplicate.
7. A customer with suspended reason because of NMB in CMD is not supposed to be suspended again with some other reason unless SAP initiates reset of NMB status, except for “Duplicate”
8. If we are linking non NMB customer as duplicate against NMB master customer then the NMB flag of Master customer should be extended to Suspended duplicate customer. If this is not working, the SAP team need to fix it at their end.