Bump

Hey Kevin - Let me see if I can find someone from IFS to help. Leaving this up in case customers or partners have advice!

My working idea so far is to migrate those Sales and Marketing Companies as Customers first, then when the migration is complete, do UPDATE queries against CUSTOMER_INFO_TAB.CUSTOMER_CATEGORY and VMO_COMPANY_TAB.IDCODCCA to demote them back to P:rospects.

This feels less invasive than writing directly to the tables to create Person and Customer Contact records. I’m trying to reinvent the fewest wheels.

Hi @Mohamed Infaz,
Any thoughts and help on this or any member who could assist?
Thanks & Best Regards,
Yasas 

• Hi @durette, we did a migration from SaM to Apps10 and while we did not had to migrate the contacts, we experienced some other issue with it.
  
  First the IFS Standard scripts are run. In our case, the customer were already included into the core IFS and we only added the SaM Configuration on top with Scripts. We ran into the issue, that the configured “Prospect” Category was lost during this process and all of them are converted to “Customer”, since this was the only setting available in the legacy version of Apps 8. 
•  
• In this scenario,we already got all the contacts we needed and did not write a specific script for that. So sadly no scripts, but you can ping me, maybe I can help you out with some experience sharing.
   

Thanks. We saw that and addressed it by adding the basic data.

DECLARE
   info_       VARCHAR2(32767);
   objid_      VARCHAR2(32767);
   objversion_ VARCHAR2(32767);
   attr_       VARCHAR2(32767);
BEGIN
   BEGIN
      client_sys.clear_attr(attr_);
      client_sys.add_to_attr('IDCOD', 'cca.PC', attr_);
      client_sys.add_to_attr('IDCNA', 'CCA',    attr_);
      vmo_base_code_api.new__(info_, objid_, objversion_, attr_, 'DO');
   EXCEPTION WHEN OTHERS THEN
      dbms_output.put_line('ERROR calling vmo_base_code_api.new__: ' || SQLERRM);
   END;

   BEGIN
      client_sys.clear_attr(attr_);
      client_sys.add_to_attr('IDCOD',     'cca.PC',   attr_);
      client_sys.add_to_attr('IDLNG',     'en',       attr_);
      client_sys.add_to_attr('CODEDESC',  'Prospect', attr_);
      client_sys.add_to_attr('SORTORDER', 0,          attr_);
      vmo_base_codedesc_api.new__(info_, objid_, objversion_, attr_, 'DO');
   EXCEPTION WHEN OTHERS THEN
      dbms_output.put_line('ERROR calling vmo_base_codedesc_api.new__: ' || SQLERRM);
   END;

   BEGIN
      client_sys.clear_attr(attr_);
      client_sys.add_to_attr('IDCOD',     'cca.PC',   attr_);
      client_sys.add_to_attr('IDLNG',     'pro',      attr_);
      client_sys.add_to_attr('CODEDESC',  'Prospect', attr_);
      client_sys.add_to_attr('SORTORDER', 0,          attr_);
      vmo_base_codedesc_api.new__(info_, objid_, objversion_, attr_, 'DO');
   EXCEPTION WHEN OTHERS THEN
      dbms_output.put_line('ERROR calling vmo_base_codedesc_api.new__: ' || SQLERRM);
   END;

END;
/
COMMIT;

Any further thoughts on Contacts, anyone?

Bump

To link a contact to Apps, the contact must be assigned an address ID. That address comes from VMO_ADDRESS.

Inside SaM, when you link a Company in the GUI, it does more than just create the Customer and change the state field. It also creates records in VMO_ADDRESS. The creation of the VMO_ADDRESS records doesn’t come from a trigger; that’s an explicit call made by the application.

In order to replicate this in a script, I’m now calling VMO_ADDRESS_API.NEW__ to create the addresses after changing the company status but changing the contact status.