cancel
Showing results for 
Search instead for 
Did you mean: 

XML For /SAPSLL/CUS_CTAX02 & /SAPSLL/CCECUS02

dean_hinson2
Active Contributor
0 Kudos

Hello,

To make it easier for one of our brokers to communicate to our GTS system for imports, we want to use XML for /SAPSLL/CCECUS02. Based on the discussions in this forum, doesn't seem to be a big issue. However, to keep development costs down with the broker, we are thinking of using the same XML for communicating the tax information. There is already a discussion that using /SAPSLL/CCECUS02 for updating the tax information in GTS. It is NOT standard and development is required. Maybe not what we want in order to keep the tax data consistently stored across legal regulations in GTS. So, here is my thought...

Can we use the data from /SAPSLL/CCECUS02 and build /SAPSLL/CUS_CTAX02 without a huge amount of development?  I believe most of the data is there but I have not done a simulation in order to determine the required fields in each segment.  Do you know if this information is available? If so, can you share?

Please let me know your thoughts.

Regards, Dean.

Accepted Solutions (1)

Accepted Solutions (1)

former_member215181
Active Contributor
0 Kudos

Hi Dean,

I'm not sure it would be worthwhile translating one iDoc into another.  With probably less complexity, it might be better to define a separate Process Code and build a new Function Module to process the CCECUS iDoc data into the ECC_CTAX_S structure - a hybrid of Function Modules /SAPSLL/IDOC_INPUT_CCECUS and /SAPSLL/IDOC_INPUT_CTAX.

Provided you can separate the two sets of data (perhaps by having the Broker send to different addresses of including some identifier in the message header), you should then be able to process them separately and correctly.

On the other hand, you'll probably find that once the Broker "gets the hang of" transforming his data into an iDoc format, he'll pretty quickly be able to produce the second mapping once he's done the first.  So he may quote you 20 days development for the CCECUS iDoc, but then only need 2 more days to produce the CTAX version.

To answer your final direct question; the iDoc definitions are in the system - Transaction WE60 holds them.

Hope that helps.

Regards,

Dave

dean_hinson2
Active Contributor
0 Kudos

Hello Dave,

Maybe your right, but for the broker (in a non-SAP system) developing code for handling XML is much easier that iDOC. To/From SAP, yes. iDOC is the way to go but XML to iDOC should be what is done for non-SAP to SAP.  Just my opinion.

So, I will put together information of the /SAPSLL/CUS_CTAX02 and see if I can convince the broker to do additional development.

Regards, Dean.

former_member215181
Active Contributor
0 Kudos

Hi Dean,

Ok, how do you plan to convert the incoming XML data into an iDoc for GTS?

Regards,

Dave

dean_hinson2
Active Contributor
0 Kudos

Hello Dave,

We have a department/tool which handled EDI mapping. I will provide the mapping from XML to iDOC. What are your concerns?

Regards, Dean.

former_member215181
Active Contributor
0 Kudos

Hi Dean,

I suppose I hadn't really understood your plan (from your first posting here).  /SAPSLL/CCECUS02 is an iDoc structure, not an XML schema, and that confused me.

I guess what you're saying is that you (or your broker) intend to create an XML schema based on the structures of that iDoc, and then would want to use the SAME schema for the Tax Statement.  In that case, you forsee an easy mapping for the Declaration message, and a potentially more difficult one for the Tax Statement.  Have I got it right now?

If I have, I'd guess that it would be marginally less work for the broker to create an additional XML schema than it would be for your guys to cross-map the Tax Statement.

From a brief look at the CTAX structure, there would certainly be some quick wins - for example, the Date, Address and Text structures - but some much more tricky ones as well.  Of course, it greatly depends on the complexity of the data being sent.  If your CTAX messages will be simply a set of amounts (for Duty and Tax) then mapping might be easy, but if some of the more complex segments are needed (like Guarantees, Duty Rates, Payment Methods, etc.) then your guys might have a hard time finding suitable place-holder fields in the CCECUS structure.

Probably I can't add much more.

Regards,

Dave

Answers (0)