SAP Jobsuche bei DV-Treff
andros
  • andros
  • SAP Forum - Guru Thema Starter
vor 17 Jahre
Hallo zusammen,

ich habe gerade feststellen müssen dass die Steuerklassifikation Kunde - obwohl sie auf Vertriebsbereichsebene erfasst wird - vertriebsbereichsübergreifend wirkt.

D. h. gebe z.B. bei einem Kunden mit VKORG 1000 die 0 für steuerfrei ein, ändert sich auch die Betrachtung des gleichen Kunden nur mit VKORG 2000.

Ist da im Customizing noch etwas schief bzw. fehlt da etwas?

Schaue ich mir allerdings die Tabelle KNVI an welche da im Hintergrund wohl benutzt wird, sehe ich schon das die Steuerklassifikation wohl nur je Land gespeichert wird.

Nun haben wir aber Kunden welche innerhalb des Konzerns eine Organschaft darstellen und deshalb für Vkorg der gleichen Organschaft mehrwertsteuerfrei, für Vkorg ausserhalb der Organschaft jedoch mehrwertsteuerpflichtig sind. Dies wäre ja sehr einfach über die Pflege zum Vertriebsbereich zu lösen wenn es sich denn so pflegen liesse wie es ursprünglich den Anschein hatte.

Kennt jemand dieses Problem und / vllt. auch die Lösung?

OSS gibt dazu nix her.
Gruss

Andreas

-----------------------------------

encore
vor 17 Jahre
Hallo Andros,

das Abgangs-Land (und damit das Land zur Steuerkennung) wird ja beim Anlegen des Vertriebsbereich-Satzes direkt vorbelegt, und zwar mit dem Land aus dem Buchungskreis (T001), wohl über die Zuordnung VkOrg - BuKrs. Damit steht im Regelfall das Lieferland fest, und damit die Steuerlogik.
Somit müsstest du schon einen eigenen Buchungskreis in einem anderen Land eröffnen, um dahin zu kommen, wo du möchtest.

Ich bin zwar kein Steuerfachmann, aber es kommt mir ungewöhnlich vor, dass im gleichen Buchungskreis Organschaft und Nicht-Organschaft zwischen "Unternehmen" vorliegt.

Evtl. hilft es dir weiter, wenn du mal nachschaust, was unter F1 im Feld STEUERKLASSIFIKATION der Vertriebsbereichdaten dokumentiert ist (User-Exit etc.)
Grüsse

nk

andros
  • andros
  • SAP Forum - Guru Thema Starter
vor 17 Jahre
encore schrieb:

Ich bin zwar kein Steuerfachmann, aber es kommt mir ungewöhnlich vor, dass im gleichen Buchungskreis Organschaft und Nicht-Organschaft zwischen "Unternehmen" vorliegt.

Sorry, habe in dem Beispiel nicht geschrieben dass natürlich auch ein anderer Buchungskreis betroffen ist.

Ich wollte drauf hinaus dass das Ganze am Vertriebsbereich aufgehängt zu sein scheint (zumindest vom Bild her) aber greifen tun die Daten wie von Dir beschrieben.

Bei uns ist es nun ja so das das Land für die Steuerkennung in beiden Fällen DE ist weil sich die Firmen alle in D befinden.

Mal nach einem User-Exit suchen.
Gruss

Andreas

-----------------------------------

JockelT
vor 6 Jahre
Hallo ihr beiden,

bedeutet also wenn meine weitere VkOrg beim Anlegen einem anderen Land zugeordnet wurde kann man die Steuerklassifikation unterschiedlich halten.

Sind die VkOrgs (zb.) 0100 & 0200 beide dem Land DE zugeordnet kann ich keine unterschiedliche Steuerklassifikation pflegen?

Hier wird es Sinn machen das ganze über die Kontierungsgruppen zu steuern?

Grüße

Thomas

SanduhrAnzeigeProgramm
vor 6 Jahre
Zitat von: JockelT 

...

bedeutet also wenn meine weitere VkOrg beim Anlegen einem anderen Land zugeordnet wurde kann man die Steuerklassifikation unterschiedlich halten.

Sind die VkOrgs (zb.) 0100 & 0200 beide dem Land DE zugeordnet kann ich keine unterschiedliche Steuerklassifikation pflegen?

Hier wird es Sinn machen das ganze über die Kontierungsgruppen zu steuern?

Wenn es bei dir um das selbe Thema geht (Kunde ist in einem VKorg. verbundenes Unternehmen und im anderen nicht) , dann vertrete ich zu dem Thema ein andere Meinung als meine Vorredner.

Entweder ist ein Unternehmen verbunden oder nicht (im Sinne Debitor).

Dann sollte man das als 2 Debitoren anlegen.

Normalerweise sind verbundene Unternehmen ja auch als spezifische Kunden mit spezieller Kontengruppe angelegt.

Wenn du das nichts desto trotz mit einem Debitor lösen möchtest, dann wäre die Kontierungsgruppe in der Tat eine Möglichkeit da man hier normaler Weise zwischen verbundenen und nicht verbundenen unterscheidet und müsste dann halt die Zugriffsfolge zur MWST erweitern.


*... who can do field replacements in the debugger can do anything in the system

*so this check can not stop (him) anyway.