01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

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

03. SOLUÇÃO

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>