Sei sulla pagina 1di 72
Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

1

 

Autore:

 

Data

Release 1,0

06/10/15

DOCUMENTO DI IMPLEMENTAZIONE Area Vendite e Distribuzione Pastificio PARTE I

Autore:

Ruolo

Data

 

Senior Consultant

$$ GIUGNO 2007

Modifiche:

Ruolo

Data

Approvazione:

Ruolo

Data

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

2

 

Autore:

 

Data

Release 1,0

06/10/15

INDICE:

1.

4

2.

LA STRUTTURA

5

2.1. STRUTTURE ORGANIZZATIVE DELLE

5

2.2. AREA VENDITE

6

2.3. STRUTTURE ORGANIZZATIVE

6

3.

ANAGRAFICHE

8

3.1.

ANAGRAFICA

8

3.1.1. Gruppi conto

9

 

3.1.2. Dati

9

 

3.1.3. Dati Societari

10

3.1.4. Dati Vendita

10

3.1.4.1 Caratteristiche di classificazione

10

3.1.4.2 Schema

11

3.2.

ANAGRAFICA

12

3.2.1.

Codice

12

3.2.1.1 Codifica

12

3.2.1.2 Codifica del

14

3.2.2. Tipo materiale

15

3.2.3. Dati relative alle vendite

15

3.2.4. Help di ricerca Pastificio

16

3.2.4.1 Prodotti del

18

3.2.4.2 Pasta

19

3.2.5.

Processi di evoluzione dell’articolo

20

3.2.5.1 Estensione anagrafica articolo su nuove organizzazioni vendita

20

3.2.5.2 Modifica componente

21

3.2.5.3 Fine vita

22

3.3.

ANAGRAFICA

22

4.

CONTROLLO DEL

24

4.1. ANAGRAFICA

24

4.2. CONTROLLO FIDO PER TIPOLOGIA CLIENTI

26

 

4.2.1. Grandi

27

 

4.2.2. Clienti normali

27

4.2.2.1 Marchio con produzione a

28

4.2.2.2 Marchio con produzione a

28

4.2.3.

Canale tradizionale

28

5.

GESTIONE PRICING

34

 

5.1. TABELLE

34

 

5.2. TIPI

35

5.2.1.

ZPR0 - Prezzo di

35

5.2.1.1 Prodotti del

35

5.2.2.

35

5.2.2.1 ZSCx – Sconto

36

5.2.2.2 ZSPx – Sconto Promozionale

36

5.2.2.3 ZFIN – Sconto

36

5.2.2.4 ZL0x – Sconto logistico

36

5.2.2.5 ZT0x – Sconto di

37

5.2.2.6 YT0x – Maggiorazione di testata

37

5.2.2.7 ZOMA – Sconto omaggio

37

5.2.3. Z100 – Sconto

37

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

3

 

Autore:

 

Data

Release 1,0

06/10/15

5.2.3.1 Sconto merce automatico: regole di determinazione

37

5.2.3.2 Sconto merce

38

5.2.3.3 Spedizione ordini con sconto merce: gestione stralci

38

 

5.2.4. ZPVx – Aliquota

40

5.2.5. ZPV0 – Percentuale abbattimento

42

5.2.6. MWST – IVA

42

5.2.7. ZMW0 – IVA

45

5.2.8. LCIT – Licenza IVA Italia

46

5.3.

SCHEMA PREZZO

48

6.

PROCESSI DI

49

6.1.

CONTRATTO A

49

6.1.1. ZKP – Contratto a quantità Ordine Globale

49

6.1.2. ZKM – Contratto a quantità Prodotti del Molino

54

6.2.

ORDINI DI VENDITA

54

6.2.1. ZOSI – Ordine standard Italia (Ordine

55

6.2.2. ZOSR – Vendita Imballi

55

6.2.3. ZOPI – Ordine Picking Italia: Vendita Pasta

55

6.2.4. ZOSM – Ordine standard: Vendita Prodotti del

56

6.2.4.1 Vendita Pasta Zootecnica

56

6.2.5.

ZOSE – Ordine standard Estero (Ordine

56

6.3.

CAMPIONATURA

57

6.3.1.

Configurazione del sistema

58

6.3.1.1 Schema dati incompleti

58

6.3.1.2 Tipo

59

6.3.1.3 Modifiche schema

60

6.3.1.4 Tabella di contabilizzazione

60

6.3.2. Tipologia campionatura

62

6.3.2.1 Campionatura Cartoni

62

6.3.2.2 Campionatura

62

6.3.3. Processo di campionatura gratuita – Tipi ordine

63

6.3.3.1 ZCG – Campionatura gratuita senza rivalsa dell’IVA (Italia)

63

6.3.3.2 ZCG1 – Campionatura gratuita senza rivalsa IVA – Picking

65

6.3.3.3 ZCG2 – Campionatura gratuita con rivalsa dell’IVA (Italia)

65

6.3.3.4 ZCG3 – Campionatura gratuita con rivalsa dell’IVA (Italia) – Picking

65

6.3.3.5 ZCG2 – Campionatura gratuita IVA esente (Italia, UE,

66

6.3.3.6 ZCG3 – Campionatura gratuita IVA esente (Italia, UE, ExtraUE) –

66

6.3.4.

Stampa fattura campionatura gratuita

66

6.4.

RISERVA CLIENTE (RESI, NOTE CREDITO, NOTE DEBITO)

66

6.4.1. ZRE – Richiesta di reso

67

6.4.2. ZREM – Reso Prodotti del Molino

68

6.4.3. ZG2 – Richiesta Nota Credito

68

6.4.4. ZL2 – Richiesta Nota

68

6.5. GESTIONE PALLET

68

 

6.6. STAMPA

69

6.6.1.

Generalità messaggi di stampa

69

6.6.2.

Tipo messaggio BA00 – Conferma di

70

6.6.3.

71

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

4

 

Autore:

 

Data

Release 1,0

06/10/15

1. INTRODUZIONE.

Scopo di questo documento è quello di illustrare le funzionalità da implementare rispetto le esigenze di carattere commerciale e distributivo rilevate in fase di analisi, così come sono strutturate nel modulo SD (Sales and Distribution) e le modalità attraverso le quali dovranno essere gestite presso la Pastificio SpA.

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

5

 

Autore:

 

Data

Release 1,0

06/10/15

2. LA STRUTTURA ORGANIZZATIVA.

2.1. Strutture organizzative delle vendite.

Le strutture organizzative in SAP rilevanti per le vendite sono basate sulla Area Vendita (Sales Area). Ciascuna Sales Area è composta dai seguenti elementi posti in relazione gerarchica fra di loro:

Organizzazione Vendite: unità organizzativa che supervisiona le politiche di vendita di beni o servizi specifici, oppure dedicata a determinate aree geografiche, o categorie di clienti.

La Organizzazione Vendite può essere legata esclusivamente ad una società, e ad una o più divisioni della stessa società.

Canale distributivo: è la modalità con cui la Organizzazione Vendite opera su mercati diversi

Settore Merceologico: tipologia di articolo, consente di qualificare qualitativamente la tipologia di beni, classificandoli in famiglie di prodotti commerciali.

Queste tre strutture organizzative sono chiave in tutti gli oggetti generati nel modulo SD, e saranno anche disponibili come parametri di selezione in tutte la analisi standard.

Saranno definite le seguenti:

Organizzazione Commerciale

Descrizione

Z001

Vendite Italia

Z002

Vendite Estero

Z003

Vendite del Molino

Canale di distribuzione

Descrizione

Z1

Vendite Dirette

Z2

Rete Agenti

Settore Merceologico

Descrizione

P1

PS Semola

P2

PS Semole Speciali

P3

PS Farina

P4

PS Zootecnica

C1

Linea Rossa

C2

Linea Farine

MO

Prodotti del Molino

Copyright 2006, SAP Italia Consulting S.p.A.

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

6

 

Autore:

 

Data

Release 1,0

06/10/15

90

Prodotti Generici

98

Servizi

99

Settore Comune

Il settore comune raggruppa le diverse categorie merceologiche.

2.2. Area Vendite.

Sulla base degli oggetti definiti nel paragrafo precedente, saranno definite per Pastificio le seguenti aree vendita:

Italia Diretto (Divella, LIDL, etc.)saranno definite per Pastificio le seguenti aree vendita: Italia – Rete Agenti Molino Diretto Molino –

Italia – Rete Agentiseguenti aree vendita: Italia Diretto (Divella, LIDL, etc.) Molino Diretto Molino – Rete Agenti Estero Diretto

Molino DirettoItalia Diretto (Divella, LIDL, etc.) Italia – Rete Agenti Molino – Rete Agenti Estero Diretto (Agritalia,

Molino – Rete Agenti(Divella, LIDL, etc.) Italia – Rete Agenti Molino Diretto Estero Diretto (Agritalia, Daybreak, WFF, Unilever, etc.)

Estero Diretto (Agritalia, Daybreak, WFF, Unilever, etc.)Italia – Rete Agenti Molino Diretto Molino – Rete Agenti Estero – Rete Agenti Società De

Estero – Rete AgentiEstero Diretto (Agritalia, Daybreak, WFF, Unilever, etc.) Società De De Matteis Matteis Agroalimentare

Società De De Matteis Matteis Agroalimentare Agroalimentare S.p.A. S.p.A. Organizzazione Commerciale Vendite Vendite
Società
De De Matteis Matteis
Agroalimentare Agroalimentare S.p.A. S.p.A.
Organizzazione
Commerciale
Vendite Vendite Italia Italia
Vendite Vendite Molino Molino
Vendite Vendite Estero Estero
Canale
Rete Rete
Rete Rete
Rete Rete
distribuzione
Diretto Diretto
Diretto Diretto
Diretto Diretto
Agenti Agenti
Agenti Agenti
Agenti Agenti
Prodotti
Prodotti
Settore
Settore
Settore
Prodotti del
Prodotti del
Settore
Settore
comune Settore
comune Settore
comune Settore
comune Settore
Merceologico
comune
Molino del
comune
Molino del
comune
comune
Molino
Molino

2.3. Strutture organizzative logistiche.

Le strutture organizzative logistiche rilevanti per la area commerciale sono:

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

7

 

Autore:

 

Data

Release 1,0

06/10/15

Divisione – lo stabilimento fisico  Autore:   Data Release 1,0 06/10/15 Luogo di spedizione – luogo da cui fisicamente viene

Luogo di spedizione – luogo da cui fisicamente viene caricato il mezzo di spedizione1,0 06/10/15 Divisione – lo stabilimento fisico Magazzino di spedizione – magazzino da cui viene

Magazzino di spedizione – magazzino da cui viene registrata la uscita merceda cui fisicamente viene caricato il mezzo di spedizione Saranno definite le seguenti: Divisione Descrizione

Saranno definite le seguenti:

Divisione

Descrizione

D001

Molino

D002

Pastificio

Luogo di spedizione

Descrizione

Z001

Molino

Z002

Pastificio

Divisione /

Descrizione

Magazzino spedizione

D001 / M109

Magazzino Spedizione Molino

D002 / M209

Magazzino Spedizione Pastificio

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

8

 

Autore:

 

Data

Release 1,0

06/10/15

3. ANAGRAFICHE.

3.1. Anagrafica Cliente.

L’anagrafica cliente è composta essenzialmente da quattro macro sezioni:

Dati generali - informazioni indipendenti da ogni struttura organizzativa (Ragione sociale, indirizzo, …);

Dati di società - informazioni ad uso strettamente contabile, dipendenti dalla singola società (metodo di pagamento, conto riconciliazione, …);

Dati di controllo credito - informazioni che servono per pilotare le regole con cui il sistema effettua il controllo credito, dipendenti dall’area di controllo credito;

Dati di vendita - informazioni di utilizzo strettamente commerciale, dipendono dall’area vendite (incoterms, funzioni partner, …);

Vendita (dati utili per la compilazione dell’ordine),

Spedizione (dati utili per la generazione della consegna),

Fatturazione (dati utili per la compilazione della fattura),

Funzioni Partner

E’ possibile gestire sulla anagrafica del cliente una informazione relativa allo stato del cliente, per identificare clienti obsoleti, o bloccati in attesa di controlli, e definire quali operazioni (inserimento ordine, spedizione, etc.) siano consentite o bloccate per questi.

Nel seguito di questo paragrafo si indicheranno, per ciascuna delle sezioni elencate, solo le informazioni emerse in fase di analisi. E’ fondamentale riconoscere come la anagrafica clienti di SAP abbia un numero enormemente superiore di informazioni disponibili che potranno comunque essere gestite in futuro, e come sia inoltre una anagrafica aperta ed ampliabile anche in futuro in caso di necessità.

E’ importante riconoscere anche come, il fatto che i dati siano suddivisi in macro aree, renda possibile una organizzazione aziendale in cui un ente (p.e. Amministrazione) può aprire un nuovo codice cliente, e manutenere una serie di dati, mentre un ente diverso può aggiornare anche successivamente solo i dati di propria competenza (p.e. Commerciale per i dati di classificazione analitica).

La analisi svolta ha evidenziato come tutti i dati presenti oggi nella scheda anagrafica cliente di Pastificio abbiano un analogo campo in SAP: in particolare, per alcune informazioni che possono avere carattere ricorsivo (p.e. numeri di telefono, fax, indirizzi mail, etc.), è disponibile in SAP la possibilità di inserire n valori per ciascuna di queste informazioni.

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

9

 

Autore:

 

Data

Release 1,0

06/10/15

3.1.1.Gruppi conto.

Il gruppo conti è una caratteristica di classificazione all'interno dei record anagrafico clienti, che serve per determinare:

a quale range di numerazione devono appartenere i numeri conto del clientedei record anagrafico clienti, che serve per determinare: se il numero del conto viene assegnato dall'utente

se il numero del conto viene assegnato dall'utente o dal sistemadi numerazione devono appartenere i numeri conto del cliente quali indicazioni sono richieste o ammesse nel

quali indicazioni sono richieste o ammesse nel record anagraficodel conto viene assegnato dall'utente o dal sistema Gruppo conti Descrizione CNAZ Clienti Nazionali

Gruppo conti

Descrizione

CNAZ

Clienti Nazionali

CDES

Destinatari Merce

CLUE

Clienti Unione Europea

CXUE

Clienti Extra - UE

COCC

Clienti Occasionali

CLEG

Clienti Sedi Legali

CLNG

Nodo Gerarchia

Per i relativi range di numerazione, e le altre proprietà dei gruppi conto, vedi documento di modellazione della area Financial.

3.1.2.Dati Generali.

Tipologia di dato

Descrizione

Codice Cliente

Progressivo numerico a 6 cifre

Ragione sociale

Ragione sociale del cliente

Indirizzo completo

Via, numero, CAP, città, provincia, nazione, etc.

Riferimenti per la comunicazione

Lingua di comunicazione, numeri di telefono, fax, indirizzo mail, etc.

Dati di controllo

Codice Fiscale e Partita IVA

Dati Bancari

Riferimenti bancari del cliente

Punti di scarico

Luogo fisico dove scaricare la merce, se diverso dall’indirizzo gestito in anagrafica

Interlocutori

Riferimenti e ruoli di persone presso il cliente (Responsabile commerciale, Amministrativo, etc. e relativi numeri di telefono/fax/e-mail)

Note

Campi descrittivi a lunghezza indefinita. E’ possibile definire questi campi sulla anagrafica del cliente, e riportarli automaticamente sui documenti successivi (ordine, consegna, fattura), per renderli disponibili per la stampa.

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

10

 

Autore:

 

Data

Release 1,0

06/10/15

3.1.3.Dati Societari.

Tipologia di dato

Descrizione

Conto di riconciliazione

Conto Co.Ge. di riconciliazione (p.e. Clienti Italia, clienti CEE, Clienti Extra CEE)

Codice Fornitore

Se il cliente è codificato anche come fornitore in questo campo va inserito il suo codice fornitore per facilitare in contabilità generale il pareggiamento delle partite attive e passive

Metodo di Pagamento

Metodo di pagamento

Condizioni di Pagamento

Condizioni di pagamento

3.1.4.Dati Vendita.

3.1.4.1 Caratteristiche di classificazione commerciale.

Tipologia di dato

Descrizione

Gruppo Clienti

GDO, Tradizionale, Industria, Trader, Catering, Allevatori

Gruppo clienti 1

Specifiche del canale tradizionale: Dettaglio, Ristorazione, Convenzionato, Ingrosso, Concessionario, etc.

Gruppo clienti 2

Tipologia Punti Vendita (GDO): Cash&Carry, Ipermercato, Supermercato, Superette, Specializzato, Discount, etc.

Gruppo clienti 3

Insegna: PAM, Panorama, IN’S, etc.

Gruppo clienti 4-5

Disponibili per sviluppi futuri

Listino

GDO, Concessionario, Ingrosso, Dettaglio

E’ importante riconoscere come:

Le caratteristiche di classificazione possono essere ampliate nel tempoIngrosso, Dettaglio E’ importante riconoscere come: Gli elenchi di valori possibili per ciascuna di queste può

Gli elenchi di valori possibili per ciascuna di queste può essere modificato nel tempo come funzione utentedi classificazione possono essere ampliate nel tempo La valorizzazione di queste caratteristiche nella anagrafica

La valorizzazione di queste caratteristiche nella anagrafica non è obbligatoria: è possibile definire un primo scenario in cui la azienda decide di ricostruire la corretta valorizzazione di questi campi nella anagrafiche insieme alla partenza di SAP, ed un secondo scenario in cui le caratteristiche sono definite come valori possibili, ma non tutte le anagrafiche clienti saranno aggiornate fin da subito. E’ chiaro che in questo secondo scenario le statistiche saranno necessariamente incomplete fino a quando le caratteristiche non saranno correttamente inserite in anagrafica.ciascuna di queste può essere modificato nel tempo come funzione utente  Copyright 2006, SAP Italia

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

11

 

Autore:

 

Data

Release 1,0

06/10/15

3.1.4.2 Schema partner.

Si definisce Committente l’intestatario del rapporto commerciale verso PASTIFICIO.

Nella anagrafica cliente saranno definiti per ciascun cliente committente i seguenti Business Partner:

Business Partner

Ruolo Partner

Gruppo Conti

Descrizione

COMMITTENTE

AG

CNAZ, CLUE, CXUE

Intestatario del rapporto commerciale

DESTINATARIO

RE

CNAZ, CLUE, CXUE

Indirizzo di spedizione della fattura. Per questo ruolo oggi non viene utilizzato in Pastificio un BP diverso da quello principale.

FATTURA

ESECUTORE

RG

CNAZ, CLUE, CXUE

BP verso il quale si apre la partita di contabilità generale. Per questo ruolo oggi non viene utilizzato in Pastificio un BP diverso da quello principale.

PAGAMENTO

DESTINATARIO

WE

CDES

Intestatario della bolla di spedizione

MERCE

LUOGO

ZW

CDES

E’ uno degli n possibili magazzini del cliente di destinazione, viene legato alla anagrafica del destinatario merce. Non esiste oggi per questo ente una anagrafica sui sistemi PASTIFICIO: i suoi dati di indirizzo sono memorizzati solo in modo descrittivo

DESTINAZIONE

MERCE

I seguenti Business Partner, di tipo fornitore, potranno invece essere ripresi solo sui documenti transazionali:

Business Partner

 

Gruppo Conti

Descrizione

AGENTE

ZA

FAGE

Codice Agente che segue il cliente per conto PASTIFICIO:

il BP sarà ripreso sull’ordine di Vendita con l’aiuto di una opportuna exit, la data di assegnazione dell’Agente al cliente sarà gestita nel database delle provvigioni

TRASPORTATORE

SP

FTRA

Spedizioniere che segue solitamente il cliente committente: il BP potrà essere definito in anagrafica cliente, e poi essere ripreso in automatico in ordine e consegna, oppure potrà essere inserito manualmente in consegna

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

12

 

Autore:

 

Data

Release 1,0

06/10/15

3.2. Anagrafica Articolo.

In SAP l’anagrafico materiale è unico, distinto in viste di dati generali e dati di divisione (Plant), che, a loro volta, sono ulteriormente suddivise in viste relative ai dati di produzione, acquisti, vendite, contabilità e controllo gestione.

Con il termine dati di vendita si intende l’insieme delle informazioni relative ad un singolo codice materiale, ma differenziabili per ogni possibile combinazione di Organizzazione Commerciale e Canale di Distribuzione.

Tali informazioni sono raccolte in una serie di videate cui è possibile accedere previa indicazione delle seguenti chiavi:

Codice Materialepossibile accedere previa indicazione delle seguenti chiavi: Organizzazione Commerciale Canale di Distribuzione Le viste

Organizzazione Commercialeprevia indicazione delle seguenti chiavi: Codice Materiale Canale di Distribuzione Le viste di interesse per le

Canale di Distribuzioneseguenti chiavi: Codice Materiale Organizzazione Commerciale Le viste di interesse per le vendite sono le seguenti:

Le viste di interesse per le vendite sono le seguenti:

Vendita 1Le viste di interesse per le vendite sono le seguenti: Vendita 2 Dati vendita/divisione Commercio estero/export

Vendita 2di interesse per le vendite sono le seguenti: Vendita 1 Dati vendita/divisione Commercio estero/export Testi vendita

Dati vendita/divisioneper le vendite sono le seguenti: Vendita 1 Vendita 2 Commercio estero/export Testi vendita Come per

Commercio estero/exportsono le seguenti: Vendita 1 Vendita 2 Dati vendita/divisione Testi vendita Come per la anagrafica dei

Testi vendita1 Vendita 2 Dati vendita/divisione Commercio estero/export Come per la anagrafica dei clienti è anche qui

Come per la anagrafica dei clienti è anche qui importante riconoscere come, il fatto che i dati siano suddivisi in viste, renda agevole una organizzazione aziendale in cui un ente (p.e. Area Progettazione) crei un nuovo codice articolo, e ne manutenga una serie di dati, mentre enti diversi aggiornano esclusivamente i dati di propria competenza (p.e. Commerciale per i dati di classificazione analitica, etc.).

3.2.1.Codice articolo.

SAP consente di definire il range di numerazione per gli articoli come alfanumerico fino ad un massimo di 18 caratteri, e di differenziare i range in funzione del tipo materiale (per i dettagli vedi il documento di modellazione della area Materials Management).

3.2.1.1 Codifica multipla.

Oggi per ciascun articolo commerciale PASTIFICIO sono definiti fino ad un massimo di tre codici diversi per lo stesso articolo:

Codifica Breve (o codifica commerciale)fino ad un massimo di tre codici diversi per lo stesso articolo:  Copyright 2006, SAP

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

13

 

Autore:

 

Data

Release 1,0

06/10/15

La codifica breve nasce dalla esigenza di gestire un codice sufficientemente breve da poter essere mnemonico, e quindi comunicabile verso l’esterno della azienda.

Codifica Lunga (o codifica parlante)e quindi comunicabile verso l’esterno della azienda. La codifica lunga dalla esigenza di gestire in un

La codifica lunga dalla esigenza di gestire in un codice parlante una serie di caratteristiche del codice materiale, non gestibili in campi aggiuntivi (esigenza superata con l’avvento di SAP).

Marchio Marchio Packaging Packaging Pezzatura Pezzatura Attributo Attributo PS PS BAR BAR N N F
Marchio
Marchio
Packaging
Packaging
Pezzatura
Pezzatura
Attributo
Attributo
PS
PS
BAR
BAR
N N
F F
0005 0005
0500 0500
24 24
A A
Tipologia
Tipologia
Tipologia
Tipologia
Codifica
Codifica
Articoli per
Articoli per
articolo
articolo
materia prima
materia prima
cartone
cartone
Il legame fra codice breve e codice lungo è sempre 1:1.

Codifica di fatturazione (sull’attuale sistema legacy di fatturazione “Quickly”)Il legame fra codice breve e codice lungo è sempre 1:1. Può accadere che al cambio

Può accadere che al cambio di uno o più componenti del prodotto finito (p.e. il film per l’imballaggio) cambi il codice lungo (e quindi il codice breve), ma non si voglia modificare il codice di Quickly.

Esempio.

Gli spaghetti sono codificati con codice breve BA5 (coincidente al tempo 0 con il codice Quickly per la fatturazione), e codice lungo PSBARNF0005050024A.

Al cambio di un componente, viene definito un nuovo codice breve (p.e. BA5n – new) ed un nuovo codice lungo, ma non modificare il corrispondente codice di fatturazione, che resta quindi BA5.

In SAP, per non stravolgere la gestione attuale, per tutti i prodotti che hanno codifica multipla, si procederà al modo seguente:

Il codice Quickly sparisce, e saranno gestiti solamente le associazioni fra codice breve e codice lungoche hanno codifica multipla, si procederà al modo seguente: Il codice breve sarà codificato come un

Il codice breve sarà codificato come un alias commerciale del codice lungo, sarà utilizzato per l’order entry, ed a scopo statistico, ma non avrà alcuna gestione logistica: tutte le operazioni logistiche in SAP (generazione fabbisogni, anagrafiche di produzione, produzione, movimentazione magazzino, spedizione, etc.) avverranno solamente sul codice lungo.solamente le associazioni fra codice breve e codice lungo Nella figura seguente il processo di generazione

Nella figura seguente il processo di generazione di un nuovo codice in SAP:

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

14

 

Autore:

 

Data

Release 1,0

06/10/15

Generazione Codice breve Generazione Codice breve • • informa l’Ufficio progettazione informa l’Ufficio
Generazione Codice breve Generazione Codice breve • • informa l’Ufficio progettazione informa l’Ufficio
Generazione Codice breve Generazione Codice breve • • informa l’Ufficio progettazione informa l’Ufficio

Generazione Codice breve

Generazione Codice breve

• •

informa l’Ufficio progettazione

informa l’Ufficio progettazione

• •

Genera il codice breve in SAP, ed

Genera il codice breve in SAP, ed

Manutiene esclusivamente le

Manutiene esclusivamente le

informazioni di propria competenza

informazioni di propria competenza

• •

Vendibile”

Vendibile”

Il codice ha lo stato vendite: “NON

Il codice ha lo stato vendite: “NON

• •

quindi ancora essere utilizzato per

quindi ancora essere utilizzato per

In questa fase il codice non può

In questa fase il codice non può

inserire nuovi ordini

inserire nuovi ordini

Generazione Codice lungo

Generazione Codice lungo

• •

Genera il codice lungo in SAP in

Genera il codice lungo in SAP in

copia dal codice breve

copia dal codice breve

• •

• •

Manutiene tutte le informazioni

Manutiene tutte le informazioni

Crea il legame in SAP fra codice

Crea il legame in SAP fra codice

breve e codice lungo

breve e codice lungo

• •

• •

Sblocca il codice breve

Sblocca il codice breve

Attiva la generazione del codice in

Attiva la generazione del codice in

BA2000

BA2000

• •

essere utilizzato per inserire nuovi

essere utilizzato per inserire nuovi

Da questo momento il codice può

Da questo momento il codice può

ordini e per generare fabbisogni di

ordini e per generare fabbisogni di

produzione

produzione

3.2.1.2 Codifica del cliente.

Spesso è necessario inserire sui documenti commerciali (conferma ordine, bolla, fattura) anche la codifica dell’articolo presso il cliente, per facilitare a questi la comprensione e la lettura dei nostri documenti.

Inoltre in fase di digitazione dell’ordine si parte sempre da una copia cartacea ricevuta dal cliente, o dall’agente. Su questa sono spesso indicati i codici articoli del cliente, e può essere necessario un lavoro preventivo (mnemonico o procedurale) per effettuare la riconversione da codice articolo del cliente a codice commerciale Pastificio prima di digitare l’ordine.

E’ possibile inserire in apposite anagrafiche il legame fra codice articolo Pastificio e codice cliente, per ciascun cliente.

Sarà possibile sfruttare questa informazione per facilitare la digitazione dell’ordine, e per le stampe che Pastificio emette verso l’esterno (conferma ordine, bolla, fattura, etc.).

Se la codifica del cliente (cross reference) viene definita sul codice breve, il sistema non è in grado di acquisire sull’ordine di vendita la cross reference stessa, in quanto effettua prima la sostituzione del codice breve con il codice lungo e poi il controllo sulla esistenza dell’inforecord.

Viene quindi implementata una exit nella include MV45AFZZ che consente di recuperare il

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

15

 

Autore:

 

Data

Release 1,0

06/10/15

valore della cross reference anche dal codice breve (VBAP-MATWA):

FORM userexit_move_field_to_vbap.

[…]

* --> in fase di creazione dell'item recupera cross reference

* dal codice breve articolo (VBAP-MATWA) DATA lv_kPastificiot LIKE vbap-kPastificiot.

SELECT SINGLE kPastificiot INTO lv_kPastificiot FROM knmt WHERE vkorg = vbak-vkorg

AND

vtweg = vbak-vtweg

AND

kunnr = vbak-kunnr

AND

matnr = vbap-matwa.

IF sy-subrc = 0

svbap-tabix = 0 AND vbap-kPastificiot = ''. vbap-kPastificiot = lv_kPastificiot. ENDIF.

AND

[…]

ENDFORM.

"USEREXIT_MOVE_FIELD_TO_VBAP

3.2.2.Tipo materiale.

Saranno definiti i seguenti tipi materiale, di cui uno apposito per la codifica degli articoli commerciali con codifica breve (gestione del transitorio):

Tipo Materiale

Descrizione

ZFER

Prodotto finito

ZHAW

Codifica Breve

Il tipo materiale ZHAW gestirà esclusivamente le videate dei dati di base e quelle delle vendite.

3.2.3.Dati relative alle vendite.

Gli articoli commerciali dovranno essere classificati a scopo analitico secondo le seguenti caratteristiche:

Tipologia di dato

Descrizione

Rilevante per il Pricing

Proposta soluzione SAP

Gruppo Marchio

Raggruppamento di Marchi per cliente

 

Gerarchia livello 1

Marchio

Pastificio, Marchio cliente

X

Gerarchia livello 2

Categoria Merceologica

PS Semola, PS Semole speciali, etc.

X

Settore Merceologico

Materia Prima

BIO, Convenzionale

X

Gruppo Materiale

Composizione

Standard, Vitamina, Uovo, etc.

X

Gruppo Bonus

Famiglia

Normali, Speciali, Normali al bronzo

X

Gruppo Materiale 1

Pezzatura

Retail 500gr, Retail 1lb, Retail 1Kg, Catering

X

Gruppo Materiale 2

Formati

Corta, Pastine, Lunga, Sfoglia, Nido, Lasagne, Artigianali

X

Gruppo Materiale 3

Pack

Cuscino, fondo Q., Fondo Q. + Cav., Doppio

X

Gruppo Materiale 4

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

16

 

Autore:

 

Data

Release 1,0

06/10/15

Fondo Q., Astuccio, Vaschetta, Sfuso, Sacchi

Fondo Q., Astuccio, Vaschetta, Sfuso, Sacchi

Fondo Q., Astuccio, Vaschetta, Sfuso, Sacchi
Fondo Q., Astuccio, Vaschetta, Sfuso, Sacchi

Sarà inoltre gestita una ulteriore caratteristica commerciale a scopo di classificazione:

Tipologia di dato

Descrizione

Rilevante per il Pricing

Proposta soluzione SAP

Formato Commerciale

Tipologia di formato

 

Ampliamento anagrafica

Nella figura seguente viene mostrato il posizionamento dei campi di classificazione commerciale sulla videata della anagrafica articolo:

Gerarchia classificazione SD (in ordine): Marchio MVKE-PRODH Categoria merceologica MARA-SPART Materia Prima
Gerarchia classificazione SD (in ordine):
Marchio
MVKE-PRODH
Categoria merceologica
MARA-SPART
Materia Prima
MVKE-KONDM
Composizione
MVKE-BONUS
Famiglia
MVKE-MVGR1
Pezzatura
MVKE-MVGR2
Formato
MVKE-MVGR3
Pack
MVKE-MVGR4
Formato commerciale
MARA-FORMATO
Questa logica sarà utilizzata in tutti i report SD, e per la definizione
dei listini (prezzi, sconti, etc.)

In fase di implementazione si valuterà se aggiungere ulteriori campi di classificazione commerciale.

Per un elenco aggiornato dei valori possibili di questi campi, vedi documentazione condivisa nel web di progetto.

3.2.4.Help di ricerca Pastificio.

Per facilitare la ricerca degli articoli viene creato un nuov help di ricerca ed agganciato come ID Matchcode all’help di ricerca standard MAT1.

Gli step sono i seguenti:

Creazione View Z_MAT1S da utilizzare come metodo di selezione con i campi PastificioMatchcode all’help di ricerca standard MAT1. Gli step sono i seguenti:  Copyright 2006, SAP Italia

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

17

 

Autore:

 

Data

Release 1,0

06/10/15

  Autore:   Data Release 1,0 06/10/15 Creazione Help di ricerca elementare Z_MAT1S in copia da

Creazione Help di ricerca elementare Z_MAT1S in copia da MAT1S con i campi Pastificio  Autore:   Data Release 1,0 06/10/15 Agganciare Z_MAT1S a MAT1 come nuovo ID Matchcde 

elementare Z_MAT1S in copia da MAT1S con i campi Pastificio Agganciare Z_MAT1S a MAT1 come nuovo
elementare Z_MAT1S in copia da MAT1S con i campi Pastificio Agganciare Z_MAT1S a MAT1 come nuovo

Agganciare Z_MAT1S a MAT1 come nuovo ID Matchcde

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

18

 

Autore:

 

Data

Release 1,0

06/10/15

  Autore:   Data Release 1,0 06/10/15 L’effetto finale è quello di trovare il nuovo ID

L’effetto finale è quello di trovare il nuovo ID Matchcode agganciato su tutte le transazioni standard (nella figura seguente un esempio su MM02):

standard (nella figura seguente un esempio su MM02): 3.2.4.1 Prodotti del Molino. I prodotti del Molino

3.2.4.1 Prodotti del Molino.

I prodotti del Molino sono identificati in base alle seguenti caratteristiche:

Tipologia di dato

Descrizione

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

19

 

Autore:

 

Data

Release 1,0

06/10/15

Gruppo Marchio

Non necessario

Marchio

Non necessario

Categoria Merceologica

Prodotti del Molino

Materia Prima

BIO, Convenzionale

Composizione

Standard

Famiglia

Sfarinati, Sottoprodotti

Formato

Non necessario

Pack

Sfuso, Sacchi

Pezzatura

Non necessario

Si distinguono i seguenti sottoprodotti:

Articolo

Descrizione

Farinaccio

Sfuso, Sacchi

Tritello

Sfuso, Sacchi, Cubettato

Granotto

Sfuso, Sacchi

Avena

Sfuso, Sacchi

Ed i seguenti sfarinati

Articolo

Descrizione

Semola Grano duro

Esistono n diverse tipologie di semole. Sfuso, Sacchi

Farina

Sfuso, Sacchi

Semola rimacinata

Sacchi

3.2.4.2 Pasta Zootecnica.

I prodotti con Categoria Merceologica PS Zootecnica saranno gestiti con lo stesso processo di vendita dei prodotti del Molino. Hanno le seguenti caratteristiche:

Tipologia di dato

Descrizione

Gruppo Marchio

PASTIFICIO

Marchio

Pastificio

Categoria Merceologica

PS Zootecnica

Materia Prima

BIO, Convenzionale

Composizione

Standard, Vitamine, Uovo, etc.

Famiglia

Pasta, Tozzi

Formato

Non necessario

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

20

 

Autore:

 

Data

Release 1,0

06/10/15

Pack

Non necessario

Pezzatura

Sacchi, Confezioni

3.2.5.Processi di evoluzione dell’articolo.

3.2.5.1 Estensione anagrafica articolo su nuove organizzazioni vendita.

Può accadere che lo stesso articolo sia venduto su canali diversi, o addirittura su organizzazioni diverse (p.e. lo stesso articolo Pastificio che viene venduto sia in Italia che all’estero, sia sul canale diretto che su quello agenti).

E’ disponibile la transazione standard MASS per ampliare le anagrafiche sulle diverse organizzazioni.

Nelle figure seguenti un esempio di esecuzione della MASS per le anagrafiche articolo.

di esecuzione della MASS per le anagrafiche articolo. Seleziono la tabella MVKE per procedere al solo

Seleziono la tabella MVKE per procedere al solo aggiornamento dei dati vendite:

MVKE per procedere al solo aggiornamento dei dati vendite: Definisco le condizioni di estrazione (record da

Definisco le condizioni di estrazione (record da creare) e le condizioni di copia (record modello):

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

21

 

Autore:

 

Data

Release 1,0

06/10/15

E’ importante inserire il record modello per consentire al sistema di definire i dati da
E’ importante inserire il record
modello per consentire al
sistema di definire i dati da cui
copiare verso i record obiettivo

Il sistema estrae l’unico record ancora non creato nella nuova struttura organizzativa:

ancora non creato nella nuova struttura organizzativa: Ed al salvataggio mi inserisce il record: 3.2.5.2 Modifica

Ed al salvataggio mi inserisce il record:

organizzativa: Ed al salvataggio mi inserisce il record: 3.2.5.2 Modifica componente articolo. Può accadere che un

3.2.5.2 Modifica componente articolo.

Può accadere che un prodotto finito subisca nel tempo modifiche alla propria distinta base.

Il transitorio durante il quale sono disponibili nel magazzino ancora entrambi i componenti, può essere gestito effettuando le seguenti operazioni:

definizione di una sostituzione sulla anagrafica del vecchio componente (videata MRP4), con l’indicazione del nuovo codice, e della data di decorrenzapuò essere gestito effettuando le seguenti operazioni: modifica alla distinta base del prodotto finito, che indichi

modifica alla distinta base del prodotto finito, che indichi come alternativi il vecchio componente ed il nuovo componente.MRP4), con l’indicazione del nuovo codice, e della data di decorrenza  Copyright 2006, SAP Italia

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

22

 

Autore:

 

Data

Release 1,0

06/10/15

Il sistema con questi presupposti, a partire dalla data di sostituzione, è in grado di pianificare il consumo fino ad esaurimento scorte del vecchio componente, e solo successivamente di pianificare i fabbisogni sul nuovo componente.

3.2.5.3 Fine vita articolo.

E’ necessario disporre di uno strumento che inibisca le principali operazioni transazionali sui prodotti commerciali.

Questo processo può essere gestito semplicemente settando gli stati sulla anagrafica dell’articolo, per classificarlo come obsoleto, e quindi inibire le principali operazioni logistiche definibili su questo (non ordinabile, non producibile, non vendibile, etc.).

3.3. Anagrafica testi.

Si può utilizzare la transazione standard SO10 per la gestione di testi standard, che saranno poi successivamente utilizzati nelle stampe dei documenti transazionali (ordine, consegna, distinta di trasporto, fattura), o nei report definiti successivamente.

Si definisce la seguente nomenclatura per i testi standard:

Primi 4 caratteri rappresentano la società

Successivi 2 caratteri la area funzionale, o processo coinvolto

Ultimi n caratteri l’oggetto del testo

I testi sono definiti in lingua (nel nostro scenario IT ed EN).

sono definiti in lingua (nel nostro scenario IT ed EN). Fanno eccezione alla regola sopra descritta

Fanno eccezione alla regola sopra descritta i testi per i codici IVA, la cui nomenclatura segue esattamente la nomenclatura dei codici IVA, che per comodità riportiamo di seguito:

Schema IVA

Codice

Descrizione

TAXIT

CA

Non Imp.Art.40 L.427/93 Vendite UE

TAXIT

CB

Non Imp.Art.41 L.427/93 Vendite UE

TAXIT

CC

Non Imp.Art.58/1 L.427/93 Vendite UE

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

23

 

Autore:

 

Data

Release 1,0

06/10/15

TAXIT

EA

Es. Art.10/1-9 Vendite

TAXIT

FA

Escl. Art. 2/A Vendite

TAXIT

FC

Escl. Art. 15/1 Vendite Int Mora

TAXIT

FD

Escl. Art. 15/2 Vendite Sconto in Natura

TAXIT

FE

Escl. Art. 15/3 Vendite Rimb. Anticipaz/Bolli

TAXIT

FF

Escl. Art. 26

Vendite

TAXIT

FG

Escl. Art. 68 Vendite

TAXIT

FH

Non Sogg.Art.74/7 Vendite

TAXIT

FI

Escl. Art. 15/4 Vendite Rimb. Imball. Resa

TAXIT

FL

Escl. Art. 15/5 Vendite Rivalsa IVA

TAXIT

G1

IVA 10% Vendite Beni Strumentali

TAXIT

G2

IVA 20% Vendite Beni Strumentali

TAXIT

G4

IVA 4% Vendite Beni Strumentali

TAXIT

NA

Non Imp.Art.8/A Vendite EXUE

TAXIT

NB

Non Imp.Art.8/B Vendite

TAXIT

NC

Non Imp.Art.8/1C Vendite Triangolazioni

TAXIT

ND

Non Imp.Art.8/2C Vendite Lettere Intento

TAXIT

NE

Non Imp.Art.8A,71 Vendite

TAXIT

NF

Non Imp.Art.8BIS Vendite

TAXIT

NG

Non Imp. Art. 9 Vendite

TAXIT

NH

Non Imp.Art.9/7 Vendite

TAXIT

S2

IVA vendite 20%, in sospeso

TAXIT

V1

IVA 10% Vendite

TAXIT

V2

IVA 20% Vendite

TAXIT

V4

IVA 4% Vendite

TAXIT

XA

Non Imp. Art.8A Vendite EXUE

TAXIT

ZZ

No IVA Vendite (non stampata a bollato)

Nella figura seguente alcuni codici IVA creati sul sistema di sviluppo:

Nella figura seguente alcuni codici IVA creati sul sistema di sviluppo:  Copyright 2006, SAP Italia
Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

24

 

Autore:

 

Data

Release 1,0

06/10/15

4. CONTROLLO DEL CREDITO.

Il processo di controllo del credito in fase di inserimento dell’ordine deve essere visto anche nell’ambito di un flusso più generale, che preveda, dopo l’inserimento dell’ordine di vendita prima il controllo del credito, e poi un controllo commerciale sull’ordine (vedi paragrafi successivi).

Raggiunto un esito positivo del controllo del credito, indipendentemente dall’esito del controllo commerciale, l’ordine è attivo e genera un fabbisogno di produzione.

In generale, il controllo del credito è attivato in fase di creazione dell’ordine cliente e controlla dinamicamente l’esposizione creditizia del cliente sulla base del limite fido impostato anagraficamente.

Ove il controllo suddetto dovesse fornire esito negativo, e secondo le diverse classi cliente che saranno definite nel seguito, l’ordine in oggetto potrebbe risultare bloccato per le operazioni successive.

Sarà disponibile una lista di lavoro che consentirà di estrarre i documenti bloccati, analizzarli dal punto di vista finanziario, ed eventualmente rilasciarli per le elaborazioni successive.

4.1. Anagrafica Fido.

Per ciascun cliente per il quale si vuole controllare l’esposizione in fase di inserimento ordine sarà creata una anagrafica fido nella transazione FD32, nella quale saranno definiti, fra gli altri, i seguenti valori:

Campo

Descrizione

Tipologia Cliente

Grandi Clienti, Clienti Normali, Canale Tradizionale

Affidamento

Valore di affidamento per il cliente, basato sulla solidità economica del cliente stesso, e sulla storia del rapporto commerciale con PASTIFICIO

Nelle figure seguenti un esempio di anagrafica fido creata per il cliente 1000.0027 (Grande Cliente, tipologia Trader):

fido creata per il cliente 1000.0027 (Grande Cliente, tipologia Trader):  Copyright 2006, SAP Italia Consulting
Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

25

 

Autore:

 

Data

Release 1,0

06/10/15

  Autore:   Data Release 1,0 06/10/15 Nella videata seguente si può verificare la situazione

Nella videata seguente si può verificare la situazione delle partite aperte (nel nostro caso la videata sarà vuota):

partite aperte (nel nostro caso la videata sarà vuota): L’erosione dell’affidamento sarà data da: Fatture

L’erosione dell’affidamento sarà data da:

Fatture emesse, e non ancora incassatesarà vuota): L’erosione dell’affidamento sarà data da: Merce spedita e non ancora fatturata Ordini confermati

Merce spedita e non ancora fatturatasarà data da: Fatture emesse, e non ancora incassate Ordini confermati (cioè ordini che hanno già

Ordini confermati (cioè ordini che hanno già superato il controllo del fido, o che sono stati sbloccati manualmente, ma non sono ancora stati spediti)e non ancora incassate Merce spedita e non ancora fatturata La funzionalità di controllo automatico del

La funzionalità di controllo automatico del fido verificherà, durante l’inserimento di ogni singolo ordine, che il valore ancora disponibile di affidamento (affidamento originario meno la somma degli ordini aperti, delle spedizioni effettuate, e delle fatture emesse e non ancor incassate), sia ancora superiore al valore dell’ordine in oggetto. E’ possibile definire un orizzonte temporale per il controllo dinamico del fido, cioè un orizzonte entro il quale sono inclusi i documenti commerciali da tenere in considerazione ai fini del controllo del fido.

Se questo controllo ha un esito positivo, l’ordine è rilasciato per il controllo commerciale, altrimenti resta bloccato, secondo le regole definite nel seguito del capitolo, fin quando non sarà analizzato, ed eventualmente rilasciato.

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

26

 

Autore:

 

Data

Release 1,0

06/10/15

4.2. Controllo fido per tipologia clienti.

I clienti sono classificabili in anagrafica secondo una serie di caratteristiche che li qualificano dal punto di vista del credito, e debbono implicare una reazione del sistema diversa sulle diverse classi di clienti.

Di seguito viene descritto il comportamento che dovrebbe avere il sistema per le diverse classi di clienti, in presenza di un superamento dell’affidamento concesso.

Tipologia

Descrizione

Controllo

Orizzonte

Controllo

Reazione

Blocco

Blocco

cliente

Fabbisogno

Spedizione

 

001 Grandi clienti

Dinamico

6

mesi

Esposizione

W

N

N

 

002 Clienti Normali

Dinamico

6

mesi

Esposizione

W

N

S

marchio stock

 
 

003 Clienti Normale

Dinamico

6

mesi

Esposizione

W

S

 

marchio commessa

 
 

004 Clienti Canale

Dinamico

6

mesi

Partite aperte

W

N

S

Tradizionale

 

Non è possibile prevedere due comportamenti diversi sull’ordine per tipologia cliente diversa. Nel caso in cui si voglia comunque effettuare il controllo solo sull’ordine, è possibile uniformare il comportamento del sistema fra i casi 1 e 2, e 3 e 4 rispettivamente, assegnando sulla anagrafica il gruppo cliente 001 e 003. Nel caso in cui si faccia questa scelta, sarà anche possibile modificare le corrispondenti descrizioni in customizing.

Nella figura seguente si vedono le regole definite, e la parametrizzazione del sistema per il controllo fido nel primo caso:

e la parametrizzazione del sistema per il controllo fido nel primo caso:  Copyright 2006, SAP
Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

27

 

Autore:

 

Data

Release 1,0

06/10/15

  Autore:   Data Release 1,0 06/10/15 4.2.1.Grandi Clienti. Per i grandi clienti, anche in

4.2.1.Grandi Clienti.

Per i grandi clienti, anche in presenza di uno sforamento del fido, il sistema dovrebbe presentare solo un avvertimento a video, ma non bloccare l’ordine.

4.2.2.Clienti normali.

Si vorrebbe distinguere due diverse categorie di clienti in funzione delle tipologie di articolo in ordine:

Nel caso di marchio con produzione a stock, il sistema dovrebbe reagire bloccando la conferma della consegna, ma lasciando nascere comunque il fabbisogno (alla peggio vendo il prodotto ad un cliente diverso)

Nel caso di marchio privato, il sistema dovrebbe reagire bloccando la conferma di ordine, quindi bloccando la nascita del fabbisogno.

Il sistema, però non riesce a gestire tipologie di articoli in ordine, ma solo tipologie di cliente: sarebbe quindi necessario definire due tipologie di cliente, ed assegnare a queste un comportamento diverso.

Per i clienti normali viene aggiunto il controllo sulle partite aperte:

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

28

 

Autore:

 

Data

Release 1,0

06/10/15

  Autore:   Data Release 1,0 06/10/15 4.2.2.1 Marchio con produzione a stock. Il sistema deve

4.2.2.1 Marchio con produzione a stock.

Il sistema deve bloccare la processazione dell’ordine (l’ordine non può essere spedito), ma deve comunque rendere l’ordine visibile alla programmazione della produzione (deve nascere il fabbisogno).

4.2.2.2 Marchio con produzione a commessa.

L’ordine nasce bloccato per la processazione e non deve generare un fabbisogno di produzione.

4.2.3.Canale tradizionale.

Questa è la situazione maggiormente complessa. In generale si tratta di clienti con condizioni di pagamento:

Pagamento alla consegna (cioè al vettore che consegna la merce) dell’ordine.

“Un ordine fuori”, e pagamento a vista al passaggio dell’agente

Se non viene effettuato il pagamento, gli ordini successivi per lo stesso cliente devono nascere bloccati per processazione, ma non per il fabbisogno (sono tipicamente ordini a marchio Pastificio, cioè per prodotti a stock).

Nelle figure seguenti il customizing di controllo fido per ordine e consegna:

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

29

 

Autore:

 

Data

Release 1,0

06/10/15

  Autore:   Data Release 1,0 06/10/15 della riunione del 01 marzo 2007 si modifica il
  Autore:   Data Release 1,0 06/10/15 della riunione del 01 marzo 2007 si modifica il

della riunione del 01 marzo 2007 si modifica il controllo fido per il canale

tradizionale, inibendo il controllo sulla consegna, ma bloccando gli ordini in caso di sconfinamento:

A fronte

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

30

 

Autore:

 

Data

Release 1,0

06/10/15

  Autore:   Data Release 1,0 06/10/15 Non è comunque detto che il pagamento seppure avvenuto

Non è comunque detto che il pagamento seppure avvenuto sia stato registrato nel sistema al momento dell’inserimento dell’ordine successivo.

Per gli ordini del Canale Tradizionale dovrà quindi essere definita da parte di PASTIFICIO una procedura organizzativa che preveda su ciascuna trasmissione ordini da parte dell’agente l’inserimento di una nota che evidenzi se l’ordine precedente sia stato pagato o meno.

In questo modo l’operatore che inserisce l’ordine sarebbe in grado di riconoscere se l’ordine va sbloccato, anche se il pagamento per qualche motivo non è stato ancora registrato nel sistema, ed inserisce una nota in ordine relativa alla segnalazione dell’agente, a memoria futura.

A. Clienti con pagamento alla consegna (al trasportatore)

Fido: il cliente viene affidato per un importo pari al valore massimo previsto di 1 ordine Associamo al gruppo fido “Canale tradizionale” il parametro “n° partite aperte” = 1 (cioè questo cliente può avere al max 1 partita aperta)

Schema di gestione dell’ordine.

Caso a) Il cliente paga allo scarico.

Fido al cliente = € 500

 

Importo

1. Controllo Fido

2. Spedizione

3. Pagamento

4. Consegna merce

Ordine 1

€ 400

OK

OK

OK

OK

Ordine 2

€ 500

OK

OK

OK

OK

Caso b) Il cliente non paga allo scarico e la merce rientra.

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

31

 

Autore:

 

Data

Release 1,0

06/10/15

Fido al cliente = € 500

 

Importo

1. Controllo Fido

2. Spedizione

3. Pagamento

4. Consegna merce

Ordine 1

400

OK

OK

NO

NO > reso

In questo caso, la mancata consegna genera un reso merce.

Bisogna individuare la procedura più idonea per gestire questa informazione.

Se il rientro merce viene seguito dalla emissione di NC a cliente, la partita 1 del cliente si azzera e quindi un eventuale ordine 2 supererà nuovamente il controllo del fido ed andrà in consegna. Si può, in alternativa, decidere di non emettere subito NC, in modo da far risultare ancora aperta la partita relativa all’ ordine 1. In questo caso l’eventuale ordine 2 non supererà il controllo del fido. Si può ipotizzare una gestione periodica degli elenchi di clienti con NC non emesse a fronte di rientro merce.

Caso c) Il cliente non paga allo scarico (o paga in parte), ma la merce viene consegnata.

Fido al cliente = € 500

 

Importo

1. Controllo Fido

2. Spedizione

3. Pagamento

4. Consegna merce

Ordine 1

400

OK

OK

NO

OK dietro autorizzazione

In questo caso la merce viene consegnata comunque. Sarà necessario prevedere le opportune procedure di autorizzazione e assegnazione di responsabilità.

La partita dell’ordine 1 risulta aperta, quindi l’eventuale ordine 2 non supererà il controllo del fido e non verrà spedito, se non sarà incassato prima l’ordine 1.

In tutti i casi sopraindicati il controllo del credito periodico è garantito dalla condizione di pagamento a 30 gg d.f.

B. Clienti con pagamento a passaggio agente.

Fido: il cliente viene affidato per un importo pari al valore massimo previsto di 1 ordine Parametro “n° partite aperte” = 1

Schema di gestione dell’ordine

Caso a) Il cliente paga all’agente l’ordine precedente.

Fido al cliente = € 500

 

Importo

1. Pagamento ad agente ordine precedente

2. Controllo Fido

3. Spedizione

4. Consegna

merce

Ordine 1

€ 400

-

OK

OK

OK

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

32

 

Autore:

 

Data

Release 1,0

06/10/15

L’Agente, nel momento in cui ripassa dal cliente per prendere l’ordine 2 (periodo che può essere di 2 o 4 settimane), deve incassare l’ordine 1.

A questo punto possiamo avere due casi.

L’agente si reca in azienda, consegna l’incasso dell’ordine 1 e consegna anche l’ordine 2. L’incasso viene registrato in SAP, la partita dell’ordine 1 viene chiusa. L’ordine 2 viene inserito a sistema e quindi il controllo del fido è ok. (necessità di organizzare la sequenza registrazione ordine 1 > inserimento ordine 2 - ? )

 

Importo

1.

Pagamento ad agente ordine precedente

2.

Controllo Fido

3.

Spedizione

4.

Consegna

   

merce

Ordine 2

500

 

OK

 

OK

 

OK

 

OK

Può succedere che l’Agente incassi l’importo dell’ordine 1, ma la consegna dell’incasso in azienda avvenga solo dopo alcuni giorni. La partita dell’ordine 1 non è chiusa, quindi all’atto dell’inserimento dell’ordine 2, il sistema darà il blocco.

 

Importo

1.

Pagamento ad agente ordine precedente

2.

Controllo Fido

3.

Spedizione

4.

Consegna

   

merce

Ordine 2

500

 

-

 

BLOCCO

 

BLOCCO

BLOCCO

E’ necessario prevedere una procedura in base alla quale l’agente segnala sull’ordine 2 una nota del tipo “incassato € 400 a saldo totale ordine precedente”.

Sulla base di questa indicazione l’ufficio preposto può procedere allo sblocco.

Caso b) Il cliente non paga all’agente (o paga parzialmente)

Fido al cliente = € 500

 

Importo

1.Pagamento ad agente ordine precedente

2.Controllo Fido

3.Spedizione

4.Consegna

merce

Ordine 1

€ 400

-

OK

OK

OK

Ordine 2

€ 500

NO

BLOCCO

BLOCCO

BLOCCO

Anche se l’agente dovesse trasmettere l’ordine 2 e l’ordine venisse digitato a sistema, ci sarebbe il blocco dello stesso per n° di partite aperte > 1 (oltre che per supero del fido).

Ciò vale anche in caso di pagamento parziale dell’ordine 1 (es. l’agente incassa solo € 200) e scrive una nota in calce all’ordine 2 “incassato € 200 a saldo parziale ordine precedente”. Sulla base di questa indicazione, l’ufficio preposto può procedere allo sblocco, secondo una procedura che deve essere definita: in questo caso però le partite aperte sono sempre 2, fino a quando non verrà saldato l’intero importo dell’ordine 1.

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

33

 

Autore:

 

Data

Release 1,0

06/10/15

In tutti i casi sopraindicati il controllo del credito periodico è garantito dalla condizione di pagamento a 30 gg d.f

Oggetto: Society / Project

Oggetto:

Society / Project

Modulo SD / Implementazione

mySAP.ERP

 

Documento

Pagina

Argomento: area Vendite e Distribuzione

Pastificio_Implementazio ne_SD I v01.doc

34

 

Autore:

 

Data

Release 1,0

06/10/15

5. GESTIONE PRICING.

Il sistema SAP R/3 supporta la gestione dei documenti di vendita con l’utilizzo di particolari

funzionalità standard, che permettono di agganciare automaticamente, in fase di creazione del documento, le condizioni di prezzo e di sconto associate all’area di vendita del cliente

e dei prodotti.

e

maggiorazioni.

Il prezzo finale di ogni posizione del documento di vendita è il risultato del calcolo effettuato sui valori attribuiti agli elementi di prezzo associati, quali il prezzo base, gli sconti, le maggiorazioni. E’ inoltre possibile, sullo schema prezzo della posizione documento, visualizzare a scopo statistico anche il prezzo nettissimo, cioè il prezzo che include anche le decurtazioni per bonus (sconti fuori fattura) e provvigioni.

Per

di

condizioni,

SAP

intende

l’insieme

prezzi

di

listino

del

prodotto,

sconti

Il Sistema SAP R/3, richiede la definizione di un tipo condizione per ogni elemento di prezzo indicato nello schema di calcolo associato al documento di vendita.

Per ogni tipo di condizione è necessario attribuire la corretta sequenza di accesso e di priorità ai valori dell’elemento di prezzo, i quali sono impostati dall’utente in archivi appositamente messi a disposizione dal sistema chiamati “schemi prezzo”.

Le

di

implementazione.

sequenze

di

accesso

qui

definite

saranno

validate

definitivamente

in

fase

5.1. Tabelle condizioni.

Si definiscono le seguenti tabelle condizioni per poter inserire condizioni di pricing in base alle caratteristiche commerciali degli articoli definite per il progetto:

Tabella

Cliente

Listino

Gruppo

Marchio

Categoria