http://ofbiz.116.s1.nabble.com/OFBiz-Users-Application-for-industry-regulator-tp136104p136106.html
Thanks for the responses on this. I have had some time to look at these
to be dependent of their usernames. Although all users (once logged in)
next couple of days. Forgive me if this is detailed there.
On Tue, October 11, 2005 3:51 am, David E. Jones wrote:
> Ian,
>
>
> It seems like it all you are trying to do is gather information from
> them, or rather, have them maintain their own information, then maybe it is
> best to do a little customization of UI and/or permissions and let them
> login and create/update products (using the existing role limited catalog
> admin permissions), and use something like the ecommerce profile pages
> (perhaps in a new app, ie throw references/
> view-maps to the screens in a new controller.xml file).
>
> If they are going to be running other parts of their business or
> doing _anything_ other than entering this very specific information then
> you would probably want separate instances. If you might want to encourage
> them to run their own instances in the future, then maybe building a data
> push bridge with remote service calls as well as manual entry might be
> needed.
>
> Best of luck, or as would be said there, cheers!
> -David
>
>
>
> On Oct 10, 2005, at 5:42 PM, Ian Gilbert wrote:
>
>
>> Good evening list :)
>>
>>
>> I am hoping to use Ofbiz as a base for an industry regulator. It
>> has the following characteristics.
>>
>> 1. There are 100 member companies. 80 of these are unique whilst the
>> others are 'branches' of other members. These are nearly all importer
>> organisations. 2. The requirement is to allow 'members' to add product
>> and company information for the production of a 'catalog'. Historically
>> this catalog has been printed out once a year and sent to members. It is
>> more a list of members information than a list of product information but
>> they would like to include some of this information in the printed
>> catalog and allow access to the other information through the website. 3.
>> Access to this information would be via subscription (I think that
>> this might work in the same way as the subscription service to access the
>> Ofbiz docs) which is all the 'ecommerce' portion of the site would
>> sell (i.e. it would not sell the products from all the different
>> companies). 4. It is possible, although is not an initial requirement,
>> that the member companies might employ other functional business modules
>> of Ofbiz.
>> 5. Although many of these companies source unique items, there are a
>> number of products that are shared amongst member stores. In addition to
>> this, items are traded between stores. In some cases the suppliers of
>> these stores have inventory that they would like displayed (and will
>> pay for this).
>>
>> I am aware that support for Multi-companies in Ofbiz is not
>> supported out of the box and I agree with this position.
>>
>> Is Ofbiz the correct choice for this deployment? I have run Ofbiz
>> for a couple of small orgs in single company mode for some time but am
>> having some problems working out the implications. There seem to be
>> several options that I could adopt. I would like to get the opinions of
>> those on the list before starting.
>>
>> The options that I see are:
>> 1. Use multiple instances of Ofbiz, one for each company, draw the
>> company contact information as well as any product information from
>> separate databases (probably going in 'above' Ofbiz). Allow the
>> proprietors of the stores to maintain their own information (there is a
>> definite UI implication here). 2. Use multiple instances of Ofbiz, one
>> for each company, but store only company information in this. Have
>> another instance - 'Industry Regulator'
>> which contains the product information. In the future populate the
>> websites of the companies with products drawn from the 'Regulator'
>> instance (probably using WS). Give each 'proprietor' access to their
>> own products and maybe separate these using categories. Advantage is
>> that products are centralised making reporting easier. Disadvantage is
>> that this seems a complex method of doing it and would require careful
>> analysis of the 'roles' allocated to proprietors (this is probably
>> unavoidable though). In this case the actual company specific instances
>> could be gradually made available by module as the subscription model is
>> developed (e.g. For the lowest level of subs you would just be able to
>> add people to your system through the 'Party Manager' thereby giving them
>> the ability to add/modify/delete product info in the main instance whilst
>> a higher level might give you a trading site etc.,). There remains
>> issues with the UI as NONE of these proprietors will be happy with conf
>> file maintenance. I am happy to do this for three instances but 100?
>> This may cause
>> maintenance problems. 3. Store the company details in a separate database
>> and manage everything through one 'Regulator' instance. This would have
>> the advantage of being very simple but wouldn't be able to exploit the
>> other elements of the system unless we made a large number of mods which
>> would, inevitably, permanently fork our setup - something I am not keen
>> to do as we lack resource to support this even in the medium term.
>>
>> Writing this has been useful. I am now favouring number two but would
>> value other opinions and comment. I will be happy to provide further
>> information on our setup if this would be considered helpful.
>>
>> Thanks and very best wishes
>>
>>
>> Ian
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/users>>
>>
>
>
> _______________________________________________
> Users mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/users>
>