search

nippur72 / issuep

0 stars 1 forks source link

Riunificazione DocMag + Provvigioni #33

Closed nippur72 closed 9 years ago

nippur72 commented 9 years ago

Ho riunificato Provvigioni con DocMag, così come ho fatto per Margini.

C'è una finestrella che riporta i valori delle provvigioni e che abilita la visualizzazione corpo / piede.

Da notare:

mariocarmelo commented 9 years ago

Peccato! Sarebbe stato un ottimo sabato 9/5 col testare questa versione di documenti di magazzino. Con Rosalba avevamo appena discusso delle "finestrelle", della loro praticità e del contenuto e significato dei valori delle variabili. Il piacevole lavoro è stato compromesso dalle modifiche #34 e dal gestore fresco di giornata. Ora è tutto bloccato.

nippur72 commented 9 years ago

usa #39

studioReggio commented 9 years ago

Nel provare le provvigioni ho notato che se cancello una % provv. in un rigo di omaggio o di sconto merce (che cmq per definizione non dovrebbero esserci) da errore: " Operation did not succeed because the program cannot commit or quit a cell vaue change" linea 3140 Inoltre , se cancello una provvigione esistente nel piede documento non dovrebbero scattare automaticamente eventuali provvigioni rigo esistenti? (prima era così) Infatti le provvigioni rigo e piede prima erano alternative tra di loro . Stabilire una volta per tutte se devono continuare ad essere così oppure possono coesistere entrambe.

studioReggio commented 9 years ago

Non vengono calcolate le provvigioni per gli articoli di tipo 5 (voce ad importo)

nippur72 commented 9 years ago

L'errore non sono riuscito a riprodurlo, comunque avendo messo le celle readonly non dovrebbe più capitare.

IMPORTANTE: ho rimaneggiato la funzione AggiornaImportRigo() dovreste controllarla per vedere se è tutto ok.

mariocarmelo commented 9 years ago

Alla domanda di Rosalba la risposta è affermativa: le provvigioni sul rigo e quelle sul piede devono coesistere. Infatti le provvigioni calcolate sul rigo sono legate all'articolo venduto ed al prezzo praticato; mentre quelle sul piede alla persona dell'agente ed ad ogni possibile contratto anche individualmente stipulato. Le opzioni possibili nel calcolo delle provvigioni saranno molteplici e questo non è altro che il primo passo appunto prima di tutto di chiarezza concettuale. Queste stesse delucidazioni dovrebbero cominciare a trovare giusta collocazione dentro l'help/manuale di magazzino a documento e commento di tutte le possibilità funzionali. Potremmo anche pensare all'impostazione di FAQ di procedura. Che ne pensate?

nippur72 commented 9 years ago

Ho rivisto l'intero meccanismo delle provvigioni, eliminando la mutua esclusione delle provvigioni corpo e piede.

Adesso le provvigioni corpo vengono accumulate nel castelletto (in maniera invisibile) e sommate alle provvigioni del piede.

Poichè ho rimescolato parecchio codice, andrebbe ritestato.

mariocarmelo commented 9 years ago

Dal test emergono un bel po' di problemi con le provvigioni. Vediamo con un po' di pazienza di eliminarli tutti uno alla volta. Cominciamo dal più importante. Se vario il prezzo prelevandolo da listini non cambia in + o in - la provvigione per solo calcolo matematico ma può cambiare anche la % applicata. Infatti al prezzo precedente poteva essere associata una percentuale es. 10% ed al nuovo un'altra es. 5%. F5 da listini assieme al prezzo in modifica deve controllare o prelevare anche la % provvigione associata.

mariocarmelo commented 9 years ago

La finestra delle provvigioni presenta le stesse ambiguità della prima versione di margini. Entro questa sera spero di contribuire a renderla più chiara apportando direttamente le modifiche necessarie.

mariocarmelo commented 9 years ago

Dalla finestra provvigioni come è ora impostata vengono visualizzate le provvigioni calcolate nel corpo in valore assoluto e percentuale. Queste provvigioni sono determinate dal listino articoli o da modifica manuale nel corpo. Le provvigioni piede similarmente sono determinate dalla percentuale ProvvAgente1 inserita anche manualmente dalla mini finestra. Queste in CalcolaTotaleDocumento sono determinate in modo errato per la 6738 ["imponibile"] che deve essere al netto delle spese come giusto fa 7371 in CalcolaProvvigioni su (totImp-totSpese). Le provvigioni totali sono date in CalcolaTotaleDocumento da provv_corpo + provv_piede; ma va rivisto tutto il contesto, calcoli e quadrature.

mariocarmelo commented 9 years ago

Ritengo importante qualche chiarimento in relazione al "contesto". Stiamo procedendo seguendo un ordine concettuale e stiamo cercando di trasferirlo più linearmente possibile nei moduli. Con riferimento alle provvigioni sono chiare le provv_corpo e le provv_piede. Entrambe con le modifiche in corso sono determinate sia in CalcolaTotaleDocumento che in CalcolaProvvigioni. Questo non è certamente il massimo della chiarezza e semplificazione. Aggiungo che le provvigioni sono assolutamente ininfluenti al TotaleDocumento quindi nella CalcolaTotaleDocumento() non dovrebbero esserci se non per generare confusione (vedi: provv_piede = Math.ERound(totali["Imponibile"] * Tabmag_DocMag.ProvvAgente1/100) e grave appesantimento nella rideterminazione quando l'operatore interviene con modifiche estemporanee nel corpo e/o nella mini finestra. Le provvigioni determinate nel documento sono movimento di: costo per il margine, fatturato agente, contabilità.

nippur72 commented 9 years ago

Ho implementato la seguente funzione:

Ciò è stato ottenuto restituendo una mappa tipo { prezzo: 10, provvigione: 3 } al posto del singolo valore.

Modificato Articoli.pc e messo dei TODO in altri moduli da sistemare.

Se è OK procedo a completare la modifica.

mariocarmelo commented 9 years ago

La modifica è OK. Ho sistemato quei calcoli di cui ho scritto sopra. Controlla con "Beyond Compare" CalcolaProvvigioni() e CalcolaTotaleDocumento(). Ho sostituito anche un paio di totali["Imponibile"] in totali["TotMerce"] perché provvigioni e sconti cassa o valuta vanno calcolati sulla merce venduta e non sull'imponibile che comprende anche omaggi e spese. Se sorgono dubbi sono sempre raggiungibile.

studioReggio commented 9 years ago

Dal collaudo effettuato sulla versione del 19.05 di documenti magazzino ho riscontrato : se elimino un omaggio non viene riportato il doc. in elaborazione (rosso) , e anche forzando il tasto Aggiorna/ricalcola, non viene aggiornata la partita doppia

studioReggio commented 9 years ago

Se scrivo nelle provvigioni piede documento 2% , lo trasforma in 2,02%

nippur72 commented 9 years ago

Riguardo l'errore della cancellazione omaggi, in realtà non funzionava nemmeno per gli altri tipi-rigo. L'ho sistemato.

Riguardo a 

Se scrivo nelle provvigioni piede documento 2% , lo trasforma in 2,02%

non riesco a riprodurre l'errore, se ti capita ancora magari lo vediamo online in diretta.

mariocarmelo commented 9 years ago

La modifica della % provvigioni piede documento avviene solo quando viene inserito un valore negativo in quanto interpretato importo deve essere trasformato in % sul totale merce. Il valore positivo del campo non è mai sostituito. Un problema però esiste ed è ben complesso. Se i prezzi sono dichiarati IVA esclusa tutto è OK. Se i prezzi sono determinati IVA compresa vengono i dolori perché la provvigione del piede, prima di calcolarsi, deve tenere presente lo scorporo dell'IVA relativa "solo" alla merce e non anche l'Iva su omaggi, spese ecc. Pertanto, per risolvere bene il problema, la funzione: CalcolaProvvigioni() deve essere rivista ma prima occorre prevedere tra i valori di Castelletto_GetTotali() un "imponibile_per_provvigioni" appunto per un calcolo provvigioni accurato anche nel piede.

mariocarmelo commented 9 years ago

Fermo restando quanto scritto sopra, ricordo che le provvigioni calcolate sul piede possono essere considerate: "aggiuntive" a quelle del corpo ed è il caso soddisfatto attualmente dal programma; "sostitutive" e l'ipotesi è di semplicissima soluzione con: TabCoge_Comovditte.ImportoProvAgente = provv_piede; "su condizione" che vivaddio ci "spalancherà" le porte del "sorgente esterno personalizzato".

mariocarmelo commented 9 years ago

Fuori argomento: l'apice inverso che non c'è in tastiera qual è il codice? Ora ho usato il taglia ed incolla () questo scritto è tra apici inversi clonati ()

nippur72 commented 9 years ago

l'apice trasverso è ALT+96, ma conviene fare come ho fatto io, cioè una hot-key mappata su CTRL+' (utilizzando il programma "autohotkey").

Restando sempre fuori argomento, il singolo apice trasverso rende codice una parola singola mentre tre apici trasversi ad inizio riga servono a delimitare un blocco di codice su più linee:

` ` `
codice
codice
codice
` ` `
studioReggio commented 9 years ago

Guardate la fattura n. 7 in Stage che ripropone l'errore di % provvigione al piede documento segnalato: inserisco 2 e lo trasforma in 2,06 .

mariocarmelo commented 9 years ago

È' solo una questione di precisione in funzione delle cifre decimali. Il 2% di 6,79 è 0,1358 rappresentato con due sole cifre decimali diviene 0,14. La piccola differenza in valore assoluto è di € 0,042 che in % su 6,79 fa appunto 0,062%. L' "errore" nella 7 è identico sia se il 2% di 6,79 è calcolato nel piede che nel corpo.

nippur72 commented 9 years ago

si, sembra essere un effetto collaterale dell'arrotondamento: il 2% di provvigione su 6.79 porta al ricalcolo della stessa aliquota all' 1.95%.

mariocarmelo commented 9 years ago

Per chiudere questo "ticket" occorre sistemare le provvigioni piede "sostitutive": TabCoge_Comovditte.ImportoProvAgente = provv_piede e quelle "su condizione" abilitando un modulo sorgente esterno personalizzato. I moduli: Agenti e Clienti e relative tabelle nel Grande Creatore sono già stati modificati (rev. DB 53) con l'inserimento di due nuovi campi: TipoProvvigione tinyint (1=aggiuntiva; 2=sostitutiva; 3=condizionata). PersonalizzazioneProv, varchar(256) per contenere il nome completo di percorso del file sorgente esterno personalizzato quando TipoProvvigione=3.

nippur72 commented 9 years ago

per poter proseguire mi serve sapere:

mariocarmelo commented 9 years ago

Non mi pare che attualmente la procedura si preoccupi più di tanto di scrivere la % provvigioni in DocMag. Decideremo dopo di questa necessità o meno. Certamente l'importo è scritto in Comovditte. Importante è il flusso seguente: 1) le provvigioni del corpo sono sempre quelle di articoli. 2) le provvigioni del piede possono provenire nell'ordine: dall'agente,dal cliente, dalla tastiera. La successiva esclude la precedente. Sia dall'agente che dal cliente il tipo provvigione può essere: aggiuntiva,sostitutiva,personalizzata. Le provvigioni teoricamente non andrebbero calcolate solo nei documenti interni ma preferisco l'attuale funzionamento di Portento che le ammette sempre. Infatti l'operatore può comunque toglierle in qualsiasi momento ma esiste anche un altro accorgimento grazie al punto 2 di sopra. Se un cliente ha provvigione zero aggiuntiva allora rimarranno le provvigioni del corpo mentre una provvigione nel cliente zero sostitutiva azzererà ogni importo. I controlli per le provvigioni del piede li farei partire dal cliente se TipoProvvigione=0 ossia provvigione non prevista allora il controllo può passare all'agente dove % Provvigione=0 e TipoProvvigione =0 di fatto rappresentano la stessa cosa.

nippur72 commented 9 years ago

Ho implementato le modifiche di cui sopra:

Ho difficoltà a testare le modifiche in quanto su stage il DB è diventato inconsistente, dà un sacco di errori.

studioReggio commented 9 years ago

DB su Stage OK

studioReggio commented 9 years ago

Attenzione: documenti di magazzino attualmente su Stage non cancella più un documento. Provato anche attraverso Acquimov non funziona..
Sarà un effetto collaterale relativo alle transizioni modificate di recente?

studioReggio commented 9 years ago

vedi #69

mariocarmelo commented 9 years ago

Riapro l'issue perché le provvigioni piede sembrano non funzionare. I ticket vengono chiusi con molta facilità. Chi ha collaudato le provvigioni? Chi ha controllato il comportamento nel passaggio a P.D? Chi le relazioni con la scheda dell'agente?

nippur72 commented 9 years ago

I ticket si devono limitare a problemi specifici, questo ticket era relativo a "Riunificazione DocMag + Provvigioni" e siccome la riunificazione è stata fatta ed il codice è stato "revisionato" (da non confondere con "testato") è giusto chiuderlo.

Se ci sono altri problemi che si aprano altri ticket (visto che sono gratis).