everson.turossi

Já passei por inúmeras bizarrices do gênero e uma pratica adotei sempre que algo anormal acontecer é apagar o arquivo .dproj e similares, que a cada nova versão do Delphi vão aparecendo novos, e então reabrir o projeto a partir do .dpr para que sejam recriados. Acontece que o que foi citado pelo Juliomar diversas vezes como "configuração do projeto" ficam gravadas no .dproj então pouco adiante formatar maquina, reinstalar Delphi e ACBr se o arquivo problemático continua existindo.

Também me deparei com a mesma situação em relação a Protesto em Dias Úteis, todavia não podemos esquecer que a simples alteração na instrução de protesto impressa no boleto precisa ser condizente com a instrução de protesto da remessa. E é ai que a coisa se complica pois cada banco tem suas particularidades, alguns possuem opção para informar se será em dias úteis ou dias corridos, outros pedem a data de protesto, outros por "primeira ou segunda Instrução/Comando" e talvez eu tenha esquecido mais alguma. Infelizmente a única maneira de resolver tal situação integralmente seria a revisão de todas as Units de geração de remessas baseando-se na ultima versão do layout de cada tipo de cobrança para cada Banco, o que complica é reunir todos os layouts atualizados, pois a maioria dos Bancos não o disponibilizam em seus sites, e ao solicitar junto ao gerente de alguma agência, nem sempre lhe enviam a versão mais recente.

Uma sugestão. Não sei qual gerador de relatórios está usando, mas o FastReport oferece maior flexibilidade na alteração do layout sem a necessidade de persistir a alteração para os demais usuários do ACBr. Eu mesmo customizei o layout para impressão de boleto em impressoras portáteis deixando apenas 1 das vias. Acontece que tais solicitações por parte do Banco dependem muito do Humor da pessoa que está homologando pra ti. Horas pedem uma coisa, horas pedem outra. Se for atender a tudo que pedem, daqui a pouco os boletos terão que ser impressos no formato A1.

Passei pela mesma situação em duas Estações, nada de gerar BPL´s, uma com Berlin Starter e a outra Berlin Enterprise "trial".

ACBrBoleto.pas ACBrBoletoFCFR.pas ACBrNFeDANFEClass.pas ACBrNFeDANFEFR.pas ACBrNFeNotasFiscais.pas Fontes anexados. Algumas Observações: - No momento está gerando PNG apenas para Boleto e Danfe em FastReport. - Criei a propriedade PNGResolucao, pois como a motivação para essa implementação é a integração com impressoras portáteis, em 96 que é o padrão de exportação de PNG no Fast não teve boa legibilidade na impressão. - As imagens geradas são Monocromáticas e estão sendo cortadas automaticamente, para isso não criei nenhuma propriedade pois acredito que o que deve mudar de uma impressora para outra é a adaptação em relação a resolução. - Talvez haja necessidade de criar uma diretiva de compilação para o Fast pois não sei precisar desde que versão passou a exportar também para PNG, pois na paleta de componentes ainda não aparece um componente para imagem PNG como outras, mas o recurso já está disponível.

Bom dia. Vou baixar os fontes e promover as alterações.

Utilizamos o ACBr a longa data para emissão de documentos fiscais e sempre nos atendeu muito bem. Recentemente implantamos um módulo para venda em pronta entrega, onde utilizando-se de um Smartphone e uma Impressora portátil o vendedor realiza o pedido, transmite para um webservice e é feito a autorização da NF-e. Em seguida é impresso no local da venda Danfe e Boleto ambos no formato Simplificado. Estamos utilizando Danfe e Boleto em FastReport (v5.3.14) devido a licença do Delphi Berlin e também pela facilidade de adaptação do layout na impressora, e formato PNG por gerar arquivos menores que JPEG. Impressoras portáteis tem suas limitações mas trabalhando com PNG ocorreu tudo certo. Já foi feita a implantação junto ao cliente, e antes de anexar os fontes resolvi abrir este tópico para debater minha contribuição/necessidade e caso venha a ser aceita, anexo os fontes com as alterações propostas.

O tópico está sem movimentação a algum tempo, mas vou relatar aqui minha situação. Dentre as várias limitações que podem ser aplicadas a um servidor de e-mail para evitar o consumo indevido, uma delas é a quantidade de vezes que um ip/usuário pode se logar ao servidor durante um tempo X (normalmente 1 minuto). Exemplificando: preciso enviar 100 e-mails, porém o servidor está configurado para permitir que eu me logue apenas 20 vezes no servidor no prazo de 1 minuto, e que o tempo estimado para o envio de 100 emails fosse de 20 segundos. Acontece que para cada e-mail que o ACBrMail envia, ele abre uma conexão, envia, e fecha a conexão ao final do processo. Para resolver o problema de forma bem simples (gambiarra), eu poderia aplicar um intervalo no envio de cada email, porém ao invés de enviar os 100 e-mails em 20 segundos, eu precisaria de pelo menos 5 minutos. Essa restrição existe, mas pode ser resolvida facilmente enviando todos os e-emails em uma única conexão, claro que usando thread muda um pouco, mas também é possível. Estou desenvolvendo um Gerenciador para NF-e/CT-e onde o usuário pretende enviar muitos e-mails de uma única vez, e da forma como está funcionando o ACBrMail não consigo utiliza-lo, e terei que desenvolver uma solução própria para tal, mas estou disposto a faze-la no próprio ACBrMail para que possa ser utilizada por outros que tiverem a mesma necessidade.

Muito Obrigado.

Efetuei uma alteração na consulta da situação do MDF-e para que as informações da UF e município de encerramento do manifesto sejam lidas. Utilizo esta opção na consulta para atualizar informações no banco de dados que não foram atualizadas quando o MDF-e foi encerrado. ACBrMDFeWebServices.pas

SourceForge está passando por manutenção neste momento.

http://sourceforge.net/blog/

Olha só, tenho dois ambientes de testes cadastrados. A certa de 1 ano a traz quando implementei a NFS-e para Betha, ambos funcionavam perfeitamente. Quando migrei para o trunk2 me deparei com essa situação, e como o componente não estava operacional para esse provedor, cheguei a pensar que fosse problema no componente, porém após a implementação do Italo para provedores onde tem que assinar tanto o RPS quanto o Lote, o erro persistia, até que em outro tópico outro usuário falou que estava funcionando em produção e resolvi arriscar também. Pesquisando no fórum, encontrei um tópico onde usuários estavam relatando esse mesmo problema no ambiente de produção e foi constatado que se tratava de erro interno do sistema da Betha e não no componente. Tal erro foi corrigido no sistema em produção, mas parece que no ambiente de testes não. Continuo usando as mesmas bases de dados que usei na implementação. Só as uso exclusivamente para emissão de NFS-e e a integridade dessas bases continua a mesma de quando funcionava perfeitamente o webservice. Propositalmente tentei simular situações de erro como número de lote repetido e numero de RPS já emitido, e para esses casos o tratamento foi correto, identificou cada uma das situações, mas para emissão de novas NFS-e´s não foi nem com reza braba. Não cheguei a criar um novo ambiente de teste para verificar se o problema persiste, mas os que criei a 1 ano atrás estão totalmente inoperantes.

Em produção está funcionando perfeitamente. Esse problema ocorreu comigo também e não consegui de jeito algum emitir NFS-e no ambiente de homologação quando migrei para o trunk2. Cheguei a comparar um XML de lote gerado atualmente com outro gerado quando meu ambiente de homologação ainda funcionava e não encontrei divergências. Sugiro que entre em contato diretamente com o pessoal da Betha, porque o componente está OK.

Tenho implementado aqui para o provedor Betha uma rotina que verifica na Consulta de NFSe por RPS se uma nota foi substituída por outra e executa a atualização dos dados no banco. A informação que preciso vem na tag NfseSubstituidora. Segue as units alteradas. ACBrNFSeWebServices.pas pnfsNFSeR.pas

Passei por um problema semelhante no passado, e o que aconteceu é que na prefeitura quem cadastrou a empresa para o ambiente do provedor acabou esquecendo de cadastrar a inscrição municipal da empresa. Também era provedor Betha e em ambiente de produção. Você mesmo pode verificar isso acessando o sistema da Fly e-nota, vai em Opções e depois em Dados do Contribuinte e lá pode verificar se a Inscrição Municipal está cadastrada, ou como está cadastrada, pois acredito que se estiver cadastrada com formatação poderá não funcionar corretamente.

Dercide Alvarez, eu tive um caso no passado aonde a prefeitura não cadastrou a Inscrição Municipal da empresa, também não passava. Quanto ao ambiente de homologação, eu testei quando implementei, depois nunca mais verifiquei. Porém agora com o Trunk2 tive que revisar e me deparei com essa situação desconfortante. Outra coisa, já ouvi boatos no passado de que ao cadastrar a empresa em determinado provedor, foi cadastrado cnpj ou inscrição municipal com formatação, e por esse motivo surgiam erros como CNPJ ou Inscrição Municipal não encontrados.

ALA, fiz uma depuração aqui e cheguei também a esse resultado. Acontece que o que sugeri no post de "Postado quinta às 17:16" e também foi sugerido por outro usuário em outro post, faz com que esse erro de "A string literal was expected, but no opening quote character was found" pare de acontecer no provedor Betha, mas ai começa acontecer para o BHISS. Dercide Alvarez, aqui tenho apenas implementado a emissão para o provedor Betha, mas como relatei em um post anterior, só tive problemas no ambiente de testes, porém no ambiente de produção está funcionando perfeitamente. Acredito que seu caso pode ser também problema no ambiente de homologação. Toda via, verifica se não está passando CNPJ com formatação, ou qualquer outro caractere que não seja numérico.

Em relação ao provedor Betha tenho algumas considerações para a NFS-e do trunk2: Em ambiente de homologação não consegui autorizar nenhuma NFS-e. Todos os meus lotes resultam no erro "99999 - erro desconhecido". Cheguei a comparar o xml de lote gerado atualmente com o xml de lote antigo que autorizado a alguns meses, aparentemente estão iguais. Propositalmente tentei emitir NFS-e com número de lote repetido (Betha valida isso) e também com numero de RPS repetido, e o erro retornado no processamento do lote identificou corretamente cada uma das situações. Não resta dúvida que meus dois ambientes de teste estão com problemas. Em ambiente de produção, testei o Envio de NFS-e e também a Consulta de NFS-e por RPS, ambos estão funcionando perfeitamente.

Inicialmente tenta fazer ai uma depuração, e verifica se pra esse provedor ele está passando pelo mesmo trecho de código que citei a cima. Verifica também o valor das variáveis, pois no meu caso estava passando desapercebido a ausência de uma das aspas duplas.

Desde que migrei para o trunk2 os erros de webservice no provedor Betha é o "99999 - erro desconhecido"

Depurando cheguei até a seguinte conclusão: Quando chega aqui nesta linha: xmldoc.setProperty('SelectionNamespaces', SelectionNamespaces); o conteúdo do da variável SelectionNamespaces é o seguinte: xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3=http://www.betha.com.br/e-nota-contribuinte-ws" está faltando a aspa dupla depois de xmlns:ns3= Continuando a depuração cheguei até a unit ACBrNFSeWebServices onde é gerado o valor para essa variável na procedure TNFSeWebService.DefinirSignatureNode(TipoEnvio: String); onde é usada uma variável local "i" onde a mesma é atribuída da seguinte forma: i := pos(EnviarLoteRps + xmlns, FPDadosMsg); i := i + Length(EnviarLoteRps + xmlns); e alterei para: i := pos(EnviarLoteRps + xmlns, FPDadosMsg); i := i + Length(EnviarLoteRps + xmlns) - 1; Ainda não consegui autorizar nenhuma nota no provedor Betha, mas o erro mencionado foi resolvido.

Me equivoquei na hora em que colei o nome da unit, na verdade é na unit "ACBrDFeCapicom", mas ainda não encontrei solução.

Edita o arquivo "Cidades.ini"

Acabei de atualizar os fontes, porém ainda não consegui transmitir nenhuma NFSe para o provedor Betha a partir do trunk2. Acompanhando a outros tópicos, vi que em um deles o Italo mencionou que já havia efetuado testes com o provedor Betha e que o resultado foi positivo, porém aqui pra mim está dando o seguinte erro: "A string literal was expected, but no opening quote character was found". Fiz aqui uma depuração rápida, e parece que a exception é gerada na hora que ele tenta assinar o Lote na seguinte linha de código: "xmldoc.setProperty('SelectionNamespaces', SelectionNamespaces);" da unit ACBrDFeSSL.