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

UPD: в таблицы логирования можно добавить текстовое поле "Причина", в которое оператор будет записывать причину изменения статуса, но это, опять же, зависит от бизнес-процессов предприятия.

DBpr0ger,

Как-то так:

Код_клиента надо заменить на реальный код клиента. Чтобы передать код клиента в строку, существует несколько вариантов и всё зависит от того, как и где эта строка будет использоваться. Можно через конкетанцию текстовых строк и вызова через docmd.runsql, либо через Recordset, либо через вызов запроса.

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

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

Это ты у кого и про что спрашиваешь?

Посылка у тебя всегда одна, меняется только её статус на "возврат отправителю", менять отправителя и получателя нельзя, так как это противоречит логике. В базе, проще говоря, создаётся документ "накладная на возврат" и этот документ будет фигурировать при возврате посылки отправителю.

Не надо. Можно сделать в таблице "Отправления" три поля с датами: Приёма, выдачи и возврата, но правильней будет, дату перенести в таблицу логов (движения посылки), то есть, поле с датой всегда будет одно. Это слегка усложнит запрос, когда надо будет вывести все посылки с определённой датой возврата, так как нужно будет использовать две таблицы, но зато в таблице "Отправления" не будет пустых значений в поле "дата выдачи" или в "дате возврата".
Можно не вводить поле "дата возврата", а использовать "дата выдачи" как дату возврата и это логично, так как предприятие посылку выдало, но только отправителю и статус "возвращена" это будет подтверждать.
Фактически, поставленную задачу можно решить с помощью двух таблиц: клиенты и отправления. Можно не вести таблицу логов, а просто менять статус посылки на нужный. То же самое и с чёрным списком клиентов - просто менять статус клиента в таблице клиенты. Логи нужны только тогда, когда нужно вести учёт движения посылок во временном разрезе.