Guilherme Verardi
-
Total de ítens
36 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Guilherme Verardi
-
-
Segue anexo o resto da alteração. Foram inseridas as regras de negócios 865 e 866, conforme a nota técnica, quando o layout for da versão 4 ou maior. Agradeço se puderem colocar no projeto.
-
Seguem os arquivos com o merge e os XML's gerados. Note que também mudei algumas variáveis locais para o private, pois estavam acessíveis de fora da classe, e o nome das propriedade de "EstadoProcessamento" para "SituacaoProcessamento", pois foram alterados no XML de retorno.
-
1
-
-
4 minutos atrás, Juliomar Marchetti disse:
é possível você efetuar um merge desse código e anexar novamente aqui Guilherme?
Vou trabalhar nisso.
-
1
-
-
2 minutos atrás, Vanessinha Mocellin disse:
Boa tarde Guilherme, nossa aplicação não utiliza o método "Validar", utilizamos apenas "Enviar" e "Consultar".
Teria que verificar se esta disponível esse serviço, caso sua aplicação esta utilizando esse método fique a vontade em testar e sugerir a alteração!
Sim, estou utilizando essa função antes de fazer o envio na minha aplicação.
Sobre os fontes, os arquivos que enviei nos outros posts contém esta alteração, por isso da pergunta, já que havia inserido nas minhas alterações estes detalhes. Inclusive as funções de Envio, pois as duas classes de envio possuem o mesmo layout. Podendo assim ser unidos em "ValidarBlocoX" e "EnviarBlocoX".
-
Boa tarde, não foi esquecido de alterar as classes TValidarEstoque e TValidarReducaoZ? Pergunto isso, pois se olhar o webservice de recepção, tanto em Homologação quando em Produção, não existe mais a operação "ValidarEstoque" ou "ValidarReducaoZ", mas somente a "Validar".
-
1
-
-
25 minutos atrás, IGOR ALEXANDRO SCHERER disse:
Gostaria de saber, pois o .exe que está junto com o seu demo.zip está comunicando normalmente com o webservice na opção EnviarBlocoX! Porém com o ACBR atualizado ele possui apenas EnviarReducaoZ ou EnviarEstoque, onde gera o erro http 500. Tentei implementar no meu ACBR suas alterações porém não obtive sucesso... Com o novo Layout o envio correto volta a ser pelo método EnviarReducaoZ?
Este tópico foi criado para falar sobre as alterações que fiz para funcionar. Se seguir a conversa desde o início, verá que existem anexos com os fontes do ACBr que alterei para funcionar com as novas alterações.
-
Em 03/11/2017 at 11:51, IGOR ALEXANDRO SCHERER disse:
Sim eu criei o meu baseado na documentação que é o correto! Porém na hora de validar (https://sathomologa.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/validacao.aspx) ele diz que o CNPJ é inválido por esse motivo queria um xml que esteja validando nesse link para eu ver o que tem de diferente... Ou se devo realizar algum cadastro do CNPJ no site!
Na ultima vez que procurei, a documentação oficial estava defasada. Se você seguir os schemas, do post da @naiaragomesp, verá que não bate com o da documentação.
-
16 horas atrás, Moisés disse:
Olá Guilerme,
Desinstalei o componente do BlocoX e suas dependências. Peguei novamente o instalador (ACBrInstall_Trunk2.exe) no site. Instalei novamente. Recompilei meu projeto e continuou dando "Erro Interno: 0 Erro HTTP: 500".
Resolvi pegar o exemplo que vem no componente (ACBrBlocoXDemo) e acrescentei o envio. Deu no mesmo "Erro Interno: 0 Erro HTTP: 500"
Não sei mais o que fazer. Estou enviando o fonte (do Demo) caso você queira ver como fiz (o executável esta junto)
Fiz umas alterações no seu Demo na opção de gerar arquivos para Estoque, seguindo o que tenho aqui na ultima versão dos arquivos. Talvez você não consiga compilar o projeto, pois utilizo o Delphi XE8, mas você vai ter um .exe e os fontes para analisar.
Uma coisa que percebi, é que talvez você esteja usando os arquivos do início do tópico, mas mais abaixo eu anexei um zip com mais algumas mudanças. Porque se você prestar atenção, não utilizo mais a função EnviarReducaoZ ou EnviarEstoque, e sim a EnviarBlocoX.
-
1
-
-
1 hora atrás, Moisés disse:
Olá, para mim quando envio está dando "Erro Interno: 0 Erro HTTP: 500". pelo que li vocês comentando é um problema no servidor e é intermitente.
Pergunto: Este tipo de coisa da só em homologação ou alguém já teve isto em produção?
Sobre a sua pergunta. Ainda não consegui testar em produção, pois estou esperando a liberação do laudo para testar em um cliente.
E sobre o erro, talvez você precise recompilar os seus arquivos do ACBr, pois testei aqui no servidor de homologação e a comunicação está ocorrendo, inclusive e estou recebendo o retorno com o recibo.
-
40 minutos atrás, BigWings disse:
Onde diz que a regra foi removida?
Na NT_2016_002_v1.40:
http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=c3aXrtAp dc=Na página 58, verá que a rejeição 767 foi excluída. E se tentar enviar uma NFC-e na versão 4 com o valor de pagamento maior que o valor do documento, verá que o XML será aceito pelo servidor do SEFAZ.
O que ocorre agora é uma validação para obrigar a informação do troco quando for o caso (Rejeição 866).
-
1
-
-
Boa tarde,
Após fazer alguns testes, percebi que a validação de regra de negócio dentro do ACBr ainda estava gerando a rejeição de NFC-e com somatório dos pagamentos diferente do total da NF.
Conforme novo layout da NFe e NFCe 4.0 isso já foi ajustado devido a nova tag de troco dentro das informações de pagamento. Segue anexo da alteração da regra de negócio 767, para validar apenas para versões menores da 4.0.
-
30 minutos atrás, Juliomar Marchetti disse:
Desculpe mas seu código está defasado.
tirou processos que definem endereços e outras coisas.
acho que precisa rever.
Boa tarde. Mas a minha pasta "ACBrBlocoX", está na ultima revision disponível (13945).
Sobre os processos, o que fiz foi unir as funções de Consulta e Envio de Estoque e Redução Z dentro do ConsultaBlocoX e EnviaBlocoX.
Não consegui encontrar alguma função que esqueci de mover, consegue me dar um exemplo?
-
A saga continua...hehe.
Agora o arquivo de retorno, dentro do bloco Result das operações teve o campo "EstadoProcessamentoCodigo" e "EstadoProcessamentoDescricao", alterado para "SituacaoProcessamentoCodigo" e "SituacaoProcessamentoDescricao" respectivamente. Segue no anexo os arquivos alterados.
-
Agora, naiaragomesp disse:
Então, até um tempinho atrás o meu retornava o recibo e status 0 - Aguardando no recibo, pensei que fosse demora do web service para processar, mas no dia seguinte consultei o número do recibo e retornou "Não encontrado", bem estranho.
Ao consultar meu envio de hoje de manhã, esta ocorrendo a mesma coisa. Porém estou no servidor de homologação, ainda não sei como está funcionando no de produção.
Mas como o procedimento de envio retorno o recibo, parece que se houver algum problema é no próprio servidor. Acho que ainda esta passando por um processo de aprimoramento.
-
Testei hoje pela manhã com estes fontes e funcionou. Só ainda não entendi se o quando o retorno contém o "Recibo", porém o código do "EstadoProcessamentoCodigo" é "0" significa que eles receberam. Porque pelo que vi nos documentos do bloco o código "0' seria para o status "Aguardando".
-
Sobre o problema do "Erro Interno: 0 Erro HTTP: 500". Acredito que tenha sido algo no servidor, pois hoje está funcionando normalmente.
-
Estou trabalhando em uma homologação na versão 02.05 para o estado de SC, e nos meus testes encontrei alguns erros ao tentar consumir as funções do webservice de homologação. Baseado nos problemas ocorridos, percebi que os schemas e funções do webservice foram modificadas, porém não encontrei nenhum documento esse novo layout.
Como preciso fazer a homologação acabei fazendo alguns ajustes nos fontes do ACBr. As alterações foram as seguintes:
ACBrBloxoX_Comum.pas:
Função "GerarDadosEstabelecimento": Somente é necessário o preenchimento do campo "Ie".
Função "GerarDadosPafECF": Somente é necessário o preenchimento do campo "NumeroCredenciamento".
ACBrBlocoX_ReducaoZ.pas:
Função "GerarXML":
- Somente é necessário preencher o campo "NumeroFabricacao" no bloco da ECF.
- Campos "VendaBrutaDiaria" e "GT", alterados para formatar o valor sem cadas decimais e com zeros a esquerda.
ACBrBloxoX_WebServices.pas:
- Funções "Validar" e "Enviar" unidas em uma só, pois agora como a função "Consultar", elas utilizam a mesma estrutura para Estoque ou Redução Z.No momento na função "Enviar" estou recebendo o retorno "Erro Interno: 0 Erro HTTP: 500". O que parece ser algo em relação ao arquivo de envio não estar de acordo com o esperado pelo servidor. Os arquivos estão no anexo, para alguém comitar eles e testar nos servidores de produção.
-
1
-
-
17 minutos atrás, Juliomar Marchetti disse:
Retornando ele passa tranquilo?
Não entendi se sua pergunta é em relação ao valor ficar negativo ou ao processo como um todo. Mas o testando com o mesmo valor do gobbo e utilizando o código antigo não tive problema de ficar negativo. E o processo como um todo ainda não tenho como confirmar, pois quando envio o arquivo recebo o código de retorno "0" e um código de recibo. Não sei dizer se isso significa que o arquivo foi aceito, pois o retorno "0' é aguardando.
Complementando mais um pouco, parece ter várias alterações no procedimento de comunicação com o webservice. Agora as função Validar, Enviar e Consultar possuem a mesma chamada para o Estoque e a Redução Z. Mas estou trabalhando nas alterações no momento. Assim que tiver algo mais concreto irei inserir em um outro tópico passando mais informações.
-
Bom dia,
Estou no momento trabalhando na implementação deste bloco, e devido a esta alteração, o arquivo da Redução Z está sendo rejeitado no validador, devido ao fato de o número da venda bruta diária e do GT estarem fora do formato aceito no schema.
Depois desta alteração, por exemplo, o valor no XML aparece <GT>4533781611,57</GT>, e ao validar este XML recebo a mensagem "The value '4533781611,57' is invalid according to its datatype 'Numero18Type'". Se utilizo o código anterior a alteração, ficando <GT>000000453378161157</GT> o arquivo é aceito. Basicamente o schema espera que o valor esteja formato com 14 ou 18 caracteres, nos casos do bruto diário e do GT respectivamente.
Recebo este retorno testando neste site: https://sathomologa.sef.sc.gov.br/tax.NET/sat.dfe.siv.web/validacao.aspx ou tentando enviar no servidor de homologação.
-
Bom dia,
Tive a necessidade de alterar o nome do documento na lista de spool e percebi que já havia na lista de "TODO" do ACBrDevice a ideia de criar a propriedade do nome do documento. Fiz a alteração e estou enviando em anexo caso alguém necessite ou alguém com acesso queria inserir no projeto.
-
1
-
-
Sobre o mesmo problema. Segue em anexo a inclusão dos novos campos no método "Assign" do TICMS no arquivo pcnNFe. Pois no meu caso, após usar o método "Assign" o campo pST ficava com valor 0, ocasionando o mesmo erro do tópico.
-
1
-
-
Realmente o problema foi causado pelo método "Validar" que não está mais assinando o arquivo automaticamente. Inseri o método de "Assinar' antes de validar e agora esta funcionando normalmente. A alteração está registrada na revision 13344.
-
Estou enfrentando o mesmo problema. No meu caso, mesmo depois de alterar o SSLLib para "libCapicom", após alguns segundos o erro ocorre. Estou usando a ultima versão dos fontes.
-
Também consegui resolver o problema. Mas no meu caso a solução foi alterar a ordem dos "uses" da unit onde havia o código de impressão da NFe. No caso, tive que mover todas as uses do ACBr para o início, por exemplo, havia lá:
uses
System.SysUtils, System.Classes, ACBrNFe, ACBrNFeDANFEClass, ...
Alterei para:
uses
ACBrNFe, ACBrNFeDANFEClass, System.SysUtils, System.Classes, ...
Decreto 54.308
em NFC-e - Nota Fiscal do Consumidor Eletrônica
Postado
Em resumo o que entendi é o seguinte:
ST Retido: Você pega a base unitária da última compra * a quantidade na nota. (Como no seu exemplo 3). A questão da alíquota também ainda estou em dúvida, mas acredito que se trate da alíquota interna mesmo.
ST Efetivo: Neste caso, a base é calculada normalmente de acordo com os valores do item no documento, como era feito anteriormente.