Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    37.496
  • Registro em

  • Última visita

  • Days Won

    1.056

Tudo que Italo Giurizzato Junior postou

  1. Boa tarde, Muito obrigado pela colaboração, já inclui a cidade no arquivo Cidades.ini, ainda hoje estarei enviando para o repositório. Quando desejar informar novas cidades ou troca de provedor, favor utilizar o tópico: Tópico exclusivo para troca de provedor e novas cidades.
  2. Boa tarde Celso, Tente com a libCapicom em vez de libWinCrypt.
  3. Boa tarde João, A mensagem de erro é muito vaga, pois não informa se a assinatura que esta errada é do RPS ou do Lote. Tente um contato com o provedor e veja se consegue deles uma resposta mais clara, ou seja, qual das duas assinaturas esta errada. Lembre-se que a rotina responsável por realizar a assinatura digital é a mesma usada para assinar o tanto RPS quanto o Lote, sem contar que ela também é usada pelos componentes: ACBrNFe, ACBCTe, ACBrMDFe, ACBrBPe, ACBreSocial e ACBrReinf.
  4. Boa tarde Ricardo, Faça um teste usando o arquivo INI em anexo. WebISS.ini
  5. Boa tarde, A ideia dessa propriedade e mudar o layout de impressão do DANFSE. Com o refactoring ocorrido na impressão dos Documentos Auxiliares, isso inclui o DANFSE, pode ter ocorrido alguma alteração que fez com que essa propriedade de configuração parasse de funcionar. Como no XML da NFS-e retornado pelo provedor não consta todos os dados do Prestador do Serviço, acredito que a única solução vai ser: Após carregar o XML da NFS-e, popular as propriedades do Prestador, lendo as informações do banco de dados e depois executar o método para imprimir o DANFSE.
  6. Boa tarde Eraldo, Acredito que você não olhou para o código do programa, veja: // TnfseRegimeEspecialTributacao = ( retNenhum, retMicroempresaMunicipal, retEstimativa, retSociedadeProfissionais, retCooperativa, retMicroempresarioIndividual, retMicroempresarioEmpresaPP ); RegimeEspecialTributacao := retNenhum; // RegimeEspecialTributacao := retSimplesNacional; // TnfseSimNao = ( snSim, snNao ); OptanteSimplesNacional := snNao; // TnfseSimNao = ( snSim, snNao ); IncentivadorCultural := snNao;
  7. Boa tarde, Muito obrigado pela colaboração. Já inclui no arquivo Cidades.ini e ainda hoje estarei enviando para o repositório.
  8. 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;
  9. Boa tarde Maikon, Favor atualizar os fontes e faça novos testes.
  10. Boa tarde Gabriel, Muito obrigado pela colaboração, já esta no repositório.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  16. 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.
  17. Boa tarde Maikon, Vamos aos testes, altere essa URL de http:// para https:// Faça um novo teste.
  18. Boa tarde Wesley, Você poderia anexar o PDF de um DANFE ou somente a imagem da informação em questão?
  19. Boa tarde Gleryston, A sua alteração esta correta, muito obrigado pela colaboração, já enviei para o repositório.
  20. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  21. 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.
  22. 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
  23. 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.
  24. 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.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.