Repost Open Purchase Oder & Active Sales Orders

RAMMEDJR

Well Known Member
It has been recommended to us from our client manager that we look into
running the R43990 (Repost Open Purchase Orders) and R42995 (Repost Active
Sales Orders) to resolve some inventory integrity issues. We have been
unable to find documentation that explains which tables the information is
drawn from and what tables this data is then updated to. If someone could
point us to where we could find documentation on these procedures and any
heads-up from someone who has run them.

Thanks

Dave Rammer
Sheboygan County IS

B7331 SP11.2 / HP-UX 11.0 / Oracle 8.0.6
 
Dave,

Our experience is that Repost, etcetera solves little. For inventory
integrity problems, we have written/are writing reports in SQL to compare
records in F43121 receipts, F4111 inventory transactions, F41021 inventory
quantity on hand (requires computing change in balance with balance prior to
record update), F0911 GL, to detect when records do not get written. We
have seen more problems since upgrading from 7321 to 7332. Now and then it
is necessary to use Oracle to poke the right records into the tables. Other
stuff: We have seen F41021 balance updated with no other records written
when user gets "commit failed" message, which an upgrade to Oracle 8.1.6 is
supposed to have fixed. Also, I would consider doing a report with F41021
unit balance times F4105 unit cost and comparing to F0911 GL balance in
inventory account (works if you use cost type 02 weighted average, anyway)
as another tool to see if files are out of sync via no records written. I do
not have info on sales module as we use a non-One-World billing-and-AR
program. Send e-mail to me if you would like more detail on integrity tests
and files.

Dave Mallory Denver Water OW 7332 SP 15.1 Oracle 8.1.6.3.4 NT
4.0
 
Rammed,
R43990 recalculates open purchase orders against an
item/branch record in the F41021 inventory location
file.
Similarly, the R42995 recalculates commitments, or
open sales orders, against an item/branch record in
the F41021 inventory location file.
Is this enough info? let me know, be more than happy
to help.


--- RAMMEDJR <[email protected]> wrote:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=9646


__________________________________________________
 
Below is the reply I received from the JDE help desk about R43990.

Date: 03/08/01
Call number: 4287530

R43990 Repost open purchase orders (from G43A31 Advanced and Technical Menu)

1. What creates a need for this report?
For example, when you look at item availability and look for quantity on order, and you don’t think the numbers are correct.

2. What does the report do?
It looks at the F4311 and the status of open PO’s. Based on your data selection criteria, the report re-enters the correct quantity on order for open items. It will not double the quantities for “good” PO’s.

Hope this helps.

Russell



J Russell Karnap
 
Dave,
We run R42995 every 4 hours (on the scheduler). I'll try to find which tables
it hits - we have someone here who works with that report.

I'm curious to know what problems you're having with inventory integrity. We
are continually finding that the available quantity is not properly reduced when
a lot has been assigned to a sales order and the pick has been run. This
results in over-committing lots and finding that the inventory is not available
when we go to ship it. I've talked to JDE about this but unless we can track a
pattern, they can't help us. Are you running into anything similar?

Thank you,

Kelly Read
Chiquita Brands, Int'l
B733.2 SQL server. SP 11.2
 
Kelly,
R42995 hits the F41021 file - Inventory Location file.
It recalculates the sales order commitments field, i
believe its 'PCOM' - correct if I'm wrong.
Paul
--- Kelly Read <[email protected]> wrote:


__________________________________________________
 
Additionally, with the processing option in the R42995 to update the
customer's open order total, the F0301/F03012 are updated as well.

Tammy Baade
M&D Information Systems, Inc.
 
Kelly,

Do you run into any problems running it during the day? How long does it run each time? When setting up repost our consultants advised us to run it at night otherwise you're trying to hit a moving target. We have had numerous issues with repost and would love to run during the day but it also takes a while to run (we have thousands of orders entered per day and thousands of items so I guess it has a lot to look at.)

One of the other issues we have with repost is that it sometimes doesn't clear up items. If we notice an item has a skewed availability, for example on hand quantity is negative, then we often have problems with inventory allocation at pickslip print, such as committing to a serial number/lot number that doesn't have available quantity, or double-committing to one serial number. If we cancel the order(s) and run a single-item repost, it clears everything up.

Our biggest concern with repost is that it doesn't have any output, so you can't see what it changed. We are working on a report that will compare F41021 to F4211 to see if what has been ordered is properly allocated, which I hope will resolve some of our problems.

The issue we are facing now is that repost is many times the underlying issue with all later item integrity issues. If repost doesn't properly "fix" availability, we face many different problems with inventory allocation and relief.

Justin Revoredo
Amersham Pharmacia Biotech
 
Along with the other files mentioned, I know that the SO Repost will also update the F4201 Header Order Total field if it is out of whack with what is on the actual order. On the other hand, PO Repost DOES NOT update F4301 Order Total and there has been a World SAR on in it for some time. In World, we found discrepencies between detail on an order and what the header total was saying and had to write a custom program to check and update the header field for us. (Using the field for reporting so had to be correct!)
 
Justin,

We do run the repost during the day. It's set up on the scheduler to run every
4 hours. This version is set up to run wide open. Our users can also submit it
if they suspect a problem. They should be using data selection to cut down on
the amount that needs to process. They may select by branch plant, staus, item,
or wild card on part of the lot number, etc. I checked the schedule and it
normally runs 10 minutes or less. We don't have the volume that you do so your
times will be greater depending on data selection. Our orders are normally no
more than 2 items. I'd suggest that you set up your data selection to prevent
the job from running too long.

My biggest concern is why we need to run it so often. It sounds like you're
running into the same thing that we are - available quantity not being reduced
properly. In our case, the repost clears this up. I've talked to JDE about
this but since we can't reproduce the problem on demand, they can't suggest a
solution.

Kelly Read
Chiquita Brands, Int'l
Oneworld B733.2 SP11.2 SQL Server.
 
Kelly,

It's good to hear that we are not the only ones who are suffering from repost. Word to the wise, when reposting and using data selection to narrow the records processed for each job, make sure your data selection criteria is not overlapping for any of the jobs.

Here's what I mean. We were looking for a way to reduce the records that are read for each version of repost without modifying the report to bring in extra report variables for data selection. So we used workstation id as one of the variables. Since most of our users are running off of one of 10 terminal servers, we tried to run a repost version to repost orders placed on each terminal server.

We have experienced integrity issues with some batch jobs that use an inventory commitment business function. There are issues on the Knowledge Garden about this. They say something about a null pointer issue, which causes integrity issues when this business function looks at 999 or more records.

So we were concerned that the repost job needed to be narrowed down, not only because of time constraints, but also because we could not be guaranteed that repost was properly recommitting all orders. We thought our solution would work, but instead what it appeared to do was clear all commitments and then recommit all orders on terminal server 1, then the next version would run and clear all commitments again and only commit orders on terminal server 2. So we were only recommitting 10% of our orders.

Needless to say, we figured it out soon enough, and had another workaround with data selection. The point of this story is to make sure your data selection does not restrict repost from looking at all orders for any given item at any given time.


Has anyone else had similar problems with reposting? I'm not 100% satisfied with our latest solution, or more importantly, why we need to be so reliant on reposting often..

Justin Revoredo
Amersham Pharmacia Biotech
Oneworld B733.2 SP12 AS/400 Oracle
 
Re: RE: Repost Open Purchase Oder & Active Sales Orders

Read your note on Inventory Integrity. This is an issue with us as we are a large Canadian wholesale distributor with multiple sites and we are running One-World B7333.

Are you still active with Inventory Integrity and wish to exchange ideas in regards to it ?
 
Re: Repost Open Purchase Oder & Active Sales Orders

Justin hit upon the most important point in running reposts. Always run by item. NEVER run for an individual order!!! You should sort by item also.

Just another thing to keep in mind...since they run from the F4211/F4311, it will only clear up committment issues for items on open orders that are not already hard committed or have been relieved from inventory. I think there are other criteria also that will prevent processing, but not sure of the specifics. Any other items not on open orders will NOT get cleaned up.
 
Re: Repost Open Purchase Oder & Active Sales Orders

FYI: I read most of the posts about Reposting Active Sales orders to try and figure out why we where having a problem. we have been running R42995 for quite some time now ), and never seemed to have a problem. However this year the job bombed out, however it did not produce any errors, it just stopped commiting after a certain point. We made a best guess, based on some of the posts that we read, that there where just to many open orders on the system. The end of summer is especially busy for us, and this year even better than the last. Apparently this problem showed it self last year, but we apparently fixed it by running the clear hard/soft commits. However, we always run clear hard/soft commits before running the Repost Active Sales Orders, and it is still bombing out. We then decided to create multiple repost jobs. One for the main distribution center, and one for the other 6 distribution centers. It bombed out on the main distriubtion center, but worked for the other ones. I am assuming this worked because they had fewer open orders. We then decided to break the Repost Active Sales Orders into 4 jobs. We decided to break the main warehouse reposts into three different reposts. we did this by using selection criteria. we decide to do three different product classes that would cover all our products. For example the first repost would do product class 10-41, the second did product class 60, and the third did product classes 61-99. The fourth job again did all the remaining warehouses for all product classes. Guess what? It worked. By breaking it down enough we where able to get it to complete the job.

I read in one of the posts that JDE imposed a 999 (record?, Item?) limit. Perhaps this is why it bombed out but never actually produced an error. Anyway it is working now. Hope this will provide some kind of insight into the wonderful world of running reposts!
 
RE: Repost Open Purchase Oder & Active Sales Orders

Kevin

You do not say what database you are running on in your post. We are on
Oracle and occassionally get the same problem where the job does not
complete successfully. Generally it is a problem with rollback segments not
being large enough to handle the volume of doing it in one hit. You have
taken the right approach by breaking it down into smaller units. Check the
server logs for one of the jobs that failed (if you still have them).

Regards

Marty Fleming
Business Analyst
Richmond Limited

Phone: +64 +6 8786464 Ext 8168
Fax : +64 +6 8780959
Email: mailto:[email protected]

OneWorld: Xe SP16.1
Database: Oracle 8i
Enterprise Server: Compaq Proliant 8500R W2K






OneWorld: Xe SP16.1
Database: Oracle 8i
Enterprise Server: Compaq Proliant 8500R W2K
 
Back
Top