Grouping address book numbers

[tombrown]

Hi List,

We are implementing OW across several countries and would like address
book numbers to be grouped by country, for example...

Country 1 100000-199999
Country 2 200000-299999
Country 3 300000-399999

This is not a problem for converting data since we have control of the
numbers in our own programs, but once in a live environment and users
are entering new customers etc. how would we keep them to their ranges
without modifying address book entry? As I see it there in only one
next number and since that is attached to the AN8 field that will be
the one to be used

Thanks in advance

Tom Brown

=====
Please reply to [email protected]






__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one Place.
http://shopping.yahoo.com/

 

[tull]

There are a few ways to do this.
First because the people are at different locations are they accessing the same database or is the database replicated to each location. If the data is replicated to each location you can simply change the Next number at each location to start at the desired range.

Otherwise you can create a processing option that signifies which Next number index to use and make multiple versions of the Address Book. This will require changing the application to retrieve the Next number from some custom Next Number system (55 - 59) and pass the Processing option in as the index to retrieve. You may need to do some research to ensure that all Address Book entries are being made from P01012.

Good Luck
Tull

 

[pcaenaro]

Hi Tom,

did you try to setup your Next Numbers by Company?
If you have one (or more) company by country, that could solve your problem

Hope this helps

Philippe
----- Original Message -----
From: tombrown <[email protected]>
To: <[email protected]>
Sent: Wednesday, November 08, 2000 10:40 PM
Subject: Grouping address book numbers ~~0:748


> Hi List,
>
> We are implementing OW across several countries and would like address
> book numbers to be grouped by country, for example...
>
> Country 1 100000-199999
> Country 2 200000-299999
> Country 3 300000-399999
>
> This is not a problem for converting data since we have control of the
> numbers in our own programs, but once in a live environment and users
> are entering new customers etc. how would we keep them to their ranges
> without modifying address book entry? As I see it there in only one
> next number and since that is attached to the AN8 field that will be
> the one to be used
>
> Thanks in advance
>
> Tom Brown
>
> =====
> Please reply to [email protected]
>
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Thousands of Stores. Millions of Products. All in one Place.
> http://shopping.yahoo.com/
>
>
>
>
> --------------------------
> To view this thread, visit the JDEList forum at:
>
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OWDEV&Numb
er=748
> *************************************************************
> This is the JDEList One World / XE Developers Mailing List.
> Archives and information on how to SUBSCRIBE, and
> UNSUBSCRIBE can be found at http://www.JDELIST.com
> *************************************************************

 

[Zoltan_Gyimesi]

Tom,
I do not recommend the method changing PO Template of the Address Book (P01012)application. My arguments are:
* Address Book is accessible from many other applications.
* You have to delete or secure all previously existing version to ensure to use your versions, so users will lose the possibility to access Address Book from the other applications.
* By my opinion and experiences, it is not a good habit generally to modify the PO template of an original OneWorld application or UBE, mainly not for such a general used applications like this.
(... excuse me Tull)
Zoltán

 

[Zoltan_Gyimesi]

Tom,
If your users in different countries are working on the same database and "Next Numbers by Company" doesn't work for you then hardly possible to resolve your problem without changing P01012.
If you have decided to make some minor changes in P01012 then here is some tips from me.

First you have to be able to differentiate the users by country.
You can use the informations in the users profile to do it.
The most obvious for this task is the "Localization Country Code", moreover this is a cached value, so you can access it always as SL System Value in the ER codes.
There could be a side effect assigning Contry Code to the users:
if localizations exist for the specific country then it will get live for the user and maybe it is undesirable for you. If it is so, then you can add "dummy" Contry Codes to 00/LC UDC type (Localization Country Codes) like X001, X002, X003, etc. to identify the country and make sure that Localization won't be exist.

Second:
* Setup next numbers for the countries under 55xx-59yy systems.

Third:
* Create a NER BSFN to encapsulate your special logic for next numbering:
*** determine the appropriate Next Number based on Country Code
*** retrieve the number calling the standard OneWorld NextNumber BSFN
*** (...you can make additional validation on the range here)

Fourth,you have to modify P01012.
* Disable Next Numbering of AN8 on the entry form when it isn't disabled originaly (If I am right, it is disabled and the MBF will determine the number when it is empty).
* Call your BSFN for next number on the start of the Press Button event of OK button putting the number into FC Address Number.

Of cours, it isn't necessarey to create a BSFN, you can put all the logic into the Press Button event.

Could be a good idea to set Disabled or Read Only for AN8 on the entry form, preventing users to enter the number manually.

If you don't want setup many Next Numbers and want to use the original then you can modify the logic above:
**** retrieve the original next number
**** add 1000000*X to the number where X is 1, 2, 3, etc. based on the country code. Of course, in this case you won't have continous numbers inthe ranges.

Please, let me know when you tried this method, how does it work.

Good Luck,
Zoltán

 

[MRiccomini]

Phillipe...


This would not work as the address book is not setup by company but is
common to the entire database....