Rick, This is NOT the normal, default behavior for a the Request ID assignment on a standard Remedy form.
Unless there is workflow to get the next ID value prior to saving the entry, the default behavior is for the Request ID not to be assigned until the entry is initially saved. In the form properties, is 'Enable Next Request ID Block Size' checked? If so, what is the value for the Next Request ID Block Size? --Thomas ----- Original Message ----- From: Rick Cook Newsgroups: gmane.comp.crm.arsystem.general To: [email protected] Sent: Wednesday, March 05, 2008 12:38 PM Subject: Re: Control over Request ID ** Correct. 12346 was allocated, but was then discarded before it became a viewable Incident. Rick On Wed, Mar 5, 2008 at 10:32 AM, Ganga Prasad <[EMAIL PROTECTED]> wrote: ** Neel Let me be bit more clearer. Lets say I have last request ID 000000000012345.I am going ahead with a new ticket. I don't save the ticket and cancel it. Next I am creating a ticket and saving it then my new request ID will be 000000000012347 instead of 000000000012346. My understanding behind this in above scenario is I tried to create a instance of the ticket and the Next Reqest ID is incremented by 1 and when i again tried to create a ticket again the Next Reqest ID incremented by 1 and it gave me the number 000000000012347. Is this the way it work ? -- Thanks and Regards, Ganga Prasad Pattnaik, ( Remedy Skilled Professional ) On Wed, Mar 5, 2008 at 10:36 PM, Rick Cook <[EMAIL PROTECTED]> wrote: ** I agree with Neel, whose reasons are sound. The Interface_Create form does not always create an Incident, which is why there are gaps. Rick On Wed, Mar 5, 2008 at 8:57 AM, Neel Guatam <[EMAIL PROTECTED]> wrote: Ganga, When you say 'requestID generated are not in sequence' - are you referring to; for example; all the incidents created? If so, that's how it works as when you open a new incident and select a customer, it generated an incident ID and increment the nextID for that module. However, when user cancels out and doesn't save that incident, the next incident created will not be in sequence and have a gap of one. If many users in production do that then you'll see the broken sequence and it's normal. IF this is the case then I don't think you should be messing with it. Just my $0.02 Neel Gautam Accenture - Chicago Delivery Centre Core Values: Stewardship * Best People * Client Value Creation * One Global Network * Respect for the Individual * Integrity -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ganga Prasad Sent: Wednesday, March 05, 2008 10:50 AM To: [email protected] Subject: Re: Control over Request ID ** Thanks Rick In fact issue with me is that the request ID generated are not in sequence. So can we make the is possible to break the sequence or if broken then make it in order ? Thanks and Regards, Ganga Prasad Pattnaik, ( Remedy Skilled Professional ) On Wed, Mar 5, 2008 at 10:10 PM, Rick Cook <[EMAIL PROTECTED]> wrote: ** You can, but should do so carefully. The nextId column in the arschema table contains the number of the next Request ID for the specified form. Manipulating that manually is done by resetting the value via SQL command, which should only be done under specific controlled conditions, which are listed in the Remedy documentation. Failure to think through the process carefully may result in the form being unable to accept further entries until the problem is fixed. If you want to present a different type of number to customers, or exercise more control over it, I would recommend that you create and use a different field. Rick On Wed, Mar 5, 2008 at 8:19 AM, Ganga Prasad <[EMAIL PROTECTED]> wrote: ** Hi All Do we have any control over the sequence of Request ID ? My understanding is that this number us generated automatically. Can we control the way it is getting generated ? This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
