Quite true, Thomas - an assumption on my part, based on having asked the question myself while configuring ITSM 7. So, Ganga, are you using ITSM 7?
Rick On Wed, Mar 5, 2008 at 12:11 PM, Thomas Bean <[EMAIL PROTECTED]> wrote: > ** Hi Rick, > I don't think Ganga ever said he was using ITSM 7.0 -- he just mentioned > ARS 7.0.01. > > --Thomas > > > ----- Original Message ----- > *From:* Rick Cook <[EMAIL PROTECTED]> > *Newsgroups:* gmane.comp.crm.arsystem.general > *To:* [email protected] > *Sent:* Wednesday, March 05, 2008 1:54 PM > *Subject:* Re: Control over Request ID > > ** You are correct, Thomas, except that ITSM 7 doesn't use Entry IDs on > the Help Desk form the way we're used to. I've seen this happen myself. > Technically, every Entry ID is represented by a record, but some are created > and discarded before they're viewable by anyone. I didn't build it... > > Rick > > On Wed, Mar 5, 2008 at 11:33 AM, Thomas Bean <[EMAIL PROTECTED]> wrote: > > > ** 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 <[EMAIL PROTECTED]> > > *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___ > > > > __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"
