0

I am currently retrofitting several custom code review Packages developed in an ECC environment for use in BW. I used a TOC to bring them from ECC into a BW Sandbox outside of STMS and as expected got a few RC8's. As I am going through and activating and fitting the code base to BW I immediatley came across the missing TIMS domain in BW. I am looking for some detail or information on why TIMS would not be a Domain in BW as most all other Domains in ECC are in BW.

My options are to move the TIMS domain in from ECC or create it in the BW environment. I am just struck by the fact it is not there.

Any advice before i go further is appreciated.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
apesa
  • 12,163
  • 6
  • 38
  • 43
  • I work with SAP Banking Services (FSAPPL software component) and TIMS domain is not available in it either. In the ECC system connected to the BaS on the other hand it is a part of software component FI-CA (Contract Accounts Receivable and Payable), so very business specific. – Jagger Sep 08 '13 at 12:17
  • @Jagger: FI-CA is not very business specific. It's what the FI guys use to sneak in stuff that should have ended up in some basic package but for some reason didn't. At least that's my impression :-) – vwegert Dec 04 '13 at 20:22

2 Answers2

1

I don't have a system at hand right now, but depending on what package and therefore what delivery component R3TR DOMA TIMS is a part of, it's only natural that it's not part of your BW installation. I'd recommend adapting the customer objects - you probably won't need the domain after all, it should be possible to adapt the data elements that use it to just use the data type TIMS directly.

vwegert
  • 18,371
  • 3
  • 37
  • 55
  • That's what I have done, but I wanted to get more background as I have never really needed TIMS in BW before. Thanks for your input. – apesa Sep 09 '13 at 16:32
1

A properly designed SAP BW system uses very few custom programs. There are routines (snippets of code included in system generated programs) which convert some data during the loading process but all the objects without exception are based on specific database field types which are defined to have a specific meaning and function in the overall snowflake schema database design. This provides for solid consistency across applications when reporting.

This also means that when data is loaded an imposition is made so that it conforms to exactly the same datatype and size no matter where its source is from, and much work is done to ensure this consistency.

All date "fields" (we don't really have "a simple field" in SAP BW - it is in fact a collection of related database tables collectively known as "a characteristic") are based on a single referential characteristic 0DATE which itself has a Data Element of /BI0/OIDATE and a Domain of DATUM.

All time characteristics are also based on a single referential characteristic 0TIME with a data element /BI0/OITIME and Domain TIME. To answer your question this domain is of type TIMS.

You have to remember that a SAP BW system is mainly about reporting on data that is arranged for speed and accuracy, quite often at an aggregated level. Sometimes a more detailed level is required, but rarely does this detail drill down to the level of the second (in time), as in fact this will explode the amount of data to be stored, and does not often provide additional value to reporting users.

Where Time is used or required, it would only be useful or practical to store the data aggregated by minute.

T9b
  • 3,312
  • 5
  • 31
  • 50
  • Thanks for your answer. However I am porting a Utility package from ECC to BW. It will provide several Utility classes for a Code Review service. I mentioned that in the first couple sentences above. Your answer applies to BW, but does not really apply to my question. Thanks tho. – apesa Dec 04 '13 at 00:00
  • I would have thought that given the facts adapting your code would have been obvious. – T9b Dec 04 '13 at 12:39