Parcel Forwarding & Package Consolidation for WooCommerce

Changelog

1.25.0

• Fixed: a customer who had just registered found an empty account, “No client record is linked to your account yet”, and no delivery address to shop with. The record, and the reference that goes on every order form, only existed once the operator had created it or booked a first parcel in, which is the wrong way round: the client needs the reference to get a first parcel sent. The record is now created the first time the customer opens a Colisly tab of his account, or a page carrying one of the shortcodes, so the address block with his reference is there from the start. Records created by the operator work as before.
• The shipment weight stored on the order for label plugins is now always written with three decimals, whatever the database returns.

1.24.0

• The clients list now shows what each client owes in storage fees, with a filter, “Clients with storage fees due”, to list only those. A forwarder announcing a promotion on storage had no way to find who it concerned short of opening every record.
• New: “Export to CSV” on the clients list. It carries the search and the filter of the screen and exports every matching client, all pages: reference, name, e-mail, phone, parcels in stock, stored weight, storage fees due, creation date. UTF-8 with a byte order mark so Excel reads the accents, columns separated the way the site’s language expects, cells that cannot run as formulas. The file is what a mailing tool or a spreadsheet needs; Colisly itself sends no mass e-mail, on purpose. No database change.

1.23.0

• Discounts now say what they apply to. Each of the three, the personal rate on the client record, the promotion and the loyalty discount, is a percentage of the handling fees, of the storage fees, or of both, so a forwarder can offer free storage for a month without touching the handling fees, or the other way round. Since two discounts no longer always share a base, the rule for picking one becomes the one that takes the most off, still alone, still never adding up; on a tie the personal rate goes first. The order line names the base when it is not the handling fees, “Promotion 100% on storage fees”.
• New: a promotion code. Give the promotion a code in the settings and a “Promotion code” box appears on the shipment request form; only the clients who type it get the promotion, and the live estimate updates once the code is accepted. The code is checked by the server, compared without regard to case, and never written in the page. Left empty, the promotion applies to everyone by itself, as before. Adds a column to the clients table; the migration runs by itself on update.

1.22.0

• New: discounts on the handling fees. A WooCommerce coupon does nothing on a shipment order, since coupons only discount products and a shipment order has none; and a promotion tool that did discount it would take its percentage off the transport too, money the forwarder pays out. Colisly now carries its own discounts, all as a percentage of the handling fees alone: a personal rate on the client record, a promotion for all clients between two dates in the settings, and a loyalty discount from a number of shipments done. Transport, fees advanced, storage and insurance are always billed in full. When several could apply, the highest one applies alone; they never add up. The client is told before requesting, the live estimate takes it off, and the order carries it as its own negative line named after its reason, “Loyalty discount 10%”, fixed at request time so a promotion ending tomorrow does not change a price agreed today. Adds a column to the clients table and two to the shipments table; the migration runs by itself on update.

1.21.0

• Carrier labels from a shipment order. The order already carried the client’s delivery address in the standard WooCommerce fields, so label plugins could print it, but they take the parcel weight from the products and a shipment order has none: the operator typed the weight on every label. With Colissimo Officiel, Colisly now hands over the real weight of the shipment, parcels plus the packaging weight set in Colissimo, unless a weight was typed by hand or a return label is being made. The weight is also stored on the order as _colisly_total_weight for any other tool. For forwarders who print their labels on the carrier’s own website, on a per-weight account, the Colisly panel on the order now shows the delivery address and the weight one value per line, with a “Copy” button, in the order postage sites ask for them. No database change.

1.20.3

• The French catalogue shipped with the plugin now matches the translation validated by the fr_FR team on translate.wordpress.org, word for word, so a site with or without the language pack reads the same. The plugin’s home page now points to its presentation page on pixfeed.net, linked from the readme too.

1.20.2

• Wording: the long dashes used as separators throughout the interface, “CL000001, Jean Dupont”, “Colissimo, 16.40 €”, are gone, replaced by commas, colons or a middle dot; empty cells now show a short dash. Twelve strings change, so their French and Spanish translations ship updated with the plugin. No functional change.

1.20.1

• Fixed: on the parcels and clients lists, the search box floated to the right as WordPress does by default, and the table flowed beside it, squeezed into half the screen with the filters hanging in the other half. The filters now sit above the table, which takes the full width; the “fees advanced” line under a price no longer breaks word by word.

1.20.0

• New: the client’s delivery address. The first thing a forwarding client needs is the address to give the shops they order from, their own name followed by their reference and then the warehouse, and it was nowhere: the reference sat alone at the top of the parcels tab and every forwarder e-mailed the warehouse address by hand. The warehouse address is now a setting, and the parcels tab opens on a “Your delivery address” block, name and reference in bold, warehouse lines under it, with a “Copy the address” button and a reminder that the reference must appear on every parcel. Two shortcodes put the same thing on any page of the site: [colisly_shipping_address] for the whole block, [colisly_client_reference] for the reference alone; a visitor who is not logged in gets a login link instead. No database change.

1.19.0

• New: fees advanced on delivery. Since customs reforms removed the duty exemption on low-value parcels, cartons increasingly reach the warehouse with duties and import VAT to pay before the carrier hands them over. The forwarder pays to get the parcel and had nowhere to write it down. The reception form now has a “Fees advanced on delivery” amount, with a short label defaulting to “Customs duties” so a carrier surcharge or a redelivery fee fits too. The amount shows on the parcel in the client’s account, in the reception e-mail with a line saying it was paid on their behalf, and on the shipment order as its own untaxed line, “Customs duties advanced on parcel COL000123”, so the client pays it back at cost together with the shipment. It can be corrected as long as the parcel is in stock. Adds two columns to the parcels table; the migration runs by itself on update.

1.18.1

• The parcel label now fits the forwarder’s printer. Its size is set in the settings, 62 × 30 mm by default, the common small label, and the type scales with it so the reference stays the biggest thing on it. The label carries the reference, the client, the reception date and the internal comment; the weight, dimensions and tracking number are printed only when ticked, since a small label has no room for them.
• Fixed: on the settings screen, ticking one of the customs “Ask the client for” boxes also switched the two others on or off behind the scenes, since the three shared a cell. Each box now only drives its own setting; the new label boxes rely on the same fix.

1.18.0

• New: a printable label for every parcel. Its reference only exists once the parcel is saved, so the operator could not label the carton while typing and reached for a separate label program and a per-client counter instead. Saving a parcel now lands on it with the reference in large type, a “Print the label” button and a “New parcel for this client” link; a “Label” link sits on every parcel row of the client record and the parcels list. The label carries the reference, the client’s name and reference, the reception date, the weight and dimensions, the tracking number and the internal comment, on a plain page sized for a label printer.

1.17.0

• New: Spanish translation, shipped with the plugin like the French one. Every string the plugin says, 393 of them, including the account tab slugs, which stay plain ASCII. A validated language pack from translate.wordpress.org takes over by itself the day it exists.

1.16.2

• The French translation ships with the plugin. Language packs from translate.wordpress.org only exist once volunteers have validated the strings, and they get to popular plugins first; until then French sites saw the plugin in English. The bundled catalogue is used whenever no language pack exists, and hands over to the pack by itself the day it does. 393 strings, everything the plugin says.

1.16.1

• The Colisly panel on the WooCommerce order now shows each parcel’s internal comment. That is where the operator notes the shelf, the bin or the state of the carton at reception, which is exactly what is needed to find the parcel once the order is paid. Still never shown to the client.

1.16.0

• The client’s “My parcels” tab now shows the stock first, with everything that already left or never will behind a second tab, “Shipped or unavailable”, each with its count. Both tabs, and “My shipments”, are paged twenty rows at a time. A client who has been sending parcels for a year has hundreds of them, and only the ones still in the warehouse are of any use day to day; listing all of them on one page made the tab unreadable exactly for the clients who use it most.

1.15.0

• New: a Colisly panel on the WooCommerce order a shipment created. The forwarder works from WooCommerce > Orders, where payment shows up, but everything about the shipment lived on the client record. The order now shows the shipment, its carrier and destination, each parcel with its weight, dimensions and tracking number, what it declares with the total value, the purchase invoices the client attached, and the customs form to print, with a link to the client record. Works with both order storages. An ordinary shop order is untouched.

1.14.1

• Fixed: the carriers table in the settings was squeezed into fields two characters wide since 1.14.0 added its three limit columns, a width cap that suited seven columns being kept for ten. The table now takes the width it needs and scrolls sideways when the screen has less.

1.14.0

• New: carrier limits. Each carrier can carry a maximum weight, a maximum length and a maximum girth (length plus twice the width plus twice the height), the figures carriers publish and refuse beyond at the counter. The weight applies to the whole shipment, since grouped parcels leave in one carton; the dimensions to each parcel, on those entered at reception. A carrier the ticked parcels exceed is greyed out in the client’s list, and a request that would force it is refused naming the parcel and the limit. A parcel whose dimensions were never entered is not refused on a measurement nobody took. All three are optional and empty by default.
• The weight bracket page reads in the order it applies: each carrier shows its zone grids first, then a grid titled “all other destinations”, with a note saying to leave it empty when every destination served is in a zone. Nothing changes in how prices are computed; the page only says what it does.

1.13.1

• Fixed: a carrier enabled but never priced was offered to clients at 0.00 and the order went through at that price, the fallback formula with an empty base and an empty price per kg being simply zero. A carrier with no rate for the client’s destination is no longer offered, a request that would force it is refused naming the carrier, and the settings warn about enabled carriers that have no rate anywhere. A bracket explicitly set to zero still counts as a price: a forwarder who includes transport in his service typed it on purpose.

1.13.0

• New: purchase invoices for customs. Customs outside the EU ask for the commercial invoice next to the declaration, and only the client has it. He attaches it to each parcel, on the shipment request or on the customs tab, PDF or image, several if needed. The forwarder finds the invoices on the parcel and on the shipment, the printed customs form states how many are attached, and the client reads them back from his documents. Stored in the private directory like every other document, served only through the authenticated download, covered by the privacy export and eraser.
• Every carrier now shows what it would charge for the parcels ticked, right in the carrier list, so the client compares before choosing rather than trying them one by one. The figure follows the same brackets, zones and volumetric rule as the checkout.
• A declared line must carry a value. Customs assess duty on it, so a line without one declared nothing they could use; it is now refused with the parcel and the contents named, on the request as on the customs tab. The form asks for the value as soon as the contents are filled.
• Two columns and one index are added to the documents table on update.

1.12.0

• A customer without a client record yet can be picked straight from the parcel creation form. The search now offers the shop’s registered users alongside the clients, marked as new, and the record is created with the first parcel. Until now every new customer had to be created by hand on the Clients tab before his first parcel could be booked in, which is not where the operator is standing when the parcel arrives. The Clients tab keeps its manual creation for whoever wants a record ahead of time.

1.11.1

• Fixed: the client search, on the parcel creation form and on the parcels list, read the WordPress first and last name only. A customer created by WooCommerce, at checkout or from its Customers screen, carries a billing name and usually no WordPress name at all, so the operator typed the name he saw on every order and found nobody, while the account sat in the Clients tab. The search now matches the billing and delivery names, the company, the phone and the login, and a first name and last name typed together find the client whichever order they come in.
• Clients are named by their billing name when WordPress only knows them by their login, on the Clients tab, the parcels list and the search results alike. “fabrice-1” is not a name anybody recognises.

1.11.0

• Fixed: the declaration form offered a single blank line whatever the limit set in the settings. A cap of three lines was a promise the form never kept, since the client could only ever declare one item per submission, and on the shipment request there is no second submission. A cap now gives the client exactly that many lines; without a cap he gets a few and a button for the rest.
• The quantity, the unit weight and the country of origin can each be turned off. They are what a real CN23 form needs line by line, but a forwarder who only wants to know what a parcel holds before copying it onto his carrier’s own form needs none of the three, and three columns filled for nothing are three columns filled badly. All three stay asked by default, so a site collecting them keeps collecting them.

1.10.0

• The shipment request now shows the delivery address the parcels are actually reshipped to, and a request can no longer be sent while that address is incomplete, with the missing lines named. The form used to ask for a destination country and nothing else, so a request could reach the forwarder with no street to deliver to, and an account that only ever filled a billing address produced an order carrying no destination at all.
• The destination is the address itself rather than a separate menu beside it. The two could disagree, the transport being priced for one country while the label was printed for another, and only the label was true.
• A client can withdraw his own shipment request as long as it is unpaid. It used to be a dead end: the request sat in the orders to pay with nothing on offer but paying it. Withdrawing puts the parcels back in stock and cancels the unpaid order with them.
• Zone countries can be picked by name from the list of countries the shop knows, and the codes already in the field are spelled out underneath, unrecognised ones flagged. Two-letter codes are what a carrier grid is keyed on, but nobody is expected to know that YT is Mayotte.
• The customs declaration on the request form now appears only when the destination actually requires one, instead of for every client as soon as a single zone asked for declarations.

1.9.1

• The declaration is filled where it belongs, on the shipment request, for the parcels being sent. The separate tab stays for clients who prefer to declare each parcel as it arrives; both write the same thing.
• The contents field can be turned into a menu: fill a list of categories in the settings and clients pick from it instead of typing. Empty by default, so nothing is imposed, and no trade’s vocabulary ships with the plugin. The number of lines a parcel may declare can be capped to what your carrier forms hold, uncapped by default.
• The operator reads the whole declaration on the shipment itself, gathered across its parcels with the total declared value, which is the sheet to copy onto a carrier’s own form.

1.9.0

• New: customs declarations. Reshipping outside the customs territory needs the contents of each parcel declared, item by item, and until now the forwarder had to collect that by e-mail. The client now declares his parcels from a Customs declaration tab in his account: description, quantity, unit weight, unit value and country of origin per line. A shipment to a destination that requires one is refused while a selected parcel is still undeclared, with the parcel named.
• Which destinations require a declaration is set on the zones, not guessed. Reshipping from mainland France to Guadeloupe needs one, since the overseas departments sit outside the EU VAT territory, while reshipping to Belgium needs none; a country code cannot tell those apart. Tick the customs column on the zones concerned and nothing changes for anyone who does not.
• The operator prints the declaration from the parcel list or the client record: sender, recipient, one line per item with its tariff number and origin, the totals a customs form asks for, and the certification to sign. It warns when the declared contents weigh more than the parcel itself, which customs would stop on.
• The declaration is personal data: it is disclosed in the privacy export and removed by the eraser, like everything else the plugin holds.

1.8.0

• New: carriers can be billed on volumetric weight. Express carriers price bulk rather than mass, so a carrier can now be marked volumetric with its own divisor, 5000 by default. The transport is then billed on whichever is greater, the real weight or length x width x height divided by the divisor, parcel by parcel. That is how the carriers themselves compute it: billing the volumetric weight instead of the real one would charge a dense 20 kg box in a small carton as 1.6 kg. A parcel whose dimensions were never entered is billed on its real weight rather than on a volume of nothing.
• New: destination zones. A forwarder does not charge the same to reship to mainland France, to the overseas departments and to Madagascar, and a single grid per carrier could never hold real tariffs. Zones group destination countries, and each carrier gets a weight bracket grid per zone. The client picks the destination when requesting a shipment, starting from the shipping address on his account, and the live estimate follows it. A country in no zone, or a zone a carrier was never priced for, keeps that carrier’s default grid, so nothing changes for a site that does not use zones.

1.7.0

• New: optional shipment insurance. Cover levels are set in the settings, a cover amount and what it costs, and the client picks one when requesting a shipment. It appears as its own line on the WooCommerce order and in the client’s shipment list. The price is always read back from the settings rather than taken from the form, so a posted amount can never decide what is billed. No cover level configured means no insurance is offered at all, which is how every existing site starts.
• New: a parcel already in stock can be corrected. Reception happens at the counter, often in a hurry, and until now a wrong weight or a mistyped tracking number had no way back: only the status could be changed. Since the weight sets the price, a typo was billed as it stood. Tracking number, weight, dimensions, photo, internal comment, grouping and allowed carriers are all editable, and correcting the weight recomputes the price.
• Editing stops the moment the parcel leaves stock. A parcel sitting in a shipment the client may already have paid is refused rather than silently repriced, and its client can never be changed after reception. Every correction is written to the client history, naming what changed.
• The carrier table now says when its two prices apply: they are labelled beyond brackets, and a line under the heading states that a carrier is normally priced with a bracket grid and that these two are the fallback. Read on their own they looked like the only carrier pricing there was.
• Fix: the estimate shown to the client on the shipment request ignored the weight brackets added in 1.6.9 and fell back to base price + price per kg. A shipment the checkout billed 45 was announced at 17. The estimate now applies the same rule as the server, and a carrier priced by bracket no longer advertises a price per kg it never charges.

1.6.10

• Fix: on the shipment request screen the parcel table lost its labels. The stacking added in 1.6.8 hides the table header, and each cell is meant to carry its own label instead; this table was the one that did not. Clients saw a bare checkbox followed by three unexplained values. The two other account tables were already correct, which is why it was missed.

1.6.9

• New: each carrier can be given its own grid of weight brackets. Carriers rarely bill per kilo, they publish a grid, and a 6 kg parcel at 45 EUR next to a 15 kg one at 150 EUR fits on no straight line. The first bracket whose maximum weight is greater than or equal to the shipment weight sets the price. A carrier left without a grid keeps billing base price + price per kg exactly as before, so nothing changes on existing sites.
• Beyond the last bracket the price falls back to base price + price per kg, but it can now only ever charge more than the last bracket, never less. A grid stopping at 15 kg used to make a 16 kg shipment cheaper than a 15 kg one.
• Fix: the settings tables grew by exactly one blank row per save, so filling in six weight brackets meant saving six times, and nothing on screen said a seventh row was possible at all. Both tables, and every carrier grid, now have an Add a row button.

1.6.8

• Fix: in the customer account, the parcels and shipments tables were wider than the account column of most themes, so the last column sat off-screen behind a horizontal scrollbar nobody thinks to look for. WooCommerce only stacks these tables under a 768px viewport, but what constrains them is the column, not the window: at a 1600px viewport the six parcel columns still had to fit in 680px. They now stack on the container’s own width.
• New screenshot of the settings screen in the plugin directory listing.

1.6.7

• Fix: a parcel created without stating a grouping decision was stored as “must be shipped alone”, against both the column default and the reception form, where grouping is allowed. Grouping is what the whole trade rests on, so the omission now means allowed.
• Privacy: the personal data export now covers what the eraser deletes. Internal notes on the client record, the internal comment on each parcel and the documents that are not shared with the client were being erased on request but never disclosed on access.
• Fix: refusing an action returned HTTP 500, which reads as a server failure to hosts and monitoring. It now returns 403.
• Fix: the client list printed every page number. It now collapses long ranges and shows the number of records.
• Fix: uninstalling with data removal enabled left the colisly_manage capability on every role and one option behind.

1.6.6

• New: a Settings shortcut on the plugins screen.
• New: a warning on the plugin screens when the store is in coming soon mode or has no payment method enabled, since shipment requests end on the WooCommerce payment page and would otherwise fail with no explanation.
• Fix: adding a client who already has a record announced a creation that did not happen.
• Fix: a pricing tier capped at zero was accepted and silently moved every parcel to the next tier. It is now dropped like an empty row.
• Fix: on narrow screens the parcel dimensions wrapped between a label and its field.
• The allowed carriers help text now states that leaving none checked places no restriction.