LOGISTIC COCKPIT: a new deal overshadowed by the old-fashioned LIS ?
Everything started when…
…some time ago, in our SDN BW Forum this question (from Sabrina Marcado) appeared:
Can anyone please tell me how LO-Cockpit is better than LIS ? I dont’ have knowledge of R/3 and I didnt really understand about the advantages.;
then, Sabrina explained in more detail that in one of my previous post (since this one has not been the first and, I think, will not be the last time that someone will want to better understand this matter!) I talked about these points:
1. Detailed Extraction: extraction can be deactivated (e.g. schedule line data) leads to leaner extractors with less volume.
2. Document Changes: only BW-relevant data changes will be updated (less upload volume).
3. No LIS-Know How necessary.
4. LIS-Tables are not updated: reduced data volume due to avoided redundancy.
Ok, in our BW Forum such a question seldom comes to nothing.
And if you are wondering how much time have to pass before someone bites the bait… here attached you can find the entire thread (with no changes) followed to Sabrinas doubts!
Thrust and parry !
From Bernd Sieger (Posted: Apr 11, 2005 1:17 PM)
in fact those points do not hold much advantages of LO extraction over LIS extraction. For an explanation:
1.: With self-defined info structures (LIS) you can generally do the same. You even save some uploading data volume since the data will already be aggregated in R/3.
3.: If you try to work with self-defined info structures (as opposed to the delivered content) you will have to build up some LIS specific knowledge about field catalogues, creating info structures, creating update rules and general LIS customizing.
4.: You can switch off the updating of the LIS info structures (not the delta tables), if you only need the data for BW (with some disadvantages regarding a future need for an init, though). So this is hardly a point in favor of LO extraction.
But there is certainly one other important point in favor of the LO extraction:
LIS extraction, while currently still maintained by SAP, is an old technology and will not be developed any further. This means that you can not expect to see added new functionality of the BW or PLUGIN_BASIS being adapted by LIS extraction.
Please also have a look at OSS note 543002: some Business Content of the LIS extraction has been discontinued.
LO extraction will (as far as I know, insert your disclaimer here 😉 ) stay up to date as far as technology goes.
Hope that helps,
From Roberto Negro (Posted: Apr 11, 2005 2:30 PM)
Dear Sabrina, here are some explanation…
1) With the new extraction cockpit, several new data structures are delivered. For each level of detail (header, item, schedule), there exists an extract structure as well as a data source.
In the old LIS we had LIS information structure called (for sales order) S260. In that structure we store information on header, item and schedule line level, which means that we had a lot of sparse entries in these structures. So if you now have to decide which level you need, you actually just have to look at the key figures that you need and to which level they are assigned to (with correspondant less redundancy or unuseful data).
If you compare that to the LIS, you always extracted all information, even if you just were interested in header information or item information or schedule line information.
2) This is a consequence of the previous point: if you have document changes on an item level and youre just interested on a header level, you would not recognize this with the new extractors. You would just select the extractors on the header level and they would not recognize that there is any change on the item level. So they just report on the level that you are interested in.
3) If you check the business content and it looks fine for you, you just have to activate these new extraction techniques in the logistic extraction cockpit customizing and then you can directly go ahead.
So there is no additional customizing necessary.
Only in some case (enhancement of LIS comm.structures) you have to know your transactional flow in order to correctly fill your new fields, but anything relevant about the old LIS reporting structures !
4) LIS tables (as S261 and related twin delta tables) are no longer updated and they are no longer needed. So you dont have redundant data and you dont have additional processing at the time when you process the documents.
Bernd, sorry, but I think that right those points were the real advantages of the LC extraction and it’s not helpful to say (and this is true) that LC is the new and LIS the old (and, afterwards, not still maintained or enhanced by SAP), so LC is better than LIS !
Otherwise I think that SAP people will be offended by this!
Hope it helps !
From Bernd Sieger (Posted: Apr 12, 2005 12:31 PM)
regarding 1: Please refer to OSS note 543002. The S260, for example, has been discontinued for a long time now. If you create self-defined info structures (S501-S999) you can be much more specific than in the Cockpit DSes as to what should be reported and what not. So that would be a clear point in favor of the LIS.
2.: Again, with self-defined info structures, events and updating groups you can do the same or better in LIS.
3.: Yes, LIS in general needs some more specific know-how than LO Extraction via the Cockpit. However, the processes are well-known and documented. There are also training courses for the LIS.
4.: You can achieve the same when using extraction from LIS info structures. See for example OSS note 309893.
As I have shown those “real advantages” are in fact not significant (except, to some degree, point 3).
I feel very comfortable to say that there are currently no plans for any further developments in LIS extraction. That is a contrast to LO Cockpit extraction, where this even currently takes place (you will see in ERP 2005).<(p>
Please note that I have been the responsible developer for both, the LO Cockpit and the LIS extraction for several years at SAP. 😉
From Roberto Negro (Posted: Apr 12, 2005 2:26 PM)
in what you write there is already (and quite evident) an answer (or better, a possible methodological criticism approach):
1) “If you create self-defined info structures”….you can obtain the same result granted by STANDARD logistic cockpit datasources…
2) “with self-defined info structures, events and updating groups you can do the same or better in LIS”…
3) “training courses for the LIS”…
It’s evident that we have to compare STD functionalities (the same starting points) and not what we can achieve with several (more or less complex) customizations.
If you believe that obtaining a certain level of result with no effort thanks to LC (as a starting point) and the same result but with self-defined infostructures, custom events, new updating groups, training courses, modifications of the standard and so on it’s the same (and for this reason you say that those “real advantages” are not significant)….ok, everyone is free to say what he wants !
Everybody (working with BW) knows that there will be no further developments in LIS extraction and related STD datasources are already no longer maintained (in fact, people says “OLD LIS datasource”…), but, in my opinion, if a beginner asks why LC replaced LIS (and it’s the same to ask what are the advantages of this change, because I hope that SAP replaces something with something new because there will be some advantages or some less disadvantages, compared with the old one),it is a self-evident truth to say that LIS is old and no longer maintained and LC is the future and don’t offer any profit to our BW beginner that are trying to better understand the reason of what happened and don’t render unto Caesar that which is Caesar’s !
I’m almost amused that you are showing your badge of rank (“I have been the responsible developer…”)…
I pay tribute to your experience, but what I wrote simply comes not from me (I’m an ordinary BW consultant) but from a transcript of a know-how conference call (“Logistics Extraction Cockpit” September 14, 2000/10:00 a.m. CDT) and, to be more specific, from one of your colleaugues, Nicolai Unterbarnscheidt from the European RIG, the Regional Implementation Group for BW.
If you want I can send to you this document so you can reach an agreement with Nicolai.
Nice to meet you !
From Bernd Sieger (Posted: Apr 13, 2005 9:40 AM)
You have some good points there, Roberto. 😉
Indeed, I may be a bit biased because if you already have LIS knowledge it is not a big hassle to create self-defined info structures and get them up and running.
If you are already experienced in LIS (however, I now see that this is probably a wrong premise regarding the OP), it could be even argued that creating a new info structure using an existing one as a template is not much more work than customizing your extract structures in the Cockpit. I never saw a customer so far, who used exactly the delivered extract structures.
Just to clarify: I told you my responsibility as a developer for those areas at SAP only as a reaction to your statement here: “Otherwise I think that SAP people will be offended by this!”. I wanted to make sure that this is quite not the case. I did not want to argue from any position of authority… 🙂
Now, let’s see if we can find some more points in favor of LO Cockpit extraction as opposed to LIS extraction, to comply with the RIG people.
There are several limitations in your ability to create a reporting model, if you work with data sources based on LIS info structures. One would be, that the data is already aggregated in case of LIS info structures. You can not retrieve information of individual document changes, in most info structure designs.
Another point is the server load the updating of info structures and their delta tables creates. The LO Cockpit extractors also create some load, but it usually should be much lower.
I hope our points of view are not too far apart anymore.
I posted this weblog…
…to demonstrate that nothing is beyond dispute and everything (even if part of our firm beliefs) can be strengthened (or weakened too) after an open and civil discussion with another;
…to show how much seriously SDNers (apart from some naughtiness…eh eh eh) have the (BW) matter at heart;
…cause I think that after this nice thrust-and-parry a lot of BW-SDNers can gain more understanding of this so interesting world (in my opinion) of BW data extraction;
…since Im not so sure that this diatribe is now closed (since I believe that LC has been a big step forward in logistic extraction even if with some imperfection) and I want to involve everyone wants to put forward more than one argument (or to refute other arguments too!) in favour of one way of thinking rather than another one (provided that there are something of different!).
1. V3 modes
V3 updating is available in LIS, too. No points here.
2. Direct Delta
This can be compared to V1 updating in LIS. While there are differences in the means, there are virtually none in the effects (data going in V1 updating to the target).
3. Queued Delta
This one has been developed for the LO Cockpit because the serialized V3 had some serious flaws, as explained in OSS note 505700. However, the flaws were _serialization_ issues. This, most of the time, is not applicable to info structures of the LIS, at all. For most info structures it is not a problem if the deletion of a document comes before the creation, since the data will be aggregated anyway. This is generally different for ODS Data Sources.
As I can see, there is not black or white, but only a neverending series of grey shades!
This will be judged by posterity!
But in all this discussion you all forgot a big pro for the LIS. If you change a field that is not in the LO cockpit you'll have to work quite hard to get the delta into the BW no matter how many appends you did to the LO structures.
Indeed you are correct. That is my problem right now, How to get the DELTA of appended fields in LO structures...
recently I had some success with creating generic extractors right on the R/3 tables. They are not the best solution in any way but it worked quite well in my special topic.
First of all, yours is a warped reading of my words 🙂
I told 'SAP people will be offended...' as a consequence of a reasoning in which (this was my first impression!) it was said that the only advantage (or so it seemed) of LC over LIS is that LC is new and LIS is old (Lapalisse!).
It's evident that no one in SAP will be offended if someone says that something will be retired...but simplify the advent of LC (that have to replace LIS in the intention of SAP) with "It's new" and no other arguments (anyway added later, so, no problem for me with Bernd!) it's not a real advantage and can represent a partial interpretation of reality!
Said that, my sentence was ironic and nothing else, SAP people will be offended when they want and it's not up to me...it was only a quip !
I know that a lot of people still uses LIS and is more or less happy (and still need a lot of help, as you can see in our forum...), but debate is about LC advantages (or not) !
Delta capability of added fields in LC is the same problem that was in LIS (here, if you add a field and nothing else, you will have the same situation)...and solutions are the same (as analyzed in my previous weblog)...
Reading your exchange of skills and great technical know-how is really a big help to me. I learned a lot from you guys. Both of you have valid points and are very firm in your stand.
I hope there will more healthy debates like this in the future and I'll wait for it...
Since LO is update in the same V1 update and there are no 'UPDATE RULE' as in case of LIS - the reliability is phenomenal. You can argue that LIS can be update in V1 task - then you are putting a lot of strain on R/3 - as for example a sales-order-save would have to wait till LIS update rules have been processed. In LO its almost a simple move - unless customer has programmed any MC* user exit. For some extractors - like application 12 - there is some processing logic to determine - last good mvt date etc .
LIS updates is prone to errors and I have seen missing documents. I have not seen missing documents in LO .
LIS delta is ADD - so you cannot update an ODS object in overwrite mode in BW - while LO is ABR delta .
I do not know if there is any standard way of achieving 'Zero down time' intialization with LIS .
I think we are comparing a BMW and a scooter 🙂 .
this one is a really good discussion about the pros and cons of LO vs. LIS.
In my life as a BW consultant I mostly implemented the LO-extraction even if there are some problems related to the delta for custom defined and added fields. I only implemented LIS-extraction, where the customer already used the LIS.
Thanks for the great blog.
Had a question related to the stock initialization using the 2LIS_03_BX. When filling the init tables using MCNB, the postings need to be blocked on the system. But what if this is not possible to do ? Is there a solution for this ?
Was also thinking about a custom init extractor which fetches the stock values a given date in the past. But 2LIS_03_BX uses quite a complex logic to do this. Are you aware of the logic used to extract the stock qty and value at a given point in time ?
Thanks for the help.
Wanted to write you an email regarding this, but could not get your email.