Currently the only options for Invoice Delivery Preference in Zuora is Print and Email. In Norway invoices sent to the Norwegian public sector must be sent electronically in the Elektronisk Handelsformat (EHF) based on the Universal Business Language (UBL). If the invoices is not sent electronically the customer can refuse to pay the invoice. As a result of the requirement we have developed a third option for invoicing - electronically invoicing. The solution is fully deployed in Zuora and as fas as we can see it is working fine. But we are experiencing an issue; As the options in Zuora are only Print and Email we have to do a "workaround" and enable the Invoice delivery preference to "No" when the customer should receive the invoice electronically. But we get a problem when we are distributing the invoices. When exporting the invoice PDF's for printing (invoice delivery preference=print), also the invoices with invoice delivery preference "No" are exported as PDF's. A consequence is that the customer will get the invoice twice both electronically and in print. Is it possible is to extend the Invoice Delivery Preference to more options to ensure that that only the invoices with invoice delivery preferebce "Print" are exported and printed?
For example; Delivery Preferences equeals Print (X), Email (0) and EHF (0).
Feature Request: Pass invoice and payment number to PayPal
Status: under evaluation
Reference Number: DE7530
Business Need: Currently when a payment is processed by credit card through PayPal, Zuora will pass payment number to PayPal as in their Invoice Number field; if the payment is processed by PayPal Express Checkout, Zuora does not pass any payment number to PayPal. Some customers have two tenants in Zuora, and both are using the same PayPal gateway and they would like to have the ability to tell which invoice/payment is from their Zuora Tenant 1 or Tenant 2. Therefore, they are requesting if it possible for Zuora to pass both invoice and payment number to PayPal when a payment is processed.
Right now we do not have an option to choose to arrange the way the components are displayed in quote creation or invoice generation. Having an option to sort or arrange in any order will help us a lot. For eg.. all software components on the top followed by hardware components.
We are experiencing major reconcilation issues given the lack of connect for ACH reversals and chargebacks. This seems to be yet another feature not supported with Cybersource. Please provide the Gateway Reconcilation for the Cybersource gateway.
There is a JS error everytime we render the iframe using Z.render() method.
Somone point it out already here: http://community.zuora.com/t5/Integrations-Extensions/Error-X-Frame-Options/td-p/10331
It would be great to have a fix for that.
It would be great if the BillPreviewRun response would include not only the UOM name but the UOM display name. The UOM name is usually configured with no spaces for easer handling via the system providing the usage and the UOM display name is the name the customer wants to show on the invoice or website. Since BillPreviewRun in some case is used to show the usage on a customer portal they want to show the UOM display name not the UOM name.
Feature Request: Improve the payment status determination in Zuora: if responseEnvelope.ack=Success and paymentExecStatus=Error, we need to make the payment as Error.
Status: Currently being reviewed by our Product Management
Reference Number: PMT-1408
Business Need: Currently when a payment with transaction logs as below: Transaction log:
CreatedOn:06/27/2013 16:56:07 PDT
TransactionDate:06/27/2013 16:56:07 PDT
TransactionId: AP-7PT88629314270127ResponseCode: Success
RequestString: actionType=PAY&preapprovalKey=PA-7HE798745K713050H&senderEmailfirstname.lastname@example.org&receiverList.receiver(0).email@example.com&receiverList.receiver(0).amount=1.00¤cyCode=AUD&returnUrl=http://www.zuora.com&cancelUrl=http://www.zuora.com&requestEnvelope.errorLanguage=en_USResponseStrin... responseEnvelope.timestamp=2013-06-27T16%3A56%3A07.862-07%3A00&responseEnvelope.ack=Success&responseEnvelope.correlationId=ec2aa8af0d5d9&responseEnvelope.build=6520082&payKey=AP-7PT88629314270127&paymentExecStatus=ERROR&payErrorList.payError(0).receiver.amount=1.00&payErrorList.payError(0).receiver.email=bwinter%40fairfaxmedia.com.au&payErrorList.payError(0).error.errorId=559044&payErrorList.payError(0).error.domain=PLATFORM&payErrorList.payError(0).error.severity=Error&payErrorList.payError(0).error.category=Application&payErrorList.payError(0).error.message=This+receiver+accepts+PayPal+payments+only+through+their+website,
the payment status in Zuora shows as "Processed", but this payment does not appear in the PayPal account.
So Zuora should make the payment as Error if responseEnvelope.ack=Success and paymentExecStatus=Error.
Customer requires a subscription cancellation callout on the subscription's end date. I believe this can be achieved by leveraging the Key Date callout with Subscription.Status, and having the receiver filter on cancelled subscriptions. Zuora does not give the option to send the subscription status. Please Add Subscription.Status as a Callout Parameter for a Key Date Event
When transferring a Subscription Invoice Owner or changing the Ultimate Parent of an account, the search-logic populated in the dropdown shows the name of various customer account names matching the entered text. Being able to see customer account ID's next to the populated results or being able enter customer account ID's and having the dropdown populate with the linked customer account would be very helpful.
Feature Request: Allow tax to be calculated based on Subscription owner Sold-To rather than always using the Invoice Owner Sold-To.
Status: under evaluation
Reference Number: DE7876
Business Need: In many cases, the location where the service is delivered is more relevant for tax purposes than the location where the service is billed.
My Idea is to introduce a fuction to tokenize a string in more substring
I have a customField on invoice called ex.CustomField_1 and its value is X|Y|Z| .
The character | is the separator of substring. The char X, Y or Z are the single token of original string.
About Tokenize I mean that it is possible to extract a single value(X, Y or Z) from original string (for example I would only the string Y ) and use it in differenposition of invoice template
When an Agent refunds a past payment, this results in an outstanding balance being created for the Invoice that the past payment relates to.
Zuora recommend to perform an Invoice Adjustment to remove the outstanding balance on the Invoice. Unfortunately if a cancellation occurs during that Invoiced period (Month / Year) then proration does not factor in the fact that the customer had a refund and hence did not pay the full amount. Proration will instead use the orginal value of the Invoiced period for it's calculation, this will result in the customer receiving a larger prorated amount than they deserve.
In an Annual Subscription a customer pays £100 per year. Assume the subscription starts the 1st Jan.
If that customer calls to complain about poor service during March, our Agent will give them a £20 refund and perform an Invoice Adjustment to remove the outstanding £20 balance.
If that customer calls up on the 1st July (exactly halfway through the annual sub) and convinces our Agent that their experience was terrible and they want an immediate cancellation, then the Agent will perform an immediate Cancellation. This will result in a negative prorated invoice for the unused period, which we'll refund back to the customer. As we've performed an Invoice Adjustment the correct amount to give back to the customer would be (100 - 20) / 2 = £40, instead Zuora ignores the Adjustment and calculates 100 / 2 = £50 as the prorated amout.
Monthly Rev rec is OOTB and needs to be associated to a product not a customer. As for invoice proration logic, this is currently done at the tenant (not account) level. A RFE will need to be created for this requirement. There is no workaround.
the notification Invoice Due can be configured to trigger one N day(s) before or after the invoice due date. What can't we specify 0 on either type of notification to be notified on the day the invoice is due?
The GUI rejects the value 0, but I don't seem to see any valid reason for that.
Off the top of my head, the Key Date(s) AutoRenew notification has the same behaviour.
In our case we have to configure Payment Terms with one less day triggering one day after to be able to trigger on the date of the invoice due.
The March release improved the subscribe() SOAP API behavior to still send VoidAuth transactions when subscribe() fails. This greatly reduced the number of Authorization transactions that expire without being deposited or voided. However, the VoidAuth transactions occasionally fail.
When the Authorization expires for a Visa card, you get Misuse of Auth fees from Visa. MasterCard has similar MC Processing Integrity fees.
There are good descriptions of the fees here:
Currently, when net terms on an account are updated, existing invoice due dates do not get updated to reflect. The invoice pdf can be regenerated for presetation to the customer, but in the system the original due date remains. This skus AR Aging, etc. We would like to see that field updated on the invoice object.
To support this , Zuora has suggested that we perform a refund equivalent to the credit memo to allow for the invoice amount to be ‰Û¡ÌÝÌáopen‰Û¡ÌÝå» for credit process & application. However such a method is not sustainable impacts the bank reconciliation (particularly credit card on file for pmt), account history (unable to identify true refunds vs credit memos processed on paid invoices); additional DM entry in our other accounting applications to clean up the refund entry on the subledger. Request to build in a feature to allow process credit requests again paid invoices.
It would be very useful to be able to pull an Invoice Item report directly from an invoice in the GUI. This would ideally output the same information as the "Invoice CSV" export, except that it would be filtered for the invoice currently being viewed.
I would the option for Usage period to remain open after posting Usage to an account, and close the Usage period upon Zuora period close.
If I am billing a customer for more than one type of transactional revenue it would be more user friendly to upload usage type#1> generate invoices, then upload usage type#2 and generate invoices and so on. This would allow me to review bill runs more accurately as well as keep invoices limited to one type of usage for customer transparency.