1,2번 항목은 영카트5 데모 http://demo.sir.co.kr/gnuboard5/shop/ 에서 확인해보시면
정상적으로 배송비 설정이 적용되는 걸 보실 수 있습니다.
3번 항목역시 환불금액을 -로 입력하지 않아도 제대로 처리가 됩니다.
4번의 경우 주문합계 금액은 상품금액과 배송비가 합산된 금액입니다. 만약 취소가 있을 경우
배송비가 변경되거나 없을 수가 있기 때문에 실제 입금 금액과 주문합계 금액이 일치하지 않게 됩니다.

1. 주문내역 수정페이지에서 배송비가 수정되지 않습니다

가정) 고객이 주문을 두건으로 나눠함.
배송비 1개 빼줘야함. 한개 주문서의 배송비를 0으로 수정함.
이때 주문상태는 입금임.

배송준비를 마치고 주문상태를 배송(또는 완료)으로 수정하면
아까 0으로 수정했던 배송비가 다시 되살아나서 미수금으로 남음.
(이경우 결제취소/환불 금액에 마이너스를 넣어줘야함. 영카트 4에서는 수정하면 되살아나지 않았음.
4에서 5로 옮기면서 그 데이터들이 모두 살아나서 대량의 주문서가 미수금으로 남아버렸음)

----> 데모사이트 역시 마찬가지임.



2. 결제취소/환불 금액에 마이너스 금액을 넣어야 취소/환불 금액으로 제대로 적용이 됩니다.

주문서를 수정하지 않고 진행할 경우는 마찮가지이지만
주문서 주문수량 수정이 가능한 것을 확인했습니다.

그러나
주문서는 작성하고 돈을 받지 않고 출고시키는 경우가 있어서
이경우에는 마이너스를 입력해야합니다.
(또는 질문 1의 배송비를 마이너스 처리한 경우)
==> 이 금액이 주문취소금액에 포함되지 않습니다.
영카트 4에서는 주문취소 금액에 포함되는 로직이었기 때문에 수년간 그렇게 해왔었습니다.



3. 관리자 주문서 페이지에서는 주문총액이 배송비를 포함한 금액임.
소비자 주문서 페이지에는 주문총액이 배송비를 제외한 순수 상품 총액임.

관리자가 상품주문총액만 알고자 할 경우, 주문총액에서 배송비를 제외해야하는 번거로움이 있음.
같은 용어에 다른 의미부여로 소비자와 의사소통시 혼선이 발생함.
영카트 4에서는 소비자 주문서 페이지와 동일했었음.
(관리자 페이지에도 순수주문상품 금액으로만 표시되었었음)


4. 매출현황에서 주문합계 금액이 맞지 않습니다.
주문금액=결제금액(무통장,카드....) +포인트+미수금-취소금액
이렇게 나와야합니다. (영카트 4에서도 이와 같았음)

현재는
결제금액+포인트+미수금-취소금액이 주문금액과 상이합니다.
따라서
매출신고시 정확한 매출금액을 추산할 수 없습니다.
(문제 2번의 마이너스 금액이 취소금액에 포함되지 않는 경우 임)

영카트5의 기본 코드로 모든 환경에 대응하는 것은 불가능합니다.
묶음배송에 대한 고려도 없고 수많은 상황에 대해 하나의 코드로 대응하는 프로그램을 개발하는 것은
불가능합니다. 기본적으로 입금 후 배송하는 것을 원칙으로 하고 있습니다.
운영하시는 쇼핑몰에 맞지 않고 수정이 필요하시다면 커스터마이징을 해주셔야 합니다.
대응할 수 없는 수많은 환경에 대해 고려하는 것은 불가능하므로 프로그램의 수정은 어렵습니다.

편리님. 저희 상황에 대응을 해달라는 것이 아닙니다.
편리님이 테스트를 어떻게 하셨는지 모르겠습니다만.. 저희가 테스트한 결과로는 데모 사이트에서 배송비 수정이 되지 않고 있습니다.
혹시나 글을 잘 못 이해하셨나해서 대댓글에서 다시 설명해드렸습니다.
몇 번이나 테스트하면서 글을 작성했습니다. 그 과정에서 저희가 미처 알고있지 못한 사실도 알기도 했구요..
역시 배송비는 수정이 안됩니다.
"입금 후 배송", "묶음 배송" 의 문제가 아닙니다. 배송비 수정이 안된다는 것입니다. 어찌보면 단순하고 이게 해결되면 자체적으로 알아서 묶음배송하고 있던 업무가 한결 쉬워지고 DB상에서 데이터의 일관성도 유지될 수 있다는 것입니다.
추가적으로 다른 문제들도 해결되리라 봅니다.

쇼핑몰에서 주문금액 등과 같은 개념들이 버전이 달라졌다고 바뀌면 어느 한 쪽이 잘못된 것이 아닐까요?
과거 버전이 잘 못되었던지 지금이 잘 못 되었든지.. 문제가 있을 수 있다는 것입니다.
이 건으로 고객(제가)이 의문을 제기한 상태입니다.
지금은 바빠서 확인 못한다면 시간이 나면 다시 확인해서 알려주겠다라고 말씀해주시면 안될까요?
마지막 답변이 결국은 고객 환경에 일일이 대응하기 힘들다잖아요.

영카트5로 영업을 한지도 몇 달이 지났습니다. 지금까지 참고 사용을 했습니다. 조금 더 늦춰진다고 크게 문제가 되지는 않습니다. 그리고 커스트마이징도 고려할 수 있습니다.

이건으로 저희가 받아들이는 것은 테스트, 입증, 설명 등이 힘들기 때문에 서둘러 이 케이스를 닫아버린다는 것입니다.

저희는 갑도 아니고 을도 아닙니다. 편리님께서 개발하여 제공해주신 솔루션을 저희는 가져다 잘 이용해서 서로 윈윈하는 관계가 아닌가요?
매번 날을 세워야하는 관계는 아니지 않습니까!

상태변경 때 배송비가 초기화되는 것은 의도한 부분입니다.
주문 취소 후 다시 주문하는 경우 영카트5의 배송비 계산 부분이 여러 설정 등으로 인해 복잡하기 때문에
사용자 편의를 위해 상태 변경 때 배송비는 주문 상품을 기준으로 다시 계산돼서 표시가 됩니다.
그리고 상태 변경 후 결제 정보 수정에서 배송비를 변경하시면 그 배송비로 설정이 됩니다.
상태 변경 때 배송비가 변경되는 것이 문제라면 코드를 변경하시면 해결됩니다.

또한 여러 상품 주문 후 일부의 상품만 취소하는 경우 배송비가 다시 계산되어야 하기 때문에
상태 변경 때 배송비가 초기화가 되는 것입니다.

게르티님을 대신해서 사용자인 제가 직접 올립니다.

우선, 편리님께서 정말 그렇게 의도하셨는지 궁금하기는 하지만
혹시 모르실 수도 있다는 생각에 다시 알려드립니다.

주문의 주문 및 입금단계에서의 배송비 원복 문제는 솔찍히 별 상관이 없습니다.
말씀하신대로 취소 등의 사유로 자칫 간과할 수 있는 배송비부과에 대한 오류를 잡아 줄 수 있어서 기존 4에 비해 개선이라면 개선된 부분이라고 생각합니다.

그런데
문제는
입금단계에서 이미 수정완료된 사항이
배송처리를 하면 다시 원복된다는 겁니다.(여기까지도 그냥 넘어가라시면 그냥 가지요.)
그래서 다시 수정을 하겠죠?

근데
또다시 완료처리 단계에서 다시 원복됩니다.
이걸 버그라 하지 않으신다면 편리님의 그 닉넴이 미워질 것 같습니다.

그리고 그 수정의 주체는 고객이 아니라 관리자입니다.
그래서 고객이 일부수정을 하는 등의 작업을 하는 주문서(상태-주문)이 아닌
관리자 페이지에서 처리하게 되는 상태의 각 단계마다 (상태-입금, 상태-배송, 상태-완료) 적게는 한두번에서 많게는 세번까지 원복됩니다.
(고객이 수정하는 주문서에서의 원복은 물론 당연히 있어야되는 거구요)

조금 불편의 문제가 아니라(조금 불편한 정도라면 말도 안꺼냅니다)
입금처리를 하는 사람
배송처리를 하는 사람
완료처리를 하는 사람이 다른 경우엔
매번 원복되는 그 배송비 문제로 번번이 사유를 설명하는 등의 절차를 걸쳐야합니다.

물론 상점메모에 기록을 해두기는 하지만
불쑥불쑥 튀어나오는 미수금 내용을 일일이 단계마다 확인 및 수정을 해야한다는 건 적잖은 스트레스입니다.

그래서 일단 배송비를 0으로 처리하지 않고 결제취소/환불 금액에 마이너스 형태로 넣고 있는데
이게 매출취소 금액에 포함되지 않고 매출로 잡힌다는 2차적인 문제가 발생합니다.


예를들어
편리님의 급여가 10% 올랐다고 가정했을때
현재 편리님 회사에서 사용하고 있는 회계프로그램에 사장님께서 10% up을 입력하셨는데
(어떤 프로그램이든 급여를 자동 계산하는 프로그램이 있다고 가정할때)

회계담당자가 전표를 발행할때 이전 상태로 자동 원복이 되었다고 생각해 보세요.
다행이 이 회계담당자분께서 어떤 경로를 통해서든 그걸 알게되어 다시 10%up이 되도록 수정해 두었습니다.

그런데 프로그램에서 전표가 아닌 이체은행 및 계좌, 금액을 출력하는데 여기서 다시 원복이 되는 겁니다.

그런데 그 결과물을 출력하는 분이 직원들 급여금액은 별 관심이 없어서 그대로 출력해서
이체자료로 활용했다고 생각해 봅시다.

편리님은 누군가 문제를 발견하고 회계담당자나 사장님에게 말씀드리기 전까지는
10%up된 급여를 받으실 수 없습니다.

그때도 그 회계담당자나 사장님께 커스트마이징하시죠? 하실수 있을까요?
아마 그 회계 프로그램 만든 업체에 연락하면 그런 답이 돌아올 수는 있을 겁니다.
"커스트마이징하세요. 급여인상은 고려하지 않은 부분입니다."

말씀하신대로 커스트마이징을 하면 상관없는 부분입니다.
어디 이것 뿐이겠습니까
하나부터 열까지 커스트마이징하면 되는 것을요.
그리고 저희는 규모는 작지만 다행이 그정도는 감당이 가능한 업체입니다.

그런데
영카트가 좋다하여 개발을 해서 사용하는 작은 업체들을 생각해보면
이런 부분은 당연히 개선이 되어야된다고 봅니다.

코드 몇개 바꿔서 진행이 가능한 업체들은 별 상관이 없겠지만
지금 이런 문제조차 인식하지 못하고 있는 작은 업체들은
매출도 아닌 매출로 인하여 세금을 더 내고 계실거란 말이죠.

어디 디자인을 바꿔달라는 얘기도 아니고
데이터 상태의 자료를 가공해 달라는 얘기도 아닙니다.

단지
재고가 있으면 주문을 받을 수 있어야하고
(이 부분은 일부 수정이 된 걸로 알고 있습니다만 역시 만족스럽진 못하구요. 그때도 아마 커스트마이징하라고 하셨었죠? 그리고 얼마있다보니 수정이 되긴 했더군요.)
물건을 팔았으면 내가 얼마나 팔았는지 정도는 알 수 있어야하고
적어도 내가 수정한 데이터가
나도 모르는 사이에 원복되는 일은 없어야된다는 겁니다.

저희는 영카트 4를 7년이상 사용한 업체입니다.
저렴한 비용으로 그동안 재고관리며 회계관리며
불편한 곳은 일일이 고쳐가며 감사하며 사용하고 있었습니다.
그 감사의 바탕은 데이터에 대한 신뢰가 있었기 때문이었겠죠.
단지 모바일 버전에 대한 아쉬움으로 5로 바꿨다가 이런 귀한 시간을 낭비하기까지 하고 있네요.

그리고
저희가 말씀드리는 부분은
저희 몰의 특수성에 따라 발생하는 문제가 아니라
몰 운영상 언제든지 발생하게 되는 일반적인 문제입니다.

배송비 계산 문제를 해결하기 위해서는 특정 상황에서는 계산되고 그렇지 않은 경우는 계산되지 않다록 해야 합니다.
그런데 이 계산되는 상황이라는 것은 쇼핑몰마다 다를 수 있습니다. 묶음배송을 하지 않는 경우는 배송비가 변경되지
않기 때문에 배송비가 모든 단계에 새로 계산이 되도 아무런 문제가 없습니다. 모든 쇼핑몰이 묶음 배송을 해서 배송비를
수동으로 다시 입력하는 경우라고 가정을 해야한다는 말씀이신가요? 저로서는 그 가정을 받아들이기가 어렵기 때문에
현재와 같은 프로세스로 작동하도록 개발을 했습니다. 이 부분이 마음에 들지 않으신다면 커스터마이징을 하실 수 밖에
없습니다. 글로 이렇게 말씀을 하셔도 제가 이해를 하지 못하고 다양한 쇼핑몰 운영의 실제 경우의 수를 알 수 없고
그 모든 경우의 수에 대응하는 것은 불가능하기 때문에 프로그램을 수정할 수가 없는 것입니다. 프로그램을 수정하면
다른 어떤 쇼핑몰에서는 또 문제가 발생할 것입니다. 그 때 다시 수정하면 되지 않겠냐고 하시면 저두 할 말은 없습니다.

묶음배송은 어느 쇼핑몰에나 있을 수 있는 사안입니다.
편리님께서 같은 쇼핑몰에서 같은날 주문서를 두번 작성했는데 업체에서 프로그램에 반영이 안되니 묶음배송 안하겠다한다면 그게 말이 되는 건가요?
그리고
프로그램과 상관없이 묶음배송을 해줬다면
적어도 그 기록이 프로그램에는 남아야하는데 계속 원복되어 없어진다면 그것도 말이 안되죠.
계산기가 있는데
주판이나 손가락으로 계산하는 모양새가 되니까요.

그리고
4에서는 가능했었고 아무 문제 없었던 건들이 5에서 자꾸 발생된다면
고민은 해보셔야하는 것 아닐까요?
아님 4를 잘못 만드셨다는 얘기가 되네요.
그런걸 모르고 저흰 긴 시간을 고맙게 사용하고 있었던거구요.

묶음배송 없는 쇼핑몰이 있냐없냐의 문제가 아닙니다.

묶음배송 뿐아니라
말씀하신 특수사항으로 배송비가 평소보다 많이 나왔다면
그 입력한 금액이 그대로 있어야하는데
상태를 바꿀때마다 기본으로 원복되니...........

도대체 편리님이 어떤 생각을 하시는지 알수가 없네요.
편리님께서 원하시는대로 만들어서 편리님 혼자 쓰시는게 아니잖아요.

영카트5 개발초기 베타버전부터 묶음 배송에 대한 고려는 하지 않았다고 밝혀왔습니다.
이전 답변에 말씀드렸듯이 영카트5에 들어간 복잡한 배송비 설정 부분 때문에 배송비의 계산은
자동으로 되도록 한 것입니다. 만약 그 기능이 없으면 10개의 각기 다른 배송 설정을 가진
상품을 주문했을 때 일부 상품을 취소하는 경우 배송비 계산을 일일이 수동을 계산해서 입력을
해줘야만 하는데.. 이 부분은 불편한 부분이 아닙니까? 제 판단에는 이 부분이 더 중요하고
환불 등에서도 배송비 계산이 더 중요하다고 생각돼서 지금처럼 프로그램 코드를 작성했습니다.
이 부분에 대해서 동의를 하지 못하시니 문제가 되는 부분이라 생각합니다. 현재도 배송비 계산 부분이
저는 더 중요하다고 생각합니다. 따라서 프로그램의 코드를 수정하기는 어렵습니다.

입장의 차이가 많이 다름을 느낍니다.
저희쪽에서 다소 감정이 앞서나가는 부분도 있었고 납득하지 못하는 부분도 서로 있었던 것 같습니다.
분야는 다르지만 저도 십수년간 개발을 해온 사람이라 그 고충 조금이나마 이해를 합니다.

다만 조금 아쉬웠던 것 하나 말씀 드리자면..
영카트의 개발이 개인주도하에 개발되는 느낌을 많이 받습니다. 실제로 편리님 혼자서 개발을 하신다고 하시더라도 개발은 (주)에스아이알소프트에서 하는 것으로 인식을 합니다.
고객인 저의 입장은 개발자를 보고 솔루션을 선택하는 것은 아닙니다. 지금까지 쌓아온 회사의 성과나 명성을 더 많이 고려합니다.
솔직히 편리님이 회사에서 어떤 위치에 계신지는 모르겠지만 편리님의 개인 의견들이 들어간 영카트5로 인식이 됩니다. 설사 편리님이 영카트의 대표라 하더라도 법인에서 내놓는 솔루션에 대해서 개인적의 의견을 개입시키면 곤란하다는 생각입니다.
단순 게시판을 관리자라 하신다면 더 큰 문제일겁니다. 본인이 동의못한다는 것과 회사가 동의를 못한다는 것에는 많은 차이가 있습니다.
저희가 우려하는 것은 고객의 의견이 한 개인의 판단에 뭍혀버리는 것입니다. 업무의 특수성에 의한 문제가 되는 것은 말씀하신대로 자체적으로 커스트마이징합니다만 이 배송비 문제는 그 특수성에 의한 문제가 아니라는 판단에서 말씀을 드린것입니다.

길지않은 개발을 하면서 개발업무가 쉽지않다는 것입니다. 처음에 개발 자체가 힘들었고, 개발이 익숙해지니 고객이 쉽지 않았습니다. 업무가 쉽지가 않더니 지금은 그 균형이 쉽지가 않습니다.
하지만 그 과정에서 늘 일관되게 중요하게 생각했던 것 중의 하나가 중심에 뭐가 있나를 인식하는 것이었습니다. 현실을 추상화하는 과정에서 많은 착오들이 생겨납니다. 현실을 어떻게 그대로 전산화를 하겠습니까? 당연히 생겨나고, 오류도 생겨납니다.
때로는 차라리 수작업이 나은 경우도 발생합니다. 때로는 전산화가 나은 경우가 있지만 현업의 요구에 의해 개발이 되지 않기도 합니다. 하지만 하나의 원칙은 어떤 경우에도 업무의 복잡성이나 업무의 편리를 위한다는 명목으로 본 업무가 잘못되는 경우는 없어야 한다는 것입니다.

저희가 제기가 문제가 실제로 문제가 있는지 어떤지는 모르겠습니다. 저의 판단은 실제 운영하시는 분의 말씀을 듣고 테스트해보고 문제가 되겠다는 것이었습니다. 일단 데이터가 틀어지는 것이 보였기 때문입니다.

경기가 좋지 않은 때입니다. 저희도 그렇고 대부분의 업체가 어려움을 호소하고 있고, 다가오는 2015년도 불확실합니다. 여러가지 방안들을 모색해야하는 시기입니다. SIR도 마찬가지일 것이라 생각됩니다. 계획하고 계신 일들 잘 진행되길 바랍니다.

저희들의 댓글들이 단순히 진상짓이 아니라 이런 고객, 이런것을 어려워하고 있구나하고 생각해주시길 바랍니다.


PS.
어디다 글을 날길까 고민하다 여기다 글을 남깁니다.
그리고 마지막 댓글은 적절하지 않다 판단하여 삭제하였습니다. 상처가 되지 않길 바랍니다.

저 역시도 다른 개발일정 때문에 자세한 설명을 드리지 못한 점 사과드립니다.

좀 더 자세히 설명을 드리자면 말씀하신 대로 입금 단계 전까지는 배송비가 계산되고 그 이후는
상태를 변경해도 배송비가 다시 계산되지 않도록 할 수는 있습니다. 다만 여기서 한가지 문제가 될 수 있는
부분이 배송 단계에서 여러 개의 상품 중 일부를 취소 하는 등의 행위가 있을 때 배송 단계였기 때문에
배송비가 다시 계산이 되지 않는다는 것입니다. 이 때는 쇼핑몰 운영자가 수동으로 다시 배송비를 계산해야 하는
문제점이 생기게 됩니다. 그럼 취소 등의 행위 때 배송비를 다시 계산하게 하면 되지 않겠냐고 물으실 수 있습니다.
그러나 처음 문의해주셨던 대로 묶음배송으로 배송한 상품의 일부 취소인 경우 운영자가 입력한 배송비가 변경이 되면
안된다고 생각이 됩니다. 그런 걸 원하신다고 이해를 했습니다. 현재 구조에서는 이 상품을 묶음배송으로
배송한 것인지 단독으로 배송한 것인지를 확인할 수가 없기 때문에 무작정 배송비를 다시 계산하도록 하는 것도
결국은 문제를 일으키게 됩니다. 묶음배송임을 확인할 수 있는 필드 등을 추가하지 않은 상태에서 코드 수정은
말씀드린 것처럼 또 다른 문제가 발생할 여지가 많습니다. 현시점에서 필드 추가 등은 기존 사용자분들에게 불편을
드릴 수 있는 부분이 있기 때문에 신중하게 접근을 해야만 하고 기능 수정이 됐을 때는 또한 충분한 테스트가
진행이 되어야 합니다. 또한 문의해주신 내용에 대해서 실제 운영자가 아니기 때문에 충분히 이해를 할 수가 없습니다.
기능과 프로세스에 대해서 충분히 이해를 할 수 없는 상태에서의 여러 번의 코드 수정은 결국은 사용자분들에게 불편만을
드릴 뿐입니다. 이 부분때문에 패치 등은 최소화하려고 노력하고 있습니다.

말씀하신 부분에 대해서는 고려를 하고 있으며 사용자분들의 수정을 최소화하고 해결할 수 있는 방법을 찾으려고
하고 있습니다. 다만 그 해결책이라는 게 금방 떠오르지 않아 커스터마이징을 하시라고 말씀을 드렸던 것입니다.