carlosmarian

Tbm recebi esta mensagem durante o processo de homologação.

Olá O link "Manual do web service de Blumenau em:" parece que não funciona mais. at+

Olá Fernando, que bom que o problema se resolveu para vc. Não tive mais relatos de clientes com este problema, eu não formatei e nem cheguei a atualizar o ACBr. Muito estranho... vou ficar monitorando. at+

Olá Fernando, Vou avaliar a possibilidade de atualizar o ACBr. No meu caso tbm continua acontecendo só que é bem esporádico, hj teve só um caso. Quando corre mando gerar novamente o XML e passa. Vou verificar, até mais.

Olá, O erro voltou a ocorre comigo, Avaliando os arquivos gerados pelo ACBr, uma coisa que pude constatar ao comparar o arquivo que é assinado(CHAVENFE-NFE.XML) com o arquivo de envio de lote(LOTE-env-lot.xml): no item do xml assinado a tag "vICMS" tem o valor "<vICMS>4.46</vICMS>", já no arquivo de lote a tag tem o seguinte valor "<vICMS>0.00</vICMS>". Acredito que isso possa indicar a falha. Assinado ... <imposto> - <ICMS> - <ICMS00> <orig>0</orig> <CST>00</CST> <modBC>3</modBC> <vBC>26.25</vBC> <pICMS>17.00</pICMS> <vICMS>4.46</vICMS> </ICMS00> </ICMS> ... Lote: ... <imposto> - <ICMS> - <ICMS00> <orig>0</orig> <CST>00</CST> <modBC>3</modBC> <vBC>26.25</vBC> <pICMS>17.00</pICMS> <vICMS>0.00</vICMS> </ICMS00> </ICMS> ... at+

Olá, Tbm passeio e ter este retorno deste de ontem(29/10/2013). Como o Fernando, como tbm o erro é temporal, envia a nota e é retornado o erro e ao retransmitir passa sem falha. Estou aguardando ocorrer novamente para obter os xml´s e poder comparar. Minha revisão do ACBr é 5889 At+

Olá, mas o correto então não seria RightStr? Imagine um campo nosso nro com o seguinte valor "000000000004" Da forma como foi implementado hj ele iria trazer "0000000" e não "0000004" como estava trazendo antes. No aguardo.

~ç

Valeuu muiito obrigado.

Juliana, referente a este alteração, procurei no histórico do SVN e encontrei um outro ajuste que foi feito no método "TACBrBancoSantander.GerarRegistroTransacao400(ACBrTitulo :TACBrTitulo; aRemessa: TStringList);". Na descrição do post fala somente da necessidade de ajuste na geração da linha digitada, e não na remessa. Antes estava assim: "Copy(NossoNumero,6,7) + DigitoNossoNumero +" Agora esta assim: "padR(LeftStr(NossoNumero,7),7,'0') + DigitoNossoNumero +" Este ajuste gerou falha(divergência) no meu teste unitário após a atualização. Minha pergunta qual necessidade gerou esta alteração, é que preciso verificar se realmente tenho que revisar meu teste Obrigado pela atenção. at+

Olá Italo, já existe uma previsão para esta liberação? Valeu....

Olá Acacio, Eu uso um relatório personalizado para impressão do danfe(e gerar PDF) não o padrão do ACBr. Investi mas algumas horas ontem nesta rotina e acredito que tenha corrigido o problema, revisei a minha rotina de semáforo e o erro de impressão parou de ocorre. Estavam ocorrendo acessos simultaneos ao componente de impressão, que acabavam gerando o erro. Valeu.

Olá, é no meu caso casa thread tem uma conexao com o banco e um objeto NFe, o processo de emissão esta indo bem, consigo transmitir varias notas em um curto espaço de tempo. O meu problema esta mesmo na hora de imprimir e gerar o PDF para encaminhar o email, para estas atividades não uso componente do ACBr devido a padrões definidos pela empresa. Isso é que esta me dando um pouco de problemas. Deixando a rotina instável.

Olá Acacio, Vc teve algum problema com a impressão do DANFE usando Thread? Em alguns casos quando tenho uma grande massa de notas em processamento, caso alguma delas demore muito para imprimir(muitos itens por exemplo) tenho um erro gerado quando é iniciado um novo processo de impressão. Falha: "Impressão em progresso" at+

Para Blumenau tive que implementar o processamento da NFSe usando C#. Boa sorte.

Alansst, a alteração do Isaque corrigiu o problema, a princípio não identifiquei outro erro. at++

Olá, O cliente efetuou o envio de um CTe mas recebeu este erro : "A nota foi enviada mas gerou erro durante a consulta: A connection with the server could not be established - URL:https://cte.sefaz.rs.gov.br/ws/cteretrecepcao/CteRetRecepcao.asmx - SOAPAction:http://www.portalfiscal.inf.br/cte/wsdl/CteRetRecepcao/cteRetRecepcao". O CTe foi validado junto a sefaz mas o erro ocorreu quando o ACBr foi buscar os dados do envio(ainda no método WebServices.Envia). Alguém já passou por isso? Será que existe uma forma de contornar isso? Outro detalhe é que depois que esta exceção foi gerada, outros erros de falha de memória foram gerados e não foi mais possível enviar nenhum CTe até que a aplicação fosse fechada. Parece que neste caso alguma variável não esta sendo finalizada corretamente. Tentei encontrar o motivo mas não consegui. At+

Olá... Mas se a nota foi emitia a menos de 5 horas do momento em que foi solicitado o cancelamento? Isso não pode gerar um problema? At+

Matéria na SEFAZ AM: http://www.sefaz.am.gov.br/noticias/ExibeNoticia.asp?codnoticia=8144 SpedBrasil: http://www.spedbrasil.net/forum/topics/mdf-e-obrigatoriedade-ajuste-sinief-10-2013

Olá Eisenheim... Alguma novidade referente ao componente de FCI? At+

Bom dia, em contato hj cedo com a SEFAZ fui informado que o erro era lá com eles. estabilizado segundo eles foi corrigido no final da noite de ontem(sem detalhes do motivo ou pq não foi atualizada a informação no site). Hj fiz um contato com o cliente e ele me informou que os cancelamentos passaram a ser processados sem erro. at+

Olá, tenho um cliente do CE que ao tentar cancelar nota esta obtendo o retor 239 - "Cabecalho - Versao do arquivo XML nao suportada" Alguém esta passando por algo similar? Obrigado.

Olá, OK Isaque, sua sugestão de alteração tbm resolveu o problema, Eu anteriormente não tinha percebido, mas o erro do R05 tbm refletia no registros 0200 do SPED, com esta sua sugestão de correção tbm ajustou o sped; Valeu. at+

Olá, Atualizei recentemente o ACBR e ao comparar os arquivo gerados antes e depois da atualização verifiquei uma pequena diferença no valor gerado para o campo "NUM_CONT" na linha R05. Antes gerava "042165" depois da atualização passou a gerar "421650", completando o valor com o zero a direita e não a esquerda. Avaliando o código verifiquei a seguinte alteração no código: Antes era: "LFill(RegR04.NUM_CONT, 6) +" e agora é : "LFill( IfThen(NUM_CONT=-1, RegR04.NUM_CONT, NUM_CONT), 6) +" Ao debugar vi que o método LFILL que é invocado depois da alteração é o com a assinatura : "LFill(Value: Currency; Size: Integer; Decimal: Integer = 2; Nulo: Boolean = false; Caracter: Char = '0'; Mascara: String = ''): String; overload;"; e não com a assinatura "LFill(Value: Integer; Size: Integer; Nulo: Boolean = false; Caracter: Char = '0'): String; overload;" Para contornar eu fiz a seguinte alteração de: "LFill( IfThen(NUM_CONT=-1, RegR04.NUM_CONT, NUM_CONT), 6) +" para: "LFill( IfThen(NUM_CONT=-1, IntToStr(RegR04.NUM_CONT), IntToStr(NUM_CONT)), 6) +" Mas eu acredito que não seja a melhor forma, outra coisa que vi é que o método "ifthen" que é chamado e o "function IfThen(AValue: Boolean; const ATrue: Char; AFalse: Char): Char; overload;" que esta na classe "ACBrSpedUtils" e não na classe "ACBrUtil". Acredito que se passar a usar o IFTHEN do ACBRUtil já deve corrigir isso pq ele tem uma assinatura que recebe dois valores inteiros e que retorna um iteiro, diferente dos que hj estão disponíveis no "ACBrSpedUtils". No aguardo. Obrigado pela atenção.

Olá, agora o IBTP disponibilizou um novo arquivo sem o ";"(ponto e virgula), trocaram por ","(vírgula). At++