Version 0.0.3

Caisse 2.8.3

  • Chiffre d’affaires entre Gc5 & caisse
Problème Le chiffre d’affaires annoncé par la caisse depuis le Z de caisse ou le menu « Caisse à C.A. » peut être différent avec celui de Gc5
Cause Uniquement lorsqu’il y a des crédits repris
Solution Sur impression du Z de caisse ou affichage du Chiffre d’affaires ( menu Caisse àC.A.) ne pas tenir compte des règlements des crédits repris dans le calcul du chiffre d’affaires, car ces montants ont déjà été comptés lors du crédit émis.(Modif dansCaModeReglement.ajouterValeur) prendre uniquement lestypeReglement == « ENCAISSER » et pas « CREDIT_REPRIS »

 

 

 

  • Encaissement du règlement et Z de caisse
Problème Le chiffre d’affaires d’une caisse peut être crédité de certains encaissements d’une autre caisse. Idem si crédit émis sur caisse 1 et repris sur caisse 2.
Cause un ticket créé sur la caisse 1 (encaissé ou mis en attente) peut être rappelé et ré-encaissé sur la caisse 2 dans un mode de règlement différent. Le programme ne tenait pas compte de l’encaissement par la caisse 2 et l’affectait à la caisse 1, car c’est elle qui avait créé initialement le ticket.
Solution Lors du calcul du chiffre d’affaires prendre le numéro de caisse qui a encaissé le ticket et non celui qui a créé le ticket.(Modif ChaineSqlGc.selectChiffreAffairesParModeReglement)

 

Nouveaux champs dans la table « reglement » :

  • cai_numero_magasin_effectue
  • numero_caisse_effectue

 

  • Rappel ticket et changement TVA
Problème Si ancien ticket rappelé après changement de TVA, c’est la nouvelle taxe qui est prise et non celle au moment de l’encaissement. La valeur TTC est toujours ok mais pas la valeur HT
Cause Pour retrouver le HT du ticket on prend celle de l’article à l’instant T
Solution Stocker les données des taxes à l’encaissement sur les lignes ticket et l’utiliser dans les traitements du programme de caisse.Dans classe et la table de la bbd LigneTicket ajout de variables : tauxTaxe et codeTaxe

  • Renseignés dès l’affectation d’un article à une ligne
  • Utilisés sur la requête Sql insert ligne_ticket
  • Utilisés dans la classe Ticket.getRepartitionTva()

Ces champs impactent également les fonctionnalités suivantes :

  • Application tarif (ex :sur place),
  • Nomenclature & détail nomenclature,
  • recup ticket si plantage (fichier texte)
  • article libre
  • Calcul du HT pour magic
  • Et GC5

 

 

Gc5

  • Pièce Achat Vente, accès à la dernière ligne
Problème Sur les écrans des pièces Achat ou Vente, si toutes les lignes sont remplis, lorsqu’on ajoute un article sur la dernière ligne, on affecte la quantité, et on appuie sur la touche du clavier « flèche bas ». On ne passe pas sur la ligne vierge suivante.
Cause Les lignes sont virtualisées afin d’accélérer  leurs affichage à l’écran si la pièce contient beaucoup de ligne. Lors de l’ajout d’un article sur la dernière ligne, la programme créé automatiquement une ligne vierge pour la prochaine saisie. Cependant il est impossible de se déplacer (changer le focus) sur une ligne virtuelle.
Solution Dans ce cas, faire dérouler la ScrollBar jusqu’à la nouvelle ligne vierge virtualisée afin de l’afficher pour la 1er fois. Méthode « textBox_PreviewKeyDown »
  • Calcul fin de journée pour crédit émis et repris
Problème Le chiffre d’affaires d’une caisse peut être crédité de certains encaissements d’une autre caisse. Idem si crédit émis sur caisse 1 et repris sur caisse 2.
Cause un ticket créé sur la caisse 1 (encaissé ou mis en attente) peut être rappelé et ré-encaissé sur la caisse 2 dans un mode de règlement différent ou pour les crédits repris. Le programme ne tenait pas compte de l’encaissement par la caisse 2 et l’affectait à la caisse 1, car c’est elle qui avait créé initialement le ticket.
Solution Modification du script de création des tables d’archives pour la table « reglement »

  1. createTableTicketCaisse

Nouveaux champs dans la table « reglement » :

  • cai_numero_magasin_effectue
  • numero_caisse_effectue

 

Modification du programme d’importation des tickets

ControleurCaisse.chargerReglementTicket

ChaineSqlCaisse.insertTicket

 

 

Modification du calcul du C.A. par mode de règlement

ChaineSqlTicketCaisse.selectTicketCaisseAvecCreditEmis

ChaineSqlTicketCaisse.selectChiffreAffairesParModeReglement

 

Problème Pendant la journée en cours si un ticket est rappelé pour modifier son mode de règlement et que la programme de fin de journée était lancé alors il se peut que le ticket soit compté deux fois. Exemple : ticket en BOA puis modifié en CHT. Ce ticket se retrouvera alors dans les deux modes de règlement
Cause Rechargement des données puis recalcule dans un 2ème temps. Ainsi le BOA est rechargé et le CHT s’ajoute. Alors que le BOA devrait disparaitre au profit du CHT
Solution Dans programme de fin de journée, si Jour J, ne pas recharger les données mais uniquement les recalculer.

 

  • Impression des remises en banque
Problème Lors de l’impression du journal de remise en banque un message d’erreur peut apparaitre indiquant une clé dupliquée sur l’insertion de données dans le fichier « fin_journee_gc_remise_banque »
Cause Avant l’impression, le programme va rechercher les règlements liés aux pièces soldées (Relevé de facture). Cette lecture est faite à partir des fichiers  « piece_reglement_2013 » et « piece_reglement_2014 ». Ainsi si le même règlement est utilisé dans ces deux fichiers on peut se retrouver avec le même mode règlement pour 2 montants différents (une somme pour 2013 et une pour 2014). Le fichier « fin_journee_gc_remise_banque » n’accepte pas les doublons et veux une seule somme pour les deux fichiers.
Solution Modifier la requête « ChaineSqlPieceGestion.getRemiseEnBanquePieceGestion ». Au lieu de faire deux sommes pour les deux fichiers et ensuite le « union » pour regrouper les deux résultats. Faire le « union » sur les deux fichiers et ensuite faire la somme regroupée par mode de règlement

 

 

 

  • Facturation des CS en FC
Problème Les pièces de vente CS (cessions) passées en FC peuvent ne pas avoir le même montant HT
Cause Si dans la table « type_piece_gestion » la

  • CS est paramétrée en HT
  • FC est paramétrée en TTC

 
Solution Lors de la mutation, si la pièce d’origine est en HT et que la pièce de destination est en TTC (exemple : CS en HT à FC en TTC). La FC sera alors calculée en HT ainsi pas d’écart de montant.ControleurPieceGestion.muterObjetEntetePiece()

 

// Si la pièce CS (cession en HT) est mutée en FC (facture TTC) : la facture sera gérée en HT et pas en TTC

if (pieceOrigine.pDonneesBrutesEntete.typePrix == TypePrix.HT && pieceMutee.pDonneesBrutesEntete.typePrix == TypePrix.TTC)

pieceMutee.pDonneesBrutesEntete.typePrix = TypePrix.HT;

else if (pieceOrigine.pDonneesBrutesEntete.typePrix == TypePrix.TTC && pieceMutee.pDonneesBrutesEntete.typePrix == TypePrix.HT)

pieceMutee.pDonneesBrutesEntete.typePrix = TypePrix.TTC;

 
  • Importation des tickets

Comme la table « ligne_ticket » possède maintenant 2 nouveaux champs :

Modification du programme de chargement des tickets

  • ControleurTicketCaisse.chargerLigneTicket
  • Dans ETL ControleurCaisse.chargerLigneTicket

 

  • Modification des classe Ticket et LigneTicket, pour faire les calculs à l’aide du champ code_taxe et taux_taxe au niveau de la ligne ticket et non de l’article. Comme cela a été modifié pour le programme de caisse (même modif pour les deux classes dans caisse et gc5)