Андрей VG, если возможен вариант только с отсечным временем, тогда поставьте 1 мин.

Спасибо!

Андрей VG, как и обещал данные для тестирования
https://cloud.mail.ru/public/9MBj/DLrwD34hR

При данной сортировке время 14:47:01 действительно идет в следующей партии, но склад № 9, а в запросе № 8. Т.е. необходима следующая партия по складу № 8.

завтра вышлю кроликов))
несколько сотен тысяч позиций по более чем 40 складов

Вот пример. Необходимо проверить каждую ошибку на странице запросы, в желтых столбцах проставить ответы: да или нет.
https://cloud.mail.ru/public/4R3C/i9whgEG62

Возможно моё упущение, поэтому попробую сначала.
Товар сканируется партиями (на картинке в исходных данных слева партии обозначены различными цветами). Одна партия имеет одно значение даты и времени, в одной партии может быть как один товар так и множество. Строка справа - это товар, который отсканировался с ошибкой и не был зарегистрирован. Как мы видим по картинке ошибка произошла  по времени между голубой и оранжевой партиями. Как показывает практика оператор обнаруживает ошибку и сканирует товар в следующей по времени партии после ошибки, т.е. при таких обстоятельствах товар должен был попасть в оранжевую партию. Однако, этого товара там нет. Это мне и необходимо проверить. Другие партии проверять не надо, интересует только вопрос - есть ли товар в оранжевой партии?

Следует учитывать, что складов и цехов может быть множество. Необходимо проверить обозначенную мной "следующую партию" именно по тому складу цеху, где произошла ошибка.

Что касается временной привязки "следующей партии" - по-разному: время может совпасть с временем ошибки (поэтому я и просил чтобы искало точное совпадение), либо может пройти 1 сек, или 5 сек, или 23 сек и т.д. В случае, когда после ошибки прошло некоторое время, решающее значение имеет фактор того, что партия должна быть следующей по времени после ошибки на этом же складе и цеху.

Андрей VG,ваш вариант очень не плох!!! Для меня главное, что нет ошибок по позициям которые реально не были отсканированы в ближайшей партии. Общее количество наименований товаров около 10000 и вероятность того, что такой же товар попадет в ближайшую партию по другому складу и цеху ничтожна мала.

Я писал ранее, что ближайшее при точном совпадении склада, цеха. Объясню суть процесса: на каждом складе и цехе товар сканируется на сканер партиями. У каждой партии есть время, в партии может быть как один товар, как и много. Запрашиваемый данные - это товары, которые отсканировались с ошибкой. Практика показывает, что оператор, в основном, обнаруживает ошибку и сканирует товар в ближайшую партию. И необходимо узнать - попал ли товар в ближайшую партию именно по запрашиваемому складу и цеху или нет. Т.е. не среди всех складов и цехов, а именно в запрашиваемом складе и цехе.
Объяснил как мог.

Андрей VG,вы очень близки!!!!
Сверил все позиции вручную, погрешность около 8-10% (это лучший результат).
Желтым цветом выделены ошибочные позиции. Все ошибки в строках где ответ "нет".
https://cloud.mail.ru/public/KB42/32ZCGk3S7

Ребята, всем большое спасибо за участие. Я так понял, что задача наверное тяжеловата для таких объемов данных.

Андрей VG, в вашем случае проверяется весь день.
А мне необходимо чтобы проверялось только время последующее после запрашиваемого.
Например время запроса 14:00:23, проверить надо только то время, которое идет следующим после 14:00:23, в нашем случае это 14:00:27, там две позиции, среди которых нет необходимого нам товара.

Андрей VG, начал проверять правильность результатов в нашем примере. Проверил первые две позиции, результат неправильный.  

Андрей VG, если не сложно, поясните мне, как работать с новыми исходными и запросными данными в вашей версии.
Хочу проверить как она работает. Я должен просто вставить новые данные и результат автоматически проставится?
Или какой-то другой алгоритм?  

БМВ,вставляю большой объем данных, все равно промахивает.
может влияет как выводятся данные в столбце дата и время? потому что дата и время идут по возрастающей от раннего к позднему, но только до тех пор пока не начинается новый склад. С нового склада время опять начинается с утра.

приложил

Вставил большой объем данных, промахивает. По многим позициям не дает результат.
Файл не могу приложить, т.к. 7 Мб.

К сожалению весь объем данных не смог уместиться в 100 кб, т.к. это несколько сотен тысяч строк.
Немного сократил. Желтым отмечен неверный результат, который находится в 67 строке.

Кстати, после того как сократил объем данных, по многим позициям результат поменялся на правильный. До того практически везде стоял результат "нет".

БМВ, к сожалению все равно ставит результат "нет".  

пока работает вариант от tolstak, сообщение № 11.

Но около 20%-30 % промахивает

Этот вариант также промахивает, ставит ответ "нет"

нет, не корректно, практически везде ставит ответ "нет"

в примере ближайшее время выделено желтым цветом.
Под ближайшим временем понимается время, ближайшее после искомого. Оно может занимать как одну строку (если товар один), так множество (если товаров много, как в примере).

Интересует только одно время, ближайшее после искомого.
В нашем случае необходимо проверить только время 18:53:34,  а 18:55:48 - уже не интересует.
Если бы под этим временем был бы один товар, то проверять надо было бы только одну позицию.
В нашем случае товаров в одно время несколько - поэтому и проверить надо все товары под временем 18:53:34.

Извиняюсь, может что не сразу, все пояснил. Надеюсь это прояснит картину.

Спасибо!!!

БМВ, все равно работает не корректно.

На этот раз я убрал искомые позиции. По одной из позиций результат "да", а должен быть "нет".

БМВ, данную формулу изначально предлагалtolstak, я писал, что она не работала
Для подтверждения я умышленно вставил искомые значение в 360 и 367 строки, чтобы проверить. Результат "нет", а должен быть "да".

tolstak, предложил вариант с округлением, это оказалось эффективнее, однако все равно не точно, некоторые позиции пропускает (есть предыдущий пример).

Приблизительно вот так, товары представлены в виде цифровых кодов

В общем, тестировал целый день. Процент попадания улучшился, однако все же большая погрешность. В переделанной версии большое количество товара определяется как перемещенный в ближайшее время, т.е. результат "ДА", хотя при просмотре вручную он там отсутствует.  

Извиняюсь, не увидел ответа.
Сча, проверю по новой схеме.

Подскажите, а что может быть не так? Часть товаров при проверке по ближайшему времени пропускает. Допустим искомые данные склад 100, цех 1, товар нож, время 01.01.2018 12:00:00. Дает результат: нет. А на самом деле при просмотре вручную есть такой товар на таком же складе и цеху в ближайшее время 01.01.2018 12:00:01. Т.е. должен быть результат "да".

tolstak, большое спасибо!!

однако работает не совсем как хотелось.
Когда проверяет ближайшее последующее время некоторые товары пропускает. Для уточнения: одновременно должны совпасть и склад, и цех, и товар, и ближайшее время.