Edit fields for invoicing information

Overview

The form fields for invoicing information (in CiviEvent) seems to be hardcoded. E.g. it lacks company name and email. It does not seem possible to change or amend these fields.

Example use-case

1. Create an event and enable web registrations
2. Make invoicing mandatory
3. Make a registration and notice what the only available fields are

Current behaviour

Hard coded fields

Proposed behaviour

Possiblity to use a profile, or custom form.

Comments

There is a StackExchange question around this: https://civicrm.stackexchange.com/questions/42202/how-can-i-add-company-to-billing-pay-later-fields but the proposed "solution" is hard and really not a solution.

We have been moving towards using tokens rather than smarty variables in message templates (which are more consistent) - I think that the organization_name would be available as the token {contact.organization_name} for organizations & for individuals if their employer_id is filled in. However, you are also wanting the token that would be equivalent of {contact.employer_id.email_primary.email} from what I understand?

Or is the issue the detail is not being collected in the first place?

Maybe I need at least some documentation about how the prompts for billing is supposed to work. Have I just missed it?

As far as I understand the fields input in that form is set as billing address of the primary registrant.

I think I have two issues with respect to this:

1. Many people get confused when they are not able to enter the company name for invoicing. Of course, we already have it from the registrants information (if they have given it, company is not mandatory), but they don't know that. So either we should allow them to enter it (in which case I'm not sure what to do with it, overwrite the current employer does not seem like the right move...), or display the value that we have in the form. Again, I have no suggestions on how to handle the various cases with company given/not given or already known.
2. The billing email is not prompted for. This means that, depending on context, the visible fields needs to be configurable. Hacking the core code, which seems to be the current option, is not sufficient since it might not match all scenarios for a site (not to mention the general problem with doing that...).

In our environment, the billing should (almost) always go to a company, often the employer of the registrant but not always. This might not be the case in other contexts, of course. Billing a company normally includes the company name and a reference.

The form has mandatory fields for "Billing First Name" and "Billing Last Name", where do these end up? Do they create a new individual if they do not match the primary registrant? For a company it would make more sense to have "Company" and "Reference" as mandatory fields.

I'm not sure the "company" given in a registration billing form should overwrite the registrants employer information. Since both the e-mail address and the postal address for billing is available on the registrant, the only information not 100% available is the Name to use for billing (Company or Personal Name).

Does that make sense?

Screen shot of the billing part of event registration:

Also I'd like to be able to configure the order of the fields, Postal Code before City, because that's how we do it in Sweden ;-)

@eileen It seems like the problem is in the data collection (specifically, how the billing block is constructed), not the tokens. I thought I had some ideas to suggest until I re-read and understood better.

mentioned in issue #3892 (closed)

And of course #2761 (closed) is relevant here.

added Concept approved triaged labels

Hi,

Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for quite some time, so we have closed it.

We would like you to help us to determine if this issue should be re-opened:

• If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
• If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?

If the answer to either question is yes, please feel free to comment or re-open the issue. Please also consider:

• Is it something that you could help implement, either by sending a patch or hiring someone who can?
• Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?

Thank you for your help and contributions to CiviCRM.

P.S. This is an automated message, see infra/gitlab issue 20. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.

closed