I have a question about the Square API
I need to get a list of items purchased by by customers.
I see there is an order endpoint, but I need order IDs to get order information.
My transactions dont seem to have any order numbers.
where can I find the order ids belonging to my customers?
In order to do this, you'll need to utilize multiple endpoints.
First, V2 ListTransactions will return an array of transactions, and if a customer is associated with a transaction, there will be a customer_id field. However, if you did not attach an order to the transaction, then there will not be an order_id present.
Just to clarify: in order to have an order_id you must do CreateOrder prior to calling Charge. This will create an order, which you can attach to a transaction to have itemizations (order_id is an optional parameter in the Charge endpoint). See the first reference link for more details.
If you do not have an order_id, you will need to then use V1 RetrievePayment (note that the id parameter for RetrievePayment is the tender_id not the transaction_id from V2 transaction). This endpoint will provide you with itemizations when you don't have an order.
References:
https://docs.connect.squareup.com/cookbook/orders-and-transactions
https://docs.connect.squareup.com/api/connect/v1#get-payments
Related
What is the best way to list all transactions per customer_id? I can't find an endpoint for this.
I've tested with https://connect.squareup.com/v2/locations/{{location_id}}/transactions/customer/{{customer_id}}
but this clearly doesn't work. I could always look through all transactions for this particular location, but if there are hundreds/thousands of transactions, bringing all those in makes no sense, and then filter thought those to get customer_id specific transactions.
TIA Jaana
You cannot find an endpoint for this because there is not one. You should list all transactions and then iterate through each one to find all the transactions for each customer_id you are interested in.
I see that the Sku fields are duplicated in the Product table.
When creating a product in BigCommerce from info in an independent POS system:
If there is only one Sku, do we create a Sku record in addition to the Product record?
If there are two Skus associated with an image and description, do we put the info for the first Sku in the product record and create a Sku record for only the second product, or do we create a sku record for each of the 2 skus?
In another ecommerce solution, each product has at least one variant (the default variant), and if there are 2 variations, then there are 2 variant records. It seems as though the Sku table is like what I am familiar with for variants. But BigCommerce may handle this differently and put the data for the default "variation" in the product record, and only use Sku records when there is more than one variation.
In BigCommerce (and some other systems), SKUs are considered unique identifiers. In BigCommerce, you can only have unique SKU once (no duplicating) and a unique product name (also not able to be duplicated).
SKUs in BC correspond to variants/combinations of options that make up a variant product. There is a default "parent product" or simple product associated with a parent SKU (if any) and then variants generally have unique SKUs, but aren't required to have SKUs.
If a product has variants, you do create additional skus in addition to the parent sku/product.
You can get a little bit more clarity through some of the API documentation for our V3 catalog api
I'm a bit confused about the origin of entities in an environment which takes advantage of CQRS & Event Sourcing. To make my question clear let's take the following well known example of a web shop:
You may model an order as an aggregate root. An order accepts order lines which themselves are defined by a product and a quantity.
Since an order line is an entity which is constructed during the order process itself there is still the notion of a product which seems to be an entity as well. But where does the product or even the catalog of products come from? In my opinion there is no such a thing like a product aggregate root in the bounded context of an order. How then would the order context know about product entities? Are they maintained in another bounded context and somehow materialized in the read store of the order context?
In the BC that contains Order it might indeed be the case that Product, as part of an OrderLine, is a value object, consisting of values such as ProductId, Name etc.
The order context does not need to know about product entities, since order lines usually only contain simple value-only properties (productId/SKU, a name, quantity and price-per/item). Therefore, Order could provide a function such as
void addOrderLine(ProductId productId, String productName, BigDecimal pricePerItem, int quantity).
It's actually not relevant for the "Order"-BC where these values for productId, productName etc originate from.
In practice, however, it's probably very likely that these values can be obtained from another bounded context, say the "Product"-BC, which is responsible for inventory management etc.
It's quite common to let the UI orchestrate these BCs:
The UI (a web shop for customers, for example) loads the products and their prices from the "Product-BC"
The user places products into a shopping basket (let's assume for simplicity that this is also the "Order-BC"). For, the UI fires commands such as AddToShoppingBasketCommand(productId, productName, quantity, price) which are handled by the "Order"-BC.
When the user wants to place the order for the current shopping basked, it fires a PlaceOrderCommand.
The command handler for PlaceOrderCommand takes the current shopping basket and constructs a corresponding Order; all it needs are, for each product, the respective properties of products that were already listed in the shopping basket (and were originally in the AddToShoppingBasketCommand). Note that it does not need to know about the notion of a Product entity from the Product-BC.
My Table looks like something below
Id | Customer_number | Customer_Name | Customer_owner
I want to insert Customer_Number as a sequence specific to Customer_owner
that is 1,2,3,.... for Customer_owner X and 1,2,3,... Customer_owner Y.
To get the Customer_number I can use following SQL
SELECT COUNT(*) FROM Customer where Customer_owner='X'
My question is that are there any performance impact. Specially for a table with 100,000 records.
Are there any better alternatives?
In terms of performance, I would suggest not adding another column to Customers, for various reasons:
The need to update all of owner's A related customers when adding a customer with the owner A, same goes for removing.
Number of clients is Repeated multiple times - taking up more space and thus (generally) slowing execution.
No real usage to link Number of clients to client's owner via another column for a record describing a single customer.
and many more explanations..
The correct normal form would be having 2 tables:
Customers(Cust_id,Cust_name,Cust_Owner_id)
2.a. Owners (Owner_id,Owner_name,NumberOfCustomers)
OR
2.b. Owners (Owner_id,Owner_name) and have NumberOfCustomers be auto calculated upon Querying.
Edit:
Since you want to display all the customers for a single owner, I assume that is your main usage, you should add a cluster index on Cust_Owner_id . Then , when querying, performance would be good since it will have the benefits of clustering according to your desired data.
Read more about clustering here: Clustered Index
Edit 2:
I've just realized your intent via latest comments, but the solution still remains, I would add, specific to your issue, that I don't recommend you should store the number for all of one owner's customers, instead, keep a SUBSCRIBED DATE Column in Customers table, and when querying, decide of the customer number upon display.
If you want however that number to be permanent (any by that the order 1,2,3,..n will probably break, since customers can be removed), simply use the Customer_Id, since it is already unique.
You can calculate Customer_Number on the fly when you need it:
select c.*, row_number() over (partition by Customer_Owner order by id) as CustomerNumber
from Customer c
This is a much safer approach than trying to store and maintain the number, which can be affected by all sorts of updates into the system. Imagine the fun of changing the numbering when an existing record changes it ownership, for instance.
If you only need unique numbering in the UI you could just assign the numbers in the UI. If you go that route you need to make sure you always retrieve customers in the same order, so add an ORDER BY Id, Or, do what Gordon Linoff suggests.
Just to be clear, I'm going to store my shopping cart in a database.
It's just that I would like information regarding the details on how to store it exactly.
I have the following structure for my shopping cart and orders:
First of all, is this technically a good approach?
A product is added to a cart with the sessionID, date and amount.
Do I add another table or rename the table given that it's not really carts but more collection of products from different carts?
When a user wants to order his products we place them in the order_items table. When the user selects purchase his order is placed in the orders table.
Is this a good approach, are there better ones?
P.S.: the user doesn't need to be registered to place an order.
What I usually do is have an intermediate table, something like ProductsInCart, with three columns, ProductID, CartID, and Quantity. ProductID keys into Products, CartID keys into Carts, and quantity is simply a positive integer.