Mrthdrb

I have a magento with a default onepage checkout.

When a fresh registered, active customer tries to checkout I get the message "Prefix is a required field" no matter if the customer has already given his prefix or not.

As the prefix is mandatory for the project, setting it to "not required" is not an option.

How do I get magento to use the already given prefix and not throw this error?

See screenshot for the full situation. This happens no matter if the customer already has an address or not.

I realize this is almost a year old, but I came across this looking for an answer myself; best I can offer at the moment is that the problem arose on the site I'm developing when I imported the customer and sales tables from an older site. The new site was an upgrade to a newer version of Magento (1.7 (IIRC) --> 1.9.2.4) and it appears that the columns in the database don't line up correctly. As a result, the validation fails when there is an attempt to insert the values into the database, even if the frontend validation may succeed.

I had same issue which i fixed in a stupid way on my side :

update customer_eav_attribute_website cea left join eav_attribute ea on ea.attribute_id = cea.attribute_id
set cea.is_required = 0
WHERE attribute_code = 'prefix'

My prefix field was well in is_required = 0 on eav table, but overriden on website table.
The more surprising thing was for me the validator error : "Customer email is required" on OneStepCheckout.
All that for a prefix..

If anyone else stumbles upon this:

The problem is caused by a missing value for the prefix field on customer entity level, not customer address entity.

When activating and requiring the "prefix" field in a shop where there are already existing customers those won't have any value stored for the prefixattribute for either customer entity nor customer address entity.

During checkout the customer can choose to create a new address and enter a value for the now required prefix attribute there but the value will still be missing for the customer entity leading to the error described above.

The only way to fix this is to either set the prefix attribute to not be required in the admin interface or assign a value to the prefix attribute for each customer (for example via a simple php script).