Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
Just applied the 2010 Year End Payroll Tax Update to MS Dynamics 10.0, which included sp5 for Dynamics. (Running on SBS2003, SQL 2005).
After installing, now customers' credit card numbers are masked/hidden in some windows, including (but not limited to) the Sales Payment Entry window. It used to show all 16 digits of customer credit card number, now it only shows the last 4 - the first 12 are masked out with "X"'s. This is a real pain as our sales agents need to see the credit card number while processing the invoice to punch the number into our crdit card processing machines to confirm payment before we can complete the invoice & approve the order.
Is there some new security setting perhaps that will revert back to the previous behavior of showing the entire credit card number in these windows?
In order to be PCI compliant, the credit card number needs to be encripted. The encription is causing the first 12 digits to be displayed with X's. If you were to undergo a PCI audit and had unencripted credit card information stored on the customer record you would fail the audit. You would also be exposing yourselft to extremely high fines if there are any problems and you aren't PCI compliant (ie $5,000 per transaction).
I would recommend investing in a credit card processing solution such as Nodus. The streamlined process (ie not having your sales people waste time going to the cc machine) and reduced processing fees due to using a PCI certified solution will quickly cover the cost of the Nodus.
It looks like Korey answered your question correctly, to be compliant the encription in GP is required and working as designed. There is no setting to unmask the credit card number. However you could look into using Modifier with VBA to possible modify the window to do what you want.
Let me know if you have any questions.
Customer Online Technical Community
We hope you get value from our new forums platform! Tell us what you think:
This posting is provided "AS IS" with no warranties, and confers no rights
Dan has the answer!
Using Modifier/VBA you can use the before user changed (or before changed) event to get the number and record it somewhere else, say into a new local field on the window that you save to the DUOS table.
If the credit card number is encrypted as it should be you not be able to use VBA to reveal the code. Plus if you do capture the data and put it in another field before saving, you will be violating the PCI-compliance rules. If you have an issue and it discovered that you were storing the data in an field that was not encrypted, you could be subject to fines that are as much as $5000 per transaction.
I am not sure that recommending an option to circumvent the PCI-compliance rules is in the best interest of this community.
We have also seen situations where the merchant bank have added an additional $1,000 plus per month fees if a non-PCI compliant systems was being used.
Adding a credit card solution to Dynamics GP that is PCI compliant and lets them process the card from within GP will save them money and eliminate a lot of risk. Yes, it might cost some to buy and implement, but they will get an ROI in a short time with time savings etc.
Third Wave Business Systems
I did not 'recommend' anyone circumvent the PCI-compliance rules, I merely spoke of existing functionality of GP. If this is a vulnerability of the software, perhaps it should be addressed in SP 6. We should probably put it on the product suggestion board, but I'm betting they already know.
At any rate, to reveal a way to get around GP's security would be irresponsible, it's up to each client to decide how they will handle contingent liabilities.
I doubt all of our customers are striving for PCI compliance.
Storing the number in a different unencrypted field is a violation of the PCI compliance rules. And therefore recommending this approach is a recommendation to violate the rules. It doesn't matter that you are recommending using standard GP functionality.
Meeting the PCI compliance rules can be difficult. Many companies think that it too much of hassle and causes extra steps. It is definitely their choice to not be compliant. However, they need to understand the risks and costs associated with the not being compliant. If they arent compliant and someone takes the list of credit card numbers, they can be fined $5000 for each stolen card number! if 100 card numbers are stolen, it is a $500,000 fine.
If someone is going to recommend circumventing the rules, then you should outline risks associated with that approach.
As mentioned before, GP masks these numbers to be compliant. You can use VBA to create a customization to help with what you need. But as other posts have mentioned, since GP masks these to be compliant creating something to unmask them may not be compliant obviously.
However VBA is an option and you may be able to create a customization of some sort that is both compliant and does what you want.
For assistance with creating a VBA customization that will both fit what they need and be compliant you would want to submit a support incident to have it routed to the correct team who can help with this. Otherwise this is working as designed:
To create a support incident request, go to CustomerSource > Support > Assisted Support > New Support Requests, or, you can use this link: mbs.microsoft.com/.../createincident.aspx.