Interface mellem Oracle og sporbarhedssystem · Web vieware marked by a Word Bookmark so that...

IBM Oracle MethodDS.912/ MD.050 FUNCTIONAL DESIGN OF CUSTOMIZATION – REGION SJÆLLAND

RICE number…: IN05Description..: T-Doc Integration

Forfatter: Kristian NørgaardOprettet: 11. november 2011

Sidst opdateret: 23. september 2011 Dokument Ref: xxxx

Version: 10

Godkendelser:Cherry Kuhlman

Tom Rasmussen

DS.912/ MD.050 Functional Design OF Customization –

Historik

Ændringer4

Dato Forfatter Version

Ændringer

11-11-2011

Kristian Nørgaard Draft 1a

Første version

24-08-2011

Kristian Nørgaard 2 Opdateret efter 2 møder med Region Sjælland

05-09-2011

Kristian Nørgaard 3 Opdateret med XML fil mapping

12-09-201123-09-2011

Tom RasmussenTom Rasmussen /Cherry Kuhlman

45

GenereltGenerelt

27-09-2011

Kristian Nørgaard 6 Opdateringer fra Region Sjælland opdateret

28-09-2011

Kristian Nørgaard 7 Gennemgået med Region Sjælland og klar til godkendelse

28-10-2011

Kristian Nørgaard 8 Opdateret efter møde med Region Sjælland og Getinge IT Solutions. Afventer QA fra Getinge IT Solutions

03-11-2011

Kristian Nørgaard 9 Opdateret efter telefonmøde og QA af mappede felter sammen med Getinge IT Solutions

11-11-11 Kristian Nørgaard 10 Updated with input from Region Sjælland. More over all required interfaces has been added eventhough that T-DOC not at current support them. Additional work has to be agreede betwen Region Sjælland and the supplier of T-DOC.

Remember: All changes in this document have to be described in the document

history (new version-number). It has to appear if re-estimate is necessary or not. It has to appear if another functional consultant has reviewed the

business needs in the DS.912/MD.050 (and comments are written in the log)

It has to appear if the customer approves the solution described in this DS.912/MD.050.

Changes after the customers approval has to be written in a appendix- unless the document is send to re-approval

Reviewere

Navn Rolle/Stilling

IL

Fil Reference: document.docx (v. Error: Reference source not found )

…

Doc Ref: xxxx Error: Reference source not found

Historik 1iixxxi6ii


DistributionCopy No.

Name Location

1 PMO Projektbibliotek: Rational Portfolio Manager

2 Projektleder34

Note til ihændehaver:Hvis du modtager en elektronisk kopi af dette dokument og printer det ud, venligst skriv dit navn på forsiden af hensyn til dokumentkontrol.Hvis du modtager en udskrift af dette dokument, venligst skriv dit navn på forsiden af hensyn til dokumentkontrol.


…


Historik 1iiixxxi6iii


Indhold

Historik........................................................................................................ iiBackground / Scope...............................................................................5

1. Synchronization of Item data from Oracle to T-DOC................................8Field Mapping......................................................................................10

2. Synchronization of Product data from T-DOC to Oracle.........................133. Synchronizing customer data from Oracle to T-DOC.............................145. Transfer of stock quantity from the Oracle to T-DOC.............................16

Field Mapping......................................................................................164. Transfer of information request from Oracle to T-Doc...........................18

Field Mapping......................................................................................196. Transfer of information supplied goods from T-DOC to Oracle..............21

Internal Order......................................................................................21Field Mapping......................................................................................21

7. Internal usage of disposable items........................................................22Field Mapping......................................................................................22

8.Internal return of disposable items.........................................................24Field Mapping......................................................................................24

9. Internal realocation...............................................................................26Deliverables.........................................................................................27Acceptance Criteria.............................................................................27RS Obligations.....................................................................................27Test.....................................................................................................28Dependencies......................................................................................28Risks....................................................................................................28To do...................................................................................................29


…


Historik 1ivxxxi6iv


Background / Scope

Formålet med dette interface er at opnå en automatisk proces for håndtering af sterile varer i systemet T-DOC der benyttes i den centrale sterile afdeling på Roskilde sygehus og mellem Oracle e-Business suite logistik (Oracle).

For at kunne udveksle data om rekvisitioner og udleveret varer i både Oracle og T-DOC er det nødvendigt at begge systemer har kendskab til de samme varer og egenproduceret varer (herefter kaldet produkter). Sådan at en vare i Oracle der også anvendes i T-DOC har samme nummer i T-DOC. Alle varestamdata oprettes altid i Oracle først og overføres efterfølgende automatisk til T-DOC. Alle produktdata oprettes altid i T-DOC først og overføres efterfølgende automatisk til Oracle.

I processen omkring produktionen af sterille artikler er der 4 niveauer, hvor kun 2 niveauer udveksles mellem Oracle og T-DOC.

Fabriks-sterile Varer

CaseCart

Produkt

Samle-vare

Engangs-sterile varer

Flergangs-varer

Niveau 1

Niveau 2

Niveau 3

Niveau 4

Case Cart : KUN i T-dok Niveau 1Operations-specifikt sterilprodukt til den enkelte operation. Beskrivelse og styring af dette niveau er udelukkende håndteret indenfor T-DOC. Skal kun bestilles i T-dok, men skal kunne prissættes i Oracle via udlevering af varer i niveau 3 eller 4.

Produkt : Med interface Niveau 2Steril produkt, som styres og vedligeholdes og kan bestilles i T-DOC. Varenummer for dette niveau overføres mellem T-DOC og Oracle sådan at det også kan bestilles i Oracle. Det lagerføres ikke i Oracle, men anvendes til at kunne lave bestilling via e-indkøb eller på kanban . Produktet afregnes ikke (pt) dvs. nul-værdi overfor den forbrugende afdeling.

Samle vare : Kun i T-dok Niveau 3Rent T-DOC niveau, som ikke anvendes i Oracle.

12-05-23 16:50 document.docx Side 5



Flergangsvarer : Med interface Niveau 4

Disse varer oprettes og styres i Oracle, som alle varer data der udveksles mellem Oracle og T-DOC. Varenummer, beskrivelse osv. overføres automatisk til T-DOC. Hvilke data, der helt specifkt skal overføres mellem T-DOC og Oracle, vil blive beskrevet i detailjer senere i dette dokument. Efter varemodtagelse lagerføres og styres de kun i T-DOC. Ved varemodtagelse i Oracle indgår de direkte som udgift på sterilcentralen eller forbrugende afdeling og lagerføres derfor ikke.

Engangsvarer (både lagerstyret sterile engangsvarer og ikke lagerstyret usterile depotvarer) : Med interface Niveau 4.

Disse varer oprettes og styres i Oracle. Varenummer, beskrivelse osv. overføres automatisk til T-DOC. Hvilke data der helt specifkt skal overføres mellem T-DOC og Oracle vil blive beskrevet i detailjer senere i dette dokument. Efter varemodtagelse lagerføres og styres nogle af disse varer både i Oracle og T-DOC. Derfor skal lagerbeholdninger for disse varer holdes overens mellem T-DOC og Oracle. Andre engangsvarer lagerstyres ikke men indgår direkte i sterilafdelingens forbrug ved modtagelse. Disse varer bliver typisk bestilt via kanban brikker af sterilafdelingen og kan endvidere leveres usteril fra depotet.

Udveksling af data mellem T-Doc og Oracle foregår vha. xml-filer placeret i bestemte mapper. Én mappe hvor Oracle placerer de data, der skal overføres fra Oracle til T-DOC, og en anden mappe hvor filer der skal overføres fra T-Doc til Oracle placeres. På samme måde som data udveksles mellem ILS og T-DOC.

Intergrationen mellem Oracle og T-DOC vil skulle håndterer 9 områder mellem de to systemer og de vil blive beskrevet i de enkelte kapitler i dokumentet. De 9 områder er følgende og vil blive beskrevet i detaljer i enkelte afsnit:

1. Integration af vare der oprettes i Oracle til T-DOC, som anvendes i steril produktionen. Det omhandler både engangs- og flergangsvarer, som beskrevet ovenfor stående.

(Se afsnit ”1. Synchronization of Item data from Oracle to T-DOC”) 2. Integration af produkt der oprettes i T-DOC til Oracle, som

anvendes i sterilproduktionen. (Se afsnit ”2. Synchronization of Product data from T-DOC to Oracle”) 3. Integrationsfil af kunde/rekvirent oplysninger data fra Oracle til T-

DOC som fx ved ændringer af kunde i indkøbssystemet.(Se afsnit ”3. Synchronizing customer data from Oracle to T-DOC”)4. Overførsel bestillingsdata fra Oracle til T-DOC, sådan at

bestillingen kan behandles af personale i Steril centralen.(Se afsnit ”4. Transfer of information request from Oracle to T-Doc)5. Overførsel indkøbsordre modtagelse fra Oracle til T-DOC, på varer

der lagerføres i både Oracle og T-DOC. Dvs lagerstyring antal/mængder.

(Se afsnit ”5. Transfer of stock quantity from the Oracle to T-DOC”)6. Leveret mængde ud af T-DOC til bestillinger oprettet i Oracle.

Overførsel af information omkring den afsendte mængde mod bestilling i T-DOC til Oracle. Sådan at bestilling fra punkt 4 bliver lukket og fremgår leveret i begge systemer. Det skal være plukkeseddels data fra Oracle der overføres til T-DOC, da det skal være Oracle der angiver hvilket lot/batch som der skal plukkes




(Se afsnit ”6. Transfer of information supplied goods from T-DOC to Oracle7. Overførsel af data omkring internt forbrugt mængde af

engangsvarer i T-DOC til Oracle. Ved produktion af Case cart eller levering til operationsafdeling af engangsvarer vil der være et forbug af engangsvarer internt i T-DOC. Dette forbrug skal overføres til Oracle, hvor lagerniveauet styres parallelt med T-DOC for disse varer. For at tilknytte engangsprodukter til den givne operation (styring) og kun i de tilfælde hvor Case cart ikke indeholder nok varer og der plukkes på operationsafdelingen.

(Se afsnit ”7. Internal usage of disposable items)8. Overførsel af data omkring intern retur mængde af engangsvarer i

T-DOC til Oracle. Ved retunering af Case cart eller anden returnering af engangsvarer vil der komme en fil med vare, mængde og retur sted fra T-DOC (internkunde). Varen vil blive retuneret til den nugældende lager gennemsnitsværdi, som kan være forksellig fra værdien på udleveringstidspunktet. Gælder kun for Case cart og engangsvare fra COP/Anæstesi som kender procedurerne for sterilevare-håndtering, hvorfor vare kan tages retur på sterilcentralen. Der lagerstyres i begge systemer.

(Se afsnit ”8.Internal return of disposable items)9. Ved udlevering af akutvogne til anvendelse i de forbrugende

afdelinger leveres en fil fra T-DOC med leveringssted/afdeling og beløb. Dette skal igangsætte en omkontering i Oracle fra ejer af vogndepot (Transitlager på afsnit COP) til den forbrugende afdeling.

(Se afsnit ”9. Internal realocation)

Alt styring vedr. Batch/lot nummer på varer og udløbsdato styres i T-DOC, da den grundlæggende sporbarhed skal dokumenteres via T-DOC. Dette er aftalt med Getinge IT Solution og Region Sjælland for at give en klar afgrænsning på disse data mellem Oracle og T-DOC.




1. Synchronization of Item data from Oracle to T-DOC

Alle vare data, der udveksles mellem Oracle og T-DOC vil blive oprettet i Oracle som mastersystem og bagefter overført og importeres til T-DOC gennem en XML fil.

Disse varer vil være af 3 hovedtyper hhv. (steril/usterile) Engangs-, genbrugelige/flergangsvarer og produkter der produces i sterilafdelingen. I Oracle oprettes alle varer med oplysninger såsom: Nummer, varebeskrivelse, måleenhed, en estimeret kostpris, leverandør, leverandørens varenr. , producentens ref.nr. gennem indkøbsaftler osv. De oplysninger der er relevante for T-DOC overføres automatisk til T-DOC via en baggrundskørsel. Når disse varer oprettes skal disse varer markeres som T-DOC varer, for at sikre at de vil blive medtaget i udtræks fil til T-DOC. De vil være markeret i Oracle gennnem et såkaldt flexfelt at de skal overføres til T-DOC, feltet på varen vil blive kaldt ”T-DOC Vare”. Dette betyder, at alene varer der er markeret, som skal anvendes i den sterile afdeling og er relevant for T-DOC, kun vil blive overført. Alle andre varer i Oracle vil ikke være indeholdt i overførslen filen.

Disse markeringer af varer til T-DOC kan ses i nedenstående skærmbillede via flexflet samt tilknytning til lagerorganisation der dækker over sterilcentral:




Overførslen skal kun indeholde nyoprettede varer. Det styres ved at varer der er blevet overført til T-DOC vil blive markeret i Oracle som overført, og vil ikke blive overført igen. Denne information vil være som et beskrivende flex felt når varen er overført, som det kan ses nedenstående:

Varer der ikke skal anvende mere eller på anden måde udgår, vil blive markeret med en varestatus som inaktive i Oracle. Disse varestatus værdier vil blive mappet til de relaterede værdier i T-DOC gennem et flexfelt omkring tilhørende T-DOC status kode:




Overførsel af varedata fra Oracle til T-DOC vil ske via et baggrund job i Oracle, som kaldes "RS Overførsel af Vare til T-DOC/RS Transfer Item T-DOC". Til opstart i brug af Oracle skal alle varer der allerede anvendes i T-DOC synkroniseres mellem Oracle og T-DOC. For at dette kan ske skal alle varer oprettes i Oracle, hvor de vil blive tildelt et nyt varenummer automatisk. Alle disse varer skal efterfølgende omdøbes/oprettes/rettes i T-DOC med samme varenummer, som de er blevet tildelt i Oracle sådan at disse er identiske. Derefter skal der kun udveksles data når en vare, varegruppe, vareart eller en rekvirent oprettes eller ændres.

Field MappingNedenstående er eksempel på de data der er indeholdt i XML fil ved overførsel mellem ILS og T-DOC, og som er basis for dette interface mellem Oracle og T-DOC.Udfra XML skema fil leveret fra Getinge IT Solutions vil disse felter blive mappet til følgende felter i Oracle ved integration.XML filnavn fra Getinge IT Solutions: TDOCItemImport

T-DOC XML Fill Felt Navn

T-DOC Felt Krav Oracle Feltnavn

Eksisterende felt ItemItem Max 20 karakter Varenummer/Item Number

Eksisterende felt (Hvor stor er feltet i T-DOC)

ItemText Max 100 karakter Varebeskrivelse/Item Description

Eksisterende felt ItemStatus Mulige Værdier: Normal, ToBeOmitted, Omitted

Vare Status/Item Status

Eksisterende felt Vareart Anvendes ikke mere, men blev anvendt i ILS itegration

Eksisterende felt Vareartnavn Anvendes ikke mere, men blev anvendt i ILS itegration

Eksisterende felt UF10 Max 100 karakter PO Vare Kategori Navn (UNSPEC Kode) – PO Item Category Name




PO Vare Kategori Beskrivelse (UNSPEC Beskrivelse) – PO Item Category Description

Eksisterende felt Varegruppenavn Anvendes ikke mere, men blev anvnedt i ILS itegration

Eksisterende felt ItemTraceType Mulige Værdier: ItemNO, SerialNo, LOTNo

User Item TypeVia flexfelt (Markering på vare), hvor disse værdier for T-DOC skal være oprettet i tilhørende værdiliste

Eksisterende felt Varetypenavn Anvendes ikke mere, men blev anvendt i ILS itegration

Eksisterende felt VareStr Anvendes ikke mere (Er indeholdt i varebeskrivelsen i Oracle)Afventer

Eksisterende felt Pris Unit Price fra varen

Eksisterende felt ItemOrderStdUOM Max 20 karakter Måleenhed – Unit of Meassure (UOM).Der er ikke behov for nogen mapning

Nyt felt ItemSupplier Max 20 karakter.T-DOC bør oprettes til ikke at validere leverandørnavn. Det betyder at en leverandør ikke skal være oprettet på forhånd i T-DOC. Bliver der overført en værdi, som T-DOC ikke kender oprettes leverandøren automatisk.

Hentes fra nugældende aktiv indkøbsaftale.

Nyt felt Leverandørnr. Hentes fra nugældende aktiv indkøbsaftale på samme måde som ovenstående.

Nyt felt ItemManufactor Max 20 karakter.T-DOC bør oprettes til ikke at validere leverandørnavn. Det betyder at en producent ikke skal være oprettet på forhånd i T-

Hentes fra nugældende aktiv indkøbsaftaleDer er ikke behov for nogen mapning, som betyder at de oprettes, da producent oprettes automatisk i T-DOC i forbindelse med




DOC. Bliver der overført en værdi, som T-DOC ikke kender oprettes producent automatisk.

indlæsning.

Nyt felt ItemManufactorNo Max 20 karakter. Hentes fra nugældende aktiv indkøbsaftale

Nyt felt ItemDisposable True/False Hentes fra flexfelt på varen sammen med T-DOC markering

Nyt felt Lagerlokation (UF8)

Default lagerlokation for lagerorganisationen angivet i rapport parameter

Eksisterende felt Source Oracle




2. Synchronization of Product data from T-DOC to OracleNår produkter oprettes i T-DOC levers en automatisk overførsel omkring disse produkter til import i Oracle i en XML fil fra T-DOC. Disse produkter vil blive tildelt et Oracle varenummer når de impoteres ind i Oracle. De vil være markeret i Oracle gennnem et såkaldt flexfelt, at de kommer fra T-DOC via et flexfeltet på varen. Det vil blive kaldt ”T-DOC Vare”, som holder T-DOC produkt nummeret . Dette T-DOC produkt/vare feltet vil efterfølgende blive anvendt ved bestilling af disse produkter, da T-DOC ikke kender Oracle varenummeret.

Nedenstående er eksempel på de data der er indeholdt i XML fil ved overførsel mellem ILS og T-DOC, og som er basis for dette interface mellem Oracle og T-DOC.Udfra XML skema fil leveret fra Getinge IT Solutions vil disse felter blive mappet til følgende felter i Oracle ved integration via Vareoprettelse API.XML filnavn fra Getinge IT Solutions: TDOCArticleExport

XML Fill Felt Navn


ProdProduct Max 20 karakter Flexfelt på ItemMaster

ItemText Max 100 karakter Varebeskrivelse/Item Description

ProductStatus Mulige Værdier: Normal, Omitted

Vare Status/Item Status




3. Synchronizing customer data from Oracle to T-DOCRekvirentsteder oprettes og vedligholdes i Oracle. Dvs. oprettes en ny afdeling eller afsnit oprettes denne altid først i Oracle, som master system. Efterfølgende dannes en XML-fil, som indeholder de nødvendige data til oprettelse af rekvirenten i T-DOC. Som parameter til dette job i Oracle kan lagerorganisation angives, sådan at der dannes en fil for et enkelt sygehus. For at styre at en kunde er overført til T-DOC i en lagerorganisation (Sygehus), oprettes en flexfelt på dellager i Oracle hvor det markeres at det er overført til T-DOC. Derved overføres kun nye afdelinger når denne kørsel afvikles fremadrettet.Udfra XML skema fil leveret fra Getinge IT Solutions vil disse felter blive mappet til følgende felter i Oracle ved integration.XML filnavn fra Getinge IT Solutions: TDOCCustomerImport



Eksisterende felt CustCustomer Max 20 karakter. Subinventory Name

Eksisterende felt TDOC_Rekvirentnr

Ikke nødvendig

Eksisterende felt Custname Max 40 karakter. Subinventory description

Eksisterende felt CustCity Max 60 karakter. Post nr. fra tilknyttet lokation

Eksisterende felt CustUF01Kontaktperson

Hentes via tilknyttet interne kunde adressen, som er tilknyttet det enkelte dellager (den interne kunde).Denne information angives på kunden i Oracle via kunde kontakt oplysninger

Eksisterende felt CustTelephone Max 20 karakter Hentes via tilknyttet interne kunde adressen, som er tilknyttet det enkelte dellager (den interne kunde)Denne information angives på kunden i Oracle via kunde kontakt oplysninger

Eksisterende felt CustEmail Max 60 karakter. Hentes via tilknyttet interne kunde adressen, som er tilknyttet det enkelte dellager (den interne kunde)Denne information angives på kunden i Oracle via kunde




kontakt oplysninger




5. Transfer of stock quantity from the Oracle to T-DOC Dette er et nyt interface der ikke eskisterer mellem ILS og T-DOC i den nuværende løsning. Beskrivelse af dette er taget ud af designet og placeret i selvstændigt dokument, da det kræver udvidelse af T-DOC funktionalitet.Når sterilafdelingen køber engangs-eller genbrugelige varer, vil indkøbsprocessen ske i Oracle. Når denne indkøbsordre / rekvisition bliver modtaget i Oracle, skal den modtagne mængde af den disponible varer, også modtages i T-DOC til lager eller udgift. En XML-fil vil blive oprettet med modtaget mængde, varenummer og placering, se detailjer under mappning af felter senere i dette afsnit. Denne fil vil blive genereret af et baggrundsjob kaldet "RS Købt Modtagne Mængde for T-DOC". Denne information kan efterfølgende blive importeret i T-DOC fra den genererede XML-fil.

De mængder der modtages i Oracle, der skal overføres til T-DOC styres udfra lagerorganisationen (dækkende over sterilafdelingen), som skal angives af brugeren som en parameter ved overførsel. Det er styret på varen i Oracle om det er en vare der lagerstyret og derved skal overføres til T-DOC. Det vil i praksis jf. Region Sjælland være tale om fabrik engangssterile varer.De mængder, der overføres til T-DOC-fil vil være den Transaction Type "Modtag" fra nedenstående skærmbillede.

Field MappingDette interface er ikke mellem ILS og T-DOC idag og der beskrives derfor et nyt XML fillayout, som efterfølgende kan avendes som import i T-DOC når det er afklaret sammen med Region Sjælland.Udfra ovenstående XML fil vil disse felter blive mappet til følgende felter i Oracle ved integration:

T-DOC XML Fill Felt Navn T-DOC Felt Krav Oracle Feltnavn

Nyt felt ItemItem or ProdProduct

Varenummer / Item Number




Nyt felt QuantityDelived Mængde /quantity

Nyt felt UF10 Lager Lokation

Mængden der overføres i denne fil vil altid være mængde i varen eller produktets primære/basis måleenhed




4. Transfer of information request from Oracle to T-Doc Når personalet i afdelinger på Region Sjælland har behov for at anmode om varer fra sterilafdelingen, vil dette ske i Oracle enten via manuel bestilling i e-indkøb, telefonisk bestilling (dvs at personale i steril afdelingen udleverer direkte fra T-DOC til afdeling, som beskrives i afsnit ”7. Internal usage of disposable items”) eller kanban brik bestilling. I Oracle vil begge typer bestillinger (e-indkøb og kanban) blive omdannet til en såkaldt intern salgsordre til levering fra sterilafdelingen for den ønskede vare og mængde. Denne ordre vil indeholde leveringssted/rekvirent, varen der skal leveres og mængden. En fil vil blive oprettet, som indeholder disse oplysninger. Denne fil vil blive genereret af et baggrundsjob kaldet "RS Intern Mængde Anmodning fraT-DOC". Disse data kan efterfølgende blive importeret i T-DOC fra den genererede XML-fil.Ordrelinjer der skal eksporteres til T-DOC er styret af organisation og et flex felt på ordrelinien, som parameter for baggrundsjobbet "RS Intern Mængde Anmodning fra T-DOC" . Denne overførsel af bestillinger fra Oracle til T-DOC vil ske fuldt automatisk, men parameteren styre at filen kun indeholder data for en Steril afdeling.Overførsel fil vil ligge som et automatisk baggrundsjob i Oracle, som vil sikre at de relevante bestillingsliner overføres i XML til T-DOC løbende automatisk.

Når en ordrelinje er blevet eksporteret til en XML-fil fra Oracle vil ordrer blive markeret at de er blevet eksporteret til T-DOC. Denne information styres med et flexfelt med værdien Yes, når de er overført til T-DOC.




Field MappingUdfra XML skema fil leveret fra Getinge IT Solutions vil disse felter blive mappet til følgende felter i Oracle ved integration.XML filnavn fra Getinge IT Solutions: TDOCOrderImportUdfra ovenstående XML fil vil disse felter blive mappet til følgende felter i Oracle ved integration:



Eksisterende felt OrderExternalID Max 20 karakter. ORDER_HEADER_ID

Eksisterende felt OrdCustomer Max 20 karakter. Subinventory Name bagved kunden, da kunden i T-DOC er identificeret gennem dellageret i Oracle. (Se afsnit omkring kundedata overførsel)

Eksisterende felt OrdTime Dato CREATION_TIME

Eksisterende felt OrdStatus Mulige værdier: Sent (Ny Ordre), Cancelled(Ordre annulleres)

Følgende Oracle ORDER_WF_STATUS værdier skal sende følgende to mulige T-DOC værdier.Awaiting Shipping (oracle værdi) = Sent (T-DOC værdi)Cancelled (Oracle værdi) = Cancelled (T-DOC værdi)

Eksisterende felt OLnLine LINE_ID

Eksisterende felt OlnArticleItem ITEM NO (Hvis der ikke er angivet et T-DOC produkt nummer). Ellers er dette felt tomt




Eksisterende felt OlnArticleProduct Felxfelt (Hvis der er angivet et T-DOC produkt nummer i flexfelt på varen i Oracle). Ellers er dette felt tomt

Eksisterende felt OLnQuantityOrdered

Positiv tal ORDERED_QUANTITY

Eksisterende felt OlnReqDelTime Dato REQUEST_DATE




6. Transfer of information supplied goods from T-DOC to Oracle

Internal Order Når varer er plukket og afsendt via T-DOC til levering, leveres en fil fra T-DOC med oplysninger om forsendelsen og den faktiske leverede mængde. Denne fil skal importeres i Oracle til at bekræfte den faktiske afsendte mængde mod den interne salgsordre i Oracle. Det betyder, at eventuelle restordre situationer vil blive afspejlet, hvis ikke hele mængden bliver leveret fra sterilafdelingen. Det er kun gældende for fabrikssterile varer. For produkter styres der ikke på restordrer. Import af data omkring den afsendte mængde i Oracle vil ske via baggrundsjobbet "RS Internal Ordre Forsendelse fra T-DOC". En identifikation af den interne salgsordre og ordrelinje i Oracle er påkrævet i filen fra T-DOC. Der håndteres ikke restordre ved levering af produkter via T-DOC. Det betyder at varen markeres, som lukket i Oracle uanset om hele den bestilte mængde leveres til afdelingen. Personalet anføre på plukkeseddel fra T-DOC, hvis ikke hele mængden er blevet leveret. Der efter skal der oprettes en ny bestilling, hvis yderlig mængde ønskes til afdelingen. Der håndteres restordre styring på fabrikssterile varer.

Field MappingNedenstående er eksempel på de data der er indeholdt i XML fil ved overførsel. Udfra XML skema fil leveret fra Getinge IT Solutions vil disse felter blive mappet til følgende felter i Oracle ved integration.XML filnavn fra Getinge IT Solutions: TDOCCustomerOrderExportUdfra ovenstående XML fil vil disse felter blive mappet til følgende felter i Oracle ved integration, hvor data indlæses i Oracle API for salgsordre shipping. Det som styre at data skal kaldes til Oracle Shipping API er at XML filen er udfyldt med værdi for OrdExternalID, som angiver at der udleveres mod en salgsordre fra Oracle.

XML Fill Felt Navn Oracle Feltnavn

OrdExternalID ORDER_HEADER_ID

OLnLine LINE_ID

OrdSuppStatus (Ordre line skal have værdien ”Delivered”)

OLnArticleProduct or OLnArticleItem INVENTORY_ITEM_ID

OLnQuantityDelivered SHIPPED_QUANTITY

OLnTime ACTUAL_SHIPPED_DATE

Løsningen understøtter ikke at der udleveres andre varer til den oprettede ordre end det som er bestilt via Oracle. Ønskes det at udleverer ekstra varer skal de enten bestilles fra afdeling eller leveres direkte via T-DOC uden tilknytning til ordren fra Oracle.




7. Internal usage of disposable items

Når en case cart er produceret til brug i kirurgi-afdelingen håndteres dette inden for T-DOC. Herunder også når kirugi-afdelinger bestiller engangsartikler fra sterilafdelingen håndteres det inden for T-DOC. Men brugen af engangsartikler inden for T-DOC skal ajourføres i Oracle, da disse varer lagerføres parallelt med T-DOC i Oracle.

Derfor skal der dannes en fil fra T-DOC, når der er et internt T-DOC forbrug af engangsartikler til f.eks. casecart produktion. Denne fil skal indeholde varenummer og mængde, der skal reduceres. Desuden skal leveringssted/rekvirent være inkluderet i filen.

Baseret på filen fra T-DOC vil der i Oracle være oprettet et antal kontoalias-transaktioner der anvendes ved dette interne T-DOC forbrug af engangsartikler. Det skal sikre at forbuget bliver bogført korrekt til den korrekte afdeling og på den rigtige konto afhængig af varetypen. Til dette oprettes et program i Oracle, som trækker disse varer ud af lagerbeholdningen i Oracle. Programmet i Oracle vil blive kaldt "RS T-DOC internt brug"

Konteringen ved udlevering vil blive styret udfra dellageret varen udleveres fra, hvor leveringsted delen kan afledes. Dertil kan produkt konteringen styres udfra varen der leveres, hvilken indkøbskategori den tilhøre.

Field Mapping Nedenstående er eksempel på de data der er indeholdt i XML fil ved overførsel. Udfra XML skema fil leveret fra Getinge IT Solutions vil disse felter blive mappet til felter i Oracle ved integration, hvor data indlæses i Oracle API.XML filnavn fra Getinge IT Solutions: TDOCCustomerOrderExportUdfra ovenstående XML fil vil disse felter blive mappet til følgende felter i Oracle ved integration, hvor lager diverse transaktions igangsættes via Lager API. Når data leveres direkte fra T-DOC i XML filen TDOCCustomerOrderExport vil feltet OrdExternalID ikke være udfyldt, da varer i denne situation ikke udleveres mod en ordre i Oracle. Det at dette felt ikke er udfyldt vil i Oracle styre at der sker denne type udlevering til afdeling uden Oracle ordre/bestillingsnummer.


CustCustomer Subinventory Name




CustName ACCOUNT ALIAS

OlnProduct or OlnItem ITEM_NO

OLnQuantityDelivered QUANTITY

OrdSuppStockName LOCATOR

OrdType 1 (ordre)

Værdien i feltet OrdType styre om der skal ske en udlevering eller retunering. Værdien 1 når der skal ske en udlevering. Værdien 2 når der skal ske en retunering.




8.Internal return of disposable items

Når en casecart leveres tilbage til sterilafdelingen håndteres dette inden for T-DOC. Ved retunering kan der være indeholdt engangsartikler, som ikke er anvendt og derfor kan anvendes igen. Denne returtransaktion skal ajourføres i Oracle, da disse varer lagerføres parallelt med T-DOC i Oracle.

Derfor skal der dannes en fil fra T-DOC, når der er en intern retunering i T-DOC af engangsartikler fra Case cart. Denne fil skal indeholde varenummer og mængde, pris der skal tilføres lageret. Desuden skal leveringssted/rekvirent være inkluderet i filen, sådan at de kan blive debiteret for de varer der leveres tilbage.

Baseret på filen fra T-DOC vil der i Oracle være oprettet et antal kontoalias-transaktioner der anvendes ved denne interne retunering i T-DOC engangsartikler. Det skal sikre at det bliver bogført korrekt på den korrekte afdeling. Til dette anvende samme program som ved forbrug, som trækker disse varer ud af lagerbeholdningen i Oracle. Programmet i Oracle vil blive kaldt "RS T-DOC internt brug", hvor mængden der kommer fra T-DOC angives som positiv og der angives at det er en retur. Varen ligges på lager i Oracle til nugældende gennemsnitskostpris.

Field MappingBygger på samme felt mapninger og logikker som beskrevet i afsnit ”7. Internal usage of disposable items” ovenfor.Udfra ovenstående XML fil vil disse felter blive mappet til følgende felter i Oracle ved integration:


CustCustomer Subinventory Name

CustName ACCOUNT ALIAS

OlnProduct or OlnItem ITEM_NO

OLnQuantityDelivered QUANTITY

OrdSuppStockName LOCATOR

OrdType 2 (retur)




Værdien i feltet OrdType styre om der skal ske en udlevering eller retunering. Værdien 1 når der skal ske en udlevering. Værdien 2 når der skal ske en retunering. Kommer der i den modtaget fil fra T-DOC varer der ikke er lagerstyret i Oracle, vil disse vare bare blive fra sorteret og ikke modtaget på lager i Oracle. Det kan f.eks. være situationen med T-DOC produkter.




9. Internal realocation

I sterilafdelingen produceres såkaldte akutvogne der stilles i et vogndepot/transitlager, som beredskab til en akutsituation. Fra sterilafdelingen overføres omkostingen til en overordnet operationsafdeling via en udlevering gennem T-DOC. Denne overorndet operationsafdeling bærer omkostningen indtil den udleveres til fysisk anvendelse på en anden afdeling. Når en akutvogn udleveres til anvendelse i en afdeling foretages en udleveringstransaktion i T-DOC, som skal igangsætte omkontering i Oracle til forbrugendeafdeling.

Det som er vigtigt for Region Sjælland er, at omkostningen placeres korrekt ved udlevering til den forbrugende afdeling/skærende speciale. I T-DOC udleverer akut case cart til en kunde der hedder Vogn depot (VD), og når denne tages i brug, skannes den videreudleveret til et af de 4 skærende specialer. Det er i forbindelse med denne transaktion, at Oracle skal forberede modtagelse af data, således der i Oracle kan laves en ompostering af omkostningerne i økonomisystemet til de skærende specialer, hvilket er et mindstekrav jf. IL 11.1.5

Udlevering af akut case cart til vogndepot sker, som beskrevet i afsnit 7. Internal usage of disposable items. Derved er de varer der lagerstyres i Oracle udleveret til kunden (COP) for vogn depot. Når akut case carten tages i brug foretages udleveringstransation i T-DOC.

Felter til at styre denne transaktion fra T-DOC i filen TDOCCustomerOrderExport er ikke kendt, da dette ikke er en integration mellem ILS og T-DOC ved Region Sjælland før implementering af Oracle. Derfor beskrives ekstra felter i denne fil, som T-DOC skal leverer til Oracle sådan at ompostering kan foretages i Oracle finans. Ved modtagelse af disse data i Oracle foretages en ompostering i Oracle finans gennem API for finans journal. Data omkring hvilken hovedbog konteringen skal foretages gennem sker ved at afsendende (vogndept) og modtagende (skærende speciale) findes via lagerorganisation for tilhørende dellager (hvilket sygehus tilhørende den forbrugende afdeling)

T-DOC XML file name XML Fill Felt Navn Oracle Feltnavn

Ikke kendt Internal realocation = Yes Værdien Yes for dette felt styre at denne omkontering startes i Oracle.

Ikke kendt CustNameReceive (Skærende speciale der forbruger akutvogn)

Navnet for modtagende afdeling. Via dette navn findes konto der skal debiteres udfra oprettet ACCOUNT ALIAS med dette slutkundens navn.

Ikke kendt Value (Værdi for akutvogn der flyttes til skærende speciale)

Værdi i danske kroner for akutvogn der skal omkonteres fra vogndepot til forbrugende afdeling

Ikke kendt CustNameSend Navnet for afsendende afdeling (vogndepot). Via dette navn findes konto der skal krediteres udfra oprettet ACCOUNT ALIAS med dette slutkundens navn.




Deliverables

IBM must deliver functional and technical solutions to the customization:

1. MD050 document 2. MD060 document (if the customization requires it)3. MD070 document (if the customization requires it)4. MD120 document (if the customization requires it)5. MD125 document (if the customization requires it)

As well as6. Test-report (defect-extract from Test Director – public report)

Existing customizations:If this requirement contains add-on’s to existing customizations we will move the solution-description of these parts into the relevant documents (together with reference to this requirement) in order to continue having the best possible total overview of the functionality of our customizations as well as traceability. In that case customer re-approval of those documents is necessary.

Customization-reference (RICE)

Title Comment

Acceptance Criteria

The following criteria must be accepted/completed before the final delivery of this requirement is considered done:

Acceptance-criteria

Documentation Comment

Design approved Document Control in DS.912 / MD050 updated with customer approval

Re-approval of existing documents1

Document Control of relevant DS.912 / MD050 updated with customer re-approval

RS ObligationsThe following lists RS obligations regarding to this customization. If this assignment is scoped in a project more precise obligations and agreed time limits will be found there2

There must be a contact-person available at RS for each customization in the project (see table with persons involved)

Questions during the development-phase must be answered by RS RS is responsible for the test activities as usual

1 In case this customizations involves add-on’s to existing customizations2 Ask your Project Manager




Test

The following tests will be done for this customizationTest-type Respon

sibleEnvironment

Integrations

Specific need for testdata

Development-test (DEV) IBMSystem- and integrationtest (SIT)

IBM

User Acceptance Test (UAT) IBM

The areas that should be tested are described in the “User Procedures”-section later in this document.

Dependencies

The following dependencies / relations to other customizations are important to be aware ofCustomization-reference (RICE)

Title Comments

Risks The following risks are related to this customizationRisk Probabili

tyPotential consequences

Responsibility

Actions required




To do

ID Status Closing date

To do Answer Remarks Raised by

Raised date

Resp.

1. ItemGroup used in T-Doc2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.



Interface mellem Oracle og sporbarhedssystem · Web vieware marked by a Word Bookmark so that...

Documents

Transcript of Interface mellem Oracle og sporbarhedssystem · Web vieware marked by a Word Bookmark so that...