Merge branch 'master' of vc.linet-services.de:public/lx-office-erp

[kivitendo-erp.git] / SL / DATEV.pm

diff --git a/SL/DATEV.pm b/SL/DATEV.pm
index cd04053..bfb48d0 100644 (file)
--- a/SL/DATEV.pm
+++ b/SL/DATEV.pm
@@ -429,8 +429,7 @@ sub _get_transactions {
       if (   !$ref->{invoice}   # we have a non-invoice booking (=gl)
           &&  $ref->{is_tax}    # that has "is_tax" set
           && !($prev_ref->{is_tax})  # previous line wasn't is_tax
-          &&  (_sign($ref->{amount}) == _sign($prev_ref->{amount})))  # and sign same as previous sign
-          {
+          &&  (_sign($ref->{amount}) == _sign($prev_ref->{amount}))) {  # and sign same as previous sign
         $trans->[$i - 1]->{tax_amount} = $ref->{amount};
       }
     }
@@ -852,6 +851,16 @@ sub kne_buchungsexport {
       $umsatzsumme += $umsatz;
       $kne_file->add_block("+" . $umsatz);
 
+      # Dies ist die einzige Stelle die datevautomatik auswertet. Was soll gesagt werden?
+      # Im Prinzip hat jeder acc_trans Eintrag einen Steuerschlüssel, außer, bei gewissen Fällen
+      # wie: Kreditorenbuchung mit negativen Vorzeichen, SEPA-Export oder Rechnungen die per
+      # Skript angelegt werden.
+      # Also falls ein Steuerschlüssel da ist und NICHT datevautomatik diesen Block hinzufügen.
+      # Oder aber datevautomatik ist WAHR, aber der Steuerschlüssel in der acc_trans weicht
+      # von dem in der Chart ab: Also wahrscheinlich Programmfehler (NULL übergeben, statt
+      # DATEV-Steuerschlüssel) oder der Steuerschlüssel des Kontos weicht WIRKLICH von dem Eintrag in der
+      # acc_trans ab. Gibt es für diesen Fall eine plausiblen Grund?
+      #
       if (   ( $datevautomatik || $taxkey)
           && (!$datevautomatik || ($datevautomatik && ($charttax ne $taxkey)))) {
 #         $kne_file->add_block("\x6C" . (!$datevautomatik ? $taxkey : "4"));