Painel de líderes

Bom dia Roger, Muito obrigado pela colaboração, vou analisar e estando tudo OK vou enviar para o repositório.

Boa tarde. Ocorreu mudança na URL para integração da NFSe na cidade de Ijuí-RS. Conforme notícia divulgada no site do município: https://www.ijui.rs.gov.br/paginapref/manual_de_orientacao_dos_procedimentos_administrativos/nota_fiscal_de_servico_eletronica Segue em anexo arquivo Pronim.ini com a alteração. Já foi testado em um cliente e funcionou corretamente. Pronim.ini

show é isso ai. como diz o Daniel use a força, leia o código . os fontes estão todos ai pra ser explorado

Alteração já se encontra no SVN.

chegou a olhar os exemplos?

Pessoal eu fiz um procedimento segundo o @marcioereno e deu certo : Ao tentar enviar caso não retorne a chave de acesso da tentativa no campo da chcte do CTE, verificar no XML a chave da tentativa retornada e após inserir no campo (no meu caso fiz via banco de dados) da xchcte de acesso da numeração que esta sendo enviada e consultar esta chave. Caso o CT-e esteja correto vai buscar os dados do envio.

@RicardoVoigt consegui resolver o problema: Tenho que carregar o xml após o envio. Codigo anterior: ACBrNFe1.EnviarEvento(StrToInt(idLote)); ACBrNFe1.ImprimirEvento; Código novo: ACBrNFe1.EnviarEvento(StrToInt(idLote)); ACBrNFe1.EventoNFe.Evento.Clear; ACBrNFe1.EventoNFe.LerXML(ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.NomeArquivo) ; ACBrNFe1.ImprimirEvento;

A chave de acesso é gerada baseada nos valores informados para os campos que a compõe. - UF do emitente - Mês e ano da emissão - CNPJ do emitente - Modelo - Série - Número - Tipo de emissão (tpEmis) - Código numérico (cNF) - Dígito verificador. Então, exceto para o dígito que é calculado, basta informar o valor de cada um desses campos individualmente que você terá a mesma chave de acesso.

https://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrDFe/ACBrNFe/ACBrNFeServicos.ini

Boa tarde a todos, Existe um problema na emissão da carta de correção da nota fiscal eletrônica quando são carregadas para a lista do componente ACBrNFe mais de uma nota, a carta de correção sempre sai com os dados da primeira nota. Detectei que o problema estava na procedure PrepareReportEvento, na linha 2122, que sempre estava carregando o item zero: NFe := TACBrNFe(DANFEClassOwner.ACBrNFe).NotasFiscais.Items[0].NFe; Fiz a correção na revisão17570 , e anexei a unit caso seja útil para mais alguém, aqui para mim resolveu o problema. Abraço! ACBrNFeDANFEFRDM.pas

- Você informa os dados do emitente, a cidade com código do IBGE da mesma. - O componente procura no arquivo Cidades.ini essa cidade e verifica qual provedor está associado a mesma.

Se a SEFAZ não permite contribuinte isento e o mesmo não tem IE você deve informar como não contribuinte.

Boa tarde Danilo, Não detenho conhecimento amplo no que diz respeito a assinatura digital, mas deve ser alguma incompatibilidade com o certificado.

Para NFCe o MA usa a SVRS: https://sistemas1.sefaz.ma.gov.br/portalsefaz/jsp/pagina/pagina.jsf?codigo=3876

estou usando essa function ACBrNFe.DistribuicaoDFePorUltNSU(Empresa.UF),Empresa.CNPJ, ultNSU); Acho que matou a charada , tem no cnpj da matriz como transporte. Acredito que seja esse o problema.

boa tarde eu tentei aqui pela chave e realmente foi , obrigado

Eu pensava que na NFC-e, na tag cAut, iria esse campo e usava assim no sistema Irei pegar então o campo NSU!

Os caras se superam... SEFAZ-PR é um show de incapacidade.

Devia ter funcionado com a alteração no .ini. Vai ser preciso debugar.

chegou a olhar que propriedades mais tem ali no envevento e também e retevento?

Estou com o mesmo problema e a solução temporária encontrada foi fazer a "Recuperação do XML" e a atualização do mesmo na base de dados. Neste caso retorna com a autorização e ai podemos dar continuidade ao processo.

No caso não é você que precisa se preocupar mas sim o usuário do sistema. a única coisa que tu pode fazer é baseado no xls que tem no site limitar mas quem deve de informar e saber é o cliente e ele deve de conversar com o contador dele

Concordo contigo, agora, o problema em questão é a situação de não obter o retorno durante a transmissão devido a essa instabilidade da Sefaz, o CTe foi transmitido só não obtém o retorno, mas referente aos erros de preenchimento, imagino que você pode tentar validar o xml no site da própria Sefaz para ver se está com algum preenchimento indevido.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Pessoal, estou com o mesmo problema mas os CTe esta sendo transmitidos normal o problema e a consulta se voce consultar a chave do cte ele te da o retorno normal, eu apenas peguei o retorno de erro se for 223 eu consulto novamente que da certo ate a receita voltar ao normal...

Problema Resolvido. Obrigado pela colaboração. Eu estava buscando em um (.ini) errado.

https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx Faltou acrescentar os dados das adições.

Qual fr3? testou com outros da pasta?

Boa tarde, a melhor solução é utilizar o MFe pois não depende mais do aplicativo Integrador Fiscal do CE: Mas se for utilizar NFCe precisa do Integrador veja esse tópico: No Componente precisa vincular o componente na propriedade "Integrador"

Não sei se você se atentou a descrição do campo, mas me parece que só existe código autorização quando é crédito mesmo. Veja Campo "135 - Contém o Código de Autorização para as transações de crédito (15 posições no máximo)". Já o campo 133, por sua própria descrição "Contém o NSU do SiTef (6 posições)" não é código de autorização. Me parece ser outro campo que não é atualmente tratado pelo ACBrTEFD. Existe algum outro motivo que você pense que a alteração seja necessária?

Boa tarde @Italo Jurisato Junior Seguem arquivos para análise. Nossa alterações: - A alteração no arquivo ACBrDFeHttpWinApi.pas não tem a ver diretamente com a implementação do novo provedor. Simplesmente facilitou no processo de desenvolvimento/debug. - Criamos um novo provedor que chamamos proDSFSJC (já que esta implementação da DSF é exclusiva pra São José dos Campos). Para tanto alteramos o arquivo Cidades.ini para que o arquivo de inicialização de SJC passe a ser o DSFSJC.ini. - Criamos o arquivo DSFSJC.ini baseado no arquivo GINFES.ini e nele alteramos os namespaces, as urls de acesso e as configurações necessárias. A mais curiosa é a inclusão de uma seção CDATA na montagem dos xmls de envio. Esta seção é necessária e foi incluída por indicação do próprio pessoal da DSF (sem ela o arquivo não é entendido pelo webservice deles). Eu não sei exatamente o que ela faz, talvez alguém com mais experiência nisso possa esclarecer este ponto. - Aí então fizemos as alterações necessárias nos próprios fontes do ACBr (criamos o enumerado proDSFSJC, e os devidos tratamentos de envios e respostas). Algumas considerações/explicações: - Nós utilizamos os seguintes métodos (somente estes foram testados e validados) : * RecepcionarLoteRpsV3 * ConsultarSituacaoLoteRpsV3 * ConsultarLoteRpsV3 * ConsultarNfsePorRpsV3 * CancelarNfseEnvio - A implementação da DSF foi bem curiosa. Pelo que entendi a ideia era causar o mínimo impacto nas aplicações dos contribuintes e para isso eles mantiveram a estrutura de xmls do GINFES. Mas a lógica de implementação e o conteúdo dos arquivos de resultados (e às vezes mesmo a estrutura deles) não são os mesmos. Exemplos: * O retorno do método ConsultarLoteRpsV3 não traz a identificação de cada um dos rps no lote. Ou seja, não é possível saber a situação de cada um deles após o envio do lote neste método. * Para saber da situação de uma determinada nota, deve-se chamar o método ConsultarSituacaoLoteRpsV3 para garantir que o lote foi processado e em seguida chamar ConsultarNfsePorRpsV3 para saber da situação da nota em si. * Apesar da estrutura do xml de envio do método CancelarNfseEnvio ser igual à do Ginfes, o arquivo de retorno é totalmente diferente e exigiu uma implementação nova de tratamento de retorno nos fontes do ACBr. Além dos arquivos fonte alterados e dos novos arquivos .ini estou anexando os arquivos .xds que nos foram repassados pela DSF. Fico à disposição para quaisquer dúvidas. ACBrDFeHttpWinApi.pas ACBrNFSeDANFSeFR.pas ACBrNFSeWebServices.pas Cidades.ini DSFSJC.ini nfse.xsd pnfsCancNfseResposta.pas pnfsConversao.pas pnfsNFSeG.pas pnfsNFSeW_ABRASFv1.pas xmldsig-core-schema20020212.xsd

Então pode ser que a propriedade KeyPreview do Form esteja False. Mude para True. Esse artigo abaixo em inglês é muito explicativo sobre o assunto: https://www.thoughtco.com/understanding-keyboard-events-in-delphi-1058213

Boa tarde Adilson, No arquivo INI do provedor Fiorilli consta que a versão é 2.01 do layout da ABRASF, favor verificar junto ao provedor, qual é a versão para essa cidade. Existem as versões: 2.02 e 2.03

Boa tarde Pedro, Muito obrigado pela colaboração, já enviei para o repositório.

Acabei de ler outro topico https://www.projetoacbr.com.br/forum/applications/core/interface/file/attachment.php?id=63933 Vou atualizar com esse arquivo pra testar e posto se deu certo ou nao . Obrigado .

Deu Certo, coloquei pra -04:00 Obrigado @BigWings!

blz, muito obrigado deu certo.

Enviei correção para o repositório, rev. 17549. Favor atualizar os fontes e testar novamente.

Não entendi, ou você atualiza os fontes do ACBr ou não... Se estiver com os fontes antigos o grupo pode não ser gerado quando pICMSInterPart = 0, isso foi alterado quando a tag foi removida. Então atualize os fontes do ACBr e tente novamente.

Perfeito pessoal, ACBRMonitor funcionando corretamente após compilação em modo release. Obrigado mais uma vez!

José esta resolvido , o problema era o arquivo pfx do cliente . De forma obrigado pela ajuda .

Correto, quando um titulo "normal" é descontado, vem pro cobrança um instrução tipo "baixa por desconto". E no empréstimo este mesmo titulo em uma instrução de entrada e depois segue seu ciclo pelo "empréstimo" Entendi, gostei da forma de desenvolvimento que você sugeriu. Eu posso desenvolver isto aqui com base no Itaú, o qual tenho o manual, e possuo meios de testar principalmente os retornos deste tipo de serviço [emprestimo] novo.

Veja:

Enviei correção para o repositório, rev. 17533. A forma que encontrei foi usando a var. TotalPages e ativando o DoublePass, assim como é feito no DANFE. Favor atualize os fontes e teste com o fr3 do repositório.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Para NFCe o PA já usa a SVRS, então será alterada apenas NFe.

Bom dia, tive esse problema no demo da NF-e, só consegui compilar deletando o .res No meu caso, como queria apenas validar alguns dados pelo demo, resolveu!

Bom dia Duarte, Favor entrar em contato com o provedor pois, segundo o Schema temos: <xsd:simpleType name="tsRegimeEspecialTributacao"> <xsd:restriction base="xsd:byte"> <xsd:pattern value="1|2|3|4|5|6"/> <xsd:whiteSpace value="collapse"/> </xsd:restriction> </xsd:simpleType> E o XML gerado (caso 3) temos: <ns4:RegimeEspecialTributacao>6</ns4:RegimeEspecialTributacao> Logo o XML do RPS esta de acordo com o Schema e o mesmo foi rejeitado com a justificativa que o código de tributação não existe? A não ser que a rejeição esteja se referindo ao código de tributação do município e não ao código de Regime Especial de Tributação. <ns4:CodigoTributacaoMunicipio>3143906</ns4:CodigoTributacaoMunicipio> Pode ser que o código 3143906 esteja errado.