Ok, doesnât appear the job number is stored in a key and a param key1 = jobnum is applied to the BAQs.
I think Key1 is the specification or the inspection ID. I think what I did was name whatever it was as the Job number as it was going to be 1 to 1 at the company I was at. Is the job number in any of the inspection tables?
Yes, in InspResults table.
I changed the link and now canât preview at all. Any pointers on tracing.
Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask:
System.Data.SqlClient.SqlException (0x80131904): Conversion failed when converting from a character string to uniqueidentifier.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
![]()
Donât know why I didnât think of this before. Just add another new field to each table and just alter the BPM that is setting the related to GUID and set the job number too.
Ok, I didnât want to break anything if I could. Iâll do that. Is that why Iâm getting the error now you think.
Ok, I donât want to dig too deep into what I had done, because I might end up re-creating the whole thing.
For whatever reason, I named whatever ended up in Key1 the same as the Job it was on. We were a job shop and that worked, but it was not necessary.
So, I would create a new column on each Inspection Results table (Char, CheckBox, Date, Number, and Short Char) and name it JobNum_c. Then I would edit the BPM that is setting the RelatedToSysRowID to populate the JobNum_c with the job number. Then, instead of the table criteria being Key1 = @JobNum parameter, it would be JobNum_c = @JobNum parameter. I think that will fix everything so you can get the data.
Let me know if I did not explain enough and we can work through any issues.
Makes sense, going to test now. Iâve changed my setup of the module 3 times so far. Initially, knowing nothing of needing a report, then needing the report. So attributes were named which with your method canât be. They stay numeric001 for example. That is fine, and all has changed. Now with the setup we will have a different inspection plan for every part we manufacture, and we will be capturing insp data at atleast 6 different operations through out the job. Which lead me to another change and to be able to use this report. Insp Plan1 (job 123, op 10) has combobox - shortchar001, so that means that on Insp Plan 2 (same job 123, op 30) I canât reuse combobox - shortchar001, correct, it would need to be shortchar002 for example? Iâve tried to space them out assigning 001-020 on Insp plan 1, then 021-030 to Insp 2 and so on. Does that make sense?
Actually, if you set up the attributes the way that I did, you can reuse them. As long as you are entering the information in the specification, my set up allows the attributes to be reused across any amount of different plans.
Great, thanks!
Couldnât access UD field in BPM. Needed to use âDirective Updateâ to get it to display. Back to the races ![]()
Did you capture the JobNum in the same BPM that you are capturing the SysRowID? When you get the JobNum, stick it in a call context bpm data field and then add the data in the data directive.
I havenât figured out the right one yet, trying.
I get this when I try to run the report also. Is this because the job data is not there.
Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask:
System.Data.SqlClient.SqlException (0x80131904): Conversion failed when converting from a character string to uniqueidentifier.strong text
Potentially. Hard to tell if you are not getting data.
SsssoooooâŚafter upgrading to SQL 2019 things are working as expected. I am getting this when trying to execute the InspColumns BAQ. Ice.Common.EpicorServerException: Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression. â>
Can you post the Query Phrase from the BAQ?
Hi John,
Appreciate the write up this is very interesting.
We are working on rolling out inspections using the advanced quality module and I have let my users know we are limited in the amount of fields we can use.
However, it looks like how you set this up is to make the attribute itself generic, and then use the description from the specification to display in BAQs or reports what each attribute was inspected for. Is that correct?
If so, have you found any draw backs to this over time?
Yes, that is exactly what I did. If you are using the specifications, then the attribute names do not matter as you can change them on the specification.
I have not found any drawbacks.
We are currently on Epicor 10.2.700 still, but planning to upgrade to the latest in hopefully the next 12 months. What version did you implement this on and do you know of any issues where it will not work in certain versions?
Right now im working on a BAQ that can pull all related inspection data to use in creating a dashboard for users, so not sure if all of the work you did was necessary since I will not be pushing this to SSRS. Rereading your original solution now.