Hello Kyle, Actually, I'll test again before committing, but so far it works, here is what I did: patch your base_external_referentials/external_osv.py, in method "oeid_to_extid" around line 46, just before the line: result = self.get_external_data(cr, uid, self.external_connection(cr, uid, self.pool.get('external.referential').browse(cr, uid, external_referential_id)), external_referential_id, {}, {'id':id}) add: if context.get('alternative_key', False): id = context.get('alternative_key', False) result = self.get_external_data(cr, uid, self.external_connection(cr, uid, self.pool.get('external.referential').browse(cr, uid, external_referential_id)), external_referential_id, {}, {'id':id}) Admittedly, this is a bit hugly to patch an abstract module just because of Magento, but it's really the simpler, so so far... Then we also need to change the product mapping in order to tel we want to use that 'alternative_key'. So in OpenERP client, edit the instance 'sale.order.line' mapping, then edit the product_id field mapping and add the following right at the beginning of the mapping: context['alternative_key'] = data['sku'] Try to import again, this will do the job and force OpenERP to lookup Magento products by sku when importing order. Luckily enough, after import, we properly continue to read the product_id field in the Magento answer and we continue to use that product_id key as the cross reference in OpenERP. Can you confirm it works for you too? BTW, Olivier Dony from OpenERP SA pointed me to the following link on Twitter http://www.fontis.com.au/blog/magento/api-product-ids-vs-skus it seems it's a know issue. I can't believe they did that. I implemented myself a polyvalent database id / absolute string id lookup on the OOOR OpenERP Ruby connector, but at least I test the nature of the field before doing anything wrong silently. They are really kidding. Thank you to provide feedback, I'll probably commit Sunday or Monday. On Sat, Dec 11, 2010 at 10:24 PM, Kyle Waid