您好

在您的开发系统中，通常开发人员如果创建TR，则在这种情况下，必要的更改已经完成。 因此，删除对象还是删除TR实际上是有意义的，因为您知道如果进行任何升级，它将检查未释放的对象，因此，出现了删除不必要的TR的情况。 因此很明显，如果将TR移至QA或Prod，则意味着TR已处于释放状态，这意味着对该TR不再进行任何更改。

如果在多个TR中记录了相同的对象或相同的更改，上述实践也可以改善这种情况。

从安全的角度来看，如果您有单独的安全团队，那么我认为您宁愿 可以向他们咨询他们的要求

谢谢

考施克

这是错误的内容。 您想在BC-CTS-TMS组件"传输管理"中提出这个问题。 不是运输管理（物流与供应链）。

马塞洛，

通常，最佳实践是从不删除任何运输工具，并始终将所有运输工具移动通过景观， 否则，您就有可能使DEV系统与PRD和QAS系统不同步，并可能导致配置设置出现各种问题。 我应该知道，就像我们在自己的组织中遇到的那样。

实际上，我们都知道有时会有空的运输工具无用，而且什么也没改变，而移动空的运输工具多少有些 无意义的。 在这种情况下，如果它确实是空的，那么确保删除它没有危害。 但是，为确保在执行此操作之前已对它进行了适当的调查，我强烈建议您使用授权来限制谁可以删除传输，只有您自己和/或传输管理团队才能执行。 不允许开发人员和配置人员删除自己的传输。 在执行此操作之前，使它们跳过几圈，然后再看一眼。

从传输中删除对象以使其变空的风险更大。 如果对象在运输中，则多数情况下是因为对该对象进行了更改，因此您绝对需要确保此更改在整个景观中保持一致。 如果以后发现不想更改，请然后必须撤消DEV系统中的更改，并在同一传输中记录该撤消，或者如果传输已被释放，请在

在这种情况下，如果您在相同的传输方式中记录了还原到原始传输的内容，您可能会认为"现在一切都一样了，因此我可以删除此传输方式 而不是释放和移动它。" 可能是正确的，但我强烈建议不要这样做，因为有时可能会遗漏某些东西，而并非所有内容都还原为原始内容。 最好将传输转移到您的QAS系统，然后进行测试以确保一切正常进行。

总结一下：

• 不允许您的DEV团队 删除传输，也不从传输中删除对象； 仅在进行了非常仔细的分析之后，才应执行基础操作。
• 如果更改已还原，请在传输中记录该还原（可能与原始更改相同），然后像往常一样在景观中移动所有内容。 这是唯一可以确定的方法。
• 不允许未释放的传输永远在DEV中失效。 当顾问或其他人离开项目或团队时，请他们通过释放他们或将他们重新分配给其他人来清理他们的运输工具。 实际上，这很难执行，但是您至少应该尝试。
• 类似地，不允许未经批准的传输永远在您的质量检查工作清单中消失。 对它们进行测试和批准，然后将其分配给PRD发布。 如果未批准它们，则不要拒绝它们，而是创建一个具有修复（或恢复）的新传输并将其向上移动，然后再次进行测试，然后将所有内容一起移至PRD中。

欢呼声 ，
Matt

如果要跟踪更改，最好的解决方法是激活SCU3中的表日志记录。

https://help.sap.com/doc/saphelp_nw70/7.0.31/ zh-cn/c7/69bcd2f36611d3a6510000e835363f/content.htm？no_cache = true

嗨Marcelo，

请注意， 通知Kaushik您答复的一种方式是，如果您的答复是直接在其答案下的"答复"或"评论"，而不是对您问题的新答复。 我已更改了您对您的评论的答复，因此这里无事可做。

我还为您的问题"软件物流-更改控制和运输"添加了一个附加标签，该标签 直接与有关STMS和运输的问题有关。 另外，您会注意到，另一个主持人更早地更改了原始标签，因为正如约瑟夫所说，"运输管理"与SAP管理卡车车队等功能有关，而不是与在SAP环境中运输变更有关。

干杯，
Matt Fraser
SAP社区主持人