SDS Version numbering in CG36 and Test scenario for subsequent shipping

[Former Member]

Dear Experts,

I have couple of questions regarding SDS upload and SDS Subsequent shipping,

1) Document versions in CG36 for Inbound SDS:

In this case, the SDSs are Inbound pdf documents, and the  mass upload transaction CG36 is used to upload them to the Report Management.

I'd like to maintain the difference between major change and minor change in the versions of the SDSs when using CG36.

However, unlike with CG36VEN where the version number is given manually during the upload,

transaction CG36 inserts an equal version change for all inbound documents, ignoring the version number (=VER) stated in the Key file. 

So to me it seems that in CG36, the version number stated in the Key file is ignored by the system standard. Is there some change i could do in the configuration to make the version number stated in the Key file become picked up as an actual version number for the document?

2) SDS subsequent shipping. F.ex shipping after one year from the first shipment to the customer:

How have you tested this scenario during the implementation, in a situation where the test environment does not contain sales orders dating back one year? F.ex. have you temporarily changed the period between first and subsequent shipping into two weeks or two days etc.?

Where in the configuration can you change this time period?

Many thanks in advance!

[dhinsap]

Dear Palin,

1. The system assigns the version number itself and does not consider any other numbers.

2. Please check the document below for subsequent shipping.

http://help.sap.com/erp2005_ehp_04/helpdata/en/a7/2878600a6c11d28a220000e829fbbd/frameset.htm

Regards

Dhinesh

[christoph_bergemann]

Hello

a.) "old" problem. Reason is that there is a "misinterpretation" of how CG36/CG36VEN can be used and how it is related to CG50/CG54.

Shortly: Version number in key file is ignored according to your findings. From point of view of EHS: this version is of no interest; EHS SDS shipments starts from "scratch"; there is no chance to have reference to e.g. any legacy system which was in place before using the "old" number

Frankly: Don't try to touch this EHS behaviour; you will get more problems in comparison to the result

b.) this is more complex; there is no general answer available; I would assume some companies try to use "debug and replace" to "fake" the data some others generate reports/transaction which change the data in database. If I remember correct: the period is "hardcoded" in the function module used for subsequent shipment (as e.g. in europe you have different rule in comparison to US).

C.B.

Check: http://help.sap.com/saphelp_trbk30/helpdata/en/a7/2877900a6c11d28a220000e829fbbd/content.htm

Chapter "Report Shipping Order Checking" and subchapter:

Standard Check Function for Validity Area USA

or

Standard Check Function for Validity Area European Union