João Paulo Müller

Pois é. É um problema dos grandes... Em contato como homologador ele comentou que o arquivo só pode ser considerado enviado assim que receber o status 1 = Sucesso. Problema que não da para aguardar o serviço levar 5 dias para processar um arquivo... Se o cliente tiver 2 ECF já trava o PDV.

Boa tarde Mario, obrigado pelo retorno. Pois bem, essa maldita demora para processar o arquivo no servidor (Status 0-Aguardando) esta dando uma dor de cabeça das grandes, pois os clientes estão ficando com o PDV travado, devido exceder o limite dos arquivos pendentes permitidos. Estou pensando em implementar uma nova versão onde desconsidera esses arquivos aguardando o processamento da soma dos arquivos pendentes, pois na verdade eles não estão mais pendentes, pois foram enviados. Posteriormente se retornar erro ai sim eu considero como pendentes. O meu medo é de por exemplo, enviar outros arquivos e um o segundo arquivo enviado processar antes do primeiro, fazendo com que as reduções z não fiquem mais em ordem cronológica, conforme exigência da ER 02.05, a qual estamos homologados. Como você está tratando ai o envio dos arquivos ?

Também penso dessa forma... O detalhe é o seguinte, estamos homologado na ER 02.05 a qual exige que os arquivos da Rz devem ser enviados em ordem cronológica. Se eu enviar o arquivo e ele ficar como status "0-Aguardando" e então eu considera-lo como enviado e enviar o próximo arquivo pendente, pode acabar acontecendo de o segundo arquivo ser processado antes do primeiro, o que faria com que não ficasse mais em ordem os arquivos da Rz.. Está acontecendo ai com seus clientes também de ficar "Processando" no servidor?

Boa tarde pessoal, procurei no fórum mais não encontrei nada sobre esse ATO. A alguns dias são o ATO DIAT que se refere a novos prazos para Bloqueio do bloxo X. Em conversa com o homologador da UnoChapeco foi comentado que essa ATO trata-se de uma medida de exceção que será revogado com a estabilidade dos sistemas SAT. Não sei com vocês, mas estamos com muitos clientes com arquivos pendurados para ser processado no servidor, o qual sempre retorna o código 0-Aguardando.

Boa tarde pessoal, Estou com esse mesmo problema aqui, passou a acontecer essa semana... O arquivo chega a ficar horas e dias pendentes no servidor, o que está deixando os PDVs travados para acesso devido os 10 arquivos pendentes. Estou pensando em enviar todos os arquivos e estes arquivos que estão como aguardando processamento não considerar como pendentes, somente após receber um retorno e obter erro, ai considerar como pendentes... O que acham? Como funciona a sistemática de vocês para transmitir os arquivo?

Estou com um problema semelhante com as reduções Z. Envio o arquivo e o WS me retorna o codigo 0-aguardando... Já estou a horas consultando esse arquivo e retorna a mesma situação.. Tem clientes que já chegou a travar o acesso ao PDF devido a essa demora para processar o arquivo no WS. É o mesmo retorno que você recebe ai Mario? Isso começou acontecer a pouco tempo, estou achando que é algo no WS...

Bom dia pessoal, Estamos enfrentando o seguinte problema com clientes que estão transmitindo o bloco X: O sistema válida e transmite o arquivo normalmente, porém o Web Service retorna o codigo "0-Aguardando". Beleza, até ai tudo bem... O detalhe é que tem casos que esta chegando a bloquear o acesso ao PDV por ter muitos arquivos pendentes, pois o arquivo ainda não foi processado. Realizo a consulta do recibo toda vez que abre o PDV e sempre esta retornando o código "0-Aguardando"... Diversos clientes já relataram esse problema, comentaram que começou essa semana. Mais alguém está enfrentando esse caso? Outros detalhe pessoal: 1) Atualmente, aqui no nosso sistema, consideramos o arquivo enviado somente quando recebemos o retorno de "Processado com sucesso", porém já vi sistema que simplesmente pelo fato de receber o recibo já consideram o arquivo enviado. O que me dizem disso? 2) O nosso processo para envio do bloco X aqui no momento funciona da seguinte maneira: É realizada a tentativa de transmissão do arquivo, se o mesmo não for processado com sucesso é interrompido o envio dos outros arquivos até que aquele seja transmitido. Estamos fazendo dessa forma devido a ordem cronológica exigida no requisito LVIII: 6. Os Arquivos com Informações da Redução Z do PAF-ECF devem ser transmitidos em ordem cronológica da data das operações a que se referem.

Aqui gerei uma versão esses dias com as duas opções LT_ALL e LT_TLS12, pra garantir.. Só uma duvida pessoal, vejo muita gente falar em configuração do IE, mas se não estou enganado quem utiliza winHTTP depende unicamente da dll (WinHTTP), certo? Ou seja, as configurações de internet não vão mudar em nada, é isso? Digo isso pois vi um vídeo aqui no ACBR que o Daniel Simões explica essa questão.

Até então esta comunicando com LT_ALL, porém acho que estão aceitando a comunicação por SSL ainda...

Pessoal, sabem dizer se vai funcionar com LT_ALL a partir do dia 02/08? Já tenho uma versão forçando comunicar com TLS, mas nem todos clientes estão atualizados... A antiga versão comunica com LT_ALL

Outra questão pessoal, preenchendo somente o CST com cstRep60, os demais valores do grupo vão zerado, o correto é realizar os calculos ou não tem a necessidade?

BigWings, não faltou uma condição ai de operação interestadual também? Se a venda for interna não necessita a alteração, certo?

Boa tarde Pessoal, estou com o mesmo caso aqui. BigWings como faço para destacar o grupo ICMSST ao invés do grupo ICMS60? Devo atribuir o CST = cst60rep como sugeriu o André?

Certo Fábio, Vou fazer isso. Será que pode parar de funcionar dessa forma, utilizando LT_ALL, quando desativar o 3.10, para esses clientes que já utilizam a 4.0 com LT_ALL? Outra questão. Qual é o servidor que irá definir isso, o Servidor de destino, ou o próprio servidor do estado do emitente? Exemplo se de SC eu enviar para SP, qual servidor ira definir? Sabe me dizer?

Boa tarde pessoal, estamos com quase todos os clientes atualizados para NFe 4.0, atualmente esta funcionando corretamente. Gostaria de verificar a seguinte situação com vocês: Estou configurando o componente da seguinte forma: Notem que não estou atribuindo nenhum valor para SSLType, ou seja, está utilizando o padrão LT_ALL. Tenho rodando a NFe 4.0 em produção e esta funcionando corretamente. A minha dúvida é a seguinte: Será que os servidores do leiaute 4.0 estão aceitando outra comunicação além da TLS 1.2? Ou realmente estou conectando na TLS 1.2? Será que quando for desativado o antigo leiaute pode ocorrer de esses clientes que estão utilizando a configuração dessa forma parar de funcionar? Assisti agora pouco um vídeo Daniel Simoes onde foi comentando que a configuração de LT_ALL pode acabar dando problema, pois é tentado um protocolo, depois o outro e assim sequencialmente, até conseguir conectar, onde pode ocorrer de o Servidor bloquear a conexão. Acontece que até então esta funcionado dessa forma. Posso alterar para forçar o TLS_12 sem problema, o detalhe é que teria que atualizar os clientes novamente, o que não seria uma boa ideia... Utilizo a configuração dessa forma, pois usamos a mesma função para diversas aplicações como NFs, CTe, etc... Por esse motivo não forçamos o uso do TLS 1.2 E ai, será que posso ter problema na próxima semana?

Boa tarde pessoal, Os mercados já está transmitindo os arquivos do bloco X, até o final de anos os demais seguimentos serão obrigados a transmitir os arquivos.. Como estão tratando essa questão do Out of Memory? Pegamos um cliente agora com este problema, possui 120 mil produtos.

Boa noite Will, Conseguiu resolver esse problema? Estou com o mesmo caso aqui. Estou alterando da ER 02.03 para homologar na ER 02.05. Será que este erro pode ser pelo fato de eu não estar preenchendo o campo NumeroCredenciamento da ECF? O erro retornado é: XML inválido: Número do credenciamento do PAF-ECF informado no XML diferente do SAT. XML...

Tenho uma tabela de relacionamento entre FCP, UF E NCM, se o sistema encontrar FCP cadastrada para aquela UF e NCM e a operação for interna preenche as tags de FCP. Também possuo uma flag na regra do imposto dizendo se calcula FCP na operação interna ou não, pois há estado que depende de outras variáveis alem do produto para calcular a FCP, como por exemplo o estado de PR que depende se é consumidor final.

Boa tarde, na Nota Técnica 2016.002 - v 1.50 foi alterada as validações para o modo correto, porém ainda não foi implementada as alterações, portanto não há como testar ainda. Hoje (16/05/2018) saiu a NT 2016.002 v 1.51 na qual foram alterados os prazos de implementação para: – Ambiente de Homologação (ambiente de teste das empresas): 21/05/2018.– Ambiente de Produção: 04/06/2018.

Temos que torcer para não ocorrer isto em ambiente de produção, se não vai ficar muito em cima da hora para a desativação da versão 3.10... Tomara que prorroguem.

Mesma situação aqui, pelo que analisei as alterações da ultima NT (1.50) ainda não estão em vigor... Que beleza em... O jeito é esperar...

Pessoa na verdade, eu acho que as alterações da NT versão 1.50 ainda não está aplicadas, pois essa validação que está exibindo nem existe mais, acredito que o correto é poder preencher o grupo das duplicatas normalmente. Alias teve uma outra alteração que foi feita na NT 1.50 que também não esta funcionando, que é o FCP ST para o estado de destino, já tentei enviar FCP ST preenchendo os campos conforme a nova versão, mas ainda recebo a rejeição da versão antiga... Acredito que ainda não esta em vigor a nova versão NT 2016.002 v. 1.50, e posteriormente quando estrar em vigor, podera utilizar o grupo de duplicatas normalmente..

As alterações da NT 2016.002 v. 1.50 já eram para estar em homologação né? SEFAZ se atrapalhou nas datas? Na NT diz o seguinte: O prazo para implantação das alterações trazidas pela versão 1.50 desta NT é: Ambiente de Homologação (ambiente de teste das empresas): 02/05/2018. Ambiente de Produção: 16/05/2018. Pois retirei a duplicata Mercantil e estou informando o grupo de duplicatas, mas ainda recebo a rejeição de Grupo duplicata informando e forma de pagamento não é duplicata mercantil...

Boa tarde pessoal, Me tirem uma dúvida, se eu faço uma nota de ST + ICMS (CST 010) deverá ser preenchido os campos de FCP e FCP ST referente ao estado de destino, certo? Essa nova NT me deixou confuso em relação a isso, pois diz que o capo FCP deve ser validado para origem e FCPST para destino. Se faço uma operação de ST + ICMS e preencho o FCP e FCPST da erro de FCP invalido. Deve ser preenchido somente FCP ST?? Temos a seguinte rejeição que me deixou mais confuso pois pede para subtrair o vFCP da base de calculo do ST: Rejeição: Valor do FCP informado difere de base de cálculo*alíquota [nItem: nnn] Se informado CST= 10 ou 30 ou 70 ou 90 ou CSOSN=201 ou 202 ou 203 ou 900 e vFCPST (id:N23d) difere da vBCFCPST (id:N23a)* pFCPST (id:N23b) - vFCP (id:N17c) (*4)