Italo Giurizzato Junior

Bom dia Vânia, Lendo a sua postagem e analisando esses 2 últimos XML que você anexou notei o seguinte: Primeiro, algumas tags você esta informando 2 ou 3 casas decimais sendo que o correto seria 4. Note que o XML gerado e assinado pelo Monitor faz essa correção. Outra coisa, no grupo ICMS20 você gerou as tags: vBCFCP, pFCP e vFCP com o valor zero. O monitor por sua vez ao gerar o novo XML removeu essas 3 tags. Vamos entender o porque o Monitor fez essa remoção, abaixo temos um fragmento do manual que se refere a essas 3 tags: Note que as 3 tags são obrigatórios pois na coluna de ocorrências aparece 1-1, mas veja que as 3 são fichas de um grupo fictício (N17.1) chamado: -x- Sequencia XML que é opcional. O que o manual esta querendo nos informar é que essas 3 tags formam um grupo, sendo assim ou todas são geradas ou nenhuma delas vão constar no XML. E quando elas devem ser geradas? Quando o valor das 3 forem diferente de zero, você até poderia informar a base de calculo do FPC, mas como o percentual é zero, logo o valor do FPC é zero. Neste caso não faz sendo informar a base de calculo diferente de zero e o percentual e o valor como sendo zero. Como não tem FCP - para o item em questão as 3 tags não devem ser geradas. Não analisei as demais tags que não foram geradas no novo XML gerado pelo Monitor, mas acredito que o motivo seja o mesmo.

Bom dia Leo, O grande problema é que os provedores disponibilizam um Schema para que possamos validar o Lote de RPS antes do seu envio, mas o schema usado pelo validador do webservice é outro. Segundo o Schema disponibilizado pelo provedor entre o grupo <Tomador> e o elemento <OptanteSimplesNacional> temos: <xsd:element name="Tomador" type="tcDadosTomador" minOccurs="0" maxOccurs="1" /> <xsd:element name="Intermediario" type="tcDadosIntermediario" minOccurs="0" maxOccurs="1" /> <xsd:element name="ConstrucaoCivil" type="tcDadosConstrucaoCivil" minOccurs="0" maxOccurs="1" /> <xsd:element name="RegimeEspecialTributacao" type="tsRegimeEspecialTributacao" minOccurs="0" maxOccurs="1" /> <xsd:element name="OptanteSimplesNacional" type="tsSimNao" minOccurs="1" maxOccurs="1" /> Note que os grupos: <Intermidiario>, <ConstrucaoCivil> e o elemento <RegimeEspecialTributacao> que aparecem na mensagem de rejeição, segundo o Schema são opcionais. Mas como dito antes, o Schema usado no webservice exige que o elemento <RegimeEspecialTributacao> seja obrigatório. Sendo assim informe o Regime Especial de Tributação que as chances do RPS ser aceito é grande.

Bom dia Thiago, Todos os provedores (empresas contratadas pelas prefeituras) que seguem a versão 2 do layout da ABRASF a principio disponibiliza o serviço de envio Síncrono. Neste caso não temos o serviço para consultar a situação do lote. O que temos é o Consultar Lote que se o lote enviado foi processado com sucesso, teremos como retorno o XML da NFS-e, caso contrario teremos a lista de rejeições. Estude o programa exemplo do componente ACBrNFSe.

Bom dia Danilo, Estamos analisando esse efeito colateral.

Bom dia, O componente de impressão possui uma propriedade chamada MostraPreview (se não me falha a memória) que devemos atribuir o valor False para que o Preview não seja apresentado na tela.

Bom dia João, Estamos analisando esse efeito colateral.

Bom dia Souza, Note que a sua nota foi processada e autorizada pela SEFAZ. Abra o XML que você anexou e veja no final que consta o protocolo de autorização. Favor anexar todos os XML gerados ao enviar essa nota, pois essa mensagem de erro pode ser referente a outra ação que o monitor esteja realizando.

Danilo, Mas a unit que passei não tem nada haver com essa.

Boa tarde Danilo, Favor testar com as units abaixo: ACBrDFeXsLibXml2.pas ACBrNFSeWebServices.pas

Boa tarde João, Peço que faça um teste com as Units abaixo: ACBrDFeXsLibXml2.pas ACBrNFSeWebServices.pas

Boa tarde William, Acabei de fazer um teste usando o programa exemplo, o XML do evento 2200 foi gerado, assinado e validado com sucesso. Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a Suite ACBr usando o ACBrInstall_Trunk2 com a opção: apagar arquivos antigos marcada? Configurou o programa exemplo para usar os schemas da pasta: ...\trunk2\Exemplos\ACBrDFe\Schemas\eSocial ?

Boa tarde Volnei, Sim, mas peço que leia as Notas Técnicas pois consta informações importantes para o Desenvolvedor e contem as datas de implementação no ambiente de homologação e produção das SEFAZ.

Boa tarde Souza, Segundo a Nota Técnica 2016/002 versão 1.61 temos: * Remoção do campo indPag (B05) * Acrescentado a opção 5 no campo indPres (B25b) * Inclusão do Campo indPag (YA01b) no Grupo YA. Informações de Pagamento. Pela estrutura apresentada pela referida NT o campo indPag vem antes de tPag. Note que a rejeição diz que o campo indPag é inesperado e que o esperado é tPag. Isso demostra que o Webservice da Bahia esta desatualizado. Resumindo o problema esta na SEFAZ. O ACBrMonitor esta gerando o XML em conformidade com a NT. A inclusão do campo indPag (YA01b) se deu na versão 1.50 da referida NT sendo assim o prazo de implantação no ambiente de homologação foi 21/05/2018. Pelo jeito a SEFAZ-BA não fez o dever de casa.

Bom dia a todos, Os componentes ACBrNFe, ACBrCTe e ACBrMDFe já estão preparados para gerar o grupo <infRespTec> = Informações do Responsável Técnico. Para quem emite NF-e favor ler a Nota Técnica 2018/005, já os emitentes de CT-e - Nota Técnica 2018/002 versão 1.01, e MDF-e - Nota Técnica 2018/002 versão 1.02 Essas NT estão disponíveis nos Portais de cada Documento Fiscal Eletrônico. Para quem esta com os fontes atualizados e reinstalados, ao selecionar o componente ACBrNFe ou ACBrCTe ou ACBrMDFe vai notar no Object Inspector em Configurações o grupo RespTec e dentro deste as propriedades idCSRT e CSRT. O grupo <infRespTec> contem as seguintes informações: CNPJ, Nome, e-mail, telefone, idCSRT e HashCSRT do Responsável Técnico. Sendo que as duas ultimas são geradas automaticamente se as propriedades idCSRT e CSRT forem informadas. Logo o que muda na aplicação: Configuração: Configuracoes.RespTec.idCSRT := <identicador do CSRT> Configuracoes.RespTec.CSRT := <Código de Segurança do Responsável Técnico> Tanto o ID quanto o código serão fornecidos futuramente pela SEFAZ, sendo assim devemos atribuir zero ao idCSRT e uma string vazia para CSRT, nesse primeiro momento. Rotina que alimenta o componente: // Dados do Responsável Técnico infRespTec.CNPJ := xCNPJ_RespTec; infRespTec.xContato := xContato_RespTec; // Nome do responsável técnico infRespTec.email := xEmail_RespTec; infRespTec.fone := xFone_RespTec; Como dito acima o idCSRT e HashCSRT são gerados automaticamente caso o idCSRT seja diferente de zero e CSRT diferente de uma string vazia. Observação: Tanto a configuração quanto a alimentação do componente é exatamente a mesma conforme o exemplo acima para a NF-e, CT-e e MDF-e. A geração desse grupo esta condicionada a cada UF, sendo assim uma UF poderá exigir e outra não, logo devemos ficar atento a legislação de cada UF.

Bom dia Morgana, Se você tenta encerrar o MDF-e 272 ocorre a rejeição refere a data é porque ele existe, caso contrario deveria mostrar a rejeição informando que o MDF-e não consta na base de dados da SEFAZ. Entre no Portal do MDF-e e tente baixar o MDF-e em questão.

João, Você poderia fazer esse teste de enviar o cancelamento?

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

Bom dia Josafar, Caso você tenha 5 UF (percurso) entre a UF Origem e UF Destino é simples, basta executar 5 vezes o trecho abaixo (uma para cada UF). with Ide.infPercurso.Add do begin UFPer:= mskUFPer.Text; end; O Add vai acionar a UF cada vez que é executado, portanto o valor de mskUFPer.Text tem que mudar pra cada vez que ele é executado. Exemplo da minha aplicação: j := DM_MDF.Percursos.RecordCount -1; // Checa a quantidade de UF de Percurso na tabela Percursos if j >= 0 then begin DM_MDF.Percursos.First; // Posiciona na primeira UF for i := 0 to j do begin with Ide.infPercurso.Add do begin UFPer := DM_MDF.PercursosUFPerc.AsString; // Lê da tabela Percursos o valor do campo UFPerc end; DM_MDF.Percursos.Next; // Avança para a próxima UF end; end;

Bom dia João, Eu não sei porque tem provedor que não defini o atributo ID como sendo "Id", paciência (para não escrever outra coisa). O grande problema do cancelamento é que temos de forma resumida o seguinte layout: <CancelarNFseEnvio> <=== Nível 1 <Pedido> <=== Nível 2 <InfPedidoCancelamento Id="valor do ID"> <=== Nível 3 (...) </InfPedidoCancelamento> <Signature> <=== Nível 3 (...) </Signature> </Pedido> </CancelarNFseEnvio> Se ID for "id" ocorre erro ao usar o libCapicom, para que o erro não ocorra não podemos atribuir o valor do ID ao atributo URI da assinatura. Por outro lado se usarmos o libWinCrypt o erro não ocorre e o valor do ID é atribuído a URI. Mas ai surge um segundo problema. Note que o grupo <Signature> se encontra no nível 3 da estrutura, com o libCapicom a assinatura é realizada e o grupo <Signature> é inserido no local correto. Por outro lado com o libWinCrypt a assinatura é realizada mas o grupo <Signature> é colocada no nível 2, ou seja ficando abaixo do </Pedido> (fechamento do grupo Pedido). Foi feita uma alteração para contornar isso, mas me parece que essa alteração esta gerando uma assinatura invalida.

Bom dia Felipe, Primeiro: o cliente que rejeitou a carga deve emitir uma NF-e caso ele seja contribuinte ou uma CRM - Carta Remessa de Mercadoria a titulo de devolução. Segundo: a transportadora deverá emitir um novo CT-e e utilizar como documento originário a NF-e ou a CRM emitida por esse cliente que agora vai figurar no CT-e como sendo o remetente da carga e quem era antes o remetente passa a ser o destinatário. Portanto você não vai usar o mesmo CT-e e muito menos emitir uma carta de correção.

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

Duarte, Já esta no repositório, atualize e veja como ficou o INI do provedor, já enviei também a unit que você alterou. Fiz um teste, consegui enviar e obter uma resposta satisfatória do webservice. Depois é preciso incluir no arquivo Cidades.INI as demais cidades que se utilizam desse provedor.

Bom dia Duarte, Muito obrigado pela colaboração, já estou fazendo alterações no arquivo INI do provedor e vou comparar o XML gerado com o Schema. Ainda hoje vou enviar as alterações para o repositório.

Boa noite Renan, É bem provável que seja publicado alguma Nota Técnica ou cada Estado em seu site vai constar algo informando sobre a obrigatoriedade.

Willian, Você tem certeza que atualizou todos os fontes de todas as pastas? Não tem nenhum fonte com uma bolinha vermelha em seu ícone?