cdvdt

Bom dia, Essas informações estão na página 10 do manual, Layout do Arquivo-Remessa - Registro de Transação - Tipo 2, o layout exige algumas informações de endereço do pagador depois da quarta mensagem, o que difere da implementação padrão para o método.

Bom dia, Em anexo estão o patch para o arquivo, os fontes completos e o layout usado como referência. Desde já agradeço. ACBrBancoBradescoMoneyPlus.pas.patch ACBrBancoBradescoMoneyPlus.zip Layout_CNAB_400-10 (3).pdf

Bom dia, Gostaria de propor uma alteração em TACBrBancoBradescoMoneyPlus, com a adição da implementação do Registro de Transação - Tipo 2, de acordo com o layout recebido do banco em anexo, a remessa gerada já foi homologada com o banco. Envio, o fonte completo, assim como o patch, e o layout usado como referência. Desde já agradeço.

Analisando os fontes notei que a margem da configuração é sempre aplicada aos layouts, e se o utilizador do componente não defini-las, isso implica em zerar as margens, o valor padrão, e o problema acaba ocorrendo. Ainda analisando os fontes notei que cada layout tem configuração de margem diferente. Me parece que seria ideal haver um mecanismo para conservar as margens predeterminadas no layout, já que podem eventualmente ser alterados em alguma atualização, e os valores padrão são os que se espera serem corretamente impressos.

Bom dia, Gostaria de propor uma alteração na impressão de DANFe simplificada para Fortes Report, que permite a impressão da mesma no formato DANFe simplificada - Etiqueta, conforme descrita na NT 2020.004. Para possibilitar a impressão foi adicionado ao componente ACBrDANFeRL a propriedade booleana Etiqueta que, se ativa e com o TipoDANFE como tiSimplificado selecionado, altera a impressão mantendo as informações obrigatórias e suprimindo os itens. Envio tanto os arquivos finais utilizados como um patch aplicável aos arquivos. Desde já agradeço. ACBrDANFeSimplificadoFortes.rar ACBrDANFeSimplificadoFortes.patch

Acabei de testar e o erro persiste. É exatamente o mesmo erro.

Estamos credenciados, o desenvolvimento foi feito usando o ambiente de homologação de São Paulo.

Eu sei que o SAT é necessário para contingência offline, mas não afeta a operação normal, certo? Foi necessário trocar o SAT ou o certificado?

Boa tarde, Sou de um software de SP e temos uma implementação para NFC-e usando ACBr. Esse mês surgiu para um cliente também de SP a necessidade de NFC-e. Em testes de homologação o método enviar do componente ACBrNFE tem gerado a exceção EACBrDFeException com a seguinte mensagem: Erro Interno: -2146893815 Erro HTTP: 0 URL: https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeAutorizacao4.asmx Erro: 2148073481 - Notei que ocorre em decorrência de uma exceção EACBrWinReqResp interna ao ACBr. O exemplo do ACBr gera o mesmo erro, e a verificação de status gera erro semelhante. Requisições de status para outras UF não geram erro. Estou usando libWinCrypt, cryWinCrypt, httpWinHttp e xsLibXml2, e LT_TLSv1_2 para TLS. O nosso certificado é A3, e funciona normalmente para outras operações, incluindo emissão NF-e. Acompanhei as threads: Nenhum deles parece chegar ao ponto da solução. Existe algum problema com a emissão em São Paulo? É só para homologação? Os parâmetros de conexão são esse mesmos?

Boa tarde, Envio uma imagem sim, a primeira página é o boleto no layout lPadrao, a segunda página é um segundo relatório FortesReport adicionado através da propriedade verso, proposta na alteração. Caso nenhum relatório seja associado a propriedade o boleto é impresso como tradicionalmente. Att.

Boa tarde, Queria propor a adição de uma propriedade à classe TACBrBoletoFCFortes de impressão do boleto usando FortesReport, para permitir a impressão de uma página de verso no boleto, que poderia ser usado para, entre outras, informações do correio. O arquivo anexado já foi devidamente testado. Desde já agradeço. ACBrBoletoFCFortesFr.pas