This is a MUST to be…

[alraaayeq]

Hi all,


This is my first post here, I hope this is not a duplicated thread..


I looked over the Sugar’s demo and sample data; I got surprised that there are no numeric UNIQUE IDs for accounts and other enteritis instead the used entity’s name. I wonder how the software could operate without them…take for example if I have account called ‘Mohammed Ali’ definitely we will encounter another new customer called ‘Mohammed Ali’, what should I do in this case?

SugarCRM will lose many features, mainly when you talk about integration…I hope developers here comment on this, Is my finding correct!!!? And what did they used to do to over come such thing…



Thanks,

[longreach]

I must say, I have seen this request from a few other clients - for Accounts, and for several other objects in the system.

[alraaayeq]

I must say, I have seen this request from a few other clients - for Accounts, and for several other objects in the system.

Good!

and how did you meet their requirements?

[george_bbch]

Good!

and how did you meet their requirements?

Hi alraaayeq and welcome to the forum
In our scenario we have another system (ERP) where we maintain the accounts (including the bookkeeping stuff). So the account number is generated there. Until we will create a link between the two systems to syncrhonise this info, we have to manually enter / update / delete it using a custom field that can be easily defined using Studio.

Hope this helps!
George

[alraaayeq]

Hi alraaayeq and welcome to the forum
In our scenario we have another system (ERP) where we maintain the accounts (including the bookkeeping stuff). So the account number is generated there. Until we will create a link between the two systems to syncrhonise this info, we have to manually enter / update / delete it using a custom field that can be easily defined using Studio.

Hope this helps!
George

Thanks George!


Doing things manually means the software does not give what was expected from it (with addition to other issues likes errors rates will be higher …etc) ,also it is not how you did it (i.e. in your ERP) , rather the software do not allow you to automate/enhance things by this kind of backbone restrictions.

Moreover, it will be frustrating to start implementing a new UNIQUE keys mechanism and later on you might find it does not work smoothly ( here in this forum a guy mentioned his experience in implementing such thing , at the end still he gets more troubles..)


I guess I reached a show stopper point and I could not continue using SugarCRM any more …

[george_bbch]

Thanks George!

You're welcome!

Doing things manually means the software does not give what was expected from it (with addition to other issues likes errors rates will be higher …etc) ,also it is not how you did it (i.e. in your ERP) , rather the software do not allow you to automate/enhance things by this kind of backbone restrictions.

In the past 3 years I've evaluated a couple of dozens of CRM systems, some of them quite thoroughly, others just at the surface. Some of them were actually integrated CRM / ERP systems. Out of this experience:

- if you have 2 separate systems CRM - ERP (and you need them both), you'll always have a sync issue with addresses, products and orders-deliveries/credit notes-returns, no matter what the name of the systems are. At least according to our approach that defines the CRM system as "all about the customer". So, we've identified your kind of problem as major, but not really a killer criteria - see also below.
Nota bene: If you have other systems, as well (webshop, product management system), things get even more complicated.

- a dedicated CRM system tends to be better (with respect to features) than an integrated one

- we are moving to Sugar because of the benefits it offers us, which are more important than the disadvantages; we are aware of drawbacks like this, we will live with them for a while and improve/fix them over time.

Moreover, it will be frustrating to start implementing a new UNIQUE keys mechanism and later on you might find it does not work smoothly ( here in this forum a guy mentioned his experience in implementing such thing , at the end still he gets more troubles..)


I guess I reached a show stopper point and I could not continue using SugarCRM any more …

I wonder what alternatives your're considering.

Regards,
George

[longreach]

Good!

and how did you meet their requirements?

In our case, we added to the base code a field that auto-increments, and added it to the various display screens. Not using Studio.

[alraaayeq]

You're welcome!


In the past 3 years I've evaluated a couple of dozens of CRM systems, some of them quite thoroughly, others just at the surface. Some of them were actually integrated CRM / ERP systems. Out of this experience:

- if you have 2 separate systems CRM - ERP (and you need them both), you'll always have a sync issue with addresses, products and orders-deliveries/credit notes-returns, no matter what the name of the systems are. At least according to our approach that defines the CRM system as "all about the customer". So, we've identified your kind of problem as major, but not really a killer criteria - see also below.
Nota bene: If you have other systems, as well (webshop, product management system), things get even more complicated.

- a dedicated CRM system tends to be better (with respect to features) than an integrated one

- we are moving to Sugar because of the benefits it offers us, which are more important than the disadvantages; we are aware of drawbacks like this, we will live with them for a while and improve/fix them over time.

Well, I will keep your valuable points in my head..

I wonder what alternatives your're considering.

Regards,
George

Yah, Honestly nothing planned, except I will search for some....


Thanks again

[alraaayeq]

In our case, we added to the base code a field that auto-increments, and added it to the various display screens. Not using Studio.

I noticed that there is a built in id field in entities tables, I wonder if you replaced them with the new one , or as addition to it.

And it will be great if I can estimate/share the required efforts needed to implement this enhancement ( in terms of time? , how many files? ,major issues and lessons learned ..etc)



Thanks again.

[malcolmh]

If you are going to use SugarCRM data as the primary source of customer contact data, then you can use the internal ID generated by SugarCRM for Accounts and Contacts and transfer this ID to other systems such as billing systems or whatever.

If your primary customer data is coming and only coming from another system i.e an ERP system, you can either add an additional field in Sugar or use this number when importing instead of the Sugar internal ID number, displaying the number in the dialogs.