Do you think it is case sensative?  In the file layout it is shown as  PAYMENTTYPE

I think the PaymentType child goes to the invoice's payment entry, which probably won't exist unless it's a CC transaction...

If you just want to look up a value in AR_PaymentType, why not flow a UDF into the invoice header (instead of doing a lookup)?

Thanks for the responses. My test invoice is a CC transaction with a filled Payment tab, but I expected the object to return zero if it weren't and to not generate an error. Thanks for the idea to flow it. I'll try that, as can been seen, I have a hard time giving up.

I was never able to get writing to the Sales Order Payment object to work for credit cards. What I did instead, is write the credit card to the customer, then reference the Credit Card ID on the sales order. This actually worked.

Here are some code snippets:

r = oSS.nSetProgram(oSS.nLookupTask("SO_SalesOrder_ui"))
Set o = oScript.NewObject("SO_SalesOrder_bus", oSS)
r = o.nSetKeyValue("SalesOrderNo$", SalesOrderNo)
r = o.nSetKey()

...

Set oPmt = o.oPaymentObj

r = oPmt.oARCreditCard.nAddNewCreditCard(PaymentType, ccNumber, expirationYear, expirationMonth, guid)

Set oCustCreditCard = oScript.NewObject("AR_CustomerCreditCard_bus", oSS)
r = oCustCreditCard.nSetKeyValue("ARDivisionNo$", "00")
r = oCustCreditCard.nSetKeyValue("CustomerNo$", CustomerNo)
r = oCustCreditCard.nSetKeyValue("CreditCardGUID$", guid)
r = oCustCreditCard.nSetKey()
r = oCustCreditCard.nSetValue("PaymentType$", PaymentType)
r = oCustCreditCard.nSetValue("CreditCardID$", CreditCardID)
r = oCustCreditCard.nSetValue("ExpirationDateYear$", expirationYear)
r = oCustCreditCard.nSetValue("ExpirationDateMonth$", expirationMonth)

r = oCustCreditCard.nWrite()
Set oCustCreditCard = Nothing

r = oPmt.nAddDeposit()
r = oPmt.nSetValue("CreditCardID$", CreditCardID)

r = oPmt.nWrite()

r = o.nWrite()

Sage100UserThanks for that helpful code snippet, but my need was to read a field in the AR_PaymentType table. I ended up using Kevin M's suggestion of having it flow to SO_InvoiceHeader.

Is this on a stock system or are there other enhancements?

I just threw this test script together and it worked on my stock 2018 system.

In SO Invoice Date Entry, the coPaymentTypeChild handle is the AR_PaymentType_Svc class and its table is AR_PaymentType.

David Speck This worked perfectly (minus the MoveFirst as it was already positioned correctly). Thank you AGAIN!!!  I just want to know why didn't the 1st method (as documented in multiple scripting resources including Steve M's) work?

Hey jepritch is there an award for the most helpful person in this forum? David deserves it!!!

I stopped using statements that combined AsObject and GetObject, NewObject, or GetChildHandle because i don't like to have to use On Error Resume Next unless absolutely required to. Imho, it is much better to get the numeric value returned by the last three into its own variable, hence the "n" prefix, test it for not being equal to zero and if not, then set it as an object handle with a "o" prefix using AsObject. 

Although the MoveFirst shouldn't be needed as i was just making sure that it really was going to the payment type table and not some other table. However, you may or may not need to include a [ReadAdditional "PaymentType"] before getting the child object or before getting your values from the child object. Have seen a few cases where the child object wasn't on the record i was expecting and ReadAdditional resolves that. If you don't pass it any arguments, it will read all child data sources so you can potentially save on resource overhead by just passing "PaymentType" to it so it will only read that child data source.

connex - I agree there are a number of incredibly helpful individuals that continuously contribute on these forums and you should all be commended.  David Speck Kevin M among two I know in particular, and you usually have the question answered before I can even read it. :)   Guess I'm getting obsolete

Thanks to everyone that makes this a real community!!!