Ship Confirm in batch (interface)

Aarto

Aarto

Reputable Poster
Hi list!

We are facing a project in which the customer wants to use a 3d party Warehouse management system that has to be interfaced to OneWorld.

When it comes to sales order process, we would like to use the F47 files as basis for communications with the WH system. Entered sales order could be populated to F47131/F47132 by using R42500 (batch ship confirm) without calling R47500 (Inbound transaction processor) in the end section. We could then export these files to the local WH system.
The local WH would then process the orderlines and if any picking deviations are reported, we could update F47132 with the actual picked, backordered and cancelled quantities

So.. to test this, I ran the batch ship confirm R42500 UBE followed by R47500 (Modifying the F47132 file before R47500 was ran, changing the shipped/backordered/cancelled qty:s)

Alas, R47500 apparently only processes the lines where F47132 qty:s are identical to F4211 qty:s. If the F47132 qty:S were changed after the R42500 was ran, these lines would be reported as errors.
Only the lines where qty:s were unchanged were processed by R47500

In a previous project we had to write an RPG ship confirmation application from scratch and i would really like to avoid that if at all possible..

Has anyone else faced the same problem? Any tips?
Maybe we have to modify R47500 to accept differences between F47132/F4211 and to treat F47132 as 'manual input' that overrides F4211 data

Grateful for any tips..

OneWorld Xe
AS/400

Regards..

Aarto Reponen
Application Consultant
SYSteam Applications International Consulting AB
Mobile: +46 703 089 284
E-mail: [email protected]
http://www.systeam.se
 
You may be stuck with doing an RPG program, but you could make it a purely batch program. We needed to do a green-screen interactive ship confirm program, but found that we could split the line directly in F4211 and still keep everything in synch.
For example, if the original line was for a quantity of 100 from location A and they actually shipped 70 from location B and 20 from location C, then we changed the single F4211 record from 100 allocated to location A to 70 allocated to location A and created two more records for 20 allocated to location A and 10 allocated to location A (with this third record having the back-ordered line statuses). Since line splits during our pick list routine incremented by 0.100, we made the line splits during the ship confirm routine increment by 0.001 so that people could quickly see what split the line
The next step was to create ship confirm record in F47132 for the quantity of 70 and location of B and the quantity of 20 and location of C, to take care of the 90 that was shipped, while the 10 in the back-ordered status is taken care of by the nightly sales order re-post.
Thus you might try running a batch program that compares the modified F47132 with the F4211 and programmatically splits any lines necessary to get them matched up.
 
Back
Top