Displaying international Product Catalogue

Hi Community,

has someone ever faced the challenge to display an international Product Catalogue?

Imagine you have a world wide company selling the same items but using their local product names (i.e. used on printing the Quote in local language).

In SugarCRM Products are records and records requries a (one) name. This ends in setting up the same items with different names depending on the amount of languages you use in the world. OFC reports can be adjusted and based on a common item code but you loose the out of the box reporting/forecast/ functionalities at least in SugarCRM Enterprise when you configure it on line item / product base.

Not enough all SugarCRM User see all the product items you have in the product catalogue due to missing teams are available on Product Catalogue. Using Product Types or categories for displaying a country/subsidarie and linking the local product items to it may bring order to chaos a bit but does not realy solve the overall pain.

My question is: Have I completely missed a way to display this out of the box and someone can give me a hint?

I'm fully aware of that you can solve some or all parts of the described by using custom code but in this case it is not the way I want to go with it.

Looking forward for your input / discussion!

Best regards

Björn

  • Hi Björn Canales Pfisterer 

    Definitely we faced this challenge a couple of times in the past.

    There we go:

    Introducing Teams in the Product Catalog module is a piece of cake, indeed we had done that for some customers in an upgrade safe and packageScan safe way.

    It is also easy to automatically inject in the GRID under Quotes a filter according to the Language's Team of authenticated user. That means, a given User will only be able to choose Products which share the same Teams the own User is related to.

    These strategies also can be accomplished in the GRID under Opportunity.

    Regards

    André Lopes
    Lampada Global
    Skype: andre.lampada
  • Thanks André Lopes,

    that describes how we do it too. I might have mentioned initially that I'm working at a SugarCRM Partner ;-)

    To be honest it works in a way but as it is not "standard" you are always a bit away of core functionalities also limiting the use of them.

    My thinking is that I really like the flexibility of SugarCRM and the ability of doing customisations with out of the box functionalities quickly, on the fly and mostly without downtime or user interruption. On this part SugarCRM has given us awesome new features like adv. processes etc. and is adding new things (features) quickly. And if this is not enough, just type down some code as a hook and add your extension quickly. Love it!

    But sometimes I see that this flexibility is so sweet that SugarCRM enthusiasts forget to think about what they do. Is a custom code extension the first choice?

    Some days ago I had a very good call with a customer who told me 'Sometimes it makes me sad that we are spending so much effort (money) in keeping existing custom code functionalities to be up to date with every new update. I would like to see lots of 'expected core' functionalities coming from the product, get rid of old code and invest this money to sexy features that adds an extension to our CRM instead of completing the lacks in some (unfinished) parts of this Software'

    You know what? He is right.

    I totally agree in trying to solve everythig with out of the box abilities - sometimes with waiting for the next version that adds a missing link to finish it.

    Also setting up enhancement requests on SugarCRM Support.

    Only in case of nothing helps I think about custom code for covering basic CRM requirements.

    Uff, wall of text for just explaining why I posted this thread but I would like to open a discusssion about this how this could be displayed out of the box in SugarCRM rather than just setting up an idea that does not met the common thinking and get lost in "no votes" ;-)

    Would really love to see SugarCRM staff join this thread

    Cheers

    Björn

  • I got the point.

    SugarCRM is an amazing CRM platform, flexible at an user perspective and at a developer/admin perspective as well.

    Indeed I believe it is the most flexible CRM platform to date.

    But in another hand it is impossible for SugarCRM staff to make it widefly flexible the way anyone could do anything through Studio.

    So SugarCRM invites developers to explore the hooks available in the framework so additional features can be accomplished for some specifc or even generic solutions.

    The question is: you better be carefull on extending some framework component so it will not affect a future upgrading or it will not stop working after an upgrading.

    Certainly we have no control on future changes in the framework architecture so eventually we may face some situation on upgrading.

    It is important to explain the risks to customers.

    In short words there are some topics to invite SugarCRM staff to talk about:

    • Upcoming constrains on silentUpgrade (currently it has been the big deal on upgrading)
    • Changes at the framework architecture which may affect customization stability, specially the ones which used to work without big deal

    Regards

    André Lopes
    Lampada Global
    Skype: andre.lampada
  • all well said but the lack of a translation option is a general issue. Duplicating products just to have a translation of a name will create a mess once you start talking about reporting and analytics, also if you want to interface to an ERP etc ... typically in larger scale implementations there is  need to have also products transferred from an ERP Systems (like SAP or others) and there the produzcts come with way more information and translations in multiple languages. 

    We ended up in the meantime in building our own standard product management module that holds hiorarchical product groups, product attributes, products, product variants, different units of measures. A more flexible pricing engine is next on the agenda. Of course you can ask the question if this shoudl be part of a CRM solutiopn .. but when you start talking CPQ ... yes it is essential. 

  • Exactly, that' what Im facing regulary. A different story can be how to display "service products" like consulting based companies have which does not have list prices but contract based prices. What to do when the agreed service price per day is above the set "list price"? Giving negative discount? but that's another topic. Introducing service products and contract periods is a further topi.

    But:

    typically in larger scale implementations there is  need to have also products transferred from an ERP Systems (like SAP or others) and there the produzcts come with way more information and translations in multiple languages. 

    Now imagine you have diferent local ERP systems all over the world....

    Anyway, first help can be to separate local product catalogues by implementing teams to products.

    OFC you are still not able to use products based standard reporting functionalities and dashlets but you can create reports based on "itemnumber" which can connect multiple records for the same item with different names.

    Best Regards

    Björn

  • Hi Björn Canales Pfisterer,

    I have the same question and stumbled over this thread just now,  thank you for posting the question initially!

    We already have activated Teams in the Product Catalogue, but we don't use it to separate languages, but for the separation of our different kinds of Sales Teams - so each team member only sees products relevant for their kind of sales work.

    Luckily, a bilingual Product Catalogue is enough for us at the moment, so that each product in our catalogue has a German-English double-name looking like this: Name German | Name English. So, if the English speaking guys want to look up a product directly via typing, they have to remember looking it up with "%Name English", otherwise they won't get results. This is really annoying, but we can live with it for now and it ensures, that each product exists only once and we can report everything nicely.

    But, just like you, I was and still am hoping for a more elegant way of achieving multi-language in the product catalogue. ;-)