[Gelöst] CC - DB weicht ab zwischen AU und RG

Hi,

Gegeben sei ein Auftrag mit 2 Positionen:
A: VK 30,69 - EP 16,80 - DB 13,89 - DB% 45,26
B: VK 13 - EP 12 - DB 0,50 - DB% 3,85

Mit F9 Statistik:
Total: VK 43,69 - EP 29,3 - DB 14,39 - DB% 32,94

Total Logisch :) Nun kommen wir zum Sonderfall:
A: VK 30,69 - EP 16,80 - DB 13,89 - DB% 45,26
B: VK 0 - EP 12 - DB -12 - DB% 0 (Theoritischer DB = -12, und DB% 0 weil Division durch 0 ja nicht geht)

Mit F9 Statistik:
Total: VK 30,69 - EP 28,80 - DB 1,89 - DB% 6,2

Auch noch total logisch , finde ich...

Dieser Sonderfall wird nun gebucht, in der Gebuchten Rechnung findet man dann:

Mit F9 Statistik:
Total: VK 30,69 - EP 16,80 - DB 13,89 - DB% 45,3 (Passt nicht mit der Statistik vom Auftrag überein)

In Tabelle "Cust. Ledger Entry" finde ich den DB 13,89.

Scheinbar wird an irgendeiner Stelle "Profit (LCY)" ignoriert wenn VK = 0 ist.
Kann ja nur während der Buchungsroutine sein?

Würde nun gerne nachschauen was da wo passiert, ob es da evtl. eine Individualisierung gab die Schuld sein könnte.

Habe das nun auch mal mit dem RTC probiert, im Auftrag bei Statistik F9 ist der DB 1,89, nach dem Buchen (in Geb. VK Rechnung) ist der DB 13,89
Also gleiches Problem.

Jemand ne Idee wo ich mal nachschauen könnte? Scheinbar wird beim Buchen die Auftragszeile mit VK = 0 irgendwo ignoriert. ?

Danke

Zuletzt geändert von elTorito am 4. Februar 2015 16:47, insgesamt 1-mal geändert.

Hallo,

generell kann man sagen, das der DB in einem Auftrag und der DB der Rechnung eher nie übereinstimmen.

bei Lagerabgangsmethode FIFO ist das eher Zufall.

Das kann nur funktionieren, wenn du sehr zeitnah die Lagerregulierung durchführst, sich die Einstandspreise der Artikel nicht ändern, zwischen Auftrag und Lieferung (die ist hier maßgebend) keine Zeit vergeht.

Erklärung:
- Wenn du einen Auftrag erstellst, wird der Einstandpreis und DB zum Zeitpunkt der Auftragserstellung aus der Artikelkarte bzw. den Lagerhaltungsdaten in den Auftrag übernommen.
- Diese beiden Werte ändern sich - im Standard - nicht, wenn du an den Preisen/Rabatten in der Auftragszeile etwas änderst (50% Rabatt, DB% bleibt der gleiche ).
- Wenn du die Ware lieferst sucht sich NAV einen positiven Artikelposten gegen den der Bestand und abgebucht wird.
- Der tatsächliche Einstandsbetrag deines Auftrags wird aus eben diesen positiven Artikelposten gebildet, und der kann ein ganz anderer sein, als der Durchschnitt von der Artikelkarte/Lagerhaltungsdaten
- NAV ab 2009 hat hier den "DB ursprünglich" und den "DB reguliert" eingeführt, der beide Informationen abbildet.
- Der "DB reguliert" kann sich auch später noch ändern, wenn du z.B. eine Lagerregulierung durchführst, oder du Zu- /Abschläge auf den zugehörigen Einkauf oder Verkauf buchst.

Gruß, Fiddi

Guten Morgen Fiddi,

ich verstehe...

immerhin schonmal schön das es kein Bug scheint, nicht so schön wie der Ablauf ist,...

Artikel sind bei uns FiFo, meistens passt der EP auch zu der Artikelkarte, ist jetzt erst aufgefallen, mit den VK = 0 Artikelzeilen,
was nun auch logisch scheint wenn sich NAV ein Positiven Artikelposten sucht.

Diese beiden Werte ändern sich - im Standard - nicht, wenn du an den Preisen/Rabatten in der Auftragszeile etwas änderst (50% Rabatt, DB% bleibt der gleiche ).

Dafür haben wir glaube ich eine "individual lösunG" , wir haben in Auftragszeilen ein Feld: "Akt. Spanne %", dieser zeigt für die Auftragszeile den Deckungsbeitrag an, in "DB%" ändert sich, wie du schriebst, der DB nicht ... so sehen wir welche marge wir in der Auftragszeile haben, und den DB% interpretieren wir als "diesen DB % sollte erreicht werden"

Mit Zu/Abschlägen arbeiten wir nicht, Lagerregulierung wird nächtlich ausgeführt.

Hintergrund der Geschichte ist eine Tabelle/Report , wir haben eine Custom Tabelle "UmsatzstatistiK" welche folgende Felder abbildet:
Verkauf (MW), DB(MW), Datumsfilter, Kostenstellenfilter

DB(MW) resultiert aus der Summe von "Profit (LCY)" aus den Debitorenposten (Cust. Ledger Entry) , ein Report bildet die Summen und stellt das Vorjahr und Monate Gegenüber, quasi um zu sehen: VK /DB im Januar dies Jahr, was war im letzten Jahr, VK/DB Differenz...

Wenn wir nun . aus welchen Grund auch immer, dem Kunden eine Leistung nicht in Rechnung stellen können (VK = 0), müssen diese Leistung aber unserem Lieferanten bezahlen (EP 12) , dann wird diese "Transaktion" nicht berücksichtigt , weil der "Negative DB " nicht im Debitorenposten abgebildet wird.

Meine Argumentation war: Es gibt keinen Negativen Deckungsbeitrag, weil DB% wegen Division durch Null nicht ermittelt werden kann. Entweder habe ich Gewinn oder keinen (im Falle von keinem , halt 0)... Aber nun gut, ich bin kein BWLer, wenn höhere Instanz meint es müsse ein Negativer DB abgebildet werden, dann wird diese wohl recht haben ...

Ich hab nun mal folgendes versucht:
2 Jungfräuliche Artikel, Ohne Posten, und ein Jungfräulichen Debitor, ohne Posten.
Artikel A: VK 100, EP 50,, DB%50
Artikel B: VK 40, EP 20, DB%: 50

Artikelzeile:
A: VK 100 - EP 50 - DB% 50
B: VK 0 - EP 20 - DB% 50

F9 Statistik sagt:
Total: VK 100 - DB 30 - DB% 30 (EP wäre 70)

Gebuchte Rechnung F9 Statistik:
Total: VK 100 - DB 50 - DB% 50

Also auch, "nicht richtig" trotz keine zugrunde liegenden Posten...

Hab mir nunmal die Wertposten angeschaut, ist der VK in der Artikelzeile = 0, wird dort Einstandsbetrag(tats.) = 0 gebucht.
Gebe ich hingegen ein VK von 0,001 ein, wird dort Einstandspreis (tats.) = 20 gebucht

Was mich wieder zu der Annahme führt das irgendwo ein "IF VK = 0" THEN EP = 0 behandelt wird :)

ich spinne das ganze mal weiter ...

In der Wertposten Tabelle, wo der EP = 0 gebucht wurde, ändere ich den Einstandsbetrag (tats.) auf -20 und Lagerregul. auf -20 ,
In der Gebuchten Rechnung ändert sich die F9 Statistik auf DB % Reguliert = 30 (würde ja dem DB entsprechen wie er im Auftrag war ...

Ok. Ich verrenne mich gerade etwas ...

ich versuch das mal anders anzugehen:

Wie könnte ich eine Umsatzstatistik darstellen , welcher auch den "Negativen" Deckungsbeitrag berücksichtigt , wenn ein Artikel zu VK = 0 verkauft wird?

Das geht doch gar nicht, oder?

Ist es denn richtig das in den Wertposten der Einstandsbetrag tats. = 0 gesetzt wird, wenn man VK= 0 bucht ?
Wenn hier zumindest der EP weggebucht würde der in der Auftragszeile eingetragen wurde, könnte ich die Wertposten zugrunde ziehen...

Mal gucken wie ich der höheren Instanz erkläre dass hier weder ein Bug, noch Feature vorliegt, dass es einfach so ist :)
Scheint mir zumindest so...

Ist es denn richtig das in den Wertposten der Einstandsbetrag tats. = 0 gesetzt wird, wenn man VK= 0 bucht ?

natürlich - im Standard - nicht

Du solltest die immer die Felder "Einstandspreis (erwartet)", "Einstandspreis (tatsächlich)" und "Einstandspreis (lagerwert unabhängig)" in den Artikelposten einblenden, das macht es etwas übersichtlicher.

Ein weiteres Problem könnte bei euch die Fakturierung der VK- Lieferung vor der EK- Rechnung (oder noch schlimmer: EK-Lieferung) sein. Dann könnte es mit dem DB in den Debitorenposten ein Problem geben. Generell ist es besser auf die Artikelposten oder noch besser Wertposten zu gehen um die Deckungsbeiträge zu ermitteln (sofern ihr keine Sachkonten in der VK- Rechnung habt).

Es gibt, meine ich, auch in NAV2009 schon einen Bericht, der den DB reguliert ermittelt, vielleicht kannst du das als Beispiel benutzen.

Gruß, Fiddi

Ist es denn richtig das in den Wertposten der Einstandsbetrag tats. = 0 gesetzt wird, wenn man VK= 0 bucht ?

natürlich - im Standard - nicht

hmm. Nochmal zum mitschreiben...
Also wenn VK = 0 ist, und dann Einstandsbetrag. (tats. ) = 0 eingetragen wird, dann ist es falsch?
Im Standard müsste da ein EP weggeschrieben werden, trotz VK = 0?

Du solltest die immer die Felder "Einstandspreis (erwartet)", "Einstandspreis (tatsächlich)" und "Einstandspreis (lagerwert unabhängig)" in den Artikelposten einblenden, das macht es etwas übersichtlicher.

Sind bei uns alle 0, wenn VK = 0 gebucht wurde.

Ein weiteres Problem könnte bei euch die Fakturierung der VK- Lieferung vor der EK- Rechnung (oder noch schlimmer: EK-Lieferung) sein. Dann könnte es mit dem DB in den Debitorenposten ein Problem geben. Generell ist es besser auf die Artikelposten oder noch besser Wertposten zu gehen um die Deckungsbeiträge zu ermitteln (sofern ihr keine Sachkonten in der VK- Rechnung habt).

OK. Soweit bin ich aber noch nicht ;) Ich probiere gerade in einer Testversion, da wird nichts "zwischengebucht" , und zeigt ja schon nicht das Gewünschte.

Es gibt, meine ich, auch in NAV2009 schon eine Bericht, der den DB reguliert ermittelt, vielleicht kannst du das als Beispiel benutzen.

So Adhoc fällt mir dazu nur der R112 (Verkaufsstatistik) ein, der aber auch seine Werte von den Debitorenposten bezieht... hmm...

Verfolge mal einen Artikelposten vom Einkauf bis zum Verkauf.

Dann sollte klar werden, woher der Einstandspreis im Auftrag/Rechnung kommt.

Der Einstandspreis 0 kann durchaus korrekt sein, wenn der Zugang auch mit 0 gebucht wurde, aber eher unwahrscheinlich, dass jemand eine Bestellung bei der Lieferung ohne Einkaufsbetrag bucht.

So Adhoc fällt mir dazu nur der R112 (Verkaufsstatistik) ein, der aber auch seine Werte von den Debitorenposten bezieht... hmm...

nicht nur!

114 macht es ähnlich, indem es den regulierten Betrag zu dem Debitorenposten sucht.

Hi,

Verfolge mal einen Artikelposten vom Einkauf bis zum Verkauf.
Dann sollte klar werden, woher der Einstandspreis im Auftrag/Rechnung kommt.

Meinst du ?

also,

2 Jungfräuliche Artikel , Jungfräulicher Kreditor und Debitor:

A: VK 100, EP 50 , DB% 50
B: VK 20, EP 10 , DB% 50

EK Bestellung
1 Stk A , EK 50
1 Stk B EK 10

Artikelposten nach EK Liefern/Fakt.:
A - EP (erwartet) 0, EP (Tatsächl) 50, EP (lagerwertunabh.) 0, VK erwartet 0, VK Tatsächl. 0
B - EP (erwartet) 0, EP (Tatsächl) 10, EP (lagerwertunabh.) 0, VK erwartet 0, VK tatsächl. 0

VK Auftrag
A- VK 100, EP 50 , DB% 50, DB% Berechn. 0
B- VK 0, EP 10 , DB% 50, DB% Berechn. 0

Statistik Auftrag:
VK 100, DB urspr. und reguliert 40, DB% (urspr. u. reguliert) 40, Urspr. EP 60, Lagerwert Reguliert: 60

Artikelposten nach VK Liefern/Fakt:
A - EP (erwartet) 0, EP (Tatsächl) -50, EP (lagerwertunabh.) 0, VK erwartet 0, VK Tatsächl. 100
B - EP (erwartet) 0, EP (Tatsächl) 0, EP (lagerwertunabh.) 0, VK erwartet 0, VK tatsächl. 0

Statistik Rechnung:
VK 100, DB urspr. und reguliert 50, DB% (urspr. u. reguliert) 50, Urspr. EP 50, Lagerwert Reguliert: 50

Statistik Rechnung (nach Lagerregulierung)!!!:
VK 100, DB urspr.50, DB reguliert 40, DB% urspr 50, DB%reguliert 40, Urspr. EP 50, Lagerwert Reguliert: 60, Kostenregulierungsbetrag: 10

R114:
VK 100, DB 50, DB reguliert 40, DB% 50, DB%reguliert 40,


Ok, erst nicht klar, nach der Lagerregulierung ist jetzt klar, wonach ich die ganze Zeit suche ist der "regulierte DB " ?

Richtig ?

Hallo,

das mit dem Einstandspreis 0 darf so nicht sein

wenn du 10€ Lagerwert geliefert bekommen hast, dann musst du auch 10€ Lagerwert ausliefern, egal was der Kunde dafür zahlt.

Sonst würdest du mit jedem solchen Verkauf deinen Lagerwert erhöhen, und vor allem ist der Lagerwert des Artikels nicht 0, wenn du keinen Bestand mehr hast. (akt. Lagerwert ermitteln)

Ich habe das eben in NAV 2013 noch mal nachvollzogen, da wird definitiv der Einstandspreis des Zugangs auch wieder abgebucht.

Gruß, Fiddi

Hallo,

das mit dem Einstandspreis 0 darf so nicht sein

wenn du 10€ Lagerwert geliefert bekommen hast, dann musst du auch 10€ Lagerwert ausliefern, egal was der Kunde dafür zahlt.

Sonst würdest du mit jedem solchen Verkauf deinen Lagerwert erhöhen, und vor allem ist der Lagerwert des Artikels nicht 0, wenn du keinen Bestand mehr hast. (akt. Lagerwert ermitteln)

Ich habe das eben in NAV 2013 noch mal nachvollzogen, da wird definitiv der Einstandspreis des Zugangs auch wieder abgebucht.

Gruß, Fiddi

Hmm. Habe ich da evtl. was falsches niedergeschrieben oder vergessen?

Artikelposten nach Lagerregulierung heben sich die Einstandsbeträge auf.
A EP (Tats.) 50 und -50
B EP (Tats.) 10 und -10

Lagerwert bei beiden Artikel = 0 .

Nochmal im schnelldurchlauf...

EK Bestellung mit Artikel A und B jeweils 1 Stk lief/fakt.

Lagerwert nun jeweils Zugänge = 2, Abgänge = 1, Wert: 50, und 10, Geb. Lagerreg. 50 und 10

Artikelposten:
A: EP (Tats.) 50
B: EP (Tats.) 10
(alle anderen 0 wie oben)

VK Auftrag mit :
A 1 Stk VK100, EP 50
B 1 Stk VK 0 , EP 10
F9 Statistik: VK 100, DB Urspr. 40, DB reguliert 40, Urspr. EP 60, Lagerwert reguliert 60, DB% 40

Liefern/Fakturieren...

Artikelposten:
A - EP (Tats.) -50, VK Betrag 100
B- EP (Tats.) 0 , VK Betrag 0

F9 Statistik für Gebuchte Rechnung: VK 100, DB Urspr. 50, DB reguliert 50, Urspr. EP 50, Lagerwert reguliert 50, DB% 50

Lagerwert:
A: Zugänge 2, Abgänge 2, Wert = 0 , geb. Lagerreg. 0
A: Zugänge 2, Abgänge 2, Wert = 10 , geb. lagerreg. 10

Lagerreg. fakt. Einstandspreise... danach:

Lagerwert:
A: Zugänge 2, Abgänge 2, Wert = 0 , geb. Lagerreg. 0
A: Zugänge 2, Abgänge 2, Wert = 0 , geb. lagerreg. 0

F9 Statistik für Gebuchte Rechnung: VK 100, DB Urspr. 50, DB reguliert 40, Urspr. EP 50, Lagerwert reguliert 60, DB% urs. 50%, DB%reguliert 40

In Wertposten wurde nach der Regulierung ein neuer Datensatz eingefügt wo sich die 10 EUR auf Lagerwert pro Einheit befinden.

Scheint richtig zu sein?

Also wenn:
A VK 100, EP 50
B VK 0, EP 10

dann habe ich , salopp gesagt, 60 EUR bezahlt, 40 EUR verdient, also DB = 40, was den regulierten DB entspricht.

Also brauche ich für "unsere" Korrekte Auswertung den Regulierten DB, und der kann erst korrekt sein nach einer Lagerregulierung ? :)

Also brauche ich für "unsere" Korrekte Auswertung den Regulierten DB, und der kann erst korrekt sein nach einer Lagerregulierung ? :)

Dem kann ich nur zum Teil zustimmen.
Die Lagerregulierung sollte eigentlich nur nötig sein, wenn sich der Lagerwert des durch den Verkauf ausgeglichenen Zugangs nach dem buchen der Verkaufslieferung ändert.
D.h. verkaufst EK- seitig nur gelieferte Ware und berechnest diese, bevor eine im Betrag abweichende EK- Rechnung gebucht wurde, oder verkaufst einen negativen Bestand, der erst später durch eine EK-Lieferung/-Rechnung ausgeglichen wird. Dann muss erst die Lagerregulierung laufen.
Ansonsten sollte der EP schon ohne die LR korrekt sein. !

Da hat wahrscheinlich mal jemand was programmiert, aber Gott sei Dank die Lagerregulierung vergessen.

Gruß, Fiddi

Also brauche ich für "unsere" Korrekte Auswertung den Regulierten DB, und der kann erst korrekt sein nach einer Lagerregulierung ? :)

Dem kann ich nur zum Teil zustimmen.
Die Lagerregulierung sollte eigentlich nur nötig sein, wenn sich der Lagerwert des durch den Verkauf ausgeglichenen Zugangs nach dem buchen der Verkaufslieferung ändert.
D.h. verkaufst EK- seitig nur gelieferte Ware und berechnest diese, bevor eine im Betrag abweichende EK- Rechnung gebucht wurde, oder verkaufst einen negativen Bestand, der erst später durch eine EK-Lieferung/-Rechnung ausgeglichen wird. Dann muss erst die Lagerregulierung laufen.
Ansonsten sollte der EP schon ohne die LR korrekt sein. !

Da hat wahrscheinlich mal jemand was programmiert, aber Gott sei Dank die Lagerregulierung vergessen.

Gruß, Fiddi

Ich sollte mal wieder den Cronus installieren um sowas zu testen ... da sucht man sich ja nen Wurm...

Aber du hast recht, habe nun ein VK-Auftrag (Menge ins Minus gebucht) , da wird dann nichts Reguliert. (Auch nicht nach Lagerregulierung)
Erst wenn ich eine Einkaufsbestellung buche, die mir den Bestand wieder auffüllt , bekomme ich den passenden regulierten DB / tatsächlichen ...

Ich glaub ich steig hier aus ...

Abschliessend noch folgende Behauptung (welche ich auch den Cheffe erläutern werde) :

Korrekter Deckungsbeitrag und Einstandspreisermittlung kann nur durch ordentlich gebuchte Artikel erreicht werden.
Und wenn ein Artikel 5000 mal verkauft wurde (mit unterschiedlichen EP's, dazu noch mal mit VK =0, mal nicht, nie eingekauft wurde) kann man da nichts 100% ermitteln ...

Müssen wir uns für die "Sonderfälle" was anderes einfallen lassen :)

Vielen Dank für deine Unterstützung/Hilfe Fiddi , zumindest mir ist nun klar geworden warum unsere Umsatzstatistik nicht 100% korrekt ist :)

...

- es MUSS einen Negativen Deckungsbeitrag geben
- Division durch 0 um DB% zu errechnen ist falsch, es muss möglich sein -DB% zu rechnen auch durch 0 ...
- am besten nochmal mit dem NSC sprechen, denn es handelt sich hier um einen Programmfehler
- Der Fehler ist klar, das passiert nur wenn VK 0 EP 0, ne VK 0 EP <> 0 ...
- Reden die Tage nochmal drüber ...

in 6 Monate habe ich das Thema wieder aufm Tisch, Wetten?

- es MUSS einen Negativen Deckungsbeitrag geben

Den gibt es bei jeder Transaktion, bei der der VK unter dem EP liegt. Positiver DB = Überschuss der Einzelerlöse über die Einzelkosten einer Bezugsgröße. Wenn man keinen Überschuss hat, ist der DB negativ. VK = 0 ist lediglich ein Sonderfall davon. Dann entspricht der negative DB dem kompletten EP (Warenwert).

habe nun ein VK-Auftrag (Menge ins Minus gebucht) , da wird dann nichts Reguliert. (Auch nicht nach Lagerregulierung)

VK mit negativer Menge ist eine bestandserhöhende Buchung, die werden nur reguliert , wenn man die Einstandspreisrückverfolgung nutzt (d.h. im Feld "Ausgeglichen von Artikelposten" einen negativen Artikelposten auswählt, dann sind die vom Wertefluss gekoppelt). Unabhängig davon können später ggf. noch Rundungsposten dafür entstehen, wenn diese Rücknahme wieder komplett abverkauft ist, siehe auch hier.

VK mit negativer Menge ist eine bestandserhöhende Buchung,

Ich denke er meinte in einen negativen Bestand gebucht.

Gruß Fiddi

VK mit negativer Menge ist eine bestandserhöhende Buchung,

Ich denke er meinte in einen negativen Bestand gebucht.

Gruß Fiddi

Hi,

ja, ich meinte Lagerbestand ins Minus gebucht

die ganze Geschichte ist halt etwas verwirrend...

Wir haben ja das individuelle Feld "Curr Span %", dieses zeigt die Spanne bzw. Deckungsbeitrag für die Artikelzeile an, ändert sich auch mit ändern des VK,
ich vermute mal dass dieses Feld implementiert wurde, weil das Feld "DB%" sich den Wert aus der Artikelkarte holt und nach überschreiben des VK in der Zeile nicht angepasst wird.

Dank fiddi habe ich ja nun erfahren das der DB nicht einfach nur VK-EP ist, sondern das die Einstandspreisregulierung da mit drin hängt. Sich deswegen im nachhinein der DB in einer Geb. RG ändern kann, und dass felder wie DB% Reguliert, Urspr. EP, usw... auch einen Sinn haben, und nicht nur angezeigt werden weils schön aussieht...

@Kowa, mit dem Negativen DB war falsch ausgedrückt, klar gibt es den, solange der VK kleiner als EP ist, ist der DB Negativ, ist der VK aber 0 geht die Rechnung:

DB% = (VK-EP)/VK x100 nicht auf, weil Division durch 0, in dem Falle hätte man gerne einen Deckungsbeitrag von -100% angezeigt.


Ich bin jetzt mal folgenden Fall durchgegangen(und habe mir meine Testbuchungen der letzten Tage mal angesehen),
und habe schon wieder ??? vor Augen...

Ich habe ein Artikel mit Lagerbestand 5 Stk, EP 11, ich erstelle ein Auftrag, Verkaufe 1 Stk zu 0 EUR, EP in der Auftragszeile ist 11.
Nach dem Buchen finde ich in der Geb. RG EP (Unit Cost (LCY)) = 0, demzufolge DB = 0 und DB%=0 (auch nach Lagerregulierung).

Auch in dem o.g. beispiel,

F9 Statistik für Gebuchte Rechnung: VK 100, DB Urspr. 50, DB reguliert 40, Urspr. EP 50, Lagerwert reguliert 60, DB% urs. 50%, DB%reguliert 40

In der Geb. RG ist für Artikel A der EP = 50, für Artikel B aber 0.

Der in der Auftragszeile eingegebene EP sollte sich doch in der Geb. VK RG Zeile wiederfinden? Oder? Auch wenn VK = 0 ?

So...

Habe in der CU 80 , in der Funktion "DivideAmount" (scheint mir Standard) ein :

Code:


WITH SalesLine DO
  IF (SalesLineQty = 0) OR ("Unit Price" = 0) OR ("Line Discount %" = 100) THEN BEGIN
    "Line Amount" := 0;
    "Line Discount Amount" := 0;
    "Inv. Discount Amount" := 0;
    "VAT Base Amount" := 0;
    Amount := 0;
    "Amount Including VAT" := 0;
   //ANPASSUNG ->
   "Unit Cost (LCY)" := 0;
  //ANPASSUNg <-


Gefunden...
Kommentiere ich es aus.. und wiederhole mein Beispiel:

Artikel mit Lagerbestand 5 Stk, EP 11, ich erstelle ein Auftrag, Verkaufe 1 Stk zu 0 EUR, EP in der Auftragszeile ist 11.
Nach dem Buchen finde ich in der Geb. RG und Geb. Lieferung, EP (Unit Cost (LCY)) = 11, demzufolge DB = -11 und DB%=0 (auch nach Lagerregulierung).

Diese -11 findet sich dann auch wieder in DB(MW) der Debitorenposten, auf welche unser Umsatzstatistik Report basiert.

Also scheint das:

"Unit Cost (LCY)" := 0;

der kleine Unruhestifter zu sein?
Oder warum sollte an dieser Stelle EP = 0 gesetzt werden?

Also scheint das:

"Unit Cost (LCY)" := 0;

der kleine Unruhestifter zu sein?

Ich denke schon.

Wie ich gestern schon schrieb:"Da hat mal irgendjemand was programmiert, und..."

Und das ganze wahrscheinlich nur, weil es irgendwo einen Report gibt, der mit negativen DBs nicht umgehen kann.

Gruß, Fiddi

Ich denke schon.
Wie ich gestern schon schrieb:"Da hat mal irgendjemand was programmiert, und..."
Und das ganze wahrscheinlich nur, weil es irgendwo einen Report gibt, der mit negativen DBs nicht umgehen kann.
Gruß, Fiddi

Ja, würde ja auch passen zu meiner Frage/Vermutung im Eingangspost:

Scheinbar wird beim Buchen die Auftragszeile mit VK = 0 irgendwo was ignoriert. ?

Werde das mal den NAV Partner weitergeben. Müssen die Korrigieren falls es keine plausible Erklärung gibt.

Danke!

Also scheint das:
"Unit Cost (LCY)" := 0;
der kleine Unruhestifter zu sein?

Wenn das pauschal immer gemacht wird, ohne VK-Gutschriften bzw. negative Eingabemengen in Aufträgen und Rechnungen auszuschließen, ist das gefährlicher Pfusch .
Dann werden alle Artikel mit VK=0 ohne Wert zurückgebucht. Wenn man dann keine Einstandspreisrückverfolgung aktiviert hat, bleibt es auch langfristig bei diesem Nullwert.

Also scheint das:
"Unit Cost (LCY)" := 0;
der kleine Unruhestifter zu sein?

Wenn das pauschal immer gemacht wird, ohne VK-Gutschriften bzw. negative Eingabemengen in Aufträgen und Rechnungen auszuschließen, ist das gefährlicher Pfusch .
Dann werden alle Artikel mit VK=0 ohne Wert zurückgebucht. Wenn man dann keine Einstandspreisrückverfolgung aktiviert hat, bleibt es auch langfristig bei diesem Nullwert.

Scheinbar Pauschal nur wenn:

Code:

IF (SalesLineQty = 0) OR ("Unit Price" = 0) OR ("Line Discount %" = 100) THEN BEGIN
"Unit Cost (LCY)" := 0;


Einst.-Pr.-Rückverfolg. notw. (Kreditoren Einrichtung?), haben wir nicht Aktiviert.

Was würde das in diesem Fall ändern?

Auf den EP(Durchschn.) hat sich bei uns noch nie jemand verlassen.
Ist auch nicht überall möglich, da hier desöfteren spezielle EK Preise für bestimmte Objekte ausgehandelt werden, oder Tagespreise...

Ich hoffe jetzt nicht das dieser "Bug" große Auswirkung auf irgendwelche relevanten Werte hat,
Hat ja auch nur 3 Jahre gedauert bis dass jetzt aufgefallen ist :)

Einst.-Pr.-Rückverfolg. notw. (Kreditoren Einrichtung?), haben wir nicht Aktiviert.
Was würde das in diesem Fall ändern?

Dann wird der Nullwertposten durch die Lagerregulierung nachträglich umbewertet, das war der vergleichbare Fall mit anderen Ursachen hier bzw. hier.
Ohne bleibt der Nullwert unverändert ( => falscher Lagerwert) und Abverkäufe von diesen Posten bekommen auch Einstandspreis 0 und damit eine falschen überhöhten Deckungsbeitrag ( => falsche DB-Ermittlung).
Manuelle Abhilfe: Den Posten korrekt bewerten mit einem Neubewertungsbuchblatt.

Hallo es wird sicherlich selten passieren, aber Kai hat schon Recht.

Wenn du Ware einbuchst (Artikelbuchblatt.-> schau mal ob da in CU 22 auch noch so ein Code drin ist) oder eine Gutschrift erstellst mit VK 0, dann würde der Artikel mit EP 0 eingebucht, nicht mit dem tatsächlichen EP, was wiederum dazu führen würde, das du noch merkwürdigere DBs in deinen Belegen bekommst. ( Verkaufst du eine solche Rücknahme, hast du 100% DB)

Warum ist das so: IN NAV werden alle Artikelzugänge (Art- Buchblatt{ Zugang,Einkauf}, Gutschrift, EK- Rechnung, Istmeldungen) mit dem dort angegeben EP berwertet und auch so weiter benutzt. Daran ändert auch eine Lagerregulierung nichts mehr, die sucht höchstens Abgänge, die sie mit diesen EPs beglücken kann.

Gruß, Fiddi

Warum ist das so: IN NAV werden alle Artikelzugänge (Art- Buchblatt{ Zugang,Einkauf}, Gutschrift, EK- Rechnung, Istmeldungen) mit dem dort angegeben EP berwertet und auch so weiter benutzt.

…es sei denn die Einstandspreisrückverfolgung ist eingeschaltet (s.o).