Client refunds (out_refund) show only one type of Tax in the tax list, even if there should be more than one. For example: I have this out refund lines: One S_IVA10B and other with S_IVA21B
You can see S_IVA21B and S_IVA10B, right? Well... if you go to Other information tab, you find only one tax line:
Any of you know why this is happening (only) on refunds? The out_invoice elements are correct.
It was a reported bug. Now it is solved in this commit: https://github.com/OCA/l10n-spain/commit/4ac7266648aab0fa469ae271a7541f6bec79f3fb
For unknown reason it haven't worked for me, but there is an official fix.
Related
What I want:
I have created a script in the Script Editor that makes your first
line item in a cart free. I want this script to execute once per customer.
My question:
What is the syntax to limit a script to execute once per customer
through the use of the Script Editor app?
Business use case:
Without adding this functionality to my script, a customer could
checkout with 1 item free... but then they could begin shopping again
and checkout with a new cart with the first line item free again... that
means they could get 10 free items from 10 different checkouts.
Thanks for your time and thoughts!
P.S. Script is in Ruby. Also, Setting up a discount code won't work for my use case.
UPDATE
Thank you for your responses. I will be attempting these suggested updates this week and will post my results soon.
UPDATE 2
So the below suggestions and marked answer were all spot on except for one detail. The script editor keeps on running into some type of error even though the described syntax below is correct. Another stackoverflow answer suggested to use '&'.
So I ended up doing something like this:
customer = Input.cart.customer
if customer&.tags&.include?("gift_received")
...
end
This works for me. Thanks again for all your answers!
Any kind of solution could only work if Accounts are required
otherwise you can't track the history of orders.
There are two possible solutions
You create a flow that assigns a tag to a customer when they receive a gift. You check for the tag : Input.cart.customer.tags.include?('gift_received') and don't apply the discount.
If your case is just 'Gift on the first order' you can just check Input.cart.customer.orders_count > 0 and that's it.
Um. You can always just assign a little tag to the customer. For example, if they received this free item, give them a tag on their first order. Now, if they try and fool you nine more times, check for that tag. If they have it, remove the item from checkout. Boom. problem solved.
I have created a script in the Script Editor that makes your first line item in a cart free. I want this script to execute once per customer.
The best way is to flag customers using tags. You can use Shopify flows to add tags to orders containing free gifts to mark customers as the customers who received already free gifts. This will be better than checking Input.cart.customer.orders_count > 0 because it will give you more visibility in the orders & customers panel.
The approach mentioned by #Fabio Filippi is the best however it needs to be secured:
You create a flow that assigns a tag to a customer when they receive a gift. You check for the tag : Input.cart.customer.tags.include?('gift_received') and don't apply the discount.
Business use case:
Without adding this functionality to my script, a customer could checkout with 1 item free... but then they could begin shopping again and checkout with a new cart with the first line item free again... that means they could get 10 free items from 10 different checkouts.
Nothing prevents the user from creating a new account so you need to consider some verification logic that will be assigning the gift_received tag after the customer is validated.
If you want to avoid fraud I would consider using both (note that in this case we are checking if customer already bought something in the past) Input.cart.customer.orders_count > 1 and Input.cart.customer.tags.include?('gift_received') OR Input.cart.customer.tags.include?('gift_received') and Input.cart.customer.total_spent > Money.new(cents: 1000). This way you can have "eligible for gift" kind of logic. There are many ways to approach it.
Here is an example of the data I am using:
"Q7: How does gender income inequality manifest in the communities in which you live and/or work? What do you believe is needed to help close the wealth gap between men and women as well as among women of different races in the county?
Wouldn’t go into pay equity because that would get dismissed. The wealth gap is a more compelling argument.
Equity is more emotional. And wealth gap is more numbers. It goes toward the same thing though."
I am running Rstudio and using library(RQDA) and library(tidyverse).
I am trying to analyze several qualitative interviews formatted in question/answer form as in the provided example. I finished the coding process and now I'm trying to find themes. While coding, I created code categories that correspond with each interview question with the hopes that I would be able to pull out all the codings per code category now. Unfortunately, I cannot figure out how to do it and would appreciate some assistance!
thanks
I am not sure about this but I understood code categories to be helpful for structuring your work by your theoretical perspective. If you create a code category for each interview question (i.e., the topic of the question is your theme/code category), you may have various codes belonging to one "code category", which might not have that much in common. Alternatively, you could create cases (case 1 might be the answers to the first interview question, etc.): "b) Open a file, select part of the file, select a case name, then click button "Link" in "Cases" tab, you can thus link the selected part of file to the selected case" (http://rqda.r-forge.r-project.org/documentation_2.html).
We have an issue with our site where if you add items in a promotion (eg. buy x and y and get z% off y), then remove one of the items (x) you still get the discount (on y). I'm a bit of a self taught noob when it comes to magento and PHP so I don't even know where I would look, does anyone have any ideas?
Just check once again all the conditions and actions applied for that promotion.
Discount might be still there because of that reason also.
Ok so it turns out the colleague who set the promotion up put the affected items in both sets of conditions - should have checked there first!
I'm killing myself trying to find the right solution for this problem. Here is my issue:
Selling Wires:
We will say a wire is $5.00
If you want 1 foot its $5.00
If you want 2 feet its $10.00
...
Each foot isn't a separate SKU. Its a recalculation of the total. Thats it. Really easy, but for some reason incredibly difficult in Magento.
How would I code this? Any ideas?
****UPDATE***
These are configurable products. Didn't think of that in the beginning.
One way to do this without adding additional attributes or logic is sell by the foot.
Have your SKU as wire-1-foot for example and use Magento's built-in tier pricing to customise your pricing for multiple quantities, aka multiple feet of wire.
You will probably also want to customise the block around the quantity field to make this a clearer for customers.
EDIT:
You could also consider grouped products as they behave slightly differently, e.g. http://www.webshopapps.com/blog/2010/11/tiered-pricing-on-configurable-products/
Please consider the situation where a product has extra SKU parts in it's custom options. The product may have a SKU product and the custom option has option, the end result will automatically be product-option.
Now go into the admin and attempt to order this product with a custom price, the custom option becomes an 'additional option' and the extra -option is missing. My store (enterprise 1.8) needs these SKUs to be intact but I need help making a fix for this. I expect I will have to override Mage_Adminhtml_Model_Sales_Order_Create at some point and that's OK.
I've googled this problem until my fingers are numb but cannot even find mention of it let alone a confirmed fix. Please point me at the cause of the problem.
This was hard to track down because it seemed intermittent. I'm answering myself in detail because I don't want anyone else to go through the same ordeal.
The problem stemmed from custom options which both added a custom SKU and contained a colon in their title. If you look closely in the following picture you can just see two colons in "Colors::Black" - the first is the option's name, the second is added by Magento. When updating the order it attempts to parse the custom options back from that text box and the extra colon throws a spanner.
The other bad thing is because Magento cannot read the custom option back that particular option gets dropped. In this case it's a required option, which leads to a warning message.
Since the option is missing so is it's SKU part. Other custom options are not affected which clouds the issue. The simple answer to all this is to just avoid colons.