사용자 정의 스키마

시스템 스키마에 없는 내용을 문서에서 읽어야 할 때, 자신만의 스키마를 정의합니다.

언제 의미가 있는가

• 비표준 레이아웃의 공급자별 문서.
• 산업 특성: 무게 증명서, 시험 프로토콜, 연료 카드.
• 시스템에서 필요한 필드가 다른 곳에서는 나타나지 않는 경우.

자체 스키마의 문서는 회계로 전송되거나 회계 형식으로 내보낼 수 없다는 점을 유념해야 합니다 — 이러한 형식은 고정 필드를 읽습니다. 남은 형식은 JSON, XML, YAML, CSV, Excel 및 PDF입니다. 요약에 포함되려면 숫자 필드 TotalAmount가 있는 문서여야 합니다.

정의 방법

스키마 탭의 편집기에서. JSON 스키마 형식으로 작성합니다 — properties가 있는 객체, 각 필드는 type과 description, 목록은 array와 items로 기재합니다. 표준을 알고 있는 사람은 놀라지 않을 것이고, 모르는 사람은 템플릿(청구서, 부가세 포함 청구서, 영수증, 납품서, 최소형) 또는 시스템 스키마의 복사본으로 시작합니다. 템플릿의 필드는 시스템 스키마와 같은 영어 이름을 가지므로, 이들과 관련된 검증 양식에서 설명을 찾을 수 있습니다; 필드 설명은 인터페이스 언어로 되어 있으며 수정 가능합니다.

링크, allOf, oneOf, 조건 및 유사한 구조는 편집기에서 허용되지 않습니다; 스키마는 평면 필드 트리여야 합니다. 시스템 스키마의 복사본은 모델에 대한 정의도 가지고 있어 동일하게 인식할 수 있으며, 버튼 연결 해제를 통해 일반 사용자 정의 스키마로 변환됩니다.

필드 설명은 모델을 위한 가이드입니다

이것이 페이지에서 가장 중요한 사항입니다. description은 단순히 사람을 위한 것이 아니라 모델도 읽습니다. "주문 번호"와 "주문 번호, Z-로 시작하며 여섯 자리 숫자이고 바코드의 오른쪽 상단에 위치하는 경우"의 차이는 성공률에 엄청난 차이를 가져옵니다.

한계

필드 수는 요금제에 따라 다릅니다: Free 및 Starter에서는 80개, Business에서는 160개, Scale에서는 240개. 중첩 필드와 항목 필드도 포함됩니다. 이름과 설명은 각 문서에 대해 모델에 전송되므로, 긴 스키마는 더 비싼 처리 비용을 의미합니다.

시험하기

편집기는 문법을 지속적으로 검사하며 스키마가 맞지 않는 한 저장을 허용하지 않습니다. 실제 문서에서만 시험할 수 있습니다: 선택한 스키마로 문서를 업로드하거나, 완료된 문서에서 다시 처리를 선택합니다. 두 경우 모두 일반 처리와 같은 크레딧이 소모됩니다.

변경 및 삭제

수정된 스키마는 이후 처리에 적용됩니다. 이미 처리된 문서는 생성된 대로 데이터를 유지합니다. 적어도 한 문서가 인식된 스키마는 삭제할 수 없습니다 — 문서가 검증 양식을 잃게 됩니다.