Skip to main content
boermansdigital
Open menu

Process exampleMFT

The file was sent, but not processed: what next?

The transfer shows a green tick, but the receiving team cannot see any new orders. Sending the file again seems reasonable. Yet some records may already have been processed. First establish which part of the chain the green tick actually describes.

An original working example or decision framework, not a customer result or technical certification.

Agree what each status means

Define sent, received, accepted and processed. A file may be on the correct server while the import task has not started. An import may also accept only some records. Identify the system that confirms the business outcome.

Use a traceable reference that lets both parties identify the same delivery. A filename may be insufficient if reused every day. Compare the version, timestamp and expected contents rather than relying on the name alone.

Four checkpoints in a fictional order flow

The available signals depend on the implementation and agreements.
CheckpointPossible evidenceFollow-up owner
TransportTransfer result and timestampTransfer administrator.
ArrivalCorrect destination and identifiable file versionReceiving environment administrator.
ValidationFormat and required-data checksOwner of the import requirements.
ProcessingAccepted and rejected records plus business confirmationReceiving application or process owner.

Find the last confirmed stage

Start with the delivery reference and compare timestamps. Check time zones and whether processing was due to have completed. Then examine queues, rejections and partial results. Do not draw a conclusion from the most recent dashboard alone.

A format mismatch needs a different response from a task that has not started. Retain the original version for authorised investigation under the retention policy. Share only the information the relevant administrator needs.

Do not resend blindly

Establish which records have already taken effect before resubmitting a delivery. Some imports recognise repeated instructions; others do not. Replacing a file on disk does not automatically reverse business actions already performed.

Agree who authorises resubmission and how it is distinguished from the original delivery. Have the receiver confirm the intended result. Reconcile accepted and rejected totals again afterwards.

What belongs in the handover agreement?

  • Expected delivery and processing times.
  • The meaning and sender of each confirmation.
  • A contact and cover during absence.
  • A path for partial processing and corrections.
  • Access and retention rules for files and logs.

Detect missing expected deliveries too. No error message may mean that nothing started at all.

Start with one identifiable delivery

Map the systems, handovers and available confirmations for a single delivery. This often reveals gaps in evidence or ownership. An MFT platform can support transfer operations, but business processing still needs explicit agreements with the receiving application.

What would you like to clarify?

Describe the process step or open question. We can explore a practical next step together.

Discuss your process

Explore your file transfers with the MFT Scan