GRC guia Enviar Lote Incorreto

[Former Member]

Boa tarde,

Devido alguns problemas ( WEB service não acessível, Erro PI , etc. ) o sistema disponibiliza o lote na guia Enviar Lote Incorreto no monitor do GRC.

Para enviar ao SEFAZ é necessário uma ação manual, selecionar o lote e reiniciar.

Tem algum programa que seleciona esses lotes e encaminha novamente automaticamente sem precisar de uma ação manual ?

Gostaria de poder schedular um job que busque esses lotes parados nessa guia e reinicialize.

A informação dos lotes ficam nas tabelas /XNFE/BATSTA e /XNFE/BAT_HIST.

Terei que implementar algo Z para essa solicitação ?

Alguém possui esse serviço rodando no seu ambiente ?

Muito obrigada!

Cris.

[Former Member · Accepted solution]

Boas noticias!

Finalmente consegui rodar meu Z e executar/autorizar os lotes incorretos.

Disponibilizado a lógica utilizada no http://wiki.sdn.sap.com/wiki/display/Snippets/JOBLOTEINCORRETO-RESEND

Muuuuuuuiiiiiito obrigada pelo retorno de todos e todo o empenho em ajudar do Fernando e Carlos.

Abs,

Cris.

[former_member193386 · Accepted solution]

EDITADO PELA MODERACAO.

Edited by: Henrique Pinto on May 18, 2010 6:14 PM

[henrique_pinto · Accepted solution]

Ficar pedindo pontos no forum é contra as regras de comportamento dos foruns da SAP Community Network.

Tem que partir de cada um, assim como quem ajuda tem que fazê-lo sem esperar retorno.

Abs,

Henrique.

[henrique_pinto · Accepted solution]

Cristiane,

boa iniciativa de compartilhar o codigo.

Vc pode incluir link pro seu codigo no wiki central de NFE (https://wiki.sdn.sap.com/wiki/display/BPX/SAP+NFE).

Inclua na secao Wikis, seguindo os exemplos q jah tem por lá.

Abs,

Henrique.

[henrique_pinto · Accepted solution]

Ninguem incluiu o link do codigo no wiki do SAP NFE.

Eu poderia faze-lo, mas preferia que quem criou o conteudo (ou outra pessoa da comunidade) o fizesse, pra cultivar a cultura no pessoal.

Abs,

Henrique.

[former_member193386 · Accepted solution]

cristiane, assim que vc criar o prog poderia criar o wiki com o fonte?

[henrique_pinto · Accepted solution]

Acho que ela já pôs o fonte em http://wiki.sdn.sap.com/wiki/display/Snippets/JOBLOTEINCORRETO-RESEND

Abs,

Henrique.

[henrique_pinto · Accepted solution]

Ops,

eu linkei com o nome antigo e depois alterei o titulo, assim o link quebra e ninguem acha mais...

O link correto agora é: http://wiki.sdn.sap.com/wiki/display/Snippets/Samplecodeforautomaticresendofbatcheswithcommunication+errors

Alternativamente, o link curto é http://wiki.sdn.sap.com/wiki/x/IoVRCw

Mas eu jah linkei o wiki lah no Wiki central de SAP NFE.

Abs,

Henrique.

[Former Member]

Resumindo, a função /XNFE/BATCH_REQUEST não serve pois esse lote nem foi enviado ainda ao SEFAZ certo !

A função correta é a /XNFE/005a_BATCH_NFE_OUT inserida na outra fonte do programa.

Voltei a questão anterior...Gostaria de ver o que o SAP realmente preenche nas tabelas quando passa pela view VI_BATCH método ON_FUNCTION_SEND quando executo o lote via GRC para poder comparar com o que eu estou passando nessas mesmas funções e então encontrar o problema.

A questão é, não conheço web dynpro, tenho como debugar ? E como faço isso ?

Como faço para compartilhar a fonte do meu Z para vcs analisarem ?

Muito, muito obrigada e desculpe todo esse transtorno !

[former_member193386]

cristiane

creio que nao tem muito a mais que fazer, basta no final ao inves de vc chamar o BATCH_REQUEST vc chamar o /XNFE/005A_BATCH_NFE_OUT, nesse momento vc vai ter quase todos os dados que precisa menos o IT_NFE que vc pode obter usando parte do codigo anterior seu

para facilitar basta adicionar esse codigo a seguir e guardar os dados em uma tabela interna e passa-lo no parametro IT_NFE

SELECT * FROM /xnfe/xml INTO TABLE lt_xml
             FOR ALL ENTRIES IN it_batch
             WHERE id      = it_batch-id
               AND versnum = it_batch-versnum
               AND type    = '1'
               AND tpemis  = it_batch-tpemis.

Edited by: Carlos Rodrigo Pereira on May 18, 2010 7:36 PM

[former_member182114]

Bom dia Carlos,

O ponto para compartilhar códigos é http://wiki.sdn.sap.com/wiki/display/Snippets/CommunityCodeGallery, clique em Add Page.

@Cristiane,

Transtorno só se você não conseguir. Rsss

Como a estamos falando de desenvolvimento novo às vezes caimos no jeito de fazer a coisa (toque pessoal), daí poderíamos discutir por eras e uma "solução única" não será atingida pois existem várias formas de se fazer e chegar ao resultado. Estou pontuando itens que afetaram clientes no passado e foram investigados, corrigidos e adicionados ao standard.

Abraços, Fernando Da Ró

[former_member193386]

Cristiane

Aproveite e adicione o seu fonte ali

[Former Member]

Quando simulo o status do serviço fora /XNFE/SRVST-ERROR_STATUS = 70 os campos da tabela /XNFE/BAT_HIST ficam

assim :

BATCHID 1191

ERTIME 20.100.518.12

BATSTAT 01

ERROR STATUS 38

ERNAME BASIS

ERROR DESCRIP

Voltando o serviço e rodando o programa que criei, eu duplico essa linha alterando ERTIME, ERROR_STATUS = space e o ERNAME.

Nova linha :

BATCHID 1191

ERTIME 20.100.518.133.95

BATSTAT 01

ERROR STATUS

ERNAME ABAP

ERROR DESCRIP

Executo a função /XNFE/BATCH_REQUEST e o sistema cria uma nova linha nessa tabela :

BATCHID 1191

ERTIME 20.100.518.134.121,6350000

BATSTAT 04

ERROR STATUS

ERNAME ABAP

E permanece assim...Não tenho retorno desse lote!

Fica com triangulo amarelo no GRC.

[former_member193386]

uma outra sugestao, para mim funcionou sempre simplesmente limpando o ERROR_STATUS da ultima linha do BAT_HIST, no seu caso, a que esta com o ERROR_STATUS '38', tanta fazer dessa maneira.

[Former Member]

Bom dia ,

Muito obrigada pelo retorno de todos.

Optei em trabalhar com as tabelas conforme sugestão do Carlos.

Lógica do programa :

1-Seleciono na tabela /XNFE/BATSTA os lotes conforme período / uf / process = 'X'

2-Pela função /XNFE/BAT_HIST_READ_AKTUAL busco a última atualização desse lote na tabela /XNFE/BAT_HIST

3-Conforme o lote e o campo status_error valido se lote possui erro de Batch ( exemplo 38 )

4-Seleciono o status do serviço do estado em questão se o.k. - tabela /XNFE/SRVSTA status 107 - Serviço em operação

5-Valido se lote não está sendo processado função ENQUEUE_/XNFE/ENQ_BATSTA/DEQUEUE_/XNFE/ENQ_BATSTA

6-Insiro nova linha na tabela /XNFE/BAT_HIST alterando os campos ERTIME-data/hora atual ERROR_STATUS = space ERNAME = sy-uname

7-Chamo função '/XNFE/BATCH_REQUEST' passando as informações da tabela /XNFE/BATSTA do lote duplicado

O programa roda função e não retorna com erro.

Porém o lote não é processado corretamente ainda

Na tabela /XNFE/BATSTA ele fica agora com estas informações :

BATCHID 1191

CUF 42

UF EMIT SC

TPAMB 2

TPEMIS 1

STATCODE

CREATETMPL 20.100.518.125.647,2300000

QUANTNFE 1

BATCHSIZE 5.897

SENDTMPL 20.100.518.125.647,2300000

REQTMPL 0,0000000

RECEIPTNO 0

MAXRETRIES 50

RETRIES 1

WAIT 30

RECTMPL 0,0000000

RECDATE

RECTIME 00:00:00

TZONE

TMED 0

PROCESS R

No GRC está com Status do Lote 04 - Solicitação enviada.

Tenho que executar + alguma função ?

Obrigada,

Cris.

[former_member193386]

Nao entendi bem, vc nao precisaria duplicar o lote, somente a linha na /XNFE/BATHIST, o lote esta com o STATUS 04 de enviado ?

[former_member193386]

Cristiane

creio que podemos mudar algumas coisas no processo que vc descreveu, primeiro o passo 2 é desnecessário, nao precisa que vc obtenha o ultimo registro da BAT_HIST dessa maneira

o passo 5 é desnecessario tbem, pq, o lote nao vai estar tendo intervencao humana já que ele será tratado automaticamente portanto nao faz sentido vc estar verificando se ele nao vai estar sendo processado

no passo 6, o campo ERROR_STATUS tem que estar com nulo, nao com espaco em branco como havia colocado erroneamente

[former_member182114]

Bom dia Pessoal,

Eita negócio enrolado... Vamos tentar separar as coisas e ir pra frente:

o passo 5 é desnecessario tbem, pq, o lote nao vai estar tendo intervencao humana já que ele será tratado automaticamente portanto nao faz sentido vc estar verificando se ele nao vai estar sendo processado

@Carlos, este passo é importante. O botão ainda está na tela e algum administrador pode ser "convocado" a agilizar. E duas versões deste mesmo report de restart podem ser executadas simultaneamente. O lock evita o problema em ambos os casos.

Executo a função /XNFE/BATCH_REQUEST e o sistema cria uma nova linha nessa tabela :

@Cristiane, o lote ainda não foi enviado para a Sefaz nenhuma vez então este passo de BATCH_REQUEST é apenas quando se tem já foi enviado (status 03), como você estava no 01 tem que fazer o envio.

Siga o VI_BATCH->ON_FUNCTION_SEND mesmo, você ainda tem aquela versão? Debugou? Você realmente parecia estar bem perto com aquele código.

Observação: Para restart de consulta de lote o código seria VI_BATCH->ON_FUNCTION_RECHECK.

Atenciosamente, Fernando Da Ró

[former_member193386]

fernando

Se caso alguem tentar enviar o lote antes do processo automatico provavelmente o status do lote nao será o mesmo que estamos tentando processar, ou seja, ele nao estara disponivel no menu ou na selecao que estamos fazendo para o relatorio.

quanto o status do envio do lote, se o mesmo esta com status 01 ele nao foi realmente enviado ai sefaz, mas vale a pena, para prosseguir com os testes garantir se ele REALMENTE nao foi enviado consultando a chave da NFe no sefaz.

existe tbem a funcao /XNFE/BATCH_REQUEST que pode ser usar em contrapartida do relatorio que verifica o status no sefaz ( se o lote já foi enviado ) ou a /XNFE/005a_BATCH_NFE_OUT ( dependendo da versao que vc estiver usando ) para enviar o lote ao sefaz como vc estava fazendo no seu programa anteriormente

Edited by: Carlos Rodrigo Pereira on May 18, 2010 6:40 PM

[former_member182114]

Cristiane, dê algum feedback... enquanto isso eu e o Carlos seguimos na thread.. rsss

Se caso alguem tentar enviar o lote antes do processo automatico provavelmente o status do lote nao será o mesmo que estamos tentando processar, ou seja, ele nao estara disponivel no menu ou na selecao que estamos fazendo para o relatorio.

Sim, é um caso raro só acontece por exemplo se já estava na minha tela aguardando ao apertar o botão, daí o job roda e "leva" o lote.

A função /XNFE/BATCH_REQUEST é chamada pelo report /XNFE/BATCH_REQUEST que é o segundo step do programa /xnfe/process_reports.

No SCN tem uma parte que serve para compartilhar códigos, pode ser uma opção para agilizar esta thread. O que acham?

Atenciosamente, Fernando Da Ró

[former_member193386]

pode ser sim, passe a instrucao para que agilizemos

[Former Member]

Bom dia,

Fui verificar a lógica de processamento da web dynpro do Lote. Confesso que nunca trabalhei com web dynpro e encontrei dificultades em montar meu Z para reprocessar esses lotes.

Estou focando somente nos lotes com erros tipo 38 - Lote: Web Service não acessível que ficam na guia Enviar lote incorreto.

Visão : VI_BATCH

Método : ON_FUNCTION_SEND

Criei um programa com a lógica de busca e envio desses lotes.

Abaixo programa para verificação.

Porém após sua execução, toda nfe fica rejeitada pelo SEFAZ 239 - Rejeição Cabeçalho versão arquivo XML

O lote fica com status 03 - Enviado as autoridades com status do erro 70 - Erro processamento do lote.

O ERP recebe essa rejeição.

Re-encaminho essa mesma nota, é gerado um novo lote e esse é atualizado normalmente.

Com certeza está faltando algo no meu Z para o processo correto desse lote.

Poderia dar uma olhada e retornar com dicas ?

Muito Obrigada,

Cris.

*&----

---

*

*& Report ZNFE_JOB_LOTE_RESEND

*&

*&----

---

*

*&

*&

*&----

---

*

REPORT ZNFE_JOB_LOTE_RESEND.

TABLES: /XNFE/BATSTA.

DATA: TI_BATCH TYPE TABLE OF /XNFE/BATSTA.

DATA: LT_ELEMENT TYPE WDR_CONTEXT_ELEMENT_SET,

LT_BATCH TYPE /XNFE/BATCH_T,

LT_NFEHD TYPE /XNFE/NFEHD_T,

LT_NFE TYPE /XNFE/NFE_STRING_TAB,

LT_STATUS TYPE /XNFE/BAT_HIST_T.

DATA: LS_DATA TYPE /XNFE/WD_BATCH_S,

ls_nfehd TYPE /xnfe/nfehd,

LS_BATCH TYPE /XNFE/BATCH_S,

LS_STATUS TYPE /XNFE/BAT_HIST.

DATA: LL_BATCH LIKE LINE OF TI_BATCH,

LL_STATHIS LIKE LINE OF LT_STATUS.

DATA: LV_BATCHID TYPE /XNFE/BATCHID,

LV_FUNCMOD TYPE /XNFE/FUNCMOD,

LV_GOVVERS TYPE /XNFE/GOVVERS,

LV_ERRORSTAT TYPE /XNFE/ERROR_STATUS,

LV_ERROR TYPE STRING,

LV_TIMESTAMP TYPE TIMESTAMPL,

LV_VERSION TYPE /XNFE/VERSION,

LV_TEXT TYPE STRING,

LV_P1 TYPE SYST-MSGV1,

LV_P2 TYPE SYST-MSGV2,

LV_CABEC TYPE /XNFE/CABEC_VERS,

LV_LOTE TYPE /XNFE/BATCHID.

DATA: LT_KEY TYPE /XNFE/BAT_HIST_PK_T,

LS_KEY LIKE LINE OF LT_KEY,

LT_STATHIS TYPE /XNFE/BAT_HIST_T,

LS_STATHIS LIKE LINE OF LT_STATHIS.

DATA: LV_SENDTMPL_FROM TYPE TIMESTAMPL,

LV_SENDTMPL_TO TYPE TIMESTAMPL.

*---- Error Status

CONSTANTS: BEGIN OF GC_ERROR, "#EC NEEDED

XI TYPE /XNFE/ERROR_STATUS VALUE '01', "generell

XMLVALID TYPE /XNFE/ERROR_STATUS VALUE '10', "Validation

SSERVICE TYPE /XNFE/ERROR_STATUS VALUE '20', "Signatur

SZERTI TYPE /XNFE/ERROR_STATUS VALUE '21', "Signatur

SV_SERV TYPE /XNFE/ERROR_STATUS VALUE '22', "Signatur

SV_XMLV TYPE /XNFE/ERROR_STATUS VALUE '23', "Signatur

SXISYS TYPE /XNFE/ERROR_STATUS VALUE '24', "Signatur

SXIAPP TYPE /XNFE/ERROR_STATUS VALUE '25', "Signatur

SKEYST TYPE /XNFE/ERROR_STATUS VALUE '26', "Signatur

STSRV TYPE /XNFE/ERROR_STATUS VALUE '27', "Signatur

SIGERROR TYPE /XNFE/ERROR_STATUS VALUE '28', "Signatur

BFINISHED TYPE /XNFE/ERROR_STATUS VALUE '31', "Batch

BINPROC TYPE /XNFE/ERROR_STATUS VALUE '32', "Batch

BSEFAZ TYPE /XNFE/ERROR_STATUS VALUE '33', "Batch

BSCAN TYPE /XNFE/ERROR_STATUS VALUE '34', "Batch

BSIGN_S TYPE /XNFE/ERROR_STATUS VALUE '35', "Batch

BXISYS TYPE /XNFE/ERROR_STATUS VALUE '36', "Batch

BXIAPP TYPE /XNFE/ERROR_STATUS VALUE '37', "Batch

BSERV TYPE /XNFE/ERROR_STATUS VALUE '38', "Batch

BSRXISYS TYPE /XNFE/ERROR_STATUS VALUE '40', "B Stat Req

BSRXIAPP TYPE /XNFE/ERROR_STATUS VALUE '41', "B Stat Req

BSRMAXREQ TYPE /XNFE/ERROR_STATUS VALUE '42', "B Stat Req

BSRBNFOUND TYPE /XNFE/ERROR_STATUS VALUE '43', "B Stat Req

BSROTHERS TYPE /XNFE/ERROR_STATUS VALUE '44', "B Stat Req

BSRB2B TYPE /XNFE/ERROR_STATUS VALUE '45', "B Stat Req

BREJECT TYPE /XNFE/ERROR_STATUS VALUE '46', "rejected Batch

CXISYS TYPE /XNFE/ERROR_STATUS VALUE '50', "Canc/Skip

CXIAPP TYPE /XNFE/ERROR_STATUS VALUE '51', "Canc/Skip

COTHERS TYPE /XNFE/ERROR_STATUS VALUE '52', "Canc/Skip

SSYSCAN TYPE /XNFE/ERROR_STATUS VALUE '53', "Sign/Canc

SAPPCAN TYPE /XNFE/ERROR_STATUS VALUE '54', "Sign/Canc

SSYSSKIP TYPE /XNFE/ERROR_STATUS VALUE '55', "Sign/Skip

SAPPSKIP TYPE /XNFE/ERROR_STATUS VALUE '56', "Sign/Skip

GAPSTATERR TYPE /XNFE/ERROR_STATUS VALUE '57', "Gap/status_error

GAPIDERR TYPE /XNFE/ERROR_STATUS VALUE '58', "Gap/id_error

SSERVICE_S TYPE /XNFE/ERROR_STATUS VALUE '60', "Sign Scan

SZERTI_S TYPE /XNFE/ERROR_STATUS VALUE '61', "Sign Scan

SV_SERV_S TYPE /XNFE/ERROR_STATUS VALUE '62', "Sign Scan

SV_XMLV_S TYPE /XNFE/ERROR_STATUS VALUE '63', "Sign Scan

SXISYS_S TYPE /XNFE/ERROR_STATUS VALUE '64', "Sign Scan

SXIAPP_S TYPE /XNFE/ERROR_STATUS VALUE '65', "Sign Scan

SKEYST_S TYPE /XNFE/ERROR_STATUS VALUE '66', "Sign Scan

STSRV_S TYPE /XNFE/ERROR_STATUS VALUE '67', "Sign Scan

SIGERROR_S TYPE /XNFE/ERROR_STATUS VALUE '68', "Sign Scan

ERROR_GOV TYPE /XNFE/ERROR_STATUS VALUE '70', "Error Goverment

ERROR_REJ TYPE /XNFE/ERROR_STATUS VALUE '71', "Error Rejected

ERROR_DEN TYPE /XNFE/ERROR_STATUS VALUE '72', "Error Denied

TMP_ERR_SEFAZ TYPE /XNFE/ERROR_STATUS VALUE '73', "Error Goverment

ERR_XML_GOV TYPE /XNFE/ERROR_STATUS VALUE '74', "XML-Error Goverment

UNEXPEC_ERR TYPE /XNFE/ERROR_STATUS VALUE '75', "999 Batch Error Goverment

SRV_XISYS TYPE /XNFE/ERROR_STATUS VALUE '80', "Service Status

SRV_XIAPP TYPE /XNFE/ERROR_STATUS VALUE '81', "Service Status

SRV_OTHERS TYPE /XNFE/ERROR_STATUS VALUE '82', "Service Status

NSC_XISYS TYPE /XNFE/ERROR_STATUS VALUE '90', "Nfe Status Check

NSC_XIAPP TYPE /XNFE/ERROR_STATUS VALUE '91', "Nfe Status Check

B2B_XISYS TYPE /XNFE/ERROR_STATUS VALUE '92', "B2B

B2B_XIAPP TYPE /XNFE/ERROR_STATUS VALUE '93', "B2B

END OF GC_ERROR.

*&----

---

*

• PARAMETROS DE SELEÇÃO

*&----

---

*

SELECT-OPTIONS: SO_BATID FOR /XNFE/BATSTA-BATCHID,

SO_UF FOR /XNFE/BATSTA-UF_EMIT,

SO_STA FOR /XNFE/BATSTA-STATCODE.

PARAMETERS: PA_DTFR LIKE SY-DATUM,

PA_HRFR LIKE SY-UZEIT,

PA_DTTO LIKE SY-DATUM,

PA_HRTO LIKE SY-UZEIT.

*&----

---

*

START-OF-SELECTION.

*&----

---

*

*convert timestamp - date from

CONVERT DATE PA_DTFR TIME PA_HRFR

INTO TIME STAMP LV_SENDTMPL_FROM TIME ZONE SY-ZONLO.

*convert timestamp - date to

CONVERT DATE PA_DTTO TIME PA_HRTO

INTO TIME STAMP LV_SENDTMPL_TO TIME ZONE SY-ZONLO.

IF LV_SENDTMPL_FROM IS INITIAL AND LV_SENDTMPL_TO IS INITIAL.

SELECT * FROM /XNFE/BATSTA

INTO TABLE TI_BATCH

WHERE BATCHID IN SO_BATID

AND UF_EMIT IN SO_UF

AND STATCODE IN SO_STA.

IF SY-SUBRC <> 0.

EXIT.

ENDIF.

ELSE.

SELECT * FROM /XNFE/BATSTA

INTO TABLE TI_BATCH

WHERE BATCHID IN SO_BATID

AND UF_EMIT IN SO_UF

AND SENDTMPL BETWEEN LV_SENDTMPL_FROM AND LV_SENDTMPL_TO

AND STATCODE IN SO_STA.

IF SY-SUBRC <> 0.

EXIT.

ENDIF.

ENDIF.

• determine Batchstatus and Errorstatus

LOOP AT TI_BATCH INTO LL_BATCH.

LS_KEY-BATCHID = LL_BATCH-BATCHID.

APPEND LS_KEY TO LT_KEY.

ENDLOOP.

CALL FUNCTION '/XNFE/BAT_HIST_READ_AKTUAL'

EXPORTING

IT_BATKEY = LT_KEY

IMPORTING

ET_AKT_BATSTATUS = LT_STATHIS

EXCEPTIONS

KEY_TABLE_EMPTY = 0

NO_STATUS_FOUND = 0

OTHERS = 0.

LOOP AT TI_BATCH INTO LL_BATCH.

CLEAR: LS_STATHIS.

*read actual status

READ TABLE LT_STATHIS INTO LS_STATHIS

WITH KEY BATCHID = LL_BATCH-BATCHID.

IF SY-SUBRC = 0 AND LS_STATHIS-ERROR_STATUS NE SPACE.

IF LS_STATHIS-ERROR_STATUS = GC_ERROR-XI OR

LS_STATHIS-ERROR_STATUS = GC_ERROR-BSEFAZ OR

LS_STATHIS-ERROR_STATUS = GC_ERROR-BSCAN OR

LS_STATHIS-ERROR_STATUS = GC_ERROR-BXISYS OR

LS_STATHIS-ERROR_STATUS = GC_ERROR-BXIAPP OR

LS_STATHIS-ERROR_STATUS = GC_ERROR-BSERV OR "38

LS_STATHIS-ERROR_STATUS = GC_ERROR-UNEXPEC_ERR. "999 Batch error

CLEAR LT_BATCH. "ins 20080201

*read all nfe from batch

CALL FUNCTION '/XNFE/READ_NFE_FROMBATCH'

EXPORTING

IV_BATCHID = LL_BATCH-BATCHID

IMPORTING

ET_BATCH = LT_BATCH

ET_NFEHD = LT_NFEHD

EXCEPTIONS

EMPTY_BATCHID = 0

OTHERS = 0.

LOOP AT LT_NFEHD INTO ls_nfehd.

LOOP AT LT_BATCH INTO LS_BATCH.

LS_BATCH-TPEMIS = LS_NFEHD-TPEMIS.

LL_BATCH-TPEMIS = LS_NFEHD-TPEMIS.

MODIFY LT_BATCH FROM LS_BATCH.

ENDLOOP.

ENDLOOP.

• read all NF-e-strings

CLEAR LT_NFE.

CALL FUNCTION '/XNFE/GET_NFE_STRING'

EXPORTING

IT_BATCH = LT_BATCH

IMPORTING

ET_NFESTRING = LT_NFE

EXCEPTIONS

NO_XML = 1

OTHERS = 2.

CALL FUNCTION '/XNFE/GET_XML_VERSION'

EXPORTING

IV_CUF = LL_BATCH-CUF

IV_TPAMB = LL_BATCH-TPAMB

IMPORTING

EV_GOVVERS = LV_GOVVERS

EV_VERSION = LV_VERSION

EV_CABEC = LV_CABEC

EXCEPTIONS

GOVERNMENT_VERSION_MISSED = 1

VERSIONS_NOT_MAINTAINED = 2

OTHERS = 3.

• check if SEFAZ system is online

DATA:

LS_SRVSTA TYPE /XNFE/SRVSTA,

LT_SRVSTA TYPE /XNFE/SRVSTA_T.

SELECT * FROM /XNFE/SRVSTA INTO TABLE LT_SRVSTA

WHERE CUF = LL_BATCH-CUF

AND TPAMB = LL_BATCH-TPAMB

AND GOVSYS = SPACE.

SORT LT_SRVSTA BY CHECKTMPL DESCENDING.

READ TABLE LT_SRVSTA INTO LS_SRVSTA INDEX 1.

CHECK LS_SRVSTA-STATUS = '107'.

• build name of function module depending on XML version

LV_FUNCMOD = '/XNFE/005a_BATCH_NFE_OUT'.

MOVE LV_GOVVERS TO LV_FUNCMOD+6(4).

LV_LOTE = LL_BATCH-BATCHID.

CALL FUNCTION LV_FUNCMOD "'/XNFE/005a_BATCH_NFE_OUT'

EXPORTING

IV_CUF = LL_BATCH-CUF

IV_TPEMIS = LL_BATCH-TPEMIS

IV_TPAMB = LL_BATCH-TPAMB

IV_VERSAO = LV_VERSION

IV_VERSAO_CABEC = LV_CABEC

IV_VERSAO_DADOS = LV_VERSION

IV_ID_LOTE = LV_LOTE

IT_NFE = LT_NFE

IMPORTING

EV_ERROR = LV_ERROR.

CHECK LV_ERROR IS INITIAL.

• set new batch status

CLEAR LT_STATUS.

GET TIME STAMP FIELD LV_TIMESTAMP.

LS_STATUS-ERTIME = LV_TIMESTAMP.

PERFORM GET_TIME_STAMP IN PROGRAM /XNFE/SAPLAPPL_PROCESSES CHANGING LS_STATUS-ERTIME.

LS_STATUS-BATCHID = LL_BATCH-BATCHID.

LS_STATUS-ERROR_STATUS = LV_ERRORSTAT.

LS_STATUS-ERNAME = SY-UNAME.

APPEND LS_STATUS TO LT_STATUS.

*set status

CALL FUNCTION '/XNFE/BAT_HIST_UPDATE'

EXPORTING

• IF_SYNCHRON = ' '

IT_BAT_HIST = LT_STATUS

EXCEPTIONS

UPDATE_TABLE_EMPTY = 0

OTHERS = 0.

ENDIF.

ENDIF.

ENDLOOP.

[former_member193386]

tenho uma solucao alterando os dados diretamente nas tabelas do GRC.

1) na tabela /XNFE/BATSTA busque todos os registros dentro do range de status que deseja reprocessar e adicione a uma internal table ( o que nos interessa é o BATCHID dos lotes que deseja reprocessar)

2) em seguida entre na tabela /XNFE/NATHIST para cada registro /XNFE/BATSTA-BATCHID obtido e apague a ultima linha com o error status que deseja reprocessar ( se eu nao me engano é ERROR STATUS '40') e altere esse campo para ' ' (branco).

3) ao final chame o processo do relatorio /XNFE/BATCH_REQUEST.

Creio que assim fica mais facil de se criar um programa que reprocesse os lotes que não foram processados por erro de envio com um job agendado.

Espero que tenha ajudado!

[former_member182114]

Bom dia Cristiane,

Não dá muito pra ler seu último post, mas notei que você não se baseou em versão recente do GRC.

Os restarts do webdynpro passaram a travar o lote, ou NF-e, para evitar que dois usuários façam a mesma ação e não vi isto no seu código:

CALL FUNCTION 'ENQUEUE_/XNFE/ENQ_BATSTA'

Pegue o código numa versão recente SP13/SP14.

Quanto ao problema, tá bem difícil de acompanhar na thread, parece que você está enviando um XML vazio pra Sefaz então dá uma debugada e veja se as variaveis que estão levando o XML estão recebendo o conteúdo.

@Carlos,

Em alguns casos dá para se fazer sem executar o código do GRC, apenas modificando as tabelas, porém deve ser feito com todo cuidado e sempre deixando rastro (não para achar culpados, mas justamente para a rastreabilidade para investigações futuras).

No caso do item 2 que comentou, adicione uma nova linha ao invés de substituir a antiga, numa investigação é como se não tivesse acontecido erros, além disso registre o usuário no ERNAME.

Atenciosamente, Fernando Da Rós

-

-

---

Lembrei de outro item importante, Cristiane para o cenário de restart que você menciona sem problemas pois está na linha certa de reiniciaro 01/38, verificar disponibilidade da Sefaz e enviar se disponível.

Para qualquer outra situação de erro deve-se ter algum controle para o job não tentar eternamente um lote, isso pode sobrecarregar o servidor.

Para os erros de checagem também é importante se as NF-es dentro dele ainda precisam de verificação (isto também foi introduzido no código standard). Explicando: Em algumas situações em que o lote fica parado é habilitado no monitor de NF-e o "Query Status", e se o usuário decidir pela consulta da NF-e o sistema não permite a re-consulta do lote. Este tratamento também é importante para evitar se tenha informações divergentes e não controladas no GRC. A consulta individual é mais importante que a consulta do lote. Ex.: Uma NF-e 1010 pode ser enviada, a Sefaz rejeitada, e reenviada em outro lote. Se por algum motivo o primeiro lote for reiniciado pode receber a rejeição novamente, sendo que o controlo agora está pelo segundo lote ou pela consulta individual. (meio confuso né), mas a idéia é o lote é temporário a NF-e é perene.

Atenciosamente, Fernando Da Rós

Edited by: Fernando Ros on May 18, 2010 12:34 PM

[former_member193386]

Concordo com o Fernando quanto a criar uma nova linha ao inves de se alterar o status da ultima existente, vc poderia apenas copiar a linha anterior e criar uma nova baseada nela sem o campo com o status de erro, contudo, quanto ao envio de lotes com o mesmo numero de NFe que havia sido rejeitado creio que esse nao seja o problema Fernando, já que pelo que eu entendi, só estamos querendo enviar lotes com erro de transmissao e nao com erros de validacao da NFe, isso ppode ser feito filtrando apenas os lotes que estejam com o respetivo codigo de erro evitando erros de validacoes referentes às NFes.

[former_member182114]

Bom dia Carlos,

Na verdade só estava chamando a atenção pois muitos foram os problema estranhos em que a base ficava estranha... Hoje o GRC controla de forma mais rígida os status, então qualquer programa que corre por fora tem que seguir a mesma linha.

Resumindo toda a explicação que dei de madrugada: Devemos usar bom senso nos automatismos.

Obrigado pelas contribuições ao fórum.

Atenciosamente, Fernando Da Ró

[former_member193386]

concordo com vc, automatizar demais alguns processos pode acarretar em problemas futuros, esse processo que estamos analisando aqui, se for sómente para lotes com erro de transmissão creio que não acarrete problemas, só vale a pena deixar bem claro que o ideal seria fazer o processo manualmente para proceder uma analise caso o erro nao seja de transmissão e que não ocorra para todos os lotes enviados.

[henrique_pinto]

Nao há report standard, teria q ser Z mesmo.

Mas tem gente q desenvolveu e eh tranquilo, procure aqui no proprio forum q tem exemplos.

P.ex.: .

Abs,

Henrique.

[former_member182114]

Bem resgatado Henrique,

Só complementando que o GRC agora possue tratamento para evitar que usuários simultaneamente disparem uma mesma ação (os restarts), este programa também deve ter os tratamentos equivalentes para evitar a concorrência entre multiplos jobs ou job x user na interface.

Atenciosamente, Fernando Da Ró