Skip to content

V8.5 Alpha Document Number Support

← Elliott Version 8.5

The primary reason for this feature is because some Elliott users are running out of invoice numbers and are approaching invoice number 999999. In the past, users could use a special archive procedure to reset the invoice number.  However, there are some limitations with the archive and users may find some minor issues after the archiving.

By using alphabetic invoice numbers, each digit can have the value from 0 – 9 and A-Z. So the maximum number of invoice numbers is 36 * 36 * 36 * 36 * 36 * 36 = 2,176,782,336. This exponentially increases the number of invoices that can be stored in Elliott, so users can avoid resetting the invoice number counter in the future.

For example, in the scenario of the following “Starting Invoice Number” in A/R Setup:
999999 – the next number will be set to 0 and a duplicate invoice can be created.
A99999 – the next number will be B00000.
AA9999 – The next number will be AB0000.
AAA999 – The next number will be AAB000.
AAZ999 – The next number will be ABA000.
AAAA99 – The next number will be AAAB00.
AAAAA9 – The next number will be AAAAB0.
AAAAAA – The next number will be AAAAAB.
AAAAAZ – the next number will be AAAABA

So the number of possible document numbers depends on the number of leading alpha digits the user enters in the Starting Invoice Number in A/R Setup. The system will always maintain that many number of digits of alphabetic characters. For example, if a user enters AAA001 as the starting invoice number, then the left 3 digits will always be alphabetic from A – Z. The right 3 digits will always be numeric from 0 – 9. This is important for the following reasons:
It will be easier to read by establishing a convention of how many alpha digits and numeric digits and their positions.
You may confuse 0 (zero) and O (oh).

Users do not have to make alphabetic or numeric as either leading or trailing, but it should be consistent. For example, the user can enter the following as the starting invoice number:
A1239Z – the next number will be A1240A. So the rules are:
Add 1 to Z = A + Carry over 1 to the left digit.
Add 1 to 9 = 0 + Carry over 1 to the left digit.

The rule is that the digit that’s alphabetic will always be alphabetic. The digit that’s numeric will always be numeric until someone manually changes the starting invoice number. 

The alphabetic document number feature not only applies to invoice numbers, it also applies to most other fields that are considered as document numbers.  This includes, but is not limited to:

Sales order numbers
Work order numbers
A/P voucher numbers
A/P manual check numbers
A/P computer check numbers
Invoice numbers
Inventory Transaction Processing document numbers
BOMP engineering change numbers
Purchase order numbers
Purchase order receiving document numbers
Contract numbers for contract pricing
New EDI import order numbers
Changed EDI import numbers
COP recurring order number
ACH batch numbers
Payroll check numbers
Credit card log numbers)
Web voucher numbers
Web production order numbers
Web sales order numbers
Ship-to purchase order numbers
Physical/cycle tag numbers
A/R cash receipts check numbers
Presales Interface order numbers

Since Elliott’s document numbers were indexed as numeric in the past, if you wish to start using the Alphabetic Document Number feature, you will have to go through a conversion process to re-index these columns as strings. Once you actually store alphabetic document numbers in these fields, there will be no reversing back to the Elliott V8.2 database format. It is unlikely that you will need to go back to the Elliott V8.2 database format due to any Elliott V8.5 issues. But you may use other third party applications -- like Crystal Reports or web applications -- that access Elliott’s data through ODBC or web services. These applications treated Elliott’s document number columns as numeric in the past, so some sort of conversions are required. You will have to handle these conversions on your own. Please refer to:

If you have no need to use alphabetic document numbers, then you don’t have to go through the database conversion immediately. You can continue using V8.2 web services, the V8.2 DDF files and their corresponding database for external applications to access Elliott’s data. Elliott V8.5 will work with the V8.2 database structure without any problem. But we will eventually stop supporting V8.2 web services and DDF, so you still should plan on migrating to V8.5 web services (if you use web services), and using the new V8.5 DDF at some point. This will require database conversion.

The main risk of converting to the Elliott V8.5 database format is that your external applications may stop working. To minimize your risk, we suggest you to take the following steps:

Step 1 - Convert External Applications First

If you use external applications like Crystal Reports or web applications, you should start converting them to become Elliott V8.5 compatible. By default, Elliott V8.5 will create the database name like ELI85DATA. This is based on the new DDF files in the <ElliottRoot>\Bin85\DDF40 folder. We presume you will make a copy of your existing applications to another area when performing this conversion and point to the ELI85DATA database.

While you perform this conversion, you will continue to let your production Crystal Reports or web applications access your V8.2 database (e.g., ELIDATA) and web services.

Step 2 - Convert Database, Test or Live

After you are done with your conversion, to begin using the V8.5 database, like ELI85DATA, you will need to convert your V8.2 data to Elliott V8.5 format. This involves rebuilding the index of many Elliott tables. For example, Invoice Number used to be a numeric field. It is a string field in Elliott V8.5. For all tables that have the invoice number field and are part of the table’s index, you will need to convert those indexes to treat invoice numbers as string fields now. You can do so by logging on to the PSQL server as an administrator, bringing up the command prompt, going to the folder <ElliottRoot>\Bin85, and typing the following command:

            DDF2BTR <ElliottRoot>\DATA\*.BTR

Substitute<ElliottRoot>with the root directory where your Elliott is installed. For example, use “M:\Elliott7.” The DATA is the corresponding DATA folder. It can be DATA, DATA_02…etc., which corresponds to each company. If you have custom modifications with your database, you will specify the path of your custom DDF with the DDF2BTR command. Use DDF2BTR /? to find out the proper command to do so.

When you perform this conversion on the PSQL server, you can estimate about 120 MB per minute. Do not perform this conversion on the client side since the performance will be significantly slower and less reliable. The actual time may depend on many factors. Only convert your Elliott data when no one is using Elliott, including external applications that access Elliott data like Report Writer or web services.

To be safe, you can optionally copy your production company’s data to a new company and perform your database conversion in the new company first, then continue your test with external applications that point to this new company. If the external application tests are successful, then convert your production company data. If you have multiple companies, you may perform this conversion one at a time. You don’t need to convert all of them at the same time. You still can convert the V8.5 database back to the V8.2 format as long as there’s no alphabetic value stored in any document number fields.

Step 3 - Enable Alpha Document Number Support

To enable alphabetic document numbers, you will go to Global Setup -> System -> Comp. Specialized Control.  Answer “Y” to “Use Alpha Document Numbers?”  


The application will present the user with information about converting the database if this is the first time, the option is set to "Y."


Press Enter to continue to the next warning screen.


Each kind of document number is controlled by its corresponding Global Setup flag. You will need to turn that flag on in order to use alphabetic values for that document number.  


Choose the document for which you intend to use alphabetic values.  For example, you may choose to use an alphabetic value for an invoice or sales order number, but not for a purchase order number.  

Choose one of the following options:

  1. Y - This enables alpha document number support with format control.
  2. N - This disables alpha document number support. Only numeric values will be supported.
  3. W - Alpha document number support is enabled and the user will be warned if they attempt to create a document that does not match the specified format.
  4. F - Alpha document number support is enabled and the user can enter any format they like.

If the Y option is chosen, the document number format will be validated when new documents are created (i.e. the enforcement is on Add Mode only.  We do not enforce on change mode because there could be document in different format created previously). If the user enters a document number that does not match the existing format specified in add mode, they will receive the following error message:


Once you are done with this, you will go to the corresponding counter area to set the starting value. For example, if you choose to use alphabetic invoice numbers, you may go to A/R Setup and set the starting invoice number like, say, AAA001. This value is up to you. The important thing to know is if the digit in the starting value is alphabetic, then it will stay alphabetic. If it is numeric, then it will stay numeric. So the digit of value “A” can have a value of A-Z.  The numeric digit will have the value of 0-9. Therefore, this format can accommodate a maximum 26 * 26 * 26 * 10 * 10 * 10 = 17,576,000 number of invoices. It is up to you to decide your invoice number format. Alphabetic values can be in the beginning, the middle or the end.  Or you can make them all alphabetic. The format will stay the same until you change the starting counter value.  

Once you have alphabetic values stored in any document number fields, you will not be able to go back to Elliott V8.2 or V7.5. Attempting to access a company with alpha document support enabled will generate this error message:


CLS

Feedback and Knowledge Base

(thinking…)