you are right on the money there ...... configs.
should be by company not by the applicaction.
Regards,
Anders
--- "Gert Neetesonne (Hotmail)"
<[EMAIL PROTECTED]> wrote: > Unfortunately,
MBS is promising our customers that
> Axapta is an application
> which is proven for multiple countries, and leaving
> us partners with the
> trouble. Partners have to merge DIS-layers
> themselves (for which customers
> do not want to pay), and MBS refuses to import these
> merged layers in a
> "customized" DIS-layer.
>
> Good strategy, because that way, they can sell an
> extra BUS-license on the
> back of the customer. If the customer does not want
> to buy it, the merged
> local version mixes up with the tailor made software
> in the VAR-layer
> (making upgrades crazy)
>
> Moreover, when a new release or major comes out, it
> takes up to 3 months
> before all new DIS-layers are released.
>
>
>
> Now MBS is also merging DIS-layers, but they aren't
> usable if you have an
> installation with companies from more than country.
> The country specific
> functionality is linked to a configuration key. A
> configuration key can be
> switched on or off for the whole application (i.e.
> for all companies). So,
> you should switch on all keys for all countries you
> have. In the code, they
> check if a configuration key is enabled to execute
> code. This implies that
> in an installation with Belgian and Dutch
> functionality the functionality
> for both countries will be executed, and not one of
> them.
>
> Of course, this implies that modifications are still
> necessary, even if
> layers have been integrated.
>
>
>
> Seems we still have a long way to go.
>
>
>
> Gert Neetesonne
>
> EDAN Business Software
>
>
>
> _____
>
> From: Mai-Britt Winther (MICROSOFT BUSINESS
> SOLUTIONS)
> [mailto:[EMAIL PROTECTED]
> Sent: zaterdag 28 februari 2004 13:51
> To: [EMAIL PROTECTED]
> Subject: SV: [development-axapta] Mutli-Country
> Implementation - Single
> Database
>
>
>
> Hi Danny
>
>
>
> MBS developement is for every major version merging
> existing DIS layers -
> however you will find that for example the Russian
> DIS layer is a tricky
> layer to merge, since that layer i huge.
>
>
>
> All other layers will try to keep their pieces of
> country specific
> functionality to a bare minimum thereby enabling us
> to easier merge these
> pieces into a new version.
>
>
>
> Having written this - we have a team at MBS who is
> concentrating on merging
> these DIS layers into the next major release - in
> this case 4.0. However in
> the meantime, partners would have to merge the DIS
> layers themselves, if
> they require and choose to run with more than one
> DIS layer on the same
> installation.
>
>
>
> Best regards
>
>
>
> Mai-Britt
>
>
>
> _____
>
> Fra: origaet [mailto:[EMAIL PROTECTED]
> Sendt: lø 28-02-2004 13:35
> Til: [EMAIL PROTECTED]
> Emne: [development-axapta] Mutli-Country
> Implementation - Single Database
>
> Dear all,
>
> I am investigating how a world-wide roll-out of
> Axapta can be
> established using one central database.
>
> The biggest problem I see at current is related to
> the Country
> Specific layers, whereas these are developed by each
> MBS Country
> Team.
>
> Possibly, whithout having it investigated, these
> country layers can
> have contradictionary approaches. Most likely, there
> are country
> layers that have upgraded the database with new
> fields and even
> tables.
>
> In previous topics I read suggestions that the
> different country
> layers (DIS, DIP) should be merged.
> If however the database schemes are different
> between country layers
> merging the layers will results in greater
> inconsistencies.
>
> Having to investigate all the different layers to
> find out what is
> matching and what not, and thereafter perhaps
> applying all the
> differences to one base country layer becomes
> unfeasible.
>
>
> I recognize two possible situations.
>
> Situation 1
> If database schemes are identical, one could
> consider installing
> an application for each layer.
>
> Situation 2
> If database schemes are different, one will have to
> patch all the
> country layers into one big layer. Apply the
> database changes made
> by every country to the central database, validate
> all the country
> application layers, and hope all of it works.
>
>
>
> I have a few questions about the subject:
> 1. Is there some kind of standardized development
> rule to avoid two
> or more countries apply similar - but not precise
> the same -
> database changes. Maybe by giving each country
> seperate ranges for
> naming tables, fields, etc...
>
> 2. What experiences do we have with inconsistencies
> between
> different country layers - especially database
> schemes.
>
> 3. In case of situation 1 is there a way to use one
> central
> application. I am thinking about determing the
> country layer to use
> based on logon parameters.
>
> 4. Are there more issues besides the country layers
> that should be
> investigated thoroughly for this kind of roll-out.
>
> 5. Is MBS planning to do some about this problem,
> for at least the
> aim is to also cover global companies.
>
> All information is welcome!
>
=== message truncated ===
> ATTACHMENT part 2 application/ms-tnef
name=winmail.dat
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
| Yahoo! Groups Sponsor | |
|
|
Yahoo! Groups Links
- To visit your group on the web, go to:
http://groups.yahoo.com/group/development-axapta/
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
