Status de serviço NF-e 3.10 x tpAmb

[eduardohartmann]

Pessoal, boa tarde.

Estamos configurando a NF-e 3.10 num cliente e ao testar em DEV os satus de serviço verificamos que, ao contrário do esperado, o job /XNFE/NFE_CHECK_SRV_STATUS está disparando a consulta de status para tpAmb = 1 e 2, ao invés de somente para 2.

Debugamos até a FM /XNFE/SRVSTA_READ_CUST, e encontramos um comportamento diverso do que havíamos idealizado. Ao invés de retornar as entradas de configuração somente para tpAmb = 2, voltaram as configurações de ambos os tipos de ambiente conforme tabela LT_TSRV:

Podemos ver que para cada CUF temos 1 e 2

Verificamos que isso veio da configuração da /XNFE/TCUF e da /XNFE/GOVPAR.

Na GOVPAR temos a definição de tpAmb e CUF por CNPJ, para cada Sistema Lógico (LOGSYS) e Tipo de Documento.

Ex.:

DOCTYPE	LOGSYS	CNPJ	CUF	TPAMB
NFE	DEV100	AAA	41	2
NFE	DEV100	BBB	35	2
NFE	DEV100	CCC	35	2
NFE	QAS100	AAA	41	2
NFE	QAS100	BBB	35	2
NFE	QAS100	CCC	35	2
NFE	PRD100	AAA	41	1
NFE	PRD100	BBB	35	1
NFE	PRD100	CCC	35	1

Com essa configuração, a ideia é ter uma TO que vai poder ser levada para QAS e PRD com os dados corretos para cada ambiente. Esperávamos que a FM só recuperasse os dados do ambiente em que estamos executando-a, no caso DEV100. Mas não, a FM pegou todos os registros, independentemente do LOGSYS, e com isso, resultou no print acima, onde para cada CUF temos tpamb 1 e 2.

Em seguida o sistema passa essa tabela para ser feita a consulta de status, e temos em DEV a consulta de tpAmb = 1 sendo feita (o que não desejávamos). Como o programa principal (/XNFE/NFE_CHECK_SRV_STATUS) não tem mais o parâmetro tpAmb na tela de seleção, não temos como filtrar.

Concluímos que somos obrigados a ajustar os dados em cada ambiente para que seja feita a consulta apenas conforme o LOGSYS desejado, ou seja, ao mover isso para PRD teremos que ajustar os dados (ou criar n TOs com os dados de cada ambiente - no nosso caso, temos uns 7 ambientes, DEV100, DEV200, DEV300, QAS100, REG100, SDB100, PRD100).

Alguém chegou a seguir essa mesma ideia? Mudaram a definição no meio? Como planejam seguir com isso?

PS.: procurei notas para essa FM, sem sucesso:

Obrigado, abraços!

Eduardo Hartmann

[rhviana]

Eduardo,

Você não precisa transportar tudo, eu crio requests separadas para os diversos ambientes para justamente não subir nada relativo a homologação para produção, simples assim.

Sobre o programa, realmente ele se baseia no que tem na tabela, no que foi configurado na SPRO, não apenas realizando filtro por tipo de ambiente - Homolog/Produção.

Abs,

Viana.

[eduardohartmann]

Oi Viana,

O problema é justamente essa gestão das requests...... quando uma request é criada aqui, após o unit test (DEV) e validação do teste integrado (QAS), ela com certeza subirá até PRD (ou você tera gente te perguntando dela toda semana). Assim, cada uma dessas requests (QAS, SandBox, Regression, PRD) vai subir - e pela minha experiência, quase nunca conseguem colocá-las na ordem certa

E outro problema vem com refresh de ambientes, pois a configuração que está em PRD não pode rodar em QAS, por exemplo - e a ideia era deixar tudo customizado para diminuir ao máximo o trabalho pós-refresh.

Enfim, acho que vamos levar a configuração completa para todos os ambientes com uma única request, e eliminar as entradas não relevantes. Vai gerar uma tarefa de cutover mas pelo menos fica numa request só

abraço!

EH

[rhviana]

EH,

O que eu faço é o seguinte, sempre faço a configuração separada, primeiro faço tudo voltado para produção e gero as requests para produção e depois faço a config para desenvolvimento.

Outra coisa que até acabei fazendo o projeto foi solicitar abertura do ambiente para refino da configuração, e foi aceito.

Solicita ai, apaga tudo de homolog e já era

Abssss

[eduardohartmann]

Pois é, era isso que eu queria evitar, mas enfim... se não pode vencê-los rsrsrs

O mais chato de tudo é que a pessoa que vai fazer isso em PRD com om FF não está nem no BR, vamos ter que documentar tintim por tintim o que fazer, e rezar pra fazerem certo dessa vez kkk

Lá vem mais um golive com emoção

[eduardohartmann]

Hummm acabei de pensar numa situação que pode ter levado a deixarem a FM assim...

Se o GRC receber dados de um sistema produtivo e outro de testes, ele deveria checar os status para ambos.

Outra coisa, o sistema lógico que deveria ser filtrado é o do ECC, não do GRC... assim não serve usar o próprio sistema lógico para filtrar

Mas bem que poderia usar o Tipo de Ambiente do GRC (se é produtivo ou não) para fazer a seleção - não conheço nenhum cliente que usa um servidor para PRD e Testes.

Ainda assim, ideias de como vocês configuraram são bem vindas, podemos ter ideias para melhorar esse processo.

abs!