MII - Shift Level Reporting

[nagarajan_ramudu]

Hi MII Gurus,

What is the best and suggested method to handle shift information in MII? Can we configure MII to have the shift information? (example Shift: Work center1, 12 Hour Shift, this means there are 2 shifts for a given day). How long the shift level production information can be kept in MII? (short period reporting - for example: three months)

Do we really need to bring the production recipts with shift information to SAP?

For a given day SAP says production as 1000 Qty, but MII say 500 Qty was produced for the first shift and remaining was produced in second shift with exact production receipt time and details.

Is this a suggested process? It is my idea that we can avoid lot of shift level configs, shift level reporting and MII interfaces

with above approach.

Was any project impleted like this? Please share your ideas and thoughts.

Can we easily integrate MII with BI for the reporting?

Thanks

Nagarajan

[Former Member]

Although MII has time periods built into it where you can define a shift start time / end time etc. I have found this to not be much of use in the real world. Not because a design issue with MII, mostly because of the complex nature of manufacturing. In most applications I've used a "Shift" table in my relational database. In some cases the table is solely used in MII, but I've also used and RFC to CATS data to get shifts. A table like this table comes in handy when you need queries like "Give me year to date production numbers for shift 1" type of queries. Its a lot easier to query production data with a query like "SELECT * FROM PRODDATA WHERE Shiftnumber = 1" Than trying to query from a time basis alone. Of course its really nice if your production data has a shift number attached to it, so keep that in mind when you are building your production data inserts.

As far as how long you wish to keep your data in MII, thats really up to your storage capacity and database design. I use 1 year as a minimum typically.

[nagarajan_ramudu]

Thanks for your time and reply.

With a dedicated table(s) in MII, can I avoid sending shift information or still I need to send the shift level details to ECC? I am thinking to avoid duplicate information in both ECC and MII. Please let me know.

[Former Member]

Hi,

Shift production details are very useful. Based on the shift it is very easy for us to calculate production of the day,month and year. If data is gathered from RDBMS then it s very easy and transaction will also quiet handy, in other case if data is from plant level then you need to put some efforts to get the production data.Here if you get production in shiftwise then no need to query again to plant for getting the daywise,monthwise etc.(Reduces multiple transactions).You can aggregate shiftwise data into daywise,monthly, yearly. Coming to storing the data, you can go with xml data storage.

I hope this helps you someway.

-Suresh

[Former Member]

Depending on what you are doing you may have to send shift data to ECC. It sounds redundant, but I've always kept shift data in RDBS for MII for the simple reason that building reports from this data is WAY easer than leveraging data from ECC. Also, most of the systems I've developed had some requirement by the customer to be able to build their own reports. Far more people know SQL than RFC calls. So some duplication of data is often necessary. However, I don't consider this to be a drawback. Data sometimes needs to be "scrubbed" by users. You'll have faulty sensors or someone forgets to report correct qualities or a power outage, in other words, s&%t happens on the shop floor you'll never fully anticipate. And this is far easier to do scrubbing in MII than having to commit to ECC then do roll backs.

This might be a result of my old school thinking, of building these systems before we ever talked to ECC, but I've rarely run into problems where my MII and ECC data do not match. Usually that scenario is caused when someone makes a change and ECC and no mechanism is made to push the change down to MII.