cancel
Showing results for 
Search instead for 
Did you mean: 

997 Ack from Client

former_member237514
Participant
0 Kudos

Hi all,

I am new to B2B addon's ,

I have one doubt regarding 997 acknowledgement generating.

I have scenario like client will send EDI850 mesg --- PI --- ECC,then next From ECC -- PI--- client  will send 997 regarding EDI 850 and next will trigger 855 and 810 mesg to client .Then client will generate 997 (855,810) -- PI --- ECC.this the scenario. for this I am maintain 2 scenarios.

1st scenario for incoming EDI850 mesg to PI to ECC:

flow 1:client (as2 channel)------PI------Edi separator(997 required)

flow 2:Edi separator -------PI------------ECC(IDOC)

flow 3:Ediseparator--------PI-------------AS2(997 mesg to client)

2nd scenario for outgoing EDI855,810 to client.

IDOC------PI------AS2(855)

IDOC------PI------AS2(810).



My doubt is:


1st scenario it self i am picking the data from client using AS2 channel for either EDI 850 or 997  and i put the 997 as required in Receiver EDI separator channel for 1st scenario in 1st flow. so when ever client will pass edi 850 i will generate 997 to client regarding edi 850.


so some times client will generate 997 to us for related edi 855 and 810. this 997 will pick 1st scenario 1st flow through AS2 channel then it will pass to Receiver  Ediseparator channel , but here receiver ediseparator channel i maintain as 997 as required under ANSIX12 tab .so again 997 will generate to client ??? or it will skip the process or it will wont work ???



please clear my doubt.


Thanks

Kavitha



Accepted Solutions (0)

Answers (1)

Answers (1)

former_member213558
Active Participant
0 Kudos

Hi.

you can suggest you customer to stop sending 997 for your 855/810.

do you want to consider 997 at ECC level? if yes find the case 1, else case2 and case 3 are optional.

case 1.

usually inbound 997 required to reconcile at ECC end for outgoing message 855/810 accepted/rejected through inbound 997. you can create a RFC for inbound 997, and finally your scenario will be.


for 855 --> IDOC------PI------AS2(855)


for 997 --> AS2 - > EDISeparator

                  EDISeparator -> RFC


so create a EdiSeparator sender channel for inbound 997 and fill only receiver IDs.

note: pass your IDOC number in GS06 element, and you'll get the same in inbound 997, so based on  IDOC# you can store the status in RFC, and do study on 997 transaction set that will helps you.

2. case 2.

pass your inbound 997 and to server and create batch program  to delete the 997 file every day.

for 997 AS2 - > EDISeparator

            EDISeparator -> File


3. using TPM you may achieve this issue, but i'm not sure. lets wait for others comment.


former_member237514
Participant
0 Kudos

Hi Ramesh,

Thanks for giving reply.

Based on ur answer i understood like we need to say to client to stop the sending 997 to us is it right??

next we need to consider 997 at ECC level then only we know that what ever we send data to client that  data is accepted or rejected .

if we use Even RFC also it will execute 2 flows right for incomeing as2 mesg.

for 997 --> AS2 - > EDISeparator(here i need to maintain 997 required )

                  EDISeparator -> RFC



FYI .I am using single AS2 Channel for picking the data from client then using Sender Ediseperator i am splitting the EDI mesg's.



Thanks

Kavitha

former_member213558
Active Participant
0 Kudos

Based on ur answer i understood like we need to say to client to stop the sending 997 to us is it right??


you are right.



and your scenario will be as you said.


for 997 --> AS2 - > EDISeparator(here i need to maintain 997 required )

                  EDISeparator -> RFC (i.e here you maintain only receiver ID combination and version combination.)


since you selected 997 required in receiver 997 channel, it'll start find the 977 sender channel and the receiver channel is REF (ie your second ICO).


note: fill only receiver ID parameter in  your ediseparator (for 997) channel.


for outbound 997 receiver id is your trading partner ID, and inbound 997 receiver id is your customer ID.


former_member237514
Participant
0 Kudos

Hi Ramesh,

Thanks for giving reply.

if we inform to client like  stop to sending 997 to us .they will nt accept y because how to we know what ever we sent 855,810 mesg's their accept or rejected that details client will  send through  in 997 only right.

i have no problem when i select Required 997 in Receiver Ediseparator in 1st Flow .with out select that option we cant send 997 to client right??

here my problem is if client will send 997 to us i mean to PI .it will execute 1st flow right

like AS2(997)-------PI-------Ediseparator(997 required)

in that flow again one more 997 will generate to client ??? y i am asking means ediseparator we select  Require 997 .

former_member213558
Active Participant
0 Kudos

in that flow again one more 997 will generate to client ??? y i am asking means ediseparator we select  Require 997 .

in your first ICO if you selected "997 required" then it start finding the 997 channel based on your sender/receiver ID. then point it to receiver channel as RFC/File. in this way you can avoid sending 997 against your inbound 997. 


like AS2(997)-------PI-------Ediseparator(997 required)

Ediseparator (997) --> RFC/File


note: fill only receiver ID parameter in  your ediseparator (for inound /outbound 997) channel , transaction set and version . rest of all use wild characters. like below.


for outbound 997 receiver id is your trading partner ID, and inbound 997 receiver id is your customer ID.

former_member213558
Active Participant
0 Kudos

did you resolved this issue? do let me know further.

Former Member
0 Kudos

You should not ask the client to stop 997 because of this technical issue. 997 is always recommended unless your business specifically says it is not needed. It is better to receive 997 in PO and ignore if not needed.

You should have a dedicated scenario for receiving 997s and disable 997 for a 997 there.

sM