on 07-08-2014 1:31 AM
Hi all,
Our system is ME6.1 with ECC 6.0 ehp 6. using DRF and MEINT for integration
I would like to have inventory IDs be created in ME when I do a 261 in ECC, each inventory ID would be a discrete raw material serial number from the material document, is this possible standard?
in the ME documentation, it refers to creating inventory IDs through integration, but no other details, where is this database field ERP_inventory=true?
“The inventory IDs are created through SAP ME ERP integration or manually by shop floor personnel.”
“For inventory ID records created through SAP ME ERP integration, the database field ERP_INVENTORY is equal to 'true'.”
Thank you in advance
Hi David,
Yes, it is possible. See the details here:
Transfer of Floor Stock Data - SAP Manufacturing Execution (SAP ME) - SAP Library
Regards,
Sergiy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Sergiy, however can you point me towards the correct settings in the system for the inventory IDs to be created as the raw material serial numbers from ERP?
eg.
ERP material: ABC
ERP quantity: 1
ERP serial: 34920001
Goods issued to ME via DRF Movement 261
ME material: ABC /version A
ME quantity: 1
Inventory ID: 34920001
my material maintenance settings are:
Data to Collect on Assembly: INV
Data to Collect on Removal: INV
Data to Collect on Floor Stock Receipt: ERP_INV_REPT_DATA
IN500 activity settings are on
Automatic_ID_Generation: No
when inventory comes into ME, it just automatically generates a inventory ID based on my next number maintenance settings and does not capture any serial information.
Thank you in advance!
David,
We have a similar need. We want to take a 311 (instead of a 261), get the ECC batch number and use it to generate our inventory ID. The first transfer of a quantity from batch 12345678 into ME would get inventory ID "12345678-01". The next would get "12345678-02", and so on. We are also trying to put a service extension on the split service so that splits use this same format, just taking the next available 2-digit 'split number'.
We do get the BATCH_NUMBER assembly data field on the inventory record, so that we have the tie back to the ECC batch. We just want to take it another step beyond that, and make the generated inventory IDs more obviously related to the original batch number.
Let us know if you make any forward progress, and we'll do the same.
Regards,
Barry Schader
Medtronic
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Two years later ...
Just some notes on our experience in this area:
We implemented this in production, but essentially did it the 'wrong' way (IMO):
We went live with the inventory ID being the ECC Batch Number plus a sequential suffix (eg: 123456789 -> 123456789-0001). That took two changes:
I’m not sure that I would recommend our approach, as it totally ignores Next Number Maintenance. So the user loses all flexibility to define the format, if the service-extension is turned on. I think it’s possible to ‘filter’ the service extension, but I we haven’t gone there yet. And that wouldn’t address the MEINT part.
Subsequently, for SFC-generation, we did a service extension on the generateNextNumber method in Next Number (NN) itself, so that the user can now put “%ERP_BATCH%” in the Prefix field for any NN configuration, but probably only for SFCs. The extension looks up the batch number from the shop order. So that leaves the user with the flexibility to decide which NN configuration(s) to use this in.
The downside to extending NN: We weren't able to figure out how to get the sequence numbering to behave exactly right for our application. We set Reset Sequence Number to "Always". Then, when we release an entire shop order at one time, we get the result we want, with SFCs running from %ERP_BATCH%-0001 to %ERP_BATCH%-0999 (for an order for 999 units). But if we release a partial order, then the next attempt to release more units from the same order will start again at -0001. That SFC already exists, so the release fails. We thought it might skip over existing SFCs, but it did not (at least in our configuration on 6.1.4). If we set Reset Sequence Number to "Never", it solves that problem, but burns through sequence numbers very rapidly.
--Barry
Message was edited by: Barry Schader
User | Count |
---|---|
99 | |
11 | |
11 | |
6 | |
6 | |
4 | |
4 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.