#vilakku/ot

• What is the movement history of this serial number?
• What was the latest Ship Doc for this serial number?
• What was the latest Customer Return for this serial number?

#Install

moon add vilakku/ot

#Setup

#Usage

///|
async fn print_latest_ship_doc(serial : String) -> Unit {
  let client = @http.Client::Client("https://services.ordertime.com")
  try {
    match @ordertime_client.get_latest_ship_doc_for_sn(client, serial) {
      Some(tx) =>
        println("Latest ship doc \{tx.doc_no()} for item \{tx.item()}")
      None => println("No ship doc for this serial number")
    }
  } catch {
    err => println("OrderTime query failed: \{err}")
  }
}

#Behavior worth knowing

• "Latest" means the highest DocNo. OrderTime assigns document numbers in sequence, so the maximum is the most recently recorded transaction. The rule does not depend on the order rows come back in, and ties keep the earlier row. latest_transaction implements the rule and is public, so you can apply it to any list of transactions you already have.
• Unmodeled transaction types are skipped. Rows whose TranType is not Receiver (2), Ship Doc (4), Transfer (5), or Customer Return (10) are logged and dropped while parsing.
• The counterparty falls back to RelatedToEntityRef. Movement list rows carry no CustomerRef; the customer field reads CustomerRef when present and the related entity (customer, vendor, ...) otherwise.
• Detail fields are not in list responses. Memo, internal notes, customer PO, and tracking numbers live on the full document only, so the matching fields on list results are always empty. The full-document lookups above return them populated.
• The record cap is explicit, and hitting it is an error. Every list query asks for up to 1000 records (the endpoint maximum) instead of accepting the silent 100-record default. A response that comes back with 1000 rows may have more behind it, so the client raises OrderTimeQueryFailed::TooManyRecords rather than returning a truncated result that looks complete. A serial number normally has a handful of movements, so in practice this never fires; it exists so a truncated answer can never pass silently.
• The API is slow. A single list call can take on the order of 20 seconds. Size any timeouts accordingly.

#Errors

• a non-200 response raises an error carrying the HTTP status code (the API uses 400 for a bad request, 403 when the API user's role lacks rights, and 409 when data validation fails);
• a 200 response whose body is not valid JSON, or is valid JSON but not an array of rows, raises an error describing the problem;
• a list response that returns the full 1000-record cap raises OrderTimeQueryFailed::TooManyRecords, because it may be truncated (see the record cap note above);
• network failures raise the HTTP layer's own errors.

#The payloads underneath

{
  "Type": 1141,
  "NumberOfRecords": 1000,
  "Filters": [
    {
      "PropertyName": "LotOrSerialNo",
      "FilterValueArray": "EXAMPLESN00000000001"
    }
  ]
}

#TranType reference

#Not implemented yet

• Inventory queries (record type 1110: stock levels, for example all units of a model in a location).
• Write operations of any kind.