Vanessinha Mocellin

Estavamos enfrentando esse problema, porém a SEFAZ andou mudando o manual, não exigindo mais produtos sem estoque e sem movimentação, dessa forma para nós resolveu o problema. Verifica o manual e confirma oque passei, se o sistema de vocês estiver gerando esses produtos que não precisam, acredito que irá resolver nao gera-los mais.

Boa tarde Guilherme, nossa aplicação não utiliza o método "Validar", utilizamos apenas "Enviar" e "Consultar". Teria que verificar se esta disponível esse serviço, caso sua aplicação esta utilizando esse método fique a vontade em testar e sugerir a alteração!

Segue em anexo os fontes com as modificações do Bloco X referente as alterações disponibilizadas no layout (alterações realizadas com base na revisão 14175). Em anexo também segue um arquivo redução Z e um arquivo de estoque como exemplos que foram enviados e validados. Histórico das alterações: Alterações fonte ACBrBlocoX_Comum.pas: Grupo Estabelecimento: Removido os campos CNPJ e Nome Empresarial que foram removidos do layout. Grupo PafEcf: Removido os campos NomeComercial, Versao, CNPJDesenvolvedor e NomeEmpresarialDesenvolvedor que foram removidos do layout. Alterações fonte ACBrBlocoX_WebServices.pas: Alterado a montagem dos dados da mensagem: Removido as tags pCnpjEstabelecimento, pDataReferencia e pNumeroCredenciamentoEcf que foram removidas do layout. Alterado endereço do webservice que foi modificado. Alteração fonte ACBrBlocoX_Estoque.pas: Inserido controle para setar vazio a alíquota quando a alíquota for zero e a situação tributária for: Isento, Não Tributado ou Substituição Tributária, pois ocorre erro se for zero. Alterações fonte ACBrBlocoX_ReducaoZ.pas: Grupo Ecf: Removido os campos NumeroCredenciamento, Tipo, Marca, Modelo, Versao, Caixa que foram removidos do layout. Grupo DadosReduzaoZ: Inserido controle para o tipo de convênio gerar 6 ou 9 dígitos e alterado formato dos campos VendaBrutaDiaria e GT, pois não podem ter virgula e deve ter zeros a esquerda em virtude da validação que ocorre erro. Alteração fonte pcnConversao.pas: Inserido tcNumStr no tipo de campo, utilizado na geração dos campos VendaBrutaDiaria e GT do arquivo da Redução Z. Alteração fonte pcnGerador.pas: Inserido tratamento para o tipo tcNumStr, para inserir zeros a esquerda. Informativo repassado pela secretária de Estado da Fazendo de Santa Catarina com resumo dos ambientes: Homologação – XSD Redução Z : https://sathomologa.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/xsd/reducaoz.xsd Estoque: https://sathomologa.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/xsd/estoque.xsd Homologação – XML Página: https://sathomologa.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/validacao.aspx Webservice: http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx Produção – XSD Redução Z: https://tributario.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/xsd/reducaoz.xsd Estoque: https://tributario.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/xsd/estoque.xsd Produção – XML Página: https://tributario.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/validacao.aspx Webservice: http://webservices.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx Layout Bloco X atualizado (obs: ainda não é a versão final, sendo assim poderá sofrer alterações sem aviso prévio) sharingSLzijD81OPeJzh9FqE/edit?usp=1yez14gry9Mi4rTpwDRDf–bR-google.com/document/d/https://docs. OBS: Peço que utilizem o ambiente de produção para testes somente até o dia 15/11. Após esta data, isso iremos excluir todos os registros e deixá-lo pronto para recepcionar os dados, conforme os prazos estabelecidos em legislação. O ambiente de homologação continuará disponível. Att. Bruno Nogueira Auditor Fiscal da Receita Estadual Secretaria de Estado da Fazenda de Santa Catarina Diretoria de Administração Tributária – DIAT Gerência de Sistemas e Informações Tributárias – GESIT Fonte: http://bell.unochapeco.edu.br/lts/?p=3171 Obs: ainda não é a versão final do layout. Fontes.rar Arquivos.rar

Bom dia, estou postando os fontes que o Adriano Rezena alterou, segue em anexo. Alterações aplicadas em cima da revisão 13841 dos fontes da ACBr. ACBrBlocoX_Estoque.pas ACBrBlocoX_ReducaoZ.pas ACBrBlocoX_WebServices.pas

Fiz os testes e fechou 100%, obrigada Daniel!

Bom dia Daniel, segue em anexo o XML solicitado e os fontes alterados atualizados. pcnNFeW.pas pcnGerador.pas 21150519371309000116550010000008191049346877.xml

Boa tarde Daniel, fiz os testes e fechou 100%, muito obrigada!

Após a atualização dos fontes para o trunk2, começou a ocorrer problema na importação de XML. No processo da importação utilizo o método ACBrNFe.NotasFiscais.Validar(), para verificar se o XML que esta sendo importado é de fato um XML válido. É nesse processo que ocorre o erro, como se a estrutura do XML fosse inválida, porém teoricamente estaria válida. Em analise ao XML consegui identificar que as tags SignatureValue e X509Certificate estão com o conteúdo quebrado em linhas, se for editado manualmente o XML e ajustado o conteúdo do campo para ficar em apenas uma linha, o XML é validado sem erros por esse método. A questão é que esse mesmo XML com as linhas quebradas na versão do trunk era validado e agora no trunk2 retorna erro de validação. Em anexo segue XML para analise, esse XML foi baixado direto do site da SEFAZ. Para fins de testes, baixei um XML do site da SEFAZ enviado pelo nosso próprio sistema utilizando a ACBr, e esse XML baixou as tags SignatureValue e X509Certificate sem quebras, com o conteúdo correto em apenas uma linha. Então conclui-se que o XML baixado do site da SEFAZ é o mesmo que é enviado no processo da autorização. Dessa forma pode-se concluir que o sistema do fornecedor enviou esse XML dessa maneira para SEFAZ. Porém pedir para os fornecedores mandarem o conteúdo dessas tags sem essas quebras é inviável, pois um dos fornecedores que esta ocorrendo esse problema para ter ideia é a Garoto. A principio a SEFAZ considera o conteúdo dessas tags quebrados valido, provavelmente eles devem ter um método para remover os espaçamentos em branco entre as tags. Onde também deveria existir antes na versão do trunk e foi perdido na versão do trunk2, acredito que essa validação deve ocorrer a partir de dlls pelas estruturas dos schemas, pois não consegui debuggar para identificar onde estaria o problema. Apenas queria reportar essa situação, se acharem viável ajustar para considerar valido esse XML, ou caso não for alterado essa validação no componente, vou criar uma função externa para que remova esses espaçamentos. 43151097580260000115550010004607611044609403-nfe_vald.xml

Bom dia Daniel, Desculpa a demora, não recebi notificação que havia respondido o tópico. Sim, as alterações tinham sido feitas no trunk. Segue em anexo alterações feitas no trunk2 revisão 10125. pcnNFeW.pas pcnGerador.pas

Pois é, essa situação já tinha identificado no inicio da implementação da NFC-e, porém não faz sentido oque eles solicitam no manual, não existe a possibilidade de duas criptografias diferentes serem iguais. Já falei com o a SEFAZ do RS e MT praticamente desenhei a minha duvida para eles e eles não fazem nem ideia do que eu estou falando. Se o token não foi criado com esse intuito não faço ideia para que ele serve também. Totalmente inviável instalar em todos os PDV's.

Boa tarde Alesandro, Nada resolvido ainda, nem retorno das SEFAZ's.

Bom dia Juliomar, Com essa ultima alteração compila em D6, porém desfaz a alteração realizada desse tópico que foi sugerida pelo Thiago referente a revisão 8881. Segue em anexo fonte com nova alteração, visando permanecer as alterações sugeridas pelo Thiago e permanecer com os comandos internos do delphi que você sugeriu utilizar. ACBrUtil.pas

Estou com problemas de compilação no D6 após atualizar o fonte com essa alteração, em virtude de não existir o método AnsiRightStr no StrUtils para essa versão. Em anexo alteração que substitui comando inexistente na versão D6 para compatibilidade com as demais versões. Alterações previstas referente a revisão 9062. ACBrUtil.pas

Boa tarde srs. Ao importar uma NF-e gerada por software de terceiros em nosso sistema utilizando o componente da ACBr (ACBrNFe.NotasFiscais.Valida), ocorreu o seguinte erro de validação no grupo (G - Entrega) tag (G02 - CNPJ): Erro: Expecting: {http://www.portalfiscal.inf.br/nfe}CNPJ. Essa NF-e encontra-se autorizada na SEFAZ e seu XML é validado sem erros, conclui-se então que o problema se encontra na validação da ACBr. A validação da ACBr retorna erro em virtude da tag CNPJ estar vazia, conforme exemplo abaixo: -<entrega> <CNPJ/> <xLgr>AV. TESTE</xLgr> <nro>01</nro> <xCpl>COMPLEMENTO</xCpl> <xBairro>BAIRRO</xBairro> <cMun>2111300</cMun> <xMun>Sao Luis</xMun> <UF>MA</UF> </entrega> Segundo o manual, quando for informado um CNPJ ele pode ter de 0 a 14 caracteres, dessa forma o conteúdo vazio da tag é considerado válido, apenas a tag CPF quando informada deve conter obrigatoriamente 11 caracteres, abaixo trecho do manual: G. Identificação do Local de Entrega # ID Campo Descrição Ele Pai Tipo Ocor. Tam. Observação 89 G01 entrega Identificação do Local de entrega G A01 0-1 Informar somente se diferente do endereço destinatário. 90 G02 CNPJ CNPJ CE G01 N 1 -1 0 ou 14 Informar CNPJ ou CPF. 90 a G02a CPF CPF CE G01 N 1 -1 11 Preencher os zeros não significativos. (v2.0) Foi realizada a correção dessa situação, para considerar válida e gerar a tag CNPJ vazia caso não for informado valor para o mesmo. Alterações previstas referente a revisão 9062, em anexo alterações. pcnGerador.pas pcnNFeW.pas

Pessoal, sexta-feira, final da tarde ocorreu o mesmo problema, porém em um cliente do MT. No momento que estava ocorrendo essa situação a SEFAZ desse estado estava fora, oscilando. Final da tarde foi identificado que a SEFAZ do MT estava no ar novamente então foi colocado as notas retransmitirem sem alterar absolutamente nada e as mesmas foram autorizadas corretamente. Já ouvi relatos do estado de SP e PR, pelo que analisei nesse tópico e em outros, chego a conclusão que é problema no webservice mesmo, e não propriamente configuração do IE (claro que as configurações devem estar corretas). Partindo da seguinte lógica, que em momentos funcionam e em outros não, na mesma máquina, segundo vários relatos. Uma situação que ocorreu nesse cliente no MT é que uma NF-e retornou esse erro e foi autorizada na SEFAZ. Em situações como essa que o problema é na SEFAZ não temos oque fazer a não ser tratar os erros e retornos. Sugiro aumentar o tempo que será aguardado o retorno nesses casos que se perde a comunicação e também realizar tratamento para essa situação (de reconsulta, retransmissão).

Referente ao problema que o Victor relatou sobre o retorno em branco do erro, esta retornando em branco devido não estar sendo alimentado em nenhum lugar a property FMsg (da classe base). Essa situação foi solucionada alterando o método TratarResposta da classe TNFeConsNFeDest, atribuindo o valor do xMotivo a property FMsg. Para o caso do Daniel Caus foi alterado o método TratarResposta da classe TDistribuicaoDFe, atribuindo também o valor do xMotivo a property FMsg, conforme já é realizado em outras classes por exemplo: TNFeRecepcao, TNFeRetRecepcao, TNFeRecibo etc. Daniel trate sua aplicação com try except, coloque os tratamentos realizados da rejeição 656 dentro da exceção (EACBrNFeException). Em anexo fonte com solução. Obs: Em analise no fonte da ACBrNFe, onde é gerado exceção retornando a property FMsg foi identificado que além das classes TNFeConsNFeDest (problema do Victor) e TDistribuicaoDFe (problema do Daniel) existem as classes TAdministr e TNFeDownloadNFe que geram exceção e não tem tratamento de retorno para a mensagem, então foi ajustado essas quatro classes para retornar a mensagem corretamente. Nesse fonte encontra-se juntamente a alteração do tópico: Alterações previstas em relação à revisão 8330 do svn. ACBrNFeWebServices.pas

Bom dia Srs. Desde a semana passada os serviços disponibilizados pela SEFAZ do MT estão instáveis. Diversos clientes reportaram problemas na transmissão das NFC-es, porém em analise aos logs gravados os erros estão em branco (cStat e xMotivo). Essa situação ocorre quando utilizado a forma de transmissão SÍNCRONA. Foi identificado então o erro de fato que esta retornando no estado do MT: 999 - Erro Não Catalogado, que seria segundo esse tópico problema com a própria SEFAZ. Porém quando ocorre esse erro (999) não esta retornando para o método, em virtude da SEFAZ do MT não gerar o grupo protNFe, então é assumido para o cStat = 0 (zero) e xMotivo = '' (branco). Sugiro então, realizar uma adaptação para caso não existir valor para os campos o cStat e xMotivo do grupo protNFe seja considerado os valores dos campos cStat e xMotivo do grupo retEnviNFe. Dessa forma é retornado o erro que de fato ocorreu e não valores em branco. Em anexo XML para analise e fonte com as alterações sugeridas. Alterações previstas em relação à revisão 8327 do svn. xml.xml ACBrNFeWebServices.pas

Deve estar bem diferente e com erros Juliomar, em virtude de ter sido adicionada no fórum a quase um mês e deve ter sofrido modificações, porém a alteração é apenas um número que muda de 1 para 0.

Eu entendi a quem estava sendo direcionada a pergunta Juliomar hehehe a questão é que não tinha porque não fucionar kkkk

O estado do MA esta processando apenas NFe em modo assíncrono. No processo de envio assincrono retornar o cStat 103 - Lote recebido com sucesso, nesse caso salve o recibo para ser possível realizar a consulta posteriormente (ACBrNFe.WebServices.Enviar.Recibo) Pode estar consultando da seguinte maneira: ACBrNFe.NotasFiscais.Clear; ACBrNFe.WebServices.Recibo.Recibo := Recibo; ACBrNFe.WebServices.Recibo.Executar; Obtém os dados nos seguintes campos: ACBrNFe.WebServices.Recibo.NFeRetorno.ProtNfe.items[ 0 ].cStat; ACBrNFe.WebServices.Recibo.NFeRetorno.ProtNFe.Items[ 0 ].xMotivo; ACBrNFe.WebServices.Recibo.NFeRetorno.ProtNfe.Items[ 0 ].dhRecbto; ACBrNFe.WebServices.Recibo.NFeRetorno.ProtNFe.Items[ 0 ].nProt; ACBrNFe.WebServices.Recibo.RetWS; Obs: O envio do Sincrono e Assincrono é passado no 3º parametro método enviar: ACBrNFe.Enviar(Lote, Imprimir, Sincrono).

Boa tarde Juliomar Resolve sim, é apenas uma diretiva de compilação, optei por fazer dessa forma para que o processamento de quem não utiliza Thread permaneça o mesmo. Para quem utiliza com Thread, basta adicionar a diretiva de compilação em seu projeto.

Boa tarde Leonardo. Estava tendo o mesmo problema que citou, no XML não estava sendo gerado os impostos dos itens serviço nas tags de serviço (ISSQN) estava sendo gerado nas tags de produto (ICMS) por isso ocorria divergência de valores. Pois no total da nota tinha valor de serviço porém nos itens tinha apenas valor de ICMS. Sugeri uma alteração e a mesma já se encontra no repositório da ACBr, verifique se esta com os fontes atualizados, se é o mesmo problema e se soluciona o que precisa. Essa situação foi relatada no seguinte tópico: Obs: Estou conseguindo transmitir uma nota conjugada sem problemas.

Ao ser validado um XML com o grupo D01 - Avulsa esta retornando erro: <avulsa> ID:D12/dPag(Data de pagamento do Documento de Arrecadação) - Nenhum valor informado. O campo dPag conforme consta no manual é opcional, porém na ACBr esta sendo validado como obrigatório. Foi alterado o método GerarAvulsa da unit pcnNFeW, alterando a ocorrência do campo dPag de 1 (obrigatório) para 0 (opcional). Em anexo a unit pcnNFeW.pas com a alteração realizada. pcnNFeW.pas

Boa tarde pessoal. Alguém já conseguiu autorizar uma NF-e 3.10 para o estado do MA de forma SÍNCRONA? Esta retornado cStat = 103 (Lote recebido com sucesso), onde esse retorno seria referente a forma ASSÍNCRONA. Apenas precisaria saber se alguém conseguiu autorizar, para certificar que o problema não seja apenas comigo. Porque pelo que tudo indica esse estado não esta preparado ainda para transmitir de forma SÍNCRONA. Acredito que teríamos que ter algum tratamento sobre essa situação, porque caso contrario, teria que ser verificado antes de autorizar uma NF-e que estado esta sendo processado e então passar de parâmetro SÍNCRONO OU ASSÍNCRONO. Obs: MA utiliza a Sefaz Virtual do Ambiente Nacional.

Bom dia Italo, Ou seja, oque venho questionando desde o inicio, não vejo uma possibilidade de gerar os DigestValue iguais. A unica forma seria ter o certificado em todos os pontos de vendas, mas se torna inviável, dessa forma não faria sentido a existência do token. Acredito que quem tenha feito o manual, sequer se deu o capricho de por em pratica essa teoria. Não tive mais retorno da SEFAZ, estou ficando sem alternativas.