cancel
Showing results for 
Search instead for 
Did you mean: 

Qualified tables -mapping phone qualifiers

Former Member
0 Kudos

Hi ,

We are using SP4 patch 4, and the standard business content .

While mapping the qualified table phone, if there is only a single phone number then the mapping works without issues. However, if a cusotmer has more than one phone number maintained/ if the xml has more than one customer´s details , the phone details appear in a separate Idoc segment ADTEL. In this case , when the source is ADTEL the fields are mapped to the destination fields in customer, and the compound field gets created.

The IM does not allow the values to get imported, it gives an error saying that its unable to find the source record. To counter this, tried joining the ADTEL segment to the main KNA1 segment and all the phone fields appear however the destination field Phone is not mapped.

What is the best way to map qualified tables when there are more than one customer´s details coming in ?

All suggestions will be rewarded !

Thanks ,

Anita

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

The most important point in qualified tables is to properly identify the Yes Qualifiers and No Qualifiers.

Qualifiers – are those fields whose values change based on the value of some other field(s) and whose value is different for each main table record

Non Qualifiers – These fields are only the part of qualified lookup table, but they apply not only to the qualified table but also to each association of the qualified table record to the main table record. Simply speaking, they are the fields that will decide the values in the Qualifier (main table)fields

In case of customer address, it can be:

Is AddressPrimary: No Qualifier

Phone, Street, City: Yes Qualifier

You can import data to qualified tables in following way:

1. Map all the No Qualifiers from source to Destination (They will appear under the Customer Address Qualified table) Note: All Non Qualifiers must be compulsorily mapped!!

2. Perform Record matching step and Import the data

3. Now map all the Yes Qualifiers from source to destination (These will appear in the main table)

4. You would now have only one value left for mapping: the Lookup field in the main table.

5. To map this create a compound field of the Yes Qualifier and map it

6. Perform the Import

Hope this helps...

Regards,

Ketan

*Award points if suggestion found useful

Answers (1)

Answers (1)

former_member201266
Contributor
0 Kudos

Hi Anita,

I completely agree with Ketan, but I would like to add couple of points to it.

Here I start;

1) You can import data only into Display fields of an lookup table from the main table.

2) If you have more than one display fields than you have 3 different techniques to enter data into it, as-

Suppose you have a destination look up table NAMES with three display fields

as FIRST_NAME(FN), MID_NAME(MN), LAST_NAME(LN) the

i) you can have a field in source table as FN;MN;LN, here you have three different fields into one field and they are separated with a delimiter.you can map this source field with the NAMES<FN;MN;LN> destination field. The records will be imported successfully but the format will not be correct; as when u map values it required the same values to be there before importing; So this can be applicable only when you have all those three fields values individually in the table.

ii) you can have three separated fields and combine them with a separate them with a delimiter and continue with the first step; but it also requires the individual values to be there in the Names table.

iii) The third and best alternative is to have the individual fields in the source and map to all respective display fields in the destination. Then you an create the compound filed in the source and the field is automatically mapped and the values are also mapped most of the times. The best thing about compound field is that it does not require the individual values of the FN,MN and LN to exit; they are automatically added.

When it comes to qualified tables you have the fields as DISPLAY FIELDS AND NON QUALIFIERS that is the filed's FN,MN,LN should all be display fields and they should not be qualifiers, then only you can create a compound fields for them.

If a field in a qualified table is a qualifier and display field then you can map it individually but its not part of a compuond field.

if a field is qualifier and not display field then also you can map it individually, and this field is also not part of a compound field.

if a field is non qualifier and not display field the this value has to be entered manually through data manager.

All this points comes into picture when you are trying to import data into a qualified table through your main table.

Regards,

CHARAN

Former Member
0 Kudos

Thanks Ketan & Charan for your suggestions. Well, I understand the concept of the qulaified tables and how to import the data. The current issue is that the standard business content for the Customer data has multi-valued qualified tables Phone, Fax, E-mail.

For Phone & Fax the NQ, DF is the country field, the other fields present in the table std no, extension,telephone, sequence number,complete no are all qualifiers. As we need atleast 2 DF, NQ fields to create a combination , we are forced to select the std no as a NQ ,DF . This is a flag and we have attached the yes/no indicator lookup table values to this field. However, though this solves the problem of creating the compund field.

It causes issues while importing as what happens is that the destination values look somthing like this for eg: IN ;NULL std no -indicating that the std no vlaue for the country india is null. for this in the DM if you set the record for the country IN to yes/no then this appears in the import manager.

The question is, is this the right approach ? Is there is a better way to populate this qualified table ? Is creating a qualified table the best approach to handle the phone/fax / email fields ? We do need to be able to upload the data in the IM / server and not populate them in Data manager.

The e-mail table´s structure is

Address Type T(50), Code T(1),Email Address T(241),Sequence No T(3).

This has been modified to Add Type Lk flat (yes/no indiactor), code Lk flat (yes/no indicator),Email Address T(241),Sequence No T(3).

Thanks for your time ,any suggestions on this issue would be most welcome.

Regards,

Anita

former_member201266
Contributor
0 Kudos

Hi Anita,

You didn't get me; I said you, if you have more than one display field than you got to create an compound field, but not change a qualifer field to a create a compound filed.

I mean to say you need not create a compound field when you have only one NQ,DF and in this case directly map it. Map the country of Phone with independtly. It wont give you any kind of error.

Please let me know in case of any errors or problems

Regards,

CHARAN

Former Member
0 Kudos

Thanks Charan will try your suggestion and let you know if it works.

In the standard content they have Q, DF complete number , so right now we´re going to try with country as DF,NQ and the complete no field as Q,DF and check if the import occurs without errors.

Regards,

Anita

Former Member
0 Kudos

Charan,

Your suggestion works fine for the phone and fax fields. In case of e-mail however, I am getting a strange error the IM keeps crashing everytime the fields are mapped.

The e-mail qual table has the fields address type T(50),DF, NQ ; code T(1) nq, e-mail DF,Q, sequence number Q.

every time I finish mapping the NQ fields, and map the Q the IM crashes.

Any ideas why this occurs ?

Regards,

Anita

former_member201266
Contributor
0 Kudos

Hi anita,

Sorry I dont have any idea why such thing happens, when using IM for me it cracshed some times but not always; check the data properly; the data lenght and the type etc.. it will be either u mis Map wrong fields. Any ways if you could provide me ur mail id; i have a document which i can send you; it might help you a lot.

Regards,

CHARAN

Former Member
0 Kudos

hi charan, appreciate all your help ,pls sned the document ot anita_m_george@yahoo.com. thanks ,anita