PO text

BillFClark

Active Member
Uploading purchase orders with F4301Z and F4311Z. What file needs to be populated to create header text lines? Also I know it is viewed through order attachments but what file is that on the AS/400?

One World Xe B7333 SP13, World 7.3, AS400 File Server, NT 4.0 Deployment Server, EDI TrustedLink E Version 5 (Premenos)
 
Hi Bill,

Attachments are held in the F00165 table.

The GDOBNM field will generally denote the file the attachments will be
associated with, prefixed by GT to indicate a media object. So for the
Purchase Order Header this will be GT4301.

The GDTXKY field will generally be the primary key for that file, so for our
PO header this will be Order No, Order Type, Order Company, Order suffix. As
this table has a composite primary key separate the values with pipes '|'.
e.g. 128|OR|01000|000.

Field GDTXVC will contain the text from your legacy system, don't worry
about all the formatting data as this will get added the first time the
attachment is updated. You may not be able to see the text you've added
previously via the UTB as GDTXVC is a very big field.

If your using a standard Table Conversion you'll be limited to attachments
of 255 char's.

Have fun

Neil.
 
Re: RE: PO text

I really appreciate the help.

One World Xe B7333 SP13, World 7.3, AS400 File Server, NT 4.0 Deployment Server, EDI TrustedLink E Version 5 (Premenos)
 
Re: RE: PO text

Neil,

Do you know how to upload text for purchase orders? I know to upload text for an inbound purchase order for EDI you update F4714 hdr or F4715 dtl but I am not too familiar on upload outbound PO's using the Z files. FYI, We have a separate system which creates the PO's and we will be uploading those to JDE. Then we run the PO print R43500 to extract to our EDI files.

One World Xe B7333 SP13, World 7.3, AS400 File Server, NT 4.0 Deployment Server, EDI TrustedLink E Version 5 (Premenos)
 
RE: RE: PO text

Hi Bill,

If I understand you correctly you need to upload the text for the PO's into
OneWorld (though you've slightly confused me with sending them out again).
If the attachments are less than the 255 characters maximum then you can
create a table conversion UBE. This can take data from a number of different
sources (such as flat file, access) and output them into a OneWorld table
(in our case the F00165). How do you plan to populate the F4301Z1 and
F4311Z1 as this is may prove adaptable to loading into the F00165? Is this a
one off load for an initial data migration or for an ongoing interface?

Regards

Neil.
 
Re: RE: RE: PO text

Neil,
This is will be a several times a day process. We have a separate AS400 package that generates our purchase orders. An RPG program will extract those orders and write them to the Z files and the UBE will create in F4301 and F4311. I was wanting to know if there were Z files to build to create the notes. Since the F00165 is keyed by order number we will not know that until the UBE runs. I guess after the order is created a program could read the F4301 file and then chain out to our legacy notes file and create the F00165 then? Would prefer having the UBE create the notes if possible though. Thoughts?

One World Xe B7333 SP13, World 7.3, AS400 File Server, NT 4.0 Deployment Server, EDI TrustedLink E Version 5 (Premenos)
 
RE: RE: RE: PO text

Hi Bill,

The way I'd look to approach this is along the lines your thinking of, so
the process will be:
1. Generate PO's
2. RPG extract and write to Z files, also including a unique reference back
to the original PO. I've used Reference 2 (PHVR02) before to store the
original order No. but there's plenty of fields to choose from.
3. Run R4311Z1I to import from F4301Z1/F4311Z1 into F4301/F4311.
4. New program to extract notes. Now you can write these directly to the
F00165 or you can create your own z file based on the F00165 and create a
simple UBE to the load this from your new z file into the actual F00165.

The Pros over having a new z file is that you'll have more control if the
process goes wrong and this should allow for easier error correction.
The cons are it's another step which will increase load times.

I'd favour the creation of a new z file. You'll then be able to utilise the
file and UBE again if you have other processes that need to create F00165
records.

If your notes are over 255 char's you won't be able to use a table
conversion UBE. There was some C code published a while ago so have a hunt
round the archives.

Regards

Neil.
 
Re: RE: RE: RE: PO text

Neil,
Thanks for you help with the PO text. It has worked exactly how you said. Once it is in the F00165 and someone reviews the attachment One World puts the formatting codes in the file (TXVC field). We then hav an RPG pgm that will extract those notes when building the fax to send. We have to strip off the codes (not a huge deal). Was wondering what is the use of the GDTXPO field (254 alpha)? Could we write the PO comment (which will not change) into both the TXPO and the TXVC field and just retrieve the TXPO comments for the fax? Am getting ready to test to see what happens when we bring up the attachment what affect it has on the TXPO field but was wondering if there were other uses for the field.

One World Xe B7333 SP13, World 7.3, AS400 File Server, NT 4.0 Deployment Server, EDI TrustedLink E Version 5 (Premenos)
 
RE: RE: RE: RE: PO text

Hi Bill,

Glad you were successful. I'm not sure what TXPO's used for in the F00165,
the DD doesn't reveal too much either so I'd say ago ahead and try (in a
strictly controlled manner of course). Changes made in OW to the attachment
will only be reflected in the TXVC but this doesn't seem to be a concern.

Good luck

Neil.



OW B733.2, SP 11.1
Sun Solaris/UNIX
 
Bill,

we are actualy doing a conversion from World to OneWorld and the biggest problem was to transfert the media object to F00165. I was looking at all the reply here and I want to add something about the 255 caracters limit.

We are using "Table Conversion" and transfering Media Object text with +- 2000 caracters and it's working without any problem now.

here is the solution :

Call Business Function GetTargetDataSource (B9840E)
szObjectStatus <= "AV"
szUserGroup <= SL UserID
szNameObject <= "F00165"
szEnvironmentName <= SL TargetEnvironment
szDatabasePath => VA rpt_szTargetDataSource
(Those fields are the only one that we are using to have it working)

Then Call Business Function ConvertNarrativeText (B0500047)
szOBNM <= VA rpt_Object ex: "GT4311"
szTXKY <= VA rpt_Key_Blob ex: ("123|00000|SO")
szLNGP <= VA rpt_Language
szTXPO <= VA rpt_Blank
szTXVC <= VA rpt_ProcessingOptionText
cErrorFlag => VA rpt_ErrorFlag
szTargetDataSource <= VA rpt_szTargetDataSource (from BSFN B9840E)

(Those fields are the only one that we are using to have it working)

Very important ! we got many error using a Variable (rpt_ProcessingOptionText) of type TXVC, use instead a variable of type "ISTDATA2".

Tell me if you have any error with this solution. I can tell you that we are using it right now with a thousand records and it`s working fine even with text over 2000 caracters.

Christian Audet



Implementing B7333 (Xe) SP14.1, SQL
(Support B732, B7331 and B7332)
 
Hi Christian,
A small correction: I didn't find ISDATA2. However, ISTDATA2 is there!
Warm regards,
Adrian

B732.1 SP12.2, Oracle 806
Xe U3 SP17, Oracle 8i
FormScape 2.1
RS/6000, Citrix<P ID="edit"><FONT SIZE=-1>Edited by Adrian_Chimirel on 11/19/01 11:19 AM.</FONT></P>
 
Hi Adrian,

Do I understand you well that you are looking for large Data Items?
If yes then please see the attachment of this post on the Forum.
We have our own Data Dictionary browser on our B7332 where I can filter on field size (and other DD attributes) easily.
The attachment contains the hits filtering on size greater than 1999.
The result contains 22 Data Items on our B7332.

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 

Attachments

  • 3-24148-LargeDDs.zip
    3.1 KB · Views: 130
Servus Zoltán,
A very useful
Thank you,
Adrian
PS As you may have noticed in my edited post, ISTDATA2 was mistyped to ISDATA2; it should read ISTDATA2.
No problemo, it could happen to anyone :)

B732.1 SP12.2, Oracle 806
Xe U3 SP17, Oracle 8i
FormScape 2.1
RS/6000, Citrix
 
Adrian,

you are wright, I did a mistake. Sorry !

Christian

Implementing B7333 (Xe) SP14.1, SQL
(Support B732, B7331 and B7332)
 
Christian,
As I was replying to Zoltan, no problem; it could happen to anybody, really!
Keep the good work going; "L'important, c'est la rose ... " ... crois moi.
Thanks again,
Adrian

B732.1 SP12.2, Oracle 806
Xe U3 SP17, Oracle 8i
FormScape 2.1
RS/6000, Citrix
 
Back
Top