edi issue list v0.2

23
# Issue Impact 1 Default Pack Code 2 Customer own designations 3 Contract Determination 4 Sales Organisation Critic al Critic al Critic al Critic al

Upload: manindra-kumar-tiwari

Post on 23-Nov-2015

31 views

Category:

Documents


1 download

DESCRIPTION

edi

TRANSCRIPT

Sheet1#IssueImpactDescriptionCommentSolutionStatusConcerns1Default Pack CodeCriticalThe EDI messages can contain a SKF designation, but in most cases they do not contain a pack code. In this case the EDI order runs into error. The first analysis revealed two issues:1) If there is no pack code, SAP PI send an empty product ID field in the IDoc2) The function module 1) Change SAP PI2) Use the determined sales organisation To be implemented and tested.Mail from David Warren 25/03/2014: Hi Constantin I checked the Finnish COH production database and they:- have 343 active Customers Own Designations that have a pack code.- Have no records in the Package code default table (OAPCDT) that is read to retrieve the default PC using Customer / Dept / Product.

--> Please check how customer own designations are going to be migrated. For my understanding customer designations will always be linked to a pack variant in SAP and never to a final variant. In the case that there is a customer designation in SAP linked to a final variant we probably have no solution for this yet.

2Customer own designationsCriticalI have heard that the solution for customer own designation has changed back from using product determination to customer material info records. It needs to be tested if the end to end process for EDI sales orders is still working. If the customer sends in an own designation via I057, I060 should contain the customer own designation. CMIR defect already raised.To be tested. Might not be an issue. To be tested end to end. I060 would send back the SKF designation, even if the customer sends in an own designation.3Contract DeterminationCriticalHow are contracts determined for EDI sales orders? Test and verify with MDM and SKF, whether we are doing the correct thing. single contract is working fine for the EDI order.Need to understand more about the sold to party and ship to party combination is working or not ?Current solution: If there is only one open sales contract for customer / material, it automtically gets assigned for the EDI order. If there is more than one sales contract, the sales order will be saved in error and a task get's created for the CSR: The CSR then has to go to the sales order and select the correct sales contract.To be disucssed with Bryson Gamble, Bryan Ogden and Eric BenthamIf there is only one conract, are we sure that it is the correct one? Right now it always is selected automatically.4Sales Organisation CriticalWhat happens if a customer has one or more sales organisations assigned in SAP? How can SAP determine the correct sales organisation. Which sales organisation should be used for the sales order and for the default pack code (1) issue?
Author: Author:Multiple sales area possible ?IN ECC we have a EDSDC table where we maintain the customer/vendor sales area for EDI, so we can utlize that or similar to this either can create a custom table and maintain sales area for the EDI customers like we did for WCL or can utilise the CRMM_DOM_PARTNER table in crm . OR

Selecting Sales org only is fine but selecting first sales area will have some consequences. Need to look into more detailsThis has been discussed with Bryan Ogden, Silvia Pisch, Dennise Scheib and MDM. Normally there should not be more than one sales organisation for an EDI customer. But it could be, that data migration is merging accounts. The assumption was, that if there are more than one sales area data assigned to a customer (e.g. not different sales orgs but different distribution channels), the sales order is placed in error and a task is created for the CSR. The CSR then could manually update the sales order and select the correct sales area data. Nevertheless, Manindra mentioned that SAP by default would select the first sales area from the list. This is also what Sujan recommended as solution. Please validate with the business if this would be the correct behaviour. To be decided, implemented and tested.5External External / Internal Translation (=Sold-To and Ship-To determination)CriticalSo far we are planning to store the EDI customer number on the business partner (id type: Z_CEDI) in SAP CRM. This wouldn't be a unique way to identify the sold-to party and ship-to party of a sales order.Need to understand the Customer migration details to look from end to end solution perspective.

As per concern # 2 raised, under cencerns column, my understanding is we have mapped the ADDRESS ID to ship to party not the SH account and hence one ship to party i.e. one address can not have multiple sold to party (one address-> many sold to party not possible as per my understanding)

Change PI and enhance the BP with the EDI customer ID and EDI address ID. Arijit has the detailed documentation of the logic. Please ask him to explain you the logic. If you are not sure I can review it. Please also document the solution in a digital way, so that we can include it in the FSD. If you don't have time to include it in the FSD, please send it to Sandip Deshmukh. He has a change tracker for me and we will update all FSDs at once, with the changes mentioned there. Please let me know if you have any questions or concerns.To be finalised, implemented in SAP PI and SAP CRM, Align with MDM (Dave Bhatt), and discsuss how this can be migrated or prepared for the production system.1) This issue needs to be addressed from an end-to-end perspective. For the outbound message (I060) we need to send the correct value back. Take the value from ship-to is ok, but we need to split the value into the two fields: Customer PARTY Id is mapped from ../skf:Header/oa:Parties/skf:CustomerParty/oa:PartyId/oa:Id Delivery Party Id is mapped from ../skf:Header/oa:Parties/skf:ShipToParty/oa:PartyId//oa:Id

2) In the case that one ship to has multiple sold-tos our logic would not work. Dave Bhatt needs to confirm that this really could be the case. Then Sujan would need to be involved again, because the whole solution for this issue would need to be reviewed.

6Exception for the Ecternal / Internal Translation (=Sold-To and Ship-To determination) MediumFor issue (5) there is also an exception table / logic based on the "item group code". This logic has not yet been discussed in detail and would not be implemented for issue (5). Please evaluate if this is required for Finland / Global Template and create a plan and solution, how to handle this. Not required for FinlandTo be discussed with Sujan, Gran and Kalle.To be finalised.7Remote ID/ GAIA Partner IDCriticalSales order acknowledgements from SAP CRM do not have a logic, to determine to which EDI broker system (in Finland either LIASION or BS) they should be routed. In COH today there is a remote ID table which contains entries specific for customer / transaction type. The remote IDs from this table are translated into the final value by using a second table. Right now the receiver value is hardcoded in SAP PI and sends all acknowledgements to LIAISON. In Development, logic given to PI and ABAP team.Email from Rajeev 20/03/2014:

Dear All,

Based on the discussion I am summarizing the logic for Partner id determination for I060 - Acknowledge Sales Order.

A new business identification Type( Category ) will be created in CRM . The identification number for that identification Category will contain the value for the "Partner id" which will be passed to GAIA header and will be used for routing.

To achieve the above below steps needs to be done :

A ) New identification type needs to be defined . Action Owner : C2C TeamB ) Add the activity in cut over to populate the right value either manually or some automation for all EDI partners. Action Owner : C2C TeamC ) Once the Identification type is defined confirm the logic to PI so that necessary changes can be implemented. Action Owner : C2C + Integration Team

Logic which needs to be implemented in PI looks like below :IF E101CRMXIF_BUSTRANS- E101CRMXIF_PARTNER_XT-E101CRMXIF_PARTNER-PARTNER_FCT = 'C2C Team to be Confirm '.

E101CRMXIF_BUSTRANS- E101CRMXIF_PARTNER_XT-E101CRMXIF_PARTNER-E1011006_IDENTIFICATION_KEY-IDENTIFICATIONNUMBER WHERE E101CRMXIF_BUSTRANS- E101CRMXIF_PARTNER_XT-E101CRMXIF_PARTNER-E1011006_IDENTIFICATION_KEY = 'C2C Team to be Confirm'' .

D ) Test end to end to see correct routing is happening. Action Owner : Integration team.

@Constantin , Please feel free to add the more details if something is missing.

Similar logic has to be built for I048 - EDI Invoice. @Dennis / Kerkko , please provide me the logic so that it can be incorporated at the earliest.To be implemented and tested.This needs to be alligned with Master Data or the cutover activity planning, because the values need to be set up or migrated to production system.8Compressed DesignationsCriticalWhen the sales order contains compressed designations there is no data/functionality in SAP yet, to handle these id type. Customer designation would work same way as SKF designation as per discussion with bryson.In the discussion have been involved: Silvia Pisch, Bryan Ogden, Eliana Soleiman, Magnus Koldemar, Loy PereiraTo be discussed and finalise a decision.Gran Wigbring is validating the impact for Finland. He will confirm how many customers are actually sending compressed designations for Finland.

Sheet2Row #IDOC FieldCMF FieldValueComments41CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/PARTNER_FCTAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty'00000019'This will be identifier only for PI.42CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/PARTNER_NOAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/PartyId/IdCompany Code For Sales OrgIn case of Finland it would be 951343CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/NAMEAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/NameOy SKF AB, EspooThis value need to be read by ECC based on sales organization data of SP44CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/NAME_2AcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/NameName 2 if any of Sales OrgThis value need to be read from ECC. Based on sales organization data of SP46CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/E104CRMXIF_ADDRESS/STREETAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Addresses/oa:Address/skf:PrimaryAddress/AddressLineStreet Value of Sales Org47CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/E104CRMXIF_ADDRESS/HOUSE_NOAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Addresses/oa:Address/skf:PrimaryAddress/AddressLineHouse No of Sales OrgCRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/E104CRMXIF_ADDRESS/POSTL_COD1AcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Addresses/oa:Address/skf:PrimaryAddress/PostalCodePostal Code of Sales Org48CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/CITYAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Addresses/oa:Address/skf:PrimaryAddress/CityCity of Sales OrgFI45CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PRICING_X/E101CRMXIF_PRICING/VAT_REG_NOAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/TaxIdVAT No of Sales OrgBased on the company Code read value from table49CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/E104CRMXIF_ADDRESS/COUNTRYISOAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Addresses/oa:Address/skf:PrimaryAddress/ISOCountryCodeCountry (3 Chars) Use Country Conversion table in PISales Organization Country50CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/PARTNER_NOAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Contacts/oa:ContactAbs/skf:SalesPerson/oa:Person/PersonCodePersonal No of Employee Responsiblei.e.PARTNER_FCT= "ZCSREP"Read the personal no from table HRP1001 based on SP & Employee Responsible53CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/FIRSTNAMEAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Contacts/oa:ContactAbs/skf:SalesPerson/DescriptionFirst Name of Employee ResponsibleZCSREP54CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/LASTNAMEAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Contacts/oa:ContactAbs/skf:SalesPerson/DescriptionLast Name of Employee Responsible51CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/FIRSTNAME +

CRMXIF_ORDER_SAVE_U06/IDOC/E101CRMXIF_BUSTRANS/E101CRMXIF_PARTNER_XT/E101CRMXIF_PARTNER/E102CRMXIF_ADDRESS/LASTNAMEAcknowledgeSalesOrder/DataArea/skf:SalesOrder/skf:Header/oa:Parties/oa:PartyType/skf:SellerParty/oa:Contacts/oa:ContactAbs/skf:SalesPerson/oa:Person/PersonName/FormattedNameFirst Name+Space+Last Name

Sheet3