Hi Ganga, Assuming you are using ITSM 7.x here is the logic to generate the Incident IDs in sequence.
Step 1: Write a filter on Submit to generate an Instance ID if the field is NULL. Step 2: Write another filter to push the Instance ID to the NUM Generator form. Don't forget to override the filter phasing. Step 3: Write another filter to set the Incident ID field from the NUM Generator form. I used this workflow to generate the IDs in sequence. Regards, Kalyan. On Thu, Mar 6, 2008 at 2:05 AM, Roger Medsker <[EMAIL PROTECTED]> wrote: > ** > > Rick, Thomas, > > > > Assumption: Ganga is using ITSM 7.x > > > > What is happening is the following. When Ganga opens an Incident (or > Change), workflow performs a push to a "Ticket Num Generator" form which > generates a request ID for that form just like we're used to. Workflow then > sets the "Request ID" field (NOT field ID 1) for the Incident (or Change) > form to $LASTID$. If the Incident (or Change) is saved then the Request ID > is used. If the Incident was not saved the Request ID is abandoned. The next > time Ganga opens the form the process is repeated. If the previous (by > anyone) Request ID was used the current Request ID is one number greater > than the previous. If the previous Request ID was abandoned there will be a > gap. > > > > Roger > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Rick Cook > *Sent:* Wednesday, March 05, 2008 1:54 PM > > *To:* arslist@ARSLIST.ORG > *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:* arslist@ARSLIST.ORG > > *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: arslist@ARSLIST.ORG > 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"
