Hey I was not there, Hold on. I am not using any ITSM. Mine is completely customised application developed from scratch. -- Thanks and Regards, Ganga Prasad Pattnaik, ( Remedy Skilled Professional ) On Thu, Mar 6, 2008 at 9:29 PM, Kalyan Krishna Nethy <[EMAIL PROTECTED]> wrote:
> ** 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___ > > > > __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"
