You made such an excellent argument for the use of mnemonic debtor
numbers that I went back to my internal customers to challenge the
requirement of automatically assigning the debtor number. The
difficulty for one of our businesses in using mnemonics is large number
of customers with the same name. We have a catalog company that sells
products to schools across the US. So, it is common for us to have
several different customers with the same name. For example, we have 16
different Washington Elementary schools scattered throughout the US as
Phil Daintree wrote:
>Searches on DebtorNo will of course be faster and entry of a debtor code or
>selection of a customer based on a name search is required before inquiries
>or orders or any operation to do with a customer can be done. A Mnemonic
>(almost certainly spelt wrongly!!) name entered as a code would be a short
>cut for operators in selecting a customers so they don't need to wade through
>a pile of similar name customers to find the one they are after - it would of
>course be impossible to remember some arbitrary numeric code. Experienced
>operators would have to do less typing and have improved throughput.
>You're right to avoid a duplicate customer a search for the existence of the
>customer first is the most effective route. However, another pretty good
>albeit not completely reliable method is to have some rule for the
>construction of the code - this could be enforced automatically under the
>autogeneration method you propose.
>eg. For customers with just one word names the first 10 characters of the
>name. For customers with two word names - the first 5 characters of the
>first word and the first five of the second word etc. For customers with
>three words in their name 4/3/3. Customers with more than 3 words in their
>name only using the first 3. Ignoring words like "the", "and", "proprietry",
>"limited", "plc", "SA", "inc"
>This could be done programatically - then compared to existing customer codes
>to check for duplicates. If ok to add then the code is changed to lose the
>last three characters and replace with 001, if that exists 002 etc. My view
>is that the efficiencies that would come for having a mnemonic customer code
>that follows the company convention would exceed the intial pain of entering
>it or coding an autogeneration facility.
>Not thought that deeply on this, just top of head stuff.
>On Wed, 09 Mar 2005 13:02, Scott Rosa wrote:
>>I brought TypeNo into the discussion of DebtorNo because I did not
>>clearly understand the purpose of the SysTypes table. I did not realize
>>that it was intended for use with financial transactions.
>>I want to auto-assign the debtor number for several reasons, some of
>>which may be flawed: (1) speed - one less field to enter, (2)
>>consistency - my users will be all over the place in their debtor number
>>assignment, (3) appearance - our customers are used to being assigned
>>system-generated account numbers.
>>I appreciate the concern for duplicate debtors and I think that I can
>>see how manually assigning the debtor number may lower the risk of
>>duplicates. However, whether the debtor number is automatically
>>assigned or not, is not the risk for duplicates the same either way?
>>Wouldn't the key to minimizing duplicates be the search facility,
>>providing several different ways to search for the existence of a
>>customer before adding them anew? If the debtor number and branch code
>>are simply keys to the DebtorsMaster and CustBranch, help me understand
>>the benefit of manually assigning these keys? I am open to manually
>>assigning them if I can present a compelling business reason to my
>>internal customers for doing so.
>>With all that being said, if I do decide to auto-assign the DebtorNo, is
>>there a better way to do it rather than using the SysTypes table? I am
>>not a fan of using tables or fields or code in ways they were not
>>intended to be used. And, if community sees value in it, I want to
>>contribute it back; but, I want to contribute something that the core
>>developers leverage going forward.
>>Phil Daintree wrote:
>>>I am not sure i understand why TypeNo comes into the discussion of the
>>>TypeNo is the number of the transaction type ...
>>>The transaction type can be any of the pre-defined systypes - normally in
>>>AR - thats 10 - for sales invoice, 11 for credit notes, 12 for receipts.
>>>The typeno is held against every debtortrans as transno and is
>>>incremented each time a new transaction of the type is added. It is
>>>defned as an integer.
>>>The last number used is stored in systypes. Changing the value in systypes
>>>allows the sequence to be changed - if you go to a number already used you
>>>will duplicate transaction numbers and allsorts of associated snags. If
>>>you go to a number not previously used then there is no problem - this is
>>>the recommended way to start transactions from a specified number.
>>>typeno therefore has nothing to do with debtorno?
>>>I am not sure why you would want to auto-assign debtor numbers? however,
>>>so long as there is no duplication and debtorno remains an acceptable
>>>length - I think its 10 characters I can't see an issue. Would it be
>>>possible to auto set up a new debtorno for the same customer who has
>>>previously been auto set up as something else? This would be a bad thing
>>>and would really do away with the point of a debtors ledger - to keep
>>>track of how much people owe you?
>>>I'd like to understand the business model.
>>>On Wed, 09 Mar 2005 06:23, Scott Rosa wrote:
>>>>I was planning to add an option to config to control whether the feature
>>>>was on or off (eg, $AutoAssignDebotorNo). I had not thought about a
>>>>prefix or suffix option, which is a great idea! I probably need some
>>>>more feedback from the community about acceptable lengths, if any, for
>>>>the prefix and suffix and what to do if someone exceeds those lengths.
>>>>With TypeNo being a length of six, I imagine that we would want the
>>>>prefix and suffix to be no more than four characters combined. Although
>>>>I want to try to minimize the impact to the core code, what do you think
>>>>about making the prefix and suffix imput fields when adding a customer
>>>>or a branch? This will allow us to better control the size of those
>>>>fields and provide flexibility so that one assign different a different
>>>>prefix or suffix for different categories of customers. More than
>>>>trouble than it's worth?
>>>>Because I only need to auto assign the debtor number, I was not planning
>>>>to do the same for the customer branch code; but, if I don't have a lot
>>>>of trouble implementing the feature for debtor master, I will implement
>>>>it for customer branch too.
>>>>From: Danie Brink <brink@...>
>>>>Organization: DataForce Solutions
>>>>Subject: Re: [WebERP-developers] SysTypes and DebtorsMaster
>>>>Date: Tue, 8 Mar 2005 02:14:45 +0200
>>>>On Tuesday 08 March 2005 01:36, Scott Rosa wrote:
>>>>>>i need to generate the DebtorNo (aka Customer Code) automatically when
>>>>>>adding a customer. i have noticed that there is a function available
>>>>>>already in SQL_CommonFunctions to retrieve and update transaction
>>>>>>numbers from the SysTypes table. i was considering adding entry to
>>>>>>this table for DebtorsMaster. however, before i do so, can someone
>>>>>>please explain any logic behind the TypeID field. is there some
>>>>>>numbering scheme in use? or, could i simply add my own entries, say
>>>>>>starting at 100?
>>>>>>thanks and regards,
>>>>Hi Scott, about the TypeID field, Phil is the best one to answer that
>>>>question as it is part of how the accounting stuff works in many cases.
>>>>However as to the DebtorNo, you should keep in mind that there are two
>>>>records required to affect a sale in the system one for the debtorsmaster
>>>>and one for the custbranch. In general the default custbranch code could
>>>>also be the same code as the debtorno, but in reality it means that a
>>>>Customer code is a combination of the debtorno and the custbranch i.e.
>>>>I'm mentioning this just in case, and considering the fact that you may
>>>>be looking at sales. Also when you do this could you please if you so
>>>>choose add fields to the config system for something like prefix +
>>>>number + postfix or prefix calculation option + number + postfix
>>>>calculation option that will allow us to use and expand this in future.
>>>>I am not sure if this is acceptable but using a high typenumber will
>>>>probably not break anything Phil will probably be able to suggest
>>>>something better in this regard.
>>>>SF email is sponsored by - The IT Product Guide
>>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>>Discover which products truly live up to the hype. Start reading now.
>>>>Web-erp-developers mailing list
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>Web-erp-developers mailing list