This article explains messages you may see that mention the batch changing, timing out, or already being busy with something else. It is for property managers, building staff and board members. More...
Last updated
This article explains messages you may see that mention the batch changing, timing out, or already being busy with something else. It is for property managers, building staff and board members. More than one person at your property can have the same import batch open at the same time, and background work keeps running even after you close the drawer. Before URBI writes anything, it checks that nothing has moved under you since you last looked. Being refused here is the system protecting your building's records, not a mistake you made. For each message below, this article says plainly what to do and, equally importantly, what was and was not written.
What it means. Something about this batch changed between the moment you loaded it and the moment you tried to act on it. Your action was not carried out.
Why it happened. Someone else at your property, or a background task, changed the batch's bank debit attestation while you had the page open.
What to do.
What it means. You tried to upload a bank details file, but the batch had changed in the meantime. The file was not uploaded.
Why it happened. The batch changed between when the page read it and when your upload was sent.
What to do. Reload the import, then upload the file again.
A refusal message with its refresh guidance, as it appears on the Review step.
What it means. Your bank details upload was sent, but URBI has not yet confirmed whether it finished processing. Nothing is confirmed lost or confirmed saved yet.
Why it happened. The background task that stages the uploaded rows did not finish inside the time the page waited for it.
What to do. Reload the import to see whether the rows landed before you try uploading again.
What it means. The same kind of wait, shown on the units-matching step rather than the upload step. The page is still checking in the background.
Why it happened. The staging task returned before it was finished.
What to do. Wait a short while. If nothing appears, reload the page.
Each of the following appears when a specific save did not finish inside the time the page waited for it. In every case, the save may still complete in the background; the message means "we do not know yet," not "this failed."
What it means. Your changes on the units and payer resolution steps were sent, but confirmation did not come back in time.
Why it happened. The task that applies your resolutions did not settle before the page's wait ended.
What to do. Try the same action again.
What it means. Your Launch settings, such as the fee start date or start period mode, were sent, but confirmation did not come back in time.
Why it happened. The launch-settings save task did not settle before the page's wait ended.
What to do. Press Continue again.
What it means. Your bank debit consent choice was sent, but confirmation did not come back in time.
Why it happened. The consent save task did not settle before the page's wait ended.
What to do. Reload the page, then check whether your consent choice saved before trying again.
What it means. You tried to start a new import, but confirmation that the batch was created did not come back in time.
Why it happened. The batch-creation task did not settle before the page's wait ended.
What to do. Upload the file again to start the batch.
What it means. You asked to move a scheduled send to a new time, and that request is still being worked on.
Why it happened. The reschedule task did not settle before the page's wait ended.
What to do. Refresh the Send card to see the current schedule.
What it means. You asked to cancel a scheduled send, and that request is still being worked on.
Why it happened. The cancel task did not settle before the page's wait ended.
What to do. Refresh the Send card to see whether the schedule was cancelled.
What it means. You asked to book a future send, and that request is still being worked on.
Why it happened. The schedule task did not settle before the page's wait ended.
What to do. Refresh the Send card to see whether the send was booked.
What it means. You asked to remind everyone who has not yet signed, and reminders are still being sent in the background. This is progress, not a failure.
Why it happened. Sending reminders to every unsigned person can take longer than the page's normal wait.
What to do. Wait about a minute, then press Refresh to see the result.
What it means. You tried to commit a batch that is no longer in a state that can be committed. Nothing was committed by this attempt.
Why it happened. The batch already moved past the committable stage, most often because it already committed.
What to do. Reload the batch; it may already have committed successfully.
What it means. You pressed Retry, but the batch is still in the middle of committing.
Why it happened. The batch's status is COMMITTING.
What to do. Wait for the run to finish, then check the result.
What it means. You pressed Retry, but there is nothing for it to do.
Why it happened. No rows in this batch are in a failed state.
What to do. Nothing to do. Check the commit result to see the actual outcome.
What it means. You tried to commit, but no row in the batch is ready.
Why it happened. Every row is still unresolved, was skipped, or was already created in an earlier attempt.
What to do. Finish the units and Payer steps for the remaining rows, then try committing again.
What it means. You tried to upload bank details, or confirm or delete a row, but the batch is past the point where those actions are allowed.
Why it happened. The batch is no longer in one of the three editable states (draft, resolving, or ready).
What to do. Start a new batch for anything further you need to change.
What it means. You tried to send, reschedule or cancel a send, but a send for this batch is already in progress.
Why it happened. The batch's communication status is currently SENDING.
What to do. Wait for the current send to finish, then try again if still needed.
What it means. You tried to save a change to bank debit consent while a send was in progress. Your change was not saved.
Why it happened. Same condition as above, caught on the Launch settings step.
What to do. Wait for the send to finish, then make your change.
What it means. You tried to book a new send, but one is already booked.
Why it happened. A schedule already exists for this batch.
What to do. Use the Reschedule or Cancel schedule controls on the existing send instead of booking a new one.
What it means. You tried to reschedule a send, but there is nothing booked.
Why it happened. No schedule exists for this batch.
What to do. Schedule a send first, then reschedule it if you need to move it later.
What it means. You tried to cancel a send, but there is nothing booked.
Why it happened. No schedule exists for this batch.
What to do. Nothing to do.
What it means. A send you had booked for the future has been cancelled automatically. Nothing was sent.
Why it happened. Someone changed a Launch settings field, such as the fee start date, while a send was booked. Changing any of those fields cancels the booking automatically, since the messages would otherwise carry the old settings.
What to do. If you still want the messages to go out, book a new send, or send immediately, from the Send card.
What it means. You deliberately closed the commit drawer earlier, and the commit carried on running in the background the whole time. Reopening it now shows you where it stands.
Why it happened. Committing a batch continues running even after the drawer is closed.
What to do. Wait for it to finish. Nothing was lost by closing the drawer.
What it means. Your browser or tab closed while a commit was running, without you choosing to close it. The commit kept going on its own, and picked up exactly where it left off rather than starting over or skipping ahead.
Why it happened. The batch was reopened in the COMMITTING status with no record of a deliberate close in this browser session.
What to do. Wait for it to finish. No row was committed twice, and no row was missed.
What it means. These appear while a commit is actively running, letting you know it is safe to leave the page.
Why it happened. Always shown while a commit run is in flight.
What to do. Close the drawer if you want to. The commit will keep running and you can return to check on it later.
What it means. Two separate imports tried to create a lease for the same unit at the same moment. This row was skipped so the unit does not end up with two conflicting leases. No lease was created from this row.
Why it happened. Two imports raced on the same unit.
What to do. Retry the failed row once you are sure only one import is working on that unit.
What it means. URBI tried to continue setting up a condo fee for a unit's active lease, but found that lease had actually been created by a different row than the one being resumed. It stopped rather than risk activating the fee against the wrong lease.
Why it happened. This shows up when a commit is retried after an earlier interruption, and in the meantime a different row's activity became attached to the same unit's active lease.
What to do. Check the unit involved. If the lease and fee shown for it are not what you expect, re-upload the correct row in a new batch rather than retrying this one.
What it means. A retry tried to pick up where an earlier attempt left off, expecting to find the recurring charge schedule that attempt had created. It was not there.
Why it happened. Something removed the charge schedule between the original attempt and the retry, most likely a change made directly on the lease outside this import.
What to do. Retry the import again. If this keeps happening for the same row, contact your URBI administrator.
What it means. The commit was unable to read a page of the batch's staged rows partway through and stopped rather than continue with incomplete information. Rows already processed before the stop are not affected; rows after the stop were not attempted.
Why it happened. The commit engine could not read the next page of rows.
What to do. Retry the import, and note the reason given for reference if it happens again.
What it means. The commit finished its work, but recording its final status failed. The rows themselves may well have been processed correctly; it is the summary of the run that failed to save.
Why it happened. The write of the batch's terminal status failed.
What to do. Reopen the batch to see its real, current state rather than relying on this message alone.
What it means. You tried to replace the uploaded file, but the batch has moved past the point where that is allowed.
Why it happened. The batch left the draft state while the replace-file panel was open, most likely because someone else moved it forward.
What to do. Start a new import instead.
What it means. You tried to discard a draft import, and the request failed.
Why it happened. The discard action did not complete.
What to do. Try again in a moment, or reload the page and try once more.
What it means. URBI can no longer find the file behind this batch.
Why it happened. The stored file behind the batch is gone.
What to do. Upload the file again to continue.
What it means. A background task looked for this batch to continue some deferred work, such as a delayed bank debit enrolment or invoice, and could not find it.
Why it happened. The batch row was removed before the background task ran.
What to do. Nothing to do. The deferred work was abandoned along with the batch; if you expected it to still happen, contact your URBI administrator.
What it means. You, or someone else on your team, made the staff declaration for this batch's bank debit rows, but the bank debit rows were then changed. The declaration on file no longer matches what would actually be committed, so URBI will not accept it as it stands. Nothing has been committed using the old declaration.
Why it happened. A declaration only covers the specific set of rows that existed at the moment it was made. Changing the rows afterward, even by re-uploading a corrected bank details file, breaks that match.
What to do. Open the declaration again and confirm it a second time, the same way as the first. See The staff declaration for exactly what the declaration commits your property to, and for the two related messages you may see alongside this one.
What it means. A held invoice for this batch was already being raised by another send attempt at the exact moment this one reached it. This attempt stood down rather than raise the same invoice twice. No invoice was raised twice, and none was lost.
Why it happened. More than one send process reached the same held invoice at the same time. See What exists after you commit, and what you can still change for when and why an invoice is held back and later raised at Send time.
What to do. Wait a moment and refresh. The other attempt will complete the work; you do not need to repeat it.
What it means. The same kind of overlap as above, seen from the side of the attempt that arrived second. The invoice is being handled by the attempt that got there first.
Why it happened. Two send attempts overlapped on the same held invoice.
What to do. Wait a moment and refresh to see the result. Nothing was billed twice.