Italo Giurizzato Junior

Alison, Notei nesse XML que a URL referente ao QR-Code foi gerada segundo a versão 1.00 e não na versão 2.00 Você disse que definiu a versão diretamente no componente, mas esta gerando na versão 1.00 Todos os fontes de todas as pastas estão atualizados? Após baixar a atualização, você reinstalou os componentes através do ACBrInstall_Trunk2? Será que a sua aplicação não esta pegando um DCU antigo de alguma unit do componente?

Bom dia Adryelle, A principio o que deveria ocorre ao realizar a consulta. A SEFAZ retornar o grupo infProt com os dados referente a autorização da nota e em seguida a lista de eventos vinculados a mesma, que neste caso seria o evento de cancelamento. É bem provável que a SEFAZ em vez de retornar os dados referente a autorização, esta retornado os dados referente ao cancelamento dentro do grupo infProt mais o evento de cancelamento. Isso explica o fato de ao consultar o grupo infProd não ser adicionado ao XML quando a propriedade AtualizarXMLCancelado esta com o valor False.

Bom dia Alison, Favor anexar o XML da nota que esta sendo rejeitada, para podermos analisar.

Bom dia Luís, Essa alteração para 4 dígitos tem haver com a nova versão? Se sim, então é preciso incluir um IF para podermos manter compatibilidade com as versões anteriores. Outra coisa, nessa linha temos " 2, 2, 1, " o primeiro dois indica o tamanho mínimo da informação, o segundo dois o tamanho máximo e o UM indica que a informação é obrigatória. Ao mudar o segundo parâmetro da função Poem_Zeros para 4 que diz que a informação deve ser completada com zeros a esquerda até ter um tamanho de 4 dígitos, então devemos mudar no inicio de linha para: " 4, 4, 1, ". Você não concorda?

Boa tarde Kleiser, É o componente que esta gerando o XML do evento, correto? Se sim, após gerar, assinar e validar mão ocorre nenhum erro de validação? Você chegou a comparar o XML gerado com o layout do evento em questão disponibilizado no manual, para ver se não esta faltando nenhuma tag que pudesse estar provocando a rejeição?

Boa tarde Paulo, Vou pensar em uma solução para todos os modais.

BigWings, Tens razão, o provedor Agili não segue a ABRASF.

Bom dia BigWings, Não seria o contrario? Antes usava o Agili e agora Agiliv2. Pois até onde sei a implementação do provedor Agili, gera o XML do RPS segundo a versão 1 do layout da ABRASF. Por outro lado a implementação do provedor Agiliv2, gera o XML do RPS segundo a versão 2 do layout da ABRASF. Todos os provedores que tem em seu nome "v2" indica que seguem a versão 2 do layout do ABRASF. O acréscimo do "v2" ao nome do provedor se deu pois vários provedores que seguiam a versão 1, implementaram um novo Webservice segundo a versão 2. As cidades atendidas por esses provedores, algumas ainda se utilizam do Webservices da versão 1 e outras da versão 2. Por exemplo a cidade: Ariquemes/RO se utiliza do provedor Agili, já Peixoto de Azevedo/MT se utiliza do Agiliv2.

Bom dia Kleiser, O evento esta sendo gerado segundo a versão 2.4.2? Você esta usando o programa exemplo para realizar os testes?

Bom dia Paulo, Esse XML tem 2 coisas erradas. Primeiro não existe NameSpace no grupo <rodo> Segundo o Manual do CT-e 3.00 - página 12 item b temos: b) Declaração namespace O documento XML terá tão somente UMA declaração de namespace no elemento raiz do documento com o seguinte padrão: <CTe xmlns=”http://www.portalfiscal.inf.br/cte” > (exemplo para o XML do CT-e) Esse XML possui um namespace np grupo CTe que esta correto e uma segunda no grupo rodo que esta errado, conforme o manual. Os namespace que aparecem nos grupos cteProc e protCTe não traz nenhum prejuízo, pois são grupos que não fazem parte da estrutura do CT-e. O grupo cteProc contem dois grupos: CTe (gerado e enviado para SEFAZ) e protCTe (gerado e retornado pela SEFAZ), portanto é de se esperar que cada um desses dois grupos tenham os seus namespace. Segundo quem desenvolveu essa aplicação não sabe o que vem a ser o Recebedor e Expedidor e quando usar. Note que os dados do Expedidor são exatamente os mesmos do Remetente e os dados de Recebedor são exatamente os mesmos do Destinatário. O Expedidor e Recebedor só devem aparecer no XML do CT-e quando temos um CT-e cujo tipo de serviço é: 2 = Redespacho ou 3 = Redespacho intermediário. Se tratando de Redespacho deverá constar o Recebedor ou o Expedidor e nunca os dois, mais o Remente e o Destinatário. E se tratando de Redespacho Intermediário deverá constar somente o Recebedor e o Expedidor. Esse CT-e que você anexou o tipo de serviço é zero, ou seja, normal. Quanto a sua alteração visa resolver o problema de um CT-e mau feito cujo modal é o Rodoviário e os demais modais? Acredito que devemos adotar uma outra solução que atenda todos os modais.

Bom dia a todos, Pelo que entendi lendo a NT 2016/002 versão 1.61 as tags: pGLP, pGNn, pGNi e vPart só devem ser gerados se o valor de cProdANP for 210203001 caso contrario não devem serem gerados. Favor atualizarem os fontes e faça novos testes com cProdANP igual e diferente de 210203001.

Boa tarde, Você poderia anexar o XML da nota que foi rejeitada e o que foi autorizado?

Junior, Você disse que várias postagens suas estão sem nenhum retorno. Pois bem, você notou onde realizou essas postagens? Todas elas fora do ACBrDFe / ACBrNFSe. Se o seu problema é com o componente ACBrNFSe porque não posta no lugar destinado a ele? Fica ai a dica.

Bom dia Junior, Se o provedor ao retornar o resultado do recebimento do Lote não retorna um numero de protocolo, o que você espera que façamos? Que culpa tempos nós que a prefeitura contratou um provedor que não segue o layout da ABRASF? Não estou dizendo que você tem que se virar, mas que você entenda que nem todos os provedores tem a boa vontade de nos atender. Um tempo atrás entramos em contato com alguns provedores para simplesmente obter a lista de cidades atendidas por eles. Vários se recusaram a passar a lista. Agora imagina fornecer alguma informação técnica.

Bom dia, Hoje mandei para o repositório algumas alterações.

Bom dia Marcos, Esse erro ocorre porque você esta usando o componente com o Capicom, se passar a usar o WinCrypt o problema não ocorre.

Bom dia Dimas, Já fiz a alteração, ainda hoje estarei enviando para o repositório.

Bom dia a todos, A obrigatoriedade da assinatura será adotada para todas as cidades do provedor IPM? Favor solicitar junto ao provedor um XML exemplo que contem a assinatura.

Bom dia Simons, Compare o XML de exemplo que você anexou na postagem do dia 12/09 note que no grupo <Signature> existe uma diferença. No exemplo é usando apenas um algoritmo de transformação já o ACBr se utiliza de duas. Talvez o problema possa ser esse. Favor questionar o provedor sobre isso.

Bom dia a todos, Já encontra-se disponível o ambiente de homologação e produção para as empresas do Estado do Piauí poderem emitir o BP-e. O Estado do Piauí será atendido pela SEFAZ Virtual RS. Para realizarem os testes é necessário que as empresas entrem em contato com a SEFAZ do seu estado.

Beleza, ainda hoje estarei enviando para o repositório.

E o provedor processou com sucesso o RPS com o valor zero na tag <Alíquota> ?

Boa tarde Edu, É muito estanho a mensagem "em branco" vai ser necessário "debugar" para saber o motivo, pois a principio o cancelamento esta sendo realizado com sucesso e esta ocorrendo o retorno, acusando o cancelamento.

Boa tarde Igor, Tentou alterar a rotina? Exemplo: case FProvedor of proGINFES: Gerador.wCampoNFSe(tcDe4, '#25', 'Aliquota', 01, 05, 1, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ); proRJ, proPublica, proBHISS: Gerador.wCampoNFSe(tcDe4, '#25', 'Aliquota', 01, 05, 0, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ);

Boa tarde Edu, Favor anexar os XML de envio e de retorno referente ao cancelamento.