Il problema è questo: Creo un articolo NUOVO, che più normale non si puo’, costing: medio prezzo = costo + profitto margine = 37,5 - - - - Ne compro 10 a 1000 € (100 cad) ne deriva: costo medio = 100 costo unitario = 100 prezzo = 160 - - - - ne vendo 3 a 120 € cadauno F9 = 16.7 di margine, giusto - - - - ne acquisto altri 20 a 1500 € (75 cad) ne deriva: costo medio = 81.48 costo unitario = 100 (!!!) prezzo = 160 (!!!) ma perchè ??? nella 3.60 mi ricalcolava il prezzo! - - - - ne vendo 21 a 100 cadauno F9 = margine 0% (!!! il margine vero è 23.8 !!!) - - - - udite udite costo medio è diventato 16,67 (AAAAARGH) costo unitario sempre 100 (di nuovo AAAARGH) - - - - In poche parole noi abbiamo l’esigenza di variare il prezzo di vendita ad ogni carico, è QUESTO uno dei principali motivi per cui abbiamo scelto navision, e sembrava funzionare benissimo nella 3.60, ora abbiamola 3.70 abbiamo girato il tutto al nostro NSC che ci ha confermato il test, è allibito, ma non ci sa risolvere perchè dice che è cambiata la code unit 22, e in molto … è possibile che questo problema non sia stato sollevato da nessuno? 2) il costo unitario non dovrebbe SEMPRE essere copiato in automatico ad ogni variazione del costo medio ??? 3) l’operazione rettifica costi-prezzi crea ancora più casino, addirittura converte il costo medio (che io chiamo ponderato istantaneo, ovvero che tenga conto della giacenza effettiva al momento del carico) in costo medio STORICO !!! Potete aiutarmi ? grazie Gianni Capra
Devi far girare il batch Rettifica Costo - Mov. Art. (attenzione se avete molti movimenti e non l’avete mai fatto girare potrebbe impiegare diverse ore), con gli ultimi aggiornamenti il nuovo Costo Medio sostituisce il Costo Unitario solo quando quest’ultimo e 0. Questo ti permette di tenere il costo unitario fermo fin quando decidi di far girare il batch, il quale, oltre ad aggiornare la scheda articolo, crea un nuovo Movimento Valorizzazione di tipo Costo Diretto in modo che il costo del venduto e, di conseguenza, il margine siano corretti. Cmq la codeunit incriminata è la 5804, che aggiorna il costo medio solo quando la funzione è richiamata dall’aggiornamento batch. La funzione è UpdateUnitCost: Nuova versione: WITH Item DO BEGIN IF NewStdCost <> 0 THEN “Standard Cost” := NewStdCost; IF “Costing Method” = “Costing Method”::Standard THEN “Unit Cost” := “Standard Cost” ELSE BEGIN IF CalledFromAdjustment THEN BEGIN CostCalcMgt.GetRndgSetup(GLSetup,Currency,RndgSetupRead); IF CalculateAverageInclExpCost(Item,AverageCost,AverageCostACY) THEN IF AverageCost <> 0 THEN “Unit Cost” := ROUND(AverageCost,GLSetup.“Unit-Amount Rounding Precision”); END ELSE BEGIN IF (“Unit Cost” = 0) AND (InvoicedQty > 0) AND (LastDirectCost <> 0) THEN BEGIN CALCFIELDS(“Net Invoiced Qty.”); IF (“Net Invoiced Qty.” > 0) AND (“Net Invoiced Qty.” <= InvoicedQty) THEN “Unit Cost” := LastDirectCost; END; END; END; Vecchia versione: UpdateUnitCost(VAR Item : Record Item;LocationCode : Code[10];VariantCode : Code[10];LastDirectCost : Decimal;NewStdCost : Decimal;Upda WITH Item DO BEGIN IF NewStdCost <> 0 THEN “Standard Cost” := NewStdCost; IF “Costing Method” = “Costing Method”::Standard THEN “Unit Cost” := “Standard Cost” ELSE BEGIN IF LastDirectCost <> 0 THEN “Unit Cost” := LastDirectCost; CostCalcMgt.GetRndgSetup(GLSetup,Currency,RndgSetupRead); IF CalculateAverageCost(Item,AverageCost,AverageCostACY) THEN IF AverageCost <> 0 THEN “Unit Cost” := ROUND(AverageCost,GLSetup.“Unit-Amount Rounding Precision”); END; Non so cosa comporti l’eventuale modifica. In alternativa potreste cambiare l’OnValidate del campo “Calcola Prezzo/Margine” in modo che il calcolo si basi sul Costo Medio (che però va calcolato, v. form scheda articolo) invece che sul Costo Unitario, questo trigger è richiamato dalla funzione incriminata, quindi dovrebbe risolvere il vs problema di calcolo prezzo, anche se il margine della vendita sarà corretto solo dopo aver eseguito il batch di Rettifica Costo - Mov. Art. Elena
Elena, per prima cosa grazie davvero! Però mi puoi spiegare cosa c’entra quel 16,67€ che viene fuori nel costo medio dopo la seconda vendita? secondo me è un vero e proprio buco. I ns prezzi cambiano tutti i giorni… Quando mi dici di far girare quella procedura intendi dire per rimettere le cose a posto, vero? Cioè se ho capito bene, la lancio e poi modifico la code unit per fargli calcolare il prezzo sul costo medio. Però poi al prossimo giro mi sbaglierà ancora il costo medio, no? Scusami se non ho capito bene… ed in ogni caso grazie per la risposta. Ciao Gianni
16,67 è il rapporto tra il margine e il prezzo: 20 : 120 = x : 100 il margine è una percentuale sul prezzo, non sul costo. I miei suggerimenti erano diversi e alternativi non complementari 1) far girare il batch Rettifica Costo - Mov. Art. ogni volta che volete aggiornare il Costo Unitario della scheda Articolo 2) modificare il calcolo del Prezzo Unitario della scheda articolo in modo che si basi sul Costo Medio (che però va calcolato richiamando un’apposita funzione) 3) modificare la codeunit 5804 in modo che aggiorni il Costo Unitario ogni volta che il Medio cambia. La terza è la più rischiosa perché non ne conosco le implicazioni, bisognerebbe verificare i motivi per cui la codeunit in questione è stata modificata. Devo dire che un collega durante un corso mi ha detto di preferire il funzionamento attuale perché in questo modo il margine, in fase di ordine, è calcolato su un costo noto che non sarà variato finché non si deciderà si eseguire il batch (esattamente l’opposto di quello che vorreste voi). La prima non prevede modifiche, ma non so se per voi è percorribile. La seconda … sistema il prezzo unitario ma il margine sull’ordine è sbagliato, troverai il margine corretto sul Mov. cont. art. di vendita (e i suoi Mov. Valorizzazione), ma solo dopo avere fatto girare il batch. Ora vado al mare … Buona Pasqua. Elena
Ciao Elena, leggerai questo post al ritorno dal mare [8D] … e ti auguro sinceramente di trovare bel tempo! intanto: certo che il margine è quello che dici, ma 16.67 LO METTE NELL’AVERAGE-COST !!! Scusami se sono zuccone, ma se anche personalizzo in modo che copi (come dovrebbe fare, leggendo tutti i manuali e gli help possibili, ed anche leggendo parecchie lamentele in merito nelle sezioni internazionali) il costo medio sull’unitario, come faccio se il medio è calcolato a raglio??? Non posso certo lanciare il batch ogni volta, e poi il batch mi fa lo STORICO!!! Ciao e grazie Gianni
Rieccomi … il tempo ha retto solo fino a ieri … dove sforzarti di più con gli auguri [:D] Tornando al tuo problema, scusa avevo letto di fretta, per il costo medio a 16,67 la spiegazione sta nel fatto che anche la seconda vendita è valorizzata al costo di 100, e rimarrà così finché non farai girare il batch, quindi il tuo medio deriva da: +10 * 100 = +1000 -3 * 100 = -300 +20 * 75 = +1500 -21 * 100 = -2100 ==== ====== 6 100 Costo Medio = 100 / 6 = 16,67 (questi valori dovresti trovarli nei mov. valorizzazione che vedi dal drill-down del costo medio) dopo aver fatto girare il batch, ammesso che la sequenza con cui hai riportato i tuoi movimenti coincida con la sequenza per data di registrazione, avrai: +10 * 100 = +1000 -3 * 100 = -300 +20 * 75 = +1500 -21 * 81,48 = -1711,11 ==== ====== 6 488,89 Costo Medio = 488,89 / 6 = 81,48148 ti torna?
quote:
Originally posted by elbi
Devo dire che un collega durante un corso mi ha detto di preferire il funzionamento attuale perché in questo modo il margine, in fase di ordine, è calcolato su un costo noto che non sarà variato finché non si deciderà si eseguire il batch (esattamente l’opposto di quello che vorreste voi).
In effetti credo che il vecchio sistema facesse rabbrividire molti amministrativi, perche’ non permetteva di avere un costo medio di periodo, necessario per effettuare valorizzazioni “a posteriori” ovvero in sede di bilancio. Pero’ non capisco perche’, avendoci messo le mani, non abbiano creato due campi, uno col “Costo medio corrente”, calcolato in tempo reale, come era prima, e un “Costo medio di periodo” da calcolare periodicamente, a bocce ferme. Se dovessi prendere in considerazione una personalizzazione, mi orienterei su questa soluzione. Anna
Ciao Elena, ciao Anna. Gentilissime. (quindi approfitto per tediarVi ancora un po’) x Elena: 1) scusa se gli auguri non hanno funzionato, anche per me 4 giorni chiuso in casa dalla suocera con i nipotini che mi hanno costretto a Risico e Monòpoli ripetuti [xx(] Speriamo nella prox pausa [8D] Dunque: la domanda sul 16,67 era retorica, nel senso che avevo capito COME faceva il conto, ma da quando in qua si considerano le VENDITE nei COSTI? Non è un controsenso? L’unica spiegazione che mi do’ è che se considero le vendite “a copertura” dei costi di acquisto, effettivamente i 6 pezzi rimanenti hanno un residuo di costo totale di 100€ quindi secondo questo perverso ragionamento i commerciali non hanno marginato sulle vendite, bensì hanno fatto in modo che i 6 pezzi che rimangono costino pochissimo … E’ un po’ stravagante no? Inoltre: far girare il batch NON riporta effettivamente a 81.48, bensì a 83.33, ovvero: 10 * 100 = 1000 20 * 750 = 1500 (1000+1500) / (10+20) = 2500 / 30 = 83.33 ovvero il “costo medio ponderato STORICO” Il che è vecchio di 15 anni come ragionamento … x Anna: grazie anche a Te. D’accordissimo, infatti il loro ragionamento cozza pesamente con altre scelte di tipo amministrativo. Ritengo che la valorizzazione di magazzino, per un amministrativo, sia stata fino a qualche anno fa di 5 tipi preponderanti: (correggetemi se sbaglio) 1) CMP (costo medio ponderato storico) 2) LIFO 3) FIFO 4) ultimo costo di acquisto 5) media aritmetica degli ultimi “n” costi di acquisto Navision introduceva a mio parere il calcolo MIGLIORE, ovvero quello del costo medio ponderato ricorsivo (ovvero basato di volta in volta sulle giacenze effettive non impegnate, sommate al carico “attuale”) Chiamiamo: GL la giacenza libera da impegni CMPR costo medio ponderato ricorsivo QC quantità da caricare adesso C costo unitario della merce da caricare adesso Al momento di un carico: NuovoCMPR = ((CMPR * GL) + (C * QC)) / (GL + QC) … ERA OTTIMO !!! … Mi consigliate di personalizzare? Il mio problema è come NON fargli conteggiare le vendite nel calcolo del costo medio? Grazie ancora e scusate tutti per il post lunghissimo.
quote:
Originally posted by gianus
Inoltre: far girare il batch NON riporta effettivamente a 81.48, bensì a 83.33, ovvero: 10 * 100 = 1000 20 * 750 = 1500 (1000+1500) / (10+20) = 2500 / 30 = 83.33 ovvero il “costo medio ponderato STORICO” Il che è vecchio di 15 anni come ragionamento …
dici questo perché hai provato? se il tuo risultato dopo l’aggiornamento è 83,33 … o abbiamo una diversa versione di programma o qualche dato diverso … ho appena fatto una verifica veloce e ti garantisco che dopo aver fatto girare il batch il costo medio è 81,48167
??? riprovo subito, di persona. L’avevo fatto provare ad un collega. riprovo adesso. ciao
Elena, ciao. Fa esattamente 83.33 periodico, come ti avevo detto. La qual cosa peggiora la situazione. Ora: 1) Prima che mi scordi, PERCHE’ solo la SECONDA vendita modifica il costo medio ??? 2) comunque, vediamo perchè a me viene 83,33 ed a Te 81,48etc non so che patch ci sia installata, nel senso, se la cosiddetta patch “09” è installata (parlo per sentito dire) si capisce dal fatto che alcune tabelle hanno una certa version list? se sì, ti dico la version list della table 32: Item ledger entry: NAVW13.70.00.09,NAVIT3.70.00.09.00.01 2) Il db è SQL server, credo sp3. grazie ancora, prima o poi cercherò di sdebitarmi. Ciao
Come ti dicevo è determinante la sequenza per data di registrazione. Se le 4 operazioni hanno tutte la stessa data, considera prima i due acquisti, poi le due vendite e di conseguenza il medio è di 83,33. Se invece registri con date diverse, es: 020404 il primo acquisto 020404 la prima vendita 030404 il secondo acquisto 030404 la seconda vendita ottieni il costo 81,48167
E’ proprio così. Ma ti pare ???
quote:
Originally posted by gianus
E’ proprio così. Ma ti pare ???
Secondo te come POTREBBE fare? [:p] Anna
quote:
Originally posted by gianus
E’ proprio così. Ma ti pare ???
Certo che mi pare, questo ti permette di avere uffici diversi che fanno le stesse registrazioni senza doversi sincronizzare o cmq, se per qualunque motivo ti sei dimenticato una registrazione e la inserisci con una data di registrazione precedente alle ultime fatte, questo non ti causa problemi nel calcolo del medio, infatti il batch riprende i movimenti e li rimette in sequenza di data registrazione rettificando dove necessario il costo del venduto. In questo modo il costo del venduto è il costo medio della giacenza presente al momento della vendita. Inoltre se le fatture di acquisto arrivano in ritardo (oppure registri un addebito articoli assegnandolo ad un acquisto, es. spese di trasporto), dopo la loro registrazione il batch ti rettifica il costo del venduto delle vendite avvenute dopo il carico ma prima della registrazione fattura. Per questi motivi, se anche facessi l’aggiornamento del costo unitario ad ogni nuovo acquisto (come prima del SP1), avresti sì un valore più vicino al costo medio reale, ma non potresti cmq prescindere dal batch in questione. A me sembra che tutto ciò abbia senso, soprattutto in considerazione del fatto che in versioni precedenti, se non registravi in sequenza, i conti non tornavano.