Categoria: Informatica aziendale

Per il controllo ATP su ordini di vendita esistono report e BAPI specifiche da utilizzare ma certe volte vi potrebbe capitare di dover eseguire un controllo all’interno di un flusso dell’ordine o addirittura eseguire il controllo in un altro processo particolare per aggiornare la disponibilità.

Le funzioni centrali del server ATP sono nel gruppo programmi SAPLATP, questo è il core del calcolo sui segmenti, quelli che eseguono la disponibilità sull’ordine di vendita sono all’interno del gruppo programmi SAPMV45 e nello specifico si tratta dei form FCODE_BVFP per ATP sull’intero documento e form FCODE_PORE per il singolo item.

Se siete all’interno dell’elaborazione dell’ordine di vendita ( VA01 o VA02) e quindi avete gia caricato in memoria le tabelle potrete semplicemente richiamare queste due funzioni tenendo sempre in grande considerazione il flusso del programma.

Per poter eseguire la disponibilità al di fuori dell’elaborazione dell’ordine di vendita dovete sapere alcune regole nella logica SD di SAP, come ad esempio il fatto che la disponibilità è sempre una condizione sottostante ad un controllo credito positivo del BP e che il credito impegnato totale standard è calcolato sulla merce che ha conferma di disponibilità.

Per questo per poter eseguire con successo l’ATP su un documento o un singolo item al di fuori dell’elaborazione ordine di vendita, dovreste prima caricare i dati del documento di vendita e poi fare sempre il controllo credito che predispone il server ATP, una volta fatto questo potete caricare i dati dell’item in memoria per poi eseguire il controllo su quest’ultimo.

Questo un esempio di esecuzione:

IF lv_vbeln NE '' AND lv_posnr NE '000000'
     CALL FUNCTION 'SD_SALES_DOCUMENT_READ'
        EXPORTING
          document_number = lv_vbeln
        IMPORTING
          evbak           = vbak
          evbakkom        = vbakkom
        EXCEPTIONS
          error_message   = 01.
      IF sy-subrc NE 0.
        CHECK 1 = 0.
      ENDIF.
      
      IF vbakkom-lifsk EQ '01'.
        CALL FUNCTION 'SD_SALES_DOCUMENT_PERFORM'
          EXPORTING
            in_program    = 'SAPFV45K'
            perform       = 'KREDITLIMIT_PRUEFEN_BEI_CALL'
          EXCEPTIONS
            error_message = 01.
        IF sy-subrc NE 0.
          CHECK 1 = 0.
        ENDIF.
      ENDIF.
    ENDON.

    CALL FUNCTION 'SD_SALES_ITEM_READ'
      EXPORTING
        item_number         = lv_posnr
      IMPORTING
        evbap               = vbap
        evbapkom            = vbapkom
      EXCEPTIONS
        error_message       = 01
        item_number_missing = 02.
    CALL FUNCTION 'SD_SALES_ITEM_TABLES_READ'
      EXPORTING
        item_number         = lv_posnr
      TABLES
        exvbep              = xvbep
      EXCEPTIONS
        error_message       = 01
        item_number_missing = 02.

    IF vbakkom-lifsk NE vbak-lifsk.
      da_save = charx.
    ENDIF.

    " ATP sulla posizione
    IF vbak-lifsk EQ ' '.
      CALL FUNCTION 'SD_SALES_DOCUMENT_PERFORM'
        EXPORTING
          in_program    = 'SAPMV45A'
          perform       = 'FCODE_PORE'
        EXCEPTIONS
          error_message = 01.
      IF sy-subrc NE 0.
        IF p_spool = abap_true.
          CLEAR ls_pos_log.
          MOVE-CORRESPONDING ls_pos_odv TO ls_pos_log.
          ls_pos_log-type = 'FCODE_PORE(SAPMV45A)'.
          ls_pos_log-id = sy-msgid .
          ls_pos_log-number = sy-msgno.
          MOVE 'Errore disponibilità ATP' TO ls_pos_log-message.
          APPEND ls_pos_log TO  p_t_pos_odv_log[].
        ENDIF.
        CHECK 1 = 0.
      ENDIF.
      da_save = charx.

  ENDIF.

Nel mondo SAP il linguaggio di sviluppo principale è ABAP, Advanced Business Application Programming : questo linguaggio è stato ideato per manipolare e rappresentare dati, il codice dell’ERP è stato scritto sin dalla nascita in questo linguaggio che è stato continuamente migliorato fino ai giorni nostri, release 7.55 e ABAP 2022 con S/4HANA.

Intorno al 2004 con la piattaforma NetWeaver e l’avvento dell’architettura orientata ai servizi gli si è affiancato Java, una scelta naturale visto l’ambito di utilizzo di questo linguaggio: l’application server SAP è quindi formato da due stack, uno ABAP e uno Java integrati fra loro.

Per anni lo sviluppo è stato circoscritto agli strumenti della SAPGUI, l’interfaccia grafica proprietaria che incorpora tutti gli strumenti necessari allo sviluppo e che finchè lo stack era solo ABAP era sufficiente a qualsiasi sviluppatore SAP. Gli strumenti della SAPGUI sono stati continuamente migliorati fino ad arrivare alle potenti transazioni che conosciamo oggi, solo alcuni esempi: la SE11 per la creazione e gestione delle strutture dati, la SE38 e ancora meglio la SE80 per la gestione del codice, SE10 e STMS per la gestione dei cambiamenti e dei trasporti. Chi come me sviluppa su SAP da più di un decennio conosce a menadito questi strumenti e posso dirvi che non sono proprio intuitivi, prevedono uno sforzo iniziale importante nella curva di apprendimento che va colmata con tanti concetti dietro le scene ma una volta sorpassato il picco iniziale si ottiene un’ottima produttività, direi la produttività massima possibile quando si arriva a padroneggiarli

Per lo sviluppo dello stack Java invece è stato preso Eclipse come riferimento, inizialmente sviluppato da IBM e poi sostenuto dalla comunità open source : su questo sono stati sviluppati nel tempo dei plugin per la gestione e programmazione del database e dello stack NetWeaver, Developer Studio copre l’intero ciclo di vita di un’applicazione Java in SAP ed Hana Studio è specifico della gestione del database.

Negli ultimi anni visto che solo l’ambito ABAP era rimasto fuori da Eclipse ,l’azienda ha pensato bene di accorpare tutto in questo software dando vita a ADT – ABAP Development Tools . ADT come la SAPGUI, offre gli strumenti di syntax check ed highlight, code completion, code refactoring e pretty printing con una interfaccia grafica semplice e personalizzabile che permette di editare e tenere sotto controllo contemporaneamente piu oggetti di implementazione, gestire le nuove view database chiamate Core Data Services, tenere sotto controllo il sistema di trasporto e molto altro.

ADT è uno strumento molto potente che sarà continuamente migliorato, offre una notevole produttività e migliora ambiti come l’auto completamento e l’introspezione, la generazione automatica di classi e metodi locali, il re-factoring del codice ma ancora c’è qualche aspetto dove la SAPGUI è superiore, come il debugging avanzato specialmente quando si cerca di andare nel punto di interruzione dopo che è cambiata la struttura di un metodo piuttosto che si voglia editare contemporaneamente ad altri utenti una stessa classe ( intendiamoci a breve anche queste piccole cose saranno sanate).

Quindi i due strumenti praticamente si equivalgono, i pro ed i contro sono veramente pochi e molto personali, dipendono piu che altro dal bagaglio di esperienza sull’uno o sull’altro e quindi dalla conoscenza che si ha di esso.

Secondo il mio modesto parere, se si sviluppa solamente ABAP oppure se si è abituati a sviluppare e testare sulla SAPGUI non è conveniente passare ad ADT, non c’è nulla in meno e comunque ne avremo bisogno per testare i programmi.

Pensando a chi scrive solamente codice magari nei due stack oppure ad un nuovo nuovo sviluppatore ABAP che magari ha gia esperienza in Eclipse passare ad ADT sarà naturale.

Il vero punto di forza di Eclipse è la potenza dell’interfaccia grafica, intesa nel veloce passaggio ad altri oggetti o task e di alcuni strumenti come il refactoring, ADT è molto piu vicina all’idea di un’IDE di programmazione.

Per chi non abbandona mai l’ERP o ABAP comunque le possibilità della SAPGUI la rendono piu produttiva e soprattutto piu completa, ci vorrebbero anni prima di arrivare a tanto con ADT.

Buon ABAP a tutti!

La pianificazione aziendale come la pianificazione personale è un’attività importantissima per poter raggiungere un obiettivo nel tempo e nel modo che ci siamo prefissati. Per gestire la pianificazione aziendale SAP mette a disposizione tutta una serie di strumenti che ci consentono di mappare le nostre attività e calcolarne date, tempi, quantità. Questo riguarda tutti i processi ma in particolare modo quello logistico e produttivo: partendo dalla pianificazione generale potremo organizzare le operazioni aziendali fino alle micro attività, potremo alleggerire il nostro personale di operazioni ripetitive e soprattutto reagire alle inefficienze in modo integrata fra i vari reparti, evitando sovraccarichi, problemi di disponibilità, ritardi in operazioni seguenti.

Che sia un servizio o un bene materiale, di solito tutto parte dalla domanda del cliente, si stabilisce qualità, prezzo e tempi per poi organizzare le operazioni necessarie. Dovremo mappare queste operazioni nel sistema SAP cosi che poi questo ci aiuti a calcolare e stabilire la linea di pianificazione secondo le impostazioni e parametri che avremo configurato: impostazioni sui materiali, sui tipi di documenti, sulle modalità e tipi di gestione si tradurranno in continue operazioni di persone e macchine nella linea di pianificazione. Una volta configurati i parametri principali andremo ad affinarlo sempre piu scendendo nelle impostazioni di dettaglio nelle varie aree.

La data di consegna al cliente è il primo cardine di una linea di pianificazione, per prima cosa dovremo capire se schedulare in avanti o all’indietro per fissare i nostri tempi. Questo dipende in gran parte da come vogliamo lavorare e come fissiamo la data nel contratto di vendita col cliente, se promettiamo la merce ad una data questo ci obbligherà a schedulare a ritroso per tutte le altre operazioni, se offriamo la nostra migliore data potremo calcolare in avanti in base alle nostre capacità: questo implica capire come organizzare e gestire il nostro processo aziendale.

In uno scenario MTS (make to stock) dovremo fare particolare attenzione allo scenario produttivo ed alle capacità, il calcolo sulla nostra distribuzione sarà molto importante ed ancora di più saranno le nostre previsioni di vendita e quindi il punto ottimale di accumulo di stock nel tempo per evitare rotture. Se siamo in uno scenario MTO (make to order) conterà molto la stabilità dei nostri processi perché il calcolo sarà su una unica linea di pianificazione dove tutte le operazioni sono concatenate e dovremo calcolale al meglio per rispettare le date: dall’approvvigionamento delle materie prime alla produzione fino alla distribuzione della merce.

In SAP possiamo concertare e poi propagare la nostra linea di pianificazione su tutti i moduli sino ad arrivare al dettaglio nelle varie di processo ( acquisto, qualità, produzione, logistica): ricordate di stabilire dei punti di buffering nel flusso per fare fronte agli imprevisti e alle rotture, purtroppo la realtà non è mai perfetta…. La velocità del business deciderà poi la cadenza dei job di di pianificazione a sistema, cioè ogni quanto ripianificare le operazioni per il periodo seguente, potrebbe essere giornaliero, settimanale o addirittura mensile.

Questa è la teoria del macro processo aziendale, dovremo implementare con gli strumenti che SAP ci mette a disposizione queste logiche ponendo enfasi sul coinvolgimento dell’azienda in ogni suo livello, SAP è lo strumento ma sono le persone che fanno la vera produttività .

In SAP, ad alto livello, per la pianificazione generale della supply chain troviamo lo strumento principe, APO – Advanced Planner and Optimizer che con la tecnologia di database in memory HANA consente l’integrazione di un’infinità di dati in real-time da tutti i processi applicativi interessati.

APO è una soluzione che si basa su un insieme di integrazioni specifiche con gli altri moduli SAP eliminando la necessità di utilizzare diverse soluzioni per ogni area: diciamo che APO è il nodo centrale della pianificazione che estende poi le sue influenze sin nelle operazioni più basse dell’ERP.

La pianificazione con APO consente alle aziende di tenere conto di innumerevoli fattori come la disponibilità delle risorse, i tempi logistici (di consegna dei fornitori, di trasferimento in ogni processo), la domanda dei clienti e moltissimi altri fattori utilizzando algoritmi di ottimizzazione avanzati: in questo modo APO può generare un piano ottimale e influenzare le varie aree per massimizzare la disponibilità delle risorse e ridurre i costi.

APO comunque non è sempre necessario, se le dimensioni del business sono ridotte gli strumenti di pianificazione standard come MRP e ATP sono più che sufficienti, magari unite anche alla gestione delle capacità e delle risorse che ormai in S/4 sono implementate ovunque, oltre che nella produzione anche in gestione del magazzino, qualità e trasporti.

In qualsiasi sistema gestionale esistono due funzioni per la supply chain che sono essenziali per produzione e logistica:

Master Resource Planning : la pianificazione dell’approvvigionamento generale delle risorse necessarie alla vendita, sia di produzione interna che esterna, abbreviata MRP.

Available To Promise: la pianificazione della disponibilità delle merci in uscita rispetto le quantità gia impegnate da altri fabbisogni, in generale in vendita e per consumo.

L’MRP è una funzione di calcolo in INPUT e riguarda la parte iniziale dei processi logistici e produttivi: si occupa degli acquisti delle materie prime, della produzione dei semilavorati e delle lavorazioni esterne necessarie a produrre la merce che poi andrà in stock pronta per la vendita.

L’ATP è una funzione di calcolo in OUTPUT, cioè riguarda la parte finale dei processi e precisamente il calcolo delle quantità ancora a disposizione per l’uscita quindi alla vendita per i clienti finali o per i consumatori interni.

SAP per quanto riguarda l’MRP reperisce dall’anagrafica articolo le impostazioni sul tipo di approvvigionamento, per primo guarda se questo è interno o esterno: se è esterno guarda il periodo di approvvigionamento, la quantità dello stock di riordino, le impostazioni del lotto e del suo arrotondamento, guarda se esiste un fornitore abituale o lo determina tramite la lista sorgente.

Se SAP riesce a determinare il fornitore, legge le impostazioni del record info acquisti che lega in modo piu specifico il materiale al fornitore ed al prezzo concordato: a questo punto può calcolare con il tipo di funzione selezionata (deterministica, basate sui volumi, euristica, ne esistono molte) le quantità generando le richieste di acquisto. Queste possono essere rilasciate anche in modo automatico creando veri e propri ordini di acquisto che possono essere trasmessi telematicamente al fornitore: se SAP non è riuscito a determinare il fornitore lascerà all’utente la richiesta di acquisto pronta da elaborare inserendo i dettagli di fornitore, prezzi, destinazioni e modalità secondo accordi.

Nel caso di approvvigionamento interno SAP puo generare la richiesta di trasferimento del materiale dal plant produttivo: in quest’ultimo caso SAP deve effettuare la pianificazione della produzione dove va a esplodere le liste dei componenti necessari, se non disponibili dovrà rieseguire l’MRP sulle componenti, e controllare le versioni di produzione del materiale per calcolare la linea di schedulazione delle date degli ordini di produzione in base alle capacità disponibili sulle risorse.

L’ATP invece controlla lo stock disponibile, cioè le quantità già impegnate per la vendita o per altri scopi e le quantità di cui potete ancora disporre, non ancora promesse a nessuno come sta a significare l’abbreviazione anglosassone. Pensate al vostro stock in magazzino, se avete già degli ordini cliente che state processando o spedendo quanto stock ancora disponibile alla vendita vi rimane ? Questa è la quantità disponibile che ad esempio possiamo promettere su ordine di vendita al cliente, al netto delle quantità gia impegnate: capite che in questo caso il sistema gestionale deve memorizzare ogni singolo impegno di vendita del materiale e calcolare ad ogni nuovo impegno se questo può essere soddisfatto o meno.

Fin qui nulla di complicato se non fosse per il fatto che la disponibilità deve essere calcolata anche per materiali che non vanno solo in vendita ma su cui si basano altri prodotti magari in modo personalizzato o combinato: pensate al singolo articolo che potete vendere sfuso direttamente o su cui andate a creare dei kit assieme ad altri articoli. Questi articoli diverranno dei componenti dell’articolo assemblato e su questi componenti avrete sia impegni da ordini di vendita che impegni da ordini di produzione di assemblati.

In questi casi MRP e ATP si incrociano e lavorano a stretto contatto in INPUT e OUTPUT sullo stock magazzino: MRP determina quante sono le quantità del componente necessarie alla produzione dell’assemblato e quindi le quantità da approvvigionare ma è ATP che decide in base alle vostre regole a chi assegnare lo stock del componente.

ATP infatti deve memorizzare ogni impegno su ordine di vendita sia di assemblato che di prodotto sfuso, nel caso della produzione dell’assemblato prenderà come riferimento gli impegni delle esplosioni BOM sui componenti generate dall’MRP. ATP sommerà le quantità controllando che la quantità totale degli ordini di vendita, sia di componenti per assemblati che di componenti singoli, non arrivi alla quantità totale in stock del componente: nel caso la quantità totale a stock disponibile venga superata non permetterà piu di allocare ordini di vendita. Naturalmente nel frattempo MRP controllerà le quantità in stock e nel caso sia impostata con calcolo basato sul volume di consumo ( ad es. V1 o V2 ) terrà conto dei volumi in vendita ed in produzione e aumenterà il lotto di riordino in approvvigionamento di conseguenza.

In questo articolo ho spiegato in modo abbastanza sintetico le due colonne portanti di ogni gestionale ma ricordate che la bontà del comportamento del sistema dipenderà poi dai dati e dalle configurazioni che sceglierete di adottare: queste devono essere “cucite” sul processo di business per come deve funzionare nella realtà, scomponete i processi e pensando alle best practices capite quale è il migliore scenario da utilizzare, concordatelo con il cliente, poi da li sceglierete la miglior configurazione validata dai test effettivi, poi dati accurati per farlo funzionare al meglio.

SAP mette a disposizione una infinità di scenari e relative configurazioni per tenere conto di ogni particolarità, nei prossimi articoli ne parleremo in modo piu specifico assieme ad alcune particolarità di MRP e ATP, buon SAP a tutti!