CB 028 3 - Programa Customizado de Negativaçao - v37

575039736.
doc
01
ID:
Título: CB.028.3_Programa Customizado para Módulo do R/3: RM-CA
Negativação
Criado por: Luis Angeli Data solicitação:
Tempo orçado em horas para execução da tarefa ABAP: Data início
desenvolvimento:
Ambiente: ( )TIM Consolidação ( )HR ( )CFM ( )ONE CLIENT ( X )RM-CA
( )100 ( )101 ( )200 ( )201 ( )202 ( )203 ( X )204 ( )400 ( )500 ( )Todos
1. Registro de Modificações
Nº do chamado ou SIR Link do Documento Referência
INC000000635439 VERSÃO 37
Histórico de Versões
Versão Data Atualizado por Descrição da Atualização
17 03/06/2006 Luis Angeli Atualização de criterio de distribuição para CB.
18 13/06/2006 Luis Angeli Revisão ABAP. Melhorias nas logicas.
19 26/06/2006 Luis Angeli Visualização da data de prorrogação de vencimento na tabela de
controle e historico de negativação.
20 25/08/2006 Luis Angeli Revisão TI. Incorporação de algumas informações do cliente na
tabela de Gerenciamento da negativação. Padronização de logicas
para identificação de reguas e niveis de cobrança na tabela
FKKMAZE.
21 31/08/2006 Luis Angeli Detalhamento da identificação da entrada paga de parcelamento
item 2.4.2 campo AUGRD.
22 25/09/2006 Luis Angeli Visualização nas tabelas de controle e historico de negativação de
faturas em situação de No dunning.
23 02/02/2007 Luis Angeli Validação do arquivo de retorno do SERASA pelo numero do
sequencial no header do arquivo.
24 05/02/2007 Luis Angeli Validação do arquivo de retorno do SERASA pelo numero do
sequencial no header do arquivo por contrato. Campo contrato
acrescentado na tabela de arquivos processados.
25 27/04/2007 Luis Angeli Implantação de Paralelismo.
Tratamento de migrados com quantidade de registros Zero na
tabela de controle de arquivos processados.
26 29/04/2007 Luis Angeli Utilização do modulo de função FKK_FILL_SAMPLE_0350 ao
invés do módulo FKK_ SAMPLE_0350.
27 19/07/2007 Luis Angeli Exclusão de motivos de exclusão diferentes de 01 e 02 dos
candidatos para renegativação.
575039736.doc Criado em 13/05/2008 Página: 1 de 77

575039736.doc
28 22/10/2007 Wilromar Junior Alteração no nome do arquivo de retorno do SPC e alteração nos
tratamentos de validação deste arquivo
29 23/10/2007 Wilromar Junior Inclusão do customer_id e código Febraban no arquivo de saída
do SPC
30 31/10/2007 Wilromar Junior Inclusão de crítica no módulo de função ZCB_NEGATIVACAO_0350
para evitar duplicidade de fatura no mesmo bureau na tabela de
gerenciamento da negativação
31 31/10/2007 Wilromar Junior Descartar o último registro do arquivo de retorno do SPC, pois o
mesmo é enviado com um caracter especial
32 31/10/2007 Wilromar Junior Gravar o sequencial de envio do SPC no HEADER do arquivo
33 19/11/2007 Wilromar Junior Alteração no nome do arquivo do SPC
34 19/11/2007 Wilromar Junior Aumento do tamanho da coluna QUANTREG da tabela de controle
de arquivos processados de 5 para 8 posições.
35 14/03/2008 Luis Angeli Exclusão dos parâmetros UF, Segmento e Subsegmento dos
critérios de distribuição dos bureaus de credito.
Validação de dados na tabela FKKMAKO (evento

FKK_FILL_SAMPLE_0350)
Geração dos arquivos para envio ao SPC diferenciado por contrato
36 18/4/2008 Gustavo Freire (TIM CELULAR e TIM NORDESTE),
Validação do campo MSTYP para preenchimento na tabela de

gerenciamento da negativação
37 12/05/2008 Gustavo Freire Validação de No-Dunning (Cliente e/ou Fatura), no processo de

Renegativação.

575039736.doc
2. Objetivo
Descrição Programa de gerenciamento de faturas e geração de arquivos para os diferentes Bureas
de credito
Tipo de ( ) Interface Batch ( ) Interface Online ( ) Relatório
programa ( ) SAPSCript ( ) Enhancement ( ) Modificação SAP standard
( ) Programa Online ( ) Carga de Dados
Prioridade ( X ) Alta / Obrigatório ( ) Média / Recomendável ( ) Baixa / Desejável
Para interfaces Sistema Origem: Sistema Destino:
1. Tipo de interface ( ) Online ( X ) Batch
2. Direção da Interface ( ) Entrada ( ) Saída ( ) Ambas direções
3. Periodicidade ( ) Diária ( ) Semanal ( ) Mensal
( ) Quinzenal ( ) Eventual ( ) Outros: _______________
4. Número de registros ____ registros
Técnica de Atualização dos ( ) BAPI ( ) Direct Input ( ) IDOC
Dados ( ) Batch Input ( ) Call transaction
Para relatórios
1. O relatório será criado via ( ) Report Painter ( ) Report Writer ( ) Report ABAP
( ) ABAP Query
2. Características requeridas ( ) Drill-down ( ) ALV Grid ( ) Lista
( ) Outros: __________________________________________________
Impacto caso não seja ( ) Requerimentos legais não serão atendidos
desenvolvido ( ) Falta de informação para gerir o negócio
( ) Perda de funcionalidade comparando com o sistema antigo
( ) Mudança de procedimento necessário
( X )Outros: Os clientes não vão ser enviados para o Bureau de Crédito
Existe alternativa no R/3? ( ) Sim ( x ) Não
Descreva a alternativa
encontrada
Razão porque esta alternativa ( ) Problemas de performance ( ) Complexidade de operação
não é aceitável: ( ) Outros:

575039736.doc
3. Detalhamento da Especificação Funcional
3.1. Processos relacionados
Esta Especificação Funcional descreverá o programa que selecionará todos as faturas que vão ser
enviados/excluídos de Negativação e gerará os arquivos para serem enviados para os Bureaus de Crédito.
Este programa será rodado em batch uma vez por dia, depois da execução do programa do lote de pagamentos
e depois que seja rodado o programa de cobrança (Dunning).
Á partir da lista de Negativação gerada pela régua de cobrança, o programa seguirá alguns critérios pré-
definidos nas transações customizadas da EF “CB.028.01 – Transações Customizadas para configuração de
critérios para Negativaçao” e algumas validações que serão descritas abaixo.
3.2. Regras de negócio
Premissas e regras de negócio.
- Inclusão de clientes para Negativação

É necessário que a lista com os clientes / faturas que serão enviados para Negativação tenha sido gerado pelo
job diario de cobrança baseado naquelas faturas que atingiram o nivel de cobrança de negativação.
As faturas inicialmente negativadas e excluidas devido ao parcelamento, apos a quebra de acordo do mesmo
deverão voltar a ser negativadas, desde que atendam aos critérios de negativação.
Caso uma fatura selecionada para negativação não seja negativada por causa de uma restrição ativa, devera
ser negativada no momento que a restrição expire.
- Exclusão de clientes da Negativação

É necessário que a fatura já tenha sido negativada.
A exclusão sera efetuada nos casos:
Pagamento do valor negativado ou parcial desde que o saldo seja menor que o valor mínimo de cobrança.
Ajuste total do valor negativado ou parcial desde que o saldo seja menor que o valor mínimo de cobrança.
Fatura em parcelamento com entrada paga.
- Controle do resultado da negativação

É necessário receber dos Bureaus de Crédito um arquivo de retorno com o resultado do envio do arquivo
SLA’s:
As inclusões nos bureaus de crédto devem ocorrer em até 24 horas após o tratamento do nível de advertência.
As exclusões nos bureaus de crédito devem ser enviadas em até 24 horas após a efetiva compensação das
faturas negativadas.
As exclusões manuais comandadas pelo usuário devem ser enviadas em até 24 horas após o comando de
exclusão.

575039736.doc
3.3. Dependências
Esta EF está relacionada com a EF CB.028.1 – Transações Customizadas para configuração de critérios de
negativação.
3.4. Volume de transações
Quantidade de CB's
Mês/Ano - Tipo CB - Qtd.
04/2005 - CB - 14.883
05/2005 - CB - 68.027
06/2005 - CB - 127.986
06/2005 - CB_ATIVO - 545
07/2005 - CB - 277.924
07/2005 - CB_ATIVO - 1.167
08/2005 - CB - 58.655
08/2005 - CB_ATIVO - 190
09/2005 - CB - 41.881
09/2005 - CB_ATIVO - 22
102005 - CB - 85.892
10/2005 - CB_SUSP - 121.408
10/2005 - CB_ATIVO - 19.625
11/2005 - CB - 35.611
11/2005 - CB_SUSP - 66.240
11/2005 - CB_ATIVO - 762
12/2005 - CB - 25.574
12/2005 - CB_SUSP - 80.205
12/2005 - CB_ATIVO - 136.870

575039736.doc
3.5. Parametrização do sistema para atividades em massa

Esta parametrização è pré-requisito para processamento em Paralelo com técnica de atividade em massa da
SAP
3.5.1. Criar nova transação

Criar transação Z_EXTR_NEG.
3.5.2. Criar modulo de função

Criar o modulo de função Z_RMCA_NEGATIVACAO. Este modulo recebe em input (Importing) os valores inferior
e superior do objeto de paralelismo GPART (VALUE I_LOW e I_HIGH), a estrutura das atividades em massa
FKK_MAD_BASICS e a estrutura do “counter” FKK_MASS_ACT_COUNT.
3.5.3. Criar Evento

Os eventos Standard são gravados na tabela TFKFBM; Para criar um novo evento a tabela deve ser atualizada
com a transação SM30.
Para processamento em paralelo da SAP é necessário criar um modulo de função para eventos (momentos).
No caso do Crivo foi criado um modulo Z_RMCA_NEGATIVACAO junto ao momento Z00X.

575039736.doc
3.5.4. Criar Layout para transação

Deve ser criada uma tela customizada pela transação Z_EXTR_NEG.
A tela deverá ser semelhante a qualquer transação em massa da SAP, em particular deve-se ter os seguintes
tabs e campos de seleções:
- ID Data -> Data de execução
- Identificação -> ID adicional para execuções
- Tab Seleções: Contém os parâmetros para a extração:
o Seleção por parceiro de negocio (para delimitar a seleção).
o Seleção do submodulo que sera executado (Radio Button):
 Programa 1 (Negativação/Positivação de faturas)
 Programa 3 (Renegativação de faturas).
O quadro de grupo Parceiro de Negocio é Standard e não precisa ser criado ou customizado.
O quadro de grupo com outros campos devem ser criados com uma tela customizada.
Devera ser criado o layout Z00X assim como na figura abaixo:

575039736.doc
Extrator de Negativação
Negativação/Positivação de faturas
Renegativação de faturas
3.5.5. Criar Nova atividade em massa

Deve ser customizada uma nova atividade em massa da SAP na Guia de implementação -> Contabilidade
financeira -> Conta corrente contratual -> Configurações técnicas -> Preparar atividades em massa:
No caso da Negativação devera ser criada, a atividade ZEXX com objeto de paralelismo Parceiro de negocio
(GPART), modulo de atividade Z00X e layout Z00X (criados nos passos anteriores).
3.6. Fluxograma do processo
3.7. Descrição Funcional Detalhada

As tabelas, campos e BAPI standard aqui mencionados são referências e devem ser confirmadas pela
especificação técnica.
Os parâmetros que formam parte da configuração do RMCA, utilizados no desenho funcional não deverão ser
colocados como parte do código ABAP (“hardcode”) do desenho técnico.
O programa descrito nesta EF identificará todas as faturas que deverão ser enviadas/excluídas da Negativação
para os Bureau de Crédito, gerará os arquivos para cada Bureau e receberá o retorno dos Bureaus com o
resultado do envio dos arquivos. Para isso o programa deverá:
1 – Ler a lista de faturas que entraram no nivel de negativação nas reguas de cobrança.
2- Identificar faturas com quebra de acordo de parcelamento que havian sido excluidas da negativação pelo
parcelamento.
3 – Verificar os critérios de restrição para inclusão das faturas em negativação.
4 – Verificar condição de no dunning de faturas apos a expiração de restrição, antes da negativação das
mesmas.
5 – Verificar se alguma fatura enviada para negativação deverá ser excluída.

575039736.doc
6 – Fazer a distribuição de faturas por Bureau de Crédito

7 – Criar arquivo de inclusão/exclusão das faturas para negativação.
8 – Processar arquivo de volta.
9 – Gerar relatório de erros.
10 – Ajustar o historico de negativação.
Principais tabelas utilizadas:

FKKMAZE – Histórico de reclamação - itens do documento
TFK047M - Reclamar CCC - atividades de reclamação
FKKMAKO – Cabeçalho do histórico de reclamação
DFKKOP – Itens para documentos conta corrente
BUT000 – PN: dados gerais I
IST_TDATA – Dados de objetos telco para conta corrente contratual
FKKVKP – Conta de contrato - específica de parceiro
TFK047L – Reclamar CCC - definição das atividades de reclamação
TFK047A – Procedimento de advertência
ADRC - Endereços (administração de endereços central)
BUT020 - PN: endereços
DFKKBPTAXNUM - Nºs de identificação fiscal p/parceiro de negócios
BUT0ID - PN: nºs de identificação
FKK_INSTPLN_HIST - Histórico de plano de pgto.em prestações
FKK_INSTPLN_HEAD - Dados do cabeçalho do plano de pagamento em prestações
3.7.1. Fluxo Detalhado

1 - Identificação das faturas que serão Negativadas

575039736.doc

575039736.doc
2 – Identificação das faturas que deverão ser excluidas da negativação.

575039736.doc
3- Identificação de faturas marcadas para inclusão/exclusão de negativação
4 - Especificação dos campos dos arquivos para os Bureaus de credito

575039736.doc
5 - Recebimento do retorno com resultado do envio dos arquivos de Bureaus de credito

575039736.doc
3.7.2 - Descrição do Processo-Fluxos Principais
O processo de Negativação terá quatro fluxos principais:

575039736.doc
 Módulos de Função: Na transação de atividade de cobrança (FPVB), deve ser customizado um módulo
de função ZCB_NEGATIVACAO_350 para preencher informações na tabela ZTCBGEREN_NEGATI. Esta
tabela será utilizada durante o programa em paralelo de negativação.
 Programa 1 - Atividade em Massa para Negativação: Este programa deve ter lógica de paralelismo
com atividades em massa da SAP e objeto de paralelismo “Parceiro de Negócios”. Para cada fatura na
tabela de “delta” ZTCBGEREN_NEGATI o programa deve avaliar segundo criterios detalhados abaixo e
gravar dados na tabela para gerar arquivo de saída.
 Programa 2 – Geração de Arquivos de Saída: O programa 2 deve buscar dados das tabelas gravadas
pelo programa 1 e gerar arquivos de saída.
 Programa 3 – Processamento de Arquivos de Retorno. O programa 3 processara os arquivos de
retorno vindos dos diferentes Bureaus de credito.
O programa1 e o Programa 3 processam um numero elevado de dados sendo necessário usar uma técnica de
processamento paralelo com os programas disponível no SAP Standard.
A figura abaixo mostra a lógica de paralelismo com objeto parceiro de negocio.
Nota: Atualmente o mesmo programa extrai os dados, processa e cria o arquivo.
3.8. Parte 1: Criação Modulo de Função para atividade de cobrança FPVB

Será necessário criar um modulo de função ZCB_NEGATIVACAO_0350 para atividade de cobrança (transação FPVB)
como copia do template standard FKK_FILL_SAMPLE_0350.
Este modulo de função deve ser chamado por todos os níveis de cobrança NEGATIVACAO e terá da preencher
dados na tabela ZTCBGEREN_NEGATI.

575039736.doc
Segue detalhes:
Alteração do evento FKK_FILL_SAMPLE_0350 para categoria de nível de advertência ZB (SERASA), ZC(SPC) ou ZM
(EQUIFAX).
1. Identificar clientes com ação de advertência de Negativação.
1.1. Verificar existência de registro na tabela ZTCBGEREN_NEGATI com as seguintes condições :

 ZTCBGEREN_NEGATI – VTRE2 = T_FKKMAZE-VTRE2
 ZTCBGEREN_NEGATI - MSTYP = T_FKKMAZE-MSTYP
Após seleção acima, eliminar os registros que apresentem T_FKKMAZE – MSTYP <>de “ZB”, “ZC” ou “ZM”. Os
resgistros que apresentam MSTYP diferente dos citados acima, não devem ser inseridos na tabela
ZTCBGEREN_NEGATI.
1.2. Criar um registro na tabela ZTCBGEREN_NEGATI com as faturas em Negativação da forma abaixo, apenas
para os registros que não foram selecionados no item 1.1, ou seja, inserir na tabela ZTCBGEREN_NEGATI
apenas se a fatura (VTRE2) e o bureau (MSTYP) não existirem.
 ZTCBGEREN_NEGATI-LAUFD=T_FKKMAZE-LAUFD
 ZTCBGEREN_NEGATI-LAUFI=T_FKKMAZE-LAUFI
 ZTCBGEREN_NEGATI -GPART = T_FKKMAZE-GPART;
 ZTCBGEREN_NEGATI -OPBEL = T_FKKMAZE-OPBEL;

575039736.doc
 ZTCBGEREN_NEGATI - ZZDT_SELECAO = T_FKKMAZE-MDRKD.

 ZTCBGEREN_NEGATI - MSTYP = T_FKKMAZE-MSTYP
 ZTCBGEREN_NEGATI - VKONT = T_FKKMAZE-VKONT
 ZTCBGEREN_NEGATI – MINBT= Fazer um join com a tabela TFK047C com os parametros
T__FKKMAZE-MAHNV= TFK047C-MAHNV e T_FKKMAZE-MAHNS=TFK047C-MAHNS. Gravar o
TFK047C-MINBT no ZTCBGEREN_NEGATI – MINBT.
 ZTCBGEREN_NEGATI – VTRE2 = T_FKKMAZE-VTRE2
 ZTCBGEREN_NEGATI-NOVAFAT=’X’
Deve ser criado apenas um registro por GPART / OPBEL na tabela ZTCBGEREN_NEGATI.

575039736.doc
3.9. Programa 1: FM para Atividade de Negativação Z_RMCA_NEGATIVACAO
3.9.1 Premissas
1: Range de parceiros de negocio:
Todas as extrações devem seguir a lógica abaixo para seleção do range de GPART a ser analisado:
 GPART ≥ I_LOW;
 GPART ≤ I_HIGH;
 AND GPART em [range definido na Tela de seleção];
 AND GPART em tabela ZTCBGEREN_NEGATIV
Obs.: em tempo de desenvolvimento ABAP deve ser analisada a melhor forma de seleção do range de GPART: se
selecionar todos os parceiros e filtrar as condições de tela de seleção/ clientes em Negativação ou se executar
todas as condições em paralelo.
2: Sub-modulos do programa:
O usuário terá possibilidade de selecionar o processo de negativaçao que deseja executar com um “radio-button”
na tela de seleção.
Os radio button podem ser chamados:
P_Negativ -> Negativaçao e positivação (chama sub-modulo 1)
P_Renegativ -> Renegativaçao de faturas em aberto (chama sub-modulo 2)
Dependo do radio button selecionado o modulo de função Z_RMCA_NEGATIVACAO deve chamar o sub-modulo 1 ou
sub-modulo 2 com dethales abaixo.
3.9.2 – Sub-modulo 1- Negativação e positivação
1: Seleçoes dados das tabelas

1. Criar tabelas temporárias com dados para processamento:
1.1. Extrair da DFKKOP todos os registros para o range de GPART analisado com AUGST=’vazio’. Gravar o
retorno em uma tabela temporária de processamento (Temp_DFKKOP) com a seguinte estrutura: OPBEL,
OPUPK, OPUPW, OPUPZ, AUGST, GPART, VTRE2, ABWBL, BETRW, BLART, HVORG, TVORG, FAEDN, STUDT.
1.2. Extrair da BUT020 todos os registros para o range de GPART analisado, entrar na tabela ADRC e identificar
a REGION e gravar o retorno em uma tabela temporária de processamento (TEMP_ADRC) com a seguinte
estrutura: GPART, REGION, CITY1, STREET, HOUSE_NUM1, HOUSE_NUM2, POST_CODE1 e CITY2.

575039736.doc
1.3. Extrair da DFKKBPTAXNUM todos os registros para o range de GPART analisado e gravar o retorno em uma
tabela temporária de processamento (Temp_ DFKKBPTAXNUM) com a seguinte estrutura: GPART, TAXTYPE
e TAXNUM.
1.4. Extrair da BUT000 todos os registros para o range de GPART analisado e gravar o retorno em uma tabela
temporária de processamento (Temp_BUT000) com a seguinte estrutura:
GPART, ZSEGMENTAÇAO, ZSUBSEGMENTAÇÃO, ZZCCUSTO, NAME_FIRST , NAME_LAST, NAME_ORG1 e
customer_id.
1.5. Extrair da BUT0ID todos os registros para o range de GPART analisado e BUT_0ID-TYPE=’CUSTCD’. Gravar o
retorno em uma tabela temporária de processamento (Temp_BUT0ID) com a seguinte estrutura: GPART,
IDNUMBER.
2: Validação de cliente em Negativação

Este submodulo 1 tem 3 steps que serão detalhados em baixo:
 Step 1 – Processamento de novas faturas inseridas na tabela ZTCBGEREN_NEGATI (da FPVB)

 Step 2 – Processamento de faturas antigas presentes na tabela ZTCBGEREN_NEGATI ainda não negativadas.
 Step 3 – Identificação de faturas pagas / parceladas com entrada paga que devem ser positivadas.
Step 1 – Processamento de novas faturas inseridas na tabela ZTCBGEREN_NEGATI pelo modulo de função
Extrair da tabela ZTCBGEREN_NEGATI todos os registros para o range de GPART analisado e campo NOVAFAT=’X’ e
gravar o retorno em uma tabela temporária de processamento (Temp1_ ZTCBGEREN_NEGATI) com a seguinte
estrutura: GPART, OPBEL, MDRKD, e MSTYP.
3. Identificação de restrições de envio para negativação, ativas. (Tabelas ZTCBRESTR_NEGATI e

ZTCBGEREN_NEGATI descritas na EF CB.028.1 Transaçoes customizadas para configuração de criterios de
negativação)
3.1 Identificação de restrição para a UF do cliente da fatura selecionada para negativação.
Para cada fatura OPBEL da TEMP1_ ZTCBGEREN_NEGATI, identificar na tabela ZTCBRESTR_NEGATI se existe
algum registro com campo UF= TEMP_ADRC-REGION, com campo Data de inicio =< SY-DATUM e campo Data de
fim >=SY_DATUM.
Caso seja encontrado algum registro na tabela ZTCBRESTR_NEGATI que cumpra a condição descrita acima
ativar flag ZTCBGEREN_NEGATI - ZZ_RESTR_UF (Identificação de fatura com restrição de envio por UF) para a
fatura em analise.
Caso contratrio (Não foi encontrado nenhum registro na tabela ZTCBRESTR_NEGATI) retirar flag do campo
ZTCBGEREN_NEGATI - ZZ_RESTR_UF caso esteja preenchido e preencher o campo ZTCBGEREN_NEGATI-
ZZ_RESTR_LIB com ‘X’ para a fatura em analise.

575039736.doc
3.2 Identificação de restrição para a cidade do cliente da fatura selecionada para negativação.
Para cada registro da tabela TEMP1_ ZTCBGEREN_NEGATI, identificar na tabela ZTCBRESTR_NEGATI se existe
algum registro com campo UF= TEMP_ADRC-REGION e campo Cidade= TEMP_ADRC-CITY1, com campo Data de
inicio =< SY-DATUM e campo Data de fim >=SY_DATUM.
ativar flag ZTCBGEREN_NEGATI - ZZ_RESTR_CID (Identificação de fatura com restrição de envio por Cidade)
para a fatura em analise.
Caso contratrio (Não foi encontrado nenhum registro na tabela ZTCBGEREN_NEGATI) retirar flag do campo
ZTCBGEREN_NEGATI - ZZ_RESTR_CID caso esteja preenchido e preencher o campo ZTCBRESTR_NEGATI-
ZZ_RESTR_LIB com ‘X’ para a fatura em analise.
4. Identificação de valor a negativar.
4.1 – Identificação de itens da fatura selecionada para negativação.
Na tabela TEMP_DFKKOP identificar todos os registros com TEMP_DFKKOP-OPBEL =

TEMP1_ZTCBGEREN_NEGATI-OPBEL da seleção feita no passo 1.1. Excluir aqueles com TEMP_DFKKOP-
HVORG iguais aos HVORG presentes na tabela Operadoras LD da EF PG.013 Extractor de pagamento de
Co-billing(Exclusão de itens de operadoras LD) e aqueles com HVORG e TVORG iguais ao HVORG e TVORG
com ID_Processo = 02 da tabela ZTCB_ITEM_PROCESSO descrita na EF CB.011.1 Tratamento de recarga
programada e conta fixa_interface_RP. (Exclusão de itens de fatura de recarga programada)
4.2 Calculo de valor em aberto.
Para todos itens do mesmo documento (TEMP_DFKKOP-OPBEL comum a todos os itens) identificados no
passo 4.1 o programa deverá checar o valor do cada item no campo Montante TEMP_DFKKOP-BETRW e
totalizar o valor de todos eles numa variavel temporaria no sistema. (Montante em divida para TIM e LD41)
Este sera o valor da fatura que devera ser enviado a negativação(Montante em divida para TIM e LD 41
sem recarga programada.)
5. Validação de envio para o Bureau de credito indicado no nivel de cobrança

(MSTYP=ZB ou MSTYP=ZC ou MSTYP=ZM).
Identificar na tabela ZTCBCRIT_DISTRIB se existe algum registro com campo ZZIND_PFPJ = dado
encontrado no campo TEMP_ DFKKBPTAXNUM -TAXTYPE no passo 2.3 , campo ZZVL_MIN =< valor em
aberto calculado no passo 4.2 e campo ZZBUREAU = TEMP1_ ZTCBGEREN_NEGATI-MSTYP identificado para
a fatura no passo 1.1
IF verdadeiro:
Identificar critrerios de distribuição como cumpridos para o bureau de credito.

(Deixar campo status da inclusão em branco na tabela ZTCBGEREN_NEGATI )
ELSE
Casso contrario:
Identificar criterios como não cumpridos para o Bureau de credito indicado na regua de cobrança.
Devera ser registrado no log de erro a mensagem que indique ‘Fatura XXX não cumpre os criterios de
distribuição: CPF/CNPJ= dado encontrado no campo TAXTYPE no passo 2.3, valor =< valor em aberto
calculado no passo 4.2 para o Bureau XXXXX’ (Bureau indicado para a fatura no passo 1.1).

575039736.doc
Exemplo:
Tabela Configurações de criterios para distribução de cliente por Bureau de credito.(Tabela de exemplo, sem
valores reais)
Bureau CPF/CNPJ Valor minimo
Serasa BR1 60
Serasa BR2 60
SPC BR1 60
SPC BR2 60
A fatura em analise apresenta as seguintes caracteristicas:

Cliente Pessoa Fisica: BR1
Valor da fatura para itens TIM e LD 41: 80 R$
Bureau de credito indicado pela regua de cobrança: Serasa
Nesse caso o Bureau de credito selecionado cumpre com todos os criterios cadastrados na tabela
Configurações de criterios para distribução de cliente por Bureau de credito para o Bureau Serasa como é
mostrado na tabela exemplo.
6. – Atualização de informações de faturas a negativar na tabela Z de Gerenciamento da Negativação.
A tabela ZTCBGEREN_NEGATI deverá ser atualizada com as seguintes informações por OPBEL:
Os campos a ser atualizados são:

- Data da Seleção: Data em que a fatura entro no nivel de negativação Temp1_ ZTCBGEREN_NEGATI-
MDRKD(Data de execução da advertência) do registro selecionado no passo 1.1
- UF: UF do Parceiro de negocios indentificada no punto 2.2 Temp_ADRC-REGION
- Cidade: Cidade do cliente indentificada no punto 2.2 Temp_ADRC-CITY1
- Operadora: Identificar na tabela ZTDMCOSTCENTEROP o ZZIDOPERADORA para os ZTDMCOSTCENTEROP_
ZZCOST_ID= Temp_BUT000-ZZCCUSTO identificado no passo 2.4
- Custcode: Custcode do cliente identificado no passo Temp_BUT0ID-IDNUMBER 2.5
- Parceiro de negócios (GPART): este campo devera ser atualizado com o campo Temp1_ ZTCBGEREN_NEGATI -
GPART do registro selecionado no passo 1.1
- Conta Contrato (VKONT): Este campo deverá ser atualizado com o campo Temp1_ ZTCBGEREN_NEGATI -VKONT
do registro selecionado no passo 1.1
- Número do documento no RMCA (OPBEL): Este campo deverá ser atualizado com o campo Temp1_
ZTCBGEREN_NEGATI-OPBEL do registro selecionado no passo 1.1
- Numero da fatura (VTRE2): este campo devera ser atualizado com o Numero da fatura identificado no passo
1.1 Temp1_ ZTCBGEREN_NEGATI-VTRE2.
- Data de vencimento da fatura: verificar se o campo Temp_DFKKOP-STUDT está preenchido com ´00.00.0000
´. Caso esteja, extrair o conteúdo do campo Temp_DFKKOP -FAEDN. Caso não esteja, extrair o conteúdo do
campo Temp_DFKKOP -STUDT(Diferimento até) para os FATNEGTEMP-OPBEL identificados nos passo 2.1
- Valor: Este campo deverá ser atualizado com o valor armazenado na variavel temporaria para calcular o
valor total de cada documento Temp_DFKKOP -OPBEL so para itens TIM e LD 41. Calculo feito no ponto 4.2
- NOME: Temp_BUT000-NAME_FIRST <espaço> Temp_BUT000-NAME_LAST se TEMP_ DFKKBPTAXNUM –
TAXTYPE=’BR2’ e Temp_BUT000-NAME_ORG1 caso TEMP_ DFKKBPTAXNUM –TAXTYPE=’BR1’.
- TAXNUM: Numero de CPF/CNPJ do cliente identificado no passo 2.3 Temp1_DFKKBPTAXNUM-TAXNUM
- Endereço: TEMP_ADRC-STREET + <espaço> + TEMP_ADRC- HOUSE_NUM1 + <espaço>+ TEMP_ADRC -
HOUSE_NUM2 (Endereço). Endereço identificado no passo 2.2.
- CEP: TEMP_ADRC-POST_CODE1 identificado no passo 2.2
- Barrio: TEMP_ADRC-CITY2 identificado no passo 2.2
- Tipo de cliente: TEMP_ DFKKBPTAXNUM -TAXTYPE identificado no passo 2.3
- Codigo do contrato: para os casos que Temp1_ ZTCBGEREN_NEGATI -MSTYP=’ZB’:
Identificar na tabela ZTCBT_INF_OPERA o ZZCOD_CONTRATO, para os ZTCBT_INF_OPERA-ZZID_CENTRO =
Temp_BUT000-ZZCUSTO identificado.

575039736.doc
Para os casos em que Temp1_ ZTCBGEREN_NEGATI -MSTYP =’ZC’ ou Temp1_ ZTCBGEREN_NEGATI -MSTYP
=’ZM’ :
Identificar na tabela ZTCBT_INF_OPERA_SPC o ZZCOD_CONTRATO, para os ZTCBT_INF_OPERA_SPC-
ZZID_CENTRO = Temp_BUT000-ZZCUSTO identificado.
- ID do centro de custo: TEMP_BUT000-ZZCUSTO identificado no passo 2.4
- CNPJ RAIZ Operadora: Identificar na tabela ZTCBT_INF_OPERA o ZZCNPJ_RAIZ para os ZTCBT_INF_OPERA-
ZZID_CENTRO =Temp_BUT000-ZZCUSTO identificado, para os casos que Temp1_ ZTCBGEREN_NEGATI -
MSTYP=’ZB’. Casos em que Temp1_ ZTCBGEREN_NEGATI -MSTYP=’ZC’ ou ‘ZM’ deixar campo em branco.
- Filial: Identificar na tabela ZTCBT_INF_OPERA o ZZFILIAL, para os ZTCBT_INF_OPERA-ZZID_CENTRO
=Temp_BUT000-ZZCUSTO identificado, para os casos que Temp1_ ZTCBGEREN_NEGATI -MSTYP=’ZB’.
Casos em que Temp1_ ZTCBGEREN_NEGATI -MSTYP=’ZC’ ou ‘ZM’ deixar campo em branco.
- Status da inclusão: este campo devera ser preenchido da seguinte forma:
Se os criterios de distribuição não foram cumpridos no passo 3. para a fatura em analise o campo
devera ser preenchido da seguinte forma:
CPF/CNPJ encontrado no campo TAXTYPE no passo 2.3 valor em aberto calculado no passo 4.2.
Caso todos os criterios checados no passo 5. para a fatura estejam cumpridos deixar campo em
branco.
- A incluir: Marcar com ‘X’ caso os criterios de seleção do Bureau de credito foram cumpridos (campo status
da inclusão foi deixado em branco), e campo ZTCBGEREN_NEGATI -Restrição liberada = ‘X’.
- Data de envio a inclusão: preencher com SY-DATUM, caso os criterios de seleção do Bureau de credito foram
cumpridos (campo status da inclusão foi deixado em branco), e campo ZTCBGEREN_NEGATI -Restrição liberada
= ‘X’.
- Customer_id : TEMP_BUT000-CUSTOMER_ID identificado no passo 2.4
- Código Febraban da operadora: Identificar na tabela ZTDMCOSTCENTEROP o ZZFEBRABAN para os
ZTDMCOSTCENTEROP_ ZZCOST_ID= Temp_BUT000-ZZCCUSTO identificado no passo 2.4
OBS: Todo registro que seja incorporado ou modificado na tabela ZTCBGEREN_NEGATI devera ser atualizado na
tabela Z_Historico de negativação como um novo registro. (Tabela descrita na EF CB.028.1).
Atualizar a tabela temporaria ZTCBGEREN_NEGATI_TEMP_ARQ com a informação das faturas que devem ir no
arquivo.(Faturas identificadas para serem incluidas no Bureau de credito). (MSTYP, ZZCOD_CONTRATO, ZZTAXNUM,
ZZNOME, ZZENDE, ZZBAIRRO, ZZCEP, ZZCIDADE, ZZUF, ZZDAT_VENC, VTRE2, ZZVLR_FAT, ZZCNPJRAIZ_CTO,
ZZFILIAL, ZZTIPOCLI, ZZIDCTROCUSTO, CUSTOMER_ID, ZZFEBRABAN.)
Step 2 – Processamento de faturas antigas presentes na tabela ZTCBGEREN_NEGATI ainda não negativadas.
7. Extrair da tabela ZTCBGEREN_NEGATI todos os registros para o range de GPART analisado segundo os
criterios:
o Faturas com restrição de negativação ativa. Identificar na tabela ZTCBGEREN_NEGATI as faturas
com campo ZZ_RESTR_UF=’X’ ou ZZ_RESTR_CID=’X’.
o Faturas com No Dunning ativo. Identificar na tabela ZTCBGEREN_NEGATI as faturas com campo
ZZ_DUNNING_FAT= ‘X’ ou ZZ_DUNNING_CONTR=’X’.
o Faturas com erro na inclusão que precisam ser reenviadas. Identificar na tabela
ZTCBGEREN_NEGATI as faturas com flag ZZREPROCINC . Limpar o flag ZZREPROCINC após a carga
das faturas na tabela TEMP2_ ZTCBGEREN_NEGATI.

575039736.doc
Gravar na tabela TEMP2_ ZTCBGEREN_NEGATI com a estrutura GPART, OPBEL, MDRKD, MINBT e MSTYP.
Extrair da DFKKLOCKS todos os registros para o range de GPART analisado (range inicial) e GPART da tabela
temporarea TEMP2_ ZTCBGEREN_NEGATI. Gravar o retorno em uma tabela temporária de processamento
(Temp_DFKKLOCKS) com a seguinte estrutura: : GPART, LOOBJ1(12), LOTYP, PROID, LOCKR, TDATE.
8. Identificação de restrições de envio para negativação, ativas.
8.1 Identificação de restrição para a UF do cliente da fatura selecionada para negativação.
Para cada fatura OPBEL da TEMP2_ ZTCBGEREN_NEGATI, identificar na tabela ZTCBRESTR_NEGATI se existe
algum registro com campo UF= TEMP_ADRC-REGION, com campo Data de inicio =< SY-DATUM e campo Data de
fim >=SY_DATUM.
ativar flag ZTCBGEREN_NEGATI - ZZ_RESTR_UF (Identificação de fatura com restrição de envio por UF) para a
fatura em analise.
Caso contratrio (Não foi encontrado nenhum registro na tabela ZTCBRESTR_NEGATI) retirar flag do campo
ZTCBGEREN_NEGATI - ZZ_RESTR_UF e preencher o campo ZTCBGEREN_NEGATI-ZZ_RESTR_LIB com ‘X’ para a
fatura em analise.
8.2 Identificação de restrição para a cidade do cliente da fatura selecionada para negativação.
Para cada registro da tabela TEMP2_ ZTCBGEREN_NEGATI, identificar na tabela ZTCBRESTR_NEGATI se existe
algum registro com campo UF= TEMP_ADRC-REGION e campo Cidade= TEMP_ADRC-CITY1, com campo Data de
inicio =< SY-DATUM e campo Data de fim >=SY_DATUM.
ativar flag ZTCBGEREN_NEGATI - ZZ_RESTR_CID (Identificação de fatura com restrição de envio por Cidade)
para a fatura em analise.
Caso contratrio (Não foi encontrado nenhum registro na tabela ZTCBGEREN_NEGATI) retirar flag do campo
ZTCBGEREN_NEGATI - ZZ_RESTR_CID e preencher o campo ZTCBRESTR_NEGATI- ZZ_RESTR_LIB com ‘X’ para a
fatura em analise.
9. Verificação de faturas/clientes em no dunning.
9.1 Verificação de no dunning para fatura identificada sem restrição no passo 8. (ZTCBRESTR_NEGATI-
ZZ_RESTR_LIB=’X’)(Caso a fatura não esteja identificada com restrição liberada o passo 9 não devera ser
validado.)
Para as faturas presentes na tabela TEMP2_ZTCBGEREN_NEGATI identificar na Tabela

TEMP_DFKKLOCKS(Bloqueios comerciais) se existe algum motivo de não dunning ativo para a fatura
selecionada.
Entrar na tabela TEMP_DFKKLOCKS com o numero de TEMP2_ZTCBGEREN_NEGATI-OPBEL=

TEMP_DFKKLOCKS-LOOBJ1(12) com TEMP_DFKKLOCKS-PROID= ‘01’(Isenção de advertencia) e
TEMP_DFKKLOCKS-LOTYP=‘02’ (nivel de item de documento).
Para os LOOBJ1(12)(Objeto de Bloqueio) identificados:

575039736.doc
IF algum TEMP_DFKKLOCKS-FDATE =< SY- DATUM AND TEMP_DFKKLOCKS-TDATE >= SY-DATUM (No dunning
por algum motivo ainda ativo).
Caso seja encontrado algum registro na tabela TEMP_DFKKLOCKS que cumpra a condição descrita acima
ativar flag ZTCBGEREN_NEGATI- ZZ_DUNNING_FAT. Para o OPBEL em analise.
Caso contrario (Não foi encontrado nenhum registro na tabela DFKKLOCKS) retirar flag do campo
ZTCBGEREN_NEGATI- ZZ_DUNNING_FAT caso esteja preenchido e preencher o campo ZZ_DUNNING_LIB
com ‘X’ para a fatura em analise.
9.2 Identificar na Tabela TEMP_DFKKLOCKS(Bloqueios comerciais) se existe algum motivo de não dunning
ativo para a conta contrato selecionada.
Entrar na tabela TEMP_DFKKLOCKS com TEMP2_ZTCBGEREN_NEGATI-VKONT=TEMP_DFKKLOCKS-LOOBJ1(12)

e com TEMP_DFKKLOCKS-PROID= ‘01’ (Isenção de advertencia) e TEMP_DFKKLOCKS-LOTYP=‘06’ (nivel de
conta contrato).

por algum motivo ainda ativo)
Caso seja encontrado algum registro na tabela TEMP_DFKKLOCKS que cumpra a condição descrita acima
ativar flag ZTCBGEREN_NEGATI- ZZ_DUNNING_CONTR.
Caso contratrio (Não foi encontrado nenhum registro na tabela TEMP_DFKKLOCKS) retirar flag do campo
ZTCBGEREN_NEGATI- ZZ_DUNNING_CONTR caso esteja preenchido e preencher o campo ZZ_DUNNING_LIB
com ‘X’ para a fatura em analise.
10. Identificação de valor a negativar.
10.1 – Identificação de itens da fatura selecionada para negativação.
Na tabela TEMP_DFKKOP identificar todos os registros com TEMP_DFKKOP-OPBEL =

TEMP2_ZTCBGEREN_NEGATI-OPBEL. Excluir aqueles com TEMP_DFKKOP-HVORG iguais aos HVORG
presentes na tabela Operadoras LD da EF PG.013 Extractor de pagamento de Co-billing(Exclusão de itens
de operadoras LD) e aqueles com HVORG e TVORG iguais ao HVORG e TVORG com ID_Processo = 02 da
tabela ZTCB_ITEM_PROCESSO descrita na EF CB.011.1 Tratamento de recarga programada e conta
fixa_interface_RP. (Exclusão de itens de fatura de recarga programada)
10.2 Calculo de valor em aberto.
Para todos itens do mesmo documento (TEMP_DFKKOP-OPBEL comum a todos os itens) identificados no
passo 10.1 o programa deverá checar o valor do cada item no campo Montante TEMP_DFKKOP-BETRW e
totalizar o valor de todos eles numa variavel temporaria no sistema. (Montante em divida para TIM e LD41)
Este sera o valor da fatura que devera ser enviado a negativação(Montante em divida para TIM e LD 41
sem recarga programada.) caso seja maior que o minimo de cobrança (verificação no passo 10.3 abaixo)
10.3 Verificação de valor em aberto dentro do valor minimo permitido para entrar no nivel de
negativação.
Se valor total dos itens em aberto (só TIM e LD 41) para o documento Temp2_ZTCBGEREN_NEGATI -OPBEL
em analise é menor que o valor no campo Temp2_ZTCBGEREN_NEGATI – MINBT (Montante limite) ou se não
foram achados registros para o OPBEL em analise na tabela TEMP_DFKKOP.

575039736.doc
Desconsiderar a fatura do analise, deletar o registro da tabela ZTCBGEREN_NEGATI, preencher o

registro na tabela ZTCBHIS_NEGATI com campo ZZVLR_FAT=0 e continuar o processamento da
proxima fatura na tabela Temp2_ZTCBGEREN_NEGATI –OPBEL.
Se o valor total dos itens em aberto é maior ou igual que o valor no campo Temp2_ZTCBGEREN_NEGATI –
MINBT, continuar o processamento normal da fatura.
11.Validação de envio para o Bureau de credito indicado no nivel de cobrança(MSTYP=ZB ou MSTYP=ZC ou

MSTYP=ZM).
Identificar na tabela ZTCBCRIT_DISTRIB se existe algum registro com campo ZZIND_PFPJ = dado
encontrado no campo TEMP_ DFKKBPTAXNUM -TAXTYPE no passo 2.3 , campo ZZVL_MIN =< valor em
aberto calculado no passo 10.2 e campo ZZBUREAU = TEMP1_ ZTCBGEREN_NEGATI-MSTYP identificado
para a fatura no passo 1.1
IF verdadeiro:
Identificar critrerios de distribuição como cumpridos para o bureau de credito.

(Deixar campo status da inclusão em branco na tabela ZTCBGEREN_NEGATI )
ELSE
Casso contrario:
Identificar criterios como não cumpridos para o Bureau de credito indicado na regua de cobrança.
Devera ser registrado no log de erro a mensagem que indique ‘Fatura XXX não cumpre os criterios de
distribuição: CPF/CNPJ= dado encontrado no campo TAXTYPE no passo 2.3, valor =< valor em aberto
calculado no passo 10.2 para o Bureau XXXXX’ (Bureau indicado para a fatura no passo 1.1).
12. – Atualização de informações de faturas a negativar na tabela Z de Gerenciamento da Negativação.
A tabela ZTCBGEREN_NEGATI deverá ser atualizada com as seguintes informações por OPBEL:
Os campos a ser atualizados são:

- Data da Seleção: Data em que a fatura entro no nivel de negativação Temp2_ ZTCBGEREN_NEGATI-
MDRKD(Data de execução da advertência).
- UF: UF do Parceiro de negocios indentificada no punto 2.2 Temp_ADRC-REGION
- Cidade: Cidade do cliente indentificada no punto 2.2 Temp_ADRC-CITY1
- Operadora: Identificar na tabela ZTDMCOSTCENTEROP o ZZIDOPERADORA para os ZTDMCOSTCENTEROP_
ZZCOST_ID= Temp_BUT000-ZZCCUSTO.
- Custcode: Custcode co cliente identificado no passo Temp_BUT0ID-IDNUMBER 2.5
- Parceiro de negócios (GPART): este campo devera ser atualizado com o campo Temp2_ ZTCBGEREN_NEGATI -
GPART do registro em analise.
- Conta Contrato (VKONT): Este campo deverá ser atualizado com o campo Temp2_ ZTCBGEREN_NEGATI -VKONT
do registro em analise.
- Número do documento no RMCA (OPBEL): Este campo deverá ser atualizado com o campo Temp2_
ZTCBGEREN_NEGATI-OPBEL em analise.
- Numero da fatura (VTRE2): este campo devera ser atualizado com o Numero da fatura Temp2_
ZTCBGEREN_NEGATI-VTRE2 em analise.
- Data de vencimento da fatura: verificar se o campo Temp_DFKKOP-STUDT está preenchido com ´00.00.0000
´. Caso esteja, extrair o conteúdo do campo Temp_DFKKOP -FAEDN. Caso não esteja, extrair o conteúdo do
campo Temp_DFKKOP -STUDT(Diferimento até) para o OPBEL em analise Temp2_ ZTCBGEREN_NEGATI-OPBEL.
- Valor: Este campo deverá ser atualizado com o valor armazenado na variavel temporaria para calcular o
valor total de cada documento Temp_DFKKOP -OPBEL so para itens TIM e LD 41. Calculo feito no passo 10.

575039736.doc
- NOME: Temp_BUT000-NAME_FIRST <espaço> Temp_BUT000-NAME_LAST se TEMP_ DFKKBPTAXNUM –

TAXTYPE=’BR2’ e Temp_BUT000-NAME_ORG1 caso TEMP_ DFKKBPTAXNUM –TAXTYPE=’BR1’.
- TAXNUM: Numero de CPF/CNPJ do cliente identificado no passo 1.4 Temp_DFKKBPTAXNUM-TAXNUM
- Endereço: TEMP_ADRC-STREET + <espaço> + TEMP_ADRC- HOUSE_NUM1 + <espaço>+ TEMP_ADRC -
HOUSE_NUM2 (Endereço). Endereço identificado no passo 2.2.
- CEP: TEMP_ADRC-POST_CODE1 identificado no passo 2.2
- Barrio: TEMP_ADRC-CITY2 identificado no passo 2.2
- Tipo de cliente: TEMP_ DFKKBPTAXNUM -TAXTYPE identificado no passo 2.3
- Codigo do contrato: para os casos que Temp1_ ZTCBGEREN_NEGATI -MSTYP=’ZB’:
Identificar na tabela ZTCBT_INF_OPERA o ZZCOD_CONTRATO, para os ZTCBT_INF_OPERA-ZZID_CENTRO =
Temp_BUT000-ZZCUSTO identificado.
Para os casos em que Temp1_ ZTCBGEREN_NEGATI -MSTYP =’ZC’ ou Temp1_ ZTCBGEREN_NEGATI -MSTYP =’ZM’
:
Identificar na tabela ZTCBT_INF_OPERA_SPC o ZZCOD_CONTRATO, para os ZTCBT_INF_OPERA_SPC-
ZZID_CENTRO = Temp_BUT000-ZZCUSTO identificado.
- ID do centro de custo: TEMP_BUT000-ZZCUSTO identificado no passo 2.4
- CNPJ RAIZ Operadora: Identificar na tabela ZTCBT_INF_OPERA o ZZCNPJ_RAIZ para os ZTCBT_INF_OPERA-
ZZID_CENTRO =Temp_BUT000-ZZCUSTO identificado, para os casos que Temp1_ ZTCBGEREN_NEGATI -
MSTYP=’ZB’. Casos em que Temp1_ ZTCBGEREN_NEGATI -MSTYP=’ZC’ ou ‘ZM’ deixar campo em branco.
- Filial: Identificar na tabela ZTCBT_INF_OPERA o ZZFILIAL, para os ZTCBT_INF_OPERA-ZZID_CENTRO
=Temp_BUT000-ZZCUSTO identificado, para os casos que Temp1_ ZTCBGEREN_NEGATI -MSTYP=’ZB’.
Casos em que Temp1_ ZTCBGEREN_NEGATI -MSTYP=’ZC’ ou ‘ZM’ deixar campo em branco.
- Status da inclusão: este campo devera ser preenchido da seguinte forma:
Se os criterios de distribuição não foram cumpridos no passo 3. para a fatura em analise o campo
devera ser preenchido da seguinte forma:
CPF/CNPJ encontrado no campo TAXTYPE no passo 2.3 <espaço> valor em aberto calculado no
passo 10.2.
Caso todos os criterios checados no passo 11. para a fatura estejam cumpridos deixar campo em
branco.
- A incluir: Marcar com ‘X’ caso os criterios de seleção do Bureau de credito foram cumpridos (campo status
da inclusão foi deixado em branco), campo Restrição liberada = ‘X’ e campo No Dunning liberado=’X’.
- Customer_id : TEMP_BUT000-CUSTOMER_ID identificado no passo 2.4
- Código Febraban da operadora: Identificar na tabela ZTDMCOSTCENTEROP o ZZFEBRABAN para os
ZTDMCOSTCENTEROP_ ZZCOST_ID= Temp_BUT000-ZZCCUSTO identificado no passo 2.4
OBS: Todo registro que seja incorporado ou modificado na tabela Z_Gerenciamento da negativação devera ser
atualizado na tabela Z_Historico de negativação como um novo registro. (Tabela descrita na EF CB.028.1).
Atualizar a tabela temporaria ZTCBGEREN_NEGATI_TEMP_ARQ com a informação das faturas que devem ir no
arquivo.(Faturas identificadas para serem incluidas no Bureau de credito). (MSTYP, ZZCOD_CONTRATO,
ZZTAXNUM, ZZNOME, ZZENDE, ZZBAIRRO, ZZCEP, ZZCIDADE, ZZUF, ZZDAT_VENC, VTRE2, ZZVLR_FAT,
ZZCNPJRAIZ_CTO, ZZFILIAL, ZZTIPOCLI, ZZIDCTROCUSTO, CUSTOMER_ID, ZZFEBRABAN.)
Step 3 – Identificação de faturas pagas / parceladas com entrada paga que devem ser positivadas.
13. Extrair da ZTCBGEREN_NEGATI todos os registros para o range de GPART analisado que estejam com:
- O campo “data de envio inclusão” preenchido.
- O campo “data de envio exclusão” em branco.
(isso significa que a fatura já foi enviada para Negativaçao e ainda não foi excluída e poderá ser excluída por
algum motivo).

575039736.doc
Gravar na tabela TEMP3_ZTCBGEREN_NEGATI.
14. Identificação de valor em aberto para as faturas que estão negativadas.

O programa devera checar diariamente o valor em aberto(na tabela DFKKOP) para os itens TIM e LD 41 das
faturas com status enviadas a negativação e ainda não excluidas na tabela ZTCBGEREN_NEGATI.
14.1 Na tabela Temp_DFKKOP identificar todos os registros com mesmo numero de

Temp3_ZTCBGEREN_NEGATI-OPBEL. Excluir aqueles com DFKKOP-HVORG iguais aos HVORG’s presentes
na tabela Operadoras LD campo Operação Principal da EF PG.013 Extractor de pagamento de Co-
billing(Exclusão de itens de operadoras LD) e aqueles com HVORG e TVORG iguais ao HVORG e TVORG
com ID_Processo = 02 da tabela ZTCB_ITEM_PROCESSO descrita na EF CB.011.1 Tratamento de recarga
programada e conta fixa_interface_RP. (Exclusão de itens de fatura de recarga programada)
14.2 Para todos itens do documento identificados no paso 14.1 o sistema deverá checar o valor do
item no campo Montante Temp_DFKKOP-BETRW (Montante na moeda de transação com sinal +/-) e
totalizar o valor deles numa variavel temporaria no sistema. (Montante em divida para TIM e LD41
nesse momento).
Caso não exista nenhum registro na tabela Temp_DFKKOP para o OPBEL em analise (A fatura esta
completamente paga) Flegar campo ‘A Excluir’ na tabela ZTCBGEREN_NEGATI para o documento
OPBEL em analise, e preencher o campo Motivo da exclusão com ‘01’ (pagamento da dívida).
Continuar no passo 15.
14.3 Verificação de valor em aberto dentro do valor minimo permitido para entrar no nivel de
negativação.
Se valor total dos itens em aberto (só TIM e LD 41) para o documento Temp3_ZTCBGEREN_NEGATI -
OPBEL em analise é menor que o valor no campo Temp3_ZTCBGEREN_NEGATI – MINBT (Montante
limite)
Flegar campo ‘A Excluir’ na tabela ZTCBGEREN_NEGATI para o documento OPBEL em analise,

preencher o campo Motivo da exclusão com ‘01’ (pagamento da dívida) e continuar no passo 15.
14. Verificação de faturas em negativação parceladas com entrada paga.
14.1 Para os registros identificados no paso 13 e não marcados para exclusão no passo 14 (faturas ainda
negativadas com valor em aberto acima do valor minimo de cobrança)
Checar se fatura foi parcelada.
Identificar na tabela TEMP_DFKKOP se para o OPBEL em analise (Temp3_ZTCBGEREN_NEGATI –OPBEL) o campo

TEMP_DFKKOP-ABWBL. Caso não esteja preenchido desconsiderar o OPBEL em analise
Temp3_ZTCBGEREN_NEGATI –OPBEL e iniciar o processamento para uma outra fatura.
14.2 Identificação de entrada paga para parcelamento identificado acima.
Entrar novamente na tabela com campo Temp_DFKKOP-OPBEL = Temp3_DFKKOP-ABWBL identificado

no passo 14.1 e Temp3_DFKKOP-OPUPK=’0001’. Caso não seja encontrado nenhum registro:
Ativar flag ZZ_A_EXCLUIR na tabela ZTCBGEREN_NEGATI para o documento OPBEL em analise,

preencher o campo ZZMOTIVO_EXCL com ‘02’ (renegociação da dívida). Ativar Flag
ZTCBGEREN_NEGATI -ZZPAR_ENTRADA_PG com ‘X’.

575039736.doc
15. Extrair da tabela ZTCBGEREN_NEGATI todos os registros para o range de GPART analisado e campo
ZZ_A_EXCLUIR=’X’ e campo ZZDT_ENVIO_EXCL=vazio e gravar o retorno na tabela temporária de
processamento ZTCBGEREN_NEGATI_TEMP_ARQ com a seguinte estrutura:
MSTYP, ZZ_A_EXCLUIR, ZZCOD_CONTRATO, ZZTAXNUM, ZZNOME, ZZENDE, ZZBAIRRO, ZZCEP, ZZCIDADE, ZZUF,
ZZDAT_VENC, VTRE2, ZZVLR_FAT, ZZCNPJRAIZ_CTO, ZZFILIAL, ZZTIPOCLI, ZZIDCTROCUSTO, ZZMOTIVO_EXCL.
Excluir os casos que o ZZMOTIVO_EXCL=’97’ (Faturas indicadas pelo usuario como faturas negativadas a mais
de X anos, não precisam ser incluidas no arquivo.)
3.9.3 –Sub-modulo 2: Identificação de faturas retiradas da negativação com valor reaberto
Este sub-modulo tem uma verificação de valores novamente abertos, acima do minimo de cobrança para
faturas já excluidas da negativação.
Na tabela ZTCBGEREN_NEGATI (gerenciamento da negativação selecionar as faturas (OPBEL) com parceiro de

negocio no range selecionado (I_LOW, I_HIGH, Tela de seleção), campos A Excluir= ‘X’ , campo data da
Confirmação da exclusão > = SY-DATUM – ZTCB_QUANTREV-DIAS (Por exemplo 90 días) (para o
ZTCBQUANTREV-ID do processo = ‘1’), campo ZZPAR_ENTRADA_PG= ‘vazio’ e campo ZZMOTIVO_EXCL = ‘01’ ou
‘02’ . Carregar na tabela temporaria Temp4_ ZTCBGEREN_NEGATI.
Extrair da DFKKOP todos os registros para o range de GPART em Temp4_ ZTCBGEREN_NEGATI com
AUGST=’vazio’. Gravar o retorno em uma tabela temporária de processamento (Temp_DFKKOP) com a
seguinte estrutura: OPBEL, OPUPK, OPUPW, OPUPZ, AUGST, GPART, VTRE2, ABWBL, BETRW, BLART, HVORG,
TVORG.
Extrair da DFKKLOCKS todos os registros para o range de GPART analisado (range inicial) e GPART da tabela
temporarea TEMP4_ ZTCBGEREN_NEGATI. Gravar o retorno em uma tabela temporária de processamento
(Temp_DFKKLOCKS) com a seguinte estrutura: : GPART, LOOBJ1(12), LOTYP, PROID, LOCKR, TDATE.
6.1 Identificação de valor em aberto para as faturas selecionadas.

O programa devera checar o valor em aberto(na tabela Temp_DFKKOP) para os itens TIM e LD 41 das faturas
com status excluidas carregadas na tabela Temp4_ ZTCBGEREN_NEGATI.
6.1.2 Na tabela TEMP_DFKKOP identificar todos os registros com mesmo numero Temp4_
ZTCBGEREN_NEGATI -OPBEL e com campo DFKKOP - BLART = FA ou FM ou F1 ou FP. Excluir aqueles
com DFKKOP-HVORG iguais aos HVORG’s presentes na tabela Operadoras LD campo Operação
Principal da EF PG.013 Extractor de pagamento de Co-billing(Exclusão de itens de operadoras LD) e
aqueles com HVORG e TVORG iguais ao HVORG e TVORG com ID_Processo = 02 da tabela
ZTCB_ITEM_PROCESSO descrita na EF CB.011.1 Tratamento de recarga programada e conta
fixa_interface_RP. (Exclusão de itens de fatura de recarga programada)
6.1.3 Para todos itens do documento identificados no paso 6.1.2 o sistema deverá checar o valor do
item no campo Montante TEMP_DFKKOP-BETRW (Montante na moeda de transação com sinal +/-) e
totalizar o valor deles numa variavel temporaria no sistema. (Montante em divida para TIM e LD41
nesse momento).
6.2 Verificação de valor em aberto dentro do valor minimo permitido para entrar no nivel de negativação.

575039736.doc
Checar se o valor total dos itens em aberto para o documento Temp4_ ZTCBGEREN_NEGATI -OPBEL
selecionado no punto 6.1.1 e maior ou igual que o valor minimo configurado para o nivel de negativação
nas reguas de cobrança (MINBT (Montante limite))
Se valor total (calculado no passo 6.1.3) dos itens em aberto (só TIM e LD 41) para o documento Temp4_
ZTCBGEREN_NEGATI -OPBEL em analise é maior que o valor no campo Temp4_ ZTCBGEREN_NEGATI – MINBT
(valor minimo na regua de cobrança).
6.3 Verificação de faturas/clientes em No-dunning
6.3.1 No-Dunning Nível do Fatura:

Para as faturas presentes na tabela Temp4_ ZTCBGEREN_NEGATI identificar na Tabela
TEMP_DFKKLOCKS(Bloqueios comerciais) se existe algum motivo de no-dunning ativo para a fatura
selecionada.
Entrar na tabela TEMP_DFKKLOCKS com o numero de Temp4_ ZTCBGEREN_NEGATI -OPBEL=

TEMP_DFKKLOCKS-LOOBJ1(12) com TEMP_DFKKLOCKS-PROID= ‘01’(Isenção de advertencia) e
TEMP_DFKKLOCKS-LOTYP=‘02’ (nivel de item de documento).

por algum motivo ainda ativo). Caso seja encontrado algum registro na tabela TEMP_DFKKLOCKS que
cumpra a condição descrita acima ativar flag ZTCBGEREN_NEGATI- ZZ_DUNNING_FAT. Para o OPBEL em
analise.
Caso contrario preencher o campo ZZ_DUNNING_LIB com ‘X’ para a fatura em analise.
6.3.2 No-Dunning Nível da cliente:

Entrar na tabela TEMP_DFKKLOCKS com Temp4_ ZTCBGEREN_NEGATI -GPART=TEMP_DFKKLOCKS-
LOOBJ1(12) e com TEMP_DFKKLOCKS-PROID= ‘01’ (Isenção de advertencia) e TEMP_DFKKLOCKS-LOTYP=‘06’
(nivel de conta contrato).

por algum motivo ainda ativo). Caso seja encontrado algum registro na tabela TEMP_DFKKLOCKS que
cumpra a condição descrita acima ativar flag ZTCBGEREN_NEGATI- ZZ_DUNNING_CONTR.
Caso contrario preencher o campo ZZ_DUNNING_LIB com ‘X’ para a fatura em analise.
Deletar o registro existente na tabela ZTCBGEREN_NEGATI para o OPBEL em analise.

Atualizar o registro deletado na tabela de historico ZTCBHIS_NEGATI.
Atualizar a tabela ZTCBGEREN_NEGATI com os:
 ZTCBGEREN_NEGATI-LAUFD= Temp4_ ZTCBGEREN_NEGATI -LAUFD

 ZTCBGEREN_NEGATI-LAUFI= Temp4_ ZTCBGEREN_NEGATI -LAUFI
 ZTCBGEREN_NEGATI -GPART = Temp4_ ZTCBGEREN_NEGATI -GPART;
 ZTCBGEREN_NEGATI -OPBEL = Temp4_ ZTCBGEREN_NEGATI -OPBEL;
 ZTCBGEREN_NEGATI - ZZDT_SELECAO = Temp4_ ZTCBGEREN_NEGATI -MDRKD.
 ZTCBGEREN_NEGATI - MSTYP = Temp4_ ZTCBGEREN_NEGATI -MSTYP
 ZTCBGEREN_NEGATI - VKONT = Temp4_ ZTCBGEREN_NEGATI -VKONT
 ZTCBGEREN_NEGATI – MINBT= Temp4_ ZTCBGEREN_NEGATI – MINBT.
 ZTCBGEREN_NEGATI – VTRE2 = Temp4_ ZTCBGEREN_NEGATI -VTRE2.

575039736.doc
Caso o valor em aberto da fatura não seja maior ou igual que o minimo de cobrança Temp4_
ZTCBGEREN_NEGATI – MINBT continuar no passo 7.
7. Identificação de faturas parceladas retiradas da negativação com posterior quebra de acordo.

Programa para verificação de faturas positivadas por motivo de parcelamento ativo, com posterior quebra do
acordo.
Na tabela ZTCBGEREN_NEGATI selecionar as faturas (OPBEL) com campos A Excluir= ‘X’ , campo data da
Confirmação da exclusão > = SY-DATUM – ZTCB_QUANTREV-DIAS (Por exemplo 90 días) (para o
ZTCBQUANTREV-ID do processo = ‘1’), e campo ZZPAR_ENTRADA_PG= ‘X’. Carregar na tabela temporaria
Temp5_ ZTCBGEREN_NEGATI.
7.1 Identificação de faturas excluidas da negativação com posterior quebra de acordo.

Checar entre as faturas da Tabela Temp5_ZTCBGEREN_NEGATI parceladas com entrada paga se houve quebra
de acordo.
Verificar na tabela TEMP_DFKKOP se para o OPBEL em analise (Temp5_ZTCBGEREN_NEGATI –OPBEL) o campo

Temp5_DFKKOP-ABWBL esta preenchido. Caso esteja preenchido desconsiderar a fatura do analise e continuar
com a proxima Temp5_ZTCBGEREN_NEGATI-OPBEL. Caso não esteja preenchido o ABWBL marcar o campo
ZTCBGEREN_NEGATI-ZZPAR_COM_QUEBRA com ‘X’
Deletar o registro existente na tabela ZTCBGEREN_NEGATI para o OPBEL em analise.

Atualizar o registro deletado na tabela de historico ZTCBHIS_NAGATI.
E Atualizar a tabela ZTCBGEREN_NEGATI com os:
 ZTCBGEREN_NEGATI-LAUFD = Temp5_ ZTCBGEREN_NEGATI -LAUFD

 ZTCBGEREN_NEGATI-LAUFI = Temp5_ ZTCBGEREN_NEGATI -LAUFI
 ZTCBGEREN_NEGATI -GPART = Temp5_ ZTCBGEREN_NEGATI -GPART;
 ZTCBGEREN_NEGATI -OPBEL = Temp5_ ZTCBGEREN_NEGATI -OPBEL;
 ZTCBGEREN_NEGATI - ZZDT_SELECAO = Temp5_ ZTCBGEREN_NEGATI -MDRKD.
 ZTCBGEREN_NEGATI - MSTYP = Temp5_ ZTCBGEREN_NEGATI -MSTYP
 ZTCBGEREN_NEGATI - VKONT = Temp5_ ZTCBGEREN_NEGATI -VKONT
 ZTCBGEREN_NEGATI – MINBT= Temp5_ ZTCBGEREN_NEGATI – MINBT.
 ZTCBGEREN_NEGATI – VTRE2 = Temp5_ ZTCBGEREN_NEGATI -VTRE2.
3.10. Programa 2: Geração de arquivos para envio aos Bureaus de credito
3.10.1 - Premissas
Apos finalizado o programa 1, este programa devera gerar os diferentes arquivos com as informações contidas na
tabela ZTCBGEREN_NEGATI_TEMP_ARQ, baseado na logica seguinte:

575039736.doc
 Para registros presentes na tabela ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP=’ZB’ devera seguir o layout de

arquivo detalhado abaixo para o Bureau de credito SERASA. (Criando arquivos separados para cada
contrato da TIM com SERASA.)
 Para registros presentes na tabela ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP=’ZC’ devera seguir o layout de
arquivo detalhado abaixo para o Bureau de credito SPC. (Criando arquivos separados para cada contrato da
TIM com o SPC)
 Para registros presentes na tabela ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP=’ZM’ devera seguir o layout de
arquivo detalhado abaixo para o Bureau de credito EQUIFAX. (Criando arquivos separados para cada
contrato da TIM com o EQUIFAX)
 Apos a geração de todos os arquivos a tabela ZTCBGEREN_NEGATI_TEMP_ARQ devera ser limpada.
16 - Especificação dos campos dos arquivos para os Bureaus de credito
A informação a ser preenchida nos arquivos dos Bureaus de credito devera estar em letras maiusculas, sem
acentos e caracteres especiais.
16.1 Arquivo de saída para envio de faturas/clientes negativados para o SPC (detalhamento dos campos do
layout):
Para as faturas presentes na tabela ZTCBGEREN_NEGATI_TEMP_ARQ para serem enviadas ao SPC

(negativação ou positivação) ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP=’ZC’ o programa devera gerar
arquivos separados pelos diferentes codigos de contrato ZTCBGEREN_NEGATI_TEMP_ARQ -
ZZCOD_CONTRATO conforme layout descrito abaixo.
Nomenclatura do arquivo de saída proposto:
SPCSSSSSSE
Onde:
SSSSSS é o número sequencial do arquivo. (Dado armazenado na tabela de Tabela sequencial arquivos
no campo sequencial para o MSTYP=’ZC’ , tabela descrita na seção 3.7 novos objetos). O caracter “E”
é referente a arquivo de envio. Para os casos de arquivos gerados com sucesso incrementar em uma
unidade o campo ‘Sequencial’ na Tabela sequencial arquivos para o MSTYP=’ZC’.
Os arquivos gerados deverão ser jogados num diretorio UNIX especifico para negativação
Disponibilizar o arquivo gerado no diretório de saída do servidor do RMCA (.../SPC). Diariamente se verificará
se foi criado algum novo arquivo nesse diretório, se fará a transferência do arquivo ao diretório destino do
sistema SPC, e se mudará o nome do arquivo para .old, movendo para um diretório de backup.
(.../SPC/OUTPUT): Somente os arquivos a serem enviados para o SPC.
(.../SPC /BACKUP) : Somente os arquivos enviados com sucesso ao SPC.
(.../SPC /INPUT) : Somente os arquivos retornados com sucesso do SPC.

575039736.doc
(.../SPC /PROCESSED) : Somente os arquivos retornados do SPC e processados com sucesso.

(.../SPC /ERROR) : Somente os arquivos que ocorreram erros na validação (formato, layout, seqüencial)
retornados do SPC.
(.../SPC/LOG) : Somente os arquivos de logs gerados pelo processo.
A informação dos arquivos criados com sucesso e jogados no diretorio (.../SPC/OUTPUT) deverá ser atualizada
na tabela controle de arquivos processados (ZTCB_ARQ_PROCES). Campo NOMARQ = SPCSSSSSSE gerado, campo
RETOK=Blank, campo data de envio=SY-DATUM, campo data de processamento=blank, campo sequencial
devera ser preenchido com o sequencial do arquivo gerado SSSSSS e campo ZZCONTRATO com a informação
encontrada na tabela ZTCBGEREN_NEGATI_TEMP_ARQ- ZZCOD_CONTRATO
Layout de Arquivo:
Condições gerais:
1.1. Header
1.1.1. No campo 1.1.1 “Associado” o programa deverá gravar o valor do campo Codigo de contrato
ZZCOD_CONTRATO da Tabela ZTCBGEREN_NEGATI_TEMP_ARQ, que representa o código do contrato
identificador da TIM no SPC
1.1.2. No campo 1.1.2 “Constante” o programa deverá gravar o valor fixo ‘0000000000’.
1.1.3. No campo 1.1.3 “Data do Movimento” o programa deverá gravar a data de envio do arquivo
para o SPC (data corrente do sistema SY-DATUM). ( ddmmaa)
1.1.4. No campo 1.1.4 “Constante” o programa deverá gravar o valor fixo ‘REMESSA’.
1.1.5. No campo 1.1.5 “Informante” o programa deverá gravar o nome do informante armazenado na
tabela Controle arquivos SPC no campo Nome do informante.
1.1.6. No campo 1.1.6 o programa deverá gerar o número da remessa do arquivo sequencial,
incrementando de 1 a cada novo movimento. (Sequencial do arquivo obtido da tabela
ZTCB_CONTROLE para o ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP= ‘ZC’ e
ZTCBGEREN_NEGATI_TEMP_ARQ-ZZCOD_CONTRATO=Codigo do contrato da operadora no SPC). O
sequencial deve ser alinhado à direita e preenchidos com zeros à esquerda.
1.1.7. No campo 1.1.7 “Constante” o programa deverá gravar 8 espaços em branco.
1.1.8. No campo 1.1.8 “Versão” o programa deverá gravar o valor fixo ‘03’.
1.2. Detalhe - NOME
1.2.3. No campo 1.2.3 “Sequência” o programa deverá gerar um número sequencial do registro. Os
registros intermediários deverão vir em ordem crescente por número de sequência a partir do
nº 1.
1.2.4. No campo 1.2.4 “Sistema” o programa deverá gravar o valor fixo ‘1’, que corresponde ao
código do sistema para SPC.
1.2.5. No campo 1.2.5 “Constante” o programa deverá gerar um valor fixo ‘A’.
1.2.6. No campo 1.2.6 “Constante” o programa deverá gerar um valor fixo ‘10’.
1.2.7. No campo 1.2.7 “Documento” o programa deverá trazer da tabela
ZTCBGEREN_NEGATI_TEMP_ARQ o campo ‘ZZTAXNUM’, referente ao CPF/CNPJ.
e para os casos de clientes identificados como pessoas fisicas ZTCBGEREN_NEGATI_TEMP_ARQ-
ZZTIPOCLI= ‘BR2’ devera preencher:
‘CPF’ + nº do CPF do cliente(TAXNUM) + brancos a direita.
Para os clientes identificados como pessoas juridicas ZTCBGEREN_NEGATI_TEMP_ARQ-ZZTIPOCLI=
‘BR1’ devera preencher:
‘CNPJ’+ nº do CNPJ(TAXNUM) do cliente+brancos direita.
1.2.8. No campo 1.2.8 “Documento” o programa deverá gravar 20 espaços em branco.
1.2.9. No campo 1.2.9 “Documento” o programa deverá gravar 20 espaços em branco.

575039736.doc
1.2.10. No campo 1.2.10 “Nome” o programa deverá pegar o campo ZZNOME do registro na tabela
ZTCBGEREN_NEGATI_TEMP_ARQ , que representa o nome do devedor (cliente).
1.2.12. No campo 1.2.12 “Data” preencher 00000000.
1.2.13. No campo 1.2.13 “Nome” o programa deverá gravar 40 espaços em branco.
1.2.15. No campo 1.2.15 “Constante” o programa deverá gravar um valor fixo ‘000000’.
1.2.16. No campo 1.2.16 “Naturalidade” o programa deverá gravar 20 espaços em branco.
1.2.17. No campo 1.2.17 “Unidade da Federação” o programa deverá gravar 2 espaços em branco.
1.2.19. No campo 1.2.19 “Código” o programa deverá gravar 20 espaços em branco.
Endereço
1.2.20. No campo 1.2.20 “Associado” o programa deverá gravar o valor do campo ZZCOD_CONTRATO
da Tabela ZTCBGEREN_NEGATI_TEMP_ARQ , que representa o código do contrato identificador da TIM
no SPC.
1.2.22. No campo 1.2.22 “Sequência” o programa deverá gerar um número sequencial do registro.
Preencher com mesmo numero do campo 1.2.3
1.2.23. No campo 1.2.23 “Sistema” o programa deverá gravar o código do sistema ‘1’, que
corresponde ao código do sistema para SPC.
1.2.24. No campo 1.2.24 “Constante” o programa deverá gravar um valor fixo ‘B’.
1.2.26. No campo 1.2.26 preencher com mesmo dado do campo 1.2.7 (CPF/CNPJ)
1.2.27. No campo 1.2.27 “Tipo de Registro” o programa deverá gravar um valor fixo ‘1’,
correspondente ao endereço do cliente devedor.
1.2.28. No campo 1.2.28 “Endereço” o dado no campo ZZENDE da tabela
ZTCBGEREN_NEGATI_TEMP_ARQ, que informa o tipo, nome do logradouro, número e complemento do
endereço do cliente devedor.
1.2.29. No campo 1.2.29 “Bairro” o programa deverá buscar no campo ZZBAIRRO da tabela
ZTCBGEREN_NEGATI_TEMP_ARQ
1.2.30. No campo 1.2.30 “CEP” o programa deverá buscar no campo ZZCEP da tabela
1.2.31. No campo 1.2.31 “Cidade” o programa deverá buscar no campo ZZCidade da tabela
1.2.32. No campo 1.2.32 “UF” o programa deverá buscar no campo ZZUF da tabela
1.2.33. No campo 1.2.33 “Telefone” o programa deverá gravar 20 espaços em branco.
Ocorrência do SPC
1.2.36. No campo 1.2.36 “Associado” o programa deverá gravar o valor do campo ZZCOD_CONTRATO
da Tabela ZTCBGEREN_NEGATI_TEMP_ARQ , que representa o código do contrato identificador
da TIM no SPC
1.2.38. No campo 1.2.38 “Sequencia” o programa deverá gravar o número sequencial do
registro(Preencher com mesmo numero do campo 1.2.3 .)
1.2.41. No campo 1.2.41 “Operação” o programa deverá gravar o código de operação, onde ‘10’ – Inclusão
e ‘20’ – Exclusão. Dependerá de se o campo ZTCBGEREN_NEGATI_TEMP_ARQ -
ZZ_A_INCLUIR=’X’ ou o campo ZTCBGEREN_NEGATI_TEMP_ARQ -ZZ_A_EXCLUIR=’X’

575039736.doc
1.2.42. No campo 1.2.42 preencher com mesmo preenchido no campo 1.2.7 (CPF/CNPJ).
1.2.43. No campo 1.2.43 “Data” o programa deverá buscar o campo ZZDAT_VENC da tabela
ZTCBGEREN_NEGATI_TEMP_ARQ, que indica a data de vencimento da fatura.
1.2.44. No campo 1.2.44 “Ocorrência” o programa deverá preencher fixo = ‘RG’.
1.2.45. No campo 1.2.45 “Contrato” o programa deverá buscar o campo Ref.(fatura) VTRE2 da tabela
de ZTCBGEREN_NEGATI_TEMP_ARQ. Este é o numero da fatura (VTRE2) que vamos mandar para
negativação. Todas as informações enviadas são correspondentes a essa fatura.
1.2.46. No campo 1.2.46 “Avalista” o programa deverá gravar 20 espaços em branco.
1.2.47. No campo 1.2.47 “Valor” o programa deverá gravar o montante correspondente ao campo
ZZVLR_FAT da tabela ZTCBGEREN_NEGATI_TEMP_ARQ.
1.2.48. No campo 1.2.48 “Documento de Débito” o programa deverá gravar o valor fixo ‘CT’, que
corresponde a Contrato.
1.2.49. No campo 1.2.49 “Reservado” o programa deverá gravar 17 espaços em branco.
1.2.50. No campo 1.2.50 “Constante” o programa deverá gravar o valor fixo ‘N’.
1.2.52. No campo 1.2.52“Constante” o programa deverá gravar 92 espaços em branco.
1.2.53. No campo 1.2.53 “Reservado” o programa deverá concatenar o valor dos campos CUSTOMER_ID
e ZZFEBRABAN da tabela ZTCBGEREN_NEGATI_TEMP_ARQ, considerando 8 posições para o
CUSTOMER_ID, alinhado à direita e completado com zeros a esquerda, e 4 posições para
ZZFEBRABAN, alinhado à esquerda. Completar os 3 caracteres restantes à direita com espaços em
branco.
1.3. Trailler
1.3.3. No campo 1.3.3 “Data do Movimento” o programa deverá gravar a data de envio do arquivo
para o SCPC (data corrente do sistema SY-DATUM). ( ddmmaa)
Para cada fatura preenchida no arquivo se devera atualizar a tabela ZTCBGEREN_NEGATI o campo NOMARQ o nome
do arquivo em que a fatura foi incluida, o campo ZZDT_ENVIO_INCL=SY-DATUM (Se
ZTCBGEREN_NEGATI_TEMP_ARQ- ZZ_A_INCLUIR=’X’) ou o campo ZZDT_ENVIO_EXCL=SY-DATUM (Se
ZTCBGEREN_NEGATI_TEMP_ARQ- ZZ_A_EXCLUIR=’X’) e o campo ZZNOVAFAT devera ser limpado caso esteja
preenchido.
No final da geração do arquivo na tabela ZTCB_ARQ_PROCES arquivos processados o campo QUANTREG devera ser
atualizado com a quantidade de registros (de faturas) incorporadas na seção detalhe do arquivo.
16.2 Arquivo de saída para envio de faturas negativadas para o SERASA (detalhamento dos campos do layout):
16.2.1 Identificação de faturas a negativar por operadora.
Para as faturas presentes na tabela ZTCBGEREN_NEGATI_TEMP_ARQ para serem enviadas ao SERASA (negativação
ou positivação) ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP=’ZB’ o programa devera gerar arquivos separados pelos
diferentes codigos de contrato ZTCBGEREN_NEGATI_TEMP_ARQ - ZZCOD_CONTRATO com a seguinte nomenclatura
e Layout:
Nomenclatura do arquivo de saída
NDM.NDXXXXX.PEFIN.DDMMYYYYHHMISS.SSSSSS
Onde:
XXXXX é o código do contrato da operadora no SERASA.

575039736.doc
DDMMYYYYHHMISS é a data e hora de geração do arquivo

SSSSSS é o número sequencial do arquivo. (Deverá continuar o sequencial migrado do BSCS) . (Dado armazenado
na tabela de Tabela sequencial arquivos ZTCB_CONTROLE no campo sequencial para o MSTYP=’ZB’ e para cada
Codigo de contrato ZZCOD_CONTRATO. Para os casos de arquivos gerados com sucesso incrementar em uma
unidade o campo ZZSEQUENCIAL.
Os arquivos gerados deverão ser jogados num diretorio UNIX especifico para negativação.
Disponibilizar o arquivo gerado no diretório de saída do servidor do RMCA (.../SERASA). Diariamente se
verificará se foi criado algum novo arquivo nesse diretório, se fará a transferência do arquivo ao diretório
destino do SERASA, e se mudará o nome do arquivo para .old, movendo para um diretório de backup.
(.../SERASA/OUTPUT): Somente os arquivos a serem enviados para o SERASA.
(.../SERASA /BACKUP) : Somente os arquivos enviados com sucesso ao SERASA.
(.../SERASA /INPUT) : Somente os arquivos retornados com sucesso do SERASA.
(.../SERASA/PROCESSED) : Somente os arquivos retornados do SERASA e processados com sucesso.
(.../SERASA /ERROR) : Somente os arquivos que ocorreram erros na validação (formato, layout, seqüencial)
retornados do SERASA.
(.../SERASA /LOG) : Somente os arquivos de logs gerados pelo processo
A informação dos arquivos criados com sucesso e jogados no diretorio (.../SERASA/OUTPUT) deverá ser
atualizada na tabela Tabela controle arquivos processados ZTCB_ARQ_PROCES. Campo
ZZNOME_NOMARQ = NDM.NDXXXXX.PEFIN.DDMMYYYYHHMISS.SSSSSS gerado, campo data de envio=SY-
DATUM, campo RETOK=Blank, campo data de processamento=blank e campo sequencial devera ser
preenchido com o sequencial do arquivo gerado SSSSSS.
Layout do arquivo:
2.2 Header
2.1.1 No campo 2.1.1 o programa deverá gravar o valor fixo ‘0’ (zero), referente ao código de registro.
2.1.2 No campo 2.1.2 o programa deverá gravar o CNPJ da institução informante, para isso devera
procurar o dado na tabela ZTCBGEREN_NEGATI_TEMP_ARQ no campo CNPJ RAIZ do contrato
ZZCNPJRAIZ_CTO.
2.1.3 No campo 2.1.3 o programa deverá gravar a data de envio do arquivo para o SERASA (data
corrente gerada do sistema). AAAAMMDD
2.1.4 No campo 2.1.4 o programa deverá buscar da tabela “Instituição informante” ZTCBDADOS_INSTIT o
campo ‘DDD’, referente ao DDD do tel. de contato da instituição informante (TIM) para o codigo
de contrato para o Bureau do arquivo que esta semdo gerado.(Campos
ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP e codigo de contrato ZTCBGEREN_NEGATI_TEMP_ARQ-
ZZCOD_CONTRATO na Tabela de cadastro de dados da instituição informante descrita na EF
CB.028.1)
2.1.5 No campo 2.1.5 o programa deverá buscar da tabela “Instituição informante” (custom - Criado na
EF CB.028.1 – Transações customizadas para configuração de critérios de negativação) o campo
‘telefone’, referente ao telefone de contato da instituição informante (TIM) para o codigo de
contrato do arquivo que esta semdo gerado.(campo codigo de contrato e MSTYP na Tabela de
cadastro de dados da instituição informante descrita na EF CB.028.1
2.1.6 No campo 2.1.6 o programa deverá buscar da tabela “Instiuição informante” (custom - Criado na
‘ramal’, referente ao ramal de contato da instituição informante (TIM) para o codigo de contrato
do arquivo que esta semdo gerado.(campo codigo de contrato e MSTYP na Tabela de cadastro de
dados da instituição informante descrita na EF CB.028.1
2.1.7 No campo 2.1.7 o programa deverá buscar da tabela “Instituição informante” (custom - Criado na
‘Nome_contato’, referente ao nome da pessoa responsável pelo contato com a instituição

575039736.doc
informante (TIM) para o codigo de contrato do arquivo que esta semdo gerado.(campo codigo de
contrato e MSTYP na Tabela de cadastro de dados da instituição informante descrita na EF
CB.028.1
OBS: A tabela “Instituição informante” será criada para armazenar os dados da instituição informante
(TIM) na EF CB.028.1 – Transações customizadas para configuração de critérios de negativação.
2.1.8 No campo 2.1.8 o programa deverá gravar o conteudo do campo ZZCOD_CONVENIO( Ex:SERASA-
CONVEM 04) da tabela ZTCB_CONTROLE para o ZTCBGEREN_NEGATI_TEMP_ARQ -MSTYP=’ZB’ para o
ZTCBGEREN_NEGATI_TEMP_ARQ -ZZCOD_CONTRATO do arquivo sendo gerado.
2.1.9 No campo 2.1.9 o programa deverá gerar o número da remessa do arquivo sequencial,
incrementando de 1 a cada novo movimento. (Sequencial do arquivo obtido da tabela
ZTCB_CONTROLE para o ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP= ‘ZB’ e
ZTCBGEREN_NEGATI_TEMP_ARQ-ZZCOD_CONTRATO=Codigo do contrato da operadora no Serasa,
campo sequencial)
2.1.10 No campo 2.1.10 o programa deverá gravar o valor referente ao código de envio do arquivo, sendo
“E” = ENTRADA.
2.1.11 No campo 2.1.11 o programa deverá gravar ‘0001’.
2.1.12 No campo 2.1.12 o programa deverá gravar 403 espaços em branco.
2.1.14 No campo 2.1.14 o programa deverá gravar ‘0000001’
2.2 Detalhe
2.2.1 No campo 2.2.1 o programa deverá gravar o valor código de registro fixo ‘1’.
2.2.2 No campo 2.2.2 o programa deverá gravar o código de operação, onde I – Inclusão e E – Exclusão.
Dependerá de se o campo ZTCBGEREN_NEGATI_TEMP_ARQ -ZZ_A_INCLUIR=’X’ ou o campo
ZTCBGEREN_NEGATI_TEMP_ARQ -ZZ_A_EXCLUIR=’X’.
2.2.3 No campo 2.2.3 o programa deverá preencher o ZTCBGEREN_NEGATI_TEMP_ARQ-ZZFILIAL.
2.2.4 No campo 2.2.4 o programa deverá preencher o ZTCBGEREN_NEGATI_TEMP_ARQ- ZZDAT_VENC.

(Data de vencimento da fatura).
2.2.5 No campo 2.2.5 o programa deverá repetir a data da ocorrência 2.2.4
2.2.6 No campo 2.2.6 o programa deverá gravar o valor fixo ‘0O’, referente ao código de natureza da
operação.
2.2.7 No campo 2.2.7 o programa deverá gravar 4 espaços em branco, referente ao código praça
Embratel.
2.2.8 No campo 2.2.8 o programa deverá gravar o Tipo de pessoa do principal, onde F – Fisica e J –
Juridica. Caso o campo ZTCBGEREN_NEGATI_TEMP_ARQ-ZZTIPOCLI=’BR1’ preencher com ‘J’, caso
esteja preenchido com “BR2” deverá gravar no campo 2.2.8 o valor ‘F’.
2.2.9 No campo 2.2.9 o programa deverá gravar o Tipo do doc. do principal, onde 1 – CNPJ e 2 – CPF.
ZTCBGEREN_NEGATI_TEMP_ARQ-ZZTIPOCLI =’BR1’ o campo 2.2.9 deverá ser gravado com 1. Caso
ZTCBGEREN_NEGATI_TEMP_ARQ-ZZTIPOCLI = ‘BR2’ o campo devera ser gravado com o valor 2.
2.2.10 No campo 2.2.10 programa deverá gravar o Primeiro documento do principal, composto da
seguinte maneira: CPF completo = base + dígito ou CNPJ completo = base + filial + dígito.
Para isso o programa deverá ir na tabela Z_Gerenciamento de negativaçao e selecionar o campo
ZTCBGEREN_NEGATI_TEMP_ARQ-TAXNUM.
2.2.11 No campo 2.2.11 o programa deverá gravar 2 espaços em branco para os casos de inclusão. Para os
casos de exclusão devera preencher com campo ZTCBGEREN_NEGATI_TEMP_ARQ- ZZMOTIVO_EXCL.
2.2.12 No campo 2.2.12 o programa deverá gravar 1 espaço em branco, correspondente ao tipo do
segundo documento do cliente.
2.2.13 No campo 2.2.13 o programa deverá gravar 15 espaços em branco, correspondentes ao valor do RG
do cliente.
2.2.14 No campo 2.2.14 o programa deverá gravar 2 espaços em branco, referente a UF da identidade do
cliente.
2.2.15 No campo 2.2.15 o programa deverá gravar 1 espaço em branco.

575039736.doc

2.2.22 No campo 2.2.22 o programa deverá buscar o campo ZTCBGEREN_NEGATI_TEMP_ARQ- ZZNOME
2.2.26 No campo 2.2.26 o programa deverá buscar os seguintes campos da
ZTCBGEREN_NEGATI_TEMP_ARQ- ZZENDE.
2.2.27 No campo 2.2.27 o programa deverá gravar o campo ZTCBGEREN_NEGATI_TEMP_ARQ- ZZBAIRRO.
2.2.28 No campo 2.2.28 o programa gravar o campo ZTCBGEREN_NEGATI_TEMP_ARQ-ZZCIDADE , referente
ao Cidade do cliente.
2.2.29 No campo 2.2.29 o programa deverá gravar o campo ZTCBGEREN_NEGATI_TEMP_ARQ-UF,
referente a UF do cliente.
2.2.30 No campo 2.2.30 o programa deverá gravar o campo na tabela ZTCBGEREN_NEGATI_TEMP_ARQ-
ZZCEP, referente ao CEP do cliente.
2.2.31 No campo 2.2.31 o programa deverá gravar o valor do débito (dívida) correspondente ao campo
ZTCBGEREN_NEGATI_TEMP_ARQ- ZZVLR_FAT.
2.2.32 No campo 2.2.32 o programa deverá buscar o campo ‘Numero de fatura’
ZTCBGEREN_NEGATI_TEMP_ARQ-VTRE2 e o campo ‘Id do centro de custo’
ZTCBGEREN_NEGATI_TEMP_ARQ- ZZIDCTROCUSTO. Devera preencher o campo 2.2.32 do jeito
seguinte:
GSM + ID do centro de custo + Numero da fatura (número da fatura com 10 posições, completando
com zeros a esquerda)
2.2.34 No campo 2.2.34 o programa deverá gravar o endereço restante do campo 2.2.26, referentes ao
complemento do endereço do devedor ou com 25 espaços em branco
2.2.35 No campo 2.2.35 o programa deverá gravar 4 espaços em branco, referentes ao DDD+Número do
telefone do devedor (cliente).
2.2.37 No campo 2.2.37 o programa deverá 8 espaços em branco.
2.2.40 No campo 2.2.40 o programa deverá gravar 60 espaços em branco
2.2.41 No campo 2.2.41 o programa deverá gerar um número sequencial do arquivo de registro. O
primero registro de detalhe devera ser preenchido com valor ‘2’ sendo incrementado em uma
unidade a cada novo registro gerado. O valor deve ser completado com zeros a esquerda.
2.3 Trailler
2.3.1 No campo 2.3.1 o programa deverá gravar o valor fixo ‘9’, referente ao código registro.
2.3.4 No campo 2.3.4 o programa deverá gerar um número sequencial do arquivo de registro. Devera ser
preenchido com o numero do ultimo registro gerado no detalhe mais um. (Completar com ceros a
izquerda)
preenchido.
No final da geração do arquivo na tabela ZTCB_ARQ_PROCES arquivos processados o campo QUANTREG devera ser
atualizado com a quantidade de registros (de faturas) incorporadas na seção detalhe do arquivo.

575039736.doc
16.3 Arquivo de saída para envio de faturas/clientes negativados para o EQUIFAX (detalhamento dos campos
do layout):
Para as faturas presentes na tabela ZTCBGEREN_NEGATI_TEMP_ARQ para serem enviadas ao EQUIFAX

(negativação ou positivação) ZTCBGEREN_NEGATI_TEMP_ARQ-MSTYP=’ZM’ o programa devera gerar um arquivo
com a seguinte nomenclatura e Layout:
Nomenclatura do arquivo de saída proposto:
EQUIFAX.DDMMYYYYHHMISS.SSSSSS.TXT
Onde:
DDMMYYYYHHMISS é a data e hora de geração do arquivo
SSSSSS é o número sequencial do arquivo. (Dado armazenado na tabela de Tabela sequencial arquivos no
campo sequencial para o MSTYP=’ZM’ , tabela descrita na seção 3.7 novos objetos). Para os casos de arquivos
gerados com sucesso incrementar em uma unidade o campo ‘Sequencial’ na Tabela sequencial arquivos para o
MSTYP=’ZM’.
Os arquivos gerados deverão ser jogados num diretorio UNIX especifico para negativação.
Disponibilizar o arquivo gerado no diretório de saída do servidor do RMCA (.../EQUIFAX). Diariamente se
verificará se foi criado algum novo arquivo nesse diretório, se fará a transferência do arquivo ao diretório
destino do sistema EQUIFAX, e se mudará o nome do arquivo para .old, movendo para um diretório de
backup.
(.../EQUIFAX /OUTPUT): Somente os arquivos a serem enviados para o SPC.
(.../EQUIFAX /BACKUP) : Somente os arquivos enviados com sucesso ao SPC.
(.../EQUIFAX /INPUT) : Somente os arquivos retornados com sucesso do SPC.
(.../EQUIFAX /PROCESSED) : Somente os arquivos retornados do SPC e processados com sucesso.
(.../EQUIFAX /ERROR) : Somente os arquivos que ocorreram erros na validação (formato, layout, seqüencial)
retornados do SPC.
(.../EQUIFAX /LOG) : Somente os arquivos de logs gerados pelo processo.
A informação dos arquivos criados com sucesso e jogados no diretorio (.../EQUIFAX/OUTPUT) deverá ser
atualizada na tabela Tabela controle arquivos processados. Campo NOMARQ =
EQUIFAX.DDMMYYYYHHMISS.SSSSSS gerado, campo data de envio=SY-DATUM, campo RETOK=Blank, campo
data de processamento=blank e campo sequencial devera ser preenchido com o sequencial do arquivo gerado
SSSSSS.
Layout do arquivo:
O layout do arquivo para EQUIFAX é o mesmo layout descrito para SPC no passo 4.1 da logica do programa. O
conteudo do arquivo podera ser diferente do conteudo do arquivo de SPC.
preenchido.

575039736.doc
No final da geração do arquivo na tabela ZTCB_ARQ_PROCES arquivos processados o campo QUANTREG devera
ser atualizado com a quantidade de registros (de faturas) incorporadas na seção detalhe do arquivo.
17. O programa deverá atualizar a tabela ZTUT_DATAPROC-DATUM com SY-DATUM no final do processamento com
sucesso para o ZTUT_DATAPROC-REPID= “Negativação”.
3.11. Programa 3: Programa para Recebimento do retorno
3.11.1 - Premissas
Este programa já existe e não precisa ser alterado por motivo do paralelismo. (Modificações a serem executadas
resaltadas em amarelo abaixo nos items 5.2.1 e 5.3.1)
3.11.2 – Detalhamento do processo
5.1. Após X horas do envio de cada arquivo (depende da configuração do job que deverá ser criado para iniciar
este programa), o programa deve verificar no diretório de retorno de cada um dos CB’s se existe arquivo
de retorno (a verificação deve ser feita através da nomenclatura de cada arquivo.)
5.2. Verificar o conteudo do diretorio(.../SPC/INPUT). Caso não existam arquivos a serem processados ir no
passo 5.2.4. Se existir arquivo:
Para os arquivos de retorno do SPC pendentes de processamento no diretório (.../SPC/INPUT), verificar se

existem registros correspondentes na tabela “controle arquivos processados” (ZTCB_ARQ_PROCES), através do
campo NOMARQ igual ao nome do arquivo no diretório, desconsiderando a décima posição (última) (Pois esta
será igual a “E” no arquivo de envio e igual a “R” no arquivo de retorno). E através do campo ‘ZZCONTRATO’
igual ao número do contrato, encontrado no header do arquivo de retorno (Campo 1.1.1 do layout do arquivo
de retorno).
EXPLO mascara do arquivo:
 Arquivo enviado : SPCSSSSSSE (onde, SSSSSS = sequencial e “E” = constante (envio))
 Arquivo de retorno : SPCSSSSSSR (onde, SSSSSS = sequencial e “R” = constante (retorno))
Caso o arquivo encontrado no diretorio .../SPC/INPUT tenha nomenclatura diferente do padrão “SPCSSSSSSR”,
onde somente “SSSSSS” pode ser variável, gravar na tabela “Arquivos Rejeitados” com o motivo de
“Nomenclatura do arquivo SPC não é de retorno” e transferir o arquivo para um diretório de arquivos
rejeitados. (.../SPC/ERROR).
Caso o arquivo encontrado no diretorio .../SPC/INPUT não exista na tabela de “controle arquivos
processados” descrita na seção 3.7 novos objetos, gravar na tabela “Arquivos Rejeitados” com o motivo de
“arquivo não enviado ao SPC” e transferir o arquivo para um diretório de arquivos rejeitados. (.../SPC/ERROR)
5.2.1. Para cada arquivo de retorno existente no diretorio (.../SPC/INPUT) e na tabela “controle arquivos
processados” com campo RETOK= ‘blank’ o programa deverá descartar o último registro do arquivo,
pois o mesmo virá com um caracter especial (hexa "1A") e, após o descarte, fazer as seguintes
validações:
 Checar se o arquivo tem, pelo menos, um header e um trailler; caso contrario gravar a
mensagem “Arquivo sem Header ou Trailler”.
 Checar se o campo 1.1.4 está gravado com ‘Retorno’; caso contrario gravar mensagem “Arquivo
não é de retorno-Returncode <> Retorno”

575039736.doc
 Checar se todos os registros detalhe (desconsiderar header e trailler) tem tamanho maior ou
igual a 232 caracteres e menor ou igual a 250 caracteres; caso contrario gravar a mensagem
“Tamanho de registro fora da faixa permitida (232 a 250 caracteres)”
 Checar se a quantidade de registros no detalhe do arquivo é igual ao dado no campo QUANTREG
da tabela controle arquivos processados(Entrar na tabela com os campos ZZCONTRATO e
ZZNOMEARQ). Caso contrario gravar a mensagem “Arquivo com quantidade de faturas errada.”
Para os casos em que o campo quantidade de registros na tabela de arquivos processados, esteja
preenchido com valor ‘0’ (zero). Não executar esta validação.(Caso de faturas migradas)
5.2.1.1 Se alguma das condições acima não for satisfeita, o arquivo será rejeitado e transferido para um
diretório de arquivos rejeitados. (.../SPC/ERROR).
Todas as mensagens de erro deverão ser concatenadas e separadas “|” pipe e armazenadas no campo
motivo da rejeição da Tabela controle arquivos Rejeitados para cada arquivo rejeitado.
5.2.2. Para cada arquivo de retorno existente no diretorio (.../SPC/INPUT) e na tabela “controle arquivos
processados” com campo RETOK= ‘X’ o programa devera gravar na tabela “Arquivos Rejeitados” com
o motivo de “arquivo ja processado com sucesso” e transferir o arquivo para um diretório de
arquivos rejeitados. (.../SPC/ERROR)
5.2.3. Para os arquivos não rejeitados preencher o campo RETOK com ‘X’ e campo data do
processamento com SY-DATUM , na tabela de controle arquivos processados(Entrar na tabela
ZTCB_ARQ_PROCES com os campos ZZCONTRATO e ZZNOMEARQ).
5.2.3.1. Verificar resultado de cada registro detalhe no arquivo (desconsiderar os registros header
e trailler nesta verificação): IF informação for diferente de ‘00’ nos campos 1.2.19, ou 1.2.35
ou 1.2.54 (no layout de arquivo de saida SPC), concatenar os campos diferentes de ‘00’, ir para
passo 5.2.3.2, ELSE ir para 5.2.3.3
5.2.3.2. Gravar no log de erro do arquivo: nome do arquivo e código do contrato (ZZCONTRATO),
registros que apresentaram erro e tipo de erro ocorrido (identificado em 5.2.3.1). Alem disso
identificar o número da fatura no campo 1.2.45 (no layout de arquivo de saida SPC), buscar
registro correspondente na tabela de Gerenciamento da Negativação no campo VTRE2 para o
campo MSTYP=’ZC’, (arquivo enviado-campo 1.2.45 = tabela Gerenciamento da Negativação-
Numero da fatura e preencher o status de confirmação de inclusão ou status de confirmação de
exclusão com:
IF campo 1.2.41 = ‘10’, preencher no campo ‘Status Inclusão’ da tabela Ger. Negativação os
codigos de erro concatenados identificados no passo 5.2.3.1, IF 1.2.41 = ‘20’ preencher no
campo ‘Status Exclusão’ da tabela Ger. Negativação), fazer loop até terminar os registros do
arquivo.
fazer loop até terminar os registros do arquivo e END

5.2.3.3. Identificar o número da fatura no campo 1.2.45 (no layout de arquivo de saida SPC),
buscar registro correspondente na tabela Gerenciamento da Negativação, descrita na EF
CB028.1 (arquivo enviado-campo 1.2.45 = tabela Gerenciamento da Negativação-Numero da
fatura) e preencher a data da confirmação da inclusão/exclusão com a data da execução do
programa, da seguinte forma:
5.2.3.4. IF campo 1.2.41 = ‘10’, preencher data no campo Data confirm inclusão da tabela
Z_Gerenciamento da Negativação, IF 1.2.41 = ‘20’ preencher data no campo Data confirm
exclusão da tabela Z_Gerenciamento da Negativação), fazer loop até terminar os registros do
arquivo e END.
5.2.4. Ao final do processamento de todos os arquivos de retorno do SPC, deverá ser verificado quais
são os arquivos que deveriam ter sido retornados após “n” dias configuráveis e gerar um arquivo
texto para ser enviado a área responsável.
5.2.4.1. Verificar na tabela “controle arquivos processados”, através do campo
‘Retorno_OK’=blank’ e campo “data de envio” <= a SY-DATUM – parâmetro DIAS configurado na
tabela ZTCBQUANTREV para o ID de processo=’3’ e gerar o arquivo com a seguinte
nomenclatura “Arq_SPC_Nao_Retornados_AAAAMMDDHH24MISS.TXT” e as seguintes
informações deverão ser informadas no arquivo:

575039736.doc
- Nome do arquivo – campo NOMARQ da tabela de “controle arquivos processados”

- Contrato da Operadora com o SPC: Campo ZZCONTRATO da tabela de “controle arquivos
processados”
- Data do envio para o SPC – campo “data de envio” da tabela de “controle arquivos processados”
- Nome do contato – campo “pessoa de contato da TIM” da tabela “c adastro de dados da instituição
informante” descrita na EF CB.028.1 para o código do contrato correspondente e MSTYP=’ZC’
- DDD + Telefone – campos DDD e Telefone referentes ao telefone de contato da responsável da TIM da
tabela “cadastro de dados da instituição informante” descrita na EF CB.028.1 para o código do
contrato correspondente. Exemplo : 021 8113 0000.
Ramal de contato – campo ramal do responsável da TIM descrito na tabela “cadastro de dados da
instituição informante” na EF CB.028.1 para o código do contrato correspondente. Exemplo : 021 8113
0000.
Exemplo do registro a ser gravado no arquivo:
Os seguintes arquivos não foram retornados pelo SPC:

XXXXXXXXXXXXXXXXXXXX – nome do arquivo
XXXXXXXXX- Contrato da Operadora
XXXXXXXXX- Contrato da Operadora
Entrar em contato com < Nome do Contato> no telefone < DDD + Telefone> ou no ramal <ramal>
Esse arquivo deverá ser gravado no diretório (.../SPC/NoReturn) e um processo externo (exemplo um
shell script como utilizado atualmente) enviará através de uma lista de distribuição via email como já
existente em Produção (exemplo: dl_prod_cobranca e dl_cobranca).
Após enviado o arquivo para a lista de distribuição acima descrita, o arquivo deverá ser movido para o
diretório de backup (.../SPC/BACKUP).
5.3. Verificar o conteudo do diretorio (..../SERASA/INPUT). Caso não existam arquivos a serem processados ir
no passo 5.3.4. Se existir arquivo:
Para os arquivos de retorno do SERASA pendentes de processamento no diretório (.../SERASA /INPUT),
identificar o numero de remessa (sequencial) no header dentro do arquivo( Campo 2.2.1 Número de remessa
descrito na seção 4.2 dos layouts dos arquivos de entrada ). Verificar se existem algum registro correspondente
na tabela “controle arquivos processados”, através do campo ‘ZZSEQUENCIAL’ igual ao sequencial achado no
header do arquivo de retorno, para o contrato vindo no nome do arquivo em processamento NDM.NDXXXXX
(campo Contrato da tabela Controle de Arquivos processados). Caso o arquivo encontrado no diretorio
.../SERASA /INPUT não exista na tabela de “controle processados” descrita na seção 3.7 novos objetos, g ravar
na tabela “Arquivos Rejeitados” com o motivo de “arquivo não enviado ao SERASA” e transferir o arquivo para
um diretorio de arquivos rejeitados (..../SERASA/ERROR).
5.3.1. Para cada arquivo de retorno existente no diretorio (.../SERASA /INPUT) e na tabela “controle
arquivos processados SERASA” com campo RETOK= ‘blank’ o programa devera fazer as seguintes
validações:
 Checar se o campo 2.1.8 está gravado com a identificação do campo “Codigo convenio” da
tabela Controle arquivos SERASA; caso contrario gravar mensagem “Codigo de convenio
invalido.”
 Checar se o campo 2.1.10 está gravado com ‘R’; caso contrario gravar mensagem “Arquivo não é
de retorno-Returncode <> R”
 Checar se o campo 2.1.9 corresponde ao numero de sequencial presente na tabela controle
arquivos processados SERASA para o arquivo em analise, caso contrario gravar mensagem
“Numero de remessa errado”
 Checar se todos os registros tem o mesmo tamanho (600 caracteres); caso contrario gravar a
mensagem “Tamanho de registro diferente de 600 caracteres”

575039736.doc
 Checar se o arquivo tem, pelo menos, um header e um trailler; caso contrario gravar a
mensagem “Arquivo sem Header ou Trailler”
 Checar se o código de retorno no header está em branco; (campo 2.1.13 no layout do arquivo de
retorno de SERASA), caso contrario gravar a mensagem “Arquivo com codigo de erro no header”
 Checar se o código de retorno no trailer está em branco; (campo 2.3.3 no layout do arquivo de
retorno de SERASA), caso contrario gravar a mensagem “Arquivo com codigo de erro no trailler”
 Checar se a quantidade de registros no detalhe do arquivo é igual ao dado no campo QUANTREG
da tabela controle arquivos processados, caso contrario gravar a mensagem “Arquivo com
quantidade de faturas errada.” Para os casos em que o campo quantidade de registros na tabela
de arquivos processados, esteja preenchido com valor ‘0’ (zero), não executar esta validação.
(Caso de faturas migradas)
Se alguma das condições acima não for satisfeita, o arquivo será rejeitado e transferido para um diretório
de arquivos rejeitados. (.../SERASA/ERROR).
Todas as mensagens de erro deverão ser concatenadas e separadas “|” pipe e armazenadas no campo
motivo da rejeição da Tabela controle arquivos Rejeitados para cada arquivo rejeitado.
5.3.2. Para cada arquivo de retorno existente no diretorio (.../SERASA/INPUT) e na tabela “controle
arquivos processados” com campo RETOK= ‘X’ o programa devera gravar na tabela “Arquivos
Rejeitados” com o motivo de “arquivo ja processado com sucesso” e transferir o arquivo para um
diretório de arquivos rejeitados. (.../SERASA/ERROR).
5.3.3. Para os arquivos não rejeitados preencher o campo RETOK com ‘X’ na tabela de controle arquivos
processados
5.3.3.1. Verificar resultado de cada registro no arquivo: IF informação for diferente de branco ou
diferente de ‘001’ no campo 2.2.40 ir para passo 5.3.3.2, ELSE ir para 5.3.3.3
5.3.3.2. Gravar no log de erro do arquivo: nome do arquivo enviado com erro, registros que
apresentaram erro e tipo de erro ocorrido (identificado em 5.3.3.1). Alem disso identificar o
número da fatura no campo 2.2.32 (no layout de arquivo de saida SCPC), buscar registro
correspondente na tabela Gerenciamento da Negativação no campo VTRE2 para o campo
Bureau=’ZB’, descrita na EF CB028.1 (arquivo enviado-campo 2.2.32 = tabela Gerenciamento da
Negativação-Numero da fatura) e preencher o status de confirmação de inclusão ou status de
confirmação de exclusão com:
IF campo 2.2.2 = ‘I’, preencher no campo ‘Status Inclusão’ da tabela Ger. Negativação o codigo
de erro identificado no passo 5.3.3.1, IF campo 2.2.2 = ‘E’ preencher no campo ‘Status
Exclusão’ da tabela Ger. Negativação), fazer loop até terminar os registros do arquivo.
fazer loop até terminar os registros do arquivo e END
5.3.3.3. Identificar o número da fatura no campo 2.2.32, buscar registro correspondente na tabela
Z_Gerenciamento da Negativação-Numero da fatura, e preencher a data da confirmação da
inclusão/exclusão com a data da execução do programa, da seguinte forma:
5.3.3.4. IF campo 2.2.2 = I, preencher data no campo Data confirm incl da tabela Ger.
Negativação, IF campo 2.2.2 = ‘E’ preencher data no campo Data confirm excl da tabela Ger.
Negativação), fazer loop até terminar os registros do arquivo e END
5.3.4. Ao final do processamento de todos os arquivos de retorno do Serasa, deverá ser verificado quais
os arquivos que deveriam ter sido retornados após “n” dias configuráveis e gerar um arquivo texto
para ser enviado a área responsável.
5.3.4.1. Verificar na tabela “controle arquivos processados SERASA”, através do campo
‘Retorno_OK’=blank’ e campo “data de envio” <= a SY-DATUM – parâmetro DIAS configurado na
tabela ZTCBQUANTREV para o ID de processo=’3’ e gerar o arquivo com a seguinte nomeclatura
“Arq_SERASA_Nao_Retornados_AAAAMMDDHH24MISS.TXT” e as seguintes informações deverão
ser informadas no arquivo:
- Nome do arquivo – campo NOMARQ da tabela de “controle processados SERASA”
- Data do envio para o SERASA – campo “data de envio” da tabela de “controle processados SERASA”
- Nome do contato – campo “pessoa de contato da TIM” da tabela “c adastro de dados da instituição
informante” descrita na EF CB.028.1 para o código do contrato correspondente e MSTYP=’ZM’

575039736.doc
- DDD + Telefone – campos DDD e Telefone referentes ao telefone de contato da responsável da TIM da
tabela “cadastro de dados da instituição informante” descrita na EF CB.028.1 para o código do
contrato correspondente. Exemplo : 021 8113 0000.
Ramal de contato – campo ramal do responsável da TIM descrito na tabela “cadastro de dados da
instituição informante” na EF CB.028.1 para o código do contrato correspondente. Exemplo : 021 8113
0000.
Exemplo do registro a ser gravado no arquivo:
Os seguintes arquivos não foram retornados pelo SERASA:

Entrar em contato com < Nome do Contato> no telefone < DDD + Telefone> ou no ramal <ramal>
Esse arquivo deverá ser gravado no diretório (.../SERASA/NoReturn) e um processo externo (exemplo
um shell script como utilizado atualmente) enviará através de uma lista de distribuição via email como
já existente em Produção (exemplo: dl_prod_cobranca e dl_cobranca).
Após enviado o arquivo para a lista de distribuição acima descrita, o arquivo deverá ser movido para o
diretório de backup (.../SERASA/BACKUP).
END
5.4 O arquivo de retorno de EQUIFAX devera ter o mesmo tratamento descrito no passo 5.2 para o arquivo de
retorno de SPC.
3.12. Novos Objetos
Criar Tabela ZTCBT_INF_OPERA_SPC de informação das Operadoras.

Campo Descrição Campo Chave Elemento de Dados Tipo Ta
m
ID Centro de Custo ID CENTRO DE CUSTO X CHAR 5
Codigo de Contrato Codigo de Contrato CHAR 8
Valores da tabela ZTCBT_INF_OPERA_SPC de informação das Operadoras.

ID CENTRO DE CUSTO CÓDIGO DO CONTRATO
1 00300812
2 00300812
3 00300812
4 00300812
5 00300812
6 00300812
7 00300812
8 00300812
9 00300812
10 00300812
11 00300812
12 00300812
13 00300812
14 00300812
15 00300812
16 00300812

575039736.doc
17 00339308
18 00339308
19 00339308
20 00339308
21 00339308
22 00339308
23 00300812
24 00339308
25 00339308
26 00300812
27 00339308
28 00300812
29 00300812
Campo Descrição Campo Chave Elemento de Dados Tipo Ta

m
ID Centro de Custo ID CENTRO DE CUSTO X CHAR 5
Codigo de Contrato Codigo de Contrato CHAR 5
CNPJ RAIZ CNPJ RAIZ CHAR 8
Filial FILIAL CHAR 6
Valores da tabela de informação das Operadoras.
ID Centro Codigo de CNPJ RAIZ Filial

de Custo Contrato
5 88473 04206050 000180
4 88473 04206050 000180
1 88473 04206050 000180
2 88473 04206050 000180
7 88473 04206050 000180
14 88473 04206050 000180
8 88473 04206050 000180
11 88473 04206050 000180
12 88473 04206050 000180
15 88473 04206050 000180
10 88473 04206050 000180
9 88473 04206050 000180
6 88473 04206050 000180
3 88473 04206050 000180
16 88473 04206050 000180
13 88473 04206050 000180
29 88473 04206050 000180

575039736.doc
19 58752 01009686 001205

25 58752 01009686 001205
24 58752 01009686 001205
21 88482 02336993 000100
17 88482 02336993 000100
20 88482 02336993 000100
22 88482 02336993 000100
27 88482 02336993 000100
18 88482 02336993 000100
26 33232 02332397 000144
23 33242 02334700 000148
28 33222 02432056 000140
Tabela controle arquivos processados
Campo Descrição Campo Chave Tipo Tam

NOMARQ Nome do Arquivo X CHAR 50
Codigo do contrato das
Contrato operadoras no Serasa / SPC X CHAR 5
Flag de arquivo de retorno 1
RETOK processado com succeso CHAR
Data em que foi enviado para o 8
Data de envio CB DATS
Data do Data em que o arquivo foi 8
processamento processado com sucesso. DATS
Sequencial na hora da geração
Sequencial do arquivo CHAR
Quantidade de registros no
detalhe na hora da geração do
QUANTREG arquivo NUM 8
Tabela controle arquivos Rejeitados
Campo Descrição Campo Chave Tipo Tam

Sequencial incrementado de um 6
em um a cada nova registro
Sequencial inserido X NUM
Nome do Arquivo Nome do Arquivo rejeitado X CHAR 50
Motivo da
rejeição Motivo da rejeição CHAR 100
Data da rejeição Data da rejeição DATS 8
Tabela controle sequencial
Campo Descrição Campo Chave Tipo Ta

m
MSTYP Bureau de credito CHAR 2
Nome do Nome da empresa 15
informante informante CHAR
8 Codigo de CHAR 5

575039736.doc
Contrato/identificador
da TIM
Sequencial do numero
Sequencial do arquivo NUM 10
Codigo convenio Codigo do convenio CHAR 15
Tabela de Quantidade de dias maximos para checar faturas reabertas (ZTCB-QUANTREV)

m
DIAS NUM 3
ID Processo CHAR 1
Descrição CHAR 10
Novos Append Structure na tabela ZTCBGEREN_NEGATI e ZTCBHIS_NEGATI.

m
LAUFD ID de data DATS 8
Critério de identificação 6
LAUFI adicional CHAR
Indicativo de nova 1
NOVAFAT fatura CHAR
3.13. Material adicional

575039736.doc
4. Interfaces de entrada
4.1. Arquivos de retorno (SPC)
Layout - Header
Nome e caminho para o arquivo de SPCSSSSSSR
saída
Caso o arquivo já exista: ( ) Sobrescrever (“overwrite”)
( x ) Acrescentar no final (“append”) ???
( ) Mensagem de erro (“Abort”)
( ) Outros: ______________________________________________
Campo Nome de Tipo Tam. Dec. Conteúdo Descrição
campo
1.1.1 Associado NUMC 8 0 “00300812” ou Código do contrato identificador da TIM
“00339308 “ no SPC
00300812: TIM CELULAR
00339308: TIM NORDESTE
1.1.2 Constante NUMC 10 0 “0000000000” Código constante
1.1.3 Data do Movimento DATA 6 0 Formato ddmmaa Data de envio do arquivo
1.1.4 Constante NUMC 7 0 “retorno” Identificação de retorno”
1.1.5 Informante CHAR 55 0 “TIM BRASIL” Nome do Informante
1.1.6 Controle CHAR 8 0 Número da remessa do arquivo
sequencial, incrementando de 1 a cada
novo movimento (preencher com zeros à
esquerda)
1.1.7 Constante CHAR 8 0 Blank Blank
1.1.8 Versão NUMC 2 0 “03” Identificação da versão do arquivo
Layout - Detalhe
saída
( ) Outros: ______________________________________________
campo
NOME

“00339308 “ no SPC
1.2.2 Constante NUMC 1 0 “1” “1”
1.2.3 Sequencia NUMC 5 0 Número de Seqüência (Começar com o
número 1 e incrementar a cada registro
existente no arquivo)
1.2.4 Sistema NUMC 1 0 “1” = SPC Cód. do sistema
1.2.5 Constante NUMC 1 0 “A” “A”
1.2.6 Constante NUMC 2 0 “10” “10”

575039736.doc
1.2.7 Documento CHAR 20 0 Número do documento principal

(CPF/CNPJ)
‘CPF’+n de CPF do cliente+brancos a
direita
Ou
‘CNPJ’+ n de CNPJ do cliente+brancos a
direita
1.2.8 Documento CHAR 20 0 Blank Blank

1.2.9 Documento CHAR 20 0 Blank Blank
1.2.10 Nome CHAR 50 0 Nome do devedor (cliente)
1.2.11 Constante NUMC 6 0 Blank
“DDMMAAAA” ou Data de nascimento “DDMMAAAA” ou
1.2.12 Data DATA 8 0
“00000000” “00000000”
1.2.13 Nome CHAR 40 0 Blank Blank
1.2.14 Constante NUMC 16 0 Blank Blank
1.2.15 Constante NUMC 6 0 “000000” “000000”
1.2.16 Naturalidade CHAR 20 0 Blank Blank
1.2.17 Unidade da Federação CHAR 2 0 Blank Blank
1.2.19 Código de Retorno CHAR 20 0 Código do resultado de processamento,
com até 10 ocorrências. (relação dos
código final do layout)
ENDEREÇO
“00339308 “ no SPC
1.2.21 Constante NUMC 1 0 “1” “1”
1.2.23 Sistema NUMC 1 0 “1” = SPC Cód. do sistema:
1.2.24 Constante NUMC 1 0 “B” “B”
1.2.25 Constante NUMC 2 0 “10” “10”
1.2.26 Documento CHAR 20 0 Número do documento principal
(CPF/CNPJ)
1.2.27 Tipo de Registro NUMC 1 0 “1” Tipo de Registro:
“1” = Endereço do devedor (cliente)
Informar tipo e nome do logradouro,
1.2.28 Endereço CHAR 50 0
número e complemento (apt, bloco, etc.)
1.2.29 Bairro CHAR 20 0 Bairro
1.2.30 CEP NUMC 8 0 CEP
1.2.31 Cidade CHAR 20 0 Cidade
1.2.32 UF CHAR 2 0 Sigla da Unidade da Federação
1.2.33 Telefone NUMC 20 0 Número do telefone
1.2.34 Constante CHAR 71 0 Blank
1.2.35 Código de Retorno CHAR 20 0 Código do resultado de processamento,
código final do layout)
OCORRÊNCIA DO SCPC
Associado NUMC 8 0 “00300812” ou Código do contrato identificador da TIM
“00339308 “ no SPC
1.2.36 00339308: TIM NORDESTE
1.2.37 Constante NUMC 1 0 “1” “1”
1.2.38 Sequencia NUMC 5 0 Número de Sequência
1.2.39 Constante NUMC 1 0 “1” “1”
1.2.40 Constante NUMC 1 0 “1” “1”
Código de operação: Inclusão “10”
Operação NUMC 2 0 “10” ou “20”
1.2.41 Exclusão “20”
Documento CHAR 20 0 Documento principal
1.2.42 (CPF+número+brancos a direita)

575039736.doc
1.2.43 Data DATA 8 0 Formato: ddmmaaaa Data do vencimento da fatura

1.2.44 Ocorrência NUMC 2 0 Tipo de ocorrência (RG)
1.2.45 Contrato NUMC 22 0 Número da fatura (nº referencia)
1.2.46 Avalista CHAR 20 0 Blank Blank
1.2.47 Valor NUMC 11 0 Valor de débito (dívida)
1.2.48 Documento de Débito CHAR 2 0 “CT” Contrato = “CT”
1.2.49 Reservado CHAR 17 0 Blank Blank
1.2.50 Constante CHAR 1 0 “N” “N”
1.2.51 Constante NUMC 2 0 “00” “00”
Reservado CHAR 15 0 Blank Customer_id (8 posições) + Código
1.2.53 Febraban (4 posições)
Código de Retorno CHAR 20 0 Código do resultado de processamento,
1.2.54 código final do layout)
Layout - Trailler
saída
( ) Outros: ______________________________________________
campo
“00339308 “ no SPC
1.3.2 Constante NUMC 10 0 “9999999999” “9999999999”
Códigos de Retorno:
00 Operação bem Sucedida
30 Nada Consta
31 Registrado
39 Não Autorizado a Consulta
40 Documento do Débito Inválido
41 Sistema Inválido
42 Tipo de Registro Inválido
43 Código de Operação Inválida
44 Documento-1 Inválido
47 Nome do Devedor Inválido
48 Data de Nascimento do Devedor Inválida
49 Nome do Cônjuge Inválido
50 Data de Nascimento do Cônjuge Inválida
51 Tipo de Endereço Inválido
52 Endereço Inválido
53 Bairro Inválido
54 Número do CEP Inválido
55 Cidade Inválida
56 Unidade da Federação Inválida
57 Código DDD Inválido
58 Número do Telefone Inválido
59 Ramal Inválido
60 Número do Telex Inválido
61 Número do fax Inválido
62 Data de Ocorrência Inválida / Expirada
63 Banco Inválido
64 Agência inválida
65 Número do Cheque Inválido

575039736.doc
66 Motivo Inválido
67 Valor Inválido
68 Tipo de Cobrança Inválido
69 Limite de Parcelas Inválida
70 Praça Inválida
71 Cartório Inválido
72 Registro fora de Seqüência
73 Tipo de Ocorrência Inválida / Não Autorizado
74 Documento de Protesto Inválido
75 Contrato Inválido
76 Documento do Avalista Inválido
77 Tipo de Intercâmbio Inválido
78 Nome do Intercâmbio Inválido
79 Alínea Inválida / Não Permitida
80 Naturalidade Inválida
81 Contato Inválido
82 Roteiro Inválido
83 Forma de Pagamento Inválida
84 Data Inicial de Cliente Inválida
85 Tipo de Passagem/Crédito Inválido
86 Endereço do Devedor/Correntista não Informado
87 Endereço do Avalista não Informado
88 Quantidade de parcelas Inválidas
90 Devedor não Cadastrado
91 Ocorrência Inexistente
92 Avalista não Cadastrado
93 Localidade para Consulta de SCPC ( Intercâmbio ) não responde
94 Localidade para Consulta de SCPC ( Intercâmbio ) inexistente
95 Exclusão de Ocorrência Não Permitida (Sistema ‘4’ - SRC)
96 Contrato/Cheque em duplicidade (somente para inclusão no SCPC e USECHEQUE)
97 Conta corrente inválida
98 Código de Associado Inibido
99 Entrar em Contato com a ACSP
4.2. Arquivos de retorno (SERASA)
Layout - Header
Nome e caminho para o arquivo de saída NDM.NDXXXXX.PEFIN.DDMMYYYYHHMISS.SSSSSS
( ) Outros:
______________________________________________
campo
2.1.1 Codigo do Registro NUMC 1 0 “0” Código do registro = “0” (zero)
Número do CNPJ da instituição informante
2.1.2 CNPJ NUMC 9 0 ajustado à direita e preenchido com zeros
a esquerda
2.1.3
Data da geração DATA 8 0 Formato: Data da geração do arquivo (AAAAMMDD)
AAAAMMDD
Número de DDD do tel. de contato da
2.1.4 DDD NUMC 4 0
instiuição informante (TIM)
Número do tel. de contato da instiuição
2.1.5 Telefone NUMC 8 0
informante (TIM)
Número de ramal do telefone de contato
2.1.6 Ramal NUMC 4 0
da instiuição informante (TIM)
Nome do contato da instituição informante
2.1.7 Nome CHAR 70 0
(TIM)
Identificação do arquivo fixo “SERASA-
2.1.8 Identificação CHAR 15 0
CONVEM 04”
Número de remessa 6 0 Número da remessa do arquivo sequencial
2.1.9 do 000001, incrementando de 1 a cada
novo movimento. Depende da migração.

575039736.doc
2.1.10 Código de envio CHAR 1 0 “R” retorno Código de envio de arquivo

Constante CHAR 4 0 ‘0001’ Diferencial de remessa caso a insituição
2.1.11 informante tenha necessidade de enviar
mais de uma remessa no mesmo dia.
Código de erro CHAR 60 0 Códigos de erro – 3 posições ocorrendo 20
vezes. Ausência de códigos indica que o
2.1.13 arquivo foi aceito no movimento de
Retorno. Na entrada, preencher com
brancos
2.1.14 Seqüencial NUMC 7 0 “0000001” Sequencial de registro do arquivo
Layout - Detalhe
( ) Outros:
______________________________________________
campo
2.2.1 Código do Registro NUMC 1 0 “1” Código do registro = “1”
I – inclusão Código da operação =
E – exclusão I – inclusão
Operação CHAR 1 0
C – devolução do E – exclusão
2.2.2 correio C – devolução do correio
2.2.3 CNPJ CHAR 6 0 Filial e dígito do CNPJ da contratante
Data de vencimento DATA 8 0 Formato: Data vencimento (AAAAMMDD)
2.2.4 AAAAMMDD
Data do término DATA 8 0 Formato: Data do término do contrato (AAAAMMDD)
2.2.5 AAAAMMDD
2.2.6 Natureza CHAR 3 0 “00” Cód. natureza operação = “00”
2.2.7 Praça CHAR 4 0 Cód. praça Embratel
Tipo de pessoa do principal:
Tipo Pessoa CHAR 1 0 “F” ou “J” Física = “F”
2.2.8 Jurídica = “J”
Tipo do primeiro doc. do principal:
Tipo doc 1 NUMC 1 0 “1”ou “2” 1 - CNPJ
2.2.9 2 - CPF
Primeiro doc. do principal:
CPF completo – base + dígito ou CNPJ
Primeiro doc CHAR 15 0 completo – base + filial + dígito.
(ajustado à direita e preenchido com zeros
2.2.10 a esquerda)

575039736.doc
blank (para os Motivo de baixa:

casos de Blank – Para casos de inclusão
inclusão) Codigo de motivo da execusão para os
casos de exclusão.
Casos de exclusão:
01 – PAGAMENTO DA
DÍVIDA
02 – RENEGOCIAÇÃO DA
DÍVIDA
03 – INCLUSÃO INDEVIDA
04 – ORDEM JUDICIAL
05 – CORREÇÃO DE
ENDEREÇO
06 – ATUALIZAÇÃO DO
VALOR – VALORIZAÇÃO
07 – ATUALIZAÇÃO DO
VALOR – PAGAMENTO
PARCIAL
08 – ATUALIZAÇÃO DE
DATA
09 – CORREÇÃO DO
NOME
10 – CORREÇÃO DO
Motivo baixa CHAR 2 0 NÚMERO DO CONTRATO
11 – CORREÇÃO DE
VÁRIOS DADOS ( VALOR
+DATAS+ ETC)
12 – BAIXA POR PERDA
DE CONTROLE DA BASE
13 – MOTIVO NÃO
IDENTIFICADO
OS MOTIVOS ABAIXO
SÃO DE USO INTERNO
DO SISTEMA DA SERASA,
PORTANTO NÃO DEVEM
SER USADOS.
00 – MOTIVO ANTES DA
IMPLANTAÇÃO
( PASSADO )
95 – COMUNICADO
DEVOLVIDO DO
CORREIO
96 – DETERMINAÇÃO
JUDICIAL
97 – DECURSO DO
PRAZO
99 – MOTIVO DA BAIXA
2.2.11 NÃO INFORMADO
Tipo doc 2 CHAR 1 0 Blank Tipo do segundo documento do principal:
2.2.12 Blank
Segundo doc CHAR 15 0 Blank Segundo documento do principal:
2.2.13 Blank
UF Blank UF:
CHAR 2 0
2.2.14 Blank
2.2.22 Nome do devedor CHAR 70 0 Nome do devedor (cliente)
2.2.23 Data de nascimento CHAR 8 0 Blank Blank
Nome do pai DATA 70 0 Blank Nome do pai.
2.2.24 Blank
Nome da mãe CHAR Nome do mãe.
2.2.25
70 0 Blank Blank
2.2.26 Endereço CHAR 45 0 Endereço completo

575039736.doc

2.2.28 Município CHAR 25 0 Município
2.2.29 UF CHAR 2 0 Sigla UF
2.2.30 CEP CHAR 8 0 CEP
2.2.31 Montante NUMC 15 0 Valor montante
2.2.32 Fatura NUMC 16 2 Nº fatura
DDD NUMC 4 0 Blank DDD do telefone do devedor (cliente):
2.2.35 Blank
Telefone NUMC 9 0 Blank Número do telefone do devedor (cliente):
2.2.36 Blank
2.2.37 Constante DATA 8 0 Blank Blank
Código de erro CHAR 60 0 Códigos de erro – 3 posições ocorrendo 20
arquivo foi aceito no movimento de
2.2.40 brancos
2.2.41 Seqüencial NUMC 7 0 Sequência do registro no arquivo.
Layout - Trailler
( ) Outros:
______________________________________________
campo
2.3.1 Código do registro NUMC 1 0 “9” Código de registro = “9” (trailler)
Código de erro NUMC 60 0 Códigos de erro – 3 posições ocorrendo 20
2.3.3 arquivo foi aceito no movimento de
brancos
2.3.4 Seqüencial NUMC 7 0 Sequência de registro do arquivo
Códigos de Retorno:
001 ARQUIVO SEM DETALHES

002 PRIMEIRO REGISTRO NAO E HEADER / SEQUENCIA DIFERENTE DE 1
003 REGISTRO DIFERENTE DE 0, 1 E 9
004 REGISTRO FORA DE SEQUENCIA
005 REGISTRO TRAILLER NAO INFORMADO
006 REGISTRO DEVERIA SER DE PRINCIPAL
007 REGISTRO DE EXCLUSAO NO LOTE DE INCLUSAO
008 CODIGO DE OPERACAO DIFERENTE DE E, I
009 TIPO DE PESSOA PRINCIPAL DIFERENTE DE F, J
010 TIPO DE PESSOA COOBRIGADO DIFERENTE DE F, J
011 NOME INVALIDO
012 NOME NAO PODE SER BRANCOS
013 DATA DO HEADER INVALIDA
014 DATA DA OCORRENCIA INVALIDA

575039736.doc
015 DATA DA OCORRENCIA MAIOR QUE A DATA DA PREPARACAO

016 DATA DA OCORRENCIA MAIOR QUE A ATUAL
017 DATA DA OCORRENCIA JA DECURSADA
018 IDENTIFICACAO DO ARQUIVO INVALIDA
019 REMESSA NAO POSTERIOR A ULTIMA
020 REMESSA NAO NUMERICA OU IGUAL A ZERO
021 CAMPO DE RECEBIMENTO DA REMESSA DIFERENTE DE 'E'
022 EXCLUSAO PARA REGISTRO INEXISTENTE
023 INCLUSAO PARA COOBRIGADO JA EXISTENTE
024 CNPJ DO HEADER INVALIDO
025 CNPJ NAO CADASTRADO NO SISTEMA (TABELA DE REMESSA)
026 FILIAL DA INSTITUICAO NAO NUMERICA
027 FILIAL DA INSTITUICAO INVALIDA
028 DOCUMENTO DO PRINCIPAL NAO NUMERICO
029 DOCUMENTO DO PRINCIPAL INVALIDO
030 DOCUMENTO DO COOBRIGADO NAO NUMERICO
031 DOCUMENTO DO COOBRIGADO INVALIDO
032 DOCUMENTO DO COOBRIGADO IGUAL AO DO PRINCIPAL
033 TRAILLER FORA DE SEQUENCIA
034 SEQUENCIA NAO NUMERICA
035 NATUREZA INVALIDA
036 NATUREZA INVALIDA PARA O CNPJ INFORMADO
037 PRACA INVALIDA
038 VALOR/BOLETIM/CIRCULAR NAO NUMERICO
039 NAO DEVE SER INFORMADO VALOR PARA COOBRIGADO
040 REG. NAO ATUALIZADO. ERRO NO PRINCIPAL OU COOBRIGADO DA
OCORRENCIA.
041 BANCO DO CORRENTISTA INVALIDO
042 REG. COM DOC. ISENTO DEVERA SER ENVIADO DIRETO AO BANCO DO
BRASIL
043 INCLUSAO DO TITULAR COM ALINEA DIFERENTE DO PRINCIPAL
044 AGENCIA INVALIDA
045 DOCUMENTO INVALIDO
046 DIGITO DO DOCUMENTO INVALIDO
047 CONTA NAO NUMERICA
048 CHEQUE INICIAL NAO NUMERICO
049 CHEQUE FINAL NAO NUMERICO
050 CHEQUE INICIAL NAO INFORMADO E FINAL INFORMADO
051 CHEQUE INICIAL INFORMADO E FINAL NAO INFORMADO
052 CHEQUE INICIAL IGUAL A ZEROS E FINAL DIFERENTE DE 999999
053 CHEQUE INICIAL DIFERENTE DE ZEROS E FINAL IGUAL A ZEROS
054 CHEQUE INICIAL MAIOR DO QUE O CHEQUE FINAL
055 MOTIVO NAO INFORMADO
056 MOTIVO DIFERENTE DE "C","E","R","S","M" E "T"
057 VALOR NAO NUMERICO
058 TIPO DE COMANDO DIFERENTE DE "1" E "2"
059 INCLUSAO PARA REGISTRO JA EXISTENTE
060 TIPO DE PESSOA DIFERENTE DE "F" E "J"
061 INFORMACAO ENVIADA NAO PERTENCE A ESTE BANCO
062 BANCO INVALIDO
063 EXCLUSAO NAO EFETUADA (DOC NAO EH O MESMO DA INCLUSAO)
064 CONTA INVALIDA

575039736.doc
065 CHEQUE INVALIDO

066 DIFERENCIAL INVALIDO
067 TIPO DE REGISTRO DIFERENTE DE "0", "2", "4", "6" E "9"
068 MOTIVO DEVE SER INFORMADO
069 CODIGO DO MOTIVO INVALIDO NA EXCLUSAO
070 CODIGO DE REPASSE DA TABELA DE BANCO DIFERENTE DE "S" OU "N"
071 TIPO DE PESSOA DIFERENTE DE "1" E "2"
072 ALINEA INVALIDA
073 DOCUMENTO NAO MAIOR QUE 10000
074 VALOR INVALIDO
075 ALTERACAO NAO EFETUADA - CHAVE NAO EXISTENTE
076 INCLUSAO DO TITULAR SEM PRINCIPAL
077 EXCLUSAO NAO EFETUADA (BCO,AGENCIA,CONTA,CHEQUE NAO ENCONTRADO)
078 EXCLUSAO PARA CCF INVALIDO, EXISTE REGISTRO NO ACHEI
079 DOCUMENTO PARA EXCLUSAO DO CCF DEVE SER PREENCHIDO
080 EXCLUSAO EFETUADA SO PELO DOCUMENTO
081 REGISTRO APOS TRAILLER
082 REGISTRO JA EXISTENTE COM ALINEA NAO RESTRITIVA
083 CCF DO BB NAO ACEITA DOC FORMADO POR UM UNICO ALGARISMO
084 REGISTRO JA EXISTENTE COM ALINEA 12, 13 OU 14
085 NUMERO DO CONTRATO/TITULO INVALIDO
086 CHAVE DA INSTITUICAO DEVE SER INFORMADA
087 CHAVE DA INSTITUICAO DUPLICADA
088 CHAVE DA INSTITUICAO INVALIDA
089 EMPRESA NAO PARTICIPANTE DO CONVENIO
100 NOME DO INFORMANTE EH OBRIGATORIO
101 DATA DE NASCIMENTO EH OBRIGATORIA / INVALIDA
102 NUMERO DO CONTRATO/TITULO EH OBRIGATORIO
103 TIPO DE DOCUMENTO INVALIDO
104 CONVENIO NAO CADASTRADO
105 INCLUSAO BLOQUEADA FACE A DETERMINACAO JUDICIAL
106 MOVIMENTO APOS RESCISAO DE CONTRATO DO CONVENIO.
107 NOME DO PAI INVALIDO
108 NOME DA MAE INVALIDO
109 FALTA ENDERECO
110 FALTA BAIRRO
111 FALTA UF DO ENDERECO
112 FALTA CEP DO ENDERECO
113 FALTA INFORMACAO TIPO DE PESSOA
114 TIPO DE PESSOA INFORMADO NO PRINCIPAL E NO COOBRIGADO
115 TIPO DE PESSOA DO PRINCIPAL DIFERENTE DE F
116 TIPO DE PESSOA DO COOBRIGADO DIFERENTE DE F
117 CPF DO PRINCIPAL INVALIDO
118 CPF DO COOBRIGADO INVALIDO
119 CEP DO ENDERECO INVALIDO
120 DATA DA OCOR.INVALIDA,INF.A 30 DIAS OU SUP.1 ANO
121 DATA DE NASCIMENTO INFERIOR A 18 ANOS
122 PROBLEMA NA SERACGCO,LIGUE(011)5591-0137
123 PROBLEMA NA SERACPFO,LIGUE(011)5591-0137
124 ERRO LEIT. RECONSUL, LIGUE(011)5591-0137
125 DOCUMENTO DEVE SER NUMERICO
126 PROBLEMA NA RSRDOCTO,LIGUE(011)5591-0137

575039736.doc
127 PROBLEMA NA RSODOCTO,LIGUE(011)5591-0137

128 ERRO LEIT.OCORRENCIAS,LIGUE(011)5591-0137
129 CODIGO DA ESTACAO INVALIDO
130 ACESSO NAO AUTORIZADO,LIGUE(011)5591-0137
131 PROBLEMA NA SERASIGA,LIGUE(011)5591-0137
132 PROBLEMA NA SERAGERA,LIGUE(011)5591-0137
133 PROBLEMA NA RECONSUL,LIGUE(011)5591-0137
134 PROBLEMA NA UCBANCOR,LIGUE(011)5591-0137
135 CHQ INICIAL DEVE SER NUMERICO E > ZEROS
136 BANCO DEVE SER NUMERICO E > QUE ZEROS
137 VALOR SE DIGITADO TEM QUE SER > ZEROS
138 DATA VENCIMENTO INVALIDA(DDMMAAAA)
139 DATA VENCIMENTO OBRIGATORIA
140 VALOR OBRIGATORIO
141 NRO MAXIMO DE CHEQUES P/ CONSULTA EH 12
142 BANCO NAO TRABALHA COM CONTA CORRENTE
143 DIG.VERIF.DO CH.INIC. DEVE SER NUMERICO
144 DIG.VERIF.NAO CORRESPONDE C/NUM.CH.INIC
145 DIG.VERIF. DO CH. FIN. DEVE SER NUMERICO
146 DIG.VERIF.NAO CORRESPONDE C/ NUM CH.FIN
147 CODIGO IDENTIFICACAO DEVE SER NUMERICO
148 CODIGO IDENTIFICACAO TEM QUE SER > ZEROS
149 PROBLEMA NA SMLOGER, LIGUE(011)5591-0137
150 PROBLEMA NA SMCONSUL, LIGUE(011)5591-0137
151 ERRO LEIT. SMCONSUL, LIGUE(011)5591-0137
152 PROBLEMA NA SMGCCCON, LIGUE(011)5591-0137
153 PROBLEMA NA RSCOMPAR, LIGUE(011)5591-0137
154 PROBLEMA NA SMLIMCON, LIGUE(011)5591-0137
155 ERRO LEIT. SMGCCCON, LIGUE(011)5591-0137
156 DATA OCORRENCIA INFERIOR A 4 DIAS
157 EXCLUSAO SO PERMITIDA PARA A FONTE DE INCLUSAO
158 BANCO EM LIQUIDACAO
159 SENHA OBRIGATORIA
160 LOGON OBRIGATORIO
161 ACESSO BLOQUEADO,LIGUE SERASA
162 TIPO DE PESSOA DIFERENTE DE 1, 2 E 6
163 TIPO DE REGISTRO DIFERENTE DE 0, 1 E 9
164 TIPO DE DOCUMENTO DIFERENTE DE 1, 2, 4 E 6
165 DT.TERMINO DO CONTRATO ANTERIOR A DT. DA OCORRENCIA
166 DATA DE TERMINO DO CONTRATO INVALIDA
167 FALTA UF DO RG
168 VALOR DEVE SER NUMERICO E MAIOR QUE ZEROS
169 AREA INFORMANTE DA REMESSA C/ ERRO. MOVIMENTO REJEITADO
170 BANCO INVAL. P/ NATUREZA DE/DC/CH. VER AS 4 PRIMEIRAS POS.
CONTRATO
171 TIPO DE PESSOA DO CREDOR DIFERENTE DE F, J
172 TIPO DE DOCUMENTO DO CREDOR INVALIDO
173 DOCUMENTO DO CREDOR NAO NUMERICO
174 DOCUMENTO DO CREDOR INVALIDO
175 NOME DO CREDOR EH OBRIGATORIO
176 NOME DO CREDOR INVALIDO
177 FOI INFORMADO O CREDOR. PARTICIPANTE NAO EH ENTIDADE DE CLASSE

575039736.doc
178 ALINEA DIF 12,13 E 14 (NATUREZA DE/DC/CH, 2 ULTIMAS POS.

CONTRATO)
179 STATUS INVALIDO.
180 CGC INVALIDO.
181 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. MUDOU-SE
182 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. ENDERECO
INSUFICIENTE
183 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. NUMERO INEXISTENTE
184 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. DESCONHECIDO
185 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. RECUSADO
186 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. NAO PROCURADO
187 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. AUSENTE
188 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. FALECIDO
189 EXCL.DEVIDO DEVOL.COMUNICADO PELO CORREIO.INFOR.PORTEIRO/SINDICO
190 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. ENDERECO
DESCONHECIDO
191 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. CEP INCORRETO
192 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. NAO ESPECIFICADO
193 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. CX POSTAL
INEXISTENTE
194 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO. IMOVEL INEXISTENTE
195 EXCL. DEVIDO DEVOL. COMUNICADO PELO CORREIO
196 INCLUSAO RECUSADA/CARTA DEVOLVIDA DO CORREIO/END.IGUAL AO
ANTERIOR.
200 BANCO DO HEADER INVALIDO
201 QTD DE REGISTROS NA REMESSA (REGISTROS DETALHES) NAO NUMERICA
202 QTD DE TITULOS NA REMESSA (CAMPO 17 = 1) NAO NUMERICA
203 QTD DE INDICACOES NA REMESSA (TITULOS DO TIPO DMI) NAO NUMERICA
204 QTD DE ORIGINAIS NA REMESSA (TITULOS DIFERENTES DE DMI)NAO
NUMERICA
205 BANCO NAO CADASTRADO NO SISTEMA (TABELA DE BANCOS)
206 CONVENIO NAO CADASTRADO (TABELA DE CONVENIOS)
207 TIPO DE PESSOA (DEVEDOR) DIFERENTE DE F, J
208 TIPO DE DOCUMENTO DO DEVEDOR INVALIDO
209 DOCUMENTO DO DEVEDOR NAO NUMERICO
210 DOCUMENTO DO DEVEDOR INVALIDO
211 NUMERO DE CONTROLE NAO EH DO PRIMEIRO DEVEDOR
212 NUMERO DE CONTROLE DO DEVEDOR FORA DE SEQUENCIA
213 TIPO DE PESSOA (CEDENTE) DIFERENTE DE F, J
214 TIPO DE DOCUMENTO DO CEDENTE INVALIDO
215 DOCUMENTO DO CEDENTE NAO NUMERICO
216 DOCUMENTO DO CEDENTE INVALIDO
217 NOME DO CEDENTE EH OBRIGATORIO
218 NOME DO CEDENTE INVALIDO
219 VALOR DO TITULO INVALIDO
220 VALOR REMANESCENTE DO TITULO INVALIDO
221 NOME DO SACADOR DO TITULO EH OBRIGATORIO
222 NOME DO SACADOR DO TITULO INVALIDO
223 NOSSO NUMERO EH OBRIGATORIO
224 SIGLA DE IDENTIFICACAO DA ESPECIE DO TITULO INVALIDA
225 DATA DA EMISSAO DO TITULO SUPERIOR A DATA DE VENCIMENTO
226 DATA DA EMISSAO DO TITULO INVALIDA
227 DATA DE VENCIMENTO DO TITULO SUPERIOR A DATA DE HOJE
228 TITULO JA DECURSADO. VERIFIQUE A DATA DE VENCIMENTO

575039736.doc
229 DATA DE VENCIMENTO DO TITULO INVALIDA

230 DATA DE VENCIMENTO DO TITULO INF. A 3 DIAS OU SUPERIOR A 1 ANO
231 TIPO DE OCORRENCIA DIFERENTE DE 0, 3
232 TIPO DE OCORRENCIA DE BAIXA (3) NO TITULO DE INCLUSAO (0)
233 NOME DO DEVEDOR EH OBRIGATORIO
234 NOME DO DEVEDOR INVALIDO
235 FALTA ENDERECO DO DEVEDOR
236 FALTA UF DO ENDERECO DO DEVEDOR
237 FALTA CEP DO ENDERECO DO DEVEDOR
238 CEP DO ENDERECO DO DEVEDOR INVALIDO
239 DOCUMENTO DO DEVEDOR IGUAL AO DO CEDENTE
240 AS INFORMACOES, DO TITULO, ESTAO DIFERENTES COM OS SEUS
DEVEDORES
241 INCLUSAO PARA DEVEDOR JA EXISTENTE NO TITULO
242 REGISTRO NAO ATUALIZADO. ERRO NO CEDENTE OU DEVEDOR
243 SOMATORIO DE SEGURANCA (QTD NA REMESSA) DO TRAILLER NAO NUMERICO
244 SOMATORIO DE SEGURANCA (VALOR DA REMESSA) DO TRAILLER NAO
NUMERICO
245 SOMATORIO DE SEGURANCA (QTD NA REMESSA) DIFERENTE DO PROCESSADO
246 SOMATORIO DE SEGURANCA (VALOR DA REMESSA) DIFERENTE DO
PROCESSADO
247 QTD DE REGISTROS NA REMESSA (REG. DETALHES) DIFERENTE DO
PROCESSADO
248 QTD DE TITULOS NA REMESSA (CAMPO 17 = 1) DIFERENTE DO PROCESSADO
249 QTD DE INDICACOES NA REMESSA (DMI) DIFERENTE DO PROCESSADO
250 QTD DE ORIGINAIS NA REMESSA (DIF. DMI) DIFERENTE DO PROCESSADO
251 CAMPOS DO REGISTRO HEADER COM ERRO
252 REMESSA NAO NUMERICA OU FORA DE SEQUENCIA
253 REGISTRO HEADER OU TRAILLER NAO EXISTENTES
254 BANCO NAO NUMERICO OU = 0
255 BANCO NAO ENCONTRADO NA TAB. BANCOS
256 BANCO NAO ENCONTRADO NA TAB. REMESSA
257 BANCO INATIVO
258 EMPRESA NAO NUMERICA OU = 0
259 EMPRESA COM DOCUMENTO INVALIDO
260 EMPRESA NAO EXISTE NA TAB. DE LOGON
261 EMPRESA NAO ENCONTRADA NA TAB. REMESSA
262 LOGON INVALIDO
263 IDENTIFICACAO DO ARQUIVO INVALIDA
264 TIPO DE SAIDA INVALIDO (TAB. REMESSA)
265 BANCO NAO PARTICIPANTE DO ACHEI
266 BANCO SEM OPCAO DE REPASSE NA TAB.BCO
267 BANCO JA EXTINTO
268 DATA DA REMESSA INVALIDA
269 FALTA ENDERECO DO CREDOR
270 FALTA CIDADE DO ENDERECO DO CREDOR
271 FALTA UF DO ENDERECO DO CREDOR
272 FALTA CEP DO ENDERECO DO CREDOR
273 CEP DO ENDERECO DO CREDOR INVALIDO
274 CNPJ NAO EXISTE NO CADASTRO DE CNPJ/CPF ATE ESTA DATA
275 CPF NAO EXISTE NO CADASTRO DE CNPJ/CPF ATE ESTA DATA
276 FILIAL NAO EXISTE NO CADASTRO DE CNPJ/CPF ATE ESTA DATA
277 CNPJ CREDOR/CEDENTE NAO EXISTE NO CADASTRO DE CNPJ/CPF ATE ESTA

575039736.doc
DAT
278 CPF CREDOR/CEDENTE NAO EXISTE NO CADASTRO DE CNPJ/CPF ATE ESTA
DATA
279 FILIAL CREDOR/CEDENTE NAO EXISTE CADASTRO DE CNPJ/CPF ATE ESTA
DATA
280 CAMPOS DO CMC7 INVALIDOS
281 IDENTIFICACAO DADOS DO CHEQUE INVALIDO
282 BCO/AGE (CMC7 INI/FIN) DEVEM SER IGUAIS
283 IDENTIFICAçãO DADOS DO CHEQUE INVALIDA
284 BCO/AGE (CMC7 INI/FIN) DEVEM SER IGUAIS
285 FALTA O MUNICIPIO DO ENDERECO.
286 DOCUMENTO DO CREDOR IGUAL AO DO NEGATIVADO
287 REGISTRO DEVERIA SER DE PRINCIPAL OU COOBRIGADO
288 REGISTRO DEVERIA SER DE COOBRIGADO
289 INFORMADO A UF SEM O NUMERO DO RG
290 EXCLUSAO POR DATA DE OCORRENCIA JA DECURSADA
291 EXCLUSAO POR DETERMINACAO JUDICIAL
292 EXCLUSAO POR SOLICITACAO DA EMPRESA PARTICIPANTE
293 SEQUENCIA DO NUMERO DO CHEQUE DEVE SER MAIOR QUE ZERO.
294 SEQUENCIA DO CHEQUE JA EXISTENTE PARA A CHAVE.
295 RAZAO SOCIAL NAO CORRESPONDE AO CNPJ INFORMADO.
296 NOME NAO CORRESPONDE AO CPF INFORMADO.
297 COOBRIGADO INIBIDO/EXCLUIDO DEVIDO A INIBICAO/EXCLUSAO DO
PRINCIPAL
298 COOBRIGADO NAO INCLUIDO - PRINCIPAL NAO ENCONTRADO
299 COMPLEMENTO DO DOCUMENTO DO PRINCIPAL INVALIDO.
300 TIPO DE DOCUMENTO DO PRINCIPAL INVALIDO.
301 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-MUDOU-SE
302 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-END.INSUFIC.
303 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-NR.
INEXISTENTE
304 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-DESCONHECIDO
305 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-RECUSADO
306 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO - NAO
PROCURADO
307 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-AUSENTE
308 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-FALECIDO
309 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO
CORREIO-INFORM.P/PORT.
310 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-
END.N.CONHECIDO
311 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-CEP
INCORRETO
312 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-N
ESPECIFICADO
313 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-
C.P.INEXISTENTE
314 REGISTRO ESPECIAL - DEVOLUCAO COMUNICADO DO CORREIO-IMOVEL
INEXIST.
315 REGISTRO ESPECIAL - DEVIDO A DEVOLUCAO COMUNICADO DO CORREIO.
316 COMANDO INVALIDO
317 TIPO DE PESSOA INVALIDA
318 DOCUMENTO IGUAL A ZEROS
319 PESSOA JURIDICA COM DOCUMENTO DE PESSOA FISICA
320 BANCO DO CORRENTISTA NAO INFORMADO
321 BANCO DO CORRENTISTA NAO NUMERICO

575039736.doc
322 AGENCIA NAO INFORMADA

323 AGENCIA NAO NUMERICA
324 COMANDO INVALIDO
325 DATA DA INCLUSAO NO CCF INVALIDA
326 INCLUSAO NAO PERMITIDA P/ PESSOA '06'
327 QTDE. DE OCORRENCIAS NAO NUMERICA
328 ERRO NO ACESSO DA 'RSCONRE1'
329 ERRO NO ACESSO DA 'TS' GERADA PELA 'RSCONRE1'
330 NOME NAO EXISTE NO RESUMO P/ ALTERACAO
331 REGISTRO NAO ENCONTRADO PELA 'RSCONRE1'
332 TRANS.CONTRATADA DEVE ESTAR PREENCHIDA.
333 CODIGO DO RELEASE DEVE ESTAR PREENCHIDO.
334 CODIGO DO RELEASE NAO CONFERE.
335 CNPJ SOLIC.DEVE SER NUMERICO E > ZEROS.
336 DIGITO DO CNPJ SOLICITANTE NAO CONFERE.
337 MEIO DE ACESSO DIFERENTE DE 1 E 2.
338 FUNCAO DE CHAMADA DEVE ESTAR PREENCHIDO.
339 FUNCAO DE CHAMADA NAO CONFERE.
340 AREA RESERVADA DEVE CONTER DADOS.
341 OPCAO DE CONSULTA NAO CONFERE.
342 TIPO DE CHEQUE DIFERENTE DE 0, 1 OU 2.
343 CMC7 INICIAL DEVE SER NUMERICO E > ZEROS.
344 DIGITOS DO CMC7 INICIAL NAO CONFEREM.
345 CMC7 FINAL DEVE SER NUMERICO.
346 DIGITOS DO CMC7 FINAL NAO CONFEREM.
347 CMC7 INICIAL MAIOR QUE CMC7 FINAL.
348 BCO/AGE (CMC7 INI/FIN) DEVEM SER IGUAIS.
349 DDD DEVE SER NUMERICO E > ZEROS.
350 TELEFONE DEVE SER NUMERICO E > ZEROS.
351 ENCERRAMENTO DO HEADER DIFERENTE DE 'X'.
352 TIPO DE CHEQUE DEVE SER IGUAL A ZERO.
353 SE TIPO DE CHEQUE=0, NAO INFORME CHEQUES.
354 PROBLEMA NO RETORNO DA CONSULTA. LIGUE (0XX11) 5591.0137
356 DATA DO COMPROMISSO MAIOR QUE A ATUAL.
357 DATA DO COMPROMISSO INVALIDA.
358 VALOR DO COMPROMISSO NAO NUMERICO.
359 DDD DEVE SER NUMERICO.
360 TELEFONE DEVE SER NUMERICO.
361 MOTIVO DE BAIXA INVALIDO
362 INCLUSãO RECUSADA - DT MENOR QUE 90 DIAS CONFORME RES.NR 85
ANATEL.
363 QUANTIDADE DE DIAS NAO NUMERICO
364 TRANSACAO INDISPONIVEL NO MOMENTO. CONTATE A SERASA.
365 COD. BCO. AGE E CTA INFORMADOS ANTERIORMENTE PELO BANCO P/ESTE
DOC
366 EXISTEM REGISTROS DE CONSULTA PARA ESSE DOC. DE BCO, AGE, E
CONTA
367 COD. BANCO E AGENCIA INFORMADOS ANTERIORMENTE PELO BCO P/ESSE
DOC
368 EXISTEM REG. DE CONSULTAS PARA ESSE DOCUMENTO DE BANCO E AGENCIA
369 CODIGO DO BANCO INFORMADO ANTERIORMENTE PELO BANCO PARA ESSE DOC
370 EXISTEM REGISTROS DE CONSULTAS PARA ESSE DOCUMENTO DE BANCO
371 NAO EXISTEM REGISTROS DE CONSULTAS DESSA CONTA PARA ESSE

575039736.doc
DOCUMENTO
372 CLIENTE NAO ESTA AUTORIZADO A USAR A TRANSACAO
378 QUANTIDADE DE DIAS NAO INFORMADO.
379 TIPO DE CONSULTA INVALIDO
380 FLUXO DE CONTROLE DIFERENTE DE 'INI' E 'CON'
381 INCLUSAO REJEITADA - VLR CONSID.ELEVADO - INCLUIR PELO SISCONVEM
382 BANCO CEDENTE NAO INFORMADO.
383 BANCO CEDENTE INVALIDO.
384 BANCO CEDENTE NAO CADASTRADO.
385 DADOS DE CREDOR INVALIDOS PARA CLIENTE NAO-PARTICIPANTE DA
CUSTODIA
386 AGENCIA DO BANCO CEDENTE NAO INFORMADA.
387 AGENCIA DO BANCO CEDENTE INVALIDA.
388 CONTA-CORRENTE DO CREDOR NAO INFORMADA.
389 CONTA-CORRENTE DO CREDOR INVALIDA.
390 INCLUSAO RECUSADA - PARTICIPANTE COM LOGON BLOQUEADO
391 REGISTRO REJEITADO – INCONSISTENCIA NO HEADER
392 FALTA CODIGO CLIENTE NA RSREMESSA OU CODIGO NÃO TEM 5 CARACTERS
393 FALTA PROCNAME NA RSREMESSA OU PROCNAME NÃO TEM 8 CARACTERS
394 CNPJ NÃO CORRESPONDE AO CODIGO DE CLIENTE INFORMADO
395 NECESSARIO CADASTRAR O LOGON NA RELOGBAN
396 INCLUSAO REJEITADA-VLR.CONS.ELEVADO-NEGAT.PRIMARIA-
INCL.SISCONVEN
397 VLR.CONSID.ELEVADO-NEGAT.PRIMARIA-REDIGITAR O VALOR
398 REGISTRO GERAL INVALIDO
399 ORGAO EXPEDICAO DO RG EH OBRIGATORIO
400 DATA EXPEDICAO DO RG INVALIDA
401 NRO RAMAL DEVE SER NUMERICO E > QUE ZEROS
402 A I.F. &NRDOCIF DO ARQ. & DOC NÃO E PARTICIPANTE DA CENTRAL DE
RISCO
403 A “TAG” TPARQ NÃO PODE SER “N” PARA ARQ.&DOC &NRDOCIF DE &DTBASE
404 A “TAG” TPARQ NÃO PODE SER “T” PARA ARQ. &DOC &NRDOCIF DE &DTBA
405 ARQ. &DOC DA IF &NRDOCIF E DATA &DTBASE FOI REJEITADO POR ERRO
406 ARQ. &DOC DA IF &NRDOCIF DE DATA &DTBASE RECEPCIONADO E O.K.
407 A “TAG” TPARQ DO ARQ. &DOC CONTEM VALOR “%” INVALIDO
408 DATA &DTBASE DO ARQ. &DOC NÃO E POSTERIOR A ULTIMO FECHAM.
&FECHIF
409 DATA &BASE ARQ.&DOC ANTERIOR A 13 MESES DO ULT FECHAM. &FECHIF
410 TIPO DE REGISTRO “&TR” DO ARQ. &DOC DESCONHECIDO OU INVALIDO
411 TENTATIVA DE PROCESSAR DOC3030, MAS O ARQUIVO NÃO E DOC3030
412 DT.BASE &DTBASE DO ARQ. &DOC ANTERIOR A DATA DE IMPLANTACAO
&DTIMPL
413 DT.BASE &DTBASE DIFERE DA DT.IMPL. &DTIMPL DO ARQ. &DOC PRIM.
Exec.
414 DT.BASE &DTBASE ARQ. &DOC ANTERIOR A FECHAMENTO &DTFECH –
NR.PARTIC
415 DT.BASE &DTBASE ARQ.POSTERIOR MÊS SEGUINTE DA DTFECH. &DTFECH
416 DT.BASE &DTBASE DO ARQ. &DOC, NÃO PODE SER FUTURA. DT.HOJE &
DTATUAL
417 DATA BASE &DTBASE DO ARQ. &DOC INVALIDA
418 REPETICAO DO REGISTRO DE INFORMACOES AGREGADAS
419 REPETICAO DE REGISTRO DE VENCIMENTOS DE INFORMACOES AGREGADAS
420 CLASSIFICACAO DE RISCO DIFERENTE DE “HH” PARA COD.VENC.310 OU
320
421 MODALIDADE IGUAL A 15 PARA COD.VENC. 310 OU 320

575039736.doc
422 I.F. DO PARTICIPANTE &NRDOCIF DO ARQ. &DOC INVALIDA

423 TENTATIVA DE RODAR DOCTO 3020, MAS DOCUMENTO NÃO E 3020
424 DUPLICIDADE DO DOCTO DO CLIENTE E TIPO DOCTO DO CLIENTE
425 DIVERG. ENTRE TOT. CRED. DE VALOR SUPERIOR A R$ 5 MIL INFORMADOS
426 DIVERG.ENTRE TOT. CRED, DE VALOR SUP. A R$ 5 MIL, MESMA
CLASS.RISCO
427 DIVERG.ENTRE TOT. CRED., VALOR SUP.A R$ 5 MIL, MESMA MODALIDADE
428 DIVERG. ENTRE TOT. CRED., VALOR SUP. R$ 5 MIL, MESMO TIPO
CLIENTE
431 DOCTO 3030 ENVIADO INCORRETO, POR ISTO DOCTO 3020 NÃO ACEITO
432 DOCTO 3020 NÃO ACEITO. FAVOR ENVIAR DOCTO 3030 ANTES DO DOCTO
3020
433 REPETICAO DE DADOS DE OPERACOES CONSOLIDADAS
434 REPETICAO DE DADOS DE VENCIMENTOS DAS OPERACOES CONSOLIDADAS
435 COD.VENC. 310 OU 320 INVALIDO PARA MODALIDADE IGUAL A 15
436 REPETICAO DE DADOS DE OPERACOES INDIVIDUALIZADAS
437 REPETICAO DE DADOS DOS VENCIMENTOS DAS OPERACOES
INDIVIDUALIZADAS
438 REPETICAO DE DADOS DE GARANTIAS NÃO FIDEJUSSORIAS
439 DUPLICIDADE NAS INFORMACOES DE CONGLOMERADOS
440 INCORRETO RODAR DOCTO 3020. DOCTO 3030 FOI ENVIADO, MAS
INCORRETO
441 INCORRETO RODAR DOCTO 3020, POIS DEVE SER ENVIADO DOCTO 3030
ANTES
442 REPETICAO DE DADOS DE GARANTIAS FIDEJUSSORIAS
443 EXCLUSAO POR CONTESTACAO / DECLARACAO DO INTERESSADO
444 TS DE DOCUMENTOS COM MAIS LINHAS DO QUE O PREVISTO
445 OPCAO DE CONSULTA DIFERENTE DE CH,PF,CP E PE
446 VENCIMENTO NÃO PODE SER MENOR QUE HOJE
447 ERRO NO ACESSO AO MODULO RECHEQUE ONLINE
448 ERRO NO ACESSO AO MODULO RECONSUX
449 ERRO NA LEITURA DA TS DO RECONSUX
450 ERRO NO ACESSO AO MODULO REGISTRO DE CONSULTAS
451 ERRO NO ACESSO AO MODULO RECONSUB
452 ERRO NA LEITURA DA TS DO RECONSUB
453 ERRO NO ACESSO AO MODULO RSGESTAO
454 ERRO NO ACESSO AO MODULO TECONTEL
455 ERRO NA LEITURA DA TS DOCUMENTO
456 ERRO NA LEITURA DA TS CHEQUES
457 ERRO NA LEITURA DA TS GESTAO
458 ERRO NO ACESSO AO MODULO GRCONUSE
459 ERRO NO ACESSO AO MODULO REINCCON
460 ERRO NO ACESSO AO MODULO SMGCCINC
461 ERRO NO ACESSO AO MODULO REINCCLI
462 OPCAO DE CONSULTA PERSONALIZADA SEM SOLICITACAO
463 ERRO NO ACESSO AO MODULO RELOGBAR
464 NRO MAXIMO DE CHEQUES PARA CONSULTA EH 24
465 DATA DO CANCELAMENTO DO CONTRATO NÃO INFORMADA
466 EXCLUSAO POR FALTA DE DOCUMENTOS DA DIVIDA
490 FALTAM DADOS CADASTRAIS DO CREDOR DA DÍVIDA
491 MUNICIPIO NÃO CORRESPONDE AO CEP E/OU UF INFORMADO
492 INCLUSÃO CONDICIONADA À APRESENTAÇÃO DE DOCUMENTAÇÃO DA DÍVIDA
600 SISTEMA INATIVO
900 ERRO DE ACESSO A TEX26

575039736.doc
999 ERRO DESCONHECIDO

575039736.doc
5. Interfaces de saída
5.1. Arquivos de saída (SPC) (Envio ao Bureau de credito)
Layout - Header
Nome e caminho para o arquivo de SPCSSSSSSE
saída
( ) Outros: ______________________________________________
campo
1.1.1 Associado NUMC 8 0 “00300812” ou “00339308 Código do contrato identificador da
“ TIM no SPC
1.1.2 Constante NUMC 10 0 “0000000000” Código constante
1.1.4 Constante NUMC 7 0 “remessa” Identificação de remessa”
1.1.5 Informante CHAR 55 0 “TIM BRASIL” Nome do Informante
1.1.6 Controle CHAR 8 0 Número da remessa do arquivo
sequencial, incrementando de 1 a
cada novo movimento (preencher
com zeros à esquerda)
1.1.8 Versão NUMC 2 0 “03” Identificação da versão do arquivo
Layout - Detalhe
Nome e caminho para o arquivo de
saída
( x ) Acrescentar no final (“append”)
( ) Outros: ______________________________________________
campo
NOME
1.2.1 Associado NUMC 8 0 “00300812” ou Código do contrato identificador da TIM no

“00339308 “ SPC
1.2.2 Constante NUMC 1 0 “1” “1”
1.2.5 Constante NUMC 1 0 “A” “A”
1.2.6 Constante NUMC 2 0 “10” “10”

575039736.doc
1.2.7 Documento CHAR 20 0 Número do documento principal (CPF/CNPJ)

Devera ser preenchido:
‘CPF’ + nº do CPF do cliente+ brancos a
direita.
Ou
‘CNPJ’ + nº do CNPJ do cliente+ brancos a
direita
1.2.8 Documento CHAR 20 0 Blank
1.2.9 Documento CHAR 20 0 Blank
1.2.10 Nome CHAR 50 0 Nome do devedor (cliente)
Data de nascimento “DDMMAAAA” ou
1.2.12 Data DATA 8 0
“00000000”
1.2.13 Nome CHAR 40 0 Blank
1.2.15 Constante NUMC 6 0 “000000”
1.2.16 Naturalidade CHAR 20 0 Blank
1.2.17 Unidade da Federação CHAR 2 0 Blank
1.2.19 Código de retorno CHAR 20 0 Blank(Sera preenchido no arquivo de retorno)
ENDEREÇO
1.2.20 Associado NUMC 8 0 “00300812” ou Código do contrato identificador da TIM no
“00339308 “ SPC.
1.2.21 Constante NUMC 1 0 “1” “1”
1.2.24 Constante NUMC 1 0 “B” “B”
1.2.25 Constante NUMC 2 0 “10” “10”
1.2.26 Documento CHAR 20 0 Número do documento principal (CPF)
1.2.27 Tipo de Registro NUMC 1 0 “1” Tipo de Registro:
“1” = Endereço do devedor (cliente)
Informar tipo e nome do logradouro, número
1.2.28 Endereço CHAR 50 0
e complemento (apt, bloco, etc.)
1.2.30 CEP NUMC 8 0 CEP
1.2.31 Cidade CHAR 20 0 Cidade
1.2.32 UF CHAR 2 0 Sigla da Unidade da Federação
1.2.33 Telefone NUMC 20 0 Número do telefone
1.2.34 Constante CHAR 71 0 Blank
1.2.35 Código de retorno CHAR 20 0 Blank(Sera preenchido no arquivo de retorno)
OCORRÊNCIA DO SCPC
Associado NUMC 8 0 “00300812” ou Código do contrato identificador da TIM no
“00339308 “ SPC
1.2.36 00339308: TIM NORDESTE
1.2.37 Constante NUMC 1 0 “1” “1”
1.2.38 Sequencia NUMC 5 0 Número de Sequência
1.2.39 Constante NUMC 1 0 “1” “1”
1.2.40 Constante NUMC 1 0 “1” “1”
Código de operação: Inclusão “10”
Operação NUMC 2 0 “10” ou “20”
1.2.41 Exclusão “20”
Documento CHAR 20 0 Documento principal (CPF+número+brancos a
1.2.42 direita)
1.2.43 Data DATA 8 0 Formato: ddmmaaaa Data do vencimento da fatura
1.2.44 Ocorrência NUMC 2 0 Tipo de ocorrência (RG)
1.2.45 Contrato NUMC 22 0 Número da fatura (nº referencia)
1.2.46 Avalista CHAR 20 0 Blank Blank
1.2.47 Valor NUMC 11 0 Valor de débito (dívida)
1.2.48 Documento de Débito CHAR 2 0 “CT” Contrato = “CT”

575039736.doc
1.2.49 Reservado CHAR 17 0 Blank Blank

1.2.50 Constante CHAR 1 0 “N” “N”
1.2.51 Constante NUMC 2 0 “00” “00”
Reservado CHAR 15 0 Blank Customer_id (8 posições) + Código Febraban
1.2.53 (4 posições)
1.2.54 Código de retorno CHAR 20 0 Blank Blank(Sera preenchido no arquivo de retorno)
Layout - Trailler
Nome e caminho para o arquivo de
saída
( x ) Acrescentar no final (“append”)
( ) Outros: ______________________________________________
campo
“00339308 “ no SPC
1.3.2 Constante NUMC 10 0 “9999999999” “9999999999”
5.2. Arquivos de saída (SERASA) (Envio ao Bureau de credito)
Layout - Header
( X ) Acrescentar no final (“append”) ???
( ) Outros:
______________________________________________
campo
2.1.1 Codigo do Registro NUMC 1 0 “0” Código do registro = “0” (zero)
Número do CNPJ da instituição
2.1.2 CNPJ NUMC 9 0 informante(sem virgulas) ajustado à
direita e preenchido com zeros a esquerda
2.1.3 Data da geração DATA 8 0 Data da geração do arquivo (AAAAMMDD)
Número de DDD do tel. de contato da
2.1.4 DDD NUMC 4 0
instiuição informante (TIM)
Número do tel. de contato da instiuição
2.1.5 Telefone NUMC 8 0
informante (TIM)
Número de ramal do telefone de contato
2.1.6 Ramal NUMC 4 0
da instiuição informante (TIM)
Nome do contato da instituição informante
2.1.7 Nome CHAR 70 0
(TIM)
Identificação do arquivo fixo “SERASA-
2.1.8 Identificação NUMC 15 0
CONVEM 04”
Número de remessa 6 0 Número da remessa do arquivo
2.1.9 sequencial, incrementando de 1 a cada
novo movimento
2.1.10 Código de envio CHAR 1 0 “E” ( ENTRADA) Código de envio de arquivo
Constante CHAR 4 0 ‘0001’ Diferencial de remessa caso a instituição
2.1.11 informante tenha necessidade de enviar
mais de uma remessa no mesmo dia.

575039736.doc
2.1.13 Codigo de erro CHAR 60 0 Blank Blank
2.1.14
Seqüencial NUMC 7 0 “0000001” Sequencial de registro do arquivo
(0000001 para header)
Layout - Detalhe
Nome e caminho para o arquivo de saída
( ) Outros:
______________________________________________
campo
2.2.1 Código do Registro NUMC 1 0 “1” Código do registro = “1”
Código da operação =
I – inclusão
Operação CHAR 1 0
E – exclusão
2.2.2
CNPJ CHAR 6 0 Filial e dígito do CNPJ da
2.2.3 contratante
2.2.4 Data de vencimento DATA 8 0 Data vencimento (AAAAMMDD)
Data do término DATA 8 0 Data do término do contrato
(AAAAMMDD)
2.2.5
2.2.6 Natureza CHAR 3 0 ‘00’ Cód. natureza operação = “00”
2.2.7 Praça CHAR 4 0 Blank Cód. praça Embratel
Tipo de pessoa do principal:
Tipo Pessoa CHAR 1 0 “F” ou “J” Física = “F”
2.2.8 Jurídica = “J”
Tipo do primeiro doc. do principal:
Tipo doc 1 NUMC 1 0 “1” ou “2” 1 - CNPJ
2.2.9 2 - CPF
Primeiro doc. do principal:
CPF completo – base + dígito ou
CNPJ completo – base + filial +
Primeiro doc CHAR 15 0
dígito.
(ajustado à direita e preenchido
2.2.10 com zeros a esquerda)

575039736.doc
blank (para os casos de Motivo de baixa:

inclusão) Blank – Para casos de inclusão
Casos de exclusão: Codigo de motivo da exclusão para

01 – PAGAMENTO DA DÍVIDA os casos de exclusão.
02 – RENEGOCIAÇÃO DA DÍVIDA
03 – INCLUSÃO INDEVIDA
04 – ORDEM JUDICIAL
05 – CORREÇÃO DE ENDEREÇO
06 – ATUALIZAÇÃO DO VALOR –
VALORIZAÇÃO
07 – ATUALIZAÇÃO DO VALOR –
PAGAMENTO PARCIAL
08 – ATUALIZAÇÃO DE DATA
09 – CORREÇÃO DO NOME
10 – CORREÇÃO DO NÚMERO DO
CONTRATO
11 – CORREÇÃO DE VÁRIOS
DADOS ( VALOR +DATAS+ ETC)
Motivo baixa CHAR 2 0 12 – BAIXA POR PERDA DE
CONTROLE DA BASE
13 – MOTIVO NÃO IDENTIFICADO
OS MOTIVOS ABAIXO SÃO DE
USO INTERNO DO SISTEMA DA
SERASA, PORTANTO NÃO
DEVEM SER USADOS.
00 – MOTIVO ANTES DA
IMPLANTAÇÃO ( PASSADO )
95 – COMUNICADO DEVOLVIDO
DO CORREIO
96 – DETERMINAÇÃO JUDICIAL
97 – DECURSO DO PRAZO
99 – MOTIVO DA BAIXA NÃO
INFORMADO
2.2.11
Tipo doc 2 CHAR 1 0 blank Tipo do segundo documento do
principal:
2.2.12 Blank
Segundo doc CHAR 15 0 blank Segundo documento do principal:
2.2.13 Blank
UF
CHAR 2 0 blank UF:
2.2.14 Blank
2.2.15 Constante CHAR 1 0 blank Blank
2.2.22 Nome do devedor CHAR 70 0 Nome do devedor (cliente)
2.2.23 Data de nascimento CHAR 8 0 blank Data de nascimento (AAAAMMDD)
Nome do pai DATA 70 0 blank Nome do pai.
2.2.24 Blank
Nome da mãe CHAR
70 0 blank Nome do mãe.
2.2.25 Blank
2.2.26 Endereço CHAR 45 0 Endereço completo
2.2.28 Município CHAR 25 0 Município - Cidade
2.2.29 UF CHAR 2 0 Sigla UF
2.2.30 CEP CHAR 8 0 CEP
2.2.31 Montante NUMC 15 0 Valor montante com dos decimas

575039736.doc
Fatura NUMC 16 2 GSM + ID do centro de custo + No

fatura
Onde:
- GSM é uma string com 3
caracteres
- ID do centro de custo é o ID do
centro de custo do cliente
preenchido com zeros a esquerda
até que tenha 3 caracteres
- Número da fatura é o número de
referência externa da fatura,
completando com zeros a esquerda
até que tenha 10 posições
Exemplo:
2.2.32 GSM0160000000735
2.2.33 Nosso Número NUMC 9 0 blank Blank
Constante CHAR 25 0 COMPLEMENTO DO ENDEREÇO
DO DEVEDOR - USAR SOMENTE
QUANDO O CAMPO 2.2.26
(ENDEREÇO COMPLETO ) NÃO
FOR SUFICIENTE.
Caso contrario 25 espaços
2.2.34 em branco.
DDD NUMC 4 0 Blank DDD do telefone do devedor
(cliente):
2.2.35 Blank
Telefone NUMC 9 0 Blank Número do telefone do devedor
(cliente):
2.2.36 Blank
2.2.37 Constante DATA 8 0 Blank Blank
2.2.40 Codigo de erro CHAR 60 0 Blank Blank
Seqüencial NUMC 7 0 Sequência do registro no arquivo:
Preencher com o número
sequencial do arquivo (o header
terá o número sequencial igual a 1,
para o primeiro registro do detalhe
o número seqüencial deve ser igual
a 2, incrementando de 1 a cada
registro criado). Completar com
zeros a esquerda até ter 7
2.2.41 posições.
Layout - Trailler
Nome e caminho para o arquivo de saída
( X ) Acrescentar no final (“append”)
( ) Outros:
______________________________________________
campo
2.3.1 Código do registro NUMC 1 0 “9” Código de registro = “9” (trailler)
2.3.3 Codigo de erro NUMC 60 0 Blank Blank

575039736.doc
Seqüencial NUMC 7 0 Sequência do registro no arquivo:

Preencher com o número sequencial do
arquivo (o header terá o número
sequencial igual a 1, para o primeiro
2.3.4
registro do detalhe o número seqüencial
deve ser igual a 2 e assim por diante).
Completar com zeros a esquerda até ter
7 posições.
5.3. Procedimentos em caso de erros na execução da interface

Responsável pela interface N/A
em caso de erro no
processamento
Agendamento ( ) Periódico (“Job”) ( ) Manual
Impactos da não execução N/A
da interface
Procedimentos em caso de N/A
erros detectados

575039736.doc
6. Relatórios
6.1. Definição do layout da tela de seleção
N/A
6.2. Definição dos parâmetros de seleção

Parâmetro Tipo Referencia Valor inicial Consistência
N/A N/A N/A N/A N/A
6.3. Definição do layout do relatório

N/A
6.4. Chave de ordenação para visualização final do relatório

N/A

575039736.doc
7. Programas Online
7.1. Definição do layout das telas
7.2. Definição das consistências a efetuar

Item Campo da tela Atributo Descrição
7.3. Definição das Funcionalidades
8. Formulários / SAPSCRIPT
8.1. Programa extrator

Programa extrator de informações N/A
8.2. Desenho do formulário desejado

N/A
8.3. Modelo de formulário padrão

Nome do Formulário Padrão N/A
Caminho no guia de implementação (IMG)
N/A
Transação N/A

575039736.doc
9. Outros Desenvolvimentos
9.1. Implementação de ampliações SAP (“enhancements”)
Ampliação SAP Componente Tipo Ação

N/A N/A N/A N/A
9.2. Modificação de objeto standard SAP

Objeto standard SAP Tipo do Objeto Descrição da alteração
N/A N/A N/A

575039736.doc
10. Requerimentos para testes
10.1. Condições de testes funcionais
Teste # Condição Resultado esperado

01 Colocar uma fatura no nivel de Fatura inserida na tabela de control
cobrança negativação com divida Z_gerenciamento de negativação com
maior a 10R$. Rodar o programa de campo data da seleção preenchido,
negativação. flag a incluir ativado.
02 Colocar uma fatura de um cliente de Fatura inserida na tabela de control
Rio de janeiro no nivel de cobrança Z_gerenciamento de negativação com
negativação com divida maior a 10R$. campo data da seleção preenchido,
Criar uma restricão para Rio de flag a incluir não ativado, flag
Janeiro. Rodar o programa de Restrição UF ativado.
negativação
03 Para a fatura do teste 02 trocar a data Registro ja existente na tabela de
de fim da restrição de Rio de Janeiro control Z_gerenciamento de
para um dia antes da execução do negativação, com campo data da
teste . Rodar o programa de seleção preenchido, flag a incluir
negativação. ativado, flag restrição UF branco.
10.2. Condições de testes técnicos
Teste # Condição Resultado esperado

N/A N/A N/A
10.3. Considerações para testes / Dependências

N/A

575039736.doc
11. Especificação Técnica (Uso da Equipe ABAP)
11.1. Dependências
11.2. Riscos envolvidos no processo
11.3. Informações de desenvolvimento
11.3.1. Classe de desenvolvimento (pacote)
11.3.2. Classe de mensagem
11.3.3. Nome do programa
11.3.4. Transação
11.3.5. Request
11.4. Descrição da solução técnica
11.5. Desenvolvimento tipo “report”

 Definição da tela de seleção
 INITIALIZATION.
 START-OF-SELECTION.
 END-OF-SELECTION.
 AT SELECTION-SCREEN.
 TOP-OF-PAGE.
 END-OF-PAGE.
 AT USER-COMMAND.
 (Outros eventos)
11.6. Desenvolvimento tipo interface

 Endereço do arquivo
 Nome do arquivo
 Sistema de origem
 Sistema de destino

575039736.doc
 Tipo de mensagem
 Tipo Básico IDOC
 Extensão
 Modelo de distribuição
 No. Parceiro
 Tipo de parceiro
 Código de processo entrada
 Controle de mensagens
 Mapeamento dos dados
 Definição da tela de seleção
 INITIALIZATION.
 START-OF-SELECTION.
 END-OF-SELECTION.
 AT SELECTION-SCREEN.
 TOP-OF-PAGE.
 END-OF-PAGE.
 AT USER-COMMAND.
 (Outros eventos)
11.7. Desenvolvimento tipo “user-exit”

 Nome da “user-exit”
 Nome do Projeto
 Mecanismo de disparo (“trigger”)
 Dados de entrada
 Processamento
 Dados de saída

575039736.doc
11.8. Desenvolvimento tipo field-exit

 Nome da “field-exit”
 Nome do programa Standard SAP e Número da tela
 Mecanismo de disparo (“trigger”)
 Dados de entrada
 Processamento
 Dados de saída
12. Apêndice
12.1. Documentação adicional

CB 028 3 - Programa Customizado de Negativaçao - v37

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CB 028 3 - Programa Customizado de Negativaçao - v37

Enviado por

Direitos autorais:

Formatos disponíveis

575039736.

575039736.doc Criado em 13/05/2008 Página: 1 de 77

Validação de dados na tabela FKKMAKO (evento

Validação do campo MSTYP para preenchimento na tabela de

37 12/05/2008 Gustavo Freire Validação de No-Dunning (Cliente e/ou Fatura), no processo de

575039736.doc Criado em 13/05/2008 Página: 2 de 77

575039736.doc Criado em 13/05/2008 Página: 3 de 77

3. Detalhamento da Especificação Funcional

3.1. Processos relacionados

3.2. Regras de negócio

Premissas e regras de negócio.

- Inclusão de clientes para Negativação

- Exclusão de clientes da Negativação

A exclusão sera efetuada nos casos:

- Controle do resultado da negativação

575039736.doc Criado em 13/05/2008 Página: 4 de 77

3.4. Volume de transações

575039736.doc Criado em 13/05/2008 Página: 5 de 77

3.5. Parametrização do sistema para atividades em massa

3.5.1. Criar nova transação

3.5.2. Criar modulo de função

3.5.3. Criar Evento

575039736.doc Criado em 13/05/2008 Página: 6 de 77

3.5.4. Criar Layout para transação

575039736.doc Criado em 13/05/2008 Página: 7 de 77

3.5.5. Criar Nova atividade em massa

3.6. Fluxograma do processo

3.7. Descrição Funcional Detalhada

575039736.doc Criado em 13/05/2008 Página: 8 de 77

6 – Fazer a distribuição de faturas por Bureau de Crédito

Principais tabelas utilizadas:

3.7.1. Fluxo Detalhado

575039736.doc Criado em 13/05/2008 Página: 9 de 77

575039736.doc Criado em 13/05/2008 Página: 10 de 77

2 – Identificação das faturas que deverão ser excluidas da negativação.

575039736.doc Criado em 13/05/2008 Página: 11 de 77

3- Identificação de faturas marcadas para inclusão/exclusão de negativação

4 - Especificação dos campos dos arquivos para os Bureaus de credito

575039736.doc Criado em 13/05/2008 Página: 12 de 77

5 - Recebimento do retorno com resultado do envio dos arquivos de Bureaus de credito

575039736.doc Criado em 13/05/2008 Página: 13 de 77

3.7.2 - Descrição do Processo-Fluxos Principais

O processo de Negativação terá quatro fluxos principais:

575039736.doc Criado em 13/05/2008 Página: 14 de 77

Nota: Atualmente o mesmo programa extrai os dados, processa e cria o arquivo.

3.8. Parte 1: Criação Modulo de Função para atividade de cobrança FPVB

575039736.doc Criado em 13/05/2008 Página: 15 de 77

1.1. Verificar existência de registro na tabela ZTCBGEREN_NEGATI com as seguintes condições :

575039736.doc Criado em 13/05/2008 Página: 16 de 77

 ZTCBGEREN_NEGATI - ZZDT_SELECAO = T_FKKMAZE-MDRKD.

575039736.doc Criado em 13/05/2008 Página: 17 de 77

3.9. Programa 1: FM para Atividade de Negativação Z_RMCA_NEGATIVACAO

3.9.2 – Sub-modulo 1- Negativação e positivação

1: Seleçoes dados das tabelas

575039736.doc Criado em 13/05/2008 Página: 18 de 77

2: Validação de cliente em Negativação

 Step 1 – Processamento de novas faturas inseridas na tabela ZTCBGEREN_NEGATI (da FPVB)

3. Identificação de restrições de envio para negativação, ativas. (Tabelas ZTCBRESTR_NEGATI e

3.1 Identificação de restrição para a UF do cliente da fatura selecionada para negativação.

575039736.doc Criado em 13/05/2008 Página: 19 de 77

4. Identificação de valor a negativar.

4.1 – Identificação de itens da fatura selecionada para negativação.