(gelöst) Änderungen an der Rechnungs.tpl werden nicht konsistent übernommen

[BoKr]

Gelöst: Es lag an den Kundengruppen, die angelegt waren im BO/Kunden mit unterschiedlichen Einstellungen zur Preisanzeige. Es lagen Gruppen vor, für die netto Preise galten und welche mit brutto Preisen. Die Ursache war in unserem Fall, dass das update von 149 auf 1541 die neuen Gruppen anlegte und ich nicht geprüft hatte, welche Preisanzeige diese haben.

 

beste Grüße

Boris

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

 

Hallo

 

unter ps1541 habe ich Änderungen an der invoice.tpl, die im Ordner /pdf im Templateordner liegt, vorgenommen.

 

Merkwürdigerweise werden nicht alle Änderungen konsistent übernommen!

 

Das sieht so aus, dass ich während meiner Tests an der invoice.tpl immer wieder verschiedene Rechnungen aus BO/BEstellungen aufgerufen habe, um meine Fortschritte zu sehen bzw. die Änderungen zu überprüfen.

 

 

Leider habe ich es dieses mal am Liveshop machen müssen. Was ich aber nicht als Problem angesehen habe, da ich ja an der Dublette im oben genannten Ordner gearbeitet habe und meine Änderungen minimal waren (auskommentieren von Spalten, da aus irgend einem Grunde der Preis netto wie brutto angezeigt wurde, ich es aber so nicht machen darf als Kleinunternehmer. Ich zeige die Preise nur als Endpreise (nenne sie aber nicht Brutto, sondern verweise auf die Erklärung,was ein Endpreis nach §19 Ust.G. ist)).

 

Ich habe nun /cache/smarty & /cache/compile auf dem Server gelöscht. Cache Optimierungen unter Leistung aus und Kompilierung auf an....

 

Dennoch werden mit im BO unter Bestellungen, wenn ich eine Rechnung aufrufe, Rechnungen 'teilweise' angezeigt, die darauf schließen lassen, dass zur Generierung gecachte Dateien genutzt werden.

 

Es werden PDF Rechungen generiert, die meine Änderungen an der invoice.tpl etc. nicht respektieren. Das gilt nicht für alle, es gibt auch welche, die so aussehen, wie sie es sollen bzw. sollten.

 

Frage:

 

Was muss ich tun, damit die Änderungen an der tpl für alle Rechungen gelten? Kann ja nicht sein, dass Kunden eine total zersprungene und falsche Rechung zugeschickt bekommen

 

 

PS:

Es gab den Hinweis im Forum, es könne an den Servereinstellungen des Hosters liegen. Keine Ahnung, was damit gemweint sein soll, da alles andere bisher gut läuft seit einem Jahr. Wahrscheinlich basier der Hinweis auf der Vermutung, dass mein Hoster Hetzner bei meinem SharedHosting Paket Teile zwischenspeichert, die zur Generierung der PDF herangezogen werden, außerhalb meiner Kontrolle durch Prestashop und dem Löschen der Cache Ordner in meinem Prestashop`?!

Edited July 30, 2013 by B.Köring (see edit history)

[eleazar]

Entweder du änderst die Vorlagen im Standard-Verzeichnis /pdf oder du legst ein gleichnamiges in /overrides an. Im Templateverzeichnis scheinen nur die im Unterverzeichnis mails abgelegten Vorlagen korrekt zu überschreiben. Ein Verzeichnis pdf hat hier eigentlich nichts zu suchen.

Arbeitest du eventuell mit einer deutschen Anpassung, die ebenfalls ein Rechnungsformular mitbringt?

[BoKr]

Ich komme nicht weiter, aber um vorweg die Fragen zu beantworten, nein ich habe keinerlei solch Modul installiert, so weit ich es weiß.

 

Für Schnelleser:

Das Problem ist im Zusammenhang mit der Steuerberechnung zu sehen. Mal denkt der Shop, Steuer sei an, mal aus. Also: {if $tax_excluded_display} ) ...

Nur warum?

 

EDIT: HAB ES. Seit dem upgrade von 1.49 auf 1.541 wurde eine neue Gruppe Kunden eingeführt. Diese hat als Voreinstellung eine andere als die Gruppen (unsere Einstellung wahrscheinlich, ich weiß es nicht mehr) zuvor zur Preisanzeige:

zuvor: netto Preise

1541: brutto Preise

Nun kann ich nur hoffen, dass ich nicht in weiter Probleme laufe, weil ich vielleicht mal etwas geändert habe, damit alles Kleinunternehmerkonform aussieht (ja, ich bin kein Coder, oder Codeleser, da ich ja im Lernprozess bin und mich mit alle dem erst seit ein paar Monaten auseinandersetze:).

 

------------------------------------ alte Frage / Problem ----------------------------------------------

 

Es scheint egal zu sein, ob ich Änderungen im Ordner

/root/pdf

/root/override/pdf

/root/...mein template/pdf

mache.

 

Ich habe aber nun festgestellt, dass es was anderes ist als ein CachingProblem!

 

 

Es liebt bedingt an der invoice.tpl (und meinen Änderungen) sowie an irgend etwas, was wahrscheinlich mit dem Artikel zu tun hat, der auf die Rechnung kommt.

 

Der Zusammenhang ist bei den 'Steuern' zu suchen.

 

In unserem Shop sind diese deaktiviert.

Wir sind Kleinunternehmer und mussten uns bisher anders und selbständig helfen beim Prestashop. Andere Systeme sind da weiter, aber tut nun nichts zur Sache.

 

Ich zeige mal, was ich meine. Es sind zwei Rechnungen, die an einem Tage geschrieben wurden:

 

So will ich es nicht:

 

Der Artikel sieht so aus im BO:

 

 

 

DIE 2. Rechung:

 

So sollte es sein, nur dass natürlich der Tabellenkopf 100% Weiter haben sollte. Das ist auch kein Problem, es nur zur Verdeutlichung, dass diese Rechnung aus der selben invoice.tpl generiert wird. Nur hier wird halt die Zeile zum BruttoPreis nicht berücksichtigt.

!Wie gesagt, selbe tpl wie oben. -> also nichts auskommentiert. Nur der Prestashop scheint beim 1. Artikel der 1. Rechnung andere Steuern zu sehen, als bei der 2. Geschichte!

 

Wo aber die stehen sollen bzw. herkommen, da bin ich überfragt

 

 

 

 

 

 

 

 

 

 

 

 

Nach der Thumbshow hier meine Änderungen der Rechnungsvorlage von Eleazar aus diesem Forum:

 

<!-- PRODUCTS TAB 100%-->
<table style="width: 100%; font-size: 9pt;">   <!-- 12 44 11 10 10 13 =  100		  -->
 <tr style="line-height:4px;">
 <td style="text-align: left; background-color: #CCC; color: #000; padding-left: 10px; font-weight: bold; width: 12%">{l s='Reference' pdf='true'}</td>
 <td style="text-align: left; background-color: #CCC; color: #000; padding-left: 10px; font-weight: bold; width: 30%">{l s='Artikel' pdf='true'}</td>
 <!-- unit price tax excluded is mandatory -->
 {if !$tax_excluded_display}
  <td style="background-color: #CCC; color: #000; text-align: right; font-weight: bold; width: 11%">{l s='Einzelpreis' pdf='true'}<!--<br />{l s='netto' pdf='true'} --></td>
 {/if}
 <td style="background-color: #CCC; color: #000; text-align: right; font-weight: bold; width: 11%">
  {l s='Einzelpreis' pdf='true'}<br />
  {if $tax_excluded_display}
<!-- {l s='netto' pdf='true'} -->
  {else}
 {l s='brutto' pdf='true'}
  {/if}
 </td>

 <td style="background-color: #CCC; color: #000; text-align: right; font-weight: bold; width: 10%">{l s='Discount' pdf='true'}</td>
 <td style="background-color: #CCC; color: #000; text-align: center; font-weight: bold; width: 10%">{l s='Menge' pdf='true'}</td>
<!-- ITO Steuer *-->
 <td style="background-color: #CCC; color: #000; text-align: center; font-weight: bold; width: 16%">{l s='Total' pdf='true'}<br />
 {if $tax_excluded_display}
{l s='(Endpreis)*' pdf='true'}
  {else}
{l s='(Tax Incl.)' pdf='true'}
  {/if}
 </td>
</tr>

<!-- PRODUCTS -->

 

Hier ist gut erkennbar, dass es mit der Tax excl/incl Rechung zu tun hat!

 

Denn bei der 2. Rechnung (Ziel) ist der Gesamtpreis mit dem Untertitel angezeigt wie an Ende des Codesschnippsels zu sehen: {l s='(Endpreis)*' pdf='true'} (also bei {if $tax_excluded_display} )

Bei der 1. Rechnung wird aber der 'Else-Fall' {l s='(Tax Incl.)' pdf='true'} ausgewertet?!

 

Also, wie kann das sein, wo liegt der Fehler?

Wahrscheinlich in der Art & Weise, wie unser Produkt konfiguriert ist.

Zumindest hoffe ich das, und ich muss auch fragen, wie ich sicher stellen kann, dass es nur bei dem einen der Fall ist. Sonst riskiere ich, dass immer wieder falsche Rechnungen geschrieben werden.

 

Ein Wahnsinn

beste Grüße

Edited July 30, 2013 by B.Köring (see edit history)

[eleazar]

Ist dir gar nicht aufgefallen, Boris, dass es sich hier um zwei verschiedene Rechnungsformulare handelt? Eines hast du ja sogar selbst bemerkt: die Tabellenbreite stimmt nicht. Vielleicht schaust du dir auch mal die Spalte "Gesamtpreis" in den beiden Rechnungen genauer an. Die sind doch nicht identisch!

Die erste dürfte wahrscheinlich im Hauptverzeichnis /pdf zu finden sein. Was deine Auskommentierungen im Quelltext der zweiten, den du hier zitierst, bewirken sollen, entzieht sich leider meiner Kenntnis.

Und noch ein Tipp: Wenn sich die addierten Spaltenbreiten nicht auf 100% belaufen, wird die Gesamtbreite natürlich entsprechend gekürzt. ;-)

Edited July 30, 2013 by eleazar (see edit history)

[eleazar]

Und aus ggb. Anlass noch ein Hinweis auf unsere Forums-Regeln:

 

"Verwende bitte so selten wie möglich Großbuchstaben oder farbige Lettern, um deinem Anliegen Nachdruck zu verleihen."

[BoKr]

Kein Problem für mich, die Hervorhebungen weg zu lassen, aber ich bin der Ansicht, dass sie punktuell eingesetzt für viele hilfreich sind.

• Leider verstehe ich nun nicht, was Du damit meinst, es seien zwei verschiedene Rechnungsformulare?
  
• Das mit den Spaltenrelationen /-breiten hatte ich hoffentlich gar nicht erfragt und ist ja auch simpel. ( http://forge.prestas...owse/PSCFV-1647 )
  
• Die Hervorhebungen habe ich genutzt, um unser Problem zu verdeutlichen. Da bist nun gar nicht drauf eingegangen. Ist nun aber auch nicht mehr nötig,
  
• denn die Probleme ergaben sich aus der Tatsache, dass bei uns im Shop seit dem update auf 1541 neue Gruppen angelegt waren (nun allerdings mit der Einstellung brutto Preise).
  
• Die Änderungen an 'Deiner' Vorlage waren nötig für uns, damit die Vorlage mit den Einstellungen Brutto-/Nettopreise je nach Gruppeneinstellung unter /Kunden (BO) mit deaktivierter Steuer was brauchbares produziert.
  

 

 

Wie ich es nun als nicht Steuerfachmann einschätze sollte es rechtskonform sein. Gedanken muss ich mir noch machen, ob ich die Rabattspalte ausblende bzw. ausblenden darf.

 

Sonst vielen Dank für die Vorlage! Vor allem, wenn man nun nicht so des Französischen oder Englischen mächtig ist und dort sich kundig machen kann

 

 

PS:

R., schau doch mal in die 2. Zeile des Schnippsels. Irgendwie ahnte ich, dass der Hinweis käme:

>> Und noch ein Tipp: Wenn sich die addierten Spaltenbreiten nicht auf 100% belaufen, wird die Gesamtbreite natürlich entsprechend gekürzt. ;-) <<

Edited July 30, 2013 by B.Köring (see edit history)

[eleazar]

Na, dann ist dieser öffentliche Selbstfindungsprozess dann ja bei einer Lösung angelangt ... ;-)