Scripting

Scenario: Customer recently switched from SPS to APS, and the APS apparently doesn't like increases in CC charges beyond the original SO PreAuth amount (which SPS allows but the APS bank does not... apparently a ""fun"" conversation Robert had with them). Since the customer adds environmental fees at time of invoicing (and they don't want these charges on the SO), that is a real problem. What we came up with was a script to pre-calculate the environmental fee total (with a little extra for potential freight charges), and added those amounts into the FreightAmt field on the SO, with the goal of inflating the PreAuth amount. One problem was that the Ship Code (Weight and Manual) was sometimes overriding the FreightAmt to zero on the SO after the script ran (event triggers on PreTotals... and then added column post validate on FreightAmt, but still it happened). This was finally fixed by replacing buttons (Accept...) with versions which recalculate the FreightAmt before saving / quick printing... and another similar script to make sure the FreightAmt is what they want on CC panel load. Now, we discover that the PreAuth amount on the CC tab is intermittently not equal to the SO total (Payment ""Amount"" vs ""Auth Amount""). Ugh. I feel like I'm chasing a moving target, and am not eager to start scripting the CC field values to properly set the PreAuth amount (checking to make sure the SO doesn't have an Auth No already). Has anyone else dealt with this kind of thing already? Any suggestions on how to safely make sure the Auth Amount on an SO is what they want?

How do they deal with freight that's not known when the order is entered but is added when the shipment is about to go out?

I added a UDF to the invoice / shipping screen for ""manual freight"" and script the FreightAmt on the invoice to always equal that UDF. This makes sure the SO freight value is ignored, while still allowing freight to be charged (rare for this customer... but it does happen).

The SO screen values:

I think @WayneSchulz is asking, how do other clients add Freight at Shipping and then Post Auth the APS Credit Card for more money than was originally Pre-Authorized? Most often, the actual freight charges are not known at the time the SO is pre-authorized.

APS is OK with changes up to a certain percentage of the sales order. I am not as intimate with the Sage process as I am with APS in SAP, but we can have multiple authroizations associated with the same sales order and then collect multiple pre-auths. I would call Patti Benitez and get one of her people involved if you have not already.

From APS:

Thanks @GaryFeldman ... we've been dealing with Brittany Dudman. I'll pass Patti's name along for follow-up.

Aside from the politics at APS (more of a long term situation we were already pursuing), does anyone have suggestions on the immediate short term issue of padding the SO pre-auth amount reliably, without user intervention?

(The customer understandably does not like invoicing these charges separately, manually...).

Why don't you add the fee to the SO, but change the customer facing document (Sales Order) to exclude it? I believe the Crystal work would be much easier than scripting the right number into PreAuth amount.

I think it's worth noting that the issue/restriction that is causing Kevin so much trouble is specific only to Canada. The Canadian bank does not allow the CAPTURE amount above the AUTH amount, which is really restrictive for the reasons others have pointed out. The US banks do not have this restriction. I think the approach of calculating and putting into freight is not a bad one, but freight gets overridden. APS is working on finding other options for Canada. Kevin, we may be able to modify the integration to address the issue. I thought it had already been handled.

The client specifically requested that no lines be added to the order (i.e. no change in processes from SPS). The problem is the scripted environmental charges on the invoice need to be based on the actual shipped quantities. SO's are apparently never printed for the customer (only internal picking sheets) so bumping up the freight amount should have worked seamlessly... but ""should"" is the magic word.

Thanks for the comment @PhilipWhirley ... I think we were told the same restriction applied to the US bank too, but yes this client is Canadian.

Is there a GetChildHandle on SO header to bring me to the payment record?

if the Sales Order object is coOrder then the payment object is coOrder'PaymentObj. You probably don't need to do a GetChildHandle because it is already assigned a property. I hope this helps.

Kevin - To expand on what Phil said If starting point is the SO Header: Set oPayment = oBusObj.AsObject(oBusObj.PaymentObj) If starting point is Lines then. Set oPayment = oHeaderObj.AsObject(oHeaderObj.PaymentObj)

Thanks @PhilipWhirley and @AlnoorCassim ! That should do it. With that object I should be able to check if there's an Auth No, and then use an InvokeChange on the Auth Amount (panel post load script). I'll post an update after I get a chance to test things.

The Set oPayment = oBusObj.AsObject(oBusObj.PaymentObj) worked perfectly for the cc panel post-load script to query the Auth details before the rest of the script did it's thing. Setting the amount directly with an InvokeChange bypasses a number of things which were inconsistent when using the FreightAmt. (I had to force users to the CC tab before saving / printing, but that is a small price to pay). Thanks again.

We had a customer recently switch from SPS/PAYA to APS and they are experiencing the same issue - cannot invoice an amount greater than what was pre-auth'd. Spoke with Bryce Deeney from APS and he explained why our customer has this limitation. APS uses several banks and one allows this but they chose not to underwrite our customer. They sell equine products that are actually prescription items which can be more risky i.e. they COULD potentially be abused. So another bank DID the underwriting and they do not allow invoicing more than the auth'd amount. If it's a freight issue (which it sometimes is), he suggested padding freight charges on the order. If it's due to an order change - where the customer added additional product, he suggested either deleting the original order and reentering it or to add a new order for the additional product. Just an FYI.

So for freight the recommendation is to guess high and add that freight on the initial order? I think that would work most times except for when someone wants a rush order overnighted and the freight is unusually high compared to normal shipping ?

As an aside, we found that Sage, when NOT integrated to CC, does not like the amount to be increased at all or it will only indicate that the CC covered the initial charge and any amount that you added (typically freight) showed as an open AR. We wrestled this for quite some time and still are battling it. The resolution was to create a report to show the orders where the CC didn't equal the total order (they don't do partial CC charge). We reported this to Sage but the first few people didn't know you could use a CC number without being integrated to a processor. The next few denied it was a problem and/or blamed user error (until I demoed it). The last few people sort of shrugged and let me with the impression that Sage wasn't going to worry about a credit card issue if the card wasn't integrated into a processor.

I was wondering if any amount not charged would show as an open balance. Interesting. Not sure it would with APS but still interesting. Thanks @WayneSchulz.

FYI, Bryce said only 3% of their customers are subject to this.