First and foremost "best practice" is to cease to use the term "encryption" because SHA-256 is not encryption. This is called hashing. If your senior developers and the third-party auditors all talk of SHA-256 as "encryption" then rest assured that none of them actually knows what they are talking about.
In your system, whatever the client sends, be it "encrypted" (hashed) or not on the client, is a value that grants access; that value is thus password-equivalent and revealing it is as deadly to the security of your server as the plaintext password. That kind of client-side hashing does not bring the security improvement that your auditors appear to believe it to do. Compounding the situation is the fact that when the client performs hashing with Javascript code, that Javascript code was just sent by the server itself, so a compromised server could perfectly send some Javascript that simply receives the user password as he types it in, and send that password to a server in Mongolia.
In any case, human minds being what they are, user-remembered passwords are weak against brute force (called "dictionary attacks"). A simple invocation of a cryptographic hash function such as SHA-256, irrespective of how cryptographically secure that function is, is way too fast to provide much protection here; an off-the-shelf desktop PC can hash potential passwords at rates counted in billions per second. Good password hashing requires dedicated functions with a configurable (but inherently high) computational cost. You won't be able to do that properly in Javascript because Javascript is feeble for computation-intensive tasks.
The best practice is to use SSL (always), transmit the password as-is in the SSL tunnel, and let the server apply a proper password hashing function, i.e. bcrypt (with a high enough iteration count -- as high as can be tolerated given the available hardware and expected peak load).
Occasionally, one encounters auditors in want of something to say, and you may have to perform some ritual dancing to appease them. One of such dances is sprinkling cryptography in various places, like cake icing. This is idiotic but harmless, as long as you do not remove the important parts. In your case, you can do SHA-256 hashing on the client side, but you must not remove the proper password hashing on the server side -- that is, consider the client-computed hash result as the "password" and use that as input to bcrypt. (Beware that hash outputs are binary, not text, so some encoding is needed, e.g. hexadecimal or Base64.)
The extra SHA-256 would then be useless, but will not make your system weaker -- contrary to what you are purporting to do:
So for our future release, we've transitioned to using cryptojs to encrypt passwords (unsalted) client-side, and these values are stored directly into the database without any further manipulation.
If you do that, then the database contents can be used to grant immediate access to the server. A simple read-only glimpse at the database (e.g. a discarded broken hard drive, a lost backup tape, a SQL injection attack...), and your security has gone down the drain.
