Italo Giurizzato Junior

Boa tarde jwester, Favor atualizar os fontes e testar novamente.

Boa tarde Gary, Favor atualizar os fontes e testar novamente.

Boa tarde Daniel, Favor atualizar os fontes e tentar novamente.

Binho, Para você ver que algumas dessas empresas que oferecem para as prefeituras o serviço de webservices de NFS-e são amadoras, note: Em particular o provedor mencionado por você. 1. No Schema temos a definição da TAG: IncentivadorCultural no grupo de informações do RPS <xsd:element name="IncentivadorCultural" type="tsSimNao" minOccurs="1" maxOccurs="1"/> 2. Definição do tipo simples: tsSimNao <xsd:simpleType name="tsSimNao"> <xsd:restriction base="xsd:byte"> <xsd:pattern value="1|2"/> </xsd:restriction> </xsd:simpleType> 3. Concluimos que a TAG IncentivadorCultural é obrigatória, uma vez que o minOccurs é igual a 1 e cujo valor será 1 ou 2, para Sim ou Não respectivamente. 4. No Schema temos a definição da TAG: IncentivadorCultural no grupo de informações da NFSe: <xsd:element name="IncentivadorCultural" type="tsSimNao" minOccurs="1" maxOccurs="1"/> 5. Também do mesmo tipo e obrigatório. 6. Se nós fossemos validar os XMLs de retorno, o XML referente a NFS-e que você anexou, não seria validado pois não consta essa TAG no mesmo. Fica aqui a pergunta, quem esta errado? Até quando vamos ter que fazer gambiarras, pois essas empresas não geram o XML conforme o schema. Cada vez mais ,acredito da seguinte frase: Faça o que eu mando, mas não faça o que eu faço. Ou seja, nós temos que gerar o XML do jeito que eles querem, mas o retorno eles fazem de qualquer jeito.

Boa tarde Hugo, Favor atualizar os fontes e testar novamente.

Boa tarde Lucas, Esta disponivel algumas alterações no componente ACBrNFSe. Vamos a elas: 1. Criei o provedor Pronim, este provedor vai utilizar o schema que você disponibilizou e relacionei a esse provedor a cidade de Catanduva/SP. 2. Realizei alterações em algumas units para completar a implementação do provedor Pronim. 3. A Unit ACBrProvedorGovBR agora não atende mais a cidade de Catanduva/SP e vai continuar utilizando os schemas que estão na pasta GovBR. Peço a você que refaça os testes com a cidade de Catanduva, so que agora utilizando os schemas da pasta Pronim. Se possível realizar os testes com as demais cidades atendidas por GovBR. As que falharem, vamos mudar para o Pronim e realizar os testes novamente. O porque dessas alterações e implementação? No Schema ( nfse.xsd ) que você disponibilizou que por sinal esta funcionando para a cidade de Catanduva/SP a TAG ValorISSRetido vem depois de ValorLiquido. Por outro lado na pasta GovBR temos vários schemas e em particular o ( tipos_complexos.xsd ) a TAG ValorISSRetido vem antes de ValorLiquido. Acredito que a Empresa GovBR para algumas cidades utilizou-se de um schema e para outras outro schema. Fico no aguardo de um retorno dos seus testes e aproveito para solicitar que os demais desenvolvedores que utilizam o componente para as cidades atendidas pelo provedor GovBR, por favor realizem os testes também. Desde já muito obrigado a todos.

Bom dia Rodrigo, Já esta disponivel a sua alteração. Muito obrigado pela colaboração. E aproveitei para incluir mais uma propriedade: EPECEnviado cujo valor padrão é False. Se o tipo de emissão for 4 e a propriedade EPECEnviado for True será acrescentado no quadro de Observação uma linha informado que o EPEC foi enviado para a SEFAZ.

Bom dia Hugo, No programa exemplo, temos varios botões para gerar e enviar, você já tentou utilizar o [Gerar e Enviar Lote] ou [Gerar e Enviar Lote Sincrono] ?

Bom dia Lucas, O Schema e a Unit da forma que estão funciona para qual cidade ou quais cidades?

Bom dia Daniel, Favor atualizar os fontes e testar novamente.

Bom dia Alan, O provedor SimplISS, realizou uma alteração no layout do XML, possibilitando a inclusão de mais de 1 um serviço. Logo o código mencionado por você, é um exemplo de como alimentar o componente para este provedor especifico. Portanto, devemos informar apenas 1 serviço, através da propriedade: ItemListaServico para os demais provedores.

Boa tarde Lucas, Por favor, post como anexo, o schema e a unit que você alterou, para que eu possa avaliar e disponibilizar para os demais.

Boa tarde Marcos, Tente desta forma: sProtocolo := ACBrMDFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt; sStat := IntToStr(ACBrMDFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.cStat); sMotivo := ACBrMDFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.xMotivo; sDataHora := DateTimeToStr(ACBrMDFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.dhRegEvento);

Bom dia lestipa, No meu entendimento devemos sim, acrescentar o digito "2" ou "4" dependendo do tipo de informação que esta sendo passanda, uma vez que TAG poderá conter o numero da DI ou DSI. Outra coisa, note que no XML essa TAG pode conter até 12 digitos.

Bom dia Márcio, Primeiramente, quem é obrigado a emitir o MDF-e? Vamos ao Ajuste Sinief 15 de 2012: (...) Cláusula terceira O MDF-e deverá ser emitido: “I - pelo contribuinte emitente de CT-e de que trata o Ajuste SINIEF 09/07, de 25 de outubro de 2007, no transporte de carga fracionada, assim entendida a que corresponda a mais de um conhecimento de transporte; II - pelo contribuinte emitente de NF-e de que trata o Ajuste SINIEF 07/05, de 30 de setembro de 2005, no transporte de bens ou mercadorias acobertadas por mais de uma NF-e, realizado em veículos próprios ou arrendados, ou mediante contratação de transportador autônomo de cargas.”; (...) (...) Cláusula décima sétima A obrigatoriedade de emissão do MDF-e será imposta aos contribuintes de acordo com o seguinte cronograma: Nova redação dada ao inciso I da cláusula décima sétima pelo Ajuste SINIEF 10/13, efeitos a partir de 26.06.13. I - na hipótese de contribuinte emitente do CT-e de que trata o Ajuste SINIEF 09/07, no transporte interestadual de carga fracionada, a partir das seguintes datas: a) 2 de janeiro de 2014, para os contribuintes que prestam serviço no modal rodoviário relacionados no Anexo Único ao Ajuste SINIEF 09/07 e para os contribuintes que prestam serviço no modal aéreo; 2 de janeiro de 2014, para os contribuintes que prestam serviço no modal ferroviário; c) 1º de julho de 2014, para os contribuintes que prestam serviço no modal rodoviário, não optantes pelo regime do Simples Nacional e para os contribuintes que prestam serviço no modal aquaviário; d) 1º de outubro de 2014, para os contribuintes que prestam serviço no modal rodoviário optantes pelo regime do Simples Nacional; II - na hipótese de contribuinte emitente de NF-e de que trata o Ajuste SINIEF 07/05, no transporte interestadual de bens ou mercadorias acobertadas por mais de uma NF-e, realizado em veículos próprios ou arrendados, ou mediante contratação de transportador autônomo de cargas, a partir das seguintes datas: a) 3 de fevereiro de 2014, para os contribuintes não optantes pelo regime do Simples Nacional; 1º de outubro de 2014, para os contribuintes optantes pelo regime do Simples Nacional. (...) Acredito que isso responde a sua pergunta. Como você pode ver, não é só as transportadoras que são obrigadas a emitir o MDF-e. Mas tudo depende da situação.

Bom dia Luis, Todos os testes que eu faço, informo como documento originário o tipo Outros, como por exemplo uma declaração. Desta forma não tem como eles acusarem que o documento não existe. Sei que não pratica não é desta forma que funciona. Mas, acredito que como eu, você esta realizando testes no ambiente de homologação, sendo assim, ele não deveria checar a chave da NF-e colocada como documento originário. E pelo jeito esta checando e por se tratar de um ambiente de homologação, deve estar procurando essa chave também na base de dados do ambiente de homologação. Acredito eu, que não teremos esse problema no ambiente de produção, visto que, a NF-e foi autorizada no ambiente de produção e o CT-e esta sendo enviando tambéma para o mesmo ambiente.

Boa noite Kiko, Segundo a NT 2013/005 v1.02 página 87, temos: Regra de Validação: I19-10 para o modelo 55 Número da DI / DSI inválido ***Implementação futura Obrig. 329 Rej. Rejeição: Número da DI /DSI inválido Como você ver a implementação da checagem dessa informação é obrigatória, só que a SEFAZ ainda vai demorar um pouco para implementar.

Boa tarde Rodrigo, Você se refere ao XML de qual provedor ou de qual cidade?

Boa tarde Antonio, Checando a unit responsável pela leitura do XML notei que esse problema já foi sanado, veja: (*C14*)NFe.Emit.enderEmit.cPais := Leitor.rCampo(tcInt, 'cPais'); if NFe.Emit.enderEmit.cPais = 0 then NFe.Emit.enderEmit.cPais := 1058; Tanto para o Emitente quanto para o Destinatário. Conclu-o que os seus fontes estão desatualizados.

Boa tarde lestipa, A rotina que valida o campo nDI, foi elabora com base na NT 2013/005 versão 1.01, mais precisamente página 97.

Boa tarde Vanessa, Quando ocorre o Encerramento temos o retorno 132 acusando o Encerramento homologado e também o 135 acusando que o evento de encerramento foi vinculado ao MDF-e Isso também ocorre com o cancelamento. Você já tentou realizar uma consulta para ver o conteudo do XML de retorno de um MDF-e cancelado e outro encerrado?

Boa tarde Idez, Favor atualizar os fontes e testar.

Realizei testes com o programa exemplo. Executando o Imprimir, ImprimirPDF, ImprimirEvento e ImprimirEventoPDF e nenhum deles ocorreu erro. Apenas fiz testes de visualização, não enviei para a impressora.

Djean, E com o programa exemplo, também ocorre esse erro?

Bom dia Djean, Você tentou usuar o programa exemplo que acompanha o componente? Observação: ele se utiliza do Quick Report como gerador de relatórios.