Fixes for W-9208977, W-9133292, W-9280951.

Corrects error message in synchronous checkout flow.
Adds comments to the readme and PaymentController class to describe how
to go about debugging.
Adds improved context message for payment method for specifying what
payment option to display first.

Author: dan-zak

examples/checkout-sync/flows/Summer_2021_B2B_Checkout.flow

@@ -1403,7 +1403,7 @@ There's more smarts that could be here by adding other outcomes of the stat
         <inputAssignments>
             <name>ErrorMessage</name>
             <value>
-                <stringValue>Looks like you don&apos;t have an active CartCheckoutSession. Do you have a checkout running in another tab?</stringValue>
+                <stringValue>Checkout was modified outside of this session. Please exit this checkout and start a new checkout or return to the concurrent checkout.</stringValue>
             </value>
         </inputAssignments>
         <storeOutputAutomatically>true</storeOutputAutomatically>

examples/lwc/README.md

@@ -61,3 +61,13 @@ Connect APIs for search don't have Apex enabled yet. So we can call those Connec
 * To call third-party APIs from your component’s JavaScript, add the API endpoint as a CSP Trusted Site.
 * To call Salesforce APIs, make the API calls from your component’s Apex controller. Use a named credential to authenticate to Salesforce. (Documentation is [here](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/apex_api_calls.htm) and [here](https://developer.salesforce.com/docs/atlas.en-us.228.0.apexcode.meta/apexcode/apex_callouts_named_credentials.htm).)
 * Create a Named Credential callout. The steps are documented [here](/examples/lwc/docs/NamedCredentials.md).
+
+## Known Issues
+
+### Flow Debugging
+
+Debugging with the flow typically requires impersonating a buyer [Run flow as another user](https://help.salesforce.com/articleView?id=release-notes.rn_ls_debug_flow_as_another_user.htm&type=5&release=232). However, the custom payment component installed as a part of this installation will be run as the user that is debugging, and not the buyer. This typically causes some malfunctioning behavior like missing billing addresses. There are a few workarounds.
+
+1. Don't debug and instead run as the buyer within the store relying on errors sent to the email specified in `Process Automation Settings` to find problems.
+1. If you know the buyer's account you can make a change in [B2BPaymentController.cls](force-app/main/default/classes/B2BPaymentController.cls). Directions are specified near the top of `getPaymentInfo()`.
+1. You can also make a change in the `getUserAccountInfo()` method in [B2BUtils.cls](force-app/main/default/classes/B2BUtils.cls). Here you would put the ID of the user instead of the call to `UserInfo.getUserId();`. This was not documented within the class as the effects would be farther reaching than in B2BPaymentController.cls.

examples/lwc/force-app/main/default/classes/B2BPaymentController.cls

@@ -7,6 +7,17 @@ public with sharing class B2BPaymentController {
         // Get the effectiveAccountId
         String accountId = B2BUtils.getUserAccountID();
 
+        /////////////////////////////////////////////////////////////////////////////////////
+        // When debugging within the flow, calls to this controller cannot be impersonated,
+        // meaning the buyer won't be used. Therefore, the getUserAccountID() will not return
+        // correctly. For debugging purposes, one can temporarily specify the account ID of
+        // the buyer under test to get around this limitation. This will impact any user
+        // trying to use this method, so this is only suggested on non-production orgs.
+        // 
+        // Example:
+        // String accountId = '001xx000003GZBjAAO';
+        /////////////////////////////////////////////////////////////////////////////////////
+        
         // Get the 'purchaseOrderNumber' from the WebCart
         WebCart webCart = [SELECT Id, BillingAddress, PoNumber FROM WebCart WHERE Id=:cartId
                            WITH SECURITY_ENFORCED];

examples/lwc/force-app/main/default/lwc/paymentMethod/paymentMethod.js-meta.xml

@@ -11,7 +11,7 @@
             <property name="hidePurchaseOrder" label="Hide Purchase Order" type="Boolean" description="" default="false" role="inputOnly" />
             <property name="hideCreditCard" label="Hide Credit Card" type="Boolean" description="" default="false" role="inputOnly" />
             <property name="poRequired" label="Require Purchase Order Number" type="Boolean" description="" default="false" role="inputOnly"/>
-            <property name="selectedPaymentType" label="Selected Payment Type" type="String" description="The selected payment type" role="inputOnly" />
+            <property name="selectedPaymentType" label="Selected Payment Type" type="String" description="The selected payment type (PurchaseOrderNumber, CardPayment)" role="inputOnly" />
             <!-- These are the internal billingAddressSelector cmp -->
             <property name="hideBillingAddress" label="Hide Billing Address" type="Boolean" description="" default="false" role="inputOnly"/>
             <property name="billingAddressRequired" label="Require Billing Address" type="Boolean" description="" default="false" role="inputOnly"/>

sfdx/README.md

@@ -135,3 +135,13 @@ Deploy your changes to production using [packaging](https://developer.salesforce
 ## More Information about what is installed
 
 Once installed, you should be able actually take a cart through checkout as a buyer user. However, while the flow of the checkout functions, much of the important work is mocked. To see what was installed so you can determine what to update, you should go to the Examples directory and then navigate into the directories you care about. For instance, the *framework* directory contains all of the flows that control the flow of the checkout. The *integrations* directory is where you'll find Apex classes that can be updated to hook up to real systems to determine shipping and taxes.
+
+## Known Issues
+
+### Flow Debugging
+
+Debugging with the flow typically requires impersonating a buyer [Run flow as another user](https://help.salesforce.com/articleView?id=release-notes.rn_ls_debug_flow_as_another_user.htm&type=5&release=232). However, the custom payment component installed as a part of this installation will be run as the user that is debugging, and not the buyer. This typically causes some malfunctioning behavior like missing billing addresses. There are a few workarounds.
+
+1. Don't debug and instead run as the buyer within the store relying on errors sent to the email specified in `Process Automation Settings` to find problems.
+1. If you know the buyer's account you can make a change in [B2BPaymentController.cls](../examples/lwc/force-app/main/default/classes/B2BPaymentController.cls). Directions are specified near the top of `getPaymentInfo()`.
+1. You can also make a change in the `getUserAccountInfo()` method in [B2BUtils.cls](../examples/lwc/force-app/main/default/classes/B2BUtils.cls). Here you would put the ID of the user instead of the call to `UserInfo.getUserId();`. This was not documented within the class as the effects would be farther reaching than in B2BPaymentController.cls.