Painel de líderes

Boa tarde, estamos enfrentando problemas referente ao envio de NFS-e através do provedor GINFES, gostaria de saber se tem alguma forma de configurar o tempo de resposta para evitar este problema.

A tag deve ser xJust e não xJus.

Bom dia.. PercentualReducao=33.33 O Nome do campo de reducao esta diferente do manual https://acbr.sourceforge.io/ACBrMonitor/ModeloNFeINICompleto.html é para ser o abaixo pRedBC= Sugiro , deixar os nomes padrao conforme o link do ModeloNfe, tem varios campos com nomes diferentes. Valeu.

boa tarde ainda nao foi liberado para gerar o campo CSRT no PR as informações obrigatorias serão : infRespTec.CNPJ := // CNPJ da Empresa infRespTec.xContato := // Nome do Contato infRespTec.email := // email do Contato ou Empresa infRespTec.fone := // fone do Contato ou Empresa

Boa tarde, O idCSRT e CSRT não tem data para ser exigido no XML (Implementação futura). O que vai ser exigido a partir do dia 03/06/2019 para as UF: AM, MS, PE, PR, SC e TO é o grupo <infRespTec> com as seguintes informações: CNPJ, xContato, fone e email.

Boa tarde Lucas, Não vejo vantagem nessa funcionalidade, visto que a NFC-e é destinada ao Consumidor Final e não para uma empresa que vai utilizar esses dados para dar entrada no estoque, no contas a pagar, ... A SEFAZ até o momento não disponibilizou um serviço para realizar o download do XML da NFC-e, apenas NF-e.

Boa tarde a todos, Existem outras postagens no fórum com problemas parecidos, tudo indica que o provedor Ginfes esta passando por algum problema de lentidão, mas é lógico que eles não vão admitir. O jeito é infernizar o provedor, com as reclamações, quem sabe assim eles dão um jeito. Sugiro também que entrem em contato com a prefeito para fazer reclamações e se possível for, fazer uma reclamação por escrito (contribuinte seria a pessoa mais indicada) e protocolar na prefeitura atendida por esse provedor.

Reinstalei o componente novamente, alterei a forma de configurar o componente, deixei como no DEMO, e funcionou corretamente. Obrigado.

Recompilei o ACBr assim {$DEFINE DFE_SEM_CAPICOM} e funcionou

Deu erro na validação do arquivo no momento do envio da remessa?

É necessário realizar o preenchimento dessas tags. Aqui no Paraná, se enviar sem terá uma rejeição (em ambiente de homologação) - Produção está aceitando com ou sem os campos por enquanto. Um detalhe importante, essas validações são a critério da UF. Por tanto é necessário verificar com a SEFAZ do estado se eles vão ou não aderir essas novas validações. Caso a UF em questão implementará, verifique a propriedade nova no ACBr ForcarGerarTagRejeicao938. Pois em algumas UF mesmo os valores sendo zerados e a tag sendo facultativa é necessário informar. Veja mais detalhes no tópico abaixo. (nesse mesmo tópico tem uma resposta da SEFAZ-MG explicando qual valor informar nessas tag's novas)

Funcionou em produção, em homologação não estou conseguindo testar, mas tudo bem. Valeu, obrigado

Pesquisando e lendo um pouco mais aqui... vi que o meu sat (RB200 Bematech) não suporta a versão 0.08...

Boa tarde, acredito que o Banco permita mais de uma ocorrência no mesmo arquivo.... Para fazer isso no componente Boleto, basta carregar os dados do mesmo Boleto quantas vezes desejar apenas alterando a ocorrência a cada inclusão.

Obrigado a todos pelo esclarecimento valeu vou fazer meus teste

Entendi, pensava que pelo método do empregador, poderia baixar qualquer evento transmitido pelo CNPJ da empresa informada. Utilizando o método do trabalhador, pediu o CPF, inicio e fim do período, que informei janeiro (01/01/2019 a 31/01/2019), e retornou "406 - Não foram encontrados registros conforme os filtros informados". Mas tudo bem, farei mais alguns testes mais tarde. Obrigado

Hélio, Já movi a sua postagem para dentro do SAC. Segundo não é xJus e sim xJust. Errado: Tpimp=4 xJus=NFE EM CONTINGENCIA POR FALTA DE COMUNICACAO COM SERVIDOR dhCont=27/05/2019 10:57:42 Correto: Tpimp=4 xJust=NFE EM CONTINGENCIA POR FALTA DE COMUNICACAO COM SERVIDOR dhCont=27/05/2019 10:57:42 Esta faltando a letra "t"

Oi ítalo. Obrigado pela atenção. Já consegui resolver. Estão no datamodule. Exclui todos os componentes e adicionei novamente. Ai deu certo. Valeu. Muito obrigado.

Edevair, Não vejo como uma gambiarra, mas sim como uma limitação no sistema do banco não receber em um mesmo arquivo mais de uma solicitação de alteração para um mesmo titulo.

Edevair, Desculpa não entendi: No meu entendimento se desses 18 boletos, 6 (por exemplo) estão com a data de vencimento e ou valor errado o banco não tem como saber. Se você enviar um arquivo com somente a ocorrência de alteração de data de vencimento de um ou vários boletos o que poderia dar errado? E depois enviar um outro alterando o valor.

Na verdade eu já testei e dá erro na remessa, o problema é que tem um cliente que faz parcelamento grande com seus produtos, tudo no boleto em 18X aí gera os boletos e envia pro cliente dele e remessa pro banco, se no caso precisar mudar o valor do boleto ou vencimentos, se for cancelar todos os boletos sai em média R$ 58,00 sendo que pra alteração o banco não cobra nada.. O problema não está sendo atualizar o boleto e imprimir, isso eu já faço, o problema realmente é informar o banco destas alterações... Pq a validação ocorre linha a linha, se mando uma remessa com toRemessaAlterarVencimento e tiver alterado as duas coisas, dá erro e o mesmo acontece com toRemessaAlterarValorTitulo Complicado de resolver sem gambiarra....

Edevair, Como disse antes não utilizo o componente, logo não sou a pessoa mais indicada para responder sobre ele. O que sei é que o boleto pode ser emitido pelo Cedente e entregue ao Sacado (pagador) e um arquivo deve ser gerado e enviado ao banco para que este faça o registro do mesmo. Ou o Cedente gera o arquivo envia para o banco fazer o registro e também imprimir o boleto e enviar para o Sacado. Acredito que neste caso essas ocorrências que você mencionou façam sentido, ou seja, um arquivo com essas ocorrências é enviado para o banco, este faz as devidas alterações e um novo boleto é impresso e enviado ao Sacado. Agora se é possível informar mais de um tipo de ocorrência para um mesmo titulo, isso eu não sei, mas não custa testar.

Bom dia Edevair, Não utilizo o componente ACBrBoleto, mas tanto o vencimento quanto o seu valor influencia no código de barras e linha digitavel. Sendo assim, acredito que neste caso será necessário solicitar o cancelamento do boleto enviado e o envio de um novo com a data e valor corretos.

Grandemente agradecido pela solução. Acabei de testar e funcionou corretamente (pelo menos o ConsultaStatus). Estou anexando as evidências do funcionamento (somente o "sucesso" - guardei o comparativo com a versão anterior mas não vou postar para não confundir). (...No meu caso, utilizo o ACBrMonitorPLUS.exe através do wine em um Ubuntu 14...) Peço que aguardem mais 1 ou 2 dias antes de fechar o tópico, pois vou colocar para rodar nos outros usuários que REALMENTE emitem NF-e para garantir que os webservices de processamento de NFe aceitarão a solução da mesma forma. Novamente, agradeço a atenção e solução!

Bom dia Leite, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Vitor, Aparentemente com o ajuste realizado pelo Daniel, solucionou o problema para este certificado no Windows e Linux... Favor realizar os testes com Versão em anexo, para o Windows basta substituir o executável na pasta do ACBrMonitor. ACBrMonitorPLUS-1.2.0.60-1.x86_64.rpm ACBrMonitor.zip

@Daniel Simoes @Vitor JR Eu tive um problema recente com um certificado de cliente com essa mesma cadeia, mas acessando pela SVRS. Usando OpenSSL ocorria o erro HTTP 403 em qualquer operação, com WinCrypt a consulta de status funcionava mas ao tentar emitir a NFCe retornava a rejeição "Certificado Transmissor erro no acesso a LCR". Após vários contatos com a certificadora que dizia que estava tudo certo com o certificado, a resposta veio da SEFAZ-RS: Isso foi no dia 08/04/2019. Depois de contatar novamente a certificadora com essa informação, eles admitiram o problema e foi solucionado no dia seguinte com a publicação da cadeia no ITI e atualização das mesmas pela SEFAZ-RS. Então creio que a SEFAZ-SP deve fazer o mesmo. Infelizmente o certificado que tinha do cliente foi revogado e emitido um novo com ICP-Brasil v2. Testei mesmo assim (usando o certificado revogado) a consulta de status: GO em homologação passou a funcionar. Em SP continua o erro 403 mas ele acontece com WinCrypt também.

Bom dia! No teu arquivo INI, você não informou o codigo CST, nem origem da mercadoria. Como não tem esta informação o ACBrMonitorPLUS está setando a padrão CST=00. Parte do conteúdo do teu arquivo: Falta o campo CST. Isto em primeiro momento. Corrija e depois se não der certo, continue informando neste tópico.

Obrigado pelo envio dos Certificados para teste... Eu realmente consegui reproduzir o problema, com OpenSSL, certificado em PFX, consultando o Status de Serviço em SP, em um Certificado onde todas as cadeias, são V5 (imagem abaixo) Creio que seja algo no lado do Servidor, que ainda não deve ter as novas cadeias de certificado instaladas... Este problema me remeteu a esse tópico, de problema muito similar: Usando a solução de converter o PFX para PEM, e posteriormente lê-lo usando o "FHTTP.Sock.SSL.CertCAFile", realmente funcionava... o que me fez concluir que a maneira como a Synapse estava lendo o arquivo PFX, não estava completa, pois não lia os certificados da Cadeia, no contexto... A solução foi simples, há um comando para inserir uma cadeia de certificados, no contexto... (porém somente descobri após muita pesquisa) if PKCS12parse(p12, FKeyPassword, pkey, cert, ca) > 0 then if SSLCTXusecertificate(Fctx, cert) > 0 then if SSLCTXusePrivateKey(Fctx, pkey) > 0 then Result := True; // Set Certificate Verification chain if Result and (ca <> nil) then SslCtxCtrl(Fctx, SSL_CTRL_CHAIN, 0, ca); // <---- AQUI Por favor teste, substituindo as Units e anexo, na sua pasta: ACBr\Fontes\Terceiros\synalist ssl_openssl_lib.pas ssl_openssl.pas

Obrigado Ítalo. Realmente o Provedor é o IPM. Vou alterar Provedor no Cidades INI e vou testar. Qualquer dificuldade posto aqui.

Entendi Jucemar, nesse caso não tem jeito, cada rubrica tem que identificar o beneficiário. Concordo com você que teria outras formas de prestar essas informações (algo parecido com o plano de saúde no S1200 talvez), pode ser que tenham bons motivos pra ter feito assim, ou na pressa pra entregar era o que tinha... kkkk. Como falei antes, aqui temos o beneficiário vinculado ao trabalhador e na hora de gerar o xml, ao identificar que é pensão, pegamos os dados do vínculo e montamos as tags. O e-Social tem evoluído bastante (veja quantas alterações no layout), pode ser que amanhã ou depois isso mude, mas isso é o que temos pra agora.

Aqui em MG já teve dia que só sincroniza a nfe com o portal nacional depois de 24 horas, e se consegue fazer ciência instantaneamente, é só vem o xml depois de 24 horas. outros dias o xml retorna em 2segundos depois de fazer o manifesto.

Boa tarde, Fiz um ajuste na impressão do Fortes, vi que o componente se referia a averbação, mais estava como "Número da apólice" e não estava carregando informação: Estou preenchendo os campos também: Se estiverem de acordo, segue os arquivos modificados: ACBrMDFeDAMDFeRLRetrato.dfm ACBrMDFeDAMDFeRLRetrato.pas

Isso mudou agora? uso assim a anos, o terceiro parâmetro informava o tipo de documento, de era CNPJ ou IE, não li quando mudou valeu mesmo. Obrigado. HASA

Amigos, deu certo... eu apenas atualizei os SCHEMAS na pasta do programa e ja deu certo.

Opa! Então, para cada rubrica com incidência de IRRF 51, 52, 53, 54 ou 55 o grupo <penAlim> deve ser informado, nas demais o grupo deve ser omitido. Geralmente temos somente uma rubrica de pensão para cada demonstrativo do empregado. Se você tiver mais de uma talvez seja interessante junta-las. Assumindo que você é o desenvolvedor do programa e de todo modo precisa ter várias rubricas de pensão, o beneficiário deve ser informado para cada uma rubrica no xml, mas no seu programa você pode realizar esse vinculo somente uma vez e quando for gerar o evento busca esse vinculo e repete para cada uma. Como são dados cadastrais não vejo como poderia interferir em algum totalizador. É interessante que os valores do campo <vlrPensao> corresponda aos valores das rubricas, no meu caso o valor da rubrica e o valor da pensão foi sempre o mesmo. As rubricas de pensão alimentícia devem ser informadas porque interferem na formação da base de calculo do IRRF, então se você esta se referindo a totalizações que o sistema do e-Social faz, acho que o valor das rubricas que são importantes. Acredito que esses dados estão sendo solicitados mais para fazerem algum tipo de cruzamento de informação com a declaração do IR ou algo do tipo, para efeito de cálculo e fechamento da folha, o que vale é o valor da rubrica.

Bom dia Bruno, Fiz uma alteração no arquivo INI do provedor e ainda hoje estarei envia para o repositório. Quem sabe com essa alteração resolve o problema.

Bom dia Elaine, Note que no arquivo 55-env-lot-soap.xml a tag hashIdentificador esta vazia. O seu conteúdo é retornado ao solicitar a abertura de uma sessão. Se não esta retornando isso significa que o Identificação do Prestador e ou Senha informados na solicitação de abertura estão incorretos.

http://michellcomputing.co.uk/blog/2016/05/windres-installation-on-linux/ isso funcionou

Sim, pensei nisso... alias essa foi a decisão mais difícil... Há prós e contras... fazer um evento desse porte em SP é no mínimo 4x mais caro... (porém é bem mais rápido de vender) No fim, os fatores decisivos, para escolher o Interior, foram: O (terrível) transito de SP, e as espaçosas acomodações do Parque Tecnológico de Sorocaba

O Refactoring já está no ar. Vejam o seguinte tópico: