1초 재계산. 임금 수정 및 재계산. 유효기간별 선점

기타 - 예를 들어 보너스는 해당 기간의 급여 금액에 따라 결정될 수 있습니다. 이 경우 보너스가 계산된 후 급여가 변경될 수 있습니다. 기본적으로 플랫폼은 이러한 상황을 제어하지 않습니다. 개발자가 이를 추적해야 한다고 생각하는 경우 계산 레지스터의 특별한 하위 개체인 재계산을 사용해야 합니다.

재계산 기록은 별도의 테이블에 저장됩니다. 이는 종속 레지스터를 정확하게 다시 계산해야 한다는 것을 보장하지는 않지만 그러한 잠재적인 필요성을 나타내는 신호 역할을 합니다.

일반적으로 재계산 테이블 항목에는 다음 필드가 포함됩니다.

재계산 객체(데이터를 재계산해야 하는 기록 문서)
계산 유형 - 이 계산 레지스터에 대해 정의된 계산 유형 계획의 계산 유형에 대한 링크

레코드는 주어진 계산 레지스터의 하나 또는 여러 차원의 맥락에서 더 자세히 저장될 수 있습니다. 예를 들어, 전체 부서의 급여 등록 기관이 소급되었습니다. 또한 변경 사항은 직원 Ivanov에게만 적용되었습니다. 재계산에 직원 차원을 추가하면 이를 추적할 수 있습니다. 이 경우 재계산 차원은 계산 레지스터 차원에 연결되어야 합니다.

해당 계산 유형 계획에 기본 기간 속성 집합이 있는 경우 재계산 테이블의 데이터가 자동으로 생성됩니다. 속성이 설정되지 않은 경우 개발자가 레코드 생성을 담당합니다.

시험 1C: Platform Professional의 질문 14.41. 재계산 데이터...

계산 레지스터 항목이 아닙니다.
계산 레지스터 항목입니다
재계산 레지스터 항목입니다.
실제 유효기간 테이블의 기록입니다

정답은 첫 번째이며 일반적으로 별도의 테이블에 저장됩니다.

시험 1C: Platform Professional의 질문 14.42. "재계산" 차원 속성 창의 "통신" 탭에 있는 "차원 등록" 속성에서 다음을 나타냅니다.

기본 레지스터 측정, 데이터가 변경되면 현재 레지스터 레코드를 다시 계산해야 합니다.
현재 레지스터 측정, 기본 레지스터의 데이터가 변경되면 해당 항목을 다시 계산해야 함
기본 레지스터 측정, 데이터가 변경되면 현재 레지스터 레코드를 다시 계산해야 함

정답은 두 번째입니다. 현재 레지스터의 항목을 업데이트해야 하는 필요성을 추적하려면 재계산 자체가 필요합니다.

시험 1C: Platform Professional의 질문 14.43. "재계산" 테이블은 행으로 채워지며, 각 행은 다음을 나타냅니다.

계산 유형에 대한 정보 세트와 다시 계산해야 하는 계산 레지스터 항목의 문서 기록기입니다. 테이블에는 재계산 측정값도 포함됩니다.
계산 유형 및 다시 계산해야 하는 계산 등록 항목의 문서 등록 기관에 대한 정보 세트
계산 유형, 레지스트라 문서의 행 번호 및 다시 계산해야 하는 계산 레지스터 항목의 레지스트라 자체에 대한 정보 세트입니다. 테이블에는 재계산 측정값도 포함됩니다.
정답은 없습니다

첫 번째 대답은 정확합니다. 위의 분석입니다.

시험 1C: Platform Professional의 질문 14.45. 정답을 선택하세요:

재계산 작업 과정에서 개발자는 시스템이 재계산 테이블에 제공하는 정보를 "무시"할 수 있습니다. 즉, 계산 결과 수정을 거부할 수 있습니다.
1C:Enterprise 8 시스템의 재계산 작동 원리는 "알림"입니다.
구성 개발자는 정산 등록 항목을 다시 계산하는 프로세스를 제어할 수 없으며 시스템이 모든 작업을 자동으로 수행합니다.
진술 1과 2는 참입니다

네 번째 정답은 재계산은 종속 데이터를 변경해야 할 잠재적 필요성만 모니터링한다는 것입니다.

시험 1C: Platform Professional의 질문 14.46. 하나의 계산 레지스터에 대해...

재계산은 한 번만 지원됩니다.
서로 다른 구조의 세 가지 할당만 지원될 수 있습니다.
다양한 구조에 대한 재계산이 얼마든지 지원됩니다.

정답은 세 번째입니다. 계산 레지스터에 하위 Recalculation 개체를 원하는 만큼 추가하는 데 문제가 없습니다. 해당 개체의 구조는 어떤 방식으로든 제어되지 않습니다.

시험 1C: Platform Professional의 문제 14.57. 정산 빈도는 월 단위입니다. 해당 설정이 계산 레지스터에 지정되었습니다. 급여 계산 유형의 경우 이동 계산 유형이 대체 계산 유형으로 지정됩니다. 14/03/01에 급여 정보가 정보 기반에 입력되었지만 계산이 이루어지지 않았습니다. 14년 3월 20일에 출장이 정보 데이터베이스에 입력되어 계산되었습니다. 2014년 3월 30일에 급여 계산이 시작되었습니다. 급여 계산 시 출장 데이터도 고려되나요? 출장을 다시 계산해야 하나요?

고려되지만 출장은 다시 계산해야합니다
고려되며 여행 재계산이 필요하지 않습니다.
고려되지 않습니다. 여행 계산을 취소하고 두 가지 계산 유형을 모두 다시 계산해야 합니다.
고려되지 않습니다. 정확하게 계산하려면 급여와 출장이 하나의 문서에 있어야 합니다.

재계산은 필요하지 않으며, 출장 기록은 해당 월 이내입니다.

이 기사에서는 계산 레지스터 작업의 이론적 기초를 고려하고 근무 시간에 비례하여 직원의 임금을 계산합니다.

이론

계산 레지스터(RR)-1C 시스템에서 주기적 계산을 구현하는 데 사용되는 구성 메타데이터 개체입니다. 계산 레지스터의 명백한 적용 영역에는 급여 계산, 임대료 계산, 임대료 계산이 포함됩니다.

구조상 계산 레지스터는 누적 레지스터 또는 정보 레지스터와 유사합니다. 누적 레지스터와 마찬가지로 측정, 리소스, 세부 정보가 있지만 계산 레지스터의 작동 원리는 완전히 다릅니다.

핵심적으로 누적 레지스터의 측정은 다음과 같은 역할을 합니다. 필터» 우리는 축적 레지스터로부터 데이터를 수신하는 맥락에서. 예를 들어, 특정 항목의 맥락에서 누적 등록 "남은 상품"에 따라 "남은 부분"을 취하거나 특정 직원의 맥락에서 정보 등록 "직원 급여"에 따라 "최신 컷"을 취하는 경우 . 누적 기록과 달리 정기 계산 기록의 측정은 ""(이는 기록의 유효 기간 동안 시간 확장 계산 유형이 서로 경쟁하는 경우, 즉 예를 들어 출장 계산)을 구현하는 역할을 합니다. type은 유효 기간에 대한 급여 계산 유형을 대체합니다) 및 ""(보너스 계산 유형이 이전 기간의 급여 계산 유형에 따라 달라지는 경우).

활동 기간별 억압 메커니즘«:

여기서는 계산 유형 "출장"에 기간이 있고 4월 10일부터 4월 20일까지 유효한 것을 볼 수 있습니다. "출장"은 계산 유형 "급여"에 대한 대체 계산 유형으로 표시됩니다. "급여"도 시간이 지남에 따라 연장되며 4월 1일부터 4월 30일까지 유효합니다. "출장"은 계산 유형 "급여"(급여보다 우선 순위가 높음)에 대한 대체 계산 유형으로 표시되고 급여 유효 기간 동안 유효하므로 급여는 출장으로 대체되며 “실제 급여 유효기간”이 형성됩니다.” 실제 급여 유효기간 “출장으로 인한 급여 유효기간이며, 당사의 경우 4월 1일부터 2기간으로 구성됩니다. 4월 21일부터 9일까지, 4월 21일부터 30일까지 총 19일이다. 기간 기반 변위 메커니즘은 장기 계산에만 작동합니다.

위 그림은 "의 원리를 그래픽으로 보여줍니다. 기준기간별 의존성 메커니즘«:

2017년 4월 말에 직원에게 급여의 10%에 해당하는 보너스를 주고 싶다고 가정해 보겠습니다. 급여는 보너스 계산의 기본 유형으로 표시됩니다.

그러나 보험료 계산을 위한 "기준"으로 4월 전체가 아닌 4월 10일부터 4월 20일까지의 간격(11일)만 사용합니다. 보너스 기준을 계산해 보겠습니다. 직원의 급여는 60,000 루블이고 한 달은 30 일이며 일일 급여 = 60,000/30 = 2,000 루블입니다. 다음 2000*11 = 22000 문지름. 보험료 계산 기준은 22,000 루블입니다.

프리미엄을 계산해 봅시다: (22000/100)*10 = 2200 루블. 급여의 10% 보너스는 2,200 루블입니다.

애플리케이션 메타데이터 개체 "계산 유형 계획"은 계산 레지스터와 밀접하게 연관되어 있습니다.

계산 유형 계획(PVR)- 계산 유형 유형에 대한 정보를 저장하고 서로 다른 계산이 서로 미치는 영향을 결정하는 구성 메타데이터 개체입니다.

하나의 계산 유형 계획은 여러 계산 레지스터에서 사용될 수 있지만, 하나의 계산 레지스터는 여러 계산 유형 계획을 동시에 사용할 수 없습니다.

계산 레지스터는 계산된 데이터가 저장되는 테이블로, 계산 종류별로 이 데이터를 계산하기 위한 알고리즘이 저장된다. 계산 기록부에는 계산 기록부(예: 급여)에서 이동하는 문서 등록자가 하나 이상 있어야 합니다.

1C Enterprise 시스템의 계산 메커니즘은 먼저 계산 레지스터에 항목을 입력한 다음 이 데이터를 기반으로 계산을 수행하도록 설계되었습니다. 예를 들어, 동일한 급여가 계산 기록부에 기록될 때까지 급여를 기준으로 보너스를 계산하는 것은 불가능합니다.

관행

실제로 계산 레지스터를 자세히 살펴보겠습니다.

1 단계계산 유형에 대한 계획부터 시작해 보겠습니다. 계산 레지스터를 생성하기 전에 계산 유형 계획을 생성해야 합니다. 계산된 데이터를 저장하기 위한 테이블(즉, 계산 레지스터)을 만들기 전에 이 데이터를 계산하기 위한 알고리즘(즉, 계산 유형에 대한 계획)을 지정해야 하기 때문에 계산 레지스터 이전에 계산 유형에 대한 계획을 만듭니다.

"기본 요금" 계산 유형에 대한 계획을 작성해 보겠습니다. 즉시 "계산"탭으로 이동하겠습니다. 여기서 우리는 즉시 "플래그"를 봅니다. 유효기간 사용", 이 플래그가 설정되면 이 계획에 포함된 모든 유형의 계산에 시간의 길이(예: 급여, 출장) 및 이 계산 유형 계획의 경우 " 활동 기간별 억압 메커니즘". "유효 기간 사용" 플래그가 설정되지 않은 경우 계산 유형(예: 보너스, 벌금)이 연장되지 않으며 "유효 기간별 대체 메커니즘"이 작동하지 않습니다. 또한 이 탭에는 "베이스에 대한 종속성" 및 "계산 유형에 대한 기본 계획" 섹션이 있습니다. "를 구현하는 데 사용됩니다. 기준기간별 의존성 메커니즘"하지만 나중에 이야기하겠습니다. 지금은 "Independent" 모드에서 "Dependency on the base"를 그대로 두겠습니다.

미리 정의된 계산 유형인 "Salary"를 만들어 보겠습니다. "기본"탭에서는 모든 것이 간단합니다. 계산 유형의 이름과 코드를 설정합니다.

우리가 플래그를 설정했다는 사실 덕분에 " 유효기간 사용"이제 탭이 생겼습니다." 변위" 그리고 켰어 " 기간 기반 억압 메커니즘«.

이 탭에는 급여를 유효 기간별로 대체하는 계산 유형(예: 출장)이 표시됩니다.

메모: "변위"에서는 이 계산 유형 계획에만 속하는 계산 유형을 추가할 수 있습니다.

"라는 탭도 있습니다. 발표자» - 변경 시 현재 계산 유형을 다시 계산해야 하는 계산 유형을 나타냅니다. 여기에서 다른 계산 유형 계획의 계산 유형을 지정할 수도 있습니다. 예를 들어, "급여" 계산 유형은 "보너스" 계산 유형보다 우선합니다. 즉, 급여가 변경되면 보너스도 다시 계산해야 합니다. 보너스는 급여에 따라 계산됩니다. 이 경우 "Salary" 계산 유형은 유효 기간을 사용하는 "Basic Accruals" PRP에 속하고, "Bonus" 계산 유형은 유효 기간을 사용하지 않는 "Additional Accruals" PRP에 속합니다.

2 단계.기본 구조를 사용하여 “Charts” 디렉터리를 생성해 보겠습니다. "일정" 디렉토리에 직원의 근무 시간(5일, 6일 등)을 저장합니다.

3단계.생산 달력(근무일 및 주말)을 저장할 개체도 필요합니다. 이러한 목적을 위해 당사는 비주기적인 독립적인 정보 등록부를 사용합니다.

2차원 "날짜"와 "일정" 및 리소스 "시간"을 사용하여 비주기적인 독립 정보 레지스터 "작업 일정"을 만들어 보겠습니다.

"근무일정" 정보 기록부 덕분에 근무일수에 비례하여 급여에서 임금을 계산할 수 있습니다.

4단계.아래 표시된 세부 구조를 사용하여 "급여" 문서를 생성합니다.

필수 조건:

작업 실행이 "금지"로 설정되었습니다.왜냐하면 1C의 정기 정산 메커니즘에는 의미가 없습니다. 우리는 보너스, 급여 또는 벌금을 실시간으로 계산하지 않습니다.

기본 설정으로 문서 양식을 만들어 보겠습니다.

5단계. 마지막으로 계산 레지스터를 생성하는 단계에 이르렀습니다.

계산 레지스터 메타데이터 개체는 구성기의 "계산 레지스터" 분기에 있습니다.

"기본 요금"이라는 계산 레지스터를 만들어 보겠습니다. 아래 계산 레지스터 설정을 살펴보겠습니다.

1. '계산 유형 계획' 필드에 1단계에서 생성한 PVR '기본 요금'을 입력합니다.

2. "유효 기간" 플래그를 "True"로 설정합니다. 1단계에서 지정한 PVR은 다음과 같습니다. 시간 연장.

이 플래그를 설정한 후 표준 세부 정보 "Action Period", "Action PeriodStart", "ActionPeriodEnd"를 즉시 사용할 수 있습니다. 즉, 이 계산 레지스터에 등록된 계산 유형도 다음과 같습니다. 시간의 길이그리고 우리는 " 활동 기간별 억압 메커니즘«.

추신 다음과 같은 PVR을 지정하는 경우 시간의 길이"유효 기간" 플래그가 "False"로 설정된 RR의 경우 이 PVR은 유효 기간이 없는 PVR로 작동합니다. 시간 연장.

3. "유효 기간" 플래그를 "True"로 설정하면 "차트", "차트 값", "차트 날짜" 필드를 사용할 수 있게 됩니다.

"일정" 필드에는 3단계에서 생성된 "작업 일정" 정보 레지스터가 표시됩니다.

"일정 값" 필드에는 "작업 일정" 정보 레지스터의 "시간 수" 리소스가 표시됩니다.

"일정 날짜" 필드에는 "작업 일정" 정보 등록부의 "날짜" 차원이 표시됩니다.

4. "빈도" 필드에 "월" 값을 표시합니다. 이는 데이터가 월 단위로 레지스터에 입력된다는 의미입니다.

다음은 레지스트리 메타데이터 구조입니다.

차원의 "기본" 플래그는 성능에만 영향을 미치므로 설정할 필요는 없지만 설정할 경우 "직원" 필드가 인덱싱됩니다.

"직원" 차원 - "에서 사용됩니다. 행동 기간에 따른 억압 메커니즘" 그리고 " 기본 기간에 의존하는 메커니즘«.

자원 "금액" - 계산된 급여가 여기에 기록됩니다.

"차트" 속성은 레지스터 차원이 아닌 속성으로 표시됩니다. 그것이나 아무것도 대체하지 않습니다. 본질적으로 참조 필드입니다. 중요한!!! "일정 링크" 필드를 작성하는 것을 잊지 마세요."일정" 속성에는 "근무 일정" 정보 등록의 "일정" 차원이 표시되어야 합니다. 그렇지 않으면 급여 금액이 계산되지 않습니다.

"매개변수" 속성은 급여 값을 저장합니다.

이제 "근무 일정" MS와의 연결을 표시했으므로 근무 일수에 비례하여 직원의 급여를 계산하겠습니다.

우리는 문서를 등록 기관 "으로 표시합니다. 급여"는 4단계에서 생성되었습니다.

6단계. 계산 레지스터 "기본 요금"에 따라 이동합니다.

4단계에서 생성된 "급여" 문서로 돌아가겠습니다.

문서 개체 모듈의 게시 처리를 설명하겠습니다.

문서 처리 처리 코드의 일부

1C(코드)

절차 처리 처리(실패, 처리 모드) // Movement.MainAccruals.Write의 BasicAccruals 등록 = True; Movements.MainAccruals.Clear(); 등록기간 = 월초(날짜); MainAccruals 주기의 각 TechLineMainAccruals에 대해 Movement = Movements.MainAccruals.Add(); 이동.반전 = 거짓; Movement.CalculationType = TechLineMainAccruals.CalculationType; Movement.ActionPeriodStart = TechLineMainAccruals.StartDate; Movement.ActionPeriodEnd = EndDay(TexLineMainAccruals.EndDate); 운동.등록기간 = 등록기간; Movement.Employee = TechLineMainAccruals.Employee; Movement.Chart = TechStringMainAccruals.Chart; Movement.Parameter = TechStringMainAccruals.Size; 엔드사이클; 절차 종료

처리절차(실패, 모드)

// 주요 발생액 등록

동정. 기본적립. 쓰기 = 사실;

동정. 기본적립. 분명한() ;

등록기간 = 월초(날짜) ;

각 TechLine BasicAccruals에 대해 BasicAccrualsCycle에서

움직임 = 움직임. 기본적립. 추가하다() ;

움직임. 스토노= 거짓;

움직임. 계산 유형=TexLineMainAccruals. 계산 유형;

움직임. PeriodActionStart = TechLineMainAccruals. 시작일

움직임. ActionPeriodEnd=EndDay(TexLineMainAccruals.EndDate) ;

움직임. 등록기간 = 등록기간;

움직임. 직원 = TechLineMainAccruals. 직원;

움직임. 차트 = TechLineMainAccruals. 일정;

움직임. 매개변수 = TechStringMainAccruals. 크기;

엔드사이클;

절차 종료

테스트 문서를 작성하고 실행해 보겠습니다.

"문서 이동"으로 이동해 보겠습니다.

등록 기간이 월 초로 설정되어 있는 것을 볼 수 있습니다. RR의 빈도는 "월"로 표시됩니다. 또한 금액을 제외한 모든 필드가 채워져 있음을 알 수 있습니다(급여는 아직 계산되지 않음).

7단계.급여계산 코드를 작성해 봅시다.

다음 플래그를 사용하여 일반 모듈 "계산"을 만들어 보겠습니다.

계산 자체는 이 일반 모듈에서 수행됩니다.

"계산" 모듈에 "요금 계산" 내보내기 기능을 작성해 보겠습니다.

RR "기본 요금" 설정에서 "일정", "일정 값", "일정 날짜" 필드를 입력했으므로 계산 레지스터의 가상 테이블을 사용할 수 있게 되었습니다. 데이터그래픽,가상 테이블에 대한 쿼리에서 우리는 다음 필드에 관심이 있습니다.

"실제 조치 기간 시간" -일정 데이터를 기반으로 계산된 실제 근무 시간이 포함됩니다.

"작업 시간 시간" -계산기간 중 일정데이터를 기준으로 계산된 근무시간을 포함합니다.

급여 계산 절차

1C(코드)

프로시저 CalculateAccruals(등록자, 레코드 세트) 내보내기 //급여 요청=새 요청; Query.Text="SELECT | ISNULL(BasicAccrualsGraphicsData.NumberofHoursActualActionPeriod, 0) AS HoursFact, |BasicAccrualsGraphicsData.Parameter, |ISNULL(BasicAccrualsGraphicsData.NumberofHoursActionPeriod, 0) AS HoursPlan, |BasicAccrualsGraphicsData ica.줄 번호 |FROM |계산 Register.Basic 발생. 그래픽 데이터(| 등록자 = &등록자 | 및 계산 유형 = &계산 유형Salary) AS Basic AccrualsDataGraphics"; Request.SetParameter("등록자", 녹음기); // 현재 문서에서만 검색이 수행되도록 문서를 등록 기관에 전달합니다. Request.SetParameter("Calculation TypeSalary", Plans of Calculation Types. Basic Accruals. Salary); //연봉 계산 유형을 설정합니다. 급여 계산 Selection=Request.Run().Select(); 검색 구조=새 구조; SearchStructure.Insert("RowNumber",0); //계산을 위해 라인 번호별로 데이터를 검색하기 위한 구조 생성 RecordSet의 각 레코드에 대해 Cycle //현재 문서의 레코드 세트를 순환Search Structure.LineNumber=Record.LineNumber; //검색할 라인 번호 채우기 If Selection.FindNext(Search Structure) Then //현재 라인 번호를 기반으로 계산할 데이터를 샘플에서 찾습니다. Record.Sum =?(Selection.HoursPlan=0.0, Sampling.HoursFact /Sample.HoursPlan * 샘플링 .Parameter); //파라미터 - 현재 급여에서 근무일수에 비례하여 급여를 계산합니다. EndIf; 선택.재설정(); //선택 항목을 재설정하려면 먼저 선택 항목을 검색하려면 레코드 세트의 다음 레코드가 필요합니다. EndCycle; Recordset.Write(, True); //계산된 레코드를 데이터베이스에 쓰고 매개변수를 전달합니다. 바꾸기 = True EndProcedure

//샐러리

요청=새 요청;

요구. 텍스트="선택

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActualActionPeriod, 0) AS HoursFact,

| BasicAccrualsDataGraphics.Parameter,

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActionPeriod, 0) AS HoursPlan,

| BasicAccrualsDataGraphics.NumberLines

|발신

| 계산 기록부 기본 발생액 그래픽 데이터(

| 녹음기 = 녹음기(&R)

좋은 오후에요. 오랫동안 소식을 듣지 못했습니다 :) 오늘은 ZUP 3.0의 과거 기간에 대한 재계산 기능을 명확히하고 싶습니다. 이 기사에서는 내부에서 작동하는 방식에 대해 설명하고 이에 따라 이 프로세스를 제어할 수 있습니다. 결국, 당신은 아마도 프로그램이 예기치 않게 사람에게 알려지지 않은 금액을 발생시키고, 이를 반전시키고, 약간의 차이가 나타난다는 사실을 접했을 것입니다... 그리고 당신은 이것을 원하지 않았거나 원했습니다. 그러나 이것은 일어나지 않았습니다))

의 시작하자. 첫째, 급여를 "급여"문서로 간주하는 순간 재계산이 발생합니다. 이를 위해 "추가 발생, 재계산" 탭이 제공됩니다. 내가 당신에게 조언하고 싶은 첫 번째 사항은 다음과 같습니다. 항상 라벨의 데이터를 확인하세요. "추가 발생, 재계산" . 귀하가 알지 못한 채 거기에 나타날 수 있으며 계산 금액이 왜 동일하지 않은지 이해하지 못할 것입니다.

이론적으로 문서 헤더에는 프로그램이 곧 누군가의 수를 계산하려고 한다거나 이를 다시 채워야 한다는 경고가 항상 표시됩니다. 왜냐하면... 누군가는 포함되지 않았습니다.

프로그램은 내가 누구와 몇 달 동안 계산해야 하는지 어떻게 알 수 있나요?

그녀는 당신의 행동에 따라 이것을 결정합니다. 문서를 소급 적용했나요? 프로그램은 이 문서에 있는 직원들을 살펴보고 그들의 목록을 기록했습니다. 문서를 수정했습니까(예: 지난달 작업표 수정)? 프로그램은 이 시간표의 모든 사람을 기억했으며 이번 달은 다시 계산됩니다. 인사 및 급여를 포함한 거의 모든 문서가 영향을 받습니다. 이 경우, 프로그램은 귀하가 문서를 만진 것이 귀하의 급여에 영향을 미쳤는지 여부를 고려하지 않습니다.

당신이 입사 지원서에 가서 댓글을 쓴 후 문서를 다시 게시했다고 가정해 보겠습니다. 월급도 없고, 임명 날짜도 없고, 직위도 없고... 아무것도 건드리지 않았습니다. 그러나 프로그램은 이전 기간의 문서를 덮어쓴 이유를 알지 못하며 텔레파시가 아니며 단순히 이 직원을 녹음했습니다.

두 번째 팁(일명 첫 번째 비밀): "모든 기능"을 통해 "급여 재계산" 정보 등록으로 이동합니다. 게으르지 말고 탑승하세요! 모든 급여 계산 전과 소급된 모든 문서 후에 거기에 들어가십시오.

많은 회계사들은 이 조언을 그들이 이미 충분히 갖고 있는 새로운 직업을 갖게 된다는 의미로 인식합니다. 하지만 거기까지 오르지 않으면 작업의 논리를 이해할 수 없고, 프로그램이 블랙박스 같은 존재라면 친구가 될 수도 없습니다. 우정은 친구의 내면을 이해하는 것에서 시작됩니다! 상대방의 내면 세계에 관심이 없다면 그는 당신의 친구가 아닙니다.

그럼, 올라갔어? 엄청난. 원칙적으로 비어 있고 한 줄도 없지만 소급하여 무언가를 터치하자마자 직원과 다시 계산해야 할 달이 포함 된 기록이 여기에 나타납니다.

세 번째 팁: 직원 수를 계산하려는 프로그램의 의도에 동의하지 않는 경우, 이 기록부에서 해당 행을 지우십시오..

1. 선이 어떻게 나타나는지 이미 이해하셨나요? 엄청난.

2. "급여"문서를 작성하고 등록부의 라인을 기준으로 게시하면 테이블 재계산 및 작성이 수행됩니다. "추가 발생, 재계산."

3. 재계산된 직원은 등록부에서 제거되고 비어 있게 됩니다.

4. "급여" 문서를 취소하면 라인이 원래 위치로 돌아가므로 다시 채울 때 모든 것이 제자리에 놓이게 됩니다.

네 번째 팁(이 문제는 해결될 수도 있음): "급여" 문서를 다시 작성하기 전에 펼쳐보세요!

알고리즘에 따라 문서 게시 후 등록이 삭제됩니다. 이를 지우지 않고 다시 채우면 프로그램은 누가 계산되어야 하는지 알 수 없으며 재계산이 포함된 표 부분은 비어 있게 됩니다. 릴리스 21도 마찬가지였습니다. 22일에는 아직 확인할 시간이 없었습니다.

또 다른 뉘앙스로, 문서에서 재계산할 사람 목록을 클릭하면 정보 등록 목록 양식이 열립니다."급여 재계산."그리고 하나의 항목을 "삭제"하는 버튼도 있습니다.

추신 (중요한)

이번 조사를 실시한 이유는 Accounting 3.0에서 원본 데이터를 전송할 때 끝없는 재계산이 있었기 때문입니다. 전환하는 동안 모든 기술과 번역을 터치해야 합니다.)) 그런 다음 레지스터의 모든 내용을 삭제합니다. "연봉 재계산"그렇지 않으면 모든 연도에 대한 모든 것을 다시 계산하게 됩니다. 회계 3.0에서 데이터 전송으로 ZUP 3.0 시작하기

이는 하나의 작업이 다시 실행되었을 때 데모 데이터베이스에서 발생한 일입니다. 그리고 1C Accounting 3.0을 1C ZUP 3.0으로 전송하면 가능한 모든 작업을 다시 실행하게 됩니다.

그게 전부입니다. 댓글에 질문을 하고 프로그램을 두려워하지 마세요. 프로그램을 이해해야 하며 사랑으로 보답할 것입니다.

많은 1C 프로그래머는 실무에서 "계산"구성 요소를 접한 적이 없으므로 각 작업에 복잡한주기 계산에 대한 작업이 포함 된 플랫폼 8.0의 전문가 시험에 응시해야 할 때 어려움이 발생하며 주로 이해가 어렵습니다.

8.0에서 이 구성요소를 알아내도록 하겠습니다. 다양한 계산 문제를 해결하는 대신, 어떤 계산 문제라도 해결할 수 있도록 이 구성요소를 이해해 보도록 하겠습니다. 이 매뉴얼을 공부한 후에는 계산 레지스터가 어떻게 배열되고 작동하는지 이해하게 될 것입니다.

예를 들어 시험 중에 설치된 프레임 구성을 사용합니다.

솔직히 말해서 또 어떤 계산이 필요한지 오랫동안 알아내려고 노력했지만 알 수 없었으니 급여 계산 문제를 생각해 보겠습니다.

계산이란 무엇입니까?

기본적으로 최종 급여 제품은 다음 형식의 급여 등록 항목 세트입니다.

직원	기간	계산 유형	결과	데이터	코멘트
측정	공식적인	공식적인			소품

"데이터" 열의 값은 직원의 기본급(고용 계약에 따른)을 반영하지만, 이 금액은 상여금으로 증액되거나 벌금, 결근 등에 의해 감액될 수 있으므로 실제 지불할 금액은 뒤에 입력합니다. "결과" 열의 계산입니다. 이것이 계산입니다. 특정 직원에 대한 "자원" 열의 금액은 해당 직원에게 지급되는 급여입니다.

따라서 계산 레지스터는 본질적으로 협상 가능한 누적 레지스터와 구조가 유사한 레코드 세트입니다. 복잡한 계산을 수행하기 위해 추가 설정이 지정되어 계산 레지스터에 대한 많은 가상 테이블을 구축할 수 있지만 본질적으로 이 레지스터는 그림에 표시된 레코드 집합일 뿐입니다.

결제 기록의 각 항목은 특정 유형의 결제 및 기간과 관련됩니다.

계산 유형

계산 유형의 각 레코드에는 서비스 속성(계산 유형)이 있습니다.

계산 유형은 "계산 유형 계획"과 같은 특수 참고 서적의 요소로 간주할 수 있습니다. 여기에는 세부 정보, 표 형식 부분, 사전 정의된 요소 및 사용자 생성 요소도 포함되어 있습니다. 시스템에는 이러한 "디렉토리"가 여러 개 있을 수 있습니다.

예를 들어 Main 계산 유형과 사전 정의된 계산 유형에 대한 계획을 만들어 보겠습니다. 샐러리, 보너스, 결석, 출장.

계산 유형은 계산 레지스터 항목이 서로에게 미치는 영향을 반영하기 위해 기능적으로 사용됩니다. 그러나 간단히 말해서 그들은 계산 유형이 서로에게 미치는 영향에 대해 이야기합니다.

계산 유형	설명	예
기준기간별	종속 기간 계산 결과는 기준 기간 결과에 따라 달라집니다. 기준기간 결과가 변경되면 종속기간 결과를 다시 계산해야 합니다.	보너스는 기본 기간 급여에 따라 달라집니다.
기간별 삭제	종속기간의 유효기간은 기준기간의 유효기간을 대체하므로 기준기간은 실제	결근은 실제 급여 기간에 영향을 미칩니다.
주요 계산	계산은 선행 계산에 따라 달라지지만 직접적이지는 않지만 간접적입니다. 계산 A는 기본 계산 B에 종속되고 계산 B는 기본 계산 B에 종속되므로 A는 간접적으로 B에 종속됩니다. 즉, A는 선행 계산 B에 따라 달라집니다. 실제로 계산 C가 변경되면 B도 변경될 수 있으므로 A도 변경될 수 있습니다. 시스템은 이러한 복잡한 종속성을 자동으로 추적하지 않으므로 어떤 계산이 선행하는지 표시해야 합니다.	보너스는 급여 기준에 따라 다르지만 간접적으로 결근에 따라 달라집니다.

이러한 영향으로 인해 정산대장 기재의 유효기간은 4개 기간으로 구분됩니다.

기간	설명
등록기간	사건이 어느 기간에 기록되었습니까? 일반적으로 문서를 입력할 때
타당성	이벤트는 언제 진행되나요? 해당 이벤트가 속한 기간.
기본 기간	기본 기간이 있는 기간에만 의미가 있으며 기본 기간의 간격을 설명합니다.
실제 유효기간	유효 기간이 다른 유형의 계산으로 대체되는 경우 실제 유효 기간은 이러한 유형의 계산이 실제로 적용되는 여러 기간으로 구성됩니다.

등록 기간은 계산 레지스터의 빈도에 해당하는 기간의 시작인 하나의 숫자로 지정됩니다. 본 서비스 항목에 다른 날짜를 설정하더라도 해당 기간의 시작일로 대체됩니다. 남은 기간은 기간의 시작과 끝이라는 두 개의 필드로 지정됩니다. 실제 유효 기간은 기간 집합입니다. 여러 날짜 간격으로 구성될 수 있습니다.

타임 차트

시스템에는 계산 기록부의 데이터를 시간 차트와 연결하여 특정 기간의 근무 시간을 얻을 수 있는 기능이 있습니다.

타임라인은 하나의 차원이 날짜를 저장하고 다른 차원은 계산 레지스터에 의해 차원과 연결되며 리소스 중 하나는 시간을 추적하는 데 사용되는 간단한 정보 레지스터입니다.

차원 계산 레지스터와 관련된 일반적으로"그래프 유형"을 의미합니다.

날짜	차트 종류	의미
11.01.05 금	오일
11.01.05 금	육일
12.01.05 앉았다	오일
12.01.05 앉았다	육일

정기적인 세부 레지스터 대신 날짜 차원을 사용하는 이유는 무엇입니까? 모든 것은 매우 간단합니다. 1월 11일 금요일에 5일 동안 8시간의 근무 시간이 있었다고 해서 다음 날에도 다시 8시간의 근무 시간이 있다는 의미는 아닙니다. 그러나 정기 레지스터를 사용하는 경우 기록이 없으면 다음 날의 값은 전날에서 가져옵니다.

따라서 특정 기간(실제 조치, 등록, 기본 기간 등)이 있으면 일정에 따라 해당 기간에 대한 시간 수를 자동으로 얻을 수 있습니다.

재계산

재계산은 시퀀스 경계를 다소 연상시킵니다. 종속 계산이 있으므로 기본 계산과 선행 계산을 변경할 때 시스템은 종속 계산을 다시 계산해야 한다는 점을 인식해야 합니다.

이것이 재계산의 목적입니다.

기본 레코드를 계산하는 경우 시스템은 종속 레코드를 계산하는 데 필요한 할당을 기록합니다. 종속 레코드를 계산하면 할당이 지워집니다.

기본적으로 재계산은 다시 계산해야 하는 계산 레지스터 항목의 목록입니다.

재계산에 측정값을 입력하지 않으면 기본 계산이 변경되면 모든 종속 레코드가 재계산 목록에 추가됩니다.

재계산에서 "직원" 차원을 생성한 경우 직원에 대한 기본 계산이 변경되면 이 직원에 대한 종속 레코드만 재계산에 추가됩니다.

실제적인 작업

이론은 충분합니다. 실제로 세부 사항을 연구해 봅시다. 프레임 구성을 기본으로 살펴보겠습니다.

문제의 공식화:

보너스를 급여의 고정 비율(결근 및 여행 수당 제외)로 설정하도록 합니다.

여행수당은 이중 급여 + 여행일별 고정금액으로 지급되도록 하세요.

직원에게 결근으로 인한 결근 기간 동안 급여의 절반에 해당하는 벌금이 부과되도록하십시오.

진전:

초기 훈련

계산 유형 "기본"에 대한 새 계획을 만들어 보겠습니다.

계산 유형과 계산 간의 종속성을 정의해 보겠습니다.

	기초적인	변위	발표자
샐러리		결근, 출장
상		결근, 출장	급여, 결근, 출장
출장
장기 결석

이러한 유형의 계산을 "기본" 계산 유형 계획에 추가하고 표에 따라 계산 유형 속성의 종속성을 설정해 보겠습니다.

급여 계산 레지스터에서 "개인" 유형의 "직원" 차원을 생성하여 레지스터에 직원을 위한 분석 섹션이 포함되도록 하겠습니다.

구성에는 이미 "급여" 문서가 포함되어 있습니다.

헤더에는 "날짜"와 "등록 기간"이라는 두 개의 날짜가 있고 각 줄에는 "시작 날짜"와 "종료 날짜"라는 두 개의 날짜가 있습니다.

날짜는 단순히 문서가 실행된 날짜이고, 등록 기간은 급여를 계산하는 달을 나타내며, 각 줄의 날짜는 각 계산 유형의 유효 기간을 나타냅니다.

문서 모듈에 "데이터" 속성의 초기 설정을 추가해 보겠습니다. 여기에 초봉을 입력하고 등록 기간, 유효 기간 및 기본 기간을 설정하겠습니다.

문서 모듈은 다음과 같습니다:

을 위한 각각에게 TechStringList목록 주기에서

// 계산 등록

움직임 = 움직임 .계산.추가();

움직임 .S 토르노= 거짓;

움직임 .idCalculation에서 = TechStringList.CalculationType;

움직임 .PeriodActionsStart= 하루의 시작( TechStringList.StartDate);

움직임 .PeriodActionEnd= 종료일();

움직임 .등록기간 = 등록기간;

움직임 .BasicPeriodStart= 하루의 시작( TechStringList.StartDate);

움직임 .BasePeriodEnd= 종료일( TechStringList.End 날짜);

움직임 .직원 = TechStringList.Employee;

움직임 .일정 = TechStringList.Graph;

움직임 .결과 = 0;

움직임 .데이터 = TechStringList.Size;

엔드사이클 ;

항목을 반전하려면 Reversal 속성이 필요합니다(빼기 기호와 유사).

계산 유형을 표시하고 날짜를 하루의 시작과 끝으로 설정합니다. 물론 기준기간은 기준에 따른 계산방식에 대해서만 입력이 가능하고, 데이터는 급여에 대해서만 입력이 가능하지만 다 그렇게 됩니다.

우리는 모든 문서의 날짜를 2003년 1월 20일로 지정하고 등록 기간은 2003년 1월 2일로 설정됩니다. 등록기간 2003년 1월 1일 기간의 시작으로 변환됨). 이 기간에 대한 작업 일정이 완료되었으므로 2003년 1월을 사용합니다.

"재계산" 재계산을 생성하고 여기에 "직원" 차원과 연결된 "직원" 차원을 추가해 보겠습니다.

재계산을 가지고 놀기.

게임을 플레이하려면 요청 콘솔을 열고 '처리 중'을 실행하세요. 맞춤 요청» 프레임 구성에서. 쿼리 생성자를 사용하여 새 쿼리를 만들고 거기에 가상 테이블을 추가해 보겠습니다. 재계산.계산.재계산, 요청 텍스트는 다음과 같습니다.

선택하다

계산재계산.재계산 개체 정보,

계산재계산.계산 ID,

계산 재계산. 직원으로부터

에서

계산 레지스터.계산.재계산어떻게 계산재계산

세 가지 문서를 생성하겠습니다. 먼저 직원 A와 B의 급여를 계산합니다. 직원 A는 1월 1일부터 31일까지 근무하고 B는 1월 1일부터 20일까지 근무합니다. 두 번째는 1월 1일부터 31일까지 직원 B에게 보너스를 할당하고, 세 번째는 직원 A에게 1월 20일부터 25일까지 결근을 할당합니다.

우리는 실제 유효 기간을 가지고 놀고 있습니다.

새 쿼리를 만들어 보겠습니다. 이번에는 쿼리에 테이블 데이터를 추가하겠습니다. 계산 레지스터, 계산, 실제 조치 기간.

요청을 생성하고 직원 A의 급여 기간이 1월 1일부터 19일까지와 1월 26일부터 31일까지 두 기간으로 나뉘는 것을 확인하겠습니다. 기간을 2개로 나누어서 이해해 주시길 바라겠습니다. 왜냐하면... 결근이 급여를 대체했습니다.

계산 레지스터의 작동 메커니즘이 우리 눈앞에서 점점 더 명확해지고 있다고 생각합니다.

그래프를 공부해보자.

이제 직원의 급여를 기준으로 급여를 계산해 보겠습니다.

가상 테이블을 사용하여 계산 레지스터에 대한 새 쿼리를 만들어 보겠습니다. 계산 레지스터.계산.DataGraphics. 이 가상 테이블에 대한 매개변수(예: 레코드 선택 조건)를 설정할 수 있습니다. 직원=직원 선택(&S)그리고 계산 유형=계산 유형(&C)그리고 그래프=그래픽 보기(&V).

요청 매개변수에 특정 직원, 계산 유형 및 일정을 설정하고 결과가 몇 시간인지 살펴보겠습니다.

결과 열	의미
ValuePeriod액션	등록부에 입력된 유효 기간은 몇 시간입니까?
값실제기간작업	해당 직원은 실제로 몇 시간 일했습니까?
가치기준기간	급여의 경우 보너스의 경우 기본 기간의 근무 시간이 의미가 없습니다.
값등록기간	등록기간(1월)에는 근무시간이 몇 시간인가요?

재계산은 급여 계산의 필수적인 부분을 구성합니다. 직원의 병가, 휴가 또는 결근에 대한 정보가 회계 부서에 약간의 지연으로 접수되면 급여가 재계산되고 이에 따라 보험료가 부과됩니다. 1C 전문가는 보험료 계산 및 재계산이 1C: 급여 및 인사 관리 8 프로그램, 에디션 3의 회계 및 규제 보고에 어떻게 반영되는지에 대해 이야기합니다.

임금을 재산정할 때에는 보험료를 재산정할 필요가 있습니다. 또한 기여금을 재계산하는 이유는 해당 연도 중 관세가 변경되었거나 보험료 기준에 계산이 포함되지 않는 등의 오류 발견 때문일 수 있습니다.

이러한 경우 회계사는 연방세 서비스에 업데이트된 정보를 제출할 필요성, 의무 및 권리에 대해 질문이 있습니다.

2016년 10월 10일자 러시아 연방세청 명령 ММВ-7-11/551@에 대한 부록 2에 제공된 보험료 계산 작성 절차의 1.2항에 따라 지불인은 다음과 같습니다. 기록되지 않거나 불완전한 정보가 있거나 지불할 보험료 금액을 과소평가하는 오류가 있는 경우 계산에 필요한 변경을 하고 세무 당국에 업데이트된 보고서를 제출할 의무가 있습니다.

업데이트된 계산을 제출할지 여부를 결정할 때 회계사는 다음 질문에 답해야 합니다.

모든 정보가 반영되었는지 여부
오류가 발생했는지 여부와 이로 인해 납부해야 할 보험료 금액이 과소평가되었는지 여부.

업데이트된 계산을 제출하는 것은 의무, 권리 또는 강제적 필요성일 수 있습니다.

보험료 계산 업데이트

연방세청에 보고서를 제출한 후 직원에 대한 불완전하거나 부정확한 정보가 제출되었거나 지불할 보험료 금액을 과소평가하는 오류가 발견된 경우 업데이트된 계산을 제출할 의무가 발생합니다.

업데이트된 계산을 의무적으로 제출해야 하는 일반적인 오류 유형:

1. 직원이 자신의 개인 데이터 변경 사항을 즉시 보고하지 않았으며 연방세청이 계산 섹션 3에 해당 직원에 대한 허위 정보를 제공했습니다.

2. 직원이 보험료 우대율을 적용할 수 있는 부서에서 근무했습니다. 그러다가 기본보험요율이 적용되는 부대로 이동하게 됐다. 직원의 이동에 대한 정보가 회계 부서에서 늦게 접수되었습니다. 기여금 계산이 감소된 비율로 잘못 계산되었습니다.

3. 1C : 급여 및 인사 관리 8 프로그램의 초기 설정 단계에서 보험료 계산 기준에서 보험료를 제외하는 실수가 발생했습니다. 오류를 수정하면 추가 비용이 청구됩니다.

4. 특혜관세를 적용받은 부서는 이를 사용할 권리를 상실하지만 해당 정보는 지연되어 급여 관리자에게 전달됩니다. 기본요율에 따라 재계산하면 납부할 보험료가 증가하게 됩니다.

5. 보험료를 계산할 때 해당 직위가 추가 관세가 부과되는 위험 직업 목록에 포함되어 있다고 프로그램에 표시되지 않았습니다. 오류가 발견되어 수정된 후 재계산으로 인해 추가 요율로 보험료가 과소납부되었습니다.

예제를 사용하여 "1C : 급여 및 인사 관리 8"판 3에서 보험료 재계산 기능을 살펴 보겠습니다.

실시예 1

단위당 보험료를 계산할 때 재고보험료 우대율이 적용되었습니다. 기술혁신경제특구 거주자(요금 코드 “05”). 이 관세는 2018년에 연금 기금에 13%의 기여금을 제공합니다. 사회보험기금에서 2.9%; 연방 의무 의료 보험 기금에서 5.1%. 이것이 바로 직원 V.S.에 대한 기여금이 계산된 방식입니다. 여자 이름. 월 수입은 10,000 루블입니다. 해당 달의 보험 공제 금액은 다음과 같습니다.

연금 기금-1,300 루블;
FFOMS-510 루블;
사회 보험 기금-290 루블.

표시된 금액은 2018년 1분기 보험료 산정에 반영되었습니다.

부서가 보험료 우대율을 적용할 권리를 상실한 것으로 밝혀졌을 때, 2017년 10월 25일자 러시아 연방세청의 서한 No. GD-4-11/21611@ 및 교육부에 따라 2017년 12월 18일자 러시아 재무부 No.03-15-06/84443 명확한 계산서를 제출할 필요가 있었습니다. 이를 형성하려면 새로운 요율로 보험료를 다시 계산해야 합니다.

카드에 부문필드를 비워야합니다 특혜관세 공포. 기여. 이제 부서에는 조직에 사용되는 관세가 적용되며 카드에 지정됩니다. 조직북마크에 회계 정책 및 기타 설정링크 회계정책현장에서 관세 유형.

예제 1에서 조직은 다음과 같이 설정됩니다. 기본보험료율(관세 코드 "01"), 2018년 기여율 제공: 러시아 연방 연금 기금에 22%; 사회보험기금 2.9%; FFOMS 5.1%. 연금 기금이 기여금의 9%(22% - 13%)를 "과소 지불"했으며 관세 코드가 변경된 것은 분명합니다.

고려 중인 사례 1에서 기여금을 다시 계산하려면 소득 회계 절차를 수정해야 합니다. 이 문서는 이전 기간의 소득 기록 및 보험료 재계산 절차를 등록하기 위한 것입니다. (메뉴 세금 및 수수료). 북마크에 소득정보모든 직원 소득을 수동으로 명확히해야합니다. 동시에 북마크에 예상 기여도보험료는 자동으로 재계산됩니다.

직원 V.S. 월 수입이 10,000 루블 인 아이비. 해당 달의 보험 공제 금액은 다음과 같습니다.

러시아 연금 기금-2,200 루블;
연방 의무 의료 보험 기금 및 사회 보험 기금에서 금액은 변경되지 않았으며 각각 510 루블에 달했습니다. 그리고 290 문지름.

1분기 보험료를 재계산한 후, 명확한 계산서를 작성해야 합니다. 서비스 이용 1C-보고,수정되는 기간에 대한 새 보고서를 작성해야 합니다. 제목 페이지나타내다 수정번호(그림 2). 모든 사람의 관세 코드가 변경되었으므로 설명은 부서의 모든 직원에게 영향을 미쳤습니다. 따라서 업데이트된 계산의 섹션 3은 부서의 모든 직원을 대상으로 구성됩니다. 다른 경우, 업데이트된 계산의 형성이 데이터 변경 또는 개별 직원의 발생으로 인해 발생하는 경우 섹션 3에는 해당 직원에 대한 데이터만 표시됩니다. 어쨌든 명확한 계산의 나머지 섹션은 완전히 새로운 데이터로 채워집니다.

쌀. 2. 2018년 1분기 보험료 산정명세 표제면

업데이트된 보험료 계산서를 제출할 권리

보험 계약자는 보험료 금액을 과대평가하는 오류를 발견한 경우 검사에 업데이트된 계산서를 제출할 수 있습니다. 실제로, 현재 기간의 다음 기여금 계산 중에 재계산이 이루어지며 그 결과는 다음 기간의 보고서에 반영됩니다. 업데이트된 계산을 제시할 수 있는 상황 옵션:

1. 직원은 근무한 달 전체에 대한 급여를 받았습니다. 보험료 계산은 연방 세금 서비스에 제출되었지만 나중에 직원이 자비로 병가 또는 휴가 중임이 밝혀졌습니다. 보험료 산정기준에 포함되지 않은 적립금이 보험료 적용 적립금을 대체하여 보험료가 초과 지급되었습니다.

2. 직원 발생액 재계산으로 인해 보험료가 재계산되어 감소됩니다.

실시예 2

직원 S.S.의 6월 급여를 계산할 때 Gorbunkov는 다음을 수상했습니다.

급여 지불 - 7,500 루블;
6 월 출장비 (평균 수입 기준)-2,500 루블.

보험료는 기본요율로 계산되었습니다. 6월에는 S.S.의 급여에서 기부됩니다. Gorbunkov는 다음과 같습니다.

러시아 연금 기금-2,200 루블;
FFOMS-510 루블;
사회 보험 기금-290 루블.

이 기부금은 지불되었으며 2018년 반기 계정에 포함되었습니다. 2018년 6월 25일부터 2018년 6월 30일까지 회계 부서에 제출된 병가는 업데이트된 계산을 구성할 이유가 되지 않습니다. 프로그램에 등록된 문서 병가이전에 발생한 여행 수당 금액을 취소합니다(그림 3).

쌀. 3. "병가" 문서의 여행 수당 재계산

조직은 7월에 병가를 받았습니다. 이는 오류 상황이 아니며 보험료 미납으로 이어지지 않습니다. 병가로 발생한 금액은 보험료가 부과되지 않기 때문에 다음 금액에 보험료가 초과 지급되었습니다.

러시아 연방 연금 기금-550 루블;
FFOMS-127.50 루블;
사회 보험 기금-72.50 루블.

프로그램에서 병가, 등록됨 2018년 7월, 당월 보험료 계산에 영향을 미치므로 계산 기반이 줄어 듭니다.

이러한 상황에서는 업데이트된 계산서를 제출해야 한다는 법적 요구 사항이 없습니다. 모든 재계산은 다음 기간에 발생하며 다음 보고서에 반영됩니다. 그러나 동시에 조직은 반기 보고서를 명확히하고 설명을 제출하여 발생한 초과 지불에 대해 연방세 서비스에 알릴 권리가 있습니다.

그러나 월말 이전에 계산을 성급하게 설명해서는 안됩니다. 결국, 한 달 내내 다양한 문서가 등록됩니다. 어느 순간 문서가 병가실제로 전월 소득을 취소할 수 있으며, 해당 월의 임금 계산 결과에 따라 또 다른 문서, 예를 들어 급여 및 기여금 계산, 이전 기간의 반전 소득을 초과하는 추가 발생이 발생합니다. 이에 따라 당월 수입은 출장 환입액만큼 감소하고, 전월 마이너스 금액은 남지 않으며, 정산 보고서에도 변동 사항이 표시되지 않습니다.

업데이트된 보험료 계산서를 제출해야 할 필요성

많은 경우, 업데이트된 계산서를 제출할 의무가 없음에도 불구하고 보험 계약자는 업데이트를 제출하는 것 외에는 보험료 초과 지불을 보고할 수 있는 다른 기회가 없습니다.

1. 현재 기간의 기여금 재계산 결과 직원은 마이너스 금액을 받습니다. 마이너스 금액이 포함된 보고서는 연방세청에 제출할 수 없습니다. 따라서 이전 기간에 대한 업데이트된 보고서를 생성하는 방법은 단 하나뿐입니다.

2. 직원이 위험한 작업에 종사했습니다. 보험료는 추가 요율로 계산되었습니다. 정상적인 근무 조건에서 직원의 직장 이동에 대한 정보가 회계 부서에서 늦게 수신되었습니다. 재계산 결과, 현재 기간의 직원 발생액은 더 이상 추가 요율의 기여금에 적용되지 않으므로 계산된 기여금을 추가 요율로 줄이는 것은 불가능합니다.

실시예 3

이 경우 앞선 예시 2와 달리 출장 취소로 인한 마이너스 보험료는 적립금으로 보상되지 않습니다. 다른 직원의 발생으로 인해 보험료 총액이 양수라는 사실에도 불구하고 섹션 3에서 직원은 음수 값으로 유지되며 이는 용납될 수 없습니다. 따라서 회계사는 문서를 작성해야 합니다. 보험료 재산정, 6월 분담금을 다시 계산하고 업데이트된 계산을 생성하여 연방세청에 제출합니다.

1C: 급여 및 인사 관리 8 프로그램은 보험료 재계산 프로세스를 자동화합니다. 서비스 이용 1C-보고보험료에 대한 초기 및 명확한 계산이 자동으로 생성됩니다. 그러나 명확한 계산을 준비하는 결정은 회계사에게 있습니다. 보고서가 이미 제출된 기간에 계산을 변경하는 문서를 등록한 결과를 분석한 후 회계사는 이전 기간의 보험료를 다시 계산하거나 당월에 자동으로 계산됩니다.

편집자로부터. 이 기사에서는 조정 계산 데이터를 고려하여 보험료 계산을 위한 통제 비율을 확인하기 위해 1C:Enterprise 8에 구현된 메커니즘에 대해 읽어보세요.