在 Microsoft Dynamics CRM 3.0 中重新处理分销商/客户的纠缠
我继承了 MS CRM 3.0 的实现,其中每个联系人都被分配给一个特定的“分销商”。不幸的是,经销商并没有被定义为任何类型的实体。相反,联系表单被修改为包含包含经销商名称和地址的额外字段。
到目前为止,每次经销商地址发生变化,或者修改经销商的邮政编码区域时,外部自定义应用程序和数据库都会提取并修改每个联系人以反映这些变化。
我对 MS CRM 完全陌生,我很想听听是否有人有想法,允许我以这样的方式添加经销商,以便可以在 CRM 中的一个地方修改他们的名称/地址,这可以链接到个人联系人。
有想法吗?
I've inherited an implementation of MS CRM 3.0 where individual contacts are each assigned to a particular "distributor." Unfortunately, distributors are not defined as any sort of entity. Instead, the contact form was modified to include extra fields that contain the distributor name and address.
Up till now, each time the distributor address changed, or the zip-code based regions for the distributors were modified, an external custom app and database pulled and modified every contact to reflect these changes.
I'm completely new to MS CRM, and I'm interested to hear if anyone has ideas that would allow me to add Distributors in such a way that their name/address can be modified from within the CRM in one place, and that can be linked to individual contacts.
Ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
不幸的是,消除这种混乱的唯一方法将涉及大量的数据清理和迁移工作。我会尝试使用现有的帐户实体,并简单地放置一个“类型”字段将其标记为经销商。通过这样做,您可以获得许多出色的开箱即用功能。
无论您选择哪一个选项,无论是开箱即用的实体还是新实体,您都需要使用数据迁移包(例如 Scribe 或 DTS for SQL)将数据从联系人移动到新实体。
Unfortunately the only way to undo that mess would involve a large undertaking of data cleanup and migration. I would try to use the existing account entity and simply place a "type" field to mark it as a distributor. You get a lot of great out of the box functionality by doing so.
Whichever option you choose, whether it's the out of the box entity or a new one, you'll need to use a data migration package such as Scribe or DTS for SQL to move the data from the contacts to their new entity.
老实说,我认为解决这种情况不需要大量代码。如果你要给你基本的想法,我将编写伪代码 - 我认为从长远来看,这可能最终是最好的长期解决方案。
首先创建一个Distributor 自定义实体。根据需要在联系人/帐户之间创建关系。然后使用下面的伪代码 - 填写适合您情况的具体内容。运行它。然后您可以删除那些不必要的属性,然后就可以开始了。
To be honest, I don't think it would be a ton of code to unmuck this situation. I'll pseudo code if for you to give you the basic idea - I think in the long run this might end up being the best long term solution.
First create a Distributor custom entity. Create a relationship between contacts/accounts as appropriate. Then take the pseudo code below - fill in the stuff specific to your situation. Run it. Then you can remove those unnecessary properties and you should be good to go.