Painel de líderes

Boa tarde Eu fiz algumas alterações ontem, corrigindo a retrocompatibilidade do componente, caso seja necessário gerar o arquivo com data anterior a 2017. Também corrigi o contrato Dercide, obrigado pela dica. Segue a unit corrigida Atenciosamente. ACBrConvenio115.pas

Existe a diferença entre os regimes tributários existentes, e você tem que saber como proceder para cada um. O software é o responsável pela "alimentação" dos parâmetros, o Total.vCFeLei12741 nada mais é do que a soma de todos os Imposto.vItem12741.

Fui olhar os fontes e descobrir o problema e na seguinte linha: o AcbrmonitorPlus lê dois digitos da sequencia do reboque, e eu estava gerando com 3 digitos seguindo o padrão dos outros sequenciais. sSecao := 'reboque' + IntToStrZero(I, 2); [reboque001] placa=OLL1630 RENAVAM=00537562621 tara=8980 capKG=23000 tpCar=01 UF=TO gerei depois como: [reboque01] deu certo desta forma.

Boa tarde, além do que o KIKO informou, mais algumas considerações: CFOP=6405 não existe, existe 6404. Abaixo do COFINS de cada item: </COFINS> -<ICMSUFDest> <vBCUFDest>0.00</vBCUFDest> <pFCPUFDest>0.0000</pFCPUFDest> --> Precisa ver as alíquotas de SC para RS, abaixo é de SP para MS <pICMSUFDest>18.0000</pICMSUFDest> <pICMSInter>7.00</pICMSInter> <pICMSInterPart>60.0000</pICMSInterPart> <vFCPUFDest>0.00</vFCPUFDest> <vICMSUFDest>0.00</vICMSUFDest> <vICMSUFRemet>0.00</vICMSUFRemet> </ICMSUFDest> Você está colocando valores aqui: <vICMSDeson>0.00</vICMSDeson> <vICMSUFDest>17.64</vICMSUFDest> --> deixa zerado <vICMSUFRemet>11.76</vICMSUFRemet> --> pode tirar esta linha Faça o teste com estas mudanças para ver se dá certo. Sds, Ricardo.

No svn as alterações!

Já que essas certificadoras afirmam que o conteudo do certificado está sendo apagado por aplicativo de terceiros, também deveriam explicar o porquê de serem tão vulnerávels e apresentar o log que comprove quando e como isso ocorreu. Isso pra mim é desculpa esfarrapada e uma tremenda falta de ética profissional para encobrir falhas do produto que comercializam. Que inventem meios de tornar os certificados mais seguros.

Pessoal, entrei no forum por conta deste tema. Tenho um software que usa esse serviço da SEFAZ, meus clientes estão loucos e não tenho como provar que o problema esta do lado deles e não do nosso. Abraço!

O componente já faz isso pra você, basta você configurar corretamente o caminho onde quer salvar os XML´s retornados pelo aparelho. Exemplo: ACBrSAT.ConfigArquivos.PastaCFeVenda := 'C:\SAT\VENDA\'; ACBrSAT.ConfigArquivos.PastaCFeCancelamento := 'C:\SAT\CANCEL\';

rs... Acho que não tem pra quem chorar, pois pode ter certeza que tem alguém correndo atras disso lá. Pra ti comparar, nesse momento, estou com 23 horas de diferença. mas domingo chegou a ter mais de 30. Que eu me lembre, nunca teve um atraso que demorasse tanto tempo pra recuperar. Pra quem quiser acompanhar, é só criar um controle pra comparar a data de autorização com a data de recebimento do resumo... eu faço isso no PRTG a alguns meses, e tenho um indicador que me mostra a média das ultimas horas, por isso consigo acompanhar os atrasos sem ter que ficar fazendo teste...

era isso mesmo, o tipo de convenio 1, nao permite boletos de sistemas fora do banco, desculpe o incomodo, primeira vez que pego uma conta assim Obrigado

Juliomar, As alterações foram feitas conforme o manual referente a 2017. Essa unit que postei é a que estava no SVN, apenas corrigi conforme relatei. Dercide.

Não sei se já leu as regras do fórum mas por favor poste em um é aguarde pois este é o segundo tópico em que posta o mesmo texto!

Correção no svn! está sendo aplicado conforme o manual certo?

A solução é simples... não use espaços nos nomes das pastas...

Não é uma limitação do ACBrInstall... O compilador de linha da Embarcadero, não se dá bem, com pastas com espaços ou caracteres especiais no nome..

Realmente não existe. O XML original não é alterado com o cancelamento. Para apurações contábeis, ele deve ter a posse dos dois arquivos (venda e cancelamento).

Jéter, No arquivo de itens, o campo 28 ( Numero do Contrato ) esta com 25 posições e o correto são 15. function TACBrConvenio115Item.RegistroEAssinatura(AVersaoAnterior: Boolean): TConvenio115AssinaturaMD5; Linha 947 ==> 28) Contrato => são 15 digitos e não 25. Isso esta causando erro na geração do arquivo, pois o mesmo esta sendo gerado com 342 posições por linha e o correto são 331. Segue a UNIT que esta no SVN alterada e testada. Dercide. ACBrConvenio115.pas

Dercide, A Unit do Jéter estava dando erro, SVN até ontem a hora que consultei não tinha sido atualizado ainda. João Paulo

Bom dia Dercide. Baixei o que você postou na quarta-feira e funcionou, consegui validar o arquivo. Aparece uma advertência na validação para clientes com CPF: MEST 154-CNPJ numericamente inválido, porém consegui validar e Gerar Controle normalmente. Muito Obrigado! João Paulo

Bom dia amigo, aqui eu emito normalmente todos os DF-e's com as configurações em anexo, já em relação ao motivo, não sei dizer ao certo, mas acredito que deve estar relacionado à forma com que o WS é estruturado mesmo, acredito que fuja um pouco de nosso controle, posso estar enganado, mas é minha opinião.

Boa noite. Atualizei a unit e gerei o arquivo. Porém na hora de validar apresenta o erro: Quantidade de bytes do aquivo item (38.073) não é um múltiplo de 333. Abro o arquivo item e ele está com 342 caracteres por linha. Se alguém tiver alguma ideia do que pode ser, grato. Att João Paulo

No svn a mudança.

Boa tarde, Opção 1: Sim Opção 2: Posta o XML gerado Opção 3: Não tenho aqui impresso nenhum em produção para lhe mostrar, mas vai sair os dizeres abaixo que a SEFAZ completa no XML como abaixo: -<obsFisco xCampo="01.02.01.02"> <xTexto>Consulte o QRCode deste extrato atraves do App DeOlhoNaNota</xTexto> </obsFisco> Sds, Ricardo.

Boa tarde! Realmente tem erros no teu arquivo. Teu XML 1=Operação interna; 2=Operação interestadual; 3=Operação com exterior. Veja que não é operação interna e sim interestadual. O emitente está em SC e o destinatário está em RS Nos itens vc informou CFOP 6405. Não existe este CFOP na tabela de CFOP válidos. Item 1 e item 2 Não sei se tem mais erros, foi o que percebi. Também não sei te dizer se este erro dá falha em schemas, mas que está errado isto posso te afirmar.

@Juliomar Marchetti encontrei outra situação com o validador. Está passando teste OK para o email com a seguinte formatação : marcelo.bortolini@gmail Isso ocorre pois nos testes não é verificado se o '.' está depois do '@' Alterei a função para executar o teste : Segue .pas para análise ACBrValidador.pas

Boa tarde favor atualizar e testar no svn

Boa tarde Nao daria para usar o comando Consultar pra atualizar o xml com a autorizacao ? (Nao eh a toa q no manual da emissão em Contingencia offline da NFCe eh sugerido pular a numeraçao a fim de evitar duplicidade) Outro dia eative vendo um video sobre esse assunto q o cara chamou essa sua situacao de "buraco negro".... Att Ricardo

Olá! Poderia dizer o que fez para resolver o problema? Pois em alguns clientes que usam bematech o problema de espeçamento ocorre. Obrigado!