Add Support for Online Store Product tags

[asirota]

Online Store Product tags were not available via API. They appear to be available in the most recent API updates. This will need to be improved in the next WAQM release.

[thelontx]

Scoping of modules/api calls/techniques to support Online Store mapping to different QBO products/classes/accounts:

QBWA is an "invoice first" solution. As each Invoice is read from WA, its details are used to derive the needed mappings for QBWA.

For OnlineStore invoices, the line item description uses the Product name. This line item description can be used to derive the Product Name.
NOTES:

• The Invoice details DO NOT provide the Online Store Product directly.
• The Invoice details DO NOT provide the Online Store Order number either. (FYI... The Order does list the invoice ID and Product name, but not the product tag)

Example: Product with a Variant
Product Name = Member Shirt
Product Variant = Shirt size --> values = [S,M,L,XL]

Example invoice for a Product with Variant:
This example is for an Order for 2x t-shirts where both are of size M.
Invoice Line item details: "Member Shirt (M) x 2"

Example: Product without a Variant
Product Name = Member Poster

Example invoice for a Product without a Variant:
This example is for an Order for 3x posters.
Invoice Line item details: "Member Poster x 3"

Once the Product Name is identified, an API call may be made to download ALL products. Once downloaded, QBWA can search the products for matching Product Names and then return the Matched Product Tag for the invoice.

Because of the architecture of QBWA, this search process is repeated for each Invoice. This is similar to the approach used to find Event tags.

Unlink events, each Event invoice will apply to a single event. An Online Store invoice may apply to multiple products added to the cart before checkout. So, each line item must be mapped separately, similar to an extra cost field.

[thelontx]

Initial recommendation: Use "tag approach" and derive product tag from each invoice. (similar to event tags)

PRO for Product tag approach:

• simplified QBWA mapping - 1 mapping tag can be used for multiple products
• consistent with event tag approach (for QBWA training purposes)
• enforces more rigor for mapping - less likely to have unmapped Products - less risk of errors due to free text product names

CON for Product tag approach:

• additional search/api call and aggregation needed to query products and find matching product tag using the product title on the invoice; more operations consumed
• client must use Product Tags
• consistent with event tag approach - a product can have multiple tags, but only the first matched product tag is used for mapping

Alternate approach (not recommended): Directly use Product Name "free text" from the Invoice line item description for mapping.

PRO for Product name "free text" approach:

• fewer Make.com modules/calls; potentially fewer operations
• client does not need to use Product tags
• potentially more flexibility? (but also required more QBWA maintenance)

CON for Product name "free text" approach:

• every Product must be mapped inside QBWA separately
• more risk of errors due to "free text" product names
• less rigor - increased likelihood of client creating Products and forgetting to add to QBWA mapping

[thelontx]

Initial Design approach: (assuming tags used)

First portion of Core scenario is same. Identify as Online Store Invoice and specify DEFAULT Online Store mapping for the Invoice (from the Data Store mapping).

When iterating through Invoice line items, refactor to branch Online Store invoice lines separate from others. "Other" lines are still searched to look for ExtraCost matches. Use resulting Online Store tag match OR ExtraCost match to define the line item QBO mappings (for accounts, products, classes, etc.)

Primary effort/risks/challenges:

1. Ability to successfully parse line item description to find product name, even when special characters or extra lines are used.
2. Refactoring approach to limit extra operations used? use router, set variable, get variable modules? does this actually simplify and reduce operations? Alternate is to just "repeat" the technique serially to iterate/aggregate across products and find matches.
3. Can this refactor approach be used for existing Event invoice tag matching to further reduce operations? (not technically a part of this feature request - is added scope)
4. Any implications for taxes? I think these are handled already, but may need to verify?
5. Update Mapping Guide to show/clarify expected tag matching for Products