JeannyPaiva
-
Total de ítens
236 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por JeannyPaiva
-
-
Boa tarde,
Me deparei com um problema na leitura do XML na tag <qtdRat> do grupo infUnidTransp.
Fiz a correção desta tag e mais alguns detalhes na leitura de XML que precisei tratar.
Segue arquivo anexo
-
Responderam aos clientes que a contingência SVC-SP está ativada (mesmo não estando com o aviso no portal do CTe).
Estão emitindo atualmente nesta contingência.
-
2
-
-
Começamos a ter este problema por aqui também em várias empresas.
Orientamos os clientes a entrar em contato com a SEFAZ e fazer pressão pra habilitarem a contingência até que estabilizem (ou seja por tempo indeterminado).
-
1
-
-
Creio que seja o caso de reportar à SEF de MG, porém estes dias eles estão apenas respondendo de forma automática.
-
13 horas atrás, Márcio B. disse:
Sugiro que vocês atualizem o ACBR conforme a recomendação do Sr. Italo.
Segue em anexo a imagem do XML gerado por um sistema "não ACBr" que motivou as alterações bem como a imagem do schema onde indica a utilização do & no lugar do CDATA.
Está atualizado aqui sim @Márcio B. , possivelmente você não teve o mesmo problema que nós por não utilizar o mesmo recurso de ler o XML já gerado para depois enviar.
A questão eh que o tratamento de leitura da tag x geração esta incompatível. Ao ler o XML já gerado o & é convertido para &.
Porém ao gerar novamente o parâmetro ParseTextXML estava false.
Para seguir o mesmo padrão de demais tags string fiz as seguintes alterações:
Em ACBrCTe > GetURLQRCode, preencher a tag com & novamente em vez de & (como já estava antes)Em pcteCTeW passar o parâmetro de ParseTextXML para True, que assim irá realizar a conversão correta dos caracteres.
Esta alteração segue os mesmos padrões do comportamento de outros campos string como Nome, Endereço, etc.
@Juliano Otaviano Barreto, teste novamente com essa alteração sem zerar o qrCodCTe.
-
1
-
1
-
-
Tive aqui o mesmo erro do @Juliano Otaviano Barreto.
Para contornar temporariamente, após ler o XML eu apaguei a tag qrCodCTe para que assim ela fosse gerada novamente.
Não fiz alterações definitivas ainda, mas pelo pouco que vi ao ler o XML já gerado com o qrCodCTe preenchido ele troca & para & causando o problema na assinatura do XML.
-
1
-
-
1 minuto atrás, Túlio de Pádua disse:
Que coisa, estou aguardando uma resposta deles, certamente mandarão essa mesma. Eu já tinha alterado localmente também para atender aos testes aqui, vou ver o seu se também como está. Uma pergunta, está conseguindo fazer o envio do CTe-OS?
Não temos CTe-OS aqui, apenas CTe em modal rodoviário, então não sei dizer.
Mas se está com algum erro é possível que a resolução seja semelhante. -
SEF MG finalmente respondeu dizendo que eles estão certos e os demais que estão errados.
CitarRef. a mensagem: 1.416.624 - DOCUMENTOS ELETRÔNICOS > CT-e > CONTINGÊNCIA / TRANSMISSÃO / VALIDAÇÃO
Bom dia, Jeanny!
Segue retorno da nossa equipe de TI, sobre o problema apresentado:
Com relação ao informado em:
"Depois de muito comparar o wsdl de MG com demais estados e tentar entender o motivo de apenas MG não aceitar os XML enviados, encontramos o motivo do problema.
No soapAction de TODOS os demais estados, e de acordo com o MOC 4.0 está com "CTeRecepcaoSincV4". Apenas de MG está divergindo aceitando apenas "CTeRecepcaoSinc"." No MOC_CTe_VisaoGeral_v4.00, página 21, primeiro parágrafo, temos a informação de como deve ser apresentada a informação:
"<soap12:Body>
<cteDadosMsg xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSinc">string</cteDadosMsg>
</soap12:Body>"
Sendo assim, estamos seguindo conforme a documentação, e seguimos esse mesmo padrão para os demais serviços.
Com relação a rejeição 628, já realizamos os ajustes e já se encontra em homologação para validação.
No manual realmente consta dessa forma
Ou seja, não irão alterar.
Alterei novamente a o fonte que havia enviado anteriormente apenas como teste para atender ao envio para MG e também para contingência (a versão anterior tinha atrapalhado o envio para SVC-SP).
* A rejeição do envio de eventos já foi realmente corrigida.
-
2
-
-
Bom dia.
A tag xJustMotivo no evento de Insucesso de Entrega é opcional (utilizada apenas para tpMotivo = 4).
Porém no fonte ela está como ocorrência obrigatória
Segue anexo correção para gerar a tag apenas quando preenchida.
-
1
-
-
27 minutos atrás, Kakako Tecnologia disse:
Boa tarde pessoal!
Não acredito ser uma "alteração sugerida". Na verdade a Sefaz de MG que esta trabalhando fora do padrão. Quando resolverem corrigir o lado deles, essa alteração que realizou irá parar de funcionar. O ideal é "buzinar" neles mesmo porque ali é dificil hein. Provavelmente (em minha opinião) a pior Sefaz do Brasil em questões de TI.Por isso mesmo não coloquei como alteração sugerida, apenas informei o que foi preciso fazer para funcionar para adiantar outros aspectos da homologação. Caso outros tenham necessidade em emitir para MG para adiantar o nosso lado do desenvolvimento e realizar outras validações.
Continuo enviando os relatos para a SEF/MG, e pedindo que demais façam o mesmo.
-
Exatamente a mesma resposta aqui @TiicTechnology Sac. Estão usando como resposta automática. rs
Da última agora mandei a reclamação quanto a rejeição do evento pra ver se algo muda, mas ainda não responderam
-
1
-
-
Com as alterações do arquivo anexado consegui emitir CTe para MG.
Envio de eventos respondeu, porém está retornando rejeição (628 - Rejeicao: Erro Atributo ID do evento nao corresponde a concatenacao dos campos (ID + tpEvento + chCTe + nSeqEvento)). Acredito que estejam validando incorretamente de acordo com a regra dos eventos da versão 3.0 com a sequencia de apenas 2 dígitos.
O último retorno da SEF/MG foi um não retorno.
-
3
-
-
Obrigada @Scott pela informação.
Fiz um teste realizando a alteração sugerida e consegui autorizar um CTe pelo menos em MG.
Vou verificar e testar nos demais serviços, e tentar novamente contato pelo Fale Conosco sugerindo a padronização, e/ou ajuste nos fontes aqui do ACBr enquanto eles continuam nos causando problemas.
-
Nada ainda em MG, o mesmo erro continua, e até o momento sem respostas do Fale Conosco.
Sugiro que demais devs/empresas de MG também entrem em contato e caso tenham alguma resposta satisfatória, compartilhar com os demais aqui.
-
1
-
-
Boa tarde.
Tivemos recentemente rejeição no envio de GNRE para receita 100110 (A receita '10011-0' exige contribuintes inscritos! Favor informar a Inscricao Estadual do Emitente.)
Ao realizar os ajustes para envio da IE da UF favorecida nos deparamos com a seguinte orientação quanto ao preenchimento da GNRE para envio de Inscrição estadual:
Contribuinte Emitente - Se o contribuinte tiver inscrição da UF Favorecida, preencher apenas o campo 'Inscrição Estadual', caso contrário, preencher os demais campos que correspondem ao Contribuinte Emitente. Dados relacionados ao contribuinte emitente:
- Inscrição Estadual - Corresponde a inscrição estadual na UF favorecida.
ou
- CNPJ/CPF - Corresponde à Identificação do Contribuinte/Empresa responsável pelo fornecimento de mercadorias/produtos. Informar CNPJ quando se tratar de pagamento efetuado por pessoa jurídica, ou CPF quando se tratar de pagamento efetuado por pessoa física.
- Razão Social - Corresponde ao nome da Razão Social do contribuinte.
- Endereço - Corresponde ao endereço completo empresa do contribuinte (logradouro, número, bairro e complemento do endereço do contribuinte).
- UF - Corresponde a UF da empresa do contribuinte.
- Município - Corresponde ao município empresa do contribuinte. Selecione primeiro a UF do contribuinte emitente para habilitar este campo.
- CEP - Corresponde ao CEP da empresa do contribuinte.
- Telefone - Corresponde ao código DDD (2 dígitos) e número do telefone do contribuinte (8 dígitos).https://www.gnre.pe.gov.br:444/gnre/portal/ajuda.jsp
Porém o preenchimento da IE estava condicionada ao preenchimento do campo de identificação do emitente (CNPJ). Foi necessário ajuste para permitir envio apenas da IE sem demais informações.
Segue arquivo anexado.
-
1
-
-
Boa tarde @Italo Giurizzato Junior,
Parece que entramos no clássico problema de conserta para um e atrapalha para outro.
O mesmo provedor (SH3) que é utilizado para São João Del Rey, é utilizado em São Geraldo e Visconde do Rio Branco, porém está retornando de forma diferente.
De acordo com os arquivos acima anexados.
SJDR = > nfseDadosMsg
SG e VRB = > outputXML
Logo, quando foi realizada a ultima correção, SG e VRB parou de funcionar.
Para tentar sanar o problema realizei as seguintes alterações nos arquivos que seguem para avaliação:
1 - No arquivo ACBrNFSeXServicos.ini adicionei um parâmetro para identificar qual a tag de resposta ==> Params=ResponseTag:outputXML
2 - Em SH3.Provider ler buscar a informação do parâmetro "ResponseTag" para realizar a leitura do XML.
@alfadesign, se possível testes para SJDR com estes fontes para ver se soluciona o problema para todos.
* No arquivo ACBrNFSeXServicos.ini inclui apenas para as cidades citadas acima, seria necessário outros que utilizam este mesmo provedor identificar como ocorre o retorno em suas cidades.
**Optei por responder no mesmo tópico em vez de abrir novo pois aparentemente foi aqui que gerou a ultima alteração.
Exemplo-SG-188-lista-nfse-ger-soap.xml SH3.Provider.pas ACBrNFSeXServicos.ini
-
Boa tarde.
Foi realizado um ajuste para possibilitar ler XML de retorno da consulta por Faixa do provedor SH3.
Segue fonte e XML de exemplo
202300000000008202300000000010000001-lista-nfse-fai-soap.xml SH3.Provider.pas
-
Boa tarde.
Passou a ocorrer, após esta alteração, falha ao ler o XML de retorno em ConsultarNFSeporRps.
Mesmo sendo o mesmo provedor SH3 parece que tem variado o retorno. No exemplo acima ele retorna com a tag nfseDadosMsg. Porém aqui, para a cidade de São Geraldo retorna a tag outputXML.Realizei a correção nos meus fontes para resolver, mas creio que possa ter empasses semelhantes em outras cidades. Como poderíamos tratar essa divergência ?
*Segue arquivo de exemplo e alteração.
-
Bom dia.
Foi necessário a realização de um ajuste para o provedor EL no tratamento da tag IssRetido. Segue em anexo.
-
Boa tarde.
Precisar realizar algumas alterações para o provedor EL, utilizado por Linhares, e um ajuste para o envio de RPS (geral).
EL:
- Formatação de Alíquota
- Identificação do XML carregado (NFSe ou RPS)
- Ajuste de informações de retorno de erros
- Ajuste na leitura de XML de retorno de consultas e cancelamento.
RPS:
- Ao ler XML de RPS estava carregando a informação de data para a propriedade DataEmissaoRps, porém ao Gerar novamente o XML estava passando a propriedade DataEmissao, que no caso chegava com Zero.
ACBrNFSeXGravarXml_ABRASFv2.pas EL.LerXml.pas EL.Provider.pas EL.GravarXml.pas
-
Boa tarde.
Obrigada.
-
Boa tarde.
Foi necessário ajustar o retorno de XML do Provedor SH3 após as últimas atualizações.
Segue unit alterada.
-
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
-
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
Leitura da Tag indDeduzDeson na NFe
em ACBrNFe
Postado
Bom dia.
Realizei um ajuste quanto a leitura da tag indDeduzDeson.
Como o valor padrão ao passar pela função StrToTIndicador é tiSim, quando não há informação da Tag no XML estava atribuindo este valor em vez de tiNao.
pcnNFeR.pas