amarildolacerda

NFCe: WebService para RS: (ACBrNFeUtil.pas linha: 1305 - em -> class function NotaUtil.GetURLRS... ) .... case ALayOut of LayNfeRecepcao : Result := DFeUtil.SeSenao(AAmbiente=1, 'https://nfe.sefaz.rs.gov.br/ws/Nfeautorizacao/NFeautorizacao.asmx' 'https://homologacao.nfe.sefaz.rs.gov.br/ws/Nfeautorizacao/NFeautorizacao.asmx'); LayNfeRetRecepcao : Result := DFeUtil.SeSenao(AAmbiente=1, 'https://nfe.sefaz.rs.gov.br/ws/NferetAutorizacao/NFeretAutorizacao.asmx' 'https://homologacao.nfe.sefaz.rs.gov.br/ws/NferetAutorizacao/NFeretAutorizacao.asmx'); LayNfeInutilizacao : Result := DFeUtil.SeSenao(AAmbiente=1, 'https://nfe.sefaz.rs.gov.br/ws/nfeinutilizacao/nfeinutilizacao2.asmx' 'https://homologacao.nfe.sefaz.rs.gov.br/ws/nfeinutilizacao/nfeinutilizacao2.asmx'); LayNfeConsulta : Result := DFeUtil.SeSenao(AAmbiente=1, 'https://nfe.sefaz.rs.gov.br/ws/NfeConsulta/NfeConsulta2.asmx' 'https://homologacao.nfe.sefaz.rs.gov.br/ws/NfeConsulta/NfeConsulta2.asmx'); LayNfeStatusServico : Result := DFeUtil.SeSenao(AAmbiente=1, 'https://nfe.sefaz.rs.gov.br/ws/NfeStatusServico/NfeStatusServico2.asmx' 'https://homologacao.nfe.sefaz.rs.gov.br/ws/NfeStatusServico/NfeStatusServico2.asmx'); LayNfeCancelamento : Result := DFeUtil.SeSenao(AAmbiente=1, 'https://nfe.sefaz.rs.gov.br/ws/NfeCancelamento/NfeCancelamento2.asmx' 'https://homologacao.nfe.sefaz.rs.gov.br/ws/NfeCancelamento/NfeCancelamento2.asmx'); LayNFeCCe, LayNFeEvento : Result := DFeUtil.SeSenao(AAmbiente=1, 'https://nfe.sefaz.rs.gov.br/ws/recepcaoevento/recepcaoevento.asmx' 'https://homologacao.nfe.sefaz.rs.gov.br/ws/recepcaoevento/recepcaoevento.asmx'); end; end; ....

NFCe: em pcnNFeR.pas -> linha 175.... trocar o tipo de tcDat para tcDatHor. if NFe.infNFe.Versao >= 3 then begin (*B09*) NFe.ide.dEmi := Leitor.rCampo(tcDatHor, 'dhEmi'); // AL na NFCe utiliza data e hora (*B10*) NFe.ide.dSaiEnt := Leitor.rCampo(tcDatHor, 'dhSaiEnt'); end else begin (*B09*) NFe.ide.dEmi := Leitor.rCampo(tcDat, 'dEmi'); (*B10*) NFe.ide.dSaiEnt := Leitor.rCampo(tcDat, 'dSaiEnt'); (*B10a*)NFe.ide.hSaiEnt := Leitor.rCampo(tcHor, 'hSaiEnt'); end;

Em relação ao PAF-ECF, me parece que tem muita gente querendo que ele acabe. Acho que ainda é cedo para ficar animado. Nós temos como concorrentes: - o próprio NFCe, que ninguém ainda disse que vai matar o PAF-ECF ; - o NOVO ECF (desejado por alguns estados) - Este teve o prazo prorrogado em função de não haver fabricantes suficiente para iniciar o processo ( a máquina já existe / homologada); - o SAT em São Paulo - confirmei esta semana na AFRAC que não tem nenhum fabricante autorizado na SEFAZ até o momento - por isto espero que seja prorrogado; - e ainda, tem alguns falando de CF-e - nem vi o que este faz. Para quem esta em um estado ou outro, talvez não seja tão relevante; Mas para quem esta em todos os estados !!! dá para imaginar o cenário !!!

Vejo que o pessoal esta animado, muito bom. Aqui nós não temos tempo para aguardar o Italo, é uma pena, mas não tem outra saída, já que o cronograma que tenho (era iniciar produção em 15/03/2013), esta ajustado para 01/04/2013. Só espero que o Italo aproveite alguma coisa do código que disponibilizei. Nós tinhamos agenda para iniciar piloto na loja esta semana, mas por questões que nosso parceiro, o Tiago, virou papai (parabéns ao papai fresco), achamos melhor esticar mais uns 15 dias. Com isto deveremos ter piloto na loja atendendo cliente pelo final deste mês ou início de março/2013.

Especificação Técnica 2012.004 b (com as alterações da reunião de 05/12 em Aracaju). Especificações Técnicas do DANFE NFC-e_QRCode_Versao2_21_12_2012.pdf NT2012.004 v1.00b.pdf Especificações Técnicas do DANFE NFC-e_QRCode_Versao2_21_12_2012.pdf NT2012.004 v1.00b.pdf

A Reunião de Aracaju na semana passada definiu algumas datas: 07/12/2012 - Publicação de documentação técnica prevendo a compactação do XML no envio para SEFAZ (solicitação empresas). 14/12/2012 - Liberação do WS da SEFAZ para recebimento de XML compactado. 21/12/2012 - Liberação da versão atualizada da NT. A partir desta liberação, o manual não sofrerá alterações até a entrada em produção. Nova versão contemplará: Detalhamento do QRCode com hash de contingência. Detalhamento do prazo de cancelamento (24 horas) e cancelamento fora do prazo (168 horas). Inclusão de nova regra de validação (IE do destinatário). A partir da criação desta regra, não será mais permitido a emissão de NFC-e para empresas. Esta ação visa diminuir a incidência de rejeições nos PDVs, como acontece com a NF-e. Nos casos de venda para empresas, deverá ser emitida a NF-e modelo 55. 21/01/2013 - SEFAZ RS (estado) e AM. 04/02/2013 - SEFAZ RS (SVRS), MT, AC, SE, MA e RN. 30/04/2013 - Prazo máximo para entrada em produção.

3. Modelos de Impressão do DANFE NFC-e e do Relatório de Vendas 3.1 Relatório de Vendas O Relatório de venda, por tratar-se de um documento não fiscal com o objetivo de detalhar para o consumidor final a operação de venda realizada, não possui leiaute regulamentado, mas sim requisitos mínimos de informações. 3.1.1 Informações mínimas por item As informações mínimas que devem constar no documento de relatório de vendas referentes a cada item da operação de venda são: · Código = código do produto adotado pelo estabelecimento; · Descrição = descrição do produto; · Qtde = quantidade de unidades do produto adquiridas pelo consumidor; · Un = unidade de medida do produto; · Valor unit. = valor de uma unidade do produto; · Valor total = valor total do produto (Qtde x Valor unit) . 3.1.2 Informações mínimas de totalizadores As informações mínimas que devem constar no documento de relatório de vendas referentes ao total da compra são: · Valor total = somatório dos valores totais dos itens acrescido dos acréssimos e decrescido dos descontos. Este valor deve ser igual ao valor constante no DANFE resumido; · Forma de pagamento = forma na qual o pagamento da NFC-e foi efetuado (podem ocorrer mais de uma forma de pagamento, devendo neste caso ser indicado o montante parcial do pagamento para a respectiva forma. Exemplo: em dinheiro, em cheque, etc.; · Valor pago = valor recebido do cliente na forma de pagamento identificada imediatamente acima; · Troco = valor retornado para o cliente em função da soma dos meios de pagamento exceder o valor total da operação.

2. Leiaute de Impressão DANFE NFC-e Este capítulo descreve o leiaute de impressão do Documento Auxiliar da NFC-e pelo contribuinte, chamado de DANFE NFC-e, assim como os requisitos mínimos do relatório de venda que poderá acompanhar o DANFE NFC-e a critério do consumidor final. Algumas considerações acerca da impressão do DANFE NFC-e e do relatório de vendas: · O DANFE NFC-e é um documento fiscal auxiliar, sendo apenas uma representação simplificada em papel da transação de venda no varejo, de forma a permitir a consulta do documento fiscal eletrônico no ambiente da SEFAZ pelo consumidor final; · A impressão do DANFE NFC-e é efetuada diretamente pelo Aplicativo do contribuinte em impressora comum (não fiscal), com base nas informações do arquivo eletrônico XML da NFC-e; · No DANFE NFC-e não devem ser inseridas informações à mão, que não constem do arquivo eletrônico XML da NFC-e; · O relatório de vendas é um documento não fiscal com a finalidade de detalhar para o consumidor final a operação de venda realizada; · Poderá ser impresso apenas o DANFE NFC-e Resumido (ecológico), sem o relatório de vendas, que contém as informações detalhadas dos itens de mercadorias, desde que o consumidor assim o solicite. O consumidor que aceitar receber somente o DANFE NFC-e Resumido poderá posteriormente solicitar ao emissor a impressão do relatório de vendas ou correspondente DANFE NFC-e completo gerado pelo portal da Secretaria da Fazenda, que deverá ser fornecido sem custo; · A legislação poderá prever que, por opção do adquirente da mercadoria, o DANFE NFC-e não seja impresso e seja enviado por mensagem eletrônica (email ou MMS); ou seja impresso em formato resumido (DANFE NFC-e Resumido) sem a impressão do relatório de vendas. A legibilidade do texto impresso no DANFE NFC-e e no relatório de vendas, assim como a durabilidade do papel empregado, deverão ser garantidos, no mínimo, pelo prazo de seis meses.

Foram definidas as regras para o QRCode (veja abaixo). Alguém tem algum background sobre o assunto, como imprimi-lo usando o ACBr ? 1.2 Imagem do QRCode para NFC-e A imagem do QR Code que será impressa no DANFE NFC-e conterá uma URL composta com as seguintes informações: · Endereço do site da Secretaria da Fazenda de localização do emitente da NFC-e; · Chave de Acesso da NFC-e · Data e Hora da NFC-e (Formato AAAA-MM-DDThh:mm:ssTZD (UTC - Universal Coordinated Time, onde TZD pode ser -02:00 (Fernando de Noronha), -03:00 (Brasília) ou -04:00 (Manaus), no horário de verão serão - 01:00, -02:00 e -03:00. Ex.: 2010-08-19T13:00:15-03:00.) A URL ficará conforme exemplo mostrado abaixo: www.nfe.sefaz.se.gov.br/ConsultaNFCe.jsp?chaveAcesso= acesso>&data=&hora= O QR code deverá ser impresso com os padrões residentes das impressoras de não impacto (térmica, laser ou deskjet) e de impacto (matriciais ou de linhas). No DANFE NFC-e, o QR Code deverá ser impresso logo acima do espaço reservado à identificação do consumidor, tendo largura e altura mínimas de 15 mm x 15 mm. A largura e altura mínimas foram definidas conforme testes realizados, nos quais o leitor de QR Code conseguiu ler a imagem.

Definido a data de inicio de exigência para 01/07/2013... Portaria Cat-147 de 05/11/2012; Para concentrar os registros, vamos passar a utilizar o tópico: viewtopic.php?f=5&t=5034

Estabelecido o prazo de início de vigência do SAT. 01/07/2013.. http://info.fazenda.sp.gov.br/NXT/gateway.dll/legislacao_tributaria/portaria_cat/pcat1472012.htm?f=templates&fn=default.htm&vid=sefaz_tributaria:vtribut Liberado o simulador para o SAT. Esta no site da fazenda: http://www.fazenda.sp.gov.br/sat

Reunião do dia 07/11: Foram apresentadas propostas de funcionamento da NFC-e; No geral não ocorreram decisões sobre os trabalhos. O Newton Oller, quem coordena o projeto pelo lado do fisco, juntamente com sua equipe, anotaram as sugestões e levaram para discussão interna. Como houve publicação de data para o SAT-SP, há uma expectativa que o grupo acelere o processo da NFC-e visando a operacionalização antes da entrada em vigência do SAT-SP; Por enquanto não há novidades.

Ouvi recentemente da equipe do SAT que a data de implantação passou para ser o primeiro semestre de 2013, ou seja - mudanças de planos.

Sobre a reunião do dia 09/10, no seu todo houve avanço em alguns pontos básicos e outros nem tanto: - definido uma lista básica de meios de pagamentos (acresce alguns aos que o fisco há havia proposto); - apresentado uma lista de unidade de medida para constar como padrão; - em relação ao PIS/COFINS, não esteve presente o representante da Receita Federal, o que prejudicou a discussão. No entanto esteve presente o Marcelo/Sefaz/SP (envolvido com SAT) e ele ressaltou alguns pontos sobre SAT e em algum ponto ficou claro que o SAT já esta fechado quanto a este ponto, ou seja, será necessário informar dados de PIS/COFINS; Há uma tendência de ocorrer o mesmo com NFC-e, me parece que é uma questão de tempo para sua aplicação - não esta fechado; - foi informado sobre ajustes a serem feitos no SPED-Fiscal e Contribuições; esta em andamento um entendimento para alteração nos layouts e validadores; - um ponto de muita polêmica é o que trata sobre contingenciamento; Ainda se espera por sugestões dos participantes para melhorar o que já foi apresentado (haverá uma reunião para tratar exclusivamente do assunto no próximo dia 29/10 em SP); - um dos participantes (representante dos estados participante, me parece) discorreu sobre o interesse que no futuro seja ordenado algum modelo para exigir o código EAN no XML, argumentando que a forma como esta sendo utilizado hoje não esta contribuindo por falta de uma regra clara; - em relação ao NCM, há uma tendência que continue aceitando temporariamente os 2 primeiros dígitos, mas que depois de um prazo passará a exigir os 8 dígitos, bom irmos nos preparando para esta mudança. Por fim, não foi apresentado nenhuma mudança na norma técnica naquele evento, continuamos aguardando.

O Código que postei aqui é o mesmo que esto usando. No momento já emitidos perto de 1 centena de NFC-e com este código. Estas NFC-e foram enviadas para o site da SEFAZ/RS. Não estou encontrando problema para enviar e autorizar as NFC-e, o ponto aqui é em relação ao retorno, ainda não conseguimos avançar o bastante, mais por conta de algumas instabilidades no ambiente de homologação que espero ter um resultado mais consistente nesta semana que entra. Tem uma reunião para os participantes do piloto que ocorrerá no dia 09/10/12... Esta reunião vai discutir alteração no layout da NT 2012.004... "em especial, relativa a exigência dos campos do Pis e Cofins desejada pela Receita Federal"; Algumas coisas ainda não estão funcionando. Ex: Cancelamento, OFF-Line... No momento somente SEFAZ/RS e MT estão participando do Piloto. Eles estão discutindo quando vai abrir para os demais estado que assinaram o convênio, o que se sabe é que será ainda em outubro/12;

Segue código de ajuste para NFCe (NFe Versão 3.00) e Norma Técnica. Aviso aos navegantes... estes códigos estão com base na NT 2012.004 que ainda não foi concluída. Vou anexar a NT 2012.004 também... versão 0.01a. Certamente será alterada nos próximos dias. Para acessar o modelo CUSTOM, incluido na alteração do ACBrECF: Type TACBrECFCustom = class(TACBrECF) public function GetACBrECFClass:TACBrECFClassOf;override; end; function TACBrECFCustom.GetACBrECFClass: TACBrECFClassOf; begin result := TACBrNFCeClass; end; No lugar de inicializar TACBrECF no seu código, trocar para TACBrECFCustom. Atribuir o modelo para ser ecfCustom... que irá permitir chamar o novo modelo (no exemplo: a NFC-e - para impressão). Já para gerar a NFC-e, seguir as mesmas regras da NF-e do ACBr (só trocar a chamada para o fonte da versão 3.00) ACBrNFe3.rar PCN3.rar NT2012.004%20v1.00a.pdf ACBrNFCeClass.pas ACBrECF.pas ACBrECFClass.pas

No projeto SAT assim como na NFC-e, me parece adequado tratar a impressão em um outro componente como se fosse um ECF. Vai reduzir o trabalho de todos.

No momento estou envolvido com o piloto do projeto da NFC-e e não esta sobrando muito tempo. viewtopic.php?f=12&t=7399

O link ja voltou. https://www.sefaz.rs.gov.br/Site/Notici ... ciaId=4862

A NFG é o mesmo da NFe, vale o comentário para a NF-e. A NFC-e é um outro projeto. mais informações: https://www.sefaz.rs.gov.br/Site/Notici ... ciaId=4862 Link testado OK.

Em reunião na SEFAZ/SP neste último dia 01/10/2012, foi apresentado o cronograma de trabalho da SEFAZ/SP para implantação do SAT/SP. Em linhas gerais: -a homologação dos equipamentos se inciarão nesta próxima semana do dia 08; -a partir do dia 20/10 estará disponível para os desenvolvedores o simulador do SAT; -quem portar os AC para o SAT deverão se cadastrar em uma página a ser disponibilizada pela SEFAZ; -Implantação a partir de 01/01/2013 Material disponível: www.fazenda.sp.gov.br/sat

Com a NFC-e sai o ECF e no seu lugar entra o envio do XML para a SEFAZ. Mesmo sendo eletrônico, continua a necessidade de impressão da DANFE-NFC para o cliente. Neste ponto pode ser um impressora não fiscal de 40 colunas. Fluxo: Vende todos os itens no PDV -> formata o XML -> envia para SEFAZ -> aguarda autorização -> imprime o DANFE-NFC para o cliente. Desafios: - Imprimir código QR Code em uma impressora de 40 colunas. (alguém conhece alguma impressora não fiscal que tenha este código nativo ?); - Impressão concomitante, não é mais obrigatório; encontrar uma impressora que seja rápida suficiente para imprimir no final; Como há expectativa em imprimir um cupom reduzido, talvez não seja tão importante; - Alterar ACBrECF para permitir incluir novos modelos além dos previsto internamento. Isto permitirá desenvolver novos modelos independente do código principal do grupo e depois submete-los para aprovação ao grupo (sugestão anexo).

O material ainda não é oficial, por isto ainda não esta disponível. O estado do RS esta recebendo a versão nova na versão 3.00 para a NFC-e em homologação. Não existe produção ainda. Até o final de desta semana ou/ no mais tardar na outra eu terei o código do ACBr alterado para enviar NFC-e. Quando estiver mais claro o funcionamento e concluido os primeiros testes, irei disponbilizar aqui no grupo. Algumas mudanças principais: - Não obrigatório informar os dados do cliente; - Obrigatório informa a forma de pagamento da venda; - Inclui identificação para estrangeiros; - Não informar dados de PIS/COFINS; - Só pode ser utilizado para Venda Presencial / Internet; Esta previsto que a versão 3.00 passará a ser aplicado tanto para NFe como para NFC-e no futuro. Em relação ao Código ACBr... Já portamos o código disponível no dia 15/09 no grupo. Fizemos assim: - acrescentamos o digito 3 ao nome dos fontes (.pas), e mantemos o mesmo nome dos objetos. - alteramos as chamadas USES... para os novos nomes; - retiramos tags que não são mais válidas, ou foram alterados para formatos diferentes: ex dhEmi que passou a ter data/hora no formato TZD; excluido a hEmi e dEmi; - acrescentamos tags novas: ex: idFinal, idEstrangeiro.... e outras. - acrescentamos as tags relativo a forma de pagamento.... No momento já enviamos um teste para a SEFAZ RS... com poucas críticas que estaremos corrigindo. Abraços.

Dia 25/09, se iniciará o ambiente de teste para a NFC-e (NFe Versão 3.00). Até aqui foram concluídas as alterações do ACBrNFe 2.00 para as novas TAGs da versão 3.00. A NT 2012.004 prevê que no futuro a NFe 2.00 passará a utilizar a mesma versão da 3.00 e então funcionarão tanto NFe como NFC-e na mesma versão. Quando a finalidade for venda a consumidor final (NFC-e), algumas TAGs passam a ser obrigatórias e outras não precisam ser preenchida (ex: CPF/CNPJ do consumidor final);

Tentando alterar o mínimo possível no ACBr consegui gerar o 470 criando TACBrEFD_G5 = class(TACBrSpedFiscalExt); (veja o codigo anexo); Para inicializar o object: sped := TACBrEFD_G5.create(nil); // herda de TACBrSpedFiscal Para criar o registro C470.... C470 := sped.RegistroC470New; With C470 {bloco_C.registroC470New} Do Begin COD_ITEM := '1'; QTD := 1; UNID := 'KG'; QTD_CANC := 0; VL_ITEM := 100; CST_ICMS := '000'; CFOP := '5102'; Aliq_ICMS := 18; VL_PIS := 0,65; VL_COFINS := 3,00; if C470 is TRegistroC470_G5 then // avalia se é para gerar dados do G5 with TRegistroC470_G5(C470) do begin CST_PIS := '01'; VL_BC_PIS := 100; ALIQ_PIS := 0,65; CST_COFINS := '01'; VL_BC_COFINS := 100; ALIQ_COFINS := 3; IND_MOV := '1'; end; End; nao precisa fazer mais nada... o evento da classe é que vai adicionar a informação na linha; O que precisa mudar no ACBr: - passar para Protected/Virtual -> procedure WriteRegistroC470(RegC460: TRegistroC460);virtual em ACBrEFDBloco_C_Class.pas; [fim] ACBrEFD_G5.pas