Future of Padloper - New Project Lead Announcement

[kongondo]

1 hour ago, MarcoPLY said:

For the Shipping Price coulde be useful if we can also trigger for the total cost of all items.
Always for Shipping Price, could be an option, in the category shipping backend, calcolate the costo adding the singular shipping prices or only take the highest, as it is now.

Then you are going to love the next progress update :-). ?

[arjen]

On 10/29/2018 at 8:59 PM, kongondo said:

So, for digital products, an email and names (first + last?) would suffice? For physical products, the least required should be a full address + full names and I think an email for order status updates, no? In both cases, this data has to be stored somewhere though. Only difference is an account is not created.

Apologies for the late response but I think @szabesz nailed it:

On 10/29/2018 at 9:28 PM, szabesz said:

Regarding customer's private data: any data which is directly related to (i.e. "required by") the order should be considered as "must have" because legally speaking there is a contract between the seller and the buyer, and the customer cannot ask the shop-owner to delete such data from the system. However, "ordinary user" data – which is not related to a particular order – should only be stored if the customer explicitly agrees to it, and such data should be deletable without breaking the integrity of any order's data.

Exactly. That's why I liked Apeisa's original idea of storing the customer data on the order as well. This way you can easily delete the user and its data except for the data necesseray by law like orders.

[kongondo]

1 hour ago, arjen said:

Exactly. That's why I liked Apeisa's original idea of storing the customer data on the order as well. This way you can easily delete the user and it's data except for the data necesseray by law like orders.

That's easy enough to implement. The only decision I was struggling with is how ?. My original idea (which I have now discarded given the feedback here) was to have customers as normal ProcessWire users. The advantage of that is that we would't need to have the same data stored in two different places; as ProcessWire Users and also as customer data in our Orders field. Using that approach, a simple customer id in Orders field would reference the user. Now we can do it the other way around, maybe incorporating this idea:

3 hours ago, MarcoPLY said:

the e-commerce users in a separate page like a Padloper Customers

 

We were always going to have a 'separate dashboard' for users/customers, albeit, referencing ProcessWire users with a certain role, like 'pad-customer' or similar. I'll write more about this later. Give the previous comments, we can instead have this dashboard backed by its own Field OR external DB table. We already have a Customers Fieldtype. It will just need some tweaking or conversion to a separate db table outside ProcesWire . We'll use the field to store customer data in relation to their orders or abandoned carts, making sure we fulfil our legal obligations (if required). The only tricky bit is if those customers decide to get registered. Maybe it's not a big deal. We'd let ProcessWire handle their normal user stuff, like login and permissions and we handle the rest, i.e. their shop related stuff. In this case though, the customer id (from customers table) will be different from their ProcessWire user id. However, the customer Field would reference the User's ProcessWire ID, so no big deal there. For unregistered customers, their ProcessWire ID would be 0. 

Alternatively, our order Field could store user/customer data directly but I'd rather have them as separate entities due to various advantages, e.g. being able to send newsletters to your customers, sending them promo/discount info, engaging most loyal customers, etc. 

Just thinking out loud here, at the very least to see if it makes sense to me when I read this again some hours later ?.

Thoughts?

Edited October 31, 2018 by kongondo

[Jozsef]

2 hours ago, kongondo said:

That's a tick then ?. It's already implemented ?!

Thanks, it seems to tick all boxes for common discounts, well done. 

[szabesz]

4 hours ago, kongondo said:

My original idea (which I have now discarded given the feedback here) was to have customers as normal ProcessWire users.

It could be done by specifying what user data is deletable and what not. Also, user without an order is deletable but a user with at least one order is not.

4 hours ago, kongondo said:

a separate db table outside ProcesWire

Are you thinking that we need this because of being able to impose restrictions on this table outside of the scope of the normal PW API? Or because of something else?

4 hours ago, kongondo said:

customer data in relation to their orders or abandoned carts

1. If I were to implement it, I would "bake" all the data of an order into its "record", meaning not just storing relations but the actual data too, in order not to make it possible to erase order data by deleting users, whether it be PW users or custom ones.
2. We must keep in mind that "abandoned carts" are not contracts just yet, but deletable user data.

[kongondo]

43 minutes ago, szabesz said:

Are you thinking that we need this because of being able to impose restrictions on this table outside of the scope of the normal PW API? Or because of something else?

No. An external table means I avoid creating pages for each customer. 

46 minutes ago, szabesz said:

in order not to make it possible to erase order data by deleting users,

That is not going to be possible. Erasing users will not erase the order data. I am not using page fields or similar. The only thing that would happen in such a case is that a user id stored in a customer database would point to a non existing user ?

 

 

[kongondo]

Customers discussion:

I've had a bit of a think and I think I'm probably complicating matters. With your input and a bit more thought, for now, I'll go with this approach:

1. Registered customers are ProcessWire users. We'll give them some role to distinguish them from other users + they never see the backend. The will have a record of their details in User template (address etc). These records are editable, e.g. change of address, etc.
2. Guest users will only have a presence in their respective orders, their records saved together with their order
3. For registered users, their orders will reference their ProcessWire user ID as well. To satisfy legal requirements, their data (the minimum required) will also be saved with their orders. As was pointed out, if their ProcessWire user account gets deleted, we still have their data in respect of their orders
4. The backend will have a dashboard/page for managing users, both registered and guest customers. For guest customers, the data shown will be what is in their orders. They will be clearly marked as guest customers.
5. There will be a global shop setting to allow either both guest and registered customers or registered customers only or guest checkout only
6. Shop owners will indicate what information they want collected from their customers. It will be their duty to inform customers why they need the information
7. Registered customers will have frontend login and customised dashboards
8. Orders will still be filterable - unpaid, abandoned, etc. Orders will have records of customers, both guest and registered customers. These records are permanent and un-editable (and decoupled from any other similar/identical records in the case of registered users) ONCE AN order has reached a finalised state. Before the finalised state, the order can be amended, e.g. an address was entered wrongly and needs editing, etc.. Order statuses and any changes made will be accompanied by chronological order notes (same as we currently have them).

I hope I haven't forgotten anything...

Edited November 1, 2018 by kongondo
clarity

[szabesz]

All those points sound ok to me. I just request a simple addition (maybe you just forgot to add but still...):

8 hours ago, kongondo said:

5. There will be a global shop setting to allow either both guest and registered customers or registered customers only

Since I maintain a webshop which is set to "guest only checkout", I'm pretty sure there is a need for that too ? 

Edited November 1, 2018 by szabesz
typo

[arjen]

15 hours ago, kongondo said:

The advantage of that is that we would't need to have the same data stored in two different places; as ProcessWire Users and also as customer data in our Orders field.

I know what you mean. I see order data as a kind of artifact data which is only relevant to that specific order. Basicly it is stored in the two places, but if the order address changes for the user? You wouldn't want old orders to change the address as wel. So the single source of truth is stored on the user. See my quickly drafted visual:

[arjen]

7 hours ago, kongondo said:

With your input and a bit more thought, for now, I'll go with this approach

I missed this one ?

Seems good to me!

[kongondo]

2 hours ago, szabesz said:

All those points sound ok to me. I just request a simple addition (maybe you just forgot to add but still...):

Since I maintain a webshop witch is set to "guest only checkout", I'm pretty sure there is a need for that too ? 

Oops, thanks. Post edited.

[Mustafa-Online]

I can't wait to build my first E-commerce site using Padloper ? - Great Job @kongondo 

[kongondo]

1 hour ago, arjen said:

I see order data as a kind of artifact data which is only relevant to that specific order. Basicly it is stored in the two places, but if the order address changes for the user? You wouldn't want old orders to change the address as wel.

Yes, this will be the approach. I've edited my earlier post to be more clear.

[szabesz]

9 hours ago, kongondo said:

These records are permanent and un-editable

This is ok after the order has reach the end on its lifecycle, ie. it is shipped or in the case of digital only product/services a given state is reached. However, orders should be editable based on special conditions (eg.: being in predefined – better yet configurable – states) so that shop managers can adjust orders before shipping based on customer's request (in case that request is not too late, ie.: order is not yet shipped, for example) and/or after a failed delivery when there is a need to ship it again.

Related question: it will be possible for shop managers to create an order for registered customers on their behalf, won't it?

[kongondo]

9 hours ago, szabesz said:

This is ok after the order has reach the end on its lifecycle, ie. it is shipped or in the case of digital only product/services a given state is reached. However, orders should be editable based on special conditions (eg.: being in predefined – better yet configurable – states)

I wasn't clear. I meant customer addresses, emails etc should not be editable in the order. However, I now see your point about the need to edit an address, e.g. a customer entered the wrong details and phoned in to amend. 

If I get you correctly, as for order states, yes, we have that. I posted a few details in this post.

9 hours ago, szabesz said:

Related question: it will be possible for shop managers to create an order for registered customers on their behalf, won't it?

Yes, manual order creation is already available. The API is finished. I'll post details soon, hopefully by tomorrow. I just need to finish testing a few other things first. So, manual order creation will be possible for whoever you want. You can take orders over the phone, at the POS, accept cash payments, invoices for goods delivered, etc. The interface is not ready but the API is. This means you can even use the API directly to create orders, not that you would want to do that if you have a GUI ?

[kongondo]

News Update - 20 November 2018

Hi all. This update should have gone up about 3 weeks ago :-). Some of you are aware that I've been having computer issues but that's sorted (fingers crossed) for now. Before that, I'd managed to work on and mostly complete a number of things. I'll try and remember them now as I write and hopefully I don't forget anything (these posts not only help with generating discussions but they will be useful references when I get round to doing the docs).

Orders

First, thanks  (especially @arjen and @szabesz) for the feedback on orders and customers.

We now have a FieldtypeOrders  and FieldtypeOrderItems which store permanent records of orders. The former stores the aggregates (total price, etc) and customer info. The latter stores data about each individual item in the order (name, price, etc). These two simplify querying orders (backend stuff).

Customers

FieldtypeCustomers stores registered customers' data. It is also useful for frontend customer login areas/dashboards and for returning customers in cases where customers have to login in to make purchases, e.g. retrieve their stored address.

Products

The products field has been updated to store product dimensions.

Shipping

This is by far the biggest work to date, I think. It consists of 3 modules, one each for Shipping Zones, Options and Rates. I think it is comprehensive enough to do away with the need to write custom shipping classes although we'll keep that option open.

Please note that although the explanation of the underlying logic behind shipping can seem complicated, the GUI for setting up shipping will be quite simple and intuitive to use. 

Zones

Setting up shipping zones

To create a shipping zone, you will have first set up countries where you ship to. This is a global setting since it also affects taxes.  Once that is sorted, you can start creating shipping zones. You can create as many shipping zones as you need.

A shipping zone consists of geographical areas where you ship physical products to. A shipping zone can have as many shipping regions as needed. 

Regions

A shipping region can be any of these:

• Continent (E.g. Asia)
• Country (Germany, Lithuania, UAE)
• State/Province (Kowloon, Goa, Texas, Arezzo)

The selection of regions (GUI) will be inbuilt. I.e., shop admins will be able to select Quebec or Nigeria or Asia, etc.

In addition, one will be able to further refine their region definitions using postal/zip codes.

Postal/Zip codes

Postal codes can be matched in several ways:

• Verbatim: in this case, you specify an exact postcode(s) to match, e.g.  CD30 78GH or 18000
• Range: For numerical postcodes such as US zip codes, shop admins can specify the desired range(s), e.g. 60001 - 61909
• Wild cards: This will match the first n characters of the postal code, e.g. SW* or BH3*

You can enter as many postal codes to match as you wish.

A customer's shipping address details at checkout are used to match their order to the shipping zones defined in the system. If no match is found, the system defaults to a generic shipping zone/rate if you have one set up AND assuming the customer's delivery address is in a 'place' you ship to. If not match is found at this point, the customer will be shown an error or custom message you set up.

Shipping zones examples

1. State/Province + Postcodes

Say you ship only to California. It's a big place so you decide to divide up the place , into 5 shipping zones using zip codes. In this example, the first 4 shipping zones are defined by zip code ranges. The fifth zone takes care of any other areas inside California not within the zip code ranges in the first 4 zones.

1. California zone 1: 90001 - 92999
2. California zone 2: 93000 - 93705
3. California zone 3: 94200 - 94799
4. California zone 4: 95000 - 95750
5. California zone 5: All other zip codes in California

In this example, zone #5 will be matched as long as the State in the shipping address state is California and the zip code is not within the ranges described in zones 1 - 4.

2. Country + States/Provinces

In this example, you ship only to Canada. You create several zones based on Canadian provinces as follows:

1. Canada zone 1: Alberta, British Columbia Saskatchewan (multiple regions in one zone)
2. Canada zone 2: Ontario, Quebec
3. Canada zone 3: All other provinces

In this example, zone #5 (all other provinces) will be matched as long as the shipping address country is Canada and the province is not one of those in zones 1 or 2.

3. Continent

In this example, we use continents to set up shipping zones based on groups of countries. For instance, setting up zones for Africa:

1. Africa zone 1: East Africa consisting of the countries (regions) Kenya, Uganda, Tanzania
2. Africa zone 2: West Africa; Gambia, Cameroon, Togo, Niger
3. Africa zone 3: North Africa: Egypt, Tunisia, Morocco
4. Africa zone 4: South Africa: Zimbabwe, Botswana, South Africa

In this case, the system will match the country to their continent. Customers do not have to enter 'continent' in their shipping address details :-).

Rates

Shipping zones alone are useless without rates :-). Padloper 2 allows you to create rates that you can use and reuse across different zones. Please note that rates in this case just define the applicable rates(s) for an order (or part of an order) based on certain conditions. Rates do not specify how much shipment should be paid. We will come to that later below.

Rates can be based on:

1. Flat rate: A single flat rate should be paid for this zone. For instance, using our examples above, we can set a flat rate for all shipments to California zone 1 but set a different rate for California zone 3.
2. Price:  Shipment is calculated based on price. E.g. if order is worth < $30, charge $2.50
3. Weight: Shipment rate calculated based on weight of items in basket
4. Quantity: Shipment calculated based on quantity of items in basket

Rate Applies To

A rate 'based on' value in itself is incomplete. One also needs to specify how the shipment rate will be applied. The choices are:

1. Order: Shipment will be charged PER ORDER (the whole order). This means apply the shipment once irrespective of number of items in the order, or their price or weight, etc.
2. Item: Shipment will be charged PER ITEM in the order. So, if we have 10 items, shipping will be charged 10 times, etc. 
3. Item-group: Shipment will be charged once PER EACH MULTIPLES OF THE 'SAME ITEM'. By item-group is meant a product with the SAME ID and same VARIANT ID. So, if we have two shirts, that have the same product ID, but one is orange with variant ID 1 and the other is blue with variant ID 2, those are NOT the same item. If our basket contains 3 of the orange shirts, that is counted as one item-group and if we have 1 blue short, that is another item group. In this case, shipment will be charged once for each item-group - once for the orange shirts and once for the blue shirt.
4. Product-class: This is a special rate so let's examine it more closely.

 

Product Class Shipment is a powerful feature that allows shipment to be calculated based on a product class. A product can only belong to one class at a time. A class is a special category which you use to group similar products for the purposes of shipping. 

For instance, you can have the following classes:

• Heavy: This would be a class for heavy items
• Bulky: A class for bulky items
• Small
• Fragile
• Etc...

You can create and use as many product classes as you wish.

Product class shipment is used with any combination of the above Rates and Rate Applies To. With product class shipments, you can mix and match as required. For instance, for your Small items, you can use Flat Rate shipping applicable to the whole Order. You could also have a Weight-based Rate that is Applied per Item. Or, a ship your Fragile items using a Quantity Rate applying per Item-group. As you can see, using product class shipments allows for more flexibility within an order. Of course, you can set up different product class rates depending on your shipping zone. For example, you can Flat Rate shipment for Bulky items shipped locally and an Item Rate shipment for Small items shipped to your international customers.

Please note that in the case of Rate Applies To Order with respect to Product Class shipment

Rate Value

Using a Rate Value setting, you can specify what value should be used to determined whether an order has met a shipping criteria. Consider the following examples:

• €2 shipment will be charged PER ITEM in the basket if the ITEM COSTS at least €15. In this case the Rate Value looks at the price of a single item (i.e, >= €15) in order to apply a €2 per item shipment
• Now consider a similar example but with a different Rate Value. €2 shipment to be charged PER ITEM in the basket if the TOTAL COST of the basket is at least €15. In this case, the total cost of the basket is used to determine if the threshold has been reached.

The last piece of the puzzle is Shipping Methods. You might have a flat rate or a price-based rate, but in relation to time (or level of service) how do you actually deliver the product?

Methods

Shipping methods are straightforward. You can add as many shipping methods as you want. For instance:

• Collection: Buyer collects from your shop
• Same day delivery
• Standard delivery
• 3 - 4 Days' delivery
• Express delivery
• Etc

There are no predefined methods. You set this up yourself to suit your needs.

Options

Shipping Options complete the shipment system. A shipping option is a combination of a shipping rate and a shipping method. Think of them as a matrix (similar to Table  rate shipping in WooCommerce). Shipping options are automatically created based on selected Shipping Rates and Shipping Methods for a zone. The admin then has to enter a shipping fee/charge/cost for each combination of Rate and Method. At checkout, the customer will be presented with the shipping options available to them and how much that would cost them. Here are some examples Shipping Options (Methods X Rates):

Options: a 1 x 1 combination

You should could offer a Standard Delivery (Method) charging a Flat Rate £10 for all transactions. 

Options: a 2 x 1 combination

Offer Normal and Express shipping charged at a Flat Rate £5 and £10 respectively for either Method.

Options: a 1 x 2 combination

Offer Standard delivery on all shipping based on Quantity of order and charging $7 if order contains less than 10 items and $4.50 if order contains more than 10 items

Options: a 2 x 2 combination

Delivery Methods:

• Collection
• Normal
• Same Day

Weight-based Rates:

• Rate 1: Less than 10 kg
• Rate 2: Greater than 10 kg but less than 20 kg
• Rate 3: Greater than 20 kg

Shipping options will be the matrix of the above methods and rates each with a shipment fee, e.g.

• Collection x Rate 1: Free
• Normal x Rate 1: £5
• Same Day x Rate 1: £15
• Normal x Rate 2: £8
• Etc..

Options: a more complex combination: product class rates

Delivery Methods

• Standard
• Express

Product-class Rates + Applies To

• Small items: quantity-based rate charged per item-group
• Fragile items: flat rate charged per item
• Heavy goods: weight-based rate charged per item

Rates

• Small items quantity less than 5: $0.75
• Small Items quantity more than 5 but less than 15: $0.50
• Heavy goods: less than 30 kg: €10 per product

Shipping options will be a matrix of the above methods and rates each with its own shipment fee, e.g.

• Standard delivery of Small Items if less than 5: $0.75 per item-group
• Express delivery of Heavy Goods if item < 30 kg:  €10 per product

You get the idea ?

Maximum shipping Cost and Handling Fee

Padloper 1 included a maximum shipping cost. This is retained in version 2. 

In version 2, you can add a handling fee which will be applied PER EACH shipment calculation. So, if shipping applies per order, a handling fee is applied once. If shipping applies once per product class in an order, handling fee will be charged x the number of eligible product classes in the shipment (e.g. once for Small items, once for Heavy Goods, ETC).

Merge Shipping

This is work in progress and applies to Product Class-based shipping. It allows the shop admin to specify what shipping rates can be merged in order to use one shipping rate instead of two. For instance, a shopping cart/basket could contain 5 Small Items and 3 Medium-Sized Items. Rather than charge for and ship these separately, the items could be merged and shipped together using the Medium-Sized items rate.

Shipping Package

This is a planned feature that may not make it in the first release. It is useful where shop owners use delivery services like Fedex where package dimensions and weight or volumetric weight are important factors.

 

I think that's it. I could have forgotten something or could have expressed something better. I'll edit this post if such needs arise.

[Pixrael]

Awesome! Keep a record of this post for the future module documentation!

You mean "Shipping Package" will be the "Calculate Rate" based on the carriers API?

[kongondo]

1 hour ago, Pixrael said:

You mean "Shipping Package" will be the "Calculate Rate" based on the carriers API?

Yes. I'm not sure how I'll approach it though. It's just an idea at the moment.

[szabesz]

Thanks for the write up, it looks promising indeed!

6 hours ago, kongondo said:

Shipping Package

This is a planned feature that may not make it in the first release. It is useful where shop owners use delivery services like Fedex where package dimensions and weight or volumetric weight are important factors.

In the long run, my client would be interested in such a feature for sure.

[ngrmm]

hey @kongondo thx for updates

some years ago i built an multilang-shop with padloper. there is always an issue with prices based on user-lang or user-location.
some shopowner want to force their users to see the a different product-price based on their location. example:
user from germany pays: 20€
user from poland pays: 18€

i know this not depends on padloper. but maybe there is a possibility for force-switch the language in the new product-template.
or maybe update the price at the checkout if the user enter in the final billing-address.
i hope you understand what i mean ?

[LostKobrakai]

45 minutes ago, ngrmm said:

prices based on user-lang

Prices (or anything else in a shop) should never be by language imho. What if I'm living in a country foreign to my native speaking language. The German living in America should always be able to visit a shop in German (if it's localized), but otherwise shall be treated like any other American.

[ngrmm]

2 hours ago, LostKobrakai said:

Prices (or anything else in a shop) should never be by language imho. What if I'm living in a country foreign to my native speaking language. The German living in America should always be able to visit a shop in German (if it's localized), but otherwise shall be treated like any other American.

thats right, but how about updating prices based on billing address?

[Marty Walker]

@kongondo Looking forward to seeing v2! I have v1 but I'll wait to see v2 before I move my shops away from snipcart and bigcartel.

[Marco Ro]

On 11/20/2018 at 4:59 PM, kongondo said:

On 11/20/2018 at 3:37 PM, Pixrael said:

You mean "Shipping Package" will be the "Calculate Rate" based on the carriers API?

Yes. I'm not sure how I'll approach it though. It's just an idea at the moment.

Can we have something like ready-api.php page, with all the variable for use just like a endpoint for connect with the API of any carriers ? 

Could be a backend page where for each of our Padloper fields there are editable fields to connect with the carriers API. Also will be great if there are the fields for add the link of the carriers page where send the data.

Or maybe could be just a page where there are a recap of our API + documentation and that in a separate php page we will write our code.

 

 

[Jozsef]

Hi @kongondo, thanks for the updates. Do you have a rough idea on when will an initial release be available? I'd need to add a simple store to a PW site after the holidays. You said there won't be an upgrade path so I'd rather not use V1 anymore.