통신이 끊겨도 재고를 셀 수 있는 실사 어플 제작하기

핵심 요약

1. 상품코드와 실제수량을 기기에 보관해 통신이 끊겨도 실사를 이어가는 앱을 만듭니다. 2. Flutter의 오프라인 우선 구조와 FastAPI 파일 수신, PostgreSQL 트랜잭션을 업무에 맞게 연결합니다. 3. 작업자별 구역 배정, 기준시각 대조, 수량 충돌 검토와 중복 반영 방지는 직접 개발합니다.

재고 실사 어플 제작의 핵심은 현장에서 센 수량을 빠짐없이 남기고, 어떤 대장과 비교했는지 확인하는 데 있습니다. 창고 모바일 앱 개발에서는 연결이 끊긴 동안의 수정과 재연결 이후의 검토까지 한 흐름으로 다뤄야 합니다. 아래는 이를 제작할 때 필요한 기능과 검수 조건입니다.

FastAPI로 기준 대장과 실사구역 준비하기

먼저 ‘상품코드·품명·포장단위가 있는 상품목록 파일’과 ‘구역·상품코드·장부수량·추출시각이 있는 재고대장 파일’을 준비합니다. FastAPI는 UploadFile로 업로드 파일을 받을 수 있습니다. 파일의 필수 열, 수량 형식, 업로드 권한을 확인하는 기능은 별도로 개발합니다.

대장을 읽은 뒤에는 실사 기준시각을 화면에 표시하고 작업자마다 담당 구역을 배정합니다. 같은 상품이 여러 구역에 있으면 구역별로 수량을 구분하며, 중복 배정은 시작 전에 확인하게 합니다. 필수 열이 빠진 파일은 잘못된 행을 안내하고, 작업 시작 전에 담당 구역과 비교할 대장이 맞는지 검수합니다.

상품코드 스캔을 실제수량 입력에 연결하기

스캔 결과에서 받은 상품코드를 상품목록과 연결해 품명, 포장단위, 현재 실사구역을 보여 줍니다. 작업자가 상품을 확인한 뒤 실제수량을 입력하고 ‘수량 저장’을 누르는 흐름입니다. 스캔 도구는 사용할 단말기와 실제 라벨로 읽기 시험을 거쳐 선택하며, 특정 라이브러리의 인식 범위를 미리 단정하지 않습니다.

같은 구역에서 같은 상품을 다시 읽으면 기존 입력을 열어 수정하도록 만듭니다. 박스 수와 낱개 수를 혼동하지 않도록 입력 단위를 고정하고, 환산이 필요하면 승인된 포장단위 정보를 사용합니다. 검수에서는 미등록 코드를 임의의 상품에 연결하지 않는지, 수량 0과 아직 세지 않은 항목이 구분되는지 확인합니다.

Flutter로 오프라인 수량 수정과 로컬 보관하기

Flutter 공식 문서는 저장소 계층에서 로컬 데이터와 원격 API를 함께 다루는 오프라인 우선 설계 예시를 제공합니다. 여기서 저장소 계층은 화면과 기기·서버의 데이터 사이를 연결하는 부분입니다. 이 구조를 바탕으로 실사 시작 전에 담당 구역의 상품목록과 기준 대장을 기기에 내려받도록 구현합니다.

수량을 저장할 때는 상품코드, 구역, 작업자, 입력 수량과 수정시각을 기기에 함께 남깁니다. 연결이 끊겨도 기존 값을 다시 열어 고칠 수 있게 하고, 기기 저장이 끝난 뒤에만 저장 완료를 안내합니다. 검수할 때는 통신을 끊고 수량을 수정한 다음 앱을 닫았다 열어, 마지막으로 저장한 값과 아직 서버에 보내지 못한 내역이 보이는지 확인합니다.

기준시각 대조와 작업자 간 수량 충돌 검토하기

연결이 돌아오면 기기에 보관한 내용을 서버로 보내고 해당 실사의 기준 대장과 비교합니다. 비교 화면에는 장부수량, 실제수량, 차이와 작업자를 나란히 보여 주며, 다른 기준시각의 대장이 섞이지 않도록 확인 로직을 넣습니다. 기준시각 이후의 입출고를 확인할 수 없는 항목은 자동 확정에서 제외하고 검토 대상으로 보여 줍니다.

같은 구역의 같은 상품에 서로 다른 수량이 제출되면 최근 값으로 덮어쓰지 않고 두 입력을 함께 표시합니다. 책임자가 ‘재실사 요청’ 또는 ‘수량 확정’을 선택하고 판단 이유를 남기는 기능을 직접 개발합니다. 서로 다른 구역의 동일 상품은 충돌로 처리하지 않고, 각 구역의 검토가 끝난 수량을 합산하는지 확인합니다.

PostgreSQL로 확정 수량과 검토 이력 함께 저장하기

PostgreSQL 트랜잭션은 여러 데이터 변경을 모두 반영하거나 모두 취소하는 기능입니다. 이를 이용해 확정 수량을 대장에 반영하는 작업과 누가 어떤 이유로 확정했는지 기록하는 작업을 한 묶음으로 처리합니다. 두 작업 중 하나라도 실패하면 완료로 표시하지 않으며, 수량과 검토 이력이 따로 남지 않는지 검수합니다.

대표적인 실패 검수는 서버가 수량을 저장한 직후 통신이 끊겨 앱이 같은 내용을 다시 보내는 상황입니다. 같은 제출을 구분하는 기준을 직접 만들어, 실제수량 12개를 재전송해도 24개로 늘거나 검토 이력이 중복되지 않게 합니다. 최종 화면에서는 확정된 항목과 추가 검토가 필요한 항목을 구분하고, 미해결 항목이 남으면 실사 전체를 완료 처리하지 않도록 합니다.

재고 실사 어플 제작을 준비하신다면 상품목록과 기준시각이 포함된 재고대장 예시, 작업자별 구역 배정 방식, 연결할 재고관리 시스템 정보를 정리해 문의해 주세요. 트램스 AI 제작 문의 (https://trams.co.kr/ai-si/contact/#inquiry)