Wanted to see if this was remotely possible. But i have an import mapping setup that work in the following manner on the SALES ORDER entity in Commerce Connector:
As you can see this will look for the “MISC” tag and if it exists it will map the customerID to my “ECOMGUEST” customer. If FALSE, it maps to the C0000011 customer.
What I would LIKE to occur is that on the FALSE result of the IIF statement that it reverts to actually using the native connectors logic to either use the existing shopify customer or create a new one.
Possible?
Best answer by simonliang91
@simonliang91 any updates here? It has been two years since you mentioned a development plan. Thanks
We have implemented it in 2026R1 already, you can upgrade your instance to have this feature.
DefaultMapping: References the default field mapping defined for the connector. When the keyword is applied, the system follows the default behavior as though no manual mapping is configured. This keyword is especially useful when you want to preserve or conditionally apply the default behavior.
@kkeating24 , that’s the limitation I bump into all the time. I didn’t find a solution. It would be nice to have a special command for the default behavior. For example, add a DEFAULT keyword. Subscribing to this thread.
A particular scenario where this would be useful also seems to be to allow Shopify gift certificates to work in a multi-currency environment.
Since there is only one gift certificate item mapping per Shopify connector and the sales account mapped to that item needs to have a currency (for liability set-up and payment method mapping), a sales order will not import if a gift certificate order is received for a different currency (to the default sales account assigned to the non-stock item).
One way to resolve would be to check the currency of the incoming order and whether the item is a gift certificate. If so, change the sales account on the line to the relevant currency account - since the mapping takes effect for ALL incoming sales orders a way is needed of only applying the logic if the item is a gift certificate - otherwise just follow the default process (in this case just use the existing sales account on the stock item).
A particular scenario where this would be useful also seems to be to allow Shopify gift certificates to work in a multi-currency environment.
Since there is only one gift certificate item mapping per Shopify connector and the sales account mapped to that item needs to have a currency (for liability set-up and payment method mapping), a sales order will not import if a gift certificate order is received for a different currency (to the default sales account assigned to the non-stock item).
One way to resolve would be to check the currency of the incoming order and whether the item is a gift certificate. If so, change the sales account on the line to the relevant currency account - since the mapping takes effect for ALL incoming sales orders a way is needed of only applying the logic if the item is a gift certificate - otherwise just follow the default process (in this case just use the existing sales account on the stock item).
wouldn’t this work with an IIF statement? You could say “if” the currency is x and the item is a gift certificate than accountB. The false statement refers back to the default AccountB. It should still process the rest of the sales order lines accordingly.
Unfortunately there are more than just two sales accounts across all the stock/non-stock items in the business. I wouldn’t want to have to create an IIF statement with a branch for every different occurrence of a sales account / stock item (since the import mappings apply to ALL imported sales orders). I’m not sure we’d know which sales account to map either just from the incoming Shopify data (since you can’t use Acumatica fields in this logic) - this is why it would be nice to have a fall-through outcome where you could define the branches of logic you did want to cater for, and then fall through to default logic (ie whatever the sales account is on the stock/non-stock item).
Just to re-iterate you can’t seem to use any local Acumatica fields in the “External Field / Value” (probably for a good reason) but can’t therefore really do any more in-depth logic.
If you could have a magic string like “<<DEFAULT>>” as an outcome to a logic branch then that would be great, but not sure the way the mappers are structured would suit this.
For the moment we’ll have to deal with this in a customisation but it seems a real shame to have to reboot the application (and force users off the system) to fulfil the requirements.
DefaultMapping: References the default field mapping defined for the connector. When the keyword is applied, the system follows the default behavior as though no manual mapping is configured. This keyword is especially useful when you want to preserve or conditionally apply the default behavior.
