Régys Silveira

É a mesma nota eletrônica, igualzinha, mas impressa em formato resumido conforme a nota técnica 2012/01, isso já tem um tempo que está sendo testado no RS, cerca de 1 mês. Mas sinceramente eu acho complicado por uma série de fatores que já foram até discutidos em outro tópico aqui do fórum que foi aberto para discutir isso quando do lançamento dela no RS.

Acho que respondi estás perguntas a cima, nada vai mudar, continua como estava antes, quanto ao André postar, eu penso que ele continuará mantendo o blog dele como sempre foi. Olhem, nada muda, continua como sempre foi, independente do SAC ou não, o desenvolvimento do monitor continua, o ACBr vai ficar cada vez melhor com a ajuda de todo mundo, não precisa ter medo ou receio, tudo continua como sempre foi. Vejam que respondi 4 formas diferentes de acompanhar as mudanças e somente uma delas é relacionada ao SAC, se contarmos com o blog do André então são 5 formas. Fiquem tranquilos, nada muda, o ACBr vai continuar sendo sempre o que é e com a ajuda de todo mundo melhorando cada vez mais.

Aparentemente a sua versão do JCL e JVCL não possuem a constante esperada que é mostrada na mensagem de erro, para implementar o ACBrInstall utilizamos o JCL e JVCL baixados diretamente do repositório de fontes do JEDI e não aquele que é disponibilizado no site, pode ser isso.

Existem arquivos texto de controle do que é alterado nos diretórios geralmente começados por "changelog", neles são registradas as datas, alterações e quais usuários efetuaram a alteração ou envio para o repositório, talvez isso lhe ajude.

Envie um arquivo de log do ACBrECF de quando ocorre a situação para que possamos lhe ajudar.

Se você utiliza o componente e possui o repositório, basta atualizar a acompanhar as alterações pelo histórico. Se você é usuário do ACBrSAC vai ser postado o aviso e a versão atualizada. Se você é usuário do ACBrNFeMonitor que baixa pelo sourceforge aguarde uma nova versão compilada.

Opa, falha minha, , foi mal mesmo.

Mas foi isso que te passei lá atrás:

Para que as alterações possam ser validadas é necessário que sejam postados os arquivos alterados, não fazemos validação de alterações com trechos de código.

Não existe na lei nenhum texto padrão tanto para o corpo do e-mail quanto para a própria carta de correção em si, na verdade a impressão da carta de correção nem é prevista, portanto, você poderia fazer como bem entender. Aqui eu gosto de colocar no corpo do e-mail as informações básicas da nota fiscal (numero, serie, data, etc), emitente (razao social, cnpj) e destinatário (razao social, cnpj) e um texto citando a lei que regulamenta a emissão e a guarda dos XMLs para que o usuário saiba como proceder quanto ao recebimento e guarda dos arquivos.

Quanto ao evento de cancelamento as mudanças são transparentes para o usuário, porque são alterações internas, não vai mudar a forma que é hoje, bastaria recompilar o ACBrNFeMonitor quando liberarmos as alterações e pronto ele já vai estar funcionando como deve. Quanto as validações também é transparente, o webservice vai retornar os erros para o monitor e o monitor retorna para o aplicativo que deve então tratá-los.

Eu compilei ele em XE2 e compila normal, provavelmente vai funcionar com o XE também.

Para compilar o ACBRInstall e necessário o Delphi 2010, ACBr, JCL e a JVCL instalados.

Qual UF, se for PR não estava mesmo passando.

Sim porque os erros partem do webservice e não do componente, todos são erros de retorno.

Anexe a unit modificada, mesmo sendo trechos pequenos precisamos do arquivo para comparar no todo. Quanto a modificação, eu tenho aqui o ACBr instalado no XE2 e funciona perfeitamente, não foi necessário fazer nenhum acerto, qual era a mensagem de erro?

Eu olhei o artigo, bastante interessante, mas veja que o artigo já tem mais de 1 ano, o ACBr evoluiu muito neste período, se você fizer como disse e consultar o demo do ACBrEAD vai ver que não precisa fazer tudo aquilo para gerar o par de chaves e inclusive o demo já gera o arquivo xml para utilizar no eECFc, quanto a utilização das chaves basta a chave como é gerada inclusive com as quebras de linha que o componente assina e valida corretamente. Para validar agora pode-se utilizar o chave publica ou o próprio arquivo xml que é utilizado no eECFc, basta passar o conteúdo do arquivo xml na variável chave do evento.

Eu fiz uma atualização agora a tarde, atualize e teste. As chaves você está informando no formato RSA correto, como o gerado pelo exemplo do ACBrEAD. Veja o exemplo ACBrEAD em \exemplos\ACBrEAD, lá tem a demonstração de tudo que se pode fazer com ele, geração de par de chaves, arquivo eECFc, validação, etc, etc.

O seu ACBr está atualizado pois hoje estou fazendo testes com ela para fazer alguns acertos e está tudo funcionando corretamente. Como você está passando as chaves?

O erro ocorre justamente porque o retorno não é nada do esperado, são situações que o componente não espera e o software deveria tratar visto que algo falhou.

Também acredito nisto, pois se pegarmos o conteúdo do arquivo ped-cce e validarmos em: http://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx não apresenta erros. Isso mesmo Kiko e o retorno em branco para alguns casos demonstra a falha de comunicação, já em outros casos o erro é de versão do cabeçalho, o ACBr está gerando corretamente conforme as versões liberadas, parece que o webservice é que não está validando está versão corretamente.

depende da mensagem, veja que existem vários eventos no ACBrECF, estude cada um deles.

Esse retorno ai é de erro por isso não salva. O Webservice parece não estar funcionando corretamente pois vários usuários tem relatado o mesmo erro, aguarde a normalização e tente novamente.

Utilize "CCeRetorno.retEvento.Items.RetInfEvento.XML" ou o arquivo salvo na pasta setada em configurações do ACBrNFe

Chegou a olhar o demo que existe em acbr\exemplos\ACBrBoleto?