JeannyPaiva

Bom dia. Tive um problema semelhante ao atualizar o componente (de apresentar o retorno vazio), porém vi que o problema estava no momento de interpretar o retorno. Em testes com os provedores SH3 e VersaTecnologia, ao debugar apenas identifiquei que apresentava "Range Check Error", na unit ACBrXmlBase, TipoEncoding. Realizei a alteração na função e resolvi aqui o problema. Pode ser o mesmo caso com o XML retornado pelo Betha ACBrXmlBase.pas

As URLs de contingência SVC quando enviadas de MG está sendo validada fora do padrão dos demais estados. Para contornar, aqui eu utilizo arquivo ACBrCTeServicos.ini diferente para MG dos demais estados. Para homologação [CTe_SVC-SP_H] URL-QRCode=https://hcte.fazenda.mg.gov.br/portalcte/sistema/qrcode.xhtml

Obrigada.

Boa tarde. Realizei alguns ajustes para o provedor SH3, utilizado por São Geraldo. ACBrNFSeXServicos.ini : correção das urls de homologação e link para impressão.ACBrNFSeXServicos.ini SH3.Provider.pas: correção para leitura do XML que não possui a tag 'return'. Em anexo também um exemplo de XML de retorno deles. SH3.Provider.pas 101-lista-nfse-ger-soap.xml

Exemplos de erros que ocorriam sem os ajustes. RetCancelamentoNFSe.txt RetNFSeAliq.txt

Em VersaTecnologia.GravarXml, é referente a formatação da aliquota, que estava causando rejeição nos calculos. Alteração realizada: DivAliq100 := True; Em VersaTecnologia.Provider.pas no XML acusou falha no envio pelo envio do NameSpace novamente na tag InfPedidoCancelamento. Foi sobrescrito GerarMsgDadosCancelaNFSe para ajustar a tag '<' + Prefixo2 + 'InfPedidoCancelamento' + IdAttr + '>' .

Boa tarde, Estou realizando a troca do componente NFSe para NFSeX e precisei realizar dois ajustes para o provedor VersaTecnologia. Segue fontes alterados. VersaTecnologia.Provider.pas VersaTecnologia.GravarXml.pas

Boa tarde. Em uma determinada situação, ao Ler um arquivo XML e Assinar, algumas tags estavam ficando duplicadas ao assinar (onde ele carrega novamente as informações do componente e gera de novo o arquivo). Realizei um ajuste na leitura de CTe. Segue anexo arquivo com alteração. pcteCTeR.pas

Boa tarde . A URL correta é realmente a apontada https://dfe-portal.svrs.rs.gov.br/CTe/Servicos (URL-QRCode=https://cte.fazenda.mg.gov.br/portalcte/sistema/qrcode.xhtml) tanto para produção quanto homologação em MG , porém por algum motivo, ao enviar para SVC-SP, em homologação, eles validam que deve ser enviado URL-QRCode=https://hcte.fazenda.mg.gov.br/portalcte/sistema/qrcode.xhtml, e não o endereço aceito pela SEF MG. Por ser algo ocasional, e dificilmente no cliente é emitido em homologação SVC-SP, o que faço é trocar a URL no arquivo ini para homologação apenas para testes aqui na empresa, mas distribuir o arquivo de acordo com o especificado no endereço acima.

Aqui também temos este problema. Devido a isso não conseguimos realizar testes na rotina.

Acredito que este projeto do DTe vai cair por terra. https://comsefaz.org.br/?p=1948

Neste caso o município de descarregamento informado para o documento deve ser São Paulo, e lá o transportador que irá levar a mercadoria até o destino final irá emitir outro MDFe de SP para PA.

A quem se interesse: Enviei mensagem para a SEF MG questionando o erro de falha de schema ao enviar as novas tags em Homologação. Segue resposta:

Sim... já tentei de todas as formas possíveis... enviando URL de SP, de MG, todas são rejeitadas. MG é muito ruim para nos responder, e quando respondem costumam ser respostas evasivas e nada é solucionado.

Tenho mesmo problema por aqui ao enviar CTe em contingência para SVC-SP. De acordo com a informação do portal o endereço está correto, porém a rejeição continua. Já tentei entrar em contato com a SEF e simplesmente dizem que estão encaminhando para outro setor para analisar, nunca respondem e nem é resolvido. Faz meses que temos essa rejeição e sem solução.

Bom dia. Na leitura do XML para o provedor SH3 não está sendo efetuada a leitura do campo ValorIss ou ValorIssRetido quando IssRetido = stRetencao. Adicionei o provedor na condição para atribuição do campo. pnfsNFSeR.pas

Warlei, conseguiu alguma solução? Para mim responderam a mesma coisa, e mesmo entrando em contato depois reclamando que isso não resolvia, só tive um grande vácuo como resposta.

Enviando novamente XML2.zip

Segue XML.zip

Evento-110181-311908866820930001055704000000005812630029701101811-evento.xmlCTe-110181-31190886682093000105570400000000581263002970.xmlEvento-110111-311909866820930001055704000000007413630029791101111-evento.xmlCTe-110111-31190986682093000105570400000000741363002979.xmlEvento-110110-311908866820930001055704000000007312439011771101101-evento.xmlCTe-110110-31190886682093000105570400000000731243901177.xmlEvento-110180-311908866820930001055704000000005812630029701101801-evento.xmlCTe-110180-31190886682093000105570400000000581263002970.xml XMLs para exemplo (CTe + Evento). Não consegui gerar apenas o de Não Prestação, por rejeição quanto ao autor do evento.

Boa tarde. Realizei alterações para possibilitar a impressão dos Eventos de Comprovante de Entrega, e Cancelamento de Comprovante. Seguem os fontes para verificação. DACTE_EVENTOS.fr3 ACBrCTeDACTEFR.pas

Bom dia. Como empresa desenvolvedora temos apenas o CNPJ da própria habilitada para homologação (e a política da empresa não permite uso de dados do cliente para testes). Portanto a mesma empresa que emite CTe na homologação, emite a NFe também. Recebi novo retorno da SEF hoje informando que fizeram mais correções ontem no ambiente de homologação, e consegui emitir alguns hoje, e outros ainda com algumas rejeições ainda não façam muito sentido. O problema era lá mesmo (MG tem um histórico de dar dor de cabeça pra gente a cada nova implementação de recurso)

Tive esse retorno também a principio, e passando a informar algumas horas antes do horário do evento, voltou a apresentar a rejeição 999.

Obteve algum retorno diferente da SEF? Entrei em contato com a SEF-MG também para averiguar o erro. Me retornaram hoje informando que haviam corrigido no ambiente de homologação, porém o problema persiste. **Alguns clientes entraram em contato informando que a data inicial de obrigatoriedade seria 01/09/2019 de acordo com o Ajuste SINIEF n. 012/2019, porém se não conseguimos nem ao menos testar, será impossível liberar esta alteração (que já está com prazo apertado).

Reenviando o FR3. No primeiro arquivo estava faltando o código de barras dos Dados CTe (para contingencia FS-DA) DACTE_Retrato.fr3