当我母亲给我命令从农民穆勒那里购买牛奶时，我实际上不应该去超市购买纸箱牛奶。

如果您在自动高架存储中指示系统，则非常相似。

只有人类可能会记得他们在其他地方看到过该文章，但他们不知道该文章在其他存储中是否最终不会保留给其他订单。

订单是一条指令，如果订单上基本上说"去那里拿这件物料"，而工人去了那里并且没有任何物料，那么他要么无法确认此订单，要么他用0零零地确认它 在那里，所有TO数量过帐到差异。

由于系统中的库存显然不等于仓库的实际情况，他将订单退回办公室，主管将分析情况并最终创建新订单，甚至发起实物库存。

我不会开发额外的程序或进行修改，以允许在特殊情况下确认存储类型的更改，因为我只能预见到比目前已经更大的混乱。

目标收件箱可以在确认期间更改，仅适用于"入站"，但您的查询似乎是出站的，因此，我确定这是自定义RF事务，并且您的要求是在出站期间更改源存储类型，因为目标存储类型是固定的 （916）在出站期间

系统建议将一个完整的托盘存放到XYZ型，该类型仅适用于完整的托盘-如果用户发现存在少于托盘装载量的货物，他应予以确认。 触发库存以对该垃圾箱采取纠正措施。 创建另一个转储单，系统将遵循完整货盘和部分货盘的逻辑（我确定部分货箱仅带有一个储物箱，下次您将在储物箱中找到全部存货，如果没有） 则说明上架过程存在严重问题）。 按照仓库的最佳做法，我认为无需更改源存储类型

在确认期间，用户在托盘中仅发现9个箱子。 因此在此系统中，不允许用户使用部分货盘确认TO -在您未进入与数量和数量相关的系统之前，系统如何知道它是部分货盘 在自定义程序中有一个签入可以验证整个托盘数量，您需要在程序中查找您的自定义逻辑

您好jurgen，

我理解并同意您的发言。

但是，我们实时面临这样的挑战，我们必须为此类特殊情况提供解决方案。

让我们假设系统为存储类型XYZ提议一个完整的托盘，该类型仅用于完整的托盘。

在TO创建系统中，建议将具有10个箱子的完整托盘提议为XYZ存储类型，但是在TO确认期间，用户在托盘中仅发现9个箱子。 因此在该系统中，由于专用于完整托盘，因此不允许用户使用部分托盘（9个盒）确认TO。

因此，要处理此类异常情况，我们必须准备好一些解决方案。

希望您已经理解了我的问题，并且希望您对此感到信服。

致谢

阿比