Posts by martinf

Ja, genauso hatte ich unsere Buchhaltung verstanden. Mit Mahnwesenfestsetzen soll die Rechnung in der aktuellen Mahnstufe bleiben.

Wir haben noch eine andere Frage. Wäre es möglich auch Mahnstufen festzusetzen? D.h. Rechnungen sollen schon im Mahnwesen drin bleiben, aber werden nicht automatisch in die nächste Stufe verschoben falls man z.B. Spezial-Kunden hat, denen man im Fall der Fälle etwas mehr Zeit geben will?

Oder müsste man die komplett im Mahnwesen sperren und sich da einen Report zusammenstellen?

Ah, danke. Komisch, dass die Suche im Forum das nicht gefunden hat.

Die Tage der Mahnstufe sind dann kumulativ und basieren immer auf dem Rechnungsdatum?

Hallo, wir versuchen gerade das Mahnwesen zum Laufen zu bringen, sind aber nicht erfolgreich. Ich vermute, wir müssen hier erst Mahnstufen konfigurieren? In den globalen Einstellungen gibt es eine Seite mit Mahnwesen, dort ist aber alles leer. Vermutlich sind das die Mahnstufen? Wie konfiguriert man die?

Im Xentral war es so:

Danke für die Info.

Wir versuchen das jetzt über die Verbindlichkeiten zu lösen. Bei jedem Vorgang eine Verbindlichkeit anlegen, dort noch eine neue Zahlweise "bar" hinzufügen und dann einen Report/SQL query ziehen.

Hallo, gibt es Pläne, ein Kassenbuch zu entwickeln oder hat sich da jemand schonmal dran versucht? Im Xentral gab es das mal, vermutlich aber nicht in der Open-Source-Version, da ich nur begrenzt Code sehe.

Hmm, der Commit ist noch nicht im master drin. Alex musst du noch den master nach github pushen?

Du musst bei Art noch Preisgruppe auswählen, einmal speichern und dann wieder in die Gruppe reingehen. Dann sind die Rabatt-Felder da.

Da fehlt scheinbar ein Refresh der Seite, wenn man die Art ändert.

Hat sich bei euch jemand mal so eine Art Alternativ- und Exklusiv-Artikel gewünscht?

Bsp. Exklusiv-Artikel

Eine Basis-Stückliste eines Geräts enthält z.B. RAM 8 GB, der Kunde will aber als Option 64GB haben - momentan bucht unsere Auftragsabwicklung einfach die 64GB in den Auftrag dazu, ohne die 8GB zu löschen, weil sie technisch nicht das Verständnis hat, das dass nicht geht. Kann man hier einen Hinweis erhalten, das Artikel 8GB und 64GB nicht zusammen gehen?

Bsp. Alternativ-Artikel

Es gibt SSDs von mehreren Herstellern mit sonst gleichen/ähnlichen Eigenschaften. Im Einkauf beschaffen wir immer den, der grad am günstigsten ist. Kann man beim Auftrag-Anlegen irgendwie sehen, dass wenn SSD A nicht (ausreichend) vorhanden ist, dann einfach SSD B zu nehmen wäre?

Danke, hat funktioniert

Wie funktioniert eigentlich die Lupe im Seriennummernmodule bei "Seriennummer wählen"?

Da kommt ja ein Dialog mit einer SN-Liste bei onclick(). Aber wo steht der Javascript-Code dafür und mit welcher Magie wird diese Liste befüllt?

Ich hab da mal einen Pull Request dazu gemacht, wir arbeiten auch viel mit Grundrabatten über Preisgruppen

Wenn man im Wareneingang auf Neu und dann einen Lieferanten klickt, legt es sofort einen Eintrag in der Tabelle paketannahme an, auch wenn man dann im Folgefenster nicht auf Speichern oder Abschließen klickt. Das Verhalten war auch in Xentral so, nur hat man es da nie mitbekommen, weil es nicht die coole Paketannahme-Liste gab. Nach der Datenmigration von Xentral haben wir jetzt da hunderte leere Pakete, die man auch nicht löschen kann (vielleicht auch nicht löschen will weil die vielleicht von paketdistribution referenziert werden).

Wie sieht hier der Workflow aus? Würdet man auch ein versehentlich angelegtes Paket dann irgendwann später noch mit Positionen befüllen? Kommt sowas vor? Oder braucht es doch einen Filter und/oder Lösch-Knopf?

Der Query selber im Workbench dauert nur ein paar ms.

Ich probiere gerade das in das $more_data1 reinzufummeln, bekomme aber bislang nur SQL-Fehler. Ich sehe auch nicht wirklich, wo $sql oder $where richtig benutzt werden.

Hab es grad mal gemessen. Wenn der Filter "Anhang fehlt" nicht gesetzt ist, dann sind es 20sek, ist der Filter gesetzt dann 14 sek.

Wenn ich den Join mal rausnehme sind es nur 0,2 sek.

Bei Xentral hatten wir das Problem auch und durften dann halt niemals den Anhang-fehlt-Filter setzen.

Die Verbindlichkeiten-Seite ist bei uns sehr langsam. Vermutlich liegt es an dem SQL-Query in verbindlichkeit.php:94 mit dem LEFT JOIN über die Tabelle datei_stichwoerter und datei (hat bei uns ca 25k bzw, 10k Einträge). Verbindlichkeiten selber haben wir ca 8600.

Wenn ich den Query in Mysql Workbench separat ausführe, dann braucht der 21 Sek.

Was genau macht denn der Query? Ich blicke da durch den PHP-Code nicht wirklich durch, ob man da was beschleunigen kann?

Ja, das hört sich gut an

Von Xentral sind wir gewohnt, dass er die dann einfach automatisch erzeugt. (Dann musste man allerdings bei S/N behafteten Artikeln mit Lagerbestand aufpassen, dass man keine falsche S/N reinkopiert hatte, die hat er dann auch neu angelegt, obwohl man eigentlich die im Lager wollte).

Evtl. kann man das so machen, dass für Nicht-Lagerartikel die Nummern unten in der Textbox angelegt werden und nur für Lagerartikel der Check, ob die wirklich vorhanden sind?

Ich habe einen Stücklisten-Artikel, der explodiert werden soll. Wenn ich diese Position in einen Auftrag hinzufüge, dann stürzt er ab in class.erpapi.php in AuftragExplodieren(), weil es die Tabelle lieferkette_bestellung nicht gibt. Weder im alten Xentral noch im Schema von OpenXE.

$checklieferkette = $this->app->DB->Select("SELECT id FROM lieferkette_bestellung WHERE belegtyp='auftrag' AND belegid='$auftrag' LIMIT 1");

Kann man das einfach löschen?

Es sind nur die beiden Tabellen seriennummern und seriennummern_beleg_position? Ok, dann kann ich das recht einfach migrieren.

Anderer Punkt: Kann man auch für Nicht-Lagerartikel ad-hoc im Lieferschein eine S/N vergeben? Wir haben z.B. Geräte als Stücklisten definiert, die erst im Lieferschein zusammengebaut werden und dort eine S/N bekommen (das Produktionsmodul von Xentral haben wir nie verstanden). Für diese Geräte verkaufen wir dann später auch noch einen Serviceartikel mit der gleichen S/N.

Kann man das abbilden? Momentan kann ich nur eine vorhandene S/N auswählen.