Hi Danny
For version 4.0 you will
expect to find the vast majority of the DIS layers merged into the SYS layer. And
as a new thing we are actually striving to deliver all layers at the same time –
that means there will not be a 3 months interval between the SYS release and
the DIS layers release. I cannot promise you that this will happen for Service
pack 3 as well, but I know that all our country offices are actually also
trying to meet the service pack 3 release date as well. They are now in the
development loop together with the rest of the development team.
In the case of the
contact person name field – please check the fix list for service pack 2,
because the change was actually made for CRM, as far as I remember.
That case is
unfortunately a classical example of unfortunate events – because normally
corrections like that should not be made in a service pack. However there were
some problems that needed to be fixed. Normally all country offices do a walk
through of the corrections for the service pack and test with their respective DIS
layers in order to ensure that these things do not conflict with other DIS
corrections – that happens before fx. the service pack is critical test
completed. If the country office finds some issues they release a newer DIS
layer that will take care of the problems.
When building a major
release the development circle is long and very tedious. And there are many
rules to apply by, however we need to build the whole version, and run a side
track for the DIS layers, because some of the DIS layers functionality will
have to either be changed or singled out as we develop along. As you all know
Axapta strives towards generic design, meaning if a new taxation rule suddenly
comes up in fx. Germany
and the German office creates a temp. solution in a DIS layer to comply with
the legal demand (of course they will try to provide the correct solution from
the beginning allowing us just to ‘plug’ it in later in the
release), we will have to investigate what it takes to build it in with the
standard taxation engine – only separating it with a configuration key.
You may probably not
expect that all DIS layers will be merged to the SYS layer in 4.0 – especially
the Russian DIS layer is so huge that it actually has a size more or less the
same as the standard application. It takes a very long time to investigate such
a layer and split it apart in order to just ‘plug’ it in. But all
the other official DIS layers will be part of the 4.0 development circle. We
have a separate team in development only focusing on global development
localization.
If you for any matter
experience problems like the one you described please let the country office
know in order for them to pass on that knowledge to the localization team and
allowing us to fix it. Contrary of what people may think, we actually try to
fix as much as we can – but anyone working in developing a standard ERP
solution will know that at some point in time the window for correcting and
developing will be closed for a release in order to enter into stabilization
and test.
Best regards
Mai-Britt
From:
Danny Gaethofs [mailto:[EMAIL PROTECTED]
Sent: 2. marts 2004 19:01
To: [EMAIL PROTECTED]
Subject: RE: [development-axapta]
Mutli-Country Implementation - Single Database
Thanks for sharing your experience.
It seems there are a lot of problems to overcome before one can easily
execute a global roll-out over several countries.
When can we expect the new release AND will all the current DIS layers
be integrated?
What kind of development rules exist for the country localizations?
For example I am trying to install the Belgian DIS layer on top of SP2
and I am getting errors on the field contactpersonname. Apparently a new field
has been added to the CompanyInfo table. What happens if other countries
implement the same field but for other purposes? Or do you have rules that
prevent these kind of things.
"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!
Kind Regards
Danny Gaethofs
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/SIG=12c63lig6/M=274551.4550177.5761904.1261774/D=egroup
web/S=1705006764:HM/EXP=1078058127/A=2019528/R=2/SIG=141cnn6h7/*http:/ad.dou
bleclick.net/jump/N3349.yahoo1/B1282054.27;abr=!ie4;abr=!ie5;sz=300x250;code
=18634;dcopt=rcl;ord=1077971727683696?>
Click HereClick Here
_____
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]
<mailto:[EMAIL PROTECTED]>
* Your use of Yahoo!
Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/>
.
> ATTACHMENT part 2 application/ms-tnef name=winmail.dat
Do you Yahoo!?
Yahoo! Search - Find what
you’re looking for faster.
Yahoo! Groups Links
