Starting Feb 15, 2018 in Dynamics 365 for Retail and Finance & Operations, Retailers shall not be able to display intelligent product recommendations on the point of sale (POS) device any more. (for more information, see Personalized product recommendations).

For all Dynamics 365 for Finance and Operations removed or deprecated features, see Removed or deprecated features

The post Retail Personalized product recommendations appeared first on Microsoft Dynamics 365 Blog.

As another reminder, here is the link to the latest blog notice on the discontinuation:
Reminder: Microsoft Dynamics Online Payment Services will be discontinued on Dec 31, 2017

If you are still utilizing Dynamics Online for your payment solution, I would like to provide you with some helpful information to prepare for the discontinuation of the service that is fast approaching.

Payment provider merchant account
As noted in the reminder blog above, while DOPS is being discontinued, this does NOT cancel your payment provider merchant account.  This will only remove the ability to process payments using the DOPS gateway, Microsoft does not own or have access to the payment provider merchant accounts. 

To avoid future billing, if you have a merchant account with First Data, Bank of America, CyberSource, or PayPal and will not be using that account with your new solution, please contact your payment provider to ensure that your merchant account is closed.

Access to the Dynamics Online portal
After December 31, 2017, you will no longer be able to log into the Dynamics Online portal.

Transactional reports (last 90 days only)
The Dynamics Online portal does have the option to Export to Excel.  If you believe you will need a list of transactions for reconciliation, please ensure you export the data prior to the end of the day on December 31.  As of January 1, 2018, you will have 2 options to obtain this information:

1. Contact your payment provider for transaction details and reports
2. Open a support ticket with Microsoft to have an engineer assist you in obtaining transactional data.

DOPS transactions that are currently processing
If you have yet to migrate to another solution and will still be using Dynamics Online as of December 31, this presents the question as to how these transactions will be processed.  Keep in mind that you cannot process (authorize, capture, void, refund) any transaction through DOPS after Dec 31, even if that transaction occurred prior to Dec 31.  You will need to contact your payment provider for assistance.

DOPS transaction types

• Credit cards linked in AX – All credit cards linked to customer accounts created with DOPS service will need to be recreated in AX using the new payment provider solution. 
• Authorized – This will stay authorized in our system but the bank will remove the auth hold on the funds for 3-5 days.
• Captured – Funds transferred (Most transactions are captured real time.  For the First Data nightly batch settlement, this will be executed the next day, Jan 1).
• Void – Funds have been rolled back.
• Refund – Funds have been refunded.

 After the 12/31

• Credit cards linked in AX – Will no longer work for any connector, need to be deleted and re-entered.
• Authorization – Will be lost.  Either process this through your new solution or work with the payment provider to capture an existing authorization if possible.
• Capture – Will not be able to process linked refunds.
• Void – Will not be able to void a payment.
• Refund – Will not be able to refund a payment.
  

Existing credit cards on customer accounts
To reiterate the above note.  Credit cards linked to customer accounts in AX that process through Dynamics Online will no longer be valid.  When adding a new credit card, it is linked to the default credit card processor at the time the card was added.  This cannot be updated, the card needs to be removed from the system.  Also, there is and will not be an option to Export any credit card data due to security and privacy reasons.  You will need to notify your customer that you have changed the way you process credit cards and for security reasons need to obtain their credit card again. 

The post Dynamics Online Payment Services – important notes on the discontinuation appeared first on Microsoft Dynamics 365 Blog.

This is a reminder that as of the end of the day on December 31, 2017, Microsoft Dynamics Online Payment Services (DOPS) will be discontinued and you will no longer be able to process payments through the service.  Please ensure that you are on track to implement an alternative solution well ahead of time and have a back up plan for any possible down time moving to your new service if any issues where to arise after December 31, 2017.

Also, while DOPS is being discontinued, this does NOT cancel your payment provider merchant account.  This will only remove the ability to process payments using the DOPS gateway, Microsoft does not own or have access to the payment provider merchant accounts.  If you have a merchant account with First Data, Bank of America, CyberSource, or PayPal and will not be using that account with your new solution, please contact your payment provider to ensure that your merchant account is closed when you move to the new solution to avoid future billing from the provider for their account service.

If you have any questions, please email dops@microsoft.com.

Here is a link to the original discontinuation notice:

https://blogs.msdn.microsoft.com/axsupport/2017/01/03/discontinuation-of-dynamics-online-payment-services/

The post Reminder: Microsoft Dynamics Online Payment Services will be discontinued on Dec 31, 2017 appeared first on Microsoft Dynamics 365 Blog.

A notice was recently released on the discontinuation of Dynamics Online Payment Services.  Please review this notice using either the PartnerSource and CustomerSource links or the verbatim below: 

PartnerSource
https://mbs.microsoft.com/partnersource/northamerica/news-events/news/onlinepaymentservdisnotice

CustomerSource
https://mbs.microsoft.com/customersource/northamerica/news-events/news-events/news/onlinepaymentservdisnotice

Discontinuation verbatim:
Effective January 1, 2018, Payments Services for Microsoft Dynamics ERP (Payment Services), available with any versions of Microsoft Dynamics AX, Microsoft Dynamics NAV, Microsoft Dynamics GP, Microsoft Dynamics RMS, Microsoft Dynamics POS 2009, and Microsoft Office Accounting, will be discontinued. Customers of the Payment Services will not be able to process credit or debit card transactions after December 31, 2017.

To mitigate the potential business impact of the Payment Services being discontinued, customers should consider payment solutions provided by Dynamics Independent Solution Providers (ISVs) by searching by searching Microsoft’s AppSource or Solution Finder, or work with their Dynamics implementation partner to determine options.

Customers who have not cancelled their subscription to the Payment Services and whose subscription is due for renewal before January 1, 2018 will receive the annual, automatically generated, 12-month subscription renewal notice for this service.  Subscriptions to the Payment Services will be renewed only for the period beginning on the date specified in the renewal notice and ending on January 1, 2018.  A customer’s subscription to the Payment Services may not be renewed for 12 months depending on the date it expires.  The notice supersedes any subscription renewal a customer receives. If you have any questions, please email dops@microsoft.com.

The post Discontinuation of Dynamics Online Payment Services appeared first on Microsoft Dynamics 365 Blog.

With the increased usage of the number of Retail discounts associated to items coupled with the trade agreements and affiliations, the Pricing engine has seen significant performance issues attempting to process the best discount.  This performance degradation increases as more items are added to an order due to the proportionately increasing number of discounts needing to be processed.  While there have been a few hotfixes to address a few specific performance issues, it is recommended to be on the latest build to ensure you have all of the latest fixes. (Please open a support case if you need assistance finding the latest Retail fixes.)

The main purpose of this article is to bring to your attention out one of the main advantages of being on the latest builds, and that is the configuration settings available in the Retail parameters under Discounts that allows you to choose how to process discounts.  When you open the Retail parameters to view the Discount form, you will see three options that were added based on how you would like to process overlapping discounts: Best performance, Balanced calculation, and Best discount.

Keep in mind when choosing between these options that the Best performance calculation may result in a discount that is not the best for the customer, but to save on performance it is the Heuristic result that was returned.  As such, you may need to test the 3 options based on the number of discounts you have configured to ensure you are seeing the expected results.  This may include needing to minimize the number of discounts associated to an item, deleting outdated discounts that may be included in the calculation but are no longer used, use scannable coupon discounts as seen fit, group items of high quantity by different units (box, crate, 6pack..), etc.

You can read the details of each option in the screenshot below, click on the picture to enlarge it for better readability.

NOTE: At the top of the screenshot you will also see that another new checkbox option was added: “Apply discounts to price overrides”.  In the past, when a price override operation was used at the POS, you could not apply a discount to that item.  POS saw this price override as the final price of the line item.  When using this option, you can now perform the price override to update the sales price and then apply a discount to that price.

I understand that there may be other scenarios in which using Best performance may still take time calculate the discounts on the order.  If this is something that you feel needs to be addressed, please open a new incident with the AX support team with detailed discount setup instructions and steps to reproduce the issue.

I hope you find this helpful and thanks for reading!

The post Retail discount calculations – Performance vs Best price appeared first on Microsoft Dynamics 365 Blog.

When configuring discounts and setting the Discount concurrency mode, you have the option to choose Exclusive, Best price, or Compounded.  The question presented when ringing up POS transactions is which one takes precedence when you have multiple discounts that are applicable to the same sale?  This article will provide you with a brief explanation on the precedence of these configurations.

As you configure your discounts with these 3 options, keep in mind:

1. When multiple Compounded discounts are applicable, the highest discount will always calculate first.  The next highest discount is then calculated on the remaining amount.  This calculation hierarchy will continue until all applicable Compounded discounts have been applied.
   • Correct: 40% discount + 20% discount = 52% discount
     • (40% discount on $100 = $40. Remaining = $60.  20% discount on $60 = 12. Remaining = $48)
   • Not Correct: 40% discount + 20% discount = 60% discount
2. Exclusive discounts will always apply over a Best price or Compounded discount, even if it is the lowest discount percentage.
   • When more than one Exclusive discount is applicable, the highest will be used.
3. When Best price and Compounded are both applicable or if multiple of the same one is applicable, the highest discount will be used.

Now that we have covered the basics, let’s take a look at a transaction matrix consisting of 3 discounts (20%, 30%, and 40%) for each transaction.  Each Discount will be configured with 1 of the 3 concurrency modes.  We will then determine which discount is applied to the transaction based on what we know about the discounts in the information provided above.

The post Retail Discount Concurrency Modes appeared first on Microsoft Dynamics 365 Blog.

MPOS has the ability to send receipt emails in real-time.  This utilizes the RTS to call directly back to AX to send the email at the time of the transaction.  This is unlike EPOS where the posting of the transactions via statement posting process is required before the email can be sent.  EPOS has not changed, see the EPOS blog article for these specific steps.

The intent of this blog is to help provide the basic information and links on how to configure and send email receipts for MPOS transactions.

To get started, you will first need to configure a SMTP server to send the emails.  The link below will take you to the TechNet article that walks you through the steps to configure this.

IMPORTANT NOTE:  At the time of writing this article, the sendEmail method in the RetailTransactionService class does require the use of SMTP to send email receipts.  It may be possible to customize this if you would like to use an Exchange service, but it is not supported at this time.

Configure email functionality in Microsoft Dynamics AX

https://technet.microsoft.com/en-us/library/aa834374.aspx

You will then need to configure the email receipts settings in the Retail.  There are 3 options for how receipts will be printed/sent: POS, e-mail, or both.  You can set these to be specific to a Customer or in the Retail parameters.  The Retail parameters setting will be used when you ring up a transaction at the MPOS without a customer.  See the TechNet link below for details on setting these configurations.

Set up email receipts

https://technet.microsoft.com/en-us/library/hh597117.aspx?f=255&MSPPError=-2147217396

Set default options for email receipts

1. Click Retail > Setup > Parameters > Retail parameters.
2. Click the Posting tab, and then under Email receipt, in the Receipt option field, select an option as the default:
   • POS – Print receipts from the point-of-sale register.
   • E-mail – Send receipts to customers in email messages.
   • Both – Print receipts from the point-of-sale register and send receipts to customers in email messages.
3. In the Subject field, enter the text that appears by default in the subject line of a receipt that is sent as an email message.
4. In the File name field, enter the file name for the attachment such as “ContosoSalesReceipt”. Do not include the file extension.
   NOTE: You will need to following KB in order for the entered File Extension name to be used:
   – KB 3147122 – Emailed receipts do not use the file name specified in the retail parameters
   – https://fix.lcs.dynamics.com/home/index/373711/kb/3147122

Set email receipt options for a customer

1. Click Accounts receivable > Common > Customers > All customers.
2. On the All customers list page, select a customer, and then, on the Customer tab, in the Maintain group, click Edit.
3. In the Customers form, on the Retail FastTab, select an option in the Receipt option field:
   • POS – The customer will receive only printed receipts. The printed receipt is generated from the point-of-sale register.
   • E-mail – The customer will receive only email receipts.
   • Both – The customer will receive both a printed receipt and an email receipt.
4. In the Receipt email field, enter the customer’s email address if you selected either E-mail or Both in the Receipt option field.

Set up an E-mail Template for receipts

1. Click Organization Administration > Setup > E-mail Templates
2. Press CTRL + N to create a new template.
3. Complete the following in the Overview tab:
   1. E-mail ID:  EmailRecpt  (this name is to be entered exactly as seen, it has been hardcoded to look for this ID).
   2. E-mail description:  Enter a description.
   3. Default language code:  Select the desired language.
   4. Sender name:  Specify a name for the sender of the email – customers will see this on the email as the From name.
   5. Sender e-mail:  Specify a valid email address – customers will see this on the email as the From email address.
4. In the lower grid, configure the following:
   1. E-mail ID:  This should already be populated as EmailRecpt.
   2. Language:  Specify the desired language here again.
   3. Subject:  Enter a subject for the title of the email that will appear on all email receipts.
   4. Layout:  Choose the desired formatting language.
   5. 
5. Click the E-mail message button to fill out the template for the Body of email messages to be sent.
   NOTE:  EPOS attaches the receipt as a PDF, MPOS sends the receipt in the body of the email message.
   1. Type up the body of the message you want to have for the customers.
   2. Wherever you want the receipt to appear (as seen in MPOS), insert the placeholder %message% 
      NOTE:  This is the only placeholder the code will replace when sending MPOS receipts as it is the only thing sent by MPOS – getting more placeholder options would require customization on the MPOS side.
   3. 

Depending on the settings that you configured, you will need to run the respective Distribution schedule jobs to sync these changes to POS.

1. 1010 – Customer
2. 1070 – Channel configuration
3. 1090 – Registers
4. 1110 – Global configuration

MPOS transaction

Perform a transaction in MPOS, enter an email address, and click Send.

The following email is sent to customer real-time.

The post Sending email receipts from Retail MPOS Transactions (AX 2012) appeared first on Microsoft Dynamics 365 Blog.

Processing refunds can be a very simple and easy task, a customer returns an item that they do not want and you refund the money they paid for it right? Unfortunately, it’s not quite that simple as you also need to take into consideration partial returns, taxes, discounts, freight, and restocking fees?

There are 3 main areas of Microsoft Dynamics AX that returns are processed through in respect to credit card functionality: Accounts Receivable, Call Center, and MPOS/EPOS. I will be covering some basic scenarios and suggestions on how to process a refund based on the current design of the application.

Optional note: Another refund scenario to consider in place of issuing a straight up refund to a customer’s credit card is to issue an account credit for future orders or a check refund process to track refunds. I have seen both of these being used by businesses, which can help deter fraud returns. The refund terms are normally defined in additional sales agreement verbiage. This also allows for additional return options in AX outside of the credit card processing limitations.

Accounts Receivable (AR):

The design expectation is that you will be creating a Credit Memo/Note from the original Sales Order to perform the return/refund. The credit card functionality in AR is strict that it is expecting a “return of the item” and not just crediting the credit card. This functionality is not included in the Payment journal form nor is it supported to use RMA’s (Return Merchandise Authorization). If you are not returning an item but want to refund a certain dollar amount, a workaround or customization is needed as this is not directly supported through AR.

Below are a few basic scenarios and suggested solutions. There may be other scenarios but this small list will provide you with a basic understanding to help determine a solution for anything not listed below.

• Refunding the entire transaction (Net amount, Charges, and Taxes).
  
  • On the original sales order, click Create Credit note on the Sell menu tab.
  • Select the sales order and the item lines to be returned.
  • All entities (items, charges, taxes) will be included in the refund.
  • Invoice the Credit note sales order to refund the credit card.
• Refunding only a few of the items from the transaction (Net amount, Charges, and/or Taxes).
  
  • On the original sales order, click Create Credit note on the Sell menu tab.
  • Select the sales order and the specific item lines to be returned.
  • The selected items and their associated taxes along with ALL charges will be included in the refund.
  • Make any updates as needed to create a partial refund, such as removing or changing the charges, or changing line items quantities.
  • Invoice the Credit note sales order to refund the credit card.
• Refunding only partial of the net amount (price adjustment).
  
  • In this scenario, you are looking to refund the customer an amount of the sale, not an actual item or any of the charges or taxes.
  • On the original sales order, click Create Credit note on the Sell menu tab.
  • Select the sales order and one of the item lines in order to create the return order.
  • Delete the line item as you are not returning that item.
  • Add a non-inventory item (Price Adjustment) that will need to be used to perform the refund.
  • Make any updates as needed such as removing the charges.
  • Invoice the Credit note sales order to refund the credit card.
• Refunding only certain items.
  
  • On the original sales order, click Create Credit note on the Sell menu tab.
  • Select the sales order and the specific item lines to be returned.
  • The selected items and their associated taxes along with ALL charges will be included in the refund.
  • Make any updates as needed to create a partial refund, such as removing or changing the charges or changing line items quantities.
  • Invoice the Credit note sales order to refund the credit card.
• Refunding only charges/fees.
  
  • You cannot refund charges without returning an item as the Invoice option will not be enabled.
  • On the original sales order, click Create Credit note on the Sell menu tab.
  • Select the sales order and one of the item lines in order to create the return order.
  • Delete the line item as you are not returning that item.
  • Add a non-inventory item (Charges-Fees Refund) that will need to be used to perform the refund.
    • Either use the non-inventory item with a dollar amount for the refund (remove the charges)
    • Or have a zero price for the non-inventory item and the Charges amount will be refunded (recommended)
  • Invoice the Credit note sales order to refund the credit card.
• Refunding only Taxes.
  
  • Taxes are not line items nor are they normally refunded without the item. The design of sales orders does not support the direct refund of just the tax to the credit card. Thus performing any reversal not involving the return of the item does not affect any tax posting accounts.
  • On the original sales order, click Create Credit note on the Sell menu tab.
  • Select the sales order and one of the item lines in order to create the return order.
  • Delete the line item as you are not returning that item.
  • Add a non-inventory item (Tax Refund) that will need to be used to perform the refund and enter the amount of the tax refund.
  • Invoice the Credit note sales order to refund the credit card.

Call Center:

The credit card functionality in Call center can be used similar to that of AR. The only difference is the addition of the Complete and Payment buttons to submit the payment. When the “Enable order completion” option is marked in the Call center channel, these option will become available on the Sales Order.

Call Center does add a feature called “Order credit” to the Sales order form. Using this button, you can perform standalone credits to the customer from the Invoiced order (it must have at least 1 invoiced line) without having to return an item or create a credit note. You would just simply enter the amount of the credit with a reason code and post it. The 2 biggest drawbacks to utilizing this workflow is that this credit will not be directly associated to the sales order, and that the posting will only affect the Customer Account offset by the Offset account listed for the Journal specified in the Call center parameters. It is strongly recommended to test this workflow to ensure it meets your posting needs prior to use.

• Refunding Misc using Order credit.
  
  • On the original sales order after invoicing part or all of the order, click Order credit in the Sales order menu tab.
  • Enter the amount of the credit with a Reason code, click OK to process the refund the credit card.
    • If Credit type defaults to Account credit, uncheck the option at the bottom for Credit to account.
    • This option can be changed in the Call center parameters in the Payment section.
• Refunding only Taxes/Charges.
  
  • On the original sales order after invoicing part or all of the order, click Order credit in the Sales order menu tab.
  • Enter the amount of the credit.
  • Select a Reason code for Charge Refund or Tax Refund.
  • Click OK to process the refund to the credit card.

EPOS/MPOS:

The credit card functionality in POS is dependent on the previous sale. In order to process a refund to a credit card, you can either use the Return Transaction or Return Product function. The main difference in this functionality is that the Return Product doesn’t care about the customer and will use the current discounts and offers, whereas the Return Transaction uses all of the original information from the recalled transaction. When dealing with a lot of discounts and returns, it is recommended to utilize Return Transaction.

• Return Transaction requires a receipt and can use any credit card for refunding the payment. If you would like to use the same card, this would be a process of the cashier verifying the last 4 digits of the card number on the receipt with the card being used for the return.
• Return Product can return any item and use any credit card for refunding the payment.

Here are a few scenarios and suggested solution based on the Return Transaction functionality:

• How to refund the original Full amount (Net amount, Charges and Taxes)
  
  • Use the Return Transaction function to recall the original transaction (either from a customer receipt or Show journal).
    
  • Select all items for return
  • Perform all entities will be included in refund
    
  • Swipe the Credit card via hardware or click Credit card to manually enter the card info to process the refund.
    
• Refunding only certain items from the original transaction.
  
  • Use the Return Transaction function to recall the original transaction (either from a customer receipt or Show journal).
    
  • Select only the items needing an adjustment.
  • Swipe the Credit card via hardware or click Credit card to manually enter the card info to process the refund.
    
• Refunding a partial amount of an item from the original net amount (price adjustment).
  
  • In this scenario, you are looking to refund the customer an amount of the sale, not an actual item or any of the charges or taxes. There are two ways to accomplish this, either add a non-inventory item to the sale for a courtesy credit, or return and resell the item at the correct price.
  • Use the Return Transaction function to recall the original transaction (either from a customer receipt or Show journal).
    
  • Select only the items needing an adjustment.
  • Two options:
    • Return the item with the full original amount and then resell the item at the correct price. (recommended)
    • Add a non-inventory item (Price Adjustment) that will need to be used to perform the refund.
  • Swipe the Credit card via hardware or click Credit card to manually enter the card info to process the refund.
    
• Refunding Misc credits.
  
  • You cannot refund charges, taxes, or fees directly. The best way to perform this is to add a non-inventory item to the sale for the credit.
  • Click Return Product
  • Add a non-inventory item (Misc Credit) that will need to be used to perform the refund with a prompt to enter a dollar amount.
  • Swipe the Credit card via hardware or click the Credit card tender to manually enter the card info to process the refund.
    

The post Sales order refunds for credit card payments appeared first on Microsoft Dynamics 365 Blog.

We are continuing to see a reoccurrence of very similar error messages when using Dynamics Online Payment Services (DOPS) with Microsoft Dynamics AX 2009 and 2012. The resolutions normally deal with the setup and configuration of either AX or DOPS. This blog is intended to cover some of the common errors encountered with the resolutions that we have been providing when configuring or using DOPS. The list of errors below can occur in Accounts Receivable and/or Retail. If you are experiencing a different error or the resolution did not resolve your issue, follow the steps at the end of this blog to create a new case with the AX support team.

AX 2009 CU7-CU8 – “The credit card feature is not installed.”
Cause: There were two updates to enable credit card processing in AX 2009 CU7 & CU8.
Resolution: Install the two fixes from KB 979304 (located by searching PartnerSource only).

The authorization could not be completed.

• Error code: InvalidExpirationDate – Error message: Invalid Argument: ExpirationDate
  

  Cause: Check Expiration Date is not marked
  Resolution: Go to: AX >> Retail >> Retail Channels >> Retail Stores >> select a store >> Set up menu >> Payment Methods. Select the credit card payment method. Click Card Setup. For each card type, checkmark the Check expiration date option.

• Error code: Value cannot be null – Parameter name: name – Error message:
  

  Cause: The incorrect EFT Service was selected, normally experienced in AX 2012 R1 as the “Dynamics Online” service is no longer used. This is option is removed in R2.
  Resolution: Go to: AX >> Retail >> Setup >> POS >> Profiles >> Hardware profiles. Select the hardware profile. Expand the EFT Service fast tab. In the EFT Service field, select Payment Connector and select Dynamisc Payment Connector in the next field. Complete the rest of the form.

• Error code: CommunicationError – Error message: There was an error communicating with the payment provider. Please retry your request.
  

  Cause: The customer’s Payment Provider Profile information was entered incorrectly in the activation profile in Dynamics Online. The profile information is not viewable in Dynamics Online.
  Resolution: Disable the payment service in the Dynamics Online customer portal. Have the Partner activate the payment service again in the Dynamics Online partner portal with the correct information.

Error code 1100 – Error message: Cannot authenticate with the provided credentials
Cause: Issue is in the authenticating of the Microsoft account (Live ID), password, and/or public key.
Resolution: Go to: AX >> Retail >> Setup >> POS >> Profiles >> Hardware profiles. Select the hardware profile. Expand the EFT Service fasttab. Delete and enter in the Microsoft account (Live ID) and password again.

Resolution 1: Go to the following blog to check user credentials:
http://blogs.msdn.com/b/axsupport/archive/2013/03/06/dynamics-online-user-roles.aspx

Resolution 2: AX 2012 R2 introduces the use of a public key – Use the following blogs to assign the public key to a system user in Dynamics Online.
Retail – Step 15 – http://blogs.msdn.com/b/axsupport/archive/2013/10/22/ax-2012-r2-for-retail-configuring-the-eft-service-in-the-retail-hardware-profile-with-dynamics-online-payment-services.aspx
AR – Step 12 – http://blogs.msdn.com/b/axsupport/archive/2013/10/03/ax-2012-r2-connecting-a-dynamics-online-payment-service-to-ax-accounts-receivable.aspx

Error code 1100 – Error message: Payment provider has not been set up.
Cause 1: You are not running POS in TestMode. Running N-job can overwrite this if you have already set the EFTTESTMODE = 1 at the POS.
Resolution: Use the blog below to set the POS EFTTESTMODE = 1
Step 30 – http://blogs.msdn.com/b/axsupport/archive/2013/10/09/ax-2012-r2-for-retail-configuring-pos-for-test-mode-with-dynamics-online-payment-service.aspx?wa=wsignin1.0

Cause 2: You created a production Payment Service but haven’t signed up for a Payment Provider yet
Resolution: Log into your payment service at https://www.dynamicsonline.com/CustomerPortal.aspx and under the Payment Providers section, sign up for a payment provider account.

Error code 21073 – Error message: There is no active payment provider for the specified payment type
Cause 1: The Payment Service hasn’t been activated by the Partner
Resolution: Have the Partner log into https://www.dynamicsonline.com/PartnerPortal.aspx and activate the payment service. For a walk through, view the video at:
Provisioning Microsoft Dynamics Online Payment Services
https://www.youtube.com/watch?v=7pOs48Mh4FI&feature=youtu.be

Cause 2: Using a production payment service with no active payment provider while POS is set to test mode
Resolution: You should be using a ServiceID from a “demo” Payment Service which doesn’t require (or allow) a payment provider. You can have both a demo and production payment service set up at once in Dynamics Online and then set up two different Retail hardware profiles for testing and for production.

Cause 3: While utilizing POS in test mode, you ran an N-1090 job that updated the hardware profile and set the POS hardware profile back to production mode.
Resolution: Use the blog below to set the POS EFTTESTMODE = 1
Step 30 – http://blogs.msdn.com/b/axsupport/archive/2013/10/09/ax-2012-r2-for-retail-configuring-pos-for-test-mode-with-dynamics-online-payment-service.aspx?wa=wsignin1.0

Error code 20002 – The Windows Live ID that you entered is not valid. Do you want to continue?
Cause 1: If encountered in the POS Retail Hardware profile
Resolution: Just click Yes to continue. This validation is not correctly performed. Test transactions to verify.
Side note: Ensure the public keys are properly copied and roles assigned to the system user

Cause 2: Corrupted hardware profile settings after an upgrade or database restore.
Resolution: Try creating a new AR payment service profile or Retail hardware profile. If in AX 2012 R2, this includes creating a new System User in Dynamics Online with proper public key and roles assigned.

Currency not supported by connector(20002)
Cause: In the Payment services window, the Supported currencies field, you cannot end with a semi-colon. For example, a value of CAD; will return the error but CAD by itself will validate. AX sees the semi-colon and then looks for another currency which is blank and handled by the code as a not supported currency.
Resolution: Remove the semicolon in the Supported currencies field from CAD; to display CAD

The payment service or payment account does not support currency USD or the payment account has not been configured.
Cause: The Method of Payment posting account does not have USD configured as the default currency.
Resolution: Drill back on the Method of payment used for credit cards, drill back on the configured Posting account, set the Currency to USD.

Error code 20976640 – Error message: Unable to resolve the service.
Cause 1: The System User in DOPS doesn’t have full rights to all
Resolution: Go to the following blog to check user and system user credentials:
http://blogs.msdn.com/b/axsupport/archive/2013/03/06/dynamics-online-user-roles.aspx

Cause 2: Incorrect service account ID entered
Resolution: Verify or reenter the Service Account ID from the Dynamics Online customer portal:
https://www.dynamicsonline.com/CustomerPortal.aspx

Cause 3: Firewall is blocking the payment service sites
Resolution: Check and add access to the following site that should return an XML coded page:
https://paymentservice.dynamicsonline.com/paymentwebservice.asmx?wsdl

CreatePaymentTransaction failed: 1022 = We encountered a problem. Please try again after some time. Contact Support if the problem persists.
Cause: Firewall is blocking the payment service sites
Resolution: Add the following sites to the Firewall:
https://paymentservice.dynamicsonline.com/paymentwebservice.asmx?wsdl
https://paymentservice.dynamics.com/dlpaymentservice.asmx

Error code 20119 – Error message: Invalid Argument: TenderAccountNumber
Cause 1: The card type is not set to the proper entity. The main issue here is that if you create a new Card Type, this field is blank with no drop-down options.
Resolution: Go to: Retail >> Setup >> Payment Methods >> Card types >> Card issuer >> this column should display “Credit provider” or “Debit provider” as this is required and verified through DOPS.

Cause 2: You may receive this error in AX 2012 R2 – Retail POS if you do not have EFTTESTMODE set to 1 and the EFTCONNECTORPROPERTIES field is not corrected by adding the IsTestMode PaymentProperty.
Resolution: Use the blog below to set the POS to test mode.
Start at step 30 – http://blogs.msdn.com/b/axsupport/archive/2013/10/09/ax-2012-r2-for-retail-configuring-pos-for-test-mode-with-dynamics-online-payment-service.aspx?wa=wsignin1.0

Error code 50000 –
Cause: This is a general error stating there is a credit card setup issue in AX
Resolution 1: Check expiration checkbox not checked.

Resolution 2: Go to: Retail >> Setup >> Payment Methods >> Card types >> set the Card Types column to International credit card/debit card

Resolution
3: Go to: Retail >> Setup >> Payment Methods >> Card Numbers >> The digits to verify should match the number of digits entered into the Card number from and Card number to fields.
Example: If Visa is set up with Card number from = 4, then the Digits to identify should be set to a 1 to verify just that 1 digit. If this is set to 4, then its expecting the Card number from to be something like 4000 and the Card number to be something like 4999.

Online services error 1100: Unmapped: 1100 Message: Authentication didn’t succeed with the given credentials. You must specify a certificate pfx data.
Cause: The customers Voice account is already linked with another organization in Dynamics Online
Resolution: Locate and log into the correct organization in Dynamics Online.

Still having trouble?

If you’re still having trouble, you can get assistance in the following ways:

• Post your questions on the Microsoft Dynamics Community forum.
• Contact your partner.
• If you are enrolled in a support plan directly with Microsoft, enter a new support request with Microsoft Dynamics Technical Support.

Getting Help from Technical Support

If you need to file a request for help setting up or using Payment Services, use the following steps to contact Microsoft Technical Support.

1. If you are a Partner
   1. Sign in to PartnerSource.
   2. In the navigation bar, click Support.
   3. Click Get Help Now by Creating a Support Request.

   -OR-
   

2. If you are a Customer:
   1. Sign in to CustomerSource.
   2. Click Log a Support Incident.
3. In the Regarding which customer? field, select the company the request is for, and then click Next.
4. Under New Support Incident, click the name of the product that you want to use Payment Services with, such as Microsoft Dynamics AX Business Value (2012).
5. In the Support Topic list, select Company-Wide Features (GAB, Workflow, Number Sequences, and so on).
6. In the Sub-topic list, select Dynamics Online (site, commerce, and credit card, and then click Next.
7. Review details for accuracy in the Contact information, Support contract information, and Product information areas and make any necessary updates.
8. In the Please tell us about your problem area, provide our support team with details about the issue you are having.
9. Click Submit.

The post Dynamics Online Payment Services – Common errors and troubleshooting steps appeared first on Microsoft Dynamics 365 Blog.

This is a quick article to let you know that when configuring AX and Retail you will need to use Retail Initialize function in all companies that will be using Retail.  The location of the Initialize button is in Retail >> Setup >> Parameters >> Retail parameters >> in the menu bar, click Initialize.

When Initialize is ran for the first time, it will create the Retail tables, jobs, forms, etc. Running Initialize a second time will attempt to create these same entities.  Since they already exists, you will be presented with an Infolog with errors stating that they already exists and it is unable to create them.  The big catch here is that running the Initialize also marks the SYSTEMINUSE flag for that company in the RETAILPARAMETERS table.  If you do not run the Initialize in additional companies, most of the Retail functionality will work but there are a few checks here and there that will cause issues. 

In one such instance, posting a Retail Statement will process successfully, but there will not be any records in the RetailCustInvoiceJourTable table as a check is made for the SYSTEMINUSE flag on whether it needs to copy the CustInvoiceJourTable to the RetailCustInvoiceJourTable.  This can be correct after the fact by re-running the job to copy the contents, but it is best to avoid this scenario.

We are looking to create additional checks to prevent the initial creation of things such as the Retail store, registers, etc. in a company that hasn’t been initialized yet.  Until a fix is released to perform these checks, please ensure that you have Initialized any company that will be utilizing Retail.

The post Ensure to use the Retail Initialize in all AX companies configured with Retail appeared first on Microsoft Dynamics 365 Blog.