diff --git a/docs/square-order.md b/docs/square-order.md index 14ff861a..d25d9284 100644 --- a/docs/square-order.md +++ b/docs/square-order.md @@ -69,9 +69,59 @@ See comment above - fixed and very cool. Didn't make it to production in time, my apologies, I have revalidated this now. +### If schedule_type is 'SCHEDULED', partner must populate pick_up time and prep_time_duration + +> It is scheduled within MyOrderApp Interface, but there is no pick_up time and +> prep_time duration that appears in the API call of the order + +I have added prep_time_duration for scheduled orders. Specifically, in my FAQ I +state that all "pickup lead time durations" are by default 15 minutes, and that +this is configurable upon submission of a support ticket. I plan on making this +merchant configurable soon after launch. + +## Customers + +For items: + +- Create customer in partner app creates customer in Square (P1) +- Delete customer in partner app deletes customer in Square +- Update customer in partner app updates customer in Square +- All Partner/Square common customer fields are synced between systems + +> Partner is not created in partner app but it is created in Square - made an +> order with a customer ‘Amit Test’ but the customer does not appear in the +> MyOrderApp Interface. Within customers, the list is empty + +When you log in as a Seller in the "MyOrderApp for Sellers" dashboard, +it automatically passes your authentication information to the created +application, which in turn automatically creates a MyOrderApp Customer +(which also creates a Square Customer) on the Merchant's behalf. + +That is to say that there is a User who is both a Merchant and a Customer. + +In the Customer list on MyOrderApp, I exclude the Customer that has the same +User ID as the current Merchant. + +In order to test the create/read/update/delete functions of MyOrderApp seperate +from the Merchant, because even if you hit "delete" while on the Seller +dashboard, it will just automatically create a new one, you need to navigate +in a separate browser or browse anonymously. This is because the authentication +information is securely stored in cookies for persistance. + +If you test it in a new browser, you should find that you can create a Customer, +perform any operations, and then delete that customer, and as long as you do not +use the same email as the Merchant account, that Customer will be visible on the +Dashboard, and regardless of whether they're the Merchant or not, that Square +is kept up to date on the Customer information. + ## Orders -### Order fulfillment state pushed as PROPOSED & Order can move through all states +For items: + +- Order can move through all states +- If partner is closing Orders in Square, partner must mark Order and Order + Fulfillment as 'COMPLETE' +- Order fulfillment state pushed as PROPOSED > "For two test orders, I made one that was pickup ASAP and another that was to > be picked up in the future. For the pickup in the future (Using Order ID @@ -107,40 +157,58 @@ Order IDs: - 1HhiNZC3ZkqCifO5yacO2YBwjH6YY - tHpvzLtGBxfq6TrPEF16Lh6I4pFZY -When a Customer taps the pay button, I mark these draft orders as cancelled -and open a new order with the final details and post the payment for that order. +When you tapped the pay button, I marked these DRAFT Orders as CANCELED and +created a new OPEN Order with the final details and posted the payment for that +Order. -First, from the documentation, the reason that I cancel the order instead of deleting it: +The reason I did this was I found that if something goes wrong with updating the +Order, my app and Square can get into a state where the Customer is stuck, +because Orders may only have and be created with one fulfillment object. +However, assuming nothing goes wrong with the UpdateOrder call, this is safe. -> In the current implementation, the Orders API doesn't provide an endpoint to -> delete an order. However, Square reserves the right to delete DRAFT orders -> that haven't been updated in 30 days. +All that is to say: **I've changed the behavior to be what I think is more +conventional, try it now.** -Second, you ask "why have DRAFT orders?" The reason is that Customers can change -information about the order while they're building it. Specifcally, customers can change -the location and fulfillment information. The API does not allow Orders to have -these fields updated. +### Sync an item with a location price override, correct price must be shown for location chosen in partner platform (P1) -### If partner is closing Orders in Square, partner must mark Order and Order Fulfillment as 'COMPLETE' +> I set the test item "Croissant" with a location price override of $0.50 for my +> New York location. While the price is updated when selecting 'Check out,' in +> the interface it still shows the old price. Small UI fix to ensure that +> sellers see the correct price per location + +If a Merchant updates their Catalog while a Customer has a Draft Order with +an updated object, they will see stale information until they update the Order. +However, given that the price at the time of Order creation is a valid price, +if they do not update the Order and they checkout, they will have the original +price, which I believe is the correct behavior. When they subsequently refresh +their catalog by either pulling down to refresh, selecting a new location, or +otherwise refreshing the application, they will receive the updated catalog. + +## Future fixes -> No Order Fulfillment Line item for one order but appears on another +For items: -## If partner is closing Orders, partner must send corresponding refund to Refunds API to maintain proper reporting +- Refunds in third-party are pushed to Square via Refunds API +- If partner is closing Orders, partner must send corresponding refund to Refunds API to maintain proper reporting + +With comment: > Do not see refund reporting from Square to MyOrderApp - please add an > indicator of refunds processed in order to maintain proper reporting across > both platforms -## Sync an item with a location price override, correct price must be shown for location chosen in partner platform +And: -> I set the test item "Croissant" with a location price override of $0.50 for my -> New York location. While the price is updated when selecting 'Check out,' in -> the interface it still shows the old price. Small UI fix to ensure that -> sellers see the correct price per location +> While MyOrderApp does not allow refunds within the platform, please at minimum +> add in a status indicator of refunds -## Future fixes +I kindly request that this do not block passing QA. I am happy to implement refund +awareness in the customer and merchant applications, and I've even started it, +but I do not want to do it hastily and make a mistake. -### Refunds in third-party are pushed to Square via Refunds API +### Invalid CVV & Invalid expiration date (P2) -> While MyOrderApp does not allow refunds within the platform, please at minimum -> add in a status indicator of refunds +> Long loading time then eventually get a 400 error (Our servers couldn't handle that) - +> recommend adjusting this wording to be more user friendly + +Similarly, I can commit to having this fixed within a week. diff --git a/src/moa-square/services/orders.service.ts b/src/moa-square/services/orders.service.ts index 187f7b51..c49b63e1 100644 --- a/src/moa-square/services/orders.service.ts +++ b/src/moa-square/services/orders.service.ts @@ -652,6 +652,9 @@ export class OrdersService extends EntityRepositoryService { }`, scheduleType: pickupDateString ? 'SCHEDULED' : 'ASAP', pickupAt: pickupOrAsapDate.toISOString(), + prepTimeDuration: pickupDateString + ? `P${merchant.pickupLeadDurationMinutes ?? '15'}M` + : undefined, recipient: { customerId: customerSquareId, },