Skip to main content

Mobile Borrow And Customer Management

This page documents the current mobile behavior for borrow-item editing and customer-management edit fields.

  • CustomerList uses CustomerManagementListHeader for the search box.
  • When the user submits search from the keyboard, the header passes the TextInput submit event text to the screen.
  • CustomerList uses that submitted text as the effective search value for getCustomerSapList immediately, then syncs the local search state/ref.
  • This prevents Thai IME timing issues where typing a word such as ขาย and pressing search could send only the first committed character, such as ข, to the customer API.
  • The search still preserves the existing filters for shipping type and route code.

Customer address forms on iOS​

  • CustomerDetail no longer opens the "add address" form as a nested modal.
  • Pressing เพิ่มที่อยู่ใหม่ switches the screen from the customer detail view to a full-screen address form view inside the same screen.
  • The detail header back action and the form กลับ action close the address form and return to the customer detail view.
  • CustomerManagementEdit uses the same full-screen address editor pattern for adding and editing draft addresses.
  • While the address editor is open, the customer main form is hidden so only one scroll owner is active.
  • Address search, route selection, and map picking are still modal/picker flows, but they are opened from the screen-level address form instead of from another modal.
  • Modal visibility is guarded by the active view:
    • customer-detail address search/map/route modals only open while the customer-detail address form is active.
    • customer-management address search/map/route modals only open while the address editor is active.
    • customer-management main-form selectors such as customer type, know-us, branch, day, and month are hidden while the address editor is active.
  • This avoids iOS modal-over-modal and scroll gesture conflicts while keeping the save behavior, address payload, auto-create ShipTo option, and draft reload behavior unchanged.

Borrow detail item editing​

  • BorrowDetail allows item editing only when the document is still NEW and the current user is the borrow owner.
  • Owner comparison now trims both user.userCode and detail.userCode before matching.
  • Tapping an existing borrow item opens a dedicated edit modal.
  • The edit modal uses the same visual style as the add-product modal, but it does not show the product list or product search.
  • The edit flow loads the current product by productCode. If the item is missing from the in-memory inventory snapshot, the screen fetches it from inventory before opening the edit modal.
  • Permission enforcement for editing is checked again when the user presses save.

Borrow detail item save and delete behavior​

  • Editing an existing borrow item now updates by itemId, and falls back to id when itemId is missing in the item payload.
  • This prevents the edit flow from accidentally calling create-item APIs and triggering duplicate-item errors such as "item already exists in the list".
  • Borrow-item deletion also falls back to item.id when item.itemId is missing.
  • If no usable item identifier exists, the screen now shows a direct error instead of failing silently.

Customer management edit fields​

  • CustomerManagementEdit keeps customerType/customerTypeCode and knowus/knowusCode as separate fields.
  • CustomerManagementEdit includes an optional taxID text field directly under ฉายา.
  • taxID is not required for saving and is carried in the customer draft payload when present.
  • CustomerManagementDetail and CustomerDetail display taxID in the customer information section, falling back to - when the value is empty or missing.
  • The option lists now load from the correct source collections:
    • customerTypes populate the ประเภทลูกค้า selector.
    • knowUs populate the รู้จักเราจาก selector.
  • This fixes the previous behavior where the two selectors were swapped in the edit screen.

Customer draft create, replace, and pending child records​

  • Creating a new customer from CustomerManagementEdit creates the customer draft first.
  • After the draft is created, the screen attempts to create draft addresses and draft branches under that draft id.
  • If some addresses or branches fail to save, the screen still keeps the created customerDraftId and navigates with replace into the same draft edit screen.
  • The screen passes unsaved child records as pending route params and merges them back into the refreshed screen state after reloading draft detail, addresses, and branches from the server.
  • This means unsaved addresses or branches remain visible to the user after the screen reloads, even when those records are not yet stored on the server.
  • A later save updates the existing draft instead of creating a new draft again.

SAP B1 approval recovery​

  • When immediate approval of a newly created individual customer fails, Mobile shows the B1 approval error and replaces the edit screen with the created draft detail.
  • The draft detail reloads after an approval failure. DRAFT exposes approve/reject; SAP_PARTIAL exposes only retry approval submission through POST /customer-draft/:id/retry.