We have an ERP integration which has data sovereignty. All changes are made through the ERP.
The problem now is that orders go to the mail of the main account and not to that of the contact who placed the order.
The ERP only has a logic of customer accounts with contacts, but no email address for the main contact. So we had to create fake email addresses. Also, the ERP has no authorization logic. Meaning there is no admin or anything like that. So we can't just take the first user for example, because this could also be deactivated.
So I do know, that this how B2B Suite is designed, but it doesn't fit our needs.
What's the best way now to send the email to the account of the ordering contact, or at least a copy?
The B2B-Suite currently always assigns the order to the customer account. However, the information about which contact placed the order is stored in the b2b tables.
I would suggest that to follow this guide Add data to mails.
With the order-data, you could load the B2B-order-context and the Contact-Information and replace the recipients with the correct email.
Useful services would be:
Shopware\B2B\Order\FrameworkOrderContextRepository::fetchOneOrderContextByReferencedOrderId()
Shopware\B2B\StoreFrontAuthentication\Framework\StoreFrontAuthenticationRepository::fetchAuthenticationById()
Shopware\B2B\StoreFrontAuthentication\Framework\IdentityChainIdentityLoader::fetchIdentityByAuthentication()
Related
So I am thinking of moving my current eCommerce System to Shopify and I wanted to evaluate, if certain functions are available. I am selling software/digital goods, that do have internal protection utilizing a licensing snippet (verifying a serial code). So regarding the most common use-flows, I wanted to check, if the following two things are configurable and of course how to do that:
1.) Guest Purchase with external license & serial creation:
User makes a purchase that is confirmed and processed
Shopify calls an external service for license & serial creation (with users email as unique id)
External service creates user, license and serial & sends back serial code
Shopify sends out the purchase confirmation mail with order detail & serial code
2.) User: change of email
Shopify user will try an email address update
Shopify will send the update to external service to update external database
I understand, that parts of this are doable with WebHooks, but I understand hooks to be uni-directional and async - so I could not intercept the sending of a purchase confirmation mail to enrich it's content beforehand (e.g. with a serial). Is that correct?
Any help is very much appreciated. Thanks in advance!
It is most definitely possible. All you have to do is installl third party shopify apps. There are many of them and you can definitely find some of them to meet both you're needs.
You can get more info at the shopify website.
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
I already have a free user account into cloudbees.
Now I need to setup the account of my approved FOSS project. I couldn't use my personal email for this. This means that I need to create an specific email for the open source project?
We (cloudbees) also can convert your FREE account to FOSS if you wish. please then reply to your approval email asking for the conversion
Many email providers (such as Google) will deliver email to an account if the address includes the account name followed by some delimiter and some arbitrary characters.
So if your email address is foo#gmail.com, you will receive mail from foo+1#gmail.com, foo+abc#gmail.com, etc. In this way, you can create multiple unique accounts on CloudBees which all map to a single email inbox.
http://lifehacker.com/144397/instant-disposable-gmail-addresses
This probably works on all the other webmail providers, but that's a guess.
I have a client who wants his custom-written CRM to be able to access his sales people's emails so that, effectively, a history of email conversations between customer and salesperson is stored inside the CRM's database.
The CRM is written in Visual Basic 2008 and the database is SQL Server 2008. The only email these people use, in the shop and on the road, is Gmail. Each sales person has their own Gmail address. That's how they operate.
If they're on the road and respond to a customer's email inquiry about a product, they would like that email conversation to be stored in a table in the database. I think that's the part I can't wrap my head around. How do I get access to the email data (knowing the user id and password) and doing so from Visual Basic 2008?
A free or close to free solution would be preferred.
One thing that we have done in the past is create a separate email account and just have the users to BCC this email address, for example, crm#somewhere.com. We then have a small application, on the server, that polls email from this central mailbox and automatically attaches it to the entity based on the recipients email address.
We also allow the user to add some commands at the bottom of the email, for attaching to things like work orders and/or bills, for example, wo 1000 (for a work order 1000) or b 1000 (for bill 1000).
Just another idea.
How have people intergrated custom CRM type applications with email?
I have a Access 2003 front-end application with a SQL Server 2005 backend. One CRM
part of the application tracks the activity with the customer in a traffic
log table. Sometimes the salesstaff has communication with their customer
using email instead. What do people do to synch this up with an application?
I was thinking about creating a form to enter the initial message, so I
could save it into a table and then have the system generate a email, of
course, this doesn't handle the email communication after the initial email.
Thanks
What you need to do is setup your domain name with a free google apps account. Your sales staff can still use the clients of their choice, but since they are essentially using custom gmail accounts, every single email that they send and receive will be recorded in a nice and neat transactional format in the gmail interface. Since your sales staff is always online, they will always have access to every message they ever sent. If you want to have access to the emails, you can set it up that every single message that gets sent are automatically blind forwarded to your account. Filters can be set up to automatically tag and archive them, so you will not be overwhelmed, but you will still be able to search them. Google Apps will also give you a central contact directory similar to outlook/exchange.
Here are a few options for you:
Use web forms for all communications. When a message is sent out, the only thing it includes is a link back to the site. Responses are sent the same way.
Setup an email alias that your sales staff Cc's when they want their correspondence to be tracked. Your app would periodically read a POP mailbox, and record the traffic. Customers would have to remember to Cc the same email box for the traffic to be remembered.
Establish a single common email box, such as sales#domain.com. All outgoing mail is marked as being from that account, so all replies will go through it. To send mail, sales staff uses a web form. Messages are tagged with a key that associates them with a particular customer. Putting the key in the subject header usually works OK (that's how many support ticket management systems work, for example). Replies from customers keep the tag. Your app then reads an associated POP mailbox, parses out the keys, and stores the email accordingly.