You may run into problems with enumerated properties if you assign option codes that collide with option code values assigned by an ATG product. As an example, consider the case of payment groups in ATG Commerce. ATG Commerce defines 3 payment group subtypes with values 0, 1, and 2. Suppose you define an additional 3 payment group subtypes with values 3, 4, and 5. If the next ATG release of ATG Commerce were to add two new payment group subtypes with values 3 and 4, these values would collide with two of your additional 3 payment group subtypes using these same values.
In order to avoid collisions between option codes used by your repository definition and any option codes used in subsequent ATG products, you should observe the following convention in assigning option codes to enumerated property values:
Project | Reserved Option Code Values |
|---|---|
customer use | 0 - 999 (Note that some of these values 1 – 100 might already be used in older ATG versions. Check the repository definition file for the property in those cases. It may be better to limit your option code values to 101 - 999.) |
DAF | 1000 - 1999 |
DPS | 2000 - 2999 |
DSS | 3000 - 3999 |
ATG Commerce B2C | 4000 - 4999 |
ATG Commerce B2B | 5000 - 5999 |
ATG Portal | 6000 - 6999 |
ATG Outreach | 7000 - 7999 |
ATG Content Administration | 8000 - 8999 |
ATG Ticketing | 9000 - 9999 |
ATG Knowledge and Self Service | 10000 - 10999 |
ATG Commerce Service Center | 11000 - 11999 |
ATG Response Management | 12000 - 12999 |
ATG Search | 13000 - 13999 |
Agent | 14000 - 14999 |
ATG Chat | 15000 - 15999 |
future ATG use | 16000 + |
In the unlikely event that you need more than 1000 separate values for a single enumerated property, you can also use negative integers as option code values.
