RE: [EXTERNAL] Re: Reporting by month value

Almost forgot. For backfilling old records replace the $DATE$ string with the $3$ value (usually $Create Date$ Run it with an escalation that sets MM to 13 and have the filter trigger on modify when MM=”13”. Then just fix the filter to run on submit with no runif qualification. Thank you, ---

RE: [EXTERNAL] Re: Reporting by month value

Dustin, If you have developer control over the form you can add some hidden “housekeeping” fields. I usually build a field and a MM field on each form that will get reports generated. Use functions in filters on submit to fill the fields. Set fields action YEAR($DATE$) MM

Re: [EXTERNAL] Re: Reporting by month value

that query should work, agreed it is complicated by each year you want, but it's the best I think you can do. On Wed, Jan 31, 2018 at 2:23 PM, Fawver, Dustin wrote: > LJ, > > > > While that qualification is simple, it becomes complex for what I need. I > could create one

RE: [EXTERNAL] Re: Reporting by month value

LJ, While that qualification is simple, it becomes complex for what I need. I could create one that works for a few years, such as: ('Requisition Date' >= "1/1/2018" AND 'Requisition Date' < "2/1/2018") OR ('Requisition Date' >= "1/1/2017" AND 'Requisition Date' < "2/1/2017") OR

Re: Reporting by month value

Dustin, If you are trying to do that in a Run-If or qualification, you can't use 'functions' in those areas...you can only use them in set/push actionsgenerating a report for everything in January would be something like 'Requisition Date' >= "1/1/2018" AND 'Requisition Date' < "2/1/2018"

Reporting by month value

Greetings! I have a form that includes a date field. There are records with dates spanning several years. I need to generate a report that returns records that have a date value for a particular month of the year. For instance, I may need to find records that have a date that falls in

RE: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

Ha. You may be right there. Software numbering is always an arcane endeavour.  /Ben From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of LJ LongWing Sent: January-31-18 9:49 AM To: ARSList Subject: Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; -

RE: FYI: Duplicate Field Names in 9.1.00 201512160229 possible

Hi Jason, I certainly recall many view generation failures at least until 7.6.04. Back then if a view generation failed it did not throw an error. That may still be the case. Only if you used the views would you discover something amiss. The viewname column was added to arschema in

Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

my hesitance regarding '9.5' specifically is surrounding that 9.5 was the planned version of the next version of Remedy which included Innovation Suitea bit over a year ago Innovation Suite was moved off into it's own product suite and is no longer planned to be part of Remedybecause of

Re: FYI: Duplicate Field Names in 9.1.00 201512160229 possible

A bit OT but I do remember a time when you could name a field with a DB keyword and the SQL view would not be generated. I Remember we a few forms with the field call "function" and the SQL view wouldn't build until we got smart and started naming the field something like "functionx". I think the

RE: FYI: Duplicate Field Names in 9.1.00 201512160229 possible

As I said, “I’m curious as to what field names were generated for the view.” I have no idea how they got it done. I have an older dev studio and it prevented that action from going to the server (as it should).Remember that Remedy has code for generating a field’s viewname. There’s a

RE: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

Hi LJ, I am getting this from my client – although I was involved in the support ticket. So, I didn’t hear it from the horse’s mouth. I was told “around 9.5”. It doesn’t really matter when it is fixed. The OOTB ITSM apps generally do not have umlauts in the “Query Fields” defined for

Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

Ben, Your statement regarding being fixed around '9.5' doesn't make any sense to medid whoever you talked to SAY 9.5 or did they say 'next release', or more likely 'future version'? On Wed, Jan 31, 2018 at 7:59 AM, Ben Chernys < ben.cher...@softwaretoolhouse.com> wrote: > FYI > > > > BMC has

Re: FYI: Duplicate Field Names in 9.1.00 201512160229 possible

Ben, I'm not sure how exactly that can happen because the 'name', assuming we are talking about the DB name of the field is used in the View creation, and you obviously can't have two columns with the same name in the DB view, so you can't do it in Dev Studio either...I would be curious to see a

FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

FYI BMC has raised this as a bug and is expecting to fix it around 9.5. Cheers Ben From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] Sent: May-29-17 7:57 AM To: 'arslist@ARSLIST.ORG' Subject: RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone

FYI: Duplicate Field Names in 9.1.00 201512160229 possible

Hi Folks, Just ran into an odd issue. A customer has created a field twice in the same form with the same name (but different ids). I tried to do the same on my 9.1.02 server using the 8.0 Developer Studio but the client prevented a duplicate entry into the name field. I remember the old

Re: Adding WorkLog on SRM Submit.

Hello Prajakta, The use case is honestly the culture around here. We have a website that was created in Remedy 7.x era that would basically create incidents for Help Request and mocked up "service request" The website would then put all the user inputs into work logs and that's how the support

RE: Adding WorkLog on SRM Submit.

Hi, I agree with Carl's suggestions. But would like to understand the use case of mapping such data in the Work info fields at the time of creation. Ideally, work info entries should be added once the request is created. --Prajakta From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf