Italo Giurizzato Junior

Boa tarde Walter, Como assim não reconhece? with ACBrCTe1.Conhecimentos.Add.CTe do begin (...) {Carrega as informacoes CTe Normal} with infCTeNorm do begin (...) {Carrega dados da CTe substituta 0-1} with infCTeSub do begin chCte := ''; //Se tomador não é Contribuinte tomaNaoICMS.refCteAnu := ''; //Se tomador for Contribuinte case TipoDoc of // TipoDoc = Tipo do Documento que o Tomador Emitiu para anulação de valor do Cte Anterior 0: tomaICMS.refNFe := '';//NFe 1: tomaICMS.refCte := '';//CTe 2://NF begin tomaICMS.refNF.CNPJCPF := ''; tomaICMS.refNF.modelo := ''; tomaICMS.refNF.serie := 0; tomaICMS.refNF.subserie := 0; tomaICMS.refNF.nro := 0; tomaICMS.refNF.valor := 0; tomaICMS.refNF.dEmi := Date; end; end; end; (...) end; (...) end;

Boa tarde Maikon, Favor atualizar os fontes e faça novos testes.

Boa tarde Gabriel, Muito obrigado pela colaboração, já esta no repositório.

Bom dia José, Concordo com você se o sistema de pagamento não esta integrado com o de automação, não existe nenhuma garantia que realmente no pagamento foi utilizado a bandeira ABC ou DEF, bem como se foi crédito ou débito. É muito comum notarmos em supermercados o cliente tentar pagar com um cartão e não conseguir e realizar o pagamento com outro, que podem ter bandeiras diferentes. Exemplo, não conseguir pagar com o cartão de débito vale alimentação, pois não foi liberado o dinheiro e ter que pagar com o cartão de crédito.

Bom dia Paulo, Vou fazer as alterações no componente visando gerar o XML segundo o exemplo, mas neste caso como o Schema fornecido não bate com o exemplo, não será possível realizar a validação antes do envio. A minha sugestão é que você e outros desenvolvedores peçam aos seus clientes a ir na prefeitura e protocolar uma reclamação referente a esse provedor, motivo: falta de documentação e o pouco que foi fornecido é divergente, ou seja, os Schemas usados para validar o XML antes do seu envio não bate com o XML de exemplo fornecido. Até que me prove o contrario, vejo essa empresa como amadora, que implementou um webservice nas "coxas", ou seja, não se baseou no layout estabelecido nos Schemas.

Bom dia Eraldo, Se faz necessário saber quais os valores que estão sendo informados no XML nos campos mencionados na mensagem. Com certeza devem estar com os valores errados ou se a tag for opcional a mesma pode não estar sendo gerada.

Bom dia Wesley, Segundo a versão 6.00 do Manual da NF-e temos na página 265 um modelo do DANFE, onde na figura abaixo temos o quadro referente a modalidade do frete: Como você pode ver, o quadro já possui um titulo: "Frete por Conta", sendo assim não vejo nenhuma necessidade de constar nesse quadro logo abaixo do titulo o seguinte texto (por exemplo): "Contratação do Frete por conta do Remetente (CIF)", visto que esse quadro se refere a contratação do frete. No meu entendimento a impressão da palavra "Remetente" já é o suficiente para deixar claro, por conta do titulo que o quadro possui. Outra coisa, a nota técnica que você se refere no item 5.1 deixa claro qual é o código que devemos atribuir ao campo X02, ou seja, a tag modFrete, mas em nenhum momento diz qual é o texto que devemos imprimir no quadro. Por fim na imagem que o Big Wings postou, na linha referente a "Frete Por Conta de" temos na coluna observação a indicação Obs 8. Na página 144 temos: Obs 8: TAG: X02 Isso me faz crer que no quadro em questão devemos imprimir o valor da tag X02, ou seja, modFrete, portanto (0, 1, 2, 3, 4 ou 9). Concluo a minha postagem que estou de acordo com o Big Wings.

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

Olá pessoal, Vamos utilizar este tópico somente para anexar o arquivo Cidades.ini e se necessário o arquivo INI do provedor quanto ocorrer a troca de provedor de uma cidade ou para incluir uma nova cidade. Algumas regras básicas: 1. Qualquer postagem nesse tópico que não tenha o objetivo exposto acima será excluído sem aviso prévio. 2. Informar se a postagem se refere a uma troca ou inclusão de cidade. 3. Se for troca informar a cidade, o provedor que vai deixar de atender e o novo, não esqueça de informar a data de inicio. 4. Se for uma inclusão informar a cidade e o provedor. 5. Ao anexar o arquivo Cidades.ini e o arquivo INI do provedor (quando se fizer necessário) estes devem estar o mais atualizados possíveis, ou seja, primeiro atualize os seus fontes e depois faça as alterações no arquivo Cidades.ini e no INI do provedor e anexe aqui no tópico. 6. Não faça alteração no arquivo INI do provedor que possa gerar efeito colateral para as demais cidades atendidas pelo mesmo provedor. 7. Procure realizar testes para saber se as suas alterações forem bem sucedidas. 8. Exemplos de uma postagens: A cidade XYZ trocou de provedor (de: ABC para DEF). O provedor DEF vai passar a recepcionar as notas a partir de dd/mm/aaaa. Segue em anexo os arquivos INI. A cidade XYZ se utiliza do provedor ABC. Segue em anexo os arquivos INI. Obrigado pela compreensão de todos. Desde já muito obrigado pelas colaborações.

Boa tarde Maikon, Vamos aos testes, altere essa URL de http:// para https:// Faça um novo teste.

Boa tarde Wesley, Você poderia anexar o PDF de um DANFE ou somente a imagem da informação em questão?

Boa tarde Gleryston, A sua alteração esta correta, muito obrigado pela colaboração, já enviei para o repositório.

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

Boa tarde, Na unit ACBrMDFe, temos o seguinte método: function ConsultarMDFeNaoEnc(const ACNPJCPF: String): Boolean; ACBrMDFe1.ConsultarMDFeNapEnc(xCNPJCPF); Você notou que o programa exemplo possui um botão que exemplifica esse tipo de consulta? De uma forma diferente a de cima, mas tem.

Boa tarde Gustavo, Primeiramente quem envia o evento de comprovante de entrega é a própria transportadora, portanto o emitente do CT-e. No XML do pedido do evento a chave do CT-e os 2 primeiros dígitos é o código IBGE da UF cujo CT-e foi emitido, e consta 24, logo a UF é RN e não MG. Olhando o seu XML, notei algumas coisas erradas: 1. O código da UF que aparece no cabeçalho é 35 = SP, portanto esta errado, deveria ser 24. 2. Data/Hora de entrega, só consta a data, a hora esta toda zerada, isso pode fazer com que ocorra outros tipos de rejeição. dhEvento >= dhhashEntrega > dhEntrega

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

Bom dia, O Encerramento é um evento, vide o programa exemplo. Nele é solicitado o XML para poder extrair do mesmo as informações necessárias. Mas se você tem essas informações no banco de dados, em vez de carregar o XML para ter acesso as informações, basta ler elas do banco de dados e passar para o componente. Não entendi qual é a dificuldade.

Bom dia Roberto, Você esta usando o DAMDFE feito em Fast ou Fortes? Anexa o PDF de como esta sendo impresso e o XML do mesmo.

Bom dia Walter, Tente da seguinte forma: infCTeNorm.infCTeSub.chCte := <chave do CT-e Normal>; infCTeNorm.infCTeSub.refCteAnu := <chave do CT-e de Anulação>; caso o tomador não seja contribuinte do ICMS e foi emitido antes o CT-e de Anulação. ou infCTeNorm.infCTeSub.chCte := <chave do CT-e Normal>; infCTeNorm.infCTeSub.tomaICMS.refNFe := <chave da NF-e de Anulação>; caso o tomador seja contribuinte e emitiu a NF-e de Anulação.

Paulo, Já esta no repositório, os arquivos Cidades.ini e SimplISSv2.ini, bem como a pasta SimplISSv2 que contem os schemas. Enviei também algumas alterações nos fontes visando o componente. Infelizmente o provedor fornece um Schema que não condiz com o que foi implementado no Webservice, dai o erro. Repito, uma tremenda falta de respeito e muito amadorismo.

Bom dia Paulo, Com o Schema corrigido pelo nosso amigo BigWings consegui validar o XML gerado. Mas a estrutura do XML que o webservice espera não é exatamente a que consta no Schema. Vamos a um exemplo: No Schema temos: <xsd:complexType name="tcLoteRps"> <xsd:sequence> <xsd:element name="NumeroLote" type="tsNumeroLote" minOccurs="1" maxOccurs="1" /> <xsd:element name="CpfCnpj" type="tcCpfCnpj" minOccurs="1" maxOccurs="1" /> <xsd:element name="InscricaoMunicipal" type="tsInscricaoMunicipal" minOccurs="0" maxOccurs="1" /> (...) </xsd:sequence> <xsd:attribute name="Id" type="tsIdTag" /> <xsd:attribute name="versao" type="tsVersao" use="required" /> </xsd:complexType> Só que o webservice espera pela tag <Cnpj> e não pelo grupo <CpfCnpj> conforme consta no schema. Imagem do Erro ao enviar o Lote. Ou esse provedor faça as devidas correções no webservice para que o mesmo fique em conformidade com o Schema, ou eles forneçam um Schema que condiz com o que o webservice espera receber. Esse tipo de situação, para mim é uma tremenda falta de respeito para com os contribuintes da cidade e muito amadorismo. A minha sugestão é pedir para os seus clientes protocolarem na prefeitura uma reclamação, informando que com o Schema fornecido por eles, além de ter sido corrigido para poder usar não bate com o que o webservice espera. A finalidade do Schema é poder validar o XML antes do seu envio com o objetivo de evitar o envio de um XML que contenha erros de estrutura.

Bom dia a todos, O consultar status só serve para saber se o webservice do status esta funcionando, se ele retornasse a situação de todos os serviços (recepção, consulta, evento, inutilização, ...) seria uma maravilha, mas infelizmente não é assim que a coisa funciona. E outro detalhe importante, o DistribuicaoDFe é um serviço disponibilizado pelo Ambiente Nacional e não pela SEFAZ-Autorizadora. Logo não adianta absolutamente nada, executar o consultar status de serviço.

Paulo, A mensagem de erro é:

Paulo, Precisa de usuário e senha, como sou do Estado de São Paulo, acredito que não vou conseguir me cadastrar para poder ter acesso. Tente mandar por e-mail para mim.

Paulo, Ao usar esse schema que você anexou acusa que ele é invalido, preciso descobrir o que esta errado nele. O link que contem o manual não abre, a tela fica em branco.