Guilherme Verardi

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.

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. ACBrNFeNotasFiscais.pas

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. Fontes.zip Arquivos.zip

Vou trabalhar nisso.

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".

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.

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.

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. ACBrBlocoXDemo.zip

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.

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).

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. ACBrNFeNotasFiscais.pas

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. ACBrBlocoX.zip

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. ACBrBlocoX_Comum.pas ACBrBlocoX_ReducaoZ.pas ACBrBlocoX_WebServices.pas

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. ACBrDevice.pas

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. pcnNFe.pas

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, ...