기업은 제공할 수 있는 기회가 있습니다. 전자 보고특수 운영자뿐만 아니라 러시아 연방 세무 서비스 포털을 통해 직접. 지금까지는 시범사업이지만 국세청에 따르면 9월 말까지 서비스가 전면 가동될 예정이다. 그리고 이를 통해 3분기(9개월)에 대한 신고서를 제출할 수 있습니다. 이제 "정련"에 대해 연습할 수 있습니다. 동작 알고리즘은 다음과 같습니다.
1 . 전자 서명 및 가입자 ID 받기
연방 세무 서비스 웹 사이트를 통해 법정 대리인, 즉 이사 만 서명 한 신고서를 제출할 수 있지만 수석 회계사는 아닙니다. 이미 특수 사업자를 통해 신고한 업체는 기존 전자서명을 사용할 수 있습니다. 그러나 이전에 서면으로 만보고 한 사람들은 먼저 러시아 연방 세금 서비스 DTC 네트워크에 포함 된 인증 센터에서 인증서를 구입해야합니다 (목록은 웹 사이트 www.nalog.ru에 있음). 평균적으로 이것은 6-10,000 루블입니다.
회사가 웹사이트를 통해 보고할 예정임을 전문 운영자에게 알려야 합니다. 그래야만 특수 운영자가 러시아 연방 세금 서비스 포털에 회사를 등록하고 가입자 ID(보고를 보낼 수 없는 고유 코드)를 제공합니다.
2 . 전문 프로그램 설치
신고서를 작성하고 파일을 업로드하려면 "법인 납세자" 프로그램이 필요합니다. 웹 사이트 www.nalog.ru의 "법인 및 개인을 위한 소프트웨어" 섹션에서 무료로 다운로드할 수 있습니다. 모든 보고 데이터를 다시 입력할 필요는 없습니다. 컴퓨터에서 가져올 수 있습니다. 회계 프로그램또는 플래시 드라이브("서비스" > "자기 매체로부터 보고서 수신"). 성공적으로 준비되고 업로드된 파일은 "업로드된 파일 등록"("도구" 버튼)에 추가됩니다.
3 . 신고서가 있는 선적 컨테이너 형성
파일을 보내기 전에 디지털 서명 및 식별자와 함께 전송 컨테이너에 "포장"됩니다. 이렇게 하려면 "업로드된 파일 레지스트리"로 이동하여 선언이 있는 파일을 선택하고 도구 모음에서 "선적 컨테이너 생성" 버튼을 클릭해야 합니다.
4. 세무 서비스 포털을 통해 보고서 제출
보고서를 제출하려면 "EV에서 세금 및 회계 보고서 표시" 섹션에서 www.nalog.ru로 이동해야 합니다. 하지만 그 전에 다음을 확인하는 것이 좋습니다. 소프트웨어포털의 요구 사항을 충족합니다(예: 운영 체제이어야 한다 마이크로소프트 윈도우 XP, Vista 또는 7 및 브라우저는 Microsoft 인터넷 익스플로러 6.0 이상 또는 Safari 4.0 이상). 이렇게 하려면 "조건 확인 수행" 링크를 클릭하십시오. 검사가 성공적으로 끝나면 배송 컨테이너를 내리고 검사실로 보낼 수 있습니다.
5 . 보고서가 검사에 제출되었는지 확인
중앙 집중식 데이터 처리를 위한 지역 간 검사는 포털을 통해 보고서를 보낼 때 특수 운영자 역할을 합니다. 선언 수락 확인에서 그녀는 영수증을 보냅니다. 신고서 제출일은 영수증에 신고서를 발송한 날짜로 기재된 날짜입니다(러시아 연방 세법 80조 4항). 다만, 신고내용이 형식논리적 통제를 통과하지 못한 경우에는 접수거부 및 사유를 신고합니다. 제거된 경우 보고서를 다시 제출할 수 있습니다.
이 기사는 신문 "UNP"No.30에 게재되었으며,
JSC GNIVTs(러시아의 FTS): 2016년 8월 5일 모스크바 시간 05:00부터 FDC 사이트의 기술 작업으로 인해 GP-3 수신 단지의 연방 수준 구성 요소(GPK, SM, IRUD, SP FU)가 사용할 수 없습니다. 예상 완료 시간은 모스크바 시간 12:00입니다.동시에 Link-Service 회사는보유할 것이다 엔지니어링 작업. 메일 서버 주어진 시간이메일을 보내거나 받지 못할 수 있습니다. 불편에 대해 사과드립니다.게시일 8월 4일 2016 10:55 Vyacheslav Abisalov 작성
게시일 1월 19일 2016, 04:51 작성자: Vyacheslav Abisalov
게시일: 1월 18일 2016, 08:22 작성자: Vyacheslav Abisalov
12월 8일 제출 2015, 11:24 작성자: Vyacheslav Abisalov
12월 6일 제출 2015, 13:49 작성자: Vyacheslav Abisalov
전자 디지털 서명을 사용하는 통신 채널을 통해 세무 당국의 수신 콤플렉스와 정보 상호 작용하는 운송 컨테이너의 통합 형식
1. 용어 및 정의1.1. 전자 전자 서명(EDS) - 정보의 암호화 변환의 결과로 얻은 이 전자 문서를 위조로부터 보호하도록 설계된 전자 문서의 속성으로 서명 키 인증서의 소유자를 식별하고 정보 왜곡이 없는지 확인할 수 있습니다. 전자 문서에서.
1.2. 서명 키 인증서(인증서) - 인증 기관(이하 CA라고 함)의 권한이 있는 사람의 EDS가 있는 종이 문서 또는 전자 문서로, 공개 키를 포함하고 인증 확인을 위해 CA에서 발급합니다. EDS의 소유자를 식별하고 전송된 정보의 기밀성을 보장합니다.
1.3. 전자 문서 (문서) - 형식의 요구 사항에 따라 전자 형식으로 제시된 문서 이 유형의문서.
1.4. 트랜잭션 - 특정 유형의 워크플로 프레임워크 내에서 문서 및 EDS가 포함된 컨테이너를 전송하는 단일 단계로, 전송된 문서 세트, EDS, 보낸 사람 및 받는 사람을 결정합니다.
1.5. 전자 문서 관리(문서 흐름) - 문서 교환에 대한 일부 규제 프로세스를 제공하는 문서 흐름 참가자 간의 문서 교환을 위한 일련의 거래(예: 세금 신고서(회계 보고서) 제출을 위한 문서 흐름) .
1.6. 운송 컨테이너 - 논리적으로 관련된 문서 및 EDS 및 관련 운송 정보 세트가 하나의 파일로 결합됩니다.
1.7. 가입자 - 납세자 또는 납세자의 권한 있는 대리인인 정보 상호 작용에 등록된 참가자입니다.
1.8. NBO - 세금 신고(계산), 재무제표 및 세금 및 수수료 계산 및 지불의 기초가 되는 기타 문서.
2. 일반 정보2.1. 이 문서형성 및 처리된 운송 컨테이너의 구조를 설명합니다. 소프트웨어 도구납세자가 세금 신고 (계산), 재무 제표 및 기타 문서를 제출할 때 전자 문서 관리 조직을 보장하기 위해 EDS를 사용하여 전기 통신 채널을 통해 전자 형식으로 전문 통신 사업자 및 가입자와 정보 상호 작용하는 동안 세무 당국 세금 및 수수료 계산 및 지불. 워크플로 유형 목록은 이 문서의 부록 4 - 11에 나와 있습니다.
2.2. 정보 상호 작용은 거래를 통한 문서 흐름의 구현을 통해 발생합니다. 문서 흐름의 한 참가자에서 문서의 관련 참가자의 권한 있는 사람을 대신하여 이 거래에 대해 고정된 일련의 문서 및 EDS가 있는 다른 운송 컨테이너로 전송 흐름.
2.3. 특정 유형의 워크플로에 대해 달리 지정하지 않는 한 워크플로 동안 문서는 압축 및 암호화된 형식으로 전송됩니다. 문서 아래의 EDS는 일반 텍스트로 전송됩니다.
2.4. 각 워크플로 유형에 대해 사용된 서비스 형식 및 기술 문서는 웹사이트 www.nalog.ru에 게시된 워크플로 유형 참조서에 나와 있습니다.
3. 용기 구성에 대한 일반 요구 사항3.1. 선적 컨테이너의 내용물
전송 컨테이너는 다음을 포함하는 zip 아카이브입니다.
전송 정보가 포함된 파일 XML 형식;
전송된 문서의 내용이 포함된 파일의 Zip 아카이브
문서 설명이 포함된 파일의 Zip 아카이브;
전송된 EDS의 내용이 포함된 파일.
운송 컨테이너의 계획은 그림 1에 나와 있습니다.
그림 1. 운송 컨테이너의 구성도(미도시)
3.1.1. 문서 및 디지털 서명의 내용이 포함된 파일은 "" 형식의 범용 고유 식별자를 사용하여 이름이 지정됩니다.
3.1.2. 문서 및 디지털 서명의 내용이 포함된 전송 정보 및 파일은 STORE 모드에서 zip 아카이브로 결합됩니다. 전송 정보 파일은 전송 컨테이너로 전송될 때 압축되거나 암호화되지 않습니다.
3.1.3. 하나의 트랜잭션과 관련된 문서 및 EDS는 하나의 운송 컨테이너로 전송됩니다.
3.1.4. 문서 설명이 전송되는 문서 유형에 따라 결정되는 경우 문서 설명은 별도의 zip-archive로 운송 컨테이너에 있습니다. 문서 설명 형식은 이 문서의 부록 1에 나와 있습니다. 문서 설명에는 전송된 파일에 대한 추가 정보가 포함되어 있으며 참고용입니다. 이 문서는 전송 컨테이너 파일을 해독할 수 없을 때 보다 유익한 진단 메시지를 제공하는 데 사용할 수 있습니다.
3.1.5. 운송 정보 기술 형식은 이 문서의 부록 2에 나와 있습니다.
3.2. 전송 컨테이너 파일 이름
3.2.1. 전송 컨테이너는 형식에 따라 고유한 이름을 가진 파일로 전송됩니다.
3.2.4. 컨테이너에 문서가 여러 개 있는 경우 전송 컨테이너의 파일 이름에는 트랜잭션 유형 이름에 이름이 포함된 문서의 코드가 표시됩니다.
3.2.5. 파일 이름의 정보는 컨테이너의 전송 정보에 있는 해당 정보와 일치해야 합니다.
3.3. 문서 콘텐츠 유형에 대한 설명은 이 문서의 부록 3에 나와 있습니다.
3.4. 워크플로 유형에 대한 요구 사항은 이 문서의 부록 4 - 11에 나와 있습니다.
4. 문서흐름 참여자의 유형 및 식별4.1. 워크플로는 워크플로의 다음 참가자 간에 수행됩니다.
4.3. SOUN 분류자의 코딩에서 세무당국의 4자리 코드는 세무당국의 식별자로 사용된다.
4.4. 러시아 연방세청에서 결정한 고유한 3자리 코드는 전문 통신 사업자 및 신뢰할 수 있는 인증 기관의 식별자로 사용됩니다.
4.5. 구독자 ID 형식은
| <префикс системы><код абонента> |
<префикс системы>- 이것은 전문 통신 사업자 또는 신뢰할 수 있는 인증 기관의 식별자입니다. 길이<префикса системы>3자입니다.<префикс системы>가입자가 서비스를 사용하는 전문 통신 사업자의 식별자와 일치해야 합니다.
<код абонента>에서 사용되는 고유한 가입자 코드입니다. 내부 시스템전문 통신 사업자 또는 신뢰할 수 있는 인증 기관 길이<код абонента>최대 43자.
5. 사용기술의 명세5.1. 범용 고유 식별자
5.1.1. UUID(Universally Unique Identifiers)는 워크플로, 문서를 식별하고 전송 컨테이너에서 파일 이름을 생성하는 데 사용됩니다.
5.1.2. 사용되는 보편적으로 고유한 식별자는 다음에 따라 생성되어야 합니다. 일반 원칙 RFC 4122(http://www.ietf.org/rfc/rfc4122.txt)에 설명된 대로 UUID 생성. 범용 고유 식별자는 소문자로 작성된 32자리 16진수로 표시됩니다.
5.2. 파일 결합 및 압축
5.2.1. zip 아카이브 형식은 여러 문서를 단일 배송 컨테이너로 결합하고 문서를 압축하는 데 사용됩니다.
5.2.2. zip 아카이브 형식은 http://www.pkware.com/documents/casestudies/APPNOTE.TXT에 있는 공개 사양에 설명되어 있습니다. 에 따라 보관해야 합니다. 기본 능력버전 2.0(암호화를 사용하지 않음).
5.2.3. 문서에는 압축 전에 "파일"이라는 이름이 지정되고 그 후에 아카이브에 저장됩니다. 아카이브의 이름은 3.1.1절에 따라 구성됩니다. 아카이브에서 문서를 추출할 때 전송 정보 설명 파일의 정보를 사용하여 원본 파일 이름을 복원합니다.
5.3. 암호화
5.3.1. 암호화의 경우 알고리즘 GOST 28147-89가 사용됩니다. 알고리즘 GOST R 34.10-2001은 EDS를 구성하는 데 사용됩니다.
5.3.2. 암호화된 데이터 및 EDS는 PKCS #7 컨테이너(RFC 2315, /content/base/)를 사용하여 전송됩니다. DER 인코딩은 파일에 저장하는 데 사용됩니다.
5.3.3. 암호화된 데이터는 EnvelopedData 구조를 콘텐츠로 사용하여 ContentInfo 구조로 전달됩니다.
5.3.4. 디지털 서명은 콘텐츠로 SignedData 구조가 있는 ContentInfo 구조로 전송됩니다. 디지털 서명에는 인증서가 포함될 수 있으며 서명된 콘텐츠는 포함되지 않아야 합니다.
5.3.5. 기본 운송 컨테이너의 일부로 전송된 문서의 암호화는 다음 주소로 이루어져야 합니다. 공개 키암호화를 위해 지정된 수신자의 인증서 및 발신자 인증서의 공개 키. 수신 문서를 수신 또는 처리한 결과 전송된 문서의 암호화는 암호화를 위해 지정된 수신자 인증서의 공개 키 주소, 보낸 사람 인증서의 공개 키 및 해당 공무원의 인증서 공개 키 주소로 수행됩니다. 들어오는 문서에 서명했습니다.
6. 통신 채널을 통해 전자 형식으로 세금 신고서 및 재무 제표를 제출하기 위한 통합 시스템과 상호 작용할 때 메일 메시지 구성에 대한 일반 요구 사항메시지 형식의 SMTP 및 POP3 프로토콜을 사용하여 세무 당국의 통합 수신 단지의 전자 문서 교환을 위해 전문 통신 사업자와 서버 간의 메시지 교환을 사용하는 경우 이메일구조 요구 사항 메일 메시지이 문서의 부록 12에 나와 있습니다.
승인됨
러시아 연방세청 명령
에서 " 19
» 04
2012년
№ MMV-7-6/ [이메일 보호됨]
통합 배송 컨테이너 형식
수신 단지와 정보 상호 작용 중
통신 채널을 통한 세무 당국
전자 서명을 사용하여
1. 용어 및 정의
1.1. 전자문서(문서) -이 유형의 문서 형식 요구 사항에 따라 전자 형식으로 제출된 문서.
1.2. 거래- 서류가 담긴 컨테이너 이송 1단계 및 전자 서명전송된 문서 세트, ES, 보낸 사람 및 받는 사람을 결정하는 특정 유형의 워크플로 프레임워크 내에서 필요한 유형(ES)입니다.
1.3. 전자문서관리(문서관리)- 문서 교환에 대한 일부 규제된 프로세스를 제공하는 문서 흐름 참가자 간의 문서 교환을 위한 일련의 거래(예: 세금 신고서(회계 보고서) 제출을 위한 문서 흐름).
1.4. 선적 컨테이너- 논리적으로 관련된 문서 및 ES 및 관련 전송 정보의 집합이 하나의 파일로 결합됩니다.
1.5. 구독자- 납세자 또는 납세자의 권한 있는 대리인인 정보 상호 작용에 등록된 참가자.
1.6. NBO -세금 신고(계산), 재무 제표 및 세금 및 수수료 계산 및 지불의 기초가 되는 기타 문서.
2. 일반 정보
2.1. 이 문서는 납세자가 제출할 때 전자 문서 관리의 조직을 보장하기 위해 ES를 사용하는 통신 채널을 통해 전자 형식의 전문 통신 사업자 및 가입자와 정보 상호 작용하는 과정에서 세무 당국의 소프트웨어에 의해 생성 및 처리되는 운송 컨테이너의 구조를 설명합니다. 세금 신고서(계산), 재무 제표 및 세금 및 수수료의 계산 및 지불을 위한 기초 역할을 하는 기타 문서. 워크플로 유형 목록은 이 문서의 부록 4-11에 나와 있습니다.
2.2. 정보 상호 작용은 거래를 통한 문서 흐름의 구현을 통해 발생합니다. 문서 흐름의 한 참가자에서 문서의 관련 참가자의 권한 있는 사람을 대신하여 이 거래에 대해 고정된 문서 및 ES 세트가 있는 다른 운송 컨테이너로 전송 흐름.
2.3. 특정 유형의 워크플로에 대해 달리 지정하지 않는 한 워크플로 동안 문서는 압축 및 암호화된 형식으로 전송됩니다. 문서 아래의 ES는 공개 형식으로 전송됩니다.
2.4. 각 워크플로 유형에 대해 사용된 서비스 형식 및 기술 문서는 웹 사이트 www.에 게시된 워크플로 유형 디렉토리에 제공됩니다. *****
3. 일반적인 요구 사항용기의 구성에
3.1. 선적 컨테이너의 내용물
전송 컨테이너는 다음을 포함하는 zip 아카이브입니다.
- xml 형식의 전송 정보가 있는 파일 전송된 문서의 내용이 포함된 파일의 zip 아카이브 문서에 대한 설명이 포함된 파일의 zip 아카이브; 전송된 ES의 내용이 포함된 파일
운송 컨테이너의 계획은 그림 1에 나와 있습니다.
마이크로소프트" href="/text/category/microsoft/" rel="bookmark">마이크로소프트 워드, 마이크로 소프트 엑셀, Open Document Text, Document Spreadsheet, Open XML Word 및 스캔한 이미지가 포함된 Open XML Spreadsheet에는 다음 요구 사항이 적용됩니다. 흑백 이미지 256가지 회색 음영을 사용하여 150dpi 이상 300dpi 이하의 스캔한 문서 해상도.
3.4. 워크플로 유형에 대한 요구 사항은 부록 4 - 11에 나와 있습니다. , 이 문서에 1.
4. 문서흐름 참여자의 유형 및 식별
4.1. 워크플로는 워크플로의 다음 참가자 간에 수행됩니다.
상징 | 설명 |
구독자 | 납세자( 실재또는 개인 기업가) 또는 그의 권한 있는 대리인 |
세무 당국 | 러시아 연방 세무국 세무 당국 |
특수 연산자 | 전문 통신사 |
신뢰할 수 있는 CA | 러시아 연방 세무 서비스의 신뢰할 수 있는 CA 네트워크에 포함된 인증 기관 |
4.2. 문서 흐름 참가자의 식별자는 라틴 문자 a–z, 0–9, "@", "."로 구성됩니다. 그리고 "-". 식별자는 대소문자를 구분하지 않습니다.
4.3. SOUN 분류자의 코딩에서 세무당국의 4자리 코드는 세무당국의 식별자로 사용된다.
4.4. 러시아 연방세청에서 결정한 고유한 3자리 코드는 전문 통신 사업자 및 신뢰할 수 있는 인증 기관의 식별자로 사용됩니다.
4.5. 구독자 ID 형식은
<префикс системы><код абонента>
<префикс системы>전문 통신 사업자 또는 신뢰할 수 있는 인증 기관의 식별자입니다. 길이<префикса системы>3자입니다.<префикс системы>가입자가 서비스를 사용하는 전문 통신 사업자의 식별자와 일치해야 합니다.
<код абонента>전문 통신 사업자 또는 신뢰할 수 있는 인증 센터의 내부 시스템에서 사용되는 고유한 가입자 코드입니다. 길이<код абонента>최대 43자.
5. 사용기술의 명세
5.1. 범용 고유 식별자
5.1.1. UUID(Universally Unique Identifiers)는 워크플로, 문서를 식별하고 전송 컨테이너에서 파일 이름을 생성하는 데 사용됩니다.
5.1.2. 사용된 UUID는 RFC 4122(http://www.ietf.org/rfc/rfc4122.txt)에 설명된 대로 UUID 생성을 위한 일반 원칙에 따라 생성되어야 합니다. 범용 고유 식별자는 소문자로 작성된 32자리 16진수로 표시됩니다.
5.2. 파일 결합 및 압축
5.2.1. zip 아카이브 형식은 여러 문서를 단일 배송 컨테이너로 결합하고 문서를 압축하는 데 사용됩니다.
5.2.2. zip 아카이브 형식은 http://www에서 사용할 수 있는 공개 사양에 설명되어 있습니다. /documents/casestudies/APPNOTE. txt. 암호화를 사용하지 않고 버전 2.0의 기본 기능에 따라 보관해야 합니다.
5.2.3. 문서에는 압축 전에 "파일"이라는 이름이 지정되고 그 후에 아카이브에 저장됩니다. 아카이브의 이름은 단락 3.1.1에 따라 구성됩니다. 아카이브에서 문서를 추출할 때 전송 정보 설명 파일의 정보를 사용하여 원본 파일 이름을 복원합니다.
5.3. 암호화
5.3.1. 암호화에 사용되는 알고리즘 고스트. 알고리즘은 ES를 생성하는 데 사용됩니다. GOST R 34.10-2001.
5.3.2. 암호화된 데이터 및 ES는 PKCS #7 컨테이너(RFC 2315, http://www.ietf.org/rfc/rfc2315.txt)를 사용하여 전송됩니다. DER 인코딩은 파일에 저장하는 데 사용됩니다.
5.3.3. 암호화된 데이터는 구조로 전송됩니다. 콘텐츠 정보구조로 EnvelopedData내용으로.
5.3.4. EP는 구조로 전송됩니다. 콘텐츠 정보구조로 서명된 데이터내용으로. ES는 관련 인증서를 포함해야 하며 서명한 문서를 포함해서는 안 됩니다.
5.3.5 기본 전송 컨테이너의 일부로 전송된 문서의 암호화는 암호화를 위해 지정된 수신자 인증서의 공개 키 주소와 보낸 사람 인증서의 공개 키 주소로 수행되어야 합니다. 수신 문서를 수신 또는 처리한 결과 전송된 문서의 암호화는 암호화를 위해 지정된 수신자 인증서의 공개 키 주소, 보낸 사람 인증서의 공개 키 및 해당 공무원의 인증서 공개 키 주소로 수행됩니다. 들어오는 문서에 서명했습니다.
6. 통신 채널을 통해 전자 형식으로 세금 신고서 및 재무 제표를 제출하기 위한 통합 시스템과 상호 작용할 때 메일 메시지 구성에 대한 일반 요구 사항
이메일 메시지 형식의 SMTP 및 POP3 프로토콜을 사용하여 세무 당국의 통합 수신 단지의 전자 문서 교환을 위해 전문 통신 사업자와 서버 간의 메시지 교환을 사용할 때 메일 메시지 구조에 대한 요구 사항은 다음과 같습니다. 이 문서의 부록 12에 명시되어 있습니다.
나. NBO 문서 설명 형식
(버전 02)
1. 일반
1.1. 목적
이 문서는 운송 컨테이너(이하 교환 파일이라고 함)에 포함된 NBO 문서에 대한 정보의 전자 전송을 위한 XML 파일에 대한 요구 사항을 설명합니다.
2. 교환 파일의 설명
TR_DEKL_2_700_02_09_02_xx, 여기서 xx는 현재 버전계획.
파일 확장자는 xsd입니다.
체재 문자열 T(n-k) 또는 T(=k) 형식으로 표시됩니다. 여기서 n은 한 줄에 있는 최소 문자 수, k - 최대 금액문자, 기호 "-"는 구분 기호, 기호 "="는 정액줄당 문자 수. 최소 문자 수가 0이면 형식은 T(0-k)입니다. 최대 문자 수가 무제한인 경우 형식은 T(n-)입니다. 요소의 길이가 불확실한 경우 형식은 T입니다.
· 추가 정보. 복잡한 요소의 경우 이 요소의 구성을 설명하는 표에 대한 링크가 제공됩니다. 분류기(코드 사전 등)에서 제한된 값 목록을 취하는 요소의 경우 분류기(코드 사전 등)의 해당 이름이 표시되거나 목록이 제공됩니다. 가능한 값. 분류기(코드 사전 등)의 경우 해당 위치에 대한 참조가 표시될 수 있습니다. 사용자 정의 데이터 유형을 사용하는 요소의 경우 유형 요소의 이름이 지정됩니다.
3. 파일 교환 다이어그램
그림 1. Exchange 파일 구조 다이어그램
4. 교환 파일의 논리적 모델의 구조적 요소 목록
교환 파일의 논리적 모델의 구조적 요소 목록은 표에 나와 있습니다. 4.1
표 4.1 |
||||||||||
양도된 NBO 문서에 대한 설명(설명) |
||||||||||
요소 이름 | 요소의 약칭(코드) | 요소 유형 속성 | 요소 형식 | 필수 요소 표시 | 추가 정보 |
|||||
이전된 NBO 문서 형식의 이름 | 이름 양식 | |||||||||
전송된 문서의 KND NBO | KNDForms | |||||||||
이전된 문서 유형 NBO | 문서의 종류 | "기본" 또는 "수정" 값을 허용합니다. |
||||||||
NBO 문서가 제출된 보고 연도 | 일반 요소 |
|||||||||
NBO 문서가 전송되는 기간의 코드 | 코드 기간 | 세금(신고) 기간을 정의하는 코드 디렉토리(SKNP)에 따라 NBO 문서가 전송되는 기간의 코드 신고서에 명시된 세금(신고) 기간과 일치 보고서에 포함된 경우 필수 |
||||||||
가입자가 등록된 세무 당국의 코드 | NPO 위치회계 | 일반 요소<СОНОТип> |
||||||||
NBO 문서가 전송되는 과세 대상 관리가 수행되는 세무 당국의 코드 | NPO위치 | 일반 요소<СОНОТип>세무 당국 지정 시스템 분류기의 코드 |
||||||||
추가 정보 | 일반 요소 |
|||||||||
II. 이의 제기, 서신 및 메일링 리스트에 대한 설명 형식
(버전 02)
1. 일반
1.1. 목적
이 문서는 항소, 서신 및 배포에 대한 설명에 대한 정보의 전자 전송을 위한 XML 파일에 대한 요구 사항을 설명합니다.
2. 교환 파일의 설명
2.1. 교환 파일에 대한 일반 정보
교환 파일의 이름은 다음과 같아야 합니다.
파일 이름 확장자는 xml입니다. 파일 이름 확장자는 소문자와 대문자로 지정할 수 있습니다.
교환 파일의 첫 번째 줄의 매개변수
XML 파일의 첫 번째 줄은 다음과 같아야 합니다.
교환 파일의 스키마가 포함된 파일 이름
교환 파일의 XSD 스키마가 포함된 파일 이름은 다음과 같아야 합니다.
TR_PISRAS_2_700_03_09_02_xx, 여기서 xx는 현재 스키마 버전입니다.
파일 확장자는 xsd입니다.
2.2. 교환 파일의 논리적 모델
파일의 논리적 모델은 그림 1의 섹션 3에 그래픽으로 표시됩니다. 교환 파일의 논리적 모델의 요소는 XML 파일의 요소와 속성입니다. 논리 파일 모델의 구조적 요소의 전체 목록과 이에 대한 정보는 섹션 4에 나와 있습니다.
논리 파일 모델의 각 구조 요소에 대해 섹션 4는 다음 정보를 제공합니다.
· 요소의 이름. 요소의 전체 이름이 제공됩니다.
· 요소의 약칭. 요소의 약어 이름이 제공됩니다. 약어는 문자와 숫자로 작성할 수 있습니다.
· 요소 유형의 기호. 다음 값을 사용할 수 있습니다. "C" - 복잡한 요소(중첩된 요소가 있음), "P" - 단순 요소(중첩된 요소가 없음); A는 속성입니다. 사용자 정의 데이터 유형을 사용하여 요소를 정의하는 경우 데이터 유형(일반 요소)의 이름이 "추가 정보" 열에 표시됩니다.
요소 형식. 형식은 전설, 다음 값에 해당합니다. Т – 문자열; N은 숫자 값(정수 또는 소수)입니다.
문자열의 형식은 T(n-k) 또는 T(=k)로 지정됩니다. 여기서 n은 문자열의 최소 문자 수, k는 최대 문자 수, 기호 "-"는 구분 기호, 기호 "="는 한 줄에 고정된 수의 문자를 의미합니다. 최소 문자 수가 0이면 형식은 T(0-k)입니다. 최대 문자 수가 무제한인 경우 형식은 T(n-)입니다. 요소의 길이가 불확실한 경우 형식은 T입니다.
숫자 값의 형식은 N(m. k)로 지정됩니다. 여기서 m은 부호(음수인 경우), 정수 및 분수 부분구분 소수점이 없는 숫자이고 k는 소수점 이하 자릿수의 최대 수입니다. 소수점 이하 자릿수가 0인 경우(즉, 숫자가 정수인 경우) 숫자 값의 형식은 N(m)입니다.
"날짜" 유형의 요소와 같이 XML의 기본인 단순 요소(http://www.w3.org/TR/xmlschema-0에 정의됨)의 경우 "요소 형식" 필드가 비어 있습니다. 이러한 요소의 경우 기본 요소의 유형이 "추가 정보" 필드에 표시됩니다.
필수 요소의 부호는 요소의 필수 존재를 결정합니다. XML 파일. 필수 요소의 속성은 다음 값을 사용할 수 있습니다. "O" - 요소의 필수 존재(요소의 이름과 해당 값은 교환 파일에 있어야 함); "H" – 요소의 존재는 선택 사항입니다(교환 파일의 요소 이름과 값이 없을 수 있음). 요소가 제한된 값 목록을 사용할 수 있는 경우(분류기, 코드 사전 등에 따라) 요소의 의무 속성에 "К" 기호가 추가됩니다. 예: "확인". 요소의 구현 수가 둘 이상이면 요소의 필수 기호에 "M"기호가 추가됩니다. 예: "OM, OKM".