Hi there - does anyone have a hint or ideas on how to get the credit card auth number on the SO picking sheet crystal report? 

Can I get the field into the existing report work table? (I hope)

OR would I be forced to bring SalesOrderPayment table into the crystal report designer, or...?

Create a modified SO (Sales Order Printing) to look like your picking sheet.  The payment business object appears to be in that work table.

You can do this with a sub-report in the picking sheet, linked by the sales order number. You don't need to create a completely new report.

Thank you to both of you.  It looks like Sage is the only one that can link the tables/objects to make them available from another such as this work table... not being able to get the AuthNo but it CAN get the AuthDate... and this is acceptable to our users. 

HOWEVER for some reason, this date is *ALWAYS* 1-1-1753 on the report.  I tested the same report on our MAS 200 deploy and the AuthDate does come in correctly.  Both MAS 200 and Sage 100 have the same exact fields in SO_PickingSheetWrk (including AuthDate), but it looks like there may be a problem with the system taking AuthDate out of the 'new' SO_SalesOrderPayment and populating the work table. 

I have opened up a ticket with Sage.  We are on PU #1, perhaps we need PU #3 which was recently released. 

Sadly, we will have to start over with our rigorous validation testing...  Thanks again, all.

I think you are misunderstanding me. I'm not saying to create an object link in the data file. I'm talking about opening the Crystal report, and adding a sub-report to the necessary table.

Thanks.  I believe I do understand:  You are saying to include within the report, another report and this sub report would use an additional table - a standard SQL table - NOT the report's work table.  (this is akin to the third line of my original post) 

My previous post was generally thanking both of you and then stating (or suggesting) that apparently SAGE is the *only one* that can manipulate/code the system in such a way that data from the standard tables flows into the report work tables.  (This would be the best case scenario.  There is a speed factor)  However the work table already DOES have the AuthDate ... but it is not working correctly on our version which seems to be a bug or glitch. 

I am pursuing a fix for this at the moment.

Hello,

Yes a sub-report is inside the main report (that uses the work table). But the sub-report uses SO_SalesOrderPayment.

You are using the SQL version? I tested using Sage 100 Advanced (non-SQL) 2017.1 and the Authorization Date field from SO_SalesOrderPayment comes through just fine.

Sage100User, Thank you for looking so much into it.  We are using the SQL version. 

We are currently on MAS 200 SQL version 4.50.30 and we are working toward deploying Sage 100 Premium 2017 5.40.1.0. 

Yes outside of the Sage universe, I have made crystal reports with extra tables and sub reports before.  Within the Sage product, I have seen them get quite complicated and have seen them slow down from 8 seconds to 3 minutes. 

I spoke to SAGE today and their council was as expected try to stay with the work tables 'that is what they were made for' and you seem to indicate that you have a comparable version - yet it works for you. 

I am scratching my head as the SAGE tech indicated that it did not work for his non SQL version of 2017 but there is a difference: he claimed to be on PU#3.

Sage100User, I don't think this matters, but wanted to ask anyway: did you use a live/real credit card in your test?  I am setup on a test merchant account and am using from the list of approved Sage test credit card numbers...

Yes we are actively processing credit cards using Sage Payments and so when I tested viewing SO_SalesOrderPayment in Crystal Reports, I was able to see the Authorization Date field contents just fine.