requiring information after login and before finalizing checkout

[delia]

The cart does not allow outside registration - the manager creates the accounts by using add customer in admin. He needs their tax id but he is not given that information so that he can enter it when he creates the account.

So he wants to prevent the customer from checking out unless they provide that tax id number.

I see two places where this might be easiest to do. One would be on the checkout payment page - just like terms and conditions. If there is no tax id, then the buyer gets an error message telling him to provide the tax id in the edit account section (he actually would prefer them redirected to that page but I don't see how to do that right off hand and then you have to have messaging in a second place to show what is needed)

I also thought about it being a function of logging in. During login, their account is checked for the presence of the taxid and if there is none, then the buyer gets redirected to the edit account page and told to provide the tax id.

My question is are there other scenarios that would be simpler and in general what's the easier way to get to do this (in the code)?

[kobra]

Not in the code but one could change the store function maybe
admin > config > Customer Details > Customer Approval Status - Authorization Pending > set to one of the options

Only approve them if they provide their tax ID

[delia]

No, each is vetted before being manually added. His problem is that he doesn't have control over that vetting process. He is simply given the basic info without the tax id. So this has to happen after they are logged in.

[mc12345678]

I have seen a version of VAT related software that offers this additional field.

As to addressing the above two. The redirect/validation for the checkout_payment page could occur in the includes/modules/pages/checkout_payment page (possibly using an observer on start or end of the file or as another has suggested directly in the file itself, but no matter.

Personally, I would think it would be more desirable to add the field possibly to the checkout_payment page and have it store the data against the user when entered, rather than redirecting to somewhere else that could then guide them to elsewhere (including out of the purchasing process).

Having it on the login page would also make sense to a degree, though would think it would be on the initial "account create" versus just simply logging in.

Just some ideas to add to the above.

As to other locations? Well, there is the users's account page itself, but as far as needing it? Guess it also depends on the benefits offered by having the taxid. If there is to be a difference in prices or display, then would want to have the data as part of logging in like suggested.

[kobra]

No, each is vetted before being manually added. His problem is that he doesn't have control over that vetting process.

Do not understand??
If each is "vetted" why is part of this not obtaining their tax ID??
If he does not have control - then this sounds as if there is a 3rd party doing it and he could/can demand that the tax ID be part of it

[delia]

I certainly agree but we don't know why his situation is set up that way and it's really none of my business. I was hired to provide this to him and I way under estimated the time because he was not clear and I did not make sure my assumptions were correct. Just trying to complete a difficult job or else refund his money.

So Kobra, something constructive would be appreciated.

mc12345678, my first thought was to provide the ability to put the tax id in on the checkout page that now seems like the best way to proceed. Simple would be a change to the query that inserts the order. Perhaps in the class - order.php around line 614? I can add that field to the order and then would need an additional bit to insert it into the customer table somewhere? Does that sound doable?

[kobra]

So at what point does the tax ID get entered/provided currently?

[delia]

He just wants to make sure it's provided before they order - but after they login (guess it could be during the login, too)

[mc12345678]

I certainly agree but we don't know why his situation is set up that way and it's really none of my business. I was hired to provide this to him and I way under estimated the time because he was not clear and I did not make sure my assumptions were correct. Just trying to complete a difficult job or else refund his money.

So Kobra, something constructive would be appreciated.

mc12345678, my first thought was to provide the ability to put the tax id in on the checkout page that now seems like the best way to proceed. Simple would be a change to the query that inserts the order. Perhaps in the class - order.php around line 614? I can add that field to the order and then would need an additional bit to insert it into the customer table somewhere? Does that sound doable?

Without digging in, the thing I would think about is possibly using a session variable for assignment once entered. The thought is this:
Arrive at page (could be stepping forward or cycling through the checkout process).
If the session variable is set use that, if not set then pull from the user's stored information, if not set there, then display the field to be entered.
The next consideration is if this number can be different for the same person or not for each order that they place. If so, then best solution is to provide a pick list of such values including the ability to add one. Otherwise, if not such a pick list then the field is always displayed possibly showing a list of previously used values to copy and paste and the field is always displayed but if previously entered in a loop then it should appear again.

As to capturing in the order, the order class would need to be modified to account for the additional field to be associated either with the user or the entire order (this last appears to be addressed by incorporating in the line section described.)

Then there is the need to pull the information back out on the admin side, which assumably is already addressed.

Ideally, and a little of this has been done here in this thread, need to identify how the data is to be used throughout the process, to what it is relevant, who needs to be able to see it etc... That planning will cut down on the coding and help identify what needs what and where...

[mc12345678]

He just wants to make sure it's provided before they order - but after they login (guess it could be during the login, too)

This somewhat depends on the proposed use of the information, if only one exists per logged in individual or if it can be a per purchase option/requirement. Further this part depends on repeat business, ie. Enter every time, "set it and forget it", offer options at checkout, etc...