Error: location not found

[Former Member]

Hi everybody,

while doing an initial transfer of master data- the location model was cleared successfully, but the materials and work centers int models give an error: location not found with Q msg. TID not giving any details in system log as it says no log found. I am unable to figure out what to look out for now.

Regards,

Lok

[Former Member · Accepted solution]

Loknath,

I can suggest you two things. (because we are not having complete detail of your problem)

1. Ensure, Location in error message is created successfully in APO. Check consistency

2. Enable the logging so that we can get to see more detail logs.

Pavan

[Former Member · Accepted solution]

Hi Pavan,

The location exists in APO after the CIF

While CIF'ing material, i was directed to a Q message (APO inbound) saying locaton does not exist.

What could be possibly wrong

[Former Member · Accepted solution]

in the first thing please check resetting the status of the queue if it goes through..if not check if location is assigned to a model in APO

[Former Member · Accepted solution]

Thanks Sai,

A initial transfer job is running, ignore faulty q mode. As such the locations are assiged to active model and verion. the problem is material int model. refers to "location does not exist" and the inbound Q TID is not recognized in slg1. so can't pinpoint the location that it talking abt. The same is the phenomenon with Resource model too.

Regards,

Loknath

[Former Member · Accepted solution]

Hi Sai,

If you could spare some time i would like to discuss for a few minutes to get this thing sorted.

Regards,

Lok

[Former Member · Accepted solution]

please go to the failed queue entry and open the LUW and check to what all locations its refering to..you should be able to get the location details if not as I normally say try debuging the queue

[Former Member · Accepted solution]

thanks sai,

the problem is log shows nothing with the TID.. and i dont get anything from the generic selection of logs

debugged but its greek to me. could not follow anything

Regards,

Loknath

[Former Member · Accepted solution]

In the past I had similar issue but not with the initial transfer and at that time I could trace out the location and that was not assigned to the active model in APO.I think lets wait for the job to run and see if it throws any error again..

[Former Member · Accepted solution]

Hey,

the job got cancelled in 1 sec

here the log.

11/26/2008 10:48:34 Job started 00

11/26/2008 10:48:34 Step 001 started (program RIMODINI, variant &0000000000003, user ID LR249J) 00

11/26/2008 10:48:34 Queue: CFLDEC6CLNT500_2480 Blocked XC

11/26/2008 10:48:34 Tgt System: SC6CLNT500 XC

11/26/2008 10:48:34 Function Module: /SAPAPO/CIF_PROD_INBOUND XC

11/26/2008 10:48:34 Error Text: Exception condition "LOCATION_NOT_FOUN XC

11/26/2008 10:48:34 Operation terminated due to error (queue CFLDEC6CLNT500_2480, target system SC6CLNT500) XC

11/26/2008 10:48:34 Job cancelled after system exception ERROR_MESSAGE 00

[Former Member · Accepted solution]

hey if you can call me in next 15 min I can give you my number..can discuss on this

[Former Member · Accepted solution]

Loknath,

The fact that the job failed immediately indicates that the failed queue from the previous run has not been processed or deleted. It is still there, blocking new IM transfers, and you MUST deal with it before trying to activate any more CIF models.

For right now, forget about the logs. Go directly to the failed queue CFLDEC6CLNT500_2480, using SMQ1 in the ERP system. Note the first LUW that has a failure message. The failure message may give you enough data. If not, then display the contents of the LUW. The text contained in the LUW should give you clues as to exactly what is failing.

The most common reason for this failure is that you are trying to send a Material/plant combination from the ERP to SCM, and the plant does not yet exist in SCM in the active model. The failed LUW will contain clues as to what that failed plant (location) is. In my system, the first mention of a plant in the Material IM LUW is in the rows immediately following the text "I T _ C I F _ M A T L O C" (keep the spaces if you are going to do a text search).

Once you have the errant location in your hand, then comes the hard part, determining what is wrong with it in SCM. Does it exist? Is it the right location type? Exists in the active model? Right Business system Group? Livecache all consistant?

If you can't determine the error with the location in SCM, sometimes it is easier to inactivate the location CIF, delete the location completely from SCM using WUF, and start over.

Good luck!

Regards,

DB49

[Former Member · Accepted solution]

Hi DB,

did precisely as advised by you, deleting the faulity q's. looked into all such Q's. the RIMODINI job got cancelled after 3 hrs. in a sense a slight improvement over y'day. The where used list again pops up some error quoting some MDL table. Nothing happened. Same error "location_not_found"- the business system group is correct, location type is correct, assigned to active model and verison.

I am now going for a mass delete spree.

Pls. refer my latest post

Regards,

[Former Member · Accepted solution]

Hi Loknath,

Sorry you weren't successful yet. Welcom to the wonderful world of SCM troubleshooting!

Mass deletes can be fun, as long as you are working in the Dev or Qual system. Not so much fun working in Production when the Director of Planning is breathing down your neck waiting for a solution...

I myself would stick to the Whereused and the one location I had discovered had triggered the error. There are LOTS of reports in SCM to delete stuff that is hard to delete. You mentioned an error message about an MDL table. Can you give me the exact text of the message? I can research this while you are on your 'killing' spree.

Regards,

DB49

[Former Member · Accepted solution]

Thanks DB for following this up close.yes i have executed all these mass programs to delete everything in APO DB and Livecache

This system is a parallel Qual system that needs to be up and running in a couple of hrs for lots of testing. As of now i am nowhere close. still the same LOCATION NOT FOUND Q WITHOUT ANY LOG. THIS TIME I AM IGNORING AND SIMULATANELOULY DELETING SUCH APO INBOUND QUEUES letting RIMODINI finish atleast once and that done now for all MD models. Ran the CIF job that successful.

This is the message that i am still getting (it all started from here) while creating a sales order in ECC.

Access via 'NULL' object reference not possible.

Could you see what could be possiblly wrong

ps: with WUF it seems i have entered a large selection. this time with limited selection it returns. but i already used this program /SAPAPO/DLOC_DEL_JOB - submit job for deletion of locations.

[Former Member · Accepted solution]

Hi Lok,

Sorry, I have never seen that error message. I HAVE seen some weird messages which talk about 'access' when working on an SCM with RulesBaseAvailability check when 'someone' had deleted one of the rules determined by an access sequence, but left the determination procedure in place. I don't remember the exact message.

FYI that job /SAPAPO/DLOC_DEL_JOB only deletes locations that have already been tagged for deletion. You can't tag a location for deletion until all WUF entries have been removed, or you have manually tagged the location for deletion using /SAPAPO/LOC3..

Do you yet know at least one location that definitely giving causing an error (by looking in the errored LUW) is bothering you? Have you successfully deleted it?

You sound like you are under some pressure. This is normal! Unfortunately, this type of troubleshooting just cannot be rushed. It is necessary to be very methodical and very meticulous.

Using the method you have used to delete the failed queue LUWs mean that you cannot be sure that your testing will work in the same way that the live system will work. If you elect to proceed with the testing, you should make every effort to use testing scenarios that avoid any reference to the data elements contained in the deleted queues.

Regards,

DB49.

[Former Member · Accepted solution]

Hi Lok,

Did some quik research. Your error

Access via 'NULL' object reference not possible.

Is an ABAP error, not an application error. Check ST22

for the dump in both systems (ERP and SCM). Get your

developers/basis guys to look at this while you correct any

remaining app problems.

Rgds,

DB49

[Former Member · Accepted solution]

Hi DB,

Million thanks for the wonderful document with the precious comments for mass deletion.

Unfortunately i am unable to find which location is the Q referring to. The Q msg (short one) is not enough to make out whats wrong. and the TID in SLG1 does not return anything

As of now the situaiton is like this (after RIMODINI.. ignoring and deleting the faulty Q's)

- In the Product master MAT1- the product only exists at global leve but not at location level.

-All other master data exists in SCM

-There some trasaction data thats cifd and consistent

-Events from ecc (e.g sales order) is not able to call APO for ATP check and gave that NULL error that i talked abt

In the meanwhile i took some ABAP help as my ignorance in this area is encyclopedic but could not identify the souce of the problem. The abap guy debugged the ATP BAPI FM that was going wrong.

If you can give your personal email. i would glad to have a livemeeting with you

Regards

Loknath

[Former Member · Accepted solution]

This is what i read from ST22 reg this atp check from sales order. line 337 is where it fails. this is a standard program so you can find and let me know what cooks up there. cant attach the full runtime error here, a feature thats badly needed.

Termination occurred in the ABAP program "/SAPAPO/CL_ATPT_REQ_GRP=======CP" -

in "CHECK_AVAILABILITY".

The main program was "SAPMSSY1 ".

In the source code you have the termination point in line 337

of the (Include) program "/SAPAPO/CL_ATPT_REQ_GRP=======CM008".

328 MOVE-CORRESPONDING sy TO gtc->ms_atpmsg.

329 gtc->message_append( ).

330 RAISE internal_error.

331 ENDIF.

332 ENDIF.

333

334

335

336 * handle tpds check for manual override of supplier or check of subitem

>>>>> IF lr_req_end->loc->loctype = /sapapo/cl_tpds_c=>loctype_supplier

338 AND bustype = /sapapo/cl_atp_c=>reqgrpbustype_anchor

339 AND ( ls_howtochk_end-sos_execute IS NOT INITIAL

340 OR ( lr_req_end->strucind = /sapapo/cl_atp_c=>strucind_nosucc

341 AND lr_req_end->tpdsout-tpdsflag IS NOT INITIAL ) ).

342 ls_howtochk_end-atpidx = 0.

343 ls_howtochk_end-allidx = 0.

[Former Member · Accepted solution]

Lok,

Unfortunately, my ABAP is also meager.

The include in your other post does not exist in my system (SCM 5.0) although I have several with similar names. Even if I had any ABAP, I couldn't help much without the code to look at..... You really need to get an experienced ABAPer to sit with you in a debug session. He needs to tell you contents of all the fields that are being used to determine the message, and he should give you a suggestion as to what is wrong.

Beyond that, next thing I'd try is some logical troubleshooting. Find a Material/Plant/customer combination that you KNOW exists in SCM. Create a sales order against this combo, and if it works, then you know the problem is related to the missing Productl/Location Master data.

You have not yet identified to me what contents you found in the failed LUWs, only that the messages were short and cryptic.

While waiting for your ABAPer, you might want to try this:

1. Generate your errored queue. I think I don't have to tell you how to do this.

2. SMQ1 in the ERP. populate client, asterisks for queue name and queue destination. execute.

3. select the errored queue from the list. clik display.

4. Status should be 'sysfail'. Double click on the word sysfail. You will get text of the message that will give a little more information. If the location is not readable (sometimes it is too long to fit into the popup window), close the error message window.

5. Put your cursor on the queue name and clik display.

6. The first LUW in the list is the one you want to see. Should be tagged with an error. Again, put your cursor on the queue name and clik display.

7. Now you are seeing the data contents of the record. It is displayed in hex and in ASCII. You can kind of read the ASCII (text) stuff. Page down until you get to the ascii "I T _ C I F _ M A T L O C".

8. On one of the rows you should see a location type, eg '1 0 0 1, 1 0 0 2, 1 0 0 3, etc (there will be spaces between each number). In the same row, just before this, there will be the name of a location. There may be multiple locations in this LUW, keep paging down, eg, plants, warehouses, shipping points, customers, etc etc. EVERY LOCATION IN THIS LUW MUST PREVIOUSLY EXIST IN SCM before the product/location record can be created. Do they?

9. If they do, and you have tried all the previous steps, then you must assume that 'somehow' the data in SCM is corrupted (this does happen). Delete each of the locations and re-CIF them across, one location at a time. Do not use jobs, do it manually, it will go quickly. Then, try to re-create and re-activate the failed IM (which is a Material Master record).

I am unfortunately on holiday and am now embarking on some travel, so I won't be able to assist any more today. I will try to log on tonite or tomorrow (I am in North America) to see where you have gotten.

Good Luck,

DB49

[Former Member · Accepted solution]

Finally the reason is something like this

A tool (SAP intergrated) was being used to extract master and transaction data tables from another system to this new system that went wrong on many aspects.

This tool was being used for the first time.. and it copied the master tables and transaction tables with logical system entries same as the original system. This is supposed to be corrected with a program called bdlc- to correct the logical systems.

This consequently made the GUID;s inconsistent in various master tables. esp. Locations and hence they could never be deleted from the tables and the reason for this post. e.g. tables like LOC and LOCMAP had different LOC GUIDs.

Usually client copies and DB refreshes are used peridodically to keep dev, qual and prod systems in sync This time the tool was different. a tool from a new vendor to build new clients. With this tool not entire master data (entries) transaction data needs to be copied. This client was supposed to be used for regression testing.

Now we have some new type of problems in the connected ECC system. despite wiping off all the integration models, initial transfers are referring to wrong logical systems. Now that the problem source is known. I just hope this would be set right now. I am not breaking my head anymore.

Thanks for all those (esp. DB - many thanks for sharing that whole list of programs for systematic deletion of master and trx data from APO) who patiently followed this thread. I thought i shd make a final attempt at summarizing the whole thing lest you face similar issues in future.

Regards,

Loknath