Italo Giurizzato Junior

Boa tarde Luciano, O ACBrNFeMonitor não estava conseguindo identificar o comando para imprimir eventos. Fiz a correção e já esta disponível, favor aguardar a nova compilação do ACBrNFeMonitor.

Boa noite Sérgio, Acredito que você não leu com atenção o item 3 do manual. Na sua postagem você diz que não encontrou no manual como informar os dados do emitente, destinatário e produtos, pois muito bem, no item 3 temos um paragrafo que diz: O programa exemplo: ACBrNFe_demo que encontra-se na pasta: ...\Exemplos\ACBrNFe2\Delphi possui uma procedure chamada GerarNFe que exemplifica a alimentação dessas propriedades com os dados pertinentes a venda. Quando me refiro "dados pertinentes a venda" estou me referindo ao emitente, destinatário e produtos. Convido a você a estudar o programa exemplo e ler os Manuais e Notas Técnicas que Juliomar mencionou em sua postagem.

Boa noite a todos, A principio devemos utilizar a série = 1 até que a numeração atinja 999.999.999, ai devemos incrementar a série ou seja passamos para a série = 2 e a numeração volta para 1. Não entendi o motivo de utilizar séries diferentes para modais diferentes, a questão é a nível de relatório? se sim basta colocar no mesmo uma coluna referente ao modal. Não há necessidade de pedir permissão a SEFAZ para utilizar uma nova série e também não vejo necessidade de se utilizar uma série diferente para cada "ponta", é possível gerenciar isso de outras formas, como por exemplo pelo CNPJ do emitente, caso cada "ponta" possua um CNPJ diferente, se possuir o mesmo, pode-se ter um campo no banco de dados que defini o local de emissão e esta informação pode ser incluída nos relatórios operacionais e gerenciais.

Boa noite Gustavo, Post como anexo o lote que contem mais de um CT-e e que um deles (não pode ser o primeiro) tenha sido rejeitado. E post como anexo também o retorno do envio do respectivo lote,

Boa noite Thiago, Um problema parecido ocorreu também com o CT-e e MDF-e, fiz uma alteração nos componentes desses documentos fiscais. Amanhã fazei a mesma alteração no componente da NF-e e depois é só aguardar a liberação da nova compilação do ACBrNFeMonitor.

Bom dia Gustavo, Infelizmente a SEFAZ não retorna o na mesma sequencia que você envia. Se todos os CT-e do lote forem autorizados no retorno vai estar na mesma sequencia do envio. Mas se um deles for rejeitado, este será colocado em primeiro lugar. exemplo envio dos CT-e: 1, 2 e 3 (nesta sequencia) se o 2 for rejeitado temos no retorno a seguinte sequencia: 2, 1 e 3 Você deve estar lendo o retorno e atualizando o banco de dados sem checar exatamente quem você esta lendo, acreditando que o retorno encontra-se na mesma sequencia do envio.

Alexandre, O que precisa ficar claro é que temos interesse em fazer com que o componente atenda o maior numero possível de cidades no que diz respeito a emissão da NFS-e. Mas precisamos da compreensão e colaboração de todos. Compreensão, pois não temos condições de desenvolver a toque de caixa e o que foi desenvolvido não vai funcionar de primeira. Colaboração, pois sem as informações e os arquivos que listei, não temos como dar inicio ao desenvolvimento e quanto mais pessoas estiverem envolvidas, escrevendo códigos, testando, fazendo as correções fica mais fácil.

Bom dia Igor, Não se deve mudar o nome do título do quadro no DACTE uma vez que ele segue o manual. Para que a informação seja impressa no local correto devemos informar: tpMed = "PESO BRUTO" ou tpMed = "PESO BC"

Bom dia, Por favor faça uma nova atualização dos fontes e teste novamente.

Bom dia Luciano, Você tem certeza que o nome que você informou como sendo do evento é exatamente esse? <chave> + <tipo evento> + -procEventoMDFe.xml que eu saiba é: <ID do evento> + -procEventoMDFe.xml onde <ID do evento> = <tipo evento> + <chave> + <numero seq. evento>

Bom dia Alexandre, Desculpe, mas você não mandou o schema no inicio do tópico e sim as URLs de homologação e de produção. É preciso muito mais: 1. schema (arquivo XSD) usado para validar o lote de RPS gerado antes do envio para o Web Services. 2. NameSpace (é uma URL que informada no XML). 3. Arquivos XML de exemplos de envio, cancelamento e consulta. 4. Arquivos soap de exemplos, esses arquivos também são XML mas eles contem toda a estrutura de envelopamento do XML a ser enviado para o Web Services. 5. Esse Web Services atende somente a cidade de São Pedro da Aldeira? De posse de todos esses arquivos e informações, se você programa em Delphi e tiver curiosidade em aprender como o componente funciona basta você analisar como foi implementado os demais provedores e tentar implementar para a cidade desejada. O ACBr não é uma empresa que desenvolve e disponibiliza soluções e sim um grupo de centenas e milhares de pessoas que compartilham informações, conhecimento e códigos.

Bom dia Luis, Primeiramente, não entendi, você gera as notas de entrada? Essas notas são de compra de mercadoria ou de entrada por devolução? Se for de compra, é o seu fornecedor que deve disponibilizar os XMLs das mesmas. Você diz que gera o XML das notas que não são eletrônicas? Esta errado isso, pois o seu fornecedor emitiu uma nota segundo um modelo e você gera o Sped em outro modelo, no caso 55 ou 65. O componente esta em conformidade com a Nota Técnica 2013/005 versão 1.22 Até a versão 2.00 tínhamos duas TAGs: dSaiEnt e hSaiEnt para informar a data e hora de saída ou entrada da mercadoria, a partir da versão 3.10 essas duas TAGs se transformaram em apenas uma: dhSaiEnt que contem tanto a data quanto a hora (veja a formatação na página 17) da NT. No componente para manter a compatibilidade com a versão 2.00 o nome da propriedade ainda é dSaiEnt. Se a versão do XML for 2.00 devemos atribuir a essa propriedade a data e será gerado a TAG: dSaiEnt, por outro lado se a versão for 3.10 devemos atribuir a essa mesma propriedade a data e hora e será gerado a TAG dhSaiEnt. Quanto a linha que você esta questionando é que a TAG: dhSaiEnt só esta presente no modelo 55, ela não deve ser gerada se o modelo for 65. Na página 46 da NT mencionada acima temos uma observação referente a TAG dhSaiEnt, onde diz que: não devemos informar este campo para a NFC-e, ou seja modelo 65. Na página 100 temos a regra B10-10 referente ao modelo 65 que diz que a NFC-e será rejeitada caso esta tenha a TAG que contem a data e hora de saída/entrada. Por que o modelo 65 não tem essa TAG, simples, esse modelo se refere a NFC-e ou seja Nota Fiscal do Consumidor Eletrônica, sendo assim fica subentendido que a data e hora da saída da mercadoria é a mesma da emissão da nota. Se o seu parceiro acompanhasse a evolução dos documentos fiscais eletrônicos com base nos manuais e notas técnicas publicados pelo ENCAT e disponibilizados no Portal Nacional da NF-e, você não precisaria ficar argumentando com ele.

Bom dia, Primeiramente, por favor tenha calma, não estamos a disposição de todos 24 horas por dia e o nosso trabalho não se resume em responder questões no fórum. Conforme a sua postagem você informou o grupo e o campo de alteração da seguinte forma: <grupoAlterado><compl></grupoAlterado> <campoAlterado><xObs></campoAlterado> tente desta outra forma: <grupoAlterado>compl</grupoAlterado> <campoAlterado>xObs</campoAlterado>

Bom dia Luciano, Sim, no caso do MDF-e tanto o Cancelamento quanto o Encerramento são eventos. Lembre-se que todo MDF-e emitido e autorizado pela SEFAZ precisa ser Encerrado ou Cancelado caso conste erro ou outro problema qualquer.

Bom dia Vagner, Identifiquei alguns erros no seu TXT, são de grafia, o correto esta em negrito: [veic001] cInt=1 RENAVAM=584253168 placa=BWY8429 tara=17 capKG=27000 capM3=40 tpProp=T tpVeic=0 tpRod=03 tpCar=01 UF=SP CNPJ=26332442891 RNTRC=07089895 xNome=JOSE MAURY BRUNIALTI IE=202205274 PropUF=SP ProptpProp=1

Wislei, O ACBr não criou o seu próprio padrão, como dito na nota técnica o que esta definido nos manuais e notas técnicas publicadas pelo ENCAT estamos seguindo. Os XMLs cujo nome não foi estipulado pelo ENCAT, o ACBr procurou adotar um nome que condiz com o conteúdo do XML. E com a finalidade de padronizar alguns arquivos tiveram os seus nomes alterados.

Wislei, Muito obrigado pela colaboração, já esta disponível, favor atualizar os fontes.

Boa dia a todos, Favor atualizar os fontes e testar novamente.

Bom dia Wilei, Existe uma Nota Técnica publicada por nós referente a nomenclatura dos arquivos XML e PDF. Essa NT encontra-se disponível aqui mesmo no fórum na aba Downdoad e na pasta ...\Doctos\NotasTecnicas

Bom dia a todos, Favor atualizar os fontes e testar novamente.

Bom dia, Qual é o comando que você utiliza para fazer o envio?

Bom dia Wislei, Atribua o valor True a Configuracoes.Geral.Salvar e tente novamente.

Bom dia, O arquivo 0-ped-eve.xml é o envio do evento que neste caso de cancelamento. A SEFAZ após receber o pedido de evento, o processa e nos retorna o resultado. O retorno da SEFAZ é salvo com o seguinte nome 0-eve.xml, você tem esse arquivo?

Bom dia, Essa linha é incluída ao envelopar a a mensagem para ser enviada para o Web Services. Você concorda que a mensagem informando que o XML esta em desacordo com o Schema fica difícil de resolver? A mensagem é muito genérica e não aponta onde exatamente esta o problema. Outra coisa se você conseguiu gerar o XML com a mesma estrutura em comparação com o que é aceito por eles, então o que esta faltando? Seria interessante conseguir com o provedor ou com quem consegue emitir, o XML completo, ou seja, com as TAGs de envelope.

Altere também o código do município do tomador para 0025300 fora isso somente o codigoTributacaoMunicipio que não sei se é diferente para cada contribuinte ou se é o mesmo para todos.