x Want to participate? Join the group to interact
Options
  • State Verified Answer
  • Replies 6 replies
  • Subscribers 88 subscribers
  • Views 1712 views
  • Users 0 members are here
Browse Forums
Announcements
293
topics
370
replies
Business Object Interface
1k
topics
7k
replies
Core Financial Modules
2k
topics
8k
replies
Customization and Productivity
3k
topics
12k
replies
Distribution, Manufacturing, and Applications
2k
topics
7k
replies
General Discussion
1k
topics
3k
replies
Partner Cloud
44
topics
90
replies
Payroll, Time Tracking, and Job Cost
776
topics
1k
replies
Reporting and Analytics
960
topics
3k
replies
Sage CRM for Sage 100
164
topics
357
replies
Technical and Installation
2k
topics
9k
replies
Year-end Forum
89
topics
237
replies
Kevin M

oSession.AsObject(oBusObj.PaymentObj) inconsistent results in SO scripts

SOLVED
Posted By

I have this code in a BOI script (SO Header, PreWrite)...

...
Set oPayment = oSession.AsObject(oBusObj.PaymentObj)
retVal = oPayment.GetValue("CreditCardAuthorizationNo$", sAuthNo)
retVal = oPayment.GetValue("AuthorizationDate$", sAuthDate)
retVal = oSession.AsObject(oSession.UI).MessageBox("","CreditCardAuthorizationNo " & sAuthNo & " sAuthDate " & sAuthDate)

But it is coming up blank.

Yet I have a button script on the panel with the exact same script code, and it works?!?

Is there something I can do in a BOI script to reliably get access to the CC payment data for an SO?

I tried adding these lines, but nothing seems to help.

retVal = oBusObj.ReadAdditional("PaymentType")

retVal = oBusObj.ReadAdditional("PaymentTypeCategory")

retVal = oBusObj.ReadAdditional("PaymentObj")

(Big picture of the script is to check for a valid PreAuth on an SO for customers with certain Terms... so I need reliable access to payment data to check the Auth #, amount and date).

  • 0

    I think with Pre-Write, isn't the data not officially "there" yet? Whereas the button script reads what's on the screen even if the record isn't committed.

    If you save the order then try the "Pre-Write" again, does it then show the data?

  • 0 in reply to Sage100User

    Thanks for the suggestion.

    I can reopen the order (which was saved on Hold, as forced by the script... even though it had a valid PreAuth with good date), try to take it off hold (which triggers the BOI script when I Accept) and the pop-up amounts are blank, even though they are on screen when the script invokes the Payments tab.  Click the Test button, and values are there.  Accept... no values in the pop-up.

    I could do an ODBC lookup if I didn't need things to work for new orders, but I know for sure the data won't be "there" (and available to ODBC) until the Write is successful... same with a new object to SO_SalesOrderPayment_bus with a lookup, the data won't be "there" for a new SO... while the SO business object should certainly have a way of accessing the Payment record for the current order.  I just need to know how to reliably access that record in a BOI script. 

    I read that PaymentObj can be accessed in a similar way to oBusObj.Lines... not a child handle, but as a property of the business object.

    If I have to invoke a button with use of oSession's SetStorageVar / GetStorageVar, I'd be very surprised.

  • 0

    After you get the handle to the payment object, try displaying its current key in either the trace window or a message box to see if it is even on a record. You can also try checking the EditState property.

  • 0 in reply to David Speck

    In the Pre-write event script the EditState is zero (no record in memory).

  • +1 in reply to Kevin M
    verified answer

    Try a MoveFirst and then loop through until you hit EoF while outputting the GetKey() to either the trace window or a MessageBox (i would avoid the latter if there are more than a few records in the payment table) then you might want to follow up with a Clear to put it back in the same state you found it in.

  • 0 in reply to David Speck

    Thanks David... such a loop seems to go through Payment records filtered to the current SO (not the whole table).

    Probably done that way because there could technically be multiple payment records on an SO.

    For an SO like this, it loops through the two records, which makes sense and is something I'll have to accommodate but I should be able to do that.

*Community Hub is the new name for Sage City