먼저, 다음과 같은 예시를 살펴보겠습니다. 전체적인 그림 의 오라클 BRM 청구 프로세스가 수행합니다:
- 지난 달에 발생한 잔액 영향의 총 금액을 집계합니다. 여기에는 사용료와 구독료가 포함될 수 있습니다.
- 청구서와 관련된 모든 청구서 항목의 상태를 보류 중이던 것을 처리 중으로 변경하여 요금 누적을 중지하고 해당 항목에 결제를 적용할 수 있도록 합니다. 또한 청구서에 결제 기한이 추가됩니다.
- 신용카드 처리업체에 자동으로 결제를 요청하거나 인보이스를 전송하여 결제를 요청합니다.
- 결제가 BRM 데이터베이스에 기록되면 고객의 계정 잔액을 자동으로 업데이트합니다.
그렇다면 이 모든 것이 실제로 어떻게 이루어질까요?
프로덕션에서 brm 청구를 실행하기 전에 모든 사전 필수 단계를 실행해야 합니다. 첫 번째 단계는 프로덕션 환경의 복사본을 준비하는 것입니다. 이 환경은 사전 프로덕션 또는 일부 테스트 환경일 수 있습니다. 이 단계에는 이 환경에 최신 프로덕션 릴리스를 설치하고 프로덕션 데이터베이스를 복사하는 작업이 포함됩니다. 다음으로, 환경 구성은 프로덕션 환경의 구성을 반영해야 합니다. 다음은 적절하게 설정해야 하는 주요 구성입니다:
- cm 구성($HOME/pin/sys/cm/pin.conf)을 변경합니다,
o 직급 항목이 1로 설정되어 있는지 확인합니다.
o 에이전트 반환 매개변수의 항목을 0으로 변경합니다.
o simulate_agent 매개변수의 항목을 1로 변경합니다.
이 두 가지 마지막 변경 사항은 법안 실행 중에 프로비저닝 작업을 포함하지 않도록 하기 위해 수행되었습니다.
- dm_oracle 구성($HOME/pin/sys/dm_oracle/pin.conf)을 변경합니다,
o dm_bigsize 매개 변수를 8388608 이상으로 설정합니다.
o dm_shmsize 매개 변수를 33554432 이상으로 설정합니다.
o dm_n_fe를 8로 설정합니다.
o dm_max_per_fe를 16으로 설정합니다.
o dm_n_be를 24로 설정합니다.
o dm_trans_be_max를 22로 설정합니다.
- PIN_BILL_ACCTS 구성($HOME/pin/apps/pin_billd/pin.conf)을 변경합니다,
o 레벨을 확인합니다. 청구서 테스트 중에 확인해야 하는 항목에 따라 1 또는 3 중 적절한 값으로 변경합니다.
o 핀_빌드 및 핀_m타의 자식 매개변수를 5로 변경합니다.
o 핀_빌드 및 핀_타에 대한 per_batch 파라미터를 20000으로 변경합니다.
o 핀_빌드 및 핀_타에 대한 fetch_size 매개변수를 150000으로 변경합니다.
- PIN_INV_ACCTS 구성($HOME/pin/apps/pin_inv/pin.conf)을 변경합니다,
o 레벨을 확인합니다. 청구서 테스트 중에 확인해야 하는 항목에 따라 1 또는 3 중 적절한 값으로 변경합니다.
o 핀_빌드 및 핀_m타의 자식 매개변수를 5로 변경합니다.
o 핀_빌드 및 핀_m타의 per_batch 매개변수를 2000으로 변경합니다.
o 핀_빌드 및 핀_m타의 fetch_size 매개변수를 15000으로 변경합니다.
최상의 프로덕션 시뮬레이션을 얻으려면 빌런 핀_가상_시간을 프로덕션에서 실제 빌런이 실행되는 날짜로 설정해야 합니다. 이 작업이 완료되면 빌런을 시작할 수 있습니다.
시간당 약 100,000건의 청구서를 생성하는 pin_bill_day 스크립트를 사용하여 매월 청구를 실행합니다. 이 스크립트는 청구일이 청구일을 실행하는 날의 자정 이전인 계정에 대한 청구서를 생성합니다. 그렇다면 pin_billd_day 스크립트는 실제로 어떤 기능을 하나요? 다음 청구 유틸리티를 실행합니다:
- PIN_DEFERRED_ACT: 지연된 작업을 실행합니다. 예를 들어 계정이 비활성 상태가 되어야 하는 경우 이 유틸리티는 예약된 날짜에 상태 변경을 수행합니다.
- PIN_BILL_ACCTS: 계정의 미결제 잔액을 계산하고 미결제 잔액에 대한 청구서를 생성합니다.
- PIN_COLLECT: 신용 카드를 사용하는 계정의 미결제 잔액을 수금하고 직불 결제 방법을 안내합니다.
- PIN_REFUND: 환불 항목이 있는 계정을 찾아 온라인 환불 거래를 진행합니다.
- PIN_INV_ACCTS: 청구되는 각 계정에 대한 인보이스를 생성합니다.
- PIN_CYCLE_FEES: 고객의 계정에 이월 수수료 잔액 영향을 적용하고 보류 중인 취소 날짜가 만료된 상품을 취소합니다.
핀빌데이 스크립트의 진행 상황과 성능을 확인하기 위해 데이터베이스에 대한 쿼리를 실행하여 완료된 청구서 수, 아직 완료되지 않은 청구서 수, 오류가 있는 청구서가 있는지 등에 대한 정보를 얻습니다.
BRM 청구 부분이 끝나고 모든 청구서가 생성되면 인보이스 발행이 시작됩니다. 인보이스가 생성된 후에는 XML 문서로 내보낸 다음 PDF 형식으로 변환됩니다.
앞서 언급한 쿼리 외에도 청구 및 인보이스 발행이 완료된 후 이 프로세스에서 생성된 데이터의 정확성을 확인하기 위해 실행해야 하는 다른 쿼리도 있습니다. 다음은 몇 가지 쿼리를 일괄적으로 실행하는 예입니다:
- 청구가 실패했나요?
billinfo_t에서 * select * 여기서 청구_상태 = 4, bill_info_id'청구 단위(1)';
-예상 결과: 행을 찾을 수 없음
- 청구되지 않은 계정이 있나요?
SELECT PID_ID0, FIRST_NAME, SAME_NAME, A.STATUS FROM ACCOUNT_T A, ACCOUNT_NAMEINFO_T AN WHERE
a.poid_id0=an.obj_id0 및
created_t< 및
존재하지 않음(bill_t b에서 b.account_obj_id0 선택)
여기서 end_t= 및
b.account_obj_id0=a.poid_id0);
-예상 결과: 행을 찾을 수 없음
- 청구서 번호가 없는 청구서가 있나요?
bill_t에서 *를 선택합니다. 여기서 end_t=이고 bill_no는 null입니다;
- 예상됩니다: 행을 찾을 수 없음
발견된 모든 문제는 버전 관리 시스템을 통해 조사 및 수정되며, 수정 사항은 나중에 다음 릴리스 버전에 포함됩니다.
안녕하세요,
어떤 플랫폼을 사용하고 계신가요? 이 구현을 지원하기 위한 하드웨어의 크기는 어느 정도인가요?
감사합니다.
안녕하세요 아야줄,
우리 고객은 두 대의 HP-UX Intanium 서버를 사용합니다.
BRM 서버:
- 2 x HP Integrity RX6600
- 인텔 아이테니엄 듀얼 코어 1.8GHz 4개
- 64GB 메모리
- HP UX B.11.23 64비트
- 다중 Gbit 이더리움 및 4Gb FC
BRM DB 서버:
- 2 x IBM x36502
- 인텔 제온 듀얼 코어 3.16GHz 2개
- 48GB 메모리, 레드햇 엔터프라이즈 리눅스 4(나한트 업데이트 8)
- 4TB 디스크 스토리지 할당
- 다중 Gbit 이더리움 및 4Gb FC
- Oracle 10.2 EE RAC 데이터베이스
액티브/대기 모드에서 BRM에 사용되는 자동 스토리지 관리
미디에이션, 리포팅 및 기타 용도로 사용되는 보조 BRM 대기 DB RAC 노드
스토리지:
- 1 x HP XP 24000
- BRM 데이터베이스 ASM 관리용 전용 디스크
- 64GB 캐시4 BRM 데이터베이스를 위한 Gbit FC 대역폭
잘 부탁드립니다,
에일
동일한 계정에서 청구 한 후 일부 플랜은 인센티브가 발생하고 일부는 그렇지 않은 경우 플래그 또는 기타 필드 데이터가 누락 된 경우 발생하면 클래스 및 필드 유형을 알려주십시오 ........ 우리는 청구에 pin_bill_day를 사용하고 있습니다 ........
안녕하세요, 아비라미
일부 거래, 요금제 또는 제품이 결제 후 비활성 상태가 되는 데에는 여러 가지 이유가 있을 수 있습니다.
청구 스크립트는 하나 이상의 청구 유틸리티를 실행하며, 핀_청구_일은 다음 청구 유틸리티를 실행합니다:
* 핀_디퍼드_액트
* PIN_BILL_ACCTS
* 핀 수집
* 핀_환불
* PIN_INV_ACCTS
* 핀 입금
* PIN_CYCLE_FEES
핀_청구_일을 사용자 지정하여 실행할 청구 유틸리티를 지정하고 각 청구 유틸리티에 대한 매개변수를 설정하여 실행 방법을 지정할 수 있습니다.
기본적으로 pin_deferred_act 유틸리티는 pin_bill_day 스크립트에 포함되어 있으며 지연된 작업을 실행하는 데 사용됩니다. 예를 들어 CSR이 계정을 비활성 상태로 예약한 경우, pin_deferred_act 유틸리티는 예약된 날짜에 상태 변경을 수행합니다. 이는 청구 후 일부 요금제가 비활성 상태가 되는 가장 일반적인 이유입니다.
두 번째 이유는 pin_bill_day 스크립트에도 포함된 pin_cycle_fees 유틸리티를 실행하기 때문일 수 있습니다. pin_cycle_fees 유틸리티는 보류 중인 취소 날짜가 만료된 제품을 취소합니다. 예를 들어, 제품이 향후 날짜에 취소되도록 설정된 경우 pin_cycle_fees 유틸리티는 제품을 취소합니다.
앞서 언급했듯이 각 청구 유틸리티에 대한 매개 변수를 설정하여 실행 방법과 수행 할 작업을 지정할 수 있습니다. 먼저 일부 요금제를 활성화할 때 cycle_end_t(주기 종료 시간) 및 purchase_end_t(구매 종료 시간)를 설정하고, 결제를 실행할 때 상태 변경(귀하의 경우 비활성으로)을 트리거하는 날짜에 주의를 기울이는 것이 좋습니다.
제 답변이 도움이 되었기를 바랍니다. 자세한 설명을 위해서는 비활성 상태가되는 계정 (요금제)과 청구 유틸리티 구성에 대한보다 구체적인 정보가 필요합니다.
안부 인사, 알레스 시베틱
안녕하세요,
여기에 문제가 있습니다. 내 데이터베이스에는 사이클 포워드, 일회성, 사이클 체납의 세 가지 유형의 제품이 있습니다. 주기 연체 제품은 제품 목록에 그냥 포함되어 있습니다. 그러나 다음 달 1일에 핀빌데이를 실행할 때 시스템에서 두 개의 중복 이벤트가 생성되고 있습니다. 결과적으로 두 개의 동일한 라인이 인보이스에 반영되어 있어야하는 금액의 두 배로 인보이스가 생성됩니다. 초기 분석 후 두 개의 pin_bill_day 실행 파일로 인해주기 체납 제품에 대해 중복 줄이 발생하고 있음을 발견했습니다. 하나는 핀빌_accts이고 다른 하나는 핀사이클_수수료 입니다.
그래서 다음 달 1일 핀빌_날짜로 실행되는 핀주기_수수료에 대한 주기 연체 상품 수수료 계산을 필터링할 수 있는 방법을 알려주세요. 답변 부탁드리며 추가 설명이 필요한 경우 알려주세요.
감사합니다,
Sayan
안녕하세요,
Oracle BRM를 처음 사용하는데 배우고 싶습니다. 어디서부터 시작해야 하는지 알려주세요. 온라인에서 관련 문서를 구할 수 있나요?
안녕하세요,
인터넷 검색을 해보세요. 유튜브 동영상도 찾을 수 있고, Oracle BRM 문서도 찾을 수 있을 것입니다. Oracle 골드 파트너인 저희는 Oracle 커뮤니케이션 청구 및 수익 관리(약칭 Oracle BRM, OBRM, OCBRM) 책을 보유하고 있습니다. Oracle BRM 에센셜부터 시작하여 필요에 따라 계속 진행하실 것을 권장합니다(OCBRM 개발, OCBRM 파이프라인 개발, OCBRM 가격 책정, OBRM 관리 등).
감사합니다,
에일
제안해 주셔서 감사합니다.
"순방향 주기 부족"(대부분 로그에서 "프로토 / 호스트 이름 / 포트의 잘못된 구문 분석" 오류)에 대한 한 가지 문제가 있으며, "순방향 주기 부족" 사례가 여러 건 있는 것을 다시 발견했습니다.
""프로토 / 호스트 이름 / 포트의 잘못된 구문 분석"오류가 더 이상 감지되지 않습니다.
왜 그런 일이 발생했나요?
이 문제에 대한 해결책을 제시해 주시겠습니까?
안녕하세요,
질문이 있습니다. 지연 청구에 관한 질문입니다. 지연 청구를 사용 설정하면 어떤 영향이 있나요?
현재 청구서 실행과 관련하여 청구서를 두 번 실행하고 부분 청구 및 최종 청구를 실행해야하기 때문에 성능이 크게 저하되는 문제에 직면하고 있습니다. 현재 첫 번째 단계를 완료하는 데 2일 이상 소요되고 있으며, 데이터베이스 수준에서 추적된 문제는 "select poid_DB, poid_ID0, poid_TYPE, poid_REV from bal_grp_t where bal_grp_t에서 TX - 행 잠금 경합입니다.bal_grp_t.poid_id0의 업데이트에 대해 bal_grp_t.poid_id0으로 1순서를 지정합니다." 그리고 DB 파일을 순차적으로 읽습니다.
이 문제와 관련된 조언을 해 주실 수 있을 것 같습니다.
감사합니다.
안녕하세요 아야줄!
지연 청구를 사용하면 기본적으로 청구서를 생성하는 청구 주기보다 오래된 이벤트에 대해 청구할 수 있습니다. 청구해야 하지만 이미 청구가 완료된 청구 주기 중에 발생한 이벤트를 수신하는 경우 이 기능을 사용합니다. 예를 들어 국제 로밍을 제공하는 휴대폰 사업자의 경우 이벤트/통화가 완료된 후 최대 30일까지도 이벤트를 수신할 수 있으므로 "오래된" 이벤트도 청구해야 합니다.
청구 성능 문제와 언급된 SQL 문과 관련하여, bal_grp_t의 TX - 행 잠금 경합은 문제의 원인이 아니라 증상일 뿐입니다. 위의 SQL 문은 BRM에서 트랜잭션 내부를 잠그는 주요 메커니즘으로 사용되고 있습니다. BRM은 기본적으로 트랜잭션 내에서 수정되는 모든 객체를 잠그지 않습니다. 대신 객체가 수정되는 계정의 잔액 그룹만 잠급니다. 예를 들어 빌런 작업 중 또는 이벤트 충전 작업 중입니다.
이 행 잠금 경합은 계정의 작업/트랜잭션이 아직 완료되지 않았지만 다른 작업/트랜잭션이 이미 시작되어 동일한 객체에 대한 잠금을 요청하고 있으며, 당연히 첫 번째 작업이 커밋 또는 롤백을 수행하여 작업을 완료하고 트랜잭션을 완료하기를 기다리고 있다는 것을 보여줍니다.
빌런 중 느린 SQL 작업을 진단하려면 Oracle 데이터베이스 엔터프라이즈 관리자를 사용하여 성능, 상위 활동 섹션으로 이동하여 해당 시간에 실행 중인 상위 SQL 문을 관찰하면 됩니다. I/O를 많이 사용하거나 CPU를 과도하게 사용하는 경우 튜닝 후보가 될 수 있습니다. 때때로 SQL 옵티마이저에서 사용하는 데이터베이스 통계가 오래되어 옵티마이저가 차선책을 선택하는 경우가 있습니다. 기본 제공되지 않는 사용자 지정 청구 절차를 만드는 경우 새 인덱스를 만들거나 SQL 문을 변경해야 하는 경우도 있습니다.
마일리지가 다를 수 있으므로 이 블로그만으로 성능 문제를 진단하기는 어렵습니다. 때로는 잘못된 아키텍처 설계, 사용자 지정 코드, 잘못 조정된 데이터베이스 서버(예: 테라바이트 판매에만 열중하고 IOPS는 잊어버린 현대의 IT 영업 사원들처럼 데이터베이스용 디스크 스핀들이 충분하지 않은 경우)와 같이 근본적인 문제가 더 깊숙이 숨어 있을 수 있습니다.
잘 부탁드립니다,
오그젠 안토닉
안녕하세요,
Pin_billd와 Pin_bill_accts의 기능에는 어떤 차이가 있나요? 입력 매개변수는 어떻게 되나요?
balance_group과 아이템 및 이벤트의 차이점을 알고 싶으신가요?
안녕하세요,
고객센터 잔액 탭에 현재 잔액인 "bal_sub_bals_t" 테이블이 반영되지 않습니다. 무엇이 문제일 수 있나요? 그리고 이 문제를 해결하는 방법을 알려주세요. 도와주세요.
구독을 취소 한 고객이 있는데 환불을 해줘야하는데 신용 카드가 만료되어 처리 할 수없고 매달 불일치가 발생하므로 고객에게 신용 카드를 업데이트하라고 말하는 것 외에 이러한 문제를 해결하려면 어떻게해야합니까?
안녕하세요: 이전 게시물 중 하나(2011년 10월 28일, 관리자에 의해 작성됨)에 Oracle BRM 골드 파트너를 위한 Oracle 필수 도서에 대한 언급이 있습니다. 이 책에 액세스하는 방법에 대한 자세한 정보를 제공해 주시겠습니까? 이 책은 귀하가 판매하는 책인가요 아니면 Oracle에서 판매하는 책인가요? 미리 감사드립니다.
청구 및 인보이스 발행은 항상 단일 모드로 실행되므로 배치당_배치 값은 중요하지 않습니다.
안녕하세요,
BRM의 계정에서 생성할 수 있는 청구서 수에 제한이 있는지 알고 싶습니다.
그렇다면 어디서 확인할 수 있는지 알려주시기 바랍니다.
안부
기본적으로 제한이 없으며 계정당 청구서를 여러 개 발행할 수 있습니다. 이렇게 하려면 잔액 그룹을 더 만들고 각각 새로 만든 청구서 단위(/billinfo)에 할당해야 합니다.
자세한 내용은 다음을 참조하세요. http://ow.ly/TKGc308tB9F
안녕하세요 라나,
청구 및 인보이스 발행이 항상 단일 모드로 실행되는 것에 동의하지 않습니다. Per_batch 속성
는 배치 모드에서 각 워커 스레드가 처리하는 개체 수를 지정합니다.
더 많은 스레드에서 실행하려면 자식 속성을 2개 이상으로 설정해야 합니다.
자식 속성은 지정된 작업을 수행하기 위해 스폰되는 작업자 스레드 수를 지정합니다. 기본값은 5입니다.
이 예는 스레드가 10개인 구성을 보여줍니다.
- PIN_MTA CHILDREN 10
- PIN_MTA PER_BATCH 600
- PIN_MTA PER_STEP 1500
- PIN_MTA FETCH_SIZE 6000
감사합니다,
Igor
안녕하세요,
청구 및 인보이스는 어떻게 확인하나요?
모든 청구서가 생성되었는지 어떻게 확인하나요?
모든 인보이스가 생성되었는지 어떻게 확인하나요?
감사합니다,
Karl
PIN_BILL_ACCTS 및 PIN_INV_ACCTS 유틸리티 실행의 진행 상황, 성능 및 완료를 확인하는 쿼리 외에도 청구 및 인보이스 발행이 완료된 후 이러한 프로세스에서 생성된 데이터의 정확성을 확인하기 위해 실행할 수 있는 쿼리 집합이 있습니다. 쿼리는 다음과 같습니다:
- 이벤트와 아이템의 차이점은 무엇인가요?
SELECT I.ACCOUNT_OBJ_ID0,I.POID_ID0,I.NAME,ITEM_TOTAL,SUM(금액),SUM(금액)-ITEM_TOTAL
FROM EVENT_BAL_IMPACTS_EB,ITEM_T I
여기서 eb.item_object_id0=i.poid_id0
및 i.bill_obj_id0에서 (bill_t에서 poid_id0 선택 여기서 start_t=)
및 eb.resource_id=978
그룹 BY I.ACCOUNT_OBJ_ID0,I.PID_ID0,NAME,ITEM_TOTAL
합계(금액)-아이템_총계0 가 있음
합계(금액)-아이템_총계 desc 순으로 정렬합니다;
-예상: 행을 찾을 수 없음
John
Oracle BRM에서 성능 문제를 어떻게 해결하고 있나요?
Patrick
안녕하세요,
다음 Oracle BRM MTA 청구 유틸리티를 실행하면 다음과 같은 오류가 발생합니다:
[핀_빌드]$ 핀_빌_액츠 -v
PIN_BILL_ACCTS: 심볼 조회 오류: PIN_BILL_ACCTS: 정의되지 않은 심볼입니다:
pcm_set_multithread
[핀_빌드]$ 핀_콜렉트
핀콜렉트: 심볼 조회 오류: 핀콜렉트: 정의되지 않은 심볼입니다:
pcm_set_multithread
[핀_빌드]$ 핀_인브_액츠
PIN_INV_ACCTS: 심볼 조회 오류: PIN_INV_ACCTS: 정의되지 않은 심볼입니다:
pcm_set_multithread
도와주세요
지난 포스팅을 작성한 지 꽤 시간이 지났습니다. Oracle BRM 운영자에게 도움이 될 수 있는 몇 가지 SQL 쿼리를 공유하겠습니다. 블로그 보안 제한으로 인해 SLT를 대체하여 선택해야 합니다.
- 아이템이 있는데 청구서가 없는 계정이 있나요?;
SLT a.poid_id0,first_name,last_name,a.status
FROM ACCOUNT_T A,ACCOUNT_NAME_INFO_T AN
여기서 an.obj_id0=a.poid_id0
존재하지 않음 (bill_t b의 SLT 1
여기서 bill_no는 null이 아닙니다.
및 end_t=
및 b.account_obj_id0=a.poid_id0)
존재합니다(항목_t i에서 SLT 1
여기서 a.poid_id0=i.account_obj_id0
및 유효_t=
-항목_no가 널이 아닌 경우
및 item_total!=0.00)
및 a.created_t<
- 예상됩니다: 행을 찾을 수 없음
- 한 가지 더 방법;
SLT a.poid_id0,first_name,last_name,a.status
FROM ACCOUNT_T A,ACCOUNT_NAME_INFO_T AN
여기서 an.obj_id0=a.poid_id0
존재하지 않음 (bill_t b의 SLT 1
여기서 bill_no는 null이 아닙니다.
및 end_t=
및 b.account_obj_id0=a.poid_id0)
존재합니다(항목_t i,billinfo_t bi에서 SLT 1
여기서 a.poid_id0=i.account_obj_id0
및 i.account_object_id0=bi.account_object_id0
및 i.bill_object_id0=bi.last_bill_object_id0
및 item_total!=0.00)
및 a.created_t<
- 예상됩니다: 행을 찾을 수 없음
- 항목과 청구서 간에 차이가 있나요?) b,
SLT poid_id0 청구서,현재_총액 청구서_총계,항목_총계
from (SLT poid_id0,current_total from bill_t
여기서 end_t=
(SLT bill_obj_id0,sum(round(item_total,2)) item_total
item_t에서
그룹 BY BILL_OBJ_ID0) i
여기서 i.bill_object_id0=b.poid_id0
및 abs(current_total-item_total)>0.01입니다;
- 예상됩니다: 행을 찾을 수 없음
Oracle BRM 청구 및 인보이스를 확인하기 위해 몇 가지 SQL 쿼리를 추가하고 있습니다:
- 청구되지 않은 항목이 있나요?) 또는 상태=1 또는 AR_BILL_OBJ_ID0=0 또는 AR_BILLINFO_OBJ_ID0=0)
item_t i에서 SLTdistinct 계정_객체_id0,청구서_객체_id0
존재하는 경우
(bill_t b의 SLT1
여기서 b.poid_id0=i.bill_object_id0
및 end_t=
및 (effective_t!=
;
- 청구되지 않은 계정이 있나요?
SLTpoid_id0, 이름, 성, a.status
FROM ACCOUNT_T A, ACCOUNT_NAME_INFO_T AN
여기서 a.poid_id0=an.obj_id0
및 created_t<
존재하지 않음 (bill_t b의 SLTb.account_obj_id0
여기서 end_t=
및 b.account_obj_id0=a.poid_id0);
-예상 결과: 행을 찾을 수 없음
- 다른 방법);
billinfo_t bi의 SLT*
여기서 청구_상태=0
및 last_bill_t=
존재하지 않음
(SLT1 from bill_t b where b.account_object_id0=bi.account_object_id0
bill_no가 널이 아니고 end_t=.
-예상 결과: 행을 찾을 수 없음
- 청구서가 두 개 있는 계정이 있나요?
SLTcount(*),account_obj_id0
에서 bill_t
여기서 end_t=
계정_OBJ_ID0으로 그룹화
카운트(*)가 1이어야 합니다;
-예상 결과: 행을 찾을 수 없음
- 청구서 번호가 없는 청구서가 있나요?
bill_t의 SLT*
여기서 end_t=
이고 bill_no는 null입니다;
- 예상됩니다: 행을 찾을 수 없음
ldd libcmpin.so, libportal.so, libportal64.so 및 libpcmcpp67.so를 분석한 결과 이 오류의 근본 원인은 (경로 설정)과 관련이 있는 것으로 나타났습니다.
libportal.so => /brmdata/opt/ifw/lib/libportal.so (0xf76c7000)
변수를 확인하시기 바랍니다 $LD_LIBRARY_PATH , 기본적으로 IFW를 가리키고 있습니다.
오류를 수정하려면 실행하세요:
소스 $PIN_HOME/source.me.csh
를 클릭하고 작업을 계속합니다.
이제 Oracle BRM 유틸리티가 정상적으로 작동합니다.
첨부된 쿼리를 사용하여 Oracle BRM 청구 및 인보이스를 검토하고 있습니다.
- 청구서 번호가 중복된 청구서가 있나요?
인보이스_t에서 SLT count(*),bill_no
bill_no로 그룹화
카운트(*)가 1이어야 합니다;
- 예상됩니다: 행을 찾을 수 없음
- 청구에 실패하셨나요?
billinfo_t의 SLT *
여기서 청구_상태 = 4
- 및 bill_info_id<>'청구 단위(1)';
-예상 결과: 행을 찾을 수 없음
- 청구서에 청구서 정보가 제대로 표시되어 있나요?
SLT b.poid_id0,b.account_obj_id0,current_total,due,total_due,subords_total,parent_id0,bp.poid_id0
FROM BILL_T B,BILLINFO_T BI
여기서 b.account_object_id0=bi.account_object_id0
및 end_t=
및 (b.billinfo_obj_id0<>BI.PID_ID0 또는 B.AR_BILLINFO_OBJ_ID0<>BI.AR_BILLINFO_OBJ_ID0);
- 예상됩니다: 행을 찾을 수 없음
- 자녀를 위한 청구서에 부모 청구서가 제대로 있나요?
SLT b.poid_id0,b.account_obj_id0,b.current_total,b.due,b.total_due,b.subords_total,b.parent_id0
FROM BILL_T B,BILL_INFO_T BI,BILL_INFO_T BIP,BILL_T BP
여기서 b.account_object_id0=bi.account_object_id0
및 bi.poid_id0!=bi.ar_billinfo_obj_id0
및 bi.ar_billinfo_obj_id0=bip.poid_id0
및 bip.account_object_id0=bp.account_object_id0
및 b.end_t=
및 bp.end_t=
및 b.parent_id0<>bp.poid_id0;
- 예상됩니다: 행을 찾을 수 없음
- 어린이 요금이 맞나요?
SLT b.poid_id0,b.account_obj_id0,current_total,due,total_due,subords_total,parent_id0
FROM BILL_T B,BILLINFO_T BI
여기서 b.account_object_id0=bi.account_object_id0
및 bi.poid_id0!=bi.ar_billinfo_obj_id0
및 end_t=
및 (현재_총계<>만기 또는 서브오더_총계<>0 또는 parent_id0=0);
- 예상됩니다: 행을 찾을 수 없음
- 실제 부모님에게 청구하는 것이 맞나요?
SLT b.poid_id0,b.account_object_id0,current_total,due,total_due,subords_total,parent_id0,ar_hierarchy_size
FROM BILL_T B,BILLINFO_T BI
여기서 b.account_object_id0=bi.account_object_id0
및 bi.poid_id0=bi.ar_billinfo_obj_id0
및 end_t=
및 서브오더_총계<>0
및 (현재_총계<>0 또는 parent_id0<>0 또는 서브오더_총계<>만기 또는 AR_Hierarchy_SIZE=0);
예상됨: 행을 찾을 수 없음
- 자녀와 부모의 청구서 합계가 동일합니까?
SLT poid_id0,서브오더_총계,어린이.현재_총계
에서 bill_t b,
(SLT parent_id0,sum(current_tal) current_tal
FROM BILL_T WHERE PATH_ID0<>0
group by parent_id0) children
여기서 b.poid_id0=children.parent_id0
및 end_t=
및 children.current_total<>서브오더_총계;
- 예상됩니다: 행을 찾을 수 없음
- 청구서 정보 last_bill_t가 올바르게 설정되었나요? –01.01 ;
SLT distinct a.poid_id0,first_name,last_name,a.status,pin2date(last_bill_t)
FROM BILLINFO_T BI,ACCOUNT_T A, ACCOUNT_NAME_INFO_T AN
여기서 계정_객체_ID0=a.poid_id0
및 an.obj_id0=a.poid_id0
및 bi.last_bill_t!=
및 청구_상태가 (0,4)인 경우
및 a.created_t<
- 예상됩니다: 행을 찾을 수 없음
- 청구서 정보 next_bill_t가 올바르게 설정되었나요?;
SLT distinct a.poid_id0,first_name,last_name,a.status,pin2date(last_bill_t)
FROM BILLINFO_T BI,ACCOUNT_T A, ACCOUNT_NAME_INFO_T AN
여기서 계정_객체_ID0=a.poid_id0
및 an.obj_id0=a.poid_id0
and bi.next_bill_t!= 1201820400 -01.02
및 청구_상태가 (0,4)인 경우
및 a.created_t<
- 예상됩니다: 행을 찾을 수 없음
- 청구서 정보 미래_청구서_t가 올바르게 설정되었나요?;
SLT distinct a.poid_id0,first_name,last_name,a.status,pin2date(last_bill_t)
FROM BILLINFO_T BI,ACCOUNT_T A, ACCOUNT_NAME_INFO_T AN
여기서 계정_객체_ID0=a.poid_id0
및 an.obj_id0=a.poid_id0
및 bi.future_bill_t!=1204326000 -01.03
및 청구_상태가 (0,4)인 경우
및 a.created_t<
- 예상됩니다: 행을 찾을 수 없음
- 청구서 정보 last_bill_obj_id0이 생성되나요?;
SLT a.poid_id0,first_name,last_name,a.status
FROM BILLINFO_T BI,ACCOUNT_T A,ACCOUNT_NAME_INFO_T AN
여기서 계정_객체_ID0=a.poid_id0
및 an.obj_id0=a.poid_id0
존재하지 않음
(bill_t b의 SLT 1
여기서 b.poid_id0=last_bill_object_id0
및 b.account_object_id0=bi.account_object_id0
및 last_bill_t=end_t)
및 청구_상태가 (0,4)인 경우
및 a.created_t<
- 예상됩니다: 행을 찾을 수 없음
- 청구서 정보가 다음_청구서_객체_ID0이 생성되나요?;
SLT a.poid_id0,first_name,last_name,a.status
FROM BILLINFO_T BI,ACCOUNT_T A, ACCOUNT_NAME_INFO_T AN
여기서 계정_객체_ID0=a.poid_id0
및 an.obj_id0=a.poid_id0
존재하지 않음
(bill_t b의 SLT 1
여기서 b.poid_id0=bill_object_id0
및 b.account_object_id0=bi.account_object_id0
및 bi.last_bill_t=b.start_t)
및 청구_상태가 (0,4)인 경우
및 a.created_t<
- 예상됩니다: 행을 찾을 수 없음
- 빌인포 미래_빌_객체_ID0이 생성되나요?;
SLT a.poid_id0,first_name,last_name,a.status
FROM BILLINFO_T BI,ACCOUNT_T A, ACCOUNT_NAME_INFO_T AN
여기서 계정_객체_ID0=a.poid_id0
및 an.obj_id0=a.poid_id0
존재하지 않음
(bill_t b의 SLT 1
여기서 b.poid_id0=next_bill_object_id0
및 b.account_object_id0=bi.account_object_id0
및 bi.last_bill_t=b.start_t)
및 청구_상태가 (0,4)인 경우
및 a.created_t<
- 예상됩니다: 행을 찾을 수 없음
OK!!
- 인보이스가 생성되지 않은 청구서가 있나요?
SLT b.poid_id0,b.account_obj_id0,bill_no,due
FROM BILL_T B,BILLINFO_T BI
여기서 b.account_object_id0=bi.account_object_id0
및 b.end_t=
(10001,10007)에 pay_type을 입력합니다.
및 b.billinfo_obj_id0=b.ar_billinfo_obj_id0
존재하지 않음
(인보이스_t i의 SLT 1
여기서 i.bill_object_id0 = b.poid_id0);
예상됨: 행을 찾을 수 없음
- 청구서와 일치하지 않는 인보이스가 있나요?
SLT * 청구서_t b,인보이스_t i로부터
여기서 b.poid_id0=i.bill_object_id0
및 (b.bill_no<>i.bill_no 또는 b.end_t<>i.bill_date_t);
- 예상됩니다: 행을 찾을 수 없음
- 청구서 번호가 중복된 송장이 있나요?
인보이스_t에서 SLT count(*),bill_no
bill_no로 그룹화
카운트(*)가 1이어야 합니다;
- 예상됩니다: 행을 찾을 수 없음
잘 부탁드립니다,
에일