.jpg.49dd1a5c5ffbc8d45fd706fcfabb6202.jpg)
Simone D. Russo
-
Total de ítens
33 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Simone D. Russo
-
-
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
-
31 minutos atrás, Oneide Luiz Schneider disse:
Aqui em SC já esta obrigando tbm faz dias ou semanas.
Precisei fazer isso semana retrasada.
Não entendo mais nada. Nenhum cliente nosso de SC reclamou até agora.
-
1
-
-
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.
-
1
-
-
12 minutos atrás, AG Sistemas disse:
Bom dia !
Estou com o mesmo problema para transmitir a nf-e em homologação eu passo "Cobr.Fat.vDesc := 0;" mas não esta aparecendo a TAG
Desde já agradeço.
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.
-
2
-
-
7 minutos atrás, Leonardo Araujo disse:
Que estranho... trocando para credito (05) loja deu a mesma mensagem... sem sucesso ainda
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.
-
9 horas atrás, Mauricio Bragaia disse:
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.
-
1
-
-
No meu ambiente de homologação e produção dos clientes está tudo OK. Emiti agora para testar.
Segue um exemplo de envio:
-
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.
-
1
-
-
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.
-
1 hora atrás, Reginaldo Caputo disse:
@Reginaldo Caputo já estou cuidando disso...mas vai gerar tanta reclamação
-
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.
-
1
-
-
Bom dia Cris!
Obrigada pela dica! Sucesso aí pra vc!
-
3
-
-
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
-
1
-
-
Boa tarde
Segundo o manual do fabricante e implementação do acbr, esta é a disposição dos campos:Constante 00. 1 2GTDA GT no momento da última redução. 3 20CANCEL Cancelamentos 21 34DESCON Descontos 35 48TR Tributos 49 112TP Totalizadores Parciais Tributados 113 378SANGRIA 379 392SUPRIMENTOS 393 406NSI Totalizadores não Sujeitos ao ICMS 407 532CNSI Contadores dos TP’s não Sujeitos ao ICMS 533 568COO Contador de Ordem de Operação 569 574CNS Contador de Operações não Sujeitas ao ICMS 575 580AL Número de Alíquotas Cadastradas 581 582DATA_PC Data do Movimento 583 588ACRESC Acréscimo 589 602ACRFIN Acréscimo Financeiro 603 616Segundo o arquivo que minha impressora gera, é esta:string fixa "00" 1 2GT da última Redução 3 20Cancelamentos 21 34Descontos 35 48string fixa "00000000000000" 49 62Acrescimos 63 76Venda Bruta 77 90Aliquotas 91 154Totalizador das Aliquotas 155 378String fixa "TTTTTTTTTTTTTTTT" 379 394Substituição tributária 395 408Isento 409 422Não Incidência 423 436COO 451 456Contador Geral de operação não fiscal 457 462Data de Movimento 463 468Eu 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.
Requisito LX e LXI da ER 02.06
em PAF-ECF
Postado
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".