Histórico da Página

...

02. SITUAÇÃO/REQUISITO

Nova funcionalidade para separação de participações em guias de honorário, a partir de uma guia de origem

...

A funcionalidade de separação foi implementada e, após aplicação do patch de fontes e dicionários deste chamado, funciona conforme abaixo:--

• Condições
  • Parâmetro MV_PLSUNI com conteúdo 1 (essa funcionalidade é destinada à cooperativas médicas)
  • Parâmetro MV_PL7RDA com conteúdo .F. (o uso dessa funcionalidade não é compatível com a funcionalidade de alterar o código da RDA na participação do evento)
  • O profissional executante deve estar vinculado à uma RDA (BAU_CODBB0 = BB0_CODIGO = BD7_CDPFPR) e esta RDA deve ser do tipo Cooperado (BAU_COPCRE = 1).
  • O tipo de Cálculo da RDA Cooperado ser diferente de Valor apresentado (BAU_TPCALC diferente de 3).
  • Tanto a RDA que enviou a cobrança, quanto a RDA Cooperado vinculado ao profissional devem ter o mesmo local de atendimento cadastrado, o local de atendimento da guia nova será o que tiver o mesmo CNES do local de atendimento da guia original (BB8_CNES da Origem deve existir no BB8_CNES do destino).
  • A regra de cobrança ‘Pagamento na RDA’ não pode ter sido aplicada ao evento na guia original.
  • Somente aplica em guias na fase DIGITAÇÃO.
  • Caso pelo menos uma condição não seja atendida, a participação não será separada.

...

•  O que acontece com a guia original
  • O valor apresentado pela RDA original será mantido.
  • As composições dos eventos que virarem novas guias terão o pagamento bloqueado

...

• O que acontece com a nova guia
  • O tipo de guia a ser gerado será sempre uma guia de honorário
  • O valor apresentado da guia nova será sempre Zero
  • As composições bloqueadas na guia original serão incluídas conforme parametrização da RDA destino
  • Deve haver correspondência entre a TDE da RDA origem e da RDA destino, uma composição sem unidade equivalente não será transferida
  • Se houver regra de coparticipação que diferencie algo do prestador, exemplo nível de autorização BGP e nível de cobrança BGS, a regra será aplicada sobre o Prestador Cooperado e não sobre a RDA origem durante a mudança de fase da nova guia, ou seja, caso utilize o nível BGP para autorizações em Prestador com BAU_TIPPRE ‘XXX’ e o RDA cooperado tiver o BAU_TIPPRE ‘YYY’, este nível não será válido na mudança de fase da nova guia, somente na guia original.

...

• Sobre os vínculos
  • Será gravada uma tabela de vínculos para que seja possível rastrear internamente os Protocolos gerados a partir de um protocolo original
  • Não será possível cancelar nenhuma das guias/protocolos gerados ou original se aplicado o processo de separação de PEGs. Em caso de intenção de não pagamento, o objeto em questão deve ser glosado.
  • Será possível desfazer a importação XML original caso nenhuma das guias, originais ou geradas, tenha sido Faturada ou consolidada. Em caso da importação ser desfeita, todos os Protocolos vinculados são excluídos junto do original.

...

• Momentos de aplicação
  • Na importação de arquivos XML de lote de guias
  • Utilizando uma opção no menu Outras ações dentro da rotina de processamento de contas após posicionar no PEG que irá aplicar a regra

...

• Observações
  • A possibilidade de ter RDAs diferentes no BD7 será removida com a liberação desta funcionalidade, em momento futuro.
  • O motivo de bloqueio padrão pode ser definido no parâmetro MV_PLQGMB.

04. DEMAIS INFORMAÇÕES

Não se aplica.

05. ASSUNTOS RELACIONADOS

• Não se aplica.

<style>
div.theme-default .ia-splitter #main {
    margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
    display: none;
}
#main {
    padding-left: 10px;
    padding-right: 10px;
    overflow-x: hidden;
}

.aui-header-primary .aui-nav,  .aui-page-panel {
    margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
    margin-left: 0px !important;
}

.aui-tabs.horizontal-tabs>.tabs-menu>.menu-item.active-tab a::after { 
	background: #FF9900; !important 
}

.menu-item.active-tab { 
	border-bottom: none !important; 
}

</style>