Re: incident SLAs
Whenever you are plugging in a Keyword into Remedy fields that are not the Advanced Search bar it always seems to put the \ right after the $ sign. They are basically the same. Thanks Peter Lammey ESPN IT Packaging and Automation 860-766-4761 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Tuesday, June 29, 2010 5:53 PM To: arslist@ARSLIST.ORG Subject: Re: incident SLAs Peter - Thanks for the suggestion. I will test it in Dev. I knew it had to be easier than I thought. What is the difference between $NULL$ and $\NULL$ ? I've seen this before but can't remember exactly. Marcelo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lammey, Peter A. Sent: Tuesday, June 29, 2010 3:23 PM To: arslist@ARSLIST.ORG Subject: Re: incident SLAs Set your Stop conditions for your Response SLA to the following: 'Status' = Resolved OR 'Status History.In Progress.TIME' != $\NULL$ OR 'Status' = In Progress OR 'Status History.Resolved.TIME' != $\NULL$ This way when the ticket is Resolved or Closed or Cancele or In Progress it stops the clock and determines Measurement status and will stay stopped as long as you have a Status history date for Resolved or In Progress. Thanks Peter Lammey ESPN IT Packaging and Automation 860-766-4761 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Tuesday, June 29, 2010 4:12 PM To: arslist@ARSLIST.ORG Subject: incident SLAs I wanted to ping the list to see what others are doing/thinking regarding SLAs and ITSM. We currently have 2 SLAs per incident: response and resolution. - we'll focus on the response SLA for now. As normal, when a ticket is new, the SLAs are attached and are kicked off when the status is Assigned. The response SLA stops when the ticket is set to In Progress. This means that the ticket has been acknowledged. If the ticket is re-assigned to another support group, the status changes back to Assigned and the response SLA starts calculating time again. I have been asked to look at once the response SLA is met once, then don't restart it if the incident is assigned to another support group. Or as some folks put it why have to shoot the duck twice if it's already dead with the first shot. I was thinking of creating a hidden field on the HPD:Help Desk form and having a filter populate this field if the status is In progress. AND adding to the Terms and Conditions of the response service target: AND 'field' = $NULL$. I wanted to check w/ the list if this is a good solution or if I am creating workflow for something that can be done OOB by a setting change. Any comments appreciated. Thanks. Marcelo ARS7.1 P7 ITSM 7.0.03 P6 SLM 7.0 P4 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are Please consider the environment before printing this e-mail. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
incident SLAs
I wanted to ping the list to see what others are doing/thinking regarding SLAs and ITSM. We currently have 2 SLAs per incident: response and resolution. - we'll focus on the response SLA for now. As normal, when a ticket is new, the SLAs are attached and are kicked off when the status is Assigned. The response SLA stops when the ticket is set to In Progress. This means that the ticket has been acknowledged. If the ticket is re-assigned to another support group, the status changes back to Assigned and the response SLA starts calculating time again. I have been asked to look at once the response SLA is met once, then don't restart it if the incident is assigned to another support group. Or as some folks put it why have to shoot the duck twice if it's already dead with the first shot. I was thinking of creating a hidden field on the HPD:Help Desk form and having a filter populate this field if the status is In progress. AND adding to the Terms and Conditions of the response service target: AND 'field' = $NULL$. I wanted to check w/ the list if this is a good solution or if I am creating workflow for something that can be done OOB by a setting change. Any comments appreciated. Thanks. Marcelo ARS7.1 P7 ITSM 7.0.03 P6 SLM 7.0 P4 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: incident SLAs
Set your Stop conditions for your Response SLA to the following: 'Status' = Resolved OR 'Status History.In Progress.TIME' != $\NULL$ OR 'Status' = In Progress OR 'Status History.Resolved.TIME' != $\NULL$ This way when the ticket is Resolved or Closed or Cancele or In Progress it stops the clock and determines Measurement status and will stay stopped as long as you have a Status history date for Resolved or In Progress. Thanks Peter Lammey ESPN IT Packaging and Automation 860-766-4761 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Tuesday, June 29, 2010 4:12 PM To: arslist@ARSLIST.ORG Subject: incident SLAs I wanted to ping the list to see what others are doing/thinking regarding SLAs and ITSM. We currently have 2 SLAs per incident: response and resolution. - we'll focus on the response SLA for now. As normal, when a ticket is new, the SLAs are attached and are kicked off when the status is Assigned. The response SLA stops when the ticket is set to In Progress. This means that the ticket has been acknowledged. If the ticket is re-assigned to another support group, the status changes back to Assigned and the response SLA starts calculating time again. I have been asked to look at once the response SLA is met once, then don't restart it if the incident is assigned to another support group. Or as some folks put it why have to shoot the duck twice if it's already dead with the first shot. I was thinking of creating a hidden field on the HPD:Help Desk form and having a filter populate this field if the status is In progress. AND adding to the Terms and Conditions of the response service target: AND 'field' = $NULL$. I wanted to check w/ the list if this is a good solution or if I am creating workflow for something that can be done OOB by a setting change. Any comments appreciated. Thanks. Marcelo ARS7.1 P7 ITSM 7.0.03 P6 SLM 7.0 P4 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are Please consider the environment before printing this e-mail. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: incident SLAs
Peter - Thanks for the suggestion. I will test it in Dev. I knew it had to be easier than I thought. What is the difference between $NULL$ and $\NULL$ ? I've seen this before but can't remember exactly. Marcelo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lammey, Peter A. Sent: Tuesday, June 29, 2010 3:23 PM To: arslist@ARSLIST.ORG Subject: Re: incident SLAs Set your Stop conditions for your Response SLA to the following: 'Status' = Resolved OR 'Status History.In Progress.TIME' != $\NULL$ OR 'Status' = In Progress OR 'Status History.Resolved.TIME' != $\NULL$ This way when the ticket is Resolved or Closed or Cancele or In Progress it stops the clock and determines Measurement status and will stay stopped as long as you have a Status history date for Resolved or In Progress. Thanks Peter Lammey ESPN IT Packaging and Automation 860-766-4761 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Tuesday, June 29, 2010 4:12 PM To: arslist@ARSLIST.ORG Subject: incident SLAs I wanted to ping the list to see what others are doing/thinking regarding SLAs and ITSM. We currently have 2 SLAs per incident: response and resolution. - we'll focus on the response SLA for now. As normal, when a ticket is new, the SLAs are attached and are kicked off when the status is Assigned. The response SLA stops when the ticket is set to In Progress. This means that the ticket has been acknowledged. If the ticket is re-assigned to another support group, the status changes back to Assigned and the response SLA starts calculating time again. I have been asked to look at once the response SLA is met once, then don't restart it if the incident is assigned to another support group. Or as some folks put it why have to shoot the duck twice if it's already dead with the first shot. I was thinking of creating a hidden field on the HPD:Help Desk form and having a filter populate this field if the status is In progress. AND adding to the Terms and Conditions of the response service target: AND 'field' = $NULL$. I wanted to check w/ the list if this is a good solution or if I am creating workflow for something that can be done OOB by a setting change. Any comments appreciated. Thanks. Marcelo ARS7.1 P7 ITSM 7.0.03 P6 SLM 7.0 P4 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are Please consider the environment before printing this e-mail. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ITSM7.5 Incident SLAs
That's really helpful Jiri, thank you! 1. I have gone throught he settings as you suggest, and it wasn't too far a drift. o Reset Goal for Same Request? = Yes (was No) o Allow Service Target to Re-Open? = No (was Yes) 2. I have now created the Groups and associated Service Targets as you suggest, as they were not defined before. The manual confirms the Reported Date+ is used for SLAs as they attach when the incident conditions like priority change. 3. The SLA Due Times using assigned groups with different business hours, are not correct. Not sure if I have wrong settings or if there is a bug here. I can provide more detail on this. 4. When the priority or assigned group (different business hours) changes, is it normal to see the previous SLAs getting met (or missed goal) and remaining visible on the table field? Is there a way to show only the latest SVT Title at anyone time 5. Following on from 4. When the assigned group changes and business hours change, the customer would like to see just one SLA present, rather than one or more Met and the latest In Process - Is this possible? 6. Also when new SLAs attach when priority changes, Progress is Attached and not In Process. This is despite the Start Condition is 'Status' = New for Resolution, and 'SLA Responded' = No for Respond. This is unexpected and a little strange! Any thoughts on this would be very much appreciated. Best regards Mike On Thu, May 20, 2010 at 3:33 PM, Jiri Pospisil jiri.pospi...@lchclearnet.com wrote: ** Mike, If that is the case, I can only think of checking/trying some of the following settings: - In data source Start Time for Request-Based SVTs = Reported Date + - on service target o Use Start Time as defined on the Application form – blank o Business Schedules – Use on App Form ticked o Group – Team Response (this you would need to define as a new group and it may be this setting that makes the time carry on rather than start from beginning again) o Reset Goal for Same Request? = Yes o Allow Service Target to Re-Open? = No Regards Jiri *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Mike Buck *Sent:* 20 May 2010 15:17 *To:* arslist@ARSLIST.ORG *Subject:* Re: ITSM7.5 Incident SLAs ** Thank you Jiri, I really appreciate the time you took to respond. I actually tried something very similar to what you suggest, and made the Reset Goal for the Same Request When: 'TR.Assigned Group ID' != $\NULL$ and this works OK for the first group, but when I reassign to the next group with different (or the same) hours, the Due Date is too early, and I have no foggy idea why this is? I have double checked my data etc. Its possible that my settings are not correct, or that I am doing something wrong somewhere. Either that, or ITSM7.5 has a bug? Thank you again for your response. Kind regards Mike On Thu, May 20, 2010 at 2:51 PM, Jiri Pospisil jiri.pospi...@lchclearnet.com wrote: ** ++ Please Read The Disclaimer At The Bottom Of This Email ++ Mike, We are only on SLM 7.1, but we do something very similar here. What you seem to be missing is setting on the Data Source called *Reset Goal for Same Request When*. We have this set to 'TR.Assigned Group' != $\NULL$ AND 'DB.Assigned Group' != $\NULL$ This way it resets the target every time the assignee group changes, but not on incident submission. Hope this helps. Jiri Pospisil Remedy Specialist LCH.Clearnet http://www.lchclearnet.com/ *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Mike Buck *Sent:* 20 May 2010 14:30 *To:* arslist@ARSLIST.ORG *Subject:* ITSM7.5 Incident SLAs ** Hi Does anyone know how to configure things so that the SLA re-attaches when it's re-assigned to another group? The new group's business hours (new group's Business Entity) should be used in calculating the new SLA Due Date. Currently Response and Resolution SLAs get attached to Incidents using the Reported Date as the start time, and SLA Due Dates get calculated correclty against the group's business hours/hols. The group's business hours/hols are defined in Segments, and associated with a Business Entity with the Entity Title matching the Group ID e.g. SGP1234. SLA/OLA Type Data Fields = 'Assigned Group ID' in the Target Data Source for HPD:Help Desk. Your help would be very much appreciated. Kind regards Mike PS. The documentation says a lot but lacks the clarity. _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ * This email is intended for the named recipient(s) only. Its
ITSM7.5 Incident SLAs
Hi Does anyone know how to configure things so that the SLA re-attaches when it's re-assigned to another group? The new group's business hours (new group's Business Entity) should be used in calculating the new SLA Due Date. Currently Response and Resolution SLAs get attached to Incidents using the Reported Date as the start time, and SLA Due Dates get calculated correclty against the group's business hours/hols. The group's business hours/hols are defined in Segments, and associated with a Business Entity with the Entity Title matching the Group ID e.g. SGP1234. SLA/OLA Type Data Fields = 'Assigned Group ID' in the Target Data Source for HPD:Help Desk. Your help would be very much appreciated. Kind regards Mike PS. The documentation says a lot but lacks the clarity. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ITSM7.5 Incident SLAs
++ Please Read The Disclaimer At The Bottom Of This Email ++ Mike, We are only on SLM 7.1, but we do something very similar here. What you seem to be missing is setting on the Data Source called Reset Goal for Same Request When. We have this set to 'TR.Assigned Group' != $\NULL$ AND 'DB.Assigned Group' != $\NULL$ This way it resets the target every time the assignee group changes, but not on incident submission. Hope this helps. Jiri Pospisil Remedy Specialist LCH.Clearnethttp://www.lchclearnet.com/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mike Buck Sent: 20 May 2010 14:30 To: arslist@ARSLIST.ORG Subject: ITSM7.5 Incident SLAs ** Hi Does anyone know how to configure things so that the SLA re-attaches when it's re-assigned to another group? The new group's business hours (new group's Business Entity) should be used in calculating the new SLA Due Date. Currently Response and Resolution SLAs get attached to Incidents using the Reported Date as the start time, and SLA Due Dates get calculated correclty against the group's business hours/hols. The group's business hours/hols are defined in Segments, and associated with a Business Entity with the Entity Title matching the Group ID e.g. SGP1234. SLA/OLA Type Data Fields = 'Assigned Group ID' in the Target Data Source for HPD:Help Desk. Your help would be very much appreciated. Kind regards Mike PS. The documentation says a lot but lacks the clarity. _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ * This email is intended for the named recipient(s) only. Its contents are confidential and may only be retained by the named recipient(s) and may only be copied or disclosed with the consent of LCH.Clearnet Limited and/or LCH.Clearnet SA. If you are not an intended recipient please delete this e-mail and notify postmas...@lchclearnet.com. LCH.Clearnet Limited, LCH.Clearnet SA and each other member of the LCH.Clearnet Group accept no liability, including liability for negligence, in respect of any statement in this email. The contents of this email are subject to contract in all cases, and LCH.Clearnet Limited and/or LCH.Clearnet SA makes no contractual commitment save where confirmed by hard copy. Cet e-mail et toutes les pièces jointes (ci-après le message) sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, est interdite, sauf autorisation expresse de LCH.Clearnet Limited et/ou LCH.Clearnet SA. Si ce message vous a été adressé par erreur, merci de le détruire et d'en avertir immédiatement postmas...@lchclearnet.com. LCH.Clearnet Limited, LCH.Clearnet SA et les autres entités du groupe LCH.Clearnet Group, ne peuvent en aucun cas être tenues responsables au titre de ce message à moins qu’il n’ait fait l’objet d’un contrat signé. LCH.Clearnet Limited, Registered Office: Aldgate House, 33 Aldgate High Street, London EC3N 1EA.Recognised as a Clearing House under the Financial Services Markets Act 2000. Reg in England No.25932 Telephone: +44 20 7426 7000 Internet: http://www.lchclearnet.com LCH.Clearnet SA, Siège Social, 18 rue du Quatre Septembre, 75002 Paris, Chambre de Compensation conformément au Code Monétaire et Financier. * ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ITSM7.5 Incident SLAs
Thank you Jiri, I really appreciate the time you took to respond. I actually tried something very similar to what you suggest, and made the Reset Goal for the Same Request When: 'TR.Assigned Group ID' != $\NULL$ and this works OK for the first group, but when I reassign to the next group with different (or the same) hours, the Due Date is too early, and I have no foggy idea why this is? I have double checked my data etc. Its possible that my settings are not correct, or that I am doing something wrong somewhere. Either that, or ITSM7.5 has a bug? Thank you again for your response. Kind regards Mike On Thu, May 20, 2010 at 2:51 PM, Jiri Pospisil jiri.pospi...@lchclearnet.com wrote: ** ++ Please Read The Disclaimer At The Bottom Of This Email ++ Mike, We are only on SLM 7.1, but we do something very similar here. What you seem to be missing is setting on the Data Source called *Reset Goal for Same Request When*. We have this set to 'TR.Assigned Group' != $\NULL$ AND 'DB.Assigned Group' != $\NULL$ This way it resets the target every time the assignee group changes, but not on incident submission. Hope this helps. Jiri Pospisil Remedy Specialist LCH.Clearnet http://www.lchclearnet.com/ *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Mike Buck *Sent:* 20 May 2010 14:30 *To:* arslist@ARSLIST.ORG *Subject:* ITSM7.5 Incident SLAs ** Hi Does anyone know how to configure things so that the SLA re-attaches when it's re-assigned to another group? The new group's business hours (new group's Business Entity) should be used in calculating the new SLA Due Date. Currently Response and Resolution SLAs get attached to Incidents using the Reported Date as the start time, and SLA Due Dates get calculated correclty against the group's business hours/hols. The group's business hours/hols are defined in Segments, and associated with a Business Entity with the Entity Title matching the Group ID e.g. SGP1234. SLA/OLA Type Data Fields = 'Assigned Group ID' in the Target Data Source for HPD:Help Desk. Your help would be very much appreciated. Kind regards Mike PS. The documentation says a lot but lacks the clarity. _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ * This email is intended for the named recipient(s) only. Its contents are confidential and may only be retained by the named recipient(s) and may only be copied or disclosed with the consent of LCH.Clearnet Limited and/or LCH.Clearnet SA. If you are not an intended recipient please delete this e-mail and notify postmas...@lchclearnet.com. LCH.Clearnet Limited, LCH.Clearnet SA and each other member of the LCH.Clearnet Group accept no liability, including liability for negligence, in respect of any statement in this email. The contents of this email are subject to contract in all cases, and LCH.Clearnet Limited and/or LCH.Clearnet SA makes no contractual commitment save where confirmed by hard copy. Cet e-mail et toutes les pièces jointes (ci-après le message) sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, est interdite, sauf autorisation expresse de LCH.Clearnet Limited et/ou LCH.Clearnet SA. Si ce message vous a été adressé par erreur, merci de le détruire et d'en avertir immédiatement postmas...@lchclearnet.com. LCH.Clearnet Limited, LCH.Clearnet SA et les autres entités du groupe LCH.Clearnet Group, ne peuvent en aucun cas être tenues responsables au titre de ce message à moins qu’il n’ait fait l’objet d’un contrat signé. LCH.Clearnet Limited, Registered Office: Aldgate House, 33 Aldgate High Street, London EC3N 1EA. Recognised as a Clearing House under the Financial Services Markets Act 2000. Reg in England No.25932 Telephone: +44 20 7426 7000 Internet: http://www.lchclearnet.com LCH.Clearnet SA, Siège Social, 18 rue du Quatre Septembre, 75002 Paris, Chambre de Compensation conformément au Code Monétaire et Financier. * _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ITSM7.5 Incident SLAs
Mike, If that is the case, I can only think of checking/trying some of the following settings: - In data source Start Time for Request-Based SVTs = Reported Date + - on service target o Use Start Time as defined on the Application form - blank o Business Schedules - Use on App Form ticked o Group - Team Response (this you would need to define as a new group and it may be this setting that makes the time carry on rather than start from beginning again) o Reset Goal for Same Request? = Yes o Allow Service Target to Re-Open? = No Regards Jiri From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mike Buck Sent: 20 May 2010 15:17 To: arslist@ARSLIST.ORG Subject: Re: ITSM7.5 Incident SLAs ** Thank you Jiri, I really appreciate the time you took to respond. I actually tried something very similar to what you suggest, and made the Reset Goal for the Same Request When: 'TR.Assigned Group ID' != $\NULL$ and this works OK for the first group, but when I reassign to the next group with different (or the same) hours, the Due Date is too early, and I have no foggy idea why this is? I have double checked my data etc. Its possible that my settings are not correct, or that I am doing something wrong somewhere. Either that, or ITSM7.5 has a bug? Thank you again for your response. Kind regards Mike On Thu, May 20, 2010 at 2:51 PM, Jiri Pospisil jiri.pospi...@lchclearnet.commailto:jiri.pospi...@lchclearnet.com wrote: ** ++ Please Read The Disclaimer At The Bottom Of This Email ++ Mike, We are only on SLM 7.1, but we do something very similar here. What you seem to be missing is setting on the Data Source called Reset Goal for Same Request When. We have this set to 'TR.Assigned Group' != $\NULL$ AND 'DB.Assigned Group' != $\NULL$ This way it resets the target every time the assignee group changes, but not on incident submission. Hope this helps. Jiri Pospisil Remedy Specialist LCH.Clearnethttp://www.lchclearnet.com/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Mike Buck Sent: 20 May 2010 14:30 To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: ITSM7.5 Incident SLAs ** Hi Does anyone know how to configure things so that the SLA re-attaches when it's re-assigned to another group? The new group's business hours (new group's Business Entity) should be used in calculating the new SLA Due Date. Currently Response and Resolution SLAs get attached to Incidents using the Reported Date as the start time, and SLA Due Dates get calculated correclty against the group's business hours/hols. The group's business hours/hols are defined in Segments, and associated with a Business Entity with the Entity Title matching the Group ID e.g. SGP1234. SLA/OLA Type Data Fields = 'Assigned Group ID' in the Target Data Source for HPD:Help Desk. Your help would be very much appreciated. Kind regards Mike PS. The documentation says a lot but lacks the clarity. _attend WWRUG10 www.wwrug.comhttp://www.wwrug.com/ ARSlist: Where the Answers Are_ * This email is intended for the named recipient(s) only. Its contents are confidential and may only be retained by the named recipient(s) and may only be copied or disclosed with the consent of LCH.Clearnet Limited and/or LCH.Clearnet SA. If you are not an intended recipient please delete this e-mail and notify postmas...@lchclearnet.commailto:postmas...@lchclearnet.com. LCH.Clearnet Limited, LCH.Clearnet SA and each other member of the LCH.Clearnet Group accept no liability, including liability for negligence, in respect of any statement in this email. The contents of this email are subject to contract in all cases, and LCH.Clearnet Limited and/or LCH.Clearnet SA makes no contractual commitment save where confirmed by hard copy. Cet e-mail et toutes les pièces jointes (ci-après le message) sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, est interdite, sauf autorisation expresse de LCH.Clearnet Limited et/ou LCH.Clearnet SA. Si ce message vous a été adressé par erreur, merci de le détruire et d'en avertir immédiatement postmas...@lchclearnet.commailto:postmas...@lchclearnet.com. LCH.Clearnet Limited, LCH.Clearnet SA et les autres entités du groupe LCH.Clearnet Group, ne peuvent en aucun cas être tenues responsables au titre de ce message à moins qu'il n'ait fait l'objet d'un contrat signé. LCH.Clearnet Limited, Registered Office: Aldgate House, 33 Aldgate High Street, London EC3N 1EA. Recognised as a Clearing House under the Financial Services
