-- Achat > Bons de Livraison : facturation differee a la cloture + suivi façon "Etat" (26/07/2026)
-- La decision facture/non-facture n'est plus prise a la creation du bon (stocks_alimentation) mais
-- a sa cloture. A la cloture, 3 choix : transformer en facture (type='facture', comportement
-- inchange sauf que la ligne fournisseur_facture est desormais creee ici) ; suivre (suivi=1, le bon
-- alimente le nouveau regroupement fournisseur_etat/fournisseur_bon, meme principe que
-- client_etat/client_bon cote Vente) ; ou simple bon d'entree sans suivi (comportement non_facture
-- actuel, inchange). Les bons deja crees avant cette migration gardent leur `type` deja pose et se
-- cloturent exactement comme avant (aucune regression).

ALTER TABLE `stocks_alimentation`
  MODIFY `type` VARCHAR(20) NULL DEFAULT NULL,
  ADD COLUMN `reference` VARCHAR(50) NULL AFTER `livreur`,
  ADD COLUMN `suivi` TINYINT(1) NOT NULL DEFAULT 0 AFTER `type`;

-- Mirroir allege de client_bon (Vente) : uniquement ce qui sert au regroupement/etat, pas de
-- matricule/carte/telecollecte (propres au Vente, non pertinents cote fournisseur).
CREATE TABLE `fournisseur_bon` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `id_fournisseur` INT(11) NOT NULL,
  `date_bon` DATE NOT NULL,
  `montant` DECIMAL(10,2) NOT NULL DEFAULT 0.00,
  `source` VARCHAR(30) NOT NULL,
  `id_source` INT(11) NOT NULL,
  `id_etat` INT(11) NOT NULL DEFAULT 0,
  `id_creation` INT(11) NOT NULL,
  `date_creation` DATETIME NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_idetat` (`id_etat`),
  KEY `idx_idfournisseur_datebon` (`id_fournisseur`, `date_bon`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;

-- Mirroir allege de client_etat.
CREATE TABLE `fournisseur_etat` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `id_fournisseur` INT(11) NOT NULL,
  `date_debut` DATE NOT NULL,
  `date_fin` DATE NOT NULL,
  `montant` DECIMAL(10,2) DEFAULT NULL,
  `nombre` INT(11) DEFAULT NULL,
  `reference` VARCHAR(50) NOT NULL,
  `annee` INT(11) NOT NULL,
  `num` INT(11) NOT NULL,
  `id_creation` INT(11) NOT NULL,
  `date_creation` DATETIME NOT NULL,
  `id_cloture` INT(11) DEFAULT NULL,
  `date_cloture` DATETIME DEFAULT NULL,
  `date_echeance` DATE DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_idfournisseur` (`id_fournisseur`),
  KEY `idx_idcloture` (`id_cloture`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;

-- Mirroir de client_remplacement : ticket generique de reglement d'un fournisseur_etat, une ligne
-- par methode (espece/piece/operation/avoir/avance), meme pattern que fournisseur_paiement
-- (reglement) mais pour cette nouvelle couche "etat" (regroupement en amont de la facturation).
CREATE TABLE `fournisseur_remplacement` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `source` VARCHAR(20) NOT NULL,
  `date_remplacement` DATE NOT NULL,
  `id_etat` INT(11) NOT NULL,
  `montant` DECIMAL(10,2) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_source_idetat` (`source`, `id_etat`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;

-- Nouvelle colonne de consommation dediee a la couche Etat (distincte de id_remplacement deja
-- reserve au mecanisme PieceRemplacement, et de id_reglement/id_paiement deja utilises par la
-- couche Reglement) : permet d'attacher un avoir/une avance fournisseur existant(e) comme methode
-- de reglement d'un fournisseur_etat, sans collision avec les usages existants.
ALTER TABLE `fournisseur_avoir`
  ADD COLUMN `id_etat_remplacement` INT(11) NOT NULL DEFAULT 0;

ALTER TABLE `fournisseur_avance`
  ADD COLUMN `id_etat_remplacement` INT(11) NOT NULL DEFAULT 0;
