WtResultCode

success codes >= 0 error codes = < 0 However note that some legacy error codes (versions pre-dating 2016/01/01) use positive ranges for FAILURE codes

success codes >= 0 error codes = < 0 However note that some legacy error codes (versions pre-dating 2016/01/01) use positive ranges for FAILURE codes. NOTE: for wasp.mobile.asset cloud version 2016 (and onward), Warnings start at 1 BILLION or above

Failure codes are reserved range in the negative values

success codes >= 0 error codes = < 0 However note that some legacy error codes (versions pre-dating 2016/01/01) use positive ranges for FAILURE codes

default value: * Successfully deleted User.

Your search criteria resulted in too many matches. Please review your search conditions or values.

Your search criteria was too general. Please narrow your search, or specify a longer search pattern.

Request received and processing has started.

Prior request received and processing has started. This request is a duplicate request.

Request is not in the expected sequential order.

Request is not in the expected sequential order.

Request is not in the expected sequential order.

Request sequence missing required parameters.

Request too soon. Try again in {0} second(s).

Request too soon. Try again in {0} minute(s).

Request too soon. Try again in {0} hours(s).

Request too soon. Try again in {0} day(s).

Highest error code for request sequences. The request cannot be processed.

Archive successfully completed. Success Messages are always positive integers

Archive successfully completed for both Transactions and Orders. Success Messages are always positive integers

Archive successfully completed for Transactions History. Success Messages are always positive integers

Success Messages are always positive integers; but this is a bad failure. internal server error.

50040 == success. No http error, and custom error code indicated success

-50041 == (-50040 -1)

-50042 == (-50040 -2)

-50100 : DELETE_SCHEDULE_JOB_WITH_EXTREME_PREJUDICE * Signal the now and later services to permamently destroy this cron job from Quartz and its scheduler_action table. * Note: this message is not for the end-user to view

no need to lookup this string since the codes are for communicating with internl Wasp API

no need to lookup this string since the codes are for communicating with internl Wasp API

no need to lookup this string since the codes are for communicating with internl Wasp API

no need to lookup this string since the codes are for communicating with internl Wasp API

no need to lookup this string since the codes are for communicating with internl Wasp API

no need to lookup this string since the codes are for communicating with internl Wasp API

no need to lookup this string since the codes are for communicating with internl Wasp API

no need to lookup this string since the codes are for communicating with internl Wasp API

DO NOT allow the ''TARDIS'' effect:

[dbo].[trackby_type] defines max_qty and transaction quantity cannot exceed this value

[dbo].[trackby_type] defines what transaction type codes are allowed per track by type

never allow track-by to be redefined throughout the life of an item asset_id

IC-655. Raised when a purchase-order receipt names a location belonging to a different site than the order header. Inventory only; a purchase order with no site is unscoped and still receives into a location at any site, so this code cannot arise for one. Distinct from ORDER_LINE_INVALID_LOCATION rather than folded into it: that code and ORDER_LINE_INVALID_CONTAINER already ship the identical "The location is invalid." text, so reusing it would make three unrelated failures -- location missing or inactive, container invalid, and location at the wrong site -- indistinguishable in support logs.

generic place holder error message

generic place holder error message

generic place holder error message

generic place holder error message

generic place holder error message

Identity could not be authenticated via an external magic decoder ring due to bad user/domain/password/resources/end-point/connectivity.

Self-contained rather than reusing LENGTH_TOO_LONG, whose template takes two format arguments ("The length of {0} data is too long, maximum length is {1}.") that the GetMessageNoDb / AddMessageToResult path cannot both supply -- it would reach the user with the placeholders still in it.

AC-648. The bound exists because the resolver has to do arithmetic with this value: [dbo].[vMaintenanceDue] multiplies it out to minutes or months, and a plan saved with an absurd interval would overflow that arithmetic and take the whole My Work page down for the tenant, not just its own rows. The view drops such a plan rather than failing, and this stops another one being saved.

AC-648/AC-650 concurrency rule. Two techs can open the same resolved row, because a due row has no database identity to lock. The filtered unique index on asset + plan task + due date is what settles it, and this is what the loser is told -- with the winner's name, so it reads as information rather than a failure. Formatted with one argument.

The asset, the plan task, or the pairing of the two. Deliberately one message for all three: a caller posting a due row it did not receive is not a user who needs the difference explained, and spelling out which half was wrong would confirm the existence of records the caller may not be allowed to see.

AC-648. The mirror of MAINTENANCE_PLAN_OCCURS_EVERY_TOO_LARGE, for the other half of the same if/else. [dbo].[vMaintenanceDue] resolves a fixed-interval plan with DATEADD(day, interval, last_completed), which overflows on an absurd interval; the view guards itself by dropping any plan outside 1..36500 days, which means a plan saved with 50000 would produce no due work at all and report nothing to explain why. 36500 days is a century, so the ceiling costs no real maintenance schedule anything.

AC-648. A completion is the resolver's anchor: [dbo].[vMaintenanceDue] schedules the next occurrence from it, so a completion dated in the future pushes the asset's whole schedule out by however far the date was wrong. A mistyped year is the ordinary way that happens, and there is no in-product way to take it back -- the unique index forbids re-completing the same occurrence. Rejecting it on the way in is the only cheap moment.

AC-648. carries a value the server does not define. Rejected rather than quietly resolved to the narrowest scope: silently answering a different question hands the user a short list that looks authoritative, and a client asking for a scope this build has not shipped yet -- a newer mobile app against an older server -- has no way to find out. Absent, null and zero all still mean "not supplied" and default to Mine.

AC-648. The mirror of for . Absent, null and zero mean "not supplied" and default to AllOpen.

AC-648. The third of the bounds that exist to keep [dbo].[vMaintenanceDue] from overflowing, alongside and . The view counts occurrences from the starting date, so a plan starting at the top of the datetime range resolves its first occurrence to that date and then pushes the next one past 9999-12-31 as soon as somebody completes it -- and the DATEADD that fails is the whole view, taking My Work down for the tenant rather than dropping the one plan responsible. A mistyped year is the ordinary way it happens. The view drops a plan starting outside 1900..2999; this stops another one being saved.

AC-650. carries a value the server does not define. Absent, null and zero all mean Completed, so a caller written before the outcome existed keeps recording completions.

AC-650. Closing an occurrence as incomplete needs a reason in the notes. The row is the permanent record of work that was skipped -- it anchors the schedule exactly like a completion -- and a skip with nothing said about it is indistinguishable from a mistake.

AC-650. The condition after service names a [dbo].[condition] row that does not exist, is inactive, or belongs to another application. Checked before anything is written, because the same value goes onto [dbo].[asset].[condition_id] in the same save.

AC-650. A photo has no data, no file name, an extension outside the tenant's AttachmentSupportedImageFileTypes, or more bytes than AttachmentMaxFileSize allows. Formatted with the size limit in megabytes. Rejected before the completion is written, so a bad photo never leaves a completion behind without it.

AC-650. The completion row saved but the photo store did not take one or more of the photos. A warning rather than an error, and positive so HasError stays false: the occurrence IS complete and the schedule HAS advanced, and reporting that as a failure would invite a retry the unique index is going to refuse.

AC-650. More photos than MaintenanceCompletionModel.MaxPhotos allows on one completion. Formatted with the limit. The per-file size cap bounds each photo; this bounds the request, which is buffered whole on both web tiers.

AC-651. Every selected occurrence was reassigned. No {0} for the assignee, deliberately. AddMessageToResult passes exactly one format argument and only when it is non-empty, so a placeholder here would print literally on any batch whose assignee could not be named -- the trap MAINTENANCE_COMPLETION_ALREADY_COMPLETED has to be guarded against at every call site. The name is on MaintenanceReassignmentResultModel.AssignedToName instead, where the UI composes its own confirmation from its own message strings.

AC-651. Some of the batch moved and some did not -- the rest had been completed, superseded, or put out of reach since the page was drawn. Formatted with how many were left alone; the per-occurrence reasons are on MaintenanceReassignmentResultModel.Skipped. A success code, deliberately. The reassignments that went through are real and the caller must not be told the operation failed, or it will be retried against rows that have already moved.

AC-651. None of the selected occurrences could be reassigned -- all of them had been completed, superseded, or put out of the caller's reach. Nothing was written.

AC-651. The request named no assignee and did not ask to restore the plan default, or it named both a user and a role. An occurrence is assigned to one or the other, exactly as its plan task is.

AC-651. The request selected no occurrences to reassign.

AC-651. More occurrences in one batch than MaintenanceReassignmentModel.MaxOccurrences allows. Formatted with the limit.

AC-651. The reassignment was undone: these occurrences answer to the assignee their plan task names again. Separate from because there is no assignee to report -- restoring the default is not the same act as handing work to nobody.

AC-741. The request asked both to restore the plan default and to change it. Restoring means "let the plan decide again" and there is no reading of that which also rewrites what the plan decides, so the pair is refused rather than resolved in favour of one -- guessing would silently do the opposite of half the request. Not reachable from the Reassign modal, which disables the all-future option whenever Restore is the chosen assignee. This is the check for everything that is not that modal.

AC-722. The Completed Work request asked for a date range this server cannot answer. Either it named a window this build does not define -- the mirror of for the history page, refused rather than narrowed for the reason that one is: a client asking for a range this build has not shipped would otherwise be handed somebody else's range with no way to tell the server had ignored it, and every figure on the page would be about a period nobody asked about. Or it sent an explicit bound outside the range a query can be built from -- MaintenanceCompletedRequestModel.MinBound to MaxBound. That is a well-formed date, so it is not ; before AC-722's review it reached the arithmetic and the provider and came back as a generic exception message.

AC-722. No completion record with this id is one the caller may read -- it does not exist, it has been voided, or their asset-type or site security does not reach the asset it was recorded against. Deliberately one message for all three, exactly as is: distinguishing "not yours" from "not there" tells a caller which record ids exist, and these rows name the person who did the work.

AC-765. The caller named nobody as Completed By and has no active employee record of their own to default to. Refused rather than saved against nobody, because the unique index forbids re-completing the occurrence and the blank could never be filled in.

this error occurs when the UI attempts to remove scheduler information from a template dbo.order record.

this error occurs when the UI attempts to ADD an association entry to dbo.order_schedule to an existing entry in dbo.order that does not have one. Note this error is the opposite use case of error code MASTER_REMOVE_SCHEDULE_DISALLOWED (78,000)

Use case: whenever a scheduled template is created, it always spawn up a physical copy called the ''working head order record'' of the template. If a ''working head'' order is closed/completed, then a new working head is automatically created. Any attempt to delete a ''working head order record'' that belongs to a scheduled template will result in this error code. The way to work around it is to delete the scheduled template first.