---
suivi: 1618
date: 2026-09-18
sujet: Acompte — clé APPYMT pour payer un APADVANCE (complément #1616)
chantier: comptabilite / sage / acompte
type: diagnostic
statut: poussé
hash: f80ac145
fichiers:
  - app/Http/Controllers/Admin/IntacctController.php
  - tests/Unit/IntacctProbeApadvanceClePaiement1618SourceTest.php
  - tests/Unit/IntacctProbeApadvance1614SourceTest.php
  - tests/Feature/IntacctProbeApadvance1614Test.php
  - docs/suivi/SUIVI_1618_apadvance_cle_appymt.md
---

# SUIVI #1618 — clé APPYMT pour un APADVANCE (complément #1616)

## PROMPT ENVOYÉ

Complément #1616. La mise en paiement facture existe déjà : APPYMT +
ACH → Sage « Générer des fichiers de paiement bancaire ». L’acompte
doit emprunter ce circuit, pas un mécanisme nouveau. Seule inconnue :
par quelle clé un APPYMT désigne un APADVANCE. ADVANCEKEY = sens
inverse (consommer un acompte payé sur une facture). Si la clé n’est
pas certaine : le dire, création déjà livrée (#1616), paiement plus
tard. Ne rien deviner.

## FICHES LUES

- **#1616 LEÇON** — créable XML ≠ payable ; ADVANCEKEY = application
  d’un acompte payé ; pas intacct_bill_id. Impact : le verdict #1616
  « ACH hors écran ERP » est **corrigé** : ACH est le PAYMENTMETHOD
  du même APPYMT. L’exclusion de la file à payer reste (clé inconnue).
- **#1614 LEÇON** — même route, GS_DSI brut, jamais fields=*. Impact :
  lectures lookup APPYMT/APPYMTDETAIL enrichies (id + LABEL).
- **#1613 LEÇON** — m365GroupNames brut. Impact : sonde inchangée
  (GS_DSI). Compte refus : GS_ADMIN_ERP sans GS_DSI.

## SYNTHÈSE

### Verdict — clé APPYMT pour APADVANCE : NON ÉTABLIE

Circuit à étendre (pas à dupliquer) :

- Fichier : `app/Services/IntacctService.php`
- XML : `buildAppymtCreateXml`
- Envoi : `createAppymtForBill`
- Appelant : `PaiementAppymtExecutionService::executerLigne`
- Entête : FINANCIALENTITY, PAYMENTMETHOD, VENDORID, PAYMENTDATE
- Ligne : RECORDKEY = APBILL RECORDNO, TRX_PAYMENTAMOUNT
- PAYMENTMETHOD : `PaiementModeReglementMapper::toIntacctPaymentMethodForAppymt` — virement à régler → ACH

Pour un acompte : même XML, PAYMENTMETHOD = ACH. Inconnue = la clé
à la place de RECORDKEY.

ADVANCEKEY (doc XML) = consommer un acompte **déjà payé** sur le
paiement d’une facture. Ce n’est pas payer l’acompte.

Aucun APPYMT réel payant un APADVANCE n’a été lu dans ce lot (la
sonde le cherchera en prod : RECORDKEY, ADVANCEKEY, autres *KEY
dont id/label évoque avance). Tant que la lecture live ne tranche
pas, **ne pas étendre** `buildAppymtCreateXml`.

Création APADVANCE (#1616) inchangée. Paiement non livré.

Sonde : `synthese.paiement.appymt_champs_acompte` et
`appymtdetail_champs_acompte` (tous les champs id/label advance,
avance, acompte, apadvance). Patron ERP dans
`synthese.paiement.patron_erp_appymt_facture`.

## DÉPLOIEMENT-TEST

1. `git pull origin main`
2. `php artisan optimize:clear` + `view:clear`
3. Compte **GS_DSI** : GET `/admin/intacct/probe-apadvance?entity=E-13&recordno=686056`
4. Lire `synthese.paiement.appymtdetail_champs_acompte`,
   `appymt_champs_acompte`, `appymtdetail_recordkey_temoin`,
   `appymtdetail_advancekey_temoin`, `temoin_advance_paid`.
5. Refus : GS_ADMIN_ERP sans GS_DSI → 403.

## LEÇON

Le fichier bancaire ACH n’est pas un circuit à part : c’est la
suite Sage d’un APPYMT déjà créé par l’ERP. La question n’est pas
« comment on paie un acompte » mais « quelle clé Sage attend à la
place de RECORDKEY ». ADVANCEKEY documenté ≠ cette clé. Ne pas
mettre un RECORDNO d’APADVANCE dans RECORDKEY tant qu’un APPYMT
témoin ne l’a pas prouvé.