본문 바로가기

문제 해결, 기술 비교36

오픈소스 활용해 바코드 리더 기능 개발 회고 개요 직전에 블루투스 바코드 리더기를 이용해서 입출고를 처리하는 기능을 개발했습니다. 다음으로 엔지니어들이 제품을 설치하고 설치완료를 위해 핸드폰 바코드 리더기로 인식하는 기능이 필요합니다. 기존 기능이 너무 인식률이 떨어져 개선해야 했습니다. 조건 최대 효율을 내기 위해서 4가지 조건을 준수해야 했습니다. 모바일이 아닌 웹에서 필요한 기능이다. 바코드 리더기와 실제 바코드 규격이 호환되어야 한다. 현재 Quagga.js보다 인식률이 좋아야 한다. 가급적 프런트 프레임워크 없이 순수 js로 개발한다. 주로 백엔드를 공부했기 때문에, 프런트는 잘 몰라서 걱정이 많았습니다. 아무래도 기본 js 문법은 알고 있으나, 프레임워크를 활용해서 코드를 적용하거나 개발하는 것은 낯설었습니다. 처음에는 팀장님이 솔루션을.. 2023. 8. 21.

조직 현장 입출고 모바일 바코드리더기 연동 개발하기 문제점 조직에서 이동하는 수많은 물류를 수기로 처리하다 보니, 실제 사용하는 제품과 전산 상의 제품 바코드가 안 맞는 경우들이 있었고 엔지니어 재고 분배 시에도 분실하는 경우가 종종 있었습니다.(제품 1개당 약 수백만 원 제품이기 때문에 부품과 달리 엄청난 손해입니다.) 어긋난 재고 전산을 조회하거나 기록할 수 있는 기능을 만들어달라는 여러 가지 개발 요청을 받으면서, 근본적인 문제를 해결하지 않고 계속 부수적인 후처리만 하는 것이 아쉽게 느껴졌습니다. 따라서, 저는 개발자임에도 불구하고 바코드 사용을 강력하게 추진했습니다.(?) 따라서, 현장에서 보다 일을 신속하고 정확하게 처리할 수 있도록 개선했습니다. 바코드리더기 개발 방법 선택하기 바코드를 사용하여 현재 사용하는 시스템의 물류를 개선하는 일은 다.. 2023. 7. 18.

물류 재고 관리 개선하기 개요 회사에서 재고 실사를 하면 전산과 실물재고가 다른 경우가 있었습니다. 이 문제를 해결하기 위해 현재 상황을 분석하여 원인을 파악하고 개선한 내용을 정리합니다. 1. 지점별 제품/부품 추천 갯수 개선하기 문제점 각 지점에서 고객에게 설치를 하기 위해 제품, 부품 재고를 주문하는데 재고가 많이 남거나, 부족해서 재고가 필요한 곳에 제대로 전달되지 못하거나 자주 주문해야 하는 경우가 있었습니다. 이를 개선해 한 번 주문할 때 적정 재고를 주문할 수 있도록 권장 주문수량, 최수 주문수량을 추가했습니다. 그럼에도, 각 지점에서 설치, 교환에 필요한 재고들을 주문하는데 수량 제한이 없다보니 재고가 마이너스로 관리되는 경우들이 있었습니다. 예를 들어, 창고에 있는 제품 A가 재고가 5개밖에 없는데 3개의 지국에.. 2023. 1. 16.

기존 로그를 스프링 AOP 로 개선하기 개요 회사에 로그가 상세하게 기록되지 않아서 오류를 확인하기 힘들었습니다. AOP를 활용해 비지니스 코드에 따로 로그를 작성하지 않고도 원하는 곳에 작성할 수 있도록 개발했습니다. 기존의 로그 방식 Front, Admin 2개의 프로젝트가 있는데 이 중에 Admin 프로젝트는 로그가 아래처럼 각 Controller의 시작시에 찍혀 있습니다. 이는 비지니스 로직에 의미없는 불필요한 코드 추가이며 새로운 메서드가 생성될 때마다 수동으로 작성해야 합니다. 또한 로그 규칙이 변경된다면 모든 메서드의 로그 코드를 수정해야 하는 불편함이 있습니다. 로그는 각 메서드마다 공통으로 기능이 필요한 부분으로 관점 지향 프로그래밍이 필요합니다. 따라서 스프링 AOP를 사용해서 로그 체계를 새롭게 잡았습니다. 스프링 AOP의.. 2023. 1. 11.

UNION을 CASE WHEN THEN으로 개선하기 개요 회사에서 사용하는 기존 통계 쿼리가 5개의 UNION으로 연결되어 있었습니다. 중복되는 코드가 엄청 많았고 약 150줄이었습니다. COUNT, SUM 등을 이용하여 개선을 할 수 있다고 판단하여 UNION을 CASE WHEN THEN을 개선했습니다 문제상황 GROUP BY를 통해서 크게 3개의 덩어리를 합쳐야 했는데, 각 덩어리는 GIRO_PBLC_YN 칼럼 값에 따라서 2개로 나뉩니다. '총 건수'를 계산하는 쿼리문 하나와, '지로발행 안함' 전용 쿼리가 합쳐집니다. 쿼리는 아래와 같습니다. SELECT REQ_DT, FILE_NM, CRE_DT, MAX(TOT_CNT) TOT_CNT, MAX(TOT_CNT_N) TOT_CNT_N, MAX(TOT_REQ_AMT) TOT_REQ_AMT FROM (S.. 2023. 1. 9.

할인 쿠폰 개선하기 개요 할인쿠폰을 사용하면서 고도화해야 하는 요청들이 있었습니다. 또한 다양한 정책의 할인이 필요한 경우도 있었습니다. 이 과정들을 정리합니다. 1. 할인쿠폰 설계 개선하기 기존 할인쿠폰 테이블은 제품의 특정 상품을 제한하거나 사용 조직을 제한할 수 없었습니다. 그러다보니 다른 부서에서 만든 할인쿠폰을 사용하는 문제, 특정 제품이 아닌 전체 제품에 할인쿠폰이 적용되는 문제가 있었습니다. 따라서 할인쿠폰 테이블과 연관관계를 가지고 있던 할인쿠폰 제품 테이블을 개선하고 할인쿠폰 사용조직 테이블을 추가했습니다. 할인쿠폰 상품 테이블 개선 기존에 할인쿠폰기본(TB_DC_B) 테이블은 제품테이블(TB_PRDT)와 N:M 관계를 가지고 있었고 중간 테이블인 할인쿠폰 제품(TB_DC_PROD) 테이블이 있었습니다. 하.. 2022. 12. 28.

DataSourceBuilder, yml의 원리 및 @ConfigurationProperties 적용 개요 일반적으로 mysql DB 접속 정보를 application.yml에 설정했는데, master-slave를 구성하면서 DB 정보들을 java 설정 쪽으로 가져와야 했습니다. 1. 해당 정보를 어떻게 가져올 수 있는지 고민하던 중, DataSource로 받아오며, 손쉽게 DataSourceBuilder를 이용할 수 있다는 것을 알고 정리합니다. 2. @ConfigurationProperties을 통해서 application.yml에서 원하는 정보를 가져올 수 있습니다. DataSourceBuilder란? DataSourceBuilder는 공통 구현과 설정으로 DataSource를 편리하게 만들 수 있는 클래스입니다. 이 빌더에 의해서 구현할 수 있는 pooling Datasource에는 Hikari,.. 2022. 12. 16.

수기 업로드 작업 자동화 및 이메일 솔루션 사용 개요 렌탈료 청구서, 렌탈료 납부서, 위약금 청구서, 렌탈료 납부서 총 4개의 메일 전송 기능이 필요합니다. 기존에 사용했던 기능에서 솔루션을 도입해 개선하는 건으로, 변경사항, 삭제사항, 추가사항을 정리하고 이메일 솔루션을 도입하였습니다. 미팅 내용 변경사항 - 렌탈료와 위약금 청구서 및 납입서 수기 업로드를 이메일로 전송으로 전환 - 여러 달을 합쳐서 보여주지 않고 1달을 기준으로 문서 작성 삭제사항 - 합산포함, 선납확인서 삭제 신규 추가사항 - 정기 전송 여부, 정기 전송 일자를 추가해 일 배치로 매일 전송 - 그룹 주문번호로 최대 15개까지 내용을 묶어서 보낼 수 있음 - 위약금 자동입력(프로시저 활용, 반환접수일 추가) 실행 프로세스 정리 청구서, 납입서 전송은 크게 [유효 주문번호 조회] -.. 2022. 12. 16.

NICE API 일시불 취소 개발하기 개요 기존에 NICE API로 일시불 결제는 구현되어 있지만 모든 취소는 상담원을 통해서만 가능했습니다. 업무시간(8:30~19:00) 이외에 상담원이 부재하여 바로 취소를 할 수 없어서 NICE API 일시불 취소를 개발했습니다. NICE API 일시불 취소 순서도 취소 요청부터 취소 완료 후 알림톡 발송까지의 과정입니다. 순서도 설명 본인이 요청한 주문인가? 취소의 조건으로 본인이 요청한 주문인지, 취소가 가능한 상황인지 확인합니다. 추소 요청 주문번호에 따른 결제자 아이디가 현재 로그인 한 아이디인지 확인합니다. 또한 상품 준비 중(배송 준비 중) 상태를 기준으로 이전은 즉시 취소가 가능하며 그렇지 않다면 취소 접수를 통해 상담원에 안내합니다. 취소 가능한 상태인가? 중복 취소를 방지하기 위해서 취.. 2022. 12. 9.

이전 1 2 3 4 다음

티스토리툴바