Flow Of Data B/W Different Systems Case Study

4.3. Flow of Data b/w Different Systems:

Here, POS, CLAIM, QUOTE, DNW,SO are different teams in ST responsible for different tasks and whose applications use different packaged products like that of EDI, ModelN, B2B etc. All these applications interact with Esicom2 (which is central database for managing all the applications).

CODENAMEDateRegionSoldToCountryStreetCityZIPStateAppShipTo01866117SIFTEO2013-01.Now there happens a two-way interaction between E2 and SAP-BP. Say if a new customer is created in any application; it is flowed in to E2 using interfaces, procedures and web methods written to communicate between these.

So whenever a new entry happens in disti_end_customer table , it interacts with SAP-BP application and now the SAP-BP uses DataFlux (DFX) tool which operates on the tables present in SAP-BP and E2 and propose whether it can be linked to an old customer ; or if it’s a new customer then it must be first created in SAP-BP. This is the way, dataflux’s role is defined. The results proposed by DataFlux would be manually corrected by ST user or US user, the information is then flown in to SAP-BP or GBMS (Geographical Business Management System), used for commission purposes.

All This information
Customer data are pushed to Model N through an interface program which role is to maintain consistency between the master and the slave system and make sure that customers are available in Model N for the business transactions. While most of customer management will occur in CRM (BP application), users have the possibility to create new accounts from Model N for the purpose of entering opportunities or quotes without waiting for someone else’s action. These new accounts are then transferred to SAP CRM where they enter the Final Customer Identification (FCI) process for codification if the new customer is to be created for it. Aliasing or Linking of accounts is mater in Model