SpreeCommerce has an order overview, where it's possible to see all the orders and the states. Each day we open the order overview, and find the completed orders, pack them and ship them to the customer.
However, sometimes we don't have the goods for an order in stock, and want to mark the order as "pending", so we don't open the order each day by mistake.
What's the best way in SpreeCommerce to mark an order as "pending", so we only have to check the pending orders, when we get a new shipment of goods from our supplier?
It would be great, if we could use the state property, because SpreeCommerce allows us to filter orders by their state.
Spree supports inventory tracking as described here:
http://guides.spreecommerce.com/developer/inventory.html
This will allow you to flag a shipment as being backordered:
https://github.com/spree/spree/blob/v2.2.1/core/app/models/spree/shipment.rb#L79-L81
if any of its inventory units are backordered. An order is considered backordered if any of its shipments are considered backordered:
https://github.com/spree/spree/blob/master/core/app/models/spree/order.rb#L193-L195
Your best bets for putting an order in to a back ordered state would be:
Turn on inventory tracking in Spree and keep it up to date through synchronization or manual audits
Extend Spree to override what it means for shipment to be considered backordered and allow this to be set and unset by administrators as stock levels change
Which solution you should choose depends a great deal upon the specifics of your store and how you manage inventory. The specifics of your implementation could make either solution very easy, or very difficult.
Related
I did the amazon personalize deep dive series on youtube. At the timestamp 8:33 in the video, it was mentioned that 'Personalize does not understand negative feedback.' and that any interaction you submit is assumed to be a positive one.
But I think that giving negative feedback could improve the recommendations that we give on a whole. Personalize knowing that a user does not like a given item 'A' would help ensure that it does not recommend items similar to 'A' in the future.
Is there any way in which we can give negative feedback(ex. user doesn't like items x,y,z) to amazon personalize?
A possible way to give negative feedback that I thought of:
Let's say users can give ratings out of 5 for movies. Every time a user gives a rating >= 3 in the interactions dataset, we add an additional interaction in the dataset (i.e we have two interactions saying that a user rated a movie >=3 in the interactions.csv instead of just one). However, if he gives a rating <=2 (meaning he probably doesn't like the movie), we just keep the single interaction of that in the interactions dataset (i.e. we only have one interaction saying that a user rated a movie <=2 in the interactions.csv file)
Would this in any way help to convey to personalize that ratings <=2
are not as important/that the user did not like them?
Negative feedback, where the user explicitly indicates that they dislike an item, is currently not supported as training input for Amazon Personalize. Furthermore, there is currently no way to add weight/reward to specific interactions by event type or event value (see this answer for details).
With that said, you can use impressions with your interactions to indicate items that were seen by the user but that they chose not to interact with. Impressions are only supported by the User-Personalization recipe. From the docs:
Unlike other recipes, which solely use positive interactions (clicking, watching, or purchasing), the User-Personalization recipe can also use impressions data. Impressions are lists of items that were visible to a user when they interacted with (clicked, watched, purchased, and so on) a particular item.
Using this information, a solution created with the User-Personalization recipe can calculate the suitability of new items based on how frequently an item has been ignored, and change recommendations accordingly. For more information see Impressions data.
Impressions are not the same as an explicitly negative interaction but they do imply that the impressed items were considered less relevant/important to the user than the item that they chose to interact with.
Another approach that can be used to consider negative interactions when making recommendations is to have two event types: one event type for positive intent (e.g., "like", "watch", or "purchase") and one event type for dislike (e.g., "dislike"). Then create a Personalize solution that only trains on the positive event type. Finally, at inference time, use a Personalize filter to exclude items that the user has recently disliked.
EXCLUDE ItemID WHERE Interactions.EVENT_TYPE IN ("dislike")
In this case, Personalize is still training only on positive interactions but with the filter you won't recommend items that the user disliked.
I'm building a Django web application, part of it involves an online ordering system for food. I want to make a "receipt" object to save transactions.
My concern, however, is this - let's say I have an object Receipt that relates to Orders which relate to Items, if the items get edited or change over time, it will make the receipts look different down the line. Is there a way to save these at the moment of a transaction?
I am implementing a "soft deletion" to my models to avoid deletion issues however I don't think this would protect against edits.
The only way I can think of to deal with is to 'materialize' the Receipt. In other words when a receipt is generated use the Order and Items information current at the time and then write the actual values, not the Order/Items id to a receipt table. So for a Items item write out the attributes(description, price, qty.etc) you are interested in recording to the table, instead of just an Items.id that points to a possibly changed value in future.
I have a sample loan usecase, where I have two states:
Invoice State, and
Loan State.
Loan State is created by passing Invoice State as input.
Now as Corda follows UTXO model, when I do the default vault query, the Invoice state is not showed as it's consumed now.
To solve this, there are two possible ways:
Either, I query on all states i.e consumed and unconsumed.
Or, I
can maintain a status at Invoice state and mark the status to
something as Invoice paid after consuming it to create Loan State (So this is more like evolving state, something like bitcoin where balance is always getting transferred.).
Something like this:
Can anybody please recommend what would be the correct architecture decision?
Your Invoice should have a 'state' field with and enum of at least 'UNPAID' and 'PAID'
Your 'payInvoice' command should have the following inputs and outputs:
inputs:
Invoice - state=UNPAID
outputs
Invoice - state=PAID
Loan
The verify function should check that the inputs and outputs for this command are as above.
After which the 'UNPAID' invoice state is spent and cannot be used again.
I hope that makes sense.
Check out the 'MeteringInvoiceCommands.Pay' method in the following code. This is similar to what you need, but in this case, it is checking that a payment is produced as well as the input state is 'ISSUED' and output state is 'PAID'
https://gitlab.com/cordite/cordite/blob/master/cordapps/metering-contracts-states/src/main/kotlin/io/cordite/metering/contract/MeteringInvoiceContract.kt
I agree with bartman250. The second example makes the most sense in my view as it keeps options open in a more obvious way.
Let's say for example, for some reason the invoice needs to be reset to unpaid because there is a chargeback on a credit card, having the invoice as unconsumed works well.
The issue of worrying about it being consumed again can be handled by ensuring that the loan contract only consumes invoices that are marked as unpaid. We do something very similar with a purchase order in the letter of credit demo found here.
Having the invoice available to be queried from the vault as unconsumed is also the default query mode. It also provides the advantage of ensuring we're dealing with the latest version of the state by default.
The second example above is the best in my view.
Basically, if you hold an Enum on the Invoice with all the different states - i.e. UNPAID, PAID, REJECTED etc. You can then evolve this state in your flows.
You can then use the contract verify function for the 'paid command to check that a loan state has been created.
Imagine a little webshop which uses its own currency.
In the database, there is a table for items, which can be bought. The count of each item is limited. This limit is stored in a collumn in this table as integer.
Also, there is a table for the user's cash accounts, whereas for each account the current balance is saved.
If, for example, two users conduct their purchases at the same time and only one item is available, it could be possible that both users pay but only one receives the item due to racing conditions.
How can such racing conditions be resolved, without relying on entity framework throwing exceptions on saving?
How can I ensure the count of available items and the account balance of the buyer is correctly updated?
This isn't really a problem specific to Entity Framework, it's applicable to just about any shop scenario. It comes down to a question of policy - the only way to ensure that two customers do not purchase the same item is to allow a temporary lock to be placed on that item when they add the item to the cart, or begin the checkout process, similar to how concert tickets or flights are sold. This lock would expire if the purchase is not completed within a set amount of time, and the item would be released back for other customers to purchase.
In an e-commerce setting, this is not as suitable, since people may add an item to their cart and not check out, or spend extra time choosing additional items. This may lead to the scenario where you have items for sale but they can't be bought because they're in someone's cart who's not planning on checking out. Instead, duplicate orders are allowed, but payments are typically only pre-authorised and then completed at the time of shipping or order confirmation, so even if the second customer enters all their details and presses Buy, their card wouldn't be charged since the item wouldn't be shippable.
You can implement checks at different stages during the Checkout process to ensure the items in the cart are still available, or at the simplest level, leave it for the final "Pay Now" button on the last page. Ultimately though, this just reduces the potential for the race condition, rather than eliminating it.
1st I want to remove text field for date so the calendar will replace it.
2nd I want to make the status order.. I want to sell the service, so I need to make booking order by calendar. If the date is green client can make an order. If red the client can't book an order. If yellow there certain items can be ordered.
I hope someone can help..
Thanks.
You have to try something at least and ask only for advice then.
Anyway, few suggestions:
it cannot be done using that option field of type date, at least not with the default datepicker.
You will need to create Your own datepicker component that will search for free/partialy/fully ordered days in the database and color the table cells accordingly.
It is not very wise to hide the input - by this visible user could anytime check what date did he pick - if it is not visible he would need to always open the datepicker to check for it...
Disallowing to order some service based on some reservations is highly decreasing Your conversion rate - thus decreasing Your income. I would definitely go the way let the user buy/order anything at anytime while having separate reservation system. If user buys a service at thank You page I would recommend him to book a concrete date for the service to be drawn. Here You do not need to fight with product options which are meant totally for something different that You are trying to.
Keep that in mind (mainly the 4th point) and re-think Your problem.