CAO - FAKTURA

Hallo zusammen,

ich weiß, unsere Entwickler werden gleich die Hände über dem Kopf zusammenschlagen, aber was soll's, ich habe es getan:


Zur Erläuterung was ich habe:
CAO-1.4(f) (noch, ggf. gerne K, aber das weiter unten)

einen Online-Shop mit ca. 2000 Art's, die aber von der Struktur her so gar nicht in OScom. oder ähnliche "Fertig-Online-Shops" passen.

Derzeit habe ich für meinen O-Shop schon das erreicht:
Kunden werden DIREKT in der CAO-DB angelegt, Kunden können Lieferadressen anlegen, auswählen, etc. Alles so konform, daß ich nach Useranmeldung die Daten wohl geordnet im CAO sehe und bearbeiten kann. Funzt prima.

Weiterhin bin ich auch schon soweit, daß die Bestellungen, die abgeschickt werden, sowohl in JOURNAL, als auch in JOURNAL_POS liegen, inkl. Nummernkreis-Update in der REGISTRY.

Nun liegt hier meines erachtens das erste Probleme:
Die Zugriffssteuerung der Registry, wie macht Ihr das im CAO selbst, einfach Nummer holen und dann sofort updaten, also ohne LOCK TABLE, nach dem Motto: das geht so schnell, da passiert nichts, oder geht Ihr da auf "Nummer sicher"?

Das gilt sowohl für die vorläufigen EDI-Nr'n, als auch für die Kundennummern - die erzeuge ich auch erst so wie in CAO üblich, sobald eine Bestellung(Rechnung) erstellt wird. D.h. der Kunde kann sich "anlegen", gefühlte 3 Stunden warten und dann erst "bestellen" klicken, erst dann erhält er eine Kundennummer (KUNNUM, DEB_NUM).

Die 2. Sache sind die "Magic-Numbers", als da wären:
TERM_ID, MA_ID, ASP_ID,ATRNUM, FOLGENR und POS_TA_ID in JOURNAL

, sowie
QUELLE_SRC, TOP_POS_ID, ATRNUM*, ALTTEIL_PROZ,ALTTEIL_STCODE, ALTTEIL_FLAG und APOS_FLAG in JOURNAL_POS

(* ist das ein Schreibfehler und sollte eigentlich ARTNUM heißen?)

Zur weiteren Info meiner derzeitigen "Eingabe der Artikel":
Zuerst wird ein JOURNAL-Eintrag generiert, dann werden mit der erhaltenen REC_ID, KUNNUM, etc. in der JOURNAL_POS die Positionen eingepflegt (umfangreiches SQL-Statement mit SELECT aus ARTIKEL, JOURNAL, MENGENEINHEITEN). Und zwar genau so weit, wie man es "zu Fuß" über CAO direkt auch macht - die abschließende Speicherung/Buchung muß in CAO manuell geschehen.

Ich habe es derzeit so programmiert, das ich die "unveränderlichen" Werte bei manuellen Buchungen in die "automatischen" Übernehme, also Bsp.: TERM_ID = 9 (soweit ich das entschlüsselt habe steht die 9 für Rechnung), MA_ID bekommt den Wert 4, weil CAO das auch so macht.
Die Werte für QUELLE kenne ich zwar nicht alle, aber soweit ich es herausgefunden habe, steht 3 für RECHUNG und 13 für RECHNUNG IN BEARBEITUNG.

Hoffe, soweit so richtig.

Da ich im Moment nur mit "einfachen" Artikeln arbeite ist das alles kein Problem, nur würde ich wissen wollen, wofür MA_ID steht (vielleicht MATERIAL-ID?).
Später kommen ggf. Stücklisten-Artikel dazu - OK, kann ich auch ausprobieren


----- Ende erster Teil -----------
2. teil: CAO - Frei oder CAO - Kauf:
eine zweite Frage habe ich da noch: die Scriptfunktionen in der Kaufversion: sind diese in der Lage beim Ausdruck das Formular zu wählen, auf das gedruckt werden soll, oder aber bin ich damit in der Lage ein "Superformular" zu gestalten, bei dem dann je nach Datenlage einzelne Bereiche einfach nicht gedruckt werden?

Bsp: wir verkaufen sowohl über unseren O-Shop, als auch über EBay - O-Shop wie oben beschrieben, EBay manuelle Eingabe.
Auf der Rechnung eines O-Shop-Kunden steht nichts weiter besonderes drauf, bei den manuell gepflegten EBay-Kunden soll auf der Rechnung die EBay-Nr. mit Barcode kommen - derzeit wähle ich manuell die entspr. Formulare aus, was im Prinzip nicht schlimm ist und gut funzt, aber manchmal achtet man halt nicht drauf und hat dann das falsche Form. gedruckt.

Entsprechendes gilt für BRUTTO- bzw. NETTO-Rechnungen. Da je nach Kunde entschieden wird, ob er als Brutto-, oder Netto-Kunde läuft (Privat-/Firmenkunden) muß ich jedesmal das entsprechnde Formular auswählen.

Ich hoffe, Ihr wisst was ich meine, und wenn die K-Version das kann, dann bin ich sofort dabei. Davon abgesehen, daß ich sowieso mit der K-Version liebäugle, daß geht aber erst, wenn der O-Shop richtig läuft.

Hallo,

Weiterhin bin ich auch schon soweit, daß die Bestellungen, die abgeschickt werden, sowohl in JOURNAL, als auch in JOURNAL_POS liegen, inkl. Nummernkreis-Update in der REGISTRY.

Von Manipulationen an der DB kann ich nur dringend abraten, das wird ab kommender Version von CAO nicht mehr unterstützt!

Ich kann dir nur ans Herz legen, den offiziellen Weg per XML / Shoptransfer zu gehen, alles andere wird früher oder später Probleme machen.

CAO-Support hat geschrieben:Von Manipulationen an der DB kann ich nur dringend abraten, das wird ab kommender Version von CAO nicht mehr unterstützt!

Ich kann dir nur ans Herz legen, den offiziellen Weg per XML / Shoptransfer zu gehen, alles andere wird früher oder später Probleme machen.

OK, ich werde es mir überlegen - obwohl ich mit der 1.4 ganz zufrieden bin - tut (fast) alles, was ich möchte .

zum "ab kommender Version von CAO nicht mehr unterstützt":

Ich bin nämlich auch gerade dabei, einen neuen Server aufzusetzen - ich versuche jetzt gerade einen MySQL-4.x aufzusetzen - ist dass ab der nächsten Version auch Geschichte? Weil es ist schwer, bzw. wahrscheinlich unmöglich, jetzt noch einern MySQL-4.x zu installieren, weil zuviele Pakete nicht mehr verfügbar sind, security-lücken haben, oder sonst wie gesperrt sind.

CAO-Support hat geschrieben:Hallo,
Ich kann dir nur ans Herz legen, den offiziellen Weg per XML / Shoptransfer zu gehen, alles andere wird früher oder später Probleme machen.

Gut und schön - ich habe mir eben die Finger wundgetippt um ein gültiges XML-File zu finden. Das einzige, dass ich gefunden habe ist von Jan mit dem Datum: Mittwoch, 2. Juli 2003

Das ist das erste kl. Problem - da ich ja bereits erwähnt habe, daß ich xt:com, os-com, etc. Produkte NICHT benutze und somit die vorhandenen Scripte nicht verwenden kann,
werde ich mich darauf einlassen, aus meinen DB's ein eigenes für den Import nach CAO gültiges XML-File zu erzeugen - ist ja auch nicht das Problem (programmiertechnisch) -
nur:
1. ist die Struktur, die Jan im Juli 2003 vorgestellt hat noch aktuell?
2. verstehe ich es richtig, daß ich mein Script dann einfach unter "Datei -> Einstellungen (Shop)" eintragen muß und die Rückgabe dieses Scripts ist dann die XML-Datei?


II. Es steht noch meine Frage bzgl. der Automatisierung der Formularauswahl im Raum, ein kurzer Zweizeiler dazu wäre schön.

Danke, Gruss, FoB

Hallo,

zu 1.
Die XML-Strunktur ist noch aktuell und arbeitet mit der 1.4.x Version von CAO zusammen
zu 2.
Ja, du mußt die URL zum Script in den Shop-Einstellungen eintragen.

Zu den Formularen:
Mit der Kaufversion hast du die Möglichkeit in den Formularen Berechnungen einzubauen. Damit lassen sich Bedingungen erstellen die bestimmte Felder dann ein- oder ausblenden usw. Sieh dir im Wiki mal den Reportbuilder an, da ist einiges erklärt.