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).