Mois : juillet 2014

J’ai acheté le Hi4G

Après 4 ans de bons et loyaux services mon Samsung Galaxy Spica est devenu difficilement utilisable et sa batterie limite son autonomie à quatre heures en veille. Il me fallait donc un nouveau smartphone avant de partir en vacances. Après avoir recherché sans succès un mobile 4G double SIM et attendu en vain que le OnePlus One soit disponible pour le commun des mortels, j’ai choisi le Hi4G.

Je le conseille à tous ceux qui souhaitent acheter un smartphone pas cher ayant un très bon rapport qualité/prix. C’est en fait un ZTE Blade Apex 2 distribué en France exclusivement par le groupe Orange en marque blanche.

Quelques points à noter :

  • il est compatible 4G catégorie 4 (jusqu’à 150 mbps en réception sur les réseaux compatibles comme Free ou Orange)
  • il possède 1024 Mo de RAM, un écran de 4″5 et un processeur Qualcomm Snapdragon 400 (1,2 GHz Quad-core), 8Go de ROM
  • il possède un port microSDHC pouvant étendre la mémoire morte à 32 Go
  • la batterie ne peut pas s’enlever
  • je n’ai pas encore trouvé de tutoriel pour le rooter

Plus de détails et un test complet sur le site de 01.net.

Ce mobile semble avoir baissé de dix euros depuis son lancement fin avril et coûte aujourd’hui 119€90 tant en boutique que sur le site internet. Sachez que vous n’êtes pas obligé de prendre la Mobicarte(gratuite) qui sera proposée par le vendeur. J’ai acheté le mien seul, sans aucune carte SIM venant de chez Orange.

Point très important : en achetant ce mobile seul ou avec une Mobicarte (ou toute offre « non engageante » Orange), il est possible d’obtenir le code de desimlockage gratuitement et immédiatement après l’achat. Je suis tombé sur un vendeur très sympa bien qu’un peu à coté de la plaque car il n’était pas au courant des procédures de desimlockage de l’opérateur pour lequel il travaille ! C’est pourtant le B.A.BA.

Conformément à la loi Hamon entrée en vigueur en juin, la garantie de conformité est de 24 mois(comme indiqué sur l’étiquette produit en boutique). Pour en bénéficier au-delà des six premiers mois, le consommateur devait auparavant prouver lui-même que le défaut était présent au moment de l’achat. Orange vendant ce téléphone sous sa propre marque, ce sont ses vendeurs qui devront assurer le service après-vente que l’on ait ou pas souscrit un abonnement chez eux.

MAJ du 10 août 2014 : Après vérifications, le dernier paragraphe de mon article comptait un certain nombre d’erreurs :

  • d’après cet article concernant la loi Hamon : Concernant le passage du délai de six mois à deux ans de la garantie légale de conformité, il faudra attendre deux ans après la publication de la loi, soit le 17 mars 2016.
  • l’inscription « SAV 24 mois » sur les étiquettes des produits en boutique Orange n’est valable que si l’on possèdes toujours la ligne Orange qui a été souscrite (ou renouvelée) en même temps que l’achat du mobile
  • le Hi4G est bien vendu sous la marque commerciale Orange mais comme ZTE apparaît bien sur l’étiquette de la boite de l’appareil, c’est ZTE qui est tenu d’assurer le service après vente constructeur en cas de défaut matériel
  • cette garantie constructeur est valable 12 mois pour les produits achetés en juillet 2014
  • pour faire valoir cette garantie constructeur gratuite de 12 mois, on peut renvoyer le produit par colis ou bien aller dans l’une des 170 boutiques PSM (Point Service Mobile) agréées par ZTE

Retour sur le code sprint POS chez Akretion

J’ai eu le plaisir d’être accueilli dans les locaux lyonnais d’Akretion du 7 au 10 juillet pour développer deux briques communautaires du module Point Of Sale d’Odoo(ex-OpenERP) :

  • la gestion des afficheurs clients LED (typiquement deux lignes de vingt caractères)
  • l’envoi du montant au lecteur de carte bancaire ou éventuellement à l’imprimante de chèques (protocole CONCERT)

Chaque fonction est intégrée via deux modules distincts : l’un modifie le serveur OpenERP et le front-end Javascript du POS et l’autre joue le rôle de driver au sein du proxy hardware développé par OpenERP SA embarqué dans la POSbox. L’ensemble du code est actuellement disponible sur Launchpad et devrait bientôt être mergé dans un projet de l’OCA sur Github.

Au cours de ce code sprint j’ai également commencé à développer un module pos_payment_method_option permettant:

  • de spécifier dans l’objet account.journal si l’utilisation de cette méthode de paiement doit déclencher l’ouverture du tiroir caisse
  • spécifier dans account.journal si le restant dû doit être saisi automatiquement
  • spécifier dans account.journal si la vente doit être validée automatiquement (éviter l’écran de rendu monnaie)
  • afficher les boutons correspondant aux méthodes de paiement sur deux colonnes

Bien qu’il reste encore pas mal de choses à peaufiner dans les modules front-end que j’ai écrits, cela ne m’a pas empêché de rêver aux extensions possible du POS.

Les modules suivants devraient être disponibles dans les Addons officiels en v8 :

  • menu de sélection du client
  • gestion des tables
  • gestion des imprimantes ticket coté cuisines
  • gestion des promotions et de la fidélité

Ces modules représentent une grosse avancée mais comme toujours, certaines fonctions pourraient être ajoutées :

  • la segmentation des tickets par vendeurs avec un code, un code-barres ou une clé Dallas personnelle
  • la synchronisation des tickets en cours pour chaque vendeur sur toutes les caisses
  • le partage d’un périphérique (le lecteur de CB par exemple) entre plusieurs caisses alors que cette caisse possède sa propre POSbox pour l’afficheur client et l’imprimante tickets. Cela implique la connexion à plusieurs POSbox pour chaque caisse et le routage des flux au sein du proxy.
  • l’accès au backend en mode ResponsiveDesign afin de pouvoir saisir un nouveau client ou une nouvelle commande aisément depuis un écran tactile sans devoir recréer des vues spécifiques
  • gestion de la réservation des tables de restaurant
  • gestion des formules : une ligne d’en tête portant le prix et des lignes filles portant les composants à déstocker parmi un choix restreint. La détection automatique des formules à partir des éléments serait aussi un plus mais pourrait se frotter à une explosion combinatoire
  • le changement de méthodes de règlement à posteriori (avant la clôture de la session)
  • la réimpression de tickets à posteriori
  • pour les commerçants qui souhaitent utiliser l’écran de rendu monnaie, ajouter un bouton avec image pour chaque billet ou pièce possible permettant d’incrémenter le paiement en cash
  • la clôture « en aveugle » de la caisse (en option) : le responsable clôture la caisse sans avoir accès au chiffre d’affaire théorique ni au fond de caisse qui en découle. Cette technique est parfois utilisée pour détecter les vendeurs faisant trop d’erreurs ou essayant de taper dans la caisse
  • imprimer les tickets à la demande. Notez que s’il on choisit de valider automatiquement une vente dès l’appuie sur le bouton « Cash », il faudra soit prévoir de stocker le ticket précédent (sérialisé pour l’impression) dans un PosModel.last_order_xml soit prévoir un bouton permettant l’impression du ticket pour la vente en cours lors de sa validation
  • gestion plus fine des droits coté client : un manager doit rentrer son code pour supprimer un ticket ou une ligne, modifier un prix, mettre une quantité négative ou saisir un rabais manuellement

Comme l’a suggéré Anthony Lesuisse (CTO d’OpenERP SA) sur Twitter, il serait aussi intéressant de développer un afficheur client à base d’écran LCD classique branché en HDMI sur la POSbox. Cela serait plus gourmand en énergie et en place sur le comptoir mais ça apporterait un confort visuel et une grande souplesse. L’on pourrait pousser le concept jusqu’à intégrer des publicités du commerçant ou bien de tiers. L’afficheur client deviendrait une source de revenu complémentaire en transformant le commerçant en une régie publicitaire. Les annonceurs pourraient même associer leur annonce à des produits vendus avec un système d’enchères comme le fait GoogleAdds… C’est beau de rêver.