Prestashop: Carrier Names are not translatable anymore? - prestashop

In Prestashop 1.6.
I don't understand why the Carrier Name field is not translatable anymore.
I found serveral topics just saying that this was posible in older versions but no now. But why?
I have names like: "Standar Delivery" How are we supposed to translate these names?
Is there other approach to work with carriers and languages?
thanks.

There is no way to translate carrier names and there is issue (improvement) opened in PS Forge since 1.4. I think the reason behind is that carrier usually has a name, e.g. DHL which does not need to translate.
I see in merchants' stores they use store's name as carrier. e.g. if you have Shop ABC, then carrier name would have the same name - Shop ABC.
If you have more than one carrier, e.g. Priority Shipping, Standard Delivery, etc. then it won't work. My suggestion would be to use Standard Delivery and below there is a field named Transit time which is translatable. It is actually the same as description so you can add short description about each carrier in different languages. Customers won't need to know which type of delivery is offered by the carrier name, they can read description next to its name.
Also it would be good to have informational (CMS) page about delivery types and costs. I would say it is a must for an online store.

i have done this before for PrestaShop 1.6
I know it's possible but you need to modify 2 files and you need to adjust the database.

Related

How to know if my carrier is pick up in-store

I have a prestashop module in which they are asking me in a parameter to indicate if the carrier that was chosen is to pick up in store or not. I am getting the carrier information in this way
$carrier = new Carrier($cart->id_carrier);
This brings me the information of the carrier correctly, the problem is that the only parameter I see to know if it is pick up or not is delay, but this is a parameter which you can always change the value in the carrier configuration.
When creating the store in prestashop this creates 2 carrier by default, one is the pick up in-store, but if I delete this carrier and then I want to create another custom that is pick up in-store, prestashop does not provide a specific option to check that this carrier is of this specific method, the closest thing is the delay but this can change in many prestashop stores.
There is some method, parameter or function that tells me 100% if the carrier is pick up in-store, a parameter or something that never changes in any prestashop store?
Every carrier has id_reference in database, it is something what is always same, as you might know, every time you edit Carrier in PrestaShop, a new instance is created and inserted into database, id_reference field helps you track original id of Carrier.

How do I enable 2Checkout to accept Billing / Shipping Address for all Countires across the world?

I am using "ConvertPlus Default" Checkout Theme in 2Checkout to accept international payments from my customers across the world. I generated the Buy Link and integrated with my store.
My issue is that the Checkout Form is not showing fields to input Address and City for many countries including Mexico, Japan etc. Refer screenshot below:
How do I enable the option to accept Complete Address information for all countries across the world?
Buy Link looks like this:
https://secure.2checkout.com/checkout/buy/?merchant=\[MerchantID\]&prod=\[ProductID\]&qty=1&tpl=default
You should add the tangible parameter
Send tangible=TRUE or tangible=1 for products that require physical delivery.
As of 10/01/2019 the parameter you will need to enable shipping is
li_#_tangible
The documentation says this.
Specifies if the corresponding li_#type is a tangible or intangible.
( Must be Upper Case, ‘Y’ or ‘N’, if li#_type is ‘shipping’ forced to
‘Y’.)
Where # is the parameter number. Because you can send multile items in the same POST so it will appear as multiple items in the 2CO cart.
Here is the full documentation about parameters,
https://www.2checkout.com/documentation/checkout/parameters/
Hope this helps someone.
Cheers.

Vies database split address

I'm using vatlayer API for getting company information by put in the vat number. https://vatlayer.com/documentation
Now I want split address info in the state, zipcode, addressline and address number.
I get the address info: BREDABAAN 13052900 SCHOTEN.
The address number and zipcode stands against each other without spacing. (1305number and 2900 zipcode).
Is there another API for working with the vies database where i can split these information? Or an work around for this bug?
VatLayer don't support the split atm.
I get the address information by:
$("#organisation_address_line_1").val(json.company_address);
Thanks in advance,
There's quite a lot of API's to handle VAT validation but the ones that provide information about the trader essentially all rely on the official API at http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl . It connects directly to the VIES system. Perhaps the values returned there are a bit different: it's worth trying your validation that way as well.
Unfortunately, since VIES does not return structured addresses (except for approximate matches, but only Spain supports them at the moment) and does not specify a common format for the free text addresses, you're going to have to deal with whatever format the country has chosen to provide, which means manual parsing.
I reckon 3rd party wrapping API's could handle guessing the format and splitting the formats on their own but I am not aware of any that would do it.

Vendor specific pricing on Shopify

A client of mine has a service-oriented ecommerce site on Shopify and he's asked me to assist in making a few changes. I've never utilized the service so I'm not really familiar with it.
The price list was static at first since the client used the same vendor however now that they're growing - and therefore using multiple vendors - the costs are fluctuating and therefore the prices on Shopify need to reflect that.
I need to set it up so that when a customer logs on a vendor is programmatically chosen based on their geographic location and the prices (shown to the customer) adjust accordingly.
Is this possible? And if so, what objects/API docs should I be looking at. I seems as if I can easily hard code this with IF statements but I'd like this to scale cleanly so I'm looking for a more efficient solution.
I think this should be possible. Based on your comment:
Will I not have a zip code for the customer? – RyanMac
The easiest way would be to create a Product Variant for each region. Based on the customer.default_address you could find the customers ZIP code. Next step would be to use this within the product.liquid template to select the correct variant.
The biggest problem you have is determining their location. When a customer logs in, you know who they are, so you could dish out only products of interest to them. Problem is, how do you lump people into those regions? You have your work cut out there. When you create a customer you can assign them any code you want, so perhaps you could just match customers to vendors using a match on that. Lump any customers into GroupA and you show only products with Vendor GroupA, any customers assigned to GroupB render products from vendor GroupB....etc

Setting carrier per product

I'm working on a store that has two types of products: perishable food and general merchandise. The food must always be shipped overnight via FedEx, and the other merchandise must always be shipped via USPS. If somebody orders products from both categories, they must be shipped separately.
Do you know of an existing module or configuration settings that would allow for this?
If not, it sounds like a custom module would be the other solution. In this case, what is the best approach? I'm thinking it would be splitting the order into a multi-address shipment, using the same address for both but with different shipping methods. Unfortunately I'm not sure how to do this programatically, so any tutorials/samples/resources would be greatly appreciated.
Probably the sanest way to handle this would be to create two orders per product type, each shipping with a different carrier to the same address. This also IMO makes more sense from a stores tracking perspective as you can handle each independently from each other.
To get you on the right track(since Magento is especially cryptic in this part of itself) you should read the Inchoo programmatically create order in Magento post and by the same author Programatically create customer and order in Magento with full blown one page checkout.
Basically as I see this going is:
Get the customer order
Itinerate through each product inside the order and split it up in two arrays for each product type
Create a separate order for each product type and use the different shipping methods for each.
You will probably have to extend a some controllers OR do it the non-standard way and use helper functions for this, the hard parts will be integrating the payment/shipping modules inside your order process. Going this way will have you creating the full checkout process as the one page checkout Magento provides won't really work and is too much pain to get to work because of the way it uses AJAX.
Also another alternative is to hook in to Magento's pre-create order events and create the orders there using already defined order data split it up in two orders, but this is something I never heard or saw implemented at the moment so you'd have to do it "blindfolded" so to speak.
An easier approach would be to use a custom field that defines your product's shipping method, this way you just add that and don't care about custom orders. You just react with that, however tracking will become mostly impossible IMO.
Over-ride the Free Shipping module.
You can setup a sales rule that applies to certain products and makes them 'Free Shipping', leaving the other products to your chosen main shipment provider.
You will need to see how this works, however, the point is that Magento does have something built in to split an order into two shipping categories, albeit only a sales rule on free shipping. But you have source code...