-
Total de ítens
37.475 -
Registro em
-
Última visita
-
Days Won
1.056
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Tudo que Italo Giurizzato Junior postou
-
ACBR ignora e não gera as tags com valor zero
Italo Giurizzato Junior replied to Vânia Falcao's tópico in ACBrMonitorPLUS
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.
- 5 replies
-
- 1
-
- porto velho
- e168
-
(e 1 mais)
Tags:
-
Situação e Retorno NFS-e (Envio Sincrono)
Italo Giurizzato Junior replied to Thiago Domingues's tópico in ACBrNFSe
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.
-
Impressão DANFE - NFS-e
Italo Giurizzato Junior replied to EGOS Soluções's tópico in DFe - Documentos Fiscais Eletrônicos
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.
-
has invalid child element 'indPag'
Italo Giurizzato Junior replied to cau_souza's tópico in ACBrMonitorPLUS
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
-
erro ao gerar evento S-2200
Italo Giurizzato Junior replied to William Inácio's tópico in ACBreSocial
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 ? -
has invalid child element 'indPag'
Italo Giurizzato Junior replied to cau_souza's tópico in ACBrMonitorPLUS
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. -
Grupo de Informações do Responsável Técnico
um tópico no fórum postou Italo Giurizzato Junior Notícias do ACBr
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. -
Erro 635- Encerrar MDF-e apresenta erro sobre data do evento
Italo Giurizzato Junior replied to Morgana's tópico in ACBrDiversos
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.
-
NFSD - Desenvolve D.
Italo Giurizzato Junior replied to Duarte's tópico in DFe - Documentos Fiscais Eletrônicos
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. -
NFSD - Desenvolve D.
Italo Giurizzato Junior replied to Duarte's tópico in DFe - Documentos Fiscais Eletrônicos
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. -
Grupo ZD. Informações do Responsável Técnico
Italo Giurizzato Junior replied to Renan S's tópico in ACBrNFe
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. -
Problema com a váriavel "ConsStatServ"
Italo Giurizzato Junior replied to Willian Carminatt's tópico in ACBrNFe
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?