Il fornitore e i suoi default
Ogni vendor appartiene a un vendor group, che porta i default operativi (terms of payment, delivery terms, criteri di raggruppamento nei report) e che può essere usato come chiave di selezione dei posting profile. Il vendor posting profile è il ponte fra il documento e la contabilità: definisce il summary account su cui atterra il debito quando la vendor invoice viene posted, e si può assegnare per Table (un singolo fornitore), per Group oppure per All, con la regola che il livello più specifico prevale. Per gli anticipi esiste un posting profile dedicato ai prepayment, così che l’acconto non si confonda con il debito commerciale. All’esame la domanda non è “come si crea”, ma “a quale livello lo configuro”: se il requisito è isolare i fornitori esteri o intercompany su un conto distinto, la risposta è un posting profile associato al group, non un main account digitato sulla riga di fattura. Nota pratica: l’esame è disponibile solo in inglese e giapponese, quindi memorizza i nomi degli oggetti nella lingua originale.
Fatture, matching e vendor settlement
Una fattura può entrare da sola (vendor invoice journal, oppure invoice register e invoice approval journal quando serve rilevare subito il costo in attesa di approvazione) o essere collegata a un purchase order. Nel secondo caso interviene l’invoice matching: two-way matching confronta il prezzo con l’ordine, three-way matching aggiunge il confronto con il product receipt, e le tolerance definiscono quanta discrepanza è accettabile prima che la validazione segnali l’errore. La matching policy si imposta a livello di legal entity e si può affinare per vendor o per item: è il classico caso in cui il controllo va messo il più a monte possibile, perché una discrepanza intercettata in fase di validazione costa una correzione, mentre la stessa discrepanza scoperta dopo il posting costa una nota di credito o una rettifica contabile.
Distinzione decisiva: il settlement non è il pagamento. Il pagamento genera un movimento verso il bank account; il settlement è l’operazione che abbina la transazione aperta (fattura) con quella di segno opposto (payment, credit note, prepayment), chiude la partita e calcola l’eventuale cash discount o la differenza cambio in valuta estera. I due eventi possono coincidere se l’automatic settlement è attivo, ma restano concettualmente separati: si può pagare senza settlement (fattura ancora aperta nell’aging) e si può fare settlement fra due documenti senza alcun flusso di cassa.
Proposta di pagamento e metodi
Il payment journal si popola tramite payment proposal, che seleziona le transazioni aperte per due criteri combinabili: due date e cash discount. Scegliere “due date and cash discount” significa anticipare i pagamenti che meritano lo sconto e lasciare gli altri alla scadenza naturale. Il method of payment governa il resto: file format per l’invio in banca, payment status per il ciclo none/sent/approved, prenote per validare i dati bancari prima del primo pagamento reale, e l’eventuale bridging account quando serve un conto ponte fra emissione e riconciliazione bancaria. Nei gruppi si usano i centralized payments per pagare da una legal entity per conto di altre, con generazione automatica delle scritture due to / due from.
Expense management
Il modulo copre note spese, carte aziendali e trasferte. Le expense policy validano al momento dell’inserimento, non dopo: una violazione può essere impostata come warning (l’utente prosegue motivando) o come error (la sottomissione è bloccata). A monte c’è la travel requisition, cioè l’approvazione preventiva della spesa; a valle il workflow di approvazione dell’expense report, con possibilità di auto-approvazione entro soglie. Le credit card transaction vengono importate e riconciliate contro le righe della nota spese, le voci personali si marcano come non rimborsabili, e per vitto e trasferte esistono per diem rule e mileage. Il rimborso al dipendente e il pagamento all’emittente della carta seguono percorsi contabili diversi, definiti nella configurazione del modulo.
Trappole tipiche d’esame
- Bloccare le fatture con prezzo o quantità superiori all’ordine → matching policy e tolerance, non un workflow di approvazione: il workflow instrada, non confronta; solo l’invoice matching applica three-way matching contro product receipt.
- Il pagamento è stato registrato ma la fattura risulta ancora aperta → manca il settlement: non è un problema di posting profile né di method of payment; serve settle open transactions o l’automatic settlement.
- Conto di debito diverso per una categoria di fornitori → vendor posting profile per group: non si forza il main account sulla riga della fattura, perché la scelta si perderebbe sui documenti futuri.
- Pagare solo ciò che scade e ciò che dà sconto → payment proposal con due date e cash discount: non si filtra a mano la lista, e non si modifica la fattura per applicare lo sconto.
- Impedire la spesa fuori policy prima che venga sostenuta → travel requisition: l’expense policy con severità error blocca la nota spese, ma la trasferta è già avvenuta; il controllo utile sta prima.
- Una legal entity paga per conto delle altre → centralized payments: non un journal manuale, perché servono le scritture due to / due from automatiche.
Per i dettagli di configurazione fai sempre riferimento alla documentazione ufficiale Microsoft Learn: il passing score è 700/1000 e le domande privilegiano la scelta del meccanismo corretto, non la sequenza di click.