aus einer im Hintergrund erzeugten internen Tabelle mit den Spalten A, B, C, D, E ... und mehreren Zeilen soll automatisch ein patientenabhängiges Dokument erzeugt werden, welches in der NDOC und auch im angebundenen Dokumentarchiv (hier als PDF) gespeichert werden soll. Der Dokumenttyp soll meinetwegen DTY heißen. Es gibt den FB ISH_N2_MEDICAL_DOCUMENT, aber hier kann ich keinen ITAB-Inhalt an das zu erstellende Dokument übergeben, bestenfalls Strukturen der NDOC oder DRAW. Ziel ist es, die ITAB im Dokument als stinknormale Tabelle auszugeben. Sie enthält statistische Werte zum Patienten, also nix Besonderes. Ideen?
Der ISH_N2_MEDICAL_DOCUMENT ist schon korrekt. Sonst geht auch noch ISH_N2_DOCUMENT_BASE.
Damit legst du die Dokumentverwaltungsdaten an. Wenn das geklappt hat, musst du noch mit der CL_ISHMED_PMD_SERVICES eine Instanz auf die Dokumentabellen erzeugen und deine Daten aus der ITAB damit eintragen.
Für die Übergabe an das Archiv müsstest du dir selber was bauen, weil ISHMED hier nur vorsieht, dass es sich entweder um ein PMD oder ein Archiv-Dokument handelt. Beides kombiniert ist im Standard nicht vorgesehen.
Am ehesten mit ARCHIVOBJECT_CREATE_TABLE das PDF ins Archiv stellen und die zurückgelieferte GUID in einem eigenen Dokumentationselement im PMD speichern.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
Transaktion N2T7...
Aber alles weitere würde den Rahmen hier sprengen. Sorry.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
Wir wollen PDF. PMD machen wir mal nicht. Der entsprechende DOKTYP und die DOKART sind vorhanden, doch woher weiß ISH_N2_MEDICAL_DOCUMENT, welche Dok.nr. hier angelegt werden muss, da ich ja das Ganze "DARK" übergebe im Modus und zu diesem Zeitpunkt noch keine Dok.nr. habe? Ich führe das als Job aus innerhalb einer Schleife. Die Nummernkreistabelle der NDOC abfragen nach der nächsten freien Nummer ist nicht performant und birgt Gefahren der Dopplung, wenn zum gleichen Zeitpunkt ein anderes Dokument angelegt wird von irgendjemanden ...
Du übergibst, grob gesagt, alles was du hast AUßER der Doknummer, das Ding erledigt den Rest und liefert dir am Ende die Doknummer zurück.
Morgen könnte ich dann noch auf unserem System nachschauen, was du als TCODE usw. benötigst.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
Okay, die Datenbeschaffung mit DOKNR, DOKVR, DOKTL usw. übernimmt der FuB ISH_N2_DOCUMENT_BASE. Der TCODE sollte N201 lauten, der Modus DRK für Dark. Das Anlegen (CREATE bzw. INS) des Dokumentes – noch ganz ohne ITAB-Inhalt – schmiert aber mit Raise NO_INSERT ab, warum, weiß ich noch nicht, das muss ich debuggen.
Man kommt hier vom Hundertsten ins Tausendste. Das neue Dokument ist vom Typ PDF, Bezugsebene Patient (P), d. h. völlig Fallnummer- und bewegungsunabhängig, technisches Dokument (T). Beim Versuch, es anzulegen, kommt die Fehlermeldung "Archiv-Infostruktur SAP_ISHMED_DOC0 ist nicht aktiviert", Meldungsnummer N1ADK008. Generiert wird diese Meldung aus LN2DOC_APIF01, Form GET_ADMINDATA, FuB ISHMED_ADK_DOCUMENT_READ Zeile 1375 heraus. Der gelangt dorthin, weil zu diesem Zeitpunkt die DOKNR noch initial ist. Die Patientennummer, DOKAR, DTID sind freilich schon versorgt zu diesem Zeitpunkt. Das SAP-eigene Archiv (ADK bzw. SARJ), worauf sich die Fehlermeldung zurückführen lässt, haben wir in keinem System aktiv, als dass es hier interessieren würde. Grübel ...
Okay, hier eine andere Lösung die wir auch im System haben:
1) In der N2T7 einen Dokumenttyp anlegen, der als Anwendung PDF hat.
2) In den Details die korrekte KPro Ablagekategorie einstellen.
3) Mit der API cl_ishmed_doc_api das Dokument erzeugen.
4) Mit der API cl_ishmed_doc_content die Dokumentdaten übertragen.
Wenn ihr MCI auf eurem System habt, kannst du dir in der Klasse CL_ISHMED_MCI_PDF_CONNECTOR anschauen wie die Punkte 3 und 4 ablaufen sollten.
ODER
Du kannst gleich mit MCI einen entsprechenden Prozess designen.
Für die Konfiguration der KPro Ablage bitte die entsprechenden SAP Dokumentationen bemühen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
danke für den Tipp. Beim Verbuchen in Schritt 3 mit der Methode CREATE in die NDOC scheitert das Ganze. Der Aufruf PERFORM ndoc_db_update ON COMMIT wird übergangen, im Verbuchungsdebugging wird die FORM nicht durchlaufen; es wird kein Eintrag in der NDOC erzeugt. Woran liegt das? In der Struktur RN2DOCADMIN_CREATE habe ich keine Möglichkeit, den Mandanten mitzugeben. Der ist leer und vermutlich das Problem, weil Schlüsselfeld in der NDOC. Siehe Anhang. Die DOKNR usw. sind zu diesem Zeitpunkt versorgt.
VG + VD
sapdepp
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
habt ihr den Dokumentinhalt (z. B. eine ITAB) mit der Constructor-Methode der CL_ISHMED_DOC_CONTENT direkt erzeugt? Oder habt ihr die Daten über die SET_CONTENT der CL_ISHMED_DOC_API, wo ihr die CL_ISHMED_DOC_CONTENT als Referenz übergebt, ins Dokument geknüppelt? Dazu müsstet ihr aber auch die CL_ISHMED_DOC_CONTENT referenziert haben.
Ich glaub zweiteres.
Im Grunde hab ich nur die "Vorlage" aus CL_ISHMED_MCI_PDF_CONNECTOR um einige, weitere Funktionen angereichert, aber im Kern ist der Aufbau ident.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.