QR Codes: Compatibility With 3rd Party Inventory Management Systems?

Hi Bubblers!

A QR code conundrum for anyone interested in weighing in.

Backstory

In the absence of a bubble template, I began building a Cashback Mobile App using a nifty mobile template Mobile UI Starter Pack created by @d9999 (thank you for the building blocks kind sir!).

In tandem, I have also been building an associated Cashback Web App (that I need to link to the mobile app somehow - currently two separate app projects - eek!).

The Web App platform offers greater functionality in that it enables my clients (Partners) to create dynamic shop fronts and advertise their cashback deals (Products) from uploaded product data. It also allows customers (Users) to create dynamic user profiles, where they can explore Partner deals, track their cashback accruals and recent purchase history etc.

The Mobile App is exclusively user-facing and is really just for scanning QR codes on receipts in-store and displaying simple cashback and product data at a glance. For the in depth analysis, the Mobile App would redirect users to the Web App.

Iā€™ll explain the User journey for the QR Code Scanning and then the problems that have arisen. Hopefully some of you wise and talented people might have some ideas about how to attack this one!

1 - User visits the Partner store in person. They do their shopping. They open the Mob App at the checkout.
2- They pay for their shopping and are presented with a receipt that displays a QR code. They open the Scan Page and click the ā€œScanā€ button, activating their phoneā€™s camera. They scan the code. (NB: I am not using a dedicated scanner plugin for this, just the deviceā€™s native camera).
3- A successful scan redirects the User to a dynamic landing page (yet to be built), that will populate with the data extracted from the QR code. Purchased products that match the Product IDā€™s uploaded by the Partner on the Web App will be displayed, along with associated cashback rates and amounts accrued.
4- User taps a button to accept cashback terms, triggering a return to the home screen where they can now see their cashback info displayed. The original QR code (or access to cashback landing page) would also be rendered closed, thereby avoiding fraudulent cashback logging from an already scanned receipt.


Problem #1 - Partners will need to generate a QR Code for each Userā€™s unique shopping basket. They will have to do this at checkout. Each QR code generated is obviously going to be different with each unique shopping basket. Also, it may include both cashback product data and non-cashback product data that the Mobile App needs to be able to differentiate between.

Q: How might I enable retail Partners to generate compatible QR codes at checkout, relative to not just each Userā€™s unique shopping basket but also my backend database? Would the Partnerā€™s inventory management software need to create it? Would my Web App need to create it and be connected to their inventory management software through an API? If yes, is there an API that is recommended here or will it be contingent on the specific inventory software used?


Problem #2 - For the scanning itself, the camera seems to work fine on my iPhone 11 (iOS 15.0.2) when accessing the Mob App in the Google Chrome browser. I have read in other posts that some people have had issues getting this feature to work once launching native app versions.

Q: Is this a problem I should prepare for by building in a QR code scanner plugin from the get-go, rather than simply opening a smartphoneā€™s native camera (which seems way easier)? Would this be the failsafe to allow other, perhaps older devices to access the scanning feature?


Problem #3 - In case you hadnā€™t already guessed, I am a Bubble Noob. It has taken me some time to get to this stage, since Iā€™ve been trying to learn on the job!

So if anyone has any thoughts/solutions to some of the aforementioned, please feel free to phrase these as if speaking to a small child :smiley: There shall be no offence taken, I can assure you!

Cheers everyone!

Ben from Treea

1 Like

Check out this plugin Colour QR Code Generator Plugin | Bubble

Thereā€™s a QR code scanner one too

QR codes are basically visual representations of a URL. You can build whatever parameters you need in to a URL and then access those parameters to use as constraints in data sources and or conditionals.

For instance you could have the QR code generated read to a URL www.yoursite.com/yourpage?cart=[unique ID of the cart in your database]

From this your data source on that page would be ā€˜get data from URLā€™ and then enter cart as the key and choose the shopping cart data type as the type. This would then let the app know which cart is related to that QR code.

If you have the right links in your database to the cashbacks associated with that cart you would then be able to access those from that same data source.

1 Like

check out https://thebdk.com/ - they have some native scanning features.
image

1 Like

Thanks for this Natasha, what a great response!

The workflow you detailed makes a lot of sense and I will definetely build this in.

Do you have any ideas about how I might inform the landing page (and indeed a QR code on a physical receipt) of the product data purchased in a live, in-store scenario, as opposed to through an online transaction?

I can see how it would work with an online shopping cart, however my initial test will be conducted in person, within a physical store.

The limitation I see is that the only product data available is going to be that which is collected by the retailerā€™s inventory management system (IMS), as the productā€™s barcodes are physically scanned by a shopping assistant at the checkout. This would list the purchases made on a physical receipt, as well as displaying a QR code that could send the purchased product data off to populate the cashback landing page.

Short of needing to know the inventory management system in use (in the event of multiple clients using different systems), is there a simple work-around to obtain that source data needed to generate the correct QR code for this?

Or would it require an API that speaks to the specific IMS? Or even a unique, static QR code generated by the IMS that changes depending on the products purchased?

It would be great to make integration as simple as possible! Is there a work around that I am missing?

Thanks again Natasha!

Thank for this @d9999 !

Iā€™ll certainly have a look at BDKā€™s plugin - they definitely look like the best bet for a native integration!

Appreciate you weighing in :smiley:

1 Like

Iā€™m not sure how to get around this - how are you telling the IMS and/or printer what QR code to generate on the receipt?

ā€œstaticā€ means doesnā€™t change - a static QR code would be a singular URL. As you need a dynamic expression because the variables are the customer, the store and the products, static would not be a solution here.

Also - you donā€™t need a mobile app and a web app as separate projects. You build the one app in bubble as a responsive app and if you need to you wrap it to put it on the app stores.

1 Like

Why reserve separate QR for uniq tuple {sku, storeID, custID} ?

Why not associate sku/storeID&&startDate thru EndDate as an instance of a Promo-Item on which, during checkout , you have during checkout , a Customer-PromoItem-claim.

On the claim, you ref a discount ( sku/store/Dates ) , you create a discount instance and store it on that cust.

A single QR represents that sku-promo in that store for the duration of the promo event all customers buying at that location would have claimed the same instance of the sku/promo/store when on checkout.

1 Like

This is exactly the question Iā€™m looking to find out! Trying to think of the workflow required for this :exploding_head:

Thanks for correcting me on static QRā€¦ As you say, a dynamic expression is what I would be looking for. Just canā€™t for the life of me figure out how to inform the IMS/printer of the data for the QR code generation!

Regarding the separate app projects, I totally agree with you. The only reason for having two is simply that I purchased a template mobile app after having begun the desktop platform build (which consequently is also being responsively designed for mobile compatibility also).

The mobile app is just for scanning and viewing basic cashback analytics and deals.

I think I can link the two anyway via the Bubble App Connector plugin if Iā€™m not mistakenā€¦

Thanks for all your help and feedback :slight_smile:

Hey Rob,

Thanks for this idea - something like this could definitely work I think.

This would be the process that differentiates each customerā€™s unique claim depending on the products purchased?

Iā€™d love to try and build this but Iā€™m a bit unsure of how to start.

Do you have an example workflow that would work?

Thanks for your help!

i dont have bubble samples. i alluded to generic end state that results from ERD of entities & process ( normal checkout on a specific SKU vs. checkout flow on same sku with DISCOUNT applied ) .

tldr:

Retail mgmt involves promo events composed of item-discounts

  • promo events :: date windows
  • promo events :: items
  • promo-item :: discount amount

during a promo, a skuā€™s discount amount is CONSTANT and in a mobile app can be suitable represented by one-and-only-one QR. during the event , many customers , controlling their own shop-cart process, can use this QR to build items in a cart , leading to checkout event.

At checkout, any reduced skuā€™s could be referenced via:

  • promo-event.item OR
  • item.discount amount

above in accordance with Stripe API approachs using ( item, price, discount ) for example

And for attribution to the promo and/or repts. ledger on checkout, you capture:

  • promo:item:sold ($amount , units)

this helps measure retailing success

If your approach to design has a DB step accomodating some thought on entitiy- relations , then u may be able to rework the approach.

But it is OK to simply build it , release it and iterate on it without over-thinking the DB. My gut reaction to a process involving creation, state, DB track of QR at the lower level ( sku.custID ) just seemed like overkill.

1 Like

You couldnā€™t do this unless you built custom integrations with each third party - which you said you wanted to avoid.

But you canā€™t get a third party system to generate something compatible with your own system without building a way for each system to talk to each other.

Robā€™s idea would work if you are only doing set promotions - however if you need more variables to calculate cashbacks and promotions and you donā€™t want to build the front end POS then youā€™ll have to integrate with third party POS

1 Like

Thanks so much for this Rob. I really appreciate the detail!

I think this approach will be suitable for a first test with a fixed rate of cashback captured in the way you describe. Will do my best to figure it out with the shopā€™s devs.

Cheers!

Thanks Natasha!

Yup totally agree with you. Not sure there is a work around save for diving in with a retailer directly and building the integration following a successful test using Robā€™s suggested structure.

I will get to it and again thank you ever so much for your contributions to this!

Great community here :grinning:

1 Like

Pleasure :slight_smile: