Danny

Pessoal, só pra informar voltei pra capicom e resolveu. Comparei os xml gerados pela capicom e wincrypt e diferença está nas linhas abaixo na assinatura: wincrypt: <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> capicom: <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> Talvez não seja neste tópico que se trate essa questão, mas no meu caso está relacionado à NFe, onde a validação é feita pelo arquivo xmldsig-core-schema_v1.01.xsd, onde ocorre o problema na validação. <complexType name="SignedInfoType"> <sequence> <element name="CanonicalizationMethod"> <complexType> <attribute name="Algorithm" type="anyURI" use="required" fixed="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </complexType> </element> <element name="SignatureMethod"> <complexType> <attribute name="Algorithm" type="anyURI" use="required" fixed="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> </complexType> </element> <element name="Reference" type="ds:ReferenceType"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> Só não sei ainda como resolver a questão. Vou continuar os testes e qualquer novidade posto aqui.

Bom dia pessoal. Ocorreu também em um cliente meu depois da utilização do libWinCrypt, antes eu utilizava capicom. Infelizmente aqui no meu terminal com Win10 está normal, portanto não tenho como debugar de modo a aprofundar melhor nos fontes e detectar o que realmente está ocorrendo. No meu cliente fiz a atualização das cadeias do certificado icpBrasil v5 e atualizei as dlls da pasta DLLs\XMLSec\MinGW\32 do ACBr e não resolveu. Voltarei a utilizar a libCapicom no cliente e qualquer problema ou solução que encontrar posto aqui. Obrigado.

Olá Juliomar. Fiz a alteração que você sugeriu. Segue a unit em anexo. Obrigado. ACBrGNReGuiaRL.pas

Bom dia pessoal. Provavelmente deve ter havido uma mudança sim, apesar de não constar os novos códigos no manual. Fiz uma alteração na que resolveu o problema. Segue unit em anexo. Obrigado. ACBrSedex.pas

Tentei verificar o que ocorre, fiz vários testes em ambiente de homologação, mas não entendi o motivo pelo qual no retorno o campo PeriodoReferencia vez ou outra vem vazio. Na unit este campo é criado como ftString. Não entendo porque logo abaixo é tratado como "AsInteger". Creio que nesta situação o mais conveniente seria o except. Porém o que você sugere seria algo parecido com isso? if cdsItens.FieldByName('PeriodoReferencia').Text = '' then sReferencia := 'Mensal' else Case cdsItens.FieldByName('PeriodoReferencia').AsInteger of 0: sReferencia := 'Mensal'; 1: sReferencia := '1a Quinzena'; 2: sReferencia := '2a Quinzena'; 3: sReferencia := '1o Decêndio'; 4: sReferencia := '2o Decêndio'; 5: sReferencia := '3o Decêndio'; end;

Juliomar, a unit que você subiu está igual a que estava anteriormente com o problema. Será que você não se confundiu na hora de subir pro svn?

Bom dia colegas! Ocorre um erro na impressão e fiz uma alteração que resolveu. Por algum motivo o PeriodoReferencia vem vazio no retorno, mesmo sendo enviado corretamente, e gera o erro quando carrego o "resultado" para imprimir. Segue em anexo a alteração. Obrigado. ACBrGNReGuiaRL.pas

Boa tarde Ayrton, Observe que as alterações que fiz foi no Trunk1 e a mensagem que enviei é de quase 2 anos. Não estou utilizando o NFS-e no Trunk2. Seria necessário você fazer as alterações necessárias, já que está tendo problemas.

Boa noite pessoal. Ao consultar o CEP pelos correios não é gerada a exceção para minha aplicação. Fiz uma pequena alteração e resolveu o problema. Segue a unit em anexo. Obrigado. ACBrCEP.pas

Bom dia. O carregamento dos dados está sendo feito apenas na unit ACBrGNReGuiaRL.pas que transferi da ACBrGNReGuiaRLRetrato.pas. Presumo que a solução que implementei possa ser melhorada. Obrigado.

Bom dia pessoal. Também estava com o mesmo problema na linha: dsItens.dataset := cdsItens; Fiz algumas alterações, não sei se da maneira mais correta, mas a impressão normalizou. Seguem as units em anexo. Obrigado. ACBrGNReGuiaRL.dfm ACBrGNReGuiaRL.pas ACBrGNReGuiaRLRetrato.dfm ACBrGNReGuiaRLRetrato.pas

André, Observando melhor a unit notei que será gerado o grupo PISSN/COFINSSN quando a CST for 49, considerando a alteração que fiz.

Daniel, A contabilidade entrou em contato com a SEFAZ SP e a mesma orientou que "basta utilizar o grupo PISNT e utilizar o CST 04." para empresas do simples. Tenho uma cópia do e-mail da resposta da SEFAZ SP. Fiz as mudanças mencionadas no componente e o CFe foi gerado normalmente sem retorno de erros. Conforme mencionei o manual de orientações do leiaute indica que "O uso do subgrupo PISSN/COFINSSN são para contribuintes do Simples Nacional.", mas não informa que é obrigatório, sendo que a utilização do PISNT/COFINSNT gerou o CFe normalmente. Obrigado.

Bom dia pessoal. Apesar do manual de Orientações de Preenchimento de Campos do Leiaute do CF-e-SAT indicar que o uso do subgrupo PISSN/COFINSSN são para contribuintes do Simples Nacional há uma necessidade de contribuintes do simples utilizarem os subgrupos PISNT/COFINSNT, conforme orientações da contabilidade de um cliente. Por este motivo necessitei fazer uma alteração na pcnCFeW.pas (GerarDetImpostoPIS e GerarDetImpostoCOFINS) de modo que não force a sempre utilizar os sugbrupos PISSN/COFINSSN quando o regime de tributação é do simples nacional. Gostaria de propor esta alteração ou discutir a situação com os colegas. Segue unit em anexo. Obrigado. pcnCFeW.pas

Italo e pessoal da lista, boa tarde. Mais uma informação. O provedor do município de Cerquilho/SP foi mudado do SimplISS para 4R. http://cerquilho.sp.gov.br/produto.php?idp=MzYwNQ.. Fiz os ajustes nos fontes (Trunk1) e funcionou perfeitamente. As NFS-e foram transferidas de um provedor para o outro e a orientação da prefeitura é dar continuidade à numeração do RPS. Até breve!

Bom dia pessoal. Somente para informar que a URL do município de Cerquilho/SP foi modificada de http://187.45.245.217/ws_cerquilho/nfseservice.svc para http://wscerquilho.simplissweb.com.br/nfseservice.svc Obrigado.

Bom dia. Fiz a correção de um bug na impressão do DANFE, onde não saia o Complemento dos endereços de Retirada e Entrega. Seguem arquivos corrigidos. Obrigado. ACBrNFeDANFeRLPaisagem.dfm ACBrNFeDANFeRLPaisagem.pas ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLRetrato.pas

Boa tarde a todos. Fiz uma alteração na unit anexa necessária para gerar corretamente a GNRE. Obrigado. ACBrGNRE2.pas

Desculpe Daniel, Posso ter me equivocado nos testes, mas agora, com os fontes atuais, não encontrei problemas. Muito obrigado!

Daniel, voltei o FormatFloat somente nos campos que não aceitam decimais. Ao gerar o cálculo pelo site dos correios (http://www2.correios.com.br/sistemas/precosPrazos) esses campos não permitem entrada de decimais. Utilizando também a máscara #0 no FormaFloat gera o mesmo efeito que #,000. Deixando com FormaFloat se o componente receber por exemplo 31,25 será enviado 031 para o WS com a máscara #,000 O FloatToString proposto por você resolveu o problema do campo Valor Declarado, pois este é o único que aceita decimais. Obrigado.

Daniel, bom dia. Fiz novos testes com as alterações que você aplicou e resolveu parcialmente, mas gerou outro problema porque os campos de Peso, Comprimento, Altura, Largura e Diâmetro não podem conter casas decimais. No campo de valor declarado está correto o que você fez, enviando a casa decimal com o ponto. Fiz uma nova alteração e realizei novos testes (só não com o Diâmetro) e, acredito, ter resolvido definitivamente o problema. Segue em anexo a unit. ACBrSedex.pas

Boa tarde! Juliomar, considerando a máscara, neste caso o sistema envia o valor sem os decimais, pois o resultado é de 1 centavo considerando o centavo 04 e 99. Ou seja é enviado: &nVlValorDeclarado=1245& EMBarbosa, testei com o maior valor que o WS permite, no caso R$ 10.000,00. Mas esta máscara ignora os centavos. Obrigado pelo retorno.

Boa tarde pessoal. Encontrei um problema no valor declarado e fiz uma alteração na ACBrSedex: De '&nVlValorDeclarado=' + FormatFloat('#0.00', fnVlValorDeclarado) + para '&nVlValorDeclarado=' + FormatFloat('#0', fnVlValorDeclarado) + Estava tendo problema com valores acima de mil reais, onde estava sendo enviado por exemplo R$ 1.245,04 era enviado 1.245 e o WS entende isso como sendo um real (R$ 1.245). Segue anexo o arquivo alterado. Obrigado. ACBrSedex.pas

Pessoal, Consegui resolver segundo a recomendação do site: https://support.microsoft.com/pt-br/kb/884804 Foi somente corrigir o fuso horário do desktop que gerou a NF-e. De qualquer forma muito obrigado.

Boa tarde pessoal. O campo dhEmi no XML de uma NF-e ficou desta forma: <dhEmi>2015-12-23T00:00:01+04:30</dhEmi>, que gera o erro de validação em anexo. Utilizando o validador da SEFAZ-RS só consegui validar zerando o minuto dos "04:30". Tentando qualquer hora, seja positiva ou negativa, passa no validador, porém somente se não tiver os minutos. Estou certo que o componente está gerando corretamente na função TimeZone da unit synautil.pas. Acredito que o problema esteja no Schema da SEFAZ, porém não consegui fazer uma leitura de modo que eu tenha certeza que é no Schema (tiposBasico_v3.10.xsd): <xs:simpleType name="TDateTimeUTC"> <xs:annotation> <xs:documentation>Data e Hora, formato UTC (AAAA-MM-DDThh:mm:ssTZD, onde TZD = +hh:mm ou -hh:mm)</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:pattern value="(((20(([02468][048])|([13579][26]))-02-29))|(20[0-9][0-9])-((((0[1-9])|(1[0-2]))-((0[1-9])|(1\d)|(2[0-8])))|((((0[13578])|(1[02]))-31)|(((0[1,3-9])|(1[0-2]))-(29|30)))))T(20|21|22|23|[0-1]\d):[0-5]\d:[0-5]\d([\-,\+](0[0-9]|10|11):00|([\+](12):00))"/> </xs:restriction> </xs:simpleType> Provavelmente se alterar esta função no componente de modo que gere sempre "00" no minuto irá resolver o problema. Alguém já passou por isso e poderia me ajudar? Obrigado.