cancel
Showing results for 
Search instead for 
Did you mean: 

Inputs needed Duty rate maintenance issues

Former Member
0 Kudos

Hi All,

I have identified an issue in my system. Which is related to the query which i had posted already http://scn.sap.com/thread/3406547

We have identified a tariff code say A which was defined as a folder in the hierarchy since 01.01.2000 till 30.06.2011. Later there was a stucture change in EU union.So as of 01.07.2011 this tariff item is no more a folder.

So, in our system we have same tariff code(CTSGEN/CTSNUM) "A" 2 times. One is defined as a folder and expired(Validity date as 01.01.2000- 30.06.2011)

and one another tariff code A as a item(CTSNUM) with validity date as 01.07.2011-31.12.2999.

When the XML file with duty rate is sent by our data provider , they send the validity period of this tariff code as 01.01.2000- 31.12.2999(Consolidating the validity of 2 different tariff items). Which leads to inconsistent data and the xml upload transaction is not throwing an exception.

But when we try to do this manually, we get an error. So, following are my questions. Will be great if someone can help me on this.

1) Should we have deleted the expired folder tariff and then created a new one as a item when there were changes in the structure?

2) Should the data provider correct the xml file by sending the validity period correctly as (01.07.2011-31.12.2999) or is there a way to handle this?- Either they should split into 2 entry. one with 01.01.2000-30.06.2011 and 01.07.2011-31.12.2999

3) Is it actually possible for system to consolidate the validity of 2 different tariff items and let maintenance of duty rate. I believe this is not possible, though we see the Tariff code as A externally. Internally there are 2 different GUIDs.

4) Is the XML upload transaction capable of catching this exception in higher version of GTS.

We are on GTS 8.0.

Thanks in advance for your help.

Regards

Dhilipan

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member215181
Active Contributor
0 Kudos

Hi Dhilipan,

I'm slightly confused by your explanation.  As far as I knew, an entry can either be a "folder" or a code, but cannot be both.  For example, 12345000 might be a folder, holding codes 1234500010 and 1234500020.  That's the normal arrangement.

And I thought that table /CTSGEN contained the folders and /CTSNUM contained the codes, so that there shouldn't be any confusion between the table entries.

Have I misunderstood your situation, or am I wrong in my understanding of the data arrangements?

As for what to do - that's not so easy.  If you have (or are) a good developer and have have no other way forward then my suggestion would be to delete the relevant codes, after noting the GUIDs, then hopefully you can re-load the XML files without a problem.  After that, re-classify the relevant Products (perhaps write a program if there are many), and then programmatically amend the values in table /CORCTS (or /CORCTSC, if country-specific) to link to the new GUID so that the history is not destroyed.  But that should be a last resort.  First, try to fully understand what is happening in the system.  Perhaps your Data Provider can assist?

Regards,

Dave

Former Member
0 Kudos

Hi Dave,


Thanks for your response.

Even i was of the same opinion as you said(CTSGEN for folders and CTSNUM for Tariff items). But the official situation is something different. I should have pasted this structure earlier for your better understanding.

Till 30th June,2011- Below was the official situation in EU.

You find Tariff 3901 9090 91 as folder and as a tariff item. They do have different GUIDs though.

- Folder 3901 9090

- - Folder 3901 9090 91

- - -  Tariff code 3901 9090 91

- - -  Tariff code 3901 9090 92

- - -  Tariff code 3901 9090 93

- - -  Tariff code 3901 9090 94

- - -  Tariff code 3901 9090 97 

- - -  Tariff code 3901 9090 99

Later from 1st July,2011 this is the change in structure.

- Folder 3901 9090

- - Folder 3901 90 90 80

  - - -  Tariff code 3901 9090 80

  - - -  Tariff code 3901 9090 82

  - - -  Tariff code 3901 9090 91

  - - -  Tariff code 3901 9090 92

  - - -  Tariff code 3901 9090 93 

  - - -  Tariff code 3901 9090 94

  - - -  Tariff code 3901 9090 97

  - - -  Tariff code 3901 9090 99

So. if you see the above case, when the latest structure was updated with the xml from data provider. The earlier tariff folder and the respective item was expired by changing the validity date to 30.06.2011 and later the new structure with 1st July,2011 was updated.

So, now we have both in our system.

CTSGEN- Has one expired Tariff folder- 3901 9090 91

CTSNUM- Has one expired Tariff item- 3901 9090 91 and one valid tariff item 3901 9090 91.

But all these 3 has distinct GUIDs in the table.

And as you said, my last option was deleting the entry from the table via debug mode

But my confusion is this is a right kind of data structure provided by our providers. When i checked with them, it seems they follow the same for everyone. Any idea how do you handle this kind of scenario. Should the old expired tariff folder deleted before we update the new one?

And the major problem here is the nomenclature/structue of Duty rate and Tariff xml files are different.

So, for Tariff code 3901 9090 91 though the validity had changed there is no change in duty rate. Hence, data provider sends the duty rate with validity (01-01-2000 to 31.12.2999). Whereas, the validity in tariff master is 01.07.2011-31.12.2999.

This is actually leading to problems which i mentioned earlier. Thank you in advance for your suggestions/guidance.

Regards

Dhilipan

former_member215181
Active Contributor
0 Kudos

Hi Dhilipan,

Thanks for that further explanation.  Now I can understand what is going on.

In the Tariff, those codes all sit directly under Heading 3901 - that's to say; the folder 39019090 doesn't exist there.  It seems that your Data Provider is grouping codes following the descriptive logic, and inventing the higher-level (folder) codes.  That's ok, and probably convenient for the users when classifying Products, but it leads to the situation that you describe.

As far as I can tell, you end up with a technically-valid data-set, but with some Products that are now not classified.  Your products with classification 3901909091 are technically not classified after the end of June 2011, and need to be re-classified with the same Tariff Code under the new GUID.

Currently those products would not appear in the Classification Work-list, and that "gap" is covered under my suggestion on the "SAP Idea Place", which you can vote for if you agree:

https://ideas.sap.com/ct/ct_a_view_idea.bix?c=E8A286DD-A6EF-43F9-9371-CD3ECCDD63AA&idea_id={B99A43CD...

Meanwhile, you should be able to re-classify the Products by selecting in the Product Catalogue and choosing the same Tariff Code.  You might need to create an additional entry in the Duty Rates table /LC_CUSB1, if the Data Provider didn't already provide it.

Does that help, or have I missed part of the problem?

Regards,

Dave

Former Member
0 Kudos

Hi Dave,

Thank you so much for your response.

I agree with the classification issue. That was another problem which was part of this issue. But we were able to manage it with the manual classification. I have promoted the same in Idea space.

I agree with your approach and infact did that already in the system sometime back. I mean duty rate with 2 different entries one for 01-01-2000 to 30.06.2011, another one for 01-07-2011 to 31-12-2999

But the problem here is when there is another new upload of Duty rate via xml the same get replaced by the incorrect entry sent by Data provider. And the Data provider is not ready to change it.

So, i believe the only option here is to manually update everytime after the xml upload of duty rate

Thanks

Dhilipan

former_member215181
Active Contributor
0 Kudos

Hi Dhilipan,

It occurred to me that, since the GUIDs are not supplied in the XML file, the relationship between the Duty Rates and the Tariff Codes must be determined in the upload program.

And, from what I can see, the EXSID field is used for that determination, with the assignment favouring "older" entries.  So you could try changing the EXSID value (in debug) on the old entry in /CTSGEN to see if that makes a difference during the Duty Rate upload.  The EXSID value should not be needed to support the old Declaration documents, since the Tariff Codes there have already been determined.  And I'm assuming that the Tariff Code itself will not be referenced in a new XML file until / unless the it is expired or again re-arranged in the Tariff structure.

I wonder if that helps at all?

Regards,

Dave