00:00:03.266 --> 00:00:05.146 Started the thing it's going.
00:00:05.356 --> 00:00:05.536 Yeah.
00:00:13.946 --> 00:00:15.166 And we're live.
00:00:16.746 --> 00:00:22.486 All right, let me move a bunch of stuff around.
00:00:24.876 --> 00:00:27.006 Get myself all set up and ready.
00:00:37.526 --> 00:00:39.496 Ah.
00:00:42.516 --> 00:00:42.936 OK.
00:00:46.796 --> 00:00:47.916 I'm just going to open up.
00:00:49.036 --> 00:00:50.016 Was that one brought out?
00:00:50.026 --> 00:00:50.436 Doesn't matter.
00:00:51.556 --> 00:00:53.186 Uh, rock.
00:00:53.816 --> 00:00:54.626 That's a good one.
00:00:55.266 --> 00:00:58.376 And then I'm gonna share my screen while it loads.
00:01:09.506 --> 00:01:14.206 Uh, OK, so check out sometimes.
00:01:15.256 --> 00:01:22.242 Sometimes checkout is complicated and so as we as many
00:01:22.242 --> 00:01:26.306 of us have probably run into it.
00:01:26.366 --> 00:01:31.420 Uh, it sometimes can be tough to get a specific customization
00:01:31.420 --> 00:01:35.006 implemented the way that a client wants it.
00:01:35.636 --> 00:01:41.426 UM, couple of recent examples from rock are gift cards as a
00:01:41.426 --> 00:01:46.926 payment method, which I think we still need to clean up.
00:01:46.936 --> 00:01:51.792 Some of that implementation to do it really correctly, but it's
00:01:51.792 --> 00:01:56.345 functional and also on rock was the ability to split out in
00:01:56.345 --> 00:02:00.898 store pickup items into their own order separate from other
00:02:00.898 --> 00:02:05.527 nothing to ship items that are for example purchasing a gift
00:02:05.527 --> 00:02:05.906 card.
00:02:06.866 --> 00:02:07.416 Umm.
00:02:07.786 --> 00:02:13.726 So umm on the on that note.
00:02:15.026 --> 00:02:19.024 Obviously, most of us here are familiar with target order
00:02:19.024 --> 00:02:23.297 checkout, but for posterity on the recording, in case this is
00:02:23.297 --> 00:02:27.777 being watched by somebody who's new and doesn't know what it is,
00:02:27.777 --> 00:02:30.396 target order checkout is the default.
00:02:30.976 --> 00:02:32.866 Uh, nowadays tingly.
00:02:32.876 --> 00:02:37.089 It's the only uh checkout mode that we have in CEF and it
00:02:37.089 --> 00:02:41.665 allows you to choose multiple destinations during checkout and
00:02:41.665 --> 00:02:45.660 ship different products in the same run of checkout to
00:02:45.660 --> 00:02:49.873 different destinations as well as splitting on additional
00:02:49.873 --> 00:02:54.231 properties on those products such as whether or not they're
00:02:54.231 --> 00:02:58.590 shippable, what store they're coming from, and other things
00:02:58.590 --> 00:02:59.316 like that.
00:02:59.486 --> 00:03:02.731 So it splits all those out into separate orders based on all
00:03:02.731 --> 00:03:03.476 that criteria.
00:03:03.786 --> 00:03:10.851 So that, umm uh, each each order more or less can go to the
00:03:10.851 --> 00:03:14.266 relevant person or place umm.
00:03:14.356 --> 00:03:18.556 So hopefully that all makes sense now.
00:03:19.856 --> 00:03:24.532 Uh, generally speaking, the target order code is extremely
00:03:24.532 --> 00:03:25.166 complex.
00:03:27.516 --> 00:03:34.541 So it's not usually very clear where to go if you wanna add
00:03:34.541 --> 00:03:41.566 additional logic for splitting E carts or splitting orders.
00:03:42.806 --> 00:03:47.626 Umm, so again the specific case we had on UM, close a bunch of
00:03:47.626 --> 00:03:49.386 stuff I have open here.
00:03:51.056 --> 00:03:59.686 The specific case we had on rock was splitting normal.
00:03:59.696 --> 00:04:00.946 Nothing to ship products.
00:04:02.366 --> 00:04:03.116 Umm.
00:04:05.166 --> 00:04:09.809 From products that were nothing to ship because they're in store
00:04:09.809 --> 00:04:10.666 pickup only.
00:04:11.706 --> 00:04:12.306 Umm.
00:04:13.286 --> 00:04:17.698 And so specifically what I wanted to talk about first and
00:04:17.698 --> 00:04:22.413 we'll get into other check out related customizations and and
00:04:22.413 --> 00:04:25.456 just checkout functionality in general.
00:04:25.946 --> 00:04:29.666 What the first thing I wanted to talk about was the uh target
00:04:29.666 --> 00:04:30.266 groupings.
00:04:31.156 --> 00:04:37.216 Umm, so it's pretty tough to find, but somewhere in here I'm
00:04:37.216 --> 00:04:38.806 just doing this.
00:04:40.756 --> 00:04:41.566 OK, here we go.
00:04:41.856 --> 00:04:46.286 So somewhere around the the lower middle of this file.
00:04:47.026 --> 00:04:47.726 Umm.
00:04:48.556 --> 00:04:51.116 It grabs up the E be.
00:04:52.446 --> 00:04:52.946 There we go.
00:04:53.176 --> 00:04:56.902 We iterate over the sales items in the original cart, so this is
00:04:56.902 --> 00:05:00.513 gonna be everything you actually added to your cart and then a
00:05:00.513 --> 00:05:03.952 little further down here, we iterate over those targets and
00:05:03.952 --> 00:05:06.016 we create this target grouping key.
00:05:06.386 --> 00:05:07.976 This is the.
00:05:08.026 --> 00:05:11.863 This is the thing that determines which carts or sorry
00:05:11.863 --> 00:05:15.700 which sales items and which products will go into each
00:05:15.700 --> 00:05:16.956 individual bucket.
00:05:16.966 --> 00:05:19.016 If you will umm.
00:05:19.526 --> 00:05:23.807 And you'll notice you'll notice that the targets have a custom
00:05:23.807 --> 00:05:24.486 split key.
00:05:25.656 --> 00:05:32.362 Umm, that custom split key is your way to add additional
00:05:32.362 --> 00:05:38.479 splits and it doesn't necessarily only allow you to
00:05:38.479 --> 00:05:42.126 split on one additional factor.
00:05:43.076 --> 00:05:47.288 Umm, as long as that string is deterministic, you can split on
00:05:47.288 --> 00:05:49.896 as many additional things as you want.
00:05:49.996 --> 00:05:55.890 So for example, I can't think of any good uh explanations off the
00:05:55.890 --> 00:05:57.676 top of my head, but.
00:05:56.226 --> 00:06:02.086 Uh, pick up only pipe color, red pipe.
00:05:59.786 --> 00:06:00.256 Yeah.
00:06:00.266 --> 00:06:04.416 Yeah, that's yeah, right.
00:06:02.156 --> 00:06:02.806 You know whatever.
00:06:02.816 --> 00:06:07.349 However you wanna build ever many facets or or factors into
00:06:05.306 --> 00:06:05.986 So ultimately.
00:06:07.349 --> 00:06:08.936 that string you want.
00:06:08.946 --> 00:06:11.777 As long as you make can make a consistent result, you could
00:06:11.777 --> 00:06:13.806 build the string to however much you need.
00:06:11.786 --> 00:06:12.276 Yeah.
00:06:12.386 --> 00:06:16.871 So as yeah, so basically if you wanted to make sure that all red
00:06:16.871 --> 00:06:21.217 products were split from non red products and all pick up only
00:06:21.217 --> 00:06:25.702 products were separated from non pick up only products then what
00:06:25.702 --> 00:06:29.910 you would want to do is do like target dot customs split key
00:06:29.910 --> 00:06:33.636 equals bread pipe pickup only and as long as that key
00:06:33.636 --> 00:06:37.362 generates in that order every time and you don't ever
00:06:37.362 --> 00:06:41.639 accidentally have one that gets assigned like uh pick up only
00:06:41.639 --> 00:06:46.124 pipe red because it's just using the string itself it's not it's
00:06:46.124 --> 00:06:50.539 not splitting on this pipe you can do a dash you can do a comma
00:06:50.539 --> 00:06:54.679 whatever it doesn't matter however you wanna format this as
00:06:54.679 --> 00:06:59.026 long as it's deterministic for the same for the same setup for
00:06:59.026 --> 00:07:03.303 the same information then you can have as many constraints on
00:07:03.303 --> 00:07:04.476 this as you want.
00:07:05.716 --> 00:07:11.029 In my testing, this seemed to be like the best place to put this
00:07:11.029 --> 00:07:13.236 because it creates the key.
00:07:14.016 --> 00:07:16.316 This is actually where these keys get created.
00:07:18.426 --> 00:07:21.404 There didn't seem to be really anywhere else in this file where
00:07:21.404 --> 00:07:22.846 those keys were being newed up.
00:07:23.726 --> 00:07:24.366 Umm.
00:07:24.446 --> 00:07:27.859 And so that makes it relatively nice that once you know this is
00:07:27.859 --> 00:07:31.219 here, you just if you need to add new splits, you can add them
00:07:31.219 --> 00:07:31.806 right here.
00:07:32.686 --> 00:07:37.198 Umm, so that will that will add those those additional splits to
00:07:37.198 --> 00:07:41.085 the the targets and then whenever it goes down here and
00:07:41.085 --> 00:07:44.625 actually creates the target carts for those target
00:07:44.625 --> 00:07:48.650 groupings, it'll create the actual sub carts and all that
00:07:48.650 --> 00:07:52.815 stuff and then once those and then again from there it will
00:07:52.815 --> 00:07:55.036 create sub orders automatically.
00:07:55.226 --> 00:07:58.016 So the primary thing I had to change here was this.
00:07:58.026 --> 00:08:00.850 There was other things I had to change for different reasons on
00:08:00.850 --> 00:08:03.631 this PR, but the primary thing to actually get these splitting
00:08:03.631 --> 00:08:05.396 logic to work was just this right here.
00:08:06.306 --> 00:08:15.097 Umm, so that's something that it doesn't come up super often, but
00:08:15.097 --> 00:08:20.026 when it does, it's pretty likely to.
00:08:20.716 --> 00:08:23.138 It seems like it will be much more complicated than it
00:08:23.138 --> 00:08:23.886 probably will be.
00:08:24.526 --> 00:08:27.556 Uh, and that's that's always been my.
00:08:29.906 --> 00:08:32.968 My fear with it and my experience with it is that I I
00:08:32.968 --> 00:08:36.426 always assume that this is going to be a lot more difficult.
00:08:37.066 --> 00:08:42.009 Umm, but now that I know where to go in here specifically and
00:08:42.009 --> 00:08:46.952 I've seen it work, I know that it's actually really not not a
00:08:46.952 --> 00:08:48.866 difficult customization.
00:08:48.876 --> 00:08:51.149 It's just difficult to know where to put it, so hopefully
00:08:51.149 --> 00:08:52.716 now everyone will know where to put it.
00:08:53.556 --> 00:08:57.378 Umm, so honestly easy way to find this is if you just search
00:08:57.378 --> 00:09:01.075 new hargate grouping key and again you'll see that that is
00:09:01.075 --> 00:09:04.646 the only place in this file that those keys are created.
00:09:04.776 --> 00:09:06.947 So you don't to worry about adding this logic in two
00:09:06.947 --> 00:09:08.586 different places or anything like that.
00:09:08.676 --> 00:09:13.255 Just right here and then setting target target dot custom split
00:09:13.255 --> 00:09:17.190 key before it creates this target grouping key and you
00:09:17.190 --> 00:09:17.906 should be.
00:09:18.536 --> 00:09:19.296 You should be golden.
00:09:20.666 --> 00:09:26.236 Umm, so yeah, that's that's one of the things that uh, I
00:09:26.236 --> 00:09:28.386 recently recently did.
00:09:28.396 --> 00:09:32.579 And uh, it definitely again wasn't as complicated as I was
00:09:32.579 --> 00:09:33.926 afraid it might be.
00:09:34.156 --> 00:09:35.356 So I wanted to talk about that.
00:09:37.416 --> 00:09:44.036 Any questions on uh, target groupings and whatnot?
00:09:52.856 --> 00:09:55.936 Sounds like a no.
00:09:58.316 --> 00:09:59.106 Fantastic.
00:09:59.176 --> 00:10:04.976 Um, OK, so I'm mostly just winging it for this training.
00:10:05.536 --> 00:10:07.376 Umm, I didn't really have any.
00:10:09.626 --> 00:10:11.196 Didn't really have anything planned for it.
00:10:11.206 --> 00:10:13.336 It was just sort of a last minute to thing.
00:10:13.346 --> 00:10:18.076 So, does anybody have anything they've run into on check out
00:10:18.076 --> 00:10:22.806 recently that they need some direction or have questions on?
00:10:35.146 --> 00:10:36.596 And tough crowd.
00:10:38.256 --> 00:10:41.006 I sides it's rock thing.
00:10:41.016 --> 00:10:43.415 I was trying to think of projects where I had
00:10:43.415 --> 00:10:46.284 customizations on the checkout piece that were hard to
00:10:46.284 --> 00:10:48.736 architect, but I can't think of any write off.
00:10:54.856 --> 00:10:55.056 OK.
00:10:55.026 --> 00:10:57.656 Yeah, I'm struggling to think of anything specific that I'm like.
00:10:57.666 --> 00:11:00.910 Ohh that was a lot of the things I've done around checkout have
00:11:00.910 --> 00:11:04.104 been like not so much to do with checkout itself but more like
00:11:04.104 --> 00:11:05.726 the individual components of it.
00:11:05.736 --> 00:11:06.266 You know, I mean.
00:11:06.276 --> 00:11:06.456 So.
00:11:07.796 --> 00:11:09.386 Umm yeah? Umm.
00:11:11.876 --> 00:11:12.076 OK.
00:11:12.646 --> 00:11:13.156 Umm.
00:11:13.686 --> 00:11:17.193 Well, I do wanna cover a couple of things that uh, that I can
00:11:17.193 --> 00:11:20.588 think of that are a little bit like just a couple of really
00:11:20.588 --> 00:11:21.606 fast basic things.
00:11:22.566 --> 00:11:27.620 Umm that I've come across on different projects so you may
00:11:27.620 --> 00:11:29.076 see these things.
00:11:29.366 --> 00:11:30.216 You may not.
00:11:30.226 --> 00:11:31.056 It depends on.
00:11:31.066 --> 00:11:35.153 If I don't remember, if we fix this in core yet or not, but
00:11:35.153 --> 00:11:38.763 let's say that you make an override for target order
00:11:38.763 --> 00:11:42.850 checkout, so you've gone down into your client override and
00:11:42.850 --> 00:11:47.073 you've made a rock target order checkout provider which as it
00:11:47.073 --> 00:11:49.866 turns out we already have which is fine.
00:11:49.876 --> 00:11:50.546 Doesn't really matter.
00:11:50.936 --> 00:11:54.785 Umm my example can go on umm, unless they already fixed the
00:11:54.785 --> 00:11:58.955 bug in here, in which case this is to find a different code base
00:11:58.955 --> 00:12:02.804 that doesn't have this fixed, but so let's say you you make
00:12:02.804 --> 00:12:06.076 your you make your target order checkout override.
00:12:06.086 --> 00:12:11.056 Here you add it to your registry for I checkout provider base use
00:12:11.056 --> 00:12:12.186 our custom one.
00:12:13.006 --> 00:12:14.446 Umm, that's great.
00:12:14.456 --> 00:12:18.596 That's awesome, but then you run the code and it's not.
00:12:18.986 --> 00:12:21.813 It's not using your custom checkout provider, you put it in
00:12:21.813 --> 00:12:22.426 the registry.
00:12:22.436 --> 00:12:26.476 Everything else is correct, and yet it's still not.
00:12:26.606 --> 00:12:28.136 It's still not using your custom logic.
00:12:28.146 --> 00:12:29.066 It's not using your override.
00:12:29.976 --> 00:12:30.686 Umm.
00:12:31.516 --> 00:12:37.955 Well, the place to check for that is in the target order
00:12:37.955 --> 00:12:39.876 checkout service.
00:12:41.176 --> 00:12:46.026 Umm there is a file called or method called.
00:12:46.036 --> 00:12:46.966 Ensure target order.
00:12:46.976 --> 00:12:48.086 Checkout provider async.
00:12:48.156 --> 00:12:48.606 Yeah, it's OK.
00:12:48.616 --> 00:12:49.436 It's already been fixed here.
00:12:50.106 --> 00:12:57.745 Umm uh, you may see this line in uh in some code base is just
00:12:57.745 --> 00:13:02.796 says new target order checkout provider.
00:13:03.606 --> 00:13:05.576 It doesn't actually use the registry loader.
00:13:05.946 --> 00:13:09.800 If that's the case, then you don't wanna change that line to
00:13:09.800 --> 00:13:13.464 look like this, so that it actually uses that and then it
00:13:13.464 --> 00:13:17.255 looks like somebody added a check after that to ensure that
00:13:17.255 --> 00:13:21.235 the registered checkout provider is actually either the target
00:13:21.235 --> 00:13:24.900 order checkout provider itself, or in implementation that
00:13:24.900 --> 00:13:26.416 derives from this class.
00:13:27.266 --> 00:13:30.135 So that's a good check there just to make sure that you don't
00:13:30.135 --> 00:13:32.773 accidentally overwrite single order when target order is
00:13:32.773 --> 00:13:35.782 turned on and then called target order endpoints and it breaks a
00:13:35.782 --> 00:13:36.476 bunch of stuff.
00:13:37.326 --> 00:13:40.356 This will give you a decent decent error message configured.
00:13:40.366 --> 00:13:42.196 Checkup writer is not a target order provider.
00:13:42.546 --> 00:13:42.926 Great.
00:13:43.636 --> 00:13:48.706 Umm, so that's a good place to check and looks like Tristan.
00:13:48.716 --> 00:13:49.236 You have a question?
00:13:51.086 --> 00:13:54.584 Is there a reason we don't just have this set up like this in
00:13:54.584 --> 00:13:54.866 core?
00:13:55.906 --> 00:14:00.583 Uh, it's just a bug that needs to be fixed it it's it might be
00:13:58.756 --> 00:13:59.026 OK.
00:14:00.583 --> 00:14:03.256 already, but I don't know for sure.
00:14:03.346 --> 00:14:05.526 Let's stick a little.
00:14:05.536 --> 00:14:11.606 Look and see if it's fixed in core.
00:14:09.116 --> 00:14:11.515 So I feel like I see this continually popping up like
00:14:11.515 --> 00:14:11.826 always.
00:14:11.836 --> 00:14:15.395 Have someone being like hey, I got a test to do this and you
00:14:15.395 --> 00:14:17.146 know every like couple months.
00:14:17.156 --> 00:14:18.946 So like, that's still a thing.
00:14:18.996 --> 00:14:20.906 Like what? But.
00:14:20.486 --> 00:14:21.266 Yeah.
00:14:21.276 --> 00:14:22.106 Let's see.
00:14:22.156 --> 00:14:24.386 OK, so it is still like that in core right now.
00:14:25.056 --> 00:14:25.336 OK.
00:14:25.756 --> 00:14:27.466 So that's just something.
00:14:27.476 --> 00:14:30.086 I mean, that's like a couple of lines of code.
00:14:30.356 --> 00:14:34.112 Changing it to user registry and then adding a check to make sure
00:14:34.112 --> 00:14:37.300 that it is a target order implementation is a good idea
00:14:37.300 --> 00:14:40.316 and we will probably need to go in and do that, umm.
00:14:39.526 --> 00:14:42.980 This isn't necessarily related, but given that you're looking
00:14:42.980 --> 00:14:46.435 through the the files and the repo, does anyone remember what
00:14:44.866 --> 00:14:45.246 Umm.
00:14:46.435 --> 00:14:50.056 like the shortcut or whatever it is to bring up VS code in Azure
00:14:50.056 --> 00:14:50.446 DevOps?
00:14:51.306 --> 00:14:54.981 No, I usually if I need to make an edit in here, I just click
00:14:54.981 --> 00:14:58.596 the edit button and then you can type and then click commit.
00:15:00.156 --> 00:15:03.156 Yeah, because I remember someone had gone in like explain how you
00:15:03.156 --> 00:15:05.156 can like basically open in browser version.
00:15:05.166 --> 00:15:06.406 And it's just easier to navigate.
00:15:05.526 --> 00:15:07.376 Uh, Eric knows how to do that.
00:15:07.946 --> 00:15:11.776 Yeah, it's it's something similar to opening it in the in
00:15:08.306 --> 00:15:08.706 OK.
00:15:08.326 --> 00:15:08.596 Yeah.
00:15:11.776 --> 00:15:14.286 like a terminal like the code period.
00:15:14.746 --> 00:15:17.516 Umm let's it's something along those lines.
00:15:17.526 --> 00:15:19.156 JLR is the one that showed us.
00:15:19.706 --> 00:15:21.656 Yeah, it's pretty cool though.
00:15:19.896 --> 00:15:20.466 OK.
00:15:20.776 --> 00:15:21.086 Yeah.
00:15:21.096 --> 00:15:23.126 I just it is cool.
00:15:21.226 --> 00:15:22.026 I can't remember.
00:15:22.366 --> 00:15:24.626 It is, yeah, it's a browser version.
00:15:23.136 --> 00:15:23.926 I just keep on.
00:15:24.456 --> 00:15:27.114 I remember there was the training on it and then I tried
00:15:27.114 --> 00:15:29.166 doing it like a week later and just forgot.
00:15:29.176 --> 00:15:31.566 Whatever it was I was like. Ohh.
00:15:32.096 --> 00:15:33.216 And then I just remembered it.
00:15:32.566 --> 00:15:34.426 Yeah, trying to see if I can.
00:15:35.476 --> 00:15:36.936 Free remembered that I forgot at least.
00:15:39.386 --> 00:15:39.916 Yeah.
00:15:40.106 --> 00:15:42.446 Well, anyway, so yeah, this is a.
00:15:42.496 --> 00:15:44.934 This is a place to check and share target order checkout
00:15:44.934 --> 00:15:45.576 provider async.
00:15:45.886 --> 00:15:49.709 If you're on maybe a project that's already branched off and
00:15:49.709 --> 00:15:53.470 doesn't have this fixed, which we will fix it in core soon,
00:15:53.470 --> 00:15:55.726 then this is a good place to check.
00:15:55.746 --> 00:16:00.170 If you do, if you do override checkout and you're not seeing
00:16:00.170 --> 00:16:02.056 your changes applied, umm.
00:16:02.866 --> 00:16:04.926 So ohm.
00:16:07.646 --> 00:16:08.356 That's a good one.
00:16:10.516 --> 00:16:11.656 Another really important thing.
00:16:12.546 --> 00:16:16.728 Uh that I haven't seen this come up in a minute, but I have seen
00:16:16.728 --> 00:16:17.436 it come up.
00:16:18.816 --> 00:16:23.686 Uh before is to consider the order of operations.
00:16:25.026 --> 00:16:29.176 Uh, and check out when you are adding customizations.
00:16:30.226 --> 00:16:30.776 Umm.
00:16:30.786 --> 00:16:32.826 For example, uh.
00:16:32.836 --> 00:16:33.336 Let's see.
00:16:33.346 --> 00:16:35.976 Where's process current card two?
00:16:36.086 --> 00:16:36.556 There it is.
00:16:36.566 --> 00:16:39.304 OK, this is the method that gets called at the end of checkout
00:16:39.304 --> 00:16:40.956 process current card to target order.
00:16:40.966 --> 00:16:43.985 So this is the final thing where all of the checkout information
00:16:43.985 --> 00:16:46.586 has been collected and put together, and we're ready to
00:16:46.586 --> 00:16:49.466 take all the target carts, turn them into sub orders, process
00:16:49.466 --> 00:16:51.696 payment and all that kind of stuff, right? Umm.
00:16:54.206 --> 00:16:55.326 So that being the case.
00:16:58.546 --> 00:17:02.732 The case that we saw in rock was that we had a we we added the
00:17:02.732 --> 00:17:06.785 gift cards to the to the the code base and we wanted to make
00:17:06.785 --> 00:17:11.170 sure that when you bought a gift card it would add a gift card to
00:17:11.170 --> 00:17:15.156 your account and set up the balance and all that fun stuff.
00:17:17.056 --> 00:17:17.766 Umm.
00:17:18.206 --> 00:17:23.106 However, that logic was added right here.
00:17:29.366 --> 00:17:32.866 OK, that was all added right here originally.
00:17:34.016 --> 00:17:36.566 Can anybody tell me why that's a problem?
00:17:47.006 --> 00:17:47.926 I'll scroll up a little bit.
00:17:47.936 --> 00:17:49.916 So you can see the full method leading up to this.
00:17:59.606 --> 00:18:03.986 I need the the jeopardy sound at the end of it.
00:18:03.996 --> 00:18:06.376 I call on someone, yeah.
00:18:04.116 --> 00:18:10.986 It it it it it it it do day Doo Doo Doo there.
00:18:19.066 --> 00:18:19.786 Bomb bomb.
00:18:22.126 --> 00:18:23.526 Alright, I choose you, Tim.
00:18:23.156 --> 00:18:23.396 Is.
00:18:23.446 --> 00:18:26.336 If uh, if check out fails right?
00:18:26.346 --> 00:18:27.726 We've already created the gift card.
00:18:27.826 --> 00:18:28.236 Is that the?
00:18:29.036 --> 00:18:30.446 That is correct.
00:18:29.596 --> 00:18:30.816 So yeah.
00:18:30.996 --> 00:18:34.563 We haven't even called checkout yet and most critically, we
00:18:34.563 --> 00:18:36.346 haven't processed payment yet.
00:18:36.906 --> 00:18:37.986 Hmm yeah.
00:18:37.816 --> 00:18:41.731 So what that means is I can add as many gift cards as I want to
00:18:41.731 --> 00:18:45.341 my cart, put in a completely bogus card number and it will
00:18:45.341 --> 00:18:49.195 create all of those gift cards anyway, and then check out will
00:18:49.195 --> 00:18:52.376 fail and I will still have all of those gift cards.
00:18:53.736 --> 00:18:55.306 It may not tell me I have them.
00:18:55.316 --> 00:18:58.557 It may not send an email since checkout failed, but it's still
00:18:58.557 --> 00:19:01.644 created the record that they exist and I still have balance
00:19:01.644 --> 00:19:04.628 on them, so keeping that order of operations in mind when
00:19:04.628 --> 00:19:07.252 you're making checkout customizations is extremely
00:19:07.252 --> 00:19:07.766 important.
00:19:09.646 --> 00:19:14.977 So if it's, if it's sending we we had similar stuff on on uh
00:19:14.977 --> 00:19:20.396 Rapids on wheels forever ago, which was like making sure that
00:19:20.396 --> 00:19:24.416 we didn't set appointments for medical tests.
00:19:24.466 --> 00:19:28.186 If your payment didn't process, making sure that it happened
00:19:28.186 --> 00:19:31.967 after the payment processing check, umm and now I believe all
00:19:31.967 --> 00:19:35.809 of the logic that handled this probably in the override, to be
00:19:35.809 --> 00:19:36.236 honest.
00:19:36.626 --> 00:19:36.786 Yeah.
00:19:37.426 --> 00:19:42.816 Umm, so now uh, that's setting up the processing of the paying
00:19:42.816 --> 00:19:45.896 with gift cards, not creating them.
00:19:46.766 --> 00:19:49.096 Umm, so now we process payment.
00:19:49.166 --> 00:19:52.696 If the process payment result fails, then we return we.
00:19:52.706 --> 00:19:56.971 We fail out here, so at this point we validated that their
00:19:56.971 --> 00:20:00.586 payment method is correct and it all makes sense.
00:20:00.906 --> 00:20:04.026 And then we come down into actually grabbing the purchase
00:20:04.026 --> 00:20:07.416 gift cards from their cart and creating the records and stuff.
00:20:08.286 --> 00:20:12.377 So anytime you're you're doing customizations to check out,
00:20:12.377 --> 00:20:16.741 that should only happen in the event that deep payment succeeds
00:20:16.741 --> 00:20:20.968 and they actually get to the point of generating an order and
00:20:20.968 --> 00:20:23.286 sending all the emails and stuff.
00:20:23.346 --> 00:20:26.096 You just need to make sure that you're cognizant of where you
00:20:26.096 --> 00:20:27.826 put that code, because it does matter.
00:20:28.686 --> 00:20:32.628 Umm and especially in the case of something like gift cards,
00:20:32.628 --> 00:20:35.536 that's that's a pretty significant loophole.
00:20:35.626 --> 00:20:36.076 Um.
00:20:36.086 --> 00:20:39.988 So umm, just being being aware of what's happening in the code
00:20:39.988 --> 00:20:42.466 around where you're making your change?
00:20:43.116 --> 00:20:43.696 Umm.
00:20:44.986 --> 00:20:50.121 Similarly, colocating some like a like code, so if you're adding
00:20:50.121 --> 00:20:54.703 new emails that need to be sent when someone goes through
00:20:54.703 --> 00:20:59.206 checkout, there's a method in here called handle emails.
00:21:00.906 --> 00:21:03.876 Add your emails to this or override it.
00:21:03.886 --> 00:21:05.196 Call the base and then add it.
00:21:05.206 --> 00:21:10.921 You know, for example, if we were doing that down here, then
00:21:10.921 --> 00:21:16.729 see you dedicate copied in here that we just call it let's go
00:21:16.729 --> 00:21:22.913 umm that we can go down here and we can add or ride handle emails
00:21:22.913 --> 00:21:27.316 and then we can do uh my answer is no results.
00:21:27.326 --> 00:21:30.686 So you just await the base the way it falls.
00:21:34.396 --> 00:21:41.596 And then like there's some logic to send additional emails here.
00:21:41.726 --> 00:21:44.827 And obviously I want to make sure you don't forget to call
00:21:44.827 --> 00:21:47.928 the base because then it's not gonna send any of the order
00:21:47.928 --> 00:21:50.136 confirmation or back office order emails.
00:21:52.806 --> 00:21:55.678 So we definitely want to make sure that we do this, unless
00:21:55.678 --> 00:21:58.356 you're customization is replacing all of those emails.
00:21:59.386 --> 00:22:01.856 Umm which should be weird I guess at that point you just
00:22:01.856 --> 00:22:04.499 customize the emails themselves and not the logic that sends
00:22:04.499 --> 00:22:04.716 them.
00:22:04.776 --> 00:22:08.733 But you know, there could be a scenario I can't think of 1, but
00:22:08.733 --> 00:22:12.196 there could probably maybe be umm, but again colocating
00:22:12.196 --> 00:22:15.968 similar stuff don't add random email logic to the end of a a
00:22:15.968 --> 00:22:19.864 different method or slap it in the middle of the checkout code
00:22:19.864 --> 00:22:21.966 right after it processes payment.
00:22:21.976 --> 00:22:22.556 That kind of thing.
00:22:24.886 --> 00:22:29.351 There's also other other of those, like handle XYZ methods
00:22:29.351 --> 00:22:33.211 in here were, uh, you can there's handling payment
00:22:33.211 --> 00:22:33.816 storage.
00:22:33.826 --> 00:22:37.367 So if you have customized logic for payment records getting
00:22:37.367 --> 00:22:40.376 created, which we did for UM, what do you call it?
00:22:41.206 --> 00:22:41.936 Gift cards.
00:22:42.226 --> 00:22:43.336 You don't need to add that here.
00:22:44.166 --> 00:22:49.056 Uh, in that method, umm handle lots.
00:22:49.066 --> 00:22:52.461 So this is a a a method that was written for the uh, the core
00:22:52.461 --> 00:22:55.637 auction functionality or just sort of puts all this stuff
00:22:55.637 --> 00:22:55.966 about.
00:22:56.946 --> 00:23:01.116 Umm, purchasing a buy it now lot into one clean place.
00:23:02.396 --> 00:23:03.616 Ohh cool.
00:23:03.626 --> 00:23:04.966 I'm searching inside of that now.
00:23:04.976 --> 00:23:05.286 I don't.
00:23:05.516 --> 00:23:09.576 I don't like that uh handling attributes on the order and
00:23:09.576 --> 00:23:10.766 things like that.
00:23:12.196 --> 00:23:14.506 Uh, just handle payment storage.
00:23:17.206 --> 00:23:18.956 Handle order statuses.
00:23:19.346 --> 00:23:23.039 So anyway, all that to say, there are methods that are built
00:23:23.039 --> 00:23:26.126 to handle specific things, and if you need to make
00:23:26.126 --> 00:23:30.061 customizations that are related to those congratulations, you've
00:23:30.061 --> 00:23:31.816 already got a place to start.
00:23:33.096 --> 00:23:37.572 So sometimes I find it helpful when I'm especially in larger
00:23:37.572 --> 00:23:42.342 files like this to collapse the implementations and just look at
00:23:42.342 --> 00:23:42.636 and.
00:23:42.646 --> 00:23:44.156 You can also technically do this if you like.
00:23:44.166 --> 00:23:47.816 Go over here and expand this.
00:23:47.826 --> 00:23:49.696 You can see all the methods that are in here.
00:23:50.096 --> 00:23:51.746 Um, but I don't.
00:23:51.756 --> 00:23:52.846 I don't know why this just doesn't.
00:23:52.726 --> 00:23:55.557 That actually shows you all the methods on the class, regardless
00:23:55.557 --> 00:23:56.646 of which file they're in.
00:23:56.466 --> 00:23:56.976 Uh, OK.
00:23:56.986 --> 00:23:58.496 So that actually includes the inherited.
00:23:58.506 --> 00:23:59.036 OK.
00:23:59.086 --> 00:24:02.206 Yeah, which is a little bit messy or not messy, but
00:23:59.476 --> 00:24:02.336 Yeah, I'm in the file.
00:24:02.206 --> 00:24:02.806 confusing.
00:24:02.346 --> 00:24:05.376 If you do control M control L, it will collapse all.
00:24:06.416 --> 00:24:08.796 Umm, the control the control.
00:24:08.616 --> 00:24:10.066 So ohhh my.
00:24:08.806 --> 00:24:09.876 Like if you yeah.
00:24:09.946 --> 00:24:13.232 So that that, yeah, that one does the full hard collapse if
00:24:13.232 --> 00:24:16.682 you do control M control O it does the lighter when we're just
00:24:16.682 --> 00:24:19.146 like collapses the like to the method level.
00:24:19.946 --> 00:24:20.326 OK.
00:24:20.336 --> 00:24:20.936 That makes sense.
00:24:20.936 --> 00:24:23.846 So if you so if you do control M control to open it all back up
00:24:21.336 --> 00:24:22.396 Honestly, this is kind of nice though.
00:24:23.846 --> 00:24:26.256 and then you control M control O, you'll see the the
00:24:26.256 --> 00:24:26.756 difference.
00:24:27.366 --> 00:24:27.776 Yeah.
00:24:27.786 --> 00:24:29.376 OK so basically this is just what I read.
00:24:29.386 --> 00:24:30.546 Expanded it to after the fact.
00:24:31.406 --> 00:24:34.997 OK, but yeah, so you can you can do that and I I find that this
00:24:31.536 --> 00:24:31.716 Yeah.
00:24:34.997 --> 00:24:38.475 is nice to be able to go and look at like what methods are in
00:24:38.475 --> 00:24:38.756 here.
00:24:38.766 --> 00:24:41.636 I usually just do it manually because I didn't realize there
00:24:41.636 --> 00:24:44.506 was a shortcut for it, but this is a nice way to see all the
00:24:44.506 --> 00:24:45.776 methods that are in a file.
00:24:46.386 --> 00:24:47.036 Umm.
00:24:47.516 --> 00:24:50.892 And it's a lot easier than like control F and searching for like
00:24:50.892 --> 00:24:54.008 relevant names that the method might have if you don't know
00:24:54.008 --> 00:24:55.566 them off the top of your head.
00:24:55.636 --> 00:24:57.366 So you can use that to find if there's.
00:24:56.286 --> 00:24:58.146 There's also the drop down in the top right.
00:24:59.716 --> 00:25:05.926 Drop down this one or or that one control T.
00:25:01.826 --> 00:25:03.816 Now in in the file area.
00:25:06.726 --> 00:25:08.546 No, right above that.
00:25:10.436 --> 00:25:11.756 Right above this.
00:25:12.376 --> 00:25:15.246 Ohh, this guy that one? Yeah.
00:25:12.446 --> 00:25:12.586 Yes.
00:25:16.116 --> 00:25:18.726 That's all the methods that are part of the the class as well.
00:25:19.706 --> 00:25:22.614 I'm assuming the ones that are white are the ones that are in
00:25:22.614 --> 00:25:25.146 this file and the grayed out ones are just inherited.
00:25:25.966 --> 00:25:28.956 That's what it looks like anyway, yeah.
00:25:26.746 --> 00:25:28.356 Uh, yeah.
00:25:28.396 --> 00:25:30.473 They're either inherited or they're not in the file,
00:25:30.473 --> 00:25:30.826 whatever.
00:25:30.966 --> 00:25:31.396 Yeah.
00:25:31.406 --> 00:25:33.896 Yeah, for like being in a partial or something.
00:25:34.266 --> 00:25:34.616 Cool.
00:25:34.626 --> 00:25:35.476 That's convenient.
00:25:36.126 --> 00:25:38.806 Alright, so that's very that's very nice.
00:25:39.686 --> 00:25:40.436 Umm.
00:25:42.786 --> 00:25:43.216 All right.
00:25:43.226 --> 00:25:50.669 So one of the next things that I wanted to really quickly cover
00:25:50.669 --> 00:25:57.531 is when to when to make a checkout override or just modify
00:25:57.531 --> 00:26:03.696 core and the answer to that question is obviously it
00:26:03.696 --> 00:26:04.626 depends.
00:26:04.636 --> 00:26:07.826 So I wanted to at least put forth some of the criteria.
00:26:09.646 --> 00:26:15.406 If you're copying like 7 or 800 lines of code into the override
00:26:15.406 --> 00:26:19.456 to change one thing, just change it in core.
00:26:20.046 --> 00:26:27.209 It's that's so much extra stuff to maintain and it's confusing
00:26:27.209 --> 00:26:29.256 and etcetera, umm.
00:26:28.846 --> 00:26:32.006 Sometimes if it's a function that is like a huge function,
00:26:32.006 --> 00:26:35.434 you might be able to refactor by grabbing like the middle chunk
00:26:35.434 --> 00:26:38.166 of the function like the middle 20 lines you need.
00:26:38.936 --> 00:26:39.156 Yeah.
00:26:39.326 --> 00:26:42.762 Refactor that so that it's it's own method that that one calls
00:26:42.762 --> 00:26:45.926 and then you just override that one sub method basically.
00:26:45.956 --> 00:26:47.686 Yeah, for example, you could.
00:26:47.796 --> 00:26:52.903 You could theoretically, instead of overwriting this entire
00:26:52.903 --> 00:26:57.585 method to uh to change the target custom key or custom
00:26:57.585 --> 00:26:58.436 split key.
00:26:58.446 --> 00:27:03.660 Here you could just do like target dot customs split key
00:27:03.660 --> 00:27:09.606 equals get custom split key and pass in the target and the card.
00:27:09.876 --> 00:27:14.482 Uh, the original card and anything else you can think you
00:27:14.482 --> 00:27:19.485 may need passed into that and then you can just come down here
00:27:19.485 --> 00:27:20.676 and add a find.
00:27:20.686 --> 00:27:22.796 The last probably after this one that'll work.
00:27:23.576 --> 00:27:24.366 Uh.
00:27:24.376 --> 00:27:29.416 Protected virtual string get custom split key.
00:27:30.756 --> 00:27:32.236 Uh, with uh.
00:27:32.246 --> 00:27:34.191 Just gonna be lazy and do it this way for just a second just
00:27:34.191 --> 00:27:34.956 to get the point across.
00:27:39.136 --> 00:27:42.106 Uh, and then by default it would just return null.
00:27:42.116 --> 00:27:45.623 But then in your in your custom checkout provider, you can just
00:27:45.623 --> 00:27:48.527 override this and return whatever string you need to
00:27:48.527 --> 00:27:51.925 return based on whatever you pass in, and that makes it a lot
00:27:51.925 --> 00:27:52.966 easier than either.
00:27:53.316 --> 00:27:55.126 It's a slight modification to core.
00:27:55.136 --> 00:27:56.866 That's nice and it's easy to like.
00:27:57.156 --> 00:28:00.379 It's easy for us to bring into core and make that something
00:28:00.379 --> 00:28:03.709 where we don't have to parse through your entire override and
00:28:03.709 --> 00:28:07.146 find the thing that you changed to say, oh, that's a good idea.
00:28:07.156 --> 00:28:11.572 This needle in a haystack we can pull over if it's just if you
00:28:11.572 --> 00:28:15.497 just make this and then this down here umm, then we can
00:28:15.497 --> 00:28:20.054 clearly see what your intent was in the core file and bring that
00:28:20.054 --> 00:28:21.666 into core a lot easier.
00:28:23.896 --> 00:28:26.641 And and then we also don't have to strip out specific client
00:28:26.641 --> 00:28:27.316 customizations.
00:28:27.526 --> 00:28:30.336 If I was thinking I would have done that when I wrote this.
00:28:31.316 --> 00:28:33.946 Umm, but I wasn't thinking so.
00:28:39.596 --> 00:28:39.886 Yeah.
00:28:39.896 --> 00:28:42.775 And then if similar similarly, if you find that you have to
00:28:42.775 --> 00:28:45.126 copy a bunch of methods because they're private.
00:28:45.816 --> 00:28:49.000 Umm, there are probably private just because they didn't need to
00:28:49.000 --> 00:28:50.176 be protected beforehand.
00:28:50.476 --> 00:28:53.755 So for example, if for some like if you copy some code or you're
00:28:53.755 --> 00:28:57.085 overwriting something that needs to call this private method that
00:28:57.085 --> 00:28:59.406 has zero references, so probably doesn't get.
00:28:59.416 --> 00:29:02.094 Doesn't get used anywhere right now, but say you did for some
00:29:02.094 --> 00:29:02.396 reason.
00:29:03.696 --> 00:29:07.500 You can make it protected or static, have to make public, but
00:29:07.500 --> 00:29:11.487 you could also just make it like protected like that so that you
00:29:11.487 --> 00:29:15.536 can call this from the other one if you find that you have member
00:29:15.536 --> 00:29:19.340 that you want to override, but it's not virtual, just come in
00:29:19.340 --> 00:29:20.996 here and add virtual to it.
00:29:21.426 --> 00:29:24.916 Umm, we can find a good example up here.
00:29:24.926 --> 00:29:29.074 Most of these are already overrides, which are themselves
00:29:29.074 --> 00:29:29.646 virtual.
00:29:29.926 --> 00:29:33.059 Let's say for some reason you need to override update billing
00:29:33.059 --> 00:29:33.716 contact info.
00:29:34.476 --> 00:29:38.687 Umm you can just change it from being static to being virtual
00:29:38.687 --> 00:29:42.286 and now you can override that in a downstream class.
00:29:42.476 --> 00:29:46.736 Little modifications like that decor are much easier and it's
00:29:46.736 --> 00:29:50.858 nice because then you don't have to go and copy this entire
00:29:50.858 --> 00:29:55.186 method into your override and add more bloat to that override.
00:29:55.196 --> 00:29:56.606 You can just try to keep those.
00:29:56.976 --> 00:29:59.904 Keep keep the override as slim as possible, so it's only
00:29:59.904 --> 00:30:03.090 changing what it actually needs to change and the rest of the
00:30:03.090 --> 00:30:05.556 logic can run through core as much as possible.
00:30:21.726 --> 00:30:26.985 And the I'll be honest, that's and our only can't think of
00:30:26.985 --> 00:30:30.016 anything else good to cover here.
00:30:31.576 --> 00:30:35.293 Besides, uh, if you make adjustments to anything related
00:30:31.636 --> 00:30:32.176 Umm.
00:30:35.293 --> 00:30:38.879 to payments and money thoroughly, thoroughly test your
00:30:38.879 --> 00:30:42.921 changes and make sure that the dollar amount that you display
00:30:42.921 --> 00:30:46.964 that will be charged to a card in the front end is the actual
00:30:46.964 --> 00:30:51.007 dollar amount you charge to the card when the payment process
00:30:51.007 --> 00:30:52.376 runs on the back end.
00:30:52.846 --> 00:30:55.216 That was another issue we had with the gift card.
00:30:55.226 --> 00:30:59.626 Logic was, uh, if I put in in in the original implementation.
00:30:59.636 --> 00:31:03.164 If I put in two gift cards and I wanted it to pull $10 from, you
00:31:03.164 --> 00:31:04.846 know, let's say two gift cards.
00:31:04.856 --> 00:31:08.538 I had $50.00 balances on each and I only wanted it to pull $10
00:31:08.538 --> 00:31:11.811 from each, so I was paying $20.00 off the gift card and
00:31:11.811 --> 00:31:15.085 then I had the remaining $10 balance on my on my actual
00:31:15.085 --> 00:31:15.786 credit card.
00:31:17.416 --> 00:31:21.163 The original implementation of the logic was not functioning
00:31:21.163 --> 00:31:21.716 that way.
00:31:21.896 --> 00:31:26.090 It would actually greedily consume from the gift cards in a
00:31:26.090 --> 00:31:30.283 round Robin fashion until it either until it either had the
00:31:30.283 --> 00:31:34.477 full balance of checkout paid, or ran out of balance on the
00:31:34.477 --> 00:31:38.740 gift cards, which would mean that best case the user thought
00:31:38.740 --> 00:31:43.004 they were going to be charged money and they weren't, but it
00:31:43.004 --> 00:31:47.337 sucked up all the money on all their gift cards and you know,
00:31:47.337 --> 00:31:48.036 so it was.
00:31:48.206 --> 00:31:51.243 It was a bit of an interesting implementation because the front
00:31:51.243 --> 00:31:54.281 end and the back end we're doing completely different things in
00:31:54.281 --> 00:31:56.844 terms of how they were displaying what would actually
00:31:56.844 --> 00:31:57.176 happen.
00:31:58.236 --> 00:31:58.716 Umm.
00:31:59.506 --> 00:32:03.113 And so that's something that's extremely important if you're
00:32:03.113 --> 00:32:06.661 ever working on anything and check out that has anything to
00:32:06.661 --> 00:32:10.504 do with totals and amounts being paid and fees and anything like
00:32:10.504 --> 00:32:13.993 that, quintuple check every calculation and make sure that
00:32:13.993 --> 00:32:17.600 the final number you charge to their card matches what we're
00:32:17.600 --> 00:32:19.256 displaying on the front end.
00:32:19.686 --> 00:32:23.857 And if there's any issues that should never, frankly, should
00:32:23.857 --> 00:32:28.369 never even make it into a PR, if that has if issues like that are
00:32:28.369 --> 00:32:28.916 present.
00:32:29.266 --> 00:32:32.686 But if there are issues like that that make it to a PR we we
00:32:32.686 --> 00:32:35.096 probably should not let that get to stage.
00:32:36.186 --> 00:32:42.026 Because uh, you know, too easy to miss when all the rest of the
00:32:42.026 --> 00:32:43.486 UAT is going on.
00:32:43.636 --> 00:32:46.399 If the if the dollar amount looks correct in the front end,
00:32:46.399 --> 00:32:49.254 the clients probably going to trust that we are doing all the
00:32:49.254 --> 00:32:52.063 math on the back end correctly, which they should trust that
00:32:52.063 --> 00:32:54.366 we're doing that because we should be doing that.
00:32:54.426 --> 00:32:56.246 Obviously it would be cool if they would check it too.
00:32:56.296 --> 00:32:59.328 They should check it, but I don't blame them for trusting us
00:32:59.328 --> 00:32:59.676 for it.
00:33:00.386 --> 00:33:00.906 Umm.
00:33:01.406 --> 00:33:02.526 And we should be trusted with it.
00:33:01.826 --> 00:33:02.156 Yeah.
00:33:02.166 --> 00:33:06.544 And if it, if it turns out it's not, that could cause a great
00:33:06.544 --> 00:33:11.063 collapse and client, you know, trust and confidence in us, like
00:33:08.636 --> 00:33:08.836 Yep.
00:33:11.063 --> 00:33:13.676 that's a major, major factor, right?
00:33:13.766 --> 00:33:13.946 Yeah.
00:33:14.026 --> 00:33:16.489 Like, that's not just getting a feature wrong or business
00:33:16.489 --> 00:33:17.296 requirements wrong.
00:33:17.306 --> 00:33:19.386 That's a major thing. Uh.
00:33:18.826 --> 00:33:22.127 Yeah, especially if we end up getting into production and
00:33:22.127 --> 00:33:25.769 we're charging people's cards a different amount than we say we
00:33:25.769 --> 00:33:28.046 are, that's a massive, massive problem.
00:33:26.256 --> 00:33:26.456 Yeah.
00:33:28.876 --> 00:33:33.185 Yeah, even if they were getting charged less than what we've say
00:33:28.956 --> 00:33:31.626 Umm, so uh.
00:33:33.185 --> 00:33:34.246 they are, right?
00:33:33.896 --> 00:33:34.326 Right.
00:33:34.256 --> 00:33:34.616 Like the.
00:33:34.336 --> 00:33:35.546 It's it's still.
00:33:35.736 --> 00:33:38.971 Yeah, even in the best case scenario, if we say we're gonna
00:33:38.971 --> 00:33:42.206 charge him $100 and we only charge them 20, there's still a
00:33:42.206 --> 00:33:43.176 discrepancy there.
00:33:43.186 --> 00:33:46.592 That's gonna make that person inherently not trust the site
00:33:46.592 --> 00:33:47.046 anymore.
00:33:46.956 --> 00:33:47.156 Yeah.
00:33:47.496 --> 00:33:52.048 If they see that they're not likely to be a repeat customer
00:33:52.048 --> 00:33:56.904 to that website and that is in turn a negative negative outcome
00:33:56.904 --> 00:33:58.346 for for the client.
00:33:58.356 --> 00:34:01.676 So which in turn is a negative outcome for us.
00:34:02.226 --> 00:34:04.986 So don't, don't do that.
00:34:07.016 --> 00:34:09.916 Umm yeah.
00:34:19.536 --> 00:34:20.186 All right.
00:34:20.196 --> 00:34:26.426 Well, I can't really think of anything else to cover here.
00:34:25.926 --> 00:34:30.494 Do we just want to keep rolling with the checkout and just maybe
00:34:30.494 --> 00:34:33.726 go through check out like the implementation?
00:34:34.176 --> 00:34:35.706 I guess of target order checkout.
00:34:35.716 --> 00:34:36.916 I don't know what do you guys think?
00:34:37.656 --> 00:34:38.386 And I can try.
00:34:39.766 --> 00:34:40.376 What of it?
00:34:40.386 --> 00:34:41.536 I can make sense of.
00:34:42.476 --> 00:34:47.696 Yeah, this kind of high level explaining what it's doing.
00:34:43.436 --> 00:34:43.996 Uh.
00:34:48.376 --> 00:34:49.376 Yeah, yeah.
00:34:49.496 --> 00:34:53.201 So if you know they get a task with maybe the architecture is
00:34:53.201 --> 00:34:56.845 not great on it, they might have an idea of where things are
00:34:56.845 --> 00:34:59.116 happening to hook into kind of thing.
00:34:57.776 --> 00:34:58.386 Yeah.
00:34:58.996 --> 00:34:59.286 Cool.
00:34:59.296 --> 00:35:01.486 So we'll start with going through it on.
00:35:01.496 --> 00:35:04.216 We'll just go through, check out on the on the actual site.
00:35:06.896 --> 00:35:12.171 And and then we'll go from there and look at what the actual
00:35:12.171 --> 00:35:13.036 processes.
00:35:15.486 --> 00:35:19.144 Umm, but the process is doing on the back end and hopefully
00:35:19.144 --> 00:35:22.741 there's some bugs on develop right now that we're gonna be
00:35:22.741 --> 00:35:24.936 working on stabilizing next Sprint.
00:35:25.386 --> 00:35:26.956 So hopefully we're able to get all the way through.
00:35:26.966 --> 00:35:27.266 Checkout.
00:35:27.276 --> 00:35:30.621 There's a lot of changes that have gone in that we haven't had
00:35:30.621 --> 00:35:32.426 time to, to vet and solidify yet.
00:35:37.946 --> 00:35:42.154 Also, the servers have been going mind numbingly slow as you
00:35:42.154 --> 00:35:42.706 can see.
00:35:45.506 --> 00:35:51.312 OK, so I'm gonna buy this software that's say nothing to
00:35:51.312 --> 00:35:52.636 ship product.
00:35:53.266 --> 00:35:57.903 I know that just from my own testing repeatedly, I'm also
00:35:57.903 --> 00:36:02.939 going to buy this this exhaust pipe thing and we'll go to page
00:36:02.939 --> 00:36:06.616 2 and we'll get us uh, we'll get some wallet.
00:36:07.576 --> 00:36:08.226 Yeah.
00:36:08.296 --> 00:36:10.166 Cool with the car.
00:36:11.196 --> 00:36:12.326 I already had a laptop in here.
00:36:12.336 --> 00:36:13.626 Just gonna clear that real quick.
00:36:13.716 --> 00:36:15.856 I don't need that right now, so these are my items.
00:36:16.816 --> 00:36:19.626 Uh, cool onward.
00:36:19.816 --> 00:36:21.236 Now we're actually gonna get into checkout.
00:36:21.436 --> 00:36:24.887 So like I mentioned earlier, target order Checkout has the
00:36:24.887 --> 00:36:28.338 ability to send different products at different places and
00:36:28.338 --> 00:36:31.906 to split things out based on different criteria immediately.
00:36:31.916 --> 00:36:35.553 We're already seeing one of those, one of those possible
00:36:35.553 --> 00:36:39.126 axes of split happening shippable versus non shippable.
00:36:39.336 --> 00:36:41.086 This product is a software.
00:36:41.316 --> 00:36:44.486 It's like a download, so there's nothing.
00:36:44.736 --> 00:36:46.286 They don't have anything to ship me.
00:36:46.336 --> 00:36:48.973 They just send me like a product code and an email or download
00:36:48.973 --> 00:36:49.726 link or something.
00:36:50.846 --> 00:36:52.716 So it's a non shippable product.
00:36:52.726 --> 00:36:54.196 It gets moved into its own section.
00:36:54.626 --> 00:36:58.473 Obviously I don't need to pick a shipping address for that down
00:36:58.473 --> 00:36:59.976 here I have no addresses.
00:36:59.986 --> 00:37:00.876 I'm not logged in.
00:37:01.826 --> 00:37:08.386 Yeah, I'll be they log in, we got a guest checkout turned on
00:37:08.386 --> 00:37:09.246 in here.
00:37:10.666 --> 00:37:12.656 I assume, I hope.
00:37:24.526 --> 00:37:25.616 OK, cool.
00:37:25.806 --> 00:37:27.116 Now we're cooking.
00:37:28.356 --> 00:37:31.816 Uh, so I'm logged in as clarity admin.
00:37:32.056 --> 00:37:35.430 I'm going to go and refresh this page just so let's do everything
00:37:35.430 --> 00:37:36.146 top to bottom.
00:37:36.456 --> 00:37:41.066 OK, so now I've got my destinations I can ship to.
00:37:41.156 --> 00:37:41.566 Great.
00:37:42.136 --> 00:37:46.051 Let's say that I want to ship this wallet to my home and I
00:37:46.051 --> 00:37:47.246 want to ship this.
00:37:49.556 --> 00:37:52.276 This exhaust pipe thing to my office.
00:37:53.206 --> 00:37:53.446 Cool.
00:37:55.006 --> 00:38:00.091 So what's gonna happen at this point is whenever I submit this,
00:38:00.091 --> 00:38:05.176 it sets those properties, those desired destinations as targets
00:38:05.176 --> 00:38:06.686 on each sales item.
00:38:08.816 --> 00:38:09.946 So what that does?
00:38:09.956 --> 00:38:13.825 What that effectively means is that we're saying I want five of
00:38:13.825 --> 00:38:17.392 this to go this way to this address, and two of this to go
00:38:17.392 --> 00:38:19.206 to this address and et cetera.
00:38:19.596 --> 00:38:22.386 And then So what will actually see?
00:38:22.386 --> 00:38:24.072 I'll go ahead and click the button and we can look at the
00:38:24.072 --> 00:38:24.246 calls.
00:38:24.396 --> 00:38:28.852 So this one does the CART items update and you can see that it's
00:38:28.852 --> 00:38:31.046 sent the items with the targets.
00:38:32.246 --> 00:38:33.606 Umm, that's great.
00:38:33.806 --> 00:38:34.516 Nice and easy.
00:38:35.086 --> 00:38:38.016 After it runs that call, once, that call has succeeded.
00:38:38.026 --> 00:38:40.976 It then calls analyze current cart to target carts.
00:38:41.406 --> 00:38:44.575 This is that giant method we were looking at earlier where we
00:38:44.575 --> 00:38:47.898 talked about how to add our own custom split keys inside of that
00:38:47.898 --> 00:38:48.256 method.
00:38:48.266 --> 00:38:52.237 What it effectively does is it goes over the sales items on
00:38:52.237 --> 00:38:56.275 your actual shopping cart, so it's gonna be these items over
00:38:56.275 --> 00:38:56.606 here.
00:38:57.306 --> 00:39:00.497 And then on each of those items, it goes into the targets and
00:39:00.497 --> 00:39:03.276 uses those targets to create the target grouping key.
00:39:03.806 --> 00:39:08.159 It then takes that target grouping key umm, and groups
00:39:08.159 --> 00:39:13.145 together all of the products and quantities that have the same
00:39:13.145 --> 00:39:18.052 target grouping key and then creates new additional carts for
00:39:18.052 --> 00:39:20.506 each of those unique groupings.
00:39:21.666 --> 00:39:24.683 Umm so all the products go into the same address are in their
00:39:24.683 --> 00:39:25.316 own grouping.
00:39:25.326 --> 00:39:29.398 All the products going to another different address or
00:39:29.398 --> 00:39:33.915 coming from the same store or with the same custom split key
00:39:33.915 --> 00:39:38.061 et cetera, land in the same bucket, the same cart, it's
00:39:38.061 --> 00:39:39.616 called a target cart.
00:39:39.866 --> 00:39:42.655 I'm not sure why that, I mean I guess because you can target
00:39:42.655 --> 00:39:44.576 them to different addresses or something.
00:39:44.586 --> 00:39:47.492 I'm not sure exactly what the terminology was chosen for, but
00:39:47.492 --> 00:39:48.336 that's what it is.
00:39:48.686 --> 00:39:49.986 They're called target carts.
00:39:50.866 --> 00:39:51.506 Umm.
00:39:52.356 --> 00:39:57.623 And so once it has done that, we can then get shipping rate
00:39:57.623 --> 00:40:02.626 quotes for the target carts that are actually shippable.
00:40:03.056 --> 00:40:06.939 So here's rate quotes for shipping this uh exhaust pipe
00:40:06.939 --> 00:40:10.476 thingy to the office address that I chose earlier.
00:40:10.786 --> 00:40:12.586 It's kind of expensive because it's a giant pipe.
00:40:13.456 --> 00:40:13.886 Uh.
00:40:13.896 --> 00:40:17.578 And then here's shipping rate quotes for shipping the wallet
00:40:17.578 --> 00:40:18.906 to my my home address.
00:40:18.966 --> 00:40:22.296 It's I'm pretty cheap because it's a wallet.
00:40:23.336 --> 00:40:28.074 UM, so yeah, and then you can see finally up here again non
00:40:28.074 --> 00:40:29.496 shippable product.
00:40:30.546 --> 00:40:34.837 But if we look at this, analyze current cards targets and look
00:40:34.837 --> 00:40:39.264 at the preview, we can actually see that it generated 4 carts or
00:40:39.264 --> 00:40:41.716 return I should say return 4 carts.
00:40:42.076 --> 00:40:45.459 You may be wondering why it returned four when intuitively
00:40:45.459 --> 00:40:47.466 you can think that we only have 3.
00:40:47.476 --> 00:40:50.086 Here we have the non shippable.
00:40:50.096 --> 00:40:52.975 We have shipping to my house or the office and the shipping to
00:40:52.975 --> 00:40:53.386 my house.
00:40:53.536 --> 00:40:57.901 So either for the answer is the first one and this result is
00:40:57.901 --> 00:41:02.266 always the actual cart that was analyzed, so type name cart.
00:41:02.736 --> 00:41:07.371 But then if we look at the follow up carts, this one you
00:41:07.371 --> 00:41:12.657 can see is nothing to ship true and in the sales items we'll see
00:41:12.657 --> 00:41:17.699 that it is the Adobe design and web premium and it has a type
00:41:17.699 --> 00:41:22.416 key of target grouping dash and then this Jason BLOB that
00:41:22.416 --> 00:41:27.133 describes the target key that split this one into its own
00:41:27.133 --> 00:41:27.946 card, umm.
00:41:28.566 --> 00:41:30.296 And then again, we jump down to here.
00:41:30.826 --> 00:41:35.626 This one has the uh the exhaust pipe.
00:41:36.536 --> 00:41:40.066 That one is a different target grouping key.
00:41:40.116 --> 00:41:46.936 As you can see umm from the original one and.
00:41:50.476 --> 00:41:55.426 Yeah, that's that's the the main part of that.
00:41:55.856 --> 00:41:59.571 And so then the next step in the front end is it grabs the
00:41:59.571 --> 00:42:03.538 results here, so that are not the normal cart and that are not
00:42:03.538 --> 00:42:04.546 nothing to ship.
00:42:04.656 --> 00:42:07.746 And then it calls to get shipping rate quotes for those
00:42:07.746 --> 00:42:10.946 which it then displays as we select each one of these, it
00:42:10.946 --> 00:42:12.326 applies them to the cart.
00:42:12.396 --> 00:42:14.396 We can kind of see what it's trying to do here.
00:42:14.636 --> 00:42:18.121 It's calling current CART shipping rate quotes apply, we
00:42:18.121 --> 00:42:22.157 pass on the ID of the rate quote we selected and the type name of
00:42:22.157 --> 00:42:25.826 the cart we're applying it to and it says action succeeded.
00:42:25.836 --> 00:42:26.266 True.
00:42:26.336 --> 00:42:27.086 So it said.
00:42:27.096 --> 00:42:28.106 Yep, we're good.
00:42:28.156 --> 00:42:30.316 We set that, then we reload that cart.
00:42:31.406 --> 00:42:32.536 We look at the results.
00:42:32.546 --> 00:42:36.650 It should then have a selected true rate quote right here of
00:42:36.650 --> 00:42:37.996 the ID we passed in.
00:42:38.586 --> 00:42:39.536 Fantastic.
00:42:39.686 --> 00:42:43.299 So now we've said that for this cart we're using this rate quote
00:42:43.299 --> 00:42:45.356 for this cart, we're using this one.
00:42:45.766 --> 00:42:48.076 I need that exhaust pipe in my office.
00:42:48.156 --> 00:42:51.106 I want it on my desk by tomorrow as they say.
00:42:52.196 --> 00:42:52.876 Umm.
00:42:53.276 --> 00:42:55.276 So I'm gonna pick some expensive shipping.
00:42:56.696 --> 00:42:57.186 Cool.
00:42:57.776 --> 00:43:01.212 On the payment, we load up the wallet, choose a billing
00:43:01.212 --> 00:43:04.526 address, just make it office, I guess doesn't matter.
00:43:05.536 --> 00:43:06.676 I'm gonna use credit card.
00:43:07.616 --> 00:43:12.352 Uh, and it's just a test card number, and at this point we've
00:43:12.352 --> 00:43:15.026 generated all of the target cards.
00:43:15.116 --> 00:43:18.226 We've selected a billing contact.
00:43:18.316 --> 00:43:21.442 We have the shipping contact set, we have the rate quote
00:43:21.442 --> 00:43:21.936 selected.
00:43:22.216 --> 00:43:25.408 We have a card that we're gonna pay the balance with, so
00:43:25.408 --> 00:43:28.992 everything that we've needed to figure out for this to work has
00:43:28.992 --> 00:43:32.464 been figured out and we can just submit the order, which then
00:43:32.464 --> 00:43:35.712 like I said earlier, calls process, current cards, target
00:43:35.712 --> 00:43:38.176 orders and unfortunately fails immediately.
00:43:38.686 --> 00:43:41.102 Like I said, there's there's bugs we need to fix in core
00:43:41.102 --> 00:43:41.526 right now.
00:43:42.526 --> 00:43:46.938 Umm, so unfortunate that that didn't work, but you get the
00:43:46.938 --> 00:43:47.536 picture.
00:43:47.606 --> 00:43:51.717 It runs that and then that goes and loads up those target carts
00:43:51.717 --> 00:43:55.636 and does all of the fun stuff that it needs to do to jitter.
00:43:55.646 --> 00:43:57.396 Rate target orders from them.
00:44:00.146 --> 00:44:01.566 Apologies, I'm tired.
00:44:02.296 --> 00:44:04.966 It splits those out into the individual suborders.
00:44:05.916 --> 00:44:08.586 It sends all the emails, processes, payment, et cetera.
00:44:08.996 --> 00:44:11.366 Not all of that is happening in the order I set it.
00:44:11.456 --> 00:44:13.616 Processing payment happens before anything else.
00:44:16.126 --> 00:44:17.736 But anyway.
00:44:17.936 --> 00:44:22.196 So umm yeah.
00:44:25.826 --> 00:44:30.442 That's that's the the basic 10,000 foot view of of what
00:44:30.442 --> 00:44:34.316 actually going through checkout is doing. Umm.
00:44:44.056 --> 00:44:46.846 Is that can actually walk through what's going on in the.
00:44:47.556 --> 00:44:51.104 I don't want to necessarily go too deep into the analyze
00:44:51.104 --> 00:44:54.964 method, because for those of you that I've looked at it, it's
00:44:54.964 --> 00:44:58.637 extremely long and complicated, and that's that's it's own
00:44:58.637 --> 00:45:00.816 special training in and of itself.
00:45:01.866 --> 00:45:05.285 Umm, so I'm going to scroll past the parts that are not as
00:45:05.285 --> 00:45:05.806 relevant.
00:45:07.136 --> 00:45:10.307 I wonder if that control MO thing collapses inside the
00:45:10.307 --> 00:45:13.306 method if I reexpand it, that would be pretty cool.
00:45:13.796 --> 00:45:17.999 As you can see, this is this is 116 hundred line method goes
00:45:14.496 --> 00:45:14.686 Just.
00:45:17.999 --> 00:45:22.201 from line 244 to 1860 which is why I don't want to cover the
00:45:20.096 --> 00:45:20.246 If.
00:45:22.201 --> 00:45:23.786 entire thing right now.
00:45:25.036 --> 00:45:27.959 Yeah, just had a I had an overview of what does that
00:45:25.126 --> 00:45:25.676 Yeah OK.
00:45:27.959 --> 00:45:28.896 method do for us.
00:45:29.356 --> 00:45:29.586 Yeah.
00:45:29.596 --> 00:45:33.922 So this is the method where it actually takes the selected
00:45:33.922 --> 00:45:38.541 destinations and the stores and vendors and brands on products
00:45:38.541 --> 00:45:43.013 and the custom split key that we talked about earlier and it
00:45:43.013 --> 00:45:46.826 actually generates the target carts from here. Umm.
00:45:50.116 --> 00:45:54.506 That's a little bit better, big Ole block a crap.
00:45:54.556 --> 00:45:59.707 OK, so it really starts getting the most relevant down here
00:45:59.707 --> 00:46:01.166 around line 1200.
00:46:02.406 --> 00:46:04.996 This is where a lot of this stuff is just set up.
00:46:05.126 --> 00:46:08.415 Uh, that is not as important to to go through right now, but
00:46:08.415 --> 00:46:10.356 this is where stuff gets important.
00:46:10.366 --> 00:46:13.166 We start iterating over the sales items on the original
00:46:13.166 --> 00:46:14.666 cart, so this is my full cart.
00:46:17.096 --> 00:46:22.543 And then we roll through here and start figuring things out on
00:46:22.543 --> 00:46:23.926 uh, the product.
00:46:23.936 --> 00:46:25.256 So we want to load the full product.
00:46:27.896 --> 00:46:28.116 Umm.
00:46:30.876 --> 00:46:33.486 It's like I can't get a good yawn out, so I just keep doing
00:46:33.486 --> 00:46:33.616 it.
00:46:34.746 --> 00:46:35.536 Uh.
00:46:35.786 --> 00:46:40.216 Anyway, so we load up the product, we load the sales item.
00:46:41.506 --> 00:46:45.276 Uh, under the product, we reload the targets for that sales item.
00:46:47.106 --> 00:46:49.726 We do some fun stuff in here.
00:46:52.296 --> 00:46:53.036 Hang on, I'm reading.
00:46:57.926 --> 00:46:59.326 So we load up the CART item.
00:47:00.786 --> 00:47:04.176 Uh, we've apparently validated the product ID.
00:47:04.186 --> 00:47:09.115 I'm not sure in what way, but we've apparently validated it up
00:47:09.115 --> 00:47:14.122 here somewhere, so we're gonna set that back onto the cart item
00:47:14.122 --> 00:47:19.128 and then associate its targets to it and then save those to the
00:47:19.128 --> 00:47:21.006 database, which is fine.
00:47:21.916 --> 00:47:25.072 Uh, and then we clear the targets completely right here
00:47:25.072 --> 00:47:26.876 and then reload them afterwards.
00:47:26.886 --> 00:47:32.306 Since we've potentially modified them here, umm and then, uh, set
00:47:32.306 --> 00:47:37.234 those reloaded targets right here and then finally the most
00:47:37.234 --> 00:47:38.466 important part.
00:47:40.836 --> 00:47:48.906 For each target on the UM on this specific sales item.
00:47:50.126 --> 00:47:52.961 Uh, so there could be multiple and I'll talk about that in a
00:47:52.961 --> 00:47:53.286 minute.
00:47:53.386 --> 00:47:57.456 But for each target we create the target grouping key.
00:47:58.406 --> 00:48:01.382 This is the key like I mentioned earlier that I actually dictates
00:48:01.382 --> 00:48:03.636 which products end up in the same order together.
00:48:04.446 --> 00:48:08.819 All of the products where the type key, the store brand
00:48:08.819 --> 00:48:09.366 vendor.
00:48:11.596 --> 00:48:13.866 The origin warehouse.
00:48:13.936 --> 00:48:16.714 Nothing to ship customs split key and destination contact
00:48:16.714 --> 00:48:18.246 where all of those are the same.
00:48:18.256 --> 00:48:20.606 Those products will end up in the same cart together.
00:48:20.776 --> 00:48:23.141 If any one of these is different, it doesn't matter if
00:48:23.141 --> 00:48:25.678 six are the same and one is different, they will end up in
00:48:25.678 --> 00:48:26.366 different carts.
00:48:26.376 --> 00:48:30.180 Because of that, the intention is that each individual custom
00:48:30.180 --> 00:48:34.046 value dictates a unique cart and therefore a unique sub order.
00:48:34.996 --> 00:48:35.536 Umm.
00:48:37.286 --> 00:48:41.389 So umm, this is a really important place in the code
00:48:41.389 --> 00:48:41.776 here.
00:48:42.186 --> 00:48:46.238 This is where it actually does the the splitting out of the key
00:48:46.238 --> 00:48:50.291 and what you can see is that it creates a key and then converts
00:48:50.291 --> 00:48:54.406 to a string which is actually an overridden in a special way for
00:48:54.406 --> 00:48:55.926 the target grouping key.
00:48:57.356 --> 00:49:01.506 Uh, and then we have there.
00:49:01.516 --> 00:49:02.656 What is up with me?
00:49:06.236 --> 00:49:09.346 Umm we have this check here.
00:49:09.496 --> 00:49:12.966 We have a target groupings key which is a dictionary where the
00:49:12.966 --> 00:49:16.271 key is the target grouping key string that we're generating
00:49:16.271 --> 00:49:19.355 here, and the value is the destination ID and a list of
00:49:19.355 --> 00:49:20.016 sales items.
00:49:21.546 --> 00:49:27.276 So what we do here is we check do we already have this key?
00:49:27.346 --> 00:49:30.619 If we do, we not already have this key in the dictionary or do
00:49:30.619 --> 00:49:33.736 we have the key but the sales items on it as empty or null?
00:49:34.226 --> 00:49:37.899 If that is the case, then we just new up a new one and either
00:49:37.899 --> 00:49:41.632 way, if it doesn't already have it or it has an invalid setup,
00:49:41.632 --> 00:49:45.009 then we initialize a valid target grouping based on that
00:49:45.009 --> 00:49:45.246 key.
00:49:46.076 --> 00:49:49.321 Otherwise, if it's already in this dictionary, we add this
00:49:49.321 --> 00:49:52.786 sales item to the items that are part of this target grouping.
00:49:53.776 --> 00:49:58.668 Umm so that is how those all work once one of them generates
00:49:58.668 --> 00:50:02.196 a target key and adds it to the dictionary.
00:50:02.206 --> 00:50:05.275 If something else is shipping to the same place and all the other
00:50:05.275 --> 00:50:08.252 parameters match, then it'll get added that sales item will get
00:50:08.252 --> 00:50:09.926 added to that same target grouping.
00:50:11.236 --> 00:50:15.936 Umm, so this is a pretty central piece of the code right here.
00:50:16.976 --> 00:50:17.676 Umm.
00:50:18.536 --> 00:50:22.743 And then we roll down a little bit further and then starting on
00:50:22.743 --> 00:50:26.818 line 1300, this is the logic that actually takes those target
00:50:26.818 --> 00:50:30.959 groupings and generates the the target CART models themselves,
00:50:30.959 --> 00:50:32.536 the target CART records.
00:50:35.096 --> 00:50:40.334 And one important note is that it doesn't exclusively, always
00:50:40.334 --> 00:50:41.686 create new ones.
00:50:41.696 --> 00:50:45.324 It will update existing ones if they already exist and have that
00:50:45.324 --> 00:50:46.496 target group and key.
00:50:48.306 --> 00:50:50.546 So we iterate over these.
00:50:51.486 --> 00:50:52.146 Umm.
00:50:53.026 --> 00:50:53.946 Move empty carts.
00:50:54.966 --> 00:50:55.666 Umm.
00:50:56.546 --> 00:51:00.043 And then we go in and we could ignore the as admin part for
00:51:00.043 --> 00:51:00.276 now.
00:51:00.286 --> 00:51:04.141 So down here we find a we find the target grouping cart if it
00:51:04.141 --> 00:51:08.058 already exists based on the user account, brand, etcetera blah
00:51:08.058 --> 00:51:12.037 blah blah and the type key which is the target grouping key and
00:51:12.037 --> 00:51:15.705 we like I said, we sell that target dash grouping dash and
00:51:15.705 --> 00:51:16.886 then the JSON BLOB.
00:51:17.216 --> 00:51:18.306 That's where this is coming from.
00:51:18.516 --> 00:51:19.716 So we tried to find this card.
00:51:20.786 --> 00:51:24.729 Umm, if the target CART model is null then that means we don't
00:51:24.729 --> 00:51:27.796 already have a target for this particular split.
00:51:28.606 --> 00:51:31.474 Umm, there's nothing in the in the database that exists for
00:51:31.474 --> 00:51:32.096 this already.
00:51:32.106 --> 00:51:33.396 So we're gonna make a new one.
00:51:33.786 --> 00:51:38.576 So we get an instance of ichart model active is true.
00:51:38.636 --> 00:51:42.817 Set the created date time stamp and then we set do create the
00:51:42.817 --> 00:51:43.356 true uh.
00:51:43.856 --> 00:51:47.205 However, uh, so let's let's pretend that this part doesn't
00:51:47.205 --> 00:51:50.782 happen right now, and that we that we did successfully read an
00:51:50.782 --> 00:51:53.166 existing target card out of the database.
00:51:53.656 --> 00:51:56.590 Well, if it's not active, then we wanna mark it as active and
00:51:56.590 --> 00:51:59.382 say that we need to update if the session ID doesn't match
00:51:59.382 --> 00:52:01.606 because maybe this person got halfway through.
00:52:01.616 --> 00:52:04.013 Check out on a different computer and then move to
00:52:04.013 --> 00:52:06.926 another one or even a different browser on the same computer.
00:52:06.996 --> 00:52:07.216 Etcetera.
00:52:07.916 --> 00:52:10.886 Umm, if the user's ID doesn't match, I don't.
00:52:10.896 --> 00:52:13.901 I don't know why that wouldn't would happen, but I guess it
00:52:13.901 --> 00:52:16.406 could if the account ID if the brand ID etcetera.
00:52:16.896 --> 00:52:19.342 It basically determines if there's anything on the model
00:52:19.342 --> 00:52:20.586 that doesn't currently match.
00:52:20.596 --> 00:52:24.542 Then we need to update this then existing model instead of
00:52:24.542 --> 00:52:25.946 creating a new model.
00:52:26.816 --> 00:52:30.806 Umm this is handling setting the type ID with the target
00:52:30.806 --> 00:52:31.436 grouping.
00:52:31.506 --> 00:52:34.045 Again, you can see that target dash grouping dash and then the
00:52:34.045 --> 00:52:34.206 key.
00:52:35.356 --> 00:52:41.836 Umm, the status and the state are you getting set here?
00:52:42.066 --> 00:52:50.174 Then we grab up the E the current sales items based on the
00:52:50.174 --> 00:52:50.586 uh.
00:52:50.596 --> 00:52:54.352 If it was an existing cart, so like let's assume that it's not
00:52:54.352 --> 00:52:55.366 an existing cart.
00:52:55.376 --> 00:52:56.836 This is gonna be an empty list right here.
00:52:58.016 --> 00:52:58.676 Umm.
00:52:59.096 --> 00:53:03.393 And then this next list right here is the sales items that we
00:53:03.393 --> 00:53:07.136 have determined will be part of this target grouping.
00:53:07.446 --> 00:53:08.876 So this will be the group.
00:53:09.066 --> 00:53:13.317 This will be the new sales items that were determined by those
00:53:13.317 --> 00:53:15.746 split keys way up here, right here.
00:53:16.926 --> 00:53:18.606 Adding this to the sales items right here.
00:53:21.436 --> 00:53:23.386 And then down back where we were.
00:53:28.956 --> 00:53:30.306 Sorry, I got a little bit lost.
00:53:31.016 --> 00:53:33.586 I went too far. Umm.
00:53:37.786 --> 00:53:38.586 Hello way too far.
00:53:38.596 --> 00:53:39.096 There we go.
00:53:39.726 --> 00:53:41.396 So now we're back down here.
00:53:41.546 --> 00:53:44.808 We've got the current items and we have the current items that
00:53:44.808 --> 00:53:47.914 were read out of the database with this current target cart
00:53:47.914 --> 00:53:50.606 and the items we need to put into this target cart.
00:53:51.846 --> 00:53:53.946 Make one here and we.
00:53:56.646 --> 00:54:00.170 Effectively, we find the original CART item that matches
00:54:00.170 --> 00:54:04.127 to this, we find the target on that original cart and determine
00:54:04.127 --> 00:54:07.898 the quantity that we care to actually put on this line item,
00:54:07.898 --> 00:54:09.876 and then we add it to the thing.
00:54:09.886 --> 00:54:13.523 We can also see if we already have it and if we don't, then we
00:54:13.523 --> 00:54:14.216 will set it.
00:54:14.586 --> 00:54:18.899 Otherwise we go on and we update the quantities we set all these
00:54:18.899 --> 00:54:22.416 things and we set the flag for do, update or create.
00:54:22.906 --> 00:54:25.955 So that's updating the existing target order I or target sales
00:54:25.955 --> 00:54:28.326 items that we may have read out of the database.
00:54:28.716 --> 00:54:31.777 This next four each actually creates the ones that we didn't
00:54:31.777 --> 00:54:34.536 read out of the database, so it adds them to the cart.
00:54:34.586 --> 00:54:37.306 So this is in the case of somebody went part way through
00:54:37.306 --> 00:54:39.978 checkout, went back to the catalog, added something and
00:54:39.978 --> 00:54:41.266 then went back to checkout.
00:54:41.656 --> 00:54:44.977 That could happen, or obviously in the case of a first time
00:54:44.977 --> 00:54:48.519 going through checkout at all, it will run this this loop won't
00:54:48.519 --> 00:54:52.116 have anything up here, but this one will actually create all the
00:54:52.116 --> 00:54:55.160 sales items, so we go over the original items for this
00:54:55.160 --> 00:54:58.812 grouping, determine the quantity from the original target, create
00:54:58.812 --> 00:55:02.299 these with certain feature flags to make sure that we only set
00:55:02.299 --> 00:55:04.236 certain things if they need to be.
00:55:05.286 --> 00:55:06.046 Umm.
00:55:07.086 --> 00:55:11.746 And we grab the uh destination contact from the target.
00:55:12.986 --> 00:55:13.736 Uh.
00:55:13.746 --> 00:55:14.846 And you step for something.
00:55:14.856 --> 00:55:17.957 I don't remember what I guess we said it on the new targets or
00:55:17.957 --> 00:55:19.926 copying the targets themselves as well.
00:55:23.286 --> 00:55:27.788 And then finally we add it to the new targets and we add the
00:55:27.788 --> 00:55:30.076 item to the target sales items.
00:55:31.036 --> 00:55:33.996 Umm, collapse some of these extra ones.
00:55:34.366 --> 00:55:35.416 Now we get down here.
00:55:35.426 --> 00:55:39.102 If we need to create the new cart then this is, then we're
00:55:39.102 --> 00:55:41.656 gonna run through here and do the again.
00:55:41.666 --> 00:55:45.714 We can ignore as admin and just create the cart and then we
00:55:45.714 --> 00:55:49.896 attempt to resolve it back out and add it to resulting cards.
00:55:50.686 --> 00:55:55.350 If we need to update, then we, uh, do bit of extra logic to
00:55:55.350 --> 00:56:00.091 check if the total target cart quantity is 0 or less than or
00:56:00.091 --> 00:56:00.946 equal to 0.
00:56:00.956 --> 00:56:03.948 Then we can just delete it because we removed all of the
00:56:03.948 --> 00:56:06.626 active items from that cart from that target cart.
00:56:06.636 --> 00:56:10.251 So maybe this could happen in the case that a user goes
00:56:10.251 --> 00:56:11.606 through checkout and.
00:56:13.586 --> 00:56:17.207 Chooses to ship a product to their home and then says Ohh
00:56:17.207 --> 00:56:18.456 never mind restarts.
00:56:18.466 --> 00:56:22.621 Checkout and ships it to a different place then that one of
00:56:22.621 --> 00:56:24.976 those sales items could be empty.
00:56:24.986 --> 00:56:26.196 There could be none of them.
00:56:26.986 --> 00:56:30.856 Uh collapse that so?
00:56:30.866 --> 00:56:33.376 Then we go in here and we call carts update.
00:56:33.586 --> 00:56:36.676 We resolve the cart and again we add it to the resulting cards.
00:56:37.496 --> 00:56:38.106 Umm.
00:56:39.616 --> 00:56:43.120 And that is in the summer of doing the creation or updating
00:56:43.120 --> 00:56:43.646 of carts.
00:56:45.116 --> 00:56:48.026 And then finally you can show the end of the method.
00:56:48.036 --> 00:56:51.637 Here we update the original cart with any changes we've made to
00:56:51.637 --> 00:56:51.806 it.
00:56:51.816 --> 00:56:53.646 We reload set original cart.
00:56:53.996 --> 00:56:57.462 We make sure that the resulting carts count or we check the
00:56:57.462 --> 00:56:59.426 resulting cards count being zero.
00:56:59.716 --> 00:57:02.989 If it's zero, then we add the original cart to it and then we
00:57:02.989 --> 00:57:06.316 wrap it in a failing response that says no cards are available
00:57:06.316 --> 00:57:08.586 after analysis, which should never happen.
00:57:08.596 --> 00:57:11.052 If you have any products in your cart, they should end up in some
00:57:11.052 --> 00:57:11.796 kind of target cart.
00:57:12.836 --> 00:57:16.926 Otherwise the logic didn't work, so that's a failure.
00:57:19.186 --> 00:57:23.348 And then finally, we throw the discounts on to the original
00:57:23.348 --> 00:57:27.649 cart so that those map out, uh or we run the discount logic I
00:57:27.649 --> 00:57:31.880 guess and then we reload that cart one more time and then we
00:57:31.880 --> 00:57:34.516 add it to the beginning of the array.
00:57:34.526 --> 00:57:37.647 Like I said, the first the first card that comes back in the
00:57:37.647 --> 00:57:40.564 response on the analyze is always the original cart that
00:57:40.564 --> 00:57:43.839 was analyzed and then we wrapped that in a passing CEFAR action
00:57:43.839 --> 00:57:45.016 response and that's it.
00:57:45.526 --> 00:57:47.386 That's target order analysis.
00:57:59.886 --> 00:58:00.146 Uh.
00:58:02.396 --> 00:58:04.646 It's pretty complicated.
00:58:02.806 --> 00:58:03.436 Ah.
00:58:05.466 --> 00:58:07.836 She it's super complicated.
00:58:08.226 --> 00:58:10.136 I get these in architecture process.
00:58:10.146 --> 00:58:12.016 I'll get these custom.
00:58:12.086 --> 00:58:15.794 You know, they would these custom check out workflows and
00:58:15.794 --> 00:58:19.501 some of them don't even seem like you know there would be
00:58:19.501 --> 00:58:20.716 that big of a lift.
00:58:20.726 --> 00:58:25.473 But even finding the place to where you want to inject your
00:58:25.473 --> 00:58:26.976 logic is difficult.
00:58:27.646 --> 00:58:31.519 It can be, Yep, 100% so hopefully hopefully going
00:58:29.716 --> 00:58:30.046 Yeah.
00:58:31.519 --> 00:58:36.088 through some of this kind of identifying the the the major
00:58:36.088 --> 00:58:40.968 sections has helped a little bit something that could be worth
00:58:40.968 --> 00:58:44.066 doing in a future uh, refactoring here.
00:58:44.816 --> 00:58:49.431 Uh, obviously, besides trying to consult like, break some of this
00:58:49.431 --> 00:58:53.697 out into separate methods so it's not one, one monolith that
00:58:53.697 --> 00:58:58.242 is basically one method for 1800 line file, but it would also be
00:58:58.242 --> 00:59:02.578 to kind of create regions in here where one of the regions is
00:59:02.578 --> 00:59:07.123 just like general setup and then another region is like creating
00:59:07.123 --> 00:59:11.319 target groupings from current CART sales items or something
00:59:11.319 --> 00:59:14.256 and then that's this for each right here.
00:59:14.506 --> 00:59:18.347 And then inside of that, calling attention specifically to if you
00:59:18.347 --> 00:59:21.256 wanna add custom splits, this is where you do it.
00:59:21.266 --> 00:59:24.681 And again, we can even make this an overridable virtual method
00:59:22.306 --> 00:59:22.446 Yeah.
00:59:24.681 --> 00:59:26.036 that creates that string.
00:59:26.266 --> 00:59:30.143 That custom split key if umm, so that if a client project needs
00:59:30.143 --> 00:59:33.536 to override it, it doesn't have to come in here at all.
00:59:33.546 --> 00:59:36.736 It can just override that and do whatever logic, but.
00:59:40.086 --> 00:59:44.789 All that to say then then you know another region down here of
00:59:44.789 --> 00:59:48.969 creating target carts from target groupings or creating
00:59:48.969 --> 00:59:53.373 slash updating target carts from target groupings and then
00:59:53.373 --> 00:59:58.001 finally down here toward the very end doing the saving target
00:59:58.001 --> 01:00:02.704 carts and validating results, validating and returning results
01:00:02.704 --> 01:00:07.109 or something like basically breaking it down into like the
01:00:07.109 --> 01:00:11.513 four or five major steps that happen inside of that uh, so
01:00:11.513 --> 01:00:11.886 that.
01:00:15.576 --> 01:00:18.748 So that's a little bit easier to know where you need to go if you
01:00:18.748 --> 01:00:19.806 know that you need to.
01:00:20.856 --> 01:00:24.341 Maybe fix a bug related to some data that doesn't exist on a
01:00:24.341 --> 01:00:25.026 target cart.
01:00:25.116 --> 01:00:28.278 Then you can find the region that says creating, updating
01:00:28.278 --> 01:00:30.786 target carts spaced on target groupings like.
01:00:30.796 --> 01:00:33.786 That's probably where I need to go jump right into that.
01:00:34.756 --> 01:00:38.333 If you know that you want to add custom splits, then there's the
01:00:38.333 --> 01:00:41.525 one that says creating creating target groupings based on
01:00:41.525 --> 01:00:42.406 splitting logic.
01:00:42.966 --> 01:00:44.696 That sounds like a good place to start.
01:00:45.126 --> 01:00:45.816 That kind of thing.
01:00:45.826 --> 01:00:49.146 So possible good future future.
01:00:51.236 --> 01:00:54.706 Uh, what do you call that clean up?
01:00:57.236 --> 01:00:58.316 Formatting cleanup.
01:01:01.706 --> 01:01:05.546 She did everything in a succinct manner, so it's easier to read
01:01:05.546 --> 01:01:07.466 and understand what's happening.
01:01:06.066 --> 01:01:06.266 Yep.
01:01:09.106 --> 01:01:09.426 Umm.
01:01:09.216 --> 01:01:09.926 OK.
01:01:10.136 --> 01:01:12.666 Um, we could probably shut the door.
01:01:12.676 --> 01:01:13.206 Uncheck out.
01:01:13.216 --> 01:01:15.876 I guess we got about 30 minutes left.