Italo Giurizzato Junior

Bom dia Marcelo, Da forma que esta hoje no componente, o RPS é processado com sucesso pelo provedor?

Bom dia Renato, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório. Duas observação: O seu arquivo Cidades.ini esta desatualizado. Você tem certeza que se faz necessário assinar os pedidos de consulta? No Schema não consta que eles devem ser assinados.

Boa tarde Rômulo, Verifique se todos os fontes de todas as pastas estão atualizados. Pelo que vi, parece que os seus fontes estão desatualizados.

Boa tarde Rafael, Favor anexar o arquivo INI que você esta usando e que o envio ocorre sem problemas.

Boa tarde Marcelo, Deve ter mais alguma coisa que esteja provocando esse erro.

Henrique, Ainda hoje estarei enviando uma alteração, tanto nos fontes do componente quanto no arquivo Cidades.ini

Bom tarde Henrique, O jeito mesmo é passar o campo VersaoDados para o arquivo Cidades.ini Rafael, o seu problema não tem nada haver com o que esta sendo discutido nesse tópico, por favor vamos seguir as regras do fórum. Não misture assuntos.

Boa tarde Nelson, Foi necessário fazer um novo componente só para esse provedor? Não tinha como acrescentar esse provedor no componente ACBrNFSe aos moldes de outros que não seguem o layout da ABRASF? A não ser que a assinatura digital seja totalmente diferente da utilizada nos demais provedores.

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Favor atualizar os fontes e fazer novos testes.

Boa tarde, O componente ACBrReinf bem como o ACBreSocial, por ter dezenas de layouts (um para cada tipo de evento) até o momento não foi criado uma rotina que carrega o XML e extrai as informações contidas nas tags. O método LoadFromFile que por sua vez chama o LoadFromString carrega o arquivo e atribui o seu conteúdo em uma propriedade chamada XML. Feito isso é verificado se o XML lido esta assinado ou não, caso não esteja ocorre a assinatura. Em seguida o XML assinado é validado e salvo em disco e a propriedade XML agora é atualizada com o conteúdo do XML assinado. Desta forma ele já fica pronto para o envio individual ou em lote.

Boa tarde, Fiz uma alteração visando resolver esse problema, se você utiliza o ACBrMonitor aguarde a nova versão.

Muito obrigado pelo retorno. Tópico Fechado, para novo assunto favor criar um novo tópico.

Bom dia Adilson, Isso é muito estranho, pois o componente não tem nada haver com o banco de dados. Você armazena o XML de retorno no banco de dados ou em disco? Acredito que o problema seja algum campo da tabela que no Firebird esta com um tipo e no Oracle esta com outro. E a faixa de armazenamento desse outro é menor que o tipo usado no Firebird. Isso pode explicar a mensagem de erro: "argument out of range" = argumento fora do intervalo.

Bom dia Vagner, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia João, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Favor atualizar os fontes e faça novos teste.

Bom dia, Sim, já fiz a correção e ainda hoje vou enviar para o repositório.

Bom dia, Pelo que pude ver o problema não é o envio do BP-e e sim o seu cancelamento, correto? Sendo assim necessito dos XMLs referente ao envio do evento de cancelamento bem como o seu retorno. Favor anexar os XML de envio do evento e seu retorno para que possamos analisar.

Bom dia Luciana, Você tem os schemas do MDF-e junto com os da NF-e, pois muito bem, até o momento você não teve problemas porque não utilizou o método DistribuicaoDFe do MDF-e. Os schemas do Distribuição DFe do MDF-e se chama: distDFeInt_v1.00 já o da NF-e se chama: distDFeInt_v1.01 Como a versão do MDF-e é 3.00 o componente vai procurar pelo arquivo distDFeInt_v3.00 como não acha vai a procura de uma versão menor e acaba achando primeiramente o Schema da NF-e e não no MDF-e, ocasionando erros. E tem mais, se um tinha você vier a ter uma aplicação que emita CT-e o Schema do Distribuição DFe deste modelo de documento tem o mesmo nome do Schema do MDF-e, consequentemente vai ocorrer uma sobreposição de arquivos. Sendo assim, volto a afirmar não misture os schemas de modelos de documentos diferentes.

Bom dia Adilson, Você sabe me dizer se o XML do MDF-e é gerado, assinado e validado? Se sim, depois é gerado o XML de envio? Quando isso ocorre é interessante configurar o componente para salvar os arquivos Soap, pois o problema pode estar na leitura do retorno. Tendo os arquivos soap temos tanto os arquivos de envio, bem como os de retorno, isso as vezes ajuda a descobrir o motivo do problema.

Olá pessoal, Na postagem "Como obter o XML do Fornecedor" mostrei o uso do método DistribuicaoDFePorChaveNFe, nessa nova postagem vou mostrar mais dois métodos: DistribuicaoDFePorUltNSU e DistribuicaoDFePorNSU. Vamos a sintaxe, que por sinal é semelhante ao do DistribuicaoDFePorChaveNFe. DistribuicaoDFePorUltNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do ultimo NSU> ) DistribuicaoDFePorNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do NSU> ) Primeiramente vamos entender o que vem a ser esse tal de NSU. NSU - numero sequencial único, é um numero atribuído pelo Ambiente Nacional ao documento ora compartilhado pelas SEFAZ-Autorizadora. Exemplo: o emitente da nota é do Estado de São Paulo, logo a nota é enviada para a SEFAZ-SP esta por sua vez vai compartilhar com o Ambiente Nacional as notas que foram autorizadas, o Ambiente Nacional por sua vez atribui um NSU para cada nota que receber. Na verdade o Ambiente Nacional gera um resumo da nota e atribui o NSU a esse resumo primeiramente e não a nota propriamente dita. Um NSU só será atribuído a nota quando o destinatário enviar o evento de Manifestação do Destinatário. Lembre-se o NSU da nota será um numero diferente do NSU do resumo dela, e por ser gerado após o envio do evento de Manifestação do Destinatário, podemos concluir que o NSU da nota é maior que o NSU do resumo. Vamos agora entender como funciona os dois métodos mencionados acima. O método DistribuicaoDFePorNSU é o mais simples de entender, pois este simplesmente baixa o documento que possui o NSU informado. Note que usei o termo documento, pois o webservice DistribuicaoDFe pode retornar os seguintes tipos de documentos: Resumo de Nota, Nota Completa, Resumo de Evento e Evento Completo. Se o NSU informado no método DistribuicaoDFePorNSU for o NSU de um resumo, o que teremos como retorno será o XML do resumo e não o XML da Nota. Por outro lado o método DistribuicaoDFePorUltNSU nos retorna uma lista com até 50 documentos, cujos NSU são superiores ao NSU informado. Exemplo: DistribuicaoDFePorUltNSU( 35, 12345678000123, 450 ) ===> 450 é o valor do Ultimo NSU. Ao executar o método, como dito anteriormente poderá nos retornar uma lista com até 50 documentos, pois bem suponha que retorne 50, os NSU desse documentos retornados serão, 451, 452, 453, ...., 498, 499, 500. Lembre-se que nessa lista podemos ter Resumos de Notas, Notas Completas, Resumo de Eventos e Eventos Completos. Através de uma propriedade chamada Schema nos traz a informação do tipo de documento retornado. Temos também outras duas propriedades muito importantes, são elas: UltNSU e MaxNSU. A propriedade UltNSU nos informa o numero do NSU referente ao ultimo documento da lista, já a propriedade MaxNSU nos informar o maior NSU existente no Ambiente Nacional. Continuando o exemplo acima, vamos supor que após a execução os valores de UltNSU e MaxNSU são respectivamente 500 e 750. Era de se esperar mesmo que o valor de ultNSU seja 500 pois informamos 450 e foi retornado 50 documentos, logo o NSU do ultimo é 500. A próxima vez que formos executar o DistribuicaoDFePorUltNSU devemos informar o valor 500, para que ele retorne os documentos a partir de 501 que é o próximo da lista. E devemos repetir o procedimento até que o valor de ultNSU seja igual a maxNSU, desta forma vamos ter baixado todos os documentos disponibilizados pelo Ambiente Nacional. Lembre-se que o valor de MaxNSU tende sempre a crescer a medida que novas notas forem emitidas e compartilhadas com o Ambiente Nacional e a medida que o destinatário for enviando o evento de Manifestação do Destinatário. Entre uma execução e outra do DistribuicaoDFePorUltNSU você pode realizar a manifestação referente a cada resumo de nota obtido, ou seja, enviar o evento de Manifestação do Destinatário. Desta forma a medida que você vai avançando na lista o Ambiente Nacional já vai liberando a Nota Completa (notas manifestadas) e disponibilizando ela na lista. O DistribuicaoDFe não serve apenas para que possamos obter o XML do fornecedor, mas também descobrirmos se existe alguma empresa emitindo notas contra o nosso CNPJ sem no nosso consentimento. Você descobre isso através do DistribuicaoDFePorUltNSU e pode avisar a SEFAZ enviando o evento de Manifestação do Destinatário: Desconhecimento da Operação. Esse evento diz a SEFAZ que você não comprou desse fornecedor. Para saber mais sobre Manifestação do Destinatário vide a Nota Técnica 2012/002 versão 1.02 e para saber mais sobre o Distribuição DFe vide a Nota Técnica 2014/002 versão 1.02b, ambas estão disponíveis no Portal Nacional da NF-e.

Bom dia Lucas, Você costuma atualizar todos os fontes de todas as pastas com frequência? Pois os Schemas bem como a atualização dos fontes e do programa exemplo, foram enviados para o repositório no dia 10/09/2018, data esta da liberação do ambiente de homologação.

Bom dia, Pelo que sei até o momento o DABPE só foi desenvolvido em EscPos, sendo assim não é possível gerar o seu PDF. A geração do PDF só será possível quando tivermos o DABPE em Fast e ou Fortes Report. Se tiver interesse em colaborar com o projeto desenvolvendo em Fast e ou Fortes Report, ficaremos gratos, pois toda ajuda é bem vinda.

Bom dia Rômulo, Configura o componente para salvar os arquivos soap. Depois anexa os arquivos soap de envio, de consulta e de cancelamento para que possamos analisar.