Italo Giurizzato Junior

Bom dia Agricio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Arce, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia a todos, Favor atualizar os fontes e fazerem novos testes.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum.

Bom dia Thiago, Vamos ver se eu entendi o seu problema. Você tem uma rotina própria que gera o XML, correto? Esta utilizando o componente ACBrCTe apenas para assinar, validar e enviar, correto? Mas ao tentar enviar ocorre o erro de validação acusando que não consta o elemento Signature. O XML que você anexou, contem a assinatura, logo não era para ocorrer esse erro de validação.

Bom dia Thiago, Te aconselho, nesse período de transição emitir em ambiente de homologação no sistema novo. Se você mudar de série a numeração vai iniciar do 1. Como você vai fazer para explicar para a SEFAZ os CT-e que não foram emitidos da outra versão? O sistema atual se utiliza da serie 1 e a numeração se encontra em 50.000 O novo vai utilizar a serie 2 com numeração inicial 1. Após o processo de transição o sistema atual para na numeração 50.500, sabendo que a numeração de uma serie varia de 1 até 999.999.999 o que você vai dizer para a SEFAZ porque não emitiu os CT-e de 50.501 até 999.999.999 da série 1? Pense um pouco mais sobre isso.

Bom dia Jonilton, Você utiliza o ACBrMonitor? Se sim, veja o exemplo abaixo: [vPrest] vTPrest=500 vRec=500 [Comp001] xNome=Frete Peso vComp=400 [Comp002] xNome=Pedagio vComp=100

Bom dia Cleonir, Primeiramente muito obrigado pela colaboração. Já baixei tudo o que você anexou, vou analisar o que foi feito e disponibilizar no Branches até o final desta semana.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Paulo, Favor anexar o arquivo TXT para que possamos analisar.

Isso também pode esta ocorrendo. Concordo com você.

Boa tarde Robson, Você verificando se existe algum item na lista, pois essa mensagem diz que esta ocorrendo uma tentativa de leitura de um item da lista que possa estar vazia.

Boa tarde Robinho, Vamos verificar.

Acredito que não.

Bom, neste caso deve ser mesmo o provedor. Aqui na minha cidade o cabeamento da Vivo é só fibra ótica, já a NET parte é fibra, parte é cabo metálico. Não deveria dar tanta diferença assim, mas...

Boa tarde, Desculpe, ficou faltando completar a postagem anterior. Se tratando de NFC-e devemos emitir a nota em contingência ou pelo SAT (no caso de São Paulo). Infelizmente não temos via webservice um serviço para realizar uma consulta para saber se realmente o numero foi inutilizado. Se não me falha a memória a única forma de saber é sita site.

Boa tarde, Não enviei nenhum evento de cancelamento por substituição, uma vez que não tenho nenhum cliente que emite NFC-e. Veja esta regra que consta na mesma NT. Por essa regra eu concluo que para enviar o evento de cancelamento por substituição se faz necessário existir na base de dados da SEFAZ a nota enviada por contingência.

Boa tarde a todos, Conforme anunciado pelo SEFAZ, a partir de Janeiro de 2019, seria válido o layout 0.08 do XML de entrada.... e ao mesmo tempo, o (antigo e obsoleto) layout 0.06 deixaria de ser aceito.... O fato do layout ser aceito, não significa necessariamente que todos precisam migrar imediatamente para ele... Isso depende inclusive, da atualização do Software Básico dos equipamentos em campo (veja tópico a seguir ) O que realmente muda, é que o layout 0.06, deixou de ser aceito... ( bem, mesmo isso foi prorrogado ) Portanto se a sua aplicação apenas suporta o XML 0.06, CORRA e faça os ajustes necessários para suportar a 0.07 ou a 0.08... Se você já suporta o layout 0.07, então veja aqui, o que há de novo no layout 0.08, e como se ajustar a ele... O que mudou no XML de entrada 0.08 ? Conforme consta na Especificação SAT_v_ER_2_26_04, temos as seguintes alterações: Layout do XML de venda: 1. Grupo enderEmit - campo xBairro passa a ter o seu tamanho variável alterado de 2-60 para 1-60 (mínimo 1 caractere e máximo de 60). 2. Grupo emit - campo IE passa a ter o seu tamanho fixo de 12 alterado para variável: 2-14. 3. Grupo dest - campo CPF passa a ter tamanho fixo de 11 dígitos, antes o campo poderia ficar vazio. 4. Grupo prod - incluído o campo CEST (opcional) de tamanho fixo de 7 dígitos. 5. Grupo obsFiscoDet - campo xTextoDet passa a ter uma nova instrução de preenchimento: 6. O grupo obsFisco gerado pelo SAT é que teve uma mudança significativa e merece ser mencionado aqui. Esse grupo antes estava dentro do grupo infAdic, agora ele esta no mesmo nível do infAdic, portanto ambos (infAdic e obsFisco) estão dentro do grupo CFe. Layout do XML de Cancelamento: 1. Os campos referentes aos itens: 1, 2 e 3 (do layout do XML de venda) sofreram a mesma alteração, mas eles são gerados pelo SAT.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Giovani, Veja este vídeo: Como informar e imprimir o Fundo de Combate a Pobreza

Boa tarde, Ambas as empresas contrataram a mesma empresa que provem o acesso a internet? Todas as notas da primeira sempre são autorizadas em 2 segundos e todas as notas da segunda sempre levam 10 segundos para serem autorizadas?

Se tratando de NF-e existe uma alternativa que é enviar a nota para a SVC- SEFAZ-Virtual de Contingência. Como e Quando usar o SVC

Bom dia, Na página 3 da Nota Técnica 2018/004 temos: "Sendo assim, a partir dessa Nota Técnica será possível um contribuinte cancelar uma NFC-e que foi emitida em duplicidade. Esse tipo de situação pode acontecer quando um contribuinte emite uma NFC-e (NFC-e 1), porém, por algum motivo, não obtém resposta, ficando pendente de retorno, e em seguida emite outra NFC-e (NFC-2), normalmente em contingência, para acobertar a operação. Depois é verificado que a “NFC-e 1” também foi autorizada, e sendo assim temos duas NFC-e acobertando a mesma operação. Acontecendo isso, o contribuinte poderá solicitar o cancelamento, no prazo não superior a 168 horas, da NFC-e emitida em duplicidade e que não acobertou a operação (NFC-e 1), tendo que referenciar a NFC-e que substituiu (NFC-2) aquela que está sendo cancelada." Pelo que entendi a coisa funciona da seguinte forma: Emiti a nota de numero 500 segundo o tipo de emissão = 1 (Normal) a nota foi enviada, mas não obtive o retorno. Emite a mesma nota só que agora com o numero 501, tipo de emissão = 9 (contingência) a nota foi enviada. Dentro do prazo de 168 horas descobri que ambas as notas foram autorizadas e o cliente levou as mercadorias com o DANFE referente a nota de numero 501, logo tenho que cancelar a nota de numero 500, pois temos duas notas acobertando a mesma venda. Devo neste caso enviar um evento de cancelamento por substituição informando a nota a ser cancelada (numero 500) e a nota que a substitui (numero 501) Exemplo de como alimentar o componente para enviar o evento de cancelamento por substituição No campo chNFe devemos informar a chave da nota a ser cancelada (segundo o exemplo acima a nota de numero 500) No campo chNFeRef devemos informar a chave da nota substituta (segundo o exemplo acima a nota de numero 501). Resumindo, só podemos enviar o evento de cancelamento por substituição, depois de enviado e confirmado que as duas notas foram autorizadas.