Simone D. Russo

Bom dia Will. Vou renovar a homologação em Outubro e meu sistema também não possui meios externos para geração de DAV e Pré-Venda. Já questionei várias vezes a Polimig qui em SP sobre este requisito mas até agora não me deram uma resposta definitiva. Uma hora falam que vão consultar o pessoal de MG outra o Fisco, ou seja nem eles sabem orientar como deve ser feito. Por fim, devido a minha insistência, responderam o seguinte: "Ainda não obtivemos resposta ainda, mas conforme relatei anteriormente, acredito que vá uma observação no LAUDO especificando que a empresa não trabalha com essa particularidade e a não conformidade". Ou seja, eles "acreditam" que vai ser assim. Já argumentei que o manual é claro onde diz que: "A emissão do Cupom Fiscal, a partir de dados capturados por dispositivos móveis, internet e outros meios externos ao PAF-ECF e ao Sistema de gestão deverá ser realizada por meio de Módulo de Recepção Externa do PAF-ECF (MRE)," Ou seja...se meu sistema não tem esses meios externos para capturar dados eu estou desobrigada deste requisito. Mas parece que os técnicos não conseguem interpretar o texto apenas olham o perfil de requisitos e dizem: "E = exigido".

Obrigada Anderson, olhei no site e já percebi que são mais organizados que a Polimig. Tem programas para validar os arquivos rapidamente. Na Polimig analisa tudo no olho, demorando bem mais o processo. Temos um representante em Tubarão/SC também. Já entramos em contato com a UNISUL. Valeu mesmo.

Anderson, obrigada pelas informações. Desculpe mudar o foco do post mas gostaria de saber onde você costuma homologar seu PAF. Eu já fiz 3 vezes com a Polimig, mas este ano eles estão muito dispersos, o técnico não consegue responder nenhuma dúvida, não retornam nossos questionamentos e nem o boleto que vai vencer nos enviam (isso porque já cobramos diversas vezes por telefone). Estou um pouco preocupada quanto ao comportamento deles....

Bom dia, hoje vcs estão conseguindo comunicar com o WS de homologação? Sexta eu comuniquei normal, mas a partir de hoje só retorna o método Validar. Consultar e Enviar retorna o erro 500. Estou testando pelo exemplo do acbr http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx?op=Enviar http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx?op=Consultar http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx?op=Validar

Bom dia, hoje vcs estão conseguindo comunicar com o WS de homologação? Sexta eu comuniquei normal, mas a partir de hoje só retorna o método Validar. Consultar e Enviar retorna o erro 500. http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx?op=Enviar http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx?op=Consultar http://webservices.sathomologa.sef.sc.gov.br/wsDfeSiv/Recepcao.asmx?op=Validar

Não entendo mais nada. Nenhum cliente nosso de SC reclamou até agora.

Bom dia Também fomos surpreendidos com o mesmo problema ontem em SP e BA. Fizemos como outros colegas, passamos a enviar o literal "SEM GTIN" e atualizamos os Schemas. Os clientes desses Estados foram normalizados. A versão 1.30 da NT 2017.001(Junho/2018) coloca todos os CNAES e NCMs em produção para "Data Futura". Mas soltaram isso ontem e pegaram todos de surpresa no meio da tarde. A descrição da rejeição 889 ainda é clara e cita o anexo (tabela) de vigência: "Se não informado GTIN (cEAN=Nulo). Observação 1: Regra de validação se aplica por grupo de CNAE e NCM conforme vigência definida no ANEXO I.01; Observação 2: Para produtos que não possuem GTIN, utilizar a informação de "SEM GTIN"". No PA essa validação está valendo desde o dia 02/07, nossos clientes pararam lá também nesta data. Mas olha que estranho: o campo CNAE do emitente não é obrigatório no XML. Se mandamos sem CNAE não retorna rejeição 889 com GTIN em branco. Se mandamos com CNAE retorna a rejeição. Em SP ontem mandando sem CNAE rejeitava. RS, MG, RJ, GO, MT, MS, RR, SC todos emitindo NF-e e NFC-e normalmente com o GTIN em branco. Cada UF está interpretando as regras do seu próprio jeito.

Na unit pcnNFeW.pas o campo vDesc ainda está como não obrigatório: Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 0, nfe.Cobr.Fat.vDesc, DSC_VDESC); Por isso que ao passar zero, o acbr ignora.... Mude para: Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 1, nfe.Cobr.Fat.vDesc, DSC_VDESC); Que a tag passará a ser gerada no xml, mesmo com conteúdo zerado. Pode ser que na versão de hoje já esteja alterada, eu ainda não verifiquei.

Leonardo...mas misteriosamente a SEFAZ aceita 14 - Duplicata Mercantil, não estão validando. Em nenhum Estado valida porque meus clientes não reclamaram. Estou mudando de 14 pra 15 - Boleto Bancário porque acredito que logo vamos levar um susto, da noite pro dia vão passar a validar.

Eu me esforço mas não consigo entender a SEFAZ. A duplicata mercantil foi retirada na versão 1.50 (prevista para entrada em produção em 16/05/2018) mas a SEFAZ não está validando porque ainda emito nota em produção e homologação com este meio de pagamento.

No meu ambiente de homologação e produção dos clientes está tudo OK. Emiti agora para testar. Segue um exemplo de envio: 35180703368152000130550090000008931550279256-nfe.xml

Meus clientes estão emitindo notas em produção no mesmo formato de sempre, sem enviar a tag <vDesc> no grupo <fat> No manual da 1.60 as datas são: Ambiente de Homologação (ambiente de teste das empresas): 02/07/2018 Ambiente de Produção: 09/07/2018

Ambiente de homologação SP não está mais obrigando informar a tag <dup> para notas à vista, era um erro mesmo, já corrigiram. Para vendas a prazo já consigo informar a data de vencimento = data de emissão, corrigiram também. Sobre o grupo <fat>, devo informar a tag <vDesc> mesmo que zerada.

Ambiente de homologação SP já está travando as alterações de 03/09... Não consegui emitir hoje com o meu formato atual da parcela. No acbr , o campo vDesc não está como obrigatório e não vai no xml se estiver zerado, estourando também a rejeição 905 Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 0, nfe.Cobr.Fat.vDesc, DSC_VDESC); Mudei para o abaixo para conseguir testar. Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 1, nfe.Cobr.Fat.vDesc, DSC_VDESC); Cada piscada é um susto novo, tá tenso demais.

Bom dia Até 30/06 para notas à vista eu enviava somente as tags <fat> e <pag>. A partir de 01/07 a SEFAZ passou a exibir a tag <dup> também. Massssss a SEFAZ não aceita data de vencimento = data de emissão então tive que jogar um dia depois Se não enviar retorna a rejeição 851. Segue em anexo como eu enviava antes e como estou enviando agora. O estranho é que somente a SEFAZ de SP está validando, nossos clientes de outros Estados não reclamaram. Mais estranho ainda é que na descrição da rejeição 851 diz o seguinte: "Se informado o grupo de Parcelas de cobrança (tag:dup, Id:Y07) e a soma do valor das parcelas (vDup, id: Y10) difere do Valor Líquido da Fatura (vLiq, id:Y06). Obs.: Implementação futura em ambiente de produção a partir de 02-jul-2018." Eu entendi que somente "SE" eu enviar o grupo <dup> será validada a somatória das parcelas, mas SEFAZ SP está considerando a rejeição mesmo que a tag <dup> não seja enviada, o que na prática daria uma soma de zero. Posso estar muito enganada mas na minha humilde opinião isso é um erro da SEFAZ. Outra coisa que vai gerar conversa é o código da parcela que a partir de 03/09 deverá ser no formato 001, 002, 003.... O cliente não quer emitir uma venda à vista e ver no DANFE parcela: 1 e vencimento: (1 dia posterior)....na prática isso vai ficar muito ruim.

Falei com a Tatiane da Polimig agora a pouco. Ela me respondeu o seguinte: "Na homologação será cobrado apenas a validação do arquivo no WebService (podemos assim passar dados fictícios). Você deve implementar também o envio pois seu cliente utilizará este recurso, mas não testaremos".

Bom dia André, executei como você orientou e validou o XML corretamente. Mas o envio, realmente só retorna "Sucesso" quando passamos dados reais. Eu tenho credenciamento em Santa Catarina e cliente ativo lá, estou usando os dados dele para testar.

Bom dia, na propriedade XML você deve passar seu XML assinado e não o caminho. Passando o caminho dá esse erro aí. Aproveitando, estou passando assim: ACBrBlocoX.WebServices.EnviarBlocoX.XML := DMECF.ACBrBlocoX.ReducoesZ.XMLAssinado; ACBrBlocoX.WebServices.ValidarBlocoX.ValidarEcf := False; ACBrBlocoX.WebServices.ValidarBlocoX.ValidarPafEcf := False; ACBrBlocoX.WebServices.EnviarBlocoX.Executar; Mesmo assim, recebo o seguinte retorno: <EnviarResult><?xml version="1.0" encoding="utf-8"?><ReducaoZResposta xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><Codigo>9</Codigo><Mensagem>PAF-ECF não autorizado para esse contribuinte</Mensagem></ReducaoZResposta></EnviarResult>

Olá, aproveitando este post vou registrar um problema com retorno. Este log é de um cliente que utiliza um SAT da elgin, windows XP. Neste primeiro caso, a resposta foi: ACBrSAT.Resposta.codigoDeRetorno = 0 Mas, consultando o lote de cupons na área do cliente na SEFAZ, o mesmo foi corretamente validado e transmitido. 19/08/16 16:22:13:468 - NumeroSessao: 726748 - Comando: EnviarDadosVenda( <CFe> 19/08/16 16:22:14:546 - NumeroSessao: 726748 - Resposta:2Ų Logo após o cliente transmitiu novamente a mesma venda, que também está corretamente validada e registrada no site da SEFAZ: 19/08/16 16:24:44:453 - NumeroSessao: 561593 - Comando: EnviarDadosVenda( <CFe> 19/08/16 16:24:45:765 - NumeroSessao: 561593 - Resposta:561593|06000|1005| Já aconteceu com vocês de receber o retorno com este lixo, mesmo sendo uma venda validada com sucesso?

Bom dia Pessoal, tudo bem? Um membro do fórum me mandou uma mensgem privada esses dias perguntando se eu desenvolvi a fila, já que eu comecei a discussão rsrsr, vou copiar para vocês o que respondi pra ele: Eu implementei o compartilhamento sim, tem funcionado muito bem nos clientes. Fizemos um controle bem simples: 1) O SAT fica instalado num servidor. 2) Na estação, onde está o ERP instalado, quando o usuário na tela de vendas clica em "Emitir SAT", o sistema grava numa tabela do banco de dados chamada "FILA DO SAT" uma requisição de autorização (que contém um id único), e fica esperando a resposta (controlo isso num campo na tabela FILA, 0 = aguardando 1 = processado). 3) No servidor, onde está instalado o SAT, eu criei um programa que monitora essa tabela "FILA DO SAT", buscando registros do tipo "0 = aguardando". O programa pega esse registro (que contém o número da venda), gera o xml, envia ao aparelho, se aprovado, grava o xml de retorno. O próximo passo é gravar na tabela FILA, o resultado da operação "0 = reprovado e a mensagem de retorno/1 = aprovado" e seta "1 = processado". 4) A aplicação (que ficou num repeat until por até 20 segundos esperando o registro ser alterado para "1 = processado", ao receber a resposta, se aprovado, imprime o recibo, se reprovado envia a mensagem de retorno. Se em 20 segundos não recebeu retorno algum, retorna ao usuário a mensagem "SAT remoto não respondeu." Basicamente é isso. O controle desenvolvido é bem simples, mas tem funcionado bem em nossos clientes, já temos mais de 300 CNPJS vinculados à nossa empresa.

Bom dia Cris! Obrigada pela dica! Sucesso aí pra vc!

Bom dia Estou implementando o SAT na minha aplicação utilizando o aparelho da DIMEP e o ACBR. O interesse dos clientes aqui em adquirir o SAT, é que está sendo feito um movimento por alguns contadores, dizendo que o lojista poderá comprar um único aparelho que será compartilhado por todos os pontos de venda. Sabemos que não é bem assim, pois se o fluxo for muito grande, irá gerar gargalo na frente de caixa. O Marlus da DIMEP me orientou a criar um gerenciador de filas, que ficará num servidor, e que este servidor poderá ter a instalação física de vários SATs (um em cada USB - criando assim uma porta COM para cada aparelho). Assim, o gerenciador ao receber as vendas irá balancear a carga dos aparelhos direcionando os envios para os vários SATs instalados na máquina. A dll da DIMEP identifica automaticamente a porta COM que o SAT está instalado, correto? Dessa forma, como eu poderia ter vários SATs na mesma máquina? Qual SAT a dll iria "identificar"? Já questionei para o Marlus mas ele ainda não me respondeu. Resumindo, meu questionamento é: Como vocês estão pensando em desenvolver este controle de filas? Vocês acreditam que isso irá funcionar? Pois analisamos aqui vários aspectos chegamos à conclusão que nossos clientes vão preferir ter um SAT em cada máquina (como tem a impressora fiscal) evitando assim lentidão em suas vendas. Segue os emails enviados pelo Marlus: "No caso do sat , a sefaz permite o compartilhamento dos sats entre vários pdvs . O sat por especificação não e um equipamento de rede , e deve ser ligado ao pdv via USB . Para fazer o compartilhamento , deve ser desenvolvido um gerenciador de filas que irá gerenciar de qual pdv vem a solicitação e para qual sat deve ser enviado . Observe que está questão do compartilhamento deve ser avaliada com cuidado para não haver gargalo na operação da loja ." "Você pode conectar mais de um sat em um mesmo pc em usbs distintas, mas o controle de qual sat deve ser usado e do gerenciador de filas que deve ser desenvolvido . Observe que é complexa está solução de compartilhar sats , é possível mas deve ser bem avaliada para não criar problemas."

Segue a unit ACBrECFFiscNET e ACBrDevice para análise. Eu fiz ainda, uma alteração na função ACBrECFFiscNET.GetEstado para incluir também "Sem Papel". Para isso inseri um novo estado em ACBrDevice. Por favor, analise e valide também se esta alteração poderá fazer parte dos fontes oficiais. Obrigada pela atenção ACBrDevice.pas ACBrECFFiscNET.pas

Boa tarde Segundo o manual do fabricante e implementação do acbr, esta é a disposição dos campos: Constante 00. 1 2 GTDA GT no momento da última redução. 3 20 CANCEL Cancelamentos 21 34 DESCON Descontos 35 48 TR Tributos 49 112 TP Totalizadores Parciais Tributados 113 378 SANGRIA 379 392 SUPRIMENTOS 393 406 NSI Totalizadores não Sujeitos ao ICMS 407 532 CNSI Contadores dos TP’s não Sujeitos ao ICMS 533 568 COO Contador de Ordem de Operação 569 574 CNS Contador de Operações não Sujeitas ao ICMS 575 580 AL Número de Alíquotas Cadastradas 581 582 DATA_PC Data do Movimento 583 588 ACRESC Acréscimo 589 602 ACRFIN Acréscimo Financeiro 603 616 Segundo o arquivo que minha impressora gera, é esta: string fixa "00" 1 2 GT da última Redução 3 20 Cancelamentos 21 34 Descontos 35 48 string fixa "00000000000000" 49 62 Acrescimos 63 76 Venda Bruta 77 90 Aliquotas 91 154 Totalizador das Aliquotas 155 378 String fixa "TTTTTTTTTTTTTTTT" 379 394 Substituição tributária 395 408 Isento 409 422 Não Incidência 423 436 COO 451 456 Contador Geral de operação não fiscal 457 462 Data de Movimento 463 468 Eu implementei no acbr a leitura deste segundo layout também....como não tive suporte do fabricante e não sei o motivo dessa string ser diferente do manual, devo subir meu código? Eu fiz um tratamento pelo tamanho da string, para pegar as informações no formato antigo, ou no novo que eu criei.