Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_APK/llms.txt

Use this file to discover all available pages before exploring further.

The Receipts module is the primary inbound workflow on the Dragon Guard handheld. Operators pull the server-managed list of pending receipt headers, drill into individual lines to confirm quantities and putaway bins, then post the document to commit stock to the warehouse. All visibility decisions are delegated to the backend — the app never reapplies a client-side Released filter, so operators see exactly what the server intends them to act on.

​
Status Reference

Each receipt header carries three status fields. The handheld computes a single VisibleStatus by preferring ProcessingStatus over DocumentStatus, then maps that value to a short badge label and a high-contrast color for warehouse floor readability.
Short LabelRaw Status ValuesBadge Color
RelRELEASED#2563EB (blue)
OpenOPEN#2563EB (blue)
RecvRECEIVING#F59E0B (amber)
PendPENDING#F59E0B (amber)
PartPARTIALLY RECEIVED, PARTIALLY POSTED#F97316 / #F59E0B
DonePOSTED, CLOSED#16A34A (green)
The computed fields on ReceivingHeaderDto that drive the badge are: 
// ReceivingHeaderDto.cs
public string VisibleStatus =>
    string.IsNullOrWhiteSpace(ProcessingStatus) ? DocumentStatus : ProcessingStatus;

public string StatusShortLabel => StatusPalette.GetShortLabel(VisibleStatus);
public string StatusBadgeColor => StatusPalette.GetBadgeColor(VisibleStatus);
ProcessingStatus takes priority over DocumentStatus so that fine-grained backend workflow states (e.g., RECEIVING) are displayed instead of the coarser document-level value. If ProcessingStatus is blank, the badge falls back to DocumentStatus. The legacy Status field is kept for backend compatibility but is not used to drive badge rendering.PARTIALLY RECEIVED and PARTIALLY POSTED both produce the short label Part but differ in badge color: PARTIALLY RECEIVED renders orange (#F97316) while PARTIALLY POSTED renders amber (#F59E0B).

​
Receipt Header Fields

​
Id
Guid
required
Internal record identifier used to load lines and post the document.
​
CompanyId
Guid
Company the receipt belongs to.
​
ReceiptNo
string
required
Human-readable receipt number displayed in the header list and detail views.
​
ExternalDocumentNo
string
Vendor or ERP purchase order reference, searchable in the header list.
​
VendorCode
string
ERP vendor code associated with this receipt.
​
VendorName
string
Vendor display name shown on the header card.
​
LocationCode
string
Warehouse location. Displayed as MAIN when blank (DisplayLocationCode).
​
Status
string
Legacy ERP status field. Retained for compatibility; not used for badge rendering.
​
DocumentStatus
string
Handheld-facing document lifecycle status. Used as badge source when ProcessingStatus is blank.
​
ProcessingStatus
string
Fine-grained workflow status (e.g., RECEIVING). Takes priority over DocumentStatus for badge rendering.
​
ReceiptDate
DateTime
Expected or actual date of receipt.
​
CreatedAt
DateTime
Timestamp when the receipt record was created.
​
CreatedBy
string
Username or identifier of the operator who created the record. Searchable in the header list.
​
PostedAt
DateTime?
Timestamp set by the backend when the document is posted. null while still open.
​
PostedBy
string?
Username of the operator who posted the document.

​
Receipt Line Fields

​
Id
Guid
required
Line identifier used in PUT /api/receivinglines/{id} update calls.
​
ReceivingHeaderId
Guid
Parent header identifier linking this line to its receipt document.
​
ItemId
Guid
Internal item GUID. Used for navigation; not shown to the operator.
​
ItemCode
string
Item catalog code for the line.
​
QuantityExpected
decimal
Originally ordered quantity — displayed in the line grid as the target to receive.
​
QuantityReceived
decimal
Quantity the operator has entered for this receiving event (editable on the detail screen).
​
PostedQuantityReceived
decimal
Cumulative quantity already posted to stock. Used to determine whether any further receiving is needed.
​
RemainingQuantity
decimal
Quantity still to receive (QuantityExpected − PostedQuantityReceived). Drives the Pend / Part / Done line badge.
​
BinId
Guid?
Internal bin identifier submitted to the server when saving the line.
​
BinCode
string
Bin the operator selects for putaway. Displayed on the detail form.
​
SuggestedBinCode
string
Backend-suggested putaway bin. Defaults to MAIN when the backend returns no suggestion.
​
UOM
string
Unit of measure for the line quantities.

​
API Endpoints

MethodEndpointPurpose
GET/api/ReceivingHeaders?PageNumber={n}&PageSize={n}Load the paginated header list
GET/api/receivinglines/by-header/{headerId}?PageNumber=1&PageSize=100Load all lines for a receipt header
GET/api/receivinglines/{id}/detailLoad a single line’s full detail
PUT/api/receivinglines/{id}Persist quantity and bin for a line
POST/api/ReceivingHeaders/{id}/postPost (commit) the receipt to stock
Endpoint path casing matches the implementation: the header list and post action use PascalCase ReceivingHeaders; the line endpoints use lowercase receivinglines. Use the exact casing shown above.
The header list call omits any status query parameter when loading all headers — the backend controls which documents are visible: 
// ReceivingService.cs
var url =
    $"api/ReceivingHeaders?" +
    $"PageNumber={pageNumber}" +
    $"&PageSize={pageSize}";

// status parameter only appended when explicitly provided by the caller
if (!string.IsNullOrWhiteSpace(status))
    url += $"&status={Uri.EscapeDataString(status)}";

​
End-to-End Receiving Flow

1

Open the Receipts module

From the home screen, tap Receipts. ReceivingHeadersViewModel.InitializeAsync() fires once; subsequent page appearances call LoadAsync() to refresh from the server so completed documents disappear naturally.
2

Browse and search headers

The header list loads up to 20 records per page from GET /api/ReceivingHeaders. Use the search bar to filter client-side across ReceiptNo, ExternalDocumentNo, VendorCode, VendorName, all three status fields, DisplayLocationCode, and CreatedBy simultaneously.
3

Select a receipt header

Tap a header card to open the lines screen. The app calls GET /api/receivinglines/by-header/{headerId}?PageNumber=1&PageSize=100 and renders each line with its RemainingQuantity and short status badge.
4

Open a line and enter the received quantity

Tap a line to open the detail screen. Enter the quantity received into the QuantityReceived field. The detail view reads the current state from GET /api/receivinglines/{id}/detail before presenting the editable form.
5

Assign a putaway bin

The detail screen pre-populates BinCode from SuggestedBinCode. Change the bin if needed. Both QuantityReceived and BinId are persisted together via PUT /api/receivinglines/{id}:
// UpdateReceivingLineDto.cs
public class UpdateReceivingLineDto
{
    public decimal QuantityReceived { get; set; }
    public Guid?   BinId            { get; set; }
}
6

Post the receipt

From the header detail action menu, tap Post. The app calls POST /api/ReceivingHeaders/{id}/post with no request body. On success it navigates back and triggers a server refresh so the header list reflects the new posted status.
// ReceivingLineService.cs
public async Task<bool> PostReceiptAsync(Guid receivingId)
{
    var endpoint = $"api/ReceivingHeaders/{receivingId}/post";
    var response = await _http.PostAsync(endpoint, null);

    if (!response.IsSuccessStatusCode)
    {
        var error = await response.Content.ReadAsStringAsync();
        throw new InvalidOperationException(ApiErrorMapper.ToUserMessage(
            error,
            "No se pudo postear la recepcion."));
    }

    return true;
}
7

Verify updated status

After posting, the header list refreshes from the server. The badge updates to Done (green #16A34A) if fully posted, or the document disappears if the backend removes it from the visible set.
Posting is blocked when the document is already posted or closed.StatusPalette.IsPostBlocked(status) returns true for any status that normalises to POSTED or CLOSED. Attempting to post such a document will cause the backend to reject the request. The UI gates the post action on this check before calling the endpoint:
// StatusPalette.cs
public static bool IsPostBlocked(string? status)
{
    var normalized = Normalize(status);
    return normalized is "POSTED" or "CLOSED";
}
Backend rejection reasons also include insufficient stock, a missing bin assignment, or nothing remaining to post. All rejection messages are surfaced to the operator via ApiErrorMapper.ToUserMessage.

​
Local Search Behaviour

The header list supports client-side filtering without an additional API call. The view model filters across all text fields: 
// ReceivingHeadersViewModel.cs
var filtered = _allItems
    .Where(x =>
        (x.ReceiptNo?.Contains(search, StringComparison.OrdinalIgnoreCase) ?? false) ||
        (x.ExternalDocumentNo?.Contains(search, StringComparison.OrdinalIgnoreCase) ?? false) ||
        (x.DisplayLocationCode.Contains(search, StringComparison.OrdinalIgnoreCase)) ||
        (x.VendorCode?.Contains(search, StringComparison.OrdinalIgnoreCase) ?? false) ||
        (x.VendorName?.Contains(search, StringComparison.OrdinalIgnoreCase) ?? false) ||
        (x.Status?.Contains(search, StringComparison.OrdinalIgnoreCase) ?? false) ||
        (x.DocumentStatus?.Contains(search, StringComparison.OrdinalIgnoreCase) ?? false) ||
        (x.ProcessingStatus?.Contains(search, StringComparison.OrdinalIgnoreCase) ?? false) ||
        (x.CreatedBy?.Contains(search, StringComparison.OrdinalIgnoreCase) ?? false)
    )
    .ToList();
Clearing the search bar immediately restores the full unfiltered list without a network request.

Build docs developers (and LLMs) love

Get started for freeTalk to us