Community - About Dennis

Ben_D · ‎08-19-2020

Following up on this. Splitting Payments across Invoices and applying to specific line items on an invoice is now fully supported. This is covered by Invoice Item Settlement. For more information please see the following KC article. https://knowledgecenter.zuora.com/Billing/Billing_and_Payments/Invoice_Settlement/C_Invoice_Item_Settlement The same principal applies to refunds and credit memos.

simplementos · ‎03-20-2020

we still experience that issue. Any updates on that?

rich_lloyd_judd · ‎10-10-2019

Thanks but in my case I was only interested in the failed callouts, the response I received didn't include all of the ones I could see in the gui and there were no pagination links to find more. Zuora have since confirmed they're working on a fix: Thank you so much for your patience, As I said earlier it is a bug from our end and we are planning to deploy the solution in the mid or later in this month on the release of 259. Last release was 257 on September 26, 2019. Kindly refer to the below release notifications to have the status of the R259. https://community.zuora.com/t5/Release-Notifications/bg-p/ReleaseAnnouncments We regret for the inconvenience caused from our end.

ayonge · ‎06-27-2018

Thanks Patrick!

Dennis · ‎07-06-2017

Reason: This is cuased by comment e.g. /* */ was added in the customization code field of HPM setting page. In Release 213, jQuery was upgraded from 1.7.1 to 1.11.0 which is used by HPM 2.0. New version jQuery does not supported to put comment e.g. /* */ in any customization code field of HPM configuration setting page Solution: Remove the comment code from the customization field of HPM configuration setting page

Dennis · ‎06-15-2017

Answer: One possible reason is the amount field of InvoicePayment object does not have a value. Here is a sample create call which can generate the error: <ns1:create xmlns:ns1="http://api.zuora.com/"> <ns1:zObjects xsi:type="ns2:Payment"> <ns2:AccountId>2c92c0f94fb13b11014fb62fc96e0fe7</ns2:AccountId> <ns2:Amount>200</ns2:Amount> <ns2:EffectiveDate>2017-09-25</ns2:EffectiveDate> <ns2:AppliedCreditBalanceAmount>0</ns2:AppliedCreditBalanceAmount> <ns2:InvoicePaymentData> <ns1:InvoicePayment xsi:type="ns2:InvoicePayment"> <ns2:Amount></ns2:Amount> <ns2:InvoiceId>2c92c0954fd7d8eb014fd8aed4b97eb1</ns2:InvoiceId> <ns2:RefundAmount>0</ns2:RefundAmount> </ns1:InvoicePayment> <ns1:InvoicePayment xsi:type="ns2:InvoicePayment"> <ns2:Amount>100.0</ns2:Amount> <ns2:InvoiceId>2c92c0954fd7d8eb014fd8aed4aa7eaf</ns2:InvoiceId> <ns2:RefundAmount>0</ns2:RefundAmount> </ns1:InvoicePayment> </ns2:InvoicePaymentData> <ns2:PaymentMethodId>2c92c0f94fd7f22d014fdec5721d16b8</ns2:PaymentMethodId> <ns2:Status>Processed</ns2:Status> <ns2:Type>External</ns2:Type> </ns1:zObjects> </ns1:create> and the response: <?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <ns1:createResponse xmlns:ns1="http://api.zuora.com/"> <ns1:result> <ns1:Errors> <ns1:Code>MISSING_REQUIRED_VALUE</ns1:Code> <ns1:Message>Amount of the InvoicePayment cannot be omitted.</ns1:Message> </ns1:Errors> <ns1:Success>false</ns1:Success> </ns1:result> </ns1:createResponse> </soapenv:Body> </soapenv:Envelope> According to below article, the amount is the required field of InvoicePayment object: https://knowledgecenter.zuora.com/DC_Developers/G_SOAP_API/E1_SOAP_API_Object_Reference/InvoicePayment

bolaurent · ‎06-06-2017

Note that if you create a custom field in Zuora and you are using SOAP API, you will need to download a new WSDL. This is not necessary if you use REST API. Bo

kconnor · ‎05-24-2017

ProductRatePlanChargeId is also set for previews. This applies to both Amend and Subscribe calls.

alok · ‎05-09-2017

Please share the order builder code for the same as we tried adding InvoicePaymentData but that didn't added increated soap request

Seb · ‎04-25-2017

Hi @Dennis, Yes they are the same now, it look like Zuora updated it in between. Thanks, Seb

bolaurent · ‎04-23-2017

Really? The documentation says "ZOQL does not support sorting results in ascending or descending order." Also, I tried this query (via rest): select id, name from rateplan order by name; and the result is: Error: q AssertionError('POST to /action/query failed: b\'{"faultcode":"fns:MALFORMED_QUERY","faultstring ":"You have an error in your ZOQL syntax","detail":{"MalformedQueryFault":{"FaultCod e":"MALFORMED_QUERY","FaultMessage":"You have an error in your ZOQL syntax"}}}\'',)

vu_phan · ‎04-17-2017

The error indicates that the quote metrics are failed to calculate because the quote's Invoice Target Date falls into a Closed Accounting Period. Here are the scenarios in which the error can happen. Invoice Target Date is set to a date in a closed accounting period. Invoice Target Date is blank. In this case it is set based on the value of Start Date and Calculate Quote Metrics Through field which cause the Invoice Target Date to fall into a closed accounting period. For example, Start Date = 03/01/2017 and Calculate Quote Metrics Through = 1, so Invoice Target Date would be 03/01/2017 which is in a closed accounting period. To resolve the issue you can either Set Invoice Target Date to a date in an open accouting period Change Calculate Quote Metrics Through field so Invoice Target Date would be in an open accounting period

Dennis · ‎04-07-2017

Answers: 1. If the card number of the default payment method has changed, Zuora PMU will close the existing payment method and then create a new payment method and set it as the default payment method on the account. 2. If the expiration date of the default payment method has changed, Zuora PMU will update the existing payment method with the latest expiration date on the account. By the way, PMU will not reset the "Consecutive Failed Payments" while updating the payment methods.

Dennis · ‎04-01-2017

Solution: Go to Z-Payment settings > Setup Profiles, Notifications and Email Templates, we can see a list of events which are configurable to enable/disable notifications(email or callout). Please see below screenshot. You can disable the highlighted events to stop emailing out if the payment method is closed or updated by Payment Method Updater.

Dennis · ‎03-31-2017

Solution: The error is thrown by an expired certificate. Please check whether your p12 from CyberSource is still valid? You might also need to contact CyberSource Support to confirm this. If you p12 file has expired, please generate a new p12 file from CyberSource and upload the new certificate to your CyberSource gateway in Zuora. You can upload the new cert by navigating to Z-Payments Settings > Setup Payment Gateway > Click on the edit button for the CyberSource Payment Gateway > Upload the new Private key file.

weiwei · ‎03-31-2017

Great News - You'll be pleased to know that we're to release a fix to the reported issue in R211, targeting Sandbox deployment on 12 April and Production on 19 April.

Dennis · ‎03-31-2017

Hi @yihaoye, The Payment Page is the page allows end user to enter their electronic payment method and submit to Zuora. If you are looking for the method to create a page to allow customer to select their electronic payment methods, it should be customized by merchant themselves. Regards, Dennis

Dennis · ‎03-27-2017

@tarunks, Here is a document about PayPal Express Checkout gateway. http://knowledgecenter.zuora.com/CB_Billing/M_Payment_Gateways/Supported_Payment_Gateways/PayPal_Exp... As a background information, Zuora gateway integration is working like a messenger which means, Zuora sends the payment transaction API call to payment gateway and reply the gateway's response to merchant via UI or API (Depends on how the payment was created). The gateway's response contains the error codes, error messages and some other information. However, those information are basically from gateway side and Zuora does not change those information. If you got any error while doing payments in Zuora, you can refer to PayPal Express Checkout document for the reason of failure. Regards, Dennis

Dennis · ‎03-27-2017

@tarunks, Processing refunds with PayPal express checkout integration is same as other payment gateways. With electronic refunds, it will automatically refund money to the customer's credit card. For more information, you can refer to below articel about refunds in Zuora. http://knowledgecenter.zuora.com/CB_Billing/K_Payment_Operations/Refunds Regards, Dennis

Dennis · ‎03-22-2017

Known issue: We might see some payments do not have external refunds created by Zuora Gateway Reconciliation. Those payments are in chargeback status at payment gateway side. Root cause of the problem: This is a design gap issue in Gateway Reconciliation. If the payment was settled first in payment gateway and then changed to ChargedBack status, we apologize that this scenario is not supported in current product design. Status: Engineer team is aware of this design gap and they are planning to enhance the Gateway Reconciliation function in future release. ETA is still under discussion. Workaround: In current stage, the workaround is to manually create the external refunds on those impacted payments either via UI or API calls. Reference Number: PAY-8380

Dennis · ‎03-21-2017

Hi @sunyu, I have attached the use case description file to this RFE. Our product manager team will review and response to the post. Thank you! Regards, Dennis

Lana · ‎03-20-2017

Thanks for sharing your solution with the community, @grantni!

Dennis · ‎03-19-2017

Solution: The target date of the payment run must be on or before the date when the payment run is executed. Otherwise, the invoice might be charged by using an electronic payment method rather than by applying the credit balance. For example, if the payment run is executed on September 2 but you set the target date of the payment run to September 3, the credit balance amount might not be applied to the invoice. Reference article: http://knowledgecenter.zuora.com/CB_Billing/G_Credit_Balances/C_Applying_Credit_Balances

Dennis · ‎03-06-2017

Solution: We can doing a data source export on 'Gateway Reconciliation log' and checking the number of exported records. Please follow below steps to extract the Gateway Reconciliation log: 1. Goto the UI and click "Reporting", (left navigation pane) 2. Click on the "Data Sources" 3. Select "Gateway Reconciliation log" as the "Data Source" 4. Select All "Gateway Reconciliation log" fields. 5. In the Filters section, select filter based on the job number. 6. Click "Export" In the export list, we can see the Number of Records/Files of the export job. Doing the export at 5 minutes interval, if the Number of Records/Files is increasing which means the reconciliation job is still working. Otherwise, that means the job is hanging. Please contact Zuora support to change the status of the job to "Error" so you are able to retry the job afterwards.

Richard · ‎03-02-2017

@smdavis , Zuora also documents the pro-ration calculation in our KC here: http://knowledgecenter.zuora.com/BC_Subscription_Management/Subscriptions/G_Proration/Calculating_Total_Amount_with_Partial_Period_Proration There's a couple of examples included, but as the KC points out the exact results can vary based on tenant settings, so be sure to check your tenant against the settings mentioned in the KC page.

Dennis · ‎02-10-2017

Hi @PeterKis, The best practise can be vary due to use cases and scenarios from different customers. However, you can refer to below article for the detailed description of the retry rule configuration and choose a best way fits your use case. http://knowledgecenter.zuora.com/CB_Billing/L_Payment_Methods/H_Configure_Payment_Method_Retry_Rules Regards Dennis

Dennis · ‎02-05-2017

Hi @PeterKis, In this case, you have to cancel the invoice before you are able to rollback the amendment. Thank you Dennis

Dennis · ‎02-05-2017

Resolution: In CyberSource gateway API v1.97 setup page, there is an option 'Skip optional fields'. If this option is enabled, below 4 optional billTo fields will not be sent to CyberSource. The “billTo_customerID” is the information discussed at here: -“billTo_customerID” -”billTo_company” -”billTo_phoneNumber” -”billTo_ipAddress” Tthe reason we have this option for merchant to select is that CyberSource has some front-end validation wherein several special characters are rejected during a transaction request. This prevents the merchants from processing successful transactions whenever there’s a special character on these optional fields wherein the validation has been implemented. For instance, the field billTo_company does not support several special characters, including a colon ( : ) . This CyberSource optional field is mapped to the Zuora Billing Account, thus if the Account has a special character, the transaction request will fail the validation. https://support.cybersource.com/cybskb/index?page=content&id=C1251 With above information, merchant can decide whether or not to enable the option based on their business use case.

Dennis · ‎02-03-2017

Hi @rdavila, You have to doing a query call to query out the subscription Id and version with the subscription name and then use the subscription Id as a condition to query out the RatePlan id and finally, using RatePlan id as a condition to query out the information of RatePlanCharge object. Alternatively, you might think of ZOQL query to create an export like below query: select subscription.*, RatePlanCharge.* from RatePlanCharge So you can filter the information you need from the output file of the ZOQL export. Thank you!

Dennis · ‎01-22-2017

Root cause: FirstData Payeezy does not support multiple threads on concurrency in their API. The rate limit is 5 transactions per second in their test and production environment.

Happy Business Starts Here