Strange Outside Process Problem

[jdaub]

I run Mac SQL Server 7.5.103f with several companies. We routinely use outside processing in shop orders (SFC) where we link a PO line item with a SO line item. Then when the PO is received the material is automatically issued to the Shop Order.

This has always worked fine, however, all of a sudden with no cause we can pin down, when we receive in the PO for one of these outside processes, the distribution amount on the receiving screen is $0.00, instead of the correct extended price. This in spite of the fact that the correct unit price and qty info are on the same receiving screen just above the distribution area. The POORDLIN and POORDHDR files both look fine, as do the SFDTLFIL and SFORDFIL. I have run out of ideas and would appreciate any thoughts on the matter.

The process still works correctly in other companies (databases) running the same Macola code on the same SQL Server 2000 installation. It certainly appears to be data-related, but all the relevent tables check out to be healthy. Does this scenario ring a bell with anyone? Its got my reseller baffled. I imagine someone is doing something differently, but no one is admitting to it. It will probably turn out to be something simple and stupid, but some pretty good minds have been banging heads over this for a while.

Thanks

 

[MacolaHelp]

Check your material cost type/loc file in IM & make sure all records have GL #s in all fields. Maybe even export the file & visually scan. This data is used when generating a PO & is written into the poordlin. You may need to export poordlin & visually scan the GL account portion of the records to see if you have ascii corruption. I believe when you receive, it gets the info from the poordlin to process the GL trx, but you can override at that time. It sounds like the PO might not have the proper GL information in the file.

I once had a client who was hit by lightening & we didn't discover file corruption until 3 weeks after the event & we began having odd behavior in SF. When I exported sfordfil I found little smiley faces & dingbats in some records. It was a "looking for a needle in a haystack" project, but I did finally succeed. A standard macola rebuild or btrieve rebuild did not catch this. Macola has told me that the SQL import does better validation on this ascii character problem.

Have you tried exporting, renaming these files & importing back in? If so, it might find any corrupted records. If you think it might be a user, can you identify who has created the PO? Do you create POs inside PO or create unreleased POs from SF or MRP? Maybe it is in the PO creation process that something is haywire?

 

[jdaub]

MacolaHelp- Thanks for the good suggestions. The I/M cost type/loc file looks good, and I have exported and imported the PO header & line item files, using SQL Server utilities. The account numbers look good in the PO Line Item file.

We are creating these PO's from within the P/O module, then linking to the Shop Order. Normal PO's work fine. It is only those PO's that are linked to a Shop Order that present a problem.

I have several PO's that date back to September that exhibit the bad behavior. I have restored a test DB from shortly after that, and everything including the distribution works correctly. However, the same order fails now. I am doing a file by file copy into the test DB of current data files used in receiving, and testing after each one, in hopes of isolating the problem to a particular file. So far the problem does not appear to be in the PO Header or Line Item files, nor Shop Floor Detail.

 

[jdaub]

Problem Solved! During a merger of two inventory locations by the accounting people they accidentally created a record in the IMINVLOC file with a blank itemno & location. For an outside process the receiving program was using the cost from this record rather than the PO cost, and distributing $0.00.